Errata Search
RFC Number:		Errata ID:
Source of RFC		Status:	All/Any Verified+Reported Verified Reported Held for Document Update Rejected
Area Acronym:	All/Any app art gen int ops rai rtg sec tsv wit	Type:	All/Any Editorial Technical
WG Acronym:		Submitter Name:
Other:	All/Any IAB INDEPENDENT IRTF Legacy Editorial	Date Submitted:
Summary Table Full Records

Found 7142 records.

Status: Verified (3238)

RFC 5, "Decode Encode Language (DEL)", June 1969

Source of RFC: Legacy

Errata ID: 582
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Zhang Xin Liang
Date Reported: 2005-05-23

In the Forward, it says:

It was generally agreed beforehand that the runmning of interactive
programs across the network was the first problem that would be
faced.

It should say:

It was generally agreed beforehand that the running of interactive
programs across the network was the first problem that would be
faced.

Errata ID: 5296
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Krzysztof Piecuch
Date Reported: 2018-03-22
Verifier Name: John Scudder
Date Verified: 2024-01-12

Throughout the document, when it says:

Network Working Group                                           4691
RFC-5                                                           Jeff Rulifson
                                                                June 2, l969

It should say:

Network Working Group                                           4691
RFC-5                                                           Jeff Rulifson
                                                                June 2, 1969

Notes:

Most likely OCR interpreted 1 as L. The date should be 1969 obviously.

Errata ID: 5866
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Martin Thomson
Date Reported: 2019-09-26
Verifier Name: Benjamin Kaduk
Date Verified: 2019-09-26

Section FORWARD says:

FORWARD

It should say:

FOREWORD

Notes:

"Foreword" is a generally accepted name for text that is put before a document. In this case "PREFACE" would also be acceptable, but it seems to be the case that "FOREWORD" was the intent.

RFC 20, "ASCII format for network interchange", October 1969

Source of RFC: Legacy

Errata ID: 4217
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Levine
Date Reported: 2015-01-03
Verifier Name: Barry Leiba
Date Verified: 2015-01-05

Section 4.2 says:

      2 The use of the symbols in 2/2, 2/7, 2/12, 5/14, /6/0, and 7/14
   as diacritical marks is described in Appendix A, A5.2
      3 These characters should not be used in international interchange
   without determining that there is agreement between sender and
   recipient.  (See Appendix B4.)

It should say:

     2 The use of the symbols in 2/2, 2/7, 2/12, 5/14, /6/0, and 7/14
   as diacritical marks is described in Appendix A, A5.2, of X3.4-1968.
      3 These characters should not be used in international interchange
   without determining that there is agreement between sender and
   recipient.  (See Appendix B4 of X3.4-1968.)

Notes:

The appendixes are in the original standard, not the RFC.

In the abstract, it says "X3, 4-" rather than "X3.4-" which is surely an OCR or transcription error.

Errata ID: 6652
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2021-07-31
Verifier Name: RFC Editor

Section 4.2 says:

      2 The use of the symbols in 2/2, 2/7, 2/12, 5/14, /6/0, and 7/14

It should say:

      2 The use of the symbols in 2/2, 2/7, 2/12, 5/14, 6/0, and 7/14

Notes:

Unnecessary slash.

Errata ID: 6879
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: studentmain
Date Reported: 2022-03-12
Verifier Name: RFC Editor
Date Verified: 2022-03-14

Throughout the document, when it says:

where as UCLA uses X'OD' or 0/13 (carriage return).

It should say:

where as UCLA uses X'0D' or 0/13 (carriage return).

Notes:

x'0d', not x'od'

RFC 31, "Binary Message Forms in Computer", February 1968

Source of RFC: Legacy

Errata ID: 581
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jim Ursetto
Date Reported: 2000-09-25

Section 7 says:

   This size declaration should appear at the end of the
   message description; thus, forcing the reader to postpone an early
   consideration of bit details. xmodmap -e "add lock = Caps_Lock"

It should say:

   This size declaration should appear at the end of the
   message description; thus, forcing the reader to postpone an early
   consideration of bit details. 

RFC 33, "New Host-Host Protocol", February 1970

Note: This RFC has been updated by RFC 36, RFC 47

Source of RFC: Legacy

Errata ID: 1053
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Noel Chiappa
Date Reported: 2007-08-13
Verifier Name: ron bonica
Date Verified: 2010-05-11

On page 3, it says:

   It is important to remember that there are 356 links
   in each direction and that no relationship among these is imposed by
   the network.

It should say:

   It is important to remember that there are 256 links
   in each direction and that no relationship among these is imposed by
   the network.

Errata ID: 1780
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Matthias Bärwolff
Date Reported: 2009-05-11
Verifier Name: ron bonica
Date Verified: 2010-05-11

Throughout the document, when it says:

RFMN

It should say:

RFNM

Notes:

This typo occurs twice on page 4.

RFC 124, "Typographical error in RFC 107", April 1971

Source of RFC: Legacy

Errata ID: 5787
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Darius Kazemi
Date Reported: 2019-07-19
Verifier Name: Eric Vyncke
Date Verified: 2024-01-12

Throughout the document, when it says:

RFCs Updated:  106

It should say:

RFCs Updated:  107

Notes:

Amusingly, this early RFC errata mis-labels the very RFC that it's updating (though it's correct in two other places in the document, including the title).

RFC 162, "NETBUGGER3", May 1971

Source of RFC: Legacy

Errata ID: 6589
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Martin Thomson
Date Reported: 2021-05-24
Verifier Name: Benjamin Kaduk
Date Verified: 2021-05-24

Throughout the document, when it says:

   An alternate possibility is for Host X to use his Telnet to enter our
   system and start NETBUGGER3 himself.  He can then be running
   NETBUGGER3 on one console and his filenet on another.

   An alternate possibility is for Host X to use his Telnet to enter our
   system and start NETBUGGER3 himself.  He can then be running
   NETBUGGER3 on one console and his filenet on another.

It should say:

   An alternate possibility is for Host X to use his Telnet to enter our
   system and start NETBUGGER3 himself.  He can then be running
   NETBUGGER3 on one console and his filenet on another.

Notes:

It looks like the transcription resulted in the duplication of this paragraph.

RFC 194, "The Data Reconfiguration Service -- Compiler/Interpreter Implementation Notes", July 1971

Source of RFC: Legacy

Errata ID: 5859
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Darius Kazemi
Date Reported: 2019-09-14
Verifier Name: John Scudder
Date Verified: 2024-01-12

Section 3 says:

  +-------------+                        +--------------+
  | inputstream |                        | outputstream |
  +-------------+                        +--------------+
             /\                           /
              \                          /
               \                        /
                \                     \/
                +-----------------------+
                |         CPU           |
                +-----------------------+
                       |        /\
                       |         |
                       |         |
                       \/        |
                +-----------------------+
    Storage:    | Instruction           |
                | Sequence              |
                +-----------------------+
                | Label Table           |
                +-----------------------+
                | Literal/Identifier    |
                | Pool                  |
                +-----------------------+
                | Variable length       |
                | string area           |
                +-----------------------+


                Fig. 1. Form Interpreter

It should say:

  +-------------+                        +--------------+
  | inputstream |                        | outputstream |
  +-------------+                        +--------------+
             \                           /\
              \                          /
               \                        /
               \/                      /
                +-----------------------+
                |         CPU           |
                +-----------------------+
                       |        /\
                       |         |
                       |         |
                       \/        |
                +-----------------------+
    Storage:    | Instruction           |
                | Sequence              |
                +-----------------------+
                | Label Table           |
                +-----------------------+
                | Literal/Identifier    |
                | Pool                  |
                +-----------------------+
                | Variable length       |
                | string area           |
                +-----------------------+


                Fig. 1. Form Interpreter

Notes:

This was discovered while cross-referencing the online RFC Editor txt version to a paper original at the Computer History Museum. Reference: https://write.as/365-rfcs/rfc-194

RFC 640, "Revised FTP reply codes", June 1974

Source of RFC: Legacy

Errata ID: 3435
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2012-12-25
Verifier Name: Barry Leiba
Date Verified: 2012-12-25

Section 11a says:

       There are four values for the first digit of the reply code:      11a

It should say:

       There are five values for the first digit of the reply code:      11a

Notes:

Technical type (vs. Editorial) although operation was not affected ("four" cannot reasonably be considered a misspelling of "five")

Reply code first digit values per sections 11b through 11f are 1, 2, 3, 4, and 5

RFC 675, "Specification of Internet Transmission Control Program", December 1974

Note: This RFC has been obsoleted by RFC 7805

Source of RFC: Legacy

Errata ID: 6868
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Chuck Craft
Date Reported: 2022-03-05
Verifier Name: RFC Editor
Date Verified: 2022-03-15

Section 7 says:

6. ROWE74

It should say:

6. ROWE70

Notes:

[PSN] [ROWE70,
POUZ73].

AFIPS 1970,

RFC 783, "TFTP Protocol (revision 2)", June 1981

Note: This RFC has been obsoleted by RFC 1350

Source of RFC: Legacy

Errata ID: 580
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: "Yin Shuming"
Date Reported: 2006-02-18

Section 2 says:

Any transsfer begins with a request to read or write a file, which also 
serves to request a connection.

It should say:

Any transfer begins with a request to read or write a file, which also 
serves to request a connection.

Notes:

from pending

Errata ID: 703
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: "Yin Shuming"
Date Reported: 2006-02-18

Section 5 says:

The mode field contains the string "netascii", "octec", or "mail" (or any 
comibnation of upper and lower case, such as "NETASCII", "NetAscii", etc.) 
in netascii indicating the three modes defined in the protocol.

It should say:

The mode field contains the string "netascii", "octec", or "mail" (or any 
combination of upper and lower case, such as "NETASCII", "NetAscii", etc.) 
in netascii indicating the three modes defined in the protocol.

Notes:

spelling error: comibnation/combination

from pending

RFC 791, "Internet Protocol", September 1981

Note: This RFC has been updated by RFC 1349, RFC 2474, RFC 6864

Source of RFC: Legacy
Area Assignment: int

Errata ID: 716
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Damien Mattei
Date Reported: 2007-01-03
Verifier Name: Ralph Droms
Date Verified: 2010-12-06

Section 3.1 says:

        +--------+--------+--------+--------+
        |10001000|00000010|    Stream ID    |
        +--------+--------+--------+--------+
         Type=136 Length=4

It should say:

        +--------+--------+--------+--------+
        |10001000|00000100|    Stream ID    |
        +--------+--------+--------+--------+
         Type=136 Length=4

Rationale:

This number count the length which is 4 and not 2.
10 in binary is 2 in decimal, 100 in binary is 4 in decimal.

The option-length octet counts the option-type octet and the 
option-length octet as well as the option-data octets.(see page 15)
The length is 4 for the Stream identifier option as we have 4 bytes and 
it is well written in page 16 of RFC 791:

The following internet options are defined:

      CLASS NUMBER LENGTH DESCRIPTION
      ----- ------ ------ -----------
        0     0      -    End of Option list.  This option occupies only
                          1 octet; it has no length octet.
        0     1      -    No Operation.  This option occupies only 1
                          octet; it has no length octet.
        0     2     11    Security.  Used to carry Security,
                          Compartmentation, User Group (TCC), and
                          Handling Restriction Codes compatible with DOD
                          requirements.
        0     3     var.  Loose Source Routing.  Used to route the
                          internet datagram based on information
                          supplied by the source.
        0     9     var.  Strict Source Routing.  Used to route the
                          internet datagram based on information
                          supplied by the source.
        0     7     var.  Record Route.  Used to trace the route an
                          internet datagram takes.
        0     8      4    Stream ID.  Used to carry the stream
                          identifier.
        2     4     var.  Internet Timestamp.

Notes:

from pending

Errata ID: 6356
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Patrick Ni
Date Reported: 2020-12-15
Verifier Name: Eric Vyncke
Date Verified: 2021-01-04

Section 3.2 says:

(14) THEN TL <- TDL+(IHL*4)

It should say:

(14) THEN TL <- TDL+(IHL-Of-First-Fragment*4)

Notes:

IHL could be different between the first fragment and the rest. Only the first fragment's IHL is the same as the one in the original datagram before fragmentation

--- Verifier note ---
Updated the type of errata to technical from editorial.

Section 3.2 of RFC 791 clearly states that "When fragmentation occurs, some options are copied, but others remain with the first fragment only." so IHL varies from fragment to fragment. Therefore when copying the IP header of the F=0 fragment (step 11) all options are rightfully copied and must be counted in the re-assembled fragment total length on step 14 as noted by Patrick Ni.

Errata ID: 579
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Pavel Uvarov
Date Reported: 2004-06-16

On page 21, it says:

The intitial contents of the route data area must be zero.

It should say:

The initial contents of the route data area must be zero.

Errata ID: 583
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Pavel Uvarov
Date Reported: 2004-06-16

On page 23, it says:

The intitial contents of the timestamp data area must be zero 
or internet address/zero pairs.

It should say:

The initial contents of the timestamp data area must be zero 
or internet address/zero pairs.

Notes:

Spelling error.

Errata ID: 5037
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Prabhu K Lokesh
Date Reported: 2017-06-10
Verifier Name: RFC Editor
Date Verified: 2017-06-12

Section GLOSSARY says:

NFB
          The Number of Fragment Blocks in a the data portion of an
          internet fragment.  That is, the length of a portion of data
          measured in 8 octet units.

It should say:

NFB
          The Number of Fragment Blocks in the data portion of an
          internet fragment.  That is, the length of a portion of data
          measured in 8-octet units.

Notes:

Extra article 'a' before the term 'data portion of an internet fragment'.

Errata ID: 6184
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ye Shu
Date Reported: 2020-05-21
Verifier Name: Erik Kline
Date Verified: 2020-05-21

Section 3.2 says:

fragmentation strategy is designed so than an unfragmented datagram has all zero fragmentation information

It should say:

fragmentation strategy is designed so that an unfragmented datagram has all zero fragmentation information

Notes:

typo: so than => so that

Errata ID: 7561
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Fernando Gont
Date Reported: 2023-07-10
Verifier Name: Eric Vyncke
Date Verified: 2023-08-03

Section 3.2 says:

  Identification

    The choice of the Identifier for a datagram is based on the need to
    provide a way to uniquely identify the fragments of a particular
    datagram.  The protocol module assembling fragments judges fragments
    to belong to the same datagram if they have the same source,
    destination, protocol, and Identifier.  Thus, the sender must choose
    the Identifier to be unique for this source, destination pair and
    protocol for the time the datagram (or any fragment of it) could be
    alive in the internet.

    It seems then that a sending protocol module needs to keep a table
    of Identifiers, one entry for each destination it has communicated
    with in the last maximum packet lifetime for the internet.

    However, since the Identifier field allows 65,536 different values,
    some host may be able to simply use unique identifiers independent
    of destination.

It should say:

  Identification

    The choice of the Identification for a datagram is based on the need to
    provide a way to uniquely identify the fragments of a particular
    datagram.  The protocol module assembling fragments judges fragments
    to belong to the same datagram if they have the same source,
    destination, protocol, and Identification.  Thus, the sender must choose
    the Identification to be unique for this source, destination pair and
    protocol for the time the datagram (or any fragment of it) could be
    alive in the internet.

    It seems then that a sending protocol module needs to keep a table
    of Identification values, one entry for each destination it has communicated
    with in the last maximum packet lifetime for the internet.

    However, since the Identification field allows 65,536 different values,
    some host may be able to simply use unique identifiers independent
    of destination.

Notes:

The field is called "Identification", and not "Identifier" (please note the capitalization in the text).

Errata ID: 7560
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Simon Günther
Date Reported: 2023-07-04
Verifier Name: RFC Editor
Date Verified: 2023-07-06

Section 3.1, Line 904 says:

Bits   5:  0 = Normal Relibility, 1 = High Relibility.

It should say:

Bits   5:  0 = Normal Reliability, 1 = High Reliability.

Notes:

Typo

RFC 792, "Internet Control Message Protocol", September 1981

Note: This RFC has been updated by RFC 950, RFC 4884, RFC 6633, RFC 6918

Source of RFC: Legacy
Area Assignment: int

Errata ID: 577
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Beren Sanders
Date Reported: 2002-09-09

On p. 16 and 18, it says:

   IP Fields:

   Type

It should say:

   ICMP Fields:

   Type

Notes:

On page 16, the section 'Timestamp and Timestamp Reply Messages' has
the header 'IP Fields:' - first mentioned after the graph and then
again after 'Addresses'. The second one should actually be 'ICMP
Fields:'. This error also occurs in the discussion of the
'Information Request and Information Reply Message' on page 18.

The second 'IP Fields:' section of these two sets of message
descriptions are really talking about fields in the ICMP header not
the IP header.

[This report was updated 2009-03-11 to specify the original and corrected text, as indicated by Nikolai Malykh.]

Errata ID: 576
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Arun Darlie Koshy
Date Reported: 2004-03-26

In the Introduction, fourth paragraph, it says:

Also ICMP messages are only sent about errors in handling fragment zero of
fragemented datagrams.  (Fragment zero has the fragment offeset equal
zero).

It should say:

Also ICMP messages are only sent about errors in handling fragment zero of
fragmented datagrams.  (Fragment zero has the fragment offset equal
zero).

Errata ID: 6458
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2021-03-07
Verifier Name: Erik Kline
Date Verified: 2021-03-07

Section [Page 17] says:

      If the time is not available in miliseconds or cannot be provided

It should say:

      If the time is not available in milliseconds or cannot be provided

Notes:

Misspelled "milliseconds".

RFC 793, "Transmission Control Protocol", September 1981

Note: This RFC has been obsoleted by RFC 9293

Note: This RFC has been updated by RFC 1122, RFC 3168, RFC 6093, RFC 6528

Source of RFC: Legacy
Area Assignment: tsv

Errata ID: 573
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Robert Braden
Date Reported: 2007-02-22

A number of details in RFC 793 were corrected, modified, or clarified in RFC 1122. Familiarity with RFC 1122 and more recent TCP documents is imperative before any implementation of RFC 793 is attempted.

TCP Feature             RFC 793 Ref       See RFC 1122 Section

Received PUSH bit	Section 2.8		4.2.2.2	
Urgent Pointer		Section 3.1		4.2.2.4
TCP state diagram	Section 3.2, p.23	4.2.2.8
Simultaneous Open	Section 3.4, Fig 8	4.2.2.10
Retransmission Timeout	Section 3.7		4.2.2.15, 4.2.3.1
Event Processing	Section 3.9		4.2.2.20

Errata ID: 1562
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Verifier Name: Wes Eddy
Date Verified: 2011-08-13

Section 3.3 says:

Remember that each segment is bound to as many consecutive sequence numbers as
there are octets of data in the segment.
...
the numbers occupied by a segment are "busy" or "in use" until MSL seconds have
passed, upon crashing a block of space-time is occupied by the octets of the
last emitted segment,

It should say:

Remember that each segment is bound to as many consecutive sequence numbers as
there are octets of data and SYN or FIN flags in the segment.
...
the numbers occupied by a segment are "busy" or "in use" until MSL seconds have
passed, upon crashing a block of space-time is occupied by the octets and SYN or
FIN flags of the last emitted segment,

Notes:

I changed this text to specifically include the SYN and FIN bits, rather than the previous errata wording which was unclear since other control flags are not part of the sequence space, based on discussion on the TCPM mailing list which indicated that the prior wording was confusing.

Errata ID: 1564
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Verifier Name: Wes Eddy
Date Verified: 2011-08-13

Section 3.7 says:

When the sender creates a segment and transmits it the sender advances
SND.NXT.  When the receiver accepts a segment it advances RCV.NXT and
sends an acknowledgment.  When the data sender receives an
acknowledgment it advances SND.UNA.  The extent to which the values of
these variables differ is a measure of the delay in the communication.
The amount by which the variables are advanced is the length of the
data in the segment.  Note that once in the ESTABLISHED state all
segments must carry current acknowledgment information.

It should say:

When the sender creates a segment and transmits it the sender advances
SND.NXT.  When the receiver accepts a segment it advances RCV.NXT and
sends an acknowledgment.  When the data sender receives an
acknowledgment it advances SND.UNA.  The extent to which the values of
these variables differ is a measure of the delay in the communication.
The amount by which the variables are advanced is the length of the
data and SYN or FIN flags in the segment.  Note that
once in the ESTABLISHED state all segments must carry current acknowledgment information.

Notes:

SYN and FIN are counted, too

Errata ID: 1572
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Verifier Name: Wes Eddy
Date Verified: 2011-08-13

Section 3.4 says:

If the incoming segment has an ACK field, the reset takes its
sequence number from the ACK field of the segment, otherwise the
reset has sequence number zero and the ACK field is set to the sum
of the sequence number and segment length of the incoming segment.

It should say:

If the incoming segment has the ACK bit set, the reset takes its
sequence number from the ACK field of the segment, otherwise the
reset has sequence number zero and the ACK field is set to the sum
of the sequence number and segment length of the incoming segment.

Notes:

Every segment has an ACK field.

Errata ID: 572
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: "Yin Shuming"
Date Reported: 2006-02-18

Section 2.1 says:

The format of data blocks exchanged within the a network will generally not 
be of concern to us.

It should say:

The format of data blocks exchanged within the network will generally not 
be of concern to us.

Notes:

from pending

Errata ID: 574
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yin Shuming
Date Reported: 2005-05-22

In Section 3.7, page 43, it says:

                     If the the user signals a push function then the
      data must be sent even if it is a small segment.

It should say:

                     If the user signals a push function then the
      data must be sent even if it is a small segment.

Errata ID: 575
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Morris M. Keesan
Date Reported: 2003-10-29

Section 2.7 says:

    If there are several pending passive OPENs (recorded in TCBs) with the
    same local socket, an foreign active OPEN ...

It should say:

    If there are several pending passive OPENs (recorded in TCBs) with
    the same local socket, a foreign active OPEN ...

Errata ID: 700
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: "Yin Shuming"
Date Reported: 2006-02-18

Section 3.7 says:

One procedure for determining a retransmission time out is given here as an 
illustration.

It should say:

One procedure for determining a retransmission timeout is given here as an 
illustration.

Notes:

from pending

Errata ID: 701
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: "Yin Shuming"
Date Reported: 2006-02-18

Section 3.8 says:

since it will be specified in detail by the specification of the lowel 
level protocol.

It should say:

since it will be specified in detail by the specification of the lower 
level protocol.

Notes:

from pending

Errata ID: 1283
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Pei-chun Cheng
Date Reported: 2008-01-14
Verifier Name: Lars Eggert
Date Verified: 2009-02-16

Section 3.3 says:

 One way to deal with this problem is to deliberately delay emitting
    segments for one MSL after recovery from a crash- this is the "quite
    time" specification.  Hosts which prefer to avoid waiting are
    willing to risk possible confusion of old and new packets at a given
    destination may choose not to wait for the "quite time".
    Implementors may provide TCP users with the ability to select on a
    connection by connection basis whether to wait after a crash, or may
    informally implement the "quite time" for all connections.
    Obviously, even where a user selects to "wait," this is not
    necessary after the host has been "up" for at least MSL seconds.

It should say:

 One way to deal with this problem is to deliberately delay emitting
    segments for one MSL after recovery from a crash- this is the "quiet
    time" specification.  Hosts which prefer to avoid waiting are
    willing to risk possible confusion of old and new packets at a given
    destination may choose not to wait for the "quiet time".
    Implementors may provide TCP users with the ability to select on a
    connection by connection basis whether to wait after a crash, or may
    informally implement the "quiet time" for all connections.
    Obviously, even where a user selects to "wait," this is not
    necessary after the host has been "up" for at least MSL seconds.

Notes:

"quite time" should be "quiet time"

Errata ID: 6775
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eugene Adell
Date Reported: 2021-12-05
Verifier Name: RFC Editor
Date Verified: 2021-12-06

Section 3.3 says:

  Note that when the receive window is zero no segments should be
  acceptable except ACK segments.  Thus, it is be possible for a TCP to
  maintain a zero receive window while transmitting data and receiving
  ACKs.  However, even when the receive window is zero, a TCP must
  process the RST and URG fields of all incoming segments.

It should say:

  Note that when the receive window is zero no segments should be
  acceptable except ACK segments.  Thus, it is possible for a TCP to
  maintain a zero receive window while transmitting data and receiving
  ACKs.  However, even when the receive window is zero, a TCP must
  process the RST and URG fields of all incoming segments.

Notes:

s/it is be/it is/

RFC 804, "CCITT draft recommendation T.4", January 1981

Source of RFC: Legacy

Errata ID: 1769
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Klensin
Date Reported: 2009-04-29
Verifier Name: ron bonica
Date Verified: 2010-05-11

Section Index says:

CCITT draft recommendation T.4. International Telegraph and
Telephone Consultative Committee of the International
Telecommunication Union. January 1981.  (Format: TXT=17025 bytes)
(Status: UNKNOWN)

It should say:

CCITT draft recommendation T.4. International Telegraph and
Telephone Consultative Committee of the International
Telecommunication Union. January 1981.  (Format: TXT=17025 bytes)
(Status: Obsoleted by ITU Recommendation T.4: Standardization of Group 3 facsimile terminals for document transmission.  Available from ITU website
(http://www.itu.int/) by searching for ITU-T Recommendations, T-series, 
T.4.)

Notes:

This document is not online. Even if one could find a copy and scan it, doing so would probably violate various ITU copyrights and, because it was a draft version, relevant agreements. The changes above provide the reader with a real title for the document and pointers to current and earlier published versions.
The actual URL for the information on this document (including links to download the various versions) is http://www.itu.int/rec/T-REC-T.4/en, but the above search instructions are long-term stable while the URL may not be.

RFC 822, "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES", August 1982

Note: This RFC has been obsoleted by RFC 2822

Note: This RFC has been updated by RFC 1123, RFC 2156, RFC 1327, RFC 1138, RFC 1148

Source of RFC: Legacy
Area Assignment: app

Errata ID: 1899
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Wolf Lammen
Date Reported: 2009-10-02
Verifier Name: Pete Resnick
Date Verified: 2011-05-16

Section 3.1.4 says:

                    :sysmail              quoted string
                    @                     special
                    Some-Group            atom
                    .                     special
                    Some-Org              atom
                    ,                     special
                    Muhammed              atom
                    .                     special
                    (I am  the greatest)  comment
                    Ali                   atom
                    @                     atom
                    (the)                 comment
                    Vegas                 atom
                    .                     special
                    WBA                   atom

It should say:

                    ":sysmail"            quoted string
                    @                     special
                    Some-Group            atom
                    .                     special
                    Some-Org              atom
                    ,                     special
                    Muhammed              atom
                    .                     special
                    (I am  the greatest)  comment
                    Ali                   atom
                    @                     special
                    (the)                 comment
                    Vegas                 atom
                    .                     special
                    WBA                   atom

RFC 864, "Character Generator Protocol", May 1983

Source of RFC: Legacy

Errata ID: 4920
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jim Young
Date Reported: 2017-01-29
Verifier Name: John Scudder
Date Verified: 2024-01-12

Section TCP Based says:

   It is fairly likely that users of this service will abruptly decide
   that they have had enough and abort the TCP connection, instead of
   carefully closing it.  The service should be prepared for either the
   carfull close or the rude abort.

It should say:

   It is fairly likely that users of this service will abruptly decide
   that they have had enough and abort the TCP connection, instead of
   carefully closing it.  The service should be prepared for either the
   careful close or the rude abort.

Notes:

Spelling of "carfull" for "careful".

Errata ID: 6714
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Edwin Balani
Date Reported: 2021-10-17
Verifier Name: RFC Editor
Date Verified: 2022-01-27

Section Data Syntax says:

   The data may be anything.  It is recommended that a recognizable
   pattern be used in tha data.

      One popular pattern is 72 chraracter lines of the ASCII printing
      characters.

It should say:

   The data may be anything.  It is recommended that a recognizable
   pattern be used in the data.

      One popular pattern is 72 character lines of the ASCII printing
      characters.

Notes:

Minor spelling errors: "the" and "character"

RFC 865, "Quote of the Day Protocol", May 1983

Source of RFC: Legacy

Errata ID: 6713
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Edwin Balani
Date Reported: 2021-10-17
Verifier Name: Eric Vyncke
Date Verified: 2024-01-12

Throughout the document, when it says:

TCP Based Character Generator Service
[and]
UDP Based Character Generator Service

It should say:

TCP Based Quote of the Day Service
[and]
UDP Based Quote of the Day Service

Notes:

RFC 865 was probably written by taking RFC 864 (for the chargen protocol) and replacing "Character Generator" with "Quote of the Day", but these two section titles were missed.

RFC 868, "Time Protocol", May 1983

Source of RFC: Legacy

Errata ID: 2528
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2010-09-20
Verifier Name: ron bonica
Date Verified: 2011-10-12

Section No section says:

and -1,297,728,000 corresponds to 00:00 17 Nov 1858 GMT.

It should say:

and -1,297,728,000 (value which would be illegal for this protocol) corresponds to 00:00 17 Nov 1858 GMT.

Notes:

Although it is not explicit in the RFC, the 32-bits value is unsigned (otherwise, it could not end in 2036, as the RFC says). So, a negative value is not possible.

RFC 879, "The TCP Maximum Segment Size and Related Topics", November 1983

Note: This RFC has been obsoleted by RFC 7805, RFC 9293

Note: This RFC has been updated by RFC 6691

Source of RFC: Legacy
Area Assignment: tsv

Errata ID: 4053
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Susumu Endoh
Date Reported: 2014-07-17
Verifier Name: Martin Stiemerling
Date Verified: 2015-12-16

Section 14 says:

For example, if the IP Security option (11 octets) were in use and
the IP maximum datagram size remained at 576 octets, then the TCP
should send the MSS with a value of 525 (536-11).

It should say:

For example, if the IP Security option (11 octets) were in use and
the IP maximum datagram size remained at 576 octets, then the TCP
should send the MSS with a value of 524 (536-11-1).

Notes:

IP and TCP header must be multiple of 4 octets.

A side note: The value 11 for the IP security option is apparently copied from RFC 791 without considering that a padding to 32 bit word boundaries is required.

Errata ID: 7168
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christophe Deleuze
Date Reported: 2022-10-15
Verifier Name: RFC Editor
Date Verified: 2022-10-17

Section 6 says:

         For some networks the the directly attached network address can

It should say:

         For some networks the directly attached network address can

Notes:

Duplicated word.

RFC 889, "Internet Delay Experiments", December 1983

Source of RFC: Legacy

Errata ID: 7770
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Greg Skinner
Date Reported: 2024-01-20
Verifier Name: RFC Editor
Date Verified: 2024-01-22

Section 3 says:

     One of the basic features of TCP which allow it to be used on paths
spanning many nets of widely varying delay and packet-loss characteristics is
the retranansmission-timeout algorithm, sometimes known as the "RSRE
Algorithm" for the original designers.  The algorithm operates by recording
the time and initial sequence number when a segment is transmitted, then
computing the elapsed time for that sequence number to be acknowledged.  There
are various degrees of sophistication in the implementation of the algorithm,
ranging from allowing only one such computation to be in progress at a time to
allowing one for each segment outstanding at a time on the connection.

     The retransmission-timeout algorithm is basically an estimation process.
It maintains an extimate of the current roundtrip delay time and updates it as
new delay samples are computed.  The algorithm smooths these samples and then
establishes a timeout, which if exceeded causes a retransmission.  The
selection of the parameters of this algorithm are vitally important in order
to provide effective data transmission and avoid abuse of the Internet system
by excessive retransmissions.  I have long been suspicious of the parameters
suggested in the specification and used in some implementations, especially in
cases involving long-delay paths involving lossy nets.  The experiment was
designed to simulate the operation of the algorithm using data collected from
real paths involving some pretty leaky Internet plumbing.

It should say:

     One of the basic features of TCP which allows it to be used on paths
spanning many nets of widely varying delay and packet-loss characteristics is
the retranansmission-timeout algorithm, sometimes known as the "RSRE
Algorithm" by the original designers.  The algorithm operates by recording
the time and initial sequence number when a segment is transmitted, then
computing the elapsed time for that sequence number to be acknowledged.  There
are various degrees of sophistication in the implementation of the algorithm,
ranging from allowing only one such computation to be in progress at a time to
allowing one for each segment outstanding at a time on the connection.
     
     The retransmission-timeout algorithm is basically an estimation process.
It maintains an estimate of the current roundtrip delay time and updates it as
new delay samples are computed.  The algorithm smooths these samples and then
establishes a timeout, which if exceeded causes a retransmission.  The
selection of the parameters of this algorithm are vitally important in order
to provide effective data transmission and avoid abuse of the Internet system
by excessive retransmissions.  I have long been suspicious of the parameters
suggested in the specification and used in some implementations, especially in
cases involving long-delay paths involving lossy nets.  The experiment was
designed to simulate the operation of the algorithm using data collected from
real paths involving some pretty leaky Internet plumbing.

Notes:

The first paragraph contains grammatical errors. The second contains a spelling error.

--RFC Editor notes: --
first sentence in first paragraph: allow > allows
first sentence in first paragraph: for > by
first sentence in second paragraph: extimate > estimate

RFC 894, "A Standard for the Transmission of IP Datagrams over Ethernet Networks", April 1984

Source of RFC: Legacy

Errata ID: 570
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Gerald Park
Date Reported: 2001-03-28

In Section Frame Format:

   The minimum length of the data field of a packet sent over an
   Ethernet is 1500 octets, thus the maximum length of an IP datagram
   sent over an Ethernet is 1500 octets.

It should say:

   The maximum length of the data field of a packet sent over an
   Ethernet is 1500 octets, thus the maximum length of an IP datagram
   sent over an Ethernet is 1500 octets.

Errata ID: 5141
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Orestes Leal Rodriguez
Date Reported: 2017-10-04
Verifier Name: John Scudder
Date Verified: 2024-01-12

Throughout the document, when it says:

The minimum length of the data field of a packet sent
over an Ethernet is 1500 octets, thus the maximum 
length of an IP datagram sent over an Ethernet is 
1500 octets

It should say:

The maximum length of the data field of a packet sent
over an Ethernet is 1500 octets, thus the maximum 
length of an IP datagram sent over an Ethernet is 
1500 octets

RFC 916, "Reliable Asynchronous Transfer Protocol (RATP)", October 1984

Source of RFC: Legacy

Errata ID: 7320
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jules Maselbas
Date Reported: 2023-01-25
Verifier Name: RFC Editor
Date Verified: 2023-01-26

Section 3.3 says:

Side A                                             Side

It should say:

Side A                                             Side B

Notes:

The figure in the section 3.3. "Detecting a Half-Open Connection", has one side missing its letter here B.

RFC 918, "Post Office Protocol", October 1984

Note: This RFC has been obsoleted by RFC 937

Source of RFC: Legacy

Errata ID: 7615
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben van Hartingsveldt
Date Reported: 2023-08-24
Verifier Name: RFC Editor
Date Verified: 2023-08-25

Section Diagram says:

RECV

It should say:

RCEV

Notes:

The "RECV" in the Diagram section should be changed to "RCEV". The "RECV" is only used one time, where "RCEV" is used 6 times.

RFC 952, "DoD Internet host table specification", October 1985

Note: This RFC has been updated by RFC 1123

Source of RFC: Legacy

Errata ID: 3584
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Matthew Gast
Date Reported: 2013-04-08
Verifier Name: Ted Lemon
Date Verified: 2013-04-08

In the header, it says:

(none)

It should say:

Updates: RFC 952

Notes:

The text of RFC 1123 clearly states is updating RFC 952, but it is not called out as updating RFC 952.

RFC 1123 section 2.1 states:

"The syntax of a legal Internet host name was specified in RFC-952 [DNS:4]. One aspect of host name syntax is hereby changed: the restriction on the first character is relaxed to allow either a letter or a digit. Host software MUST support this more liberal syntax."

RFC 957, "Experiments in network clock synchronization", September 1985

Source of RFC: Legacy

Errata ID: 6870
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jim Young
Date Reported: 2022-03-07
Verifier Name: RFC Editor
Date Verified: 2022-03-07

Section 4.3.1. says:

...
re-establish correct time upon rejoining the grrd. In the much more
...

It should say:

...
re-establish correct time upon rejoining the grid. In the much more
...

Notes:

The word grid is misspelled as grrd.

RFC 959, "File Transfer Protocol", October 1985

Note: This RFC has been updated by RFC 2228, RFC 2640, RFC 2773, RFC 3659, RFC 5797, RFC 7151

Source of RFC: Legacy
Area Assignment: app

Errata ID: 568
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Juan Li
Date Reported: 2001-01-03

Section 2.1 says:

   The use of a "Set Data Type" transaction was proposed in RFC 294 in
   January 1982. 

It should say:

   The use of a "Set Data Type" transaction was proposed in RFC 294 in
   January 1972.

Errata ID: 3039
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Moutinho
Date Reported: 2011-12-01
Verifier Name: Pete Resnick
Date Verified: 2011-12-29

Section 5.3.2 says:

<number> ::= any decimal integer 1 through 255

It should say:

<number> ::= any decimal integer 0 through 255

Notes:

if 0 is not allowed, one cannot even represent 127.0.0.1 with
<host-number> ::= <number>,<number>,<number>,<number>

[Verifier Note: This does allow syntactically for nonsense values for <byte-size>, <port-number>, and <host-number>, but this was also true in the current syntax.]

Errata ID: 4869
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Megan Ruggiero
Date Reported: 2016-11-21
Verifier Name: Barry Leiba
Date Verified: 2021-03-07

Section 5.4 says:

               CDUP
                  200
                  500, 501, 502, 421, 530, 550

It should say:

               CDUP
                  250
                  500, 501, 502, 421, 530, 550

Notes:

The reply codes for CDUP are supposed to be identical to those of CWD according to Appendix II - Reply Codes. Thus, the proper return code for a successful CDUP should be 250 - Requested file action okay, not 200 - Command okay.

Errata ID: 5451
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: David LAMBERT
Date Reported: 2018-08-03
Verifier Name: Barry Leiba
Date Verified: 2021-03-07

Section APPENDIX II says:

         CWD /usr/dm
         200 directory changed to /usr/dm

...
         CWD overrainbow
         431 No such directory

It should say:

         CWD /usr/dm
         250 directory changed to /usr/dm

...
         CWD overrainbow
         550 No such directory

Notes:

Reply codes in the examples are not conform to the specification :
200 is not a valid code for CWD. It should be 250 (Requested file action okay, completed).
431 is not a valid code for CWD and is not defined in the RFC. It should be 550 (Requested file action not taken).

Errata ID: 2410
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Anthony Bryan
Date Reported: 2010-08-03
Verifier Name: Alexey Melnikov
Date Verified: 2010-08-03

Section Appendix III says:

   Mankins, David, Dan Franklin, and Buzz Owen, "Directory Oriented FTP
   Commands", RFC 776, BBN, December 1980.

It should say:

   Mankins, David, Dan Franklin, and Buzz Owen, "Directory Oriented FTP
   Commands", RFC 775, BBN, December 1980.

Notes:

Typo.
RFC 775 "Directory Oriented FTP Commands"
RFC 776 "Assigned Numbers"

Errata ID: 2024
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Klensin
Date Reported: 2010-01-27
Verifier Name: Alexey Melnikov
Date Verified: 2010-02-10

Section 4.1.3 says:

In the description of the SYST command, the second sentence reads:

"The reply shall have as its first
word one of the system names listed in the current version
of the Assigned Numbers document [4]."

Where [4] points to the then-current RFC 943.

It should say:

The reply shall have as its first
word one of the system names listed in the current version
of the IANA "Operating System Names" Registry (<http://www.iana.org/assignments/operating-system-names> at
the time of this writing)

Notes:

RFC 943 was several times obsolete by the time the community discontinued regular updates to the "Assigned Numbers" RFCs (see RFC 3232, January 2002). The clear intent was that SYST be able to use operating system names from that registry. An erratum pointing to the registry itself may aid the confused as well as providing better tracking and serving as placeholder in case RFC 959 is ever updated.

Errata ID: 4138
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eugene Adell
Date Reported: 2014-10-21
Verifier Name: Barry Leiba
Date Verified: 2014-11-27

Section 2.1 says:

      This current edition of the FTP specification is intended to
      correct some minor documentation errors, to improve the
      explanation of some protocol features, and to add some new
      optional commands.

      In particular, the following new optional commands are included in
      this edition of the specification:

         CDUP - Change to Parent Directory

         SMNT - Structure Mount

         STOU - Store Unique

         RMD - Remove Directory

         MKD - Make Directory

         PWD - Print Directory

         SYST - System

      This specification is compatible with the previous edition.  A
      program implemented in conformance to the previous specification
      should automatically be in conformance to this specification.

It should say:

      This current edition of the FTP specification is intended to
      correct some minor documentation errors, to improve the
      explanation of some protocol features, to add some new
      optional commands, and to remove obsolete ones.

      In particular, the following new optional commands are included in
      this edition of the specification:

         CDUP - Change to Parent Directory

         SMNT - Structure Mount

         STOU - Store Unique

         RMD - Remove Directory

         MKD - Make Directory

         PWD - Print Directory

         SYST - System

      All commands for the mail service are now obsolete and removed
      from this FTP specification. These commands are MLFL, MAIL,
      MSND, MSOM, MSAM, MRSQ, MRCP.  The return codes used for the
      mail service are also removed: 151, 152, 354.  Return code 215
      is reassigned here to another use.

      This specification is compatible with the previous edition.  A
      program implemented in conformance to the previous specification
      should automatically be in conformance to this specification, as
      long as it does not use the obsolete commands.

Notes:

Before claiming the specification is compliant with the previous version, noting what is added is not enough; we need to note what was removed also.

Errata ID: 6455
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2021-03-07
Verifier Name: Barry Leiba
Date Verified: 2021-03-07

Section 2.3 says:

         Ease of implementaion, sharing code, and modular programming
         argue for the second approach.

It should say:

         Ease of implementation, sharing code, and modular programming
         argue for the second approach.

Notes:

Typo.

Errata ID: 6456
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2021-03-07
Verifier Name: Barry Leiba
Date Verified: 2021-03-07

Section 2.1 says:

      RFC 354 obsoleted RFCs 264 and 265.  The File Transfer Protocol
      was now defined as a protocol for file transfer between HOSTs on
      the ARPANET, with the primary function of FTP defined as
      transfering files efficiently and reliably among hosts and
      allowing the convenient use of remote file storage capabilities.

It should say:

      RFC 354 obsoleted RFCs 264 and 265.  The File Transfer Protocol
      was now defined as a protocol for file transfer between HOSTs on
      the ARPANET, with the primary function of FTP defined as
      transferring files efficiently and reliably among hosts and
      allowing the convenient use of remote file storage capabilities.

Notes:

Misspelled "transferring".

Errata ID: 6457
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2021-03-07
Verifier Name: Barry Leiba
Date Verified: 2021-03-07

Section 3.3 says:

      Reuse of the Data Connection:  When using the stream mode of data
      transfer the end of the file must be indicated by closing the
      connection.  This causes a problem if multiple files are to be
      transfered in the session, due to need for TCP to hold the
      connection record for a time out period to guarantee the reliable
      communication.  Thus the connection can not be reopened at once.

It should say:

      Reuse of the Data Connection:  When using the stream mode of data
      transfer the end of the file must be indicated by closing the
      connection.  This causes a problem if multiple files are to be
      transferred in the session, due to need for TCP to hold the
      connection record for a time out period to guarantee the reliable
      communication.  Thus the connection can not be reopened at once.

Notes:

Misspelled "transferred".

RFC 994, "Final text of DIS 8473, Protocol for Providing the Connectionless-mode Network Service", March 1986

Source of RFC: Legacy
Area Assignment: int

Errata ID: 4208
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jean-Baptiste Cayrou
Date Reported: 2014-12-24
Verifier Name: Brian Haberman
Date Verified: 2015-03-09

Section 7.5.4 says:

7.5.4    Source Routing

   The source routing parameter specifies, either completely or partial-
   ly, the route to be taken from Source Network Address to Destination
   Network Address.

   Parameter Code:        1100 0101

It should say:

7.5.4    Source Routing

   The source routing parameter specifies, either completely or partial-
   ly, the route to be taken from Source Network Address to Destination
   Network Address.

   Parameter Code:        1100 1000

Notes:

The Source Routing (7.5.4) and the Security (7.5.3) options have the same parameter code.
See RFC926 7.5.4 for the correction.

RFC 1001, "Protocol standard for a NetBIOS service on a TCP/UDP transport: Concepts and methods", March 1987

Source of RFC: Legacy

Errata ID: 5209
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Brian
Date Reported: 2017-12-16
Verifier Name: John Scudder
Date Verified: 2024-01-12

Section 14 says:

FEGHGFCAEOGFHEECEJEPFDCAHEGBGNGF

It should say:

FEGIGFCAEOGFHEECEJEPFDCAGOGBGNGF

Notes:

I notice the same issue that Anvish received. I did not find the corrected answer anywhere after doing a few searches.

Verifier note: this checks out, but doesn’t rise to the level of a technical erratum as defined in https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/ so I’ve verified it as editorial.

RFC 1006, "ISO Transport Service on top of the TCP Version: 3", May 1987

Note: This RFC has been updated by RFC 2126

Source of RFC: Legacy

Errata ID: 7890
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Fabian Maier
Date Reported: 2024-04-12
Verifier Name: RFC Editor
Date Verified: 2024-04-12

Section 7 says:

TP0 is is meant to run over a reliable network service

It should say:

TP0 is meant to run over a reliable network service

Notes:

There is one 'is' too many

RFC 1034, "Domain names - concepts and facilities", November 1987

Note: This RFC has been updated by RFC 1101, RFC 1183, RFC 1348, RFC 1876, RFC 1982, RFC 2065, RFC 2181, RFC 2308, RFC 2535, RFC 4033, RFC 4034, RFC 4035, RFC 4343, RFC 4035, RFC 4592, RFC 5936, RFC 8020, RFC 8482, RFC 8767, RFC 9471

Source of RFC: Legacy
Area Assignment: int

Errata ID: 564
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Chlisin
Date Reported: 2003-02-06

Section 3.3 says:

   The usual mail address <local-part>@<mail-domain> is mapped into a
   domain name by converting <local-part> into a single label
   (regardles of dots it contains), converting <mail-domain> into a
   domain name using the usual text format for domain names (dots
   denote label breaks), and concatenating the two to form a single
   domain name. 

It should say:

   The usual mail address <local-part>@<mail-domain> is mapped into a
   domain name by converting <local-part> into a single label
   (regardless of dots it contains), converting <mail-domain> into a
   domain name using the usual text format for domain names (dots
   denote label breaks), and concatenating the two to form a single
   domain name.

Errata ID: 4740
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Robert Edmonds
Date Reported: 2016-07-11
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2018-04-01

Section 4.3.2 says:

   6. Using local data only, attempt to add other RRs which may be
      useful to the additional section of the query.  Exit.

It should say:

   6. Using local data only, attempt to add other RRs which may be
      useful to the additional section of the response.  Exit.

Notes:

Changed "query" to "response".

Section 4.3.2 describes the algorithm used by nameservers to answer queries. I.e., a nameserver receives a query from a client, and then it performs this algorithm in order to construct a response to send to the client.

Steps 1, 3, and 5 of this algorithm talk about setting fields or bits in the response, or about adding resource records to the answer section of the response, but then step 6 says to add resource records to the additional section of the *query*. This doesn't make any sense, because the server is constructing a response to a query that it's already received. "Response" must have been intended instead.

Errata ID: 565
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: "Yin Shuming"
Date Reported: 2006-02-18

Section 4.3.1 says:

This bit specifies specifies whether the requester wants recursive service 
for this query. Clients may.....

It should say:

This bit specifies whether the requester wants recursive service for this 
query. Clients may.....

Errata ID: 1074
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Kristoff
Date Reported: 2006-03-13

 

Section 2.2. says:

  - Where there tradeoffs between the cost of acquiring data, the

but should probably say:

  - Where there are tradeoffs between the cost of acquiring data, the

Section 3.6.2. says:

  For example, suppose a name server was processing a query with for

but should probably simply say:

  For example, suppose a name server was processing a query for

Section 4.3.4. misspells 'because':

  This feature can be particularly important in a system which
  implements naming short shorts that use search lists beacuse

It should say:

[see above]

Notes:

from pending

Errata ID: 4943
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Shane Kerr
Date Reported: 2017-02-20
Verifier Name: Terry Manderson
Date Verified: 2017-03-01

Section 4.3.5. says:

it must assume that its copy of the zone is obsolete an discard it.

It should say:

it must assume that its copy of the zone is obsolete and discard it.

Notes:

Fix typo; "an" should be "and".

Errata ID: 6460
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2021-03-08
Verifier Name: Barry Leiba
Date Verified: 2021-03-08

Section 5.3 says:

than typical occurances.  This section outlines a recommended basic

It should say:

than typical occurrences.  This section outlines a recommended basic

Notes:

Misspelled "occurrences".

Errata ID: 6461
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2021-03-08
Verifier Name: Barry Leiba
Date Verified: 2021-03-08

Section 7 says:

                Networks",Communications of the ACM, October 1986,

It should say:

                Networks", Communications of the ACM, October 1986,

Notes:

Missing space.

Errata ID: 6462
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2021-03-08
Verifier Name: Barry Leiba
Date Verified: 2021-03-08

Section 7 says:

                Superceeded by this memo.

It should say:

                Superseded by this memo.

Notes:

Misspelled "superseded".

Errata ID: 7111
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stephan Garland
Date Reported: 2022-09-01
Verifier Name: RFC Editor
Date Verified: 2022-09-02

Throughout the document, when it says:

insure

It should say:

ensure

Notes:

Section 3.6.2 uses both ensure and insure to mean the same thing, which is to guarantee or make certain. Sections 4.1, 4.2.2, and 5.3.3 all use the insure form.

Generally, insure is used in the financial sense, with making certain being a secondary definition. At the very least, consistency in the same paragraph of 3.6.2 would be cleaner.

Errata ID: 7820
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Buehler
Date Reported: 2024-02-23
Verifier Name: RFC Editor
Date Verified: 2024-02-25

Section 3.7.1 says:

The QCLASS field may contain:

<any class>     matches just that class (e.g., IN, CH).

*               matches aLL RR classes.

It should say:

The QCLASS field may contain:

<any class>     matches just that class (e.g., IN, CH).

*               matches all RR classes.

Notes:

Manual inspection of each use of the terms RR and RRs did not reveal any additional incorrectly capitalized adjacent words.

aLL > all

RFC 1035, "Domain names - implementation and specification", November 1987

Note: This RFC has been updated by RFC 1101, RFC 1183, RFC 1348, RFC 1876, RFC 1982, RFC 1995, RFC 1996, RFC 2065, RFC 2136, RFC 2181, RFC 2137, RFC 2308, RFC 2535, RFC 2673, RFC 2845, RFC 3425, RFC 3658, RFC 4033, RFC 4034, RFC 4035, RFC 4343, RFC 5936, RFC 5966, RFC 6604, RFC 7766, RFC 8482, RFC 8490, RFC 8767

Source of RFC: Legacy
Area Assignment: int

Errata ID: 562
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: CFeng
Date Reported: 2003-02-09

Section 6.4.2 says:

                         +-----------------------------------------+
           Header        |         OPCODE=RESPONSE, ID=997         |
                         +-----------------------------------------+
          Question       |QTYPE=A, QCLASS=IN, QNAME=VENERA.ISI.EDU |
                         +-----------------------------------------+
           Answer        |  VENERA.ISI.EDU  A IN 10.1.0.52         |
                         +-----------------------------------------+
          Authority      |                 <empty>                 |
                         +-----------------------------------------+
         Additional      |                 <empty>                 |
                         +-----------------------------------------+

It should say:

                         +-----------------------------------------+
           Header        |      OPCODE=IQUERY, ID=997, QR=1        |
                         +-----------------------------------------+
          Question       |QTYPE=A, QCLASS=IN, QNAME=VENERA.ISI.EDU |
                         +-----------------------------------------+
           Answer        |  VENERA.ISI.EDU  A IN 10.1.0.52         |
                         +-----------------------------------------+
          Authority      |                 <empty>                 |
                         +-----------------------------------------+
         Additional      |                 <empty>                 |
                         +-----------------------------------------+

Notes:

There is an error in the Header line. It should be
"OPCODE=IQUERY, ID=997, QR=1" because the OPCODE does not have a
value of RESPONSE (see Section 4.1.1).

Errata ID: 2130
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexei A. Smekalkine
Date Reported: 2010-04-05
Verifier Name: Brian Haberman
Date Verified: 2012-04-26

Section 3.2.1 says:

TTL             a 32 bit signed integer that specifies the time interval
                that the resource record may be cached before the source
                of the information should again be consulted.  Zero
                values are interpreted to mean that the RR can only be
                used for the transaction in progress, and should not be
                cached.  For example, SOA records are always distributed
                with a zero TTL to prohibit caching.  Zero values can
                also be used for extremely volatile data.

It should say:

TTL             a 32 bit unsigned integer that specifies the time interval
                that the resource record may be cached before the source
                of the information should again be consulted.  Zero
                values are interpreted to mean that the RR can only be
                used for the transaction in progress, and should not be
                cached.  For example, SOA records are always distributed
                with a zero TTL to prohibit caching.  Zero values can
                also be used for extremely volatile data.

Notes:

Conflicting descriptions of the type of TTL field.

Section 3.2.1 says "a 32 bit signed integer" while section 4.1.3 says "a 32 bit unsigned integer".

Errata ID: 6601
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Patrick Ni
Date Reported: 2021-06-07
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2021-06-14

Section 7.1 says:

This timestamp uses the absolute time format previously discussed for RR storage in zones and caches

It should say:

This timestamp uses the absolute time format previously discussed for RR storage in caches

Notes:

In section 6.1.3. Time, it says "while data in the zone stays with constant TTL ... The RRs in zones use relative times; the refresh timers and cache data use absolute times"

Errata ID: 563
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Allan Edward Prentice
Date Reported: 2006-03-04
Verifier Name: Brian Haberman
Date Verified: 2012-04-26

Section 5.1 says:

Because these files are text files several special encodings are
necessary to allow arbitrary data to be loaded. In particular:

                of the root.

@               A free standing @ is used to denote the current origin.

It should say:

Because these files are text files several special encodings are
necessary to allow arbitrary data to be loaded. In particular:

@               A free standing @ is used to denote the current origin.

Notes:

"of the root." makes no sense here.

Errata ID: 5728
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Etan Wexler
Date Reported: 2019-05-21
Verifier Name: RFC Editor
Date Verified: 2019-06-03

Section 3.3.5 says:

See the definition of MX and [RFC-974] for details ofw
the new scheme.

It should say:

See the definition of MX and [RFC-974] for details of
the new scheme.

Notes:

ofw -> of

Errata ID: 6264
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Merlin Büge
Date Reported: 2020-08-24
Verifier Name: Eric Vyncke
Date Verified: 2023-08-03

Section 2.2 says:

amount of new network code which is required.  This scheme can also
allow a group of hosts can share a small number of caches rather than
maintaining a large number of separate caches, on the premise that the
centralized caches will have a higher hit ratio.  In either case,

It should say:

amount of new network code which is required.  This scheme can also
allow a group of hosts to share a small number of caches rather than
maintaining a large number of separate caches, on the premise that the
centralized caches will have a higher hit ratio.  In either case,

Notes:

[WK]: s/a group of hosts can share a/a group of hosts to share a/ (I had to use 'dif' to find the change. Commenting here to save others from same.
[EV] Indeed the s/can/to/ is a valid grammar correction.

Errata ID: 6463
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2021-03-08
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2021-03-08

Section 3.3.13 says:

reason for this provison is to allow future dynamic update facilities to

It should say:

reason for this provision is to allow future dynamic update facilities to

Notes:

Mistyped "provision".

Errata ID: 6464
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2021-03-08
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2021-03-08

Section 4.1.4 says:

Pointers can only be used for occurances of a domain name where the

It should say:

Pointers can only be used for occurrences of a domain name where the

Notes:

Misspelled "occurrences".

Errata ID: 6465
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2021-03-08
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2021-03-08

Section 8.2 says:

      This condition means the the mailbox was actually a mailing

It should say:

      This condition means that the mailbox was actually a mailing

Notes:

Doubling.

Errata ID: 6466
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2021-03-08
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2021-03-08

Section 9 says:

                Superceeded by this memo.

It should say:

                Superseded by this memo.

Notes:

Misspelled "superseded".

Errata ID: 7424
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Wolfgang Keller
Date Reported: 2023-04-15
Verifier Name: RFC Editor
Date Verified: 2023-04-26

Section 2.3.1. says:

The following syntax will result in fewer problems with many

applications that use domain names (e.g., mail, TELNET).

It should say:

The following syntax will result in fewer problems with many
applications that use domain names (e.g., mail, TELNET).

Notes:

In section "2.3.1. Preferred name syntax" of RFC 1035, there occures a double newline in the middle of a sentence. This double newline should be replaced by a single newline.

Errata ID: 7587
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Roj
Date Reported: 2023-08-02
Verifier Name: RFC Editor
Date Verified: 2023-08-02

Section 4.1.1 says:

ID              A 16 bit identifier assigned by the program that
                generates any kind of query.  This identifier is copied
                the corresponding reply and can be used by the requester
                to match up replies to outstanding queries.

It should say:

ID              A 16 bit identifier assigned by the program that
                generates any kind of query.  This identifier is copied
                to the corresponding reply and can be used by the
                requester to match up replies to outstanding queries.

Notes:

There’s a missing preposition.

RFC 1036, "Standard for interchange of USENET messages", December 1987

Note: This RFC has been obsoleted by RFC 5536, RFC 5537

Source of RFC: Legacy
Area Assignment: app

Errata ID: 561
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Florian Weimer
Date Reported: 2001-05-17

Section 2.1.4 says:

   If the message is submitted in response to another message (e.g.,
   is a follow-up) the default subject should begin with the four
   characters "Re:", and the "References" line is required.

It should say:

   If the message is submitted in response to another message (e.g.,
   is a follow-up) the default subject should begin with the four
   characters "Re: ", and the "References" line is required.

Errata ID: 1760
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Hans Bot
Date Reported: 2009-04-09
Verifier Name: Alexey Melnikov
Date Verified: 2010-09-02

Section 2.2.5 says:

    This command should generate a
    "Subject" line which is the same as the original message, except
    that if the original subject does not begin with "Re:" or "re:", the
    four characters "Re:" are inserted before the subject. 

It should say:

   This command should generate a 
   "Subject" line which is the same as the original message, except 
   that if the original subject does not begin with "Re: " or "re: ",
   the four characters "Re: " are inserted before the subject.

Notes:

Space has been omitted three times. Please compare with original text in RFC850 to confirm that the spaces should be there. (http://www.w3.org/Protocols/rfc850/rfc850.html)

Alexey: also see RFC 5322.

RFC 1065, "Structure and identification of management information for TCP/IP-based internets", August 1988

Note: This RFC has been obsoleted by RFC 1155

Source of RFC: Legacy
Area Assignment: ops

Errata ID: 2080
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vivek Gupta
Date Reported: 2010-03-19
Verifier Name: Dan Romascanu
Date Verified: 2010-11-02

Section 4.2 says:

Each such subject type is uniquely named by its OBJECT IDENTIFIER and 
also has a textual name,

It should say:

Each such object type is uniquely named by its OBJECT IDENTIFIER and 
also has a textual name,

Notes:

The word "subject" should be replaced by the word "object" in the referred context

RFC 1071, "Computing the Internet checksum", September 1988

Note: This RFC has been updated by RFC 1141

Source of RFC: Legacy
Area Assignment: int

Errata ID: 560
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tim Moors
Date Reported: 2004-04-05

Section 4.1 says:

        while( count > 1 )  {
           /*  This is the inner loop */
               sum += * (unsigned short) addr++;
               count -= 2;

It should say:

        while( count > 1 )  {
           /*  This is the inner loop */
               sum += * (unsigned short *) addr++;
               count -= 2;

Errata ID: 7711
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mohammed Amine CHAKIR
Date Reported: 2023-11-23
Verifier Name: RFC Editor
Date Verified: 2023-11-28

Section 3 says:

We now present explicit examples of calculating a simple 1's
complement sum on a 2's complement machine.  The examples show the
same sum calculated byte by bye, by 16-bits words in normal and
swapped order, and 32 bits at a time in 3 different orders.  All
numbers are in hex.

It should say:

We now present explicit examples of calculating a simple 1's
complement sum on a 2's complement machine.  The examples show the
same sum calculated byte by byte, by 16-bits words in normal and
swapped order, and 32 bits at a time in 3 different orders.  All
numbers are in hex.

Notes:

A small typo in line 3 in the second occurrence of the word 'byte'

RFC 1122, "Requirements for Internet Hosts - Communication Layers", October 1989

Note: This RFC has been updated by RFC 1349, RFC 4379, RFC 5884, RFC 6093, RFC 6298, RFC 6633, RFC 6864, RFC 8029, RFC 9293

Source of RFC: Legacy
Area Assignment: int

Errata ID: 559
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Grzegorz R. Gryczka
Date Reported: 2002-10-19

 

Section 1.1.3 incorrectly implies that all support protocols are 
at the Application layer.  In particular, it mentions that support 
protocol RARP (Reverse ARP), which is not an application-layer protocol.

Errata ID: 618
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bob Braden
Date Reported: 2007-10-25
Verifier Name: Bob Braden
Date Verified: 2007-11-12

Section 4.2.5 says:

  OPEN to broadcast/multicast IP Address         |4.2.3.14| | | | |x|
  Silently discard seg to bcast/mcast addr       |4.2.3.14|x| | | | |

It should say:

  OPEN to broadcast/multicast IP Address         |4.2.3.10| | | | |x|
  Silently discard seg to bcast/mcast addr       |4.2.3.10|x| | | | |

Errata ID: 4446
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marek Perny
Date Reported: 2015-08-16
Verifier Name: RFC Editor
Date Verified: 2015-08-18

Section 1.1.1 says:

         A host is generally said to be multihomed if it has more than
         one interface to the same or to different networks.  See
         Section 1.1.3 on "Terminology".

It should say:

         A host is generally said to be multihomed if it has more than
         one interface to the same or to different networks.  See
         Section 1.3.3 on "Terminology".

Notes:

"Section 1.1.3" should be "Section 1.3.3".

Errata ID: 6468
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2021-03-09
Verifier Name: Barry Leiba
Date Verified: 2021-03-10

Section 3.3.1.4 says:

                      acknowleged data must have been transmitted

It should say:

                      acknowledged data must have been transmitted

Notes:

Misspelled "acknowledged".

Errata ID: 6469
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2021-03-09
Verifier Name: Barry Leiba
Date Verified: 2021-03-10

Section 4.1.3.5 says:

            application layer (e.g, so that the application can later

It should say:

            application layer (e.g., so that the application can later

Notes:

Missing full stop.

Errata ID: 6470
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2021-03-09
Verifier Name: Barry Leiba
Date Verified: 2021-03-10

Section 4.2.3.4 says:

                 (1)  if a maximum-sized segment can be sent, i.e, if:

It should say:

                 (1)  if a maximum-sized segment can be sent, i.e., if:

Notes:

Missing full stop.

RFC 1123, "Requirements for Internet Hosts - Application and Support", October 1989

Note: This RFC has been updated by RFC 1349, RFC 2181, RFC 5321, RFC 5966, RFC 7766, RFC 9210

Source of RFC: Legacy

Errata ID: 558
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ben Harris
Date Reported: 2003-02-12

Section 2.5 says:

Host names of up to 635 characters |2.1 |x| | | | | 

It should say:

Host names of up to 63 characters |2.1 |x| | | | | 

Notes:

Section 2.1 says "Host software MUST handle host names of up to 63 characters" and doesn't mention the number 635 at all.

Errata ID: 584
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Harris
Date Reported: 2003-02-12

Section 7 says:

[TELNET:9] "Telnet End-Of-Record Option," J. Postel, RFC-855, December 1983. 

It should say:

[TELNET:9] "Telnet End-Of-Record Option," J. Postel, RFC-885, December 1983.

Notes:

RFC 855 is "Telnet Option Specifications"; RFC 885 is "Telnet end of record option".

Errata ID: 1354
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Klensin
Date Reported: 2008-03-08
Verifier Name: Lisa Dusseault
Date Verified: 2008-07-14

Section 2.1 says:

The syntax of a legal Internet host name was specified in RFC-952 [DNS:4].

It should say:

The syntax of a legal Internet host name was specified in RFC-952
[DNS:4] and reiterated in RFC-1034 Section 3.5 [DNS:1].

Notes:

This essentially trivial editorial change makes it slightly easier for
anyone (or any tool) that tracks changes and updates to host and domain
naming rules to identify the applicability of this section.

Errata ID: 5456
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: David LAMBERT
Date Reported: 2018-08-12
Verifier Name: Mirja Kühlewind
Date Verified: 2018-08-13

Section 4.1.2.5 says:

                 This is required because of the long delay after a TCP
                 connection is closed until its socket pair can be
                 reused, to allow multiple transfers during a single FTP
                 session.  Sending a port command can avoided if a
                 transfer mode other than stream is used, by leaving the
                 data transfer connection open between transfers.

It should say:

                 This is required because of the long delay after a TCP
                 connection is closed until its socket pair can be
                 reused, to allow multiple transfers during a single FTP
                 session.  Sending a port command can be avoided if a
                 transfer mode other than stream is used, by leaving the
                 data transfer connection open between transfers.

Notes:

The verb is missing in the last sentence.
"Sending a port command can avoided..."

Errata ID: 6474
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2021-03-11
Verifier Name: Benjamin Kaduk
Date Verified: 2021-03-16

Section 6.1.3.6 says:

                 on the the existence of a TXT or WKS RR in most
                 domains.

It should say:

                 on the existence of a TXT or WKS RR in most domains.

Notes:

Doubled word.

Errata ID: 6475
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2021-03-11
Verifier Name: Benjamin Kaduk
Date Verified: 2021-03-16

Section 3.2.1 says:

         option-negotiation loops.  A host MUST refuse (i.e, reply

It should say:

         option-negotiation loops.  A host MUST refuse (i.e., reply

Notes:

Missing full stop.

RFC 1150, "FYI on FYI: Introduction to the FYI Notes", March 1990

Note: This RFC has been obsoleted by RFC 6360

Source of RFC: Legacy

Errata ID: 3829
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marek Perny
Date Reported: 2013-12-09
Verifier Name: RFC Editor

Section 2 says:

The formost reason is that the distribution
   mechanisms for RFCs are tried and true.

It should say:

The foremost reason is that the distribution
   mechanisms for RFCs are tried and true.

Notes:

spelling error

RFC 1155, "Structure and identification of management information for TCP/IP-based internets", May 1990

Source of RFC: Legacy

Errata ID: 2601
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vivek Gupta
Date Reported: 2010-11-03
Verifier Name: Dan Romascanu
Date Verified: 2010-11-04

Section 4.2 says:

Each such subject type is uniquely named by its OBJECT IDENTIFIER

It should say:

Each such object type is uniquely named by its OBJECT IDENTIFIER

Notes:

The word "subject" should be replaced by the word "object" in the referred context

RFC 1158, "Management Information Base for network management of TCP/IP-based internets: MIB-II", May 1990

Note: This RFC has been obsoleted by RFC 1213

Source of RFC: Legacy

Errata ID: 557
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Vincent Berger
Date Reported: 2002-03-27

Section 5.4.2 says:

   egp(5),
   ggp(6),
   hello(7),
   rip(8),
   is-is(9),
   es-is(10),
   ciscoIgrp(11),
   bbnSpfIgp(12),
   ospf(13)
   bgp(14)

It should say:

   egp(5),
   ggp(6),
   hello(7),
   rip(8),
   is-is(9),
   es-is(10),
   ciscoIgrp(11),
   bbnSpfIgp(12),
   ospf(13),
   bgp(14)

RFC 1180, "TCP/IP tutorial", January 1991

Source of RFC: Legacy
Area Assignment: int

Errata ID: 556
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Chao Yel
Date Reported: 2000-02-28

 

In Section 5.10, Table 12 - Delta's Route Table: 

[Based on Figure 9] Network "factory" should correspond to Delta Interface #2;
Network "accounting" should correspond to Delta Interface #3.

Errata ID: 5074
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Erik Auerswald
Date Reported: 2017-07-29
Verifier Name: Éric Vyncke
Date Verified: 2024-01-12

Section 5.3 says:

When an incoming IP packet arrives it is never forwarded back out
through the same network interface.

It should say:

When an incoming IP packet arrives it may be forwarded back out
through the same network interface.

Notes:

IP routers can and do send IP packets out the ingress interface. An ICMP redirect message may be sent in this case.

This is different to Ethernet bridge behavior, where a frame will not be sent out the ingress interface.

An IP packet that egresses the ingress interface is carried in a new Ethernet frame, this is not the same frame that arrived at the ingress interface (different SRC and DST MAC addresses, decreased TTL in the IP header).

RFC 1258, "BSD Rlogin", September 1991

Note: This RFC has been obsoleted by RFC 1282

Source of RFC: Legacy

Errata ID: 2772
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-04-08
Verifier Name: ron bonica
Date Verified: 2011-10-12

Throughout the document, when it says:

Notes:

RFC 1258 is obsoleted by RFC 1282, that is clearly stated in the last document. However no such entry was added to RFC Editor database. It should be added once this errata report is verified.

RFC 1319, "The MD2 Message-Digest Algorithm", April 1992

Note: This RFC has been obsoleted by RFC 6149

Source of RFC: pem (sec)

Errata ID: 554
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jem Berkes
Date Reported: 2002-01-30

Section 3.1 says:

   Padding is performed as follows: "i" bytes of value "i" are appended
   to the message so that the length in bytes of the padded message
   becomes congruent to 0, modulo 16. At least one byte and at most 16
   16 bytes are appended.

It should say:

   Padding is performed as follows: "i" bytes of value "i" are appended
   to the message so that the length in bytes of the padded message
   becomes congruent to 0, modulo 16. At least one byte and at most 
   16 bytes are appended.

Errata ID: 555
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: David Hopwood
Date Reported: 2002-02-11

Section 3.2 says:

      ...
      /* Process each 16-word block. */
      For i = 0 to N/16-1 do

         /* Checksum block i. */
         For j = 0 to 15 do
            Set c to M[i*16+j].
            Set C[j] to S[c xor L].
            Set L to C[j].
          end /* of loop on j */
       end /* of loop on i */

   The 16-byte checksum C[0 ... 15] is appended to the message. Let
   M[0
   with checksum), where N' = N + 16.

It should say:

      ...
      /* Process each 16-word block. */
      For i = 0 to N/16-1 do

         /* Checksum block i. */
         For j = 0 to 15 do
            Set c to M[i*16+j].
            Set C[j] to C[j] xor S[c xor L].
            Set L to C[j].
          end /* of loop on j */
       end /* of loop on i */

   The 16-byte checksum C[0 ... 15] is appended to the (padded)
   message.
   Let M[0..N'-1] be the message with padding and checksum appended,
   where N' = N + 16.

Errata ID: 3575
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Andrew Clark
Date Reported: 2013-03-29
Verifier Name: Sean Turner
Date Verified: 2013-08-14

Section 3.2 says:

      Set L to 0.

      /* Process each 16-word block. */
      For i = 0 to N/16-1 do

         /* Checksum block i. */

It should say:

      Set L to 0.

      /* Process each 16-byte block. */
      For i = 0 to N/16-1 do

         /* Checksum block i. */

Notes:

The comment should note that this section of the algorithm operates on a 16 byte -- rather than 16 word -- block.

Errata ID: 3576
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Andrew Clark
Date Reported: 2013-03-29
Verifier Name: Sean Turner
Date Verified: 2013-08-14

Section 3.4 says:

   Do the following:

      /* Process each 16-word block. */
      For i = 0 to N'/16-1 do

It should say:

   Do the following:

      /* Process each 16-byte block. */
      For i = 0 to N'/16-1 do

Notes:

The comment should note that this section of the algorithm operates on a 16 byte -- rather than 16 word -- block.

RFC 1320, "The MD4 Message-Digest Algorithm", April 1992

Note: This RFC has been obsoleted by RFC 6150

Source of RFC: pem (sec)

Errata ID: 2163
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2010-04-16
Verifier Name: Tim Polk
Date Verified: 2010-04-19

Section A.4 says:

#ifndef MD
#define MD MD5
#endif

It should say:

#ifndef MD
#define MD 5
#endif

Errata ID: 2164
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2010-04-16
Verifier Name: Tim Polk
Date Verified: 2010-04-19

Section A.4 says:

  printf
    ("MD%d time trial. Digesting %d %d-byte blocks ...", MD,
     TEST_BLOCK_LEN, TEST_BLOCK_COUNT);

It should say:

  printf
    ("MD%d time trial. Digesting %d %d-byte blocks ...", MD,
     TEST_BLOCK_COUNT, TEST_BLOCK_LEN);

Errata ID: 6998
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alok Menghrajani
Date Reported: 2022-06-18
Verifier Name: RFC Editor
Date Verified: 2022-06-20

Section A.3 says:

/* MD4 finalization. Ends an MD4 message-digest operation, writing the
     the message digest and zeroizing the context.
 */

It should say:

/* MD4 finalization. Ends an MD4 message-digest operation, writing the
   message digest and zeroizing the context.
 */

Notes:

"the the" grammar mistake

RFC 1321, "The MD5 Message-Digest Algorithm", April 1992

Note: This RFC has been updated by RFC 6151

Source of RFC: pem (sec)

Errata ID: 550
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Matt Borland
Date Reported: 2001-01-19

In Section A.4:

   #define MD MD5

It should say:

   #define MD 5

Errata ID: 551
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Gregory Smith
Date Reported: 2002-06-14

Section 3.4 says:

   /* Round 3. */
   /* Let [abcd k s t] denote the operation
        a = b + ((a + H(b,c,d) + X[k] + T[i]) <<< s). */
   /* Do the following 16 operations. */

It should say:

   /* Round 3. */
   /* Let [abcd k s i] denote the operation
        a = b + ((a + H(b,c,d) + X[k] + T[i]) <<< s). */
   /* Do the following 16 operations. */

Errata ID: 552
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Amling
Date Reported: 2000-04-12

Section 3.4 says:

   the each bit of F(X,Y,Z) will be independent

It should say:

   then each bit of F(X,Y,Z) will be independent

Errata ID: 553
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Gennaro Prota
Date Reported: 2006-11-15
Verifier Name: Tim Polk
Date Verified: 2010-04-19

Appendix A says:

  printf
 ("MD%d time trial. Digesting %d %d-byte blocks ...", MD,
  TEST_BLOCK_LEN, TEST_BLOCK_COUNT);

It should say:

  printf
 ("MD%d time trial. Digesting %d %d-byte blocks ...", MD,
  TEST_BLOCK_COUNT, TEST_BLOCK_LEN);

Errata ID: 585
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Gregory Smith
Date Reported: 2002-06-14

Section 3.4 says:

/* Round 4. */
   /* Let [abcd k s t] denote the operation
        a = b + ((a + I(b,c,d) + X[k] + T[i]) <<< s). */

It should say:

/* Round 4. */
   /* Let [abcd k s i] denote the operation
        a = b + ((a + I(b,c,d) + X[k] + T[i]) <<< s). */

RFC 1332, "The PPP Internet Protocol Control Protocol (IPCP)", May 1992

Note: This RFC has been updated by RFC 3241

Source of RFC: pppext (int)

Errata ID: 7840
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christophe Deleuze
Date Reported: 2024-03-07
Verifier Name: RFC Editor
Date Verified: 2024-03-08

The References section says:

   [1]   Simpson, W., "The Point-to-Point Protocol", RFC 1331, May 1992.

   [2]   Postel, J., "Internet Protocol", RFC 791, USC/Information
         Sciences Institute, September 1981.

   [3]   Jacobson, V., "Compressing TCP/IP Headers", RFC 1144, January
         1990.

   [4]   Postel, J., "The TCP Maximum Segment Size Option and Related
         Topics", RFC 879, USC/Information Sciences Institute, November
         1983.

It should say:

   [1]   Simpson, W., "The Point-to-Point Protocol (PPP) for the
         Transmission of Multi-protocol Datagrams over Point-to-Point
         Links", RFC 1331, May 1992.

   [2]   Postel, J., "Internet Protocol", RFC 791, USC/Information
         Sciences Institute, September 1981.

   [3]   Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial
         Links", RFC 1144, February 1990.

   [4]   Postel, J., "The TCP Maximum Segment Size and Related Topics",
         RFC 879, USC/Information Sciences Institute, November 1983.

Notes:

In the references section, titles for [1], [3] and [4] are inexact. Publication month for [3] is incorrect as well.

RFC 1337, "TIME-WAIT Assassination Hazards in TCP", May 1992

Source of RFC: Legacy

Errata ID: 6782
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Christophe Deleuze
Date Reported: 2021-12-11
Verifier Name: Martin Duke
Date Verified: 2022-01-28

Section 2.4 says:

    3.         ... <SEQ=400><ACK=101><CTL=SYN,ACK><W=800>  <-- SYN-RCVD

    4.  SYN-SENT    <-- <SEQ=300><ACK=123><CTL=ACK> ... (old duplicate)

    5.  SYN-SENT    --> <SEQ=123><CTL=RST>                   --> LISTEN

    6.  ESTABLISHED <-- <SEQ=400><ACK=101><CTL=SYN,ACK><W=900> ...

[...]

      The key to the failure in Figure 4 is that the RST segment 5 is
      acceptable to TCP B in SYN-RECEIVED state, because the sequence
      space of the earlier connection that produced this old duplicate
      overlaps the new connection space.  Thus, <SEQ=123> in segment #5
      falls within TCP B's receive window [101,900).

It should say:

    3.         ... <SEQ=400><ACK=101><CTL=SYN,ACK><W=800>  <-- SYN-RCVD

    4.  SYN-SENT    <-- <SEQ=300><ACK=123><CTL=ACK> ... (old duplicate)

    5.  SYN-SENT    --> <SEQ=123><CTL=RST>                   --> LISTEN

    6.  ESTABLISHED <-- <SEQ=400><ACK=101><CTL=SYN,ACK><W=800> ...

[...]

      The key to the failure in Figure 4 is that the RST segment 5 is
      acceptable to TCP B in SYN-RECEIVED state, because the sequence
      space of the earlier connection that produced this old duplicate
      overlaps the new connection space.  Thus, <SEQ=123> in segment #5
      falls within TCP B's receive window [101,901).

Notes:

I see two problems here.

First, line 6 is the arrival of segment sent at line 3, so it should have the same advertised window.

Second, in the following paragraph it is said that B's receive window is [101,900), which is consistent neither with line 3 (W=800) nor line 6 (W=900).

I guess (that's just a guess) the author meant W=800 in both lines 3 and 6, and made an off-by-one error in B receive's window. If it starts at 101 and has 800 for size, it is [101,901)

Errata ID: 7149
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Tüxen
Date Reported: 2022-10-06
Verifier Name: RFC Editor
Date Verified: 2022-10-06

Section 2.2 says:

As a result, B sends segment 6, an ACK for sequence = 640, which
is 40 beyond any data sent by A.  Assume for the present that this
ACK arrives at A *after* A has sent segment 7a, the next full data
segment.  In that case, the ACK segment 8a acknowledges data that
has been sent, and the error goes undetected.  Another possible
continuation after segment 6 leads to hazard H3, shown below.

It should say:

As a result, B sends segment 6, an ACK for sequence = 640, which
is 40 beyond any data sent by A.  Assume for the present that this
ACK arrives at A *after* A has sent segment 7a, the next full data
segment.  In that case, the ACK segment 8a acknowledges data that
has been sent, and the error goes undetected.  Another possible
continuation after segment 6 leads to hazard H2, shown below.

Notes:

The forward reference in the last sentence should be H2, not H3.

Errata ID: 7745
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Garri Djavadyan
Date Reported: 2024-01-01
Verifier Name: RFC Editor
Date Verified: 2024-01-02

Section 3 says:

   (F3) Use 64-bit Sequence Numbers

        O'Malley and Peterson [RFC-1264] have suggested expansion of the
        TCP sequence space to 64 bits as an alternative to PAWS for
        avoiding the hazard of wrapped sequence numbers within the same
        incarnation.

It should say:

   (F3) Use 64-bit Sequence Numbers

        O'Malley and Peterson [RFC-1263] have suggested expansion of the
        TCP sequence space to 64 bits as an alternative to PAWS for
        avoiding the hazard of wrapped sequence numbers within the same
        incarnation.

Notes:

S. O'Malley and L. Peterson actually authored [RFC-1263] not [RFC-1264].

RFC 1340, "Assigned Numbers", July 1992

Note: This RFC has been obsoleted by RFC 1700

Source of RFC: Legacy
Area Assignment: gen

Errata ID: 549
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jean Delvare
Date Reported: 2002-07-08
Verifier Name: Russ Housley
Date Verified: 2010-08-19

On page 87, it says:

SUN OS 3.5
SUN OS 4.0

It should say:

SUN-OS-3.5
SUN-OS-4.0

Notes:

The white space isn't supposed to be accepted as part of a system name.

RFC 1345, "Character Mnemonics and Character Sets", June 1992

Source of RFC: 822ext (app)

Errata ID: 2683
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: -
Date Reported: 2011-01-10
Verifier Name: Pete Resnick
Date Verified: 2011-05-03

Section 3 says:

 N->    1e4a    LATIN CAPITAL LETTER N WITH CIRCUMFLEX BELOW
 N->    1e4b    LATIN SMALL LETTER N WITH CIRCUMFLEX BELOW

...

 S.-.   1e68    LATIN CAPITAL LETTER S WITH DOT BELOW AND DOT ABOVE
 S.-.   1e69    LATIN SMALL LETTER S WITH DOT BELOW AND DOT ABOVE

It should say:

 N->    1e4a    LATIN CAPITAL LETTER N WITH CIRCUMFLEX BELOW
 n->    1e4b    LATIN SMALL LETTER N WITH CIRCUMFLEX BELOW

...

 S.-.   1e68    LATIN CAPITAL LETTER S WITH DOT BELOW AND DOT ABOVE
 s.-.   1e69    LATIN SMALL LETTER S WITH DOT BELOW AND DOT ABOVE

Notes:

Mnemonics should be unique...

RFC 1349, "Type of Service in the Internet Protocol Suite", July 1992

Note: This RFC has been obsoleted by RFC 2474

Source of RFC: rreq (rtg)

Errata ID: 4456
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Anton
Date Reported: 2015-08-26
Verifier Name: Alvaro Retana
Date Verified: 2015-08-26

Section 7.1 says:

where type 1 entries result from the receipt of code 3 (or code 1)
Redirects and type 2 entries result from the receipt of code 2 (or
code 0) Redirects.

It should say:

where type 1 entries result from the receipt of code 3 (or code 2)
Redirects and type 2 entries result from the receipt of code 1 (or
code 0) Redirects.

Notes:

I think that original text has no sense, especially considering that routers MUST NOT send 0 and 2 Redirects, type 2 routing entries has no chance to occur. Sorry if I'm mistaking and not fully understand ideas behind RFC 1349
=====
(Alvaro Retana) The report and correction are valid. I did edit them for completeness.

RFC 1350, "The TFTP Protocol (Revision 2)", July 1992

Note: This RFC has been updated by RFC 1782, RFC 1783, RFC 1784, RFC 1785, RFC 2347, RFC 2348, RFC 2349

Source of RFC: Legacy
Area Assignment: app

Errata ID: 4971
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ondrej
Date Reported: 2017-03-15
Verifier Name: Barry Leiba
Date Verified: 2019-04-30

Section 6 says:

(i.e., Datagram length < 516)

It should say:

(i.e., Datagram length < 512)

RFC 1361, "Simple Network Time Protocol (SNTP)", August 1992

Note: This RFC has been obsoleted by RFC 1769

Source of RFC: Legacy
Area Assignment: int

Errata ID: 3905
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: J. Stals
Date Reported: 2014-02-18
Verifier Name: Brian Haberman
Date Verified: 2014-05-16

Section 4 says:

(original NTP described in RFC-959) messages are no longer supported.

It should say:

(original NTP described in RFC-958) messages are no longer supported.

Notes:

RFC959 is the FTP protocol, not NTP version 0 (RFC958). It should be noted that RFC 1361 is obsolete.

RFC 1413, "Identification Protocol", February 1993

Source of RFC: ident (sec)

Errata ID: 548
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tymon Rzes'niowiecki
Date Reported: 2004-08-17

Section 6 says:

   3)   The 512 character limit on user IDs and the 64
        character limit on tokens should be understood to mean
        as follows: a) No new token (i.e., OPSYS or ERROR-TYPE)
        token will be defined that has a length greater than 64

It should say:

   3)   The 512 character limit on user IDs and the 64
        character limit on tokens should be understood to mean
        as follows: a) No new token (i.e., OPSYS or ERROR-TYPE)
        will be defined that has a length greater than 64

RFC 1436, "The Internet Gopher Protocol (a distributed document search and retrieval protocol)", March 1993

Source of RFC: Legacy

Errata ID: 7551
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Csaba Csillingh
Date Reported: 2023-06-23
Verifier Name: RFC Editor
Date Verified: 2023-06-23

Section 3.1 says:

thus creating a customized view of thethe Gopher information universe;

It should say:

thus creating a customized view of the Gopher information universe;

Notes:

Typing error.

RFC 1438, "Internet Engineering Task Force Statements Of Boredom (SOBs)", April 1993

Source of RFC: INDEPENDENT

Errata ID: 4987
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2017-04-01
Verifier Name: Eric Vyncke
Date Verified: 2024-01-12

Throughout the document, when it says:

and the Academie Francais for review

It should say:

and the Academie Francaise for review

Notes:

Perfect day to file an erratum against this RFC

"Academie" is female so "francais" needs the final e.

[Also, it should be "Académie française" but I'll wait for the implementation of RFC 7997.]

-- Verifier note (EV) --

Indeed, it should be "Académie française" ;-)

RFC 1459, "Internet Relay Chat Protocol", May 1993

Note: This RFC has been updated by RFC 2810, RFC 2811, RFC 2812, RFC 2813, RFC 7194

Source of RFC: Legacy
Area Assignment: app

Errata ID: 4091
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Kovacs
Date Reported: 2014-08-23
Verifier Name: Barry Leiba
Date Verified: 2014-09-17

Section 2.3 says:

The presence of a prefix is indicated with a single leading ASCII
   colon character (':', 0x3b), which must be the first character of the
   message itself.

It should say:

The presence of a prefix is indicated with a single leading ASCII
   colon character (':', 0x3a), which must be the first character of the
   message itself.

Notes:

The ASCII colon character is represented by 0x3A, not 0x3B (which is the semicolon).

Errata ID: 4318
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lucas Satabin
Date Reported: 2015-03-31
Verifier Name: Barry Leiba
Date Verified: 2015-04-02

Section 1.3 says:

There are two types of channels allowed by this protocol.  One is a
distributed channel which is known to all the servers that are
connected to the network. These channels are marked by the first
character being a only clients on the server where it exists may join
it.  These are distinguished by a leading '&' character.

It should say:

There are two types of channels allowed by this protocol.  One is a
distributed channel, which is known to all the servers that are
connected to the network. These channels are marked by the first
character being a '#'.  The other type of channel is limited to one
server, and only clients on the server where it exists may join
it.  These channels are distinguished by a leading '&' character.

Notes:

There is a missing chunk of text between "being a" and "only clients".

RFC 1464, "Using the Domain Name System To Store Arbitrary String Attributes", May 1993

Source of RFC: Legacy

Errata ID: 5193
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Victor Toni
Date Reported: 2017-12-02
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2017-12-06

Section 2. says:

string2      `abc`           string2=``abc``         "string2=``abc``"

It should say:

string2      `abc`           string2=`abc`         "string2=`abc`"

Notes:

Quote:
--------------------------------------------
Attribute Values

All printable ASCII characters are permitted in the attribute value.
No characters need to be quoted with a "`". In other words, the
first unquoted equals sign in the TXT record is the name/value
delimiter. All subsequent characters are part of the value.

Once again, note that in most implementations the backslash character
is an active quoting character (and must, itself, be quoted).

--------------------------------------------

"All subsequent characters are part of the value." would indicate that the part of the string after the "=" character could be copied as one.
The accent grave shoud not be escaped within the value.

RFC 1498, "On the Naming and Binding of Network Destinations", August 1993

Source of RFC: Legacy

Errata ID: 5680
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Greg Skinner
Date Reported: 2019-03-30
Verifier Name: RFC Editor
Date Verified: 2019-05-16

Section "What is the Problem?" says:

To start with, let us review Shoch's suggested terminology in its
broadest form:

     -  a name identifies what you want,
     -  an address identifies where it is, and
     -  an route identifies a way to get there.

It should say:

To start with, let us review Shoch's suggested terminology in its
broadest form:

     -  a name identifies what you want,
     -  an address identifies where it is, and
     -  a route identifies a way to get there.

Notes:

Grammar mistake ("an router"). Also, see the text under the heading 'The General Model' in IEN 19.

RFC 1517, "Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR)", September 1993

Source of RFC: IESG ()

Errata ID: 547
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mr. Sharky
Date Reported: 2002-03-30

Section 1 says:

   It has become clear that the first two of these problems are likely
   to become critical in the near term.  Classless Inter-Domain
   Routing (CIDR) ttempts to deal with these problems by defining a
   mechanism to slow the growth of routing tables and reduce the need
   to allocate new IP network numbers.

It should say:

   It has become clear that the first two of these problems are likely
   to become critical in the near term.  Classless Inter-Domain
   Routing (CIDR) attempts to deal with these problems by defining a
   mechanism to slow the growth of routing tables and reduce the need
   to allocate new IP network numbers.

RFC 1519, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", September 1993

Note: This RFC has been obsoleted by RFC 4632

Source of RFC: Legacy
Area Assignment: rtg

Errata ID: 1823
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dande Rajasekhar
Date Reported: 2009-08-05
Verifier Name: Stewart Bryant
Date Verified: 2010-10-22

Section 1 says:

This plan is primarily directed at the first two problems listed
   above.  We believe that the judicious use of variable-length
   subnetting techniques should help defer the onset of the last problem
   problem, the exhaustion of the 32-bit address space. Note also that
   improved tools for performing address allocation in a "supernetted"
   and variably-subnetted world would greatly help the user community in
   accepting these sometimes confusing techniques. Efforts to create
   some simple tools for this purpose should be encouraged by the
   Internet community.

It should say:

This plan is primarily directed at the first two problems listed
   above.  We believe that the judicious use of variable-length
   subnetting techniques should help defer the onset of the last problem, 
   the exhaustion of the 32-bit address space. Note also that
   improved tools for performing address allocation in a "supernetted"
   and variably-subnetted world would greatly help the user community in
   accepting these sometimes confusing techniques. Efforts to create
   some simple tools for this purpose should be encouraged by the
   Internet community.

Notes:

In the phrase "the onset of the last problem problem," word problem appears twice.

Errata ID: 7581
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Delton Phillips
Date Reported: 2023-08-01
Verifier Name: RFC Editor
Date Verified: 2023-08-01

Section 1 says:

This plan is primarily directed at the first two problems listed
   above.  We believe that the judicious use of variable-length
   subnetting techniques should help defer the onset of the last problem
   problem, the exhaustion of the 32-bit address space. Note also that
   improved tools for performing address allocation in a "supernetted"
   and variably-subnetted world would greatly help the user community in
   accepting these sometimes confusing techniques. Efforts to create
   some simple tools for this purpose should be encouraged by the
   Internet community.

It should say:

This plan is primarily directed at the first two problems listed
   above.  We believe that the judicious use of variable-length
   subnetting techniques should help defer the onset of the last problem, 
   the exhaustion of the 32-bit address space. Note also that
   improved tools for performing address allocation in a "supernetted"
   and variably-subnetted world would greatly help the user community in
   accepting these sometimes confusing techniques. Efforts to create
   some simple tools for this purpose should be encouraged by the
   Internet community.

Notes:

In the phrase "the onset of the last problem problem," word problem appears twice.

RFC 1522, "MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text", September 1993

Note: This RFC has been obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049

Source of RFC: 822ext (app)

Errata ID: 5488
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eugene Adell
Date Reported: 2018-09-03
Verifier Name: Barry Leiba
Date Verified: 2019-04-30

Section 2 says:

   especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "
               <"> / "/" / "[" / "]" / "?" / "." / "="

It should say:

   especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / 
               <"> / "/" / "[" / "]" / "?" / "." / "="

Notes:

this double quote at the end of the line is a mistake

RFC 1524, "A User Agent Configuration Mechanism For Multimedia Mail Format Information", September 1993

Source of RFC: Legacy

Errata ID: 1755
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Samuel Bronson
Date Reported: 2009-04-03
Verifier Name: ron bonica
Date Verified: 2011-10-12

Section B says:

         # Mailcap file for Bellcore lab 214.
         #
         # The next line sends "richtext" to the richtext
         program
         text/richtext; richtext %s; copiousoutput
         #
         # Next, basic u-law audio
         audio/*; showaudio; test=/usr/local/bin/hasaudio
         #
         # Next, use the xview program to handle several image
         formats
         image/*; xview %s; test=/usr/local/bin/RunningX
         #
         # The ATOMICMAIL interpreter uses curses, so needs a
         terminal
         application/atomicmail; /usr/local/bin/atomicmail %s; \
             needsterminal
         #
         # The next line handles Andrew format,
         #   if ez and ezview are installed
         x-be2; /usr/andrew/bin/ezview %s; \
            print=/usr/andrew/bin/ezprint %s ; \
            compose=/usr/andrew/bin/ez -d %s \;
            edit=/usr/andrew/bin/ez -d %s; \;
            copiousoutput
         #
         # The next silly example demonstrates the use of
         quoting
         application/*; echo "This is \"%t\" but \
            is 50 \% Greek to me" \; cat %s; copiousoutput

It should say:

         # Mailcap file for Bellcore lab 214.
         #
         # The next line sends "richtext" to the richtext
         # program
         text/richtext; richtext %s; copiousoutput
         #
         # Next, basic u-law audio
         audio/*; showaudio; test=/usr/local/bin/hasaudio
         #
         # Next, use the xview program to handle several image
         # formats
         image/*; xview %s; test=/usr/local/bin/RunningX
         #
         # The ATOMICMAIL interpreter uses curses, so needs a
         # terminal
         application/atomicmail; /usr/local/bin/atomicmail %s; \
             needsterminal
         #
         # The next line handles Andrew format,
         #   if ez and ezview are installed
         x-be2; /usr/andrew/bin/ezview %s; \
            print=/usr/andrew/bin/ezprint %s ; \
            compose=/usr/andrew/bin/ez -d %s \;
            edit=/usr/andrew/bin/ez -d %s; \;
            copiousoutput
         #
         # The next silly example demonstrates the use of
         # quoting
         application/*; echo "This is \"%t\" but \
            is 50 \% Greek to me" \; cat %s; copiousoutput

Notes:

Some comment lines in the example termcap file appear to have improperly reformatted to fit the 78-character limit; the needed "# " was ommitted.

RFC 1531, "Dynamic Host Configuration Protocol", October 1993

Note: This RFC has been obsoleted by RFC 1541

Source of RFC: dhc (int)

Errata ID: 546
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jim Withnall
Date Reported: 2001-10-31

Section 4.4.4 says:

   Any DHCPACK messages that arrive with an 'xid' that does not match the
   When the client receives a DHCPACK from the server, the client
   computes the lease expiration time as the sum of the time at which the
   client sent the DHCPREQUEST message and the duration of the lease in
   the DHCPACK message.

It should say:

   Any DHCPACK messages that arrive with an 'xid' that does not match the
   'xid' of the client's DHCPREQUEST message are silently discarded.
   When the client receives a DHCPACK from the server, the client
   computes the lease expiration time as the sum of the time at which the
   client sent the DHCPREQUEST message and the duration of the lease in
   the DHCPACK message.  

RFC 1534, "Interoperation Between DHCP and BOOTP", October 1993

Source of RFC: dhc (int)

Errata ID: 545
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tyler Tidman
Date Reported: 2001-09-05

Section 2 says:

   Any message received by a DHCP server that includes a 'DHCP message
   type' (51) option is assumed to have been sent by a DHCP client.

It should say:

   Any message received by a DHCP server that includes a 'DHCP message
   type' (53) option is assumed to have been sent by a DHCP client.

RFC 1535, "A Security Problem and Proposed Correction With Widely Deployed DNS Software", October 1993

Source of RFC: Legacy
Area Assignment: int

Errata ID: 4781
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Harald Albrecht
Date Reported: 2016-08-18
Verifier Name: Éric Vyncke
Date Verified: 2024-01-12

Section Solution(s) says:

Given user@a.b.c.d. connecting to host those same two
tries would appear as:

   x.b.c.d.  and x.

It should say:

Given user@a.b.c.d. connecting to host x those same two
tries would appear as:

   x.b.c.d.  and x.

Notes:

The original example text in section "Solution(s)" does not list the specific host the user@a.b.c.d. wants to connect to. From the search items listed next, I would suspect that the user wants to connect to host "x". However, I'm not exactly sure. In any case, it would be helpful to clarify the text with respect to the search list given next.

RFC 1542, "Clarifications and Extensions for the Bootstrap Protocol", October 1993

Source of RFC: Legacy

Errata ID: 544
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Grzegorz R. Gryczka
Date Reported: 2002-10-24

Section 3.1.1 says:

  If a client falls into this category, it SHOULD set (to 1) the
  newly-defined BROADCAST flag in the 'flags' field of BOOTREPLY
  messages it generates.  This will provide a hint to BOOTP servers
  and relay agents that they should attempt to broadcast their
  BOOTREPLY messages to the client.

It should say:

  If a client falls into this category, it SHOULD set (to 1) the
  newly-defined BROADCAST flag in the 'flags' field of BOOTREQUEST
  messages it generates.  This will provide a hint to BOOTP servers
  and relay agents that they should attempt to broadcast their BOOTREPLY
  messages to the client.

Notes:

(i.e. the first instance of "BOOTREPLY" should be "BOOTREQUEST".)

RFC 1606, "A Historical Perspective On The Usage Of IP Version 9", April 1994

Source of RFC: INDEPENDENT

Errata ID: 5404
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nick Hudson
Date Reported: 2018-06-22
Verifier Name: John Scudder
Date Verified: 2024-01-14

Section Routing says:

vendor to do remote diagnostics on discreet elements of the device. 

It should say:

vendor to do remote diagnostics on discrete elements of the device. 

Notes:

The document uses the word "discreet" where it ought to say "discrete"

Errata ID: 5405
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nick Hudson
Date Reported: 2018-06-22
Verifier Name: John Scudder
Date Verified: 2024-01-14

Section Allocation says:

groups of a million addresses to be allocated for each discreet unit

It should say:

groups of a million addresses to be allocated for each discrete unit

Notes:

The document uses the word "discreet" where it ought to say "discrete"

Errata ID: 5406
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Edwin Mons
Date Reported: 2018-06-22
Verifier Name: John Scudder
Date Verified: 2024-01-14

Section Manufacture says:

by the billion for the price or a grain of sugar

It should say:

by the billion for the price of a grain of sugar

Errata ID: 7328
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Carl Cerecke
Date Reported: 2023-02-03
Verifier Name: RFC Editor
Date Verified: 2023-02-03

Section Applications says:

The introduction of body monitors as IPv9 addresseable units injected

It should say:

The introduction of body monitors as IPv9 addressable units injected

Notes:

Corrected spelling of addressable

Errata ID: 7329
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Carl Cerecke
Date Reported: 2023-02-03
Verifier Name: RFC Editor
Date Verified: 2023-02-03

Section Applications says:

The usage of IPv9 addresseable consumer packaging has been a topic of

It should say:

The usage of IPv9 addressable consumer packaging has been a topic of

Notes:

Corrected spelling of addressable

Errata ID: 7330
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Carl Cerecke
Date Reported: 2023-02-03
Verifier Name: RFC Editor
Date Verified: 2023-02-03

Section Manufacture says:

day anything that wished to be could be IPv9 addresseable. It was

It should say:

day anything that wished to be could be IPv9 addressable. It was

Notes:

Corrected spelling of addressable

RFC 1628, "UPS Management Information Base", May 1994

Source of RFC: upsmib (ops)

Errata ID: 3275
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jürgen Sellinath
Date Reported: 2012-07-03
Verifier Name: Ron Bonica
Date Verified: 2012-07-03

Section 4 says:

UPS-MIB DEFINITIONS ::= BEGIN

   IMPORTS
       MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
       OBJECT-IDENTITY, Counter32, Gauge32, Integer32
           FROM SNMPv2-SMI
       DisplayString, TimeStamp, TimeInterval, TestAndIncr,
         AutonomousType
           FROM SNMPv2-TC
       MODULE-COMPLIANCE, OBJECT-GROUP
           FROM SNMPv2-CONF;

It should say:

UPS-MIB DEFINITIONS ::= BEGIN

   IMPORTS
       MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
       OBJECT-IDENTITY, Counter32, Gauge32, Integer32
           FROM SNMPv2-SMI
       DisplayString, TimeStamp, TimeInterval, TestAndIncr,
         AutonomousType, TEXTUAL-CONVENTION
           FROM SNMPv2-TC
       MODULE-COMPLIANCE, OBJECT-GROUP
           FROM SNMPv2-CONF;

Notes:

Textual conventions are used within this MIB, but the macro "TEXTUAL-CONVENTION" itself is not imported, as it should (RFC 2578 §3.2).

Errata ID: 3276
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jürgen Sellinath
Date Reported: 2012-07-03
Verifier Name: Ron Bonica
Date Verified: 2012-07-03

Section 4.8 says:

upsShutdownAfterDelay OBJECT-TYPE
       SYNTAX     INTEGER (-1..2147483648)
       UNITS      "seconds"
       MAX-ACCESS read-write
       STATUS     current
       DESCRIPTION
               "Setting this object will shutdown (i.e., turn off)
               either the UPS output or the UPS system (as determined
               by the value of upsShutdownType at the time of
               shutdown) after the indicated number of seconds, or
               less if the UPS batteries become depleted. Setting
               this object to 0 will cause the shutdown to occur
               immediately.  Setting this object to -1 will abort the
               countdown.  If the system is already in the desired
               state at the time the countdown reaches 0, then
               nothing will happen.  That is, there is no additional
               action at that time if upsShutdownType = system and
               the system is already off.  Similarly, there is no
               additional action at that time if upsShutdownType =
               output and the output is already off.  When read,
               upsShutdownAfterDelay will return the number of
               seconds remaining until shutdown, or -1 if no shutdown
               countdown is in effect.  On some systems, if the agent
               is restarted while a shutdown countdown is in effect,
               the countdown may be aborted.  Sets to this object
               override any upsShutdownAfterDelay already in effect."
       ::= { upsControl 2 }

   upsStartupAfterDelay OBJECT-TYPE
       SYNTAX     INTEGER (-1..2147483648)
       UNITS      "seconds"
       MAX-ACCESS read-write
       STATUS     current
       DESCRIPTION

It should say:

upsShutdownAfterDelay OBJECT-TYPE
       SYNTAX     INTEGER (-1..2147483647)
       UNITS      "seconds"
       MAX-ACCESS read-write
       STATUS     current
       DESCRIPTION
               "Setting this object will shutdown (i.e., turn off)
               either the UPS output or the UPS system (as determined
               by the value of upsShutdownType at the time of
               shutdown) after the indicated number of seconds, or
               less if the UPS batteries become depleted. Setting
               this object to 0 will cause the shutdown to occur
               immediately.  Setting this object to -1 will abort the
               countdown.  If the system is already in the desired
               state at the time the countdown reaches 0, then
               nothing will happen.  That is, there is no additional
               action at that time if upsShutdownType = system and
               the system is already off.  Similarly, there is no
               additional action at that time if upsShutdownType =
               output and the output is already off.  When read,
               upsShutdownAfterDelay will return the number of
               seconds remaining until shutdown, or -1 if no shutdown
               countdown is in effect.  On some systems, if the agent
               is restarted while a shutdown countdown is in effect,
               the countdown may be aborted.  Sets to this object
               override any upsShutdownAfterDelay already in effect."
       ::= { upsControl 2 }

   upsStartupAfterDelay OBJECT-TYPE
       SYNTAX     INTEGER (-1..2147483647)
       UNITS      "seconds"
       MAX-ACCESS read-write
       STATUS     current
       DESCRIPTION

Notes:

The upper limit of the ranges of upsShutdownAfterDelay and upsStartupAfterDelay points to the intention to use a 32-bit signed integer.
The biggest positive value of a 32-bit singed integer, however, is 2147483647. On a 32-Bit system the upper range given within RFC1628 (2147483648) is so large that is is unsigned, which conflicts with the limitation to 32 bits.
As 2147483648 seconds is more than 68 years, it seems preferable to change this to 2147483647, loosing 1 second but gaining the ability to be implemented with 32 bits.

Errata ID: 4831
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sean Van Gorder
Date Reported: 2016-10-14
Verifier Name: Benoit Claise
Date Verified: 2016-10-28

Section 4 says:

       OBJECT     upsOutputSource
       SYNTAX     INTEGER {
           normal(2),
           battery(4)
       }
       DESCRIPTION
               "Support of the values other(1), none(2), bypass(4),
               booster(6) and reducer(7) is not required."

It should say:

       OBJECT     upsOutputSource
       SYNTAX     INTEGER {
           normal(3),
           battery(5)
       }
       DESCRIPTION
               "Support of the values other(1), none(2), bypass(4),
               booster(6) and reducer(7) is not required."

Notes:

This error appears 3 separate times, in the MODULE-COMPLIANCE definitions upsSubsetCompliance, upsBasicCompliance, and upsFullCompliance.

The wrong numbers are specified with the named values, which must match the OBJECT-TYPE definition of upsOutputSource.

RFC 1630, "Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web", June 1994

Source of RFC: Legacy

Errata ID: 6887
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eugene Adell
Date Reported: 2022-03-17
Verifier Name: RFC Editor
Date Verified: 2022-03-17

Section Reommendations says:

Reommendations

It should say:

Recommendations

Notes:

minor typo
s/Reommendations/Recommendations/

Errata ID: 6889
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eugene Adell
Date Reported: 2022-03-17
Verifier Name: RFC Editor
Date Verified: 2022-03-17

Section OTHER RESERVED CHARACTERS says:

      The astersik ("*", ASCII 2A hex) and exclamation mark ("!" , ASCII
      21 hex) are reserved for use as having special signifiance within
      specific schemes.

It should say:

      The asterisk ("*", ASCII 2A hex) and exclamation mark ("!" , ASCII
      21 hex) are reserved for use as having special significance within
      specific schemes.

Notes:

Errata 6888 was sent too fast, sorry. Minor typos.
s/astersik/asterisk/
s/signifiance/significance/

RFC 1661, "The Point-to-Point Protocol (PPP)", July 1994

Note: This RFC has been updated by RFC 2153

Source of RFC: pppext (int)

Errata ID: 543
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stuart Cheshire
Date Reported: 2006-09-27
Verifier Name: Brian Haberman
Date Verified: 2012-04-26

Section 5.4 says:

On reception of a Configure-Reject, the Identifier field MUST
match that of the last transmitted Configure-Request.
Additionally, the Configuration Options in a Configure-Reject MUST
be a proper subset of those in the last transmitted Configure-
Request.  Invalid packets are silently discarded.

It should say:

On reception of a Configure-Reject, the Identifier field MUST
match that of the last transmitted Configure-Request.
Additionally, the Configuration Options in a Configure-Reject MUST
be a subset of those in the last transmitted Configure-
Request.  Invalid packets are silently discarded.

Notes:

The word "proper" should be deleted. (I discussed this a while ago with
the author, Bill Simpson, and he agreed.)

If A is a subset of B, then set A contains only elements that are also in
set B, up to and including all the elements of B (in which case A == B).

If A is a PROPER subset of B, then A contains only elements that are in
B, up to BUT NOT including all the elements of B.

In this case, the word "proper" is just a mistake, perhaps added because
someone thought it made the sentence sound better, without realizing that
the mathematical term "proper subset" has a specific precise meaning,
which is the wrong meaning in this case. As written in the RFC, the
sentence states that if a Configure-Request packet has n Configuration
Options in it, ALL of which are not recognizable or not acceptable, then
when the implementation returns its Configure-Reject packet, it's only
allowed to indicate that up to n-1 options were rejected, when in truth
ALL were rejected. Removing the word "proper" removes this unintended and
incorrect limitation.

RFC 1662, "PPP in HDLC-like Framing", July 1994

Source of RFC: pppext (int)

Errata ID: 542
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Charles Cranford
Date Reported: 2002-03-07

In the References Section:

   [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", 
         STD 50, RFC 1661, Daydreamer, July 1994.

It should say:

   [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", 
         STD 51, RFC 1661, Daydreamer, July 1994.

RFC 1685, "Writing X.400 O/R Names", August 1994

Source of RFC: Legacy
Area Assignment: app

Errata ID: 1404
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Harald Tveit Alvestrand
Date Reported: 2008-04-03
Verifier Name: Alexey Melnikov
Date Verified: 2010-09-02

Section 6 says:

   RFC822: Harald.Alvestrand@uninett.no
   X.400:  C=no; ADMD=; PRMD=uninett; O=uninett; S=alvestrand;
   G=harald

It should say:

   RFC822: Harald.Alvestrand@uninett.no
   X.400:  G=Harald; S=alvestrand; O=uninett; P=uninett; C=no

Notes:

The RFC is about the format of O/R names. The address as given in the author's address section should be consistent with the format recommended by the RFC.

RFC 1724, "RIP Version 2 MIB Extension", November 1994

Source of RFC: ripv2 (rtg)

Errata ID: 540
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Orly Nicklass
Date Reported: 2004-05-27

Section 9 says:

            rip2IfConfAuthKey
                OCTET STRING (SIZE(0..16)),

It should say:

            rip2IfConfAuthKey
                OCTET STRING,

RFC 1725, "Post Office Protocol - Version 3", November 1994

Note: This RFC has been obsoleted by RFC 1939

Source of RFC: Legacy
Area Assignment: app

Errata ID: 1086
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Joseph Bowbeer
Date Reported: 2007-11-29
Verifier Name: Alexey Melnikov
Date Verified: 2010-09-02

Section 7 says:

Note that if the number of lines requested by the POP3
client is greater than than the number of lines in the
                  ^^^^
body, then the POP3 server sends the entire message.

It should say:

Note that if the number of lines requested by the POP3
client is greater than the number of lines in the body,
then the POP3 server sends the entire message.

Notes:

Extraneous "than" in discussion of TOP command.

RFC 1738, "Uniform Resource Locators (URL)", December 1994

Note: This RFC has been obsoleted by RFC 4248, RFC 4266

Note: This RFC has been updated by RFC 1808, RFC 2368, RFC 2396, RFC 3986, RFC 6196, RFC 6270, RFC 8089

Source of RFC: Legacy

Errata ID: 5118
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: literal slash needed in gopher BNF
Date Reported: 2017-09-15
Verifier Name: Alexey Melnikov
Date Verified: 2017-09-21

Section 5. says:

gopherurl      = "gopher://" hostport [ / [ gtype [ selector
                 [ "%09" search [ "%09" gopher+_string ] ] ] ] ]

It should say:

gopherurl      = "gopher://" hostport [ "/" [ gtype [ selector
                 [ "%09" search [ "%09" gopher+_string ] ] ] ] ]

Notes:

The slash after the first square bracket open should be quoted because it is a literal slash, as evidenced in the example in section 3.4.1:

3.4.1. Gopher URL syntax

gopher://<host>:<port>/<gopher-path>

Errata ID: 4917
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stephan Casas
Date Reported: 2017-01-26
Verifier Name: John Scudder
Date Verified: 2024-01-15

Section 2.2 says:

the chararacter which has that octet as its code within the US-ASCII
[20] coded character set.

It should say:

the character which has that octet as its code within the US-ASCII
[20] coded character set.

Notes:

The word "character" is misspelled as "chararacter."

RFC 1751, "A Convention for Human-Readable 128-bit Keys", December 1994

Source of RFC: Legacy
Area Assignment: sec

Errata ID: 4617
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Yoav Nir
Date Reported: 2016-02-10
Verifier Name: Stephen Farrell
Date Verified: 2016-09-12

Section Appendix A says:

btoe(engout,c)
char *c, *engout;
{
        char cp[9];     /* add in room for the parity 2 bits*/

It should say:

btoe(engout,c)
char *c, *engout;
{
        char cp[10];     /* add in room for the parity 2 bits*/

Notes:

This is an off-by-one error in the sample code in Appendix A.

Further down, we have this loop:
for(p = 0,i = 0; i < 64;i += 2)
p += extract(cp,i,2);

So i goes all the way to 62, and 9-byte cp is passed to extract()

In extract, we have this:
static unsigned long
extract(s, start, length)
char *s;
int start, length;
{
.
.
.
cr = s[start/8 +2];

If start is 62, then (start/8+2) is 9. s is the same 9-byte cp, and s[start/8 +2] is a one-byte overflow.

RFC 1760, "The S/KEY One-Time Password System", February 1995

Source of RFC: Legacy

Errata ID: 6094
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Brian Jopling
Date Reported: 2020-04-12
Verifier Name: John Scudder
Date Verified: 2024-01-14

The Overview says:

One form of attack on computing system connected to the Internet is eavesdropping on network connections

It should say:

One form of attack on a computing system connected to the Internet is eavesdropping on network connections

Notes:

An article "a" should be added in front of "computing system" (i.e. "a computing system") for this statement to be grammatically correct.

Errata ID: 6095
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Brian Jopling
Date Reported: 2020-04-12
Verifier Name: John Scudder
Date Verified: 2024-01-14

The Overview says:

The captured login id and password are, at a later time, used gain access to the system.

It should say:

The captured login id and password are, at a later time, used to gain access to the system.

Notes:

Missing "to" in "used to gain access."

Errata ID: 6096
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Brian Jopling
Date Reported: 2020-04-12
Verifier Name: RFC Editor

Section 1 says:

or against active attacks where the potential intruder as able to intercept

It should say:

or against active attacks where the potential intruder is able to intercept

Notes:

Changed "intruder as able" to "intruder is able."

Errata ID: 6097
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Brian Jopling
Date Reported: 2020-04-12
Verifier Name: RFC Editor
Date Verified: 2024-01-16

The Secure Hash Function section says:

We have chosen to continue to use MD4 due the large number of client programs

It should say:

We have chosen to continue to use MD4 due to the large number of client programs

Notes:

Missing "to" in "due to the."

Errata ID: 6098
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Brian Jopling
Date Reported: 2020-04-12
Verifier Name: RFC Editor
Date Verified: 2024-01-16

The Form of Passwords sections says:

Interoperability requires at all S/KEY system hosts and calculators 
use the same dictionary.

It should say:

Interoperability requires that all S/KEY system hosts and calculators 
use the same dictionary.

Notes:

Changed "Interoperability requires at all" to "Interoperability requires that all."

Errata ID: 6099
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Brian Jopling
Date Reported: 2020-04-12
Verifier Name: RFC Editor
Date Verified: 2024-01-16

The Verification of One-Time Passwords section says:

This challenge give the client the current S/KEY parameters

It should say:

This challenge gives the client the current S/KEY parameters

Notes:

Changed "This challenge give" to "This challenge gives."

Errata ID: 6100
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Brian Jopling
Date Reported: 2020-04-12
Verifier Name: RFC Editor
Date Verified: 2024-01-16

The Verification of One-Time Passwords sections says:

Because the number of hash function applications executed by the 
client decreases by one each time, at some point the user must 
reinitialize the system of be unable to login again.

It should say:

Because the number of hash function applications executed by the 
client decreases by one each time, at some point the user must 
reinitialize the system or be unable to login again.

Notes:

Changed "must reinitialize the system of be unable to login again" to "must reinitialize the system or be unable to login again."

RFC 1766, "Tags for the Identification of Languages", March 1995

Note: This RFC has been obsoleted by RFC 3066, RFC 3282

Source of RFC: mailext (app)

Errata ID: 7872
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Shinichiro Endo
Date Reported: 2024-03-27
Verifier Name: RFC Editor
Date Verified: 2024-03-27

Section 1 says:

   A prerequisite for any such function is a means of labelling the
   information content with an identifier for the language in which is
   is written.

It should say:

   A prerequisite for any such function is a means of labelling the
   information content with an identifier for the language in which it
   is written.

Notes:

Last part of the sentence "in which is is written" should be "in which it is written".

RFC 1771, "A Border Gateway Protocol 4 (BGP-4)", March 1995

Note: This RFC has been obsoleted by RFC 4271

Source of RFC: Legacy

Errata ID: 539
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Pete Young
Date Reported: 2003-10-01

Section 4.3 says:

Total Path Attribute Length:

          This 2-octet unsigned integer indicates the total length of
	  the Path Attributes field in octets.  Its value must allow
	  the length of the Network Layer Reachability field to be
	  determined as specified below. 

          A value of 0 indicates that no Network Layer Reachability
          Information field is present in this UPDATE message.

It should say:

          A value of 0 indicates that the Path Attributes field is
	  not present in this UPDATE message.

RFC 1810, "Report on MD5 Performance", June 1995

Source of RFC: Legacy

Errata ID: 1059
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Denis Duault
Date Reported: 2007-08-28

In the References, it says:

   [7] Touch, J., Optimized MD5 software, <ftp://ftp.isi.edu/pub/hpcc-
       papers/touch/md5-opt.tar>.

It should say:

   [7] Touch, J., Optimized MD5 software, <ftp://ftp.isi.edu/pub/hpcc-
       papers/touch/md5-opt.tar.Z>.

Notes:

I noticed a broken link.
(the final ".Z" is missing)

RFC 1812, "Requirements for IP Version 4 Routers", June 1995

Note: This RFC has been updated by RFC 2644, RFC 6633

Source of RFC: rreq (rtg)

Errata ID: 537
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2005-05-12

Section 11 says:

   ROUTE:4.
        Lougheed, K., and Y.  Rekhter, "A Border Gateway Protocol 3
        (BGP-3)", RFC 1267, cisco, T.J. Watson Research Center, IBM
        Corp., October 1991.

It should say:

   ROUTE:4.
        Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", 
        RFC 1771, March 1995.

Errata ID: 538
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2005-05-12

Section 7.3.1 says:

   Although it was not designed as an exterior gateway protocol, RIP
   (described in Section [7.2.4]) is sometimes used for inter-AS
   routing.

It should say:

   Although it was not designed as an exterior gateway protocol, RIP
   (described in Appendix F.2) is sometimes used for inter-AS
   routing.

RFC 1818, "Best Current Practices", August 1995

Source of RFC: Legacy
Area Assignment: gen

Errata ID: 6923
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Robin Geuze
Date Reported: 2022-04-05
Verifier Name: RFC Editor
Date Verified: 2022-04-05

Section Discussion says:

This document creates a new subseries of RFCs, entitled Best Current Practices BCPs).

It should say:

This document creates a new subseries of RFCs, entitled Best Current Practices (BCPs).

Notes:

The opening parentheses was clearly forgotten by accident.

RFC 1867, "Form-based File Upload in HTML", November 1995

Note: This RFC has been obsoleted by RFC 2854

Source of RFC: html (app)

Errata ID: 536
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Dirk Nimmich
Date Reported: 2002-03-09

Every occurance of the string:

   , boundary=

It should say:

   ; boundary=

Errata ID: 5487
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eugene Adell
Date Reported: 2018-08-31
Verifier Name: RFC Editor
Date Verified: 2018-09-21

Section 6 says:

   If the user also indicated an image file "file2.gif" for the answer
   to 'What files are you sending?', the client might client might send
   back the following data:

It should say:

   If the user also indicated an image file "file2.gif" for the answer
   to 'What files are you sending?', the client might send back the
   following data:

Notes:

"client might" appears twice, which is a typo

RFC 1878, "Variable Length Subnet Table For IPv4", December 1995

Source of RFC: Legacy
Area Assignment: int

Errata ID: 2171
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Clark Rossdale
Date Reported: 2010-04-23

Section global says:

illistrate

It should say:

illustrate

Errata ID: 5328
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Cuauhtemoc Amox
Date Reported: 2018-04-16
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2018-04-16

Throughout the document, when it says:

Introduction

  [...]

   This document itemizes the potential values for IPv4 subnets.
   Additional information is provided for Hex and Decmial values,
   classfull equivalants, and number of addresses available within the
   indicated block.

Table

   The following table lists the variable length subnets from 1 to 32,
   the CIDR [3] representation form (/xx) and the Decmial equivalents.
   (M = Million, K=Thousand, A,B,C= traditional class values)

It should say:

Introduction

  [...]

   This document itemizes the potential values for IPv4 subnets.
   Additional information is provided for Hex and Decimal values,
   classful equivalents, and number of addresses available within the
   indicated block.

Table

   The following table lists the variable length subnets from 1 to 32,
   the CIDR [3] representation form (/xx) and the Decimal equivalents.
   (M = Million, K=Thousand, A,B,C= traditional class values)

Notes:

Introduction

Typos: classfull , equivalants, Decmial

Table
Typo: Decmial

RFC 1891, "SMTP Service Extension for Delivery Status Notifications", January 1996

Note: This RFC has been obsoleted by RFC 3461

Source of RFC: notary (app)

Errata ID: 535
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Florian Weimer
Date Reported: 2002-10-21

Section 6.2 says:

   DISCUSSION: RFC 1123, section 2.3.3 requires error notifications to
   be sent with a NULL return address ("reverse-path").

It should say:

   DISCUSSION: RFC 1123, section 5.3.3 requires error notifications to
   be sent with a NULL return address ("reverse-path"). 

Notes:

RFC 1123, section 2.3.3., does not exist. The correct section is 5.3.3.

RFC 1894, "An Extensible Message Format for Delivery Status Notifications", January 1996

Note: This RFC has been obsoleted by RFC 3464

Note: This RFC has been updated by RFC 2852

Source of RFC: notary (app)

Errata ID: 534
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2002-02-25

Section 9.4 says:

   Received: from nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk
             id <g.12954-0@sun2.nsfnet-relay.ac.uk>;
   Sun, 10 Jul 1994 00:36:51 +0100
   To: owner-info-mime@cs.utk.edu
   Date: Sun, 10 Jul 1994 00:36:51 +0100
   Subject: WARNING: message delayed at "nsfnet-relay.ac.uk"
   content-type: multipart/report; report-type=delivery-status;
         boundary=foobar

It should say:

   Received: from nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk
             id <g.12954-0@sun2.nsfnet-relay.ac.uk>;
             Sun, 10 Jul 1994 00:36:51 +0100
   To: owner-info-mime@cs.utk.edu
   Date: Sun, 10 Jul 1994 00:36:51 +0100
   Subject: WARNING: message delayed at "nsfnet-relay.ac.uk"
   MIME-Version: 1.0
   content-type: multipart/report; report-type=delivery-status;
         boundary=foobar

RFC 1915, "Variance for The PPP Compression Control Protocol and The PPP Encryption Control Protocol", February 1996

Source of RFC: Legacy

Errata ID: 533
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2002-02-26

In the Title:

                           Variance for
               The PPP Connection Control Protocol
                               and
               The PPP Encryption Control Protocol

It should say:

                           Variance for
               The PPP Compression Control Protocol
                               and
               The PPP Encryption Control Protocol

RFC 1925, "The Twelve Networking Truths", April 1996

Source of RFC: INDEPENDENT

Errata ID: 532
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Ioannidis
Date Reported: 2003-04-08

Section 2 says:

   the word is "agglutinate", not "aglutenate"

Errata ID: 7026
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Martin Thomson
Date Reported: 2022-07-14
Verifier Name: RFC Editor
Date Verified: 2022-07-15

Section 2 says:

   (7)  It is always something

It should say:

   (7)  It is always something.

Notes:

This sentence is missing a period.

(It is also incorrect: it can sometimes be nothing. The corollary says "Good, Fast, Cheap: Pick any two", which is often true, but I've been around long enough to know that sometimes people choose none of the above. That is opinion though.)

RFC 1927, "Suggested Additional MIME Types for Associating Documents", April 1996

Source of RFC: INDEPENDENT

Errata ID: 531
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2003-10-07

Section 7 says:

          1) they should not be used on data flines which might end
             up in the hands of very small children

It should say:

          1) they should not be used on data files which might end up
             in the hands of very young children

RFC 1928, "SOCKS Protocol Version 5", March 1996

Source of RFC: aft (sec)

Errata ID: 3198
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Andreas Cudok
Date Reported: 2012-04-19
Verifier Name: Sean Turner
Date Verified: 2012-05-04

Section 7 says:

o if ATYP is X’04’ - 20+method_dependent octets smaller

It should say:

o if ATYP is X’04’ - 22+method_dependent octets smaller

Notes:

RSV[2]+FRAG[1]+ATYP[1]+DST.ADDR[16]+DST.PORT[2]=22
if ATYP is X’04’ [IPv6 address]

RFC 1936, "Implementing the Internet Checksum in Hardware", April 1996

Source of RFC: Legacy

Errata ID: 530
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Joe Touch
Date Reported: 2005-05-11

Section 4 says:

            4-bit carry-lookahead 2's complement adder:
                    a,b : input data
                    p   : carry propagate, where pi = ai*bi = (ai)(bi)
                    g   : carry generate, where gi = ai + bi

It should say:

             4-bit carry-lookahead 2's complement adder:
                    a,b : input data
                    p   : carry propagate, where pi = ai + bi
                    g   : carry generate, where gi = ai*bi = (ai)(bi)

Notes:

Note: This change affects only page 4; the PLD code is known correct.

RFC 1939, "Post Office Protocol - Version 3", May 1996

Note: This RFC has been updated by RFC 1957, RFC 2449, RFC 6186, RFC 8314

Source of RFC: Legacy
Area Assignment: app

Errata ID: 529
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bernard Treine
Date Reported: 2003-11-02

Section 7 says:

          The server should never reuse an
          unique-id in a given maildrop, for as long as the entity
          using the unique-id exists.

It should say:

          The server should never reuse a
          unique-id in a given maildrop for as long as the maildrop
          exists.

RFC 1945, "Hypertext Transfer Protocol -- HTTP/1.0", May 1996

Source of RFC: http (app)

Errata ID: 7619
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ajay Kumar
Date Reported: 2023-08-26
Verifier Name: RFC Editor
Date Verified: 2023-08-29

Section 7.1 says:

Entity-Header fields define optional metainformation about the Entity-Body or

It should say:

Entity-Header fields define optional meta information about the Entity-Body or

Notes:

There should be an space between "meta" and "information"

RFC 1952, "GZIP file format specification version 4.3", May 1996

Source of RFC: Legacy

Errata ID: 7517
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mingye Wang
Date Reported: 2023-05-16
Verifier Name: RFC Editor
Date Verified: 2023-10-10

Section 2.3.1.1 says:

      0x41 ('A')  0x70 ('P')  Apollo file type information

It should say:

      0x41 ('A')  0x70 ('p')  Apollo file type information

Notes:

ASCII \x70 is lowercase p, not uppercase.

RFC 1959, "An LDAP URL Format", June 1996

Note: This RFC has been obsoleted by RFC 2255

Source of RFC: asid (app)

Errata ID: 528
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kurt D. Zeilenga
Date Reported: 2001-02-07

Section 2 says:

   <dn> ::= a string as defined in RFC 1485

It should say:

   <dn> ::= a string as defined in RFC 1779

RFC 1979, "PPP Deflate Protocol", August 1996

Source of RFC: pppext (int)

Errata ID: 527
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bartlomiej Molenda
Date Reported: 2003-11-03

Section 3 says:

   Length

      3

It should say:

   Length

      4

RFC 1985, "SMTP Service Extension for Remote Message Queue Starting", August 1996

Source of RFC: Legacy

Errata ID: 4130
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Slusarz
Date Reported: 2014-10-13
Verifier Name: Barry Leiba
Date Verified: 2014-10-14

Section 5.2 says:

If one of the 500 level error codes (550 or 551) are sent, the client
should assume that the protocol is not supported in the remote host
or that the protocol has not been implemented correctly on either the
client or server host. 

It should say:

If one of the 500 level error codes (500 or 501) is sent, the client
should assume that the protocol is not supported in the remote host
or that the protocol has not been implemented correctly on either the
client or server host. 

Notes:

550 (mailbox unavailable) and 551 (user not local) are clearly not the codes intended here; this text is meant to refer to the two syntax error codes specified in Section 5.1.

RFC 1995, "Incremental Zone Transfer in DNS", August 1996

Note: This RFC has been updated by RFC 9103

Source of RFC: dnsind (int)

Errata ID: 3197
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2012-04-18
Verifier Name: Brian Haberman
Date Verified: 2012-05-01

Section 4, pg.3 says:

|  RRs in the incremental transfer messages may be partial.  That is, if
   a single RR of multiple RRs of the same RR type changes, only the
   changed RR is transferred.

It should say:

|  RRsets in the incremental transfer messages may be partial.  That is,
|  if a single RR out of multiple RRs of the same RR type at the same
|  owner name and CLASS changes, only the changed RR is transferred.

Notes:

Rationale:
DNS resource records (RRs) are always transferred as integral
entities in the DNS protocol, and IXFR is no exception for this
rule. So there never are partial RRs in any IXFR response packets.
However, as indicated more precisely in the adjusted text above,
it is intended that partial _RRsets_ are carried in IXFR responses;
unchanged RRs are not sent inside incremental response messages.
Historical Note:
The above issue has been identified by the submitter in 2008,
but no Errata have been filed so far. However, it already had
been observed in 1999 by Andreas Gustafsson, who, in the context of
the work on RFC 1995bis, recently has provided the DNSEXT WG access
to a privately archived DNSIND mailing list thread on RFC 1995,
in which such issues have been discussed in November 1999.
For the record, the technical issues in RFC 1995 that can be
addressed by Errata Notes are now being submitted this way.

RFC 2006, "The Definitions of Managed Objects for IP Mobility Support using SMIv2", October 1996

Source of RFC: mobileip (int)

Errata ID: 5509
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Glenn Mansfield Keeni
Date Reported: 2018-09-29
Verifier Name: Éric Vyncke
Date Verified: 2024-01-12

Section 4 says:

 mipSecNotifcationsGroup NOTIFICATION-GROUP
        NOTIFICATIONS { mipAuthFailure }
        STATUS      current
        DESCRIPTION
                "The notification related to security violations."
        ::= { mipGroups 13 }

It should say:

 mipSecNotificationsGroup NOTIFICATION-GROUP
        NOTIFICATIONS { mipAuthFailure }
        STATUS      current
        DESCRIPTION
                "The notification related to security violations."
        ::= { mipGroups 13 }

Notes:

'i' missing in mipSecNotifcationsGroup

RFC 2015, "MIME Security with Pretty Good Privacy (PGP)", October 1996

Note: This RFC has been updated by RFC 3156

Source of RFC: Legacy

Errata ID: 526
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2004-01-11

Section 5 says:

&railing whitespace that occurs on lines in order to ensure  =20

It should say:

& trailing whitespace that occurs on lines in order to ensure  =20

RFC 2018, "TCP Selective Acknowledgment Options", October 1996

Source of RFC: tcplw (tsv)

Errata ID: 1610
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Matt Mathis
Date Reported: 2008-11-22
Verifier Name: Lars Eggert
Date Verified: 2008-12-19

Section 5.1 says:

   The use of time-outs as a fall-back mechanism for detecting dropped
   packets is unchanged by the SACK option.  Because the data receiver
   is allowed to discard SACKed data, when a retransmit timeout occurs
   the data sender MUST ignore prior SACK information in determining
   which data to retransmit.

It should say:

   The use of time-outs as a fall-back mechanism for detecting dropped
   packets is unchanged by the SACK option.  Because the data receiver
   is allowed to discard SACKed data, when a retransmit timeout occurs
   the data sender SHOULD ignore prior SACK information in determining
   which data to retransmit.

Notes:

At least one OS (Linux) violates the MUST to good effect: Even when timeout
driven, it keeps old SACK data so it can avoid retransmitting data already at
the receiver. Thus even under severe bandwidth exhaustion, 100% of the data
delivered to the receiver causes forward progress and the system is not subject
to classical congestion collapse (that is, congestion collapse from
unnecessarily-retransmitted packets).

When this draft is reopened, this text should be further refined to address a
number of additional issues. In particular:

- It has been observed that clearing the scoreboard on timeouts sometimes
causes very inefficient network utilization, with large quantities of
duplicated data delivered to the receiver.

- There is some risk of deadlock if the timeout was caused a corrupted
scoreboard or if the receiver reneges SACK blocks. It is important that the
checks for reneging and inconsistent scoreboards are robust. Furthermore,
there probably should be a mandatory fall back mechanism, such as requiring
classical fast retransmit and new reno behavior, or ultimately under repeated
timeouts with no forward progress, clearing the scoreboard.

- Making SACK more robust in the presence of timeouts may increase the risk of
congestion collapse associated with cascaded bottlenecks, because it may
enable TCP to function under unreasonably high loss rates.

RFC 2021, "Remote Network Monitoring Management Information Base Version 2 using SMIv2", January 1997

Note: This RFC has been obsoleted by RFC 4502

Source of RFC: rmonmib (ops)

Errata ID: 525
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Frank McKiernan
Date Reported: 2002-06-25

The DESCRIPTION of probeDownloadAction uses the wrong INTEGER definitions for downloadToPROM and downloadToRAM. On page 92, it reads:

   probeDownloadAction  OBJECT-TYPE
    SYNTAX     INTEGER {
                  notDownloading(1),
                  downloadToPROM(2),
                  downloadToRAM(3)
               }
    MAX-ACCESS read-write
    STATUS     current
    DESCRIPTION
        "When this object is set to downloadToRAM(2) or
        downloadToPROM(3), the device will discontinue its
        normal operation and begin download of the image specified
        by probeDownloadFile from the server specified by
        probeDownloadTFTPServer using the TFTP protocol.  If
        downloadToRAM(2) is specified, the new image is copied
        to RAM only (the old image remains unaltered in the flash
        EPROM).  If downloadToPROM(3) is specified
        the new image is written to the flash EPROM
        memory after its checksum has been verified to be correct.
        When the download process is completed, the device will
	warm boot to restart the newly loaded application.
        When the device is not downloading, this object will have
        a value of notDownloading(1)."
    ::= { probeConfig 8 }

It should say:

probeDownloadAction  OBJECT-TYPE
    SYNTAX     INTEGER {
                  notDownloading(1),
                  downloadToPROM(2),
                  downloadToRAM(3)
               }
    MAX-ACCESS read-write
    STATUS     current
    DESCRIPTION
        "When this object is set to downloadToRAM(3) or
        downloadToPROM(2), the device will discontinue its
        normal operation and begin download of the image specified
        by probeDownloadFile from the server specified by
        probeDownloadTFTPServer using the TFTP protocol.  If
        downloadToRAM(3) is specified, the new image is copied
        to RAM only (the old image remains unaltered in the flash
        EPROM).  If downloadToPROM(2) is specified
        the new image is written to the flash EPROM
        memory after its checksum has been verified to be correct.
        When the download process is completed, the device will
        warm boot to restart the newly loaded application.
        When the device is not downloading, this object will have
        a value of notDownloading(1)."
    ::= { probeConfig 8 }

RFC 2026, "The Internet Standards Process -- Revision 3", October 1996

Note: This RFC has been updated by RFC 3667, RFC 3668, RFC 3932, RFC 3978, RFC 3979, RFC 5378, RFC 5657, RFC 5742, RFC 6410, RFC 7100, RFC 7127, RFC 7475, RFC 8179, RFC 8789, RFC 9282

Source of RFC: poised95 (gen)

Errata ID: 522
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Scott Bradner
Date Reported: 2002-08-01

Section 10.4 says:

   "The IETF takes no position regarding the validity or scope of
   any intellectual property or other rights that might be claimed
   to  pertain to the implementation or use of the technology
   described in this document or the extent to which any license
   under such rights might or might not be available; neither does
   it represent that it has made any effort to identify any such
   rights.  Information on the IETF's procedures with respect to
   rights in standards-track and standards-related documentation
   can be found in BCP-11..."

Notes:

The reference to BCP-11 should be to BCP-9 (RFC 2026 itself).

Errata ID: 524
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bob Harvey
Date Reported: 2002-12-30

Section 2.1 says:

   Some RFCs standardize the results of community deliberations about
   statements of principle or conclusions about what is the best way to
   perform some operations or IETF process function.  These RFCs form
   the specification has been adopted as a BCP, it is given the
   additional label "BCPxxx", but it keeps its RFC number and its place
   in the RFC series. (see section 5)

It should say:

   Some RFCs standardize the results of community deliberations about
   statements of principle or conclusions about what is the best way to
   to perform some operations or IETF process function.  These RFCs form
   the 'BCP' (Best Current Practice) subseries of the RFC series.  When 
   a specification has been adopted as a BCP, it is given the 
   additional label "BCPxxx", but it keeps its RFC number and its place
   in the RFC series. (see section 5)

Notes:

The following words are missing:

'BCP' (Best Current Practice) subseries of the RFC Series. When a

Errata ID: 523
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Morris M. Keesan
Date Reported: 2003-10-07

Section 9.1 says:

    This variance procedure is for use when a one-time waving of some
    provision of this document is felt to be required.

It should say:

    This variance procedure is for use when a one-time waiving of some
    provision of this document is felt to be required.

Errata ID: 586
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Morris M. Keesan
Date Reported: 2003-10-07

Section 10.3.1 says:

    4. The contributor represents that contribution properly
       acknowledge major contributors.

    5. The contribuitor, the organization (if any) he represents and
       the owners of any proprietary rights in the contribution, agree
       that no information in the contribution is confidential and
       that the ISOC and its affiliated organizations may freely
       disclose any information in the contribution.

It should say:

    4. The contributor represents that the contribution properly
       acknowledges major contributors.

    5. The contributor, the organization (if any) he represents and
       the owners of any proprietary rights in the contribution, agree
       that no information in the contribution is confidential and
       that the ISOC and its affiliated organizations may freely
       disclose any information in the contribution.

Notes:

verb agreement ("acknowledges") and spelling correction ("contributor")

Errata ID: 1622
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2008-12-01
Verifier Name: Russ Housley
Date Verified: 2009-10-01

Section 6.5.2 says:

ISEG Chair

It should say:

IESG Chair

Errata ID: 2007
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2010-01-17
Verifier Name: Russ Housley
Date Verified: 2010-03-02

Section 10.4 says:

         This document and translations of it may be copied and
         furnished to others, and derivative works that comment on or
         otherwise explain it or assist in its implmentation may be
         prepared, copied, published and distributed, in whole or in
         part, without restriction of any kind, provided that the above
         copyright notice and this paragraph are included on all such
         copies and derivative works.  However, this document itself may
         not be modified in any way, such as by removing the copyright
         notice or references to the Internet Society or other Internet
         organizations, except as needed for the  purpose of developing
         Internet standards in which case the procedures for copyrights
         defined in the Internet Standards process must be followed, or
         as required to translate it into languages other than English.

It should say:

         This document and translations of it may be copied and
         furnished to others, and derivative works that comment on or
         otherwise explain it or assist in its implementation may be
         prepared, copied, published and distributed, in whole or in
         part, without restriction of any kind, provided that the above
         copyright notice and this paragraph are included on all such
         copies and derivative works.  However, this document itself may
         not be modified in any way, such as by removing the copyright
         notice or references to the Internet Society or other Internet
         organizations, except as needed for the  purpose of developing
         Internet standards in which case the procedures for copyrights
         defined in the Internet Standards process must be followed, or
         as required to translate it into languages other than English.

Notes:

"implementation" is misspelled.

Errata ID: 3014
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-11-04
Verifier Name: Russ Housley
Date Verified: 2011-12-06

Section 6.5.4 says:

   [NOTE:  These procedures intentionally and explicitly do not
   establish a fixed maximum time period that shall be considered
   "reasonable" in all cases.  The Internet Standards Process places a
   premium on consensus and efforts to achieve it, and deliberately
   foregoes deterministically swift execution of procedures in favor of
   a latitude within which more genuine technical agreements may be
   reached.]

It should say:

   [NOTE:  These procedures intentionally and explicitly do not
   establish a fixed maximum time period that shall be considered
   "reasonable" in all cases.  The Internet Standards Process places a
   premium on consensus and efforts to achieve it, and deliberately
   forgoes deterministically swift execution of procedures in favor of
   a latitude within which more genuine technical agreements may be
   reached.]

Notes:

s/foregoes/forgoes/

"foregoes" means "to go before; precede."
"forgoes" means "to abstain or refrain from; do without."

Errata ID: 3015
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-11-04
Verifier Name: Russ Housley
Date Verified: 2011-12-06

Section 10.3.1 says:

   5. The contribuitor, the organization (if any) he represents and the
      owners of any proprietary rights in the contribution, agree that
      no information in the contribution is confidential and that the
      ISOC and its affiliated organizations may freely disclose any
      information in the contribution.

It should say:

   5. The contributor, the organization (if any) he represents and the
      owners of any proprietary rights in the contribution, agree that
      no information in the contribution is confidential and that the
      ISOC and its affiliated organizations may freely disclose any
      information in the contribution.

Notes:

s/contribuitor/contributor/

Errata ID: 3016
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-11-04
Verifier Name: Russ Housley
Date Verified: 2011-12-06

Section 10.3.1. says:

   By submission of a contribution, each person actually submitting the
   contribution is deemed to agree to the following terms and conditions
   on his own behalf, on behalf of the organization (if any) he
   represents and on behalf of the owners of any propriety rights in the
   contribution..  Where a submission identifies contributors in
   addition to the contributor(s) who provide the actual submission, the
   actual submitter(s) represent that each other named contributor was
   made aware of and agreed to accept the same terms and conditions on
   his own behalf, on behalf of any organization he may represent and
   any known owner of any proprietary rights in the contribution.

It should say:

   By submission of a contribution, each person actually submitting the
   contribution is deemed to agree to the following terms and conditions
   on his own behalf, on behalf of the organization (if any) he
   represents and on behalf of the owners of any propriety rights in the
   contribution.  Where a submission identifies contributors in
   addition to the contributor(s) who provide the actual submission, the
   actual submitter(s) represent that each other named contributor was
   made aware of and agreed to accept the same terms and conditions on
   his own behalf, on behalf of any organization he may represent and
   any known owner of any proprietary rights in the contribution.

Notes:

s/contribution../contribution./

Errata ID: 6658
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jason Yundt
Date Reported: 2021-08-15
Verifier Name: Lars Eggert
Date Verified: 2023-08-11

Section Status says:

This document specifies an Internet Best Current Practices

It should say:

This document specifies an Internet Best Current Practice

Notes:

“Practices” should be singular.

Errata ID: 6659
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jason Yundt
Date Reported: 2021-08-15
Verifier Name: Lars Eggert
Date Verified: 2023-08-11

Section 1.2 says:

   The procedures described in this document are the result of a number
   of years of evolution, driven both by the needs of the growing and
   increasingly diverse Internet community, and by experience.

It should say:

   The procedures described in this document are the result of a number
   of years of evolution, driven both by the needs of the growing and
   increasingly diverse Internet community and by experience.

Notes:

The list contains 2 items:

• “by the needs of the growing and increasingly diverse Internet community”
• “by experience”

Since the list contains 2 items, there shouldn’t be a comma before the word “and”.

Errata ID: 6661
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jason Yundt
Date Reported: 2021-08-16
Verifier Name: RFC Editor

Section 8 says:

In the case
of a meeting, for example, the announcement shall include an agenda
that specifies the standards- related issues that will be discussed.

It should say:

In the case
of a meeting, for example, the announcement shall include an agenda
that specifies the standards-related issues that will be discussed.

Notes:

Either the hyphen or the space could be removed. I removed the space since the next sentence says “standards-related”.

Errata ID: 6669
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jason Yundt
Date Reported: 2021-08-31
Verifier Name: RFC Editor
Date Verified: 2022-01-27

Section 10.3.1 says:

l. Some works[…]

It should say:

1. Some works[…]

Notes:

This was the only item in the list that used a letter and not a number.

Errata ID: 7181
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alvaro Retana
Date Reported: 2022-10-25
Verifier Name: RFC Editor
Date Verified: 2022-10-27

Section 4.2.4 says:

   Note: Standards track specifications normally must not depend on
   other standards track specifications which are at a lower maturity
   level or on non standards track specifications other than referenced
   specifications from other standards bodies.  (See Section 7.)

It should say:

Move to Section 4:

   Standards track specifications normally must not depend on
   other standards track specifications which are at a lower maturity
   level or on non standards track specifications other than referenced
   specifications from other standards bodies.  (See Section 7.)

Notes:

The note in §4.2.4 (Historic) applies to standards track documents in general, and not specifically to Historic documents (which are not in the Standards Track) as it seems by including it in that subsection.

The text should be moved, unchanged (except for maybe removing the leading "Note:") to be the last paragraph in §4 (before the start of §4.1).

RFC 2028, "The Organizations Involved in the IETF Standards Process", October 1996

Note: This RFC has been obsoleted by RFC 9281

Note: This RFC has been updated by RFC 3668, RFC 3979, RFC 8717

Source of RFC: poised95 (gen)

Errata ID: 521
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Pete Resnick
Date Reported: 2006-03-21
Verifier Name: Russ Housley
Date Verified: 2009-10-01

Section 3.6 says:

The IAB appoints the IETF chair and is responsible for approving
other IESG candidates put forward by the IETF nominating committee.

It should say:

Full IAB members, including the IETF chair, are selected and 
appointed according to the procedures defined in [E].

Notes:

The document references include:

[E] Galvin, J (Ed.), "IAB and IESG Selection, Confirmation, and
Recall Process: Operation of the Nominating and Recall Committees",
RFC 2027, October 1996.

Of course, this document has been revised since RFC 2028 was written.

Errata ID: 764
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Pete Resnick
Date Reported: 2006-03-21
Verifier Name: Russ Housley
Date Verified: 2010-03-02

Section 3.6 says:

The IAB is also responsible for reviewing and approving the charters of new Working Groups that are proposed for the IETF.

It should say:

The formation of a working group requires a charter which is primarily negotiated 
between a prospective working group Chair and the relevant Area 
Director(s), although final approval is made by the IESG with advice 
from the Internet Architecture Board (IAB).

Notes:

from pending

Errata ID: 2727
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-02-22
Verifier Name: Russ Housley
Date Verified: 2011-06-07

Section 5 says:

[H] IRTF Charter, RFC 2014, October 1996.

It should say:

[H]  Weinrib, A. and J. Postel, "IRTF Research Group Guidelines and
     Procedures", BCP 8, RFC 2014, October 1996.

RFC 2030, "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", October 1996

Note: This RFC has been obsoleted by RFC 4330

Source of RFC: Legacy
Area Assignment: int

Errata ID: 517
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: David L. Mills
Date Reported: 2001-05-04

Section 5 says:

   d = (T4 - T1) - (T2 - T3)     t = ((T2 - T1) + (T3 - T4)) / 2.

It should say:

   d = (T4 - T1) - (T3 - T2)     t = ((T2 - T1) + (T3 - T4)) / 2.

Errata ID: 518
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Joe Hutcheson
Date Reported: 2001-03-16

Section 3 says:

   Note that when calculating the correspondence, 2000 is not a
   leap year. 

Notes:

Please disregard above statement regarding Leap Year, as the year 2000
was indeed a Leap Year.

Errata ID: 519
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Akinori Shoji
Date Reported: 2003-07-18

Section 5 says:

      Field Name              Unicast/Anycast          Multicast
                              Request    Reply
      ----------------------------------------------------------
      LI                      0          0-2           0-2
      VN                      1-4        copied from   1-4
                                         request
      Mode                    3          4             5
      Stratum                 0          1-14          1-14
      Poll                    0          ignore        ignore

It should say:

      Field Name              Unicast/Anycast          Multicast
                              Request    Reply
      ----------------------------------------------------------
      LI                      0          0-2           0-2
      VN                      1-4        copied from   1-4
                                         request
      Mode                    3          4             5
      Stratum                 0          1-15          1-15
      Poll                    0          ignore        ignore

RFC 2040, "The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms", October 1996

Source of RFC: Legacy

Errata ID: 514
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bob Baldwin
Date Reported: 2004-03-26

Section 8 says:

   1. Exclusive-or Pn-1 with the previous ciphertext
      block, Cn-2, to create Xn-1.

It should say:

   1. Exclusive-or Pn-1 with the previous ciphertext
      block, Cn-2, to create Xn-1.  For short messages where
      Cn-2 does not exist, use IV.

Errata ID: 587
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bob Baldwin
Date Reported: 2004-03-22

Section 8 says:

6. Decrypt En to create Pn-1.

It should say:

6. Decrypt En and exclusive-or with Cn-2 to create Pn-1.
   For short messages where Cn-2 does not exist, use the IV.

Errata ID: 6380
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2021-01-04
Verifier Name: Benjamin Kaduk
Date Verified: 2021-01-12

Section 11 says:

  The values for the algorithm field are:

  RC5_CBC  OBJECT IDENTIFIER ::=
    { iso (1) member-body (2) US (840) rsadsi (113549)
      encryptionAlgorithm (3) RC5CBC (8) }

  RC5_CBC_Pad OBJECT IDENTIFIER ::=
  { iso (1) member-body (2) US (840) rsadsi (113549)
    encryptionAlgorithm (3) RC5CBCPAD (9) }

   The structure of the parameters field for these algorithms is given
   below.  NOTE: if the iv field is not included, then the
   initialization vector defaults to a block of zeros whose size depends
   on the blockSizeInBits field.

  RC5_CBC_Parameters ::= SEQUENCE {
    version           INTEGER (v1_0(16)),
    rounds            INTEGER (8..127),
    blockSizeInBits   INTEGER (64, 128),
    iv                OCTET STRING OPTIONAL
  }

It should say:

  The values for the algorithm field are:

  rC5-CBC  OBJECT IDENTIFIER ::=
    { iso (1) member-body (2) us (840) rsadsi (113549)
      encryptionAlgorithm (3) rC5CBC (8) }

  rC5-CBC-Pad OBJECT IDENTIFIER ::=
  { iso (1) member-body (2) us (840) rsadsi (113549)
    encryptionAlgorithm (3) rC5CBCPAD (9) }

   The structure of the parameters field for these algorithms is given
   below.  NOTE: if the iv field is not included, then the
   initialization vector defaults to a block of zeros whose size depends
   on the blockSizeInBits field.

  RC5-CBC-Parameters ::= SEQUENCE {
    version           INTEGER {v1-0(16)},
    rounds            INTEGER (8..127),
    blockSizeInBits   INTEGER (64 | 128),
    iv                OCTET STRING OPTIONAL
  }

Notes:

The underscore character cannot be used in the definitions; a hyphen is traditional.

The object identifiers need to begin with a lower case letter, and "us" is written with both letters lowercase.

The constraints on INTEGER values used incorrect syntax.

Errata ID: 513
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bob Baldwin
Date Reported: 2004-03-22

Section 8 says:

   This mode handles any length of plaintext and produces ciphertext 
   whose length matches the plaintext length.  

It should say:

   This mode handles any length of plaintext longer than one
   block and produces ciphertext whose length matches the
   plaintext length.

RFC 2045, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", November 1996

Note: This RFC has been updated by RFC 2184, RFC 2231, RFC 5335, RFC 6532

Source of RFC: 822ext (app)

Errata ID: 2586
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Christopher Yeleighton
Date Reported: 2010-10-28
Verifier Name: Alexey Melnikov
Date Verified: 2010-11-12

Section 1. says:

   All of the header fields defined in this document are subject to the
   general syntactic rules for header fields specified in RFC 822.  In
   particular, all of these header fields except for Content-Disposition
   can include RFC 822 comments, which have no semantic content and
   should be ignored during MIME processing.

It should say:

   All of the header fields defined in this document are subject to the
   general syntactic rules for header fields specified in RFC 822.  In
   particular, all of these header fields
   can include RFC 822 comments, which have no semantic content and
   should be ignored during MIME processing.

Notes:

A header field Content-Disposition is not defined in this document. Therefore, the header fields defined in this document do not contain a field Content-Disposition and the exception is not necessary. It is also misleading because it looks as if the exception affected the Content-Disposition field defined in RFC2813 while it does not.

Errata ID: 512
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ned Freed
Date Reported: 2005-02-24
Verifier Name: Alexey Melnikov
Date Verified: 2009-08-29

Section 5.1 says:

     tspecials :=  "(" / ")" / "<" / ">" / "@" /
                   "," / ";" / ":" / "\" / <">
                   "/" / "[" / "]" / "?" / "="

It should say:

     tspecials :=  "(" / ")" / "<" / ">" / "@" /
                   "," / ";" / ":" / "\" / <"> /
                   "/" / "[" / "]" / "?" / "="

Notes:

Missing alternative separator on the second line.

Errata ID: 7120
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maciej Szumski
Date Reported: 2022-09-07
Verifier Name: RFC Editor
Date Verified: 2022-09-07

Section 2.4 says:

Note that this does NOT imply thay they have no meaning at all

It should say:

Note that this does NOT imply that they have no meaning at all

Notes:

Fixing a typo: 'thay' instead of 'that'.

RFC 2046, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", November 1996

Note: This RFC has been updated by RFC 2646, RFC 3798, RFC 5147, RFC 6657, RFC 8098

Source of RFC: 822ext (app)

Errata ID: 507
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2003-10-04

Section 5.1.5 says:

      Date: Mon, 22 Mar 1994 13:34:51 +0000

It should say:

      Date: Tue, 22 Mar 1994 13:34:51 +0000 

Errata ID: 508
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Herman Meerlo
Date Reported: 2001-10-04

Appendix A states:

     discard-text := *(*text CRLF)

It should say:

     discard-text := *(*text CRLF) *text

Errata ID: 588
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2001-12-22

Section 5.2.2.2 says:

Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
Subject: Audio mail
Message-ID: <anotherid@foo.com>

It should say:

Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
Message-ID: <anotherid@foo.com>
Subject: Audio mail

Errata ID: 589
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2001-12-22

Section 5.2.3.7 says:

Content-Type: message/external-body;
              access-type=mail-server
              server="listserv@bogus.bitnet";
              expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"

It should say:

Content-Type: message/external-body;
              access-type=mail-server;
              server="listserv@bogus.bitnet";
              expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"

Notes:

Semicolons were missing.

Errata ID: 509
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Steve Bellovin
Date Reported: 2004-02-03

Section 9 says:

9.  Security Considerations

It should say:

8.  Security Considerations

Notes:

In the Table of Contents, the Security Considerations is listed to be in Section 8. However, in the text, both the Security Considerations and Authors' Addresses are in Section 9; there is no Section 8.

Errata ID: 510
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2001-12-22

Section 5.1.5 says:

undesireble 

seperate

It should say:

undesirable

separate

Notes:

Spelling errors.

Errata ID: 511
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lars Kasper
Date Reported: 2005-01-06
Verifier Name: Alexey Melnikov
Date Verified: 2009-08-29

Section 3 says:

    (2)   image -- image data.  "Image" requires a display device
          (such as a graphical display, a graphics printer, or a
          FAX machine) to view the information. An initial
          subtype is defined for the widely-used image format
          JPEG. .  subtypes are defined for two widely-used image
          formats, jpeg and gif.

It should say:

    (2)   image -- image data.  "Image" requires a display device
          (such as a graphical display, a graphics printer, or a
          FAX machine) to view the information. Subtypes are defined
          for two widely-used image formats, jpeg and gif.

Notes:

The sentence previous to the last should be deleted, as it is covered by the last sentence.

Errata ID: 6582
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: ojab
Date Reported: 2021-05-15
Verifier Name: RFC Editor
Date Verified: 2024-01-16

Section 4.1.4 says:

Unrecognized subtypes which also specify an unrecognized charset 
should be treated as "application/octet- stream".

It should say:

Unrecognized subtypes which also specify an unrecognized charset 
should be treated as "application/octet-stream".

Notes:

Extra space in "application/octet- stream"

Errata ID: 7341
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Viatrix
Date Reported: 2023-02-07
Verifier Name: RFC Editor
Date Verified: 2023-02-07

Section 5.2.3.7 says:

provided in the same format but via different accces mechanisms.

It should say:

provided in the same format but via different access mechanisms.

Notes:

"accces" is a typo

RFC 2047, "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", November 1996

Note: This RFC has been updated by RFC 2184, RFC 2231

Source of RFC: 822ext (app)

Errata ID: 504
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jose M. Cainzos
Date Reported: 2001-11-10

Section 5 says:

   (2) An 'encoded-word' may appear within a 'comment' delimited by "(" and
       ")", i.e., wherever a 'ctext' is allowed.  More precisely, the RFC
       822 ABNF definition for 'comment' is amended as follows:

       comment = "(" *(ctext / quoted-pair / comment / encoded-word) ")"

       A "Q"-encoded 'encoded-word' which appears in a 'comment' MUST NOT
       contain the characters "(", ")" or "
       'encoded-word' that appears in a 'comment' MUST be separated from
       any adjacent 'encoded-word' or 'ctext' by 'linear-white-space'.

It should say:

   (2) An 'encoded-word' may appear within a 'comment' delimited by "(" and
       ")", i.e., wherever a 'ctext' is allowed.  More precisely, the RFC
       822 ABNF definition for 'comment' is amended as follows:

       comment = "(" *(ctext / quoted-pair / comment / encoded-word) ")"

       A "Q"-encoded 'encoded-word' which appears in a 'comment' MUST NOT
       contain the characters "(", ")" or "\".  In addition, an
       'encoded-word' that appears in a 'comment' MUST be separated from
       any adjacent 'encoded-word' or 'ctext' by 'linear-white-space'.

Errata ID: 506
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2003-02-13

Section 2 says:

   especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "
               <"> / "/" / "[" / "]" / "?" / "." / "="

It should say:

   especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" /
               <"> / "/" / "[" / "]" / "?" / "." / "="

Notes:

Also reported by Jon Steinhart 2002-01-17, but corrected by Bruce Lilly.

RFC 2049, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", November 1996

Source of RFC: 822ext (app)

Errata ID: 3933
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Occil
Date Reported: 2014-03-26
Verifier Name: Barry Leiba
Date Verified: 2014-05-07

Section 2 says:

    (10)  Conforming user agents must be able to distinguish
          encoded-words from "text", "ctext", or "word"s,
          according to the rules in section 4, anytime they
          appear in appropriate places in message headers.

It should say:

   (10)  Conforming user agents must be able to distinguish
         encoded-words from "text", "ctext", or "word"s (see the
         grammar in Section 3.3 of [RFC822]), according to
         the recognition rules in Section 6 of [RFC2047],
         any time they appear in appropriate places in
         message headers.

Notes:

Section 4 of RFC 2049 was not the correct citation.

RFC 2060, "Internet Message Access Protocol - Version 4rev1", December 1996

Note: This RFC has been obsoleted by RFC 3501

Source of RFC: Legacy

Errata ID: 503
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mathieu Fenniak
Date Reported: 2002-05-28

Section 6.4.8 says:

   Example:    C: A999 UID FETCH 4827313:4828442 FLAGS
               S: * 23 FETCH (FLAGS (\Seen) UID 4827313)
               S: * 24 FETCH (FLAGS (\Seen) UID 4827943)
               S: * 25 FETCH (FLAGS (\Seen) UID 4828442)
               S: A999 UID FETCH completed

It should say:

   Example:    C: A999 UID FETCH 4827313:4828442 FLAGS
               S: * 23 FETCH (FLAGS (\Seen) UID 4827313)
               S: * 24 FETCH (FLAGS (\Seen) UID 4827943)
               S: * 25 FETCH (FLAGS (\Seen) UID 4828442)
               S: A999 OK UID FETCH completed

Notes:

A list of known errata can be found at: ftp://ftp.cac.washington.edu/mail/rfc2060-errata

RFC 2069, "An Extension to HTTP : Digest Access Authentication", January 1997

Note: This RFC has been obsoleted by RFC 2617

Source of RFC: http (app)

Errata ID: 749
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Frank Ellermann
Date Reported: 2005-02-06
Verifier Name: Alexey Melnikov
Date Verified: 2010-07-11

Section 2.4 says:

RfC 2069 (digest access authentication) chapter 2.4 is an example,
the userame is "Mufasa", the password is "CircleOfLife":

| username="Mufasa",
| realm="testrealm@host.com",
| nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
| uri="/dir/index.html",
| response="e966c932a9242554e42c8ee200cec7f6",
| opaque="5ccc069c403ebaf9f0171e9517f40e41"

The "respose" is MD5( MD5( A1 ) || ':' || nonce || ':' || MD5( A2 ))

MD5( A1 ) = MD5( username || ':' || realm || ':' || password )
          = MD5( "Mufasa:testrealm@host.com:CircleOfLife" )
          = "4945ecf42b1bb868634058a845bedde8"

MD5( A2 ) = MD5( Method || ':' || digest-uri-value )
          = MD5( "GET:/dir/index.html" )
          = "39aff3a2bab6126f332b942af96d3366"

This results in a response = "1949323746fe6a43ef61f9606e7febea"
instead of the shown value = "e966c932a9242554e42c8ee200cec7f6".

Quick reality check, the RFC 2617 example uses the same values
    username = "Mufasa"
    nonce    = "dcd98b7102dd2f0e8b11d0f600bfb0c093"
    realm    = "testrealm@host.com"
    A2       = "GET:/dir/index.html"
with a slightly different
    password = "Circle Of Life"
resulting in MD5( A1 ) = "939e7578ed9e3c518a452acee763bce9"

The "respose" is MD5( MD5( A1 ) || ':' || X || ':' || MD5( A2 ))
for X = "dcd98b7102dd2f0e8b11d0f600bfb0c093:00000001:0a4f113b:auth"
and here the response = "6629fae49393a05397450978507c4ef1" works as
expected.

It should say:

[not submitted]

Notes:

I've tried to contact two of the RFC 2069 authors about this issue,
but got no reply.

Alexey: note that this problem was addressed in RFC 2617.

RFC 2092, "Protocol Analysis for Triggered RIP", January 1997

Source of RFC: rip (rtg)

Errata ID: 502
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kwan Jong Yoo
Date Reported: 2004-03-30

Section 3.3. says:

   Triggered RIP will NOT fuction properly (and should NOT be used) if a
   routing information will be retained/advertised for an arbitrarily
   long period of time (until an update in the opposite direction fails
   to obtain a response).

It should say:

   Triggered RIP will NOT function properly (and should NOT be used) if a
   routing information will be retained/advertised for an arbitrarily
   long period of time (until an update in the opposite direction fails
   to obtain a response).

RFC 2100, "The Naming of Hosts", April 1997

Source of RFC: INDEPENDENT

Errata ID: 6162
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Toshio SARUTA
Date Reported: 2020-05-10
Verifier Name: Erik Kline
Date Verified: 2020-05-10

Throughout the document, when it says:

Like lothlorien, pothole, or kobyashi-maru,

It should say:

Like lothlorien, pothole, or kobayashi-maru,

Notes:

Missed "a".
Kobayashi-maru is the name of a starship in Star Trek.

RFC 2104, "HMAC: Keyed-Hashing for Message Authentication", February 1997

Note: This RFC has been updated by RFC 6151

Source of RFC: ipsec (sec)

Errata ID: 501
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Gregory Ogonowski
Date Reported: 2005-06-23

Section 9 says:

        MD5Update(&context, k_ipad, 64)      /* start with inner pad */

It should say:

        MD5Update(&context, k_ipad, 64);     /* start with inner pad */

Notes:

RFC 2119, "Key words for use in RFCs to Indicate Requirement Levels", March 1997

Note: This RFC has been updated by RFC 8174

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: gen

Errata ID: 493
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Davidson, Malcolm
Date Reported: 2001-05-31

Section 1 says:

2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
   definition is an absolute prohibition of the specification.

It should say:

2. MUST NOT   This phrase, or the phrase "SHALL NOT", means that the
   definition is an absolute prohibition of the specification.

Errata ID: 495
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Davidson, Malcolm
Date Reported: 2001-05-31

Section 1 says:

1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

It should say:

1. MUST   This word, or the terms "REQUIRED" or "SHALL", means that the
   definition is an absolute requirement of the specification.

Notes:

Errata ID: 496
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kurt Zeilenga
Date Reported: 2001-01-31

Section 6 says:

   In particular, they MUST only be used where it is actually required
   for interoperation or to limit behavior which has potential for
   causing harm (e.g., limiting retransmisssions)  For example, they
   must not be used to try to impose a particular method on
   implementors where the method is not required for interoperability.   

It should say:

   In particular, they MUST only be used where it is actually required
   for interoperation or to limit behavior which has potential for
   causing harm (e.g., limiting retransmissions).  For example, they
   must not be used to try to impose a particular method on
   implementors where the method is not required for interoperability.

Errata ID: 498
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Davidson, Malcolm
Date Reported: 2001-05-31

Section 1 says:

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

It should say:

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED", means that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

Errata ID: 500
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Davidson, Malcolm
Date Reported: 2001-05-31

Section 1 says:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

It should say:

3. SHOULD   This word, or the adjective "RECOMMENDED", means that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

Errata ID: 494
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Davidson, Malcolm
Date Reported: 2001-05-31
Verifier Name: RFC Editor
Date Verified: 2007-11-07

Section 6 says:

(e.g., limiting retransmisssions)

It should say:

(e.g., limiting retransmissions)

Errata ID: 499
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Anders Langmyr
Date Reported: 2006-01-09
Verifier Name: Peter Saint-Andre
Date Verified: 2011-11-15

Section Abstract says:

       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
       NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
       "OPTIONAL" in this document are to be interpreted as described in
       RFC 2119.

It should say:

       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
       NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 
       RECOMMENDED",  "MAY", and "OPTIONAL" in this document are to 
       be interpreted as described in RFC 2119.

Notes:

The phrase "NOT RECOMMENDED" is missing from this sentence.

Errata ID: 5101
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jim Tonti
Date Reported: 2017-08-29
Verifier Name: Warren Kumari
Date Verified: 2017-08-29

Section 5 says:

5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

It should say:

5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides).

Notes:

Full stop should appear outside the parentheses in the last sentence.

RFC 2127, "ISDN Management Information Base using SMIv2", March 1997

Source of RFC: isdnmib (int)

Errata ID: 1952
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Yigal Hachmon
Date Reported: 2009-12-01
Verifier Name: Brian Haberman
Date Verified: 2012-04-26

Section Conformance says:

isdnMibConformance OBJECT IDENTIFIER ::= { isdnMib 2 }

It should say:

isdnMibConformance OBJECT IDENTIFIER ::= { isdnMib 3 }

Notes:

Maybe this was already reported as Errata 491, which I couldn't read.
Anyhow

isdnMib 2 is already used as
isdnMibTrapPrefix OBJECT IDENTIFIER ::= { isdnMib 2 }

RFC 2131, "Dynamic Host Configuration Protocol", March 1997

Note: This RFC has been updated by RFC 3396, RFC 4361, RFC 5494, RFC 6842

Source of RFC: dhc (int)

Errata ID: 489
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Soohong Daniel Park
Date Reported: 2004-04-29

Section 3.1 number 5 says:

     The client times out and retransmits the DHCPREQUEST message if the
     client receives neither a DHCPACK or a DHCPNAK message.  
     ...
     If the client
     receives neither a DHCPACK or a DHCPNAK message after employing the
     retransmission algorithm, the client reverts to INIT state and
     restarts the initialization process. 

It should say:

     The client times out and retransmits the DHCPREQUEST message if the
     client receives neither a DHCPACK nor a DHCPNAK message.  
     ...
     If the client
     receives neither a DHCPACK nor a DHCPNAK message after employing the
     retransmission algorithm, the client reverts to INIT state and
     restarts the initialization process. 

Notes:

Errata ID: 490
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sreeni R. Nair
Date Reported: 2004-01-13

Section 4.1 says:

Normally, DHCP servers and BOOTP relay agents attempt to deliver
DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using
uicast delivery.

It should say:

Normally, DHCP servers and BOOTP relay agents attempt to deliver
DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using
unicast delivery.

Notes:

typo (uicast -> unicast). Updated 2013-06-05. Thanks to Carlos Prendes for the correction.

Errata ID: 7177
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Greg Skinner
Date Reported: 2022-10-22
Verifier Name: Erik Kline
Date Verified: 2022-10-22

Section 4.1 says:

If the server has received a message through a DHCP relay agent, the server SHOULD choose an address from the interface on which the message was recieved as the 'server identifier' (unless the server has other, better information on which to make its choice).

It should say:

If the server has received a message through a DHCP relay agent, the server SHOULD choose an address from the interface on which the message was received as the 'server identifier' (unless the server has other, better information on which to make its choice).

Notes:

spelling correction

s/recieved/received/

Errata ID: 7367
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eugene Adell
Date Reported: 2023-02-23
Verifier Name: RFC Editor
Date Verified: 2023-02-23

Section 4.1 says:

   The 'server identifier' field is used both to identify a DHCP server
   in a DHCP message and as a destination address from clients to
   servers.  A server with multiple network addresses MUST be prepared
   to to accept any of its network addresses as identifying that server
   in a DHCP message.

It should say:

   The 'server identifier' field is used both to identify a DHCP server
   in a DHCP message and as a destination address from clients to
   servers.  A server with multiple network addresses MUST be prepared
   to accept any of its network addresses as identifying that server in
   a DHCP message.

Notes:

redundant word
s/to to/to/

Errata ID: 7368
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Panayiotis Gavriil
Date Reported: 2023-02-24
Verifier Name: RFC Editor
Date Verified: 2023-02-24

Section 3.1 says:

DHCPNAK      -  Server to client indicating client's notion of network
                   address is incorrect (e.g., client has moved to new
                   subnet) or client's lease as expired

It should say:

DHCPNAK      -  Server to client indicating client's notion of network
                   address is incorrect (e.g., client has moved to new
                   subnet) or client's lease has expired

Notes:

Spelling: "as expired" -> "has expired". (The original might have been the intended spelling, but grammatically it would make more sense to write "has" instead of "as" with the verb "indicate".)

Errata ID: 7369
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Panayiotis Gavriil
Date Reported: 2023-02-24
Verifier Name: RFC Editor
Date Verified: 2023-02-24

Section 3.2 says:

  2. Servers with knowledge of the client's configuration parameters
      respond with a DHCPACK message to the client.  Servers SHOULD NOT
      check that the client's network address is already in use; the
      client may respond to ICMP Echo Request messages at this point.

                Server          Client          Server

                  v               v               v
                  |                |               |
                  |              Begins            |
                  |          initialization        |
                  |                |               |
                  |                /|\             |
                  |   _________ __/ | \__________  |
                  | /DHCPREQU EST  |  DHCPREQUEST\ |
                  |/               |              \|
                  |                |               |
               Locates             |            Locates
            configuration          |         configuration
                  |                |               |
                  |\               |              /|
                  | \              |  ___________/ |
                  |  \             | /  DHCPACK    |
                  |   \ _______    |/              |
                  |     DHCPACK\   |               |
                  |          Initialization        |
                  |             complete           |
                  |               \|               |
                  |                |               |
                  |           (Subsequent          |
                  |             DHCPACKS           |
                  |             ignored)           |
                  |                |               |
                  |                |               |
                  v                v               v

     Figure 4: Timeline diagram of messages exchanged between DHCP
               client and servers when reusing a previously allocated
               network address

It should say:

  2. Servers with knowledge of the client's configuration parameters
      respond with a DHCPACK message to the client.  Servers SHOULD NOT
      check that the client's network address is already in use; the
      client may respond to ICMP Echo Request messages at this point.

                Server          Client          Server

                  v               v               v
                  |               |               |
                  |             Begins            |
                  |         initialization        |
                  |               |               |
                  |              /|\              |
                  |   __________/ | \__________   |
                  | /DHCPREQUEST  |  DHCPREQUEST\ |
                  |/              |              \|
                  |               |               |
               Locates            |            Locates
            configuration         |         configuration
                  |               |               |
                  |\              |              /|
                  | \___________  |  ___________/ |
                  |    DHCPACK  \ | /  DHCPACK    |
                  |              \|/              |
                  |               |               |
                  |         Initialization        |
                  |            complete           |
                  |               |               |
                  |               |               |
                  |          (Subsequent          |
                  |            DHCPACKS           |
                  |            ignored)           |
                  |               |               |
                  |               |               |
                  v               v               v

     Figure 4: Timeline diagram of messages exchanged between DHCP
               client and servers when reusing a previously allocated
               network address

Notes:

Alignment in various places + removing space in the middle of a word ("DHCPREQU EST" -> "DHCPREQUEST")

RFC 2132, "DHCP Options and BOOTP Vendor Extensions", March 1997

Note: This RFC has been updated by RFC 3442, RFC 3942, RFC 4361, RFC 4833, RFC 5494

Source of RFC: dhc (int)

Errata ID: 486
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: George V. Neville-Neil
Date Reported: 2001-12-12

Section 9.6 says:

    Code   Len  Type
   +-----+-----+-----+
   |  53 |  1  | 1-9 |
   +-----+-----+-----+

It should say:

    Code   Len  Type
   +-----+-----+-----+
   |  53 |  1  | 1-8 |
   +-----+-----+-----+

Errata ID: 2305
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Richard Chen
Date Reported: 2010-06-17
Verifier Name: Brian Haberman
Date Verified: 2012-12-12

Section 3.10. says:

The code for the log server option is 8.

It should say:

The code for the cookie server option is 8.

Notes:

Copy error.

RFC 2136, "Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1997

Note: This RFC has been updated by RFC 3007, RFC 4035, RFC 4033, RFC 4034

Source of RFC: dnsind (int)

Errata ID: 4469
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Andrews
Date Reported: 2015-09-09
Verifier Name: Brian Haberman
Date Verified: 2015-09-14

Section 3.4.2.2 says:

   3.4.2.2. Any Update RR whose CLASS is the same as ZCLASS is added to
   the zone.  In case of duplicate RDATAs (which for SOA RRs is always
   the case, and for WKS RRs is the case if the ADDRESS and PROTOCOL
   fields both match), the Zone RR is replaced by Update RR.  If the
   TYPE is SOA and there is no Zone SOA RR, or the new SOA.SERIAL is
   lower (according to [RFC1982]) than or equal to the current Zone SOA
   RR's SOA.SERIAL, the Update RR is ignored.  In the case of a CNAME
   Update RR and a non-CNAME Zone RRset or vice versa, ignore the CNAME
   Update RR, otherwise replace the CNAME Zone RR with the CNAME Update
   RR.

It should say:

   3.4.2.2. Any Update RR whose CLASS is the same as ZCLASS is added to
   the zone.  In case of duplicate RDATAs (which for SOA RRs is always
   the case, and for WKS RRs is the case if the ADDRESS and PROTOCOL
   fields both match), the Zone RR is replaced by Update RR.  If the
   TYPE is SOA and there is no Zone SOA RR, or the new SOA.SERIAL is
   lower (according to [RFC1982]) than or equal to the current Zone SOA
   RR's SOA.SERIAL, the Update RR is ignored.  In the case of a CNAME
   Update RR and a non-CNAME Zone RRset or vice versa, ignore the
   Update RR, otherwise replace the CNAME Zone RR with the CNAME Update
   RR.

Notes:

In the vice versa case it it not a CNAME Update RR, just a plain Update RR. Removing the word "CNAME" make the sentence cover both cases as intended.

RFC 2141, "URN Syntax", May 1997

Note: This RFC has been obsoleted by RFC 8141

Source of RFC: urn (app)

Errata ID: 7594
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kim Hermansson
Date Reported: 2023-08-09
Verifier Name: RFC Editor
Date Verified: 2023-08-09

Section 2.3 says:

<reserved>    ::= '%" | "/" | "?" | "#"

It should say:

<reserved>    ::= "%" | "/" | "?" | "#"

Notes:

BNF syntax for percentage character was incorrect; used single quote instead of double quote.

RFC 2152, "UTF-7 A Mail-Safe Transformation Format of Unicode", May 1997

Source of RFC: Legacy
Area Assignment: app

Errata ID: 3982
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Occil
Date Reported: 2014-05-08
Verifier Name: Pete Resnick
Date Verified: 2014-06-04

Section Definitions says:

               Character   ASCII & Unicode Value (decimal)

                 [...]       [...]

                  '           96

It should say:

               Character   ASCII & Unicode Value (decimal)

                 [...]       [...]

                  `           96

Notes:

The wrong character is used in the left column: code point 96 corresponds to "Grave Accent", not "Apostrophe".

Errata ID: 862
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christian Aymon
Date Reported: 2006-05-16

In "UTF-7 Definition", it says:

Such characters
include control characters such as carriage returns and line
feeds; thus, a Unicode shifted sequence always terminates at the
of a line.

It should say:

Such characters
include control characters such as carriage returns and line
feeds; thus, a Unicode shifted sequence always terminates at the
end of a line.

Notes:

missing word

RFC 2154, "OSPF with Digital Signatures", June 1997

Source of RFC: Legacy

Errata ID: 2081
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vishwas Manral
Date Reported: 2010-03-19
Verifier Name: Ross Callon
Date Verified: 2010-03-19

Section 5 says:

Because of these properties of OSFP routing, an AS can
   contain signed and unsigned areas, and achieve a predictable level of
   authentication.

It should say:

Because of these properties of OSPF routing, an AS can
   contain signed and unsigned areas, and achieve a predictable level of
   authentication.

Notes:

s/OSFP/OSPF

RFC 2183, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", August 1997

Note: This RFC has been updated by RFC 2184, RFC 2231

Source of RFC: Legacy

Errata ID: 485
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2002-01-05

Section 2 says:

   NOTE ON PARAMETER VALUE LENGHTS: A short (length <= 78 characters)

It should say:

   NOTE ON PARAMETER VALUE LENGTHS: A short (length <= 78 characters)

Errata ID: 1457
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2008-06-20
Verifier Name: Lisa Dusseault
Date Verified: 2008-10-06

Section Boilerplate says:

Network Working Group                                          R. Troost
Request for Comments: 2183                           New Century Systems
Updates: 1806                                                  S. Dorner
Category: Standards Track                          QUALCOMM Incorporated
                                                        K. Moore, Editor
                                                 University of Tennessee
                                                             August 1997

It should say:

Network Working Group                                          R. Troost
Request for Comments: 2183                           New Century Systems
Obsoletes: 1806                                                S. Dorner
Category: Standards Track                          QUALCOMM Incorporated
                                                        K. Moore, Editor
                                                 University of Tennessee
                                                             August 1997

Notes:

RFC 2183 completely replaces RFC 1806, so it should say "obsoletes" instead of "updates".

Errata ID: 3847
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eric Reitmaier
Date Reported: 2013-12-23
Verifier Name: Barry Leiba
Date Verified: 2013-12-23

Section 3 says:

        Content-Type: image/jpeg
        Content-Disposition: attachment; filename=genome.jpeg;
          modification-date="Wed, 12 Feb 1997 16:29:51 -0500";
        Content-Description: a complete map of the human genome

It should say:

        Content-Type: image/jpeg
        Content-Disposition: attachment; filename=genome.jpeg;
          modification-date="Wed, 12 Feb 1997 16:29:51 -0500"
        Content-Description: a complete map of the human genome

Notes:

In section 2 it states:

disposition := "Content-Disposition" ":"
disposition-type
*(";" disposition-parm)

The semicolon should not be at the end of a header field.
And in the example there is a semicolon behind the disposition-parm "modification-date".

RFC 2184, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", August 1997

Note: This RFC has been obsoleted by RFC 2231

Source of RFC: Legacy
Area Assignment: app

Errata ID: 841
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Terje Braten
Date Reported: 2001-04-14
Verifier Name: Pete Resnick
Date Verified: 2011-05-13

Section 7 says:

   initial-section := "*1"

   other-sections := "*" (("2" / "3" / "4" / "5" /
                           "6" / "7" / "8" / "9") *DIGIT) /
                          ("1" 1*DIGIT))

It should say:

   initial-section := "*0"

   other-sections := "*" ("1" / "2" / "3" / "4" / "5" /
                          "6" / "7" / "8" / "9") *DIGIT)

Notes:

Corrected in RFC 2231

Errata ID: 2808
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Terje Braten
Date Reported: 2001-04-14
Verifier Name: Pete Resnick
Date Verified: 2011-05-13

Section 4.1 says:

   Content-Type: application/x-stuff
    title*1*=us-ascii'en'This%20is%20even%20more%20
    title*2*=%2A%2A%2Afun%2A%2A%2A%20
    title*3="isn't it!"

It should say:

   Content-Type: application/x-stuff
    title*0*=us-ascii'en'This%20is%20even%20more%20
    title*1*=%2A%2A%2Afun%2A%2A%2A%20
    title*2="isn't it!"

Notes:

Verifier Note: Corrected in RFC 2231

Errata ID: 484
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Terje Braten
Date Reported: 2001-04-14
Verifier Name: Alexey Melnikov
Date Verified: 2010-11-12

Section 7 says:

   This specification changes this ABNF to:

   encoded-word := "=?" charset ["*" language] "?" encoded-text "?="

It should say:

   This specification changes this ABNF to:

   encoded-word := "=?" charset ["*" language] "?" encoding "?"
                   encoded-text "?="

RFC 2192, "IMAP URL Scheme", September 1997

Note: This RFC has been obsoleted by RFC 5092

Source of RFC: Legacy

Errata ID: 483
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Chris Newman
Date Reported: 2005-02-09
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-18

Section 12 says:

     imessagelist     = enc_mailbox [ "?" enc_search ] [uidvalidity]

It should say:

     imessagelist     = enc_mailbox [uidvalidity] [ "?" enc_search ]

Notes:

Wrong order of fields

RFC 2196, "Site Security Handbook", September 1997

Source of RFC: ssh ()

Errata ID: 482
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: IETF Secretariat
Date Reported: 2004-10-13

On page 21, it says:

A firewall is any one of several mechanisms used to control and watch
access to and from a network for the purpose of protecting it.  A
firewall acts as a gateway through which all traffic to and from the
protected network and/or systems passes.  Firewalls help to place
limitations on the amount and type of communication that takes place
between the protected network and the another network (e.g., the
Internet, or another piece of the site's network).

It should say:

A firewall is any one of several mechanisms used to control and watch
access to and from a network for the purpose of protecting it.  A
firewall acts as a gateway through which all traffic to and from the
protected network and/or systems passes.  Firewalls help to place
limitations on the amount and type of communication that takes place
between the protected network and another network (e.g., the
Internet, or another piece of the site's network).

Notes:

removed extraneous "the".

Errata ID: 2167
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2010-04-21
Verifier Name: RFC Editor
Date Verified: 2011-12-01

Section 3.2.3.6 says:

   Some sites choose to co-locate FTP with a Web
   server, since the two protocols share common security considerations
   However, the the practice isn't recommended, especially when the FTP
   service allows the deposit of files (see section on WWW above). 

It should say:

   Some sites choose to co-locate FTP with a Web
   server, since the two protocols share common security considerations.
   However, this practice isn't recommended, especially when the FTP
   service allows the deposit of files (see section on WWW above).

Notes:

added a period after "considerations".

Errata ID: 2674
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alexandre Dulaunoy
Date Reported: 2010-12-19
Verifier Name: RFC Editor
Date Verified: 2011-12-01

Section 3.1.1 says:

   The plan should also address how incident will be handled.  Chapter 5
   provides an in-depth discussion of this topic, but it is important
   for each site to define classes of incidents and corresponding
   responses.  For example, sites with firewalls should set a threshold
   on the number of attempts made to foil the firewall before triggering
   a response?  Escallation levels should be defined for both attacks
   and responses.  Sites without firewalls will have to determine if a
   single attempt to connect to a host constitutes an incident? What
   about a systematic scan of systems?

It should say:

   The plan should also address how incident will be handled.  Chapter 5
   provides an in-depth discussion of this topic, but it is important
   for each site to define classes of incidents and corresponding
   responses.  For example, sites with firewalls should set a threshold
   on the number of attempts made to foil the firewall before triggering
   a response?  Escalation levels should be defined for both attacks
   and responses.  Sites without firewalls will have to determine if a
   single attempt to connect to a host constitutes an incident? What
   about a systematic scan of systems?

Notes:

Escallation -> Escalation

RFC 2202, "Test Cases for HMAC-MD5 and HMAC-SHA-1", September 1997

Source of RFC: Legacy
Area Assignment: sec

Errata ID: 480
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Deron Meranda
Date Reported: 2004-05-05

In the Appendix, it says:

           /**** Outter Digest ****/

           SHAInit(&octx) ;

           /* Pad the key for outter digest */

It should say:

           /**** Outer Digest ****/

           SHAInit(&octx) ;

           /* Pad the key for outer digest */

Notes:

Errata ID: 481
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kevin Springle
Date Reported: 2002-09-17

Section 3 says:

   test_case =     7
   key =           0xaa repeated 80 times
   key_len =       80
   data =          "Test Using Larger Than Block-Size Key and Larger
                   Than One Block-Size Data"
   data_len =      73
   digest =        0xe8e99d0f45237d786d6bbaa7965c7808bbff1a91
   data_len =      20
   digest =        0x4c1a03424b55e07fe7f27be1d58bb9324a9a5a04
   digest-96 =     0x4c1a03424b55e07fe7f27be1

   test_case =     6
   key =           0xaa repeated 80 times
   key_len =       80
   data =          "Test Using Larger Than Block-Size Key - Hash Key
   First"
   data_len =      54
   digest =        0xaa4ae5e15272d00e95705637ce8a3b55ed402112
   
   test_case =     7
   key =           0xaa repeated 80 times
   key_len =       80
   data =          "Test Using Larger Than Block-Size Key and Larger
                   Than One Block-Size Data"
   data_len =      73
   digest =        0xe8e99d0f45237d786d6bbaa7965c7808bbff1a91

It should say:

   test_case =     7
   key =           0xaa repeated 80 times
   key_len =       80
   data =          "Test Using Larger Than Block-Size Key and Larger
                   Than One Block-Size Data"
   data_len =      73
   digest =        0xe8e99d0f45237d786d6bbaa7965c7808bbff1a91

RFC 2203, "RPCSEC_GSS Protocol Specification", September 1997

Note: This RFC has been updated by RFC 5403

Source of RFC: oncrpc (tsv)

Errata ID: 4067
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Benjamin Kaduk
Date Reported: 2014-07-30
Verifier Name: Martin Stiemerling
Date Verified: 2015-04-17

Section 5.1 says:

The client should assume that the server supports RPCSEC_GSS_VERS_1
and issue a Context Creation message (as described in the section
RPCSEC_GSS_VERS_1, the RPC response will have a reply_stat of
MSG_DENIED, a rejection status of AUTH_ERROR, and an auth_stat of
AUTH_REJECTED_CRED.

It should say:

The client should assume that the server supports RPCSEC_GSS_VERS_1
and issue a Context Creation message (as described in the section
'Context Creation'). If the server does not support
RPCSEC_GSS_VERS_1, the RPC response will have a reply_stat of
MSG_DENIED, a rejection status of AUTH_ERROR, and an auth_stat of
AUTH_REJECTED_CRED.

Notes:

This line was somehow lost in the transition from draft-ietf-oncrpc-rpcsec_gss-04 to RFC 2203.

RFC 2217, "Telnet Com Port Control Option", October 1997

Source of RFC: Legacy
Area Assignment: sec

Errata ID: 4551
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marko Kohtala
Date Reported: 2015-12-04
Verifier Name: Roman Danyliw
Date Verified: 2022-05-10

Section 0 says:

Remove Service

It should say:

Remote Service

Notes:

Definition of Terms contains a simple spelling error. Illustration on next page shows correct spelling.

RFC 2229, "A Dictionary Server Protocol", October 1997

Source of RFC: Legacy

Errata ID: 1753
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Matthew Luckie
Date Reported: 2009-04-02
Verifier Name: Peter Saint-Andre
Date Verified: 2011-11-14

Section 2.2 says:

   dqstring    =  <"> *(dqtext/quoted-pair) <">
   dqtext      =  <any CHAR except <">, "\", and CTLs>
   sqstring    =  <'> *(dqtext/quoted-pair) <'>
   sqtext      =  <any CHAR except <'>, "\", and CTLs>
   quoted-pair =  "\" CHAR

It should say:

   dqstring    =  <"> *(dqtext/quoted-pair) <">
   dqtext      =  <any CHAR except <">, "\", and CTLs>
   sqstring    =  <'> *(sqtext/quoted-pair) <'>
   sqtext      =  <any CHAR except <'>, "\", and CTLs>
   quoted-pair =  "\" CHAR

Notes:

As it stands, the original specification would allow an sqstring of 'Bob's Garage' to be valid when that is not intended. [Approver Note: this appears to be a copy-and-paste error.]

Errata ID: 7153
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-10-12
Verifier Name: RFC Editor
Date Verified: 2022-10-12

Section 1.1 says:

   "OPTIONAL") means that his item is optional, and may be omitted

It should say:

   "OPTIONAL") means that this item is optional, and may be omitted

Notes:

Typo.

Errata ID: 7154
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-10-12
Verifier Name: RFC Editor
Date Verified: 2022-10-12

Section 3.2.2 says:

   For code 150, parameters 1 indicates the number of definitions

It should say:

   For code 150, parameter 1 indicates the number of definitions

Notes:

Wrong plural.

Errata ID: 7155
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-10-12
Verifier Name: RFC Editor
Date Verified: 2022-10-12

Section 3.2.2 says:

   definition has been retrieved, and parameter 3 is the the short

It should say:

   definition has been retrieved, and parameter 3 is the short

Notes:

Doubled "the".

Errata ID: 7156
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-10-12
Verifier Name: RFC Editor
Date Verified: 2022-10-12

Section 3.12.1 says:

   OPTION MIME is not set, then BASE64 encoding MUST be used.  If

   OPTION MIME is set, then BASE64 is the default encoding, as specified
   in section 3.10.1.

It should say:

   OPTION MIME is not set, then BASE64 encoding MUST be used.  If
   OPTION MIME is set, then BASE64 is the default encoding, as specified
   in section 3.10.1.

Notes:

Empty line.

Errata ID: 7157
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-10-12
Verifier Name: RFC Editor
Date Verified: 2022-10-12

Section 4 says:

   commands can improved DICT performance significantly, especially in

It should say:

   commands can improve DICT performance significantly, especially in

Notes:

The correct verb form would be "improve".

Errata ID: 7158
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-10-12
Verifier Name: RFC Editor
Date Verified: 2022-10-12

Section 4 says:

   definition cannot be retrieved, and the client should report and
   error or retry the command.  If the server is working, it may be able

It should say:

   definition cannot be retrieved, and the client should report an
   error or retry the command.  If the server is working, it may be able

Notes:

Typo.

Errata ID: 7159
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-10-12
Verifier Name: RFC Editor
Date Verified: 2022-10-12

Section 8 says:

   Theses are samples of the conversations that might be expected with

It should say:

   These are samples of the conversations that might be expected with

Notes:

Typo.

RFC 2231, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", November 1997

Source of RFC: Legacy

Errata ID: 476
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2003-02-09

Section 4 says:

   A single quote is used to separate the character set, language, and
   actual value information in the parameter value string, and an
   percent sign is used to flag octets encoded in hexadecimal.

It should say:

   A single quote is used to separate the character set, language, and
   actual value information in the parameter value string, and a
   percent sign is used to flag octets encoded in hexadecimal.

Errata ID: 477
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Shuhei KOBAYASHI
Date Reported: 2001-04-17

Section 7 says:

    extended-parameter := (extended-initial-name "="
                          extended-value) /
                         (extended-other-names "="
                          extended-other-values)

It should say:

    extended-parameter := (extended-initial-name "="
                          extended-initial-value) /
                         (extended-other-names "="
                          extended-other-values)

Errata ID: 478
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jeffrey Stedfast
Date Reported: 2001-11-24

Section 7 says:

   encoded-word := "=?" charset ["*" language] "?" encoded-text "?="

It should say:

   encoded-word := "=?" charset ["*" language] "?" encoding "?"
                   encoded-text "?="

Errata ID: 590
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Shuhei KOBAYASHI
Date Reported: 2001-04-17

Section 4.1 says:

   Content-Type: application/x-stuff
    title*0*=us-ascii'en'This%20is%20even%20more%20
    title*1*=%2A%2A%2Afun%2A%2A%2A%20
    title*2="isn't it!"

It should say:

   Content-Type: application/x-stuff;
    title*0*=us-ascii'en'This%20is%20even%20more%20;
    title*1*=%2A%2A%2Afun%2A%2A%2A%20;
    title*2="isn't it!"

Errata ID: 7326
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Joe Hildebrand
Date Reported: 2023-01-31
Verifier Name: RFC Editor
Date Verified: 2023-01-31

Section 7 says:

   other-sections := "*" ("1" / "2" / "3" / "4" / "5" /
                          "6" / "7" / "8" / "9") *DIGIT)

It should say:

   other-sections := "*" ("1" / "2" / "3" / "4" / "5" /
                          "6" / "7" / "8" / "9") *DIGIT

Notes:

There is an extra parenthesis at the end of the other-section rule which does not have a matching start paren. The intent of this rule is an asterisk followed by an integer without leading zeros.

Suggested resolution: hold for document update

RFC 2234, "Augmented BNF for Syntax Specifications: ABNF", November 1997

Note: This RFC has been obsoleted by RFC 4234

Source of RFC: drums (app)

Errata ID: 472
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tanaka Akira
Date Reported: 2001-11-19

Section 3.9 says:

3.9  ; Comment

   A semi-colon starts a comment that continues to the end of line.
   This is a simple way of including useful notes in parallel with the
   specifications.

        comment        =  ";" *(WSP / VCHAR) CRLF

It should say:

   char-val       =  DQUOTE *(%x20-21 / %x23-7E) DQUOTE
                          ; quoted string of SP and VCHAR
                             without DQUOTE

   prose-val      =  "<" *(%x20-3D / %x3F-7E) ">"
                          ; bracketed string of SP and VCHAR
                             without angles
                          ; prose description, to be used as
                             last resort

   CHAR           =  %x01-7F
                          ; any 7-bit US-ASCII character,
                             excluding NUL

Notes:

Should be:
char-val = DQUOTE *(%x20-21 / %x23-7E) DQUOTE
; quoted string of SP and VCHAR
; without DQUOTE

prose-val = "<" *(%x20-3D / %x3F-7E / c-wsp) ">"
; bracketed, possibly multiline string
; of SP and VCHAR without angles
; prose description, to be used as
; last resort

CHAR = %x01-7F
; any 7-bit US-ASCII character,
; excluding NUL

Errata ID: 474
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2005-04-11
Verifier Name: Alexey Melnikov
Date Verified: 2009-10-01

Section 4 says:

    prose-val      =  "<" *(%x20-3D / %x3F-7E / c-wsp) ">"
                           ; bracketed, possibly multiline string
                           ; of SP and VCHAR without angles
                           ; prose description, to be used as
                           ; last resort

It should say:

    prose-val      =  "<" *(%x20-3D / %x3F-7E) ">"
                           ; bracketed string of SP and VCHAR
                           ; without angles
                           ; prose description, to be used as
                           ; last resort

Notes:

Alexey: As per RFC 5234.

Errata ID: 475
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: El defeKto 2000
Date Reported: 2002-12-13

Section 3.7 says:

   That is, exactly <N> occurences of <element>.

It should say:

   That is, exactly <n> occurences of <element>.

Errata ID: 473

Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: RFC Editor
Date Reported: 2006-12-13
Report Text:

Note:   The following list of known errors in RFC 2234 is for
        historical reference only.  All known errors in RFC 2234 are
        believed to have been resolved in RFC 4234, which obsoletes RFC
        2234.

---

RFC 2236, "Internet Group Management Protocol, Version 2", November 1997

Note: This RFC has been updated by RFC 3376

Source of RFC: idmr (rtg)

Errata ID: 470
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jesse Norell
Date Reported: 2004-12-17
Verifier Name: Ross Callon
Date Verified: 2009-11-07

Section 2.1 says:

        These two messages are differentiated by the Group Address, as
        described in section 1.4 .  Membership Query messages are
        referred to simply as "Query" messages.

It should say:

        These two messages are differentiated by the Group Address, as
        described in section 2.4 .  Membership Query messages are
        referred to simply as "Query" messages.

Notes:

Errata ID: 471
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stephen Nadas (RL/TNT)
Date Reported: 2006-11-28
Verifier Name: Adrian Farrel
Date Verified: 2010-08-20

Section 2.2 says:

   Varying this setting allows IGMPv2 routers to tune the "leave
   latency" (the time between the moment the last host leaves a group
   and when the routing protocol is notified that there are no more
   members), as discussed in section 7.8.  It also allows tuning of the
   burstiness of IGMP traffic on a subnet, as discussed in section 7.3

It should say:

   Varying this setting allows IGMPv2 routers to tune the "leave
   latency" (the time between the moment the last host leaves a group
   and when the routing protocol is notified that there are no more
   members), as discussed in section 8.8.  It also allows tuning of the
   burstiness of IGMP traffic on a subnet, as discussed in section 8.3

Notes:

Section 2.2 2nd para refers to section 7.8 and 7.3 neither of which
exist. It should refer to 8.8 and 8.3.

RFC 2244, "ACAP -- Application Configuration Access Protocol", November 1997

Note: This RFC has been updated by RFC 6075

Source of RFC: acap (app)

Errata ID: 468
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Chris Newman
Date Reported: 2001-01-23

Section 8 says:

return-metadata = nil / string / value-list / acl

It should say:

return-metadata = nil / string / number / value-list / acl
                ;; number is only used for "size" metadata items
                ;; acl is only used for "acl" metadata items

Notes:

Bug/clarification in formal syntax (where it doesn't match examples).

Errata ID: 613
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Chris Newman
Date Reported: 2001-01-23

Section 8 says:

   acl                = "(" [acl-identrights *(SP acl-identrights)] ")"
                              *(SPACE acl-identrights)] ")"

It should say:

   acl                = "(" [acl-identrights *(SP acl-identrights)] ")"

Errata ID: 614
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Chris Newman
Date Reported: 2001-01-23

Section 8 says:

[Formal syntax for UPDATECONTEXT was missing.] 

It should say:

command-updatectx  = "UPDATECONTEXT" 1*(SP context)

Errata ID: 615
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Chris Newman
Date Reported: 2001-01-23

Section 6.6.2 says:

   Example:    C: Z4S9 DELETEDSINCE "/folder/site/" 19951205103412
               S: Z4S9 DELETED "blurdybloop"
               S: Z4S9 DELETED "anteaters"
               S: Z4S9 OK "DELETEDSINCE completed"
               C: Z4U3 DELETEDSINCE "/folder/site/" 19951009040854
               S: Z4U3 NO (TOOOLD) "Don't have that information"

It should say:

   Example:    C: Z4S9 DELETEDSINCE "/folder/site/" "19951205103412"
               S: Z4S9 DELETED "blurdybloop"
               S: Z4S9 DELETED "anteaters"
               S: Z4S9 OK "DELETEDSINCE completed"
               C: Z4U3 DELETEDSINCE "/folder/site/" "19951009040854"
               S: Z4U3 NO (TOOOLD) "Don't have that information"
 

Notes:

Fix DELETEDSINCE example to include quotes around timestamps

Errata ID: 616

Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Chris Newman
Date Reported: 2001-01-23
Report Text:

"count" metadata-type is not documented in prose.  Will be removed in next revision.

---

Errata ID: 617
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Chris Newman
Date Reported: 2001-01-23

Section 8 says:

command-lang       = "LANG" *(SP lang-tag)

It should say:

command-lang       = "LANG" 1*(SP lang-tag)

Notes:

Formal syntax for LANG command didn't require at least one language tag. Since it doesn't make sense to change the language to an unspecified value, the ABNF needs to be changed.

Errata ID: 619
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Chris Newman
Date Reported: 2001-01-23

Section 6.4.5. says:

    C: A049 SEARCH "/addressbook/~/public" RETURN ("addressbook.Alias"
           "addressbook.Email") MAKECONTEXT ENUMERATE "blob" LIMIT 100 1
           SORT ("addressbook.Alias" "i;octet") NOT EQUAL
           "addressbook.Email" NIL

It should say:

    C: A049 SEARCH "/addressbook/~/public" RETURN ("addressbook.Alias"
           "addressbook.Email") MAKECONTEXT ENUMERATE "blob" LIMIT 100 1
           SORT ("addressbook.Alias" "i;octet") NOT EQUAL
           "addressbook.Email" "i;octet" NIL

Notes:

One SEARCH example is missing comparator in EQUAL statement.

Errata ID: 620

Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Chris Newman
Date Reported: 2001-01-23
Report Text:

Need to use entry-path on notifications when DEPTH > 1 is specified.

---

Errata ID: 621

Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Chris Newman
Date Reported: 2001-01-23
Report Text:

Note explicitly that client commands must be transmitted in full
before starting a new command. This includes literals and the
AUTHENTICATE exchange.

---

Errata ID: 622

Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Chris Newman
Date Reported: 2001-01-23
Report Text:

Note that "revocation of rights" is also know as "negative rights".

---

Errata ID: 623
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Chris Newman
Date Reported: 2001-01-23

Section 2.6.1. says:

An atom consists of one to 1024 non-special characters.  It must
begin with a letter.  Atoms are used for protocol keywords.

Notes:

Need to define the term "non-special" as equivalent to the syntax for "ATOM-CHAR".

Errata ID: 624
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Chris Newman
Date Reported: 2001-01-23

Section 2.6.2. says:

A number consists of one or more digit characters, and represents a
numeric value.  Numbers are restricted to the range of an unsigned
32-bit integer: 0 < number < 4,294,967,296.

Notes:

Permit number to include 0 to match formal syntax.

Errata ID: 625
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Chris Newman
Date Reported: 2001-01-23

Section 1.5. says:

   UTC  Universal Coordinated Time as maintained by the Bureau
        International des Poids et Mesures (BIPM).

Notes:

"Universal Coordinated Time" should be "Coordinated Universal Time".

Errata ID: 626
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Chris Newman
Date Reported: 2001-01-23

Section 3.5. says:

An ACL is represented by a multi-value with each value containing an 
identifier followed by a tab character followed by the rights. 

Notes:

This is incorrect and should be deleted from the document. The formal syntax in errata 1 is normative.

RFC 2252, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", December 1997

Note: This RFC has been obsoleted by RFC 4510, RFC 4517, RFC 4523, RFC 4512

Note: This RFC has been updated by RFC 3377

Source of RFC: asid (app)

Errata ID: 467
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Wahl
Date Reported: 2003-10-15

Section 6.33 says:

        ruleidentifiers = ruleidentifier |

It should say:

        ruleidentifiers = ruleidentifier /

Notes:

Errata ID: 591
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Wahl
Date Reported: 2003-10-15

Section 4.2 says:

           [ "EQUALITY" woid              ; Matching Rule name
           [ "ORDERING" woid              ; Matching Rule name

It should say:

           [ "EQUALITY" woid ]            ; Matching Rule name
           [ "ORDERING" woid ]            ; Matching Rule name

RFC 2254, "The String Representation of LDAP Search Filters", December 1997

Note: This RFC has been obsoleted by RFC 4510, RFC 4515

Note: This RFC has been updated by RFC 3377

Source of RFC: asid (app)

Errata ID: 466
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Charles Bates
Date Reported: 2002-10-30

Section 4 says:

   greater = ">="

It should say:

   greater than or equal = ">="

RFC 2268, "A Description of the RC2(r) Encryption Algorithm", March 1998

Source of RFC: Legacy

Errata ID: 465
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Simon Josefsson
Date Reported: 2001-10-17

Section 6 says:

   RC2Version ::= INTEGER -- 1-1024

   RC2 in CBC mode has two parameters: an 8-byte initialization vector
   (IV) and a version number in the range 1-1024 which specifies in a
   roundabout manner the number of effective key bits to be used for
   the RC2 encryption/decryption.

It should say:

   RC2Version ::= INTEGER -- 0-1024

   RC2 in CBC mode has two parameters: an 8-byte initialization vector
   (IV) and a version number in the range 0-1024 which specifies in a
   roundabout manner the number of effective key bits to be used for
   the RC2 encryption/decryption.

RFC 2281, "Cisco Hot Standby Router Protocol (HSRP)", March 1998

Source of RFC: Legacy

Errata ID: 464

Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bob Braden
Date Reported: 2003-05-22
Report Text:

Section 2, "Conditions of Use" was mistakenly included in the
document and is incorrect.

Current information on ownership claims for protocols documented
in RFCs is available from http://www.ietf.org/ietf/IPR.

---

RFC 2286, "Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128", February 1998

Source of RFC: Legacy

Errata ID: 463
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kevin Springle
Date Reported: 2002-09-17

In the Appendix:

/* The HMAC_SHA1 transform looks like:

It should say:

/* The HMAC_RMD160 transform looks like:

 

Errata ID: 627
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kevin Springle
Date Reported: 2002-09-17

In the Appendix:

    /* if key is longer than 64 bytes reset it to key=SHA1(key) */

It should say:

   /* if key is longer than 64 bytes reset it to key=RMD160(key) */

Notes:

RFC 2308, "Negative Caching of DNS Queries (DNS NCACHE)", March 1998

Note: This RFC has been updated by RFC 4035, RFC 4033, RFC 4034, RFC 6604, RFC 8020, RFC 8499, RFC 9499, RFC 9520

Source of RFC: dnsind (int)

Errata ID: 461
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hideshi Enokihara
Date Reported: 2006-02-01
Verifier Name: Brian Haberman
Date Verified: 2012-05-01

Section 7.2 says:

7.2 Dead / Unreachable Server (OPTIONAL)

   Dead / Unreachable servers are servers that fail to respond in any
   way to a query or where the transport layer has provided an
   indication that the server does not exist or is unreachable.  A
   server may be deemed to be dead or unreachable if it has not
   responded to an outstanding query within 120 seconds.

   Examples of transport layer indications are:

      ICMP error messages indicating host, net or port unreachable.
      TCP resets
      IP stack error messages providing similar indications to those above.

   A server MAY cache a dead server indication.  If it does so it MUST
   NOT be deemed dead for longer than five (5) minutes.  The indication
   MUST be stored against query tuple <query name, type, class, server
   IP address> unless there was a transport layer indication that the
   server does not exist, in which case it applies to all queries to
   that specific IP address.

It should say:

7.2 Dead / Unreachable Server (OPTIONAL)

   Dead / Unreachable servers are servers that fail to respond in any
   way to a query or where the transport layer has provided an
   indication that the server does not exist or is unreachable.  A
   server may be deemed to be dead or unreachable if it has not
   responded to an outstanding query within 120 seconds.

   Examples of transport layer indications are:

      ICMP error messages indicating host, net or port unreachable.
      TCP resets
      IP stack error messages providing similar indications to those above.

   A resolver MAY cache a dead server indication.  If it does so it MUST
   NOT be deemed dead for longer than five (5) minutes.  The indication
   MUST be stored against query tuple <query name, type, class, server
   IP address> unless there was a transport layer indication that the
   server does not exist, in which case it applies to all queries to
   that specific IP address.

Notes:

Last sentence says, "A server MAY cache a dead server indication.".
But, this "server" is typo, I think.
This "server" should be "resolver" because section 7.1's last sentence uses "resolver".

Errata ID: 4489
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Wes Hardaker
Date Reported: 2015-09-29
Verifier Name: Brian Haberman
Date Verified: 2015-10-14

In the References

It should say:

ADD:

[RFC2136]  P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, "Dynamic
           Updates in the Domain Name System (DNS UPDATE)", 
           RFC 2136, April 1997.

-------

OR:  define SERVFAIL inside of the terminology section (section 1):

"SERVFAIL" - a name for the "Server failure" (2) RCODE described in
[RFC1035 Section 4.1.1].

Notes:

Section 2.1.1 uses the term SERVFAIL to reference DNS RCODE 2, but this term isn't defined in the document nor in the referenced documents. It's first defined in 2136 and thus the two options available are to either add a reference to 2136 or to add a definition of SERVFAIL to the document in the terminology section.

RFC 2319, "Ukrainian Character Set KOI8-U", April 1998

Source of RFC: INDEPENDENT

Errata ID: 4641
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Dmitry Kohmanyuk
Date Reported: 2016-03-18
Verifier Name: Nevil Brownlee
Date Verified: 2017-07-20

Section Appendix A says:

    180       B4      U0403      CYRILLIC CAPITAL LETTER UKRAINIAN IE

It should say:

    180       B4      U0404      CYRILLIC CAPITAL LETTER UKRAINIAN IE

Notes:

Typo in Unicode code point number (main text of RFC has proper number 0404, but Appendix A has a typo: 0403).

RFC 2322, "Management of IP numbers by peg-dhcp", April 1998

Source of RFC: INDEPENDENT

Errata ID: 5213
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Junxiao Shi
Date Reported: 2017-12-23
Verifier Name: RFC Editor
Date Verified: 2024-01-16

The Issuing IP-numbers section says:

   If someone could apply for a networkrange, and he net-extension isn't
   used, coat-hangers can be prepared with sets of pegs attached to
   them.

It should say:

   If someone could apply for a networkrange, and the net-extension
   isn't used, coat-hangers can be prepared with sets of pegs attached
   to them.

Notes:

typo “he”

RFC 2324, "Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)", April 1998

Note: This RFC has been updated by RFC 7168

Source of RFC: INDEPENDENT

Errata ID: 682
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Andrew Cook
Date Reported: 2002-11-20
Verifier Name: RFC Editor
Date Verified: 2011-10-28

Section 2.1.1 says:

Content-Type set to "application/coffee-pot-command".

It should say:

Content-Type set to "message/coffeepot".

Notes:

There is a discrepancy in RFC2324 regarding the content type for HTCPCP
requests. In section 2.1.1, the MIME type is
"application/coffee-pot-command", while in section 4 the MIME type is
"message/coffepot".

--VERIFIER NOTE--
This change will make section 2.1.1 consistent with section 4.

Errata ID: 3492
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Giles Saunders
Date Reported: 2013-02-21
Verifier Name: Barry Leiba
Date Verified: 2013-02-21

Section 3 says:

               | "caf%C3%E8"                ; Catalan, French, Galician

It should say:

               | "caf%C3%E9"                ; Catalan, French, Galician

Notes:

This error was originally reported by Larry Masinter in 2005.

=============== Verifier Notes ===============
OK, I feel really silly verifying errata on a joke RFC, but......
=========================================

Errata ID: 5981
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nick Harper
Date Reported: 2020-02-12
Verifier Name: Barry Leiba
Date Verified: 2020-03-11

Section 2.2.2.1 says:

       Accept-Additions = "Accept-Additions" ":"
                          #( addition-range [ accept-params ] )

        addition-type   = ( "*"
                          | milk-type
                          | syrup-type
                          | sweetener-type
                          | spice-type
                          | alcohol-type
                          ) *( ";" parameter )

It should say:

       Accept-Additions = "Accept-Additions" ":"
                          #( addition-type [ accept-params ] )

        addition-type   = ( "*"
                          | milk-type
                          | syrup-type
                          | sweetener-type
                          | spice-type
                          | alcohol-type
                          ) *( ";" parameter )

Notes:

The Accept-Additions rule references a non-existent addition-range rule, and the addition-type rule was not referenced anywhere. I assume that addition-range was supposed to be addition-type.

----- Verifier notes -----
Verified by Adrian Farrel, as Independent Stream Editor.

Errata ID: 4837
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ignasi Cavero
Date Reported: 2016-10-19
Verifier Name: RFC Editor
Date Verified: 2017-07-20

Section 9 says:

[RFC2235] Zakon, R., "Hobbes' Internet Timeline", FYI 32, RFC 2230,
   November 1997.  See also

It should say:

[RFC2235] Zakon, R., "Hobbes' Internet Timeline", FYI 32, RFC 2235,
   November 1997.  See also

Notes:

The reference entry to RFC 2235 contains the wrong RFC number.

Errata ID: 5916
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Benj Azose
Date Reported: 2019-11-22
Verifier Name: Barry Leiba
Date Verified: 2019-11-23

Section 9 says:

[SAFE] K. Holtman. "The Safe Response Header Field", September 1997.

It should say:

[SAFE] K. Holtman. "The Safe Response Header Field", RFC 2310, April 1998.

Notes:

It looks like The Safe Response Header Field was accepted in the same month that this RFC was issued.

===== Verifier notes =====
Ah, but not on the same *day*, it must be noted.

Errata ID: 7354
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Drew DeVault
Date Reported: 2023-02-15
Verifier Name: RFC Editor
Date Verified: 2023-02-15

Section 6 says:

   The traditional technique [CAM] was to attach a frame-grabber to a
   video camera, and feed the images to a web server. This was an
   appropriate application of ATM networks. In this coffee pot
   installation, the Trojan Room of Cambridge University laboratories
   was used to give a web interface to monitor a common coffee pot.  of
   us involved in related research and, being poor, impoverished
   academics, we only had one coffee filter machine between us, which
   lived in the corridor just outside the Trojan Room. However, being
   highly dedicated and hard-working academics, we got through a lot of
   coffee, and when a fresh pot was brewed, it often didn't last long.

It should say:

   The traditional technique [CAM] was to attach a frame-grabber to a
   video camera, and feed the images to a web server. This was an
   appropriate application of ATM networks. In this coffee pot
   installation, the Trojan Room of Cambridge University laboratories
   was used to give a web interface to monitor a common coffee pot.  Of
   us involved in related research and, being poor, impoverished
   academics, we only had one coffee filter machine between us, which
   lived in the corridor just outside the Trojan Room. However, being
   highly dedicated and hard-working academics, we got through a lot of
   coffee, and when a fresh pot was brewed, it often didn't last long.

Notes:

Correct lowercase letter at start of sentence

Errata ID: 7847
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kayla Coyote
Date Reported: 2024-03-11
Verifier Name: RFC Editor
Date Verified: 2024-03-13

Section 3 says:

               | "k%C3%A1va                 ; Czech

It should say:

               | "k%C3%A1va"                ; Czech

Notes:

Missing end-quote on Czech language coffee scheme name.

RFC 2325, "Definitions of Managed Objects for Drip-Type Heated Beverage Hardware Devices using SMIv2", April 1998

Source of RFC: INDEPENDENT

Errata ID: 3993
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jack Lawson
Date Reported: 2014-05-20
Verifier Name: Nevil Brownlee (ISE)
Date Verified: 2014-06-03

Section 4 says:

   potType OBJECT-TYPE
        SYNTAX     INTEGER {
           automatic-drip(1),
           percolator(2),
           french-press(3),
           espresso(4),
           }
        MAX-ACCESS read-write
        STATUS current
        DESCRIPTION
                "The brew type of the coffee pot."
        ::= { coffee 3 }

It should say:

   potType OBJECT-TYPE
        SYNTAX     INTEGER {
           automatic-drip(1),
           percolator(2),
           french-press(3),
           espresso(4),
           }
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
                "The brew type of the coffee pot."
        ::= { coffee 3 }

Notes:

potName and potCapacity are read-only, as name and capacity will not change after instantiation; type should be as well, as potType will not change over time (reincarnation as a separate pot would constitute a new instance.) potLocation should remain read-write, as a pot may change locations.

RFC 2327, "SDP: Session Description Protocol", April 1998

Note: This RFC has been obsoleted by RFC 4566

Note: This RFC has been updated by RFC 3266

Source of RFC: mmusic (rai)

Errata ID: 459
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Not recorded
Date Reported: 2000-12-31

In the document, the following characters should be replaced with corrected text.

       '|' should be  '/'
       '"""' and '"' should be 'DQUOTE'
       '0x01..0x09'  should be '%x01-09'

Notes:

The date reported was not recorded. The estimate is during 2000.

RFC 2328, "OSPF Version 2", April 1998

Note: This RFC has been updated by RFC 5709, RFC 6549, RFC 6845, RFC 6860, RFC 7474, RFC 8042, RFC 9355, RFC 9454

Source of RFC: ospf (rtg)

Errata ID: 2953
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Joel Gannett
Date Reported: 2011-08-31
Verifier Name: Stewart Bryant
Date Verified: 2011-09-02

Section 3.4 says:

                   Destination   RT3 adv.   RT4 adv.
                   _________________________________
                   Ia,Ib         20         27
                   N6            16         15
                   N7            20         19
                   N8            18         18
                   N9-N11,H1     29         36
                   _________________________________
                   RT5           14         8
                   RT7           20         14

              Table 6: Destinations advertised into Area 1
                        by Routers RT3 and RT4.

It should say:

                   Destination   RT3 adv.   RT4 adv.
                   _________________________________
                   Ia,Ib         20         27
                   N6            16         15
                   N7            20         19
                   N8            18         25
                   N9-N11,H1     29         36
                   _________________________________
                   RT5           14         8
                   RT7           20         14

              Table 6: Destinations advertised into Area 1
                        by Routers RT3 and RT4.

Notes:

The distance from RT4 to N8 should be changed from 18 to 25. Unless there is a virtual link between RT7 and RT10, the shortest path from RT4 to N8 is 25, not 18. Although a virtual link from RT7 and RT10 is discussed in the last paragraph of Section 3.4, it is not assume part of the network design. Moreover, this change is needed to make the N9-N11,H1 row consistent with the N8 row, as each entry in the N9-N11,H1 row must be 11 greater than the same-column entry in the N8 row.

Errata ID: 3746
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ramakrishna DTV
Date Reported: 2013-10-09
Verifier Name: Stewart Bryant
Date Verified: 2013-10-10

Throughout the document, when it says:

*. Section 3.3. (Classification of routers) says:

        AS boundary routers
            A router that exchanges routing information with routers
            belonging to other Autonomous Systems.  Such a router
            advertises AS external routing information throughout the
            Autonomous System.  The paths to each AS boundary router are
            known by every router in the AS.  This classification is
            completely independent of the previous classifications: AS
            boundary routers may be internal or area border routers, and
            may or may not participate in the backbone.

*. Section 10.6 (Receiving Database Description Packets) says:

	      When the router accepts a received Database Description Packet
        as the next in sequence the packet contents are processed as
        follows.  For each LSA listed, the LSA's LS type is checked for
        validity.  If the LS type is unknown (e.g., not one of the LS
        types 1-5 defined by this specification), or if this is an AS-
        external-LSA (LS type = 5) and the neighbor is associated with a
        stub area, generate the neighbor event SeqNumberMismatch and
        stop processing the packet.

*. Section 13. (The Flooding Procedure) says:

    (3) Else if this is an AS-external-LSA (LS type = 5), and the area
        has been configured as a stub area, discard the LSA and get the
        next one from the Link State Update Packet.  AS-external-LSAs
        are not flooded into/throughout stub areas (see Section 3.6).

    (4) Else if the LSA's LS age is equal to MaxAge, and there is
        currently no instance of the LSA in the router's link state
        database, and none of router's neighbors are in states Exchange

It should say:

*. Section 3.3. (Classification of routers) should say:

        AS boundary routers
            A router that exchanges routing information with routers
            belonging to other Autonomous Systems.  Such a router
            advertises AS external routing information throughout the
            Autonomous System.  The paths to each AS boundary router are
            known by every router in the AS (except stub areas).  This
            classification is
            completely independent of the previous classifications: AS
            boundary routers may be internal or area border routers, and
            may or may not participate in the backbone.

*. Section 10.6 (Receiving Database Description Packets) should say:

	      When the router accepts a received Database Description Packet
        as the next in sequence the packet contents are processed as
        follows.  For each LSA listed, the LSA's LS type is checked for
        validity.  If the LS type is unknown (e.g., not one of the LS
        types 1-5 defined by this specification), or if this is an AS-
        external-LSA (LS type = 5) and the neighbor is associated with a
        stub area, or if this is a type-4 summary LSA and the neighbor
		is associated with a stub area, generate the neighbor event
        SeqNumberMismatch and stop processing the packet.

*. Section 13. (The Flooding Procedure) should say:

There should be an additional step in between steps 3 and 4  in
Section 13. The additional step below is denoted 3.5:

    (3) Else if this is an AS-external-LSA (LS type = 5), and the area
        has been configured as a stub area, discard the LSA and get the
        next one from the Link State Update Packet.  AS-external-LSAs
        are not flooded into/throughout stub areas (see Section 3.6).

    (3.5) Else if this is a type-4 Summary LSA (LS type = 4), and the
        area has been configured as a stub area, discard the LSA and get
        the next one from the Link State Update Packet.  Type-4 Summary
        LSAs are not flooded into/throughout stub areas.

    (4) Else if the LSA's LS age is equal to MaxAge, and there is
        currently no instance of the LSA in the router's link state
        database, and none of router's neighbors are in states Exchange

Notes:

This whole note is regarding stub areas.

RFC 2328 is already consistent with respect to AS-external-LSAs
(LS type =5). The RFC explicitly indicates that they should be neither
sent nor received in stub areas.

But RFC 2328 seems to have some omissions with respect to type-4
Summary LSA (LS type = 4). The RFC explicitly indicates that these
LSAs should never be sent in stub areas. But it does not mention what
should be done if these LSAs are received in stub areas.

The above updates try to remedy this omission.

If the neighbor is associated with a stub area, then we should never
receive a type-4 summary LSA from that neighbor. Here are the relevant
quotes from the RFC:

Section 12.4.3.1.(Originating summary-LSAs into stub areas):

"As specified in Section 12.4.3, Type 4 summary-LSAs
(ASBR-summary-LSAs) are never originated into stub
areas."

Section 4.2. (AS external routes):

"To utilize external routing information, the path to all routers
advertising external information must be known throughout the AS
(excepting the stub areas). For that reason, the locations of
these AS boundary routers are summarized by the (non-stub) area
border routers."


This is an omission from RFC 2328.

http://www.ietf.org/mail-archive/web/ospf/current/msg06720.html

Errata ID: 3974
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mike Dubrovsky
Date Reported: 2014-04-24
Verifier Name: Alia Atlas
Date Verified: 2014-05-12

Section 13 says:

    (6) Else, if there is an instance of the LSA on the sending
        neighbor's Link state request list, an error has occurred in the
        Database Exchange process.  In this case, restart the Database
        Exchange process by generating the neighbor event BadLSReq for
        the sending neighbor and stop processing the Link State Update
        packet.

    (7) Else, if the received LSA is the same instance as the database
        copy (i.e., neither one is more recent) the following two steps
        should be performed:

        (a) If the LSA is listed in the Link state retransmission list
            for the receiving adjacency, the router itself is expecting
            an acknowledgment for this LSA.  The router should treat the
            received LSA as an acknowledgment by removing the LSA from
            the Link state retransmission list.  This is termed an
            "implied acknowledgment".  Its occurrence should be noted
            for later use by the acknowledgment process (Section 13.5).

        (b) Possibly acknowledge the receipt of the LSA by sending a
            Link State Acknowledgment packet back out the receiving
            interface.  This is explained below in Section 13.5.

It should say:

    (6) Else, if the received LSA is the same instance as the database
        copy (i.e., neither one is more recent) the following two steps
        should be performed:

        (a) If the LSA is listed in the Link state retransmission list
            for the receiving adjacency, the router itself is expecting
            an acknowledgment for this LSA.  The router should treat the
            received LSA as an acknowledgment by removing the LSA from
            the Link state retransmission list.  This is termed an
            "implied acknowledgment".  Its occurrence should be noted
            for later use by the acknowledgment process (Section 13.5).

        (b) Possibly acknowledge the receipt of the LSA by sending a
            Link State Acknowledgment packet back out the receiving
            interface.  This is explained below in Section 13.5.

    (7) Else, if there is an instance of the LSA on the sending
        neighbor's Link state request list, an error has occurred in the
        Database Exchange process.  In this case, restart the Database
        Exchange process by generating the neighbor event BadLSReq for
        the sending neighbor and stop processing the Link State Update
        packet.

Notes:

The problem arises when the routing domain has two instances of LSA
with the same sequence number and the same checksum,
but with an age difference bigger than MaxAgeDiff.

The above could take place in multiple scenarios. Here are two examples:

1) There is a demand circuit somewhere in the routing domain
2) The router lost its ASBR status and therefore flushed the self-originated Type 5 LSAs
but later on gained the ASBR status back and re-originated Type 5.
If the network was partitioned, each partition can have two instances of LSA
with an age difference bigger than MaxAgeDiff.

The two instances of LSA can temporarily prevent the adjacency formation.

Consider the example below:


Topology
========


RT1 ----- RT2

Initial state:
==============
The physical link between RT1 and R2 just came up
The routers are about to form ospf adjacency.

Initial link-state databases:
=============================
R1 ospf database has LSA 10.0.0.1 age 910 seq # 0x80000001
R2 ospf database has the same LSA 10.0.0.1 age 9 seq # 0x80000001

RT1 Event Sequence:
===============

RT1 is starting to form adjacency with RT2.

1) During the Database Exchange, RT2's LSA instance is more recent because of more than 900 (MaxAgeDiff) seconds age difference (section 13.1 of RFC 2328).
2) So RT1 requests the LSA
3) RT2 sends the LSA after incrementing the age by 1 (InfTransDelay).
4) When the LSA instance arrives to RT1, it is identical (the difference is exactly 900 seconds now).

So RT1 aborts Loading according to step (6) of section 13.


Solution:
=========

Swap steps (6) and (7) of section 13.

Acee Lindem adds:
"This situation comes into play when a router views an LSA as being
more recent when the LSA is requested (via Link-State Request) but as the
same instance when the LSA is actually received."

Errata ID: 4022
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexander Okonnikov
Date Reported: 2014-06-23
Verifier Name: Alia Atlas
Date Verified: 2014-06-24

Section 10.5 says:

When receiving an Hello Packet from a neighbor on a broadcast,
Point-to-MultiPoint or NBMA network, set the neighbor
structure's Neighbor ID equal to the Router ID found in the
packet's OSPF header. For these network types, the neighbor
structure's Router Priority field, Neighbor's Designated Router
field, and Neighbor's Backup Designated Router field are also
set equal to the corresponding fields found in the received
Hello Packet; changes in these fields should be noted for
possible use in the steps below. When receiving an Hello on a
point-to-point network (but not on a virtual link) set the
neighbor structure's Neighbor IP address to the packet's IP
source address.

It should say:

When receiving an Hello Packet from a neighbor on a broadcast,
Point-to-MultiPoint or NBMA network, set the neighbor
structure's Neighbor ID equal to the Router ID found in the
packet's OSPF header. For broadcast and NBMA network types, the neighbor
structure's Router Priority field, Neighbor's Designated Router
field, and Neighbor's Backup Designated Router field are also
set equal to the corresponding fields found in the received
Hello Packet; changes in these fields should be noted for
possible use in the steps below. When receiving an Hello on a
point-to-point network (but not on a virtual link) set the
neighbor structure's Neighbor IP address to the packet's IP
source address.

Notes:

This is unnecessary in case of Point-to-MultiPoint network type to hold neighbor's Router Priority, DR, and BDR values.

Errata ID: 3734
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramakrishna DTV
Date Reported: 2013-09-23
Verifier Name: Stewart Bryant
Date Verified: 2013-10-10

Section 8.2 says:

            The AuType specified in the packet must match the AuType
            specified for the associated area.

It should say:

            The AuType specified in the packet must match the AuType
            specified for the associated interface.

Notes:

In OSPFv2, authentication is configured per interface and not per area.
Appendix D clarifies this: "The authentication type is configurable on a per-interface
(or equivalently, on a per-network/subnet) basis."

Errata ID: 4023
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alexander Okonnikov
Date Reported: 2014-06-24
Verifier Name: Alia Atlas
Date Verified: 2014-06-24

Section 12.4.1 says:

o Otherwise, the link descriptions added to the router-LSA
depend on the OSPF interface type. Link descriptions
used for point-to-point interfaces are specified in
Section 12.4.1.1, for virtual links in Section 12.4.1.2,
for broadcast and NBMA interfaces in 12.4.1.3, and for
Point-to-MultiPoint interfaces in 12.4.1.4.

It should say:

o Otherwise, the link descriptions added to the router-LSA
depend on the OSPF interface type. Link descriptions
used for point-to-point interfaces are specified in
Section 12.4.1.1, for broadcast and NBMA interfaces in 12.4.1.2,
for virtual links in Section 12.4.1.3, and for 
Point-to-MultiPoint interfaces in 12.4.1.4.

Notes:

Incorrect references.

Errata ID: 4330
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramakrishna Rao DTV
Date Reported: 2015-04-08
Verifier Name: Alia Atlas
Date Verified: 2015-04-09

Section 3.4 says:

        The link-state database for the backbone is shown in Figure 8.
        The set of routers pictured are the backbone routers.  Router
        RT11 is a backbone router because it belongs to two areas.  In
        order to make the backbone connected, a virtual link has been
        configured between Routers R10 and R11.

It should say:

        The link-state database for the backbone is shown in Figure 8.
        The set of routers pictured are the backbone routers.  Router
        RT11 is a backbone router because it belongs to two areas.  In
        order to make the backbone connected, a virtual link has been
        configured between Routers RT10 and RT11.

Notes:

s/R10/RT10
s/R11/RT11

Errata ID: 5041
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Adam Augustyn
Date Reported: 2017-06-13
Verifier Name: Alia Atlas
Date Verified: 2017-06-13

Section 10.2 says:

1-Way
    An Hello packet has been received from the neighbor, in
    which the router is not mentioned.  This indicates that
    communication with the neighbor is not bidirectional.

It should say:

1-WayReceived
    An Hello packet has been received from the neighbor, in
    which the router is not mentioned.  This indicates that
    communication with the neighbor is not bidirectional.

Notes:

RFC2328 defines The Neighbor state machine and it's states. One of the states is defined/named as 1-WayReceived ([Page 95] 10.3.).
1-WayReceived is also mentioned on page 84 and 98.

Pages 85 and 88 use event 1Way which should be renamed to 1-WayReceived for consistency with definition of the state.

[Page 85]
Event 1-Way forces Init state,


[Page 88]
10.2. Events causing neighbor state changes
1-Way
An Hello packet has been received from the neighbor, in
which the router is not mentioned. This indicates that
communication with the neighbor is not bidirectional.

On p. 85 after Figure 13, it says "Figure 13: Neighbor state changes (Database Exchange)
....
Event 1-Way forces Init state,
"
and Event 1-Way should be replaced with 1-WayReceived

Errata ID: 6679
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2021-09-07
Verifier Name: John Scudder
Date Verified: 2022-05-09

Section 3.4 says:

        The area border routers RT3, RT4, RT7, RT10 and RT11 condense
        the routing information of their attached non-backbone areas for
        distribution via the backbone; these are the dashed stubs that
        appear in Figure 8.  Remember that the third area has been
        configured to condense Networks N9-N11 and Host H1 into a single
        route.  This yields a single dashed line for networks N9-N11 and
        Host H1 in Figure 8.  Routers RT5 and RT7 are AS boundary
        routers; their externally derived information also appears on
        the graph in Figure 8 as stubs.

It should say:

        The area border routers RT3, RT4, RT7, RT10 and RT11 condense
        the routing information of their attached non-backbone areas for
        distribution via the backbone; these are the dashed stubs that
        appear in Figure 6.  Remember that the third area has been
        configured to condense Networks N9-N11 and Host H1 into a single
        route.  This yields a single dashed line for networks N9-N11 and
        Host H1 in Figure 8.  Routers RT5 and RT7 are AS boundary
        routers; their externally derived information also appears on
        the graph in Figure 8 as stubs.

Notes:

Incorrect figure number (8 instead 6).

Errata ID: 7112
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Renato Westphal
Date Reported: 2022-09-01
Verifier Name: John Scudder
Date Verified: 2022-09-01

Section 10.2 says:

        NegotiationDone
            The Master/Slave relationship has been negotiated, and DD
            sequence numbers have been exchanged.  This signals the
            start of the sending/receiving of Database Description
            packets.  For more information on the generation of this
            event, consult Section 10.8.

It should say:

        NegotiationDone
            The Master/Slave relationship has been negotiated, and DD
            sequence numbers have been exchanged.  This signals the
            start of the sending/receiving of Database Description
            packets.  For more information on the generation of this
            event, consult Section 10.6.

Notes:

The generation of the NegotiationDone event is specified in Section 10.6 (not Section 10.8).

(Also discussed at https://mailarchive.ietf.org/arch/msg/lsr/NZMWapi62sJuExnBZFBBMdW169k/)

Errata ID: 7756
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lokesh Venkata Kumar Chakka
Date Reported: 2024-01-11
Verifier Name: John Scudder
Date Verified: 2024-01-11

Section A.4.5 says:

    AS-external-LSAs are the Type 5 LSAs.  These LSAs are originated by
    AS boundary routers, and describe destinations external to the AS.
    For details concerning the construction of AS-external-LSAs, see
    Section 12.4.3.

It should say:

    AS-external-LSAs are the Type 5 LSAs.  These LSAs are originated by
    AS boundary routers, and describe destinations external to the AS.
    For details concerning the construction of AS-external-LSAs, see
    Section 12.4.4.

Notes:

Incorrect references. Construction of AS-external-LSAs explained in Section 12.4.4. Not in 12.4.

(See also https://mailarchive.ietf.org/arch/msg/lsr/OiOvEPM2W-Mwd_QgbmJASg8bDOI/)

RFC 2347, "TFTP Option Extension", May 1998

Source of RFC: Legacy
Area Assignment: app

Errata ID: 1258
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Edwin Groothuis
Date Reported: 2008-01-13
Verifier Name: Alexey Melnikov
Date Verified: 2010-11-12

Section Examples says:

   Write Request

      client                                           server
      -------------------------------------------------------
      |2|barfile|0|octet|0|blksize|0|2048|0|  -->               RRQ
                                    <--  |6|blksize|0|2048|0|   OACK

It should say:

   Write Request

      client                                           server
      -------------------------------------------------------
      |2|barfile|0|octet|0|blksize|0|2048|0|  -->               WRQ
                                    <--  |6|blksize|0|2048|0|   OACK

Notes:

At the "Write Request", the string RRQ should be replaced with WRQ.

RFC 2361, "WAVE and AVI Codec Registries", June 1998

Source of RFC: Legacy
Area Assignment: rai

Errata ID: 5124
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: David Russo
Date Reported: 2017-09-24
Verifier Name: RFC Editor
Date Verified: 2024-02-15

Appendix A.58 says:

WAVE form wFormatTag ID:n       WAVE_FORMAT_VOXWARE_BYTE_ALIGNED

It should say:

WAVE form wFormatTag ID:        WAVE_FORMAT_VOXWARE_BYTE_ALIGNED

RFC 2362, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", June 1998

Note: This RFC has been obsoleted by RFC 4601, RFC 5059

Source of RFC: idmr (rtg)

Errata ID: 457
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: RFC Editor
Date Reported: 2001-01-03

Throughout the document:

   [Figures are present only in the postscript version]

Notes:

There is no postscript version available.

RFC 2373, "IP Version 6 Addressing Architecture", July 1998

Note: This RFC has been obsoleted by RFC 3513

Source of RFC: ipngwg (int)

Errata ID: 455
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tim Hutchinson
Date Reported: 2000-10-31

In the reference:

   [TRAN]    Gilligan, R., and E. Nordmark, "Transition Mechanisms for
             IPv6 Hosts and Routers", RFC 1993, April 1996.

Notes:

the RFC number cited is incorrect; it should be RFC 1933.

RFC 2384, "POP URL Scheme", August 1998

Source of RFC: Legacy

Errata ID: 2943
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Frank Ellermann
Date Reported: 2011-08-18
Verifier Name: Peter Saint-Andre
Date Verified: 2011-11-14

Section 7 says:

        S: +OK POP3 server ready <1896.697170952@mail.eudora.com>
        C: APOP rg c4c9334bac560ecc979e58001b3e22fb

It should say:

        S: +OK POP3 server ready <1896.697170952@mail.eudora.com>
        C: APOP rg 8f5de26536bc248ba202a9ca612e71bd

Notes:

If the password for user "rg" is "secret" as in the plain PASS example before this APOP example, then
MD5("<1896.697170952@mail.eudora.com>secret") should be as shown in the corrected text.

The original text is a modification of the APOP example in RFC 1939, and
MD5("<1896.697170952@dbc.mtview.ca.us>tanstaaf") almost certainly will not match any plausible
MD5("<1896.697170952@mail.eudora.com>"||password).

RFC 2387, "The MIME Multipart/Related Content-type", August 1998

Source of RFC: mhtml (app)

Errata ID: 5578
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sloane Bernstein
Date Reported: 2018-12-18
Verifier Name: Barry Leiba
Date Verified: 2020-05-05

Section .4 says:

     related-param   := [ ";" "start" "=" cid ]
                        [ ";" "start-info"  "="
                           ( cid-list / value ) ]
                        [ ";" "type"  "=" type "/" subtype ]
                        ; order independent

It should say:

     related-param   := ( ";" "type"  "=" type "/" subtype )
                        [ ";" "start" "=" cid ]
                        [ ";" "start-info"  "="
                           ( cid-list / value ) ]
                        ; order independent, "type" is required

Notes:

The "type" parameter is specified by the rest of the document to be mandatory, but the ABNF in section 3.4 indicates that it is optional. Even though the ABNF is specified somewhat informally (and arguably should be formalized if this RFC is ever re-issued), it should not be giving information that contradicts the formal part of the specification (e.g., section 2).

===== Verifier notes =====
As the reporter says, the ABNF here needs more work, and that should be held for document update. This particular item, though, does, indeed, contradict the normative text. I have also moved the required item to the top of the parameter list for clarity.

RFC 2388, "Returning Values from Forms: multipart/form-data", August 1998

Note: This RFC has been obsoleted by RFC 7578

Source of RFC: Legacy
Area Assignment: app

Errata ID: 4030
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Anne van Kesteren
Date Reported: 2014-06-30
Verifier Name: Barry Leiba
Date Verified: 2014-07-01

Section Appendix A says:

Required parameters:
  none

It should say:

Required parameters:
  boundary (see Section 4.1)

Notes:

Without that parameter you cannot parse the payload body.

Errata ID: 2937
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Anne van Kesteren
Date Reported: 2011-08-14
Verifier Name: Peter Saint-Andre
Date Verified: 2011-11-12

Section 5.6 says:

application/x-url-encoded

It should say:

application/x-www-form-urlencoded

Notes:

This incorrect media type appears twice and should be replaced both times. In the last paragraph of this section "both" and "as well" can be removed.

RFC 2392, "Content-ID and Message-ID Uniform Resource Locators", August 1998

Source of RFC: mhtml (app)

Errata ID: 454
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2002-03-07

Section 2 says:

   example, "cid:foo4%25foo1@bar.net" corresponds to

     Content-ID: <foo4%25foo1@bar.net>

It should say:

   example, "cid:foo4%25foo1@bar.net" corresponds to

     Content-ID: <foo4%foo1@bar.net>

Errata ID: 6176
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Witten (mfwitten)
Date Reported: 2020-05-16
Verifier Name: Barry Leiba
Date Verified: 2020-05-16

Section 2 says:

--boundary-example-1

Content-ID: <foo4*foo1@bar.net>
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64

It should say:

--boundary-example-1
Content-ID: <foo4*foo1@bar.net>
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64

Notes:

There should not be a blank line between "--boundary-example-1"
and "Content-ID: <foo4*foo1@bar.net>". See the syntax provided
by the BNF term "multipart-body" in RFC 2046.

RFC 2395, "IP Payload Compression Using LZS", December 1998

Source of RFC: ippcp (int)

Errata ID: 453
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Border
Date Reported: 2000-08-30

Section 7 says:

-

It should say:

   [Deutsch96] Deutsch, P., "DEFLATE Compressed Data Format
               Specification version 1.3", RFC 1951, May 1996.

Notes:

the above reference (cited in Section 5) should appear.

RFC 2396, "Uniform Resource Identifiers (URI): Generic Syntax", August 1998

Note: This RFC has been obsoleted by RFC 3986

Note: This RFC has been updated by RFC 2732

Source of RFC: Legacy
Area Assignment: app

Errata ID: 450
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Carl Douglas
Date Reported: 2001-04-26

Section 3.4 says:

   The query component is a string of information to be interpreted by
   the resource.

      query         = *uric

   Within a query component, the characters ";", "/", "?", ":", "@",
   "&", "=", "+", ",", and "$" are reserved.

Notes:

Section 3.4, "Query Component", of RFC 2396 (URI syntax) refers to the
"/" character as being reserved.

Reserving this character creates an inconsistency for some of today's
web servers, which confuse part of the Query Component as being part of
the Path Component when the "/" character is present in the Query
Component.

The "/" character should only be permitted in the Path Component of a
URI, and elsewhere in the URI it should be escaped by using it's hex
value.

Errata ID: 451
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Marc Warne
Date Reported: 2002-09-18

Section 1.2 says:

   A URN differs from a URL in that it's primary purpose is persistent
   labeling of a resource with an identifier.

It should say:

   A URN differs from a URL in that its primary purpose is persistent
   labeling of a resource with an identifier.

Errata ID: 452
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Henry Zongaro
Date Reported: 2001-11-12
Verifier Name: Alexey Melnikov
Date Verified: 2010-11-11

Section Appendix C says:

C.1.  Normal Examples
       ...
      ?y            =  http://a/b/c/?y
       ...

Notes:

Appendix C shows an example of a relative URI Reference of "?y" with
respect to the base URI "http://a/b/c/d;p?q". However, according to the
collected syntax that appears in Appendix A, "?y" doesn't appear to be a
valid relative URI reference. The syntactic category URI-reference must
begin with an absoluteURI, a relativeURI or a pound sign. An absoluteURI
begins with a scheme, which cannot begin with a question mark; a
relativeURI begins with a net_path or abs_path, both of which begin with a
slash, or with a rel_path. A rel_path begins with a non-empty
rel_segment, which again cannot begin with a question mark.


Alexey: this was fixed in RFC 3986 (the example is correct).

Errata ID: 1069
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dave Singer
Date Reported: 2005-09-14
Date Verified: 2007-11-13

Section 1.2 says:

   A URN differs from a URL in that it's primary purpose is persistent
   labeling of a resource with an identifier.

It should say:

   A URN differs from a URL in that its primary purpose is persistent
   labeling of a resource with an identifier.

Notes:

a possessive its

RFC 2397, "The "data" URL scheme", August 1998

Source of RFC: Legacy

Errata ID: 2009
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexander Gebel
Date Reported: 2010-01-18
Verifier Name: Alexey Melnikov
Date Verified: 2010-03-11

Section 4 says:

data:text/plain;charset=iso-8859-7,%be%fg%be

It should say:

data:text/plain;charset=iso-8859-7,%be%d3%be

Notes:

The given hex encoding "%fg" is incorrect, because there is no hexadecimal digit "g" ("f" is last). A correct hex encoding of any character is permissible here.

Errata ID: 2045
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2010-02-17
Verifier Name: Alexey Melnikov
Date Verified: 2010-03-11

Section 3 says:

3. Syntax


       dataurl    := "data:" [ mediatype ] [ ";base64" ] "," data
       mediatype  := [ type "/" subtype ] *( ";" parameter )
       data       := *urlchar
       parameter  := attribute "=" value

   where "urlchar" is imported from [RFC2396], and "type", "subtype",
   "attribute" and "value" are the corresponding tokens from [RFC2045],
   represented using URL escaped encoding of [RFC2396] as necessary.

It should say:

3. Syntax


       dataurl    := "data:" [ mediatype ] [ ";base64" ] "," data
       mediatype  := [ type "/" subtype ] *( ";" parameter )
       data       := *uric
       parameter  := attribute "=" value

   where "uric" is imported from [RFC2396], and "type", "subtype",
   "attribute" and "value" are the corresponding tokens from [RFC2045],
   represented using URL escaped encoding of [RFC2396] as necessary.

Notes:

"urlchar" is not defined in RFC2396, but "uric" is (which I think is what was supposed to be used).

RFC 2402, "IP Authentication Header", November 1998

Note: This RFC has been obsoleted by RFC 4302, RFC 4305

Source of RFC: ipsec (sec)

Errata ID: 6953
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: J Foster
Date Reported: 2022-05-03
Date Verified: 2023-08-02

Section 2. (6) says:

2.6  Authentication Data

   This is a variable-length field that contains the Integrity Check
   Value (ICV) for this packet.  The field must be an integral multiple
   of 32 bits in length.  The details of the ICV computation are
   described in Section 3.3.2 below.  This field may include explicit
   padding.  This padding is included to ensure that the length of the
   AH header is an integral multiple of 32 bits (IPv4) or 64 bits
   (IPv6).  All implementations MUST support such padding.  Details of
   how to compute the required padding length are provided below.  The
   authentication algorithm specification MUST specify the length of the
   ICV and the comparison rules and processing steps for validation.

It should say:

2.6  Authentication Data

   This is a variable-length field that contains the Integrity Check
   Value (ICV) for this packet.  The field must be an integral multiple
   of 32 bits in length.  The details of the ICV computation are
   described in Section 3.3.3 below.  This field may include explicit
   padding.  This padding is included to ensure that the length of the
   AH header is an integral multiple of 32 bits (IPv4) or 64 bits
   (IPv6).  All implementations MUST support such padding.  Details of
   how to compute the required padding length are provided below.  The
   authentication algorithm specification MUST specify the length of the
   ICV and the comparison rules and processing steps for validation.

Notes:

The section referenced for ICV computation is currently 3.3.2 (Sequence Number Generation). I believe this to be an error, and that 3.3.3 (Integrity Check Value Calculation) was the intended reference.

RFC 2407, "The Internet IP Security Domain of Interpretation for ISAKMP", November 1998

Note: This RFC has been obsoleted by RFC 4306

Source of RFC: ipsec (sec)

Errata ID: 449

Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jan Wuyts
Date Reported: 2004-03-04
Report Text:

The section 4 header is missing from the document.  Presently, the document is structured as follows:

1. Abstract
2. Introduction
3. Terms and definitions
   4.1  IPSEC naming scheme
   4.2  IPSEC situation definition
...etc.

---

RFC 2408, "Internet Security Association and Key Management Protocol (ISAKMP)", November 1998

Note: This RFC has been obsoleted by RFC 4306

Source of RFC: ipsec (sec)

Errata ID: 6388
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sasikumar Mani
Date Reported: 2021-01-19
Verifier Name: Paul Wouters
Date Verified: 2022-04-10

Section 1.6.1 says:

Proof can be provided by encrypting known data in the secret session key during the protocol echange.

It should say:

Proof can be provided by encrypting known data in the secret session key during the protocol exchange.

RFC 2409, "The Internet Key Exchange (IKE)", November 1998

Note: This RFC has been obsoleted by RFC 4306

Note: This RFC has been updated by RFC 4109

Source of RFC: ipsec (sec)

Errata ID: 7552
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nico Mexis
Date Reported: 2023-06-23
Verifier Name: RFC Editor
Date Verified: 2023-06-23

Section A says:

This is a list of DES Weak and Semi-Weak keys.  The keys come from
   [Sch96].  All keys are listed in hexidecimal.

It should say:

This is a list of DES Weak and Semi-Weak keys.  The keys come from
   [Sch96].  All keys are listed in hexadecimal.

Notes:

hexidecimal -> should be hexadecimal

RFC 2417, "Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks", September 1998

Source of RFC: Legacy

Errata ID: 448
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: C. M. Heard
Date Reported: 2003-08-11

Section 3 says:

   IMPORTS
       MODULE-COMPLIANCE, NOTIFICATION-GROUP, OBJECT-GROUP
           FROM SNMPv2-CONF
       snmpModules, MODULE-IDENTITY, NOTIFICATION-TYPE, Counter32,
           Integer32, Unsigned32, OBJECT-TYPE, IpAddress
           FROM SNMPv2-SMI

It should say:

   IMPORTS
       MODULE-COMPLIANCE, NOTIFICATION-GROUP, OBJECT-GROUP
           FROM SNMPv2-CONF
       mib-2, MODULE-IDENTITY, NOTIFICATION-TYPE, Counter32,
           Integer32, Unsigned32, OBJECT-TYPE, IpAddress
           FROM SNMPv2-SMI

RFC 2418, "IETF Working Group Guidelines and Procedures", September 1998

Note: This RFC has been updated by RFC 3934, RFC 7475, RFC 7776, RFC 8717, RFC 9141

Source of RFC: Poisson (gen)

Errata ID: 3752
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: RFC Editor
Date Reported: 2013-10-15
Verifier Name: Lars Eggert
Date Verified: 2021-03-11

Section 2.2 says:

In order
to take advantage of this service, working group mailing lists
MUST include the address "wg_acronym-archive@lists.ietf.org"
(where "wg_acronym" is the working group acronym) in the
mailing list in order that a copy of all mailing list messages
be recorded in the Secretariat's archive.  

It should say:

In order
to take advantage of this service, working group mailing lists
MUST include the address "wg_acronym-archive@ietf.org"
(where "wg_acronym" is the working group acronym) in the
mailing list in order that a copy of all mailing list messages
be recorded in the Secretariat's archive.  

Notes:

'@lists.ietf.org' was changed to '@ietf.org' in the year 2005.

Although the RFC errata system is not typically used to update email addresses that were correct at the time of publication, this report results from discussion with Russ Housley and Jari Arkko.

Errata ID: 6787
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sky Lian
Date Reported: 2021-12-18
Verifier Name: Lars Eggert
Date Verified: 2023-08-11

Section Appendix says:

The primary purpose of this working group is to develop two such supportive protocols and a frameword document.

It should say:

The primary purpose of this working group is to develop two such supportive protocols and a framework document.

Notes:

From "frameword" to "framework"

Errata ID: 7408
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ian Williams
Date Reported: 2023-03-29
Verifier Name: RFC Editor
Date Verified: 2023-04-27

Section 2.3 says:

The working group is announced to the IETF-announce a by the IETF Secretariat.

It should say:

The working group is announced to the IETF-announce mailing list by the IETF Secretariat.

Notes:

"a" appears to have been used in place of "mailing list."

RFC 2421, "Voice Profile for Internet Mail - version 2", September 1998

Note: This RFC has been obsoleted by RFC 3801

Source of RFC: Legacy
Area Assignment: app

Errata ID: 440
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2002-01-06
Verifier Name: Alexey Melnikov
Date Verified: 2010-11-11

Section Appendix B says:

    Date: Mon, 26 Aug 93 10:20:20 -0700 (CDT)
    MIME-Version: 1.0  (Voice 2.0)
    Content-type: Multipart/Voice-Message; Version=2.0;
      Boundary="MessageBoundary"
    Content-Transfer-Encoding: 7bit
    Message-ID: ABCD-123456789@VM2.mycompany.com

    --MessageBoundary
    Content-type: Audio/32KADPCM
    Content-Transfer-Encoding: Base64
    Content-Disposition: inline; voice=Originator-Spoken-Name
    Content-Language: en-US
    Content-ID: part3@VM2-4321

It should say:

    Date: Thu, 26 Aug 1993 10:20:20 -0700 (CDT)
    MIME-Version: 1.0  (Voice 2.0)
    Content-type: Multipart/Voice-Message; Version=2.0;
      Boundary="MessageBoundary"
    Content-Transfer-Encoding: 7bit
    Message-ID: <ABCD-123456789@VM2.mycompany.com>

    --MessageBoundary
    Content-type: Audio/32KADPCM
    Content-Transfer-Encoding: Base64
    Content-Disposition: inline; voice=Originator-Spoken-Name
    Content-Language: en-US
    Content-ID: <part3@VM2-4321.mycompany.com>

Notes:

Date inconsistency. 4-digit year. Message-ID, Content-ID
syntax (missing <>) and semantics.

Errata ID: 442
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2002-01-06
Verifier Name: Alexey Melnikov
Date Verified: 2010-11-12

Section Appendix B says:

Date: Mon, 26 Aug 93 10:20:20 -0700 (CDT)
   MIME-Version: 1.0  (Voice 2.0)
   Content-type: Multipart/Voice-Message; Version=2.0;
     Boundary="MessageBoundary"
   Content-Transfer-Encoding: 7bit
   Message-ID: 123456789@VM2.mycompany.com
   Sensitivity: Private
   Importance: High

   --MessageBoundary
   Content-type: Audio/32KADPCM
   Content-Transfer-Encoding: Base64
   Content-Disposition: inline; voice=Originator-Spoken-Name
   Content-Language: en-US
   Content-ID: part1@VM2-4321

It should say:

Date: Thu, 26 Aug 1993 10:20:20 -0700 (CDT)
   MIME-Version: 1.0  (Voice 2.0)
   Content-type: Multipart/Voice-Message; Version=2.0;
     Boundary="MessageBoundary"
   Content-Transfer-Encoding: 7bit
   Message-ID: <123456789@VM2.mycompany.com>
   Sensitivity: Private
   Importance: High

   --MessageBoundary
   Content-type: Audio/32KADPCM
   Content-Transfer-Encoding: Base64
   Content-Disposition: inline; voice=Originator-Spoken-Name
   Content-Language: en-US
   Content-ID: <part1@VM2-4321.mycompany.com>

Notes:

Date inconsistency. 4-digit year number.
Message-ID syntax error (angle brackets required); likewise
for Content-ID. In addition, Content-ID requires a fully-qualified
domain name as it must be world-unique, like a Message-ID.
RFC 1911 section 12 has a similar example with similar errors
in the date and message-id fields.

Errata ID: 444
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2002-01-06
Verifier Name: Alexey Melnikov
Date Verified: 2010-11-12

Section Appendix B says:

|   Date: Mon, 26 Aug 93 8:23:10 -0500 (EST)
    Content-type: Multipart/Voice-Message; Version=2.0;
      Boundary="MessageBoundary2"
    Content-Transfer-Encoding: 7bit
    MIME-Version: 1.0  (Voice 2.0)

    --MessageBoundary2
    Content-type: Audio/32KADPCM
    Content-Transfer-Encoding: Base64
    Content-Disposition: inline; voice=Originator-Spoken-Name
    Content-Language: en-US
|   Content-ID: part6@VM2-4321

It should say:

|   Date: Thu, 26 Aug 1993 8:23:10 -0500 (EST)
    Content-type: Multipart/Voice-Message; Version=2.0;
      Boundary="MessageBoundary2"
    Content-Transfer-Encoding: 7bit
    MIME-Version: 1.0  (Voice 2.0)

    --MessageBoundary2
    Content-type: Audio/32KADPCM
    Content-Transfer-Encoding: Base64
    Content-Disposition: inline; voice=Originator-Spoken-Name
    Content-Language: en-US
|   Content-ID: <part6@VM2-4321.mycompany.com>

Notes:

Date inconsistency. 4-digit year. Content-ID syntax (missing <>) and
semantics (need to use fully qualified domain name).

Errata ID: 446
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2002-01-07

In Appendix B:

   SOUND;TYPE=32KADPCM;ENCODING=URI: CID:<part1@VM2-4321>
   REV:19951031T222710Z
   VERSION: 3.0
   END:VCARD

   --MessageBoundary_

It should say:

   SOUND;TYPE=32KADPCM;ENCODING=URI: CID:<part1@VM2-4321>
   REV:19951031T222710Z
   VERSION: 3.0
   END:VCARD

   --MessageBoundary--

Errata ID: 447
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2003-10-04

Section 15 says:

     Date: Mon, 26 Aug 93 8:23:10 -0500 (EST)

It should say:

     Date: Mon, 26 Aug 93 08:23:10 -0500 (EST)

Errata ID: 469
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2002-01-31

Section 15 says:

   Content-type: message/disposition-notification

   Reporting-UA: gregs-laptop.dallas.company.com (Unified FooMail 3.0)

   Original-Recipient: rfc822;22722@vm.company.com

It should say:

   Content-type: message/disposition-notification

   Reporting-UA: gregs-laptop.dallas.company.com (Unified FooMail 3.0)
   Original-Recipient: rfc822;22722@vm.company.com

Errata ID: 443
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2002-01-06
Verifier Name: Alexey Melnikov
Date Verified: 2010-11-11

Section 4.2.4 says:

Date: Wed, 28 Jul 96 10:08:49 -0800 (PST)

It should say:

Date: Sun, 28 Jul 1996 10:08:49 -0800 (PST)

Notes:

RFC 822, section 5.2 prohibits date inconsistency
between day-of-week and date (see also RFC 2822, sect. 3.3).
RFC 1123 section 5.2.14 strongly encourages use of 4-digit
year numbers; RFC 2822 mandates them. These errors also appear
in RFC 1911 section 4.2.

Errata ID: 2523
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2002-01-31
Verifier Name: Alexey Melnikov
Date Verified: 2010-11-12

Section 15 says:

    Content-type: message/disposition-notification

    Reporting-UA: gregs-laptop.dallas.company.com (Unified FooMail 3.0)

    Original-Recipient: rfc822;22722@vm.company.com
 [...]

It should say:

    Content-type: message/disposition-notification

    Reporting-UA: gregs-laptop.dallas.company.com (Unified FooMail 3.0)
    Original-Recipient: rfc822;22722@vm.company.com
 [...]

Notes:

RFC 2298 does not permit extra CRLFs between fields
in a MDN. See the BNF in RFC 2298 section 3 (note that the CRLFs
there are the ones that terminate each header field).

RFC 2426, "vCard MIME Directory Profile", September 1998

Note: This RFC has been obsoleted by RFC 6350

Source of RFC: asid (app)

Errata ID: 868
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Javier Godoy
Date Reported: 2007-03-18
Verifier Name: Alexey Melnikov
Date Verified: 2010-07-26

Section 4 says:

 ;For name=3D"AGENT"
   param        =3D agent-inline-param

   param        =3D/ agent-refer-param

   value        =3D agent-inline-value
        ; Value and parameter MUST match

   value        =3D/ agent-refer-value
        ; Value and parameter MUST match

   agent-inline-param =3D ""
        ; No parameters allowed

   agent-refer-param =3D "VALUE" "=3D" "uri"
        ; Only value parameter allowed

   agent-inline-value =3D text-value
        ; Value MUST be a valid vCard object

   agent-refer-value =3D uri
        ; URI MUST refer to image content of given type

It should say:

 ;For name=3D"AGENT"
   param        =3D agent-inline-param

   param        =3D/ agent-refer-param

   value        =3D agent-inline-value
        ; Value and parameter MUST match

   value        =3D/ agent-refer-value
        ; Value and parameter MUST match

   agent-inline-param =3D ""
        ; No parameters allowed

   agent-refer-param =3D "VALUE" "=3D" "uri"
        ; Only value parameter allowed

   agent-inline-value =3D text-value
        ; Value MUST be a valid vCard object

   agent-refer-value =3D uri
        ; URI MUST refer a valid vCard object

Notes:

- Presumably, the comment from img-refer-value was copied, but it was
not modified.
- The correction is consistent with comment for agent-inline-value.
- The purpose of AGENT type is "To specify information about another
person who will act on behalf of the individual or resource associated
with the vCard." (Section 3.5.4)

Errata ID: 869
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Javier Godoy
Date Reported: 2007-03-25
Verifier Name: Alexey Melnikov
Date Verified: 2010-07-27

Section 4 says:

   ;For name="SOURCE"
   param        = source-param
        ; No parameters allowed

It should say:

   ;For name="SOURCE"
   param        = source-param
        ; Only source parameters allowed

Notes:

Corrected the comment.

Errata ID: 870
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Javier Godoy
Date Reported: 2007-03-25
Verifier Name: Alexey Melnikov
Date Verified: 2010-07-26

Section 4 says:

 ;For name=3D"UID"
   param        =3D ""
        ; No parameters allowed

   value        =3D text-value

It should say:

 ;For name="UID"
   param        = "TYPE" "=" (iana-token / x-name)
        ; Only the TYPE parameter is allowed.

   value        = text-value

Notes:

Section 3.6.7 (p. 23) "UID Type Definition" says:

The type can include the type parameter "TYPE" to specify the format
of the identifier. The TYPE parameter value should be an IANA
registered identifier format. The value can also be a non-standard
format.

Alexey: edited as per feedback from Simon Perreault.

Errata ID: 871
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Javier Godoy
Date Reported: 2007-03-25
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-25

Section 4 says:

   adr-type     =3D "dom" / "intl" / "postal" / "parcel" / "home"
                / "work" / "pref" / iana-type / x-name
                                    ^^^^^^^^^

It should say:

   adr-type     =3D "dom" / "intl" / "postal" / "parcel" / "home"
                / "work" / "pref" / iana-token / x-name
                                    ^^^^^^^^^^

Notes:

iana-type is not defined in given ABNF, but iana-token is. This is
the only reference to iana-type in the document, so it is likely to be a
typo.

iana-token =3D 1*(ALPHA / DIGIT / "-")
; vCard type or parameter identifier registered with IANA

Errata ID: 872
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Javier Godoy
Date Reported: 2007-03-25
Verifier Name: Alexey Melnikov
Date Verified: 2010-07-26

Section 7 says:

   BEGIN:vCard
   VERSION:3.0
   FN:Frank Dawson
   ORG:Lotus Development Corporation
   ADR;TYPE=3DWORK,POSTAL,PARCEL:;;6544 Battleford Drive
    ;Raleigh;NC;27613-3502;U.S.A.
   TEL;TYPE=3DVOICE,MSG,WORK:+1-919-676-9515
   TEL;TYPE=3DFAX,WORK:+1-919-676-9564
   EMAIL;TYPE=3DINTERNET,PREF:Frank_Dawson@Lotus.com
   EMAIL;TYPE=3DINTERNET:fdawson@earthlink.net
   URL:http://home.earthlink.net/~fdawson
   END:vCard


   BEGIN:vCard
   VERSION:3.0
   FN:Tim Howes
   ORG:Netscape Communications Corp.
   ADR;TYPE=3DWORK:;;501 E. Middlefield Rd.;Mountain View;
    CA; 94043;U.S.A.
   TEL;TYPE=3DVOICE,MSG,WORK:+1-415-937-3419
   TEL;TYPE=3DFAX,WORK:+1-415-528-4164
   EMAIL;TYPE=3DINTERNET:howes@netscape.com
   END:vCard

It should say:

   BEGIN:vCard
   VERSION:3.0
   FN:Frank Dawson
|  N:Dawson;Frank;;;
   ORG:Lotus Development Corporation
   ADR;TYPE=WORK,POSTAL,PARCEL:;;6544 Battleford Drive
    ;Raleigh;NC;27613-3502;U.S.A.
   TEL;TYPE=VOICE,MSG,WORK:+1-919-676-9515
   TEL;TYPE=FAX,WORK:+1-919-676-9564
   EMAIL;TYPE=INTERNET,PREF:Frank_Dawson@Lotus.com
   EMAIL;TYPE=INTERNET:fdawson@earthlink.net
   URL:http://home.earthlink.net/~fdawson
   END:vCard


   BEGIN:vCard
   VERSION:3.0
   FN:Tim Howes
|  N:Howes;Tim;;;
   ORG:Netscape Communications Corp.
   ADR;TYPE=WORK:;;501 E. Middlefield Rd.;Mountain View;
    CA; 94043;U.S.A.
   TEL;TYPE=VOICE,MSG,WORK:+1-415-937-3419
   TEL;TYPE=FAX,WORK:+1-415-528-4164
   EMAIL;TYPE=INTERNET:howes@netscape.com
   END:vCard

Notes:

- "Profile special notes: The vCard object MUST contain the FN, N and
VERSION types." (Section 1) N was missing in the original information.

Errata ID: 1546
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Markus Lorenz
Date Reported: 2008-10-09
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-21

Section 4 says:

   ;For name="SOUND"
   param        = snd-inline-param
        ; Only sound parameters allowed

   param        =/ snd-refer-param
        ; Only sound parameters allowed

   value        = snd-line-value
        ; Value MUST match value type

It should say:

   ;For name="SOUND"
   param        = snd-inline-param
        ; Only sound parameters allowed

   param        =/ snd-refer-param
        ; Only sound parameters allowed

   value        = snd-inline-value
        ; Value MUST match value type

Notes:

There is no "snd-line-value" specified, but a "snd-inline-value" is.

Errata ID: 1548
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Markus Lorenz
Date Reported: 2008-10-09
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-20

Section 4 says:

   img-inline-param     = ("VALUE" "=" "binary")
                        / ("ENCODING" "=" "b")
                        / ("TYPE" "=" param-value
        ;TYPE value MUST be an IANA registered image type

It should say:

   img-inline-param     = ("VALUE" "=" "binary")
                        / ("ENCODING" "=" "b")
                        / ("TYPE" "=" param-value)
        ;TYPE value MUST be an IANA registered image type

Notes:

There is a closing parenthesis missing at the end of "TYPE".

Errata ID: 1549
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Markus Lorenz
Date Reported: 2008-10-09
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-25

Section 4 says:

   ;For name="KEY"

 [...]

   key-bin-param = ("TYPE" "=" keytype)
                 / ("ENCODING" "=" "b")
        ; Value MUST be a "b" encoded key or certificate

It should say:

   ;For name="KEY"

 [...]

   key-bin-param = ("VALUE" "=" "binary")
                 / ("TYPE" "=" keytype)
                 / ("ENCODING" "=" "b")
        ; Value MUST be a "b" encoded key or certificate

Notes:

According to sections 2.4.1 and 3.7.2 the KEY type value can be specified as "binary".

Errata ID: 1550
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Markus Lorenz
Date Reported: 2008-10-09
Verifier Name: Alexey Melnikov
Date Verified: 2010-07-26

Section 4 says:

   ;For name="SOUND"
   param        = snd-inline-param
        ; Only sound parameters allowed

   param        =/ snd-refer-param
        ; Only sound parameters allowed

   value        = snd-line-value
        ; Value MUST match value type

   value        =/ snd-refer-value
        ; Value MUST match value type

   snd-inline-value     = binary-value CRLF
        ; Value MUST be "b" encoded audio content

   snd-inline-param     = ("VALUE" "=" "binary"])
                        / ("ENCODING" "=" "b")
                        / ("TYPE" "=" *SAFE-CHAR)
        ; Value MUST be an IANA registered audio type

It should say:

   ;For name="SOUND"
   param        = snd-inline-param
        ; Only sound parameters allowed

   param        =/ snd-refer-param
        ; Only sound parameters allowed

   value        = snd-inline-value
        ; Value MUST match value type

   value        =/ snd-refer-value
        ; Value MUST match value type

   snd-inline-value     = binary-value 
        ; Value MUST be "b" encoded audio content

   snd-inline-param     = ("VALUE" "=" "binary")
                        / ("ENCODING" "=" "b")
                        / ("TYPE" "=" *SAFE-CHAR)
        ; Value MUST be an IANA registered audio type

Notes:

There is an odd "CRLF" at the end of the "snd-inline-value" definition. No other definition for binary-values contains this.
The value definition was corrected to "snd-inline-value" as reported in Errata ID 1546.
I also removed an unmeant closing squared bracket in the VALUE-part of the "snd-inline-param" definition.

Errata ID: 1551
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Markus Lorenz
Date Reported: 2008-10-09
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-25

Section 4 says:

   ;For name="EMAIL"

 [...]

   email-type   = "INTERNET" / "X400" / iana-token / "X-" word
        ; Values are case insensitive

It should say:

   ;For name="EMAIL"

 [...]

   email-type   = "INTERNET" / "X400" / iana-token / x-name
        ; Values are case insensitive

Notes:

The email-type should contain a 'x-name' type instead of '"X-" word' for consistancy with tel-type, key-type and adr-type.
Although "word" appears several times, it is not defined at all!

RFC 2433, "Microsoft PPP CHAP Extensions", October 1998

Source of RFC: pppext (int)

Errata ID: 7742
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christophe Deleuze
Date Reported: 2023-12-28
Verifier Name: RFC Editor
Date Verified: 2024-01-02

The IESG Note says:

The protocol described here has significant vulnerabilities.  People
planning on implementing or using this protocol should read section
12, "Security Considerations".

It should say:

The protocol described here has significant vulnerabilities.  People
planning on implementing or using this protocol should read section
11, "Security Considerations".

Notes:

The section number is incorrect.

RFC 2445, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", November 1998

Note: This RFC has been obsoleted by RFC 5545

Source of RFC: calsch (app)

Errata ID: 435
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tilghman Lesher
Date Reported: 2003-01-11

Section 4.2.18 says:

   ORGANIZER;SENT-BY:"MAILTO:sray@host.com":MAILTO:jsmith@host.com

It should say:

   ORGANIZER;SENT-BY="MAILTO:sray@host.com":MAILTO:jsmith@host.com

Errata ID: 433
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dave Flater
Date Reported: 2004-01-07

Examples in various sections (2.4, 2.4.18, etc.)

     DESCRIPTION;ALTREP="http://www.wiz.org":The Fall'98 Wild Wizards
       Conference - - Las Vegas, NV, USA
[...]

     DESCRIPTION;ALTREP="CID:<part3.msg.970415T083000@host.com>":Project
       XYZ Review Meeting will include the following agenda items: (a)
       Market Overview, (b) Finances, (c) Project Management
[...]
     ORGANIZER;SENT-BY:"MAILTO:sray@host.com":MAILTO:jsmith@host.com
[...]
     LOCATION:Conference Room - F123, Bldg. 002

     LOCATION;ALTREP="http://xyzcorp.com/conf-rooms/f123.vcf":
      Conference Room - F123, Bldg. 002
[...]

      Atlanta, Georgia END:VEVENT END:VCALENDAR
[...]
     CATEGORY:Project Report, XYZ, Weekly Meeting

[...]
      Participants: John Smith, Jane Doe, Jim Dandy\n-It was

It should say:

     DESCRIPTION;ALTREP="http://www.wiz.org":The Fall'98 Wild Wizards
       Conference - - Las Vegas\, NV\, USA
[...]

     DESCRIPTION;ALTREP="CID:<part3.msg.970415T083000@host.com>":Project
       XYZ Review Meeting will include the following agenda items: (a)
       Market Overview\, (b) Finances\, (c) Project Management
[...]
     ORGANIZER;SENT-BY="mailto:sray@host.com":mailto:jsmith@host.com
[...]
     LOCATION:Conference Room - F123\, Bldg. 002

     LOCATION;ALTREP="http://xyzcorp.com/conf-rooms/f123.vcf":
      Conference Room - F123\, Bldg. 002
[...]

      Atlanta\, Georgia END:VEVENT END:VCALENDAR
[...]
     CATEGORIES:Project Report,XYZ,Weekly Meeting

[...]
      Participants: John Smith\, Jane Doe\, Jim Dandy\n-It was

Notes:

This report comes from the following diff.

The following diff on RFC 2445 as archived also incorporates the
change to Section 4.2.18 reported by Tilghman Lesher on 2003-01-12.

960c960
< Conference - - Las Vegas, NV, USA
- ---
> Conference - - Las Vegas\, NV\, USA
1027c1027
< Market Overview, (b) Finances, (c) Project Management
- ---
> Market Overview\, (b) Finances\, (c) Project Management
1664c1664
< ORGANIZER;SENT-BY:"mailto:sray@host.com":mailto:jsmith@host.com
- ---
> ORGANIZER;SENT-BY="mailto:sray@host.com":mailto:jsmith@host.com
4699c4699
< LOCATION:Conference Room - F123, Bldg. 002
- ---
> LOCATION:Conference Room - F123\, Bldg. 002
4702c4702
< Conference Room - F123, Bldg. 002
- ---
> Conference Room - F123\, Bldg. 002
7626c7626
< Atlanta, Georgia END:VEVENT END:VCALENDAR
- ---
> Atlanta\, Georgia END:VEVENT END:VCALENDAR
7760c7760
< CATEGORY:Project Report, XYZ, Weekly Meeting
- ---
> CATEGORIES:Project Report,XYZ,Weekly Meeting
7763c7763
< Definition
- ---
> Definition
7765c7765
< Participants: John Smith, Jane Doe, Jim Dandy\n-It was
- ---
> Participants: John Smith\, Jane Doe\, Jim Dandy\n-It was

Errata ID: 434
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ryan King
Date Reported: 2005-10-10
Verifier Name: Alexey Melnikov
Date Verified: 2009-10-01

Section 4.2.7 says:

    Example:

      ATTACH;FMTYPE=IMAGE/JPEG;ENCODING=BASE64;VALUE=BINARY:MIICajC
       CAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDA
       qBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRw
       <...remainder of "BASE64" encoded binary data...>

It should say:

    Example:

      ATTACH;FMTTYPE=IMAGE/JPEG;ENCODING=BASE64;VALUE=BINARY:MIICajC
               ^
       CAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDA
       qBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRw
       <...remainder of "BASE64" encoded binary data...>

Notes:

Typo in FMTTYPE.

Errata ID: 640
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dave Flater
Date Reported: 2004-01-07

Section 4.2 says:

DESCRIPTION;ALTREP="http://www.wiz.org":The Fall'98 Wild Wizards
  Conference - - Las Vegas, NV, USA

It should say:

DESCRIPTION;ALTREP="http://www.wiz.org":The Fall'98 Wild Wizards
  Conference - - Las Vegas\, NV\, USA

Errata ID: 641
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dave Flater
Date Reported: 2004-01-07

Section 4.2.1 says:

DESCRIPTION;ALTREP="CID:<part3.msg.970415T083000@host.com>":Project
XYZ Review Meeting will include the following agenda items: (a)
Market Overview, (b) Finances, (c) Project Management

It should say:

DESCRIPTION;ALTREP="CID:<part3.msg.970415T083000@host.com>":Project
XYZ Review Meeting will include the following agenda items: (a)
Market Overview\, (b) Finances\, (c) Project Management

Notes:

Errata ID: 642
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dave Flater
Date Reported: 2004-01-07

Section 4.8.1.7 says:

LOCATION:Conference Room - F123, Bldg. 002

LOCATION;ALTREP="http://xyzcorp.com/conf-rooms/f123.vcf":
Conference Room - F123, Bldg. 002

It should say:

LOCATION:Conference Room - F123\, Bldg. 002

LOCATION;ALTREP="http://xyzcorp.com/conf-rooms/f123.vcf":
Conference Room - F123\, Bldg. 002

Errata ID: 643
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dave Flater
Date Reported: 2004-01-07

Section 5 says:

DESCRIPTION:Networld+Interop Conference
and Exhibit\nAtlanta World Congress Center\n
Atlanta, Georgia END:VEVENT END:VCALENDAR

It should say:

DESCRIPTION:Networld+Interop Conference
and Exhibit\nAtlanta World Congress Center\n
Atlanta\, Georgia END:VEVENT END:VCALENDAR

Errata ID: 644
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dave Flater
Date Reported: 2004-01-07

Section 5 says:

CATEGORY:Project Report, XYZ, Weekly Meeting
DESCRIPTION:Project xyz Review Meeting Minutes\n
Agenda\n1. Review of project version 1.0 requirements.\n2.
Definition
of project processes.\n3. Review of project schedule.\n
Participants: John Smith, Jane Doe, Jim Dandy\n-It was

It should say:

CATEGORIES:Project Report,XYZ,Weekly Meeting
DESCRIPTION:Project xyz Review Meeting Minutes\n
Agenda\n1. Review of project version 1.0 requirements.\n2.
Definition of project processes.\n3. Review of project schedule.\n
Participants: John Smith\, Jane Doe\, Jim Dandy\n-It was

Notes:

The following change addresses the escaping of commas and two
unrelated issues: the spurious CATEGORY property and a line wrapping
error.

Errata ID: 1497
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Søren Løvborg
Date Reported: 2008-09-02
Verifier Name: Alexey Melnikov
Date Verified: 2009-10-01

Section 4.2.10 says:

   Example: 
 
     SUMMARY;LANGUAGE=us-EN:Company Holiday Party

It should say:

   Example: 
 
     SUMMARY;LANGUAGE=en-US:Company Holiday Party

Notes:

There is no "us-EN" language tag. See RFC 5646 for more details.

RFC 2453, "RIP Version 2", November 1998

Note: This RFC has been updated by RFC 4822

Source of RFC: ripv2 (rtg)

Errata ID: 2398
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Zdenek
Date Reported: 2010-07-29
Verifier Name: Adrian Farrel
Date Verified: 2010-08-21

Section 3.4 says:

A proof is given in [2] that this algorithm ....

It should say:

A proof is given in [5] that this algorithm....

Notes:

On page 8
Correct the reference.

Errata ID: 3437
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bharat Joshi
Date Reported: 2012-12-26
Verifier Name: Adrian Farrel
Date Verified: 2013-05-06

Section 3.9.1 says:

   There is one special case.  If there is exactly
   one entry in the request, and it has an address family identifier of
   zero and a metric of infinity (i.e., 16), then this is a request to
   send the entire routing table.

It should say:

   There is one special case. If there is exactly
   one entry in the request, (in addition to any authentication entry)
   and it has an address family identifier of zero and a metric of
   infinity (i.e., 16), then this is a request to send the entire 
   routing table.

Notes:

Note that in RFC 2453 an authentication header is not considered to be an RTE.

There was obviously some confusion on this point and the additional parenthetic text clarifies that if an authentication entry is also present (as the first entry) then it is not included in the special case described in section 3.9.1.

Errata ID: 3996
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramakrishna DTV
Date Reported: 2014-05-22
Verifier Name: Adrian Farrel
Date Verified: 2014-05-29

Section 3.4.2 says:

   Unfortunately, the question of how long convergence will take is not
   amenable to quite so simple an answer.  Before going any further, it
   will be useful to look at an example (taken from [2]).

It should say:

   Unfortunately, the question of how long convergence will take is not
   amenable to quite so simple an answer.  Before going any further, it
   will be useful to look at an example (taken from [5]).

Notes:

Correct the reference.

Errata ID: 3999
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramakrishna DTV
Date Reported: 2014-05-25
Verifier Name: Alia Atlas
Date Verified: 2014-05-28

Section 3.4 says:

"   4.ne The method so far only has a way to lower the metric, as the
   existing metric is kept until a smaller one shows up.  It is possible
   that the initial estimate might be too low."

It should say:

"  The method so far only has a way to lower the metric, as the
   existing metric is kept until a smaller one shows up.  It is possible
   that the initial estimate might be too low."

Notes:

Spurious text "4.ne"

RFC 2459, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", January 1999

Note: This RFC has been obsoleted by RFC 3280

Source of RFC: pkix (sec)

Errata ID: 432
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Yaron Sella
Date Reported: 2001-02-13

In Appendix D.3:

   0587 03 81 81      47: . BIT STRING

It should say:

   0587 03 81 81      129: . BIT STRING

RFC 2462, "IPv6 Stateless Address Autoconfiguration", December 1998

Note: This RFC has been obsoleted by RFC 4862

Source of RFC: ipngwg (int)

Errata ID: 431
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tim Shepard
Date Reported: 2004-08-10

It currently says:

2.  TERMINOLOGY

   IP - Internet Protocol Version 6.  The terms IPv4 and are used
        only in contexts where necessary to avoid ambiguity.

It should say:

2.  TERMINOLOGY

   IP - Internet Protocol Version 6.  The terms IPv4 and IPv6 are used
        only in contexts where necessary to avoid ambiguity.

RFC 2464, "Transmission of IPv6 Packets over Ethernet Networks", December 1998

Note: This RFC has been updated by RFC 6085, RFC 8064

Source of RFC: ipngwg (int)

Errata ID: 430
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Koch
Date Reported: 2004-04-29

The URL in this reference is incorrect:

   [EUI64] "Guidelines For 64-bit Global Identifier (EUI-64)",
           http://standards.ieee.org/db/oui/tutorials/EUI64.html

It should say:

   [EUI64] "Guidelines For 64-bit Global Identifier (EUI-64)",
           http://standards.ieee.org/regauth/oui/tutorials/EUI64.html

RFC 2474, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", December 1998

Note: This RFC has been updated by RFC 3168, RFC 3260, RFC 8436

Source of RFC: diffserv (tsv)

Errata ID: 3279
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Brian Carpenter
Date Reported: 2012-07-04
Verifier Name: Martin Stiemerling
Date Verified: 2012-07-12

Section Header says:

-

It should say:

Updates: 791

Notes:

RFC 2474 obsoletes RFC 1349. However, RFC 1349 updates RFC 791, by changing the definition of the Type of Service octet. RFC 2474 changes it again. Therefore, 2474 should also be marked as updating 791.

This does lead to occasional confusion, since the Type of Service octet is named as the Differentiated Services Field by RFC 2474.

RFC 2486, "The Network Access Identifier", January 1999

Note: This RFC has been obsoleted by RFC 4282

Source of RFC: roamops (ops)

Errata ID: 428
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Dale Worley
Date Reported: 2000-08-31

Section 3 says:

   x           = %x00-7F
                 ; all 127 ASCII characters, no exception

It should say:

   special     = "<" / ">" / "(" / ")" / "[" / "]" / "\" / "."
                  / "," / ";" / ":" / "@" / %x22  / Ctl
                 ; %x22 is '"'

Errata ID: 429
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jonathan Rosenberg
Date Reported: 2003-02-12

Section 3 says:

    nai         = username / ( username "@" realm )
    username    = dot-string
    realm       = realm "." label

It should say:

    realm       = [realm "."] label

RFC 2488, "Enhancing TCP Over Satellite Channels using Standard Mechanisms", January 1999

Source of RFC: tcpsat (tsv)

Errata ID: 5250
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Lloyd Wood
Date Reported: 2018-02-01
Verifier Name: Magnus Westerlund
Date Verified: 2019-03-27

Section 2 says:

   The
   propagation delay to a LEO orbit ranges from several milliseconds
   when communicating with a satellite directly overhead, to as much as
   80 ms when the satellite is on the horizon.

It should say:

The propagation delay to a LEO orbit ranges from several milliseconds
when communicating with a satellite directly overhead, to as much as
20 ms when the satellite is on the horizon.

Notes:

80 ms * speed of light gives 24,000 km,
which is a distance larger than MEO GPS altitude.

Given that the diameter of the Earth is just over 12,000 km,
a LEO satellite on the horizon will clearly not need that
propagation delay or light travel time to reach it.

(As it's defined as propagation delay,
we're not considering MAC retransmits.)

30ms gives up to 6000km slant path, which is barely
possible for a very high definition of LEO orbit that is
almost MEO. Tighten the value further, if you like, after
drawing a couple of circles and doing a bit of trigonometry.

This 80ms is being cited uncritically in papers
(found it in a recent PhD thesis),
so needs correction.

RFC 2489, "Procedure for Defining New DHCP Options", January 1999

Note: This RFC has been obsoleted by RFC 2939

Source of RFC: dhc (int)

Errata ID: 855
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Frank Ellermann
Date Reported: 2007-02-02
Verifier Name: Brian Haberman
Date Verified: 2012-07-24

Section 4 says:

   [3] Droms, R. and K. Fong, "NetWare/IP Domain Name and Information",
       RFC 2142, November 1997.

It should say:

   [3] Droms, R. and K. Fong, "NetWare/IP Domain Name and Information",
       RFC 2242, November 1997.

Notes:

References to RFC 2142 should be to 2242.

from pending

RFC 2516, "A Method for Transmitting PPP Over Ethernet (PPPoE)", February 1999

Source of RFC: Legacy
Area Assignment: int

Errata ID: 5634
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Chris Fletcher
Date Reported: 2019-02-11
Verifier Name: Eric Vyncke
Date Verified: 2023-08-03

Section Appendix A says:

If there is data, and the first octet of the data is nonzero, then
it MUST be a printable UTF-8 string which explains why the request
was denied.  This string MAY NOT be NULL terminated.

(multiple occurrences of "MAY NOT")

It should say:

If there is data, and the first octet of the data is nonzero, then
it MUST be a printable UTF-8 string which explains why the request
was denied.  This string MUST NOT be NULL terminated.

(all occurrences of "MAY NOT" must be changed to "MUST NOT")

Notes:

The keyword "MAY NOT" does not exist in RFC 2119. It should be "MUST NOT".

Errata ID: 7746
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Christophe Deleuze
Date Reported: 2024-01-01
Verifier Name: Éric Vyncke
Date Verified: 2024-01-12

Section 7 says:

      Field Check Sequence (FCS) Alternatives,

      Address-and-Control-Field-Compression (ACFC),

      Asynchronous-Control-Character-Map (ACCM)

It should say:

      FCS-Alternatives,

      Address-and-Control-Field-Compression (ACFC),

      Async-Control-Character-Map (ACCM)

Notes:

The names used for the first and third options is not the offical one (as defined on https://www.iana.org/assignments/ppp-numbers/ppp-numbers.xhtml#ppp-numbers-4 and in rfc1570 and rfc1662, respectively). Moreover, if FCS really had to be "expanded", it should be Frame (rather than Field) Ckeck Sequence. This is from common knowledge, and from rfc1570 appendix A.

Errata ID: 4759
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Patrick Timmons
Date Reported: 2016-08-03
Verifier Name: Erik Kline
Date Verified: 2023-06-10

Section 1 says:

   Concentrator.  With this model, each host utilizes it's own PPP stack

It should say:

   Concentrator.  With this model, each host utilizes its own PPP stack

Notes:

Typo.

Errata ID: 4760
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Patrick Timmons
Date Reported: 2016-08-03
Verifier Name: Erik Kline
Date Verified: 2023-06-10

Section 4 says:

   network byte order.  It's value is defined below for Discovery

It should say:

   network byte order.  Its value is defined below for Discovery

Notes:

Typo.

Errata ID: 4761
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Patrick Timmons
Date Reported: 2016-08-03
Verifier Name: Erik Kline
Date Verified: 2023-06-10

Section 8 says:

   of time, it SHOULD resend it's PADI packet and double the waiting

It should say:

   of time, it SHOULD resend its PADI packet and double the waiting

Notes:

Typo.

Errata ID: 5788
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bo Li
Date Reported: 2019-07-22
Verifier Name: RFC Editor
Date Verified: 2021-02-10

Section 7 says:

   It is RECOMMENDED that the Access Concentrator ocassionally send
   Echo-Request packets to the Host to determine the state of the
   session.  Otherwise, if the Host terminates a session without sending
   a Terminate-Request packet, the Access Concentrator will not be able
   to determine that the session has gone away.

It should say:

   It is RECOMMENDED that the Access Concentrator occasionally send
   Echo-Request packets to the Host to determine the state of the
   session.  Otherwise, if the Host terminates a session without sending
   a Terminate-Request packet, the Access Concentrator will not be able
   to determine that the session has gone away.

Notes:

Typo. The word "ocassionally" should be "occasionally".

RFC 2518, "HTTP Extensions for Distributed Authoring -- WEBDAV", February 1999

Note: This RFC has been obsoleted by RFC 4918

Source of RFC: webdav (app)

Errata ID: 426

Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2002-05-11
Report Text:

Errata for this document can be found at: http://www.webdav.org/wg/rfcdev/issues.htm

---

RFC 2526, "Reserved IPv6 Subnet Anycast Addresses", March 1999

Source of RFC: ipngwg (int)

Errata ID: 7659
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marc Muehlfeld
Date Reported: 2023-09-28
Verifier Name: RFC Editor
Date Verified: 2023-09-28

Section 2 says:

Specifically, for IPv6 address types required to have to have 64-bit
interface identifiers in EUI-64 format, these reserved subnet anycast
addresses are constructed as follows:

It should say:

Specifically, for IPv6 address types required to have 64-bit
interface identifiers in EUI-64 format, these reserved subnet anycast
addresses are constructed as follows:

Notes:

There is a duplicate "to have" in the sentence.

RFC 2527, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", March 1999

Note: This RFC has been obsoleted by RFC 3647

Source of RFC: pkix (sec)

Errata ID: 425
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sid Sidner
Date Reported: 2002-08-05

In the NOTES Section:

   1 The ABA Digital Signature Guidelines can be purchased from the ABA.
     See http://www.abanet.com for ordering details.

It should say:

   1 The ABA Digital Signature Guidelines can be purchased from the ABA.
     See http://www.abanet.org for ordering details.

RFC 2535, "Domain Name System Security Extensions", March 1999

Note: This RFC has been obsoleted by RFC 4033, RFC 4034, RFC 4035

Note: This RFC has been updated by RFC 2931, RFC 3007, RFC 3008, RFC 3090, RFC 3226, RFC 3445, RFC 3597, RFC 3655, RFC 3658, RFC 3755, RFC 3757, RFC 3845

Source of RFC: dnssec (sec)

Errata ID: 6529
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Samuels
Date Reported: 2021-04-12
Verifier Name: Benjamin Kaduk
Date Verified: 2021-04-14

Section 2.3.1 says:

   The syntax of a SIG resource record (signature) is described in
   Section 4.  It cryptographicly binds the RRset being signed to the
   signer and a validity interval.

It should say:

   The syntax of a SIG resource record (signature) is described in
   Section 4.  It cryptographically binds the RRset being signed to the
   signer and a validity interval.

Notes:

cryptographicly should be cryptographically

RFC 2544, "Benchmarking Methodology for Network Interconnect Devices", March 1999

Note: This RFC has been updated by RFC 6201, RFC 6815, RFC 9004

Source of RFC: Legacy
Area Assignment: ops

Errata ID: 421
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Lu Jian Xiong
Date Reported: 2002-08-07

Section 6 says:

   Since the tester both sends the test traffic and receives
   it back, after the traffic has been forwarded but the DUT, the tester
   can easily determine if all of the transmitted packets were received
   and verify that the correct packets were received.

It should say:

   Since the tester both sends the test traffic and receives
   it back, after the traffic has been forwarded by the DUT, the tester
   can easily determine if all of the transmitted packets were received
   and verify that the correct packets were received.

Errata ID: 423
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Scott Campbell
Date Reported: 2001-09-20

In Section C.2.2:

   The network addresses 192.18.0.0 through 198.19.255.255 are have been
   assigned to the BMWG by the IANA for this purpose.

It should say:

   The network addresses 198.18.0.0 through 198.19.255.255 have been
   assigned to the BMWG by the IANA for this purpose.

Errata ID: 424
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Shiang-Ming Huang
Date Reported: 2004-09-08

Section 3 says:

The authors understand that it will take a considerable period of time 
to perform all of the recommended tests nder  all of the recommended 
conditions. We believe that the results are worth the effort.  Appendix 
A lists some of the tests and conditions that we believe should be 
included for specific cases.

It should say:

The authors understand that it will take a considerable period of time 
to perform all of the recommended tests under all of the recommended 
conditions.  We believe that the results are worth the effort.  Appendix 
A lists some of the tests and conditions that we believe should be 
included for specific cases.

Notes:

Errata ID: 422
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Al Morton
Date Reported: 2006-11-05
Verifier Name: ron bonica
Date Verified: 2010-11-01

Section 26.1 says:

    Procedure:  Send a specific number of frames at a specific rate
    through the DUT and then count the frames that are transmitted by the
    DUT. If the count of offered frames is equal to the count of received
    frames, the fewer frames are received than were transmitted, the rate
    of the offered stream is reduced and the test is rerun.

It should say:

       Procedure:
       Send a specific number of frames at a specific rate through the
       DUT and then count the frames that are transmitted by the DUT. If
       the count of offered frames is equal to the count of received
       frames, the rate of the offered stream is raised and the test
       rerun.  If fewer frames are received than were transmitted, the
       rate of the offered stream is reduced and the test is rerun.

Errata ID: 4998
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Daniel Andrei Minca
Date Reported: 2017-04-18
Verifier Name: Benoit Claise
Date Verified: 2017-04-18

Section 2 says:

The authors understand that it will take a
   considerable period of time to perform all of the recommended tests
   nder  all of the recommended conditions.

It should say:

The authors understand that it will take a
   considerable period of time to perform all of the recommended tests
   under  all of the recommended conditions.

Notes:

It's missing the letter 'u'

RFC 2548, "Microsoft Vendor-specific RADIUS Attributes", March 1999

Source of RFC: radius (ops)

Errata ID: 420
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Hans-Ake Lund
Date Reported: 2005-02-04
Verifier Name: Dan Romascanu
Date Verified: 2010-05-10

Section 2.7.9 says:

   Description

      The MS-Secondary-NBNS-Server Attribute is used to indicate the
      address of the secondary DNS server to be used by the PPP peer.
      It MAY be included in both Access-Accept and Accounting-Request
      packets.

It should say:

   Description

      The MS-Secondary-NBNS-Server Attribute is used to indicate the
      address of the secondary NetBIOS Name Server (NBNS) [18] server to
      be used by the PPP peer.  It MAY be included in both Access-Accept
      and Accounting-Request packets.

Errata ID: 1607
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alan DeKok
Date Reported: 2008-11-18
Verifier Name: Dan Romascanu
Date Verified: 2010-05-10

Section 2.4.1 says:

The NT-Key sub-field is sixteen octets in length and contains the
first sixteen octets of the hashed Windows NT password.  The
format of the plaintext Keys field is illustrated in the following
diagram:

It should say:

The NT-Key sub-field is sixteen octets in length and contains the
first sixteen octets of the hash of the hashed Windows NT password.  The
format of the plaintext Keys field is illustrated in the following
diagram:

Notes:

See comments referring to RFC 2548 around line 1350 of:

http://github.com/alandekok/freeradius-server/tree/master/src%2Fmodules%2Frlm_mschap%2Frlm_mschap.c

This is interoperable with everything, including Windows.

RFC 2550, "Y10K and Beyond", April 1999

Source of RFC: INDEPENDENT

Errata ID: 6705
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alok Menghrajani
Date Reported: 2021-10-10
Verifier Name: RFC Editor
Date Verified: 2022-01-27

Section 3.4.2.4 says:

Where "n" is the number of leading carets and the fig, base26 and y10k functions are defined with the following recurrence relations:

It should say:

Where "n" is the number of leading carets and the fib, base26 and y10k functions are defined with the following recurrence relations:

Notes:

typo: s/fig/fib/

RFC 2557, "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", March 1999

Source of RFC: mhtml (app)

Errata ID: 418
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Les Kramer
Date Reported: 2001-01-07

In the reference:

   [REL]           Levinson, E., "The MIME Multipart/Related Content-
                   Type", RFC 2389, August 1998.

Notes:

The RFC number cited is incorrect; it should be RFC 2387.

Errata ID: 419
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2002-01-21

Section 4.2 says:

resolution of relative URIs). However, URI-s in Content-Location
headers (if absolute, or resolvable to absolute URIs) SHOULD still
be

It should say:

resolution of relative URIs). However, URIs in Content-Location
headers (if absolute, or resolvable to absolute URIs) SHOULD still be

Errata ID: 645
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2002-01-21

Section 9.2 says:

Content-Type: multipart/related; boundary="boundary-example";
       type="text/html"; start="<foo3@foo1@bar.net>"

--boundary-example
Content-Type: text/html;charset="US-ASCII"
Content-ID: <foo3@foo1@bar.net>

It should say:

Content-Type: multipart/related; boundary="boundary-example";
       type="text/html"; start="<foo3.foo1@bar.net>"

--boundary-example
Content-Type: text/html;charset="US-ASCII"
Content-ID: <foo3.foo1@bar.net>

Notes:

Errata ID: 646
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2002-01-21

Section 9.3 says:

Content-Location: images/ietflogo2.gif
; Note - Relative Content-Location is resolved by base
; specified in the Multipart/Related Content-Location heading

It should say:

Content-Location: images/ietflogo2.gif
Comments: Note - Relative Content-Location is resolved by base
specified in the Multipart/Related Content-Location heading

Errata ID: 647
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2002-01-21

Section 9.3 says:

Content-Location: images/ietflogo2.gif
; Note - Relative Content-Location is resolved by base
; specified in the Multipart/Related Content-Location heading

It should say:

Content-Location: images/ietflogo2.gif
Comments: Note - Relative Content-Location is resolved by base
specified in the Multipart/Related Content-Location heading

Errata ID: 648
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2002-01-21

Section 9.6 says:

Content-ID: <foo3@foo1@bar.net>

It should say:

Content-ID: <foo3.foo1@bar.net>

Errata ID: 649
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2002-01-21

Section 9.6 says:

Content-Type: multipart/related; boundary="boundary-example-2";
          type="text/html"
--boundary-example-2

It should say:

Content-Type: multipart/related; boundary="boundary-example-2";
          type="text/html"

--boundary-example-2

Notes:

Errata ID: 650
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2002-01-21

Section 9.6 says:

Content-ID: <foo4@foo1@bar.net>

It should say:

Content-ID: <foo4.foo1@bar.net>

Notes:

Errata ID: 651
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2002-01-21

Section 9.6 says:

Content-Type: multipart/related; boundary="boundary-example-3";
          type="text/html"
--boundary-example-3
Content-Type: text/html;charset="US-ASCII"
Content-ID: <4@foo@bar.net>

It should say:

Content-Type: multipart/related; boundary="boundary-example-3";
          type="text/html"

--boundary-example-3
Content-Type: text/html;charset="US-ASCII"
Content-ID: <4.foo@bar.net>

Notes:

RFC 2560, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", June 1999

Note: This RFC has been obsoleted by RFC 6960

Note: This RFC has been updated by RFC 6277

Source of RFC: pkix (sec)

Errata ID: 2253
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jim Schaad
Date Reported: 2010-05-12
Verifier Name: Tim Polk
Date Verified: 2010-07-20

Section 4.2.1 says:

UnknownInfo ::= NULL -- this can be replaced with an enumeration

It should say:

UnknownInfo ::= NULL

Notes:

The is no way to change this without making existing decoders fail decoding the answer. The comment should therefore be removed

The same line exists in the ASN.1 module and should be removed there as well.

Errata ID: 2329
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Shirley Carter
Date Reported: 2010-07-13
Verifier Name: Tim Polk
Date Verified: 2010-07-20

Section 4.2.2.2.1 says:

CAs issuing such a certificate should realized that

It should say:

CAs issuing such a certificate should realize that

Notes:

simple typo "realized" => "realize"

Errata ID: 3417
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Soltes
Date Reported: 2012-11-26
Verifier Name: Sean Turner
Date Verified: 2012-11-26

Section 4.2.2.2 says:

Systems or applications that rely on OCSP responses MUST be capable
of detecting and enforcing use of the id-ad-ocspSigning value as
described above.

and

3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage

It should say:

Systems or applications that rely on OCSP responses MUST be capable
of detecting and enforcing use of the id-kp-OCSPSigning value as
described above.

and

3. Includes a value of id-kp-ocspSigning in an ExtendedKeyUsage

Notes:

The first paragraph specifies that an "id-kp-OCSPSigning" value be included, and it then defines that value as "id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}", yet the second paragraph and the third listed alternative specify the use of an "id-ad-ocspSigning" value, which is not defined.

Also, the double quote mark at the end of the third listed alternative should be removed.

RFC 2565, "Internet Printing Protocol/1.0: Encoding and Transport", April 1999

Note: This RFC has been obsoleted by RFC 2910

Source of RFC: ipp (app)

Errata ID: 4805
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sean Leonard
Date Reported: 2016-09-18
Verifier Name: RFC Editor

Section 6. says:

   [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
             Specifications: ABNF", RFC 2234. November 1997.

It should say:

   [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
             Specifications: ABNF", RFC 2234, November 1997.

Notes:

The reference to RFC 2234 should have the "RFC 2234" series information followed by a comma (not a period).

RFC 2579, "Textual Conventions for SMIv2", April 1999

Source of RFC: Legacy

Errata ID: 415
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Juergen Schoenwaelder
Date Reported: 2001-12-07

Section 7.1.1 says:

   "The RowStatus textual convention is used to manage the
   creation and deletion of conceptual rows, and is used as the
   value of the SYNTAX clause for the status column of a
   conceptual row (as described in Section 7.7.1 of [2].)

It should say:

   "The RowStatus textual convention is used to manage the
   creation and deletion of conceptual rows, and is used as the
   value of the SYNTAX clause for the status column of a
   conceptual row (as described in Section 7.1.12 of [2].)

Errata ID: 417
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Juergen Schoenwaelder
Date Reported: 2001-07-31

Section 2 says:

RFC 2579 lists an invalid range for the year in the DateAndTime TC:

            field  octets  contents                  range
            -----  ------  --------                  -----
              1      1-2   year*                     0..65536

It should say:

            field  octets  contents                  range
            -----  ------  --------                  -----
              1      1-2   year*                     0..65535

Errata ID: 416
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Juergen Schoenwaelder
Date Reported: 2004-07-27

The DateAndTime textual convention did not originally define a special value which can be used in situations where a DateAndTime value is unknown or for some other reason not available. Several MIB modules on the IETF standards-track use the value '0000

              2       3    month                     1..12
              3       4    day                       1..31

It should say:

              2       3    month                 0 | 1..12
              3       4    day                   0 | 1..31

Notes:

RFC 2581, "TCP Congestion Control", April 1999

Note: This RFC has been obsoleted by RFC 5681

Note: This RFC has been updated by RFC 3390

Source of RFC: tcpimpl (tsv)

Errata ID: 414
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Noritoshi Demizu
Date Reported: 2004-06-10

Section 4.3 says:

   The algorithms outlined in [Hoe96,FF96,MM96a,MM6b] follow the
   principles of the basic four congestion control algorithms outlined
   in this document.

It should say:

   The algorithms outlined in [Hoe96,FF96,MM96a,MM96b] follow the
   principles of the basic four congestion control algorithms outlined
   in this document.

Notes:

RFC 2585, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", May 1999

Source of RFC: pkix (sec)

Errata ID: 1831
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Paul Hoffman
Date Reported: 2009-08-12
Verifier Name: Tim Polk
Date Verified: 2010-07-20

Section 4.1 and 4.2 says:

Optional parameters: version (default value is "1")

It should say:

Optional parameters: none

[Note: legacy implementations MAY include a version parameter, which SHOULD be ignored if present.]

Notes:

The optional parameters is ambiguous because it does not state what the version refers to. It is unlikely to be the version of PKIX, because RFC 2459 preceded this document, and the versions of the PKIX format described in RFC 2459 was 2 and 3. The authors note that we did not have a reference to the PKIX specification. Because of this, we suggest that the "version" parameter be ignored if present, and that no assumption of what the default of "1" means. Further, we suggest that "version" not be used when generating MIME bodies.

RFC 2608, "Service Location Protocol, Version 2", June 1999

Note: This RFC has been updated by RFC 3224

Source of RFC: svrloc (int)

Errata ID: 4290
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Peter Budny
Date Reported: 2015-03-06
Verifier Name: Brian Haberman
Date Verified: 2015-03-09

Section 4.1 says:

This substring is the Naming Authority, as described in Section 9.6.

It should say:

This substring is the Naming Authority, as described in Section 4.2.

RFC 2616, "Hypertext Transfer Protocol -- HTTP/1.1", June 1999

Note: This RFC has been obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235

Note: This RFC has been updated by RFC 2817, RFC 5785, RFC 6266, RFC 6585

Source of RFC: http (app)

Errata ID: 408
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Greg Robson
Date Reported: 2001-10-08

Section 3.6 says:

   The Internet Assigned Numbers Authority (IANA) acts as a registry for
   transfer-coding value tokens. Initially, the registry contains the
   following tokens: "chunked" (section 3.6.1), "identity" (section
   3.6.2), "gzip" (section 3.5), "compress" (section 3.5), and
   "deflate" (section 3.5).

Notes:

There is no section 3.6.2; there is no such thing as Transfer-Coding:
identity in the RFC 2616 specification (note that there would not be
quotes around "identity" in the actual header!).

Errata ID: 412

Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Justin Erenkrantz
Date Reported: 2001-01-05
Report Text:

From Scott Lawrence:
All known errata for this HTTP RFC will be found at: 
http://purl.org/NET/http-errata and 
http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/

---

Errata ID: 411
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: WooJin Chung
Date Reported: 2006-10-31
Verifier Name: Barry Leiba
Date Verified: 2014-06-03

Section 14.3 says:

The Accept-Encoding request-header field is similar to Accept, but
restricts the content-codings (section 3.5) that are acceptable in
the response.

       Accept-Encoding  = "Accept-Encoding" ":"

                          1#( codings [ ";" "q" "=" qvalue ] )
       codings          = ( content-coding | "*" )

 Examples of its use are:

       Accept-Encoding: compress, gzip
       Accept-Encoding:
       Accept-Encoding: *
       Accept-Encoding: compress;q=0.5, gzip;q=1.0
       Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0

It should say:

The Accept-Encoding request-header field is similar to Accept, but
restricts the content-codings (section 3.5) that are acceptable in
the response.

       Accept-Encoding  = "Accept-Encoding" ":"

                          1#( codings [ ";" "q" "=" qvalue ] )
       codings          = ( content-coding | "*" )

 Examples of its use are:

       Accept-Encoding: compress, gzip
       Accept-Encoding: *
       Accept-Encoding: compress;q=0.5, gzip;q=1.0
       Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0

Notes:

As you can see, Accept-Encoding has to consist of 1 or more ( codings [ ";"
"q" "=" qvalue ] ). So you can't just leave the value of "Accept-Encoding:"
empty. The second example is, therefore, incorrect.

------------------------------------------------
Alexey: This issue was fixed in HTTPBIS WG, see <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/25>

Errata ID: 652
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Justin Erenkrantz
Date Reported: 2000-12-23

Section 4.4 says:

4.If the message uses the media type "multipart/byteranges", and the
  ransfer-length is not otherwise specified, then this self-
  elimiting media type defines the transfer-length. This media type
  UST NOT be used unless the sender knows that the recipient can arse
  it; the presence in a request of a Range header with ultiple byte-
  range specifiers from a 1.1 client implies that the lient can parse
  multipart/byteranges responses.

It should say:

4.If the message uses the media type "multipart/byteranges", and the
  Transfer-length is not otherwise specified, then this self-
  delimiting media type defines the transfer-length. This media type
  MUST NOT be used unless the sender knows that the recipient can parse
  it; the presence in a request of a Range header with multiple byte-
  range specifiers from a 1.1 client implies that the client can parse
  multipart/byteranges responses.

Notes:

Missing the first character of 6 words.

Errata ID: 653
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Justin Erenkrantz
Date Reported: 2000-12-23

Section 1.3 says:

Each of these representations is termed a `varriant'.

It should say:

Each of these representations is termed a `variant'.

Errata ID: 4522
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christophe JAILLET
Date Reported: 2015-11-03
Verifier Name: Barry Leiba
Date Verified: 2016-01-21

Section 13.5.1 says:

 The following HTTP/1.1 headers are hop-by-hop headers:

      - Connection
      - Keep-Alive
      - Proxy-Authenticate
      - Proxy-Authorization
      - TE
      - Trailers
      - Transfer-Encoding
      - Upgrade

It should say:

 The following HTTP/1.1 headers are hop-by-hop headers:

      - Connection
      - Keep-Alive
      - Proxy-Authenticate
      - Proxy-Authorization
      - TE
      - Trailer
      - Transfer-Encoding
      - Upgrade

Notes:

Trailers (with a s) does not seem to a header field, just a keyword for TE.
I think that Trailer (without a s) is expected here.

AFAIK, RFC 7230 does not have such an explicit list and is not concerned.

RFC 2617, "HTTP Authentication: Basic and Digest Access Authentication", June 1999

Note: This RFC has been obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617

Source of RFC: http (app)

Errata ID: 410

Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Scott Lawrence
Date Reported: 2001-01-05
Report Text:

All known errata for this HTTP RFC will be found at: 
http://purl.org/NET/http-errata and 
http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/

---

Errata ID: 1649
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ganga Mahesh Siddem
Date Reported: 2009-01-08
Verifier Name: Peter Saint-Andre
Date Verified: 2012-03-21

Section 5 says:

 /* calculate H(A1) as per spec */
      void DigestCalcHA1(
          IN char * pszAlg,
          IN char * pszUserName,
          IN char * pszRealm,
          IN char * pszPassword,
          IN char * pszNonce,
          IN char * pszCNonce,
          OUT HASHHEX SessionKey
          )
      {
            MD5_CTX Md5Ctx;
            HASH HA1;

            MD5Init(&Md5Ctx);
            MD5Update(&Md5Ctx, pszUserName, strlen(pszUserName));
            MD5Update(&Md5Ctx, ":", 1);
            MD5Update(&Md5Ctx, pszRealm, strlen(pszRealm));
            MD5Update(&Md5Ctx, ":", 1);
            MD5Update(&Md5Ctx, pszPassword, strlen(pszPassword));
            MD5Final(HA1, &Md5Ctx);
            if (stricmp(pszAlg, "md5-sess") == 0) {
                  MD5Init(&Md5Ctx);
|                 MD5Update(&Md5Ctx, HA1, HASHLEN);
                  MD5Update(&Md5Ctx, ":", 1);
                  MD5Update(&Md5Ctx, pszNonce, strlen(pszNonce));
                  MD5Update(&Md5Ctx, ":", 1);
                  MD5Update(&Md5Ctx, pszCNonce, strlen(pszCNonce));
                  MD5Final(HA1, &Md5Ctx);
            };
            CvtHex(HA1, SessionKey);
      };

It should say:

 /* calculate H(A1) as per spec */
      void DigestCalcHA1(
          IN char * pszAlg,
          IN char * pszUserName,
          IN char * pszRealm,
          IN char * pszPassword,
          IN char * pszNonce,
          IN char * pszCNonce,
          OUT HASHHEX SessionKey
          )
      {
            MD5_CTX Md5Ctx;
            HASH HA1;
|           HASHHEX HA1Hex;

            MD5Init(&Md5Ctx);
            MD5Update(&Md5Ctx, pszUserName, strlen(pszUserName));
            MD5Update(&Md5Ctx, ":", 1);
            MD5Update(&Md5Ctx, pszRealm, strlen(pszRealm));
            MD5Update(&Md5Ctx, ":", 1);
            MD5Update(&Md5Ctx, pszPassword, strlen(pszPassword));
            MD5Final(HA1, &Md5Ctx);
            if (stricmp(pszAlg, "md5-sess") == 0) {
|                 CvtHex(HA1, HA1Hex);
                  MD5Init(&Md5Ctx);
|                 MD5Update(&Md5Ctx, HA1Hex, HASHHEXLEN);
                  MD5Update(&Md5Ctx, ":", 1);
                  MD5Update(&Md5Ctx, pszNonce, strlen(pszNonce));
                  MD5Update(&Md5Ctx, ":", 1);
                  MD5Update(&Md5Ctx, pszCNonce, strlen(pszCNonce));
                  MD5Final(HA1, &Md5Ctx);
            };
            CvtHex(HA1, SessionKey);
      };

Notes:

DigestCalcHA1 sample implemention has to be corrected.

Errata ID: 1959
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2009-12-10
Verifier Name: Alexey Melnikov
Date Verified: 2009-12-27

Section 1.2 p4 says:

       credentials = auth-scheme #auth-param

It should say:

       credentials = auth-scheme ( token | quoted-string | #auth-param )

Notes:

Alexey Melnikov (updated as per suggestion from Paul Leach):

auth-param doesn't allow for parameters with no '=', so Basic is non conformant to the generic syntax.

Multiple versions of token/quoted-string (with no attribute name) is not allowed, as none of the existing scheme not using auth-param supports that.

(Note that RFC 2617 is using BNF from RFC 2616, which allows for implied LWS.)

Errata ID: 2600
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Victor S. Osipov
Date Reported: 2010-11-02
Verifier Name: Peter Saint-Andre
Date Verified: 2011-07-14

Section 3.2.2 says:

digest-uri       = "uri" "=" digest-uri-value
digest-uri-value = request-uri   ; As specified by HTTP/1.1

It should say:

digest-uri       = "uri" "=" <"> digest-uri-value <">
digest-uri-value = request-uri   ; As specified by HTTP/1.1

Notes:

This is an error here that the digest-uri-value is not enclosed in quotation marks;
see the correct example in Section 3.5:

Authorization: Digest username="Mufasa",
realm="testrealm@host.com",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="/dir/index.html",
. . .

Errata ID: 3720
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Brett Tate
Date Reported: 2013-09-06
Verifier Name: Barry Leiba
Date Verified: 2013-09-06

Section 3.2.2.4 says:

username="Mufasa", realm=myhost@testrealm.com

It should say:

username="Mufasa", realm="myhost@testrealm.com"

Notes:

The realm value within the Authorization header example is missing the quotes.

Errata ID: 606
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2007-10-17
Verifier Name: Alexey Melnikov
Date Verified: 2009-12-21

Section 3.6 says:

These headers are instances of the Proxy-Authenticate and
Proxy-Authorization headers specified in sections 10.33 and 10.34 of the
HTTP/1.1 specification [2] ...

It should say:

These headers are instances of the Proxy-Authenticate and
Proxy-Authorization headers specified in sections 14.33 and 14.34 of the
HTTP/1.1 specification [2] ...

Notes:

Wrong section references in RFC 2616.

Reported by Julian Reschke on an IETF mailing list.

Errata ID: 1431
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stefan Santesson
Date Reported: 2008-05-29
Verifier Name: Alexey Melnikov
Date Verified: 2009-12-21

Section 3.2.2.1 says:

   If the "qop" value is "auth" or "auth-int":

      request-digest  = <"> < KD ( H(A1),     unq(nonce-value)
                                          ":" nc-value
                                          ":" unq(cnonce-value)
                                          ":" unq(qop-value)
                                          ":" H(A2)
                                  ) <">

It should say:

   If the "qop" value is "auth" or "auth-int":

      request-digest  = <"> < KD ( H(A1),     unq(nonce-value)
                                          ":" nc-value
                                          ":" unq(cnonce-value)
                                          ":" unq(qop-value)
                                          ":" H(A2)
                                  ) > <">

Notes:

The ">" bracket is missing in the final line, closing the "<" bracket of the first line in "< KD ( H(A1)"...

RFC 2622, "Routing Policy Specification Language (RPSL)", June 1999

Note: This RFC has been updated by RFC 4012, RFC 7909

Source of RFC: rps (ops)

Errata ID: 7564
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jiang Li
Date Reported: 2023-07-13
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2024-01-15

Section 5.6 says:

In page 26 of RFC2622
In the following example 9.9.9.1 imports 128.9.0.0/16 from 9.9.9.2
 and 9.9.9.3.
 (7) peering-set: prng-bar
 peering: AS1 at 9.9.9.1
 peering-set: prng-foo
 peering: prng-bar
 peering: AS2 at 9.9.9.1
 aut-num: AS1
 import: from prng-foo accept { 128.9.0.0/16 }

It should say:

In the following example 9.9.9.1 imports 128.9.0.0/16 from 9.9.9.2
 and 9.9.9.3.
 (7) peering-set: prng-bar
 peering: AS3 at 9.9.9.1
 peering-set: prng-foo
 peering: prng-bar
 peering: AS2 at 9.9.9.1
 aut-num: AS1
 import: from prng-foo accept { 128.9.0.0/16 }

Notes:

As "Figure 22: Example topology consisting of three ASes, AS1, AS2, and
AS3; two exchange points, EX1 and EX2; and six routers." shows, the router 9.9.9.1 of AS1 connects to the router 9.9.9.3 of AS3 in exchange point 2. It states that "In the following example 9.9.9.1 imports 128.9.0.0/16 from 9.9.9.2 and 9.9.9.3.", so I think the corresponding AS of 9.9.9.3 should be AS3 instead of AS1.

Errata ID: 6588
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Benjamin Kaduk
Date Reported: 2021-05-20
Verifier Name: Robert Wilton
Date Verified: 2024-01-12

Throughout the document, when it says:

authenticaiton

It should say:

authentication

Notes:

The typo appears in section 3 (twice) and section 3.1 (once)

RFC 2625, "IP and ARP over Fibre Channel", June 1999

Note: This RFC has been obsoleted by RFC 4338

Source of RFC: ipfc (int)

Errata ID: 407
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Elizabeth G. Rodriguez
Date Reported: 2003-07-21

Section 7.1 says:

1. This table applies only to FC-4 related data, such as IP and
   ARP packets. This table does not apply to link services and
   other non-FC-4 sequences (PLOGI, for example) that must occur
   for normal operation.

It should say:

1. This table does not apply to FARP-REQ and FARP-REPLY.

Errata ID: 655
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Elizabeth G. Rodriguez
Date Reported: 2003-07-21

Section 7.2 says:

       1. This is REQUIRED for FC-4 (IP and ARP) packets

         - Routing bits of R_CTL field MUST indicate Device Data
           frames (0000)
         - Information Category of R_CTL field MUST indicate
           Unsolicited Data (0100)

It should say:

       1. This is REQUIRED for FC-4 (IP and ARP) packets

         - Routing bits of R_CTL field MUST indicate Device Data
           frames (0000)
         - Information Category of R_CTL field MUST indicate
           Unsolicited Data (0100)
           
           This does not apply to FARP-REQ and FARP-REPLY.

Notes:

Add a blank line and the sentence:
This does not apply to FARP-REQ and FARP-REPLY.
indented as shown so that it applies to both bulleted items.

Errata ID: 656
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Elizabeth G. Rodriguez
Date Reported: 2003-07-21

Section E.4.2 says:

      Code Points for FC Frame with FARP-REQ Command for MATCH_WW_PN_NN
 +---+----------------+----------------+----------------+------------+
 |Wrd|    <31:24>     |    <23:16>     |    <15:08>     |    <07:00> |
 +---+----------------+----------------+----------------+------------+
 | 0 |    0x04        |                     D_ID =                   |
 |   |                |    0xFF             0xFF              0xFF   |
 +---+----------------+----------------+----------------+------------+
 | 1 |    0x00        |                     S_ID                     |
 +---+----------------+----------------+----------------+------------+
 | 2 |    0x05        |                     F_CTL                    |
 +---+----------------+----------------+----------------+------------+
 | 3 |   SEQ_ID       |     0x20       |          SEQ_CNT            |
 +---+----------------+----------------+----------------+------------+

It should say:

      Code Points for FC Frame with FARP-REQ Command for MATCH_WW_PN_NN
 +---+----------------+----------------+----------------+------------+
 |Wrd|    <31:24>     |    <23:16>     |    <15:08>     |    <07:00> |
 +---+----------------+----------------+----------------+------------+
 | 0 |    0x22        |                     D_ID =                   |
 |   |                |    0xFF             0xFF              0xFF   |
 +---+----------------+----------------+----------------+------------+
 | 1 |    0x00        |                     S_ID                     |
 +---+----------------+----------------+----------------+------------+
 | 2 |    0x01        |                     F_CTL                    |
 +---+----------------+----------------+----------------+------------+
 | 3 |   SEQ_ID       |     0x00       |          SEQ_CNT            |
 +---+----------------+----------------+----------------+------------+

Notes:

This embodies three changes:
- R_CTL (word 0, bits 31:24) should be 0x22, not 0x04
- TYPE (word 2, bits 31:24) should be 0x01, not 0x05
- DF_CTL (word 3, bits 23:16) should be 0x00, not 0x20

Errata ID: 657
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Elizabeth G. Rodriguez
Date Reported: 2003-07-21

Section E.4.2 says:

             Code Points for FC Frame with FARP-REPLY Command
 +---+----------------+----------------+----------------+------------+
 |Wrd|    <31:24>     |    <23:16>     |    <15:08>     |    <07:00> |
 +---+----------------+----------------+----------------+------------+
 | 0 |    0x04        |                     D_ID                     |
 +---+----------------+----------------+----------------+------------+
 | 1 |    0x00        |                     S_ID                     |
 +---+----------------+----------------+----------------+------------+
 | 2 |    0x05        |                     F_CTL                    |
 +---+----------------+----------------+----------------+------------+
 | 3 |   SEQ_ID       |     0x20       |          SEQ_CNT            |
 +---+----------------+----------------+----------------+------------+

It should say:

             Code Points for FC Frame with FARP-REPLY Command
 +---+----------------+----------------+----------------+------------+
 |Wrd|    <31:24>     |    <23:16>     |    <15:08>     |    <07:00> |
 +---+----------------+----------------+----------------+------------+
 | 0 |    0x23        |                     D_ID                     |
 +---+----------------+----------------+----------------+------------+
 | 1 |    0x00        |                     S_ID                     |
 +---+----------------+----------------+----------------+------------+
 | 2 |    0x01        |                     F_CTL                    |
 +---+----------------+----------------+----------------+------------+
 | 3 |   SEQ_ID       |     0x00       |          SEQ_CNT            |
 +---+----------------+----------------+----------------+------------+

Notes:

This embodies three changes:
- R_CTL (word 0, bits 31:24) should be 0x23, not 0x04
- TYPE (word 2, bits 31:24) should be 0x01, not 0x05
- DF_CTL (word 3, bits 23:16) should be 0x00, not 0x20

RFC 2626, "The Internet and the Millennium Problem (Year 2000)", June 1999

Source of RFC: 2000 (ops)

Errata ID: 2753
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-03-25
Verifier Name: Ron Bonica
Date Verified: 2011-03-26

Section 3.6 says:

3.6 "Network News"


   There does exist a problem in both NNTP, RFC 977, and the Usenet News
   Message Format, RFC 10336.  They both specify two-digit year format.
   A working group has been formed to update the network news protocols
   in general, and addressing this problem is on their list of work
   items.

It should say:

3.6 "Network News"


   There does exist a problem in both NNTP, RFC 977, and the Usenet News
   Message Format, RFC 1036.  They both specify two-digit year format.
   A working group has been formed to update the network news protocols
   in general, and addressing this problem is on their list of work
   items.

Notes:

s/RFC 10336/RFC 1036

RFC 2630, "Cryptographic Message Syntax", June 1999

Note: This RFC has been obsoleted by RFC 3369, RFC 3370

Source of RFC: smime (sec)

Errata ID: 406
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Joseph Baran
Date Reported: 2000-12-26

Section 12.2.2 says:

The RSA signature algorithm is defined in RFC 2347 [NEWPKCS#1].  RFC
2347 specifies the use of the RSA signature algorithm with the SHA-1
and MD5 message digest algorithms.

It should say:

The RSA signature algorithm is defined in RFC 2437 [NEWPKCS#1].  RFC
2437 specifies the use of the RSA signature algorithm with the SHA-1
and MD5 message digest algorithms.

Errata ID: 658
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Joseph Baran
Date Reported: 2000-12-26

Section Reference says:

NEWPKCS#1  Kaliski, B., "PKCS #1: RSA Encryption, Version 2.0",
           RFC 2347, October 1998.

It should say:

NEWPKCS#1  Kaliski, B., "PKCS #1: RSA Encryption, Version 2.0",
           RFC 2437, October 1998.

RFC 2631, "Diffie-Hellman Key Agreement Method", June 1999

Source of RFC: smime (sec)

Errata ID: 2506
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Yves Legrandgerard
Date Reported: 2010-09-01
Verifier Name: Sean Turner
Date Verified: 2012-01-06

Section 2.2.1.1 says:

6. For i = 0 to m' - 1

        U = U + (SHA1[SEED + i] XOR SHA1[(SEED + m' + i)) * 2^(160 * i)

   Note that for m=160, this reduces to the algorithm of [FIPS-186]

        U = SHA1[SEED] XOR SHA1[(SEED+1) mod 2^160 ].

It should say:

6. For i = 0 to m' - 1

        U = U + [SHA1(seed + i) Xor SHA1((seed + m' +i ) mod 2^{seedlen})] * 2^{160 * i}

   Note that for m=160, this reduces to the algorithm of [FIPS-186]

        U = [SHA1(seed) Xor SHA1((seed +1) mod 2^{seedlen})], where seedlen
            is the binary length of seed.

Notes:

The line:
U = U + (SHA1[SEED + i] XOR SHA1[(SEED + m' + i)) * 2^(160 * i)
is syntactically incorrect. Closing bracket of last 'SHA1[' is missing.
Moreover, when m=160 (m'=1), the loop cannot reduce to the line:
U = SHA1[SEED] XOR SHA1[(SEED + 1) mod 2^160]
as it can be easily seen.

Errata ID: 5480
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Charlie Zhuo
Date Reported: 2018-08-27
Verifier Name: Benjamin Kaduk
Date Verified: 2018-08-28

Section 2.1.1 says:

h is any integer with 1 < h < p-1 such that h{(p-1)/q} mod p > 1
(g has order q mod p; i.e. g^q mod p = 1 if g!=1)

It should say:

h is any integer with 1 < h < p-1 such that h^{(p-1)/q} mod p > 1
(g has order q mod p; i.e. g^q mod p = 1 if g!=1)

Notes:

The explanation of h omitted the exponentiation operator in the inline formula.

Errata ID: 5897
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2019-11-07
Verifier Name: Roman Danyliw
Date Verified: 2022-01-19

Section 2.1.2 says:

     KeySpecificInfo ::= SEQUENCE {
       algorithm OBJECT IDENTIFIER,
       counter OCTET STRING SIZE (4..4) }

It should say:

     KeySpecificInfo ::= SEQUENCE {
       algorithm OBJECT IDENTIFIER,
       counter OCTET STRING (SIZE (4..4)) }

Notes:

The addition of '(' and ')' are needed for an ASN.1 compiler to accept the syntax without raising an error.

Errata ID: 7761
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2024-01-12
Verifier Name: RFC Editor
Date Verified: 2024-01-16

Section 2.2.1.1 says:

   6. If p > 2^(L-1) use a robust primality test to test whether p is
      prime. Else go to 18.

It should say:

   16. If p > 2^(L-1) use a robust primality test to test whether p is
       prime. Else go to 18.

Notes:

This should be numbered as step 16, not step 6.

RFC 2633, "S/MIME Version 3 Message Specification", June 1999

Note: This RFC has been obsoleted by RFC 3851

Source of RFC: smime (sec)

Errata ID: 405
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Joni Yrjana
Date Reported: 2003-03-12

Section 3.5 says:

   This may be useful in an environment were automatic signature
   verification is desired, as no private key material is required to
   verify a signature.

It should say:

   This may be useful in an environment where automatic signature
   verification is desired, as no private key material is required to
   verify a signature.

Errata ID: 5019
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Josh Soref
Date Reported: 2017-05-14
Verifier Name: Paul Wouters
Date Verified: 2024-01-12

Section 5 says:

id-aa-encrypKeyPref OBJECT IDENTIFIER ::= {id-aa 11}

It should say:

id-aa-encrypKeyPref [sic] OBJECT IDENTIFIER ::= {id-aa 11}

Notes:

encryp isn't a word, it's a typo. Unfortunately, like http's (rfc1945) referer [sic] before it, this is now part of the API.

This error should be highlighted (as rfc2068 does for referer [sic]) so that people are aware that the natural spelling doesn't apply.

If it's possible for a revised RFC to be published suggesting the correct spelling w/ a way for clients/servers to handle the old spelling, that would be nice, but based on precedent, that seems unlikely.

---
Kathleen Moriarty: As AD, this discussion needs to be continued and possibly with a different draft. As such, I am marking this as hold for document update and listing it as editorial so that there are no n the wire changes at this time with this errata.
----
There was quite a bit of on list discussion that should be reviewed for any future changes.

One summary from the discussion:
he mailing list participants are copied on these errata to get their opinion in order to inform the AD how to dispose of the errata. Most folks are just making their opinions known.

1) The next thing that folks look at is whether it’s technical or not. Debate ensues, but generally technical errata are those that affect interoperability. This one I don’t think does because there are no changes to the bits on the wire.

2) And, well folks want to get lots of changes, but the change has to run through the consensus process (back to mailing list input).

So to the import bit:

As I see it, there are two ways to get the note incorporated:

1. Write a draft that adds the note; this seems a bit heavy weight for what you are trying to do.

2. Apply the note to the latest RFC/draft that obsoletes RFC 2633; I guess you went for upstream, but generally the IETF applies changes to the latest/greatest RFC/draft. That obsoletes chain is: RFC 3851 obsoleted RFC 2633, RFC 3851 was obsoleted by RFC 5751, and draft-ietf-lamps-rfc5751-bis is about to obsolete RFC 5751. Luckily, draft-ietf-lamps-rfc5751-bis isn’t yet an RFC so there’s an option to have the note added there.

Any objections to adding a note in draft-ietf-lamps-rfc5751-bis along the same lines as the note for receipentKeyId?

Paul Wouters (AD): This note made it into RFC 8551, so marking this errata Verified to close it

RFC 2637, "Point-to-Point Tunneling Protocol (PPTP)", July 1999

Source of RFC: pppext (int)

Errata ID: 6287
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Casper van Eersel
Date Reported: 2020-09-13
Verifier Name: Eric Vyncke
Date Verified: 2023-08-03

Section 3.2.3 says:

When the PAC receives the Outgoing-Call-Reply, it attempts to connect the call, assuming the calling party has not hung up.

It should say:

When the PAC receives the Incoming-Call-Reply, it attempts to connect the call, assuming the calling party has not hung up.

Notes:

The PAC does not receive Outgoing-Call-Reply messages, as also indicated in sections 3.2.4.1 and 3.2.4.2. It receives Incoming-Call-Reply messages, as indicated in sections 3.2.3.1 and 3.2.3.2.

Errata ID: 4790
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2016-09-01

Section 2.2 says:

   Error Code               This field is set to 0 unless a "General
                            Error" exists, in which case Result Code is
                            set to 2 and this field is set to the value
                            corresponding to the general error condition
                            as specified in section 2.2.

It should say:

   Error Code               This field is set to 0 unless a "General
                            Error" exists, in which case Result Code is
                            set to 2 and this field is set to the value
                            corresponding to the general error condition
                            as specified in section 2.16.

Notes:

Incorrect reference to section 2.2.

Note - Similar pointers occur in Sections 2.4, 2.6, 2.8, 2.10, 2.13.

Errata ID: 4791
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2016-09-01
Verifier Name: Éric Vyncke
Date Verified: 2024-01-12

Section 2.4 says:

   Error Code               This field is set to 0 unless a "General
                            Error" exists, in which case Result Code is
                            set to 2 and this field is set to the value
                            corresponding to the general error condition
                            as specified in section 2.2.

It should say:

   Error Code               This field is set to 0 unless a "General
                            Error" exists, in which case Result Code is
                            set to 2 and this field is set to the value
                            corresponding to the general error condition
                            as specified in section 2.16.

Notes:

Incorrect reference to section 2.2

Errata ID: 4792
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2016-09-01
Verifier Name: Éric Vyncke
Date Verified: 2024-01-12

Section 2.6 says:

   Error Code               This field is set to 0 unless a "General
                            Error" condition exists, in which case
                            Result Code is set to 2 and this field is
                            set to the value corresponding to the
                            general error condition as specified in
                            section 2.2.

It should say:

   Error Code               This field is set to 0 unless a "General
                            Error" condition exists, in which case
                            Result Code is set to 2 and this field is
                            set to the value corresponding to the
                            general error condition as specified in
                            section 2.16.

Notes:

Incorrect reference to section 2.2

Errata ID: 4793
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2016-09-01
Verifier Name: Éric Vyncke
Date Verified: 2024-01-12

Section 2.8 says:

   Error Code               This field is set to 0 unless a "General
                            Error" condition exists, in which case
                            Result Code is set to 2 and this field is
                            set to the value corresponding to the
                            general error condition as specified in
                            section 2.2.

It should say:

   Error Code               This field is set to 0 unless a "General
                            Error" condition exists, in which case
                            Result Code is set to 2 and this field is
                            set to the value corresponding to the
                            general error condition as specified in
                            section 2.16.

Notes:

Incorrect reference to section 2.2.

RFC 2638, "A Two-bit Differentiated Services Architecture for the Internet", July 1999

Source of RFC: Legacy

Errata ID: 5361
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Greg Skinner
Date Reported: 2018-05-15
Verifier Name: Mirja Kühlewind
Date Verified: 2018-05-16

Section Appendix says:

After the draft-nichols-diff-svc-00 was submitted, the co-authors had
a discussion with Dave Clark and John Wroclawski which resulted in
Clark's using the presentation slot for the draft at the December
1997 IETF Integrated Services Working Group meeting.

It should say:

After the draft-nichols-diff-svc-arch-00 was submitted, the co-authors
had a discussion with Dave Clark and John Wroclawski which resulted in
Clark's using the presentation slot for the draft at the December
1997 IETF Integrated Services Working Group meeting.

Notes:

The original text refers to a draft that never existed.

RFC 2645, "ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses", August 1999

Source of RFC: Legacy
Area Assignment: app

Errata ID: 404
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tony Finch
Date Reported: 2005-08-30
Verifier Name: Barry Leiba
Date Verified: 2012-05-17

Section 5.2.1 says:

   If the authentication used by the customer does not provide access to
   all of the domains specified in ATRN, the provider MUST NOT send mail
   for any domains to the customer; the provider MUST reject the ATRN
   command with a 450 code.

It should say:

   If the authentication used by the customer does not provide access to
   all of the domains specified in ATRN, the provider MUST NOT send mail
   for any domains to the customer; the provider MUST reject the ATRN
   command with a 550 code.

Notes:

This seems to be contrary to SMTP's theory of reply codes:

A rule of thumb to determine whether a reply fits into the 4yz or the 5yz category (see below) is that replies are 4yz if they can be successful if repeated
without any change in command form or in properties of the sender
or receiver (that is, the command is repeated identically and the
receiver does not put up a new implementation.)

If the ODMR client repeats the ATRN request in this situation, it will be rejected again. So a 550 response would be more appropriate.

RFC 2648, "A URN Namespace for IETF Documents", August 1999

Note: This RFC has been updated by RFC 6924, RFC 9141

Source of RFC: urn (app)

Errata ID: 3145
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michal Bozon
Date Reported: 2012-03-02
Verifier Name: Peter Saint-Andre
Date Verified: 2012-03-02

Section A.2 says:

      print "Status:  302 Moved temporarily0;

It should say:

      print "Status:  302 Moved temporarily";

Notes:

might be both editorial and technical error (typo, causing the Perl code invalid)

Errata ID: 3146
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michal Bozon
Date Reported: 2012-03-02
Verifier Name: Peter Saint-Andre
Date Verified: 2012-03-02

Section A.3 says:

    if ($accept =~ /text\/uri-list/) { #look for text/uri-list,
        otherwise text/html

It should say:

    if ($accept =~ /text\/uri-list/) {
        # look for text/uri-list, otherwise text/html

Notes:

Appears 4 times in the same section. Might be both editorial and technical error (forced line break in the middle of the comment, making the Perl code invalid)

RFC 2655, "CIP Index Object Format for SOIF Objects", August 1999

Source of RFC: find (app)

Errata ID: 403
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kang-Jin Lee
Date Reported: 2002-09-04

Section 8 says:

   [2]  The Harvest Information Discovery and Access System:
        <URL:http://harvest.transarc.com/>

It should say:

   [2]  Harvest: A distributed Search System:
        <URL:http://harvest.sourceforge.net/>

RFC 2656, "Registration Procedures for SOIF Template Types", August 1999

Source of RFC: find (app)

Errata ID: 402
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kang-Jin Lee
Date Reported: 2002-09-04

Section 5 says:

   [2]  The Harvest Information Discovery and Access System:
        <URL:http://harvest.transarc.com/>

It should say:

   [2]  Harvest: A distributed Search System:
        <URL:http://harvest.sourceforge.net/>

RFC 2661, "Layer Two Tunneling Protocol "L2TP"", August 1999

Source of RFC: pppext (int)

Errata ID: 401
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ming Deng
Date Reported: 2007-03-17

Section 3 says:

SSHTRESH

It should say:

SSTHRESH

Notes:

Occurs 3 times.

from pending

Errata ID: 5632
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christophe Deleuze
Date Reported: 2019-02-11
Verifier Name: RFC Editor
Date Verified: 2019-03-19

Section 6.1 says:

It is sent by either the LAC or the LNS to being the tunnel
establishment process.

It should say:

It is sent by either the LAC or the LNS to begin the tunnel
establishment process.

RFC 2662, "Definitions of Managed Objects for the ADSL Lines", August 1999

Source of RFC: adslmib (ops)

Errata ID: 5508
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Glenn Mansfield Keeni
Date Reported: 2018-09-29
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2019-07-01

Section 7 says:

             OBJECT      adslAtucConfMinSnrMgn
             MIN-ACCESS  read-wr
             MIN-ACCESS  read-write
             DESCRIPTION
                 "Read-write access is applicable when
                  static profiles are implemented."

It should say:

             OBJECT      adslAtucConfMinSnrMgn
             MIN-ACCESS  read-write
             DESCRIPTION
                 "Read-write access is applicable when
                  static profiles are implemented."

Notes:

The extra line
MIN-ACCESS read-wr
results in MIB compilation errors.

RFC 2663, "IP Network Address Translator (NAT) Terminology and Considerations", August 1999

Source of RFC: nat (tsv)

Errata ID: 400
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Javier Waisbrot
Date Reported: 2002-11-14

Section 2.6 says:

   the NAT device cannot safely assume that the segments containing
   FINs or SYNs will be the last packets of the session (i.e., there
   could be retransmissions).

It should say:

   the NAT device cannot safely assume that the segments containing
   FINs or RSTs will be the last packets of the session (i.e., there
   could be retransmissions).

RFC 2673, "Binary Labels in the Domain Name System", August 1999

Note: This RFC has been obsoleted by RFC 6891

Note: This RFC has been updated by RFC 3363, RFC 3364

Source of RFC: dnsind (int)

Errata ID: 1679
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Klensin
Date Reported: 2009-02-09
Verifier Name: Brian Haberman
Date Verified: 2012-05-01

Section headers says:

(none)

It should say:

Updates: 1035

Notes:

This document introduces a type of label not explicitly anticipated in the core DNS documents. Not having an "updating" entry that threads it back to 1035 (or 1034) makes this specification hard to find and likely to be omitted from any compendium or overview of DNS specifications.

The situation is obviously a little complicated by our usual difficulties in updating full standards from documents that are earlier on the standards track or not on the standards track at all. 2673 was published (in 1999) as a Proposed Standard, making an intention to update 1035 well within the rules. A suggestion then appears to in 3363 (published in 2002) to change it to Experimental, but, since 3363 is itself Informational, it clearly did make that change. I can find no record of an explicit IESG action making it, but such records are hard to find. For completeness (of the confusion), RFC 3364 is also listed as updating 2673, but not only is it also Informational, it doesn't even reference 2673 -- one has to deduce the relationship to 2673 by making an inference from the discussion of 2874.

Obviously, while the erratum, and probably one for 1034 with a forward pointer to 2673, should be recorded, the key problem can be fixed by updating the rfc-index and its various clones.

An alternative, which clearly requires IESG and DNSEXT involvement (the above suggestion may or may not do so) is to decide that, after nearly a decade of presumed experience with 2673, either it is useful for something (even if not IPv6 reverse mapping) or that ten years is enough and it isn't worth the trouble. If it is useful, it should be put it back on the standards track, presumably with an applicability statement about what it is useful for. If it is not, it is time to make it Historic. Either decision would clear up the questions of its status vis-a-vis introduction of new label types and updating 1035.

RFC 2676, "QoS Routing Mechanisms and OSPF Extensions", August 1999

Source of RFC: ospf (rtg)

Errata ID: 399
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jussi Savolainen
Date Reported: 2002-07-09

Section 3.2.1 says:

    0       8       16
    |       |       |
    -----------------
   |EXP| MANT        |
    -----------------

It should say:

    0       8       15
    |       |       |
    -----------------
   |EXP| MANT        |
    -----------------

RFC 2680, "A One-way Packet Loss Metric for IPPM", September 1999

Note: This RFC has been obsoleted by RFC 7680

Source of RFC: ippm (ops)

Errata ID: 1528
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Wenxia Dong
Date Reported: 2008-09-24
Verifier Name: Lars Eggert
Date Verified: 2009-05-14

Section 2.7 says:

The first two sources are interrelated and could result in a test
packet with finite delay being reported as lost.  Type-P-One-way-
Packet-Loss is 0 if the test packet does not arrive, or if it does
arrive and the difference between Src timestamp and Dst timestamp is
greater than the "reasonable period of time", or loss threshold.  

It should say:

The first two sources are interrelated and could result in a test
packet with finite delay being reported as lost.  Type-P-One-way-
Packet-Loss is 1 if the test packet does not arrive, or if it does
arrive and the difference between Src timestamp and Dst timestamp is
greater than the "reasonable period of time", or loss threshold.

Notes:

Type-P-One-way-Packet-Loss is 1 if the test packet does not arrive, according to section 2.4 Definition in RFC2680.

RFC 2683, "IMAP4 Implementation Recommendations", September 1999

Note: This RFC has been updated by RFC 7162

Source of RFC: Legacy

Errata ID: 3129
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Karl Fenech
Date Reported: 2012-02-19
Verifier Name: Pete Resnick
Date Verified: 2012-03-29

Section 3.2.1.3 says:

       C: 022 FETCH 3 BODY[1]<0.20000>
       S: * 3 FETCH (FLAGS(\Seen) BODY[1]<0> {20000}
       S: ...data...)
       S: 022 OK done
       C: 023 FETCH 3 BODY[1]<20001.20000>
       S: * 3 FETCH (BODY[1]<20001> {20000}
       S: ...data...)
       S: 023 OK done
       C: 024 FETCH 3 BODY[1]<40001.20000>
       ...etc...

It should say:

       C: 022 FETCH 3 BODY[1]<0.20000>
       S: * 3 FETCH (FLAGS (\Seen) BODY[1]<0> {20000}
       S: ...data...)
       S: 022 OK done
       C: 023 FETCH 3 BODY[1]<20000.20000>
       S: * 3 FETCH (BODY[1]<20000> {20000}
       S: ...data...)
       S: 023 OK done
       C: 024 FETCH 3 BODY[1]<40000.20000>
       ...etc...

Notes:

The main erratum is an off-by-one error. The starting index of an IMAP partial body fetch is zero-based. A request for BODY[1]<0.20000> would fetch octets 0 to 19999 (inclusive). A request for BODY[1]<20001.20000> would fetch octets 20001 to 40000 (inclusive). As a consequence, octet 2000 is skipped in the original suggested implementation, with the strong possibility of leading to data corruption if the message body is reconstructed by concatenating the retrieved substrings.

There is a secondary erratum: There should be a mandatory space between the "FLAGS" string and the parenthesized list of flags. Refer to the definition for msg-att-dynamic in the Formal Syntax of RFC 3501.

RFC 2694, "DNS extensions to Network Address Translators (DNS_ALG)", September 1999

Source of RFC: nat (tsv)

Errata ID: 5755
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lee Chan Gyu
Date Reported: 2019-06-18
Verifier Name: RFC Editor
Date Verified: 2019-06-19

Section 4.1.1 says:

DNS_ALG would simply simply respond back

It should say:

DNS_ALG would simply respond back

Notes:

Dups

RFC 2696, "LDAP Control Extension for Simple Paged Results Manipulation", September 1999

Source of RFC: ldapext (app)

Errata ID: 7292
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yogender Bhabhoria
Date Reported: 2022-12-28
Verifier Name: RFC Editor
Date Verified: 2023-01-06

Section 4. Example says:

C: SearchRequest + pagedResultsControl(3,"")
   -- Server responds with three entries plus an indication
   -- of 5 total entries in the search result and an opaque
   -- cooking to be used by the client when retrieving subsequent
   -- pages.
   S: SearchResultEntry
   S: SearchResultEntry
   S: SearchResultEntry
   S: SearchResultDone + pagedResultsControl(5, "opaque")
   -- Client sends an identical search request (except for
   -- message id), returning the opaque cooking, asking for
   -- the next page.

It should say:

C: SearchRequest + pagedResultsControl(3,"")
   -- Server responds with three entries plus an indication
   -- of 5 total entries in the search result and an opaque
   -- cookie to be used by the client when retrieving subsequent
   -- pages.
   S: SearchResultEntry
   S: SearchResultEntry
   S: SearchResultEntry
   S: SearchResultDone + pagedResultsControl(5, "opaque")
   -- Client sends an identical search request (except for
   -- message id), returning the opaque cookie, asking for
   -- the next page.

Notes:

It's a cookie that's received/sent. Instead of cookie, the RFC says cooking in two places.

RFC 2698, "A Two Rate Three Color Marker", September 1999

Source of RFC: Legacy

Errata ID: 7867
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mohamed Boucadair
Date Reported: 2024-03-24
Verifier Name: RFC Editor
Date Verified: 2024-03-25

Section 2 says:

   The PBS and the CBS and are measured in bytes and both of them must
   be configured to be greater than 0.  

It should say:

   The PBS and the CBS are measured in bytes and both of them must
   be configured to be greater than 0.  

Notes:

extra "and"

RFC 2731, "Encoding Dublin Core Metadata in HTML", December 1999

Note: This RFC has been obsoleted by RFC 5791

Source of RFC: Legacy
Area Assignment: app

Errata ID: 396
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kang-Jin Lee
Date Reported: 2002-09-04

Section 11 says:

   [HARVEST]        Harvest Web Indexing.
                    http://www.tardis.ed.ac.uk/harvest/

It should say:

   [HARVEST]        Harvest: A distributed Search System.
                    http://harvest.sourceforge.net/

Errata ID: 1779
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2009-05-09
Verifier Name: Peter Saint-Andre
Date Verified: 2010-11-11

Section - says:

Notes:

It appears that this document has been obsoleted by "Expressing Dublin Core metadata using HTML/XHTML meta and link elements" (<http://dublincore.org/documents/dc-html/>).

RFC 2732, "Format for Literal IPv6 Addresses in URL's", December 1999

Note: This RFC has been obsoleted by RFC 3986

Source of RFC: ipngwg (int)

Errata ID: 1422
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Suhler
Date Reported: 2008-05-13
Verifier Name: Lisa Dusseault
Date Verified: 2008-05-14

Section Page 2 says:

A literal address is incorrectly rendered as a URL:

Literal:
      1080:0:0:0:8:800:200C:4171

As rendered as a URL:
      http://[1080:0:0:0:8:800:200C:417A]/index.html

It should say:

Should be:
      http://[1080:0:0:0:8:800:200C:4171]/index.html

Notes:

Larry Masinter & I verified this errata

RFC 2737, "Entity MIB (Version 2)", December 1999

Note: This RFC has been obsoleted by RFC 4133

Source of RFC: entmib (ops)

Errata ID: 395
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: RFC Editor
Date Reported: 2001-09-21

In the header:

   Network Working Group                                      K. McCloghrie
   Request for Comments: 2737                           Cisco Systems, Inc.
   Obsoletes: 2037                                               A. Bierman
                                                        Cisco Systems, Inc.
                                                              December 1999

It should say:

   Network Working Group                                      K. McCloghrie
   Request for Comments: 2737                           Cisco Systems, Inc.
   Obsoletes: 2037                                               A. Bierman
   Category: Standards Track                            Cisco Systems, Inc.
                                                              December 1999

RFC 2739, "Calendar Attributes for vCard and LDAP", January 2000

Note: This RFC has been updated by RFC 6350

Source of RFC: calsch (app)

Errata ID: 6624
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Prakhar Makhija
Date Reported: 2021-06-30
Verifier Name: RFC Editor

Section 2.3.3 says:

2.3.3  CAPURI Property IANA Registration

   To: ietf-mime-directory@imc.org

   Subject: Registration of CAPURI type for application/directory MIME
   type vCard profile.

   Type name: CAPURI

   Type purpose: To specify a protocol independent location from which a
   calendaring and scheduling client (i.e., CUA) can communicate with a
   user's entire calendar.

   Type encoding: 8bit

   Type value: A single URI value.

   Type special notes: Where multiple CAPURI properties are specified,
   the default CAPURI property is indicated with the PREF parameter.

   Intended usage: Refer to section 1.3.

It should say:

2.3.3  CAPURI Property IANA Registration

   To: ietf-mime-directory@imc.org

   Subject: Registration of CAPURI type for application/directory MIME
   type vCard profile.

   Type name: CAPURI

   Type purpose: To specify a protocol independent location from which a
   calendaring and scheduling client (i.e., CUA) can communicate with a
   user's entire calendar.

   Type encoding: 8bit

   Type value: A single URI value.

   Type special notes: Where multiple CAPURI properties are specified,
   the default CAPURI property is indicated with the PREF parameter.

   Intended usage: Refer to section 1.2.

Notes:

Usage Reference Section was incorrect

Errata ID: 6625
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Prakhar Makhija
Date Reported: 2021-06-30
Verifier Name: RFC Editor

Section 2.3.4 says:

2.3.4 CALURI Property IANA Registration

   To: ietf-mime-directory@imc.org

   Subject: Registration of CALURI type for text/directory MIME type
   vCard profile.

   Type name: CALURI

   Type purpose: To specify the URI for a user's calendar in a vCard
   object.

   Type encoding: 8bit

   Type value type: A single URI value.

   Type special notes: Where multiple CALURI properties are specified,
   the default CALURI property is indicated with the PREF parameter. The
   property should contain a URI pointing to an iCalendar object
   associated with a snapshot of the user's calendar store. If the
   iCalendar object is represented as a file or document, it's file type
   should be "ics".

   Intended usage: Refer to section 1.4.

   Type examples:

      CALURI;PREF:http://cal.host1.com/calA
      CALURI:ftp://ftp.host1.com/calA.ics

It should say:

2.3.4 CALURI Property IANA Registration

   To: ietf-mime-directory@imc.org

   Subject: Registration of CALURI type for text/directory MIME type
   vCard profile.

   Type name: CALURI

   Type purpose: To specify the URI for a user's calendar in a vCard
   object.

   Type encoding: 8bit

   Type value type: A single URI value.

   Type special notes: Where multiple CALURI properties are specified,
   the default CALURI property is indicated with the PREF parameter. The
   property should contain a URI pointing to an iCalendar object
   associated with a snapshot of the user's calendar store. If the
   iCalendar object is represented as a file or document, it's file type
   should be "ics".

   Intended usage: Refer to section 1.3.

   Type examples:

      CALURI;PREF:http://cal.host1.com/calA
      CALURI:ftp://ftp.host1.com/calA.ics

Notes:

Usage Reference Section was incorrect

Errata ID: 6626
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Prakhar Makhija
Date Reported: 2021-06-30
Verifier Name: RFC Editor

Section 2.3.2 says:

2.3.2  CALADRURI Property IANA Registration

   To: ietf-mime-directory@imc.org

   Subject: Registration of CALADRURI type for application/directory
   MIME type vCard profile.

   Type name: CALADRURI

   Type purpose: To specify the location to which an event request
   should be sent for the user.

   Type encoding: 8bit

   Type value: A single URI value.

   Type special notes: Where multiple CALADRURI properties are
   specified, the default CALADRURI property is indicated with the PREF
   parameter.

   Intended usage: Refer to section 1.2.

   Type examples:

      CALADRURI;PREF:mailto:janedoe@host.com

It should say:

2.3.2  CALADRURI Property IANA Registration

   To: ietf-mime-directory@imc.org

   Subject: Registration of CALADRURI type for application/directory
   MIME type vCard profile.

   Type name: CALADRURI

   Type purpose: To specify the location to which an event request
   should be sent for the user.

   Type encoding: 8bit

   Type value: A single URI value.

   Type special notes: Where multiple CALADRURI properties are
   specified, the default CALADRURI property is indicated with the PREF
   parameter.

   Type examples:

      CALADRURI;PREF:mailto:janedoe@host.com

Notes:

Usage Reference Section was wrong

Section 1 (Calendaring and Scheduling URIs) does not define CALADRURI

Usage type example is already mentioned in Section 2.3.2

RFC 2740, "OSPF for IPv6", December 1999

Note: This RFC has been obsoleted by RFC 5340

Source of RFC: ospf (rtg)

Errata ID: 392
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Moy
Date Reported: 2002-01-17

Section A.3.2 says:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      3               |       1       |  Packet length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Router ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Area ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Checksum            |  Instance ID  |      0         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Interface ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Rtr Pri    |             Options                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        HelloInterval         |        RouterDeadInterval      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Designated Router ID                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Backup Designated Router ID                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Neighbor ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    ...                              |

It should say:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      3        |       1       |         Packet length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Router ID                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Area ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Checksum            |  Instance ID  |      0        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Interface ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Rtr Pri    |              Options                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         HelloInterval         |        RouterDeadInterval     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Designated Router ID                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Backup Designated Router ID                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Neighbor ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |

Errata ID: 394
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Wu Qian
Date Reported: 2001-08-21

Section 3.1.2 says:

The Interface ID appears in Hello packets sent out the interface,
the link-local-LSA originated by router for the attached link, and
the router-LSA originated by the router-LSA for the associated area.

It should say:

The Interface ID appears in Hello packets sent out the interface,
the link-local-LSA originated by router for the attached link, and
the router-LSA originated by the router for the associated area.

Errata ID: 609
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Moy
Date Reported: 2002-01-17

In Section A.2 The Options field:

                         1                     2
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8  9  0  1  2  3
    -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+
     | | | | | | | | | | | | | | | | | |DC| R| N|MC| E|V6|
    -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+

It should say:

                            1                     2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8  9  0  1  2  3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+
   | | | | | | | | | | | | | | | | | | |DC| R| N|MC| E|V6|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+

Errata ID: 659
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Moy
Date Reported: 2002-01-17

Section A.3.3 says:

    0                  1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      3        |       2       |        Packet length          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Router ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Area ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Checksum            |  Instance ID  |      0        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       0       |                 Options                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Interface MTU         |       0        |0|0|0|0|0|I|M|MS
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    DD sequence number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-                     An LSA Header                           -+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    ...                              |

It should say:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      3        |       2       |         Packet length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Router ID                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Area ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Checksum            |  Instance ID  |      0        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       0       |                 Options                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Interface MTU         |       0       |0|0|0|0|0|I|M|MS
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     DD sequence number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-                      An LSA Header                          -+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |

Errata ID: 660
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Moy
Date Reported: 2002-01-17

Section A.3.4 says:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      3           |       3       |     Packet length          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Router ID                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Area ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Checksum               |  Instance ID  |      0      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              0                  |        LS type              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Link State ID                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Advertising Router                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       ...                     |

It should say:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      3        |       3       |         Packet length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Router ID                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Area ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Checksum            |  Instance ID  |      0        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               0               |           LS type             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Link State ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Advertising Router                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |

Errata ID: 661
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Moy
Date Reported: 2002-01-17

Section A.3.5 says:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      3        |       4       |         Packet length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Router ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Area ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Checksum            |  Instance ID  |      0         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           # LSAs                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-                                                            +-+
   |                            LSAs                               |
   +-                                                            +-+
   |                    ...                              |

It should say:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      3        |       4       |         Packet length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Router ID                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Area ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Checksum            |  Instance ID  |      0        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            # LSAs                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-                                                            +-+
   |                             LSAs                              |
   +-                                                            +-+
   |                             ...                               |

Errata ID: 662
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Moy
Date Reported: 2002-01-17

Section A.3.6 says:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      3              |       5       |  Packet length          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Router ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Area ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Checksum            |  Instance ID  |      0         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-                        An LSA Header                        -+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    ...                              |

It should say:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      3        |       5       |         Packet length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Router ID                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Area ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Checksum            |  Instance ID  |      0        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-                         An LSA Header                       -+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |

Errata ID: 663
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Moy
Date Reported: 2002-01-17

Section A.4.2 says:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           LS age             |           LS type              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Link State ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Advertising Router                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    LS sequence number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        LS checksum           |             length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            LS age             |           LS type             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Link State ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Advertising Router                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     LS sequence number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         LS checksum           |             length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Errata ID: 664
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Moy
Date Reported: 2002-01-17

Section A.4.3 says:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           LS age             |0|0|1|          1               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Link State ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Advertising Router                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    LS sequence number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        LS checksum           |             length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    0  |W|V|E|B|            Options                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |       0       |          Metric               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Interface ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Neighbor Interface ID                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Neighbor Router ID                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |       0       |          Metric               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Interface ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Neighbor Interface ID                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Neighbor Router ID                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ...                               |

It should say:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            LS age             |0|0|1|          1              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Link State ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Advertising Router                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     LS sequence number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         LS checksum           |             length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    0  |W|V|E|B|             Options                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |       0       |           Metric              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Interface ID                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Neighbor Interface ID                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Neighbor Router ID                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |       0       |           Metric              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Interface ID                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Neighbor Interface ID                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Neighbor Router ID                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |

Errata ID: 665
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Moy
Date Reported: 2002-01-17

Section A.4.4 says:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           LS age             |0|0|1|          2               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Link State ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Advertising Router                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    LS sequence number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        LS checksum           |             length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0               |              Options                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Attached Router                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ...                               |

It should say:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            LS age             |0|0|1|          2              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Link State ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Advertising Router                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     LS sequence number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         LS checksum           |             length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0        |              Options                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Attached Router                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |

Errata ID: 667
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Moy
Date Reported: 2002-01-17

Section A.4.5 says:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           LS age             |0|0|1|          3               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Link State ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Advertising Router                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    LS sequence number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        LS checksum           |             length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0               |                  Metric                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | PrefixLength  | PrefixOptions |             (0)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Address Prefix                         |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

It should say:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            LS age             |0|0|1|          3              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Link State ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Advertising Router                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     LS sequence number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         LS checksum           |             length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0        |                  Metric                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | PrefixLength  | PrefixOptions |              (0)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Address Prefix                        |
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Errata ID: 668
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Moy
Date Reported: 2002-01-17

Section A.4.6 says:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           LS age             |0|0|1|        4                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Link State ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Advertising Router                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    LS sequence number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        LS checksum           |             length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0               |          Options                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0               |          Metric                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Destination Router ID                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            LS age             |0|0|1|        4                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Link State ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Advertising Router                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     LS sequence number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         LS checksum           |             length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0        |                  Options                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0        |                  Metric                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Destination Router ID                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Errata ID: 669
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Moy
Date Reported: 2002-01-17

Section A.4.7 says:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           LS age             |0|1|0|          5               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Link State ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Advertising Router                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    LS sequence number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        LS checksum           |             length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        |E|F|T|                 Metric                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | PrefixLength  | PrefixOptions |     Referenced LS Type        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Address Prefix                         |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-                Forwarding Address (Optional)                -+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           External Route Tag (Optional)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Referenced Link State ID (Optional)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            LS age             |0|1|0|          5              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Link State ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Advertising Router                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     LS sequence number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         LS checksum           |             length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         |E|F|T|                 Metric                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | PrefixLength  | PrefixOptions |     Referenced LS Type        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Address Prefix                        |
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-                                                             -+ 
   |                                                               |
   +-                 Forwarding Address (Optional)               -+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  External Route Tag (Optional)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Referenced Link State ID (Optional)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Errata ID: 671
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Moy
Date Reported: 2002-01-17

Section A.4.8 says:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           LS age             |0|0|0|           8              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Link State ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Advertising Router                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     LS sequence number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        LS checksum           |             length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Rtr Pri    |                Options                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-                Link-local Interface Address                 -+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         # prefixes                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  PrefixLength | PrefixOptions |             (0)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Address Prefix                         |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  PrefixLength | PrefixOptions |             (0)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Address Prefix                         |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            LS age             |0|0|0|           8             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Link State ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Advertising Router                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      LS sequence number                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         LS checksum           |             length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Rtr Pri    |                 Options                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-                 Link-local Interface Address                -+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          # prefixes                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  PrefixLength | PrefixOptions |              (0)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Address Prefix                        |
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  PrefixLength | PrefixOptions |              (0)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Address Prefix                        |
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Errata ID: 672
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Moy
Date Reported: 2002-01-17

Section A.4.9 says:

    0                  1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           LS age             |0|0|1|            9             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Link State ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Advertising Router                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    LS sequence number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        LS checksum           |             length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         # prefixes           |     Referenced LS type         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Referenced Link State ID                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Referenced Advertising Router                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  PrefixLength | PrefixOptions |          Metric               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Address Prefix                          |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  PrefixLength | PrefixOptions |          Metric               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Address Prefix                          |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            LS age             |0|0|1|            9            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Link State ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Advertising Router                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     LS sequence number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         LS checksum           |             length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          # prefixes           |     Referenced LS type        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Referenced Link State ID                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Referenced Advertising Router                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  PrefixLength | PrefixOptions |           Metric              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Address Prefix                         |
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  PrefixLength | PrefixOptions |           Metric              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Address Prefix                         |
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

RFC 2743, "Generic Security Service Application Program Interface Version 2, Update 1", January 2000

Note: This RFC has been updated by RFC 5554, RFC 5896

Source of RFC: cat (sec)

Errata ID: 4151
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nicolas Williams
Date Reported: 2014-11-03
Verifier Name: Stephen Farrell
Date Verified: 2015-05-01

Section 2.2.4 says:

   o  GSS_S_FAILURE indicates that the context is recognized, but that
   the GSS_Process_context_token() operation could not be performed for
   reasons unspecified at the GSS-API level.

It should say:

   o  GSS_S_FAILURE indicates that the context is recognized, but
   either the GSS_Process_context_token() operation could not be
   performed for reasons unspecified at the GSS-API level, or the peer
   had an error consuming the last context token sent to it.  The latter
   occurs when the local side became fully established and produced one
   last token which was sent to the peer, but the peer encountered an
   error while processing that last context token.  In either case the
   minor status code provides additional information.

   In the case of successful processing of error tokens, the minor
   status code provides information from the input token.  The display
   string outputs of GSS_Display_status() as applied to such minor
   status codes should indicate that the error originated on the remote
   peer, along with the nature of the error.  Note that there is no
   way to distinguish failures of GSS_Process_context_token() from
   error token information other than to read the human-readable status
   display strings.

Notes:

The other major status codes that GSS_Process_context_token() can return are: GSS_S_COMPLETE (input token successfully processed), GSS_S_DEFECTIVE_TOKEN (e.g., integrity protection for the input token failed), GSS_S_NO_CONTEXT (invalid input security context).

This leaves a) no way to report error token information, b) no purpose for GSS_S_FAILURE, since the other major status codes cover all plausible error conditions.

But clearly the intention was that "asynchronous error tokens" should be passed to GSS_Process_context_token(), and for such tokens to be useful as far as conveying information about the error goes.

There are at least two easy ways to fix this: either have GSS_Process_context_token() report the error information in the minor status with a major status of GSS_S_COMPLETE, or decide that the GSS_S_FAILURE description was incorrect, that it should have been used to convey error token information. The latter is the more natural fix.

The KITTEN WG will have to review this erratum and decide whether to reject it, accept one fix, or the other. That review happened resulting in the corrected
text above.

RFC 2744, "Generic Security Service API Version 2 : C-bindings", January 2000

Note: This RFC has been updated by RFC 5896

Source of RFC: cat (sec)

Errata ID: 3810
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Benjamin Kaduk
Date Reported: 2013-11-22
Verifier Name: Stephen Farrell
Date Verified: 2014-05-08

Section Appendix A says:

 ,

It should say:

 *,

Notes:

The author of draft-ietf-cat-gssv2-cbind (which became RFC2744) switched to a different formatting process between versions 05 and 06 of that draft. This inadvertently introduced errors into the function prototypes in the example gssapi.h header, removing the asterisk which indicates that an argument is of pointer type from pointer arguments which are not the last argument in the argument list of their respective function. All sixty-eight occurrences of <space><comma> in Appendix A should be replaced by the sequence <space><asterisk><comma> as a fix. Additionally, the minor_status argument of gss_export_name() is not caught by this pattern, but also should be changed from scalar to pointer type in order for all function prototypes in the header to be corrected ("OM_uint32," becomes "OM_uint32 *,"). As another concrete example, at the top of page 91, the first argument to gss_acquire_cred should change from "OM_uint32 , /* minor_status */" to "OM_uint32 *, /* minor_status */".

RFC 2747, "RSVP Cryptographic Authentication", January 2000

Note: This RFC has been updated by RFC 3097

Source of RFC: vgmib (int)

Errata ID: 4313
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2015-03-25
Verifier Name: Martin Stiemerling
Date Verified: 2015-04-21

Section 3.2 says:

   In this approach, we could use an NTP based timestamp value as the
   sequence number.  The roll-over period of an NTP timestamp is about
   136 years, much longer than any reasonable lifetime of a key.  In
   addition, the granularity of the NTP timestamp is fine enough to
   allow the generation of an RSVP message every 200 picoseconds for a
   given key.  Many real time clock modules do not have the resolution
   of an NTP timestamp.  In these cases, the least significant bits of
   the timestamp can be generated using a message counter, which is
   reset every clock tick.  For example, when the real time clock
   provides a resolution of 1 second, the 32 least significant bits of
   the sequence number can be generated using a message counter.  The
   remaining 32 bits are filled with the 32 least significant bits of
   the timestamp.  Assuming that the recovery time after failure takes
   longer than one tick of the real time clock, the message counter for
   the low order bits can be safely reset to zero after a restart.

It should say:

   In this approach, we could use an NTP based timestamp value as the
   sequence number.  The roll-over period of an NTP timestamp is about
   136 years, much longer than any reasonable lifetime of a key.  In
   addition, the granularity of the NTP timestamp is fine enough to
   allow the generation of an RSVP message every 200 picoseconds for a
   given key.  Many real time clock modules do not have the resolution
   of an NTP timestamp.  In these cases, the least significant bits of
   the sequence number can be generated using a message counter, which
   is reset every clock tick.  For example, when the real time clock
   provides a resolution of 1 second, the 32 least significant bits of
   the sequence number can be generated using a message counter.  The
   remaining 32 bits are filled with the 32 most significant bits of
   the timestamp.  Assuming that the recovery time after failure takes
   longer than one tick of the real time clock, the message counter for
   the low order bits can be safely reset to zero after a restart.

Notes:

32 least significant bits of the timestamp will in this case be set to zero.

RFC 2759, "Microsoft PPP CHAP Extensions, Version 2", January 2000

Source of RFC: pppext (int)

Errata ID: 391
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Andrew Roughan
Date Reported: 2002-08-26

Section 9.3 says:

  0-to-256-unicode-char Password:
  4D 79 50 77

  16-octet PasswordHash:
  FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC

It should say:

  0-to-256-char Password:
  4D 79 50 77

  0-to-256-unicode-char NtPassword:
  4D 00 79 00 50 00 77 00

  16-octet NtPasswordHash:
  FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC

Errata ID: 1924
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexey Melnikov
Date Reported: 2009-10-22
Verifier Name: Brian Haberman
Date Verified: 2012-05-09

Section 8.3 says:

   NtPasswordHash(
   IN  0-to-256-unicode-char Password,
   OUT 16-octet              PasswordHash )
   {
      /*
       * Use the MD4 algorithm [5] to irreversibly hash Password
       * into PasswordHash.  Only the password is hashed without
       * including any terminating 0.
       */
   }

It should say:

   NtPasswordHash(
   IN  0-to-256-unicode-char Password,
   OUT 16-octet              PasswordHash )
   {
      /*
       * Use the MD4 algorithm [5] to irreversibly hash Password
       * encoded in UTF-16-LE into PasswordHash.
       * Only the password is hashed without
       * including any terminating 0.
       */
   }

Notes:

Section 8.3 is silent on Unicode encoding used for passwords.
Section 9.2 seem to imply that the Unicode encoding used in UTF-16-LE.

RFC 2763, "Dynamic Hostname Exchange Mechanism for IS-IS", February 2000

Note: This RFC has been obsoleted by RFC 5301

Source of RFC: isis (rtg)

Errata ID: 390
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Brian Vine
Date Reported: 2002-06-28

Section 4 says:

   A router may also optionally insert this TLV in it's pseudo node LSP
   for the association of a symbolic name to a local LAN.

It should say:

   A router may also optionally insert this TLV in its pseudo node LSP
   for the association of a symbolic name to a local LAN.

RFC 2764, "A Framework for IP Based Virtual Private Networks", February 2000

Source of RFC: Legacy

Errata ID: 389
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Elena Taguer
Date Reported: 2001-02-01

There is a case of sections being numbered wrong:

   5.3.3.1 Stub Link Connectivity Scenarios ........................ 30
   5.3.3.1 Routing Protocol Instance ............................... 31

RFC 2782, "A DNS RR for specifying the location of services (DNS SRV)", February 2000

Note: This RFC has been updated by RFC 6335, RFC 8553

Source of RFC: dnsext (int)

Errata ID: 6600
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Oleksandr Chychkan
Date Reported: 2021-06-06
Verifier Name: Erik Kline
Date Verified: 2021-06-06

Section Fictional ex says:

      ; using the sysdmin's box and the server

It should say:

      ; using the sysadmin's box and the server

Notes:

A typo in the "sysdmin's"

RFC 2784, "Generic Routing Encapsulation (GRE)", March 2000

Note: This RFC has been updated by RFC 2890

Source of RFC: Legacy
Area Assignment: rtg

Errata ID: 3719
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: C, . M. Heard
Date Reported: 2013-09-04
Verifier Name: Stewart Bryant
Date Verified: 2013-09-17

Section 2.3 and 5.2 says:

2.3. Reserved0 (bits 1-12)

   A receiver MUST discard a packet where any of bits 1-5 are non-zero,
   unless that receiver implements RFC 1701. Bits 6-12 are reserved for
   future use. These bits MUST be sent as zero and MUST be ignored on
   receipt.
...
5.2. RFC 1701 Compliant Transmitter

   An RFC 1701 transmitter may set any of the Routing Present, Key
   Present, Sequence Number Present, and Strict Source Route bits set to
   one, and thus may transmit the RFC 1701 Key, Sequence Number or
   Routing fields in the GRE header. As stated in Section 5.3, a packet
   with non-zero bits in any of bits 1-5 MUST be discarded unless the
   receiver implements RFC 1701.

It should say:

2.3. Reserved0 (bits 1-12)

   A receiver MUST discard a packet where any of bits 1-4 are non-zero,
   unless that receiver implements RFC 1701. Bits 5-12 are reserved for
   future use. These bits MUST be sent as zero and MUST be ignored on
   receipt.
...
5.2. RFC 1701 Compliant Transmitter

   An RFC 1701 transmitter may set any of the Routing Present, Key
   Present, Sequence Number Present, and Strict Source Route bits set to
   one, and thus may transmit the RFC 1701 Key, Sequence Number or
   Routing fields in the GRE header. As stated in Section 2.3, a packet
   with non-zero bits in any of bits 1-4 MUST be discarded unless the
   receiver implements RFC 1701.

Notes:

In the section entitled "Packet header," RFC 1701 defined the one-bit Routing Present, Key Present, Sequence Number Present, and Strict Source Route fields in bits 1-4 , the Recursion Control field in bits 5-7, and a Flags field in bits 8-12. It further stated that "[b]its 5 through 12 are reserved for future use and MUST be transmitted as zero." The language in RFC 2784 Section 5.2 makes it clear that incompatibilities between an RFC 1701 transmitter and an RFC 2784 receiver arise only when one or more of the the Routing Present, Key Present, Sequence Number Present, and Strict Source Route bits are set, i.e., when any of bits 1-4 are set.

Verifier's note: This looks like it was the intent of the authors, but the reader should note also RFC2890 which restores the K and S bits.

Errata ID: 1706
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2009-03-03
Verifier Name: Stewart Bryant
Date Verified: 2010-10-22

Section 5.2 says:

   An RFC 1701 transmitter may set any of the Routing Present, Key
   Present, Sequence Number Present, and Strict Source Route bits set to
   one, and thus may transmit the RFC 1701 Key, Sequence Number or
   Routing fields in the GRE header. As stated in Section 5.3, a packet
   with non-zero bits in any of bits 1-5 MUST be discarded unless the
   receiver implements RFC 1701.

It should say:

   An RFC 1701 transmitter may set any of the Routing Present, Key
   Present, Sequence Number Present, and Strict Source Route bits set to
   one, and thus may transmit the RFC 1701 Key, Sequence Number or
   Routing fields in the GRE header. As stated in Section 2.3, a packet
   with non-zero bits in any of bits 1-5 MUST be discarded unless the
   receiver implements RFC 1701.

RFC 2786, "Diffie-Helman USM Key Management Information Base and Textual Convention", March 2000

Source of RFC: Legacy

Errata ID: 388
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: David Harrington
Date Reported: 2001-08-17

The title was mis-spelled:

   Diffie-Helman USM Key Management Information Base and Textual
   Convention 

It should say:

   Diffie-Hellman USM Key Management Information Base and Textual
   Convention

RFC 2797, "Certificate Management Messages over CMS", April 2000

Note: This RFC has been obsoleted by RFC 5272

Source of RFC: pkix (sec)

Errata ID: 4037
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2014-07-03
Verifier Name: Stephen Farrell
Date Verified: 2014-07-03

Section Appendix A says:

EnrollmentMessageSyntax
   { iso(1) identified-organization(3) dod(4) internet(1)
   security(5) mechansims(5) pkix(7) id-mod(0) id-mod-cmc(6) }

It should say:

EnrollmentMessageSyntax
   { iso(1) identified-organization(3) dod(6) internet(1)
   security(5) mechansims(5) pkix(7) id-mod(0) id-mod-cmc(6) }

Notes:

The PKIX Object Identifier arc is:

id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }

So, the third element in the object identifier should be "dod(6)" instead of "dod(4)".

Errata ID: 4038
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2014-07-03
Verifier Name: Stephen Farrell
Date Verified: 2014-07-03

Section Appendix A says:

   id-cmc-confirmCertAcceptance OBJECT IDENTIFIER ::= {pkix-cmc 24}

It should say:

   id-cmc-confirmCertAcceptance OBJECT IDENTIFIER ::= {id-cmc 24}

Notes:

This is a typo in the ASN.1 module. The proper definition for this object identifier is {id-cmc 24}.

RFC 2810, "Internet Relay Chat: Architecture", April 2000

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 387
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Christophe Kalt
Date Reported: 2004-02-25

Section 5.2.1 says:

   In IRC the channel has a role equivalent to that of the multicast
   group; their existence is dynamic and the actual conversation carried
   out on a channel MUST only be sent to servers which are supporting
   users on a given channel.  Moreover, the message SHALL only be sent
   once to every local link as each server is responsible to fan the
   original message to ensure that it will reach all the recipients.

   The following examples all refer to Figure 2.

It should say:

   In IRC the channel has a role equivalent to that of the multicast
   group; their existence is dynamic and the actual conversation carried
   out on a channel MUST only be sent to servers which are supporting
   users on a given channel.  Moreover, the message SHALL only be sent
   once to every local link as each server is responsible to fan the
   original message to ensure that it will reach all the recipients.

   The following examples all refer to Figure 1.

Notes:

There is no "Figure 2".

RFC 2812, "Internet Relay Chat: Client Protocol", April 2000

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 384
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jeroen Peschier
Date Reported: 2002-12-16

Section 2.3 says:

   The presence of a prefix is indicated with a single leading ASCII
   colon character (':', 0x3b), which MUST be the first character of
   the message itself. 

It should say:

   The presence of a prefix is indicated with a single leading ASCII
   colon character (':', 0x3a), which MUST be the first character of
   the message itself.

Errata ID: 385
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alejandro Grijalba
Date Reported: 2004-06-10

Section 2.3.1 says:

  chanstring =  %x01-07 / %x08-09 / %x0B-0C / %x0E-1F / %x21-2B

It should say:

  chanstring =  %x01-06 / %x08-09 / %x0B-0C / %x0E-1F / %x21-2B

Errata ID: 386
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Konstantin Zemlyak
Date Reported: 2003-01-18

Section 5.3 says:

   244    RPL_STATSHLINE      244  RPL_STATSSLINE

It should say:

   244    RPL_STATSHLINE      245  RPL_STATSSLINE

Errata ID: 2821
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ricardo Garcia
Date Reported: 2011-06-05
Verifier Name: Peter Saint-Andre
Date Verified: 2011-06-10

Section 5.1 says:

       341    RPL_INVITING
              "<channel> <nick>"

It should say:

       341    RPL_INVITING
              "<nick> <channel>"

Notes:

Numeric reply 341 is used by the server to report a sucessful invitation attempt to the original client sending the invitation. The RFC mentions the reply arguments are the channel and the nickname, but every client and server I have tested expect the nickname first, followed by the channel name.

Errata ID: 2822
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ricardo Garcia
Date Reported: 2011-06-05
Verifier Name: Peter Saint-Andre
Date Verified: 2011-06-10

Section 5.1 says:

The original text is missing.

It should say:

       416    ERR_TOOMANYMATCHES
              "<channel> :Output too long (try locally)"

         - Returned by a server in response to a LIST or NAMES 
           message to indicate the result contains too many
           items to be returned to the client.

Errata ID: 2991
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Matthew Campbell
Date Reported: 2011-10-11
Verifier Name: Peter Saint-Andre
Date Verified: 2011-10-17

Section 3.2.3 says:

The original text is missing.

It should say:

ERR_NOSUCHCHANNEL

Notes:

Numeric reply list for Channel Modes should include ERR_NOSUCHCHANNEL.

Errata ID: 3001
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Matthew Campbell
Date Reported: 2011-10-21
Verifier Name: Peter Saint-Andre
Date Verified: 2011-11-12

Section 3.2.4 says:

The original text is missing.

It should say:

ERR_NOSUCHCHANNEL

Notes:

Numeric reply list for Topic should include ERR_NOSUCHCHANNEL.

Errata ID: 3783
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Diman Todorov
Date Reported: 2013-11-05
Verifier Name: Barry Leiba
Date Verified: 2013-11-05

Section 2.3.1 says:

chanstring = %x01-07 / %x08-09 / %x0B-0C / %x0E-1F / %x21-2B
chanstring =/ %x2D-39 / %x3B-FF

It should say:

chanstring = *49(%x01-06 / %x08-09 / %x0B-0C / %x0E-1F / %x21-2B /
             %x2D-39 / %x3B-FF)

Notes:

Unfortunately the text in 1.3 which elaborates the interpretation of this BNF rule is unclear as to whether it's permitted to have 0 chanstring characters. The total length of the "channel" construct is 50 characters, so no chanstring can ever be more than 49 characters... but not all 49 characters will always be available, depending upon how "channel" is constructed.

Note that errata 385 addresses the same rule but a different issue. Errata 385 has been taken into consideration in this correction.

Errata ID: 4836
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Brenden Case
Date Reported: 2016-10-19
Verifier Name: Barry Leiba
Date Verified: 2019-04-30

Section 2.3.1 says:

  key        =  1*23( %x01-05 / %x07-08 / %x0C / %x0E-1F / %x21-7F )
                  ; any 7-bit US_ASCII character,
                  ; except NUL, CR, LF, FF, h/v TABs, and " "

It should say:

  key        =  1*23( %x01-05 / %x07-08 / %x0C / %x0E-1F / %x21-7F )
                  ; any 7-bit US_ASCII character,
                  ; except NUL, CR, LF, ACK, h/v TABs, and " "

OR

  key        =  1*23( %x01-08 / %x0E-1F / %x21-7F )
                  ; any 7-bit US_ASCII character,
                  ; except NUL, CR, LF, FF, h/v TABs, and " "

Notes:

The hex for ACK and FF are x06 and x0C, respectively. The expression of the original text excludes ACK and includes FF. Therefore there is an error in either the expression or the comments following.
If the error is in the comments, then the first corrected text should be selected.
If the error is in the expression, then the second corrected text should be selected.

----- Verifier Notes -----
This is quite correct, though I have no idea which correction is right. In practice, I imagine it makes little difference, as it's unlikely that either character will actually be used.

Errata ID: 3255
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Robrecht Dewaele
Date Reported: 2012-06-12
Verifier Name: Barry Leiba
Date Verified: 2012-06-13

Section 5. Replies says:

353    RPL_NAMREPLY
              "( "=" / "*" / "@" ) <channel>
               :[ "@" / "+" ] <nick> *( " " [ "@" / "+" ] <nick> )
         - "@" is used for secret channels, "*" for private
           channels, and "=" for others (public channels).

It should say:

353    RPL_NAMREPLY
              "( "=" / "*" / "@" ) <channel>
               :[ "@" / "+" ] <nick> *( " " [ "@" / "+" ] <nick> )"
         - "@" is used for secret channels, "*" for private
           channels, and "=" for others (public channels).

Notes:

Missing double qoutes to end the reply string.

Errata ID: 3573
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Matthew Helsley
Date Reported: 2013-03-29
Verifier Name: Barry Leiba
Date Verified: 2013-03-29

Section 5.1 says:

           returned.  The exception to this is when a NAMES
           message is sent with no parameters and all visible
           channels and contents are sent back in a series of
           RPL_NAMEREPLY messages with a RPL_ENDOFNAMES to mark
           the end.

It should say:

           returned.  The exception to this is when a NAMES
           message is sent with no parameters and all visible
           channels and contents are sent back in a series of
           RPL_NAMREPLY messages with a RPL_ENDOFNAMES to mark
           the end.

Notes:

RPL_NAMEREPLY should be RPL_NAMREPLY

Errata ID: 4289
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tony Tam
Date Reported: 2015-03-06
Verifier Name: Barry Leiba
Date Verified: 2015-03-06

Section 2.3.1 says:

target     =  nickname / server

It should say:

target     =  nickname / servername

Notes:

There is no "server" rule.

Errata ID: 5017
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Les De Ridder
Date Reported: 2017-05-14
Verifier Name: Alexey Melnikov
Date Verified: 2017-05-19

Section 5.1 says:

       352    RPL_WHOREPLY
              "<channel> <user> <host> <server> <nick>
              ( "H" / "G" > ["*"] [ ( "@" / "+" ) ]
                          ^
              :<hopcount> <real name>"

It should say:

       352    RPL_WHOREPLY
              "<channel> <user> <host> <server> <nick>
              ( "H" / "G" ) ["*"] [ ( "@" / "+" ) ]
              :<hopcount> <real name>"

Notes:

'>' should be ')'

RFC 2813, "Internet Relay Chat: Server Protocol", April 2000

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 383
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Huang Xiangkui
Date Reported: 2006-08-28
Verifier Name: Alexey Melnikov
Date Verified: 2010-07-24

Section 3.3 says:

   The presence of a prefix is indicated with a single leading ASCII
   colon character (':', 0x3b), which MUST be the first character of the
                         ^^^^
   message itself.

It should say:

   The presence of a prefix is indicated with a single leading ASCII
   colon character (':', 0x3a), which MUST be the first character of the
                         ^^^^
   message itself.

Errata ID: 2870
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ricardo Garcia
Date Reported: 2011-07-27
Verifier Name: Peter Saint-Andre
Date Verified: 2011-07-27

Section 5.2.1 says:

as per the LUSER reply

It should say:

as per the LUSERS reply

RFC 2817, "Upgrading to TLS Within HTTP/1.1", May 2000

Note: This RFC has been updated by RFC 7230, RFC 7231

Source of RFC: tls (sec)

Errata ID: 1801
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Nottingham
Date Reported: 2009-07-05
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-18

Section 7.1 says:

   Values to be added to this name space SHOULD be subject to review in
   the form of a standards track document within the IETF Applications
   Area.  Any such document SHOULD be traceable through statuses of
   either 'Obsoletes' or 'Updates' to the Draft Standard for
   HTTP/1.1 [1].

It should say:

     Values to be added to this name space are subject to IETF review
     ([12], Section 4.1).

(where [12] would refer to RFC 5226 in the References Section)

Notes:

Since RFC 2817 was published, it has become harder to publish non-WG
documents on the Standards Track. The "IETF review" policy is defined in
RFC 5226 as:

IETF Review - (Formerly called "IETF Consensus" in
[IANA-CONSIDERATIONS]) New values are assigned only through
RFCs that have been shepherded through the IESG as AD-
Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The
intention is that the document and proposed assignment will
be reviewed by the IESG and appropriate IETF WGs (or
experts, if suitable working groups no longer exist) to
ensure that the proposed assignment will not negatively
impact interoperability or otherwise extend IETF protocols
in an inappropriate or damaging manner.

To ensure adequate community review, such documents are
shepherded through the IESG as AD-sponsored (or WG)
documents with an IETF Last Call.

which should address this nicely.

Furthermore, overloading the "Updates" relation for specifications that
use a well-defined extension point plus an IANA registry is misleading.

Reviewed by the HTTPbis WG; see <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/170>

RFC 2819, "Remote Network Monitoring Management Information Base", May 2000

Source of RFC: rmonmib (ops)

Errata ID: 5156
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Joel Nelson
Date Reported: 2017-10-16
Verifier Name: Benoit Claise
Date Verified: 2017-10-17

Section 2.1 says:

device has to deal with more than own management station

It should say:

device has to deal with more than one management station

Notes:

Seems to be carried forward from RFC 1757

RFC 2821, "Simple Mail Transfer Protocol", April 2001

Note: This RFC has been obsoleted by RFC 5321

Note: This RFC has been updated by RFC 5336

Source of RFC: drums (app)

Errata ID: 375
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jochen Topf
Date Reported: 2004-11-23
Verifier Name: Pete Resnick
Date Verified: 2011-05-16

Section 4.2.5 says:

  When an SMTP server returns a permanent error status (5yz) code after
  the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make
  any subsequent attempt to deliver that message. 

It should say:

  When an SMTP server returns a transient failure status (4yz) code after
  the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make
  any subsequent attempt to deliver that message. 

Notes:

Fixed in RFC 5321.

Errata ID: 380
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John C Klensin
Date Reported: 2005-09-10

 

For a more complete collection of revisions, please see 
draft-klensin-rfc2821bis-00.txt and the mailing list discussions.

The mailing list information is:

List-Archive: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Subscribe: <mailto:ietf-smtp-request@imc.org?body=subscribe>

Errata ID: 376
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Joel Woods
Date Reported: 2004-03-23

Section 4.1.4 says:

   MAIL (or SEND, SOML, or SAML) MUST NOT be
   sent if a mail transaction is already open, i.e., it should be sent
   only if no mail transaction had been started in the session, or it
   the previous one successfully concluded with a successful DATA  ^^ 
   command, or if the previous one was aborted with a RSET.

It should say:

   MAIL (or SEND, SOML, or SAML) MUST NOT be
   sent if a mail transaction is already open, i.e., it should be sent
   only if no mail transaction had been started in the session, or if
   the previous one successfully concluded with a successful DATA
   command, or if the previous one was aborted with a RSET.

Errata ID: 377
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Richard O. Hammer
Date Reported: 2002-10-17

Section 5 says:

   Two types of information is used to rank the host addresses: multiple
   MX records, and multihomed hosts.

It should say:

   Two types of information are used to rank the host addresses: multiple
   MX records, and multihomed hosts.

Notes:

The verb in that sentence should be "are" not "is".

Errata ID: 378
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Richard O. Hammer
Date Reported: 2002-10-03

Section 3.7 says:

   In general, the availability of Mail eXchanger records in the domain
   name system [22, 27] makes the use of explicit source routes in the
   Internet mail system unnecessary.  Many historical problems with
   their interpretation have made their use undesirable.

It should say:

   In general, the availability of Mail eXchanger records in the domain
   name system [22, 27] makes the use of explicit source routes in the
   Internet mail system unnecessary.  Many historical problems with the 
   interpretation of explicit source routes have made their use undesirable.

Errata ID: 379
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Joel Woods
Date Reported: 2004-03-31

Section 4.5.5 says:

   All other types of messages (i.e., any message which is not required
   by a standards-track RFC to have a null reverse-path) SHOULD be sent
   with with a valid, non-null reverse-path.

It should say:

   All other types of messages (i.e., any message which is not required
   by a standards-track RFC to have a null reverse-path) SHOULD be sent
   with a valid, non-null reverse-path.

Errata ID: 381
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vincent Lefevre
Date Reported: 2004-01-12

Section 3.7 says:

and subsequent distribution.  SMTP, as specified here, is not ideally
suited for this role, and work is underway on standardized mail
submission protocols that might eventually supercede the current practices.  
                                           ^^^^^^^^^

It should say:

and subsequent distribution.  SMTP, as specified here, is not ideally
suited for this role, and work is underway on standardized mail
submission protocols that might eventually supersede the current practices.  

Errata ID: 673
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vincent Lefevre
Date Reported: 2004-01-12

Section 4.1.1.1 says:

available), the client SHOULD send an address literal (see section
4.1.3), optionally followed by information that will help to identify
the client system.  y The SMTP server identifies itself to the SMTP
                   ^^^

It should say:

available), the client SHOULD send an address literal (see section
4.1.3), optionally followed by information that will help to identify
the client system.  The SMTP server identifies itself to the SMTP
                    

Notes:

The "y" should be removed.

Errata ID: 674
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vincent Lefevre
Date Reported: 2004-01-12

Section 4.1.1.1 says:

Normally, the response to EHLO will be a multiline reply.  Each line
of the response contains a keyword and, optionally, one or more
parameters.  Following the normal syntax for multiline replies, these
keyworks follow the code (250) and a hyphen for all but the last
^^^^^^^^

It should say:

Normally, the response to EHLO will be a multiline reply.  Each line
of the response contains a keyword and, optionally, one or more
parameters.  Following the normal syntax for multiline replies, these
keywords follow the code (250) and a hyphen for all but the last

Notes:

Should be "keywords".

RFC 2822, "Internet Message Format", April 2001

Note: This RFC has been obsoleted by RFC 5322

Note: This RFC has been updated by RFC 5335, RFC 5336

Source of RFC: drums (app)

Errata ID: 373
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Frank Ellermann
Date Reported: 2006-01-10
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-21

Section 3.2.6 says:

   unstructured    =       *([FWS] utext) [FWS]

It should say:

   unstructured    =       *([FWS] utext) (*WSP / obs-FWS)

Notes:

A prominent example is the <subject> defined in section 3.6.5:

subject = "Subject:" unstructured CRLF

Expanding the [FWS] at the end (ignoring <obs-FWS>) results in:

subject = "Subject:" *([FWS] utext) [[*WSP CRLF] 1*WSP] CRLF


Alexey: note that this was fixed in RFC 5322 (which obsoleted RFC 2821) in a slightly different way.

RFC 2826, "IAB Technical Comment on the Unique DNS Root", May 2000

Source of RFC: IAB

Errata ID: 4523
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dave Thaler
Date Reported: 2015-11-05
Verifier Name: Andrew Sullivan
Date Verified: 2016-01-07

Section 2 says:

The DNS type of unique naming and name-mapping system may not be
ideal for a number of purposes for which it was never designed, such
a locating information when the user doesn't precisely know the
correct names.

It should say:

The DNS type of unique naming and name-mapping system may not be
ideal for a number of purposes for which it was never designed, such
as locating information when the user doesn't precisely know the
correct names.

Notes:

Typo: "such a locating" should be "such as locating"

Also typo in section 1.2. It says
"any set of resources records"
and should say
"any set of resource records"

RFC 2834, "ARP and IP Broadcast over HIPPI-800", May 2000

Note: This RFC has been updated by RFC 5494

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: int

Errata ID: 680
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sebastian Kulpa
Date Reported: 2002-03-24
Verifier Name: Brian Haberman
Date Verified: 2012-09-07

Section 6.3 says:

On page 19 :

Data sizes and field meaning:
     ar$hrd  16 bits  Hardware type
     ar$pro  16 bits  Protocol type of the protocol fields below
     ar$op   16 bits  Operation code (request, reply, or NAK)
     ar$pln   8 bits  byte length of each protocol address
     ar$rhl   8 bits  requester's HIPPI hardware address length (q)
     ar$thl   8 bits  target's HIPPI hardware address length (x)
     ar$rpa  32 bits  requester's protocol address
     ar$tpa  32 bits  target's protocol address
     ar$rha  qbytes   requester's HIPPI Hardware address
     ar$tha  xbytes   target's HIPPI Hardware address

On page 20, there is :

Where :
     ar$hrd  - SHALL contain 28. (HIPARP)
     ar$pro  - SHALL contain the IP protocol code 2048 (decimal).
     ar$op   - SHALL contain the operational value (decimal):
               1  for   HARP_REQUESTs
               2  for   HARP_REPLYs
               8  for InHARP_REQUESTs
               9  for InHARP_REPLYs
               10 for   HARP_NAK
     ar$pln  - SHALL contain 4.
     ar$rln  - SHALL contain 10 IF this is a HIPPI-800 HW address 
               ELSE, for HIPPI-6400, it SHALL contain 6.
     ar$thl  - SHALL contain 10 IF this is a HIPPI-800 HW address
               ELSE, for HIPPI-6400, it SHALL contain 6.
     ar$rha  - in requests and NAKs it SHALL contain the requester's
               HW address. In replies it SHALL contain the target
               port's HW address.
     ar$rpa  - in requests and NAKs it SHALL contain the requester's IP
               address if known, otherwise zero.
               In other replies it SHALL contain the target
               port's IP address.
     ar$tha  - in requests and NAKs it SHALL contain the target's
               HW address if known, otherwise zero.
               In other replies it SHALL contain the requester's
               HW addressA.
     ar$tpa  - in requests and NAKs it SHALL contain the
               target's IP address if known, otherwise zero.
               In other replies it SHALL contain the requester's
               IP address.

It should say:

On page 19 :

Data sizes and field meaning:
     ar$hrd  16 bits  Hardware type
     ar$pro  16 bits  Protocol type of the protocol fields below
     ar$op   16 bits  Operation code (request, reply, or NAK)
     ar$pln   8 bits  byte length of each protocol address
     ar$rhl   8 bits  requester's HIPPI hardware address length (q)
     ar$thl   8 bits  target's HIPPI hardware address length (x)
     ar$rpa  32 bits  requester's protocol address
     ar$tpa  32 bits  target's protocol address
     ar$rha  qbytes   requester's HIPPI Hardware address
     ar$tha  xbytes   target's HIPPI Hardware address

On page 20, there is :

Where :
     ar$hrd  - SHALL contain 28. (HIPARP)
     ar$pro  - SHALL contain the IP protocol code 2048 (decimal).
     ar$op   - SHALL contain the operational value (decimal):
               1  for   HARP_REQUESTs
               2  for   HARP_REPLYs
               8  for InHARP_REQUESTs
               9  for InHARP_REPLYs
               10 for   HARP_NAK
     ar$pln  - SHALL contain 4.
     ar$rhl  - SHALL contain 10 IF this is a HIPPI-800 HW address
               ELSE, for HIPPI-6400, it SHALL contain 6.
     ar$thl  - SHALL contain 10 IF this is a HIPPI-800 HW address
               ELSE, for HIPPI-6400, it SHALL contain 6.
     ar$rha  - in requests and NAKs it SHALL contain the requester's
               HW address. In replies it SHALL contain the target
               port's HW address.
     ar$rpa  - in requests and NAKs it SHALL contain the requester's IP
               address if known, otherwise zero.
               In other replies it SHALL contain the target
               port's IP address.
     ar$tha  - in requests and NAKs it SHALL contain the target's
               HW address if known, otherwise zero.
               In other replies it SHALL contain the requester's
               HW addressA.
     ar$tpa  - in requests and NAKs it SHALL contain the
               target's IP address if known, otherwise zero.
               In other replies it SHALL contain the requester's
               IP address.

Notes:

The descriptive text references ar$rln rather than the correct ar$rhl.

RFC 2839, "Internet Kermit Service", May 2000

Source of RFC: Legacy
Area Assignment: app

Errata ID: 3700
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Amanda Baber
Date Reported: 2013-08-20
Verifier Name: Barry Leiba
Date Verified: 2013-09-06

Section 6 says:

http://www.iana.org/assignment/port-numbers

It should say:

http://www.iana.org/assignments/port-numbers

RFC 2846, "GSTN Address Element Extensions in E-mail Services", June 2000

Note: This RFC has been updated by RFC 3191, RFC 3192

Source of RFC: fax (app)

Errata ID: 371
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: RFC Editor
Date Reported: 2004-05-28

Section 8 says:

 global-phone = "+" 1*( DIGIT , written-sep )

It should say:

 global-phone = "+" 1*( DIGIT / written-sep )

RFC 2849, "The LDAP Data Interchange Format (LDIF) - Technical Specification", June 2000

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 4009
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Giovanni Cannata
Date Reported: 2014-06-09
Verifier Name: Barry Leiba
Date Verified: 2014-06-11

Section LDIF Syntax says:

change-moddn             = ("modrdn" / "moddn") SEP
                            "newrdn:" (    FILL rdn /
                                       ":" FILL base64-rdn) SEP
                            "deleteoldrdn:" FILL ("0" / "1")  SEP
                            0*1("newsuperior:"
                            (    FILL distinguishedName /
                             ":" FILL base64-distinguishedName) SEP)

It should say:

change-moddn             = ("modrdn" / "moddn") SEP
                            "newrdn:" (    FILL rdn /
                                       ":" FILL base64-rdn) SEP
                            "deleteoldrdn:" FILL ("0" / "1")  SEP [8]
                            0*1("newsuperior:"
                            (    FILL distinguishedName /
                             ":" FILL base64-distinguishedName) SEP)

Note 8: If deleteoldrdn is "0" the old rdn will be kept; if it is "1"
the old rdn will be deleted.

Notes:

There is no formal specification of the meaning of the "deleteoldrdn" value 0 or 1. 1 stands for deletion, 0 stands for keeping the old rdn. Add a note to explain the value meaning.

-----
Verifier note:
It is correct that the meaning of "deleteoldrdn" is never explained in the document. The proposed resolution is a reasonable fix for that, and such an explanation is needed.

Errata ID: 4377
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Keita Kondou
Date Reported: 2015-05-28
Verifier Name: Barry Leiba
Date Verified: 2015-05-28

Section LDIF Syntax says:

ldap-oid                 = 1*DIGIT 0*1("." 1*DIGIT)
                           ; An LDAPOID, as defined in [4]

It should say:

ldap-oid                 = 1*DIGIT 0*("." 1*DIGIT)
                           ; An LDAPOID, as defined in [4]

Notes:

ldap-oid syntax on RFC2849 allow only ONE dot.
But it should allow decimal string separated by multi dots.

RFC2251 LDAPOID definition:
The LDAPOID is a notational convenience to indicate that the
permitted value of this string is a (UTF-8 encoded) dotted-decimal
representation of an OBJECT IDENTIFIER.

LDAPOID ::= OCTET STRING

For example,

1.3.6.1.4.1.1466.1.2.3

RFC 2861, "TCP Congestion Window Validation", June 2000

Note: This RFC has been obsoleted by RFC 7661

Source of RFC: tsvwg (wit)

Errata ID: 1303
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sally Floyd
Date Reported: 2008-01-23
Verifier Name: Lars Eggert
Date Verified: 2009-02-16

Section 7 says:

None.

It should say:

[B97] Bradner, S., "Key words for use in RFCs to Indicate
         Requirement Levels", BCP 14, RFC 2119, March 1997.

Notes:

Missing citation. Reported by Emmanuel Papirakis.

RFC 2863, "The Interfaces Group MIB", June 2000

Note: This RFC has been updated by RFC 8892

Source of RFC: ifmib (int)

Errata ID: 4820
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Christopher L Marshall
Date Reported: 2016-10-05
Verifier Name: Éric Vyncke
Date Verified: 2024-01-12

Section 3.1.7 says:

   Network speeds are increasing.  The range of ifSpeed is limited to
   reporting a maximum speed of (2**31)-1 bits/second, or approximately
   2.2Gbs.  SONET defines an OC-48 interface, which is defined at
   operating at 48 times 51 Mbs, which is a speed in excess of 2.4Gbs.
   Thus, ifSpeed is insufficient for the future, and this memo defines
   an additional object: ifHighSpeed.

It should say:

   Network speeds are increasing.  The range of ifSpeed is limited to
   reporting a maximum speed of (2**32)-1 bits/second, or approximately
   4.3Gbs.  SONET defines an OC-48 interface, which is defined at
   operating at 48 times 51 Mbs, which is a speed in excess of 2.4Gbs.
   Thus, ifSpeed is insufficient for the future, and this memo defines
   an additional object: ifHighSpeed.

Notes:

RFC 3635, in section 3.2.8 quotes RFC2863 as if it were using the correct 4.3Gbps value: "For these speeds, ifSpeed should report a maximum unsigned 32-bit value of 4,294,967,295 as specified in [RFC2863]."

-- Verifier note --

Indeed https://www.rfc-editor.org/rfc/rfc2578#section-7.1.6 states that Gauge32 has a max of 4.3 Gbps (in this case). Noting that this value renders the justification of ifHighSpeed not relevant but nowadays network speeds are much higher anyway than 4.3 Gbps

RFC 2865, "Remote Authentication Dial In User Service (RADIUS)", June 2000

Note: This RFC has been updated by RFC 2868, RFC 3575, RFC 5080, RFC 6929, RFC 8044

Source of RFC: radius (ops)

Errata ID: 368
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Aaron Webb
Date Reported: 2002-09-12

Section 5.18 says:

   Multiple Reply-Message's MAY be included and if any are displayed,
   they MUST be displayed in the same order as they appear in the
   packet.

It should say:

   Multiple Reply-Messages MAY be included and if any are displayed,
   they MUST be displayed in the same order as they appear in the
   packet.

Errata ID: 1469
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Isaac NickAein
Date Reported: 2008-07-13
Verifier Name: Dan Romascanu
Date Verified: 2011-08-03

Section 7.3. says:

      02 01 00 38 15 ef bc 7d ab 26 cf a3 dc 34 d9 c0
      3c 86 01 a4 06 06 00 00 00 02 07 06 00 00 00 01
      08 06 ff ff ff fe 0a 06 00 00 00 02 0d 06 00 00
      00 01 0c 06 00 00 05 dc

It should say:

      02 01 00 38 E8 6F A2 FE 28 70 33 AD 2F 6D 5C A3
      F7 41 5D A2 06 06 00 00 00 02 07 06 00 00 00 01
      08 06 FF FF FF FE 0A 06 00 00 00 00 0D 06 00 00
      00 01 0C 06 00 00 05 DC

Notes:

in Attributes, "Framed-Routing" came with value "None" (0)
but in Hex dump of packet the value for this attribute is "Listen for routing packets" (2)

Correct Hex Dump, or Attributes.

Corrected Attributes is:

Attributes:
6 Service-Type (6) = Framed (2)
6 Framed-Protocol (7) = PPP (1)
6 Framed-IP-Address (8) = 255.255.255.254
6 Framed-Routing (10) = Listen for routing packets (2)
6 Framed-Compression (13) = VJ TCP/IP Header Compression (1)
6 Framed-MTU (12) = 1500

----------

VERIFIER NOTE: Referenced section should be 7.2 and not 7.3

Errata ID: 6486
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Paul Bennett
Date Reported: 2021-03-18
Verifier Name: Robert Wilton
Date Verified: 2021-03-24

Section 7.3 says:

   The state is the magic cookie from the Access-Challenge packet,
   unchanged.

      01 03 00 43 b1 22 55 6d 42 8a 13 d0 d6 25 38 07
      c4 57 ec f0 01 07 6d 6f 70 73 79 02 12 69 2c 1f
      20 5f c0 81 b9 19 b9 51 95 f5 61 a5 81 04 06 c0
      a8 01 10 05 06 00 00 00 07 18 10 33 32 37 36 39
      34 33 30

       1 Code = Access-Request (1)

It should say:

   The state is the magic cookie from the Access-Challenge packet,
   unchanged.

      01 03 00 43 b1 22 55 6d 42 8a 13 d0 d6 25 38 07
      c4 57 ec f0 01 07 6d 6f 70 73 79 02 12 69 2c 1f
      20 5f c0 81 b9 19 b9 51 95 f5 61 a5 81 04 06 c0
      a8 01 10 05 06 00 00 00 07 18 0a 33 32 37 36 39
      34 33 30

       1 Code = Access-Request (1)

Notes:

Mistake is length of last attribute of sample packet on page 70, in penultimate line of hex dump. RFC has 0x10; correct value is 0x0a. (Sample on page 69 shows correct value.)

Errata ID: 2712
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Wang Haojian
Date Reported: 2011-02-12
Verifier Name: Dan Romascanu
Date Verified: 2011-02-13

Section 5 says:

      Note that none of the types in RADIUS terminate with a NUL (hex
      00).  In particular, types "text" and "string" in RADIUS do not
      terminate with a NUL (hex 00).  The Attribute has a length field
      and does not use a terminator.  Text contains UTF-8 encoded 10646
      [7] characters and String contains 8-bit binary data.  Servers and
      servers and clients MUST be able to deal with embedded nulls.
      ^^^^^^^^^^^^

It should say:

      Note that none of the types in RADIUS terminate with a NUL (hex
      00).  In particular, types "text" and "string" in RADIUS do not
      terminate with a NUL (hex 00).  The Attribute has a length field
      and does not use a terminator.  Text contains UTF-8 encoded 10646
      [7] characters and String contains 8-bit binary data.  Servers and
      clients MUST be able to deal with embedded nulls.

Notes:

Unnecessary Words.

RFC 2866, "RADIUS Accounting", June 2000

Note: This RFC has been updated by RFC 2867, RFC 5080, RFC 5997

Source of RFC: radius (ops)

Errata ID: 4485
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nick Lowe
Date Reported: 2015-09-27
Verifier Name: Benoit Claise
Date Verified: 2015-10-05

Section 5.1 says:

This attribute indicates whether this Accounting-Request marks the
beginning of the user service (Start) or the end (Stop).

It MAY be used by the client to mark the start of accounting (for
example, upon booting) by specifying Accounting-On and to mark the
end of accounting (for example, just before a scheduled reboot) by
specifying Accounting-Off.

It should say:

This attribute indicates whether this Accounting-Request marks the
beginning of the user service (Start) or the end (Stop).

It MAY be used by the client to mark the start of accounting for the
NAS (for example, upon booting) by specifying Accounting-On
and to mark the end of accounting for the NAS (for example, just
before a scheduled reboot) by specifying Accounting-Off.

Notes:

Some RADIUS client implementations send scoped Accounting-On and Accounting-Off Accounting-Request packets. This is seen, for example, with some wireless APs that include a Called-Station-Id attribute to scope to a Basic Service Set (BSS).

This is an incorrect interpretation of the RFC that is not backwards compatible with consumers of RADIUS accounting information, yet the RFC is ambiguous on this point.

The RFC must be clear that Accounting-On and Accounting-Off apply to the whole NAS and cannot be scoped in this manner.

New Acct-Status-Type values must instead be defined to allow this, perhaps named something like Scoped-Accounting-On and Scoped-Accounting-Off.

Errata ID: 2713
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Wang Haojian
Date Reported: 2011-02-12
Verifier Name: Dan Romascanu
Date Verified: 2011-02-13

Section 5 says:

      [7] characters and String contains 8-bit binary data.  Servers and
      servers and clients MUST be able to deal with embedded nulls.
      ^^^^^^^^^^

It should say:

      [7] characters and String contains 8-bit binary data.  Servers and
      clients MUST be able to deal with embedded nulls.

Notes:

Same as RFC 2865 , extraneous "servers and" can be deleted. ;)

Errata ID: 3896
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Andrew Kowal
Date Reported: 2014-02-18
Verifier Name: Benoit Claise
Date Verified: 2014-02-18

Section 3 says:

This memo documents the RADIUS Accounting protocol.  The early
deployment of RADIUS Accounting was done using UDP port number 1646,
which conflicts with the "sa-msg-port" service.  The officially
assigned port number for RADIUS Accounting is 1813.

Notes:

The whole 3rd paragraph of section 3 is a duplicate of "Implementation Note" section and is barely related to packet format description.

RFC 2867, "RADIUS Accounting Modifications for Tunnel Protocol Support", June 2000

Source of RFC: radius (ops)

Errata ID: 367
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Unai Pildain
Date Reported: 2005-05-31

Section 3.5 says:

            Acct-Multi-Session-Id (51)

It should say:

            Acct-Multi-Session-Id (50)

Notes:

RFC 2868, "RADIUS Attributes for Tunnel Protocol Support", June 2000

Note: This RFC has been updated by RFC 3575

Source of RFC: radius (ops)

Errata ID: 2714
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Wang Haojian
Date Reported: 2011-02-12
Verifier Name: Dan Romascanu
Date Verified: 2011-02-28

Section 3.10 says:

3.10.  Tunnel-Server-Auth-ID

   Description

      This Attribute specifies the name used by the tunnel terminator
      during the authentication phase of tunnel establishment.  The
      Tunnel-Client-Auth-ID Attribute MAY be included (as a hint to the
      ^^^^^^^^^^^^^^^^^^^^^

It should say:

3.10.  Tunnel-Server-Auth-ID

   Description

      This Attribute specifies the name used by the tunnel terminator
      during the authentication phase of tunnel establishment.  The
      Tunnel-Server-Auth-ID Attribute MAY be included (as a hint to the

Notes:

Maybe here should be the "Tunnel-Server-Auth-ID"

Errata ID: 2716
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Wang Haojian
Date Reported: 2011-02-12
Verifier Name: Dan Romascanu
Date Verified: 2011-02-13

Section 6 says:

6.1.  Tunnel-Type Attribute Values

   Values 1-12 of the Tunnel-Type Attribute are defined in Section 5.1;
   the remaining values are available for assignment by the IANA with
   IETF Consensus [16].

6.2.  Tunnel-Medium-Type Attribute Values

   Values 1-15 of the Tunnel-Medium-Type Attribute are defined in
   Section 5.2; the remaining values are available for assignment by the
   IANA with IETF Consensus [16].

It should say:

6.1.  Tunnel-Type Attribute Values

   Values 1-12 of the Tunnel-Type Attribute are defined in Section 3.1;
   the remaining values are available for assignment by the IANA with
   IETF Consensus [16].

6.2.  Tunnel-Medium-Type Attribute Values

   Values 1-15 of the Tunnel-Medium-Type Attribute are defined in
   Section 3.2; the remaining values are available for assignment by the
   IANA with IETF Consensus [16].

Notes:

Should be "Section 3.1" and "Section 3.2"

RFC 2873, "TCP Processing of the IPv4 Precedence Field", June 2000

Note: This RFC has been obsoleted by RFC 9293

Source of RFC: Legacy

Errata ID: 366
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kurt D. Zeilenga
Date Reported: 2001-11-06

In the References Section:

   [RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
             "Assured Forwarding PHB Group", RFC 2587, June 1999.

It should say:

   [RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
             "Assured Forwarding PHB Group", RFC 2597, June 1999.

RFC 2876, "Use of the KEA and SKIPJACK Algorithms in CMS", July 2000

Source of RFC: smime (sec)

Errata ID: 1839
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sean Turner
Date Reported: 2009-08-25
Verifier Name: Tim Polk
Date Verified: 2010-04-19

Section 7 says:

300b 0609 6086 4801 6502 0101 0400

It should say:

300b 0609 6086 4801 6502 0101 04

Notes:

The SMIMECapability for SKIPJACK should be 300b 0609 6086 4801 6502 0101 04, which is the DER encoding of the id-fortezzaConfidentialityAlgorithm OID. The extra 00 should not be included.

RFC 2883, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", July 2000

Source of RFC: tsvwg (wit)

Errata ID: 365
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Noritoshi Demizu
Date Reported: 2004-06-21

Section 4.2.3 says:

         Transmitted    Received    ACK Sent
         Segment        Segment     (Including SACK Blocks)

         500-999        500-999     1000
         1000-1499      (data packet dropped)
         1500-1999      (delayed)
         2000-2499      (data packet dropped)
         2500-2999      (delayed)
         3000-3499      (data packet dropped)
         3500-3999      3500-3999   1000, SACK=3500-4000
         1000-1499      (data packet dropped)
         1500-2999      1500-1999   1000, SACK=1500-2000, 3500-4000
                        2000-2499   1000, SACK=2000-2500, 1500-2000,
                                            3500-4000
                        1500-2999   1000, SACK=1500-2000, 1500-3000,
                                               ---------
                                            3500-4000

It should say:

         Transmitted    Received    ACK Sent
         Segment        Segment     (Including SACK Blocks)

         500-999        500-999     1000
         1000-1499      (data packet dropped)
         1500-1999      (delayed)
         2000-2499      (data packet dropped)
         2500-2999      (delayed)
         3000-3499      (data packet dropped)
         3500-3999      3500-3999   1000, SACK=3500-4000
         1000-1499      (data packet dropped)
         1500-2999      1500-1999   1000, SACK=1500-2000, 3500-4000
                        2500-2999   1000, SACK=2500-3000, 1500-2000,
                                            3500-4000
                        1500-2999   1000, SACK=1500-2000, 1500-3000,
                                               ---------
                                            3500-4000

RFC 2889, "Benchmarking Methodology for LAN Switching Devices", August 2000

Source of RFC: bmwg (ops)

Errata ID: 6284
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Su Yu Lung
Date Reported: 2020-09-10
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2020-09-10

Section 5.8.3 says:

This test MUST at a minimum be performed in a three-port
   configuration in section 5.9.3.

It should say:

This test MUST at a minimum be performed in a three-port
   configuration in section 5.7.3.

Notes:

I thought it means 5.7.3.
If so, the same incorrect link also happened at 5.8.2.

"It is recommended no to exceed the address caching capacity found in section 5.9" should be "It is recommended no to exceed the address caching capacity found in section 5.7"

RFC 2898, "PKCS #5: Password-Based Cryptography Specification Version 2.0", September 2000

Note: This RFC has been obsoleted by RFC 8018

Source of RFC: Legacy

Errata ID: 4966
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Huu Nguyen
Date Reported: 2017-03-13
Verifier Name: Roman Danyliw
Date Verified: 2024-01-11

Section 5.1 says:

                   DK = Tc<0..dkLen-1>

It should say:

                   DK = T_c<0..dkLen-1>

Notes:

The referenced variable Tc does not exist.

RFC 2910, "Internet Printing Protocol/1.1: Encoding and Transport", September 2000

Note: This RFC has been obsoleted by RFC 8010

Note: This RFC has been updated by RFC 3380, RFC 3381, RFC 3382, RFC 3510, RFC 3995, RFC 7472

Source of RFC: ipp (app)

Errata ID: 4172
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Sweet
Date Reported: 2014-11-12
Verifier Name: Barry Leiba
Date Verified: 2014-11-12

Section 3.5 says:

   a value that the parser treats atomically.  Values from 0x00 to
   0x37777777 are reserved for definition in future IETF standard track
   documents.  The values 0x40000000 to 0x7FFFFFFF are reserved for
   vendor extensions.

It should say:

   a value that the parser treats atomically.  Values from 0x00 to
   0x3FFFFFFF are reserved for definition in future IETF Standards Track
   documents.  The values 0x40000000 to 0x7FFFFFFF are reserved for
   vendor extensions.

RFC 2911, "Internet Printing Protocol/1.1: Model and Semantics", September 2000

Note: This RFC has been obsoleted by RFC 8011

Note: This RFC has been updated by RFC 3380, RFC 3382, RFC 3996, RFC 3995, RFC 7472

Source of RFC: ipp (app)

Errata ID: 364
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tom Hastings
Date Reported: 2002-07-17

Section 13 says:

"redirection" - 0x0200 to 0x02FF

It should say:

"redirection" - 0x0300 to 0x03FF

Errata ID: 694
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tom Hastings
Date Reported: 2002-07-17

Section 13, Appendix B says:

The top half (128 values) of each range (0x0n40 to 0x0nFF, for 
n = 0 to 5) is reserved for vendor use within each status code
class. 

It should say:

The top half (128 values) of each range (0x0n80 to 0x0nFF, for 
n = 0 to 5) is reserved for vendor use within each status code
class.   

Notes:

Errata ID: 3365
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Sweet
Date Reported: 2012-09-25
Verifier Name: Barry Leiba
Date Verified: 2012-10-01

Section 4.1.2.2 says:

4.1.2.2 'nameWithLanguage'

   The 'nameWithLanguage' attribute syntax is a compound attribute
   syntax consisting of two parts: a 'nameWithoutLanguage' part encoded
   in a maximum of 1023 (MAX) octets plus an additional

It should say:

4.1.2.2 'nameWithLanguage'

   The 'nameWithLanguage' attribute syntax is a compound attribute
   syntax consisting of two parts: a 'nameWithoutLanguage' part (see
   Section 4.1.2.1) plus an additional

Notes:

The maximum length of the nameWithoutLanguage value (section 4.1.2.1) is 255 octets, not 1023. Better to just do it by reference, rather than by repeating the information.

Errata ID: 4173
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Sweet
Date Reported: 2014-11-12
Verifier Name: Barry Leiba
Date Verified: 2014-11-12

Section 4.4.15 says:

    0x4000-0x8FFF       reserved for vendor extensions (see section 6.4)

It should say:

    0x4000-0x7FFF       reserved for vendor extensions (see section 6.4)

Notes:

operation code is a 16-bit signed integer; max is therefore 0x7FFF...

RFC 2916, "E.164 number and DNS", September 2000

Note: This RFC has been obsoleted by RFC 3761

Source of RFC: enum (rai)

Errata ID: 362
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Dr. Carsten Bormann
Date Reported: 2000-09-27

 

* IN NAPTR 100 10 "u" "ldap+E2U" "!^+46(.*)$!ldap://ldap.se/cn=01!" .

It should say:

* IN NAPTR 100 10 "u" "ldap+E2U" "!^+46(.*)$!ldap://ldap.se/cn=0\1!" .

Errata ID: 363
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Andrews
Date Reported: 2006-04-12
Verifier Name: Robert Sparks
Date Verified: 2010-03-05

Erratum reported says that it should be:

* IN NAPTR 100 10 "u" "ldap+E2U" "!^+46(.*)$!ldap://ldap.se/cn=0\1!" .

It should say:

* IN NAPTR 100 10 "u" "ldap+E2U" "!^+46(.*)$!ldap://ldap.se/cn=0\\1!" .

Notes:

A double backslash is needed as single backslash is the escape
chararacter in the presentation format of a TXT element.
The on wire format requires a single backslash which results
in a double backslash in the presentation format.

RFC 2919, "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists", March 2001

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 3951
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Occil
Date Reported: 2014-04-03
Verifier Name: Pete Resnick
Date Verified: 2014-04-04

Section 3 says:

   The syntax of the List-Id header follows:

   list-id-header = "List-ID:" [phrase] "<" list-id ">" CRLF

It should say:

   The syntax of the List-Id header follows:

   list-id-header = "List-ID:" [phrase / CFWS] "<" list-id ">" CRLF

Notes:

This change is needed to conform with the second and fifth examples
given just after the syntax definition. Without it, the case "List-ID: <list.example.com>" (with a space after "List-ID:") would not be valid; only "List-ID:<list.example.com>" (without a space) would be, especially since it states that "the List-Id header does not allow free insertion of whitespace and comments around tokens."

RFC 2925, "Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations", September 2000

Note: This RFC has been obsoleted by RFC 4560

Source of RFC: disman (ops)

Errata ID: 360
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Randy Presuhn
Date Reported: 2002-03-26

Section 4.1 says:

   "Generated at the completion of a ping test when the
   corresponding pingCtlTrapGeneration object is set to
   testCompletion(4)."

It should say:

   "Generated at the completion of a ping test when the
   corresponding pingCtlTrapGeneration object is set to
   testCompletion(2)."

RFC 2927, "MIME Directory Profile for LDAP Schema", September 2000

Source of RFC: schema (app)

Errata ID: 359
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2002-01-04

Section 3 says:

   Content-Type: text/directory; profile="schema-ldap-0";charset="utf-8"
   Content-Transfer-Encoding: Quoted-Printable
   ldapSchemas: ( 1.2.3.4 NAME 'bogus schema' CLASSES ( top $ thing ) =
   ATTRIBUTES ( objectClass $ name ) SYNTAXES ( =
   1.3.6.1.4.1.1466.115.121.1.38 $ 1.3.6.1.4.1.1466.115.121.1.15 ) )

It should say:

   Content-Type: text/directory; profile="schema-ldap-0";charset="utf-8"
   Content-Transfer-Encoding: Quoted-Printable
   
   ldapSchemas: ( 1.2.3.4 NAME 'bogus schema' CLASSES ( top $ thing ) =
   ATTRIBUTES ( objectClass $ name ) SYNTAXES ( =
   1.3.6.1.4.1.1466.115.121.1.38 $ 1.3.6.1.4.1.1466.115.121.1.15 ) )

RFC 2938, "Identifying Composite Media Features", September 2000

Source of RFC: conneg (app)

Errata ID: 1080
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Frank Ellermann
Date Reported: 2007-11-19
Verifier Name: Alexey Melnikov
Date Verified: 2009-10-03

Section 4 says:

(h.QGEOPMCF02P09QC016CEPU22FO)
where
(h.QGEOPMCF02P09QC016CEPU22FO) :-
 (| (& (ua-media=continuous) (dpi=200) (dpi-xyratio=200/100)
       (color=Binary) (paper-size=B4) (image-coding=MH) )
    (& (ua-media=continuous) (dpi=200) (dpi-xyratio=200/100)
       (color=Binary) (paper-size=B4) (image-coding=MR) )
    (& (ua-media=stationery) (dpi=300) (dpi-xyratio=1)
       (color=Binary) (paper-size=A4) (image-coding=JBIG) )
    (& (ua-media=transparency) (dpi=300) (dpi-xyratio=1)

       (color=Binary) (paper-size=A4) (image-coding=JBIG) ) )
end

It should say:

(h.U965DKFHDGT0344VRHI6OONIBS)
where
(h.U965DKFHDGT0344VRHI6OONIBS) :-
 (| (& (ua-media=continuous) (dpi=200) (dpi-xyratio=200/100)
       (color=Binary) (paper-size=B4) (image-coding=MH) )
    (& (ua-media=continuous) (dpi=200) (dpi-xyratio=200/100)
       (color=Binary) (paper-size=B4) (image-coding=MR) )
    (& (ua-media=stationery) (dpi=300) (dpi-xyratio=1)
       (color=Binary) (paper-size=A4) (image-coding=JBIG) )
    (& (ua-media=transparency) (dpi=300) (dpi-xyratio=1)
       (color=Binary) (paper-size=A4) (image-coding=JBIG) ) )
end

Notes:

In an MD5 test suite the other three RFC 2938 examples work as expected

RFC 2939, "Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types", September 2000

Source of RFC: dhc (int)

Errata ID: 358
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tyler Tidman
Date Reported: 2001-09-04

Section 1 says:

   DHCP protocol messages are identified by the 'DHCP Message Type'
   option (option code 51).

It should say:

   DHCP protocol messages are identified by the 'DHCP Message Type'
   option (option code 53).

Errata ID: 854
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Frank Ellermann
Date Reported: 2007-02-02
Verifier Name: Brian Haberman
Date Verified: 2012-07-24

Section 4 says:

   [3] Droms, R. and K. Fong, "NetWare/IP Domain Name and Information",
       RFC 2142, November 1997.

It should say:

   [3] Droms, R. and K. Fong, "NetWare/IP Domain Name and Information",
       RFC 2242, November 1997.

Notes:

References to RFC 2142 should be to 2242.

from pending

RFC 2965, "HTTP State Management Mechanism", October 2000

Note: This RFC has been obsoleted by RFC 6265

Source of RFC: http (app)

Errata ID: 2644
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Loïc Etienne
Date Reported: 2010-11-23
Verifier Name: Peter Saint-Andre
Date Verified: 2011-05-16

Section 3.3.4 says:

port = "$Port" [ "=" <"> value <"> ]

It should say:

port = "$Port" [ "=" <"> portlist <"> ]

Notes:

<value> is too general, possibly being itself a <quoted-string> (resulting in a twofold quoted string).

The suggested change would agree with the definition on page 5, section 3.2.2: "Port" [ "=" <"> portlist <"> ]

Errata ID: 1491
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2008-08-20
Verifier Name: Alexey Melnikov
Date Verified: 2010-04-02

Section 12 says:

   [Netscape] "Persistent Client State -- HTTP Cookies", available at
              <http://www.netscape.com/newsref/std/cookie_spec.html>,
              undated.

It should say:

   [Netscape] "Persistent Client State -- HTTP Cookies", available at
              <http://www.netscape.com/newsref/std/cookie_spec.html>,
              undated.

              Copy avalaible at <http://curl.haxx.se/rfc/cookie_spec.html>

Notes:

The original URL at www.netscape.com, so it would be good to point readers to an available copy of the document.

RFC 2978, "IANA Charset Registration Procedures", October 2000

Source of RFC: Legacy

Errata ID: 357

Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ned Freed
Date Reported: 2003-02-09
Report Text:

(1) All references in RFC 2978 to RFC 2184 should be replaced by RFC
    2231.  RFC 2231 obsoleted RFC 2184 before RFC 2978 was published.

(2) The fact that vertical bar and backslash characters are now
    excluded from charset names was a change from RFC 2278 that should
    have been noted in section 7.

---

Errata ID: 1912
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ned Freed
Date Reported: 2009-10-13
Verifier Name: Alexey Melnikov
Date Verified: 2018-09-21

Section 2.3 says:

mime-charset-chars = ALPHA / DIGIT /
            "!" / "#" / "$" / "%" / "&" /
            "'" / "+" / "-" / "^" / "_" /
            "`" / "{" / "}" / "~"
    

It should say:

mime-charset-chars = ALPHA / DIGIT /
            "!" / "#" / "$" / "%" / "&" /
            "+" / "-" / "^" / "_" / "`" /
            "{" / "}" / "~"

Notes:

RFC 2231 uses single quotes as delimiters around charset names. As such, single quote should have been excluded from the list of legal characters that can appear in a charset name.

Note that this Erratum was further updated by <https://www.rfc-editor.org/errata/eid5433>
to make the list of characters even more restrictive.

Errata ID: 5433
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2018-07-22
Verifier Name: Alexey Melnikov
Date Verified: 2018-09-20

Section 2.3 says:

mime-charset-chars = ALPHA / DIGIT /
            "!" / "#" / "$" / "%" / "&" /
            "'" / "+" / "-" / "^" / "_" /
            "`" / "{" / "}" / "~"

It should say:

mime-charset-chars = ALPHA / DIGIT /
            "!" / "#" / "$" / "%" / "&" /
            "+" / "-" / "^" / "_" / "`" /
            "~" 

Notes:

HTTP (RFC 7231, Section 3.1.1.2) uses "token" in Accept-Charset. However, token does not allow for curly braces (see RFC 7230, Section 3.2.6). The IANA charset registry does not contain registered names with curly braces, so it would be good to disallow them completely.

(Note that the corrected ABNF incorporates the change for <https://www.rfc-editor.org/errata/eid1912>)

Alexey: Taking into consideration that this RFC is unlikely to be revised, I am approving this erratum, instead of insisting on a new version of the RFC that incorporates this change.

RFC 2985, "PKCS #9: Selected Object Classes and Attribute Types Version 2.0", November 2000

Source of RFC: Legacy
Area Assignment: sec

Errata ID: 356
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Robert Moskowitz
Date Reported: 2000-12-13

The Table of Contents says:

5.6  Attributes defined in S/MIMIE .............................. 18

It should say:

5.6  Attributes defined in S/MIME ..............................  18

RFC 2988, "Computing TCP's Retransmission Timer", November 2000

Note: This RFC has been obsoleted by RFC 6298

Source of RFC: tsvwg (wit)

Errata ID: 1308
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Scharf
Date Reported: 2008-02-05
Verifier Name: Lars Eggert
Date Verified: 2009-02-16

Section References says:

   [Jac88] Jacobson, V., "Congestion Avoidance and Control", Computer
           Communication Review, vol. 18, no. 4, pp. 314-329, Aug.  1988.

   [JK88]  Jacobson, V. and M. Karels, "Congestion Avoidance and
           Control", ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z.

It should say:

   [Jac88] Jacobson, V., "Congestion Avoidance and Control", Computer
           Communication Review, vol. 18, no. 4, pp. 314-329, Aug.  1988.

   [JBB92] Jacobson, V., Braden, R., Borman, D., "TCP Extensions for High
           Performance", RFC 1323, May 1992.

   [JK88]  Jacobson, V. and M. Karels, "Congestion Avoidance and
           Control", ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z.

Notes:

Reference [JBB92] is mentioned two times in section 3, but it is not included in the reference section.

RFC 3003, "The audio/mpeg Media Type", November 2000

Source of RFC: Legacy

Errata ID: 355
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Colin Perkins
Date Reported: 2000-11-22

 

   * NOTE: The audio/MPS mime type is in use in addition to the
   audio/mpeg. 

It should say:

   * NOTE: The audio/MPA mime type is in use in addition to the
   audio/mpeg. 

RFC 3010, "NFS version 4 Protocol", December 2000

Note: This RFC has been obsoleted by RFC 3530

Source of RFC: nfsv4 (wit)

Errata ID: 354

Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Matthew Wilcox
Date Reported: 2002-06-11
Report Text:

RFC 3010 claims that it obsoletes RFC 1813 and RFC 1094, when in fact it does not.

---

RFC 3015, "Megaco Protocol Version 1.0", November 2000

Note: This RFC has been obsoleted by RFC 3525

Source of RFC: megaco (rai)

Errata ID: 353
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Brian Rosen
Date Reported: 2001-09-04

In Section Annex B

   V4hex                = 1*3(DIGIT) ; "0".."225"

It should say:

   V4hex                = 1*3(DIGIT) ; "0".."255"

RFC 3023, "XML Media Types", January 2001

Note: This RFC has been obsoleted by RFC 7303

Note: This RFC has been updated by RFC 6839

Source of RFC: Legacy

Errata ID: 352
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Murata Makoto
Date Reported: 2003-05-09

Section 8.13 says:

   {BOM}<?xml encoding="utf-16"?>

   or

   {BOM}<?xml?>

It should say:

   {BOM}<?xml encoding="utf-16"?>

RFC 3024, "Reverse Tunneling for Mobile IP, revised", January 2001

Source of RFC: mobileip (int)

Errata ID: 351
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Gabriel Montenegro
Date Reported: 2003-06-02

Section 4.3.1 says:

    Upon receipt of a Registration Reply that satisfies validity
    checks,

It should say:

    Upon receipt of a Registration Request that satisfies validity
    checks,

RFC 3028, "Sieve: A Mail Filtering Language", January 2001

Note: This RFC has been obsoleted by RFC 5228, RFC 5429

Source of RFC: Legacy
Area Assignment: app

Errata ID: 350
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Piotr Kucharski
Date Reported: 2003-09-22

Section 2.4.1 says:

   mebi-, or 1,048,576 (2^20) times the value of the number; and G
   specifies tebi-, or 1,073,741,824 (2^30) times the value of the
   number [BINARY-SI].

It should say:

    mebi-, or 1,048,576 (2^20) times the value of the number; and G
    specifies gibi-, or 1,073,741,824 (2^30) times the value of the
    number [BINARY-SI].

Errata ID: 1493
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Costin Chirvasuta
Date Reported: 2008-08-21
Verifier Name: Peter Saint-Andre
Date Verified: 2010-11-11

Section 3.1 says:

   actually a separate command in terms of the grammar.  However, an
   elsif MUST only follow an if, and an else MUST follow only either an
   if or an elsif.  An error occurs if these conditions are not met.

It should say:

   actually a separate command in terms of the grammar.  However, an
   elsif or an else MUST only follow an if or an elsif.  An error occurs
   if these conditions are not met.

Notes:

Peter: Fixed in RFC 5228.

Errata ID: 5134
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Smith
Date Reported: 2017-10-03
Verifier Name: Barry Leiba
Date Verified: 2019-04-30

Section 8.1 says:

   CHAR-NOT-SLASH = (%x00-57 / %x58-ff)

   CHAR-NOT-STAR = (%x00-51 / %x53-ff)

It should say:

   CHAR-NOT-SLASH = (%x00-2e / %x30-ff)

   CHAR-NOT-STAR = (%x00-29 / %x2b-ff)

Notes:

The CHAR-NOT-SLASH is attempting to not include the SLASH character and makes two errors. Firstly, no character is skipped. Secondly, a slash character is octal 57. The correct hex value for slash is 2F.

The CHAR-NOT-STAR is attempting to not include the STAR character and claims that this is character 52. STAR is actually hex 0x2A. The apparent mistake is that the octal value of the character (STAR is octal 52) was entered as a hex value.

RFC 3029, "Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols", February 2001

Source of RFC: pkix (sec)

Errata ID: 6443
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2021-02-26
Verifier Name: Benjamin Kaduk
Date Verified: 2021-02-26

Section Appendix E says:

  ContentInfo FROM CryptographicMessageSyntax {iso(1)
  member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
  smime(16) modules(0) cms(1)}

It should say:

  ContentInfo, DigestAlgorithmIdentifier
  FROM CryptographicMessageSyntax
    {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
     smime(16) modules(0) cms(1)}

Notes:

DigestAlgorithmIdentifier is not defined in the ASN.1 Module. The easiest fix is to IMPORT it from the CMS ASN.1 Module.

Errata ID: 6444
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2021-02-26
Verifier Name: Roman Danyliw
Date Verified: 2022-05-10

Section Appendix E says:

  GeneralName, PolicyInformation
  FROM PKIX1Implicit88 {iso(1) identified-organization(3)
  dod(6) internet(1) security(5) mechanisms(5) pkix(7)
  id-mod(0) id-pkix1-implicit-88(2)}

It should say:

  GeneralName, GeneralNames, PolicyInformation
  FROM PKIX1Implicit88 {iso(1) identified-organization(3)
  dod(6) internet(1) security(5) mechanisms(5) pkix(7)
  id-mod(0) id-pkix1-implicit-88(2)}

Notes:

The ASN.1 Module uses GeneralName and GeneralNames, but only one of them is IMPORTed. The suggested fix IMPORTS both of GeneralName and GeneralNames.

RFC 3030, "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", December 2000

Source of RFC: Legacy

Errata ID: 349
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Emmanuel Papirakis
Date Reported: 2003-01-14

Section 4.2 says:

   The following dialogue illustrates the use of the large message
   extension to send a BINARYMIME object to two recipients using the
   CHUNKING and PIPELINING extensions:

   R: 
   R: 220 cnri.reston.va.us SMTP service ready
   S: EHLO ymir.claremont.edu
   R: 250-cnri.reston.va.us says hello
   R: 250-PIPELINING
   R: 250-BINARYMIME
   R: 250 CHUNKING
   S: MAIL FROM: BODY=BINARYMIME
   S: RCPT TO:
   S: RCPT TO:
   R: 250 ... Sender and BINARYMIME ok
   R: 250 ... Recipient ok
   R: 250 ... Recipient ok
   S: BDAT 100000
   S: (First 10000 octets of canonical MIME message data)

Notes:

You can see the last line is missing a 0.

RFC 3031, "Multiprotocol Label Switching Architecture", January 2001

Note: This RFC has been updated by RFC 6178, RFC 6790

Source of RFC: mpls (rtg)

Errata ID: 348
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Kristoff
Date Reported: 2005-03-01

Section 2.3 says:

   LDP                       Label Distribution Protocol
   L2                        Layer 2 L3                        Layer 3
   LSP                       Label Switched Path

It should say:

   LDP                       Label Distribution Protocol
   L2                        Layer 2 
   L3                        Layer 3
   LSP                       Label Switched Path

Notes:

there is a missing CR/LF

Errata ID: 696
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Kristoff
Date Reported: 2005-03-01

Section 3.20 says:

For example, a set of distinct address prefixes might all have the same
egress node, and label swapping might be used only to get the the traffic 
to the egress node. 

It should say:

For example, a set of distinct address prefixes might all have the same
egress node, and label swapping might be used only to get the traffic 
to the egress node. 

Notes:

Notice the double 'the'.

Errata ID: 1893
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dande Rajasekhar
Date Reported: 2009-09-24
Verifier Name: Ross Callon
Date Verified: 2009-09-29

Section 4.1.6 says:

It is important to note that if Ru and Rd are adjacent LSRs in an LSP
   for X1 and X2, forwarding will still be done correctly if Ru assigns
   distinct labels to X1 and X2 while Rd assigns just one label to the
   both of them.  This just means that R1 will map different incoming
   labels to the same outgoing label, an ordinary occurrence.

It should say:

It is important to note that if Ru and Rd are adjacent LSRs in an LSP
   for X1 and X2, forwarding will still be done correctly if Ru assigns
   distinct labels to X1 and X2 while Rd assigns just one label to the
   both of them.  This just means that Rd will map different incoming
   labels to the same outgoing label, an ordinary occurrence.

Notes:

R1 should be replaced by Rd since there is no reference for R1.

Errata ID: 2782
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Valeria Elisabetta Mattavelli
Date Reported: 2011-04-18
Verifier Name: Adrian Farrel
Date Verified: 2011-04-18

Section 2.2 says:

 layer 3                   the protocol layer at which IP and its
                           associated routing protocols operate
                           link layer synonymous with layer 2

It should say:

 layer 3                   the protocol layer at which IP and its
                           associated routing protocols operate
 
 link layer                synonymous with layer 2

Notes:

Wrong text indentation

Errata ID: 5002
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eric Gray
Date Reported: 2017-04-21
Verifier Name: RFC Editor
Date Verified: 2017-06-12

Section 3.8 says:

   Liberal label retention mode allows for quicker adaptation to routing
   changes, but conservative label retention mode though requires an LSR
   to maintain many fewer labels.

It should say:

   Liberal label retention mode allows for quicker adaptation to routing
   changes, while conservative label retention mode requires an LSR to
   maintain many fewer labels.

Notes:

Grammar error in original text, which may make it harder for some to read and understand.
Verifier Notes: (removed the spurious "though")

Errata ID: 7841
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christophe Deleuze
Date Reported: 2024-03-07
Verifier Name: RFC Editor
Date Verified: 2024-03-08

Section 2.2 says:

      label switched path       The path through one or more LSRs at one
                                level of the hierarchy followed by a
                                packets in a particular FEC.

It should say:

      label switched path       The path through one or more LSRs at one
                                level of the hierarchy followed by packets
                                in a particular FEC.

Notes:

s/a packets/packets/

Errata ID: 7842
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christophe Deleuze
Date Reported: 2024-03-07
Verifier Name: RFC Editor
Date Verified: 2024-03-08

Section 2.2 says:

      MPLS edge node            an MPLS node that connects an MPLS
                                domain with a node which is outside of
                                the domain, either because it does not
                                run MPLS, and/or because it is in a
                                different domain.  Note that if an LSR
                                has a neighboring host which is not
                                running MPLS, that that LSR is an MPLS
                                edge node.

It should say:

      MPLS edge node            an MPLS node that connects an MPLS
                                domain with a node which is outside of
                                the domain, either because it does not
                                run MPLS, and/or because it is in a
                                different domain.  Note that if an LSR
                                has a neighboring host which is not
                                running MPLS, then that LSR is an MPLS
                                edge node.

Notes:

s/that that/then that/

Errata ID: 7843
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christophe Deleuze
Date Reported: 2024-03-07
Verifier Name: RFC Editor
Date Verified: 2024-03-08

Section 2.2 says:

      VP merge                  label merging where the MPLS label is
                                carried din the ATM VPI field, so as to

It should say:

      VP merge                  label merging where the MPLS label is
                                carried in the ATM VPI field, so as to

Notes:

s/din/in/

RFC 3032, "MPLS Label Stack Encoding", January 2001

Note: This RFC has been updated by RFC 3443, RFC 4182, RFC 5332, RFC 3270, RFC 5129, RFC 5462, RFC 5586, RFC 7274, RFC 9017

Source of RFC: mpls (rtg)

Errata ID: 347
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mario Zoppetti
Date Reported: 2006-01-25

Section 3.4.4 says:

C. If possible, transmit the ICMP Destination Unreachable 
    Message to the source of the of the discarded datagram. 

It should say:

C. If possible, transmit the ICMP Destination Unreachable 
    Message to the source of the discarded datagram. 

Notes:

As you can see, the text "of the" on the second line is
repeated twice.

Errata ID: 982
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stephane Bortzmeyer
Date Reported: 2007-05-18
Verifier Name: Adrian Farrel
Date Verified: 2011-01-28

Section 2.3.2 says:

      Since an ICMP message is never sent as a result of receiving an ICMP
      message,

It should say:

      Since an ICMP message is never sent as a result of receiving an ICMP
      error message,

Notes:

As explained in RFC 1122 section 3.2.2 :

An ICMP error message MUST NOT be sent as the result of
receiving:

* an ICMP error message, or

Clearly, ICMP messages *are* sent in responce to other ICMP messages. For example, during ping processing an ICMP echo-reply message is generated as
the result of an echo-request message.

Errata ID: 2166
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2010-04-21
Verifier Name: Adrian Farrel
Date Verified: 2010-08-19

Section 4.2 says:

      2. Data Link Layer Protocol Field

         Exactly one MPLSCP packet is encapsulated in the PPP
         Information field, where the PPP Protocol field indicates type
         hex 8281 (MPLS).

It should say:

      2. Data Link Layer Protocol Field

         Exactly one MPLSCP packet is encapsulated in the PPP
         Information field, where the PPP Protocol field indicates type
         hex 8281 (MPLSCP).

RFC 3036, "LDP Specification", January 2001

Note: This RFC has been obsoleted by RFC 5036

Source of RFC: mpls (rtg)

Errata ID: 346
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Elena Taguer
Date Reported: 2001-02-01

Section 3.5.1.2.2 says:

   If the TLV type is >= 0x8000 (high order bit 1) the TLV is
   silently dropped.  Section "Unknown TLV in Known Message Type"
   elaborates on this behavior.

Notes:

There is no section with this title. The sentence in question should
have been deleted. It refers to a section that was deleted in a
version of the I-D that led to the RFC.

RFC 3037, "LDP Applicability", January 2001

Source of RFC: mpls (rtg)

Errata ID: 344
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Elena Taguer
Date Reported: 2001-01-29

Section 1 says:

   LDP is also useful in situations that require efficient hop-by-hop
   routed tunnels, such as MPLS-based VPN architectures [RFC2574] and
   tunneling between BGP border routers.  

It should say:

   LDP is also useful in situations that require efficient hop-by-hop
   routed tunnels, such as MPLS-based VPN architectures [RFC2547] and
   tunneling between BGP border routers.

RFC 3047, "RTP Payload Format for ITU-T Recommendation G.722.1", January 2001

Note: This RFC has been obsoleted by RFC 5577

Source of RFC: avt (rai)

Errata ID: 343
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Colin Perkins
Date Reported: 2002-06-04

Section 4 says:

   Encoding considerations:
         This type is only defined for transfer via RTP as specified
	 in a Work in Progress.

It should say:

   Encoding considerations:
         This type is only defined for transfer via RTP as specified
	 in RFC 3047.

RFC 3052, "Service Management Architectures Issues and Review", January 2001

Source of RFC: Legacy

Errata ID: 342

Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sid Nag
Date Reported: 2002-11-20
Report Text:

In Section 7, Sid Nag has reverted back to his original EMail address: 

   thinker@monmouth.com

---

RFC 3056, "Connection of IPv6 Domains via IPv4 Clouds", February 2001

Source of RFC: ngtrans (ops)

Errata ID: 341
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Brian Carpenter
Date Reported: 2002-11-20

Section 5.3 says:

then
apply any security checks (see Section 8);

It should say:

then
apply any security checks (see Section 9);

Errata ID: 697
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Brian Carpenter
Date Reported: 2002-11-20

Section 5.3 says:

apply any security checks (see Section 8);

It should say:

apply any security checks (see Section 9);

Notes:

RFC 3061, "A URN Namespace of Object Identifiers", February 2001

Source of RFC: INDEPENDENT

Errata ID: 1751
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Klensin
Date Reported: 2009-04-02
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-18

Section 1 says:

   o  0.9.2342.19200300.100.4 - Object ID's used in the directory pilot
      project to identify X.500 Object Classes.  Mostly defined in RFC
      1274.

   This document specifies the "oid" URN namespace [2].  This namespace
   is for encoding an Object Identifier as specified in ASN.1 [3] as a
   URI.  RFC 3001 [1] is obsoleted by this specification.

   The namespace specification is for a formal namespace.

It should say:

   o  0.9.2342.19200300.100.4 - Object ID's used in the directory pilot
      project to identify X.500 Object Classes.  Mostly defined in RFC
      1274.  RFC 1274 is now obsolete.  The usage description of these 
      identifiers now appears in RFC 4524 and the relevant registry is 
      defined in RFC 4520.

   This document specifies the "oid" URN namespace [2].  This namespace
   is for encoding an Object Identifier as specified in ASN.1 [3] as a
   URI.  RFC 3001 [1] is obsoleted by this specification.

   The namespace specification is for a formal namespace.

   A complete database of OIDs appears at http://www.oid-info.com/

Notes:

This suggested change is not substantive and makes no change to the spec itself. Instead, it supplies some additional, up-to-date, information that might be helpful to the reader and is intended to act as a placeholder to record that information for any future revision or update to 3061.

Note to RFC Editor: the source for this document is listed as "legacy", perhaps because it was published as Informational. However, it is the definition source for a Formal URN Namespace and those namespaces require IETF consensus action (see http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml), so the erratum should probably be processed as if it were a standards-track document.

RFC 3062, "LDAP Password Modify Extended Operation", February 2001

Source of RFC: Legacy
Area Assignment: app

Errata ID: 340
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kurt Zeilenga
Date Reported: 2001-03-07

Section 1 says:

   Traditionally, LDAP users where identified by the Distinguished Name
   [RFC2253] of a directory entry and this entry contained a userPassword
   [RFC2256] attribute containing one or more passwords.

It should say:

   Traditionally, LDAP users were identified by the Distinguished
   Name [RFC2253] of a directory entry and this entry contained a
   userPassword [RFC2256] attribute containing one or more passwords.

RFC 3066, "Tags for the Identification of Languages", January 2001

Note: This RFC has been obsoleted by RFC 4646, RFC 4647

Source of RFC: Legacy

Errata ID: 336
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: David Hopwood
Date Reported: 2002-07-30

Section 2.3 says:

   This will ensure that, for example, a user who implements "hwi"
   (Hawaiian), which currently has no 2-letter code, will not find his
   or her data invalidated by eventual addition of a 2-letter code for
   that language.

It should say:

   This will ensure that, for example, a user who implements "haw"
   (Hawaiian), which currently has no 2-letter code, will not find his
   or her data invalidated by eventual addition of a 2-letter code for
   that language.

Errata ID: 337
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Dr. Carsten Bormann
Date Reported: 2001-02-01

Section 2.2 says:

   URL: http://www.loc.gov/standards/iso639

It should say:

   http://www.loc.gov/standards/iso639-2/

RFC 3069, "VLAN Aggregation for Efficient IP Address Allocation", February 2001

Source of RFC: Legacy

Errata ID: 335
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bob Braden
Date Reported: 2007-06-06

Section 1 says:

customer C and resides in it's own virtual LAN, VLAN C.

It should say:

customer C and resides in its own virtual LAN, VLAN C.

Notes:

Notes/ Ooops. Ouch!

RFC 3080, "The Blocks Extensible Exchange Protocol Core", March 2001

Source of RFC: beep (app)

Errata ID: 992
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ozz Nixon
Date Reported: 2007-06-13
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-06

Section 2.2.1.1 says:

   The answer number ("ansno") must be a non-negative integer (in the
   range 0..4294967295) and must have a different value than all other
   answers in progress for the message being replied to.

It should say:

   The answer number ("ansno") must be a non-negative integer (in the
   range 0..2147483647) and must have a different value than all other
   answers in progress for the message being replied to.

Notes:

Page 8 says:

channel = 0..2147483647
msgno = 0..2147483647
more = "." / "*"
seqno = 0..4294967295
size = 0..2147483647
ansno = 0..2147483647

If page 8 is correct, page then 9 needs to be changed to suggested text above.

from pending

RFC 3083, "Baseline Privacy Interface Management Information Base for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems", March 2001

Note: This RFC has been updated by RFC 9141

Source of RFC: ipcdn (ops)

Errata ID: 334
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Rich Woundy
Date Reported: 2001-04-10

Section 4 says:

   docsBpiCmAuthState      OBJECT-TYPE
   SYNTAX                  INTEGER {
    
                                   authWait(2),
                                   authorized(3),
                                   reauthWait(4),
                                   authRejectWait(5)

It should say:

   docsBpiCmAuthState      OBJECT-TYPE
   SYNTAX                  INTEGER {

                                   start(1),
                                   authWait(2),
                                   authorized(3),
                                   reauthWait(4),
                                   authRejectWait(5)

Notes:

2014-07-14: comma added. Thanks to Mark Ellison for the correction.

RFC 3092, "Etymology of "Foo"", April 2001

Source of RFC: INDEPENDENT

Errata ID: 1454
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Frank Ellermann
Date Reported: 2008-06-15
Verifier Name: Nevil Brownlee
Date Verified: 2010-04-03

Section Appendix says:

   | 2818 |  X  |  X  |         |       | 190 |
   | 2828 |     |  X  |    X    |       | 191 |
   | 2830 |  X  |     |         |       | 192 |
   | 2831 |  X  |  X  |    X    |       | 193 |
   | 2839 |     |  X  |         |       | 194 |
   | 2846 |  X  |  X  |         |       | 195 |
   | 2853 |     |  X  |         |       | 196 |
   | 2863 |     |  X  |         |       | 197 |
   | 2910 |     |  X  |    X    |       | 198 |
   | 2912 |     |  X  |    X    |       | 199 |
   | 2915 |     |  X  |         |       | 200 |
   | 2926 |     |     |    X    |       | 201 |
   | 2942 |     |  X  |         |       | 202 |
   | 2965 |     |  X  |         |       | 203 |
   | 2967 |  X  |  X  |    X    |       | 204 |
   | 2970 |     |  X  |         |       | 205 |
   | 2993 |  X  |  X  |         |       | 206 |
   | 3010 |  X  |  X  |         |       | 207 |
   | 3023 |     |  X  |         |       | 208 |
   | 3028 |     |  X  |         |       | 209 |
   | 3075 |  X  |  X  |         |       | 210 |
   | 3080 |     |  X  |         |       | 211 |
   | 3092 |  X  |  X  |    X    |   X   | 212 |
   +------+-----+-----+---------+-------+-----+
   | RFC# | bar | foo | foo.bar | fubar |  #  |

It should say:

   | 2818 |  X  |  X  |         |       | 190 |
   | 2821 |  X  |  X  |         |       | 191 |
   | 2828 |     |  X  |    X    |       | 192 |
   | 2830 |  X  |     |         |       | 193 |
   | 2831 |  X  |  X  |    X    |       | 194 |
   | 2839 |     |  X  |         |       | 195 |
   | 2846 |  X  |  X  |         |       | 196 |
   | 2853 |     |  X  |         |       | 197 |
   | 2863 |     |  X  |         |       | 198 |
   | 2910 |     |  X  |    X    |       | 199 |
   | 2912 |     |  X  |    X    |       | 200 |
   | 2915 |     |  X  |         |       | 201 |
   | 2926 |     |     |    X    |       | 202 |
   | 2942 |     |  X  |         |       | 203 |
   | 2965 |     |  X  |         |       | 204 |
   | 2967 |  X  |  X  |    X    |       | 205 |
   | 2970 |     |  X  |         |       | 206 |
   | 2993 |  X  |  X  |         |       | 207 |
   | 3010 |  X  |  X  |         |       | 208 |
   | 3023 |     |  X  |         |       | 209 |
   | 3028 |     |  X  |         |       | 210 |
   | 3075 |  X  |  X  |         |       | 211 |
   | 3080 |     |  X  |         |       | 212 |
   | 3092 |  X  |  X  |    X    |   X   | 213 |
   +------+-----+-----+---------+-------+-----+
   | RFC# | bar | foo | foo.bar | fubar |  #  |

Notes:

RFC 2821 contains foo.com (34 occurences), bar.com (18 occurences),
bar.org (5 occurences), foo.org (4 occurences), and one foo-u.edu.

RFC 3104, "RSIP Support for End-to-end IPsec", October 2001

Source of RFC: nat (tsv)

Errata ID: 333
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Matt Holdrege
Date Reported: 2004-03-13

In the References section, "Holdrege" is spelled incorrectly. It says:

   [NAT-TERMS] Srisuresh, P. and M. Holdredge, "IP Network Address
               Translator (NAT) Terminology and Considerations", RFC
               2663, August 1999.

It should say:

   [NAT-TERMS] Srisuresh, P. and M. Holdrege, "IP Network Address
               Translator (NAT) Terminology and Considerations", RFC
               2663, August 1999.

Notes:

RFC 3107, "Carrying Label Information in BGP-4", May 2001

Note: This RFC has been obsoleted by RFC 8277

Note: This RFC has been updated by RFC 6790

Source of RFC: mpls (rtg)

Errata ID: 4497
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexander Okonnikov
Date Reported: 2015-10-13
Verifier Name: Deborah Brungard
Date Verified: 2015-12-30

Section 2 says:

Label distribution can be piggybacked in the BGP Update message by
   using the BGP-4 Multiprotocol Extensions attribute [RFC 2283].

It should say:

Label distribution can be piggybacked in the BGP Update message by
   using the BGP-4 Multiprotocol Extensions attribute
defined in RFC 2858 [BGP-MP].

Notes:

No reference [RFC 2283] in Reference section of RFC 3107. The reference is called [BGP-MP].

Errata ID: 4498
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexander Okonnikov
Date Reported: 2015-10-13
Verifier Name: Deborah Brungard
Date Verified: 2016-02-11

Section 3 says:

   The label(s) specified for a particular route (and associated with
   its address prefix) must be assigned by the LSR which is identified
   by the value of the Next Hop attribute of the route.

   When a BGP speaker redistributes a route, the label(s) assigned to
   that route must not be changed (except by omission), unless the
   speaker changes the value of the Next Hop attribute of the route.

It should say:

   The label(s) specified for a particular route (and associated with
   its address prefix) must be assigned by the LSR which is identified
   by the value of the Network Address of Next Hop field of
   MP_REACH_NLRI attribute of the route.

   When a BGP speaker redistributes a route, the label(s) assigned to
   that route must not be changed (except by omission), unless the
   speaker changes the value of the Network Address of Next Hop field of
   MP_REACH_NLRI attribute of the route.

Notes:

Next Hop address for labeled routes is conveyed within MP_REACH_NLRI attribute.

RFC 3108, "Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections", May 2001

Source of RFC: mmusic (rai)

Errata ID: 332
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Rajesh Kumar
Date Reported: 2002-05-22

Section 5.6 says:

   The base specification for SDP, RFC 2327 [1], allows the definition f
   new attributes.  In keeping with this spirit, some of the attributes
   defined in this document can also be used in SDP descriptions of IP
   nd other non-ATM sessions.  For example, the 'vsel', 'dsel' and
   'fsel' attributes defined below refer generically to codec-s.  These
   can be bed for service-specific codec negotiation and assignment in
   non-ATM s well as ATM applications.

It should say:

   The base specification for SDP, RFC 2327 [1], allows the definition of
   new attributes.  In keeping with this spirit, some of the attributes
   defined in this document can also be used in SDP descriptions of IP
   and other non-ATM sessions.  For example, the 'vsel', 'dsel' and
   'fsel' attributes defined below refer generically to codecs.  These
   can be used for service-specific codec negotiation and assignment in
   non-ATM as well as ATM applications.

Notes:

In Section 5.6.3: (First, Second and Third Bulleted items in List)
* The 'silenceSupp' attribute, used to indicate the use of of
voice activity detection for silence suppression, and to
optionally parameterize the silence suppression function.

* The 'ecan' attribute, used to indicate the use of of echo
cancellation, and to parameterize the this function.

* The 'gc' attribute, used to indicate the use of of gain
control, and to parameterize the this function.
Should be:
* The 'silenceSupp' attribute, used to indicate the use of
voice activity detection for silence suppression, and to
optionally parameterize the silence suppression function.

* The 'ecan' attribute, used to indicate the use of echo
cancellation, and to parameterize the this function.

* The 'gc' attribute, used to indicate the use of gain
control, and to parameterize the this function.
In Section 5.6.3.3:
When present, the 'ecan' attribute s is used to indicate the use or
non-use of echo cancellation. There can be several 'ecan' lines in
an SDP description.
Should be:
When present, the 'ecan' attribute is used to indicate the use or
non-use of echo cancellation. There can be several 'ecan' lines in
an SDP description.
In Section 5.6.6: (First numbered item)
(1) The originating media gateway controller (OMGC) initiates
service-level call establishment by sending the appropriate
controlsmessage to the originating media gateway (OMG).
Should be:
(1) The originating media gateway controller (OMGC) initiates
service-level call establishment by sending the appropriate
control message to the originating media gateway (OMG).
In Section 6: (Sixth definition from top)
<vci> Virtual Circui t Decimal or hex equivalent
Identifier of 16 bits
Should be:
<vci> Virtual Circuit Decimal or hex equivalent
Identifier of 16 bits

RFC 3110, "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)", May 2001

Note: This RFC has been updated by RFC 6944

Source of RFC: dnsext (int)

Errata ID: 2811
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: George Barwood
Date Reported: 2011-05-21
Verifier Name: Brian Haberman
Date Verified: 2012-05-01

Section 3 says:

Leading zero bytes are permitted in the RSA/SHA1 algorithm signature.

It should say:

Leading zero bytes MUST be added to the RSA/SHA1 algorithm signature 
so that the signature size in bytes is equal to the size of n in bytes.

Notes:

The Original Text implies that zero-padding of RSA signaturs is optional, however the underlying standard requires zero padding, http://tools.ietf.org/html/rfc2437#section-8.1.1

"4. Convert the signature representative s to a signature S of length k octets: S = I2OSP (s, k)"

where k is the length of the modulus in bytes. If the extra bytes are not added, standard RSA libraries will fail to verify the signature about 1% of the time when the padding occurs.

Errata ID: 4502
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mikko Rantanen
Date Reported: 2015-10-14
Verifier Name: Brian Haberman
Date Verified: 2015-10-14

Section 4 says:

conservative choice would be 65537 (F4, the fourth fermat number).

It should say:

conservative choice would be 65537 (F4, the fifth Fermat number).

Notes:

Numbering of Fermat numbers starts from zero. F4 and 65537 agree, but F4 is fifth Fermat number in the series, not fourth.

RFC 3118, "Authentication for DHCP Messages", June 2001

Source of RFC: dhc (int)

Errata ID: 3474
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Chris Lonvick
Date Reported: 2013-02-02
Verifier Name: Ralph Droms
Date Verified: 2013-03-09

Section 2 says:

   If the RDM field contains 0x00, the replay detection field MUST be
   set to the value of a monotonically increasing counter.  Using a
   counter value such as the current time of day (e.g., an NTP-format
   timestamp [4]) can reduce the danger of replay attacks.  This method
   MUST be supported by all protocols.

It should say:

   If the RDM field contains 0x00, the replay detection field MUST be
   set to the value of a strictly increasing counter.  Using a
   counter value such as the time since the epoch (e.g., an NTP-format
   timestamp [4]) can reduce the danger of replay attacks.  This method
   MUST be supported by all protocols.

Notes:

The term "monotonically increasing" does not actually mean what the authors and editors hope it means. :-) An example of a monotonically increasing sequence is:
1, 2, 2, 2, 2, 2, 2...

Strictly following that definition in the current section 2 would allow replays of captured packets. Changing the term to "strictly increasing" requires that subsequent values are greater than previous values. This would mean that a captured packet replayed with the same Authentication Information value would not meet the criteria described in my proposed corrected text, and should consequently be detected as a replay attack by a recipient.

The term monotonically increasing is also used at the end of Section 6 and should also be replaced with strictly increasing.

Also, the use of the term "time of day" could be problematic. If the first packet were sent just before midnight, and the second sent just after midnight, then the value of the second would be much lower than the value of the first. To align with the NTP example, I'm suggesting a change in text to be something that is actually increasing.

RFC 3119, "A More Loss-Tolerant RTP Payload Format for MP3 Audio", June 2001

Note: This RFC has been obsoleted by RFC 5219

Source of RFC: avt (rai)

Errata ID: 331
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ross Finlayson
Date Reported: 2001-11-03

Section 8 says:

   the encoding name SHALL be "mp3" (the same as the MIME subtype).

It should say:

   the encoding name SHALL be "mpa-robust" (the same as the MIME
   subtype). 

Notes:

Appendix A:
"backpointer": the size (in bytes) of the backpointer for this
frame
Should be:
"backpointer": the value (expressed in bytes) of the backpointer for
this frame
Appendix A2:
In the function "insertDummyADUsIfNecessary()":
curADU
Should be:
prevADU
Appendix B2:
The two occurrences of "32" should be "256"

RFC 3122, "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification", June 2001

Source of RFC: ipngwg (int)

Errata ID: 3696
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Arnold Plankl
Date Reported: 2013-08-14
Verifier Name: Brian Haberman
Date Verified: 2013-09-10

Section 2.2 says:

The sender node MUST send the following options in the Advertisement
   message:

   Source Link-Layer Address The link-layer address of the sender.

      Target Link-Layer Address
         The link-layer address of the target, that is, the sender of
         the advertisement.

It should say:

The sender node MUST send the following options in the Advertisement
message:

   Source Link-Layer Address
      The link-layer address of the node transmitting the
      Advertisement message

   Target Link-Layer Address
      The link-layer address of the node that transmitted the
      Solicitation message

Notes:

There is an ambiguity with the Source Link-Layer and Target Link-Layer Address option in the Inverse Neighbor Discovery Advertisement Message. It is unclear if SLLA is set to sender of the Advertisement or of the Solicitation, the same with TLLA. The RFC-text as it is would lead to SLL=TLL=sender of advertisement.

Here is an example for clarification of the problem (with 2 Ethernet-nodes, no FR):
Eth Node A - Eth Node B:
1. A sends IND S with SLLA=A, TLLA=B
2. B takes the address pair from SLLA and source-IP in ND cache
3. B answers with IND A with TAL(identified by TLLA in solicitation), SLLA=B,TLLA=B <- problem is here (SLLA=TLLA=B). Is that acceptable?
Or modify to: SLLA=A or TLLA=A? Or omit TLLA?
4. A takes the address pair from SLLA and the TAL in ND cache

Solution 1: B answers with IND A with TAL, SLLA=B, and TLLA=A => Then carries TLLA the address of the requesting node (is that acceptable as “target” address?)

Solution 2: B answers with IND A with TAL, SLLA=A, and TLLA=B => Then A could not take the address pair from SLLA and the TAL in ND cache.

RFC 3124, "The Congestion Manager", June 2001

Source of RFC: ecm (tsv)

Errata ID: 7818
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2024-02-21
Verifier Name: Martin Duke
Date Verified: 2024-03-05

Section 3.3 says:

             The nrecd parameter indicates how many bytes were
   successfully received by the receiver since the last cm_update call,
   while the nrecd parameter identifies how many bytes were received
   were lost during the same time period.  

It should say:

             The nrecd parameter indicates how many bytes were
   successfully received by the receiver since the last cm_update call,
   while the nlost parameter identifies how many bytes were lost during the same time period.  

Notes:

Wrong nrecd parameter instead of nlost at the beginning of page 10.

RFC 3125, "Electronic Signature Policies", September 2001

Source of RFC: smime (sec)

Errata ID: 5901
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2019-11-12
Verifier Name: Roman Danyliw
Date Verified: 2022-01-20

Section Appendix A.1 says:

CommitmentType ::= SEQUENCE {
        identifier                      CommitmentTypeIdentifier,
        fieldOfApplication      [0] FieldOfApplication OPTIONAL,
        semantics                       [1] DirectoryString OPTIONAL }

It should say:

CommitmentType ::= SEQUENCE {
        identifier                      CommitmentTypeIdentifier,
        fieldOfApplication      [0] FieldOfApplication OPTIONAL,
        semantics                       [1] DirectoryString OPTIONAL }

CommitmentTypeIdentifier ::= OBJECT IDENTIFIER

Notes:

The definition of CommitmentTypeIdentifier is missing from the ASN.1 module. RFC 3126 shows that it is an object identifier.

Errata ID: 5902
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2019-11-12
Verifier Name: Roman Danyliw
Date Verified: 2022-01-20

Section Appendix A.2 says:

CommitmentType ::= SEQUENCE {
        identifier                      CommitmentTypeIdentifier,
        fieldOfApplication      [0] FieldOfApplication OPTIONAL,
        semantics               [1] DirectoryString OPTIONAL }

It should say:

CommitmentType ::= SEQUENCE {
        identifier                      CommitmentTypeIdentifier,
        fieldOfApplication      [0] FieldOfApplication OPTIONAL,
        semantics               [1] DirectoryString OPTIONAL }

CommitmentTypeIdentifier ::= OBJECT IDENTIFIER

Notes:

The CommitmentTypeIdentifier definition is missing from the ASN.1 module. RFC 3126 shows that it is an object identifier.

RFC 3126, "Electronic Signature Formats for long term electronic signatures", September 2001

Note: This RFC has been obsoleted by RFC 5126

Source of RFC: smime (sec)

Errata ID: 1067
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Petra Barzin
Date Reported: 2003-02-13
Verifier Name: Russ Housley
Date Verified: 2003-02-17

Section 4.3.2 says:

   RevocationValues ::=  SEQUENCE {
      crlVals           [0] SEQUENCE OF CertificateList     OPTIONAL,
      ocspVals          [1] SEQUENCE OF BasicOCSPResponse   OPTIONAL,
      otherRevVals      [2] OtherRevVals
   }

It should say:

  RevocationValues ::=  SEQUENCE {
     crlVals           [0] SEQUENCE OF CertificateList     OPTIONAL,
     ocspVals          [1] SEQUENCE OF BasicOCSPResponse   OPTIONAL,
     otherRevVals      [2] OtherRevVals                    OPTIONAL
     }

Notes:

"OPTIONAL" is present in ETSI TS 101 733 V1.4.0

RFC 3161, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", August 2001

Note: This RFC has been updated by RFC 5816

Source of RFC: pkix (sec)

Errata ID: 1879
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nick Pope
Date Reported: 2009-09-15
Verifier Name: Tim Polk
Date Verified: 2010-04-19

Section 3.6 says:

Upon receiving a valid request, the server MUST respond with either a valid response with content type application/timestamp-response or with an HTTP error.
 

It should say:

Upon receiving a valid request, the server MUST respond with either a valid response with content type application/timestamp-reply or with an HTTP error.

Notes:

"application/timestamp-reply" are used in the rest parts of RFC 3161 (4 occurencies). Furthermore, known existing implementations are using
"application/timestamp-reply".

Errata ID: 2931
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Benjamin Dauvergne
Date Reported: 2011-08-12
Verifier Name: Sean Turner
Date Verified: 2011-11-12

Section 2.4.2 says:

   PKIStatus ::= INTEGER {
      granted                (0),
      -- when the PKIStatus contains the value zero a TimeStampToken, as
         requested, is present.
      grantedWithMods        (1),
       -- when the PKIStatus contains the value one a TimeStampToken,
         with modifications, is present.
      rejection              (2),
      waiting                (3),
      revocationWarning      (4),

       -- this message contains a warning that a revocation is
       -- imminent
      revocationNotification (5)
       -- notification that a revocation has occurred  }

It should say:

   PKIStatus ::= INTEGER {
      granted                (0),
      -- when the PKIStatus contains the value zero a TimeStampToken, as
      -- requested, is present.
      grantedWithMods        (1),
      -- when the PKIStatus contains the value one a TimeStampToken,
      -- with modifications, is present.
      rejection              (2),
      waiting                (3),
      revocationWarning      (4),

       -- this message contains a warning that a revocation is
       -- imminent
      revocationNotification (5)
       -- notification that a revocation has occurred -- }

Notes:

In ASN.1 syntax 1988, all comment lines must be prefixed with double-hyphen, and comment lines followed by some content must be terminated with a double-hyphen.

Errata ID: 2932
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Benjamin Dauvergne
Date Reported: 2011-08-12
Verifier Name: Sean Turner
Date Verified: 2011-11-12

Section 2.4.2 says:

    systemFailure       (25)
      -- the request cannot be handled due to system failure  }

It should say:

    systemFailure       (25)
      -- the request cannot be handled due to system failure -- }

Notes:

In ASN.1 syntax 1988, comment lines followed by content must be terminated by a double-hyphen.

RFC 3165, "Definitions of Managed Objects for the Delegation of Management Scripts", August 2001

Source of RFC: disman (ops)

Errata ID: 330
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Juergen Schoenwaelder
Date Reported: 2001-09-03

Section 6 says:

       SYNTAX      Integer32 (1..2147483647)

It should say:

       SYNTAX      Integer32 (0..2147483647)

RFC 3168, "The Addition of Explicit Congestion Notification (ECN) to IP", September 2001

Note: This RFC has been updated by RFC 4301, RFC 6040, RFC 8311

Source of RFC: tsvwg (wit)

Errata ID: 3639
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Richard Scheffenegger
Date Reported: 2013-06-05
Verifier Name: Martin Stiemerling
Date Verified: 2015-04-17

Section 6.1 / 6.1.3 says:

Section 6.1 says:


      * The receiver receives the packet with the CE codepoint set, and
        sets the ECN-Echo flag in its next TCP ACK sent to the sender.
[...]

      * The sender sets the CWR flag in the TCP header of the next
        packet sent to the receiver to acknowledge its receipt of and
        reaction to the ECN-Echo flag.

Section 6.1.3 says:


   When TCP receives a CE data packet at the destination end-system, the
   TCP data receiver sets the ECN-Echo flag in the TCP header of the
   subsequent ACK packet. 

   [...]
                                               The TCP receiver uses the
   CWR flag received from the TCP sender to determine when to stop
   setting the ECN-Echo flag.
   

It should say:

Section 6.1.3 should say:
 
   The TCP receiver uses the
   CWR flag received from the TCP sender to determine when to stop
   setting the ECN-Echo flag. This check has to be performed before  
   checking if the received segment is CE marked.

Notes:

The ordering of the text in the bullet points in section 6.1, and the text in section 6.1.3 can led to inappropriate implementations. At least Section 6.1.3 should be strict about the handling of CE-marked CWR-segments.


If CE is checked first, and ECE set, and thereafter CWR used to disable ECE, a CE-marked CWR segment will not result in the sending of an additional window of ECEs.


All derivatives of BSD used to

First, set ECE because of CE
Second, reset ECE because of CWR

However, the "authorative" NS2 sample code, the TBIT tool, Windows, Solaris and Linux would

First, reset ECE because of CWR
Second, set ECE because of CE

The latter approach seems to be the sensible one, and it was quickly fixed:

http://lists.freebsd.org/pipermail/freebsd-bugs/2010-April/039450.html

Errata ID: 2307
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2010-06-21
Verifier Name: Lars Eggert
Date Verified: 2010-06-29

Section 6.1 says:

   This proposal specifies two new flags in the Reserved field of the
   TCP header.  The TCP mechanism for negotiating ECN-Capability uses
   the ECN-Echo (ECE) flag in the TCP header.  Bit 9 in the Reserved
   field of the TCP header is designated as the ECN-Echo flag.  The
   location of the 6-bit Reserved field in the TCP header is shown in
   Figure 4 of RFC 793 [RFC793] (and is reproduced below for
   completeness).  This specification of the ECN Field leaves the
   Reserved field as a 4-bit field using bits 4-7.

It should say:

   This proposal specifies two new flags in the Reserved field of the
   TCP header.  The TCP mechanism for negotiating ECN-Capability uses
   the ECN-Echo (ECE) flag in the TCP header.  Bit 9 in the Reserved
   field of the TCP header is designated as the ECN-Echo flag.  The
   location of the 6-bit Reserved field in the TCP header is shown in
   Figure 3 of RFC 793 [RFC793] (and is reproduced below for
   completeness).  This specification of the ECN Field leaves the
   Reserved field as a 4-bit field using bits 4-7.

Notes:

Incorrect reference to Figure 4 of RFC 793

Errata ID: 2660
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bob Briscoe
Date Reported: 2010-12-04
Verifier Name: Lars Eggert
Date Verified: 2011-02-03

Section header block says:

Updates: 2474, 2401, 793

It should say:

Updates: 2474, 2401, 2003, 793

Notes:

RFC 3168 updates RFC 2003 but does not indicate this in its header block.

Specifically, Section 9 of RFC 3168 defines processing of the ECN field for Encapsulated Packets. This updates RFC 2003, which specified "IP Encapsulation within IP" at a time before the ECN field was defined.

Errata ID: 5966
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Richard Scheffenegger
Date Reported: 2020-01-26
Verifier Name: Martin Duke
Date Verified: 2020-04-20

Section 6.1 says:

Section 6.1 states:

      * The sender sets the CWR flag in the TCP header of the next
        packet sent to the receiver to acknowledge its receipt of and
        reaction to the ECN-Echo flag.

section 6.1.2 clarifies:

   
   We ensure that the "Congestion Window Reduced" information is
   reliably delivered to the TCP receiver.  This comes about from the
   fact that if the new data packet carrying the CWR flag is dropped,
   then the TCP sender will have to again reduce its congestion window,
   and send another new data packet with the CWR flag set.  Thus, the
   CWR bit in the TCP header SHOULD NOT be set on retransmitted packets.

   When the TCP data sender is ready to set the CWR bit after reducing
   the congestion window, it SHOULD set the CWR bit only on the first
   new data packet that it transmits.

It should say:

Section 6.1 should say:


      * The sender sets the CWR flag in the TCP header of the next new 
        data packet sent to the receiver to acknowledge its receipt of and
        reaction to the ECN-Echo flag.
 

Notes:

Discrepancies in the above text lead to poorly interoperating implementations. In NetBSD (and derived implementationd), the "SHOULD set CWR on new data" was used liberal in setting CWR on the very next packet to be sent, regardless of type. While at the same time the Linux implementation performed very stingent tests on the receiver side, if the sender was complying with the "SHOULD" like a "MUST". In request-response session with frequently changing data direction, this leads to a collapse of the congestion window, as the *BSD side will continue to interpret the still latched ECE flag as an indication of another RTT of congestion.

== Reviewer note: The original report recommended a requirement that TCP receivers MUST process CWR on any packet, data or otherwise. While this would be helpful to interoperate implementations that are incorrect due to this erratum, it is a slight change in the intent of the document.

RFC 3171, "IANA Guidelines for IPv4 Multicast Address Assignments", August 2001

Note: This RFC has been obsoleted by RFC 5771

Source of RFC: mboned (ops)

Errata ID: 1794
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Simon Perreault
Date Reported: 2009-06-17
Verifier Name: Ron Bonica
Date Verified: 2009-10-06

Section 2 says:

   224.0.2.0   - 224.0.255.0                   AD-HOC Block

It should say:

   224.0.2.0   - 224.0.255.255                 AD-HOC Block

Notes:

Section 5 mentions the AD-HOC block as being 224.0.2.0/24 - 224.0.255.0/24, which fits with the corrected text.

Furthermore, IANA has already assigned 224.0.255.0 - 224.0.255.255 for an AD-HOC usage.

RFC 3174, "US Secure Hash Algorithm 1 (SHA1)", September 2001

Note: This RFC has been updated by RFC 4634, RFC 6234

Source of RFC: INDEPENDENT

Errata ID: 328
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Christian Staudenmayer
Date Reported: 2004-03-20

In the Reference Section, it says:

   [FIPS 180-1] "Secure Hash Standard", United States of American,
                National Institute of Science and Technology, Federal
                Information Processing Standard (FIPS) 180-1, April
                1993.

It should say:

   [FIPS 180-1] "Secure Hash Standard", United States of America,
                National Institute of Science and Technology, Federal
                Information Processing Standard (FIPS) 180-1, April
                1993.

Notes:

"United States of American" changed to "United States of America"

Errata ID: 329
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ben Davis
Date Reported: 2006-06-01
Verifier Name: Nevil Brownlee
Date Verified: 2010-04-03

Section 7.2 says:

    /*
     *  Initialize the first 16 words in the array W
     */
    for(t = 0; t < 16; t++)
    {
        W[t] = context->Message_Block[t * 4] << 24;
        W[t] |= context->Message_Block[t * 4 + 1] << 16;
        W[t] |= context->Message_Block[t * 4 + 2] << 8;
        W[t] |= context->Message_Block[t * 4 + 3];
    }

It should say:

    /*
     *  Initialize the first 16 words in the array W
     */
    for(t = 0; t < 16; t++)
    {
        W[t] = (uint32_t)(context->Message_Block[t * 4]) << 24;
        W[t] |= (uint32_t)(context->Message_Block[t * 4 + 1]) << 16;
        W[t] |= context->Message_Block[t * 4 + 2] << 8;
        W[t] |= context->Message_Block[t * 4 + 3];
    }

Notes:

Note that Message_Block is an array of "integers of >= 16 bits" as described in "sha1.h" but W[] is an array of unsigned 32-bit integers.

While this works fine in many compilers, some compilers (e.g. Dynamic C v9.25) processing the line:

W[t] = context->Message_Block[t * 4] << 24;

will take the 16 bit integer "context->Message_Block[t * 4]" and shift it left 24 bits, and then assign the resulting (still) 16 bit integer to the 32 bit integer W[t].

This will lead to a different (and undesired) result than the intended behavior of first promoting the 16 bit integer "context->Message_Block[t * 4]" to a 32 bit integer, and *then* shifting that 32 bit integer left 24 times, and storing the result in W[t].

The solution is to use an explicit cast. The last two lines of code in the for loop can remain as they are, as they will not suffer from the above problem and do not need the explicit cast.

RFC 3180, "GLOP Addressing in 233/8", September 2001

Source of RFC: mboned (ops)

Errata ID: 327
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Steve Mattson
Date Reported: 2001-10-22

Section 3 says:

   The IANA has allocated 223/8 as per RFC 2770 [RFC2770].

It should say:

   The IANA has allocated 233/8 as per RFC 2770 [RFC2770].

Errata ID: 5121
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dale Worley
Date Reported: 2017-09-24
Verifier Name: Warren Kumari
Date Verified: 2017-09-24

Section 1 says:

The IANA has allocated 223/8 as per RFC 2770 [RFC2770].

It should say:

The IANA has allocated 233/8 as per RFC 2770 [RFC2770].

RFC 3182, "Identity Representation for RSVP", October 2001

Source of RFC: rap (ops)

Errata ID: 2958
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Marco Molteni
Date Reported: 2011-09-07
Verifier Name: ron bonica
Date Verified: 2011-09-09

Section 6.3 says:

6.3 Authentication (Router/PDP)

[..]

   2. Verify user credential

[..]

      -  Kerberos: Send the Kerberos ticket to the KDC to obtain the
         session key.  Using the session key authenticate the user.

It should say:

Kerberos: Extract the session key from the ticket. Use the session key to authenticate the user.

Notes:

The corrected text is only an example. The most important point is that Kerberos doesn't require the server to contact the KDC, all the information is already in the kerberos authenticator and ticket sent by the client.

See this email exchange from 2001 :-) http://psg.com/lists/rap/rap.2001/msg00269.html where the same issue is raised by Hannes Tschofenig and confirmed by one of the RFC authors, R. Hess.

RFC 3183, "Domain Security Services using S/MIME", October 2001

Source of RFC: smime (sec)

Errata ID: 3757
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2013-10-18
Verifier Name: Sean Turner
Date Verified: 2013-12-03

Section 3.1.2 says:

   An S/MIME signed attribute is used to indicate the type of signature.
   This should be used in conjunction with the naming conventions
   specified in the previous section.  When an S/MIME signed message
   containing the signature type attribute is received it triggers the
   software to verify that the correct naming convention has been used.

   The ASN.1 [4] notation of this attribute is: -

      SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER

It should say:

   An S/MIME signed attribute is used to indicate the type of signature.
   This should be used in conjunction with the naming conventions
   specified in the previous section.  When an S/MIME signed message
   containing the signature type attribute is received it triggers the
   software to verify that the correct naming convention has been used.

   The following object identifier identifies the SignatureType
   attribute:

      id-aa-signatureType OBJECT IDENTIFIER ::= { iso(1) 
          member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 2 28 }

   The ASN.1 [4] notation of this attribute is:

      SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER

Notes:

The specification provides the syntax for the SignatureType attribute,
but it fails to provide the object identifier for the attribute. The object
identifier was assigned, but for some reason it is not provided in the
document.

RFC 3189, "RTP Payload Format for DV (IEC 61834) Video", January 2002

Note: This RFC has been obsoleted by RFC 6469

Source of RFC: avt (rai)

Errata ID: 326
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stephen Casner
Date Reported: 2005-03-10
Verifier Name: Cullen Jennings
Date Verified: 2009-01-08

Section 3.1 says:

      a=fmtp:113 encode=SD-VCR/525-60
      a=fmtp:113 audio=none

It should say:

     a=fmtp:113 encode=SD-VCR/525-60 audio=none

Errata ID: 756
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stephen Casner
Date Reported: 2005-03-10
Verifier Name: Cullen Jennings
Date Verified: 2009-01-08

Section 3.2 says:

      a=fmtp: 112 encode=SD-VCR/525-60
      a=fmtp: 112 audio=bundled
      a=fmtp: 113 encode=306M/525-60
      a=fmtp: 113 audio=bundled

It should say:

      a=fmtp:112 encode=SD-VCR/525-60 audio=bundled
      a=fmtp:113 encode=306M/525-60 audio=bundled

Notes:

from pending

RFC 3196, "Internet Printing Protocol/1.1: Implementor's Guide", November 2001

Source of RFC: ipp (app)

Errata ID: 2924
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Sweet
Date Reported: 2011-08-08
Verifier Name: Peter Saint-Andre
Date Verified: 2011-11-12

Section 3.1.3.1.1 says:

The Printer object MUST return one of the following "status-code"
values for the indicated reason.  Whether all of the document data
has been accepted or not before returning the success or error
response depends on implementation.  See Section 13 in [RFC2911] for
a more complete description of each status code.

It should say:

The Printer object MUST return one of the following "status-code"
values for the indicated reason.  The Printer object MUST accept all
document data before returning the success or error response.  See
Section 13 in [RFC2911] for a more complete description of each
status code.

Notes:

HTTP (RFC 2616) classifies POST as a non-idempotent method, so a conforming server implementation may only return an error status or 100-continue as described in sections 8.1.2.2 and 8.2.2 of RFC 2616. Essentially, the printer cannot respond to the POST until it has processed all of the request message body, otherwise how would it report chunking or other protocol errors? And how would a client reliably send or a server reliably process multiple IPP requests (as POST messages) when a server provides an early response?

Errata ID: 3009
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Sweet
Date Reported: 2011-11-02
Verifier Name: Peter Saint-Andre
Date Verified: 2011-11-12

Section 7.1 says:

   Connection  must-   must    must-  must    "close" only.  Both
                 if              if             client and server
                                                SHOULD keep a
                                                connection for the
                                                duration of a sequence
                                                of operations.  The
                                                client and server MUST
                                                include this header
                                                for the last operation
                                                in such a sequence.

It should say:

   Connection  must-   must    must-  must    "close" or "upgrade" only.  Both
                 if              if             client and server
                                                SHOULD keep a
                                                connection for the
                                                duration of a sequence
                                                of operations.  The
                                                client and server MUST
                                                include this header
                                                with the value "close"
                                                for the last operation
                                                in such a sequence,
                                                if known. The value
                                                "Upgrade" is used for
                                                TLS upgrade [RFC2817].

Notes:

Implementers guide does not include support for HTTP Upgrade [RFC2817].

Errata ID: 3010
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Sweet
Date Reported: 2011-11-02
Verifier Name: Peter Saint-Andre
Date Verified: 2011-11-12

Section 7.1 says:

User-Agent     not      not

It should say:

User-Agent     may      not

Notes:

User-Agent identifies the client software to the Printer, which may in fact be useful for implementing workarounds, etc.

Errata ID: 3161
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Sweet
Date Reported: 2012-03-22
Verifier Name: Peter Saint-Andre
Date Verified: 2012-03-22

Section 4.5 says:

   The IPP object model does not prohibit a job that contains no
   documents.  Such a job may be created in a number of ways including a
   'create-job' followed by an 'add-document' that contains no data and
   has the 'last-document' flag set.

It should say:

   The IPP object model does not prohibit a job that contains no
   documents.  Such a job may be created in a number of ways including a
   'Create-Job' followed by a 'Send-Document' that contains no data and
   has the 'last-document' flag set.

Notes:

The operation is called "Send-Document", not "add-document"...

RFC 3204, "MIME media types for ISUP and QSIG Objects", December 2001

Note: This RFC has been updated by RFC 3459, RFC 5621

Source of RFC: sip (rai)

Errata ID: 325
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Francois Audet
Date Reported: 2001-12-13

In the Authors Address Section:

   Francois Audet
   Nortel Networks
   4301 Great America Parkway
   Santa Clara, CA 95054, USA
   EMail: mzonoun@nortelnetworks.com

   Mo Zonoun
   Nortel Networks
   4301 Great America Parkway
   Santa Clara, CA 95054, USA
   EMail: audet@nortelnetworks.com

It should say:

   Francois Audet
   Nortel Networks
   4301 Great America Parkway
   Santa Clara, CA 95054, USA
   EMail: audet@nortelnetworks.com

   Mo Zonoun
   Nortel Networks
   4301 Great America Parkway
   Santa Clara, CA 95054, USA
   EMail: mzonoun@nortelnetworks.com

RFC 3207, "SMTP Service Extension for Secure SMTP over Transport Layer Security", February 2002

Note: This RFC has been updated by RFC 7817

Source of RFC: Legacy

Errata ID: 324

Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Simon Josefsson
Date Reported: 2002-02-13
Report Text:

The document is missing a reference: </ORIG>   [MIME-SEC] Galvin, J., Murphy, S., Crocker, S., and Freed, N.,
               "Security Multiparts for MIME: Multipart/Signed and
               Multipart/Encrypted", RFC 1847, October 1995.
</CORR>

---

RFC 3208, "PGM Reliable Transport Protocol Specification", December 2001

Source of RFC: Legacy
Area Assignment: tsv

Errata ID: 323
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Lorenzo Vicisano
Date Reported: 2002-09-17

Section 8 says:

   Options:

      This field encodes binary indications of the presence and
      significance of any options.  It also directly encodes some
      options.

      bit 0 set => One or more Option Extensions are present

      bit 1 set => One or more Options are network-significant

         Note that this bit is clear when OPT_FRAGMENT and/or
         OPT_JOIN are the only options present.

      bit 6 set => Packet is a parity packet for a transmission
	 group
      of variable sized packets (OPT_VAR_PKTLEN).  Only present
	 when
      OPT_PARITY is also present.

      bit 7 set => Packet is a parity packet (OPT_PARITY)

      Bits are numbered here from left (0 = MSB) to right (7 =
	 LSB).

      All the other options (option extensions) are encoded in
      extensions to the PGM header.

It should say:

   Options:

      This field encodes binary indications of the presence and
      significance of any options.  It also directly encodes some
      options.

      bit 7 set => One or more Option Extensions are present

      bit 6 set => One or more Options are network-significant

         Note that this bit is clear when OPT_FRAGMENT and/or
         OPT_JOIN are the only options present.

      bit 1 set => Packet is a parity packet for a transmission
	 group
      of variable sized packets (OPT_VAR_PKTLEN).  Only present
	 when
      OPT_PARITY is also present.

      bit 0 set => Packet is a parity packet (OPT_PARITY)

      Bits are numbered here from left (0 = MSB) to right (7 =
	 LSB).

      All the other options (option extensions) are encoded in
      extensions to the PGM header.

Errata ID: 7295
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michal Ruprich
Date Reported: 2023-01-02
Verifier Name: Martin Duke
Date Verified: 2024-03-12

Section 9.2.4 says:

Option Length = 12 octets

It should say:

Option Length = 16 octets

Notes:

Every option packet has a certain length including the option header itself. OPT_LENGTH, OPT_NAK_LIST and OPT_JOIN have the length correctly counted WITH the header length (4B) but OPT_FRAGMENT has 4*4B so the total length should be 16 octets.

RFC 3209, "RSVP-TE: Extensions to RSVP for LSP Tunnels", December 2001

Note: This RFC has been updated by RFC 3936, RFC 4420, RFC 4874, RFC 5151, RFC 5420, RFC 5711, RFC 6780, RFC 6790, RFC 7274

Source of RFC: mpls (rtg)

Errata ID: 2669
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mahesh
Date Reported: 2010-12-10
Verifier Name: Adrian Farrel
Date Verified: 2011-01-28

Section 4.3.3.1 says:

The path between a loose node and its preceding node MAY include other network nodes that are not part of the strict node or its preceding abstract node.

It should say:

The path between a loose node and its preceding node MAY include other network nodes that are not part of the loose node or its preceding abstract node.

Notes:

Narration incorrectly refers to "strict" node while describing "loose" node.

RFC 3217, "Triple-DES and RC2 Key Wrapping", December 2001

Source of RFC: smime (sec)

Errata ID: 639
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2007-10-28

Section 4.4 says:

   This section contains a RC2 Key Wrap example. Intermediate values
   corresponding to the named items in section 4.1 are given in
   hexadecimal.

It should say:

   This section contains a RC2 Key Wrap example. Intermediate values
   corresponding to the named items in section 4.1 are given in
   hexadecimal. In this example, the effective key length parameter for
   the RC2 algorithm should be 40 bits.

==========================================

RC2 Effective Key Bits: 40

CEK is (16 bytes):
 b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4 d9

LENGTH is: 16

LCEK is (17 bytes):
 10 b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4
 d9

PAD is (7 bytes):
 48 45 cc e7 fd 12 50

LCEKPAD is (24 bytes):
 10 b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4
 d9 48 45 cc e7 fd 12 50

SHA-1 Digest is (20 bytes):
 0a 6f f1 9f db 40 49 88 a2 fa ee 2e 53 37 12 98
 7e ca 48 06

ICV is (8 bytes):
 0a 6f f1 9f db 40 49 88

LCEKPADICV is (32 bytes):
 10 b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4
 d9 48 45 cc e7 fd 12 50 0a 6f f1 9f db 40 49 88

IV is (8 bytes):
 c7 d9 00 59 b2 9e 97 f7

KEK (16 bytes):
 fd 04 fd 08 06 07 07 fb 00 03 fe ff fd 02 fe 05

TEMP1 (32 bytes):
 a0 1d a2 59 37 93 12 60 e4 8c 55 f5 04 ce 70 b8
 ac 8c d7 9e ff 8e 99 32 9f a9 8a 07 a3 1f f7 a7

TEMP2 (40 bytes):
 c7 d9 00 59 b2 9e 97 f7 a0 1d a2 59 37 93 12 60
 e4 8c 55 f5 04 ce 70 b8 ac 8c d7 9e ff 8e 99 32
 9f a9 8a 07 a3 1f f7 a7

TEMP3 (40 bytes):
 a7 f7 1f a3 07 8a a9 9f 32 99 8e ff 9e d7 8c ac
 b8 70 ce 04 f5 55 8c e4 60 12 93 37 59 a2 1d a0
 f7 97 9e b2 59 00 d9 c7

FinalIV (8 bytes):
 4a dd a2 2c 79 e8 21 05

KEK (16 bytes):
 fd 04 fd 08 06 07 07 fb 00 03 fe ff fd 02 fe 05

RESULT (40 bytes):
 70 e6 99 fb 57 01 f7 83 33 30 fb 71 e8 7c 85 a4
 20 bd c9 9a f0 5d 22 af 5a 0e 48 d3 5f 31 38 98
 6c ba af b4 b2 8d 4f 35

==========================================

RC2 Effective Key Bits: 128

CEK is (16 bytes):
 b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4 d9

LENGTH is: 16

LCEK is (17 bytes):
 10 b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4
 d9

PAD is (7 bytes):
 48 45 cc e7 fd 12 50

LCEKPAD is (24 bytes):
 10 b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4
 d9 48 45 cc e7 fd 12 50

SHA-1 Digest is (20 bytes):
 0a 6f f1 9f db 40 49 88 a2 fa ee 2e 53 37 12 98
 7e ca 48 06

ICV is (8 bytes):
 0a 6f f1 9f db 40 49 88

LCEKPADICV is (32 bytes):
 10 b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4
 d9 48 45 cc e7 fd 12 50 0a 6f f1 9f db 40 49 88

IV is (8 bytes):
 c7 d9 00 59 b2 9e 97 f7

KEK (16 bytes):
 fd 04 fd 08 06 07 07 fb 00 03 fe ff fd 02 fe 05

TEMP1 (32 bytes):
 03 5e 97 2a b1 5c c4 c9 c4 a0 3d ba a3 5a 21 66
 67 e4 3e bc a2 67 46 ae 86 08 db c8 9e 64 ca 29

TEMP2 (40 bytes):
 c7 d9 00 59 b2 9e 97 f7 03 5e 97 2a b1 5c c4 c9
 c4 a0 3d ba a3 5a 21 66 67 e4 3e bc a2 67 46 ae
 86 08 db c8 9e 64 ca 29

TEMP3 (40 bytes):
 29 ca 64 9e c8 db 08 86 ae 46 67 a2 bc 3e e4 67
 66 21 5a a3 ba 3d a0 c4 c9 c4 5c b1 2a 97 5e 03
 f7 97 9e b2 59 00 d9 c7

FinalIV (8 bytes):
 4a dd a2 2c 79 e8 21 05

KEK (16 bytes):
 fd 04 fd 08 06 07 07 fb 00 03 fe ff fd 02 fe 05

RESULT (40 bytes):
 f4 d8 02 1c 1e a4 63 d2 17 a9 eb 69 29 ff a5 77
 36 d3 e2 03 86 c9 09 93 83 5b 4b e4 ad 8d 8a 1b
 c6 3b 25 de 2b f7 79 93

Notes:

The text is silent about the RC2 parameter that indicates the effective key size. This errata resolves the ambiguity.

To aid implementors, this errata includes two examples. The first one matches section 4.4 and uses a 40-bit effective key size. The second one uses a 128-bit effective key size. Many thanks to Peter Yee for generating the examples and Blake Ramsdell for checking them.

RFC 3218, "Preventing the Million Message Attack on Cryptographic Message Syntax", January 2002

Source of RFC: smime (sec)

Errata ID: 5072
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kalle Olavi Niemitalo
Date Reported: 2017-07-25
Verifier Name: RFC Editor
Date Verified: 2017-07-26

Section 4 says:

   [PKCS-1-v2]   Kaliski, B., "PKCS #1: RSA Encryption, Version 2.0",
                 RFC 2347, October 1998.

It should say:

   [PKCS-1-v2]   Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
                 Specifications Version 2.0", RFC 2437, October 1998.

Notes:

RFC 2347 is "TFTP Option Extension", unrelated to PKCS.
-----
Verifier Notes: Transposition of the RFC number and incorrect author and title have been updated in the corrected text.

RFC 3219, "Telephony Routing over IP (TRIP)", January 2002

Note: This RFC has been updated by RFC 8602

Source of RFC: iptel (rai)

Errata ID: 322
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jonathan Rosenberg
Date Reported: 2002-09-06

Section 10.3.1.1 says:

   -  If the LS is configured to use the MultiExitDisc attribute to
      break ties, and the candidate routes differ in the value of the
      MultiExitDisc attribute, then select the route that has the
      lowest value of MultiExitDisc, else
   -  Select the route that was advertised by the external LS that
      has the lowest TRIP Identifier.

It should say:

   -  If the LS is configured to use the MultiExitDisc attribute to
      break ties, and the candidate routes differ in the value of the
      MultiExitDisc attribute, then select the route that has the
      highest value of MultiExitDisc, else
   -  Select the route that was advertised by the external LS that
      has the lowest ITAD number.

RFC 3226, "DNSSEC and IPv6 A6 aware server/resolver message size requirements", December 2001

Note: This RFC has been updated by RFC 4033, RFC 4034, RFC 4035

Source of RFC: dnsext (int)

Errata ID: 2810
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Edward Lewis
Date Reported: 2011-05-18
Verifier Name: Brian Haberman
Date Verified: 2012-05-01

Section 2.1 says:

DNSSEC OK[OK] specifies how ...

It should say:

DNSSEC OK[RFC3225] specifies how ...

Notes:

Reference "link" is broken.

RFC 3245, "The History and Context of Telephone Number Mapping (ENUM) Operational Decisions: Informational Documents Contributed to ITU-T Study Group 2 (SG2)", March 2002

Source of RFC: IAB

Errata ID: 319
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Derrick D. Daugherty
Date Reported: 2004-01-02

Section 4.2 says:

4.2. Name server operator requirements

   RFC 2870 (http://www.ietf.org/rfc/rfc2780.txt) describes the
   requirements for operating DNS root servers."

It should say:

4.2. Name server operator requirements

   RFC 2870 (http://www.ietf.org/rfc/rfc2870.txt) describes the
   requirements for operating DNS root servers."

RFC 3247, "Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior)", March 2002

Source of RFC: diffserv (tsv)

Errata ID: 318
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: "laercio cruvinel"
Date Reported: 2006-02-02

Section 2.1 says:

   Finally, there is an additional recommendation in [6] that an EF
   compliant node SHOULD NOT reorder packets within a micorflow.

It should say:

   Finally, there is an additional recommendation in [6] that an EF
   compliant node SHOULD NOT reorder packets within a microflow.

Notes:

micorflow --> microflow

RFC 3253, "Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)", March 2002

Source of RFC: deltav (app)

Errata ID: 317

Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2003-10-11
Report Text:

The WebDAV working group maintains an errata list for RFC3253 at:
http://www.webdav.org/deltav/protocol/rfc3253-issues-list.htm

---

RFC 3261, "SIP: Session Initiation Protocol", June 2002

Note: This RFC has been updated by RFC 3265, RFC 3853, RFC 4320, RFC 4916, RFC 5393, RFC 5621, RFC 5626, RFC 5630, RFC 5922, RFC 5954, RFC 6026, RFC 6141, RFC 6665, RFC 6878, RFC 7462, RFC 7463, RFC 8217, RFC 8591, RFC 8760, RFC 8898, RFC 8996

Source of RFC: sip (rai)

Errata ID: 316
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: RFC Editor
Date Reported: 2003-10-03

In Section 25.1:

     digest-uri-value  =  rquest-uri ; Equal to request-uri as
                          specified by HTTP/1.1 

It should say:

     digest-uri-value  =  request-uri ; Equal to request-uri as
                          specified by HTTP/1.1

Errata ID: 1051
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexandre Machado
Date Reported: 2007-08-23
Verifier Name: Robert Sparks
Date Verified: 2010-04-03

Section 25.1 says:

    srvr           =  [ [ userinfo "@" ] hostport ]

It should say:

    srvr           =  [ [ userinfo ] hostport ]

Notes:

The character "@" should not appear in this rule since it already appears at the end of the rule "userinfo":

userinfo = ( user / telephone-subscriber ) [ ":" password ] "@"

According to the use of rule "userinfo" in other rules such as "SIP-URI" and "SIPS-URI", the correct place of character "@" is really at the end of rule "userinfo" and not in all other rules using it.

Errata ID: 1073
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Marco Ambu
Date Reported: 2005-12-15
Verifier Name: Robert Sparks
Date Verified: 2010-04-03

 

I would like to show you an error in RFC 3261. I've discussed in
SIP-implementors mailing list too.

in RFC 3261 page 44 par 8.1.3.4 there is an example of URI (contact URI)
with uri headers:

sip:user@host?Subject=foo&Call-Info=<http://www.foo.com>

I've noticed that URI header "Call-Info" has a value with characters not
allowed in uri headers.

The BNF says that an header value must contain characters in   
hnv-unreserved or unreserved or escaped but '<' and '>' are not in that set.

The right example should be the following:
sip:user@host?Subject=foo&Call-Info=%3Chttp://www.foo.com%3E  

It should say:

[not submitted]

Notes:

from pending

Errata ID: 1470
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Iñaki Baz Castillo
Date Reported: 2008-07-14
Verifier Name: Robert Sparks
Date Verified: 2010-04-03

Section 17.2.2 says:

If the TU passes a final response (status codes 200-699) to the 
server while in the "Proceeding" state, the transaction MUST enter 
the "Completed" state...

It should say:

If the TU passes a final response (status codes 200-699) to the 
server while in the "Trying" or "Proceeding" state, the transaction 
MUST enter the "Completed" state...

Notes:

"17.2.2 Non-INVITE Server Transaction" doesn't consider the case in which the transaction state is "Trying" and the transaction receives from the TU a final response.
It's totally possible that TU sends a final response without sending before a provisional response. Note that this case is perfectly valid in the diagram of page 139.

Errata ID: 3183
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruno CHATRAS
Date Reported: 2012-04-10
Verifier Name: Robert Sparks

Section 23.4.3 says:

         --boundary42
         Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
              name=smime.p7m
         Content-Transfer-Encoding: base64
         Content-Disposition: attachment; filename=smime.p7m
            handling=required
         Content-Length: 231

It should say:

   --boundary42
         Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
              name=smime.p7m
         Content-Transfer-Encoding: base64
         Content-Disposition: attachment; filename=smime.p7m
            handling=required

Notes:

A Content-Length header is shown for a body-part within a multipart body. But Content-Length is an HTTP/SIP header, not a IANA-registered MIME header and should therefore not appear at that location in valid examples. The length of a body part within a multipart body is determined by MIME framing. A Content-Length header found for a body-part within a multipart body is meaningless and should be ignored.

This was discussed on both the SIP Implementors and SIP Core mailing lists.

Errata ID: 4567
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Christer Holmberg
Date Reported: 2015-12-17
Verifier Name: Ben Campbell
Date Verified: 2015-12-17

Section 20.11 says:

The handling parameter, handling-param, describes how the UAS should
react if it receives a message body whose content type or disposition
type it does not understand. The parameter has defined values of
"optional" and "required". If the handling parameter is missing, the
value "required" SHOULD be assumed. The handling parameter is
described in RFC 3204 [19].

It should say:

The handling parameter, handling-param, describes how the UAS should
react if it receives a message body whose content type or disposition
type it does not understand. The parameter has defined values of
"optional" and "required". If the handling parameter is missing, or if
the Content-Disposition header field is missing, the value "required" 
SHOULD be assumed. The handling parameter is described in RFC 3204 [19].

Errata ID: 2051
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Cullen Jennings
Date Reported: 2010-02-24
Verifier Name: Robert Sparks
Date Verified: 2010-05-23

Section 26.3.1 says:

   Proxy servers, redirect
   servers, and registrars SHOULD possess a site certificate whose
   subject corresponds to their canonical hostname. 

It should say:

   Proxy servers, redirect
   servers, and registrars SHOULD possess a site certificate whose
   subject corresponds to the DNS name other SIP devices will use to reach them. 

Notes:

The term hostname seemed to make some people think if you had two sip servers for the domain example.com with hostnames host1 and host2, the the cert should have host1.example.com when in fact the sip signaling always used exmaple.com and the cert should have a example.com as the name.

Errata ID: 4084
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Xing Lou Han
Date Reported: 2014-08-15
Verifier Name: Orie Steele
Date Verified: 2024-03-29

Section 13.2.2.4 says:

   If the dialog identifier in the 2xx response matches the dialog
   identifier of an existing dialog, the dialog MUST be transitioned to
   the "confirmed" state, and the route set for the dialog MUST be
   recomputed based on the 2xx response using the procedures of Section
   12.2.1.2.

It should say:

   If the dialog identifier in the 2xx response matches the dialog
   identifier of an existing dialog, the dialog MUST be transitioned to
   the "confirmed" state, and the route set for the dialog MUST be
   recomputed based on the 2xx response using the procedures of Section
   12.2.1.1.

Notes:

The procedures of recomputing the route set should refer to the Section 12.2.1.1, rather than Section 12.2.1.2.

Actually in Section 12.2.1.2, there is no procedure of computing route set. Instead, the related procedures can only be found in Section 12.2.1.1.

To avoid misleading, "12.2.1.2" here should be "12.2.1.1" instead.

Errata ID: 4300
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tamas Horvath
Date Reported: 2015-03-12
Verifier Name: Orie Steele
Date Verified: 2024-03-29

Section 24.2 says:

F2 100 Trying atlanta.com proxy -> Alice
(...)
F3 INVITE atlanta.com proxy -> biloxi.com proxy
(...)
F4 100 Trying biloxi.com proxy -> atlanta.com proxy
(...)
F5 INVITE biloxi.com proxy -> Bob

It should say:

F3 100 Trying atlanta.com proxy -> Alice
(...)
F2 INVITE atlanta.com proxy -> biloxi.com proxy
(...)
F5 100 Trying biloxi.com proxy -> atlanta.com proxy
(...)
F4 INVITE biloxi.com proxy -> Bob

Notes:

Figure 1 in Section 4 shows different indexes for the 100 Trying and INVITE messages.

Errata ID: 4637
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Boris Shtrasman
Date Reported: 2016-03-11
Verifier Name: Orie Steele
Date Verified: 2024-03-29

Section 23.4.3 says:

        ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
        4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
        n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
        7GhIGfHfYT64VQbnj756

        --boundary42-

It should say:

        ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
        4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
        n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
        7GhIGfHfYT64VQbnj756

        --boundary42--

Notes:

As far as I know a boundary end should end with two dashes as for RFC 3851 for that specific case, hence it should be :

--boundary42--

RFC 3262, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", June 2002

Source of RFC: sip (rai)

Errata ID: 315

Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Steve Conner
Date Reported: 2002-07-04
Report Text:

This document obsoletes RFC 2543.

---

Errata ID: 4600
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Christer Holmberg
Date Reported: 2016-01-25
Verifier Name: Ben Campbell
Date Verified: 2016-01-25

Section 3 says:

The provisional response to be sent reliably is constructed by the
UAS core according to the procedures of Section 8.2.6 of RFC 3261.
In addition, it MUST contain a Require header field containing the
option tag 100rel, and MUST include an RSeq header field.  The value
of the header field for the first reliable provisional response in a
transaction MUST be between 1 and 2**31 - 1.  It is RECOMMENDED that
it be chosen uniformly in this range.  The RSeq numbering space is
within a single transaction.  This means that provisional responses
for different requests MAY use the same values for the RSeq number.

It should say:

The provisional response to be sent reliably is constructed by the
UAS core according to the procedures of Section 8.2.6 of RFC 3261.
In addition, it MUST contain a Require header field containing the
option tag 100rel, and MUST include an RSeq header field.  The
value of the header field for the first reliable provisional 
response in a transaction MUST be between 1 and 2**31 - 1.  It is
RECOMMENDED that it be chosen uniformly in this range. The RSeq 
numbering space is within a single transaction. This means that
the RSeq value of a provisional response within a fork of a request
is independent of the RSeq value of a provisional response within 
any other fork of that request, or for the responses for any other
request. It thus may be higher, lower, or the same as any other such
RSeq value.

Errata ID: 4601
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Christer Holmberg
Date Reported: 2016-01-25
Verifier Name: Ben Campbell
Date Verified: 2016-01-25

Section 4 says:

If a provisional response is received for an initial request, and
that response contains a Require header field containing the option
tag 100rel, the response is to be sent reliably.  If the response is
a 100 (Trying) (as opposed to 101 to 199), this option tag MUST be
ignored, and the procedures below MUST NOT be used.

It should say:

If a provisional response is received for an initial request, and
that response contains a Require header field containing the option
tag 100rel, the response was sent by the UAS reliably.  If the
response is a 100 (Trying) (as opposed to 101 to 199), this option
tag MUST be ignored, and the procedures below MUST NOT be used.

Errata ID: 4602
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Christer Holmberg
Date Reported: 2016-01-25
Verifier Name: Ben Campbell
Date Verified: 2016-01-25

Section 4 says:

Assuming the response is to be transmitted reliably, the UAC MUST
create a new request with method PRACK.  This request is sent within
the dialog associated with the provisional response (indeed, the
provisional response may have created the dialog).  PRACK requests
MAY contain bodies, which are interpreted according to their type and
disposition.

It should say:

Assuming the response was transmitted reliably by the UAS, the UAC
MUST create a new request with method PRACK.  This request is sent
within the dialog associated with the provisional response (indeed,
the provisional response may have created the dialog). PRACK 
requests MAY contain bodies, which are interpreted according to
their type and disposition.

Errata ID: 4603
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Christer Holmberg
Date Reported: 2016-01-25
Verifier Name: Ben Campbell
Date Verified: 2016-01-25

Section 4 says:

Once a reliable provisional response is received, retransmissions of
that response MUST be discarded.  A response is a retransmission when
its dialog ID, CSeq, and RSeq match the original response.  The UAC
MUST maintain a sequence number that indicates the most recently
received in-order reliable provisional response for the initial
request.  This sequence number MUST be maintained until a final
response is received for the initial request.  Its value MUST be
initialized to the RSeq header field in the first reliable
provisional response received for the initial request.

It should say:

Once a reliable provisional response is received, retransmissions of
that response MUST be discarded.  A response is a retransmission 
when its dialog ID, CSeq, and RSeq match the original response. The
UAC MUST maintain, independently for each dialog ID, a sequence
number that indicates the most recently received in-order reliable
provisional response for the initial request.  This sequence number
MUST be maintained until a final response is received for the
initial request. Its value MUST, for each dialog (or early dialog),
be initialized to the RSeq header field in the first reliable
provisional response associated with the dialog received for the
initial request.

Notes:

Verifier edit: I removed two commas around "associated with the dialog" from the last sentence of the corrected text.

Errata ID: 4604
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Christer Holmberg
Date Reported: 2016-01-25
Verifier Name: Ben Campbell
Date Verified: 2016-01-25

Section 4 says:

Handling of subsequent reliable provisional responses for the same
initial request follows the same rules as above, with the following
difference: reliable provisional responses are guaranteed to be in
order.  As a result, if the UAC receives another reliable provisional
response to the same request, and its RSeq value is not one higher
than the value of the sequence number, that response MUST NOT be
acknowledged with a PRACK, and MUST NOT be processed further by the
UAC.  An implementation MAY discard the response, or MAY cache the
response in the hopes of receiving the missing responses.

It should say:

Subsequent reliable provisional responses for the same initial
request are guaranteed  to have been generated by the UAS in the
order of their RSeq values and must be acknowledged in that order.
As a result, if the UAC receives another reliable provisional
response to the same request, and its RSeq value is one higher than
the value of the previously received RSeq value in the dialog (or 
early dialog), then the new RSeq value is saved and the response is
handled as described above. If the RSeq value is not one higher than
the value of the sequence number, that response MUST NOT be
acknowledged with a PRACK, and MUST NOT be processed further by the
UAC. An implementation MAY discard the response, or MAY cache the
response to be processed (and acknowledged) after receiving the
missing responses.

RFC 3264, "An Offer/Answer Model with Session Description Protocol (SDP)", June 2002

Note: This RFC has been updated by RFC 6157, RFC 8843, RFC 9143

Source of RFC: mmusic (rai)

Errata ID: 3818
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jörgen Axell
Date Reported: 2013-12-02
Verifier Name: Gonzalo Camarillo
Date Verified: 2013-12-03

Section 4 says:

   The agent receiving the offer MAY generate an answer, or it MAY
   reject the offer.  The means for rejecting an offer are dependent on
   the higher layer protocol.  The offer/answer exchange is atomic; if
   the answer is rejected, the session reverts to the state prior to the
   offer (which may be absence of a session).

It should say:

   The agent receiving the offer MAY generate an answer, or it MAY
   reject the offer.  The means for rejecting an offer are dependent on
   the higher layer protocol.  The offer/answer exchange is atomic; if
   the offer is rejected, the session reverts to the state prior to the
   offer (which may be absence of a session).

Notes:

You can't reject an answer. When the answer is received the SDP negotiation is completed.

RFC 3265, "Session Initiation Protocol (SIP)-Specific Event Notification", June 2002

Note: This RFC has been obsoleted by RFC 6665

Note: This RFC has been updated by RFC 5367, RFC 5727, RFC 6446

Source of RFC: sip (rai)

Errata ID: 314
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2002-07-23

In the Header:

   Updates: 2543

It should say:

   Updates: 3261

RFC 3266, "Support for IPv6 in Session Description Protocol (SDP)", June 2002

Note: This RFC has been obsoleted by RFC 4566

Source of RFC: mmusic (rai)

Errata ID: 313
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bernie Hoeneisen
Date Reported: 2004-01-15

 

Section 1 refers to RFC 2328 as follows:

   Accordingly, the address type "IP6" indicating an IPv6 address,
   should be allowed in the connection field, "c=", of the SDP.  The
   ABNF already reflects this, though the "Connection Data" text under
   section 6 of RFC 2328 currently only defines the "IP4" address type.
                    ^^^^
It should refer to RFC 2327.

RFC 3267, "Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", June 2002

Note: This RFC has been obsoleted by RFC 4867

Source of RFC: avt (rai)

Errata ID: 312
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Frederic Turgis
Date Reported: 2002-07-29

Section 5.3 says:

   The FT field and the Q bit are defined in the same way as in
   Section 4.1.2. The P bits are padding and MUST be set to 0.

It should say:

   The FT field and the Q bit are defined in the same way as in
   Section 4.3.2. The P bits are padding and MUST be set to 0.

RFC 3271, "The Internet is for Everyone", April 2002

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: gen

Errata ID: 310
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Robert deMallac
Date Reported: 2002-07-31

Section 1 says:

   Internet is for everyone - but it won't be if it cannot keep up
   with the explosive demand for its services, so we must dedicate
   ourselves to continuing its technological evolution and development
   of the technical standards the lie at the heart of the Internet
   revolution.

It should say:

   Internet is for everyone - but it won't be if it cannot keep up
   with the explosive demand for its services, so we must dedicate
   ourselves to continuing its technological evolution and development
   of the technical standards that lie at the heart of the Internet
   revolution.

Errata ID: 311
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: vinton g. cerf"
Date Reported: 2002-08-01
Verifier Name: Russ Housley
Date Verified: 2010-04-12

Section 3 says:

   Internet is for everyone - but it won't be if it cannot keep up with
   the explosive demand for its services, so we must dedicate ourselves
   to continuing its technological evolution and development of the
   technical standards the lie at the heart of the Internet revolution.

It should say:

   Internet is for everyone - but it won't be if it cannot keep up with
   the explosive demand for its services, so we must dedicate ourselves
   to continuing its technological evolution and development of the
   technical standards that lie at the heart of the Internet revolution.

RFC 3272, "Overview and Principles of Internet Traffic Engineering", May 2002

Note: This RFC has been obsoleted by RFC 9522

Note: This RFC has been updated by RFC 5462

Source of RFC: tewg (subip)

Errata ID: 309
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jean-Michel Grimaldi
Date Reported: 2002-06-18

Section 4.2.2 says:

   The Internet evolved from the APARNET and adopted dynamic routing
   algorithms with distributed control to determine the paths that
   packets should take en-route to their destinations.

It should say:

   The Internet evolved from the ARPANET and adopted dynamic routing
   algorithms with distributed control to determine the paths that
   packets should take en-route to their destinations.

RFC 3275, "(Extensible Markup Language) XML-Signature Syntax and Processing", March 2002

Source of RFC: xmldsig (sec)

Errata ID: 308

Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Joseph Reagle
Date Reported: 2002-04-18
Report Text:

A list of errata can be found at: http://www.w3.org/2001/10/xmldsig-errata

---

RFC 3277, "Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance", April 2002

Source of RFC: isis (rtg)

Errata ID: 7127
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Scudder
Date Reported: 2022-09-12
Verifier Name: Alvaro Retana
Date Verified: 2022-09-12

Section 2 says:

   As such, it is recommended that each time a router establishes an
   adjacency, it will update its LSP and flood it immediately, even
   before beginning database synchronization.  This will allow for the
   Overload bit setting to propagate immediately, and remove the
   potential for an older version of the reloaded routers LSP to be
   used.

It should say:

   As such, it is recommended that each time a router establishes an
   adjacency, it will update its LSP and flood it immediately, even
   before beginning database synchronization.  This will allow for the
   Overload bit setting to propagate immediately, and remove the
   potential for an older version of the reloaded router's LSP to be
   used.

Notes:

"reloaded router's" should be possessive singular.

RFC 3279, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", April 2002

Note: This RFC has been updated by RFC 4055, RFC 4491, RFC 5480, RFC 5758, RFC 8692

Source of RFC: pkix (sec)

Errata ID: 307
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Olivier Dierick
Date Reported: 2005-08-01

Section 1 says:

   This document specifies algorithm identifiers and ASN.1 [X.660]
   encoding formats for digital signatures and subject public keys used
   in the Internet X.509 Public Key Infrastructure (PKI).

It should say:

   This document specifies algorithm identifiers and ASN.1 [X.690]
   encoding formats for digital signatures and subject public keys used
   in the Internet X.509 Public Key Infrastructure (PKI).

Notes:

In Section 4, it says:
[X.660] ITU-T Recommendation X.660 Information Technology -
ASN.1 encoding rules: Specification of Basic Encoding
Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER), 1997.
It should say:
[X.690] ITU-T Recommendation X.660 Information Technology -
ASN.1 encoding rules: Specification of Basic Encoding
Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER), 1997.

Errata ID: 2048
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jim Wigginton
Date Reported: 2009-10-12
Verifier Name: Pasi Eronen
Date Verified: 2010-02-22

Section 2.3.5 says:

      id-characteristic-two-basis OBJECT IDENTIFIER ::= {
           characteristic-two-field basisType(1) }

It should say:

      id-characteristic-two-basis OBJECT IDENTIFIER ::= {
           characteristic-two-field basisType(3) }

Notes:

Note that this bug is only in Section 2.3.5; the ASN.1 module in Section 3 has the correct OID.

Errata ID: 4036
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Matthias Koenig
Date Reported: 2014-07-03
Verifier Name: Kathleen Moriarty
Date Verified: 2015-03-31

Section 2.3.3 says:

g specifies the generator of the multiplicative subgroup of order g;

It should say:

g specifies the generator of the multiplicative subgroup of order q;

Notes:

RFC2631 states that g is of order q mod p (section 2.1.1).
Also, X9.42 (which is referenced in section 2.3.3 of RFC3279) defines g as
"generator of the q-order cyclic subgroup of GF(p), that is, an element of order q in the multiplicative group of GF(p)" (X9.42:2001, section 4.1)

Errata ID: 4102
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Annie Yousar
Date Reported: 2014-09-07
Verifier Name: Kathleen Moriarty
Date Verified: 2015-03-31

Section 1 says:

 This specification describes the encoding of digital signatures
 generated with the following cryptographic algorithms:

|   * Rivest-Shamir-Adelman (RSA);
    * Digital Signature Algorithm (DSA); and
    * Elliptic Curve Digital Signature Algorithm (ECDSA).

It should say:

 This specification describes the encoding of digital signatures
 generated with the following cryptographic algorithms:

|   * Rivest-Shamir-Adleman (RSA);
    * Digital Signature Algorithm (DSA); and
    * Elliptic Curve Digital Signature Algorithm (ECDSA).

Notes:

Len is "Adleman" and not "Adelman". The error repeats a few lines later again. The spelling in 2.2.1 is correct.

Errata ID: 7296
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Evan Pottier
Date Reported: 2023-01-03
Verifier Name: RFC Editor
Date Verified: 2023-01-06

Section 2.3.5 says:

   When the parameters are inherited, the parameters field SHALL contain
   implictlyCA, which is the ASN.1 value NULL.

It should say:

   When the parameters are inherited, the parameters field SHALL contain
   implicitlyCA, which is the ASN.1 value NULL.

Notes:

"implictly" appears to be missing an i.

RFC 3280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", April 2002

Note: This RFC has been obsoleted by RFC 5280

Note: This RFC has been updated by RFC 4325, RFC 4630

Source of RFC: pkix (sec)

Errata ID: 305
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Takashi Ito
Date Reported: 2002-11-11

Section 6.3.3 says:

   For each distribution point (DP) in the certificate CRL distribution
   points extension, for each corresponding CRL in the local CRL cache,
   while ((reasons_mask is not all-reasons) and (cert_status is
   UNREVOKED)) perform the following:

      (a)  Update the local CRL cache by obtaining a complete CRL, a
      delta CRL, or both, as required:

It should say:

   For each distribution point (DP) in the certificate CRL distribution
   points extension, for each corresponding CRL in the local CRL cache,
   while ((reasons_mask is not all-reasons) and (cert_status is
   UNREVOKED)) perform the following:

   (l)  Set the reasons_mask state variable to the union of
        its previous value and the value of the interim_reasons_mask
        state variable.

      (a)  Update the local CRL cache by obtaining a complete CRL, a
      delta CRL, or both, as required:

Errata ID: 306
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Olivier Dierick
Date Reported: 2005-08-01

Section 7 says:

   [X.660]     ITU-T Recommendation X.660 Information Technology - ASN.1
               encoding rules: Specification of Basic Encoding Rules
               (BER), Canonical Encoding Rules (CER) and Distinguished
               Encoding Rules (DER), 1997.

   [X.690]     ITU-T Recommendation X.690 Information Technology - Open
               Systems Interconnection - Procedures for the operation of
               OSI Registration Authorities: General procedures, 1992.

It should say:

   [X.660]     ITU-T Recommendation X.660 Information Technology - Open
               Systems Interconnection - Procedures for the operation of
               OSI Registration Authorities: General procedures, 1992.

   [X.690]     ITU-T Recommendation X.690 Information Technology - ASN.1
               encoding rules: Specification of Basic Encoding Rules
               (BER), Canonical Encoding Rules (CER) and Distinguished
               Encoding Rules (DER), 1997.

RFC 3281, "An Internet Attribute Certificate Profile for Authorization", April 2002

Note: This RFC has been obsoleted by RFC 5755

Source of RFC: pkix (sec)

Errata ID: 302
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Stephen Farrell
Date Reported: 2003-03-07

Section 4.4.6 says:

   Clearance ::= SEQUENCE {
           policyId            [0] OBJECT IDENTIFIER,
           classList           [1] ClassList DEFAULT {unclassified},
           securityCategories  [2] SET OF SecurityCategory OPTIONAL
   }

It should say:

   Clearance ::= SEQUENCE {
           policyId            OBJECT IDENTIFIER,
           classList           ClassList DEFAULT {unclassified},
           securityCategories  SET OF SecurityCategory OPTIONAL
   }

Notes:

The differences in tagging arose due to an unnoticed technical corrigendum (TC-2) being applied to the X.501 document during preparation of RFC 3281. The X.501 format is the correct form and will be included in a future update of RFC 3281. Implementers SHOULD modify their decoding functions to accept either format and, even if claiming RFC 3281 conformance, SHOULD output the (correct) X.501 format pending the issuing of a corrected RFC at which point the incorrect RFC 3281 format will no longer be specified.

Errata ID: 304
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2002-07-30

Section 7.1 says:

    The AC then contains the ciphertext inside its signed data.  The
    EnvelopedData (id-envelopedData) ContentType is used, and the
    content field will contain the EnvelopedData type.

It should say:

    Within EnvelopedData, the encapuslatedContentInfo identifies the
    content type carried withing the ciphertext.  In this case, the 
    contentType field of encapsulatedContentInfo MUST contain
    id-ct-attrCertEncAttrs, which has the following value:

       attrCertEncAttrs OBJECT IDENTIFIER ::=
             { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
	     pkcs9(9)
               id-smime(16) id-ct(1) 14 }

Notes:

Errata ID: 1479
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kurt Zeilenga
Date Reported: 2008-07-30
Verifier Name: Tim Polk
Date Verified: 2008-11-20

Section 4.4.6 says:

            SecurityCategory ::= SEQUENCE {
                 type      [0]  IMPLICIT OBJECT IDENTIFIER,
                 value     [1]  ANY DEFINED BY type
            }

It should say:

           SecurityCategory ::= SEQUENCE {
                 type      [0]  OBJECT IDENTIFIER,
                 value     [1] EXPLICIT ANY DEFINED BY type
            }

Notes:

It appears an error in the definition of SecurityCategory was introduced when it was taken from a module with EXPLICIT TAG default into a module with IMPLICIT TAG default. In particular, the tag on the value MUST be EXPLICIT due to the ANY. Otherwise the tag of the any would replace the value's tag.

Note that extra IMPLICIT in the original text is merely extraneous (whereas the missing EXPLICIT is quite problematic).

It is also noted that clearance was NOT defined in X.501(1993), but X.500(1997). However, X.501(2005) may be the best reference for clearance.

Errata ID: 303
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2004-08-26

Section 4.1 says:

             AttributeCertificateInfo ::= SEQUENCE {
                  version              AttCertVersion  -- version is v2,

It should say:

             AttributeCertificateInfo ::= SEQUENCE {
                  version              AttCertVersion,  -- version is v2,

Errata ID: 710
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Gidon Moont
Date Reported: 2006-12-20
Verifier Name: Stephen Farrell
Date Verified: 2006-12-21

Section 4.3.2 says:

   Note: [X.509-2000] defines the extension syntax as a "SEQUENCE OF
   Targets".  Conforming AC issuer implementations MUST only produce one
   "Targets" element.  Confirming AC users MUST be able to accept a
   "SEQUENCE OF Targets".  If more than one Targets element is found in
   an AC, the extension MUST be treated as if all Target elements had
   been found within one Targets element.

It should say:

   Note: [X.509-2000] defines the extension syntax as a "SEQUENCE OF
   Targets".  Conforming AC issuer implementations MUST only produce one
   "Targets" element.  Conforming AC users MUST be able to accept a
   "SEQUENCE OF Targets".  If more than one Targets element is found in
   an AC, the extension MUST be treated as if all Target elements had
   been found within one Targets element.

Notes:

Confirming -> Conforming

RFC 3289, "Management Information Base for the Differentiated Services Architecture", May 2002

Source of RFC: diffserv (tsv)

Errata ID: 300

Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tom Irwin
Date Reported: 2002-08-08
Report Text:

In the process of implementing the RFC 3289 DiffServ MIB, the following
errors and discrepancies were noted.

1. In the diffServClfrTable description (second paragraph),
diffServClfrStatus should be diffServClfrStorage.  This is an
understandability issue.

2. The diffServClfrElementStatus description indicates that this entry
cannot be deleted if there is a RowPointer pointing to it.  A RowPointer
is not used to select a classifier element, but rather the
diffServClfrId and diffServClfrElementId index values.  Consequently,
the diffServClfrElementTable does not require a UsageCounter or a
DestroyFlag.  This is an understandability issue.

3. In the diffServActionSpecific description (third paragraph)
erroneously references a meter.  This is an understandability issue.

4. The diffServMinRateAbsolute description indicates that zero is a
valid value.  The SYNTAX range indicates (1..4294967295), but should be
(0..4294967295).  This is an understandability issue and a MIB
implementation issue.

5. The diffServMinRateRelative description indicates that zero is a
valid value and that the values are in units of 1/1000 of 1.  The SYNTAX
range indicates (1..4294967295), but should be (0..1000).  This is an
understandability issue and a MIB implementation issue.

6. The diffServMaxRateAbsolute description indicates that zero is a
valid value.  The SYNTAX range indicates (1..4294967295), but should be
(0..4294967295).  This is an understandability issue and a MIB
implementation issue.

7. The diffServMaxRateRelative description indicates that zero is a
valid value and that the values are in units of 1/1000 of 1.  The SYNTAX
range indicates (1..4294967295), but should be (0..1000).  This is an
understandability issue and a MIB implementation issue.

---

Errata ID: 301

Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tom Irwin
Date Reported: 2002-08-27
Report Text:

1.  During implementation, there has been some confusion on the "reuse
of structural elements" in section 2.2.  It is clear from the comments
and the MIB that counters cannot be effectively reused.  What appears
confusing is the case when an entire (or partial) DiffServ tree used for
a specific interface ifIndex and direction is reused.  Is the DiffServ
tree in this case just a template such that all of the data path
elements are replicated (counters will not work properly) for another
interface?  This seems reasonable since other data path elements such as
queues and schedulers are clearly interface dependent. It is important
to remove this ambiguity since the RowPointer usage does not prohibit
this "not generally recommended" application.  What is the intent?

2. Minor update in section 3.2.2:
     ' Differentiated Services Code Point ' to
     ' Differentiated Services Code Point, including "any" '

3. Figure 9b in section 3.7.2.1 is somewhat difficult at first to follow
due to how the multiplexing is shown in the Yellow "Count Action" (an
action only has a single input).

---

RFC 3297, "Content Negotiation for Messaging Services based on Email", July 2002

Source of RFC: fax (app)

Errata ID: 299
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Graham Klyne
Date Reported: 2004-05-06

Section 8.1 says:

     Date: Wed,20 Sep 1995 00:18:00 (EDT)-0400

It should say:

       Date: Wed,20 Sep 1995 00:18:00 -0400 (EDT)

Notes:

OLD:

Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400

NEW:

Date: Wed,20 Sep 1995 00:19:00 -0400 (EDT)


OLD:

Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400

NEW:

Date: Wed,20 Sep 1995 00:21:00 -0400 (EDT)


OLD:

Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400

NEW:

Date: Wed,20 Sep 1995 00:22:00 -0400 (EDT)


In section 8.2:

OLD:

Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400

NEW:

Date: Wed,20 Sep 1995 00:19:00 -0400 (EDT)


OLD:

Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400

NEW:

Date: Wed,20 Sep 1995 00:22:00 -0400 (EDT)


In section 8.3:

OLD:

Date: Wed, 20 Sep 1995 00:18:00 (EDT)-0400

NEW:

Date: Wed, 20 Sep 1995 00:18:00 -0400 (EDT)


OLD:

Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400

NEW:

Date: Wed,20 Sep 1995 00:19:00 -0400 (EDT)


OLD:

Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400

NEW:

Date: Wed,20 Sep 1995 00:21:00 -0400 (EDT)


OLD:

Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400

NEW:

Date: Wed,20 Sep 1995 00:22:00 -0400 (EDT)


In section 8.4:

OLD:

Date: Wed,20 Sep 1995 00:18:00 (EDT)-0400

NEW:

Date: Wed,20 Sep 1995 00:18:00 -0400 (EDT)


OLD:

Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400

NEW:

Date: Wed,20 Sep 1995 00:19:00 -0400 (EDT)


OLD:

Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400

NEW:

Date: Wed,20 Sep 1995 00:21:00 -0400 (EDT)


OLD:

Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400

NEW:

Date: Wed,20 Sep 1995 00:22:00 -0400 (EDT)

RFC 3300, "Internet Official Protocol Standards", November 2002

Note: This RFC has been obsoleted by RFC 3600

Source of RFC: INDEPENDENT

Errata ID: 298
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Siegfried Schmitt
Date Reported: 2002-11-15

Section 3.2 says:

   --------   Internet Official Protocol Standards                3003 1*

It should say:

   --------   Internet Official Protocol Standards                3300 1*

Errata ID: 1579
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Randy Bush
Date Reported: 2008-10-27
Verifier Name: Nevil Brownlee
Date Verified: 2010-04-03

Section 4 says:

4.  Security Coniderations

It should say:

4.  Security Considerations

Errata ID: 2780
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-04-17
Verifier Name: Nevil Brownlee
Date Verified: 2012-11-05

Section TOC says:

2.  Contacts . . . . . . . . . . . . . . . . . . . . . . . . .   2

It should say:

2.  Resources  . . . . . . . . . . . . . . . . . . . . . . . .   2

RFC 3304, "Middlebox Communications (midcom) Protocol Requirements", August 2002

Source of RFC: midcom (tsv)

Errata ID: 983
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vishwas Manral
Date Reported: 2007-05-25
Verifier Name: RFC Editor
Date Verified: 2007-11-02

Section 5 says:

   [MCFW]    Srisuresh, S., Kuthan, J., Rosenberg, J., Molitor, A. and
             A.  Rayhan, "Middlebox communication architecture and
             framework", RFC 3303, Date.*

It should say:

   [MCFW]    Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and
             A.  Rayhan, "Middlebox communication architecture and
             framework", RFC 3303, August 2002.

Notes:

from pending

RFC 3305, "Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations", August 2002

Source of RFC: Legacy
Area Assignment: app

Errata ID: 297
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tom Petch
Date Reported: 2005-10-10
Verifier Name: Peter Saint-Andre
Date Verified: 2010-11-11

Section 3.2.1 says:

*  'issn' defined by "Using The ISSN as URN within an ISSN-URN
         Namespace" (RFC 3043) [4]

It should say:

*  'issn' defined by "Using The ISSN as URN within an ISSN-URN
         Namespace" (RFC 3044) [4]

RFC 3315, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", July 2003

Note: This RFC has been obsoleted by RFC 8415

Note: This RFC has been updated by RFC 4361, RFC 5494, RFC 6221, RFC 6422, RFC 6644, RFC 7083, RFC 7227, RFC 7283, RFC 7550

Source of RFC: dhc (int)

Errata ID: 294
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Hideshi Enokihara
Date Reported: 2006-06-29
Verifier Name: Ralph Droms
Date Verified: 2013-03-09

Section 20.1.2 says:

   The relay agent copies the source address from the IP datagram in
   which the message was received from the client into the peer-address
   field in the Relay-forward message and sets the hop-count field to
   the value of the hop-count field in the received message incremented
   by 1.

It should say:

   The relay agent copies the source address from the IP datagram in
   which the message was received from the relay agent into the peer-address
   field in the Relay-forward message and sets the hop-count field to
   the value of the hop-count field in the received message incremented
   by 1.

Notes:

Errata ID: 2472
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ole Troan
Date Reported: 2010-08-17
Verifier Name: Ralph Droms
Date Verified: 2013-03-09

Section 17.2.2 says:

If the server will not assign any addresses to any IAs in a
subsequent Request from the client, the server MUST send an Advertise
message to the client that includes only a Status Code option with
code NoAddrsAvail and a status message for the user, a Server
Identifier option with the server's DUID, and a Client Identifier
option with the client's DUID.

It should say:

If the server will not assign any addresses to an IA in a
subsequent Request from the client, the server MUST send an Advertise
message to the client that includes the IA containing a Status Code 
option with status code NoAddrsAvail and a status message for the 
user, a Server Identifier option with the server's DUID, and a Client 
Identifier option with the client's DUID. The server SHOULD include 
other stateful IA options (like IA_PD) and other configuration options 
in the Advertise message.

Errata ID: 2471
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ole Troan
Date Reported: 2010-08-17
Verifier Name: Ralph Droms
Date Verified: 2013-03-09

Section 17.1.3 says:

The client MUST ignore any Advertise message that includes a Status
Code option containing the value NoAddrsAvail, with the exception
that the client MAY display the associated status message to the
user.

It should say:

The client MUST ignore any IAs in an Advertise message that includes 
a Status Code option containing the value NoAddrsAvail, with the 
exception that the client MAY display the associated status message 
to the user.

Errata ID: 1373
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Robert Marks
Date Reported: 2008-03-19
Verifier Name: Ralph Droms
Date Verified: 2013-03-09

Section 22.17 says:

      option-code          OPTION_VENDOR_OPTS (17)

      option-len           4 + length of option-data field

      enterprise-number    The vendor's registered Enterprise Number as
                           registered with IANA [6].

      option-data          An opaque object of option-len octets,
                           interpreted by vendor-specific code on the
                           clients and servers

It should say:

      option-code          OPTION_VENDOR_OPTS (17)

      option-len           4 + length of option-data field

      enterprise-number    The vendor's registered Enterprise Number as
                           registered with IANA [6].

      option-data          An opaque object,
                           interpreted by vendor-specific code on the
                           clients and servers

Notes:

option-len is defined to be the size of the option-data + 4. Thus the size of option-data cannot option-len, but is actually option-len - 4.

Errata ID: 2928
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Leaf Yeh
Date Reported: 2011-08-09
Verifier Name: Ralph Droms
Date Verified: 2013-03-09

Section 17.2.1 says:

   For example, if the administrative policy for the server is
   that it may only respond to a client that is willing to accept a
   Reconfigure message, if the client indicates with a Reconfigure
   Accept option in the Solicit message that it will not accept a
   Reconfigure message, the servers discard the Solicit message.

It should say:

   For example, if the administrative policy for the server is 
   that it may only respond to a client that is willing to accept a 
   Reconfigure message, if the client does not include a Reconfigure 
   Accept option (see section 22.20) in the Solicit message, the 
   servers discard the Solicit message.

Errata ID: 1815
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michelle Cotton
Date Reported: 2009-07-22
Verifier Name: Brian Haberman
Date Verified: 2012-07-29

Section 26 says:

 [6]  IANA.  Private Enterprise Numbers.
        http://www.iana.org/assignments/enterprise-numbers.html.

It should say:

 [6]  IANA.  Private Enterprise Numbers.
        http://www.iana.org/assignments/enterprise-numbers

Notes:

The URL for the enterprise numbers registry is incorrect.

Errata ID: 3577
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Pablo Armando
Date Reported: 2013-03-31
Verifier Name: Ted Lemon
Date Verified: 2013-04-02

Section 9.3 says:

An example DUID of this type might look like this:

 +---+---+---+---+---+---+---+---+
 | 0 | 2 | 0 | 0 | 0 |  9| 12|192|
 +---+---+---+---+---+---+---+---+
 |132|221| 3 | 0 | 9 | 18|
 +---+---+---+---+---+---+

This example includes the two-octet type of 2, the Enterprise Number
(9), followed by eight octets of identifier data
(0x0CC084D303000912).

It should say:

An example DUID of this type might look like this:

 +---+---+---+---+---+---+---+---+
 | 0 | 2 | 0 | 0 | 0 |  9| 12|192|
 +---+---+---+---+---+---+---+---+
 |132|211| 3 | 0 | 9 | 18|
 +---+---+---+---+---+---+

This example includes the two-octet type of 2, the Enterprise Number
(9), followed by eight octets of identifier data
(0x0CC084D303000912).

Notes:

0xD3 is 211 decimal, not 221.

I am assuming that this number is the correct one: 0x0CC084D303000912

RFC 3325, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", November 2002

Note: This RFC has been updated by RFC 5876, RFC 8217

Source of RFC: sip (rai)

Errata ID: 3744
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Brett Tate
Date Reported: 2013-10-08
Verifier Name: Richard Barnes
Date Verified: 2014-02-15

Section 9.1 says:

A P-Asserted-Identity header field value MUST consist of exactly one
name-addr or addr-spec.

It should say:

A P-Asserted-Identity header field value MUST consist of exactly one
name-addr or addr-spec.  If the URI contains a comma, the URI MUST
be enclosed in angle brackets (< and >).

Notes:

While the P-Asserted-Identity and P-Preferred-Identity header fields have an ambiguity only for "," (not for ";" and "?"), we note that usage of ";" and "?" also must be enclosed in angle brackets to preserve consistency with the RFC 3261 section 20 bracket rule.

Errata ID: 3894
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Richard Barnes
Date Reported: 2014-02-15
Verifier Name: Richard Barnes
Date Verified: 2014-02-15

Section 9.2 says:

A P-Preferred-Identity header field value MUST consist of exactly one
name-addr or addr-spec.

It should say:

A P-Preferred-Identity header field value MUST consist of exactly one
name-addr or addr-spec.  If the URI contains a comma, the URI MUST
be enclosed in angle brackets (< and >).

Notes:

While the P-Asserted-Identity and P-Preferred-Identity header fields have an ambiguity only for "," (not for ";" and "?"), we note that usage of ";" and "?" also must be enclosed in angle brackets to preserve consistency with the RFC 3261 section 20 bracket rule.

Errata ID: 4202
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Giovanni Signoriello
Date Reported: 2014-12-17
Verifier Name: Orie Steele
Date Verified: 2024-04-01

Section 10.2 says:

P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@vovida.org>

It should say:

P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@cisco.com>

Notes:

May be an editorial error in the message F4, section 10.2.
In that message is added the P-Asserted-Identity with the SIP URI sip:fluffy@vovida.org
I suppose it should be cisco.com and not vovida.com.
Thank you.

Errata ID: 5499
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Richard Phernambucq
Date Reported: 2018-09-20
Verifier Name: Orie Steele
Date Verified: 2024-03-29

Section 10 says:

   * F4   proxy.cisco.com -> proxy.pstn.net (trusted)

   INVITE sip:+14085551212@proxy.pstn.net SIP/2.0
   Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-124
   Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-abc

It should say:

   * F4   proxy.cisco.com -> proxy.pstn.net (trusted)

   INVITE sip:+14085551212@proxy.pstn.net SIP/2.0
   Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-abc
   Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-124

Notes:

As per RFC 3261, chapter 16.6, step 8:
The proxy MUST insert a Via header field value into the copy before the existing Via header field values.

The order of Via headers should be reversed. This applies to the following message examples:
chapter 10.1: F4, F5
chapter 10.2: F4, F5, F6

Text and examples in RFC3261 Section 20.42 supports the argument that the order is reversed.

RFC 3329, "Security Mechanism Agreement for the Session Initiation Protocol (SIP)", January 2003

Note: This RFC has been updated by RFC 8996

Source of RFC: sip (rai)

Errata ID: 3799
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Hadriel Kaplan
Date Reported: 2013-11-13
Verifier Name: Gonzalo Camarillo
Date Verified: 2013-11-14

Section Appendix A says:

spivalue           = 10DIGIT; 0 to 4294967295

It should say:

spivalue           = 1*10DIGIT; 0 to 4294967295

Notes:

The number string does not have to have 10 digit characters if the number is not 10 digits in length.

RFC 3339, "Date and Time on the Internet: Timestamps", July 2002

Source of RFC: impp (app)

Errata ID: 4110
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Derek P. Moore
Date Reported: 2014-09-12
Verifier Name: Barry Leiba
Date Verified: 2014-09-29

Section Appendix A says:

   ISO 8601 also requires (in section 5.3.1.3) that a decimal fraction
   be proceeded by a "0" if less than unity.  Annex B.2 of ISO 8601
   gives examples where the decimal fractions are not preceded by a "0".
   This grammar assumes section 5.3.1.3 is correct and that Annex B.2 is
   in error.

It should say:

   ISO 8601/Cor1:1991 also requires (in section 5.3.1.3) that a decimal
   fraction be proceeded by "00" if less than unity.

Notes:

ISO 8601:1988/Cor 1:1991 says:

"Subclause 5.3.1.3
"Last line, delete “shall be preceded by a zero” and insert “shall be preceded by two zeros in accordance with 4.6” "

The RFC3339 grammar never allowed just one zero ("0") preceding the fraction and has always been compliant with ISO 8601/Cor 1:1991.

----- Note from the RFC authors -----
There are interpretations of ISO 8601 under which section 5.3.1.3 and Annex B.2 are entirely consistent, and the implication that they are in conflict can cause confusion.

----- Note from the Area Director -----
There is a newer version of the ISO spec, ISO 8601:2004. That version came after this RFC, so it cannot be a definitive reference with respect to this RFC, but readers should be aware of the newer version.

Errata ID: 293
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tony Finch
Date Reported: 2005-05-26

Section 5.1 says:

   The presence of optional punctuation would violate this characteristic.

It should say:

   If the format allows optional punctuation or white space then this 
   characteristic can be violated.

Notes:

In Appendix A, it says:
Time:

time-hour = 2DIGIT ; 00-24
time-minute = 2DIGIT ; 00-59
time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on
; leap-second rules
time-fraction = ("," / ".") 1*DIGIT
time-numoffset = ("+" / "-") time-hour [[":"] time-minute]
time-zone = "Z" / time-numoffset

timeopt-hour = "-" / (time-hour [":"])
timeopt-minute = "-" / (time-minute [":"])

timespec-hour = time-hour [[":"] time-minute [[":"] time-second]]
timespec-minute = timeopt-hour time-minute [[":"] time-second]
timespec-second = "-" timeopt-minute time-second
timespec-base = timespec-hour / timespec-minute / timespec-second

time = timespec-base [time-fraction] [time-zone]

iso-date-time = date "T" time
It should say:
Time:

time-hour = 2DIGIT ; 00-23
time-minute = 2DIGIT ; 00-59
time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on
; leap-second rules
time-fraction = ("," / ".") 1*DIGIT
time-numoffset = ("+" / "-") time-hour [[":"] time-minute]
time-zone = "Z" / time-numoffset

timeopt-hour = "-" / (time-hour [":"])
timeopt-minute = "-" / (time-minute [":"])

timespec-hour = time-hour [[":"] time-minute [[":"] time-second]]
timespec-minute = timeopt-hour time-minute [[":"] time-second]
timespec-second = "-" timeopt-minute time-second
timespec-base = timespec-hour / timespec-minute / timespec-second
/ timespec-midnight
timespec-midnight = "24" [[":"] "00" [[":"] "00"]]

time = timespec-base [time-fraction] [time-zone]

iso-date-time = date "T" time

In the third paragraph of Appendix A, it states "ISO 8601 is not clear on
whether an hour of 24 is permissible only if minutes and seconds are 0.
This assumes that an hour of 24 is permissible in any context."

This is clarified in the 2000 edition which says:
5.3 Time of the day

The representation of the hour by [24] is only allowed to indicate
midnight, see 5.3.2.
That would result in the following ABNF change:
time-hour = 2DIGIT ; 00-23
and additions:
timespec-midnight = "24" [[":"] "00" [[":"] "00"]]
timespec-base =/ timespec-midnight

Errata ID: 1584
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Roberto Javier Godoy
Date Reported: 2008-11-03
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-20

Section Appendix A says:

Note that due to ambiguities in ISO 8601, some interpretations had to
be made.  First, ISO 8601 is not clear if mixtures of basic and
extended format are permissible.  This grammar permits mixtures. 

It should say:

This grammar permits mixtures of basic and extended format.

Notes:

ISO 8601:2000 section 5.4.2 reads:
d) the expression shall either be completely in basic format, in which case the minimum number of separators necessary for the required expression is used, or completely in extended format, in which case additional separators shall be used in accordance with 5.2 and 5.3.

(There is similar text in section 4.3.3 of ISO 8601:2004)

Errata ID: 3710
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Thomas B
Date Reported: 2013-08-26
Verifier Name: Barry Leiba
Date Verified: 2013-08-26

Section 6 says:

[IERS] International Earth Rotation Service Bulletins,
       <http://hpiers.obspm.fr/eop-pc/products/bulletins.html>.

It should say:

[IERS] International Earth Rotation Service Bulletins,
       <http://hpiers.obspm.fr/eop-pc/products/bulletins
        /bulletins.html>.

Notes:

Original link is missing a "bulletins/" before the terminal "bulletins.html".
This leads to a 404

RFC 3345, "Border Gateway Protocol (BGP) Persistent Route Oscillation Condition", August 2002

Source of RFC: idr (rtg)

Errata ID: 3787
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramakrishna DTV
Date Reported: 2013-11-05
Verifier Name: Stewart Bryant
Date Verified: 2014-01-16

Section 2.1 says:

      1) Ra has the following installed in its BGP table, with the path
         learned via AS2 marked best:

It should say:

      1) Ra has the following installed in its BGP table, with the path
         learned via AS10 marked best:

Notes:

The above text is related to a discussion of topology depicted in Figure 1. This figure does not have AS2 at all. The text should refer to AS10 instead.

RFC 3348, "The Internet Message Action Protocol (IMAP4) Child Mailbox Extension", July 2002

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 2020
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Barry Leiba
Date Reported: 2010-01-26
Verifier Name: Alexey Melnikov
Date Verified: 2010-02-10

Section 3 says:

   In some instances a server that supports the CHILDREN extension MAY
   NOT be able to determine whether a mailbox has children.

It should say:

   In some instances a server that supports the CHILDREN extension might
   not be able to determine whether a mailbox has children.

Notes:

The "may not" in this sentence is not normative text, but is just a statement of fact. It should not be rendered as an RFC 2119 term.

RFC 3364, "Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6)", August 2002

Source of RFC: dnsext (int)

Errata ID: 1680
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Klensin
Date Reported: 2009-02-09
Verifier Name: Brian Haberman
Date Verified: 2012-05-01

Section "Bitlabels" says:

addresses, it proposes to use a new kind of DNS label (a "bit label")
to represent binary addresses directly in the DNS.

It should say:

addresses, it proposes to use a new kind of DNS label (a "bit label"), 
specified in [RFC2673],
to represent binary addresses directly in the DNS.

*** RFC 2673 should also appear in the References section.***

Notes:

This document is listed as updating RFC 2673. That claim is actually dubious, since it simply explains why one particular application of 2673 may not be appropriate, an application that is not even mentioned in 2673 itself. But, if it does actually update 2673, then it should be possible for the reader to deduce how the two document interact without extensive detective work.

An alternative fix would be to remove the entry indicating updating of 2673 from the header of this document and corresponding indexes and references -- what this actually updates is 2874, which specifies a particular application of 2673.

RFC 3369, "Cryptographic Message Syntax (CMS)", August 2002

Note: This RFC has been obsoleted by RFC 3852

Source of RFC: smime (sec)

Errata ID: 291
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2003-03-03

Several object identifiers (OIDs) have been omitted from the ASN.1 module in section 12.1; however, these OIDs are fully discussed in the body of the document. On page 46 of RFC 3369, the following object identifiers need to be inserted before the end o

       -- Content Type Object Identifiers
 
       id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6 }
 
       id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }
 
       id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }
 
       id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }
 
       id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 }
 
       id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 }
 
       id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 
          ct(1) 2 }

Errata ID: 292
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2003-01-23

Section 13 says:

   [CMSALG]    Housley, R., "Cryptographic Message Syntax (CMS)
               Algorithms", RFC 3269, August 2002.

It should say:

   [CMSALG]    Housley, R., "Cryptographic Message Syntax (CMS)
               Algorithms", RFC 3370, August 2002.

Errata ID: 290
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2004-03-12

Section 12.2 says:

    AttributeCertificateVersion1
        { iso(1) member-body(2) us(840) rsadsi(113549)
          pkcs(1) pkcs-9(9) smime(16) modules(0) v1AttrCert(15) }

    DEFINITIONS EXPLICIT TAGS ::=
    BEGIN

Notes:

The tagging should be EXPLICIT instead of IMPLICIT.

RFC 3370, "Cryptographic Message Syntax (CMS) Algorithms", August 2002

Note: This RFC has been updated by RFC 5754, RFC 8702

Source of RFC: smime (sec)

Errata ID: 289
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Henning Schulzrinne
Date Reported: 2003-05-13

Section 8 says:

   [CMS]       Housley, R., "Cryptographic Message Syntax", RFC 3269,
               August 2002.

It should say:

   [CMS]       Housley, R., "Cryptographic Message Syntax", RFC 3369,
               August 2002.

RFC 3372, "Session Initiation Protocol for Telephones (SIP-T): Context and Architectures", September 2002

Source of RFC: sipping (rai)

Errata ID: 288

Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Feng Zhang
Date Reported: 2002-09-22
Report Text:

References to Figures 3, 5, and 7 should refer to Figures 2, 3, and 4, respectively.

---

RFC 3376, "Internet Group Management Protocol, Version 3", October 2002

Note: This RFC has been updated by RFC 4604

Source of RFC: idmr (rtg)

Errata ID: 1501
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dave Thaler
Date Reported: 2008-09-08
Verifier Name: Adrian Farrel
Date Verified: 2013-05-11

The header says:

Network Working Group                                            B. Cain
Request for Comments: 3376                               Cereva Networks
Obsoletes: 2236                                               S. Deering
Category: Standards Track                                    I. Kouvelas
                                                           Cisco Systems
                                                               B. Fenner
                                                    AT&T Labs - Research
                                                          A. Thyagarajan
                                                                Ericsson
                                                            October 2002

It should say:

Network Working Group                                            B. Cain
Request for Comments: 3376                               Cereva Networks
Updates: 2236                                                 S. Deering
Category: Standards Track                                    I. Kouvelas
                                                           Cisco Systems
                                                               B. Fenner
                                                    AT&T Labs - Research
                                                          A. Thyagarajan
                                                                Ericsson
                                                            October 2002

Notes:

RFC 3376 does not completely replace RFC 2236, so it should say "updates" instead of "obsoletes". Specifically, to have a compliant implementation of RFC 3376 section 4, one MUST understand and implement the "Version 2 Membership Report" and "Version 2 Leave Group" messages. This is why RFC 2236 is listed as a normative reference of RFC 3376.

Errata ID: 7339
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alvaro Retana
Date Reported: 2023-02-07
Verifier Name: John Scudder
Date Verified: 2023-02-08

Section Abstract says:

This document obsoletes RFC 2236.

It should say:

This document updates RFC 2236.

Notes:

Report EID 1501 has been Verified to update the information in the document's header: from Obsoletes to Updates.

This sentence in the abstract should be corrected for the same reason.

RFC 3377, "Lightweight Directory Access Protocol (v3): Technical Specification", September 2002

Note: This RFC has been obsoleted by RFC 4510

Source of RFC: ldapbis (app)

Errata ID: 287

Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jeff Hodges
Date Reported: 2002-09-26
Report Text:

This document updates RFCs 2251-2256, 2829 and 2830.

---

RFC 3380, "Internet Printing Protocol (IPP): Job and Printer Set Operations", September 2002

Source of RFC: ipp (app)

Errata ID: 5430
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Sweet
Date Reported: 2018-07-18
Verifier Name: Alexey Melnikov
Date Verified: 2018-07-26

Section 10 says:

      5. if the "job-message-from-operator" Printer Description
         attribute is supported (see [RFC2911], 4.3.16), then it MUST be
         settable.

It should say:

      5. if the "job-message-from-operator" Job Description
         attribute is supported (see [RFC2911], 4.3.16), then it MUST be
         settable.

Notes:

"job-message-from-operator" is an attribute for Jobs, not Printers.

RFC 3381, "Internet Printing Protocol (IPP): Job Progress Attributes", September 2002

Note: This RFC has been obsoleted by RFC 8011

Source of RFC: ipp (app)

Errata ID: 2983
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Sweet
Date Reported: 2011-10-03
Verifier Name: Peter Saint-Andre
Date Verified: 2011-11-12

Section 4.1 says:

4.1 job-collation-type (type2 enum)

   Job Collation includes sheet collation and document collation.  Sheet
   collation is defined to be the ordering of sheets within a document
   copy.  Document collation is defined to be the ordering of document
   copies within a multi-document job.  The value of the "job-
   collation-type" is affected by the value of the "sheet-collate" Job
   Template attribute (see section 3.1), if supplied and supported.

   The Standard enum values are:

      '1' 'other':  not one of the defined values

      '2' 'unknown':  the collation type is unknown

      '3' 'uncollated-sheets':  No collation of the sheets within each
                    document copy, i.e., each sheet of a document that
                    is to produce multiple copies, is replicated before
                    the next sheet in the document is processed and
                    stacked.  If the device has an output bin collator,
                    the 'uncollated-sheets(3)' value may actually

It should say:

4.1 job-collation-type (type2 enum|other|unknown)

   Job Collation includes sheet collation and document collation.  Sheet
   collation is defined to be the ordering of sheets within a document
   copy.  Document collation is defined to be the ordering of document
   copies within a multi-document job.  The value of the "job-
   collation-type" is affected by the value of the "sheet-collate" Job
   Template attribute (see section 3.1), if supplied and supported.

   The Standard enum values are:

      '3' 'uncollated-sheets':  No collation of the sheets within each
                    document copy, i.e., each sheet of a document that
                    is to produce multiple copies, is replicated before
                    the next sheet in the document is processed and
                    stacked.  If the device has an output bin collator,
                    the 'uncollated-sheets(3)' value may actually

Notes:

"other" and "unknown" are out-of-band values, per RFC 2911 section 4.1:

Note: SNMP MIBs use '2' for 'unknown' which corresponds to the IPP
"out-of-band" value 'unknown'. See the description of the "out-of-
band" values at the beginning of Section 4.1. Therefore, attributes
of type 'enum' start at '3'.

RFC 3385, "Internet Protocol Small Computer System Interface (iSCSI) Cyclic Redundancy Check (CRC)/Checksum Considerations", September 2002

Source of RFC: Legacy

Errata ID: 286
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Vicente Cavanna
Date Reported: 2002-11-18

Section 8.1 says:

   ///////////////////////////////////////////////////////////////////////
   // File:  CRC32_D1.v
   // Date:  Mon Nov 18 18:51:31 2002
   //
   // Copyright (C) 1999 Easics NV.
   // This source file may be used and distributed without restriction
   // provided that this copyright statement is not removed from the file
   // and that any derivative work contains the original copyright notice
   // and the associated disclaimer.
   //
   // THIS SOURCE FILE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS
   // OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
   // WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
   //
   // Purpose: Verilog module containing a synthesizable CRC function
   //   * polynomial: p(0 to 32) := "100000101111011000111011011110001"
   //   * data width: 1
   //
   // Info: jand@easics.be (Jan Decaluwe)
   //       http://www.easics.com
   ///////////////////////////////////////////////////////////////////////


   module CRC32_D1;
 
     // polynomial: p(0 to 32) := "100000101111011000111011011110001"
     // data width: 1
     function [31:0] nextCRC32_D1;

       input Data;
       input [31:0] CRC;
 
       reg [0:0] D;
       reg [31:0] C;
       reg [31:0] NewCRC;

     begin

       D[0] = Data;
       C = CRC;

       NewCRC[0] = D[0] ^ C[31];
       NewCRC[1] = C[0];
       NewCRC[2] = C[1];
       NewCRC[3] = C[2];
       NewCRC[4] = C[3];
       NewCRC[5] = C[4];
       NewCRC[6] = D[0] ^ C[5] ^ C[31];
       NewCRC[7] = C[6];
       NewCRC[8] = D[0] ^ C[7] ^ C[31];
       NewCRC[9] = D[0] ^ C[8] ^ C[31];
       NewCRC[10] = D[0] ^ C[9] ^ C[31];
       NewCRC[11] = D[0] ^ C[10] ^ C[31];
       NewCRC[12] = C[11];
       NewCRC[13] = D[0] ^ C[12] ^ C[31];
       NewCRC[14] = D[0] ^ C[13] ^ C[31];
       NewCRC[15] = C[14];
       NewCRC[16] = C[15];
       NewCRC[17] = C[16];
       NewCRC[18] = D[0] ^ C[17] ^ C[31];
       NewCRC[19] = D[0] ^ C[18] ^ C[31];
       NewCRC[20] = D[0] ^ C[19] ^ C[31];
       NewCRC[21] = C[20];
       NewCRC[22] = D[0] ^ C[21] ^ C[31];
       NewCRC[23] = D[0] ^ C[22] ^ C[31];
       NewCRC[24] = C[23];
       NewCRC[25] = D[0] ^ C[24] ^ C[31];
       NewCRC[26] = D[0] ^ C[25] ^ C[31];
       NewCRC[27] = D[0] ^ C[26] ^ C[31];
       NewCRC[28] = D[0] ^ C[27] ^ C[31];
       NewCRC[29] = C[28];
       NewCRC[30] = C[29];
       NewCRC[31] = C[30];

       nextCRC32_D1 = NewCRC;

     end

     endfunction

   endmodule

RFC 3389, "Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)", September 2002

Source of RFC: avt (rai)

Errata ID: 285
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Magnus Westerlund
Date Reported: 2004-01-22

 

In section 5.1, it says:

         m=audio 49230 RTP/AVP 101 102
         a=rtpmap:101 G7221/16000
         a=fmtp:121 bitrate=24000
         a=rtpmap:102 CN/16000

It should say:

         m=audio 49230 RTP/AVP 101 102
         a=rtpmap:101 G7221/16000
         a=fmtp:101 bitrate=24000
                ^^^
         a=rtpmap:102 CN/16000

RFC 3390, "Increasing TCP's Initial Window", October 2002

Source of RFC: tsvwg (wit)

Errata ID: 4569
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2015-12-22
Verifier Name: Martin Stiemerling
Date Verified: 2016-01-12

Section 8.1 says:

   A second set of experiments explored TCP performance over dialup
   modem links.  In experiments over a 28.8 bps dialup channel [All97a,
   AHO98], a four-segment initial window decreased the transfer time of
   a 16KB file by roughly 10%, with no accompanying increase in the drop
   rate.  A simulation study [RFC2416] investigated the effects of using
   a larger initial window on a host connected by a slow modem link and
   a router with a 3 packet buffer.  The study concluded that for the
   scenario investigated, the use of larger initial windows was not
   harmful to TCP performance.

It should say:

   A second set of experiments explored TCP performance over dialup
   modem links.  In experiments over a 28.8 kbps dialup channel [All97a,
   AHO98], a four-segment initial window decreased the transfer time of
   a 16KB file by roughly 10%, with no accompanying increase in the drop
   rate.  A simulation study [RFC2416] investigated the effects of using
   a larger initial window on a host connected by a slow modem link and
   a router with a 3 packet buffer.  The study concluded that for the
   scenario investigated, the use of larger initial windows was not
   harmful to TCP performance.

Notes:

Error bit rate - kbps instead of bps.

Errata ID: 4583
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Joe Touch
Date Reported: 2016-01-06
Verifier Name: Martin Stiemerling
Date Verified: 2016-04-03

Section 1. says:

   This increased initial window is optional: a TCP MAY start with a
   larger initial window.  However, we expect that most general-purpose
   TCP implementations would choose to use the larger initial congestion
   window given in equation (1) above.

It should say:

   This increased initial window is optional: a TCP MAY start with a
   smaller initial window.  However, we expect that most general-purpose
   TCP implementations would choose to use the larger initial congestion
   window given in equation (1) above.

Notes:

The MAY allows use of values smaller than this document allows, not larger.

RFC 3393, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", November 2002

Source of RFC: ippm (ops)

Errata ID: 6981
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2022-05-26
Verifier Name: RFC Editor
Date Verified: 2022-06-16

Section 2.7.1 says:

      It is the claim here (see remarks in section 1.3) that the effects
      of skew are rather small over the time scales that we are
      discussing here, since temperature variations in a system tend to
      be slow relative to packet inter-transmission times and the range
      of drift is so small.

It should say:

      It is the claim here (see remarks in section 1.4) that the effects
      of skew are rather small over the time scales that we are
      discussing here, since temperature variations in a system tend to
      be slow relative to packet inter-transmission times and the range
      of drift is so small.

Notes:

Incorrect reference - 1.3 instead 1.4

RFC 3394, "Advanced Encryption Standard (AES) Key Wrap Algorithm", September 2002

Source of RFC: smime (sec)

Errata ID: 3671
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lucas Garron
Date Reported: 2013-06-26
Verifier Name: Sean Turner
Date Verified: 2013-08-14

Section 2.2.3.1 says:

If unwrapping produces A[0] any other value,

It should say:

If unwrapping produces A[0] equal to any other value,

Notes:

This resembles a copy-paste typo, where the last portion of "If unwrapping produces A[0]" was not removed in the second of two sentences.

I edited this based on comments from the authors.

Errata ID: 5777
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Charles Timko
Date Reported: 2019-07-10
Verifier Name: Roman Danyliw
Date Verified: 2022-01-20

Section 2.2.1 says:

   1) Initialize variables.

       Set A0 to an initial value (see 2.2.3)
       For i = 1 to n
            R[0][i] = P[i]

It should say:

   1) Initialize variables.

       Set A[0] to an initial value (see 2.2.3)
       For i = 1 to n
            R[0][i] = P[i]

Notes:

An array subscript notation should be used for A[]

Errata ID: 6942
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Samuel Lee
Date Reported: 2022-04-25
Verifier Name: Paul Wouters
Date Verified: 2024-01-22

Section 2.1 says:

R[i]          An array of 64-bit registers where
                       i = 0, 1, 2, ..., n
A[t], R[i][t] The contents of registers A and R[i] after encryption
                       step t.

It should say:

R[i]          An array of 64-bit registers where
                       i = 1, 2, ..., n
A[t], R[t][i] The contents of registers A and R[i] after encryption
                       step t.

Notes:

1) There are n 64-bit registers indexed R[1] to R[n] in the algorithms in section 2.2.
2) The notation of the algorithms in section 2.2 dereference R[][] using the step as the first index, and the index of the register from 1 to n as the second index

Paul Wouters(AD): There was some talk of a better fix, but that would require new text for whole sections, which is more that what should be done in an errata.

RFC 3401, "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", October 2002

Source of RFC: urn (app)

Errata ID: 283
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Olaf M. Kolkman
Date Reported: 2005-12-29
Verifier Name: Alexey Melnikov
Date Verified: 2010-04-02

Section 5 says:

Part Three: The Domain Name System (DNS) Database" (RFC 3402) [1]

It should say:

Part Three: The Domain Name System (DNS) Database" (RFC 3403) [2]

RFC 3404, "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", October 2002

Source of RFC: urn (app)

Errata ID: 282
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2006-10-05

Section 4.5 says:

   See the
   Additional Information Processing section of RFC 3404 for more
   information on NAPTR records and the Additional Information section
   of a DNS response packet.

It should say:

   See the
   Additional Information Processing section of RFC 3403 for more
   information on NAPTR records and the Additional Information section
   of a DNS response packet.

Notes:

wrong reference to RFC 3404 (must be RFC 3403)

Errata ID: 787
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2006-10-05

Section 5.1 says:

   There is opportunity for significant optimization here.  RFC 3404
   defines that Additional Information section may be available.  In
   this case the the SRV records may be returned as additional
   information for terminal NAPTRs lookups (as well as the A records for
   those SRVs).  This is a significant optimization.

It should say:

    There is opportunity for significant optimization here.  RFC 3403
    defines that Additional Information section may be available.  In
    this case the the SRV records may be returned as additional
    information for terminal NAPTRs lookups (as well as the A records for
    those SRVs).  This is a significant optimization.

Notes:

wrong reference to RFC 3404 (must be RFC 3403)

from pending

RFC 3405, "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", October 2002

Note: This RFC has been updated by RFC 8958

Source of RFC: urn (app)

Errata ID: 2687
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Joe Abley
Date Reported: 2011-01-20
Verifier Name: Alexey Melnikov
Date Verified: 2011-01-20

Section 8 says:

         To: register@URI.ARPA
         From: The IETF URN Working Group

         Key: urn
         Authority: RFC2141
         Record: urn     IN NAPTR 0 0 "" "" "/^urn:([^:]+)/\\2/i" .

It should say:

         To: register@URI.ARPA
         From: The IETF URN Working Group

         Key: urn
         Authority: RFC2141
         Record: urn     IN NAPTR 0 0 "" "" "/^urn:([^:]+)/\\1/i" .

Notes:

The uncorrected, original text contains a regular expression which is invalid -- it includes a back-reference \2 with no corresponding second enclosure. The correction is to make the back-reference \1, i.e. a reference to the single enclosure present in the regular expression.

Errata ID: 2688
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Joe Abley
Date Reported: 2011-01-20
Verifier Name: Alexey Melnikov
Date Verified: 2011-01-20

Section 4 says:

      http    IN NAPTR 100 100 "" ""  "/http:\\/\\/([^\\/:]+)/\\2/i" .

It should say:

      http    IN NAPTR 100 100 "" ""  "/http:\\/\\/([^\\/:]+)/\\1/i" .

Notes:

The uncorrected, original text contains a regular expression which is invalid -- it includes a back-reference (\2) with no corresponding second enclosure. The correction is to make the back-reference \1, i.e. a reference to the single enclosure present in the regular expression.

RFC 3406, "Uniform Resource Names (URN) Namespace Definition Mechanisms", October 2002

Note: This RFC has been obsoleted by RFC 8141

Source of RFC: urn (app)

Errata ID: 1444
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Frank Ellermann
Date Reported: 2008-06-14
Verifier Name: Alexey Melnikov
Date Verified: 2010-04-02

Section 4.3 says:

   Registrations may be revised by updating the RFC through standard
   IETF RFC update processes (see [RFC2606] for a discussion of IETF
   process).

It should say:

   Registrations may be revised by updating the RFC through standard
   IETF RFC update processes (see [RFC2026] for a discussion of IETF
   process).

Notes:

The references (section 7) list RFC 2026, not RFC 2606, as expected.

RFC 3410, "Introduction and Applicability Statements for Internet-Standard Management Framework", December 2002

Source of RFC: snmpv3 (ops)

Errata ID: 281
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: C. M. Heard
Date Reported: 2003-01-29

Section 10.2 says:

  [15] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
       "Coexistence between Version 1 and Version 2 of the Internet-
       Standard Network Management Framework", RFC 2576, January 1996.

It should say:

  [15] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
       "Coexistence between Version 1 and Version 2 of the Internet-
       Standard Network Management Framework", RFC 1908, January 1996.

RFC 3412, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", December 2002

Note: This RFC has been updated by RFC 5590

Source of RFC: snmpv3 (ops)

Errata ID: 6344
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michel Albert
Date Reported: 2020-11-30
Verifier Name: Robert Wilton
Date Verified: 2024-01-12

Section 4.2.2 says:

The elements of procedure for the dispatching of PDUs depends on the
   value of sendPduHandle.  If the value of sendPduHandle is <none>,
   then this is a request or notification and the procedures specified
   in Section 4.2.2.1 apply.  If the value of snmpPduHandle is not
   <none>, then this is a response and the procedures specified in
   Section 4.2.2.2 apply.

It should say:

The elements of procedure for the dispatching of PDUs depends on the
   value of sendPduHandle.  If the value of sendPduHandle is <none>,
   then this is a request or notification and the procedures specified
   in Section 4.2.2.1 apply.  If the value of sendPduHandle is not
   <none>, then this is a response and the procedures specified in
   Section 4.2.2.2 apply.

Notes:

This seems to be a typo where the word "snmpPduHandle" should be "sendPduHandle".

RFC 3413, "Simple Network Management Protocol (SNMP) Applications", December 2002

Source of RFC: snmpv3 (ops)

Errata ID: 2459
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Ellison
Date Reported: 2010-08-07
Verifier Name: Dan Romascanu
Date Verified: 2010-11-02

Section 4.2.1 says:

           OBJECT snmpNotifyType
           SYNTAX INTEGER {
               trap(1)
           }
           MIN-ACCESS    read-only
           DESCRIPTION
               "Create/delete/modify access is not required.
                Support of the value notify(2) is not required."

It should say:

           OBJECT snmpNotifyType
           SYNTAX INTEGER {
               trap(1)
           }
           MIN-ACCESS    read-only
           DESCRIPTION
               "Create/delete/modify access is not required.
                Support of the value inform(2) is not required."

Notes:

the enumeration value as stated: notify(2)
the enumeration value should be: inform(2)

This appears in section 4.2.1, "Definitions" for the SNMP-NOTIFICATION-MIB spanning the page break between page 54 and 55 and contained within the snmpNotifyBasicCompliance macro.

Errata ID: 279
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Guan Hai Bing
Date Reported: 2002-12-27

Section 3.5.1.1 says:

   (2) If appropriate outgoing management target information cannot be
       found, the proxy forwarder increments the snmpProxyDrops
       counter [RFC1907], and then calls the Dispatcher using the
       returnResponsePdu abstract service interface.

It should say:

   (2) If appropriate outgoing management target information cannot be
       found, the proxy forwarder increments the snmpProxyDrops
       counter [RFC3418], and then calls the Dispatcher using the
       returnResponsePdu abstract service interface. 

Notes:

In Sections 3.2 and 4.1.2:
by [RFC1905]
Should be:
by [RFC3416]

Errata ID: 280
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Eduardo Cardona
Date Reported: 2004-02-20

In Section 4.2.1, page 50, in DESCRIPTION clause of snmpNotifyFilterTable:

       A more complete discussion of notification filtering 
       can be found in section 6. of [SNMP-APPL]." 

It should say:

       A more complete discussion of notification filtering 
       can be found in section 6. of RFC3413." 

Notes:

Additionally, page 52, in DESCRIPTION clause of snmpNotifyFilterType:

filter. A more detailed discussion of the use of this
object can be found in section 6. of [SNMP-APPL]."

It should be:

filter. A more detailed discussion of the use of this
object can be found in section 6. of RFC3413."

RFC 3414, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", December 2002

Note: This RFC has been updated by RFC 5590

Source of RFC: snmpv3 (ops)

Errata ID: 278
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Piotr Bandur
Date Reported: 2003-10-28

Section 6.3.1 says:

   4) Prepend K2 to the result of the step 4 and calculate MD5 digest
      over it according to [RFC1321].  Take the first 12 octets of the
      final digest - this is Message Authentication Code (MAC).

It should say:

   4) Prepend K2 to the result of the step 3 and calculate MD5 digest
      over it according to [RFC1321].  Take the first 12 octets of the
      final digest - this is Message Authentication Code (MAC).

Notes:

In Section 7.3.1:
4) Prepend K2 to the result of the step 4 and calculate SHA digest
over it according to [SHA-NIST]. Take the first 12 octets of
the final digest - this is Message Authentication Code (MAC).
Should be:
4) Prepend K2 to the result of the step 3 and calculate SHA digest
over it according to [SHA-NIST]. Take the first 12 octets of
the final digest - this is Message Authentication Code (MAC).

Errata ID: 7797
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: 李骋昊
Date Reported: 2024-02-05
Verifier Name: RFC Editor
Date Verified: 2024-02-05

Section 1.3 says:

   For these protocols, it not possible to obtain data integrity without
   data origin authentication, nor is it possible to obtain data origin
   authentication without data integrity.  Further, there is no
   provision for data confidentiality without both data integrity and
   data origin authentication.

It should say:

   For these protocols, it is not possible to obtain data integrity without
   data origin authentication, nor is it possible to obtain data origin
   authentication without data integrity.  Further, there is no
   provision for data confidentiality without both data integrity and
   data origin authentication.

Notes:

The original text is incorrect in grammar.

missing "is":
it not > it is not

RFC 3415, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", December 2002

Source of RFC: snmpv3 (ops)

Errata ID: 277
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Guan Hai Bing
Date Reported: 2002-12-27

In Section A.1:

   (a) "system"       (subtree 1.3.6.1.2.1.1)      [RFC3918]
   (b) "snmp"         (subtree 1.3.6.1.2.1.11)     [RFC3918]

It should say:

   (a) "system"       (subtree 1.3.6.1.2.1.1)      [RFC3418]
   (b) "snmp"         (subtree 1.3.6.1.2.1.11)     [RFC3418]

RFC 3416, "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", December 2002

Source of RFC: snmpv3 (ops)

Errata ID: 2757
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mikhail Kulinich
Date Reported: 2011-03-27
Verifier Name: Dan Romascanu
Date Verified: 2011-08-03

Section 3 says:

PDU ::= SEQUENCE {
           request-id INTEGER (-214783648..214783647),

           error-status                -- sometimes ignored
               INTEGER {
                   noError(0),
                   tooBig(1),
                   noSuchName(2),      -- for proxy compatibility
                   badValue(3),        -- for proxy compatibility
                   readOnly(4),        -- for proxy compatibility
                   genErr(5),
                   noAccess(6),
                   wrongType(7),
                   wrongLength(8),
                   wrongEncoding(9),
                   wrongValue(10),
                   noCreation(11),
                   inconsistentValue(12),
                   resourceUnavailable(13),
                   commitFailed(14),
                   undoFailed(15),
                   authorizationError(16),
                   notWritable(17),
                   inconsistentName(18)
               },

           error-index                 -- sometimes ignored
               INTEGER (0..max-bindings),

           variable-bindings           -- values are sometimes ignored
               VarBindList
       }

   BulkPDU ::=                         -- must be identical in
       SEQUENCE {                      -- structure to PDU
           request-id      INTEGER (-214783648..214783647),
           non-repeaters   INTEGER (0..max-bindings),
           max-repetitions INTEGER (0..max-bindings),

           variable-bindings           -- values are ignored
               VarBindList
       }

It should say:

PDU ::= SEQUENCE {
           request-id INTEGER (-2147483648..2147483647),
           error-status                -- sometimes ignored
               INTEGER {
                   noError(0),
                   tooBig(1),
                   noSuchName(2),      -- for proxy compatibility
                   badValue(3),        -- for proxy compatibility
                   readOnly(4),        -- for proxy compatibility
                   genErr(5),
                   noAccess(6),
                   wrongType(7),
                   wrongLength(8),
                   wrongEncoding(9),
                   wrongValue(10),
                   noCreation(11),
                   inconsistentValue(12),
                   resourceUnavailable(13),
                   commitFailed(14),
                   undoFailed(15),
                   authorizationError(16),
                   notWritable(17),
                   inconsistentName(18)
               },

           error-index                 -- sometimes ignored
               INTEGER (0..max-bindings),

           variable-bindings           -- values are sometimes ignored
               VarBindList
       }

   BulkPDU ::=                         -- must be identical in
       SEQUENCE {                      -- structure to PDU
           request-id      INTEGER (-2147483648..2147483647),
           non-repeaters   INTEGER (0..max-bindings),
           max-repetitions INTEGER (0..max-bindings),

           variable-bindings           -- values are ignored
               VarBindList
       }

Notes:

Consider the following dump as a Response to a Get Request:

Received 125 bytes from UDP: [127.0.0.1]:161->[0.0.0.0]
0000: 30 7B 02 01 03 30 11 02 04 5B 70 9B 75 02 03 00 0{...0...[p.u...
0016: FF E3 04 01 01 02 01 03 04 2E 30 2C 04 0D 80 00 ..........0,....
0032: 1F 88 80 82 0B 53 2D 67 01 8A 4D 02 01 01 02 03 .....S-g..M.....
0048: 02 7B 92 04 03 77 65 73 04 0C DF 8B 2A FE 4A C5 .{...wes....*.J.
0064: 4C 33 63 A6 2C C8 04 00 30 33 04 0D 80 00 1F 88 L3c.,...03......
0080: 80 82 0B 53 2D 67 01 8A 4D 04 00 A2 20 02 04 67 ...S-g..M... ..g
0096: DB 56 C4 02 01 00 02 01 00 30 12 30 10 06 0A 2B .V.......0.0...+
0112: 06 01 02 01 5C 01 01 01 00 42 02 03 E8 ....\....B...

NOTIFICATION-LOG-MIB::nlmConfigGlobalEntryLimit.0 = Gauge32: 1000

It was produced with the following command:
$ snmpget -v3 -n "" -c public -u wes -a md5 -A setup_passphrase -l authNoPriv -d localhost nlmConfigGlobalEntryLimit.0

While decoding (with my own tool) the message above, I met a constraint error with ASN.1 describing SNMPv3 message.
The actual issue with request-id parameter inside PDU & BulkPDU definitions.

Received value (from dump):
request-id = 1742427844

ASN.1:
request-id INTEGER (-214783648..214783647)

You can see that may be in number = 214783647, 4 is missed. I.e.: should be the following: 2147_4_83647

----------

Verifier Note:

There is indeed an error in the RFC, but the "correction" text is also incorrect.
The two changes needed are:

OLD:
request-id INTEGER (-214783648..214783647),
NEW:
request-id INTEGER (-2147483648..2147483647),

OLD:
request-id INTEGER (-214783648..214783647),
NEW:
request-id INTEGER (-2147483648..2147483647),

RFC 3418, "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", December 2002

Source of RFC: snmpv3 (ops)

Errata ID: 276
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Glenn M. Keeni
Date Reported: 2003-08-22

In the text, it says:

   6.1.  Informative References

It should say:

   6.2.  Informative References

RFC 3420, "Internet Media Type message/sipfrag", November 2002

Source of RFC: sip (rai)

Errata ID: 274
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ged Davies
Date Reported: 2005-06-08

In Normative References, it says:

   [1]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3265, June 2002.

It should say:

   [1]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3261, June 2002.

Errata ID: 275
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2004-10-20

The "short title" in the page headings, is missing an 's'. It currently says:

Internet Media Type message/ipfrag  

It should say:

Internet Media Type message/sipfrag  

Notes:

RFC 3424, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", November 2002

Source of RFC: IAB

Errata ID: 273
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Leslie Daigle
Date Reported: 2002-11-19

The center page header:

   IAB Considerations for UNSAP Across NAT

It should say:

   IAB Considerations for UNSAF Across NAT

RFC 3433, "Entity Sensor Management Information Base", December 2002

Source of RFC: entmib (ops)

Errata ID: 2008
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Minoru Teraoka
Date Reported: 2010-01-18
Verifier Name: Dan Romascanu
Date Verified: 2010-05-10

Section 4 says:

        exa(14),    -- 10^15
        peta(15),   -- 10^18

It should say:

        peta(14),   -- 10^15
        exa(15),    -- 10^18

RFC 3435, "Media Gateway Control Protocol (MGCP) Version 1.0", January 2003

Note: This RFC has been updated by RFC 3661

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: tsv

Errata ID: 2463
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Vishal Grover
Date Reported: 2010-08-13
Verifier Name: Robert Sparks
Date Verified: 2011-03-23

Section Appendix G says:

On Page no 206 at the bottom you will see following :

Step 2 - Delete Connection (dlcx) from ca to rgw2

   Requests rgw2 to delete the connection "67890af54c9":

      dlcx 2055 aaln/1@rgw1.whatever.net mgcp 1.0
      c: 9876543210abcdef
      i: 67890af54c9

It should say:

Step 2 - Delete Connection (dlcx) from ca to rgw2

   Requests rgw2 to delete the connection "67890af54c9":

      dlcx 2055 aaln/1@rgw2.whatever.net mgcp 1.0
      c: 9876543210abcdef
      i: 67890af54c9

Notes:

1. Need to visit Following link :
http://tools.ietf.org/rfc/rfc3435.txt

2. Go to Appendix G:

Appendix G: Example Call Flows....................................194
G.3 Connection Deletion........................................206
G.3.1 Residential Gateway to Residential Gateway.................206

3. On Page no 206 at the bottom you will see following :

Step 2 - Delete Connection (dlcx) from ca to rgw2

Requests rgw2 to delete the connection "67890af54c9":

dlcx 2055 aaln/1@rgw1.whatever.net mgcp 1.0
c: 9876543210abcdef
i: 67890af54c9

it should be rgw2 i guess.

-- NOTE from reviewing AD: This change affects page 207, not page 206.

Errata ID: 4562
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Karl Brose
Date Reported: 2015-12-10
Verifier Name: Magnus Westerlund
Date Verified: 2019-03-27

Section G.1.2 says:

Table F.2: Residential Gateway Restart

It should say:

Table F.2: Call Agent Restart

Notes:

The section is about a call agent restarting and the table illustrates the protocol correctly, but the table title is wrong, apparently copied from Table F.1 in Section G.1.1 Residential Gatway Restart.

RFC 3439, "Some Internet Architectural Guidelines and Philosophy", December 2002

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: tsv

Errata ID: 1650
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Adam Gleave
Date Reported: 2009-01-09
Verifier Name: Russ Housley
Date Verified: 2009-01-11

Section 4 says:

   While there have been many implementations of Universal Interworking
   unction (UIWF), IWF approaches have been problematic at large scale.
   his concern is codified in the Principle of Minimum Intervention
   BRYANT]:

It should say:

   While there have been many implementations of Universal Interworking
   Function (UIWF), IWF approaches have been problematic at large scale.
   This concern is codified in the Principle of Minimum Intervention
   [BRYANT]:

Notes:

First character of three lines is missing.

Errata ID: 5608
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sascha Hanse
Date Reported: 2019-01-19
Verifier Name: Mirja Kühlewind
Date Verified: 2019-01-21

Section 5. says:

Further, it is widely assumed that IP is simpler that circuit switching,
and hence should be more economical to deploy and manage [MCK2002].

It should say:

Further, it is widely assumed that PS is simpler than circuit switching,
and hence should be more economical to deploy and manage [MCK2002].

Notes:

Replaced second "that" with "than" and replaced "IP" with "PS" seeing as packet and circuit switching are being compared

Errata ID: 6722
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2021-10-26
Verifier Name: RFC Editor
Date Verified: 2022-01-27

Section 4 says:

   his concern is codified in the Principle of Minimum Intervention
   BRYANT]:

It should say:

   This concern is codified in the Principle of Minimum Intervention
   [BRYANT]:

Notes:

The symbols T and [ are missing.

Errata ID: 6837
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: David Melkumov
Date Reported: 2022-02-05
Verifier Name: RFC Editor

Section 2.4 says:

Adding an new Internet service is just a matter of distributing an application to the a few consenting desktops who wish to use it.

It should say:

Adding a new Internet service is just a matter of distributing an application to the a few consenting desktops who wish to use it.

Notes:

changing an to a

RFC 3445, "Limiting the Scope of the KEY Resource Record (RR)", December 2002

Note: This RFC has been obsoleted by RFC 4033, RFC 4034, RFC 4035

Source of RFC: dnsext (int)

Errata ID: 272
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: "Scott Rose"
Date Reported: 2005-02-22
Verifier Name: Brian Haberman
Date Verified: 2012-05-01

Values for the key protocol octet are incorrect. They should be:

        VALUE   Protocol

          0      -reserved
          1     reserved (was TLS)
          2     reserved (was email)
          3     dnssec
          4     reserved (was IPSEC)
         5-255   reserved

Notes:

Rationale: Looking at RFC2535, the values are the original assignments. The
numbers in RFC3445 are incorrect and don't match. I guess since the
registry was closed, they are all reserved now and no one double checked.

RFC 2535 has the original correct assignments, and the registry is correct
in stating that they are now all reserved.

RFC 3447, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", February 2003

Note: This RFC has been obsoleted by RFC 8017

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 592
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2003-08-28

Section 7.1.2 says:

        C    ciphertext to be decrypted, an octet string of length k,
             where k = 2hLen + 2

It should say:

        C    ciphertext to be decrypted, an octet string of length k,
             where k >= 2hLen + 2

Notes:

In the "Input:" section, near the top of the page, the condition
specified for 'k' is too restrictive. {This becomes clear from
the context - see e.g. 'step 1. c.' in mid-page 22.}

Errata ID: 594
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2003-08-28

Section 8.2.2 says:

       c. Convert the message representative m to an encoded message
          EM of length k octets (see Section 4.1):

             EM' = I2OSP (m, k).
 

It should say:

       c. Convert the message representative m to an encoded message
          EM of length k octets (see Section 4.1):

             EM = I2OSP (m, k).

Notes:

In 'step 2. c.', in fact "EM" is computed, not "EM'" -- as stated
in the text; see also 'step 3.' below.

Errata ID: 595
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2003-08-28

Section 9.1 says:

                                  +-----------+
                                  |     M     |
                                  +-----------+
                                        |
                                        V
                                      Hash
                                        |
                                        V
                          +--------+----------+----------+
                     M' = |Padding1|  mHash   |   salt   |
                          +--------+----------+----------+
                                         |
               +--------+----------+     V
         DB =  |Padding2|maskedseed|   Hash
               +--------+----------+     |
                         |               |
                         V               |    +--+
                        xor <--- MGF <---|    |bc|
                         |               |    +--+
                         |               |      |
                         V               V      V
               +-------------------+----------+--+
         EM =  |    maskedDB       |maskedseed|bc|
               +-------------------+----------+--+

It should say:

                                  +-----------+
                                  |     M     |
                                  +-----------+
                                        |
                                        V
                                      Hash
                                        |
                                        V
                          +--------+----------+----------+
                     M' = |Padding1|  mHash   |   salt   |
                          +--------+----------+----------+
                                         |
               +--------+----------+     V
         DB =  |Padding2|   salt   |   Hash
               +--------+----------+     |
                         |               |
                         V               |    +--+
                        xor <--- MGF <---|    |bc|
                         |               |    +--+
                         |               |      |
                         V               V      V
               +-------------------+----------+--+
         EM =  |    maskedDB       |     H    |bc|
               +-------------------+----------+--+

Notes:

Figure 2 names two fields "maskedseed" which in fact are _very_
different, and this nomenclature matches neither the figure
caption given nor the subsequent text -- see e.g. 'step 6.' and
'step 8.' on page 39 and 'step 12.' on page 40.

Errata ID: 633
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2003-08-28

Section 7.1.1 says:

                             +----------+---------+-------+
                        DB = |  lHash   |    PS   |   M   |
                             +----------+---------+-------+
                                            |
                  +----------+              V
                  |   seed   |--> MGF ---> xor
                  +----------+              |
                        |                   |
               +--+     V                   |
               |00|    xor <----- MGF <-----|
               +--+     |                   |
                 |      |                   |
                 V      V                   V
               +--+----------+----------------------------+
         EM =  |00|maskedSeed|          maskedDB          |
               +--+----------+----------------------------+

It should say:

                             +----------+--------+--+-------+
                        DB = |  lHash   |   PS   |01|   M   |
                             +----------+--------+--+-------+
                                            |
                  +----------+              V
                  |   seed   |--> MGF ---> xor
                  +----------+              |
                        |                   |
               +--+     V                   |
               |00|    xor <----- MGF <-----|
               +--+     |                   |
                 |      |                   |
                 V      V                   V
               +--+----------+------------------------------+
         EM =  |00|maskedSeed|          maskedDB            |
               +--+----------+------------------------------+

Errata ID: 635
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2003-08-28

Section A.2.3 says:

       * maskGenAlgorithm identifies the mask generation function.  It
         shall be an algorithm ID with an OID in the set

         PKCS1MGFAlgorithms (see Appendix A.2.1).  The default mask
         generation function is MGF1 with SHA-1.  For MGF1 (and more
         generally, ...

It should say:

       * maskGenAlgorithm identifies the mask generation function.  It
         shall be an algorithm ID with an OID in the set
         PKCS1MGFAlgorithms (see Appendix A.2.1).  The default mask
         generation function is MGF1 with SHA-1.  For MGF1 (and more
         generally, ...

Notes:

The bulleted section for 'maskGenAlgorithm' contains an unexpected
blank line within the second sentence.

Errata ID: 636
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2003-08-28

Section B.1 says:

Six hash functions are given as examples for the encoding methods
in this document: MD2 [33], MD5 [41], SHA-1 [38], and the
proposed algorithms SHA-256, SHA-384, and SHA-512 [39].

It should say:

Six hash functions are given as examples for the encoding methods
in this document: MD2 [33], MD5 [41], and the algorithms SHA-1,
SHA-256, SHA-384, and SHA-512 [38'].

Notes:

RFC 3447 has been published on Feb 04, 2003 (according to the
time stamp of rfc3447.txt on <ftp://ftp.rfc-editor.org/in-notes/>).

The new "Secure Hash Standard", FIPS Pub 180-2 had been published
on "2002 August 1" and became "effective on February 1, 2003" as
specified on page ii of FIPS 180-2, "9. Implementation Schedule".

Both events predate the publishing date of RFC 3447.

Therefore, the first sentence of the second paragraph on page 53 should be as noted above.

Errata ID: 638
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2003-08-28

Section F says:

[38]  National Institute of Standards and Technology (NIST).
      FIPS Publication 180-1: Secure Hash Standard.  April 1994.

[39]  National Institute of Standards and Technology (NIST).
      Draft FIPS 180-2: Secure Hash Standard.  Draft, May 2001.
      Available from http://www.nist.gov/sha/.

It should say:

[38]  National Institute of Standards and Technology (NIST).
      FIPS Publication 180-2: Secure Hash Standard.  August
      2002.

Notes:

RFC 3447 has been published on Feb 04, 2003 (according to the
time stamp of rfc3447.txt on <ftp://ftp.rfc-editor.org/in-notes/>).

The new "Secure Hash Standard", FIPS Pub 180-2 had been published
on "2002 August 1" and became "effective on February 1, 2003" as
specified on page ii of FIPS 180-2, "9. Implementation Schedule".

Both events predate the publishing date of RFC 3447.

The reference should be updated as noted above.

Errata ID: 2176
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Verifier Name: Sean Turner
Date Verified: 2011-06-02

Section 7.1.2 says:

   K        recipient's RSA private key (k denotes the length in octets
            of the RSA modulus n)
   C        ciphertext to be decrypted, an octet string of length k,
            where k = 2hLen + 2

It should say:

   K        recipient's RSA private key (k denotes the length in octets
            of the RSA modulus n), where k >= 2hLen + 2
   C        ciphertext to be decrypted, an octet string of length k

Notes:

k >= 2hLen + 2 belongs to K, not to C.

The >= is already reported in #592.

Errata ID: 593
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2003-08-28

Section 7.1.2 says:

           b. Apply the RSADP decryption primitive (Section 5.1.2) to the
	   RSA private key K and the ciphertext representative c to
           produce an integer message representative m:
   
       

It should say:

       b. Apply the RSADP decryption primitive (Section 5.1.2) to the
          RSA private key K and the ciphertext representative c to
          produce an integer message representative m:

Notes:

The first line of 'step 2. b.', is indented too much (by 3 chars)

Errata ID: 596
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2003-08-28

Section 9.2 says:

       SHA-512: (0x)30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00
                       04 40 || H.

It should say:

       SHA-512: (0x)30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00
                    04 40 || H.

Notes:

The second line of the last example of 'Note 1.' (for SHA-512) is indented too much (by 3 chars).

RFC 3448, "TCP Friendly Rate Control (TFRC): Protocol Specification", January 2003

Note: This RFC has been obsoleted by RFC 5348

Source of RFC: tsvwg (wit)

Errata ID: 270
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Joerg Widmer
Date Reported: 2003-03-04

Section 4 says:

If the sender does not receive a feedback report for two round
trip times, it cuts its sending rate in half.

It should say:

If the sender does not receive a feedback report for four round
trip times, it cuts its sending rate in half.

Notes:

Nofeedback timeout: Correct an inconsistency in the document.

(collected by Sally Floyd, 2004-06-11)

Errata ID: 1458
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Handley, from Wim Heirman
Date Reported: 2003-03-13

Section 4.4, item (2) says:

If the nofeedback timer expires when the sender does not yet have
an RTT sample, and has not yet received any feedback from the
receiver,

It should say:

If the nofeedback timer expires when the sender does not yet have
an RTT sample, and has not yet received any feedback from the
receiver, or when p == 0,

Notes:

(collected by Sally Floyd, 2004-06-11)

Errata ID: 1459
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michele R.
Date Reported: 2003-04-29

Section 5.5 says:

      for (i = 1 to n) {
        DF_i = 1;
      }

It should say:

      for (i = 0 to n) {
        DF_i = 1;
      }

Notes:

When initializing DF, initialize from 0 to n, not from 1 to n.

(collected by Sally Floyd, 2004-06-11)

RFC 3454, "Preparation of Internationalized Strings ("stringprep")", December 2002

Note: This RFC has been obsoleted by RFC 7564

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: int

Errata ID: 806
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sergiusz Wolicki
Date Reported: 2006-04-27

Section Appendix C says:

C. Prohibition tables

   The tables in this appendix consist of lines with one prohibited code
   point per line.  The format of the lines are the value of the code
   point, a semicolon, and a comment which is the name of the code
   point.

It should say:

[see Notes]

Notes:

This is not true as the tables in this appendix consist of lines with
one prohibited code point _range_ per line. The format of the lines
are the value of the starting code point of the range, a hyphen,
the value of the ending code point of the range, a semicolon,
and a comment which is the informal name of the range in square brackets.
If the range contains only one code point, then the hyphen and the ending
code point value are omitted, and the comment contains the name of
the code point without brackets.

from pending

RFC 3455, "Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)", January 2003

Note: This RFC has been obsoleted by RFC 7315

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rai

Errata ID: 3929
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Gagandeep Singh
Date Reported: 2014-03-23
Verifier Name: Orie Steele
Date Verified: 2024-03-29

Section 6.3 says:

Therefore intermediaries participating in this mechanism MUST apply a
hop-by-hop integrity protection mechanism such us IPsec or other
available mechanisms in order to prevent such attacks.

It should say:

Therefore intermediaries participating in this mechanism MUST apply a
hop-by-hop integrity protection mechanism such as IPsec or other
available mechanisms in order to prevent such attacks.

Notes:

Ofcourse this errata doesn't alter the technical meaning, but it is nice to have documents free of spelling errors too.

RFC 3461, "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", January 2003

Note: This RFC has been updated by RFC 3798, RFC 3885, RFC 5337, RFC 6533, RFC 8098

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 269
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mieke Van de Kamp
Date Reported: 2003-03-31

Section 5.2 says:

   A reference is made to RFC 1123, section 2.3.3, which does not exist. 
 
   The correct section in RFC 1123 is 5.3.3.

Errata ID: 686
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Valdis Kletniek
Date Reported: 2004-08-10
Verifier Name: Alexey Melnikov
Date Verified: 2009-09-06

Section 4.2 says:

   The "addr-type" portion MUST be an IANA-registered electronic mail
   address-type (as defined in [3]), while the "xtext" portion contains
   an encoded representation of the original recipient address using the
   rules in section 5 of this document.  The entire ORCPT parameter MAY
   be up to 500 characters in length.

It should say:

   The "addr-type" portion MUST be an IANA-registered electronic mail
   address-type (as defined in [3]), while the "xtext" portion contains
   an encoded representation of the original recipient address using the
   rules in section 4 of this document.  The entire ORCPT parameter MAY
                    ^
   be up to 500 characters in length.

Notes:

xtext encoding is described in Section 4, not in Section 5

Errata ID: 5575
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: M. Shulhan
Date Reported: 2018-12-13
Verifier Name: RFC Editor
Date Verified: 2019-02-19

Section 4.2 says:

When initially submitting a message via SMTP, if the ORCPT parameter
is used, it MUST contain the same address as the RCPT TO address
(unlike the RCPT TO address, the ORCPT parameter will be encoded as
xtext).  Likewise, when a mailing list submits a message via SMTP to
be distributed to the list subscribers, if ORCPT is used, the ORCPT
parameter MUST match the new RCPT TO address of each recipient, not
the address specified by the original sender of the message.)

It should say:

When initially submitting a message via SMTP, if the ORCPT parameter
is used, it MUST contain the same address as the RCPT TO address
(unlike the RCPT TO address, the ORCPT parameter will be encoded as
xtext).  Likewise, when a mailing list submits a message via SMTP to
be distributed to the list subscribers, if ORCPT is used, the ORCPT
parameter MUST match the new RCPT TO address of each recipient, not
the address specified by the original sender of the message.

Notes:

Superfluous closing parenthesis at the end of paragraph.

RFC 3464, "An Extensible Message Format for Delivery Status Notifications", January 2003

Note: This RFC has been updated by RFC 4865, RFC 5337, RFC 6533

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 2965
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bill McQuillan
Date Reported: 2011-09-09
Verifier Name: Pete Resnick
Date Verified: 2011-12-29

Section Appendix E says:

Simple DSN

   This is a simple DSN issued after repeated attempts to deliver a
   message failed.  In this case, the DSN is issued by the same MTA from
   which the message was originated.

   Date: Thu, 7 Jul 1994 17:16:05 -0400 From: Mail Delivery Subsystem
   <MAILER-DAEMON@CS.UTK.EDU> Message-Id:
   <199407072116.RAA14128@CS.UTK.EDU> Subject: Returned mail: Cannot
   send message for 5 days To: <owner-info-mime@cs.utk.edu> MIME-
   Version: 1.0 Content-Type: multipart/report; report-type=delivery-
   status;
          boundary="RAA14128.773615765/CS.UTK.EDU"

   --RAA14128.773615765/CS.UTK.EDU

It should say:

Simple DSN

   This is a simple DSN issued after repeated attempts to deliver a
   message failed.  In this case, the DSN is issued by the same MTA from
   which the message was originated.

   Date: Thu, 7 Jul 1994 17:16:05 -0400 
   From: Mail Delivery Subsystem <MAILER-DAEMON@CS.UTK.EDU> 
   Message-Id: <199407072116.RAA14128@CS.UTK.EDU> 
   Subject: Returned mail: Cannot send message for 5 days 
   To: <owner-info-mime@cs.utk.edu> 
   MIME-Version: 1.0 
   Content-Type: multipart/report; report-type=delivery-status;
          boundary="RAA14128.773615765/CS.UTK.EDU"

   --RAA14128.773615765/CS.UTK.EDU

Notes:

Apparently an unintended "Reformat Paragraph" of the top level message header.

RFC 3468, "The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols", February 2003

Source of RFC: mpls (rtg)

Errata ID: 695
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alex Zinin
Date Reported: 2004-10-23
Verifier Name: Adrian Farrel
Date Verified: 2010-01-02

The header says:

Network Working Group                                       L. Andersson
Request for Comments: 3468                                    Consultant
Category: Informational                                       G. Swallow
                                                           Cisco Systems
                                                           February 2003

It should say:

Network Working Group                                       L. Andersson
Request for Comments: 3468                                    Consultant
Updates: 3212, 3472, 3475, 3476                               G. Swallow
Category: Informational                                    Cisco Systems
                                                           February 2003

Notes:

RFC3468 documents the MPLS WG's decision to ice CR-LDP.
However, RFC3468 is not marked as updating RFC3212 (CR-LDP base spec) in the registry.

The RFCs updated by 3468 are:
3212, 3472, 3475, 3476

[Note that the RFC Editor index has been updated accordingly, but the document itself remains incorrect.]

Originally sent by Adrian Farrel.

from pending

RFC 3470, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", January 2003

Note: This RFC has been updated by RFC 8996

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 268
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Larry Masinter
Date Reported: 2003-04-25

Section 4.13 says:

   "numeric entity reference"  

It should say:

   "numeric character reference"

Notes:

Section 4.16:
"In XML instances all white space is considered significant and
is by default visible to processing applications."
Should be:
"In XML instances, white space is often significant and visible
to processing applications."

RFC 3471, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", January 2003

Note: This RFC has been updated by RFC 4201, RFC 4328, RFC 4872, RFC 6002, RFC 6003, RFC 6205, RFC 7074, RFC 7699, RFC 8359

Source of RFC: ccamp (rtg)

Errata ID: 1977
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Zongpeng Du
Date Reported: 2009-12-24
Verifier Name: Adrian Farrel
Date Verified: 2009-12-27

Section 2 says:

Another basic difference between traditional and non-PSC types of
generalized MPLS LSPs, is that bandwidth allocation for an LSP can be
performed only in discrete units, see Section 3.1.3. 

It should say:

Another basic difference between traditional and non-PSC types of
generalized MPLS LSPs, is that bandwidth allocation for an LSP can be
performed only in discrete units, see Section 3.1.2. 

Notes:

Fix to point to correct section number.

RFC 3473, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", January 2003

Note: This RFC has been updated by RFC 4003, RFC 4201, RFC 4420, RFC 4783, RFC 4874, RFC 4873, RFC 4974, RFC 5063, RFC 5151, RFC 5420, RFC 6002, RFC 6003, RFC 6780, RFC 8359

Source of RFC: ccamp (rtg)

Errata ID: 267
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Steve Conner
Date Reported: 2003-02-16

OLD:

    [RFC2402]        Kent, S. and R. Atkinson, "IP Authentication
                     Header", RFC 2401, November 1998.

    [RFC2406]        Kent, S. and R. Atkinson, "IP Encapsulating
                     Security Payload (ESP)", RFC 2401, November 1998.

It should say:

    [RFC2402]        Kent, S. and R. Atkinson, "IP Authentication
                     Header", RFC 2402, November 1998.

    [RFC2406]        Kent, S. and R. Atkinson, "IP Encapsulating
                     Security Payload (ESP)", RFC 2406, November 1998.

Errata ID: 1518
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Pontus Sköldström
Date Reported: 2008-09-18
Verifier Name: Adrian Farrel
Date Verified: 2009-10-30

Section 4.2.1 says:

  0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             | Class-Num (1) |  C-Type (1)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    IPv4 Notify Node Address                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv4 Notify Node Address: 32 bits

      The IP address of the node that should be notified when generating
      an error message.

      o  IPv6 Notify Request Object

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             | Class-Num (2) |  C-Type (2)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                    IPv6 Notify Node Address                   |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

  0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             | Class-Num(195)|  C-Type (1)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    IPv4 Notify Node Address                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv4 Notify Node Address: 32 bits

      The IP address of the node that should be notified when generating
      an error message.

      o  IPv6 Notify Request Object

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             | Class-Num(195)|  C-Type (2)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                    IPv6 Notify Node Address                   |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

The figures showing the format of the Notify Request objects have the wrong Class-Number (seems to have used the C-Type instead).

Errata ID: 4585
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexander Okonnikov
Date Reported: 2016-01-08
Verifier Name: Deborah Brungard
Date Verified: 2016-02-10

Section 5.2.1 says:

   Label RRO subobjects are included in RROs as described in [RFC3209].
   The only modification to usage and processing from [RFC3209] is that
   when labels are recorded for bidirectional LSPs, label ERO subobjects
   for both downstream and upstream labels MUST be included.

It should say:

   Label RRO subobjects are included in RROs as described in [RFC3209].
   The only modification to usage and processing from [RFC3209] is that
   when labels are recorded for bidirectional LSPs, label RRO subobjects
   for both downstream and upstream labels MUST be included.

Notes:

RRO in place of ERO.

Errata ID: 2159
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sean Turner
Date Reported: 2010-04-12
Verifier Name: Adrian Farrel
Date Verified: 2010-06-11

Section 12 says:

Alternatively, the sending of no-hop-by-hop Notify messages
can be disabled.

It should say:

Alternatively, the sending of non-hop-by-hop Notify messages
can be disabled.

Notes:

r/no-hop-by-hop/non-hop-by-hop

Errata ID: 2160
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sean Turner
Date Reported: 2010-04-12
Verifier Name: Adrian Farrel
Date Verified: 2010-06-11

Section 12 says:

Configured keys MAY be used.

It should say:

Manually configured keys MAY be used.

Notes:

Assumed that this sentence is talking about the opposite of an automated key management system, which is manually configured keys.

Errata ID: 2173
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vishwas Manral
Date Reported: 2010-04-25
Verifier Name: Adrian Farrel
Date Verified: 2010-06-11

Section TOC says:

   10. RSVP Message Formats and Handling  .........................  30
    10.1  RSVP Message Formats  ...................................  30
    10.2  Addressing Path and PathTear Messages   .................  32

It should say:

   10. RSVP Message Formats and Handling  .........................  30
    10.1  RSVP Message Formats  ...................................  30
    10.2  Addressing Path, PathTear and ResvConf Messages   .......  32

Notes:

The section is called "Addressing Path, PathTear and ResvConf Messages" while the TOC does not talk about ResvConf Message

Errata ID: 4467
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alexander Okonnikov
Date Reported: 2015-09-08
Verifier Name: Deborah Brungard
Date Verified: 2015-09-10

Section 2.4 says:

Waveband switching uses the same format as the generalized label, see
   section 2.2.

It should say:

Waveband switching uses the same format as the generalized label, see
   section 2.3.

Notes:

Incorrect reference.

RFC 3490, "Internationalizing Domain Names in Applications (IDNA)", March 2003

Note: This RFC has been obsoleted by RFC 5890, RFC 5891

Source of RFC: idn (int)

Errata ID: 266
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Adam Costello
Date Reported: 2003-04-28

Section 4.2 says:

   The ToUnicode output never contains more code points than its
   input.

This is not true; I have constructed a counterexample.  

It should say:

    The Punycode decoder can never output more code points than it
    inputs, but Nameprep can, and therefore ToUnicode can.

RFC 3492, "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", March 2003

Note: This RFC has been updated by RFC 5891

Source of RFC: idn (int)

Errata ID: 265
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Adam Costello
Date Reported: 2003-04-28

Section 6.4 says:

   where maxint is the greatest integer for which maxint + 1 cannot be
   represented.

It should say:

   where maxint is the maximum value of an integer variable.

RFC 3494, "Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status", March 2003

Source of RFC: Legacy

Errata ID: 264
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Marshall Price
Date Reported: 2004-10-15

In the "Dependent Specifications" section, it says:

RFC 1781 is a technical specification for "User Friendly Naming"
which replies on particular syntaxes described in RFC 1779.

It should say:

RFC 1781 is a technical specification for "User Friendly Naming"
which relies on particular syntaxes described in RFC 1779.

RFC 3501, "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", March 2003

Note: This RFC has been obsoleted by RFC 9051

Note: This RFC has been updated by RFC 4466, RFC 4469, RFC 4551, RFC 5032, RFC 5182, RFC 5738, RFC 6186, RFC 6858, RFC 7817, RFC 8314, RFC 8437, RFC 8474, RFC 8996

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 261
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Crispin
Date Reported: 2007-06-13

 

Section 2.3.1.1, page 8:
        old:
   A 32-bit value assigned to each message, which when used with the
   unique identifier validity value (see below) forms a 64-bit value
   that MUST NOT refer to any other message in the mailbox or any
   subsequent mailbox with the same name forever.  Unique identifiers
   [...]
        new:
   An unsigned 32-bit value assigned to each message, which when used
   with the unique identifier validity value (see below) forms a 64-bit
   value that MUST NOT refer to any other message in the mailbox or any
   subsequent mailbox with the same name forever.  Unique identifiers
   [...]
-----

Section 2.3.1.1, page 9:
        old:
   Associated with every mailbox are two values which aid in unique
   identifier handling: the next unique identifier value and the unique
   identifier validity value.
        new:
   Associated with every mailbox are two 32-bit unsigned values which
   aid in unique identifier handling: the next unique identifier value
   (UIDNEXT) and the unique identifier validity value (UIDVALIDITY).
-----

Section 5.1.3, page 19:
        old:
   All other characters (octet values 0x00-0x1f and 0x7f-0xff) are
   represented in modified BASE64, with a further modification from
   [UTF-7] that "," is used instead of "/".  Modified BASE64 MUST NOT be
   used to represent any printing US-ASCII character which can represent
   itself.
        new:
   All other characters (octet values 0x00-0x1f and 0x7f-0xff) are
   represented in modified BASE64, with a further modification from
   [UTF-7] that "," is used instead of "/".  Modified BASE64 MUST NOT be
   used to represent any printing US-ASCII character which can represent
   itself.  Only characters inside the modified BASE64 alphabet are          
   permitted in modified BASE64 text.
-----

Section 5.4, page 22:
        old:
   If a server has an inactivity autologout timer, the duration of that
   timer MUST be at least 30 minutes.  The receipt of ANY command from     
   the client during that interval SHOULD suffice to reset the
   autologout timer.
        new:
   If a server has an inactivity autologout timer that applies to
   sessions after authentication, the duration of that timer MUST be at
   least 30 minutes.  The receipt of ANY command from the client during
   that interval SHOULD suffice to reset the autologout timer.

Section 5.5, page 22:
          old:
        Note: UID FETCH, UID STORE, and UID SEARCH are different
        commands from FETCH, STORE, and SEARCH.  If the client
        sends a UID command, it must wait for a completion result     
        response before sending a command with message sequence
        numbers.
          new:
        Note: EXPUNGE responses are permitted while UID FETCH,
        UID STORE, and UID SEARCH are in progress.  If the client
        sends a UID command, it must wait for a completion result
        response before sending a command which uses message
        sequence numbers (this may include UID SEARCH).  Any
        message sequence numbers in an argument to UID SEARCH       
        are associated with messages prior to the effect of any     
        untagged EXPUNGE returned by the UID SEARCH.
-----

Section 6.2.1, page 27:
        old:
      Once [TLS] has been started, the client MUST discard cached      
      information about server capabilities and SHOULD re-issue the    
      CAPABILITY command.  This is necessary to protect against man-in-
      the-middle attacks which alter the capabilities list prior to
      STARTTLS.  The server MAY advertise different capabilities after
      STARTTLS.
        new:
      Once [TLS] has been started, the client MUST discard cached
      information about server capabilities and SHOULD re-issue the
      CAPABILITY command.  This is necessary to protect against man-in-
      the-middle attacks which alter the capabilities list prior to
      STARTTLS.  The server MAY advertise different capabilities, and
      in particular SHOULD NOT advertise the STARTTLS capability, after
      a successful STARTTLS command.
-----

Section 6.2.2, page 28:
        old:
      The authentication protocol exchange consists of a series of
      server challenges and client responses that are specific to the
      authentication mechanism.  A server challenge consists of a  
      command continuation request response with the "+" token followed 
      by a BASE64 encoded string.  The client response consists of a    
      single line consisting of a BASE64 encoded string.  If the client
      wishes to cancel an authentication exchange, it issues a line
      consisting of a single "*".  If the server receives such a  
      response, it MUST reject the AUTHENTICATE command by sending a
      tagged BAD response.
        new:
      The authentication protocol exchange consists of a series of           
      server challenges and client responses that are specific to the
      authentication mechanism.  A server challenge consists of a
      command continuation request response with the "+" token followed
      by a BASE64 encoded string.  The client response consists of a
      single line consisting of a BASE64 encoded string.  If the client
      wishes to cancel an authentication exchange, it issues a line    
      consisting of a single "*".  If the server receives such a           
      response, or if it receives an invalid BASE64 string (e.g.
      characters outside the BASE64 alphabet, or non-terminal "="), it
      MUST reject the AUTHENTICATE command by sending a tagged BAD
      response.

Section 6.3.4, page 36:
        old:
      It is permitted to delete a name that has inferior hierarchical
      names and does not have the \Noselect mailbox name attribute.  In
      this case, all messages in that mailbox are removed, and the name
      will acquire the \Noselect mailbox name attribute.
        new:
      It is permitted to delete a name that has inferior hierarchical 
      names and does not have the \Noselect mailbox name attribute.  If
      the server implementation does not permit deleting the name while
      inferior hierarchical names exists the \Noselect mailbox name
      attribute is set for that name.  In any case, all messages in
      that mailbox are removed by the DELETE command.
-----

Section 6.3.10, page 44:
        old:
   Responses:  untagged responses: STATUS
        new:
   Responses:  REQUIRED untagged response: STATUS
-----

Section 6.4.3, page 49:
        old:
      The EXPUNGE command permanently removes all messages that have the
      \Deleted flag set from the currently selected mailbox.  Before   
      returning an OK to the client, an untagged EXPUNGE response is
      sent for each message that is removed.
        new:   
      The EXPUNGE command permanently removes all messages that have the
      \Deleted flag set from the currently selected mailbox.  Before
      returning an OK to the client, an untagged EXPUNGE response is
      sent for each message that is removed.  Note that if any messages
      with the \Recent flag set are expunged, an untagged RECENT response
      is sent after the untagged EXPUNGE(s) to update the client's count
      of RECENT messages.
-----

Section 6.4.4, page 50:
        old:
      [MIME-IMB] content transfer encodings, and [MIME-HDRS] strings in
      [RFC-2822]/[MIME-IMB] headers, MUST be decoded before comparing
      text in a [CHARSET] other than US-ASCII.  US-ASCII MUST be     
      supported; other [CHARSET]s MAY be supported.
        new:
      [MIME-IMB] content transfer encodings, and [MIME-HDRS] strings in 
      [RFC-2822]/[MIME-IMB] headers, MUST be decoded before comparing  
      text.  US-ASCII MUST be supported; other [CHARSET]s MAY be supported.
-----

Section 6.4.4, page 50:   
        old:
      In all search keys that use strings, a message matches the key if      
      the string is a substring of the field.  The matching is       
      case-insensitive.
        new:
      In all search keys that use strings, a message matches the key if
      the string is a substring of the associated text.  The matching is
      case-insensitive.  Note that the empty string is a substring; this
      is useful when doing a HEADER search.
-----

Section 6.4.4, page 54:
        old:   
               C: A284 SEARCH CHARSET UTF-8 TEXT {6}
               C: XXXXXX
               S: * SEARCH 43
               S: A284 OK SEARCH completed
        new:
               C: A284 SEARCH CHARSET UTF-8 TEXT {6}
               S: + Ready for literal text
               C: XXXXXX
               S: * SEARCH 43
               S: A284 OK SEARCH completed
-----

Section 7.2.2, page 70:
        old:
      If it is not feasible for the server to determine whether or not
      the mailbox is "interesting", or if the name is a \Noselect name,
      the server SHOULD NOT send either \Marked or \Unmarked.
        new:
      If it is not feasible for the server to determine whether or not
      the mailbox is "interesting", the server SHOULD NOT send either
      \Marked or \Unmarked.  The server MUST NOT send more than one of
      \Marked, \Unmarked, and \Noselect for a single mailbox, and MAY
      send none of these.
-----

Section 7.4.2, page 75:
        old:
         body location
            A string list giving the body content URI as defined in
            [LOCATION].
        new:
         body location
            A string giving the body content URI as defined in      
            [LOCATION].

Section 7.4.2, page 77:
        old:
         body location
            A string list giving the body content URI as defined in
            [LOCATION].
        new:
         body location
            A string giving the body content URI as defined in       
            [LOCATION].


Formal Syntax, Page 84:
        old:
CHAR8           = %x01-ff
                    ; any OCTET except NUL, %x00
        new:
CHAR8           = %x01-ff 
                    ; any OCTET except NUL, %x00

charset         = atom / quoted
-----

Formal Syntax, Page 89:
        old:
resp-text-code  = "ALERT" /
                  "BADCHARSET" [SP "(" astring *(SP astring) ")" ] /
        new:
resp-text-code  = "ALERT" /
                  "BADCHARSET" [SP "(" charset *(SP charset) ")" ] /
-----          

Formal Syntax, Page 89: 
        old:
search          = "SEARCH" [SP "CHARSET" SP astring] 1*(SP search-key)
        new:
search          = "SEARCH" [SP "CHARSET" SP charset] 1*(SP search-key)
-----

Formal Syntax, Page 90:      
        old:
sequence-set    = (seq-number / seq-range) *("," sequence-set)
        new:
sequence-set    = (seq-number / seq-range) ["," sequence-set]
-----       

Formal Syntax, Page 90:
        old:
status-att-list =  status-att SP number *(SP status-att SP number)
        new:
status-att-val  = ("MESSAGES" SP number) / ("RECENT" SP number) /    
                  ("UIDNEXT" SP nz-number) / ("UIDVALIDITY" SP nz-number) /
                  ("UNSEEN" SP number)

status-att-list =  status-att-val *(SP status-att-val)
-----

IANA Considerations, Page 94:
        new:
    GSSAPI/Kerberos/SASL service names are registered by publishing a
    standards track or IESG approved experimental RFC.  The registry
    is currently located at:

         http://www.iana.org/assignments/gssapi-service-names       

    As this specification defines the "imap" service name previously
    defined in RFC 1731, the registry will be updated accordingly.
-----       


Normative References, Page 95:
        old:
   [LANGUAGE-TAGS]       Alvestrand, H., "Tags for the Identification of
                         Languages", BCP 47, RFC 3066, January 2001. 
        new:
   [LANGUAGE-TAGS]       Alvestrand, H., "Content Language Headers",
                         RFC 3282, May 2002.


Appendix B, Page 103:    
        new:
   115) Add support for Content-Location to BODYSTRUCTURE.

It should say:

[see above] 

Notes:

from pending

Errata ID: 3032
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bron Gondwana
Date Reported: 2011-11-15
Verifier Name: Peter Saint-Andre
Date Verified: 2011-11-15

Section 6.3.1 says:

   Responses:  REQUIRED untagged responses: FLAGS, EXISTS, RECENT
               REQUIRED OK untagged responses:  UNSEEN,  PERMANENTFLAGS,
               UIDNEXT, UIDVALIDITY

[...]

         OK [UNSEEN <n>]
                     The message sequence number of the first unseen
                     message in the mailbox.  If this is missing, the
                     client can not make any assumptions about the first
                     unseen message in the mailbox, and needs to issue a
                     SEARCH command if it wants to find it.

It should say:

   Responses:  REQUIRED untagged responses: FLAGS, EXISTS, RECENT
               REQUIRED OK untagged responses:  PERMANENTFLAGS,
               UIDNEXT, UIDVALIDITY, UNSEEN (if any unseen exist)

[...]

         OK [UNSEEN <n>]
                     The message sequence number of the first unseen
                     message in the mailbox.  If there are any unseen
                     messages in the mailbox, an UNSEEN response MUST
                     be sent, if not it MUST be omitted.
                     If this is missing, the client cannot make any
                     assumptions about the first unseen message in the
                     mailbox, and needs to issue a SEARCH command if
                     it wants to find it.

Notes:

There is a conflict between "REQUIRED" on the UNSEEN response and having no value to send. This change documents the approach taken by existing servers.

RFC 3507, "Internet Content Adaptation Protocol (ICAP)", April 2003

Source of RFC: INDEPENDENT

Errata ID: 258

Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alex Rousskov
Date Reported: 2005-07-18
Report Text:

Errata for this document can be found at:
http://www.measurement-factory.com/std/icap/

---

RFC 3514, "The Security Flag in the IPv4 Header", April 2003

Source of RFC: INDEPENDENT

Errata ID: 4390
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: -
Date Reported: 2015-06-10

Section 5 says:

this permit easy encoding

It should say:

this permits easy encoding

Notes:

permit -> permits. Singular verb form instead of plural

Errata ID: 5309
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: micheal65536
Date Reported: 2018-03-28
Verifier Name: RFC Editor
Date Verified: 2018-03-28

Section 4 says:

Routers that are not intended as as security devices SHOULD NOT

It should say:

Routers that are not intended as security devices SHOULD NOT

Notes:

Duplicated word.

Errata ID: 6552
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Joe Peterson
Date Reported: 2021-04-20
Verifier Name: Eric Vyncke
Date Verified: 2021-04-20

Section 2 says:

        Insecure systems MAY chose to crash, be penetrated, etc.

It should say:

        Insecure systems MAY choose to crash, be penetrated, etc.

Notes:

'Chose' is the past tense, and what is desired here is the future tense 'choose'.

-- verifier note --
While the submitter SHOULD have posted this on April the 1st for an April Fools' Day RFC. For added fun, the errata is verified by an non-English speaker...

RFC 3515, "The Session Initiation Protocol (SIP) Refer Method", April 2003

Note: This RFC has been updated by RFC 7647, RFC 8217

Source of RFC: sip (rai)

Errata ID: 4898
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marianne MOHALI
Date Reported: 2017-01-03
Verifier Name: Orie Steele
Date Verified: 2024-03-29

Section 2.1 says:

Refer-To: <sip:bob@biloxi.example.net?Accept-Contact=sip:bobsdesk.
       biloxi.example.net&Call-ID%3D55432%40alicepc.atlanta.example.com>

It should say:

Refer-To: <sip:bob@biloxi.example.net?Accept-Contact=sip:bobsdesk.
       biloxi.example.net&Call-ID=55432%40alicepc.atlanta.example.com>

Notes:

The "=" between the header name (hname) and the value (hvalue) in the headers component of the URI does not have to be in the percent-coded format as part of the ABNF of the headers component defined in RFC3261:
sip:user:password@host:port;uri-parameters?headers
headers = "?" header *( "&" header )
header = hname "=" hvalue
hname = 1*( hnv-unreserved / unreserved / escaped )
hvalue = *( hnv-unreserved / unreserved / escaped )
hnv-unreserved = "[" / "]" / "/" / "?" / ":" / "+" / "$"

RFC 3516, "IMAP4 Binary Content Extension", April 2003

Note: This RFC has been updated by RFC 4466

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 3978
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Slusarz
Date Reported: 2014-04-29
Verifier Name: Nevil Brownlee
Date Verified: 2014-08-18

Section 4.3 says:

If the domain of the decoded data is "8bit" and the data does
not contain the NUL octet, the server SHOULD return the data in
a <string> instead of a <literal8>; this allows the client to
determine if the "8bit" data contains the NUL octet without
having to explicitly scan the data stream for for NULs.

It should say:

If the domain of the decoded data is "8bit" and the data does
not contain the NUL octet, the server SHOULD return the data in
a <string> instead of a <literal8>; this allows the client to
determine if the "8bit" data contains the NUL octet without
having to explicitly scan the data stream for NULs.

Notes:

Typo: duplication of "for".

RFC 3525, "Gateway Control Protocol Version 1", June 2003

Note: This RFC has been obsoleted by RFC 5125

Source of RFC: megaco (rai)

Errata ID: 256

Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tom Taylor
Date Reported: 2005-09-13
Report Text:

Errata can be found in the ITU-T Implementor's Guide at:
http://www.itu.int/itudoc/itu-t/com16/implgd/h248.1v1.html

---

RFC 3530, "Network File System (NFS) version 4 Protocol", April 2003

Note: This RFC has been obsoleted by RFC 7530

Source of RFC: nfsv4 (wit)

Errata ID: 2613
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Marcel Telka
Date Reported: 2010-11-08
Verifier Name: Lars Eggert
Date Verified: 2011-03-07

Section 14.2.16. says:

   When an OPEN is done and the specified lockowner already has the
   resulting filehandle open, the result is to "OR" together the new
   share and deny status together with the existing status.  In this
   case, only a single CLOSE need be done, even though multiple OPENs
   were completed.  When such an OPEN is done, checking of share
   reservations for the new OPEN proceeds normally, with no exception
   for the existing OPEN held by the same lockowner.

It should say:

   When an OPEN is done and the specified owner already has the
   resulting filehandle open, the result is to "OR" together the new
   share and deny status together with the existing status.  In this
   case, only a single CLOSE need be done, even though multiple OPENs
   were completed.  When such an OPEN is done, checking of share
   reservations for the new OPEN proceeds normally, with no exception
   for the existing OPEN held by the same owner.

Notes:

The 'lockowner' should be replaced by 'owner' (twice in the paragraph). The lockowner is not related to the OPEN operation. Instead, the owner (open_owner) is related.

Errata ID: 2614
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Marcel Telka
Date Reported: 2010-11-08
Verifier Name: Lars Eggert
Date Verified: 2011-03-07

Section 14.2.18. says:

   This operation is used to confirm the sequence id usage for the first
   time that a open_owner is used by a client.  The stateid returned
   from the OPEN operation is used as the argument for this operation
   along with the next sequence id for the open_owner.  The sequence id
   passed to the OPEN_CONFIRM must be 1 (one) greater than the seqid
   passed to the OPEN operation from which the open_confirm value was
   obtained.  If the server receives an unexpected sequence id with
   respect to the original open, then the server assumes that the client
   will not confirm the original OPEN and all state associated with the
   original OPEN is released by the server.

It should say:

   This operation is used to confirm the sequence id usage for the first
   time that a open_owner is used by a client.  The stateid returned
   from the OPEN operation is used as the argument for this operation
   along with the next sequence id for the open_owner.  The sequence id
   passed to the OPEN_CONFIRM must be 1 (one) greater than the seqid
   passed to the previous OPEN operation.
   If the server receives an unexpected sequence id with
   respect to the original open, then the server assumes that the client
   will not confirm the original OPEN and all state associated with the
   original OPEN is released by the server.

Notes:

The OPEN operation does not return the open_confirm value.

Errata ID: 2637
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Marcel Telka
Date Reported: 2010-11-19
Verifier Name: Lars Eggert
Date Verified: 2011-03-07

Section 14.2.18. says:

                           Instead, to avoid unbounded memory use, the
   server needs to implement a strategy for disposing of open_owner4s
   that have no current lock, open, or delegation state for any files
   and have not been used recently.

It should say:

                           Instead, to avoid unbounded memory use, the
   server needs to implement a strategy for disposing of open_owner4s
   that have no current open state for any files
   and have not been used recently.

Notes:

A lock can be held on already opened files only. This means that every lock state can exist only in case the accompanied open state is already there.

So if there is a lock state held by server then there must be an open state for the file too. This means that we do not need to mention the "current lock state" in the RFC's sentence above.

Next, the delegation state is allocated only in case the delegation is granted by server to a client for a file. The delegation state is related to file and client. It is not related/tied to openowner. This means that it is not possible to test whether an openowner have any delegation states. Delegation states are simply not related to the openowner.

It is easily possible to have a client with some delegation granted with no valid openowner held by a server.

Errata ID: 2663
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Marcel Telka
Date Reported: 2010-12-08
Verifier Name: Lars Eggert
Date Verified: 2011-03-07

Section 8.11. says:

   When an OPEN is done for a file and the lockowner for which the open
   is being done already has the file open, the result is to upgrade the
   open file status maintained on the server to include the access and
   deny bits specified by the new OPEN as well as those for the existing
   OPEN.  The result is that there is one open file, as far as the
   protocol is concerned, and it includes the union of the access and
   deny bits for all of the OPEN requests completed.  Only a single
   CLOSE will be done to reset the effects of both OPENs.  Note that the
   client, when issuing the OPEN, may not know that the same file is in
   fact being opened.  The above only applies if both OPENs result in
   the OPENed object being designated by the same filehandle.

It should say:

   When an OPEN is done for a file and the open_owner for which the open
   is being done already has the file open, the result is to upgrade the
   open file status maintained on the server to include the access and
   deny bits specified by the new OPEN as well as those for the existing
   OPEN.  The result is that there is one open file, as far as the
   protocol is concerned, and it includes the union of the access and
   deny bits for all of the OPEN requests completed.  Only a single
   CLOSE will be done to reset the effects of both OPENs.  Note that the
   client, when issuing the OPEN, may not know that the same file is in
   fact being opened.  The above only applies if both OPENs result in
   the OPENed object being designated by the same filehandle.

Notes:

The file opens are related to open_owners, not lockowners. The lockowner
should be replaced by open_owner in the first sentence of the paragraph above.

Errata ID: 255
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jon Bauman
Date Reported: 2004-02-03

Section 8.1.8. says:

This sequence establishes the use of an lock_owner and associated 
sequence number.

Should be "a lock_owner"

It should say:

If server replica or a server immigrating a filesystem agrees to

Should be "If a server replica"

Notes:

In Section 9.3.2. Data Caching and File Locking, Last Paragraph:

by flushing to the server more data upon an LOCKU than is covered by
the locked range.

Should be "a LOCKU"

Errata ID: 2609
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marcel Telka
Date Reported: 2010-11-05
Verifier Name: Lars Eggert
Date Verified: 2011-03-07

Section 14.2.11. says:

   SYNOPSIS

     (cfh) locktype, offset, length owner -> {void, NFS4ERR_DENIED ->
     owner}

It should say:

   SYNOPSIS

     (cfh) locktype, offset, length, owner -> {void, NFS4ERR_DENIED ->
     owner}

Notes:

Missing comma in the LOCKT synopsis.

Errata ID: 2610
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marcel Telka
Date Reported: 2010-11-05
Verifier Name: Lars Eggert
Date Verified: 2011-03-07

Section 14.2.16. says:

   SYNOPSIS

     (cfh), seqid, share_access, share_deny, owner, openhow, claim ->
     (cfh), stateid, cinfo, rflags, open_confirm, attrset delegation

It should say:

   SYNOPSIS

     (cfh), seqid, share_access, share_deny, owner, openhow, claim ->
     (cfh), stateid, cinfo, rflags, attrset, delegation

Notes:

i) The open_confirm should be removed (it is not a part of the OPEN4resok structure).
ii) There is missing command between attrset and delegation.

Errata ID: 2638
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marcel Telka
Date Reported: 2010-11-19
Verifier Name: Lars Eggert
Date Verified: 2011-03-07

Section 4.2.3. says:

   FH4_VOLATILE_ANY
             The filehandle may expire at any time, except as
             specifically excluded (i.e., FH4_NO_EXPIRE_WITH_OPEN).

It should say:

   FH4_VOLATILE_ANY
             The filehandle may expire at any time, except as
             specifically excluded (i.e., FH4_NOEXPIRE_WITH_OPEN).

Notes:

The FH4_NO_EXPIRE_WITH_OPEN should be replaced with FH4_NOEXPIRE_WITH_OPEN.

Errata ID: 2639
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marcel Telka
Date Reported: 2010-11-19
Verifier Name: Lars Eggert
Date Verified: 2011-03-07

Section 4.2.3. says:

   FH4_VOL_MIGRATION
             The filehandle will expire as a result of migration.  If
             FH4_VOL_ANY is set, FH4_VOL_MIGRATION is redundant.

   FH4_VOL_RENAME
             The filehandle will expire during rename.  This includes a
             rename by the requesting client or a rename by any other
             client.  If FH4_VOL_ANY is set, FH4_VOL_RENAME is
             redundant.

.....

   Note that the bits FH4_VOL_MIGRATION and FH4_VOL_RENAME allow the
   client to determine that expiration has occurred whenever a specific
   event occurs, without an explicit filehandle expiration error from
   the server.  FH4_VOL_ANY does not provide this form of information.
   In situations where the server will expire many, but not all
   filehandles upon migration (e.g., all but those that are open),

It should say:

   FH4_VOL_MIGRATION
             The filehandle will expire as a result of migration.  If
             FH4_VOLATILE_ANY is set, FH4_VOL_MIGRATION is redundant.

   FH4_VOL_RENAME
             The filehandle will expire during rename.  This includes a
             rename by the requesting client or a rename by any other
             client.  If FH4_VOLATILE_ANY is set, FH4_VOL_RENAME is
             redundant.

.....

   Note that the bits FH4_VOL_MIGRATION and FH4_VOL_RENAME allow the
   client to determine that expiration has occurred whenever a specific
   event occurs, without an explicit filehandle expiration error from
   the server.  FH4_VOLATILE_ANY does not provide this form of information.
   In situations where the server will expire many, but not all
   filehandles upon migration (e.g., all but those that are open),

Notes:

The FH4_VOL_ANY should be replaced with FH4_VOLATILE_ANY (three times).

RFC 3533, "The Ogg Encapsulation Format Version 0", May 2003

Source of RFC: INDEPENDENT

Errata ID: 6796
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Gang Zhao
Date Reported: 2021-12-25
Verifier Name: Adrian Farrel
Date Verified: 2021-12-27

Section 5 says:

Page_1 consists of the first three segments of
packet_1, page_2 contains the remaining 2 segments from packet_1, and
page_3 contains the first three pages of packet_2.

It should say:

Page_1 consists of the first three segments of
packet_1, page_2 contains the remaining 2 segments from packet_1, and
page_3 contains the first three segments of packet_2.

Notes:

The last part of this sentence used "three pages" which should be "three segments". As package is divided into segments.

RFC 3537, "Wrapping a Hashed Message Authentication Code (HMAC) key with a Triple-Data Encryption Standard (DES) Key or an Advanced Encryption Standard (AES) Key", May 2003

Source of RFC: vgmib (int)

Errata ID: 254
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2004-10-14

Section 3.4 says:

    PAD          :  38be62

It should say:

    PAD          :  be62fe

Notes:

RFC 3542, "Advanced Sockets Application Program Interface (API) for IPv6", May 2003

Source of RFC: ipv6 (int)

Errata ID: 253
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Hideaki Yoshifuji
Date Reported: 2005-06-26

Section 11.3 says:

   This cmsghdr will be passed to every socket that sets the
   IPV6_RECVPATHMTU socket option, even if the socket is non-connected.
   Note that this also means an application that sets the option may
   receive an IPV6_MTU ancillary data item for each ICMP too big error
   the node receives, including such ICMP errors caused by other
   applications on the node.

It should say:

   This cmsghdr will be passed to every socket that sets the
   IPV6_RECVPATHMTU socket option, even if the socket is non-connected.
   Note that this also means an application that sets the option may
   receive an IPV6_PATHMTU ancillary data item for each ICMP too big error
   the node receives, including such ICMP errors caused by other
   applications on the node.

Notes:

Change: IPV6_MTU should be IPV6_PATHMTU.

Errata ID: 252
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tatuya JINMEI
Date Reported: 2004-02-12

In section 10.2 (page 41), the RFC says:

      int inet6_opt_append(void *extbuf, socklen_t extlen, int offset,
                           uint8_t type, socklen_t len, uint_t align,
                           void **databufp);

It should say:

      int inet6_opt_append(void *extbuf, socklen_t extlen, int offset,
                           uint8_t type, socklen_t len, uint8_t align,
                           void **databufp);

Notes:

Similarly, the following part of Section 15 (page 55)

<netinet/in.h> int inet6_opt_append(void *, socklen_t, int,
uint8_t, socklen_t, uint_t,
void **);

Should actually be:

<netinet/in.h> int inet6_opt_append(void *, socklen_t, int,
uint8_t, socklen_t,
uint8_t, void **);

That is, "uint_t" should be replaced with "uint8_t".

RFC 3548, "The Base16, Base32, and Base64 Data Encodings", July 2003

Note: This RFC has been obsoleted by RFC 4648

Source of RFC: INDEPENDENT

Errata ID: 3916
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Daira Hopwood
Date Reported: 2014-03-10
Verifier Name: Nevil Brownlee
Date Verified: 2014-12-22

Section References says:

   [12]  Wilcox-O'Hearn, B., "Post to P2P-hackers mailing list",
         http://zgp.org/pipermail/p2p-hackers/2001-September/
         000315.html, September 2001.

It should say:

   [8]  Wilcox-O'Hearn, B., "Post to P2P-hackers mailing list",
         http://zgp.org/pipermail/p2p-hackers/2001-September/
         000313.html, September 2001.

Notes:

Noticed by Zancas Wilcox.

This erratum was submitted as a correct to reference [12], however
RFC 3548 has it as [8].

RFC 3552, "Guidelines for Writing RFC Text on Security Considerations", July 2003

Note: This RFC has been updated by RFC 8996, RFC 9416

Source of RFC: IAB

Errata ID: 2142
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lev Novikov
Date Reported: 2010-04-08
Verifier Name: Danny McPherson
Date Verified: 2010-09-10

Section 4.5.2.2 says:

   Note that if the client has a certificate than SSL-based client
   authentication can be used.  To make this easier, SASL provides the
   EXTERNAL mechanism, whereby the SASL client can tell the server
   "examine the outer channel for my identity".  Obviously, this is not
   subject to the layering attacks described above.

It should say:

   Note that if the client has a certificate then SSL-based client
   authentication can be used.  To make this easier, SASL provides the
   EXTERNAL mechanism, whereby the SASL client can tell the server
   "examine the outer channel for my identity".  Obviously, this is not
   subject to the layering attacks described above.

Notes:

Changed "than" to "then".

Errata ID: 2248
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Glen Zorn
Date Reported: 2010-05-07
Verifier Name: Danny McPherson
Date Verified: 2010-09-10

Section 4.5.1 says:

modifying with the kernel or installing new drivers.  

It should say:

modifying the kernel or installing new drivers.  

Notes:

Correct poor grammar.

Errata ID: 3828
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eliot Lear
Date Reported: 2013-12-09
Verifier Name: RFC Editor
Date Verified: 2014-09-03

Section 5 says:

Part of the purpose of the
Security Considerations section is to explain what attacks are out of
scope and what countermeasures can be applied to defend against them.
In

It should say:

Part of the purpose of the Security Considerations section
is to explain what attacks are in and out of scope and what
countermeasures can be applied to defend against them.

Notes:

Note dangling "In".

Not sure if this is exactly what the authors had in mind, and might suggest a more substantial change in a document update. For the moment I *think* this covers it.

Errata ID: 4563
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Walter Dolce
Date Reported: 2015-12-13
Verifier Name: Andrew Sullivan
Date Verified: 2016-01-07

Section 4.2. says:

This problem exists with any negotiation approach, but 
generic frameworks exacerbate it by encouraging the application 
protocol author to just specify the framework rather than think hard 
about the appropriate underlying mechanisms, particularly since the 
mechanisms can very widely in the degree of security offered.

It should say:

This problem exists with any negotiation approach, but 
generic frameworks exacerbate it by encouraging the application 
protocol author to just specify the framework rather than think hard 
about the appropriate underlying mechanisms, particularly since the 
mechanisms can vary widely in the degree of security offered.

Notes:

At the end of the paragraph, I think "very" should be changed to "vary"

Errata ID: 7610
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Pete Jorgensen
Date Reported: 2023-08-19
Verifier Name: Mirja Kühlewind
Date Verified: 2024-01-11

Section 3.3.5 says:

Note that it is only necessary to authenticate one side of the
   transaction in order to prevent man-in-the-middle attacks.  In such a
   situation the the peers can establish an association in which only
   one peer is authenticated.  In such a system, an attacker can
   initiate an association posing as the unauthenticated peer but cannot
   transmit or access data being sent on a legitimate connection.  This
   is an acceptable situation in contexts such as Web e-commerce where
   only the server needs to be authenticated (or the client is
   independently authenticated via some non-cryptographic mechanism such
   as a credit card number).

It should say:

Note that it is only necessary to authenticate one side of the
   transaction in order to prevent man-in-the-middle attacks.  In such a
   situation the peers can establish an association in which only
   one peer is authenticated.  In such a system, an attacker can
   initiate an association posing as the unauthenticated peer but cannot
   transmit or access data being sent on a legitimate connection.  This
   is an acceptable situation in contexts such as Web e-commerce where
   only the server needs to be authenticated (or the client is
   independently authenticated via some non-cryptographic mechanism such
   as a credit card number).

Notes:

2nd sentence fix "the the".

RFC 3561, "Ad hoc On-Demand Distance Vector (AODV) Routing", July 2003

Source of RFC: manet (rtg)

Errata ID: 7762
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Heiko Kiesel
Date Reported: 2024-01-14
Verifier Name: John Scudder
Date Verified: 2024-01-16

Section 6.7. says:

(iii)     the sequence numbers are the same, but the route is is
             marked as inactive, or

It should say:

(iii)     the sequence numbers are the same, but the route is
             marked as inactive, or

Notes:

Grammar mistake: Duplicated "is"

RFC 3575, "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", July 2003

Note: This RFC has been updated by RFC 6929

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: ops

Errata ID: 3378
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bernard Aboba
Date Reported: 2012-10-13
Verifier Name: Benoit Claise
Date Verified: 2012-12-13

Section Metadata says:

Updates: 2865

It should say:

Updates: 2865, 2868

Notes:

IANA needs to be updated as well.

http://www.iana.org/assignments/radius-types/radius-types.xml#radius-types-14

OLD
Registration Procedures
IETF Consensus
Reference
[RFC2868]

NEW
Registration Procedures
Designated Expert
Reference
[RFC3575]


http://www.iana.org/assignments/radius-types/radius-types.xml#radius-types-15

OLD
Registration Procedures
IETF Consensus
Reference
[RFC2868]

NEW
Registration Procedures
Designated Expert
Reference
[RFC3575]

=======================================================



Some background information:

RFC 3575 Section 2.1 states the following:

Certain attributes (for example, NAS-Port-Type) in RADIUS define a
list of values to correspond with various meanings. There can be 4
billion (2^32) values for each attribute. Additional values can be
allocated by the Designated Expert. The exception to this policy is
the Service-Type attribute (6), whose values define new modes of
operation for RADIUS. Values 1-16 of the Service-Type attribute have
been allocated. Allocation of new Service-Type values are by IETF
Consensus. The intention is that any allocation will be accompanied
by a published RFC.

Note that the Tunnel-Type and Tunnel-Medium-Type attributes are not called out as an exception, only Service-Type. If the intent was to exempt RFC 2868, those attributes would have been included as exceptions but they are not.

Therefore, it looks to me like the omission of RFC 2868 in the Updates: header is an errata.

In other words:

The discussion, as I understand it, is about "IETF consensus" versus "Designated Expert"

From RFC 2868

6.1. Tunnel-Type Attribute Values

Values 1-12 of the Tunnel-Type Attribute are defined in Section 5.1;
the remaining values are available for assignment by the IANA with
IETF Consensus [16].

6.2. Tunnel-Medium-Type Attribute Values

Values 1-15 of the Tunnel-Medium-Type Attribute are defined in
Section 5.2; the remaining values are available for assignment by the
IANA with IETF Consensus [16].

From RFC 3575

Certain attributes (for example, NAS-Port-Type) in RADIUS define a
list of values to correspond with various meanings. There can be 4
billion (2^32) values for each attribute. Additional values can be
allocated by the Designated Expert. The exception to this policy is
the Service-Type attribute (6), whose values define new modes of
operation for RADIUS.

So Tunnel-Type and Tunnel-Medium-Type are "IETF consensus" or "Designated Expert"?

From the IETF 80 meeting minutes, https://www.ietf.org/proceedings/80/minutes/radext.txt:

2. IANA issues
A. How to allocate tunnel params? In RFC 3575 (RFC2868 conflicts as 3575 assigns based on expert review but didn’t update 2868). Omission of RFC 2868 could be an errata; this is basically a request for metadata.
- Asks Dan for comment: was looking for input from the working group before proceeding.
- Alan thought it was an errata.
- Stefan states no opinion.
- Klaas also states no opinion.
- Nancy asks for further understanding. Bernard clarifies: RFC 2868 states “standards action” and 3575 is more lenient in saying just expert review.
- Now Dan remembers: when there’s conflicts such as this, 2 solutions: take the stricter or take the latest. But if it’s the latest, then it needs to be clearer. Believes in this case, explicit clarification is justified since 3575 is more recent and the request is justified. But need IESG perspective review by WG.
- Bernard suggests to get a sense of this group and then take it to the mailgroup.
Asks: proposal is to accept and verify the errata and update 3575 to include 2868.
In favor: 10, non oppose. Given consensus, will take to the mail list.

RFC 3580, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", September 2003

Note: This RFC has been updated by RFC 7268

Source of RFC: INDEPENDENT

Errata ID: 1503
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Avi Lior
Date Reported: 2008-09-12
Verifier Name: Nevil Brownlee
Date Verified: 2010-04-03

Section 3.21 says:

For IEEE 802.1X Authenticators, this attribute is used to store the
   Supplicant MAC address in ASCII format (upper case only), with octet
   values separated by a "-".  Example: "00-10-A4-23-19-C0".

It should say:

For IEEE Std 802.1X-2001 authenticators, this attribute is used to store
the Supplicant MAC address, represented as an ASCII character string in
Canonical format (see IEEE Std 802). For example, "00-10-A4-23-19-C0".

Notes:

The IETF Informational RFC needed to specify that the representation of the MAC address is in Canonical Format.

This is the case in the IEEE document 802_1x-2001 which is the corrected text provided.

I would be okay if the authors wanted to use Supplicant MAC address instead of "bridge or Access Point" in the proposed corrected text.

Errata ID: 4484
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nick Lowe
Date Reported: 2015-09-27
Verifier Name: Nevil Brownlee
Date Verified: 2016-03-17

Section 2.2 says:

   The purpose of this attribute is to make it possible to link together
   multiple related sessions.  While [IEEE8021X] does not act on
   aggregated ports, it is possible for a Supplicant roaming between
   Access Points to cause multiple RADIUS accounting packets to be sent
   by different Access Points.

It should say:

   The purpose of this attribute is to make it possible to link together
   multiple related sessions.  While [IEEE8021X] does not act on
   aggregated ports, it is possible for a Supplicant roaming between
   Basic Service Sets to cause multiple RADIUS accounting packets to be
   sent by the same or different Access Points.

Notes:

This was written in the context of an Access Point only offering a single Basic Service Set, predating Access Points containing multiple radios or supporting Virtual Access Points. It is not accurate today.

Errata ID: 4491
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nick Lowe
Date Reported: 2015-10-04
Verifier Name: Nevil Brownlee
Date Verified: 2016-03-17

Section 3.20 says:

Called-Station-Id

   For IEEE 802.1X Authenticators, this attribute is used to store the
   bridge or Access Point MAC address in ASCII format (upper case only),
   with octet values separated by a "-".  Example: "00-10-A4-23-19-C0".
   In IEEE 802.11, where the SSID is known, it SHOULD be appended to the
   Access Point MAC address, separated from the MAC address with a ":".
   Example "00-10-A4-23-19-C0:AP1".

It should say:

Called-Station-Id

   For IEEE 802.1X Authenticators, this attribute is used to store the
   bridge MAC address or IEEE 802.11 BSSID (upper case only), with octet
   values separated by a "-".  Example: "00-10-A4-23-19-C0".
   In IEEE 802.11, where the SSID is known, it SHOULD be appended to the
   BSSID, separated from the BSSID with a ":".
   Example "00-10-A4-23-19-C0:AP1".

   The Called-Station-Id MUST be UTF-8 encoded.

Notes:

The RFC was written in the context of an Access Point only offering a
single Basic Service Set, predating and not anticipating Access Points
containing multiple radios or supporting Virtual Access Points. It is
not accurate today and the RFC should originally have stated a Basic
Service Set. It was an error to not state this.

This errata, however, emphatically does not change the original
meaning or intention of the RFC. Basic Service Set was always meant.

Since 802.11 SSIDs may be UTF-8 encoded, the Called-Station-Id MUST always be treated as being UTF-8 encoded in the context of 802.1X to accommodate 802.11 where the SSID has been appended. (This inherently encodes the bridge MAC address or IEEE 802.11 BSSID as ASCII would.)

RFC 3588, "Diameter Base Protocol", September 2003

Note: This RFC has been obsoleted by RFC 6733

Note: This RFC has been updated by RFC 5729, RFC 5719, RFC 6408

Source of RFC: aaa (ops)

Errata ID: 773
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alan McNamee
Date Reported: 2006-04-13
Verifier Name: Dan Romascanu
Date Verified: 2009-09-09

 

AVP Format

   <Vendor-Specific-Application-Id> ::=3D < AVP Header: 260 >
                                     1* [ Vendor-Id ]
                                     0*1{ Auth-Application-Id }
                                     0*1{ Acct-Application-Id }

Notes:

for 1* [ Vendor-Id ], is it required or optional?=20
In my understanding, [ ] represent "optional", which means allowing none =
of=20
this type AVP appear, but 1* means at least one needed, Is it =
inconsistent?
The same problem for 0*1{ Auth-Application-Id } and 0*1{ =
Acct-Application-Id }.

Can it is be issued as RFC bug for RFC errata?

from pending

Errata ID: 1429
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Parveen Verma
Date Reported: 2008-05-25
Verifier Name: Dan Romascanu
Date Verified: 2009-09-09

Section 11.4.1 says:

11.4.1. Result-Code AVP Values


   As defined in Section 7.1, the Result-Code AVP (AVP Code 268) defines
   the values 1001, 2001-2002, 3001-3010, 4001-4002 and 5001-5017.

   All remaining values are available for assignment via IETF Consensus
   [IANA].

It should say:

11.4.1. Result-Code AVP Values


   As defined in Section 7.1, the Result-Code AVP (AVP Code 268) defines
   the values 1001, 2001-2002, 3001-3010, 4001-4003 and 5001-5017.

   All remaining values are available for assignment via IETF Consensus
   [IANA].

Notes:

7.1.4. Transient Failures

......
DIAMETER_AUTHENTICATION_REJECTED 4001
......
DIAMETER_OUT_OF_SPACE 4002
......
ELECTION_LOST 4003
The peer has determined that it has lost the election process and
has therefore disconnected the transport connection.

For Transient Failures we have error code 4001-4003 defined but the IANA consideration part says only 4001-4002, which can mean the value 4003 is free, but 4003 is assigned to ELECTION_LOST hence error.

Errata ID: 2817
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Vinay parashar
Date Reported: 2011-05-28
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02

Section 5.5.2 says:

There is no valid avp named[ Original-State-Id ].

in DWA message [ Original-State-Id ] should be replaced by [ Origin-State-Id ]
Message Format
<DWA> ::= < Diameter Header: 280 >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Error-Message ]
* [ Failed-AVP ]
[ Original-State-Id ]

It should say:

 Message Format
<DWA> ::= < Diameter Header: 280 >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Error-Message ]
* [ Failed-AVP ]
[ Origin-State-Id ]

Errata ID: 3280
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Hans Liu
Date Reported: 2012-07-04
Verifier Name: Benoit Claise
Date Verified: 2012-07-17

Section 5.6 says:

Section 5.6 says for both I- and R-:

Open - "Rcv-DPR" - "Snd-DPA,Disc" - "Closed"  

It should say:

Per section 5.4, the receiver of the Disconnect-Peer-Answer 
initiates the transport disconnect, so it should say, for 
both I- and R-:

Open - "Rcv-DPR" - "Snd-DPA" - "Closing"  

Notes:

In RFC3588bis-34, section 5.4 states more clearly as below

The receiver of the Disconnect-Peer-Answer initiates the transport disconnect. The sender of the Disconnect-Peer-Answer should be able to detect the transport closure and cleanup the connection.

Errata ID: 250
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alan McNamee
Date Reported: 2004-10-02

Section 8.3.2 says:

   Message Format

      <RAA>  ::= < Diameter Header: 258, PXY >
                 < Session-Id >
                 { Result-Code }
                 { Origin-Host }
                 { Origin-Realm }
                 [ User-Name ]
                 [ Origin-State-Id ]
                 [ Error-Message ]
                 [ Error-Reporting-Host ]
               * [ Failed-AVP ]
               * [ Redirect-Host ]
                 [ Redirect-Host-Usage ]
                 [ Redirect-Host-Cache-Time ]
               * [ Proxy-Info ]
               * [ AVP ]

It should say:

   Message Format

      <RAA>  ::= < Diameter Header: 258, PXY >
                 < Session-Id >
                 { Result-Code }
                 { Origin-Host }
                 { Origin-Realm }
                 [ User-Name ]
                 [ Origin-State-Id ]
                 [ Error-Message ]
                 [ Error-Reporting-Host ]
               * [ Failed-AVP ]
               * [ Redirect-Host ]
                 [ Redirect-Host-Usage ]
                 [ Redirect-Max-Cache-Time ]
               * [ Proxy-Info ]
               * [ AVP ]

Notes:

Errata ID: 251
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alan McNamee
Date Reported: 2004-10-02

Section 5.5.2 says:

   Message Format

      <DWA>  ::= < Diameter Header: 280 >
                 { Result-Code }
                 { Origin-Host }
                 { Origin-Realm }
                 [ Error-Message ]
               * [ Failed-AVP ]
                 [ Original-State-Id ]

It should say:

   Message Format

      <DWA>  ::= < Diameter Header: 280 >
                 { Result-Code }
                 { Origin-Host }
                 { Origin-Realm }
                 [ Error-Message ]
               * [ Failed-AVP ]
                 [ Origin-State-Id ]

Notes:

Errata ID: 3266
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jack Teng
Date Reported: 2012-06-25
Verifier Name: RonBonica
Date Verified: 2012-06-28

Section 5.4. says:

The Disconnection-Reason AVP contains the reason the Diameter node 
issued the Disconnect-Peer-Request message.

It should say:

The Disconnect-Cause AVP contains the reason the Diameter node 
issued the Disconnect-Peer-Request message.

Notes:

(There is no such AVP named Disconnection-Reason)

RFC 3589, "Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5", September 2003

Source of RFC: INDEPENDENT

Errata ID: 4310
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alexander Okonnikov
Date Reported: 2015-03-23
Verifier Name: Nevil Brownlee
Date Verified: 2015-06-30

Section ToC says:

...
   4.  Acknowledgements............................................... 3
   5.  Intellectual Property Statement................................ 3
...

It should say:

...
   4.  Intellectual Property Statement................................ 3
   5.  Acknowledgements............................................... 3
...

Notes:

Interchanged references to sections 4 and 5.

RFC 3597, "Handling of Unknown DNS Resource Record (RR) Types", September 2003

Note: This RFC has been updated by RFC 4033, RFC 4034, RFC 4035, RFC 5395, RFC 6195, RFC 6895

Source of RFC: dnsext (int)

Errata ID: 1063
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Koch
Date Reported: 2005-09-13
Verifier Name: Brian Haberman
Date Verified: 2012-05-01

Section 7 says:

   As a courtesy to implementors, it is hereby noted that the complete
   set of such previously published RR types that contain embedded
   domain names, and whose DNSSEC canonical form therefore involves
   downcasing according to the DNS rules for character comparisons,
   consists of the RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
   HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV,
   DNAME, and A6.

It should say:

[not supplied]

Notes:

Compare with RFC 4034 (section 6.2):

"3. if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX,
SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in
the DNS names contained within the RDATA are replaced by the
corresponding lowercase US-ASCII letters;"

Almost exactly the same list. One HINFO too much is no issue,
but if this actually should be TXT it's a real typo.

neither TXT nor HINFO contain domain names in RDATA, so it's a bug in both
RFC 3597 and 4034, although one that doesn't hurt. One could also argue that the list lacks NSAP-PTR, but then that's as obsolete as MD ans MF.

RFC 3605, "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", October 2003

Source of RFC: mmusic (rai)

Errata ID: 1050
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexandre Machado
Date Reported: 2007-09-13
Verifier Name: Cullen Jennings
Date Verified: 2009-01-08

Section 2.1 says:

   rtcp-attribute =  "a=rtcp:" port  [nettype space addrtype space
                         connection-address] CRLF

It should say:

   rtcp-attribute =  "a=rtcp:" port  [space nettype space addrtype space
                         connection-address] CRLF

Notes:

There must be a space between "port" and "nettype".

RFC 3611, "RTP Control Protocol Extended Reports (RTCP XR)", November 2003

Source of RFC: avt (rai)

Errata ID: 1759
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Timur Friedman
Date Reported: 2009-04-07
Verifier Name: Cullen Jennings
Date Verified: 2009-04-07

Section 6.3 says:

"recv-rtt"

It should say:

"rcvr-rtt"

Notes:

Sec. 6.3 describes the SDP attribute in Sec. 5.1, but erroneously calls it "recv-rtt" whereas it is in fact "rcvr-rtt". The IANA, following Sec. 6.3, had recorded "recv-rtt" but has corrected this and now records "rcvr-rtt".

Errata ID: 3795
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Stephen James
Date Reported: 2013-11-11
Verifier Name: Ben Campbell
Date Verified: 2015-07-22

Section 5.1 says:

rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF

It should say:

rtcp-xr-attrib = "a=" "rtcp-xr" [ ":" xr-format *(SP xr-format)] CRLF

Notes:

The ABNF for the attribute is causing some interoperability issues.
The text as written shows that the colon is required while the parameters are optional.
This leaves the format: "a=rtcp-xr:" the required format. Vendors are using "a=rtcp-xr" which strictly violates the ABNF above. Moving the ':' into the optional part seems correct.

Errata ID: 4597
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Liu Yuanlong
Date Reported: 2016-01-22
Verifier Name: Ben Campbell
Date Verified: 2016-05-25

Section 4.7.2 says:

burst density 84, which corresponds to 33%

It should say:

burst density 85, which corresponds to 33%

Notes:

error calculation for burst density, burst density=4/12*256=85.33...?85

RFC 3625, "The QCP File Format and Media Types for Speech Data", September 2003

Source of RFC: INDEPENDENT

Errata ID: 249
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Richard Walters
Date Reported: 2005-08-30

Section 3 says:

    VRAT            = %x76 %x72 %x61 %x74

Notes:

This rule is important because without it, it isn't clear whether the
"vrat" string is capitalized (like "RIFF" and "QLCM") or not (like
"fmt " and "data").

Errata ID: 3383
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tom Ritter
Date Reported: 2012-10-18
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-16

Section 3 says:

   rate-map-table  = 8rate-map-entry

It should say:

   rate-map-table  = *rate-map-entry

Notes:

I believe this is a simple typo specifying that there are num-rates number of rate-map-entries

Yes. Something like n-rate-map-entries would be even clearer (* implies a pointer to me)

RFC 3627, "Use of /127 Prefix Length Between Routers Considered Harmful", September 2003

Note: This RFC has been obsoleted by RFC 6547

Source of RFC: INDEPENDENT

Errata ID: 2465
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Fernando Gont
Date Reported: 2010-08-15
Verifier Name: Nevil Brownlee
Date Verified: 2012-11-05

Section 6.2 says:

   [ICMPv3]    Conta, A., Deering, S., "Internet Control Message
               Protocol (ICMPv6)", Work in Progress.

It should say:

   [ICMPv6]    Conta, A., Deering, S., "Internet Control Message
               Protocol (ICMPv6)", Work in Progress.

Notes:

Pointer to this reference should be fixed accordingly (i.e., s/ICMPv3/ICMPv6/ across the document)

RFC 3633, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", December 2003

Note: This RFC has been obsoleted by RFC 8415

Note: This RFC has been updated by RFC 6603, RFC 7550

Source of RFC: dhc (int)

Errata ID: 2468
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ole Troan
Date Reported: 2010-08-17
Verifier Name: Ralph Droms
Date Verified: 2013-03-09

Section 12.1 / 12.2 says:

 Section 12.1:
   Upon the receipt of a valid Reply message, for each IA_PD the
   requesting router assigns a subnet from each of the delegated
   prefixes to each of the links to which the associated interfaces are
   attached, with the following exception: the requesting router MUST
   NOT assign any delegated prefixes or subnets from the delegated
   prefix(es) to the link through which it received the DHCP message
   from the delegating router.

It should say:

 Section 12.1:
   Upon the receipt of a valid Reply message, for each IA_PD the
   requesting router assigns a subnet from each of the delegated
   prefixes to each of the links to which the associated interfaces are
   attached.

New last paragraph of 12.2:
  When the DR delegates prefixes to a Requesting Router, the
  Requesting Router has sole authority for assignment of those
  prefixes, and the Delegating Router MUST NOT assign any prefixes
  from that delegated prefix to any of its own links.

Notes:

This change clarifies that the authority over the address space is delegated to the RR (Requesting Router). Moving the use restriction for the address space from the DR (Delegating Router) to the RR (Requesting Router).

2011-08-02: Notes updated per request from Ole Troan and Leaf Yeh.

Errata ID: 2469
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ole Troan
Date Reported: 2010-08-17
Verifier Name: Ralph Droms
Date Verified: 2013-03-09

Section 11.1 says:

The requesting router MUST ignore any Advertise message that includes
a Status Code option containing the value NoPrefixAvail, with the
exception that the requesting router MAY display the associated
status message to the user.

It should say:

The requesting router MUST ignore any IA_PDs in an Advertise message
that includes a Status Code option containing the value NoPrefixAvail, 
with the exception that the requesting router MAY display the 
associated status message to the user.

Errata ID: 2470
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ole Troan
Date Reported: 2010-08-17
Verifier Name: Ralph Droms
Date Verified: 2013-03-09

Section 11.2 says:

If the delegating router will not assign any prefixes to any IA_PDs
in a subsequent Request from the requesting router, the delegating
router MUST send an Advertise message to the requesting router that
includes the IA_PD with no prefixes in the IA_PD and a Status Code
option in the IA_PD containing status code NoPrefixAvail and a status
message for the user, a Server Identifier option with the delegating
router's DUID and a Client Identifier option with the requesting
router's DUID.

It should say:

If the delegating router will not assign any prefixes to an IA_PD
in a subsequent Request from the requesting router, the delegating
router MUST send an Advertise message to the requesting router that
includes the IA_PD with no prefixes in the IA_PD and a Status Code
option in the IA_PD containing status code NoPrefixAvail and a status
message for the user, a Server Identifier option with the delegating
router's DUID and a Client Identifier option with the requesting
router's DUID. The server SHOULD include other stateful IA options
(like IA_NA) and other configuration options in the Advertise message.

Notes:

Edited by Ralph Droms on 2010-08-20 to correct reference to IA_NA (was IA_PD) in last line.

RFC 3642, "Common Elements of Generic String Encoding Rules (GSER) Encodings", October 2003

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 5136
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Smith
Date Reported: 2017-10-03
Verifier Name: Adrian Farrel
Date Verified: 2018-04-14

Section 5 says:

      day     =   ( %x30 %x31-39 )    ; "01" to "09"
                / ( %x31-32 %x30-39 ) ; "10" to "29"
                / ( %x32 %x30-31 )    ; "30" to "31"

It should say:

      day     =   ( %x30 %x31-39 )    ; "01" to "09"
                / ( %x31-32 %x30-39 ) ; "10" to "29"
                / ( %x33 %x30-31 )    ; "30" to "31"

Notes:

The day value incorrectly includes values 01 to 09, 10 to 29 and then 20 to 21. The last field should instead allow for values 30 to 31.

RFC 3647, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", November 2003

Source of RFC: pkix (sec)

Errata ID: 247
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Daniel Montpetit
Date Reported: 2004-04-21

On page 68, it says:

   ------------------------------------------------------
   4.6.6 Archive Collection System
         (Internal or External)                 5.5.6
   ------------------------------------------------------
   4.6.6 Procedures to Obtain and
         Verify Archive Information             5.5.7
   ------------------------------------------------------

It should say:

   ------------------------------------------------------
   4.6.6 Archive Collection System
         (Internal or External)                 5.5.6
   ------------------------------------------------------
   4.6.7 Procedures to Obtain and
         Verify Archive Information             5.5.7
   ------------------------------------------------------

Errata ID: 7278
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Preston Locke
Date Reported: 2022-12-19
Verifier Name: RFC Editor
Date Verified: 2022-12-19

Section 7 says:

In particular, representatives of the ISC made changes to the framework to better suite it to the legal environment and make it more accessible to lawyers.

It should say:

In particular, representatives of the ISC made changes to the framework to better suit it to the legal environment and make it more accessible to lawyers.

Notes:

r/suite/suit

RFC 3650, "Handle System Overview", November 2003

Source of RFC: INDEPENDENT

Errata ID: 4466
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Message
Date Reported: 2015-09-07
Verifier Name: Nevil Brownlee
Date Verified: 2016-03-17

Section 10 says:

[1] Kahn, R. and R. Wilensky, "A Framework for Distributed 
Digital Object Services", D-Lib Magazine, 1995.

It should say:

1] Kahn, R. and R. Wilensky, "A Framework for Distributed 
Digital Object Services", D-Lib Magazine, 1995.
This paper is now out of print.  A more recent version of it is
accessible at
https://www.doi.org/topics/2006_05_02_Kahn_Framework.pdf

Notes:

A search of the on-line index to that Journal,
http://www.dlib.org/author-index.html#K,
for that article fails.

Per the Managing Editor of D-Lib Magazine (in March 2016):

A correct citation for the original paper in the RFC should simply be:

Kahn, Robert E., Robert Wilensky, "A Framework for Distributed Digital Object Services", May 1995. http://hdl.handle.net/4263537/5001.

RFC 3651, "Handle System Namespace and Service Definition", November 2003

Source of RFC: INDEPENDENT

Errata ID: 3966
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dale Worley
Date Reported: 2014-04-16
Verifier Name: Nevil Brownlee
Date Verified: 2014-12-22

Section 3 says:

       <NamingAuthority> = *(<NamingAuthority>  ".") <NAsegment>

It should say:

       <NamingAuthority> = *(<NAsegment>  ".") <NAsegment>

Notes:

Strictly speaking, this is an editorial change because the corrected
BNF generates the same strings as the original BNF. But the corrected
BNF is far easier for the reader to understand; it matches how people
think about the syntax.

RFC 3659, "Extensions to FTP", March 2007

Source of RFC: ftpext (app)

Errata ID: 899
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-04-14
Verifier Name: RFC Editor
Date Verified: 2007-11-02

Section 6.5 says:

   That those pathnames all exist does not imply that the TVFS sever
   will necessarily grant any kind of access rights to the named paths,
   or that access to the same file via different pathnames will
   necessarily be granted equal rights.

It should say:

   That those pathnames all exist does not imply that the TVFS server
   will necessarily grant any kind of access rights to the named paths,
   or that access to the same file via different pathnames will
   necessarily be granted equal rights.

Notes:

typo: sever --> server

from pending

Errata ID: 900
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-04-14
Verifier Name: RFC Editor
Date Verified: 2007-11-02

Section 7 says:

   The MLST and MLSD commands also extend the FTP protocol as presented
   in STD 9, RFC 959 [3] and STD 3, RFC 1123 [9] to allow that
   transmission of 8-bit data over the control connection.

It should say:

   The MLST and MLSD commands also extend the FTP protocol as presented
   in STD 9, RFC 959 [3] and STD 3, RFC 1123 [9] to allow the
   transmission of 8-bit data over the control connection.

Notes:

typo: that --> the

from pending

Errata ID: 6252
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Simon Kissane
Date Reported: 2020-08-08
Verifier Name: Orie Steele
Date Verified: 2024-03-29

Section 10.2 says:

To add a file type to this OS specific registry of OS specific file types, an applicant must send to the IANA a request, in which is specified the OS name, the OS specific file type, a definition of the syntax of the fact value, which must conform to the syntax of a token as given in this document, and a specification of the semantics to be associated with the particular fact and its values.

It should say:

To add a file type to this OS specific registry of OS specific file types, an applicant must send to the IANA a request, in which is specified the OS name, the OS specific file type, and a specification of the semantics to be associated with the particular OS specific file type.

Notes:

It appears that the text in section 10.2 has been copy/pasted from section 10.1, without applying the necessary adjustments for the differences between OS-specific facts and OS-specific filetypes. While OS-specific facts do have values (see section 7.2), there is no concept of a "value" of an OS-specific filetype defined in the RFC (see section 7.5.1.5).

This error effectively makes it impossible to register an OS-specific filetype with IANA, were IANA to follow the wording of the RFC to the letter – IANA must demand a "definition of the syntax of the fact value" for every filetype registration, despite the fact that request makes no sense for a filetype as defined in the RFC.

RFC 3665, "Session Initiation Protocol (SIP) Basic Call Flow Examples", December 2003

Source of RFC: sipping (rai)

Errata ID: 2740
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Niels Widger
Date Reported: 2011-03-02
Verifier Name: Robert Sparks
Date Verified: 2011-03-03

Section 3.8 says:

   F11 CANCEL Proxy 1 -> Proxy 2

   CANCEL sip:alice@atlanta.example.com SIP/2.0
   Via: SIP/2.0/UDP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1
   Max-Forwards: 70
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 1 CANCEL
   Content-Length: 0

It should say:

   F11 CANCEL Proxy 1 -> Proxy 2

   CANCEL sip:bob@biloxi.example.com SIP/2.0
   Via: SIP/2.0/UDP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1
   Max-Forwards: 70
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 1 CANCEL
   Content-Length: 0

Notes:

The Request-URI of message F11 is incorrect according to RFC 3261 Section 9.1: "The following procedures are used to construct a CANCEL request. The Request-URI, Call-ID, To, the numeric part of CSeq, and From header fields in the CANCEL request MUST be identical to those in the request being cancelled, including tags".

Errata ID: 3295
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: David Waiting
Date Reported: 2012-07-26
Verifier Name: Gonzalo Camarillo
Date Verified: 2013-04-03

Section 3.8. says:

F18 ACK Proxy 1 -> Proxy 2

ACK sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 ACK
Content-Length: 0

It should say:

F18 ACK Proxy 1 -> Proxy 2

ACK sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 ACK
Content-Length: 0

Notes:

Proxy 1 includes an incorrect Via header in the ACK.

Errata ID: 4047
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Gergely Szabo
Date Reported: 2014-07-11
Verifier Name: Francesca Palombini
Date Verified: 2023-11-09

Section 2.1 says:

   F3 REGISTER Bob -> SIP Server

   REGISTER sips:ss2.biloxi.example.com SIP/2.0
   Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashd92
   Max-Forwards: 70
   From: Bob <sips:bob@biloxi.example.com>;tag=ja743ks76zlflH
   To: Bob <sips:bob@biloxi.example.com>
   Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
   CSeq: 2 REGISTER
   Contact: <sips:bob@client.biloxi.example.com>
   Authorization: Digest username="bob", realm="atlanta.example.com"
    nonce="ea9c8e88df84f1cec4341ae6cbe5a359", opaque="",
    uri="sips:ss2.biloxi.example.com",
    response="dfe56131d1958046689d83306477ecc"
   Content-Length: 0

It should say:

   F3 REGISTER Bob -> SIP Server

   REGISTER sips:ss2.biloxi.example.com SIP/2.0
   Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashd92
   Max-Forwards: 70
   From: Bob <sips:bob@biloxi.example.com>;tag=ja743ks76zlflH
   To: Bob <sips:bob@biloxi.example.com>
   Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
   CSeq: 2 REGISTER
   Contact: <sips:bob@client.biloxi.example.com>
   Authorization: Digest username="bob", realm="atlanta.example.com",
    nonce="ea9c8e88df84f1cec4341ae6cbe5a359", opaque="",
    uri="sips:ss2.biloxi.example.com",
    response="dfe56131d1958046689d83306477ecc"
   Content-Length: 0

Notes:

A comma (,) is missing before the 'nonce' parameter of the Authorization header.

RFC 3666, "Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows", December 2003

Source of RFC: sipping (rai)

Errata ID: 728
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mani Devarajan
Date Reported: 2005-01-11
Verifier Name: Cullen Jennings
Date Verified: 2009-01-08

Section 3.1 says:

F2 INVITE Alice -> Proxy1

It should say:

F2 INVITE NGW 1 -> Proxy1

RFC 3677, "IETF ISOC Board of Trustee Appointment Procedures", December 2003

Source of RFC: IAB

Errata ID: 2807
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Pete Resnick
Date Reported: 2011-05-13
Verifier Name: Olaf Kolkman
Date Verified: 2011-07-24

Throughout the document, when it says:

Category: Standards Track

It should say:

Category: Best Current Practice

RFC 3678, "Socket Interface Extensions for Multicast Source Filters", January 2004

Source of RFC: magma (int)

Errata ID: 2524
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: YOSHIFUJI Hideaki
Date Reported: 2010-09-16
Verifier Name: Brian Haberman
Date Verified: 2012-04-27

Section 5.2.2 says:

   The interface argument holds the local IP address of the interface.

It should say:

   The interface argument holds the interface index of the interface.

Notes:

See Section 5.2.1.

Errata ID: 1395
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dave Thaler
Date Reported: 2008-03-27
Verifier Name: Brian Haberman
Date Verified: 2012-04-26

Section 5.1 says:

The rules for generating errors are the same as those given in
Section 5.1.3.

It should say:

The rules for generating errors are the same as those given in
Section 4.1.3.

Notes:

There is no section 5.1.3.

RFC 3680, "A Session Initiation Protocol (SIP) Event Package for Registrations", March 2004

Note: This RFC has been updated by RFC 6140

Source of RFC: sipping (rai)

Errata ID: 3494
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Brett Tate
Date Reported: 2013-02-24
Verifier Name: Gonzalo Camarillo
Date Verified: 2013-04-03

Section 6 says:

   NOTIFY sip:app.example.com SIP/2.0
   Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii
   From: sip:joe@example.com;tag=xyzygg
   To: sip:app.example.com;tag=123aa9
   Call-ID: 9987@app.example.com
   CSeq: 1288 NOTIFY
   Contact: sip:server19.example.com
   Event: reg
   Max-Forwards: 70
   Content-Type: application/reginfo+xml
   Content-Length: ...

   NOTIFY sip:app.example.com SIP/2.0
   Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaij
   From: sip:joe@example.com;tag=xyzygg
   To: sip:app.example.com;tag=123aa9
   Call-ID: 9987@app.example.com
   CSeq: 1289 NOTIFY
   Contact: sip:server19.example.com
   Event: reg
   Max-Forwards: 70
   Content-Type: application/reginfo+xml
   Content-Length: ...

It should say:

   NOTIFY sip:app.example.com SIP/2.0
   Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii
   From: sip:joe@example.com;tag=xyzygg
   To: sip:app.example.com;tag=123aa9
   Call-ID: 9987@app.example.com
   CSeq: 1288 NOTIFY
   Contact: sip:server19.example.com
   Event: reg
   Subscription-State:active;expires=3600
   Max-Forwards: 70
   Content-Type: application/reginfo+xml
   Content-Length: ...

   NOTIFY sip:app.example.com SIP/2.0
   Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaij
   From: sip:joe@example.com;tag=xyzygg
   To: sip:app.example.com;tag=123aa9
   Call-ID: 9987@app.example.com
   CSeq: 1289 NOTIFY
   Contact: sip:server19.example.com
   Event: reg
   Subscription-State:active;expires=3000
   Max-Forwards: 70
   Content-Type: application/reginfo+xml
   Content-Length: ...

Notes:

The two NOTIFY examples are missing mandatory Subscription-State header.

RFC 3696, "Application Techniques for Checking and Transformation of Names", February 2004

Source of RFC: INDEPENDENT

Errata ID: 246
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John C. Klensin
Date Reported: 2005-07-09

Section 3 says:

   The exact rule is that any ASCII character, including control
   characters, may appear quoted, or in a quoted string.  When quoting
   is needed, the backslash character is used to quote the following
   character.  For example

      Abc\@def@example.com

   is a valid form of an email address.  Blank spaces may also appear,
   as in

      Fred\ Bloggs@example.com

   The backslash character may also be used to quote itself, e.g.,

      Joe.\\Blow@example.com

It should say:

   The exact rule is that any ASCII character, including control
   characters, may appear quoted, or in a quoted string.  When quoting
   is needed, the backslash character is used to quote the following
   character.  For example

      "Abc\@def"@example.com

   is a valid form of an email address.  Blank spaces may also appear,
   as in

      "Fred\ Bloggs"@example.com

   The backslash character may also be used to quote itself, e.g.,

      "Joe.\\Blow"@example.com

Errata ID: 1003
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John C. Klensin
Date Reported: 2005-07-09

Section 3 says:

   In addition to restrictions on syntax, there is a length limit on
   email addresses.  That limit is a maximum of 64 characters (octets)
   in the "local part" (before the "@") and a maximum of 255 characters
   (octets) in the domain part (after the "@") for a total length of 320
   characters.  Systems that handle email should be prepared to process
   addresses which are that long, even though they are rarely
   encountered.

It should say:

   In addition to restrictions on syntax, there is a length limit on
   email addresses.  That limit is a maximum of 64 characters (octets)
   in the "local part" (before the "@") and a maximum of 255 characters
   (octets) in the domain part (after the "@") for a total length of 320
   characters. However, there is a restriction in RFC 2821 on the length of an
   address in MAIL and RCPT commands of 256 characters.  Since addresses
   that do not fit in those fields are not normally useful, the upper
   limit on address lengths should normally be considered to be 256.

   

Errata ID: 1004
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Charles Curran
Date Reported: 2007-09-09
Verifier Name: John C. Klensin
Date Verified: 2007-09-09

Section 4.3 says:

   +-------------------------+-----------------------------+-----------+
   |      Email address      |         MAILTO URL          |   Notes   |
   +-------------------------+-----------------------------+-----------+
   |     Joe@example.com     |  mailto:joe@example.com     |     1     |

...

   Notes on Table

   1.  No characters appear in the email address that require escaping,
       so the body of the MAILTO URL is identical to the email address.

It should say:

   +-------------------------+-----------------------------+-----------+
   |      Email address      |         MAILTO URL          |   Notes   |
   +-------------------------+-----------------------------+-----------+
   |     Joe@example.com     |  mailto:Joe@example.com     |     1     |

...

   Notes on Table

   1.  No characters appear in the email address that
       require escaping, so the body of the MAILTO URL is
       identical to the email address.  Because the local part
       of email addresses may be treated as case-sensitive by
       the system hosting the mailbox (see RFC 2821, Section
       4.1.2), "mailto:joe@example.com" would not be a valid
       URL for the mailbox Joe@example.com even though, if the
       recommendations of RFC 2821 are followed, it would work
       as a synonym.  See also Section 6.2.3 of RFC 3986.

Errata ID: 1690
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Dominic Sayers
Date Reported: 2009-02-22
Verifier Name: Nevil Brownlee
Date Verified: 2010-04-03

Section 3 says:

(from erratum 1003)

In addition to restrictions on syntax, there is a length limit on
   email addresses.  That limit is a maximum of 64 characters (octets)
   in the "local part" (before the "@") and a maximum of 255 characters
   (octets) in the domain part (after the "@") for a total length of 320
   characters. However, there is a restriction in RFC 2821 on the length of an
   address in MAIL and RCPT commands of 256 characters.  Since addresses
   that do not fit in those fields are not normally useful, the upper
   limit on address lengths should normally be considered to be 256.

It should say:

In addition to restrictions on syntax, there is a length limit on
   email addresses.  That limit is a maximum of 64 characters (octets)
   in the "local part" (before the "@") and a maximum of 255 characters
   (octets) in the domain part (after the "@") for a total length of 320
   characters. However, there is a restriction in RFC 2821 on the length of an
   address in MAIL and RCPT commands of 254 characters.  Since addresses
   that do not fit in those fields are not normally useful, the upper
   limit on address lengths should normally be considered to be 254.

Notes:

I believe erratum ID 1003 is slightly wrong. RFC 2821 places a 256 character limit on the forward-path. But a path is defined as

Path = "<" [ A-d-l ":" ] Mailbox ">"

So the forward-path will contain at least a pair of angle brackets in addition to the Mailbox. This limits the Mailbox (i.e. the email address) to 254 characters.

Errata ID: 3563
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: David Hoerl
Date Reported: 2013-03-22
Verifier Name: Nevil Brownlee
Date Verified: 2014-02-03

Section 3.4 says:

Section 3 says:

   The exact rule is that any ASCII character, including control
   characters, may appear quoted, or in a quoted string.  When quoting
   is needed, the backslash character is used to quote the following
   character.  For example

      Abc\@def@example.com

   is a valid form of an email address.  Blank spaces may also appear,
   as in

      Fred\ Bloggs@example.com

   The backslash character may also be used to quote itself, e.g.,

      Joe.\\Blow@example.com

It should say:

Section 3 says:

   The exact rule is that any ASCII character, including control
   characters, may appear quoted, or in a quoted string.  When quoting
   is needed, the backslash character is used to quote the following
   character.  For example

      Abc\@def@example.com
or      
      "Abc@def"@example.com

   is a valid form of an email address.  Blank spaces may also appear,
   as in

      Fred\ Bloggs@example.com
or      
      "Fred Bloggs"@example.com

   The backslash character may also be used to quote itself, e.g.,

      Joe.\\Blow@example.com
or      
      " Joe.\Blow"@example.com

Notes:

Errata 246 is clearly wrong. The author changed the quoting to make it appear backslash quoting was required to use a single backquote. This is totally wrong, and contradicts the RFC text:

"may appear quoted, or in a quoted string".

I tested today with several mailers sending to the google pseudo-alias of first.last+note@gmail.com, where note can be arbitrary text. By testing numerous versions of quoting I was able to see that my corrected text was what appeared in the destination email.

RFC 3700, "Internet Official Protocol Standards", July 2004

Note: This RFC has been obsoleted by RFC 5000

Source of RFC: INDEPENDENT

Errata ID: 1350
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Shestakov Valerij
Date Reported: 2008-03-05
Verifier Name: Nevil Brownlee
Date Verified: 2010-04-03

Section In ToC says:

2.  Contacts . . . . . . . . . . . . . . . . . . . . . . . . . . .  2

It should say:

2.  Resources  . . . . . . . . . . . . . . . . . . . . . . . . . .  2

RFC 3712, "Lightweight Directory Access Protocol (LDAP): Schema for Printer Services", February 2004

Note: This RFC has been obsoleted by RFC 7612

Source of RFC: INDEPENDENT

Errata ID: 243

Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2004-09-06
Report Text:

[RFC2279] has been obsoleted by [RFC3629].  All citations to [RFC2279] should refer to [RFC3629].


      [RFC3629]   Yergeau, F., "UTF-8, a Transformation Format of ISO
                  10646", RFC 3629, STD 63, November 2003.

---

Errata ID: 244
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2004-09-06
Verifier Name: Bob Braden
Date Verified: 2007-11-12

Section 4.2 says:

     Note:  This attribute is based on 'printer-uri-supported', 'uri-
     authentication-supported', and `'uri-security-supported' (called the
     'Three Musketeers' because they are parallel ordered attributes)

It should say:

     Note:  This attribute is based on 'printer-uri-supported', 'uri-
     authentication-supported', and 'uri-security-supported' (called the
     'Three Musketeers' because they are parallel ordered attributes)

Notes:

Extraneous "`" in 2nd line.

Errata ID: 245
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2004-09-06
Verifier Name: Bob Braden
Date Verified: 2007-11-12

Section References says:

     
      [RFC2717]   Petke, R. and I. King, "Registration Procedures for URL
                  Scheme Names", RFC 2717, November 1999.

      [RFC2718]   Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke,
                  "Guidelines for new URL Schemes", BCP 19, RFC 2718,
                  November 1999.

      [RFC2978]   Freed, N. and J.Postel, "IANA Charset Registration
                  Procedures", RFC2978, October 2000.

It should say:

     
      [RFC2717]   Petke, R. and I. King, "Registration Procedures for URL
                  Scheme Names", RFC 2717, BCP 35, November 1999.

      [RFC2718]   Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke,
                  "Guidelines for new URL Schemes", RFC 2718, November
                  1999.

      [RFC2978]   Freed, N. and J.Postel, "IANA Charset Registration
                  Procedures", RFC2978, BCP 19, October 2000.

RFC 3715, "IPsec-Network Address Translation (NAT) Compatibility Requirements", March 2004

Source of RFC: ipsec (sec)

Errata ID: 242
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Matt Holdrege
Date Reported: 2004-03-13

Section 6.1 says:

   [RFC2663]    Srisuresh, P. and M. Holdredge, "IP Network Address
                Translator (NAT) Terminology and Considerations", RFC
                2663, August 1999.

It should say:

   [RFC2663]    Srisuresh, P. and M. Holdrege, "IP Network Address
                Translator (NAT) Terminology and Considerations", RFC
                2663, August 1999.

RFC 3720, "Internet Small Computer Systems Interface (iSCSI)", April 2004

Note: This RFC has been obsoleted by RFC 7143

Note: This RFC has been updated by RFC 3980, RFC 4850, RFC 5048, RFC 7146

Source of RFC: ips (tsv)

Errata ID: 241
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julian Satran
Date Reported: 2004-09-01

Section 3.2.6.1 says:

The only exception is if a discovery session (see Section 2.3 iSCSI Session Types) is to be established.

It should say:

The only exception is if a discovery session (see Section 3.3 iSCSI Session Types) is to be established.

Notes:

Section 2.3 --> Section 3.3

RFC 3728, "Definitions of Managed Objects for Very High Speed Digital Subscriber Lines (VDSL)", February 2004

Source of RFC: adslmib (ops)

Errata ID: 1791
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Smadar Tauber
Date Reported: 2009-06-03
Verifier Name: Dan Romascanu
Date Verified: 2009-06-10

Section 4 says:

UNITS definition of the following MIB objects, should change from dBm to dB.
That will also fix the conflict with the units appearing in the Description of these MIB objects (dB).

vdslPhysCurrSnrMgn
vdslPhysCurrAtn
vdslLineConfDownMaxSnrMgn
vdslLineConfDownMinSnrMgn
vdslLineConfDownTargetSnrMgn
vdslLineConfUpMaxSnrMgn
vdslLineConfUpMinSnrMgn
vdslLineConfUpTargetSnrMgn

Example of original text:
   vdslPhysCurrSnrMgn OBJECT-TYPE
       SYNTAX       Integer32 (-127..127)
       UNITS        "0.25dBm"
       MAX-ACCESS   read-only
       STATUS       current
       DESCRIPTION
           "Noise Margin as seen by this Vtu with respect to its
           received signal in 0.25dB.  The effective range is
           -31.75 to +31.75 dB."
       REFERENCE    "T1E1.4/2000-009R3, Part 1, common spec"
        ::= { vdslPhysEntry 5 }

It should say:

Example of corrected text:
   vdslPhysCurrSnrMgn OBJECT-TYPE
       SYNTAX       Integer32 (-127..127)
       UNITS        "0.25dB"
       MAX-ACCESS   read-only
       STATUS       current
       DESCRIPTION
           "Noise Margin as seen by this Vtu with respect to its
           received signal in 0.25dB.  The effective range is
           -31.75 to +31.75 dB."
       REFERENCE    "T1E1.4/2000-009R3, Part 1, common spec"
        ::= { vdslPhysEntry 5 }

Notes:

This Errata replaces errata 1788 (rejected because it did not include list of all MIB objects having this problem and could not be edited).
It was decided by the adslmib Forum, that the solution should be as described by this Errata.

RFC 3730, "Extensible Provisioning Protocol (EPP)", March 2004

Note: This RFC has been obsoleted by RFC 4930

Source of RFC: provreg (app)

Errata ID: 239
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: "Scott Hollenbeck"
Date Reported: 2004-11-22
Verifier Name: Alexey Melnikov
Date Verified: 2009-06-19

Section 2.9.2.3 says:

S:    <msgQ count="4" id="12346"/>

It should say:

S:    <msgQ count="4" id="12345"/>

Notes:

Author knows the best :-).

Errata ID: 240
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: "Scott Hollenbeck"
Date Reported: 2004-11-17
Verifier Name: Alexey Melnikov
Date Verified: 2009-06-19

Section 2.9.2.3 says:

A <poll> acknowledgement response notes the number of messages remaining in
the queue and the ID of the next message available for retrieval.

It should say:

A <poll> acknowledgement response notes the ID of the message that has been
acknowledged and the number of messages remaining in the queue.

Notes:

RFC 3733, "Extensible Provisioning Protocol (EPP) Contact Mapping", March 2004

Note: This RFC has been obsoleted by RFC 4933

Source of RFC: provreg (app)

Errata ID: 238
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Scott Hollenbeck
Date Reported: 2004-05-13

Section 3.2.4 says:

   S:    <result code="1000">
   S:      <msg>Command completed successfully</msg>

It should say:

   S:    <result code="1001">
   S:      <msg>Command completed successfully; action pending</msg>

RFC 3736, "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", April 2004

Note: This RFC has been obsoleted by RFC 8415

Source of RFC: dhc (int)

Errata ID: 3796
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ralph Droms
Date Reported: 2013-11-11
Verifier Name: Ted Lemon
Date Verified: 2014-03-02

Section 5.2 says:

   Client message: sent by a DHCP relay agent in a Relay-forward message
                   to carry the client message to a server (section 20)

   Server message: sent by a DHCP server in a Relay-reply message to
                   carry a response message to the relay agent (section
                   20)

It should say:

   Relay Message: sent by a DHCP relay agent in a Relay-forward
                  message to carry the client message to a server or
                  sent by a DHCP server in a Relay-reply message to
                  carry a response message to the relay agent (section
                  20)

Notes:

The correct name for the option carries in the Relay-forward message is "Relay Message". That option is shared by both Relay-forward and Relay-reply messages to carry a DHCPv6 message from or to (respectively) a DHCPv6 client.

I've marked this errata as "technical" because it might have an impact on implementations.

RFC 3739, "Internet X.509 Public Key Infrastructure: Qualified Certificates Profile", March 2004

Source of RFC: pkix (sec)

Errata ID: 3108
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Loïc Etienne
Date Reported: 2012-02-06
Verifier Name: Sean Turner
Date Verified: 2012-02-08

Section C.1.1.1. says:

GeneralizedTime : "197110141200Z"

It should say:

GeneralizedTime : "19711014120000Z"

Notes:

X.690
11 Restrictions on BER employed by both CER and DER
11.7 GeneralizedTime
11.7.2 The seconds element shall always be present.

In rfc 3739, C.3 DER-encoding, the second-zeroes are present:
... ..313937 31313031 34313230 3030305A ...
They are just missing in the string representation above.

Additionally RFC 5280 requires the second-zeroes be present.

Errata ID: 7589
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Piotr Popis
Date Reported: 2023-08-03
Verifier Name: Paul Wouters
Date Verified: 2023-08-03

Section 3.2.6.1 says:

The SementicsInformation component identified by id-qcs-
   pkixQCSyntax-v1 MAY contain a semantics identifier and MAY identify
   one or more name registration authorities.

It should say:

The SemanticsInformation component identified by id-qcs-
   pkixQCSyntax-v1 or id-qcs-
   pkixQCSyntax-v2 MAY contain a semantics identifier and MAY identify
   one or more name registration authorities.

Notes:

1. Editorial error: "SementicsInformation" should be replaced by "SemanticsInformation".
2. Technical error: for consistency with the last paragraph of this chapter that paragraph relates to both statements: qcStatement-1 and qcStatement-2, not only to the qcStatement-1.

Errata ID: 7801
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Corey Bonnell
Date Reported: 2024-02-07
Verifier Name: RFC Editor
Date Verified: 2024-02-08

Section .2.6.1 says:

   If a value of type SemanticsInformation is present in a QCStatement
   where the statementID component is set to id-qcs-pkix-QCSyntax-v1 or
   id-qcs-pkix-QCSyntax-v2, then at least one of the semanticsIdentifier
   or nameRegistrationAuthorities fields must be present, as indicated.
   Note that the statementInfo component need not be present in a
   QCStatement value even if the statementID component is set to id-
   qcs-pkix-QCSyntax-v1 or id-qcs-pkix-QCSyntax-v2.

It should say:

   If a value of type SemanticsInformation is present in a QCStatement
   where the statementId component is set to id-qcs-pkix-QCSyntax-v1 or
   id-qcs-pkix-QCSyntax-v2, then at least one of the semanticsIdentifier
   or nameRegistrationAuthorities fields must be present, as indicated.
   Note that the statementInfo component need not be present in a
   QCStatement value even if the statementId component is set to id-
   qcs-pkix-QCSyntax-v1 or id-qcs-pkix-QCSyntax-v2.

Notes:

The name of the statement ID component per the ASN.1 definition is "statementId", not "statementID".

This appears in both sentences above.

RFC 3741, "Exclusive XML Canonicalization, Version 1.0", March 2004

Source of RFC: xmldsig (sec)

Errata ID: 237

Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Donald Eastlake III
Date Reported: 2004-03-26
Report Text:

Please see the corresponding W3C document:

http://www.w3.org/TR/xml-exc-c14n


Please see the pointer to the W3C errata:

http://www.w3.org/2002/07/xml-exc-c14n-errata

---

RFC 3742, "Limited Slow-Start for TCP with Large Congestion Windows", March 2004

Source of RFC: tsvwg (wit)

Errata ID: 236
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sally Floyd
Date Reported: 2005-06-08

Section 2 says:

   the invariant is maintained so that the congestion window is
   increased during slow-start by at most max_ssthresh/2 MSS per round-
   trip time. 

It should say:

   the invariant is maintained that the congestion window is
   increased during slow-start by at most max_ssthresh MSS per
   round-trip time (and at least max_ssthresh/2 MSS per round-trip
   time).

Notes:

Later in Section 2:
it
takes:

log(max_ssthresh) + (cwnd - max_ssthresh)/(max_ssthresh/2)

round-trip times to reach a congestion window of cwnd, for a
congestion window greater than max_ssthresh.
Should be:
it
takes at least:

log(max_ssthresh) + (cwnd - max_ssthresh)/(max_ssthresh)

and at most:

log(max_ssthresh) + (cwnd - max_ssthresh)/(max_ssthresh/2)

round-trip times to reach a congestion window of cwnd, for a
congestion window greater than max_ssthresh.

Later in Section 2:
Thus, with Limited Slow-Start with max_ssthresh set to 100 MSS, it
would take 836 round-trip times to reach a congestion window of
83,000 packets,
Should be:
Thus, with Limited Slow-Start with max_ssthresh set to 100 MSS, it
would take at least 836 round-trip times to reach a congestion window of
83,000 packets,

RFC 3744, "Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol", May 2004

Source of RFC: webdav (app)

Errata ID: 235

Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2004-05-26
Report Text:

Issues and resolutions regarding this document can be reviewed at:

http://greenbytes.de/tech/webdav/draft-reschke-rfc3744bis-issues.html

---

RFC 3748, "Extensible Authentication Protocol (EAP)", June 2004

Note: This RFC has been updated by RFC 5247, RFC 7057

Source of RFC: eap (int)

Errata ID: 5139
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ivo Sedlacek
Date Reported: 2017-10-04
Verifier Name: Éric Vyncke
Date Verified: 2024-01-12

Section 3.4 says:

3.4.  Lower Layer Indications

   The reliability and security of lower layer indications is dependent
   on the lower layer.  Since EAP is media independent, the presence or
   absence of lower layer security is not taken into account in the
   processing of EAP messages.

   To improve reliability, if a peer receives a lower layer success
   indication as defined in Section 7.2, it MAY conclude that a Success
   packet has been lost, and behave as if it had actually received a
   Success packet.  This includes choosing to ignore the Success in some
   circumstances as described in Section 4.2.

   A discussion of some reliability and security issues with lower layer
   indications in PPP, IEEE 802 wired networks, and IEEE 802.11 wireless
   LANs can be found in the Security Considerations, Section 7.12.

   After EAP authentication is complete, the peer will typically
   transmit and receive data via the authenticator.  It is desirable to
   provide assurance that the entities transmitting data are the same
   ones that successfully completed EAP authentication.  To accomplish
   this, it is necessary for the lower layer to provide per-packet
   integrity, authentication and replay protection, and to bind these
   per-packet services to the keys derived during EAP authentication.
   Otherwise, it is possible for subsequent data traffic to be modified,
   spoofed, or replayed.

   Where keying material for the lower layer ciphersuite is itself
   provided by EAP, ciphersuite negotiation and key activation are
   controlled by the lower layer.  In PPP, ciphersuites are negotiated
   within ECP so that it is not possible to use keys derived from EAP
   authentication until the completion of ECP.  Therefore, an initial
   EAP exchange cannot be protected by a PPP ciphersuite, although EAP
   re-authentication can be protected.

   In IEEE 802 media, initial key activation also typically occurs after
   completion of EAP authentication.  Therefore an initial EAP exchange
   typically cannot be protected by the lower layer ciphersuite,
   although an EAP re-authentication or pre-authentication exchange can
   be protected.

It should say:

3.4.  Lower Layer Indications

   The reliability and security of lower layer indications is dependent
   on the lower layer.  Since EAP is media independent, the presence or
   absence of lower layer security is not taken into account in the
   processing of EAP messages.

   To improve reliability, if a peer receives a lower layer success
   indication as defined in Section 7.12, it MAY conclude that a Success
   packet has been lost, and behave as if it had actually received a
   Success packet.  This includes choosing to ignore the Success in some
   circumstances as described in Section 4.2.

   A discussion of some reliability and security issues with lower layer
   indications in PPP, IEEE 802 wired networks, and IEEE 802.11 wireless
   LANs can be found in the Security Considerations, Section 7.12.

   After EAP authentication is complete, the peer will typically
   transmit and receive data via the authenticator.  It is desirable to
   provide assurance that the entities transmitting data are the same
   ones that successfully completed EAP authentication.  To accomplish
   this, it is necessary for the lower layer to provide per-packet
   integrity, authentication and replay protection, and to bind these
   per-packet services to the keys derived during EAP authentication.
   Otherwise, it is possible for subsequent data traffic to be modified,
   spoofed, or replayed.

   Where keying material for the lower layer ciphersuite is itself
   provided by EAP, ciphersuite negotiation and key activation are
   controlled by the lower layer.  In PPP, ciphersuites are negotiated
   within ECP so that it is not possible to use keys derived from EAP
   authentication until the completion of ECP.  Therefore, an initial
   EAP exchange cannot be protected by a PPP ciphersuite, although EAP
   re-authentication can be protected.

   In IEEE 802 media, initial key activation also typically occurs after
   completion of EAP authentication.  Therefore an initial EAP exchange
   typically cannot be protected by the lower layer ciphersuite,
   although an EAP re-authentication or pre-authentication exchange can
   be protected.

Notes:

2nd paragraph of section 3.4 of RFC3748 states:
---------------------
To improve reliability, >>if a peer receives a lower layer success
indication as defined in Section 7.2<<, it MAY conclude that a Success
packet has been lost, and behave as if it had actually received a
Success packet. This includes choosing to ignore the Success in some
circumstances as described in Section 4.2.
---------------------

RFC3748 section 7.2 does not seem to state anything about lower layer indications.

RFC3748 section 7.12 contains some text on the lower layer indications and also RFC3748 section 7.16 contains some text on lower layer indications.

So, it is proposed to change 2nd paragraph of section 3.4 of RFC3748 to reference section 7.12 (or section 7.16) instead of referencing section 7.2.

-- Verifier note --

Indeed, the 2nd paragraph of section 3.4 should have a reference to section 7.12. draft-ietf-eap-rfc2284bis-00 has text relevant to section 3.4 that was moved to section 7.12 in later revisions.

RFC 3770, "Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)", May 2004

Note: This RFC has been obsoleted by RFC 4334

Source of RFC: pkix (sec)

Errata ID: 233
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2005-01-22

Section 8 says:

   id-aca-wlanSSID  OBJECT IDENTIFIER ::= { id-aca 6 }

It should say:

   id-aca-wlanSSID  OBJECT IDENTIFIER ::= { id-aca 7 }

Notes:

Errata ID: 234
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2005-01-22

Section 4 says:

    The WLAN SSID attribute certificate attribute is identified by
    id-aca-wlanSSID.

      id-aca  OBJECT IDENTIFIER  ::=  { iso(1) identified-organization(3)
        dod(6) internet(1) security(5) mechanisms(5) pkix(7) 10 }

      id-aca-wlanSSID  OBJECT IDENTIFIER ::= { id-aca 6 }

It should say:

    The WLAN SSID attribute certificate attribute is identified by
    id-aca-wlanSSID.

      id-aca  OBJECT IDENTIFIER  ::=  { iso(1) identified-organization(3)
        dod(6) internet(1) security(5) mechanisms(5) pkix(7) 10 }

      id-aca-wlanSSID  OBJECT IDENTIFIER ::= { id-aca 7 }

Notes:

This same error is repeated in the ASN.1 Module (Section 8).

RFC 3777, "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", June 2004

Note: This RFC has been obsoleted by RFC 7437

Note: This RFC has been updated by RFC 5078, RFC 5633, RFC 5680, RFC 6859

Source of RFC: nomcom (gen)

Errata ID: 4179
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Brian Carpenter
Date Reported: 2014-11-13
Verifier Name: Barry Leiba
Date Verified: 2014-11-13

Section 4 says:

   3.  The nominating committee comprises at least a Chair, 10 voting
       volunteers, 3 liaisons, and an advisor.

It should say:

   3.  The nominating committee comprises at least a Chair, 10 voting
       volunteers, two liaisons, and an advisor.

Notes:

The ISOC liaison is optional. Saying "at least ... two" is future-proof.

RFC 3779, "X.509 Extensions for IP Addresses and AS Identifiers", June 2004

Source of RFC: pkix (sec)

Errata ID: 2537
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jim Schaad
Date Reported: 2010-09-30
Verifier Name: Sean Turner
Date Verified: 2011-02-23

Section 2.2.3.9 says:

   To simplify the comparison of IP address blocks when performing
   certification path validation, a maximum IP address MUST contain at
   least one bit whose value is 1, i.e., the subsequent octets may not
   be omitted nor all zero.

It should say:

Text should be deleted.

Notes:

There are a number of different issues relative to this text that need to be addressed.

1. This text implicitly change the rules for encoding a maximum value. As an example the address 0.0.0.255 is encoded as 03 03 00 00 00 00 according to the rule " The BIT STRING for the maximum address results from removing all the least-significant one-bits from the maximum address."

2. The rule in no way simplifies any comparisions of IP address blocks. If one really wishes to simplify the comparison then one needs to change the rule for maximum addresses to remove all but the last least-signficant one-bit from the address. However it is not clear that even this would really simplify the comparison in any significant way.

If you look at the example in 2.2.3.9 - tis is not clear how having the one bit at the top of the encoding helps make the comparisons any easier - but it satisfies the requirment that atleast one bit is a 1. If the maximum value ws encoded as 1000 1 (0x3 0x02 0x03 0x84) - a bitwise comparision routine could make for a simplified a < b comparison (looking at only the top 5 bits of the address to be compared.)

Errata ID: 6792
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Theo Buehler
Date Reported: 2021-12-21
Verifier Name: Benjamin Kaduk
Date Verified: 2021-12-25

Section Appendix B says:

   30 3d                       Extension {
      06 08 2b06010505070107     extnID        1.3.6.1.5.5.7.1.7
      01 01 ff                   critical
      04 2e                      extnValue {
         30 2c                     IPAddrBlocks {
            30 10                    IPAddressFamily {
               04 03 0001 01           addressFamily: IPv4 Unicast
                                       IPAddressChoice
               30 09                     addressesOrRanges {
                                           IPAddressOrRange
                  03 02 00 0a                addressPrefix    10/8
                                           IPAddressOrRange
                  03 03 04 b010              addressPrefix    172.16/12
                                         } -- addressesOrRanges
                                     } -- IPAddressFamily
            30 07                    IPAddressFamily {
               04 03 0001 02           addressFamily: IPv4 Multicast
                                       IPAddressChoice
               05 00                     inherit from issuer
                                     } -- IPAddressFamily
            30 0f                    IPAddressFamily {
               04 02 0002              addressFamily: IPv6
                                       IPAddressChoice
               30 09                     addressesOrRanges {
                                           IPAddressOrRange
                  03 07 00 200100000002      addressPrefix   2001:0:2/47
                                         } -- addressesOrRanges
                                     } -- IPAddressFamily
                                   } -- IPAddrBlocks
                                 } -- extnValue
                                  } -- Extension

It should say:

   30 3d                       Extension {
      06 08 2b06010505070107     extnID        1.3.6.1.5.5.7.1.7
      01 01 ff                   critical
      04 2e                      extnValue {
         30 2c                     IPAddrBlocks {
            30 10                    IPAddressFamily {
               04 03 0001 01           addressFamily: IPv4 Unicast
                                       IPAddressChoice
               30 09                     addressesOrRanges {
                                           IPAddressOrRange
                  03 02 00 0a                addressPrefix    10/8
                                           IPAddressOrRange
                  03 03 04 ac10              addressPrefix    172.16/12
                                         } -- addressesOrRanges
                                     } -- IPAddressFamily
            30 07                    IPAddressFamily {
               04 03 0001 02           addressFamily: IPv4 Multicast
                                       IPAddressChoice
               05 00                     inherit from issuer
                                     } -- IPAddressFamily
            30 0f                    IPAddressFamily {
               04 02 0002              addressFamily: IPv6
                                       IPAddressChoice
               30 09                     addressesOrRanges {
                                           IPAddressOrRange
                  03 07 00 200100000002      addressPrefix   2001:0:2/48
                                         } -- addressesOrRanges
                                     } -- IPAddressFamily
                                   } -- IPAddrBlocks
                                 } -- extnValue
                                  } -- Extension

Notes:

b010 represents 176.16/12, the hex representation of 172 is ac, so it should be ac10.

The IPv6 addressPrefix in question is 2001:0:2/48, not 2001:0:2/47, as explained in the text before the example.

Errata ID: 836
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Randy Bush
Date Reported: 2006-06-21

Section 3.2.3.1 says:

The ASIdentifiers type is a SEQUENCE containing one or more forms of
autonomous system identifiers -- AS numbers (in the asnum element) or
routing domain identifiers (in the rdi element).  When the ASIdentifiers type
contains multiple forms of identifiers, the asnum
entry MUST precede the rdi entry.  AS numbers are used by BGP, and
routing domain identifiers are specified in the IDRP [RFC1142].

It should say:

[see Notes]

Notes:

IDRP was never defined in an RFC, only by ISO 10747.

from pending

Errata ID: 1886
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Charles Bobo
Date Reported: 2009-09-21
Verifier Name: Sean Turner
Date Verified: 2010-04-19

Section 2.1.1 says:

   An IPv6 address is a 128-bit quantity that is written as eight
   hexadecimal numbers, each in the range 0 through ffff, separated by a
   semicolon (":"); 2001:0:200:3:0:0:0:1 is an example of an IPv6
   address.  IPv6 addresses frequently have adjacent fields whose value
   is 0.  One such group of 0 fields may be abbreviated by two
   semicolons ("::"). 

It should say:

   An IPv6 address is a 128-bit quantity that is written as eight 
   hexadecimal numbers, each in the range 0 through ffff, separated by a 
   colon (":"); 2001:0:200:3:0:0:0:1 is an example of an IPv6 address.
   IPv6 addresses frequently have adjacent fields whose value is 0.  One
   such group of 0 fields may be abbreviated by two colons ("::").

Notes:

"semicolon" should be "colon"
Added reference to RFC4291.
Verifier: Forward reference to RFC4291 is inappropriate.

RFC 3781, "Next Generation Structure of Management Information (SMIng) Mappings to the Simple Network Management Protocol (SNMP)", May 2004

Source of RFC: INDEPENDENT

Errata ID: 733
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Kirkham
Date Reported: 2005-02-13
Verifier Name: Bob Braden
Date Verified: 2008-04-21

Section 3.1 says:

  Integer64 ::=
       [APPLICATION 10]
           IMPLICIT INTEGER (-9223372036854775808..9223372036854775807)

   Unsigned64
       [APPLICATION 11]
           IMPLICIT INTEGER (0..18446744073709551615)

   Float32
       [APPLICATION 12]
           IMPLICIT OCTET STRING (SIZE (4))

   Float64
       [APPLICATION 13]
           IMPLICIT OCTET STRING (SIZE (8))

   Float128
       [APPLICATION 14]
           IMPLICIT OCTET STRING (SIZE (16))

It should say:

  Integer64 ::=
       [APPLICATION 10]
           IMPLICIT INTEGER (-9223372036854775808..9223372036854775807)

   Unsigned64 ::=
       [APPLICATION 11]
           IMPLICIT INTEGER (0..18446744073709551615)

   Float32 ::=
       [APPLICATION 12]
           IMPLICIT OCTET STRING (SIZE (4))

   Float64 ::=
       [APPLICATION 13]
           IMPLICIT OCTET STRING (SIZE (8))

   Float128 ::=
       [APPLICATION 14]
           IMPLICIT OCTET STRING (SIZE (16))

RFC 3782, "The NewReno Modification to TCP's Fast Recovery Algorithm", April 2004

Note: This RFC has been obsoleted by RFC 6582

Source of RFC: tsvwg (wit)

Errata ID: 231
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sally Floyd
Date Reported: 2004-06-07

Section 8 says:

   When not in Fast Recovery, the value of the state variable "recover"
   should be pulled along with the value of the state variable for
   acknowledgments (typically, "snd_una") so that, when large amounts of
   data have been sent and acked, the sequence space does not wrap and
   falsely indicate that Fast Recovery should not be entered (Section 3,
   step 1, last paragraph).

It should say:

   When updating the Cumulative Acknowledgement field outside of
   Fast Recovery, the "recover" state variable may also need to be
   updated in order to continue to permit possible entry into Fast
   Recovery (Section 3, step 1).  This issue arises when an update
   of the Cumulative Acknowledgement field results in a sequence
   wraparound that affects the ordering between the Cumulative
   Acknowledgement field and the "recover" state variable.  Entry
   into Fast Recovery is only possible when the Cumulative
   Acknowledgment field covers more than the "recover" state variable.

Notes:

RFC 3783, "Small Computer Systems Interface (SCSI) Command Ordering Considerations with iSCSI", May 2004

Source of RFC: ips (tsv)

Errata ID: 230
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Eddy Quicksall
Date Reported: 2004-05-28

Section 3.2 says:

   and a Target Session Identifying Handler (TSIH) - each identifying
   one end of the same session.

It should say:

   and a Target Session Identifying Handle (TSIH) - each identifying
   one end of the same session.

RFC 3798, "Message Disposition Notification", May 2004

Note: This RFC has been obsoleted by RFC 8098

Note: This RFC has been updated by RFC 5337, RFC 6533

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 692
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2004-10-20
Verifier Name: Alexey Melnikov
Date Verified: 2010-11-12

Section Several says:

(2) disposition modifiers
=========================

  The disposition modifiers "warning", "superseded", "expired",
  "mailbox-terminated" have not seen actual implementation. They have
  been deleted from this document.


Accordingly, the syntax production "disposition-type" in section 3.2.6.
(on page 14) and section 7. (on mid-page 22) has been changed to read:

    disposition-modifier = "error" / disposition-modifier-extension

Nevertheless, one of these 'removed' modifiers disposition is
mentioned in the text of RFC 3798:

o  "warning" :

   - section 3.2.7. , 3rd line of text on page 16

It should say:

<Remove any references to "warning">

Notes:

Alexey: The editors have this change in their editorial copy of -bis.

RFC 3811, "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management", June 2004

Note: This RFC has been updated by RFC 7274

Source of RFC: mpls (rtg)

Errata ID: 1882
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vishwas Manral
Date Reported: 2009-09-16
Verifier Name: Adrian Farrel
Date Verified: 2010-08-20

Section MplsLabel says:

              * The Generalized-MPLS (GMPLS) label contains a
                value greater than 2^24-1 and used in GMPLS
                as defined in [RFC3471]."

It should say:

              * The Generalized-MPLS (GMPLS) label may contain
                a value greater than 2^24-1 and is used in
                GMPLS as defined in [RFC3471]."

Notes:

The orriginal text implied that GMPLS labels could only be greater than
(2^24 - 1). In fact all label alues are supported.

RFC 3813, "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)", June 2004

Source of RFC: mpls (rtg)

Errata ID: 228
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Kirkham
Date Reported: 2005-02-13
Verifier Name: Adrian Farrel
Date Verified: 2010-08-21

Section mplsLsrModuleReadOnlyCompliance says:

    OBJECT       mplsInSegmentNPop
    SYNTAX       Integer32 (1..1)
    MIN-ACCESS   read-only
    DESCRIPTION "Write access is not required.  This object
                 SHOULD be set to 1 if it is read-only.

It should say:

    OBJECT       mplsInSegmentNPop
    SYNTAX       Integer32 (1)
    MIN-ACCESS   read-only
    DESCRIPTION "Write access is not required.  This object
                 SHOULD be set to 1 if it is read-only.

Notes:

Ref: RFC 2578, section 11.1:

- when a pair of values is specified, the first value
must be less than the second value.

RFC 3822, "Finding Fibre Channel over TCP/IP (FCIP) Entities Using Service Location Protocol version 2 (SLPv2)", July 2004

Note: This RFC has been updated by RFC 7146

Source of RFC: ips (tsv)

Errata ID: 225
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: David Peterson
Date Reported: 2004-11-22

Lines 274 and 333 say:

template-version=0.1

It should say:

template-version=1.0

RFC 3829, "Lightweight Directory Access Protocol (LDAP) Authorization Identity Request and Response Controls", July 2004

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 224
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2004-09-01

Section 8.1 says:

  [IANALDAP]    Hodges, J. and R. Morgan, "Lightweight Directory Access
                Protocol (v3): Technical Specification", RFC 3377,
                September 2002.

It should say:

  [IANALDAP]    Zeilenga, K., "Internet Assigned Authority (IANA)
                Considerations for the Lightweight Directory Access
                Protocol (LDAP)", RFC 3383, September 2002.

Notes:

RFC 3830, "MIKEY: Multimedia Internet KEYing", August 2004

Note: This RFC has been updated by RFC 4738, RFC 6309

Source of RFC: msec (sec)

Errata ID: 2654
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: wu yongming
Date Reported: 2010-12-02
Verifier Name: Tim Polk
Date Verified: 2011-02-23

Section 6.1 says:

 *  CS ID map info (16 bits): identifies the crypto session(s) for
      which the SA should be created.  The currently defined map type is
      the SRTP-ID (defined in Section 6.1.1).

It should say:

 *  CS ID map info (variable length): identifies the crypto session(s) for
      which the SA should be created.  The currently defined map type is
      the SRTP-ID (defined in Section 6.1.1).

Notes:

dear editors,
I guess this should be an error. After googling, I found at least one extension draft(MIKEY-TICKET) had also recognized the problem.
If I have mistaken, I would like to hear your clarification.

RFC 3834, "Recommendations for Automatic Responses to Electronic Mail", August 2004

Note: This RFC has been updated by RFC 5436

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 223
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2004-09-01

Section 4 says:

   A Service Responder MAY deliver the response to the address(es) from
   the >From field, or to another address from the request payload,
   provided this behavior is precisely defined in the specification for
   that service. 

It should say:

   A Service Responder MAY deliver the response to the address(es) from
   the From field, or to another address from the request payload,
   provided this behavior is precisely defined in the specification for
   that service. 

Notes:

RFC 3852, "Cryptographic Message Syntax (CMS)", July 2004

Note: This RFC has been obsoleted by RFC 5652

Note: This RFC has been updated by RFC 4853, RFC 5083

Source of RFC: smime (sec)

Errata ID: 222
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2005-01-22

Section 6.1 says:

          IF (originatorInfo is present) AND
             ((any certificates with a type of other are present) OR
             (any crls with a type of other are present))
          THEN version is 4
          ELSE
             IF ((originatorInfo is present) AND
                (any version 2 attribute certificates are present)) OR
                (any RecipientInfo structures include pwri) OR
                (any RecipientInfo structures include ori)
             THEN version is 3
             ELSE
                IF (originatorInfo is absent) OR
                   (unprotectedAttrs is absent) OR
                   (all RecipientInfo structures are version 0)
                THEN version is 0
                ELSE version is 2

It should say:

          IF (originatorInfo is present) AND
             ((any certificates with a type of other are present) OR
             (any crls with a type of other are present))
          THEN version is 4
          ELSE
             IF ((originatorInfo is present) AND
                (any version 2 attribute certificates are present)) OR
                (any RecipientInfo structures include pwri) OR
                (any RecipientInfo structures include ori)
             THEN version is 3
             ELSE
                IF (originatorInfo is absent) AND
                   (unprotectedAttrs is absent) AND
                   (all RecipientInfo structures are version 0)
                THEN version is 0
                ELSE version is 2

Notes:

Errata ID: 1744
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jan Vilhuber
Date Reported: 2009-03-26
Verifier Name: Tim Polk
Date Verified: 2009-06-05

Section 5 says:

A recipient independently computes the message digest.  This message
digest and the signer's public key are used to verify the signature
value.  The signer's public key is referenced either by an issuer
distinguished name along with an issuer-specific serial number or by
a subject key identifier that uniquely identifies the certificate
containing the public key.  The signer's certificate can be included
in the SignedData certificates field.

It should say:

A recipient independently computes the message digest.  This message
digest and the signer's public key are used to verify the signature
value.  The signer's public key is referenced in one of two ways.
It can be referenced by an issuer distinguished name along with an
issuer-specific serial number to uniquely identify the certificate
that contains the public key.  Alternatively, it can be referenced
by a subject key identifier, which accommodates both certified and
uncertified public keys.  While not required, the signer's
certificate can be included in the SignedData certificates field.

Notes:

The original text seems to indicate that a subjectKeyIdentifier also uniquely identifies a certificate, when in fact no certificate may exist at all. This clarification clarifies some possibly conflicting text from the CMC rfc.

Errata ID: 1756
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2009-04-04
Verifier Name: Tim Polk
Date Verified: 2009-06-05

Section 10.1.2 says:

   The SignatureAlgorithmIdentifier type identifies a signature
   algorithm.  Examples include RSA, DSA, and ECDSA.

It should say:

   The SignatureAlgorithmIdentifier type identifies a signature
   algorithm, and it can also identify a message digest alforithm.
   Examples include RSA, DSA, DSA with SHA-1, ECDSA, and ECDSA with
   SHA-256.

Notes:

Some people have taken the original text to mean that compound signature algorithm identifiers should not be used. This is not the case. Section 12.2 of RFC 2630 (the grandfather of RFC 3852) clearly requires the implementation of id-dsa-with-sha1, which is a compound signature algorithm.

RFC 3855, "Transporting Secure/Multipurpose Internet Mail Extensions (S/MIME) Objects in X.400", July 2004

Source of RFC: vgmib (int)

Errata ID: 6412
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2021-01-27
Verifier Name: Benjamin Kaduk
Date Verified: 2021-01-27

Section 2.3 says:

   id-ep-content ::= {joint-iso-itu-t(2) mhs(6) ipms(1) ep(11) 17}

   id-et-content ::= {joint-iso-itu-t(2) mhs(6) ipms(1) et(4) 17}

It should say:

   id-ep-content OBJECT IDENTIFIER ::=
      {joint-iso-itu-t(2) mhs(6) ipms(1) ep(11) 17}

   id-et-content OBJECT IDENTIFIER ::=
      {joint-iso-itu-t(2) mhs(6) ipms(1) et(4) 17}

Notes:

The "OBJECT IDENTIFIER" is needed for correct ASN.1 syntax.

RFC 3856, "A Presence Event Package for the Session Initiation Protocol (SIP)", August 2004

Note: This RFC has been updated by RFC 8996

Source of RFC: simple (rai)

Errata ID: 3676
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Liangxing Wang
Date Reported: 2013-07-01
Verifier Name: Nevil Brownlee
Date Verified: 2014-02-03

Section 6.11.1 says:

In a presence edge server (where the PUA is co-located with the PUA),

It should say:

In a presence edge server (where the PA is co-located with the PUA),

Notes:

According to section 3 definitions, an edge presence server is a presence agent
that is co-located with a PUA.

RFC 3859, "Common Profile for Presence (CPP)", August 2004

Source of RFC: impp (app)

Errata ID: 4959
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Matt Kern
Date Reported: 2017-03-07
Verifier Name: Orie Steele
Date Verified: 2024-03-29

Section 3.1 says:

When an application wants to subscriber to the presence information
   associated with a PRESENTITY (in order to receive periodic
   notifications of presence information), it invokes the subscribe
   operation, e.g.,

It should say:

When an application wants to subscribe to the presence information
   associated with a PRESENTITY (in order to receive periodic
   notifications of presence information), it invokes the subscribe
   operation, e.g.,

Notes:

The word "subscriber" should be the verb "subscribe."

RFC 3863, "Presence Information Data Format (PIDF)", August 2004

Source of RFC: impp (app)

Errata ID: 1606
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kevin Braun
Date Reported: 2008-11-18
Verifier Name: Lisa Dusseault
Date Verified: 2008-11-24

Section 4.4 says:

         <xs:pattern value="0(.[0-9]{0,3})?"/>
         <xs:pattern value="1(.0{0,3})?"/>

It should say:

         <xs:pattern value="0(\.[0-9]{0,3})?"/>
         <xs:pattern value="1(\.0{0,3})?"/>

Notes:

As given, the pattern would allow values such as "09", which is not the intention. The metacharacter '.' needs to be escaped.

RFC 3866, "Language Tags and Ranges in the Lightweight Directory Access Protocol (LDAP)", July 2004

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 221
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2004-08-31

Section 2.1 says:

   An entry may contain multiple attributes with same
   attribute type but different combinations of language tag (and other)
   options.

It should say:

   An entry may contain multiple attributes with the same
   attribute type but different combinations of language tag (and other)
   options.

Errata ID: 220
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kurt D. Zeilenga
Date Reported: 2004-08-18

Section 4 says:

   A server SHOULD indicate that it supports storing attributes with
   language tag options in the DIT by publishing 1.3.6.1.4.1.4203.1.5.4
   as a value of the root DSE.

It should say:

   A server SHOULD indicate that it supports storing attributes with
   language tag options in the DIT by publishing 1.3.6.1.4.1.4203.1.5.4
   as a value of the "supportedFeatures" [RFC3674] attribute of the root 
   DSE.

Notes:

In section 5, it says:

Implementators of this specification should take care that their use
of language tag options does not impede proper function of
implementations which do not support language tags.

It should say:

Implementors of this specification should take care that their use
of language tag options does not impede proper function of
implementations which do not support language tags.

RFC 3877, "Alarm Management Information Base (MIB)", September 2004

Source of RFC: disman (ops)

Errata ID: 219
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Andreas Politze
Date Reported: 2005-08-08

Section 6.3 says:

ituAlarmPerceivedSeverity        critical (3)

It should say:

alarmModelState                  3

Notes:

However,
ituAlarmPerceivedSeverity critical (3)
should be mapped to
alarmModelState 6
To match the mapping shown in Section 5.4:
alarmModelState -> ituAlarmPerceivedSeverity
1 -> clear (1)
2 -> indeterminate (2)
3 -> warning (6)
4 -> minor (5)
5 -> major (4)
6 -> critical (3)

RFC 3886, "An Extensible Message Format for Message Tracking Responses", September 2004

Source of RFC: msgtrk (app)

Errata ID: 218
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2004-10-20
Verifier Name: Alexey Melnikov
Date Verified: 2009-10-01

Section 3 says:

      A Message Tracking Status Motification (MTSN) is intended to be
      returned as the body of a Message Tracking request [RFC-MTRK-MTQP].
                                                 ^^^^^^^

It should say:

      A Message Tracking Status Motification (MTSN) is intended to be
      returned as the body of a Message Tracking response [RFC-MTRK-MTQP].
                                                 ^^^^^^^^

Errata ID: 216
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2004-10-20
Verifier Name: Alexey Melnikov
Date Verified: 2009-10-01

Section 5 says:

IANA has registered the SMTP extension defined in section 3.

It should say:

IANA has registered the MIME subtype defined in section 3.

Notes:

The text of RFC 3886, Section 5. (on page 8) appears to by copied
unchanged from RFC 3885 and thus does not fit the context of
RFC 3886.

Errata ID: 217
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2004-10-20
Verifier Name: Alexey Melnikov
Date Verified: 2009-10-01

Section 3.1 says:

      That body consists of one or more "fields" formatted to
                                                           ^^
      according to...

It should say:

      That body consists of one or more "fields" formatted
      according to...

Notes:

Extra "to".

RFC 3887, "Message Tracking Query Protocol", September 2004

Note: This RFC has been updated by RFC 8553, RFC 8996

Source of RFC: msgtrk (app)

Errata ID: 214
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2004-10-20

Section 5 says:

     All optional text provided with the COMMENT command are ignored.

It should say:

     All optional text provided with the COMMENT command is ignored.

Errata ID: 215
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tony Hansen
Date Reported: 2005-11-07

Section 11 says:

           ...Thus, if an MTQP client/server pair decide to use TLS
     confidentially,...

It should say:

           ... Thus, if an MTQP client/server pair decides to use TLS
     confidentially, ...

Errata ID: 3721
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ned Freed
Date Reported: 2013-09-10
Verifier Name: Barry Leiba
Date Verified: 2013-09-11

Section 4.1 says:

S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status

It should say:

S: Content-Type: multipart/related; boundary=%%%%;
S:  type="message/tracking-status"

Notes:

According to RFC 2387 section 3.1, the value of the type parameter for
multipart/related is supposed to be the "MIME media type of the 'root' body
part." Additionaly, section 3 of RFC 3886 specifically states that the value is
supposed to be "message/tracking-status". But all seven examples in section 4.1
show just the subtype as the parameter value.

*** This errata report applies to all of the examples in Section 4.1 ***

Errata ID: 5044
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Wolfgang Keller
Date Reported: 2017-06-20
Verifier Name: RFC Editor
Date Verified: 2017-06-23

Section 14.1. says:

   [RFC-MTRK-MODEL]   Hansen, T., "Message Tracking Models and
                      Requirements", RFC 3885, September 2004.

It should say:

   [RFC-MTRK-MODEL]   Hansen, T., "Message Tracking Model and
                      Requirements", RFC 3888, September 2004.

Notes:

The reference references a wrong RFC number. The text says RFC 3885, but the correct one is RFC 3888.

Verifier Notes: Also corrected title (Model not Models).

RFC 3891, "The Session Initiation Protocol (SIP) "Replaces" Header", September 2004

Source of RFC: sip (rai)

Errata ID: 7141
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Aaron Brumpton
Date Reported: 2022-09-28
Verifier Name: RFC Editor
Date Verified: 2022-09-29

Section section-7.1 says:

SIP/2.0 180 Ringing
   To: <sip:bob@example.org>;tag=6472
   From: <sip:alice@example.org>;tag=7743
   Call-ID: 425928@phone.example.org
   CSeq: 1 INVITE
   Contact: <sip:bob@bobster.example.org>

   Message *3: Bob in lab -> Alice

   INVITE sip:alice@phone.example.org
   To: <sip:alice@example.org>
   From: <sip:bob@example.org>;tag=8983
   Call-ID: 09870@labpc.example.org
   CSeq: 1 INVITE
   Contact: <sip:bob@labpc.example.org>
   Replaces: 425928@phone.example.org
    ;to-tag=7743;from-tag=6472;early-only

It should say:

SIP/2.0 180 Ringing
   To: <sip:bob@example.org>;tag=6472
   From: <sip:alice@example.org>;tag=7743
   Call-ID: 425928@phone.example.org
   CSeq: 1 INVITE
   Contact: <sip:bob@bobster.example.org>

   Message *3: Bob in lab -> Alice

   INVITE sip:alice@phone.example.org
   To: <sip:alice@example.org>
   From: <sip:bob@example.org>;tag=8983
   Call-ID: 09870@labpc.example.org
   CSeq: 1 INVITE
   Contact: <sip:bob@labpc.example.org>
   Replaces: 425928@phone.example.org
    ;to-tag=6472;from-tag=7743;early-only

Notes:

The To and From tags are mismatched in the Replaces header

RFC 3920, "Extensible Messaging and Presence Protocol (XMPP): Core", October 2004

Note: This RFC has been obsoleted by RFC 6120

Note: This RFC has been updated by RFC 6122

Source of RFC: xmpp (app)

Errata ID: 704
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Saint-Andre
Date Reported: 2004-12-08

Section 6.6 says:

It has been brought to my attention that in Section 6.6 of RFC 3920, the 
protocol snippet in Step 11 is as follows:
 
    <stream:stream
        xmlns='jabber:client'
        xmlns:stream='http://etherx.jabber.org/streams'
        from='example.com'
        id='s2s_345'
        version='1.0'>
    <stream:features/>
 
Because this is a server-to-server example, the xmlns for that stream 
header should instead be 'jabber:server'.
 

It should say:

[see above]

Notes:

from pending

Errata ID: 212
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Peter Saint-Andre
Date Reported: 2004-11-05

In Appendix C.1, add the following three lines directly after the opening <xs:schema> tag:

  <xs:import namespace='jabber:client'/>
  <xs:import namespace='jabber:server'/>
  <xs:import namespace='jabber:server:dialback'/>

Errata ID: 1406
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Frank Ellermann
Date Reported: 2008-04-08
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-06

Section 6.5 says:

The following example shows the data flow for a client authenticating
with a server using SASL, normally after successful TLS negotiation
(note: the alternate steps shown below are provided to illustrate the
protocol for failure cases; they are not exhaustive and would not
necessarily be triggered by the data sent in the example).

It should say:

The following example shows the data flow for a client authenticating
with a server using SASL, normally after successful TLS negotiation
(note: the alternate steps shown below are provided to illustrate the
protocol for failure cases; they are not exhaustive and would not
necessarily be triggered by the data sent in the example).

The digests (response and rspauth) in steps 6 and 7 of the examples
in this and the next section merely show the format, the values don't
correspond to the input values for any known password. 

Notes:

response=d388dad90d4bbd760a152321f2143af7 and
rspauth=ea40f60335c427b5527b84dbabcdfffd are the digest
values for the first example in RFC 2831 chapter 4.

RFC 3931, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", March 2005

Note: This RFC has been updated by RFC 5641

Source of RFC: l2tpext (int)

Errata ID: 210
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ming Deng
Date Reported: 2007-05-09

Section 3 says:

SSHTRESH

It should say:

SSTHRESH

Notes:

Occurs 3 times.

from pending.

Errata ID: 1433
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Stefan Puiu
Date Reported: 2008-05-30
Verifier Name: Brian Haberman
Date Verified: 2012-05-09

Section 4.5 says:

The LCCE then checks the Cookie field in the data packet against 
the Cookie value received in the Assigned Cookie AVP during session
establishment.

It should say:

The LCCE then checks the Cookie field in the data packet against 
the Cookie value sent in the Assigned Cookie AVP during session 
establishment.

Notes:

Section 5.4.4 contradicts this directly ("All data messages sent to a peer MUST use the Assigned Cookie sent by the peer in this AVP"), and seems consistent with the rest of the 'assigned ...' fields.

Errata ID: 211
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Carlos Pignataro
Date Reported: 2005-10-31

Section 5.4.5 says:

      This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for
      this AVP SHOULD be set to 0, but MAY vary (see Section 5.2).  The
      Length (before hiding) of this AVP is 32.

It should say:

     
      This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for
      this AVP SHOULD be set to 0, but MAY vary (see Section 5.2).  The
      Length (before hiding) of this AVP is 24.

Notes:

RFC 3933, "A Model for IETF Process Experiments", November 2004

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 209
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John C Klensin
Date Reported: 2006-02-15

Section 2 says:

	The I-D must state an explicit "sunset" timeout
	typically, not to exceed one year after adoption.

It should say:

	The I-D must state an explicit "sunset" timeout,
	typically not to exceed one year after adoption.

RFC 3939, "Calling Line Identification for Voice Mail Messages", December 2004

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 208

Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-01-04
Report Text:

Informative Reference includes [RFC2806]; however, [RFC2806] has been obsoleted by [RFC3966].  All citations and references should reflect this throughout the document.

---

RFC 3944, "H.350 Directory Services", December 2004

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 2251
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-01-04
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-11

Section 6 says:

  (https//:videnet.unc.edu)

It should say:

| (https://videnet.unc.edu)

Notes:

Corrected a HTTPS URI.

RFC 3945, "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", October 2004

Note: This RFC has been updated by RFC 6002

Source of RFC: ccamp (rtg)

Errata ID: 2252
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2010-05-12
Verifier Name: Adrian Farrel
Date Verified: 2010-05-16

Section 11.2 says:

   One can classify LSPs into one of a small set of service levels.
   Among other things, these service levels define the reliability
   characteristics of the LSP.  The service level associated with a
   given LSP is mapped to one or more P&R schemes during LSP
   establishment.  An advantage that mapping is that an LSP may use
   different P&E schemes in different segments of a network (e.g., some
   links may be span protected, whilst other segments of the LSP may
   utilize ring protection).  These details are likely to be service
   provider specific.

It should say:

   One can classify LSPs into one of a small set of service levels.
   Among other things, these service levels define the reliability
   characteristics of the LSP.  The service level associated with a
   given LSP is mapped to one or more P&R schemes during LSP
   establishment.  An advantage that mapping is that an LSP may use
   different P&R schemes in different segments of a network (e.g., some
   links may be span protected, whilst other segments of the LSP may
   utilize ring protection).  These details are likely to be service
   provider specific.

Notes:

Mistype error
The change is...
s/P&E/P&R/ in the 6th line

RFC 3947, "Negotiation of NAT-Traversal in the IKE", January 2005

Source of RFC: ipsec (sec)

Errata ID: 4937
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2017-02-16
Verifier Name: Paul Wouters
Date Verified: 2022-04-10

Section 6 says:

   The source IP and port address of the INITIAL-CONTACT notification
   for the host behind NAT are not meaningful (as NAT can change them),
   so the IP and port numbers MUST NOT be used to determine which
   IKE/IPsec SAs to remove (see [RFC3715], section 2.1, case c).  The ID
   payload sent from the other end SHOULD be used instead; i.e., when an
   INITIAL-CONTACT notification is received from the other end, the
   receiving end SHOULD remove all the SAs associated with the same ID
   payload.

It should say:

   The source IP and port number of the INITIAL-CONTACT notification
   for the host behind NAT are not meaningful (as NAT can change them),
   so the IP and port numbers MUST NOT be used to determine which
   IKE/IPsec SAs to remove (see [RFC3715], section 2.1, case c).  The ID
   payload sent from the other end SHOULD be used instead; i.e., when an
   INITIAL-CONTACT notification is received from the other end, the
   receiving end SHOULD remove all the SAs associated with the same ID
   payload.

Notes:

Port address should be replaced with port number.

RFC 3948, "UDP Encapsulation of IPsec ESP Packets", January 2005

Source of RFC: ipsec (sec)

Errata ID: 6774
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: warren.wang
Date Reported: 2021-12-04
Verifier Name: RFC Editor
Date Verified: 2022-01-27

Section 1 says:

This protocol specification defines methods to encapsulate and
   decapsulate ESP packets inside UDP packets for traversing Network
   Address Translators (NATs) (see [RFC3715], section 2.2, case i).  The
   UDP port numbers are the same as those used by IKE traffic, as
   defined in [RFC3947].

It should say:

This protocol specification defines methods to encapsulate and
   decapsulate ESP packets inside UDP packets for traversing Network
   Address Translators (NATs) (see [RFC3715], section 2.2, case j).  The
   UDP port numbers are the same as those used by IKE traffic, as
   defined in [RFC3947].

Notes:

Original text says:"(see [RFC3715], section 2.2, case i)", it should be case j.

RFC 3954, "Cisco Systems NetFlow Services Export Version 9", October 2004

Source of RFC: INDEPENDENT

Errata ID: 2096
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2010-03-25
Verifier Name: Nevil Brownlee
Date Verified: 2010-04-03

Section 5.3 and 6.2. says:

   Padding
         The Exporter SHOULD insert some padding bytes so that the
         subsequent FlowSet starts at a 4-byte aligned boundary.  It is
         important to note that the Length field includes the padding
         bytes.  Padding SHOULD be using zeros.

It should say:

   Padding
         The Exporter SHOULD insert some padding bytes so that the
         subsequent FlowSet starts at a 4-byte aligned boundary.  It is
         important to note that the Length field includes the padding
         bytes.  The padding length MUST be shorter than any allowable
         record in the Set.  Padding SHOULD be using zeros.

Notes:

Addition of "The padding length MUST be shorter than any allowable record in the Set."

With small field sizes, such that the record size <= 3, it's not possible to distinguish padding from further data records (s 5.3) or options data records (s 6.2).

eg, with a record length of 3, three records will consume 9 octets. Three octets of padding will be added to this, giving a total length of 12 octets. The 12 octets now look like *four* records. In this case, padding is NOT appropriate.

NB1 the same paragraph in section 6.1 is NOT affected, because the fixed size of the other fields dictates that the only possibility is padding of 2 octets.

NB2 this situation is anticipated in IPFIX (RFC 5101), from which the additional text is taken.

Errata ID: 2168
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2010-04-22
Verifier Name: Nevil Brownlee
Date Verified: 2011-03-14

Section 8 says:

   FLOW_SAMPLER_ID              48   1     Identifier shown
                                           in "show flow-sampler"

It should say:

   FLOW_SAMPLER_ID              48   N     Identifier shown
                                           in "show flow-sampler".
                                           By default N is 4.

Notes:

Change sampler ID field size to N, defaulting to 4. NB smaller sizes may be used. The actual size may be determined from the corresponding NFv9 template.

Errata ID: 2979
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-09-26
Verifier Name: Nevil Brownlee
Date Verified: 2012-03-12

Section 5.1 says:

   Source ID
         A 32-bit value that identifies the Exporter Observation Domain.
         NetFlow Collectors SHOULD use the combination of the source IP
         address and the Source ID field to separate different export
         streams originating from the same Exporter.

It should say:

   Source ID
         A 32-bit value that identifies the Exporter Observation Domain.
         NetFlow Collectors SHOULD use the combination of the source IP
         address, source port, and the Source ID field to separate different export
         streams originating from the same Exporter.

Notes:

Addition of "source port" to separate multiple export streams.

This is already addressed in RFC5101 (IPFIX) as so:

Collecting Processes SHOULD use the Transport Session and the
Observation Domain ID field to separate different export streams

NB transport session = address + ports.

RFC 3958, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", January 2005

Note: This RFC has been updated by RFC 8553

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 2106
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Leslie Daigle
Date Reported: 2010-04-02
Verifier Name: Alexey Melnikov
Date Verified: 2010-04-04

Section 6.5 says:

iana-registered-protocol  = ALPHA *31ALPHANUM

It should say:

iana-registered-protocol  = ALPHA *31ALPHANUMSYM

Notes:

Previous erratum suggested the fix was to add an ALPHANUM production, but the correct fix is to change ALPHANUM to ALPHANUMSYM in this production.

Errata ID: 4451
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Frans Oilinki
Date Reported: 2015-08-19
Verifier Name: Orie Steele
Date Verified: 2024-03-29

Section 2.2 says:

   example.com.
   ;;       order pref flags
   IN NAPTR 100   10   ""    "WP:whois++"      ( ; service
                             ""                  ; regexp
                             bunyip.example.     ; replacement
                                               )
   IN NAPTR 100   20   "s"   "WP:ldap"         ( ; service
                             ""                  ; regexp
                            _ldap._tcp.myldap.example.com. ; replacement
                                               )
   IN NAPTR 200   10   ""    "EM:protA"        ( ; service
                             ""                  ; regexp
                             someisp.example.    ; replacement
                                               )
   IN NAPTR 200   30   "a"   "EM:protB"          ; service
                             ""                  ; regexp
                             myprotB.example.com.; replacement
                                               )

It should say:

   example.com.
   ;;       order pref flags
   IN NAPTR 100   10   ""    "WP:whois++"      ( ; service
                             ""                  ; regexp
                             bunyip.example.     ; replacement
                                               )
   IN NAPTR 100   20   "s"   "WP:ldap"         ( ; service
                             ""                  ; regexp
                            _ldap._tcp.myldap.example.com. ; replacement
                                               )
   IN NAPTR 200   10   ""    "EM:protA"        ( ; service
                             ""                  ; regexp
                             someisp.example.    ; replacement
                                               )
   IN NAPTR 200   30   "a"   "EM:protB"        ( ; service
                             ""                  ; regexp
                             myprotB.example.com.; replacement
                                               )

Notes:

Not so familiar with BIND syntax, but by appearance, the last entry seems to be missing a beginning parenthesis. There is another similar omission in section 4.2 (thinkingcat.example definition, this time missing an ending parenthesis).

RFC 3961, "Encryption and Checksum Specifications for Kerberos 5", February 2005

Note: This RFC has been updated by RFC 8429

Source of RFC: krb-wg (sec)

Errata ID: 207
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Weijun Wang
Date Reported: 2006-04-05
Verifier Name: Tim Polk
Date Verified: 2010-07-20

The Unicode character g-clef used throughout the document says:

           "g-clef    U+1011E   F0 9D 84 9E"

It should say:

           "g-clef    U+1D11E   F0 9D 84 9E"

RFC 3964, "Security Considerations for 6to4", December 2004

Source of RFC: v6ops (ops)

Errata ID: 873
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Su
Date Reported: 2007-03-26
Verifier Name: Pekka Savola
Date Verified: 2007-03-26

Section 4.1.3 says:

    src_v6 = 2002:1234:1234::1 (forged address of the target 6to4 node)
    dst_v6 = 2002:0900:0002::1 (valid address)
    src_v4 = 8.0.0.1           (valid or invalid address)
    dst_v4 = 9.0.0.2           (valid address, matches dst_v6)

It should say:

    src_v6 = 2002:1234:1234::1 (forged address of the target 6to4 node)
    dst_v6 = 2001:db8::1       (valid address)
    src_v4 = 8.0.0.1           (valid or invalid address)

Notes:

copy/paste error. Traffic is sent to the native IPv6 node, so the
destination address should be non-2002::/16. When 6to4 is not used,
dst_v4 is not applicable so it could be removed.

from pending

Errata ID: 874
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Su
Date Reported: 2007-03-26
Verifier Name: Pekka Savola
Date Verified: 2007-03-26

Section 4.2.5 says:

    The policy control is usually enacted by applying restrictions to
    where the routing information for 2002::/16 and/or 192.188.99.0/24
    (if the anycast address used [3]) will spread.

It should say:

    The policy control is usually enacted by applying restrictions to
    where the routing information for 2002::/16 and/or 192.88.99.0/24
    (if the anycast address used [3]) will spread.

Notes:

typo in the anycast address.


from pending

RFC 3965, "A Simple Mode of Facsimile Using Internet Mail", December 2004

Source of RFC: fax (app)

Errata ID: 204
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-01-04

Normative Reference says:

   [5]  Buckley, R., Venable, D., McIntyre, L., Parsons, G., and J.
        Rafferty, "File Format for Internet Fax", RFC 3949, November
        2004.

It should say:

   [5]  Buckley, R., Venable, D., McIntyre, L., Parsons, G., and J.
        Rafferty, "File Format for Internet Fax", RFC 3949, February
        2005.

Notes:

[RFC3949] had not yet been published when [RFC3965] was in December, 2004.

Errata ID: 205
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-01-04

Informative References

[19] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.

It should say:

[19] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 3851, June 1999.

Notes:

from pending

RFC 3966, "The tel URI for Telephone Numbers", December 2004

Note: This RFC has been updated by RFC 5341

Source of RFC: iptel (rai)

Errata ID: 202
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2004-12-04
Verifier Name: Henning Schulzrinne
Date Verified: 2004-12-04

Section 5.1.5 says:

        +1-212-555-1 would not be a valid global context, ...

It should say:

        +1-212-555-01 would not be a valid global context, ...

Notes:

Although tiny typo, it could possibly be distorting the meaning.

Errata ID: 203
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Henning Schulzrinne
Date Reported: 2005-03-01

Section 3 says:

isdn-subaddress      = ";isub=" 1*uric

It should say:

isdn-subaddress      = ";isub=" 1*paramchar

RFC 3971, "SEcure Neighbor Discovery (SEND)", March 2005

Note: This RFC has been updated by RFC 6494, RFC 6495, RFC 6980

Source of RFC: send (int)

Errata ID: 3538
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-14
Verifier Name: Ralph Droms
Date Verified: 2013-03-10

Section 6.4.3 says:

   Length

      The length of the option (including the Type, Length, Name Type,
|     Pad Length, and Name fields), in units of 8 octets.

It should say:

   Length

      The length of the option (including the Type, Length, Name Type,
|     Pad Length, Name, and Padding fields), in units of 8 octets.

Notes:

mis-specification ?
Rationale: See the explanation for the 'Padding' field, at the bottom of page 35.

Errata ID: 3539
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-14
Verifier Name: Ralph Droms
Date Verified: 2013-03-10

Section 6.4.4 says:

   Length

      The length of the option (including the Type, Length, Cert Type,
|     Pad Length, and Certificate fields), in units of 8 octets.

It should say:

   Length

      The length of the option (including the Type, Length, Cert Type,
|     Reserved, Certificate, and Padding fields), in units of 8 octets.

Notes:

mis-specification ?

Rationale:
Apparently, there's no 'Pad Length' field in the Certificate Option;
the artwork on top of page 36 shows a 'Reserved' field in the same
octet where the Trust Anchor Option carries a 'Pad Length' field,
and the text contains a description of that 'Reserved' field.
According to the explanation for the 'Padding' field at the bottom
of page 36, the length of the 'Padding' field must be derived
implicitely from the ASN.1 encoding of the 'Certificate' field,
and the 'Length' field comprises the length of the 'Padding' field.

Note:
Because the extensible format potentially allows for other Cert Type
values and other Certificate encodings, I am in doubt whether the
decision to include a Reserved octet in place of a Pad Length octet
was very wise.
The current description of the 'Reserved' field will admit a future
revision of that decision.

Errata ID: 3540
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-14
Verifier Name: Ralph Droms
Date Verified: 2013-03-10

Section 6.4.5 says:

                                                  Future, backward-
|  compatible changes to the protocol may specify the contents of the
|  Reserved field or add new options; backward-incompatible changes may
   use different Code values.

It should say:

                                                  Future, backward-
|  compatible changes to the protocol MAY specify the contents of the
|  Reserved field or add new options; backward-incompatible changes MUST
   use different Code values.

Notes:

Section 6.4.5 vs. Section 6.4.6 -- contradiction!

Contrary to 6.4.5, the first paragraph of Section 6.4.6 says:

Future, backward-
compatible changes to the protocol MAY specify the contents of the
Reserved field or add new options; backward-incompatible changes MUST
use different Code values.

I suspect that the first "may" above should be a "MAY" and the second
"may" should have been a "MUST" as well.

If that's correct, the first paragraph of Section 6.4.5 should be corrected as above.

Errata ID: 2290
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tony Cheneau
Date Reported: 2010-05-25
Verifier Name: Brian Haberman
Date Verified: 2012-10-04

Section 5.1 says:

CGA Parameters

  A variable-length field containing the CGA Parameters data
  structure described in Section 4 of [11].
                         ^^^^^^^^^

It should say:

CGA Parameters

  A variable-length field containing the CGA Parameters data
  structure described in Section 3 of [11].
                         ^^^^^^^^^

Notes:

The current text points to Section 4 of RFC 3972, which is "CGA Generation". I believe it should point to Section 3 that is "CGA Parameters and Hash Values".

RFC 3973, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", January 2005

Note: This RFC has been updated by RFC 8736, RFC 9436

Source of RFC: pim (rtg)

Errata ID: 3271
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Joseph Weinstein
Date Reported: 2012-06-28
Verifier Name: Adrian Farrel
Date Verified: 2012-08-22

Section 4.5.1 says:

if StateRefreshCapable(I) == TRUE
         set PT(S,G) to largest active holdtime read from a Prune
         message accepted on I;

It should say:

if StateRefreshCapable(I) == TRUE
         set PT(S,G,I) to the Holdtime from an active Prune received on
         interface I. The Holdtime used SHOULD be the largest active one
         but MAY be the most recently received active Prune Holdtime.

Notes:

It is not clear what is meant by the "largest active holdtime", and in any event sec. 4.4.2.3 specifies a slightly different rule:

Send State Refresh(S,G) out interface I
The router has refreshed the Prune(S,G) state on interface I.
The router MUST reset the Prune Timer (PT(S,G,I)) to the Holdtime
from an active Prune received on interface I. The Holdtime used
SHOULD be the largest active one but MAY be the most recently
received active Prune Holdtime.

Additionally...
No macro PT(S,G) is defined anywhere in the RFC; the reference appears to be to P(S,G,I).

The concept of an "active Prune" is not defined in this RFC, but simply means those prunes which have not expired.

Errata ID: 967
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mark Doll
Date Reported: 2007-05-16
Verifier Name: Adrian Farrel
Date Verified: 2011-09-04

Section 4.6.1 says:

   assert_metric
   my_assert_metric(S,G,I) {
     if (CouldAssert(S,G,I) == TRUE) {
       return spt_assert_metric(S,G,I)
     } else {
       return infinite_assert_metric()
     }
   }

It should say:

   assert_metric
   my_assert_metric(S,G,I) {
     if (CouldAssert(S,G,I) == TRUE) {
       return spt_assert_metric(S,I)
     } else {
       return infinite_assert_metric()
     }
   }

Notes:

In Section 4.6.1, spt_assert_metric(S,I) is defined to have two
parameters, not three.

from pending [error in data transfer corrected 2/15/08.]

Errata ID: 968
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mark Doll
Date Reported: 2007-05-16
Verifier Name: Adrian Farrel
Date Verified: 2011-09-04

Section 4.6.1 says:

   assert_metric
   spt_assert_metric(S,I) {
     return {0,MRIB.pref(S),MRIB.metric(S),my_addr(I)}
   }

It should say:

   assert_metric
   spt_assert_metric(S,I) {
     return {MRIB.pref(S),MRIB.metric(S),my_addr(I)}
   }

Notes:

In Section 4.6.1, assert_metric is defined to be a 3-tuple, not a
4-tuple.

Errata ID: 969
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mark Doll
Date Reported: 2007-05-16
Verifier Name: Adrian Farrel
Date Verified: 2011-09-04

Section 4.6.1 says:

   assert_metric
   infinite_assert_metric() {
     return {1,infinity,infinity,0}
   }

It should say:

   assert_metric
   infinite_assert_metric() {
     return {infinity,infinity,0}
   }

Notes:

In Section 4.6.1, assert_metric is defined to be a 3-tuple, not a
4-tuple.

RFC 3977, "Network News Transfer Protocol (NNTP)", October 2006

Note: This RFC has been updated by RFC 6048

Source of RFC: nntpext (app)

Errata ID: 1524
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2008-09-23
Verifier Name: Lisa Dusseault
Date Verified: 2009-11-23

Throughout the document, when it says:

If the argument is a message-id and no such article exists, a 430
response MUST be returned.  If the argument is a number or is omitted
and the currently selected newsgroup is invalid, a 412 response MUST
be returned.  If the argument is a number and that article does not
exist in the currently selected newsgroup, a 423 response MUST be
returned.  If the argument is omitted and the current article number
is invalid, a 420 response MUST be returned.

It should say:

If the argument is a message-id and no such article exists, a 430
response MUST be returned.  If the argument is a number or is omitted,
and the currently selected newsgroup is invalid, a 412 response MUST
be returned.  If the argument is a number and that article does not
exist in the currently selected newsgroup, a 423 response MUST be
returned.  If the argument is omitted and the currently selected
newsgroup is valid but the current article number is invalid, a 420
response MUST be returned.

Notes:

A comma should be added after "omitted" in the second sentence. The detail about the validity of the currently selected newsgroup should be added to the last sentence.
Note that this remark applies to sections 6.2.1.2 (ARTICLE), 8.3.2 (OVER) and 8.5.2 (HDR). In the case of OVER and HDR, although the wording is different (ranges are used instead of article numbers), the changes to apply remain the same.

Errata ID: 1525
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2008-09-24
Verifier Name: Lisa Dusseault
Date Verified: 2009-11-23

Section 3.2.1.1 says:

Example of an attempt to access a facility not available to this
connection:

   [C] MODE READER
   [S] 200 Reader mode, posting permitted
   [C] IHAVE <i.am.an.article.you.will.want@example.com>
   [S] 500 Permission denied

It should say:

Example of an attempt to access a facility not available to this
connection:

   [C] MODE READER
   [S] 200 Reader mode, posting permitted
   [C] IHAVE <i.am.an.article.you.will.want@example.com>
   [S] 502 Permission denied

Notes:

The response code is 502 in that case because IHAVE is a recognized
command. It is not available to this connection but may be available
from another connection.

Errata ID: 1932
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2009-10-25
Verifier Name: Lisa Dusseault
Date Verified: 2009-11-03

Section 9.4.3 says:

over-content = 1*6(TAB hdr-content) /
      7(TAB hdr-content) *(TAB hdr-n-content)

It should say:

over-content = 7(TAB hdr-content) *(TAB hdr-n-content)

Notes:

Section 8.3.2 describes the OVER command and mentions that there are seven mandatory fields. Though trailing tabs MAY be omitted in OVER responses, it is impossible to have 1*6(TAB hdr-content) owing to the sixth and seventh fields being the metadata :bytes and :lines which are mandatory items (and MUST be computed by the news server).

Less than 7 entries cannot occur for news servers implementing OVER (which should not be confused with XOVER).

Errata ID: 2720
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2011-02-15
Verifier Name: Barry Leiba
Date Verified: 2012-05-12

Section 9.4.3 says:

   This syntax defines the content of the various multi-line responses;
   more precisely, it defines the part of the response in the multi-line
   data block after any "dot-stuffing" has been undone.  The numeric
|  portion of each non-terminal name indicates the response code that is
   followed by this data.

It should say:

   This syntax defines the content of the various multi-line responses;
   more precisely, it defines the part of the response in the multi-line
   data block after any "dot-stuffing" has been undone.  The numeric
|  portion of each non-terminal name indicates the response code of the
|  initial-response-line that is followed by this data.

Notes:

The last sentence in the RFC text is misleading; there may be (and in fact, in several cases — cf. Section 9.4.2, there indeed are) response-arguments between the response code and the data specified by the multi-line-response-content production.

First reported by Alfred Hönes.

Errata ID: 1533
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2008-10-01
Verifier Name: Lisa Dusseault
Date Verified: 2009-11-23

Section 5.3.3 says:

Example of use of the MODE READER command on a server that provides
reading facilities:

   [C] CAPABILITIES
   [S] 101 Capability list:
   [S] VERSION 2
   [S] READER
   [S] LIST ACTIVE NEWSGROUPS
   [S] .
   [C] MODE READER
   [S] 200 Reader mode, posting permitted
   [C] IHAVE <i.am.an.article.you.have@example.com>
   [S] 500 Permission denied
   [C] GROUP misc.test
   [S] 211 1234 3000234 3002322 misc.test

It should say:

Example of use of the MODE READER command on a server that provides
reading facilities:

   [C] CAPABILITIES
   [S] 101 Capability list:
   [S] VERSION 2
   [S] READER
   [S] LIST ACTIVE NEWSGROUPS
   [S] .
   [C] MODE READER
   [S] 200 Reader mode, posting permitted
   [C] IHAVE <i.am.an.article.you.have@example.com>
   [S] 500 Unknown command
   [C] GROUP misc.test
   [S] 211 1234 3000234 3002322 misc.test

Notes:

The response code 500 is sent because this server does not implement the IHAVE command at all. Therefore, IHAVE is not recognized.
Had the server known the command, it would have replied "502 Permission denied" (according to the result of CAPABILITIES, there is no possibility to authenticate or negotiate a TLS layer which could have provided the availability of the command).

Errata ID: 1929
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2009-10-24
Verifier Name: Lisa Dusseault
Date Verified: 2009-11-03

Section 9.2 says:

group-command = "GROUP" [WS newsgroup-name]

It should say:

group-command = "GROUP" WS newsgroup-name

Notes:

The ABNF syntax for the GROUP command makes its argument optional. However, that is not the case. Section 6.1.1 clearly shows that the argument (a newsgroup name) is mandatory.

Errata ID: 1930
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2009-10-24
Verifier Name: Lisa Dusseault
Date Verified: 2009-11-03

Section 7.6.1.2 says:

If the keyword is not recognised, or if an argument is specified and
the keyword does not expect one, a 501 response code MUST BE
returned.  If the keyword is recognised but the server does not
maintain the information, a 503 response code MUST BE returned.

It should say:

If the keyword is not recognised, or if an argument is specified and
the keyword does not expect one, a 501 response code MUST be
returned.  If the keyword is recognised but the server does not
maintain the information, a 503 response code MUST be returned.

Notes:

So as to be homogeneous with the rest of the document, lower-case letters should be used for the verb after "MUST".

Errata ID: 1931
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2009-10-24
Verifier Name: Lisa Dusseault
Date Verified: 2009-11-03

Section 6.1.1.3 says:

Example reselecting the currently selected newsgroup:

   [C] GROUP misc.test
   [S] 211 1234 234 567 misc.test
   [C] STAT 444
   [S] 223 444 <123456@example.net> retrieved
   [C] GROUP misc.test
   [S] 211 1234 234 567 misc.test
   [C] STAT
   [S] 223 234 <different@example.net> retrieved

It should say:

Example reselecting the currently selected newsgroup:

   [C] GROUP misc.test
   [S] 211 123 234 567 misc.test
   [C] STAT 444
   [S] 223 444 <123456@example.net> retrieved
   [C] GROUP misc.test
   [S] 211 123 234 567 misc.test
   [C] STAT
   [S] 223 234 <different@example.net> retrieved

Notes:

Section 6.1.1.2 mentions that "if the group is not empty, the estimate MUST be at least the actual number of articles available and MUST be no greater than one more than the difference between the reported low and high water marks".

The count 1234 is not correct because there are less than 567-234+1=334 articles in the newsgroup.

RFC 3978, "IETF Rights in Contributions", March 2005

Note: This RFC has been obsoleted by RFC 5378

Note: This RFC has been updated by RFC 4748

Source of RFC: ipr (gen)

Errata ID: 200
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Frank Ellermann
Date Reported: 2005-07-02

Section 4.2 says:

      (B) to prepare or allow the preparation of translations of the RFC
          into languages other than English.

It should say:

      (B) to prepare or allow the preparation of translations of the RFC
          into languages other than English,

Notes:

In Section 5.3, it says:
This notice can be used on IETF Contributions that are intended to
provide background information to educate and to facilitate
discussions within IETF working groups but are not intended to be
published as an RFCs.
It should say:
This notice can be used on IETF Contributions that are intended to
provide background information to educate and to facilitate
discussions within IETF working groups but are not intended to be
published as RFCs.

RFC 3981, "IRIS: The Internet Registry Information Service (IRIS) Core Protocol", January 2005

Note: This RFC has been updated by RFC 4992

Source of RFC: crisp (app)

Errata ID: 199
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2005-01-09

Appendix A says:

he whois application protocol label refers to RFC 954 [19].

It should say:

he whois application protocol label refers to RFC 3912 [19].

RFC 3982, "IRIS: A Domain Registry (dreg) Type for the Internet Registry Information Service (IRIS)", January 2005

Source of RFC: crisp (app)

Errata ID: 1305
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Marcos Sanz
Date Reported: 2008-01-29
Verifier Name: Peter Saint-Andre
Date Verified: 2011-08-01

Section 4 says:

     <group
       name="partialMatchGroup">
       <choice>
         <sequence>
           <element
             name="beginsWith">
             <simpleType>
               <restriction
                 base="token">
                 <minLength
                   value="1"/>
               </restriction>
             </simpleType>
           </element>
           <element
             minOccurs="0"
             name="endsWith">
             <simpleType>
               <restriction
                 base="token">
                 <minLength
                   value="1"/>
               </restriction>
             </simpleType>
           </element>
         </sequence>
         <element
           name="endsWith">
           <simpleType>
             <restriction
               base="token">
               <minLength
                 value="1"/>
             </restriction>
           </simpleType>
         </element>
       </choice>
     </group>

It should say:

	<group name="partialMatchGroup">
		<choice>
			<sequence>
				<element name="beginsWith" type="dreg:partialMatchComponentType"/>
				<element name="endsWith" type="dreg:partialMatchComponentType" minOccurs="0"/>
			</sequence>
			<element name="endsWith" type="dreg:partialMatchComponentType"/>
		</choice>
	</group>
	<simpleType name="partialMatchComponentType">
		<restriction base="token">
			<minLength value="1"/>
		</restriction>
	</simpleType>

Notes:

The original definition of the group "partialMatchGroup" violates the rule of consistent element declaration in XML schema:
http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#cos-element-consistent

In order to fix the schema without introducing any semantic changes, a type declaration has been created, which makes the schema valid and more compact.

RFC 3986, "Uniform Resource Identifier (URI): Generic Syntax", January 2005

Note: This RFC has been updated by RFC 6874, RFC 7320, RFC 8820

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 2525
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Christopher Yeleighton
Date Reported: 2010-09-17
Verifier Name: Alexey Melnikov
Date Verified: 2010-11-12

Section 3.1 says:

Advice for designers of new URI schemes can be found in [RFC2718].

It should say:

Advice for designers of new URI schemes can be found in [RFC4395].

Notes:

The document [RFC2718] is for designers of designers of new URL schemes only. It has been obsoleted by [RFC4395] that covers all URI schemes.

[RFC4395]
T. Hansen, T. Hardie, T. and L. Masinter,
"Guidelines and Registration Procedures for New URI Schemes",
RFC 4395, February 2006.

Errata ID: 7590
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Kallus
Date Reported: 2023-08-06
Verifier Name: Orie Steele
Date Verified: 2024-03-29

Section 5.2.4 says:

N/A

It should say:

N/A 

Notes:

The "1" in step 1 of the second example for "remove_dot_segments" has an unintentional hyperlink to section 1 of the document. The hyperlink should be removed.

RFC 3987, "Internationalized Resource Identifiers (IRIs)", January 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 631
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin Duerst
Date Reported: 2007-06-26

Throughout the document, when it says:

[semicolon outside]
"http://example.org/ros&#233";

It should say:

[semicolon inside]
"http://example.org/rosé"

Notes:

In ALL cases, the final semicolon has to be inside the double quotes, not outside. See the example above.

from pending

Errata ID: 629
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Martin Duerst
Date Reported: 2007-06-26

Section 3.1 says:

Syntaxical. 

It should say:

Syntactical. 

Notes:

from pending

RFC 3996, "Internet Printing Protocol (IPP): The 'ippget' Delivery Method for Event Notifications", March 2005

Source of RFC: ipp (app)

Errata ID: 5411
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Sweet
Date Reported: 2018-06-26
Verifier Name: Alexey Melnikov
Date Verified: 2018-07-26

Section 5.2.2 says:

     Table 4.  Additional Attributes in Event Notification Content for
                                Job Events

   Source Value                                  Sends  Source Object

   job-id (integer(1:MAX))                       MUST   Job
   job-state (type1 enum)                        MUST   Job

It should say:

     Table 4.  Additional Attributes in Event Notification Content for
                                Job Events

   Source Value                                  Sends  Source Object

   notify-job-id (integer(1:MAX))                MUST   Job
   job-state (type1 enum)                        MUST   Job

Notes:

The notify-job-id attribute [RFC3995] contains the subscribed Job identifier.

RFC 3998, "Internet Printing Protocol (IPP): Job and Printer Administrative Operations", March 2005

Source of RFC: ipp (app)

Errata ID: 2783
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Zehler
Date Reported: 2011-04-18
Verifier Name: Peter Saint-Andre
Date Verified: 2011-11-14

Section 8.1 says:

8.1.  'hold-new-jobs' Value


   'hold-new-jobs': The operator has issued the Hold-New-Jobs operation
      (see section 3.3.1) or other means, but the output-device(s) are
      taking an appreciable time to stop.  Later, when all output has
      stopped, the "printer-state" becomes 'stopped', and the 'paused'
      value replaces the 'moving-to-paused' value in the "printer-
      state-reasons" attribute.  This value MUST be supported if the
      Hold-New-Jobs operation is supported and the implementation takes
      significant time to pause a device in certain circumstances.

It should say:

8.1.  'hold-new-jobs' Value


   'hold-new-jobs': The operator has issued the Hold-New-Jobs operation
      (see section 3.3.1) or has initiated the holding of new jobs by 
      other means. This value indicates that all Jobs subsequently 
      submitted to the Printer will be placed into the ‘pending-held’ 
      state.  Thus all newly accepted jobs will be automatically held 
      by the Printer.  This “printer-state-reasons” value will be removed 
      when the Operator issues the Release-Held-New-Jobs Operation or 
      releases the holding of new jobs by other means. 

Notes:

This is a cut and paste error.
Note that the definition of the Hold-New-Jobs operation (3.3.1) states:

"When the Printer completes all the 'pending' and 'processing' jobs,
it enters the 'idle' state as usual. An operator monitoring Printer
state changes will know when the Printer has completed all current
jobs because the Printer enters the 'idle' state."

Thus the Printer does not enter the ‘stopped’ state as currently indicated in the text. It is the Pause-Printer
and Pause-Printer-After-Current-Job operations that move the state of the Printer to stopped’ and put the
‘moving-to-paused’ or ‘paused’ values into “printer-state-reasons”.

RFC 4004, "Diameter Mobile IPv4 Application", August 2005

Source of RFC: aaa (ops)

Errata ID: 1462
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Avi Lior
Date Reported: 2008-07-08
Verifier Name: Dan Romascanu
Date Verified: 2009-09-09

Section 9.6 says:

MIP-MN-to-HA-MSA ::= < AVP Header: 331 >
                              { MIP-MN-HA-SPI }
                              { MIP-Algorithm-Type }
                              { MIP-Replay-Mode }
                              { MIP-nonce }
                            * [ AVP ]

It should say:

MIP-MN-to-HA-MSA ::= < AVP Header: 331 >
                              { MIP-MN-to-HA-SPI }
                              { MIP-Algorithm-Type }
                              { MIP-Replay-Mode }
                              { MIP-nonce }
                            * [ AVP ]

Errata ID: 3234
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kurt Wimmer
Date Reported: 2012-05-28
Verifier Name: Benoit Claise
Date Verified: 2012-06-06

Section 7 says:

                                            +--------------------------+
                                            |    AVP Flag rules        |
                                            |----+-----+----+-----|----+
                   AVP  Section             |    |     |SHLD| MUST|MAY |
   Attribute Name  Code Defined  Value Type |MUST| MAY | NOT|  NOT|Encr|
   -----------------------------------------|----+-----+----+-----|----|
   MIP-Home-Agent-  348  7.11    DiamIdent  | M  |  P  |    |  V  | N  |
     Host

It should say:

                                            +--------------------------+
                                            |    AVP Flag rules        |
                                            |----+-----+----+-----|----+
                   AVP  Section             |    |     |SHLD| MUST|MAY |
   Attribute Name  Code Defined  Value Type |MUST| MAY | NOT|  NOT|Encr|
   -----------------------------------------|----+-----+----+-----|----|
   MIP-Home-Agent-  348  7.11    Grouped    | M  |  P  |    |  V  | N  |
     Host

Notes:

The Value Type for MIP-Home-Agent-Host should be Grouped, but the table in section 7 says DiamIdent.

Section 7.11 MIP-Home-Agent-Host AVP says it is grouped, the text in 4004 indicates it is grouped.

RFC 5447 further clarifies that MIP-Home-Agent-Host is a grouped AVP.

RFC 4010, "Use of the SEED Encryption Algorithm in Cryptographic Message Syntax (CMS)", February 2005

Source of RFC: smime (sec)

Errata ID: 3865
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2014-01-10
Verifier Name: Sean Turner
Date Verified: 2014-01-12

Section Appendix A. says:

     SeedEncryptionAlgorithmInCMS
         { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
           pkcs9(9) smime(16) modules(0) id-mod-cms-seed(24) }

It should say:

     SeedEncryptionAlgorithmInCMS
         { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
           pkcs9(9) smime(16) modules(0) id-mod-cms-seed(25) }

Notes:

The value assigned for id-mod-cms-seed in 25, not 24. This error will not impact interoperability, but it could impact developers using some ASN.1 tools.

RFC 4013, "SASLprep: Stringprep Profile for User Names and Passwords", February 2005

Note: This RFC has been obsoleted by RFC 7613

Source of RFC: sasl (sec)

Errata ID: 1812
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alexey Melnikov
Date Reported: 2009-07-18
Verifier Name: Sean Turner
Date Verified: 2010-04-19

Section 2.3 says:

This profile specifies the following characters as prohibited input:

It should say:

This profile specifies the following characters as prohibited output:

Notes:

Per RFC 3454, the check for prohibited characters is done after the "Map" and "Normalize" steps. Characters listed here are actually allowed as inputs if they get removed by the "Map" or "Normalize" steps.

RFC 4025, "A Method for Storing IPsec Keying Material in DNS", March 2005

Source of RFC: ipseckey (sec)

Errata ID: 7402
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tobias Brunner
Date Reported: 2023-03-23
Date Verified: 2023-08-02

Section 2.1 says:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  precedence   | gateway type  |  algorithm  |     gateway     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+                 +
      ~                            gateway                            ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  precedence   | gateway type  |   algorithm   |    gateway    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+               +
      ~                            gateway                            ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

Section 2.4 does not explicitly specify a length for the algorithm field (unlike section 2.2 does for the precedence field). But using only 7 bits for it after the preceding two fields used 8 bits is quite unexpected. So this seems like a mistake in this diagram. Note that the BIND DNS server already uses 8 bits for the algorithm field.

RFC 4028, "Session Timers in the Session Initiation Protocol (SIP)", April 2005

Source of RFC: sip (rai)

Errata ID: 632
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ervin Wittner
Date Reported: 2007-06-25
Verifier Name: Cullen Jennings
Date Verified: 2009-01-08

Section 9 says:

If the incoming request contains a Supported header field with a
value 'timer' but does not contain a Session-Expires header, it means
that the UAS is indicating support for timers but is not requesting
one.

It should say:

If the incoming request contains a Supported header field with a
value 'timer' but does not contain a Session-Expires header, it means
that the UAC is indicating support for timers but is not requesting
one.

Notes:

I believe that in the first sentence, the reference to "...the UAS is
indicating support...." should read "... the UAC is indicating
support..."

Errata ID: 1681
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Muthu Arul Mozhi
Date Reported: 2009-02-09
Verifier Name: Robert Sparks
Date Verified: 2010-04-03

Section 13 says:

In section 13 (Example Call Flow) the From tag never changes 
between the initial INVITE message and the subsequent INVITE 
messages sent after receiving a 422:

message 1
   INVITE sips:bob@biloxi.example.com SIP/2.0
   Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
   Supported: timer
   Session-Expires: 50
   Max-Forwards: 70
   To: Bob <sips:bob@biloxi.example.com>
   From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314159 INVITE
   Contact: <sips:alice@pc33.atlanta.example.com>
   Content-Type: application/sdp
   Content-Length: 142

message 4
   INVITE sips:bob@biloxi.example.com SIP/2.0
   Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9
   Supported: timer
   Session-Expires: 3600
   Min-SE: 3600
   Max-Forwards: 70
   To: Bob <sips:bob@biloxi.example.com>
   From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314160 INVITE
   Contact: <sips:alice@pc33.atlanta.example.com>
   Content-Type: application/sdp
   Content-Length: 142

message 10
   INVITE sips:bob@biloxi.example.com SIP/2.0
   Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds10
   Supported: timer
   Session-Expires: 4000
   Min-SE: 4000
   Max-Forwards: 70
   To: Bob <sips:bob@biloxi.example.com>
   From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314161 INVITE
   Contact: <sips:alice@pc33.atlanta.example.com>
   Content-Type: application/sdp

However, as per RFC 3261, if an initial INVITE generates a non-2xx final
response, that terminates all sessions and all dialogs that were created. 

Hence, these are not re-INVITE messages, rather new INVITE messages and 
should use a new From tag.

It should say:

message 1
   INVITE sips:bob@biloxi.example.com SIP/2.0
   Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
   Supported: timer
   Session-Expires: 50
   Max-Forwards: 70
   To: Bob <sips:bob@biloxi.example.com>
   From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314159 INVITE
   Contact: <sips:alice@pc33.atlanta.example.com>
   Content-Type: application/sdp
   Content-Length: 142

message 4
   INVITE sips:bob@biloxi.example.com SIP/2.0
   Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9
   Supported: timer
   Session-Expires: 3600
   Min-SE: 3600
   Max-Forwards: 70
   To: Bob <sips:bob@biloxi.example.com>
   From: Alice <sips:alice@atlanta.example.com>;tag=2568701785
   Call-ID: a84b4c76e66710
   CSeq: 314160 INVITE
   Contact: <sips:alice@pc33.atlanta.example.com>
   Content-Type: application/sdp
   Content-Length: 142

message 10
   INVITE sips:bob@biloxi.example.com SIP/2.0
   Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds10
   Supported: timer
   Session-Expires: 4000
   Min-SE: 4000
   Max-Forwards: 70
   To: Bob <sips:bob@biloxi.example.com>
   From: Alice <sips:alice@atlanta.example.com>;tag=5647301796
   Call-ID: a84b4c76e66710
   CSeq: 314161 INVITE
   Contact: <sips:alice@pc33.atlanta.example.com>
   Content-Type: application/sdp

Notes:

-----Original Message-----
From: Paul Kyzivat (pkyzivat)
Sent: Monday, February 09, 2009 10:09 PM
To: Muthu ArulMozhi Perumal (mperumal)
Cc: Radha Krishna Saragadam (rsaragad); Jonathan Rosenberg (jdrosen); Ram Mohan R (rmohanr)
Subject: Re: UAS behavior after sending 422 for initial INVITE

yes, I think so.

Paul

Muthu ArulMozhi Perumal (mperumal) wrote:
> In section 13 (Example Call Flow) of RFC 4028 the From tag never changes
> between the initial INVITE message and the subsequent INVITE messages
> sent after receiving a 422:
>
> message 1
> INVITE sips:bob@biloxi.example.com SIP/2.0
> From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
> Call-ID: a84b4c76e66710
>
> message 4
> INVITE sips:bob@biloxi.example.com SIP/2.0
> From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
> Call-ID: a84b4c76e66710
>
> message 10
> INVITE sips:bob@biloxi.example.com SIP/2.0
> From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
> Call-ID: a84b4c76e66710
>
> Is this a bug in the RFC?
>
> thanks,
> Muthu
>
> |-----Original Message-----
> |From: Paul Kyzivat (pkyzivat)
> |Sent: Wednesday, February 04, 2009 12:36 AM
> |To: Radha Krishna Saragadam (rsaragad)
> |Cc: Jonathan Rosenberg (jdrosen); Muthu ArulMozhi Perumal (mperumal);
> Ram Mohan R (rmohanr)
> |Subject: Re: UAS behavior after sending 422 for initial INVITE
> |
> |Radha,
> |
> |It is not a reinvite, because a dialog was never established - the
> first
> |call failed.
> |
> |So you are starting a new invite. You can use the same callid, but
> |should use a new from-tag.
> |
> | Thanks,
> | Paul
> |
> |Radha Krishna Saragadam (rsaragad) wrote:
> |> Hi Paul
> |>
> |> My question is for initial INVITE. For initial INVITE if UA
> |> receives 422 and UA want to retry INVITE with new value increased
> value
> |> then what should be the To(with tag), From(with tag) and CallID
> values?
> |> Is it a Re-INVITE or new a Dialog? Section 7.3 says same value for
> |> To,From and CallID
> |>
> |> Regards
> |> S.Radha krishna

Errata ID: 3614
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: José María González Calabozo
Date Reported: 2013-05-06
Verifier Name: Gonzalo Camarillo
Date Verified: 2013-05-21

Section 13 says:

   Record-Route: sips:p1.atlanta.example.com;lr
   Route: sips:p1.atlanta.example.com;lr

It should say:

   Record-Route: <sips:p1.atlanta.example.com;lr>
   Route: <sips:p1.atlanta.example.com;lr>

Notes:

In the examples, all the Record-Route and Route headers are wrong.

They are:
Record-Route: sips:p1.atlanta.example.com;lr
Route: sips:p1.atlanta.example.com;lr

But according with the section "25.1 Basic Rules" of RFC3261 those headers are defined as:

name-addr = [ display-name ] LAQUOT addr-spec RAQUOT
Record-Route = "Record-Route" HCOLON rec-route *(COMMA rec-route)
rec-route = name-addr *( SEMI rr-param )
rr-param = generic-param
Route = "Route" HCOLON route-param *(COMMA route-param)
route-param = name-addr *( SEMI rr-param )

So the headers should be:
Record-Route: <sips:p1.atlanta.example.com;lr>
Route: <sips:p1.atlanta.example.com;lr>

Errata ID: 4056
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lucas Wang
Date Reported: 2014-07-17
Verifier Name: Orie Steele
Date Verified: 2024-03-29

Section 8 says:

8.  Proxy Behavior

   Session timers are mostly of interest to call stateful proxy servers
   (that is, to servers that maintain the state of calls and dialogs
   established through them).  However, a stateful proxy server (that
   is, a server which is aware of transaction state but does not retain
   call or dialog state) MAY also follow the rules described here.
   Stateless proxies MUST NOT attempt to request session timers.
   Proxies that ask for session timers SHOULD record-route, as they
   won't receive refreshes if they don't.

It should say:

   Session timers are mostly of interest to call stateful proxy servers
   (that is, to servers that maintain the state of calls and dialogs
   established through them).  However, a stateless proxy server (that
   is, a server which is aware of transaction state but does not retain
   call or dialog state) MAY also follow the rules described here.
   Stateless proxies MUST NOT attempt to request session timers.
   Proxies that ask for session timers SHOULD record-route, as they
   won't receive refreshes if they don't.

Notes:

After the "However", it should be a stateless proxy server.

RFC 4029, "Scenarios and Analysis for Introducing IPv6 into ISP Networks", March 2005

Source of RFC: v6ops (ops)

Errata ID: 194
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-06-23

Section 9.1 says:

   Offering native service as quickly as possible is important.  In the
   meantime, however, a 6to4 relay may be provided in the meantime for
   optimized 6to4 connectivity and may also be combined with a tunnel
   broker for extended functionality. 

It should say:

   Offering native service as quickly as possible is important.  In the
   meantime, however, a 6to4 relay may be provided for optimized 6to4 
   connectivity and may also be combined with a tunnel broker for extended 
   functionality. 

Notes:

In Section 12, it says:
[UNMANEVA] Huitema, C., Austein, R., Satapati, S., van der Pol,
R., "Evaluation of Transition Mechanisms for Unmanaged
Networks", Work in Progress.
...
[DNSGUIDE] Durand, A., Ihren, J., "DNS IPv6 transport operational
guidelines", Work in Progress.
It should say:
[UNMANEVA] Huitema, C., Austein, R., Satapati, S., and R. van der Pol,
"Evaluation of IPv6 Transition Mechanisms for Unmanaged
Networks", RFC 3904, September 2004.
...
[DNSGUIDE] Durand, A. and J. Ihren, "DNS IPv6 Transport Operational
Guidelines", BCP 91, RFC 3901, September 2004.

RFC 4033, "DNS Security Introduction and Requirements", March 2005

Note: This RFC has been updated by RFC 6014, RFC 6840

Source of RFC: dnsext (int)

Errata ID: 3043
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Andrews
Date Reported: 2011-12-07
Verifier Name: Brian Haberman
Date Verified: 2012-05-01

Section Updates says:

Updates: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson
         3007, 3597, 3226                                       VeriSign

It should say:

Updates: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson
         3597, 3226                                             VeriSign

Notes:

RFC 4033, 4034 and 4035 all list 3007 as being updated but none of them update 3007.

RFC 4034, "Resource Records for the DNS Security Extensions", March 2005

Note: This RFC has been updated by RFC 4470, RFC 6014, RFC 6840, RFC 6944, RFC 9077

Source of RFC: dnsext (int)

Errata ID: 1062
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Koch
Date Reported: 2005-09-13
Verifier Name: Brian Haberman
Date Verified: 2012-05-01

Section 6.2 says:

   3.  if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
       HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX,
       SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in
       the DNS names contained within the RDATA are replaced by the
       corresponding lowercase US-ASCII letters;

It should say:

[not supplied]

Notes:

Compare with RFC 3597 (section 7):

"As a courtesy to implementors, it is hereby noted that the complete
set of such previously published RR types that contain embedded
domain names, and whose DNSSEC canonical form therefore involves
downcasing according to the DNS rules for character comparisons,
consists of the RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV,
DNAME, and A6."

Almost exactly the same list. One HINFO too much is no issue,
but if this actually should be TXT it's a real typo.

neither TXT nor HINFO contain domain names in RDATA, so it's a bug in both
RFC 3597 and 4034, although one that doesn't hurt. One could also argue that the list lacks NSAP-PTR, but then that's as obsolete as MD ans MF.

Errata ID: 3045
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Andrews
Date Reported: 2011-12-07
Verifier Name: Brian Haberman
Date Verified: 2012-05-01

Section Updates says:

Updates: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson
         3007, 3597, 3226                                       VeriSign

It should say:

Updates: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson
         3597, 3226                                             VeriSign

Notes:

4033, 4034 and 4035 all list 3007 as being updated but none do so.

Errata ID: 4552
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ben Laurie
Date Reported: 2015-12-04
Verifier Name: Brian Haberman
Date Verified: 2015-12-14

Section Appendix B says:

These groups are then added together, ignoring any carry bits.

It should say:

These groups are then added together with at least 32-bit precision,
retaining any carry bits.
The carry bits are then added to the result, and finally, only the lower
16 bits of the result are used as the key tag. Note that this means any
carries generated during the addition of the carry bits are ignored.
This, in turn, means that the keytag calculation is often the same as
reduction modulo 65535, but not always.

Notes:

Errata 2681 already proposes a fix to Appendix B, however the proposed fix is not quite clear. The first part of the corrected text is from 2681.

Its worth pointing this out because a naive analysis says in fact the keytag is exactly the same as reduction modulo 65535, and this has already wasted a fair amount of time.

It is also worth pointing out, perhaps, that this is a poor choice of algorithm for this particular application as it interacts badly with the properties of keys.

Errata ID: 193
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Donald E. Eastlake III
Date Reported: 2005-06-21

In Appendix B.1, it says:

                                                              For a
   DNSKEY RR with algorithm 1, the key tag is defined to be the most
   significant 16 bits of the least significant 24 bits in the public
   key modulus (in other words, the 4th to last and 3rd to last octets
   of the public key modulus).

It should say:

                                                              For a
   DNSKEY RR with algorithm 1, the key tag is defined to be the most
   significant 16 bits of the least significant 24 bits in the public
   key modulus (in other words, the 3rd to last and 2nd to last octets
   of the public key modulus).

RFC 4035, "Protocol Modifications for the DNS Security Extensions", March 2005

Note: This RFC has been updated by RFC 4470, RFC 6014, RFC 6840, RFC 8198, RFC 9077, RFC 9520

Source of RFC: dnsext (int)

Errata ID: 3044
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Andrews
Date Reported: 2011-12-07
Verifier Name: Brian Haberman
Date Verified: 2012-05-01

Section Updates says:

Updates: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson
         3007, 3597, 3226                                       VeriSign

It should say:

Updates: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson
         3597, 3226                                             VeriSign

Notes:

4033, 4034 and 4035 all list 3007 as being updated but none update 3007

Errata ID: 5226
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter van Dijk
Date Reported: 2018-01-04
Verifier Name: Eric Vyncke
Date Verified: 2023-08-03

Section 3.1.4.1 says:

   The need for special processing by a security-aware name server only
   arises when all the following conditions are met:

   o  The name server has received a query for the DS RRset at a zone
      cut.

   o  The name server is authoritative for the child zone.

   o  The name server is not authoritative for the parent zone.

   o  The name server does not offer recursion.

It should say:

   The need for special processing by a security-aware name server only
   arises when all the following conditions are met:

   o  The name server has received a query for the DS RRset at a zone
      cut.

   o  The name server is authoritative for the child zone.

   o  The name server is not authoritative for any zone above the
      child's apex.

   o  The name server does not offer recursion.

Notes:

The original text is ambiguous in the face of an authoritative server having zones C.B.A. and A. but not B.A., and could cause DS queries for C to return a NODATA at C's apex, instead of the desired referral to B. which would allow resolution to continue correctly.

RFC 4038, "Application Aspects of IPv6 Transition", March 2005

Source of RFC: v6ops (ops)

Errata ID: 6504
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Glenn Adams
Date Reported: 2021-03-30
Verifier Name: Erik Kline
Date Verified: 2021-03-31

Section 5.4.2 says:

This memo takes no stance on that approach is best.

It should say:

This memo takes no stance on which approach is best.

Notes:

Grammar correction.

RFC 4043, "Internet X.509 Public Key Infrastructure Permanent Identifier", May 2005

Source of RFC: pkix (sec)

Errata ID: 192
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Denis Pinkas
Date Reported: 2007-02-07

Appendix A.2. 1993 ASN.1 Module says:

Appendix A.2.  1993 ASN.1 Module

PKIXpermanentidentifier93 {iso(1) identified-organization(3) dod(6)
       internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
       id-mod-perm-id-93(29) }

   DEFINITIONS EXPLICIT TAGS ::=

   BEGIN

   -- EXPORTS ALL --

   IMPORTS

        id-pkix
              FROM PKIX1Explicit88 { iso(1) identified-organization(3)
              dod(6) internet(1) security(5) mechanisms(5) pkix(7)
              id-mod(0) id-pkix1-explicit(18) }
               -- from [RFC3280]

        ATTRIBUTE
              FROM InformationFramework {joint-iso-itu-t ds(5) module(1)
              informationFramework(1) 4};
               -- from [X.501]

   -- Permanent identifier Object Identifiers

   id-on   OBJECT IDENTIFIER ::= { id-pkix 8 }

   id-on-permanentIdentifier   OBJECT IDENTIFIER ::= { id-on 3 }

   -- Permanent Identifier

   permanentIdentifier ATTRIBUTE ::= {
          WITH SYNTAX     PermanentIdentifier
          ID              id-on-permanentIdentifier }

   PermanentIdentifier ::= SEQUENCE {
        identifierValue    UTF8String             OPTIONAL,
                        -- if absent, use the serialNumber attribute
                        -- if there is a single such attribute present
                        -- in the subject DN
        assigner           OBJECT IDENTIFIER      OPTIONAL
                        -- if absent, the assigner is
                        -- the certificate issuer
}

END

It should say:

Appendix A.2.  1993 ASN.1 Module

   PKIXpermanentidentifier93 {iso(1) identified-organization(3) dod(6)
       internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
       id-mod-perm-id-93(29) }

   DEFINITIONS EXPLICIT TAGS ::=

   BEGIN

   -- EXPORTS ALL --

    IMPORTS
        OTHER-NAME
            FROM CertificateExtensions {joint-iso-itu-t ds(5) module(1)
              certificateExtensions(26) 4} ;
              -- from Module CertificateExtensions (X.509:03/2000)


   -- Permanent identifier Object Identifiers

   id-pkix  OBJECT IDENTIFIER  ::=  { iso(1)
       identified-organization(3) dod(6) internet(1)security(5)
       mechanisms(5) pkix(7) }

   id-on   OBJECT IDENTIFIER ::= { id-pkix 8 }

   id-on-permanentIdentifier   OBJECT IDENTIFIER ::= { id-on 3 }


   -- Permanent Identifier

   permanentIdentifier OTHER-NAME ::=
     { PermanentIdentifier IDENTIFIED BY id-on-permanentIdentifier }

   PermanentIdentifier ::= SEQUENCE {
        identifierValue    UTF8String             OPTIONAL,
                        -- if absent, use the serialNumber attribute
                        -- if there is a single such attribute present
                        -- in the subject DN
        assigner           OBJECT IDENTIFIER      OPTIONAL
                        -- if absent, the assigner is
                        -- the certificate issuer
   }

   END

Notes:

RFC 4048, "RFC 1888 Is Obsolete", April 2005

Note: This RFC has been updated by RFC 4548

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 772
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Brian E Carpenter
Date Reported: 2005-07-28

Section Section 4 says:

IANA Considerations, of RFC 4048 omitted to request IANA
to release IPv6 option type code 11-0-00011 = 195 decimal, C3 hexadecimal.

It should say:

[see above]

Notes:

from pending

RFC 4051, "Additional XML Security Uniform Resource Identifiers (URIs)", April 2005

Note: This RFC has been obsoleted by RFC 6931

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 191
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Donald Eastlake III
Date Reported: 2005-11-08

Section 2.3.5 says:

Identifier:
  http://www.w3.org/2001/04/xmldsig-more/rsa-ripemd160

...

<SignatureMethod
  Algorithm="http://www.w3.org/2001/04/xmldsig-more/rsa-ripemd160" />

It should say:

Identifier:
  http://www.w3.org/2001/04/xmldsig-more#rsa-ripemd160

...

<SignatureMethod
  Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-ripemd160" />

Notes:

In Section 2.3.5, the two URLs should have their right-most slash ("/") replaced with a pound sign ("#").

RFC 4052, "IAB Processes for Management of IETF Liaison Relationships", April 2005

Source of RFC: IAB

Errata ID: 190
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-05-17

Section 7.2 says:

   [6]  Trowbridge, S., Bradner, S., and F. Baker, "Procedure for
        Handling Liaison Statements Between Standards Bodies",
        June 2004.

It should say:

   [6]  Trowbridge, S., Bradner, S., and F. Baker, "Procedures for 
        Handling Liaison Statements to and from the IETF", BCP 103, 
        RFC 4053, April 2005.

Notes:

Also reported by Loa Andersson <loa@pi.se> on Mon, 25 Jul 2005 14:21:06 +0200.

RFC 4055, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", June 2005

Note: This RFC has been updated by RFC 5756

Source of RFC: pkix (sec)

Errata ID: 1468
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sean Turner
Date Reported: 2008-07-09
Verifier Name: Tim Polk
Date Verified: 2008-11-19

Section 3 says:

   CAs that issue certificates with the id-RSASSA-PSS algorithm
   identifier SHOULD require the presence of parameters in the
   publicKeyAlgorithms field if the cA boolean flag is set in the basic
   constraints certificate extension.  CAs MAY require that the
   parameters be present in the publicKeyAlgorithms field for end-entity
   certificates.

It should say:

   CAs that issue certificates with the id-RSASSA-PSS algorithm 
   identifier SHOULD require the presence of parameters in the 
   subjectPublicKeyInfo algorithm field if the cA boolean flag is set 
   in the basic constraints certificate extension.  CAs MAY require 
   that the parameters be present in the subjectPublicKeyInfo algorithm 
   field for end-entity certificates. 

Notes:

The correct name of the field is "subjectPublicKeyInfo algorithm field" as opposed to "publicKeyAlgorithms field". Note that this change is also included in the draft-ietf-pkix-rfc4055-update ID.

Errata ID: 1676
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-02-02
Verifier Name: Sean Turner
Date Verified: 2010-04-19

Section 3.1, 4.1 says:

a)  Section 3.1, explanation of maskGenAlgorithm, last paragraph
    (2nd paragraph on page 9)

b)  Section 4.1, explanation of maskGenFunc, last paragraph
    (2nd paragraph on page 11)
 
both say:

         Although mfg1SHA1Identifier is defined as the default value for
         this field, implementations MUST accept both the default value
         encoding (i.e., an absent field) and mfg1SHA1Identifier to be
         explicitly present in the encoding.

It should say:

both a) and b) should say:

         Although mgf1SHA1Identifier is defined as the default value for
         this field, implementations MUST accept both the default value
         encoding (i.e., an absent field) and mgf1SHA1Identifier to be
         explicitly present in the encoding.

Notes:

Rationale: 4 instances of the same character twister:

mfg1SHA1Identifier
--- ^^
mgf1SHA1Identifier

Note: "MGF" is the abbreviation of "Mask Generation Function".

RFC 4056, "Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message Syntax (CMS)", June 2005

Source of RFC: smime (sec)

Errata ID: 7280
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jaak Ristioja
Date Reported: 2022-12-20
Verifier Name: RFC Editor
Date Verified: 2022-12-20

Section 2.2 says:

The algorithm identifier for RSASAA-PSS signatures is:

It should say:

The algorithm identifier for RSASSA-PSS signatures is:

Notes:

Replace RSASAA-PSS with RSASSA-PSS.

RFC 4057, "IPv6 Enterprise Network Scenarios", June 2005

Source of RFC: v6ops (ops)

Errata ID: 189
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-06-17

Section 4.6 says:

                                                          Network
   management will not need to support both IPv4 and IPv6 and view nodes
   as dual stacks.

It should say:

                                                          Network
   management will need to support both IPv4 and IPv6 and view nodes
   as dual stacks.

RFC 4060, "RTP Payload Formats for European Telecommunications Standards Institute (ETSI) European Standard ES 202 050, ES 202 211, and ES 202 212 Distributed Speech Recognition Encoding", May 2005

Source of RFC: avt (rai)

Errata ID: 188
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-05-17

Section 2.2 says:

   The additional fundamental frequency and voicing class information is
   compressed for each frame pair.  The pitch for the first frame of the
   FP is quantized to 7 bits and the second frame is differentially
   quantized to 7 bits. 

It should say:

   The additional fundamental frequency and voicing class information is
   compressed for each frame pair.  The pitch for the first frame of the
   FP is quantized to 7 bits and the second frame is differentially
   quantized to 5 bits. 

RFC 4086, "Randomness Requirements for Security", June 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 4960
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2017-03-09
Verifier Name: Paul Wouters
Date Verified: 2023-08-03

Section 8.2.1 says:

   If the adversary can command a highly parallel processor or a large
   network of work stations, 10^11 cycles per second is probably a
   minimum assumption today.  Looking forward a few years, there should
   be at least an order of magnitude improvement.  Thus, it is
   reasonable to assume that 10^10 keys could be checked per second, or
   3.6*10^12 per hour or 6*10^14 per week, or 2.4*10^15 per month. 

It should say:

   If the adversary can command a highly parallel processor or a large
   network of work stations, 10^11 cycles per second is probably a
   minimum assumption today.  Looking forward a few years, there should
   be at least an order of magnitude improvement.  Thus, it is
   reasonable to assume that 10^10 keys could be checked per second, or
   3.6*10^13 per hour or 8.6*10^14 per week, or 2.6*10^16 per month. 

Notes:

Incorrect values.

AD Note: The proposed corrected text is also incorrect though. The number 8.6*10^14 is per day, not per week. The per week number is 6.48 * 10^15. The proposed updated numbers for per hour and per month are a correct update. So the proposed final text should be:

or 3.6*10^13 per hour or 6.48 * 10^15 per week, or 2.6*10^16 per month.

Errata ID: 5386
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: David Jonasson
Date Reported: 2018-06-08
Verifier Name: Paul Wouters
Date Verified: 2023-08-03

Throughout the document, when it says:

   [DoD]           "Password Management Guideline", United States of
                   America, Department of Defense, Computer Security
                   Center, CSC-STD-002-85, April 1885.

It should say:

   [DoD]           "Password Management Guideline", United States of
                   America, Department of Defense, Computer Security
                   Center, CSC-STD-002-85, April 1985.

Notes:

This Informative Reference had the wrong century as publish date.

RFC 4090, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", May 2005

Note: This RFC has been updated by RFC 8271, RFC 8537, RFC 8796

Source of RFC: mpls (rtg)

Errata ID: 4203
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Yakov Rekhter
Date Reported: 2014-12-17
Verifier Name: Alia Atlas
Date Verified: 2015-01-06

Section 6 says:

Whenever the PLR has a backup path available, the PLR MUST set
the "local protection available" flag.

It should say:

Whenever the PLR has a backup path available, the PLR MUST set
the "local protection available" flag.  For example, if the PLR 
has determined to use a bypass tunnel and set up the necessary 
local forwarding state to be able to use it as a backup path, 
then that PLR has a backup path available.

Notes:

In the case of facility-based FRR the PLR must set the "local protection available" flag if it has the bypass tunnel available and the local forwarding state is set up.

Errata ID: 6203
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mihir Amrelia
Date Reported: 2020-06-03
Verifier Name: Deborah Brungard
Date Verified: 2021-02-26

Section 6 says:

If the "bandwidth protection guaranteed" flag is set, the PLR SHOULD try to
provide a bandwidth guarantee; if this is not feasible, the PLR SHOULD then try
to provide a backup without a guarantee of the full bandwidth.

It should say:

If the "bandwidth protection desired" flag is set in SESSION_ATTRIBUTE, the PLR
SHOULD try to provide a bandwidth guarantee; if this is not feasible, the PLR
SHOULD then try to provide a backup without a guarantee of the full bandwidth.

Notes:

Correcting flag name.

Errata ID: 6939
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Igor Malyushkin
Date Reported: 2022-04-20
Verifier Name: Andrew Alston
Date Verified: 2022-05-26

Section 4.4 says:

To report whether bandwidth and/or node protection are provided as requested, we define two new flags in the RRO IPv4 sub-object.

It should say:

To report whether bandwidth and/or node protection are provided as requested, we define two new flags in the RRO IPv4 sub-object and RRO IPv6 sub-object.

Notes:

Forgotten IPv6 sub-object. The title of the section implies the usage of both versions of IP protocol. Later in this section (and the document), both sub-objects are also referred to.

RFC 4106, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", June 2005

Source of RFC: ipsec (sec)

Errata ID: 1919
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Hoffman
Date Reported: 2009-10-20
Verifier Name: Pasi Eronen
Date Verified: 2010-03-01

Section 14 says:

   [GCM]      McGrew, D. and J. Viega, "The Galois/Counter Mode of
              Operation (GCM)", Submission to NIST. http://
              csrc.nist.gov/CryptoToolkit/modes/proposedmodes/gcm/
              gcm-spec.pdf, January 2004.

It should say:

[GCM]      Dworkin, M. "Recommendation for Block Cipher Modes
of Operation: Galois/Counter Mode (GCM) and GMAC", NIST Special
Publication 800-38D, November 2007.

Notes:

The previous URL is dead. According to David McGrew, SP 800-38D is an acceptable substitute for the original paper. Note that this is a normative reference for good reason: there are many details in the referred-to document that are needed to implement RFC 4106.

RFC 4108, "Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages", August 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 4093
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: George Taylor
Date Reported: 2014-09-03
Verifier Name: Kathleen Moriarty
Date Verified: 2015-03-31

Section Appendix A says:

It should say:

id-aa-fwPkgMessageDigest OBJECT IDENTIFIER ::= {
        iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
        smime(16) aa(2) 41 }
and 
FirmwarePackageMessageDigest ::= SEQUENCE {
        algorithm AlgorithmIdentifier,
        msgDigest OCTET STRING }
from section 2.2.10 do not appear in the ASN.1 module.

Notes:

Yes the two items are missing from the ASN.1 module at the end of the document.

RFC 4110, "A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", July 2005

Source of RFC: l3vpn (int)

Errata ID: 7284
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Raoul Estourgie
Date Reported: 2022-12-22
Verifier Name: RFC Editor
Date Verified: 2022-12-22

Section 1.1 says:

Solutions will need to chose between flexibility (supporting multiple options) and conciseness (selection of specific options in order to simplify implementation and deployment).

It should say:

Solutions will need to choose between flexibility (supporting multiple options) and conciseness (selection of specific options in order to simplify implementation and deployment).

Notes:

In this sentence, "choose" is the correct verb to use because it means to select or make a decision between two or more alternatives. "Chose" is the past tense of "choose," so it would not be correct to use in this context.

RFC 4111, "Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)", July 2005

Note: This RFC has been updated by RFC 8996

Source of RFC: l3vpn (int)

Errata ID: 3143
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Adam Roach
Date Reported: 2012-02-29
Verifier Name: Brian Haberman
Date Verified: 2012-09-07

Section 14 says:

   [RFC3889]    Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
                Routing Protocols", RFC 3889, October 2004.

It should say:

   [RFC4593]    Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
                Routing Protocols", RFC 4593, October 2006.

Notes:

Although the cited document appears to have reached the AUTH48 stage in 2004 and was provisionally assigned an RFC number of 3889, it was withdrawn for further editing and was never actually published under that number. Its eventual publication in 2006 was under the RFC number 4593.

RFC 4114, "E.164 Number Mapping for the Extensible Provisioning Protocol (EPP)", June 2005

Source of RFC: enum (rai)

Errata ID: 186
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bernie Hoeneisen
Date Reported: 2005-06-21

Section 3.1.2 says:

   Example <info> response:

   [...]
   S:    <domain:name>3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa</domain:name>
   S:    <domain:roid>EXAMPLE1-REP</domain:roid>
   S:    <domain:status s="ok"/>
   S:    <domain:registrant>jd1234</domain:registrant>
   S:    <domain:contact type="admin">sh8013</domain:contact>
   S:    <domain:contact type="tech">sh8013</domain:contact>
   S:    <domain:ns>
   S:     <domain:hostObj>ns1.example.com</domain:hostObj>
   S:     <domain:hostObj>ns2.example.com</domain:hostObj>
   S:    </domain:ns>
   S:    <domain:host>ns1.example.com</domain:host>
   S:    <domain:host>ns2.example.com</domain:host>
   S:    <domain:clID>ClientX</domain:clID>
   S:    <domain:crID>ClientY</domain:crID>
   [...]

It should say:

   Example <info> response:

   [...]
   S:    <domain:name>3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa</domain:name>
   S:    <domain:roid>EXAMPLE1-REP</domain:roid>
   S:    <domain:status s="ok"/>
   S:    <domain:registrant>jd1234</domain:registrant>
   S:    <domain:contact type="admin">sh8013</domain:contact>
   S:    <domain:contact type="tech">sh8013</domain:contact>
   S:    <domain:ns>
   S:     <domain:hostObj>ns1.example.com</domain:hostObj>
   S:     <domain:hostObj>ns2.example.com</domain:hostObj>
   S:    </domain:ns>
   S:    <domain:clID>ClientX</domain:clID>
   S:    <domain:crID>ClientY</domain:crID>
   [...]

Notes:

There is the <domain:host> that should list the "fully qualified names
of the subordinate host objects that exist under this superordinate domain object."
As the <domain:name> is not "example.com:, those <domain:host> elements should be
removed.

RFC 4117, "Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc)", June 2005

Source of RFC: sipping (rai)

Errata ID: 185
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Gonzalo Camarillo
Date Reported: 2005-08-22

Section 3 says:

      |--------------------(4) INVITE SDP TA------------------->|
      |                            |                            |
      |<--------------------(5) 200 OK SDP B--------------------|
      |                            |                            |
      |-------------------------(6) ACK------------------------>|
      |                            |                            |
      |--------(7) INVITE--------->|                            |
      |                            |                            |
      |<---(8) 200 OK SDP TA+TB  --|                            |
      |                            |                            |
      |--------------------(9) INVITE SDP TA------------------->|

It should say:

      |--------------------(4) INVITE SDP TB------------------->|
      |                            |                            |
      |<--------------------(5) 200 OK SDP B--------------------|
      |                            |                            |
      |-------------------------(6) ACK------------------------>|
      |                            |                            |
      |--------(7) INVITE--------->|                            |
      |                            |                            |
      |<---(8) 200 OK SDP TA+TB  --|                            |
      |                            |                            |
      |--------------------(9) INVITE SDP TB------------------->|

RFC 4119, "A Presence-based GEOPRIV Location Object Format", December 2005

Note: This RFC has been updated by RFC 5139, RFC 5491, RFC 7459

Source of RFC: geopriv (rai)

Errata ID: 1535
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Eduardo Cardona
Date Reported: 2008-10-03
Verifier Name: Robert Sparks
Date Verified: 2010-05-23

Section 2.2.2 says:

2.2.2.  'usage-rules' Element
   'retransmission-allowed': When the value of this element is 'no', the
      Recipient of this Location Object is not permitted to share the
      enclosed Location Information, or the object as a whole, with
      other parties.  When the value of this element is 'yes',


 snip.. 

 'retention-expires': This field specifies an absolute date at which
      time the Recipient is no longer permitted to possess the location

snip..
 'ruleset-reference': This field contains a URI that indicates where a
      fuller ruleset of policies, related to this object, can be found.

Notes:

Definitions do not match with the XML schema :

* boolean according to XML Schema Part 2: Datatypes Second Edition is either 'true', 'false', '0', or '1'

<xs:element name="retransmission-allowed" type="xs:boolean"
minOccurs="0" maxOccurs="1"/>

* Element names do not match

<xs:element name="retention-expiry" type="xs:dateTime"
minOccurs="0" maxOccurs="1"/>

<xs:element name="external-ruleset" type="xs:anyURI"
minOccurs="0" maxOccurs="1"/>

Errata ID: 1771
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Martin Thomson
Date Reported: 2009-05-03
Verifier Name: Robert Sparks
Date Verified: 2010-05-23

Section 2.3 says:

 <presence xmlns="urn:ietf:params:xml:ns:pidf"
    xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
    xmlns:cl=" urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc"
    entity="pres:geotarget@example.com">
...
      <gp:usage-rules>
        <gp:retransmission-allowed>no</gp:retransmission-allowed>
        <gp:retention-expiry>2003-06-23T04:57:29Z</gp:retention-expiry>
      </gp:usage-rules>

It should say:

 <presence xmlns="urn:ietf:params:xml:ns:pidf"
    xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
    xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
    xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc"
    entity="pres:geotarget@example.com">
...
      <gp:usage-rules>
        <gbp:retransmission-allowed>no</gbp:retransmission-allowed>
        <gbp:retention-expiry>2003-06-23T04:57:29Z</gbp:retention-expiry>
      </gp:usage-rules>

Notes:

This applies to both examples in Section 2.3. The use of the "urn:ietf:params:xml:ns:pidf:geopriv10" namespace for the retransmission-allowed and retention-expiry elements is incorrect. These elements are defined in the "urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy" namespace.

This does not manifest in an error in parsers due to the allowance for extensions. The XML schema <any> rule with processContents="lax" permits unknown elements, as these are. A schema-aware processor would not reliably detect these elements, potentially leading to them being ignored.

To reveal this problem, validate these examples against a schema with processContents="strict" on all <any> elements.

Errata ID: 7528
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Shraddha Soni
Date Reported: 2023-05-29
Verifier Name: Orie Steele
Date Verified: 2024-03-25

Section Normative References says:

[15]  OpenGIS, "Open Geography Markup Language (GML) Implementation
         Specification", OGC 02-023r4, January 2003,
         <http://www.opengeospatial.org/specs/?page=specs>.

It should say:

[15]  OpenGIS, "Open Geography Markup Language (GML) Implementation
         Specification", OGC 02-023r4, January 2003,
         <https://www.ogc.org/standard/gml/>.



         

Notes:

On clicking the link, now we get "Page not found" Error. It is best to avoid links to external website which is not maintained by rfc-editor.

RFC 4120, "The Kerberos Network Authentication Service (V5)", July 2005

Note: This RFC has been updated by RFC 4537, RFC 5021, RFC 5896, RFC 6111, RFC 6112, RFC 6113, RFC 6649, RFC 6806, RFC 7751, RFC 8062, RFC 8129, RFC 8429, RFC 8553

Source of RFC: krb-wg (sec)

Errata ID: 7022
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Gabriel Potter
Date Reported: 2022-07-13
Verifier Name: RFC Editor
Date Verified: 2022-07-26

Section 5.2.6.2 says:

checksumtype

It should say:

cksumtype

Notes:

The field is named "cksumtype" according to section 5.2

--VERIFIER NOTES--
Correction - The field is named in section 5.2.9.

RFC 4122, "A Universally Unique IDentifier (UUID) URN Namespace", July 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 1352
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Frank Ellermann
Date Reported: 2008-03-08
Verifier Name: Alexey Melnikov
Date Verified: 2009-12-04

In Appendix B, it says:

uuid_create_md5_from_name(): e902893a-9d22-3c7e-a7b8-d6e313b71d9f

It should say:

uuid_create_md5_from_name(): 3d813cbb-47fb-32ba-91df-831e1593ac29

Notes:

The given value e902... etc. is based on a calculation swapping the eight octets 0..3, 4..5, 6..7 twice, for the name space UUID, and for the MD5 output, as foreseen for little endian input, but the example values were already big endian. I can reproduce the example and the proposed fix, see <http://omniplex.blogspot.com/2008/03/md5-16-pop3-and-uuid.html>.

The blog entry contains links to an identical older error report, and two (different) examples from third parties also agreeing with that theory.

Errata ID: 1428
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2008-05-22
Verifier Name: Alexey Melnikov
Date Verified: 2009-12-04

Section 3 says:

UUIDs, as defined in this document, can also be ordered lexicographically.
For a pair of UUIDs, the first one follows the second if the most significant
field in which the UUIDs differ is greater for the first UUID.  The second
precedes the first if the most significant field in which the UUIDs differ
is greater for the second UUID.

It should say:

UUIDs, as defined in this document, can also be ordered lexicographically.
For a pair of UUIDs, the first one follows the second if the most significant
field in which the UUIDs differ is greater for the first UUID.  The second
follows the first if the most significant field in which the UUIDs differ
is greater for the second UUID.

Notes:

The second and third sentences in the paragraph as originally written are
inconsistent. I have proposed one of the possible fixes. There are others
that will make them consistent.

Errata ID: 3641
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Douglas Ray
Date Reported: 2013-06-06
Verifier Name: Barry Leiba
Date Verified: 2013-06-06

Throughout the document, when it says:

Advice on generating cryptographic-quality random numbers can be
   found in RFC1750 [5].

It should say:

Advice on generating cryptographic-quality random numbers can be
   found in RFC4086 [5].

Notes:

(Above sample is from section 4.5).
References to RFC 1750 should currently refer to RFC 4086.
(Likewise in Appendix A.)
The note [5] actually references RFC4086, but this is the only
point that is updated, ie, the document is inconsistent in its references.
The references in Appendix A are not cross-referenced to note [5].

------------------------ Verifier notes ------------------------
This is correct: reference [5] was updated to point to 4086, but the text in the
document body was not changed accordingly.

Errata ID: 184
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tim Wilson-Brown
Date Reported: 2006-05-03
Verifier Name: Alexey Melnikov
Date Verified: 2009-12-04

Section 4.3 says:

The UUIDs generated from the same name in two different namespaces
       should be different with (very high probability).

It should say:

The UUIDs generated from the same name in two different namespaces
       should be different (with very high probability).

Notes:

The brackets should be set similarly to the other points.

Errata ID: 3476
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Simon Kissane
Date Reported: 2013-02-02
Verifier Name: Barry Leiba
Date Verified: 2013-02-03

Section Appendix A,B says:

In Appendix A, the line:
    uuid_create_md5_from_name(&u, NameSpace_DNS, "www.widgets.com", 15);
In Appendix B, the line:
     uuid_create_md5_from_name(): e902893a-9d22-3c7e-a7b8-d6e313b71d9f

It should say:

In Appendix A, the line:
    uuid_create_md5_from_name(&u, NameSpace_DNS, "www.example.com", 15);
In Appendix B, the line:
     uuid_create_md5_from_name(): 5df41881-3aed-3515-88a7-2f4a814cf09e

Notes:

Per RFC2606 section 5, it is best practice for standards and other documentation (including RFCs) to use the reserved example domains (e.g. example.com) rather than domains which could be in actual use. Indeed, the domain in question (www.widgets.com) is in actual use at the time of writing. So this proposed change uses "www.example.com" instead, and changes the example output accordingly. (Note that original output was wrong for the original input, as already noted in verified errata 1352.)

Errata ID: 6665
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Andrzej Koszela
Date Reported: 2021-08-25
Verifier Name: Orie Steele
Date Verified: 2024-03-29

Section Appendix A says:

static unsigned16 true_random(void);

/* uuid_create -- generator a UUID */
int uuid_create(uuid_t *uuid)
{
     uuid_time_t timestamp, last_time;

It should say:

static unsigned16 true_random(void);

/* uuid_create -- generate a UUID */
int uuid_create(uuid_t *uuid)
{
     uuid_time_t timestamp, last_time;

Notes:

The comment above the declaration of uuid_create() uses "generate a UUID", so the comment above the definition is likely intended to be identical.

RFC 4130, "MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)", July 2005

Source of RFC: ediint (app)

Errata ID: 3028
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kyle Meadors
Date Reported: 2011-09-16
Verifier Name: Pete Resnick
Date Verified: 2011-11-12

Section 7.4.3 says:

   digest-alg-id = "sha1" | "md5"

It should say:

   digest-alg-id = "sha-1" | "sha1" | "md5"
		; The "sha1" is a legacy spelling of the "sha-1" defined hash in the IANA Textual Names Registry
		; It should be maintained for backwards compatibility

Notes:

The proper spelling is "sha-1" per http://www.iana.org/assignments/hash-function-text-names/hash-function-text. However, "sha1" should still be accepted to support backwards compatibility. The other hashes are newer ones since the RFC was published.
--VERIFIER NOTES--
Split off erratum 1974

Errata ID: 3029
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kyle Meadors
Date Reported: 2011-09-16
Verifier Name: Pete Resnick
Date Verified: 2011-11-12

Section 7.3 says:

   The currently supported values for MIC algorithm <micalg> values are:

        Algorithm   Value Used
        ---------    -------
         SHA-1        sha1
         MD5          md5

It should say:

   The currently supported values for MIC algorithm <micalg> values are:

        Algorithm   Value Used
        ---------    -------

         SHA-1      sha-1 or sha1
         MD5        md5

Notes:

The proper spelling is "sha-1" per http://www.iana.org/assignments/hash-function-text-names/hash-function-text. However, "sha1" should still be accepted to support backwards compatibility.

Errata ID: 1575
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: r. deutsch
Date Reported: 2008-10-14
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-20

Section 4.1 says:

Any difference between AS2 implantations and RFCs are
                           ^^^^^^^^^^^^^
   mentioned specifically in the sections below.

It should say:

Any difference between AS2 implementations and RFCs are
                           ^^^^^^^^^^^^^^^
   mentioned specifically in the sections below.

Notes:

The word "implantations" should be "implementations".

Errata ID: 4743
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Joe Touch
Date Reported: 2016-07-15
Verifier Name: Orie Steele
Date Verified: 2024-03-29

Section A.3, A.4 says:

A.3.  Signed, Encrypted Message Requesting a Signed, Asynchronous
      Receipt

   Message-ID: <#as2_company#01#a4260as2_companyout#>
   Date: Thu, 19 Dec 2002 15:04:18 GMT
   From: me@example.com
   Subject: Async MDN request
   Mime-Version: 1.0
   Content-Type: application/pkcs7-mime;
     smime-type=enveloped-data; name=smime.p7m
   Content-Transfer-Encoding: binary
   Content-Disposition: attachment; filename=smime.p7m
   Recipient-Address: 10.240.1.2//
   Disposition-Notification-To:
     http://10.240.1.2:8201/exchange/as2_company
   Disposition-Notification-Options: signed-receipt-protocol=optional,
    pkcs7-signature; signed-receipt-micalg=optional,sha1
   Receipt-Delivery-Option:
     http://10.240.1.2:8201/exchange/as2_company
   AS2-From: as2_company
   AS2-To: "AS2 Test"
   AS2-Version: 1.1
   Host: 10.240.1.2:8101
   Connection: close
   Content-Length: 3428

     [omitted binary encrypted data]



Moberg & Drummond           Standards Track                    [Page 44]

RFC 4130     AS2 for Business Data Interchange Using HTTP      July 2005


A.4.  Asynchronous MDN for Message A.3, Above

   POST / HTTP/1.1
   Host: 10.240.1.2:8201
   Connection: close, TE
   TE: trailers, deflate, gzip, compress
   User-Agent: RPT-HTTPClient/0.3-3I (Windows 2000)
   Date: Thu, 19 Dec 2002 15:03:38 GMT
   Message-ID: <AS2-20021219_030338@as2_company.dgi_th>
   AS2-Version: 1.1
   Mime-Version: 1.0
   Recipient-Address:
   http://10.240.1.2:8201/exchange/as2_company
   AS2-To: as2_company
   AS2-From: "AS2 Test"
   Subject: Your Requested MDN Response
   From: as2debug@example.com
   Accept-Encoding: deflate, gzip, x-gzip, compress, x-compress
   Content-Type: multipart/signed; micalg=sha1;
     protocol="application/pkcs7-signature";
     boundary="----=_Part_337_6452266.1040310218750"
   Content-Length: 3103

   ------=_Part_337_6452266.1040310218750
   Content-Type: multipart/report;
     report-type=disposition-notification;
     boundary="----=_Part_336_6069110.1040310218718"

   ------=_Part_336_6069110.1040310218718
   Content-Type: text/plain; charset=us-ascii
   Content-Transfer-Encoding: 7bit

   The message <x12.edi> sent to Recipient <AS2 Test> on Thu, 19 Dec
   2002 15:04:18 GMT with Subject <async MDN request> has been received.
   The EDI Interchange was successfully decrypted, and its integrity was
   verified.  In addition, the sender of the message, Sender
   <as2_company> at Location http://10.240.1.2:8201/exchange/as2_company
   was authenticated as the originator of the message.  There is no
   guarantee, however, that the EDI interchange was syntactically
   correct, or that it was received by the EDI application/translator.











Moberg & Drummond           Standards Track                    [Page 45]

RFC 4130     AS2 for Business Data Interchange Using HTTP      July 2005


   ------=_Part_336_6069110.1040310218718
   Content-Type: message/disposition-notification
   Content-Transfer-Encoding: 7bit

   Reporting-UA: AS2@test:8101
   Original-Recipient: rfc822; "AS2 Test"
   Final-Recipient: rfc822; "AS2 Test"
   Original-Message-ID: <#as2_company#01#a4260as2_companyout#>
   Disposition: automatic-action/MDN-sent-automatically;
     processed
   Received-Content-MIC: Hes6my+vIxIYxmvsA+MNpEOTPAc=, sha1

   ------=_Part_336_6069110.1040310218718--

   ------=_Part_337_6452266.1040310218750
   Content-Type: application/pkcs7-signature; name=smime.p7s
   Content-Transfer-Encoding: base64
   Content-Disposition: attachment; filename=smime.p7s

   BhbWjEfbyXoTAS/H0zpnEqLqbaBh29y2v82b8bdeGw8pipBQWmf53hIcqHGM
   4ZBF3CHw5Wrf1JIE+8TwOzdbal30zeChw88WfRfD7c/j1fIA8sxsujvf2d9j
   UxCUga8BVdVB9kH0Geexytyt0KvWQXfaEEcgZGUAAAAAAAA=

   ------=_Part_337_6452266.1040310218750-

It should say:

A.3.  Signed, Encrypted Message Requesting a Signed, Asynchronous
      Receipt

   Message-ID: <#as2_company#01#a4260as2_companyout#>
   Date: Thu, 19 Dec 2002 15:04:18 GMT
   From: me@example.com
   Subject: Async MDN request
   Mime-Version: 1.0
   Content-Type: application/pkcs7-mime;
     smime-type=enveloped-data; name=smime.p7m
   Content-Transfer-Encoding: binary
   Content-Disposition: attachment; filename=smime.p7m
   Recipient-Address: 10.240.1.2//
   Disposition-Notification-To:
     http://10.240.1.2:58201/exchange/as2_company
   Disposition-Notification-Options: signed-receipt-protocol=optional,
    pkcs7-signature; signed-receipt-micalg=optional,sha1
   Receipt-Delivery-Option:
     http://10.240.1.2:58201/exchange/as2_company
   AS2-From: as2_company
   AS2-To: "AS2 Test"
   AS2-Version: 1.1
   Host: 10.240.1.2:58101
   Connection: close
   Content-Length: 3428

     [omitted binary encrypted data]



Moberg & Drummond           Standards Track                    [Page 44]

RFC 4130     AS2 for Business Data Interchange Using HTTP      July 2005


A.4.  Asynchronous MDN for Message A.3, Above

   POST / HTTP/1.1
   Host: 10.240.1.2:58201
   Connection: close, TE
   TE: trailers, deflate, gzip, compress
   User-Agent: RPT-HTTPClient/0.3-3I (Windows 2000)
   Date: Thu, 19 Dec 2002 15:03:38 GMT
   Message-ID: <AS2-20021219_030338@as2_company.dgi_th>
   AS2-Version: 1.1
   Mime-Version: 1.0
   Recipient-Address:
   http://10.240.1.2:58201/exchange/as2_company
   AS2-To: as2_company
   AS2-From: "AS2 Test"
   Subject: Your Requested MDN Response
   From: as2debug@example.com
   Accept-Encoding: deflate, gzip, x-gzip, compress, x-compress
   Content-Type: multipart/signed; micalg=sha1;
     protocol="application/pkcs7-signature";
     boundary="----=_Part_337_6452266.1040310218750"
   Content-Length: 3103

   ------=_Part_337_6452266.1040310218750
   Content-Type: multipart/report;
     report-type=disposition-notification;
     boundary="----=_Part_336_6069110.1040310218718"

   ------=_Part_336_6069110.1040310218718
   Content-Type: text/plain; charset=us-ascii
   Content-Transfer-Encoding: 7bit

   The message <x12.edi> sent to Recipient <AS2 Test> on Thu, 19 Dec
   2002 15:04:18 GMT with Subject <async MDN request> has been received.
   The EDI Interchange was successfully decrypted, and its integrity was
   verified.  In addition, the sender of the message, Sender
   <as2_company> at Location 
   http://10.240.1.2:58201/exchange/as2_company
   was authenticated as the originator of the message.  There is no
   guarantee, however, that the EDI interchange was syntactically
   correct, or that it was received by the EDI application/translator.











Moberg & Drummond           Standards Track                    [Page 45]

RFC 4130     AS2 for Business Data Interchange Using HTTP      July 2005


   ------=_Part_336_6069110.1040310218718
   Content-Type: message/disposition-notification
   Content-Transfer-Encoding: 7bit

   Reporting-UA: AS2@test:58101
   Original-Recipient: rfc822; "AS2 Test"
   Final-Recipient: rfc822; "AS2 Test"
   Original-Message-ID: <#as2_company#01#a4260as2_companyout#>
   Disposition: automatic-action/MDN-sent-automatically;
     processed
   Received-Content-MIC: Hes6my+vIxIYxmvsA+MNpEOTPAc=, sha1

   ------=_Part_336_6069110.1040310218718--

   ------=_Part_337_6452266.1040310218750
   Content-Type: application/pkcs7-signature; name=smime.p7s
   Content-Transfer-Encoding: base64
   Content-Disposition: attachment; filename=smime.p7s

   BhbWjEfbyXoTAS/H0zpnEqLqbaBh29y2v82b8bdeGw8pipBQWmf53hIcqHGM
   4ZBF3CHw5Wrf1JIE+8TwOzdbal30zeChw88WfRfD7c/j1fIA8sxsujvf2d9j
   UxCUga8BVdVB9kH0Geexytyt0KvWQXfaEEcgZGUAAAAAAAA=

   ------=_Part_337_6452266.1040310218750-

Notes:

Port numbers used in examples need to either refer to the intended service (e.g., 80 for HTTP) or use dynamic ports (49152-65535). The examples provided used examples in the assigned User ports range (8101, 8201) both as source and destination, and neither is appropriate for the example service described.

The simplest change was to add a "5" in front of the numbers, placing them in the dynamic range (e.g., 58101, 58201).

RFC 4133, "Entity MIB (Version 3)", August 2005

Note: This RFC has been obsoleted by RFC 6933

Source of RFC: entmib (ops)

Errata ID: 183
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-09-22
Verifier Name: Dan Romascanu
Date Verified: 2009-02-18

Section 2.12.1 says:

     For example, the entPhysicalUris object may be used to encode a URI
     containing a Common Language Equipment Identifier (CLEI) URN for
     the managed physical entity.  The URN name space for CLEIs is
     defined in [RFCYYYY], and the CLEI format is defined in
     [T1.213][T1.213a].  For example, an entPhysicalUris instance may
     have the value of

        URN:CLEI:D4CE18B7AA

     [RFC3986] and [RFCYYYY] identify this as a URI in the CLEI URN name
     space.  The specific CLEI code, D4CE18B7AA, is based on the example
     provided in [T1.213a].

It should say:

     For example, the entPhysicalUris object may be used to encode a URI
     containing a Common Language Equipment Identifier (CLEI) URN for
     the managed physical entity.  The URN name space for CLEIs is
     defined in [RFC4152], and the CLEI format is defined in
     [T1.213][T1.213a].  For example, an entPhysicalUris instance may
     have the value of

        URN:CLEI:D4CE18B7AA

     [RFC3986] and [RFC4152] identify this as a URI in the CLEI URN name
     space.  The specific CLEI code, D4CE18B7AA, is based on the example
     provided in [T1.213a].

Errata ID: 779
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-09-22
Verifier Name: Ron Bonica
Date Verified: 2009-09-03

Section 8.2 says:

 [RFCYYYY]     Tesink, K. and R. Fox, "A Uniform Resource Name (URN) 
               Namespace for the CLEI Code", RFC YYYY, August 2005.

It should say:

 [RFC4152]     Tesink, K. and R. Fox, "A Uniform Resource Name (URN)
               Namespace for the CLEI Code", RFC 4152, August 2005.

RFC 4134, "Examples of S/MIME Messages", July 2005

Source of RFC: smime (sec)

Errata ID: 1716
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Maxim Masiutin
Date Reported: 2009-03-15
Verifier Name: Sean Turner
Date Verified: 2010-07-20

Section 4.8 & 4.9 says:

In 4.8,

From: aliceDss@examples.com
Subject: Example 4.8
Message-Id: <020906002550300.249@examples.com>

In 4.9,

From: aliceDss@examples.com
Subject: Example 4.9
Message-Id: <021031164540300.304@examples.com>

It should say:

In 4.8,

From: AliceDSS@example.com
Subject: Example 4.8
Message-Id: <020906002550300.249@example.com>

In 4.9,

From: AliceDSS@example.com
Subject: Example 4.9
Message-Id: <021031164540300.304@example.com>

Notes:

"From" line of the RFC-822 message is aliceDss@examples.com, while the certificate’s SubjectAlternativeName contains Rfc822Name = AliceDSS@example.com

So the two emails are different in the host part:

aliceDss@examples.com
AliceDSS@example.com

The wrong email (aliceDss@examples.com) is given in both cleartext examples and encoded examples.

Additionally, the Message-Id should also be from example.com not from examples.com.

RFC 4141, "SMTP and MIME Extensions for Content Conversion", November 2005

Source of RFC: fax (app)

Errata ID: 805
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-11-22
Verifier Name: Dave Crocker

 

(1)

In Section 1.2, the last paragraph at the bottom of page 4 says:

     *  three MIME Content header fields (Content-Convert, Content-
        Previous and *  Content-Features) that specify appropriate
        content header fields and record conversions that have been
        performed.

It should say:

     *  three MIME Content header fields (Content-Convert, Content-
|       Previous and Content-Features) that specify appropriate
        content header fields and record conversions that have been
        performed.


(2)

In Section 3, the fourth paragraph on page 6 says:

   When CONPERM is used, conversions are performed by the first ESMTP
   host that can obtain both the originator's permission and information
   about the capabilities supported by the recipient.  If a relay or
   client is unable to transmit the message to a next-hop that supports
   CONPERM or to perform appropriate conversion, then it terminates
   message transmission and returns a [DSNSMTP, DSNFMT, SYSCOD] to the
   originator, with status code 5.6.3 (Conversion required but not
   supported).

It should say:

   When CONPERM is used, conversions are performed by the first ESMTP
   host that can obtain both the originator's permission and information
   about the capabilities supported by the recipient.  If a relay or
   client is unable to transmit the message to a next-hop that supports
   CONPERM or to perform appropriate conversion, then it terminates
|  message transmission and returns a Delivery Status Notification (DSN)
   [DSNSMTP, DSNFMT, SYSCOD] to the originator, with status code 5.6.3
   (Conversion required but not supported).

Rationale:  Probably, that triple of RFCs should not be sent  :-)
The proposed text change conforms to the current authoring style
guides for I-Ds / RFCs, spelling out the abbreviation 'MDN' at its
first occurrance in the text.


(3)

Similarly, the final NOTE in Section 3, on page 9, says:

         NOTE: An originator MAY validate any conversions that are made
         by requesting a positive [DSNSMTP].  ...

where it should better say:

         NOTE: An originator MAY validate any conversions that are made
|        by requesting a positive DSN [DSNSMTP].  ...


(4)

The second item of the first enumerated list in Section 3.3,
on page 12, contains a (visually hidden) word replication.
The text says:

      2) MUST return a DSN notification to the originator, with status
         code 5.6.3 (Conversion required but not supported).  [DSNSMTP,
         DSNFMT, SYSCOD]

It should say:

|     2) MUST return a DSN to the originator, with status code 5.6.3
         (Conversion required but not supported).  [DSNSMTP, DSNFMT,
         SYSCOD]

Rationale: The trailing "N" of "DSN" already stands for "notification".


(5)

To make the spelling of [E]SMTP keywords and verbs consistent within
the text, the headline of Section 4.2 (on page 13),

  4.2.  CONPERM Parameter to Mail-From

should better use uppercaes spelling as well, to read:

  4.2.  CONPERM Parameter to MAIL-FROM


(6)

The ABNF given in Section 7, on page 16, and Section 8, on page 17,
does not fully conform to the contemporary (RFC 2822) style.
The ABNF in Section 7 omits the explicit specification of white
space usage that presumably has been intended.
The ABNF in Section 8 inserts a paramount of CFWS.

NOTE:
- RFC 2822 has deprecated the use of white space between header
  field names and the subsequent ":" and, as far as I can see,
  comments have not been allowed at such places by RFC 822,
  and aren't by the "obsolete syntax" in RFC 2822.
- RFC 2822 has carefully made [C]FWS an intrinsic part of many
  low-level syntactic constructs to improve readability of the
  high-level ABNF productions. Thus, CFWS should not be inserted
  again where it is (logically) already present.

Furthermore, the spelling of ABNF production names should be
self-consistent within a certain field. RFC 2822 makes use of
lowercase production (rule) names for teh syntactic description
of the Internet Message Format; therefore it seems preferrable
to follow this style when defining IMF extensions.

In the light of these explanations (and detailed inspection of
RFC 2822), the ABNF productions in Section 7 :

      Convert =                "Content-convert" ":"
                               permitted

      Permitted =              "ANY" / "NONE" / permitted-list

should perhaps be re-written as :

      convert =           "Content-convert:" [CFWS] permitted

      permitted =         "ANY" / "NONE" / permitted-list

and the ABNF productions in Section 8 :

      previous =          "Content-Previous" [CFWS] ":"
                          [CFWS]
                          date by type

      date =              "Date " [CFWS] date-time [CFWS] ";"
                          [CFWS]

      by =                "By " [CFWS] domain [CFWS] ";"
                          [CFWS]

should perhaps be re-written as :

      previous =          "Content-Previous:" date by type

      date =              "Date " [CFWS] date-time ";" [CFWS]

      by =                "By " domain ";" [CFWS]

or even (disallowing comments after "Date " - like RFC 2822 does):

      previous =          "Content-Previous:" date by type

      date =              "Date " date-time ";" [CFWS]

      by =                "By " domain ";" [CFWS]


(7)

The examples in Section 9 contain improperly truncated references
to MIME Content-Types.
The following line that appears
  -  in Section 9.1 in the 3rd text line on page 18,
and
  -  in Section 9.2 in the 10th text line :

   C: <<RFC 2822 message with MIME Content-Type:TIFF-FX

should, in both cases, read:

   C: <<RFC 2822 message with MIME Content-Type: image/TIFF-FX


(8)

In Appendix C, the headline:

  Appendix C.  MIME Content-Type Registrations

should say:

  Appendix C.  MIME Header Field Registrations


(9)

Perhaps, in Appendix C, the IANA should have been directed to
add to the MIME Header Registration for "Content-Features:"
an additional reference to RFC 4141.
E.g., add on page 25, before the "Authors' Addresses":

  C.3.  Content-Features

    This memo substantially amends the specification of the
    MIME Header Field "Content-Features:" registered by [[FEAT].
    The IANA should include into the 'Specification document(s)'
    clause of that registration a pointer to RFC 4141.

It should say:

[see above]

Notes:

From Dave Crocker:

I congratulate you on such an excellent job of proof-reading. I certainly do
recommend that you post your note on the errata page.

All of your points are worth considering. Some entail simple errors and
some entail matters of taste.

I believe that the errors you cite do not change the substance of the
specification, although the question of white space syntax could formally
involve a meaningful technical error. (Normally it would be clear that it
is significant; given the history of RFC733/RFC722/RFC2822 and the slow
adoption of 2822, I'm not too worried that the error in our document will
hurt real-world interoperability.

from pending

Errata ID: 4762
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Andris Reinman
Date Reported: 2016-08-04
Verifier Name: Alexey Melnikov
Date Verified: 2016-08-11

Section 9.1 says:

S: 250-<June@some.example.com> recipient ok

It should say:

S: 250 <June@some.example.com> recipient ok

Notes:

The example in section 9.1 incorrectly lists a hyphen between the status code (250) and message text (<June...) as if there would be more data coming from the server regarding the "RCPT TO:<June..." command but there is not.

RFC 4143, "Facsimile Using Internet Mail (IFAX) Service of ENUM", November 2005

Note: This RFC has been updated by RFC 6118

Source of RFC: fax (app)

Errata ID: 852
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Matthias Wimmer
Date Reported: 2007-01-31
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-21

Section 4 says:

       $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa
         IN NAPTR 10 10 "u" "E2U+ifax:mailto"
                                "!^.*$!mailto:toyo@example.com!"

It should say:

       $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa
         IN NAPTR 10 10 "u" "E2U+ifax:mailto"
                                "!^.*$!mailto:toyo@example.com!" .

Notes:

This NAPTR record is missing the REPLACEMENT field (see RFC 3403).
(Note the additional point at the end of the example.)

RFC 4147, "Proposed Changes to the Format of the IANA IPv6 Registry", August 2005

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 179
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mark Doll
Date Reported: 2005-08-29

Section 2 says:

     F800::/6              Reserved by IETF        RFC3513
     FA00::/7              Reserved by IETF        RFC3513
     FC00::/7              Reserved by IETF        RFC3513

It should say:

     F800::/6              Reserved by IETF        RFC3513
     FC00::/7              Reserved by IETF        RFC3513

Notes:

Section 2 states "There are no overlapping address blocks in the first
column", but the address blocks F800::/6 and FA00::/7
overlap. Therefore, the address block FA00::/7 should be removed from the table.

RFC 4151, "The 'tag' URI Scheme", October 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 1485
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tony Finch
Date Reported: 2008-08-08
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-11

Section 2.1 says:

      emailAddress = 1*(alphaNum /"-"/"."/"_") "@" DNSname

It should say:

      emailAddress = addr-spec
                     ; addr-spec from RFC 2822/5322

Notes:

The syntax as specified does not allow characters such as + which are commonly found in email addresses.

Alexey: this is not quite right either, as addr-spec allows various characters that need %-encoding in URIs.

RFC 4171, "Internet Storage Name Service (iSNS)", September 2005

Source of RFC: ips (tsv)

Errata ID: 175
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hannes Reinecke
Date Reported: 2006-06-23
Verifier Name: Lars Eggert
Date Verified: 2008-11-28

Section 4.1.1 says:

   STORAGE NODE       iSCSI Name                   *      *        *
                      iSCSI Node Type                     *        *
                      Alias                               *
                      iSCSI SCN Bitmap                    *
                      iSCSI Node Index                    *
                      WWNN Token
                      iSCSI AuthMethod
                      iSCSI Node Certificate
                      ^^^^^^^^^^^^^^^^^^^^^^

It should say:

   STORAGE NODE       iSCSI Name                   *      *        *
                      iSCSI Node Type                     *        *
                      Alias                               *
                      iSCSI SCN Bitmap                    *
                      iSCSI Node Index                    *
                      WWNN Token
                      iSCSI AuthMethod

Notes:

Section 4.1.1 refers to 'iSCSI Node Certificate', which is never defined in the document.

From David Black:
The comment appears to be correct, and the actual Errata should
be to remove the following line from Section 4.1.1 of RFC
4171 (iSNS) because it is not supported by the iSNS protocol:

iSCSI Node Certificate

RFC 4175, "RTP Payload Format for Uncompressed Video", September 2005

Note: This RFC has been updated by RFC 4421

Source of RFC: avt (rai)

Errata ID: 4581
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Fletcher
Date Reported: 2016-01-06
Verifier Name: Ben Campbell
Date Verified: 2016-01-06

Section 6.1 says:

Security considerations: See section 9 of RFC 4175.

It should say:

Security considerations: See section 8 of RFC 4175.

Notes:

Wrong section number for Security considerations

RFC 4180, "Common Format and MIME Type for Comma-Separated Values (CSV) Files", October 2005

Note: This RFC has been updated by RFC 7111

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 5593
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Greg Skinner
Date Reported: 2019-01-06
Verifier Name: Orie Steele
Date Verified: 2024-03-29

Section 2 says:

There maybe an optional header line appearing as the first line
of the file with the same format as normal record lines.

It should say:

There may be an optional header line appearing as the first line
of the file with the same format as normal record lines.

Notes:

fixed spelling error

Errata ID: 5714
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Damon Koach
Date Reported: 2019-05-01
Verifier Name: Barry Leiba
Date Verified: 2019-05-01

Section 5, 6 says:

Section 5: 
  "aaa","bbb","ccc" CRLF
Section 6: 
  "aaa","b CRLF
  bb","ccc" CRLF
  zzz,yyy,xxx

It should say:

Section 5:
  "aaa","bbb","ccc"CRLF
Section 6:
  "aaa","b CRLF
  bb","ccc"CRLF
  zzz,yyy,xxx

Notes:

As implied in the ABNF grammar, escaped (quoted) fields may not be followed by a space.
The corrected text removes those spaces from the examples, making them syntactically correct.

RFC 4181, "Guidelines for Authors and Reviewers of MIB Documents", September 2005

Note: This RFC has been updated by RFC 4841

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: ops

Errata ID: 173
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: C. M. Heard
Date Reported: 2005-11-01

Section 4.6.1.1 says:

 - For integer-valued enumerations:

      - INTEGER is REQUIRED; - Integer32, Unsigned32, and Gauge32 MUST
      NOT be used.

It should say:

- For integer-valued enumerations:

      - INTEGER is REQUIRED;
      - Integer32, Unsigned32, and Gauge32 MUST NOT be used.

Errata ID: 793
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: C. M. Heard
Date Reported: 2005-11-01
Verifier Name: C. M. Heard
Date Verified: 2005-11-01

Section 4.9 says:

" ... .  Two point are worth reiterating:"

It should say:

 " ... .  Two points are worth reiterating:"

Notes:

Originally from Alfred Hoenes

from pending

Errata ID: 794
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: C. M. Heard
Date Reported: 2005-11-01
Verifier Name: C. M. Heard
Date Verified: 2005-11-01

Appendix A

"... -- if the draft does not contains a verbatim copy ..."

It should say:

"... -- if the draft does not contain a verbatim copy ..."

Notes:

Originally from Alfred Hoenes

from pending

Errata ID: 857
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-10-23
Verifier Name: C. M. Heard
Date Verified: 2005-10-23

Section 4.9 says:

Two point are worth reiterating:

It should say:

Two points are worth reiterating:

Notes:

from pending

Errata ID: 858
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-10-23
Verifier Name: C. M. Heard
Date Verified: 2005-10-23

Appendix A says:

8.) IPR Notice -- if the draft does not contains a verbatim copy of

It should say:

8.) IPR Notice -- if the draft does not contain a verbatim copy of

Notes:

from pending

RFC 4182, "Removing a Restriction on the use of MPLS Explicit NULL", September 2005

Note: This RFC has been updated by RFC 5462, RFC 7274

Source of RFC: mpls (rtg)

Errata ID: 172
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-09-12
Verifier Name: Adrian Farrel
Date Verified: 2010-08-21

Section 2 says:

RFC 3032 states on page 4:

It should say:

RFC 3032 states on page 5:

Notes:

Wrong page number in reference.

RFC 4186, "Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)", January 2006

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: ops

Errata ID: 171
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-26
Verifier Name: Henry Haverinen
Date Verified: 2006-12-01

Section 8.1 says:

   Length

         Indicates the length of this attribute in multiples of four
         bytes.  The maximum length of an attribute is 1024 bytes.  The
         length includes the Attribute Type and Length bytes.

It should say:

   Length

         Indicates the length of this attribute in multiples of four
         bytes.  The maximum length of an attribute is 1020 bytes.  The
         length includes the Attribute Type and Length bytes.

Notes:

As there is no offset defined, the maximum encoded Length value
of 255 corresponds to a total of 4*255 = 1020 octets.

Note:
Other protocols incorporate an offset of -1 in similar cases, e.g.,
when a TLV Length field comprises the length of the 'T' and 'L',
also removing the artificially designed-in error case (Length=0),
that otherwise must be checked for by all implementations!
Some people speak of bad protocol design when encountering
Length fields that do not indicate the true length of an object
value proper, which might be zero.

from pending

Errata ID: 956
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-26
Verifier Name: Henry Haverinen
Date Verified: 2006-12-01

Section 10.14 says:

   The value field of the AT_MAC attribute contains two reserved bytes
   followed by a keyed message authentication code (MAC).  The MAC is
|  calculated over the whole EAP packet and concatenated with optional
   message-specific data, with the exception that the value field of the
   MAC attribute is set to zero when calculating the MAC.

It should say:

   The value field of the AT_MAC attribute contains two reserved bytes
   followed by a keyed message authentication code (MAC).  The MAC is
|  calculated over the whole EAP packet, concatenated with optional
   message-specific data, with the exception that the value field of the
   MAC attribute is set to zero when calculating the MAC.

Notes:

"The MAC is calculated ... and concatenated ..."
could easily be misunderstood.
From the context it can be concluded that the potential ambiguity
should be resolved and clarified by omitting the word 'and',
and replacing it by a comma.

from pending

Errata ID: 957
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-26
Verifier Name: Henry Haverinen
Date Verified: 2006-12-01

 

(1) [[posted separately.]]
(2) [[posted separately.]]

(3)  [missing article]

Within Section 1, the 2nd paragraph on page 5 says:

   EAP-SIM specifies optional support for protecting the privacy of
   subscriber identity using the same concept as the GSM, which uses
   pseudonyms/temporary identifiers.  [...]

It should say:

|  EAP-SIM specifies optional support for protecting the privacy of the
   subscriber identity using the same concept as the GSM, which uses
   pseudonyms/temporary identifiers.  [...]


(4)  [missing article]

Section 2, near the bottom of page 6, says:

   Fast Re-authentication Username

         The username portion of fast re-authentication identity,
         i.e., not including any realm portions.

It should say:

   Fast Re-authentication Username

|        The username portion of the fast re-authentication identity,
         i.e., not including any realm portions.


(5)  [missing article]

The first paragraph of Section 4.2.3, on page 19, says:

   If EAP-SIM peer is started upon receiving an EAP-Request/Identity
   message, then the peer MAY use an EAP-SIM identity in the EAP-
   Response/Identity packet.  [...]

It should say:

|  If the EAP-SIM peer is started upon receiving an EAP-Request/Identity
   message, then the peer MAY use an EAP-SIM identity in the EAP-
   Response/Identity packet.  [...]


(6)  [missing article]

The Section title (on page 19 and in the ToC),
                                            v
4.2.4.  Server Operation in the Beginning of EAP-SIM Exchange

should better say:
                                            vvvv
4.2.4.  Server Operation in the Beginning of an EAP-SIM Exchange


(7)  [misleading continuation indicator]

In Section 4.3.6, Figure 7 (on page 29) contains for lines that
might erroneously be misunderstod to indicate the omission of
some protocol steps (which is not the case).
I suspect that this is an artifact from a draft version where
Figure 7 was split over two pages; after joining the parts,
these continuation indicators have become ambiguous, and hence
should be deleted.

On mid-page 29, the lines:

       |     EAP-Request/SIM/Start                             |
       |     (AT_FULLAUTH_ID_REQ, AT_VERSION_LIST)             |
       |<------------------------------------------------------|
       |                                                       |
       :                                                       :
       :                                                       :
       :                                                       :
       :                                                       :
       |EAP-Response/SIM/Start                                 |
       |(AT_IDENTITY with a pseudonym identity, AT_NONCE_MT,   |
       | AT_SELECTED_VERSION)                                  |
       |------------------------------------------------------>|

should say:

       |     EAP-Request/SIM/Start                             |
       |     (AT_FULLAUTH_ID_REQ, AT_VERSION_LIST)             |
       |<------------------------------------------------------|
       |                                                       |
       |EAP-Response/SIM/Start                                 |
       |(AT_IDENTITY with a pseudonym identity, AT_NONCE_MT,   |
       | AT_SELECTED_VERSION)                                  |
       |------------------------------------------------------>|


(8)  [grammar / articles]

Within Section 5.3, the text on top of page 32,

   If the EAP server supports fast re-authentication, it MAY include the
|  skippable AT_NEXT_REAUTH_ID attribute in the encrypted data of
   EAP-Request/SIM/Challenge message (Section 9.3).  This attribute
   contains a new fast re-authentication identity for the next fast
   re-authentication.  The attribute also works as a capability flag
|  that, indicating that the server supports fast re-authentication, and
   that the server wants to continue using fast re-authentication within
   the current context.  The peer MAY ignore this attribute, in which
   case it MUST use full authentication next time.  If the peer wants to
   use re-authentication, it uses this fast re-authentication identity
|  on next authentication.  Even if the peer has a fast
   re-authentication identity, [...]

should say:

   If the EAP server supports fast re-authentication, it MAY include the
|  skippable AT_NEXT_REAUTH_ID attribute in the encrypted data of the
   EAP-Request/SIM/Challenge message (Section 9.3).  This attribute
   contains a new fast re-authentication identity for the next fast
   re-authentication.  The attribute also works as a capability flag,
|  indicating that the server supports fast re-authentication, and
   that the server wants to continue using fast re-authentication within
   the current context.  The peer MAY ignore this attribute, in which
   case it MUST use full authentication next time.  If the peer wants to
   use re-authentication, it uses this fast re-authentication identity
|  on the next authentication.  Even if the peer has a fast
   re-authentication identity, [...]


(9)  [misleading continuation indicator, again]

Repetition of the issue described in item (7) above:

In Section 5.4, in Figure 8 (on page 35), the 4 lines:

       :                                                       :
       :                                                       :
       :                                                       :
       :                                                       :

should be deleted, because these might erroneously be misunderstood
as indicating the omission of some protocol steps.


(10)  [missing article]

In Section 7, the paragraph at the bottom of page 43 says:

   The notation n*Kc in the formula above denotes the n Kc values
   concatenated.  The Kc keys are used in the same order as the RAND
|  challenges in AT_RAND attribute.  NONCE_MT denotes the NONCE_MT value
   (not the AT_NONCE_MT attribute, but only the nonce value).  The
   Version List includes the 2-byte-supported version numbers from
   AT_VERSION_LIST, in the same order as in the attribute.  [...]

It should say:

   The notation n*Kc in the formula above denotes the n Kc values
   concatenated.  The Kc keys are used in the same order as the RAND
|  challenges in the AT_RAND attribute.  NONCE_MT denotes the NONCE_MT
   value (not the AT_NONCE_MT attribute, but only the nonce value).
   The Version List includes the 2-byte-supported version numbers from
   AT_VERSION_LIST, in the same order as in the attribute.  [...]

Notes:

from pending

RFC 4187, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", January 2006

Note: This RFC has been updated by RFC 5448, RFC 9048

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: int

Errata ID: 959
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-26
Verifier Name: Henry Haverinen
Date Verified: 2006-12-01

 

(1)  [misleading wording]

In Section 3, the RFC text at the bottom of page 13 says:

            [...].  In certain circumstances, shown in Figure 4, it is
   possible for the sequence numbers to get out of sequence.

This sentence is misleading. Figure 4 only shows the *discovery*
of the de-synchronization; it does not show 'certain circumstances'
that might lead to this problem.


(2)  [typo]

On page 18, the second paragraph of Section 4.1.1.7 says:

                                                         [...].  It is
   recommended that the EAP servers implement some centralized mechanism
   to allow all EAP servers of the home operator to map pseudonyms
|  generated by other severs to the permanent identity.  [...]
                      ^^^^^^
It should say:
                                                         [...].  It is
   recommended that the EAP servers implement some centralized mechanism
   to allow all EAP servers of the home operator to map pseudonyms
|  generated by other servers to the permanent identity.  [...]
                        ^

(3)  [missing article]

The last paragraph of Section 4.1.1.8, on page 20, says:

   If the peer does not receive a new pseudonym username in the
   EAP-Request/AKA-Challenge message, the peer MAY use an old pseudonym
   username instead of the permanent username on next full
   authentication.  [...]

It should say:

   If the peer does not receive a new pseudonym username in the
   EAP-Request/AKA-Challenge message, the peer MAY use an old pseudonym
|  username instead of the permanent username on the next full
   authentication.  [...]
                                                ^^^^^

(4)  [grammar / misleading punctuation]

The last paragraph of Section 4.1.2.1, on page 22, says:

   Please note that only the EAP-AKA peer and the EAP-AKA server process
|  the AT_IDENTITY attribute and entities that pass through; EAP packets
   do not process this attribute.  [...]
                            ^                              ^^
It should say:

   Please note that only the EAP-AKA peer and the EAP-AKA server process
|  the AT_IDENTITY attribute, and entities that pass through EAP packets
   do not process this attribute.  [...]
                            ^^                              ^


(5)  [missing article]

The first paragraph of Section 4.1.3, on top of page 23, says:

|  If EAP-AKA peer is started upon receiving an EAP-Request/Identity
   message, then the peer MAY use an EAP-AKA identity in the EAP-
   Response/Identity packet.  [...]

It should say:

|  If an EAP-AKA peer is started upon receiving an EAP-Request/Identity
   message, then the peer MAY use an EAP-AKA identity in the EAP-
   Response/Identity packet.  [...]


(6)  [grammar]

The second paragraph of Section 4.1.4, on mid-page 23, says:

   If the server chooses to not ignore the contents of
|  EAP-Response/Identity, then the server may already receive an EAP-AKA
|  identity in this packet.  However, if the EAP server has not received
   any EAP-AKA peer identity (permanent identity, pseudonym identity, or
   fast re-authentication identity) from the peer when sending the first
   EAP-AKA request, or if the EAP server has received an
   EAP-Response/Identity packet but the contents do not appear to be a
   valid permanent identity, pseudonym identity, or a re-authentication
   identity, then the server MUST request an identity from the peer
   using one of the methods below.

It should say:

   If the server chooses to not ignore the contents of
|  EAP-Response/Identity, then the server may already have received an
   EAP-AKA identity in this packet.  However, if the EAP server has not
   received any EAP-AKA peer identity (permanent identity, pseudonym
   identity, or fast re-authentication identity) from the peer when
   sending the first EAP-AKA request, or if the EAP server has received
   an EAP-Response/Identity packet but the contents do not appear to be
   a valid permanent identity, pseudonym identity, or a
   re-authentication identity, then the server MUST request an identity
   from the peer using one of the methods below.


(7)  [misleading wording]

On page 25, the first paragraph of Section 4.1.6 says:

   The section above specifies two possible ways the peer can operate
   upon receipt of AT_PERMANENT_ID_REQ because a received
   AT_PERMANENT_ID_REQ does not necessarily originate from the valid
|  network.  However, an active attacker may transmit an
   EAP-Request/AKA-Identity packet with an AT_PERMANENT_ID_REQ attribute
   to the peer, in an effort to find out the true identity of the user.
   If the peer does not want to reveal its permanent identity, then the
   peer sends the EAP-Response/AKA-Client-Error packet with the error
   code "unable to process packet", and the authentication exchange
   terminates.

It should say:

   The section above specifies two possible ways the peer can operate
   upon receipt of AT_PERMANENT_ID_REQ because a received
   AT_PERMANENT_ID_REQ does not necessarily originate from the valid
|  network.  In fact, an active attacker may transmit an
   EAP-Request/AKA-Identity packet with an AT_PERMANENT_ID_REQ attribute
   to the peer, in an effort to find out the true identity of the user.
   If the peer does not want to reveal its permanent identity, then the
   peer sends the EAP-Response/AKA-Client-Error packet with the error
   code "unable to process packet", and the authentication exchange
   terminates.


(8)  [[posted separately.]]

(9)  [missing article]

The 4th paragraph of Section 5.1, near the bottom of page 32, says:

                                  [...].  For example, on the second
|  fast re-authentication, counter value is two or greater, etc.  The
   AT_COUNTER attribute is encrypted.

It should say:

                                  [...].  For example, on the second
|  fast re-authentication, the counter value is two or greater, etc.
   The AT_COUNTER attribute is encrypted.


(10)  [missing article]

The first paragraph of Section 5.3, near the bottom of page 33, says:

                                                     [...].  If the EAP
   server supports fast re-authentication, it MAY include the skippable
|  AT_NEXT_REAUTH_ID attribute in the encrypted data of EAP- Request/-
   AKA-Challenge message.  This attribute contains a new
   re-authentication identity for the next fast re-authentication.  [..]

It should say:
                                                     [...].  If the EAP
   server supports fast re-authentication, it MAY include the skippable
|  AT_NEXT_REAUTH_ID attribute in the encrypted data of the EAP-
   Request/-AKA-Challenge message.  This attribute contains a new
   re-authentication identity for the next fast re-authentication.  [..]

(The spurious blank after "EAP-" disappears due to the new line break.)


(11)  IMPORTANT -- [misleading continuation indicator, again]

Repetition of the issue described in item (8) above:

In Section 5.4, in Figure 10 (on page 36), the 6 lines:

       :                                                       :
       :                                                       :


       :                                                       :
       :                                                       :

should be deleted, because these might erroneously be misunderstood
as indicating the omission of some protocol steps.


(12)  [missing article]

The last paragraph of Section 5.5, on page 38, says:

   It should be noted that in this case, peer identity is only
   transmitted in the AT_IDENTITY attribute at the beginning of the
   whole EAP exchange.  The fast re-authentication identity used in this
   AT_IDENTITY attribute will be used in key derivation (see Section 7).

It should say:

|  It should be noted that in this case, the peer identity is only
   transmitted in the AT_IDENTITY attribute at the beginning of the
   whole EAP exchange.  The fast re-authentication identity used in this
   AT_IDENTITY attribute will be used in key derivation (see Section 7).


(13)  [missing article]

Within Section 6.1, the 3rd paragraph on page 39 says:

                                         [...].  A re-authentication
   round is considered successful only if the peer has successfully
   verified AT_MAC and AT_COUNTER attributes, and does not include the
   AT_COUNTER_TOO_SMALL attribute in EAP-Response/AKA-Reauthentication.

It should say:
                                         [...].  A re-authentication
   round is considered successful only if the peer has successfully
|  verified the AT_MAC and AT_COUNTER attributes, and does not include
   the AT_COUNTER_TOO_SMALL attribute in EAP-Response/AKA-
   Reauthentication.


(14)  [grammar / articles]

Within Section 8.1, the text at the bottom page 46,

   Attributes numbered within the range 0 through 127 are called
   non-skippable attributes.  When an EAP-AKA peer encounters a
   non-skippable attribute type that the peer does not recognize, the
|  peer MUST send the EAP-Response/AKA-Client-Error packet, and the
   authentication exchange terminates.  If an EAP-AKA server encounters
   a non-skippable attribute that the server does not recognize, then
|  the server sends EAP-Request/AKA-Notification packet with an
   [<page break>]
   [...]

should say:

   Attributes numbered within the range 0 through 127 are called
   non-skippable attributes.  When an EAP-AKA peer encounters a
   non-skippable attribute type that the peer does not recognize, the
|  peer MUST send an EAP-Response/AKA-Client-Error packet, and the
   authentication exchange terminates.  If an EAP-AKA server encounters
   a non-skippable attribute that the server does not recognize, then
|  the server sends an EAP-Request/AKA-Notification packet with an
   [<page break>]
   [...]

(15)  [missing article]

Section 9, on page 48 says:

|                           [...].  Message format is specified in
   Section 8.1.

It should say:

|                           [...].  The message format is specified in
   Section 8.1.


(16)  IMPORTANT -- misleading specification !

On page 63, the 2nd paragraph of Section 10.15 says:

   The value field of the AT_MAC attribute contains two reserved bytes
   followed by a keyed message authentication code (MAC).  The MAC is
|  calculated over the whole EAP packet and concatenated with optional
   message-specific data, with the exception that the value field of the
   MAC attribute is set to zero when calculating the MAC.  [...]

It should say:

   The value field of the AT_MAC attribute contains two reserved bytes
   followed by a keyed message authentication code (MAC).  The MAC is
|  calculated over the whole EAP packet, concatenated with optional
   message-specific data, with the exception that the value field of the
   MAC attribute is set to zero when calculating the MAC.  [...]

Rationale:
  "The MAC is calculated ... and concatenated ..."
could easily be misunderstood.  From the context it can be
concluded that the potential ambiguity should be resolved and
clarified by omitting the word 'and', and replacing it by a comma.


(17)  [improper, extraneous wording]

In Section 10.15, the second-to-last paragraph on page 63 says:

|  The MAC algorithm is HMAC-SHA1-128 [RFC2104] keyed hash value.  (The
   HMAC-SHA1-128 value is obtained from the 20-byte HMAC-SHA1 value by
   truncating the output to 16 bytes.  Hence, the length of the MAC is
   16 bytes.)  The derivation of the authentication key (K_aut) used in
   the calculation of the MAC is specified in Section 7.

It should say:

|  The MAC algorithm is HMAC-SHA1-128 [RFC2104].  (The HMAC-SHA1-128
   value is obtained from the 20-byte HMAC-SHA1 value by truncating the
   output to 16 bytes.  Hence, the length of the MAC is 16 bytes.)  The
   derivation of the authentication key (K_aut) used in the calculation
   of the MAC is specified in Section 7.

Rationale: Beyond grammar, don't mess up 'algorithm' and 'value' !


(17)  [missing article]

The second text paragraph of Section 10.18, on page 65, says:

   The value field of the AT_NONCE_S attribute contains two reserved
   bytes followed by a random number (16 bytes) that is freshly
   generated by the server for this EAP-AKA fast re-authentication.  The
   random number is used as challenge for the peer and also as a seed
   value for the new keying material.  [...]

It should say:

   The value field of the AT_NONCE_S attribute contains two reserved
   bytes followed by a random number (16 bytes) that is freshly
   generated by the server for this EAP-AKA fast re-authentication.  The
|  random number is used as a challenge for the peer and also as a seed
   value for the new keying material.  [...]


(18)  [misleading wording]

Within Section 11, the second text paragraph on page 67 says:

                        [...].  The following attribute types are
   specified in this document in [EAP-SIM]:
                             ^
It should say:

                        [...].  The following attribute types are
|  specified in this document and in [EAP-SIM]:
                             ^^^^^

(19) [[posted separately.]]

Notes:

Whereas most items just should be noted for consideration when
preparing future derived work, at least items (8), (11), and (16)
seem to deserve an Errata Note.

from pending

Errata ID: 966
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-26
Verifier Name: Henry Haverinen
Date Verified: 2006-12-01

Section 12.7 says:

   As described in Section 8, EAP-AKA allows the protocol to be extended
   by defining new attribute types.  When defining such attributes, it
   should be noted that any extra attributes included in
   EAP-Request/AKA-Identity or EAP-Response/AKA-Identity packets are not
   included in the MACs later on, and thus some other precautions must
   be taken to avoid modifications to them.

It should say:

   As described in Section 8, EAP-AKA allows the protocol to be extended
   by defining new attribute types.  When defining such attributes, it
   should be noted that the AT_CHECKCODE attribute (see Section 10.13)
   can be used to achieve the protection of extra attributes included in
   EAP-Request/AKA-Identity or EAP-Response/AKA-Identity packets.

Notes:

This text is too pessimistic. The reader's attention should be
directed to Section 10.13 of the RFC. The (late) introduction of
the AT_CHECKCODE concept, as explained there, has taken care of
this issue; implementations should make use of this attribute.

from pending

Errata ID: 3967
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Huanggj
Date Reported: 2014-04-18
Verifier Name: Brian Haberman
Date Verified: 2014-06-05

Section 3 says:

After obtaining the subscriber identity, the EAP server obtains an
   authentication vector (RAND, AUTN, RES, CK, IK) for use in
   authenticating the subscriber.  From the vector, the EAP server
   derives the keying material, as specified in Section 6.4.

It should say:

After obtaining the subscriber identity, the EAP server obtains an
   authentication vector (RAND, AUTN, RES, CK, IK) for use in
   authenticating the subscriber.  From the vector, the EAP server
   derives the keying material, as specified in Section 7.

RFC 4194, "The S Hexdump Format", October 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 4940
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2017-02-19
Verifier Name: Orie Steele
Date Verified: 2024-03-29

Section 12 says:

   [2]  Eastlake, 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
        (SHA1)", BCP 14, RFC 3174, September 2001.

It should say:

   [2]  Eastlake, 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
        (SHA1)", RFC 3174, September 2001.

Notes:

RFC 3174 is not part of BCP 14.

Errata ID: 4941
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2017-02-19
Verifier Name: Orie Steele
Date Verified: 2024-03-29

Section 12 says:

   [4]  Makoto, M., Simon, S., and D. Dan, "(Extensible Markup Language)
        XML Media Types", RFC 3023, January 2001.

It should say:

   [4]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
        RFC 3023, January 2001.

Notes:

See https://www.rfc-editor.org/refs/ref3023.txt:

"Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, DOI 10.17487/RFC3023, January 2001, <http://www.rfc-editor.org/info/rfc3023>."

RFC 4207, "Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages", October 2005

Note: This RFC has been updated by RFC 6898

Source of RFC: ccamp (rtg)

Errata ID: 167
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-12-20
Verifier Name: Adrian Farrel
Date Verified: 2010-01-02

Section 4.1.1 says:

           [...]  The format of the TraceMonitor message is as
  follows:

   <TraceMonitor Message> ::= <Common Header> <MESSAGE_ID>
                              <LOCAL_INTERFACE_ID> <TRACE>

It should say:

<< THIS CHANGE IS REJECTED >>
<< See the Notes field for the revised editorial change. >>

           [...]  The format of the TraceMonitor message is as
  follows:

   <TraceMonitor Message> ::= <Common Header> <MESSAGE_ID>
                              <LOCAL_INTERFACE_ID>
                              <TRACE> ...

Notes:

<Original note>
> RFC 4207 defines the syntax of the TraceMonitor message in Section
> 4.1.1, on page 6.
> Similarly, the TraceMonitorAck and TraceMonitorNack Messages are
> specified in Sections 4.1.2 and 4.1.3, respectively, on page 8.
>
> While the former specifies a single <TRACE> object to appear
> in a TraceMonitor message, the latter specs uses wording like
> "all of the TRACE Objects in a TraceMonitor message" or
> "TRACE object value(s)".
>
> IMHO, it makes much sense to indeed allow multiple TRACE Objects
> (with different trace types, but all related to a single Interface)
> in a single TraceMonitor Message.
</Original note>

CCAMP consensus on this issue is that the BNF is correct. That is, only a single instance of the <TRACE> object is permitted on the <TraceMonitor Message> or any of the other messages.

The text in the various sections is factually correct when it says things like "all the Trace Objects..." However, this is misleading and should be changed to be singlular in all cases.

RFC 4210, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", September 2005

Note: This RFC has been updated by RFC 6712, RFC 9480, RFC 9481

Source of RFC: pkix (sec)

Errata ID: 3949
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tom Biskupic
Date Reported: 2014-04-02
Verifier Name: Kathleen Moriarty
Date Verified: 2015-03-31

Section 5.3.4 says:

CertRepMessage ::= SEQUENCE {
         caPubs          [1] SEQUENCE SIZE (1..MAX) OF Certificate
                             OPTIONAL,
         response            SEQUENCE OF CertResponse
     }

It should say:

CertRepMessage ::= SEQUENCE {
         caPubs       [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate
                          OPTIONAL,
         response         SEQUENCE OF CertResponse
     }

Notes:

The definition in the text is different to the one in the ASN.1 module contained in Appendix F. The correct text is assumed to be the one from Appendix F

CMPCertificate is a superset of Certificate which has one element. The new structure would allow for a new certificate type to be included. Not sure that it would ever happen.

Errata ID: 4078
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lijun Liao
Date Reported: 2014-08-11
Verifier Name: Kathleen Moriarty
Date Verified: 2015-03-31

Section 5.3.4 says:

     CertOrEncCert ::= CHOICE {
         certificate     [0] Certificate,
         encryptedCert   [1] EncryptedValue
     }

It should say:

     CertOrEncCert ::= CHOICE {
         certificate     [0] CMPCertificate,
         encryptedCert   [1] EncryptedValue
     }

Notes:

The definition of CertOrEncCert in Section 5.3.4 and Appendix F of CertOrEncCert differs.

This is a change that makes no difference on the wire. This is the same issue as errata 3949.

Errata ID: 5201
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Simon Edänge
Date Reported: 2017-12-12
Verifier Name: Roman Danyliw
Date Verified: 2022-02-04

Section Appendix D.4 says:

   Initialization Response -- ip

   Field                Value

   sender               CA name
     -- the name of the CA who produced the message
   messageTime          present
     -- time at which CA produced message
   protectionAlg        MS_MAC_ALG
     -- only MAC protection is allowed for this response

It should say:

   Initialization Response -- ip

   Field                Value

   sender               CA name
     -- the name of the CA who produced the message
   messageTime          present
     -- time at which CA produced message
   protectionAlg        MSG_MAC_ALG
     -- only MAC protection is allowed for this response

Notes:

There is a typo in Appendix D.4 -- "MS_MAC_ALG" should be "MSG_MAC_ALG"

Errata ID: 7549
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rufus Buschart
Date Reported: 2023-06-23
Verifier Name: Roman Danyliw
Date Verified: 2023-06-23

Section 3.1.2. point 11 says:

correct RA of CA public key

It should say:

correct RA or CA public key

Notes:

From the context it is obvious that there is a typo in the original text. This claim is supported by the fact that the "r" and the "f" key are next to each other on the keyboard.

RFC 4211, "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", September 2005

Note: This RFC has been updated by RFC 9045

Source of RFC: pkix (sec)

Errata ID: 4797
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lijun Liao
Date Reported: 2016-09-08
Verifier Name: Stephen Farrell
Date Verified: 2016-09-13

Section 4.1 says:

   3.  The certificate subject places its name in the Certificate
       Template structure along with the public key.  In this case the
       poposkInput field is omitted from the POPOSigningKey structure.
       The signature field is computed over the DER-encoded certificate
       template structure.

It should say:

   3.  The certificate subject places its name in the Certificate
       Template structure along with the public key.  In this case the
       poposkInput field is omitted from the POPOSigningKey structure.
       The signature field is computed over the DER-encoded value of
       certReq

Notes:

The original text conflicts with the following text block (just several lines later).

" The fields of POPOSigningKey have the following meaning:
...

signature contains the POP value produce. If poposkInput is
present, the signature is computed over the DER-encoded value of
poposkInput. If poposkInput is absent, the signature is computed
over the DER-encoded value of certReq."

RFC 4217, "Securing FTP with TLS", October 2005

Note: This RFC has been updated by RFC 8996

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 800
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-11-09
Verifier Name: RFC Editor
Date Verified: 2007-11-01

Section 12.5 says:

"...  This contrasts the with situation when ..."

It should say:

"...  This contrasts with the situation when ..."

Notes:

from pending

Errata ID: 803
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-11-09
Verifier Name: RFC Editor
Date Verified: 2007-11-01

Section 12.5 says:

 "o  The various people who have help author this document ..."

It should say:

"o  The various people who have helped [to] author this document ..."

or:

"o  The various people who have helped the author of this document ..."

Notes:

from pending

RFC 4226, "HOTP: An HMAC-Based One-Time Password Algorithm", December 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 4994
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mathias Tausig
Date Reported: 2017-04-14
Verifier Name: Paul Wouters
Date Verified: 2023-08-03

Section 7.2 says:

The HOTP client (hardware or software token) increments its counter
and then calculates the next HOTP value HOTP client.  If the value
received by the authentication server matches the value calculated by
the client, then the HOTP value is validated.  In this case, the
server increments the counter value by one.

If the value received by the server does not match the value
calculated by the client, the server initiate the resynch protocol
(look-ahead window) before it requests another pass.

It should say:

The HOTP client (hardware or software token) increments its counter
and then calculates the next HOTP value HOTP client.  If the value
received by the authentication server matches the value calculated by
the server, then the HOTP value is validated.  In this case, the
server increments the counter value by one.

If the value received by the server does not match the value
calculated by the server, the server initiate the resynch protocol
(look-ahead window) before it requests another pass.

Notes:

The OTP value received by the server is the one calculated by the client.

AD Note: this text still has the stray "HOTP client" string that errata eid 5723 reported.

Errata ID: 5130
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Gerrit Jansen van Vuuren
Date Reported: 2017-09-27
Verifier Name: Paul Wouters
Date Verified: 2023-08-03

Section Appendix C says:

 static public String generateOTP(byte[] secret,
                  long movingFactor,
             int codeDigits,
                  boolean addChecksum,
             int truncationOffset)
           throws NoSuchAlgorithmException, InvalidKeyException
       {
           // put movingFactor value into text byte array
     String result = null;
     int digits = addChecksum ? (codeDigits + 1) : codeDigits;
           byte[] text = new byte[8];
           for (int i = text.length - 1; i >= 0; i--) {
               text[i] = (byte) (movingFactor & 0xff);
               movingFactor >>= 8;
           }

It should say:

 static public String generateOTP(byte[] secret,
                  long movingFactor,
             int codeDigits,
                  boolean addChecksum,
             int truncationOffset)
           throws NoSuchAlgorithmException, InvalidKeyException
       {
           // put movingFactor value into text byte array
     String result = null;
     long count = movingFactor;
     int digits = addChecksum ? (codeDigits + 1) : codeDigits;
           byte[] text = new byte[8];
           for (int i = text.length - 1; i >= 0; i--) {
               text[i] = (byte) (count & 0xff);
               count >>= 8;
           }

Notes:

method parameters like movingFactor should not be edited or changed in the method logic. This may lead to misunderstanding and bugs when the code is ported to other platforms and or re-implemented. Here movingFactor would be expected to stay constant and can be reused, but the original implementation updates the value to 0, which means any extra logic or updates (even debug statements) would always see movingFactor == 0 no matter what.

Errata ID: 163
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: M'Raihi, David
Date Reported: 2005-12-26

Section 9 says:

   Oracle AuthO()
   --------------
      A = ALG(K,C)
      C = C + 1
      Return O to B

It should say:

   Oracle AuthO()
   --------------
      A = ALG(K,C)
      C = C + 1
      Return A to B
             ^^

Notes:

Section A.4.1, Paragraph 3, Lemma 1 definition, top of page 19

The description of Lemma 1 defines P_ {N,m} (z) using the term Z_ {n}
and it should actually be Z_ {N}.
P_{N,m}(z) = Pr [x mod m = z : x randomly pick in Z_{n}]
Should be:
P_{N,m}(z) = Pr [x mod m = z : x randomly pick in Z_{N}]
^^^

Section E.2, Paragraph 4, bottom of page 32
32^8 > 10^12 so the security of an 8-alphanumeric HOTP code is
significantly better than a 9-digit HOTP value.
Should be:
32^8 > 10^12 so the security of an 8-alphanumeric HOTP code is
significantly better than a 12-digit HOTP value.
^^

In Author's Addresses, Page 35, David Naccache's contact information should be:

David Naccache
ENS, DI
45 rue d'Ulm
75005 Paris, France
and
Information Security Group,
Royal Holloway,
University of London, Egham,
Surrey TW20 0EX, UK

EMail: david.naccache@ens.fr, david.naccache@rhul.ac.uk

Errata ID: 5723
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Adam Sorini
Date Reported: 2019-05-18
Verifier Name: Roman Danyliw
Date Verified: 2022-01-20

Section 7.2 says:

The HOTP client (hardware or software token) increments its counter
and then calculates the next HOTP value HOTP client.

It should say:

The HOTP client (hardware or software token) increments its counter
and then calculates the next HOTP value.

Notes:

Stray "HOTP client" at the end of the sentence (for no reason).

RFC 4227, "Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)", January 2006

Note: This RFC has been updated by RFC 8553

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 162
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-02-08
Verifier Name: Eamon O'Tuathail
Date Verified: 2006-02-14

Section 9 says:

   Although service provisioning is a policy matter, at a minimum, all
   implementations MUST provide the following tuning profiles:

   for authentication: http://iana.org/beep/SASL/DIGEST-MD5

   for confidentiality: http://iana.org/beep/TLS (using the
      TLS_RSA_WITH_AES_EDE_CBC_SHA cipher)

   for both: http://iana.org/beep/TLS (using the
      TLS_RSA_WITH_AES_EDE_CBC_SHA cipher supporting client-side
      certificates)

It should say:

   Although service provisioning is a policy matter, at a minimum, all
   implementations MUST provide the following tuning profiles:

   for authentication: http://iana.org/beep/SASL/DIGEST-MD5

   for confidentiality: http://iana.org/beep/TLS (using the
      TLS_RSA_WITH_AES_128_CBC_SHA cipher)

   for both: http://iana.org/beep/TLS (using the
      TLS_RSA_WITH_AES_128_CBC_SHA cipher supporting client-side
      certificates)

Notes:

--VERIFIER NOTES--
It was first reported to us by Alfred Hînes with helpful comments by Philip
Nesser.

Errata ID: 699
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-02-08
Verifier Name: Eamon O'Tuathail
Date Verified: 2006-02-14

Section 6.1.1 says:

     If the authority component contains a domain name and a port number,
     e.g.,

        soap.beep://stockquoteserver.example.com:1026

     then the DNS is queried for the A Resource Records corresponding to
     the domain name, and the port number is used directly.

     If the authority component contains a domain name and no port number,
     e.g.,

         soap.beep://stockquoteserver.example.com

     the Service Record algorithm [11] is used with a service parameter of
     "soap-beep" and a protocol parameter of "tcp" to determine the IP/TCP
     addressing information.  If no appropriate SRV RRs are found (e.g.,
     for "_soap-beep._tcp.stockquoteserver.example.com"), then the DNS is
     queried for the A RRs corresponding to the domain name and the port
     number used is assigned by the IANA for the registration in Section
     8.4.

It should say:

     If the authority component contains a domain name and a port number,
     e.g.,

       	soap.beep://stockquoteserver.example.com:1026

     then the DNS is queried for the Address Records (i.e. "A" for
     IPv4, "AAAA" for IPv6 based on the host resolver specifications) 
     corresponding to the domain name, and the port number is used directly.

     If the authority component contains a domain name and no port number,
     e.g.,

           soap.beep://stockquoteserver.example.com

     the Service Record algorithm [11] is used with a service parameter of
     "soap-beep" and a protocol parameter of "tcp" to determine the IP/TCP
     addressing information.  If no appropriate SRV RRs are found (e.g.,
     for "_soap-beep._tcp.stockquoteserver.example.com"), then the DNS is
     queried for the Address RRs corresponding to the domain name     
     and the port number used is assigned by the IANA for the registration
     in Section 8.4.

Notes:

--VERIFIER NOTES--
It was first reported to us by Alfred Hînes with helpful comments by Philip
Nesser.

RFC 4230, "RSVP Security Properties", December 2005

Source of RFC: nsis (tsv)

Errata ID: 975
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-16
Verifier Name: RFC Editor
Date Verified: 2007-11-02

 

Section 3.1 says:

   o  Keyed Message Digest:

       The Keyed Message Digest is a security mechanism built into RSVP
|      that used to provide integrity protection of a signaling message
       (including its sequence number). 

It should say:

   o  Keyed Message Digest:

       The Keyed Message Digest is a security mechanism built into RSVP
|      that is used to provide integrity protection of a signaling
       message (including its sequence number).

Section 3.4 -- word omissions

In the first paragraph on page 11, Section 3.4 says:

                                             [...].  If user identity
|        confidentiality is provided, then the policy locator has to be
         encrypted with the public key of the recipient.  How to obtain
         this public key is not described in the document.  This detail
         may be specified in a concrete architecture in which RSVP is
         used.

It should say:
                           vvvvvvv
                                             [...].  If user identity
|        confidentiality is to be provided, then the policy locator has
         to be encrypted with the public key of the recipient.  How to
         obtain this public key is not described in the document.  This
         detail may be specified in a concrete architecture in which
         RSVP is used.

Rationale: Better balance the two parts of the tagged sentence!


Section 4.3 -- word omission

Within Section 4.3, near the bottom of page 27, the first paragraph
under the headline (6) Performance says:
                                                             v
|                                       [...].  Otherwise, it difficult
       to say which identifier is used to index the security
       association.

It should say:
                                                             vvv
|                                       [...].  Otherwise, it is
       difficult to say which identifier is used to index the security
       association.


Section 5.4 -- spurious blank line

On top of page 36, the text in the last bullet, (3), of Section 5.4
contains a spurious blank line, perhaps a page reformating artifact.
The RFC says:

   (3) It is assumed that SPIs do not change during the lifetime of the
       established QoS reservation.  If a new IPsec SA is created, then
|
       a new SPI is allocated for the security association.  [...]

It should say:

   (3) It is assumed that SPIs do not change during the lifetime of the
       established QoS reservation.  If a new IPsec SA is created, then
       a new SPI is allocated for the security association.  [...]


Section 5.6 -- a typo and a word omission

The second paragraph on page 37 says:

                              v
|  If an RSVP message can taket more than one possible path, then the
   IPsec engine will experience difficulties protecting the message.
   Even if the RSVP daemon installs a traffic selector with the
   destination IP address, still, no distinguishing element allows
   selection of the correct security association for one of the possible
|  RSVP nodes along the path.  Even if it possible to apply IPsec
   protection (in tunnel mode) for RSVP signaling messages by
   incorporating some additional information, there is still the
   possibility that the tunneled messages do not recognize a path change
   in a non-RSVP router.  [...]

It should say:

|  If an RSVP message can take more than one possible path, then the
   IPsec engine will experience difficulties protecting the message.
   Even if the RSVP daemon installs a traffic selector with the
   destination IP address, still, no distinguishing element allows
   selection of the correct security association for one of the possible
|  RSVP nodes along the path.  Even if it is possible to apply IPsec
   protection (in tunnel mode) for RSVP signaling messages by
   incorporating some additional information, there is still the
   possibility that the tunneled messages do not recognize a path change
   in a non-RSVP router.  [...]


Section 5.7 -- spurious blank line

Similar as noted in item (6) above, there is a spurious blank line
in the first paragraph of Section 5.7.
On top of page 38, the RFC says:

   mechanism, but authentication might, in many cases, be insufficient
   for authorization.  The communication procedures defined for policy
|
   objects [42] can be improved to support the more efficient per-
   channel financial settlement model by avoiding policy handling
   between inter-domain networks at a signaling message granularity.
   [...]

It should say:

   mechanism, but authentication might, in many cases, be insufficient
   for authorization.  The communication procedures defined for policy
   objects [42] can be improved to support the more efficient per-
   channel financial settlement model by avoiding policy handling
   between inter-domain networks at a signaling message granularity.
   [...]


Section 9.2 -- typo/punctuation

Within Section 9.2, the first entry on top of page 42 says:

   [21]  Dobbertin, H., Bosselaers, A., and B. Preneel, "RIPEMD-160: A
|        strengthened version of RIPEMD in Fast Software Encryption",
         LNCS vol. 1039, pp. 71-82, 1996.

It should say:

   [21]  Dobbertin, H., Bosselaers, A., and B. Preneel, "RIPEMD-160: A
|        strengthened version of RIPEMD", in: Fast Software Encryption,
         LNCS vol. 1039, pp. 71-82, 1996.

It should say:

[see above]

Notes:

from pending

RFC 4234, "Augmented BNF for Syntax Specifications: ABNF", October 2005

Note: This RFC has been obsoleted by RFC 5234

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 160
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-10-13

Section 3.10 says:

         Strings, Names formation

         Comment

         Value range

         Repetition

         Grouping, Optional

         Concatenation

         Alternative

It should say:

         Strings, Names formation

         Comment

         Value range

         Grouping, Optional

         Repetition

         Concatenation

         Alternative

Notes:

This re-ordering aligns the table with the prose description and the
meta-grammar in section 4.

RFC 4235, "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", November 2005

Note: This RFC has been updated by RFC 7463, RFC 8996

Source of RFC: sipping (rai)

Errata ID: 771
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nicolas-Peter Pohland
Date Reported: 2007-01-14
Verifier Name: Cullen Jennings
Date Verified: 2009-01-28

Section 6.2 says:

direction="receiver">

It should say:

direction="recipient">

Notes:

Occurs on pages 28, 29 (2 times), and 30.

The proposed version of text is consistent with the rest of the document,
including the schema in section 4.4.

from pending

Errata ID: 774
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nicolas-Peter Pohland
Date Reported: 2007-01-14
Verifier Name: Cullen Jennings
Date Verified: 2009-01-28

Section 4.4 says:

<xs:attribute name="display-name" type="xs:string"

It should say:

<xs:attribute name="display" type="xs:string"

Notes:

The proposed version of text is consistent with the rest of the document,
especially with all examples and has been implemented by several
manufacturers this way.

from pending

Errata ID: 781
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nicolas-Peter Pohland
Date Reported: 2007-01-14
Verifier Name: Cullen Jennings
Date Verified: 2009-01-28

Section 6.2 says:

          <local>
            <target uri="sip:alice@pc33.example.com"/>
              <param pname="+sip.rendering" pval="yes"/>
          </local>

It should say:

           <local>
            <target uri="sip:alice@pc33.example.com">
              <param pname="+sip.rendering" pval="yes"/>
            </target>
          </local>

Notes:

The <param> element must be enclosed by the <target> element.

from pending

Errata ID: 788
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nicolas-Peter Pohland
Date Reported: 2007-01-15
Verifier Name: Cullen Jennings
Date Verified: 2009-01-28

Section 6.2 says:

          <state reason="cancelled">terminated</state>
 
          <state reason="replaced">terminated</state>
 
          <state reason="replaced">confirmed</state>
 
          <state reason="remote-bye">terminated</state>

It should say:

          <state event="cancelled">terminated</state>
 
          <state event="replaced">terminated</state>
 
          <state event="replaced">confirmed</state>
 
          <state event="remote-bye">terminated</state>

Notes:

The "state" element does not have a "reason" attribute. It is called "event"
by definition in section 4.1.2. and the schema in 4.4.

from pending

Errata ID: 158
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Procter
Date Reported: 2006-10-24

Section 4.1 says:

      <?xml version="1.0"?>
      <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                   version="0" notify-state="full"
                   entity="sip:alice@example.com">
      </dialog-info>

It should say:

      <?xml version="1.0"?>
      <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                   version="0" state="full"
                   entity="sip:alice@example.com">
      </dialog-info>

Notes:

The proposed version of text is consistent with the rest of the document,
including the schema in section 4.4.

RFC 4237, "Voice Messaging Directory Service", October 2005

Source of RFC: vpim (app)

Errata ID: 1070
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: RFC Editor
Date Reported: 2005-11-02

Section 4.2 says:

vPIMRfc822Mailbox                A      IANA-ASSIGNED-OID.2.1
vPIMTelephoneNumber              A      IANA-ASSIGNED-OID.2.2

It should say:

vPIMTelephoneNumber                   A  1.3.6.1.1.11.2.1  
vPIMRfc822Mailbox                     A  1.3.6.1.1.11.2.2  

Errata ID: 156
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-11-30

Section 4.1 says:

   IANA has registered an LDAP Object Identifier for use in this
   technical specification, according to the following template:

It should say:

   IANA has registered an LDAP Object Identifier for use in this
   technical specification, according to the following template.
   This Object Identifier, 1.3.6.1.1.11, is referred to as the
   "IANA-ASSIGNED-OID" in the body of this memo.

Errata ID: 157
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-11-30
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-18

Section 2 says:

   (IANA-ASSIGNED-OID.1 NAME 'vPIMUser'
           SUP 'top'
           ...          )

It should say:

   (IANA-ASSIGNED-OID.1.1 NAME 'vPIMUser'
           SUP 'top'
           ...          )

Notes:

Note: IANA assigned OID 1.3.6.1.1.11 to IANA-ASSIGNED-OID. See <http://www.iana.org/assignments/ldap-parameters>.

Errata ID: 1071
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-11-30

Section 2.5 says:

Because ADPCM is a required format, the audio32kadpcm value must be
listed if this attribute is present.

It should say:

Because ADPCM is a required format, the audio/32kadpcm value must
be listed if this attribute is present.

RFC 4238, "Voice Message Routing Service", October 2005

Note: This RFC has been updated by RFC 6118

Source of RFC: vpim (app)

Errata ID: 155
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-11-30
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-18

Section 5 says:

   This specification registers the E2U+VPIM and E2U+Voice services
   according to the specifications and guidelines in RFC 3761 [ENUM]
   and the definitions in this document.

It should say:

   This specification registers the E2U+VPIM:LDAP and E2U+VPIM:Mailto
   services according to the specifications and guidelines in RFC 3761
   [ENUM] and the definitions in this document.

Notes:

[Note: The RFC text uses "<uri_schema_name>" vs. "<uri_schema_name>:"
in a non-systematical manner. I suspect the difference is not meant to
be significant in the text. Systematical usage of only one of these
two styles would be preferrable in derived (and other future) work.
I have intentionally omitted the trailing ":" after "Mailto" above.]

RFC 4241, "A Model of IPv6/IPv4 Dual Stack Internet Access Service", December 2005

Source of RFC: INDEPENDENT

Errata ID: 819
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-12-20
Verifier Name: Nevil Brownlee
Date Verified: 2010-04-03

Section 2.3 says:

      [ ....mising text ... ]
      IA_PD option and IA_PD Prefix options for the chosen prefix(es)
      back to the PE.

It should say:

Notes:

The 3rd paragraph of the indented, bulleted enumeration in
Section 2.3 contains only a fragment of a sentence.

The second bulleted paragraph covers this, the unbulleted third para
seems to be unneccessary, probably a fragment from a former edit;
just delete it.

Errata ID: 1411
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-12-20
Verifier Name: Nevil Brownlee
Date Verified: 2010-04-03

Section 2.3 says:

      [ ....mising text ... ]
      IA_PD option and IA_PD Prefix options for the chosen prefix(es)
      back to the PE.

It should say:

Notes:

The 3rd paragraph of the indented, bulleted enumeration in
Section 2.3 contains only a fragment of a sentence.

That unbulleted fragment seems to be left over from earlier editing,
the bullet before it says it all here. Delete the fragment.

Errata ID: 3462
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Pengfei Liu
Date Reported: 2013-01-16
Verifier Name: Nevil Brownlee
Date Verified: 2014-02-03

Section 3 says:

          |---Configure-Request-->| \
          |<--Configure-Request---|  |
          |<----Configure-Nak-----|  | PPP Network Layer Protocol Phase
          |<----Configure-Ack-----|  | (IPCP)
          |---Configure-Request-->|  |
          |<----Configure-Ack-----| /

It should say:

          |---Configure-Request-->| \
          |<--Configure-Request---|  |
          |<----Configure-Nak-----|  | PPP Network Layer Protocol Phase
          |-----Configure-Ack---->|  | (IPCP)
          |---Configure-Request-->|  |
          |<----Configure-Ack-----| /

Notes:

Wrong IPCP process in Figure 2.
In the IPCP phase of original Figure 2, there're both Configure-Nak and Configure-Ack for the first Configure-Request and it's impossible. The first Configure-Ack in IPCP phase of original Figure 2 should be sent to PE from CPE.

Errata ID: 153
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-12-20
Verifier Name: Bob Braden
Date Verified: 2008-04-21

Section 2.5 says:

       The CPE should return ICMPv6 Destination Unreachable message to
   a source address or silently discard the packets, when the original
   packet is destined for the unassigned prefix in the delegated prefix.

It should say:

       The CPE should return an ICMPv6 Destination Unreachable message
   to the source address or silently discard the packet when the original
   packet is destined for an unassigned prefix in the delegated prefix.

Errata ID: 821
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-12-20
Verifier Name: Nevil Brownlee
Date Verified: 2010-04-03

 

Second paragraph of Section 2.6:

   Devices connected to user network may learn a recursive DNS server
   address with the mechanism described in [RFC3736].


And the first sentence in Section 2.8:

   ICMPv6 Echo Request will be sent to the user network for connectivity
   monitoring in the service.

It should say:

Second paragraph of Section 2.6:

   Devices connected to the user network may learn a recursive DNS
   server address with the mechanism described in [RFC3736].

And the first sentence in Section 2.8:

   ICMPv6 Echo Requests will be sent to the user network for
   connectivity monitoring in the service.

RFC 4252, "The Secure Shell (SSH) Authentication Protocol", January 2006

Note: This RFC has been updated by RFC 8308, RFC 8332

Source of RFC: secsh (sec)

Errata ID: 5563
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Benoît Morgan
Date Reported: 2018-11-27
Verifier Name: Paul Wouters
Date Verified: 2023-07-28

Section 8. says:

      SSH_MSG_USERAUTH_FAILURE without partial success - The password
      has not been changed.  Either password changing was not supported,
      or the old password was bad.  Note that if the server has already
      sent SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, we know that it supports
      changing the password.

      SSH_MSG_USERAUTH_CHANGEREQ - The password was not changed because
      the new password was not acceptable (e.g., too easy to guess).

It should say:

      SSH_MSG_USERAUTH_FAILURE without partial success - The password
      has not been changed.  Either password changing was not supported,
      or the old password was bad.  Note that if the server has already
      sent SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, we know that it supports
      changing the password.

      SSH_MSG_USERAUTH_PASSWD_CHANGEREQ - The password was not changed 
      because the new password was not acceptable (e.g., too easy to 
      guess).

Notes:

SSH_MSG_USERAUTH_PASSWD_CHANGEREQ seems to have been truncated to SSH_MSG_USERAUTH_CHANGEREQ for no apparent reason.

RFC 4253, "The Secure Shell (SSH) Transport Layer Protocol", January 2006

Note: This RFC has been updated by RFC 6668, RFC 8268, RFC 8308, RFC 8332, RFC 8709, RFC 8758, RFC 9142

Source of RFC: secsh (sec)

Errata ID: 4533
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: denis bider
Date Reported: 2015-11-13
Verifier Name: Paul Wouters
Date Verified: 2023-07-28

Section 7.1 says:

[[ A paragraph is missing in this section to clarify implementation
   requirements for the reserved field. This paragraph could suitably
   be inserted after the description of first_kex_packet_follows. ]]

It should say:

      (reserved field)
         Servers and clients may or may not be aware of a future
         extension to this RFC that specifies a use for this field.

         Servers and clients that are NOT aware of such an extension:
         - MUST send this field with value zero;
         - MUST NOT act on any value of this field when received,
           whether the received value is zero or non-zero;
         - in key exchange, MUST properly hash the actual received
           value of this field.

         This behavior is REQUIRED to allow use of this field in
         future protocol extension.

Notes:

RFC 4253 defines the KEXINIT reserved field as follows:

uint32 0 (reserved for future extension)

This has in practice not been sufficient for developers to understand the requirements for sending and handling this field.

At least one common implementation will currently fail key exchange if the field is non-zero, because it forgets to decode it, and just assumes it is always zero.

At least one other implementation will currently disconnect if the field is non-zero, because it takes the above definition to mean that the field must be zero when received.

The above paragraph clarifies the correct treatment of this field. This has been discussed during November 2015 with other implementers on the "ietf-ssh@netbsd.org" mailing list. There appears to be consensus that the above is the correct treatment.

Errata ID: 1486
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Pasi Eronen
Date Reported: 2008-08-08
Verifier Name: Pasi Eronen
Date Verified: 2008-08-11

Section 12 says:

         SSH_MSG_DISCONNECT             1
         SSH_MSG_IGNORE                 2
         SSH_MSG_UNIMPLEMENTED          3
         SSH_MSG_DEBUG                  4
         SSH_MSG_SERVICE_REQUEST        5
         SSH_MSG_SERVICE_ACCEPT         6
         SSH_MSG_KEXINIT                20
         SSH_MSG_NEWKEYS                21

It should say:

         SSH_MSG_DISCONNECT             1
         SSH_MSG_IGNORE                 2
         SSH_MSG_UNIMPLEMENTED          3
         SSH_MSG_DEBUG                  4
         SSH_MSG_SERVICE_REQUEST        5
         SSH_MSG_SERVICE_ACCEPT         6
         SSH_MSG_KEXINIT                20
         SSH_MSG_NEWKEYS                21
         SSH_MSG_KEXDH_INIT             30
         SSH_MSG_KEXDH_REPLY            31

Notes:

This errata combines the partial errata reported by Denis Bider (errata ID 152 on 2006-01-23) and Dwayne Litzenberger (errata ID 1408 on 2008-04-11).

Errata ID: 4721
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Oleg Andriyanov
Date Reported: 2016-06-27
Verifier Name: Paul Wouters
Date Verified: 2023-07-28

Section 5.3 says:

   o  The minimum size of a TCP/IP header is 32 bytes.  Thus, the
      increase is actually from 33 to 51 bytes (roughly).

   o  The minimum size of the data field of an Ethernet packet is 46
      bytes [RFC0894].  Thus, the increase is no more than 5 bytes.
      When Ethernet headers are considered, the increase is less than 10
      percent.

It should say:

   o  The minimum size of a TCP/IP header is 32 bytes.  Thus, the
      increase is actually from 33 to 60 bytes (roughly).

   o  The minimum size of the data field of an Ethernet packet is 46
      bytes [RFC0894].  Thus, the increase is no more than 14 bytes.
      When Ethernet headers are considered, the increase is less than 25
      percent.

Notes:

As the minimum size of SSH message is 28, the minimum size of the TCP segment containing SSH message must be 32 + 28 == 60 bytes (as opposed to 32 + 1 in case of transmission of plain text over TCP).

RFC 4254, "The Secure Shell (SSH) Connection Protocol", January 2006

Note: This RFC has been updated by RFC 8308

Source of RFC: secsh (sec)

Errata ID: 6850
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Hamid Nazari
Date Reported: 2022-02-14
Verifier Name: Paul Wouters
Date Verified: 2023-07-28

Section 5.1 says:

Requests for assignments of new SSH_MSG_CHANNEL_OPEN 'reason code'
values (and associated 'description' text) in the range of 0x00000005
to 0xFDFFFFFF MUST be done through the IETF CONSENSUS method, as
described in [RFC2434].  The IANA will not assign Channel Connection
Failure 'reason code' values in the range of 0xFE000000 to
0xFFFFFFFF.  Channel Connection Failure 'reason code' values in that
range are left for PRIVATE USE, as described in [RFC2434].

It should say:

Requests for assignments of new SSH_MSG_CHANNEL_OPEN_FAILURE 'reason code'
values (and associated 'description' text) in the range of 0x00000005
to 0xFDFFFFFF MUST be done through the IETF CONSENSUS method, as
described in [RFC2434].  The IANA will not assign Channel Connection
Failure 'reason code' values in the range of 0xFE000000 to
0xFFFFFFFF.  Channel Connection Failure 'reason code' values in that
range are left for PRIVATE USE, as described in [RFC2434].

Notes:

The 'reason code' is present on SSH_MSG_CHANNEL_OPEN_FAILURE message to denote cause of the failure while original text attributes it to SSH_MSG_CHANNEL_OPEN by mistake.

Errata ID: 3878
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jim Wigginton
Date Reported: 2014-02-02
Verifier Name: Stephen Farrell
Date Verified: 2015-05-12

Section 5.2 says:

   The maximum amount of data allowed is determined by the maximum
   packet size for the channel, and the current window size, whichever
   is smaller.  The window size is decremented by the amount of data
   sent.  Both parties MAY ignore all extra data sent after the allowed
   window is empty.

It should say:

   The maximum amount of data allowed is determined by the maximum
   packet size for the channel, and the current window size, whichever
   is smaller.  The window size is decremented by the length of the data
   sent, length field included.  Both parties MAY ignore all extra data
   sent after the allowed window is empty.

Notes:

This is the data transfer packet:

byte SSH_MSG_CHANNEL_DATA
uint32 recipient channel
string data

Since string's are defined by RFC4251 as being "stored as a uint32 containing its length (number of bytes that follow) and zero (= empty string) or more bytes that are the value of the string" it's unclear weather or not the uint32 length field contributes to the total or not. In my interoperability testing it seems that it does but it doesn't seem that this is all that clear from this RFC.

It is also unclear from this RFC whether or not SSH_MSG_CHANNEL_EXTENDED_DATA should be decrementing from the window size or not. A strict interpretation would suggest it does not since the RFC makes no mention of it.

RFC 4255, "Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints", January 2006

Source of RFC: secsh (sec)

Errata ID: 693
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sam Weiler
Date Reported: 2006-02-10

Section 3.1 says:

The RDATA for a SSHFP RR consists of an algorithm number, fingerprint
type and the fingerprint of the public host key.

        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   algorithm   |    fp type    |                               /

It should say:

[not submitted]

Notes:

Section 3.1 has a packet format picture, and the upper row of bit
numbers seems to have been shifted to the left.

from pending

Errata ID: 6266
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jonathan Neuschäfer
Date Reported: 2020-08-26
Verifier Name: Benjamin Kaduk
Date Verified: 2020-08-30

Section 3.1.1 says:

   This algorithm number octet describes the algorithm of the public
   key.  The following values are assigned:

          Value    Algorithm name
          -----    --------------
          0        reserved
          1        RSA
          2        DSS

   Reserving other types requires IETF consensus [4].

It should say:

   This algorithm number octet describes the algorithm of the public
   key.  The following values are assigned:

          Value    Algorithm name
          -----    --------------
          0        reserved
          1        RSA
          2        DSA

   Reserving other types requires IETF consensus [4].

Notes:

The algorithm with value 2 is given as DSS in section 3.1.1, but as DSA in section 5

RFC 4256, "Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)", January 2006

Source of RFC: secsh (sec)

Errata ID: 1678
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Frank Cusack
Date Reported: 2009-02-03
Verifier Name: Pasi Eronen
Date Verified: 2009-02-16

Section 3.2 says:

   The language tag is deprecated and SHOULD be the empty string.  It
   may be removed in a future revision of this specification.  Instead,
   the server SHOULD select the language used based on the tags
   communicated during key exchange [SSH-TRANS].

   If the language tag is not the empty string, the server SHOULD use
   the specified language for any messages sent to the client as part of
   this protocol.  The language tag SHOULD NOT be used for language
   selection for messages outside of this protocol.  If the server does
   not support the requested language, the language to be used is
   implementation-dependent.

It should say:

   The language tag MAY be the empty string.  If acceptable/preferable
   languages were communicated during key exchange [SSH-TRANS], or in
   the SSH_MSG_USERAUTH_REQUEST message, the language tag SHOULD be the
   language selected by the server for the SSH_MSG_USERAUTH_INFO_REQUEST
   message.

Notes:

As originally pointed out by Alfred Hoenes (errata ID 758), this text
was incorrectly copy-pasted from Section 3.1.

The Information Request is sent from the server to the client, and it
already contains strings that make use of the particular
language/locale. The language tag in this message specifies the
language/locale used for building the 'instruction' and 'prompt'
strings in the request. This parallels the use of the language tag
in, e.g., the Disconnection Message of the SSH Transport Layer
Protocol.

Errata ID: 4746
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Gabriele Bonacini
Date Reported: 2016-07-25
Verifier Name: Paul Wouters
Date Verified: 2023-07-28

Throughout the document, when it says:

section 3.2, page 4:

int       num-prompts

section 3.4, page 6:

int       num-responses

section 3.4.4

page 7:
S:   int       1
...
C:   int       1

page 8:

S:   int       1
...
C:   int       1
...
S:   int       2
...
C:   int       2
...
S:   int       0

page 9:

S:   int       0

It should say:

section 3.2, page 4:

uint32       num-prompts

section 3.4, page 6:

uint32       num-responses

section 3.4.4

page 7:
S:   uint32       1
...
C:   uint32       1

page 8:

S:   uint32       1
...
C:   uint32       1
...
S:   uint32       2
...
C:   uint32       2
...
S:   uint32       0

page 9:

S:   uint32       0

Notes:

The type "int" is not present between the list of types present in the RFC 4251, section 5 ( "Data Type Representations Used in the SSH Protocols" ) . Alone it's confusing and meaningless.

RFC 4268, "Entity State MIB", November 2005

Source of RFC: entmib (ops)

Errata ID: 2611
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Ellison
Date Reported: 2010-11-06
Verifier Name: Dan Romascanu
Date Verified: 2010-11-23

Section 5 says:

   entStateOperEnabled NOTIFICATION-TYPE
.
.
.
               ...to find out whether
               there were any known alarms against the entity at that
               time that may explain why the physical entity has become
               operationally disabled."
     ::= { entStateNotifications 1 }

   entStateOperDisabled NOTIFICATION-TYPE
.
.
.
               ...to find out whether
               there were any known alarms against the entity at that
               time that may affect the physical entity's
               ability to stay operationally enabled."
     ::= { entStateNotifications 2 }

It should say:

   entStateOperEnabled NOTIFICATION-TYPE
.
.
.
               ...to find out whether
               there were any known alarms against the entity at that
               time that may affect the physical entity's
               ability to stay operationally enabled."
     ::= { entStateNotifications 1 }

   entStateOperDisabled NOTIFICATION-TYPE
.
.
.
               ...to find out whether
               there were any known alarms against the entity at that
               time that may explain why the physical entity has become
               operationally disabled."
     ::= { entStateNotifications 2 }

Notes:

It appears that the text was inadvertently swapped in the DESCRIPTION clauses for the ~Enabled and ~Disabled notification definitions.

Errata ID: 826
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-12-20

 

(1)

In the CONTACT-INFO clauses of both MODULE-IDENTITY instances
(page 6 and page 10), apparently a text line (between the two
HTTP URIs given) has been blanked out inadvertently; usually,
        "Working Group Charter:"
appears at similar places in other MIB definitions.


(2) [typo]

The DESCRIPTION clause of the EntityAlarmStatus TEXTUAL-CONVENTION
declaration contains a funny 'byte twist'.
 It says (near the middle of page 8):

       When the 'value of underRepair' is set, the resource is
       currently being repaired, ...

It should say:

       When the value of 'underRepair' is set, the resource is
       currently being repaired, ...


(3) 
In the DESCRIPTION clause of the entStateAdmin OBJECT-TYPE says:

    Setting this object to 'notSupported' will result in an 'inconsistentValue' error. [...]

It should say:

    Setting this object to 'unknown' will result in an 'inconsistentValue' error. [...]

Notes:


    This is inconsistent with the value range for the EntityAdminState
    TEXTUAL-CONVENTION describing the syntax of this object.
    (Perhaps there's some history behind the scene.)

(4) [typo/grammar]

The fourth paragraph of the DESCRIPTION clause of the entStateOper
OBJECT-TYPE, 10 text lines from the bottom of page 12, says:

       A value of 'testing' means that entity currently being
       tested and cannot therefore report whether it is
       operational or not.

It should perhaps better say:
                                                       vvvv
       A value of 'testing' means that entity currently is
       being tested and cannot therefore report whether it
       is operational or not.


(5) [editing omission?]

The DESCRIPTION clause of the entStateStandby OBJECT-TYPE, near
mid-page 14, says:

       Some entities will exhibit only a subset of the
       remaining standby state values.  [...]
       ^^^^^^^^^^
Perhaps this text has been 'cloned' without full adaptation.
Since, in this case, no possible value of the object has been
excluded by the text, the word "remaining" is inappropriate in
this context.  Therefore, this clause should better say:

       Some entities will exhibit only a subset of the
       standby state values.  [...]


(6) + (7)  [typo/grammar]

The second paragraph of the DESCRIPTION clause of each of the
two NOTIFICATION-TYPE declarations, near the bottom of page 14
and near the top of page 15, contains the sentence:

       The entity this notification refers can be identified by
       extracting the entPhysicalIndex from one of the
       variable bindings.  [...]

Preferrably, this sentence should better say (in both instances):

                                          vvvv
       The entity this notification refers to can be identified
       by extracting the entPhysicalIndex from one of the
       variable bindings.  [...]    

It should say:

[see above]       

Notes:

from pending

RFC 4270, "Attacks on Cryptographic Hashes in Internet Protocols", November 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 1072
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Henrik Levkowetz
Date Reported: 2005-12-02
Verifier Name: Russ Housley
Date Verified: 2010-03-11

Section 1 says:

   Hash algorithms are used by cryptographers in a variety of security
   protocols, for a variety of purposes, at all levels of the Internet
   protocol stack.  They are used because they have two security
   properties: to be one way and collision free.

It should say:

   Hash algorithms are used by cryptographers in a variety of security
   protocols, for a variety of purposes, at all levels of the Internet
   protocol stack.  They are used because they have two security
   properties: to be one-way and collision-free.

Notes:

Note the " one way and collision free." On the face of it, as plain
English, this is nonsense. In cryptographic terminology, I believe
the correct expression is " one-way and collision-free."

RFC 4271, "A Border Gateway Protocol 4 (BGP-4)", January 2006

Note: This RFC has been updated by RFC 6286, RFC 6608, RFC 6793, RFC 7606, RFC 7607, RFC 7705, RFC 8212, RFC 8654, RFC 9072

Source of RFC: idr (rtg)

Errata ID: 2838
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jamie Taylor
Date Reported: 2011-06-16
Verifier Name: Stewart Bryant
Date Verified: 2011-08-02

Section 8.2.2 says:

on page 72, description of the Established state:

If the HoldTimer_Expires event occurs (Event 10), the local system:
 ...[list of actions to take]...

It should say:

If the HoldTimer_Expires event occurs (Event 10), the local system:
 - deletes all routes associated with this connection
 ...[list of actions in original text]...

Notes:

All other transitions from Established to Idle explicitly state that all routes associated with the connection are deleted. This transition should as well.

Errata ID: 1633
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Scudder
Date Reported: 2008-12-12
Verifier Name: Stewart Bryant
Date Verified: 2011-08-02

Section 6.3 says:

   If an optional attribute is recognized, then the value of this
   attribute MUST be checked.  If an error is detected, the attribute
   MUST be discarded, and the Error Subcode MUST be set to Optional
   Attribute Error.  The Data field MUST contain the attribute (type,
   length, and value).

It should say:

   If an optional attribute is recognized, then the value of this
   attribute MUST be checked.  If an error is detected, the Error 
   Subcode MUST be set to Optional Attribute Error.  The Data 
   field MUST contain the attribute (type, length, and value).

Notes:

This simply removes the clause "the attribute MUST be discarded", which doesn't make sense since the peering is to be terminated anyway.

Errata ID: 4493
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruno Decraene
Date Reported: 2015-10-06
Verifier Name: Alvaro Retana
Date Verified: 2016-07-14

Section 4.5 says:

      Message Header Error subcodes:

               1 - Connection Not Synchronized.
               2 - Bad Message Length.
               3 - Bad Message Type.

      OPEN Message Error subcodes:

               1 - Unsupported Version Number.
               2 - Bad Peer AS.
               3 - Bad BGP Identifier.
               4 - Unsupported Optional Parameter.
               5 - [Deprecated - see Appendix A].
               6 - Unacceptable Hold Time.

      UPDATE Message Error subcodes:

               1 - Malformed Attribute List.
               2 - Unrecognized Well-known Attribute.
               3 - Missing Well-known Attribute.
               4 - Attribute Flags Error.
               5 - Attribute Length Error.
               6 - Invalid ORIGIN Attribute.
               7 - [Deprecated - see Appendix A].
               8 - Invalid NEXT_HOP Attribute.
               9 - Optional Attribute Error.
              10 - Invalid Network Field.
              11 - Malformed AS_PATH.

It should say:

      Message Header Error subcodes:

               0 - Unspecific.
               1 - Connection Not Synchronized.
               2 - Bad Message Length.
               3 - Bad Message Type.

      OPEN Message Error subcodes:

               0 - Unspecific.
               1 - Unsupported Version Number.
               2 - Bad Peer AS.
               3 - Bad BGP Identifier.
               4 - Unsupported Optional Parameter.
               5 - [Deprecated - see Appendix A].
               6 - Unacceptable Hold Time.

      UPDATE Message Error subcodes:

               0 - Unspecific.
               1 - Malformed Attribute List.
               2 - Unrecognized Well-known Attribute.
               3 - Missing Well-known Attribute.
               4 - Attribute Flags Error.
               5 - Attribute Length Error.
               6 - Invalid ORIGIN Attribute.
               7 - [Deprecated - see Appendix A].
               8 - Invalid NEXT_HOP Attribute.
               9 - Optional Attribute Error.
              10 - Invalid Network Field.
              11 - Malformed AS_PATH.

Notes:

RFC 4271 defines a use and a name for Error subcode 0:
- §4.5 (any error code):
If no appropriate Error Subcode is defined, then a zero
(Unspecific) value is used for the Error Subcode field.

- §6.2 (OPEN error code):
If one of the Optional Parameters in the OPEN message is recognized,
but is malformed, then the Error Subcode MUST be set to 0
(Unspecific).

The "IANA Considerations" section would also need to be updated
accordingly (says "0 Reserved”). However, IANA has corrected the
corresponding registry at http://www.iana.org/assignments/bgp-parameters.

Errata ID: 5369
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eric Osborne
Date Reported: 2018-05-25
Verifier Name: RFC Editor
Date Verified: 2018-05-25

Section 9.2.2.2 says:

         route MUST have the ORIGIN attribute with the value EGP.  In
         all other cases,, the value of the ORIGIN attribute of the
         aggregated route is IGP.

It should say:

         route MUST have the ORIGIN attribute with the value EGP.  In
         all other cases, the value of the ORIGIN attribute of the
         aggregated route is IGP.

Notes:

Extra comma after 'cases'.

RFC 4281, "The Codecs Parameter for "Bucket" Media Types", November 2005

Note: This RFC has been obsoleted by RFC 6381

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: tsv

Errata ID: 2859
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Randall Gellens
Date Reported: 2011-07-12
Verifier Name: Wes Eddy
Date Verified: 2011-08-17

Section 3.1 says:

   cod-fancy   := "codecs*" ":=" encodedv

It should say:

   cod-fancy   := "codecs*" "=" encodedv
                                       ^^^

Notes:

The syntax is supposed to specify "=" not ":="

RFC 4282, "The Network Access Identifier", December 2005

Note: This RFC has been obsoleted by RFC 7542

Source of RFC: radext (sec)

Errata ID: 757
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Koch
Date Reported: 2005-12-13
Verifier Name: Dan Romascanu
Date Verified: 2009-09-09

Section 2.6 says:

   The BNF of the realm portion allows the realm to begin with a digit,
   which is not permitted by the BNF described in [RFC1035].  This
   change was made to reflect current practice; although not permitted
   by the BNF described in [RFC1035], Fully Qualified Domain Names
   (FQDNs) such as 3com.com are commonly used and accepted by current
   software.

It should say:

[not supplied]

Notes:

section 2.6 missed the update of the hostname syntax in
RFC 1123, section 2.1.

RFC 1123 (STD 3) 2.1 allows labels starting with a <digit>
in fully qualified domain names of a host, RFC 1035 (STD 13)
2.3.1 still wants labels starting with a <letter>.

RFC 4286, "Multicast Router Discovery", December 2005

Source of RFC: magma (int)

Errata ID: 142
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-12-18
Verifier Name: Brian Haberman
Date Verified: 2012-04-26

Section 3.1.2 says:

  3.1.2.  AdvertisementJitter

     This is the maximum time (in seconds) by which the
     AdvertisementInterval is perturbed for each unsolicited
     Advertisement.  Note that the purpose of this jitter is to avoid
     synchronization of multiple routers on a network, hence choosing a
     value of zero is discouraged.  This value MUST be an integer no less
     than 0 seconds and no greater than AdvertisementInterval.

     The AdvertisementJitter MUST be  0.025*AdvertisementInterval .

It should say:

  3.1.2.  AdvertisementJitter

     This is the maximum time (in seconds) by which the
     AdvertisementInterval is perturbed for each unsolicited
     Advertisement.  Note that the purpose of this jitter is to avoid
     synchronization of multiple routers on a network.
     The value of AdvertisementJitter is not independently configurable;
     it is a variable derived internally within the implementation
     from the configured value for AdvertisementInterval.

    The AdvertisementJitter MUST be set to 0.025*AdvertisementInterval.

RFC 4288, "Media Type Specifications and Registration Procedures", December 2005

Note: This RFC has been obsoleted by RFC 6838

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 141
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-12-18

Section 4.2.2 says:

    A Media type of "image" indicates that the content specifies or more
    separate images that require appropriate hardware to display. ...

It should say:

    A Media type of "image" indicates that the content specifies one or
    more separate images that require appropriate hardware to display.
    ...

Errata ID: 818
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-12-18

 

Two small editorial issues:

- Perhaps as an artifact of the conversion of text from an existing
  RFC to a revised memo in I-D format and finally back to RFC format,
  along with repeated re-pagination, it can be observed from time to
  time that there appear unexpected blank lines in RFC text which
  visually break sentences apart.  This recurring arifact has hit
  RFC 4288 near the top of its pages #8 and #10.

It should say:

[not submitted]

Notes:

I assume you're referring to the break between "linear" and "sequence". I agree
it should not have been there.

from pending

RFC 4290, "Suggested Practices for Registration of Internationalized Domain Names (IDN)", December 2005

Source of RFC: INDEPENDENT

Errata ID: 5594
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Levine
Date Reported: 2019-01-07
Verifier Name: Adrian Farrel
Date Verified: 2021-06-01

Section 1.1 says:

The
   definition of the subset was embedded in the DNS protocol itself,
   although some applications protocols, notably those concerned with
   electronic mail, did impose and enforce similar rules.

It should say:

The
   definition of the subset was not embedded in the DNS protocol itself,
   although some applications protocols, notably those concerned with
   electronic mail, did impose and enforce similar rules.

Notes:

Author confirms the "not" is missing.

RFC 4291, "IP Version 6 Addressing Architecture", February 2006

Note: This RFC has been updated by RFC 5952, RFC 6052, RFC 7136, RFC 7346, RFC 7371, RFC 8064

Source of RFC: ipv6 (int)

Errata ID: 3480
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Erik Hugne
Date Reported: 2013-02-07
Verifier Name: Brian Haberman
Date Verified: 2013-03-16

Section 2.7 says:

Interface-Local scope spans only a single interface on a node
and is useful only for loopback transmission of multicast.

It should say:

Interface-Local scope spans only a single interface on a node 
and is useful only for loopback transmission of multicast.
Packets with interface-local scope received from another node 
must be discarded.

Notes:

It should be explicitly stated that interface-local scoped multicast packets
received from the link must be discarded.
The BSD implementation currently does this, but not Linux.
http://www.ietf.org/mail-archive/web/ipv6/current/msg17154.html

Errata ID: 6848
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Fabrice Verrac
Date Reported: 2022-02-12
Verifier Name: Eric Vyncke
Date Verified: 2022-04-06

Section Appendix A says:

Note: [EUI-64] actually defines 0xFF and 0xFF as the bits to be
         inserted to create an IEEE EUI-64 identifier from an IEEE MAC-
         48 identifier.

It should say:

Note: [EUI-64] actually defines 0xFF and 0xFE as the bits to be
         inserted to create an IEEE EUI-64 identifier from an IEEE MAC-
         48 identifier.

Notes:

Just seems to be a typo

-- Verifier note --
This is indeed a minor typo as the rest of the RFC is clear that 0xFF and 0xFE are used.

RFC 4293, "Management Information Base for the Internet Protocol (IP)", April 2006

Source of RFC: ipv6 (int)

Errata ID: 140
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-07
Verifier Name: Brian Haberman
Date Verified: 2013-03-16

Section 3.2.11 says:

   The circumstances used in the compliance section are implementing
   IPv4, IPv6, or IPv6 router functions and having a bandwidth of less
   than 20MB, between 20MB and 650MB, or greater than 650MB.

It should say:

   The circumstances used in the compliance section are implementing
   IPv4, IPv6, or IPv6 router functions and having a bandwidth of less
|  than 20Mbps, between 20Mbps and 650Mbps, or greater than 650Mbps.

Notes:

from pending

Errata ID: 3520
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-07
Verifier Name: Brian Haberman
Date Verified: 2013-03-16

The DESCRIPTION clause of the ipSystemStatsHCOctetGroup (p. 87) says:

           "This group is mandatory for systems that have an aggregate
            bandwidth of greater than 20MB.  Including this group does
            not allow an entity to neglect the 32 bit versions of these
            objects."

It should say:

           "This group is mandatory for systems that have an aggregate
|           bandwidth of greater than 20Mbps.  Including this group does
            not allow an entity to neglect the 32 bit versions of these
            objects."

Notes:

from pending

Errata ID: 3529
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-07
Verifier Name: Brian Haberman
Date Verified: 2013-03-16

The DESCRIPTION clause of the ipIfStatsOutFragCreates OBJECT-TYPE (p. 53) says:

           "The number of output datagram fragments that have been
            generated as a result of IP fragmentation.

            When tracking interface statistics, the counter of the
|           outgoing interface is incremented for a successfully
|           fragmented datagram.

            [...]

It should say:

           "The number of output datagram fragments that have been
            generated as a result of IP fragmentation.

            When tracking interface statistics, the counter of the
            outgoing interface is incremented for a successfully
|           created datagram fragment.

            [...]

Notes:

improperly replicated description text.
A "mirror" of Errata ID 3526 recurs, for the Interface Statistics.

Errata ID: 3521
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-07
Verifier Name: Brian Haberman
Date Verified: 2013-03-16

The DESCRIPTION clause of the ipSystemStatsHCPacketGroup (p. 87-88) says:

           "This group is mandatory for systems that have an aggregate
            bandwidth of greater than 650MB.  Including this group
            does not allow an entity to neglect the 32 bit versions of
            these objects."

It should say:

           "This group is mandatory for systems that have an aggregate
|           bandwidth of greater than 650Mbps.  Including this group
            does not allow an entity to neglect the 32 bit versions of
            these objects."

Notes:

from pending

Errata ID: 3522
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-07
Verifier Name: Brian Haberman
Date Verified: 2013-03-16

The DESCRIPTION clause of the ipIfStatsHCOctetGroup (p. 88) says:

           "This group is mandatory for systems that include the
            ipIfStatsGroup and include links with bandwidths of greater
            than 20MB.  Including this group does not allow an entity to
            neglect the 32 bit versions of these objects."

It should say:

           "This group is mandatory for systems that include the
            ipIfStatsGroup and include links with bandwidths of greater
|           than 20Mbps.  Including this group does not allow an entity
            to neglect the 32 bit versions of these objects."

Notes:

from pending

Errata ID: 3523
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-07
Verifier Name: Brian Haberman
Date Verified: 2013-03-16

The DESCRIPTION clause of the ipIfStatsHCPacketGroup (p. 88) says:

           "This group is mandatory for systems that include the
            ipIfStatsGroup and include links with bandwidths of greater
            than 650MB.  Including this group does not allow an entity
            to neglect the 32 bit versions of these objects."

It should say:

           "This group is mandatory for systems that include the
            ipIfStatsGroup and include links with bandwidths of greater
|           than 650Mbps.  Including this group does not allow an entity
            to neglect the 32 bit versions of these objects."

Notes:

from pending

Errata ID: 3524
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-07
Verifier Name: Brian Haberman
Date Verified: 2013-03-16

The DESCRIPTION clause of the ipv4SystemStatsHCPacketGroup (p. 88) says:

           "This group is mandatory for all systems supporting IPv4 and
            that have an aggregate bandwidth of greater than 650MB.
            Including this group does not allow an entity to neglect the
            32 bit versions of these objects."

It should say:

           "This group is mandatory for all systems supporting IPv4 and
|           that have an aggregate bandwidth of greater than 650Mbps.
            Including this group does not allow an entity to neglect the
            32 bit versions of these objects."

Notes:

from pending

Errata ID: 3525
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-07
Verifier Name: Brian Haberman
Date Verified: 2013-03-16

The DESCRIPTION of the ipSystemStatsOutFragReqds and OBJECT-TYPE (p. 35) says:

           "The number of IP datagrams that would require fragmentation
            in order to be transmitted.

            When tracking interface statistics, the counter of the
            outgoing interface is incremented for a successfully
            fragmented datagram.

            [...]

It should say:

           "The number of IP datagrams that would require fragmentation
            in order to be transmitted.

            When tracking interface statistics, the counter of the
|           outgoing interface is incremented for a datagram requiring
|           fragmentation.

            [...]

Notes:

The DESCRIPTION clauses of the ipSystemStatsOutFragReqds OBJECT-TYPE and the ipSystemStatsOutFragOKs OBJECT-TYPE erroneously contain identical clauses. After analysis of the context it becomes apparent that the DESCRIPTION clause of the ipSystemStatsOutFragReqds OBJECT-TYPE should be updated as above. (Note: The original text is appropriate in the DESCRIPTION clause of the ipSystemStatsOutFragOKs OBJECT-TYPE, where it appears again.)

Errata ID: 3526
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-07
Verifier Name: Brian Haberman
Date Verified: 2013-03-16

The DESCRIPTION clause of the ipSystemStatsOutFragCreates (p. 36) says:

           "The number of output datagram fragments that have been
            generated as a result of IP fragmentation.

            When tracking interface statistics, the counter of the
|           outgoing interface is incremented for a successfully
|           fragmented datagram.

            [...]

It should say:

           "The number of output datagram fragments that have been
            generated as a result of IP fragmentation.

            When tracking interface statistics, the counter of the
            outgoing interface is incremented for a successfully
|           created datagram fragment.

            [...]

Notes:

improperly replicated description text.
Obviously, the second sentence contradicts the first one.
( Apparently, this is an un-edited copy from the DESCRIPTION clauses
mentioned above, in Errata ID 3525, that needs editing to be appropriate.)

Errata ID: 3527
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-07
Verifier Name: Brian Haberman
Date Verified: 2013-03-16

The DESCRIPTION clause of the ipIfStatsOutFragReqds OBJECT-TYPE (p. 52) says:

           "The number of IP datagrams that would require fragmentation
            in order to be transmitted.

            When tracking interface statistics, the counter of the
|           outgoing interface is incremented for a successfully
|           fragmented datagram.

            [...]

It should say:

           "The number of IP datagrams that would require fragmentation
            in order to be transmitted.

            When tracking interface statistics, the counter of the
|           outgoing interface is incremented for a datagram requiring
|           fragmentation.

            [...]

Notes:

improperly replicated description text.
A "mirror" of Errata ID 3525 recurs, for the Interface Statistics.

Errata ID: 3530
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-07
Verifier Name: Brian Haberman
Date Verified: 2013-03-16

The DESCRIPTION clause of the ipAddressPrefixType OBJECT-TYPE (p. 60) says:

           "The address type of ipAddressPrefix."

It should say:

|          "The address type of ipAddressPrefixPrefix."

Notes:

mentions an object that does not exist in the MIB module.

Errata ID: 2526
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Raphael Garti
Date Reported: 2010-09-19
Verifier Name: Brian Haberman
Date Verified: 2012-04-26

Section 5 (p.76) says:

ipDefaultRouterLifetime OBJECT-TYPE
    SYNTAX     Unsigned32 (0..65535)
    UNITS      "seconds"
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION
           "The remaining length of time, in seconds, that this router
            will continue to be useful as a default router.  A value of
            zero indicates that it is no longer useful as a default
            router.  It is left to the implementer of the MIB as to
            whether a router with a lifetime of zero is removed from the
            list.

            For IPv6, this value should be extracted from the router
            advertisement messages."
    REFERENCE "For IPv6 RFC 2462 sections 4.2 and 6.3.4"
    ::= { ipDefaultRouterEntry 4 }

It should say:

ipDefaultRouterLifetime OBJECT-TYPE
    SYNTAX     Unsigned32 (0..65535)
    UNITS      "seconds"
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION
           "The remaining length of time, in seconds, that this router
            will continue to be useful as a default router.  A value of
            zero indicates that it is no longer useful as a default
            router.  It is left to the implementer of the MIB as to
            whether a router with a lifetime of zero is removed from the
            list.

            For IPv6, this value should be extracted from the router
            advertisement messages."
    REFERENCE "For IPv6 RFC 2461 sections 4.2 and 6.3.4"
    ::= { ipDefaultRouterEntry 4 }

Notes:

The REFERENCE clause of ipDefaultRouterLifetime (p.76) refers to an RFC which does not contain the sections referred to. The correct reference should be to RFC 2461.

Errata ID: 3531
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-07
Verifier Name: Brian Haberman
Date Verified: 2013-03-16

The ipDefaultRouterPreference OBJECT-TYPE (p. 76) says:

           "An indication of preference given to this router as a
            default router as described in he Default Router
            Preferences document.  [...]

and

    REFERENCE "RFC 4291, section 2.1"

It should say:

           "An indication of preference given to this router as a
|           default router as described in the Default Router
            Preferences document.  [...]

and                                        

|   REFERENCE "RFC 4191, section 2.1"

Notes:

two typos: he/the and 4291/4191.

RFC 4294, "IPv6 Node Requirements", April 2006

Note: This RFC has been obsoleted by RFC 6434

Note: This RFC has been updated by RFC 5095

Source of RFC: ipv6 (int)

Errata ID: 139
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Andrews
Date Reported: 2006-04-11

Section 5.1 says:

   Those nodes are NOT RECOMMENDED to support the experimental A6 and
   DNAME Resource Records [RFC-3363].

It should say:

   Those nodes are NOT RECOMMENDED to support the experimental A6
   Resource Records [RFC-3363].

RFC 4295, "Mobile IPv6 Management Information Base", April 2006

Source of RFC: mip6 (int)

Errata ID: 3548
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Verifier Name: Brian Haberman
Date Verified: 2013-03-16

Section 5 says:

(in the DESCRIPTION clause of the mip6HCNodeOutPkts OBJECT-TYPE
declaration, in the 12th line on page 28)

This object is a 64-bit version of mip6NodeOutOctets.

It should say:

This object is a 64-bit version of mip6NodeOutPkts.

Notes:

The DESCRIPTION clause of the mip6HCNodeOutPkts OBJECT-TYPE
declaration, on page 28 of RFC 4295, apparently has been
cloned from another object without proper editing, and thus
refers to a wrong object, mip6NodeOutOctets, where it should
refer to the object, mip6NodeOutPkts.

Errata ID: 3553
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Verifier Name: Brian Haberman
Date Verified: 2013-03-16

 

The DESCRIPTION clause of the mip6CnCompliance MODULE-COMPLIANCE,
on page 94, says:

                  "The compliance statement for SNMP entities
                   that implement the MOBILEIPV6-MIB and
|                  support monitoring of the basic correspondent node
|                  functionality.

This is the same description text as supplied for the
mip6CnCoreCompliance (on the same page), and hence does not
suffice to distinguish these two compliance statements.

The above text perhaps should say:

                  "The compliance statement for SNMP entities
                   that implement the MOBILEIPV6-MIB and support
                   monitoring of the basic correspondent node
|                  functionality and per-MN BU traffic.

Notes:

The items below are presented in RFC textual order.
I use change bars ('|' in column 1) and occasionally
up/down pointing marker lines ('^^^'/'vvv') to emphasize
the location of textual issues and/or proposed corrections.
Modified text has been re-adjusted to match RFC formatting
rules, where appropriate.

from pending

RFC 4296, "The Architecture of Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) on Internet Protocols", December 2005

Source of RFC: rddp (tsv)

Errata ID: 136
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-01-06
Verifier Name: lars.eggert@nokia.com
Date Verified: 2008-12-10

Section 2.2.1 says:

  void        rdma_read(socket_t s, ddp_addr_t s, ddp_addr_t d)

It should say:

  rdma_read(socket_t s, ddp_addr_t s, length_t l, ddp_addr_t d)

Notes:

This is inconsistent with the detailed description of that primitive
given subsequently on page 15 (2nd-to-last list paragraph), which
specifies four (4) arguments.

The latter, detailed spec is the appropriate version.

RFC 4301, "Security Architecture for the Internet Protocol", December 2005

Note: This RFC has been updated by RFC 6040, RFC 7619

Source of RFC: ipsec (sec)

Errata ID: 2180
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Verifier Name: Sean Turner
Date Verified: 2010-07-20

Section 4.4.2.2. says:

OPAQUE****        0  prot. "P"    OPAQUE

It should say:

OPAQUE****        0  prot. "P"    discard packet

Notes:

Opaque means protocol must not be available. Therefore this packet does not match and must be discarded.
The same four times more.

Errata ID: 2184
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Verifier Name: Sean Turner
Date Verified: 2010-07-20

Section D2 says:

We could define ANY as the complement of OPAQUE,
i.e., it would match all values but only for accessible port fields.

It should say:

We could define ANY as the complement of OPAQUE,
i.e., it would match all values but only for accessible port fields.
But we did not. ANY encompasses OPAQUE.

Notes:

misleading

RFC 4302, "IP Authentication Header", December 2005

Source of RFC: ipsec (sec)

Errata ID: 134
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Vishwas Manral
Date Reported: 2006-01-12

Section 3.3.4 says:

   NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire
   implementations, it will be necessary to examine all the extension
   headers to determine if there is a fragmentation header and hence
   that the packet needs reassembling prior to IPsec processing.

It should say:

   NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire
   implementations, it will be necessary to examine all the extension
   headers to determine if there is a fragmentation header, and either
   the More flag or the Fragment Offset is non-zero. If so that packet
   needs reassembling prior to IPsec processing.

RFC 4303, "IP Encapsulating Security Payload (ESP)", December 2005

Source of RFC: ipsec (sec)

Errata ID: 133
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Vishwas Manral
Date Reported: 2006-01-12

Section 3.3.4 says:

   NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire
   implementations, it will be necessary to examine all the extension
   headers to determine if there is a fragmentation header and hence
   that the packet needs reassembling prior to IPsec processing.

It should say:

   NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire
   implementations, it will be necessary to examine all the extension
   headers to determine if there is a fragmentation header, and either
   the More flag or the Fragment Offset is non-zero. If so that packet
   needs reassembling prior to IPsec processing.

Errata ID: 1654
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2009-01-16
Verifier Name: Pasi Eronen
Date Verified: 2009-06-18

Section 3.4.4.1 says:

Implementation Note:

            Implementations can use any set of steps that results in the
            same result as the following set of steps.  Begin by
            removing and saving the ICV field.  Next check the overall
            length of the ESP packet minus the ICV field.  If implicit
            padding is required, based on the block size of the
            integrity algorithm, append zero-filled bytes to the end of
            the ESP packet directly after the Next Header field, or
            after the high-order 32 bits of the sequence number if ESN
            is selected.  Perform the ICV computation and compare the
            result with the saved value, using the comparison rules
            defined by the algorithm specification.

It should say:

Implementation Note:

            Implementations can use any set of steps that results in the
            same result as the following set of steps.  Begin by
            removing and saving the ICV field.  Next check the overall
            length of the ESP packet minus the ICV field.  If implicit
            padding is required, based on the block size of the
            integrity algorithm, append padding bytes (according integrity 
            algorithm specification, see Section 3.3.2.1) to the end of
            the ESP packet directly after the Next Header field, or
            after the high-order 32 bits of the sequence number if ESN
            is selected.  Perform the ICV computation and compare the
            result with the saved value, using the comparison rules
            defined by the algorithm specification.

Notes:

(confirmed by Stephen Kent)

Errata ID: 6559
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Yaakov Stein
Date Reported: 2021-04-25
Verifier Name: Paul Wouters
Date Verified: 2022-04-10

Section 3.1.1 says:

                  AFTER APPLYING ESP
             -------------------------------------------------
       IPv4  |orig IP hdr  | ESP |     |      |   ESP   | ESP|
             |(any options)| Hdr | TCP | Data | Trailer | ICV|
             -------------------------------------------------

It should say:

                  AFTER APPLYING ESP
             ----------------------------------------------------
       IPv4  |updated IP hdr  | ESP |     |      |   ESP   | ESP|
             |(any options)   | Hdr | TCP | Data | Trailer | ICV|
             ----------------------------------------------------

Notes:

"orig" implies that the IP header is left as-is, while in fact the "protocol" field and the "total length" and the checksum must be updated. There IS appropriate text explaining this in RFC 3948 "The Total Length, Protocol, and Header Checksum (for IPv4) fields in the IP header are edited to match the resulting IP packet." but this text is missing here.

We have encountered an implementation that does not update the "total length" and the implementer claims that this is mandated by RFC 4303.

Paul / Tero:

This is updating the figure in RFC4303 (ESP) and should use "updated IP hdr" instead of "orig IP header", as the specification does in fact modify the protocol, total length and checksum fields.

In any potential future document update, text should be added that explains which fields are updated similar to what is done in the RFC3948:

The Total Length, Protocol, and Header Checksum (for IPv4) fields
in the IP header are edited to match the resulting IP packet.

As ESP is still used the IPsecME WG might want to make a RFC4303bis at some point and this fix should then be included. Perhaps the WG should think about moving it from proposed standard to internet standard at one point.

Errata ID: 4798
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Antonios Atlasis
Date Reported: 2016-09-09
Verifier Name: Paul Wouters
Date Verified: 2022-04-10

Section 2 says:

         * If tunnel mode is being used, then the IPsec implementation
           can add Traffic Flow Confidentiality (TFC) padding (see
           Section 2.4)  after the Payload Data and before the Padding
           (0-255 bytes) field.

It should say:

         * If tunnel mode is being used, then the IPsec implementation
           can add Traffic Flow Confidentiality (TFC) padding (see
           Section 2.7)  after the Payload Data and before the Padding
           (0-255 bytes) field.

Notes:

Section 2.4 refers to padding for Encryption. It is section 2.7 which refers to Traffic Flow Confidentiality (TFC) Padding

Errata ID: 4799
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Antonios Atlasis
Date Reported: 2016-09-09
Verifier Name: Paul Wouters
Date Verified: 2022-04-11

Section 2.6 says:

   To facilitate the rapid generation and discarding of the padding
   traffic in support of traffic flow confidentiality (see Section 2.4),
   the protocol value 59 (which means "no next header") MUST be used to
   designate a "dummy" packet.

It should say:

   To facilitate the rapid generation and discarding of the padding
   traffic in support of traffic flow confidentiality (see Section 2.7),
   the protocol value 59 (which means "no next header") MUST be used to
   designate a "dummy" packet.

Notes:

Section 2.4 refers to padding for Encryption. It is section 2.7 which refers to Traffic Flow Confidentiality (TFC) Padding.

RFC 4305, "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", December 2005

Note: This RFC has been obsoleted by RFC 4835

Source of RFC: ipsec (sec)

Errata ID: 132
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Donald Eastlake III
Date Reported: 2006-02-20

In the header, it says:

Obsoletes: 2404, 2406       

It should say:

Obsoletes: 2402, 2406

RFC 4306, "Internet Key Exchange (IKEv2) Protocol", December 2005

Note: This RFC has been obsoleted by RFC 5996

Note: This RFC has been updated by RFC 5282

Source of RFC: ipsec (sec)

Errata ID: 2279
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sergiu Todirascu
Date Reported: 2010-05-19
Verifier Name: Sean Turner
Date Verified: 2010-07-21

Section 3.3.2 says:

          Name                     Number                 Defined In
          NONE                       0
          AUTH_HMAC_MD5_96           1                     (RFC2403)
          AUTH_HMAC_SHA1_96          2                     (RFC2404)
          AUTH_DES_MAC               3
          AUTH_KPDK_MD5              4                     (RFC1826)
          AUTH_AES_XCBC_96           5                     (RFC3566)

It should say:

          Name                     Number                 Defined In
          NONE                       0
          AUTH_HMAC_MD5_96           1                     (RFC2403)
          AUTH_HMAC_SHA1_96          2                     (RFC2404)
          AUTH_DES_MAC               3
          AUTH_KPDK_MD5              4                     (RFC1828)
          AUTH_AES_XCBC_96           5                     (RFC3566)

Notes:

The RFC for AUTH_KPDK_MD5 should be 1828, not 1826 which is the first version of AH.

RFC 4307, "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)", December 2005

Note: This RFC has been obsoleted by RFC 8247

Source of RFC: ipsec (sec)

Errata ID: 1937
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tero Kivinen
Date Reported: 2009-11-02
Verifier Name: Pasi Eronen
Date Verified: 2010-03-01

Section 3.1.3. says:

      ENCR_NULL                11        [RFC2410]       MAY

It should say:

      ENCR_NULL                11        [RFC2410]       MUST NOT

Notes:

ENCR_NULL is MUST NOT for IKEv2, as RFC4306 specifies that ENCR_NULL MUST NOT be used as IKE encryption algorithm (RFC4306 section 5).

RFC 4308, "Cryptographic Suites for IPsec", December 2005

Source of RFC: ipsec (sec)

Errata ID: 1090
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Paul Hoffman
Date Reported: 2007-12-08
Verifier Name: Tim Polk
Date Verified: 2008-11-20

Section 2 says:

<none>

It should say:

2.4 Hash Algorithm for IKEv1

This document does not specify a hash algorithm to negotiate for IKEv1. Any hash algorithm can be used; SHA-1 is a common choice. No hash algorithm is needed for IKEv2.

Notes:

This was accidentally omitted during the discussion of this document.

RFC 4314, "IMAP4 Access Control List (ACL) Extension", December 2005

Source of RFC: imapext (app)

Errata ID: 828
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Arnaud Taddei
Date Reported: 2005-12-31

Section 2.1.1 says:

Example:       C: A003 Setacl INBOX/Drafts Byron lrswikda
               S: A001 OK Setacl complete
               C: A002 getAcl INBOX/Drafts
               S: * ACL INBOX Fred rwipslxcetda Byron lrswikcdeta
               S: A002 OK Getacl complete

It should say:

Example:       C: A003 Setacl INBOX/Drafts Byron lrswikda
               S: A003 OK Setacl complete
               C: A004 getAcl INBOX/Drafts
               S: * ACL INBOX/Drafts Fred rwipslxcetda Byron lrswikcdeta
               S: A004 OK Getacl complete

Notes:

from pending

Errata ID: 127
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Arnaud Taddei
Date Reported: 2005-12-31

Section 2.1.1 says:

   The client has specified the "d" right in the SETACL command above
   and it expands to "et" on the server:

               C: A002 getacl INBOX/Drafts
               S: * ACL INBOX Fred rwipslxcetda David lrswideta
               S: A002 OK Getacl complete

It should say:

   The client has specified the "d" right in the SETACL command above
   and it expands to "et" on the server:

               C: A002 getacl INBOX/Drafts
               S: * ACL INBOX/Drafts Fred rwipslxcetda David lrswideta
               S: A002 OK Getacl complete

Errata ID: 831
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Arnaud Taddei
Date Reported: 2005-12-31

Section 3.5 says:

The MYRIGHTS command returns the set of rights that the user has to
mailbox in an untagged MYRIGHTS reply.

It should say:

The MYRIGHTS command returns the set of rights that the user has to
the mailbox in an untagged MYRIGHTS reply.

Notes:

from pending

RFC 4319, "Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines", December 2005

Source of RFC: adslmib (ops)

Errata ID: 796
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Clay Sikes
Date Reported: 2007-01-07

Section 2.5 says:

       =2=    SHDSL optional wire-pair-2 (Not applicable to HDSL2)

It should say:

       =2=    SHDSL optional wire-pair-2 (Not applicable to HDSL2)
                  and SHDSL.bis optional wire-pair-3 and wire-pair-4
                  (not applicable to HDSL2 and 'classic' SHDSL)

Notes:

from pending

Errata ID: 813
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Clay Sikes
Date Reported: 2007-01-07

Section 3 says:

[[Page 45, hdsl2ShdslSpanConfMinLineRate, description]]

       If the minimum line rate equals the maximum line rate
       (hdsl2ShdslSpanMaxLineRate), the line rate is considered
       'fixed'.

It should say:

       If the minimum line rate equals the maximum line rate
       (hdsl2ShdslSpanConfMaxLineRate), the line rate is considered
       'fixed'.

Notes:

from pending

Errata ID: 815
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Clay Sikes
Date Reported: 2007-01-07

Section 3 says:

[[Page 46, hdsl2ShdslSpanConfMaxLineRate, description]]

       If the minimum line rate equals the maximum line rate
        (hdsl2ShdslSpanMaxLineRate), the line rate is considered
        'fixed'.

It should say:

       If the minimum line rate (hdsl2ShdslSpanConfMinLineRate) equals
        the maximum line rate, the line rate is considered
        'fixed'.

Notes:

from pending

Errata ID: 838
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-01-18

 

after studying the recently published RFC 4319 authored by you
I'd like to report the textual issues I found in that memo.  

I use change bars '|' in column 1 and '^^^' / 'vvv' style tags on 
extar lines to emphasize the location of the textual issues and/or    
the proposed corrections.
If necessary, I also have adjusted the line folding of proposed 
text to keep it conformant with RFC formatting rules.


(1)

Apparently, Figure 2 on page 10 has not been adapted from RFC 3276
to remain aligned with the extensions covered by RFC 4319.      
To keep the changes minimal, I propose to just amend the Figure         
caption, replacing:

       Key:  <////> HDSL2/SHDSL span
             <~~~~> HDSL2/SHDSL segment
             =1=    HDSL2/SHDSL wire-pair-1
             =2=    SHDSL optional wire-pair-2 (Not applicable to HDSL2)
             C      Customer side segment endpoint (modem)
             N      Network side segment endpoint (modem)             

by:

       Key:  <////> HDSL2/SHDSL span
             <~~~~> HDSL2/SHDSL segment
             =1=    HDSL2/SHDSL wire-pair-1
|            =2=    SHDSL optional wire-pair-2 (not applicable to HDSL2)
|                   and SHDSL.bis optional wire-pair-3 and wire-pair-4
|                   (not applicable to HDSL2 and 'classic' SHDSL)
             C      Customer side segment endpoint (modem)
             N      Network side segment endpoint (modem)


(2)

Section 2.7, on page 11, contains a bulleted list with two entries.
It turns out that the second (indented) paragraph of the 2nd bullet
in fact applies to both entries and hence should
  -  not be indented so much, and
  -  be adapted for plural grammar.
Thus, the paragraph saying:
                            vvv      vv
      The index value for this profile is a locally-unique
      administratively-assigned name for the profile having the textual
      convention 'SnmpAdminString' (RFC 3411 [RFC3411]).

should be modified to say:
                         vvv       vv
|  The index value for these profiles is a locally-unique
|  administratively-assigned name for the profile having the textual
|  convention 'SnmpAdminString' (RFC 3411 [RFC3411]).


(3)

The REVISION / DESCRIPTION clause pairs in MODULE-IDENTITY macro
invocations preferrably should be formulated in an 'update-friendly'
manner, i.e. such that the text does not need to be modified when
another revision of the MIB module is published in the future.

Therefore, I propose to change the DESCRIPTION clause for the
RFC 4319 revision of the HDSL2-SHDSL-LINE-MIB, at the bottom of
page 15 to follow this requirement.
The text there contains improper wording as well, the correction
of which justifies a combined Erratum entry.
Hence, the lines:

   REVISION    "200512070000Z" -- December 7, 2005
   DESCRIPTION "This version, published as RFC 4319.
         The following changes have been made in this version:
           1.  Added a 3rd and 4th wire pair.
           2.  Modified all rates such that their rates are only
               constrained by an unsigned 32-bit value and not by
               what today's perceived technology limitations are.

should be changed to say:

   REVISION    "200512070000Z" -- December 7, 2005
|  DESCRIPTION "Revised version, published as RFC 4319.
         The following changes have been made in this version:
           1.  Added a 3rd and 4th wire pair.
|          2.  Modified all rates such that they are only
               constrained by an unsigned 32-bit value and not by
               what today's perceived technology limitations are.


(3)

On page 16 (lower half), the 2nd paragraph of the DESCRIPTION clause
of the Hdsl2ShdslPerfCurrDayCount TEXTUAL-CONVENTION contains a mis-
spelled syntax name (of another TEXTUAL-CONVENTION).

The sentence,

                                [ ... ]  At that time, the value of the
         gauge is stored in the previous 1-day history interval, as
         defined in a companion object of type
         Hdsl2Shdsl1DayIntevalCount, and the current interval gauge
         is restarted at zero.

should say:

                                [ ... ]  At that time, the value of the
         gauge is stored in the previous 1-day history interval, as
         defined in a companion object of type
|        Hdsl2Shdsl1DayIntervalCount, and the current interval gauge
         is restarted at zero.
                           ^


(4)

On page 17 (lower half), the DESCRIPTION clause of the
Hdsl2ShdslPerfIntervalThreshold TEXTUAL-CONVENTION suffers from the
lack of a verb in its 2nd sentence.
The paragraph,

        "This convention defines a range of values that may be set in
         a fault threshold alarm control.  As the number of seconds in
         a 15-minute interval numbers at most 900, objects of this type
         may have a range of 0...900, where the value of 0 disables the
         alarm."

should say:

        "This convention defines a range of values that may be set in
         a fault threshold alarm control.  As the number of seconds in
|        a 15-minute interval numbers is at most 900, objects of this
         type may have a range of 0...900, where the value of 0 disables
         the alarm."


(5)

On page 18, there is a word omission in the DESCRIPTION clause of the
Hdsl2ShdslWirePair TEXTUAL-CONVENTION.
The paragraph,

        "This is the referenced pair of wires in an HDSL2/SHDSL segment.
         HDSL2 only supports a single pair (wirePair1 or two wire),
         SHDSL lines support an optional second pair (wirePair2 or four
         wire), and G.shdsl.bis support an optional third pair
         (wirePair3 or six wire) and an optional fourth pair
         (wirePair4 or eight wire)."

should say:

        "This is the referenced pair of wires in an HDSL2/SHDSL segment.
         HDSL2 only supports a single pair (wirePair1 or two wire),
         SHDSL lines support an optional second pair (wirePair2 or four
|        wire), and G.shdsl.bis lines support an optional third pair
         (wirePair3 or six wire) and an optional fourth pair
         (wirePair4 or eight wire)."


(6)

On pages 45..49 it would be very useful to have REFERENCE clauses
added to the OBJECT-TYPE declarations for the technology specific
objects in the Span Configuration Profile Table (similarly to what
has been done for the OBJECT-TYPE declarations for the objects in
the Unit Inventory Group, on pp. 24..27).


(7)

The DESCRIPTION clause of the hdsl2ShdslSpanConfMinLineRate OBJECT-
TYPE declaration contains a reference to a truncated object name.

That clause says:

        "This object configures the minimum transmission rate for
         the associated SHDSL Line in bits-per-second (bps) and includes
         both payload (user data) and any applicable framing overhead.
         If the minimum line rate equals the maximum line rate
         (hdsl2ShdslSpanMaxLineRate), the line rate is considered
         'fixed'.  If the minimum line rate is less than the
         maximum line rate, the line rate is considered
         'rate-adaptive'."

It should say:

        "This object configures the minimum transmission rate for
         the associated SHDSL Line in bits-per-second (bps) and includes
         both payload (user data) and any applicable framing overhead.
         If the minimum line rate equals the maximum line rate
|        (hdsl2ShdslSpanConfMaxLineRate), the line rate is considered
         'fixed'.  If the minimum line rate is less than the
         maximum line rate, the line rate is considered
         'rate-adaptive'."


(8)

The DESCRIPTION clauses of OBJECT-TYPE declarations preferrably
should be 'self-centric', i.e. describe context as seen from
the respective object. Therefore, text replications from one object
to another object without proper adaptation are sub-optimal, at best.
In particular, referencing an object within its DESCRIPTION clause
by name, while omitting to call another object (referenced there)
by its name does not add much to the clarity of the DESCRIPTION.

Therefore, I propose to slightly modify the DESCRIPTION clause of
the hdsl2ShdslSpanConfMaxLineRate OBJECT-TYPE declaration, on top
of page 46.  This clause is affected by issue (7) as well.

The clause says:

        "This object configures the maximum transmission rate for
         the associated SHDSL Line in bits-per-second (bps) and includes
         both payload (user data) and any applicable framing overhead.
         If the minimum line rate equals the maximum line rate
         (hdsl2ShdslSpanMaxLineRate), the line rate is considered
         'fixed'.  If the minimum line rate is less than the
         maximum line rate, the line rate is considered
         'rate-adaptive'."

It better should say:

        "This object configures the maximum transmission rate for
         the associated SHDSL Line in bits-per-second (bps) and includes
         both payload (user data) and any applicable framing overhead.
|        If the minimum line rate (hdsl2ShdslSpanConfMinLineRate) equals
|        the maximum line rate the line rate is considered 'fixed'.
         If the minimum line rate is less than the maximum line rate,
         the line rate is considered 'rate-adaptive'."


(9)

On pages 47/48, the DESCRIPTION clauses for the four objects:
    hdsl2ShdslSpanConfCurrCondTargetMarginDown,
    hdsl2ShdslSpanConfWorstCaseTargetMarginDown,
    hdsl2ShdslSpanConfCurrCondTargetMarginUp,  and
    hdsl2ShdslSpanConfWorstCaseTargetMarginUp
contain mainly identical text.  This emphasizes the similarities
between these objects but leaves the reader alone as to the use and
differing purpose of the objects.  It would be very desirable to
have additional expanatory text added to these four descriptions
to clarify the intended use (e.g., as an alarm limit).

    

It should say:

[see above]  

Notes:

from pending

Errata ID: 797
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Clay Sikes
Date Reported: 2007-01-07

Section 2.7 says:

SHDSL segment endpoints.  These profiles are defined in the
hdsl2ShdslEndpointAlarmConfProfileTable.

The index value for this profile is a locally-unique ...

It should say:

SHDSL segment endpoints.  These profiles are defined in the
hdsl2ShdslEndpointAlarmConfProfileTable.

The index value for these profiles is a locally-unique ...

Notes:

from pending

Errata ID: 801
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Clay Sikes
Date Reported: 2007-01-07
Verifier Name: RFC Editor
Date Verified: 2007-11-01

Section 3 says:

2.  Modified all rates such that their rates are only

It should say:

2.  Modified all rates such that they are only

Notes:

from pending

Errata ID: 807
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Clay Sikes
Date Reported: 2007-01-07
Verifier Name: RFC Editor
Date Verified: 2007-11-01

Section 3 says:

[[Page 16, Hdsl2ShdslPerfCurrDayCount, second paragraph in the description]]

       Hdsl2Shdsl1DayIntevalCount, and the current interval gauge

It should say:

       Hdsl2Shdsl1DayIntervalCount, and the current interval gauge

Notes:

from pending

Errata ID: 808
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Clay Sikes
Date Reported: 2007-01-07
Verifier Name: RFC Editor
Date Verified: 2007-11-01

Section 3 says:

[[Page 17, Hdsl2ShdslPerfIntervalThreshold , description]]

       a 15-minute interval numbers at most 900, objects of this

It should say:

       a 15-minute interval numbers is at most 900, objects of this

Notes:

from pending

Errata ID: 812
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Clay Sikes
Date Reported: 2007-01-07

Section 3 says:

[[Page 18, Hdsl2ShdslWirePair , description]]

       wire), and G.shdsl.bis support an optional third pair

It should say:

       wire), and G.shdsl.bis lines support an optional third pair

Notes:

from pending

RFC 4322, "Opportunistic Encryption using the Internet Key Exchange (IKE)", December 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 2455
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-20
Verifier Name: Sean Turner
Date Verified: 2010-08-06

Section 9.3 says:

The first senrtence of Section 9.3, on page 34, says:

   Tunnels sometimes go down because the remote end crashes,
   disconnects, or has a network link break.  [...]

The 'line break' might occor at any place within the network,
not just at the 'remote end'.
Therefore, the text should better say:

   Tunnels sometimes go down because the remote end crashes,
|  disconnects, or a network link break occurs.  [...]

Notes:

To facilitate the recognition of the text changes proposed,
I have added change bars ('|') in column 1, and up/down pointing
marker lines ('^^^'/'vvv').

Errata ID: 2456
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-20
Verifier Name: Sean Turner
Date Verified: 2010-08-06

Section 11.2 says:

Within the details of step 5, the text on page 38, lacks of a
sub-step label.
The text,

   (5J) DNS replies with public key of initiator.
        Upon successfully authenticating the peer, the connection
        instance makes a transition to authenticated OE peer on SG-B.
        The format of the TXT record returned is described in
        Section 5.2.
        Responder replies with ID and authentication.
        SG-B sends its ID along with authentication material, completing
        the phase 1 negotiation.
   (5L) IKE phase 2 negotiation.
        [...]

should say:

   (5J) DNS replies with public key of initiator.
        Upon successfully authenticating the peer, the connection
        instance makes a transition to authenticated OE peer on SG-B.
        The format of the TXT record returned is described in
        Section 5.2.
|  (5K) Responder replies with ID and authentication.
        SG-B sends its ID along with authentication material, completing
        the phase 1 negotiation.
   (5L) IKE phase 2 negotiation.
        [...]

Notes:

To facilitate the recognition of the text changes proposed,
I have added change bars ('|') in column 1, and up/down pointing
marker lines ('^^^'/'vvv').

Errata ID: 2458
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-20
Verifier Name: Sean Turner
Date Verified: 2010-08-06

Section 12.3 says:

The second paragraph of Section 12.3 (on page 41) says:

   The design of ISAKMP/IKE, and its use of cookies, defend against many
   kinds of denial of service.  [...]

It should say:
                                                           v
|  The design of ISAKMP/IKE, and its use of cookies, defends against
   many kinds of denial of service.  [...]

Notes:

To facilitate the recognition of the text changes proposed,
I have added change bars ('|') in column 1, and up/down pointing
marker lines ('^^^'/'vvv').

Errata ID: 2451
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-20
Verifier Name: Sean Turner
Date Verified: 2010-08-06

Section 1.2 says:

The last paragraph of that section, on page 4, says:

                                                            [...].  The
   mechanism described here, however, does provides an additional way to
   distribute the authentication materials; it is a public key method
   that does not require deployment of an X.509 based infrastructure.

It should say:
                                                 vvv
                                                            [...].  The
|  mechanism described here, however, does provide an additional way to
   distribute the authentication materials; it is a public key method
   that does not require deployment of an X.509 based infrastructure.

Notes:

To facilitate the recognition of the text changes proposed,
I have added change bars ('|') in column 1, and up/down pointing
marker lines ('^^^'/'vvv').

Errata ID: 2457
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-20
Verifier Name: Sean Turner
Date Verified: 2010-08-06

Section 11.2 says:

The final paragraph of Section 11.2, on page 39, says:

      SG-A sends the datagram saved at step (5) through the newly
      created tunnel to SG-B, where it gets decrypted and forwarded.
      Bob receives it at (7) and replies at (8).  SG-B already has a
|     tunnel up with G1 and uses it.  [...]
                     ^^
"G1" is undefined; apparently, it should be "SG-A".
Hence, this snippit should say:

      SG-A sends the datagram saved at step (5) through the newly
      created tunnel to SG-B, where it gets decrypted and forwarded.
      Bob receives it at (7) and replies at (8).  SG-B already has a
|     tunnel up with SG-A and uses it.  [...]
                     ^^^^

Notes:

To facilitate the recognition of the text changes proposed,
I have added change bars ('|') in column 1, and up/down pointing
marker lines ('^^^'/'vvv').

Errata ID: 2454
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-20
Verifier Name: Sean Turner
Date Verified: 2010-08-06

Section 4.5 says:

The first paragraph of Section 4.5, on page 25, says:

   The implementation described (FreeS/WAN 1.98) neither uses DNSSEC
   directly to explicitly verify the authenticity of zone information,
   nor uses the NSEC records to provide authentication of the absence of
   a TXT or KEY record.  [...]

It should say:

   The implementation described (FreeS/WAN 1.98) neither uses DNSSEC
   directly to explicitly verify the authenticity of zone information,
|  nor does it use the NSEC records to provide authentication of the
   absence of a TXT or KEY record.  [...]

(or similar).

Notes:

To facilitate the recognition of the text changes proposed,
I have added change bars ('|') in column 1, and up/down pointing
marker lines ('^^^'/'vvv').

Errata ID: 2452
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-20
Verifier Name: Sean Turner
Date Verified: 2010-08-06

Section 3.2.5 says:

Section 3.2.5

a) The second paragraph of Section 3.2.5, on page 16,

   Exit from this state occurs with either a successfully created IPsec
   SA or a failure of some kind.  Successful SA creation results in a
   transition to the key connection state.

should correctly name the state (cf. the Figure in Section 3.2, and
Section 3.2.6) by saying:

   Exit from this state occurs with either a successfully created IPsec
   SA or a failure of some kind.  Successful SA creation results in a
|  transition to the keyed connection state.
                        ^^

b) The second paragraph on page 17 contains the sentence:

                                            [...].  For an OE-
   pessimistic connection, the initiator makes a transition to the deny
   connection again with a low lifespan.  [...]

Conformant to the terminology used in the remainder of the text
(cf. the definition in the 3rd paragraph of Section 3.2, on page 12),
it should say:
                                                              vvvvvvvv
|                                           [...].  For an OE-paranoid
   connection, the initiator makes a transition to the deny connection
   again with a low lifespan.  [...]


c) The final paragraph of the section, still on page 17, says:

   The third failure occurs when there is signature failure while
   authenticating the remote gateway.  This can occur when there has
   been a key roll-over, but DNS has not caught up.  In this case again,
   the initiator makes a transition to the clear-text or the deny
   connection based upon the connection class.  However, the lifespan
   depends upon the remaining time to live in the DNS.  [...]

It should say:
                                         vvv
|  The third failure occurs when there is a signature failure while
   authenticating the remote gateway.  This can occur when there has
   been a key roll-over, but DNS has not caught up.  In this case again,
   the initiator makes a transition to the clear-text or the deny
|  connection state based upon the connection class.  However, the
   lifespan depends upon the remaining time to live in the DNS.  [...]
             ^^^^^^^

Rationale for the second change:
  Transitions occur between *states* in the FSM.  'clear-text' and
  'deny connection' are names given to two of these FSM states.

Notes:

To facilitate the recognition of the text changes proposed,
I have added change bars ('|') in column 1, and up/down pointing
marker lines ('^^^'/'vvv').

RFC 4326, "Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS)", December 2005

Note: This RFC has been updated by RFC 7280

Source of RFC: ipdvb (int)

Errata ID: 124
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Gorry Fairhurst
Date Reported: 2006-08-02

Section 7.2 says:

When in the Reassembly State, the Receiver reads a 2-byte SNDU Length 
field from the TS Packet payload. If the value is less than or equal to 
4, or equal to 0xFFFF, the Receiver discards the Current SNDU and

It should say:

When in the Reassembly State, the Receiver reads the first two bytes 
from the TS Packet payload. This value forms the first 2 bytes of the 
SNDU base header, which is a combination of the D-bit and the 
SNDU-Length. If the combined value is less than or equal to 4, or equal 
to 0xFFFF (i.e. D=1 and SNDU Length = 32768), the Receiver MUST discard 
the Current SNDU and

Notes:

- Usage of last byte in a TS-Packet.
Source: Bernhard Collini-Nocker & Gorry Fairhurst, 15th February 2006

Errata ID: 726
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Gorry Fairhurst
Date Reported: 2006-08-02

Section 4.1 says:

The most significant bit of the Length field carries the value of the 
Destination Address Absent Field, the D-bit

It should say:

The most significant bit of the first byte of the SNDU base header 
carries the value of the Destination Address Absent Field, the D-bit

Notes:

- Length field description refers to a 16-bit value.
Source: Bernhard Collini-Nocker, 15th February 2006

Errata ID: 727
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Gorry Fairhurst
Date Reported: 2006-08-02

In Example A.2, it says:

| HDR | 0x00 | 0x00 | 0xB1 | ... | C180 | 0x00 | 0x65 |

It should say:

| HDR | 0x00 | 0x00 | 0xB1 | ... | C180 | 0x00 | 0xB5 |

Notes:

- Misrepresentation of hex byte in example, Change /0x65/0xB5/
Source: Karsten Siebert, 26th February 2006

RFC 4327, "Link Management Protocol (LMP) Management Information Base (MIB)", January 2006

Note: This RFC has been obsoleted by RFC 4631

Source of RFC: ccamp (rtg)

Errata ID: 123

Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Adrian Farrel
Date Reported: 2006-01-18
Report Text:

RFC 4327 makes use of the TruthValue textual convention defined in RFC
2579.

Several places in the text identify the enumerations of the textual
convention ("true" and "false") using their names and their numeric values
(1 and 2 respectively).

However, several references to the enumerations of the textual convention
use the incorrect numeric values.

All references to the enumerations of this textual convention in this RFC
should take the names ("true" and "false") as the definitive settings, and
should disregard the numeric values when stated incorrectly.

---

Errata ID: 705
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-02-24
Verifier Name: Adrian Farrel
Date Verified: 2009-10-30

 

(1)  [plaintext flaw]

In the final paragraph of Section 7, on page 8, RFC 4327 says:

   In parallel with the entry created in the lmpTeLinkTable, an entry
   may be created in the teLinkTable of TE Link MIB module
   [RFC4220].

It should better say:

   In parallel with the entry created in the lmpTeLinkTable, an entry
|  may be created in the teLinkTable of the TE Link MIB module
   [RFC4220].
                                       ^^^^^

(2)  [plaintext flaw]

In the second paragraph of Section 8, at the bottom of page 8,
RFC 4327 says:

                        [...].  The interrelation of entries in the
   ifTable is defined by Interfaces Stack Group defined in [RFC2863].

It should say:

                        [...].  The interrelation of entries in the
|  ifTable is defined by the Interfaces Stack Group defined in
   [RFC2863].
                        ^^^^^


(3)  LmpInterval TEXTUAL-CONVENTION  (page 12)

The clause,

   DESCRIPTION
       "The interval delay in milliseconds."

perhaps should better say:

   DESCRIPTION
|      "The delay interval in milliseconds."

or even:

   DESCRIPTION
|      "The interval period for a periodically performed LMP operation,
|       in milliseconds."


(4)  LmpRetransmitInterval TEXTUAL-CONVENTION  (page 12)

The clause,

   DESCRIPTION
       "The retransmission interval delay in milliseconds."

perhaps should better say:

   DESCRIPTION
|      "The retransmission delay interval in milliseconds."

or even better:

   DESCRIPTION
|      "The (initial) retransmission interval in milliseconds."


(5)  lmpNbrRetransmitInterval OBJECT-TYPE  (page 14)

The sentence in the DESCRIPTION clause,

   "[...]  This object ... is used to implement congestion-handling
   mechanism as defined in Section 10 of the Link Management Protocol
   specification, which is based on RFC 2914."

should perhaps better say:
                                               vvvvv
|  "[...]  This object ... is used to implement the congestion-handling
   mechanism as defined in Section 10 of the Link Management Protocol
   specification, which is based on RFC 2914."


(6)  lmpNbrRetryLimit OBJECT-TYPE  (page 14)

The correction from item (5) above should be applied here as well.


(7)  lmpCcRemoteAddressType OBJECT-TYPE  (page 20)

   DESCRIPTION
       "This value represents the remote control channel IP address
        type.  In point-to-point configuration, this value can be set
        to unknown(0)."
   ::= { lmpControlChannelEntry 6 }

should better say:

   DESCRIPTION
       "This value represents the remote control channel IP address
|       type.  In point-to-point configurations, this value can be set
        to unknown(0)."
   ::= { lmpControlChannelEntry 6 }
                                              ^

[ The possible alternative, "In a point-to-point configuration, ..."
  is not proposed here, to maintain a style similar to the minimal
  change for the next object -- see (8) below.]


(8)  lmpCcRemoteIpAddr OBJECT-TYPE  (page 20)

   DESCRIPTION
       "[...]
        Control channel must be numbered on non-point-to-point
        configuration.  For point-to-point configuration, the
        remote control channel address can be of type unknown
        in which case this object must be a zero-length string.  The
        lmpCcRemoteId object then identifies the unnumbered
        address."
   ::= { lmpControlChannelEntry 7 }

should better say:

   DESCRIPTION
       "[...]
|       The control channel must be numbered on non-point-to-point
|       configurations.  For point-to-point configurations, the
        remote control channel address can be of type unknown
        in which case this object must be a zero-length string.  The
        lmpCcRemoteId object then identifies the unnumbered
        address."
   ::= { lmpControlChannelEntry 7 }


(11)  lmpControlChannelPerfEntry OBJECT-TYPE  (page 24)

   DESCRIPTION
       "An entry in this table is created by a LMP-enabled device for
        every control channel.  lmpCcCounterDiscontinuityTime is used
        to indicate potential discontinuity for all counter objects
        in this table."

The latter is not true.
In this MIB module, the discontinuity is monitored per table *entry*
(conceptual row), not for the table as a whole -- see the DESCRIPTIONs
for lmp<*>DiscontinuityTime later in the RFC.

Therefore, the above clause should say:

   DESCRIPTION
       "An entry in this table is created by a LMP-enabled device for
        every control channel.  lmpCcCounterDiscontinuityTime is used
        to indicate potential discontinuity for all counter objects
|       in this entry (conceptual row)."


(12)  lmpCcChannelStatusAckSent OBJECT-TYPE  (page 34)

The clause,

   DESCRIPTION
       "This object counts the number of ChannelStatus messages
        that have been sent on this control channel."
   ::= { lmpControlChannelPerfEntry 47 }

refers to the wrong message type; it should say:

   DESCRIPTION
|      "This object counts the number of ChannelStatusAck messages
        that have been sent on this control channel."
   ::= { lmpControlChannelPerfEntry 47 }


(14)  lmpTeLinkPerfEntry OBJECT-TYPE  (page 42)

The correction from item (11) above is to be applied here as well:

Replace:

   DESCRIPTION
       "An entry in this table is created by an LMP-enabled device for
        every TE link.  lmpTeCounterDiscontinuityTime is used
        to indicate potential discontinuity for all counter objects
        in this table."

by:

   DESCRIPTION
       "An entry in this table is created by an LMP-enabled device for
        every TE link.  lmpTeCounterDiscontinuityTime is used
        to indicate potential discontinuity for all counter objects
|       in this entry (conceptual row)."


(15)  lmpTeEndVerifyRetransmit OBJECT-TYPE  (page 45/46)

   DESCRIPTION
       "This object counts the number of EndVerify messages that
        have been retransmitted over this control channel."
   ::= { lmpTeLinkPerfEntry 12 }

is inappropriate.  In accordance with the text supplied for the
other objects in the LMP TE Link Performance Table, it should say:

   DESCRIPTION
       "This object counts the number of EndVerify messages that
|       have been retransmitted for this TE link."
   ::= { lmpTeLinkPerfEntry 12 }


(16)  lmpTeTestStatusFailureRetransmit OBJECT-TYPE  (page 47)

   DESCRIPTION
       "This object counts the number of TestStatusFailure messages
        that have been retransmitted on this TE link."
   ::= { lmpTeLinkPerfEntry 20 }

should say:

   DESCRIPTION
       "This object counts the number of TestStatusFailure messages
        that have been retransmitted for this TE link."
   ::= { lmpTeLinkPerfEntry 20 }

[ According to Section 12.5.8. of the LMP specification [RFC 4204],
  LMP TestStatusFailure messages are transmitted over the control
  channel; hence, "retransmitted *on* this TE Link" is wrong! ]


(17)  lmpTeLinkSummaryRetransmit OBJECT-TYPE  (page 48)

The correction from item (15) above is to be applied here as well:

Replace:

   DESCRIPTION
       "This object counts the number of LinkSummary messages that
        have been retransmitted over this control channel."
   ::= { lmpTeLinkPerfEntry 25 }

by:

   DESCRIPTION
       "This object counts the number of LinkSummary messages that
|       have been retransmitted for this TE link."
   ::= { lmpTeLinkPerfEntry 25 }


(18)  lmpTeChannelStatusAckSent OBJECT-TYPE  (page 50)

The correction from item (12) above is to be applied here as well:

Replace:

   DESCRIPTION
       "This object counts the number of ChannelStatus messages
        that have been sent for this TE link."
   ::= { lmpTeLinkPerfEntry 34 }

by:

   DESCRIPTION
|      "This object counts the number of ChannelStatusAck messages
        that have been sent for this TE link."
   ::= { lmpTeLinkPerfEntry 34 }


(20)  lmpDataLinkPerfEntry OBJECT-TYPE  (page 55)

The correction from item (11) above is to be applied here as well:

Replace:

   DESCRIPTION
       "An entry in this table contains information about
        the LMP performance counters for the data-bearing links.
        lmpDataLinkDiscontinuityTime is used to indicate potential
        discontinuity for all counter objects in this table."

by:

   DESCRIPTION
       "An entry in this table contains information about
        the LMP performance counters for the data-bearing links.
        lmpDataLinkDiscontinuityTime is used to indicate potential
|       discontinuity for all counter objects in this entry."


(21)  lmpNotificationMaxRate OBJECT-TYPE  (page 57/58)

The DESCRIPTION text near the top of page 58 says:

                        [...].  For instance, a network of 100 nodes
        with 5 links of 128 wavelengths each and a link verification
        of 1 minute with no more than 10% of the links failed at any
        given time would have 1 notification per second sent from
        each node, or 100 notifications per second for the whole
        network.  The rest of the notifications are negligible
        compared to this number.

        To alleviate the congestion problem, the
        lmpNotificationMaxRate object can be used to implement a
        throttling mechanism.  It is also possible to enable/disable
        certain type of notifications.

It should say, correcting two flaws (line breaks adjusted):

                        [...].  For instance, a network of 100 nodes
        with 5 links of 128 wavelengths each and a link verification
|       interval of 1 minute with no more than 10% of the links failed
        at any given time would have 1 notification per second sent
        from each node, or 100 notifications per second for the whole
        network.  The rest of the notifications are negligible
        compared to this number.

        To alleviate the congestion problem, the
        lmpNotificationMaxRate object can be used to implement a
        throttling mechanism.  It is also possible to enable/disable
|       certain types of notifications.


(23)  lmpControlChannelGroup OBJECT-GROUP  (page 72)

At the bottom of page 72, the RFC says:

   DESCRIPTION
          "Objects that can be used to configure LMP interface."

It should say:

   DESCRIPTION
|         "Objects that can be used to configure LMP interfaces."

It should say:

[see above]

Notes:

Verifier's analysis:

1. Yes. Editorial nit.
2. Yes. Editorial nit.
3. Yes. Editorial nit.
4. Yes. Editorial nit.
5. Yes. Editorial nit.
6. Yes. Editorial nit.
7. Yes. Editorial nit.
8. Yes. Editorial nit.
11. Yes. Editorial change of substance.
12. Yes. Editorial change of substance.
14. Yes. Editorial change of substance.
15. Yes. Editorial change of substance.
16. Yes. Editorial change of substance.
17. Yes. Editorial change of substance.
18. Yes. Editorial change of substance.
20. Yes. Editorial change of substance.
21. Yes. Editorial nit.
23. Yes. Editorial nit.

Rejected items have been moved to Errata ID 1938.

RFC 4330, "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", January 2006

Note: This RFC has been obsoleted by RFC 5905

Source of RFC: INDEPENDENT

Errata ID: 2263
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Scott Barnes
Date Reported: 2010-05-15
Verifier Name: Nevil Brownlee
Date Verified: 2013-05-23

Section 5 says:

4.  The server reply should be discarded if any of the LI, Stratum,
    or Transmit Timestamp fields is 0 or the Mode field is not 4
    (unicast) or 5 (broadcast).

It should say:

4.  The server reply should be discarded if any of the VN, Stratum, 
    or Transmit Timestamp fields is 0 or the Mode field is not 4 
    (unicast) or 5 (broadcast).

Notes:

Zero is a legal value for the LI field under normal conditions. Zero is not legal for VN field, however.

Errata ID: 2480
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Dave Higton
Date Reported: 2010-08-20
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-20

Section 4 says:

      MSF        Rugby (UK) Radio 60 kHz

It should say:

      MSF        Anthorn (UK) Radio 60 kHz

Notes:

The MSF transmitter was relocated from Rugby to Anthorn, in Cumbria, on 2007 March 31. See http://www.npl.co.uk/science-+-technology/time-and-frequency/npl-ensures-accurate-uk-time-for-the-next-15-years

http://www.npl.co.uk/educate-explore/what-is-time/what-is-msf confirms this.

RFC 4334, "Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)", February 2006

Source of RFC: pkix (sec)

Errata ID: 122
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-03

 

(1)

In the 3rd paragraph of section 1, on page 2 RFC 4334 says:

   For example, the same wireless station might use IEEE 802.1X to
   authenticate to a corporate IEEE 802.11 WLAN and a public IEEE 802.11
   "hotspot."  [...]
           ^^
The syntax error of that sentence should be corrected to say:

   For example, the same wireless station might use IEEE 802.1X to
   authenticate to a corporate IEEE 802.11 WLAN and a public IEEE 802.11
|  "hotspot".  [...]
           ^^

(2)

At the end of the 2nd paragraph of section 5, on page 6, the RFC says:

                           [...].  Whenever this SSID disclosure is a
   concern, different peer certificates ought to be used for the each
   WLAN.
                                                         ^^^^^^^^^^^^
It should say:

                           [...].  Whenever this SSID disclosure is a
|  concern, different peer certificates ought to be used for each WLAN.


(3)

In Section 7.1, on page 7, the Normative Reference,

                                               vvv
   [EAP]       Aboba, B., Blunk, L., Vollbrechtand, J., Carlson, J.,
               and H. Levkowetz, "Extensible Authentication Protocol
               (EAP)", RFC 3748, June 2004.

should say:

|  [EAP]       Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
|              H. Levkowetz, Ed., "Extensible Authentication Protocol
               (EAP)", RFC 3748, June 2004.

and on page 8, the Normative Reference,

                                       v
   [X.690]     ITU-T Recommendation X.660 Information Technology - ASN.1
               encoding rules: Specification of Basic Encoding Rules
               (BER), Canonical Encoding Rules (CER) and Distinguished
               Encoding Rules (DER), 1997.

should say:
                                       v
|  [X.690]     ITU-T Recommendation X.690 Information Technology - ASN.1
               encoding rules: Specification of Basic Encoding Rules
               (BER), Canonical Encoding Rules (CER) and Distinguished
               Encoding Rules (DER), 1997.

Notes:

* The minor item (1) is included for completeness.
* Items (1) and (2) are inherited from RFC 3770.

from pending

RFC 4340, "Datagram Congestion Control Protocol (DCCP)", March 2006

Note: This RFC has been updated by RFC 5595, RFC 5596, RFC 6335, RFC 6773

Source of RFC: dccp (tsv)

Errata ID: 974
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Eddie Kohler
Date Reported: 2006-07-11

Section 6.6.4 says:

[text below should be added to the end of the section]

It should say:

   FGSR and FGSS values always satisfy FGSR <= GSR and FGSS <= GSS,
   where GSR and GSS are the Greatest Sequence Numbers Received by and
   Sent from this endpoint.  These constraints MUST be enforced even
   when GSR and GSS wrap, as they might in a long connection.
   Implementations SHOULD thus check FGSR and FGSS after every packet
   received or sent, as follows.  (Wmax is the maximum allowed value for
   the Sequence Window feature; see Section 7.5.2.)

         If FGSR > GSR, then FGSR := GSR - Wmax.
         If FGSS > GSS, then FGSS := GSS - Wmax.

   Alternate implementations that correctly handle sequence number
   wrapping are also acceptable.

Notes:

One technical omission has been found concerning the FGSR and FGSS
variables used to detect reordering of feature negotiation options. We
suggest adding the above paragraph to the end of Section 6.6.4, on Page
42.

via Alfred Hoenes

from pending

Errata ID: 1049
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sally Floyd
Date Reported: 2007-09-01

Section 6.6.8 says:

      The Ack
      Ratio feature takes two-byte, non-zero integer values, so a
      "Change L(Ack Ratio, 0)" option is never valid.

It should say:

      The Sequence Window feature takes six-byte, non-zero integer
      values, with a minimum valid value of 32, so a "Change
      L(Sequence Window, 0)" option is never valid.

Notes:

reported by Gerrit Renker

Errata ID: 980
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eddie Kohler
Date Reported: 2006-07-11

 

In Section 6.6.4, Page 41, it says:

              (Change and/or Confirm).  This value is initialized to
              ISR - 1.

It should say:

              (Change and/or Confirm).  This value is initialized to
              ISR - 1, where ISR is the Initial Sequence Number Received
              from the other endpoint.  (ISR and other sequence number
              variables are defined in Section 7.1.)

In Section 6.6.4, Page 41, it says:

              reordering.  FGSS is initialized to ISS.

It should say:

              reordering.  FGSS is initialized to ISS, the Initial
              Sequence Number Sent by this endpoint.


In Section 7.5.2, Page 49, it says:

    getting out sync after bursts of loss,

It should say:

    getting out of sync after bursts of loss,


In Section 8.1.2, Page 60, it says:

            intepreting the four-character result as a 32-bit big-endian

It should say:

            interpreting the four-character result as a 32-bit big-endian


In Appendix A, Page 116, it says:

    right to left.  The implementation maintains five variables, aside

It should say:

    right to left.  The implementation maintains four variables, aside

And it says:

       acknowledged in the buffer.  This corresponds to the "head"

It should say:

       acknowledged in the buffer.  This corresponds to the "buf_head"

On Page 117, it says:

    Ack Vector, it remembers four variables:

It should say:

    Ack Vector, it remembers five variables:


In Section A.3, Page 121, it says:

    HC-Sender packet 3, so the HC-Sender has now received HC-Receiver's

It should say:

    HC-Sender packet 3, so the HC-Sender has now received the HC-Receiver's


In Section A.4, Page 122, it says:

    a single acknowledgement number tells HC-Receiver how much ack

It should say:

    a single acknowledgement number tells the HC-Receiver how much ack

Notes:

via Alfred Hoenes

from pending

RFC 4342, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)", March 2006

Note: This RFC has been updated by RFC 5348, RFC 6323, RFC 8311

Source of RFC: dccp (tsv)

Errata ID: 610
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sally Floyd
Date Reported: 2007-10-24

Section 6 says:

      2. A Receive Rate option, defined in Section 8.3, specifying the
         rate at which data was received since the last DCCP-Ack was
         sent.

It should say:

      2. A Receive Rate option, defined in Section 8.3, specifying the
         rate at which data was received over the last round-trip time.

Notes:

Section 8.3 of RFC 4342 (DCCP CCID 3) specifies that the Receive
Rate option reports the receive rate since the last feedback packet
was sent. In contrast, Section 6.2 of RFC 3448 (TFRC) specifies
that the feedback packet reports the receive rate over the last
round-trip time. As a result, the receive rate specified by
RFC 4342 differs from that of TFRC for a feedback packet after an
idle period; the receive rate report specified in RFC 4342 reports
the receive rate over the entire idle period. The receive rate
reported by RFC 4342 also differs from that of TFRC for an early
feedback packet reporting a new loss event. This errata updates
RFC 4342 to use the definition of the receive rate as specified in
RFC 3448.

Errata ID: 611
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sally Floyd
Date Reported: 2007-10-24

Section 8.3 says:

      Its four data bytes indicate the rate at which
      the receiver has received data since it last sent an
      acknowledgement, in bytes per second.  To calculate this receive
      rate, the receiver sets t to the larger of the estimated round-
      trip time and the time since the last Receive Rate option was
      sent.

It should say:

      Its four data bytes indicate the rate at which
      the receiver has received data over the last round-trip time,
      in bytes per second.  To calculate the time interval t for
      calculating this receive rate, the receiver follows Section
      6.2 of [RFC3448].

Notes:

This errata updates RFC 4342 to use the definition of the receive rate
as specified in RFC 3448.

Errata ID: 612
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sally Floyd
Date Reported: 2007-10-24

Section 8.3 says:

It should say:

      Assume that the sender receives two feedback packets with 
      Acknowledgement Numbers A1 and A2, respectively.  Further assume
      that the sender sent no data packets in between Sequence Numbers
      A1+1 and A2, inclusive.  (All those packets must have been pure
      acknowledgements, Sync and SyncAck packets, and so forth.)  Then
      the sender MAY, at its discretion, ignore the second feedback
      packet's Receive Rate option.  Note that when the sender decides
      to ignore such an option, it MUST NOT reset the nofeedback timer
      as it normally would; the nofeedback timer will expire as if the
      second feedback packet had not been received.

Notes:

This is a new paragraph to be added to the end of Section 8.3.
It specifies that if the interval covered by a feedback packet doesn't include
any data packets, then the sender doesn't have to use the reported receive rate.

Errata ID: 829
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Eddie Kohler
Date Reported: 2007-02-07

Section 5 says:

   Translating this to the packet-based congestion control of CCID 3,
   the initial CCID 3 sending rate is allowed to be at least two packets
   per RTT, and at most four packets per RTT, depending on the packet
   size.  The initial rate is only allowed to be three or four packets
   per RTT when, in terms of segment size, that translates to at most
   4380 bytes per RTT.

It should say:

   Therefore, in contrast to [RFC3448], the initial CCID 3 sending rate
   is allowed to be at least two packets per RTT, and at most four
   packets per RTT, depending on the packet size.  The initial rate is
   only allowed to be three or four packets per RTT when, in terms of
   segment size, that translates to at most 4380 bytes per RTT.  This
   might be implemented, for example, by setting the initial sending
   rate to min(4*s, max(2*s, 4380 bytes)), where "s" as usual is the
   packet size in bytes.

Notes:

Clarification of initial sending rates.

Reported By: Eddie Kohler and Sally Floyd, from Gerrit Renker and Arjuna Sathiaseelan

from pending

Errata ID: 830
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Eddie Kohler
Date Reported: 2007-02-07

Section 5 says:

   The sender's measurement of the round-trip time uses the Elapsed Time
   and/or Timestamp Echo option contained in feedback packets, as
   described in Section 8.2. The Elapsed Time option is required, while
   the Timestamp Echo option is not.  The sender maintains an average
   round-trip time heavily weighted on the most recent measurements.

It should say:

   The sender's measurement of the round-trip time uses DCCP's mechanisms
   for round-trip time measurement.  This includes Elapsed Time and/or
   Timestamp Echo options.  As described in Section 8.2, feedback packets
   must carry an Elapsed Time option; Timestamp Echo is optional.
   The sender maintains an average round-trip time heavily weighted on the
   most recent measurements.  Senders MAY use any available round-trip time
   measurements, including from the initial Request-Response packet exchange,
   to maintain this average.  This differs from [RFC 3448], which constrains
   round-trip time measurements to feedback packets only.

Notes:

Clarification of round-trip time measurement.

Reported By: Eddie Kohler and Sally Floyd, from Gerrit Renker and Arjuna Sathiaseelan

from pending

RFC 4343, "Domain Name System (DNS) Case Insensitivity Clarification", January 2006

Note: This RFC has been updated by RFC 5890

Source of RFC: dnsext (int)

Errata ID: 2647
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sam Bretheim
Date Reported: 2010-11-29
Verifier Name: Brian Haberman
Date Verified: 2012-04-30

Section 2.1 says:

   ("."), which can be expressed as and \046 or \.  It is advisable to

It should say:

   ("."), which can be expressed as \046 or \.  It is advisable to

RFC 4346, "The Transport Layer Security (TLS) Protocol Version 1.1", April 2006

Note: This RFC has been obsoleted by RFC 5246

Note: This RFC has been updated by RFC 4366, RFC 4680, RFC 4681, RFC 5746, RFC 6176, RFC 7465, RFC 7507, RFC 7919

Source of RFC: tls (sec)

Errata ID: 1075
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Eric Rescorla
Date Reported: 2006-02-26

Section 4.7 says:

PKCS #1 block type 0 or type 1, as described in [PKCS1A].

It should say:

PKCS #1 block type 1, as described in [PKCS1A].

Errata ID: 1896
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-05-29
Verifier Name: Pasi Eronen
Date Verified: 2009-10-14

Section 7.2.2 says:

   decryption_failed
      This alert MAY be returned if a TLSCiphertext decrypted in an
      invalid way: either it wasn't an even multiple of the block
      length, or its padding values, when checked, weren't correct.
      This message is always fatal.

   Note: Differentiating between bad_record_mac and decryption_failed
         alerts may permit certain attacks against CBC mode as used in
         TLS [CBCATT].  It is preferable to uniformly use the
         bad_record_mac alert to hide the specific type of the error.

It should say:

   decryption_failed
      This alert was used in TLS version 1.0, and MUST NOT be sent in
      TLS 1.1.

   Note: Differentiating between bad_record_mac and decryption_failed
         alerts may have permitted certain attacks against CBC mode 
         as used in TLS 1.0 [CBCATT].  It is preferable to uniformly 
         use the bad_record_mac alert to hide the specific type of 
         the error.

Notes:

(split off from Errata ID 117 )

The original text contradicted the text for bad_record_mac
("This alert also MUST be returned if an alert is sent because
a TLSCiphertext decrypted in an invalid way").

RFC 4352, "RTP Payload Format for the Extended Adaptive Multi-Rate Wideband (AMR-WB+) Audio Codec", January 2006

Source of RFC: avt (rai)

Errata ID: 114
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-02-07

 

(1)

In Section 4.3.2.3 of RFC 4352, the first formula line on page 18,

      TS(i) = TS(i-1) + (DISi + 1) * frame duration,    2 < i < n

should say:

      TS(i) = TS(i-1) + (DISi + 1) * frame duration,    2 <= i <= n


(2)

The 'Example Algorithm' in Section 4.5.1, on page 27, in the second
half of Step 1, says:

   Return recovered timestamps as
   x(n) = t0 + n*L1 and associated ISF equal to isf0,
   for 0 < n < (t1 - t0)/L0
   goto End

This pseudocode fragment should say:

   for 0 < n < (t1 - t0)/L0
      Return recovered timestamps as
      x(n) = t0 + n*L0 and associated ISF equal to isf0
   goto End


(3)

In Section 7.2, on page 32, the second item of the unnumbered list
says:

   -  The media type (payload format name) is used in SDP "a=rtpmap" as
      the encoding name.  [...]

It should say:

   -  The media subtype (payload format name) is used in SDP "a=rtpmap"
      as the encoding name.  [...]


(4)

Within the second paragraph on page 33, Section 7.2.1 of RFC 4352
says:
                                            [...]  As any receiver will
      be capable of receiving stereo frame type and perform local mixing
      within the AMR-WB+ decoder, there is normally only one reason to
      restrict to mono only: to avoid spending bit-rate on data that are
      not utilized if the front-end is only capable of mono.

It should say:
                                            [...]  As any receiver will
      be capable of receiving stereo frame types and perform local
      mixing within the AMR-WB+ decoder, there is normally only one
      reason to restrict to mono only: to avoid spending bit-rate on
      data that are not utilized if the front-end is only capable of
      mono.

Notes:

from pending

RFC 4357, "Additional Cryptographic Algorithms for Use with GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms", January 2006

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 1473
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Serguei Leontiev
Date Reported: 2008-07-16
Verifier Name: Russ Housley
Date Verified: 2010-03-11

Section 7 says:

This algorithm creates a GOST 28147-89 key Kd, given GOST R 34.10-94
or GOST R 34.10-2001 secret key K and diversification data D of size
4..40 bytes.

It should say:

This algorithm creates a GOST 28147-89 key Kd, produced from given 
256-bit secret key K and diversification data D of size 4..40 bytes.

Notes:

In this place "secret key" means any key, which MUST NOT be used to
protect of raw data. For example, private keys, shared secret keys,
wrap/unwrap keys, etc.

Russian-English terminology translation bug

Errata ID: 5927
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Stanislav Smyshlyaev
Date Reported: 2019-12-06
Verifier Name: Paul Wouters
Date Verified: 2024-01-16

Section 10.6 says:

           Gost28147-89-ParamSet
           FROM Gost28147-89-EncryptionSyntax

...

       GostR3410-94-PublicKeyParameters ::=
           SEQUENCE {
               publicKeyParamSet
                   OBJECT IDENTIFIER (
                       id-GostR3410-94-TestParamSet |
                           -- Only for testing purposes
                       id-GostR3410-94-CryptoPro-A-ParamSet |
                       id-GostR3410-94-CryptoPro-B-ParamSet |
                       id-GostR3410-94-CryptoPro-C-ParamSet |
                       id-GostR3410-94-CryptoPro-D-ParamSet |
                       id-GostR3410-94-CryptoPro-XchA-ParamSet |
                       id-GostR3410-94-CryptoPro-XchB-ParamSet |
                       id-GostR3410-94-CryptoPro-XchC-ParamSet
                   ),
               digestParamSet
                   OBJECT IDENTIFIER (
                       id-GostR3411-94-TestParamSet |
                           -- Only for testing purposes
                       id-GostR3411-94-CryptoProParamSet
                   ),
               encryptionParamSet Gost28147-89-ParamSet OPTIONAL
           }

It should say:

           id-Gost28147-89-CryptoPro-A-ParamSet, Gost28147-89-ParamSet
           FROM Gost28147-89-EncryptionSyntax

...

       GostR3410-94-PublicKeyParameters ::=
           SEQUENCE {
               publicKeyParamSet
                   OBJECT IDENTIFIER (
                       id-GostR3410-94-TestParamSet |
                           -- Only for testing purposes
                       id-GostR3410-94-CryptoPro-A-ParamSet |
                       id-GostR3410-94-CryptoPro-B-ParamSet |
                       id-GostR3410-94-CryptoPro-C-ParamSet |
                       id-GostR3410-94-CryptoPro-D-ParamSet |
                       id-GostR3410-94-CryptoPro-XchA-ParamSet |
                       id-GostR3410-94-CryptoPro-XchB-ParamSet |
                       id-GostR3410-94-CryptoPro-XchC-ParamSet
                   ),
               digestParamSet
                   OBJECT IDENTIFIER (
                       id-GostR3411-94-TestParamSet |
                           -- Only for testing purposes
                       id-GostR3411-94-CryptoProParamSet
                   ),
               encryptionParamSet Gost28147-89-ParamSet DEFAULT
                    id-Gost28147-89-CryptoPro-A-ParamSet
           }

Notes:

The parameters structures of GostR3410-94-PublicKeyParameters defined in RFC 4357 and RFC 4491 that do not match. In RFC4491, a DEFAULT is provided for the 'encryptionParamSet' object identifier, while in RFC 4357, the 'encryptionParamSet' object identifier is OPTIONAL.


---Verifier Notes:---
Paul Wouters (AD): Closed as Verified. There won't be any updates for RFC 4357 as the algorithms are not used anymore.
The current GOST algorithms are defined in RFC 6986, RFC 7801 and RFC 7836.

Errata ID: 5928
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Stanislav Smyshlyaev
Date Reported: 2019-12-06
Verifier Name: Paul Wouters
Date Verified: 2024-01-16

Section 10.8 says:

           Gost28147-89-ParamSet
           FROM Gost28147-89-EncryptionSyntax

...

       GostR3410-2001-PublicKeyParameters ::=
           SEQUENCE {
               publicKeyParamSet
                   OBJECT IDENTIFIER (
                       id-GostR3410-2001-TestParamSet |
                           -- Only for testing purposes
                       id-GostR3410-2001-CryptoPro-A-ParamSet |
                       id-GostR3410-2001-CryptoPro-B-ParamSet |
                       id-GostR3410-2001-CryptoPro-C-ParamSet |
                       id-GostR3410-2001-CryptoPro-XchA-ParamSet |
                       id-GostR3410-2001-CryptoPro-XchB-ParamSet
                   ),
               digestParamSet
                   OBJECT IDENTIFIER (
                       id-GostR3411-94-TestParamSet |
                           -- Only for testing purposes
                       id-GostR3411-94-CryptoProParamSet
                   ),
               encryptionParamSet Gost28147-89-ParamSet OPTIONAL
           }

It should say:

           id-Gost28147-89-CryptoPro-A-ParamSet, Gost28147-89-ParamSet
           FROM Gost28147-89-EncryptionSyntax

...

       GostR3410-2001-PublicKeyParameters ::=
           SEQUENCE {
               publicKeyParamSet
                   OBJECT IDENTIFIER (
                       id-GostR3410-2001-TestParamSet |
                           -- Only for testing purposes
                       id-GostR3410-2001-CryptoPro-A-ParamSet |
                       id-GostR3410-2001-CryptoPro-B-ParamSet |
                       id-GostR3410-2001-CryptoPro-C-ParamSet |
                       id-GostR3410-2001-CryptoPro-XchA-ParamSet |
                       id-GostR3410-2001-CryptoPro-XchB-ParamSet
                   ),
               digestParamSet
                   OBJECT IDENTIFIER (
                       id-GostR3411-94-TestParamSet |
                           -- Only for testing purposes
                       id-GostR3411-94-CryptoProParamSet
                   ),
               encryptionParamSet Gost28147-89-ParamSet DEFAULT
                    id-Gost28147-89-CryptoPro-A-ParamSet
           }

Notes:

The parameters structures of GostR3410-2001-PublicKeyParameters defined in RFC 4357 and RFC 4491 do not match. In RFC4491, a DEFAULT is provided for the 'encryptionParamSet' object identifier, while in RFC 4357, the 'encryptionParamSet' object identifier is OPTIONAL.

---Verifier Notes:---
Paul Wouters (AD): Closed as Verified. There won't be any updates for RFC 4357 as the algorithms are not used anymore.
The current GOST algorithms are defined in RFC 6986, RFC 7801 and RFC 7836.

Errata ID: 1467
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Serguei Leontiev
Date Reported: 2008-07-09
Verifier Name: Russ Housley
Date Verified: 2010-03-11

Section 13.2 says:

   [RFDSL]       "Russian Federal Digital Signature Law", 10 Jan 2002 N
                 1-FZ

It should say:

   [RFDSL]       "Russian Federal Electronic Digital Signature Law",
                 10 Jan 2002 N 1-FZ.

Notes:

Russian-English terminology translation bug

RFC 4360, "BGP Extended Communities Attribute", February 2006

Note: This RFC has been updated by RFC 7153, RFC 7606

Source of RFC: idr (rtg)

Errata ID: 1632
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yakov Rekhter
Date Reported: 2008-12-12
Verifier Name: Stewart Bryant
Date Verified: 2012-02-20

Section 7 says:

      This document defines a class of extended communities called IPv4
   address specific extended community for which the IANA is to create
   and maintain a registry entitled "IPv4 Address Specific Extended
   Community".  All the communities in this class are of extended Types.
   Future assignment are to be made using the "First Come First Served"
   policy defined in [RFC2434].  The Type values for the transitive
   communities of the two-octet AS specific extended community class
   are 0x0100-0x01ff, and for the non-transitive communities of that
   class are 0x4100-0x41ff.  Assignments consist of a name and the
   value.

It should say:

      This document defines a class of extended communities called IPv4
   address specific extended community for which the IANA is to create
   and maintain a registry entitled "IPv4 Address Specific Extended
   Community".  All the communities in this class are of extended Types.
   Future assignment are to be made using the "First Come First Served"
   policy defined in [RFC2434].  The Type values for the transitive
   communities of the IPv4 Address specific extended community class
   are 0x0100-0x01ff, and for the non-transitive communities of that
   class are 0x4100-0x41ff.  Assignments consist of a name and the
   value.

Errata ID: 1917
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yakov Rekhter
Date Reported: 2009-10-19
Verifier Name: Ross Callon
Date Verified: 2009-10-19

Section 6 says:

If a route has a non-transitivity extended community, 

It should say:

If a route has a non-transitive extended community, 

RFC 4361, "Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)", February 2006

Note: This RFC has been updated by RFC 5494

Source of RFC: dhc (int)

Errata ID: 3954
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Samir Sawhney
Date Reported: 2014-04-09
Verifier Name: Ted Lemon
Date Verified: 2014-04-09

Section 7 says:

"Some DHCP servers work around this problem for the common case where
the boot Programmable Read Only Memory (PROM) presents no client
identifier, and the operating system DHCP client presents a client
identifier constructed from the Message Authentication Code (MAC)
address of the network interface..."

It should say:

"Some DHCP servers work around this problem for the common case where
the boot Programmable Read Only Memory (PROM) presents no client
identifier, and the operating system DHCP client presents a client
identifier constructed from the Media Access Control (MAC)
address of the network interface..."

Notes:

The sentence (included above) from Section 7 of RFC 4361 provides an incorrect
expansion of the MAC acronym (Message Authentication Code).

RFC 4364, "BGP/MPLS IP Virtual Private Networks (VPNs)", February 2006

Note: This RFC has been updated by RFC 4577, RFC 4684, RFC 5462

Source of RFC: l3vpn (int)

Errata ID: 3649
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bharat Joshi
Date Reported: 2013-06-12
Verifier Name: Brian Haberman
Date Verified: 2013-06-13

Section 4.3.2 says:

Then if
a route is potentially reachable over more than one attachment
circuit, the PE/CE routing can switch the preferred path for a
route from one attachment circuit to another, without there being
any need to distribute new a label for that route.

It should say:

Then if
a route is potentially reachable over more than one attachment 
circuit, the PE/CE routing can switch the preferred path for a 
route from one attachment circuit to another, without there being 
any need to distribute a new label for that route.

Notes:

'distribute new a label' should be 'distribute a new label'.

RFC 4365, "Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs)", February 2006

Source of RFC: l3vpn (int)

Errata ID: 112
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-20
Verifier Name: ron bonica
Date Verified: 2011-08-01

 

       If these are desired, they must be provided by mechanisms that
       are outside the scope of the VPN mechanisms.  For instance, the
       users can use secure protocols on an end-to-end basis, e.g.,
       IPsec, Secure Shell (SSH), Secure Sockets Layer (SSL), etc.

It should say:

       If these are desired, they must be provided by mechanisms that
       are outside the scope of the VPN mechanisms.  For instance, the
       users can use secure protocols on an end-to-end basis, e.g.,
|      IPsec, Secure Shell (SSH), Transport Layer Security (TLS), etc.
                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

RFC 4367, "What's in a Name: False Assumptions about DNS Names", February 2006

Source of RFC: IAB

Errata ID: 110
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2006-02-26
Verifier Name: RFC Editor
Date Verified: 2007-10-10

Section 3 says:

   >From this model, it is clear that three entities in the system can
   potentially make false assumptions about the service provided by the
   server.

It should say:

   From this model, it is clear that three entities in the system can
   potentially make false assumptions about the service provided by the
   server.

RFC 4368, "Multiprotocol Label Switching (MPLS) Label-Controlled Asynchronous Transfer Mode (ATM) and Frame-Relay Management Interface Definition", January 2006

Source of RFC: mpls (rtg)

Errata ID: 675
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Verifier Name: Adrian Farrel
Date Verified: 2010-10-31

Section 5 says:

    [...].  Note that mplsLcAtmStdUnlabTrafVci and mplsLcAtmStdCtrlVci
   MUST not be equal; nor should mplsLcAtmStdCtrlVpi or
   mplsLcAtmStdUnlabTrafVpi be equal.

It should say:

  Note that the VPI/VCI pair used for unlabeled traffic 
  (mplsLcAtmStdUnlabTrafVpi, mplsLcAtmStdUnlabTrafVci) MUST NOT equal
  the VPI/VIC pair used for control traffic (mplsLcAtmStdCtrlVpi,
  mplsLcAtmStdCtrlVci).

Notes:

The (Vpi, Vci) - *pairs* must not be equal for every
mplsLcAtmStdInterfaceConfEntry.

Errata ID: 105
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Verifier Name: Adrian Farrel
Date Verified: 2010-06-11

Section 2 says:

   C-FR  RFC 3034 defines a label-switching-controlled Frame Relay
         (LC-FR) interface.  Packets traversing such an interface carry
         labels in the DLCI field

   C-ATM RFC 3035 defines a label-switching-controlled ATM (LC-ATM)
         interface as an ATM interface controlled by the label switching
         control component. 

It should say:

   LC-FR
         RFC 3034 defines a label-switching-controlled Frame Relay
         (LC-FR) interface.  Packets traversing such an interface carry
         labels in the DLCI field

   LC-ATM
         RFC 3035 defines a label-switching-controlled ATM (LC-ATM)
         interface as an ATM interface controlled by the label switching
         control component. 

Notes:

The acronyms, "C-FR" and "C-ATM", do not appear elsewhere in the text.
Apparently, the first column has been cut off.

RFC 4377, "Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks", February 2006

Source of RFC: mpls (rtg)

Errata ID: 109
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Verifier Name: Adrian Farrel
Date Verified: 2010-08-21

Section 2.1 says:

   One-hop Delay:             The fixed delay experienced by a packet to
                              reach the next hop resulting from the of
                              the propagation latency, the transmission
                              latency, and the processing latency.

It should say:

   One-hop Delay:             The fixed delay experienced by a packet to
                              reach the next hop resulting from the sum
                              of the propagation latency, the
                              transmission latency, and the processing
                              latency.

Notes:

Fix word omission. Insert "sum"

Errata ID: 676
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Verifier Name: Adrian Farrel
Date Verified: 2010-08-21

Section 4.1 says:

   Furthermore, the automation of path liveliness is desired in cases
   where large numbers of LSPs might be tested.  [...]

It should say:

|  Furthermore, the automation of path liveliness testing is desired in
   cases where large numbers of LSPs might be tested.  [...]

Notes:

Fix word omission. Insert "testing"

Errata ID: 677
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Verifier Name: Adrian Farrel
Date Verified: 2010-08-21

Section 4.11.1 says:

      (1) At an ingress LSR, accounting of traffic through LSPs that
|         begin at each egress in question.
          ^^^^^

      (2) At an intermediate LSR, accounting of traffic through LSPs for
|         each pair of ingress to egress.
                               ^^ 
            v
|     (3) At egress LSR, accounting of traffic through LSPs for each
          ingress.

It should say:

      (1) At an ingress LSR, accounting of traffic through LSPs that
|         end at each egress in question.

      (2) At an intermediate LSR, accounting of traffic through LSPs for
|         each pair of ingress and egress.

|     (3) At an egress LSR, accounting of traffic through LSPs for each
          ingress.

Notes:

Fix wrong wording in bullet (1) [s/begin/end/]

Minor typos in bullets (2) and (3).

Errata ID: 3753
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: RFC Editor
Date Reported: 2013-10-15
Verifier Name: Adrian Farrel
Date Verified: 2013-10-16

In the Authors' Addresses, it says:

Comments should be made directly to the MPLS mailing list
at mpls@lists.ietf.org.

Notes:

This report has been modified from the original report submitted.

'@lists.ietf.org' was changed to '@ietf.org' in the year 2005 so that comments should be made directly to the MPLS mailing list at mpls@ietf.org.

However, this type of statement is typically removed from Internet-Drafts when they are published as RFCs, and it was only the presence of this statement in an unusual place in the document that caused it to be retained.

Therefore, this statement should be removed in entirety.

RFC 4379, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", February 2006

Note: This RFC has been obsoleted by RFC 8029

Note: This RFC has been updated by RFC 5462, RFC 6424, RFC 6425, RFC 6426, RFC 6829, RFC 7506, RFC 7537, RFC 7743

Source of RFC: mpls (rtg)

Errata ID: 108
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Verifier Name: Adrian Farrel
Date Verified: 2010-01-02

Section 3 says:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type = 1 (FEC TLV)       |          Length = 12          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type = 1 (FEC TLV)       |          Length = 32          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

According to Section 3.3 of the LDP specification, RFC 3036,
the Lenght element of LDP TLVs measures the size of the Value
element in bytes.
Therefore, 'Length = 12' is wrong, it should be 'Length = 32'.

from pending

Errata ID: 1418
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Brian Carpenter
Date Reported: 2008-04-30
Verifier Name: Adrian Farrel
Date Verified: 2010-01-02

Section 4.3 says:

   An MPLS echo request is a UDP packet.  The IP header is set as
   follows: the source IP address is a routable address of the sender;
   the destination IP address is a (randomly chosen) IPv4 address from
   the range 127/8 or IPv6 address from the range
   0:0:0:0:0:FFFF:127/104.

It should say:

   An MPLS echo request is a UDP packet.  The IP header is set as
   follows: the source IP address is a routable address of the sender;
   the destination IP address is a (randomly chosen) IPv4 address from
   the range 127/8 or IPv6 address from the range
   0:0:0:0:0:FFFF:7F00/104.

Notes:

The ":127" is ambiguous (intended to be decimal, but could be hexadecimal).
An alternative fix would be 0:0:0:0:0:FFFF:127.0.0.0/104.

This report was corrected 9/15/08 as requested by Brian Carpenter.

Errata ID: 1714
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Yaakov (J) Stein
Date Reported: 2009-03-12
Verifier Name: Adrian Farrel
Date Verified: 2010-01-02

Section 3 says:

Page 6 figure

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Version Number        |         Global Flags          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Message Type |   Reply mode  |  Return Code  | Return Subcode|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Sender's Handle                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Sequence Number                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    TimeStamp Sent (seconds)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  TimeStamp Sent (microseconds)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  TimeStamp Received (seconds)                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                TimeStamp Received (microseconds)              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            TLVs ...                           |
      .                                                               .
      .                                                               .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Page 8 para 6
  The TimeStamp Sent is the time-of-day (in seconds and microseconds,
  according to the sender's clock) in NTP format [NTP] when the MPLS
  echo request is sent.

It should say:

Page 6 figure

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Version Number        |         Global Flags          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Message Type |   Reply mode  |  Return Code  | Return Subcode|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Sender's Handle                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Sequence Number                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    TimeStamp Sent (seconds)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                TimeStamp Sent (seconds fraction)              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  TimeStamp Received (seconds)                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              TimeStamp Received (seconds fraction)            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            TLVs ...                           |
      .                                                               .
      .                                                               .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Page 8 para 6
  The TimeStamp Sent is the time-of-day in NTP format [NTP], 
  according to the sender's clock, when the MPLS echo request is sent.  

Notes:

The text and figure were contradictory since in NTP format the second field
of 32 bits is fractional seconds, not microseconds.

Errata ID: 1786
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jon Chung Hyok
Date Reported: 2009-05-20
Verifier Name: Adrian Farrel
Date Verified: 2009-08-24

Section 4.4 (p. 38) says:

         If the number of labels in the FEC stack is greater
            than or equal to FEC-stack-depth {

It should say:

         If the number of FECs in the FEC stack is greater
            than or equal to FEC-stack-depth {

Notes:

labels -> FECs

Errata ID: 3399
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Fang Lu
Date Reported: 2012-11-06
Verifier Name: Adrian Farrel
Date Verified: 2012-11-23

Section 3.3.1 says:

Those same addresses embedded in IPv6 would be encoded as follows:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 1 1 1 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

Those same addresses embedded in IPv6 would be encoded as follows:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 1 1 1 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

The base IPv6 address should have 16 bytes (128 bits), there are more 4 bytes typed.

RFC 4382, "MPLS/BGP Layer 3 Virtual Private Network (VPN) Management Information Base", February 2006

Source of RFC: l3vpn (int)

Errata ID: 3334
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jeffrey Haas
Date Reported: 2012-09-04
Verifier Name: Brian Haberman
Date Verified: 2012-09-12

Section 7 says:

mplsL3VpnVrfPerfRoutesDropped OBJECT-TYPE
   SYNTAX        Counter32
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
       "This counter should be incremented when the number of routes
        contained by the specified VRF exceeds or attempts to exceed
        the maximum allowed value as indicated by
        mplsL3VpnVrfMaxRouteThreshold.

It should say:

mplsL3VpnVrfPerfRoutesDropped OBJECT-TYPE
   SYNTAX        Counter32
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
       "This counter should be incremented when the number of routes
        contained by the specified VRF exceeds or attempts to exceed
        the maximum allowed value as indicated by
        mplsL3VpnVrfConfHighRteThresh.

Notes:

The variable mplsL3VpnVrfMaxRouteThreshold does not exist in this MIB and is not imported from elsewhere.

The proper reference is mplsL3VpnVrfConfHighRteThresh and the same should be used for the DESCRIPTION clause for mplsL3VpnVrfNumVrfRouteMaxThreshExceeded.

RFC 4384, "BGP Communities for Data Collection", February 2006

Source of RFC: grow (ops)

Errata ID: 4550
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Warren Turkal
Date Reported: 2015-12-01
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2023-02-06

Section 4.1 says:

The chart at the bottom of 4.1:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      0x00     |      0x0008   |           0x2A7C              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      0x00     |      0x00     |           0x10F2              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      0x00     |      0x08     |           0x2A7C              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      0x00     |      0x00     |           0x10F2              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

The second group has a hex value that looks like two octets: "0x0008". If I am interpreting the chart, extended community RFCs, and the extended community IANA registry correctly, the second group should be a single octet (i.e., "0x08").

Also, the same error is in the Section 4.2 chart.

Warren Kumari: I've marked this Verified, and retained the previous rejection note below for transparency.

See registry at: https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml#trans-two-octet-as for details, and also thread at: https://mailarchive.ietf.org/arch/msg/grow/p0NDCuSN8YfvVqG1mlyGv0b3-Ng/




--PREVIOUS VERIFIER NOTES--
The Transitive Two-Octet AS-Specific Extended Community Sub-Types registry specifies the low order byte as it notes:

Reference
[RFC7153]
Note
This registry contains values of the second octet (the "Sub-Type"
field) of an extended community when the value of the first
octet (the "Type" field) is 0x00.

so the diagram which includes both is correct but obviously somewhat hard to read since it contains both bytes. I think this proposed text ads little additional clarity.

RFC 4385, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", February 2006

Note: This RFC has been updated by RFC 5586

Source of RFC: pwe3 (int)

Errata ID: 1743
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Yaakov (J) Stein
Date Reported: 2009-03-26
Verifier Name: Adrian Farrel
Date Verified: 2011-08-03

Section 4, 4.1, 4.2 says:

The sequence number mechanism described here uses a circular unsigned
16-bit number space that excludes the value zero.
...
o The sequence number that follows 65535 (maximum unsigned 16-bit
  number) is one.
...
o If the sequence number on the packet is zero, the sequence
  integrity of the packets cannot be determined.  In this case, the
  received packet is considered to be in order.

It should say:

The sequence number mechanism for all PW types except the TDM PWs 
SAToP [RFC4553], CESoPSN [RFC5086], and TDMoIP [RFC5087] use a 
circular unsigned 16-bit number space that excludes the value zero. 
The sequence numbers for TDM PWs include the value zero.
...
o For all non-TDM PWs the sequence number that follows 65535 
(maximum unsigned 16-bit number) is one.
...
o If the sequence number on a non-TDM-PW packet is zero, the sequence
  integrity of the packets cannot be determined.  In this case, the
  received packet is considered to be in order.

Notes:

The fact that the TDM PWs always require sequence number and do not give a zero value special meaning was well-known and documented in the relevant RFCs. However, this was forgotten in this document and has caused confusion to implementers.

RFC 4388, "Dynamic Host Configuration Protocol (DHCP) Leasequery", February 2006

Note: This RFC has been updated by RFC 6148

Source of RFC: dhc (int)

Errata ID: 3518
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-02
Verifier Name: Ralph Droms
Date Verified: 2013-03-09

Section 6.4.1 says:

(1)  [word omission]

The second paragraph of section 4.2 of RFC 4388 says:

   The DHCP Server MIB effort [DHCPMIB] grew out of traffic engineering
   and troubleshooting activities at large DHCP installations, and is
   primarily intended as a method of gathering performance statistics
   about servers the load presented to them.

It should perhaps better say:

   The DHCP Server MIB effort [DHCPMIB] grew out of traffic engineering
   and troubleshooting activities at large DHCP installations, and is
   primarily intended as a method of gathering performance statistics
|  about servers and the load presented to them.
                ^^^^^


(2)  [improper wording]

RFC 4388 repeatedly talks about

   "[an] IP address most recently accessed by a client"
                                  ^^^^^^^^^^^
where, IMHO, it should talk about

|  "[an] IP address most recently assigned to a client"
                                  ^^^^^^^^^^^
Rationale:
  The client may access any IP address at any time.  Such access
  is mostly unrelated to the protocol described in RFC 4338.

The affected places in the text I found are:
- Section 5, first paragraph of both the second and the third
  bulleted items, on page 10 / 11, respectively;
- Last paragraph on page 17 (within section 6.4.1).


(3)  [incomplete specification]

The second paragraph of Section 6.4.1, on page 17, says:

   In the event that an IP address appears in the "ciaddr" field of a
   DHCPLEASEQUERY message, if that IP address is one managed by the DHCP
   server, then that IP address MUST be set in the "ciaddr" field of a
   DHCPLEASEUNASSIGNED message.

It should in fact say:

   In the event that an IP address appears in the "ciaddr" field of a
   DHCPLEASEQUERY message, if that IP address is one managed by the DHCP
   server, then that IP address MUST be set in the "ciaddr" field of a
|  DHCPRELEASEACTIVE or DHCPLEASEUNASSIGNED message returned.
   ^^^^^^^^^^^^^^^^^^^^^                           ^^^^^^^^^

Rationale:
  From the remaining text, it can be inferred that the "ciaddr"
  field from the DHCPLEASEQUERY message should be copied to an
  DHCPRELEASEACTIVE reply message as well -- cf. section 6.4.2.

IMHO, this copy should be performed generally, i.e. also in the case
described by the subsequent paragraph:

   If the IP address is not managed by the DHCP server, then a
   DHCPLEASEUNKNOWN message must be returned.

that therefore might be amended to say:

   If the IP address is not managed by the DHCP server, then a
|  DHCPLEASEUNKNOWN message MUST be returned, with that IP address
|  set in the "ciaddr" field.

[The original 'must' should be a 'MUST' because the alternatives
are also specified as a 'MUST' -- or else the specification would
be incomplete.]

Taken together, it might be preferable to restate this fact by
only changing the first paragraph cited above as follows, and leave
the second paragraph unchanged with the exception of the 'must':

   In the event that an IP address appears in the "ciaddr" field of a
|  DHCPLEASEQUERY message, then that IP address MUST be set in the
|  "ciaddr" field of any reply returned.

|  If that IP address is one managed by the DHCP server, then it MUST
|  reply with a DHCPRELEASEACTIVE or DHCPLEASEUNASSIGNED message.

   If the IP address is not managed by the DHCP server, then a
|  DHCPLEASEUNKNOWN message MUST be returned.

Please comment on which alternative you prefer.

It should say:

[incomplete specification]

The second paragraph of Section 6.4.1, on page 17, says:

   In the event that an IP address appears in the "ciaddr" field of a
   DHCPLEASEQUERY message, if that IP address is one managed by the DHCP
   server, then that IP address MUST be set in the "ciaddr" field of a
   DHCPLEASEUNASSIGNED message.

It should in fact say:

   In the event that an IP address appears in the "ciaddr" field of a
   DHCPLEASEQUERY message, if that IP address is one managed by the DHCP
   server, then that IP address MUST be set in the "ciaddr" field of a
|  DHCPRELEASEACTIVE or DHCPLEASEUNASSIGNED message returned.
   ^^^^^^^^^^^^^^^^^^^^^                           ^^^^^^^^^

Rationale:
  From the remaining text, it can be inferred that the "ciaddr"
  field from the DHCPLEASEQUERY message should be copied to an
  DHCPRELEASEACTIVE reply message as well -- cf. section 6.4.2.

IMHO, this copy should be performed generally, i.e. also in the case
described by the subsequent paragraph:

   If the IP address is not managed by the DHCP server, then a
   DHCPLEASEUNKNOWN message must be returned.

that therefore might be amended to say:

   If the IP address is not managed by the DHCP server, then a
|  DHCPLEASEUNKNOWN message MUST be returned, with that IP address
|  set in the "ciaddr" field.

[The original 'must' should be a 'MUST' because the alternatives
are also specified as a 'MUST' -- or else the specification would
be incomplete.]

Taken together, it might be preferable to restate this fact by
only changing the first paragraph cited above as follows, and leave
the second paragraph unchanged with the exception of the 'must':

   In the event that an IP address appears in the "ciaddr" field of a
|  DHCPLEASEQUERY message, then that IP address MUST be set in the
|  "ciaddr" field of any reply returned.

|  If that IP address is one managed by the DHCP server, then it MUST
|  reply with a DHCPRELEASEACTIVE or DHCPLEASEUNASSIGNED message.

   If the IP address is not managed by the DHCP server, then a
|  DHCPLEASEUNKNOWN message MUST be returned.

Please comment on which alternative you prefer.

Notes:

Split from errata 104

RFC 4395, "Guidelines and Registration Procedures for New URI Schemes", February 2006

Note: This RFC has been obsoleted by RFC 7595

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 1673
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Larry Masinter
Date Reported: 2009-01-29
Verifier Name: RFC Editor
Date Verified: 2009-01-29

RFC Header

BCP: 115

It should say:

BCP: 35

Notes:

RFC 4395 obsoletes RFC 2717, which was BCP 35. RFC 4395 should have been published as BCP 35 (not BCP 115). Number 115 in the BCP series has been retired.

Authors and AD approved this change.

RFC 4396, "RTP Payload Format for 3rd Generation Partnership Project (3GPP) Timed Text", February 2006

Source of RFC: avt (rai)

Errata ID: 102
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-07

Section 4.1.4 says:

For TYPE 3 units containing the last (trailing) modifier fragment,...

It should say:

For TYPE 3 units containing the complete modifiers,...

Notes:

from pending

RFC 4397, "A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture", February 2006

Source of RFC: ccamp (rtg)

Errata ID: 973
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Steve Conner
Date Reported: 2006-12-16

Section 9 says:

   [RFC3473]        Berger, L., Ed., "Generalized Multi-Protocol Label
                    Switching (GMPLS) Signaling Functional Description",
                    RFC 3471, January 2003.

It should say:

   [RFC3473]        Berger, L., Ed., "Generalized Multi-Protocol Label
                    Switching (GMPLS) Signaling Resource ReserVation
                    Protocol-Traffic Engineering (RSVP-TE) Extensions",
                    RFC 3473, January 2003.

Notes:

from pending

RFC 4404, "Definitions of Managed Objects for Fibre Channel Over TCP/IP (FCIP)", February 2006

Source of RFC: ips (tsv)

Errata ID: 101
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-03

Section 2.1 says:

   The FCIP Entity table contains information about this entity's
   existing instances of FCIP entities.

It should say:

   The FCIP Entity table contains information about this device's
   existing instances of FCIP entities.

Notes:

The present text is almost recursive nonsense.
* Section 2. explains the terminology.
* The DESCRIPTION clause of the fcipEntityInstanceTable OBJECT-TYPE
definition (on page 9) correctly states:

"Information about this FCIP device's existing instances of
FCIP entities."
^^^^^^

from pending

RFC 4408, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1", April 2006

Note: This RFC has been obsoleted by RFC 7208

Note: This RFC has been updated by RFC 6652

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 2250
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Wayne Schlitt
Date Reported: 2006-05-16
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-11

Section B.3 says:

   $ORIGIN _spf.example.com.  mary.mobile-users                   A
   127.0.0.2 fred.mobile-users                   A 127.0.0.2
   15.15.168.192.joel.remote-users     A 127.0.0.2
   16.15.168.192.joel.remote-users     A 127.0.0.2

It should say:

   $ORIGIN _spf.example.com.
   mary.mobile-users                   A 127.0.0.2
   fred.mobile-users                   A 127.0.0.2
   15.15.168.192.joel.remote-users     A 127.0.0.2
   16.15.168.192.joel.remote-users     A 127.0.0.2

Notes:

The DNS zone file example has incorrect line breaks.

RFC 4409, "Message Submission for Mail", April 2006

Note: This RFC has been obsoleted by RFC 6409

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 1078
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stephane Bortzmeyer
Date Reported: 2006-06-26
Verifier Name: Alexey Melnikov
Date Verified: 2009-09-06

Section 7 says:

NO-SOLICITING  Notification of no soliciting MAY       [Msg-Track]

It should say:

NO-SOLICITING  Notification of no soliciting MAY       [No-soliciting]

And a new reference in Section 13:

   [No-soliciting] C. Malamud, "A No Soliciting Simple Mail Transfer
                   Protocol (SMTP) Service Extension", RFC 3865,
                   September 2004.

Notes:

Section 13 says:

[Msg-Track] Allman, E. and T. Hansen, "SMTP Service Extension
for Message Tracking", RFC 3885, September 2004.

Which is not correct for NO-SOLICITING, which is defined in RFC 3865

RFC 4418, "UMAC: Message Authentication Code using Universal Hashing", March 2006

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 3507
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Lucas Clemente Vella
Date Reported: 2013-03-03
Verifier Name: Sean Turner
Date Verified: 2013-03-16

Section Appendix says:

     'a' * 2^25    5109A660  2E2DBC36860A0A5F  72C6388BACE3ACE6FBF062D9

It should say:

     'a' * 2^25    85EE5CAE  FACA46F856E9B45F  A621C2457C0012E64F3FDAE9

Notes:

The test vector for message 'a' * 2^25 is wrong in the RFC. This is a know error already published by the author on the page http://fastcrypto.org/umac/ (direct link: http://fastcrypto.org/umac/rfc4418.errata.txt ), but I am reporting it here because it is neither shown in Errata Search nor triggers the costumary "Errata Exist" alert on RFC's HTML view.

RFC 4419, "Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol", March 2006

Note: This RFC has been updated by RFC 8270

Source of RFC: secsh (sec)

Errata ID: 5567
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tomoyuki Sahara
Date Reported: 2018-12-07
Verifier Name: Paul Wouters
Date Verified: 2023-07-28

Section 3 says:

     byte    SSH_MSG_KEY_DH_GEX_REQUEST

It should say:

     byte    SSH_MSG_KEX_DH_GEX_REQUEST

Notes:

KEY should be KEX.

1. Section 5. defines "SSH_MSG_KEX_DH_GEX_REQUEST".
2. Other messages in RFC4419 have the same prefix "SSH_MSG_KEX_DH_GEX_".
3. RFC5656 defines two messages start with "SSH_MSG_KEX_".

RFC8270 refers to "SSH_MSG_KEY_DH_GEX_REQUEST" and it should be corrected too.

RFC 4427, "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", March 2006

Source of RFC: ccamp (rtg)

Errata ID: 95
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Verifier Name: Dimitri Papadimitriou
Date Verified: 2006-08-14

Section 7.1 says:

   Note that the restoration resources must be pre-computed, must
   be signaled, and may be selected a priori, but may not cross-
   connected.  Thus, the restoration LSP is not able to carry any
   extra-traffic.

It should say:

   Note that the restoration resources must be pre-computed, must
   be signaled, and may be selected a priori, but may not be cross-
   connected.  Thus, the restoration LSP is not able to carry any
   extra-traffic.

Notes:

missing verb

from pending

Errata ID: 743
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Verifier Name: Dimitri Papadimitriou
Date Verified: 2006-08-14

Section 5 says:

   Failure notification phase is used 1) to inform intermediate nodes
   that LSP(s)/span(s) failure has occurred and has been detected and 2)
   to inform the recovery deciding entities (which can correspond to any
   intermediate or end-point of the failed LSP/span) that the
   corresponding LSP/span is not available.

It should say:

|  The failure notification phase is used 1) to inform intermediate
   nodes that LSP(s)/span(s) failure has occurred and has been detected
   and 2) to inform the recovery deciding entities (which can correspond
   to any intermediate or end-point of the failed LSP/span) that the
   corresponding LSP/span is not available.

Notes:

missing article

from pending

Errata ID: 745
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Verifier Name: Dimitri Papadimitriou
Date Verified: 2006-08-14

Section 6.3 says:

   At the egress node, the normal traffic is selected
|  from either its working or one of the protection LSP/span.

   Unprotected extra traffic can be transported over the M protection
|  LSP/span whenever the protection LSPs/spans is not used to carry a
   normal traffic.

It should say:

   At the egress node, the normal traffic is selected
|  from either its working or one of the protection LSPs/spans.

   Unprotected extra traffic can be transported over the M protection
|  LSPs/spans whenever the protection LSPs/spans is not used to carry a
   normal traffic.

Notes:

singular-->plural

from pending

RFC 4428, "Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration)", March 2006

Source of RFC: ccamp (rtg)

Errata ID: 94
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Verifier Name: Dimitri Papadimitriou
Date Verified: 2006-08-14

 

(1)  [missing articles]

In Section 4.1, the third paragraph on page 7 says:

   In pre-OTN networks, a failure may be masked by intermediate O-E-O
   based Optical Line System (OLS), preventing a Photonic Cross-Connect
   (PXC) from detecting upstream failures.  In such cases, failure
   detection may be assisted by an out-of-band communication channel,
   and failure condition may be reported to the PXC control plane.  This
   can be provided by using [RFC4209] extensions that deliver IP
   message-based communication between the PXC and the OLS control
   plane.  [...]

It should say:

|  In pre-OTN networks, a failure may be masked by an intermediate O-E-O
   based Optical Line System (OLS), preventing a Photonic Cross-Connect
   (PXC) from detecting upstream failures.  In such cases, failure
   detection may be assisted by an out-of-band communication channel,
|  and a failure condition may be reported to the PXC control plane.
   This can be provided by using [RFC4209] extensions that deliver IP
   message-based communication between the PXC and the OLS control
   plane.  [...]


(2)  [unexpected break]

Again on page 7, later on in the same paragraph as mentioned above,
the RFC says:

           [...].  If the intermediate OLS supports electrical (digital)
   mechanisms, using the LMP communication channel, these failure
|  conditions are reported to
|
   the PXC and subsequent recovery actions are performed as described in
   Section 5.  As such, from the control plane viewpoint, this mechanism
   turns the OLS-PXC-composed system into a single logical entity, thus
   having the same failure management mechanisms as any other O-E-O
   capable device.

It should say:

           [...].  If the intermediate OLS supports electrical (digital)
   mechanisms, using the LMP communication channel, these failure
|  conditions are reported to the PXC and subsequent recovery actions
   are performed as described in Section 5.  As such, from the control
   plane viewpoint, this mechanism turns the OLS-PXC-composed system
   into a single logical entity, thus having the same failure management
   mechanisms as any other O-E-O capable device.


(3)  [incomplete wording]

At the end of Section 4.1, in the last bullet, on page 8, the RFC says:

     o with out-of-band communication between entities: entities are
       physically separated, but an out-of-band communication channel is
       provided between them (e.g., using [RFCF4204]).

It should say (according to the Verifier):

     o with out-of-band communication between entities: entities are
       physically separated, but an out-of-band communication channel is
|      provided between them (e.g., using LMP [RFC4204]).


(4)  [unexpected blank line]

In Section 5.5.1, the diagram for option '2. Overbooking', near the
bottom of page 22, suffers from an unexpected blank line.

The RFC says:

                    +----- Dedicated (for instance: 1+1, 1:1, etc.)
                    |
                    |
|
                    +----- Shared (for instance: 1:N, M:N, etc.)
                    |
   Level of         |
   Overbooking -----+----- Unprotected (for instance: 0:1, 0:N)

It should say:

                    +----- Dedicated (for instance: 1+1, 1:1, etc.)
                    |
                    |
                    +----- Shared (for instance: 1:N, M:N, etc.)
                    |
   Level of         |
   Overbooking -----+----- Unprotected (for instance: 0:1, 0:N)


(5)  [typo: missing underscore]

In Section 7.2, the second-to-last paragraph on page 29 says:

   In SONET/SDH environments, one typically considers the VT_SPE/LOVC
   and STS SPE/HOVC as independent layers (for example, VT_SPE/LOVC LSP
   uses the underlying STS_SPE/HOVC LSPs as links).  [...]

It should say:

   In SONET/SDH environments, one typically considers the VT_SPE/LOVC
|  and STS_SPE/HOVC as independent layers (for example, VT_SPE/LOVC LSP
   uses the underlying STS_SPE/HOVC LSPs as links).  [...]


(6)  [singular-->plural]

In Section 8, the second-to-last paragraph on page 33 says:

                              [...].  For instance, it is obvious that
   providing a 1+1 LSP protection minimizes the LSP downtime (in case of
|  failure) while being non-scalable and consuming recovery resource
   without enabling any extra-traffic.
                                                                   ^^
It should say:

                              [...].  For instance, it is obvious that
   providing a 1+1 LSP protection minimizes the LSP downtime (in case of
|  failure) while being non-scalable and consuming recovery resources
   without enabling any extra-traffic.


(7)  [singular-->plural]

The third paragraph of Section 8.2, on page 34, says:

                          [...].  Dynamic restoration enables on-demand
   path computation based on the information received through failure
   notification message, and as such, it is more robust with respect to
   the failure scenario scope.

It should say (according to the Verifier):

                          [...].  Dynamic restoration enables on-demand
   path computation based on the information received through failure
|  notification message(s), and as such, it is more robust with respect to
   the failure scenario scope.


(8)  [singular-->plural]

At the bottom of page 35, Section 8.3 of RFC 4428 says:

                          [...].  Recovery schemes, in particular
   restoration, with pre-signaled resource reservation (with or without
   pre-selection) should be capable of reserving an adequate amount of
   resource to ensure recovery from any specific set of failure events,
   such as any single SRLG failure, any two SRLG failures, etc.

It should say:

                          [...].  Recovery schemes, in particular
   restoration, with pre-signaled resource reservation (with or without
   pre-selection) should be capable of reserving an adequate amount of
|  resources to ensure recovery from any specific set of failure events,
   such as any single SRLG failure, any two SRLG failures, etc.


(9)  [punctuation: adjustment for 'logical quoting']

In Section 12.2, some Informative References, as found in the RFC,
do not conform to the RFC style guidelines regarding 'logical quoting'.

E.g., the RFC says, at the bottom of page 44:

   [BOUILLET]   E. Bouillet, et al., "Stochastic Approaches to Compute
                Shared Meshed Restored Lightpaths in Optical Network
|               Architectures," IEEE Infocom 2002, New York City, June
                2002.
                             ^^
It should say:

   [BOUILLET]   E. Bouillet, et al., "Stochastic Approaches to Compute
                Shared Meshed Restored Lightpaths in Optical Network
|               Architectures", IEEE Infocom 2002, New York City, June
                2002.

Similar changes should be applied to the following entries on page 45:

   [DEMEESTER]
   [GLI]
   [KODIALAM1]
   [KODIALAM2]
   [MANCHESTER]
   [T1.105]
   [WANG]
   [G.707]
   [G.709]

and on page 46:

   [G.783]
   [G.798]
   [G.841]
   [G.842]
   [G.874]

Notes:

from pending

RFC 4433, "Mobile IPv4 Dynamic Home Agent (HA) Assignment", March 2006

Source of RFC: mip4 (int)

Errata ID: 898
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kent Leung
Date Reported: 2007-04-11

 

In RFC 4433 paragraph 3.4, the extension is specified as skippable with type=139.  
However the extension is specified in the "Long Extension
Format", which should be used for non-skippable extensions only according
to RFC 3344 paragraph 1.10.

It should say:

The extension should be specified in the "Short Extension Format" which
is used for skippable extensions in accordance to RFC 3344 paragraph
1.11.

Notes:

This problem was reported by László Molnár.

from pending

RFC 4436, "Detecting Network Attachment in IPv4 (DNAv4)", March 2006

Source of RFC: dhc (int)

Errata ID: 91
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bernard Aboba
Date Reported: 2007-01-01

Section 2.1.1 says:

   If a valid ARP Reply is received, the MAC address in the sender
   hardware address field (ar$sha) in the ARP Reply is matched against
   the target hardware address field (ar$tpa) in the ARP Request, and
   the IPv4 address in the sender protocol address field (ar$spa) of the
   ARP Reply is matched against the target protocol address field
   (ar$tpa) in the ARP Request.  If a match is found, then the host
   continues to use that IPv4 address, subject to the lease re-
   acquisition and expiration behavior described in Section 4.4.5 of the
   DHCP specification [RFC2131].

It should say:

   If a valid ARP Reply is received, where:
   
   (a) the address in the sender hardware address field (ar$sha) is
       the MAC address of the node being tested for, and
   (b) the address in the sender protocol address field (ar$spa) is
       the IPv4 address of the node being tested for,
   
   then the host concludes that its candidate IPv4 address is valid
   for this network and may continue to be used, subject to the lease
   re-acquisition and expiration behavior described in Section 4.4.5
   of the DHCP specification [RFC2131].

RFC 4438, "Fibre-Channel Name Server MIB", April 2006

Source of RFC: imss (ops)

Errata ID: 90
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Verifier Name: Keith McCloghrie
Date Verified: 2006-07-10

The DESCRIPTION clause of the t11NsRegClassOfSvc OBJECT-TYPE,on page 16/17, says:

           "The class of service indicator.  This object is an
           array of bits that contain a bit map of the classes of
           service supported by the associated port.  If a bit in
           this object is 1, it indicates that the class of
           service is supported by the associated port.  When a
           bit is set to 0, it indicates that no class of service
           is supported by this Nx_Port.

           If this object has not been not registered for a port,
           then the instance for that port is not instantiated."

It should say:

           "The class of service indicator.  This object is an
           array of bits that contain a bit map of the classes of
           service supported by the associated port.  If a bit in
           this object is 1, it indicates that the class of
           service is supported by the associated port.  When all
           bits are set to 0, it indicates that no class of
           service is supported by this Nx_Port.

           If this object has not been registered for a port,
           then the instance for that port is not instantiated."

RFC 4446, "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", April 2006

Source of RFC: pwe3 (int)

Errata ID: 996
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Danny McPherson
Date Reported: 2007-10-08
Verifier Name: Mark Townsley
Date Verified: 2007-10-08

Section 3.2 says:

   0x0008  SONET/SDH Circuit Emulation Service Over
     MPLS [CEP]

   ...

   0x0010  SONET/SDH Circuit Emulation over Packet [CEP]

It should say:

   0x0008  SONET/SDH Circuit Emulation Service Over
     MPLS Encapsulation [CEM]

  ...

   0x0010  SONET/SDH Circuit Emulation over Packet
     [RFC4842]

Notes:

The 0x0008 value should not have been listed as
allocated to [CEP], now [RFC 4842], only the 0x0010 value is
provided for [CEP]. The 0x0008 value should be associated
with "SONET/SDH Circuit Emulation Service Over MPLS
Encapsulation [CEM]", and a corresponding informative
reference for [CEM] provided.

The IANA PW Type registry has been updated to correct this
error.

RFC 4450, "Getting Rid of the Cruft: Report from an Experiment in Identifying and Reclassifying Obsolete Standards Documents", March 2006

Source of RFC: newtrk (gen)

Errata ID: 84
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sam Weiler
Date Reported: 2006-03-29

Section 8 says:

    This experiment would have been completely useless without
    participation of the members of the old-standards mailing list.
    Most notably, Pekka Savalo, Bob...

It should say:

    This experiment would have been completely useless without
    participation of the members of the old-standards mailing list.
    Most notably, Pekka Savola, Bob...

Notes:

Typo in Pekka Savola's name

RFC 4455, "Definition of Managed Objects for Small Computer System Interface (SCSI) Entities", April 2006

Source of RFC: ips (tsv)

Errata ID: 83
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Verifier Name: Keith McCloghrie
Date Verified: 2006-07-10

Page 66 says:

 --********************** Notifications ******************************
 -- scsiNotifications OBJECT IDENTIFIER ::= { scsiMIB  2 }

It should say:

 --********************** Notifications ******************************
 -- scsiNotifications OBJECT IDENTIFIER ::= { scsiMIB  0 }

Notes:

There are two issues here:

1) a typo in the ASN.1 comments. The correct OID is { scsiMIB 0 } because
that's what the MIB compiler will process, i.e., the MIB compiler will
not process the ASN.1 comment. It is not too late to correct the typo
in the ASN.1 comment.

2) In the development of the MIB, the change to use the OID structure
recommended by Appendix D of RFC 4181 caused the use of
scsiNotificationsPrefix (as the means to include zero in the OIDs of
the notifications) to become no longer necessary, and it would have
been better if it had been removed. But, it is now too late to remove
scsiNotificationsPrefix.

RFC 4458, "Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR)", April 2006

Note: This RFC has been updated by RFC 8119

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rai

Errata ID: 1409
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Francois AUDET
Date Reported: 2008-04-16
Verifier Name: Robert Sparks
Date Verified: 2011-02-07

Section 5 says:

     target-param      =  "target" EQUAL pvalue

     cause-param       =  "cause" EQUAL Status-Code

It should say:

     target-param      =  "target=" pvalue

     cause-param       =  "cause=" Status-Code

Notes:

The definition was too permissive and conflicted with RFC 3261 ABNF (p. 223). Since this parameter is part of the other-param of uri-parameter, only a "=" (i.e, no linear whitespace allowed) and not EQUAL (which allows linear whitespace).

RFC 4462, "Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol", May 2006

Note: This RFC has been updated by RFC 8732, RFC 9142

Source of RFC: secsh (sec)

Errata ID: 4684
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dave Thompson
Date Reported: 2016-05-05
Verifier Name: Benjamin Kaduk
Date Verified: 2020-02-14

Section 8 says:

      The family of SSH key exchange method names beginning with "gss-
      group1-sha1-" and not containing the at-sign ('@'), to name the
      key exchange methods defined in Section 2.3.

It should say:

      The family of SSH key exchange method names beginning with "gss-
      group1-sha1-" and not containing the at-sign ('@'), to name the
      key exchange methods defined in Section 2.3.

      The family of SSH key exchange method names beginning with "gss-
      group14-sha1-" and not containing the at-sign ('@'), to name the
      key exchange methods defined in Section 2.4.

Notes:

The group14-sha1 family of key exchange method names was not listed in the IANA considerations as being registered. The registration is (already) correct in http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-parameters-16

RFC 4468, "Message Submission BURL Extension", May 2006

Note: This RFC has been updated by RFC 5248

Source of RFC: lemonade (app)

Errata ID: 895
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexey Melnikov
Date Reported: 2007-04-11
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-06

Section 5 says:

X.7.8 Trust relationship required

It should say:

X.7.14 Trust relationship required

Notes:

Incorrect Enhanced Status Code. See <http://www.iana.org/assignments/smtp-enhanced-status-codes> for more details.

Errata ID: 896
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexey Melnikov
Date Reported: 2007-04-11
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-06

Section 6 says:

554 5.7.8 URL resolution requires trust relationship

It should say:

554 5.7.14 URL resolution requires trust relationship

Notes:

Incorrect Enhanced Status Code. See <http://www.iana.org/assignments/smtp-enhanced-status-codes> for more details.

RFC 4469, "Internet Message Access Protocol (IMAP) CATENATE Extension", April 2006

Note: This RFC has been updated by RFC 5550

Source of RFC: lemonade (app)

Errata ID: 2002
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mike Abbott
Date Reported: 2010-01-14
Verifier Name: Alexey Melnikov
Date Verified: 2010-04-02

Section 5 says:

   url-resp-text = 1*(%x01-09 /
                      %x0B-0C /
                      %x0E-5B /
                      %x5D-FE) ; Any TEXT-CHAR except "]"

It should say:

   url-resp-text = 1*(%x01-09 /
                      %x0B-0C /
                      %x0E-5C /
                      %x5E-FE) ; Any TEXT-CHAR except "]"

Notes:

The skipped character %x5C is "\" not "]". I think the intent is to omit "]" since url-resp-text is used exclusively inside a [BADURL url-resp-text] response code, and they want to avoid aliasing the closing "]".

Errata ID: 4046
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Chris Newman
Date Reported: 2014-07-10
Verifier Name: Barry Leiba
Date Verified: 2014-07-10

Section Appendix A says:

   S: A003 NO [BADURL "/INBOX;UIDVALIDITY=785799047/;UID=113330;
   section=1.5.9"] CATENATE append has failed, one message expunged

It should say:

   S: A003 NO [BADURL /INBOX;UIDVALIDITY=785799047/;UID=113330;
   section=1.5.9] CATENATE append has failed, one message expunged

Notes:

This example treats the url-resp-text in the badurl-response-code as though it were an astring. It is not: it is a bare imapurl, as stated in section 5:

"The astring in the definition of url and the url-resp-text in the
definition of badurl-response-code each contain an imapurl as defined
by [2]."

The example is incorrect, in that the double quotes should be removed so the url-resp-text is a valid imapurl, and only that.

RFC 4470, "Minimally Covering NSEC Records and DNSSEC On-line Signing", April 2006

Source of RFC: dnsext (int)

Errata ID: 81
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sam Weiler
Date Reported: 2006-05-09

Section 2 says:

             ).com 3600 IN NSEC +.com ( RRSIG NSEC )

It should say:

            \).com 3600 IN NSEC \+.com ( RRSIG NSEC )

Notes:

Line should use the escape characters as defined in RFC 1035.

RFC 4474, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", August 2006

Note: This RFC has been obsoleted by RFC 8224

Source of RFC: sip (rai)

Errata ID: 1055
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Cullen Jennings
Date Reported: 2007-07-12

Section 6 says:

   The verifier processes this certificate
   in the usual ways, including checking that it has not expired, that
   the chain is valid back to a trusted certification authority (CA),
   and that it does not appear on revocation lists.  Once the
   certificate is acquired, it MUST be validated following the
   procedures in RFC 3280 [9].

It should say:

   The verifier processes this certificate in the usual ways,
   including checking that it has not expired, that the chain is valid
   back to a trusted certification authority (CA), and that it does
   not appear on revocation lists.  To fetch certificate chains, the
   certificate can use the SubjectInfoAccess and techniques such as
   RFC 4387 can be used to retrieve the chain.  Once the certificate
   is acquired, it MUST be validated following the procedures in RFC
   3280 [9].

Notes:

insert a new sentence

Errata ID: 1056
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Cullen Jennings
Date Reported: 2007-07-12

Section 6 says:

   This document introduces a new logical role for SIP entities called a
   server.

It should say:

   This document introduces a new logical role for SIP entities called a
   verifier.

Notes:

change server to verifier.

Errata ID: 1057
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Cullen Jennings
Date Reported: 2007-07-12

Section 10.1 says:

   Content-Length: 147

It should say:

   Content-Length: ...

Notes:

There are two places where this occurs in section 10.1.

Errata ID: 1058
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Cullen Jennings
Date Reported: 2007-07-12

Section 9 says:

   Identity = "Identity" HCOLON signed-identity-digest
   signed-identity-digest = LDQUOT 32LHEX RDQUOT

It should say:

   Identity = "Identity" HCOLON signed-identity-digest
   signed-identity-digest = quoted-string

RFC 4480, "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)", July 2006

Source of RFC: simple (rai)

Errata ID: 2960
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Raphael Bossek
Date Reported: 2011-09-07
Verifier Name: Robert Sparks
Date Verified: 2012-02-08

Section 7.2. says:

7.2. Schema Registration for Schema ............................32
     'urn:ietf:params:xml:ns:pidf:status:rpid'

----on the page 32----

7.2.  Schema Registration for Schema
      'urn:ietf:params:xml:ns:pidf:status:rpid'

   URI:  urn:ietf:params:xml:ns:pidf:status:rpid

It should say:

7.2. Schema Registration for Schema ............................32
     'urn:ietf:params:xml:schema:pidf:status:rpid'

----on the page 32----

7.2.  Schema Registration for Schema
      'urn:ietf:params:xml:schema:pidf:status:rpid'

   URI:  urn:ietf:params:xml:schema:pidf:status:rpid

Notes:

The XML Schema sub-namespace is 'urn:ietf:params:xml:schema:pidf:status:rpid' (instead of 'urn:ietf:params:xml:ns:pidf:status:rpid') as registered in the IANA maintained registry at http://www.iana.org/assignments/xml-registry/schema.html

RFC 3688: The IETF XML Registry; Syntax for XML schema sub-namespace define the XML Schema namespace syntax as "urn:ietf:params:xml:schema:<id>".

Errata ID: 3596
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ben Campbell
Date Reported: 2013-04-17
Verifier Name: Gonzalo Camarillo
Date Verified: 2013-04-17

Section 5.1 says:

[There are 8 occurrences of the following element in the schema in section 5.1]   

      <xs:attributeGroup ref="fromUntil"/>

It should say:

[Each occurrence should be replaced with the following]

     <xs:attributeGroup ref="dm:fromUntil"/>

Notes:

fromUntil is imported from the presence data model namespace "urn:ietf:params:xml:ns:pidf:data-model". This schema imports that namespace with a prefix of "dm". (see beginning of section 5.1) The prefix was left off of the "fromUntil" entries.

Errata ID: 1001
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Huang
Date Reported: 2007-09-07

The header on every page says:

RFC 4480                          RIPD                         July 2006

It should say:

RFC 4480                          RPID                         July 2006

RFC 4490, "Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS)", May 2006

Source of RFC: smime (sec)

Errata ID: 1463
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Serguei Leontiev
Date Reported: 2008-07-09
Verifier Name: Russ Housley
Date Verified: 2010-03-11

Section 4.1.1 says:

Using the secret key corresponding to the originatorKey publicKey and
the recipient's public key, the algorithm VKO GOST R 34.10-94 or VKO
GOST R 34.10-2001 (described in [CPALGS]) is applied to produce the
KEK.

It should say:

Using the private key corresponding to the originatorKey publicKey and
the recipient's public key, the algorithm VKO GOST R 34.10-94 or VKO
GOST R 34.10-2001 (described in [CPALGS]) is applied to produce the
KEK.

Notes:

Russian-English terminology translation bug

Errata ID: 1464
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Serguei Leontiev
Date Reported: 2008-07-09
Verifier Name: Russ Housley
Date Verified: 2010-03-11

Section 4.2.1 says:

Using the secret key corresponding to the GostR3410-
TransportParameters ephemeralPublicKey and the recipient's public
key, the algorithm VKO GOST R 34.10-94 or VKO GOST R 34.10-2001
(described in [CPALGS]) is applied to produce the KEK.

It should say:

Using the private key corresponding to the GostR3410-
TransportParameters ephemeralPublicKey and the recipient's public
key, the algorithm VKO GOST R 34.10-94 or VKO GOST R 34.10-2001
(described in [CPALGS]) is applied to produce the KEK.

Notes:

Russian-English terminology translation bug

Errata ID: 5089
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2017-08-18
Verifier Name: Kathleen Moriarty
Date Verified: 2017-08-22

Section 12.1 says:

   [GOSTR341194] "Information technology. Cryptographic Data Security.
                 Hashing function.", GOST R 34.10-94, Gosudarstvennyi
                 Standard of Russian Federation, Government Committee of
                 the Russia for Standards, 1994. (In Russian)

It should say:

   [GOSTR341194] "Information technology. Cryptographic Data Security.
                 Hashing function.", GOST R 34.11-94, Gosudarstvennyi
                 Standard of Russian Federation, Government Committee of
                 the Russia for Standards, 1994. (In Russian)

Notes:

Incorrect standard number.

RFC 4492, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", May 2006

Note: This RFC has been obsoleted by RFC 8422

Note: This RFC has been updated by RFC 5246, RFC 7027, RFC 7919

Source of RFC: tls (sec)

Errata ID: 2389
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Juho Vähä-Herttua
Date Reported: 2010-07-23
Verifier Name: Sean Turner
Date Verified: 2011-03-26

Section 5.4 says:

   point:   This is the byte string representation of an elliptic curve
      point following the conversion routine in Section 4.3.6 of ANSI
      X9.62 [7].  This byte string may represent an elliptic curve point
      in uncompressed or compressed format; it MUST conform to what the
      client has requested through a Supported Point Formats Extension
      if this extension was used.

        enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType;

   ec_basis_trinomial:   Indicates representation of a characteristic-2
      field using a trinomial basis.

   ec_basis_pentanomial:   Indicates representation of a
      characteristic-2 field using a pentanomial basis.

It should say:

   point:   This is the byte string representation of an elliptic curve
      point following the conversion routine in Section 4.3.6 of ANSI
      X9.62 [7].  This byte string may represent an elliptic curve point
      in uncompressed or compressed format; it MUST conform to what the
      client has requested through a Supported Point Formats Extension
      if this extension was used.

        enum {
            ec_basis_trinomial(1), ec_basis_pentanomial(2),
            (255)
        } ECBasisType;

   ec_basis_trinomial:   Indicates representation of a characteristic-2
      field using a trinomial basis.

   ec_basis_pentanomial:   Indicates representation of a
      characteristic-2 field using a pentanomial basis.

Notes:

The ECBasisType enumeration is submitted as part of the ECParameters structure and therefore needs numerical values. It is common to assign numerical values starting from 1 to enums and maximum value of 255 should be enough, since currently there are only two known basis types and it is unlikely to change in the near future.

Errata ID: 3652
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Peter Dettman
Date Reported: 2013-06-13
Verifier Name: Sean Turner
Date Verified: 2013-08-14

Section 5.4 says:

ECBasisType basis;
select (basis) {
    case ec_trinomial:
        opaque  k <1..2^8-1>;
    case ec_pentanomial:
        opaque  k1 <1..2^8-1>;
        opaque  k2 <1..2^8-1>;
        opaque  k3 <1..2^8-1>;
};

It should say:

ECBasisType basis;
select (basis) {
    case ec_basis_trinomial:
        opaque  k <1..2^8-1>;
    case ec_basis_pentanomial:
        opaque  k1 <1..2^8-1>;
        opaque  k2 <1..2^8-1>;
        opaque  k3 <1..2^8-1>;
};

Notes:

ECBasisType is earlier introduced as:
enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType;

The cases of the select statement should spell the enum elements correctly.

{spt} Related to: http://www.rfc-editor.org/errata_search.php?eid=2389

Errata ID: 4783
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Florent Tatard
Date Reported: 2016-08-19
Verifier Name: Kathleen Moriarty
Date Verified: 2016-08-24

Section 5.7 says:

Actions of the sender:

   The client selects an ephemeral ECDH public key corresponding to the
   parameters it received from the server according to the ECKAS-DH1
   scheme from IEEE 1363 [6].  It conveys this information to the client
   in the ClientKeyExchange message using the format defined above.

It should say:

Actions of the sender:

   The client selects an ephemeral ECDH public key corresponding to the
   parameters it received from the server according to the ECKAS-DH1
   scheme from IEEE 1363 [6].  It conveys this information to the server
   in the ClientKeyExchange message using the format defined above.

Notes:

The client conveys data to the server, not itself.

RFC 4501, "Domain Name System Uniform Resource Identifiers", May 2006

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 78
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yitzchak M. Gottlieb
Date Reported: 2006-05-23

Section 3 says:

   In particular, the "dnsname" field of the DNS URI is to be
   considered an internationalized domain name (IDN) unaware
   domain name slot, in the terminology of RFC 3940 [14].

It should say:

   In particular, the "dnsname" field of the DNS URI is to be
   considered an internationalized domain name (IDN) unaware
   domain name slot, in the terminology of RFC 3490 [14].

Notes:

Reference 14 is RFC 3490 not RFC 3940.

RFC 4502, "Remote Network Monitoring Management Information Base Version 2", May 2006

Source of RFC: rmonmib (ops)

Errata ID: 77
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-06-28

 

(1)  clarification

The RFC 4502 text in Section 2.2, under bullet 3), on page 5,
says:

         Bit     Definition

         6       For WAN media, this bit is set for packets
                 coming from one direction and cleared for
                 packets coming from the other direction.
                 It is an implementation-specific matter
|                as to which bit is assigned to which
                 direction, but it must be consistent for
                 all packets received by the agent.  [...]

This text certainly is intended to always (and only) cover bit #6.
Therefore, the wording, "which bit is assigned" is misleading;
it should be "which [bit] value is assigned".

Thus, the above snippit sould better say:

         Bit     Definition

         6       For WAN media, this bit is set for packets
                 coming from one direction and cleared for
                 packets coming from the other direction.
                 It is an implementation-specific matter
|                as to which bit value is assigned to which
                 direction, but it must be consistent for
                 all packets received by the agent.  [...]


(2)  Ref. issue

In Section 3.2, the third paragraph on page 9 says:

   In the RMON MIB [RFC2819], the EntryStatus textual convention was
   introduced to provide this mutual exclusion function.  Since then,
   this function was added to the SNMP framework as the RowStatus
   textual convention.  The RowStatus textual convention is used for the
   definition of all new tables.

This text unfortunately has turned wrong by updating the (obsolete)
reference "[RFC1757]" (in RFC 2102) to "[RFC2819]".
(-- A very unusual event! --)
The text in RFC 2102 was correct, because RFC 1757 predates the
invention of the 'RowStatus' TC which was finalized in STD 58.
But STD 58 predates RFC 2819, and therefore, the clause,
     vvvvvvvvvv
|    Since then,
     this function was added to the SNMP framework
     as the RowStatus textual convention.
has turned wrong by the replacement of the Ref.!

(NOTE: RFC 2819 in fact still makes use of the 'EntryStatus' TC,
 which already had been introduced in RFC 1271, the predecessor
 of RFC 1757 !)

To correct this issue without causing a need to update the
References of RFC 4502 as well, I propose the following substitute
text as an Erratum for the text snippit above:

          vvvvvvvvvvvvvvvvvvvv
|  In the predecessors of the RMON MIB [RFC2819], the EntryStatus
   textual convention was introduced to provide this mutual exclusion
   function.  Since then, this function was added to the SNMP framework
   as the RowStatus textual convention.  The RowStatus textual
   convention is used for the definition of all new tables.


(3)  outdated Ref.

The DESCRIPTION clause of the protocolDirID OBJECT-TYPE,
on page 21/22 of RFC 4502, says:

    DESCRIPTION
        "A unique identifier for a particular protocol.  Standard
        identifiers will be defined in such a manner that they
<< page break >>
        can often be used as specifications for new protocols - i.e.,
        a tree-structured assignment mechanism that matches the
        protocol encapsulation 'tree' and that has algorithmic
        assignment mechanisms for certain subtrees.  See RFC 2074 for
        more details.

        [...]

RFC 2074 has been obsoleted by RFC 2895 and RFC 2896.
Therefore, the last sentence of this paragraph should better say:

                                             [...].  See RFC 2895 and
        RFC 2896 for more details.


(4)  MIB indexing issue #1

As stated in the text added by RFC 4502 to the DESCRIPTION clause
of the addressMapEntry OBJECT-TYPE, the addressMapTable might run
in problems due to the cumulative length of its index object
instances.

Therefore, I suspect that it might have been better to replace the
last index object, addressMapSource, by an object mirroring the
addressMapControlIndex object (direct use of addressMapControlIndex
as the *last* index object might not be considered a valid option).

NOTE:
I know that it it too late now for any change, unfortunately.


(5)  MIB indexing issue #2

The DESCRIPTION clause of the TimeFilter TEXTUAL-CONVENTION,
on page 16, explains that an index object of type TimeFilter
should be included as the *first* INDEX component for a time-
filtered table:

      A time-filtered conceptual table is created by inserting a
      single object of SYNTAX TimeFilter as the first INDEX component
      in a copy of an existing basic conceptual table (i.e., any
      SEQUENCE without a TimeFilter INDEX component).  [...]

The RMON2 MIB does not follow this rule for the following tables:
  - nlHostTable,
  - nlMatrixSDTable,
  - nlMatrixDSTable,
  - alHostTable,
  - alMatrixSDTable, and
  - alMatrixDSTable.

Since there are arguably good reasons for the present indexing
structure of these tables, it might perhaps have been better
to have the above DESCRIPTION of the TC modified to accommodate
for the existing practice.


(6)  textual issue

The first paragraph of the DESCRIPTION clause for the
alMatrixTopNControlRateBase OBJECT-TYPE, on page 78, says:

        "This object controls which alMatrix[SD/DS] entry that the
        alMatrixTopNEntries are sorted by, which view of the matrix
        table that will be used, as well as which table the results
        will be reported in.

It should perhaps better say (deleting 2 x 'that'):

|       "This object controls which alMatrix[SD/DS] entry the
        alMatrixTopNEntries are sorted by, which view of the matrix
|       table will be used, as well as which table the results
        will be reported in.


(7)  wrong numerical limits in ASN.1 comment

The ASN.1 comments on the User History Collection Group,
in the second paragraph on page 86, says:

-- A sample value is stored in two objects - an absolute value and
-- a status object.  This allows numbers from -(2G-1) to +4G to be
-- stored.  The status object also indicates whether a sample is
-- valid.  This allows data collection to continue if periodic
-- retrieval of a particular instance fails for any reason.

Based on the specification of usrHistoryAbsValue and
usrHistoryValStatus (on page93/94), I strongly suspect that the
specified limits are wrong, and that this text should say:

-- A sample value is stored in two objects - an absolute value and
-- a status object.  This allows numbers from -(4G-1) to +(4G-1) to
-- be stored.  The status object also indicates whether a sample is
-- valid.  This allows data collection to continue if periodic
-- retrieval of a particular instance fails for any reason.


(8)  inappropriate semantics specified in DESCRIPTION text
     for objects in the usrHistoryControlTable

The DESCRIPTION clause of the usrHistoryControlBucketsRequested and
usrHistoryControlBucketsGranted objects (on page 87/88) seem to be
garbled a bit.

The latter contains the (3rd) paragraph:

        The associated usrHistoryControlBucketsRequested object
        should be set before or at the same time as this object
        to allow the probe to accurately estimate the resources
        required for this usrHistoryControlEntry.

This makes no sense here, because the usrHistoryControlBucketsGranted
object is read-only, and hence cannot be set.

I strongly suspect that a similar coupling in fact is needed
for the usrHistoryControlObjects object in relation to the
usrHistoryControlBucketsRequested object:
The probe cannot estimate the internal resource requirements,
and hence determine the value of usrHistoryControlBucketsGranted
without knowing the values of both the usrHistoryControlObjects
and the usrHistoryControlBucketsRequested objects in a row.

Therefore, I suspect that the above paragraph should be deleted,
and re-inserted with a slight modification as the new second
paragraph into the usrHistoryControlBucketsRequested DESCRIPTION
clause, saying:
                                        vvvvvvv
|       The associated usrHistoryControlObjects object
        should be set before or at the same time as this object
        to allow the probe to accurately estimate the resources
        required for this usrHistoryControlEntry.

(I intentionally have omitted the appropriate line re-folding
 here for clarity.)


(9)  two typos

The DESCRIPTION clause of the ControlString TEXTUAL-CONVENTION,
on page 95, contains two typos:

The paragraph:

           ^w  Wait for the reply string that follows, which is
               terminated by the next command or the end of string.
               Partial and case-insensitive matching is applied, i.e.,
               if the reply string (any case combination) is found
               anywhere in the received string, then the a match is
               found.  If the current timeout elapses without a match,
               then the remaining control string is ignored.

should say (deleting 'the' in 'the a') :

           ^w  Wait for the reply string that follows, which is
               terminated by the next command or the end of string.
               Partial and case-insensitive matching is applied, i.e.,
               if the reply string (any case combination) is found
|              anywhere in the received string, then a match is found.
               If the current timeout elapses without a match, then
               the remaining control string is ignored.

The 4th-to-last line of page 95,

           ^    0x1C

should say:

           ^\    0x1C


(10)  textual clarification

In the Appendix of RFC 4502 (Section 8), the paragraph below
the pseudo-code on page 133 says:

   The agent applies this function regardless of the lastActivationTime
   of the conceptual row in question.  In other words, counter
   discontinuities are ignored (i.e., a conceptual row is deleted and
   then re-created later).  An agent should consider an object instance
   'changed' when it is created (either at restart time for scalars and
   static objects, or row-creation-time for dynamic tables).

It should better say:

   The agent applies this function regardless of the lastActivationTime
   of the conceptual row in question.  In other words, counter
|  discontinuities (e.g., a conceptual row is deleted and then re-
|  created later) are ignored.  An agent should consider an object
   instance 'changed' when it is created (either at restart time for
   scalars and static objects, or row-creation-time for dynamic tables).

Notes:

from pending

RFC 4503, "A Description of the Rabbit Stream Cipher Algorithm", May 2006

Source of RFC: INDEPENDENT

Errata ID: 2504
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Justin Harrison
Date Reported: 2010-08-27
Verifier Name: Nevil Brownlee
Date Verified: 2013-05-23

Section Appendix B says:

B.1.  Testing Round Function and Key Setup

     key  = [91 28 13 29 2E ED 36 FE 3B FC 62 F1 DC 51 C3 AC]

[...]

B.2.  Testing the IV Setup

     key  = [91 28 13 29 2E ED 36 FE 3B FC 62 F1 DC 51 C3 AC]

It should say:

B.1.  Testing Round Function and Key Setup

     key  = [91 28 13 29 2E 3D 36 FE 3B FC 62 F1 DC 51 C3 AC]

[...]

B.2.  Testing the IV Setup

     key  = [91 28 13 29 2E 3D 36 FE 3B FC 62 F1 DC 51 C3 AC]

Notes:

There is a typographical error in the example key used in sections B.1 and B.2. As a result of this error, the key does not match the examples.

The correct key values appear in Appendix A.

Errata ID: 5341
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Wolfgang Keller
Date Reported: 2018-04-28
Verifier Name: Adrian Farrel
Date Verified: 2018-04-30

Section A.2. says:

     mkey = [00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00]

It should say:

     key  = [00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00]

Notes:

The letter combination "mkey" for the key is only used in section "A.2. Testing with IV Setup" and nowhere else. In sections A.1, B.1 and B.2 instead consistently "key" is used. So I assume that the additional "m" is a typo. To retain formatting, an additional space is added after "key" as in sections A.1, B.1 and B.2.

RFC 4510, "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", June 2006

Source of RFC: ldapbis (app)

Errata ID: 7215
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-10-31
Verifier Name: RFC Editor
Date Verified: 2022-10-31

Section 3 says:

   [RFC4511] replaces the majority RFC 2251, portions of RFC 2252, and

It should say:

   [RFC4511] replaces the majority of RFC 2251, portions of RFC 2252,
   and

Notes:

Missing "of".

RFC 4511, "Lightweight Directory Access Protocol (LDAP): The Protocol", June 2006

Source of RFC: ldapbis (app)

Errata ID: 7216
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-10-31
Verifier Name: RFC Editor
Date Verified: 2022-11-01

Section 4.1.6 says:

   the value syntax.  See objectIdentiferFirstComponentMatch in

It should say:

   the value syntax.  See objectIdentifierFirstComponentMatch in

Notes:

Typo.

Errata ID: 7217
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-11-01
Verifier Name: RFC Editor
Date Verified: 2022-11-01

Section 4.1.11 says:

   - direction as to what value the sender should provide for the
     criticality field (note: the semantics of the criticality field are
     defined above should not be altered by the control's
     specification),

It should say:

   - direction as to what value the sender should provide for the
     criticality field (note: the semantics of the criticality field
     defined above should not be altered by the control's
     specification),

Notes:

Erroneous "are".

Errata ID: 7218
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-11-01
Verifier Name: RFC Editor
Date Verified: 2022-11-01

Section 4.4 says:

   choice using the ExtendedResponse type (See Section 4.12).  The

It should say:

   choice using the ExtendedResponse type (see Section 4.12).  The

Notes:

The word "see" should not be capitalized here.

Errata ID: 7219
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-11-01
Verifier Name: RFC Editor
Date Verified: 2022-11-01

Section 4.4 says:

   - the OBJECT IDENTIFIER assigned to the notification (to be specified
     in the responseName,

It should say:

   - the OBJECT IDENTIFIER assigned to the notification (to be specified
     in the responseName),

Notes:

Missing parenthesis.

Errata ID: 7220
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-11-01
Verifier Name: RFC Editor
Date Verified: 2022-11-01

Section 8 says:

   [RFC4512]     Zeilenga, K., Lightweight Directory Access Protocol
                 (LDAP): Directory Information Models", RFC 4512, June
                 2006.

It should say:

   [RFC4512]     Zeilenga, K., "Lightweight Directory Access Protocol
                 (LDAP): Directory Information Models", RFC 4512, June
                 2006.

Notes:

Missing quotation mark.

Errata ID: 7221
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-11-01
Verifier Name: RFC Editor
Date Verified: 2022-11-01

Section A.2 says:

         the code may used to indicate an alias has been dereferenced
         that names no object.

It should say:

         the code may be used to indicate an alias has been
         dereferenced that names no object.

Notes:

Missing "be".

Errata ID: 7222
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-11-01
Verifier Name: RFC Editor
Date Verified: 2022-11-01

Section C.1.17 says:

   - The SubstringFilter substrings 'initial, 'any', and 'final' types
     are now AssertionValue rather than LDAPString.  Also, added

It should say:

   - The SubstringFilter substrings 'initial', 'any', and 'final'
     types are now AssertionValue rather than LDAPString.  Also, added

Notes:

Missing quotation mark.

RFC 4512, "Lightweight Directory Access Protocol (LDAP): Directory Information Models", June 2006

Source of RFC: ldapbis (app)

Errata ID: 5261
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jonathan Giddy
Date Reported: 2018-02-12
Verifier Name: Orie Steele
Date Verified: 2024-03-29

Section 6.1 says:

And where a server is unable (or
unwilling) to preserve the value of user information, the server
SHALL ensure that an equivalent value (per Section 2.3) is returned.

It should say:

And where a server is unable (or
unwilling) to preserve the value of user information, the server
SHALL ensure that an equivalent value (per Section 2.2) is returned.

Notes:

The concept of equivalent values is defined in Section 2.2 of RFC 4512. Section 2.3 does not mention equivalent values.

Errata ID: 7224
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-11-01
Verifier Name: RFC Editor
Date Verified: 2022-11-01

Section 2.3.3 says:

   An alias, or alias name, is "an name for an object, provided by the

It should say:

   An alias, or alias name, is a "name for an object, provided by the

Notes:

Wrong form of the indefinite article (the cited source has "an alternative name").

Errata ID: 7225
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-11-01
Verifier Name: RFC Editor
Date Verified: 2022-11-01

Section 5.1.3/5.1.4/5.1.5 says:

   Procedures for registering object identifiers used to discovery of
   protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520].

It should say:

   Procedures for registering object identifiers used for discovery of
   protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520].

Notes:

Either "used for discovery of protocol mechanisms" or "used to discover protocol mechanisms" would be correct.

Errata ID: 7226
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-11-01
Verifier Name: RFC Editor
Date Verified: 2022-11-01

Section A.1.4 says:

   The Section 6.1 and the second paragraph of Section 6.2 of RFC 2251
   where incorporated into this document.

It should say:

   The Section 6.1 and the second paragraph of Section 6.2 of RFC 2251
   were incorporated into this document.

Notes:

Misspelling.

Errata ID: 7227
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-11-01
Verifier Name: RFC Editor
Date Verified: 2022-11-01

Section A.2.2 says:

   Definitions of operational attributes provided in Section 5 of RFC
   2252 where incorporated into this document.

It should say:

   Definitions of operational attributes provided in Section 5 of RFC
   2252 were incorporated into this document.

Notes:

Misspelling.

Errata ID: 7228
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-11-01
Verifier Name: RFC Editor
Date Verified: 2022-11-01

Section A.2. says:

   'extensibleObject' object classes.  These definitions where
   integrated into Section 4.2 and Section 4.3 of this document,

It should say:

   'extensibleObject' object classes.  These definitions were
   integrated into Section 4.2 and Section 4.3 of this document,

Notes:

Misspelling.

RFC 4513, "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", June 2006

Note: This RFC has been updated by RFC 8996

Source of RFC: ldapbis (app)

Errata ID: 7230
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-11-01
Verifier Name: RFC Editor
Date Verified: 2022-11-15

Section 6.3.3 says:

   support a policy mechanism that at the time of authentication or
   password modification, requires that:

It should say:

   support a policy mechanism that, at the time of authentication or
   password modification, requires that:

Notes:

Missing comma.

Errata ID: 7231
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-11-01
Verifier Name: RFC Editor
Date Verified: 2022-11-01

Section A.2 says:

   requested, time of day, etc..  Some factors may be specific to the

It should say:

   requested, time of day, etc.  Some factors may be specific to the

Notes:

No additional period should be used after the abbreviation.

RFC 4514, "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", June 2006

Source of RFC: ldapbis (app)

Errata ID: 7229
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-11-01
Verifier Name: RFC Editor
Date Verified: 2022-11-01

Section 2.4 says:

   AttributeValue is represented by an number sign ('#' U+0023)

It should say:

   AttributeValue is represented by a number sign ('#' U+0023)

Notes:

Wrong form of the indefinite article.

RFC 4517, "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", June 2006

Source of RFC: ldapbis (app)

Errata ID: 4653
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Emmanuel Lecharny
Date Reported: 2016-03-31
Verifier Name: Barry Leiba
Date Verified: 2016-03-31

Section 4.2 says:

4.2.  Matching Rule Definitions

   Nominated character strings in assertion and attribute values are
   prepared according to the string preparation algorithms [RFC4518] for
   LDAP when evaluating the following matching rules:

      numericStringMatch,
      numericStringSubstringsMatch,
      caseExactMatch,
      caseExactOrderingMatch,
      caseExactSubstringsMatch,
      caseExactIA5Match,
      caseIgnoreIA5Match,
      caseIgnoreIA5SubstringsMatch,
      caseIgnoreListMatch,
      caseIgnoreListSubstringsMatch,
      caseIgnoreMatch,
      caseIgnoreOrderingMatch,
      caseIgnoreSubstringsMatch,
      directoryStringFirstComponentMatch,
      telephoneNumberMatch,
      telephoneNumberSubstringsMatch and
      wordMatch.

It should say:

4.2.  Matching Rule Definitions

   Nominated character strings in assertion and attribute values are
   prepared according to the string preparation algorithms [RFC4518] for
   LDAP when evaluating the following matching rules:

      numericStringMatch,
      numericStringOrderingMatch,
      numericStringSubstringsMatch,
      caseExactMatch,
      caseExactOrderingMatch,
      caseExactSubstringsMatch,
      caseExactIA5Match,
      caseIgnoreIA5Match,
      caseIgnoreIA5SubstringsMatch,
      caseIgnoreListMatch,
      caseIgnoreListSubstringsMatch,
      caseIgnoreMatch,
      caseIgnoreOrderingMatch,
      caseIgnoreSubstringsMatch,
      directoryStringFirstComponentMatch,
      telephoneNumberMatch,
      telephoneNumberSubstringsMatch and
      wordMatch.

Notes:

The 'numericStringOrderingMatch' matching rule should be in the list of Matching Rules that are prepared accordingly to RFC 4518.

In 4.2.23, a reference to the String Preparation algorithm is made :

"In preparing the attribute value and assertion value for comparison,
characters are not case folded in the Map preparation step, and only
numericString Insignificant Character Handling is applied in the
Insignificant Character Handling step."

RFC 4518, "Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation", June 2006

Source of RFC: ldapbis (app)

Errata ID: 860
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Stephane PERBELLINI
Date Reported: 2007-02-23
Verifier Name: Kurt Zeilenga
Date Verified: 2007-02-23

Section 2.2 says:

   COMBINING GRAPHEME JOINER (U+034F) and VARIATION SELECTORs 
   (U+180B-180D, FF00-FE0F) code points are also mapped to nothing. 

It should say:

   COMBINING GRAPHEME JOINER (U+034F) and VARIATION SELECTORs 
   (U+180B-180D, FE00-FE0F) code points are also

Notes:

FF00-FE0F should be FE00-FE0F

from pending

Errata ID: 1757
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Steven Legg
Date Reported: 2009-04-05
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-20

Section 2.6.1 says:

Otherwise, the following steps are taken:

It should say:

Otherwise, the following steps are taken:

   - Any inner (non-empty) sequence of space characters is replaced
     with exactly two SPACE characters;

Errata ID: 1758
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Steven Legg
Date Reported: 2009-04-05
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-20

Section 2.6.1 says:

As an any or final substring,
the same input would result in "foo<SPACE>bar<SPACE>".

It should say:

As an any or final substring,
the same input would result in "foo<SPACE><SPACE>bar<SPACE>".

Errata ID: 7213
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-10-31
Verifier Name: RFC Editor
Date Verified: 2022-11-15

Section 2.6.1 says:

   "foo<SPACE>bar<SPACE><SPACE>", result in the output

It should say:

   "foo<SPACE>bar<SPACE><SPACE>" result in the output

Notes:

Unnecessary comma.

RFC 4519, "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", June 2006

Source of RFC: ldapbis (app)

Errata ID: 6974
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jesse Coretta
Date Reported: 2022-05-17
Verifier Name: Orie Steele
Date Verified: 2024-03-29

Section 3.13 says:

3.13.  'residentialPerson'

   The 'residentialPerson' object class is the basis of an entry that
   includes a person's residence in the representation of the person.
   (Source: X.521 [X.521])

      ( 2.5.6.10 NAME 'residentialPerson'
         SUP person
         STRUCTURAL
         MUST l
         MAY ( businessCategory $ x121Address $ registeredAddress $
               destinationIndicator $ preferredDeliveryMethod $
               telexNumber $ teletexTerminalIdentifier $
               telephoneNumber $ internationalISDNNumber $
               facsimileTelephoneNumber $ preferredDeliveryMethod $
               street $ postOfficeBox $ postalCode $ postalAddress $
               physicalDeliveryOfficeName $ st $ l ) )

It should say:

3.13.  'residentialPerson'

   The 'residentialPerson' object class is the basis of an entry that
   includes a person's residence in the representation of the person.
   (Source: X.521 [X.521])

      ( 2.5.6.10 NAME 'residentialPerson'
         SUP person
         STRUCTURAL
         MUST l
         MAY ( businessCategory $ x121Address $ registeredAddress $
               destinationIndicator $ preferredDeliveryMethod $
               telexNumber $ teletexTerminalIdentifier $
               telephoneNumber $ internationalISDNNumber $
               facsimileTelephoneNumber $ preferredDeliveryMethod $
               street $ postOfficeBox $ postalCode $ postalAddress $
               physicalDeliveryOfficeName $ st ) )

Notes:

The "l" attributeType (a.k.a "localityName", as defined in section 2.16 of this same document) is defined in this class in ambiguous fashion. "l" is declared as both required (MUST) and permitted (MAY). It should be removed from the MAY clause.

It is also worth pointing out this flaw is limited solely to this RFC, as the original residentialPerson definition defined within the ITU-T X.521 document (section 6.10) is indeed correct. The "localityName" attribute type is not listed in ambiguous fashion.

Errata ID: 7208
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-10-31
Verifier Name: RFC Editor
Date Verified: 2022-10-31

Section 3.3 says:

   The 'dcObject' object class permits an entry to contains domain

It should say:

   The 'dcObject' object class permits an entry to contain domain

Notes:

Wrong verb form.

Errata ID: 7209
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-10-31
Verifier Name: RFC Editor
Date Verified: 2022-10-31

Section 3.14 says:

   The 'uidObject' object class permits an entry to contains user

It should say:

   The 'uidObject' object class permits an entry to contain user

Notes:

Wrong verb form.

Errata ID: 7210
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-10-31
Verifier Name: RFC Editor
Date Verified: 2022-10-31

Section 2.21 says:

            mailing list object, would be the DN of the director (role):

It should say:

            mailing list object would be the DN of the director (role):

Notes:

Unnecessary comma.

Errata ID: 7211
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-10-31
Verifier Name: RFC Editor
Date Verified: 2022-10-31

Section 2.19 says:

   Examples: "Widget", "Widget, Inc.", and "Widget, Incorporated.".

It should say:

   Examples: "Widget", "Widget, Inc.", and "Widget, Incorporated".

Notes:

The name "Widget, Incorporated" should be written without a period.

Errata ID: 7212
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-10-31
Verifier Name: RFC Editor
Date Verified: 2022-11-01

Section 2.5 says:

             1pm.", and "distribution list for all technical staff".

It should say:

             1 p.m.", and "distribution list for all technical staff".

Notes:

Missing space and period.

RFC 4520, "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", June 2006

Source of RFC: ldapbis (app)

Errata ID: 7207
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-10-31
Verifier Name: RFC Editor
Date Verified: 2022-10-31

Section .6 says:

   [RFC4511.  The protocolOp CHOICE indicates the type of message

It should say:

   [RFC4511].  The protocolOp CHOICE indicates the type of message

Notes:

A closing bracket is missing.

RFC 4521, "Considerations for Lightweight Directory Access Protocol (LDAP) Extensions", June 2006

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 7206
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-10-30
Verifier Name: RFC Editor
Date Verified: 2022-10-31

Section 3.1 says:

   operation defined in [RFC4511] (e.g., search, modify) , an extended

It should say:

   operation defined in [RFC4511] (e.g., search, modify), an extended

Notes:

Space before comma.

RFC 4523, "Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates", June 2006

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 4074
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Emmanuel Lécharny
Date Reported: 2014-08-07
Verifier Name: Barry Leiba
Date Verified: 2014-09-17

Section 3.7 says:

      ( 2.5.13.40 NAME 'algorithmIdentifier'
           DESC 'X.509 Algorithm Identifier Match'
           SYNTAX 1.3.6.1.1.15.7 )

It should say:

      ( 2.5.13.40 NAME 'algorithmIdentifierMatch'
           DESC 'X.509 Algorithm Identifier Match'
           SYNTAX 1.3.6.1.1.15.7 )

Notes:

The name should be 'algorithmIdentifierMatch', in order to be used in section 4.7 as an EQUALITY MatchingRule.

Errata ID: 4107
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sean Leonard
Date Reported: 2014-09-09
Verifier Name: Barry Leiba
Date Verified: 2014-09-17

Section 7.2 says:

   The IANA has updated the LDAP
   Descriptor registry [RFC44520] as indicated below.

It should say:

   The IANA has updated the LDAP
   Descriptor registry [RFC4520] as indicated below.

RFC 4524, "COSINE LDAP/X.500 Schema", June 2006

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 7202
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-10-30
Verifier Name: RFC Editor
Date Verified: 2022-10-31

Section 1 says:

   CCITT (Commite' Consultatif International de Telegraphique et

It should say:

   CCITT (Comite Consultatif International de Telegraphique et

Notes:

Misspelling "Commite".

Errata ID: 7203
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-10-30
Verifier Name: Orie Steele
Date Verified: 2024-03-29

Section 3.4 says:

          internationaliSDNNumber $ facsimileTelephoneNumber $ street $
          postOfficeBox $ postalCode $ postalAddress $
          physicalDeliveryOfficeName $ st $ l $ description $ o $
          associatedName ) )

   The 'top' object class and the 'dc', 'userPassword', 'searchGuide',
   'seeAlso', 'businessCategory', 'x121Address', 'registeredAddress',
   'destinationIndicator', 'preferredDeliveryMethod', 'telexNumber',
   'teletexTerminalIdentifier', 'telephoneNumber',
   'internationaliSDNNumber', 'facsimileTelephoneNumber', 'street',

It should say:

          internationalISDNNumber $ facsimileTelephoneNumber $ street $
          postOfficeBox $ postalCode $ postalAddress $
          physicalDeliveryOfficeName $ st $ l $ description $ o $
          associatedName ) )

   The 'top' object class and the 'dc', 'userPassword', 'searchGuide',
   'seeAlso', 'businessCategory', 'x121Address', 'registeredAddress',
   'destinationIndicator', 'preferredDeliveryMethod', 'telexNumber',
   'teletexTerminalIdentifier', 'telephoneNumber',
   'internationalISDNNumber', 'facsimileTelephoneNumber', 'street',

Notes:

RFC 4519 has the spelling "internationalISDNNumber" instead of "internationaliSDNNumber".

Errata ID: 7204
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-10-30
Verifier Name: Orie Steele
Date Verified: 2024-04-01

Section 3.7 says:

          facsimileTelephoneNumber $ internationaliSDNNumber $
          physicalDeliveryOfficeName $ postalAddress $ postalCode $
          postOfficeBox $ preferredDeliveryMethod $ registeredAddress $
          seeAlso $ sn $ street $ telephoneNumber $
          teletexTerminalIdentifier $ telexNumber $ x121Address ) )

   The 'domain' object class is described in Section 3.4 of this
   document.  The 'cn', 'description', 'destinationIndicator',
   'facsimileTelephoneNumber', 'internationaliSDNNumber,

It should say:

          facsimileTelephoneNumber $ internationalISDNNumber $
          physicalDeliveryOfficeName $ postalAddress $ postalCode $
          postOfficeBox $ preferredDeliveryMethod $ registeredAddress $
          seeAlso $ sn $ street $ telephoneNumber $
          teletexTerminalIdentifier $ telexNumber $ x121Address ) )

   The 'domain' object class is described in Section 3.4 of this
   document.  The 'cn', 'description', 'destinationIndicator',
   'facsimileTelephoneNumber', 'internationalISDNNumber,

Notes:

RFC 4519 has the spelling "internationalISDNNumber" instead of "internationaliSDNNumber".

Errata ID: 7205
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-10-30
Verifier Name: RFC Editor
Date Verified: 2022-10-31

Section 3.9 says:

   class does not require (or allow) the 'userPassword attribute'.

It should say:

   class does not require (or allow) the 'userPassword' attribute.

Notes:

Unlucky positioning of quotation marks.

RFC 4526, "Lightweight Directory Access Protocol (LDAP) Absolute True and False Filters", June 2006

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 7201
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-10-30
Verifier Name: RFC Editor
Date Verified: 2022-10-31

Section 1 says:

   This documents extends LDAPv3 to support absolute True and False

It should say:

   This document extends LDAPv3 to support absolute True and False

Notes:

Wrong noun form.

RFC 4527, "Lightweight Directory Access Protocol (LDAP) Read Entry Controls", June 2006

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 7200
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-10-30
Verifier Name: RFC Editor
Date Verified: 2022-10-31

Section 3.1 says:

   controlType is 1.3.6.1.1.13.1 and whose the controlValue, an OCTET

It should say:

   controlType is 1.3.6.1.1.13.1 and whose controlValue, an OCTET

Notes:

Erroneous "the".

RFC 4528, "Lightweight Directory Access Protocol (LDAP) Assertion Control", June 2006

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 7198
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-10-30
Verifier Name: RFC Editor
Date Verified: 2022-10-31

Section 1 says:

   part the operation.

It should say:

   part of the operation.

Notes:

Missing "of".

RFC 4529, "Requesting Attributes by Object Class in the Lightweight Directory Access Protocol", June 2006

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 7199
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-10-30
Verifier Name: RFC Editor
Date Verified: 2022-10-31

Section 1 says:

   object class identifier from an attribute descriptions.

It should say:

   object class identifier from an attribute description.

Notes:

Erroneous "descriptions".

RFC 4532, "Lightweight Directory Access Protocol (LDAP) "Who am I?" Operation", June 2006

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 65
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-06
Verifier Name: Alexey Melnikov
Date Verified: 2010-09-02

Section 3 says:

   Servers indicate their support for this extended operation by
   providing a whoamiOID object identifier as a value of the
   'supportedExtension' attribute type in their root DSE.  The server
   SHOULD advertise this extension only when the client is willing and
                                             ^^^^^^^^^^
   able to perform this operation.   

It should say:

   Servers indicate their support for this extended operation by
   providing a whoamiOID object identifier as a value of the
   'supportedExtension' attribute type in their root DSE.  The server
   SHOULD advertise this extension only when it is willing
                                             ^^
   and able to perform this operation.

Notes:

As far as I can see, the last sentence there is misleading and
does not match the operational scenario; and hence, it should be
clarified. According to the recommendations given, the client
will not try the operation if the OID is not offered by the server,
and hence the server cannot know whether the client is willing
to send the whoami Request; and in this case, the *server* will
perform the operation, i.e., send the whoami Response.

Errata ID: 7195
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-10-30
Verifier Name: RFC Editor
Date Verified: 2022-10-31

Section 1 says:

   specification, the term "the authorization identity" and "the
   authzId" are generally to be read as "the primary authorization
   identity" and the "the primary authzId", respectively.

It should say:

   specification, the term "the authorization identity" and "the
   authzId" are generally to be read as "the primary authorization
   identity" and "the primary authzId", respectively.

Notes:

Doubled "the".

Errata ID: 7196
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-10-30
Verifier Name: RFC Editor
Date Verified: 2022-10-31

Section 4.1 says:

   When a Proxied Authorization Control is be attached to the "Who am

It should say:

   When a Proxied Authorization Control is attached to the "Who am

Notes:

Erroneous "be".

Errata ID: 7197
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-10-30
Verifier Name: RFC Editor
Date Verified: 2022-10-31

Section 7 says:

   The LDAP "Who am I?" operation takes it's name from the UNIX

It should say:

   The LDAP "Who am I?" operation takes its name from the UNIX

Notes:

The possessive form of "it" should be written without an apostrophe.

RFC 4534, "Group Security Policy Token v1", June 2006

Source of RFC: msec (sec)

Errata ID: 940
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Verifier Name: Tim Polk
Date Verified: 2008-11-20

Section B.4 says:

omission in ASN.1 module

Section B.3, on pp. 20/21, gives a textual introduction with ASN.1
snippits to, and Section B.4, on pp. 21/22 gives the formal ASN.1
module for, GSAKMPv1 De-Registration.

Unfortunately, there's a significant inconsistency between these
two sources of data structure and syntax.

On page 20, in Section B.3 the RFC says:

     GSAKMPv1DeRegistrationInfo ::= SEQUENCE {
       leaveMechanisms  SEQUENCE OF LeaveMechanisms,
|      terse            BOOLEAN,
       transport        Transport
     }

On page 21, in Section B.4 the RFC says:

   GSAKMPv1DeRegistrationInfo ::= SEQUENCE {
     leaveMechanisms SEQUENCE OF LeaveMechanisms,
     transport       Transport
   }

Obviously, the line
       terse            BOOLEAN,
has been lost on its way into the ASN.1 module, and should be
re-inserted to make it consistent with the text.

Notes:

from pending

RFC 4541, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", May 2006

Source of RFC: magma (int)

Errata ID: 63
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-08
Verifier Name: Morten Jagd Christensen
Date Verified: 2006-11-13

Section 3 says:

   Additionally, if a non-Querier switch spoofs any General Queries (as
   addressed in Section 2.1 above, for Spanning Tree topology changes),
   the switch should use the null IP source address (::) when sending
   said queries.  When such proxy queries are received, they must not be
   included in the Querier election process.

It should say:

   Additionally, if a non-Querier switch spoofs any General Queries (as
   addressed in Section 2.1 above, for Spanning Tree topology changes),
   the switch should use the unspecified IP source address (::) when
   sending said queries.  When such proxy queries are received, they
   must not be included in the Querier election process.

Notes:

The term, "null" IP address is inappropriate, according to the current
IPv6 Address Architecture document. RFC 4541 should use the proper
term, "unspecified" address (cf. Section 2.5.2 of RFC 4291).

from pending

Errata ID: 914
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-08
Verifier Name: Morten Jagd Christensen
Date Verified: 2006-11-13

Section 3 says:

   Initial allocation of IPv6 multicast addresses, as described in
   [RFC3307], however, cover only the lower 32 bits of group ID.

It should say:

   The Initial allocation of IPv6 multicast addresses, as described in
   [RFC3307], however, covers only the lower 32 bits of group ID.

Notes:

from pending

RFC 4543, "The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH", May 2006

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 1821
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Pasi Eronen
Date Reported: 2009-07-30
Verifier Name: Pasi Eronen
Date Verified: 2009-10-08

Section 9 says:

(nothing)

It should say:

The following text should have been included in Section 9:

For the negotiation of AES-GMAC in AH with IKEv1, the following
values have been assigned in the IPsec AH Transform Identifiers
registry (in isakmp-registry). Note that IKEv1 and IKEv2 use
different transform identifiers.

   "11" for AH_AES-128-GMAC

   "12" for AH_AES-192-GMAC

   "13" for AH_AES-256-GMAC

In addition, the following values have been assigned in the
Authentication Algorithms registry (in isakmp-registry):

   "11" for AES-128-GMAC

   "12" for AES-192-GMAC

   "13" for AES-256-GMAC

For the negotiation of AES-GMAC in ESP with IKEv1, the following
value has been assigned from the IPsec ESP Transform Identifiers
registry (in isakmp-registry). Note that IKEv1 and IKEv2 use a
different transform identifier.

   "23" for ESP_NULL_AUTH_AES-GMAC

Notes:

Found by Soo-Fei Chew (ipsec@ietf.org list, 2009-04-09);
approved by IESG in 2009-06-04 telechat.

Errata ID: 3643
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Bowler
Date Reported: 2013-06-06
Verifier Name: Sean Turner
Date Verified: 2013-08-14

Section 4 says:

   In AUTH_AES_GMAC, the AH Authentication Data field consists of the IV
   and the Authentication Tag, as shown in Figure 5.  Unlike the usual
   AH case, the Authentication Data field contains both an input to the
   authentication algorithm (the IV) and the output of the
   authentication algorithm (the tag).  No padding is required in the
   Authentication Data field, because its length is a multiple of 64
   bits.

It should say:

   In AUTH_AES_GMAC, the AH Authentication Data field consists of the IV
   and the Authentication Tag, as shown in Figure 5.  Unlike the usual
   AH case, the Authentication Data field contains both an input to the
   authentication algorithm (the IV) and the output of the
   authentication algorithm (the tag).  In IPv6, padding of 4 octets is
   required to bring the AH header to a multiple of 64-bits.  No padding
   is required for IPv4.

Notes:

The original text fails to consider the rest of the AH header which is 12 octets plus the authentication data field.

Errata ID: 62
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: David McGrew
Date Reported: 2006-07-06
Verifier Name: Russ Housley
Date Verified: 2010-03-11

Section 7 says:

In ENCR_NULL_AUTH_AES_GMAC, the IV is not included in either the  
plaintext or the additional authenticated data.

It should say:

In AES-GCM-ESP, the IV is not included in either the plaintext or  
the additional authenticated data.

Notes:

This error might confuse the reader because it makes the text
contradict Figure 4.

Errata ID: 1921
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Hoffman
Date Reported: 2009-10-20
Verifier Name: Russ Housley
Date Verified: 2010-03-11

Section 11 says:

   [GCM]      McGrew, D. and J. Viega, "The Galois/Counter Mode of
              Operation (GCM)", Submission to NIST. http://
              csrc.nist.gov/CryptoToolkit/modes/proposedmodes/gcm/
              gcm-spec.pdf, January 2004.

It should say:

[GCM]      Dworkin, M. "Recommendation for Block Cipher Modes
of Operation: Galois/Counter Mode (GCM) and GMAC", NIST Special
Publication 800-38D, November 2007.

Notes:

The original link is dead.

RFC 4544, "Definitions of Managed Objects for Internet Small Computer System Interface (iSCSI)", May 2006

Note: This RFC has been obsoleted by RFC 7147

Source of RFC: ips (tsv)

Errata ID: 1636
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-04
Verifier Name: Lars Eggert
Date Verified: 2008-12-19

 

The DESCRIPTION clause of the iscsiHdrIntegrityNone OBJECT-IDENTITY,

    DESCRIPTION
        "The authoritative identifier when no integrity
|       scheme (for either the header or data) is being
<<page break>>
        used."

should better say:

    DESCRIPTION
        "The authoritative identifier when no integrity
|       scheme for the header is being used."

The DESCRIPTION clause of the iscsiHdrIntegrityCrc32c OBJECT-IDENTITY,

    DESCRIPTION
        "The authoritative identifier when the integrity
|       scheme (for either the header or data) is CRC32c."

should better say:

    DESCRIPTION
        "The authoritative identifier when the integrity
|       scheme for the header is CRC32c."

The DESCRIPTION clause of the iscsiDataIntegrityNone OBJECT-IDENTITY,

    DESCRIPTION
        "The authoritative identifier when no integrity
|       scheme (for either the header or data) is being
        used."

should better say:

    DESCRIPTION
        "The authoritative identifier when no integrity
|       scheme for the data is being used."

The DESCRIPTION clause of the iscsiDataIntegrityCrc32c OBJECT-IDENTITY,

    DESCRIPTION
        "The authoritative identifier when the integrity
|       scheme (for either the header or data) is CRC32c."

should better say:

    DESCRIPTION
        "The authoritative identifier when the integrity
|       scheme for the data is CRC32c."

Notes:

The iscsiDescriptors OBJECT-IDENTITY declarations, on page 16/17
of the RFC, unfortunately contain pairwise identical DESCRIPTION
clauses, making Header and Data Integrity identifiers
indistinguishable.

Errata ID: 1637
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-04
Verifier Name: Lars Eggert
Date Verified: 2008-12-19

 

The DESCRIPTION clause of the iscsiSsnAuthIdentity OBJECT-TYPE,
on page 58 of the RFC, says:

    DESCRIPTION
        "This object contains a pointer to a row in the
        IPS-AUTH MIB module that identifies the authentication
|       method being used on this session, as communicated
        during the login phase."

It should say:

    DESCRIPTION
        "This object contains a pointer to a row in the
        IPS-AUTH MIB module that identifies the authentication
|       identity being used on this session, as communicated
        during the login phase."

RFC 4550, "Internet Email to Support Diverse Service Environments (Lemonade) Profile", June 2006

Note: This RFC has been obsoleted by RFC 5550

Source of RFC: lemonade (app)

Errata ID: 59
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-11
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-06

Section 1.1 says:

   In particular, examples assume that Lemonade
   Submit and IMAP servers support all Lemonade extensions described in
   this document, so they don't show how to deal with absence of an
   extension.

It should say:

   In particular, examples assume that Lemonade
   Submit and IMAP servers support all Lemonade extensions described in
   this document, so they don't show how to deal with the absence of an
   extension.

Notes:

missing article

Errata ID: 736
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-11

Section 9.2 says:

   [IMAP-DISC] Melnikov, A., "Synchronization operations for
               disconnected IMAP4 clients", Work in Progress, October
               2004.

It should say:

   [IMAP-DISC] Melnikov, A., Ed., "Synchronization Operations for 
               Disconnected IMAP4 Clients", RFC 4549, June 2006.

Notes:

This I-D has been published -- synchronized with RFC 4550 -- as RFC 4549.

from pending

Errata ID: 1767
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tony Hansen
Date Reported: 2009-04-16
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-06

Section 2.4.1, 2.4.2 says:

S: a002 OK URLFETCH completed
I: a003 LOGOUT
S: * BYE See you later
S: a003 OK Logout successful

It should say:

I: a002 OK URLFETCH completed
S: a003 LOGOUT
I: * BYE See you later
I: a003 OK Logout successful

Notes:

According to section 1.1 (Conventions Used in This Document):
In examples, "M:", "I:", and "S:" indicate lines sent by the client
messaging user agent, IMAP e-mail server, and SMTP submit server,
respectively.

The exact same error appears in both sections 2.4.1 and 2.4.2.

RFC 4551, "IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization", June 2006

Note: This RFC has been obsoleted by RFC 7162

Source of RFC: imapext (app)

Errata ID: 3509
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Pete Maclean
Date Reported: 2013-03-05
Verifier Name: Barry Leiba
Date Verified: 2013-03-05

Section 3.2 says:

 Example 5:

      C: c101 STORE 1 (UNCHANGEDSINCE 12121230045) -FLAGS.SILENT
         (\Deleted)
      S: * OK [HIGHESTMODSEQ 12111230047]
      S: * 50 FETCH (MODSEQ (12111230048))
      S: c101 OK Store (conditional) completed

It should say:

Example 5:

      C: c101 STORE 50 (UNCHANGEDSINCE 12121230045) -FLAGS.SILENT
         (\Deleted)
      S: * OK [HIGHESTMODSEQ 12111230047]
      S: * 50 FETCH (MODSEQ (12111230048))
      S: c101 OK Store (conditional) completed

Notes:

Since successful conditional stores MUST return the FETCH (MODSEQ) data for every message that was changed, the untagged FETCH response in this example should refer to the same message as the STORE command. To avoid any suggestion that 1 might be a special case, I have made the correction to use 50 in both contexts.

Errata ID: 3401
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Slusarz
Date Reported: 2012-11-08
Verifier Name: Barry Leiba
Date Verified: 2012-11-08

Section 3.2 says:

      However, if the mod-sequence of any metadata item of the message
      is greater than the specified UNCHANGEDSINCE value, then the
      requested operation MUST NOT be performed.  In this case, the
      mod-sequence attribute of the message is not updated, and the
      message number (or unique identifier in the case of the UID STORE
      command) is added to the list of messages that failed the
      UNCHANGESINCE test.

      When the server finished performing the operation on all the
      messages in the message set, it checks for a non-empty list of
      messages that failed the UNCHANGESINCE test.  If this list is
      non-empty, the server MUST return in the tagged response a
      MODIFIED response code.  The MODIFIED response code includes the
      message set (for STORE) or set of UIDs (for UID STORE) of all
      messages that failed the UNCHANGESINCE test.

   Example 3:

      All messages pass the UNCHANGESINCE test.

      C: a103 UID STORE 6,4,8 (UNCHANGEDSINCE 12121230045)
          +FLAGS.SILENT (\Deleted)
      S: * 1 FETCH (UID 4 MODSEQ (12121231000))
      S: * 2 FETCH (UID 6 MODSEQ (12121230852))
      S: * 4 FETCH (UID 8 MODSEQ (12121130956))
      S: a103 OK Conditional Store completed

It should say:

      However, if the mod-sequence of any metadata item of the message
      is greater than the specified UNCHANGEDSINCE value, then the
      requested operation MUST NOT be performed.  In this case, the
      mod-sequence attribute of the message is not updated, and the
      message number (or unique identifier in the case of the UID STORE
      command) is added to the list of messages that failed the
      UNCHANGEDSINCE test.

      When the server finished performing the operation on all the
      messages in the message set, it checks for a non-empty list of
      messages that failed the UNCHANGEDSINCE test.  If this list is
      non-empty, the server MUST return in the tagged response a
      MODIFIED response code.  The MODIFIED response code includes the
      message set (for STORE) or set of UIDs (for UID STORE) of all
      messages that failed the UNCHANGEDSINCE test.

   Example 3:

      All messages pass the UNCHANGEDSINCE test.

      C: a103 UID STORE 6,4,8 (UNCHANGEDSINCE 12121230045)
          +FLAGS.SILENT (\Deleted)
      S: * 1 FETCH (UID 4 MODSEQ (12121231000))
      S: * 2 FETCH (UID 6 MODSEQ (12121230852))
      S: * 4 FETCH (UID 8 MODSEQ (12121130956))
      S: a103 OK Conditional Store completed

Notes:

This erratum changes "UNCHANGESINCE" to "UNCHANGEDSINCE" in four places.

Errata ID: 3506
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hoa V. DINH
Date Reported: 2013-03-01
Verifier Name: Barry Leiba
Date Verified: 2013-03-01

Section 4. says:

   resp-text-code      =/ "HIGHESTMODSEQ" SP mod-sequence-value /
                          "NOMODSEQ" /
                          "MODIFIED" SP set

It should say:

   resp-text-code      =/ "HIGHESTMODSEQ" SP mod-sequence-value /
                          "NOMODSEQ" /
                          "MODIFIED" SP sequence-set

Notes:

RFC 1730 and RFC 2060 mentioned "set". It's been changed to sequence-set in RFC 3501.
Therefore, I think the same name should be applied in RFC 4551.

RFC 4559, "SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows", June 2006

Source of RFC: INDEPENDENT

Errata ID: 2912
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2011-08-03
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-20

Section 4 says:

Notes:

The "Negotiate" authentication scheme violates basic HTTP principles, in that it attaches information to the connection on which the handshake happened, and furthermore uses syntax in the WWW-Authenticate and Authorization header fields that is in violation of the base ABNF definitions.

Errata ID: 2913
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2011-08-03
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-20

Section 6 says:

Notes:

The Security Considerations require the use of the HTTP header field "Proxy-Support", which is not defined in this document nor registered with IANA.

RFC 4561, "Definition of a Record Route Object (RRO) Node-Id Sub-Object", June 2006

Source of RFC: mpls (rtg)

Errata ID: 7583
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Igor Malyushkin
Date Reported: 2023-08-01
Verifier Name: Andrew Alston
Date Verified: 2023-11-12

Section 3 says:

[RSVP-TE] defines the IPv4 and IPv6 RRO sub-objects.  Moreover, two additional flags are defined in [FAST-REROUTE]: the "Local Protection Available" and "Local Protection in Use" bits.

It should say:

[RSVP-TE] defines the IPv4 and IPv6 RRO sub-objects.  Moreover, two additional flags are defined in [FAST-REROUTE]: the "Bandwidth protection" and "Node protection" bits.

Notes:

The "Local Protection Available" and "Local Protection in Use" are defined in RFC3209 (Sections 4.4.1.1, 4.4.1.2), not RFC4090. The latter defines "Bandwidth protection" and "Node protection" in Section 4.4.

RFC 4566, "SDP: Session Description Protocol", July 2006

Note: This RFC has been obsoleted by RFC 8866

Source of RFC: mmusic (rai)

Errata ID: 1089
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Colin Perkins
Date Reported: 2007-12-06
Verifier Name: Cullen Jennings
Date Verified: 2009-01-08

Section 9 says:

IP6-multicast =       hexpart [ "/" integer ]

IP6-address =         hexpart [ ":" IP4-address ]

hexpart =             hexseq / hexseq "::" [ hexseq ] /
                              "::" [ hexseq ]

hexseq  =             hex4 *( ":" hex4)

hex4    =             1*4HEXDIG

It should say:

IP6-multicast =       IP6-address [ "/" integer ]

IP6-address =                                      6( h16 ":" ) ls32
                          /                       "::" 5( h16 ":" ) ls32
                          / [               h16 ] "::" 4( h16 ":" ) ls32
                          / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
                          / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
                          / [ *3( h16 ":" ) h16 ] "::"    h16 ":"   ls32
                          / [ *4( h16 ":" ) h16 ] "::"              ls32
                          / [ *5( h16 ":" ) h16 ] "::"              h16
                          / [ *6( h16 ":" ) h16 ] "::"

h16 =                 1*4HEXDIG

ls32 =                ( h16 ":" h16 ) / IP4-address

Notes:

Correct IPv6 ABNF.

Errata ID: 5183
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: no space before encoding parameter in rtpmap value
Date Reported: 2017-11-14
Verifier Name: Orie Steele
Date Verified: 2024-04-01

Section 6. SDP Attr says:

 a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding
         parameters>]

It should say:

 a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding
         parameters>]

Notes:

rtpmap requires format below

a=rtpmap:97 L16/8000
a=rtpmap:98 L16/11025/2

no space between clock rate and optional parameter

RFC 4567, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", July 2006

Source of RFC: mmusic (rai)

Errata ID: 2247
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Riccardo Bernardini
Date Reported: 2010-05-06
Verifier Name: Robert Sparks
Date Verified: 2011-02-07

Section 3.2 says:

key-mgmt-spec = "prot" "=" KMPID ";" ["uri" "=" %22 URI %22 ";"] 

It should say:

key-mgmt-spec = "prot" "=" KMPID ";" ["uri" "=" %22 URI %22 ";"] ["data" "=" %22 base64 %22 ";"]

Notes:

There is an inconsistency between the ABNF for key-mgmt-spec on page 6 and the two SETUP examples on top of page 21. In both examples a field data="..." is present in the keymgmt header, but the ABNF on page 6 does not allow for it. The suggested correction solves the inconsistency.


--- From reviewer Dale Worley --
The grammar needs additional work because key-mgmt-spec is not
correctly attached to the original ABNF, and the production provided
does not allow the parameters to appear in any order. In addition,the
terminating CRLF is not shown in the ABNF. A more correct version is:

extension-header =/ KeyMgmt
(Is this the correct nonterminal to extend? RFC 4567 section 3.2 does
not make it clear what sort of header "KeyMgmt" is.)

KeyMgmt = "KeyMgmt" ":" key-mgmt-spec 0*("," key-mgmt-spec) CRLF

key-mgmt-spec = "prot" "=" KMPID 0*(key-mgmt-spec-param)

key-mgmt-spec-param = ";" "uri" "=" %22 URI %22
/ ";" "data" "=" %22 base64 %22

The whole situation is troublesome because the RFC does not make it
clear to what degree the 'prot', 'uri', and 'data' elements are
required to be in a certain order. Given that many headers are copied
from HTTP, the implication is that the first element (that is,
"prot=KMPID") must appear in the first position, but the following
elements ("uri" and "data") may be in any order. But current practice
may have de-facto standardized a different rule. We need some input
from someone who is familiar with current practice.

------
The MMUSIC WG list was polled and the responses were that allowing these parameters to appear in any order was an acceptable technical solution.

RFC 4570, "Session Description Protocol (SDP) Source Filters", July 2006

Source of RFC: mmusic (rai)

Errata ID: 5416
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Simon Rankine
Date Reported: 2018-07-06
Verifier Name: Orie Steele
Date Verified: 2024-04-01

Section 3.2.5 says:

a=source-filter incl IN IP6 FF0E::11A 2001:DB8:1:2:240:96FF:FE25:8EC9

It should say:

a=source-filter: incl IN IP6 FF0E::11A 2001:DB8:1:2:240:96FF:FE25:8EC9

Notes:

Normative text in section 3 requires a colon after the source-filter attribute, but the ipv6 example in section 3.2.5 omits this colon.

RFC 4576, "Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs)", June 2006

Source of RFC: ospf (rtg)

Errata ID: 7765
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julian Cowley
Date Reported: 2024-01-15
Verifier Name: John Scudder
Date Verified: 2024-01-16

Section 7 says:

   [OSPFv2]   Postel, J., "Suggested Telnet Protocol Changes", RFC 328,
              April 1972.

It should say:

   [OSPFv2]   Moy, J., "OSPF Version 2", RFC 2328, April 1998.

Notes:

The error was caused by a missing 2 in front of the RFC number in the reference.

RFC 4577, "OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)", June 2006

Source of RFC: l3vpn (int)

Errata ID: 2264
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: William McCall
Date Reported: 2010-05-17
Verifier Name: Brian Haberman
Date Verified: 2012-09-12

Section 4.2.6 says:

         [...] If BGP installs
         a route of one of these types in the VRF, and if that route is
         selected for redistribution into OSPF, it will be advertised by
         OSPF in either a type 3 or a type 5 LSA, depending on the
         domain identifier.

It should say:

         [...] If BGP installs
         a route of one of these types in the VRF, and if that route is
         selected for redistribution into OSPF, it will be advertised by
         OSPF in either a type 3, type 5, or type 7 LSA, depending on the
         domain identifier and the type of area the PE/CE link belongs to.

Notes:

Suggested because reading 4.2.6 is contradictory with the following:

4.2.8.1. External Routes

[...]If the route is advertised, and the PE/CE link belongs to a NSSA area, it is advertised in a type 7 LSA.[...]

RFC 4578, "Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE)", November 2006

Source of RFC: dhc (int)

Errata ID: 4624
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: David Anderson
Date Reported: 2016-02-23
Verifier Name: Brian Haberman
Date Verified: 2016-03-23

Section 2.1 says:

            Type   Architecture Name
            ----   -----------------
              0    Intel x86PC
              1    NEC/PC98
              2    EFI Itanium
              3    DEC Alpha
              4    Arc x86
              5    Intel Lean Client
              6    EFI IA32
              7    EFI BC
              8    EFI Xscale
              9    EFI x86-64

It should say:

            Type   Architecture Name
            ----   -----------------
              0    Intel x86PC
              1    NEC/PC98
              2    EFI Itanium
              3    DEC Alpha
              4    Arc x86
              5    Intel Lean Client
              6    EFI IA32
              7    EFI x86-64
              8    EFI Xscale
              9    EFI BC

Notes:

The values for EFI BC and EFI x86-64 should be swapped. UEFI imeplementations use value 7 to report EFI x86-64, not value 9. The IANA registry for DHCPv6 options (http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#processor-architecture) correctly reflects reality, with values 7 and 9 swapped compared to RFC 4578.

RFC 4584, "Extension to Sockets API for Mobile IPv6", July 2006

Source of RFC: mip6 (int)

Errata ID: 741
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Verifier Name: Samita Chakrabarti
Date Verified: 2006-08-14

Section 6.1 says:

   This specification recommends that the IPv6 RAW sockets mechanism
   send and receive Mobility Header (MH) packets.  The behavior is
|  similar to ICMPV6 processing, where the kernel passes a copy of the
   mobility header packet to the receiving socket.  Depending on the
   implementation, the kernel may process the mobility header in
   addition to passing the mobility header to the application.  In order
   to comply with the restriction in the Advanced Sockets API for IPv6
   [1], applications should set the IPV6_CHECKSUM socket option with
   IPPROTO_MH protocol RAW Sockets.  A Mobile IPv6 implementation that
   supports the Mobile IPv6 API must implement Mobility Header API
   checksum calculations by default at the kernel for both incoming and
   outbound paths.  A Mobile IPv6 implementation must not return error
   on the IPV6_CHECKSUM socket option setting, even if the socket option
   is a NO-OP function for that implementation because it verifies the
   checksum at the kernel level.  The Mobility Header checksum procedure
   is described in the Mobile IPv6 Protocol [2] specification.  Again,
   for application portability it is recommended that the applications
   set the IPV6_CHECKSUM socket option along with the RAW sockets for
   IPPROTO_MH protocol.

It should say:

   This specification recommends that the IPv6 RAW sockets mechanism
   send and receive Mobility Header (MH) packets.  The behavior is
|  similar to ICMPv6 processing; the kernel passes a copy of the
   mobility header packet to the receiving socket.  Depending on the
   implementation, the kernel may process the mobility header in
   addition to passing the mobility header to the application.  In order
   to comply with the restriction in the Advanced Sockets API for IPv6
   [1], applications should set the IPV6_CHECKSUM socket option with
   IPPROTO_MH protocol RAW Sockets.  A Mobile IPv6 implementation that
   supports the Mobile IPv6 API must implement Mobility Header API
|  checksum calculations by default in the kernel for both incoming and
   outbound paths.  A Mobile IPv6 implementation must not return an
   error on the IPV6_CHECKSUM socket option setting, even if the socket
   option is a NO-OP function for that implementation because it
   verifies the checksum at the kernel level.  The Mobility Header
   checksum procedure is described in the Mobile IPv6 Protocol [2]
   specification.  Again, for application portability it is recommended
   that the applications set the IPV6_CHECKSUM socket option along with
|  the RAW sockets for the IPPROTO_MH protocol.

Notes:

misleading wording

from pending

Errata ID: 52
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Verifier Name: Samita Chakrabarti
Date Verified: 2006-08-14

Section 4.6 says:

   IPv6 Neighbor Discovery changes are also defined in
   <netinet/icmp6.h>.

      New 'Home Agent' flag in router advertisement:  #define
      ND_RA_FLAG_HOMEAGENT   0x20  /* Home Agent flag in RA */

      New Router flag with prefix information of the home agent:
      #define  ND_OPT_PI_FLAG_ROUTER  0x20  /* Router flag in PI */
 
   As per the Mobile IPv6 specification [2], Section 7.2, a Home Agent
   MUST include at least one prefix option with the Router Address (R)
   bit set.  Advanced Socket API [1] defines data structure for prefix
   option as follows:

It should say:

   IPv6 Neighbor Discovery changes are also defined in
   <netinet/icmp6.h>.

   New 'Home Agent' flag in router advertisement:
 
      #define  ND_RA_FLAG_HOMEAGENT   0x20  /* Home Agent flag in RA */

   New Router flag with prefix information of the home agent:
 
      #define  ND_OPT_PI_FLAG_ROUTER  0x20  /* Router flag in PI */

   As per the Mobile IPv6 specification [2], Section 7.2, a Home Agent
   MUST include at least one prefix option with the Router Address (R)
   bit set.  The Advanced Socket API [1] defines a data structure for
   the prefix option as follows:

Notes:

separation of machine readable text and RFC text, and missing articles

from pending

Errata ID: 739
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Verifier Name: Samita Chakrabarti
Date Verified: 2006-08-14

All instances of

IPV6 and ICMPV6

For example, in section 5:

   Legacy IPv6 applications/implementations using the Advanced Socket
   API [1] mechanisms, upon receiving Home Address destination options
   or Routing headers(Type 2), will discard the packet as per Sections
   4.2 and 4.4 of IPV6 Protocol [3] specification, respectively;
   otherwise, they should properly handle the Home Address destination
   option and the Routing Header Type 2 specified in this document.

It should say:

IPv6 and ICMPv6

For example, should say (also incorporating other corrections):

   Legacy IPv6 applications/implementations using the Advanced Socket
   API [1] mechanisms, upon receiving Home Address destination options
   or Routing headers (Type 2), will discard the packet as per Sections
   4.2 and 4.4 of the IPv6 Protocol [3] specification, respectively;
   otherwise, they should properly handle the Home Address destination
   option and the Routing Header Type 2 specified in this document.

Notes:

unusual capitalization

Other places affected are:
Section 5.1, 1st paragraph (page 17);
Section 5.3, 1st paragraph (page 19);
Section 6.1, 1st paragraph (page 21)

from pending

Errata ID: 740
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Verifier Name: Samita Chakrabarti
Date Verified: 2006-08-14

Section 5.3 says:

   Any user-level implementation or application that sends the Home
   address destination option through ancillary data objects should
   follow the order extension header defined in this document when using
   IPV6_MIPDSTOPTS socket options.

It should say:

   Any user-level implementation or application that sends the Home
   address destination option through ancillary data objects should
|  follow the order of extension headers defined in this document when
|  using the IPV6_MIPDSTOPTS socket options.

Notes:

from pending

RFC 4585, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", July 2006

Note: This RFC has been updated by RFC 5506, RFC 8108

Source of RFC: avt (rai)

Errata ID: 2853
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ali Begen
Date Reported: 2011-07-05
Verifier Name: Robert Sparks
Date Verified: 2011-08-05

Section 4.2 says:

OLD:
      rtcp-fb-param      = SP "app" [SP byte-string]
                         / SP token [SP byte-string]
                         / ; empty
NEW:
      rtcp-fb-param      = [ SP "app" [SP byte-string]
                         / SP token [SP byte-string] ]


OLD:
      rtcp-fb-ack-param  = SP "rpsi"
                         / SP "app" [SP byte-string]
                         / SP token [SP byte-string]
                         / ; empty
NEW:
      rtcp-fb-ack-param  = [ SP "rpsi"
                         / SP "app" [SP byte-string]
                         / SP token [SP byte-string] ]


OLD:
      rtcp-fb-nack-param = SP "pli"
                         / SP "sli"
                         / SP "rpsi"
                         / SP "app" [SP byte-string]
                         / SP token [SP byte-string]
                         / ; empty
NEW:
      rtcp-fb-nack-param = [ SP "pli"
                         / SP "sli"
                         / SP "rpsi"
                         / SP "app" [SP byte-string]
                         / SP token [SP byte-string] ]

Notes:

During the AUTH48 of RFC 6285, we discovered a bug with the ABNF syntax in RFC 4585. The original ABNF in Section 4.2 (as noted above) is incorrect ("/ ;empty" is not a valid ABNF - RFC 5234 does not allow empty alternates).

The NEW text intends to fix it. There are 3 places where the same change should be applied (changes are identical).

Errata ID: 3313
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mo Zanaty
Date Reported: 2012-08-11
Verifier Name: Robert Sparks
Date Verified: 2012-11-26

Section 4.2 says:

      rtcp-fb-ack-param  = SP "rpsi"
                         / SP "app" [SP byte-string]
                         / SP token [SP byte-string]
                         / ; empty

It should say:

      rtcp-fb-ack-param  = SP "rpsi"
                         / SP "app" [SP byte-string]
                         / SP token [SP byte-string]

Notes:

RFC 4585 defines and allows generic NACK (with no further parameters) but not generic ACK (which always requires further parameters). Section 4.2 says:
...
Parameters MUST be provided to further distinguish different types
of positive acknowledgement feedback.
...
The feedback type "nack", without parameters, indicates use of the
Generic NACK feedback format as defined in Section 6.2.1.
...
The ABNF incorrectly allows nothing after "ack", implying that generic ACK is valid. Even the approved errata, which replaces the invalid empty alternate with optional [], still allows nothing after "ack". Note that recent interest in RTP congestion control (e.g. RMCAT BOF) may lead to defining a standard ACK.

RFC 4591, "Frame Relay over Layer 2 Tunneling Protocol Version 3 (L2TPv3)", August 2006

Note: This RFC has been updated by RFC 5641

Source of RFC: l2tpext (int)

Errata ID: 735
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-11
Verifier Name: Brian Haberman
Date Verified: 2012-05-10

Section 4.3 says:

   With L2TPv3 as the tunneling protocol, the packet resulted from the
   encapsulation is N bytes longer than Frame Relay frame without the
   opening and closing HDLC flags or FCS.  The value of N depends on the
   following fields:

It should say:

  With L2TPv3 as the tunneling protocol, the packet resulting from the
  encapsulation is N bytes longer than the Frame Relay frame without
  the opening and closing HDLC flags or FCS.  The value of N depends on
  the following fields:

Errata ID: 3223
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-11
Verifier Name: Brian Haberman
Date Verified: 2012-05-10

Section 3.2 says:

   General Result Codes regarding L2TP session establishment are defined
   in [RFC3931].  Additional Frame Relay result codes are defined as
   follows:

      17: FR PVC was deleted permanently (no longer provisioned) 18: FR
      PVC has been INACTIVE for an extended period of time 19:
      Mismatched FR Header Length

It should say:

   General Result Codes regarding L2TP session establishment are defined
   in [RFC3931].  Additional Frame Relay result codes are defined as
   follows:

     17: FR PVC was deleted permanently (no longer provisioned)
     18: FR PVC has been INACTIVE for an extended period of time
     19: Mismatched FR Header Length

Errata ID: 3224
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-11
Verifier Name: Brian Haberman
Date Verified: 2012-05-10

Section 3.5 says:

   The Frame Relay Header Length Type is a 2-octet unsigned integer with
   the following values defined in this document:

      2: Two-octet Frame Relay Header 4: Four-octet Frame Relay Header

It should say:

   The Frame Relay Header Length Type is a 2-octet unsigned integer with
   the following values defined in this document:

     2: Two-octet Frame Relay Header
     4: Four-octet Frame Relay Header

Errata ID: 3225
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-11
Verifier Name: Brian Haberman
Date Verified: 2012-05-10

Section 4.1 says:

   C/R (bit 6) FR frame C/R (command/response) bit [Q922].

   F - FECN (bit 12):  FR FECN (Forward Explicit Congestion
   Notification) bit [Q922].

   B - BECN (bit 13):

   FR BECN (Backward Explicit Congestion Notification) bit [Q922].

   D - DE (bit 14) FR DE bit indicates the discard eligibility [Q922].

It should say:

  C (bit 6):     FR frame C/R (command/response) bit [Q922].

  F (bit 12):    FR FECN (Forward Explicit Congestion Notification)
                 bit [Q922].

  B (bit 13):    FR BECN (Backward Explicit Congestion Notification)
                 bit [Q922].

  D (bit 14):    FR DE bit indicates the discard eligibility [Q922].

Notes:

The "full bit names" have been removed from the left hand sides
(corresponding to the diagrams), and replaced "C/R" by "C", because
these "full bit names" do not appear in the diagrams, but already do
appear in the explanatory text on the right hand side. Thus, to the
left of the colons, there now are only -- and precisely -- the terms
from the diagrams.

RFC 4594, "Configuration Guidelines for DiffServ Service Classes", August 2006

Note: This RFC has been updated by RFC 5865, RFC 8622

Source of RFC: tsvwg (wit)

Errata ID: 4910
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: David Black
Date Reported: 2017-01-18
Verifier Name: Mirja Kühlewind
Date Verified: 2017-01-20

Section 4.8 says:

It can be assumed that this class will consume any available
bandwidth and that packets traversing congested links may
experience higher queuing delays or packet loss.

It should say:

This class is expected to consist of TCP traffic and
other traffic with a TCP-like response to available bandwidth
and network bottlenecks; therefore, it can be assumed that this traffic
will consume any bandwidth available to the class and that packets
traversing congested links may experience higher queuing
delays and/or packet loss.

Notes:

This errata adds some explanation to a sentence in the description of the High-Throughput Data Service Class. The original sentence was misread to imply less than best effort service as part of work on WiFi mapping of Diffserv. That implication is incorrect, e.g., as indicated by the AF1x DSCP marking recommendation. The added explanation was agreed to with the WiFi Diffserv draft authors as sufficient to avoid any implication that less than best effort service is appropriate for this traffic service class.

RFC 4596, "Guidelines for Usage of the Session Initiation Protocol (SIP) Caller Preferences Extension", July 2006

Source of RFC: sipping (rai)

Errata ID: 1287
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Eric Tremblay
Date Reported: 2008-01-16
Verifier Name: Cullen Jennings
Date Verified: 2009-01-08

Throughout the document, when it says:

msgserver

It should say:

actor="msg-taker"

Notes:

Throughout RFC4596, msgserver is used as a feature tag while its use was never standardized. A standards compliant proxy server would simply ignore this msgserver parameter. msgserver was used in some UA capabilities draft but was later changed to actor="msg-taker". Somehow this change did not get through to RFC4596.
See http://www1.ietf.org/mail-archive/web/sip/current/msg08884.html for when the change took place.

Errata ID: 4716
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Gunnar Hellstrom
Date Reported: 2016-06-20
Verifier Name: Ben Campbell
Date Verified: 2016-06-20

Section 3.9.2 says:

languages=

It should say:

language=

Notes:

There are seven occurrences of this error in the sip examples of section 3.9.2.
As comparison, section 3.16.2 has the correct spelling in its three occurrences.
The parameter name refers to the language feature tag from RFC 2987, named "language".

Errata ID: 45
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-17

Section 3.5.1 says:

Y2 represents an audio/video phone that should only used
when needed.

It should say:

Y2 represents an audio/video phone that should only be
used when needed.

Notes:

word omission

from pending

Errata ID: 761
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-17

Section 3.1 says:

3.1. Routing of INVITE and MESSAGE to Different UA

It should say:

3.1. Routing of INVITE and MESSAGE to Different UAs

Notes:

from pending

Errata ID: 763
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-17

Section 2 says:

The may prefer to reach
the user on a device that supports video (because a video-conference
is desired).  

It should say:

They may prefer to reach
the user on a device that supports video (because a video-conference
is desired). 

Notes:

from pending

RFC 4601, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", August 2006

Note: This RFC has been obsoleted by RFC 7761

Note: This RFC has been updated by RFC 5059, RFC 5796, RFC 6226

Source of RFC: pim (rtg)

Errata ID: 44
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Stephen Nadas
Date Reported: 2006-11-07
Verifier Name: David Ward

Normative References say:

   [6]  Holbrook, H. and B. Cain, "Source-Specific Multicast for IP",
        RFC 4507, August 2006.

It should say:

   [6]  Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 
        4607, August 2006.

Notes:

Reference [6] in RFC 4601 is wrong, it says SSM for IP is
RFC 4507 when it is RFC 4607.

Errata ID: 2927
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ang Way Chuang
Date Reported: 2011-08-09
Verifier Name: Adrian Farrel
Date Verified: 2011-08-18

Section 4.2.2 says:

     void
     Update_SPTbit(S,G,iif) {
       if ( iif == RPF_interface(S)
             AND JoinDesired(S,G) == TRUE
             AND ( DirectlyConnected(S) == TRUE
                   OR RPF_interface(S) != RPF_interface(RP(G))
                   OR inherited_olist(S,G,rpt) == NULL
                   OR ( ( RPF'(S,G) == RPF'(*,G) ) AND
                        ( RPF'(S,G) != NULL ) )
                   OR ( I_Am_Assert_Loser(S,G,iif) ) {
          Set SPTbit(S,G) to TRUE
       }
     }

It should say:

     void
     Update_SPTbit(S,G,iif) {
       if ( iif == RPF_interface(S)
             AND JoinDesired(S,G) == TRUE
             AND ( DirectlyConnected(S) == TRUE
                   OR RPF_interface(S) != RPF_interface(RP(G))
                   OR inherited_olist(S,G,rpt) == NULL
                   OR ( ( RPF'(S,G) == RPF'(*,G) ) AND
                        ( RPF'(S,G) != NULL ) )
                   OR ( I_Am_Assert_Loser(S,G,iif) ) ) ) {
          Set SPTbit(S,G) to TRUE
       }
     }

Notes:

The logical evaluation is not properly enclosed.

Errata ID: 3727
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christopher Brown
Date Reported: 2013-09-16
Verifier Name: Adrian Farrel
Date Verified: 2013-09-17

Section 4.6.1 says:

A6:  Store new assert winner as AssertWinner(S,G,I) and assert
      winner metric as AssertWinnerMetric(S,G,I).
      Set Assert Timer to Assert_Time.
      If (I is RPF_interface(S)) AND (UpstreamJPState(S,G) == true)
      set SPTbit(S,G) to TRUE.

It should say:

A6:  Store new assert winner as AssertWinner(S,G,I) and assert
      winner metric as AssertWinnerMetric(S,G,I).
      Set Assert Timer to Assert_Time.
      If (I is RPF_interface(S)) AND (UpstreamJPState(S,G) == Joined)
      set SPTbit(S,G) to TRUE.

Notes:

The UpstreamJPState(S,G) should be 'Joined' not 'true'.

RFC 4605, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", August 2006

Source of RFC: magma (int)

Errata ID: 3285
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jon Hak Song
Date Reported: 2012-07-14
Verifier Name: Brian Haberman
Date Verified: 2012-07-24

Section 3 says:

Note that this does not protect against an "upstream loop".  For
   example, see the figure below:


           LAN 1  --------------------------------------
                  Upstream |              | Downstream
                           A              B
                Downstream |              | Upstream
           LAN 2  --------------------------------------

   B will unconditionally forward packets from LAN 1 to LAN 2, and A
   will unconditionally forward packets from LAN 2 to LAN 1.  This will
   cause an upstream loop.  A multicast routing protocol that employs a
   tree building algorithm is required to resolve loops like this.

It should say:

Note that this does not protect against an "upstream loop".  For
   example, see the figure below:


           LAN 1  --------------------------------------
                  Upstream |              | Downstream
                           A              B
                Downstream |              | Upstream
           LAN 2  --------------------------------------

   B will unconditionally forward packets from LAN 2 to LAN 1, and A
   will unconditionally forward packets from LAN 1 to LAN 2.  This will
   cause an upstream loop.  A multicast routing protocol that employs a
   tree building algorithm is required to resolve loops like this.

Notes:

Multicast packets should be forwarded from Upstream to Downstream.

RFC 4607, "Source-Specific Multicast for IP", August 2006

Source of RFC: ssm (rtg)

Errata ID: 906
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-08

Section 7.5 says:

applied to all source address

It should say:

applied to all source addresses

Notes:

from pending

RFC 4612, "Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type Registration", August 2006

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 42
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-11

Section 4 says:

   Additional information:

      Magic number(s):  File extension(s):  Macintosh File Type Code(s):

It should say:

   Additional information:

      Magic number(s):
      File extension(s):
      Macintosh File Type Code(s):

Notes:

line folding issue

Errata ID: 731
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-11

Section 5 says:

   Consider the following example, which describes a media stream that
   allows the transport of G.711 audio and T.38 fax information:

   m=audio 6800 RTP/AVP 0 98 a=rtpmap:98 t38/8000 a=fmtp:98
   T38FaxVersion=2;T38FaxRateManagement=transferredTCF

It should say:

   Consider the following example, which describes a media stream that
   allows the transport of G.711 audio and T.38 fax information:

      m=audio 6800 RTP/AVP 0 98
      a=rtpmap:98 t38/8000
      a=fmtp:98 T38FaxVersion=2;T38FaxRateManagement=transferredTCF

Notes:

line folding issue

Errata ID: 732
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-11

Section 7 says:

   [2]  Handley, M. and V. Jacobson, "SDP: Session Description
        Protocol", RFC 2327, April 1998.

It should say:

   [2]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 
        Description Protocol", RFC 4566, July 2006.

Notes:

Item [2] refers to RFC 2327.
That RFC had been obsoleted by RFC 4566 at the time of publication
of RFC 4612 (RFC 4566 had been published 3 weeks before RFC 4612).

RFC 4616, "The PLAIN Simple Authentication and Security Layer (SASL) Mechanism", August 2006

Note: This RFC has been updated by RFC 8996

Source of RFC: sasl (sec)

Errata ID: 6235
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Benjamin Kaduk
Date Reported: 2020-07-24
Verifier Name: Roman Danyliw
Date Verified: 2022-01-19

Section 1 says:

   The PLAIN mechanism should not be used without adequate data security
   protection as this mechanism affords no integrity or confidentiality
   protections itself.  The mechanism is intended to be used with data
   security protections provided by application-layer protocol,
   generally through its use of Transport Layer Security ([TLS])
   services.

It should say:

   The PLAIN mechanism should not be used without adequate data security
   protection as this mechanism affords no integrity or confidentiality
   protections itself.  The mechanism is intended to be used with data
   security protections provided by an application-layer protocol,
   generally through its use of Transport Layer Security ([TLS])
   services.

Notes:

Missing "an" in "an application-layer protocol".

RFC 4619, "Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks", September 2006

Source of RFC: pwe3 (int)

Errata ID: 41
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Verifier Name: Andrew G. Malis
Date Verified: 2006-11-01

Section 1 says:

   The main functions required to support frame relay PW by a
   Provider Edge (PE) include:

It should say:

   The main functions required to support frame relay PWs by a
   Provider Edge (PE) include:

Notes:

from pending

Errata ID: 817
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Verifier Name: Andrew G. Malis
Date Verified: 2006-11-01

 

(1)  [[posted separately.]]


(2)  improper wording (mismatch with what follows)

On page 3, the last paragraph above Figure 1 says:
                                                     v      vvv
   The following figure describes the reference models that are derived
   from [RFC3985] to support the frame relay PW emulated services.

It should say:

|  The following figure describes the reference model that is derived
   from [RFC3985] to support the frame relay PW emulated services.


(3)  typo (missing article)

Within Section 5, the 2nd list item on page 6 says:

   - Frame relay Local Management Interface (LMI) is terminated locally
     in the PE connected to the frame relay attachment circuit.

It should say:

|  - The Frame relay Local Management Interface (LMI) is terminated
     locally in the PE connected to the frame relay attachment circuit.


(4)  missing article

The last bullet within Section 7.2, near the top of page 8, says:

   - Payload

     The payload field corresponds to X.36/X.76 frame relay frame
     information field with the following components removed: bit/byte
     stuffing, frame relay header, and FCS.  [...]

It should say:

   - Payload

|    The payload field corresponds to an X.36/X.76 frame relay frame
     information field with the following components removed: bit/byte
     stuffing, frame relay header, and FCS.  [...]


(5)  typos/grammar

The last bulleted item in Section 7.6.2, on top of page 12, says:

                                        vvvvvv
|  - Otherwise, if the payload is longer, then the length specified in
|    the control word padding characters are removed according to the
     length field.
                     ^

It should say:
                                        v  v
|  - Otherwise, if the payload is longer than the length specified in
|    the control word, padding characters are removed according to the
     length field.
                     ^

(6)  typo

The second sentence in the first paragraph of Section 7.9, on page 12,

                                                           v
           [...].  If the PE detects a service-affecting condition for a
|  particular DLCI, as defined in [Q933] Q.933, Annex A.5, sited in IA
   FRF1.1, the PE MUST communicate to the remote PE the status of the PW
   that corresponds to the frame relay DLCI status.  [...]

should say:
                                                           v
           [...].  If the PE detects a service-affecting condition for a
|  particular DLCI, as defined in [Q933] Q.933, Annex A.5, cited in IA
   FRF1.1, the PE MUST communicate to the remote PE the status of the PW
   that corresponds to the frame relay DLCI status.  [...]


(7)  typo/grammar

The last sentence in the second paragraph of Section 7.9, on page 12,

   [...].  The IANA allocation registry of "Pseudowire Type" is defined
   in [RFC4446] along with initial allocated values.

should say:

|  [...].  The IANA allocation registry of "Pseudowire Types" is defined
|  in [RFC4446] along with initially allocated values.

Notes:

from pending

RFC 4623, "Pseudowire Emulation Edge-to-Edge (PWE3) Fragmentation and Reassembly", August 2006

Source of RFC: pwe3 (int)

Errata ID: 40
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Carlos Pignataro
Date Reported: 2006-10-25

Section 5.5 says:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |M|H|0|0|0|0|    Length         |              0                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |x|S|B|E|x|x|x|x|              Sequence Number                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |x|S|B|E|x|x|x|x|              Sequence Number                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

Extraneous part of the AVP Header in Figure 6.

Errata ID: 598
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Carlos Pignataro
Date Reported: 2006-10-25

Section 5.3 says:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|H|0|0|0|0|    Length         |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              MRU              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|H|0|0|0|0|    Length         |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               94              |              MRU              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

Missing "Attribute Type" in the AVP Header of Figure 4.

Errata ID: 599
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Carlos Pignataro
Date Reported: 2006-10-25

Section 5.4 says:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |M|H|0|0|0|0|    Length         |              0                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              MRRU             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |M|H|0|0|0|0|    Length         |              0                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               95              |              MRRU             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

Missing "Attribute Type" in the AVP Header of Figure 5.

Errata ID: 600
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Carlos Pignataro
Date Reported: 2006-10-25

Section 5.6 says:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |M|H|0|0|0|0|    Length         |              0                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |T|L|x|x|S|x|O|P|B|E|x|x|  Ver  |          Length (opt)         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |T|L|x|x|S|x|O|P|B|E|x|x|  Ver  |          Length (opt)         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Tunnel ID           |           Session ID          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             Ns (opt)          |             Nr (opt)          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Offset Size (opt)        |    Offset pad... (opt)        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

Extraneous part of the AVP Header in Figure 7.

RFC 4627, "The application/json Media Type for JavaScript Object Notation (JSON)", July 2006

Note: This RFC has been obsoleted by RFC 7159

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 607
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2007-10-17
Verifier Name: Alexey Melnikov
Date Verified: 2010-07-24

Section 2.2 says:

      object = begin-object [ member *( value-separator member ) ]
      end-object

It should say:

      object = begin-object [ member *( value-separator member ) ]
               end-object

Notes:

(edited by Alexey): Wrong indentation on the second line of the ABNF production, otherwise this is not legal ABNF.

RFC 4632, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", August 2006

Source of RFC: grow (ops)

Errata ID: 2955
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Olivier Le Rigoleur
Date Reported: 2011-09-03
Verifier Name: ron bonica
Date Verified: 2011-09-09

Section 6.1 says:

 C2: 10.24.16.0/20       \ |    |  _10.24.12.0 - 10.24.15.0__  |    |
                          \|    | / C4: 10.24.12.0/20        \ |    |
                                                 ~~~~~

It should say:

 C2: 10.24.16.0/20       \ |    |  _10.24.12.0 - 10.24.15.0__  |    |
                          \|    | / C4: 10.24.12.0/22        \ |    |

Notes:

~Should be 10.24.12.0/22 as described just above

Errata ID: 3485
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Markus Falb
Date Reported: 2013-02-18
Verifier Name: RonBonica
Date Verified: 2013-02-18

Section 2 says:

three classes of networks: Class A
(most significant address bits '00'), with 128 possible networks each
and 16777216 end systems

It should say:

three classes of networks: Class A
(most significant address bit '0'), with 128 possible networks each
and 16777216 end systems

Notes:

MSB bits ’00’ would mean that only 6 bits are available for the network part and this would mean only 64 CLASS A networks.

Errata ID: 4194
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: larry
Date Reported: 2014-12-04
Verifier Name: Benoit Claise
Date Verified: 2015-07-19

Section 5.3 says:

 Systems that process route announcements must be able to verify that
   information that they receive is acceptable according to policy
   rules.  Implementations that filter route advertisements must allow
   masks or prefix lengths in filter elements.  Thus, filter elements
   that formerly were specified as

      accept 172.16.0.0
      accept 172.25.120.0.0
      accept 172.31.0.0
      deny 10.2.0.0
      accept 10.0.0.0

It should say:

 Systems that process route announcements must be able to verify that
   information that they receive is acceptable according to policy
   rules.  Implementations that filter route advertisements must allow
   masks or prefix lengths in filter elements.  Thus, filter elements
   that formerly were specified as

      accept 172.16.0.0
      accept 172.25.120.0
      accept 172.31.0.0
      deny 10.2.0.0
      accept 10.0.0.0

Notes:

the second network address has 40 bits (5 groups of numbers instead of 4-32 bits).

172.25.120.0.0

RFC 4635, "HMAC SHA (Hashed Message Authentication Code, Secure Hash Algorithm) TSIG Algorithm Identifiers", August 2006

Note: This RFC has been obsoleted by RFC 8945

Source of RFC: dnsext (int)

Errata ID: 2332
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Donald Eastlake 3rd
Date Reported: 2010-07-19
Verifier Name: Brian Haberman
Date Verified: 2012-05-01

Section top 1st page says:

Network Working Group                                    D. Eastlake 3rd
Request for Comments: 4635                         Motorola Laboratories
Category: Standards Track                                    August 2006

It should say:

Network Working Group                                    D. Eastlake 3rd
Request for Comments: 4635                         Motorola Laboratories
Updates 2845
Category: Standards Track                                    August 2006

Notes:

This RFC, which I authored, clearly updates the Original RFC 2845 for TSIG: It makes it MANDATORY to implement HMAC-SHA1 and HMAC-SHA256 if you claim to support TSIG. It defines a new TSIG error code, BADTRUC, and specifies when it is to be returned. This are *significant* *normative* updates to RFC 2845. The RFC index for 2845 and 4635 should be updated to show this.

Errata ID: 4526
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Richard Hansen
Date Reported: 2015-11-09
Verifier Name: Brian Haberman
Date Verified: 2015-11-09

Section 2 says:

      Optional       hamc-sha384

It should say:

      Optional       hmac-sha384

Notes:

Simple typo (transposed characters).

2018-06-21: Status changed from "Held for Document Update" to "Verified".

RFC 4636, "Foreign Agent Error Extension for Mobile IPv4", October 2006

Source of RFC: mip4 (int)

Errata ID: 822
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Verifier Name: Brian Haberman
Date Verified: 2013-03-16

In the header, it does not include any relationship to other RFCs.

It should say:

Updates: 3344

Notes:

Section 4 of RFC 4636, on page 3, clearly states:

This document updates the Mobile IP base specification [4] regarding
the procedures followed by the foreign agent in the case that the
home agent fails authentication. [...]

... and [4] is RFC 3344.

I expected the line in the RFC heading, and appropriate links in the RFC index.

Has this been omitted by accident, or have there been strong
arguments to omit this significant link ?
In the former case, can that be corrected 'after the fact' ?

RFC 4640, "Problem Statement for bootstrapping Mobile IPv6 (MIPv6)", September 2006

Source of RFC: mip6 (int)

Errata ID: 36
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Verifier Name: Brian Haberman
Date Verified: 2012-05-11

Section 12 says:

   [RFC3776]     Galvin, J., "IAB and IESG Selection, Confirmation, and
                 Recall Process: Operation of the Nominating and Recall
                 Committees", BCP 10, RFC 3777, June 2004.

It should say:

   [RFC3776]     Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 
                 Protect Mobile IPv6 Signaling Between Mobile Nodes and Home 
                 Agents", RFC 3776, June 2004.

Notes:

In Section 12, near the bottom of page 20, a strange accident must
have hit the Ref. tagged [RFC3776]. This indeed should be a citation of the Mobile IP related RFC 3776, but it is a citiation of the unrelated RFC 3777.

RFC 4641, "DNSSEC Operational Practices", September 2006

Note: This RFC has been obsoleted by RFC 6781

Source of RFC: dnsop (ops)

Errata ID: 35
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Verifier Name: Olaf Kolkman
Date Verified: 2006-12-01

Section 4.2.1.1 says:

   Pre-publish key rollover involves four stages as follows:

      ----------------------------------------------------------------
      initial         new DNSKEY       new RRSIGs      DNSKEY removal
      ----------------------------------------------------------------
      SOA0            SOA1             SOA2            SOA3
      RRSIG10(SOA0)   RRSIG10(SOA1)    RRSIG11(SOA2)   RRSIG11(SOA3)

      DNSKEY1         DNSKEY1          DNSKEY1         DNSKEY1
      DNSKEY10        DNSKEY10         DNSKEY10        DNSKEY11
      DNSKEY11         DNSKEY11
      RRSIG1 (DNSKEY) RRSIG1 (DNSKEY)  RRSIG1(DNSKEY)  RRSIG1 (DNSKEY)
      RRSIG10(DNSKEY) RRSIG10(DNSKEY)  RRSIG11(DNSKEY) RRSIG11(DNSKEY)
      ----------------------------------------------------------------

It should say:

   Pre-publish key rollover involves four stages as follows:

      ----------------------------------------------------------------
      initial         new DNSKEY       new RRSIGs      DNSKEY removal
      ----------------------------------------------------------------
      SOA0            SOA1             SOA2            SOA3
      RRSIG10(SOA0)   RRSIG10(SOA1)    RRSIG11(SOA2)   RRSIG11(SOA3)

      DNSKEY1         DNSKEY1          DNSKEY1         DNSKEY1
      DNSKEY10        DNSKEY10         DNSKEY10        DNSKEY11
|                     DNSKEY11         DNSKEY11
      RRSIG1 (DNSKEY) RRSIG1 (DNSKEY)  RRSIG1(DNSKEY)  RRSIG1 (DNSKEY)
      RRSIG10(DNSKEY) RRSIG10(DNSKEY)  RRSIG11(DNSKEY) RRSIG11(DNSKEY)
      ----------------------------------------------------------------

                         Pre-Publish Key Rollover

Notes:

The mis-alignment of the indicated line breaks the intended
presentation of the procedure; cf. subsequent RFC text.


from pending

Errata ID: 790
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Verifier Name: Olaf Kolkman
Date Verified: 2006-12-01

Section 4.2.1.2 says:

   Double signature ZSK rollover involves three stages as follows:

      ----------------------------------------------------------------
      initial             new DNSKEY         DNSKEY removal
      ----------------------------------------------------------------
      SOA0                SOA1               SOA2
      RRSIG10(SOA0)       RRSIG10(SOA1)      RRSIG11(SOA2)
      RRSIG11(SOA1)

      DNSKEY1             DNSKEY1            DNSKEY1
      DNSKEY10            DNSKEY10           DNSKEY11
      DNSKEY11
      RRSIG1(DNSKEY)      RRSIG1(DNSKEY)     RRSIG1(DNSKEY)
      RRSIG10(DNSKEY)     RRSIG10(DNSKEY)    RRSIG11(DNSKEY)
      RRSIG11(DNSKEY)
      ----------------------------------------------------------------

                Double Signature Zone Signing Key Rollover

It should say:

   Double signature ZSK rollover involves three stages as follows:

      ----------------------------------------------------------------
      initial             new DNSKEY         DNSKEY removal
      ----------------------------------------------------------------
      SOA0                SOA1               SOA2
      RRSIG10(SOA0)       RRSIG10(SOA1)      RRSIG11(SOA2)
|                         RRSIG11(SOA1)

      DNSKEY1             DNSKEY1            DNSKEY1
      DNSKEY10            DNSKEY10           DNSKEY11
|                         DNSKEY11
      RRSIG1(DNSKEY)      RRSIG1(DNSKEY)     RRSIG1(DNSKEY)
      RRSIG10(DNSKEY)     RRSIG10(DNSKEY)    RRSIG11(DNSKEY)
|                         RRSIG11(DNSKEY)
      ----------------------------------------------------------------

                Double Signature Zone Signing Key Rollover

Notes:

The mis-alignment of the indicated 3 lines breaks the
intended presentation of the procedure; cf. subsequent RFC text.

The initial report was corrected by Yue Luo 2007-11-16 so that "RRSIG11" in the last row is in "New DNSKEY" stage instead of "initial" stage.

Errata ID: 791
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13

Section 3.5 says:

As the chain of
trust really is "a chain", there is not much sense in making one of
the keys in the chain several times larger then the others. 

It should say:

As the chain of
trust really is "a chain", there is not much sense in making one of
the keys in the chain several times larger than the others. 

Notes:

then -> than

from pending

Errata ID: 792
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13

Section 4.2.1.2 says:

   Making sure that the "new DNSKEY" phase lasts until the signature
   expiration time of the data in initial version of the zone is
   recommended. 

It should say:

   Making sure that the "new DNSKEY" phase lasts until the signature
|  expiration time of the data in the initial version of the zone is
   recommended.  

Notes:

missing article

from pending

RFC 4643, "Network News Transfer Protocol (NNTP) Extension for Authentication", October 2006

Source of RFC: nntpext (app)

Errata ID: 1787
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Antti-Juhani Kaijanaho
Date Reported: 2009-05-24
Verifier Name: Lisa Dusseault
Date Verified: 2009-11-25

Section 3.1 says:

user-pass-char = B-CHAR

NOTE: a server implementation MAY parse AUTHINFO USER and AUTHINFO
PASS specially so as to allow white space to be used within the
username or password.  Such implementations accept the additional
syntax (making these two items inconsistent with "token" in Section
9.8 of [NNTP]):

user-pass-char =/ SP / TAB

It should say:

user-pass-char = CTRL / %x21-FF

NOTE: a server implementation MAY parse AUTHINFO USER and AUTHINFO
PASS specially so as to allow white space to be used within the
username or password.  Such implementations accept the additional
syntax (making these two items inconsistent with "token" in Section
9.8 of [NNTP]):

user-pass-char =/ SP / TAB

Notes:

RFC 3977 defines B-CHAR in section 9.8 as:

B-CHAR = CTRL / TAB / SP / %x21-FF

It already contains TAB (%x09) and SP (%x20). Therefore, we have
to define user-pass-char as any byte character except NUL, TAB, LF, CR
and SP. Otherwise, the note does not make sense.

--- RFC Editor Note ---
This report was updated 2009-12-07 per a request from Julien Élie.

RFC 4646, "Tags for Identifying Languages", September 2006

Note: This RFC has been obsoleted by RFC 5646

Source of RFC: ltru (app)

Errata ID: 34
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By:
Date Reported: 2006-09-29
Verifier Name: Alexey Melnikov
Date Verified: 2009-06-19

Appendix B says:

 sl-rozaj (Resian dialect of Slovenian

It should say:

 sl-rozaj (Resian dialect of Slovenian)

Notes:

Missing ")"

Errata ID: 1061
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Frank Ellermann
Date Reported: 2007-11-09
Verifier Name: Alexey Melnikov
Date Verified: 2009-06-19

Section 3.1 says:

ASCCHAR    = %x21-25 / %x27-7E / UNICHAR ; Note: AMPERSAND is %x26
UNICHAR    = "&#x" 2*6HEXDIG ";"

It should say:

ASCCHAR    = %x21-25 / %x27-7E / UNICHAR ; Note: AMPERSAND is %x26
UNICHAR    = %x26.23.78 2*6HEXDIG ";"    ; starts with "&#x" 

Notes:

It has to be a lower case "x", i.e. %x78 in RFC 5234 ABNF.
(All quoted strings in ABNF are case-insensitive.)

RFC 4648, "The Base16, Base32, and Base64 Data Encodings", October 2006

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 2837
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Frank Ellermann
Date Reported: 2011-06-15
Verifier Name: Peter Saint-Andre
Date Verified: 2011-06-16

Section 16.2 says:

http://zgp.org/pipermail/p2p-hackers/2001-September/000315.html

It should say:

http://zgp.org/pipermail/p2p-hackers/2001-September/000316.html

Notes:

The same "off by one" issue was already present in RFC 3548 (obsoleted by RFC 4648). The archived article 315 has another author. Articles 316 and 319 are from the author noted in the RFCs, belong to a discussion of "web-safe base64" formats (incl. hex. + base32 alternatives), and specify the relevant base64 modification:

316 is shorter than 319, and nearer to the erroneous 315, so that was likely the intended article.

Errata ID: 5855
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Daniel Barclay
Date Reported: 2019-09-06
Verifier Name: Orie Steele
Date Verified: 2024-04-01

Section 10. says:

10.  Test Vectors

   BASE64("") = ""

   BASE64("f") = "Zg=="

   ...

Notes:

TL;DR: Test Vectors section should specify the character encoding (ASCII/UTF-8) of the _character_ sequences used to represent input-data _octet_ sequences.

The input to a Base 64/-32/-16 encoding operation is sequence of _octets_.

However, the test vector expressions use sequences of _characters_ to represent input _octet_ sequences.

That's a type mismatch (characters where octets are needed), and although it's pretty obvious that the strings were meant to represent octet sequences, there's no mention the the intended character encoding isn't, say, EBCDIC.

Some possible fixes:
1) The text should specify the character encoding (ASCII/UTF-8) to be used to interpret the character sequences as input octet sequences.
2) The input octet sequences should be represented with a more direct (encoding-independent) representation of octets (e.g., "0x48, 0x69".).

Errata ID: 7514
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Zachary Collier
Date Reported: 2023-05-09
Verifier Name: RFC Editor
Date Verified: 2023-05-09

Section 3.5 says:

If this property do not hold [...]

It should say:

If this property does not hold [...]

Notes:

The verb "do" in the clause "If this property do not hold" is incorrect. The correct verb is "does," as the subject "this property" is singular.

RFC 4650, "HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY)", September 2006

Source of RFC: msec (sec)

Errata ID: 2387
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Verifier Name: Tim Polk
Date Verified: 2010-07-20

 

(15) typo -- results in wrong Endpoint identifier specified

The 3rd paragraph of Appendix A, on page 25, says:

   To establish a call, it is assumed that endpoint B has obtained
   permission from the gatekeeper (not shown).  Endpoint B as the caller
   builds the MIKEY-DHHMAC I_message (see section 3) and sends the
   I_message encapsulated within the H.323-SETUP to endpoint A.  A
|  routing gatekeeper (GK) would forward this message to endpoint B; in
   case of a non-routing gatekeeper, endpoint B sends the SETUP directly
   to endpoint A.  [...]

It should say:

It should say:

   To establish a call, it is assumed that endpoint B has obtained
   permission from the gatekeeper (not shown).  Endpoint B as the caller
   builds the MIKEY-DHHMAC I_message (see section 3) and sends the
   I_message encapsulated within the H.323-SETUP to endpoint A.  A
|  routing gatekeeper (GK) would forward this message to endpoint A; in
   case of a non-routing gatekeeper, endpoint B sends the SETUP directly
   to endpoint A.  [...]

Notes:

from pending

RFC 4660, "Functional Description of Event Notification Filtering", September 2006

Note: This RFC has been updated by RFC 6665

Source of RFC: simple (rai)

Errata ID: 32
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-08
Verifier Name: Cullen Jennings
Date Verified: 2008-11-16

Section 11.1 says:

   [4]  Roach, A.B., Campbell, B., and J. Rosenberg, "A Session
        Initiation Protocol (SIP) Event Notification Extension for
        Resource Lists", RFC 4663, September 2006.

It should say:

   [4]  Roach, A.B., Campbell, B., and J. Rosenberg, "A Session
        Initiation Protocol (SIP) Event Notification Extension for
        Resource Lists", RFC 4662, August 2006.

RFC 4661, "An Extensible Markup Language (XML)-Based Format for Event Notification Filtering", September 2006

Source of RFC: simple (rai)

Errata ID: 918
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-09

Section 3.6.1 says:

   Previous XML
   document" in this context refers to the raw version of the most
   recent XML document that was sent to the subscriber, before the
   filters were applied to it.

It should say:

   "Previous XML
   document" in this context refers to the raw version of the most
   recent XML document that was sent to the subscriber, before the
   filters were applied to it.

Notes:

missing quotation marks

from pending

RFC 4662, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", August 2006

Source of RFC: sip (rai)

Errata ID: 1656
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Adam Roach
Date Reported: 2009-01-20
Verifier Name: Cullen Jennings
Date Verified: 2009-01-23

Section 6 says:

<resource uri="sip:bob@vancouver.example.com"">

It should say:

<resource uri="sip:bob@vancouver.example.com">

Notes:

One of the examples has two double quotes where it should have only one double quote.

This text appears on page 21. It is in a non-normative example; hence, it is merely editorial.

RFC 4668, "RADIUS Authentication Client MIB for IPv6", August 2006

Source of RFC: radext (sec)

Errata ID: 29
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-06
Verifier Name: Dan Romascanu
Date Verified: 2009-09-03

Section 7 says:

[[Around the page break from page 8 to page 9, and once more,
near the top of page 14]]

   --
   -- AccessRequests + PendingRequests + ClientTimeouts =
   -- Successfully received
   --

It should say:

   --
   -- AccessRequests - PendingRequests - ClientTimeouts =
   -- Successfully received
   --

Notes:

I strongly suspect that this is wrong (-- and it does not either
match the presentation style of the formulae above in the text).
Conceptually, it makes no sense to count 'PendingRequests' and
'ClientTimeouts' as 'Successfully received', and the subsequent
DESCRIPTION clauses strongly support my suspicion that both
instances of this formula in fact be as above.

from pending

RFC 4669, "RADIUS Authentication Server MIB for IPv6", August 2006

Source of RFC: radext (sec)

Errata ID: 28
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-06

The DESCRIPTION clause of the radiusAuthServResetTime OBJECT-TYPE declaration says:

                "If the server has a persistent state (e.g., a process)
                 and supports a 'reset' operation (e.g., can be told to
                 re-read configuration files), this value will be the
                 time elapsed (in hundredths of a second) since the
                 server was 'reset.'

It should say:

                "If the server has a persistent state (e.g., a process)
                 and supports a 'reset' operation (e.g., can be told to
                 re-read configuration files), this value will be the
|                time elapsed (in centiseconds) since the
|                server was 'reset'. 

Notes:

The original description does not conform to the 'rational quoting' style required by the RFC authoring guidelines.

Also, why not use the common ISO-standard unit-multiple name, "centiseconds" (abbreviation: "cs"), instead of the long-winded "hundredths of a second" ?

This also applies to the DESCRIPTION clauses of
- radiusAuthServUpTime (RFC 4669, top of page 7),

from pending

RFC 4672, "RADIUS Dynamic Authorization Client MIB", September 2006

Source of RFC: radext (sec)

Errata ID: 887
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-06
Verifier Name: Stefaan De Cnodder
Date Verified: 2006-11-07

 

severe MIB module structural problem
-- issue instantiated similarly in both RFC 4672 and 4673

Let's start with RFC 4672 and the RADIUS-DYNAUTH-CLIENT-MIB module.

On page 5 of RFC 4672, two module-global scalar objects are specified;
the DESCRIPTION clause of the
radiusDynAuthClientDisconInvalidServerAddresses OBJECT-TYPE says:

                                           [...].  This counter may
                 experience a discontinuity when the DAC module
                 (re)starts, as indicated by the value of
                 radiusDynAuthClientCounterDiscontinuity."

and the literally same sentence appears again in the DESCRIPTION
clause of the radiusDynAuthClientCoAInvalidServerAddresses OBJECT-TYPE.

This would make sense iff radiusDynAuthClientCounterDiscontinuity
would have been defined as another module-global scalar MIB object.
But unfortunately, radiusDynAuthClientCounterDiscontinuity is a
tabular row object in the radiusDynAuthServerTable, with separate
instances for every radiusDynAuthServerIndex instantiated there.
So, which object instance should be taken for reference ???
Moreover, should ever the radiusDynAuthServerTable be empty,
no such CounterDiscontinuity objects would be instantiated,
invalidating the semantical integrity of the MIB module.

Thus, let's take a closer look at the DESCRIPTION clause of the
radiusDynAuthClientCounterDiscontinuity OBJECT-TYPE, on page 17
of the RFC:

          DESCRIPTION
                "The time (in hundredths of a second) since the
                 last counter discontinuity.  A discontinuity may
                 be the result of a reinitialization of the DAC
                 module within the managed entity."

It remains unclear which scope was intended, i.e. whether "the last
counter discontinuity" was meant to just cover the counters within
the same conceptual row of the table, of it was meant to cover all
the counter objects in the MIB module.
If the former interpretation is to be accepted, the references
to this object from the scalar objects' DESCRIPTIONS quoted above
would be severely ambiguous.
In case of the latter interpretation, the semantics of this object
indeed do not depend in any way on the conceptual row, i.e. the
related radiusDynAuthServerIndex instance; but if an object of
the same semantics appears in every table row instantiated, all
of its instances must have the same value at any point in time.
Hence, the object with that semantics should have been modeled
as a module-global scalar object, and not as a tabular object !!!

IMHO, such a single, module-global scalar object would perhaps be
sufficient for the desired purpose.

In a similar way, the module-global scalar counters in the
RADIUS-DYNAUTH-SERVER-MIB module,
radiusDynAuthServerDisconInvalidClientAddresses and
adiusDynAuthServerCoAInvalidClientAddresses,
as specified on page 6 of RFC 4673, refer to the object,
radiusDynAuthServerCounterDiscontinuity,
which turns out to be a tabular row object in the
radiusDynAuthClientTable, not another scalar object,
thus leading to the same kind of ambiguity.

Taken altogether, the specifications are ambigous and will certainly
lead to interoperability problems.

I strongly propose to revise these MIB module specifications as
soon as possible.

Notes:

from pending


--VERIFIER COMMENT--
seems to be correct. The scalars do not have a discontinuity object.
That sentence should be removed or either an object has to be added. It
seems that the other mibs like RFC4668 also does not have such an object
for the scalars while it has a discontinuity timer for the objects in
the table... It should be for all or for none I would think.

Errata ID: 26
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-06
Verifier Name: Stefaan De Cnodder
Date Verified: 2006-11-07

 

(for RFC 4672 and 4673)

As specified in RFC 3410 and Part 1 of STD 62, RFC 3411, and
re-stated in the boilerplate Section 3, "The Internet-Standard
Management Framework", there's just one single
Management Information Base (MIB) comprised of various "MIB modules".
Thus, throughout the titles and the text bodies of the RFCs, the
proper term, "RADIUS ... MIB module" should be used consistently,
instead of the rather sluggish "RADIUS ... MIB".

Notes:

from pending

Errata ID: 889
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-06
Verifier Name: Stefaan De Cnodder
Date Verified: 2006-11-07

Section 4 says:

hundredths of a second

It should say:

centiseconds

Notes:

Why not use the common ISO-standard unit-multiple name, "centiseconds" (abbreviation: "cs"), instead of the long-winded "hundredths of a second" ?

This applies to the UNITS and the DESCRIPTION clauses of
- radiusDynAuthClientRoundTripTime (RFC 4672, page 7),
- radiusDynAuthClientCounterDiscontinuity (RFC 4672, page 17),

from pending

--VERIFIER COMMENT--
well, yes, centiseconds can be used as well but both terms are the same.

Errata ID: 890
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-06
Verifier Name: Stefaan De Cnodder
Date Verified: 2006-11-07

In Section 4

The DESCRIPTION clauses of several OBJECT-TYPE invocations 
contain the same spurious fragment of a sentence:

   [...].  Disconnect-NAK packets received from unknown addresses.

This fragment apparently has been copied inadvertently from the
DESCRIPTION clause for radiusDynAuthClientDisconInvalidServerAddress,
and it should be deleted afterwards, in all instances:

  - radiusDynAuthClientCoAInvalidServerAddresses  (page 5),
  - radiusDynAuthClientDisconRequests  (page 8),
  - radiusDynAuthClientDisconAuthOnlyRequests  (page 8), and
  - radiusDynAuthClientDisconRetransmissions  (page 8).

Notes:

from pending

--VERIFIER COMMENT--
correct, this sentence has to be removed everywhere.

RFC 4673, "RADIUS Dynamic Authorization Server MIB", September 2006

Source of RFC: radext (sec)

Errata ID: 888
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-06
Verifier Name: Stefaan De Cnodder
Date Verified: 2006-11-07

 

severe MIB module structural problem
-- issue instantiated similarly in both RFC 4672 and 4673

Let's start with RFC 4672 and the RADIUS-DYNAUTH-CLIENT-MIB module.

On page 5 of RFC 4672, two module-global scalar objects are specified;
the DESCRIPTION clause of the
radiusDynAuthClientDisconInvalidServerAddresses OBJECT-TYPE says:

                                           [...].  This counter may
                 experience a discontinuity when the DAC module
                 (re)starts, as indicated by the value of
                 radiusDynAuthClientCounterDiscontinuity."

and the literally same sentence appears again in the DESCRIPTION
clause of the radiusDynAuthClientCoAInvalidServerAddresses OBJECT-TYPE.

This would make sense iff radiusDynAuthClientCounterDiscontinuity
would have been defined as another module-global scalar MIB object.
But unfortunately, radiusDynAuthClientCounterDiscontinuity is a
tabular row object in the radiusDynAuthServerTable, with separate
instances for every radiusDynAuthServerIndex instantiated there.
So, which object instance should be taken for reference ???
Moreover, should ever the radiusDynAuthServerTable be empty,
no such CounterDiscontinuity objects would be instantiated,
invalidating the semantical integrity of the MIB module.

Thus, let's take a closer look at the DESCRIPTION clause of the
radiusDynAuthClientCounterDiscontinuity OBJECT-TYPE, on page 17
of the RFC:

          DESCRIPTION
                "The time (in hundredths of a second) since the
                 last counter discontinuity.  A discontinuity may
                 be the result of a reinitialization of the DAC
                 module within the managed entity."

It remains unclear which scope was intended, i.e. whether "the last
counter discontinuity" was meant to just cover the counters within
the same conceptual row of the table, of it was meant to cover all
the counter objects in the MIB module.
If the former interpretation is to be accepted, the references
to this object from the scalar objects' DESCRIPTIONS quoted above
would be severely ambiguous.
In case of the latter interpretation, the semantics of this object
indeed do not depend in any way on the conceptual row, i.e. the
related radiusDynAuthServerIndex instance; but if an object of
the same semantics appears in every table row instantiated, all
of its instances must have the same value at any point in time.
Hence, the object with that semantics should have been modeled
as a module-global scalar object, and not as a tabular object !!!

IMHO, such a single, module-global scalar object would perhaps be
sufficient for the desired purpose.

In a similar way, the module-global scalar counters in the
RADIUS-DYNAUTH-SERVER-MIB module,
radiusDynAuthServerDisconInvalidClientAddresses and
adiusDynAuthServerCoAInvalidClientAddresses,
as specified on page 6 of RFC 4673, refer to the object,
radiusDynAuthServerCounterDiscontinuity,
which turns out to be a tabular row object in the
radiusDynAuthClientTable, not another scalar object,
thus leading to the same kind of ambiguity.

Taken altogether, the specifications are ambigous and will certainly
lead to interoperability problems.

I strongly propose to revise these MIB module specifications as
soon as possible.

Notes:

from pending

--VERIFIER COMMENT--
seems to be correct. The scalars do not have a discontinuity object.
That sentence should be removed or either an object has to be added. It
seems that the other mibs like RFC4668 also does not have such an object
for the scalars while it has a discontinuity timer for the objects in
the table... It should be for all or for none I would think.

Errata ID: 25
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-06
Verifier Name: Stefaan De Cnodder
Date Verified: 2006-11-07

Section 4 says:

hundredths of a second

It should say:

centiseconds

Notes:

Why not use the common ISO-standard unit-multiple name, "centiseconds" (abbreviation: "cs"), instead of the long-winded "hundredths of a second" ?

This applies to the UNITS and the DESCRIPTION clause of
- radiusDynAuthServerCounterDiscontinuity (RFC 4673, page 17),

from pending

--VERIFIER COMMENT--
well, yes, centiseconds can be used as well but both terms are the same.

RFC 4676, "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", October 2006

Note: This RFC has been obsoleted by RFC 4776

Source of RFC: geopriv (rai)

Errata ID: 22
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-02

Section 3.2 says:

  option-code:  OPTION_GEOCONF_CIVIC (37)

It should say:

  option-code:  OPTION_GEOCONF_CIVIC (36)

Notes:

RFC 4677, "The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force", September 2006

Note: This RFC has been obsoleted by RFC 6722

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: gen

Errata ID: 21
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-06
Verifier Name: Russ Housley
Date Verified: 2010-04-12

Section 8.1 says:

 There are six kinds of RFCs:

   o  Proposed standards
   o  Draft standards
   o  Internet standards (sometimes called "full standards")
   o  Informational documents
   o  Experimental protocols
   o  Historic documents

It should say:

  There are seven kinds of RFCs:

   o  Proposed standards
   o  Draft standards
   o  Internet standards (sometimes called "full standards")
   o  Best Current Practice documents
   o  Informational documents
   o  Experimental protocols
   o  Historic documents

Notes:

This enumeration omits the "Best Current Practice" documents.
The approval process for BCPs is quite different than Informational
RFCs. Because BCPs are so important, including their role in publishing
the the IETF Standards Process itself, they shoudl be included in this
list.

RFC 4678, "Server/Application State Protocol v1", September 2006

Source of RFC: INDEPENDENT

Errata ID: 946
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-15
Verifier Name: Bob Braden
Date Verified: 2008-04-21

 

It should say:

  -

Notes:

Section 7.3.2 says:
"o Interval: These two bytes indicate a recommended polling interval
for the load balancer to use. The Group Workload Manager is
stating that any polling interval smaller than the suggested
interval would probably retrieve values before they have had a
chance to change."

but it does not mention the intended *unit* for this Interval.

from pending

Errata ID: 949
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-15
Verifier Name: Nevil Brownlee
Date Verified: 2010-04-05

Section 7.5.2 says:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Set Member State Reply(0x1025)|Size of SetMemberStateReply TLV|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Return Code  |
      +-+-+-+-+-+-+-+-+

It should say:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Set Member State Reply(0x1065)|Size of SetMemberStateReply TLV|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Return Code  |
      +-+-+-+-+-+-+-+-+

Notes:

Assuming the correct values are in section 4.2.
Further, 7.5.1. Set Member State Request has 1060,
agreeing with section 4.2.


from pending

Errata ID: 950
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-15
Verifier Name: Nevil Brownlee
Date Verified: 2010-04-05

Section 7.3.2 says:

   o  Interval: These two bytes indicate a recommended polling interval
      for the load balancer to use.  The Group Workload Manager is
      stating that any polling interval smaller than the suggested
      interval would probably retrieve values before they have had a
      chance to change.

It should say:

  o  Interval: These two bytes indicate a recommended polling interval
      (number of seconds) for the load balancer to use.  The Group
      Workload Manager is stating that any polling interval smaller than
      the suggested  interval would probably retrieve values before they
      have had a chance to change.

Notes:

does not mention the intended *unit* for this Interval -- seconds /
centiseconds / milliseconds ???

Section 7.3 seems to say the Intervals are in seconds.

from pending

Errata ID: 951
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-15
Verifier Name: Nevil Brownlee
Date Verified: 2010-04-05

Section 7.6.2 says:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Set LB State Reply (0x1025) | Size of Set LB State Reply TLV|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Return Code  |
      +-+-+-+-+-+-+-+-+

It should say:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Set LB State Reply (0x1055) | Size of Set LB State Reply TLV|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Return Code  |
      +-+-+-+-+-+-+-+-+

Notes:

Assuming the correct values are in section 4.2.

from pending

Errata ID: 2129
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-15
Verifier Name: Nevil Brownlee
Date Verified: 2010-04-05

Section 7.6.2 says:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Set LB State Reply (0x1025) | Size of Set LB State Reply TLV|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Return Code  |
      +-+-+-+-+-+-+-+-+

It should say:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Set LB State Reply (0x1055) | Size of Set LB State Reply TLV|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Return Code  |
      +-+-+-+-+-+-+-+-+

Notes:

Assuming the correct values are in section 4.2.

from pending

Errata ID: 20
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-15
Verifier Name: Nevil Brownlee
Date Verified: 2010-04-05

Section 7.1 says:

...will only be considered if 
the Trust flag is set while the state of the load balancer/scheduler is set.

It should say:

... will only be considered if 
the Trust flag has been set with a Set LB State message.

Notes:

also applies to section 7.2

from pending

RFC 4679, "DSL Forum Vendor-Specific RADIUS Attributes", September 2006

Source of RFC: INDEPENDENT

Errata ID: 597
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Carlos Pignataro
Date Reported: 2007-10-03
Verifier Name: Vince Mammoliti
Date Verified: 2007-10-03

Section 3.3.17 says:

Valid values for the sub-fields are as follows:

      Data Link

         0x01 AAL5
         0x02 Ethernet

It should say:

Valid values for the sub-fields are as follows:

      Data Link

         0x00 AAL5
         0x01 Ethernet

Notes:

"Data Link" values in the Value field of the Access-Loop-Encapsulation (Section 3.3.17, paragraph 14) are incorrect, should start from 0x00 and not 0x01 (see TR-101).

Errata ID: 19
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Verifier Name: Nevil Brownlee
Date Verified: 2010-04-05

Section 3.3.1 says:

      The slot identifier does not exceed 6 characters in length, and the port
      identifier does not exceed 3 characters in length using a '\' as a
      delimiter.

It should say:

      The slot identifier does not exceed 6 characters in length, and the port
      identifier does not exceed 3 characters in length using a '/' as a
      delimiter.

RFC 4683, "Internet X.509 Public Key Infrastructure Subject Identification Method (SIM)", October 2006

Source of RFC: pkix (sec)

Errata ID: 1047
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-18
Verifier Name: Sean Turner
Date Verified: 2010-07-29

Section A says:

It should say:

id-pkip
 FROM PKIXCRMF-2005
  { iso(1) identified-organization(3) dod(6) internet(1) security(5)
    mechanisms(5) pkix(7) id-mod(0) id-mod-crmf2005(36) }

Notes:

As exposed in Errata 2359 above, the OID 'id-pkip' used on page 19
needs to be IMPORTed from the PKIXCRMF-2005 ASN.1 module in
Appendix B of RFC 4211 -- otherwise the PKIXSIM ASN.1 module
in Appendix A of RFC 4683 will not compile.

Errata ID: 2362
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-18
Verifier Name: Sean Turner
Date Verified: 2010-07-29

Section A says:

The change exposed in Errata 2358 has to be applied to the
collected ASN.1 as well.

Errata ID: 2358
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-18
Verifier Name: Sean Turner
Date Verified: 2010-07-29

Section 5.1 says:

The ASN.1 at the bottom of page 11 says:

        SIM ::= SEQUENCE {
            hashAlg          AlgorithmIdentifier,
            authorityRandom  OCTET STRING,   -- RA-chosen random number
                                             -- used in computation of
                                             -- pEPSI
|           pEPSI            OCTET STRING    -- hash of HashContent
                                             -- with algorithm hashAlg
        }

It should say:

        SIM ::= SEQUENCE {
            hashAlg          AlgorithmIdentifier,
            authorityRandom  OCTET STRING,   -- RA-chosen random number
                                             -- used in computation of
                                             -- pEPSI
|           pEPSI            OCTET STRING    -- hash of hash of
|                                            -- HashContent with
                                             -- algorithm hashAlg
        }

It should say:

See above.

Notes:

Rationale:
PEPSI is an iterated hash; see Section 4.4 where the last
line on page 9 says,
where PEPSI = H(H(P || R || SIItype || SII))
-----------------v-------
and Section 5.2 for the definition of HashContent.

Errata ID: 2359
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-18
Verifier Name: Sean Turner
Date Verified: 2010-07-29

Section 5.3 says:

At the bottom of page 12, Section 5.3 says:

   id-regEPEPSI OBJECT IDENTIFIER ::= { id-pkip 3 }

For instance, a note should be added at the bottom of page 12:

   id-regEPEPSI OBJECT IDENTIFIER ::= { id-pkip 3 }
|
|  where id-pkip is defined in [RFC4211].

It should say:

See above.

Notes:

The OID, 'id-pkip' is neither defined within RFC 4683 nor imported.
Eventually, I found it being defined in RFC 4211.
That should be made explicit in Section 5.3 of RFC 4683 !

Errata ID: 2355
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-18
Verifier Name: Sean Turner
Date Verified: 2010-07-29

Section 4.4 says:

On page 10, the second-to-last paragraph of Section 4.4 says:

   Note that a secure communication channel MUST be used to pass P and
|  SII passing from the end entity to the RA, to protect them from
   disclosure or modification.

It should say:

   Note that a secure communication channel MUST be used to pass P and
|  SII from the end entity to the RA, to protect them from disclosure or
   modification.

It should say:

See above.

RFC 4684, "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)", November 2006

Source of RFC: l3vpn (int)

Errata ID: 18

Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: RFC Editor
Date Reported: 2006-11-28
Report Text:

This RFC was briefly posted with a misspelling in the title.
It was reposted with "Internet Protcol" corrected to "Internet Protocol".

---

Errata ID: 964
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tom Petch
Date Reported: 2006-11-29

Section 6 says:

withdrawls

It should say:

withdrawals

Notes:

from pending

Errata ID: 6246
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Robert Raszuk
Date Reported: 2020-07-31
Verifier Name: Eric Vyncke
Date Verified: 2021-02-08

Section 4 says:

 This prefix is structured as follows:

        +-------------------------------+
        | origin as        (4 octets)   |
        +-------------------------------+
        | route target     (8 octets)   |
        +                               +
        |                               |
        +-------------------------------+

It should say:

 This prefix is structured as follows:

        +-------------------------------+
        | origin as       (4 octets)    |
        +-------------------------------+
        | route target   (0-8 octets)   |
        +                               +
        |                               |
        +-------------------------------+

Notes:

The text defines route target as prefix however figure in section 4 does not reflect this correctly. This is editorial change, but apparently causing a lot of confusion in the community.

-- Verifier note --
The submitter is one of the author and the original text causes confusion, it is marked as verified.

RFC 4695, "RTP Payload Format for MIDI", November 2006

Note: This RFC has been obsoleted by RFC 6295

Source of RFC: avt (rai)

Errata ID: 17
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Lazzaro
Date Reported: 2007-01-18

 

In this errata, we briefly summarize several errata to RFC 4695,
reported by Alfred Hoenes. The listed errata either fix normative
problem in RFC 4695, or describe editorial errata that may be
particularly confusing to the implementor.

The presentation below is brief. See the main text of
<draft-ietf-avt-rfc4695-bis-00.txt> for a bis version of RFC 4695 that
integrates the fixes listed below in a more-complete way, and also
includes many other editorial fixes.

John Lazzaro, lazzaro@eecs.berkeley.edu

---

[1] In Appendix C.1 and Appendix C.2.3 of RFC 4695, an ABNF rule
related to System Chapter X is incorrectly defined as:

       <parameter> = "__" <h-list> ["_" <h-list>] "__"

The correct version of this rule is:

       <parameter> = "__" <h-list> *( "_" <h-list> ) "__"

[2] In Appendix C.6.3 of RFC 4695, the URIs permitted to be assigned
to the "url" parameter are not stated clearly.  URIs assigned to "url"
MUST specify either HTTP or HTTP over TLS transport protocols.

In Appendix C.7.1 and C.7.2 of RFC 4695, the transport
interoperability requirements for the "url" parameter are not stated
clearly.  For both C.7.1 and C.7.2, HTTP is REQUIRED and HTTP over TLS
is OPTIONAL.

[3] Both fmtp lines in both session description examples in Appendix
C.7.2 of RFC 4695 contain instances of the same syntax error (a
missing ";" at a line wrap after "cm_used=2M0.1.2").

[4] In Appendix D of RFC 4695, all uses of "*ietf-extension" in rules
are in error, and should be replaced with "ietf-extension".  Likewise,
all uses of "*extension" are in error, and should be replaced with
"extension".  This bug incorrectly lets the null token be assigned to
the j_sec, j_update, render, smf_info, and subrender parameters.

[5] In Appendix D of RFC 4695, the definitions of the <command-type>
and <chapter-rules> incorrectly allow lowercase letters to appear in
these strings. The correct definitions of these rules appear below:
    command-type =   [A] [B] [C] [F] [G] [H] [J] [K] [M]
                    [N] [P] [Q] [T] [V] [W] [X] [Y] [Z]

   chapter-list =   [A] [B] [C] [D] [E] [F] [G] [H] [J] [K]
                    [M] [N] [P] [Q] [T] [V] [W] [X] [Y] [Z]

   A        = %x41
   B        = %x42
   C        = %x43
   D        = %x44
   E        = %x45
   F        = %x46
   G        = %x47
   H        = %x48
   J        = %x4A
   K        = %x4B
   M        = %x4D
   N        = %x4E
   P        = %x51
   Q        = %x52
   T        = %x54
   V        = %x56
   W        = %x57
   X        = %x58
   Y        = %x59
   Z        = %x5A

[6] In Appendix D of RFC 4695, the definitions of the <four-octet>,
<nonzero-four-octet>, and <midi-chan> are incorrect.  The correct
definitions of these rules appear below:
    nonzero-four-octet =  (NZ-DIGIT 0*8(DIGIT))
                       / (%x30-33 9(DIGIT))
                       / ("4" %x30-31 8(DIGIT))
                       / ("42" %x30-38 7(DIGIT))
                       / ("429" %x30-33 6(DIGIT))
                       / ("4294" %x30-38 5(DIGIT))
                       / ("42949" %x30-35 4(DIGIT))
                       / ("429496" %x30-36 3(DIGIT))
                       / ("4294967" %x30-31 2(DIGIT))
                       / ("42949672" %x30-38 (DIGIT))
                       / ("429496729" %x30-34)

   four-octet        = "0" / nonzero-four-octet
   midi-chan         = DIGIT / ("1" %x30-35)
   DIGIT             = %x30-39
   NZ-DIGIT          = %x31-39

[7] In Appendix D of RFC4695, the rule <hex-octet> is
incorrect.  The correct definition of this rule appears below.
    hex-octet   = %x30-37 U-HEXDIG
   U-HEXDIG    = DIGIT / A / B / C / D / E / F

   ; DIGIT as defined in [5] above
   ; A, B, C, D, E, F as defined in [4] above

[8] In Appendix D of RFC4695, the rules <base64-unit> and
<base64-pad> are defined unclearly.  The rewritten rules
appear below:
    base64-unit = 4(base64-char)
   base64-pad  = (2(base64-char) "==") / (3(base64-char) "=")

Errata ID: 2673
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Lazzaro
Date Reported: 2010-12-18
Verifier Name: Robert Sparks
Date Verified: 2011-02-07

Section 3 says:

   If the LEN header field is nonzero, the MIDI list has the structure
   shown in Figure 3.

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Delta Time 0     (1-4 octets long, or 0 octets if Z = 1)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  MIDI Command 0   (1 or more octets long)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Delta Time 1     (1-4 octets long)                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  MIDI Command 1   (1 or more octets long)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Delta Time N     (1-4 octets long)                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  MIDI Command N   (0 or more octets long)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 3 -- MIDI list structure

It should say:

   If the LEN header field is nonzero, the MIDI list has the structure
   shown in Figure 3.

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Delta Time 0     (1-4 octets long, or 0 octets if Z = 0)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  MIDI Command 0   (1 or more octets long)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Delta Time 1     (1-4 octets long)                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  MIDI Command 1   (1 or more octets long)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Delta Time N     (1-4 octets long)                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  MIDI Command N   (0 or more octets long)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 3 -- MIDI list structure

Notes:

The sole change here is in the parenthesized text that follows
the "Delta Time 0" name in the first bitfield shown in Figure 3.
RFC 4695 has "1-4 octets long, or 0 octets if Z = 1". This
does not match the definition of Z in the main text. The corrected
figure text is: "1-4 octets long, or 0 octets if Z = 0". Thankfully, all
known implementations follow the main text in this
regard, so this bug should not have resulted in interoperability
issues. This bug has been fixed in the bis I-D intended to
obsolete RFC 4695 that is currently in Last Call in AVT.

RFC 4696, "An Implementation Guide for RTP MIDI", November 2006

Source of RFC: avt (rai)

Errata ID: 2790
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Lazzaro
Date Reported: 2011-04-25
Verifier Name: Robert Sparks
Date Verified: 2011-04-30

Section 2 says:

In Figure 1:

rtp_maxptime=0; guardtime=44100; render=synthetic; rinit="audio/asc";

In Figure 2:

rtp_ptime=0; rtp_maxptime=0; render=synthetic; rinit="audio/asc";

It should say:

In Figure 1:

rtp_maxptime=0; guardtime=44100; render=synthetic; rinit=audio/asc;

In Figure 2:

rtp_ptime=0; rtp_maxptime=0; render=synthetic; rinit=audio/asc;

Notes:

The double-quotes around audio/asc in the session descriptions shown
in Figures 1 and 2 should not exist; the Corrected Text version shows the
legal syntax for rinit assigns. This bug also appears in numerous examples
in RFC 4695, an RFC that will soon be obsolete, and replaced with a new
RFC whose examples also have this bug fixed (I'm an author of the
RFCs). As we are not aware of implementations that use the rinit parameter,
we do not expect interoperability concerns due to the buggy examples.

RFC 4705, "GigaBeam High-Speed Radio Link Encryption", October 2006

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: gen

Errata ID: 14
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-01

Section 11 says:

   [IKEv2]    Kaufman, C., "The Internet Key Exchange (IKEv2) Protocol",
              RFC 2306, December 2005.                

It should say:

   [IKEv2]    Kaufman, C., "The Internet Key Exchange (IKEv2) Protocol",
              RFC 4306, December 2005.

Notes:

Errata ID: 1920
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Hoffman
Date Reported: 2009-10-20
Verifier Name: Russ Housley
Date Verified: 2010-04-12

Section 7 says:

   [GCM]      McGrew, D. and J. Viega, "The Galois/Counter Mode of
              Operation (GCM)", Submission to NIST.
              http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/
              gcm/gcm-spec.pdf, January 2004.  [Soon: NIST SP 800-38D.]

It should say:

[GCM]      Dworkin, M. "Recommendation for Block Cipher Modes
of Operation: Galois/Counter Mode (GCM) and GMAC", NIST Special
Publication 800-38D, November 2007.

Notes:

The original link is dead.

RFC 4707, "Netnews Administration System (NAS)", October 2006

Source of RFC: INDEPENDENT

Errata ID: 5813
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2019-08-18
Verifier Name: Adrian Farrel
Date Verified: 2019-08-18

Section 6.1.1 says:

   Answer = response-code [answertext] CRLF
            text CRLF
            "." CRLF

It should say:

   answer = response-code [answertext] CRLF
            *(text CRLF)
            "." CRLF

Notes:

There may be zero, one or more additional lines of text followed by a CRLF.

Errata ID: 5815
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2019-08-18
Verifier Name: Adrian Farrel
Date Verified: 2019-08-18

Section 6.3.3.1 says:

   help-answer =  "410" [answertext] CRLF
                  text CRLF
                  "." CRLF
   help-answer =/ "100" [answertext] CRLF
                  text CRLF
                  "." CRLF

It should say:

   help-answer =  "410" [answertext] CRLF
                  *(text CRLF)
                  "." CRLF
   help-answer =/ "100" [answertext] CRLF
                  *(text CRLF)
                  "." CRLF

Notes:

Per the examples shown, it is clear that zero, one, or more lines of text may be supplied.

Errata ID: 5816
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2019-08-18
Verifier Name: Adrian Farrel
Date Verified: 2019-08-18

Section 6.3.3.2 says:

   info-answer =  "400" [answertext] CRLF
                  text CRLF
                  "." CRLF
   info-answer =/ "101" [answertext] CRLF
                  text CRLF
                  "." CRLF

It should say:

   info-answer =  "400" [answertext] CRLF
                  *(text CRLF)
                  "." CRLF
   info-answer =/ "101" [answertext] CRLF
                  *(text CRLF)
                  "." CRLF

Notes:

Per the examples shown in the text, it is clear that a response may include zero, one, or many additional lines of text.

Errata ID: 5821
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2019-08-18
Verifier Name: Adrian Farrel
Date Verified: 2019-08-18

Section 6.3.3.6 says:

   The data consist of a newsgroup- or hierarchy-name/status indicator
   pair per line.  Name and status indicator must be separated by at
   least one white space.
[...]
   listdata    =  name WSP list-status

It should say:

   The data consist of a newsgroup- or hierarchy-name/status indicator
   pair per line.  Name and status indicator must be separated by at
   least one white space.
[...]
   listdata    =  name 1*WSP list-status

Notes:

Only one white space is allowed in the definition of listdata. I suggest allowing several WSP for consistency with the description.
Same remark for the definition of listdata in Section 6.3.3.7 (LSTR command).

Errata ID: 5822
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2019-08-18
Verifier Name: Adrian Farrel
Date Verified: 2019-08-18

Section 6.3.3.6 says:

   list-answer =/ "401" [answertext] CRLF
                  text CRLF
                  "." CRLF
   list-answer =/ "510" [answertext] CRLF
                   text CRLF
                   "." CRLF

It should say:

   list-answer =/ "401" [answertext] CRLF
                  *(text CRLF)
                  "." CRLF
   list-answer =/ "510" [answertext] CRLF
                  *(text CRLF)
                  "." CRLF

Notes:

Zero, one, or more lines of text are allowed.

Errata ID: 5823
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2019-08-18
Verifier Name: Adrian Farrel
Date Verified: 2019-08-18

Section 6.3.3.7 says:

   lstr-answer =/ "401" [answertext] CRLF
                  text CRLF
                  "." CRLF
   lstr-answer =/ "510" [answertext] CRLF
                  text CRLF
                  "." CRLF

It should say:

   lstr-answer =/ "401" [answertext] CRLF
                  *(text CRLF)
                  "." CRLF
   lstr-answer =/ "510" [answertext] CRLF
                  *(text CRLF)
                  "." CRLF

Notes:

Zero, one, or more lines of text are allowed.

Errata ID: 5834
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2019-08-18
Verifier Name: Adrian Farrel
Date Verified: 2019-08-18

Section 11 says:

    Mod-Sub-Adr      no           N    no         Submission address

It should say:

    Mod-Sub-Adr      no           N    yes        Submission address

Notes:

This header is repeatable, as stated in its definition in Section 6.3.4.
A newsgroup may have several e-mails to be reached.

Errata ID: 5836
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2019-08-18
Verifier Name: Adrian Farrel
Date Verified: 2019-08-18

Section 11 says:

    Article-Length   no           H    no         Article length

It should say:

    Article-Length   no          H/N    no        Article length

Notes:

As stated in the definition of Article-Length in Section 6.3.4, it also applies to newsgroups.

Errata ID: 5841
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2019-08-19
Verifier Name: Adrian Farrel
Date Verified: 2019-09-01

Section 6.3.3 says:

   text          = %d1-9 /           ; all octets except
                   %d11-12 /         ; US-ASCII NUL, CR and LF
                   %d14-255

It should say:

   text          = *(%d1-9 /         ; all octets except
                     %d11-12 /       ; US-ASCII NUL, CR and LF
                     %d14-255)

Notes:

Each time the "text" keyword is used in ABNF definitions in this RFC, it means "any number, including none, of octets except NUL, CR and LF" and not one such octet.

Errata ID: 5826
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2019-08-18
Verifier Name: Adrian Farrel
Date Verified: 2019-08-18

Section 6.3.3.10 says:

   <-- GETP 0 0 0 humanities
   --> 615 data follow

It should say:

   <-- GETP 0 0 0 humanities
   --> 613 data follow

Notes:

Section 10 and also getp-answer in Section 6.3.3.10 indicates a 613 response code for GETP.

Errata ID: 5827
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2019-08-18
Verifier Name: Adrian Farrel
Date Verified: 2019-08-18

Section 6.3.3.11 says:

   <-- GETA 0 0 0 humanities
   --> 613 data follow

It should say:

   <-- GETA 0 0 0 humanities
   --> 615 data follow

Notes:

Section 10 and also geta-answer in Section 6.3.3.11 indicates a 615 response code for GETA.

Errata ID: 5831
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2019-08-18
Verifier Name: Adrian Farrel
Date Verified: 2019-08-18

Section 6.3.4 says:

   Serial

   Header:      Serial

   Used for:    hierarchy
   Mandatory:   no
   Inheritable: no
   Repeatable:  no
   Description: Timestamp for hierarchy data.
   Comment:     For a detailed description, see Section 6.4.
   Example:     Serial: 20020821102413

   Used for:    newsgroup
   Mandatory:   no
   Inheritable: no
   Repeatable:  no
   Description: Timestamp for newsgroup data.
   Comment:     For a detailed description, see Section 6.4.
   Example:     Serial: 20020821102413

It should say:

   Serial

   Header:      Serial

   Used for:    hierarchy
   Mandatory:   no
   Inheritable: no
   Repeatable:  no
   Description: Timestamp for hierarchy data.
   Comment:     For a detailed description, see Section 6.3.3.10.
   Example:     Serial: 20020821102413

   Used for:    newsgroup
   Mandatory:   no
   Inheritable: no
   Repeatable:  no
   Description: Timestamp for newsgroup data.
   Comment:     For a detailed description, see Section 6.3.3.10.
   Example:     Serial: 20020821102413

Notes:

Its use as a timestamp is described in Section 6.3.3.10, for both hierarchies and newsgroups.

RFC 4717, "Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks", December 2006

Source of RFC: pwe3 (int)

Errata ID: 2257
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ron Insler
Date Reported: 2010-05-13
Verifier Name: Stewart Bryant
Date Verified: 2011-08-05

Section 7.2 says:

7.2.  VPC Case

   When configured for a VPC cell relay service, both PEs SHOULD act as
   a VP cross-connect in accordance with the OAM procedures defined in
   [I.610].

   The PEs SHOULD be able to process and pass the following OAM cells
   transparently according to [I.610]:

     - F4 AIS (segment and end-to-end)
     - F4 RDI (segment and end-to-end)
     - F4 loopback (segment and end-to-end)

It should say:

7.2.  VPC Case

   When configured for a VPC cell relay service, both PEs SHOULD act as
   a VP cross-connect in accordance with the OAM procedures defined in
   [I.610].

   The PEs SHOULD be able to process and pass the following OAM cells
   transparently according to [I.610]:

     - F4 AIS (segment and end-to-end)
     - F4 RDI (segment and end-to-end)
     - F4 loopback (segment and end-to-end)
     - F4 CC (segment and  end-to-end)

Notes:

As per [I.610] all OAM cells must be transferred transparently , RFC 4717 does not mentioned the F4 CC OAM cell .

Errata ID: 2920
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-10-17
Verifier Name: Stewart Bryant
Date Verified: 2011-08-05

 

(10b)
The T bit explanation (in the lower half of page 27) contains
misleading and inappropriate wording related to Figure 4.
Figure 4 generally applies for both the proper AAL5 CPCS-SDU payload
or the case of an ATM OAM cell payload.  Furthermore, it should be
noted that Section 8.1 (which contains and explains Figure 4)
specifies the Flags field as 'reserved, should be set to 0'.
This is incompatible with the subsequent text that requires the T bit
to be set to 1 for an OAM cell.  Therefore, to avoid confusion,
the clause referencing to Figure 4 should better be deleted from
the T bit explanation.

Hence, the text,

       Bit (T) of the control word indicates whether the packet contains
       an ATM admin cell or an AAL5 payload.  If T = 1, the packet
|      contains an ATM admin cell, encapsulated according to the N-to-
|      one cell relay encapsulation, Figure 4.  If not set, the PDU
       contains an AAL5 payload.  The ability to transport an ATM cell
       in the AAL5 SDU mode is intended to provide a means of enabling
       administrative functionality over the AAL5 VCC (though it does
       not endeavor to preserve user-cell and admin-cell
       arrival/transport ordering).

should say:

       Bit (T) of the control word indicates whether the packet contains
       an ATM admin cell or an AAL5 payload.  If T = 1, the packet
|      contains an ATM admin cell.  If T = 0, the PDU contains an AAL5
       payload.  The ability to transport an ATM cell in the AAL5 SDU
       mode is intended to provide a means of enabling administrative
       functionality over the AAL5 VCC (though it does not endeavor to
       preserve user-cell and admin-cell arrival/transport ordering).

Notes:

This is section 10(b) from Erratum 999

Errata ID: 2922
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-10-17
Verifier Name: Stewart Bryant
Date Verified: 2011-08-05

 

(12)  Section 11.2.1 -- internal mis-ref.

The 3rd bullet in Section 11.2.1, near the bottom of page 30, says:

     - The E and C bits of the fragment shall be set as defined in
|      section 9.
               ^
It should say:

     - The E and C bits of the fragment shall be set as defined in
|      section 11.1.
               ^^^^

Rationale:
  As explained above for item (11a), the specification of these bits in
  Section 11.1 is contrary to their (hidden) use in Sections 8 and 9.


                                          ^

(14)  Section 12 -- internal mis-refs

The last paragraph of Section 12 (on page 32) says:

   In both the ATM-to-PSN and PSN-to-ATM directions, the method used to
   transfer the CLP and EFCI information of the individual cells into
   the ATM-specific field, or flags, of the PW packet is described in
|  detail in sections 6 through 9 for each encapsulation mode.
                      ^         ^
It should say:

   In both the ATM-to-PSN and PSN-to-ATM directions, the method used to
   transfer the CLP and EFCI information of the individual cells into
   the ATM-specific field, or flags, of the PW packet is described in
|  detail in sections 8 through 11 for each encapsulation mode.
                      ^         ^^

Notes:

This is elements 12 and 14 of erratum 999

RFC 4718, "IKEv2 Clarifications and Implementation Guidelines", October 2006

Note: This RFC has been obsoleted by RFC 5996

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 1502
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Pasi Eronen
Date Reported: 2008-09-11
Verifier Name: Russ Housley
Date Verified: 2009-01-07

Section 5.11.4 says:

After the CREATE_CHILD_SA exchanges, three IKE_SAs exist between
A and B; the one containing the lowest nonce inherits the CHILD_SAs.

It should say:

After the CREATE_CHILD_SA exchanges, three IKE_SAs exist between 
A and B; of the two new IKE_SAs, the one containing the lowest nonce 
is redundant and will be closed; the other one inherits the CHILD_SAs.

Notes:

Pointed out by Jeffrey Sun on the ipsec mailing list, 2008-03-31

RFC 4728, "The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4", February 2007

Source of RFC: manet (rtg)

Errata ID: 917
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-04-20
Verifier Name: Dave Maltz
Date Verified: 2007-04-20

Section 4.1 says:

   -  In DSR, the route returned in each Route Reply that is received by
      the initiator of a Route Discovery (or that is learned from the
      header of overhead packets, as described in Section 8.1.4)
      represents a complete path (a sequence of links) leading to the
      destination node.  [...]

It should say:

   -  In DSR, the route returned in each Route Reply that is received by
      the initiator of a Route Discovery (or that is learned from the
      header of overheard packets, as described in Section 8.1.4)
      represents a complete path (a sequence of links) leading to the
      destination node.  [...]

Notes:

Text was inteded to not talk about "overhead" packets, but (promiscuously) "overheard" packets!

from pending

Errata ID: 920
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-04-20
Verifier Name: Dave Maltz
Date Verified: 2007-04-20

Section 6.5 says:

      Opt Data Len

         8-bit unsigned integer.  Length of the option, in octets,
         excluding the Option Type and Opt Data Len fields.

It should say:

      Opt Data Len

         8-bit unsigned integer.  Length of the option, in octets,
         excluding the Option Type and Opt Data Len fields. In the
         basic form of this Option, this field has the value 2.
         (See Section 7.4.1 for an extended version of this Option.)

Notes:

Provide specific value of the length field.

from pending

Errata ID: 924
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-04-20
Verifier Name: Dave Maltz
Date Verified: 2007-04-20

Section 7.1 says:

      Flow Identification

         The flow ID for this flow, as described in Section 3.5.1.

It should say:

      Flow Identifier

         The flow ID for this flow, as described in Section 3.5.1.

Notes:

Terminology inconsistency.

from pending

Errata ID: 926
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-04-20
Verifier Name: Dave Maltz
Date Verified: 2007-04-20

Section 8.2.1 says:

   The behavior of a node processing a packet containing DSR Options
   header with both a DSR Source Route option and a Route Request option
   is unspecified.

It should say:

   The behavior of a node processing a packet containing a DSR Options
   header with both a DSR Source Route option and a Route Request option
   is unspecified.

Notes:

missing article.

from pending

Errata ID: 927
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-04-20
Verifier Name: Dave Maltz
Date Verified: 2007-04-20

Section 8.6.2 says:

   -  Set the Protocol field of the IP header to the protocol number
      assigned for DSR (48).

It should say:

   -  Set the Protocol field of the previous header to the protocol
      number assigned for DSR (48).

Notes:

The procedure specified in Section 8.6.2 is a bit misleading in its
last step; if followed literally, it will mess up the packet in the
case that there is any Hop-by-Hop Options header present after the
IP header.

from pending

Errata ID: 919
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-04-20
Verifier Name: Adrian Farrel
Date Verified: 2011-08-23

Section 6.4 says:

         When the Opt Data Len is greater than that required for
         the fixed portion of the Route Error plus the necessary
         Type-Specific Information as indicated by the Option Type
         value in the option, the remaining octets are interpreted as
         extensions.

It should say:

         When the Opt Data Len is greater than that required for
         the fixed portion of the Route Error plus the necessary
         Type-Specific Information as indicated by the Error Type
         value in the option, the remaining octets are interpreted as
         extensions.

Notes:

As can be seen from the context, the "Type-Specific Information" is
dependent on the "Error Type" field value, not the "Option Type"
field value.

RFC 4730, "A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)", November 2006

Source of RFC: sipping (rai)

Errata ID: 13
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Eric Burger
Date Reported: 2006-11-30
Verifier Name: Cullen Jennings
Date Verified: 2009-01-08

Section 5.1 says:

   DRegexCharacter  = DIGIT / "A" / "B" / "C" / "D" / "R" / "*" / "#" /
                              "a" / "b" / "c" / "d" / "r"

It should say:

   DRegexCharacter  = DIGIT / "A" / "B" / "C" / "D" / "R" / "X" / "*" / "#"
                              "a" / "b" / "c" / "d" / "r" / "x"

Notes:

The ABNF for DRegex (page 29) is missing an 'x'.

Errata ID: 3209
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2012-05-03
Verifier Name: Gonzalo Camarillo
Date Verified: 2013-04-04

Section 7.4, 7.5 says:

urn:ietf:xml:ns:kpml-...

It should say:

urn:ietf:params:xml:ns:kpml-...

Notes:

The headlines of Sections 7.4 and 7.5 contain garbled versions of
the IETF protocol parameter sub-namespaces defined in the RFC:
the hierarchical element "params:" is missing.

This flaw also is mirrored in the Table of Contents of the RFC.

RFC 4733, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", December 2006

Note: This RFC has been updated by RFC 4734, RFC 5244

Source of RFC: avt (rai)

Errata ID: 984
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-12-19
Verifier Name: Tom Taylor
Date Verified: 2006-12-19

Section 7 says:

   Legal event codes range from 0 to 255.  The initial registry content
   is shown in Table 7, and consists of the sixteen events defined in
   Section 3 of this document.  The remaining codes have the following
   disposition:

   o  codes 17-22, 50-51, 90-95, 113-120, 169, and 206-255 are available
      for assignment;

   o  codes 23-40, 49, and 52-63 are reserved for events defined in
      [16];

   o  codes 121-137 and 174-205 are reserved for events defined in [17];

   o  codes 16, 41-48, 64-88, 96-112, 138-168, and 170-173 are reserved
      in the first instance for specifications reviving the
      corresponding RFC 2833 events, and in the second instance for
      general assignment after all other codes have been assigned.

It should say:

   Legal event codes range from 0 to 255.  The initial registry content
   is shown in Table 7, and consists of the sixteen events defined in
   Section 3 of this document.  The remaining codes have the following
   disposition:

|  o  codes 17-22, 50-51, 90-95, 113-120, 169, and 212-255 are available
      for assignment;
                                                   ^^^

   o  codes 23-40, 49, and 52-63 are reserved for events defined in
      [16];

|  o  codes 121-137, 144-159, and 174-211 are reserved for events
      defined in [17];
                   ^^^^^^^^^^         ^^^
                          vv             vvvvvvvvvv
|  o  codes 16, 41-48, 64-89, 96-112, 138-143, 160-168, and 170-173 are
      reserved in the first instance for specifications reviving the
      corresponding RFC 2833 events, and in the second instance for
      general assignment after all other codes have been assigned.

Notes:

Section 7 of RFC 4733, in the lower half of page 39,
specifies the initial content of the IANA maintained
audio-telephone-event-registry subregistry, as intended
for after publication of RFC 4733 -- see (1a) below.

Additionally, in Appendix A, on page 47, RFC 4733 restates this
information and summarizes the disposition of the legacy event
code assignments from the obsoleted RFC 2833, in particular,
Table 8 represents the current assignments and dispositions,
as per RFC 4733 -- see (1b) below.

Unfortunately, there are significant inconsistencies between
these two text blocks. Looking into Ref. [17] of RFC 4733,
the ietf-avt-rfc2833biscas draft, it turns out that both
text blocks are also inconsistent with that future RFC.
Consequently, the current IANA file is also affected.

from pending

Errata ID: 985
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-12-19
Verifier Name: Tom Taylor
Date Verified: 2006-12-19

Appendix A, Table 8, says:

   +-------------+---------------------------------------+-------------+
   | Event Codes | RFC 2833 Description                  | Disposition |
   +-------------+---------------------------------------+-------------+
   |        0-15 | DTMF digits                           | RFC 4733    |
   |          16 | Line flash (deprecated)               | Reserved    |
   |       23-31 | Unused                                | [16]        |
   |       32-40 | Data and fax                          | [16]        |
   |       41-48 | Data and fax (V.8bis, deprecated)     | Reserved    |
   |       52-63 | Unused                                | [16]        |
   |       64-89 | E.182 line events (deprecated)        | Reserved    |
   |      96-112 | Country-specific line events          | Reserved    |
   |             | (deprecated)                          |             |
   |     121-127 | Unused                                | [17]        |
   |     128-137 | Trunks: MF 0-9                        | [17]        |
   |     138-143 | Trunks: other MF (deprecated)         | Reserved    |
   |     144-159 | Trunks: ABCD signalling               | [17]        |
   |     160-168 | Trunks: various (deprecated)          | Reserved    |
   |     170-173 | Trunks: various (deprecated)          | Reserved    |
   |     174-205 | Unused                                | [17]        |
   +-------------+---------------------------------------+-------------+

It should say:

   +-------------+---------------------------------------+-------------+
   | Event Codes | RFC 2833 Description                  | Disposition |
   +-------------+---------------------------------------+-------------+
   |        0-15 | DTMF digits                           | RFC 4733    |
   |          16 | Line flash (deprecated)               | Reserved    |
   |       23-31 | Unused                                | [16]        |
   |       32-40 | Data and fax                          | [16]        |
   |       41-48 | Data and fax (V.8bis, deprecated)     | Reserved    |
|  |          49 | Calling Tone                          | [16]        |
   |       52-63 | Unused                                | [16]        |
   |       64-89 | E.182 line events (deprecated)        | Reserved    |
   |      96-112 | Country-specific line events          | Reserved    |
   |             | (deprecated)                          |             |
   |     121-127 | Unused                                | [17]        |
   |     128-137 | Trunks: MF 0-9                        | [17]        |
   |     138-143 | Trunks: other MF (deprecated)         | Reserved    |
   |     144-159 | Trunks: ABCD signalling               | [17]        |
   |     160-168 | Trunks: various (deprecated)          | Reserved    |
   |     170-173 | Trunks: various (deprecated)          | Reserved    |
|  |     174-211 | Unused                                | [17]        |
   +-------------+---------------------------------------+-------------+

Notes:

Section 7 of RFC 4733, in the lower half of page 39,
specifies the initial content of the IANA maintained
audio-telephone-event-registry subregistry, as intended
for after publication of RFC 4733 -- see (1a) below.

Additionally, in Appendix A, on page 47, RFC 4733 restates this
information and summarizes the disposition of the legacy event
code assignments from the obsoleted RFC 2833, in particular,
Table 8 represents the current assignments and dispositions,
as per RFC 4733 -- see (1b) below.

Unfortunately, there are significant inconsistencies between
these two text blocks. Looking into Ref. [17] of RFC 4733,
the ietf-avt-rfc2833biscas draft, it turns out that both
text blocks are also inconsistent with that future RFC.
Consequently, the current IANA file is also affected.

from pending

Errata ID: 3489
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Xavier Marjou
Date Reported: 2013-02-18
Verifier Name: Gonzalo Camarillo
Date Verified: 2013-04-18

Section 2.1 says:

Named telephone events are carried as part of the audio stream and
MUST use the same sequence number and timestamp base as the regular
audio channel to simplify the generation of audio waveforms at a
gateway. 

It should say:

Named telephone events are carried as part of the audio stream and 
if they use the same SSRC (therefore the same timing and sequence 
number space), they MUST use the same timestamp clock rate as the 
regular audio channel.

Notes:

RFC4733 was written in a way to avoid the multiple clock-rate problem by mandating the use of the same SSRC for DTMF and audio. However it's not explicitly written, which brings an ambiguity. It was commented that RFC4733 needs to be updated. (c.f. http://tools.ietf.org/wg/avtext/minutes?item=minutes-85-avtext.html). This errata obsoletes the previous proposed errata (ID: 3451).

Errata ID: 986
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-12-19

Section 2.6.2 says:

the current duration of tone signal

It should say:

the current duration of a tone signal

Notes:

from pending

Errata ID: 987
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-12-19

Section 8 says:

Magnus Westerland

It should say:

Magnus Westerlund

Notes:

from pending

RFC 4740, "Diameter Session Initiation Protocol (SIP) Application", November 2006

Source of RFC: aaa (ops)

Errata ID: 6028
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Luke Mewburn
Date Reported: 2020-03-25
Verifier Name: Robert Wilton
Date Verified: 2024-01-12

Throughout the document, when it says:

"Digest-QoP".

It should say:

"Digest-Qop".

Notes:

The AVP is referenced in section 9.5.6 from RFC 4590 (obsoleted by RFC 5090) which names the AVP "Digest-Qop" (i.e., with a lowercase 'p').

The error occurs in various sections, including 9.5.3, 9.5.4, 9.5.5, 9.5.6, 11.

RFC 4741, "NETCONF Configuration Protocol", December 2006

Note: This RFC has been obsoleted by RFC 6241

Source of RFC: netconf (ops)

Errata ID: 1456
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Andy Bierman
Date Reported: 2008-06-19
Verifier Name: Dan Romascanu
Date Verified: 2009-09-03

Section 8.7.5.1 says:

    <rpc message-id="101"
           xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <copy-config>
          <source>
            <running/>
          </source>
          <target>
            <startup/>
          </target>
        </copy-config>
      </rpc>

It should say:

   <rpc message-id="101"
           xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <copy-config>
          <target>
            <startup/>
          </target>
          <source>
            <running/>
          </source>
        </copy-config>
      </rpc>

Notes:

The parameters are in the wrong order.
The XSD and the example on page 40 are correct.

RFC 4742, "Using the NETCONF Configuration Protocol over Secure SHell (SSH)", December 2006

Note: This RFC has been obsoleted by RFC 6242

Source of RFC: netconf (ops)

Errata ID: 948
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Eliot Lear
Date Reported: 2007-05-10
Verifier Name: Dan Romascanu
Date Verified: 2009-09-03

Section 3 says:

   [user@client]$ ssh -s server.example.org -p <830> netconf

It should say:

  [user@client]$ ssh -s server.example.org -p 830 netconf

Notes:

<830> --> 830

from pending

Errata ID: 1628
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Pasi Eronen
Date Reported: 2008-12-04
Verifier Name: Dan Romascanu
Date Verified: 2009-08-31

Section 7 says:

IANA is also requested to assign "netconf" as an SSH Service Name as
defined in [RFC4250], as follows:

         Service Name                  Reference
         -------------                 ---------
         netconf                       RFC 4742

It should say:

IANA is also requested to assign "netconf" as an SSH Connection
Protocol Subsystem Name as defined in [RFC4250], as follows:

         Subsystem Name                Reference
         -------------                 ---------
         netconf                       RFC 4742

Notes:

The IANA registry (http://www.iana.org/assignments/ssh-parameters)
also needs to be fixed.

Errata ID: 12
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Heikki Kortti
Date Reported: 2007-03-30

Section 9.1 says:

   [RFC4721]  Enns, R., Ed., "NETCONF Configuration Protocol", RFC 4721,
              December 2006.

It should say:

   [RFC4741]  Enns, R., Ed., "NETCONF Configuration Protocol", RFC 4741, 
              December 2006.

Notes:

RFC4742 refers throughout to the NETCONF specification as RFC4721, even though NETCONF is really specified in RFC4741.

from pending

Errata ID: 947
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eliot Lear
Date Reported: 2007-05-10
Verifier Name: Dan Romascanu
Date Verified: 2009-09-03

Section 3 says:

   In order to allow NETCONF traffic to be easily identified and
   filtered by firewalls and other network devices, NETCONF servers MUST
   default to providing access to the "netconf" SSH subsystem only when
   the SSH session is established using the IANA-assigned TCP port
   <830>.

It should say:

   In order to allow NETCONF traffic to be easily identified and
   filtered by firewalls and other network devices, NETCONF servers MUST
   default to providing access to the "netconf" SSH subsystem only when
   the SSH session is established using the IANA-assigned TCP port
   830.

Notes:

<830> --> 830

from pending

RFC 4743, "Using NETCONF over the Simple Object Access Protocol (SOAP)", December 2006

Note: This RFC has been updated by RFC 8996

Source of RFC: netconf (ops)

Errata ID: 7317
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dominik Krappel
Date Reported: 2023-01-24
Verifier Name: RFC Editor
Date Verified: 2023-02-27

Section 3.6. says:

   S:               <full-name>Charlie Root</full-name>
   S:                 <dept>1</dept>
   S:                 <id>1</id>
   S:               </company-info>

It should say:

   S:               <full-name>Charlie Root</full-name>
   S:               <company-info>
   S:                 <dept>1</dept>
   S:                 <id>1</id>
   S:               </company-info>

Notes:

The opening tags for <company-info> seem to be missing in the example.

Errata ID: 7318
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dominik Krappel
Date Reported: 2023-01-24
Verifier Name: Robert Wilton
Date Verified: 2024-01-12

Section 3.6. says:

   S:               <full-name>Fred Flintstone</full-name>
   S:                 <dept>2</dept>
   S:                 <id>2</id>
   S:               </company-info>

It should say:

   S:               <full-name>Fred Flintstone</full-name>
   S:               <company-info>
   S:                 <dept>2</dept>
   S:                 <id>2</id>
   S:               </company-info>

Notes:

The opening tags for <company-info> seem to be missing in the example.

RFC 4745, "Common Policy: A Document Format for Expressing Privacy Preferences", February 2007

Source of RFC: geopriv (rai)

Errata ID: 1455
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Chris Newman
Date Reported: 2008-06-16
Verifier Name: Cullen Jennings
Date Verified: 2009-01-08

Section 7.4 says:

   pair.  Times are expressed in XML dateTime format.

It should say:

   pair.  Times are expressed in XML dateTime [W3C-Schema] format with a
   mandatory timezone.

Notes:

The reference to W3C Schema is normative. The timezone needs to be mandatory
in order to ensure interoperability. An alternative would be to reference
RFC 3339 normatively.

RFC 4746, "Extensible Authentication Protocol (EAP) Password Authenticated Exchange", November 2006

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 10
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-26
Verifier Name: Russ Housley
Date Verified: 2010-03-15

Section 4.3.7 says:

   Consequently, EAP-PAX requires the use of a
   Diffie-Hellman group with modulus larger than 3000.  

It should say:

   Consequently, EAP-PAX requires the use of a
   Diffie-Hellman group with modulus larger than 3000 bits. 

Notes:

Provide units.

Errata ID: 11
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-26
Verifier Name: Russ Housley
Date Verified: 2010-03-15

Section 3.2 says:

   These 52+L octets are then attached to the packet as the payload.

It should say:

   These 54+L octets are then attached to the packet as the payload.

Notes:

Correction based on preceding text (page 16) and Figure 8

Errata ID: 954
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-26
Verifier Name: Russ Housley
Date Verified: 2010-03-15

Section 3.2 says:

(1)  [typo]

On page 6 of RFC 4746, the 1st paragraph of Section 2.1 says:

   PAX_STD is a simple nonce-based authentication using the strong
   long-term key.  [...]

It should say:

|  PAX_STD is a simple nonce-based authentication using a strong
   long-term key.  [...]


(2)  [missing article]

Within Section 2.2, near the bottom of page 8, RFC 4746 says:

   When using EAP-PAX with Wireless LAN, clients SHOULD validate that
   the certificate's wlanSSID extension matches the SSID of the network
   to which it is currently authenticating.

It should say:

|  When using EAP-PAX with a Wireless LAN, clients SHOULD validate that
   the certificate's wlanSSID extension matches the SSID of the network
   to which it is currently authenticating.


(3)  [missing article]

On page 9, the 1st paragraph of Section 2.3 says:

   Messages PAX_STD-2, PAX_STD-3, PAX_SEC-4, PAX_SEC-5, and PAX_ACK
   contain optional component ADE.  [...]

It should say:

   Messages PAX_STD-2, PAX_STD-3, PAX_SEC-4, PAX_SEC-5, and PAX_ACK
|  contain an optional component ADE.  [...]


(4)  [extraneous word]

The 2nd paragraph of Section 4, at the bottom of page 19, says:

                                          [...].  Also note that the
   security of PAX can be proved using under the Random Oracle model.

It should say:
                                          [...].  Also note that the
|  security of PAX can be proved under the Random Oracle model.

Notes:

Corrects minor editorial errors.

RFC 4747, "The Virtual Fabrics MIB", November 2006

Source of RFC: imss (ops)

Errata ID: 1045
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-12
Verifier Name: Keith McCloghrie
Date Verified: 2007-09-18

Section 6 says:

[in the DESCRIPTION of t11vfLocallyEnabledOperStatus, page 13]
 
      DESCRIPTION
           "This object is used to report the operational status of
            Virtual Fabric tagging on this Port.

            SET operation   Description
            --------------  -------------------------------------------
            off(1)          Virtual Fabric tagging is disabled on this
                            Port.

            on(2)           Virtual Fabric tagging is enabled on this
                            Port."

It should say:

       DESCRIPTION
           "This object is used to report the operational status of
            Virtual Fabric tagging on this Port.

            Operational-Status Description
            ------------------ -------------------------------------
            off(1)             Virtual Fabric tagging is disabled on
                               this Port.

            on(2)              Virtual Fabric tagging is enabled on
                               this Port."

Notes:

--VERIFIER NOTES--

t11vfLocallyEnabledOperStatus is a read-only object -- which means it
it does not have "SET operation"s. So, the problem is the line in
t11vfLocallyEnabledOperStatus's DESCRIPTION shown above.

[Aside: traditionally, "operational status" is always read-only, as in
ifOperStatus in RFC 2863.]

Errata ID: 1046
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-12
Verifier Name: Keith McCloghrie
Date Verified: 2007-09-18

Section 6 says:

[in the DESCRIPTION of t11vfLocallyEnabledTable, page 12]
 
       DESCRIPTION
           "A table for assigning and reporting operational status of
            locally-enabled Virtual Fabric IDs to Ports.  The set of
            Virtual Fabrics operational on the Port is the bit-wise
            'AND' of the set of locally-enabled VF_IDs of this Port
            and the locally-enabled VF_IDs of the attached Port."

It should say:

       DESCRIPTION
           "A table for reporting operational status of
            locally-enabled Virtual Fabric IDs to Ports.  The set of
            Virtual Fabrics operational on the Port is the bit-wise
            'AND' of the set of locally-enabled VF_IDs of this Port
            and the locally-enabled VF_IDs of the attached Port."

Notes:

--VERIFIER NOTES--

This phrase makes it seem like t11vfLocallyEnabledTable is
read-write and needs to be changed.

The only reaon this table has a RowStatus object (and a StorageType) is
so that a management application can limit the rows in the table to be
only those which it is interested in. It doesn't allow the operational
status to be changed. Therefore the words "assigning and" need to be
removed, so that the definition is as above.

RFC 4750, "OSPF Version 2 Management Information Base", December 2006

Source of RFC: ospf (rtg)

Errata ID: 3292
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Kirkham
Date Reported: 2012-07-23
Verifier Name: Stewart Bryant
Date Verified: 2013-01-09

Section 5 says:

   ospfTrapCompliance MODULE-COMPLIANCE
        STATUS       obsolete
        DESCRIPTION
           "The compliance statement."
        MODULE       -- this module
        MANDATORY-GROUPS { ospfTrapControlGroup }

        GROUP       ospfTrapControlGroup
        DESCRIPTION
           "This group is optional but recommended for all
           OSPF systems."
        ::= { ospfTrapCompliances 1 }

It should say:

   ospfTrapCompliance MODULE-COMPLIANCE
        STATUS       obsolete
        DESCRIPTION
           "The compliance statement."
        MODULE       -- this module
        GROUP       ospfTrapControlGroup
        DESCRIPTION
           "This group is optional but recommended for all
           OSPF systems."
        ::= { ospfTrapCompliances 1 }

Notes:

ospfTrapControlGroup is listed both in the MANDATORY-GROUPS clause and in a GROUP clause. Per RFC 2580, Conformance Statements for SMIv2 (brackets added to indicate pertinent rule):

"5.4.2. Mapping of the GROUP clause

The GROUP clause, which need not be present, is repeatedly used to
name each object and notification group which is conditionally
mandatory for compliance to the MIB module. The GROUP clause can
also be used to name unconditionally optional groups. [A group named
in a GROUP clause must be absent from the correspondent MANDATORY-
GROUPS clause.]"

It is listed in both clauses in RFC 1850 as well (which RFC 4750 obsoletes). It is STATUS current in RFC 1850 and STATUS obsolete in 4750; however, obsolete or not, it is not legal according to SMI rules.

RFC 4752, "The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism", November 2006

Source of RFC: sasl (sec)

Errata ID: 4863
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lars Francke
Date Reported: 2016-11-13
Verifier Name: Stephen Farrell
Date Verified: 2017-01-20

Section 3.1 - 3.3 says:

conf_flag

It should say:

conf_req_flag

Notes:

The three sections 3.1, 3.2 and 3.3 refer to a flag "conf_flag" which does not exist in the GSS_Wrap call as specified in RFC 2743 (https://tools.ietf.org/html/rfc2743#page-65). The correct name is "conf_req_flag".

I also looked in the previous version of RFC 2743 -> RFC 2078 but the same applies there.

RFC 4753, "ECP Groups For IKE and IKEv2", January 2007

Note: This RFC has been obsoleted by RFC 5903

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 9
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2007-04-23

Section 7 says:

   The Diffie-Hellman public value is obtained by concatenating the x
   and y values.

   The format of the Diffie-Hellman shared secret value is the same as
   that of the Diffie-Hellman public value.

Notes:

The last paragraph is incorrect. The Diffie-Hellman shared secret
contains only the x value. The y value is not included in the shared
secret.

Errata ID: 1800
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Paul Hoffman
Date Reported: 2009-07-02
Verifier Name: Tim Polk
Date Verified: 2009-07-09

Section 7 and 8 says:

It should say:

Sections 8.1, 8.2 and 8.3 end with text of the following form:

   These are concatenated to form

   g^ir:
          (binary data value appropriate to each example)

   This is the value that is used in the formation of SKEYSEED.

In each of these three sections, the above text should be replaced with:

      The Diffie-Hellman shared secret value is girx.

Notes:

The technical errata at <http://www.rfc-editor.org/errata_search.php?eid=9> is incorrect. It causes the specification in section 7 to disagree with the examples in section 8.

RFC 4754, "IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA)", January 2007

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 4748
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Arnaud EBALARD
Date Reported: 2016-07-26
Verifier Name: Paul Wouters
Date Verified: 2024-02-27

Section 8 says:

8.1.  ECDSA-256

   IANA assigned the ID value 9 to ECDSA-256.

   ...

          vvvv
 00000048 00090000 CB28E099 9B9C7715 FD0A80D8 E47A7707 9716CBBF 917DD72E
 97566EA1 C066957C 86FA3BB4 E26CAD5B F90B7F81 899256CE 7594BB1E A0C89212
 748BFF3B 3D5B0315

8.2.  ECDSA-384

   IANA assigned the ID value 10 to ECDSA-384.

   ...

          vvvv
 00000068 000A0000 FB017B91 4E291494 32D8BAC2 9A514640 B46F53DD AB2C6994
 8084E293 0F1C8F7E 08E07C9C 63F2D21A 07DCB56A 6AF56EB3 B263A130 5E057F98
 4D38726A 1B468741 09F417BC A112674C 528262A4 0A629AF1 CBB9F516 CE0FA7D2
 FF630863 A00E8B9F

8.3.  ECDSA-521

   IANA assigned the ID value 11 to ECDSA-521.

   ...

          vvvv
 0000008C 000B0000 0154FD38 36AF92D0 DCA57DD5 341D3053 988534FD E8318FC6
 AAAAB68E 2E6F4339 B19F2F28 1A7E0B22 C269D93C F8794A92 78880ED7 DBB8D936
 2CAEACEE 54432055 22510177 05A70302 90D1CEB6 05A9A1BB 03FF9CDD 521E87A6
 96EC926C 8C10C836 2DF49753 67101F67 D1CF9BCC BF2F3D23 9534FA50 9E70AAC8
 51AE01AA C68D62F8 66472660

It should say:

8.1.  ECDSA-256

   IANA assigned the ID value 9 to ECDSA-256.

   ...

          vvvv
 00000048 09000000 CB28E099 9B9C7715 FD0A80D8 E47A7707 9716CBBF 917DD72E
 97566EA1 C066957C 86FA3BB4 E26CAD5B F90B7F81 899256CE 7594BB1E A0C89212
 748BFF3B 3D5B0315

8.2.  ECDSA-384

   IANA assigned the ID value 10 to ECDSA-384.

   ...

          vvvv
 00000068 0A000000 FB017B91 4E291494 32D8BAC2 9A514640 B46F53DD AB2C6994
 8084E293 0F1C8F7E 08E07C9C 63F2D21A 07DCB56A 6AF56EB3 B263A130 5E057F98
 4D38726A 1B468741 09F417BC A112674C 528262A4 0A629AF1 CBB9F516 CE0FA7D2
 FF630863 A00E8B9F

8.3.  ECDSA-521

   IANA assigned the ID value 11 to ECDSA-521.

   ...

          vvvv
 0000008C 0B000000 0154FD38 36AF92D0 DCA57DD5 341D3053 988534FD E8318FC6
 AAAAB68E 2E6F4339 B19F2F28 1A7E0B22 C269D93C F8794A92 78880ED7 DBB8D936
 2CAEACEE 54432055 22510177 05A70302 90D1CEB6 05A9A1BB 03FF9CDD 521E87A6
 96EC926C 8C10C836 2DF49753 67101F67 D1CF9BCC BF2F3D23 9534FA50 9E70AAC8
 51AE01AA C68D62F8 66472660

Notes:

In Figure 14 of Section 3.8 of RFC 7296 describing IKEv2 AUTH Payload format, the Auth Method field is a one byte field located just after the Payload Length field, i.e. Auth Method is encoded in the fifth byte of the AUTH Payload.

In Section 8.1 of RFC 4754, the example AUTH payload for ECDSA-256 encodes the Auth Method (0x09) in the sixth byte of the AUTH Payload instead of the fifth. This is the same in section 8.2 for ECDSA-384 and 8.3 for ECDSA-512, for which the Auth Method values (respectively 0x0A and 0x0B) are also encoded in the sixth bytes instead of the fifth.

RFC 4757, "The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows", December 2006

Note: This RFC has been updated by RFC 6649

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 1372
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kevin Coffman
Date Reported: 2008-03-14
Verifier Name: Sean Turner
Date Verified: 2011-06-01

Section 7.3 says:

 // Generate checksum of message -
 //  SGN_CKSUM + Token.Confounder
 //   Key derivation salt = 15

 Sgn_Cksum = MD5((int32)15, Token.Header,
                Token.Confounder);

It should say:

 // Generate checksum of message -
 //  SGN_CKSUM + Token.Confounder
 //   Key derivation salt = 13

 Sgn_Cksum = MD5((int32)13, Token.Header,
                Token.Confounder);

Notes:

The final RFC appears to have cut-and-paste typo regarding the salt value used when generating the checksum for a WRAP token. The value used for a MIC token is 15, the value used for a WRAP token is 13.

Love Hörnquist Åstrand <lha@kth.se> pointed out that an earlier draft shows the values actually in use:

http://tools.ietf.org/html/draft-brezak-win2k-krb-rc4-hmac-02

Errata ID: 1646
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Luke Howard
Date Reported: 2008-12-29
Verifier Name: Sean Turner
Date Verified: 2011-06-01

Section 7.2 7.3 says:

                           Kseq = HMAC(Kss, "fortybits", (int32)0);
                                        // len includes terminating null
                           memset(Kseq+7, 0xab, 7)

It should say:

                           Kseq = HMAC(Kss, "fortybits", (int32)0);
                                        // len includes terminating null
                           memset(Kseq+7, 0xab, 9)

Notes:

applies both to section 7.2 and 7.3, confirmed by Larry Zhu

Errata ID: 1674
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ganga Mahesh Siddem
Date Reported: 2009-01-30
Verifier Name: Sean Turner
Date Verified: 2011-06-28

Section 7.3 says:

                   if (encrypt)
                           RC4(Kcrypt, Token.Confounder);

                   // Sum the data buffer

                   Sgn_Cksum += MD5(data);         // Append to checksum

                   // Encrypt the data (if encrypting)

                   if (encrypt)
                           RC4(Kcrypt, data);

It should say:

                   // Sum the data buffer

                   Sgn_Cksum += MD5(data);         // Append to checksum

                   // Encrypt the  Confounder + data (if encrypting)

                   tmp=concat(Token.Confounder,data);

                   if (encrypt)
                           RC4(Kcrypt, tmp); /* tmp=Confounder + data */
               
                   memcpy(Token.Confounder,tmp,8);

                   memcpy(data,tmp+8,(tmp.len-8));             

Notes:

Notes : 1.Verified RC4 Encryption and Decryption on (Token.Confounder+Data) with Kcrypt key .
2.Verified RC4(K,x+y) !=RC4(K,x);RC4(K,y)
3.Reporting this issue after Larry's Feedback.

Errata ID: 1675
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ganga Mahesh Siddem
Date Reported: 2009-01-30
Verifier Name: Sean Turner
Date Verified: 2011-06-01

Section 7.3 says:

                 // Create the sequence number

                   if (direction == sender_is_initiator)
                   {
                           memset(&Token.SEND_SEQ[4], 0xff, 4)
                   }
                   else if (direction == sender_is_acceptor)
                   {
                           memset(&Token.SEND_SEQ[4], 0, 4)
                   }

It should say:

                                            // Create the sequence number

                   if (direction == sender_is_initiator)
                   {
                           memset(&Token.SEND_SEQ[4], 0, 4)
                   }
                   else if (direction == sender_is_acceptor)
                   {
                           memset(&Token.SEND_SEQ[4], 0xff, 4)
                   }

Notes:

SEND_SEQ values are interchanged .

Errata ID: 2562
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michiko Short
Date Reported: 2010-10-13
Verifier Name: Sean Turner
Date Verified: 2011-06-01

Section 3 says:

9.  TGS-REP encrypted part (includes application session key),
          encrypted with the TGS authenticator subkey (T=8)

It should say:

9.  TGS-REP encrypted part (includes application session key),
          encrypted with the TGS authenticator subkey (T=9)

Notes:

Typo

Errata ID: 2628
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Matthias Schertler
Date Reported: 2010-11-12
Verifier Name: Sean Turner
Date Verified: 2011-06-01

Section 5 says:

nonce (edata.Confounder, 8);
memcpy (edata.Data, data);
edata.Checksum = HMAC (K2, edata);

It should say:

nonce (edata.Confounder, 8);
memcpy (edata.Data, data);
edata.Checksum = HMAC (K2, concat(edata.Confounder, edata.Data));

Errata ID: 1647
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ganga Mahesh Siddem
Date Reported: 2008-12-31
Verifier Name: Sean Turner
Date Verified: 2011-06-01

Section 7.2 and 7.3 says:

In 7.2:

if (exportable)
                   {
                           Kseq = HMAC(Kss, "fortybits", (int32)0);
                                        // len includes terminating null
                           memset(Kseq+7, 0xab, 7)
                   }

In 7.3:
 
if (exportable)
                   {

                           Kcrypt = HMAC(Klocal, "fortybits", (int32)0);
                                       // len includes terminating null
                           memset(Kcrypt+7, 0xab, 7);
                   }

Again in 7.3:

if (exportable)
                   {
                           Kseq = HMAC(Kss, "fortybits", (int32)0);
                                       // len includes terminating null
                           memset(Kseq+7, 0xab, 7)
                   }

It should say:

In 7.2:

if (export)
                   {
                           Kseq = HMAC(Kss, "fortybits", (int32)0);
                                        // len includes terminating null
                           memset(Kseq+7, 0xab, 7)
                   }

In 7.3:
 
if (export)
                   {

                           Kcrypt = HMAC(Klocal, "fortybits", (int32)0);
                                       // len includes terminating null
                           memset(Kcrypt+7, 0xab, 7);
                   }

Again in 7.3:

if (export)
                   {
                           Kseq = HMAC(Kss, "fortybits", (int32)0);
                                       // len includes terminating null
                           memset(Kseq+7, 0xab, 7)
                   }

Notes:

misnamed "export" argument . Larry Zhu confirmed this issue

Sean Turner add (as pointed out by Magnus Nystrom) that there were actually three exportable/export replacements needed: 1 in Section 7.2 and two in Section 7.3.

Errata ID: 1651
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ganga Mahesh Siddem
Date Reported: 2009-01-10
Verifier Name: Sean Turner
Date Verified: 2011-06-01

Section 7.3 says:

// new encryption key salted with seq
  Kcrypt = HMAC(Kcrypt, (int32)seq);

It should say:

// new encryption key salted with seq
  Kcrypt = HMAC(Kcrypt, (int32)seq_num);

Notes:

misnamed "seq" argument in HMAC function .

RFC 4758, "Cryptographic Token Key Initialization Protocol (CT-KIP) Version 1.0 Revision 1", November 2006

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 714
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-01-01
Verifier Name: Magnus Nystrom
Date Verified: 2007-01-05

Section 3.8.2 says:

     </xs:sequence>
     <xs:attribute name="id" type="xs:ID"/>
   </xs:complexType>

It should say:

      </xs:sequence>
    </xs:complexType>

Notes:

from pending

Errata ID: 718
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-01-01
Verifier Name: Magnus Nystrom
Date Verified: 2007-01-05

Section 3.8.3 says:

      <xs:attribute name=3D"Version" type=3D"ct-kip:VersionType"/>
    </xs:complexType>

It should say:

      <xs:attribute name=3D"Version" type=3D"VersionType"/>
    </xs:complexType>

Notes:

from pending

Errata ID: 720
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-01-01
Verifier Name: Magnus Nystrom
Date Verified: 2007-01-05

Section 3.9.3 says:

    <xs:complexContent>
      <xs:extension base=3D"ExtensionType">
        <xs:sequence>

It should say:

    <xs:complexContent>
      <xs:extension base=3D"AbstractExtensionType">
         <xs:sequence>

Notes:

from pending

Errata ID: 722
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-01-01
Verifier Name: Magnus Nystrom
Date Verified: 2007-01-05

Appendix A says:

    <xs:complexType name=3D"PayloadType">
      <xs:annotation>
        <xs:documentation xml:lang=3D"en">
        </xs:documentation>
      </xs:annotation>

It should say:

    <xs:complexType name=3D"PayloadType">
      <xs:annotation>
        <xs:documentation xml:lang=3D"en">
         Currently, only the nonce is defined.  In future versions,
         other payloads may be defined, e.g., for one-roundtrip
         initialization protocols.
      </xs:documentation>
    </xs:annotation>

Notes:

documentation was missing

from pending

Errata ID: 723
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-01-01
Verifier Name: Magnus Nystrom
Date Verified: 2007-01-05

Appendix B.2 says:

    <CT-KIPTrigger
      xmlns=3D [...]

It should say:

    <?xml version=3D"1.0" encoding=3D"UTF-8"?>
    <CT-KIPTrigger
      xmlns=3D [...]

Notes:

from pending

Errata ID: 724
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-01-01
Verifier Name: Magnus Nystrom
Date Verified: 2007-01-05

Appendix B.4 says:

    <ServerHello
      xmlns=3D
      "http://www.rsasecurity.com/rsalabs/otps/schemas/2005/12/ct-kip#"
      xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#"
      xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"
      Version=3D"1.0" SessionID=3D"4114" Status=3D"Success">

It should say:

    <ServerHello
      xmlns=3D
      "http://www.rsasecurity.com/rsalabs/otps/schemas/2005/12/ct-kip#"
      xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#"
      xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"
      Version=3D"1.0" SessionID=3D"4114" Status=3D"Continue">

Notes:

from pending

Errata ID: 725
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-01-01
Verifier Name: Magnus Nystrom
Date Verified: 2007-01-05

Appendix D says:

n = ROUND( dsLen / bLen )

It should say:

n = CEILING( dsLen / bLen )

Notes:

Appendix D repeatedly uses the "ROUND" function where in fact it
should use the "CEILING function (3 instances: on pp. 49, 51, and 52).

from pending

Errata ID: 713
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-01-01
Verifier Name: Magnus Nystrom
Date Verified: 2007-01-05

Section 3.7.1 says:

   The XML format for CT-KIP messages have been designed to be
   extensible.  [...]  

It should say:

   The XML format for CT-KIP messages has been designed to be
   extensible.  [...]

Notes:

from pending

RFC 4760, "Multiprotocol Extensions for BGP-4", January 2007

Note: This RFC has been updated by RFC 7606

Source of RFC: idr (rtg)

Errata ID: 1573
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: yakov rekhter
Date Reported: 2008-10-13
Verifier Name: Stewart Bryant
Date Verified: 2012-02-20

Section 4 says:

      Address Family Identifier (AFI):

         This field in combination with the Subsequent Address Family
         Identifier field identifies the set of Network Layer protocols
         to which the address carried in the Next Hop field must belong,
         the way in which the address of the next hop is encoded, and
         the semantics of the Network Layer Reachability Information
         that follows.  If the Next Hop is allowed to be from more than
         one Network Layer protocol, the encoding of the Next Hop MUST
         provide a way to determine its Network Layer protocol.

         Presently defined values for the Address Family Identifier
         field are specified in the IANA's Address Family Numbers
         registry [IANA-AF].

      Subsequent Address Family Identifier (SAFI):

         This field in combination with the Address Family Identifier
         field identifies the set of Network Layer protocols to which
         the address carried in the Next Hop must belong, the way in
         which the address of the next hop is encoded, and the semantics
         of the Network Layer Reachability Information that follows.  If
         the Next Hop is allowed to be from more than one Network Layer
         protocol, the encoding of the Next Hop MUST provide a way to
         determine its Network Layer protocol.

It should say:

      Address Family Identifier (AFI):
 
         This field in combination with the Subsequent Address Family
         Identifier field identifies the semantics of Withdrawn Routes 
         Network Layer Reachability Information carried in the attribute.
 
         Presently defined values for the Address Family Identifier
         field are specified in the IANA's Address Family Numbers
         registry [IANA-AF].

      Subsequent Address Family Identifier (SAFI):

         This field in combination with the Address Family Identifier
         field identifies the semantics of Withdrawn Routes Network
         Layer Reachability Information carried in the attribute.

Notes:

This original text refers to the field (Next Hop) that is not present in
the attribute MP_UNREACH_NLRI. Therefore the original text is not applicable.

RFC 4762, "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", January 2007

Source of RFC: l2vpn (int)

Errata ID: 4144
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alexander ("Sasha") Vainshtein
Date Reported: 2014-10-23
Verifier Name: Adrian Farrel
Date Verified: 2014-11-20

Section Appendix A says:

   In a VPLS, we use a VCID (which, when using the PWid FEC, has been
   substituted with a more general identifier (AGI), to address
   extending the scope of a VPLS) to identify an emulated LAN segment.
   Note that the VCID as specified in [RFC4447] is a service identifier,
   identifying a service emulating a point-to-point virtual circuit.  In
   a VPLS, the VCID is a single service identifier, so it has global
   significance across all PEs involved in the VPLS instance.

It should say:

   In a VPLS, we use a PWID (which, when using the Generalized PW ID 
   FEC, has been substituted with a more general identifier (AGI), 
   to address
   extending the scope of a VPLS) to identify an emulated LAN segment.
   Note that the PWID as specified in [RFC4447] is a service identifier,
   identifying a service emulating a point-to-point virtual circuit.  In
   a VPLS, the PWID is a single service identifier, so it has global
   significance across all PEs involved in the VPLS instance.

Notes:

1. The problematic text follows a diagram depicting the PWID FEC (a.k.a. FEC-128) as it appears in RFC 4447. This diagram includes a 32-bit PWID field, but there is no VCID field. Nor is VCID mentioned anywhere in RFC 4447 - it has been used in the original Martini drafts but has then been replaced by PWID.

2. According to RFC 4447, AGI is used only in the Generalized PW ID FEC (a.k.a. FEC-129) but not in the PWID FEC (a.k.a. FEC-128).

RFC 4763, "Extensible Authentication Protocol Method for Shared-secret Authentication and Key Establishment (EAP-SAKE)", November 2006

Source of RFC: INDEPENDENT

Errata ID: 1413
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-02-12
Verifier Name: Bob Braden
Date Verified: 2008-04-23

Section 3.2.6.1 says:

   The KDF is a keyed hash function with key "Key" and operating on
   input "Label | Msg".  The convention followed herein is that
   concatenation is denoted by |, FLOOR denotes the floor function, and
   [x...y] denotes bytes x through y.

It should say:

   The KDF is a keyed hash function with key "Key" and operating on
   input "Label | Msg".  The convention followed herein is that
   concatenation is denoted by |, CEIL denotes the ceiling function,
   and [x...y] denotes bytes x through y.

Notes:

The 'FLOOR' function is used where the 'CEILING' or 'CEIL' function is needed, to properly set the repetition count for partitioning a message into fixed-size blocks. The same error occurs in the code block at the end of Section 3.2.6.1.

Errata ID: 1414
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-02-12
Verifier Name: Nevil Brownlee
Date Verified: 2010-04-05

Section 3.3.1 says:

   Type

      To be assigned

  

It should say:

   Type

     EAP-SAKE (=48)

Notes:

8) The explanation,

AT_ENCR_DATA

This attribute is optional to use in this message. The encrypted
data, if present, may contain an attribute AT_NEXT_TMPID,
containing the NAI the Peer should use in the next EAP
authentication.

should say:

| AT_ENCR_DATA (=128)

| This attribute is optional to use in this message. The cleartext
| form of the encrypted data, if present, may contain an attribute
AT_NEXT_TMPID, containing the NAI the Peer should use in the next
EAP authentication.


(13) Section 4 -- lack of specification

The first paragraph of Section 4 (on page 37) says:

| IANA allocated a new EAP Type for EAP-SAKE.
^
It should say:

| IANA allocated a new EAP Type, 48, for EAP-SAKE.
^^^^^^


(15) Section 8.1 -- outdated Normative Reference

On page 45, the ref. [SHA1] should better point to the current
version, "FIPS 180-2 (with Change Notice)", February 2004.

Errata ID: 1416
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-02-12
Verifier Name: Nevil Brownlee
Date Verified: 2012-11-05

 

The items below are presented in RFC textual order.
I use change bars ('|' in column 1) and occasionally
up/down pointing marker lines ('^^^'/'vvv') to emphasize
the location of textual issues and/or proposed corrections.
Modified text has been re-adjusted to match RFC formatting
rules, where appropriate.


(1)  Section 3.1 -- word omission

The first bullet in Section 3.1, on mid-page 4, says:
                   v
|  o It is based on well-established Bellare-Rogaway mutual
     authentication protocol.

It should say:
                   vvvvv
|  o It is based on the well-established Bellare-Rogaway mutual
     authentication protocol.

BTW: Wouldn't that have deserved a proper reference ???


(2)  Section 3.2.6.1 -- URGENT algorithmic correction

Unfortunately, Section 3.2.6.1 contains a bad legacy mistake.
Like a couple of related documents, it does not properly set
the repetition count needed for the partitioning of a message
into fixed-size blocks, by substituting the 'FLOOR' function
where the 'CEILING' or 'CEIL' function would be needed.

To most easily see what's wrong, try substituting  Length := 16
(hence, a single 20-octet HMAC-SHA1 result is needed to cover
the requested size), and observe the controlling loop:

           for i := 0 to FLOOR(Length/20)-1 do
becomes:
           for i := 0 to FLOOR(16/20)-1 do
which is:
           for i := 0 to 0-1 do
or:
           for i := 0 to -1 do

and hence no H-SHA1 calls are ever performed.

The simple rule-of-thumb is:
  - you need FLOOR if you want to fit fixed-size pieces into a bag;
  - you need CEIL[ING] if you want to cover a bag with fixed-size pieces.

These are the changes to make the algorithm in Section 3.2.6.1 work
as intended:

In the first paragraph on page 16, where the RFC says:

   The KDF is a keyed hash function with key "Key" and operating on
   input "Label | Msg".  The convention followed herein is that
|  concatenation is denoted by |, FLOOR denotes the floor function, and
   [x...y] denotes bytes x through y.

it should say:

   The KDF is a keyed hash function with key "Key" and operating on
   input "Label | Msg".  The convention followed herein is that
|  concatenation is denoted by |, CEIL denotes the ceiling function,
   and [x...y] denotes bytes x through y.

The code block at the end of Section 3.2.6.1 :

   KDF(Key, Label, Msg, Length)
   R := []  ;; null string
|  for i := 0 to FLOOR(Length/20)-1 do
|  R := R | H-SHA1(Key, Label, Msg, i)
   return R[0...(Length-1)]

should properly state:

   KDF(Key, Label, Msg, Length)
   R := []  ;; null string
|  for i := 0 to CEIL(Length/20)-1 do
|    R := R | H-SHA1(Key, Label, Msg, i)
   return R[0...(Length-1)]

[ Note: I also have indented the statement making up the body
        of the loop to cleraly identify this property. ]


(3)  Section 3.2.8.2 -- clarification needed

Within Section 3.2.8.2, the second paragraph on page 20 says:

   The default encryption algorithm, as described in Section 3.2.8.3,
   requires the length of the plaintext to be a multiple of 16 bytes.
   The sender MAY need to include the AT_PADDING attribute as the last
|  attribute within the value field of the AT_ENCR_DATA attribute.  The
   length of the padding is chosen so that the length of the value field
   of the AT_ENCR_DATA attribute becomes a multiple of 16 bytes.  The
   AT_PADDING attribute SHOULD NOT be included if the total length of
   other attributes present within the AT_ENCR_DATA attribute is a
   multiple of 16 bytes.  The length of the AT_PADDING attribute
   includes the Attribute Type and Attribute Length fields.  The actual
   pad bytes in the value field are set to zero (0x00) on sending.  The
   recipient of the message MUST verify that the pad bytes are zero
   after decryption and MUST silently discard the message otherwise.

It should say:

   The default encryption algorithm, as described in Section 3.2.8.3,
   requires the length of the plaintext to be a multiple of 16 bytes.
   The sender MAY need to include the AT_PADDING attribute as the last
|  attribute within the plaintext of the value field of the AT_ENCR_DATA
   attribute.  The length of the padding is chosen so that the length of
   the value field of the AT_ENCR_DATA attribute becomes a multiple of
   16 bytes.  The AT_PADDING attribute SHOULD NOT be included if the
   total length of other attributes present within the AT_ENCR_DATA
   attribute is a multiple of 16 bytes.  The length of the AT_PADDING
   attribute includes the Attribute Type and Attribute Length fields.
   The actual pad bytes in the value field are set to zero (0x00) on
   sending.  The recipient of the message MUST verify that the pad bytes
   are zero after decryption and MUST silently discard the message
   otherwise.

Note:
The proper distinction between the plaintext and the ciphertext
version of fields that are encrypted in its on-the-wire form should be
heavily emphasized; neglecting this distinction can lead to significant
interoperability problems and catastrophic cryptographic failures!


(4)  Section 3.3.1 -- lack of specification, and a word omission

Unfortunately, the RFC has not been cleaned up after IANA allocation
and remains unspecific und indeterminate on the protocol constant
(EAP method type)  EAP-SAKE (=48).

In Section 3.3.1, the explanation:

   Type

      To be assigned.

should say:

   Type

|     EAP-SAKE (=48)


At the end of Section 3.3.1, the explanation:

   Subtype

      EAP-SAKE subtype: SAKE/Challenge, SAKE/Confirm, SAKE/Auth-Reject,
      and SAKE/Identity.  All messages of type "EAP-SAKE" that are not
|     of these subtypes MUST silently discarded.
      [...]                          ^

should say:

   Subtype

      EAP-SAKE subtype: SAKE/Challenge, SAKE/Confirm, SAKE/Auth-Reject,
      and SAKE/Identity.  All messages of type "EAP-SAKE" that are not
|     of these subtypes MUST silently be discarded.
      [...]                          ^^^^


(5)  Section 3.3.2 -- format, and incomplete specification

The inadvertent blank line near the end of the table on page 24
has no functional meaning and hence should be deleted.

At the end of the section, below the table, add the sentence:

   The attribute type values assigned by this specification (and
   registered by the IANA) are listed in section 4.

Note:
  Below, I have chosen to supply the missing values explicitely,
  rather than proposinf to repeatedly add similar pointers to Sct. 4.
  This seems to better serve the needs of the reader and hopefully
  will aid the implementer as well.


(6)  Section 3.3.3 -- lack of specification, and artwork improvement

For uniformity, *all* constant values should be made visible in
the message format diagrams.
The rationale of item (4) above applies as well.

The figure in Section 3.3.4, on page 26, contains the initial part:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |Type=EAP-SAKE  |    Version=2  | Session ID    |   Subtype=1   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |   AT_RAND_S    | Length = 18  |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   |    ...

It should say:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |    Code=1     |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  | Type=EAP-SAKE |   Version=2   |  Session ID   |   Subtype=1   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |   AT_RAND_S   |   Length=18   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   |    ...

The explanation:

   Type

|     EAP-SAKE

should say:

   Type

|     EAP-SAKE (=48)

At the end of the section, on page 27, the explanations:

|  AT_RAND_S

      The value field of this attribute contains the Server nonce RAND_S
      parameter.  The RAND_S attribute MUST be present in
      EAP.Request/SAKE/Challenge.

|  AT_SERVERID

      The value field of this attribute contains the Server identifier
      (e.g., a non-null terminated string).  The AT_SERVERID attribute
      SHOULD be present in EAP.Request/SAKE Challenge.

should say:

|  AT_RAND_S (=1)

      The value field of this attribute contains the Server nonce RAND_S
      parameter.  The RAND_S attribute MUST be present in
      EAP.Request/SAKE/Challenge.

|  AT_SERVERID (=5)

      The value field of this attribute contains the Server identifier
      (e.g., a non-null terminated string).  The AT_SERVERID attribute
      SHOULD be present in EAP.Request/SAKE Challenge.


(7)  Section 3.3.5 -- lack of specification, and artwork improvement

As above ...

The figure in Section 3.3.5, on page 28, contains the initial part:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Type=EAP-SAKE  |    Version=2  | Session ID    |   Subtype=1   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   AT_RAND_P    | Length = 18  |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   |  ...

It should say:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Code=2     |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type=EAP-SAKE |   Version=2   |  Session ID   |   Subtype=1   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   AT_RAND_P   |   Length=18   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   |  ...

On page 29, the explanation:

   Type

|     EAP-SAKE

should say:

   Type

|     EAP-SAKE=48

And the subsequent explanation headlines:

|  AT_RAND_P

|  AT_PEERID

|  AT_SPI_P

|  AT_MIC_P

should be amended to say, respectively:

|  AT_RAND_P (=2)

|  AT_PEERID (=6)

|  AT_SPI_P (=8)

|  AT_MIC_P (=4)


(8)  Section 3.3.6 -- lack of specification, and artwork improvement

As above ...
Also, a spurious separator line in the diagram should be deleted.

The figure in Section 3.3.6, on page 30, contains the initial part:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |Type=EAP-SAKE  |    Version=2  | Session ID    |   Subtype=2   |
|  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   AT_SPI_S    | Length        |        SPI_S                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   AT_IV       | Length        |   Initialization Vector ...   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               :
   |   ...

It should say:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |    Code=1     |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  | Type=EAP-SAKE |   Version=2   |  Session ID   |   Subtype=2   |
|  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   AT_SPI_S    | Length        |        SPI_S                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   AT_IV       | Length        |   Initialization Vector ...   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               :
   |   ...

On page 31, the explanation:

   Type

|     EAP-SAKE

should say:

   Type

|     EAP-SAKE=48

The subsequent explanation headlines:

|  AT_SPI_S

|  AT_IV

|  AT_MSK_LIFE

|  AT_MIC_S

should be amended to say, respectively:

|  AT_SPI_S (=7)

|  AT_IV (=129)

|  AT_MSK_LIFE (=132)

|  AT_MIC_S (=3)

Finally, the explanation,

   AT_ENCR_DATA

      This attribute is optional to use in this message.  The encrypted
      data, if present, may contain an attribute AT_NEXT_TMPID,
      containing the NAI the Peer should use in the next EAP
      authentication.

should say:

|  AT_ENCR_DATA (=128)

|     This attribute is optional to use in this message.  The cleartext
|     form of the encrypted data, if present, may contain an attribute
      AT_NEXT_TMPID, containing the NAI the Peer should use in the next
      EAP authentication.


(9)  Section 3.3.7 -- lack of specification, and artwork improvement

As above ...

The figure in Section 3.3.7, on page 32, contains the initial part:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |Type=EAP-SAKE  |    Version=2  | Session ID    |   Subtype=2   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |   AT_MIC_P     | Length = 18  |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                       MIC_P                                   |
   |  ...

It should say:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |    Code=2     |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  | Type=EAP-SAKE |   Version=2   |  Session ID   |   Subtype=2   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |   AT_MIC_P    |   Length=18   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                       MIC_P                                   |
   |  ...

The explanation:

   Type

|     EAP-SAKE

should say:

   Type

|     EAP-SAKE (=48)

And on page 33, the explanation headlines:

|  AT_MIC_P

|  AT_PADDING

should be amended to say, respectively:

|  AT_MIC_P (=4)

|  AT_PADDING (=130)


(10)  Section 3.3.8 -- lack of specification, and artwork improvement

As above ...

The figure in Section 3.3.8, on page 33, says:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |Type=EAP-SAKE  |    Version=2  | Session ID    |   Subtype=3   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |    Code=2     |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  | Type=EAP-SAKE |   Version=2   |  Session ID   |   Subtype=3   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The explanation:

   Type

|     EAP-SAKE

should say:

   Type

|     EAP-SAKE (=48)


(11)  Section 3.3.9 -- lack of specification, and artwork improvement

As above ...

The figure in Section 3.3.9, on page 34, contains the initial part:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |Type=EAP-SAKE  |    Version=2  | Session ID    |   Subtype=4   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |    Code=1     |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  | Type=EAP-SAKE |   Version=2   |  Session ID   |   Subtype=4   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

On page 35, the explanation:

   Type

|     EAP-SAKE

should say:

   Type

|     EAP-SAKE=48

The subsequent explanation headlines:

|  AT_PERM_ID_REQ

|  AT_ANY_ID_REQ

|  AT_SERVERID

should be amended to say, respectively:

|  AT_PERM_ID_REQ (=10)

|  AT_ANY_ID_REQ (=9)

|  AT_SERVERID (=5)


(12)  Section 3.3.10 -- lack of specification, and artwork improvement

As above ...

The figure in Section 3.3.10, on page 36, contains the initial part:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |Type=EAP-SAKE  |    Version=2  | Session ID    |   Subtype=4   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |    Code=2     |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  | Type=EAP-SAKE |   Version=2   |  Session ID   |   Subtype=4   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The explanation:

   Type

|     EAP-SAKE

should say:

   Type

|     EAP-SAKE (=48)

And on page 37, the explanation headline:

   AT_PEERID

should be amended to say:

   AT_PEERID (=6)


(13)  Section 4 -- lack of specification

The first paragraph of Section 4 (on page 37) says:

|  IANA allocated a new EAP Type for EAP-SAKE.
                                ^
It should say:

|  IANA allocated a new EAP Type, 48, for EAP-SAKE.
                                ^^^^^^

(14)  Section 5.5 -- spelling and terminology

'Server' and 'Peer' are distinguished roles of EAP entities.
Therefore, when talking about both participants in an EAP session,
the term 'Peer' (in headline case) should not be used to avoid
confusion.

Therefore, the last paragraph of Section 5.5, on page 40,
that says,

     [...]  Thus, the recipient of an EAP message can be assured that
|  the message it just received is the one just sent by the other Peer
   and not a replay, since it contains a valid MIC of the recipient's
|  nonce and the other Peer nonce.  As before, the extent of replay
   protection is commensurate with the security of the KDF used to
   derive the MIC, the length and entropy of the shared secret used by
   the KDF, and the length of the MIC.

should better say:

     [...]  Thus, the recipient of an EAP message can be assured that
|  the message it just received is the one just sent by the other party
   and not a replay, since it contains a valid MIC of the recipient's
|  nonce and the other party's nonce.  As before, the extent of replay
   protection is commensurate with the security of the KDF used to
   derive the MIC, the length and entropy of the shared secret used by
   the KDF, and the length of the MIC.


(15)  Section 8.1 -- outdated Normative Reference

On page 45, the ref. [SHA1] should better point to the current
version, "FIPS 180-2 (with Change Notice)", February 2004.

It should say:

[not submitted]

Notes:

from pending

Errata ID: 845
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-02-12
Verifier Name: Bob Braden
Date Verified: 2008-04-23

Section 3.1 says:

   o It is based on well-established Bellare-Rogaway mutual
     authentication protocol.

It should say:

   o It is based on the well-established Bellare-Rogaway mutual
     authentication protocol.

RFC 4771, "Integrity Transform Carrying Roll-Over Counter for the Secure Real-time Transport Protocol (SRTP)", January 2007

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 3233
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mats Näslund
Date Reported: 2012-05-28
Verifier Name: Robert Sparks
Date Verified: 2012-06-07

Section 2 says:

When the receiver receives an SRTP packet, it processes the packet
according to RFC 3711 except that during authentication processing
ROC_local is replaced by ROC_sender (retrieved from the packet).

It should say:

When the receiver receives an SRTP packet, it processes the packet
according to RFC 3711 except that during replay check and authentication processing
ROC_local is replaced by ROC_sender (retrieved from the packet).

Notes:

While this is typo, it has the unfortunate side effect of creating a possibility for a replay attack where the attacker injects a previous message, possibly causing the receiver to loose synch on the ROC value. This is prevented if the receiver uses ROC_sender in place of ROC_local during both authentication _and_ replay check.

We thank David McGrew for spotting this error.

RFC 4778, "Operational Security Current Practices in Internet Service Provider Environments", January 2007

Source of RFC: opsec (ops)

Errata ID: 835
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-02-15
Verifier Name: Merike Kaeo
Date Verified: 2007-02-18

Section 2.2.3 says:

   SSH may not be supported on legacy equipment.  In some cases,
   changing the host name of a device requires an SSH rekey event since
   the key is based on some combination of host name, Message
   Authentication Code (MAC) address, and time.

It should say:

   SSH may not be supported on legacy equipment.  In some cases,
   changing the host name of a device requires an SSH rekey event since
   the key is based on some combination of host name, Media Access
   Control (MAC) address, and time.

(Or perhaps simply, and more generally, use "link layer address"
 in place of "Media Access Control (MAC) address".)

Notes:

wrong acronym expansion

RFC 4779, "ISP IPv6 Deployment Scenarios in Broadband Access Networks", January 2007

Source of RFC: v6ops (ops)

Errata ID: 958
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-14

 

(1)  Section 5.2 -- bad acronym expansion

Within Section 5.2, bullet B. on page 11 says:

   B.  Problems with IPv6 Neighbor Discovery (ND) on CM and CMTS.  In
|      IPv4, these devices rely on Internet Group Multicast Protocol
       (IGMP) join messages to track membership of hosts that are part
       of a particular IP multicast group.  [...]

It should say:

   B.  Problems with IPv6 Neighbor Discovery (ND) on CM and CMTS.  In
|      IPv4, these devices rely on Internet Group Management Protocol
       (IGMP) join messages to track membership of hosts that are part
       of a particular IP multicast group.  [...]


(2)  Section 5.2.1.3 -- typo / missing article

The first paragraph of Section 5.2.1.3, on top of page 14 says:

                                                 [...].  In order to do
   that, the CM and CMTS must forward Neighbor Discovery (ND) packets
|  between ER and the hosts attached to the CM.
          ^
It should say:

                                                 [...].  In order to do
   that, the CM and CMTS must forward Neighbor Discovery (ND) packets
|  between the ER and the hosts attached to the CM.
          ^^^^^


(3)  Section 5.2.1.4 -- typo / missing article

The first paragraph of Section 5.2.1.4, on mid-page 14 says:

                    [...].  If there is a GWR present, it will also use
|  static default route to the ER.

It should say:

                    [...].  If there is a GWR present, it will also use
|  a static default route to the ER.
   ^^


(4)  Section 5.2.2 -- typo / missing article

On page 15, the text for scenario #2 says:

   [...]
   This scenario is also easy to deploy since the cable operator just
|  needs to add GWR at the customer site.
               ^
It should say:

   [...]
   This scenario is also easy to deploy since the cable operator just
|  needs to add a GWR at the customer site.
               ^^^


(5)  Section 5.2.2.2.3 -- wrong article

On page 18, the second paragraph of Section 5.2.2.2.3 says:

   The GWR will use its IPv4 address to source the tunnel to the ER.
|  The tunnel endpoint will be the IPv4 address of the ER.  [...]
                               ^^^
It should say:

   The GWR will use its IPv4 address to source the tunnel to the ER.
|  The tunnel endpoint will be an IPv4 address of the ER.  [...]
                               ^^

Rationale:
  Since IP addresses usually identify *interfaces* and routers
  presumably have more than one IP interface, it is improper
  to talk about *the* IP address of a router.


(6)  Section 5.2.2.3 -- improper text in figure ?

On page 19, Figure 5.2.2.3 is:

                           +-----------+   +-------------+
     +-----+  +-------+    |   Cable   |   | CMTS / Edge |
     |Host |--|  CM   |----|  (HFC)    |---|             |=>ISP
     +-----+  +-------+    |  Network  |   |   Router    | Network
                           +-----------+   +-------------+

|    |-------||---------------------------||---------------|
|     IPv4/v6              IPv4/v6              IPv4/v6

Because all parts of the network shown are dual-stack, it makes
no sense to show two boundaries between similar regions.
Hence, the figure should better be:

                           +-----------+   +-------------+
     +-----+  +-------+    |   Cable   |   | CMTS / Edge |
     |Host |--|  CM   |----|  (HFC)    |---|             |=>ISP
     +-----+  +-------+    |  Network  |   |   Router    | Network
                           +-----------+   +-------------+

|    |-----------------------------------------------------|
|                          IPv4/v6


(7)  Section 5.2.2.5.2

The first paragraph of Section 5.2.2.5.2, at the bottom of page 22,
says:

   Since the CM/GWR is dual stack, it can receive an IPv4 or IPv6
   address using DHCP for management purposes.  As the GWR functionality
|  is embedded in the CM, it will need an IPv6 address for forwarding
   data traffic.  IPv6 address assignment for the CM/GWR and host can be
   done via DHCPv6 or DHCP-PD.

Apparently, to be able to *forward* IPv6 traffic, the GWR needs at least
two IPv6 addresses.  Therefore, the RFC should perhaps better say:

   Since the CM/GWR is dual stack, it can receive an IPv4 or IPv6
   address using DHCP for management purposes.  As the GWR functionality
|  is embedded in the CM, it will need IPv6 addresses for forwarding
   data traffic.  IPv6 address assignment for the CM/GWR and host can be
   done via DHCPv6 or DHCP-PD.


(8)  Section 5.2.3 -- missing articles

The first paragraph of Section 5.2.3 says, at the top of page 24:

                          [...].  MLDv2 is almost identical to IGMPv3
|  and also supports ASM (Any-Source Multicast) and SSM (Source-Specific
   Multicast) service models.

It should say:

                          [...].  MLDv2 is almost identical to IGMPv3
|  and also supports the ASM (Any-Source Multicast) and the SSM (Source-
   Specific Multicast) service models.


(9)  Section 6.2.1.2 -- typo

On page 30, the bullet B. within Section 6.2.1.2 says:

             v
       The later option allows it to contact a remote DHCPv6 server, if
       needed.  [...]

It should say:
             vv
|      The latter option allows it to contact a remote DHCPv6 server, if
       needed.  [...]


(10)  Section 6.2.2 -- typo

In the last paragraph on page 31, Section 6.2.2 says:

                                 v
|  This solution scales better then the Point-to-Point, but since there
   is only one PPP session per ATM PVC, the subscriber can choose a
   single ISP service at a time.

It should say:
                                 v
|  This solution scales better than the Point-to-Point, but since there
   is only one PPP session per ATM PVC, the subscriber can choose a
   single ISP service at a time.


(11)  Section 6.3 -- clarity

The last paragraph of Section 6.3 (second paragraph on page 39) says:

   This facilitates the deployment of multicast services.  The
   discussion of this section applies to all the multicast sections in
|  the document.
     ^
It should say:

   This facilitates the deployment of multicast services.  The
   discussion of this section applies to all the multicast sections in
|  this document.
     ^^

(12)  Section 6.3.1 -- grammar / typos

The first paragraph of Section 6.3.1, on page 39, says:
      v
|  Any Source Multicast (ASM) is useful for Service Providers that
   intend to support the forwarding of multicast traffic of their
   customers.  It is based on the Protocol Independent Multicast -
   Sparse Mode (PIM-SM) protocol and it is more complex to manage
   because of the use of Rendezvous Points (RPs).  With IPv6, static RP
|  and Bootstrap Router [BSR] can be used for RP-to-group mapping
   similar to IPv4.  [...]

It should say:
      v
|  Any-Source Multicast (ASM) is useful for Service Providers that
   intend to support the forwarding of multicast traffic of their
   customers.  It is based on the Protocol Independent Multicast -
   Sparse Mode (PIM-SM) protocol and it is more complex to manage
   because of the use of Rendezvous Points (RPs).  With IPv6, static RP
|  and Bootstrap Routers [BSR] can be used for RP-to-group mapping
   similar to IPv4.  [...]

Alternatively, the last sentence above could be reworded to say:

   because of the use of Rendezvous Points (RPs).  With IPv6, static RP
|  and the Bootstrap Router protocol [BSR] can be used for RP-to-group
   mapping similar to IPv4.  [...]


(13)  Section 8.1 -- multiple flaws

Near the end of the first paragraph on page 56, Section 8.1 says:

              [...].  The AP forwards all the packets coming to/from
|  host to the Edge Router.  The underlying connection between the AP
|  and Edge Router could be based on any access layer technology such as
   HFC/Cable, FTTH, xDSL, etc.

It should say:

              [...].  The AP forwards all the packets coming to/from
|  hosts to the Edge Router.  The underlying connection between the AP
|  and the Edge Router could be based on any access layer technology
   such as HFC/Cable, FTTH, xDSL, etc.

In the second paragraph on page 56, Section 8.1 says:

|                [...].  In most of the cases, SP assigns a limited
   number of public IP addresses to its customers.  [...]

It should say:
                                               vvvv
|                [...].  In most of the cases, the SP assigns a limited
   number of public IP addresses to its customers.  [...]

At the end of the section (near the bottom of page 56), the RFC says:

|  A. Layer 2 NAP with Layer 3 termination at NSP Edge Router

|  B. Layer 3 aware NAP with Layer 3 termination at Access Router

It should say either:

|  A. Layer 2 NAP with Layer 3 termination at an NSP Edge Router

|  B. Layer 3 aware NAP with Layer 3 termination at an Access Router

or:

|  A. Layer 2 NAP with Layer 3 termination at NSP Edge Routers

|  B. Layer 3 aware NAP with Layer 3 termination at Access Routers


(14)  Section 8.1.1 -- grammar

The first paragraph of Section 8.1.1, at the bottom of page 56, says:

   When a Layer 2 switch is present between AP and Edge Router, the AP
|  and Layer 2 switch continues to work as a bridge, forwarding IPv4 and
   IPv6 packets from WLAN Host/Router to Edge Router and vice versa.

It should say:

   When a Layer 2 switch is present between AP and Edge Router, the AP
|  and Layer 2 switch continue to work as a bridge, forwarding IPv4 and
   IPv6 packets from WLAN Host/Router to Edge Router and vice versa.


(15)  Section 8.1.2

On page 59, the second paragraph of Section 8.1.2 says:

   When the WLAN Host initiates the connection, the AAA authentication
|  and association process with WLAN AP will be similar, as explained in
   Section 8.1.1.
                               ^                       ^
It should say:

   When the WLAN Host initiates the connection, the AAA authentication
|  and association process with the WLAN AP will be similar as explained
   in Section 8.1.1.
                               ^^^^^                       ^

(16)  Section 8.1.2.2 -- clarification needed

On page 60, bullet C. of Section 8.1.2.2 says:

       vv                                                             vv
|  C.  It can use its link-local address to communicate with the ER.  It
       can also dynamically acquire through stateless auto-configuration
       the address for the link between itself and the ER.  [...]

The double "it" is unclear and inprecise.  (The immediately preceding
sentences refer to three different entities, the DHCP server, the
Access Router, and the Edge Router -- which one is "it" ?)

Presumably, it was intended to refer to the Access Router, and not to
the AAA Server, but -- according to Figure 8.1.2 -- only the latter
potentially has a common link with the ER and hence can use link-local
addresses, whereas the AR is connected to the ER via the Access
Provider Network that might comprise multiple IP hops on the route
from AR to ER.

It should say (text provided by Adeel):

The Access Router can dynamically acquire through stateless address auto-configuration the address for the link between itself and the ER. This step is followed by a request via DHCP-PD for a
+prefix shorter than /64 that in turn is divided in /64s and assigned to its interfaces connecting the hosts on the customer site.


(17)  Section 8.1.2.3 -- missing article

The last paragraph of Section 8.1.2.3, on mid-page 61, says:

   If the Access Router is owned by the SP, then the Access Router will
|  also run IPv6 IGP, and will be part of the SP IPv6 routing domain
   (OSPFv3 or IS-IS).  [...]

It should say:

   If the Access Router is owned by the SP, then the Access Router will
|  also run an IPv6 IGP, and will be part of the SP IPv6 routing domain
   (OSPFv3 or IS-IS).  [...]


(18)  Section 8.1.3 -- missing articles

Section 8.1.3, near the bottom of page 61, says:

   PPP Terminated Aggregation (PTA) and L2TPv2 Access Aggregation (LAA)
   models, as discussed in Sections 6.2.2 and 6.2.3, respectively, can
   also be deployed in IPv6 WLAN environment.

It should say:

|  The PPP Terminated Aggregation (PTA) and L2TPv2 Access Aggregation
   (LAA) models, as discussed in Sections 6.2.2 and 6.2.3, respectively,
|  can also be deployed in an IPv6 WLAN environment.


(19)  Section 8.1.3.1 -- missing articles

At the bottom of page 61, the first paragraph Section 8.1.3.1 says:
                                   v
|  While deploying the PTA model in IPv6 WLAN environment, the Access
   Router is Layer 3 aware and it has to be upgraded to support IPv6.

It should say:
                                   vvvv
|  While deploying the PTA model in an IPv6 WLAN environment, the Access
   Router is Layer 3 aware and it has to be upgraded to support IPv6.

The bottom line on page 61,
                                            v
|  Figure 8.1.3.1 describes the PTA Model in IPv6 WLAN environment.

should say:
                                            vvvv
|  Figure 8.1.3.1 describes the PTA Model in an IPv6 WLAN environment.

Alternatively, "the" could be inserted in place of "an", in both cases.


(20)  Section 8.1.3.2

On page 62, the literally same changes as presented in item (19)
should be applied as well.


(21)  Section 8.2 -- multiple grammar issues

The first paragraph on top of page 64 says:

                                  vvvvv
|  It is important to note that in the shared wireless environments,
   multicast can have a significant bandwidth impact.  [...]

It should say:
                                  v
|  It is important to note that in shared wireless environments,
   multicast can have a significant bandwidth impact.  [...]

The second paragraph on page 64 says:

                          vvvvvv
|  The IPv6 WLAN Hosts can also join desired multicast groups as long as
   they are enabled to support MLDv1 or MLDv2.  [...]

It should say:
                          v
|  The IPv6 WLAN Hosts can join desired multicast groups as long as they
   are enabled to support MLDv1 or MLDv2.  [...]

(Rationale:
 "also" lacks similar context in preceding that might be resumed here.)

The third paragraph on page 64 says:
                                        vvvvv
|                [...].  The Edge Router has also needs to be enabled
|  for PIM-SSM in order to receive joins from IPv6 WLAN Hosts or WLAN/
   Access Router (if present), and send joins towards the SP core.

It should say:
                                        v
|                [...].  The Edge Router also needs to be enabled for
|  PIM-SSM in order to receive joins from IPv6 WLAN Hosts or the WLAN/
   Access Router (if present), and send joins towards the SP core.

The sixth paragraph on page 64 says:
                                    vvvvv
|  This problem is inherited by WLAN that can impact both IPv4 and IPv6
   multicast packets; it is not specific to IPv6 multicast.

It should say:
                                    vvvvv
|  This problem is inherited by WLANs and can impact both IPv4 and IPv6
   multicast packets; it is not specific to IPv6 multicast.

Finally, the last paragraph on page 64 says:
                       v
|  While deploying WLAN (IPv4 or IPv6), one should adjust their
   broadcast/multicast settings if they are in danger of dropping
   application dependent frames.  [...]

It should say:
                       vv
|  While deploying WLANs (IPv4 or IPv6), one should adjust their
   broadcast/multicast settings if they are in danger of dropping
   application dependent frames.  [...]


(22)  Section 8.3 -- improper article

The third paragraph of Section 8.3, on mid-page 65 says:

        [...]  The same IPv4 QoS concepts and methodologies should be
|  applied for the IPv6 as well.
              ^^^^^
It should say:

        [...]  The same IPv4 QoS concepts and methodologies should be
|  applied for IPv6 as well.
              ^

(23)  Section 8.4 -- word twister

The first paragraph of Section 8.4, near the bottom of page 65, says:

                                                  vvvvvvvvvvvvvvvvv
|  There are limited changes that have to be done for WLAN the Host/
   Router in order to enhance security.  [...]

It should say:
                                                  vvvvvvvvvvvvvvvvv
|  There are limited changes that have to be done for the WLAN Host/
   Router in order to enhance security.  [...]


(24)  Section 10

The last sub-item of item (21) above recurs in Section 10.
At the end of bullet E. , near the bottom of page 72, the RFC says:

                        vvvvv
                                            [...].  This problem is
|      inherited by WLAN that can impact both IPv4 and IPv6 multicast
       packets; it is not specific to IPv6 multicast.

It should say:
                        vvvvv
                                            [...].  This problem is
|      inherited by WLANs and can impact both IPv4 and IPv6 multicast
       packets; it is not specific to IPv6 multicast.

It should say:

[see above]

Notes:

Authors verified changes. Did not split into multiple items.

from pending.

RFC 4782, "Quick-Start for TCP and IP", January 2007

Source of RFC: tsvwg (wit)

Errata ID: 8
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Scharf
Date Reported: 2007-04-10
Verifier Name: Sally Floyd
Date Verified: 2007-04-10

Section 4.3 says:

   The QS Nonce in the
   Response is set to the received value of the QS Nonce in the Quick-
   Start Option.

It should say:

   The QS Nonce in the
   Response is set to the received value of the QS Nonce in the Quick-
   Start Option.

   If the TCP host has sufficient receive buffer space, it could
   estimate the required buffer space as the product of the approved
   Quick-Start rate and the round-trip time, and advertise a receive
   window based on this required buffer space.  This receive window
   should allow the other TCP host to fully use the approved Quick-Start
   Request.

   If the TCP host doesn't know the round-trip time, the TCP host
   could use an estimate of the round-trip time in calculating the
   required buffer space.  Alternately, the TCP host could base the
   advertised receive window on the available buffer space, without
   calculating the buffer space required for the other TCP host to
   fully use the approved Quick-Start Request.

   If the Quick-Start Response is sent in a SYN/ACK packet, then
   window scaling of the receive window is not allowed [RFC1323];
   if necessary, the TCP host could send a scaled receive window
   in a separate ACK packet following the SYN/ACK packet.

Notes:

Clarification regarding the receive window.

from pending

Errata ID: 604
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Scharf
Date Reported: 2007-04-10
Verifier Name: Sally Floyd
Date Verified: 2007-04-10

Section 4.4 says:

The TCP host SHOULD set its congestion window cwnd to QS-cwnd only if
QS-cwnd is greater than cwnd; otherwise, QS-cwnd is ignored.

It should say:

The TCP host SHOULD set its congestion window cwnd to QS-cwnd
only if QS-cwnd is greater than cwnd; otherwise, QS-cwnd is
ignored. In either case, the sender can transmit up to the
minimum of the cwnd and the receiver's advertised window rwnd,
as specified in [RFC2581].

Notes:

Clarification regarding the receive window.

from pending

Errata ID: 2034
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Laurent Toutain
Date Reported: 2010-02-08
Verifier Name: Lars Eggert
Date Verified: 2011-02-03

Section 12.1 says:

   IPv6 Option Number [RFC2460]:

   HEX         act  chg  rest
   ---         ---  ---  -----
     6          00   1   00110     Quick-Start

It should say:

   IPv6 Option Number [RFC2460]:

   HEX         act  chg  rest
   ---         ---  ---  -----
    26          00   1   00110     Quick-Start

Notes:

In IANA web page http://www.iana.org/assignments/ipv6-parameters values are sorted following rest field, by HEX contains the complete value. The errors appears also in the IANA database.

RFC 4790, "Internet Application Protocol Collation Registry", March 2007

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 7
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Filip Navara
Date Reported: 2007-03-29

Section 3.1 says:

collation-id    = collation-prefix ";" collation-core-name

It should say:

collation-id    = collation-scope ";" collation-core-name

Notes:

Submitted to the RFC Editor by Chris Newman.
Also reported by Alfred Hoenes 2007-04-10.

Errata ID: 3510
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Klensin
Date Reported: 2013-03-08
Verifier Name: Barry Leiba
Date Verified: 2013-03-08

Section Global says:

US-ASCII (most places)

It should say:

ASCII (but see note)

Notes:

The terms "US-ASCII" and "ASCII" are used interchangeably in this document, sometimes in the same paragraph (see the first paragraph of 9.2.1). Neither is anchored in a reference to either X3.4-1986 (e.g., the "us-ascii charset") or to X3.4-1968 or RFC 20 (e.g., NVT ASCII). There is one explicit mention of the "US-ASCII charset" (Section 5) but all the rest, including the section titles that use "ASCII" already, appear to be talking about the ASCII repertoire with terms like "ASCII" (or "US-ASCII") letters. Except where the charset, or some very special property of X3.4-1986, is intended, I believe that all of these should be just "ASCII".

I don't think this is likely to cause any significant confusion among anyone who is likely to read this spec, much less confusion sufficient to cause interoperability problems (hence, it is not a technical error), but it is confusing and should be cleaned up --both to rationalize the terminology and to provide citations for the terminology that is used-- if the document is ever updated.

RFC 4791, "Calendaring Extensions to WebDAV (CalDAV)", March 2007

Note: This RFC has been updated by RFC 5689, RFC 6638, RFC 6764, RFC 7809, RFC 7953, RFC 8996

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 1002
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2007-07-14
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-11

Section 5.3.1 says:

      (DAV:needs-privilege): The DAV:bind privilege MUST be granted to
               ^          ^
      the current user on the parent collection of the Request-URI.

It should say:

      (DAV:need-privileges): The DAV:bind privilege MUST be granted to
               ^         ^
      the current user on the parent collection of the Request-URI.

Notes:

As per RFC 3744.

Errata ID: 1476
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Filip Navara
Date Reported: 2008-07-20
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-11

Section 7.8.10. says:

   <D:error>
     <C:supported-filter>
       <C:prop-filter name="X-ABC-GUID"/>
     </C:supported-filter>
   </D:error>

It should say:

   <D:error xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
     <C:supported-filter>
       <C:prop-filter name="X-ABC-GUID"/>
     </C:supported-filter>
   </D:error>

Notes:

Proper namespace declarations should be returned in the XML response.

Errata ID: 4161
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Hiroaki KAWAI
Date Reported: 2014-11-05
Verifier Name: Barry Leiba
Date Verified: 2015-02-06

Section 7.8.9 says:

           <D:getetag>"fffff-abcd5"</D:getetag>
           <C:calendar-data>BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Client//EN
   BEGIN:VTODO
   DTSTAMP:20060205T235300Z
   DUE;VALUE=DATE:20060106
   LAST-MODIFIED:20060205T235308Z
   SEQUENCE:1
   STATUS:NEEDS-ACTION
   SUMMARY:Task #2
   UID:E10BA47467C5C69BB74E8720@example.com
   BEGIN:VALARM
   ACTION:AUDIO
   TRIGGER;RELATED=START:-PT10M
   END:VALARM
   END:VTODO
   END:VCALENDAR
   </C:calendar-data>

It should say:

           <D:getetag>"fffff-abcd5"</D:getetag>
           <C:calendar-data>BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Client//EN
   BEGIN:VTIMEZONE
   LAST-MODIFIED:20040110T032845Z
   TZID:US/Eastern
   BEGIN:DAYLIGHT
   DTSTART:20000404T020000
   RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
   TZNAME:EDT
   TZOFFSETFROM:-0500
   TZOFFSETTO:-0400
   END:DAYLIGHT
   BEGIN:STANDARD
   DTSTART:20001026T020000
   RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
   TZNAME:EST
   TZOFFSETFROM:-0400
   TZOFFSETTO:-0500
   END:STANDARD
   END:VTIMEZONE
   BEGIN:VTODO
   DTSTAMP:20060205T235300Z
   DUE;TZID=US/Eastern:20060106T120000
   LAST-MODIFIED:20060205T235308Z
   SEQUENCE:1
   STATUS:NEEDS-ACTION
   SUMMARY:Task #2
   UID:E10BA47467C5C69BB74E8720@example.com
   BEGIN:VALARM
   ACTION:AUDIO
   TRIGGER;RELATED=END:-PT10M
   END:VALARM
   END:VTODO
   END:VCALENDAR
   </C:calendar-data>

Notes:

1. DUE VTODO component property in abcd5.ics is using TZID=US/Eastern and response needs VTIMEZONE component.

2. RELATED is not START but END, because VTODO has only DUE property.

Errata ID: 4153
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hiroaki KAWAI
Date Reported: 2014-11-05
Verifier Name: Barry Leiba
Date Verified: 2015-02-06

Section 7.8.1 says:

       <D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href>
       <D:propstat>
         <D:prop>
           <D:getetag>"fffff-abcd3"</D:getetag>
           <C:calendar-data>BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Client//EN
   BEGIN:VTIMEZONE
   LAST-MODIFIED:20040110T032845Z
   TZID:US/Eastern

It should say:

       <D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href>
       <D:propstat>
         <D:prop>
           <D:getetag>"fffff-abcd3"</D:getetag>
           <C:calendar-data>BEGIN:VCALENDAR
   VERSION:2.0
   BEGIN:VTIMEZONE
   LAST-MODIFIED:20040110T032845Z
   TZID:US/Eastern

Notes:

Remove the PRODID property in abcd3.ics, which was not selected by C:calendar-date/C:comp[@name="VCALENDAR"]/*

Errata ID: 4154
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hiroaki KAWAI
Date Reported: 2014-11-05
Verifier Name: Barry Leiba
Date Verified: 2015-02-06

Section 7.8.5 says:

   <D:multistatus xmlns:D="DAV:"
                  xmlns:C="urn:ietf:params:xml:ns:caldav">
     <D:response>
       <D:href>http://cal.example.com/bernard/work/abcd4.ics</D:href>
       <D:propstat>
         <D:prop>
           <D:getetag>"fffff-abcd5"</D:getetag>
           <C:calendar-data>BEGIN:VCALENDAR

It should say:

   <D:multistatus xmlns:D="DAV:"
                  xmlns:C="urn:ietf:params:xml:ns:caldav">
     <D:response>
       <D:href>http://cal.example.com/bernard/work/abcd5.ics</D:href>
       <D:propstat>
         <D:prop>
           <D:getetag>"fffff-abcd5"</D:getetag>
           <C:calendar-data>BEGIN:VCALENDAR

Notes:

Typo in D:href

Errata ID: 4155
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hiroaki KAWAI
Date Reported: 2014-11-05
Verifier Name: Barry Leiba
Date Verified: 2015-02-06

Section 7.8.3 says:

           <C:calendar-data>BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Client//EN
   BEGIN:VEVENT
   DTSTAMP:20060206T001121Z
   DTSTART:20060103T170000
   DURATION:PT1H
   RECURRENCE-ID:20060103T170000
   SUMMARY:Event #2
   UID:00959BC664CA650E933C892C@example.com
   END:VEVENT
   BEGIN:VEVENT
   DTSTAMP:20060206T001121Z
   DTSTART:20060104T190000
   DURATION:PT1H
   RECURRENCE-ID:20060104T170000
   SUMMARY:Event #2 bis
   UID:00959BC664CA650E933C892C@example.com
   END:VEVENT
   END:VCALENDAR
   </C:calendar-data>

It should say:

           <C:calendar-data>BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Client//EN
   BEGIN:VEVENT
   DTSTAMP:20060206T001121Z
   DTSTART:20060103T170000Z
   DURATION:PT1H
   RECURRENCE-ID:20060103T170000Z
   SUMMARY:Event #2
   UID:00959BC664CA650E933C892C@example.com
   END:VEVENT
   BEGIN:VEVENT
   DTSTAMP:20060206T001121Z
   DTSTART:20060104T190000Z
   DURATION:PT1H
   RECURRENCE-ID:20060104T170000Z
   SUMMARY:Event #2 bis
   UID:00959BC664CA650E933C892C@example.com
   END:VEVENT
   END:VCALENDAR
   </C:calendar-data>

Notes:

9.6.5 says:
Date and local
time with reference to time zone information MUST be converted
into date with UTC time.

Errata ID: 4156
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hiroaki KAWAI
Date Reported: 2014-11-05
Verifier Name: Barry Leiba
Date Verified: 2015-02-06

Section 7.8.3 says:

           <C:calendar-data>BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Client//EN
   BEGIN:VEVENT
   ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com
   ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com
   DTSTAMP:20060206T001220Z
   DTSTART:20060104T150000
   DURATION:PT1H
   LAST-MODIFIED:20060206T001330Z
   ORGANIZER:mailto:cyrus@example.com
   SEQUENCE:1
   STATUS:TENTATIVE
   SUMMARY:Event #3
   UID:DC6C50A017428C5216A2F1CD@example.com
   X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com
   END:VEVENT
   END:VCALENDAR
   </C:calendar-data>

It should say:

           <C:calendar-data>BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Client//EN
   BEGIN:VEVENT
   ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com
   ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com
   DTSTAMP:20060206T001220Z
   DTSTART:20060104T150000Z
   DURATION:PT1H
   LAST-MODIFIED:20060206T001330Z
   ORGANIZER:mailto:cyrus@example.com
   SEQUENCE:1
   STATUS:TENTATIVE
   SUMMARY:Event #3
   UID:DC6C50A017428C5216A2F1CD@example.com
   X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com
   END:VEVENT
   END:VCALENDAR
   </C:calendar-data>

Notes:

9.6.5 says:
Date and local
time with reference to time zone information MUST be converted
into date with UTC time.

Errata ID: 4157
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hiroaki KAWAI
Date Reported: 2014-11-05
Verifier Name: Barry Leiba
Date Verified: 2015-02-06

Section 7.8.4 says:

           <C:calendar-data>BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Client//EN
   BEGIN:VFREEBUSY
   ORGANIZER;CN="Bernard Desruisseaux":mailto:bernard@example.com
   UID:76ef34-54a3d2@example.com
   DTSTAMP:20050530T123421Z
   DTSTART:20060101T100000Z
   DTEND:20060108T100000Z
   FREEBUSY;FBTYPE=BUSY-TENTATIVE:20060102T100000Z/20060102T120000Z
   END:VFREEBUSY
   END:VCALENDAR
   </C:calendar-data>

It should say:

           <C:calendar-data>BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Client//EN
   BEGIN:VFREEBUSY
   ORGANIZER;CN="Bernard Desruisseaux":mailto:bernard@example.com
   UID:76ef34-54a3d2@example.com
   DTSTAMP:20050530T123421Z
   DTSTART:20060101T000000Z
   DTEND:20060108T000000Z
   FREEBUSY;FBTYPE=BUSY-TENTATIVE:20060102T100000Z/20060102T120000Z
   END:VFREEBUSY
   END:VCALENDAR
   </C:calendar-data>

Notes:

Typo in DTSTART, DTEND property.

Errata ID: 4158
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hiroaki KAWAI
Date Reported: 2014-11-05
Verifier Name: Barry Leiba
Date Verified: 2015-02-06

Section 7.8.5 says:

     <D:response>
       <D:href>http://cal.example.com/bernard/work/abcd4.ics</D:href>
       <D:propstat>
         <D:prop>
           <D:getetag>"fffff-abcd4"</D:getetag>
           <C:calendar-data>BEGIN:VCALENDAR

It should say:

     <D:response>
       <D:href>http://cal.example.com/bernard/work/abcd5.ics</D:href>
       <D:propstat>
         <D:prop>
           <D:getetag>"fffff-abcd5"</D:getetag>
           <C:calendar-data>BEGIN:VCALENDAR

Notes:

Typo in D:href and D:getetag. "Task #2" is abcd5.ics.

Errata ID: 4159
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hiroaki KAWAI
Date Reported: 2014-11-05
Verifier Name: Barry Leiba
Date Verified: 2015-02-06

Section 7.8.5 says:

   BEGIN:VTODO
   DTSTAMP:20060205T235300Z
   DUE;TZID=US/Eastern:20060106T120000
   LAST-MODIFIED:20060205T235308Z
   SEQUENCE:1
   STATUS:NEEDS-ACTION
   SUMMARY:Task #2
   UID:E10BA47467C5C69BB74E8720@example.com
   BEGIN:VALARM
   ACTION:AUDIO
   TRIGGER;RELATED=START:-PT10M
   END:VALARM
   END:VTODO

It should say:

   BEGIN:VTODO
   DTSTAMP:20060205T235300Z
   DUE;TZID=US/Eastern:20060106T120000
   LAST-MODIFIED:20060205T235308Z
   SEQUENCE:1
   STATUS:NEEDS-ACTION
   SUMMARY:Task #2
   UID:E10BA47467C5C69BB74E8720@example.com
   BEGIN:VALARM
   ACTION:AUDIO
   TRIGGER;RELATED=END:-PT10M
   END:VALARM
   END:VTODO

Notes:

RELATED is not START but END.

Both rfc2445 section4.8.6.3 and rfc5545 section3.8.6.3 says:

If the trigger is set relative to START, then the "DTSTART"
property MUST be present in the associated "VEVENT" or "VTODO"
calendar component. If an alarm is specified for an event with
the trigger set relative to the END, then the "DTEND" property or
the "DTSTART" and "DURATION " properties MUST be present in the
associated "VEVENT" calendar component. If the alarm is specified
for a to-do with a trigger set relative to the END, then either
the "DUE" property or the "DTSTART" and "DURATION " properties
MUST be present in the associated "VTODO" calendar component.

Errata ID: 4160
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hiroaki KAWAI
Date Reported: 2014-11-05
Verifier Name: Barry Leiba
Date Verified: 2015-02-06

Section 7.8.9 says:

           <C:calendar-data>BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Client//EN
   BEGIN:VTODO
   DTSTAMP:20060205T235335Z
   DUE;VALUE=DATE:20060104
   STATUS:NEEDS-ACTION
   SUMMARY:Task #1
   UID:DDDEEB7915FA61233B861457@example.com
   BEGIN:VALARM
   ACTION:AUDIO
   TRIGGER;RELATED=START:-PT10M
   END:VALARM
   END:VTODO
   END:VCALENDAR
   </C:calendar-data>

It should say:

           <C:calendar-data>BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Client//EN
   BEGIN:VTODO
   DTSTAMP:20060205T235335Z
   DUE;VALUE=DATE:20060104
   STATUS:NEEDS-ACTION
   SUMMARY:Task #1
   UID:DDDEEB7915FA61233B861457@example.com
   BEGIN:VALARM
   ACTION:AUDIO
   TRIGGER;RELATED=END:-PT10M
   END:VALARM
   END:VTODO
   END:VCALENDAR
   </C:calendar-data>

Notes:

RELATED is not START but END.

Both rfc2445 section4.8.6.3 and rfc5545 section3.8.6.3 says:

If the trigger is set relative to START, then the "DTSTART"
property MUST be present in the associated "VEVENT" or "VTODO"
calendar component. If an alarm is specified for an event with
the trigger set relative to the END, then the "DTEND" property or
the "DTSTART" and "DURATION " properties MUST be present in the
associated "VEVENT" calendar component. If the alarm is specified
for a to-do with a trigger set relative to the END, then either
the "DUE" property or the "DTSTART" and "DURATION " properties
MUST be present in the associated "VTODO" calendar component.

Errata ID: 4162
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hiroaki KAWAI
Date Reported: 2014-11-05
Verifier Name: Barry Leiba
Date Verified: 2015-02-06

Section 7.10.1 says:

   <?xml version="1.0" encoding="utf-8" ?>
   <C:free-busy-query xmlns:C="urn:ietf:params:xml:ns:caldav">
     <C:time-range start="20060104T140000Z"
                     end="20060105T220000Z"/>
   </C:free-busy-query>

It should say:

   <?xml version="1.0" encoding="utf-8" ?>
   <C:free-busy-query xmlns:C="urn:ietf:params:xml:ns:caldav">
     <C:time-range start="20060104T140000Z"
                     end="20060104T220000Z"/>
   </C:free-busy-query>

Notes:

Typo in C:time-range/@end

Errata ID: 4163
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hiroaki KAWAI
Date Reported: 2014-11-05
Verifier Name: Barry Leiba
Date Verified: 2015-02-06

Section 7.10.1 says:

   BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Server//EN
   BEGIN:VFREEBUSY
   DTSTAMP:20050125T090000Z
   DTSTART:20060104T140000Z
   DTEND:20060105T220000Z
   FREEBUSY;FBTYPE=BUSY-TENTATIVE:20060104T150000Z/PT1H
   FREEBUSY:20060104T190000Z/PT1H
   END:VFREEBUSY
   END:VCALENDAR

It should say:

   BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Server//EN
   BEGIN:VFREEBUSY
   DTSTAMP:20050125T090000Z
   DTSTART:20060104T140000Z
   DTEND:20060104T220000Z
   FREEBUSY;FBTYPE=BUSY-TENTATIVE:20060104T150000Z/PT1H
   FREEBUSY:20060104T190000Z/PT1H
   END:VFREEBUSY
   END:VCALENDAR

Notes:

Typo in DTEND.

Errata ID: 4164
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hiroaki KAWAI
Date Reported: 2014-11-05
Verifier Name: Barry Leiba
Date Verified: 2015-02-06

Section Appendix B says:

   BEGIN:VEVENT
   DTSTAMP:20060206T001121Z
   DTSTART;TZID=US/Eastern:20060104T140000
   DURATION:PT1H
   RECURRENCE-ID;TZID=US/Eastern:20060104T120000
   SUMMARY:Event #2 bis
   UID:00959BC664CA650E933C892C@example.com
   END:VEVENT
   END:VCALENDAR

It should say:

   BEGIN:VEVENT
   DTSTAMP:20060206T001121Z
   DTSTART;TZID=US/Eastern:20060104T140000
   DURATION:PT1H
   RECURRENCE-ID;TZID=US/Eastern:20060104T120000
   SUMMARY:Event #2 bis
   UID:00959BC664CA650E933C892C@example.com
   END:VEVENT
   BEGIN:VEVENT
   DTSTAMP:20060206T001121Z
   DTSTART;TZID=US/Eastern:20060106T140000
   DURATION:PT1H
   RECURRENCE-ID;TZID=US/Eastern:20060106T120000
   SUMMARY:Event #2 bis bis
   UID:00959BC664CA650E933C892C@example.com
   END:VEVENT
   END:VCALENDAR

Notes:

"Event #2 bis bis" seems to be required.

Errata ID: 4165
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hiroaki KAWAI
Date Reported: 2014-11-05
Verifier Name: Barry Leiba
Date Verified: 2015-02-06

Section Appendix B says:

   STATUS:TENTATIVE
   SUMMARY:Event #3
   UID:DC6C50A017428C5216A2F1CD@example.com
   END:VEVENT
   END:VCALENDAR

It should say:

   STATUS:TENTATIVE
   SUMMARY:Event #3
   UID:DC6C50A017428C5216A2F1CD@example.com
   X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com
   END:VEVENT
   END:VCALENDAR

Notes:

abcd3.ics seems to have X-ABC-GUID property.

Errata ID: 4166
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hiroaki KAWAI
Date Reported: 2014-11-05
Verifier Name: Barry Leiba
Date Verified: 2015-02-06

Section Appendix B says:

   TRIGGER;RELATED=START:-PT10M

It should say:

   TRIGGER;RELATED=END:-PT10M

Notes:

abcd4.ics RELATED parameter is not START but END, because TODO has only DUE property.

Errata ID: 4167
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hiroaki KAWAI
Date Reported: 2014-11-05
Verifier Name: Barry Leiba
Date Verified: 2015-02-06

Section Appendix B says:

           <D:getetag>"fffff-abcd5"</D:getetag>
           <C:calendar-data>BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Client//EN
   BEGIN:VTODO
   DTSTAMP:20060205T235300Z
   DUE;VALUE=DATE:20060106
   LAST-MODIFIED:20060205T235308Z
   SEQUENCE:1
   STATUS:NEEDS-ACTION
   SUMMARY:Task #2
   UID:E10BA47467C5C69BB74E8720@example.com
   BEGIN:VALARM
   ACTION:AUDIO
   TRIGGER;RELATED=START:-PT10M
   END:VALARM
   END:VTODO
   END:VCALENDAR
   </C:calendar-data>

It should say:

           <D:getetag>"fffff-abcd5"</D:getetag>
           <C:calendar-data>BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Client//EN
   BEGIN:VTIMEZONE
   LAST-MODIFIED:20040110T032845Z
   TZID:US/Eastern
   BEGIN:DAYLIGHT
   DTSTART:20000404T020000
   RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
   TZNAME:EDT
   TZOFFSETFROM:-0500
   TZOFFSETTO:-0400
   END:DAYLIGHT
   BEGIN:STANDARD
   DTSTART:20001026T020000
   RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
   TZNAME:EST
   TZOFFSETFROM:-0400
   TZOFFSETTO:-0500
   END:STANDARD
   END:VTIMEZONE
   BEGIN:VTODO
   DTSTAMP:20060205T235300Z
   DUE;TZID=US/Eastern:20060106T120000
   LAST-MODIFIED:20060205T235308Z
   SEQUENCE:1
   STATUS:NEEDS-ACTION
   SUMMARY:Task #2
   UID:E10BA47467C5C69BB74E8720@example.com
   BEGIN:VALARM
   ACTION:AUDIO
   TRIGGER;RELATED=END:-PT10M
   END:VALARM
   END:VTODO
   END:VCALENDAR
   </C:calendar-data>

Notes:

1. "Task #2" seems to be intended to show DUE with US/Eastern timezone, because "Task #1" is DATE.

2. RELATED would be not START, but END.

RFC 4795, "Link-local Multicast Name Resolution (LLMNR)", January 2007

Source of RFC: dnsext (int)

Errata ID: 846
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-02-13
Verifier Name: Bernard Aboba

Section 2.1.1 says:

as described in Section 4.2

It should say:

as described in Section 4.1


The description of the Tentative bit should read as follows:

   T       Tentative.  The 'T'entative bit is set in a response if the
           responder is authoritative for a UNIQUE name, but has not yet
           verified the uniqueness of the name, and it is cleared in all
           other cases.  A responder MUST ignore the 'T' bit in a query,
           if set.  A response with the 'T' bit set is silently
           discarded by the sender, except if it is received in reply to
           a uniqueness query issued according to the rules in Section
           4.1, in which case, a conflict has been detected and that
           conflict MUST be resolved as described in Section 4.1.

Notes:

from pending

Errata ID: 847
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-02-13
Verifier Name: Bernard Aboba

Section 2.3 says:

could be caused by coexistence

It should say:

could be caused by the coexistence

Notes:

from pending

Errata ID: 848
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-02-13
Verifier Name: Bernard Aboba

Section 2.5 says:

sent to an LLMNR multicast addresses defined in Section 2

It should say:

sent to one of the LLMNR multicast addresses defined in Section 2

Notes:

from pending

Errata ID: 849
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-02-13
Verifier Name: Bernard Aboba

Section 2.5 says:

TTL field in the IPV4 header MAY be set

It should say:

TTL in the IPv4 header MAY be set

Notes:

from pending

Errata ID: 850
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-02-13
Verifier Name: Bernard Aboba

Section 4.1 says:

The first paragraph should include an additional sentence:

"Responses for non-UNIQUE names are always sent with the 'T' bit clear."

It should say:

[see above]

Notes:

from pending

Errata ID: 851
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-02-13
Verifier Name: Bernard Aboba

Section 4.2 says:

   In order to enable ongoing detection of name conflicts, when an LLMNR
   sender receives multiple LLMNR responses to a query, it MUST check if
   the 'C' bit is clear in any of the responses.  If so, the sender

   SHOULD send another query for the same name, type, and class, this
   time with the 'C' bit set, with the potentially conflicting resource
   records included in the additional section.

It should say:

   In order to enable ongoing detection of name conflicts, when an LLMNR
   sender receives multiple LLMNR responses to a query, it MUST check if
   the 'C' bit is clear in any of the responses.  If so, the sender
   SHOULD send another query for the same name, type, and class, this
   time with the 'C' bit set, with the potentially conflicting resource
   records included in the additional section.

Notes:

The second paragraph has an interspersed blank line inserted.

from pending

RFC 4803, "Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base", February 2007

Source of RFC: ccamp (rtg)

Errata ID: 1841
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Girish Mahanta
Date Reported: 2009-08-27
Verifier Name: Adrian Farrel
Date Verified: 2010-01-02

Section Section 7 says:

gmplsOutSegmentTTLDecrement OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object indicates the amount by which to decrement the Time
to Live (TTL) of any payload packets forwarded on this segment if
per-hop decrementing is being done.
A value of zero indicates that no decrement should be made or
that per-hop decrementing is not in use.
See the gmplsTunnelTTLDecrement object in the gmplsTunnelTable
of GMPLS-TE-STD-MIB for a value by which to decrement the TTL
for the whole of a tunnel.
This object cannot be modified if mplsOutSegmentRowStatus for
the associated entry in the mplsOutSegmentTable is active(1)."
REFERENCE
"1. Time To Live (TTL) Processing in Multi-Protocol Label
Switching (MPLS) Networks, RFC 3443.
2. Generalized Multiprotocol Label Switching (GMPLS) Traffic
Engineering Management Information Base, RFC 4802."
DEFVAL { 0 }
::= { gmplsOutSegmentEntry 2 }

It should say:

gmplsOutSegmentTTLDecrement OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object indicates the amount by which to decrement the Time
to Live (TTL) of any payload packets forwarded on this segment if
per-hop decrementing is being done.
A value of zero indicates that no decrement should be made or
that per-hop decrementing is not in use.
This object cannot be modified if mplsOutSegmentRowStatus for
the associated entry in the mplsOutSegmentTable is active(1)."
REFERENCE
"1. Time To Live (TTL) Processing in Multi-Protocol Label
Switching (MPLS) Networks, RFC 3443."
DEFVAL { 0 }
::= { gmplsOutSegmentEntry 2 }

Notes:

In gmplsOutSegmentTable for the object gmplsOutSegmentTTLDecrement there is no gmplsTunnelTTLDecrement object in the gmplsTunnelTable of GMPLS-TE-STD-MIB which is referenced.

Errata ID: 3831
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Adrian Farrel
Date Reported: 2013-12-12
Verifier Name: Stewart Bryant
Date Verified: 2013-12-23

Section 6 says:

   In mplsXCTable:
   {
      mplsXCIndex                = 0x01,
      mplsXCInSegmentIndex       = 0x00000015,
      mplsXCOutSegmentIndex      = 0x00000012,
      mplsXCLspId                = 0x0102 -- unique ID
      mplsXCLabelStackIndex      = 0x00, -- only a single outgoing label
      mplsXCRowStatus            = createAndGo(4)
   }

   In mplsXCTable:
   {
      mplsXCIndex                = 0x02,
      mplsXCInSegmentIndex       = 0x00000016,
      mplsXCOutSegmentIndex      = 0x00000013,
      mplsXCLspId                = 0x0102 -- unique ID
      mplsXCLabelStackIndex      = 0x00, -- only a single outgoing label
      mplsXCRowStatus            = createAndGo(4)
   }

It should say:

   In mplsXCTable:
   {
      mplsXCIndex                = 0x01,
      mplsXCInSegmentIndex       = 0x00000015,
      mplsXCOutSegmentIndex      = 0x00000012,
      mplsXCLspId                = 0x0102 -- unique ID
      mplsXCLabelStackIndex      = 0x00, -- only a single outgoing label
      mplsXCRowStatus            = createAndGo(4)
   }

   In mplsXCTable:
   {
      mplsXCIndex                = 0x01,
      mplsXCInSegmentIndex       = 0x00000016,
      mplsXCOutSegmentIndex      = 0x00000013,
      mplsXCLspId                = 0x0102 -- unique ID
      mplsXCLabelStackIndex      = 0x00, -- only a single outgoing label
      mplsXCRowStatus            = createAndGo(4)
   }

Notes:

The entries in the mplsXCTable are indexed by {mplsXCIndex, mplsXCInSegmentIndex, mplsOutSegmentIndex}. All XC entries for the same LSP should share a common value of mplsXCIndex because mplsTunnelXCPointer can be set to point to the first entry and then all of the other entries can be found.

The error in the example in Section 6 is that it shows a different value of mplsXCIndex for the reverse direction cross-connects. It should be set to the same value as is used for the forward direction cross-connect.

RFC 4807, "IPsec Security Policy Database Configuration MIB", March 2007

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 3046
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Clark
Date Reported: 2011-12-08
Verifier Name: Sean Turner
Date Verified: 2012-08-15

Section 5 & 5.1.2 says:

s5:

The filter section of the MIB module is composed of the different
types of filters in the Policy Model.  It is made up of the
spdTrueFilter, spdCompoundFilterTable, spdSubfiltersTable,
spdIpHeaderFilterTable, spdIpOffsetFilterTable, spdTimeFilterTable,
spdIpsoHeaderFilterTable.

s5.1.2, paragraph 9:

SpdIpHeaderFilterEntry(spdIpHeadFiltName = "192.0.2.6")
     = (spdIpHeadFiltType            = 0x80,        -- sourceAddress
        spdIpHeadFiltIPVersion       = 1,           -- IPv4
        spdIpHeadFiltSrcAddressBegin = 0xC0000206,  -- 192.0.2.6
        spdIpHeadFiltSrcAddressEnd   = 0xC0000206,  -- 192.0.2.6
        spdIpHeadFiltRowStatus       = 4)           -- createAndGo

It should say:

s5:

The filter section of the MIB module is composed of the different
types of filters in the Policy Model.  It is made up of the
spdTrueFilter, spdCompoundFilterTable, spdSubfiltersTable,
spdIpOffsetFilterTable, spdTimeFilterTable, and spdIpsoHeaderFilterTable.

s5.1.2, paragraph 9:

SpdIpOffsetHeaderFilterEntry(ipspIpOffFiltName = "192.0.2.6")
     = (spdIpOffFiltOffset           = 0x0b         -- sourceAddress
        spdIpOffFiltType             = 1            -- valueMatch
        spdIpOffFiltValue            = 0xb0000206   -- 192.0.2.6
        spdIpOffFiltRowStatus        = 4)           -- createAndGo

Notes:

The text quoted includes spdIpHeaderFitlerTable, but it does not exist in the MIB definition in Section 6. In addition, spdIpHeaderFilterTable is referenced in the tutorial of Section 5.1.2. This oversight is either a large editorial oversight in Section 5 or a large technical oversight in Section 6.

After discussions with the authors, spdIpHeaderFitlerEntry needs to be removed from s5 and the spdIpHeaderFitlerTable example in s5.1.2 needs to be amended.

RFC 4812, "OSPF Restart Signaling", March 2007

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 6

Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Abhay Roy
Date Reported: 2007-03-29
Report Text:

The running page footer displays the wrong status of the document; 
the footer displays "Experimental".  However, RFC 4812 is an 
Informational document.  The status is displayed correctly in 
the document header and in the RFC index.

---

RFC 4823, "FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet", April 2007

Note: This RFC has been updated by RFC 8996

Source of RFC: ediint (app)

Errata ID: 2282
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-14
Verifier Name: Alexey Melnikov
Date Verified: 2010-11-12

Section 7.4.4 says:

Item 8 in Section 7.4.4, on page 27 says:

   8.  The "failed" disposition type MAY NOT be used for the situation
       in which there is some problem in processing the message other
|      than interpreting the request for an MDN.  The "processed" or
|      other disposition type with appropriate disposition modifiers is
       to be used in such situations.

It should say:

   8.  The "failed" disposition type MAY NOT be used for the situation
       in which there is some problem in processing the message other
|      than interpreting the request for an MDN.  The "processed"
|      disposition type with appropriate disposition modifiers MUST be
       used in such situations.

Notes:

The ABNF given in Section 7.4.3, on page 25,

AS3-disposition-type = "processed" / "failed"

explicitely excludes "other" disposition types.


Source: apps

Errata ID: 2284
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-14
Verifier Name: Alexey Melnikov
Date Verified: 2010-07-15

Section 7.4.1 says:

   The AS3-MDN follows the MDN specification [6] except where noted in
   this section.  The modified entity definitions in this document use
   the vertical-bar character, '|', to denote a logical "OR"
   construction.  Refer to RFC 2045 for the format of MIME-message-
   headers.

     The format of the AS3-MDN is

     MDN, no signature

       -RFC822/2045
         -RFC3798 (message/disposition-notification)

<<page break>>

     MDN, signature

       -RFC822/2045
         -RFC1847 (multipart/signed)
           -RFC3798 (message/disposition-notification)
           -RFC3851 (application/pkcs7-signature)

It should say:

   The AS3-MDN follows the MDN specification [6] except where noted in
|  this section.  Refer to RFC 2045 for the format of MIME headers.

|  The format of the AS3-MDN is

     MDN, no signature

|      -RFC2822/2045
|        -RFC3462 (multipart/report;
|                  report-type=disposition-notification)
|          -RFC2046 (text/plain)
|          -RFC3798 (message/disposition-notification,
|                    as modified by Section 7.4.2)

     MDN, signature

|      -RFC2822/2045
         -RFC1847 (multipart/signed)
|          -RFC3462 (multipart/report;
|                    report-type=disposition-notification)
|            -RFC2046 (text/plain)
|            -RFC3798 (message/disposition-notification)
           -RFC3851 (application/pkcs7-signature)

Notes:

Unlike, e.g., Section 4.2, the message structures depicted in
Section 7.4.1, on pages 23/24, are imprecise and misleading;
'message/disposition-notification' is *not* the atomic MIME entity
shown in the text; according to RFC 3798, the MDN is encapsulated
in a 'multipart/report', which has a mandatory first body part
of type 'text/plain', not shown in the current text.
Because RFC 4823 explicitely quotes RFC 822 (should better be 2822!),
RFC 2045, and RFC 3798, I strongly suspect that the specification
indeed wanted to re-use the MDN structure specified in RFC 3798.
This is supported by subsequent details exposed in Section 7.4.2.

Furthermore, the RFC text there introduces a notation that is not
made use of anywhere in the RFC. That sentence is to be deleted.


I have omitted the third, optional body part of the 'multipart/report'
-- cf. the final remark (#4) at the end of Appendix A.2 of RFC 4823,
which recommends against making use of it.

Errata ID: 6234
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Benjamin Kaduk
Date Reported: 2020-07-23
Verifier Name: Barry Leiba
Date Verified: 2020-08-04

Section 6.1 says:

   the AUTH command described within [4].  While any authentication
   mechanism based upon [4] MAY be utilized, AUTH TLS (as described in
   [18]) MUST be supported. (Note that [18] relies on TLS Version 1.0
   [13], not Version 1.1 [23].)

It should say:

   the AUTH command described within [4].  While any authentication
   mechanism based upon [4] MAY be utilized, AUTH TLS (as described in
   [18]) MUST be supported. (Note that TLS Version 1.1 [23] is the current
   version of TLS, though [18] references the older Version 1.0 [13].)

Notes:

RFC 4217 (reference [18]) does not specifically require TLS version 1.0. It references RFC 2246 (TLS 1.0) solely because that was the only version of TLS specified at the time of its publication. Securing FTP with TLS merely requires a version of TLS, not a specific version of TLS, so this document should refer to the current version of TLS at the time of its own publication.

Note that [13] is listed as a normative reference and [23] an informative reference; in light of the above correction the normative/informative statuses should be swapped.

RFC 4824, "The Transmission of IP Datagrams over the Semaphore Flag Signaling System (SFSS)", April 2007

Source of RFC: INDEPENDENT

Errata ID: 878
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Henrik Levkowetz
Date Reported: 2007-04-08
Verifier Name: Jogi Hofmueller
Date Verified: 2007-04-16

Section 3.4 says:

                   SFS       \0/     \0__     0/_     0/
                              |       |       |       |\
                             / \     / \     / \     / \
                              U       V       W       X
                   IP-SFS    ACK     KAL     NAK     RTR

                   -----------------------------------------

                   SFS        0__     0__
                             /|       |\
                             / \     / \
                              Y       Z
                   IP-SFS    RTT    unused

It should say:

                   SFS       \0/     |0       0/_     0/
                              |       |\      |       |\
                             / \     / \     / \     / \
                              U       V       W       X
                   IP-SFS    ACK     KAL     NAK     RTR

                   -----------------------------------------

                   SFS       \0__     0__
                              |       |\
                             / \     / \
                              Y       Z
                   IP-SFS    RTT    unused

Notes:

The illustrated SFS for symbol 'Y', signifying control signal 'RTT',
is depicted as identical with symbol 'M', which signals nibble value
0x0C. This means that some implementations may break off receipt with
an error on receiving 0x0C and interpreting it as RTT, while others
may see RTT and interpret it as a spurious 0x0C, and ignore it.

References [JCroft, Wikipedia] gives a different way of signalling 'Y',
which does not coincide with any of the other symbols. This
discrepancy between the current specification and the references may
also result in both implementation and execution differences, as some
interfaces may already have signal 'Y' hard-coded according to [JCroft]
or [Wikipedia], which will result in transmission of an SFS which will
not be understood by an interface that follows the current specification
strictly.

Author: Errors in the forms of SFS representation for SFS V/KAL and SFS Y/RTT.

from pending

Errata ID: 908
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-04-09
Verifier Name: Jogi Hofmueller
Date Verified: 2007-04-16

Section 4.3 says:

   [...].  If the link partner ready to receive, it returns an RTR
   signal.

It should say:

   [...].  If the link partner is ready to receive, it returns an RTR
   signal.

Notes:

word omission

from pending

Errata ID: 909
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-04-09
Verifier Name: Jogi Hofmueller
Date Verified: 2007-04-16

 

RFC 4824 completely fails to appropriatey point out the benefits and
merits of IP-SFS, and to perform a fair comparison with industry
standard strenght security for common wireless protocols.

Apparently, IP-SFS provides for industry standard Wireless Equivalent
Privacy (WEP).  It *is* a wireless protocol!  Its interfaces do not
consume electrical power (if used under daylight conditions) and do not
produce any electromagnetical interference.  The former property
results in great applicability to developing economies that lack
substantial ubiquitous electrical power distribution but have a lot of
cheap manpower available, but it also makes IP-SFS great for countries
with instable electrical power distribution systems, like the U.S.
(and, yet currently still to a lesser degree, Europe).  Both properties
together make IP-SFS strictly immune to any modern cryptanalytical
methods based on the variation of power consumption over time and to
the suspected industry espionage by the electronical 'sky ears' still
deployed in Europe and otherwise mostly idle, since the end of the Cold
War.

Furthermore, IP-SFS apparently is very well suited for environments
with stringent legal requirements for the war against the Axis of
Evil, with its step-by-step increasing legal custody of privacy and
political correctness of content to be performed / enforced by
legal authorities and cooperating access and content providers.

That should make IP-SFS particularly interesting for the emerging
infrastructure of the .cn domain (and for many other countries,
as well).

To change the disadvantageous presentation of IP-SFS and to address
at least a few of its benefits, I recommend to change, via an RFC
Errata Note, the first paragraph of Section 5,

|  By its nature of line-of-sight signaling, IP-SFS is considered
|  insecure.  The transmission of sensitive data over IP-SFS is strongly
|  discouraged unless security is provided by higher level protocols.

to say:

|  By its nature of line-of-sight signaling, IP-SFS is considered to
|  provide industry strength wireless equivalent security and privacy
|  (WEP).  The transmission of sensitive data over IP-SFS is strongly
|  discouraged unless security is provided by legal environments or
|  corporate guidelines of conduct, impending punishment of the
|  interfaces, or other higher level protocols.


:-)

It should say:

[see above]

Notes:

from pending

Errata ID: 880
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Henrik Levkowetz
Date Reported: 2007-04-08
Verifier Name: Jogi Hofmueller
Date Verified: 2007-04-16

Section 3 says:

   IP-SFS adapts the standard SFSS to encode an alphabet of 16 signals
   (flag patterns) to represent data values 0-15 (Section 3.2.1) and 9
   signals to represent control functions (Section 3.2.2).  With 16 data
   signals, IP-SFS transmission is based upon 4-bit nibbles, two per
   octet.  Each of the signal patterns defined in Section 3.2 is called
   an SFS.

It should say:

   IP-SFS adapts the standard SFSS to encode an alphabet of 16 signals
   (flag patterns) to represent data values 0-15 (Section 3.3) and 9
   signals to represent control functions (Section 3.4).  With 16 data
   signals, IP-SFS transmission is based upon 4-bit nibbles, two per
   octet.  Each of the signal patterns defined in Section 3.2 is called
   an SFS.

Notes:

In Section 3. reference is made to sections 3.2.1 and 3.2.2, which
don't exist. I believe you meant to refer to 3.3 and 3.4 respectively.

from pending

RFC 4826, "Extensible Markup Language (XML) Formats for Representing Resource Lists", May 2007

Source of RFC: simple (rai)

Errata ID: 1477
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Byron Campen
Date Reported: 2008-07-22
Verifier Name: Cullen Jennings
Date Verified: 2009-01-08

Section 3.2 says:

    <xs:complexType name="externalType">
     <xs:sequence>
      <xs:element name="display-name" type="display-nameType"
       minOccurs="0"/>
      <xs:any namespace="##other" processContents="lax" minOccurs="0"
       maxOccurs="unbounded"/>
     </xs:sequence>
     <xs:attribute name="anchor" type="xs:anyURI"/>
     <xs:anyAttribute namespace="##other" processContents="lax"/>
    </xs:complexType>

It should say:

    <xs:complexType name="externalType">
     <xs:sequence>
      <xs:element name="display-name" type="display-nameType"
       minOccurs="0"/>
      <xs:any namespace="##other" processContents="lax" minOccurs="0"
       maxOccurs="unbounded"/>
     </xs:sequence>
     <xs:attribute name="anchor" type="xs:anyURI" use="required"/>
     <xs:anyAttribute namespace="##other" processContents="lax"/>
    </xs:complexType>

Notes:

Normative text reads:
The <external> element has a single
mandatory attribute, "anchor", which specifies the external list by
means of an absolute HTTP URI.

Errata ID: 2867
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yi Chen
Date Reported: 2011-07-20
Verifier Name: Robert Sparks
Date Verified: 2011-11-04

Section 3.1 says:

The <entry>
element has a single mandatory attribute, "ref".

It should say:

The <entry-ref>
element has a single mandatory attribute, "ref".

Notes:

ref is a mandatory attribute of entry-ref but not entry.

RFC 4827, "An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents", May 2007

Source of RFC: simple (rai)

Errata ID: 5024
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Olivier Biot
Date Reported: 2017-05-22
Verifier Name: Ben Campbell
Date Verified: 2017-05-22

Section 14 says:

   The authors would like to thank Jari Urpalainen, Jonathan Rosenberg,
   Hisham Khartabil, Aki Niemi, Mikko Lonnfors, Oliver Biot, Alex Audu,

It should say:

   The authors would like to thank Jari Urpalainen, Jonathan Rosenberg,
   Hisham Khartabil, Aki Niemi, Mikko Lonnfors, Olivier Biot, Alex Audu,
                                                

Notes:

My name [Olivier Biot] was misspelled.

(Verifier Note: There were carets marking the change in the original errata, but they were misaligned when viewed outside of the errata tool. I removed them, and added a mention of the changed name in the notes.)

RFC 4828, "TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant", April 2007

Source of RFC: dccp (tsv)

Errata ID: 915
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-04-19
Verifier Name: Sally Floyd
Date Verified: 2007-04-19

Appendix B.1 says:

                   (1.184 Kbps Maximum TFRC Data Sending Rate)

It should say:

                   (1184 Kbps Maximum TFRC Data Sending Rate)

Notes:

The caption for Table 7 is wrong.

from pending

RFC 4842, "Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP)", April 2007

Source of RFC: pwe3 (int)

Errata ID: 1064
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-17

Section 11.2.1.1 says:

   The 28 bits of the EBM are divided into groups of 4 bits, each
   corresponding to a different VTG within the STS container.  All 4 
   bits are used to indicate whether VT1.5 (T1) tributaries are carried
   within a VTG.  The first 3 bits read from right to left are used to
   indicate whether VT2 (E1) tributaries are carried within a VTG.  The
   first 2 bits are used to indicate whether VT3 (DS1C) tributaries are    
   carried within a VTG.

It should say:

   The 28 bits of the EBM are divided into groups of 4 bits, each
   corresponding to a different VTG within the STS container.  All 4
   bits are used to indicate whether VT1.5 (T1) tributaries are carried
   within a VTG.  The 3 rightmost bits in a bit group are used to    
   indicate whether VT2 (E1) tributaries are carried within a VTG.
   The 2 rightmost bits in a bit group are used to indicate whether  
   VT3 (DS1C) tributaries are carried within a VTG.

Notes:

Replaced 'first 3 bits read from right to left' with '3 rightmost
bits' and similarly 'first 2 bits' with '2 rightmost bits'. The
new text avoids possible confusion with regards to the position
of the relevant bits.

from pending

Errata ID: 1065

Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-17
Date Verified: 2011-02-01
Report Text:

   The notation B*3 was replaced with the notation B3* which is
   consistent with the definitions.

from pending

---

Errata ID: 1066
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-17

Section 11.2.3.2 says:

                     All 4 bits are used to indicate whether VC-11 (T1)    
   tributaries are carried within a TUG-2.  The first 3 bits read right
   to left are used to indicate whether VC-12 (E1) tributaries are
   carried within a TUG-2.  The first bit is used to indicate that a
   VC-2 is carried within a TUG-2.

It should say:

                     All 4 bits are used to indicate whether VC-11 (T1)
   tributaries are carried within a TUG-2.  The rightmost 3 bits are 
   used to indicate whether VC-12 (E1) tributaries are carried within a
   TUG-2.  The rightmost bit is used to indicate that a VC-2 is carried
   within a TUG-2.

Notes:

Replaced 'first 3 bits read from right to left' with '3 rightmost
bits' and similarly 'first 2 bits' with '2 rightmost bits'. The
new text avoids possible confusion with regards to the position
of the relevant bits.

from pending

Errata ID: 6718
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lars Eggert
Date Reported: 2021-10-21
Verifier Name: Martin Vigoureux
Date Verified: 2021-11-03

Section 18.1 says:

   [RTP]           Schulzrinne, H., Casner, S., Frederick, R., and V.
                   Jacobson, "RTP: A Transport Protocol for Real-Time
                   Applications", STD 64, RFC 3005, July 2003.

It should say:

   [RTP]           Schulzrinne, H., Casner, S., Frederick, R., and V.
                   Jacobson, "RTP: A Transport Protocol for Real-Time
                   Applications", STD 64, RFC 3550, July 2003.

Notes:

The RFC number for [RTP] should be 3550, not 3005.

RFC 4851, "The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)", May 2007

Note: This RFC has been updated by RFC 8996, RFC 9427

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 953
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-12

Section 4.2.9 says:

      Action

         The Action field is two octets.  Values include:

            Process-TLV

            Negotiate-EAP

It should say:

      Action

         The Action field is two octets.  Values include:

         1  Process-TLV

         2  Negotiate-EAP

Notes:

The 'Action' code points to be dropped from the final text.

from pending

Errata ID: 952
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-12
Verifier Name: RFC Editor
Date Verified: 2007-11-02

 

Section 3.2.1 -- terminological mismatch

Only in this section, the RFC uses the spelling "SessionID" (4 x);
throughout the remainder of the text, "Session ID" is used.


Section 3.2.3 -- typo

In the 3rd text line of Section 3.2.3, on page 12,
the RFC test:

             ... contains a empty Session ID
should say:
             ... contains an empty Session ID
                            ^

Section 3.3.1 -- typo

In the second line of the last paragraph of Section 3.3.1,
on page 13, the RFC text:

             ... If either indicates failure. then the method is
should say:
             ... If either indicates failure, then the method is
                                            ^

Section 3.7 -- typo

In the first line of the second paragraph of Section 3.7,
the RFC text:

   Since EAP is an lock-step protocol, [...]
                 ^
should say:

   Since EAP is a lock-step protocol, [...]


Section 5.5 -- typo

In the third line of Section 5.5 (on page 35), as in many other
places in the RFC, the initial

   Where

should be

   where


Section 6 -- inconsistent use of established terms

The RFC 2434 requirements terms are spelled inconsistently.
For uniformity, at the bottom of page 36,

           ... based on specifications required ...
                        ^            ^ ^
should be:
           ... based on Specification Required ...

and in the fourth line on page 37,

           ... on a specification required basis ...
                    ^             ^
should be:
           ... on a Specification Required basis ...


Section 7.4.1 -- typos

there are two typos in the last part of the first paragraph
of Section 7.4.1; the lines on top of page 40,
                      vvv
|  is unauthenticated an may not have any relevance to the authenticated
   identity.  EAP-FAST implementations should not attempt to compare any
   identity disclosed in the initial cleartext EAP Identity response
|  packet with those Identities authenticated in Phase 2
                                                        ^
should say:
                        v
|  is unauthenticated and may not have any relevance to the authenticated
   identity.  EAP-FAST implementations should not attempt to compare any
   identity disclosed in the initial cleartext EAP Identity response
|  packet with those Identities authenticated in Phase 2.

It should say:

[see above]

Notes:

editorial nits.

from pending.

RFC 4852, "IPv6 Enterprise Network Analysis - IP Layer 3 Focus", April 2007

Source of RFC: v6ops (ops)

Errata ID: 1044
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-08

Section 10.2 says:

   [TSPB]   Blanchet, M., and F. Parent, "IPv6 Tunnel Broker with the
|           Tunnel Setup Protocol (TSP", Work in Progress, August 2005.

It should say:

   [TSPB]   Blanchet, M., and F. Parent, "IPv6 Tunnel Broker with the
|           Tunnel Setup Protocol (TSP)", Work in Progress, August 2005.

Notes:

Matching parenthesis missing.

RFC 4853, "Cryptographic Message Syntax (CMS) Multiple Signer Clarification", April 2007

Source of RFC: smime (sec)

Errata ID: 5
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-03

Section 4 says:

RFC 3852, section 5.1, the next to the last paragraph says:

It should say:

RFC 3852, section 5.1, the last paragraph says:

RFC 4857, "Mobile IPv4 Regional Registration", June 2007

Source of RFC: mip4 (int)

Errata ID: 2103
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Pete McCann
Date Reported: 2010-04-01
Verifier Name: Brian Haberman
Date Verified: 2012-10-04

Section 8.1 says:

8.1.  Regional Registration Flag

   The only change to the Mobility Agent Advertisement Extension defined
   in [RFC3344] is a flag indicating that the domain, to which the FA
   generating the Agent Advertisement belongs, supports regional
   registrations.  The flag is inserted after the flags defined in
   [RFC3344], [RFC3024], and [RFC3519].

   Regional Registration flag:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |    Length     |        Sequence Number        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Lifetime            |R|B|H|F|M|G|r|T|U|I| reserved  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  zero or more Care-of Addresses               |
       |                              ...                              |

   The flag is defined as follows:

            Type    16 (Mobility Agent Advertisement)

            I       Regional Registration.  This domain supports
                    regional registration as specified in this document.

It should say:

8.1.  Regional Registration Flag

   The only change to the Mobility Agent Advertisement Extension defined
   in [RFC3344] is a flag indicating that the domain, to which the FA
   generating the Agent Advertisement belongs, supports regional
   registrations.  The flag is inserted after the flags defined in
   [RFC3344], [RFC3024], [RFC3519], and [RFC3543].

   Regional Registration flag:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |    Length     |        Sequence Number        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Lifetime            |R|B|H|F|M|G|r|T|U|X|I|reserved |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  zero or more Care-of Addresses               |
       |                              ...                              |

   The flag is defined as follows:

            Type    16 (Mobility Agent Advertisement)

            I       Regional Registration.  This domain supports
                    regional registration as specified in this document.

Notes:

Bit 10 was already allocated by RFC 3543. We need to move the 'I' bit one position to the right, and also add a reference to RFC 3543 in the References section.

RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", September 2007

Note: This RFC has been updated by RFC 5942, RFC 6980, RFC 7048, RFC 7527, RFC 7559, RFC 8028, RFC 8319, RFC 8425, RFC 9131

Source of RFC: ipv6 (int)

Errata ID: 1595
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Teco Boot
Date Reported: 2008-11-11
Verifier Name: Brian Haberman
Date Verified: 2012-06-01

Section 2.2 says:

   asymmetric reachability
                  - a link where non-reflexive and/or non-transitive
                    reachability is part of normal operation.  (Non-
                    reflexive reachability means packets from A reach B,
                    but packets from B don't reach A.  Non-transitive
                    reachability means packets from A reach B, and
                    packets from B reach C, but packets from A don't
                    reach C.)  Many radio links exhibit these
                    properties.

It should say:

   asymmetric reachability
                  - a link where uni-directional and/or non-transitive
                    reachability is part of normal operation.  (Uni-
                    directional reachability means packets from A reach B,
                    but packets from B don't reach A.  Non-transitive
                    reachability means packets from A reach B, and
                    packets from B reach C, but packets from A don't
                    reach C.)  Many radio links exhibit these
                    properties.

Notes:

Discussed on Autoconf ML:
http://www.ietf.org/mail-archive/web/autoconf/current/msg01119.html
Term non-reflexive link is "link to itself". To be replaced with either asymmetric, non-symmetric or uni-directional. Asymmetric and Non-symmetric are confusing as those are often used for asymmetric link metrics (e.g. ADSL, UMTS/HSPDA).

Errata ID: 2709
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jan Kramer
Date Reported: 2011-02-09
Verifier Name: Brian Haberman
Date Verified: 2012-10-03

Section Appendix C says:

!INCOMPLETE     NA, Solicited=1,        -                   REACHABLE
                Override=0
                Same link-layer
                address as cached.

!INCOMPLETE     NA, Solicited=any,     Update content of    unchanged
                Override=any, No       IsRouter flag.
                link-layer address

It should say:

!INCOMPLETE     NA, Solicited=1,      -                   REACHABLE
                Override=0
                Same link-layer
                address as cached.

!INCOMPLETE     NA, Solicited=1,     Update content of    REACHABLE
                Override=any, No     IsRouter flag.
                link-layer address

!INCOMPLETE     NA, Solicited=0,     Update content of    unchanged
                Override=any, No     IsRouter flag.
                link-layer address


or 



!INCOMPLETE     NA, Solicited=1,        -                   REACHABLE
                Override=0
                Same link-layer
                address as cached
                or no link-layer 
                address

!INCOMPLETE     NA, Solicited=any,     Update content of    unchanged
                Override=any, No       IsRouter flag.
                link-layer address

Notes:

Section 7.2.4. says:

"If the solicitation's IP Destination Address is
not a multicast address, the Target Link-Layer Address option MAY be
omitted; the neighboring node's cached value must already be current
in order for the solicitation to have been received."

Consider host A has a Neighbor Cache Entry for a unicast address of host B with the state PROBE. If it sends an NS to that address, B will answer with a NA.
If the Target Link-Layer Address is actually omitted, the host which sent the solicitation would only update the IsRouter flag of the Neighbor Cache Entry and leave the state unchanged.
At retransmit timeout host A would send another NS, since the state is still PROBE. After some retransmissions the entry would be discarded, although it was obviously reachable.

With one of the above suggestions, the Neighbor Cache Entry will be marked as REACHABLE, even if no Target Link-Layer Option is included in the NA.

Errata ID: 3154
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ladislav Lhotka
Date Reported: 2012-03-11
Verifier Name: Brian Haberman
Date Verified: 2012-12-12

Section 6.2.1 says:

Default: 0.33 * MaxRtrAdvInterval If MaxRtrAdvInterval >= 9 seconds;
otherwise, the Default is MaxRtrAdvInterval.

It should say:

Default: 0.33 * MaxRtrAdvInterval If MaxRtrAdvInterval >= 9 seconds;
otherwise, the Default is 0.75 * MaxRtrAdvInterval.

Notes:

The original text contradicts the previous paragraph in the definition of MinRtrAdvInterval, which says: "MUST be no less than 3 seconds and no greater than .75 * MaxRtrAdvInterval."

Errata ID: 6983
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ramakrishna Rao DTV
Date Reported: 2022-05-30
Verifier Name: Eric Vyncke
Date Verified: 2023-08-03

Section 11.1 says:

   Redirect attacks can also be achieved by any host in order to flood a
   victim or steal its traffic.  A host can send a Neighbor
   Advertisement (in response to a solicitation) that contains its IP
   address and a victim's link-layer address in order to flood the
   victim with unwanted traffic.  Alternatively, the host can send a
   Neighbor Advertisement that includes a victim's IP address and its
   own link-layer address to overwrite an existing entry in the sender's
   destination cache, thereby forcing the sender to forward all of the
   victim's traffic to itself.

It should say:

   Redirect attacks can also be achieved by any host in order to flood a
   victim or steal its traffic.  A host can send a Neighbor
   Advertisement (in response to a solicitation) that contains its IP
   address and a victim's link-layer address in order to flood the
   victim with unwanted traffic.  Alternatively, the host can send a
   Neighbor Advertisement that includes a victim's IP address and its
   own link-layer address to overwrite an existing entry in the sender's
   neighbor cache, thereby forcing the sender to forward all of the
   victim's traffic to itself.

Notes:

s/destination cache/neighbor cache/

Neighbor advertisement affects neighbor cache and not destination cache.

Errata ID: 4461
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Zhou Yangchao
Date Reported: 2015-08-30
Verifier Name: Brian Haberman
Date Verified: 2015-09-14

Section 6.2.3 says:

- In the Cur Hop Limit field: the interface's configured
        CurHopLimit.

It should say:

- In the Cur Hop Limit field: the interface's configured
        AdvCurHopLimit.

Notes:

The interface 's configured name of Cur Hop Limit is AdvCurHopLimit in the Section 6.2.1.

RFC 4865, "SMTP Submission Service Extension for Future Message Release", May 2007

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 2040
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Arnt Gulbrandsen
Date Reported: 2010-02-11
Verifier Name: Alexey Melnikov
Date Verified: 2010-02-15

Section 3 says:

   4) One required parameter, the hold-param, is added to the MAIL
      command using either the keyword "HOLDFOR" or the keyword
      "HOLDUNTIL".

 [...]

      Using ABNF [n2], the syntax of this parameter is as follows:

         future-release-interval = future-release-integer

         future-release-date-time = Internet-style-date-time-UTC

It should say:

The last quoted ABNF production should be:

         future-release-date-time = date-time
            ; <date-time> defined in Section 5.6 of RFC 3339

Notes:

The ABNF contains a dangling production. An early draft shows that the RFC 3339 production date-time is what's intended (as Ned Freed found out).

The RFC also has no examples. I have a working server implementation of this, so without examples I guess talking to my server is second best. Send me mail in case of interest.

RFC 4866, "Enhanced Route Optimization for Mobile IPv6", May 2007

Source of RFC: mipshop (int)

Errata ID: 601
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-14
Verifier Name: Christian Vogt
Date Verified: 2007-06-25

Section 4.2 says:

   If the Binding Update message is authenticated based on the CGA  
   property of the mobile node's home address or by a proof of the
   mobile node's knowledge of a permanent home keygen token, the
   lifetime for the binding SHOULD be set to the maximum of
                                                 ^^^^^^^
   MAX_CGA_BINDING_LIFETIME and the value specified in the Lifetime
   field of the Binding Update message.

It should say:

   If the Binding Update message is authenticated based on the CGA
   property of the mobile node's home address or by a proof of the
   mobile node's knowledge of a permanent home keygen token, the
   lifetime for the binding SHOULD be set to the minimum of
                                                 ^^^^^^^      
   MAX_CGA_BINDING_LIFETIME and the value specified in the Lifetime
   field of the Binding Update message.

Notes:

Page 21, 1st paragraph

Errata ID: 602
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-14
Verifier Name: Christian Vogt
Date Verified: 2007-06-25

Section 4.2 says:

                                          If the Binding Update message
   is authenticated through a proof of the mobile node's reachability at
   the home address, then the lifetime for the binding SHOULD be set to
   the maximum of MAX_RR_BINDING_LIFETIME [1] and the value specified in
       ^^^^^^^
   the Lifetime field of the Binding Update message.

It should say:

                                          If the Binding Update message
   is authenticated through a proof of the mobile node's reachability at
   the home address, then the lifetime for the binding SHOULD be set to
   the minimum of MAX_RR_BINDING_LIFETIME [1] and the value specified in
       ^^^^^^^
   the Lifetime field of the Binding Update message.

Notes:

Page 21, 1st paragraph

Errata ID: 4
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-14
Verifier Name: Christian Vogt
Date Verified: 2007-06-25

Section 6.2 says:

                                                           Enhanced
    Router Optimization does not make assumptions on the relationship
    ^^^^^^
    between mobile and correspondent nodes.

It should say:

                                                           Enhanced
    Route Optimization does not make assumptions on the relationship
    ^^^^^  
    between mobile and correspondent nodes.

Notes:

Page 43, 1st paragraph

Errata ID: 603
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-14
Verifier Name: Christian Vogt
Date Verified: 2007-06-25

Section 4.2 says:

                                                       The correspondent
    node may in either case grant a further reduced lifetime, but it MUST
         ^^^
    NOT accept a higher lifetime.

It should say:

                                                       The correspondent
    node MAY in either case grant a further reduced lifetime, but it MUST
         ^^^
    NOT accept a higher lifetime.

Notes:

Page 21, 1st paragraph

RFC 4867, "RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", April 2007

Source of RFC: avt (rai)

Errata ID: 4347
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Thomas Belling
Date Reported: 2015-04-27
Verifier Name: Ben Campbell
Date Verified: 2016-05-25

Section 4.3.1 says:

   CMR (4 bits): Indicates a codec mode request sent to the speech
      encoder at the site of the receiver of this payload.  The value of
      the CMR field is set to the frame type index of the corresponding
      speech mode being requested.  The frame type index may be 0-7 for
      AMR, as defined in Table 1a in [2], or 0-8 for AMR-WB, as defined
      in Table 1a in [4].  CMR value 15 indicates that no mode request
      is present, and other values are for future use.

   The codec mode request received in the CMR field is valid until the
   next codec mode request is received, i.e., a newly received CMR value
   corresponding to a speech mode, or NO_DATA overrides the previously
   received CMR value corresponding to a speech mode or NO_DATA.
   Therefore, if a terminal continuously wishes to receive frames in the
   same mode X, it needs to set CMR=X for all its outbound payloads, and
   if a terminal has no preference in which mode to receive, it SHOULD
   set CMR=15 in all its outbound payloads.

   If receiving a payload with a CMR value that is not a speech mode or
   NO_DATA, the CMR MUST be ignored by the receiver.

It should say:

   CMR (4 bits): Indicates a codec mode request sent to the speech
      encoder at the site of the receiver of this payload.  The value of
      the CMR field is set to the frame type index of the corresponding
      speech mode being requested.  The frame type index may be 0-7 for
      AMR, as defined in Table 1a in [2], or 0-8 for AMR-WB, as defined
      in Table 1a in [4].  CMR value 15 indicates that the receiver has
      no preference in which mode within the negotiated mode set to
      receive, and other values are for future use.

   The codec mode request received in the CMR field is valid until the
   next codec mode request is received, i.e., a newly received CMR value
   corresponding to a speech mode, or CMR=15 overrides the previously
   received CMR value corresponding to a speech mode or CMR=15.
   Therefore, if a terminal continuously wishes to receive frames not 
   higher than mode X, it needs to set CMR=X for all its outbound
   payloads, and if a terminal has no preference in which mode within 
   the negotiated mode set to receive, it SHOULD set CMR=15 in all its
   outbound payloads.

   If receiving a payload with a CMR value that is not a speech mode or
   CMR=15, the CMR MUST be ignored by the receiver.

Notes:

The definition of CMR 15 as "no mode request is present", could be understood to suggest that other previously received CMR values remain applicable. However, this contradicts text in the subsequent paragraphs suggesting CMR=15 should be used when the "terminal has no preference in which mode to receive", and stating that any previously received CMR value is overridden by CMR=15.

It is thus unclear for a receiving entity that has previously received a CMR value requesting a lower AMR mode and then receives a CMR value 15 if it should continue to send using the lower AMR mode or if it can select a higher mode within the negotiated mode set based on own preferences.

CMR 15 is referred to as "NO_DATA" in subsequent text, but "NO_DATA" is not well defined. This value appears in the quoted references, but these references are only quoted for CMR values 0 to 7/8.

It is also not perfectly clear if CMR=15 allows for any mode, or only modes within the negotiated mode set. However, the definition of the mode-set parameter in Clause 8.1 suggests that only modes within the negotiated mode-set can be sent when a mode-set has been negotiated.

The text "if a terminal continuously wishes to receive frames in the same mode X, it needs to set CMR=X for all its outbound payloads" seems to suggest that the receiver will always follow the request, although it may also choose to send lower modes, as explained in text further below.

This erratum has been discussed and endorsed by the 3GPP SA4 group before submission to IETF.

Errata ID: 4348
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Thomas Belling
Date Reported: 2015-04-27
Verifier Name: Ben Campbell
Date Verified: 2016-05-25

Section 4.3.1 says:

   The encoder SHOULD follow a received codec mode request, but MAY
   change to a lower-numbered mode if it so chooses, for example, to
   control congestion.

It should say:

   The encoder MUST follow a received codec mode request as soon as
   possible. It SHOULD use the requested mode, but MAY change to a
   lower-numbered mode if it so chooses, for example, to
   control congestion. However, the encoder MUST NOT use a
   higher-numbered mode than the received codec mode request.

Notes:

This seems to be the intention of the existing text, but is not explicitly stated. It is essential for the end-to-end mode control and interoperability with 3GPP CS networks that a peer does not send higher modes than requested.

This erratum has been discussed and endorsed by the 3GPP SA4 group before submission to IETF.

Errata ID: 4349
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Thomas Belling
Date Reported: 2015-04-27
Verifier Name: Ben Campbell
Date Verified: 2016-05-25

Section 8.1 says:

      mode-set: Restricts the active codec mode set to a subset of all
               modes, for example, to be able to support transport
               channels such as GSM networks in gateway use cases.
               Possible values are a comma separated list of modes from
               the set: 0,...,7 (see Table 1a [2]).  The SID frame type
               8 and NO_DATA (frame type 15) are never included in the
               mode set, but can always be used.  If mode-set is
               specified, it MUST be abided, and frames encoded with
               modes outside of the subset MUST NOT be sent in any RTP
               payload or used in codec mode requests.  If not present,
               all codec modes are allowed for the payload type.

It should say:

      mode-set: Restricts the active codec mode set to a subset of all
               modes, for example, to be able to support transport
               channels such as GSM networks in gateway use cases.
               Possible values are a comma separated list of modes from
               the set: 0,...,7 (see Table 1a [2]).  The SID frame type
               8 and NO_DATA (frame type 15) are never included in the
               mode set, but can always be used.  If mode-set is
               specified, it MUST be abided, i.e. frames encoded with
               modes outside of the subset MUST NOT be sent in any RTP
               payload and codec mode requests MUST only use modes
               within the mode-set or CMR=15. If the mode-set parameter
               is not present, then all codec modes are allowed for the
               payload type.

Notes:

The existing text rules out that CMR=15 is used when a mode-set has been negotiated. However, this contradicts a statement in .clause 4.3.1 that if a terminal has no preference in which mode to receive, it SHOULD set CMR=15 in all its outbound payloads.

This erratum has been discussed and endorsed by the 3GPP SA4 group before submission to IETF.

RFC 4868, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", May 2007

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 1785
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sheila Frankel
Date Reported: 2009-05-19
Verifier Name: Pasi Eronen
Date Verified: 2009-05-27

Section 2.7.2.3 says:

Test Case AUTH512-4:
   Key =          0a0b0c0d0e0f10111213141516171819
                  0102030405060708090a0b0c0d0e0f10
                  1112131415161718191a1b1c1d1e1f20
                  2122232425262728292a2b2c2d2e2f30
                  3132333435363738393a3b3c3d3e3f40  (64 bytes)

It should say:

Test Case AUTH512-4:
   Key =          0102030405060708090a0b0c0d0e0f10
                  1112131415161718191a1b1c1d1e1f20
                  2122232425262728292a2b2c2d2e2f30
                  3132333435363738393a3b3c3d3e3f40  (64 bytes)

Notes:

Originally noted by Tero Kivinen

RFC 4871, "DomainKeys Identified Mail (DKIM) Signatures", May 2007

Note: This RFC has been obsoleted by RFC 6376

Note: This RFC has been updated by RFC 5672

Source of RFC: dkim (sec)

Errata ID: 1376
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tony Hansen
Date Reported: 2008-03-21
Verifier Name: Pasi Eronen
Date Verified: 2009-05-14

Section 3.4.3/.4 says:

section 3.4.3 & section 3.4.4

It should say:

Add to end of section 3.4.3:

   The sha1 value (in base64) for an empty body (canonicalized to a "CRLF") is "uoq1oCgLlTqpdDX/iUbLy7J1Wic=".
   The sha256 value is "frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=".

Add to end of section 3.4.4:

   The sha1 value (in base64) for an empty body (canonicalized to a null input) is "2jmj7l5rSw0yVb/vlWAYkK/YBwk=".
   The sha256 value is "47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=".

Notes:

From the October 2008 interop event:

Empty message bodies
• the “simple” body canonicalization says precisely what to do in the case of an empty message body
• “relaxed” does not
• Consensus is that the “relaxed” body canonicalization of the null body is the null input
• Majority felt it was conspicuous that “simple” was explicit while “relaxed” was not
• Errata: add clarification statement on expected values for relaxed

Errata ID: 1377
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tony Hansen
Date Reported: 2008-03-21
Verifier Name: Pasi Eronen
Date Verified: 2009-05-14

Section 3.4.4 says:

---

It should say:

Add a 4th bullet item to section 3.4.4:

o  If the body is non-empty, but does not end with a CRLF, a CRLF is 
   added.  (For email, this is only possible when using extensions to
   SMTP or non-SMTP transport mechanisms.)

Notes:

From the October 2008 interop event:

No Trailing CR-LF
* What if body is non-empty, but does not end in CRLF?
* Only possible with BDAT or non-SMTP transport mechanisms
* “simple” (§3.4.3) says to add a CRLF
* “relaxed” (§3.4.4) says nothing
* Consensus is to add a CRLF for Relaxed if
– it was missing and
– the body is not empty
– Errata: Add statement on what to do for Relaxed

Errata ID: 1378
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tony Hansen
Date Reported: 2008-03-21
Verifier Name: Pasi Eronen
Date Verified: 2009-05-14

Section 3.3 says:

The rsa-sha256 algorithm is the default if no algorithm is specified. 

It should say:

(nothing)

Notes:

According to 3.5, including "a=" is REQUIRED, so the algorithm is
always specified, and there is no default.

Errata ID: 1379
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tony Hansen
Date Reported: 2008-03-21
Verifier Name: Pasi Eronen
Date Verified: 2009-05-14

Section 3.5 says:

       sig-z-tag      = %x7A [FWS] "=" [FWS] sig-z-tag-copy
                    *( [FWS] "|" sig-z-tag-copy )
   sig-z-tag-copy = hdr-name ":" qp-hdr-value

It should say:

       sig-z-tag      = %x7A [FWS] "=" [FWS] sig-z-tag-copy
                    *( "|" [FWS] sig-z-tag-copy )
   sig-z-tag-copy = hdr-name [FWS] ":" qp-hdr-value

Notes:

From the October 2008 interop event, there are several issues with z=:

FWS in z= tag

1) Does not allow any FWS between the "|" and the following header name in sig-z-tag-copy

2) By the ABNF, the informative example that immediately follows is invalid:

z=From:foo@eng.example.net|To:joe@example.com|
----Subject:demo=20run|Date:July=205,…

3) The [FWS] is redundant there; sig-z-tag-copy ends with qp-hdr-value, which can already end with arbitrary FWS

4) No FWS allowed between the hdr_name and the following ":“:

The modified ABNF is not redundant and agrees with the example.

Errata ID: 1384
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tony Hansen
Date Reported: 2008-03-22
Verifier Name: Pasi Eronen
Date Verified: 2009-05-14

Section 4.3.4 says:

   The "relaxed" body canonicalization algorithm:

   o  Ignores all whitespace at the end of lines.  Implementations MUST
      NOT remove the CRLF at the end of the line.

   o  Reduces all sequences of WSP within a line to a single SP
      character.

   o  Ignores all empty lines at the end of the message body.  "Empty
      line" is defined in Section 3.4.3.

It should say:

   The "relaxed" body canonicalization algorithm MUST apply the
   following steps (a) and (b) in order:

   a) Reduce whitespace:
      *  Ignore all whitespace at the end of lines.  Implementations MUST
         NOT remove the CRLF at the end of the line.

      *  Reduce all sequences of WSP within a line to a single SP
         character.

   b)  Ignore all empty lines at the end of the message body.  "Empty
      line" is defined in Section 3.4.3.

Notes:

This was discussed on the dkim interop mailing list.

You can wind up with different results depending on whether steps 1 and 3 are executed in that order or swapped around. Half of the implementations were found to do it one way and another half the other way.

It was decided that the same text applied to section 4.3.2

The "relaxed" header canonicalization algorithm MUST apply the
following steps in order:

should be used in 4.3.4 as well, that is

The "relaxed" body canonicalization algorithm MUST apply the
following steps in order:

But since steps 1&2 can still be done in either order, make those sub-bullets of step 1.

Just to be totally clear, following this decision we would wind up with this sequence.

Given this input:

testing<cr><lf>
<sp><sp><cr><lf>
<cr><lf>

a) Reduce whitespace:
* Ignore all whitespace at the end of lines. Implementations MUST
NOT remove the CRLF at the end of the line.

testing<cr><lf>
<cr><lf>
<cr><lf>

* Reduce all sequences of WSP within a line to a single SP
character.

testing<cr><lf>
<cr><lf>
<cr><lf>

b) Ignore all empty lines at the end of the message body. "Empty
line" is defined in Section 3.4.3.

testing<cr><lf>

If the two steps in (a) are performed in the opposite order,

testing<cr><lf>
<sp><sp><cr><lf>
<cr><lf>

a) Reduce whitespace:
* Reduce all sequences of WSP within a line to a single SP
character.

testing<cr><lf>
<sp><cr><lf>
<cr><lf>

* Ignore all whitespace at the end of lines. Implementations MUST
NOT remove the CRLF at the end of the line.

testing<cr><lf>
<cr><lf>
<cr><lf>

b) Ignore all empty lines at the end of the message body. "Empty
line" is defined in Section 3.4.3.

testing<cr><lf>

Errata ID: 1461
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Frank Ellermann
Date Reported: 2008-07-04
Verifier Name: Pasi Eronen
Date Verified: 2009-05-14

Section 3.5 says:

       sig-h-tag       = %x68 [FWS] "=" [FWS] hdr-name
                     0*( *FWS ":" *FWS hdr-name )

It should say:

       sig-h-tag       = %x68 [FWS] "=" [FWS] hdr-name
                     0*( [FWS] ":" [FWS] hdr-name )

Notes:

Confirmed by many occurrences of [FWS] in this section the intention is to allow optional "folding white space" with at most one folding. Compare section 2.3 in this memo for the rationale; more than one folding is known as <obs-FWS> in RFC 2822 and MUST NOT be generated.

Errata ID: 1487
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Murray S. Kucherawy
Date Reported: 2008-08-14
Verifier Name: Pasi Eronen
Date Verified: 2009-05-14

Section 3.6.1 says:

   v=  Version of the DKIM key record (plain-text; RECOMMENDED, default
       is "DKIM1").  If specified, this tag MUST be set to "DKIM1"
       (without the quotes).  This tag MUST be the first tag in the
       record.  Records beginning with a "v=" tag with any other value
       MUST be discarded.  Note that verifiers must do a string
       comparison on this value; for example, "DKIM1" is not the same as
       "DKIM1.0".

       ABNF:

       key-v-tag    = %x76 [FWS] "=" [FWS] "DKIM1"

It should say:

   v=  Version of the DKIM key record (plain-text; RECOMMENDED, default
       is "DKIM1").  If specified, this tag MUST be set to "DKIM1"
       (without the quotes).  This tag MUST be the first tag in the
       record.  Records beginning with a "v=" tag with any other value
       MUST be discarded.  Note that verifiers must do a string
       comparison on this value; for example, "DKIM1" is not the same as
       "DKIM1.0".

       ABNF:

       key-v-tag    = %x76 [FWS] "=" [FWS] %x44 %x4B %x49 %x4D %x31

Notes:

RFC5234 section 2.3 says string literals in ABNF are case-insensitive. However, RFC4871 section 3.2 says tag values are case-sensitive unless stated otherwise. This renders the defintion of "v=" in section 3.6.1 of this RFC ambiguous.

Therefore, one interpretation of "DKIM1" here allows "dkim1" and one does not.

Either the "case-sensitive" nature of tag values should be changed, or the ABNF needs to be revised to be more precise.

RFC 4872, "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", May 2007

Note: This RFC has been updated by RFC 4873, RFC 6780, RFC 9270

Source of RFC: ccamp (rtg)

Errata ID: 928
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-07
Verifier Name: Adrian Farrel
Date Verified: 2010-10-30

Section 14.1 says:

[[Within the explanations for the PROTECTION Object, on mid-page 32]]

Reserved: 5 bits

It should say:

Reserved: 6 bits

Notes:

See the artwork of the object on page 31 and count the bits.

from pending

Errata ID: 929
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-07
Verifier Name: RFC Editor
Date Verified: 2007-11-02

Section 15.1 says:

   The primary path route is specified via the PRIMARY_PATH_ROUTE object
   (PPRO).  The Primary Path Route Class Number (Class-Num) of form
   0bbbbbbb 38.

It should say:

   The primary path route is specified via the PRIMARY_PATH_ROUTE object
   (PPRO).  The Primary Path Route Class Number (Class-Num) of form
   0bbbbbbb is 38.
       
or even:

   The primary path route is specified via the PRIMARY_PATH_ROUTE object
   (PPRO).  The Primary Path Route Class Number (Class-Num) of form
   0bbbbbbb assigned by IANA is 38.

Notes:

Missing verb.

from pending

Errata ID: 930
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-07
Verifier Name: RFC Editor
Date Verified: 2007-11-02

Section 15.1 says:

   The contents of a PRIMARY_PATH_ROUTE object are a series of
   variable-length data items called subobjects (see Section 15.3).

It should say:

   The contents of a PRIMARY_PATH_ROUTE object are a series of
   variable-length data items called subobjects (see Section 15.2).

Notes:

Referred to wrong section. 15.3 --> 15.2

from pending

Errata ID: 931
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-07
Verifier Name: Adrian Farrel
Date Verified: 2010-10-30

Section 15.2 says:

   An empty PPRO with no subobjects is considered illegal.  If there is
   no first subobject, the corresponding Path message is also in error,
   and the receiving node SHOULD return a PathErr message with the new
   error code/sub-code "Routing Problem/Bad PRIMARY_PATH_ROUTE object".

It should say:

   An empty PPRO has no subobjects and is considered illegal.  A node
   receiving a Path message containing an empty PPRO SHOULD return a
   PathErr message with the new error code/sub-code "Routing Problem/
   Bad PRIMARY_PATH_ROUTE object".

Notes:

The original problem report said...

According to the text, PPROs are only admitted in Path messages.
PPROs "with no first subobject" carry no subobjects at all.
It is unclear why the text tries to distinguish these 'too cases'
and uses the word, "also", in the second sentence.

Something significant might have been lost in the text,
which cannot be concluded from the context.
In this case, please supply the missing clues.
Otherwise, the RFC should read unambiguously as supplied above.

...and proposed the text...

An empty PPRO with no subobjects is considered illegal. A node
receiving an empty PPRO SHOULD return a PathErr message with the new
error code/sub-code "Routing Problem/Bad PRIMARY_PATH_ROUTE object".

This proposal is rejected in favor of the corrected text because it lost some of the meaning.

Errata ID: 933
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-07
Verifier Name: Adrian Farrel
Date Verified: 2010-10-30

Section 16.2 says:

   Similarly, terminating nodes receiving a Path message with a
   PROTECTION object requiring association between working and recovery
   LSPs MUST include an ASSOCIATION object.  Otherwise, such nodes MUST
   return a PathErr message with the new error code/sub-code "Routing
   Problem/PROTECTION object not Applicable".

It should say:

   Similarly, a Path message with a PROTECTION object requiring
   association between working and recovery LSPs MUST include an
   ASSOCIATION object.  Terminating nodes receiving such Path message
   without an ASSOCIATION object MUST return a PathErr message with the
   new error code/sub-code "Routing Problem/PROTECTION object not
   Applicable".

Errata ID: 1935
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vishwas Manral
Date Reported: 2009-10-29
Verifier Name: Adrian Farrel
Date Verified: 2009-10-30

Section 15.3 says:

   - PRROs SHOULD be present in the Path message for the pre-
     provisioning of the secondary protecting LSP to enable recovery
     resource sharing between one or more secondary protecting LSPs (see
     Section 15.4).

It should say:

   - PPROs SHOULD be present in the Path message for the pre-
     provisioning of the secondary protecting LSP to enable recovery
     resource sharing between one or more secondary protecting LSPs (see
     Section 15.4).

Notes:

Second bullet point in the section.
s/PRRO/PPRO/

RFC 4873, "GMPLS Segment Recovery", May 2007

Note: This RFC has been updated by RFC 9270

Source of RFC: ccamp (rtg)

Errata ID: 1797
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: David McWalter
Date Reported: 2009-06-23
Verifier Name: Adrian Farrel
Date Verified: 2010-08-20

Section 5.2 says:

The collection of SRROs is controlled via the
segment-recording-desired flag in the SESSION_ATTRIBUTE object.  This
flag MAY be set even when SEROs are not used.

It should say:

   The collection of SRROs is controlled via the
   presence of an RRO in the message being processed.

Notes:

No request was made to IANA to assign a value for the segment-recording-desired flag.

As reported in the Errata, the segment-recording-desired flag is
unassigned. The flag is unassigned and therefore cannot be used.
As agreed to on the CCAMP mail list and the Stockholm (IETF 75)
working group meeting the the collection of SRROs should be
controlled based on the presence of an RRO in the message being
processed. That is, the segment-recording-desired flag should be
considered to be set when an RRO is present in the message being
processed.

Errata ID: 937
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-08
Verifier Name: Adrian Farrel
Date Verified: 2010-10-30

Section 4.2.4 says:

   Recovery LSP removal follows standard procedures defined in [RFC3209]
   and [RFC3473].  This includes with and without setting the
   administrative status.

It should say:

   Recovery LSP removal follows standard procedures defined in [RFC3209]
   and [RFC3473].  These procedures include LSP removal with and without
   setting the administrative status flags described in Section 7 of
   [RFC3473].

Errata ID: 939
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-08
Verifier Name: Adrian Farrel
Date Verified: 2010-10-30

Section 4.3.1 says:

   o new text:
      If a message contains multiple NOTIFY_REQUEST objects, only the
      first object used is in notification.  Subsequent NOTIFY_REQUEST
      objects MUST be propagated in the order received.

It should say:

   o new text:
      If a message contains multiple NOTIFY_REQUEST objects, only the
      first object is used to supply the information used to build and
      send a notification. Subsequent NOTIFY_REQUEST objects MUST be
      propagated in the order received.

Notes:

The original proposed text (below) is rejected because the presence of the NOTIFY_REQUEST object is not a trigger.
o new text:
If a message contains multiple NOTIFY_REQUEST objects, only the
first object is used to potentially trigger a notification.
Subsequent NOTIFY_REQUEST objects MUST be propagated in the order
received.

Errata ID: 943
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-08
Verifier Name: Adrian Farrel
Date Verified: 2010-10-30

Section 6.1 says:

   LSP Segment Recovery Flags are carried in the PROTECTION object of
   the same C-Type defined in [RFC4872].  The format of the flags are:

It should say:

   LSP Segment Recovery Flags are carried in the PROTECTION object of
   C-Type 2 defined in [RFC4872].  The format of the modifed PROTECTION
   object carrying these flags is:

Notes:

The subsequent diagram depicts the full object, not only the (new) flags.

RFC 4874, "Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", April 2007

Note: This RFC has been updated by RFC 6001, RFC 8390

Source of RFC: ccamp (rtg)

Errata ID: 3572
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dhruv Dhody
Date Reported: 2013-03-28
Verifier Name: Adrian Farrel
Date Verified: 2013-03-29

Section 1.2 says:

           area A               area B              area C
    <-------------------> <----------------> <------------------>

   Ingress-----A1----A2----AB1----B1----B2----BC1----C1----C2----Egress
   ^  \                / | \              / | \                /
   |   \              /  |  \            /  |  \              /
   |    A3----------A4--AB2--B3--------B4--BC2--C3----------C4
   |                     ^                  ^
   |                     |                  |
   |                     |                  |
   |                     |              ERO: (C3-strict, C4-strict,
   |                     |                    Egress-strict)
   |                     |              XRO: Not needed
   |                     |
   |               ERO: (B3-strict, B4-strict, BC2-strict, Egress-loose)
   |               XRO: (BC1, C1, C2)
   |
   ERO: (A3-strict, A4-strict, AB2-strict, Egress-loose)
   XRO: (AB1, B1, B2, BC1, C1, C2, Egress)

It should say:

           area A               area B              area C
    <-------------------> <----------------> <------------------>

   Ingress-----A1----A2----AB1----B1----B2----BC1----C1----C2----Egress
   ^  \                / | \              / | \                /
   |   \              /  |  \            /  |  \              /
   |    A3----------A4--AB2--B3--------B4--BC2--C3----------C4
   |                     ^                  ^
   |                     |                  |
   |                     |                  |
   |                     |              ERO: (C3-strict, C4-strict,
   |                     |                    Egress-strict)
   |                     |              XRO: Not needed
   |                     |
   |               ERO: (B3-strict, B4-strict, BC2-strict, Egress-loose)
   |               XRO: (BC1, C1, C2)
   |
   ERO: (A3-strict, A4-strict, AB2-strict, Egress-loose)
   XRO: (AB1, B1, B2, BC1, C1, C2)

Notes:

The figure incorrectly shows the longest XRO to include the Egress as well.

The text in the RFC is correct - "....so the ERO and XRO signaled at Ingress could be (A3-strict, A4-strict, AB2-strict, Egress-loose) and (AB1, B1, B2, BC1, C1, C2), respectively. "

The editorial error exist in the figure.

RFC 4875, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", May 2007

Note: This RFC has been updated by RFC 6510

Source of RFC: mpls (rtg)

Errata ID: 2483
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Verifier Name: Adrian Farrel
Date Verified: 2010-08-21

Section 6.1 says:

Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.

(3)  Section 6.1 -- bad internal reference, and missing article

Within Section 6.1, the first text lines on page 17 say:

|  The S2L sub-LSP flow descriptor has the same format as S2L sub-LSP
|  descriptor in section 4.1 with the difference that a
   P2MP_SECONDARY_RECORD_ROUTE object is used in place of a P2MP
   SECONDARY_EXPLICIT_ROUTE object.  [...]

The text should insert the missing article and correct the reference to point to Section 5.1

It should say:

|  The S2L sub-LSP flow descriptor has the same format as the S2L
|  sub-LSP descriptor in section 5.1 with the difference that a
   P2MP_SECONDARY_RECORD_ROUTE object is used in place of a P2MP
   SECONDARY_EXPLICIT_ROUTE object.  [...]

Errata ID: 2490
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Verifier Name: Adrian Farrel
Date Verified: 2010-08-21

Section 17 says:

Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.

(10)  Section 17 -- bad internal reference

Within Section 17, in the second paragraph on page 35, the reader
is referred to:
                 "Figure 2 in section 24"
which should be:
                 "Figure 2 in Appendix A"

RFC 4876, "A Configuration Profile Schema for Lightweight Directory Access Protocol (LDAP)-Based Agents", May 2007

Source of RFC: INDEPENDENT

Errata ID: 989
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-27
Verifier Name: Nevil Brownlee
Date Verified: 2010-04-15

Appendix A says:

Example 4:

|  serviceSearchDescriptor: email:ou=\\mar\\\\keting,\\"?base
   attributeMap: email:cn=name

|  base: ou=\\mar\\keting,"
   scope: base
   filter (&(objectclass=inetOrgPerson)(name~=Jane Hernandez))

It should say:

    serviceSearchDescriptor: email:ou=\\mar\\\\keting\",?base
    attributeMap: email:cn=name

    base: ou=\mar\\keting",o=airius.com
    scope: base
    filter (&(objectclass=inetOrgPerson)(name~=Jane Hernandez))

Notes:

Issues:

- unescaping of `\\mar` should give `\mar` , not `\\mar`
- to obtain `ing,"` , the escaped version should be `ing,\"'
(This presentation is biased to attribute one error each to the
two tagged lines - you might have intended another version.)

Discussed this with author, corrected version as above, with comment
"I have moved the quote to before the comma (since that is more of a
constructive example) and properly escaped it, as well as properly
processed the first escaped backslash."

Errata ID: 990
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-27
Verifier Name: Nevil Brownlee
Date Verified: 2010-04-07

Appendix A says:

Example 6:

   serviceSearchDescriptor: email:??(&(objectclass=person)
|                                   (ou=Org1 \\\\(temporary\\\\)))

   base: o=airius.com
   scope: sub
|  filter: (&((&(objectclass=person)(ou=Org1 \\(Temporary\\)))
             (cn~=Jane Henderson)))

It should say:

Example 6:

   serviceSearchDescriptor: email:??(&(objectclass=person)
|                                   (ou=Org1 \\\\(temporary\\\\)))

   base: o=airius.com
   scope: sub
|  filter: (&((&(objectclass=person)(ou=Org1 \\(temporary\\)))
             (cn~=Jane Henderson)))

Notes:

There's a spelling mismatch in capitalization:
'temporary' <--> 'Temporary'

from pending

Errata ID: 988
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-27
Verifier Name: RFC Editor
Date Verified: 2007-11-02

 

(1)  Section 3.1 -- word omission in DESC

On page 9, the RFC says:

   ( 1.3.6.1.4.1.11.1.3.1.1.15 NAME 'serviceAuthenticationMethod'
|    DESC 'Specifies types authentication methods either
     used, required, or supported by a particular service'
     EQUALITY caseIgnoreMatch
     SUBSTR caseIgnoreSubstringsMatch
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

It should say:

   ( 1.3.6.1.4.1.11.1.3.1.1.15 NAME 'serviceAuthenticationMethod'
|    DESC 'Specifies types of authentication methods either
     used, required, or supported by a particular service'
     EQUALITY caseIgnoreMatch
     SUBSTR caseIgnoreSubstringsMatch
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )


(2)  Section 4.6 -- typo/grammar

On page 19, just above the headline 'Example:', the RFC says:

|        The authors' belief that the user community is more familiar
         with the search filter syntax described by RFC 4515 than with
         that described by the enhancedSearchGuide syntax.

It should say either:

|        The authors' belief is that the user community is more familiar
         with the search filter syntax described by RFC 4515 than with
         that described by the enhancedSearchGuide syntax.

or, even simpler:

|        The authors believe that the user community is more familiar
         with the search filter syntax described by RFC 4515 than with
         that described by the enhancedSearchGuide syntax.


(3)  Section 4.13 -- missing articles

On page 26, the RFC says:

   Example:

      Suppose a DUA is acting on behalf of an email service.  By default
      the "email" service uses the "mail", "cn", and "sn" attributes to
|     discover mail addresses in entries created using inetOrgPerson
      object class [RFC2789].  However, the email service has been
|     deployed in an environment that uses entries created using
      "employee" object class.  [...]

It should perhaps better say:

      Suppose a DUA is acting on behalf of an email service.  By default
      the "email" service uses the "mail", "cn", and "sn" attributes to
|     discover mail addresses in entries created using the inetOrgPerson
      object class [RFC2789].  However, the email service has been
|     deployed in an environment that uses entries created using the
      "employee" object class.  [...]

It should say:

[see above]

Notes:

from pending

RFC 4877, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", April 2007

Source of RFC: mip6 (int)

Errata ID: 910
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-04-16
Verifier Name: RFC Editor
Date Verified: 2007-11-02

Section 3 says:

   The packet formats for tunneled mobile prefix discovery messages are
   very similar to the tunneled Binding Update and Binding
   Acknowledgment with the with the home address as the source address
   in the inner IP header.

It should say:

   The packet formats for tunneled mobile prefix discovery messages are
   very similar to the tunneled Binding Update and Binding
   Acknowledgment with the home address as the source address in the
   inner IP header.

Notes:

from pending

Errata ID: 911
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-04-16
Verifier Name: RFC Editor
Date Verified: 2007-11-02

Section 4.2 says:

   o  The home agent MUST use the Type 2 Routing header in Binding
      Acknowledgements and Mobile Prefix Advertisements sent to the
      mobile node when transport mode IPsec protection is used, again
      due to the need to have the home address visible when the policy
      checks are made.

It should say:

   o  The home agent MUST use the Type 2 Routing header in Binding
      Acknowledgements and Mobile Prefix Advertisements sent to the
      mobile node when transport mode IPsec protection is used, again
      due to the need to have the home address be visible when the
      policy checks are made.

Notes:

omission of verb

from pending

Errata ID: 912
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-04-16
Verifier Name: RFC Editor
Date Verified: 2007-11-02

Section 4.3 says:

          [...].  The use of sequence number in the ESP header to
      provide anti-replay protection is optional because the sequence
      numbers in the Binding Updates provide anti-replay protection.

It should say:

          [...].  The use of the sequence number in the ESP header to
      provide anti-replay protection is optional because the sequence
      numbers in the Binding Updates provide anti-replay protection.

Notes:

missing article

from pending

Errata ID: 913
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-04-16
Verifier Name: RFC Editor
Date Verified: 2007-11-02

Section 5 says:

                   [...].  This case uses IPsec tunnel mode SA with the
       protocol selector set to 'any'.

It should say:

                   [...].  This case uses IPsec tunnel mode SAs with
       the protocol selector set to 'any'.

Notes:

SA --> SAs

from pending

RFC 4880, "OpenPGP Message Format", November 2007

Note: This RFC has been updated by RFC 5581

Source of RFC: openpgp (sec)

Errata ID: 2270
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: David Shaw
Date Reported: 2010-05-18
Verifier Name: Sean Turner
Date Verified: 2010-07-20

Section 5.2.2 says:

       SHA224:     0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
                   0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x04, 0x05,
                   0x00, 0x04, 0x1C

It should say:

       SHA224:     0x30, 0x2d, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
                   0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x04, 0x05,
                   0x00, 0x04, 0x1C

Notes:

The second byte as published in 4880 is 0x31 but should be 0x2d.

Hal Finney noted this once, but I didn't see it entered in as an errata.

Errata ID: 2271
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: David Shaw
Date Reported: 2010-05-18
Verifier Name: Sean Turner
Date Verified: 2010-07-20

Section 6.5 says:

   Input data:  0x14FB9C03D97E
   Hex:     1   4    F   B    9   C     | 0   3    D   9    7   E
   8-bit:   00010100 11111011 10011100  | 00000011 11011001 11111110
   6-bit:   000101 001111 101110 011100 | 000000 111101 100111 111110
   Decimal: 5      15     46     28       0      61     37     62
   Output:  F      P      u      c        A      9      l      +

It should say:

   Input data:  0x14FB9C03D97E
   Hex:     1   4    F   B    9   C     | 0   3    D   9    7   E
   8-bit:   00010100 11111011 10011100  | 00000011 11011001 01111110
   6-bit:   000101 001111 101110 011100 | 000000 111101 100101 111110
   Decimal: 5      15     46     28       0      61     37     62
   Output:  F      P      u      c        A      9      l      +

Notes:

This example shows the conversion of 0x14FB9C03D97E into Radix-64. The problem is in the last byte, where '7E' is shown in binary as 11111110. That of course should be 01111110. The error is carried through in the 6-bit rendering of that data where the next-to-last 6-bit group 100111 should actually be 100101. The decimal rendering as well as the output (character) line is correct.

Errata ID: 3298
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Daniel Kahn Gillmor
Date Reported: 2012-07-27
Verifier Name: Stephen Farrell
Date Verified: 2013-03-16

Section 5.2.4 says:

Key revocation signatures (types 0x20 and 0x28) hash only the key being revoked.

It should say:

Primary key revocation signatures (type 0x20) hash only the key being revoked.
Subkey revocation signature (type 0x28) hash first the primary key and then the
subkey being revoked.

Notes:

This amendment to subkey revocation signatures is intended to align the spec with existing implementations. (it also makes the subkey revocation signatures more symmetric with the subkey binding signatures).

GnuPG (all known versions with subkey support) hashes both keys, as does PGP (tested at version 6.5.8). I'm unaware of any other OpenPGP implementation that actually complies with the spec as written for subkey revocations.

This was apparently noticed (but apparently ignored) back in 2000 (see point 2 of [0]) and was recently discussed again on the IETF list [1].

[0] http://www.mhonarc.org/archive/html/ietf-openpgp/2000-12/msg00001.html
[1] http://www.mhonarc.org/archive/html/ietf-openpgp/2012-07/msg00003.html

Errata ID: 2242
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Verifier Name: Sean Turner
Date Verified: 2010-07-20

Section 13.1.3. says:

   mL = intended length in octets of the encoded message, at least tLen
        + 11, where tLen is the octet length of the DER encoding T of a
        certain value computed during the encoding operation

It should say:

   emLen = intended length in octets of the encoded message, at least
        tLen + 11, where tLen is the octet length of the DER encoding T
        of a certain value computed during the encoding operation

Notes:

In the following text it is called emLen.

Changed to editorial.

RFC 4884, "Extended ICMP to Support Multi-Part Messages", April 2007

Note: This RFC has been updated by RFC 8335

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 3
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-06

Section 7 says:

The one's complement of the one's complement sum of the data
structure, with the checksum field replaced by zero for the
purpose of computing the checksum.

It should say:

The one's complement of the one's complement sum of the ICMP
Extension Structure, with the checksum field replaced by zero for
the purpose of computing the checksum.

RFC 4886, "Network Mobility Support Goals and Requirements", July 2007

Source of RFC: nemo (int)

Errata ID: 1040
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Verifier Name: Thierry Ernst
Date Verified: 2007-09-09

Section 4 says:

   R13: NEMO support signaling over the bi-directional must be
        minimized.

It should say:

  R13: NEMO support signaling over the bi-directional tunnel must be
       minimized.

Notes:

word omission

RFC 4890, "Recommendations for Filtering ICMPv6 Messages in Firewalls", May 2007

Source of RFC: v6ops (ops)

Errata ID: 2706
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Phil Whineray
Date Reported: 2011-02-06
Verifier Name: ron bonica
Date Verified: 2011-03-03

Section Appendix B. says:

   if [ "$STATE_ENABLED" -eq "1" ]
   then
     # Allow incoming time exceeded code 0 messages
     # only for existing sessions
     for inner_prefix in $INNER_PREFIXES
     do
       ip6tables -A icmpv6-filter -m state -p icmpv6 \
            -d $inner_prefix \
            --state ESTABLISHED,RELATED --icmpv6-type packet-too-big \
            -j ACCEPT
     done
   else
     # Allow incoming time exceeded code 0 messages
     for inner_prefix in $INNER_PREFIXES
     do
       ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
            --icmpv6-type ttl-zero-during-transit -j ACCEPT
     done
   fi

It should say:

   if [ "$STATE_ENABLED" -eq "1" ]
   then
     # Allow incoming time exceeded code 0 messages
     # only for existing sessions
     for inner_prefix in $INNER_PREFIXES
     do
       ip6tables -A icmpv6-filter -m state -p icmpv6 \
            -d $inner_prefix \
            --state ESTABLISHED,RELATED --icmpv6-type ttl-zero-during-transmit \
            -j ACCEPT
     done
   else
     # Allow incoming time exceeded code 0 messages
     for inner_prefix in $INNER_PREFIXES
     do
       ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
            --icmpv6-type ttl-zero-during-transit -j ACCEPT
     done
   fi

Notes:

Not sure if this is really editorial as it is in the example code, not the main RFC.

In any case, the example incorrectly specifies an icmpv6 type in one code path.

Errata ID: 3985
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: James Robertson
Date Reported: 2014-05-13
Verifier Name: Joel Jaeggli
Date Verified: 2014-05-19

Section Appendix B says:

if [ "$STATE_ENABLED" -eq "1" ]
then
  # Allow incoming time exceeded code 0 messages
  # only for existing sessions
  for inner_prefix in $INNER_PREFIXES
  do
    ip6tables -A icmpv6-filter -m state -p icmpv6 \
         -d $inner_prefix \
         --state ESTABLISHED,RELATED --icmpv6-type packet-too-big \
         -j ACCEPT
  done
else
  # Allow incoming time exceeded code 0 messages
  for inner_prefix in $INNER_PREFIXES
  do
    ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
         --icmpv6-type ttl-zero-during-transit -j ACCEPT
  done
fi

It should say:

if [ "$STATE_ENABLED" -eq "1" ]
then
  # Allow incoming time exceeded code 0 messages
  # only for existing sessions
  for inner_prefix in $INNER_PREFIXES
  do
    ip6tables -A icmpv6-filter -m state -p icmpv6 \
     -d $inner_prefix \
     --state ESTABLISHED,RELATED --icmpv6-type ttl-zero-during-transit \
     -j ACCEPT
  done
else
  # Allow incoming time exceeded code 0 messages
  for inner_prefix in $INNER_PREFIXES
  do
    ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
         --icmpv6-type ttl-zero-during-transit -j ACCEPT
  done
fi

Notes:

RFC 4890 Errata ID 2706 states that icmpv6-type packet-too-big should
state icmpv6-type ttl-zero-during-transmit. This should read
ttl-zero-during-transit.

RFC 4897, "Handling Normative References to Standards-Track Documents", June 2007

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: gen

Errata ID: 2793
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-05-01
Verifier Name: Russ Housley
Date Verified: 2011-12-06

Section 2 says:

   The term "Standards-Track document", as used in this specification,
   is assumed to include BCPs but not Informational or Experimental
   documents of any variety or origin.

It should say:

   The term "Standards-Track document", as used in this specification,
   is assumed to include Standards Track RFCs at any maturity level 
   and BCPs but not Informational, Experimental or Historic documents
   of any variety or origin.

Notes:

Rationale: Mentioning Historic documents as not included in the "Standards-Track document" definition; fuller description of this term.

RFC 4906, "Transport of Layer 2 Frames Over MPLS", June 2007

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rtg

Errata ID: 1034
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-08-17
Verifier Name: Stewart Bryant
Date Verified: 2011-01-17

Section 6 says:

               0x8008   CEM [CEM]

It should say:

               0x0008   CEM [CEM]

Notes:

This is a typo in the VC Type assignment list in this document.

The correct value (0x0008) is in the IANA MPLS Pseudowire Types Registry
and in the CEM specification (RFC5143)

RFC 4907, "Architectural Implications of Link Indications", June 2007

Source of RFC: IAB

Errata ID: 2
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stephane Bortzmeyer
Date Reported: 2007-06-25

Section 1.4.2 says:

   In order to address
   this problem, "Packetization Layer Path MTU Discovery" [RFC4821] does
   depend on the delivery of ICMP messages.

It should say:

   In order to address
   this problem, "Packetization Layer Path MTU Discovery" [RFC4821] does
   not depend on the delivery of ICMP messages.

RFC 4909, "Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST LTKM/STKM Transport", June 2007

Note: This RFC has been obsoleted by RFC 5410, RFC 6309

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 1033
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-08-17
Verifier Name: Russ Housley
Date Verified: 2010-03-11

Section 3 says:

                            1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      ! Next   !      Type     !            Length             !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      !       OMA BCAST S/LTKM Subtype  (variable length)      ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 1: OMA BCAST MIKEY General Extension

It should say:

                            1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      ! Next payload  !      Type     !            Length             !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      !       OMA BCAST S/LTKM Subtype  (variable length)             ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 1: OMA BCAST MIKEY General Extension

Notes:

After cross-checking with the basic MIKEY specification, RFC 3830,
Section 6.15, I conclude that most probably the figure should be as above.

RFC 4918, "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", June 2007

Note: This RFC has been updated by RFC 5689

Source of RFC: webdav (app)

Errata ID: 1068
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2007-11-13
Verifier Name: Lisa Dusseault
Date Verified: 2007-11-13

Section 10.4.7 says:

     If: (Not <urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>
     <urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092>) 

It should say:

     If: (Not <urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>
          <urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092>) 

Notes:

Indentation is relevant here. In the published form, the second line would be a separate (invalid) HTTP header, not a continuation line.

Errata ID: 1519
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Manfred Baedke
Date Reported: 2008-09-19
Verifier Name: Peter Saint-Andre
Date Verified: 2011-06-08

Section 8.3 says:

Within Simple-ref productions, senders MUST NOT:

   o  use dot-segments ("." or ".."), or

   o  have prefixes that do not match the Request-URI (using the
      comparison rules defined in Section 3.2.3 of [RFC2616]).

It should say:

Within Simple-ref productions, senders MUST NOT use dot-segments ("." or "..").
Simple-ref productions used in Multi-Status responses MUST NOT have prefixes that
do not match the Request-URI (using the comparison rules defined in Section 3.2.3
of [RFC2616]).

Notes:

The original text explicitly applies not only to Simple-ref productions used in Multi-Status responses, but also to those used in Destination Headers. Since URIs used in Destination headers may have other prefixes (for example in a cross-server COPY request), this is wrong.

Errata ID: 1430
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Werner Baumann
Date Reported: 2008-05-26
Verifier Name: Lisa Dusseault
Date Verified: 2008-05-30

Section 9.3 says:

9.3.  MKCOL Method

   MKCOL creates a new collection resource at the location specified by
   the Request-URI. [...]

It should say:

9.3 MKCOL Method

   The MKCOL method is used to create a new collection. All DAV compliant
   resources MUST support the MKCOL method.

   MKCOL creates a new collection resource at the location specified by
   the Request-URI. [...]

Notes:

The statement, that support for MKCOL is a MUST-requirement has unintentionally been dropped.

RFC 4919, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", August 2007

Source of RFC: 6lowpan (int)

Errata ID: 1789
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jeffrey Wildman
Date Reported: 2009-06-01
Verifier Name: Ralph Droms
Date Verified: 2013-03-10

Section 5. Goals says:

   1.  Fragmentation and Reassembly layer: As mentioned in the overview,
       the protocol data units may be as small as 81 bytes.  This is
       obviously far below the minimum IPv6 packet size of 1280 octets,
       and in keeping with Section 5 of the IPv6 specification
       [RFC2460], a fragmentation and reassembly adaptation layer must
       be provided at the layer below IP.

It should say:

   1.  Fragmentation and Reassembly layer: As mentioned in the overview,
       the payload of medium access layer frames may be capped in size (as small 
       as 81 bytes).  This is obviously far below the minimum IPv6 Maximum 
       Transmission Unit (MTU) size of 1280 octets, and in keeping with Section 5 
       of the IPv6 specification [RFC2460], a fragmentation and reassembly 
       adaptation layer must be provided at the layer below IP.

Notes:

Changed 'protocol data units' to 'medium access layer frames' for clarity.

Changed 'may be as small as 81 bytes' to 'may be capped in size (as small as 81 bytes)'. We are highlighting the fact that link layer payloads can't exceed some size X, while we are also expecting IPv6 packets much larger than X bytes to be pushed down to the link layer. (Hence the requirement for fragmentation and reassembly mechanisms at the link layer.)

'minimum IPv6 packet size of 1280 octets' changed to 'minimum IPv6 MTU size of 1280 octets'. In the IPv6 specification [RFC 2460], Section 5 'Packet Size Issues' says that the minimum allowable IPv6 MTU is 1280 octets. This is not equivalent to saying that the minimum IPv6 packet size is 1280 bytes (as suggested in the original text in RFC 4919).

RFC 4920, "Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE", July 2007

Source of RFC: ccamp (rtg)

Errata ID: 4480
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Dhruv Dhody
Date Reported: 2015-09-20
Verifier Name: Deborah Brungard
Date Verified: 2015-11-18

Section 6.2 says:

For types 10 and 23, the Value field has the format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Length      |     IS-IS Area Identifier                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                     IS-IS Area Identifier (continued)         ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Length

          Length of the actual (non-padded) IS-IS Area Identifier in
          octets.  Valid values are from 2 to 11 inclusive.

It should say:

For types 10 and 23, the Value field has the format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Length      |     IS-IS Area Identifier                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                     IS-IS Area Identifier (continued)         ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Length

          Length of the actual (non-padded) IS-IS Area Identifier in
          octets.  Valid values are from 1 to 13 inclusive.

Notes:

IS-IS area IDs can vary from 1 to 13 bytes in length (max NSAP length is 20, minus 1 byte for NSEL, minus 6 bytes for SysID).

*Noted by Jonathan Hardwick in another document that was using the same data.

Errata ID: 1460
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lou Berger
Date Reported: 2008-06-27
Verifier Name: Adrian Farrel
Date Verified: 2010-01-02

Section 7,1 and 7.2 says:

Section 7.1:

"Path_State_Remove_Flag"

Section 7.2:
"Path_State_Remove Flag"

It should say:

Both sections:
"Path_State_Removed flag ([RFC3473])"

RFC 4938, "PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics", June 2007

Note: This RFC has been obsoleted by RFC 5578

Source of RFC: INDEPENDENT

Errata ID: 1027
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-08-20
Verifier Name: Nevil Brownlee
Date Verified: 2010-04-07

Section 4.5 says:

|  The PADQ must carry a single Metric Tag TYPE, which contains the
   following fields:

It should say:

|  The PADQ must carry a single Metric Tag TLV, which contains the
   following fields:

Notes:

clarification

Errata ID: 1028
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-08-20
Verifier Name: Nevil Brownlee
Date Verified: 2010-04-07

Section 6 says:

   In-band credit management allows credits to be incrementally granted
   with each PPP Session Stage packet.  These in-band incremental credit
|  grants are not explicitly unacknowledged.  However, they are
   reflected in the in-band credit flow from the peer node.

It should say:

   In-band credit management allows credits to be incrementally granted
   with each PPP Session Stage packet.  These in-band incremental credit
|  grants are not explicitly acknowledged.  However, they are reflected
   in the in-band credit flow from the peer node.

Notes:

I strongly suspect that in the second sentence,
"not explicitly unacknowledged"
is an erroneous double negation and should be
"not explicitly acknowledged" .

Errata ID: 1029
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-08-20
Verifier Name: Nevil Brownlee
Date Verified: 2010-04-07

Section 6 says:

   Packets received when granted credits that have been exhausted
   are discarded.

It should say:

   When granted credits have been exhausted, any further packets
   received are discarded.

Notes:

That sentence does not parse. Perhaps, the word 'that' should be
deleted.

Yes - I've supplied a sentence that makes it clearer.

RFC 4939, "Definitions of Managed Objects for iSNS (Internet Storage Name Service)", July 2007

Source of RFC: ips (tsv)

Errata ID: 1026
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-14
Verifier Name: Lars Eggert
Date Verified: 2008-12-19

 

(2)  Section 5 (MIB Module)

(2a,b)  isnsNumPortals and isnsNumPortalGroups  (page 26)

The DESCRIPTION clauses of the isnsNumPortals and isnsNumPortalGroups
OBJECT-TYPE declarations deviate from the wording for used the
related 'sibling' MIB objects making the text a bit too unspecific.
The replacement text proposed below is aligned with the text pattern
used throughout the upper part of page 26.

(2a)
For isnsNumPortals, the RFC says:

          DESCRIPTION
|     "The current total number of Portals registered in iSNS.
       This is the number of rows in isnsRegPortalTable."

It should perhaps better say:
                                                         vvvvv
          DESCRIPTION
|     "The current total number of Portals registered in this iSNS
|      instance.  This is the number of rows in isnsRegPortalTable."
       ^^^^^^^^
(2b)
For isnsNumPortalGroups, the RFC says:

          DESCRIPTION
|     "The current total number of Portal Groups registered in
|      iSNS.  This is the number of rows in isnsRegPgTable."

It should perhaps better say:
                                                              vvvvv
          DESCRIPTION
|     "The current total number of Portal Groups registered in this
|      iSNS instance.  This is the number of rows in isnsRegPgTable."
           ^^^^^^^^^

(2d)  isnsDdIscsiMemberName  (page 36)

The DESCRIPTION clause of the isnsDdIscsiMemberName OBJECT-TYPE
declaration says:

       [...]
       The node index used for a specific node name is only
       persistent across iSNS Server reinitializations for nodes
       that are in a Discovery Domain (DD) or are registered
|      control nodes.  This value is only required during row
|      creation if the storage node is not yet registered in the
|      iSNS Server instance.  If the storage node is not yet
|      registered, then the iSCSI Name MUST be provided with the
|      iSCSI node index during row creation in order to create the
|      1-to-1 mapping."

The tagged text makes almost no sense here, and should better have
been omitted, because row creation (and deletion) via SNMP in the
isnsDdIscsiMemberTable is not supported by (this version of) the
MIB module.

Hence, The RFC should better simply say:
       [...]
       The node index used for a specific node name is only
       persistent across iSNS Server reinitializations for nodes
       that are in a Discovery Domain (DD) or are registered
|      control nodes."


(2e)  isnsDdPortalMemberEntry  (page 37)

The DESCRIPTION clause of the isnsDdPortalMemberEntry OBJECT-TYPE
declaration says:

      "Each entry indicates an explicit addition of a portal to a
       discovery domain.  The explicit addition of an entity portal
       to a discovery domain indicates the portal is preferred for
       access to nodes of the entity for this discovery domain.
       Registered Portal Group objects are used in iSCSI to
|      indicate mapping of portals to nodes across all discovery
       domains.  Portals that have been explicitly mapped to a
|      discovery domain will be returned as part of a query that
       is scoped to that discovery domain.  If no portal of an
       entity has been explicitly mapped to a discovery domain,
       then all portals of the entity that provide access to a
       storage node are returned as part of a query.  The table
       indexes are the server instance, the DD ID of the Discovery
       Domain, and the Portal Index of the portal."

In the coupled context od SNMP and iSNS, the bare term 'query' is
ambiguous and its use might lead to some confusion.
Closely reading all other text in the document related to the
DD Portal Membership table, isnsDdPortalMemberTable, has indicated
to me that it makes only sense to talk about iSNS queries in the
context of the second tag mark above.
Further, IMHO an article is missing in the first tagged line above.

Altogether, the RFC should better say:

      "Each entry indicates an explicit addition of a portal to a
       discovery domain.  The explicit addition of an entity portal
       to a discovery domain indicates the portal is preferred for
       access to nodes of the entity for this discovery domain.
       Registered Portal Group objects are used in iSCSI to
|      indicate the mapping of portals to nodes across all discovery
       domains.  Portals that have been explicitly mapped to a
|      discovery domain will be returned as part of an iSNS query
       that is scoped to that discovery domain.  If no portal of an
       entity has been explicitly mapped to a discovery domain,
       then all portals of the entity that provide access to a
       storage node are returned as part of a query.  The table
       indexes are the server instance, the DD ID of the Discovery
       Domain, and the Portal Index of the portal."


(2i)  isnsServerNotificationGroup  (page 75)

At the very end of the MIB module, the isnsServerNotificationGroup
NOTIFICATION-GROUP declaration says:

      isnsServerNotificationGroup  NOTIFICATION-GROUP
          NOTIFICATIONS {
             isnsServerStart,
             isnsServerShutdown
                        }
          STATUS                  current
          DESCRIPTION
|     "iSNS Server Notification managed objects."
             ::= { isnsGroups 10 }

That DESCRIPTION clause IMHO is misleading and could easily be
confused with the DESCRIPTION clause of the isnsNotificationsObjGroup
OBJECT-GROUP declaration saying:
      "iSNS Notification managed objects."

Perhaps, the phrase used for the isnsServerNotificationGroup (marked
above) should better be:

|     "iSNS Server Notifications."

Notes:

confusion-reducing clarifications to Description clauses

RFC 4941, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", September 2007

Note: This RFC has been obsoleted by RFC 8981

Source of RFC: ipv6 (int)

Errata ID: 3240
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-10-12
Verifier Name: Brian Haberman
Date Verified: 2012-06-01

Section 3.3 says:

   4.  When creating a temporary address, the lifetime values MUST be
       derived from the corresponding prefix as follows:

       *  Its Valid Lifetime is the lower of the Valid Lifetime of the
          public address or TEMP_VALID_LIFETIME.

       *  Its Preferred Lifetime is the lower of the Preferred Lifetime
          of the public address or TEMP_PREFERRED_LIFETIME -
          DESYNC_FACTOR.

It should say:

   4.  When creating a temporary address, the lifetime values MUST be
       derived from the corresponding prefix as follows:

       *  Its Valid Lifetime is the lower of the Valid Lifetime of the
          prefix and TEMP_VALID_LIFETIME.

       *  Its Preferred Lifetime is the lower of the Preferred Lifetime
          of the prefix and TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR.

Notes:

The language of RFC 4941 has been 'upgraded' from RFC 3041 by
replacing the confusing language related to "global addresses"
by correctly speaking about "prefixes" when referring to
information obtained in RA Prefix Options.
Unfortunately, in one place this 'upgrade' has been missed.

Errata ID: 4763
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jiri Bohac
Date Reported: 2016-08-04
Verifier Name: Erik Kline
Date Verified: 2021-01-28

Section 5 says:

DESYNC_FACTOR -- A random value within the range 0 -
   MAX_DESYNC_FACTOR.  It is computed once at system start (rather than
   each time it is used) and must never be greater than
   (TEMP_VALID_LIFETIME - REGEN_ADVANCE).

It should say:

DESYNC_FACTOR -- A random value within the range 0 -
   MAX_DESYNC_FACTOR.  It is computed once at system start (rather than
   each time it is used) and must never be greater than
   (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE).

Notes:

At various places in the RFC, DESYNC_FACTOR is used in a calculation like (TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR) or (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE - DESYNC_FACTOR). It needs to be smaller than (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE) for the result of these calculations to be larger than zero. It's never used in a calculation together with TEMP_VALID_LIFETIME.

Errata ID: 998
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-10-12
Verifier Name: Brian Haberman
Date Verified: 2012-06-01

Section 6 says:

The second paragraph of Section 6 refers to the Source Address
Selection API Extension without giving any reference.  The related
Internet-Draft in the meantime has been published as RFC 5014,
less than two weeks after RFC 4941.
It would have been useful to place a pointer to that work-in-progress
(or the RFC, if publication were coordinated).

Errata ID: 3241
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-10-12
Verifier Name: Brian Haberman
Date Verified: 2012-06-01

Section 3.4 says:

   When a temporary address becomes deprecated, a new one MUST be
   generated.  This is done by repeating the actions described in
   Section 3.3, starting at step 3).  [...]

It should say:

   When a temporary address becomes deprecated, a new one MUST be
   generated.  This is done by repeating the actions described in
   Section 3.3, starting at step 4).  [...]

Notes:

The bullets in Section 3.3 have been renumbered from RFC 3041,
necessitated by the insertion of a new bullet as #2.
In an internal reference in Section 3.4, this change has not been
reflected accordingly.

RFC 4944, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", September 2007

Note: This RFC has been updated by RFC 6282, RFC 6775, RFC 8025, RFC 8066, RFC 8931

Source of RFC: 6lowpan (int)

Errata ID: 4359
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Gabriel Montenegro
Date Reported: 2015-05-07
Verifier Name: Brian Haberman
Date Verified: 2015-09-14

Section 5.1 says:

   ESC:  Specifies that the following header is a single 8-bit field for
      the Dispatch value.  It allows support for Dispatch values larger
      than 127.

It should say:

   ESC:  Specifies that the following header is a single 8-bit field for
      the Dispatch value.  It allows support for Dispatch values larger
      than 63.

Notes:

The (non-ESCaped) Dispatch value is a 6-bit selector. However, it used to be a 7-bit selector, which has a value at most 127. When the field became a 6-bit selector, this maximum became 63, but the referring text was never updated.

For historical reference, see an early version from IETF 67 proposing the Dispatch value within the Dispatch header as a 7-bit field:

http://6lowpan.tzi.org/FrontPage?action=AttachFile&do=view&target=tentative-draft2-ietf-6lowpan-format-07.txt

The dispatch type is defined by a zero-bit as the first bit. The
dispatch type and header is shown here:

1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Dispatch | type-specific header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Dispatch 7-bit selector. Identifies the type of header
immediately following the Dispatch type.

The relevant slides also show this (slide 8): http://6lowpan.tzi.org/FrontPage?action=AttachFile&do=view&target=6lowpan-header-proposal-2.ppt

RFC 4948, "Report from the IAB workshop on Unwanted Traffic March 9-10, 2006", August 2007

Source of RFC: IAB

Errata ID: 1024
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stephane Bortzmeyer
Date Reported: 2007-09-15
Verifier Name: Olaf Kolkman
Date Verified: 2008-11-16

Section 4.3.2 says:

for example, a bug in the BIND packet was discovered

It should say:

for example, a bug in the BIND package was discovered

Notes:

from pending

RFC 4954, "SMTP Service Extension for Authentication", July 2007

Note: This RFC has been updated by RFC 5248

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 1
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rob Siemborski
Date Reported: 2007-07-19

Section 4.1 says:

   S: 220-smtp.example.com ESMTP Server

It should say:

   S: 220 smtp.example.com ESMTP Server

Notes:

There are 3 instances of this (one on p. 7 and two on p. 8).

Errata ID: 1021
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-08-25
Verifier Name: Alexey Melnikov
Date Verified: 2007-08-25

Section 5 says:

  Note:
       For the purposes of this discussion, "authenticated identity"
       refers to the identity (if any) derived from the authorization
|      identity of previous AUTH command, while the terms "authorized
       identity" and "supplied <mailbox>" refer to the sender identity
       that is being associated with a particular message.

It should say:

  Note:
       For the purposes of this discussion, "authenticated identity"
       refers to the identity (if any) derived from the authorization
|      identity of the previous AUTH command, while the terms
       "authorized identity" and "supplied <mailbox>" refer to the
       sender identity that is being associated with a particular
       message.  

Notes:

missing article

from pending

Errata ID: 1022
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-08-25
Verifier Name: Alexey Melnikov
Date Verified: 2007-08-25

Section 9 says:

   Additional security considerations for [PLAIN] over
|  [TLS] are mentioned in Section 15 of this document.

It should say:

   Additional security considerations for [PLAIN] over
|  [TLS] are mentioned in Section 14 of this document.

Notes:

wrong document-internal reference

from pending

Errata ID: 4015
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jeffrey 'jf' Lim
Date Reported: 2014-06-15
Verifier Name: Barry Leiba
Date Verified: 2014-07-01

Section 4 says:

See also Section 15 for additional requirements on
implementations of [PLAIN] over [TLS].

It should say:

See also Section 14 for additional requirements on
implementations of [PLAIN] over [TLS].

Notes:

----- Verifier Notes -----
This happened when the RFC Editor moved the authors' addresses out of numbered section 13, and caused the subsequent sections to be renumbered. We missed the internal reference.

Errata ID: 5224
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bastian Schumacher
Date Reported: 2018-01-02
Verifier Name: Orie Steele
Date Verified: 2024-04-01

Section 4 says:

If the initial
response argument is omitted and the chosen mechanism requires
an initial client response, the server MUST proceed as defined
in Section 5.1 of [SASL]. 

[...]

If use of the initial response
argument would cause the AUTH command to exceed this length,
the client MUST NOT use the initial response parameter (and
instead proceed as defined in Section 5.1 of [SASL]).

It should say:

If the initial
response argument is omitted and the chosen mechanism requires
an initial client response, the server MUST proceed as defined
in Section 5.1 of [RFC 2222]. 

[...]

If use of the initial response
argument would cause the AUTH command to exceed this length,
the client MUST NOT use the initial response parameter (and
instead proceed as defined in Section 5.1 of [RFC 2222]).

Notes:

[SASL] points to RFC 4422 that does not contain a Section 5.1.
So the Original text leads to confusion. The referenced Text can be found in RFC 2222 instead.

RFC 4956, "DNS Security (DNSSEC) Opt-In", July 2007

Source of RFC: dnsext (int)

Errata ID: 1018
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-08-16
Verifier Name: Brian Haberman
Date Verified: 2012-05-01

 

(1)  typo (technical error)

Within Section 4.2.2.2. of RFC 4956, the last sentence of the
paragraph on top of page 8 contains a wrong RCODE value.
The RFC says:

                v
                                 [...].  In particular, a NOERROR/NODATA
|  (i.e., RCODE=3, but the answer section is empty) response to a DS
   query may be proven by an Opt-In flagged covering NSEC record, rather
   than an NSEC record matching the query name.

It should say:
                v
                                 [...].  In particular, a NOERROR/NODATA
|  (i.e., RCODE=0, but the answer section is empty) response to a DS
   query may be proven by an Opt-In flagged covering NSEC record, rather
   than an NSEC record matching the query name.

Rationale: See RCODE list in RFC 1035 [1], page 27, and RFC 2181 [8].


(2)  missing article

Still on page 8, an article is missing in the third bullet
in Section 4.2.4 .
The RFC says:

   o  sending a NOERROR/NODATA response when query type is DS and the
|     covering NSEC is tagged as Opt-In, unless NSEC record's owner name
      matches the query name.
                                               ^
It should say:

   o  sending a NOERROR/NODATA response when query type is DS and the
|     covering NSEC is tagged as Opt-In, unless the NSEC record's owner
      name matches the query name.
                                               ^^^^^

(3)  inconsistency

There's a small inconsistency in the presentation of DNS querys
(and responses) in Section 6.
In almost all instances, in that context the text gives domain
names with the DNS 'root label', the trailing dot.
Yet, in the second line of the first paragraph on page 10,
this dot is missing twice.

The RFC says:

   In this example, a query for a signed RRset (e.g., "FIRST-
|  SECURE.EXAMPLE A") or a secure delegation ("WWW.SECOND-SECURE.EXAMPLE
   A") will result in a standard DNSSEC response.

It should say:

   In this example, a query for a signed RRset (e.g., "FIRST-
|  SECURE.EXAMPLE. A") or a secure delegation ("WWW.SECOND-
|  SECURE.EXAMPLE. A") will result in a standard DNSSEC response.
                 ^

(4)  text truncation

In Section 9, on top of page 13, the list of acknowledged people
apparently has been truncated.

The RFC says:
          v
|     Mats Kolkman, Edward Lewis, Ted Lindgreen, Rip Loomis, Bill
      Manning, Dan Massey, Scott Rose, Mike Schiraldi, Jakob Schlyter,
      Brian Wellington.

The -09 draft had the following list:

|     Mats Dufberg, Miek Gieben, Olafur Gudmudsson, Bob Halley, Olaf
      Kolkman, Edward Lewis, Ted Lindgreen, Rip Loomis, Bill Manning,
      Dan Massey, Scott Rose, Mike Schiraldi, Jakob Schlyter, Brian
      Wellington.

AFAICS, most probably the draft was o.k. and the bulk of the first
line of that list has been lost in the publication process.


(5)  references

RFC 3655 [3] and RFC 3090 [10] have been incorporated into, and
formally been obsoleted by RFC 4033..35 [4][5][6].

IMHO, it is therefore inappropriate to list [3] as a Normative
Reference in Section 10.1, and it it of questionable benefit
to list both [3] and [10] at all in Section 10.


I apologize for not having caught and reported items (1)..(3) and
(5) when I once studied the -09 draft version of the document;
item (4) is new.

I strongly recommend to post an RFC Errata Note covering at least
items (1) and (4).

RFC 4958, "A Framework for Supporting Emergency Telecommunications Services (ETS) within a Single Administrative Domain", July 2007

Source of RFC: ieprep (rai)

Errata ID: 1016
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-08-20
Verifier Name: Ken Carlberg
Date Verified: 2007-08-20

Section 4.4.1 says:

a Media Access Controller (MAC) frame

It should say:

a Media Access Control (MAC) frame

Errata ID: 1017
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-08-20
Verifier Name: Ken Carlberg
Date Verified: 2007-08-20

Section 4.2.1 says:

mostly likely

It should say:

most likely

RFC 4959, "IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response", September 2007

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 4052
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Slusarz
Date Reported: 2014-07-16
Verifier Name: Barry Leiba
Date Verified: 2014-07-16

Section 3 says:

This extension adds an optional second argument to the AUTHENTICATE
command that is defined in Section 6.2.2 of [RFC3501].  If this
second argument is present, it represents the contents of the
"initial client response" defined in Section 5.1 of [RFC4422].

It should say:

This extension adds an optional second argument to the AUTHENTICATE
command that is defined in Section 6.2.2 of [RFC3501].  If this
second argument is present, it represents the contents of the
"initial client response" defined in Section 5 of [RFC4422].

Notes:

There is no Section 5.1 in RFC 4422 - Section 5 is a single section.

RFC 4960, "Stream Control Transmission Protocol", September 2007

Note: This RFC has been obsoleted by RFC 9260

Note: This RFC has been updated by RFC 6096, RFC 6335, RFC 7053, RFC 8899

Source of RFC: tsvwg (wit)

Errata ID: 3788
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Karen Nielsen
Date Reported: 2013-11-06
Verifier Name: Martin Stiemerling
Date Verified: 2014-01-13

Section 8.1 says:

   An endpoint shall keep a counter on the total number of consecutive
   retransmissions to its peer (this includes retransmissions to all the
   destination transport addresses of the peer if it is multi-homed),
   including unacknowledged HEARTBEAT chunks.  

It should say:

An endpoint shall keep a counter on the total number of consecutive
retransmissions to its peer (this includes data retransmissions 
to all the destination transport addresses of the peer if it is 
multi-homed),including the number of unacknowledged HEARTBEAT 
chunks observed on the path which currently is used for data 
transfer. Unacknowledged HEARTBEAT chunks observed on paths 
different from the path currently used for data transfer shall 
not increment the association error counter, as this could lead 
to association closure even if the path which 
currently is used for data transfer is available (but idle). 

Notes:

RFC4960 Endpoint Failure detection mechanism is deficient in that
HB failures on some failing paths may take the association down, even
if other paths are working perfectly, but simply at the time no data
or HBs are being sent on the working paths.

The situation occurs when the association is idle
(no data is being transmitted) and the HBI settings on
the failing paths are much more aggressive than the HBI
set on the working paths. RFC6458 allows for specification
of the HBI on a per destination address whereby
such in-homogeneous setting of the HBI can occur.

The solution proposed to the issue is to demand that
HB failures observed on paths different from the path
currently used for data transfer do
not contribute to the association error counter.
HB failures observed on the path currently used for
data transfer, when this path is idle,
shall contribute to the association error counter.
Thereby supporting Endpoint Failure detection when the
association is idle. When the association is transmitting data,
the fate of the data transmissions and retransmissions
will serve to instantiate Endpoint Failure detection.

Errata ID: 1440
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Tüxen
Date Reported: 2008-06-12
Verifier Name: Lars Eggert
Date Verified: 2008-07-16

Section 8.3 says:

   When the value of this counter reaches the protocol parameter
   'Path.Max.Retrans', the endpoint should mark the corresponding
   destination address as inactive if it is not so marked, and may also
   optionally report to the upper layer the change of reachability of
   this destination address.  After this, the endpoint should continue
   HEARTBEAT on this destination address but should stop increasing the
   counter.

It should say:

   When the value of this counter exceeds the protocol parameter
   'Path.Max.Retrans', the endpoint should mark the corresponding
   destination address as inactive if it is not so marked, and may also
   optionally report to the upper layer the change of reachability of
   this destination address.  After this, the endpoint should continue
   HEARTBEAT on this destination address but should stop increasing the
   counter.

Notes:

The path should be considered inactive, when the error counter exceeds
the threshold. This is stated correctly in 8.2.

Errata ID: 3423
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Pontus Andersson
Date Reported: 2012-12-01
Verifier Name: Martin Stiemerling
Date Verified: 2013-03-06

Section B says:

   unsigned long
   generate_crc32c(unsigned char *buffer, unsigned int length)
   {
     unsigned int i;
     unsigned long crc32 = ~0L;

It should say:

   unsigned long
   generate_crc32c(unsigned char *buffer, unsigned int length)
   {
     unsigned int i;
     unsigned long crc32 = 0xffffffffL;

Notes:

The remainder register (crc32) should be initialized to 0xffffffffL rather than ~0L, for correct operation on platforms where unisigned long is longer than 32 bits. I.e., 64-bit platforms.

Errata ID: 4400
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Pourtet
Date Reported: 2015-06-25
Verifier Name: Martin Stiemerling
Date Verified: 2015-07-16

Section 5.1.6. says:

                                    /-- INIT ACK [Veri Tag=Tag_A,
                                   /             I-Tag=Tag_Z,
    (Cancel T1-init timer) <------/              Cookie_Z, & other info]
                                         (destroy temp TCB)
    COOKIE ECHO [Cookie_Z] ------\
    (Start T1-init timer)         \
    (Enter COOKIE-ECHOED state)    \---> (build TCB enter ESTABLISHED
                                          state)
                                   /---- COOKIE-ACK
                                  /
    (Cancel T1-init timer, <-----/

It should say:

                                    /-- INIT ACK [Veri Tag=Tag_A,
                                   /             I-Tag=Tag_Z,
    (Cancel T1-init timer) <------/              Cookie_Z, & other info]
                                         (destroy temp TCB)
    COOKIE ECHO [Cookie_Z] ------\
    (Start T1-cookie timer)       \
    (Enter COOKIE-ECHOED state)    \---> (build TCB enter ESTABLISHED
                                          state)
                                   /---- COOKIE-ACK
                                  /
    (Cancel T1-cookie timer, <---/

Notes:

Upon reception of an INIT ACK Endpoint A should start the T1-cookie timer, not the T1-init timer. Reception of a COOKIE-ACK cancels The T1-cookie timer, not the T1-init timer.

Errata ID: 4656
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Lionel Morand
Date Reported: 2016-04-06
Verifier Name: Spencer Dawkins
Date Verified: 2018-07-10

Throughout the document, when it says:

6.2.  Acknowledgement on Reception of DATA Chunks

   The SCTP endpoint MUST always acknowledge the reception of each valid
   DATA chunk when the DATA chunk received is inside its receive window.

   When the receiver's advertised window is 0, the receiver MUST drop
   any new incoming DATA chunk with a TSN larger than the largest TSN
   received so far.  If the new incoming DATA chunk holds a TSN value
   less than the largest TSN received so far, then the receiver SHOULD
   drop the largest TSN held for reordering and accept the new incoming
   DATA chunk.  In either case, if such a DATA chunk is dropped, the
   receiver MUST immediately send back a SACK with the current receive
   window showing only DATA chunks received and accepted so far.  The
   dropped DATA chunk(s) MUST NOT be included in the SACK, as they were
   not accepted.  The receiver MUST also have an algorithm for
   advertising its receive window to avoid receiver silly window
   syndrome (SWS), as described in [RFC0813].  The algorithm can be
   similar to the one described in Section 4.2.3.3 of [RFC1122].

   The guidelines on delayed acknowledgement algorithm specified in
   Section 4.2 of [RFC2581] SHOULD be followed.  Specifically, an
   acknowledgement SHOULD be generated for at least every second packet
   (not every second DATA chunk) received, and SHOULD be generated
   within 200 ms of the arrival of any unacknowledged DATA chunk.  In
   some situations, it may be beneficial for an SCTP transmitter to be
   more conservative than the algorithms detailed in this document
   allow.  However, an SCTP transmitter MUST NOT be more aggressive than
   the following algorithms allow.

   An SCTP receiver MUST NOT generate more than one SACK for every
   incoming packet, other than to update the offered window as the
   receiving application consumes new data.

   IMPLEMENTATION NOTE: The maximum delay for generating an
   acknowledgement may be configured by the SCTP administrator, either
   statically or dynamically, in order to meet the specific timing
   requirement of the protocol being carried.

   An implementation MUST NOT allow the maximum delay to be configured
   to be more than 500 ms.  In other words, an implementation MAY lower
   this value below 500 ms but MUST NOT raise it above 500 ms.

[ remaining of the section unchanged ]

***********************************************************************
15.  Suggested SCTP Protocol Parameter Values

   The following protocol parameters are RECOMMENDED:

      RTO.Initial - 3 seconds
      RTO.Min - 1 second
      RTO.Max - 60 seconds
      Max.Burst - 4
      RTO.Alpha - 1/8
      RTO.Beta - 1/4
      Valid.Cookie.Life - 60 seconds
      Association.Max.Retrans - 10 attempts
      Path.Max.Retrans - 5 attempts (per destination address)
      Max.Init.Retransmits - 8 attempts
      HB.interval - 30 seconds
      HB.Max.Burst - 1

   IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to
   customize some of these protocol parameters (see Section 10).

   Note: RTO.Min SHOULD be set as recommended above.

It should say:

6.2.  Acknowledgement on Reception of DATA Chunks

   The SCTP endpoint MUST always acknowledge the reception of each valid
   DATA chunk when the DATA chunk received is inside its receive window.

   When the receiver's advertised window is 0, the receiver MUST drop
   any new incoming DATA chunk with a TSN larger than the largest TSN
   received so far.  If the new incoming DATA chunk holds a TSN value
   less than the largest TSN received so far, then the receiver SHOULD
   drop the largest TSN held for reordering and accept the new incoming
   DATA chunk.  In either case, if such a DATA chunk is dropped, the
   receiver MUST immediately send back a SACK with the current receive
   window showing only DATA chunks received and accepted so far.  The
   dropped DATA chunk(s) MUST NOT be included in the SACK, as they were
   not accepted.  The receiver MUST also have an algorithm for
   advertising its receive window to avoid receiver silly window
   syndrome (SWS), as described in [RFC0813].  The algorithm can be
   similar to the one described in Section 4.2.3.3 of [RFC1122].

   The guidelines on delayed acknowledgement algorithm specified in
   Section 4.2 of [RFC2581] SHOULD be followed.  Specifically, an
   acknowledgement SHOULD be generated for at least every second packet
   (not every second DATA chunk) received, and SHOULD be generated
   within 200 ms of the arrival of any unacknowledged DATA chunk.  In
   some situations, it may be beneficial for an SCTP transmitter to be
   more conservative than the algorithms detailed in this document
   allow.  However, an SCTP transmitter MUST NOT be more aggressive than
   the following algorithms allow.

   An SCTP receiver MUST NOT generate more than one SACK for every
   incoming packet, other than to update the offered window as the
   receiving application consumes new data.

   IMPLEMENTATION NOTE: The maximum delay for generating an
   acknowledgement may be configured by the SCTP administrator, either
   statically or dynamically, in order to meet the specific timing
   requirement of the protocol being carried.

   An implementation MUST NOT allow the maximum delay (protocol 
   parameter 'SACK.Delay') to be configured to be more than 500 ms.
   In other words, an implementation MAY lower the value of 
   'SACK.Delay' below 500 ms but MUST NOT raise it above 500 ms.

[ remaining of the section unchanged ]

***********************************************************************
15.  Suggested SCTP Protocol Parameter Values

   The following protocol parameters are RECOMMENDED:

      RTO.Initial - 3 seconds
      RTO.Min - 1 second
      RTO.Max - 60 seconds
      Max.Burst - 4
      RTO.Alpha - 1/8
      RTO.Beta - 1/4
      Valid.Cookie.Life - 60 seconds
      Association.Max.Retrans - 10 attempts
      Path.Max.Retrans - 5 attempts (per destination address)
      Max.Init.Retransmits - 8 attempts
      HB.interval - 30 seconds
      HB.Max.Burst - 1
      SACK.Delay - 200 milliseconds

   IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to
   customize some of these protocol parameters (see Section 10).

   Note: RTO.Min SHOULD be set as recommended above.

Notes:

In section 6.2, the name 'SACK.Delay' is given to the protocol parameter that indicate themaximum delay for generating a SACK.

In section 15, the list of SCTP protocol parameters and associated recommended value is not complete. The maximum delay for generating an acknowledgement ('SACK.Delay') is missing from this list.

Errata ID: 5202
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nicholas Wilson
Date Reported: 2017-12-13
Verifier Name: Spencer Dawkins
Date Verified: 2018-07-10

Section 3.3.4. says:

   The SACK also contains zero or more Gap Ack Blocks.  Each Gap Ack
   Block acknowledges a subsequence of TSNs received following a break
   in the sequence of received TSNs.  By definition, all TSNs
   acknowledged by Gap Ack Blocks are greater than the value of the
   Cumulative TSN Ack.

It should say:

   The SACK also contains zero or more Gap Ack Blocks.  Each Gap Ack
   Block acknowledges a subsequence of TSNs received following a break
   in the sequence of received TSNs.  By definition, all TSNs
   acknowledged by Gap Ack Blocks are greater than the value of the
   Cumulative TSN Ack.

   The sequence of Gap Ack Blocks MUST be an increasing sequence of
   ranges, non-intersecting, and with at least one TSN as a gap between
   each Block and between the Cumulative TSN Ack and the first Block.

Notes:

It seems clear that the Gap Ack sequence must be sent in its "canonical" form (monotonic non-overlapping ranges) but I can't find anywhere where this is actually stated.

It is implied (but not stated) by the following sentence on the next page, which implies that there is no freedom of choice in how the Gap Ack sequence is encoded:

"For example, assume that ...
then the parameter part of the SACK MUST be constructed as follows"

Verifier Notes:
This errata suggests two corrections:
(1) Ensure that the gap ack blocks are not overlapping.
(2) Ensure that the gap ack blocks are monotonic.

Subsequent discussion in TSVWG, as documented in
https://tools.ietf.org/html/draft-ietf-tsvwg-rfc4960-errata-06#section-3.47,
has converged on this resolution:

* The intention actually was to have the gap blocks isolated. So (1) ought
to be included in the next revision of SCTP.
* In some cases gap blocks might not be monotonic. This is the same as with
the handling of gap reports in TCP SACK. Therefore (2) ought not be
included in the next revision of SCTP.

Errata ID: 1574
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Randall Stewart
Date Reported: 2008-10-14
Verifier Name: Magnus Westerlund
Date Verified: 2009-04-03

Section 9.2 says:

Once an endpoint has reached the SHUTDOWN-RECEIVED state, it MUST NOT
 send a SHUTDOWN in response to a ULP request, and should discard
 subsequent SHUTDOWN chunks.

It should say:

Once an endpoint has reached the SHUTDOWN-RECEIVED state, it MUST NOT
 send a SHUTDOWN in response to a ULP request, and should discard
 subsequent ULP shutdown requests.

Notes:

The text never intended the SCTP endpoint to ignore SHUTDOWN
chunks from its peer. If it did the endpoints could never gracefully
terminate a associations in some cases.

Errata ID: 2592
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: tom petch
Date Reported: 2010-10-29
Verifier Name: Lars Eggert
Date Verified: 2010-10-31

Section 14.1 says:

14.1.  IETF-Defined Chunk Extension

   The assignment of new chunk parameter type codes is done through an
   IETF Consensus action, as defined in [RFC2434].  Documentation of the
   chunk parameter MUST contain the following information:

It should say:

14.1.  IETF-Defined Chunk Extension

   The assignment of new chunk type codes is done through an
IETF Consensus action, as defined in [RFC2434].  Documentation of the
chunk type MUST contain the following information:

Notes:

The OLD text relates to parameter types, and not chunk types, and already appears, correctly, in section 14.2. Section 14.1 is about chunk types,as the NEW text says.

Errata ID: 5003
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Max Mattes
Date Reported: 2017-04-24
Verifier Name: Spencer Dawkins
Date Verified: 2018-07-10

Section 10.1 says:

   o  Receive Unacknowledged Message

      Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer
              size, [,stream id] [, stream sequence number] [,partial
              flag] [,payload protocol-id])

It should say:

   O) Receive Unacknowledged Message

      Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer
              size, [,stream id] [, stream sequence number] [,partial
              flag] [,payload protocol-id])

Notes:

This is part of a lettered list of items, and surrounding sublists use lowercase "o" as a bullet. This item appears to have been mis-corrected to an "o" sublist item when it should be item "O)" of the primary list, as evidenced by the preceding item "N)" and following "P)"

Errata ID: 5957
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Földvári Zoltán
Date Reported: 2020-01-13
Verifier Name: Mirja Kühlewind
Date Verified: 2020-01-13

Section 10.1 says:

D) Abort

      Format: ABORT(association id [, Upper Layer Abort Reason]) ->
      result

   Ungracefully closes an association.  Any locally queued user data
   will be discarded, and an ABORT chunk is sent to the peer.  A success
   code will be returned on successful abort of the association.  If
   attempting to abort the association results in a failure, an error
   code shall be returned.

   Mandatory attributes:

   o association id - local handle to the SCTP association.

   Optional attributes:

   o Upper Layer Abort Reason - reason of the abort to be passed to the
   peer.

   None.

It should say:

D) Abort

      Format: ABORT(association id [, Upper Layer Abort Reason]) ->
      result

   Ungracefully closes an association.  Any locally queued user data
   will be discarded, and an ABORT chunk is sent to the peer.  A success
   code will be returned on successful abort of the association.  If
   attempting to abort the association results in a failure, an error
   code shall be returned.

   Mandatory attributes:

   o association id - local handle to the SCTP association.

   Optional attributes:

   o Upper Layer Abort Reason - reason of the abort to be passed to the
   peer.

Notes:

There is an extra "None." at the end but it is not necessary because there is an optional attribute.

RFC 4966, "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status", July 2007

Source of RFC: v6ops (ops)

Errata ID: 1306
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Brian Carpenter
Date Reported: 2008-01-29
Verifier Name: Ron Bonica
Date Verified: 2009-10-06

Throughout the document, when it says:

[RFC3498] 

It should say:

[RFC3948]

Notes:

All citations of [RFC3498] are intended to be [RFC3948]

Errata ID: 3142
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: David L. Black
Date Reported: 2012-02-29
Verifier Name: Ron Bonica
Date Verified: 2012-03-06

Section 2.1 says:

Unless UDP encapsulation is used for IPsec [RFC3498], traffic using
IPsec AH (Authentication Header), in transport and tunnel mode, and
IPsec ESP (Encapsulating Security Payload), in transport mode, is
unable to be carried through NAT-PT without terminating the security
associations on the NAT-PT, due to their usage of cryptographic
integrity protection.

It should say:

IPsec traffic using AH (Authentication Header) [RFC4302] in both
transport and tunnel modes cannot be carried through NAT-PT without
terminating the security associations on the NAT-PT, due to the
inclusion of IP header fields in the scope of AH's cryptographic
integrity protection [RFC3715].  In addition, IPsec traffic using
ESP (Encapsulating Security Payload) [RFC4303] in transport mode
generally uses UDP encapsulation [RFC3948] for NAT traversal
(including NAT-PT traversal) in order to avoid the problems
described in [RFC3715].

Notes:

This RFC4966 text was copied into draft-ietf-behave-64-analysis-06.
Gen-ART review of that draft found that the statement was incorrect
for ESP. The correct explanations of the problems (in great detail)
can be found in RFC 3715.

RFC 4967, "Dial String Parameter for the Session Initiation Protocol Uniform Resource Identifier", July 2007

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rai

Errata ID: 3723
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Gagandeep Singh
Date Reported: 2013-09-12
Verifier Name: Gonzalo Camarillo
Date Verified: 2013-11-14

Section 3 says:

Thus, the digit 2 is the first row, second column, and consists of
   770Hz and 1209Hz frequencies mixed together.

It should say:

Thus, the digit 2 is the first row, second column, and consists of
   697Hz and 1336Hz frequencies mixed together.

Notes:

As per the specification, DTMF is a 4 x 4 matrix with four row frequencies (697, 770, 852, 941 Hz) and four column frequencies (1209, 1336, 1477, 1633 Hz).
Thus correct matrix for digit 2 should be (697Hz, 1336Hz)

RFC 4975, "The Message Session Relay Protocol (MSRP)", September 2007

Note: This RFC has been updated by RFC 7977, RFC 8591, RFC 8873, RFC 8996

Source of RFC: simple (rai)

Errata ID: 1954
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Dennis Noordsij
Date Reported: 2009-12-03
Verifier Name: Robert Sparks
Date Verified: 2010-10-28

Section 9 says:

ext-header = hname ":" SP hval CRLF

It should say:

ext-header = hname ":" SP hval

Notes:

The rule:

headers = To-Path CRLF From-Path CRLF 1*( header CRLF )

already suffixes every header with a CRLF. The result is that the extension headers are followed by 2 CRLFs, introducing empty lines inside the header segment. This appears to be unintended, since none of the other headers have a terminating CRLF in their production rules, only the ext-header.

RFC 4976, "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", September 2007

Note: This RFC has been updated by RFC 7977, RFC 8553, RFC 8996

Source of RFC: simple (rai)

Errata ID: 1272
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-14
Verifier Name: Robert Sparks
Date Verified: 2010-04-28

Section 4.6 (p.12) says:

                  [...].  Specifically, an Expires header in an AUTH
   request indicates how long the provided URIs will be valid.

It should say:

                  [...].  Specifically, an Expires header field in an
   AUTH response indicates how long the provided URIs will be valid.

Notes:

At the bottom of page 12:
a) terminology -- cf GLOBAL errata report
b) s/request/response/ !!!

RFC 4978, "The IMAP COMPRESS Extension", August 2007

Source of RFC: lemonade (app)

Errata ID: 1803
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-18
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-06

Section 3 says:

        C: b login arnt tnra
        S: b OK Logged in as arnt
        C: c compress deflate
|       S: d OK DEFLATE active
           ^

It should say:

        C: b login arnt tnra
        S: b OK Logged in as arnt
        C: c compress deflate
|       S: c OK DEFLATE active
           ^

Notes:

The tag in the reply from the server MUST match the tag in the
command sent by the client.

RFC 4984, "Report from the IAB Workshop on Routing and Addressing", September 2007

Source of RFC: IAB

Errata ID: 1950
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Shane Amante
Date Reported: 2009-11-30
Verifier Name: Danny McPherson
Date Verified: 2010-09-10

Section 4.3 says:

   Since each
   technology step roughly doubles memory, that implies that if demand
   grows faster than about (2x/1.5x) = 1.3x per year, then technology
   refresh will not be able to remain on a constant cost curve.

It should say:

   Since each
   technology step roughly doubles memory, that implies that if demand
   grows faster than about (2x/1.5x) = 1.3x every 2 years, then technology
   refresh will not be able to remain on a constant cost curve.

RFC 4985, "Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name", August 2007

Source of RFC: pkix (sec)

Errata ID: 2520
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Stefan Santesson
Date Reported: 2010-09-14
Verifier Name: Tim Polk
Date Verified: 2011-03-09

Section 2 says:

 Name
    The DNS domain name of the domain where the specified service
    is located.

It should say:

Name
    A DNS domain name, representing a domain for which the certificate
    issuer has asserted that the certified subject is a legitimate
    provider of the identified service.

Notes:

The current text is ambiguous compared with the defined meaning of this name form given in the RFC.

The definition of this component is given in the overall definition as:

"The content of the components of this name form MUST be consistent
with the corresponding definition of these components in an SRV RR
according to RFC 2782 [N3]."

And later in the same section:

"The purpose of the SRVName is limited to authorization of
service provision within a domain."

The changed text makes it clear that the domain is the domain where the certified host is a legitimate service provider, which may or may not be the domain where the same host is located. Thus the changed text harmonize with the rest of the document.

RFC 4987, "TCP SYN Flooding Attacks and Common Mitigations", August 2007

Source of RFC: tcpm (wit)

Errata ID: 7052
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Merlin Büge
Date Reported: 2022-07-28
Verifier Name: RFC Editor
Date Verified: 2022-07-29

Section 3.6 says:

Instead, they encode most of the state
(and all of the strictly required) state that they would normally
keep into the sequence number transmitted on the SYN-ACK.

It should say:

Instead, they encode most of the state
(and all of the strictly required state) that they would normally
keep into the sequence number transmitted on the SYN-ACK.

Notes:

Move the second "state" into the parentheses.

RFC 4991, "A Common Schema for Internet Registry Information Service Transfer Protocols", August 2007

Source of RFC: crisp (app)

Errata ID: 2285
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-21

Section 3 says:

The XML Schema presented in Section 3 contains, in the lower half
of page 4, the following type declaration:

   <complexType name="octetsType">
     <choice>
|      <element name="exceedsMaximum">
|        <complexType/>
|      </element>
       <element name="octets" type="positiveInteger" />
     </choice>
   </complexType>

It should say:

   <complexType name="octetsType">
     <choice>
|      <element name="exceedsMaximum" />
       <element name="octets" type="positiveInteger" />
     </choice>
   </complexType>

Notes:

Source: apps

RFC 4992, "XML Pipelining with Chunks for the Internet Registry Information Service", August 2007

Note: This RFC has been updated by RFC 8996

Source of RFC: crisp (app)

Errata ID: 1009
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Verifier Name: Peter Saint-Andre
Date Verified: 2011-08-01

Section Appendix A says:

   C:           (chunk 1)
   C: 0x44      (LC=no,DC=yes,CT=sd)
   C: 0x00 0x11 (chunk length=11)

It should say:

   C:           (chunk 1)
   C: 0x44      (LC=no,DC=yes,CT=sd)
   C: 0x00 0x12 (chunk length=18)

Notes:

Apparently, there is an inconsistency in chunk 1 of the first request block, closely related to errata ID 2830, and this has nurtured my suspicion reported there that perhaps the 'mechanism data length' field has been added late in the draft history, without sufficient care.

The first chunk data field has the following components:
SASL mechanism "PLAIN" ... 1 + 5 octets
10 octets of SASL PLAIN data ... 2 + 10 octets
This sums up to (decimal) 18 octets, or 0x12.

[Separated out other errata from this one. This was the last erratum originally reported in 1009.]

Errata ID: 2829
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Verifier Name: Peter Saint-Andre
Date Verified: 2011-08-01

Section 6.2 says:

  Chunks of this type contain XML conformant to the schema specified in
  [9] and MUST have the <versions> element as the root element.

It should say:

   Chunks of this type MUST contain XML conformant to the schema
   specified in [9] and MUST have the <versions> element as the root
   element, unless sent by the Client to solicit version information;
   client to server chunks may be zero length, as detailed below.

Notes:

Note: This erratum was separated off from erratum #1009.

The reporter of the erratum said:

As already mentioned earlier in the text and clarified in the
second-to-last paragraph of the same section, this requirements
language is improper because it is intended to allow clients to
send this type of chunk as well, with unspecified (perhaps empty)
content, to be ignored by the server.

The authors of the specification provided the following notes:

We recommend accepting the error reported in Erratum ID 2829,
but we do not recommend accepting the proposed fix. The issue
is that the MUSTs listed in the original apply when the server
emits this, but not to the client when it is soliciting this.
We recommend the following:

"Chunks of this type MUST contain XML conformant to the schema
specified in [9] and MUST have the <versions> element as the
root element, unless sent by the Client to solicit version
information; client to server chunks may be zero length, as
detailed below."

Errata ID: 2827
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Verifier Name: Pete Resnick
Date Verified: 2011-06-11

Section 4 says:

|                 [...].  Conceptually, a CRB is a type of RQB; they
   share the same format, but a CRB is constrained in conveying only
   specific information and is only sent at the beginning of the session
   lifecycle.

It should say:

|                 [...].  Conceptually, a CRB is a type of RSB; they
   share the same format, but a CRB is constrained in conveying only
   specific information and is only sent at the beginning of the session
   lifecycle.

Notes:

Separating separate errata from 1009.

RFC 4993, "A Lightweight UDP Transfer Protocol for the Internet Registry Information Service", August 2007

Source of RFC: crisp (app)

Errata ID: 1010
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Verifier Name: Alexey Melnikov
Date Verified: 2010-07-07

Section 3.1.5 says:

The first paragraph of Section 3.1.5, on page 97of RFC 4993, says:

|  A payload type with version information ('vi') MUST be conformant to
   the XML defined in [8] and use the <versions> element as the root
   element.

It should say:

|  A payload type with version information ('vi') sent from the server
|  to the client MUST be conformant to the XML defined in [8] and use
   the <versions> element as the root element.

Notes:

As mentioned in other places of the text, this requirements language
is improper because it is intended to allow clients to send this
type of chunk as well, with unspecified (perhaps empty) content,
to be ignored by the server.

Note: This issue is a replication of the issue detailed in item (A.3)
for RFC 4992.

Errata ID: 2320
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Verifier Name: Alexey Melnikov
Date Verified: 2010-07-07

Section 8 says:

The first paragraph of Section 8, on page 12 of RFC 4993, says:

   IRIS-LWZ is intended for serving public data; it provides no in-band
   mechanisms for authentication or confidentiality.  Any application
   with these needs must provide out-of-band mechanisms (e.g., IPsec),
   or use the IRIS transfer protocols that provide such capabilities,
|  such as IRIS-XPC [9].
                ^^^

It should say:

   IRIS-LWZ is intended for serving public data; it provides no in-band
   mechanisms for authentication or confidentiality.  Any application
   with these needs must provide out-of-band mechanisms (e.g., IPsec),
   or use the IRIS transfer protocols that provide such capabilities,
|  such as IRIS over XPCS [9].
                ^^^^^^^^^

Notes:

The last phrase fatally misses the requirement.
The needed services are only provided by the TLS encapsulation of
IRIS-XPC, the compound protocol being named IRIS over XPCS in [9], and
that is being made visible via explicit iris.xpcs URIs [9].

Alexey: the term IRIS-XPCS is not defined in [9], but "IRIS over XPCS" is used. So I modified the change accordingly.

RFC 4996, "RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)", July 2007

Note: This RFC has been obsoleted by RFC 6846

Source of RFC: rohc (tsv)

Errata ID: 1291
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-21
Verifier Name: Magnus Westerlund
Date Verified: 2009-09-07

Section 6.3.3 (end) says:

      Item 1, ..., item n: Each item corresponds to an XI with X = 1 in
      XI 1, ..., XI m.  The format of the entries in the item list is
|     described in Section 6.2.
                           ^^^^

It should say:

      Item 1, ..., item n: Each item corresponds to an XI with X = 1 in
      XI 1, ..., XI m.  The format of the entries in the item list is
|     encoded by the encoding method found in the table of Section 6.3.
|     The compressed format(s) suffixed by "_list_item" in the encoding
|     methods defines the item inside the compressed item list.
 

Notes:

6.2 definitely does not contain this information.
I did not find a section that actually gives all these
details, as could be expected.

Maybe, something has been lost during the development of the document.

Authors and WG chair provided the corrected text with additional details.

Errata ID: 1292
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-21
Verifier Name: Magnus Westerlund
Date Verified: 2009-09-07

Section 6.4.3 (end) says:

   The "inferred_ip_v4_length" encoding method compresses the IPv4
|  header checksum down to a size of zero bits.  Using this encoding
   method, the decompressor infers the value of this field by counting
   in octets the length of the entire packet after decompression.

It should say:

   The "inferred_ip_v4_length" encoding method compresses the IPv4
|  Total Length field down to a size of zero bits.  Using this encoding
   method, the decompressor infers the value of this field by counting
   in octets the length of the entire packet after decompression.

Notes:

Apparently missed edit after copy & paste.

Errata ID: 1293
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-21
Verifier Name: Magnus Westerlund
Date Verified: 2009-09-07

Section 6.4.8.2,p.34 says:

   Establishing residue:

|     The scaling factor is established by sending unscaled TCP
                  ^^^^^^
      Acknowledgment Number bits, so that the decompressor can infer its
      value from the unscaled value and the scaling factor (ack_stride).

It should say:

   Establishing residue:

|     The scaling residue is established by sending unscaled TCP
                  ^^^^^^^^
      Acknowledgment Number bits, so that the decompressor can infer its
      value from the unscaled value and the scaling factor (ack_stride).

Notes:

Apparently missed edit after copy & paste from preceding paragraph.

Errata ID: 1298
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-21
Verifier Name: Magnus Westerlund
Date Verified: 2009-09-07

Section 8.2, p.67 says:

   COMPRESSED sack2_list_item {
     discriminator =:= '00000010';
     block_1       =:= sack_block(ack_value);
     block_2       =:= sack_block(block_1_end.UVALUE);
     ENFORCE(length.UVALUE == 18);
   }

It should say:

   COMPRESSED sack2_list_item {
     discriminator =:= '00000010';
     block_1       =:= sack_block(ack_value);
|    block_2       =:= sack_block(block_1.UVALUE && 0xFFFFFFFF);
     ENFORCE(length.UVALUE == 18);
   }

Notes:

ROHC-FN is intended to introduce precision.
Therefore, no ad-hoc variable names should be introduced,
independent of how mnemonic their names might be.

I hope that the NEW text substituted above indeed is what had been
intended.

Similar corrections need to be applied on page 68 (10 instances)
and on top of page 69 (one instance).

Errata ID: 1299
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-21
Verifier Name: Magnus Westerlund
Date Verified: 2009-09-07

Section 8.2, p.69 says:

 tcp_opt_generic
 {
   UNCOMPRESSED {
     type                                    [ 8 ];
     length_msb =:= uncompressed_value(1, 0) [ 1 ];
     length_lsb                              [ 7 ];
|    contents                           [ length_len.UVALUE*8-16 ];
   }
                                                 ^^^

It should say:

 tcp_opt_generic
 {
   UNCOMPRESSED {
     type                                    [ 8 ];
     length_msb =:= uncompressed_value(1, 0) [ 1 ];
     length_lsb                              [ 7 ];
|    contents                           [ length_lsb.UVALUE*8-16 ];
   }
                                                 ^^^

Notes:

'length_len' has never been introduced.
This must be a confusing typo, invalidating the formal specification.

Tis same correction needs to be applied once more, near the bottom
of page 69.

RFC 5002, "The Session Initiation Protocol (SIP) P-Profile-Key Private Header (P-Header)", August 2007

Note: This RFC has been updated by RFC 8217

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: gen

Errata ID: 1008
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-09

Throughout the document, when it says:

Author*                      Informational                      [Page X]

It should say:

Camarillo & Blanco           Informational                      [Page X]

RFC 5005, "Feed Paging and Archiving", September 2007

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 1685
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2009-02-18
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-11

Section 4 says:

    <entry>
      <title>Atom-Powered Robots Scheduled To Run Amok</title>
      <link href="http://example.org/2003/11/24/robots_coming"/>
|     <id>urn:uuid:cdef5c6d5-gff8-4ebb-assa-80dwe44efkjo</id>
      <updated>2003-11-24T12:00:00Z</updated>
      <summary>Some text from an old, different entry.</summary>
    </entry>

It should say:

    <entry>
      <title>Atom-Powered Robots Scheduled To Run Amok</title>
      <link href="http://example.org/2003/11/24/robots_coming"/>
|     <id>urn:uuid:2c355272-fd98-11dd-8474-0016415cd53f</id>
      <updated>2003-11-24T12:00:00Z</updated>
      <summary>Some text from an old, different entry.</summary>
    </entry>

Notes:

The example UUID has the wrong number of characters in the first part, and non-hex digits in the last two parts (see http://intertwingly.net/blog/2009/02/17/White-House-FeedBack-Loop).

(The suggested replacement has a freshly minted UUID)

Errata ID: 1806
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Nottingham
Date Reported: 2009-07-12
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-11

Throughout the document, when it says:

URI

It should say:

IRI

Notes:

Atom defines links as IRIs, not URIs; they should not be constrained to URIs.

Also implies a reference to RFC3987 (or successor).

RFC 5007, "DHCPv6 Leasequery", September 2007

Source of RFC: dhc (int)

Errata ID: 3763
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Darpan Malhotra
Date Reported: 2013-10-23
Verifier Name: Ted Lemon
Date Verified: 2014-03-02

Throughout the document, when it says:

4.3.3.  Receipt of LEASEQUERY-REPLY

   A successful LEASEQUERY-REPLY is one without an OPTION_STATUS_CODE
   option (or an OPTION_STATUS_CODE option with a success code).  There
   are three variants:

   1.  If the server had bindings for the requested client, the message
       includes an OPTION_CLIENT_DATA option and the requestor extracts
       the client data from the LEASEQUERY-REPLY and updates its binding
       information database.  If the OPTION_CLIENT_DATA contains no
       OPTION_CLT_TIME, the requestor SHOULD silently discard the
       OPTION_CLIENT_DATA option.

...

4.3.4.  Handling DHCPv6 Client Data from Multiple Sources

...

   The requestor SHOULD use the OPTION_CLT_TIME to resolve data
   conflicts originated from different servers, and SHOULD accept data
   with most recent OPTION_CLT_TIME.

It should say:

4.3.3. Receipt of LEASEQUERY-REPLY

   A successful LEASEQUERY-REPLY is one without an OPTION_STATUS_CODE
   option (or an OPTION_STATUS_CODE option with a success code).  There
   are three variants:

   1.  If the server had bindings for the requested client, the message
       includes an OPTION_CLIENT_DATA option and the requestor extracts
       the client data from the LEASEQUERY-REPLY and updates its binding
       information database.  

...

4.3.4. Handling DHCPv6 Client Data from Multiple Sources

...

   The requestor SHOULD use the OPTION_CLT_TIME to resolve data
   conflicts originated from different servers, and SHOULD accept data
   with most recent OPTION_CLT_TIME. If OPTION_CLT_TIME is not
   present in a response, then response from other servers having
   OPTION_CLT_TIME should be preferred.

Notes:

Consider the scenario of DHCPv6 Failover (as mentioned in RFC 7031), there will be cases where only one server (Main) would have communicated with the client. Bindings for the client will be present on both servers, but the partner server (Backup) will not have Client Last Transaction Time. When a requestor sends Leasequery to the backup server, the response should not contain OPTION_CLT_TIME.

Further, consider the following scenarios:
1. Requestor gets response for Leasequery from both servers (main and backup).
In this scenario, response having OPTION_CLT_TIME should be preferred by the requestor. This is the justification for adding the text in Section 4.3.4.

2. Requestor gets response for Leasequery from only from one server (as other server is down).
Consider main to be down. So, the requestor gets response only from Backup. The requestor should still accept this data. This is justification of removing the text from Section 4.3.3.

Errata ID: 4816
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sander Steffann
Date Reported: 2016-10-02
Verifier Name: Eric Vyncke
Date Verified: 2021-02-08

Throughout the document, when it says:

There are references to OPTION_CLIENT_LINK, which doesn't exist.

It should say:

The references are apparently for option 48: OPTION_LQ_CLIENT_LINK.

Notes:

-- Verifier note --
Section 4.1.2.5 of this RFC indeed specifies OPTION_LQ_CLIENT_LINK (the DHCPv6 IANA registry also uses OPTION_LQ_CLIENT_LINK). So, sections 4.3.3 and 4.4.1 should use "OPTION_LQ_CLIENT_LINK" rather than "OPTION_CLIENT_LINK".

RFC 5008, "Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)", September 2007

Note: This RFC has been obsoleted by RFC 6318

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 1729
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sean Turner
Date Reported: 2009-03-16
Verifier Name: Russ Housley
Date Verified: 2010-04-08

Section 4.1 says:

      originator MUST be the originatorKey alternative.  The
      originatorKey algorithm field MUST contain the id-ecPublicKey
      object identifier (see Section 3) with NULL parameters.  The
      originatorKey publicKey field MUST contain the message
      originator's ephemeral public key, which is a DER-encoded ECPoint
      (see Section 3).  The ECPoint SHOULD be represented in
      uncompressed form.

It should say:

      originator MUST be the originatorKey alternative.  The 
      originatorKey algorithm field MUST contain the id-ecPublicKey 
      object identifier (see Section 3).  The parameters associated 
      with id-ecPublicKey MUST be absent, ECParameters, or NULL. The 
      parameters associated with id-ecPublicKey SHOULD be absent or 
      ECParameters, and NULL is allowed to support legacy implementations.  
      The originatorKey publicKey field MUST contain the message 
      originator's ephemeral public key, which is a DER-encoded ECPoint 
      (see Section 3).  The ECPoint SHOULD be represented in uncompressed 
      form.

Notes:

This change aligns RFC 5008 with the draft-ietf-smime-3278bis. The correct parameters for id-ecPublicKey is either absent or ECParameters not NULL. Retained NULL for backwards compatibility.

Errata ID: 1902
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sean Turner
Date Reported: 2009-10-05
Verifier Name: Russ Housley
Date Verified: 2010-04-08

Section 4.3 says:

      keyInfo contains the object identifier of the key-encryption
      algorithm that will be used to wrap the content-encryption key and
      NULL parameters.  In Suite B, Security Level 1, AES-128 Key Wrap
      MUST be used, resulting in {id-aes128-wrap, NULL}.  In Suite B,
      Security Level 2, AES-256 Key Wrap MUST be used, resulting in
      {id-aes256-wrap, NULL}.

It should say:

      keyInfo contains the object identifier of the key-encryption
      algorithm that will be used to wrap the content-encryption key and
      absent parameters.  In Suite B, Security Level 1, AES-128 Key Wrap
      MUST be used, resulting in {id-aes128-wrap}.  In Suite B,
      Security Level 2, AES-256 Key Wrap MUST be used, resulting in
      {id-aes256-wrap}.

Notes:

Parameters for AES-* Key Wrap MUST be absent according to RFC 3565.

Errata ID: 2060
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sean Turner
Date Reported: 2010-03-03
Verifier Name: Russ Housley
Date Verified: 2010-04-08

Section 2 says:

2.  SHA-256 and SHA-256

It should say:

2.  SHA-256 and SHA-384

Notes:

The title should reflect SHA-384 as the other hash algorithm.

Errata ID: 4477
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: poima fuimaono
Date Reported: 2015-09-19
Verifier Name: Stephen Farrell
Date Verified: 2015-09-19

Section 2 says:

SHA-256 and SHA-256

It should say:

SHA-256 and SHA-384

Notes:

SHA-384 as other has algorithm

RFC 5015, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", October 2007

Note: This RFC has been updated by RFC 8736, RFC 9436

Source of RFC: pim (rtg)

Errata ID: 3762
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christopher Brown
Date Reported: 2013-10-22
Verifier Name: Adrian Farrel
Date Verified: 2013-10-23

Section 3.5.3.1. says:

      Best-Offer
         Used by the DF to record the identity and advertised metrics of
         the router that has made the last offer, for use when sending
         the Path message.

It should say:

      Best-Offer
         Used by the DF to record the identity and advertised metrics of
         the router that has made the last offer, for use when sending
         the Pass message.

Notes:

typo: Path message should be Pass message

RFC 5019, "The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments", September 2007

Note: This RFC has been updated by RFC 8996

Source of RFC: pkix (sec)

Errata ID: 5740
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jaime Hablutzel
Date Reported: 2019-05-26
Verifier Name: RFC Editor
Date Verified: 2019-06-03

Section 2.2.1 says:

In the case where a responder does not have the ability to respond to
an OCSP request containing a option not supported by the server, it
SHOULD return the most complete response it can.

It should say:

In the case where a responder does not have the ability to respond to
an OCSP request containing an option not supported by the server, it
SHOULD return the most complete response it can.

Notes:

"a option" should be "an option"

RFC 5022, "Media Server Control Markup Language (MSCML) and Protocol", September 2007

Source of RFC: INDEPENDENT

Errata ID: 1239
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Verifier Name: Nevil Brownlee
Date Verified: 2011-03-28

Section 6.1.1.1 says:

   Attributes of <audio>:

   o  url - required, no default value: The URL of the content to be
      retrieved and played.  The target may be a local or remote (NFS)
      "file://" scheme URL or an "http://" or "https://" scheme URL.  If
      the URL is not fully qualified and a "baseurl" attribute was set,
      the value of the "baseurl" attribute will be prepended to this
      value to generate the target URL.

It should say:

< see Notes >

Notes:

Again, the RFC should make use of standard terminology
established in the IETF.
STD 66, RFC 3986 should be used here.
The attribute, 'url', should better have been named 'uri'.

Consequently, all subsequent references to an URL w.r.t. this
attribute should be replaced by "URI" or "URI reference", as
appropriate.

Authors comment: This is really an Editorial erratum. If it were to be changed, it should be changed consistently throughout the document.

Errata ID: 1242
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Verifier Name: Nevil Brownlee
Date Verified: 2011-03-28

Section 6.1.1.1. says:

   o  rate - optional, default value "0": Specifies the absolute
      playback rate of the content relative to normal as either a
      positive percentage (faster) or a negative percentage (slower).
      Any value that attempts to set the rate above the maximum allowed
      or below the minimum allowed silently sets the rate to the maximum
      or minimum.  The rate reverts back to its original value when
      playback of the content URL has been completed.

It should say:

|  o  rate - optional, default value "0": Specifies the deviation of the
|     content playback rate from its normal value as either a positive
      percentage (faster) or a negative percentage (slower).
      Any value that attempts to set the rate above the maximum allowed
      or below the minimum allowed silently sets the rate to the maximum
      or minimum.  The rate reverts back to its original value when
|     playback of the content specified by the URI has been completed.

Notes:

There is perfect confusion between 'absolute' and 'relative",
leaving this specification open to gross misunderstanding.

I hope the proposed replacement text says what had been intended
to say; it also corrects sluggish language and applies STD 66 terms.

Errata ID: 1247
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Verifier Name: Nevil Brownlee
Date Verified: 2011-03-28

Section 6.5.3, p.41 says:

   The recording example (Figure 19) plays a prompt and records it to
   the destination specified in the "recurl" attribute encoded as MS-GSM
   in wave format.

It should say:

|  The recording example (Figure 19) plays a prompt and records the
|  response to the destination specified in the "recurl" attribute
   encoded as MS-GSM in wave format.

Notes:

The RFC text is ambiguous/misleading; what does 'it' refer to ?

I guess that nobody will be interested in recording the prompt.
Therefore, I hope the clarification above says what has been intended.

Errata ID: 1248
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Verifier Name: Nevil Brownlee
Date Verified: 2011-03-28

Section 8, page 48 says:

   Managecontent Attributes:

   o  src - required, no default value: Specifies the local source URL
      of the content.  The URL scheme MUST be "file://".

   o  dest - required (see note), no default value: Specifies the
      destination URL.  The URL scheme MUST be "http://".  Note: If the
      selected action is 'delete', this attribute is optional; otherwise
      it is required.

It should say:

   Managecontent Attributes:

|  o  src - required, no default value: Specifies the local source URI
|     of the content.  The URI scheme MUST be "file".

   o  dest - required (see note), no default value: Specifies the
|     destination URI.  The URI scheme MUST be "http".  Note: If the
      selected action is 'delete', this attribute is optional; otherwise
      it is required.

Notes:

a)
The RFC should follow STD 66, RFC 3986 terminology and syntax.
URI schemes do not allow ':' and '/' -- see Section 3.1 (p.17) of RFC 3986.

b) ... MUST be "http" ...
Why the hack does the RFC explicitely forbid using HTTP security
and the "https" URI scheme ????
(I do not believe the authors expect the use of "Upgrade to TLS"
within HTTP, which is rarely implemented -- although it once was
intended as a generice security layer drop-in mechanism.)

Authors comment: Yes, HTTP is a MUST implement, though not the only option here.

Errata ID: 1234
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Verifier Name: Nevil Brownlee
Date Verified: 2011-03-28

Section 5.5 says:

   A client can modify a leg by issuing an INFO on the dialog associated
 | with the participant leg.  For example, Figure 8 mutes a conference
   leg.

It should say:

   A client can modify a leg by issuing an INFO on the dialog associated
 | with the participant leg.  For example, the request in Figure 8 mutes
   a conference leg.

Notes:

Text below Figure 7 (on page 15) is misleading.
Figure 8 is printed on the paper sheet in my hand
and does not mute anything :-)

Errata ID: 1235
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Verifier Name: Nevil Brownlee
Date Verified: 2011-03-28

Section 5.7, 3rd par says:

|  A request for an active talker report is in Figure 9.  The active
   talker report enumerates the current call legs in the mix.

It should say:

|  A request for an active talker report is shown in Figure 9.  The
   active talker report enumerates the current call legs in the mix.

Notes:

Improved language.

Errata ID: 1236
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Verifier Name: Nevil Brownlee
Date Verified: 2011-03-28

Section 5.8.2.3 says:

   The corresponding MSCML request is as follows.
   <?xml version="1.0"?>
   <MediaServerControl version="1.0">
   ...

   Figure 12: Join Agent Request

It should say:

   The corresponding MSCML request is as follows.
|
   <?xml version="1.0"?>
   <MediaServerControl version="1.0">
   ...

   Figure 12: Join Agent Request

Notes:

On page 22, the XML shown in Figure 12 should have been separated
from the preceding text with a blank line.

The same issue recurs in Section 5.8.2.4 below (on the same page),
with respect to Figure 13.

Errata ID: 1240
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Verifier Name: Nevil Brownlee
Date Verified: 2011-03-28

Section 6.1.1.1. says:

   o  gain - optional, default value "0": Sets the absolute gain to be
      applied to the content URL.  [...]

It should say:

   o  gain - optional, default value "0": Sets the absolute gain to be
      applied to the content specified by the URI.  [...]

Notes:

Sluggish language --
can't mute an URI, or apply gain to an URI ! :-)

Note that other errata request the change from URL to URI throughout.

Errata ID: 1241
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Verifier Name: Nevil Brownlee
Date Verified: 2011-03-28

Section 6.1.1.1 says:

   o  gaindelta - optional, default value "0": Sets the relative gain to
|     be applied to the content URL.  The value of this attribute is
      specified in units of dB.  The media server MAY silently cap
      values that exceed the gain limits imposed by the platform.  The
      level reverts back to its original value when playback of the
|     content URL has been completed.

It should say:

   o  gaindelta - optional, default value "0": Sets the relative gain to
|     be applied to the content specified by the URI.  The value of this
      attribute is specified in units of dB.  The media server MAY
      silently cap values that exceed the gain limits imposed by the
      platform.  The level reverts back to its original value when
|     playback of the content has been completed.

Notes:

Again, sluggish language (and non-use of STD 66 terminology).

Errata ID: 1243
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Verifier Name: Nevil Brownlee
Date Verified: 2011-03-28

Section 6.1.1.1 p.29 says:

   Spoken variables are specified using the <variable> element.  This
   element has the attributes described in the list below.  MSCML's
|  spoken variables are based on those described in Audio Server
   Protocol [17].

It should say:

   Spoken variables are specified using the <variable> element.  This
   element has the attributes described in the list below.  MSCML's
|  spoken variables are based on those described in the Audio Server
   Protocol [17].

Notes:

Missing article (mid-page 29).

Author comment: Good catch.

Errata ID: 1245
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Verifier Name: Nevil Brownlee
Date Verified: 2011-03-28

Section 6.4.3 says:

a) 
    ... "immediate" and "infinite."       (3 instances)          


b)
    ... returnkey is set to #, ...
    

It should say:

a) 
    ... "immediate" and "infinite".       (3 instances)          


b)
    ... returnkey is set to "#", ...
 

Notes:

a) Syntax error; apply 'rational quotation' !
The issue occurs in the 1st, 3rd, and 4th bullet on page 35.

b) Clarification; the single pound character needs to be double-quoted
in the XML anyway, isn't it?
This also will make the text more uniform.

Errata ID: 1246
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Verifier Name: Nevil Brownlee
Date Verified: 2011-03-28

Section 6.5.2, p.40 says:

."

It should say:

".

Notes:

Again, in the second to seventh bullet on page 40,
'rational quotation' should be applied (6 instances).

Errata ID: 1249
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Verifier Name: Nevil Brownlee
Date Verified: 2011-03-28

Section 8, page 49 says:

   o  name - required (see note), no default value: Specifies the field
      name for the content in the form when using the 'post' method.
      This is not to be confused with the "src" or "dest" attributes.
|     Note: This attribute is required when the "htttpmethod" has the
      value "post" and is optional otherwise.

It should say:

   o  name - required (see note), no default value: Specifies the field
      name for the content in the form when using the 'post' method.
      This is not to be confused with the "src" or "dest" attributes.
|     Note: This attribute is required when the "httpmethod" attribute
      has the value "post" and is optional otherwise.

Notes:

A typo, and sluggishly inprecise use of language.

Errata ID: 1251
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Verifier Name: Nevil Brownlee
Date Verified: 2011-03-28

Section 8.1, last pa says:

."               (2 instances)

It should say:

".

Notes:

The last paragraph of Section 8.1 again contains two syntax errors
based non non-pplication of 'rational quoting'.

Errata ID: 1254
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Verifier Name: Nevil Brownlee
Date Verified: 2011-03-28

Section 9.2, Table 5 says:

... it MUST match remote terminal's identifier ...

It should say:

... it MUST match the remote terminal's identifier ...

Notes:

Insert the missing article in the 5th line from the bottom of Figure 5.

RFC 5023, "The Atom Publishing Protocol", October 2007

Note: This RFC has been updated by RFC 8996

Source of RFC: atompub (app)

Errata ID: 1304
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2008-01-29
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-21

Section 5.3 says:

   2.  If the Member Resource was created successfully, the server
       responds with a status code of 201 and a Location header that
       contains the IRI of the newly created Entry Resource.  Media
       Resources could have also been created and their IRIs can be
       found through the Entry Resource.  See Section 9.6 for more
       details.

It should say:

   2.  If the Member Resource was created successfully, the server
       responds with a status code of 201 and a Location header that
       contains the URI of the newly created Entry Resource.  Media
       Resources could have also been created and their IRIs can be
       found through the Entry Resource.  See Section 9.6 for more
       details.

Notes:

The Location header (as defined in HTTP/1.1) contains a URI, not a IRI.

Errata ID: 3207
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Rushforth
Date Reported: 2012-05-01
Verifier Name: Barry Leiba
Date Verified: 2012-05-04

Section p51 says:

   anyForeignElement =
       element * - atom:* {
          (attribute * { text }
           | text
           | anyElement)*
       }

It should say:

   anyForeignElement =
       element * - app:* {
          (attribute * { text }
           | text
           | anyElement)*
       }

Notes:

I believe the schema unintentionally prohibits atom:link from being included in the categories document. Given that in another schema in the same appendix it is allowed, and going by the text in the normative sections, I believe this must be a cut and paste error.

RFC 5025, "Presence Authorization Rules", December 2007

Source of RFC: simple (rai)

Errata ID: 2544
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tiberius Duluman
Date Reported: 2010-10-05
Verifier Name: Gonzalo Camarillo
Date Verified: 2013-04-16

Section 3.3.2.12 says:

   bare:  This value indicates that the <user-input> element is to be
      retained.  However, any "idle-threshold" and "since" attributes
      are to be removed.  This value is assigned the numeric value of
      10.

It should say:

   bare:  This value indicates that the <user-input> element is to be
      retained.  However, any "idle-threshold" and "last-input" attributes
      are to be removed.  This value is assigned the numeric value of
      10.

Notes:

<user-input> does not have a "since" attribute defined.

RFC 5035, "Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility", August 2007

Source of RFC: smime (sec)

Errata ID: 2364
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Verifier Name: Tim Polk
Date Verified: 2010-07-29

Section 4 says:

On mid-page 6, Section 4 of RFC 5035 gives the following text as part
of the new Section 5.4.1.1, Certificate Identification Version 2 :

   The fields of ESSCertIDv2 are defined as follows:

   hashAlgorithm
      contains the identifier of the algorithm used in computing
      certHash.

   certHash
      is computed over the entire DER-encoded certificate (including the
|     signature) using the SHA-1 algorithm.

   [...]

The core reason for the new Cert ID version is algorithm agility.
Therefore, specifying SHA-1 here does not make any sense (and it
would turn the hashAlgorithm field useless) !

The 'certHash' field explanation should say:

   certHash
      is computed over the entire DER-encoded certificate (including the
|     signature) using the algorithm specified by hashAlgorithm.
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

It should say:

See above.

Notes:

See above.

RFC 5036, "LDP Specification", October 2007

Note: This RFC has been updated by RFC 6720, RFC 6790, RFC 7358, RFC 7552

Source of RFC: mpls (rtg)

Errata ID: 3156
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2012-03-15
Verifier Name: Adrian Farrel
Date Verified: 2012-03-17

Section 3.5.8 says:

   Path Vector
      Specifies the LSRs along the LSR being set up by the Label Request
      message.  Section "Path Vector Procedures" describes how to handle
      this TLV.

It should say:

   Path Vector
      Specifies the LSRs along the LSP being set up by the Label Request
      message.  Section "Path Vector Procedures" describes how to handle
      this TLV.

Notes:

Erroneously typed LSR instead of the LSP.

RFC 5044, "Marker PDU Aligned Framing for TCP Specification", October 2007

Note: This RFC has been updated by RFC 6581, RFC 7146

Source of RFC: rddp (tsv)

Errata ID: 1427
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Zem Green
Date Reported: 2008-05-21
Verifier Name: Lars Eggert
Date Verified: 2009-01-12

Section 4.2 says:

FPDUPTR: The FPDU Pointer is a relative pointer, 16 bits long,
   interpreted as an unsigned integer that indicates the number of
   octets in the TCP stream from the beginning of the ULPDU Length field
   to the first octet of the entire Marker.  The least significant two
   bits MUST always be set to zero at the transmitter, and the receivers
   MUST always treat these as zero for calculations.

It should say:

FPDUPTR: The FPDU Pointer is a relative pointer, 16 bits long,
   interpreted as an unsigned integer that indicates the number of
   octets in the TCP stream from the beginning of the ULPDU Length field
   to the first octet of the entire Marker.  The least significant two
   bits MUST always be set to zero at the transmitter, and the receivers
   MUST always treat these as zero for calculations (except for CRC calculation).

Notes:

Evaluated by Pat Thaler and David Black.
Type changed from Editorial to Technical by Lars Eggert.

RFC 5050, "Bundle Protocol Specification", November 2007

Source of RFC: IRTF

Errata ID: 1504
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-09-15
Verifier Name: Stephen Farrell
Date Verified: 2009-11-10

Section 6.1.1,pg.40 says:

|  Fragment Offset:   If the bundle fragment bit is set in the status
|     flags, then the offset (within the original application data unit)
      of the payload of the bundle that caused the status report to be
      generated is included here.

|  Fragment length:   If the bundle fragment bit is set in the status
|     flags, then the length of the payload of the subject bundle is
      included here.

It should say:

|  Fragment Offset:   If the bundle fragment bit is set in the
|     administrative record flags, then the offset (within the original
      application data unit) of the payload of the bundle that caused
      the status report to be generated is included here.

|  Fragment length:   If the bundle fragment bit is set in the
|     administrative record flags, then the length of the payload of
      the subject bundle is included here.

Notes:

Note the distinct fields:
-- administrative record flags (least significant nibble of the
one-octet administrative record header, per Figure 9 on pg.37)
-- status flags (first octet in the body of a bundle status report,
per Figure 11 on page 39)
The fragment bit is contained in the former, not in the latter.

Attention: this same issue recurs literally in Section 6.1.2,
on pg. 43, below Figure 14 !

Errata ID: 1505
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-09-15
Verifier Name: Stephen Farrell
Date Verified: 2009-11-10

Section 6.1.2,pg.43 says:

<same as for Section 6.1.1 -- see Errata ID 1504>

It should say:

<same as for Section 6.1.1 -- see Errata ID 1504>

Errata ID: 1506
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-09-15
Verifier Name: Stephen Farrell
Date Verified: 2009-11-10

Section 10.2,p.47/48 says:

   ... Work Progress, ...

It should say:

   ... Work in Progress, ...

Notes:

Occurs twice, in entry [BSP] and in entry [SECO].

"Work in Progress" is mandatory per various process and IPR documents,
for referring to an Internet-Draft.

RFC 5052, "Forward Error Correction (FEC) Building Block", August 2007

Source of RFC: rmt (tsv)

Errata ID: 1006
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Verifier Name: Michael Luby
Date Verified: 2007-09-09

Section 9.1.2 says:

... the last source block is L-((L-1)/E) rounded down to the nearest
integer)*E octets in length.

It should say:

... the last source block is L-floor((L-1)/E)*E octets in length.

Notes:

Apparently, this sections has been crafted to give a formulation of
the algorithm avoiding the distinction between various cases, and in
particular a separate formulation for the "regular" corner case of
an object that can be partitioned exactly into blocks of equal size.
The formulae given in Section 9.1.2 make use of the standard
functions 'ceil' and 'floor' (restated in Section 9.1), but the
final paragraph of the section, at the bottom of page 19, tries to
paraphrase the 'floor' function (see above).

BTW:
Many FEC schemes are only prepared to deal with encoding symbols of
equal size. To accommodate this, wouldn't it therefore have been
preferable to specify padding (to full size E) of the last symbol of
the last block, for the purpose of this common, default algorithm ?


--- VERIFIER NOTES ---
It is the typical case (not a non-standard case) that the object size is not
an even multiple of some nice encoding source block length, and thus
typically A_small not= A_large. Furthermore, it is the typical case that L
is not a multiple of E. Thus, what you characterize as the "regular" case
is actually quite atypical in the real-world.

Also, any application can pad out the last source symbol of a source block
if it wants if the FEC encoder/decoder can't handle it, the specification
does not mandate a particular implementation. On the other hand, it is
unnecessary, and usually wasteful, to actually send those padding bytes over
the wire, and this specification specifies what is sent on the wire and how.
This is why it is like it is.

RFC 5054, "Using the Secure Remote Password (SRP) Protocol for TLS Authentication", November 2007

Note: This RFC has been updated by RFC 8996

Source of RFC: tls (sec)

Errata ID: 4546
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Rick van Rein
Date Reported: 2015-11-30
Verifier Name: Paul Wouters
Date Verified: 2024-01-16

Section 2.6 says:

B = k*v + g^b % N

It should say:

B = ( k*v + g^b ) % N

Notes:

The customary binding is that + has lower priority than % and so the default reading of the expression would be
B = k*v + ( g^b % N )
That is inconsistent with the existence of PAD(B) and the size of B in the test vectors, so the context hints at proper brackets, but this may still lead to implementation errors (of which I actually ran into an example).

Paul Wouters (AD): This errata is correct, but note that this RFC is applicable only for TLS < 1.3. For TLS 1.3, one needs to use a PAKE as replacement, such as those defined in RFC8492. As such, this errata is left as Verified as there won't be a document update for this document.

Errata ID: 7538
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mingye Wang
Date Reported: 2023-06-07
Verifier Name: Paul Wouters
Date Verified: 2023-10-11

Section 2.1 says:

 The version of SRP used here is sometimes referred to as "SRP-6"
   [SRP-6].

It should say:

 The version of SRP used here is sometimes referred to as "SRP-6a"
   [SRP-6a].


 [SRP-6a]: Wu, T., "SRP Protocol Design", circa 2005, http://srp.stanford.edu/design.html

Notes:

The protocol described uses a non-constant k, which is an innovation of SRP-6a -- never published formally in a technical report (until this RFC) and dating to ~2005 if we go by the libsrp version history. Actual [SRP-6] of 2002 uses a constant k = 3.

Reference to the [SRP-6] text is still valuable for rationale, but is not accurate. Confusion between these two versions is harmful and may impeded interoperability.

RFC 5058, "Explicit Multicast (Xcast) Concepts and Options", November 2007

Source of RFC: INDEPENDENT

Errata ID: 1205
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-02
Verifier Name: Nevil Brownlee
Date Verified: 2010-04-19

Section 3 says:

[1075]

It should say:

[1075][3973]

Notes:

In the second bullet in the lower part of page 7, the RFC refers to
dense-mode multicast routing protocols. Beyond the dated RFC 1075,
it should mention the state-of-the-art Dense-Mode PIM (PIM-DM), published
in RFC 3973.
A proper entry [3973] needs to be added to Section 16 as well.

That will be
[3973] Adams, A, Nicholas, J and Siadak, W., "Protocol Independent Multicast -
Dense Mode (PIM-DM): Protocol Specification (Revised)," RFC 3973,
January 2005

Errata ID: 1206
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-02
Verifier Name: Nevil Brownlee
Date Verified: 2010-04-19

Section 9.2.2 says:

   The Xcast4 header is format depicted in Figure 4.  [...]

It should say:

   The Xcast4 header format is depicted in Figure 4.  [...]

Notes:

Word twister.

Errata ID: 1208
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-02
Verifier Name: Nevil Brownlee
Date Verified: 2010-04-19

Section 9.2.2 ff. says:

     0               1               2               3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | [...]                                                         | 

It should say:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | [...]                                                         |

Notes:

The ruler line on top of Figure 4 (page 18) is garbled.
The figures should be centered to the bit positions, as usual;
the ten's digits need decade alignment; someone must have confused
that with octet numbering.
The same correction needs to be applied to
o Figure 5 in the same section (mid-page 19),
o Figure 6 in Section 9.3.2.1 (top of page 21),
o Figure 7 in Section 9.3.2.2 (top of page 22).

Note to RFC-Ed.: This issue looks like an influenza virus,
it has already affected multiple recent RFCs!

RFC 5059, "Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)", January 2008

Note: This RFC has been updated by RFC 8736, RFC 9436

Source of RFC: pim (rtg)

Errata ID: 1321
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-02-14
Verifier Name: Adrian Farrel
Date Verified: 2011-08-18

Section 3.1, 3rd par says:

   In a scoped IPv4 BSM, the scope of the message is given by the first
   group range in the message, which can be any sub-range of 224/4.  [...]

It should say:

   In a scoped IPv4 BSM, the scope of the message is given by the first
|  group range in the message, which can be any sub-range of 224.0.0.0/4.
   [...]

Notes:

Location is 3rd paragraph of Section 3.1, on mid-page 9.
This correction also needs to be applied to "224/4" in the
7th paragraph of Section 3.3, on mid-page 19.
Rationale:
The basic "strategic" document for CIDR notation now is BCP 122,
RFC 4632, and that document clearly states (in section 3.1, at
the bottom of page 5):
vvvvvvv
| [...] In CIDR notation, a prefix is shown as a 4-octet
quantity, just like a traditional IPv4 address or network number,
followed by the "/" (slash) character, followed by a decimal value
between 0 and 32 that describes the number of significant bits.

As a Standards-Track document, RFC 5059 should follow this rule.

Errata ID: 1322
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-02-14
Verifier Name: Adrian Farrel
Date Verified: 2011-08-18

Section 4.1, pg.29 says:

   Frag RP Cnt 1..m

It should say:

   Frag RP Cnt 1..n

Notes:

This is a legacy issue inherited from RFC 2362.

In section 4.1, 'n' is used for the number of group range blocks
in the Bootstrap Message,
'm' is used for the number of RP Address sub-blocks within each
group range block.

'Frag RP Cnt' is a group range block level parameter and hence
needs indexing in the range 1..n .

Further, the reader should be cautious regarding the use of 'm':
In the diagram of the Bootstrap Message 'fragment' on pg. 27-28,
'm' is used in two contexts, but these are independent instances,
which better had been named differently, or indexed with the
group range block index i = 1..n ; on page 27, 'm' is the value of
the 'Frg RP Cnt 1' field and might better be designated as 'm_1',
while on page 28, 'm' is the value of the 'Frg RP Cnt n' field
and accordingly might better have been designated as 'm_n'.
In the corresponding field explanations on page 29, the remaining
3 instances of 'm' should better be replaced by 'm_i' for clarity:

RP address 1..m --> RP address 1..m_i

RP1..m Holdtime --> RP 1..m_i Holdtime

RP1..m Priority --> RP 1..m_i Priority

Purists would perhaps insist on having the additional (major)
index 'i' prepended to the running index '1..m_i' in all these
field names, as well.

RFC 5060, "Protocol Independent Multicast MIB", January 2008

Source of RFC: pim (rtg)

Errata ID: 1449
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-06-14
Verifier Name: Adrian Farrel
Date Verified: 2011-09-28

Section 5, pg.49 ff. says:

...

pimSGIJoinPruneState OBJECT-TYPE
    SYNTAX     INTEGER {
|                 noInfo (1),
|                 join (2),
|                 prunePending (3)
               }
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION
            "The state resulting from (S,G) Join/Prune messages
|           received on this interface.  This corresponds to the state
|           of the downstream per-interface (S,G) state machine in the
|           PIM-SM and PIM-DM specification."
    REFERENCE "RFC 4601 section 4.5.3 and RFC 3973 section 4.4.2"
    ...

...

It should say:

pimSGIJoinPruneState OBJECT-TYPE
    SYNTAX     INTEGER {
                  noInfo (1),
                  join (2),
                  prunePending (3),
                  pruned (4)
               }
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION
            "The state resulting from (S,G) Join/Prune messages
            received on this interface.  This corresponds to the state
            of the downstream per-interface (S,G) state machine in the
            PIM-SM and PIM-DM specification."
    REFERENCE "RFC 4601 section 4.5.3 and RFC 3973 section 4.4.2"
    ::= { pimSGIEntry 4 }

Notes:

A fourth state is added to allow for the reporting of pruned state in PIM-DM.

RFC 5065, "Autonomous System Confederations for BGP", August 2007

Source of RFC: idr (rtg)

Errata ID: 3791
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramakrishna DTV
Date Reported: 2013-11-08
Verifier Name: Stewart Bryant
Date Verified: 2014-01-16

Section 7 says:

   Additionally, confederations (as well as route reflectors), by
   excluding different reachability information from consideration at
   different locations in a confederation, have been shown [RFC3345] to
   cause permanent oscillation between candidate routes when using the
   tie-breaking rules required by BGP [BGP-4].

It should say:

   Additionally, confederations (as well as route reflectors), by
   excluding different reachability information from consideration at
   different locations in a confederation, have been shown [RFC3345] to
   cause persistent oscillation between candidate routes when using the
   tie-breaking rules required by BGP [BGP-4].

Notes:

s/permanent/persistent

RFC 3345 nowhere refers to this oscillation as "permanent". It consistently refers to it as "persistent" only.

"Permanent" is a much stronger word than "persistent", and I believe is not applicable here.

RFC 5075, "IPv6 Router Advertisement Flags Option", November 2007

Note: This RFC has been obsoleted by RFC 5175

Source of RFC: ipv6 (int)

Errata ID: 1351
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Thomas Narten
Date Reported: 2008-02-29
Verifier Name: Bob Hinden
Date Verified: 2008-02-29

Section 4 says:

   o  Type - TBD (to be assigned by IANA)

It should say:

   o  Type - 26

RFC 5085, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", December 2007

Note: This RFC has been updated by RFC 5586

Source of RFC: pwe3 (int)

Errata ID: 4693
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Carlos Pignataro
Date Reported: 2016-05-13
Verifier Name: Deborah Brungard
Date Verified: 2016-07-12

Section 8.3.1 says:

8.3.1.  Control Message Attribute Value Pairs (AVPs)

   An additional AVP Attribute is specified in Section 6.3.1.  It was
   defined by IANA as described in Section 2.2 of [RFC3438].

It should say:

8.3.1.  Control Message Attribute Value Pairs (AVPs)

   An additional AVP Attribute is specified in Section 6.3.1.  It was
   defined by IANA as described in Section 2.1 of [RFC3438].

Notes:

The correct section of RFC 3438 is 2.1 instead of 2.2

RFC 5087, "Time Division Multiplexing over IP (TDMoIP)", December 2007

Source of RFC: pwe3 (int)

Errata ID: 1215
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-03
Verifier Name: Stewart Bryant
Date Verified: 2011-08-04

Section 6, 7th para says:

   When the L flag is set there are four possibilities for treatment of
   payload content.  The default is for IWF1 to fill the payload with
   the appropriate amount of AIS (usually all-ones) data.  If the AIS
   has been generated before the IWF this can be accomplished by copying
   the received TDM data; if the penultimate TDM link fails and the IWF
   needs to generate the AIS itself.  [...]

It should say:

   When the L flag is set there are four possibilities for treatment of
   payload content.  The default is for IWF1 to fill the payload with
   the appropriate amount of AIS (usually all-ones) data.  If the AIS
   has been generated before the IWF this can be accomplished by copying
|  the received TDM data; if the penultimate TDM link fails, the IWF 
   needs to generate the AIS itself.  [...]
                                                           ^^^^^^

RFC 5088, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", January 2008

Note: This RFC has been updated by RFC 9353

Source of RFC: pce (rtg)

Errata ID: 1266
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-13
Verifier Name: Adrian Farrel
Date Verified: 2010-01-02

Section 4.4, 2nd par says:

|  A PCED sub-TLV may include several NEIG-PCE-DOMAIN sub-TLVs when the
   PCE can compute paths towards several neighbor PCE-Domains.

It should say:

|  A PCED TLV may include several NEIG-PCE-DOMAIN sub-TLVs when the PCE
   can compute paths towards several neighbor PCE-Domains.

Notes:

In OSPF, PCED is a TLV, not a sub-TLV, as clearly stated
in this RFC. All other occurrences of 'PCED' in the RFC
indeed correctly use 'TLV'.

Errata ID: 6459
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: tom petch
Date Reported: 2021-03-08
Verifier Name: John Scudder
Date Verified: 2021-03-25

Section 7.2 says:

   This document provides new capability bit flags, which are present in
   the PCE-CAP-FLAGS TLV referenced in Section 4.1.5.

It should say:

   This document provides new capability bit flags, which are present in
   the PCE-CAP-FLAGS TLV referenced in Section 4.5.

Notes:

There is no Section 4.1.5.

RFC 5090, "RADIUS Extension for Digest Authentication", February 2008

Source of RFC: radext (sec)

Errata ID: 5115
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Denis Ovsienko
Date Reported: 2017-09-14
Verifier Name: Benoit Claise
Date Verified: 2017-09-15

Section 3 says:

3.17.  Digest-Domain Attribute
[...]
   Length
         3
[...]

3.18.  Digest-Stale Attribute
[...]
   Length
         3

It should say:

3.17.  Digest-Domain Attribute
[...]
   Length
         >= 3
[...]

3.18.  Digest-Stale Attribute
[...]
   Length
         >= 3

Notes:

Those two attributes contain string values. All other such attributes in Section 3 uniformly define Length >= 3.

RFC 5091, "Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems", December 2007

Note: This RFC has been updated by RFC 8996

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 2736
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: David Núñez (University of Málaga)
Date Reported: 2011-02-27
Verifier Name: Sean Turner
Date Verified: 2011-07-25

Section 4.1.1 says:

Last line of the algorithm:

5. Let v = v_1 (mod n)

It should say:

5. Let v = v_2 (mod n)

Notes:

With the actual version of the RFC, the output of the algorithm 4.1.1 with the test cases input is v = 5ab5b7a6d72fa91bd01df98e29afb77f05e7b880, which doesn't correspond with the expected output.

However, with the correction, the output is correct:
v = 79317c1610c1fc018e9c53d89d59c108cd518608

Errata ID: 2738
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: David Núñez (University of Málaga)
Date Reported: 2011-02-27
Verifier Name: Sean Turner
Date Verified: 2011-07-25

Section 4.1.1 says:

The input n MUST 
be less than 2^(hashlen), where hashlen is the number of octets 
comprising the output of the hash function hashfcn. 

It should say:

The input n MUST 
be less than 256^(hashlen), where hashlen is the number of octets 
comprising the output of the hash function hashfcn.

Notes:

Since hashlen is the output size in bytes of the hash function, the correct limit is 256^hashlen.

Errata ID: 2739
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: David Núñez (University of Málaga)
Date Reported: 2011-02-27
Verifier Name: Sean Turner
Date Verified: 2011-07-25

Section 4.2.1 says:

The value of b MUST be less than 
or equal to the number of bytes in the output of hashfcn

It should say:

The value of b MUST be greater than 
or equal to the number of bytes in the output of hashfcn

Notes:

If b is less than or equal to hashlen, then the result of the fourth step of the algorithm would always be 1, since the division will result in a number between 0 and 1.

Errata ID: 3228
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Richard Heylen
Date Reported: 2012-05-18
Verifier Name: Sean Turner
Date Verified: 2012-07-18

Section 3.5.2. says:

(x_V /z_V^2, s * x_V / z_V^3) in (F_p)^2,

It should say:

(x_V /z_V^2, s * y_V / z_V^3) in (F_p)^2,

Errata ID: 3229
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Richard Heylen
Date Reported: 2012-05-18
Verifier Name: Sean Turner
Date Verified: 2012-07-18

Section 2.1 says:

a * b = ((a_1 * b_1 - a_0 * b_0)(mod p),

It should say:

a * b = ((a_0 * b_0 - a_1 * b_1)(mod p),

RFC 5092, "IMAP URL Scheme", November 2007

Note: This RFC has been updated by RFC 5593

Source of RFC: lemonade (app)

Errata ID: 1802
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tony Hansen
Date Reported: 2009-07-06
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-06

Section 9 says:

   If the following relative URL is located in that body part:

      <;section=1.4>

   this could result in the following client commands:

    C: A004 UID FETCH 20 (BODY.PEEK[1.2.MIME]
                                      ^
           BODY.PEEK[1.MIME]
           BODY.PEEK[HEADER.FIELDS (Content-Location)])

It should say:

   If the following relative URL is located in that body part:

      <;section=1.4>

   this could result in the following client commands:

    C: A004 UID FETCH 20 (BODY.PEEK[1.4.MIME]
                                      ^
           BODY.PEEK[1.MIME]
           BODY.PEEK[HEADER.FIELDS (Content-Location)])

Notes:

1.2.MIME should read 1.4.MIME

Errata ID: 1091
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alexey Melnikov
Date Reported: 2007-12-10
Verifier Name: Alexey Melnikov
Date Verified: 2009-06-19

Section 7 says:

[URI-GEN] defines four forms of relative URLs: <inetwork-path>,
<iabsolute-path>, <irelative-path>, and <ipath-empty>.  Their syntax
is defined in Section 11.

It should say:

[URI-GEN] defines four forms of relative URLs: <network-path>,
<absolute-path>, <relative-path>, and <path-empty>.  This document
introduces more restricted, IMAP-specific syntax corresponding to
these non-terminals, <inetwork-path>, <iabsolute-path>,
<irelative-path>, and <ipath-empty>.  Their syntax is defined
in Section 11.

Notes:

[URI-GEN] doesn't define <inetwork-path>, <iabsolute-path>, <irelative-path>, and <ipath-empty>, they are defined in the RFC 5092.

The issue was identified by Alfred Hœnes <ah@tr-sys.de>, he also suggested the new text.

Errata ID: 1092
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alexey Melnikov
Date Reported: 2007-12-10
Verifier Name: Alexey Melnikov
Date Verified: 2009-06-19

In Appendix A, it says:

/* Copyright (C) The IETF Trust (2007).  This version of
   sample C code is part of RFC XXXX; see the RFC itself
   for full legal notices.

   Regarding this sample C code (or any portion of it), the authors
   make no guarantees and are not responsible for any damage
   resulting from its use.  The authors grant irrevocable permission
   to anyone to use, modify, and distribute it in any way that does
   not diminish the rights of anyone else to use, modify, and
   distribute it, provided that redistributed derivative works do
   not contain misleading author or version information.

   Derivative works need not be licensed under similar terms.
 */

It should say:

/* Copyright (C) The IETF Trust (2007).  This version of
   sample C code is part of RFC 5092; see the RFC itself
   for full legal notices.

   Regarding this sample C code (or any portion of it), the authors
   make no guarantees and are not responsible for any damage
   resulting from its use.  The authors grant irrevocable permission
   to anyone to use, modify, and distribute it in any way that does
   not diminish the rights of anyone else to use, modify, and
   distribute it, provided that redistributed derivative works do
   not contain misleading author or version information.

   Derivative works need not be licensed under similar terms.
 */

Notes:

Changed RFC XXXX to RFC 5092.

The issue was reported by Alfred Hœnes <ah@tr-sys.de>.

Errata ID: 6598
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: queila
Date Reported: 2021-06-05
Verifier Name: Orie Steele
Date Verified: 2024-04-01

Section 7 says:

[URI-GEN] defines four forms of relative URLs: <inetwork-path>,
<iabsolute-path>, <irelative-path>, and <ipath-empty>.  Their syntax
is defined in Section 11.

It should say:

[URI-GEN] defines four forms of relative URLs: <network-path>,
<absolute-path>, <relative-path>, and <path-empty>.  This document
introduces more restricted, IMAP-specific syntax corresponding to
these non-terminals, <inetwork-path>, <iabsolute-path>,
<irelative-path>, and <ipath-empty>.  Their syntax is defined
in Section 11.

Notes:

[URI-GEN] doesn't define <inetwork-path>, <iabsolute-path>, <irelative-path>, and <ipath-empty>, they are defined in the RFC 5092.

The issue was identified by Alfred Hœnes <ah@tr-sys.de>, he also suggested the new text.

RFC 5101, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", January 2008

Note: This RFC has been obsoleted by RFC 7011

Source of RFC: ipfix (ops)

Errata ID: 1655
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2009-01-20
Verifier Name: Dan Romascanu
Date Verified: 2009-02-18

Section A.4.4. says:

   Line Card ID               | IPFIX Message  | Exported Flow Records
   -------------------------------------------------------------------
   Line Card 1 (lineCardId=1) | 345            | 10201
   Line Card 2 (lineCardId=2) | 690            | 20402

It should say:

   Enterprise field 123 | exportedPacketCount | exportedFlowCount
   -------------------------------------------------------------------
   1                    | 345                 | 10201
   2                    | 690                 | 20402

Notes:

The example in A.4.4 uses set ID 260 which is defined in the template in A.4.3.
Therefore the fields used in A.4.4 must be those defined in A.4.3.
Fortunately the field lengths are correct, so no other change is required.

Errata ID: 2791
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Adrian Farrel
Date Reported: 2011-04-28
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02

Section 7 says:

   If the length of the Information Element is greater than or equal to
   255 octets, the length is encoded into 3 octets before the
   Information Element.  The first octet is 255, and the length is
   carried in the second and third octets, as shown in Figure S.

It should say:

   The length may also be encoded into 3 octets before the Information
   element allowing the length of the Information Element to be
   greater than or equal to 255 octets. In this case, first octet of
   the Lenght field MUST be 255, and the length is carried in the 
   second and third octets, as shown in Figure S.

Notes:

The original text is ambiguous as to whether it is possible to carry a length of less than 255 encoded in a 3 octet Length field. The quoted text seems to say it is not allowed, but Figure S says that the 2nd and 3rd octets may be set to "Length (0 to 65535)".

Since there is absolutely no harm (except a little inefficiency) in using a 3 octet Length field to encode a small length, the document should be clarified to remove the ambiguity.

Errata ID: 2814
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Brian Trammell
Date Reported: 2011-05-24
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02

Section 4.1 says:

   exportedFlowTotalCount
                           The total number of Flow Records that the
                           Exporting Process successfully sent to the
                           Collecting Process since the Exporting
                           Process re-initialization.

It should say:

   exportedFlowRecordTotalCount
                           The total number of Flow Records that the
                           Exporting Process successfully sent to the
                           Collecting Process since the Exporting
                           Process re-initialization.

Notes:

The exportedFlowRecordTotalCount Information Element (42) is incorrectly referenced in the text in this section as exportedFlowTotalCount.

Errata ID: 1818
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Benoit Claise
Date Reported: 2009-07-26
Verifier Name: Dan Romascanu
Date Verified: 2009-08-02

Section All says:

Notes:

Throughout the document, all instances of "Option Template" must be replaced by "Options Template"

Errata ID: 2792
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Adrian Farrel
Date Reported: 2011-04-28
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02

Section A.5.2 says:

A.5.2.  Example of Variable-Length Information Element with Length 255
        to 65535 Octets

It should say:

A.5.2.  Example of Variable-Length Information Element with 3 Octet
        Length Encoding

Notes:

Per Erratum 2791, this section header should be changed to reflect that the 3 octet Lenght encoding supports lengths of less than 255 as well as greater than or equal to 255.

Note that there is a corresponding change in the Table of Contents

Errata ID: 2888
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02

Section 6.1.7 says:

6.1.7.  dateTimeSeconds

   The data type dateTimeseconds represents a time value in units of
   seconds normalized to the GMT timezone.  It MUST be encoded in a
   32-bit integer containing the number of seconds since 0000 UTC Jan 1,
   1970.  The 32-bit integer allows the time encoding up to 136 years.

It should say:

6.1.7.  dateTimeSeconds

   The data type dateTimeSeconds represents a time value in units of
   seconds normalized to the GMT timezone.  It MUST be encoded in a
   32-bit integer containing the number of seconds since 0000 UTC Jan 1,
   1970.  The 32-bit integer allows the time encoding up to 136 years.

Notes:

s/dateTimeseconds/dateTimeSeconds/

- per the section title, the definition in IANA's IPFIX registry, and usage in other IPFIX RFCs.

Errata ID: 2889
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02

Section multiple says:

exportedFlowCount

It should say:

exportedFlowRecordTotalCount

Notes:

s/exportedFlowCount/exportedFlowRecordTotalCount/ (four times)

- in sections A.4.1 (+figure), and A.4.3 (+figure).

The definition in [RFC5102] and IANA's IPFIX registry is "exportedFlowRecordTotalCount" (as correctly used elsewhere in this RFC).

Errata ID: 2890
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02

Section multiple says:

exportedPacketCount

It should say:

exportedMessageTotalCount

Notes:

s/exportedPacketCount/exportedMessageTotalCount/ (six times)

- in sections A.4.1 (+figure), A.4.2 (+figure), and A.4.3 (+figure).

[RFC5102] defines exportedMessageTotalCount, exportedOctetTotalCount, and exportedFlowRecordTotalCount - but no "exportedPacketCount".

Presumably "exportedMessageTotalCount" is the name that's intended here.

Errata ID: 2891
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02

Section multiple says:

inOctetDeltaCount

It should say:

octetDeltaCount

Notes:

s/inOctetDeltaCount/octetDeltaCount/ (four times)

- in sections A.2.1 (+figure) and A.2.2 (+figure)

Per [RFC5102] and IANA's IPFIX registry, the correct name is "octetDeltaCount".

Errata ID: 2892
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02

Section multiple says:

inPacketDeltaCount

It should say:

packetDeltaCount

Notes:

s/inPacketDeltaCount/packetDeltaCount/ (four times)

- in sections A.2.1 (+figure) and A.2.2 (+figure)

Per [RFC5102] and IANA's IPFIX registry, the correct name is "packetDeltaCount".

Errata ID: 2903
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02

Section 6.1.6 says:

6.1.6.  string and octetarray

   The data type string represents a finite length string of valid
   characters of the Unicode character encoding set.  The string data
   type MUST be encoded in UTF-8 format.  The string is sent as an array
   of octets using an Information Element of fixed or variable length.

   The length of the Information Element specifies the length of the
   octetarray.

It should say:

6.1.6.  string and octetArray

   The data type string represents a finite length string of valid
   characters of the Unicode character encoding set.  The string data
   type MUST be encoded in UTF-8 format.  The string is sent as an array
   of octets using an Information Element of fixed or variable length.

   The length of the Information Element specifies the length of the
   octetArray.

Notes:

s/octetarray/octetArray/ (twice).

Also in section 6.2:
"Information Elements containing integer, string, float, and
octetarray types in the information model ..."

Per RFC5102 and IANA's IPFIX registry, the correct name is "octetArray".

RFC 5102, "Information Model for IP Flow Information Export", January 2008

Note: This RFC has been obsoleted by RFC 7012

Note: This RFC has been updated by RFC 6313

Source of RFC: ipfix (ops)

Errata ID: 1307
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: RFC Editor
Date Reported: 2008-02-04
Verifier Name: Dan Romascanu
Date Verified: 2008-02-04

Section 7.3 says:

*  URI: urn:ietf:params:xml:ns:ipfix-info-15

  ...

*  URI: urn:ietf:params:xml:schema:ipfix-info-15

It should say:

*  URI: urn:ietf:params:xml:ns:ipfix-info

  ...

*  URI: urn:ietf:params:xml:schema:ipfix-info

Notes:

Discovered by Pearl Liang of IANA.

Errata ID: 1492
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Simon Perreault
Date Reported: 2008-08-21
Verifier Name: Dan Romascanu
Date Verified: 2009-08-03

Section Appendix A says:

         See RFC 793 for the definition of the TCP
         source port field.

It should say:

         See RFC 793 for the definition of the TCP
         destination port field.

Notes:

This is for elementId="183".

Errata ID: 1736
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2009-03-24
Verifier Name: Dan Romascanu
Date Verified: 2009-08-02

Section 5.4.22. says:

            0      1      2      3      4      5      6      7
         +------+------+------+------+------+------+------+------+
         | MCv4 | RES. | RES. |  T   |   IPv6 multicast scope    |
         +------+------+------+------+------+------+------+------+

It should say:

            0      1      2      3      4      5      6      7
         +------+------+------+------+------+------+------+------+
         |   IPv6 multicast scope    |  T   | RES. | RES. | MCv4 |
         +------+------+------+------+------+------+------+------+

Notes:

The diagram is back to front.

Errata ID: 1737
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2009-03-24
Verifier Name: Dan Romascanu
Date Verified: 2009-08-02

Section 5.8.5. says:

           0      1      2      3      4      5      6      7
       +------+------+------+------+------+------+------+------+
       | EOOL | NOP  | SEC  | LSR  |  TS  |E-SEC |CIPSO |  RR  | ...
       +------+------+------+------+------+------+------+------+

           8      9     10     11     12     13     14     15
       +------+------+------+------+------+------+------+------+
   ... | SID  | SSR  | ZSU  | MTUP | MTUR | FINN | VISA |ENCODE| ...
       +------+------+------+------+------+------+------+------+

          16     17     18     19     20     21     22     23
       +------+------+------+------+------+------+------+------+
   ... |IMITD | EIP  |  TR  |ADDEXT|RTRALT| SDB  |NSAPA | DPS  | ...
       +------+------+------+------+------+------+------+------+

          24     25     26     27     28     29     30     31
       +------+------+------+------+------+------+------+------+
   ... | UMP  |  QS  |   to be assigned by IANA  |  EXP |      |
       +------+------+------+------+------+------+------+------+

It should say:

           0      1      2      3      4      5      6      7
       +------+------+------+------+------+------+------+------+
       |  RR  |CIPSO |E-SEC |  TS  | LSR  | SEC  | NOP  | EOOL | ...
       +------+------+------+------+------+------+------+------+

           8      9     10     11     12     13     14     15
       +------+------+------+------+------+------+------+------+
   ... |ENCODE| VISA | FINN | MTUR | MTUP | ZSU  | SSR  | SID  | ...
       +------+------+------+------+------+------+------+------+

          16     17     18     19     20     21     22     23
       +------+------+------+------+------+------+------+------+
   ... | DPS  |NSAPA | SDB  |RTRALT|ADDEXT|  TR  | EIP  |IMITD | ...
       +------+------+------+------+------+------+------+------+

          24     25     26     27     28     29     30     31
       +------+------+------+------+------+------+------+------+
   ... |      |  EXP |   to be assigned by IANA  |  QS  | UMP  |
       +------+------+------+------+------+------+------+------+

Notes:

The diagram is back to front.

Errata ID: 1738
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2009-03-24
Verifier Name: Dan Romascanu
Date Verified: 2009-08-02

Section 5.8.6. says:

              0     1     2     3     4     5     6     7
          +-----+-----+-----+-----+-----+-----+-----+-----+
          | Res | FRA1| RH  | FRA0| UNK | Res | HOP | DST |  ...
          +-----+-----+-----+-----+-----+-----+-----+-----+

              8     9    10    11    12    13    14    15
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... | PAY | AH  | ESP |         Reserved            | ...
          +-----+-----+-----+-----+-----+-----+-----+-----+

             16    17    18    19    20    21    22    23
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... |                  Reserved                     | ...
          +-----+-----+-----+-----+-----+-----+-----+-----+

             24    25    26    27    28    29    30    31
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... |                  Reserved                     |
          +-----+-----+-----+-----+-----+-----+-----+-----+

It should say:

             0     1     2     3     4     5     6     7
          +-----+-----+-----+-----+-----+-----+-----+-----+
          | DST | HOP | Res | UNK | FRA0| RH  | FRA1| Res |  ...
          +-----+-----+-----+-----+-----+-----+-----+-----+

              8     9    10    11    12    13    14    15
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... |         Reserved            | ESP | AH  | PAY |...
          +-----+-----+-----+-----+-----+-----+-----+-----+

             16    17    18    19    20    21    22    23
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... |                  Reserved                     | ...
          +-----+-----+-----+-----+-----+-----+-----+-----+

             24    25    26    27    28    29    30    31
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... |                  Reserved                     |
          +-----+-----+-----+-----+-----+-----+-----+-----+

Notes:

The diagram is back to front.

Errata ID: 1739
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2009-03-24
Verifier Name: Dan Romascanu
Date Verified: 2009-08-02

Section 5.8.8. says:

              0     1     2     3     4     5     6     7
          +-----+-----+-----+-----+-----+-----+-----+-----+
          |   0 |   1 |   2 |   3 |   4 |   5 |   6 |   7 |  ...
          +-----+-----+-----+-----+-----+-----+-----+-----+

              8     9    10    11    12    13    14    15
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... |   8 |   9 |  10 |  11 |  12 |  13 |  14 |  15 |...
          +-----+-----+-----+-----+-----+-----+-----+-----+

             16    17    18    19    20    21    22    23
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... |  16 |  17 |  18 |  19 |  20 |  21 |  22 |  23 |...
          +-----+-----+-----+-----+-----+-----+-----+-----+

                                . . .

             56    57    58    59    60    61    62    63
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... |  56 |  57 |  58 |  59 |  60 |  61 |  62 |  63 |
          +-----+-----+-----+-----+-----+-----+-----+-----+

It should say:

              0     1     2     3     4     5     6     7
          +-----+-----+-----+-----+-----+-----+-----+-----+
          |   7 |   6 |   5 |   4 |   3 |   2 |   1 |   0 |  ...
          +-----+-----+-----+-----+-----+-----+-----+-----+

              8     9    10    11    12    13    14    15
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... |  15 |  14 |  13 |  12 |  11 |  10 |   9 |   8 |...
          +-----+-----+-----+-----+-----+-----+-----+-----+

             16    17    18    19    20    21    22    23
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... |  23 |  22 |  21 |  20 |  19 |  18 |  17 |  16 |...
          +-----+-----+-----+-----+-----+-----+-----+-----+

                                . . .

             56    57    58    59    60    61    62    63
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... |  63 |  62 |  61 |  60 |  59 |  58 |  57 |  56 |
          +-----+-----+-----+-----+-----+-----+-----+-----+

Notes:

The diagram is back to front.

Errata ID: 2944
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-22
Verifier Name: Dan Romascanu
Date Verified: 2011-08-22

Section 5.8.5 says:

           0      1      2      3      4      5      6      7
       +------+------+------+------+------+------+------+------+
       | EOOL | NOP  | SEC  | LSR  |  TS  |E-SEC |CIPSO |  RR  | ...
       +------+------+------+------+------+------+------+------+

           8      9     10     11     12     13     14     15
       +------+------+------+------+------+------+------+------+
   ... | SID  | SSR  | ZSU  | MTUP | MTUR | FINN | VISA |ENCODE| ...
       +------+------+------+------+------+------+------+------+

          16     17     18     19     20     21     22     23
       +------+------+------+------+------+------+------+------+
   ... |IMITD | EIP  |  TR  |ADDEXT|RTRALT| SDB  |NSAPA | DPS  | ...
       +------+------+------+------+------+------+------+------+

          24     25     26     27     28     29     30     31
       +------+------+------+------+------+------+------+------+
   ... | UMP  |  QS  |   to be assigned by IANA  |  EXP |      |
       +------+------+------+------+------+------+------+------+

It should say:

           0      1      2      3      4      5      6      7
       +------+------+------+------+------+------+------+------+
       |      |  EXP |   to be assigned by IANA  |  QS  | UMP  | ...
       +------+------+------+------+------+------+------+------+


           8      9     10     11     12     13     14     15
       +------+------+------+------+------+------+------+------+
   ... | DPS  |NSAPA | SDB  |RTRALT|ADDEXT|  TR  | EIP  |IMITD | ...
       +------+------+------+------+------+------+------+------+


          16     17     18     19     20     21     22     23
       +------+------+------+------+------+------+------+------+
   ... |ENCODE| VISA | FINN | MTUR | MTUP | ZSU  | SSR  | SID  | ...
       +------+------+------+------+------+------+------+------+


          24     25     26     27     28     29     30     31
       +------+------+------+------+------+------+------+------+
   ... |  RR  |CIPSO |E-SEC |  TS  | LSR  | SEC  | NOP  | EOOL |
       +------+------+------+------+------+------+------+------+

Notes:

The bits were originally shown in the wrong order.

Errata 1737 tried to correct this by reversing the bits, but overlooked reversing the bytes.

Note that the network bit numbering in the figure is exactly the reverse of the "Bit" value in the following table.

Errata ID: 2945
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-22
Verifier Name: Dan Romascanu
Date Verified: 2011-08-22

Section 5.8.6 says:

              0     1     2     3     4     5     6     7
          +-----+-----+-----+-----+-----+-----+-----+-----+
          | Res | FRA1| RH  | FRA0| UNK | Res | HOP | DST |  ...
          +-----+-----+-----+-----+-----+-----+-----+-----+

              8     9    10    11    12    13    14    15
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... | PAY | AH  | ESP |         Reserved            | ...
          +-----+-----+-----+-----+-----+-----+-----+-----+

             16    17    18    19    20    21    22    23
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... |                  Reserved                     | ...
          +-----+-----+-----+-----+-----+-----+-----+-----+

             24    25    26    27    28    29    30    31
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... |                  Reserved                     |
          +-----+-----+-----+-----+-----+-----+-----+-----+

It should say:

             0     1     2     3     4     5     6     7
          +-----+-----+-----+-----+-----+-----+-----+-----+
          |                  Reserved                     | ...
          +-----+-----+-----+-----+-----+-----+-----+-----+

              8     9    10    11    12    13    14    15
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... |                  Reserved                     | ...
          +-----+-----+-----+-----+-----+-----+-----+-----+

             16    17    18    19    20    21    22    23
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... |         Reserved            | ESP | AH  | PAY | ...
          +-----+-----+-----+-----+-----+-----+-----+-----+

             24    25    26    27    28    29    30    31
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... | DST | HOP | Res | UNK | FRA0| RH  | FRA1| Res |
          +-----+-----+-----+-----+-----+-----+-----+-----+

Notes:

The bits were originally shown in the wrong order.

Errata 1738 tried to correct this by reversing the bits, but overlooked reversing the bytes.

Note that the network bit numbering in the figure is exactly the reverse of the "Bit" value in the following table.

Errata ID: 2946
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-22
Verifier Name: Dan Romascanu
Date Verified: 2011-08-22

Section 5.8.8 says:

              0     1     2     3     4     5     6     7
          +-----+-----+-----+-----+-----+-----+-----+-----+
          |   0 |   1 |   2 |   3 |   4 |   5 |   6 |   7 |  ...
          +-----+-----+-----+-----+-----+-----+-----+-----+

              8     9    10    11    12    13    14    15
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... |   8 |   9 |  10 |  11 |  12 |  13 |  14 |  15 |...
          +-----+-----+-----+-----+-----+-----+-----+-----+

             16    17    18    19    20    21    22    23
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... |  16 |  17 |  18 |  19 |  20 |  21 |  22 |  23 |...
          +-----+-----+-----+-----+-----+-----+-----+-----+

                                . . .

             56    57    58    59    60    61    62    63
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... |  56 |  57 |  58 |  59 |  60 |  61 |  62 |  63 |
          +-----+-----+-----+-----+-----+-----+-----+-----+

It should say:

              0     1     2     3     4     5     6     7
          +-----+-----+-----+-----+-----+-----+-----+-----+
          |  63 |  62 |  61 |  60 |  59 |  58 |  57 |  56 |  ...
          +-----+-----+-----+-----+-----+-----+-----+-----+

              8     9    10    11    12    13    14    15
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... |  55 |  54 |  53 |  52 |  51 |  50 |  49 |  48 |...
          +-----+-----+-----+-----+-----+-----+-----+-----+

             16    17    18    19    20    21    22    23
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... |  47 |  46 |  45 |  44 |  43 |  42 |  41 |  40 |...
          +-----+-----+-----+-----+-----+-----+-----+-----+

                                . . .

             56    57    58    59    60    61    62    63
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... |   7 |   6 |   5 |   4 |   3 |   2 |   1 |   0 |
          +-----+-----+-----+-----+-----+-----+-----+-----+ 

Notes:

The bits were originally shown in the wrong order.

Errata 1739 tried to correct this by reversing the bits, but overlooked reversing the bytes.

Errata ID: 4984
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2017-03-30
Verifier Name: Benoit Claise
Date Verified: 2017-07-27

Section 5.2.10, appA says:

Each bit represents an Information Element in the Data Record 
with the n-th bit
representing the n-th Information Element.

It should say:

Each bit represents an Information Element in the Data Record,
with the n-th least significant bit
representing the n-th Information Element.

Notes:

A misunderstand arose as to whether bits were assigned in host order or network order - so clarify that the bits are assigned from the least significant to the most significant, ie right-to-left rather than left-to-right.

Moreover, this clarification applies to IANA's IPFIX registry.

NB RFC 8038 re-uses this definition for mibIndexIndicator. Consistency between the definitions is desirable.

Errata ID: 2879
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02

Section 2.3 says:

   o  Middleboxes [RFC3234] may change Flow properties, such as the
      Differentiated Service Code Point (DSCP) value or the source IP
      address.  If an IPFIX Observation Point is located in the path of
      a Flow before one or more middleboxes that potentially modify
      packets of the Flow, then it may be desirable to also report Flow
      properties after the modification performed by the middleboxes.
      An example is an Observation Point before a packet marker changing
      a packet's IPv4 Type of Service (TOS) field that is encoded in
      Information Element classOfServiceIPv4.  Then the value observed
      and reported by Information Element classOfServiceIPv4 is valid at
      the Observation Point, but not after the packet passed the packet
      marker.  For reporting the change value of the TOS field, the
      IPFIX information model uses Information Elements that have a name
      prefix "post", for example, "postClassOfServiceIPv4".

It should say:

   o  Middleboxes [RFC3234] may change Flow properties, such as the
      Differentiated Service Code Point (DSCP) value or the source IP
      address.  If an IPFIX Observation Point is located in the path of
      a Flow before one or more middleboxes that potentially modify
      packets of the Flow, then it may be desirable to also report Flow
      properties after the modification performed by the middleboxes.
      An example is an Observation Point before a packet marker changing
      a packet's IPv4 Type of Service (TOS) field that is encoded in
      Information Element ipClassOfService.  Then the value observed
      and reported by Information Element ipClassOfService is valid at
      the Observation Point, but not after the packet passed the packet
      marker.  For reporting the change value of the TOS field, the
      IPFIX information model uses Information Elements that have a name
      prefix "post", for example, "postIpClassOfService".

Notes:

s/ClassOfServiceIPv4/ipClassOfService/ (twice)
s/postClassOfServiceIPv4/postIpClassOfService/ (once)

Also correct another instance of "postClassOfServiceIPv4" in section 5:

OLD
Information Elements with a name having the "post" prefix, for
example, "postClassOfServiceIPv4"
NEW
Information Elements with a name having the "post" prefix, for
example, "postIpClassOfService"
END

RFC 5103, "Bidirectional Flow Export Using IP Flow Information Export (IPFIX)", January 2008

Source of RFC: ipfix (ops)

Errata ID: 2899
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02

Section 4 says:

   The location of the Observation Point(s)
   with respect to the middlebox can be communicated using Options with
   Observation Point as Scope and elements such as lineCardID or
   samplerID.

It should say:

   The location of the Observation Point(s)
   with respect to the middlebox can be communicated using Options with
   Observation Point as Scope and elements such as lineCardId or
   selectorId.

Notes:

s/lineCardID/lineCardId/
s/samplerID/selectorId/

Per the definitions in RFC5102, RFC5477 and IANA's IPFIX registry.

RFC 5106, "The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method", February 2008

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 1338
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-03
Verifier Name: Sean Turner
Date Verified: 2010-07-30

Section 7, pg. 14/15 says:

                                                                  Only
   after receiving message 6, the server SHOULD respond with an
<< page break >>
   authentication failure notification, i.e., a message conforming to
|  message 6 in Figure 10.  The purpose of this behaviour is to prevent
   an adversary from probing the EAP-IKEv2 peer identifier space.

It should say:

                                                                   Only
   after receiving message 6, the server SHOULD respond with an
   authentication failure notification, i.e., a message conforming to
|  message 7 in Figure 10.  The purpose of this behaviour is to prevent
   an adversary from probing the EAP-IKEv2 peer identifier space.

Notes:

Rationale: See Figure 10 in Appendix A (on page 30).

Note: The RFC contains Figure 1..6, 10, and 11, but no Figure 7..9 !

RFC 5116, "An Interface and Algorithms for Authenticated Encryption", January 2008

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 4008
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tapio Sokura
Date Reported: 2014-06-08
Verifier Name: Kathleen Moriarty
Date Verified: 2015-03-31

Section 2.2 says:

   The
   authenticated decrypt operation will, with high probability, return
   FAIL whenever the inputs N, P, and A were crafted by a nonce-
   respecting adversary that does not know the secret key (assuming that
   the AEAD algorithm is secure).

It should say:

   The
   authenticated decrypt operation will, with high probability, return
   FAIL whenever the inputs N, C, and A were crafted by a nonce-
   respecting adversary that does not know the secret key (assuming that
   the AEAD algorithm is secure).

Notes:

Inputs to the authenticated decrypt operation do not include plaintext P, but instead includes ciphertext C.

Thanks for the correction, since this is descriptive text, it will be marked as editorial.

Errata ID: 4268
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Martin Thomson
Date Reported: 2015-02-09
Verifier Name: Kathleen Moriarty
Date Verified: 2015-03-31

Section 3.1 says:

As an example, the nonce 100 could be stored, after which the nonces
1 through 99 could be used for encryption.  The nonce value 200 could
be stored at the same time that nonces 1 through 99 are being used,
and so on.

It should say:

As an example, the nonce 100 could be stored, after which the nonces
1 through 99 could be used for encryption.  Then, nonces 101 to 199
could be used after the nonce 200 was saved.

Notes:

This might be confusing in its original form, maybe even suggesting an interpretation where nonces are reused.

RFC 5118, "Session Initiation Protocol (SIP) Torture Test Messages for Internet Protocol Version 6 (IPv6)", February 2008

Source of RFC: sipping (rai)

Errata ID: 1311
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-02-11
Verifier Name: Cullen Jennings
Date Verified: 2008-04-16

Section 4.3, 1st par says:

                                                  [...], the intended port
   number becomes the last octet of the reference.

It should say:

                                                  [...], the intended port
   number becomes the last octet pair of the reference.

Notes:

Each hexadecimal group in a literal IPv6 address encodes two octets
of the IPv6 address -- cf. RFC 4291 !

RFC 5123, "Considerations in Validating the Path in BGP", February 2008

Source of RFC: INDEPENDENT

Errata ID: 1366
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-13
Verifier Name: Nevil Brownlee
Date Verified: 2012-11-05

Section 1.,last para says:

   Assume a BGP speaker in AS65002 has received an advertisement for
|  10.1.1.0/24 from a BGP speaker in AS65001, with an AS Path of {65000,
|  65001}.

It should say:

   Assume a BGP speaker in AS65002 has received an advertisement for
|  10.1.1.0/24 from a BGP speaker in AS65001, with an AS Path of {65001,
|  65000}.

Notes:

Rationale:
AS Path presentation should consistently follow the common
practice for BGP-4.
RFC 5123 mixes standard and reversed AS Path notation.
To avoid confusion, all reversed AS Path notations should
be corrected.

For clarity, further instances of this issue in Sections 1.2,
1.4, and 2.2 are addressed in separate Errata Notes.

Errata ID: 1367
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-13
Verifier Name: Nevil Brownlee
Date Verified: 2012-11-05

Section 1.2,2nd para says:

   Path validation, in the context of this small internetwork, asserts
   that when a BGP speaker in AS65002 receives an advertisement from a
|  BGP speaker in AS65001 with the AS Path {65000, 65001}, the speaker
   can assume that AS65001 is attached to the local AS, and that AS65001
   is also attached to AS65000.

It should say:

   Path validation, in the context of this small internetwork, asserts
   that when a BGP speaker in AS65002 receives an advertisement from a
|  BGP speaker in AS65001 with the AS Path {65001, 65000}, the speaker
   can assume that AS65001 is attached to the local AS, and that AS65001
   is also attached to AS65000.

Notes:

For rationale, see previous Errata Note.

Errata ID: 1368
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-13
Verifier Name: Nevil Brownlee
Date Verified: 2012-11-05

Section 1.4,2nd para says:

   In terms of the small example internetwork, if a BGP speaker in
   AS65002 receives an advertisement from a peer in AS65001 for the
|  destination 10.1.1.0/24, with an AS Path {65000, 65001}, will traffic
   forwarded to the BGP speaker in AS65001 actually be forwarded through
   routers within AS65001, then AS65000, to reach its destination?

It should say:

   In terms of the small example internetwork, if a BGP speaker in
   AS65002 receives an advertisement from a peer in AS65001 for the
|  destination 10.1.1.0/24, with an AS Path {65001, 65000}, will traffic
   forwarded to the BGP speaker in AS65001 actually be forwarded through
   routers within AS65001, then AS65000, to reach its destination?

Notes:

For rationale, see Errata Note for Section 1

Errata ID: 1369
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-13
Verifier Name: Nevil Brownlee
Date Verified: 2012-11-05

Section 2.2, pg. 5 says:

   A BGP speaker in AS65000 may receive an advertisement from a peer
|  that 10.1.1.0/24 is reachable along the path {65004, 65002, 65001}.
   [...]

It should say:

   A BGP speaker in AS65000 may receive an advertisement from a peer
|  that 10.1.1.0/24 is reachable along the path {65001, 65002, 65004}.
   [...]

Notes:

For rationale, see Errata Note for Section 1.

Errata ID: 1370
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-13
Verifier Name: Nevil Brownlee
Date Verified: 2012-11-05

Section 2.2, pg. 6 says:

a)  first bullet:

   o  Is the AS Path valid?  The AS Path the receiving BGP speaker in
|     AS65000 receives from its peer in AS65001, {65004, 65002, 65001),
      does exist, and is valid.

b)  third bullet:
 
   o  Is the AS Path consistent with the forwarding path (does
      forwarding consistency exist)?  No, the advertised AS Path is
|     {65004, 65002, 65001}, while the actual path is {65004, 65003,
|     65001}.

It should say:

a)  first bullet:

   o  Is the AS Path valid?  The AS Path the receiving BGP speaker in
|     AS65000 receives from its peer in AS65001, {65001, 65002, 65004),
      does exist, and is valid.

b)  third bullet:
 
   o  Is the AS Path consistent with the forwarding path (does
      forwarding consistency exist)?  No, the advertised AS Path is
|     {65001, 65002, 65004}, while the actual path is {65001, 65003,
|     65004}.

Notes:

For rationale, see Errata Note for Section 1, Errata ID: 1366

Errata ID: 1396
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2008-03-30
Verifier Name: Nevil Brownlee
Date Verified: 2012-11-05

Section 2.1 says:

 While
 Dijkstra's Sender Policy Framework (SPF) and the Diffusing Update
 Algorithm (DUAL) both base their loop-free path calculations on the
 cost of a path

It should say:

 While
 Dijkstra's Shortest Path First (SPF) and the Diffusing Update
 Algorithm (DUAL) both base their loop-free path calculations on the
 cost of a path

Notes:

This confusion with RFC 4408 is funny :-)

RFC 5134, "A Uniform Resource Name Namespace for the EPCglobal Electronic Product Code (EPC) and Related Standards", January 2008

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 1325
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-02-16
Verifier Name: Alexey Melnikov
Date Verified: 2010-11-12

Section 2, pg. 4 says:

   Rules for Lexical Equivalence:

         The entire URN is case-sensitive.

It should say:

   Rules for Lexical Equivalence:

         The namespace-specific part of the URN is case-sensitive.

Notes:

The original rule contradicts Section 5 of RFC 2141 [1],
which requests case-insensitive comparison after downcasing
of "urn:" and the NID, and normalization of %-escaping.
The correction restores conformance with RFC 2141.

[[ please remove after verification:
apparently this correction has been lost since LC ]]

Errata ID: 1328
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-02-20
Verifier Name: Alexey Melnikov
Date Verified: 2010-11-12

Section 3, pg.7 says:

   Rules for Lexical Equivalence:

         The entire URN is case-sensitive.

It should say:

   Rules for Lexical Equivalence:

         The namespace-specific part of the URN is case-sensitive.

Notes:

Rationale: See previous report, Errata ID 1325 !


[[ Additional note (please remove upon verification):
Re-entered after reported change to the Errata System
(hopefully) allows it to accept this report. ]]

RFC 5137, "ASCII Escaping of Unicode Characters", February 2008

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 5138
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Smith
Date Reported: 2017-10-04
Verifier Name: Alexey Melnikov
Date Verified: 2017-10-04

Section A.3 says:

   EmbeddedUnicodeChar =   %x5C.7A 4HEXDIG ; starts with "\u"

It should say:

   EmbeddedUnicodeChar =   %x5C.75 4HEXDIG ; starts with "\u"

Notes:

Hex 7A is the character 'z', which doesn't match the comment.
As far as I can tell, the Java language defines unicode characters to be \u, like the comment says, and therefore the ABNF should be %x5C.75

Errata ID: 4888
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Matthew Kerwin
Date Reported: 2016-12-14
Verifier Name: Orie Steele
Date Verified: 2024-04-01

Section 1.1 says:

So, even for the fairly simple cases of ASCII and standard built by
extending ASCII, such as the ISO 8859 family, we have been living

It should say:

So, even for the fairly simple cases of ASCII and standards built by
extending ASCII, such as the ISO 8859 family, we have been living

Notes:

Should be plural "standards"

Errata ID: 7234
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-11-02
Verifier Name: RFC Editor
Date Verified: 2022-11-03

Section 2 says:

      or more decoding steps to determine a Unicode code point that can
      used to look up the character in a table.  That may be appropriate
      in some cases where the goal is really to represent the UTF-8 form
      but, in general, it just obscures desired information and makes
      errors more likely and debugging harder.

It should say:

      or more decoding steps to determine a Unicode code point that can
      be used to look up the character in a table.  That may be
      appropriate in some cases where the goal is really to represent
      the UTF-8 form but, in general, it just obscures desired
      information and makes errors more likely and debugging harder.

Notes:

Missing "be".

Errata ID: 7235
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-11-02
Verifier Name: Orie Steele
Date Verified: 2024-04-01

Section 2 says:

   form used in Java (See Section 6.3).  While those forms are

It should say:

   form used in Java (see Section 6.3).  While those forms are

Notes:

The word "see" should not be capitalized here.

Errata ID: 7236
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2022-11-02
Verifier Name: Orie Steele
Date Verified: 2024-04-01

Section 5.1 says:

   start in "\u" (See, e.g., Section 6.1, below>), but uses explicit

It should say:

   start in "\u" (see, e.g., Section 6.1, below), but uses explicit

Notes:

The character ">" should not be here and the word "see" should not be capitalized here.

RFC 5141, "A Uniform Resource Name (URN) Namespace for the International Organization for Standardization (ISO)", March 2008

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 6328
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jason Polis
Date Reported: 2020-11-06
Verifier Name: Barry Leiba
Date Verified: 2020-11-10

Section 2.4.1 + AppB says:

      docelement    = ":" ( "clause" / "figure" / "table" / "term" ) ":"
                      elementnumber / elementrange
                      *( "," elementnumber / elementrange )

It should say:

      docelement    = ":" ( "clause" / "figure" / "table" / "term" ) ":"
                      ( elementnumber / elementrange )
                      *( "," ( elementnumber / elementrange ) )

Notes:

In docelement, "elementnumber / elementrange" should be grouped in both places.

RFC 5144, "A Domain Availability Check (DCHK) Registry Type for the Internet Registry Information Service (IRIS)", February 2008

Source of RFC: crisp (app)

Errata ID: 1335
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-03
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-21

Section 5.3 says:

     [...] Sraightforwarad-NAPTR [...]
           ^^          ^^^

It should say:

     [...] Straightforward-NAPTR [...]
           ^^^          ^^

RFC 5150, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", February 2008

Source of RFC: ccamp (rtg)

Errata ID: 1345
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-03
Verifier Name: Adrian Farrel
Date Verified: 2009-08-24

Section 5.1.1,p.8 says:

   If an egress node receiving a Path message with the "LSP stitching
|  desired" bit set in the Flags field of received LSP_ATTRIBUTES object
                                      ^^^^
|  recognizes the object, the TLV TLV, and the bit and also supports the
                              ^^^^^^^
   desired stitching behavior, then it MUST allocate a non-NULL label
   for that S-LSP in the corresponding Resv message.  Also, so that the
   head-end node can ensure that the correct label (forwarding) actions
   will be carried out by the egress node and that the S-LSP can be used
   for stitching, the egress node MUST set the "LSP segment stitching
   ready" bit defined in the Flags field of the RRO Attribute subobject.

It should say:

   If an egress node receiving a Path message with the "LSP stitching
|  desired" bit set in the Flags field of the Attributes Flags TLV of
                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|  the received LSP_ATTRIBUTES object recognizes the object, the TLV,
   ^^^^                                                          ^^^
   and the bit and also supports the desired stitching behavior, then it
   MUST allocate a non-NULL label for that S-LSP in the corresponding
   Resv message.  Also, so that the head-end node can ensure that the
   correct label (forwarding) actions will be carried out by the egress
   node and that the S-LSP can be used for stitching, the egress node
   MUST set the "LSP segment stitching ready" bit defined in the Flags
   field of the RRO Attribute subobject.

Notes:

Location is 6th paragraph of Section 5.1.1 (i.e., 3rd paragraph on page 8).

Rationale:
a) apparently significant text dropped
b) spurious word replication

RFC 5151, "Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions", February 2008

Source of RFC: ccamp (rtg)

Errata ID: 1346
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-04
Verifier Name: Adrian Farrel
Date Verified: 2009-08-24

Section 9.1 says:

   A new bit has been allocated from the "Attributes Flags" sub-registry
   of the "RSVP TE Parameters" registry.

                                            vvvvvvvvv
| Bit | Name                 | Attribute  | Path       | RRO | Reference
  No  |                      | Flags Path | Flags Resv |     |
  ----+----------------------+------------+------------+-----+----------
| 4     Contiguous LSP         Yes          No           Yes   [RFC5150]
                                                                   ^^^^^

It should say:

   A new bit has been allocated from the "Attributes Flags" sub-registry
   of the "RSVP TE Parameters" registry.

                                            vvvvvvvvv
| Bit | Name                 | Attribute  | Attribute  | RRO | Reference
  No  |                      | Flags Path | Flags Resv |     |
  ----+----------------------+------------+------------+-----+----------
| 4     Contiguous LSP         Yes          No           Yes   [RFC5151]
                                                                   ^^^^

Notes:

a) Registry heading garbled
b) RFC 5151 -- that's where we are there!

Hint: The IANA registry file is *not* affected.
Apparently the error has been introduced after IANA processing,
or IANA has detected and corrected the issue when updating it.

RFC 5153, "IP Flow Information Export (IPFIX) Implementation Guidelines", April 2008

Source of RFC: ipfix (ops)

Errata ID: 2900
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02

Section 7.2 says:

   Consequently, an Exporting Process reporting traffic Flows measured
   at a device that hosts one or more middleboxes should clearly
   indicate to Collecting Processes the location of the used Observation
   Point(s) with respect to the middlebox(es).  This can be done by
   using Options with Observation Point as scope and elements like, for
   instance, lineCardID or samplerID.  Otherwise, processing the
   measured Flow data could lead to wrong results.

It should say:

   Consequently, an Exporting Process reporting traffic Flows measured
   at a device that hosts one or more middleboxes should clearly
   indicate to Collecting Processes the location of the used Observation
   Point(s) with respect to the middlebox(es).  This can be done by
   using Options with Observation Point as scope and elements like, for
   instance, lineCardId or selectorId.  Otherwise, processing the
   measured Flow data could lead to wrong results.

Notes:

s/lineCardID/lineCardId/
s/samplerID/selectorId/

Per the definitions in RFC5102, RFC5477 and IANA's IPFIX registry.

Errata ID: 2901
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02

Section 3.3 says:

   Note that it is sometimes necessary to export information about
   entities that exist outside any Observation Domain, or within
   multiple Observation Domains (e.g., information about Metering
   Processes scoped to meteringProcessID).  Such information SHOULD be
   exported in an IPFIX Message with Observation Domain ID 0 (see
   [RFC5101], Section 3.1).

It should say:

   Note that it is sometimes necessary to export information about
   entities that exist outside any Observation Domain, or within
   multiple Observation Domains (e.g., information about Metering
   Processes scoped to meteringProcessId).  Such information SHOULD be
   exported in an IPFIX Message with Observation Domain ID 0 (see
   [RFC5101], Section 3.1).

Notes:

s/meteringProcessID/meteringProcessId/

Per RFC5102 and IANA's IPFIX registry, the correct name is "meteringProcessId".

RFC 5155, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", March 2008

Note: This RFC has been updated by RFC 6840, RFC 6944, RFC 9077, RFC 9157, RFC 9276

Source of RFC: dnsext (int)

Errata ID: 3544
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Andy Newton
Date Reported: 2013-03-10
Verifier Name: Ralph Droms
Date Verified: 2013-03-12

Section 3.3 says:

o  The Next Hashed Owner Name field is represented as an unpadded
   sequence of case-insensitive base32 digits, without whitespace.

It should say:

o  The Next Hashed Owner Name field is represented as an unpadded 
   sequence of case-insensitive base32hex digits, without whitespace.

Notes:

RFC 4648 Section 7 says: 'This encoding may be referred to as "base32hex". This encoding should not be regarded as the same as the "base32" encoding and should not be referred to as only "base32".'

There are many spots in RFC 5155 that use the term base32 where base32hex is the appropriate term. Section 3.3 above is the most important, but Section 1.1 uses the term as well Section 3 paragraph 4 and Section 3.2 paragraph 8.

Errata ID: 3441
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Edward Lewis
Date Reported: 2012-12-31
Verifier Name: Ralph Droms
Date Verified: 2013-03-10

Section 7.2.3 & 8.5 says:

7.2.3

(contents)

8.5

(contents)

It should say:

7.2.3.  No Data Responses, QTYPE is not DS

  If the No Data Response is a result of an empty non-terminal derived 
  from an insecure delegation covered by an Opt-Out NSEC3 RR, the 
  closest provable encloser proof MUST be included in the response.  
  The included NSEC3 RR that covers the "next closer" name for the 
  delegation MUST have the Opt-Out flag set to one. 

  In all other cases, the server MUST include the NSEC3 RR that matches 
  QNAME.  This NSEC3 RR MUST NOT have the bits corresponding to either 
  the QTYPE or CNAME set in its Type Bit Maps field.

===============================================

8.5.  Validating No Data Responses, QTYPE is not DS

  If there is an NSEC3 RR that matches QNAME present, the validator must 
  check that both the QTYPE and the CNAME type are not set in its Type 
  Bit Maps field.

  Note that this test also covers the case where the NSEC3 RR exists
  because it corresponds to an empty non-terminal, in which case the
  NSEC3 RR will have an empty Type Bit Maps field.

  If there is no NSEC3 RR present that matches QNAME, then the validator 
  MUST verify a closest provable encloser proof for the QNAME.  The 
  validator MUST verify that the Opt-Out bit is set in the NSEC3 RR that 
  covers the "next closer" name to the delegation name. This test covers 
  the case where the response is due to an Empty Non-Terminal derived 
  from an insecure delegation covered by an Opt-Out NSEC3 RR.

Notes:

The corrections were derived from a private email from an editor of RFC 5155. Note that the ordering of the paragraphs in the proposed 8.5 fix has been changed. No other change is intentional.

From Roy Arends:

We missed documenting the case of what a server and a validator should do in case of an opted-out, multi-label delegation. We did make it clear in signing (7.1).

This is also not part of the demo zone, included in RFC5155.

As suggested text for an errata, may I offer:

7.2.3. No Data Responses, QTYPE is not DS

If the No Data Response is a result of an empty non-terminal derived
from an insecure delegation covered by an Opt-Out NSEC3 RR, the
closest provable encloser proof MUST be included in the response.
The included NSEC3 RR that covers the "next closer" name for the
delegation MUST have the Opt-Out flag set to one.

In all other cases, the server MUST include the NSEC3 RR that matches
QNAME. This NSEC3 RR MUST NOT have the bits corresponding to either
the QTYPE or CNAME set in its Type Bit Maps field.

8.5. Validating No Data Responses, QTYPE is not DS

If there is no NSEC3 RR present that matches QNAME, then the validator
MUST verify a closest provable encloser proof for the QNAME. The
validator MUST verify that the Opt-Out bit is set in the NSEC3 RR that
covers the "next closer" name to the delegation name. This test covers
the case where the response is due to an Empty Non-Terminal derived
from an insecure delegation covered by an Opt-Out NSEC3 RR.

If there is an NSEC3 RR that matches QNAME present, the validator must
check that both the QTYPE and the CNAME type are not set in its Type
Bit Maps field.

Note that this test also covers the case where the NSEC3 RR exists
because it corresponds to an empty non-terminal, in which case the
NSEC3 RR will have an empty Type Bit Maps field.

The following message is the singularly most important one in the errata submission, from David Blacka, commenting on the order of the paragraphs:

http://www.ietf.org/mail-archive/web/dnsext/current/msg12835.html

The heads of the threads to review:

http://www.ietf.org/mail-archive/web/dnsext/current/msg12819.html
http://www.ietf.org/mail-archive/web/dnsext/current/msg12821.html
http://www.ietf.org/mail-archive/web/dnsext/current/msg12830.html
http://www.ietf.org/mail-archive/web/dnsext/current/msg12832.html
http://www.ietf.org/mail-archive/web/dnsext/current/msg12839.html
http://www.ietf.org/mail-archive/web/dnsext/current/msg12854.html
and
http://www.ietf.org/mail-archive/web/dnsext/current/msg12864.html

Errata ID: 4622
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Robert Edmonds
Date Reported: 2016-02-18
Verifier Name: Brian Haberman
Date Verified: 2016-02-19

Section 7.2.8 says:

7.2.8.  Responding to Queries for NSEC3 Owner Names

   The owner names of NSEC3 RRs are not represented in the NSEC3 RR
   chain like other owner names.  As a result, each NSEC3 owner name is
   covered by another NSEC3 RR, effectively negating the existence of
   the NSEC3 RR.  This is a paradox, since the existence of an NSEC3 RR
   can be proven by its RRSIG RRSet.

   If the following conditions are all true:

   o  the QNAME equals the owner name of an existing NSEC3 RR, and

   o  no RR types exist at the QNAME, nor at any descendant of QNAME,

   then the response MUST be constructed as a Name Error response
   (Section 7.2.2).  Or, in other words, the authoritative name server
   will act as if the owner name of the NSEC3 RR did not exist.

It should say:

7.2.8.  Responding to Queries for NSEC3 Owner Names

   The owner names of NSEC3 RRs are not represented in the NSEC3 RR
   chain like other owner names.  As a result, each NSEC3 owner name is
   covered by another NSEC3 RR, effectively negating the existence of
   the NSEC3 RR.  This is a paradox, since the existence of an NSEC3 RR
   can be proven by its RRSIG RRSet.

   If the following conditions are all true:

   o  the QNAME equals the owner name of an existing NSEC3 RR, and

   o  no RR types exist at the QNAME besides NSEC3, nor at any
      descendant of QNAME,

   then the response MUST be constructed as a Name Error response
   (Section 7.2.2).  Or, in other words, the authoritative name server
   will act as if the owner name of the NSEC3 RR did not exist.

Notes:

If the QNAME is equal to the owner name of an existing NSEC3 RR, then the NSEC3 RR type itself will exist at the QNAME, and the second condition will always be false.

RFC 5162, "IMAP4 Extensions for Quick Mailbox Resynchronization", March 2008

Note: This RFC has been obsoleted by RFC 7162

Source of RFC: lemonade (app)

Errata ID: 1807
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Timo Sirainen
Date Reported: 2009-07-14
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-18

Section 1 says:

It should say:

   Once a "CONDSTORE enabling command" is issued by the client, the
   server MUST automatically include both UID and mod-sequence data in
   all subsequent untagged FETCH responses (until the connection is
   closed), whether they were caused by a regular STORE/UID STORE, a
   STORE/UID STORE with UNCHANGEDSINCE modifier, or an external agent.
   Note that this rule doesn't affect untagged FETCH responses caused by
   a FETCH command that doesn't include UID and/or MODSEQ FETCH data
   item, or UID FETCH without the MODSEQ FETCH data item.

Notes:

Rationale:

It's very difficult for clients to make use of unsolicited FETCH responses without the UID field. This is made even worse by the text that says "servers SHOULD NOT send UIDs for previously expunged messages [in VANISHED replies]". Since it's not a MUST NOT, a conversation with an RFC compliant server could be for example:

A1 NOOP
* 0 EXISTS
A1 OK
A2 NOOP
* 10 EXISTS
* VANISHED 1000:2000
* 3 FETCH (FLAGS (\Seen) MODSEQ (14749))
* 5 FETCH (FLAGS (\Seen) MODSEQ (14749))
* VANISHED 2000:3000
A2 OK NOOP Completed

The client couldn't do anything with the information from FETCH replies, because it can't know what messages they refer to.

Errata ID: 1808
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Timo Sirainen
Date Reported: 2009-07-14
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-18

Section 3.4 says:

   If at least one message got expunged, the server MUST send
   the updated per-mailbox modification
   sequence using the HIGHESTMODSEQ response code (defined in
   [CONDSTORE]) in the tagged OK response.

      Example:    C: A202 CLOSE
                  S: A202 OK [HIGHESTMODSEQ 20010715194045319] done

It should say:

   The server MUST NOT send the updated per-mailbox modification
   sequence using the HIGHESTMODSEQ response code (defined in
   [CONDSTORE]) in the tagged OK response, as this might cause loss of
   synchronization on the client.

      Example:    C: A202 CLOSE
                  S: A202 OK done

Notes:

Rationale:

The HIGHESTMODSEQ can't be used reliably unless server sends to client all changes done by other clients. Even then it's difficult for both clients and servers to implement this. For example:

C1: 2 STORE 1 +FLAGS.SILENT \Deleted
S1: * 1 FETCH (MODSEQ 1)
S1: 2 OK

C2: 1 STORE 2 +FLAGS.SILENT \Deleted
S1: * 2 FETCH (MODSEQ 2)
S2: 1 OK

C1: 3 CLOSE
S1: 3 [HIGHESTMODSEQ 3]

The client probably thought that only message 1 was expunged, so it
doesn't register the second expunge. And it probably never will if it
uses QRESYNC to find out only about new expunges.

And even worse example would be if the second client had also removed
the \Deleted flag from message 1. Then the first client would have
registered wrong message to be expunged.

Errata ID: 1809
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Timo Sirainen
Date Reported: 2009-07-14
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-18

Section 5 says:

   After completing a full synchronization, the client MUST also take
   note of any unsolicited MODSEQ FETCH data items received from the
   server.  Whenever the client receives a tagged response to a command,
   it calculates the highest value among all MODSEQ FETCH data items
   received since the last tagged response.  If this value is bigger
   than the client's copy of the HIGHESTMODSEQ value, then the client
   MUST use this value as its new HIGHESTMODSEQ value.

   Note: It is not safe to update the client's copy of the HIGHESTMODSEQ
   value with a MODSEQ FETCH data item value as soon as it is received
   because servers are not required to send MODSEQ FETCH data items in
   increasing modseqence order.  This can lead to the client missing
   some changes in case of connectivity loss.

It should say:

   After completing a full synchronization, the client MUST also take
   note of any unsolicited MODSEQ FETCH data items and HIGHESTMODSEQ
   response codes received from the server.  Whenever the client receives
   a tagged response to a command, it checks the received unsolicited
   responses to calculate the new HIGHESTMODSEQ value.  If the
   HIGHESTMODSEQ response code is received, the client MUST use it even
   if it has seen higher mod-sequences.  Otherwise, the client calculates
   the highest value among all MODSEQ FETCH data items received since the
   last tagged response.  If this value is bigger than the client's copy
   of the HIGHESTMODSEQ value, then the client MUST use this value as its
   new HIGHESTMODSEQ value.

      Example:    C: A1 STORE 1:2 (UNCHANGEDSINCE 96) +FLAGS.SILENT \Seen
                  S: * 1 FETCH (UID 6 MODSEQ (103))
                  S: * 2 FETCH (UID 7 MODSEQ (101))
                  S: * OK [HIGHESTMODSEQ 99] VANISHED reply with
		      MODSEQ 100 is delayed
                  S: A1 OK [MODIFIED 3] done

                  C: A2 STORE 3 +FLAGS.SILENT \Seen
                  S: * 3 FETCH (UID 8 MODSEQ (104))
                  S: A2 OK [HIGHESTMODSEQ 99] Still delaying VANISHED

                  C: A3 NOOP
                  S: * VANISHED 8
                  S: A3 OK [HIGHESTMODSEQ 104] done

   Note: It is not safe to update the client's copy of the HIGHESTMODSEQ
   value with a MODSEQ FETCH data item value as soon as it is received
   because servers are not required to send MODSEQ FETCH data items in
   increasing modseqence order.  Some commands may also delay EXPUNGE
   (or VANISHED) replies with smaller mod-sequences. These can lead to
   the client missing some changes in case of connectivity loss.

Notes:

Rationale:

Otherwise clients could lose changes in case of connectivity loss.

Errata ID: 1810
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Timo Sirainen
Date Reported: 2009-07-14
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-18

Section 1 says:

It should say:

   Server implementing QRESYNC MUST send untagged events to client in a
   way that client doesn't lose any changes in case of connectivity loss.
   In particular this means that if server sends MODSEQ FETCH data items
   while EXPUNGE (or VANISHED) replies with lower mod-sequences are being
   delayed, the server MUST send HIGHESTMODSEQ response code with a lower
   value than the EXPUNGE's mod-sequence. See example in section 5.

Notes:

This is related to the other errata in section 5, which describes what the client's behavior should be. This describes what the server's behavior should be. Would have been nice to put them into the same section, but that probably would require larger changes.

RFC 5176, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", January 2008

Note: This RFC has been updated by RFC 8559

Source of RFC: radext (sec)

Errata ID: 1407
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Avi Lior
Date Reported: 2008-04-09
Verifier Name: Dan Romascanu
Date Verified: 2010-11-02

Section 6.1 says:

Typically, the Dynamic Authorization Server will extract the realm
   from the Network Access Identifier [RFC4282] included within the
   User-Name or Chargeable-User-Identity Attribute, and determine the
   corresponding RADIUS servers in the realm routing tables.

It should say:

Typically, the Dynamic Authorization Server will extract the realm
   from the Network Access Identifier [RFC4282] included within the
   User-Name and determine the
   corresponding RADIUS servers in the realm routing tables.

Notes:

Chargeable-User-Identity Attribute defined in RFC4372 does not allow any entity other then the home network to parse the CUI attribute. It is in essence opaque. Here is the text:
"RADIUS entities other than the Home RADIUS
server MUST treat the CUI content as an opaque token, and SHOULD
NOT perform operations on its content other than a binary equality
comparison test, between two instances of CUI."

Errata ID: 2012
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Avi Lior
Date Reported: 2010-01-25
Verifier Name: Dan Romascanu
Date Verified: 2010-11-02

Section 3.5 says:

Values 200-299 represent successful completion, so that these
values may only be sent within CoA-ACK or Disconnect-ACK packets
and MUST NOT be sent within a CoA-NAK or Disconnect-NAK packet.

It should say:

Values 200-299 represent successful completion, so that these
values may be sent in other reply messages such as Access-Reject, Access-Challenge, CoA-ACK or Disconnect-ACK packets
and MUST NOT be sent within a CoA-NAK or Disconnect-NAK packet.

Notes:

RFC 3579 allows for Error-Cause to be sent (specifically) in an access-challenge and also in Reject messages as well.

The specification in 5176 restricts the usage and should be clarified especially since 5176 was published after 3579.

I proposed minimal text but I think a broader approach is needed for this attribute. Here are some thoughts:
1) Error-Cause is needed in Access-Reject (as is allowed by 3579)
2) IANA should have procedures for defining new values (currently no procedure is defined). SDO need to be able to use Error-Cause to report back why an Authentication/Authorization failed. Error-Cause seems to be the only solution other than Reply-Message which is not really designed for reporting error cause to the NAS.

Errata ID: 4311
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alan DeKok
Date Reported: 2015-03-23
Verifier Name: Kathleen Moriarty
Date Verified: 2015-07-20

Section 2.3 says:

Section 2.3 says:

      In CoA-Request and Disconnect-Request packets, all attributes MUST
      be treated as mandatory. 

It should say:

In CoA-Request and Disconnect-Request packets, all attributes MUST
be treated as mandatory to understand by the NAS, except Proxy-State
attributes that MUST be treated as opaque data.  See Section 3.1 for a
discussion of how the NAS must handle Proxy-State.

Notes:

This was seen with vendor equipment. CoA proxying was done to the NAS, and the proxy was adding and forwarding Proxy-State as required by Section 3.1. However, the NAS was returning a CoA-NAK with Error-Cause = Unsupported-Attribute.

The issue comes because Proxy-State is called out in Section 3.1 for special handling. However, that special handling isn't called out in Section 2.3. As a result, implementors can get confused.

The RADEXT WG is rechartering with a document to address CoA proxying. We will also be addressing this issue in that document. There are additional attributes which a NAS should ignore, OR which should be filtered out by the proxy closest to the NAS.

The text was slightly updated by the WG from the originally submitted text.

Errata ID: 3294
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mauricio Sanchez
Date Reported: 2012-07-26
Verifier Name: Benoit Claise
Date Verified: 2012-07-26

Section 3.6 says:

   Disconnect Messages

   Request   ACK      NAK   #   Attribute
   0-1       0        0     1   User-Name (Note 1)
   0-1       0        0     4   NAS-IP-Address (Note 1)
   0-1       0        0     5   NAS-Port (Note 1)
   0         0        0     6   Service-Type
   0         0        0     8   Framed-IP-Address (Note 1)

It should say:

   Disconnect Messages

   Request   ACK      NAK   #   Attribute
   0-1       0        0     1   User-Name (Note 1)
   0-1       0        0     4   NAS-IP-Address (Note 1)
   0-1       0        0     5   NAS-Port (Note 1)
   0         0        0     6   Service-Type
   0-1       0        0     8   Framed-IP-Address (Note 1)

Notes:

Section 3.6 ("Table of Attributes") changed the number of Frame-IP-Address attributes allowed in Disconnect-Message compared to previous RFC3576 (changed from "0-1" to "0"). The table should revert back to its original RFC3576 value in order to maintain backward compatibility with RFC3576.

Errata ID: 4280
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alan DeKok
Date Reported: 2015-02-24
Verifier Name: Kathleen Moriarty
Date Verified: 2015-04-21

Section 3.6 says:

   0         0        0+  101   Error-Cause


In both tables, for CoA and Disconnect messages.

It should say:

   0         0+        0+  101   Error-Cause


In both tables, for CoA and Disconnect messages.

Notes:

Section 3.5 says that Error-Cause may be sent in a CoA-ACK or Disconnect-ACK packet:

...
Values 200-299 represent successful completion, so that these
values may only be sent within CoA-ACK or Disconnect-ACK packets

RFC 5180, "IPv6 Benchmarking Methodology for Network Interconnect Devices", May 2008

Source of RFC: bmwg (ops)

Errata ID: 1752
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michelle Cotton
Date Reported: 2009-04-02
Verifier Name: Ron Bonica
Date Verified: 2009-04-27

Section 8 says:

The IANA has allocated 2001:0200::/48 for IPv6 benchmarking, which
is a 48-bit prefix from the RFC 4773 pool.

It should say:

The IANA has assigned 2001:0002::/48 for IPv6 benchmarking, which
is a 48-bit prefix from the RFC 4773 pool.

Notes:

There was an error in the assigned prefix. This should have been 2001:0002::/48. The previous prefix is actually NOT part of the RFC 4773 pool.

Errata ID: 3953
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Fernando Gont
Date Reported: 2014-04-07
Verifier Name: Benoit Claise
Date Verified: 2014-04-15

Section 3 says:

Nevertheless, for each evaluated device, it
is recommended to perform as many of the applicable tests described
in Section 6 as possible.

It should say:

Nevertheless, for each evaluated device, it
is recommended to perform as many of the applicable tests described
in Section 7 as possible.

RFC 5191, "Protocol for Carrying Authentication for Network Access (PANA)", May 2008

Note: This RFC has been updated by RFC 5872

Source of RFC: pana (int)

Errata ID: 2997
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Yoshihiro Ohba
Date Reported: 2011-10-13
Verifier Name: Ralph Droms
Date Verified: 2013-03-10

Section 8.4 says:

The Key-Id AVP (AVP Code 4) is of type Integer32 and contains an MSK
identifier.  

It should say:

The Key-Id AVP (AVP Code 4) is of type Unsigned32 and contains an MSK
identifier.

Notes:

The Correct Text will be consistent with the following text in Section 5.3, "The Key-Id AVP is of type Unsigned32..."

Errata ID: 3397
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Yoshihiro Ohba
Date Reported: 2012-10-30
Verifier Name: Ralph Droms
Date Verified: 2013-03-10

Section 4.3 says:

When the PAA initiates re-authentication, it sends a 
PANA-Auth-Request message containing the session identifier for the 
PaC.  The PAA MUST initiate EAP re-authentication before the current 
session lifetime expires.

It should say:

When the PAA initiates re-authentication, it sends a 
PANA-Auth-Request message containing the session identifier for the 
PaC.  In this case, the PAA MUST initiate EAP re-authentication 
before the current session lifetime expires.

Notes:

The 2nd sentence in the original text seems to indicate that re-authentication initiation from PAA is mandated, which is not correct as Section 3 says "the PAA may, and the PaC should, initiate re-authentication if they want to update the PANA session lifetime before the PANA session lifetime expires.

Errata ID: 3439
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Yoshihiro Ohba
Date Reported: 2012-12-27
Verifier Name: Brian Haberman
Date Verified: 2013-01-07

Section 8.3 says:

All PANA implementations MUST support AUTH_HMAC_SHA1_160 (7) [RFC4595].

It should say:

All PANA implementations MUST support AUTH_HMAC_SHA1_160 (7) [RFC4595] with a key length of 20 octets.

Notes:

RFC 4595 refers to FC-SP (INCITS Technical Committee T11, ANSI INCITS xxx-200x, "Fibre Channel - Security Protocols (FC-SP)") which refers to RFC 2104 for HMAC. However, since RFC 2104 allows variable key length, a fixed key length needs to be specified in RFC 5191 to avoid a potential interoperability problem.

RFC 5198, "Unicode Format for Network Interchange", March 2008

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 1402
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-31
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-11

Section 2, mid-pg.4 says:

   The use of LF without CR is questionable; see Appendix B for more
   discussion.  The newer control characters IND (U+0084) and NEL ("Next
   Line", U+0085) might have been used to disambiguate the various line-
   ending situations, but, because their use has not been established on
   the Internet, because many protocols require CRLF, and because IND
|  and NEL fall within the "C1 Controls" group (see below), they MUST
   NOT be used.  [...]
                                                    ^^^^^

It should say:

   The use of LF without CR is questionable; see Appendix B for more
   discussion.  The newer control characters IND (U+0084) and NEL ("Next
   Line", U+0085) might have been used to disambiguate the various line-
   ending situations, but, because their use has not been established on
   the Internet, because many protocols require CRLF, and because IND
|  and NEL fall within the "C1 Controls" group (see above), they MUST
   NOT be used.  [...]
                                                    ^^^^^^

Notes:

The only relevant discussion of "C1 Controls" in the document
is in bullet 3 within the same section, on the preceding page.
Hence, "below" is misleading for the reader and needs to be
replaced to correctly say "above".

RFC 5208, "Public-Key Cryptography Standards (PKCS) #8: Private-Key Information Syntax Specification Version 1.2", May 2008

Note: This RFC has been obsoleted by RFC 5958

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 1890
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sean Turner
Date Reported: 2009-09-22
Verifier Name: Russ Housley
Date Verified: 2010-03-11

Section 5 says:

attributes           [0]  IMPLICIT Attributes OPTIONAL }

It should say:

attributes           [0]  Attributes OPTIONAL }

Notes:

This change will align the text with the ASN.1 module. Note that the ASN.1 module is an IMPLICIT module and the IMPLICIT tag on this line is unnecessary.

RFC 5213, "Proxy Mobile IPv6", August 2008

Note: This RFC has been updated by RFC 6543, RFC 7864

Source of RFC: netlmm (int)

Errata ID: 3140
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Behcet Sarikaya
Date Reported: 2012-02-28
Verifier Name: Brian Haberman
Date Verified: 2012-05-08

Section 8.1 says:

    As per this specification, the following mobility options are
      valid in a Proxy Binding Update message.  These options can be
      present in the message in any order.  There can be one or more
      instances of the Home Network Prefix options present in the
      message.  However, there cannot be more than one instance of any
      of the following options.

         Mobile Node Identifier option

         Home Network Prefix option

         Handoff Indicator option

         Access Technology Type option

         Timestamp option

         Mobile Node Link-layer Identifier option

         Link-local Address option

It should say:

    As per this specification, the following mobility options are
      valid in a Proxy Binding Update message.  These options can be
      present in the message in any order.  There can be one or more
      instances of the Home Network Prefix options present in the
      message.  However, there cannot be more than one instance of any
      of the following options.

         Mobile Node Identifier option

         Handoff Indicator option

         Access Technology Type option

         Timestamp option

         Mobile Node Link-layer Identifier option

         Link-local Address option

Notes:

There can be more than one instance of Home Network Prefix. So the list should not include Home Network Prefix

Errata ID: 3141
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Behcet Sarikaya
Date Reported: 2012-02-28
Verifier Name: Brian Haberman
Date Verified: 2012-05-08

Section 8.2 says:

As per this specification, the following mobility options are
      valid in a Proxy Binding Acknowledgement message.  These options
      can be present in the message in any order.  There can be one or
      more instances of the Home Network Prefix options present in the
      message.  However, there cannot be more than one instance of any
      of the following options.

         Mobile Node Identifier option

         Home Network Prefix option

         Handoff Indicator option

         Access Technology Type option

         Timestamp option

         Mobile Node Link-layer Identifier option

         Link-local Address option

It should say:

As per this specification, the following mobility options are
      valid in a Proxy Binding Acknowledgement message.  These options
      can be present in the message in any order.  There can be one or
      more instances of the Home Network Prefix options present in the
      message.  However, there cannot be more than one instance of any
      of the following options.

         Mobile Node Identifier option

         Handoff Indicator option

         Access Technology Type option

         Timestamp option

         Mobile Node Link-layer Identifier option

         Link-local Address option

Notes:

There can be more than one instance of Home Network Prefix option so the list should not contain Home Network Prefix.

RFC 5216, "The EAP-TLS Authentication Protocol", March 2008

Note: This RFC has been updated by RFC 8996, RFC 9190

Source of RFC: emu (sec)

Errata ID: 1389
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-26
Verifier Name: Pasi Eronen
Date Verified: 2009-01-05

Section 2.1.3 says:

   If the peer's authentication is unsuccessful, the EAP server SHOULD
   send an EAP-Request packet with EAP-Type=EAP-TLS, encapsulating a TLS
   record containing the appropriate TLS alert message.  The EAP server
|  SHOULD send a TLS alert message immediately terminating the
   conversation so as to allow the peer to inform the user or log the
   cause of the failure and possibly allow for a restart of the
   conversation.

It should say:

   If the peer's authentication is unsuccessful, the EAP server SHOULD
   send an EAP-Request packet with EAP-Type=EAP-TLS, encapsulating a TLS
   record containing the appropriate TLS alert message.  The EAP server
|  SHOULD send a TLS alert message rather than immediately terminating
                                   ^^^^^^^^^^^^
   the conversation so as to allow the peer to inform the user or log
   the cause of the failure and possibly allow for a restart of the
   conversation.

Notes:

The double word omission totally distorts the proper sense
of the sentence. The 4th paragraph of this section describes
the converse scenarion, and it does it properly; the wording
from there has been adopted above.

Note that RFC 2716 already had dropped the word "than" making it
difficult to understand. Additionally dropping "rather" as well in
RFC 5216 fully distorts the intended sense and leads to confusion.

[Confirmed by Bernard Aboba and Ryan Hurst]

Errata ID: 6357
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Benjamin Kaduk
Date Reported: 2020-12-16
Verifier Name: Roman Danyliw
Date Verified: 2022-01-19

Section 5.1 says:

   [3] Section 5 of BCP 86 [RFC3766] offers advice on the required RSA
   or Diffie-Hellman (DH) module and Digital Signature Algorithm (DSA)
   subgroup size in bits, for a given level of attack resistance in
   bits.  For example, a 2048-bit RSA key is recommended to provide
   128-bit equivalent key strength.  The National Institute of Standards
   and Technology (NIST) also offers advice on appropriate key sizes in
   [SP800-57].

It should say:

   [3] Section 5 of BCP 86 [RFC3766] offers advice on the required RSA
   or Diffie-Hellman (DH) modulus and Digital Signature Algorithm (DSA)
   subgroup size in bits, for a given level of attack resistance in
   bits.  For example, a 2048-bit RSA key is recommended to provide
   128-bit equivalent key strength.  The National Institute of Standards
   and Technology (NIST) also offers advice on appropriate key sizes in
   [SP800-57].

Notes:

RSA and DH computations are parameterized by their moduli, with singular "modulus" (not "module").

RFC 5220, "Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules", July 2008

Source of RFC: v6ops (ops)

Errata ID: 1475
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2008-07-18
Verifier Name: Ron Bonica
Date Verified: 2009-10-06

Section 2.1.7 says:

RFC 3041 defines a Temporary Address.

It should say:

RFC 4941 defines a Temporary Address.

Notes:

RFC 3041 has been obsoleted a few months before the publication of RFC 5220.

RFC 5222, "LoST: A Location-to-Service Translation Protocol", August 2008

Note: This RFC has been updated by RFC 6848, RFC 8917, RFC 9036

Source of RFC: ecrit (rai)

Errata ID: 4174
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Dan Banks
Date Reported: 2014-11-12
Verifier Name: Alissa Cooper
Date Verified: 2016-04-03

Section 15 & Apdx A says:

In section 15, the Exception pattern says (in part):
  locationProfileUnrecognized =
    element locationProfileUnrecognized {
      attribute unsupportedProfiles { xsd:NMTOKENS },
      basicException
    }

The corresponding section in Appendix A says:
       <define name="locationProfileUnrecognized">
         <element name="locationProfileUnrecognized">
           <attribute name="unsupportedProfiles">
             <data type="NMTOKENS"/>
           </attribute>
           <ref name="basicException"/>
         </element>
       </define>

It should say:

Section 15 should say:
  locationProfileUnrecognized =
    element locationProfileUnrecognized {
      basicException
    }

Appendix A should say:
       <define name="locationProfileUnrecognized">
         <element name="locationProfileUnrecognized">
           <ref name="basicException"/>
         </element>
       </define>

Notes:

The ‘unsupportedProfiles’ attribute is not referenced anywhere else in the text of the document; no instruction is given describing the use of this attribute. This, by itself, is problematic. However, based on the type, it seems reasonable that the intent may have been to list the location profiles which the server is unable to understand.

Consider the condition under which the ‘locationProfileUnrecognized’ error is returned (section 12.1):
8. If a server receives a request that only contains location
information using profiles it does not understand, the server
responds with a <locationProfileError>

If none of the locations include the optional ‘profile’ attribute, the server may not be able to identify any of the profiles and therefore would be incapable of returning a list of profile names. This is especially problematic considering that the ‘unsupportedProfiles’ attribute is required by the schema.

Even in cases where one or more locations include the profile attribute, the client already knows what profiles were used in the request, so returning a list of these profiles does not provide new information to the client.

At best, use of the ‘unsupportedProfiles’ attribute appears to be redundant; at worst, it is impossible. Therefore, the suggested course of action is to remove the attribute from the schema.

Errata ID: 4176
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Dan Banks
Date Reported: 2014-11-13
Verifier Name: Alissa Cooper
Date Verified: 2016-04-03

Section 15 & Apdx A says:

Section 15:  

exceptionContainer =
    (badRequest?
     & internalError?
     & serviceSubstitution?
     & defaultMappingReturned?
     & forbidden?
     & notFound?
     & loop?
     & serviceNotImplemented?
     & serverTimeout?
     & serverError?
     & locationInvalid?
     & locationProfileUnrecognized?),
    extensionPoint,
    source

And:

  serverError = element serverError { basicException }
  locationInvalid = element locationInvalid { basicException }

Appendix A:

           <optional>
             <ref name="serverError"/>
           </optional>
           <optional>
             <ref name="locationInvalid"/>
           </optional>

And:

       <define name="serverError">
         <element name="serverError">
           <ref name="basicException"/>
         </element>
       </define>

       <define name="locationInvalid">
         <element name="locationInvalid">
           <ref name="basicException"/>
         </element>
       </define>

It should say:

Section 15:  

exceptionContainer =
    (badRequest?
     & internalError?
     & serviceSubstitution?
     & defaultMappingReturned?
     & forbidden?
     & notFound?
     & loop?
     & serviceNotImplemented?
     & serverTimeout?
     & serverError?
     & SRSInvalid?
     & locationInvalid?
     & locationProfileUnrecognized?),
    extensionPoint,
    source

And:

  serverError = element serverError { basicException }
  SRSInvalid = element SRSInvalid { basicException }
  locationInvalid = element locationInvalid { basicException }

Appendix A:

           <optional>
             <ref name="serverError"/>
           </optional>
           <optional>
             <ref name="SRSInvalid"/>
           </optional>
           <optional>
             <ref name="locationInvalid"/>
           </optional>

And:

       <define name="serverError">
         <element name="serverError">
           <ref name="basicException"/>
         </element>
       </define>

       <define name="SRSInvalid">
         <element name="SRSInvalid">
           <ref name="basicException"/>
         </element>
       </define>

       <define name="locationInvalid">
         <element name="locationInvalid">
           <ref name="basicException"/>
         </element>
       </define>

Notes:

The SRSInvalid error is defined in section 13.1, but was omitted from the schemas.

RFC 5225, "RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite", April 2008

Source of RFC: rohc (tsv)

Errata ID: 1421
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-05-13
Verifier Name: Magnus Westerlund
Date Verified: 2009-03-17

Section 6.6.6, p.28 says:

|  The inferred_ip_v4_length encoding method compresses the IPv4 header
|  checksum down to a size of zero bits, i.e., no bits are transmitted
   in compressed headers for this field.  [...]

It should say:

|  The inferred_ip_v4_length encoding method compresses the IPv4 Total
|  Length field down to a size of zero bits, i.e., no bits are
   transmitted in compressed headers for this field.  [...]

Notes:

Apparently, a copyedit flaw (text copied from 6.6.4 insufficiently
modified).

Errata ID: 2703
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Carl Knutsson
Date Reported: 2011-02-03
Verifier Name: Wesley Eddy
Date Verified: 2012-06-05

Section 6.6.11 says:

o  ip_id_behavior, one octet for each IP header in the compressible
   header chain starting from the outermost header.  Each octet
   consists of 2 bits padded with 6 MSBs of zeroes.

It should say:

o  ip_id_behavior_outer, one octet for each IPv4 header except the
   innermost in the compressible header chain starting from the outermost 
   header. Each octet consists of 2 bits padded with 6 MSBs of zeroes.

o  ip_id_behavior_innermost, one octet if the innermost header is an 
   IPv4 header. The octet consists of 2 bits padded with 6 MSBs of zeroes.

Notes:

There is no control field called ip_id_behavior in the document. There are two control fields related to IP-ID behavior, ip_id_behavior_innermost and ip_id_behavior_outer. For IPv6, only the ip_id_behavior_innermost field exists and its value is always IP_ID_BEHAVIOR_RANDOM according to the FN. This makes it impossible to include ip_id_behavior_outer when calculating the crc for IPv6 headers. Furthermore, since the ip_id_behavior_innermost is constant it makes no sense to include it in the crc calculation.

This errata has been verified based on discussion on the ROHC mailing list involving the authors in February, 2011.

Errata ID: 3185
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: FWX
Date Reported: 2012-04-11
Verifier Name: Wes Eddy
Date Verified: 2012-04-27

Section page 64 says:

rtp(profile_value, ts_stride_value, time_stride_value,
    reorder_ratio_value)
{
  UNCOMPRESSED {
    ENFORCE((profile_value == PROFILE_RTP_0101) ||
            (profile_value == PROFILE_RTP_0107));
    rtp_version =:= uncompressed_value(2, 0) [  2 ];

It should say:

rtp(profile_value, ts_stride_value, time_stride_value,
    reorder_ratio_value)
{
  UNCOMPRESSED {
    ENFORCE((profile_value == PROFILE_RTP_0101) ||
            (profile_value == PROFILE_RTP_0107));
    rtp_version =:= uncompressed_value(2, 2) [  2 ];

Notes:

rtp_version is set to 2, not to zero.

See RTP Header Fields page 115 :

Version

This field is expected to have the value two and the field is
therefore classified as STATIC-KNOWN.

Errata ID: 3248
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: FWX
Date Reported: 2012-06-07
Verifier Name: Wesley Eddy
Date Verified: 2012-08-08

Section 6.8.2.4 says:

page 67:

  COMPRESSED udp_lite_endpoint_dynamic {
    ENFORCE(profile_value == PROFILE_UDPLITE_0108);
    reserved =:= compressed_value(4, 0)                      [  4 ];
    coverage_behavior =:= irregular(2)                       [  2 ];
    reorder_ratio     =:= irregular(2)                       [  2 ];
    checksum_coverage =:=
      checksum_coverage_dynchain(coverage_behavior.UVALUE)   [ 16 ];
    checksum          =:= irregular(16)                      [ 16 ];
    msn               =:= irregular(16)                      [ 16 ];
  }

page 68:

  COMPRESSED udp_lite_regular_dynamic {
    ENFORCE(profile_value == PROFILE_RTP_0107);
    coverage_behavior =:= irregular(2)                       [  2 ];
    reserved =:= compressed_value(6, 0)                      [  6 ];
    checksum_coverage =:=
        checksum_coverage_dynchain(coverage_behavior.UVALUE) [ 16 ];
    checksum =:= irregular(16)                               [ 16 ];
  }

It should say:

page 67:

  COMPRESSED udp_lite_endpoint_dynamic {
    ENFORCE(profile_value == PROFILE_UDPLITE_0108);
    reserved =:= compressed_value(4, 0)                      [  4 ];
    coverage_behavior =:= irregular(2)                       [  2 ];
    reorder_ratio     =:= irregular(2)                       [  2 ];
    checksum_coverage =:=
      checksum_coverage_dynchain(coverage_behavior.UVALUE)   [ 0, 16 ];  <===
    checksum          =:= irregular(16)                      [ 16 ];
    msn               =:= irregular(16)                      [ 16 ];
  }

page 68:

  COMPRESSED udp_lite_regular_dynamic {
    ENFORCE(profile_value == PROFILE_RTP_0107);
    coverage_behavior =:= irregular(2)                       [  2 ];
    reserved =:= compressed_value(6, 0)                      [  6 ];
    checksum_coverage =:=
        checksum_coverage_dynchain(coverage_behavior.UVALUE) [ 0, 16 ];  <====
    checksum =:= irregular(16)                               [ 16 ];
  }

Notes:

checksum_coverage_dynchain(behavior) compression method (page 66) may compress the checksum_coverage field to 0 bits if behavior is set to UDP_LITE_COVERAGE_INFERRED.

RFC 5226, "Guidelines for Writing an IANA Considerations Section in RFCs", May 2008

Note: This RFC has been obsoleted by RFC 8126

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: gen

Errata ID: 2245
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Glen Zorn
Date Reported: 2010-05-06
Verifier Name: Russ Housley
Date Verified: 2011-12-06

Section 4.1 says:

The IESG can (and should) reject a request if another path for registration is available that is more appropriate and there is no compelling reason to use that path.

It should say:

The IESG can (and should) reject a request if another path for registration is available that is more appropriate and there is no compelling reason not to use that path.

RFC 5228, "Sieve: An Email Filtering Language", January 2008

Note: This RFC has been updated by RFC 5229, RFC 5429, RFC 6785, RFC 9042

Source of RFC: sieve (app)

Errata ID: 5579
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Thomas Schmid
Date Reported: 2018-12-19
Verifier Name: Orie Steele
Date Verified: 2024-04-01

Section 2.3. says:

   Example:  if size :over 100k { # this is a comment
                discard;
             }

It should say:

   Example:  if size :over 100K { # this is a comment
                discard;
             }

Notes:

The small "k" after the 100 is invalid syntax according the ABNF.

"8.1. Lexical Tokens" defines a number as:

number = 1*DIGIT [ QUANTIFIER ]
QUANTIFIER = "K" / "M" / "G"

Either the Quantifier needs to be extended to allow also lowercase characters or the example needs to be corrected.

RFC 5229, "Sieve Email Filtering: Variables Extension", January 2008

Note: This RFC has been updated by RFC 5173

Source of RFC: sieve (app)

Errata ID: 5015
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Stan Kalisch
Date Reported: 2017-05-10
Verifier Name: Alexey Melnikov
Date Verified: 2017-05-19

Section 3.2 says:

# Imagine the header
      # Subject: [acme-users] [fwd] version 1.0 is out
      if header :matches "Subject" "[*] *" {
          # ${1} will hold "acme-users",
          # ${2} will hold "[fwd] version 1.0 is out"
          fileinfo "INBOX.lists.${1}"; stop;
                ^
      }

It should say:

# Imagine the header
      # Subject: [acme-users] [fwd] version 1.0 is out
      if header :matches "Subject" "[*] *" {
          # ${1} will hold "acme-users",
          # ${2} will hold "[fwd] version 1.0 is out"
          fileinto "INBOX.lists.${1}"; stop;
      }

Notes:

This suggestion corrects the spelling of the "fileinto" action in the example.

RFC 5230, "Sieve Email Filtering: Vacation Extension", January 2008

Note: This RFC has been updated by RFC 8580

Source of RFC: sieve (app)

Errata ID: 2035
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Barry Leiba
Date Reported: 2010-02-08
Verifier Name: Alexey Melnikov
Date Verified: 2010-02-10

Section 5.4 says:

   Unless explicitly overridden with a :from parameter, the From field
   SHOULD be set to the address of the owner of the Sieve script.

It should say:

   Unless explicitly overridden with a :from parameter, the From field
   SHOULD be set to the address of the owner of the Sieve script.

   Informative advice: Users often have multiple email addresses, and
   "the address of the owner of the Sieve script" may offer a choice
   among several.  If the sieve processor recognizes an address
   belonging to the owner of the Sieve script in the To or Cc fields
   of the input message, then it's better to use that address for the
   From field of the generated message, rather than any other addresses
   the script's owner may also have.

Notes:

The added text represents the intent of the working group for selecting "the address of the owner" in cases where the owner has multiple addresses known to the Sieve engine. Normative text would not be appropriate here, but an informative note clarifies the WG's intent.

Errata ID: 6294
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ken Murchison
Date Reported: 2020-09-22
Verifier Name: Barry Leiba
Date Verified: 2020-10-08

Section 4.4 says:

require "vacation";
vacation :mime text:
Content-Type: multipart/alternative; boundary=foo

--foo

I'm at the beach relaxing.  Mmmm, surf...

--foo
Content-Type: text/html; charset=us-ascii

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
 "http://www.w3.org/TR/REC-html40/strict.dtd">
<HTML><HEAD><TITLE>How to relax</TITLE>
<BASE HREF="http://home.example.com/pictures/"></HEAD>
<BODY><P>I'm at the <A HREF="beach.gif">beach</A> relaxing.
Mmmm, <A HREF="ocean.gif">surf</A>...
</BODY></HTML>

--foo--
.

It should say:

require "vacation";
vacation :mime text:
Content-Type: multipart/alternative; boundary=foo

--foo

I'm at the beach relaxing.  Mmmm, surf...

--foo
Content-Type: text/html; charset=us-ascii

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
 "http://www.w3.org/TR/REC-html40/strict.dtd">
<HTML><HEAD><TITLE>How to relax</TITLE>
<BASE HREF="http://home.example.com/pictures/"></HEAD>
<BODY><P>I'm at the <A HREF="beach.gif">beach</A> relaxing.
Mmmm, <A HREF="ocean.gif">surf</A>...
</BODY></HTML>

--foo--
.
;

Notes:

The ';' terminating the vacation action command is missing.

RFC 5232, "Sieve Email Filtering: Imap4flags Extension", January 2008

Source of RFC: sieve (app)

Errata ID: 4952
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Thomas Schmid
Date Reported: 2017-02-26
Verifier Name: Alexey Melnikov
Date Verified: 2017-02-28

Section 9. Extended says:

#
# Keep all messages to or from people in my company
#
elsif anyof address :domain :is ["From", "To"] "company.example.com"
           {

It should say:

#
# Keep all messages to or from people in my company
#
elsif address :domain :is ["From", "To"] "company.example.com"
           {

Notes:

The anyof test is defined in the RFC 5228 as
anyof <tests: test-list>
test-list = "(" test *("," test) ")"

Which means the parentheses after anyof are mandatory/required.

I would suggest dropping the anyof completely. An anyof with a single test is equivalent to a single test.

Alexey Melnikov: I've updated the corrected text to match your latest suggestion.

Errata ID: 4953
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Thomas Schmid
Date Reported: 2017-02-26
Verifier Name: Alexey Melnikov
Date Verified: 2017-02-28

Section 9. Extended says:

        {
        remove "MyFlags" "\\Flagged";
        fileinto :flags "${MyFlags}" "spam";
        }
else

It should say:

        {
        removeflag "MyFlags" "\\Flagged";
        fileinto :flags "${MyFlags}" "spam";
        }
else

Notes:

Neither "fileinto", "imap4flags" or "variables" declare a "remove" action.

So this should be most likely "removeflag" instead of "remove"

RFC 5233, "Sieve Email Filtering: Subaddress Extension", January 2008

Source of RFC: sieve (app)

Errata ID: 3079
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Aaron Stone
Date Reported: 2012-01-05
Verifier Name: Pete Resnick
Date Verified: 2012-02-20

Section 4 says:

   A diagram showing the ADDRESS-PARTs of an email address where the
   detail information follows a separator character sequence of "+" is
   shown below:

          :user "+" :detail  "@" :domain
         \-----------------/
             :local-part

   A diagram showing the ADDRESS-PARTs of a email address where the
   detail information precedes a separator character sequence of "--" is
   shown below:

          :detail "--" :user  "@" :domain
         \------------------/
             :local-part

It should say:

   A diagram showing the ADDRESS-PARTs of an email address where the
   detail information follows a separator character sequence of "+" is
   shown below:

          :user "+" :detail  "@" :domain
         \-----------------/
             :localpart

   A diagram showing the ADDRESS-PARTs of an email address where the
   detail information precedes a separator character sequence of "--" is
   shown below:

          :detail "--" :user  "@" :domain
         \------------------/
             :localpart

Notes:

Throughout the document, the prose phrase "local-part" is hyphenated, while the syntactic word ":localpart" is not hyphenated. Also, correct "a email address" to "an email address"

RFC 5234, "Augmented BNF for Syntax Specifications: ABNF", January 2008

Note: This RFC has been updated by RFC 7405

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 2968
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Daniel van Vugt
Date Reported: 2011-09-12
Verifier Name: Pete Resnick
Date Verified: 2013-01-28

Section 4 says:

elements       =  alternation *c-wsp

It should say:

elements       =  alternation *WSP

Notes:

The grammar in section 4 of RFC 5234 is ambiguous. This was discovered by my own parsing code when trying to parse the ABNF grammar with itself. The ambiguity can be seen in a simplified form using the following 10 characters of input:

Input: X = Y \r \n ; Z \r \n
Offset: 0 1 2 3 4 5 6 7 8 9

My parser finds these two (ambiguous) solutions...

SOLUTION 1:

rulelist @ 0 len 10
rule @ 0 len 10
rulename @ 0 len 1 "X"
ALPHA @ 0 len 1
star_c_wsp @ 1 len 0
defined_as @ 1 len 1
star_c_wsp @ 2 len 0
elements @ 2 len 4
alternation @ 2 len 1
concatenation @ 2 len 1
repetition @ 2 len 1
element @ 2 len 1
rulename @ 2 len 1 "Y"
ALPHA @ 2 len 1
star_c_wsp @ 3 len 3
c_wsp @ 3 len 3
c_nl @ 3 len 2
CRLF @ 3 len 2
CR @ 3 len 1
LF @ 4 len 1
WSP @ 5 len 1
SP @ 5 len 1
c_nl @ 6 len 4
comment @ 6 len 4 ";Z
"
WSP_or_VCHAR @ 7 len 1
VCHAR @ 7 len 1
CRLF @ 8 len 2
CR @ 8 len 1
LF @ 9 len 1

SOLUTION 2:

rulelist @ 0 len 10
rule @ 0 len 5
rulename @ 0 len 1 "X"
ALPHA @ 0 len 1
star_c_wsp @ 1 len 0
defined_as @ 1 len 1
star_c_wsp @ 2 len 0
elements @ 2 len 1
alternation @ 2 len 1
concatenation @ 2 len 1
repetition @ 2 len 1
element @ 2 len 1
rulename @ 2 len 1 "Y"
ALPHA @ 2 len 1
star_c_wsp @ 3 len 0
c_nl @ 3 len 2
CRLF @ 3 len 2
CR @ 3 len 1
LF @ 4 len 1
star_c_wsp @ 5 len 1
c_wsp @ 5 len 1
WSP @ 5 len 1
SP @ 5 len 1
c_nl @ 6 len 4
comment @ 6 len 4 ";Z
"
WSP_or_VCHAR @ 7 len 1
VCHAR @ 7 len 1
CRLF @ 8 len 2
CR @ 8 len 1
LF @ 9 len 1


The solution to this ambiguity is to change:
elements = alternation *c-wsp
to:
elements = alternation *WSP


--VERIFIER NOTES--

The current document is clearly incorrect. However, though the solution appears correct, it has not been tested.

Errata ID: 3076
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Daniel van Vugt
Date Reported: 2012-01-04
Verifier Name: Pete Resnick
Date Verified: 2013-01-28

Section 4 says:

 rulelist       =  1*( rule / (*c-wsp c-nl) )

It should say:

 rulelist       =  1*( rule / (*WSP c-nl) )

Notes:

This errata is very similar to errata 2968, but different.

The grammar in section 4 is ambiguous. This ambiguity is revealed using 7 characters of input:
';' <CR> <LF> <SP> ';' <CR> <LF>

which produces 2 different matches (please forgive my program output):

rulelist @ 0 len 7
rulelist1 @ 0 len 3
star_c_wsp @ 0 len 0
c_nl @ 0 len 3
comment @ 0 len 3 ";\r\n"
CRLF @ 1 len 2
CR @ 1 len 1
LF @ 2 len 1
rulelist1 @ 3 len 4
star_c_wsp @ 3 len 1
c_wsp @ 3 len 1
WSP @ 3 len 1
SP @ 3 len 1
c_nl @ 4 len 3
comment @ 4 len 3 ";\r\n"
CRLF @ 5 len 2
CR @ 5 len 1
LF @ 6 len 1

-----------

rulelist @ 0 len 7
rulelist1 @ 0 len 7
star_c_wsp @ 0 len 4
c_wsp @ 0 len 4
c_nl @ 0 len 3
comment @ 0 len 3 ";\r\n"
CRLF @ 1 len 2
CR @ 1 len 1
LF @ 2 len 1
WSP @ 3 len 1
SP @ 3 len 1
c_nl @ 4 len 3
comment @ 4 len 3 ";\r\n"
CRLF @ 5 len 2
CR @ 5 len 1
LF @ 6 len 1

-----------

A solution to this ambiguity, which I have verified works, is:
rulelist = 1*( rule / (*WSP c-nl) )

This prevents the c-nl inside c-wsp from getting confused with the c-nl in rulelist.

--VERIFIER NOTES--

The current document is clearly incorrect. However, though the solution appears correct, it has not been tested.

RFC 5239, "A Framework for Centralized Conferencing", June 2008

Source of RFC: xcon (rai)

Errata ID: 4120
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christian Groves
Date Reported: 2014-09-21
Verifier Name: Orie Steele
Date Verified: 2024-04-01

Section 8.4 says:

   ...
   A media session within a conferencing system can have any number of
   floors (0 or more) that are represented by the conference identifier.
   When using SDP offer/answer exchange to negotiate a floor control
   connection with the focus using the call signaling interface, the
   unique conference identifier is contained in the 'floorid' SDP
   attribute, as defined in [RFC4583], e.g., a=floorid:1 m-stream:10 .
   Each 'floorid' attribute, representing a unique floor, has an
   'm-stream' tag containing one or more identifiers.  The identifiers
   represent individual SDP media sessions (as defined using 'm=' from
   SDP) using the SDP 'Label' attribute, as defined in [RFC4574].

It should say:

   ...   
   A media session within a conferencing system can have any number of
   floors (0 or more) that are represented by the conference identifier.
   When using SDP offer/answer exchange to negotiate a floor control
   connection with the focus using the call signaling interface, the
   unique conference identifier is contained in the 'floorid' SDP
   attribute, as defined in [RFC4583], e.g., a=floorid:1 mstrm:10 .
   Each 'floorid' attribute, representing a unique floor, has an
   'mstrm' tag containing one or more identifiers.  The identifiers
   represent individual SDP media sessions (as defined using 'm=' from
   SDP) using the SDP 'Label' attribute, as defined in [RFC4574].

Notes:

In section 6 of the RFC4583 the ABNF for the "floorid" attribute is: floor-id-attribute = "a=floorid:" token [" mstrm:" token *(SP token)]

The text string "mstrm" is used to reference the media stream rather than "m-stream" that appears in this section.

RFC 5245, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", April 2010

Note: This RFC has been obsoleted by RFC 8445, RFC 8839

Note: This RFC has been updated by RFC 6336

Source of RFC: mmusic (rai)

Errata ID: 2338
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Reif, Frank
Date Reported: 2010-07-20
Verifier Name: Robert Sparks
Date Verified: 2011-02-07

Section 15.1 says:

extension-att-name    = byte-string    ;from RFC 4566

It should say:

extension-att-name    = token    ;from RFC 4566

Notes:

"extension-att-name" may contain the SP (0x20) as defined for "byte-string" in RFC 4566.
The 'SP' character cannot be allowed within "extension-att-name" as it is also used as delimiter between "extension-att-name" and "extension-att-value".

Errata ID: 3149
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marc Petit-huguenin
Date Reported: 2012-03-07
Verifier Name: Robert Sparks
Date Verified: 2012-04-13

Section 21.1.4 says:

Type of Attribute: session-level

It should say:

Type of Attribute: media-level

Notes:

Section 15.3 clearly says that "ice-mismatch" is media-level:

'"ice-mismatch" is a media-level
attribute only, and when present in an answer, indicates that the
offer arrived with a default destination for a media component that
didn't have a corresponding candidate attribute.'

Section Section 6.1 also implies that "ice-mismatch" is media-level:

"In some cases, the answer may omit a=candidate attributes for the
media streams, and instead include an a=ice-mismatch attribute for
one or more of the media streams in the SDP."

RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2", August 2008

Note: This RFC has been obsoleted by RFC 8446

Note: This RFC has been updated by RFC 5746, RFC 5878, RFC 6176, RFC 7465, RFC 7507, RFC 7568, RFC 7627, RFC 7685, RFC 7905, RFC 7919, RFC 8447, RFC 9155

Source of RFC: tls (sec)

Errata ID: 1585
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Pasi Eronen
Date Reported: 2008-11-05
Verifier Name: Pasi Eronen
Date Verified: 2009-03-02

Section A.4.2 says:

struct {
    ClientCertificateType certificate_types<1..2^8-1>;
    DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;

It should say:

struct {
    ClientCertificateType certificate_types<1..2^8-1>;
    SignatureAndHashAlgorithm
      supported_signature_algorithms<2^16-1>;
    DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;

Notes:

The definition in Section 7.4.4 (which includes the "supported_
signature_algorithms" field) is the correct one (confirmed
by Eric Rescorla on 2009-02-27)

Errata ID: 2643
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Matt McCutchen
Date Reported: 2010-11-22
Verifier Name: Sean Turner
Date Verified: 2011-03-09

Section E.3 says:

When a TLS-capable server negotiates SSL 2.0 it SHOULD, after
decrypting the ENCRYPTED-KEY-DATA field, check that these 8 padding
bytes are 0x03.  If they are not, the server SHOULD generate a random
value for SECRET-KEY-DATA, and continue the handshake (which will
eventually fail since the keys will not match).

It should say:

When a TLS-capable server negotiates SSL 2.0 it SHOULD, after
decrypting the ENCRYPTED-KEY-DATA field, check that these 8 padding
bytes are not all 0x03.  If they are, the server SHOULD generate a random
value for SECRET-KEY-DATA, and continue the handshake (which will
eventually fail since the keys will not match).

Notes:

The condition is the wrong way around. When the bytes *are* all 0x03, that means the client supports TLS, so there must have been a version rollback attack in order for SSL 2.0 to be negotiated. For example, see the NSS implementation (line number may rot):

https://mxr.mozilla.org/mozilla/source/security/nss/lib/ssl/sslcon.c#1695

Errata ID: 2864
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfredo Pironti
Date Reported: 2011-07-19
Verifier Name: Sean Turner
Date Verified: 2012-01-09

Section A.4.2 says:

struct {
    ClientCertificateType certificate_types<1..2^8-1>;
    DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;

--- Fixed by errata 1585 to

struct {
    ClientCertificateType certificate_types<1..2^8-1>;
    SignatureAndHashAlgorithm
      supported_signature_algorithms<2^16-1>;
    DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;

It should say:

struct {
    ClientCertificateType certificate_types<1..2^8-1>;
    SignatureAndHashAlgorithm
      supported_signature_algorithms<2..2^16-2>;
    DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;

Notes:

The supported_signature_algorithms field is a variable length array. As such ceiling and floor should be specified, and they should be multiple of the base type (which is two bytes long in this case).

Errata ID: 2865
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfredo Pironti
Date Reported: 2011-07-19
Verifier Name: Sean Turner
Date Verified: 2012-01-09

Section 7.4.4 says:

struct {
    ClientCertificateType certificate_types<1..2^8-1>;
    SignatureAndHashAlgorithm
      supported_signature_algorithms<2^16-1>;
    DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;

It should say:

struct {
    ClientCertificateType certificate_types<1..2^8-1>;
    SignatureAndHashAlgorithm
      supported_signature_algorithms<2..2^16-2>;
    DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;

Notes:

The supported_signature_algorithms field is a variable length array. As such ceiling and floor should be specified, and they should be multiple of the base type (which is two bytes long in this case). See section 7.4.1.4.1 for a valid definition of this field.

Errata ID: 3122
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Daniel Otte
Date Reported: 2012-02-16
Verifier Name: Sean Turner
Date Verified: 2012-05-06

Section A.4. says:

   enum {
       hello_request(0), client_hello(1), server_hello(2),
       certificate(11), server_key_exchange (12),
       certificate_request(13), server_hello_done(14),
       certificate_verify(15), client_key_exchange(16),
       finished(20)
       (255)
   } HandshakeType;

It should say:

   enum {
       hello_request(0), client_hello(1), server_hello(2),
       certificate(11), server_key_exchange (12),
       certificate_request(13), server_hello_done(14),
       certificate_verify(15), client_key_exchange(16),
       finished(20),
       (255)
   } HandshakeType;

Notes:

The comma after finished(20) is missing in the original text.

Errata ID: 3123
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Daniel Otte
Date Reported: 2012-02-16
Verifier Name: Sean Turner
Date Verified: 2012-05-06

Section A.4.2. says:

   struct {
       select (KeyExchangeAlgorithm) {
           case dh_anon:
               ServerDHParams params;
           case dhe_dss:
           case dhe_rsa:
               ServerDHParams params;
               digitally-signed struct {
                   opaque client_random[32];
                   opaque server_random[32];
                   ServerDHParams params;
               } signed_params;
           case rsa:
           case dh_dss:
           case dh_rsa:
               struct {} ;
              /* message is omitted for rsa, dh_dss, and dh_rsa */
           /* may be extended, e.g., for ECDH -- see [TLSECC] */
   } ServerKeyExchange;

It should say:

   struct {
       select (KeyExchangeAlgorithm) {
           case dh_anon:
               ServerDHParams params;
           case dhe_dss:
           case dhe_rsa:
               ServerDHParams params;
               digitally-signed struct {
                   opaque client_random[32];
                   opaque server_random[32];
                   ServerDHParams params;
               } signed_params;
           case rsa:
           case dh_dss:
           case dh_rsa:
               struct {} ;
              /* message is omitted for rsa, dh_dss, and dh_rsa */
           /* may be extended, e.g., for ECDH -- see [TLSECC] */
       };
   } ServerKeyExchange;

Notes:

The '};' which belongs to 'select (KeyExchangeAlgorithm) {' is missing in the original text.

Errata ID: 4109
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Christopher Armstrong
Date Reported: 2014-09-11
Verifier Name: Stephen Farrell
Date Verified: 2015-03-24

Section A.4.2 says:

   opaque ASN.1Cert<2^24-1>;

It should say:

   opaque ASN.1Cert<1..2^24-1>;

Notes:

The appendix definition of ASN.1Cert leaves out the floor of the variable-length vector, which must be specified according to the vector syntax specification in section 4.3. Fortunately, the original definition of ASN.1Cert in section 7.4.2 does specify the floor as 1, so the definition in A.4.2 should be updated to match.

Errata ID: 4507
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Benjamin Kaduk
Date Reported: 2015-10-19
Verifier Name: Paul Wouters
Date Verified: 2024-01-16

Section 7.4.1.2 says:

After sending the ClientHello message, the client waits for a
ServerHello message.  Any handshake message returned by the server,
except for a HelloRequest, is treated as a fatal error.

It should say:

After sending the ClientHello message, the client waits for a
ServerHello message.  Any other handshake message returned by the
server, except for a HelloRequest, is treated as a fatal error.

Notes:

A ServerHello received after a ClientHello should not be treated as a fatal error.

Paul Wouters (AD): TLS 1.2 has been obsoleted by TLS 1.3 RFC8446. The language in that RFC does not contain the same issue (see https://datatracker.ietf.org/doc/html/rfc8446#section-4.1.2). As such, this is marked as Verified.

Errata ID: 4750
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Adrien de Croy
Date Reported: 2016-07-27
Verifier Name: Paul Wouters
Date Verified: 2024-01-16

Section 4.3 Vectors says:

The length of
   an encoded vector must be an even multiple of the length of a single
   element (for example, a 17-byte vector of uint16 would be illegal).

It should say:

The length of
   an encoded vector must be a whole multiple of the length of a single
   element (for example, a 17-byte vector of uint16 would be illegal).

Notes:

Original text implies vectors can only contain even (0,2,4,6,8...) numbers of elements. The example does not resolve this but indicates the intent is that parts of elements are not allowed. It is clear from other examples that odd numbers of elements are permitted.

Paul Wouters (AD): As TLS 1.2 is obsoleted by TLS 1.3, this errata is closed as Verified. In TLS 1.3 in RFC 8447 the text states more clearly: Here, T' occupies n bytes in the data stream, where n is a multiple of the size of T.

Errata ID: 4912
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2017-01-18
Verifier Name: Paul Wouters
Date Verified: 2024-01-16

Section A.4.1 says:

   SignatureAndHashAlgorithm
    supported_signature_algorithms<2..2^16-1>;

It should say:

   SignatureAndHashAlgorithm
    supported_signature_algorithms<2..2^16-2>;

Notes:

Error in last sentence. See errata ID 2865.

Paul Wouters (AD): From errata ID 2865: The supported_signature_algorithms field is a variable length array. As such ceiling and floor should be specified, and they should be multiple of the base type (which is two bytes long in this case). See section 7.4.1.4.1 for a valid definition of this field.
This is already fixed in TLS 1.3 RFC8446

RFC 5251, "Layer 1 VPN Basic Mode", July 2008

Source of RFC: l1vpn (rtg)

Errata ID: 1556
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-10-09
Verifier Name: Adrian Farrel
Date Verified: 2010-08-20

Section 4.1.2, Fig.4 says:

        +---------------------------------------+
        |     PPI Length (1 octet)              |
        +---------------------------------------+
        |     PPI (variable)                    |
        +---------------------------------------+
        |     CPI AFI (2 octets)                |
        +---------------------------------------+
|       |     CPI (length)                      |
        +---------------------------------------+
        |     CPI (variable)                    |
        +---------------------------------------+

          Figure 4: Auto-Discovery Information

It should say:

        +---------------------------------------+
        |     PPI Length (1 octet)              |
        +---------------------------------------+
        |     PPI (variable)                    |
        +---------------------------------------+
        |     CPI AFI (2 octets)                |
        +---------------------------------------+
|       |     CPI Length (1 octet)              |
        +---------------------------------------+
        |     CPI (variable)                    |
        +---------------------------------------+

          Figure 4: Auto-Discovery Information

Notes:

Rationale:
The name of the field in the Figure should be consistent
with the subsequent explanations in the text, and the
information presented should be comparable

Errata ID: 1557
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-10-09
Verifier Name: Adrian Farrel
Date Verified: 2010-08-20

Section 4.1.2, pg.14 says:

         ... consistent between the those providers.  [...]

It should say:

         ... consistent between those providers.  [...]

Notes:

Rationale: extraneous aricle

RFC 5252, "OSPF-Based Layer 1 VPN Auto-Discovery", July 2008

Source of RFC: l1vpn (rtg)

Errata ID: 1489
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-08-15
Verifier Name: Adrian Farrel
Date Verified: 2010-08-20

Section 3.1,1st para says:

{at the end of the first paragraph, line 2 on page 8}

    ... advertised by a specific TE.
                                 ^

It should say:

    ... advertised by a specific PE.
                                 ^

Notes:

distorting typo: TE = Traffic Engineering,
PE = Provider Edge {Router}

RFC 5254, "Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)", October 2008

Source of RFC: pwe3 (int)

Errata ID: 1792
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stewart Bryant
Date Reported: 2009-06-04
Verifier Name: Adrian Farrel
Date Verified: 2011-09-19

Section 2 says:

Single-Segment Pseudowire (SS-PW).  

A PW setup directly between two PE devices.  Each direction of an SS-PW traverses one PSN tunnel that connects the two PEs.

It should say:

Single-Segment Pseudowire (SS-PW). 

A PW set up directly between two T-PE devices. Each PW in one direction of a SS-PW traverses one PSN tunnel that connects the two T-PEs.

Notes:

The document defines two types of PE, T-PE and S-PE. An SS-PW can only exist between a pair of T-PEs, so this is an editorial rather than a technical errata.

This errata aligns the definition of SS-PW with draft-ietf-pwe3-ms-pw-arch

RFC 5255, "Internet Message Access Protocol Internationalization", June 2008

Source of RFC: imapext (app)

Errata ID: 4092
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Chris Newman
Date Reported: 2014-08-26
Verifier Name: Barry Leiba
Date Verified: 2014-08-26

Section 3.5 says:

    lang-range-quoted = astring
        ; Once any literal wrapper or quoting is removed, this
        ; follows the language-range rule in [RFC4647]

It should say:

    lang-range-quoted = astring
        ; Once any literal wrapper or quoting is removed, this
        ; follows the language-range rule in [RFC4647],
        ; or is the 7-character string "default"

Notes:

This change makes the ABNF comment match the prose and example in section 3.2.

RFC 5260, "Sieve Email Filtering: Date and Index Extensions", July 2008

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 1836
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ned Freed
Date Reported: 2009-08-22
Verifier Name: Alexey Melnikov
Date Verified: 2009-08-23

Section A says:

int jday(int year, int month, int day)
{
    int j, c, ya;

    if (month > 2)
        month -= 3;
    else
    {
        month += 9;
        year--;
    }
    c = year / 100;
    ya = year - c * 100;
    return (c * 146097 / 4 + ya * 1461 / 4 + (month * 153 + 2) / 5 +
            day + 1721119);
}

void jdate(int j, int *year, int *month, int *day)
{
    int y, m, d;

    j -= 1721119;
    y = (j * 4 - 1) / 146097;
    j = j * 4 - y * 146097 - 1;
    d = j / 4;
    j = (d * 4 + 3) / 1461;
    d = d * 4 - j * 1461 + 3;
    d = (d + 4) / 4;
    m = (d * 5 - 3) / 153;
    d = d * 5 - m * 153 - 3;
    *day = (d + 5) / 5;
    *year = y * 100 + j;
    if (m < 10)
        *month = m + 3;
    else
    {
        *month = m - 9;
        *year += 1;
    }
}

It should say:

int jday(int year, int month, int day)
{
    int c, ya;

    if (month > 2)
        month -= 3;
    else
    {
        month += 9;
        year--;
    }
    c = year / 100;
    ya = year - c * 100;
    return (c * 146097 / 4 + ya * 1461 / 4 + (month * 153 + 2) / 5 +
            day + (1721119 - 2400001));
}

void jdate(int j, int *year, int *month, int *day)
{
    int y, m, d;

    j -= (1721119 - 2400001);
    y = (j * 4 - 1) / 146097;
    j = j * 4 - y * 146097 - 1;
    d = j / 4;
    j = (d * 4 + 3) / 1461;
    d = d * 4 - j * 1461 + 3;
    d = (d + 4) / 4;
    m = (d * 5 - 3) / 153;
    d = d * 5 - m * 153 - 3;
    *day = (d + 5) / 5;
    *year = y * 100 + j;
    if (m < 10)
        *month = m + 3;
    else
    {
        *month = m - 9;
        *year += 1;
    }
}

Notes:

The sample Julian day and date routines are coded to use regular Julian dates, not the modified Julian dates specified in the RFC. The above modification adds the necessary conversion factors for modified Julian days. An unused variable (j) was also removed.

RFC 5272, "Certificate Management over CMS (CMC)", June 2008

Note: This RFC has been updated by RFC 6402

Source of RFC: pkix (sec)

Errata ID: 2063
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jim Schaad
Date Reported: 2010-03-04
Verifier Name: Tim Polk
Date Verified: 2010-04-28

Section Appendix A says:

 EnrollmentMessageSyntax
 { iso(1) identified-organization(3) dod(4) internet(1)
 security(5) mechansims(5) pkix(7) id-mod(0) id-mod-cmc2002(23) }

It should say:

 EnrollmentMessageSyntax
 { iso(1) identified-organization(3) dod(6) internet(1)
 security(5) mechansims(5) pkix(7) id-mod(0) id-mod-cmc2002(23) }

Notes:

ASN.1 Object Identifiers are assigned based on the number not the name, this means that the current module is assigned in a name space that is not under our control.

Errata ID: 7627
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Piotr Popis
Date Reported: 2023-09-04
Verifier Name: RFC Editor
Date Verified: 2023-09-05

Section 6.7 says:

See Section 5 of [CRMF] for a detailed discussion of POP.

It should say:

See Section 4 of [CRMF] for a detailed discussion of POP.

Notes:

This is a purely editorial change.

RFC 5275, "CMS Symmetric Key Management and Distribution", June 2008

Source of RFC: smime (sec)

Errata ID: 2069
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jim Schaad
Date Reported: 2010-03-06
Verifier Name: Tim Polk
Date Verified: 2010-04-28

Section Appendix A says:

CMC-CONTROL, EXTENDED-FAILURE-INFO
FROM EnrollmentMessageSyntax
    { iso(1) identified-organization(3) dod(4) internet(1) security(5)
    mechansims(5) pkix(7) id-mod(0) id-mod-cmc2002-02(53) }

It should say:

CMC-CONTROL, EXTENDED-FAILURE-INFO
FROM EnrollmentMessageSyntax
    { iso(1) identified-organization(3) dod(6) internet(1) security(5)
    mechanisms(5) pkix(7) id-mod(0) id-mod-cmc2002-02(53) }

Notes:

We corrected the object identifier to place it into the correct tree in RFC 5272, this means that it needs to get corrected here were it is imported.

Errata ID: 5943
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2019-12-21
Verifier Name: Benjamin Kaduk
Date Verified: 2019-12-24

Section 3.1.1 says:

   GLOwnerInfo ::= SEQUENCE {
     glOwnerName     GeneralName,
     glOwnerAddress  GeneralName,
     certificate     Certificates OPTIONAL }

It should say:

   GLOwnerInfo ::= SEQUENCE {
     glOwnerName     GeneralName,
     glOwnerAddress  GeneralName,
     certificates    Certificates OPTIONAL }

Notes:

The definition of GLOwnerInfo in Section 3.1.1 does not match the ASN.1 module or the discussion that follows. Changing "certificate" to "certificates" resolves this problem.

RFC 5279, "A Uniform Resource Name (URN) Namespace for the 3rd Generation Partnership Project (3GPP)", July 2008

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 1516
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-09-15
Verifier Name: Alexey Melnikov
Date Verified: 2010-11-12

Section 2, pg.2/3 says:

   Declaration of syntactic structure:

|     The Namespace Specific String (NSS) of all URNs that use the
|     "3gpp" NID will have the following structure:

           urn:3gpp:{3gpp-urn}

      where the "3gpp-urn" is a US-ASCII string that conforms to the
      NSS(Namespace Specific String) Syntax described in RFC 2141
|     [RFC2141] and defines a specific resource type.

It should say:

   Declaration of syntactic structure:

|     All URNs that use the "3gpp" NID will have the following
|     structure:

            urn:3gpp:{3gpp-urn}

      where the "3gpp-urn" is a US-ASCII string that conforms to the
      NSS(Namespace Specific String) Syntax described in RFC 2141
|     [RFC2141] and defines a specific resource.

Notes:

a) Obviously, the original clause contradicts itself.

It is impossible that the NSS is a proper subpart of itself
as would be required by the text and the syntax shown.

The corrected text resolves this partial issue, but not the
next two issues, which still remain open. Furthermore, for
logical consistency, "resource type" had to be replaced by
"resource" in the last line, to maintain the required
uniqueness property of '3gpp' URNs.

b) Even the corrected statement merely is a simple instantiation of
the general definition in RFC 2141 (Section 2, page 1), plus
giving an alias name (<3gpp-urn>) to the NSSs of '3gpp' URNs.

However, it does not cure the apparent underspecification:

The current URN Namespace registration template per BCP 66,
RFC3406, serves for "... providing a mechanism for disclosing
[the] structure of the URN namespace ..." (page 11 of RFC 3406),
but the quoted clause, as it stands, does *not*
"outline any structural features of identifiers in this namespace"
(p. 12 of RFC 3406).

RFC 5280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", May 2008

Note: This RFC has been updated by RFC 6818, RFC 8398, RFC 8399, RFC 9549

Source of RFC: pkix (sec)

Errata ID: 3579
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Timothy J. Miller
Date Reported: 2013-04-03
Verifier Name: Sean Turner
Date Verified: 2013-04-05

Section 4.2.1.4 says:

certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation

It should say:

CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation

Notes:

ASN.1 type references must begin with an upper case character. Schema in A.2 is correct.

Errata ID: 7658
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sean Mullan
Date Reported: 2023-09-26
Verifier Name: Roman Danyliw
Date Verified: 2024-01-11

Section 7.1 says:

The hyperlink to "Section 2.6.1" of RFC 4158 in this text is incorrect:

   *  In step 6, Insignificant Character Removal, perform white space
      compression as specified in Section 2.6.1, Insignificant Space
      Handling, of [RFC4518].

It currently points to https://www.rfc-editor.org/rfc/rfc5280#section-2.6.1

It should say:

It should point to https://www.rfc-editor.org/rfc/rfc4518#section-2.6.1

Notes:

Simple fix to correct an incorrect hyperlink.

RFC 5281, "Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)", August 2008

Note: This RFC has been updated by RFC 8996, RFC 9427

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 1494
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-08-22
Verifier Name: Sean Turner
Date Verified: 2011-03-09

Section 8, pg.19 says:

      Keying Material = PRF-128(SecurityParameters.master_secret, "ttls
                keying material", SecurityParameters.client_random +
                SecurityParameters.server_random)

It should say:

      Keying Material = PRF-128(SecurityParameters.master_secret,
                "ttls keying material", SecurityParameters.client_random
                + SecurityParameters.server_random)

Notes:

The string in double quotes is a cryptographically significant
protocol element and hence white space within it should be
represented faithfully and unambiguously in the published text.
The line break and additional indentation inserted into the string
during final editing of the RFC disturb the clarity of the text.

This same issue already has been discussed at length in the context
of other documents making use of the same or similar key material
derivation techniques.

RFC 5282, "Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol", August 2008

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 3605
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Wan-Teh Chang
Date Reported: 2013-04-25
Verifier Name: Sean Turner
Date Verified: 2013-05-01

Section 10.1.3 says:

   This algorithm is identical to AEAD_AES_128_GCM (see Section 5.1 of
   [RFC5116]), except that the tag length, t, is 12, and an
   authentication tag with a length of 12 octets (64 bits) is used.

It should say:

   This algorithm is identical to AEAD_AES_128_GCM (see Section 5.1 of
   [RFC5116]), except that the tag length, t, is 12, and an
   authentication tag with a length of 12 octets (96 bits) is used.

Notes:

"(64 bits)" should be changed to "(96 bits)".

Errata ID: 3606
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Wan-Teh Chang
Date Reported: 2013-04-25
Verifier Name: Sean Turner
Date Verified: 2013-05-01

Section 10.1.4 says:

   This algorithm is identical to AEAD_AES_256_GCM (see Section 5.2 of
   [RFC5116], except that the tag length, t, is 12 and an authentication
   tag with a length of 12 octets (64 bits) is used.

It should say:

   This algorithm is identical to AEAD_AES_256_GCM (see Section 5.2 of
   [RFC5116], except that the tag length, t, is 12 and an authentication
   tag with a length of 12 octets (96 bits) is used.

Notes:

"(64 bits)" should be changed to "(96 bits)".

RFC 5286, "Basic Specification for IP Fast Reroute: Loop-Free Alternates", September 2008

Note: This RFC has been updated by RFC 8518

Source of RFC: rtgwg (rtg)

Errata ID: 2323
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: András Császár
Date Reported: 2010-07-12
Verifier Name: Stewart Bryant
Date Verified: 2011-08-12

Section 3.6 says:

   16.  If D_opt(H_h.neighbor, D) < D_opt(P_i.neighbor, D) and
        D_opt(P_i.alt_next_hops, D) >= D_opt(P_i.neighbor, D), then H_h
        is a downstream alternate and P_i.alt_next_hops is simply an
        LFA.  Prefer H_h and goto Step 20.

It should say:

   16.  If D_opt(H_h.neighbor, D) < D_opt(S, D) and
        D_opt(P_i.alt_next_hops, D) >= D_opt(S, D), then H_h
        is a downstream alternate and P_i.alt_next_hops is simply an
        LFA.  Prefer H_h and goto Step 20.

RFC 5288, "AES Galois Counter Mode (GCM) Cipher Suites for TLS", August 2008

Note: This RFC has been updated by RFC 9325

Source of RFC: tls (sec)

Errata ID: 4694
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Aaron Zauner
Date Reported: 2016-05-14
Verifier Name: Stephen Farrell
Date Verified: 2016-11-24

Section 6.1 says:

   AES-GCM security requires that the counter is never reused.  The IV
   construction in Section 3 is designed to prevent counter reuse.

   Implementers should also understand the practical considerations of
   IV handling outlined in Section 9 of [GCM].

It should say:

   Security of AES-GCM requires that the "nonce" (number used once) is
   never reused.  The IV construction in Section 3 does not prevent 
   implementers from reusing the nonce by mistake.  It is paramount that 
   the implementer be aware of the security implications when a nonce 
   is reused even once. 

   Nonce reuse in AES-GCM allows for the recovery of the authentication key 
   resulting in complete failure of the mode's authenticity.  Hence, TLS 
   sessions can be effectively attacked through forgery by an adversary.
   This enables an attacker to inject data into the TLS allowing for XSS and 
   other attack vectors.

Notes:

Obviously the original wording is so ambiguous that implementers got it wrong in the real world. Related to: https://www.blackhat.com/us-16/briefings.html#nonce-disrespecting-adversaries-practical-forgery-attacks-on-gcm-in-tls

It may be worth adding a reference to [JOUX] http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/...38.../GCM/Joux_comments.pdf and maybe the paper we're intending to release on the actual HTTPS forgery/injection attack.

I'd actually like to change the nonce construction to that of the ChaCha20/Poly1305 document, but I figure this will cause massive breakage for already deployed implementations. TLS 1.3 fixes this issue per design.

RFC 5296, "EAP Extensions for EAP Re-authentication Protocol (ERP)", August 2008

Note: This RFC has been obsoleted by RFC 6696

Source of RFC: hokey (sec)

Errata ID: 1825
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Glen Zorn
Date Reported: 2009-08-10
Verifier Name: Tim Polk
Date Verified: 2010-07-20

Section 5.1 says:

   We identify two types of bootstrapping for ERP: explicit and implicit
   bootstrapping.  In implicit bootstrapping, the local ER server SHOULD
   include its domain name and SHOULD request the DSRK from the home AAA
   server during the initial EAP exchange, in the AAA message
   encapsulating the first EAP Response message sent by the peer.

It should say:

   We identify two types of bootstrapping for ERP: explicit and implicit
   bootstrapping.  In implicit bootstrapping, the local AAA client or agent 
   SHOULD include its domain name and SHOULD request the DSRK from the home AAA
   server in the AAA message encapsulating the first EAP Response message sent
   by the peer during the initial EAP exchange.

Notes:

The local ER server is an ERP entity, incapable of inserting anything into a AAA message; the ER server's purpose is to provide reauthentication services, not to edit AAA messages. Furthermore, the original text requires that the ER server unnecessarily insert itself in the path of EAP messages, slowing the initial authentication.

Errata ID: 1845
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Glen Zorn
Date Reported: 2009-08-31
Verifier Name: Tim Polk
Date Verified: 2010-03-21

Section 2 says:

An ER server is a logical entity; 
the home ER server is located on the same backend authentication 
server as the EAP server in the home domain.  The local ER server 
may not necessarily be a full EAP server.

It should say:

An ER server is a logical entity; 
it may not necessarily be co-located with, or physically part of, 
a full EAP server. 

Notes:

The original text makes two unwarranted assumptions, which the corrected text eliminates. The first assumption is that the EAP server in the home domain is located on a back-end authentication (i.e., AAA) server; the second that the home ERP server is also located there. Neither of these conditions are required and place unnecessary restrictions upon deployment options.

Errata ID: 2856
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Qin Wu
Date Reported: 2011-07-11
Verifier Name: Stephen Farrell
Date Verified: 2011-08-14

Section 5.3.2 says:

The EMSKname is in the username part of the NAI and is encoded in
hexadecimal values.  The EMSKname is 64 bits in length and so the 
username portion takes up 128 octets.

It should say:

The EMSKname is in the username part of the NAI and is encoded in
hexadecimal values.  The EMSKname is 64 bits in length and so the 
username portion takes up 16 octets.

Notes:

Verified after checking with hokey WG.

RFC 5302, "Domain-Wide Prefix Distribution with Two-Level IS-IS", October 2008

Source of RFC: isis (rtg)

Errata ID: 3994
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Amit Kalita
Date Reported: 2014-05-20
Verifier Name: Alia Atlas
Date Verified: 2014-06-10

Section 3.1 says:

L2->L1 inter-area external routes with external metric:  These are
      advertised in L1 LSPs, in TLV 130.  The up/down bit is set to one,
      metric-type is external metric.  These IP prefixes are learned via
      L2 routing, and were derived during the L1 SPF computation from
      prefixes advertised in L2 LSPs in TLV 130 with external metrics.

It should say:

L2->L1 inter-area external routes with external metric:  These are
      advertised in L1 LSPs, in TLV 130.  The up/down bit is set to one,
      metric-type is external metric.  These IP prefixes are learned via
      L2 routing, and were derived during the L2 SPF computation from
      prefixes advertised in L2 LSPs in TLV 130 with external metrics.

Notes:

The following part has been corrected:

"These IP prefixes are learned via
L2 routing, and were derived during the L1 (should be L2) SPF computation from
prefixes advertised in L2 LSPs in TLV 130 with external metrics."

The IP prefixes which are learned via L2 routing were derived during L2 SPF computation instead of L1 SPF computation from prefixes advertised in L2 LSPs. As these prefixes were originally advertised in L2 area hence the SPF for these prefixes should run on the L2 LSPs and eventually the prefixes derived through L2 LSP should be leaked into L1 area.

RFC 5303, "Three-Way Handshake for IS-IS Point-to-Point Adjacencies", October 2008

Source of RFC: isis (rtg)

Errata ID: 2587
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mohammad Fahad Imteyaz
Date Reported: 2010-10-29
Verifier Name: Stewart Bryant
Date Verified: 2011-01-28

Section 3.2 says:

Add a clause e) to the end of "Sending point-to-point IIH PDUs" (section 8.2.3 of [ISIS]):

It should say:

Add a clause e) to the end of "Sending point-to-point IIH PDUs" (section 8.2.4 of [ISIS]):

Notes:

Though the ISIS reference name in "Normative References" have been updated to "International Standard 10589:2002, Second Edition, 2002" , the section reference was still to first edition of ISO/IEC 10589

Errata ID: 2588
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mohammad Fahad Imteyaz
Date Reported: 2010-10-29
Verifier Name: Stewart Bryant
Date Verified: 2011-01-28

Section 3.2 says:

The current three-way 
state of the adjacency with its neighbor on the link (as defined 
in new section 8.2.4.1.1 introduced later in the document) SHALL 
be reported in the Adjacency Three-Way State field.

It should say:

The current three-way 
state of the adjacency with its neighbor on the link (as defined 
in new section 8.2.5.1.1 introduced later in the document) SHALL 
be reported in the Adjacency Three-Way State field.

Notes:

Though the ISIS reference name in "Normative References" have been updated to "International Standard 10589:2002, Second Edition, 2002" , the section reference was still to first edition of ISO/IEC 10589.

RFC 5307, "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", October 2008

Note: This RFC has been updated by RFC 6001, RFC 6002, RFC 7074

Source of RFC: isis (rtg)

Errata ID: 1554
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-10-09
Verifier Name: Adrian Farrel
Date Verified: 2012-08-16

Section 1.3, pg.6 says:

|  When the Switching Capability field is LSC, there is no Switching
   Capability specific information field present.

It should say:

|  When the Switching Capability field is LSC or FSC, there is no
   Switching Capability specific information field present.

Notes:

Location is the penultimate paragraph in Section 1.3, on mid-page 6.

Rationale:
In the same section, the list on top of page 5 shows the possible
Switching Capability values, their meaning and short name.
Later on, the RFC says:

The content of the Switching Capability specific information field
depends on the value of the Switching Capability field.

... and then starts to discuss the various cases.

The quoted paragraph is the last one in this discussion, and
it addresses the penultimate case in the list; the last case,
FSC, is not dealt with in any way.

Hence, the 'Switching Capability-specific information' in the
Interface Switching Capability Descriptor is underspecified.

The above correction tries to fix this deficiency to the best
knowledge of the submitter of what has been intended.

Errata ID: 4223
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alexander Okonnikov
Date Reported: 2015-01-07
Verifier Name: Alia Atlas
Date Verified: 2015-01-07

Section 1.3 says:

Maximum Link State Protocol Data Unit (LSP) Bandwidth is encoded as a
list of eight 4-octet fields in the IEEE floating point format
[IEEE], with priority 0 first and priority 7 last.

It should say:

Maximum Label Switched Path (LSP) Bandwidth is encoded as a
list of eight 4-octet fields in the IEEE floating point format
[IEEE], with priority 0 first and priority 7 last.

Notes:

Mixed up LSP abbreviation expansion.

RFC 5317, "Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile", February 2009

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rtg

Errata ID: 1710
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-03-08
Verifier Name: Adrian Farrel
Date Verified: 2010-06-11

Section 5., pg.7 says:

                v
|  Slides 47 to 48 provide a description of how the forwarding and the
   ACH OAM mechanism work in detail.  [...]

It should say:

                v
|  Slides 47 to 78 provide a description of how the forwarding and the
   ACH OAM mechanism work in detail.  [...]

Notes:

Rationale: cf. the slides!

RFC 5320, "The Subnetwork Encapsulation and Adaptation Layer (SEAL)", February 2010

Source of RFC: INDEPENDENT

Errata ID: 2105
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-04-02
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-16

Section 4.3.3, pg.19 says:

      +-------------------------+ -
      |                         |   ~ Outer */SEAL/*/IPv4 hdrs~   |
      |                         |   |
      +-------------------------+   |
      |      ICMPv4 Header      |   |
      |(Dest Unreach; Frag Need)|   |
      +-------------------------+   |
      |                         |    > Up to 576 bytes
      ~    IP/*/SEAL/*/IPv4     ~   |
      ~ hdrs of packet/fragment ~   |
      |                         |   |
      +-------------------------+   |
      |                         |   |
      ~ Data of packet/fragment ~   |
      |                         |   /
      +-------------------------+ -

       Figure 3: SEAL-Encapsulated ICMPv4 Fragmentation Needed Message

It should say:

      +-------------------------+ -
|     |                         |   \
|     ~ Outer */SEAL/*/IPv4 hdrs~   |
      |                         |   |
      +-------------------------+   |
      |      ICMPv4 Header      |   |
      |(Dest Unreach; Frag Need)|   |
      +-------------------------+   |
      |                         |    > Up to 576 bytes
      ~    IP/*/SEAL/*/IPv4     ~   |
      ~ hdrs of packet/fragment ~   |
      |                         |   |
      +-------------------------+   |
      |                         |   |
      ~ Data of packet/fragment ~   |
      |                         |   /
      +-------------------------+ -

       Figure 3: SEAL-Encapsulated ICMPv4 Fragmentation Needed Message

Notes:

(Most likely an nroff-related problem with the trailing backslash!)

Yes; clearly the diagram needs to be tidied up.

RFC 5321, "Simple Mail Transfer Protocol", October 2008

Note: This RFC has been updated by RFC 7504

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: art

Errata ID: 1683
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Roberto Javier Godoy
Date Reported: 2009-02-15
Verifier Name: Alexey Melnikov
Date Verified: 2009-09-07

Section 4.4 says:

Additional-Registered-Clauses  = CFWS Atom FWS String

It should say:

Additional-Registered-Clauses  = 1*(CFWS Atom FWS String)

Notes:

1. The rule Additional-Registered-Clauses is used by the rule Opt-info (also in section 4.4, page 59) as:

Opt-info = [Via] [With] [ID] [For] [Additional-Registered-Clauses]

2. The ABNF comment for Additional-Registered-Clauses states that "Additional standard clauses may be added in this location by future standards and registration with IANA."

3. Each sequence (CFWS Atom FWS String) represents a single clause.

Errata ID: 4198
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jasen Betts
Date Reported: 2014-12-09
Verifier Name: Barry Leiba
Date Verified: 2014-12-09

Section 4.2 says:

Whenever possible, a receiver-
SMTP SHOULD test the first digit (severity indication) of the reply
code.

It should say:

Whenever possible, a sender-
SMTP SHOULD test the first digit (severity indication) of a reply
code it receives.

Notes:

The "sender" is the entity that issues commands and receives response codes (from the "receiver").

Errata ID: 2578
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dominic Sayers
Date Reported: 2010-10-18
Verifier Name: Peter Saint-Andre
Date Verified: 2010-11-12

Section 4.1.2 says:

   Terminals not defined in
   this document, such as ALPHA, DIGIT, SP, CR, LF, CRLF, are as defined
   in the "core" syntax in Section 6 of RFC 5234 [7] or in the message
   format syntax in RFC 5322 [4].

It should say:

   Terminals not defined in
   this document, such as ALPHA, DIGIT, SP, CR, LF, CRLF, are as defined
   in the "core" syntax in Appendix B of RFC 5234 [7] or in the message
   format syntax in RFC 5322 [4].

Notes:

The core syntax of ABNF is defined in Appendix B "Core ABNF of ABNF" of RFC 5234, not Section 6, which lists the document's references.

RFC 5322, "Internet Message Format", October 2008

Note: This RFC has been updated by RFC 6854

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 1905
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Wolf Lammen
Date Reported: 2009-10-09
Verifier Name: Pete Resnick
Date Verified: 2011-06-11

Section 4.1 says:

   obs-unstruct    =   *((*LF *CR *(obs-utext *LF *CR)) / FWS)

It should say:

   obs-unstruct    =   *( (*CR 1*(obs-utext / FWS)) / 1*LF ) *CR

Notes:

It looks to me, as if the rule for obs-unstruct matches any US_ASCII character sequence, and is, hence, either overly complicated, or simply wrong. For example: CR LF 'A' is matched by the original rule (loop matches CR first, then LF 'A'). If I understand the accompaying text right, the intention was to allow for reversed sequences LF CR, as well as bare CR and LF sequences, but strictly forbid any occurrence of CR LF (in that order). This would be expressed by my rule, that basically states that any sequence of CR either is at the end, or is followed by a non-LF, or an FWS

[Alexey: removed unchanged ABNF rules, corrected an obvious error in the description of the change.]

Errata ID: 1908
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Wolf Lammen
Date Reported: 2009-10-11
Verifier Name: Alexey Melnikov
Date Verified: 2010-03-24

Section 4.2 says:

   In the obsolete syntax, any amount of folding white space MAY be
   inserted where the obs-FWS rule is allowed.  This creates the
   possibility of having two consecutive "folds" in a line, and
   therefore the possibility that a line which makes up a folded header
   field could be composed entirely of white space.

   obs-FWS         =   1*WSP *(CRLF 1*WSP)

It should say:

   In the obsolete syntax, any amount of folding white space MAY be
   inserted where the obs-FWS rule is allowed.  This creates the
   possibility of having two consecutive "folds" in a line, and
   therefore the possibility that a line which makes up a folded header
   field could be composed entirely of white space.

   obs-FWS         =   1*([CRLF] WSP)

Notes:

If I understand the relevant portions of RFC 822 right (notably section 3.1.1
["The general rule is that wherever there may be linear-white-space...
a CRLF followed by ... LWSP-char(s) may instead be inserted"], along with
section 3.1.4, section 3.3), it is permitted to extend a phrase
atom SPACE atom
by inserting linear-white-space (CRLF SPACE CRLF SPACE) instead, yielding:
atom CRLF SPACE CRLF SPACE atom
However, this is not recognized by the rules of RFC 5322, because the new
syntax forbids consecutive foldings, whereas obs-FWS requires a leading
white-space character at the beginning.

Errata ID: 3979
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Occil
Date Reported: 2014-04-30
Verifier Name: Pete Resnick
Date Verified: 2014-04-30

Section 3.6.7; 4.5.7 says:

received        =   "Received:" *received-token ";" date-time CRLF

obs-received    =   "Received" *WSP ":" *received-token CRLF

It should say:

received        =   "Received:" [1*received-token / CFWS]
                      ";" date-time CRLF

obs-received    =   "Received" *WSP ":" [1*received-token / CFWS] CRLF

Notes:

"The 'Received:' field contains a (possibly empty) list of tokens followed by a semicolon and a date-time specification." As it was originally written, though, whitespace and comments are disallowed right after the colon if the list of tokens is empty: for example, the header field "Received: ; Wed, 30 Apr 2014 00:00:00 -0000\r\n" (with a space after the first colon) would be invalid according to the current spec; only "Received:; Wed, 30 Apr 2014 00:00:00 -0000\r\n" (without a space) would be.

Verifier note: The erratum is clearly correct. There are other possible ABNF solutions, but the one above is sufficient to fix the problem.

Errata ID: 1766
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nick Levinson
Date Reported: 2009-04-16
Verifier Name: Alexey Melnikov
Date Verified: 2010-03-24

Section 3.4.1 says:

If the
string can be represented as a dot-atom (that is, it contains no
characters other than atext characters or "." surrounded by atext
characters), then the dot-atom form SHOULD be used and the quoted-
string form SHOULD NOT be used.

It should say:

If the
string can be represented as a dot-atom (that is, it contains no 
characters other than atext characters or one or more of "." 
surrounded by atext characters), then the dot-atom form SHOULD 
be used and the quoted-string form SHOULD NOT be used.

Notes:

Based on sec. 3.2.3 ("dot-atom = [CFWS] dot-atom-text [CFWS]" (brackets so in original) & "dot-atom-text = 1*atext *('.' 1*atext)") and on appx. A.1.2 (the example "john.q.public@example.com").

Errata ID: 2515
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Rushton
Date Reported: 2010-09-10
Verifier Name: Pete Resnick
Date Verified: 2011-05-16

Section Appendix A.5 says:

From: Pete(A nice \) chap) <pete(his account)@silly.test(his host)>

It should say:

From: Pete(A nice \) chap) <pete@silly.test(his host)>

Notes:

Section 3.4.1: "Comments and folding white space SHOULD NOT be used around the "@" in the addr-spec."

Errata ID: 2579
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dominic Sayers
Date Reported: 2010-10-18
Verifier Name: Pete Resnick
Date Verified: 2011-05-16

Section Appendix A.5 says:

   To:A Group(Some people)
        :Chris Jones <c@(Chris's host.)public.example>,
            joe@example.org,
     John <jdoe@one.test> (my dear friend); (the end of the group)

It should say:

   To:A Group(Some people)
        :Chris Jones <c@public.example(Chris's host.)>,
            joe@example.org,
     John <jdoe@one.test> (my dear friend); (the end of the group)

Notes:

Section 3.4.1: "Comments and folding white space SHOULD NOT be used around the "@" in the addr-spec."

Errata ID: 6920
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Klensin
Date Reported: 2022-04-05
Verifier Name: Orie Steele
Date Verified: 2024-04-01

Section 2.1 says:

and interpreted as US-ASCII [ANSI.X3-4.1986] characters.  For brevity, this document sometimes refers to this range of characters as simply "US-ASCII characters".

It should say:

and interpreted as ASCII [ANSI.X3-4.1986] characters.  For brevity, this document sometimes refers to this range of characters as simply "ASCII characters".

Notes:

The choice of "US-ASCII" as a charset name reflected circumstances at the time, but it was not then and has never been the name of a coded character set, much less the one specified in the various versions of what is now ANSI INCITS 4-1986[R2017]. The common name of the latter, both specified in the Standard and in common practice, is "ASCII" without any further qualification. "For brevity", "ASCII" is not only more accurate, but shorter. While the correction is being made, it would be wise to change the citation anchor to "[ASCII]" or, if necessary for some reason, "[ASCII1986]". The odd punctuation used in "[ANSI.X3-4.1986]" to refer to ANSI X3.4-1986 is just unnecessarily confusing.

(this erratum is being reported more or less at the request of the editor of RFC 5322 and its successor)

RFC 5326, "Licklider Transmission Protocol - Specification", September 2008

Source of RFC: IRTF

Errata ID: 1657
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-01-23
Verifier Name: Stephen Farrell
Date Verified: 2009-11-10

Section 3.1.1, pg.12 says:

   if (CTRL flag = 0)
      segment is a data segment if (EXC flag = 0)
         segment contains only red-part data if (Flag 1 = 1)
            segment is a checkpoint segment is the last segment in the
            red part of the block if (Flag 0 = 1)
               segment is the last segment in the block
         else // segment is not end of red-part
            if (Flag 0 = 1)
               segment is a checkpoint
      else
         segment contains only green-part data if (Flag 1 = 1)
            if (Flag 0 = 1)
               segment is the last segment in the block
   else
      segment is a control segment if (EXC flag = 0)
         segment pertains to report activity if (flag 0 = 0)
            segment is a report segment
         else
            segment is an acknowledgment of a report segment
      else
         segment pertains to session cancellation activity if (Flag 1 =
         0)
            segment pertains to cancellation by block sender if (Flag 0
            = 1)
               segment is a cancellation by sender
            else
               segment is an acknowledgment of a cancellation by sender
         else
            segment pertains to cancellation by block receiver if (Flag
            0 = 1)
               segment is a cancellation by receiver
            else
               segment is an acknowledgment of a cancellation by
               receiver

It should say:

   if (CTRL flag = 0)
      segment is a data segment
      if (EXC flag = 0)
         segment contains only red-part data
         if (Flag 1 = 1)
            segment is a checkpoint
            segment is the last segment in the red part of the block
            if (Flag 0 = 1)
               segment is the last segment in the block
         else // segment is not end of red-part
            if (Flag 0 = 1)
               segment is a checkpoint
      else
         segment contains only green-part data
         if (Flag 1 = 1)
            if (Flag 0 = 1)
               segment is the last segment in the block
   else
      segment is a control segment
      if (EXC flag = 0)
         segment pertains to report activity
         if (flag 0 = 0)
            segment is a report segment
         else
            segment is an acknowledgment of a report segment
      else
         segment pertains to session cancellation activity
         if (Flag 1 = 0)
            segment pertains to cancellation by block sender
|           if (Flag 0 = 0)
               segment is a cancellation by sender
            else
               segment is an acknowledgment of a cancellation by sender
         else
            segment pertains to cancellation by block receiver
|           if (Flag 0 = 0)
               segment is a cancellation by receiver
            else
               segment is an acknowledgment of a cancellation by
               receiver

Notes:

Issues:

a) Confusing placement of line breaks: "if" clauses could be
understood as postfix qualifiers, but in fact shall be prefixes
to subsequent clauses; independent statements should be separated
by line breaks.

Correction: re-formating of entire pseudocode block

b) Sense of "Flag 0" in the "CTRL=1" branches is illogical and inconsistent
with remainder of the RFC -- e.g., cf. sections 3.1.2 and 3.1.3 !

Correction: Change "if (Flag 0 = 1)" --> "if (Flag 0 = 0)"
in the two lines tagged with change bars in the corrected text.

Errata ID: 1658
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-01-23
Verifier Name: Stephen Farrell
Date Verified: 2009-11-10

Section 3.2.1, pg.16 says:

   If the data segment is a checkpoint, the segment MUST additionally
   include the following two serial numbers (checkpoint serial number
   and report serial number) to support efficient retransmission.  Data
   segments that are not checkpoints MUST NOT have these two fields in
|  the header and MUST continue on directly with the client service
       ^^^^^^ 
  data.

It should say:

   If the data segment is a checkpoint, the segment MUST additionally
   include the following two serial numbers (checkpoint serial number
   and report serial number) to support efficient retransmission.  Data
   segments that are not checkpoints MUST NOT have these two fields in
|  the segment content and MUST continue on directly with the client
       ^^^^^^^^^^^^^^^
   service data.

Notes:

Rationale:
Section 3.2 is about 'Segment Content' as defined in section 3
and depicted in the figure on page 10 of the RFC.
Accordingly, the subject two fields are *not* part of the segment
_header_, and the original text is misleading.

Additional concern (please 'Keep for Update'):
The subject two fields, checkpoint serial number and report serial
number, obviously are not in the restricted scope of the Client
Service ID -- they are related to corrresponding fields carried in
non-data segments which do not contain a Client Service ID field.
Therefore, with respect to layering considerations, it would have
been more reasonable to place the two subject fields in front of
the Client Service ID field, at the front of the data segment, to
get them conceptionally out of the scope of the Client Service ID
field governing the Offset, Length, and Client Service Data fields.

RFC 5331, "MPLS Upstream Label Assignment and Context-Specific Label Space", August 2008

Note: This RFC has been updated by RFC 7274

Source of RFC: mpls (rtg)

Errata ID: 1700
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-03-02
Verifier Name: Adrian Farrel
Date Verified: 2010-01-04

Section 7, pg. 8 says:

   Some tunnels may not even require configuration, e.g., a Generic
   Routing Encapsulation (GRE) tunnel can be "created" just by
   encapsulating packets and transmitting them.  In such a case, the IP
   address of the root is considered to be the IP source address of the
|  encapsulated packets.
             ^^ 

It should say:

   Some tunnels may not even require configuration, e.g., a Generic
   Routing Encapsulation (GRE) tunnel can be "created" just by
   encapsulating packets and transmitting them.  In such a case, the IP
   address of the root is considered to be the IP source address of the
|  encapsulation headers.
             ^^^  

Notes:

Location is 4th paragraph on page 8.

Rationale:

The term "encapsulated packets" has been variously interpretted to mean
the "payload packets that" and the "whole packets including the
encapsulation headers."

To make this completely clear, the text should be read as in the correction.

Clarifying Reference:

Earlier in the same section, the 2nd paragraph on page 7 defines
the 'root' of a tunnel:

"The root is identified by the head-end IP address of the tunnel."

Consequentially, in the case of 'ad-hoc' GRE tunnels the IP address
of the 'root' obviously is the source address in the *outer* IP
header.

RFC 5335, "Internationalized Email Headers", September 2008

Note: This RFC has been obsoleted by RFC 6532

Source of RFC: eai (app)

Errata ID: 1509
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-09-15
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-06

Section 4.5, 2nd par says:

|  The "Return-Path" header provides the email return address in the
|  mail delivery.  Thus, the header is augmented to carry UTF-8
   addresses (see the revised syntax of <angle-addr> in Section 4.4 of
   this document).  This will not break the rule of trace field
|  integrity, because the header is added at the last MTA and described
   in [RFC2821].

It should say:

|  The "Return-Path" header field provides the email return address in
|  the mail delivery.  Thus, the header field is augmented to carry
   UTF-8 addresses (see the revised syntax of <angle-addr> in Section
   4.4 of this document).  This will not break the rule of trace field
|  integrity, because the header field is added at the last MTA and
   described in [RFC2821].

Notes:

Conformance to long-standing terminology established in the IETF
requires making the precise distinction between a 'header' and the
'header fields' it is comprised of.

Most parts of this RFC do this job correctly; this paragraph is an
exception.

Errata ID: 2322
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Klensin
Date Reported: 2010-07-12
Verifier Name: Alexey Melnikov
Date Verified: 2010-07-13

Section Author info says:

Y. Abel   (in first-page header block)

Abel      (in page footers)

It should say:

A. Yang

Yang

Notes:

The author is listed in the Author's Address section as "Abel Yang (editor)", which is correct although "Abel YANG (editor)" might have been preferable. In any event, the family name is "Yang", not "Abel", so the page 1 header block, page footers, and RFC Index entries are in error.

This is fixed in draft-ietf-eai-rfc5335bis-02 and later. A successor to that document will eventually obsolete RFC 5335.

RFC 5336, "SMTP Extension for Internationalized Email Addresses", September 2008

Note: This RFC has been obsoleted by RFC 6531

Source of RFC: eai (app)

Errata ID: 1510
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-09-15
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-06

Section 3.4,pg.10 says:

   The ALT-ADDRESS-parameter MUST NOT appear more than once in any MAIL
|  or RCPT command.  ALT-ADDRESS-esmtp-value MUST be an all-ASCII email
                                ^^^^^^^
   address before xtext encoding.

It should say:

   The ALT-ADDRESS-parameter MUST NOT appear more than once in any MAIL
|  or RCPT command.  ALT-ADDRESS-value MUST be an all-ASCII email
                                ^
   address before xtext encoding.
                                

Notes:

"ALT-ADDRESS-esmtp-value" does not occur anywhere else in the RFC.
Presumably the rule names have been shortened and the edits have been
performed incompletely. "ALT-ADDRESS-value" is the rule name expected
from the ABNF above this paragraph.

Errata ID: 1511
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-09-15
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-06

Section 3.7.3,pg.13 says:

         uFor = "FOR" ( FWS (uPath / uMailbox) ) CFWS
          ; Replaces For in Section 4.4 of RFC 2821
|         ; uPath and uMailbox are defined in Sections 2.4 and
|         ; 2.3, respectively, of this document

It should say:

         uFor = "FOR" ( FWS (uPath / uMailbox) ) CFWS
          ; Replaces For in Section 4.4 of RFC 2821
|         ; uPath and uMailbox are defined in Sections 3.4 and
|         ; 3.3, respectively, of this document

Notes:

Wrong section numbers for document-internal references.

RFC 5337, "Internationalized Delivery Status and Disposition Notifications", September 2008

Note: This RFC has been obsoleted by RFC 6533

Source of RFC: eai (app)

Errata ID: 1512
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-09-15
Verifier Name: Lisa Dusseault
Date Verified: 2008-09-16

Section Heading says:

Updates: 3461, 3464, 3798

It should say:

Updates: 3461, 3462, 3464, 3798

Notes:

Within Section 4, the text in the RFC on page 8 clearly updates the
definition of the multipart/report media type defined in RFC 3642.
This should be made visible in the front matter and the metadata
of the RFC.

Errata ID: 1513
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-09-15
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-06

Section 4, pg.7 says:

|  text-fixed = %d1-9 /      ; Any Unicode character except for NUL,
|              %d11 /       ; CR and LF, encoded in UTF-8
               %d12 /
               %d14-127
     ; Same as <text> from [RFC2822], but without <obs-text>.
     ; If/when RFC 2822 is updated to disallow <obs-text>,
     ; this should become just <text>
     ; Also, if/when RFC 2822 is updated to disallow control characters
     ; this should become a reference to RFC 2822upd instead.

   utf8-text = text-fixed / UTF8-non-ascii

It should say:

|  text-fixed = %d1-9 /     ; Any US-ASCII character except for NUL,
|               %d11 /      ; CR and LF
                %d12 /
                %d14-127
     ; Same as <text> from [RFC2822], but without <obs-text>.
     ; If/when RFC 2822 is updated to disallow <obs-text>,
     ; this should become just <text>
     ; Also, if/when RFC 2822 is updated to disallow control characters
     ; this should become a reference to RFC 2822upd instead.

   utf8-text = text-fixed / UTF8-non-ascii

Notes:

The long comment as well as the subsequent definition of
<utf8-text> shows that the inline comment in the first two
lines must be in error.
The replacement inline comment is the translation of the
ABNF (assumed to be correct) to english text.

Errata ID: 1515
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-09-15
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-06

Section 5, 3rd para says:

   The MDN specification also defines the Disposition-Notification-To
|  header, which is an address header and thus follows the same 8-bit
|  rules as other address headers such as "From" and "To" when used in a
   UTF-8 header message.

It should say:

   The MDN specification also defines the Disposition-Notification-To
|  header field, which is an address header field and thus follows the
|  same 8-bit rules as other address header fields such as "From" and
   "To" when used in a UTF-8 header message.

Notes:

Long-standing terminology established in the IEFT should be applied
in this paragraph as well, making the precise distinction between a
"header" and the "header fields" it it comprised of (other parts of
the document already do it the right way).

RFC 5340, "OSPF for IPv6", July 2008

Note: This RFC has been updated by RFC 6845, RFC 6860, RFC 7503, RFC 8362, RFC 9454

Source of RFC: ospf (rtg)

Errata ID: 2078
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Acee Lindem
Date Reported: 2010-03-17
Verifier Name: Stewart Bryant
Date Verified: 2013-01-07

Section 4.8.1 says:

   o  In Step 2, when a router Vertex V has just been added to the
      shortest-path tree, there may be multiple LSAs associated with the
      router.  All router-LSAs with the Advertising Router set to V's
      OSPF Router ID MUST be processed as an aggregate, treating them as
      fragments of a single large router-LSA.  The Options field and the




Coltun, et al.              Standards Track                    [Page 45]
^L
RFC 5340                     OSPF for IPv6                     July 2008


      router type bits (bits Nt, V, E, and B) should always be taken
      from the router-LSA with the smallest Link State ID.

   o  Step 2a is not needed in IPv6, as there are no longer stub network
      links in router-LSAs.

   o  In Step 2b, if W is a router and the router-LSA V6-bit or R-bit is
      not set in the LSA options, the transit link W is ignored and V's
      next link is examined.

It should say:

   o  In Step 2, when a router Vertex V other than the root (which is
      the router doing the calculation) has just been added to the
      shortest-path tree and the router-LSA R-bit is not set in the
      LSA options, Vertex V's links are ignored and the next vertex on
      the candidate list should be examined as described in Step 3.



Coltun, et al.              Standards Track                    [Page 45]
^L
RFC 5340                     OSPF for IPv6                     July 2008


   o  Also In Step 2, when a router Vertex V has just been added to the
      shortest-path tree, there may be multiple LSAs associated with the
      router.  All router-LSAs with the Advertising Router set to V's
      OSPF Router ID MUST be processed as an aggregate, treating them as
      fragments of a single large router-LSA.  The Options field and the
      router type bits (bits Nt, V, E, and B) should always be taken
      from the router-LSA with the smallest Link State ID.

   o  Step 2a is not needed in IPv6, as there are no longer stub network
      links in router-LSAs.

   o  In Step 2b, if W is a router and the router-LSA V6-bit is not set
      in the LSA options, the transit link to W is ignored and V's next
      link is examined.

Notes:

This change corrects errata 2046 described below:

This change reflects the fact that the R-bit and the V6-bit should not be handled identically. The R-bit allows the router to participate in the IPv6 unicast topology but does not allow transit traffic. The V6-bit doesn't allow either. This problem was pointed out by Balaji Ganesh.

Michael Barnes brought up the fact that the R-Bit should be ignored in the Router-LSA for the calculating router. This errata fixes this omission in the first paragraph of the corrected text.

Errata ID: 3350
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Barnes
Date Reported: 2012-09-12
Verifier Name: Stewart Bryant
Date Verified: 2013-01-07

Section 2.7 says:

   o  Two Options bits, the "R-bit" and the "V6-bit", have been added to
      the Options field for processing router-LSAs during the SPF
      calculation (see Appendix A.2).  If the "R-bit" is clear, an OSPF
      speaker can participate in OSPF topology distribution without
      being used to forward transit traffic; this can be used in multi-
      homed hosts that want to participate in the routing protocol.  The
      V6-bit specializes the R-bit; if the V6-bit is clear, an OSPF
      speaker can participate in OSPF topology distribution without
      being used to forward IPv6 datagrams.  If the R-bit is set and the
      V6-bit is clear, IPv6 datagrams are not forwarded but datagrams
      belonging to another protocol family may be forwarded.

It should say:

   o  Two Options bits, the "R-bit" and the "V6-bit", have been added to
      the Options field for processing router-LSAs during the SPF
      calculation (see Appendix A.2).  If the "R-bit" is clear, an OSPF
      speaker can participate in OSPF topology distribution without
      being used to forward transit traffic; this can be used in multi-
      homed hosts that want to participate in the routing protocol. An
      Area Border Router MUST advertise a consistent R-bit setting in
      its self-originated router-LSAs for all attached areas. 
      The V6-bit specializes the R-bit; if the V6-bit is clear, an OSPF
      speaker can participate in OSPF topology distribution without
      being used to forward IPv6 datagrams.  If the R-bit is set and the
      V6-bit is clear, IPv6 datagrams are not forwarded but datagrams
      belonging to another protocol family may be forwarded.

Notes:

This addresses a corner case.

Errata ID: 3351
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Barnes
Date Reported: 2012-09-12
Verifier Name: Stewart Bryant
Date Verified: 2013-01-07

Section 4.4.3.4 says:

   o  Link-local addresses MUST never be advertised in inter-area-
      prefix-LSAs.

It should say:

   o  Link-local addresses MUST never be advertised in inter-area-
      prefix-LSAs.

  o   If the router's router-LSA R-bit is clear, only IPv6 prefixes
      associated with local interfaces MAY be advertised in
      inter-area-prefix-LSAs. Non-local IPv6 prefixes, e.g., those 
      advertised by other routers and installed during the SPF computation,
      MUST NOT be advertised in inter-area-prefixes-LSAs. 

Errata ID: 3352
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Barnes
Date Reported: 2012-09-12
Verifier Name: Stewart Bryant
Date Verified: 2013-01-07

Section 4.4.3.6 says:

   o  Link-local addresses can never be advertised in AS-external-LSAs.

It should say:

   o  Link-local addresses can never be advertised in AS-external-LSAs.

   o  If the router's router-LSA R-bit is clear, only IPv6 prefixes
      associated with local interfaces MAY be advertised in AS-external-LSAs.
      Non-local IPv6 prefixes, e.g., those exported from other routing
      protocols, MUST NOT be advertised in AS-external-LSAs. 

Errata ID: 3357
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: David Ward
Date Reported: 2012-09-17
Verifier Name: Stewart Bryant
Date Verified: 2013-01-07

Section C.7 says:

   Host IPv6 prefix
      An IPv6 prefix belonging to the directly connected host.  This
      must not be a valid IPv6 global prefix.

It should say:

   Host IPv6 prefix
      An IPv6 prefix belonging to the directly connected host.  This
      must be a valid IPv6 global prefix.

Notes:

http://www.ietf.org/mail-archive/web/ospf/current/msg06446.html

RFC 5345, "Simple Network Management Protocol (SNMP) Traffic Measurements and Trace Exchange Formats", October 2008

Source of RFC: IRTF

Errata ID: 1580
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-10-30
Verifier Name: Juergen Schoenwaelder
Date Verified: 2009-11-09

Section 3.8, para #2 says:

   Depending on the data recorded in a trace, it might be possible to
   determine the age of devices by looking at the values of objects such
|  as sysObjectID and sysDecr [RFC3418].  [...]

It should say:

   Depending on the data recorded in a trace, it might be possible to
   determine the age of devices by looking at the values of objects such
|  as sysObjectID and sysDescr [RFC3418].  [...]
                           ^

Notes:

See RFC 3418.

Errata ID: 1581
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-10-30
Verifier Name: Juergen Schoenwaelder
Date Verified: 2009-11-09

Section 4.1, pg.15 says:

  oid.type =
    xsd:string {
      pattern =
|       "(([0-1](\.[1-3]?[0-9]))|(2.(0|([1-9]\d*))))" ~
        "(\.(0|([1-9]\d*))){0,126}"
    }

It should say:

  oid.type =
    xsd:string {
      pattern =
|       "(([0-1](\.[1-3]?[0-9]))|(2\.(0|([1-9]\d*))))" ~
        "(\.(0|([1-9]\d*))){0,126}"
    }

Notes:

Missing backslash disturbs the pattern;
"\." is needed to make the dot literal.

RFC 5348, "TCP Friendly Rate Control (TFRC): Protocol Specification", September 2008

Source of RFC: dccp (tsv)

Errata ID: 1614
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-11-24
Verifier Name: Lars Eggert
Date Verified: 2008-11-28

Section 4.6, pg. 19 says:

<<  last paragraph of Section 4.6 >>

   For TFRC senders allowed to accumulate sending credits for unused
   send time over the last T seconds, the sender would be allowed to use
|  unused nominal send times t_j for t_j < now - T, for T set to the
   round-trip time.
                                          ^^^^

It should say:

   For TFRC senders allowed to accumulate sending credits for unused
   send time over the last T seconds, the sender would be allowed to use
|  unused nominal send times t_j for t_j < t_now - T, for T set to the
   round-trip time.
                                          ^^^^^^

Notes:

Rationale:
Consistent use of variable names.

Errata ID: 1615
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-11-24
Verifier Name: Lars Eggert
Date Verified: 2008-11-28

Section 6.2, pg.28 says:

   2)  Calculate the measured receive rate, X_recv, based on the packets
       received within the previous R_(m-1) seconds.  This is performed
       whether the feedback timer expired at its normal time or expired
|      early due to a new lost or marked packet (i.e., step (3) in
       Section 6.1).
                                                             ^

It should say:

   2)  Calculate the measured receive rate, X_recv, based on the packets
       received within the previous R_(m-1) seconds.  This is performed
       whether the feedback timer expired at its normal time or expired
|      early due to a new lost or marked packet (i.e., step (4) in
       Section 6.1).
                                                             ^

Notes:

Rationale:
The steps in 6.1 have been renumbered since RFC 3448, due to
the insertion of a new step (2); this change apparently has
been missed here.

RFC 5357, "A Two-Way Active Measurement Protocol (TWAMP)", October 2008

Note: This RFC has been updated by RFC 5618, RFC 5938, RFC 6038, RFC 7717, RFC 7750, RFC 8545

Source of RFC: ippm (ops)

Errata ID: 1587
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-11-05
Verifier Name: Lars Eggert
Date Verified: 2009-05-14

Section 3.5, pg.10 says:

<< last paragraph of 3.5 >>

   When the requested Receiver Port is not available (e.g., port in
   use), the Server at the Session-Reflector MAY suggest an alternate
   and available port for this session in the Port field.  The Session-
   Sender either accepts the alternate port, or composes a new Session-
|  Request message with suitable parameters.  Otherwise, the Server at
   vvvvvvvvvvvvvvvvvv                                    !!!!!!!!!!^^^
|  the Control-Client uses the Accept field to convey other forms of
|  session rejection or failure and MUST NOT suggest an alternate port;
                               ^
   in this case, the Port field MUST be set to zero.

It should say:

   When the requested Receiver Port is not available (e.g., port in
   use), the Server at the Session-Reflector MAY suggest an alternate
   and available port for this session in the Port field.  The Session-
   Sender either accepts the alternate port, or composes a new Session-
|  Request message with suitable parameters.  Otherwise, the Server uses
                                                                   ^
|  the Accept field to convey other forms of session rejection or
|  failure to the Control-Client and MUST NOT suggest an alternate port;
          ^^^^^^^^^^^^^^^^^^^^^^^
   in this case, the Port field MUST be set to zero.

Notes:

The original description does not match the architectural model depicted
in the figure in Section 1.2 (page 4), where the Server and the
Control-Client are distinct entities, and the TWAMP-Control messages
flow between these parties.

The proposed corrected text aims to clarify the roles.

Errata ID: 1589
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-11-05
Verifier Name: Lars Eggert
Date Verified: 2009-05-14

Section 4.2.1, pg.16 says:

<<  headline for figure on page 16  >>

|  For authenticated and encrypted modes:

It should say:

|  Plaintext format for authenticated and encrypted modes:
   ^^^^^^^^^^^^^^^^^^

Notes:

The original headline is misleading; it does *not* show the general
on-the-wire format, which is partially hidden by encryption.

Thus, the headline should be amended to avoid confusion.

Errata ID: 1590
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-11-05
Verifier Name: Lars Eggert
Date Verified: 2009-05-14

Section 4.2.1, pg.17 says:

<<  second paragraph on page 17  >>
   Sequence Number is the sequence number of the test packet according
|  to its transmit order.  It starts with zero and is incremented by one
|  for each subsequent packet.  The Sequence Number generated by the
   Session-Reflector is independent from the sequence number of the
   arriving packets.

It should say:

   Sequence Number is the sequence number of the test packet according
|  to its transmit order within the TWAMP test session.  It starts with
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|  zero and is incremented by one for each subsequent packet in the
   vvvvvvv                                                  ^^^^^^^^
|  session.  The Sequence Number generated by the Session-Reflector is
   independent from the sequence number of the arriving packets.

Notes:

In the original text, it remains unclear whether this sequence number
is maintained per session, per Session-Sender, or per Session-Reflector.

Appendix I, in the 3rd text paragraph on page 23, seems to give
a hint that the Session-Reflector generated sequence numbers might
have been intended to be generated independently per *session*.

Since similar behavior is not present in OWAMP, it ugently needs to
be specified in RFC 5357 to further interoperable implementations.

The corrected text proposed aims at cure this deficiency via a change
with minimal footprint.

Errata ID: 1593
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-11-05
Verifier Name: Lars Eggert
Date Verified: 2009-05-14

Section 8.1 and 8.2 says:

<<  Section 8.1, on top of page 22 >>

   IANA has created a TWAMP-Control Command Number registry.  TWAMP-
|  Control commands are specified by the first octet in OWAMP-Control
                                     !!!!!!!!!!!!!!!
   messages as shown in Section 3.5 of [RFC4656], and modified by this
|  document.  Thus, this registry may contain sixteen possible values.
                                              ^^^^^^^

It should say:

   IANA has created a TWAMP-Control Command Number registry.  TWAMP-
   Control commands are specified by the first octet in OWAMP-Control
   messages as shown in Section 3.5 of [RFC4656], and modified by this
|  document.  Thus, this registry may contain 256 possible values.
                                              ^^^

Notes:

Dependent second instance of the issue:

According to the quoted snippet from Section 8.1, Section 8.2 again
uses "may only contain sixteen values", which should be corrrected
in the same manner.


Rationale:

Apparently, "the first octet" will allow *256* possible values, not 16.
Therefore, without an explanation of why only 16 values are allowed,
this restriction does not make sense.

In to the lack of an explanation for the restriction, the RFC text
and the IANA registry should be changed, replacing "sixteen" by "256"
throughout.

Alternatively, a clarifying note would have to be supplied, in order
to justify the restriction.


Hint: Errata Note entered on request of the responsible AD before
resolution with the authors.

Errata ID: 5045
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Xiao Min
Date Reported: 2017-06-21
Verifier Name: Mirja Kühlewind
Date Verified: 2020-03-04

Section 4.2.1 says:

   The minimum data segment length of TWAMP-Test packets in
   unauthenticated mode is 41 octets, and 104 octets in both
   authenticated mode and encrypted modes.

It should say:

   The minimum data segment length of TWAMP-Test packets in
   unauthenticated mode is 41 octets, and 112 octets in both
   authenticated mode and encrypted modes.

Notes:

In authenticated/encrypted mode, the minimum data segment length should be 112 octets, instead of 104 octets.

Errata ID: 5046
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Xiao Min
Date Reported: 2017-06-21
Verifier Name: Mirja Kühlewind
Date Verified: 2018-11-28

Section 4.1.2 says:

   each direction of transmission (this is usually desirable).  To
   compensate for the Reflector's larger test packet format, the Sender
   appends at least 27 octets of padding in unauthenticated mode, and at
   least 56 octets in authenticated and encrypted modes.

It should say:

   each direction of transmission (this is usually desirable).  To
   compensate for the Reflector's larger test packet format, the Sender
   appends at least 27 octets of padding in unauthenticated mode, and at
   least 64 octets in authenticated and encrypted modes.

Notes:

In authenticated/encrypted mode, the minimum data segment length of TWAMP-Test and OWAMP-Test packets is 112 octets and 48 octets respectively, so the Sender should append at least 64 octets, instead of 56 octets.

RFC 5375, "IPv6 Unicast Address Assignment Considerations", December 2008

Source of RFC: v6ops (ops)

Errata ID: 3309
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Lívio Zanol Pereira de Souza Puppim
Date Reported: 2012-08-06
Verifier Name: Benoit Claise
Date Verified: 2012-08-08

Section B.2.2 says:

 B.2.2. /127 Addresses

   The usage of the /127 addresses, the equivalent of IPv4's RFC 3021
   [RFC3021], is not valid and should be strongly discouraged as
   documented in RFC 3627 [RFC3627].

It should say:

 B.2.2. /127 Addresses

   The usage of the /127 addresses, the equivalent of IPv4's RFC 3021
   [RFC3021], is valid as stated in RFC 6164 [RFC 6164].

RFC 5377, "Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents", November 2008

Note: This RFC has been obsoleted by RFC 8721

Source of RFC: ipr (gen)

Errata ID: 1725
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-03-16
Verifier Name: Russ Housley
Date Verified: 2009-07-15

Section Abstract says:

                                              v
|  [...] The Trustees of the IETF Trust accepts direction from the IETF
   regarding the rights to be granted.  [...]

It should say:

|  [...] The Trustees of the IETF Trust accept direction from the IETF
   regarding the rights to be granted.  [...]

Errata ID: 1726
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-03-16
Verifier Name: Russ Housley
Date Verified: 2009-07-15

Section 4.5,1st para says:

           [...].  It would be inappropriate and confusing if such
   additional licenses restricted the rights the IETF intends to grant
|  in the content of RFCS.
                        ^

It should say:

           [...].  It would be inappropriate and confusing if such
   additional licenses restricted the rights the IETF intends to grant
|  in the content of RFCs.
                        ^

RFC 5378, "Rights Contributors Provide to the IETF Trust", November 2008

Source of RFC: ipr (gen)

Errata ID: 6673
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jason Yundt
Date Reported: 2021-09-01
Verifier Name: RFC Editor
Date Verified: 2022-01-27

Throughout the document, when it says:

RFC 5378                   RFC 3978-incoming               November 2008

It should say:

RFC 5378             Rights Provided to IETF Trust         November 2008

Notes:

This appears at the top of every page. It looks like a placeholder title from a draft of this document made it into the final version.

RFC 5381, "Experience of Implementing NETCONF over SOAP", October 2008

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: ops

Errata ID: 1611
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-11-24
Verifier Name: ron bonica
Date Verified: 2010-11-01

Section 4.2.1,pg.15 says:

<<  example on mid-page 15 >>

   C:\NetconfServer>java -classpath .;%AXIS_HOME%\lib\axis.jar;%
   AXIS_HOME%\lib\jaxrpc.jar;%AXIS_HOME%\lib\saaj.jar;%AXIS_HOME%
   \lib\commons-logging-1.0.4.jar;%AXIS_HOME%\lib\commons-discovery-
|  0.2.jar org.apache.axis.client.AdminClient -p 832 depoy.wsdd
                                                     ^^^^^

It should say:

   C:\NetconfServer>java -classpath .;%AXIS_HOME%\lib\axis.jar;%
   AXIS_HOME%\lib\jaxrpc.jar;%AXIS_HOME%\lib\saaj.jar;%AXIS_HOME%
   \lib\commons-logging-1.0.4.jar;%AXIS_HOME%\lib\commons-discovery-
|  0.2.jar org.apache.axis.client.AdminClient -p 832 deploy.wsdd
                                                     ^^^^^^

Notes:

Rationale:
Mismatch between example and explaining text; typo?
s/depoy/deploy/

RFC 5384, "The Protocol Independent Multicast (PIM) Join Attribute Format", November 2008

Note: This RFC has been updated by RFC 7887

Source of RFC: pim (rtg)

Errata ID: 1597
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-11-17
Verifier Name: Adrian Farrel
Date Verified: 2012-05-08

Section 4, last para says:

   - The encoding type 1 has been allocated, defined as "native encoding
|    for the address family, but with zero or more PIM Join Attributes
     present", and this document is the reference.

It should say:

   - The encoding type 1 has been allocated, defined as "native encoding
|    for the address family, but with one or more PIM Join Attributes
     present", and this document is the reference.

Notes:

Rationale:

Section 3.1 of this RFC says (3rd para):
A type 1 Encoded-Source Address MUST contain at least one Join
Attribute. The way to specify that there are no Join Attributes for
a particular tree is to use the type 0 Encoded-Source Address.

Hence, having *zero* attributes in encoding type 1 is explicitely
forbidden.

Please alse have the IANA registry entry be corrected.

RFC 5385, "Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs", February 2010

Source of RFC: INDEPENDENT

Errata ID: 3781
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Martin Vigoureux
Date Reported: 2013-11-04
Verifier Name: Nevil Brownlee
Date Verified: 2013-11-18

Section 2.4.2. says:

Install the "Generic/Text Only" printer, as found under "Generic" in
the available print drivers list.  Configure the printer to save to a
file or click 'save to file' when printing.  A printed file will have
a .prn file suffix.

It should say:

Install the "Generic/Text Only" printer, as found under "Generic" in
the available print drivers list.  Configure the printer to save to a
file or click 'save to file' when printing.  Configure the paper size
to be US Letter. A printed file will have a .prn file suffix.

Notes:

Adding the information about the required paper size configuration.
Using other paper sizes (e.g., A4) leads to pagination issues.

RFC 5386, "Better-Than-Nothing Security: An Unauthenticated Mode of IPsec", November 2008

Source of RFC: btns (sec)

Errata ID: 1608
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-11-18
Verifier Name: Tim Polk
Date Verified: 2008-11-19

Section 2, pg. 3 says:

   o  Any peer that uses an IKEv2 AUTH method involving a digital
      signature (made with a private key to a public key cryptosystem)
      may match a BTNS PAD entry, provided that it matches no non-BTNS
      PAD entries.  Suitable AUTH methods as of August 2007 are: RSA
|     Digital Signature (method #1) and DSS Digital Signature (method
      #3); see [RFC4306], Section 3.8.

It should say:

   o  Any peer that uses an IKEv2 AUTH method involving a digital
      signature (made with a private key to a public key cryptosystem)
      may match a BTNS PAD entry, provided that it matches no non-BTNS
      PAD entries.  Suitable AUTH methods as of August 2007 are: RSA
|     Digital Signature (method #1) and DSA Digital Signature (method
      #3); see [RFC4306], Section 3.8.

Notes:

Rationale:

When referring to an authentication method, i.e. an algorithm,
the acronym used should designate the algorithm.

There is a particular distinction in the NIST FIPS documents:
a trailing 'S' designtes a Standard, and a trailing 'A' designates
an Algorithm.
In particular, the DSS (Digital Signature Standard, FIPS 186-2/3)
describes three different algorithms:
- the NIST's Digital Signature Algorithm (DSA),
- the Elliptic Curve Digital Signature Algorithm (ECDSA), and
- the RSA signature algorithm.

Hence, to avoid any potential confusion, "DSA" should be used to
designate the particular algorithm listed as the first item above.

RFC 5395, "Domain Name System (DNS) IANA Considerations", November 2008

Note: This RFC has been obsoleted by RFC 6195

Source of RFC: dnsext (int)

Errata ID: 2618
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Olafur Gudmundsson
Date Reported: 2010-11-10
Verifier Name: Ralph Droms
Date Verified: 2010-11-11

Section 3.1.1 says:

 1. A complete template as specified in Appendix A has been posted for
      three weeks to the namedroppers@ops.ietf.org mailing list before
      the Expert Review decision.

....and later on...

No less than three weeks and no more than six weeks after a completed
   template has been formally posted to namedroppers@ops.ietf.org, the
   selected Expert shall post a message, explicitly accepting or
   rejecting the application, to IANA, namedroppers@ops.ietf.org, and

It should say:

 1. A complete template as specified in Appendix A has been posted for
      three weeks to the dnsext@ietf.org mailing list before
      the Expert Review decision

......and later on ...

No less than three weeks and no more than six weeks after a completed
   template has been formally posted to dnsext@ietf.org, the
   selected Expert shall post a message, explicitly accepting or
   rejecting the application, to IANA, dnsext@ietf.org, and

Notes:

The DNSEXT working group has changed mailing lists to the dnsext@ietf.org.
There is also occurrence of the old mailing list address in section 3.1.2
paragraph 1, and in section 5 paragraph 3. These additional occurrences should also be changed to dnsext@ietf.org

Note (RDroms): the errata is written in this way, including the notes, because the errata submission form apparently only allows errata in one section of the doc.

RFC 5402, "Compressed Data within an Internet Electronic Data Interchange (EDI) Message", February 2010

Source of RFC: INDEPENDENT

Errata ID: 6508
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lars Eggert
Date Reported: 2021-04-02
Verifier Name: RFC Editor
Date Verified: 2021-04-02

In the Copyright Notice, it says:

(http:trustee.ietf.org/license-info)

It should say:

(http://trustee.ietf.org/license-info)

RFC 5404, "RTP Payload Format for G.719", January 2009

Source of RFC: avt (rai)

Errata ID: 3245
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ravi Kumar
Date Reported: 2012-06-04
Verifier Name: Robert Sparks
Date Verified: 2012-06-07

Section 7.1 says:

7.1.  Media Type Definition

int-delay:  
         int-delay = "int-delay:" source-delay *("," source-delay)
         source-delay = SSRC ":" delay-value
         SSRC = 1*8HEXDIG ; The 32-bit SSRC encoded in hex format
         delay-value = 1*5DIGIT ; The delay value in milliseconds
 
         Example: int-delay=ABCD1234:1000,4321DCB:640
 
         NOTE: No white space allowed in the parameter before the end of
         all the value pairs

It should say:

         int-delay = "int-delay=" source-delay *("," source-delay)
         source-delay = SSRC ":" delay-value
         SSRC = 1*8HEXDIG ; The 32-bit SSRC encoded in hex format
         delay-value = 1*5DIGIT ; The delay value in milliseconds
 
         Example: int-delay=ABCD1234:1000,4321DCB:640
 
         NOTE: No white space allowed in the parameter before the end of
         all the value pairs

Notes:

int-delay ABNF does not match example mention in RFC.

"int-delay:" need to change to "int-delay="

7.2. Mapping to SDP
o Any remaining parameters go in the SDP "a=fmtp" attribute by
copying them directly from the media type parameter string as a
semicolon-separated list of parameter=value pairs.
As per section 7.2 int-delay parameter should be part of a=fmtp line and it should have parameter as parameter=value pair.

But as per ABNF it should be int-delay:<value>

Also example mentions that int-delay=<value>

RFC 5408, "Identity-Based Encryption Architecture and Supporting Data Structures", January 2009

Source of RFC: smime (sec)

Errata ID: 5838
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2019-08-18
Verifier Name: Benjamin Kaduk
Date Verified: 2019-08-19

Section 6 says:

   IBEPublicParameters ::= SEQUENCE (1..MAX) OF
     IBEPublicParameter

It should say:

   IBEPublicParameters ::= SEQUENCE SIZE (1..MAX) OF
     IBEPublicParameter

Notes:

Need to add "SIZE" for the ASN.1 module to compile properly.

RFC 5414, "Wireless LAN Control Protocol (WiCoP)", February 2010

Note: This RFC has been obsoleted by RFC 5415

Source of RFC: INDEPENDENT

Errata ID: 6509
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lars Eggert
Date Reported: 2021-04-02
Verifier Name: RFC Editor
Date Verified: 2021-04-02

In the Copyright Notice, it says:

(http:trustee.ietf.org/license-info)

It should say:

(http://trustee.ietf.org/license-info)

RFC 5415, "Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification", March 2009

Note: This RFC has been updated by RFC 8553, RFC 8996

Source of RFC: capwap (ops)

Errata ID: 1832
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Margaret Wasserman
Date Reported: 2009-08-13
Verifier Name: Dan Romascanu
Date Verified: 2010-05-11

Section 4.6.40 says:

    4 -   Base MAC Address: The WTP's Base MAC address, which MAY be
             assigned to the primary Ethernet interface.

It should say:

     4 -   Base MAC Address: The WTP's Base MAC address MUST be
              included in the WTP Board Data message element, and MAY be
              assigned to the primary Ethernet interface.

Notes:

This is to correct the problem that the requirement for the Base MAC Address (mandatory or optional) is not defined in the spec. This change is needed to allow the MIBs to use the Base MAC Address as an index, and has been approved by the CAPWAP WG.

Errata ID: 3187
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dong-Yun Seo
Date Reported: 2012-04-11
Verifier Name: Benoit Claise
Date Verified: 2012-06-05

Section 2.3. says:

                            /-------------------------------------\
                            |          /-------------------------\|
                            |         p|                         ||
                            |    q+----------+ r +------------+  ||
                            |     |   Run    |-->|   Reset    |-\||
                            |     +----------+   +------------+ |||
                           n|  o      ^           ^     ^      s|||
                +------------+--------/           |     |       |||
                | Data Check |             /-------/    |       |||
                +------------+<-------\   |             |       |||
                                      |   |             |       |||
                       /------------------+--------\    |       |||
                      f|             m|  h|    j   v   k|       |||
               +--------+     +-----------+     +--------------+|||
               |  Join  |---->| Configure |     |  Image Data  ||||
               +--------+  n  +-----------+     +--------------+|||
                ^   |g                 i|                    l| |||
                |   |                   \-------------------\ | |||
                |   \--------------------------------------\| | |||
                \------------------------\                 || | |||
         /--------------<----------------+---------------\ || | |||
         | /------------<----------------+-------------\ | || | |||
         | |  4                          |d           t| | vv v vvv
         | |   +----------------+   +--------------+   +-----------+
         | |   |   DTLS Setup   |   | DTLS Connect |-->|  DTLS TD  |
       /-|-|---+----------------+   +--------------+ e +-----------+
       | | |    |$  ^  ^   |5  ^6         ^              ^  |w
       v v v    |   |  |   |   \-------\  |              |  |
       | | |    |   |  |   \---------\ |  |  /-----------/  |
       | | |    |   |  \--\          | |  |  |              |
       | | |    |   |     |          | |  |  |              |
       | | |    v  3|  1  |%     #   v |  |a |b             v
       | | \->+------+-->+------+   +-----------+    +--------+
       | |    | Idle |   | Disc |   | Authorize |    |  Dead  |
       | |    +------+<--+------+   +-----------+    +--------+
       | |     ^   0^  2      |!
       | |     |    |         |   +-------+
      *| |u    |    \---------+---| Start |
       | |     |@             |   +-------+
       | \->+---------+<------/
       \--->| Sulking |
            +---------+&

It should say:

                            /-------------------------------------\
                            |          /-------------------------\|
                            |         p|                         ||
                            |    q+----------+ r +------------+  ||
                            |     |   Run    |-->|   Reset    |-\||
                            |     +----------+   +------------+ |||
                           n|  o      ^           ^     ^      s|||
                +------------+--------/           |     |       |||
                | Data Check |             /-------/    |       |||
                +------------+<-------\   |             |       |||
                                      |   |             |       |||
                       /------------------+--------\    |       |||
                      f|             m|  h|    j   v   k|       |||
               +--------+     +-----------+     +--------------+|||
               |  Join  |---->| Configure |     |  Image Data  ||||
               +--------+  g  +-----------+     +--------------+|||
                ^   |e                 i|                    l| |||
                |   |                   \-------------------\ | |||
                |   \--------------------------------------\| | |||
                \------------------------\                 || | |||
         /--------------<----------------+---------------\ || | |||
         | /------------<----------------+-------------\ | || | |||
         | |  4                          |d           t| | vv v vvv
         | |   +----------------+   +--------------+   +-----------+
         | |   |   DTLS Setup   |   | DTLS Connect |-->|  DTLS TD  |
       /-|-|---+----------------+   +--------------+ c +-----------+
       | | |    |$  ^  ^   |5  ^6         ^              ^  |w
       v v v    |   |  |   |   \-------\  |              |  |
       | | |    |   |  |   \---------\ |  |  /-----------/  |
       | | |    |   |  \--\          | |  |  |              |
       | | |    |   |     |          | |  |  |              |
       | | |    v  3|  1  |%     #   v |  |a |b             v
       | | \->+------+-->+------+   +-----------+    +--------+
       | |    | Idle |   | Disc |   | Authorize |    |  Dead  |
       | |    +------+<--+------+   +-----------+    +--------+
       | |     ^   0^  2      |!
       | |     |    |         |   +-------+
      *| |u    |    \---------+---| Start |
       | |     |@             |   +-------+
       | \->+---------+<------/
       \--->| Sulking |
            +---------+&

Notes:

DTLS Connect to DTLS Teardown (c):

Join to DTLS Teardown (e):

Join to Configure (g)

RFC 5416, "Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11", March 2009

Source of RFC: capwap (ops)

Errata ID: 3682
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bulavskiy Dmitriy
Date Reported: 2013-07-15
Verifier Name: Benoit Claise
Date Verified: 2013-07-28

Section 2.4. says:

The AC will signal the update to the GTK using an IEEE 802.11
Configuration Request message, including an IEEE 802.11 Update WLAN
message element with the new GTK, its index, the Transmit Sequence
Counter (TSC) for the Group Key and the Key Status set to 3 (begin
GTK update).
...
When the AC has completed the GTK update to all
STAs in the BSS, the AC MUST transmit an IEEE 802.11 Configuration
Request message including an IEEE 802.11 Update WLAN message element
containing the new GTK, its index, and the Key Status set to 4 (GTK
update complete).

It should say:

The AC will signal the update to the GTK using an IEEE 802.11
Configuration Request message, including an IEEE 802.11 Update WLAN
message element with the new GTK, its index, the Transmit Sequence
Counter (TSC) for the Group Key and the Key Status set to 2 (begin
GTK update).
...
When the AC has completed the GTK update to all
STAs in the BSS, the AC MUST transmit an IEEE 802.11 Configuration
Request message including an IEEE 802.11 Update WLAN message element
containing the new GTK, its index, and the Key Status set to 3 (GTK
update complete).

Notes:

Key Status field is defined as follows:
2 - The value of 2 indicates that the AC will begin rekeying the
GTK with the STA's in the BSS. It is only valid when IEEE
802.11 is enabled as the security policy for the BSS.

3 - The value of 3 indicates that the AC has completed rekeying
the GTK and broadcast packets no longer need to be duplicated
and transmitted with both GTK's.

RFC 5423, "Internet Message Store Events", March 2009

Source of RFC: lemonade (app)

Errata ID: 1748
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-03-30
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-06

Section 6, 3rd para says:

   Using IANA Considerations [RFC5226] terminology, entries that do not
|  start with "vnd." are allocated by IETF Consensus, while those
   starting with "vnd." are allocated First Come First Served.

It should say:

   Using IANA Considerations [RFC5226] terminology, entries that do not
|  start with "vnd." are allocated by IETF Review, while those starting
   with "vnd." are allocated First Come First Served.

Notes:

Rationale:
BCP 26, RFC 5226, does not define "IETF Consensus" any more;
this term has been functionally replaced by "IETF Review".

RFC 5438, "Instant Message Disposition Notification (IMDN)", February 2009

Source of RFC: simple (rai)

Errata ID: 3850
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Niket Kumar
Date Reported: 2013-12-26
Verifier Name: Richard Barnes
Date Verified: 2013-12-27

Section 8.3 says:

   The aggregated IMDN is constructed using the multipart/mixed MIME
   type and including as individual payloads all the IMDNS that were
   received as message/imdn+xml.

   Below is an example of aggregated IMDNs.

   From: Bob <im:bob@example.com>
   To: Alice <im:alice@example.com>
   NS: imdn <urn:ietf:params:imdn>
   imdn.Message-ID: d834jied93rf
   Content-type: multipart/mixed;
                      boundary="imdn-boundary"
   Content-Disposition: notification
   Content-length: ...

   --imdn-boundary
   Content-type: message/imdn+xml

   <?xml version="1.0" encoding="UTF-8"?>
   <imdn xmlns="urn:ietf:params:xml:ns:imdn">
         <message-id>34jk324j</message-id>
         <datetime>2008-04-04T12:16:49-05:00</datetime>
        <recipient-uri>im:bob@example.com</recipient-uri>
         <original-recipient-uri
           >im:bob@example.com</original-recipient-uri>
         <delivery-notification>
            <status>
               <delivered/>
            </status>
         </delivery-notification>
       </imdn>

   --imdn-boundary
   Content-type: message/imdn+xml

   <?xml version="1.0" encoding="UTF-8"?>
   <imdn xmlns="urn:ietf:params:xml:ns:imdn">
         <message-id>34jk324j</message-id>
         <datetime>2008-04-04T12:16:49-05:00</datetime>
        <recipient-uri>im:bob@example.com</recipient-uri>
         <original-recipient-uri
            >im:bob@example.com</original-recipient-uri>
         <display-notification>
            <status>
               <displayed/>
            </status>
         </display-notification>
       </imdn>

   --imdn-boundary

It should say:

   The aggregated IMDN is constructed using the multipart/mixed MIME
   type and including as individual payloads all the IMDNS that were
   received as message/imdn+xml.

   Below is an example of aggregated IMDNs.

   From: Bob <im:bob@example.com>
   To: Alice <im:alice@example.com>
   NS: imdn <urn:ietf:params:imdn>
   imdn.Message-ID: d834jied93rf
   Content-type: multipart/mixed;
                      boundary="imdn-boundary"
   Content-Disposition: notification
   Content-length: ...

   --imdn-boundary
   Content-type: message/imdn+xml

   <?xml version="1.0" encoding="UTF-8"?>
   <imdn xmlns="urn:ietf:params:xml:ns:imdn">
         <message-id>34jk324j</message-id>
         <datetime>2008-04-04T12:16:49-05:00</datetime>
        <recipient-uri>im:bob@example.com</recipient-uri>
         <original-recipient-uri
           >im:bob@example.com</original-recipient-uri>
         <delivery-notification>
            <status>
               <delivered/>
            </status>
         </delivery-notification>
       </imdn>

   --imdn-boundary
   Content-type: message/imdn+xml

   <?xml version="1.0" encoding="UTF-8"?>
   <imdn xmlns="urn:ietf:params:xml:ns:imdn">
         <message-id>34jk324j</message-id>
         <datetime>2008-04-04T12:16:49-05:00</datetime>
        <recipient-uri>im:bob@example.com</recipient-uri>
         <original-recipient-uri
            >im:bob@example.com</original-recipient-uri>
         <display-notification>
            <status>
               <displayed/>
            </status>
         </display-notification>
       </imdn>

   --imdn-boundary--

Notes:

The last multipart MIME boundary should have a "--" at the end. In the above example it should be "--imdn-boundary--" instead of "--imdn-boundary"

RFC 5439, "An Analysis of Scaling Issues in MPLS-TE Core Networks", February 2009

Source of RFC: mpls (rtg)

Errata ID: 1693
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-02-22
Verifier Name: Adrian Farrel
Date Verified: 2009-08-24

Section 5 says:

   Consider the requirement for a full mesh of LSPs linking all PEs.
|  That is, each PE has an LSP to and from every other LSP.  Thus, if
                                                       ^^^
   there are S(PE) PEs in the network, there are S(PE)*(S(PE) - 1) LSPs.

It should say:

   Consider the requirement for a full mesh of LSPs linking all PEs.
|  That is, each PE has an LSP to and from every other PE.  Thus, if
                                                       ^^
   there are S(PE) PEs in the network, there are S(PE)*(S(PE) - 1) LSPs.

Notes:

Rationale:
Distorting confusion of abbreviations.
The LSPs under consideration extend from one PE to another PE.

RFC 5440, "Path Computation Element (PCE) Communication Protocol (PCEP)", March 2009

Note: This RFC has been updated by RFC 7896, RFC 8253, RFC 8356, RFC 9488

Source of RFC: pce (rtg)

Errata ID: 2940
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ramon Casellas
Date Reported: 2011-08-18
Verifier Name: Adrian Farrel
Date Verified: 2011-08-19

Section 5 says:

PCEP operates over TCP using a registered TCP port (4189).  This allows 
the requirements of reliable messaging and flow control to be met without 
further protocol work.  All PCEP messages MUST be sent using the registered 
TCP port for the source and destination TCP port.

It should say:

PCEP operates over TCP using a registered TCP port (4189).  This allows 
the requirements of reliable messaging and flow control to be met without 
further protocol work.  A PCE MUST listen for incoming connections at the 
registered port and a PCC SHOULD use the registered port as source port 
but MAY use any source port (e.g. ephemeral port).

Notes:

As discussed / agreed during IETF80, IETF81 and following chairs / AD suggestion

Errata ID: 2941
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ramon Casellas
Date Reported: 2011-08-18
Verifier Name: Adrian Farrel
Date Verified: 2011-08-19

Section 10.7.1 says:

 o  PCEP uses a single registered port for all communications.  The
    PCE SHOULD listen for TCP connections only on ports where
    communication is expected.

 o  The PCE SHOULD NOT allow parallel TCP connections from the same
    PCC on the PCEP-registered port.

It should say:

 o  PCEP uses a single registered port for all communications.  The
    PCE MUST listen for TCP connections only on ports where
    communication is expected.

 o  The PCE MUST NOT allow parallel TCP connections from the same
    PCC on the PCEP-registered port.

Notes:

RFC 5440 is not consistent regarding the use of RFC2119 keywords. In section 5 the RFC states "MUST" regarding the registered port and in section 10.7.1 it is stated "SHOULD". Section 10.7.1 seems to imply the PCE could listen at any port (which is technically possible, but not in line with the rest of the document). Finally, the restriction about multiple connections is confusing: Section 4.2.1 "Only one PCEP session can exist between a pair of PCEP peers at any one time" but section 10.7.1 uses "SHOULD NOT". Technically, without the TCP source restriction, it should be possible to accept multiple connections from a PCEP peer, but such a change could have broader implications

Errata ID: 4555
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mahendra Singh Negi
Date Reported: 2015-12-06
Verifier Name: Deborah Brungard
Date Verified: 2015-12-30

In Appendix A

   The following set of variables are initialized:

      TCPRetry=0,

It should say:

   The following set of variables are initialized:

      ConnectRetry=0,

Notes:

Variable TCPRetry is not defined, defined variable is
ConnectRetry.

Errata ID: 4956
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Adrian Farrel
Date Reported: 2017-03-01
Verifier Name: Deborah Brungard
Date Verified: 2017-03-02

Section 9.3 says:

Notes:

This section does not tell IANA the range for the Object-Types to be registered for each Object-Class, nor what to do with the values not assigned in this document.

IANA has correctly recognised that the top value is 15, and that the values between those shown here and 15 should be marked as "Unassigned."

However, there is confusion over the value 0 for an Object-Type. The old entries (arising from RFC 5440) do not mention 0. Newer entries for RFC 7470 and several I-Ds in the pipe mark 0 as Unassigned.

For consistency, ALL 0 Object-Types should be marked "Reserved".

(This might need an Errata Report against some other RFCs if you are particularly fussy, but I think we can do it all on this report.)

RFC 5441, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", April 2009

Source of RFC: pce (rtg)

Errata ID: 1762
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: RFC Editor
Date Reported: 2009-04-14
Verifier Name: Ross Callon
Date Verified: 2009-04-15

Section 15.3 says:

   IANA has allocated the following allocation value:

      Bit number  Meaning                  Reference
         4        BRPC path computation    This document
                  chain unavailable

It should say:

   IANA has allocated the following allocation value:

      Bit number  Meaning                  Reference
         28       BRPC path computation    This document
                  chain unavailable

Notes:

The bit number is 28.

The error was noted by Pearl Liang of IANA.

RFC 5444, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format", February 2009

Note: This RFC has been updated by RFC 7631, RFC 8245

Source of RFC: manet (rtg)

Errata ID: 3496
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Christopher Dearlove
Date Reported: 2013-02-25
Verifier Name: Adrian Farrel
Date Verified: 2013-02-28

Section Appendix A says:

   o  The <pkt-seq-num> field, if present, contains a sequence number
      that is incremented by 1 for each packet generated by a node.  The
      sequence number after 65535 is 0.  In other words, the sequence
      number "wraps" in the usual way.

It should say:

   o  The <pkt-seq-num> field, if present, contains a sequence number
      that SHOULD be maintained for each participating interface and
      incremented by 1 for each packet generated by a node for that
      interface.  The sequence number after 65535 is 0.  In other words,
      the sequence number "wraps" in the usual way.

Notes:

Packet sequence number should be per interface, not per node. Uses that recognise missing packet sequence numbers only work in the corrected (intended) case.

Errata ID: 1790
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yannick Lacharité
Date Reported: 2009-06-02
Verifier Name: Adrian Farrel
Date Verified: 2011-08-04

Section Appendix E says:

[...]

The packet contains a single message with length 54 octets.
                                                  ^
[...]

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 1 0 0 0|    Packet Sequence Number     | Message Type  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1 1 1 1 0 0 1 1|0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 0|   Orig Addr   |
                                                    ^

It should say:

[...]

The packet contains a single message with length 55 octets.
                                                  ^
[...]

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 1 0 0 0|    Packet Sequence Number     | Message Type  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1 1 1 1 0 0 1 1|0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 1|   Orig Addr   |
                                                    ^

Notes:

Correction to the message length, which is 55 instead of 54.

Errata ID: 3497
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christopher Dearlove
Date Reported: 2013-02-25
Verifier Name: Adrian Farrel
Date Verified: 2013-02-28

Section Appendix D.6 says:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |0|0|0|0|1|M|Rsv|            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                             Value                             |
     |                                                               |
     |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |
     +-+-+-+-+-+-+-+-+

It should say:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |0|0|0|1|1|M|Rsv|            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                             Value                             |
     |                                                               |
     |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |
     +-+-+-+-+-+-+-+-+

Notes:

Corrects example TLV to have correct <tlv-flags> bits.

Errata ID: 4003
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christopher Dearlove
Date Reported: 2014-05-29
Verifier Name: Adrian Farrel
Date Verified: 2014-05-29

Section Appendix B says:

  o  <msg-hop-limit> field, if present, contains the number of hops on
     which the packet is allowed to travel before being discarded by a
     MANET router.  The <msg-hop-limit> is set by the message
     originator and is used to prevent messages from endlessly
     circulating in a MANET.  When forwarding a message, a MANET router
     should decrease the <msg-hop-limit> by 1, and the message should
     be discarded when <msg-hop-limit> reaches 0.

  o  <msg-hop-count> field, if present, contains the number of hops on
     which the packet has traveled across the MANET.  The <msg-hop-
     count> is set to 0 by the message originator and is used to
     prevent messages from endlessly circulating in a MANET.  When
     forwarding a message, a MANET router should increase <msg-hop-
     count> by 1 and should discard the message when <msg-hop-count>
     reaches 255.

It should say:

  o  <msg-hop-limit> field, if present, contains the number of hops on
     which the message is allowed to travel before being discarded by a
     MANET router.  The <msg-hop-limit> is set by the message
     originator and is used to prevent messages from endlessly
     circulating in a MANET.  When forwarding a message, a MANET router
     should decrease the <msg-hop-limit> by 1, and the message should
     be discarded when <msg-hop-limit> reaches 0.

  o  <msg-hop-count> field, if present, contains the number of hops on
     which the message has traveled across the MANET.  The <msg-hop-
     count> is set to 0 by the message originator and is used to
     prevent messages from endlessly circulating in a MANET.  When
     forwarding a message, a MANET router should increase <msg-hop-
     count> by 1 and should discard the message when <msg-hop-count>
     reaches 255.

Notes:

Two changes of "packet" to "message". Message is consistent with the normative Section 5.2 that defines these fields (which may appear in each message, so are not uniquely defined for a packet), the text introducing these bullet points, and the remainder of these paragraphs.

(Note that the original and corrected text has had indentation reduced by one space.)

Errata ID: 4178
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ronald in 't Velt
Date Reported: 2014-11-13
Verifier Name: Adrian Farrel
Date Verified: 2014-11-18

Section 6.5.1 says:

When an Address Block TLV Type is registered, then a new registry for
type extensions of that type must be created.  A document that
defines a Message TLV Type MUST also specify the mechanism by which
its type extensions are allocated, from among those in [BCP26].

It should say:

When an Address Block TLV Type is registered, then a new registry for
type extensions of that type must be created.  A document that
defines an Address Block TLV Type MUST also specify the mechanism by
which its type extensions are allocated, from among those in [BCP26].

Notes:

'Message TLV Type' should read 'Address Block TLV Type'. This is likely a 'Copy-Paste' error from section 6.4.1, which stipulates a similar requirement for Message TLV Type Extension Registry creation.

RFC 5445, "Basic Forward Error Correction (FEC) Schemes", March 2009

Source of RFC: rmt (tsv)

Errata ID: 1717
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-03-15
Verifier Name: Magnus Westerlund
Date Verified: 2009-03-27

Section 9, pg.16 says:

last paragraph at the bottom of page 16:

   This document assigns the Under-Specified FEC Encoding ID 128 under
   the ietf:rmt:fec:encoding name-space (which was previously assigned
|  by [RFC3452]) to "Small Block, Large Block, and Please note that we
|  have added a comma between large block and expandable throughout this
|  document (RFC Editor style is to include a comme before the last item
|  of a series).  If you do not object, we will ask IANA to include this
|  comma in their registry for consistency. --> Expandable FEC Codes" as
   specified in Section 4 above.

It should say:

   This document assigns the Under-Specified FEC Encoding ID 128 under
   the ietf:rmt:fec:encoding name-space (which was previously assigned
|  by [RFC3452]) to "Small Block, Large Block, and Expandable FEC Codes"
   as specified in Section 4 above.

Notes:

Apparently an xml source flaw carried over to final version.

RFC 5447, "Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction", February 2009

Source of RFC: dime (ops)

Errata ID: 3034
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Romain Kuntz
Date Reported: 2011-11-22
Verifier Name: ron bonica
Date Verified: 2011-12-06

Section 4.2.5 says:

The following examples show how the LOCAL_HOME_AGENT_ASSIGNMENT
(referred to as LOCAL-bit in the examples) capability and the MIP-
Agent-Info AVP 

It should say:

The following examples show how the LOCAL_HOME_AGENT_ASSIGNMENT
(referred to as LOCAL-bit in the examples) capability and the MIP6-
Agent-Info AVP 

Notes:

There is no such thing as the "MIP-Agent-Info" AVP, it should be "MIP6-Agent-Info"

RFC 5454, "Dual-Stack Mobile IPv4", March 2009

Source of RFC: mip4 (int)

Errata ID: 1718
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-03-15
Verifier Name: Brian Haberman
Date Verified: 2013-03-16

Section 2.1, pg.5 says:

   Prefix Length

      A sixteen-byte field containing the Mobile IPv6 Network Prefix;
      all insignificant (low-order) bits (beyond the Prefix Length) MUST
      be set to 0 by the originator of the option and ignored by the
      receiver.

   Mobile IPv6 Network Prefix

      A sixteen-byte field containing the Mobile IPv6 Network Prefix

It should say:

   Prefix Length

|     Indicates the prefix length of the prefix included in the Mobile
|     IPv6 Network Prefix field.  A value of 255 indicates that a link-
|     local address is included in the Mobile IPv6 Network Prefix field.

   Mobile IPv6 Network Prefix

|     A sixteen-byte field containing the Mobile IPv6 Network Prefix;
|     all insignificant (low-order) bits (beyond the Prefix Length) MUST
|     be set to 0 by the originator of the option and ignored by the
|     receiver.

Notes:

The replacement text apparently has been placed into the wrong
field explanation.
The text presented for "Prefix Length" is the text that should
be specified for "Mobile IPv6 Network Prefix"; the correct text
for "Prefix Length" (as shown above) is borrowed from Section 2.2.

RFC 5455, "Diffserv-Aware Class-Type Object for the Path Computation Element Communication Protocol", March 2009

Source of RFC: pce (rtg)

Errata ID: 3396
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dana Kutenicsova
Date Reported: 2012-10-30
Verifier Name: Adrian Farrel
Date Verified: 2012-11-04

Section 3.2 says:

<request>::= <RP>
             <END-POINTS>
             [<CLASSTYPE>]
             [<LSPA>]
             [<BANDWIDTH>]
             [<metric-list>]
             [<RRO>]
             [<IRO>]
             [<LOAD-BALANCING>]

It should say:

<request>::= <RP>
             <END-POINTS>
             [<CLASSTYPE>]
             [<LSPA>]
             [<BANDWIDTH>]
             [<metric-list>]
             [<RRO>[<BANDWIDTH>]]
             [<IRO>]
             [<LOAD-BALANCING>] 

Notes:

Reoptimization BANDWIDTH object was allowed to appear as BANDWIDTH to RRO in PCReq message in draft-ietfd-pce-pcep-10, which became RFC5440. This change was never reflected in the history of RFC5455.

RFC 5457, "IANA Considerations for IAX: Inter-Asterisk eXchange Version 2", February 2010

Source of RFC: INDEPENDENT

Errata ID: 2871
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Cullen Jennings
Date Reported: 2011-07-27
Verifier Name: Nevil Brownlee
Date Verified: 2011-11-23

Section 2.6 says:

0x34 | OSPTOKEN       | OSP Token Block     

It should say:

0x35 | OSPTOKEN       | OSP Token Block     

Notes:

The token value in the RFC is wrong - it should have been 0x35 not 0x34. This change has been reviewed by expert review for the IANA registry (Cullen Jennings), the responsible AD ( Robert Sparks) and Kevin Fleming and other developers of systems that implement this protocol.

RFC 5458, "Security Requirements for the Unidirectional Lightweight Encapsulation (ULE) Protocol", March 2009

Source of RFC: ipdvb (int)

Errata ID: 1746
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-03-30
Verifier Name: Ted Lemon
Date Verified: 2013-03-16

Section 2 says:

[[ at the bottom of page 5 / top of page 6 ]]

   TS: Transport Stream [ISO-MPEG2].  A method of transmission at the
   MPEG-2 layer using TS Packets; it represents Layer 2 of the ISO/OSI
   reference model.  See also TS Logical Channel and TS Multiplex.
                              ^^^^^^^^^^^^^^^^^^^^^^^

<< page break >>

   TS Multiplex: In this document, ...

It should say:

   TS: Transport Stream [ISO-MPEG2].  A method of transmission at the
   MPEG-2 layer using TS Packets; it represents Layer 2 of the ISO/OSI
   reference model.  See also TS Logical Channel and TS Multiplex.

   TS Logical Channel: Transport Stream Logical Channel.  In this
   document, this term identifies a channel at the MPEG-2 level
   [ISO-MPEG2].  It exists at level 2 of the ISO/OSI reference model.
   All packets sent over a TS Logical Channel carry the same PID value
   (this value is unique within a specific TS Multiplex).  The term
   "Stream" is defined in MPEG-2 [ISO-MPEG2] to describe the content
   carried by a specific TS Logical Channel (see ULE Stream).  Some PID
   values are reserved (by MPEG-2) for specific signalling.  Other
   standards (e.g., ATSC, DVB) also reserve specific PID values.

   TS Multiplex: In this document, ...

Notes:

The quoted keyword explanation for "TS Logical Channel"
is missing in Section 2.

Authors/Verifiers:
Please restore the entry and fill in the missing Corrected Text.

RFC 5460, "DHCPv6 Bulk Leasequery", February 2009

Note: This RFC has been updated by RFC 7653

Source of RFC: dhc (int)

Errata ID: 3571
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sunil M Gandhewar
Date Reported: 2013-03-28
Verifier Name: Ted Lemon
Date Verified: 2013-04-03

Section 5.2.1 says:

5.2.1. LEASEQUERY-DATA

The LEASEQUERY-DATA message carries data about a single DHCPv6
client’s leases and/or PD bindings on a single link. The purpose of
the message is to reduce redundant data when there are multiple
bindings to be sent. The LEASEQUERY-DATA message MUST be preceded by
a LEASEQUERY-REPLY message. The LEASEQUERY-REPLY carries the query’s
status, the Leasequery’s Client-ID and Server-ID options, and the
first client’s binding data if the query was successful.

LEASEQUERY-DATA MUST ONLY be sent in response to a successful
LEASEQUERY, and only if more than one client’s data is to be sent.
The LEASEQUERY-DATA message’s transaction-id field MUST match the
transaction-id of the LEASEQUERY request message. The Server-ID,
Client-ID, and OPTION_STATUS_CODE options SHOULD NOT be included:
that data should be constant for any one Bulk Leasequery reply, and
should have been conveyed in the LEASEQUERY-REPLY message.

It should say:

5.2.1. LEASEQUERY-DATA

The LEASEQUERY-DATA message carries data about a single DHCPv6
client’s leases and/or PD bindings on a single link. The purpose of
the message is to reduce redundant data when there are multiple
bindings to be sent. The LEASEQUERY-DATA message MUST be preceded by
a LEASEQUERY-REPLY message. The LEASEQUERY-REPLY carries the query’s
status, the Leasequery’s Client-ID and Server-ID options, and the
first client’s binding data if the query was successful.

LEASEQUERY-DATA MUST ONLY be sent in response to a successful
LEASEQUERY, and only if more than one client’s data is to be sent.
The LEASEQUERY-DATA message’s transaction-id field MUST match the
transaction-id of the LEASEQUERY request message. The Server-ID,
requestor's Client-ID, and OPTION_STATUS_CODE options SHOULD NOT be included:
that data should be constant for any one Bulk Leasequery reply, and
should have been conveyed in the LEASEQUERY-REPLY message.

Notes:

The term "Client-Id" in second paragraph sounds like client's Client-Id and it will be different for more than one client's data. So it should be corrected to "requestor's Client-ID" or "Leasequery's Client-ID" instead of just "Client-ID".

Mark Stapp reviewed this erratum and agrees that it is an improvement. Thanks!

RFC 5462, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", February 2009

Source of RFC: mpls (rtg)

Errata ID: 1704
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-03-03
Verifier Name: Adrian Farrel
Date Verified: 2010-08-19

Section 2.3, pg.7 says:

In the updated text for RFC 5129, section 2, bullet 5:

     ... TC-capable, ...
         ^^

It should say:

     ... ECN-capable, ...
         ^^^

Notes:

Rationale:
Presumed editing flaw introduces undefined term; "ECN-capable"
occurs in the same paragraph, "TC-capable" nowhere else! ==> This
extraneous change of the original RFC 5129 text should be backed out.

RFC 5464, "The IMAP METADATA Extension", February 2009

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 1691
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-02-22
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-11

Section 3.1,2nd para says:

   For example, a general comment being added to a mailbox may have an
|  entry name of "/comment" and a value of "Really useful mailbox".
                  ^^^^^^^^

It should say:

   For example, a general comment being added to a mailbox may have an
|  entry name of "/shared/comment" and a value of "Really useful
   mailbox".

Notes:

Rationale:
The example given in the Original Text violates the rules for
the formation of entry names specifcied later in the RFC
(cf. section 3.2 ff.), and is therefore considered confusing.

Errata ID: 1692
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-02-22
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-11

Section 4.3, pg.11 says:

       Arguments:  mailbox-name
|                  entry
|                  value
|                  list of entry, values

It should say:

       Arguments:  mailbox-name
|                  list of {entry, value} pairs

Notes:

Location is top of page 11.

Rationale:
The prose version of the syntax specification is confusing.
The ABNF in Section 5 is much more specific, and the prose
should correspond to the ABNF. The relevant ABFN rules
in Section 5 (pg.14/15) are (stripped of comments):
setmetadata = "SETMETADATA" SP mailbox SP entry-values
entry-values = "(" entry-value *(SP entry-value) ")"
entry-value = entry SP value

Errata ID: 2785
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Timo Sirainen
Date Reported: 2011-04-20
Verifier Name: Barry Leiba
Date Verified: 2012-05-08

Section 4.2.1 says:

 |         C: a GETMETADATA "INBOX" (MAXSIZE 1024)
                                    (/shared/comment /private/comment)
           S: * METADATA "INBOX" (/private/comment "My own comment")
           S: a OK [METADATA LONGENTRIES 2199] GETMETADATA complete

It should say:

 |         C: a GETMETADATA (MAXSIZE 1024) "INBOX"
                                    (/shared/comment /private/comment)
           S: * METADATA "INBOX" (/private/comment "My own comment")
           S: a OK [METADATA LONGENTRIES 2199] GETMETADATA complete

Notes:

GETMETADATA examples with options are wrong. ABNF says the options should be before mailbox name, not after. (Having them after mailbox name would also make the parsing more difficult since it could be confused with entries-list).

Errata ID: 2786
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Timo Sirainen
Date Reported: 2011-04-20
Verifier Name: Barry Leiba
Date Verified: 2012-05-08

Section 4.2.2 says:

 |         C: a GETMETADATA "INBOX" (DEPTH 1)
                                   (/private/filters/values)
           S: * METADATA "INBOX" (/private/filters/values/small
                "SMALLER 5000" /private/filters/values/boss
                "FROM \"boss@example.com\"")
           S: a OK GETMETADATA complete

It should say:

 |         C: a GETMETADATA (DEPTH 1) "INBOX"
                                   (/private/filters/values)
           S: * METADATA "INBOX" (/private/filters/values/small
                "SMALLER 5000" /private/filters/values/boss
                "FROM \"boss@example.com\"")
           S: a OK GETMETADATA complete

Notes:

Same reason as for the section 4.2.1 errata.

Errata ID: 3868
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tim Gokcen
Date Reported: 2014-01-16
Verifier Name: Barry Leiba
Date Verified: 2014-01-17

Section 4.4.1 says:

   Example:

           C: a GETMETADATA "INBOX" /private/comment /shared/comment
           S: * METADATA "INBOX" (/private/comment "My comment"
                                  /shared/comment "Its sunny outside!")
           S: a OK GETMETADATA complete

      In the above example, two entries and their values are returned by
      the server.

   Example:

           C: a GETMETADATA "INBOX" /private/comment /shared/comment
           S: * METADATA "INBOX" (/private/comment "My comment")
           S: * METADATA "INBOX" (/shared/comment "Its sunny outside!")
           S: a OK GETMETADATA complete

It should say:

   Example:

           C: a GETMETADATA "INBOX" (/private/comment /shared/comment)
           S: * METADATA "INBOX" (/private/comment "My comment"
                                  /shared/comment "Its sunny outside!")
           S: a OK GETMETADATA complete

      In the above example, two entries and their values are returned by
      the server.

   Example:

           C: a GETMETADATA "INBOX" (/private/comment /shared/comment)
           S: * METADATA "INBOX" (/private/comment "My comment")
           S: * METADATA "INBOX" (/shared/comment "Its sunny outside!")
           S: a OK GETMETADATA complete

Notes:

ABNF in section 5 for "getmetadata" says that when requesting multiple metadata entries, they must be part of a parenthesized list, and not simply space-separated:

getmetadata = "GETMETADATA" [SP getmetadata-options] SP mailbox SP entries
entries = entry / "(" entry *(SP entry) ")"
entry = astring

RFC 5465, "The IMAP NOTIFY Extension", February 2009

Source of RFC: lemonade (app)

Errata ID: 2318
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: David Woodhouse
Date Reported: 2010-07-06
Verifier Name: Barry Leiba
Date Verified: 2012-05-02

Section 3.1 says:

               (Time passes.  The client decides it wants to know about
               one more mailbox.  As the client already knows necessary
               STATUS information for all mailboxes below the Lists
               mailbox, and because "notify set status" would cause
               STATUS responses for *all* mailboxes specified in the
               NOTIFY command, including the ones for which the client
               already knows STATUS information, the client issues an
               explicit STATUS request for the mailbox to be added to
               the watch list, followed by the NOTIFY SET without the
               STATUS parameter.)
         C: d STATUS misc (UIDVALIDITY UIDNEXT MESSAGES)
         S: * STATUS misc (UIDVALIDITY 1 UIDNEXT 999)
         S: d STATUS completed

         C: e notify set (selected MessageNew (uid
            body.peek[header.fields (from to subject)]) MessageExpunge)
            (subtree Lists MessageNew) (mailboxes misc MessageNew)
         S: e OK done

It should say:

               (Time passes.  The client decides it wants to know about
               one more mailbox.  As the client already knows necessary
               STATUS information for all mailboxes below the Lists
               mailbox, and because "notify set status" would cause
               STATUS responses for *all* mailboxes specified in the
               NOTIFY command, including the ones for which the client
               already knows STATUS information, the client issues a
               NOTIFY SET without the STATUS parameter, followed by an
               explicit STATUS request for the newly-added mailbox.
               Note that if these two commands were issued in the reverse
               order, that would be a client bug; changes may occur in
               the mailbox between the completion of the STATUS command,
               and the issuing of the NOTIFY command.  The client may
               never be notified of such changes.)
         C: d notify set (selected MessageNew (uid
            body.peek[header.fields (from to subject)]) MessageExpunge)
            (subtree Lists MessageNew) (mailboxes misc MessageNew)
         S: d OK done

         C: e STATUS misc (UIDVALIDITY UIDNEXT MESSAGES)
         S: * STATUS misc (UIDVALIDITY 1 UIDNEXT 999)
         S: e STATUS completed

Notes:

The order of the STATUS and NOTIFY commands is changed. The original sequence is buggy, because any changes to the folder which occur between the two commands will not be noticed by the client.

Rather than just fixing it, my suggested correction also highlights the potential error -- if the authors of the RFC can do it, and especially since it's been shown as an example in the RFC until now, then it's worth making sure we highlight the problem.

Errata ID: 1694
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-02-23
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-06

Section 8, pg.18 says:

      message-event   = ( "MessageNew" [SP
                          "(" fetch-att *(SP fetch-att) ")" ] )
                      [[...]]
|                     ;; The fett-att list may only be present for the
                      ;; SELECTED/SELECTED-DELAYED mailbox filter
                      ;; (<filter-mailboxes>).

It should say:

      message-event   = ( "MessageNew" [SP
                          "(" fetch-att *(SP fetch-att) ")" ] )
                      [[...]]
|                     ;; The fetch-att list may only be present for the
                      ;; SELECTED/SELECTED-DELAYED mailbox filter
                      ;; (<filter-mailboxes>).

Notes:

Location is near bottom of page 18.

Rationale: confusing typo; s/fett/fetch/

Errata ID: 1804
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Barry Leiba
Date Reported: 2009-07-06
Verifier Name: Alexey Melnikov
Date Verified: 2010-04-05

Section 3.1 says:

page 7
         C: b notify set status (selected MessageNew (uid
            body.peek[header.fields (from to subject)]) MessageExpunge)
            (subtree Lists MessageNew)
Page 8
         C: e notify set (selected MessageNew (uid
            body.peek[header.fields (from to subject)]) MessageExpunge)
            (subtree Lists MessageNew) (mailboxes misc MessageNew)

It should say:

page 7
         C: b notify set status (selected (MessageNew (uid
            body.peek[header.fields (from to subject)]) MessageExpunge))
            (subtree Lists (MessageNew))
Page 8
         C: e notify set (selected (MessageNew (uid
            body.peek[header.fields (from to subject)]) MessageExpunge))
            (subtree Lists (MessageNew)) (mailboxes misc (MessageNew))

Notes:

Incorrect syntax in example... each "events" set needs to be in parentheses.

Errata ID: 3824
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jan-Philipp Litza
Date Reported: 2013-12-06
Verifier Name: Barry Leiba
Date Verified: 2013-12-06

Section 3 says:

   IMAP servers that support this extension advertise the NOTIFY
   capability.  This extension adds the NOTIFY command as defined in
   Section 5.1.

It should say:

   IMAP servers that support this extension advertise the NOTIFY
   capability.  This extension adds the NOTIFY command as defined in
   Section 3.1.

Notes:

Wrong section reference.

RFC 5473, "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports", March 2009

Source of RFC: ipfix (ops)

Errata ID: 2877
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02

Section A.2 says:

   o  The Class of Service field: ClassOfServiceIPv4 in [RFC5102], with
      a type of 5 and a length of 1 octet.

It should say:

   o  The Class of Service field: ipClassOfService in [RFC5102], with
      a type of 5 and a length of 1 octet.

Notes:

s/ClassOfServiceIPv4/ipClassOfService/ per IANA IPFIX registry, #5.

Errata ID: 2878
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02

Section A.2 says:

   In this example, using IPFIX to export the measurement data for each
   received packet, 38 bytes have to be transferred (sourceAddressV4=4,
   destinationAddressV4=4, classOfServiceV4=1, protocolIdentifier=1,
   sourceTransportPort=2, destinationTransportPort=2,
   observationTimeMilliseconds=8, digestHashValue=8, ipTotalLength=8).
   Without considering the IPFIX protocol overhead, a Flow of 1000
   packets produces 38000 bytes of measurement data.  Using the proposed
   optimization, each packet produces an export of only 28 bytes
   (observationTimeMilliseconds=8, digestHashValue=8, ipTotalLength=8,
   commonPropertiesID=4).  The export of the Flow information produces
   18 bytes (sourceAddressV4=4, destinationAddressV4=4,
   classOfServiceV4=1, protocolIdentifier=1, sourceTransportPort=2,
   destinationTransportPort=2, commonPropertiesID=4).  For a Flow of
   1000 packets, this sums to 28018 bytes.  This is a decrease of more
   than 26 percent.

It should say:

   In this example, using IPFIX to export the measurement data for each
   received packet, 38 bytes have to be transferred (sourceIPv4Address=4,
   destinationIPv4Address=4, ipClassOfService=1, protocolIdentifier=1,
   sourceTransportPort=2, destinationTransportPort=2,
   observationTimeMilliseconds=8, digestHashValue=8, ipTotalLength=8).
   Without considering the IPFIX protocol overhead, a Flow of 1000
   packets produces 38000 bytes of measurement data.  Using the proposed
   optimization, each packet produces an export of only 28 bytes
   (observationTimeMilliseconds=8, digestHashValue=8, ipTotalLength=8,
   commonPropertiesID=4).  The export of the Flow information produces
   18 bytes (sourceIPv4Address=4, destinationIPv4Address=4,
   ipClassOfService=1, protocolIdentifier=1, sourceTransportPort=2,
   destinationTransportPort=2, commonPropertiesID=4).  For a Flow of
   1000 packets, this sums to 28018 bytes.  This is a decrease of more
   than 26 percent.

Notes:

s/sourceAddressV4/sourceIPv4Address/
s/destinationAddressV4/destinationIPv4Address/
s/classOfServiceV4=1/ipClassOfService/

- twice each.

Names are per IANA's IPFIX registry.

Errata ID: 2880
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02

Section Figure 15 says:

     0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Set ID = 3            |      Length = 40 octets       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Template ID = 256       |       Field Count = 7         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Scope Field count = 1    |0|  commonPropertiesID = 137   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Scope 1 Field Length = 4     |0|    sourceIPv4Address = 8    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Field Length = 4         |0| destinationIPv4Address = 12 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Field Length = 4         |0|  classOfServiceIPv4 = 5     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Field Length = 1         |0|  protocolIdentifier = 4     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Field Length = 1         |0|  transportSourcePort = 7    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Field Length = 2         |0|transportDestinationPort = 11|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Field Length = 2         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Set ID = 3            |      Length = 40 octets       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Template ID = 256       |       Field Count = 7         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Scope Field count = 1    |0|  commonPropertiesID = 137   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Scope 1 Field Length = 4     |0|    sourceIPv4Address = 8    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Field Length = 4         |0| destinationIPv4Address = 12 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Field Length = 4         |0|    ipClassOfService = 5     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Field Length = 1         |0|  protocolIdentifier = 4     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Field Length = 1         |0|  transportSourcePort = 7    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Field Length = 2         |0|transportDestinationPort = 11|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Field Length = 2         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

s/classOfServiceIPv4/ipClassOfService/

Also, fix the alignment of the bit position numbering at the top of the figure.

Errata ID: 2886
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02

Section (all) says:

commonPropertiesID

It should say:

commonPropertiesId

Notes:

This doc consistently uses "commonPropertiesID" when the field defined in [RFC5101] and IANA's IPFIX registry is "commonPropertiesId".

Note that some of the other errata on this RFC also contain this incorrect usage.

Errata ID: 2893
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02

Section A.1 says:

inOctetDeltaCount

It should say:

octetDeltaCount

Notes:

s/inOctetDeltaCount/octetDeltaCount/ (three times)

- including figure 10.

Per [RFC5102] and IANA's IPFIX registry, the correct name is "octetDeltaCount".

Errata ID: 2894
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02

Section A.1 says:

inPacketDeltaCount

It should say:

packetDeltaCount

Notes:

s/inPacketDeltaCount/packetDeltaCount/ (three times)

- including figure 10.

Per [RFC5102] and IANA's IPFIX registry, the correct name is "packetDeltaCount".

Errata ID: 2908
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02

Section Figure 15 says:

     0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Set ID = 3            |      Length = 40 octets       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Template ID = 256       |       Field Count = 7         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Scope Field count = 1    |0|  commonPropertiesID = 137   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Scope 1 Field Length = 4     |0|    sourceIPv4Address = 8    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Field Length = 4         |0| destinationIPv4Address = 12 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Field Length = 4         |0|  classOfServiceIPv4 = 5     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Field Length = 1         |0|  protocolIdentifier = 4     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Field Length = 1         |0|  transportSourcePort = 7    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Field Length = 2         |0|transportDestinationPort = 11|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Field Length = 2         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

     0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Set ID = 3            |      Length = 40 octets       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Template ID = 256       |       Field Count = 7         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Scope Field count = 1    |0|  commonPropertiesID = 137   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Scope 1 Field Length = 4     |0|    sourceIPv4Address = 8    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Field Length = 4         |0| destinationIPv4Address = 12 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Field Length = 4         |0|  classOfServiceIPv4 = 5     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Field Length = 1         |0|  protocolIdentifier = 4     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Field Length = 1         |0|  sourceTransportPort = 7    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Field Length = 2         |0|destinationTransportPort = 11|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Field Length = 2         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

s/transportSourcePort/sourceTransportPort/
s/transportDestinationPort/destinationTransportPort/

Per RFC5102 and IANA's IPFIX registry, the correct names are "sourceTransportPort" and "destinationTransportPort".

Errata 2880 also relates to this figure.

RFC 5476, "Packet Sampling (PSAMP) Protocol Specifications", March 2009

Source of RFC: psamp (ops)

Errata ID: 2053
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2010-02-25
Verifier Name: Dan Romascanu
Date Verified: 2010-11-02

Section 6.5.1. says:

Notes:

   * There are two Records here in the same Data Set.  Each record
     defines a different Selection Sequence.

   * If, for example, a different Selection Sequence is composed of
     three Selectors, then a different Options Template with three
     selectorId Information Elements (instead of two) must be used.

It should say:

Notes:

   * There are two Records here in the same Data Set.  Each record
     defines a different Selection Sequence.

   * If, for example, a different Selection Sequence is composed of
     three Selectors, then a different Options Template with three
     selectorId Information Elements (instead of two) must be used.

   * IPFIX Reduced Size Encoding [RFC5101] has been used for the
     selectorId fields.

Notes:

Addition of "Reduced Size Encoding" note per Errata ID 2052.
NB "fields" is plural in this example only.

Errata ID: 2054
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2010-02-25
Verifier Name: Dan Romascanu
Date Verified: 2010-11-02

Section 6.5.2.1. says:

   Notes:

   * A selectorAlgorithm value of 1 represents systematic count-based
     Sampling.

   * samplingPacketInterval and samplingPacketSpace are of type
     unsigned32 but are compressed down to one octet here, as allowed by
     the IPFIX protocol specifications [RFC5101].

It should say:

   Notes:

   * A selectorAlgorithm value of 1 represents systematic count-based
     Sampling.

   * samplingPacketInterval and samplingPacketSpace are of type
     unsigned32 but are compressed down to one octet here, as allowed by
     the IPFIX protocol specifications [RFC5101].

   * IPFIX Reduced Size Encoding [RFC5101] has been used for the
     selectorId field.

Notes:

Addition of "Reduced Size Encoding" note per Errata ID 2052.

Errata ID: 2055
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2010-02-25
Verifier Name: Dan Romascanu
Date Verified: 2010-11-02

Section 6.5.2.2. says:

   Notes:

   * A selectorAlgorithm value of 2 represents systematic time-based
     Sampling.

   * samplingTimeInterval and samplingTimeSpace are of type unsigned32
     but are compressed down here.

It should say:

   Notes:

   * A selectorAlgorithm value of 2 represents systematic time-based
     Sampling.

   * samplingTimeInterval and samplingTimeSpace are of type unsigned32
     but are compressed down here.

   * IPFIX Reduced Size Encoding [RFC5101] has been used for the
     selectorId field.

Notes:

Addition of "Reduced Size Encoding" note per Errata ID 2052.

Errata ID: 2056
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2010-02-25
Verifier Name: Dan Romascanu
Date Verified: 2010-11-02

Section 6.5.2.3. says:

   Notes:

   * A selectorAlgorithm value of 3 represents Random n-out-of-N
     Sampling.

   * samplingSize and samplingPopulation are of type unsigned32 but are
     compressed down to one octet here.

It should say:

   Notes:

   * A selectorAlgorithm value of 3 represents Random n-out-of-N
     Sampling.

   * samplingSize and samplingPopulation are of type unsigned32 but are
     compressed down to one octet here.

   * IPFIX Reduced Size Encoding [RFC5101] has been used for the
     selectorId field.

Notes:

Addition of "Reduced Size Encoding" note per Errata ID 2052.

Errata ID: 2057
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2010-02-25
Verifier Name: Dan Romascanu
Date Verified: 2010-11-02

Section 6.5.2.4. says:

   Notes:

   * A selectorAlgorithm value of 4 represents Uniform Probabilistic
     Sampling.

   * samplingProbability is of type float64 but is compressed down to a
     float32 here.

It should say:

   Notes:

   * A selectorAlgorithm value of 4 represents Uniform Probabilistic
     Sampling.

   * samplingProbability is of type float64 but is compressed down to a
     float32 here.

   * IPFIX Reduced Size Encoding [RFC5101] has been used for the
     selectorId field.

Notes:

Addition of "Reduced Size Encoding" note per Errata ID 2052.

Errata ID: 2058
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2010-02-25
Verifier Name: Dan Romascanu
Date Verified: 2010-11-02

Section 6.5.2.5 says:

   Notes:

   * A selectorAlgorithm value of 5 represents Property Match Filtering.

   * In this filter, there is a mix of information from the packet and
     information from the router.

It should say:

   Notes:

   * A selectorAlgorithm value of 5 represents Property Match Filtering.

   * In this filter, there is a mix of information from the packet and
     information from the router.

   * IPFIX Reduced Size Encoding [RFC5101] has been used for the
     selectorId field.

Notes:

Addition of "Reduced Size Encoding" note per Errata ID 2052.

Errata ID: 2059
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2010-02-25
Verifier Name: Dan Romascanu
Date Verified: 2010-11-02

Section 6.5.2.6 says:

   Notes:

   * A selectorAlgorithm value of 6 represents Hash-based Filtering
     using the BOB algorithm.

It should say:

   Notes:

   * A selectorAlgorithm value of 6 represents Hash-based Filtering
     using the BOB algorithm.

   * IPFIX Reduced Size Encoding [RFC5101] has been used for the
     selectorId field.

Notes:

Addition of "Reduced Size Encoding" note per Errata ID 2052.

Errata ID: 3825
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Andrew Feren
Date Reported: 2013-12-08
Verifier Name: Benoit Claise
Date Verified: 2013-12-09

Section 6.4.1 says:

The Packet
   Report MAY include only the final selector packetSelected, to act as
   an index for that Selection Sequence in the Selection Sequence
   Statistics Report Interpretation, which also allows the calculation
   of the Attained Selection Fraction.

It should say:

The Packet
   Report MAY include only the final selector packetsSelected, to act as
   an index for that Selection Sequence in the Selection Sequence
   Statistics Report Interpretation, which also allows the calculation
   of the Attained Selection Fraction.

Notes:

Should be plural: packet[s]Selected.

packetSelected is not defined and occurs nowhere else.
packetsSelected "contains the number of packets selected by a Selector in the Selection Sequence" which makes sense as the index into "that Selection Sequence".

Errata ID: 3826
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Andrew Feren
Date Reported: 2013-12-08
Verifier Name: Benoit Claise
Date Verified: 2013-12-09

Throughout the document, when it says:

packetsSelected

It should say:

selectorIdTotalPktsSelected

Notes:

The source of packetsSelected is noted as RFC5477, but "packetsSelected" occurs nowhere in RFC5477.
RFC5476 Figure N shows "packetsSelected = 319".

Both RFC5477 and http://www.iana.org/assignments/ipfix name elementId 319 "selectorIdTotalPktsSelected"

Errata ID: 3827
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Andrew Feren
Date Reported: 2013-12-08
Verifier Name: Benoit Claise
Date Verified: 2013-12-09

Throughout the document, when it says:

packetsObserved

It should say:

selectorIdTotalPktsObserved

Notes:

The source of packetsObserved is noted as RFC5477, but "packetsObserved" occurs nowhere in RFC5477.
RFC5476 Figure N shows "packetsObserved = 318".

Both RFC5477 and http://www.iana.org/assignments/ipfix name elementId 318 "selectorIdTotalPktsObserved"

RFC 5477, "Information Model for Packet Sampling Exports", March 2009

Source of RFC: psamp (ops)

Errata ID: 2052
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2010-02-25
Verifier Name: Dan Romascanu
Date Verified: 2010-11-02

Section 8.1.2 says:

Abstract Data Type:  unsigned16

It should say:

Abstract Data Type:  unsigned64

Notes:

Change selectorID from 16 bits to 64 bits per discussion on the IPFIX mailing list:

http://www.ietf.org/mail-archive/web/ipfix/current/msg05133.html

RFC 5479, "Requirements and Analysis of Media Security Management Protocols", April 2009

Source of RFC: sip (rai)

Errata ID: 2602
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Fabio Pietrosanti
Date Reported: 2010-11-04
Verifier Name: Robert Sparks
Date Verified: 2011-02-21

Section A.5.2 says:

      SDP Security Descriptions with SIPS
         Not applicable; SDP Security Descriptions does not have a long-
         term secret.

It should say:

      SDP Security Descriptions with SIPS
         The PFS feature of SDP Security Description with SIPS rely on 
         TLS and the availability or not of PFS for SRTP calls depends 
         on the negotiated TLS key negotiation algorithm.

         If the selected TLS key negotiation algorithm of SIPS provide 
         PFS feature, then the underlying SRTP encryption will support PFS. 
         For example TLS_DHE_RSA_WITH_AES_256_CBC_SHA provde PFS feature as 
         described in RFC5246.

         If the selected TLS key negotiation algorithm of SIPS does not 
         provide PFS feature, then the underlying SRTP encryption will not 
         support PFS. For example TLS_RSA_WITH_AES_256_CBC_SHA does not 
         provide PFS feature as described in RFC5246.

Notes:

It's not true that SDP Security Descriptions with SIPS have PFS "Not applicable" because the SDES rely on TLS that is part of the security scheme.

Practically if the long terms keys (the x509v3 RSA key of SIPS server) is compromised, the TLS sessions can be decrypted, the SDES key extracted and SRTP calls deciphered.

TLS support key exchange methods that provide PFS trough the use of Ephemeral Diffie Hellman keys.

When SIPS use TLS with DHE key negotiation, then SDES acquire PFS feature because even in case of long-term key compromise (the server x509v3 RSA key), the short term keys (the SDES keys exchanged) will be safe.

----
From reviewer Dale Worley:

It seems that the entry for "SDP Security Descriptions with S/MIME" is
also incorrect, as revelation of the private keys of the participants
will render the SDES readable. I think better phrasing of the revised

wording is:

SDP Security Descriptions with SIPS

PFS if the selected TLS cipher suites for the SIPS hops provide PFS.

SDP Security Descriptions with S/MIME

No PFS.

RFC 5480, "Elliptic Curve Cryptography Subject Public Key Information", March 2009

Note: This RFC has been updated by RFC 8813

Source of RFC: pkix (sec)

Errata ID: 6670
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Corey Bonnell
Date Reported: 2021-08-31
Verifier Name: Benjamin Kaduk
Date Verified: 2021-09-01

Section 3 says:

   If the keyUsage extension is present in a certificate that indicates
   id-ecDH or id-ecMQV in SubjectPublicKeyInfo, then the following
   values MUST NOT be present:

     digitalSignature;
     nonRepudiation;
     keyTransport;
     keyCertSign; and
     cRLSign.

It should say:

   If the keyUsage extension is present in a certificate that indicates
   id-ecDH or id-ecMQV in SubjectPublicKeyInfo, then the following
   values MUST NOT be present:

     digitalSignature;
     nonRepudiation;
     keyEncipherment;
     keyCertSign; and
     cRLSign.

Notes:

"keyTransport" KU bit name does not exist; I believe "keyEncipherment" is intended here instead.

While RFC 8813 makes it clear that "keyEncipherment" and "dataEncipherment" are prohibited, I'm marking this erratum as "Technical" due the reference to a non-existent bit name.

RFC 5491, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", March 2009

Note: This RFC has been updated by RFC 7459

Source of RFC: geopriv (rai)

Errata ID: 1888
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin Thomson
Date Reported: 2009-09-21
Verifier Name: Cullen Jennings
Date Verified: 2009-11-30

Section 3 says:

The PIDF format provides for an unbounded number of <tuple>,
<device>, and <person> elements.  Each of these elements contains a
single <status> element that may contain more than one <geopriv>
element as a child.  

It should say:

The PIDF format provides for an unbounded number of <tuple>,
<device>, and <person> elements.  Each of these elements may
contain more than one <geopriv> element.  

Notes:

<status> only exists in <tuple> [RFC3863], not <device> or <person> [RFC4479]. The proposed text removes the problem.

I believe that it was only late that someone pointed out that <status> only applied to <tuple>; this sentence obviously got missed in the edit.

Errata ID: 1951
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Martin Thomson
Date Reported: 2009-11-30
Verifier Name: Cullen Jennings
Date Verified: 2009-11-30

Section 5.2.2 says:

                     <gml:pos>43.311 -73.422</gml:pos> <!--A-->
                     <gml:pos>43.111 -73.322</gml:pos> <!--F-->
                     <gml:pos>43.111 -73.222</gml:pos> <!--E-->
                     <gml:pos>43.311 -73.122</gml:pos> <!--D-->
                     <gml:pos>43.411 -73.222</gml:pos> <!--C-->
                     <gml:pos>43.411 -73.322</gml:pos> <!--B-->
                     <gml:pos>43.311 -73.422</gml:pos> <!--A-->

It should say:

                     <gml:pos>43.311 -73.422</gml:pos> <!--A-->
                     <gml:pos>43.111 -73.322</gml:pos> <!--B-->
                     <gml:pos>43.111 -73.222</gml:pos> <!--C-->
                     <gml:pos>43.311 -73.122</gml:pos> <!--D-->
                     <gml:pos>43.411 -73.222</gml:pos> <!--E-->
                     <gml:pos>43.411 -73.322</gml:pos> <!--F-->
                     <gml:pos>43.311 -73.422</gml:pos> <!--A-->

Notes:

The points in Figure 7 are correct (i.e., they are in a counter-clockwise direction) but the comment labels are in the wrong order.

RFC 5496, "The Reverse Path Forwarding (RPF) Vector TLV", March 2009

Source of RFC: pim (rtg)

Errata ID: 3665
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bharat Joshi
Date Reported: 2013-06-17
Verifier Name: Adrian Farrel
Date Verified: 2013-09-18

Section 3.1 says:

Use of the attribute is, however, not restricted to the construction 
of source trees.  It may also be used to construct a shared tree.  In
this case, the RPF Vector TLV contains the IP address of a Rendezvous
Point (RP).

It should say:

Use of the attribute is, however, not restricted to the construction
of source trees.  It may also be used to construct a shared tree.  In
this case, the RPF Vector TLV contains the IP address of an edge 
router on the path to the Rendezvous Point (RP).

Notes:

For a source tree, as per section 3.0, RPF Vector TLV contains the IP address of edge-1 which is to be used to reach the source. Similarly, for shared tree, RPF vector TLV should contain the IP address of the edge router which is to be used to reach RP.

Errata ID: 3668
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bharat Joshi
Date Reported: 2013-06-17
Verifier Name: Adrian Farrel
Date Verified: 2013-09-17

Section 4 says:

4.  Vector Attribute TLV Format

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |F|S| Type      | Length        |        Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.......

   F bit
      Forward Unknown TLV.  If this bit is set, the TLV is forwarded
      regardless of whether the router understands the Type.  If the TLV
      is known, the F bit is ignored.

   S bit
      Bottom of Stack.  If this bit is set, then this is the last TLV in
      the stack.

It should say:

4.  Vector Attribute TLV Format

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |F|E| Type      | Length        |        Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.......

   F-bit
      Forward Unknown TLV.  If this bit is set, the TLV is forwarded
      regardless of whether the router understands the Type.  If the TLV
      is known, the F bit is ignored.

   E-bit:
      End of Attributes.  If this bit is set, then this is the last TLV
      in the stack. 

Notes:

RFC 5384 defined the Join Attribute for PIM.
RPF vector is one such Join attribute.

RFC 5384 defined the format for Join Attributes to use the F-bit and E-bit.

This change aligns the terminology with RFC 5384 and aligns the bit numbers in the figure.

There is no change to bits on the wire, procedures, or implementation details.

RFC 5497, "Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs)", March 2009

Source of RFC: manet (rtg)

Errata ID: 1722
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-03-16
Verifier Name: Adrian Farrel
Date Verified: 2012-03-12

Section 6.2, pg.9 says:

[ first bullet: ]

   o  The <length> field in the TLV MUST contain the value m * (2n+1),
|     with n being the number of (time-value, hop count) pairs in the
|     Time TLV, and m being number-values as defined in [RFC5444].

It should say:

   o  The <length> field in the TLV MUST contain the value m * (2n+1),
|     with n being the number of (time-value, hop count) pairs per
|     associated address in the Time TLV, and m being number-values as
      defined in [RFC5444].
 

Notes:

Rationale:
The original text is contradictory in itself, and it opposes the
subsequent bullets and prose in the same section.
The proposed correction (inserting "per associated adddress")
is derived from the text in the first paragraph of the section.

Errata ID: 1723
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-03-16
Verifier Name: Adrian Farrel
Date Verified: 2011-08-05

Section 7.1 and 7.2 says:

a) Section 7.1, last paragraph

   An INTERVAL_TIME TLV is an example of a Time TLV specified as in
|  Section 5.

b) Section 7.2, last paragraph

   A VALIDITY_TIME TLV is an example of a Time TLV specified as in
|  Section 5.

It should say:

a)

   An INTERVAL_TIME TLV is an example of a Time TLV specified as in
|  Section 6.

b)

   A VALIDITY_TIME TLV is an example of a Time TLV specified as in
|  Section 6.

Notes:

Rationale:
Section 5 only contains the low-level details;
Section 6, contains the precise specification of the
Time TLV format used in Sections 7.1 and 7.2.

Errata ID: 1724
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-03-16
Verifier Name: Adrian Farrel
Date Verified: 2011-08-05

Section 8.1 and 8.2 says:

a) Section 8.1, last paragraph

   An INTERVAL_TIME TLV is an example of a Time TLV specified as in
|  Section 5.

b) Section 8.2, last paragraph

   A VALIDITY_TIME TLV is an example of a Time TLV specified as in
|  Section 5.

It should say:

a)

   An INTERVAL_TIME TLV is an example of a Time TLV specified as in
|  Section 6.

b)

   A VALIDITY_TIME TLV is an example of a Time TLV specified as in
|  Section 6.

Notes:

Rationale:
Section 5 only contains the low-level details;
Section 6 contains the precise specification of the
Time TLV format used in Sections 8.1 and 8.2.

See Errata ID #1723 for similar issues in Sections 7.1 and 7.2.

RFC 5513, "IANA Considerations for Three Letter Acronyms", April 2009

Source of RFC: INDEPENDENT

Errata ID: 1889
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nico R.
Date Reported: 2009-09-22
Verifier Name: Nevil Brownlee
Date Verified: 2012-11-05

Section 7.2. says:

ahttp://www.qosfc.com/

It should say:

http://www.qosfc.com/

Notes:

This appears at the “[URL-QoS]” reference, the second reference to the Queen of the South Football Club.

According to the URI schemes registry[1] maintained by IANA, “ahttp” is not a valid URI scheme. It should probably be “http” instead.

The URI in its current form is inaccessible, because its meaning is not well-defined for users.

[1] http://www.iana.org/assignments/uri-schemes.html

RFC 5518, "Vouch By Reference", April 2009

Note: This RFC has been updated by RFC 8553

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 2583
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Levine
Date Reported: 2010-10-26
Verifier Name: Sean Turner
Date Verified: 2012-01-06

Section 7.1 says:

If the DKIM signature contains an i= field, the domain name from
that field is used; otherwise, the domain name from the DKIM
signature d= field is used.

It should say:

The domain name from the DKIM signature d= field is used.

Notes:

RFC 5672 clarifies that the d= domain is the primary identity in a DKIM signature.

RFC 5520, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", April 2009

Source of RFC: pce (rtg)

Errata ID: 1777
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-05-05
Verifier Name: Adrian Farrel
Date Verified: 2009-11-07

Section 7.3, pg. 17 says:

   IANA maintains a registry of bit flags carried in the PCEP RP object
   as defined in [RFC5440].  IANA assigned a new bit flag as follows:

|  Bit Number  Hex       Name                             Reference
|  23          0x000017  Path-Key (P-bit)                 [RFC5520]

It should say:

   IANA maintains a registry of bit flags carried in the PCEP RP object
   as defined in [RFC5440].  IANA assigned a new bit flag as follows:

|  Bit Number    Name                                     Reference
|  23            Path-Key (P-bit)                         [RFC5520]

Notes:

Rationale: 'translating' the decimal bit number into a 6-digit (!)
hexadecimal value does not add specific insight and might even be
considered confusing; at most a hexadecimal bit mask might have
some additional value -- but it should be specified as an /8/-digit
mask in this case (the RP Flags field is 32 bits wide).
Because the definition of the addressed sub-registry (Section 9.6
of RFC 5440) did not specify a 'Hex' item and the IANA Registry
consequentially does not contain such column, the 'Hex' column
should have been dropped from Section 7.3 of RFC 5520 as well.

Downgraded to Editorial as the change makes no difference to the technical reading of the text.

Errata ID: 3582
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dhruv Dhody
Date Reported: 2013-04-05
Verifier Name: Adrian Farrel
Date Verified: 2013-04-10

Section 3.2.3 says:

<request>::= <RP>
                    <segment-computation> | <path-key-expansion>

       where:
          <segment-computation> ::= <END-POINTS>
                                    [<LSPA>]
                                    [<BANDWIDTH>]
                                    [<BANDWIDTH>]
                                    [<metric-list>]
                                    [<RRO>]
                                    [<IRO>]
                                    [<LOAD-BALANCING>]
          <path-key-expansion> ::= <PATH-KEY>

It should say:

<request>::= <RP>
                    <segment-computation> | <path-key-expansion>

       where:
          <segment-computation> ::= <END-POINTS>
                                    [<LSPA>]
                                    [<BANDWIDTH>]
                                    [<metric-list>]
                                    [<RRO>[<BANDWIDTH>]]
                                    [<IRO>]
                                    [<LOAD-BALANCING>]
          <path-key-expansion> ::= <PATH-KEY>

Notes:

This document defines <path-key-expansion> to allow path request message to be used for getting the confidential path segment. The <segment-computation> should be as per RFC5440 itself.
There is a mistake in the second BANDWIDTH object which should be placed with RRO as per RFC5440.

RFC 5521, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions", April 2009

Source of RFC: pce (rtg)

Errata ID: 1775
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-05-05
Verifier Name: Adrian Farrel
Date Verified: 2010-01-02

Section 2.1.1, pg. 6 says:

   Type
      The type of the subobject.  The following subobject types are
      defined.

      Type           Subobject
      -------------+-------------------------------
      1              IPv4 prefix
      2              IPv6 prefix
      4              Unnumbered Interface ID
      32             Autonomous system number
      34             SRLG

   Length
      [...]

   Prefix Length
      [...]

   Attribute
      The Attribute field indicates how the exclusion subobject is to be
      interpreted.

   0 Interface
      The subobject is to be interpreted as an interface or set of
      interfaces.  All interfaces identified by the subobject are to be
      excluded from the computed path according to the setting of the
|     X-bit.  This value is valid only for subobject types 1, 2, and 3.

   1 Node
      The subobject is to be interpreted as a node or set of nodes.  All
      nodes identified by the subobject are to be excluded from the
      computed path according to the setting of the X-bit.  This value
|     is valid only for subobject types 1, 2, 3, and 4.

   2 SRLG
      The subobject identifies an SRLG explicitly or indicates all of
      the SRLGs associated with the resource or resources identified by
      the subobject.  Resources that share any SRLG with those
      identified are to be excluded from the computed path according to
      the setting of the X-bit.  This value is valid for all subobjects.

It should say:

   Attribute
      The Attribute field indicates how the exclusion subobject is to be
      interpreted.

   Type
      [...]

   Length
      [...]

   Prefix Length
      [...]

   Attribute
      The Attribute field indicates how the exclusion subobject is to be
      interpreted.

      0 Interface
         The subobject is to be interpreted as an interface or set of
         interfaces.  All interfaces identified by the subobject are to
         be excluded from the computed path according to the setting of
         the X-bit.  This value is valid only for subobject types 1, 2,
|        and 4.
             ^

      1 Node
         The subobject is to be interpreted as a node or set of nodes.  
         All nodes identified by the subobject are to be excluded from
         the computed path according to the setting of the X-bit.  This
|        value is valid only for subobject types 1, 2, 4, and 32.
                                                       ^      ^^

      2 SRLG
         The subobject identifies an SRLG explicitly or indicates all of
         the SRLGs associated with the resource or resources identified
         by the subobject.  Resources that share any SRLG with those
         identified are to be excluded from the computed path according 
         to the setting of the X-bit.  This value is valid for all
         subobjects.

Notes:

Rationale:

a) Technical:
The enumeration of subobject types for Attribute '0 Interface'
and '1 Node' is out of sync with the table at the top of the page
and the IANA registry (cf. Section 4.1 of this RFC, on page 13).

The Corrected Text proposed above is based on the assumption that
the figures given originally refer to the position of the
subobjects in the table, i.e. that the subobjects in the table
once had been assigned sequential type numbers, 1 through 5;
this change seems to be technically reasonable.

>>> Technical change verified by original document author and cross-checked
>>> to early versions of the document.

b) Editorial: For clarity, the details for the Attribute field
values should have been indented one more step, making them
visually subordinate to 'Attribute' and not appearing like
additional common fields.

Errata ID: 3750
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Dana Kutenicsova
Date Reported: 2013-10-15
Verifier Name: Stewart Bryant
Date Verified: 2013-10-23

Section 3.1.1 says:

The format and definition of PKS when it appears as an XRO subobject
are as defined in [RFC5520], except for the definition of the L bit.
The L bit of the PKS subobject in the XRO MUST be ignored.

It should say:

The format and definition of PKS when it appears as an XRO subobject
are as defined in [RFC5520], except that the L bit described in 
[RFC5220] is replaced with the X bit as discussed in Section 2.1.1 
of this document.

Notes:

The original text did not describe the value of the X bit in
PKS subobjects.

Errata ID: 2705
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramon Casellas
Date Reported: 2011-02-05
Verifier Name: Adrian Farrel
Date Verified: 2011-05-08

Section 2.1.1 says:

 Unnumbered Interface ID Subobject

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |X|  Type = 3   |     Length    |    Reserved   |  Attribute    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        TE Router ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Interface ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The TE Router ID and Interface ID fields are as defined in [RFC3477].






Oki, et al.                 Standards Track                     [Page 7]
 
RFC 5521        Extensions to PCEP for Route Exclusions       April 2009


   Autonomous System Number Subobject

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |X|  Type = 4   |     Length    |      2-Octet AS Number        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Note that as in other PCEP objects [RFC5440] and RSVP-TE objects
   [RFC3209], no support for 4-octet Autonomous System (AS) Numbers is
   provided.  It is anticipated that, as 4-octet AS Numbers become more
   common, both PCEP and RSVP-TE will be updated in a consistent way to
   add this support.

   SRLG Subobject

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |X|  Type = 5   |     Length    |       SRLG Id (4 bytes)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      SRLG Id (continued)      |    Reserved   |  Attribute    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Attribute SHOULD be set to two (2) and SHOULD be ignored on
   receipt.

It should say:

 Unnumbered Interface ID Subobject

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |X|  Type = 4   |     Length    |    Reserved   |  Attribute    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        TE Router ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Interface ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The TE Router ID and Interface ID fields are as defined in [RFC3477].






Oki, et al.                 Standards Track                     [Page 7]
 
RFC 5521        Extensions to PCEP for Route Exclusions       April 2009


   Autonomous System Number Subobject

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |X|  Type = 32  |     Length    |      2-Octet AS Number        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Note that as in other PCEP objects [RFC5440] and RSVP-TE objects
   [RFC3209], no support for 4-octet Autonomous System (AS) Numbers is
   provided.  It is anticipated that, as 4-octet AS Numbers become more
   common, both PCEP and RSVP-TE will be updated in a consistent way to
   add this support.

   SRLG Subobject

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |X|  Type = 34  |     Length    |       SRLG Id (4 bytes)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      SRLG Id (continued)      |    Reserved   |  Attribute    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Attribute SHOULD be set to two (2) and SHOULD be ignored on
   receipt.

Notes:

This is the correct resolution consistent with the table further up the document, and with the IANA registry

RFC 5524, "Extended URLFETCH for Binary and Converted Parts", May 2009

Source of RFC: lemonade (app)

Errata ID: 6214
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Дилян Палаузов
Date Reported: 2020-06-24
Verifier Name: Barry Leiba
Date Verified: 2020-06-25

Section 6 says:

This document defines the URLFETCH=BINARY IMAP capability.  IANA has added it to the registry accordingly.

It should say:

This document defines the URLAUTH=BINARY IMAP capability.  IANA is asked to replace URLFETCH=BINARY with URLAUTH=BINARY in the IMAP registry.

Notes:

This document talks about URLAUTH=BINARY. Mentioning URLFETCH=BINARY in the IANA section was not intended.

RFC 5530, "IMAP Response Codes", May 2009

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 6675
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Barry Leiba
Date Reported: 2021-09-01
Verifier Name: Murray Kucherawy
Date Verified: 2021-09-01

Section 6 says:

      ALERT                RFC 3501
      BADCHARSET           RFC 3501

It should say:

      HASCHILDREN          RFC 3348
      ALERT                RFC 3501
      BADCHARSET           RFC 3501
      CAPABILITY           RFC 3501

Notes:

When RFC 5530 created the IMAP Response Codes registry it registered all response codes that existed at the time, but missed “CAPABILITY” and “HASCHILDREN”. This errata report notes that for the record and so IANA may correctly register those two codes.

RFC 5531, "RPC: Remote Procedure Call Protocol Specification Version 2", May 2009

Note: This RFC has been updated by RFC 9289

Source of RFC: nfsv4 (wit)

Errata ID: 4849
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: RFC Editor
Date Reported: 2016-10-31
Verifier Name: RFC Editor
Date Verified: 2016-10-31

Appendix C says:

   RPCSEC_GSS      6               /* GSS-based RPC security for auth,
                                      integrity and privacy, RPC 5403 */

It should say:

   RPCSEC_GSS      6               /* GSS-based RPC security for auth,
                                      integrity and privacy, RFC 5403 */

Notes:

"RPC 5403" should be "RFC 5403".

RFC 5536, "Netnews Article Format", November 2009

Source of RFC: usefor (app)

Errata ID: 5116
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Paul Kyzivat
Date Reported: 2017-09-14
Verifier Name: Alexey Melnikov
Date Verified: 2017-09-27

Section 3 says:

   fields          =/ *( approved /
                         archive /
                         control /
                         distribution /
                         expires /
                         followup-to /
                         injection-date /
                         injection-info /
                         lines /
                         newsgroups /
                         organization /
                         path /
                         summary /
                         supersedes /
                         user-agent /
                         xref )

It should say:

   optional-field  = <see RFC 5322 Section 3.6.8>

   news-fields     =  approved /
                      archive /
                      control /
                      distribution /
                      expires /
                      followup-to /
                      injection-date /
                      injection-info /
                      lines /
                      newsgroups /
                      organization /
                      path /
                      summary /
                      supersedes /
                      user-agent /
                      xref

   optional-field  =/    news-fields

Notes:

In Section 3 of RFC5536, the ABNF syntax provided does not do what is clearly intended. What is specified is:

fields =/ *( approved /
archive /
control /
distribution /
expires /
followup-to /
injection-date /
injection-info /
lines /
newsgroups /
organization /
path /
summary /
supersedes /
user-agent /
xref )

and that extends RFC5322:

fields = *(trace
*optional-field /
*(resent-date /
resent-from /
resent-sender /
resent-to /
resent-cc /
resent-bcc /
resent-msg-id))
*(orig-date /
from /
sender /
reply-to /
to /
cc /
bcc /
message-id /
in-reply-to /
references /
subject /
comments /
keywords /
optional-field)

message = (fields / obs-fields)
[CRLF body]

The problem is with the way things are grouped. Let me give a simpler example:

foo = *("a" / "b") / *("c" / "d")

This means the following are valid: ab aabb bab cd ccdd dcd
But the following are not: abcd ac

I think it is clear that the latter is intended to be valid, for which the syntax would be:

foo = *("a" / "b" / "c" / "d")

It isn't easy to do a valid syntax extension that achieves this effect
because of way the ABNF of RFC5322 is structured. However, after offline
discussion, we realized that RFC5322 already has an extension point for
new headers via the <optional-field> rule. Along with that, RFC3864
established a process for registering header fields with IANA.

The above fix is based on discussion with Pete Resnick (editor of RFC 5322), Julien ÉLIE, Alexey Melnikov and Paul Kyzivat.

An alternative fix from Paul Kyzuvat is:

So, my recommendation is that to fix this, remove from section 3 the
extension of the <fields> rule:

fields =/ *( approved / ...
xref )

Instead, simply rely on the text to specify the newly defined header
fields, and the IANA registration to link them to RFC5322.

RFC 5537, "Netnews Architecture and Protocols", November 2009

Note: This RFC has been updated by RFC 8315

Source of RFC: usefor (app)

Errata ID: 1981
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-28
Verifier Name: Lisa Dusseault
Date Verified: 2010-01-19

Section 3.2.1 says:

... first paragraph:

   If a relaying or serving agent receives an article from an injecting
|  or serving agent that is part of the same news server, it MAY leave
      ^^^^^^^
   the Path header field of the article unchanged.  [...]

It should say:

   If a relaying or serving agent receives an article from an injecting
|  or relaying agent that is part of the same news server, it MAY leave
      ^^^^^^^^
   the Path header field of the article unchanged.  [...]

Notes:

Rationale:
Cf. the definition of agent roles presented in Section 1 and the
first paragraph of Section 3:
Serving agents only forward to reading agents, and in that step,
the articles are not modified in any way.

Errata ID: 1993
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2009-12-28
Verifier Name: Lisa Dusseault
Date Verified: 2010-01-19

Section 5.2.1.1 says:

  A newgroup control message requesting creation of the moderated
  newsgroup example.admin.info.

      From: "example.* Administrator" <admin@noc.example>
      Newsgroups: example.admin.info
      Date: 27 Feb 2002 12:50:22 +0200
      Subject: cmsg newgroup example.admin.info moderated
      Approved: admin@noc.example
      Control: newgroup example.admin.info moderated
      Message-ID: <ng-example.admin.info-20020227@noc.example>
      MIME-Version: 1.0
      Content-Type: multipart/mixed; boundary="nxtprt"
      Content-Transfer-Encoding: 8bit

It should say:

  A newgroup control message requesting creation of the moderated
  newsgroup example.admin.info.

|     Path: not-for-mail
      From: "example.* Administrator" <admin@noc.example>
      Newsgroups: example.admin.info
      Date: 27 Feb 2002 12:50:22 +0200
      Subject: cmsg newgroup example.admin.info moderated
      Approved: admin@noc.example
      Control: newgroup example.admin.info moderated
      Message-ID: <ng-example.admin.info-20020227@noc.example>
      MIME-Version: 1.0
      Content-Type: multipart/mixed; boundary="nxtprt"
      Content-Transfer-Encoding: 8bit

Notes:

As the mandatory Path: header field is missing, this control message is only a proto-article.

A control message is defined in Section 5 as an article which contains a Control: header field. Therefore, a Path: header field should be added to the headers of this sample newgroup control article.

RFC 5544, "Syntax for Binding Documents with Time-Stamps", February 2010

Note: This RFC has been updated by RFC 5955

Source of RFC: INDEPENDENT

Errata ID: 6510
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lars Eggert
Date Reported: 2021-04-02
Verifier Name: RFC Editor
Date Verified: 2021-04-02

In the Copyright Notice, it says:

(http:trustee.ietf.org/license-info)

It should say:

(http://trustee.ietf.org/license-info)

RFC 5545, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", September 2009

Note: This RFC has been updated by RFC 5546, RFC 6868, RFC 7529, RFC 7953, RFC 7986, RFC 9073, RFC 9074, RFC 9253

Source of RFC: calsify (app)

Errata ID: 1911
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bernard Desruisseaux
Date Reported: 2009-10-13
Verifier Name: Alexey Melnikov
Date Verified: 2009-10-13

Section 2.1 says:

| DQUOTE                 | 22                |

It should say:

| DQUOTE                 | 34                |

Notes:

The codepoint for the DQUOTE character was erroneously specified in hexadecimal instead of decimal. Issue was found by Raimund Nisius.

Errata ID: 1913
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Anshul Agrawal
Date Reported: 2009-10-13
Verifier Name: Alexey Melnikov
Date Verified: 2010-07-07

Section 3.3.10 says:

represents the last Monday of the month.  The numeric value in a
BYDAY rule part with the FREQ rule part set to YEARLY corresponds
to an offset within the month when the BYMONTH rule part is
present, and corresponds to an offset within the year when the
BYWEEKNO or BYMONTH rule parts are present.  If an integer

It should say:

represents the last Monday of the month.  The numeric value in a
BYDAY rule part with the FREQ rule part set to YEARLY corresponds
to an offset within the month when the BYMONTH rule part is
present, and corresponds to an offset within the year when the
BYWEEKNO or BYMONTH rule parts are not present.  If an integer
                                   ^^^

Notes:

The original statement appears contradictory in itself.

Errata ID: 1916
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexey Melnikov
Date Reported: 2009-10-15
Verifier Name: Lisa Dusseault
Date Verified: 2010-03-10

Section 3.6.4 says:

  BEGIN:VFREEBUSY
  UID:19970901T115957Z-76A912@example.com
  DTSTAMP:19970901T120000Z
  ORGANIZER:jsmith@example.com
           ^

It should say:

  BEGIN:VFREEBUSY
  UID:19970901T115957Z-76A912@example.com
  DTSTAMP:19970901T120000Z
  ORGANIZER:mailto:jsmith@example.com
            ^^^^^^^

Notes:

The last example in section 3.6.4 is missing "mailto:" after the "ORGANIZER:"

Errata ID: 2039
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Arnout Engelen
Date Reported: 2010-02-10
Verifier Name: Alexey Melnikov
Date Verified: 2010-02-15

Section 4 says:

       BEGIN:VALARM
       ACTION:AUDIO
       TRIGGER:19980403T120000Z
       ATTACH;FMTTYPE=audio/basic:http://example.com/pub/audio-
        files/ssbanner.aud
       REPEAT:4
       DURATION:PT1H
       END:VALARM

It should say:

       BEGIN:VALARM
       ACTION:AUDIO
       TRIGGER;VALUE=DATE-TIME:19980403T120000Z
       ATTACH;FMTTYPE=audio/basic:http://example.com/pub/audio-
        files/ssbanner.aud
       REPEAT:4
       DURATION:PT1H
       END:VALARM

Notes:

The trigger is presented as a DATE-TIME, but the default type of this field is DURATION (3.8.6.3). Either the type must be specified (as per the corrected text), or specified in DURATION format.

Errata ID: 4271
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Neil Jenkins
Date Reported: 2015-02-12
Verifier Name: Barry Leiba
Date Verified: 2015-02-17

Section 3.3.10 says:

Recurrence rules may generate recurrence instances with an invalid
date (e.g., February 30) or nonexistent local time (e.g., 1:30 AM
on a day where the local time is moved forward by an hour at 1:00
AM).  Such recurrence instances MUST be ignored and MUST NOT be
counted as part of the recurrence set.

It should say:

Recurrence rules may generate recurrence instances with an invalid
date (e.g., February 30). Such recurrence instances MUST be ignored
and MUST NOT be counted as part of the recurrence set.

Recurrence rules may generate recurrence instances with a nonexistent
local time ((e.g., 1:30 AM on a day where the local time is moved
forward by an hour at 1:00 AM).  Such recurrence instances are
handled as specified in Section 3.3.5.

Notes:

The section about ignoring times that don't occur in the timezone of the expansion is contradicted by the later passage (p44):

"""If the computed local start time of a recurrence instance does not
exist, or occurs more than once, for the specified time zone, the
time of the recurrence instance is interpreted in the same manner
as an explicit DATE-TIME value describing that date and time, as
specified in Section 3.3.5."""

And this is the behaviour implemented by major clients such as Calendar.app and Google Calendar.

Errata ID: 2677
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bernard Desruisseaux
Date Reported: 2010-12-21
Verifier Name: Alexey Melnikov
Date Verified: 2011-01-20

Section 3.8.1.10 says:

Conformance:
This property can be specified once in "VEVENT" or "VTODO" calendar component.
                               ^^^^

It should say:

Conformance:
This property can be specified in "VEVENT" or "VTODO" calendar component.

Notes:

The word "once" was mistakenly introduced in RFC 5545.
RFC 2445 didn't have this issue.

Issues was previously reported by Dennis Gearon <gearond@sbcglobal.net>
(See Errata 2676) but proposed the wrong correction.

Errata ID: 3740
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Daniel Barkalow
Date Reported: 2013-09-29
Verifier Name: Barry Leiba
Date Verified: 2013-10-08

Section 4 says:

       BEGIN:VTIMEZONE
       TZID:America/New_York
       BEGIN:STANDARD
       DTSTART:19981025T020000
       TZOFFSETFROM:-0400
       TZOFFSETTO:-0500
       TZNAME:EST
       END:STANDARD
       BEGIN:DAYLIGHT
       DTSTART:19990404T020000
       TZOFFSETFROM:-0500
       TZOFFSETTO:-0400
       TZNAME:EDT
       END:DAYLIGHT
       END:VTIMEZONE

It should say:

       BEGIN:VTIMEZONE
       TZID:America/New_York
       BEGIN:STANDARD
       DTSTART:19671029T020000
       RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU;UNTIL=20061029T060000Z
       TZOFFSETFROM:-0400
       TZOFFSETTO:-0500
       TZNAME:EST
       END:STANDARD
       BEGIN:DAYLIGHT
       DTSTART:19870405T020000
       RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1SU;UNTIL=20060402T070000Z
       TZOFFSETFROM:-0500
       TZOFFSETTO:-0400
       TZNAME:EDT
       END:DAYLIGHT
       END:VTIMEZONE

Notes:

The time zone specification in the original example does not cover the event in the example (which occurs on 19980312, before both of the listed onsets).

---- Verifier notes -----
The corrected text uses part of the VTIMEZONE definition in the example on page 68.

Errata ID: 3779
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Daniele Mancini
Date Reported: 2013-10-31
Verifier Name: Barry Leiba
Date Verified: 2013-10-31

Section 3.3.10 says:

represents the last Monday of the month.  The numeric value in a
BYDAY rule part with the FREQ rule part set to YEARLY corresponds
to an offset within the month when the BYMONTH rule part is
present, and corresponds to an offset within the year when the
BYWEEKNO or BYMONTH rule parts are present.  If an integer
modifier is not present, it means all days of this type within the
specified frequency.  For example, within a MONTHLY rule, MO
represents all Mondays within the month.  The BYDAY rule part MUST
NOT be specified with a numeric value when the FREQ rule part is
not set to MONTHLY or YEARLY.  Furthermore, the BYDAY rule part
MUST NOT be specified with a numeric value with the FREQ rule part
set to YEARLY when the BYWEEKNO rule part is specified.

It should say:

represents the last Monday of the month.  The numeric value in a
BYDAY rule part with the FREQ rule part set to YEARLY corresponds
to an offset within the month when the BYMONTH rule part is
present, and corresponds to an offset within the year when the
BYMONTH rule part is not present.  If an integer
modifier is not present, it means all days of this type within the
specified frequency.  For example, within a MONTHLY rule, MO
represents all Mondays within the month.  The BYDAY rule part MUST
NOT be specified with a numeric value when the FREQ rule part is
not set to MONTHLY or YEARLY.  Furthermore, the BYDAY rule part
MUST NOT be specified with a numeric value with the FREQ rule part
set to YEARLY when the BYWEEKNO rule part is specified.

Notes:

Other than the missing 'not', pointed out in the errata 1913, the original text contradicts itself regarding BYWEEKNO.
At the beggining of the paragraph, it says that when using a YEARLY frequency with BYWEEKNO rule part, the integer part identifies an offset within the year (i.e. either in [-53, 0) or (0, 53], as it can be a week day in a valid week of the year, even if it is not clearly specified), but at the end of the paragraph, it states that offsets should not be specified in conjunction with a BYWEEKNO rule part.

Errata ID: 3883
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruce Florman
Date Reported: 2014-02-05
Verifier Name: Barry Leiba
Date Verified: 2014-02-14

Section 3.8.5.3 says:

      Every 3 hours from 9:00 AM to 5:00 PM on a specific day:

       DTSTART;TZID=America/New_York:19970902T090000
       RRULE:FREQ=HOURLY;INTERVAL=3;UNTIL=19970902T170000Z

       ==> (September 2, 1997 EDT) 09:00,12:00,15:00

It should say:

      Every 3 hours from 9:00 AM to 5:00 PM on a specific day:

       DTSTART;TZID=America/New_York:19970902T090000
       RRULE:FREQ=HOURLY;INTERVAL=3;UNTIL=19970902T210000Z

       ==> (September 2, 1997 EDT) 09:00,12:00,15:00

Notes:

The UNTIL rule part is specified with UTC time, which was four hours ahead of America/New_York on 19970902. So 170000Z would only be 1:00 PM on that day.

The corrected UNTIL rule matches the description (from 9 to 5). Note that "UNTIL=19970902T190000Z" would have the same effect (the last event is at 3 PM in New York, which is 19:00 Z), but 21:00 Z is what matches the description.

Errata ID: 4149
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Hiroaki KAWAI
Date Reported: 2014-10-29
Verifier Name: Barry Leiba
Date Verified: 2014-10-30

Section 4 says:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//RDU Software//NONSGML HandCal//EN
BEGIN:VFREEBUSY
ORGANIZER:mailto:jsmith@example.com
DTSTART:19980313T141711Z
DTEND:19980410T141711Z

It should say:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//RDU Software//NONSGML HandCal//EN
BEGIN:VFREEBUSY
UID:19970901T115957Z-76A912@example.com
DTSTAMP:19970901T120000Z
ORGANIZER:mailto:jsmith@example.com
DTSTART:19980313T141711Z
DTEND:19980410T141711Z

Notes:

3.6.4 says
fbprop = *(
;
; The following are REQUIRED,
; but MUST NOT occur more than once.
;
dtstamp / uid /

Errata ID: 6109
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Lars Henriksen
Date Reported: 2020-04-19
Verifier Name: Francesca Palombini
Date Verified: 2024-01-16

Section 3.6.1 says:

The anniversary type of "VEVENT" can span more than one date (i.e., "DTEND"
property value is set to a calendar date after the "DTSTART" property value).

It should say:

The anniversary type of "VEVENT" can span more than one date (i.e., "DTEND"
property value is set to a calendar date at least two days after the "DTSTART"
property value).

Notes:

"DTEND" comes, by definition (3.8.2.2), always after "DTSTART". The span (duration) is the difference between the two.

Errata ID: 7691
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tom Sydney Kerckhove
Date Reported: 2023-10-30
Verifier Name: Murray Kucherawy
Date Verified: 2023-11-01

Section 3.8.4.2 says:

The following is an example of this property with an alternate
representation of an LDAP URI to a directory entry containing the
contact information:

CONTACT;ALTREP="ldap://example.com:6666/o=ABC%20Industries\,
 c=US???(cn=Jim%20Dolittle)":Jim Dolittle\, ABC Industries\,
 +1-919-555-1234

It should say:

The following is an example of this property with an alternate
representation of an LDAP URI to a directory entry containing the
contact information:

CONTACT;ALTREP="ldap://example.com:6666/o=ABC%20Industries,
 c=US???(cn=Jim%20Dolittle)":Jim Dolittle\, ABC Industries\,
 +1-919-555-1234

Notes:

Note that the original text has an escaped comma in the ALTREP parameter value at the end of the unfolded line.

The characters '\' and ',' are allowed in quoted parameter values.
This means that the URL must be parsed as
"ldap://example.com:6666/o=ABC%20Industries\,c=US???(cn=Jim%20Dolittle)"
but this is not a valid URI because of the extra backslash.

Because commas do not need to be escaped in quoted parameter values, I assume that this is an error and the comma should not have been quoted.

Errata ID: 2497
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Scott Furry
Date Reported: 2010-08-21
Verifier Name: Peter Saint-Andre
Date Verified: 2010-09-14

Section 2.1 (pg 7) says:

              +------------------------+-------------------+
              | Character name         | Decimal codepoint |
              +------------------------+-------------------+
              | HTAB                   | 9                 |
              | LF                     | 10                |
              | CR                     | 13                |
-->           | DQUOTE                 | 22                |
-->           | SPACE                  | 32                |
... table continues

It should say:

              +------------------------+-------------------+
              | Character name         | Decimal codepoint |
              +------------------------+-------------------+
              | HTAB                   | 9                 |
              | LF                     | 10                |
              | CR                     | 13                |
-->           | SPACE                  | 32                |
-->           | DQUOTE                 | 34                |
                                         ^^
                                         corrected value
...table continues

Notes:

Correction to Table on page 7 of RFC updating the order of ASCII-US listing (decimal codepoint descending) and incorporating errata ID 1911(2009-10-13 - DQUOTE char listing shows hexadecimal value).

Errata ID: 2038
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Arnout Engelen
Date Reported: 2010-02-10
Verifier Name: Alexey Melnikov
Date Verified: 2010-02-15

Section Appendix A says:

   5.  The "DURATION" property can no longer appear in "VFREEBUSY"
       components.

A.2. Restrictions Removed

It should say:

   5.  The "DURATION" property can no longer appear in "VFREEBUSY"
       components.

   6.  Use of the "charset" Content-Type parameter in MIME transports 
       is now mandatory.

A.2. Restrictions Removed

Notes:

One change is missing from the list of changes.

Errata ID: 2516
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: David Wright
Date Reported: 2010-09-13
Verifier Name: Peter Saint-Andre
Date Verified: 2010-09-14

Section 3.8.4.1 says:

Example:  The following is an example of this property's use when
      another calendar user is acting on behalf of the "Attendee":

       ATTENDEE;SENT-BY=mailto:jan_doe@example.com;CN=John Smith:
        mailto:jsmith@example.com

It should say:

Example:  The following is an example of this property's use when
      another calendar user is acting on behalf of the "Attendee":

       ATTENDEE;SENT-BY="mailto:jan_doe@example.com";CN=John Smith:
                        ^                          ^
        mailto:jsmith@example.com

Notes:

In the specification for SENT-BY (3.2.18), the r-value MUST be explicitly bound by DQUOTEs (ABNF follows)

sentbyparam = "SENT-BY" "=" DQUOTE cal-address DQUOTE

Errata ID: 2527
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: David Wright
Date Reported: 2010-09-20
Verifier Name: Alexey Melnikov
Date Verified: 2010-11-04

Section 3.8.5.2 says:

  Example:  The following are examples of this property:

       RDATE:19970714T123000Z
       RDATE;TZID=America/New_York:19970714T083000

       RDATE;VALUE=PERIOD:19960403T020000Z/19960403T040000Z,
        19960404T010000Z/PT3H

       RDATE;VALUE=DATE:19970101,19970120,19970217,19970421
        19970526,19970704,19970901,19971014,19971128,19971129,19971225

It should say:

  Example:  The following are examples of this property:

       RDATE:19970714T123000Z
       RDATE;TZID=America/New_York:19970714T083000

       RDATE;VALUE=PERIOD:19960403T020000Z/19960403T040000Z,
        19960404T010000Z/PT3H

       RDATE;VALUE=DATE:19970101,19970120,19970217,19970421,
                                                           ^
        19970526,19970704,19970901,19971014,19971128,19971129,19971225

Notes:

Comma missing at the fold boundary.

Errata ID: 3747
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfie John
Date Reported: 2013-10-09
Verifier Name: Barry Leiba
Date Verified: 2013-10-26

Section 3.3.10 says:

   +----------+--------+--------+-------+-------+------+-------+------+
   |          |SECONDLY|MINUTELY|HOURLY |DAILY  |WEEKLY|MONTHLY|YEARLY|
   +----------+--------+--------+-------+-------+------+-------+------+
   |BYMONTH   |Limit   |Limit   |Limit  |Limit  |Limit |Limit  |Expand|
   +----------+--------+--------+-------+-------+------+-------+------+
   |BYWEEKNO  |N/A     |N/A     |N/A    |N/A    |N/A   |N/A    |Expand|
   +----------+--------+--------+-------+-------+------+-------+------+
   |BYYEARDAY |Limit   |Limit   |Limit  |N/A    |N/A   |N/A    |Expand|
   +----------+--------+--------+-------+-------+------+-------+------+
   |BYMONTHDAY|Limit   |Limit   |Limit  |Limit  |N/A   |Expand |Expand|
   +----------+--------+--------+-------+-------+------+-------+------+
   |BYDAY     |Limit   |Limit   |Limit  |Limit  |Expand|Note 1 |Note 2|
   +----------+--------+--------+-------+-------+------+-------+------+
   |BYHOUR    |Limit   |Limit   |Limit  |Expand |Expand|Expand |Expand|
   +----------+--------+--------+-------+-------+------+-------+------+
   |BYMINUTE  |Limit   |Limit   |Expand |Expand |Expand|Expand |Expand|
   +----------+--------+--------+-------+-------+------+-------+------+
   |BYSECOND  |Limit   |Expand  |Expand |Expand |Expand|Expand |Expand|
   +----------+--------+--------+-------+-------+------+-------+------+
   |BYSETPOS  |Limit   |Limit   |Limit  |Limit  |Limit |Limit  |Limit |
   +----------+--------+--------+-------+-------+------+-------+------+

      Note 1:  Limit if BYMONTHDAY is present; otherwise, special expand
               for MONTHLY.

      Note 2:  Limit if BYYEARDAY or BYMONTHDAY is present; otherwise,
               special expand for WEEKLY if BYWEEKNO present; otherwise,
               special expand for MONTHLY if BYMONTH present; otherwise,
               special expand for YEARLY.

It should say:

   +----------+--------+--------+-------+-------+------+-------+------+
   |          |SECONDLY|MINUTELY|HOURLY |DAILY  |WEEKLY|MONTHLY|YEARLY|
   +----------+--------+--------+-------+-------+------+-------+------+
   |BYMONTH   |Limit   |Limit   |Limit  |Limit  |Limit |Limit  |Expand|
   +----------+--------+--------+-------+-------+------+-------+------+
   |BYWEEKNO  |N/A     |N/A     |N/A    |N/A    |N/A   |N/A    |Expand|
   +----------+--------+--------+-------+-------+------+-------+------+
   |BYYEARDAY |Limit   |Limit   |Limit  |N/A    |N/A   |N/A    |Expand|
   +----------+--------+--------+-------+-------+------+-------+------+
   |BYMONTHDAY|Limit   |Limit   |Limit  |Limit  |N/A   |Expand |Expand|
   +----------+--------+--------+-------+-------+------+-------+------+
   |BYDAY     |Limit   |Limit   |Limit  |Limit  |Expand|Note 1 |Note 2|
   +----------+--------+--------+-------+-------+------+-------+------+
   |BYHOUR    |Limit   |Limit   |Limit  |Expand |Expand|Expand |Expand|
   +----------+--------+--------+-------+-------+------+-------+------+
   |BYMINUTE  |Limit   |Limit   |Expand |Expand |Expand|Expand |Expand|
   +----------+--------+--------+-------+-------+------+-------+------+
   |BYSECOND  |Limit   |Expand  |Expand |Expand |Expand|Expand |Expand|
   +----------+--------+--------+-------+-------+------+-------+------+
   |BYSETPOS  |Limit   |Limit   |Limit  |Limit  |Limit |Limit  |Limit |
   +----------+--------+--------+-------+-------+------+-------+------+

      Note 1:  Limit if BYMONTHDAY is present; otherwise, special expand
               for MONTHLY.

      Note 2:  Limit if BYYEARDAY or BYMONTHDAY is present; otherwise,
               special expand for YEARLY.

Notes:

The change is to "Note 2":
Removed WEEKLY and MONTHLY clause as Note 2 only applies to FREQ = YEARLY.

Errata ID: 4414
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Joseph Silvestre
Date Reported: 2015-07-10
Verifier Name: Barry Leiba
Date Verified: 2015-07-21

Section 3.3.10 says:

      The UNTIL rule part defines a DATE or DATE-TIME value that bounds
      the recurrence rule in an inclusive manner.  If the value
      specified by UNTIL is synchronized with the specified recurrence,
      this DATE or DATE-TIME becomes the last instance of the
      recurrence.  The value of the UNTIL rule part MUST have the same
      value type as the "DTSTART" property.  Furthermore, if the
      "DTSTART" property is specified as a date with local time, then
      the UNTIL rule part MUST also be specified as a date with local
      time.  If the "DTSTART" property is specified as a date with UTC
      time or a date with local time and time zone reference, then the
      UNTIL rule part MUST be specified as a date with UTC time.  In the
      case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL
      rule part MUST always be specified as a date with UTC time.  If
      specified as a DATE-TIME value, then it MUST be specified in a UTC
      time format.  If not present, and the COUNT rule part is also not
      present, the "RRULE" is considered to repeat forever.

It should say:

      The UNTIL rule part defines a DATE or DATE-TIME value that bounds
      the recurrence rule in an inclusive manner.  If the value
      specified by UNTIL is synchronized with the specified recurrence,
      this DATE or DATE-TIME becomes the last instance of the
      recurrence.  The value of the UNTIL rule part MUST have the same
      value type as the "DTSTART" property.  Furthermore, if the
      "DTSTART" property is specified as a date with local time, then
      the UNTIL rule part MUST also be specified as a date with local
      time.  If the "DTSTART" property is specified as a date with UTC
      time or a date with local time and time zone reference, then the
      UNTIL rule part MUST be specified as a date with UTC time.  In the
      case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL
      rule part MUST always be specified as a date with UTC time.
      If not present, and the COUNT rule part is also not
      present, the "RRULE" is considered to repeat forever.

Notes:

The following sentence from RFC 2445 should have been removed from the text.

If
specified as a DATE-TIME value, then it MUST be specified in a UTC
time format.

Errata ID: 5602
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Carsten Bormann
Date Reported: 2019-01-15
Verifier Name: Francesca Palombini
Date Verified: 2024-01-16

Section 3.1.3 says:

     ATTACH;FMTTYPE=text/plain;ENCODING=BASE64;VALUE=BINARY:VGhlIH
      F1aWNrIGJyb3duIGZveCBqdW1wcyBvdmVyIHRoZSBsYXp5IGRvZy4

It should say:

     ATTACH;FMTTYPE=text/plain;ENCODING=BASE64;VALUE=BINARY:VGhlIH
      F1aWNrIGJyb3duIGZveCBqdW1wcyBvdmVyIHRoZSBsYXp5IGRvZy4=

Notes:

The base64 text used in the example misses the base64 padding. RFC 5545 appears to be using base64 according to RFC 4648 Section 4 with padding throughout, except for this example. (The corrected text decodes to "The quick brown fox jumps over the lazy dog.") Beyond temporary confusion in implementers, it is possible that this example will turn up in a test suite and ultimately cause unnecessarily lenient behavior of decoders ("soup"); it should be either clarified that this lenient behavior is not the intention or the behavior should be codified.

Errata ID: 5794
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eugene Adell
Date Reported: 2019-07-28
Verifier Name: Barry Leiba
Date Verified: 2020-12-15

Section ToC says:

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Basic Grammar and Conventions . . . . . . . . . . . . . . . .   6
     2.1.  Formatting Conventions  . . . . . . . . . . . . . . . . .   6
     2.2.  Related Memos . . . . . . . . . . . . . . . . . . . . . .   7
   3.  iCalendar Object Specification  . . . . . . . . . . . . . . .   8
     3.1.  Content Lines . . . . . . . . . . . . . . . . . . . . . .   8
       3.1.1.  List and Field Separators . . . . . . . . . . . . . .  11
       3.1.2.  Multiple Values . . . . . . . . . . . . . . . . . . .  11
       3.1.3.  Binary Content  . . . . . . . . . . . . . . . . . . .  11
       3.1.4.  Character Set . . . . . . . . . . . . . . . . . . . .  12
     3.2.  Property Parameters . . . . . . . . . . . . . . . . . . .  12
       3.2.1.  Alternate Text Representation . . . . . . . . . . . .  13
       3.2.2.  Common Name . . . . . . . . . . . . . . . . . . . . .  15
       3.2.3.  Calendar User Type  . . . . . . . . . . . . . . . . .  15
       3.2.4.  Delegators  . . . . . . . . . . . . . . . . . . . . .  16
       3.2.5.  Delegatees  . . . . . . . . . . . . . . . . . . . . .  16
       3.2.6.  Directory Entry Reference . . . . . . . . . . . . . .  17
       3.2.7.  Inline Encoding . . . . . . . . . . . . . . . . . . .  17
       3.2.8.  Format Type . . . . . . . . . . . . . . . . . . . . .  18
       3.2.9.  Free/Busy Time Type . . . . . . . . . . . . . . . . .  19
       3.2.10. Language  . . . . . . . . . . . . . . . . . . . . . .  20
       3.2.11. Group or List Membership  . . . . . . . . . . . . . .  20
       3.2.12. Participation Status  . . . . . . . . . . . . . . . .  21
       3.2.13. Recurrence Identifier Range . . . . . . . . . . . . .  22
       3.2.14. Alarm Trigger Relationship  . . . . . . . . . . . . .  23
       3.2.15. Relationship Type . . . . . . . . . . . . . . . . . .  24
       3.2.16. Participation Role  . . . . . . . . . . . . . . . . .  25
       3.2.17. RSVP Expectation  . . . . . . . . . . . . . . . . . .  25
       3.2.18. Sent By . . . . . . . . . . . . . . . . . . . . . . .  26
       3.2.19. Time Zone Identifier  . . . . . . . . . . . . . . . .  26
       3.2.20. Value Data Types  . . . . . . . . . . . . . . . . . .  28
     3.3.  Property Value Data Types . . . . . . . . . . . . . . . .  29
       3.3.1.  Binary  . . . . . . . . . . . . . . . . . . . . . . .  29
       3.3.2.  Boolean . . . . . . . . . . . . . . . . . . . . . . .  30
       3.3.3.  Calendar User Address . . . . . . . . . . . . . . . .  30
       3.3.4.  Date  . . . . . . . . . . . . . . . . . . . . . . . .  31
       3.3.5.  Date-Time . . . . . . . . . . . . . . . . . . . . . .  31
       3.3.6.  Duration  . . . . . . . . . . . . . . . . . . . . . .  34
       3.3.7.  Float . . . . . . . . . . . . . . . . . . . . . . . .  35
       3.3.8.  Integer . . . . . . . . . . . . . . . . . . . . . . .  35
       3.3.9.  Period of Time  . . . . . . . . . . . . . . . . . . .  36
       3.3.10. Recurrence Rule . . . . . . . . . . . . . . . . . . .  37
       3.3.11. Text  . . . . . . . . . . . . . . . . . . . . . . . .  45
       3.3.12. Time  . . . . . . . . . . . . . . . . . . . . . . . .  46
       3.3.13. URI . . . . . . . . . . . . . . . . . . . . . . . . .  48
       3.3.14. UTC Offset  . . . . . . . . . . . . . . . . . . . . .  49
     3.4.  iCalendar Object  . . . . . . . . . . . . . . . . . . . .  49
     3.5.  Property  . . . . . . . . . . . . . . . . . . . . . . . .  50
     3.6.  Calendar Components . . . . . . . . . . . . . . . . . . .  50
       3.6.1.  Event Component . . . . . . . . . . . . . . . . . . .  52
       3.6.2.  To-Do Component . . . . . . . . . . . . . . . . . . .  56
       3.6.3.  Journal Component . . . . . . . . . . . . . . . . . .  58
       3.6.4.  Free/Busy Component . . . . . . . . . . . . . . . . .  60
       3.6.5.  Time Zone Component . . . . . . . . . . . . . . . . .  63
       3.6.6.  Alarm Component . . . . . . . . . . . . . . . . . . .  72
     3.7.  Calendar Properties . . . . . . . . . . . . . . . . . . .  77
       3.7.1.  Calendar Scale  . . . . . . . . . . . . . . . . . . .  77
       3.7.2.  Method  . . . . . . . . . . . . . . . . . . . . . . .  78
       3.7.3.  Product Identifier  . . . . . . . . . . . . . . . . .  79
       3.7.4.  Version . . . . . . . . . . . . . . . . . . . . . . .  80
     3.8.  Component Properties  . . . . . . . . . . . . . . . . . .  81
       3.8.1.  Descriptive Component Properties  . . . . . . . . . .  81
         3.8.1.1.  Attachment  . . . . . . . . . . . . . . . . . . .  81
         3.8.1.2.  Categories  . . . . . . . . . . . . . . . . . . .  82
         3.8.1.3.  Classification  . . . . . . . . . . . . . . . . .  83
         3.8.1.4.  Comment . . . . . . . . . . . . . . . . . . . . .  84
         3.8.1.5.  Description . . . . . . . . . . . . . . . . . . .  85
         3.8.1.6.  Geographic Position . . . . . . . . . . . . . . .  87
         3.8.1.7.  Location  . . . . . . . . . . . . . . . . . . . .  88
         3.8.1.8.  Percent Complete  . . . . . . . . . . . . . . . .  89
         3.8.1.9.  Priority  . . . . . . . . . . . . . . . . . . . .  90
         3.8.1.10. Resources . . . . . . . . . . . . . . . . . . . .  92
         3.8.1.11. Status  . . . . . . . . . . . . . . . . . . . . .  93
         3.8.1.12. Summary . . . . . . . . . . . . . . . . . . . . .  94
       3.8.2.  Date and Time Component Properties  . . . . . . . . .  95
         3.8.2.1.  Date-Time Completed . . . . . . . . . . . . . . .  95
         3.8.2.2.  Date-Time End . . . . . . . . . . . . . . . . . .  96
         3.8.2.3.  Date-Time Due . . . . . . . . . . . . . . . . . .  97
         3.8.2.4.  Date-Time Start . . . . . . . . . . . . . . . . .  99
         3.8.2.5.  Duration  . . . . . . . . . . . . . . . . . . . . 100
         3.8.2.6.  Free/Busy Time  . . . . . . . . . . . . . . . . . 101
         3.8.2.7.  Time Transparency . . . . . . . . . . . . . . . . 102
       3.8.3.  Time Zone Component Properties  . . . . . . . . . . . 103
         3.8.3.1.  Time Zone Identifier  . . . . . . . . . . . . . . 103
         3.8.3.2.  Time Zone Name  . . . . . . . . . . . . . . . . . 105
         3.8.3.3.  Time Zone Offset From . . . . . . . . . . . . . . 106
         3.8.3.4.  Time Zone Offset To . . . . . . . . . . . . . . . 106
         3.8.3.5.  Time Zone URL . . . . . . . . . . . . . . . . . . 107
       3.8.4.  Relationship Component Properties . . . . . . . . . . 108
         3.8.4.1.  Attendee  . . . . . . . . . . . . . . . . . . . . 108
         3.8.4.2.  Contact . . . . . . . . . . . . . . . . . . . . . 111

         3.8.4.3.  Organizer . . . . . . . . . . . . . . . . . . . . 113
         3.8.4.4.  Recurrence ID . . . . . . . . . . . . . . . . . . 114
         3.8.4.5.  Related To  . . . . . . . . . . . . . . . . . . . 117
         3.8.4.6.  Uniform Resource Locator  . . . . . . . . . . . . 118
         3.8.4.7.  Unique Identifier . . . . . . . . . . . . . . . . 119
       3.8.5.  Recurrence Component Properties . . . . . . . . . . . 120
         3.8.5.1.  Exception Date-Times  . . . . . . . . . . . . . . 120
         3.8.5.2.  Recurrence Date-Times . . . . . . . . . . . . . . 122
         3.8.5.3.  Recurrence Rule . . . . . . . . . . . . . . . . . 124
       3.8.6.  Alarm Component Properties  . . . . . . . . . . . . . 134
         3.8.6.1.  Action  . . . . . . . . . . . . . . . . . . . . . 134
         3.8.6.2.  Repeat Count  . . . . . . . . . . . . . . . . . . 135
         3.8.6.3.  Trigger . . . . . . . . . . . . . . . . . . . . . 135
       3.8.7.  Change Management Component Properties  . . . . . . . 138
         3.8.7.1.  Date-Time Created . . . . . . . . . . . . . . . . 138
         3.8.7.2.  Date-Time Stamp . . . . . . . . . . . . . . . . . 139
         3.8.7.3.  Last Modified . . . . . . . . . . . . . . . . . . 140
         3.8.7.4.  Sequence Number . . . . . . . . . . . . . . . . . 141
       3.8.8.  Miscellaneous Component Properties  . . . . . . . . . 142
         3.8.8.1.  IANA Properties . . . . . . . . . . . . . . . . . 142
         3.8.8.2.  Non-Standard Properties . . . . . . . . . . . . . 142
         3.8.8.3.  Request Status  . . . . . . . . . . . . . . . . . 144
   4.  iCalendar Object Examples . . . . . . . . . . . . . . . . . . 146
   5.  Recommended Practices . . . . . . . . . . . . . . . . . . . . 150
   6.  Internationalization Considerations . . . . . . . . . . . . . 151
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . 151
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . 151
     8.1.  iCalendar Media Type Registration . . . . . . . . . . . . 151
     8.2.  New iCalendar Elements Registration . . . . . . . . . . . 155
       8.2.1.  iCalendar Elements Registration Procedure . . . . . . 155
       8.2.2.  Registration Template for Components  . . . . . . . . 155
       8.2.3.  Registration Template for Properties  . . . . . . . . 156
       8.2.4.  Registration Template for Parameters  . . . . . . . . 156
       8.2.5.  Registration Template for Value Data Types  . . . . . 157
       8.2.6.  Registration Template for Values  . . . . . . . . . . 157
     8.3.  Initial iCalendar Elements Registries . . . . . . . . . . 158
       8.3.1.  Components Registry . . . . . . . . . . . . . . . . . 158
       8.3.2.  Properties Registry . . . . . . . . . . . . . . . . . 158
       8.3.3.  Parameters Registry . . . . . . . . . . . . . . . . . 161
       8.3.4.  Value Data Types Registry . . . . . . . . . . . . . . 162
       8.3.5.  Calendar User Types Registry  . . . . . . . . . . . . 162
       8.3.6.  Free/Busy Time Types Registry . . . . . . . . . . . . 163
       8.3.7.  Participation Statuses Registry . . . . . . . . . . . 163
       8.3.8.  Relationship Types Registry . . . . . . . . . . . . . 164
       8.3.9.  Participation Roles Registry  . . . . . . . . . . . . 164
       8.3.10. Actions Registry  . . . . . . . . . . . . . . . . . . 165
       8.3.11. Classifications Registry  . . . . . . . . . . . . . . 165
       8.3.12. Methods Registry  . . . . . . . . . . . . . . . . . . 165
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 165
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . 166
     10.1. Normative References  . . . . . . . . . . . . . . . . . . 166
     10.2. Informative References  . . . . . . . . . . . . . . . . . 167
   Appendix A.  Differences from RFC 2445  . . . . . . . . . . . . . 169
     A.1.  New Restrictions  . . . . . . . . . . . . . . . . . . . . 169
     A.2.  Restrictions Removed  . . . . . . . . . . . . . . . . . . 169
     A.3.  Deprecated Features . . . . . . . . . . . . . . . . . . . 169

It should say:

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Basic Grammar and Conventions . . . . . . . . . . . . . . . .   6
     2.1.  Formatting Conventions  . . . . . . . . . . . . . . . . .   6
     2.2.  Related Memos . . . . . . . . . . . . . . . . . . . . . .   8
   3.  iCalendar Object Specification  . . . . . . . . . . . . . . .   8
     3.1.  Content Lines . . . . . . . . . . . . . . . . . . . . . .   9
       3.1.1.  List and Field Separators . . . . . . . . . . . . . .  11
       3.1.2.  Multiple Values . . . . . . . . . . . . . . . . . . .  12
       3.1.3.  Binary Content  . . . . . . . . . . . . . . . . . . .  12
       3.1.4.  Character Set . . . . . . . . . . . . . . . . . . . .  13
     3.2.  Property Parameters . . . . . . . . . . . . . . . . . . .  13
       3.2.1.  Alternate Text Representation . . . . . . . . . . . .  14
       3.2.2.  Common Name . . . . . . . . . . . . . . . . . . . . .  15
       3.2.3.  Calendar User Type  . . . . . . . . . . . . . . . . .  16
       3.2.4.  Delegators  . . . . . . . . . . . . . . . . . . . . .  17
       3.2.5.  Delegatees  . . . . . . . . . . . . . . . . . . . . .  17
       3.2.6.  Directory Entry Reference . . . . . . . . . . . . . .  18
       3.2.7.  Inline Encoding . . . . . . . . . . . . . . . . . . .  18
       3.2.8.  Format Type . . . . . . . . . . . . . . . . . . . . .  19
       3.2.9.  Free/Busy Time Type . . . . . . . . . . . . . . . . .  20
       3.2.10. Language  . . . . . . . . . . . . . . . . . . . . . .  21
       3.2.11. Group or List Membership  . . . . . . . . . . . . . .  21
       3.2.12. Participation Status  . . . . . . . . . . . . . . . .  22
       3.2.13. Recurrence Identifier Range . . . . . . . . . . . . .  23
       3.2.14. Alarm Trigger Relationship  . . . . . . . . . . . . .  24
       3.2.15. Relationship Type . . . . . . . . . . . . . . . . . .  25
       3.2.16. Participation Role  . . . . . . . . . . . . . . . . .  25
       3.2.17. RSVP Expectation  . . . . . . . . . . . . . . . . . .  26
       3.2.18. Sent By . . . . . . . . . . . . . . . . . . . . . . .  27
       3.2.19. Time Zone Identifier  . . . . . . . . . . . . . . . .  27
       3.2.20. Value Data Types  . . . . . . . . . . . . . . . . . .  29
     3.3.  Property Value Data Types . . . . . . . . . . . . . . . .  30
       3.3.1.  Binary  . . . . . . . . . . . . . . . . . . . . . . .  30
       3.3.2.  Boolean . . . . . . . . . . . . . . . . . . . . . . .  31
       3.3.3.  Calendar User Address . . . . . . . . . . . . . . . .  31
       3.3.4.  Date  . . . . . . . . . . . . . . . . . . . . . . . .  32
       3.3.5.  Date-Time . . . . . . . . . . . . . . . . . . . . . .  32
       3.3.6.  Duration  . . . . . . . . . . . . . . . . . . . . . .  35
       3.3.7.  Float . . . . . . . . . . . . . . . . . . . . . . . .  36
       3.3.8.  Integer . . . . . . . . . . . . . . . . . . . . . . .  37
       3.3.9.  Period of Time  . . . . . . . . . . . . . . . . . . .  37
       3.3.10. Recurrence Rule . . . . . . . . . . . . . . . . . . .  38
       3.3.11. Text  . . . . . . . . . . . . . . . . . . . . . . . .  45
       3.3.12. Time  . . . . . . . . . . . . . . . . . . . . . . . .  47
       3.3.13. URI . . . . . . . . . . . . . . . . . . . . . . . . .  49
       3.3.14. UTC Offset  . . . . . . . . . . . . . . . . . . . . .  49
     3.4.  iCalendar Object  . . . . . . . . . . . . . . . . . . . .  50
     3.5.  Property  . . . . . . . . . . . . . . . . . . . . . . . .  51
     3.6.  Calendar Components . . . . . . . . . . . . . . . . . . .  51
       3.6.1.  Event Component . . . . . . . . . . . . . . . . . . .  52
       3.6.2.  To-Do Component . . . . . . . . . . . . . . . . . . .  55
       3.6.3.  Journal Component . . . . . . . . . . . . . . . . . .  57
       3.6.4.  Free/Busy Component . . . . . . . . . . . . . . . . .  59
       3.6.5.  Time Zone Component . . . . . . . . . . . . . . . . .  62
       3.6.6.  Alarm Component . . . . . . . . . . . . . . . . . . .  71
     3.7.  Calendar Properties . . . . . . . . . . . . . . . . . . .  76
       3.7.1.  Calendar Scale  . . . . . . . . . . . . . . . . . . .  76
       3.7.2.  Method  . . . . . . . . . . . . . . . . . . . . . . .  77
       3.7.3.  Product Identifier  . . . . . . . . . . . . . . . . .  78
       3.7.4.  Version . . . . . . . . . . . . . . . . . . . . . . .  79
     3.8.  Component Properties  . . . . . . . . . . . . . . . . . .  80
       3.8.1.  Descriptive Component Properties  . . . . . . . . . .  80
         3.8.1.1.  Attachment  . . . . . . . . . . . . . . . . . . .  80
         3.8.1.2.  Categories  . . . . . . . . . . . . . . . . . . .  81
         3.8.1.3.  Classification  . . . . . . . . . . . . . . . . .  82
         3.8.1.4.  Comment . . . . . . . . . . . . . . . . . . . . .  83
         3.8.1.5.  Description . . . . . . . . . . . . . . . . . . .  84
         3.8.1.6.  Geographic Position . . . . . . . . . . . . . . .  85
         3.8.1.7.  Location  . . . . . . . . . . . . . . . . . . . .  87
         3.8.1.8.  Percent Complete  . . . . . . . . . . . . . . . .  88
         3.8.1.9.  Priority  . . . . . . . . . . . . . . . . . . . .  89
         3.8.1.10. Resources . . . . . . . . . . . . . . . . . . . .  91
         3.8.1.11. Status  . . . . . . . . . . . . . . . . . . . . .  92
         3.8.1.12. Summary . . . . . . . . . . . . . . . . . . . . .  93
       3.8.2.  Date and Time Component Properties  . . . . . . . . .  94
         3.8.2.1.  Date-Time Completed . . . . . . . . . . . . . . .  94
         3.8.2.2.  Date-Time End . . . . . . . . . . . . . . . . . .  95
         3.8.2.3.  Date-Time Due . . . . . . . . . . . . . . . . . .  96
         3.8.2.4.  Date-Time Start . . . . . . . . . . . . . . . . .  97
         3.8.2.5.  Duration  . . . . . . . . . . . . . . . . . . . .  99
         3.8.2.6.  Free/Busy Time  . . . . . . . . . . . . . . . . . 100
         3.8.2.7.  Time Transparency . . . . . . . . . . . . . . . . 101
       3.8.3.  Time Zone Component Properties  . . . . . . . . . . . 102
         3.8.3.1.  Time Zone Identifier  . . . . . . . . . . . . . . 102
         3.8.3.2.  Time Zone Name  . . . . . . . . . . . . . . . . . 103
         3.8.3.3.  Time Zone Offset From . . . . . . . . . . . . . . 104
         3.8.3.4.  Time Zone Offset To . . . . . . . . . . . . . . . 105
         3.8.3.5.  Time Zone URL . . . . . . . . . . . . . . . . . . 106
       3.8.4.  Relationship Component Properties . . . . . . . . . . 106
         3.8.4.1.  Attendee  . . . . . . . . . . . . . . . . . . . . 107
         3.8.4.2.  Contact . . . . . . . . . . . . . . . . . . . . . 109
         3.8.4.3.  Organizer . . . . . . . . . . . . . . . . . . . . 111
         3.8.4.4.  Recurrence ID . . . . . . . . . . . . . . . . . . 112
         3.8.4.5.  Related To  . . . . . . . . . . . . . . . . . . . 115
         3.8.4.6.  Uniform Resource Locator  . . . . . . . . . . . . 116
         3.8.4.7.  Unique Identifier . . . . . . . . . . . . . . . . 117
       3.8.5.  Recurrence Component Properties . . . . . . . . . . . 118
         3.8.5.1.  Exception Date-Times  . . . . . . . . . . . . . . 118
         3.8.5.2.  Recurrence Date-Times . . . . . . . . . . . . . . 120
         3.8.5.3.  Recurrence Rule . . . . . . . . . . . . . . . . . 122
       3.8.6.  Alarm Component Properties  . . . . . . . . . . . . . 132
         3.8.6.1.  Action  . . . . . . . . . . . . . . . . . . . . . 132
         3.8.6.2.  Repeat Count  . . . . . . . . . . . . . . . . . . 133
         3.8.6.3.  Trigger . . . . . . . . . . . . . . . . . . . . . 133
       3.8.7.  Change Management Component Properties  . . . . . . . 136
         3.8.7.1.  Date-Time Created . . . . . . . . . . . . . . . . 136
         3.8.7.2.  Date-Time Stamp . . . . . . . . . . . . . . . . . 137
         3.8.7.3.  Last Modified . . . . . . . . . . . . . . . . . . 138
         3.8.7.4.  Sequence Number . . . . . . . . . . . . . . . . . 138
       3.8.8.  Miscellaneous Component Properties  . . . . . . . . . 139
         3.8.8.1.  IANA Properties . . . . . . . . . . . . . . . . . 140
         3.8.8.2.  Non-Standard Properties . . . . . . . . . . . . . 140
         3.8.8.3.  Request Status  . . . . . . . . . . . . . . . . . 141
   4.  iCalendar Object Examples . . . . . . . . . . . . . . . . . . 144
   5.  Recommended Practices . . . . . . . . . . . . . . . . . . . . 147
   6.  Internationalization Considerations . . . . . . . . . . . . . 148
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . 148
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . 149
     8.1.  iCalendar Media Type Registration . . . . . . . . . . . . 149
     8.2.  New iCalendar Elements Registration . . . . . . . . . . . 152
       8.2.1.  iCalendar Elements Registration Procedure . . . . . . 152
       8.2.2.  Registration Template for Components  . . . . . . . . 152
       8.2.3.  Registration Template for Properties  . . . . . . . . 153
       8.2.4.  Registration Template for Parameters  . . . . . . . . 153
       8.2.5.  Registration Template for Value Data Types  . . . . . 154
       8.2.6.  Registration Template for Values  . . . . . . . . . . 154
     8.3.  Initial iCalendar Elements Registries . . . . . . . . . . 155
       8.3.1.  Components Registry . . . . . . . . . . . . . . . . . 155
       8.3.2.  Properties Registry . . . . . . . . . . . . . . . . . 156
       8.3.3.  Parameters Registry . . . . . . . . . . . . . . . . . 158
       8.3.4.  Value Data Types Registry . . . . . . . . . . . . . . 159
       8.3.5.  Calendar User Types Registry  . . . . . . . . . . . . 160
       8.3.6.  Free/Busy Time Types Registry . . . . . . . . . . . . 160
       8.3.7.  Participation Statuses Registry . . . . . . . . . . . 161
       8.3.8.  Relationship Types Registry . . . . . . . . . . . . . 161
       8.3.9.  Participation Roles Registry  . . . . . . . . . . . . 162
       8.3.10. Actions Registry  . . . . . . . . . . . . . . . . . . 162
       8.3.11. Classifications Registry  . . . . . . . . . . . . . . 162
       8.3.12. Methods Registry  . . . . . . . . . . . . . . . . . . 163
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 163
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . 164
     10.1. Normative References  . . . . . . . . . . . . . . . . . . 164
     10.2. Informative References  . . . . . . . . . . . . . . . . . 165
   Appendix A.  Differences from RFC 2445  . . . . . . . . . . . . . 167
     A.1.  New Restrictions  . . . . . . . . . . . . . . . . . . . . 167
     A.2.  Restrictions Removed  . . . . . . . . . . . . . . . . . . 167
     A.3.  Deprecated Features . . . . . . . . . . . . . . . . . . . 167

Notes:

Most of the Table Of Contents gives wrong page numbers.

===== Verifier notes =====
Indeed: the character table in Section 2.1, which appears at the top of page 8 in the RFC, appears to have been added during final editing, and has thrown off the page numbering for all sections beginning with 2.2.

Errata ID: 7332
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tobias Subklewe
Date Reported: 2023-02-04
Verifier Name: Francesca Palombini
Date Verified: 2024-01-16

Section 3.3.9 says:

The period start at 18:00:00 on January 1, 1997 and lasting 5
hours and 30 minutes would be:

19970101T180000Z/PT5H30M

It should say:

The period start at 18:00:00 on January 1, 1997 and lasting 5
hours and 30 minutes would be:

19970101T180000/PT5H30M

Notes:

I do not know if this is an editorial or technical issue.

If I understand the datetime value (Section 3.3.5) correct the last character should only be "Z" if the value is in UTC.

In the first example in section 3.3.9 UTC is explicitely mentioned but not in the second example.

RFC 5546, "iCalendar Transport-Independent Interoperability Protocol (iTIP)", December 2009

Note: This RFC has been updated by RFC 6638

Source of RFC: calsify (app)

Errata ID: 2097
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bernard Desruisseaux
Date Reported: 2010-03-29
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-21

Section 3.4.6 says:

   +--------------------+----------+-----------------------------------+
   | Component/Property | Presence | Comment                           |
   +--------------------+----------+-----------------------------------+
   |                    |          |                                   |
   | ...                |          |                                   |
   |                    |          |                                   |
   |   ORGANIZER        | 0        |                                   |

It should say:

   +--------------------+----------+-----------------------------------+
   | Component/Property | Presence | Comment                           |
   +--------------------+----------+-----------------------------------+
   |                    |          |                                   |
   | ...                |          |                                   |
   |                    |          |                                   |
   |   ORGANIZER        | 1        |                                   |

Notes:

The "ORGANIZER" property should be REQUIRED in "VTODO" calendar components with the "REFRESH" method.

Errata ID: 2331
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Filip Navara
Date Reported: 2010-07-15
Verifier Name: Alexey Melnikov
Date Verified: 2010-07-26

Section 3.4. says:

   | REPLY          | Reply to a VTODO request.  Attendees MAY set     |
   |                | PARTSTAT to ACCEPTED, DECLINED, TENTATIVE,       |
   |                | DELEGATED, PARTIAL, and COMPLETED.               |
 

It should say:

   | REPLY          | Reply to a VTODO request.  Attendees MAY set     |
   |                | PARTSTAT to ACCEPTED, DECLINED, TENTATIVE,       |
   |                | DELEGATED, IN-PROCESS, and COMPLETED.            |

Notes:

The PARTSTAT value for VTODO component that is in progress is IN-PROCESS, not PARTIAL, per RFC 5545.

Errata ID: 3932
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfie John
Date Reported: 2014-03-25
Verifier Name: Barry Leiba
Date Verified: 2014-03-28

Section 3.1.2 says:

   |   DAYLIGHT         | 0+       | MUST be one or more of either     |
   |                    |          | STANDARD or DAYLIGHT.             |
   |     COMMENT        | 0+       |                                   |
   |     DTSTART        | 1        | MUST be local time format.        |
   |     RDATE          | 0+       |                                   |
   |     RRULE          | 0 or 1   |                                   |
   |     TZNAME         | 0+       |                                   |

It should say:

   |   DAYLIGHT         | 0+       | MUST be one or more of either     |
   |                    |          | STANDARD or DAYLIGHT.             |
   |     COMMENT        | 0+       |                                   |
   |     DTSTART        | 1        | MUST be local time format.        |
   |     RDATE          | 0+       | If present, RRULE MUST NOT be     |
   |                    |          | present                           |
   |     RRULE          | 0 or 1   | If present, RDATE MUST NOT be     |
   |                    |          | present                           |
   |     TZNAME         | 0+       |                                   |

Notes:

The corrected text appeared in RFC 2446, however I couldn't find the reasoning as to why it was omitted in RFC 5546.

The correct comments also appear a few lines below, under "STANDARD".

RFC 5547, "A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer", May 2009

Source of RFC: mmusic (rai)

Errata ID: 3190
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruno CHATRAS
Date Reported: 2012-04-12
Verifier Name: Robert Sparks

Throughout the document, when it says:

Section 9.1., paragraph 7:
OLD:

    --boundary71
    Content-Type: application/sdp
    Content-Length: [length of SDP]

NEW:

    --boundary71
    Content-Type: application/sdp


Section 9.1., paragraph 9:
OLD:

    --boundary71
    Content-Type: image/jpeg
    Content-Transfer-Encoding: binary
    Content-ID: <id2@alicepc.example.com>
    Content-Length: [length of image]
    Content-Disposition: icon

NEW:

    --boundary71
    Content-Type: image/jpeg
    Content-Transfer-Encoding: binary
    Content-ID: <id2@alicepc.example.com>
    Content-Disposition: icon


Section 9.2., paragraph 24:
OLD:

    --boundary71
    Content-Type: application/sdp
    Content-Length: [length of SDP]

NEW:

    --boundary71
    Content-Type: application/sdp


Section 9.2., paragraph 26:
OLD:

    --boundary71
    Content-Type: image/jpeg
    Content-Transfer-Encoding: binary
    Content-ID: <id3@alicepc.example.com>
    Content-Length: [length of image]
    Content-Disposition: icon

NEW:

    --boundary71
    Content-Type: image/jpeg
    Content-Transfer-Encoding: binary
    Content-ID: <id3@alicepc.example.com>
    Content-Disposition: icon

Notes:

A Content-Length header is shown for a body-part within a multipart body. But Content-Length is an HTTP/SIP header, not a IANA-registered MIME header and should therefore not appear at that location in valid examples. The length of a body part within a multipart body is determined by MIME framing. A Content-Length header found for a body-part within a multipart body is meaningless and should be ignored.

This was discussed on both the SIP Implementors and SIP Core mailing lists.

RFC 5552, "SIP Interface to VoiceXML Media Services", May 2009

Source of RFC: mediactrl (rai)

Errata ID: 1994
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Henry Lum
Date Reported: 2010-01-04
Verifier Name: Robert Sparks
Date Verified: 2011-02-07

Section 2.4 says:

session.connection.redirect:  This array is populated by information
      contained in the History-Info [RFC4244] header in the initial
      INVITE or is otherwise undefined.  Each entry (hi-entry) in the
      History-Info header is mapped, in reverse order, into an element
      of the session.connection.redirect array.

It should say:

session.connection.redirect:  This array is populated by information
      contained in the History-Info [RFC4244] header in the initial
      INVITE or is otherwise undefined.  Each entry (hi-entry) in the
      History-Info header is mapped, in order appeared in the History-Info header, into an element of the session.connection.redirect array.

Notes:

The elements in the History info header is designed as a tree-like structure from the origination to the destination where each forwarding proxy appends to the end of the header and add an index. The original RFC text requires that the elements to be shown in VXML session.connection.redirect array in reverse order and this is incorrect based on the definition of session.connection.redirect. The first element in the array should be the original called number which maps to index=1 in history-info, and the last element should be the last redirected number which is the last element in history-info.

--- From reviewer Dale Worley ---

The definition of session.connection.redirect from the VXML 2.0
specification (http://www.w3.org/TR/2004/REC-voicexml20-20040316/) is:

session.connection.redirect
This variable is an array representing the connection redirection
paths. The first element is the original called number, the last
element is the last redirected number. Each element of the array
contains a uri, pi (presentation information), si (screening
information), and reason property. The reason property can be
either "unknown", "user busy", "no reply", "deflection during
alerting", "deflection immediate response", "mobile subscriber not
reachable".

As such, copying the History-Info values into
session.connection.redirect in the same order is somewhat more
correct, as the first History-Info value should be the original
request-URI. But History-Info may contain other values other than the
ones that are ancestral to the INVITE containing it, and assembling
the correct redirection sequence may require some additional
processing. Also, the definition of History-Info is being updated
(draft-ietf-sipcore-rfc4244bis) to provide better recording of
redirection sequences. Documenting how to extract the redirection
sequence in a way that would work in all cases is a significant piece
of work.

Currently, the best straightforward specification is to map the
elements in forward order:

session.connection.redirect: This array is populated by information
contained in the History-Info [RFC4244] header in the initial
INVITE or is otherwise undefined. Each entry (hi-entry) in the
History-Info header is mapped, in order, into an element of the
session.connection.redirect array.

RFC 5555, "Mobile IPv6 Support for Dual Stack Hosts and Routers", June 2009

Note: This RFC has been updated by RFC 8553

Source of RFC: mext (int)

Errata ID: 3463
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Romain Kuntz
Date Reported: 2013-01-17
Verifier Name: Éric Vyncke
Date Verified: 2024-01-12

Throughout the document, when it says:

with error code 144

Notes:

Binding acknowledgement error status 144 is referenced in sections 4.4.2 and 4.5 to specify that MN should not use UDP encapsulation. However, there is no mention of this status number in the IANA Considerations section (section 8).

-- Verifier note (EV) ---

The MIPv6 Status code 144 does not appear in https://www.iana.org/assignments/mobility-parameters/mobility-parameters.xhtml#mobility-parameters-6

Even worse, it is actually assigned to MIPV6-ID-MISMATCH by a previous RFC 4285 (and the semantics of MIPV6-ID-MISMATCH probably does not match RFC 5555 semantics).

RFC 5559, "Pre-Congestion Notification (PCN) Architecture", June 2009

Source of RFC: pcn (tsv)

Errata ID: 3164
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bob Briscoe
Date Reported: 2012-03-23
Verifier Name: Wes Eddy
Date Verified: 2012-04-27

Section 4.2 says:

   o  Police - police, by dropping any packets received with a DSCP
      indicating PCN transport that do not belong to an admitted flow.
      (A prospective PCN-flow that is rejected could be blocked or
      admitted into a lower-priority behaviour aggregate.)

It should say:

   o  Police - drop or re-mark to a lower-priority behaviour aggregate
      i) packets received with a DSCP indicating PCN transport that do not
      belong to an admitted flow and ii) packets that are part of a flow
      that asked to be admitted as a PCN-flow but was rejected.

Notes:

In the original text the first sentence contradicts the parenthesis. It could be interpreted to mean that dropping is the only allowed policing action, whereas the parenthesis shows that downgrading was also considered appropriate.

Also the original text used the term 'blocking' as a different action to 'downgrading', whereas Section 3.6 just above this text has said '"Blocking" means it is dropped or downgraded to a lower-priority behaviour aggregate,...'

Errata ID: 3565
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Welzl
Date Reported: 2013-03-26
Verifier Name: Martin Stiemerling
Date Verified: 2013-04-10

Section 10.2 says:

   [Moncaster09-1]  Moncaster, T., Briscoe, B., and M. Menth, "Baseline
                    Encoding and Transport of Pre-Congestion
                    Information", Work in Progress, May 2009.

It should say:

   [Moncaster09-1]  Moncaster, T., Briscoe, B., and M. Menth, "Baseline
                    Encoding and Transport of Pre-Congestion
                    Information", RFC 5696, November 2009.

RFC 5568, "Mobile IPv6 Fast Handovers", July 2009

Note: This RFC has been updated by RFC 7411

Source of RFC: mipshop (int)

Errata ID: 1816
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Rajeev Koodli
Date Reported: 2009-07-23
Verifier Name: Brian Haberman
Date Verified: 2012-06-06

Section 6.4.2 says:

Type: 17

It should say:

Type: 34 

Notes:

The Type value for the Mobility Header IPv6 Address/Prefix option should have been updated to 34 upon IANA assignment.

Errata ID: 1943
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Rajeev Koodli
Date Reported: 2009-11-19
Verifier Name: Brian Haberman
Date Verified: 2012-06-06

Section 6.2.1.2 says:

   Upon receiving an HI message, the NAR MUST respond with a Handover
   Acknowledge message.  If the 'S' flag is set in the HI message, the
   NAR SHOULD include the New Care-of Address option and a Code 3.

It should say:

   Upon receiving an HI message, the NAR MUST respond with a Handover
   Acknowledge message.  If the 'S' flag is set in the HI message, the
   NAR SHOULD include the New Care-of Address option and a Code 2.

Notes:

Code 2 is used in assigned addressing. Some Codes were cleaned up in 5068/5568, but this was not reflected in above text

Errata ID: 1944
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rajeev Koodli
Date Reported: 2009-11-19
Verifier Name: Brian Haberman
Date Verified: 2012-04-26

Section 6.4.6 says:

2: NCoA is invalid, use the supplied NCoA.  The supplied NCoA
(in the form of an IP Address Option) MUST be present following
the Reserved field.

It should say:

2: NCoA is invalid, use the supplied NCoA. The supplied NCoA 
(an IPv6 Address of 16 octets) MUST be present following the 
Reserved field.

Notes:

Clarifies that an IPv6 address is included (and not IPv6 address/prefix option)

RFC 5569, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", January 2010

Source of RFC: INDEPENDENT

Errata ID: 2022
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-01-26
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-16

Section 1 says:

[[ second-to-last paragraph, on mid-page 3 ]]

   While IPv6 availability was limited in December 2007 to only one IPv6
   link per customer site (with /64 site-prefix assignments).  A few
   months later, [...]

It should say:

|  IPv6 availability was limited in December 2007 to only one IPv6 link
   per customer site (with /64 site-prefix assignments).  A few months
   later, [...]

Notes:

Rationale: Incomplete sentence; strike "While" to fix.

Errata ID: 2023
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-01-26
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-16

Section 3 says:

[[  In the NOTE on top of page 6 ]]

                                  [...], and as soon as Free would get a
   prefix shorter than /32, this restriction would be relaxed.  [...]

It should say:

                                 [...], and as soon as Free got a prefix
   shorter than /32, it was possible to relax this restriction. [...]

Notes:

Rationale: Wrong temporal relationship, not matching text in Section 1.

Errata ID: 6511
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lars Eggert
Date Reported: 2021-04-02
Verifier Name: RFC Editor
Date Verified: 2021-04-02

In the Copyright Notice, it says:

(http:trustee.ietf.org/license-info)

It should say:

(http://trustee.ietf.org/license-info)

RFC 5570, "Common Architecture Label IPv6 Security Option (CALIPSO)", July 2009

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 1811
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: R. Atkinson
Date Reported: 2009-07-17
Verifier Name: Sean Turner
Date Verified: 2010-04-19

Section 5.1.8 says:

This contains a variable number of 64-bit words.

It should say:

This contains a variable number of 32-bit words.

Notes:

Sections 5.1.3 and 5.2 closely relate to the text in Section 5.1.8. Those 2 other sections provide further explanation why the text in Section 5.1.8 should refer to "32-bit words" rather than "64-bit words".

RFC 5572, "IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)", February 2010

Source of RFC: INDEPENDENT

Errata ID: 2540
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Fernando Gont
Date Reported: 2010-10-02
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-16

Section 4.4.1.2 says:

This marker is used by the
tunnel broker to identify a TSP signaling packet that is sent
after an IPv6 over UDP is established.

It should say:

This marker is used by the 
tunnel broker to identify a TSP signaling packet that is sent 
after an IPv6 over UDP tunnel is established.

RFC 5575, "Dissemination of Flow Specification Rules", August 2009

Note: This RFC has been obsoleted by RFC 8955

Note: This RFC has been updated by RFC 7674

Source of RFC: idr (rtg)

Errata ID: 5043
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jan Matejka
Date Reported: 2017-06-20
Verifier Name: Alvaro Retana
Date Verified: 2017-11-06

Section 7 says:

        +--------+--------------------+--------------------------+
        | type   | extended community | encoding                 |
        +--------+--------------------+--------------------------+
        | 0x8006 | traffic-rate       | 2-byte as#, 4-byte float |
        | 0x8007 | traffic-action     | bitmask                  |
        | 0x8008 | redirect           | 6-byte Route Target      |
        | 0x8009 | traffic-marking    | DSCP value               |
        +--------+--------------------+--------------------------+

   Traffic-rate:  The traffic-rate extended community is a non-
      transitive extended community across the autonomous-system
      boundary and uses following extended community encoding:

It should say:

        +--------+--------------------+--------------------------+
        | type   | extended community | encoding                 |
        +--------+--------------------+--------------------------+
        | 0x8006 | traffic-rate       | 2-byte as#, 4-byte float |
        | 0x8007 | traffic-action     | bitmask                  |
        | 0x8008 | redirect           | 6-byte Route Target      |
        | 0x8009 | traffic-marking    | DSCP value               |
        +--------+--------------------+--------------------------+

   Traffic-rate:  The traffic-rate extended community
      uses following extended community encoding:

Notes:

The traffic rate type is allocated in the Transitive Experimental Range (https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml#bgp-extended-communities-10) but the text declares it non-transitive.

=====
[Alvaro Retana]

I am marking this report as Verified knowing that the issue is already being addressed in rfc5575bis.

RFC 5578, "PPP over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics", February 2010

Source of RFC: INDEPENDENT

Errata ID: 6512
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lars Eggert
Date Reported: 2021-04-02
Verifier Name: RFC Editor
Date Verified: 2021-04-02

In the Copyright Notice, it says:

(http:trustee.ietf.org/license-info)

It should say:

(http://trustee.ietf.org/license-info)

RFC 5586, "MPLS Generic Associated Channel", June 2009

Note: This RFC has been updated by RFC 6423, RFC 7026, RFC 7214, RFC 7274

Source of RFC: mpls (rtg)

Errata ID: 1940
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Matthew Bocci
Date Reported: 2009-11-03
Verifier Name: Adrian Farrel
Date Verified: 2009-12-02

Section 10 says:

In order to support this
requirement, IANA has changed the code point allocation scheme for
the PW Associated Channel Type be changed as follows:

   0 - 32751 : IETF Review
   32760 - 32767 : Experimental

It should say:

In order to support this
requirement, IANA has changed the code point allocation scheme for
the PW Associated Channel Type be changed as follows:

   0 - 32759 : IETF Review
   32760 - 32767 : Experimental
   32768 - 65535 : IETF Review

Notes:

There are some gaps in the specified allocation policy for some parts of the ACH channel type range (32752 to 32759 and 32768 to 65535). The channel type is a 16-bit value, and the IANA considerations section of RFC5586 should be updated to reflect this.

The correction should be to clarify that the allocation policy for the code points that have been left out of RFC5586 is IETF review (which reflects the WG consensus at the time of publication), and to leave the Experimental range where it is to avoid impacting current implementations.

This also requires an update by IANA to the PW ACH Channel Type registry.

RFC 5589, "Session Initiation Protocol (SIP) Call Control - Transfer", June 2009

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rai

Errata ID: 3989
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Procter
Date Reported: 2014-05-15
Verifier Name: Francesca Palombini
Date Verified: 2023-11-09

Section 7.3 says:

Target-Dialog: 592435881734450904;local-tag=9m2n3wq
 ;remote-tag=763231

It should say:

Target-Dialog: 090459243588173445;local-tag=7553452
 ;remote-tag=31431

Notes:

The ladder diagram states that F5 (REFER) should have Target-Dialog referencing dialog 1 and the embedded Replaces header should reference dialog 2. The complete F5 message references dialog 2 in both places, which is incorrect.

RFC 5595, "The Datagram Congestion Control Protocol (DCCP) Service Codes", September 2009

Note: This RFC has been updated by RFC 6335

Source of RFC: dccp (tsv)

Errata ID: 3815
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Gorry Fairhurst
Date Reported: 2013-11-29
Verifier Name: Martin Stiemerling
Date Verified: 2015-12-16

Section 2.2 says:

All standards assigned Service Codes, including
all values assigned by IANA, are required to use a value that may be
represented using a subset of the ASCII character set.

It should say:

Requests for a Service Code in the IANA Considerations section of a
Standards-Track specification are to be assigned from the
Specifications-Required portion of the Service Code registry.
These assignments are required to use a value that may be
represented using a subset of the ASCII character set (see section 5).

Notes:

RFC 5595 did not clearly specify the intended update to RFC 4340. An update is also required to section 10.3.1 to be consistent.

Errata ID: 3816
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Gorry Fairhurst
Date Reported: 2013-11-29
Verifier Name: Martin Stiemerling
Date Verified: 2015-12-16

Section 5 says:

This document does not update the IANA allocation procedures for the
DCCP Port Number and DCCP Service Codes Registries as defined in RFC
4340.

It should say:

This document does not update the IANA allocation procedures for the
DCCP Port Number Registry as defined in RFC 4340. Section 2.2 of
this document updated the IANA allocation procedures for the DCCP
Service Codes Registry by requiring Service Code assignments
by a Standards-Track specification to be assigned from the
Specifications-Required portion of the Service Code registry.

Notes:

RFC 5595 did not clearly specify the intended update to RFC 4340. An update is also
required to section 10.3.1 to be consistent in RFC 6335.

RFC 5598, "Internet Mail Architecture", July 2009

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 3260
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Murray Kucherawy
Date Reported: 2012-06-15
Verifier Name: Barry Leiba
Date Verified: 2012-06-15

Section 4.3.1 says:

4.3.1. Mail Submission Agent (MSA)


   A Mail Submission Agent (MSA) accepts the message submitted by the
   aMUA and enforces the policies of the hosting ADMD and the
   requirements of Internet standards.

It should say:

4.3.1. Message Submission Agent (MSA)


   A Message Submission Agent (MSA) accepts the message submitted by the
   aMUA and enforces the policies of the hosting ADMD and the
   requirements of Internet standards.

Notes:

The document tends to use "Message" rather than "Mail". However, in the case of the MSA, it uses "Mail" more than "Message".

The document probably needs a pass to ensure consistent use of both terms throughout.

RFC 5601, "Pseudowire (PW) Management Information Base (MIB)", July 2009

Source of RFC: pwe3 (int)

Errata ID: 4069
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexander ("Sasha") Vainshtein
Date Reported: 2014-08-05
Verifier Name: Brian Haberman
Date Verified: 2014-08-06

Section 12 says:

 pwAttachedPwIndex OBJECT-TYPE
     SYNTAX        PwIndexOrZeroType
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
         "If the PW is attached to another PW instead of a local
          native service, this item indicates the pwIndex of the
          attached PW.  Otherwise, this object MUST
          be set to zero.  Attachment to another PW will have no
          PW specific entry in any of the service MIB modules."
     DEFVAL { 0 }
     ::= { pwEntry 10 }

It should say:

 pwAttachedPwIndex OBJECT-TYPE
     SYNTAX        PwIndexOrZeroType
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
          "If the PW is attached to another PW instead of a local
           native service, this item indicates the pwIndex of the
           attached PW.  Otherwise, this object MUST
           be set to zero.  Attachment to another PW will have no
           PW specific entry in any of the service MIB modules.
           This object may be modified only when the value of
           the associated pwAdminStatus object is down(2), and
           the associated pwOperStatus object has value down(2)
           or notPresent(5) such that the row in the pwTable
           represents an inactive PW."
     DEFVAL { 0 }
     ::= { pwEntry 10 }

Notes:

Description of the pwEntry object in the same RFC states that "The read-create objects in this table are divided into
three categories:
1) Objects that MUST NOT be changed after row activation.
These are objects that define basic properties of the
PW (for example type, destination, etc.).
2) Objects that MAY be changed when the PW is
defined as not active. A change of these objects involves
re-signaling of the PW or it might be traffic affecting.
PW not active is defined as one of the following
conditions:
a) The pwRowStatus is notInService(2).
b) The pwRowStatus is notReady(3).
c) The pwAdminStatus is down(2).
If the operator needs to change one of the values for an
active row, the operator can either set the pwRowStatus to
notInService(2) or set pwAdminStatus to down(2).
Signaling (or traffic) is initiated again upon setting
the pwRowStatus to active(1) or setting the pwAdminStatus
to up(1) or testing(3), respectively.
3) Objects that MAY be changed at any time."

In further states (in tthe same description) that "By default, all the read-create objects MUST NOT be changed after row activation, unless specifically indicated in the individual object description."

pwAttachedPwIndex object is used to stitch a couple of PWs represented by two different rows in the pwTable, with the pwAttachedPwIndex value in the row representing one of them set to the pwIndex of the other one and vice versa.
Since there is no way in the SMIv2 paradigm to create two rows in the same table
in a single atomic operation, setting a this attribute in a pair of rows is only
possible when both are created. In order to do that, read-create access mode of
the pwAttachedPwIndex object has to be interpreted as ability to set its value
when the row represents an inactive PW.
In accordance with the quoted description, such an interpretation must be
explicitly specified in the description of this object.

Such a specification is missing in the current text, hence the default
interpretation of the read-create access mode is holds.
Proposed text fixes this problem.

Errata ID: 1859
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-09
Verifier Name: Stewart Bryant
Date Verified: 2011-11-12

Section 12, pg.25 says:

[[ DESCRIPTION clause for pwFcsRetentionCfg OBJECT-TYPE ]]

         "The local configuration of Frame Check Sequence (FCS)
          retention for this PW.  FCS retention can be configured for
          PW types High-Level Data Link Control (HDLC), Point-to-Point
          Protocol (PPP), and Ethernet only.  If the implementation
|         does not support FCS retention, an error MUST be reported in
          pwFcsRetentionStatus.  This object MAY be changed only if
          the PW is not active."

It should say:

         "The local configuration of Frame Check Sequence (FCS)
          retention for this PW.  FCS retention can be configured for
          PW types High-Level Data Link Control (HDLC), Point-to-Point
          Protocol (PPP), and Ethernet only.  If this object is set to
          fcsRetentionEnable(2) and the implementation does not support
          the FCS retention for this PW, an error MUST be indicated by
          setting pwFcsRetentionStatus to localFcsRetentionCfgErr(4).
          This object can be changed only if the PW is not active." 

Notes:

Rationale:

The original DESCRIPTION indicated unconditional signaling of an error, whether
the activation of unsupported FCS retention is requested or not.
This is contrary to the DESCRIPTION for pwFcsRetentionStatus.

Errata ID: 3030
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stewart Bryant
Date Reported: 2011-11-12
Verifier Name: Stewart Bryant
Date Verified: 2011-11-12

Section 12, page 37 says:

pwPerf1DayIntervalTable  OBJECT-TYPE
     SYNTAX        SEQUENCE OF PwPerf1DayIntervalEntry
     MAX-ACCESS    not-accessible
     STATUS        current
     DESCRIPTION
          "This table provides per-PW performance information for
           the current day's measurement and the previous day's
           interval."

It should say:

DESCRIPTION
          "This table provides per-PW performance information for
           the current day's measurement and the previous day's
           measurement."

Errata ID: 1861
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-09
Verifier Name: Stewart Bryant
Date Verified: 2011-11-12

Section 12, pg.34 says:

  pwPerfIntervalEntry OBJECT-TYPE
     SYNTAX        PwPerfIntervalEntry
     MAX-ACCESS    not-accessible
     STATUS        current
     DESCRIPTION
          "An entry in this table is created by the agent for every
|          PW."

It should say:

  pwPerfIntervalEntry OBJECT-TYPE
     SYNTAX        PwPerfIntervalEntry
     MAX-ACCESS    not-accessible
     STATUS        current
     DESCRIPTION
          "An entry in this table is created by the agent for every
           monitored interval for each monitored PW."

Errata ID: 1862
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-09
Verifier Name: Stewart Bryant
Date Verified: 2011-11-12

Section 12, pg.38 says:

  pwPerf1DayIntervalEntry OBJECT-TYPE
     SYNTAX        PwPerf1DayIntervalEntry
     MAX-ACCESS    not-accessible
     STATUS        current
     DESCRIPTION
          "An entry in this table is created by the agent for every
|          PW."

It should say:

  pwPerf1DayIntervalEntry OBJECT-TYPE
     SYNTAX        PwPerf1DayIntervalEntry
     MAX-ACCESS    not-accessible
     STATUS        current
     DESCRIPTION
          "An entry in this table is created by the agent for every
           monitored day for each monitored PW."

Errata ID: 2815
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Daniel Cohn
Date Reported: 2011-05-24
Verifier Name: Stewart Bryant
Date Verified: 2011-11-12

Section Daniel says:

  pwOperStatus OBJECT-TYPE
     SYNTAX        PwOperStatusTC
     MAX-ACCESS    read-only
     STATUS        current
     DESCRIPTION
          "This object indicates the operational status of the PW; it
           does not reflect the status of the Customer Edge (CE) bound
           interface.  It is set to down only if pwNotForwarding,
           psnFacingPwRxFault, or psnFacingPwTxFault indications are
           set in pwLocalStatus or pwRemoteStatus.
           It indicates 'lowerLayerDown' if the only reason for
           not being in the 'up' state is that either the outer tunnel
           or physical layer of the network side is in the 'down'
           state.
           All other states are declared based on the description
           of the PwOperStatusTC.
           "
     ::= { pwEntry 38 }

It should say:

  pwOperStatus OBJECT-TYPE
     SYNTAX        PwOperStatusTC
     MAX-ACCESS    read-only
     STATUS        current
     DESCRIPTION
          "This object indicates the operational status of the PW; it
           does not reflect the status of the Customer Edge (CE) bound
           interface.  It is set to down only if pwNotForwarding,
           psnPwRxFault, or psnPwTxFault indications are
           set in pwLocalStatus or pwRemoteStatus.
           It indicates 'lowerLayerDown' if the only reason for
           not being in the 'up' state is that either the outer tunnel
           or physical layer of the network side is in the 'down'
           state.
           All other states are declared based on the description
           of the PwOperStatusTC.
           "
     ::= { pwEntry 38 }

Notes:

psnFacingPwRxFault and psnFacingPwTxFault were replaced in RFC 5542 by psnPwRxFault and psnPwTxFault respectively

RFC 5608, "Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models", August 2009

Source of RFC: isms (sec)

Errata ID: 2100
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Martin Björklund
Date Reported: 2010-03-31
Verifier Name: Sean Turner
Date Verified: 2010-05-03

Section 2.3 says:

Inactivity-Timeout

It should say:

Idle-Timeout

Notes:

This change should be made to both occurrences in Section 2.3. The list of attributes in section 3 correctly lists the Idle-Timeout attribute.

RFC 5610, "Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements", July 2009

Source of RFC: ipfix (ops)

Errata ID: 1822
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Brian Trammell
Date Reported: 2009-08-04
Verifier Name: Dan Romascanu
Date Verified: 2009-08-06

Section 3.7 says:

These types are registered in the IANA IPFIX Information Element
Units subregistry; new types may be added on a First Come First 
Served [RFC5226] basis.

It should say:

These units are registered in the IANA IPFIX Information Element 
Units subregistry; new units may be added on an Expert Review 
[RFC5226] basis.

Notes:

The text in the IANA Considerations (section 5) and in the IANA registry created therefrom (http://www.iana.org/assignments/ipfix/ipfix.xhtml#informationElementUnits) specifies Expert Review, which was the intent of the WG. The text in section 3.7 is an editorial hold-over from an older version of the document.

Errata ID: 4731
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Logarajan
Date Reported: 2016-07-06
Verifier Name: Benoit Claise
Date Verified: 2016-07-06

Section Appendix A says:

                     1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Set ID = 3           |          Length =  26         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Template ID = 257        |        Field Count = 4        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Scope Field Count = 2      |0| priv.EnterpriseNumber   346 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Field Length = 4        |0| informationElementId    303 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Field Length = 2        |0| inf.El.DataType         339 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Field Length = 1        |0| inf.El.Semantics        344 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Field Length = 1        |0| inf.El.Name             341 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Field Length = 65536      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

                     1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Set ID = 3           |          Length =  30         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Template ID = 257        |        Field Count = 5        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Scope Field Count = 2      |0| priv.EnterpriseNumber   346 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Field Length = 4        |0| informationElementId    303 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Field Length = 2        |0| inf.El.DataType         339 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Field Length = 1        |0| inf.El.Semantics        344 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Field Length = 1        |0| inf.El.Name             341 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Field Length = 65536      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

Length should be 30 and Field Count should be 5.

RFC 5616, "Streaming Internet Messaging Attachments", August 2009

Source of RFC: lemonade (app)

Errata ID: 2077
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-03-17
Verifier Name: Alexey Melnikov
Date Verified: 2010-03-23

Section 7 (pg. 27) says:

 |           ..., and between the client the media server.
                                        ^

It should say:

|            ..., and between the client and the media server.
                                        ^^^^^

RFC 5627, "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", October 2009

Source of RFC: sip (rai)

Errata ID: 3173
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nataraju A B
Date Reported: 2012-04-02
Verifier Name: Robert Sparks
Date Verified: 2012-11-04

Section 4.4 says:

   o  a 2xx response to NOTIFY
   o  the UPDATE request
   o  a 2xx response to NOTIFY

It should say:

   o  a 2xx response to NOTIFY
   o  the UPDATE request
   o  a 2xx response to **UPDATE**

Notes:

This section 4.4 describes different messages which can update the remote target within a dialog.

RFC 5628, "Registration Event Package Extension for Session Initiation Protocol (SIP) Globally Routable User Agent URIs (GRUUs)", October 2009

Source of RFC: sipping (rai)

Errata ID: 2995
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Paul Kyzivat
Date Reported: 2011-10-13
Verifier Name: Robert Sparks
Date Verified: 2011-11-04

Section 5 says:

   If the notifier includes the <temp-gruu> element, it MUST populate
   the element with the most recently assigned temporary GRUU that is
   associated with the instance ID and AOR of the registered contact.
   It MUST also populate the element with a "cseq" attribute
   corresponding to the first (oldest) currently active temporary GRUU
   that is associated with the instance ID and AOR of the registered
   contact.  The value of the "cseq" attribute is set to the value of
   the CSeq header field of the REGISTER request that caused that first
   temporary GRUU to be assigned.

It should say:

   If the notifier includes the <temp-gruu> element, it MUST populate
   the element with the most recently assigned temporary GRUU that is
   associated with the instance ID and AOR of the registered contact.
   It MUST also populate the element with a "first-cseq" attribute
   corresponding to the first (oldest) currently active temporary GRUU
   that is associated with the instance ID and AOR of the registered
   contact.  The value of the "first-cseq" attribute is set to the value of
   the CSeq header field of the REGISTER request that caused that first
   temporary GRUU to be assigned.

Notes:

This replaces '"cseq" attribute' with '"first-cseq" attribute.
This is almost a typo, since there is no "cseq" attribute of <temp-gruu>.
Following the text as written would yield an invalid xml document.

This was reported to me by Ivo Sedlacek:
http://www.ietf.org/mail-archive/web/sipcore/current/msg04282.html

RFC 5639, "Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation", March 2010

Source of RFC: INDEPENDENT

Errata ID: 2082
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-03-21
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-16

Section A.2, pg. 25 says:

|  1.  Set h = find_integer_2(s).
|
|  2.  Convert h to an integer A.

   3.  If -3 = A*Z^4 mod p is not solvable, then set s = update_seed(s)
       and go to Step 1.

   4.  Compute one solution Z of -3 = A*Z^4 mod p.

   5.  Set s = update_seed(s).

   6.  Set B = find_integer_2(s).

   7.  If B is a square mod p, then set s = update_seed(s) and go to
       Step 6.

   8.  If 4*A^3 + 27*B^2 = 0 mod p, then set s = update_seed(s) and go
       to Step 1.

   9.  Check that the elliptic curve E over GF(p) given by y^2 = x^3 +
       A*x + B fulfills all security and functional requirements given
       in Section 3.  If not, then set s = update_seed(s) and go to Step
       1.

   10. Set s = update_seed(s).

   11. Set k = find_integer_2(s).

   12. Determine the points Q and -Q having the smallest x-coordinate in
       E(GF(p)).  Randomly select one of them as point P.

It should say:

|  1.  Set A = find_integer_2(s).
|
   2.  If -3 = A*Z^4 mod p is not solvable, then set s = update_seed(s)
       and go to Step 1.

   3.  Compute one solution Z of -3 = A*Z^4 mod p.

   4.  Set s = update_seed(s).

   5.  Set B = find_integer_2(s).

   6.  If B is a square mod p, then set s = update_seed(s) and go to
       Step 5.

   7.  If 4*A^3 + 27*B^2 = 0 mod p, then set s = update_seed(s) and go
       to Step 1.

   8.  Check that the elliptic curve E over GF(p) given by y^2 = x^3 +
       A*x + B fulfills all security and functional requirements given
       in Section 3.  If not, then set s = update_seed(s) and go to Step
       1.

   9.  Set s = update_seed(s).

   10. Set k = find_integer_2(s).

   11. Determine the points Q and -Q having the smallest x-coordinate in
       E(GF(p)).  Randomly select one of them as point P.

Notes:

Rationale:
According to the first part of A.2, the routine find_integer_2()
returns an integer value (see also original step 6.).
Thus, step 2 should be deleted, and 'h' is not needed.
Note that merely renumbered steps are not taagged with
a change bar above.

Updated 2013-06-06. Thanks to Edward Huff for the correction.

Errata ID: 2071
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Johannes Merkle
Date Reported: 2010-03-10
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-20

Section A.1 says:

      p_320 = 1763593322239166354161909842446019520889512772719515192772
      9604152886408688021498180955014999035278

It should say:

      p_320 = 1763593322239166354161909842446019520889512772719515192772
      960415288640868802149818095501499903527

Errata ID: 2083
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-03-21
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-16

Section 1.1,1st para says:

   This RFC specifies elliptic curve domain parameters over prime fields
   GF(p) with p having a length of 160, 192, 224, 256, 320, 384, and 512
   bits.  These parameters were generated in a pseudo-random, yet
   completely systematic and reproducible, way and have been verified to
   resist current cryptanalytic approaches.  The parameters are
   compliant with ANSI X9.62 [ANSI1] and ANSI X9.63 [ANSI2], ISO/IEC
   14888 [ISO1] and ISO/IEC 15946 [ISO2], ETSI TS 102 176-1 [ETSI], as
|  well as with FIPS-186-2 [FIPS], and the Efficient Cryptography Group
   (SECG) specifications ([SEC1] and [SEC2]).

It should say:

   This RFC specifies elliptic curve domain parameters over prime fields
   GF(p) with p having a length of 160, 192, 224, 256, 320, 384, and 512
   bits.  These parameters were generated in a pseudo-random, yet
   completely systematic and reproducible, way and have been verified to
   resist current cryptanalytic approaches.  The parameters are
   compliant with ANSI X9.62 [ANSI1] and ANSI X9.63 [ANSI2], ISO/IEC
   14888 [ISO1] and ISO/IEC 15946 [ISO2], ETSI TS 102 176-1 [ETSI], as
|  well as with FIPS-186-2 [FIPS], and the Standards for Efficient
   Cryptography Group (SECG) specifications ([SEC1] and [SEC2]).

Notes:

Rationale: incomplete expansion of acronym.

Additional note:
In Section 7.2, two of the references quoted here should perhaps
better point to the current versions of the documents:

[SEC1] "SEC1: Elliptic Curve Cryptography",
Version 2.0, May 2009.

[FIPS] NIST, "Digital Signature Standard (DSS)",
FIPS PUB 186-3, November 2008.

Errata ID: 2084
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-03-21
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-16

Section 2.,1st para says:

   Throughout this memo, let p > 3 be a prime and GF(p) a finite field
|  (sometimes also referred to as Galois Field or GF(p)) with p
   elements.  [...]

It should say:

   Throughout this memo, let p > 3 be a prime and GF(p) a finite field
|  (sometimes also referred to as Galois Field or F_p) with p elements.
   [...]

or perhaps more precisely:

   Throughout this memo, let p > 3 be a prime and GF(p) a finite field
|  (Galois Field) with p elements (sometimes also referred to as F_p). 
   [...]

Notes:

Rationale:
... GF(p) ... sometimes also referred to as ... GF(p) ...
does no make sense.
The original version from the draft did make sense -- mentioning
_another_ common notion, "F_p".

Errata ID: 4701
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mirko Dressler
Date Reported: 2016-05-25
Verifier Name: Nevil Brownlee
Date Verified: 2016-06-08

Section A.2 says:

    Seed_ab_384 for brainpoolP384r1:
    BCFBFA1C877C56284DAB79CD4C2B3293D20E9E5E

|   Seed_ab_512 for brainpoolP384r1:
    AF02AC60ACC93ED874422A52ECB238FEEE5AB6AD

It should say:

    Seed_ab_384 for brainpoolP384r1:
    BCFBFA1C877C56284DAB79CD4C2B3293D20E9E5E

|   Seed_ab_512 for brainpoolP512r1:
    AF02AC60ACC93ED874422A52ECB238FEEE5AB6AD

Notes:

Copy/Paste-Error, change noted as correct by Manfred Lochter

Errata ID: 5075
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Taylor R Campbell
Date Reported: 2017-08-01
Verifier Name: RFC Editor
Date Verified: 2017-08-01

Section 2.2 and 7.2 says:

2.2.  Technical Requirements
       [...]
                                            This property permits the
       use of the arithmetical advantages of curves with A = -3, as
       shown by Brier and Joyce [BJ].

7.2.  Informative References
       [...]
   [BJ]       Brier, E. and M. Joyce, "Fast Multiplication on Elliptic
              Curves through Isogenies", Applied Algebra Algebraic
              Algorithms and Error-Correcting Codes, Lecture Notes in
              Computer Science 2643, Springer Verlag, 2003.

It should say:

2.2.  Technical Requirements
       [...]
                                            This property permits the
       use of the arithmetical advantages of curves with A = -3, as
       shown by Brier and Joye [BJ].

7.2.  Informative References
       [...]
   [BJ]       Brier, E. and M. Joye, "Fast Multiplication on Elliptic
              Curves through Isogenies", Applied Algebra Algebraic
              Algorithms and Error-Correcting Codes, Lecture Notes in
              Computer Science 2643, Springer Verlag, 2003.

Notes:

The author's name is Marc Joye, not Marc Joyce. See the original paper here: https://link.springer.com/chapter/10.1007/3-540-44828-4_6

RFC 5643, "Management Information Base for OSPFv3", August 2009

Source of RFC: ospf (rtg)

Errata ID: 2789
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vladica Stanisic
Date Reported: 2011-04-25
Verifier Name: Stewart Bryant
Date Verified: 2011-08-12

Section 5 says:

ospfv3VirtNbrEvents OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times this virtual link has
changed its state or an error has occurred.
Discontinuities in the value of this counter
can occur at re-initialization of the management
system and at other times as indicated by the
value of ospfv3DiscontinuityTime."
::= { ospfv3VirtNbrEntry 9 }

It should say:

ospfv3VirtNbrEvents OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times this virtual neighbor has
changed its state or an error has occurred.
Discontinuities in the value of this counter
can occur at re-initialization of the management
system and at other times as indicated by the
value of ospfv3DiscontinuityTime."
::= { ospfv3VirtNbrEntry 9 }

RFC 5649, "Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm", September 2009

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 6943
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Samuel Lee
Date Reported: 2022-04-25
Verifier Name: Roman Danyliw
Date Verified: 2022-04-25

Throughout the document, when it says:

plaintext length may be in range [1, 2^32]

It should say:

plaintext length may be in range [1, 2^32), or [1, 2^32-1]

Notes:

The text is ambiguous about how to handle a plaintext of size 2^32 bytes. The text seems to suggest a plaintext of size 2^32 is permitted, but the description of generation/verification of the AIV does not handle this case.
As written different implementations could disagree on what constitutes a valid ciphertext.

I would suggest the simplest solution is to explicitly say the maximum plaintext length is 2^32-1 (which is still much larger than any intended use case, as this should be for encrypting keying material).

RFC 5651, "Layered Coding Transport (LCT) Building Block", October 2009

Source of RFC: rmt (tsv)

Errata ID: 3843
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Eric Turcotte
Date Reported: 2013-12-16
Verifier Name: Martin Stiemerling
Date Verified: 2015-12-16

Section 5.2.1 says:

There are two formats for Header Extension fields, as depicted in
Figure 2. The first format is used for variable-length extensions,
with Header Extension Type (HET) values between 0 and 127. The
second format is used for fixed-length (one 32-bit word) extensions,
using HET values from 127 to 255.

It should say:

There are two formats for Header Extension fields, as depicted in
Figure 2. The first format is used for variable-length extensions,
with Header Extension Type (HET) values between 0 and 127. The
second format is used for fixed-length (one 32-bit word) extensions,
using HET values from 128 to 255.

Notes:

the correct range for one 32-bit word extension HET values starts from 128, and not from 127.

RFC 5652, "Cryptographic Message Syntax (CMS)", September 2009

Note: This RFC has been updated by RFC 8933

Source of RFC: smime (sec)

Errata ID: 6250
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2020-08-06
Verifier Name: Benjamin Kaduk
Date Verified: 2020-08-07

Section 9.2 says:

   If the authAttrs field is present, the content-type attribute (as
   described in Section 11.1) and the message-digest attribute (as
   described in Section 11.2) MUST be included, and the input to the MAC
   calculation process is the DER encoding of authAttrs.  A separate
   encoding of the authAttrs field is performed for message digest
   calculation.  The IMPLICIT [2] tag in the authAttrs field is not used
   for the DER encoding, rather an EXPLICIT SET OF tag is used.  That
   is, the DER encoding of the SET OF tag, rather than of the IMPLICIT
   [2] tag, is to be included in the message digest calculation along
   with the length and content octets of the authAttrs value.

It should say:

   If the authAttrs field is present, the content-type attribute (as
   described in Section 11.1) and the message-digest attribute (as
   described in Section 11.2) MUST be included, and the input to the MAC
   calculation process is the DER encoding of authAttrs.  A separate
   encoding of the authAttrs field is performed for message digest
   calculation.  The IMPLICIT [2] tag in the authAttrs field is not used
   for the DER encoding, rather an EXPLICIT SET OF tag is used.  That
   is, the DER encoding of the SET OF tag, rather than of the IMPLICIT
   [2] tag, is to be included in the MAC calculation along
   with the length and content octets of the authAttrs value.

Notes:

The paragraph is talking about the input to a MAC calculation, not the input to message digest calculation.

Errata ID: 6546
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Daniel Kahn Gillmor
Date Reported: 2021-04-15
Verifier Name: Benjamin Kaduk
Date Verified: 2021-04-15

Section 12.1 says:

  -- Imports from Appendix B of this document
           AttributeCertificateV1
              FROM AttributeCertificateVersion1

It should say:

  -- Imports from Section 12.2 of this document
           AttributeCertificateV1
              FROM AttributeCertificateVersion1

Notes:

The AttributeCertificateVersion1 is defined in section 12.2; there is no Appendix B in this document.

RFC 5655, "Specification of the IP Flow Information Export (IPFIX) File Format", October 2009

Source of RFC: ipfix (ops)

Errata ID: 3559
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2013-03-20
Verifier Name: Benoit Claise
Date Verified: 2013-03-24

Section 8.2.1 says:

(none)

It should say:

Units:   milliseconds

Notes:

collectionTimeMilliseconds requires units of milliseconds.

Compare with sections 8.2.7 and 8.2.14 in the same document.

IANA's IPFIX IE registry requires the corresponding update.

Errata ID: 3560
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2013-03-20
Verifier Name: Benoit Claise
Date Verified: 2013-07-26

Section 8.2.11 + .18 says:

(none)

It should say:

Range: The valid range is 0-0.

Notes:

8.2.11 messageScope requires a value of 0 ("The value of this Information Element MUST be written as 0") but no range is given. The range should say "0-0". (Compare with text in RFC 5102).

Similarly for 8.2.18 sessionScope.

Note to IANA: the changes are already done in the IPFIX registry, via the IE doctors (draft-ietf-ipfix-ie-doctors-07 procedure)

Errata ID: 1988
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-28
Verifier Name: Dan Romascanu
Date Verified: 2010-05-11

Section 9.1.3, pg.39 says:

   signedAttrs:  an optional set of attributes that are signed along
      with the content.

|  digestAlgorithm:  identifies the digital signature algorithm and
      associated parameters used to generate the signature.

   signature:  the digital signature of the associated file.

   unsignedAttrs:  an optional set of attributes that are not signed.

It should say:

   signedAttrs:  an optional set of attributes that are signed along
      with the content.

|  signatureAlgorithm:  identifies the digital signature algorithm and
      associated parameters used to generate the signature.

   signature:  the digital signature of the associated file.

   unsignedAttrs:  an optional set of attributes that are not signed.

Notes:

Rationale:
Same SEQUENCE element name listed twice, for two different explanations.

Further Note (keep for update!):
In Section 9.1, in the ASN.1 on page 37, for a better approximation
to ASN.1, all pairs of curly braces, "{" ... "}", should better be
preceded by the keyword "SEQUENCE".

Errata ID: 4306
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Wayne Tackabury
Date Reported: 2015-03-19
Verifier Name: Benoit Claise
Date Verified: 2015-03-19

Section A.5 says:

   224: 0A 47 0A B6 E5 47 0C 07 48 00|01 03 00 18 00 3E
           [ message checksum record ^ -->
   240: 2B 37 08 CE B2 0E 30 11 32 12 4A 5F E3 AD DB 00

   256:|00 0A 05 10 47 0A B6 E5 00 00 00 06 00 00 00 01

It should say:

   224: 0A 47 0A B6 E5 47 0C 07 48 00|01 03 00 16 00 3E
           [ message checksum record ^ -->
   240: 2B 37 08 CE B2 0E 30 11 32 12 4A 5F E3 AD DB 00

   256:|00 0A 05 10 47 0A B6 E5 00 00 00 06 00 00 00 01

Notes:

First of all, note that per erratum #2030, the offsets in this whole section are wrong, it should begin (I think) at 192. I shall use the published (incorrect) offset for illuminating this point:

I believe the byte at #237 should be 0x16 and not 0x18. I suspect this checksum was copy-pasted from a prior instance in the example, where there were three pad bytes added to the data record for #259 (0x103). In this instance, there is only one pad byte at #255, hence the offset here should be two less (22 or 0x16 and not 24 or 0x18):

2 bytes set ID
2 bytes length
1 byte option data
16 bytes checksum data
1 byte pad (at #255)

...totalling 22. Thanks!

Errata ID: 2906
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02

Section B.1.1 says:

   Observation Domain ID:   Similarly, the NetFlow V9 sourceID has
      become the IPFIX Observation Domain ID.

It should say:

   Observation Domain ID:   Similarly, the NetFlow V9 Source ID has
      become the IPFIX Observation Domain ID.

Notes:

s/sourceID/Source ID/

Per consistent usage in RFC3954, the correct term is "Source ID".

RFC 5656, "Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer", December 2009

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 1960
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-17
Verifier Name: Sean Turner
Date Verified: 2010-07-30

Section 6.2,2nd para says:

|  For example, the method name for ECDH key exchange with ephemeral
|  keys generated on the nistp256 curve is "ecdsa-sha2-nistp256".

It should say:

                                    vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
|  For example, the method name for the SSH ECC public key algorithm
|  using the nistp256 curve is "ecdsa-sha2-nistp256".
   ^^^^^

Notes:

Rationale: The RFC text inadvertently mixes content appropriate for
Section 6.2 with content in Section 6.3; the current text would cause
a contradiction with 6.3, as can be seen from the 2nd para in 6.3.

Errata ID: 4207
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alex Gaynor
Date Reported: 2014-12-23
Verifier Name: Kathleen Moriarty
Date Verified: 2015-03-24

Section 12.1 says:

   [SEC1]         Standards for Efficient Cryptography Group, "Elliptic
                  Curve Cryptography", SEC 1, May 2009,
                  <http://www.secg.org/download/aid-780/sec1-v2.pdf>.

   [SEC2]         Standards for Efficient Cryptography Group,
                  "Recommended Elliptic Curve Domain Parameters", SEC 2,
                  September 2000,
                  <http://www.secg.org/download/aid-386/sec2_final.pdf>.

It should say:

  [SEC1]         Standards for Efficient Cryptography Group, "Elliptic
                 Curve Cryptography", SEC 1, May 2009,
                 <http://www.secg.org/sec1-v2.pdf>.

  [SEC2]         Standards for Efficient Cryptography Group,
                 "Recommended Elliptic Curve Domain Parameters", SEC 2,
                 September 2000,
                 <http://www.secg.org/SEC2-Ver-1.0.pdf>.

Notes:

The link presented in these references are now 404s.

Corrected text was provided by Douglas Stebila.

Verified the issue with old links and verified the new links have the referenced documents.

RFC 5657, "Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard", September 2009

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: gen

Errata ID: 1900
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-10-02
Verifier Name: Russ Housley
Date Verified: 2010-04-12

Section 5.5 says:

|     [RFC4234] progressed from Proposed Standard through Draft Standard
|     to Standard and is obsoleted by [RFC5234].

It should say:

|     [RFC4234] progressed from Proposed Standard to Draft Standard and
|     then has been obsoleted by the Full Standard [RFC5234].

Notes:

Clear description of historical timeline.

Errata ID: 1901
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-10-02
Verifier Name: Russ Housley
Date Verified: 2010-04-12

Section 6.2 says:

[[ second paragraph of Section 6.2 ]]

      VRFY and EXPN commands are often not implemented or are disabled.
      This does not pose an interoperability problem for SMTP because
|     EXPN is an optional features and its support is never relied on.
      [...]                     ^^

It should say:

      VRFY and EXPN commands are often not implemented or are disabled.
      This does not pose an interoperability problem for SMTP because
|     EXPN is an optional feature and its support is never relied on.
      [...]                     ^

Notes:

Correct typo.

RFC 5660, "IPsec Channels: Connection Latching", October 2009

Source of RFC: btns (sec)

Errata ID: 4051
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Watson Ladd
Date Reported: 2014-07-16
Verifier Name: Roman Danyliw
Date Verified: 2022-01-20

Section 2.2 says:

Connection latches can exist in any of the following five states:

It should say:

Connection latches can exist in any of the following four states:

Notes:

This sentence is followed by a list with four elements, not five. The state machine diagram also has four states, not five.

RFC 5661, "Network File System (NFS) Version 4 Minor Version 1 Protocol", January 2010

Note: This RFC has been obsoleted by RFC 8881

Note: This RFC has been updated by RFC 8178, RFC 8434

Source of RFC: nfsv4 (wit)

Errata ID: 2291
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Eisler
Date Reported: 2010-05-27
Verifier Name: Lars Eggert
Date Verified: 2011-03-07

Section 18.36.3. says:

      The server
      MUST specify an ONC RPC program number equal to csa_cb_program and
      an ONC RPC version number equal to 4 in callbacks sent to the
      client.

It should say:

      The server
      MUST specify an ONC RPC program number equal to csa_cb_program and
      an ONC RPC version number equal to 1 in callbacks sent to the
      client.

Notes:

RFC5661 disagrees with RFC5662. The latter specifies a version number of 1.

Errata ID: 2005
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Eisler
Date Reported: 2010-01-17
Verifier Name: Lars Eggert
Date Verified: 2011-03-07

Section 15.1.11.3 says:

The highest_slot argument in a Sequence operation exceeds the replier's enforced
highest_slotid.

It should say:

The highest_slot argument in a Sequence operation exceeds the replier's enforced
highest_slotid. Also, the rsa_target_highest_slotid argument in a CB_RECALL_SLOT
operation exceeds maximum enforced slot ID of the session's fore channel.

Notes:

The NFSv4.1 specification permits the client to return NFS4ERR_BAD_HIGH_SLOT in
the event rsa_target_highest_slotid is higher the highest slot ID of the
session's fore channel. Arguably this is an unnecessary complication; the client
can return NFS4_OK to sucvh a CB_RECALL_SLOT operation, and then send a
SEQUENCE operation with an sa_highest_slotid argument that is less than or
equal to rsa_target_highest_slotid. NFSv4.2 should specify this simplification.

Errata ID: 2299
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Eisler
Date Reported: 2010-06-03
Verifier Name: Lars Eggert
Date Verified: 2011-03-07

Section 18.45.3. says:

If SECINFO_STYLE4_PARENT is passed, then
   SECINFO_NO_NAME is querying for the required security of the current
   filehandle's parent

It should say:

If SECINFO_STYLE4_PARENT is passed, then
   SECINFO_NO_NAME is querying for the required security of the current
   filehandle's parent, where the current filehandle MUST be that of directory (an object of type NF4DIR).

Errata ID: 2326
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tom Haynes
Date Reported: 2010-07-13
Verifier Name: Lars Eggert
Date Verified: 2011-03-07

Section 15.1.16.3 says:

NFS4ERR_NXIO (Error Code 5) 

It should say:

NFS4ERR_NXIO (Error Code 6) 

Errata ID: 2327
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tom Haynes
Date Reported: 2010-07-13
Verifier Name: Lars Eggert
Date Verified: 2011-03-07

Section 6.4.3.1 says:

   If the object being created is not a directory, the inherited ACL
   SHOULD NOT inherit ACEs from the parent directory ACL unless the
   ACE4_FILE_INHERIT_FLAG is set.

It should say:

   If the object being created is not a directory, the inherited ACL
   SHOULD NOT inherit ACEs from the parent directory ACL unless the
   ACE4_FILE_INHERIT_ACE is set.

Errata ID: 3208
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Benny Halevy
Date Reported: 2012-05-02
Verifier Name: Martin Stiemerling
Date Verified: 2015-12-16

Throughout the document, when it says:

Notes:

Section 12.5.2. says:
The first successful LAYOUTGET
processed by the server using a non-layout stateid as an argument
MUST have the "seqid" field of the layout stateid in the response set
to one. Thereafter, the client MUST use a layout stateid (see
Section 12.5.3) on future invocations of LAYOUTGET on the file, and
the "seqid" MUST NOT be set to zero.

It should say:
The first successful LAYOUTGET
processed by the server using a non-layout stateid as an argument
MUST have the "seqid" field of the layout stateid in the response set
to one. Thereafter, the client MUST use a layout stateid (see
Section 12.5.3) on future invocations of LAYOUTGET on the file, and
the "seqid" MUST NOT be set to zero.
| The client MUST serialize LAYOUTGET operations using a non-layout
| stateid with any other operation affecting the layout state on the file,
| including CB_LAYOUTRECALL, to allow consistent initialization of the
| layout state.

Add the following paragraph to section 12.5.3.:
| A client MAY always forget its layout state and associated
| layout stateid at any time (See also section 12.5.5.1).
| In such case, the client MUST use a non-layout stateid for the next
| LAYOUTGET operation. This will signal the server that the client has
| no more layouts on the file and its respective layout state can be
| released before issuing a new layout in response to LAYOUTGET.

Section 12.5.5.2.1. says:
One critical issue with regard to layout operations sequencing
concerns callbacks. The protocol must defend against races between
the reply to a LAYOUTGET or LAYOUTRETURN operation and a subsequent
CB_LAYOUTRECALL. A client MUST NOT process a CB_LAYOUTRECALL that
implies one or more outstanding LAYOUTGET or LAYOUTRETURN operations
to which the client has not yet received a reply. The client detects
such a CB_LAYOUTRECALL by examining the "seqid" field of the recall's
layout stateid. If the "seqid" is not exactly one higher than what
the client currently has recorded, and the client has at least one
LAYOUTGET and/or LAYOUTRETURN operation outstanding, the client knows
the server sent the CB_LAYOUTRECALL after sending a response to an
outstanding LAYOUTGET or LAYOUTRETURN.

It should say:
One critical issue with regard to layout operations sequencing
concerns callbacks. The protocol must defend against races between
the reply to a LAYOUTGET or LAYOUTRETURN operation and a subsequent
CB_LAYOUTRECALL. A client MUST NOT process a CB_LAYOUTRECALL that
implies one or more outstanding LAYOUTGET or LAYOUTRETURN operations
to which the client has not yet received a reply. The client detects
such a CB_LAYOUTRECALL by examining the "seqid" field of the recall's
layout stateid. If the "seqid" is not exactly one higher than what
the client currently has recorded, and the client has at least one
LAYOUTGET and/or LAYOUTRETURN operation outstanding,
| or if the client has a outstanding LAYOUTGET with a non-layout stateid,
the client knows
the server sent the CB_LAYOUTRECALL after sending a response to an
outstanding LAYOUTGET or LAYOUTRETURN.

Section 12.5.5.2.1.1. says:
It is permissible for the client to send multiple parallel LAYOUTGET
operations for the same file or multiple parallel LAYOUTRETURN
operations for the same file or a mix of both.

It should say:
It is permissible for the client to send multiple parallel LAYOUTGET
operations for the same file
| using the layout stateid
or multiple parallel LAYOUTRETURN
operations for the same file or a mix of both.

Section 12.5.5.2.1.2. says:
Note
that in the first case, the "seqid" in the layout stateid of the
recall is two greater than what the client has recorded;

It should say:
Note
that in the first case, the "seqid" in the layout stateid of the
recall is two greater than what the client has recorded,
| or the client has an outstanding LAYOUTGET using a non-layout stateid;

Errata ID: 3379
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Asmita Karandikar
Date Reported: 2012-10-15
Verifier Name: Magnus Westerlund
Date Verified: 2019-10-25

Section 18.50.3 says:

If there are
sessions (both idle and non-idle), opens, locks, delegations, 
layouts, and/or wants (Section 18.49) associated with the unexpired 
lease of the client ID, the server MUST return NFS4ERR_CLIENTID_BUSY.

It should say:

If there are 
sessions (both idle and non-idle), opens, locks, delegations, 
and/or wants (Section 18.49) associated with the unexpired 
lease of the client ID, the server MUST return NFS4ERR_CLIENTID_BUSY.

Notes:

Should not include layouts.
A forgetful client may not return LAYOUTS. In this case, a server will always return NFS4ERR_CLIENTID_BUSY on DESTROY_CLIENTID and end up persisting the client’s lease until it expires although the client is explicitly asking us not to.

Errata ID: 4711
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tom Haynes
Date Reported: 2016-06-16
Verifier Name: Magnus Westerlund
Date Verified: 2020-09-03

Section 15.1.5.5 says:

A stateid with a non-zero seqid value does match the current seqid
   for the state designated by the user.

It should say:

A stateid with a non-zero seqid value is not the most current seqid
   for the state.

Notes:

Two issues here:

1) The negation of the fact, i.e., "does not match".
2) The state is not associated with an user.

Errata ID: 5040
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jonathan Price
Date Reported: 2017-06-12
Verifier Name: Magnus Westerlund
Date Verified: 2020-09-03

Section 18.46.3 says:

Operations other than SEQUENCE, BIND_CONN_TO_SESSION, EXCHANGE_ID,
CREATE_SESSION, and DESTROY_SESSION, MUST NOT appear as the first
operation in a COMPOUND.  

It should say:

Operations other than SEQUENCE, BIND_CONN_TO_SESSION, 
EXCHANGE_ID, DESTROY_CLIENTID, CREATE_SESSION, and 
DESTROY_SESSION, MUST NOT appear as the first 
operation in a COMPOUND.  

Notes:

In the section for DESTROY_CLIENTID (18.50.3), the following text exists (see snipped section below).
This means that DESTROY_CLIENTID must also be in the list for operations that are allowed
in the first operation of a compound.

<...snip...>
If DESTROY_CLIENTID is not prefixed by SEQUENCE, it MUST be the only
operation in the COMPOUND request (otherwise, the server MUST return
NFS4ERR_NOT_ONLY_OP). If the operation is sent without a SEQUENCE
preceding it, a client that retransmits the request may receive an
error in response, because the original request might have been
successfully executed.
<...snip...>

Errata ID: 5467
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Trond Myklebust
Date Reported: 2018-08-17
Verifier Name: Spencer Dawkins
Date Verified: 2018-08-17

Section 15.2 says:

   | LAYOUTGET            | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED,     |
   |                      | NFS4ERR_BADIOMODE, NFS4ERR_BADLAYOUT,      |
   |                      | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID,       |
   |                      | NFS4ERR_DEADSESSION, NFS4ERR_DELAY,        |
   |                      | NFS4ERR_DELEG_REVOKED, NFS4ERR_DQUOT,      |
   |                      | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE,          |
   |                      | NFS4ERR_INVAL, NFS4ERR_IO,                 |
   |                      | NFS4ERR_LAYOUTTRYLATER,                    |
   |                      | NFS4ERR_LAYOUTUNAVAILABLE, NFS4ERR_LOCKED, |
   |                      | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE,       |
   |                      | NFS4ERR_NOSPC, NFS4ERR_NOTSUPP,            |
   |                      | NFS4ERR_OLD_STATEID, NFS4ERR_OPENMODE,     |
   |                      | NFS4ERR_OP_NOT_IN_SESSION,                 |
   |                      | NFS4ERR_RECALLCONFLICT,                    |
   |                      | NFS4ERR_REP_TOO_BIG,                       |
   |                      | NFS4ERR_REP_TOO_BIG_TO_CACHE,              |
   |                      | NFS4ERR_REQ_TOO_BIG,                       |
   |                      | NFS4ERR_RETRY_UNCACHED_REP, NFS4ERR_ROFS,  |
   |                      | NFS4ERR_SERVERFAULT, NFS4ERR_STALE,        |
   |                      | NFS4ERR_TOOSMALL, NFS4ERR_TOO_MANY_OPS,    |
   |                      | NFS4ERR_UNKNOWN_LAYOUTTYPE,                |
   |                      | NFS4ERR_WRONG_TYPE                         |

It should say:

   | LAYOUTGET            | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED,     |
   |                      | NFS4ERR_BADIOMODE, NFS4ERR_BADLAYOUT,      |
   |                      | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID,       |
   |                      | NFS4ERR_DEADSESSION, NFS4ERR_DELAY,        |
   |                      | NFS4ERR_DELEG_REVOKED, NFS4ERR_DQUOT,      |
   |                      | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED,        |
   |                      | NFS4ERR_GRACE, NFS4ERR_INVAL, NFS4ERR_IO,  |
   |                      | NFS4ERR_LAYOUTTRYLATER,                    |
   |                      | NFS4ERR_LAYOUTUNAVAILABLE, NFS4ERR_LOCKED, |
   |                      | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE,       |
   |                      | NFS4ERR_NOSPC, NFS4ERR_NOTSUPP,            |
   |                      | NFS4ERR_OLD_STATEID, NFS4ERR_OPENMODE,     |
   |                      | NFS4ERR_OP_NOT_IN_SESSION,                 |
   |                      | NFS4ERR_RECALLCONFLICT,                    |
   |                      | NFS4ERR_REP_TOO_BIG,                       |
   |                      | NFS4ERR_REP_TOO_BIG_TO_CACHE,              |
   |                      | NFS4ERR_REQ_TOO_BIG,                       |
   |                      | NFS4ERR_RETRY_UNCACHED_REP, NFS4ERR_ROFS,  |
   |                      | NFS4ERR_SERVERFAULT, NFS4ERR_STALE,        |
   |                      | NFS4ERR_TOOSMALL, NFS4ERR_TOO_MANY_OPS,    |
   |                      | NFS4ERR_UNKNOWN_LAYOUTTYPE,                |
   |                      | NFS4ERR_WRONG_TYPE                         |

Notes:

LAYOUTGET takes a stateid argument that can represent either a layout or a delegation,
or open/lock state. As such, it needs to be able to report back when the state represented
by that stateid has expired.

(Verified on NFSv4 mailing list)

Errata ID: 6015
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sushil Agarwal
Date Reported: 2020-03-12
Verifier Name: Magnus Westerlund
Date Verified: 2020-09-04

Section 17 says:

CB_SEQUENCE             | OPT  

It should say:

CB_SEQUENCE             | REQ

Notes:

The section 20.9.3 of CB_SEQUENCE says

"In each CB_COMPOUND request, CB_SEQUENCE MUST appear once and MUST be the
first operation. The error NFS4ERR_SEQUENCE_POS MUST be returned
when CB_SEQUENCE is found in any position in a CB_COMPOUND beyond the
first. If any other operation is in the first position of CB_COMPOUND, NFS4ERR_OP_NOT_IN_SESSION MUST be returned."

Since CB_RECALL_SLOT is REQ operation in NFSv4.1. This make CB_COMPOUND as REQ procedure. Since CB_COMPOUND require CB_SEQUENCE as its first operation and hence CB_SEQUENCE must be required operation.

Errata ID: 3558
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Cal Turney
Date Reported: 2013-03-19
Verifier Name: Martin Stiemerling
Date Verified: 2013-03-20

Section 15.1.4.2 says:

In Table 5 Section 5.1 Page 342, NFS4ERR_DQUOT is defined as error number 69:

    "| NFS4ERR_DQUOT | 69 | Section 15.1.4.2 |"

However, in Section 15.1.4.2 Page 349 it is identified as error code 19:

    "15.1.4.2. NFS4ERR_DQUOT (Error Code 19)"

It should say:

    "15.1.4.2. NFS4ERR_DQUOT (Error Code 69)"

Notes:

I believe NFS4ERR_DQUOT is in fact 69 and the reference to error code 19 in Section 15.1.4.2 is a typo.

In RFC 3010, Error Code 19 was assigned to "NFS4ERR_NODEV" but that association appears to have suffered the same fate as RFC 3010 itself and there is no mention of NFS4ERR_NODEV in RFC 3530 which rendered that RFC obsolete.

Errata ID: 2006
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Eisler
Date Reported: 2010-01-17
Verifier Name: Lars Eggert
Date Verified: 2011-03-07

Section 15.1.1.3 says:

For any of a number of reasons, the replier could not process this
   operation in what was deemed a reasonable time.  The client should
   wait and then try the request with a new slot and sequence value.

   Some examples of scenarios that might lead to this situation:

   o  A server that supports hierarchical storage receives a request to
      process a file that had been migrated.

   o  An operation requires a delegation recall to proceed, and waiting
      for this delegation recall makes processing this request in a
      timely fashion impossible.

   In such cases, the error NFS4ERR_DELAY allows these preparatory
   operations to proceed without holding up client resources such as a
   session slot.  After delaying for period of time, the client can then
   re-send the operation in question (but not with the same slot ID and
   sequence ID; one or both MUST be different on the re-send).

   Note that without the ability to return NFS4ERR_DELAY and the
   client's willingness to re-send when receiving it, deadlock might
   result.  For example, if a recall is done, and if the delegation
   return or operations preparatory to delegation return are held up by
   other operations that need the delegation to be returned, session
   slots might not be available.  The result could be deadlock.

It should say:

For any of a number of reasons, the replier could not process this
   operation in what was deemed a reasonable time.  The requester should
   wait and then try the request with a new slot and sequence value.

   Some examples of scenarios that might lead to this situation:

   o  A server that supports hierarchical storage receives a request to
      process a file that had been migrated.

   o  An operation requires a delegation recall to proceed, and waiting
      for this delegation recall makes processing this request in a
      timely fashion impossible.

   In such cases, the error NFS4ERR_DELAY allows these preparatory
   operations to proceed without holding up requester resources such as a
   session slot.  After delaying for period of time, the requester can then
   re-send the operation in question. If the operation that returned
   NFS4ERR_DELAY was not a Sequence operation, the initial, preceding 
   Sequence operation of the Compound request MUST NOT be re-sent with same 
   slot ID and sequence ID; one or both MUST be different on the re-send. If
   the operation that returned NFS4ERR_DELAY was a Sequence operation, then
   the Sequence MUST be re-sent with the same slot ID and sequence ID.

   Note that without the ability to return NFS4ERR_DELAY and the
   requester's willingness to re-send when receiving it, deadlock might
   result.  For example, if a recall is done, and if the delegation
   return or operations preparatory to delegation return are held up by
   other operations that need the delegation to be returned, session
   slots might not be available.  The result could be deadlock.

Notes:

This errata is correcting two problems:

(1) The use of term "requester" instead of "client" since NFS4ERR_DELAY
is applicable for both the backchannel and fore channel.

(2) Clarification that NFS4ERR_DELAY from a Sequence operation is handled
differently from non-Sequence operations.

Errata ID: 2062
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Peter Varga
Date Reported: 2010-03-04
Verifier Name: Lars Eggert
Date Verified: 2011-03-07

Section 2.10.6.1.3 says:

A reply that consists only of the Sequence operation with the error NFS4ERR_FALSE_RETRY.

When the replier detects a false retry, it is permitted (but not always obligated) to return NFS4ERR_FALSE_RETRY...

If the replier determines the users are different between the original request and a retry, then the replier MUST return NFS4ERR_FALSE_RETRY.

...current minor version (e.g., SETCLIENTID), the replier MAY return NFS4ERR_FALSE_RETRY...

The difference is due to NFS4ERR_FALSE_RETRY being a valid error for only Sequence operations...

It should say:

A reply that consists only of the Sequence operation with the error NFS4ERR_SEQ_FALSE_RETRY.

When the replier detects a false retry, it is permitted (but not always obligated) to return NFS4ERR_SEQ_FALSE_RETRY...

If the replier determines the users are different between the original request and a retry, then the replier MUST return NFS4ERR_SEQ_FALSE_RETRY.

...current minor version (e.g., SETCLIENTID), the replier MAY return NFS4ERR_SEQ_FALSE_RETRY...

The difference is due to NFS4ERR_SEQ_FALSE_RETRY being a valid error for only Sequence operations...

Notes:

References to NFS4ERR_FALSE_RETRY instead of NFS4ERR_SEQ_FALSE_RETRY

Errata ID: 2249
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Eisler
Date Reported: 2010-05-10
Verifier Name: Lars Eggert
Date Verified: 2011-03-07

Section 12.5.5.2.1.5 says:

   Once a CB_LAYOUTRECALL of LAYOUTRECALL4_FSID is sent, the server MUST
   NOT allow the client to use any layout stateid that refers to a file
   with the specified fsid except for LAYOUTCOMMIT operations.  Once the
   client receives a CB_LAYOUTRECALL of LAYOUTRECALL4_ALL, it MUST NOT
   use any layout stateid that refers to a file with the specified fsid
   except for LAYOUTCOMMIT operations.

It should say:

   Once a CB_LAYOUTRECALL of LAYOUTRECALL4_FSID is sent, the server MUST
   NOT allow the client to use any layout stateid that refers to a file
   with the specified fsid except for LAYOUTCOMMIT operations.  Once the
   client receives a CB_LAYOUTRECALL of LAYOUTRECALL4_FSID, it MUST NOT
   use any layout stateid that refers to a file with the specified fsid
   except for LAYOUTCOMMIT operations.

Notes:

Copy/paste error from the previous paragraph. s/_ALL/_FSID/ in the second sentence of the corrected paragraph.

Errata ID: 2280
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul J Gilliam
Date Reported: 2010-05-20
Verifier Name: Lars Eggert
Date Verified: 2011-03-07

Section 10.4 says:

   OPEN_DELEGATE_READ delegations may be outstanding simultaneously and
   do not conflict.  An OPEN_DELEGATE_WRITE delegation allows the client
   to handle, on its own, all opens.  Only OPEN_DELEGATE_WRITE
   delegation may exist for a given file at a given time, and it is
   inconsistent with any OPEN_DELEGATE_READ delegations.

It should say:

   OPEN_DELEGATE_READ delegations may be outstanding simultaneously and
   do not conflict.  An OPEN_DELEGATE_WRITE delegation allows the client
   to handle, on its own, all opens.  Only one OPEN_DELEGATE_WRITE
   delegation may exist for a given file at a given time, and it is
   inconsistent with any OPEN_DELEGATE_READ delegations.

Errata ID: 2324
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Trond Myklebust
Date Reported: 2010-07-12
Verifier Name: Lars Eggert
Date Verified: 2011-03-07

Section 2.10.6.2 says:

A retry might be sent while the original request is still in progress
on the replier.  The replier SHOULD deal with the issue by returning
NFS4ERR_DELAY as the reply to SEQUENCE or CB_SEQUENCE operation, but
implementations MAY return NFS4ERR_MISORDERED.

It should say:

A retry might be sent while the original request is still in progress
on the replier.  The replier SHOULD deal with the issue by returning
NFS4ERR_DELAY as the reply to SEQUENCE or CB_SEQUENCE operation, but
implementations MAY return NFS4ERR_SEQ_MISORDERED.

Errata ID: 2328
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tom Haynes
Date Reported: 2010-07-13
Verifier Name: Lars Eggert
Date Verified: 2011-03-07

Section 15.1.16 says:

Notes:

From 3530:

NFS4ERR_RESOURCE For the processing of the COMPOUND procedure, the server may exhaust available resources and can not continue processing operations within the COMPOUND procedure. This error will be returned from the server in those instances of resource exhaustion related to the processing of the COMPOUND procedure.

Since it is not used by 5661, shouldn't it appear in Section 15.1.16 Obsoleted Errors?

Errata ID: 2330
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tom Haynes
Date Reported: 2010-07-14
Verifier Name: Lars Eggert
Date Verified: 2011-03-07

Section 3.3.7 says:

   0            1
   +-----------+-----------+-----------+--
   |  count    | 31  ..  0 | 63  .. 32 |
   +-----------+-----------+-----------+--

It should say:

                     0            1
   +-----------+-----------+-----------+--
   |  count    | 31  ..  0 | 63  .. 32 |
   +-----------+-----------+-----------+--

Errata ID: 2548
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: J. Bruce Fields
Date Reported: 2010-10-11
Verifier Name: Lars Eggert
Date Verified: 2011-03-07

Section 18.36.3 says:

csa_fore_chan_attrs, csa_fore_chan_attrs:

It should say:

csa_fore_chan_attrs, csa_back_chan_attrs:

Errata ID: 4215
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tom Haynes
Date Reported: 2014-12-30
Verifier Name: Martin Stiemerling
Date Verified: 2016-02-02

Section 22.1 says:

   All assignments to the registry are made on a First Come First Served
   basis, per Section 4.1 of [55].  The policy for each assignment is
   Specification Required, per Section 4.1 of [55].

It should say:

The registry is to be maintained using the Specification Required
policy as defined in Section 4.1 of [55].

Notes:

Found during the IANA Review of 3530bis.

Errata ID: 6324
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tigran Mkrtchyan
Date Reported: 2020-11-04
Verifier Name: RFC Editor
Date Verified: 2024-02-02

Section 18.23.3 says:

The request's cookieverf field should be set to 0 zero) when the

It should say:

The request's cookieverf field should be set to 0 (zero) when the

Notes:

Missing the open parenthesis

RFC 5663, "Parallel NFS (pNFS) Block/Volume Layout", January 2010

Note: This RFC has been updated by RFC 6688

Source of RFC: nfsv4 (wit)

Errata ID: 4139
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Christoph Hellwig
Date Reported: 2014-10-23
Verifier Name: Martin Stiemerling
Date Verified: 2016-02-02

Section 2.7 says:

<section doesn't exist yet>

It should say:

2.7.  Volatile write caches

   Many storage devices implement volatile write caches that require an
   explicit flush to persist the data from write write operations to
   stable storage.  When a volatile write cache is used the pNFS server
   must ensure the volatile write cache has been committed to stable
   storage before the LAYOUTCOMMIT operation returns.  An example for
   this behavior are SCSI devices with the WCE (Writeback Cache Enable)
   bit set to 1 in the caching mode page (mode page 0x8),
   which require a "SYNCRONIZE CACHE (10)" or "SYNCRONIZE CACHE (16)"
   operation to write back the storage device cache.

Notes:

RFC5663 currently doesn't acknowledge the existence of volatile write caches, but they are common in consumer or SMB storage systems. Add a section that requires the server to take care of them.

RFC 5676, "Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications", October 2009

Source of RFC: opsawg (ops)

Errata ID: 1927
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-10-23
Verifier Name: Dan Romascanu
Date Verified: 2009-10-25

Section 4, 3rd para says:

   The MIB module is organized into a group of scalars and two tables.
   The syslogMsgControl group contains two scalars controlling the
|  maximum size of SYSLOG messages recorded in the tables and also
   controlling whether SNMP notifications are generated for SYSLOG
   messages.

It should say:

   The MIB module is organized into a group of scalars and two tables.
   The syslogMsgControl group contains two scalars controlling the
|  maximum number of SYSLOG messages recorded in the tables and also
   controlling whether SNMP notifications are generated for SYSLOG
   messages.

Notes:

Rationale: possible confusion.

"maximum size of SYSLOG messages recorded" conceptionally would
relate to the SIZE of syslogMsgMsg OCTET STRING instances or the
maximum value for syslogMsgSDParams instances, but the DESCRIPTION
clause for the syslogMsgTableMaxSize OBJECT-TYPE in the MIB module
in Section 7 clarifies that this object indicates the maximum
*number* of entries in the syslogMsgTable and does not describe
some filtering criterion (by size) of the SYSLOG messages recorded.

RFC 5677, "IEEE 802.21 Mobility Services Framework Design (MSFD)", December 2009

Source of RFC: mipshop (int)

Errata ID: 1964
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-21
Verifier Name: Brian Haberman
Date Verified: 2012-09-07

Section 7, Fig. 9 says:

|                MN                                         MoS
 |===================================|    |======| |===================|
 + ---------+                                                +---------+
 | MIH USER |       +------+  +------+    +------+  +------+ | MIH USER|
 | +------+ |       | TCP  |  |DHCP  |    |DHCP  |  | TCP  | | +------+|
 | | MIHF | |       |Client|  |Client|    |Server|  |Server| | | MIHF ||
 +----------+       +------+  +------+    +------+  +------++----------+
     |                 |         |           |         |          |
 ...

It should say:

|                MN                                   Mobility Server
 |===================================|    |======| |===================|
 + ---------+                                                +---------+
 | MIH USER |       +------+  +------+    +------+  +------+ | MIH USER|
 | +------+ |       | TCP  |  |DHCP  |    |DHCP  |  | TCP  | | +------+|
 | | MIHF | |       |Client|  |Client|    |Server|  |Server| | | MIHF ||
 +----------+       +------+  +------+    +------+  +------++----------+
     |                 |         |           |         |          |
 ...

Notes:

Rationale:
The published RFC uses improved terminology, distinguishing
between "MoS" (IEEE 802.21 Mobility Services) and "Mobility
Servers" providing these services -- cf. Section 2 of the RFC.
Unfortunately, this change has been missed for the heading of
Figure 9, on top of page 20.

RFC 5681, "TCP Congestion Control", September 2009

Note: This RFC has been updated by RFC 9438

Source of RFC: tcpm (wit)

Errata ID: 5458
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: James McCauley
Date Reported: 2018-08-12
Verifier Name: Mirja Kühlewind
Date Verified: 2018-08-13

Section 2 says:

   DUPLICATE ACKNOWLEDGMENT: An acknowledgment is considered a
      "duplicate" in the following algorithms when (a) the receiver of
      the ACK has outstanding data, (b) the incoming acknowledgment
      carries no data, (c) the SYN and FIN bits are both off, (d) the
      acknowledgment number is equal to the greatest acknowledgment
      received on the given connection (TCP.UNA from [RFC793]) and (e)
      the advertised window in the incoming acknowledgment equals the
      advertised window in the last incoming acknowledgment.

It should say:

   DUPLICATE ACKNOWLEDGMENT: An acknowledgment is considered a
      "duplicate" in the following algorithms when (a) the receiver of
      the ACK has outstanding data, (b) the incoming acknowledgment
      carries no data, (c) the SYN and FIN bits are both off, (d) the
      acknowledgment number is equal to the greatest acknowledgment
      received on the given connection (SND.UNA from [RFC793]) and (e)
      the advertised window in the incoming acknowledgment equals the
      advertised window in the last incoming acknowledgment.

Notes:

There is no such thing as TCP.UNA in RFC793. The boundary between acknowledged and unacknowledged sent data is SND.UNA.

RFC 5683, "Password-Authenticated Key (PAK) Diffie-Hellman Exchange", February 2010

Source of RFC: INDEPENDENT

Errata ID: 6513
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lars Eggert
Date Reported: 2021-04-02
Verifier Name: RFC Editor
Date Verified: 2021-04-02

In the Copyright Notice, it says:

(http:trustee.ietf.org/license-info)

It should say:

(http://trustee.ietf.org/license-info)

RFC 5684, "Unintended Consequences of NAT Deployments with Overlapping Address Space", February 2010

Source of RFC: INDEPENDENT

Errata ID: 6514
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lars Eggert
Date Reported: 2021-04-02
Verifier Name: RFC Editor
Date Verified: 2021-04-02

In the Copyright Notice, it says:

(http:trustee.ietf.org/license-info)

It should say:

(http://trustee.ietf.org/license-info)

RFC 5694, "Peer-to-Peer (P2P) Architecture: Definition, Taxonomies, Examples, and Applicability", November 2009

Source of RFC: IAB

Errata ID: 1947
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-11-26
Verifier Name: Danny McPherson
Date Verified: 2010-09-10

Section 5.1, pg.12 says:

   An example of a sensor network based on P2P content distribution and
|  Delay-tolerant Networking (DTL) is ZebraNet [Juang2002].  [...]
                                ^

It should say:

   An example of a sensor network based on P2P content distribution and
|  Delay-tolerant Networking (DTN) is ZebraNet [Juang2002].  [...]
                                ^

Notes:

Rationale:
The (common) acronym "DTN" is used subsequently in the RFC,
but "DTL" isn't used anywhere else in the text.

RFC 5702, "Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC", October 2009

Note: This RFC has been updated by RFC 6944

Source of RFC: dnsext (int)

Errata ID: 7090
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter van Dijk
Date Reported: 2022-08-15
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2022-08-26

Section 8.2 says:

8.2.  Signature Type Downgrade Attacks

   Since each RRSet MUST be signed with each algorithm present in the
   DNSKEY RRSet at the zone apex (see Section 2.2 of [RFC4035]), a
   malicious party cannot filter out the RSA/SHA-2 RRSIG and force the
   validator to use the RSA/SHA-1 signature if both are present in the
   zone.  This should provide resilience against algorithm downgrade
   attacks, if the validator supports RSA/SHA-2.

It should say:

[none]

Notes:

The section is incorrect in its entirety. Although the requirement on signers does exist, there is no related requirement for validators to check that all signature algorithms are present. RFC6840 5.11 (which I do realise is newer than RFC5702) re-states this explicitly, where RFC4035 merely implied this distinction.

RFC 5703, "Sieve Email Filtering: MIME Part Tests, Iteration, Extraction, Replacement, and Enclosure", October 2009

Source of RFC: sieve (app)

Errata ID: 6108
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ken Murchison
Date Reported: 2020-04-17
Verifier Name: Barry Leiba
Date Verified: 2020-04-18

Section 9.2 says:

enclose :subject "Warning" :text

It should say:

enclose :subject "Warning" text:

Notes:

The keyword used to signal a multi-line text string is "text:", NOT ":text"

RFC 5707, "Media Server Markup Language (MSML)", February 2010

Source of RFC: INDEPENDENT

Errata ID: 3373
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tamás Györgyey
Date Reported: 2012-10-09
Verifier Name: Nevil Brownlee
Date Verified: 2013-10-31

Section 16.2.2 says:

<xs:attribute name="amt" use="optional">
    <xs:simpleType>
        <xs:restriction base="xs:integer">
            <xs:minInclusive value="-96"/>
            <xs:maxInclusive value="96"/>
        </xs:restriction>
    </xs:simpleType>
</xs:attribute>

It should say:

<xs:attribute name="amt" use="optional">
    <xs:simpleType>
        <xs:union>
            <xs:simpleType>
                <xs:restriction base="xs:integer">
                    <xs:minInclusive value="-96" />
                    <xs:maxInclusive value="96" />
                </xs:restriction>
            </xs:simpleType>
            <xs:simpleType>
                <xs:restriction base="xs:string">
                    <xs:enumeration value="mute" />
                </xs:restriction>
            </xs:simpleType>
        </xs:union>
    </xs:simpleType>
</xs:attribute>

Notes:

Section "8.12.1.1 <gain>" says, for the "amt" attribute of the <gain> element:

"amt: a specific gain to apply specified in dB or the string "mute"
indicating that the stream should be muted. This attribute MUST
NOT be used if "agc" is present."

However, in section "16.2.2. msml-conf-core-datatypes.xsd" the provided schema does not allow the value "mute", only integers. Either the XSD should be corrected as suggested, or the part
'or the string "mute" indicating that the stream should be muted' removed from the description.

Errata ID: 4021
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Wang Lihe
Date Reported: 2014-06-23
Verifier Name: Nevil Brownlee
Date Verified: 2014-07-20

Section 8.3 says:

8.3
      deletewhen: defines whether a media server should automatically
      delete the conference.  Possible values are "nomedia",
      "nocontrol", and "never".  Default is "nomedia".
16.2.2
<xs:attribute name="deletewhen" default="never">
      <xs:simpleType>
       <xs:restriction base="xs:string">
        <xs:enumeration value="nomedia"/>
        <xs:enumeration value="nocontrol"/>
        <xs:enumeration value="never"/>
       </xs:restriction>
      </xs:simpleType>
     </xs:attribute>
10.2.2.1
deletewhen: as defined by <createconference> element in MSML
      Conference Core Package.
16.4.4
<xs:attribute name="deletewhen" use="optional" default="never">
      <xs:simpleType>
       <xs:restriction base="xs:string">
        <xs:enumeration value="nomedia"/>
        <xs:enumeration value="nocontrol"/>
        <xs:enumeration value="never"/>
       </xs:restriction>
      </xs:simpleType>
     </xs:attribute>

Notes:

I don't know which is right, it is "nomedia" from 8.3 and "never" from xsd. One of it should be rewrite. The same thing to the 10.2.2.1 and 16.4.4.

16.2.2 may be missed 'use="optional"'.

---

This RFC's authors confirm that section 8.3 is incorrect; deletewhen's deafult should be 'never'.

As well, "if the 'use=' atribute is not specified in the schema definition for a given attribute, then it defaults to 'optional'".

Errata ID: 4171
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mistake in Schema
Date Reported: 2014-11-11
Verifier Name: Nevil Brownlee
Date Verified: 2014-12-22

Section 16.3.4 says:

<xs:element name="record" substitutionGroup="primitive">
<xs:complexType>
<xs:complexContent>
<xs:extension base="primitiveType">
<xs:choice minOccurs="0">
<xs:element ref="play" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="tonegen" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="recordexit">
<xs:complexType>
<xs:group ref="sendType"/>
</xs:complexType>
</xs:element>
</xs:choice>

It should say:

<xs:element name="record" substitutionGroup="primitive">
<xs:complexType>
<xs:complexContent>
<xs:extension base="primitiveType">
<xs:choice minOccurs="0">
<xs:element ref="play" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="tonegen" minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
<xs:element name="recordexit">
<xs:complexType>
<xs:group ref="sendType"/>
</xs:complexType>
</xs:element>

Notes:

Example in section 13.3 shows both <play> and <recordexit> within <record>
but the schema doesn't allows this

Sec 13.3 example
<?xml version="1.0" encoding="UTF-8"?>
<msml version="1.1">
<dialogstart target="conn:12345" name="12345">
<record prespeech="3s" postspeech="5s" maxtime="60s" termkey="#"
dest="file://record.wav" format="g729">
<play barge="true">
<audio uri="file://prompt.wav"/>
</play>
<recordexit>
<send target="source" event="done"
namelist="record.len record.end"/>
</recordexit>
</record>
</dialogstart>
</msml>

Errata ID: 4640
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ignacio Bertacchini
Date Reported: 2016-03-16
Verifier Name: Nevil Brownlee
Date Verified: 2017-07-20

Section 16.3.10 says:

<xs:element name="tts" type="smediaType" substitutionGroup="smedia"/>

It should say:

 <xs:element name="tts" substitutionGroup="smedia">
  <xs:complexType mixed="true">
   <xs:complexContent>
    <xs:extension base="smediaType">
     <xs:attribute name="uri" type="xs:string" use="optional"/>
    </xs:extension>
   </xs:complexContent>
  </xs:complexType>
 </xs:element>

Notes:

The tts element as is provided does not accept the uri attribute, nor the text content indicated by the RFC. The corrected validation supports commands like the following:

<?xml version="1.0" encoding="UTF-8"?>
<msml version="1.1">
<dialogstart target="conn:AAI_Unique_ID_1" name="sample" type="application/moml+xml">
<play>
<tts uri="file:///somefile.vxml"/>
<tts uri="file:///someotherfile.vxml" iterate="2" xml:lang="en-us"/>
<tts xml:lang="es-ar">text to be read</tts>
<tts>other text</tts>
</play>
</dialogstart>
</msml>

RFC 5708, "X.509 Key and Signature Encoding for the KeyNote Trust Management System", January 2010

Source of RFC: INDEPENDENT

Errata ID: 2014
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-01-26
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-16

Section 8.2, pg.6 says:

   [SHA2-2]     NIST, "Descriptions of SHA-256, SHA-384, and SHA-512",
                May 2001, <http://csrc.nist.gov/publications/fips/
                fips180-3/fips180-3_final.pdf>.

It should say:

   [SHA2-2]     Federal Information Processing Standards Publication
                (FIPS PUB) 180-3, Secure Hash Standard (SHS), October
                2008, <http://csrc.nist.gov/publications/fips/
                fips180-3/fips180-3_final.pdf>.

Notes:

Rationale:
The given Ref. entry is a mix of outdated and current information.
(Corrected text obtained by borrowing from RFC 5758.)
Also, the Ref. anchor "SHA2-2" seems to be a reminiscent
of the predecessor FIPS PUB 180-2; perhaps, "[SHS]" might have
been preferable.

Errata ID: 6515
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lars Eggert
Date Reported: 2021-04-02
Verifier Name: RFC Editor
Date Verified: 2021-04-02

In the Copyright Notice, it says:

(http:trustee.ietf.org/license-info)

It should say:

(http://trustee.ietf.org/license-info)

RFC 5717, "Partial Lock Remote Procedure Call (RPC) for NETCONF", December 2009

Source of RFC: netconf (ops)

Errata ID: 1978
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-28
Verifier Name: Dan Romascanu
Date Verified: 2010-05-11

Section App. A, p.16 says:

    <!-- reply to <partial-lock> -->

    <xs:complexType name="contentPartInPartialLockReplyType">
        <xs:annotation>
            <xs:documentation>
                The content of the reply to a successful
                partial-lock request MUST conform to this complex type.
            </xs:documentation>
        </xs:annotation>
        <xs:sequence>
            <xs:element name="lock-id" type="lock-id-type">
              <xs:annotation>
                <xs:documentation>
|                 Identifies the lock to be released.  Must be the value
|                 received in the response to a partial-lock operation.
                </xs:documentation>
              </xs:annotation>
            </xs:element>
            [...]

It should say:

    <!-- reply to <partial-lock> -->

    <xs:complexType name="contentPartInPartialLockReplyType">
        <xs:annotation>
            <xs:documentation>
                The content of the reply to a successful
                partial-lock request MUST conform to this complex type.
            </xs:documentation>
        </xs:annotation>
        <xs:sequence>
            <xs:element name="lock-id" type="lock-id-type">
              <xs:annotation>
                <xs:documentation>
|                 Identifies the lock, if granted.  This lock-id must
|                 be used in the partial-unlock operation.
                </xs:documentation>
              </xs:annotation>
            </xs:element>
            [...]

Notes:

Rationale:
The clause in the RFC apparently has been copied from page 15
(bottom part), where the partialUnLockType is getting defined,
without the necessary changes in semantics for the context of
the reply to a partial-lock operation.
The replacement text has been crafted in the spirit of the
corresponding description in the YANG module in Appendix B.

Errata ID: 2746
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mehmet Ersue
Date Reported: 2011-03-09
Verifier Name: Dan Romascanu
Date Verified: 2011-03-09

Section Appendix C says:

   Step 6 - Lock user Joe

   <nc:rpc
     xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
     xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0"
         message-id="104">
     <partial-lock>
       <select xmlns:usr="http://example.com/users">
         /usr:top/usr:users/user[usr:name="Joe"]"
       </select>
     </partial-lock>
   </nc:rpc>

   The NETCONF server grants the partial lock.  The scope of this second
   lock includes only the <user> node with name Joe.  The lock protects
   all data below this particular <user> node.

   Step 7 - Receive lock

   <nc:rpc-reply
     xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
     xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0"
     message-id="104">
       <lock-id>2</lock-id>
       <locked-node xmlns:usr="http://example.com/users">
           /usr:top/usr:users/user[usr:name="Joe"]"
       </locked-node>
   </nc:rpc-reply>

It should say:

   Step 6 - Lock user Joe

   <nc:rpc
     xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
     xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0"
         message-id="104">
     <partial-lock>
        <select xmlns:usr="http://example.com/users">
          /usr:top/usr:users/usr:user[usr:name="Joe"]
        </select>
     </partial-lock>
   </nc:rpc>

   The NETCONF server grants the partial lock.  The scope of this second
   lock includes only the <user> node with name Joe.  The lock protects
   all data below this particular <user> node.

   Step 7 - Receive lock

   <nc:rpc-reply
     xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
     xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0"
     message-id="104">
       <lock-id>2</lock-id>
        <locked-node xmlns:usr="http://example.com/users">
            /usr:top/usr:users/usr:user[usr:name="Joe"]
        </locked-node>
   </nc:rpc-reply>

Notes:

- Appendix C is non-normative.
- The instance identifier: /usr:top/usr:users/user[usr:name="Joe"]"
must be replaced with: /usr:top/usr:users/usr:user[usr:name="Joe"]

RFC 5722, "Handling of Overlapping IPv6 Fragments", December 2009

Note: This RFC has been updated by RFC 6946

Source of RFC: 6man (int)

Errata ID: 3089
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Simon Perreault
Date Reported: 2012-01-13
Verifier Name: Brian Haberman
Date Verified: 2012-06-01

Section 4 says:

   IPv6 nodes transmitting datagrams that need to be fragmented MUST NOT
   create overlapping fragments.  When reassembling an IPv6 datagram, if
   one or more its constituent fragments is determined to be an
   overlapping fragment, the entire datagram (and any constituent
   fragments, including those not yet received) MUST be silently
   discarded.

It should say:

   IPv6 nodes transmitting datagrams that need to be fragmented MUST NOT
   create overlapping fragments.  When reassembling an IPv6 datagram, if
   one or more its constituent fragments is determined to be an
   overlapping fragment, the entire datagram (and any constituent
   fragments) MUST be silently discarded.

Notes:

Discarding fragments "including those not yet received" is not implementable. You'd have to keep state about the (source, destination, protocol, id) 4-tuple for MSL (120 seconds). If you do this you create two bugs:
- A new attack vector: an attacker could eat your resources. And if you just limit the number of such state entries then you fail to implement RFC 5722 correctly.
- It breaks at fairly low speeds. See draft-ietf-intarea-ipv4-id-update.

The proposal is simply to remove the "including those not yet received" bit. Normal host stacks do not keep state once a fragment has been reassembled. You reassemble the full packet and clear the fragment table. So this corrected text would align the RFC with actual practice.

This errata report results from an implementation attempt by OpenBSD.

RFC 5728, "The SatLabs Group DVB-RCS MIB", March 2010

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: int

Errata ID: 2287
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stephane Combes
Date Reported: 2010-05-21
Verifier Name: Dan Romascanu
Date Verified: 2010-05-23

Section 3.4.2 says:

Both dvbRcsRcstNetwork.dvbRcsNetworkLanIpAddress (Traffic) 

It should say:

Both dvbRcsRcstNetwork.dvbRcsNetworkLanInetAddress (Traffic) 

Notes:

typo

RFC 5730, "Extensible Provisioning Protocol (EPP)", August 2009

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 1878
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-11
Verifier Name: Alexey Melnikov
Date Verified: 2009-09-11

Throughout the document, when it says:

a)  [[ global ]]

   RFC 4646

b)  [[ global ]]

   [RFC4646]

c)  [[ Section 9.1 ]]

   [RFC4646]  Phillips, A. and M. Davis, "Tags for Identifying
              Languages", BCP 47, RFC 4646, September 2006.

It should say:

a)

   RFC 5646

b)

   [RFC5646]

c)

   [RFC5646]  Phillips, A., Ed., and M. Davis, Ed., "Tags for
              Identifying Languages", BCP 47, RFC 5646,
              September 2009.

Notes:

Unfortunately, RFC 5730 has been published just three days before
RFC 5646, which has obsoleted RFC 4646 and performed a significant
revision of the Language Tag syntax and IANA registry.

I hope that it was not intended to tie EPP to the old Language Tag
architecture. The new one is much better aligned with ISO, the UN
statistics department, and Unicode, and will be generally adopted.

The intent of this Errata Note is to give the author and the IESG
an opportunity to confirm that EPP shall not be tied to the old
LangTag architecture and the now obsolete RFC 4646.

Errata ID: 1846
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Scott Hollenbeck
Date Reported: 2009-09-02
Verifier Name: Alexey Melnikov
Date Verified: 2009-09-06

Section 2.4 says:

o  An OPTIONAL <svcExtension> element that contains one or more
   <extURI> elements that contain namespace URIs representing
   object extensions supported by the server.

o  A <dcp> (data collection policy) element that contains child

It should say:

  o  An OPTIONAL <svcExtension> element that contains one or more
     <extURI> elements that contain namespace URIs representing
     object extensions supported by the server.

-  A <dcp> (data collection policy) element that contains child

Notes:

The description of the <dcp> element, which extends to the description of the OPTIONAL <expiry> element, is indented one level too deep. The <dcp> element should be described at the same level as the <svcMenu> element instead of being indented as if it were a child of the <svcMenu> element.

Errata ID: 1877
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-11
Verifier Name: Alexey Melnikov
Date Verified: 2009-09-11

Section 2.4, pg.8 says:

   -  An <svDate> element that contains the server's current date and
|     time in Universal Coordinated Time (UTC).

It should say:

   -  An <svDate> element that contains the server's current date and
|     time in Coordinated Universal Time (UTC).

Notes:

Rationale: Use of established, official terminology.

Note: There are other variants of "Universal Time" (mostly of
historical interest now), and hence, the term initially
had been written as "Universal Time, Coordinated", giving
rise to the acronym "UTC" that parallels the precursor "UT1".

RFC 5748, "IANA Registry Update for Support of the SEED Cipher Algorithm in Multimedia Internet KEYing (MIKEY)", August 2010

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 2741
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: RFC Editor
Date Reported: 2011-03-04
Verifier Name: RFC Editor
Date Verified: 2011-03-04

In the Document Header

Internet Engineering Task Force (IETF)                          J. Jeong
Request for Comments: 5748                                        H. Kim
Category: Informational                                         H. Jeong
ISSN: 2070-1721                                                   Y. Won
                                        Korea Internet & Security Agency
                                                             August 2010

It should say:

Internet Engineering Task Force (IETF)                           S. Yoon
Request for Comments: 5748                                      J. Jeong
Category: Informational                                           H. Kim
ISSN: 2070-1721                                                 H. Jeong
                                                                  Y. Won
                                        Korea Internet & Security Agency
                                                             August 2010

Notes:

Reported by S. Yoon

The RFC Editor mistakenly removed the author's name when formatting the document to include the updated document header.

The "Authors' Addresses" section and related database entries are correct.

RFC 5751, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", January 2010

Note: This RFC has been obsoleted by RFC 8551

Source of RFC: smime (sec)

Errata ID: 2143
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jim Schaad
Date Reported: 2010-04-08
Verifier Name: Tim Polk
Date Verified: 2010-07-20

Section 3.2.2 says:

      Name                   CMS Type                Inner Content
      enveloped-data         EnvelopedData           id-data
      signed-data            SignedData              id-data
      certs-only             SignedData              none
      compressed-data        CompressedData          id-data

It should say:

      Name                   CMS Type                Inner Content
      enveloped-data         EnvelopedData           id-data
      signed-data            SignedData              id-data
      certs-only             SignedData              id-data
      compressed-data        CompressedData          id-data

Notes:

The inner content type is not an optional field. Some inner content type MUST be included, id-data is the correct inner content type to be specified.

The balance of the required information is in section 3.7. It is possible that the fact that id-data is used as the encapsulated content type should be added to the section Step 1 in 3.7

Errata ID: 2708
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jim Schaad
Date Reported: 2011-02-06
Verifier Name: Tim Polk
Date Verified: 2011-03-09

Section 3.4.3.3 says:

Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42

It should say:

Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha-1; boundary=boundary42

Notes:

In this version we updated the strings associated with the micalg parameter, however the example was not updated to use the correct new value.

RFC 5752, "Multiple Signatures in Cryptographic Message Syntax (CMS)", January 2010

Source of RFC: smime (sec)

Errata ID: 4444
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Derek Edson
Date Reported: 2015-08-11
Verifier Name: Stephen Farrell
Date Verified: 2015-08-14

Section 3 says:

id-aa-multipleSignatures OBJECT IDENTIFIER ::= {
        iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
        id-aa(16) 51 }

It should say:

id-aa-multipleSignatures OBJECT IDENTIFIER ::= { 
       iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 
       smime(16) id-aa(2) 51 }

Notes:

The definition in Appendix A (ASN.1 module) is also incorrect, and inconsistent with section 3, which defines

id-aa-multipleSignatures OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) id-aa(2) 51 }

Under 1.2.840.113549.1.9, 16 is smime, not id-aa. id-aa(2) exists under smime(16)

Errata ID: 3670
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Joël Repiquet
Date Reported: 2013-06-25
Verifier Name: Sean Turner
Date Verified: 2013-08-12

Section 4.3 says:

   The procedures for generating SignerInfo are as specified in Section
   4.4.1 of [CMS] with the following addition:

It should say:

   The procedures for generating SignerInfo are as specified in Section
   5.3 with the following addition:

Notes:

Sean Turner confirmed the error but did not mention the right section reference.

I updated this to point to s5.3. (spt)

RFC 5754, "Using SHA2 Algorithms with Cryptographic Message Syntax", January 2010

Source of RFC: smime (sec)

Errata ID: 2693
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sean Turner
Date Reported: 2011-01-28
Verifier Name: Tim Polk
Date Verified: 2011-03-09

Section 3.3 says:

... the object identifier ecdsa-with-SHA1* (where * is 
224, 256, 384, or 512) with absent parameters.

It should say:

... the object identifier ecdsa-with-SHA* (where * is 
224, 256, 384, or 512) with absent parameters.

Notes:

r/ecdsa-withSHA1*/ecdsa-with-SHA*
The "1" shouldn't be there the algorithm names are ecdsa-with-SHA224, etc. not ecdsa-with-SHA1224.

Errata ID: 4846
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Annie Yousar
Date Reported: 2016-10-28
Verifier Name: Roman Danyliw
Date Verified: 2022-01-20

Section section 3.2 says:

   The SMIMECapabilities attribute value indicates support for one of
|  the DSA signature algorithms in a SEQUENCE with the capabilityID
   field containing the object identifier sha*WithRSAEncryption (where *
   is 224, 256, 384, or 512) with NULL parameters.  

It should say:

   The SMIMECapabilities attribute value indicates support for one of
|  the RSA signature algorithms in a SEQUENCE with the capabilityID
   field containing the object identifier sha*WithRSAEncryption (where *
   is 224, 256, 384, or 512) with NULL parameters.  

Notes:

The section 3.2 is related to RSA.

RFC 5755, "An Internet Attribute Certificate Profile for Authorization", January 2010

Source of RFC: pkix (sec)

Errata ID: 3731
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Leonardo Cotta de Almeida
Date Reported: 2013-09-18
Verifier Name: Barry Leiba
Date Verified: 2014-01-14

Section 7.1 says:

   Within EnvelopedData, the encapsulatedContentInfo identifies the
   content type carried within the ciphertext.  In this case, the
   contentType field of encapsulatedContentInfo MUST contain id-ct-
   attrCertEncAttrs, which has the following value:

It should say:

   Within EnvelopedData, the encryptedContentInfo identifies the
   content type carried within the ciphertext.  In this case, the
   contentType field of encryptedContentInfo MUST contain id-ct-
   attrCertEncAttrs, which has the following value:

Notes:

The EnvelopedData structure has no "EncapsulatedContentInfo". It has a "EncryptedContentInfo":

EnvelopedData ::= SEQUENCE {
version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos,
encryptedContentInfo EncryptedContentInfo,
unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }

CMS objects that carry a "EncapsulatedContentInfo" are of type "SignedData":

SignedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
signerInfos SignerInfos }

Source: RFC 5652 (unchanged at least since RFC 3852).

Errata ID: 4541
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vlad Semenov
Date Reported: 2015-11-20
Verifier Name: Stephen Farrell
Date Verified: 2015-11-20

Section 4.3.4 says:

      name           id-ce-authorityInfoAccess
      OID            { id-pe 1 }

It should say:

      name           id-pe-authorityInfoAccess
      OID            { id-pe 1 }

Notes:

id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } is defined in http://tools.ietf.org/html/rfc5280#section-4.2.2.1

RFC 5760, "RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback", February 2010

Note: This RFC has been updated by RFC 6128

Source of RFC: avt (rai)

Errata ID: 2114
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: ALfred Hoenes
Date Reported: 2010-04-05
Verifier Name: Robert Sparks
Date Verified: 2010-09-16

Section 10.1, pg.40 says:

|  rtcp-unicast:rsi *(SP <processing>:<rtcp-type>])

      This attribute MUST be used to indicate the "Distribution Source
|     Feedback Summary" model of operation.  In this model, a list or
      parameters may be used to explicitly specify how RTCP packets
      originated by receivers are handled.  Options for processing a
      given RTCP packet type are:

      aggr:    The Distribution Source has means for aggregating the
               contents of the RTCP packets and will do so.

|     forward: The Distribution Source will forward the RTCP packet
               unchanged.

|     term:    The Distribution Source will terminate the RTCP packet.

It should say:

|  rtcp-unicast:rsi *(SP <processing>:<rtcp-type>)

      This attribute MUST be used to indicate the "Distribution Source
|     Feedback Summary" model of operation.  In this model, a list of
      parameters may be used to explicitly specify how RTCP packets
      originated by receivers are handled.  Options for processing a
      given RTCP packet type are:

      aggr:    The Distribution Source has means for aggregating the
               contents of the RTCP packets and will do so.

|     forward: The Distribution Source will forward the RTCP packets
               unchanged.

|     term:    The Distribution Source will terminate the RTCP packets.

Notes:

Rationale:

a) (Technical): unmatched "]" in syntax rule;

b) (Editorials): s/or/of/ , and use plural: s/packet/packets/

RFC 5761, "Multiplexing RTP Data and Control Packets on a Single Port", April 2010

Note: This RFC has been updated by RFC 8035, RFC 8858

Source of RFC: avt (rai)

Errata ID: 3380
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin Storsjö
Date Reported: 2012-10-16
Verifier Name: Robert Sparks
Date Verified: 2012-11-04

Section 4 says:

   o  RTP payload type 80 conflicts with Receiver Summary Information
      (RSI) packets defined in "RTCP Extensions for Single-Source
      Multicast Sessions with Unicast Feedback" [6].

It should say:

   o  RTP payload type 81 conflicts with Receiver Summary Information
      (RSI) packets defined in "RTCP Extensions for Single-Source
      Multicast Sessions with Unicast Feedback" [6].

Notes:

Reference [6], RFC 5760 (IANA likewise), specifies that RTCP RSI has the RTCP packet type number 209, which means that it would conflict with RTP payload type 81, not 80 as stated.

RFC 5764, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", May 2010

Note: This RFC has been updated by RFC 7983, RFC 9443

Source of RFC: avt (rai)

Errata ID: 3971
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin Thomson
Date Reported: 2014-04-22
Verifier Name: Ben Campbell
Date Verified: 2015-07-22

Section 4.1.3 says:

   If the client detects a nonzero-length MKI in the server's response
   that is different than the one the client offered, then the client
   MUST abort the handshake and SHOULD send an invalid_parameter alert.

It should say:

   If the client detects a nonzero-length MKI in the server's response
   that is different than the one the client offered, then the client
   MUST abort the handshake and SHOULD send an illegal_parameter alert.

Notes:

invalid_parameter isn't defined anywhere; this probably means illegal_parameter(47), which is defined in RFC 5246.

Errata ID: 4788
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Eric Rescorla
Date Reported: 2016-08-30
Verifier Name: Ben Campbell
Date Verified: 2016-11-08

Section 4.2 says:

   which are assigned as shown below.  The per-association context value
   is empty.

It should say:

   which are assigned as shown below.  No per-association context value
   is used.

Notes:

This code is somewhat ambiguous, though the better interpretation is probably that you should use a zero-length context (arm 2 of https://tools.ietf.org/html/rfc5705#section-4). However, real implementations do not seem to use the exporter value, so we need to resolve this in that direction.

Errata ID: 4873
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Peter Wu
Date Reported: 2016-11-30
Verifier Name: Murray Kucherawy
Date Verified: 2023-11-08

Section 5.1.1 says:

When the mechanism described in this document is in
effect, this is modified so that data written by upper-level protocol
clients of DTLS is assumed to be RTP/RTP and is encrypted using SRTP
rather than the standard TLS record encoding.

It should say:

When the mechanism described in this document is in
effect, this is modified so that data written by upper-level protocol
clients of DTLS is assumed to be RTP/RTCP and is encrypted using SRTP
rather than the standard TLS record encoding.

Notes:

Section 5.1 notes that RTP or RTCP can be sent over the channel, so "RTP/RTP" should be "RTP/RTCP".

RFC 5766, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", April 2010

Note: This RFC has been obsoleted by RFC 8656

Note: This RFC has been updated by RFC 8155, RFC 8553

Source of RFC: behave (tsv)

Errata ID: 5231
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Hannes Landeholm
Date Reported: 2018-01-09
Verifier Name: Spencer Dawkins
Date Verified: 2018-01-09

Section 16 says:

    |<-- Refresh success response -------|             |             |
    |    Transaction-Id=0x427BD3E625A85FC731DC4191     |             |
    |    SOFTWARE="Example server, version 1.17"       |             |
    |    LIFETIME=600 (10 minutes)       |             |             |

It should say:

    |<-- Refresh success response -------|             |             |
    |    Transaction-Id=0x427BD3E625A85FC731DC4191     |             |
    |    SOFTWARE="Example server, version 1.17"       |             |
    |    LIFETIME=600 (10 minutes)       |             |             |
    |    MESSAGE-INTEGRITY=...           |             |             |

Notes:

The last example refresh success response lacks message-integrity, incorrectly implying that the response after a stale nonce exchange does not have to be authenticated.

Errata ID: 3854
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Venu
Date Reported: 2013-12-31
Verifier Name: Spencer Dawkins
Date Verified: 2016-01-13

Section 11 says:

0x4000 through 0x7FFF: These values are the allowed channel
numbers (16,383 possible values).

It should say:

0x4000 through 0x7FFF: These values are the allowed channel
numbers (16,384 possible values).

Notes:

Section 11.2: The channel number is in the range 0x4000 through 0x7FFE
(inclusive);
Since both the values are inclusive it should be 16384 = (0x7FFF-0x4000 + 1)

Errata ID: 4815
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Costin
Date Reported: 2016-09-28
Verifier Name: Magnus Westerlund
Date Verified: 2019-12-17

Section 11.2. says:

 The channel number is in the range 0x4000 through 0x7FFE
      (inclusive);

It should say:

 The channel number is in the range 0x4000 through 0x7FFF
      (inclusive);

Notes:

It seems in the rest of the channel numbers allowed range definitions the values are 0x4000 through 0x7FFF. See: 11. Channels, 18. IANA Considerations.

RFC 5773, "Analysis of Inter-Domain Routing Requirements and History", February 2010

Source of RFC: IRTF

Errata ID: 2675
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-12-20
Verifier Name: Lars Eggert
Date Verified: 2011-06-07

Section 5.9, pg.41 says:

   o  The policies that can be implemented using BGP are designed for
      control of traffic exchange between operators, not for controlling
      paths within a domain.  Policies for BGP are most conveniently
|     expressed in Routing Policy Support Language (RPSL) [RFC2622] and
      this could be extended if thought desirable to include additional
      policy information.

It should say:

   o  The policies that can be implemented using BGP are designed for
      control of traffic exchange between operators, not for controlling
      paths within a domain.  Policies for BGP are most conveniently
|     expressed in Routing Policy Specification Language (RPSL)
      [RFC2622] and this could be extended if thought desirable to
      include additional policy information.

Notes:

Rationale: Cf. the title of RFC 2622 !

RFC 5776, "Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols", April 2010

Source of RFC: msec (sec)

Errata ID: 2155
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: ALfred Hoenes
Date Reported: 2010-04-09
Verifier Name: Sean Turner
Date Verified: 2011-03-28

Section 6.2.1,pg.52 says:

|  o  direct time synchronization response: Upon receiving a response, a
      receiver who has no pending request MUST immediately drop the
      packet.  If this receiver has previously issued a request, he
|     first checks the Group MAC (if applicable), then the "t_r" field,
|     to be sure it is a response to his request, and finally the
      digital signature.  A replayed packet will be dropped during these
      verifications, without compromising the TESLA component.

It should say:

|  o  Direct time synchronization response: Upon receiving a response, a
      receiver who has no pending request MUST immediately drop the
      packet.  If this receiver has previously issued a request, he
|     first checks the "t_r" field, to be sure it is a response to his 
|     request, then the Group MAC (if applicable), and finally the
      digital signature.  A replayed packet will be dropped during these
      verifications, without compromising the TESLA component.

Notes:

Rationale:
a) [supplemental, editorial] capitalization after preceding full stop;
b) conflict with reasonable specification in section 4.2.2.1:
the "t_r" field match with an 'open' request is a very lightweight
operation, and an attacker needs to be on-path and fast or *very*
lucky to happen to pass this check; so performing the more costly
Group MAC verification operation _only_ if the packet "t_r" matches
an open request significantly reduces the workload an attacker can
impose on the receiver; thus, the order of operations specified in
Section 4.2.2.1 is an important detail of the overall anti-DoS
strategy and should not be contradicted by the Security
Considerations section.

Errata ID: 2156
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-04-09
Verifier Name: Tim Polk
Date Verified: 2010-07-20

Section 3.3.2 says:

[[  first paragraph  ]]

   The bootstrap information message (with the in-band bootstrap scheme)
|  and direct time synchronization response message (with the indirect
   time synchronization scheme) both need to be signed by the sender.
   [...]

It should say:

   The bootstrap information message (with the in-band bootstrap scheme)
|  and direct time synchronization response message (with the direct
   time synchronization scheme) both need to be signed by the sender.
   [...]

Notes:

Rationale: most likely a typo, but confusing:
why would the _indirect_ schem use the _direct_ scheme's messages?

RFC 5777, "Traffic Classification and Quality of Service (QoS) Attributes for Diameter", February 2010

Source of RFC: dime (ops)

Errata ID: 2333
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Francois Bard
Date Reported: 2010-07-19
Verifier Name: Dan Romascanu
Date Verified: 2010-11-02

Section 4.2.1 says:

   Time-Of-Day-Condition ::= < AVP Header: 560 >
                             [ Time-Of-Day-Start ]
                             [ Time-Of-Day-End ]
                             [ Day-Of-Week-Mask ]
                             [ Day-Of-Month-Mask ]
                             [ Month-Of-Year-Mask ]
                             [ Absolute-Start-Time ]
                             [ Absolute-End-Time ]
                             [ Timezone-Flag ]
                           * [ AVP ]

It should say:

   Time-Of-Day-Condition ::= < AVP Header: 560 >
                             [ Time-Of-Day-Start ]
                             [ Time-Of-Day-End ]
                             [ Day-Of-Week-Mask ]
                             [ Day-Of-Month-Mask ]
                             [ Month-Of-Year-Mask ]
                             [ Absolute-Start-Time ]
                             [ Absolute-Start-Fractional-Seconds ]
                             [ Absolute-End-Time ]
                             [ Absolute-End-Fractional-Seconds ]
                             [ Timezone-Flag ]
                             [ Timezone-Offset ]
                           * [ AVP ]

Notes:

3 AVPs are omitted in the ABNF for the Time-Of-Day-Condition AVP.

Errata ID: 2334
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Francois Bard
Date Reported: 2010-07-19
Verifier Name: Dan Romascanu
Date Verified: 2010-11-02

Section 10.1 says:

   |Timezone-Offset                       571    4.2.12    Integer32   |
   |Treatment-Action                      572    5.1       Grouped     |
   |QoS-Profile-Id                        573    5.2       Unsigned32  |

It should say:

   |Timezone-Offset                       571    4.2.12    Integer32   |
   |Treatment-Action                      572    5.1       Enumerated  |
   |QoS-Profile-Id                        573    5.2       Unsigned32  |

Notes:

The Treatment-Action AVP is of type Enumerated, as defined in 5.1

Errata ID: 2335
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Francois Bard
Date Reported: 2010-07-19
Verifier Name: Dan Romascanu
Date Verified: 2010-11-02

Throughout the document, when it says:

IP-Bit-Mask-Width

It should say:

IP-Mask-Bit-Mask-Width

Notes:

The original name, IP-Bit-Mask-Width, seems to have been corrupted at some point. Since the AVP is referred as IP-Mask-Bit-Mask-Width in the IANA registry, this name should be used.

Errata ID: 2336
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Francois Bard
Date Reported: 2010-07-19
Verifier Name: Dan Romascanu
Date Verified: 2010-11-02

Section 4.2.8 says:

The Absolute-Start-Fractional-Seconds AVP (AVP Code 567) is of type
Unsigned32.  The value specifies the fractional seconds that are
added to Absolute-Start-Time value in order to determine when the
time window starts.  If this AVP is absent from the Time-Of-Day-
Condition AVP, then the fractional seconds are assumed to be zero.

It should say:

The Absolute-Start-Fractional-Seconds AVP (AVP Code 567) is of type
Unsigned32.  The value specifies the fractional seconds that are
added to Absolute-Start-Time value in order to determine when the
time window starts.  The Absolute-Start-Fractional-Seconds represent 
a 32-bit fraction field giving a precision of about 232 picoseconds 
( 1/((2^32)-1)) seconds ).  If this AVP is absent from the Time-Of-Day-
Condition AVP, then the fractional seconds are assumed to be zero.
See the Network Time Protocol [RFC 1305] for more precision.

Notes:

The AVP description lacked a explanation about what a fractional second is.

RFC 5778, "Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction", February 2010

Source of RFC: dime (ops)

Errata ID: 3035
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Romain Kuntz
Date Reported: 2011-11-22
Verifier Name: ron bonica
Date Verified: 2011-12-06

Throughout the document, when it says:

MIP-Agent-Info

It should say:

MIP6-Agent-Info

Notes:

There is no such thing as the "MIP-Agent-Info" AVP (section 5.2.2 and 6.21), it should be "MIP6-Agent-Info" instead.

RFC 5780, "NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)", May 2010

Note: This RFC has been updated by RFC 8553

Source of RFC: behave (tsv)

Errata ID: 2844
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Selbie
Date Reported: 2011-06-25
Verifier Name: Wes Eddy
Date Verified: 2011-06-27

Section 7.5 says:

RESPONSE-PORT is a 16-bit unsigned integer in network byte order 
followed by 2 bytes of padding. Allowable values of RESPONSE-PORT 
are 0-65536.

It should say:

RESPONSE-PORT is a 16-bit unsigned integer in network byte order 
followed by 2 bytes of padding. Allowable values of RESPONSE-PORT 
are 0-65535.

Notes:

The 16-bit unsigned int range is 0-65535 (0x0000 - 0xffff). 65536 can't be represented inside a a 16-bit.

RFC 5782, "DNS Blacklists and Whitelists", February 2010

Source of RFC: IRTF

Errata ID: 2584
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Levine
Date Reported: 2010-10-26
Verifier Name: Lars Eggert
Date Verified: 2011-06-07

Section 1 says:

Rand and Vixie created a 
DNS-based distribution scheme that quickly became more popular than 
the original BGP distribution. 

It should say:

Eric Ziegast, who was a system administrator for Vixie Enterprises 
where the RBL was hosted, created a DNS-based distribution scheme 
that quickly became more popular than the original BGP distribution.

Notes:

Vixie asked me to make this correction, to properly credit the inventor of DNSBLs.

RFC 5784, "Sieve Email Filtering: Sieves and Display Directives in XML", March 2010

Source of RFC: sieve (app)

Errata ID: 2086
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-03-21
Verifier Name: Alexey Melnikov
Date Verified: 2010-03-23

Section 6, pg.12 says:

   Registrant Contact:  IETF Sieve working group
                        <ietf-mta-filters@imc.org>

It should say:

   Registrant Contact:  IETF Sieve working group
                        <sieve@ietf.org>

Notes:

Rationale:
The 'sieve' mailing list has moved to the IETF.ORG site on 2009-08-19,
according to:
<http://www.IETF.ORG/mail-archive/web/sieve/current/msg00565.html>.

RFC 5785, "Defining Well-Known Uniform Resource Identifiers (URIs)", April 2010

Note: This RFC has been obsoleted by RFC 8615

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 4190
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lauri Rooden
Date Reported: 2014-11-27
Verifier Name: Barry Leiba
Date Verified: 2014-11-27

Section 6.2 says:

             <http://www.w3.org/TR/2002/ REC-P3P-20020416>.


             <http:// www.w3.org/TR/2004/REC-webarch-20041215>.

It should say:

             <http://www.w3.org/TR/2002/REC-P3P-20020416>.


             <http://www.w3.org/TR/2004/REC-webarch-20041215>.

Notes:

There are erroneous spaces in links

RFC 5789, "PATCH Method for HTTP", March 2010

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 3169
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Nottingham
Date Reported: 2012-03-28
Verifier Name: Pete Resnick
Date Verified: 2012-03-29

Section 2 says:

   If
   the operation does not modify the resource identified by the Request-
   URI in a predictable way, POST should be considered instead of PATCH
   or PUT.

It should say:

   If
   the operation does not modify the resource identified by the Request-
   URI in a predictable way that's defined by the semantics of the PATCH 
   media type, POST should be considered instead of PATCH or PUT.


[Also, I suggest adding this to section two, after the sixth paragraph:]

   The means of applying a PATCH request to a resource's state is
   determined by the request's media type.  If a server receives a PATCH
   request with a media type whose specification does not define
   semantics specific to PATCH, the server SHOULD reject the request by
   returning the 415 Unsupported Media Type status code, unless a more
   specific error status code takes priority.

   In particular, servers SHOULD NOT assume PATCH semantics for generic
   media types that don't define them, such as "application/xml" or
   "application/json".  Doing so will cause interoperability issues,
   because the semantics of PATCH become specific to that resource,
   rather than general.

Notes:

RFC5789 does not explicitly tie PATCHing semantics to the media type of the request. This was well understood in the discussions around the document, and can be read between the lines in it, but it doesn't come out and say it.

Errata ID: 5521
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Nottingham
Date Reported: 2018-10-12
Verifier Name: Barry Leiba
Date Verified: 2020-01-07

Section 2.1 says:

   Successful PATCH response to existing text file:

   HTTP/1.1 204 No Content
   Content-Location: /file.txt
   ETag: "e0023aa4f"

   The 204 response code is used because the response does not carry a
   message body (which a response with the 200 code would have).  Note
   that other success codes could be used as well.

   Furthermore, the ETag response header field contains the ETag for the
   entity created by applying the PATCH, available at
   http://www.example.com/file.txt, as indicated by the Content-Location
   response header field.

It should say:

   Successful PATCH response to existing text file:

   HTTP/1.1 204 No Content
   ETag: "e0023aa4f"

   The 204 response code is used because the response does not carry a
   message body (which a response with the 200 code would have).  Note
   that other success codes could be used as well.

   Furthermore, the ETag response header field contains the ETag for the
   entity created by applying the PATCH.

Notes:

See discussion at:
https://github.com/httpwg/http-core/issues/20

Errata ID: 7513
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Ivković
Date Reported: 2023-05-09
Verifier Name: Orie Steele
Date Verified: 2024-04-01

Section 2 says:

PATCH is neither safe nor idempotent as defined by [<a href="./rfc2616" title="&quot;Hypertext Transfer Protocol -- HTTP/1.1&quot;">RFC2616</a>], <a href="#section-9.1">Section</a> <a href="#section-9.1">9.1</a>.

It should say:

PATCH is neither safe nor idempotent as defined by [<a href="./rfc2616" title="&quot;Hypertext Transfer Protocol -- HTTP/1.1&quot;">RFC2616</a>], <a href="./rfc2616#section-9.1">Section</a> <a href="./rfc2616#section-9.1">9.1</a>.

Notes:

Having a link to #section-9.1 leads the browser to section 9.1 in the current RFC (5789). The link should, however, point to section 9.1 in RFC 2616.

RFC 5791, "RFC 2731 ("Encoding Dublin Core Metadata in HTML") Is Obsolete", February 2010

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 2535
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2010-09-30
Verifier Name: Alexey Melnikov
Date Verified: 2010-11-04

Section boilerplate says:

Internet Engineering Task Force (IETF)                        J. Reschke
Request for Comments: 5791                                    greenbytes
Category: Informational                                         J. Kunze
ISSN: 2070-1721                                 University of California
                                                           February 2010

It should say:

Internet Engineering Task Force (IETF)                        J. Reschke
Request for Comments: 5791                                    greenbytes
Obsoletes: 2731                                                 J. Kunze
Category: Informational                         University of California
ISSN: 2070-1721                                            February 2010

Notes:

This spec does obsolete RFC 2731. The ID http://tools.ietf.org/html/draft-reschke-rfc2731bis-05 says that, and it was approved that way (see https://datatracker.ietf.org/doc/draft-reschke-rfc2731bis/#writeup).

(Note that my records show that the AUTH48 version of the XML version of this document is correct, so the error was introduced later on).

RFC 5792, "PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)", March 2010

Source of RFC: nea (sec)

Errata ID: 3935
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Steve Hanna
Date Reported: 2014-03-27
Verifier Name: Stephen Farrell
Date Verified: 2014-05-08

Section 3.1 says:

Each PA-TNC message may
contain one or more attributes associated with the functional
component identified in the component type (PA Subtype) of the
Posture Broker (PB) protocol.

It should say:

Each PA-TNC message may
contain zero or more attributes associated with the functional
component identified in the component type (PA Subtype) of the
Posture Broker (PB) protocol.

Notes:

Section 4 of RFC 5792 says “A PA-TNC message MUST contain a PA-TNC header (defined in section 3.6. followed by a sequence of zero or more PA-TNC attributes.” This contradicts the text in section 3.1, which says “one or more”. The correct text is “zero or more”. There’s no reason why a PA-TNC message containing zero attributes should be prohibited. For PA-TNC messages with some PA subtypes, an empty message containing no attributes may be enough.

Errata ID: 3936
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Steve Hanna
Date Reported: 2014-03-27
Verifier Name: Stephen Farrell
Date Verified: 2014-05-08

Section 3.4 says:

As depicted in section 3.2, a PA-TNC message consists of a PA-TNC
header followed by a sequence of one or more attributes.

It should say:

As depicted in section 3.2, a PA-TNC message consists of a PA-TNC
header followed by a sequence of zero or more attributes.

Notes:

Section 4 of RFC 5792 says “A PA-TNC message MUST contain a PA-TNC header (defined in section 3.6. followed by a sequence of zero or more PA-TNC attributes.” This contradicts the text in section 3.4, which says “one or more”. The correct text is “zero or more”. There’s no reason why a PA-TNC message containing zero attributes should be prohibited. For PA-TNC messages with some PA subtypes, an empty message containing no attributes may be enough.

RFC 5793, "PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC)", March 2010

Source of RFC: nea (sec)

Errata ID: 2848
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Andreas Steffen
Date Reported: 2011-06-28
Verifier Name: Stephen Farrell
Date Verified: 2011-07-21

Section 4.8.1 says:

Remediation String (variable length)

      The Remediation String field MUST contain a UTF-8 [6] encoded
      string.  This string contains human-readable instructions for
      remediation that MAY be displayed to the user by the Posture
      Broker Client.  NUL termination MUST NOT be included.  If a
      Posture Broker Client receives a Reason String that does contain a
      NUL termination, it MUST respond with a fatal Invalid Parameter
      error in a CLOSE batch.

It should say:

Remediation String (variable length)

      The Remediation String field MUST contain a UTF-8 [6] encoded
      string.  This string contains human-readable instructions for
      remediation that MAY be displayed to the user by the Posture
      Broker Client.  NUL termination MUST NOT be included.  If a
      Posture Broker Client receives a Remediation String that does contain a
      NUL termination, it MUST respond with a fatal Invalid Parameter
      error in a CLOSE batch.

Notes:

Copy-and-paste error: Reason String must be changed to Remediation String.

SF: Was discussed by NEA WG which agreed this should be Approved. [1]
http://www.ietf.org/mail-archive/web/nea/current/msg01132.html

RFC 5794, "A Description of the ARIA Encryption Algorithm", March 2010

Source of RFC: INDEPENDENT

Errata ID: 2064
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jungkeun Lee
Date Reported: 2010-03-04
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-16

Appendix B says:

AriaModesOfOperation {
   iso(1) member-body(2) korea(400) nsri(200046) algorithm (1)
   symmetric-encryption-algorithm(1) asn1-module(0) alg-oids(0) }

It should say:

AriaModesOfOperation {
   iso(1) member-body(2) korea(410) nsri(200046) algorithm (1)
   symmetric-encryption-algorithm(1) asn1-module(0) alg-oids(0) }

Notes:

A typo

OLD: korea(400)
NEW: korea(410)

RFC 5797, "FTP Command and Extension Registry", March 2010

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 2581
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: VicTor Smirnoff
Date Reported: 2010-10-19
Verifier Name: Peter Saint-Andre
Date Verified: 2011-11-12

Section 3 says:

   | STOU  | base | Store Unique      | a    | o    | 959, 1123        |

It should say:

   | STOU  | base | Store Unique      | s    | o    | 959, 1123        |

Notes:

RFC0959 has defined STOU as FTP (S)ervice command, but not (A)ccess Control command

Errata ID: 5748
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eugene Adell
Date Reported: 2019-06-08
Verifier Name: Orie Steele
Date Verified: 2024-04-01

Section 3 says:

   | RNTO  | base | Rename From       | s    | m    | 959              |

It should say:

   | RNTO  | base | Rename To         | s    | m    | 959              |

Notes:

Obviously RNTO = Rename To as defined in RFC 959

Errata ID: 7532
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Gordon Steemson
Date Reported: 2023-06-02
Verifier Name: Orie Steele
Date Verified: 2024-04-01

Section sections 3 and 7 says:

(multiple occurrences of each within Table 1, column “RFC#s/References and Notes”)
2640
3659

It should say:

(in section 7.2)

[RFC2640] Curtin, B., "Internationalization of the File Transfer Protocol", RFC 2640, July 1999.

(and)

[RFC3659] Hethmon, P., "Extensions to FTP", RFC 3659, March 2007.

Notes:

These RFCs are referenced prominently in the table which the remainder of the RFC is centered upon, but were omitted from the actual “References” section. Merely to find out what their topics were, I had to go and query for them on the rfc-editor website. This is inefficient in both network resources and user time.

RFC 5801, "Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family", July 2010

Note: This RFC has been updated by RFC 9266

Source of RFC: sasl (sec)

Errata ID: 2768
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Simon Josefsson
Date Reported: 2011-04-06
Verifier Name: Sean Turner
Date Verified: 2011-05-12

Section 10.1 and 11. says:

Section 10.1:
        const gss_OID  desired_mech,

Section 11.1:
       const gss_buffer_t   sasl_mech_name,

It should say:

Section 10.1:
        gss_const_OID  desired_mech,

Section 11.1:
       gss_const_buffer_t   sasl_mech_name,

Add to section 2:
   The normative reference to [RFC5587] is for
   the C types "gss_const_buffer_t" and "gss_const_OID", nothing else
   from that document is required to implement this document.

Add new normative reference:
   [RFC5587]  Williams, N., "Extended Generic Security Service Mechanism
              Inquiry APIs", RFC 5587, July 2009.

Notes:

There is a bug in the C interfaces for these functions. RFC 5587 section 3.4.6 explains the problem and specifies new types to use instead. This errata makes RFC 5801 use the corrected types.

As far as I understand, there are no technical/implementation implications caused by this change -- it merely helps the compiler check implementations better and (in some cases) it can avoid compiler warnings on application code.

A similar issue was recently discussed in the Kitten WG list.

Errata ID: 2825
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Thomas Maslen
Date Reported: 2011-06-07
Verifier Name: Stephen Farrell
Date Verified: 2013-03-16

Section 5.1 says:

The initiator-address-type and acceptor-address-type fields of the GSS-CHANNEL-BINDINGS structure MUST be set to 0.

It should say:

The initiator-address-type and acceptor-address-type fields of the GSS-CHANNEL-BINDINGS structure MUST be set to 255 (GSS_C_AF_NULLADDR).

Notes:

See RFC 2744, section 3.11, last paragraph: "[...] or omit addressing information, specifying GSS_C_AF_NULLADDR as the address-types".

Appendix A of RFC 2744 specifies that the value of GSS_C_AF_NULLADDR is 255.

RFC 5802, "Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms", July 2010

Note: This RFC has been updated by RFC 7677, RFC 9266

Source of RFC: sasl (sec)

Errata ID: 2651
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jehan Pagès
Date Reported: 2010-11-30
Verifier Name: Sean Turner
Date Verified: 2011-03-09

Section 7 says:

   nonce           = "r=" c-nonce [s-nonce]
                     ;; Second part provided by server.

   c-nonce         = printable

   s-nonce         = printable

It should say:

   nonce           = "r=" c-nonce [s-nonce]
                     ;; Second part provided by server.

   c-nonce         = 1*(printable)

   s-nonce         = 1*(printable)

Notes:

"printable" is defined this way:
printable = %x21-2B / %x2D-7E
;; Printable ASCII except ",".
;; Note that any "printable" is also
;; a valid "value".

Hence a "printable" is a single printable character (except ','). But a nonce is a "a sequence of random printable ASCII characters excluding ','" (section 5.1), as can also be seen by the examples (and common sense for a security feature using randomness).

Errata ID: 2652
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jehan Pagès
Date Reported: 2010-11-30
Verifier Name: Sean Turner
Date Verified: 2011-03-26

Section 9 says:

It should say:

Add the follow to the end of the 4th paragraph (starts with if an attacker):

  Further, implementations are RECOMMENDED to reject salt values
  shorter than 2 characters and MAY reject even longer salt values if
  they are considered to be insufficient.  See [RFC4086] on generating
  randomness.

Notes:

The original version (in Sec 7) would allow the empty string (hence the base64 encoding of an empty string). Though it may technically be an acceptable base64 encoded string, it is not acceptable in our use as we use it for security features which are not supposed to be empty (though it is not defined this way, but common sense tells). This security consideration addresses this concern.

Errata ID: 2640
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jehan Pagès
Date Reported: 2010-11-22
Verifier Name: Tim Polk
Date Verified: 2011-03-26

Section 5 says:

The server verifies the nonce and the proof, verifies that the
authorization identity (if supplied by the client in the first
message) is authorized to act as the authentication identity, and,
finally, it responds with a "server-final-message", concluding the
authentication exchange.

It should say:

The server verifies the nonce and the proof, verifies that the
authentication identity is authorized to act as the authorization
identity (if supplied by the client in the first message) , and,
finally, it responds with a "server-final-message", concluding the
authentication exchange.

Notes:

It is the authentication identity which acts as (if authorized to) the authorization identity, not the opposite.

RFC 5804, "A Protocol for Remotely Managing Sieve Scripts", July 2010

Note: This RFC has been updated by RFC 7817, RFC 8553

Source of RFC: sieve (app)

Errata ID: 2655
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexey Melnikov
Date Reported: 2010-12-02
Verifier Name: Peter Saint-Andre
Date Verified: 2011-05-16

Section 4 says:

|  quoted                = DQUOTE *1024QUOTED-CHAR DQUOTE
                           ;; limited to 1024 octets between the <">s

It should say:

|  quoted                = DQUOTE *QUOTED-CHAR DQUOTE
                           ;; limited to 1024 octets between the <">s

Notes:

The 1024 limit is on the number of octets, not on the number of Unicode characters.

As per bug report from Mark Crispin.

Errata ID: 7825
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mauro De Gennaro
Date Reported: 2024-02-27
Verifier Name: Murray Kucherawy
Date Verified: 2024-03-18

Section 4 says:

response-logout       = response-oknobye

It should say:

response-logout       = response-ok

Notes:

The client sends the LOGOUT command when it is finished with a
connection and wishes to terminate it. The server MUST reply with an
OK response. The server MUST ignore commands issued by the client
after the LOGOUT command.

[Verifier notes:] Verified by Alexey Melnikov.

Errata ID: 6345
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kaspar Etter
Date Reported: 2020-11-30
Verifier Name: Orie Steele
Date Verified: 2024-04-01

Section 2.6 says:

Examples:
[…]
       C: Putscript "mysievescript" {110+}
       C: require ["fileinto"];
       C:
       C: if envelope :contains "to" "tmartin+sent" {
       C:   fileinto "INBOX.sent";
       C: }
       S: OK

       C: Putscript "myforwards" {190+}
       C: redirect "111@example.net";
       C:
       C: if size :under 10k {
       C:     redirect "mobile@cell.example.com";
       C: }
       C:
       C: if envelope :contains "to" "tmartin+lists" {
       C:     redirect "lists@groups.example.com";
       C: }
       S: OK (WARNINGS) "line 8: server redirect action
               limit is 2, this redirect might be ignored"

It should say:

Examples:
[…]
       C: Putscript "mysievescript" {99+}
       C: require ["fileinto"];
       C:
       C: if envelope :contains "to" "tmartin+sent" {
       C:   fileinto "INBOX.sent";
       C: }
       C:
       S: OK

       C: Putscript "myforwards" {190+}
       C: redirect "111@example.net";
       C:
       C: if size :under 10k {
       C:     redirect "mobile@cell.example.com";
       C: }
       C:
       C: if envelope :contains "to" "tmartin+lists" {
       C:     redirect "lists@groups.example.com";
       C: }
       C:
       S: OK (WARNINGS) "line 8: server redirect action
               limit is 2, this redirect might be ignored"

Notes:

The octet count of the second example is wrong. Additionally, both the second and the third example should have an empty client line after the code like the first example. Otherwise, the octet count of the last example is also wrong.

RFC 5806, "Diversion Indication in SIP", March 2010

Source of RFC: INDEPENDENT

Errata ID: 3081
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Marianne Mohali
Date Reported: 2012-01-05
Verifier Name: Nevil Brownlee
Date Verified: 2012-04-10

Section 9.1 says:

ISUP and ISDN define the following diversion reasons:

It should say:

ISDN defines the following diversion reasons:

Notes:

The listed reasons (code and text) are not ISUP but ISDN (DSS.1)

Errata ID: 3082
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Marianne Mohali
Date Reported: 2012-01-05
Verifier Name: Nevil Brownlee
Date Verified: 2012-04-10

Section 9.1 says:

Mapping of ISUP/ISDN reason codes to Diversion reason codes is
performed as follows:
ISUP/ISDN reason code Diversion reason code
0001                  "user-busy"
0010                  "no-answer"
1111                  "unconditional"
1010                  "deflection"
1001                  "unavailable"
0000                  all others

It should say:

Mapping between ISDN reason codes and Diversion reason codes is
performed as follows:
ISDN reason code      Diversion reason code
0001                  "user-busy"
0010                  "no-answer"
1111                  "unconditional"
1010                  "deflection"
1001                  "unavailable"
0000                  all others
all others            "unknown"

Notes:

The reason codes are not ISUP but ISDN (ISUP deleted).
Missing the "all others" line in the ISDN to Diversion header mapping.

Errata ID: 3083
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Marianne Mohali
Date Reported: 2012-01-05
Verifier Name: Nevil Brownlee
Date Verified: 2012-04-10

Section 9.1 says:

9.1 Mapping ISUP/ISDN Diversion Reason Codes

It should say:

9.1 Mapping ISUP/ISDN Diversion Reason Codes

ISUP defines the following diversion reasons:
0001 = User busy
0010 = no reply
0011 = unconditional
0100 = deflection during alerting
0101 = deflection immediate response
0110 = mobile subscriber not reachable
0000 = Unknown

Mapping between ISUP reason codes and Diversion reason codes is
performed as follows:
ISUP reason code      Diversion reason code
0001                  "user-busy"
0010                  "no-answer"
0011                  "unconditional"
0100 or 0101          "deflection"
0110                  "unavailable"
0000                  all others
all others            "unknown"

Notes:

Section 9.1 mentions mapping with ISUP and ISDN but mapping with ISUP is missing. Indeed ISDN and ISUP reason parameter values are different.
This errata adds the ISUP mapping.

Errata ID: 3177
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Brett Tate
Date Reported: 2012-04-04
Verifier Name: Nevil Brownlee
Date Verified: 2012-04-10

Section 4 says:

Diversion = "Diversion" ":" 1# (name-addr *( ";" diversion_params ))
diversion-params = diversion-reason | diversion-counter |
                   diversion-limit | diversion-privacy |
                   diversion-screen | diversion-extension

It should say:

Diversion = "Diversion" HCOLON diversion-params *(COMMA diversion-params)
diversion-params    = name-addr *(SEMI (diversion-reason /
                      diversion-counter / diversion-limit /
                      diversion-privacy / diversion-screen /
                      diversion-extension))

Notes:

The original text did not comply with the format defined by RFC 4485 and RFC 3261. It also did not indicate where to find the #rule (such as within RFC 2543). Thus the ABNF for Diversion should either be modified or RFC 2543 should be referenced to help interoperability. The proposed new ABNF was provided by RFC 6044; it also changes ";" to SEMI which addresses the related LWS ambiguity concerning if RFC 3261 or RFC 2543 LWS rules should be followed.

Errata ID: 3178
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Brett Tate
Date Reported: 2012-04-04
Verifier Name: Nevil Brownlee
Date Verified: 2012-04-10

Section 6.5.1 says:

privacy="full"

It should say:

privacy=full

Notes:

The example incorrectly adds quotes to full. The quotes add confusion since full was explicitly defined to not use quotes. Similar quoting issues exist within other examples; see sections 6.5.2, 9.2.5, 9.2.6, 9.3.5, and 9.3.6.

Errata ID: 6448
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: WK Sze
Date Reported: 2021-03-02
Verifier Name: Adrian Farrel
Date Verified: 2021-03-15

Section 4 says:

The following is an extension of tables 4 and 5 in [RFC3261] for the Diversion header:

It should say:

The following is an extension of tables 2 and 3 in [RFC3261] for the Diversion header:

Notes:

RFC3261 table 2 & 3 are the "Summary of header fields" which is the correct referencing point of the new Diversion header, while table 4 & 5 are for Timers.

Errata ID: 6991
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rémy ALEGRI
Date Reported: 2022-06-14
Verifier Name: RFC Editor
Date Verified: 2022-06-14

Section 9.3.6. says:

;privacy="off

It should say:

;privacy="off"

Notes:

Hello,

In example or the 9.3.6. Example of SIP to ISDN Translation, an end quote error is present.


Sincerely,

RFC 5810, "Forwarding and Control Element Separation (ForCES) Protocol Specification", March 2010

Note: This RFC has been updated by RFC 7121, RFC 7391

Source of RFC: forces (rtg)

Errata ID: 2566
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jamal Hadi Salim
Date Reported: 2010-10-16
Verifier Name: Adrian Farrel
Date Verified: 2010-10-17

Section Appendix A says:

In Appendix A in line 8:

 o  TLV Result Values, Section 7.1.7

It should say:

 o  RESULT-TLV Result Values, Section 7.1.7

Notes:

See Section A.5

Errata ID: 2568
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jamal Hadi Salim
Date Reported: 2010-10-16
Verifier Name: Adrian Farrel
Date Verified: 2010-10-30

Section A.6. says:

A.6. Association Setup Response

a) So far the numbers are represented like:

0x0000   Success
0x0001   FE ID Invalid
etc.
b) we are only using 0x00000000-0x0000FFFF whereas the 32-bit
space covers 0x00000000-0xFFFFFFFF. 

It should say:

a) Since this is a 32 bit space and not 16 bit a proper representation
would have 8 hexadecimal  numbers and would look like:
0x00000000   Success
0x00000001   FE ID Invalid

b)We need to specify that anything from 0x00010000-0xFFFFFFFF is reserved.

Notes:

IANA will update the registry in line with this Erratum

Errata ID: 2574
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jamal Hadi Salim
Date Reported: 2010-10-16
Verifier Name: Adrian Farrel
Date Verified: 2010-10-18

Section Appendix D says:

Note 1:   This emulates adding a new nexthop entry and then
          atomically updating the L3 entries pointing to an old NH to
          point to a new one.

It should say:

Note 1:   This emulates adding a new nexthop entry and then
          atomically updating the L3 entry that pointed to the
          old NH to point to the new one.

Notes:

Example 13 text (not the example) claims you can use a single KEYINFO to
match multiple L3 entries.
You cannot use KEYINFO to match multiple table entries. The model
RFC 5812 section 4.5.3 is clear that you can only match one entry.

Errata ID: 2575
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jamal Hadi Salim
Date Reported: 2010-10-16
Verifier Name: Adrian Farrel
Date Verified: 2011-05-08

Throughout the document:

 There is some confusion in the way we describe the HA bits.

It should say:

Suggestions made by Evangelos Haleplidis for global consitency.
i. For consistency of terms:

Change word "stage" of page 17 to "phase".

ii. Change the start of section 4.2.2.3 from:
"In this stage..."
To:
"Entering this stage..."

iii.  Change the text in section 8 from:
"Figure 44 extends the state machine illustrated in Figure 4 to 
allow for new states that facilitate connection recovery."
To:
"Figure 44 changes the state machine illustrated in Figure 4 to specify 
states that facilitate connection recovery."

Also add the following text right after that:
"In this figure, the pre-association phase and the Association Setup 
Stage are merged in one state and Association Lost stage is included 
in the Not Associated state."

iv. Alter wording in Figure 44 in Page 84.
Where it says: 
"CE issues Association Setup"
Change to:
"CE issues Association Setup Response"

Notes:

Changes i through iii are entirely editorial and helf clarity in reading.

Change iv fixes a message name that might be confusing.

Errata ID: 4188
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Francois-Xavier Le Bail
Date Reported: 2014-11-21
Verifier Name: Adrian Farrel
Date Verified: 2014-12-05

Section A.5. says:

                0x12        E_E_INVALID_FLAGS

It should say:

                0x12        E_INVALID_FLAGS

Notes:

The 'E_INVALID_FLAGS' is defined in 'section 7.1.7 RESULT TLV'.

The same problem exist in IANA Protocol Registries database at
http://www.internetassignednumbersauthority.org/assignments/forces/forces.xhtml#tlv-types because the typo occurs in 'Appendix A. IANA Considerations'

RFC 5812, "Forwarding and Control Element Separation (ForCES) Forwarding Element Model", March 2010

Note: This RFC has been updated by RFC 7408

Source of RFC: forces (rtg)

Errata ID: 2576
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jamal Hadi Salim
Date Reported: 2010-10-16
Verifier Name: Adrian Farrel
Date Verified: 2010-10-17

Section Table 1 says:

   |                |            |               |     information     |
   |   FE Protocol  |      2     |      [2]      |  Defines parameters |
   |     Object     |            |               |    for the ForCES   |
   |                |            |               |  protocol operation |

It should say:

   |                |            |               |     information     |
   |   FE Protocol  |      2     |    RFC 5810   |  Defines parameters |
   |     Object     |            |               |    for the ForCES   |
   |                |            |               |  protocol operation |

Notes:

Reference [2] used to be the reference to the I-D that became RFC 5810

Errata ID: 3371
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Evangelos Haleplidis
Date Reported: 2012-10-07
Verifier Name: Adrian Farrel
Date Verified: 2012-11-04

Throughout the document, when it says:

Page 65 Section 4.7.2 paragraph 1
<product> lists the allowed frame formats...

Page 95 Section 5.1
      <xsd:element name="frameProduced"> 

It should say:

Page 65 Section 4.7.2 paragraph 1
<product> MAY lists the allowed frame formats...

Page 65 Section 4.7.2 paragraph 1 additional text at end of paragraph
The <product> element MUST contain at least either a frame format or a metadata.

Page 95 Section 5.1
      <xsd:element name="frameProduced" minOccurs="0">

Notes:

Issue with frameProduced being mandatory for an output port.

Errata ID: 3487
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jamal Hadi Salim
Date Reported: 2013-02-18
Verifier Name: Adrian Farrel
Date Verified: 2013-02-19

Section 5.1 says:

                  <component access="read-only" componentID="7">
                    <name>FEState</name>
                    <synopsis>State of this FE</synopsis>
                    <typeRef>FEStateValues</typeRef>
                  </component>

It should say:

                  <component access="read-write" componentID="7">
                    <name>FEState</name>
                    <synopsis>State of this FE</synopsis>
                    <typeRef>FEStateValues</typeRef>
                  </component>

Notes:

FEObject FEState (component ID 7) is read-write. It was mistakenly
labelled read-only

RFC 5815, "Definitions of Managed Objects for IP Flow Information Export", April 2010

Note: This RFC has been obsoleted by RFC 6615

Source of RFC: ipfix (ops)

Errata ID: 2895
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02

Section 6.1 says:

    ipfixSelectorFunctions (1)
    |
    +- ipfixFuncMyFunc (?)
       |
       +- ipfixFuncMyFuncAvail (1) = true
       +- ipfixFuncMyFuncParameters (2)
          |
          +- ipfixFuncMyFuncParametersEntry (1)
             |
             +- index (1) (ipfixFuncMyFuncParametersIndex)
             |  +- ipfixFuncMyFuncParam1 (1) = 47
             |  +- ipfixFuncMyFuncParam2 (2) = -128
             |  +- ipficFuncMyFuncParam3 (3) = 19
             |
             +- index(4) (ipfixFuncMyFuncParametersIndex)
                +- ipfixFuncMyFuncParam1 (1) = 19
                +- ipfixFuncMyFuncParam2 (2) = -1
                +- ipficFuncMyFuncParam3 (3) = 728

It should say:

    ipfixSelectorFunctions (1)
    |
    +- ipfixFuncMyFunc (?)
       |
       +- ipfixFuncMyFuncAvail (1) = true
       +- ipfixFuncMyFuncParameters (2)
          |
          +- ipfixFuncMyFuncParametersEntry (1)
             |
             +- index (1) (ipfixFuncMyFuncParametersIndex)
             |  +- ipfixFuncMyFuncParam1 (1) = 47
             |  +- ipfixFuncMyFuncParam2 (2) = -128
             |  +- ipfixFuncMyFuncParam3 (3) = 19
             |
             +- index(4) (ipfixFuncMyFuncParametersIndex)
                +- ipfixFuncMyFuncParam1 (1) = 19
                +- ipfixFuncMyFuncParam2 (2) = -1
                +- ipfixFuncMyFuncParam3 (3) = 728

Notes:

s/ipficFuncMyFuncParam3/ipfixFuncMyFuncParam3/ (twice)

Typo.

RFC 5817, "Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks", April 2010

Source of RFC: ccamp (rtg)

Errata ID: 5299
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Naiming Shen
Date Reported: 2018-03-24
Verifier Name: Deborah Brungard
Date Verified: 2018-06-29

Section 4.1 says:

   The OSPF and IS-IS procedures for graceful shutdown of TE links are
   similar to the graceful restart of OSPF and IS-IS as described in
   [RFC4203] and [RFC5307], respectively.  Specifically, the node where
   graceful shutdown of a link is desired originates the TE LSA or IS-
   IS-LSP containing a Link TLV for the link under graceful shutdown
   with the Traffic Engineering metric set to 0xffffffff, 0 as
   unreserved bandwidth.

It should say:

   The OSPF and IS-IS procedures for graceful shutdown of TE links are
   similar to the graceful restart of OSPF and IS-IS as described in
   [RFC4203] and [RFC5307], respectively.  Specifically, the node where
   graceful shutdown of a link is desired originates the TE LSA or IS-
   IS-LSP containing a Link TLV for the link under graceful shutdown
   with the Traffic Engineering metric set to 0xffffffff for OSPF and
   to 0xffffff for IS-IS, 0 as unreserved bandwidth.

Notes:

IS-IS TE Default Metric is a 24-bit unsigned integer as defined in RFC 5305 section 3.7 "Sub-TLV 18: Traffic Engineering Default Metric"; while in OSPF, RFC 3630 section 2.5.5, the OSPF TE metric is four octets in length.

RFC 5819, "IMAP4 Extension for Returning STATUS Information in Extended LIST", March 2010

Source of RFC: morg (app)

Errata ID: 2072
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-03-11
Verifier Name: Alexey Melnikov
Date Verified: 2010-03-11

Section 3. says:

[ second example, near the bottom of page 3 ]

|  C: A02 LIST (SUBSCRIBED RECURSIVEMATCH)"" % RETURN (STATUS
      (MESSAGES))
   S: * LIST (\Subscribed) "."  "INBOX"
   S: * STATUS "INBOX" (MESSAGES 17)
   S: * LIST () "." "foo" (CHILDINFO ("SUBSCRIBED"))
   S: A02 OK List completed.

It should say:

                                          v
|  C: A02 LIST (SUBSCRIBED RECURSIVEMATCH) "" % RETURN (STATUS
       (MESSAGES))
      ^
   S: * LIST (\Subscribed) "."  "INBOX"
   S: * STATUS "INBOX" (MESSAGES 17)
   S: * LIST () "." "foo" (CHILDINFO ("SUBSCRIBED"))
   S: A02 OK List completed.

Notes:

2 significant space character missing.

Errata ID: 5725
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stan Kalisch
Date Reported: 2019-05-20
Verifier Name: Barry Leiba
Date Verified: 2019-05-20

Section 3 says:

3.  Examples

   C: A01 LIST "" % RETURN (STATUS (MESSAGES UNSEEN))
   S: * LIST () "."  "INBOX"
   S: * STATUS "INBOX" (MESSAGES 17 UNSEEN 16)
   S: * LIST () "." "foo"
   S: * STATUS "foo" (MESSAGES 30 UNSEEN 29)
   S: * LIST (\NoSelect) "." "bar"
   S: A01 OK List completed.

   The "bar" mailbox isn't selectable, so it has no STATUS reply.

   C: A02 LIST (SUBSCRIBED RECURSIVEMATCH)"" % RETURN (STATUS
      (MESSAGES))
   S: * LIST (\Subscribed) "."  "INBOX"
   S: * STATUS "INBOX" (MESSAGES 17)
   S: * LIST () "." "foo" (CHILDINFO ("SUBSCRIBED"))
   S: A02 OK List completed.

It should say:

3.  Examples

   C: A01 LIST "" % RETURN (STATUS (MESSAGES UNSEEN))
   S: * LIST () "." "INBOX"
   S: * STATUS "INBOX" (MESSAGES 17 UNSEEN 16)
   S: * LIST () "." "foo"
   S: * STATUS "foo" (MESSAGES 30 UNSEEN 29)
   S: * LIST (\NoSelect) "." "bar"
   S: A01 OK List completed.

   The "bar" mailbox isn't selectable, so it has no STATUS reply.

   C: A02 LIST (SUBSCRIBED RECURSIVEMATCH)"" % RETURN (STATUS
      (MESSAGES))
   S: * LIST (\Subscribed) "." "INBOX"
   S: * STATUS "INBOX" (MESSAGES 17)
   S: * LIST () "." "foo" (CHILDINFO ("SUBSCRIBED"))
   S: A02 OK List completed.

Notes:

Lines 141 and 152 each contain two spaces between ""."" and ""INBOX"" instead of one. While I had the instinct to mark these as editorial, these sample server responses have also ended up in another RFC and two IDs (which were corrected before they became RFCs). In any event, given that these responses also violate the ABNF, and given the RFC Ed.'s guideline on ambiguity, I'm just marking them as technical. I'll leave it to others more familiar with the practical issues for various implementers to make the final determination on how to label them.

Please note: a previously verified erratum (Errata ID 2072) addresses this same section; I've just left the corresponding error as is in this corrected text.

----- Verifier notes -----
Yes, this is an error: it comes from a combination of the RFC Editor style of double-spacing between sentences, the construction of the examples in XML in a manner that doesn't distinguish them from sentences, and the fact that it's nearly impossible to notice the situation when one is giving a final review.

Editorial, though, because it's in examples. The ABNF is the authoritative place, and that's correct.

RFC 5830, "GOST 28147-89: Encryption, Decryption, and Message Authentication Code (MAC) Algorithms", March 2010

Note: This RFC has been updated by RFC 8891

Source of RFC: INDEPENDENT

Errata ID: 2094
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: V. Dolmatov
Date Reported: 2010-03-23
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-12

Section 6.1 says:

 - the value of S1 is written into the first bit of N1;

   - the value of S2 is written into the second bit of N1 (etc.);

   - the value of S32 is written into the 32nd bit of N1;

   - the value of S33 is written into the first bit of N2;

   - the value of S34 is written into the 33th bit of N2 (etc.);

   - the value of S64 is written into the 32nd bit of N2.

It should say:

 - the value of S1 is written into the first bit of N1;

   - the value of S2 is written into the second bit of N1 (etc.);

   - the value of S32 is written into the 32nd bit of N1;

   - the value of S33 is written into the first bit of N2;

   - the value of S34 is written into the second bit of N2 (etc.);

   - the value of S64 is written into the 32nd bit of N2.

Errata ID: 2137
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2010-04-08
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-12

Section 3.1 says:

   Cipher: a set of reversible transformations of the set of possible
   plain texts onto the set of encrypted data, made after certain rules
   and using keys.

It should say:

   Cipher: a set of reversible transformations of the set of possible
   plain texts onto the set of encrypted data carried out by specified 
   rules with the use of keys.

Notes:

"After" does not mean "as a result."

Errata ID: 2140
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2010-04-08
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-12

Section 5.2 says:

   The fillings of the adders N1 and N2 after 32 working rounds are a
   plain text block.

It should say:

   After 32 working rounds contents of registers N1 and N2 are a plain text block.

Notes:

N1 and N2 aren't adders.

Errata ID: 2144
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2010-04-08
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-12

Section 6.1 says:

   The filling of N1 and N2 is encrypted in the electronic codebook mode
   according to the requirements of section 5.1.  The resulting
   encrypted filling of N1 and N2 is the second 64-bit block of the
   running key Gc(2); this block is bitwise added modulo 2 in the adder
   CM5 with the first 64-bit block of the plain text Tp(2).  

It should say:

   The filling of N1 and N2 is encrypted in the electronic codebook mode
   according to the requirements of section 5.1.  The resulting
   encrypted filling of N1 and N2 is the second 64-bit block of the
   running key Gc(2); this block is bitwise added modulo 2 in the adder
   CM5 with the second 64-bit block of the plain text Tp(2).  

Errata ID: 2148
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2010-04-09
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-12

Section 7.1 says:

   The initial filling of N1 and N2 is encrypted in the electronic
   codebook mode in accordance with the requirements in section 6.1.  If
   resulting encrypted filling N1 and N2 is the first 64-bit block of
   the running key Gc(1)=A(S), then this block is added bitwise modulo 2
   with the first 64-bit block of plain text Tp(1) = (t1(1), t2(1), ...,
   t64(1)).

It should say:

   The initial filling of N1 and N2 is encrypted in the electronic
   codebook mode in accordance with the requirements in section 6.1.  The
   resulting encrypted filling N1 and N2 is the first 64-bit block of
   the running key Gc(1)=A(S), then this block is added bitwise modulo 2
   in the adder CM5 with the first 64-bit block of plain text Tp(1) = 
   (t1(1), t2(1), ..., t64(1)).

Errata ID: 2152
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Dolmatov V.
Date Reported: 2010-04-09
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-12

Section 7.2 says:

The block of encrypted data Tc(1) makes the initial filling of N1, N2
   for generating the second block of the running key Gc(2).  The block
   Tc(1) is written in N1 and N2 in accordance with the requirements in
   the subsection 6.1, the resulted block Gc(2) is added bitwise modulo
   2 in the adder CM5 to the second block of the encrypted data Tc(2).
   This results in the block of plain text Tc(2).

It should say:

The block of encrypted data Tc(1) makes the initial filling of N1, N2
   for generating the second block of the running key Gc(2).  The block
   Tc(1) is written in N1 and N2 in accordance with the requirements in
   the subsection 6.1. The filling of N1 and N2 is encrypted in the electronic
   codebook mode according to the requirements of section 5.1. The encrypted
   filling of N1 and N2 makes the second 64-bit block Gc(2) which is added
   bitwise modulo 2 in the adder CM5 to the second block of the encrypted data
   Tc(2). This results in the block of plain text Tc(2).

Notes:

One necessary statement was missed in the text.

Errata ID: 2692
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kirill Gagarski
Date Reported: 2011-01-28
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-12

Section Appendix A says:

   The constant C1 is:

      The bit of N6   32 31 30 29 28 27 26 25 24 23 22 21 20 19 18

      The bit value    0  0  0  0  0  0  0  1  0  0  0  0  0  0  0


      The bit of N6   17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1

      The bit value    1  0 0  0  0  0  0  0  1 0 0 0 0 0 1 0 0

   The constant C2 is:

      The bit of N6   32 31 30 29 28 27 26 25 24 23 22 21 20 19 18

      The bit value    0  0  0  0  0  0  0  1  0  0  0  0  0  0  0


      The bit of N6   17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1

      The bit value    1  0 0  0  0  0  0  0  1 0 0 0 0 0 0 0 1

It should say:

   The constant C1 is:

      The bit of N6   32 31 30 29 28 27 26 25 24 23 22 21 20 19 18

      The bit value    0  0  0  0  0  0  0  1  0  0  0  0  0  0  0


      The bit of N6   17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1

      The bit value    1  0 0  0  0  0  0  0  1 0 0 0 0 0 1 0 0

   The constant C2 is:

      The bit of N5   32 31 30 29 28 27 26 25 24 23 22 21 20 19 18

      The bit value    0  0  0  0  0  0  0  1  0  0  0  0  0  0  0


      The bit of N5   17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1

      The bit value    1  0 0  0  0  0  0  0  1 0 0 0 0 0 0 0 1

Notes:

C1 is stored in N6 and C2 is stored in N5 (not both in N6)

Errata ID: 2134
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2010-04-08
Verifier Name: Nevil Brownlee
Date Verified: 2013-01-14

Section Abstract says:

   This document is intended to be a source of information about the
   Russian Federal standard for electronic encryption, decryption, and
   message authentication algorithms (GOST 28147-89), which is one of
   the Russian cryptographic standard algorithms called GOST
   algorithms).

It should say:

   This document is intended to be a source of information about the
   Russian Federal standard for electronic encryption, decryption, and
   message authentication algorithms (GOST 28147-89), which is one of
   the Russian cryptographic standard algorithms called GOST
   algorithms.

Errata ID: 2135
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2010-04-08
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-12

Section 7.1 says:

   The plain text is divided into 64-bit blocks Tp(1), Tp(2), ..., Tp(M)
   and encrypted in the cipher feedback mode by bitwise addition modulo
   2 in the adder CM5 with the running key Gc generated in 64-bit
   blocks, i.e., Gc(i)=(Gc(1), Gc(2), ..., Gc(M)), where M is defined by
                                                                   ___
   the length of the plain text, Gc(i) is the i-th 64-bit block, i=1,M.
   The number of bits in the block Tp(M) may be less than 64.

It should say:

   The plain text is divided into 64-bit blocks Tp(1), Tp(2), ..., Tp(M)
   and encrypted in the cipher feedback mode by bitwise addition modulo
   2 in the adder CM5 with the running key Gc generated in 64-bit
   blocks, i.e., Gc(i)=(Gc(1), Gc(2), ..., Gc(M)), where M is defined by
   the length of the plain text, Gc(i) is the i-th 64-bit block, i=1,M.
   The number of bits in the block Tp(M) may be less than 64.

Errata ID: 2136
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2010-04-08
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-12

Section 3.1 says:

   Initialisation vector: initial values of plain parameters of a
   cryptographic transformation algorithm.

It should say:

   Initialization vector: initial values of plain parameters of a
   cryptographic transformation algorithm.

Errata ID: 2138
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2010-04-08
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-12

Section 4 says:

   When writing a key (W1, W2, ..., W256), Wq = 0..1, q = 1..256, in the
   KDS the value:

   - W1 is written into the 1st bit of the register X0;

   - the value W2 is written into the 2nd bit of the register X0 (etc.);

   - the value W32 is written into the 32nd bit of the register X0;

   - the value W33 is written into the 1st bit of the register X1;

   - the value W34 is written into the 2nd bit of the register X1
     (etc.);

   - the value W64 is written into the 32nd bit of the register X1;

   - the value W65 is written into the 1st bit of the register X2
     (etc.);

   - the value W256 is written into the 32nd bit of the register X7.

It should say:

   When writing a key (W1, W2, ..., W256), Wq = 0..1, q = 1..256, in the
   KDS:

   - the value W1 is written into the 1st bit of the register X0;

   - the value W2 is written into the 2nd bit of the register X0 (etc.);

   - the value W32 is written into the 32nd bit of the register X0;

   - the value W33 is written into the 1st bit of the register X1;

   - the value W34 is written into the 2nd bit of the register X1
     (etc.);

   - the value W64 is written into the 32nd bit of the register X1;

   - the value W65 is written into the 1st bit of the register X2
     (etc.);

   - the value W256 is written into the 32nd bit of the register X7.

Errata ID: 2139
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2010-04-08
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-12

Section 5.1 says:

   The plain text to be encrypted is split into 64-bit blocks.  Input of
   a binary data block Tp = (a1(0), a2(0), ... , a31(0), a32(0), b1(0),
   b2(0), ..., b32(0)) into the registers N1 and N2 is done so that the
   value of a1(0) is put into the first bit of N1, the value of a2(0) is
   put into the second bit of N1, etc., and the value of a32(0) is put
   into the 32nd bit of N1.  The value of b1(0) is put into the first
   bit of N2, the value of b2(0) is put into the 2nd bit of N2, etc.,
   and the value of b32(0) is input into the 32nd bit of N2.

It should say:

   The plain text to be encrypted is split into 64-bit blocks.  Input of
   any binary data block Tp = (a1(0), a2(0), ... , a31(0), a32(0), b1(0),
   b2(0), ..., b32(0)) into the registers N1 and N2 is done so that the
   value of a1(0) is put into the first bit of N1, the value of a2(0) is
   put into the second bit of N1, etc., and the value of a32(0) is put
   into the 32nd bit of N1.  The value of b1(0) is put into the first
   bit of N2, the value of b2(0) is put into the 2nd bit of N2, etc.,
   and the value of b32(0) is input into the 32nd bit of N2.

Errata ID: 2141
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2010-04-08
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-12

Section 5.2 says:

      A(Tp) is A(a(0), b(0)) = (a(32), b(32)) = Tc.

It should say:

      A(Tp) = A(a(0), b(0)) = (a(32), b(32)) = Tc.

Errata ID: 2145
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2010-04-09
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-12

Section 7.1 says:

   The plain text is divided into 64-bit blocks Tp(1), Tp(2), ..., Tp(M)
   and encrypted in the cipher feedback mode by bitwise addition modulo
   2 in the adder CM5 with the running key Gc generated in 64-bit
   blocks, i.e., Gc(i)=(Gc(1), Gc(2), ..., Gc(M)), where M is defined by
                                                                   ___
   the length of the plain text, Gc(i) is the i-th 64-bit block, i=1,M.
   The number of bits in the block Tp(M) may be less than 64.

It should say:

   The plain text is divided into 64-bit blocks Tp(1), Tp(2), ..., Tp(M)
   and encrypted in the cipher feedback mode by bitwise addition modulo
   2 in the adder CM5 with the running key Gc generated in 64-bit
   blocks, i.e., Gc(i)=(Gc(1), Gc(2), ..., Gc(M)), where M is defined by
   the length of the plain text, Gc(i) is the i-th 64-bit block, i=1..M.
   The number of bits in the block Tp(M) may be less than 64.

Errata ID: 2146
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2010-04-09
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-12

Section 7.1 says:

   The initial filling of N1 and N2 is encrypted in the electronic
   codebook mode in accordance with the requirements in section 6.1.  If
   resulting encrypted filling N1 and N2 is the first 64-bit block of
   the running key Gc(1)=A(S), then this block is added bitwise modulo 2
   with the first 64-bit block of plain text Tp(1) = (t1(1), t2(1), ...,
   t64(1)).

It should say:

   The initial filling of N1 and N2 is encrypted in the electronic
   codebook mode in accordance with the requirements in section 5.1.  If
   resulting encrypted filling N1 and N2 is the first 64-bit block of
   the running key Gc(1)=A(S), then this block is added bitwise modulo 2
   with the first 64-bit block of plain text Tp(1) = (t1(1), t2(1), ...,
   t64(1)).

Errata ID: 2147
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2010-04-09
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-12

Section 7.1 says:

   The filling of N1 and N2 is encrypted in the electronic codebook mode
   in accordance with the requirements in the section 6.1.  The
   encrypted filling of N1 and N2 makes the second 64-bit block of the
   running key Gc(2), this block is added bitwise modulo 2 in the adder
   CM5 to the second block of the plain text Tp(2).

It should say:

   The filling of N1 and N2 is encrypted in the electronic codebook mode
   in accordance with the requirements in the section 5.1.  The
   encrypted filling of N1 and N2 makes the second 64-bit block of the
   running key Gc(2), this block is added bitwise modulo 2 in the adder
   CM5 to the second block of the plain text Tp(2).

Errata ID: 2149
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2010-04-09
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-12

Section 7.2 says:

   The initial filling of N1 and N2 (the initialisation vector S) is
   encrypted in the electronic codebook mode in accordance with the
   subsection 6.1.  The encrypted filling of N1, N2 is the first block
   of the running key Gc(1) = A(S), this block is added bitwise modulo 2
   in the adder CM5 with the encrypted data block Tc(1).  This results
   in the first block of plain text Tp(1).

It should say:

   The initial filling of N1 and N2 (the initialisation vector S) is
   encrypted in the electronic codebook mode in accordance with the
   subsection 5.1.  The encrypted filling of N1, N2 is the first block
   of the running key Gc(1) = A(S), this block is added bitwise modulo 2
   in the adder CM5 with the encrypted data block Tc(1).  This results
   in the first block of plain text Tp(1).

Errata ID: 2150
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2010-04-09
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-12

Section 8 says:

   - The first block of plain text:

      Tp(1) = (t1(1), t1(2), ..., t64(1)) = (a1(1)[0], a2(1)[0], ...,
              a32(1)[0], b1(1)[0], b2(1)[0], ..., b32(1)[0])

It should say:

   The first block of plain text:

      Tp(1) = (t1(1), t1(2), ..., t64(1)) = (a1(1)[0], a2(1)[0], ...,
              a32(1)[0], b1(1)[0], b2(1)[0], ..., b32(1)[0])

Errata ID: 2151
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2010-04-09
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-12

Section 8 says:

   The filling of N1 and N2 is transformed in accordance with the first
   16 rounds of the encryption algorithm in the electronic codebook mode
   (see the subsection 6.1).  In the KDS, there exists the same key that
   is used for encrypting the blocks of plain text Tp(1), Tp(2), ...,
   Tp(M) in the corresponding blocks of encrypted data Tc(1), Tc(2),
   ..., Tc(M).

It should say:

   The filling of N1 and N2 is transformed in accordance with the first
   16 rounds of the encryption algorithm in the electronic codebook mode
   (see the subsection 5.1).  In the KDS, there exists the same key that
   is used for encrypting the blocks of plain text Tp(1), Tp(2), ...,
   Tp(M) in the corresponding blocks of encrypted data Tc(1), Tc(2),
   ..., Tc(M).

Errata ID: 2153
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2010-04-09
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-12

Section 8 says:

   The resulting filling of N1 and N2 is added in the CM5 modulo 2 with
   the third block Tp(3), etc., the last block Tp(M) = (t1(M), t2(M),
   ..., t64(M)), padded if necessary to a complete 64-bit block by
   zeros, is added in CM5 modulo 2 with the filling N1, N2 (a1(M-1)[16],
   a2(M-1)[16], ..., a32(M-1)[16], b1(M-1)[16], b2(M-1)[16], ...,
   b32(M-1)[16]).

It should say:

   The resulting filling of N1 and N2 is added in the CM5 modulo 2 with
   the third block Tp(3), etc., the last block Tp(M) = (t1(M), t2(M),
   ..., t64(M)), padded if necessary to a complete 64-bit block by
   zeros, is added in CM5 modulo 2 with the filling N1, N2 
   (a1(M-1)[16], a2(M-1)[16], ..., a32(M-1)[16], b1(M-1)[16], 
   b2(M-1)[16], ..., b32(M-1)[16]).

Errata ID: 2154
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dolmatov V.
Date Reported: 2010-04-09
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-12

Section 8 says:

The encrypted data Tc(1), Tc(2), ..., Tc(M), when arriving, are
   decrypted, out of the resulting plain text blocks Tp(1), Tp(2), ...,
   Tp(M).  The MAC I'(l) is generated as described in the subsection 5.3
   and compared with the MAC I(l) received together with the encrypted
   data from the telecommunication channel or from the computer memory.
   If the MACs are not equal, the resulting plain text blocks Tp(1),
   Tp(2), ..., Tp(M) are considered false.

It should say:

he encrypted data Tc(1), Tc(2), ..., Tc(M), when arriving, are
   decrypted, out of the resulting plain text blocks Tp(1), Tp(2), ...,
   Tp(M).  The MAC I'(l) is generated as described above
   and compared with the MAC I(l) received together with the encrypted
   data from the telecommunication channel or from the computer memory.
   If the MACs are not equal, the resulting plain text blocks Tp(1),
   Tp(2), ..., Tp(M) are considered false.

Notes:

wrong reference to the original text sections

RFC 5831, "GOST R 34.11-94: Hash Function Algorithm", March 2010

Note: This RFC has been updated by RFC 6986

Source of RFC: INDEPENDENT

Errata ID: 2303
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vasily Dolmatov
Date Reported: 2010-06-17
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-16

Section 9 says:

[GOST3411]  "Information technology.  Cryptographic Data Security.
               Hashing function.", GOST R 34.10-94, Gosudarstvennyi
               Standard of Russian Federation, Government Committee of
               the Russia for Standards, 1994. (In Russian)

It should say:

[GOST3411]  "Information technology.  Cryptographic Data Security.
               Hashing function.", GOST R 34.11-94, Gosudarstvennyi
               Standard of Russian Federation, Government Committee of
               the Russia for Standards, 1994. (In Russian)

Errata ID: 2863
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tino Kaufmann
Date Reported: 2011-07-15
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-20

Section 7.3.1 says:

K[1] = 
733D2C20 65686573 74746769 326c6568
626E7373 20657369 79676120 33206D54

It should say:

K[1] = 
733D2C20 65686573 74746769 79676120
626E7373 20657369 326c6568 33206D54

Notes:

The entries 326c6568 and 79676120 have to been swapped

Errata ID: 4262
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Andrey Pilsky
Date Reported: 2015-02-05
Verifier Name: Nevil Brownlee
Date Verified: 2015-02-17

Section 7.3.2. says:

STEP 3.

   H    = 95BEA0BE 88D5AA02 FE3C9D45 436CE821
          B8287CB6 2CBC135B 3E339EFE F6576CA9

   L    = 00000000 00000000 00000000 00000000
          00000000 00000000 00000000 00000190

   K[1] = 95FEB83E BE3C2833 A09D7C9E BE45B6FE
          88432CF6 D56CBC57 AAE8136D 02215B39

   K[2] = 8695FEB8 1BBE3C28 E2A09D7C 48BE45B6
          DA88432C EBD56CBC 7FABE813 F292215B

   K[2] = 8695FEB8 1BBE3C28 E2A09D7C 48BE45B6
          DA88432C EBD56CBC 7FABE813 F292215B

   K[3] = B9799501 141B413C 1EE2A062 0CB74145
          6FDA88BC D0142A6C FA80AA16 15F2FDB1

It should say:

STEP 3.

   H    = 95BEA0BE 88D5AA02 FE3C9D45 436CE821
          B8287CB6 2CBC135B 3E339EFE F6576CA9

   L    = 00000000 00000000 00000000 00000000
          00000000 00000000 00000000 00000190

   K[1] = 95FEB83E BE3C2833 A09D7C9E BE45B6FE
          88432CF6 D56CBC57 AAE8136D 02215B39
   
   K[2] = 8695FEB8 1BBE3C28 E2A09D7C 48BE45B6
          DA88432C EBD56CBC 7FABE813 F292215B

   K[3] = B9799501 141B413C 1EE2A062 0CB74145
          6FDA88BC D0142A6C FA80AA16 15F2FDB1

Notes:

You need to remove the double K[2]

RFC 5832, "GOST R 34.10-2001: Digital Signature Algorithm", March 2010

Note: This RFC has been updated by RFC 7091

Source of RFC: INDEPENDENT

Errata ID: 3768
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Dick Franks
Date Reported: 2013-10-27
Verifier Name: Nevil Brownlee
Date Verified: 2014-02-03

Section 7.1.2 says:

Parameters a and b take the following values in this example:

   a = 7
   a = 0x7

   b = 43308876546767276905765904595650931995\\
   942111794451039583252968842033849580414

   b = 0x5FBFF498AA938CE739B8E022FBAFEF40563\\
   F6E6A3472FC2A514C0CE9DAE23B7E

It should say:

Parameters a and b take the following values in this example:

   a = 57896044618658097711785492504343953926\\
   634992332820282019728792003956564821034    (-7 mod p)

   a = 0x8000000000000000000000000000\\
   00000000000000000000000000000000042A

   b = 43308876546767276905765904595650931995\\
   942111794451039583252968842033849580414

   b = 0x5FBFF498AA938CE739B8E022FBAFEF40563\\
   F6E6A3472FC2A514C0CE9DAE23B7E

Notes:

The elliptic curve coefficient 'a' in section 7.1.2 is incorrectly defined, with the result that the generator point P in section 7.1.5 fails to satisfy the congruence relationship (1) in section 5.1.

The mistake emanates from the appendix in the GOST R 34.10-2001 standard.

Defining a to be ( -7 mod p ) restores consistency, at least to the extent that the generator point P lies on the specified curve.

Errata ID: 2304
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vasily Dolmatov
Date Reported: 2010-06-17
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-16

Section 9.1 says:

[GOST3411]       "Information technology.  Cryptographic Data
                    Security.  Hashing function.", GOST R 34.10-94,
                    Gosudarstvennyi Standard of Russian Federation,
                    Government Committee of Russia for Standards, 1994.
                    (In Russian)

It should say:

[GOST3411]       "Information technology.  Cryptographic Data
                    Security.  Hashing function.", GOST R 34.11-94,
                    Gosudarstvennyi Standard of Russian Federation,
                    Government Committee of Russia for Standards, 1994.
                    (In Russian)

RFC 5841, "TCP Option to Denote Packet Mood", April 2010

Source of RFC: INDEPENDENT

Errata ID: 4324
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jussi Judin
Date Reported: 2015-04-01
Verifier Name: Nevil Brownlee
Date Verified: 2015-06-30

Section 2 says:

   In more detail:

           +--------+--------+--------+--------+
           |00011001|00000100|00111010|00101001|
           +--------+--------+--------+--------+
            Kind=25  Length=4 ASCII :  ASCII )

           +--------+--------+--------+--------+--------+
           |00011001|00000101|00111110|00111010|01000000|
           +--------+--------+--------+--------+--------+
            Kind=25  Length=5 ASCII >  ACSII :  ASCII @

It should say:

   In more detail:

           +--------+--------+--------+--------+
           |00011001|00000100|00111010|00101001|
           +--------+--------+--------+--------+
            Kind=25  Length=4 ASCII :  ASCII )

           +--------+--------+--------+--------+--------+
           |00011001|00000101|00111110|00111010|01000000|
           +--------+--------+--------+--------+--------+
            Kind=25  Length=5 ASCII >  ASCII :  ASCII @

Notes:

Misspelled word ASCII as ACSII.

Errata ID: 5842
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Wren Turkal
Date Reported: 2019-08-20
Verifier Name: Adrian Farrel
Date Verified: 2019-08-21

Section Authors' Addresses says:

Warren Turkal

It should say:

Wren Turkal

Notes:

The author changed her name.

RFC 5849, "The OAuth 1.0 Protocol", April 2010

Note: This RFC has been obsoleted by RFC 6749

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 2550
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alasdair McIntyre
Date Reported: 2010-10-12
Verifier Name: Peter Saint-Andre
Date Verified: 2011-11-12

Throughout the document, when it says:

Section 3.1
oauth_signature="bYT5CMsGcbgUdFHObYMEfcx6bsw%3D"

Section 3.4.1.1
oauth_signature="bYT5CMsGcbgUdFHObYMEfcx6bsw%3D"

Section 3.4.1.3.1
oauth_signature="djosJKDKJSD8743243%2Fjdk33klY%3D"

It should say:

Section 3.1
oauth_signature="r6%2FTJjbCOr97%2F%2BUU0NsvSne7s5g%3D"

Section 3.4.1.1
oauth_signature="r6%2FTJjbCOr97%2F%2BUU0NsvSne7s5g%3D"

Section 3.4.1.3.1
oauth_signature="r6%2FTJjbCOr97%2F%2BUU0NsvSne7s5g%3D"

Notes:

(Apologies - this supercedes Errata ID 2549).

The signatures in sections 3.1, 3.4.1.1, and 3.4.1.3.1 of the RFC have mistakenly been calculated as if with "GET". I have supplied the correct "POST" signatures in the corrected text.

For reference, here is the perl script I used to calculate the signatures:

#!/usr/bin/perl
use strict;
use warnings;
use Digest::HMAC_SHA1;
use URI::Escape;
use MIME::Base64;

my $unsafe = '^-._~A-Za-z0-9';
my $client_secret = 'j49sk3j29djd';
my $token_secret = 'dh893hdasih9';
my $key = join('&', $client_secret, $token_secret);

my $uri_base = 'http%3A%2F%2Fexample.com%2Frequest';
my $params = join('', qw(
a2%3Dr%2520b%26a3%3D2%2520q%26a3%3Da%26b5%3D
%253D%25253D%26c%2540%3D%26c2%3D%26oauth_con
sumer_key%3D9djdj82h48djs9d2%26oauth_nonce%3
D7d8f3e4a%26oauth_signature_method%3DHMAC-SH
A1%26oauth_timestamp%3D137131201%26oauth_tok
en%3Dkkk9d7dh3k39sjv7
));

foreach my $method ('GET', 'POST') {
my $base_sig = join('&', $method, $uri_base, $params);
my $bin_sig = Digest::HMAC_SHA1::hmac_sha1($base_sig, $key);
my $b64_sig = MIME::Base64::encode_base64($bin_sig, '');
my $enc_sig = URI::Escape::uri_escape($b64_sig, $unsafe);
printf "%-8s %s\n", $method, $enc_sig;
}

RFC 5861, "HTTP Cache-Control Extensions for Stale Content", May 2010

Source of RFC: INDEPENDENT

Errata ID: 2255
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-05-13
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-16

Section 3, pg.3 says:

   Note that this directive does not affect freshness; stale cached
   responses that are used SHOULD still be visibly stale when sent
|  (i.e., have a non-zero Age header and a warning header, as per HTTP's
|  requirements).

It should say:

   Note that this directive does not affect freshness; stale cached
   responses that are used SHOULD still be visibly stale when sent
|  (i.e., have a non-zero Age header field and a Warning header field,
   as per HTTP's requirements).
                                    ^^^^^^       ^             ^^^^^^

Notes:

Rationale:
- inconsistent use of standard terminology, and
- inconsistent capitalization of header field names.

(These issues recur in the last paragraph of Section 4.)

Errata ID: 2256
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-05-13
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-16

Section 4, pg.4 says:

   Note that this directive does not affect freshness; stale cached
   responses that are used SHOULD still be visibly stale when sent
|  (i.e., have a non-zero Age header and a warning header, as per HTTP's
   requirements).

It should say:

   Note that this directive does not affect freshness; stale cached
   responses that are used SHOULD still be visibly stale when sent
|  (i.e., have a non-zero Age header field and a Warning header field,
   as per HTTP's requirements).
                                    ^^^^^^       ^             ^^^^^^

Notes:

Rationale:
- inconsistent use of standard terminology, and
- inconsistent capitalization of header field names.

(Similar issues as for section 3 -- cf. EID=2255.)

RFC 5864, "DNS SRV Resource Records for AFS", April 2010

Note: This RFC has been updated by RFC 8553

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 2260
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-05-13
Verifier Name: Pete Resnick
Date Verified: 2011-08-04

Section 4., pg.5 says:

[[ second paragraph on page 5: ]]

   DNS SRV RRs, like all DNS RRs, have a time-to-live (TTL), after which
   the SRV record information is no longer valid (see [RFC1034]).  DNS
|  RRs SHOULD be discarded after their TTL, and after the DNS query
   repeated.  This applies to DNS SRV RRs for AFS as it does for any
   other DNS RR.  Any information derived from the DNS SRV RRs, such as
   preference ranks, MUST be discarded when the DNS SRV RR is expired.

It should say:

   DNS SRV RRs, like all DNS RRs, have a time-to-live (TTL), after which
   the SRV record information is no longer valid (see [RFC1034]).  DNS
|  RRs SHOULD be discarded after their TTL, and the DNS query be
   repeated.  This applies to DNS SRV RRs for AFS as it does for any
   other DNS RR.  Any information derived from the DNS SRV RRs, such as
   preference ranks, MUST be discarded when the DNS SRV RR is expired.

Notes:

Rationale:
Obviously a late change to the text that distorts the proper sense.
The I-D text was correct.

Perhaps the affected sentence could more explicitly state:

..., and the DNS query be repeated as soon as the information
is needed again.

RFC 5870, "A Uniform Resource Identifier for Geographic Locations ('geo' URI)", June 2010

Source of RFC: geopriv (rai)

Errata ID: 7232
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christian Paul
Date Reported: 2022-11-01
Verifier Name: RFC Editor
Date Verified: 2022-11-01

Section 6.3. says:

Due to it's short length

It should say:

Due to its short length

Notes:

https://www.grammarly.com/blog/its-vs-its/

RFC 5878, "Transport Layer Security (TLS) Authorization Extensions", May 2010

Note: This RFC has been updated by RFC 8447, RFC 8996

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 3512
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ben Laurie
Date Reported: 2013-03-08
Verifier Name: Kathleen Moriarty
Date Verified: 2015-06-05

Section 3 says:

struct {
  SupplementalDataType supplemental_data_type;
  select(SupplementalDataType) {
    case authz_data: AuthorizationData;
  }
} SupplementalData;

It should say:

struct {
  SupplementalDataType supp_data_type;
  uint16 supp_data_length;
  select(SupplementalDataType) {
    case authz_data: AuthorizationData;
  }
} SupplementalDataEntry;

supp_data_length This field is the length (in bytes) of the data 
selected by SupplementalDataType.

Errata ID: 3513
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ben Laurie
Date Reported: 2013-03-08
Verifier Name: Kathleen Moriarty
Date Verified: 2015-06-05

Section 3.3 says:

struct{
  AuthorizationDataEntry authz_data_list<1..2^16­1>;
} AuthorizationData;

It should say:

struct{
  AuthorizationDataEntry authz_data_list[supp_data_length];
} AuthorizationData;

RFC 5880, "Bidirectional Forwarding Detection (BFD)", June 2010

Note: This RFC has been updated by RFC 7419, RFC 7880, RFC 8562

Source of RFC: bfd (rtg)

Errata ID: 2530
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mach Chen
Date Reported: 2010-09-24
Verifier Name: Adrian Farrel
Date Verified: 2010-09-26

Section 4.3 says:

Sequence Number

      The sequence number for this packet.  For Keyed MD5
      Authentication, this value is incremented occasionally.  For
      Meticulous Keyed MD5 Authentication, this value is incremented for
      each successive packet transmitted for a session.  This provides
      protection against replay attacks.

It should say:

Sequence Number

      The sequence number for this packet.  For Keyed MD5
      Authentication, this value is incremented (by one) occasionally.  For
      Meticulous Keyed MD5 Authentication, this value is incremented by one for
      each successive packet transmitted for a session.  This provides
      protection against replay attacks.

Notes:

This change clarifies the amount by which the sequence number is incremented.

Errata ID: 7082
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Glebs Ivanovskis
Date Reported: 2022-08-12
Verifier Name: John Scudder
Date Verified: 2022-09-06

Section 6.7.3 says:

Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to
1, and bfd.RcvAuthSeq MUST be set to the value of the received
Sequence Number field.

Replace the contents of the Auth Key/Digest field with the
authentication key selected by the received Auth Key ID field.  If
the MD5 digest of the entire BFD Control packet is equal to the
received value of the Auth Key/Digest field, the received packet
MUST be accepted.  Otherwise (the digest does not match the Auth
Key/Digest field), the received packet MUST be discarded.

It should say:

Replace the contents of the Auth Key/Digest field with the
authentication key selected by the received Auth Key ID field.  If
the MD5 digest of the entire BFD Control packet is not equal to the
received value of the Auth Key/Digest field, the received packet
MUST be discarded.

Otherwise, the packet MUST be accepted, bfd.AuthSeqKnown MUST be set to
1, and bfd.RcvAuthSeq MUST be set to the value of the received
Sequence Number field.

Notes:

1. Don't manipulate bfd.AuthSeqKnown and bfd.RcvAuthSeq before Auth Key/Digest check.
2. Explicitly mention what bfd.AuthSeqKnown and bfd.RcvAuthSeq must be set to in both cases (bfd.AuthSeqKnown is 0 and bfd.AuthSeqKnown is 1).

Based on email exchange: https://mailarchive.ietf.org/arch/msg/rtg-bfd/lDxFfNpqo4kwuNEUY0AbjMBb8JU/

(See also https://mailarchive.ietf.org/arch/msg/rtg-bfd/Ngf3Chmpy_EqNPlmuMZOslayy2E/)

Errata ID: 7083
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Glebs Ivanovskis
Date Reported: 2022-08-12
Verifier Name: John Scudder
Date Verified: 2022-09-06

Section 6.7.4 says:

Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to
1, bfd.RcvAuthSeq MUST be set to the value of the received
Sequence Number field, and the received packet MUST be accepted.

Replace the contents of the Auth Key/Hash field with the
authentication key selected by the received Auth Key ID field.  If
the SHA1 hash of the entire BFD Control packet is equal to the
received value of the Auth Key/Hash field, the received packet
MUST be accepted.  Otherwise (the hash does not match the Auth
Key/Hash field), the received packet MUST be discarded.

It should say:

Replace the contents of the Auth Key/Hash field with the
authentication key selected by the received Auth Key ID field.  If
the SHA1 hash of the entire BFD Control packet is not equal to the
received value of the Auth Key/Hash field, the received packet
MUST be discarded.

Otherwise, the packet MUST be accepted, bfd.AuthSeqKnown MUST be set to
1, and bfd.RcvAuthSeq MUST be set to the value of the received
Sequence Number field.

Notes:

1. Don't manipulate bfd.AuthSeqKnown and bfd.RcvAuthSeq before Auth Key/Hash check.
2. Explicitly mention what bfd.AuthSeqKnown and bfd.RcvAuthSeq must be set to in both cases (bfd.AuthSeqKnown is 0 and bfd.AuthSeqKnown is 1).

Based on email exchange: https://mailarchive.ietf.org/arch/msg/rtg-bfd/lDxFfNpqo4kwuNEUY0AbjMBb8JU/

(See also https://mailarchive.ietf.org/arch/msg/rtg-bfd/Ngf3Chmpy_EqNPlmuMZOslayy2E/)

Errata ID: 6926
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Glebs Ivanovskis
Date Reported: 2022-04-06
Verifier Name: RFC Editor
Date Verified: 2022-04-07

Section 6.8.6 says:

Set bfd.RemoteState to the value of the State (Sta) field.

It should say:

Set bfd.RemoteSessionState to the value of the State (Sta) field.

Notes:

The variable bfd.RemoteState is not defined in section 6.8.1 and is only mentioned once in the entire document. It is likely a typo and a similarly named bfd.RemoteSessionState was meant instead.

RFC 5881, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", June 2010

Source of RFC: bfd (rtg)

Errata ID: 2293
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Dave Katz
Date Reported: 2010-06-02
Verifier Name: Adrian Farrel
Date Verified: 2010-06-05

Section 8 says:

Ports 3784 and 3875 were assigned by IANA for use with the BFD 
Control and BFD Echo protocols, respectively.

It should say:

Ports 3784 and 3785 were assigned by IANA for use with the BFD 
Control and BFD Echo protocols, respectively.

Notes:

That is:
s/3875/3785/

A typo in the hastily-added IANA Considerations section. The normative text is correct, so this error is less onerous than it could have been, happily.

RFC 5884, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", June 2010

Note: This RFC has been updated by RFC 7726

Source of RFC: bfd (rtg)

Errata ID: 5085
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Balaji Rajagopalan
Date Reported: 2017-08-11
Verifier Name: Deborah Brungard
Date Verified: 2017-12-15

Section 6 says:

   On receipt of the LSP Ping Echo request message, the egress LSR MUST
   send a BFD Control packet to the ingress LSR, if the validation of
   the FEC in the LSP Ping Echo request message succeeds.  This BFD
   Control packet MUST set the Your Discriminator field to the
   discriminator received from the ingress LSR in the LSP Ping Echo
   request message.  The egress LSR MAY respond with an LSP Ping Echo
   reply message that carries the local discriminator assigned by it for
   the BFD session.  The local discriminator assigned by the egress LSR
   MUST be used as the My Discriminator field in the BFD session packets
   sent by the egress LSR.

   The ingress LSR follows the procedures in [BFD] to send BFD Control
   packets to the egress LSR in response to the BFD Control packets
   received from the egress LSR.  The BFD Control packets from the
   ingress to the egress LSR MUST set the local discriminator of the
   egress LSR, in the Your Discriminator field.  The egress LSR
   demultiplexes the BFD session based on the received Your
   Discriminator field.  As mentioned above, the egress LSR MUST send
   Control packets to the ingress LSR with the Your Discriminator field
   set to the local discriminator of the ingress LSR.  The ingress LSR
   uses this to demultiplex the BFD session.

It should say:

On receipt of the LSP Ping Echo request message, the egress LSR
MUST send a BFD Control packet to the ingress LSR, if the
validation of the FEC in the LSP Ping Echo request message
succeeds.  This BFD Control packet MUST set the Your Discriminator
field to the discriminator received from the ingress LSR in the LSP
Ping Echo request message. The local discriminator assigned by the
egress LSR MUST be used as the My Discriminator field in the BFD
session packets sent by the egress LSR.

The ingress LSR follows the procedures in [BFD] to send BFD Control
packets to the egress LSR in response to the BFD Control packets
received from the egress LSR.  The BFD Control packets from the
ingress to the egress LSR MUST set the local discriminator of the
egress LSR in the Your Discriminator field. The egress LSR
demultiplexes the BFD session based on the received Your
Discriminator field. As mentioned above, the egress LSR MUST send
Control packets to the ingress LSR with the Your Discriminator field
set to the local discriminator of the ingress LSR.The ingress LSR
uses this to demultiplex the BFD session.

The egress LSR processes the LSP Ping Echo request message in
accordance with the procedures defined in [RFC 8029]. The LSP Ping
Echo reply message generated by the egress LSR MAY carry the local
discriminator assigned by it for the BFD session, as specified in
section 6.1.

Notes:

Submitter:
It is not clear from the original text which of the following is optional:
- The egress MUST send a reply, but the discriminator in the reply is optional
- The reply itself is optional

Technically, the reply cannot be optional, because the egress needs to report LSP-Ping verification status to the ingress.

The proposed text recommends to include BFD discriminator in the reply. This was the intent of the original text.

Verifier:
The original Errata proposed correcting the last sentences of the second paragraph of Section 6. After discussion in the working group, it was agreed both the second and third paragraphs shown above of Section 6 needed to be revised to the three paragraphs of the corrected text shown above.

RFC 5888, "The Session Description Protocol (SDP) Grouping Framework", June 2010

Note: This RFC has been updated by RFC 8843, RFC 9143

Source of RFC: mmusic (rai)

Errata ID: 2313
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-06-24
Verifier Name: Robert Sparks
Date Verified: 2010-06-24

Section 9.2.1 says:

9.2.1.  Example

   The example below shows how the callee refuses a media stream offered
   by the caller by setting its port number to zero.  The "mid" value
   corresponding to that media stream is removed from the "group" value
   in the answer.

   SDP description in the INVITE from caller to callee:

          [...]

|  SDP description in the INVITE from callee to caller:

          [...]

It should say:

9.2.1.  Example

   The example below shows how the callee refuses a media stream offered
   by the caller by setting its port number to zero.  The "mid" value
   corresponding to that media stream is removed from the "group" value
   in the answer.

   SDP description in the INVITE from caller to callee:

          [...]

|  SDP description in the "200 OK" from callee to caller:

          [...]

Notes:

Rationale: In the scenario described by the prose,
the SDP answer is carried in the non-provisional
response to the INVITE, in this case a "200 OK",
not in another INVITE. The latter (using a re-INVITE)
is a different scenario. (Note that a re-INVITE would
likely contain an SDP offer, where port 0 is not allowed.)

RFC 5890, "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", August 2010

Source of RFC: idnabis (app)

Errata ID: 4695
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Juan Altmayer Pizzorno
Date Reported: 2016-05-17
Verifier Name: Alexey Melnikov
Date Verified: 2016-10-07

Section 2.3.2.1 says:

expansion of the A-label form to a U-label may produce strings that are
much longer than the normal 63 octet DNS limit (potentially up to 252
characters)
^^^^^^^^^

It should say:

expansion of the A-label form to a U-label may produce strings that are
much longer than the normal 63 octet DNS limit (potentially up to 252
octets)
^^^^^

Notes:

The sentence should have used "octets" instead of "characters".

A separate erratum was files for possible tightening of the upper bound in a future revision of this document.

Errata ID: 4696
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Juan Altmayer Pizzorno
Date Reported: 2016-05-17
Verifier Name: Alexey Melnikov
Date Verified: 2016-10-07

Section 4.2 says:

Because A-labels (the form actually used in the
DNS) are potentially much more compressed than UTF-8 (and UTF-8 is,
in general, more compressed that UTF-16 or UTF-32), U-labels that
obey all of the relevant symmetry (and other) constraints of these
documents  may be quite a bit longer, potentially up to 252 characters
(Unicode code points).

It should say:

Because A-labels (the form actually used in the
DNS) are potentially much more compressed than UTF-8 (and UTF-8 is,
in general, more compressed that UTF-16 or UTF-32), U-labels that
obey all of the relevant symmetry (and other) constraints of these
documents  may be quite a bit longer, potentially up to 252 octets.
                                                        ^^^^^^^^^^

Notes:

Similar to Erratum 4695.

Errata ID: 7291
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Klensin
Date Reported: 2022-12-26
Verifier Name: Murray Kucherawy
Date Verified: 2023-06-01

Throughout the document, when it says:

Request for Comments: 5890
Obsoletes: 3490
Category: Standards Track

It should say:

Request for Comments: 5890
Obsoletes: 3490
Updates: 4343
Category: Standards Track

Notes:

I have no idea whether this correction is Editorial or Technical , nor what to use as a Section indication. However...

RFC 5890 (or IDNA2008 more generally), should have updated RFC 4343 and the IDN discussion in its Section 5. The latter references the IDNA2003 documents and makes some statements that are, at best, confusing in the context of IDNA2008.

See the extended notes for RFC 4343 in https://www.rfc-editor.org/errata/eid7290 for more discussion and details.

Recommendation: Hold for document update unless this appears to anyone to be a serious problem, in which case a separate RFC, using the notes on Errata ID 7290 as a starting point, may be in order.

[AD Note:] Marking this as Verified, and will direct the RFC Editor to update the metadata about both documents.

RFC 5892, "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)", August 2010

Note: This RFC has been updated by RFC 8753

Source of RFC: idnabis (app)

Errata ID: 3312
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Patrik Fältström
Date Reported: 2012-08-09
Verifier Name: Barry Leiba
Date Verified: 2012-08-09

Section A and A.1 says:

In A:

Code point:

The code point, or code points, to which this rule is to be
applied.  Normally, this implies that if any of the code points in
a label is as defined, then the rules should be applied.  If
evaluated to True, the code point is OK as used; if evaluated to
False, it is not OK.

In A.1:

Rule Set:
  False;
  If Canonical_Combining_Class(Before(cp)) .eq.  Virama Then True;
  If RegExpMatch((Joining_Type:{L,D})(Joining_Type:T)*\u200C
    (Joining_Type:T)*(Joining_Type:{R,D})) Then True;

It should say:

In A:

Code point:

The code point, or code points, to which this rule is to be
applied.  Normally, this implies that if any of the code points in
a label is as defined, then the rules should be applied.  If
evaluated to True, the code point is OK as used; if evaluated to
False, it is not OK.

For the rule to be evaluated to True for the label, it MUST be 
evaluated separately for every occurrence of the Code point in the 
label; each of those evaluations must result in True.

In A.1:

Rule Set:
  False;
  If Canonical_Combining_Class(Before(cp)) .eq.  Virama Then True;
  If cp .eq. \u200C And RegExpMatch((Joining_Type:{L,D})(Joining_Type:T)*cp
    (Joining_Type:T)*(Joining_Type:{R,D})) Then True;

Notes:

The original text did not make it clear whether the actual rule is to be applied once for every occurrence of the code point in the label. This is a regular expression that can be interpreted in multiple ways, plus it does not take into account the case where more than one U+200C exists in a label.

RFC 5896, "Generic Security Service Application Program Interface (GSS-API): Delegate if Approved by Policy", June 2010

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 5749
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jeffrey Altman
Date Reported: 2019-06-08
Verifier Name: Benjamin Kaduk
Date Verified: 2019-11-26

Throughout the document, when it says:

Updates: 4120

It should say:

Updates: 2743, 2744, 4120, and 4121

Notes:

The content of RFC5896 modifies the technical meaning of all four RFCs not just 4120.

RFC 5905, "Network Time Protocol Version 4: Protocol and Algorithms Specification", June 2010

Note: This RFC has been updated by RFC 7822, RFC 8573, RFC 9109

Source of RFC: ntp (int)

Errata ID: 3007
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Danny Mayer
Date Reported: 2011-10-28
Verifier Name: Brian Haberman
Date Verified: 2012-04-27

Section 7.4 says:

b.  For kiss code RATE, the client MUST immediately reduce its
       polling interval to that server and continue to reduce it each
       time it receives a RATE kiss code.

It should say:

b.  For kiss code RATE, the client MUST immediately increase its
       polling interval to that server and continue to increase it each
       time it receives a RATE kiss code.

Notes:

The client needs to poll the server for new timestamps less often

Errata ID: 3627
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tal Mizrahi
Date Reported: 2013-05-17
Verifier Name: Brian Haberman
Date Verified: 2014-05-16

Section 7.5 says:

In NTPv4, one or more extension fields can be inserted after the 
header and before the MAC, which is always present when an extension 
field is present.

It should say:

In NTPv4, one or more extension fields can be inserted after the 
header and before the MAC, if a MAC is present. If a MAC is not 
present, one or more extension fields can be inserted after the 
header, according to the following rules:
o If the packet includes a single extension field, the length of the 
  extension  field MUST be at least 7 words, i.e., at least 28 octets.
o If the packet includes more than one extension field, the length of 
  the last extension field MUST be at least 28 octets. The length of 
  the other extension fields in this case MUST be at least 16 octets 
  each.

Notes:

The usage of NTP extension fields without authentication is aligned with Section 10 of RFC 5906:

The extension field parser initializes a pointer to the first octet beyond the NTP packet header and calculates the number of octets remaining to the end of the packet If the remaining length is 20 (128-bit digest plus 4-octet key ID) or 22 (160-bit digest plus 4-octet key ID), the remaining data are the MAC and parsing is complete. If the remaining length is greater than 22, an extension field is present. If the remaining length is less than 8 or not a multiple of 4, a format error has occurred and the packet is discarded; otherwise, the parser increments the pointer by the extension field length and then uses the same rules as above to determine whether a MAC is present or another extension field.

Errata ID: 4504
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Miroslav Lichvar
Date Reported: 2015-10-15
Verifier Name: Erik Kline
Date Verified: 2022-07-27

Section 7.3 says:

   LI Leap Indicator (leap): 2-bit integer warning of an impending leap
   second to be inserted or deleted in the last minute of the current
   month with values defined in Figure 9.

           +-------+----------------------------------------+
           | Value | Meaning                                |
           +-------+----------------------------------------+
           | 0     | no warning                             |
           | 1     | last minute of the day has 61 seconds  |
           | 2     | last minute of the day has 59 seconds  |

It should say:

   LI Leap Indicator (leap): 2-bit integer warning of an impending leap
   second to be inserted or deleted in the last minute of the current
   day with values defined in Figure 9.

           +-------+----------------------------------------+
           | Value | Meaning                                |
           +-------+----------------------------------------+
           | 0     | no warning                             |
           | 1     | last minute of the day has 61 seconds  |
           | 2     | last minute of the day has 59 seconds  |

Notes:

There is an inconsistency (day vs month) between the LI description and the description of values in the Figure 9. Few paragraphs before that text there is: Except for a minor variation when using the IPv6 address family, these fields are backwards compatible with NTPv3.

If it was month instead of day it would not be compatible with RFC 1305 (NTPv3) and RFC 4330 (SNTPv4), which were obsoleted by RFC 5905.

Errata ID: 5600
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Takashi Nakamoto
Date Reported: 2019-01-15
Verifier Name: Erik Kline
Date Verified: 2022-08-29

Section 10. says:

   Let the first stage offset in the sorted list be theta_0; then, for
   the other stages in any order, the jitter is the RMS average

                          +-----                 -----+^1/2
                          |  n-1                      |
                          |  ---                      |
                  1       |  \                     2  |
      psi   =  -------- * |  /    (theta_0-theta_j)   |
                (n-1)     |  ---                      |
                          |  j=1                      |
                          +-----                 -----+

It should say:

   Let the first stage offset in the sorted list be theta_0; then, for
   the other stages in any order, the jitter is the RMS average

               +-----                             -----+^1/2
               |              n-1                      |
               |              ---                      |
               |    1         \                     2  |
      psi   =  | -------- *   /    (theta_0-theta_j)   |
               |  (n-1)       ---                      |
               |              j=1                      |
               +-----                             -----+

Notes:

The formula to calculate jitter "psi" in section "10. Clock Filter Algorithm" is incorrect, and also inconsistent with the formulate to calculate "psi_s" in section "11.2.2. Cluster Algorithm".

"psi" is defined as RMS average, so the term 1/(n-1) should be within [ ]^1/2 block.

Errata ID: 5601
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Takashi Nakamoto
Date Reported: 2019-01-15
Verifier Name: Erik Kline
Date Verified: 2022-09-26

Section 11.2.3. says:

                  | s.rootdisp  <-- p.epsilon_r + p.epsilon + |
                  |                 p.psi + PHI * (s.t - p.t) |
                  |                 + |THETA|                 |
                  | s.refid     <-- p.refid                   |
                  | s.reftime   <-- p.reftime                 |
                  | s.t         <-- p.t                       |
                  +-------------------------------------------+

                    Figure 25: System Variables Update

   There is an important detail not shown.  The dispersion increment
   (p.epsilon + p.psi + PHI * (s.t - p.t) + |THETA|) is bounded from
   below by MINDISP.

It should say:

                  | s.rootdisp  <-- p.epsilon_r + p.epsilon + |
                  |                 p.psi + PHI * (t_s - p.t) |
                  |                 + |THETA|                 |
                  | s.refid     <-- p.refid                   |
                  | s.reftime   <-- p.reftime                 |
                  | s.t         <-- p.t                       |
                  +-------------------------------------------+

                    Figure 25: System Variables Update

   where t_s is the time when the system variables are updated.
   There is an important detail not shown.  The dispersion increment
   (p.epsilon + p.psi + PHI * (t_s - p.t) + |THETA|) is bounded from
   below by MINDISP.

Notes:

In the same section, it is said that "By rule, an update is discarded if its time of arrival p.t is not strictly later than the last update used s.t." This means that p.t > s.t when the system variable is updated. Hence, (s.t - p.t) is negative. It may lead to a negative dispersion, but, by definition, the dispersion cannot be negative. So, the original formula should be wrong.

Because the dispersion is defined as the value that grows at constant rate PHI, s.rootdisp should be

s.rootdisp <-- p.epsilon_r + p.epsilon + p.psi + PHI * (t_s - p.t) + |THETA|

where t_s is the time when the system variables are updated. The symbol t_s is arbitrary because it is not defined in other places.

---

[verifier notes]

From https://mailarchive.ietf.org/arch/msg/ntp/CHcBo-my1WdRg5PbhSU8aFlIS_k/ :

"""
... the reported section with is indeed erroneous, and s.t
should be replaced with c.t, defined in section 9.1/12. The attached
note seems inaccurate in the statement that a new name (t_s) is
needed, since c.t covers the required concept...
"""

Errata ID: 5978
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: David Verbree
Date Reported: 2020-02-08
Verifier Name: Erik Kline
Date Verified: 2022-09-26

Section A.5.1.1. says:

    /*
        * Verify valid root distance.
        */
    if (r->rootdelay / 2 + r->rootdisp >= MAXDISP || p->reftime >
        r->xmt)
            return;                 /* invalid header values */

It should say:

    /*
        * Verify valid root distance.
        */
    if (p->rootdelay / 2 + p->rootdisp >= MAXDISP || p->reftime >
        r->xmt)
            return;                 /* invalid header values */

Notes:

The r->rootdelay and r->rootdisp are the received values not in double format and therefore, should not be compared against MAXDISP. Use the p->rootdelay and p->rootdisp instead which have already been converted to double via FP2D macro.

---

[verifier notes]

See also https://mailarchive.ietf.org/arch/msg/ntp/Cbg3sOhChyfenYoj7UG5wCymFMU/

Errata ID: 6207
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tam Phan
Date Reported: 2020-06-08
Verifier Name: Erik Kline
Date Verified: 2022-09-26

Section A.5.5.1 says:

/*
         * Find the largest contiguous intersection of correctness
         * intervals.  Allow is the number of allowed falsetickers;
         * found is the number of midpoints.  Note that the edge values
         * are limited to the range +-(2 ^ 30) < +-2e9 by the timestamp
         * calculations.
         */
        low = 2e9; high = -2e9;
        for (allow = 0; 2 * allow < n; allow++) {

                /*
                 * Scan the chime list from lowest to highest to find
                 * the lower endpoint.
                 */
                found = 0;
                chime = 0;
                for (i = 0; i < n; i++) {
                        chime -= s.m[i].type;
                        if (chime >= n - found) {
                                low = s.m[i].edge;
                                break;
                        }
                        if (s.m[i].type == 0)
                                found++;
                }

                /*
                 * Scan the chime list from highest to lowest to find
                 * the upper endpoint.
                 */
                chime = 0;
                for (i = n - 1; i >= 0; i--) {
                        chime += s.m[i].type;
                        if (chime >= n - found) {
                                high = s.m[i].edge;
                                break;
                        }
                        if (s.m[i].type == 0)
                                found++;
                }




Mills, et al.                Standards Track                   [Page 91]
 
RFC 5905                   NTPv4 Specification                 June 2010


                /*
                 * If the number of midpoints is greater than the number
                 * of allowed falsetickers, the intersection contains at
                 * least one truechimer with no midpoint.  If so,
                 * increment the number of allowed falsetickers and go
                 * around again.  If not and the intersection is
                 * non-empty, declare success.
                 */
                if (found > allow)
                        continue;

                if (high > low)
                        break;
        }

It should say:

/*
         * Find the largest contiguous intersection of correctness
         * intervals.  Allow is the number of allowed falsetickers;
         * found is the number of midpoints.  Note that the edge values
         * are limited to the range +-(2 ^ 30) < +-2e9 by the timestamp
         * calculations.
         */
        low = 2e9; high = -2e9;
        for (allow = 0; 2 * allow < n; allow++) {

                /*
                 * Scan the chime list from lowest to highest to find
                 * the lower endpoint.
                 */
                found = 0;
                chime = 0;
                for (i = 0; i < n; i++) {
                        chime -= s.m[i].type;
                        if (chime >= n - allow) {
                                low = s.m[i].edge;
                                break;
                        }
                        if (s.m[i].type == 0)
                                found++;
                }

                /*
                 * Scan the chime list from highest to lowest to find
                 * the upper endpoint.
                 */
                chime = 0;
                for (i = n - 1; i >= 0; i--) {
                        chime += s.m[i].type;
                        if (chime >= n - allow) {
                                high = s.m[i].edge;
                                break;
                        }
                        if (s.m[i].type == 0)
                                found++;
                }




Mills, et al.                Standards Track                   [Page 91]
 
RFC 5905                   NTPv4 Specification                 June 2010


                /*
                 * If the number of midpoints is greater than the number
                 * of allowed falsetickers, the intersection contains at
                 * least one truechimer with no midpoint.  If so,
                 * increment the number of allowed falsetickers and go
                 * around again.  If not and the intersection is
                 * non-empty, declare success.
                 */
                if (found > allow)
                        continue;

                if (high > low)
                        break;
        }

Notes:

The algorithm described in section 11.2.3 is not properly written here; we compare c to n - f in the algorithm, but f != found; f corresponds to the "allowed" falsetickers. This algorithm implementation results in the lower and upper bounds unchanging throughout the described loop, but this change should fix the implementation.

---

[INT AD notes]

For analysis and further discussion see https://mailarchive.ietf.org/arch/msg/ntp/zJNoHvZ08SPX-3kwflMK7PIReFo/ especially the one or two addition issues identified.

Errata ID: 6550
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Perry Lorier
Date Reported: 2021-04-17
Verifier Name: Erik Kline
Date Verified: 2022-08-29

Section A.5.2 says:

        for (i = 0; i < NSTAGE; i++) {
                p->disp += f[i].disp / (2 ^ (i + 1));
                p->jitter += SQUARE(f[i].offset - f[0].offset);
        }

It should say:

        for (i = 0; i < NSTAGE; i++) {
                p->disp += f[i].disp / (1 << (i + 1));
                p->jitter += SQUARE(f[i].offset - f[0].offset);
        }

Notes:

^ is the xor operator in C, not the exponent operator. 2 xor (i+1) will be zero when i == 1, causing a division by zero error.

Errata ID: 4019
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Teruaki Kitasuka
Date Reported: 2014-06-20
Verifier Name: Brian Haberman
Date Verified: 2014-06-20

Section 11.2.1 says:

   An
   example of this calculation is shown by the rootdist() routine in
   Appendix A.5.1.1.

It should say:

   An
   example of this calculation is shown by the root_dist() routine in
   Appendix A.5.5.2.

Notes:

No rootdist() routine is in Appendix. root_dist() appears in Appendix A.5.5.2.

Errata ID: 4121
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marina Gertsvolf
Date Reported: 2014-09-23
Verifier Name: Brian Haberman
Date Verified: 2014-10-21

Section 8 says:

In the exchange above, a packet is duplicate or
   replay if the transmit timestamp t3 in the packet matches the org
   state variable T3. 

It should say:

In the exchange above, a packet is duplicate or
   replay if the transmit timestamp t3 in the packet matches the org
   state variable. 

Notes:

The org state variable for peer A has not yet been assigned the value T3.

Errata ID: 4680
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Riccardo Brama
Date Reported: 2016-04-29
Verifier Name: Erik Kline
Date Verified: 2022-07-27

Section 6, Fig 3 says:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Era Number                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Era Offset                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                           Fraction                            |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                              NTP Date Format

It should say:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Era Number                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Era Offset                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                           Fraction                            +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                              NTP Date Format

Notes:

This allows to better appreciate only two 32b rows really form the Fraction part, leading to an overall type length of 128b instead of 160b as it could otherwise be misunderstood in the original figure.

---

The "+" vs "|" on the Fraction line would seem to improve consistency with packet layouts in other documents.

Errata ID: 5104
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Denis Ovsienko
Date Reported: 2017-08-30
Verifier Name: Erik Kline
Date Verified: 2022-07-27

Section 7.3, Fig 8 says:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Key Identifier                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                            dgst (128)                         |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Key Identifier                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                       Message Digest (128)                    |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

As the text before the figure explains, the last field is called "Message Digest", which is consistent with the rest of the document. In this document "dgst" and "mac" mean two protocol variables associated with this packet field.

---

Note: edited to clarify 4 32bit words, rather than 3 rows.

Errata ID: 5189
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marcel Telka
Date Reported: 2017-11-28
Verifier Name: Erik Kline
Date Verified: 2022-09-26

Section 6 says:

   | 31 Dec 1999 | 51,543     | 0   | 3,155,587,200 | Last day 20th    |
   |             |            |     |               | Century          |

It should say:

   | 31 Dec 2000 | 51,909     | 0   | 3,187,209,600 | Last day 20th    |
   |             |            |     |               | Century          |

Notes:

20th Century was from 1901 to 2000.

---

[verifier notes]

See also: https://mailarchive.ietf.org/arch/msg/ntp/Cbg3sOhChyfenYoj7UG5wCymFMU/

Errata ID: 7555
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sylvain Etienne
Date Reported: 2023-06-28
Verifier Name: RFC Editor
Date Verified: 2023-06-28

Section 4 says:

Under the auspices of the
   Metre Convention of 1865, in 1975 the CGPM [CGPM] strongly endorsed
   the use of UTC as the basis for civil time.

It should say:

Under the auspices of the
   Metre Convention of 1875, in 1975 the CGPM [CGPM] strongly endorsed
   the use of UTC as the basis for civil time.

Notes:

The Metre convention was signed on 20 May 1875 as stated on https://www.bipm.org/en/metre-convention.

RFC 5906, "Network Time Protocol Version 4: Autokey Specification", June 2010

Source of RFC: ntp (int)

Errata ID: 6402
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2021-01-20
Verifier Name: Erik Kline
Date Verified: 2022-07-27

Section Appendix J says:

   CertificateSerialNumber
   SET { ::= INTEGER
           Validity ::= SEQUENCE {
                   notBefore              UTCTime,
                   notAfter               UTCTime
           }
   }

It should say:

   CertificateSerialNumber ::= INTEGER

   Validity ::= SEQUENCE {
                   notBefore              UTCTime,
                   notAfter               UTCTime
   }

Notes:

The original ASN.1 will not compile.

Errata ID: 3345
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: liyh
Date Reported: 2012-09-12
Verifier Name: Brian Haberman
Date Verified: 2012-09-12

Section 5 says:

 Certificate exchange.[...]Completion of this exchange lights the VAL bit as described below.

It should say:

Certificate exchange.[...]Completion of this exchange lights the CERT bit as described below.

Errata ID: 3346
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: liyh
Date Reported: 2012-09-12
Verifier Name: Brian Haberman
Date Verified: 2012-09-12

Section 5 says:

Identity exchange.[...] Completion of this exchange lights the IFF bit as described below.

It should say:

Identity exchange.[...] Completion of this exchange lights the VRFY bit as described below.

Errata ID: 3349
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: liyh
Date Reported: 2012-09-12
Verifier Name: Brian Haberman
Date Verified: 2012-09-12

Section 5 says:

Leapseconds exchange.  [...]Completion of this exchange lights the LPT bit as described below.

It should say:

Leapseconds exchange.  [...]Completion of this exchange lights the LEAP bit as described below.

Notes:

refer to 11.1

Errata ID: 4026
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tal Mizrahi
Date Reported: 2014-06-25
Verifier Name: Brian Haberman
Date Verified: 2014-07-01

Section 10 says:

One or more extension fields follow the NTP packet header and the
   last followed by the MAC.  The extension field parser initializes a
   pointer to the first octet beyond the NTP packet header and
   calculates the number of octets remaining to the end of the packet.
   If the remaining length is 20 (128-bit digest plus 4-octet key ID) or
   22 (160-bit digest plus 4-octet key ID), the remaining data are the
   MAC and parsing is complete.  If the remaining length is greater than
   22, an extension field is present.  If the remaining length is less
   than 8 or not a multiple of 4, a format error has occurred and the
   packet is discarded; otherwise, the parser increments the pointer by
   the extension field length and then uses the same rules as above to
   determine whether a MAC is present or another extension field.

It should say:

One or more extension fields follow the NTP packet header and the
   last followed by the MAC.  The extension field parser initializes a
   pointer to the first octet beyond the NTP packet header and
   calculates the number of octets remaining to the end of the packet.
   If the remaining length is 20 (128-bit digest plus 4-octet key ID) or
   24 (160-bit digest plus 4-octet key ID), the remaining data are the
   MAC and parsing is complete.  If the remaining length is greater than
   24, an extension field is present.  If the remaining length is less
   than 8 or not a multiple of 4, a format error has occurred and the
   packet is discarded; otherwise, the parser increments the pointer by
   the extension field length and then uses the same rules as above to
   determine whether a MAC is present or another extension field.

Notes:

The original text stated that a MAC is present if the remaining length is 20 octets or 22 octets. This was a typo; the correct statement is that a MAC is present if the remaining length is 20 octets or *24 octets*.

RFC 5908, "Network Time Protocol (NTP) Server Option for DHCPv6", June 2010

Source of RFC: ntp (int)

Errata ID: 3624
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Francois-Xavier Le Bail
Date Reported: 2013-05-16
Verifier Name: Brian Haberman
Date Verified: 2013-05-16

Section 4 says:

[...]
The currently defined time source suboptions are
NTP_OPTION_SRV_ADDR, NTP_OPTION_SRV_MC_ADDR, and NTP_OPTION_SRV_FQDN.
[...]

It should say:

[...]
The currently defined time source suboptions are
NTP_SUBOPTION_SRV_ADDR, NTP_SUBOPTION_MC_ADDR, and NTP_SUBOPTION_SRV_FQDN.
[...]

Notes:

It does not appear clearly if the type of error must be technical or editorial.

The three suboptions are defined in the sections 4.1, 4.2 and 4.3. Their names are differents of those used in second paragraph of the section 4.

Iana standardized the 4.1, 4.2 and 4.3 names. see:
http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xml
[...]
Value Name Reference
1 NTP_SUBOPTION_SRV_ADDR [RFC5908]
2 NTP_SUBOPTION_MC_ADDR [RFC5908]
3 NTP_SUBOPTION_SRV_FQDN [RFC5908]
[...]

RFC 5910, "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)", May 2010

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 2597
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: NOGUCHI Shoji
Date Reported: 2010-11-01
Verifier Name: Alexey Melnikov
Date Verified: 2010-11-04

Section 5.2.5 says:

   Example <update> Command,
                 Removing all DS and Key Data Using <secDNS:rem>
                 with <secDNS:all>:

   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
   C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   C:  <command>
   C:    <update>
   C:      <domain:update
   C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   C:        <domain:name>example.com</domain:name>
   C:      </domain:update>
   C:    </update>
   C:    <extension>
   C:      <secDNS:update urgent="true"
|  C:       xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.0">
   C:        <secDNS:rem>
   C:          <secDNS:all>true</secDNS:all>
   C:        </secDNS:rem>
   C:      </secDNS:update>
   C:    </extension>
   C:    <clTRID>ABC-12345</clTRID>
   C:  </command>
   C:</epp>

It should say:

   Example <update> Command,
                 Removing all DS and Key Data Using <secDNS:rem>
                 with <secDNS:all>:

   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
   C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   C:  <command>
   C:    <update>
   C:      <domain:update
   C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   C:        <domain:name>example.com</domain:name>
   C:      </domain:update>
   C:    </update>
   C:    <extension>
   C:      <secDNS:update urgent="true"
|  C:       xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
   C:        <secDNS:rem>
   C:          <secDNS:all>true</secDNS:all>
   C:        </secDNS:rem>
   C:      </secDNS:update>
   C:    </extension>
   C:    <clTRID>ABC-12345</clTRID>
   C:  </command>
   C:</epp>

Notes:

secDNS-1.0 -> secDNS-1.1

RFC 5911, "New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME", June 2010

Note: This RFC has been updated by RFC 6268

Source of RFC: smime (sec)

Errata ID: 2612
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jim Schaad
Date Reported: 2010-11-06
Verifier Name: Tim Polk
Date Verified: 2010-11-30

Section 6 and others says:

ct-Data CONTENT-TYPE ::= {OCTET STRING IDENTIFIED BY id-data}

It should say:

ct-Data CONTENT-TYPE ::= {IDENTIFIED BY id-data}

Notes:

Due to a confusion in the part of the author's head that resulted from the difference the way that encapsulated content types are encoded between PKCS#7 and CMS, I put the type of OCTET STRING in this location. Since the OCTET STRING is explicitly included by the the encapulsated content type now, there should be an absence of a data type for the content type of id-data. Making this change however requires that some additional changes be made. It is not possible to just omit the type for a TYPE-IDENTIFIER type so a new class definition is required for CONTENT-TYPE. Unfortionately it is also not possible to simply omit the type from the syntax provided for the new content type as the parser is defined as being opertunistic rather than pessimistic by the ASN.1 syntax. Thus the tag IDENTIFIER would be consumed as a type and the rest of the parsing would fail. We there need to make the following changes:

1. Define a new object class of CONTENT-TYPE as
CONTENT-TYPE ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Type OPTIONAL
} WITH SYNTAX {
[TYPE &Type] IDENTIFIED BY &id
}

2. We make the change to the defintion of ct-Data as above so that it no longer has an implied ASN.1 type associated with the object identifier

3. We then change all locations where a new content type is defined as follows:
ct-Foo CONTENT-TYPE ::= {Foo IDENTIFIED BY id-Foo}
becomes
ct-Foo CONTENT-TYPE ::= {TYPE Foo IDENTIFIED BY id-Foo}

Changes 1 and 2 will occur in the module for RFC 3851 (now RFC 5281)
Change 3 will occur in a number of different modules including modules that have been published independently since this document was released.

Errata ID: 2648
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jim Schaad
Date Reported: 2010-11-29
Verifier Name: Tim Polk
Date Verified: 2010-11-30

Section Section 6 says:

  FROM AttributeCertificateVersion1-2009
      { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
      smime(16) modules(0) id-mod-v1AttrCert-02(49) } ;

It should say:

  FROM AttributeCertificateVersion1-2009
      { iso(1) member-body(2) dod(6) internet(1) security(5)
        mechanisms(5) pkix(7) id-mod(0) id-mod-v1AttrCert-02(49) } ;

Notes:

The wrong oid arc was used for the module identification. A similar changes is also being reported for RFC 5912

Errata ID: 2665
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jim Schaad
Date Reported: 2010-12-09
Verifier Name: Tim Polk
Date Verified: 2011-03-26

Section Section 6 says:

FROM AttributeCertificateVersion1-2009
      { iso(1) member-body(2) dod(6) internet(1) security(5)
        mechanisms(5) pkix(7) id-mod(0) id-mod-v1AttrCert-02(49) } ;

It should say:

FROM AttributeCertificateVersion1-2009
      { iso(1) identified-organization(3) dod(6) internet(1) security(5)
        mechanisms(5) pkix(7) id-mod(0) id-mod-v1AttrCert-02(49) } ;

Notes:

One incorrect node in the arc was noted from the last errata.

Errata ID: 3128
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2012-02-18
Verifier Name: Sean Turner
Date Verified: 2012-03-05

Section 8 says:

   ContentInfo
   FROM CryptographicMessageSyntax2004
       { iso(1) member-body(2) us(840) rsadsi(113549)
       pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2004-02(41) } ;

It should say:

   ContentInfo
   FROM CryptographicMessageSyntax-2009
       {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
        smime(16) modules(0) id-mod-cms-2004-02(41)};

Notes:

ContentInfo to be imported from the module that is defined elsewhere in RFC 5911.

RFC 5912, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", June 2010

Note: This RFC has been updated by RFC 6960, RFC 9480

Source of RFC: pkix (sec)

Errata ID: 2839
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Carl Wallace
Date Reported: 2011-06-16
Verifier Name: Sean Turner
Date Verified: 2011-07-26

Section 14 says:

Notes:

anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificatePolicies 0 } does not appear in the PKIX1Implicit-2009 module. It appears in the body of RFC 5280 and in the corresponding ASN.1 module in RFC 5280.

Errata ID: 2649
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jim Schaad
Date Reported: 2010-11-29
Verifier Name: Tim Polk
Date Verified: 2010-11-30

Section 7, says:

  AttributeCertificateVersion1-2009
      { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
      smime(16) modules(0) id-mod-v1AttrCert-02(49) } ;

It should say:

AttributeCertificateVersion1-2009
      { iso(1) member-body(2) dod(6) internet(1) security(5)
        mechanisms(5) pkix(7) id-mod(0) id-mod-v1AttrCert-02(49) } ;

Notes:

Oid was used from the wrong arc. THis change corrects the arc used for the OID number.

Errata ID: 3130
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2012-02-19
Verifier Name: Sean Turner
Date Verified: 2012-03-05

Throughout the document, when it says:

  ct-foo CONTENT-TYPE ::=
      { FooType IDENTIFIED BY id-ct-foo }

It should say:

  ct-foo CONTENT-TYPE ::=
      { TYPE FooType IDENTIFIED BY id-ct-foo }

Notes:

Of course, 'ct-foo', 'FooType', and 'id-ct-foo' need to be replaced as appropriate for the use of CONTENT-TYPE in RFC 5912. CONTENT-TYPE is imported from a module defined in RFC 5911, and errata 2612 makes a change to that definition. Therefore, 'TYPE' needs to be added each time a content type is defined to align with errata 2612.

The definitions that need to be updated are:
ct-encKeyWithID,
ct-scvp-certValRequest,
ct-scvp-certValResponse,
ct-scvp-valPolRequest,
ct-scvp-valPolResponse,
ct-PKIData, and
ct-PKIResponse.

Errata ID: 3259
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: James Manger
Date Reported: 2012-06-14
Verifier Name: Sean Turner
Date Verified: 2012-07-16

Section 4 says:

CRLReason ::= INTEGER

It should say:

IMPORTS
CRLReason
FROM PKIX1Implicit-2009

Notes:

CRLReason is correctly defined in section 14 "ASN.1 Module for RFC 5280, Explicit and Implicit" as:
CRLReason ::= ENUMERATED { … }

It is incorrectly re-defined in section 4 "ASN.1 Module for RFC 2560" (OCSP) as an INTEGER. It should import the correct definition instead.
ENUMERATED and INTEGER are similar, but not the same. They are BER-encoded differently (with a tags of 0x0A and 0x02 respectively).

Errata ID: 3626
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Carl Wallace
Date Reported: 2013-05-17
Verifier Name: Sean Turner
Date Verified: 2013-05-20

Section 14 says:

   -- CRL number extension OID and syntax
   ext-CRLNumber EXTENSION ::= {SYNTAX
       INTEGER (0..MAX) IDENTIFIED BY id-ce-cRLNumber }
   id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }

   CRLNumber ::= INTEGER (0..MAX)

It should say:

   -- CRL number extension OID and syntax
   CRLNumber ::= INTEGER  (0..MAX)

   ext-CRLNumber EXTENSION ::= {SYNTAX
       CRLNumber IDENTIFIED BY id-ce-cRLNumber }
   id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }

Notes:

The CRLNumber extension was not defined to use the CRLNumber type. It should use the CRLNumber type. This is a corrected resubmission of an earlier errata submission that included an error.

Errata ID: 3692
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Carl Wallace
Date Reported: 2013-08-02
Verifier Name: Sean Turner
Date Verified: 2013-08-12

Section 14 says:

crlExtensions EXTENSION ::= {
           ext-AuthorityKeyIdentifier | ext-IssuerAltName |
           ext-CRLNumber | ext-DeltaCRLIndicator |
           ext-IssuingDistributionPoint |  ext-FreshestCRL, ... }

It should say:

crlExtensions EXTENSION ::= {
           ext-AuthorityKeyIdentifier | ext-IssuerAltName |
           ext-CRLNumber | ext-DeltaCRLIndicator |
           ext-IssuingDistributionPoint |  ext-FreshestCRL | 
           ext-AuthorityInfoAccess, ... }

Notes:

Section 5.2.7 of RFC 5280 allows AIA to be a CRL extension.

Errata ID: 6806
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Carl Wallace
Date Reported: 2022-01-03
Verifier Name: Benjamin Kaduk
Date Verified: 2022-01-04

Section 6 says:

   pk-rsa PUBLIC-KEY ::= {
    IDENTIFIER rsaEncryption
    KEY RSAPublicKey
    PARAMS TYPE NULL ARE absent
    -- Private key format not in this module --
    CERT-KEY-USAGE {digitalSignature, nonRepudiation,
    keyEncipherment, dataEncipherment, keyCertSign, cRLSign}
   }

It should say:

   pk-rsa PUBLIC-KEY ::= {
    IDENTIFIER rsaEncryption
    KEY RSAPublicKey
    PARAMS TYPE NULL ARE required
    -- Private key format not in this module --
    CERT-KEY-USAGE {digitalSignature, nonRepudiation,
    keyEncipherment, dataEncipherment, keyCertSign, cRLSign}
   }

Notes:

Section 2.3.1 of RFC 3279 states "(t)he parameters field MUST have ASN.1 type NULL for this algorithm identifier."

RFC 5913, "Clearance Attribute and Authority Clearance Constraints Certificate Extension", June 2010

Source of RFC: pkix (sec)

Errata ID: 5890
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2019-10-31
Verifier Name: Benjamin Kaduk
Date Verified: 2019-11-05

Section Section 3 says:

     id-pe-authorityClearanceConstraints OBJECT IDENTIFIER ::= {
       iso(1) identified-organization(3) dod(6) internet(1) security(5)
       mechanisms(5) pkix(7) pe(1) 21 }

It should say:

   id-pe-clearanceConstraints OBJECT IDENTIFIER ::=
     { iso(1) identified-organization(3) dod(6) internet(1) security(5)
       mechanisms(5) pkix(7) pe(1) 21 }

Notes:

Section 3 and Appendix A use different names for the object identifier. They should match. This change treats the complete ASN.1 module from Appendix A as the canonical version.

RFC 5914, "Trust Anchor Format", June 2010

Source of RFC: pkix (sec)

Errata ID: 2667
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jim Schaad
Date Reported: 2010-12-09
Verifier Name: Tim Polk
Date Verified: 2011-03-26

Section A.1 says:

   PKCS7-CONTENT-TYPE ::= TYPE-IDENTIFIER

   trust-anchor-list PKCS7-CONTENT-TYPE ::=
       { TrustAnchorList IDENTIFIED BY id-ct-trustAnchorList }

It should say:

INSERT INTO IMPORTS SECTION before the final semi-colon

   CONTENT-TYPE
   FROM CryptographicMessageSyntax-2009 -- from [RFC5911]
      { iso(1) member-body(2) us(840) rsadsi(113549)
      pkcs(1) pkcs-9(9) smime(16) modules(0)
      id-mod-cms-2004-02(41) }




REPLACE ABOVE TEXT WITH

   trust-anchor-list CONTENT-TYPE ::=
       { TYPE TrustAnchorList IDENTIFIED BY id-ct-trustAnchorList }

Notes:

The content type is designed to be placed into a CMS SignedData object. Since the exact same class definition (not a syntaxically identicial one) needs to be used to get object sets to work correctly, the defintion of the content type must be updated to reference the identical one defined in the CMS module.

A future version should additionally note that the content type is to be added to the ContentSet object set in the CMS module.

RFC 5915, "Elliptic Curve Private Key Structure", June 2010

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 2698
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sean Turner
Date Reported: 2011-01-31
Verifier Name: Stephen Farrell
Date Verified: 2011-11-12

Section 4 says:

PEM encoding the DER-encoded ECPrivateKey is
common; "Proc-Type:" and "DEK-INFO:" fields [RFC1421] followed by the
DER-encoded ECPrivateKey are sandwiched between:

It should say:

PEM encoding the DER-encoded ECPrivateKey is
common; "Proc-Type:" and "DEK-Info:" fields [RFC1421] (each on a new line),
followed by a blank line, and then followed by the Base64 encoding (see
Section 4 of [RFC4648]) of the DER-encoded ECPrivateKey are sandwiched
between:

Notes:

Needed to indicate that the Proc-Type and DEK-Info are on separate lines and that there is a blank line between the DEK-Info and the ECPrivateKey. Also it's not clear that the ECPrivateKey structure is PEM encoded during this process - it is. And finally, "DEK-INFO" should really have been "DEK-Info". This aligns with current industry practice.

Errata ID: 3962
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jim Schaad
Date Reported: 2014-04-14
Verifier Name: Kathleen Moriarty
Date Verified: 2015-03-24

Section 3 and A says:

   ECPrivateKey ::= SEQUENCE {
     version        INTEGER { ecPrivkeyVer1(1) } (ecPrivkeyVer1),
     privateKey     OCTET STRING,
     parameters [0] ECParameters {{ NamedCurve }} OPTIONAL,
     publicKey  [1] BIT STRING OPTIONAL
   }

It should say:

   ECPrivateKey ::= SEQUENCE {
     version        INTEGER { ecPrivkeyVer1(1) } (ecPrivkeyVer1),
     privateKey     OCTET STRING,
     parameters [0] ECParameters  OPTIONAL,
     publicKey  [1] BIT STRING OPTIONAL
   }

Notes:

ECParameters is not a parametrized type. This means that it cannot be used as a parameterized type by passing in the NamedCurve set as a parameter.

RFC 5917, "Clearance Sponsor Attribute", June 2010

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 4537
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Lars Wilhelmsen
Date Reported: 2015-11-18
Verifier Name: Stephen Farrell
Date Verified: 2015-11-19

Section Introduction says:

This document specifies the clearance sponsor attribute.  It is
   included in public key certificates [RFC5280] and attribute
   certificates [RFC5755].  This attribute is only meaningful as a
   companion of the clearance attribute [RFC5755] [RFC5912].  The
   clearance sponsor is the entity (e.g., agency, department, or
   organization) that granted the clearance to the subject named in the
   certificate.  For example, the clearance sponsor for a subject
   asserting the Amoco clearance values [RFC3114] could be
   "Engineering".

It should say:

This document specifies the clearance sponsor attribute.  It is
   included in public key certificates [RFC5280] and attribute
   certificates [RFC5755].  This attribute is only meaningful as a
   companion of the clearance attribute [RFC5755] [RFC5913].  The
   clearance sponsor is the entity (e.g., agency, department, or
   organization) that granted the clearance to the subject named in the
   certificate.  For example, the clearance sponsor for a subject
   asserting the Amoco clearance values [RFC3114] could be
  "Engineering".

RFC 5913 should be added to the references:

   [RFC5913]  Turner, S. and S. Chokhani, "Clearance Attribute and
                        Authority Clearance Constraints Certificate Extension",
                        RFC 5913, June 2010.

Notes:

The first paragraph in the section references RFC 5912. As far as I can see, it should really reference RFC 5913 (Clearance Attribute and Authority Clearance Constraints - Certificate Extension).

Errata ID: 5883
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2019-10-25
Verifier Name: Benjamin Kaduk
Date Verified: 2019-10-26

Section Appendix A says:

     DirectoryString
       PKIX1Explicit-2009
         { iso(1) identified-organization(3) dod(6) internet(1)
           security(5) mechanisms(5) pkix(7) id-mod(0)
           id-pkix1-explicit-02(51) }

It should say:

     DirectoryString
       FROM PKIX1Explicit-2009
         { iso(1) identified-organization(3) dod(6) internet(1)
           security(5) mechanisms(5) pkix(7) id-mod(0)
           id-mod-pkix1-explicit-02(51) }

Notes:

As already reported in eid4558, the "FROM" is missing. In addition, "-mod" is missing from the text portion of the object identifier.

Errata ID: 5884
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2019-10-25
Verifier Name: Benjamin Kaduk
Date Verified: 2019-10-26

Section Appendix A says:

   at-clearanceSponsor ATTRIBUTE ::= {
     TYPE                   DirectoryString { ub-clearance-sponsor }
                            ( WITH COMPONENTS { utf8String PRESENT } )
     EQUALITY MATCHING RULE caseIgnoreMatch
     IDENTIFIED BY          id-clearanceSponsor
   }

It should say:

   at-clearanceSponsor ATTRIBUTE ::= {
     TYPE                   DirectoryString { ub-clearance-sponsor }
                            ( WITH COMPONENTS { uTF8String PRESENT } )
     EQUALITY MATCHING RULE caseIgnoreMatch
     IDENTIFIED BY          id-clearanceSponsor
   }

Notes:

The DirectoryString that is imported from RFC 5912 uses a different capitalization for "uTF8String". They need to be the same for the ASN.1 module to compile properly.

RFC 5918, "Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)", August 2010

Note: This RFC has been updated by RFC 7358

Source of RFC: mpls (rtg)

Errata ID: 2474
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-08-18
Verifier Name: Adrian Farrel
Date Verified: 2010-08-19

Section 6, pg.7 says:

[[ below Figure 3: ]]

      Len FEC Type Info: Two octets.  It MUST be set to 0x0002.

It should say:

      Len FEC Type Info: One octet.  It MUST be set to 0x02.

Notes:

The 'FEC Element Type' field is specified as a single octet in
Section 3 (Figure 1 and subsequent field description on pg.4/5);
Figure 3 also matches Figure 1.

RFC 5925, "The TCP Authentication Option", June 2010

Source of RFC: tcpm (wit)

Errata ID: 4365
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Joe Touch
Date Reported: 2015-05-12
Verifier Name: Martin Stiemerling
Date Verified: 2015-12-16

Section 7.6 says:

   TCP's 4-bit data offset requires that the options end 60 bytes (15
   32-bit words) after the header begins, including the 20-byte header.
   This leaves 40 bytes for options, of which 15 are expected in current
   implementations (listed below), leaving at most 25 for other uses.
   TCP-AO consumes 16 bytes, leaving 9 bytes for additional SYN options
   (depending on implementation dependant alignment padding, which could
   consume another 2 bytes at most).

   o  SACK permitted (2 bytes) [RFC2018][RFC3517]

   o  Timestamps (10 bytes) [RFC1323]

   o  Window scale (3 bytes) [RFC1323]

It should say:

   TCP's 4-bit data offset requires that the options end 60 bytes (15
   32-bit words) after the header begins, including the 20-byte header.
   This leaves 40 bytes for options, of which 19 are expected in current
   implementations (listed below), leaving at most 21 for other uses.
   TCP-AO consumes 16 bytes, leaving 5 bytes for additional SYN options
   (depending on implementation dependent alignment padding, which could
   consume another 2 bytes at most).

   o  SACK permitted (2 bytes) [RFC2018][RFC3517]

   o  Timestamps (10 bytes) [RFC1323]

   o  Window scale (3 bytes) [RFC1323]

   o  Maximum Segment Size (4 bytes) [RFC793]

Notes:

MSS was missing in the original text. New text includes MSS and updates numbers accordingly.

Also corrects a spelling error (dependant -> dependent), which is non-technical but included in the revised text.

Errata ID: 5672
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Joe Touch
Date Reported: 2019-03-24
Verifier Name: Mirja Kühlewind
Date Verified: 2020-03-04

Section 6.2 says:

     /* set the flag when the SEG.SEQ first rolls over */
     if ((RCV.SNE_FLAG == 0)
        && (RCV.PREV_SEQ > 0x7fff) && (SEG.SEQ < 0x7fff)) {
           RCV.SNE = RCV.SNE + 1;
           RCV.SNE_FLAG = 1;
     }
     /* decide which SNE to use after incremented */
     if ((RCV.SNE_FLAG == 1) && (SEG.SEQ > 0x7fff)) {
        SNE = RCV.SNE - 1; # use the pre-increment value
     } else {
        SNE = RCV.SNE; # use the current value
     }
     /* reset the flag in the *middle* of the window */
     if ((RCV.PREV_SEQ < 0x7fff) && (SEG.SEQ > 0x7fff)) {
        RCV.SNE_FLAG = 0;
     }
     /* save the current SEQ for the next time through the code */
     RCV.PREV_SEQ = SEG.SEQ;

It should say:

     /* set the flag when the SEG.SEQ first rolls over */
     if ((RCV.SNE_FLAG == 0)
        && (RCV.PREV_SEQ > 0x7fffffff) && (SEG.SEQ < 0x7fffffff)) {
           RCV.SNE = RCV.SNE + 1;
           RCV.SNE_FLAG = 1;
     }
     /* decide which SNE to use after incremented */
     if ((RCV.SNE_FLAG == 1) && (SEG.SEQ > 0x7fffffff)) {
        SNE = RCV.SNE - 1; # use the pre-increment value
     } else {
        SNE = RCV.SNE; # use the current value
     }
     /* reset the flag in the *middle* of the window */
     if ((RCV.PREV_SEQ < 0x7fffffff) && (SEG.SEQ > 0x7fffffff)) {
        RCV.SNE_FLAG = 0;
     }
     /* save the current SEQ for the next time through the code */
     RCV.PREV_SEQ = SEG.SEQ;

Notes:

The SNE values are 32 bits; the current pseudocode used 16-bit masks (0x7fff) instead of their 32-bit equivalent (0x7fffffff).

This error was first noted by Tero Kivinen <kivinen@iki.fi>.

Errata ID: 5961
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ron Bonica
Date Reported: 2020-01-22
Verifier Name: Mirja Kühlewind
Date Verified: 2020-01-22

Section 7.4 says:

d. Determine the RNextKeyID as indicated by the rnext_key
pointer, and insert it in the TCP-AO RNextKeyID field (using
the rnext_key MKT’s RecvID as the TCP-AO KeyID)

It should say:

d. Determine the RNextKeyID as indicated by the rnext_key
pointer, and insert it in the TCP-AO RNextKeyID field (using
the rnext_key MKT’s RecvID as the TCP-AO RNextKeyID)

Notes:

This was a cut-and-paste error

RFC 5931, "Extensible Authentication Protocol (EAP) Authentication Using Only a Password", August 2010

Note: This RFC has been updated by RFC 8146

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 3109
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Dan Harkins
Date Reported: 2012-02-06
Verifier Name: Sean Turner
Date Verified: 2012-05-04

Section 2.2.2 says:

An integer scalar, x, acts on an ECC group element, Y, via repetitive
addition (Y is added to itself x times), also called point
multiplication -- x * Y.

The inverse function for an ECC group is defined such that the sum of
an element and its inverse is the "point at infinity" (the identity
for elliptic curve point addition).  In other words,

    Q + inv(Q) = "O"

It should say:

An integer scalar, x, acts on an ECC group element, Y, via repetitive
addition (Y is added to itself x times), also called point
multiplication -- x * Y.

ECC groups require the use of a mapping function, F(), which returns
the x-coordinate of a point on the elliptic curve. In other words,
if point Y has coordinates Y.x and Y.y, then,

    Y.x = F(Y)

The inverse function for an ECC group is defined such that the sum of
an element and its inverse is the "point at infinity" (the identity
for elliptic curve point addition).  In other words,

    Q + inv(Q) = "O"

Notes:

Section 2.8.4.1 mentions function F() as defined in 2.2.2 but there is no
function F() in 2.2.2.

RFC 5934, "Trust Anchor Management Protocol (TAMP)", August 2010

Source of RFC: pkix (sec)

Errata ID: 2668
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jim Schaad
Date Reported: 2010-12-09
Verifier Name: Tim Polk
Date Verified: 2011-03-26

Section A.1 says:

ORIG-1
   CONTENT-TYPE  ::= TYPE-IDENTIFIER

ORIG-2
   tamp-status-query CONTENT-TYPE  ::=
     { TAMPStatusQuery IDENTIFIED BY id-ct-TAMP-statusQuery }

ORIG-3
   tamp-status-response CONTENT-TYPE  ::=
     { TAMPStatusResponse IDENTIFIED BY id-ct-TAMP-statusResponse }

ORIG-4
   tamp-update CONTENT-TYPE  ::=
     { TAMPUpdate IDENTIFIED BY id-ct-TAMP-update }

ORIG-5
   tamp-update-confirm CONTENT-TYPE  ::=
     { TAMPUpdateConfirm IDENTIFIED BY id-ct-TAMP-updateConfirm }

ORIG-6
   tamp-apex-update CONTENT-TYPE  ::=
       { TYPE TAMPApexUpdate IDENTIFIED BY id-ct-TAMP-apexUpdate }

ORIG-7
   tamp-apex-update-confirm CONTENT-TYPE  ::=
     { TAMPApexUpdateConfirm IDENTIFIED BY
         id-ct-TAMP-apexUpdateConfirm }

ORIG-8
   tamp-community-update CONTENT-TYPE  ::=
     { TAMPCommunityUpdate IDENTIFIED BY id-ct-TAMP-communityUpdate }

ORIG-9
   tamp-community-update-confirm CONTENT-TYPE  ::=
     { TAMPCommunityUpdateConfirm IDENTIFIED BY
       id-ct-TAMP-communityUpdateConfirm }

ORIG-10
   tamp-sequence-number-adjust CONTENT-TYPE  ::=
     { SequenceNumberAdjust IDENTIFIED BY id-ct-TAMP-seqNumAdjust }

ORIG-11
   tamp-sequence-number-adjust-confirm CONTENT-TYPE  ::=
     { SequenceNumberAdjustConfirm IDENTIFIED BY
       id-ct-TAMP-seqNumAdjustConfirm }

ORIG-12
   tamp-error CONTENT-TYPE  ::=
     { TAMPError IDENTIFIED BY id-ct-TAMP-error }

It should say:

INSERT IN THE IMPORTS SECTION BEFORE THE FINAL SEMI-COLON

 CONTENT-TYPE
   FROM CryptographicMessageSyntax-2009 -- from [RFC5911]
      { iso(1) member-body(2) us(840) rsadsi(113549)
      pkcs(1) pkcs-9(9) smime(16) modules(0)
      id-mod-cms-2004-02(41) }

ORIG-2
   tamp-status-query CONTENT-TYPE  ::=
     { TYPE TAMPStatusQuery IDENTIFIED BY id-ct-TAMP-statusQuery }

ORIG-3
   tamp-status-response CONTENT-TYPE  ::=
     { TYPE TAMPStatusResponse IDENTIFIED BY id-ct-TAMP-statusResponse }

ORIG-4
   tamp-update CONTENT-TYPE  ::=
     { TYPE TAMPUpdate IDENTIFIED BY id-ct-TAMP-update }

ORIG-5
   tamp-update-confirm CONTENT-TYPE  ::=
     { TYPE TAMPUpdateConfirm IDENTIFIED BY id-ct-TAMP-updateConfirm }

ORIG-6
   tamp-apex-update CONTENT-TYPE  ::=
       { TYPE TAMPApexUpdate IDENTIFIED BY id-ct-TAMP-apexUpdate }

ORIG-7
   tamp-apex-update-confirm CONTENT-TYPE  ::=
     { TYPE TAMPApexUpdateConfirm IDENTIFIED BY
         id-ct-TAMP-apexUpdateConfirm }

ORIG-8
   tamp-community-update CONTENT-TYPE  ::=
     { TYPE TAMPCommunityUpdate IDENTIFIED BY id-ct-TAMP-communityUpdate }

ORIG-9
   tamp-community-update-confirm CONTENT-TYPE  ::=
     { TYPE TAMPCommunityUpdateConfirm IDENTIFIED BY
       id-ct-TAMP-communityUpdateConfirm }

ORIG-10
   tamp-sequence-number-adjust CONTENT-TYPE  ::=
     { TYPE SequenceNumberAdjust IDENTIFIED BY id-ct-TAMP-seqNumAdjust }

ORIG-11
   tamp-sequence-number-adjust-confirm CONTENT-TYPE  ::=
     { TYPE SequenceNumberAdjustConfirm IDENTIFIED BY
       id-ct-TAMP-seqNumAdjustConfirm }

ORIG-12
   tamp-error CONTENT-TYPE  ::=
     { TYPE TAMPError IDENTIFIED BY id-ct-TAMP-error }

Notes:

This errata addresses two different issues:
1. The exact same class definition, not a clone, must be used in order to have the ASN.1 object sets work correctly. This is the reason for the change in the definition of the CONTENT-TYPE class.

2. An errata on RFC5911 added the keyword TYPE so that a content type can be defined as not having an associated ASN.1 type (either because it is raw data or is a different structured data type such as XML). This means that all objects of the CONTENT-TYPE class need to have the word TYPE added to them.

Note also that the text is removed and not replaced for ORIG-1

RFC 5935, "Expressing SNMP SMI Datatypes in XML Schema Definition Language", August 2010

Source of RFC: opsawg (ops)

Errata ID: 2477
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-08-19
Verifier Name: Dan Romascanu
Date Verified: 2010-11-02

Section 7, pg.11 says:

   In accordance with RFC 3688 [RFC3688], the IANA XML registry has been
   updated with the following namespace and schema registrations
   associated with this document:

   o  urn:ietf:params:xml:ns:smi:base:1.0

|  o  urn:ietf:params:xml:schema:base:1.0

It should say:

   In accordance with RFC 3688 [RFC3688], the IANA XML registry has been
   updated with the following namespace and schema registrations
   associated with this document:

   o  urn:ietf:params:xml:ns:smi:base:1.0

|  o  urn:ietf:params:xml:schema:smi:base:1.0

Notes:

Rationale: "smi:" component missing in schema registration;
Section 7.2 provides the correct URI.
The registry entry at IANA is correct as well.

Remark:
Also, the ASCII transliteration of the last name of the submitter
of this note is misspelled in the last paragraph of Section 8.

RFC 5938, "Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP)", August 2010

Source of RFC: ippm (ops)

Errata ID: 2478
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-08-19
Verifier Name: Lars Eggert
Date Verified: 2010-08-20

Section 3.2 and 3.4 says:

a) [[ second-to-last para of Section 3.2: ]]

   The Server MUST respond with one or more Start-N-Ack messages (which
   SHOULD be sent as quickly as possible).  Start-N-Ack messages SHALL
|  have the format defined in the next session.
                                         ^^

b) [[ last para of Section 3.4: ]]

   The Server MUST respond with one or more Stop-N-Ack messages (which
   SHOULD be sent as quickly as possible).  Stop-N-Ack messages SHALL
|  have the format defined in the next session.
                                         ^^

It should say:

a)

   The Server MUST respond with one or more Start-N-Ack messages (which
   SHOULD be sent as quickly as possible).  Start-N-Ack messages SHALL
|  have the format defined in the next section.
                                         ^^

b)

   The Server MUST respond with one or more Stop-N-Ack messages (which
   SHOULD be sent as quickly as possible).  Stop-N-Ack messages SHALL
|  have the format defined in the next section.
                                         ^^

Notes:

Rationale: potentially confusing typo (iterated)!

RFC 5939, "Session Description Protocol (SDP) Capability Negotiation", September 2010

Note: This RFC has been updated by RFC 6871

Source of RFC: mmusic (rai)

Errata ID: 3545
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Dale Worley
Date Reported: 2013-03-11
Verifier Name: Gonzalo Camarillo
Date Verified: 2013-04-03

Section 3.4.1 says:

     a=acap:2 a=pcfg:1 t=1 a=1   ;Not allowed to embed "pcfg"

It should say:

     a=acap:2 pcfg:1 t=1 a=1   ;Not allowed to embed "pcfg"

Notes:

The existing text, with "a=" before "pcfg", is outright syntactically incorrect per the syntax in the first paragraph of the section. The correction is needed for the text to be the intended demonstration of a semantic error.

RFC 5944, "IP Mobility Support for IPv4, Revised", November 2010

Source of RFC: mip4 (int)

Errata ID: 3116
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Pearl Liang
Date Reported: 2012-02-07
Verifier Name: Brian Haberman
Date Verified: 2012-04-17

Section 3.7.2 says:

Section 3.7.2 "Receiving Registration Requests" says:

Otherwise, if the foreign agent does not serve the mobile node as a home
agent,
   the foreign agent rejects the Registration Request with Code 194
   (Invalid Home Agent Address).

Another entry for "Invalid Home Agent Address" is indicated in Section 3.4: 

        194 Invalid Home Agent Address

It should say:

For Section 3.7.2 "Receiving Registration Requests", it should say:

Otherwise, if the foreign agent does not serve the mobile node as a home
agent,
the foreign agent rejects the Registration Request with Code 116
(Invalid Home Agent Address).

For the entry for "Invalid Home Agent Address" in Section 3.4, it should say:

        116 Invalid Home Agent Address

Notes:

The Code 194 was incorrectly registered under the range for Error Codes from the Foreign Agent (64-127). The mobile note (Invalid Home Agent Address) is a registration under denied by the foreign agent, and so the mobile note should be changed to the Code 116 for Invalid Home Agent Address in the range for Error Codes from the Foreign Agent. The Code 194 has been reserved in the range for Error Codes from the Gateway Foreign Agent (194-200).

Errata ID: 3428
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ville Nuorvala
Date Reported: 2012-12-12
Verifier Name: Brian Haberman
Date Verified: 2012-12-12

Section 3.3 says:

      M        Minimal encapsulation.  If the 'M' bit is set, the mobile
               node requests that its home agent use minimal
               encapsulation [16] for datagrams tunneled to the mobile
               node.

It should say:

      M        Minimal encapsulation.  If the 'M' bit is set, the mobile
               node requests that its home agent use minimal
               encapsulation [15] for datagrams tunneled to the mobile
               node.

Notes:

The citation points to the wrong reference:
[16] Plummer, D., "Ethernet Address Resolution Protocol: Or
Converting Network Protocol Addresses to 48.bit Ethernet
Address for Transmission on Ethernet Hardware", STD 37, RFC
826, November 1982.

It should point to:
[15] Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
October 1996.

Errata ID: 3438
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Pritish Aherrao
Date Reported: 2012-12-27
Verifier Name: Brian Haberman
Date Verified: 2013-01-03

Section 3.7.3.2 says:

A Registration Reply that satisfies the validity checks of Section
3.8.2.1 is relayed to the mobile node.

It should say:

A Registration Reply that satisfies the validity checks of Section
3.7.3.1 is relayed to the mobile node.

Notes:

Currently, the incorrect cross reference is provided.
The Foreign Agent would perform the validity checks mentioned in Section 3.7.3.1 upon receiving the Registration Reply and would relay the Registration Reply that satisfies the validity checks.

Errata ID: 4133
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jack Martin
Date Reported: 2014-10-17
Verifier Name: Brian Haberman
Date Verified: 2014-10-21

Section 1.10 says:

This format is applicable for non-skippable extensions that carry
information of more that 256 bytes.
.
.
.
Since the Length field is 16 bits wide, the extension data can exceed
256 bytes in length.

It should say:

This format is applicable for non-skippable extensions that carry
information of more that 254 bytes.
.
.
.
Since the Length field is 16 bits wide, the extension data can exceed
254 bytes in length.

Notes:

Since the short extension form defined in section 1.11 can only carry up to 254 bytes of data, all extensions with 255 or more bytes needs to use the long extension.

Errata ID: 4134
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jack Martin
Date Reported: 2014-10-17
Verifier Name: Brian Haberman
Date Verified: 2014-10-21

Section 1.11 says:

This format is compatible with the skippable extensions defined in
Section 1.9. It is not applicable for extensions that require more
than 256 bytes of data; for such extensions, use the format described
in Section 1.10.

It should say:

This format is compatible with the skippable extensions defined in
Section 1.9. It is not applicable for extensions that require more
than 254 bytes of data; for such extensions, use the format described
in Section 1.10.

Notes:

The length field is 8 bits which yields a maximum of 255 data octets.
But the length field must include one octet for the sub-type field,
yielding a maximum of 254 octets of data.

RFC 5952, "A Recommendation for IPv6 Address Text Representation", August 2010

Source of RFC: 6man (int)

Errata ID: 2498
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mohamed Boucadair
Date Reported: 2010-08-23
Verifier Name: Brian Haberman
Date Verified: 2012-06-01

Section 6 says:

"This is due to the "::"usage in IPv6 addresses."

It should say:

"This is due to the ":" usage in IPv6 addresses."

RFC 5958, "Asymmetric Key Packages", August 2010

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 2653
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sean Turner
Date Reported: 2010-12-01
Verifier Name: Stephen Farrell
Date Verified: 2011-11-12

Section 2 and App A says:

  ct-asymmetric-key-package CONTENT-TYPE ::=
    { AsymmetricKeyPackage IDENTIFIED BY id-ct-KP-aKeyPackage }

It should say:

  ct-asymmetric-key-package CONTENT-TYPE ::=
    { TYPE AsymmetricKeyPackage IDENTIFIED BY id-ct-KP-aKeyPackage }

Notes:

With the approval of errata 2612 (http://www.rfc-editor.org/errata_search.php?eid=2612), the asymmetric key package content type definition also needs to be updated to add "TYPE" to the CONTENT-TYPE definition.

RFC 5960, "MPLS Transport Profile Data Plane Architecture", August 2010

Note: This RFC has been updated by RFC 7274

Source of RFC: mpls (rtg)

Errata ID: 2534
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Italo Busi
Date Reported: 2010-09-29
Verifier Name: Adrian Farrel
Date Verified: 2010-11-18

Section 6 says:

   Where enhanced security is desirable, and a trust relationship exists
   between an LSR and its peer, the LSR MAY choose to implement the
   following policy for the processing of MPLS packets received from one
   or more of its neighbors:

      Upon receipt of an MPLS packet, discard the packet unless one of
      the following two conditions holds:

      1.  Any MPLS label in the packet's label stack processed at the
          receiving LSR, such as an LSP or PW label, has a label value
          that the receiving LSR has distributed to that neighbor; or

      2.  Any MPLS label in the packet's label stack processed at the
          receiving LSR, such as an LSP or PW label, has a label value
          that the receiving LSR has previously distributed to the peer
          beyond that neighbor (i.e., when it is known that the path
          from the system to which the label was distributed to the
          receiving system is via that neighbor).

It should say:

   Where enhanced security is desirable, and a trust relationship exists
   between two LSRs, an LSR receiving an MPLS packet MAY choose to 
   implement an additional policy for processing the received packet as
   follows:

      The receiving LSR discards the packet unless every MPLS label
      stack entry that it processes from the packet's label stack has a 
      label that has been agreed for use by the sender of the packet
      (for example, is a reserved label or has been distributed using
      the management plane or control plane upstream or downstream 
      allocation). 

Notes:

There was considerable confusion about the distinction between peer and neighbour. This was first raised in a liaison from the ITU-T visible at
https://datatracker.ietf.org/liaison/916/

Clarification was also added about which labels are acceptable.

This does not result in a technical change to the specification, but introduces clarity about the processes described.

Errata ID: 2533
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Italo Busi
Date Reported: 2010-09-29
Verifier Name: Adrian Farrel
Date Verified: 2010-11-10

Section 3.2 says:

   A section MUST provide a means of identifying the type of payload it
   carries.  If the section is a data-link, link-specific mechanisms
   such as a protocol type indication in the data-link header MAY be
   used.  If the section is an LSP, this information MAY be implied by
   the LSP label or, if the LSP payload is MPLS-labeled, by the setting
   of the S bit.  Additional labels MAY also be used if necessary to
   distinguish different payload types; see [RFC5921] for examples and
   further discussion.

It should say:

   A section MUST provide a means of identifying the type of payload it
   carries. This mechanism may be used to facilitate multiplexing MPLS
   with other protocols on the section if that function is supported by
   the section. Support or non-support of multiplexing on sections is
   out-of-scope for this document.

   If the section is a data-link, link-specific mechanisms
   such as a protocol type indication in the data-link header MAY be
   used.  If the section is an LSP, this information MAY be implied by
   the LSP label or, if the LSP payload is MPLS-labeled, by the setting
   of the S bit.  Additional labels MAY also be used if necessary to
   distinguish different payload types; see [RFC5921] for examples and
   further discussion.

Notes:

This change clarifies the requirement to support payload identification, the way it is used, and the use to which it is put. Furthermore, it clarifies the standing of protocol multiplexing onto underlying sections.

This issue was first raised in a liaison from the ITU-T
See https://datatracker.ietf.org/liaison/916/

RFC 5961, "Improving TCP's Robustness to Blind In-Window Attacks", August 2010

Note: This RFC has been updated by RFC 9293

Source of RFC: tcpm (wit)

Errata ID: 4845
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Tüxen
Date Reported: 2016-10-27
Verifier Name: Mirja Kühlewind
Date Verified: 2016-10-31

Section 3.2 says:

   1) If the RST bit is set and the sequence number is outside the
      current receive window (SEG.SEQ <= RCV.NXT || SEG.SEQ > RCV.NXT+
      RCV.WND), silently drop the segment.

It should say:

   1) If the RST bit is set and the sequence number is outside the
      current receive window (SEG.SEQ < RCV.NXT || SEG.SEQ >= RCV.NXT+
      RCV.WND), silently drop the segment.

Notes:

The condition should be the opposite of (RCV.NXT <= SEG.SEQ < RCV.NXT+RCV.WND), which is stated in the second item of the enumeration.

RFC 5965, "An Extensible Format for Email Feedback Reports", August 2010

Note: This RFC has been updated by RFC 6650

Source of RFC: marf (app)

Errata ID: 4421
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Simon Leinen
Date Reported: 2015-07-19
Verifier Name: Barry Leiba
Date Verified: 2015-07-19

Section B.2 says:

   --part1_13d.2e68ed54_boundary
   Content-Type: message/rfc822
   Content-Disposition: inline

   From: <somespammer@example.net>
   Received: from mailserver.example.net (mailserver.example.net
        [192.0.2.1]) by example.com with ESMTP id M63d4137594e46;
        Thu, 08 Mar 2005 14:00:00 -0400

   To: <Undisclosed Recipients>
   Subject: Earn money

It should say:

   --part1_13d.2e68ed54_boundary
   Content-Type: message/rfc822
   Content-Disposition: inline

   From: <somespammer@example.net>
   Received: from mailserver.example.net (mailserver.example.net
        [192.0.2.1]) by example.com with ESMTP id M63d4137594e46;
        Thu, 08 Mar 2005 14:00:00 -0400
   To: <Undisclosed Recipients>
   Subject: Earn money

Notes:

In the second example report, there is an empty line in the middle of the headers section of the quoted rfc822 message. This seems wrong.

RFC 5969, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", August 2010

Source of RFC: softwire (int)

Errata ID: 3049
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alessandro Cortiana
Date Reported: 2011-12-11
Verifier Name: Ralph Droms
Date Verified: 2013-03-10

Section 12 says:

By restricting the 6rd domain to within a provider
network, a CE only needs to accept packets from a single or small set
of known 6rd BR IPv4 addresses.

It should say:

By restricting the 6rd domain to within a provider
network, a CE only needs to accept packets from a single or small set
of known 6rd BR IPv4 addresses and from other CEs within the 6rd domain.

Notes:

A CE also needs to accept packets from other CEs within the 6rd domain.
This happens when, within a 6rd domain, two customer sites want to communicate.
Reference: RFC5569 section 3

RFC 5981, "Authorization for NSIS Signaling Layer Protocols", February 2011

Source of RFC: nsis (tsv)

Errata ID: 2985
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Roland Bless
Date Reported: 2011-10-05
Verifier Name: Wes Eddy
Date Verified: 2011-11-14

Section 4.4 says:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0| Type = SESSION_AUTH   |0|0|0|0|    Object   Length    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             |   AUTH_ENT_ID | HMAC_SIGNED   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   reserved                    | Transform ID  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             | SOURCE_ADDR   |  IPV4_ADDRESS |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                IPv4 Source Address of NSLP sender             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             |  START_TIME   | NTP_TIME_STAMP|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        NTP Time Stamp (1)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        NTP Time Stamp (2)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             | NSLP_OBJ_LIST |     zero      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |No. of signed NSLP objects = n |  rsv  |  NSLP object type (1) |
   +-------+-------+---------------+-------+-------+---------------+
   |  rsv  | NSLP object type (2)  |             .....            //
   +-------+-------+---------------+---------------+---------------+
   |  rsv  | NSLP object type (n)  |     (padding if required)     |
   +--------------+----------------+---------------+---------------+
   |            Length             |   AUTH_DATA   |     zero      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Key-ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Message Authentication Code HMAC Data                |
   +---------------------------------------------------------------+

    Figure 5: Example of a SESSION_AUTH_OBJECT That Provides Integrity
                       Protection for NSLP Messages

It should say:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0| Type = SESSION_AUTH   |0|0|0|0|    Object   Length    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             |   AUTH_ENT_ID | HMAC_SIGNED   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   reserved    |          Transform ID         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             | SOURCE_ADDR   |  IPV4_ADDRESS |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                IPv4 Source Address of NSLP sender             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             |  START_TIME   | NTP_TIME_STAMP|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        NTP Time Stamp (1)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        NTP Time Stamp (2)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             | NSLP_OBJ_LIST |     zero      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |No. of signed NSLP objects = n |  rsv  |  NSLP object type (1) |
   +-------+-------+---------------+-------+-------+---------------+
   |  rsv  | NSLP object type (2)  |             .....            //
   +-------+-------+---------------+---------------+---------------+
   |  rsv  | NSLP object type (n)  |     (padding if required)     |
   +--------------+----------------+---------------+---------------+
   |            Length             |   AUTH_DATA   |     zero      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Key-ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Message Authentication Code HMAC Data                |
   +---------------------------------------------------------------+

    Figure 5: Example of a SESSION_AUTH_OBJECT That Provides Integrity
                       Protection for NSLP Messages

Notes:

The Transform ID was specified in RFC 5996 as a two-octect value.
Figure 5 showed incorrectly only an octect wide field. The text,
however, refers to the specification in RFC 5996 and the corresponding
IANA registry. Thus I don't consider it as technical error since
only the figure showing an example is wrong.

Errata ID: 2986
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Martin Röhricht
Date Reported: 2011-10-05
Verifier Name: Wes Eddy
Date Verified: 2011-11-14

Section 3.2 says:

      6.  END_TIME: The end time for the session.

      7.  AUTHENTICATION_DATA: The authentication data of the Session
          Authorization Object.

It should say:

      6.  END_TIME: The end time for the session.

      7.  NSLP_OBJECT_LIST: A list of all NSLP objects that
          are included in an HMAC calculation.

      8.  AUTHENTICATION_DATA: The authentication data of the Session
          Authorization Object.

Notes:

Since the NSLP_OBJECT_TYPE attribute was introduced in Section 3.2.7 it should also appear in the comprehensive list of currently available X-Types at the beginning of Section 3.2.

RFC 5994, "Application of Ethernet Pseudowires to MPLS Transport Networks", October 2010

Source of RFC: pwe3 (int)

Errata ID: 2547
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-10-07
Verifier Name: Adrian Farrel
Date Verified: 2011-08-02

Throughout the document, when it says:

a)

MPLS EXP field

b)

EXP-Inferred-PSC LSP (E-LSP)

It should say:

a)

MPLS Traffic Class field

b)

Explicitly TC-encoded-PSC LSP (E-LSP)

Notes:

Rationale:
RFC 5462 has carefully changed the terminology and updated RFCs 3032
and 3270 (among others); it has given a detailed explantion why this
needs to be done and confirmed that all future RFCs should
unconditionally use the updated terms.
See in particular Sections 2.1 and 2.2 of RFC 5462 for the updates to
RFC 3032 and RFC 3270 (respectively) that are relevant for this RFC.

Ironically, RFC 5994 cites RFC 5462, yet uses the obsolete terms. Sigh!

RFC 5996, "Internet Key Exchange Protocol Version 2 (IKEv2)", September 2010

Note: This RFC has been obsoleted by RFC 7296

Note: This RFC has been updated by RFC 5998, RFC 6989

Source of RFC: ipsecme (sec)

Errata ID: 2707
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Yaron Sheffer
Date Reported: 2011-02-06
Verifier Name: Sean Turner
Date Verified: 2011-03-26

Section 3.6 says:

[...] and also MUST be capable of being configured to send and accept the 
Hash and URL format (with HTTP URLs)

It should say:

[...] and also MUST be capable of being configured to send and accept the 
two Hash and URL formats (with HTTP URLs)

Notes:

This change from the original RFC 4306 text was made late in the process, responding to the Gen-Art reviewer comment. Factually, the document (earlier in the same section) defines two Hash and URL formats, making this sentence a clear inconsistency. The erratum is flagged as Technical because the text is normative.

Errata ID: 3036
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Valery Smyslov
Date Reported: 2011-11-26
Verifier Name: Sean Turner
Date Verified: 2011-11-27

Section 3.10 says:

      [...] Of the notifications defined in this document, the SPI is
      included only with INVALID_SELECTORS and REKEY_SA.

It should say:

      [...] Of the notifications defined in this document, the SPI is
      included only with INVALID_SELECTORS, REKEY_SA and CHILD_SA_NOT_FOUND.

Notes:

Original text was carried over from RFC4306 and contradicts with the text in section 2.25, which clearly says that SPI field in CHILD_SA_NOT_FOUND notification is populated. Notification CHILD_SA_NOT_FOUND was not defined in RFC4306, and the whole section 2.25 is new to RFC5996.

RFC 6003, "Ethernet Traffic Parameters", October 2010

Source of RFC: ccamp (rtg)

Errata ID: 2552
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-10-12
Verifier Name: Adrian Farrel
Date Verified: 2010-11-10

Section 4.1, pg.7 says:

   Index: 8 bits

      [...]

      A given index value j can be associated to at most N Class-Type
      values CTi (i =< N) of the EXTENDED_CLASSTYPE object.  This
|     association applies when a set of one or more CTIs maps to a
      single (shared) BW profile.  An example of value setting consists
      in assigning an arbitrary value comprised within the range
      [0x08,0xF8] associated to a set of CTi, the values in the range
|     [0xF8,0xFF] being selected for reserved sets.  This allows mapping
      to one of 248 predefined CTi sets.

It should say:

   Index: 8 bits

      [...]

      A given index value j can be associated to at most N Class-Type
      values CTi (i =< N) of the EXTENDED_CLASSTYPE object.  This
|     association applies when a set of one or more CTis maps to a
      single (shared) BW profile.  An example of value setting consists
      in assigning an arbitrary value comprised within the range
      [0x08,0xF8] associated to a set of CTi, the values in the range
|     [0xF9,0xFF] being selected for reserved sets.  This allows mapping
      to one of 248 predefined CTi sets.

Notes:

Rationale:
a) consistent use of "CTi" -- 'i' essentially is a subscript index;
b) avoid ambiguity due to overlap in ranges given

[The first item is Editorial, but the second one clearly Technical]

Errata ID: 2551
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-10-12
Verifier Name: Adrian Farrel
Date Verified: 2010-11-10

Section 4, pg. 5 says:

   Type: 16 bits

      Defined values are:

      Type     Length   Format            Description
      ------------------------------------------------------
        0         -     Reserved          Reserved value
        1         -     Reserved          Reserved value
|       2        24     see Section 3.1   Ethernet Bandwidth
                                          Profile [MEF10.1]
        3         8     [RFC6004]         Layer 2 Control
                                          Protocol (L2CP)
      255         -     Reserved          Reserved value

It should say:

   Type: 16 bits

      Defined values are:

      Type     Length   Format            Description
      ------------------------------------------------------
        0         -     Reserved          Reserved value
        1         -     Reserved          Reserved value
|       2        24     see Section 4.1   Ethernet Bandwidth
                                          Profile [MEF10.1]
        3         8     [RFC6004]         Layer 2 Control
                                          Protocol (L2CP)
      255         -     Reserved          Reserved value

Notes:

Incorrect internal reference.

RFC 6006, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths", September 2010

Note: This RFC has been obsoleted by RFC 8306

Source of RFC: pce (rtg)

Errata ID: 4867
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: DHRUV DHODY
Date Reported: 2016-11-16
Verifier Name: Deborah Brungard
Date Verified: 2017-03-13

Section 3.4 says:

           <PCReq Message>::= <Common Header>
                                 <request>
        where:
                <request>::= <RP>
                                <end-point-rro-pair-list>
                                [<OF>]
                                [<LSPA>]
                                [<BANDWIDTH>]
                                [<metric-list>]
                                [<IRO>]
                                [<LOAD-BALANCING>]

        where:

                <end-point-rro-pair-list>::=
                                   <END-POINTS>[<RRO-List>][<BANDWIDTH>]
                                   [<end-point-rro-pair-list>]

                <RRO-List>::=<RRO>[<BANDWIDTH>][<RRO-List>]
                <metric-list>::=<METRIC>[<metric-list>]

It should say:

           <PCReq Message>::= <Common Header>
                              [<svec-list>]
                              <request-list>

           where:

                <svec-list>::=<SVEC>
                              [<OF>]
                              [<metric-list>]
                              [<svec-list>]

                <request-list>::=<request>[<request-list>]

                <request>::= <RP>
                             <end-point-rro-pair-list>
                             [<OF>]
                             [<LSPA>]
                             [<BANDWIDTH>]
                             [<metric-list>]
                             [<IRO>|<BNC>]
                             [<LOAD-BALANCING>]

           where:

                <end-point-rro-pair-list>::=
                                   <END-POINTS>[<RRO-List>[<BANDWIDTH>]]
                                   [<end-point-rro-pair-list>]
                <RRO-List>::=(<RRO>|<SRRO>)[<RRO-List>]
                <metric-list>::=<METRIC>[<metric-list>]

Notes:

o Update the Routing Backus-Naur Form (RBNF) [RFC5511] for Request
message format:

* Update the request message to allows for the bundling of
multiple path computation requests within a single Path
Computation Request (PCReq) message.

* Add <svec-list> in PCReq message. This object was missed in
[RFC6006].

* Add BNC object in PCReq message. This object is required to
support P2MP. It shares the same format as Include Route Object
(IRO) but it is a different object.

* Update the <RRO-List> format to also allow Secondary Record
Route object (SRRO). This object was missed in [RFC6006].

* Removed the BANDWIDTH Object followed by Record Route Object
(RRO) from <RRO-List>. As BANDWIDTH object doesn't need to follow
for each RRO in the <RRO-List>, there already exist BANDWIDTH
object follow <RRO-List> and is backward compatible with
[RFC5440].

* Update the <end-point-rro-pair-list> to allow optional BANDWIDTH
object only if <RRO-List> is included.

Refer https://datatracker.ietf.org/doc/draft-palleti-pce-rfc6006bis/?include_text=1

Errata ID: 4868
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: DHRUV DHODY
Date Reported: 2016-11-16
Verifier Name: Deborah Brungard
Date Verified: 2016-11-16

Section 3.5 says:

          <PCRep Message>::= <Common Header>
                                <response>
          <response>::=<RP>
                          [<end-point-path-pair-list>]
                          [<NO-PATH>]
                          [<attribute-list>]

        where:

           <end-point-path-pair-list>::=
                   [<END-POINTS>]<path>[<end-point-path-pair-list>]

          <path> ::= (<ERO>|<SERO>) [<path>]

          <attribute-list>::=[<OF>]
                               [<LSPA>]
                               [<BANDWIDTH>]
                               [<metric-list>]
                               [<IRO>]

It should say:

          <PCRep Message>::= <Common Header>
                             <response-list>

          where:

              <response-list>::=<response>[<response-list>]

              <response>::=<RP>
                         [<end-point-path-pair-list>]
                        [<NO-PATH>]
                        [<UNREACH-DESTINATION>]
                        [<attribute-list>]

              <end-point-path-pair-list>::=
                      [<END-POINTS>]<path>[<end-point-path-pair-list>]

              <path> ::= (<ERO>|<SERO>) [<path>]

          where:

              <attribute-list>::=[<OF>]
                                 [<LSPA>]
                                 [<BANDWIDTH>]
                                 [<metric-list>]
                                 [<IRO>]

Notes:

o Update the RBNF for Reply message format:

* Update PCEP allows for the bundling of multiple path computation
responses within a single Path Computation Reply (PCRep) message.

* Update UNREACH-DESTINATION in PCRep message. This object was
missed in [RFC6006].

Refer: https://datatracker.ietf.org/doc/draft-palleti-pce-rfc6006bis/?include_text=1

Errata ID: 3819
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Udayasree
Date Reported: 2013-12-04
Verifier Name: Adrian Farrel
Date Verified: 2013-12-05

Section 3.13.2 says:

Each message sent to the PCE, except the last
one, will have the F-bit set in the RP object to signify that the
response has been fragmented into multiple messages.

It should say:

Each message sent by the PCE, except the last
one, will have the F-bit set in the RP object to signify that the
response has been fragmented into multiple messages.

Notes:

This section is about response, and response messages are sent *by* the PCE.

Errata ID: 3830
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Udayasree
Date Reported: 2013-12-10
Verifier Name: Adrian Farrel
Date Verified: 2013-12-13

Section 3.15 says:

To indicate P2MP message fragmentation errors associated with a P2MP
path request, a new Error-Type (17) and subsequent error-values are
defined as follows for inclusion in the PCEP-ERROR object:

It should say:

To indicate P2MP message fragmentation errors associated with a P2MP
path request, a new Error-Type (18) and subsequent error-values are
defined as follows for inclusion in the PCEP-ERROR object:

Notes:

17 P2MP END-POINTS Error
18 P2MP Fragmentation Error

It should be 18 in this statement

RFC 6009, "Sieve Email Filtering: Delivery Status Notifications and Deliver-By Extensions", October 2010

Source of RFC: sieve (app)

Errata ID: 2545
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-10-05
Verifier Name: Alexey Melnikov
Date Verified: 2010-11-12

Section 7.2 says:

   # Send a copy to my cell phone to be delivered before 10PM
   if currentdate :value "lt"
                  :comparator "i;ascii-numeric" "hour" "22"
   {
       if currentdate :matches "date" "*" {set "date" "${0}";}
       if currentdate :matches "zone" "*" {set "zone" "${0}";}
|      redirect :copy :bytimeabsolute "${date}T20:00:00${zone}"
                :bymode "return" "cellphone@example.com";
   }

It should say:

   # Send a copy to my cell phone to be delivered before 10PM
   if currentdate :value "lt"
                  :comparator "i;ascii-numeric" "hour" "22"
   {
       if currentdate :matches "date" "*" {set "date" "${0}";}
       if currentdate :matches "zone" "*" {set "zone" "${0}";}
|      redirect :copy :bytimeabsolute "${date}T22:00:00${zone}"
                :bymode "return" "cellphone@example.com";
   }

Notes:

Rationale: "10PM" corresponds to T22:00:00 , not T20:00:00 .

RFC 6010, "Cryptographic Message Syntax (CMS) Content Constraints Extension", September 2010

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 2666
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jim Schaad
Date Reported: 2010-12-09
Verifier Name: Stephen Farrell
Date Verified: 2011-06-02

Section A.1 says:

   ct-Any CONTENT-TYPE ::= {NULL IDENTIFIED BY id-ct-anyContentType }

It should say:

   ct-Any CONTENT-TYPE ::= {TYPE NULL IDENTIFIED BY id-ct-anyContentType }

Notes:

This errata is filed to deal with the change made to RFC 5911. The addition of the TYPE key word allows for a type to be omitted. It may be that the authors will want to take advantage of this and remove the "TYPE NULL" from the object defined and say that there is no ASN.1 type associated with this object identifier.

RFC 6011, "Session Initiation Protocol (SIP) User Agent Configuration", October 2010

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rai

Errata ID: 2622
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-11-11
Verifier Name: Gonzalo Camarillo
Date Verified: 2013-04-03

Section 2.3.1.2 says:

   If the DNS request to resolve the Configuration Service Domain name
   to a request URL does not receive any response, the UA should follow
   standard DNS retry procedures.

   If the DNS request to resolve the Configuration Service Domain name
|  to a host name returns a response that indicates that no matching
|  result is available (NXDOMAIN), the UA SHOULD attempt to obtain
   another Configuration Service Domain name using the procedures in
   Section 2.2, "Obtaining the Configuration Service Domain".

It should say:

   If the DNS request to resolve the Configuration Service Domain name
   to a request URL does not receive any response, the UA should follow
   standard DNS retry procedures.

   If the DNS request to resolve the Configuration Service Domain name
|  to a request URL returns a response that indicates that the queried
|  domain does not exist (NXDomain), that no matching result is
|  available at that domain (NoError response with an empty NAPTR RRset
|  in the Answer section), or that a permanent error condition exists
|  (other non-zero RCODE value, e.g., ServFail), the UA SHOULD attempt
   to obtain another Configuration Service Domain name using the
   procedures in Section 2.2, "Obtaining the Configuration Service
   Domain".

Notes:

Rationale:
a) This section discusses the U-NAPTR usage; therefore, as in the first
paragraph, the second paragraph should not erroneously indicate
a "host name" return, it also should precisely indicate that it
talks about U-NAPTR lookup; hence s/host name/request URL/ .

b) It is an unfortunately widespread misconception that a DNS query
for a RR type that does not exists at a particular domain name
returns a NXDomain response. This is not the case. An empty RRset
is a valid response returned with RCODE=0 (NoError). Further, the
RFC text omits the important error cases that also need to be dealt
with by the SIP UA configuration procedure.
The replacement text tries to clarify the different situations
where no NAPTR record can be obtained.

c) Use the standard version spelling of DNS RCODE names as registered
in the "DNS RCODEs" sub-registry -- part of
http://www.IANA.ORG/assignments/dns-parameters.

Errata ID: 2623
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-11-11
Verifier Name: Gonzalo Camarillo
Date Verified: 2013-04-03

Section 2.4.2 says:

[[ first bullet on page 14: ]]
 
  o  If a DNS request to resolve the host name in the request URL
      returns a response that indicates that no matching result is
|     available (NXDOMAIN), the UA MUST remove that request URL from the
      list of alternatives for the Configuration Service Domain.

It should say:

   o  If a DNS request to resolve the host name in the request URL
      returns a response that indicates that no matching result is
|     available, the UA MUST remove that request URL from the list of
      alternatives for the Configuration Service Domain.

Notes:

Rationale:
See the related Errata Note for Section 2.3.1.2 (EID=2622) for
background and details. Dropping the parenthetical "NXDOMAIN"
here seems to be the most simple way to remove the misleading
allusion that "no matching data available" be equivalent to a
NXDomain response.

RFC 6016, "Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs", October 2010

Source of RFC: tsvwg (wit)

Errata ID: 2553
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-10-12
Verifier Name: Lars Eggert
Date Verified: 2011-01-28

Section 8.6, pg.27 says:

[[ last paragraph of section 8.6 ]]

|
|  The flags and DSCP are identical to the same fields of the AGGREGATE-
|  IPv4 and AGGREGATE-IPv6 SESSION objects.

It should say:

[[ nothing ]]

Notes:

Rationale: The text in this paragraph does not match the preceding
artwork for Class = 11, C-Type = 16 and 17; it is spurious and
needs to be deleted.

Errata ID: 2558
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-10-12
Verifier Name: Lars Eggert
Date Verified: 2011-01-28

Section 8.5, pg.24 says:

|  The usage of Aggregated VPN-IPv4 (or VPN-IPv6) SESSION object is
   described in Section 7.3.  The AGGREGATE-VPN-IPv4 (respectively,
   AGGREGATE-IPv6-VPN) SESSION object appears in RSVP messages that
   ordinarily contain a AGGREGATE-IPv4 (respectively, AGGREGATE-IPv6)
   SESSION object as defined in [RFC3175] and are sent between ingress
   PE and egress PE in either direction.  The GENERIC-AGGREGATE-VPN-IPv4
|  (respectively, AGGREGATE-VPN-IPv6) SESSION object should appear in
   all RSVP messages that ordinarily contain a GENERIC-AGGREGATE-IPv4
   (respectively, GENERIC-AGGREGATE-IPv6) SESSION object as defined in
   [RFC4860] and are sent between ingress PE and egress PE in either
   direction.  [...]

It should say:

|  The usage of the Aggregated VPN-IPv4 (or VPN-IPv6) SESSION object is
   described in Section 7.3.  The AGGREGATE-VPN-IPv4 (respectively,
   AGGREGATE-IPv6-VPN) SESSION object appears in RSVP messages that
   ordinarily contain a AGGREGATE-IPv4 (respectively, AGGREGATE-IPv6)
   SESSION object as defined in [RFC3175] and are sent between ingress
   PE and egress PE in either direction.  The GENERIC-AGGREGATE-VPN-IPv4
|  (respectively, GENERIC-AGGREGATE-VPN-IPv6) SESSION object should appear
   in all RSVP messages that ordinarily contain a GENERIC-AGGREGATE-IPv4
   (respectively, GENERIC-AGGREGATE-IPv6) SESSION object as defined in
   [RFC4860] and are sent between ingress PE and egress PE in either
   direction.  [...]

Notes:

Rationale:
a) missing articles [editorial]
b) reference to wrong object

RFC 6020, "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", October 2010

Source of RFC: netmod (ops)

Errata ID: 2949
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Andy Bierman
Date Reported: 2011-08-28
Verifier Name: Dan Romascanu
Date Verified: 2011-09-05

Section 12 says:

(top of page 149)

 leafref-specification =
                         ;; these stmts can appear in any order
                         path-stmt stmtsep
                         [require-instance-stmt stmtsep]

It should say:

 leafref-specification = path-stmt stmtsep

Notes:

require-instance-stmt not allowed in leafref

Errata ID: 3087
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin Bjorklund
Date Reported: 2012-01-09
Verifier Name: Dan Romascanu
Date Verified: 2012-01-11

Section 12 says:

   deviate-add-stmt    = deviate-keyword sep add-keyword optsep
                         (";" /
                          "{" stmtsep
                              [units-stmt stmtsep]
                              *(must-stmt stmtsep)
                              *(unique-stmt stmtsep)
                              [default-stmt stmtsep]
                              [config-stmt stmtsep]
                              [mandatory-stmt stmtsep]
                              [min-elements-stmt stmtsep]
                              [max-elements-stmt stmtsep]
                          "}")

   deviate-delete-stmt = deviate-keyword sep delete-keyword optsep
                         (";" /
                          "{" stmtsep
                              [units-stmt stmtsep]
                              *(must-stmt stmtsep)
                              *(unique-stmt stmtsep)
                              [default-stmt stmtsep]
                          "}")

   deviate-replace-stmt = deviate-keyword sep replace-keyword optsep
                         (";" /
                          "{" stmtsep
                              [type-stmt stmtsep]
                              [units-stmt stmtsep]
                              [default-stmt stmtsep]
                              [config-stmt stmtsep]
                              [mandatory-stmt stmtsep]
                              [min-elements-stmt stmtsep]
                              [max-elements-stmt stmtsep]
                          "}")

It should say:

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

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

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

Notes:

The comment "these stmts can appear in any order" is missing from these three statements.

Errata ID: 3094
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Emmanuel Nataf
Date Reported: 2012-01-20
Verifier Name: Dan Romascanu
Date Verified: 2012-01-23

Section 12 says:

   bit-stmt            = bit-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [position-stmt stmtsep]
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                            "}"
                          "}")

It should say:

   bit-stmt            = bit-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [position-stmt stmtsep]
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                          "}")

Notes:

An extra "}"

Errata ID: 3288
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin Björklund
Date Reported: 2012-07-20
Verifier Name: Benoit Claise
Date Verified: 2012-07-26

Section 7.12.1 says:

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | augment      | 7.15    | 0..1        |
                 | description  | 7.19.3  | 0..1        |
                 | if-feature   | 7.18.2  | 0..n        |
                 | refine       | 7.12.2  | 0..1        |
                 | reference    | 7.19.4  | 0..1        |
                 | status       | 7.19.2  | 0..1        |
                 | when         | 7.19.5  | 0..1        |
                 +--------------+---------+-------------+

It should say:

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | augment      | 7.15    | 0..n        |
                 | description  | 7.19.3  | 0..1        |
                 | if-feature   | 7.18.2  | 0..n        |
                 | refine       | 7.12.2  | 0..n        |
                 | reference    | 7.19.4  | 0..1        |
                 | status       | 7.19.2  | 0..1        |
                 | when         | 7.19.5  | 0..1        |
                 +--------------+---------+-------------+

Notes:

The cardinality for 'augment' and 'refine' is '0..n'

Errata ID: 3289
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin Björklund
Date Reported: 2012-07-20
Verifier Name: Benoit Claise
Date Verified: 2012-07-26

Section 12 says:

   descendant-schema-nodeid =
                         node-identifier
                         absolute-schema-nodeid

It should say:

   descendant-schema-nodeid =
                         node-identifier
                         [absolute-schema-nodeid]

Notes:

A single node identifier is a valid descendant-schema-nodeid.

Errata ID: 3290
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin Björklund
Date Reported: 2012-07-20
Verifier Name: Benoit Claise
Date Verified: 2012-07-26

Section 12 says:

   decimal64-specification = fraction-digits-stmt

It should say:

   decimal64-specification = ;; these stmts can appear in any order
                             fraction-digits-stmt
                             [range-stmt stmtsep]

Notes:

A decimal64 type can be restricted with the "range" statement.

Errata ID: 3470
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ladislav Lhotka
Date Reported: 2013-01-24
Verifier Name: Benoit Claise
Date Verified: 2013-02-12

Section 7.16.2 says:

An identity MUST NOT reference itself, neither directly nor 
indirectly through a chain of other identities.

It should say:

The derivation of identities has the following properties:

o It is irreflexive, which means that an identity is not derived from 
  itself.

o It is transitive, which means that if identity B is derived from A
  and C is derived from B, then C is also derived from A.

Notes:

The desired properties of identity derivation are not clearly stated. The discussion in the NETMOD mailing led to a general agreement that identity derivation is supposed to be irreflexive and transitive. These two properties together also eliminate the possibility of a circular derivation.

Errata ID: 3493
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jernej Tuljak
Date Reported: 2013-02-24
Verifier Name: Benoit Claise
Date Verified: 2013-02-24

Section 12 says:

value-stmt          = value-keyword sep integer-value stmtend

It should say:

value-stmt          = value-keyword sep integer-value-arg-str stmtend

integer-value-arg-str   = < a string that matches the rule
                           integer-value-arg >

integer-value-arg       = integer-value

Notes:

Value statement should follow the rules for specifying YANG statement arguments. Current grammar does not allow a quoted string to appear as an argument to a value-stmt. Published IETF YANG modules exist which assume a quoted string may appear as an argument to this statement (eg. ietf-inet-types).

Errata ID: 3495
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jernej Tuljak
Date Reported: 2013-02-25
Verifier Name: Benoit Claise
Date Verified: 2013-02-28

Section 12 says:

   revision-stmt       = revision-keyword sep revision-date optsep
                         (";" /
                          "{" stmtsep
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                          "}")

It should say:

   revision-stmt       = revision-keyword sep revision-date optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                          "}")

Notes:

The comment "these stmts can appear in any order" is missing from this statement.

Errata ID: 3832
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Chris LaBauve
Date Reported: 2013-12-12
Verifier Name: Benoit Claise
Date Verified: 2013-12-13

Section 7.4.1 says:

               +------------------+---------+-------------+
               | substatement     | section | cardinality |
               +------------------+---------+-------------+
               | bit              | 9.7.4   | 0..n        |
               | enum             | 9.6.4   | 0..n        |
               | length           | 9.4.4   | 0..1        |
               | path             | 9.9.2   | 0..1        |
               | pattern          | 9.4.6   | 0..n        |
               | range            | 9.2.4   | 0..1        |
               | require-instance | 9.13.2  | 0..1        |
               | type             | 7.4     | 0..n        |
               +------------------+---------+-------------+

It should say:

               +------------------+---------+-------------+
               | substatement     | section | cardinality |
               +------------------+---------+-------------+
               | base             | 9.10.2  | 0..1        |
               | bit              | 9.7.4   | 0..n        |
               | enum             | 9.6.4   | 0..n        |
               | fraction-digits  | 9.3.4   | 0..1        |
               | length           | 9.4.4   | 0..1        |
               | path             | 9.9.2   | 0..1        |
               | pattern          | 9.4.6   | 0..n        |
               | range            | 9.2.4   | 0..1        |
               | require-instance | 9.13.2  | 0..1        |
               | type             | 7.4     | 0..n        |
               +------------------+---------+-------------+

Notes:

9.3.4. states 'The "fraction-digits" statement, which is a substatement to the "type" statement' but 7.4.1 does not list "fraction-digits" as one of the substatements of "type".

9.10.2. states 'The "base" statement, which is a substatement to the "type" statement' but 7.4.1 does not list "base" as one of the substatements of "type".

Errata ID: 3835
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Chris LaBauve
Date Reported: 2013-12-12
Verifier Name: Benoit Claise
Date Verified: 2013-12-13

Section 12 says:

   type-body-stmts     = numerical-restrictions /
                         decimal64-specification /
                         string-restrictions /
                         enum-specification /
                         leafref-specification /
                         identityref-specification /
                         instance-identifier-specification /
                         bits-specification /
                         union-specification

It should say:

   type-body-stmts     = numerical-restrictions /
                         decimal64-specification /
                         string-restrictions /
                         enum-specification /
                         leafref-specification /
                         identityref-specification /
                         instance-identifier-specification /
                         bits-specification /
                         union-specification / 
                         binary-specification

   binary-specification = [length-stmt stmtsep]

Notes:

Grammar rule 'type-body-stmts' does not provide for the case when type is 'binary'; this would be a rule allowing 0 or 1 length substatements according to 9.8.1.

Errata ID: 3842
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ladislav Lhotka
Date Reported: 2013-12-13
Verifier Name: Benoit Claise
Date Verified: 2013-12-17

Section 9.4.4 says:

It is used to restrict the built-in type "string", or types derived
from "string".

It should say:

It is used to restrict the built-in types "string" and "binary", or
types derived from them.

Notes:

The "length" statement can also restrict the "binary" type. See also erratum 3835.

Errata ID: 3871
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jonathan Hansford
Date Reported: 2014-01-23
Verifier Name: Benoit Claise
Date Verified: 2014-02-01

Section 9.6.4.2 says:

If a value is not specified, then one will be automatically assigned.
If the "enum" substatement is the first one defined, the assigned
value is zero (0); otherwise, the assigned value is one greater than
the current highest enum value.

It should say:

If a value is not specified, then one will be automatically assigned.
If the "enum" substatement is the first one defined, the assigned
value is zero (0); otherwise, the assigned value is one greater than
the current highest enum value (that is, the highest enum value,
implicit or explicit, prior to the current "enum" substatement in
the parent "type" statement).

Notes:

Clarification that 'current highest' does not refer to all enum values, implicit or explicit, in the parent "type" statement but only to those that precede the current "enum" substatement.

Errata ID: 3872
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jonathan Hansford
Date Reported: 2014-01-23
Verifier Name: Benoit Claise
Date Verified: 2014-02-01

Section 9.7.4.2 says:

If a bit position is not specified, then one will be automatically
assigned. If the "bit" substatement is the first one defined, the
assigned value is zero (0); otherwise, the assigned value is one
greater than the current highest bit position.

It should say:

If a bit position is not specified, then one will be automatically
assigned. If the "bit" substatement is the first one defined, the
assigned value is zero (0); otherwise, the assigned value is one
greater than the current highest bit position (that is, the
highest bit position, implicit or explicit, prior to the current
"bit" substatement in the parent "type" statement).

Notes:

Clarification that 'current highest' does not refer to all bit positions, implicit or explicit, in the parent "type" statement but only to those that precede the current "bit" substatement.

Errata ID: 4282
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Cesar Crusius
Date Reported: 2015-02-27
Verifier Name: Benoit Claise
Date Verified: 2015-03-11

Section 12 says:

unknown-statement   = prefix ":" identifier [sep string] optsep
                      (";" / "{" *unknown-statement2 "}") 
unknown-statement2   = [prefix ":"] identifier [sep string] optsep
                      (";" / "{" *unknown-statement2 "}") 

It should say:

unknown-statement   = prefix ":" identifier [sep string] optsep
                    (";" / "{" optsep *(unknown-statement2 optsep) "}")
unknown-statement2   = [prefix ":"] identifier [sep string] optsep
                     (";" / "{" optsep *(unknown-statement2 optsep) "}")

Errata ID: 4283
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Cesar Crusius
Date Reported: 2015-02-28
Verifier Name: Benoit Claise
Date Verified: 2015-03-11

Section 12 says:

stmtend = ";" / "{" *unknown_statement "}"

It should say:

stmtend = optsep (";" / "{" stmtsep "}") stmtsep

Notes:

Note1: As specified, there are no spaces allowed between the unknown statements, and between the braces and the unknown statements.

Notes2:
The original "stmtend" rule does not allow for spaces between unknown
statements, which requires the "*unknown-statement" fix in "stmtend".

There is at least one place ("revision-date-stmt") where "stmtend" end
is not preceded by "optsep". Instead of fixing those rules, it is better to
include "optsep" in "stmtend" itself, since it should always be present.

On the same note, almost all "stmtend" uses are followed by a
"stmtsep", and any cases where that does not happen are probably an error, so again it is better to make that explicit in the "stmtend" rule itself.

With the change in this errata, there will be a lot of rules in the
ABNF with redundant (but not technically incorrect) "optsep" and "stmtsep" parts, as for example

module-header-stmts = ;; these stmts can appear in any order
[yang-version-stmt stmtsep]
namespace-stmt stmtsep
prefix-stmt stmtsep

namespace-stmt = namespace-keyword sep uri-str optsep stmtend

which now could be replaced with

module-header-stmts = ;; these stmts can appear in any order
[yang-version-stmt]
namespace-stmt
prefix-stmt

namespace-stmt = namespace-keyword sep uri-str stmtend

These changes should probably be incorporated into the next ABNF
revision.

Errata ID: 4292
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Cesar Crusius
Date Reported: 2015-03-07
Verifier Name: Benoit Claise
Date Verified: 2015-03-10

Section 12 says:

   type-stmt           = type-keyword sep identifier-ref-arg-str optsep
                         (";" /
                          "{" stmtsep
                              type-body-stmts
                          "}")

It should say:

   type-stmt           = type-keyword sep identifier-ref-arg-str optsep
                         (";" /
                          "{" stmtsep
                              [ type-body-stmts ]
                          "}")

Notes:

Every statement that can end with a single ';' should also accept ending with '{ stmtsep }' (that is what the 'stmtend' rule implies). This is the only instance I found so far of a statement that does not follow this rule.

The other option would be to replace all ";" in rules like that with 'stmtend'.

Errata ID: 4911
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ladislav Lhotka
Date Reported: 2017-01-18
Verifier Name: Benoit Claise
Date Verified: 2017-01-23

Section 6.1.3 says:

Within a double-quoted string (enclosed within " "), a backslash
character introduces a special character, which depends on the
character that immediately follows the backslash:

 \n      new line
 \t      a tab character
 \"      a double quote
 \\      a single backslash

It should say:

Within a double-quoted string (enclosed within " "), a backslash
character introduces a special character, which depends on the
character that immediately follows the backslash:

 \n      new line
 \t      a tab character
 \"      a double quote
 \\      a single backslash


The interpretation of any character other than the ones listed above
following a backslash is undefined. Authors are advised to avoid using
such backslash sequences in double-quoted strings in their YANG
modules.

Notes:

The text doesn't state whether other characters may follow the backslash, and if yes, what it means. Existing implementations have used three approaches:

1. report an error if another character follows the backslash
2. keep only the character following the backslash, i.e., for example, "\x" is the same as "x".
3. keep both the backslash and the character following it.

This ambiguity is undesirable and YANG 1.1 [RFC 7950] explicitly adopted option #1. However, many modules are still being written using YANG version 1.0, so it is important to clarify this issue in RFC 6020 as well.

RFC 6022, "YANG Module for NETCONF Monitoring", October 2010

Source of RFC: netconf (ops)

Errata ID: 4950
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Andreas Walden
Date Reported: 2017-02-24
Verifier Name: Benoit Claise
Date Verified: 2017-03-10

Section 4.2 (2,3) says:

<get-schema
           xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
             <identifer>bar</identifer>
             <version>2008-06-01</version>
           </get-schema>

a. Via <get-schema> using identifer parameter:

 <get-schema
         xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
           <identifer>bar-types</identifer>
         </get-schema>

It should say:

<get-schema
           xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
             <identifier>bar</identifier>
             <version>2008-06-01</version>
           </get-schema>

a. Via <get-schema> using identifier parameter:

 <get-schema
         xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
           <identifier>bar-types</identifier>
         </get-schema>

RFC 6026, "Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE Requests", September 2010

Source of RFC: sipcore (rai)

Errata ID: 2538
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-09-30
Verifier Name: Robert Sparks
Date Verified: 2010-10-07

Section 7.1, pg.6 says:

[[ last paragraph on page 6: ]]

   Figures 1 and 2 show the parts of the INVITE server state machine
   that have changed.  The entire new INVITE server state machine is
|  shown in Figure 5.

It should say:

   Figures 1 and 2 show the parts of the INVITE server state machine
   that have changed.  The entire new INVITE server state machine is
|  shown in Figure 7.

Notes:

- qualified as Technical because of importance of correct pointer;
- apparently this detail has been missed when the Figures in the
document have been renumbered (#5 --> #7 and #4 --> #5) to achieve
the relationship to RFC 3261 explained in Section 8 (top of page 11):

[...] This document
intentionally does not contain a Figure 4 or Figure 6 so that the
labels for Figures 5 and 7 are identical to the labels of the figures
they are replacing in RFC 3261.

Errata ID: 2539
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-10-01
Verifier Name: Robert Sparks
Date Verified: 2010-10-07

Section 8.4, pg.12 says:

|8.4.  Pages 126 through 128

   Section 17.1.1.2.  Replace paragraph 7 (starting "When in either")
   through the end of the section with:

It should say:

|8.4.  Pages 126 through 129

   Section 17.1.1.2.  Replace paragraph 7 (starting "When in either")
   through the end of the section with:

Notes:

Rationale:
In RFC 3261, Section 17.1.1.2. extends to mid-page 129.
So if the quoted text is correct, the section headline
here is strongly misleading, contradicts the text, and
hence needs adjustment.
Since the textual scope of the change is at the heart of
this RFC, this Errata note is classified as Technical.

RFC 6029, "A Survey on Research on the Application-Layer Traffic Optimization (ALTO) Problem", October 2010

Source of RFC: IRTF

Errata ID: 3097
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Wes Eddy
Date Reported: 2012-01-27
Verifier Name: Lars Eggert
Date Verified: 2012-01-30

Section 2.1 says:

In such a technique, given a cost function C, a set
of vertexes V and their corresponding edges, the triangle inequality
holds if for any triple {a, b, c} in V, C(a, c) is always less than
or equal to C(a, g) + C(b, c).

It should say:

In such a technique, given a cost function C, a set
of vertexes V and their corresponding edges, the triangle inequality
holds if for any triple {a, b, c} in V, C(a, c) is always less than
or equal to C(a, b) + C(b, c).

Notes:

A 'g' instead of a 'b' appears in the triangle inequality description.

RFC 6030, "Portable Symmetric Key Container (PSKC)", October 2010

Source of RFC: keyprov (sec)

Errata ID: 2759
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip Hoyer
Date Reported: 2011-03-30
Verifier Name: Sean Turner
Date Verified: 2011-03-31

Section 11 says:

     <xs:complexType name="AlgorithmParametersType">
          <xs:choice>



Hoyer, et al.                Standards Track                   [Page 42]

RFC 6030         Portable Symmetric Key Container (PSKC)    October 2010


               <xs:element name="Suite" type="xs:string" minOccurs="0"/>
               <xs:element name="ChallengeFormat" minOccurs="0">
                    <xs:complexType>
                         <xs:attribute name="Encoding"
                              type="pskc:ValueFormatType"
                                                      use="required"/>
                         <xs:attribute name="Min"
                              type="xs:unsignedInt" use="required"/>
                         <xs:attribute name="Max"
                              type="xs:unsignedInt" use="required"/>
                         <xs:attribute name="CheckDigits"
                              type="xs:boolean" default="false"/>
                    </xs:complexType>
               </xs:element>
               <xs:element name="ResponseFormat" minOccurs="0">
                    <xs:complexType>
                         <xs:attribute name="Encoding"
                              type="pskc:ValueFormatType"
                                                      use="required"/>
                         <xs:attribute name="Length"
                              type="xs:unsignedInt" use="required"/>
                         <xs:attribute name="CheckDigits"
                              type="xs:boolean" default="false"/>
                    </xs:complexType>
               </xs:element>
               <xs:element name="Extensions"
                    type="pskc:ExtensionsType" minOccurs="0"
                    maxOccurs="unbounded"/>
          </xs:choice>
     </xs:complexType>

It should say:

     <xs:complexType name="AlgorithmParametersType">
          <xs:sequence>



Hoyer, et al.                Standards Track                   [Page 42]

RFC 6030         Portable Symmetric Key Container (PSKC)    October 2010


               <xs:element name="Suite" type="xs:string" minOccurs="0"/>
               <xs:element name="ChallengeFormat" minOccurs="0">
                    <xs:complexType>
                         <xs:attribute name="Encoding"
                              type="pskc:ValueFormatType"
                                                      use="required"/>
                         <xs:attribute name="Min"
                              type="xs:unsignedInt" use="required"/>
                         <xs:attribute name="Max"
                              type="xs:unsignedInt" use="required"/>
                         <xs:attribute name="CheckDigits"
                              type="xs:boolean" default="false"/>
                    </xs:complexType>
               </xs:element>
               <xs:element name="ResponseFormat" minOccurs="0">
                    <xs:complexType>
                         <xs:attribute name="Encoding"
                              type="pskc:ValueFormatType"
                                                      use="required"/>
                         <xs:attribute name="Length"
                              type="xs:unsignedInt" use="required"/>
                         <xs:attribute name="CheckDigits"
                              type="xs:boolean" default="false"/>
                    </xs:complexType>
               </xs:element>
               <xs:element name="Extensions"
                    type="pskc:ExtensionsType" minOccurs="0"
                    maxOccurs="unbounded"/>
          </xs:sequence>
     </xs:complexType>

Notes:

The AlgorithmParameter should have a sequqnce of subelements not a choice as for Challenge/Response algorithms it MUST be possible to define both the ChallengeFormat and the Response Format at the same time. Currently the schema uses <xs:choice> which allows either <ChallengeFormat> or <ResponseFormat> but not both.
This correction will bring it in line with intended description in Section 4.3.4

Errata ID: 3418
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Simon Josefsson
Date Reported: 2012-11-26
Verifier Name: Sean Turner
Date Verified: 2013-03-16

Section 7 and 11 says:

Section 7:
       <Signature>

Section 11:
               <xs:element name="Signature"
                    type="ds:SignatureType" minOccurs="0"/>

It should say:

Section 7:
       <ds:Signature>

Section 11:
               <xs:element ref="ds:Signature" minOccurs="0"/>

Notes:

It seems the Signature element is in the wrong namespace, making PSKC incompatible with the XMLDsig specification.

There is a thread on this on the XMLSec mailing list:

http://thread.gmane.org/gmane.text.xml.xmlsec/4178

Both Aleksey Sanin (author of the XMLSec library) and G. Ken Holman (XML
expert) appear to believe this is an error in the XML schema for PSKC:

http://thread.gmane.org/gmane.text.xml.xmlsec/4178/focus=4181
http://thread.gmane.org/gmane.text.xml.xmlsec/4178/focus=4185

This was brought up on the keyprov mailing list:

http://thread.gmane.org/gmane.ietf.keyprov/1011

/Simon

Errata ID: 2621
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Simon Josefsson
Date Reported: 2010-11-10
Verifier Name: Tim Polk
Date Verified: 2011-03-26

Section 10.2 says:

The <Usage> element MAY be present, but no attribute of the 
<Usage> element is required.

It should say:

The <AlgorithmParameters> element MAY be present, but no attribute 
of the <AlgorithmParameters> element is required.

Notes:

The <Usage> field was renamed between draft -02 and -03 but this section was not updated.

Errata ID: 3364
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Simon Josefsson
Date Reported: 2012-09-25
Verifier Name: Sean Turner
Date Verified: 2013-03-16

Section 3 says:

      ----------------        ----------------
      | KeyPackage   |    0..1| DeviceInfo   |
      |--------------|--------|--------------|
      |              |--      | SerialNumber |
      ----------------  |     | Manufacturer |
              |         |     | ....         |
              |         |     ----------------
 

It should say:

      ----------------        ----------------
      | KeyPackage   |    0..1| DeviceInfo   |
      |--------------|--------|--------------|
      |              |--      | SerialNo     |
      ----------------  |     | Manufacturer |
              |         |     | ....         |
              |         |     ----------------
 

Notes:

Figure 1 mentions a DeviceInfo field called "SerialNumber" however it should be "SerialNo".

Errata ID: 3370
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Simon Josefsson
Date Reported: 2012-10-03
Verifier Name: Sean Turner
Date Verified: 2013-03-16

Section 6.3 says:

       id="KC0001"

It should say:

       Id="KC0001"

Notes:

The PSKC data in figure 8 does not pass a XML Schema validation -- the reason is a typo in the Id attribute name.

RFC 6031, "Cryptographic Message Syntax (CMS) Symmetric Key Package Content Type", December 2010

Source of RFC: keyprov (sec)

Errata ID: 2760
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sean Turner
Date Reported: 2011-03-31
Verifier Name: Stephen Farrell
Date Verified: 2011-04-07

Section 3.2.7 & A.2 says:

PSKCAlgorithmParameters ::= CHOICE {
     suite                UTF8String,
     challengeFormat  [0] ChallengeFormat,
     responseFormat   [1] ResponseFormat,
     ... }

It should say:

PSKCAlgorithmParameters ::= SEQUENCE {
     suite                UTF8String,
     challengeFormat  [0] ChallengeFormat,
     responseFormat   [1] ResponseFormat,
     ... }

Notes:

This aligns with the errata on RFC 6030, which is where the syntax for this attribute comes from. The errata can be found here http://www.rfc-editor.org/errata_search.php?rfc=6030&eid=2759

RFC 6038, "Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features", October 2010

Source of RFC: ippm (ops)

Errata ID: 4260
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Huck Zhao
Date Reported: 2015-02-04
Verifier Name: Spencer Dawkins
Date Verified: 2016-07-04

Section 5.2.1 says:

   ... When the Reflect Octets mode is selected, the
   Session-Sender SHALL use the following TWAMP-Test Packet Format in
   Unauthenticated mode:

It should be Session-Reflector that SHALL use the following format.

It should say:

   ... When the Reflect Octets mode is selected, the
   Session-Reflector SHALL use the following TWAMP-Test Packet Format in
   Unauthenticated mode:

Notes:

I confirmed this with Al Morton via e-mail.

Errata ID: 5549
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Prabhjot Singh Sethi
Date Reported: 2018-11-07
Verifier Name: Mirja Kühlewind
Date Verified: 2020-03-04

Section 5.1.5 says:

In this combined mode, the Packet Padding to be reflected follows the
27 MBZ octets.  In Authenticated or Encrypted modes, the Packet
Padding to be reflected follows the 56 MBZ octets.

It should say:

In this combined mode, the Packet Padding to be reflected follows the
27 MBZ octets.  In Authenticated or Encrypted modes, the Packet
Padding to be reflected follows the 64 MBZ octets.

Notes:

To achieve symmetrical size in authenticated and encrypted mode length of mbz field needs to be 64 octects instead of 56 octects.

Errata ID: 6408
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2021-01-25
Verifier Name: Martin Duke
Date Verified: 2021-01-26

Section 5.1.3 says:

   When using the truncation process in TWAMP alone, see Section 4.2.1
   of [RFC5357], the Session-Sender MUST append sufficient Packet
   Padding octets to allow the same IP packet payload lengths to be used
   in each direction of transmission (this is usually desirable).  To
   compensate for the Session-Reflector's larger test packet format, the
   Session-Sender MUST append at least 27 octets of padding in
   Unauthenticated mode, and at least 56 octets in Authenticated and
   Encrypted modes.  The sizes of TWAMP-Test protocol packets and the
   resulting truncated padding to achieve equal packet sizes in both
   directions are shown in the table below:









Morton & Ciavattone          Standards Track                   [Page 11]

RFC 6038             Reflect Octets & Symmetric Size        October 2010


    +-------------------+----------------------+---------------------+
    | Octets in:        | Unauthenticated Mode | Auth/Encrypted Mode |
    +-------------------+----------------------+---------------------+
    | Reflector Header  | 41                   | 104                 |
    | Sender Header     | 14                   | 48                  |
    | Truncated Padding | 27                   | 56                  |
    +-------------------+----------------------+---------------------+

                       TWAMP-Test Padding Truncation

   When using the Reflect Octets mode simultaneously with the truncation
   process that TWAMP recommends in Section 4.2.1 of [RFC5357], the
   Session-Sender MUST append at least 27 octets of padding plus the
   Length of the padding to reflect octets when operating in
   Unauthenticated mode.  The Session-Sender MUST append at least 56
   octets of padding plus the Length of the padding to reflect octets
   when operating in Authenticated and Encrypted modes.

It should say:

   When using the truncation process in TWAMP alone, see Section 4.2.1
   of [RFC5357], the Session-Sender MUST append sufficient Packet
   Padding octets to allow the same IP packet payload lengths to be used
   in each direction of transmission (this is usually desirable).  To
   compensate for the Session-Reflector's larger test packet format, the
   Session-Sender MUST append at least 27 octets of padding in
   Unauthenticated mode, and at least 64 octets in Authenticated and
   Encrypted modes.  The sizes of TWAMP-Test protocol packets and the
   resulting truncated padding to achieve equal packet sizes in both
   directions are shown in the table below:









Morton & Ciavattone          Standards Track                   [Page 11]

RFC 6038             Reflect Octets & Symmetric Size        October 2010


    +-------------------+----------------------+---------------------+
    | Octets in:        | Unauthenticated Mode | Auth/Encrypted Mode |
    +-------------------+----------------------+---------------------+
    | Reflector Header  | 41                   | 112                 |
    | Sender Header     | 14                   | 48                  |
    | Truncated Padding | 27                   | 64                  |
    +-------------------+----------------------+---------------------+

                       TWAMP-Test Padding Truncation

   When using the Reflect Octets mode simultaneously with the truncation
   process that TWAMP recommends in Section 4.2.1 of [RFC5357], the
   Session-Sender MUST append at least 27 octets of padding plus the
   Length of the padding to reflect octets when operating in
   Unauthenticated mode.  The Session-Sender MUST append at least 64
   octets of padding plus the Length of the padding to reflect octets
   when operating in Authenticated and Encrypted modes.

Notes:

Incorrect header sizes (104 instead of 112) and the required padding size (56 instead of 64) for modes with authentication and encryption.

Errata ID: 6409
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2021-01-25
Verifier Name: Martin Duke
Date Verified: 2021-01-26

Section 4.2 says:

   The Padding Length SHOULD be >= 56 octets when specifying a test
   session using the Authenticated or Encrypted TWAMP-Test modes to
   allow for the truncation process that TWAMP recommends, see Section
   4.2.1 of [RFC5357].

   The Padding Length SHALL be > the Length of padding to reflect when
   specifying a test session using the OPTIONAL Reflect Octets mode.

   In Unauthenticated TWAMP-Test mode, the Padding Length SHALL be >= 27
   + Length of padding to reflect octets when specifying a test session
   using both the OPTIONAL Reflect Octets mode and the truncation
   process that TWAMP recommends, see Section 4.2.1 of [RFC5357].

   In Authenticated or Encrypted TWAMP-Test modes, the Padding Length
   SHALL be >= 56 + Length of padding to reflect octets when specifying
   a test session using both the OPTIONAL Reflect Octets mode and the
   truncation process that TWAMP recommends, see Section 4.2.1 of
   [RFC5357].

It should say:

   The Padding Length SHOULD be >= 64 octets when specifying a test
   session using the Authenticated or Encrypted TWAMP-Test modes to
   allow for the truncation process that TWAMP recommends, see Section
   4.2.1 of [RFC5357].

   The Padding Length SHALL be > the Length of padding to reflect when
   specifying a test session using the OPTIONAL Reflect Octets mode.

   In Unauthenticated TWAMP-Test mode, the Padding Length SHALL be >= 27
   + Length of padding to reflect octets when specifying a test session
   using both the OPTIONAL Reflect Octets mode and the truncation
   process that TWAMP recommends, see Section 4.2.1 of [RFC5357].

   In Authenticated or Encrypted TWAMP-Test modes, the Padding Length
   SHALL be >= 64 + Length of padding to reflect octets when specifying
   a test session using both the OPTIONAL Reflect Octets mode and the
   truncation process that TWAMP recommends, see Section 4.2.1 of
   [RFC5357].

Notes:

Invalid required padding size (56 instead of 64) for modes with authentication and encryption.

Errata ID: 6410
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2021-01-25
Verifier Name: Martin Duke
Date Verified: 2021-01-26

Section 5.2.1 says:

   Section 4.2.1 of [RFC5357] recommends a padding truncation process
   for use in TWAMP.  When using that process in conjunction with the
   Reflect Octets mode, the Session-Reflector MUST reflect the
   designated octets from the Session-Sender's test packet in the Packet
   Padding (from Session-Sender) field, and MAY re-use additional Packet
   Padding from the Session-Sender.  The Session-Reflector MUST truncate
   the padding such that the highest number octets are discarded, and
   the test packet length equals the Session-Sender's packet length.
   When using the recommended truncation process, the Session-Reflector
   MUST truncate exactly 27 octets of padding in Unauthenticated mode,
   and exactly 56 octets in Authenticated and Encrypted modes.

It should say:

   Section 4.2.1 of [RFC5357] recommends a padding truncation process
   for use in TWAMP.  When using that process in conjunction with the
   Reflect Octets mode, the Session-Reflector MUST reflect the
   designated octets from the Session-Sender's test packet in the Packet
   Padding (from Session-Sender) field, and MAY re-use additional Packet
   Padding from the Session-Sender.  The Session-Reflector MUST truncate
   the padding such that the highest number octets are discarded, and
   the test packet length equals the Session-Sender's packet length.
   When using the recommended truncation process, the Session-Reflector
   MUST truncate exactly 27 octets of padding in Unauthenticated mode,
   and exactly 64 octets in Authenticated and Encrypted modes.

Notes:

Invalid required padding size (56 instead of 64) for modes with authentication and encryption.

RFC 6044, "Mapping and Interworking of Diversion Information between Diversion and History-Info Headers in the Session Initiation Protocol (SIP)", October 2010

Note: This RFC has been obsoleted by RFC 7544

Source of RFC: INDEPENDENT

Errata ID: 3071
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Marianne MOHALI
Date Reported: 2012-01-04
Verifier Name: Nevil Brownlee
Date Verified: 2012-01-04

Section 5 says:

"unavailable"-----------------------------404

It should say:

"unavailable"-----------------------------503

Notes:

This correction is done to be consistent with the reverse mapping and the fact that "unavailable" reason is used for unreachability cases.

Errata ID: 2603
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hadriel Kaplan
Date Reported: 2010-11-04
Verifier Name: Nevil Brownlee
Date Verified: 2012-01-04

Section 7.1 says:

   INVITE last_diverting_target
   Diversion:
   diverting_user3_address;reason=unconditional;counter=1;privacy=off,
   diverting_user2_address;reason=user-busy;counter=1;privacy=full,
   diverting_user1_address;reason=no-answer;counter=1;privacy=off

It should say:

   INVITE last_diverting_target
   Diversion:
   <sip:diverting_user3_address>;reason=unconditional;counter=1;privacy=off,
   <sip:diverting_user2_address>;reason=user-busy;counter=1;privacy=full,
   <sip:diverting_user1_address>;reason=no-answer;counter=1;privacy=off

Notes:

The examples in section 7.1, 7.2, and 7.3 and also in 3.2 show the Diversion header field using an "address" that is not a SIP (or Tel) URI, and without the "<" ">" delimeters. That is not correct. It is confusing, because the History-Info examples show it correctly, and thus imply the two address formats are not the same and need to be interworked, whereas in fact they are both name-addr fields, and thus both need to have the "<" and ">", etc.

Errata ID: 2604
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hadriel Kaplan
Date Reported: 2010-11-04
Verifier Name: Nevil Brownlee
Date Verified: 2012-01-04

Section 7.1 says:

   History-Info:
   <sip: diverting_user1_address; privacy=none >; index=1,

It should say:

   History-Info:
   <sip:diverting_user1_address?Privacy=none>;index=1,

Notes:

The example does not show the "?" embedded URI header indicator for the Privacy header in the URI, but instead shows it as a URI parameter.

Errata ID: 2605
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hadriel Kaplan
Date Reported: 2010-11-04
Verifier Name: Nevil Brownlee
Date Verified: 2012-01-04

Section 3.1 says:

   History-Info:
   <sip: diverting_user1_addr?Privacy=none?Reason=SIP%3Bcause%
   3D302>;index=1,

It should say:

   History-Info:
   <sip: diverting_user1_addr?Privacy=none&Reason=SIP%3Bcause%
   3D302>;index=1,

Notes:

The example shows two embedded headers, but using two "?" tokens which is incorrect - there is only one "?" token, and all subsequent embedded headers need to use "&". (as per RFC 3261 ABNF rules)

Errata ID: 3077
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marianne Mohali
Date Reported: 2012-01-05
Verifier Name: Nevil Brownlee
Date Verified: 2012-04-11

Section 2.2.1 says:

|       |       |INVITE |       |       |       |     |       |        |
|       |       |------>|       |       |       |     |       |        |
|       |       |History-Info:  |       |       |     |       |        |
|       |       |<sip:proxyP1>; index=1,|       |     |       |        |
|       |       |<sip:userB>; index=1.1 |       |     |       |        |
|       |       |<sip:userC>; cause=302; index=1.1.1  |       |        |

It should say:

|       |       |INVITE |       |       |       |     |       |        |
|       |       |------>|       |       |       |     |       |        |
|       |       |History-Info:  |       |       |     |       |        |
|       |       |<sip:proxyP1>; index=1,|       |     |       |        |
|       |       |<sip:userB>; index=1.1,|       |     |       |        |
|       |       |<sip:userC; cause=302>; index=1.1.1  |       |        |

Notes:

The "cause" parameter is an URI parameter defined in RFC4458. So that, it is included in the SIP-URI which is represented by the name-addr parameter (between <>) of the History-Info header.
There was also a missing COMMA at the end of "index=1.1".

Errata ID: 3176
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Brett Tate
Date Reported: 2012-04-04
Verifier Name: Nevil Brownlee
Date Verified: 2012-04-11

Section 3.2 says:

Diversion:

diverting_user2_addr; reason="user-busy"; counter=1; privacy=full,
diverting_user1_addr; reason="unconditional"; counter=1; privacy=off

It should say:

Diversion:

<sip:diverting_user2_address>; reason=user-busy; counter=1; privacy=full,
<sip:diverting_user1_address>; reason=unconditional; counter=1; privacy=off

Notes:

Errata 2603 already reported that the example did not correctly contain name-addr values. This is to report that the selected reason values should not be within quotes since these values have been explicitly defined to be non quoted. More specifically, the quotes within the example add confusion since RFC 5806 examples had similar quoting issues for values defined without quotes.

RFC 6045, "Real-time Inter-network Defense (RID)", November 2010

Note: This RFC has been obsoleted by RFC 6545

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 2730
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kathleen Moriarty
Date Reported: 2011-02-23
Verifier Name: Sean Turner
Date Verified: 2011-06-28

Section 5. -Page 59 says:

 <xs:element name="TrafficType" default="Attack">

It should say:

 <xs:element name="TrafficType">

Notes:

A default should not have been included for TrafficType in the schema.

RFC 6047, "iCalendar Message-Based Interoperability Protocol (iMIP)", December 2010

Source of RFC: calsify (app)

Errata ID: 5447
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Julian Cowley
Date Reported: 2018-07-31
Verifier Name: Alexey Melnikov
Date Verified: 2018-09-04

Throughout the document, when it says:

ATTENDEE;RSVP=YES:mailto:foo2@example.com

It should say:

ATTENDEE;RSVP=TRUE:mailto:foo2@example.com

Notes:

In the examples that include the ATTENDEE property, there is a minor issue. According to RFC 5545, Section 3.2.17, the RSVP parameter value should be "TRUE" or "FALSE", not "YES" or "NO".

RFC 6056, "Recommendations for Transport-Protocol Port Randomization", January 2011

Source of RFC: tsvwg (wit)

Errata ID: 2750
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bjoern A. Zeeb
Date Reported: 2011-03-13
Verifier Name: Wes Eddy
Date Verified: 2011-04-01

Section 3.3 says:

3.3.1.  Algorithm 1: Simple Port Randomization Algorithm

-           if(check_suitable_port(port))

3.3.2.  Algorithm 2: Another Simple Port Randomization Algorithm

-           if(check_suitable_port(port))

It should say:

3.3.1.  Algorithm 1: Simple Port Randomization Algorithm

+           if(check_suitable_port(next_ephemeral))

3.3.2.  Algorithm 2: Another Simple Port Randomization Algorithm

+           if(check_suitable_port(next_ephemeral))

Notes:

For neither Algorithm 1 or 2 the pseudo code defines "port" as a valid variable.
The variable passed to check_suitable_port() should be "next_ephemeral" in these cases.
It looks like a copy and paste error. The technical meaning is still clear.

RFC 6063, "Dynamic Symmetric Key Provisioning Protocol (DSKPP)", December 2010

Source of RFC: keyprov (sec)

Errata ID: 2948
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sean Turner
Date Reported: 2011-08-28
Verifier Name: Stephen Farrell
Date Verified: 2011-11-13

Section 12.2 says:

URI:  urn:ietf:params:xml:ns:keyprov:dskpp

It should say:

URI:  urn:ietf:params:xml:schema:keyprov:dskpp

Notes:

Section 12.2 is the registration for the schema not the namespace, which is in Section 12.1. The URI for the schema ought to point to :schema: and not :ns:. It's in the IANA registry it just needs to be updated here.

Errata ID: 2999
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Gareth Richards
Date Reported: 2011-10-17
Verifier Name: Sean Turner
Date Verified: 2011-11-13

Section 4.2.4 says:

           DSKPP Client                         DSKPP Server
           ------------                         ------------
           E(K,R_C), AD          --->


   When this message is sent:
      The DSKPP Client will send this message immediately following a
      <KeyProvServerHello> message whose status was set to "Continue".

It should say:

           DSKPP Client                         DSKPP Server
           ------------                         ------------
           E(K,R_C), [AD]          --->

   When this message is sent:
      The DSKPP Client will send this message immediately following a
      <KeyProvServerHello> message whose status was set to "Continue".
      The AD element MUST be sent unless it was already sent in the
      KeyProvClientHello message.

Notes:

The AD is carried in the <KeyProvClientHello> if sent as a result of a trigger and so is optional in the <ekyProvClientNonce>.

RFC 6066, "Transport Layer Security (TLS) Extensions: Extension Definitions", January 2011

Note: This RFC has been updated by RFC 8446, RFC 8449, RFC 9325

Source of RFC: tls (sec)

Errata ID: 3283
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Brad Wetmore
Date Reported: 2012-07-12
Verifier Name: Sean Turner
Date Verified: 2012-07-17

Section Appendix A says:

Appendix A:     The Server Name extension...(deleted)... It is 
provided that the ServerNameList can contain more than only one 
name of any particular name_type.

It should say:

Appendix A:     The Server Name extension...deleted..It is 
provided that the ServerNameList can contain only one name 
of any particular name_type.

Notes:

Section 3 and Appendix A seem to be conflict with each other. Am I parsing something incorrectly here:

Section 3: The ServerNameList MUST NOT contain more than one name of the same name_type.

Appendix A: The Server Name extension...deleted..It is provided that the ServerNameList can contain more than only one name of any particular name_type.

I think the words "more than" were not supposed to appear in the final RFC.

Errata ID: 4817
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: ResponderIDs type is not defined anywhere.
Date Reported: 2016-10-03
Verifier Name: Stephen Farrell
Date Verified: 2016-10-05

Section 8 says:

In the OCSPStatusRequest, the "ResponderIDs" provides a list of OCSP
responders that the client trusts. 

It should say:

In the OCSPStatusRequest, the "ResponderID" provides a list of OCSP
responders that the client trusts.

or clearer 

In OCSPStatusRequest, the "responder_id_list" provides a list of
"ResponderID", OCSP responders that the client trusts.

Notes:

ResponderIDs is not defined anywhere within the document.

Quote of this section in RFC6961 section 2.2 (p.4) seem to have fixed this.

RFC 6068, "The 'mailto' URI Scheme", October 2010

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 4020
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: NARUSE, Yui
Date Reported: 2014-06-23
Verifier Name: Barry Leiba
Date Verified: 2014-07-01

Section 2. says:

   2.  <obs-local-part> and <NO-WS-CTL> as defined in [RFC5322] MUST NOT
       be used.

It should say:

   2.  <obs-local-part> and <obs-NO-WS-CTL> as defined in [RFC5322] MUST
       NOT be used.

Notes:

NO-WS-CTL doesn't exist in RFC5322; it was changed to obs-NO-WS-CTL.

A future update to "mailto" should consider other whitespace changes as well.

RFC 6081, "Teredo Extensions", January 2011

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: int

Errata ID: 2685
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Dave Thaler
Date Reported: 2011-01-18
Verifier Name: Brian Haberman
Date Verified: 2012-09-07

Section 9 says:

   Trailer Type  Usage                              Reference
   ------------  ---------------------------------  ---------
      0x01       Nonce Trailer                      RFC 6081
      0x02       Random Port Trailer                RFC 6081
      0x03       Alternate Address Trailer          RFC 6081
      0x04       Neighbor Discovery Option Trailer  RFC 6081

It should say:

   Trailer Type  Usage                              Reference
   ------------  ---------------------------------  ---------
      0x01       Nonce Trailer                      RFC 6081
      0x03       Alternate Address Trailer          RFC 6081
      0x04       Neighbor Discovery Option Trailer  RFC 6081
      0x05       Random Port Trailer                RFC 6081

Notes:

Section 4.5 is correct, and (normatively) defines the Random Port Trailer as having Trailer Type 0x05. However, the IANA Considerations section incorrectly lists it (informatively) as 0x02.

RFC 6090, "Fundamental Elliptic Curve Cryptography Algorithms", February 2011

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 3920
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Watson Ladd
Date Reported: 2014-03-15
Verifier Name: Kathleen Moriarty
Date Verified: 2014-07-01

Section Appendix F says:

Then, the product P3=(X3,Y3,Z3) = P1 * P2 is given by:

     if P1 is the point at infinity,
        P3 = P2
     else if P2 is the point at infinity,
        P3 = P1
     else if u is not equal to 0 but v is equal to 0,
        P3 = (0,1,0)
     else if both u and v are not equal to 0,
        X3 = v * (Z2 * (Z1 * u^2 - 2 * X1 * v^2) - v^3)
        Y3 = Z2 * (3 * X1 * u * v^2 - Y1 * v^3 - Z1 * u^3) + u * v^3
        Z3 = v^3 * Z1 * Z2
     else    // P2 equals P1, P3 = P1 * P1
         w = 3 * X1^2 + a * Z1^2
        X3 = 2 * Y1 * Z1 * (w^2 - 8 * X1 * Y1^2 * Z1)
        Y3 = 4 * Y1^2 * Z1 * (3 * w * X1 - 2 * Y1^2 * Z1) - w^3
        Z3 = 8 * (Y1 * Z1)^3

It should say:

Then, the product P3=(X3,Y3,Z3) = P1 * P2 is given by:

     if P1 is the point at infinity,
        P3 = P2
     else if P2 is the point at infinity,
        P3 = P1
     else if P1=-P2 as projective points
        P3 = (0,1,0)
     else if P1 does not equal P2
        X3 = v * (Z2 * (Z1 * u^2 - 2 * X1 * v^2) - v^3)
        Y3 = Z2 * (3 * X1 * u * v^2 - Y1 * v^3 - Z1 * u^3) + u * v^3
        Z3 = v^3 * Z1 * Z2
     else    // P2 equals P1, P3 = P1 * P1
         w = 3 * X1^2 + a * Z1^2
        X3 = 2 * Y1 * Z1 * (w^2 - 8 * X1 * Y1^2 * Z1)
        Y3 = 4 * Y1^2 * Z1 * (3 * w * X1 - 2 * Y1^2 * Z1) - w^3
        Z3 = 8 * (Y1 * Z1)^3

Notes:

The original algorithm was wrong and produces incorrect answers. There are several fixes that could take place.

RFC 6107, "Procedures for Dynamically Signaled Hierarchical Label Switched Paths", February 2011

Source of RFC: ccamp (rtg)

Errata ID: 3018
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alan Davey
Date Reported: 2011-11-10
Verifier Name: Adrian Farrel
Date Verified: 2011-11-12

Section 3.2 says:

   If the P-flag in the Actions field in the LSP_TUNNEL_INTERFACE_ID
   object in a Resv message is set (i.e., one) indicating that the LSP
   is not to be advertised as a link, this TLV SHOULD NOT be present and
   MUST be ignored if encountered.

It should say:

   If the P-flag in the Actions field in the LSP_TUNNEL_INTERFACE_ID
   object in a Path message is set (i.e., one) indicating that the LSP
   is not to be advertised as a link, this TLV SHOULD NOT be present and
   MUST be ignored if encountered.

Notes:

The change is s/Resv/Path/

RFC 6109, "La Posta Elettronica Certificata - Italian Certified Electronic Mail", April 2011

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 3661
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Joël Repiquet
Date Reported: 2013-06-17
Verifier Name: Barry Leiba
Date Verified: 2013-06-17

Section 2.1 says:

   To guarantee the verifiability of signatures on as many mail clients
   as possible, X.509v3 certificates used by certified email systems
   MUST abide by the profile found in section 6.5.

It should say:

   To guarantee the verifiability of signatures on as many mail clients
   as possible, X.509v3 certificates used by certified email systems
   MUST abide by the profile found in section 5.5.

RFC 6110, "Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content", February 2011

Note: This RFC has been updated by RFC 7952

Source of RFC: netmod (ops)

Errata ID: 3362
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jernej Tuljak
Date Reported: 2012-09-21
Verifier Name: Benoit Claise
Date Verified: 2012-10-22

Throughout the document, when it says:

Table of Contents
-----------------
OLD
      12.16. The @nma:unique Annotation ..............................74


Sec. 5.3, entry in Table 2:
---------------------------
OLD
        | @nma:unique               | 10.55              |      |

Sec. 10.55:
-----------
OLD

   This statement is mapped to the @nma:unique attribute.  ARGUMENT MUST
   be translated so that every node identifier in each of its components
   is prefixed with the namespace prefix of the local module, unless the
   prefix is already present.  The result of this translation then
   becomes the value of the @nma:unique attribute.

   For example, assuming that the local module prefix is "ex",

   unique "foo ex:bar/baz"

   is mapped to the following attribute/value pair:

   nma:unique="ex:foo ex:bar/ex:baz"

Sec. 11.2, second paragraph:
----------------------------
OLD

   In a Schematron schema generated by the second mapping step, the
   basic unit of organization is a rule represented by the <sch:rule>
   element.  The following NETMOD-specific annotations from the hybrid
   schema (henceforth called "semantic annotations") are mapped to
   corresponding Schematron rules: <nma:must>, @nma:key, @nma:unique,
   @nma:max-elements, @nma:min-elements, @nma:when, @nma:leafref, @nma:
   leaf-list, and also @nma:mandatory appearing as an attribute of <rng:
   choice> (see Section 11.2.1).

Sec. 12.16 (including its title):
---------------------------------
OLD

12.16.  The @nma:unique Annotation

   The mapping of this annotation is almost identical as for @nma:key,
   see Section 12.8, with two small differences:

   o  The value of @nma:unique is a list of descendant schema node
      identifiers rather than simple leaf names.  However, the XPath
      expressions specified in Section 12.8 work without any
      modifications if the descendant schema node identifiers are
      substituted for k_1, k_2, ..., k_n.

   o  The message appearing as the text of <sch:report> is different:
      "Violated uniqueness for list CONTELEM".

Appendix A:
-----------
OLD

  <define name="unique-attribute">
    <optional>
      <attribute name="nma:unique">
        <list>
          <data type="token"/>
        </list>
      </attribute>
    </optional>
  </define>

It should say:

Table of Contents
-----------------
NEW
      12.16. The <nma:unique> Annotation ..............................74

Sec. 5.3, entry in Table 2:
---------------------------
NEW
        | <nma:unique>              | 10.55              |      |

Sec. 10.55:
-----------

NEW

   This statement is mapped to the <nma:unique> element.  ARGUMENT MUST
   be translated so that every node identifier in each of its components
   is prefixed with the namespace prefix of the local module, unless the
   prefix is already present.  The result of this translation then
   becomes the value of the @tag attribute which is attached to the
   <nma:unique> element.

   For example, assuming that the local module prefix is "ex",

   unique "foo ex:bar/baz"

   is mapped to the following annotation element:

   <nma:unique tag="ex:foo ex:bar/ex:baz"/>

Sec. 11.2, second paragraph:
----------------------------
NEW

   In a Schematron schema generated by the second mapping step, the
   basic unit of organization is a rule represented by the <sch:rule>
   element.  The following NETMOD-specific annotations from the hybrid
   schema (henceforth called "semantic annotations") are mapped to
   corresponding Schematron rules: <nma:must>, <nma:unique>, @nma:key,
   @nma:max-elements, @nma:min-elements, @nma:when, @nma:leafref, @nma:
   leaf-list, and also @nma:mandatory appearing as an attribute of <rng:
   choice> (see Section 11.2.1).

Sec. 12.16 (including its title):
---------------------------------
12.16.  The <nma:unique> Annotation

   The mapping of this annotation is similar to @nma:key,
   see Section 12.8, with two small differences:

   o  The value of the @tag attribute of <nma:unique> is a list of
      descendant schema node identifiers rather than simple leaf names.
      However, the XPath expressions specified in Section 12.8 work
      without any modifications if the descendant schema node
      identifiers are substituted for k_1, k_2, ..., k_n.

   o  The message appearing as the text of <sch:report> is different:
      "Violated uniqueness of NODES", where NODES is the value of the
      @tag attribute.

Appendix A:
-----------
NEW

  <define name="unique-element">
    <element name="nma:unique">
      <attribute name="tag">
        <list>
          <data type="token"/>
        </list>
      </attribute>
    </element>
  </define>

Notes:

The 'unique' YANG statement, which is a substatement of 'list', has the cardinality of "0..n". Multiple sibling 'unique' statements cannot be mapped to a single @nma:unique attribute in the hybrid schema. Therefore, an XML element, <nma:unique>, has to be used for mapping the 'unique' statement instead of the attribute, much like the it is done for the 'must' statement.

This change to the mapping of the 'unique' statement is realized by changing the text of Section 10.55. Several other sections are also affected by this change.

RFC 6112, "Anonymity Support for Kerberos", April 2011

Note: This RFC has been obsoleted by RFC 8062

Source of RFC: krb-wg (sec)

Errata ID: 3743
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Love Hörnquist Åstrand
Date Reported: 2013-10-08
Verifier Name: Stephen Farrell
Date Verified: 2015-04-01

Section 7 says:

 "is ASCII string "KeyExchange"

It should say:

"is ASCII string "KEYEXCHANGE"

Notes:

MIT Kerberos is the only public implementation of this draft and when I created the second implementation I noticed that the MIT folks had used the wrong constant in their code.

After talking to them it makes more sense to change the specification then break backward compatibility with old clients since there no other implementations that we know about.

RFC 6122, "Extensible Messaging and Presence Protocol (XMPP): Address Format", March 2011

Note: This RFC has been obsoleted by RFC 7622

Source of RFC: xmpp (rai)

Errata ID: 2765
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nico Roeser
Date Reported: 2011-04-03
Verifier Name: Robert Sparks
Date Verified: 2011-05-12

Section 7.2 says:

   [XEP-0165]        Saint-Andre, P., "Best Practices to Discourage JID
                     Mimicking", XSF XEP 0045, December 2007.

It should say:

   [XEP-0165]        Saint-Andre, P., "Best Practices to Discourage JID
                     Mimicking", XSF XEP 0165, December 2007.

Notes:

Seems to be a problem caused by copy-and-paste: forgot to update the XEP number.

RFC 6126, "The Babel Routing Protocol", April 2011

Note: This RFC has been obsoleted by RFC 8966

Note: This RFC has been updated by RFC 7298, RFC 7557

Source of RFC: INDEPENDENT

Errata ID: 3505
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: pearl liang
Date Reported: 2013-03-01
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-01

Section 5 says:

5.  IANA Considerations

   IANA has registered the UDP port number 6697, called "babel", for use
   by the Babel protocol.

It should say:

5.  IANA Considerations

   IANA has registered the UDP port number 6696, called "babel", for use
   by the Babel protocol.

Notes:

Author Juliusz Chroboczek has agreed to use the port number 6696/udp for babel as per a discussion with Nevil Brownlee. The port number in the document therefore should be changed to 6696/udp.

RFC 6129, "The 'application/tei+xml' Media Type", February 2011

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 3374
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Laurent Romary
Date Reported: 2012-10-09
Verifier Name: Barry Leiba
Date Verified: 2012-10-09

Throughout the document, when it says:

"Text Encoding and Interchange"

It should say:

"Text Encoding Initiative"

Notes:

Typo introduced by mistake at some point in the submission process. "Text Encoding Initiative" is the official name of the TEI (see http://www.tei-c.org). This applies to the Abstract and Introduction sections.

RFC 6130, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", April 2011

Note: This RFC has been updated by RFC 7183, RFC 7188, RFC 7466

Source of RFC: manet (rtg)

Errata ID: 3677
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Christopher Dearlove
Date Reported: 2013-07-04
Verifier Name: Adrian Farrel
Date Verified: 2013-09-17

Section App. B p. 65 says:

   o  L_HEARD_time MUST NOT be greater than L_time.
 

It should say:

  o  L_HEARD_time MUST NOT be greater than L_time, 
     unless L_lost = true.

Notes:

The case currently indicated as a constraint failure,
but not by the relaxed constraint, can occur - and
correctly - in normal operation of the protocol.

Errata ID: 4276
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christopher Dearlove
Date Reported: 2015-02-23
Verifier Name: Adrian Farrel
Date Verified: 2015-02-24

Section Section 12.6 says:

               then create a 2-Hop Neighbor Tuple with:

It should say:

               then create a 2-Hop Tuple with:

Notes:

There is no such thing as a 2-Hop Neighbor Tuple. There is a 2-Hop Tuple (which is what is meant) but also a Neighbor Tuple (which is not meant).

RFC 6137, "The Network Trouble Ticket Data Model (NTTDM)", February 2011

Source of RFC: INDEPENDENT

Errata ID: 2729
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dimitris Zisiadis
Date Reported: 2011-02-23
Verifier Name: Nevil Brownlee
Date Verified: 2011-03-01

Section 6 says:

<xs:schema xmlns="urn:ietf:params:xml:ns:nttdm-0.1"

It should say:

<xs:schema xmlns="urn:ietf:params:xml:ns:nttdm-1.0"

Notes:

Please verify this errata so that IANA can then correct the XML schema in the IANA registry.
This reports a simple typo in section 6.

RFC 6140, "Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP)", March 2011

Source of RFC: martini (rai)

Errata ID: 3144
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: David Hancock
Date Reported: 2012-03-01
Verifier Name: Robert Sparks
Date Verified: 2012-06-07

Section 5.2 says:

<none -- new text being added>

It should say:

<Insert following new paragraph between existing 2nd and 3rd paragraph>

The registrar MUST populate the Contact header field of the 200 (OK) response
to REGISTER only with the explicitly registered Contact URIs identified in the
REGISTER request (i.e., for bulk number registration, the Contact URIs
containing the “bnc” parameter). The Contact header field of the 200 (OK)
response MUST NOT contain the multiple contact addresses that are implicitly
created by the bulk number registration procedure. 

Notes:

The proposed text clarifies how the MUST statement in RFC 3261 section 10.3 item-8 applies in the case of bulk number registration.

RFC 3261 section 10.3 item-8 says ...
8. The registrar returns a 200 (OK) response. The response MUST
contain Contact header field values enumerating all current
bindings. <... text deleted...>

For bulk number registration, this means that the Contact header field in the 200 (OK) response to REGISTER contains the Contact URI with the "bnc" parameter, and not the multiple derived contact URIs that are bound to the multiple E.164 numbers associated with the registering PBX.

RFC 6145, "IP/ICMP Translation Algorithm", April 2011

Note: This RFC has been obsoleted by RFC 7915

Note: This RFC has been updated by RFC 6791, RFC 7757

Source of RFC: behave (tsv)

Errata ID: 3059
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Gandhar Gokhale
Date Reported: 2011-12-23
Verifier Name: Wesley Eddy
Date Verified: 2012-06-01

Section 5.1 says:

<Removed from RFC 2765 where it had existed after Destination Address 
field description> 

It should say:

   If any of an IPv6 Hop-by-Hop Options header, Destination Options 
   header, or Routing header with the Segments Left field equal to zero 
   are present in the IPv6 packet, those IPv6 extension headers MUST be 
   ignored (i.e., there is no attempt to translate the extension headers) 
   and the packet translated normally.  However, the Total Length field 
   and the Protocol field are adjusted to "skip" these extension headers.

Notes:

Since the extension headers shall be removed from the packet while translating to IPv4 the translator should deduct from IPv4 Total Length the length of all the extension headers present in the original IPv6 packet except ESP header (in transport mode). AH is not supposed to be translated. RFC 2765 had explicitly stated this and RFC 6145 also should continue to have this stated. Copied the correction text from RFC 2765.


A BEHAVE WG chair said on 1/19/2012:
I believe the filer is correct. Although the intent might be clear from Section 4:
" As with [RFC2765], the translating function specified in this
document does not translate any IPv4 options, and it does not
translate IPv6 extension headers except the Fragment Header."

Although the Length portion of the omitted paragraph is actually covered by
errata ID 3060 above (and we don't need 2 technical errata for the same thing)
the omitted paragraph does contain a statement about how to fill in the
Protocol field when IPv6 extension headers were present, which is nowhere
else in the doc and might not be obvious to an implementer from the
section 4 text.

Errata ID: 3060
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Gandhar Gokhale
Date Reported: 2011-12-23
Verifier Name: Wesley Eddy
Date Verified: 2012-06-01

Section 5.1.1 says:

   Total Length:  Payload length value from IPv6 header, minus 8 for the
      Fragment Header, plus the size of the IPv4 header.

It should say:

   Total Length: If the Next Header field of the Fragment Header is not 
      an extension header (except ESP) then Total Length MUST be set to 
      Payload Length value from IPv6 header, minus length of extension 
      headers up to Fragmentation Header, minus 8 for the Fragment 
      Header, plus the size of the IPv4 header. If the Next Header 
      field of the Fragment Header is an extension header (except ESP) 
      then the packet SHOULD be dropped and logged.

Notes:

If the fragmentable part (as described in RFC 2460) of the original unfragmented IPv6 packet had extension headers then the translator can not calculate the total length of the IPv4 fragment for non-initial fragments. In case of initial fragment also, only if all the extension headers of the fragmentable part are contained within the initial fragment itself then translator can know of how much length to deduct from the total length.


A BEHAVE WG chair said on 1/19/2012:
I believe the filer is correct. The RFC does not contain the right statement with
respect to handling of IPv6 extension headers. It says they're skipped when
filling in the payload but it doesn't say they're skipped when filling in the
length field.

RFC 6150, "MD4 to Historic Status", March 2011

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rai

Errata ID: 2743
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Frank Ellermann
Date Reported: 2011-03-07
Verifier Name: Robert Sparks
Date Verified: 2011-08-05

Section 1 .. 9 says:

MD2 to Historic Status 

It should say:

MD4 to Historic Status 

Notes:

The abbreviated title on all pages should say "MD4"; RFC 6150 is about MD4 (RFC 1320). A very similar document (RFC-to-be 6149) simultaneously obsoleted MD2 (RFC 1319).

Errata ID: 2930
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sean Turner
Date Reported: 2011-08-10
Verifier Name: Robert Sparks
Date Verified: 2011-11-04

Section 3 says:

There are other RFCs that refer to MD2,

It should say:

There are other RFCs that refer to MD4,

Notes:

A really, really bad cut-n-paste error. This draft discusses MD4 not MD2.

RFC 6164, "Using 127-Bit IPv6 Prefixes on Inter-Router Links", April 2011

Note: This RFC has been updated by RFC 6547

Source of RFC: 6man (int)

Errata ID: 3422
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Benjamin Cama
Date Reported: 2012-11-29
Verifier Name: Brian Haberman
Date Verified: 2012-11-29

Section 6 says:

   (b)  Addresses in which the rightmost 64 bits are assigned the
        highest 128 values (i.e., ffff:ffff:ffff:ff7f to ffff:ffff:ffff:
        ffff) SHOULD NOT be used as unicast addresses, to avoid
        colliding with reserved subnet anycast addresses [RFC2526].

It should say:

   (b)  Addresses in which the rightmost 64 bits are assigned the
        highest 128 values (i.e., ffff:ffff:ffff:ff80 to ffff:ffff:ffff:
        ffff) SHOULD NOT be used as unicast addresses, to avoid
        colliding with reserved subnet anycast addresses [RFC2526].

Notes:

The highest 128 values start at ffff:ffff:ffff:ff80, not ffff:ffff:ffff:ff7f.

RFC 6176, "Prohibiting Secure Sockets Layer (SSL) Version 2.0", March 2011

Note: This RFC has been updated by RFC 8996

Source of RFC: tls (sec)

Errata ID: 5536
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Eugene Adell
Date Reported: 2018-10-19
Verifier Name: Paul Wouters
Date Verified: 2024-03-18

Section 1 says:

   RFC 4346 [TLS1.1], and later RFC 5246 [TLS1.2], explicitly warned
   implementers that the "ability to send version 2.0 CLIENT-HELLO
   messages will be phased out with all due haste".  This document
   accomplishes this by updating the backward compatibility sections
   found in TLS [TLS1.0][TLS1.1][TLS1.2].

It should say:

   RFC 2246 [TLS1.0], and later RFC 4346 [TLS1.1], then RFC 5246
   [TLS1.2] explicitly warned implementers that the "ability to send
   version 2.0 CLIENT-HELLO messages will be phased out with all due
   haste". This document accomplishes this by updating the backward
   compatibility sections found in TLS [TLS1.0][TLS1.1][TLS1.2].

Notes:

The warning on the version 2.0 Client Hello is as old as the first TLS version (RFC 2246 Appendix E). That's what the authors meant and wanted to highlight by listing two of the three RFCs containing this warning. This is confirmed by their last sentence. It looks like a small mistake without concrete effects, I push this errata considering "IESG Processing of RFC Errata for the IETF Stream rule 6"

RFC 6181, "Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses", March 2011

Source of RFC: mptcp (tsv)

Errata ID: 4857
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tobias Seel
Date Reported: 2016-11-09
Verifier Name: Mirja Kühlewind
Date Verified: 2020-03-04

Section 5 says:

The
   attacker can do that by pretending that the path between IPA and IPT
   is congested but that the path between IPS and IPT is not.

It should say:

The
   attacker can do that by pretending that the path between IPA and IPS
   is congested but that the path between IPS and IPT is not.

Notes:

The attacker wants to pretend that the path between IPA and the Source is congested. There is no relevant path between IPA and IPT which has to be congested.

RFC 6183, "IP Flow Information Export (IPFIX) Mediation: Framework", April 2011

Source of RFC: ipfix (ops)

Errata ID: 2905
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02

Section 7 says:

      If information about a set of Original Exporters needs to be
      reported, it can be useful to export it as Common Properties as
      specified in [RFC5473].  The commonPropertiesID may then serve as
      a scope for the set of Original Exporters.

It should say:

      If information about a set of Original Exporters needs to be
      reported, it can be useful to export it as Common Properties as
      specified in [RFC5473].  The commonPropertiesId may then serve as
      a scope for the set of Original Exporters.

Notes:

s/commonPropertiesID/commonPropertiesId/

Per RFC5102 and IANA's IPFIX registry, the correct name is "commonPropertiesId".

RFC 6184, "RTP Payload Format for H.264 Video", May 2011

Source of RFC: avt (rai)

Errata ID: 3318
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Xiaohui Wei (Joanne)
Date Reported: 2012-08-14
Verifier Name: Gonzalo Camarillo
Date Verified: 2013-05-22

Section 8.1 says:

On page 46 start from line 7: 
"When max-dpb is signaled, the receiver MUST be able to decode
NAL unit streams that conform to the signaled highest level,
with the exception that the MaxDpbMbs value in Table A-1 of [1]
for the signaled highest level is replaced with the value of
max-dpb * 3 / 8. Consequently, a receiver that signals max-dpb
          ^^^^^
MUST be capable of storing the following number of decoded
frames, complementary field pairs, and non-paired fields in its
decoded picture buffer:
Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs),
              ^^^^^
16)"

It should say:

When max-dpb is signaled, the receiver MUST be able to decode
NAL unit streams that conform to the signaled highest level,
with the exception that the MaxDpbMbs value in Table A-1 of [1]
for the signaled highest level is replaced with the value of
max-dpb * 8 / 3. Consequently, a receiver that signals max-dpb
          ^^^^^
MUST be capable of storing the following number of decoded
frames, complementary field pairs, and non-paired fields in its
decoded picture buffer:
Min(max-dpb * 8 / 3 / ( PicWidthInMbs * FrameHeightInMbs),
              ^^^^^
16)

RFC 6190, "RTP Payload Format for Scalable Video Coding", May 2011

Source of RFC: payload (rai)

Errata ID: 3711
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Xiaohui Wei (Joanne)
Date Reported: 2013-08-26
Verifier Name: Richard Barnes
Date Verified: 2013-10-28

Section 1.1.3 says:

   N:    1 bit
         no_inter_layer_pred_flag.  This flag specifies, when present in
         a coded slice NAL unit, whether inter-layer prediction may be
         used for decoding the coded slice (when equal to 1) or not
         (when equal to 0).

It should say:

   N:    1 bit
         no_inter_layer_pred_flag.  This flag specifies, when present in
         a coded slice NAL unit, whether inter-layer prediction may be
         used for decoding the coded slice (when equal to 0) or not
                                                          ^
         (when equal to 1).
                        ^

RFC 6192, "Protecting the Router Control Plane", March 2011

Source of RFC: opsec (ops)

Errata ID: 4705
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Trond Endrestøl
Date Reported: 2016-06-07
Verifier Name: Benoit Claise
Date Verified: 2016-12-19

Section A.1 says:

   ipv6 access-list EBGPv6
    permit tcp host 2001:DB8:100::25 eq bgp any
    permit tcp host 2001:DB8:100::25 any eq bgp
    permit tcp host 2001:DB8:100::27 eq bgp any
    permit tcp host 2001:DB8:100::27 any eq bgp
    permit tcp host 2001:DB8:100::29 eq bgp any
    permit tcp host 2001:DB8:100::29 any eq bgp
    permit tcp host 2001:DB8:100::31 eq bgp any
    permit tcp host 2001:DB8:100::31 any eq bgp
   ip access-list extended DNS
    permit udp 198.51.100.0 0.0.0.252 eq domain any
   ipv6 access-list DNSv6
    permit udp 2001:DB8:100:1::/64 eq domain any
    permit tcp 2001:DB8:100:1::/64 eq domain any
   ip access-list extended NTP

It should say:

   ipv6 access-list EBGPv6
    permit tcp host 2001:DB8:100::25 eq bgp any
    permit tcp host 2001:DB8:100::25 any eq bgp
    permit tcp host 2001:DB8:100::27 eq bgp any
    permit tcp host 2001:DB8:100::27 any eq bgp
    permit tcp host 2001:DB8:100::29 eq bgp any
    permit tcp host 2001:DB8:100::29 any eq bgp
    permit tcp host 2001:DB8:100::31 eq bgp any
    permit tcp host 2001:DB8:100::31 any eq bgp
   ip access-list extended DNS
    permit udp 198.51.100.0 0.0.0.252 eq domain any
    permit tcp 198.51.100.0 0.0.0.252 eq domain any
   ipv6 access-list DNSv6
    permit udp 2001:DB8:100:1::/64 eq domain any
    permit tcp 2001:DB8:100:1::/64 eq domain any
   ip access-list extended NTP

Notes:

DNS is transported sometimes over UDP and sometimes over TCP. The Cisco example fails to demonstrate this behaviour in the case of IPv4. The Cisco example clearly shows this behaviour in the case of IPv6.

The Juniper example in Section A.2 should be amended in the same fashion, however I'm unfamiliar with the proper JunOS syntax.

Errata ID: 4851
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Hugo Leonardo Canalli
Date Reported: 2016-11-01
Verifier Name: joel jaeggli
Date Verified: 2017-03-29

Section A.2 says:

   term ebgp-reply {
                   from {
                       source-prefix-list {
                           EBGP-NEIGHBORS;
                       }
                       protocol tcp;
                       port bgp;
                   }
                   then accept;
               }

It should say:

   term ebgp-reply {
                   from {
                       source-prefix-list {
                           EBGP-NEIGHBORS;
                       }
                       protocol tcp;
                       tcp-established;
                       source-port bgp;
                   }
                   then accept;
               }

Notes:

There is a security question in that firewall relating to bgp reply.
Any neighbor that fakes a tcp source port to 179 can access any router port, for example, ssh.
Need to add the line tcp-established. Would also be better to add source-port bgp since bgp protocol uses the 179 port to destination. Add the fix to all bgps, including ipv6.

Errata ID: 3906
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nick Hilliard
Date Reported: 2014-03-02
Verifier Name: Benoit Claise
Date Verified: 2014-04-15

Section A.1 says:

[...]
   ip access-list extended DNS
    permit udp 198.51.100.0 0.0.0.252 eq domain any
   ipv6 access-list DNSv6
    permit udp 2001:DB8:100:1::/64 eq domain any
    permit tcp 2001:DB8:100:1::/64 eq domain any
   ip access-list extended NTP
    permit udp 198.51.100.4 255.255.255.252 any eq ntp
   ipv6 access-list NTPv6
    permit udp 2001:DB8:100:2::/64 any eq ntp
   ip access-list extended SSH
    permit tcp 198.51.100.128 0.0.0.128 any eq 22
   ipv6 access-list SSHv6
    permit tcp 2001:DB8:100:3::/64 any eq 22
   ip access-list extended SNMP
    permit udp 198.51.100.128 0.0.0.128 any eq snmp
[...]

It should say:

[...]
   ip access-list extended DNS
    permit udp 198.51.100.0 0.0.0.3 eq domain any
   ipv6 access-list DNSv6
    permit udp 2001:DB8:100:1::/64 eq domain any
    permit tcp 2001:DB8:100:1::/64 eq domain any
   ip access-list extended NTP
    permit udp 198.51.100.4 0.0.0.3 any eq ntp
   ipv6 access-list NTPv6
    permit udp 2001:DB8:100:2::/64 any eq ntp
   ip access-list extended SSH
    permit tcp 198.51.100.128 0.0.0.127 any eq 22
   ipv6 access-list SSHv6
    permit tcp 2001:DB8:100:3::/64 any eq 22
   ip access-list extended SNMP
    permit udp 198.51.100.128 0.0.0.127 any eq snmp
[...]

Notes:

The bitfield masks in the Cisco Configuration example in section A.1 look incorrect. The authors may have intended the following meanings:

ip access-list extended DNS
all hosts between 198.51.100.0 and 198.51.100.3 instead of all addresses in the range 198.51.100.0/24 which are evenly divisible by 4

ip access-list extended NTP
all hosts between 198.51.100.4 and 198.51.100.7 instead of all addresses in the range 0.0.0.0/0 which are evenly divisible by 4

ip access-list extended SSH
all hosts between 198.51.100.128 and 198.51.100.255 instead of 198.51.100.128/32

ip access-list extended SNMP
all hosts between 198.51.100.128 and 198.51.100.255 instead of 198.51.100.128/32

RFC 6194, "Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms", March 2011

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 3683
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Quynh Hung Dang
Date Reported: 2013-07-15
Verifier Name: Stephen Farrell
Date Verified: 2014-01-14

Section 3.2 says:

When n = 160, as is the case for SHA-1, it will
   take 2^106 computations to find a second pre-image in a 60-byte
   message.

It should say:

When n = 160, as is the case for SHA-1, the estimated computational
 complexity of finding a second preimage of any given message of 
about 2^60 bytes in length is 2^106 (compression function 
executions) which is significantly less than 2^160. 

Notes:

Clarification.

spt: I replaced 2^55 blocks with 2^60 bytes after some consultation with Lily and Quynh.

RFC 6204, "Basic Requirements for IPv6 Customer Edge Routers", April 2011

Note: This RFC has been obsoleted by RFC 7084

Source of RFC: v6ops (ops)

Errata ID: 3054
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tore Anderson
Date Reported: 2011-12-16
Verifier Name: ron bonica
Date Verified: 2012-01-03

Section 4.3 says:

   L-13:  If the delegated prefix changes, i.e., the current prefix is
          replaced with a new prefix without any overlapping time
          period, then the IPv6 CE router MUST immediately advertise the
          old prefix with a Preferred Lifetime of zero and a Valid
          Lifetime of the lower of the current Valid Lifetime and 2
          hours (which must be decremented in real time) in a Router
          Advertisement message as described in Section 5.5.3, (e) of
          [RFC4862].

It should say:

   L-13:  If the delegated prefix changes, i.e., the current prefix is
          replaced with a new prefix without any overlapping time
          period, then the IPv6 CE router MUST immediately advertise the
          old prefix with a Preferred Lifetime of zero and a Valid
          Lifetime of either a) zero, or b) the lower of the current
          Valid Lifetime and 2 hours (which must be decremented in real
          time), in a Router Advertisement message as described in
          Section 5.5.3, (e) of [RFC4862].

Notes:

The original text in L-13 prohibits implementers from transmitting Valid Lifetime = 0 whenever a prefix needs to be invalidated. It should not, because transmitting VL=0 is easier to implement than sending "the lower of the current Valid Lifetime and 2 hours (which must be decremented in real time)".

Transmitting Valid Lifetime = 0 has the exact same effect on a host as the procedure described in the original text, i.e., it will the host to lower (but never raise) the remaining valid lifetime to 7200 seconds.

RFC 6210, "Experiment: Hash Functions with Parameters in the Cryptographic Message Syntax (CMS) and S/MIME", April 2011

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 3866
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2014-01-10
Verifier Name: Sean Turner
Date Verified: 2014-01-20

Section Appendix B. says:

  MD5-HASH-EXPERIMENT
    { iso(1) member-body(2) us(840) rsadsi(113549)
      pkcs(1) pkcs-9(9) smime(16) modules(0)
      id-mod-MD5-XOR-EXPERIMENT(999) }

It should say:

  MD5-HASH-EXPERIMENT
    { iso(1) member-body(2) us(840) rsadsi(113549)
      pkcs(1) pkcs-9(9) smime(16) modules(0)
      id-mod-MD5-XOR-EXPERIMENT(49) }

Notes:

The value assigned for id-mod-MD5-XOR-EXPERIMENT is 49, not 999. This error will not impact interoperability, but it could impact developers using some ASN.1 tools.

RFC 6214, "Adaptation of RFC 1149 for IPv6", April 2011

Source of RFC: INDEPENDENT

Errata ID: 4323
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Joe Klein
Date Reported: 2015-04-01
Verifier Name: Nevil Brownlee
Date Verified: 2015-06-30

Section 8. Security says:

Notes:

New Physical and Link layer problem have been discovered and should be addressed in this RFC, and they are:
1. Avian IP carriers are competing for air space with Unmanned Aerial Vehicle (UAV), and as such have a higher probability of packet collision at Layer 1 has increase in retransmissions.
2. On path Avian IP carrier dropouts, caused by draughts, may also lead to a connection loss, and increase in retransmission.

Errata ID: 3566
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dale Worley
Date Reported: 2013-03-26
Verifier Name: Nevil Brownlee
Date Verified: 2013-05-27

Section Metadata says:

RFC 6214 updates RFC 1149, in a similar way to RFC 2549 updating 
RFC 1149.  But there is no metadata in RFC 6214 stating that it 
updates RFC 1149.

It should say:

"Updates: 1149"

Notes:

I discovered this defect while trying to find what was described to me as "the IPv6 update to 'avian carriers'". So actual people are inconvenienced by this defect.

RFC 6215, "MPLS Transport Profile User-to-Network and Network-to-Network Interfaces", April 2011

Source of RFC: mpls (rtg)

Errata ID: 7521
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mohamed Boucadair
Date Reported: 2023-05-23
Verifier Name: RFC Editor
Date Verified: 2023-05-23

Section 1.1 says:

   The Transport Service Interfaces for MPLS-TP are defined in Section
   3.4.3 of [RFC5921].  These definitions are illustrated by showing
   MPLS-TP Provider Edges (PEs) containing a UNI and an NNI.  The
   figures illustrate the UNI and the NNI as a span.  However, it is
   convention to illustrate these interfaces as reference points.
   Furthermore, in the case of a UNI, it is useful to illustrate the
   distribution of UNI functions between the Customer Edge (CE) side and
   the PE side of the UNI, i.e., the UNI-C (User-to-User Interface,
   Client side) and UNI-N (User-to-Network Interface, Network side), in
   order to show their relationship to one another.

It should say:

   The Transport Service Interfaces for MPLS-TP are defined in Section
   3.4.3 of [RFC5921].  These definitions are illustrated by showing
   MPLS-TP Provider Edges (PEs) containing a UNI and an NNI.  The
   figures illustrate the UNI and the NNI as a span.  However, it is
   convention to illustrate these interfaces as reference points.
   Furthermore, in the case of a UNI, it is useful to illustrate the
   distribution of UNI functions between the Customer Edge (CE) side and
   the PE side of the UNI, i.e., the UNI-C (User-to-Network Interface,
   Client side) and UNI-N (User-to-Network Interface, Network side), in
   order to show their relationship to one another.

Notes:

This is a very minor nit.

As listed in Section 1.2., UNI stands for "User-to-Network Interface", not "User-to-User Interface".

RFC 6218, "Cisco Vendor-Specific RADIUS Attributes for the Delivery of Keying Material", April 2011

Source of RFC: INDEPENDENT

Errata ID: 5178
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yogesh Kumar Bansal
Date Reported: 2017-11-06
Verifier Name: Adrian Farrel
Date Verified: 2018-04-08

Section 3.3 says:

MAC = MAC-ALG(Key, Type + Identifier + Length + Attributes)
               where ’+’ represents concatenation

It should say:

MAC = HASH-ALG(Key, Type + Identifier + Length + Attributes)
               where ’+’ represents concatenation

Notes:

HASH-ALG is the name of a free variable for the hash algorithm.

RFC 6225, "Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information", July 2011

Source of RFC: geopriv (rai)

Errata ID: 3434
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nguyen Dai Son
Date Reported: 2012-12-23
Verifier Name: Gonzalo Camarillo
Date Verified: 2013-04-03

Throughout the document, when it says:

Section C.1.1. Encoding a Location into DHCP Geodetic Form,[Page 32]


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Code (144)  |  OptLen (16)  |  LatUnc   |     Latitude      .
     |0 1 1 1 1 0 1 1|0 0 0 1 0 0 0 0|0 1 0 0 1 0|1 1 1 0 1 1 1 1 0 0.
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                Latitude (cont'd)              |  LongUnc  |   .
     .0 1 0 0 1 0 0 1 0 0 1 1 0 1 1 0 0 0 0 0 1 1 0 1|0 1 0 0 1 0|0 1.
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                       Longitude (cont'd)                      |
     .0 0 1 0 1 1 1 0 0 1 1 0 1 1 1 0 0 0 1 0 1 1 1 0 1 1 0 0 0 0 1 1|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | AType |   AltUnc  |                Altitude                   .
     |0 0 0 1|0 0 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 1.
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .  Alt (cont'd) |Ver| Res |Datum|
     .1 0 1 1 0 0 1 1|0 1|0 0 0|0 0 1|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   In hexadecimal, this is 7B104BBC 49360D49 2E6E2EC3 13C00021 B341.
   The DHCPv6 form only differs in the code and option length portion.

It should say:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Code (144)  |  OptLen (16)  |  LatUnc   |     Latitude      .
     |1 0 0 1 0 0 0 0|0 0 0 1 0 0 0 0|0 1 0 0 1 0|1 1 1 0 1 1 1 1 0 0.
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                Latitude (cont'd)              |  LongUnc  |   .
     .0 1 0 0 1 0 0 1 0 0 1 1 0 1 1 0 0 0 0 0 1 1 0 1|0 1 0 0 1 0|0 1.
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                       Longitude (cont'd)                      |
     .0 0 1 0 1 1 1 0 0 1 1 0 1 1 1 0 0 0 1 0 1 1 1 0 1 1 0 0 0 0 1 1|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | AType |   AltUnc  |                Altitude                   .
     |0 0 0 1|0 0 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 1.
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .  Alt (cont'd) |Ver| Res |Datum|
     .1 0 1 1 0 0 1 1|0 1|0 0 0|0 0 1|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   In hexadecimal, this is 90104BBC 49360D49 2E6E2EC3 13C00021 B341.
   The DHCPv6 form only differs in the code and option length portion.

Notes:

The specified value for field "Code" is 144(d) (from bit0 to bit7), but the binary (from bit0 to bit7) is 01111011(b) or 123(d). It should correct to 1001 0000(b) or 144(d).

Summary:
|-correcting point 1: Bit0 to Bit7 (from 0 1 1 1 1 0 1 1 to 1 0 0 1 0 0 0 0)
|-correcting point 2: In hexadecimal (from 7B104BBC to 90104BBC )

RFC 6231, "An Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework", May 2011

Note: This RFC has been updated by RFC 6623

Source of RFC: mediactrl (rai)

Errata ID: 3151
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eric Burger
Date Reported: 2012-03-07
Verifier Name: Robert Sparks
Date Verified: 2012-03-07

Section 4.5 says:

   | 433  | Unsupported   | request contains      |                    |
   |      | collect and   | <collect> and         |                    |
   |      | record        | <record> elements and |                    |
   |      | capability    | the MS does support   |                    |
   |      |               | these operations      |                    |
   |      |               | simultaneously.       |                    |

It should say:

   | 433  | Unsupported   | request contains      |                    |
   |      | collect and   | <collect> and         |                    |
   |      | record        | <record> elements and |                    |
   |      | capability    | the MS does not       |                    |
   |      |               | support these         |                    |
   |      |               | operations            |                    |
   |      |               | simultaneously.       |                    |

Notes:

Typo discovered in 6231-iana draft. Need anti-sense of description.

RFC 6234, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", May 2011

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 5179
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2017-11-06
Verifier Name: Roman Danyliw
Date Verified: 2022-01-19

Section 8.5 says:

 *    This file will exercise the HKDF code performing
 *      the seven tests documented in RFC 4869.

It should say:

 *    This file will exercise the HKDF code performing
 *      the seven tests documented in RFC 5869.

Notes:

Typo. Provide the correct reference in the code comment.

RFC 6235, "IP Flow Anonymization Support", May 2011

Source of RFC: ipfix (ops)

Errata ID: 2883
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02

Section 7.2.4 says:

   The Exporting Process Reliability Statistics Options Template,
   recommended in [RFC5101], contains an Exporting Process ID field,
   which may be an exportingProcessIPv4Address Information Element or an
   exportingProcessIPv6Address Information Element.

...

   Similarly, the Export Session Details Options Template and Message
   Details Options Template specified for the IPFIX File Format
   [RFC5655] may contain the exportingProcessIPv4Address Information
   Element or the exportingProcessIPv6Address Information Element to
   identify an Exporting Process from which a flow record was received,
   and the collectingProcessIPv4Address Information Element or the
   collectingProcessIPv6Address Information Element to identify the
   Collecting Process which received it.

It should say:

   The Exporting Process Reliability Statistics Options Template,
   recommended in [RFC5101], contains an Exporting Process ID field,
   which may be an exporterIPv4Address Information Element or an
   exporterIPv6Address Information Element.

...

   Similarly, the Export Session Details Options Template and Message
   Details Options Template specified for the IPFIX File Format
   [RFC5655] may contain the exporterIPv4Address Information
   Element or the exporterIPv6Address Information Element to
   identify an Exporting Process from which a flow record was received,
   and the collectorIPv4Address Information Element or the
   collectorIPv6Address Information Element to identify the
   Collecting Process which received it.

Notes:

s/exportingProcessIPv4Address/exporterIPv4Address/ (twice)
s/exportingProcessIPv6Address/exporterIPv6Address/ (twice)
s/collectingProcessIPv4Address/collectorIPv4Address/ (once)
s/collectingProcessIPv6Address/collectorIPv6Address/ (once)

- per the names in IANA's IPFIX registry.

Errata ID: 2887
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02

Section 7.2.1 says:

   In this
   description, a timestamp is an Information Element with the data type
   dateTimeSeconds, dataTimeMilliseconds, dateTimeMicroseconds, or
   dateTimeNanoseconds;

It should say:

   In this
   description, a timestamp is an Information Element with the data type
   dateTimeSeconds, dateTimeMilliseconds, dateTimeMicroseconds, or
   dateTimeNanoseconds;

Notes:

s/dataTimeMilliseconds/dateTimeMilliseconds/

Per [RFC5102] section 3.1.16, the definition is "dateTimeMilliseconds"

Errata ID: 2907
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02

Section Figure 5 says:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Set ID = 3           |          Length =  26         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Template ID = 257        |        Field Count = 4        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Scope Field Count = 2      |0| templateID              145 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Field Length = 2        |0| informationElementId    303 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Field Length = 2        |0| anonymizationFlags      285 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Field Length = 2        |0| anonymizationTechnique  286 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Field Length = 2        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Set ID = 3           |          Length =  26         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Template ID = 257        |        Field Count = 4        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Scope Field Count = 2      |0| templateId              145 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Field Length = 2        |0| informationElementId    303 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Field Length = 2        |0| anonymizationFlags      285 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Field Length = 2        |0| anonymizationTechnique  286 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Field Length = 2        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

s/templateID/templateId/

Per RFC5102 and IANA's IPFIX registry, the correct name is "templateId".

RFC 6238, "TOTP: Time-Based One-Time Password Algorithm", May 2011

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 2866
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michal Altair Valasek
Date Reported: 2011-07-20
Verifier Name: Sean Turner
Date Verified: 2011-11-12

Appendix B says

The test token shared secret uses the ASCII string value
"12345678901234567890".

It should say:

The test token shared secrets use the following ASCII string values:
- HMAC-SHA1: "12345678901234567890" (20 bytes)
- HMAC-SHA256: "12345678901234567890123456789012" (32 bytes)
- HMAC-SHA512:
  "1234567890123456789012345678901234567890123456789012345678901234" (64 bytes)

Notes:

The secret values are different for different hash types. The example Java code respects this, but the test vector documentation does not.

Errata ID: 4678
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Osric Wilkinson
Date Reported: 2016-04-27
Verifier Name: Stephen Farrell
Date Verified: 2016-04-30

Section Appendix A says:

* @return: a numeric String in base 10 that includes
*              {@link truncationDigits} digits

It should say:

* @return: a numeric String in base 10 that includes
*              {@link DIGITS_POWER} digits

Notes:

The JavaDoc for the functions refers to truncationDigits, which doesn't exist in the example code. I think the authors mean the DIGITS_POWER array.

Note that this happens four times for the four different versions of the generateTOTP() method.

RFC 6241, "Network Configuration Protocol (NETCONF)", June 2011

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

Source of RFC: netconf (ops)

Errata ID: 5790
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mahesh Jethanandani
Date Reported: 2019-07-23
Verifier Name: Ignas Bagdonas
Date Verified: 2019-08-20

In Sections 7.8, 7.9, and 8.4.1

OLD:

7.8.  <close-session>

   Description:  Request graceful termination of a NETCONF session.

      When a NETCONF server receives a <close-session> request, it will
      gracefully close the session.  The server will release any locks
      and resources associated with the session and gracefully close
      any associated connections.  Any NETCONF requests received after
      a <close-session> request will be ignored.

   Positive Response:  If the device was able to satisfy the request, an
      <rpc-reply> is sent that includes an <ok> element.

   Negative Response:  An <rpc-error> element is included in the
      <rpc-reply> if the request cannot be completed for any reason.

   Example:

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <close-session/>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

NEW

7.8.  <close-session>

   Description:  Request graceful termination of a NETCONF session.

      When a NETCONF server receives a <close-session> request, it will
      gracefully close the session.  The server will release any locks
      and resources associated with the session and gracefully close any
      associated connections.  Any NETCONF requests received after a
      <close-session> request will be ignored.

      For details on what happens if a NETCONF server receives a 
      <close-session> request while processing a confirmed commit,
      please refer to Section 8.4.

   Positive Response:  If the device was able to satisfy the request, an
      <rpc-reply> is sent that includes an <ok> element.

   Negative Response:  An <rpc-error> element is included in the
      <rpc-reply> if the request cannot be completed for any reason.

   Example:

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <close-session/>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

OLD

7.9.  <kill-session>

   Description:  Force the termination of a NETCONF session.

      When a NETCONF entity receives a <kill-session> request for an
      open session, it will abort any operations currently in process,
      release any locks and resources associated with the session, and
      close any associated connections.

      If a NETCONF server receives a <kill-session> request while
      processing a confirmed commit (Section 8.4), it MUST restore the
      configuration to its state before the confirmed commit was issued.

      Otherwise, the <kill-session> operation does not roll back
      configuration or other device state modifications made by the
      entity holding the lock.

   Parameters:

      session-id:  Session identifier of the NETCONF session to be
         terminated.  If this value is equal to the current session ID,
         an "invalid-value" error is returned.

   Positive Response:  If the device was able to satisfy the request, an
      <rpc-reply> is sent that includes an <ok> element.

   Negative Response:  An <rpc-error> element is included in the
      <rpc-reply> if the request cannot be completed for any reason.


   Example:

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <kill-session>
         <session-id>4</session-id>
       </kill-session>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

NEW

7.9.  <kill-session>

   Description:  Force the termination of a NETCONF session.

      When a NETCONF entity receives a <kill-session> request for an
      open session, it will abort any operations currently in process,
      release any locks and resources associated with the session, and
      close any associated connections.

      For details on what happens if a NETCONF server receives a 
      <kill-session> request while processing a confirmed commit,
      please refer to Section 8.4.

      Otherwise, the <kill-session> operation does not roll back
      configuration or other device state modifications made by the
      entity holding the lock.

   Parameters:

      session-id:  Session identifier of the NETCONF session to be
         terminated.  If this value is equal to the current session ID,
         an "invalid-value" error is returned.

   Positive Response:  If the device was able to satisfy the request, an
      <rpc-reply> is sent that includes an <ok> element.

   Negative Response:  An <rpc-error> element is included in the
      <rpc-reply> if the request cannot be completed for any reason.


   Example:

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <kill-session>
         <session-id>4</session-id>
       </kill-session>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>


Section 8.4.1

OLD:

   If the device reboots for any reason before the confirm timeout
   expires, the server MUST restore the configuration to its state
   before the confirmed commit was issued.

NEW:

   If the device reboots for any reason before the confirm timeout
   expires, the server MUST restore the configuration to its state
   before the confirmed commit was issued, unless the confirmed commit 
   also included a <persist> element, in which case the server MAY
   continue the confirmed commit procedure.

Notes:

This Errata modifies three different sections, Sections 7.8, 7.9 and 8.4.1. The changes in Section 7.8 and 7.9 defer the description of the behavior of confirmed commit to Section 8.4.1.

Errata ID: 3980
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Klement Sekera
Date Reported: 2014-05-05
Verifier Name: Benoit Claise
Date Verified: 2015-01-23

Sections 6.2.5 and 6.3

In section 6.3:

OLD:
   The
   algorithm continues until all sibling sets in all subtrees specified
   in the filter have been processed.

In section 6.2.5

OLD:
  o  If any sibling nodes of the selection node are instance identifier
      components for a conceptual data structure (e.g., list key leaf),
      then they MAY also be included in the filter output.

It should say:

In section 6.3:

NEW:

   The 
   algorithm continues until all sibling sets in all subtrees specified
   in the filter have been processed. If any sibling nodes of a node
   are instance identifier components for a conceptual data structure
   (e.g., list key leaf), then they MAY also be included in the filter 
   output.

In section 6.2.5

NEW:

Notes:

The intent is to allow the server to always include the key node values and the wording accidentally does not cover this case.

Here is the OLD/NEW in a more intuitive way:
In section 6.3:

OLD:

The algorithm continues until all sibling sets in all subtrees specified
in the filter have been processed.
NEW:

The algorithm continues until all sibling sets in all subtrees specified
in the filter have been processed. If any sibling nodes of a node
are instance identifier components for a conceptual data structure
(e.g., list key leaf), then they MAY also be included in the filter output.

Implicitly in section 6.2.5 to delete the moved text:

OLD:

If any sibling nodes of the selection node are instance identifier
components for a conceptual data structure (e.g., list key leaf),
then they MAY also be included in the filter output.

NEW:
<void>

Errata ID: 4066
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Andy Bierman
Date Reported: 2014-07-30
Verifier Name: Benoit Claise
Date Verified: 2014-09-22

Section 7.2 says:

If the "operation" attribute is not specified, the
configuration is merged into the configuration datastore.

It should say:

If the "operation" attribute is not specified, then the 
operation applied to the parent data node of the configuration
is used. If no parent data node is available, then the value of 
the <default-operation> parameter is used.  If the 
<default-operation> parameter is not given, the configuration 
is merged into the configuration datastore.

Notes:

sentence in para 6 is not correct.
The default-operation value is used, not the value "merge".

Discussion on the NETCONF mailing list. See http://www.ietf.org/mail-archive/web/netconf/current/msg09169.html

Errata ID: 5388
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jonathan Hansford
Date Reported: 2018-06-11
Verifier Name: Ignas Bagdonas
Date Verified: 2019-10-18

Section 8.3.4.2 says:

8.3.4.2.  <discard-changes>

   If the client decides that the candidate configuration is not to be
   committed, the <discard-changes> operation can be used to revert the
   candidate configuration to the current running configuration.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <discard-changes/>
     </rpc>

   This operation discards any uncommitted changes by resetting the
   candidate configuration with the content of the running
   configuration.

It should say:

8.3.4.2.  <discard-changes>

   Description:

         If the client decides that the candidate configuration is not
         to be committed, the <discard-changes> operation can be used to
         revert the candidate configuration to the current running
         configuration.

         This operation discards any uncommitted changes by resetting
         the candidate configuration with the content of the running
         configuration.

   Positive Response:

         If the device was able to satisfy the request, an <rpc-reply>
         is sent that contains an <ok> element.

   Negative Response:

         An <rpc-error> element is included in the <rpc-reply> if the
         request cannot be completed for any reason.

   Example:

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <discard-changes/>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

Notes:

RFC 6241 section 1.1 includes the following two definitions:

o protocol operation: A specific remote procedure call, as used
within the NETCONF protocol.

o remote procedure call (RPC): Realized by exchanging <rpc> and
<rpc-reply> messages.

Positive and negative responses are detailed for all instances of an operation within the RFC with the exception of <discard-changes>.

Section 8.3.4.2 identifies <discard-changes> as an operation, and appendices A and C identify "rollback-failed" as an error-tag to be used when the "Request to roll back some configuration change (via rollback-on-error or <discard-changes> operations) was not completed for some reason."

This change clarifies that <discard-changes> requires an <rpc-reply>.

RFC 6243, "With-defaults Capability for NETCONF", June 2011

Source of RFC: netconf (ops)

Errata ID: 4688
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Muly Ilan
Date Reported: 2016-05-08
Verifier Name: Benoit Claise
Date Verified: 2016-05-16

Section 4.5.2 says:

   If the operation attribute contains the value 'create', and the data
   node already exists in the target configuration datastore, then the
   server MUST return an <rpc-error> response with an 'invalid-value'
   error-tag.

It should say:

   If the operation attribute contains the value 'create', and the data
   node already exists in the target configuration datastore, then the
   server MUST return an <rpc-error> response with an 'data-exists'
   error-tag.

Notes:

According to RFC6241 section 7.2 the behavior for the 'create' operation is: " If the configuration data exists, an <rpc-error> element is returned with an <error-tag> value of "data-exists". "

Errata ID: 5289
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ganesh Sivasankaran
Date Reported: 2018-03-20
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2018-04-17

Section 4.5.1 says:

taken from the ’with-defaults-type’ typedef in Section 5.

It should say:

taken from the ’with-defaults-mode’ typedef in Section 5.

Notes:

Text reference typedef "with-defaults-type" does not exist in Section 5 and even in ietf-netconf-with-defaults.yang
Rather it is named typedef “with-defaults-mode”

[ WK: Verified, with agreement of authors. ]

Errata ID: 7426
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Dylan Sadoun
Date Reported: 2023-04-18
Verifier Name: Rob Wilton
Date Verified: 2023-10-02

Section 2.3.1 says:

   When data is retrieved from a server using the 'explicit' basic mode,
   and the <with-defaults> parameter is not present, data nodes MUST be
   reported if explicitly set by the client, even if they contain the
   schema default value.  Non-configuration data nodes containing the
   schema default value MUST be reported.

It should say:

   When data is retrieved from a server using the 'explicit' basic mode,
   and the <with-defaults> parameter is not present, data nodes MUST be
   reported if explicitly set by the client, even if they contain the
   schema default value.  A conceptual data node that would be set by
   the server to the schema default value MUST NOT be reported.
   Non-configuration data nodes containing the schema default value MUST
   be reported.

Notes:

This change brings the text and behavior more in alignment between ‘explicit’ Basic Mode (2.3.1) and ‘explicit’ Retrieval Mode (3.3).

The original errata also proposed that the text be clarified to define the behaviour for configuration explicitly set by a server, but after discussion with members of the WG, the general consensus is that this behaviour is outside the scope of the YANG and related management protocol RFCs that generally define changes to the server datastore contents in terms of explicit client requests to changes to the server’s configuration data. The terminology definition of “Explicitly set data” in the RFC does give some guidance of the expectations of how server set data should be treated.

Further clarification on server behavior absent of explicit client operations should be specified in new RFCs.

Errata ID: 4687
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Muly Ilan
Date Reported: 2016-05-08
Verifier Name: Benoit Claise
Date Verified: 2016-05-17

Section A.1 says:

     typedef status-type {
        description "Interface status";
        type enumeration {
          enum ok;
          enum 'waking up';
          enum 'not feeling so good';
          enum 'better check it out';
          enum 'better call for help';
        }
        default ok;
     }

It should say:

     typedef status-type {
        description "Interface status";
        type enumeration {
          enum up;
          enum 'waking up';
          enum 'not feeling so good';
          enum 'better check it out';
          enum 'better call for help';
        }
        default up;
     }

Notes:

The examples in appendix A use the value 'up' and not the value 'ok'.

RFC 6244, "An Architecture for Network Management Using NETCONF and YANG", June 2011

Source of RFC: netmod (ops)

Errata ID: 3012
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin Bjorklund
Date Reported: 2011-11-04
Verifier Name: Dan Romascanu
Date Verified: 2011-11-07

Section 2.2.1 says:

   | reference    | Value must appear elsewhere in the data            |

It should say:

   | type leafref | Value must appear elsewhere in the data            |

Notes:

The "reference" statement is used as a reference to some other specification.

The column heading is "Statement". It is not obvious that "type leafref" is a Statement, so I am not sure if the proposed corrected text is enough.

Errata ID: 5760
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ram Polisetty
Date Reported: 2019-06-22
Verifier Name: Ignas Bagdonas
Date Verified: 2019-07-09

Section 2.1 says:

configuration datastore where configuration changes can be made that
will not affect the device until a "commit-configuration" operation
is invoked.

It should say:

configuration datastore where configuration changes can be made that
will not affect the device until a "<commit/>" operation
is invoked.

Notes:

Netconf RPC for commit-configuration is <commit/>

RFC 6249, "Metalink/HTTP: Mirrors and Hashes", June 2011

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 3244
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tatsuhiro Tsujikawa
Date Reported: 2012-06-04
Verifier Name: Barry Leiba
Date Verified: 2012-06-15

Section 1.1 says:

Digest: SHA-256=MWVkMWQxYTRiMzk5MDQ0MzI3NGU5NDEyZTk5OWY1ZGFmNzgyZTJlO
DYzYjRjYzFhOTlmNTQwYzI2M2QwM2U2MQ==

It should say:

Digest: SHA-256=9HVXcpSXzGTuTNHu/JcJIggAJSzgRWF8GzWGCMe8hgo=

Notes:

This error appears in the following sections:
1.1. Example Metalink Server Response
6. Cryptographic Hashes of Whole Documents
7. Client / Server Multi-Source Download Interaction (2 occurrences in this section)

Originally noted in the aria2 forums:
http://sourceforge.net/apps/phpbb/aria2/viewtopic.php?f=1&t=133#p649

RFC 6265, "HTTP State Management Mechanism", April 2011

Source of RFC: httpstate (app)

Errata ID: 3444
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Eran Hammer
Date Reported: 2013-01-06
Verifier Name: Pete Resnick
Date Verified: 2013-02-18

Section 4.1.1 says:

path-value        = <any CHAR except CTLs or ";">
extension-av      = <any CHAR except CTLs or ";">

It should say:

path-value        = * <any CHAR except CTLs or ";">
extension-av      = * <any CHAR except CTLs or ";">

Notes:

A better correction could also be:

path-value = *av-octet
extension-av = *av-octet
av-octet = %x20-3A / %x3C-7E
; any CHAR except CTLs or ";"

Errata ID: 4148
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Zhong Yu
Date Reported: 2014-10-28
Verifier Name: Barry Leiba
Date Verified: 2014-10-30

Section 5.1.1 says:

   day-of-month    = 1*2DIGIT ( non-digit *OCTET )
...
   year            = 2*4DIGIT ( non-digit *OCTET )
   time            = hms-time ( non-digit *OCTET )

It should say:

   day-of-month    = 1*2DIGIT [ non-digit *OCTET ]
...
   year            = 2*4DIGIT [ non-digit *OCTET ]
   time            = hms-time [ non-digit *OCTET ]

Notes:

The trailing extra chars for these fields should be *optional*, not *required*.

RFC 6266, "Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)", June 2011

Source of RFC: httpbis (wit)

Errata ID: 3475
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Saašha Metsärantala
Date Reported: 2013-02-02
Verifier Name: Barry Leiba
Date Verified: 2013-02-03

In Appendix B:

Section 2 of [RFC2183] defines several additional disposition 
parameters: "creation-date", "modification-date", "quoted-date-time",
and "size".

It should say:

Section 2 of [RFC2183] defines several additional disposition
parameters: "creation-date", "modification-date", "read-date", and 
"size".

Notes:

Section 2 of RFC 2183 defines "quoted-date-time", but it is not a disposition parameter.

RFC 6274, "Security Assessment of the Internet Protocol Version 4", July 2011

Source of RFC: opsec (ops)

Errata ID: 4494
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alexander Okonnikov
Date Reported: 2015-10-06
Verifier Name: Joel Jaeggli
Date Verified: 2015-11-01

Section 3.6 says:

In Figure 3, an attacker sends ...

It should say:

In Figure 5, an attacker sends ...

Notes:

Text immediately below Figure 5 incorrectly references to incorrect figure number 3.

Errata ID: 7887
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Niklas Baerveldt
Date Reported: 2024-04-08
Verifier Name: RFC Editor
Date Verified: 2024-04-09

Section .8.4 says:

   The attacker is:

   o  Four hops away from A.

   o  Four hops away from B.

   o  Four hops away from C.

   o  Four hops away from D.

   In the network setup of Figure 3, the only system that satisfies all
   these conditions is the one marked as the "F".

It should say:

   The attacker is:

   o  Four hops away from A.

   o  Four hops away from B.

   o  Four hops away from C.

   o  Three hops away from D.

   In the network setup of Figure 6, the only system that satisfies all
   these conditions is the one marked as the "F".

Notes:

Since the packets that D gets has a TTL of 62 while A,B and C gets packets with TTL of 61, it should be that D is one less hop away than the others. This also seems to be illustrated in Figure 6.

Text that seems to refer to the network setup of Figure 6 references to incorrect figure number 3.

RFC 6275, "Mobility Support in IPv6", July 2011

Source of RFC: mext (int)

Errata ID: 3235
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alastair Galloway
Date Reported: 2012-05-30
Verifier Name: Brian Haberman
Date Verified: 2012-05-30

Section 4.1 says:

The mobile node may also accept packets from several care-of
addresses, such as when it is moving but still reachable at the
previous link.

It should say:

The mobile node may also accept packets for several care-of
addresses, such as when it is moving but still reachable at the
previous link.

Notes:

Looks like a typo ("from" typed, instead of "for"), but affects the technical meaning. I am happy for this erratum to be changed to Type: Editorial.

Errata ID: 5083
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mikael Abrahamsson
Date Reported: 2017-08-10
Verifier Name: Erik Kline
Date Verified: 2023-02-08

Throughout the document, when it says:

Notes:

Section 7.2 of RFC6275 introduces a new flag, called the R bit. This seems to update RFC 4861 section 4.6.2. However, there is no mention in RFC6275 or in RFC4861 that this happened.

--- Notes ---

Thanks for (ahem) flagging this.

RFC 8425 was produced to create an IANA registry of PIO flags and formally update RFC 4861.

Errata ID: 5695
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Brian Carpenter
Date Reported: 2019-04-16
Verifier Name: Eric Vyncke
Date Verified: 2024-01-12

Throughout the document, when it says:

[none]

It should say:

Updates: 4302 [in RFC header]

Notes:

Section 11.3.2 says:
The treatment of destination options described in RFC 4302 is
extended as follows. The AH authentication data MUST be
calculated... [etc.]
This is a change to the AH algorithm and should be flagged as a formal update to RFC 4302.

-- Verifier note (EV) ----

Indeed, RFC 6275 should formally update RFC 4302. This erratum sits somewhere between editorial and technical, and as it does not change the technical content itself, I edited the type to 'editorial'.

RFC 6277, "Online Certificate Status Protocol Algorithm Agility", June 2011

Note: This RFC has been obsoleted by RFC 6960

Source of RFC: pkix (sec)

Errata ID: 5892
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2019-11-02
Verifier Name: Benjamin Kaduk
Date Verified: 2019-11-09

Section Appendix A.1 says:

   PreferredSignatureAlgorithm ::= SEQUENCE {
    sigIdentifier       AlgorithmIdentifier{SIGNATURE-ALGORITHM, {...}},
    pubKeyAlgIdentifier SMIMECapability{PUBLIC-KEY, {...}} OPTIONAL  }

It should say:

   PreferredSignatureAlgorithm ::= SEQUENCE {
    sigIdentifier       AlgorithmIdentifier{SIGNATURE-ALGORITHM, {...}},
    pubKeyAlgIdentifier AlgorithmIdentifier{PUBLIC-KEY, {...}} OPTIONAL}

Notes:

The original ASN.1 definition does not compile. The correction uses a syntax that is aligned with RFC 6960, which obsoletes RFC 6277.

RFC 6281, "Understanding Apple's Back to My Mac (BTMM) Service", June 2011

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: tsv

Errata ID: 5676
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Stuart Cheshire
Date Reported: 2019-03-27
Verifier Name: Mirja Kühlewind
Date Verified: 2020-03-04

Section 5 says:

Following our example for alice, it queries the SRV RR for _dns-
update-tls._udp.alice.members.me.com.  Then, the updates are sent to
the dynamic DNS server returned in the Target field of query response.

...

So alice's host issues a query for
_dns-llq-tls._udp.alice.members.me.com
and obtains the server that provides LLQ service.

It should say:

Following our example for alice, it queries the SRV RR for _dns-
update-tls._tcp.alice.members.me.com.  Then, the updates are sent to
the dynamic DNS server returned in the Target field of query response.

...

So alice's host issues a query for
_dns-llq-tls._tcp.alice.members.me.com
and obtains the server that provides LLQ service.

Notes:

In both cases “_udp” should be replaced by “_tcp”.

The IANA service type “_dns-update-tls._tcp” is DNS Update (RFC 2136) over TLS over TCP.

The IANA service type “_dns-llq-tls._tcp” is DNS Long-Lived Queries (draft-sekar-dns-llq-03) over TLS over TCP.

In both cases RFC 6281 inadvertently used the label “_udp” instead of “_tcp”. Of course, TLS runs over TCP, not UDP. (I do know that DTLS can be used over UDP, but that is not what is being used here.)

RFC 6287, "OCRA: OATH Challenge-Response Algorithm", June 2011

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 3729
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Simon Josefsson
Date Reported: 2013-09-17
Verifier Name: Sean Turner
Date Verified: 2014-01-12

Section 6.3 says:

   The input for timestamps is further qualified by G, size of the time-
   step.  G can be specified in number of seconds, minutes, or hours:

           +--------------------+------------------------------+
           | Time-Step Size (G) |           Examples           |
           +--------------------+------------------------------+
           |       [1-59]S      | number of seconds, e.g., 20S |
           |       [1-59]M      |  number of minutes, e.g., 5M |
           |       [0-48]H      |  number of hours, e.g., 24H  |
           +--------------------+------------------------------+

                       Table 3: Time-step Size Table

   Default value for G is 1M, i.e., time-step size is one minute and the
   T represents the number of minutes since epoch time [UT].

It should say:

   The input for timestamps is further qualified by G, size of the time-
   step.  G can be specified in number of seconds, minutes, or hours:

           +--------------------+------------------------------+
           | Time-Step Size (G) |           Examples           |
           +--------------------+------------------------------+
           |       [1-59]S      | number of seconds, e.g., 20S |
           |       [1-59]M      |  number of minutes, e.g., 5M |
           |       [1-48]H      |  number of hours, e.g., 24H  |
           +--------------------+------------------------------+

                       Table 3: Time-step Size Table

   Default value for G is 1M, i.e., time-step size is one minute and the
   T represents the number of minutes since epoch time [UT].

Notes:

I have changed "[0-48]H" to "[1-48]H".

According to section 5.1, T is "representing the number of time-steps (seconds, minutes, hours, or days depending on the specified granularity) since midnight UTC of January 1, 1970 [UT]."

Having a granualarity of 0 is non-sense, and likely an editorial error.

RFC 6290, "A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE)", June 2011

Source of RFC: ipsecme (sec)

Errata ID: 3448
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Valery Smyslov
Date Reported: 2013-01-09
Verifier Name: Sean Turner
Date Verified: 2013-03-16

Section 4.3 says:

   For session resumption, as specified in [RFC5723], the situation is
   similar.  The responder, which is necessarily the peer that has
   crashed, SHOULD send a new ticket within the protected payload of the
   IKE_SESSION_RESUME exchange.  If the Initiator is also a token maker,
   it needs to send a QCD_TOKEN in a separate INFORMATIONAL exchange.

It should say:

   For session resumption, as specified in [RFC5723], the situation is
   similar.  The responder, which is necessarily the peer that has
   crashed, SHOULD send a new QCD_TOKEN in the IKE_AUTH exchange
   that immediately followes the IKE_SESSION_RESUME exchange.
   If the Initiator is also a token maker, it needs to send a QCD_TOKEN in
   the same IKE_AUTH exchange.

Notes:

Original text mixes up terms "ticket" (as Session Resumption ticket from RFC5723) and "token" (as QCD token from this RFC). As QCD token must never be sent in an unprotected message (see section 9.2 from this RFC) it cannot be sent in the IKE_SESSION_RESUME exchange because this exchange is done in clear. So, QCD token must be sent in the IKE_AUTH exchange that immediately followes the IKE_SESSION_RESUME exchange. In this case there is no need for the separate INFORMATIONAL exchange the Initiator's QCD token (if any) to be sent in, because it could be sent in the same IKE_AUTH exchange.

Errata ID: 3449
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Valery Smyslov
Date Reported: 2013-01-09
Verifier Name: Sean Turner
Date Verified: 2013-03-16

Section 4.1 says:

   o  Protocol ID (1 octet) MUST be 1, as this message is related to an
      IKE SA.

It should say:

   o  Protocol ID (1 octet) MUST be 0.

Notes:

RFC5996 (IKEv2) in section 3.10 while describing Protocol ID field in Notify Payload specifies that "If the SPI field is empty, this field MUST be sent as zero and MUST be ignored on receipt". As this RFC requires SPI field to be empty (later in section 4.1), Protocol ID should be zero to be consistent with RFC5996.

RFC 6296, "IPv6-to-IPv6 Network Prefix Translation", June 2011

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: ops

Errata ID: 3033
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Marek Kopecký
Date Reported: 2011-11-21
Verifier Name: ron bonica
Date Verified: 2011-12-06

Section 3.6 says:

So, the value 0xD550 is written in the 16-bit subnet area,
resulting in a mapped external address of 2001:0DB8:0001:D550::1234.

When a response datagram is received, it will contain the destination
address 2001:0DB8:0001:D550::0001, which will be mapped back to
FD01:0203:0405:0001::1234 using the inverse mapping algorithm.

It should say:

So, the value 0xD550 is written in the 16-bit subnet area,
resulting in a mapped external address of 2001:0DB8:0001:D550::1234.

When a response datagram is received, it will contain the destination
address 2001:0DB8:0001:D550::1234, which will be mapped back to
FD01:0203:0405:0001::1234 using the inverse mapping algorithm.

Notes:

PC sends the packet with Ipv6 source address 2001:0DB8:0001:D550::1234. When a response datagram is received, it must contain the destination address 2001:0DB8:0001:D550::1234.

RFC 6311, "Protocol Support for High Availability of IKEv2/IPsec", July 2011

Source of RFC: ipsecme (sec)

Errata ID: 3615
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yoav Nir
Date Reported: 2013-05-08
Verifier Name: Sean Turner
Date Verified: 2013-05-09

Section 6.4 says:

                        Note that this solution requires that either all Child SAs
   use Extended Sequence Numbers (ESNs) or else that no Child SA uses
   ESNs.

It should say:

                        Note that this solution requires that either all Child SAs
   use Extended Sequence Numbers (ESN) or else that no Child SA uses
   ESN.

Notes:

"ESN" is used here as a name of a feature. There is no need to pluralize it. This is different from "SAs" or "SPIs", where there are many of each.

RFC 6313, "Export of Structured Data in IP Flow Information Export (IPFIX)", July 2011

Source of RFC: ipfix (ops)

Errata ID: 3232
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2012-05-25
Verifier Name: Benoit Claise
Date Verified: 2012-06-04

Section 4.5.3 says:

   In the exceptional case of zero instances in the
   subTemplateMultiList, no data is encoded, only the Semantic field and
   Template ID field(s), and the Data Record Length field is set to
   zero.

It should say:

   In the exceptional case of zero instances in the
   subTemplateMultiList, no data is encoded, only the Semantic field and
   Template ID field(s), and the Data Records Length field is set to
   four.

Notes:

s/zero/four/ && s/Record/Records/

- because the Data Record Length field includes two bytes for the Template ID and two bytes for the Data Records Length field itself, as specified on page 23:

Data Records Length

This is the total length of the Data Records encoding for the
Template ID previously specified, including the two bytes for the
Template ID and the two bytes for the Data Records Length field
itself.

Therefore, a Data Records Length < 4 bytes is invalid. This should be noted in the "Data Records Length" definition.

Also note the pluralisation of "Records" in the definition.

Kudos to Manish Patil, manish.patil@guavus.com

Errata ID: 2909
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-02
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02

Section Figure 15 says:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Set ID = 2             |      Length = 16 octets       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Template ID = 257       |       Field Count = 2         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0| observationTimeMicroSec=324 |       Field Length = 8        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   digestHashValue = 326     |       Field Length = 4        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Set ID = 2             |      Length = 16 octets       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Template ID = 257       |       Field Count = 2         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0| observationTimeMicrosec=324 |       Field Length = 8        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   digestHashValue = 326     |       Field Length = 4        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

s/observationTimeMicroSec/observationTimeMicrosec/

Per RFC5477 and IANA's IPFIX registry, the correct name is "observationTimeMicroseconds".

Errata ID: 2873
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-07-28
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02

Section 11 says:

Two new IPFIX registries have been created, and the existing IPFIX
Information Element registry has been updated as detailed below.

It should say:

A new IPFIX registry has been created, and the existing IPFIX
Information Element registry has been updated as detailed below.

Notes:

Only one new registry has been created - for the "structured data types semantics", per section 11.4 of the document.

Errata ID: 2874
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-07-28
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02

Section 11 says:

   This document specifies several new IPFIX abstract data types, a new
   IPFIX Data Type Semantic, and several new Information Elements.

It should say:

This document specifies several new IPFIX abstract data types, a
new IPFIX Data Type Semantic, and several new Information
Elements. Furthermore, this document updates the schema at
http://www.iana.org/assignments/xml-registry/schema/ipfix.xsd with
the changes specified in Appendix A.

Notes:

Agreed addition of "Furthermore ,,. Appendix A." was overlooked during AUTH48.

Errata ID: 2884
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02

Section 10.1 says:

   "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet
   Sampling (PSAMP) Reports" [RFC5473] describes a bandwidth saving
   method for exporting Flow or packet information using the IP Flow
   Information Export (IPFIX) protocol.

   It defines the commonPropertiesID Information Element for exporting
   Common Properties.

It should say:

   "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet
   Sampling (PSAMP) Reports" [RFC5473] describes a bandwidth saving
   method for exporting Flow or packet information using the IP Flow
   Information Export (IPFIX) protocol.

   It discusses the commonPropertiesID Information Element for exporting
   Common Properties.

Notes:

s/defines/discusses/

- commonPropertiesId is not defined in [RFC5473], but in [RFC5101].
[RFC5473] doesn't have any IANA actions.

Errata ID: 2904
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02

Section 9.4 says:

        5-tuple (Flow Keys), octetCount, packetCount

...

   ------------------------------------------------------------------
   srcIP      | dstIP     | src  | dst  | proto | octetCount | packet
              |           | Port | Port |       |            | Count
   ------------------------------------------------------------------
   2001:DB8::1 2001:DB8::2  1025    80      6       108000      120
   ------------------------------------------------------------------

It should say:

        5-tuple (Flow Keys), octetTotalCount, packetTotalCount

...

   -----------------------------------------------------------------------
   srcIP      | dstIP     | src  | dst  | proto | octetTotal | packetTotal
              |           | Port | Port |       |   Count    |    Count
   -----------------------------------------------------------------------
   2001:DB8::1 2001:DB8::2  1025    80      6       108000         120
   -----------------------------------------------------------------------

Notes:

s/octetCount/octetTotalCount/ (twice)
s/packetCount/packetTotalCount/ (twice)

"octetCount" and "packetCount" don't exist. Per RFC5102 and IANA's IPFIX registry, the correct names are octetTotalCount and packetTotalCount.

NB correct usage in the figure on page 43 and in Figure 20 indicates that these are not the DeltaCount form.

RFC 6321, "xCal: The XML Format for iCalendar", August 2011

Note: This RFC has been updated by RFC 6868, RFC 7529

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 3042
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Christian Mollekopf
Date Reported: 2011-12-07
Verifier Name: Peter Saint-Andre
Date Verified: 2012-02-09

Section Appendix A says:

  # 3.6.6 Alarm Component

  component-valarm = element valarm {
       audioprop | dispprop | emailprop
   }

   type-audioprop = element properties {
       property-action &

       property-trigger &

       (property-duration, property-repeat)? &

       property-attach?
   }

   type-dispprop = element properties {
       property-action &
       property-description &
       property-trigger &
       property-summary &

       property-attendee+ &

       (property-duration, property-repeat)? &

       property-attach*
   }

   type-emailprop = element properties {
       property-action &
       property-description &
       property-trigger &

       (property-duration, property-repeat)?
   }

It should say:

  # 3.6.6 Alarm Component

  component-valarm = element valarm {
       type-audioprop | type-dispprop | type-emailprop
   }

   type-audioprop = element properties {
       property-action &

       property-trigger &

       (property-duration, property-repeat)? &

       property-attach?
   }

   type-emailprop = element properties {
       property-action &
       property-description &
       property-trigger &
       property-summary &

       property-attendee+ &

       (property-duration, property-repeat)? &

       property-attach*
   }

   type-dispprop = element properties {
       property-action &
       property-description &
       property-trigger &

       (property-duration, property-repeat)?
   }

Notes:

* the alarm properties lack the "type-"
* dispprop and emailprop have been exchanged

Errata ID: 3050
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Christian Mollekopf
Date Reported: 2011-12-13
Verifier Name: Peter Saint-Andre
Date Verified: 2012-02-09

Section Appendix A says:

   type-bysecond = element bysecond {
       xsd:positiveInteger
   }

   type-byminute = element byminute {
       xsd:positiveInteger
   }

   type-byhour = element byhour {
       xsd:positiveInteger
   }

It should say:

type-bysecond = element bysecond {
       xsd:nonNegativeInteger
   }

   type-byminute = element byminute {
       xsd:nonNegativeInteger
   }

   type-byhour = element byhour {
       xsd:nonNegativeInteger
   }

Notes:

Those values can be 0 (per RFC 5545) and xsd:positiveInteger doesn't allow that.

Errata ID: 3679
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Angstadt
Date Reported: 2013-07-11
Verifier Name: Barry Leiba
Date Verified: 2013-08-21

Section B.2.2 says:

<tzid>US/Eastern</tzid>

It should say:

<tzid><text>US/Eastern</text></tzid>

Notes:

The "tzid" property in the second example (p.51) is not formatted correctly. The property value should be enclosed in a "<text>" element.

Errata ID: 2929
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Philipp Kewisch
Date Reported: 2011-08-10
Verifier Name: Peter Saint-Andre
Date Verified: 2011-08-12

Section B.2.1. says:

VERSION:2.0
PRODID:-//Example Corp.//Example Client//EN
BEGIN:VTIMEZONE

It should say:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Inc.//Example Client//EN
BEGIN:VTIMEZONE

Notes:

Example Inc. is used in all examples, especially in Section B.2.2, the matching XML Data. Also, the BEGIN:VCALENDAR is missing.

Errata ID: 3892
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Clement Pellerin
Date Reported: 2014-02-14
Verifier Name: Barry Leiba
Date Verified: 2014-02-14

Section B.1.1 says:

   BEGIN:VCALENDAR
   CALSCALE:GREGORIAN
   PRODID:-//Example Inc.//Example Calendar//EN
   VERSION:2.0
   BEGIN:VEVENT
   DTSTAMP:20080205T191224Z
   DTSTART:20081006
   SUMMARY:Planning meeting
   UID:4088E990AD89CB3DBB484909
   END:VEVENT
   END:VCALENDAR

It should say:

   BEGIN:VCALENDAR
   CALSCALE:GREGORIAN
   PRODID:-//Example Inc.//Example Calendar//EN
   VERSION:2.0
   BEGIN:VEVENT
   DTSTAMP:20080205T191224Z
   DTSTART;VALUE=DATE:20081006
   SUMMARY:Planning meeting
   UID:4088E990AD89CB3DBB484909
   END:VEVENT
   END:VCALENDAR

Notes:

The default value type of DTSTART is DATE-TIME. The definition of DATE-TIME makes the time portion mandatory. By declaring the value type explicitly, this solution makes the value legal and matches the xCal sample in B.1.2

Another solution is to change the property value to match the default DATE-TIME type
DTSTART:20081006T191224Z
and adjust the xCal example in B.1.2 to match
<dtstart>
<date-time>2008-10-06T19:12:24Z</date-time>
</dtstart>

RFC 6325, "Routing Bridges (RBridges): Base Protocol Specification", July 2011

Note: This RFC has been updated by RFC 6327, RFC 6439, RFC 7172, RFC 7177, RFC 7357, RFC 7179, RFC 7180, RFC 7455, RFC 7780, RFC 7783, RFC 8139, RFC 8249, RFC 8361, RFC 8377

Source of RFC: trill (int)

Errata ID: 3002
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Donald E. Eastlake, 3rd
Date Reported: 2011-10-25
Verifier Name: Ralph Droms
Date Verified: 2013-03-09

Section 3.7.3 says:

                                   If RB1 chooses nickname x, and RB1
      discovers, through receipt of an LSP for RB2 at any later time,
      that RB2 has also chosen x, then the RBridge or pseudonode with
      the numerically higher IS-IS ID (LAN ID) keeps the nickname, or if
      there is a tie in priority, the RBridge with the numerically
      higher IS-IS System ID keeps the nickname, and the other RBridge
      MUST select a new nickname.

It should say:

If RB1
chooses nickname x, and RB1 discovers, through receipt of an LSP for
RB2 at any later time, that RB2 has also chosen x, then the RBridge or
pseudonode with the numerically higher priority keeps the nickname, or
if there is a tie in priority, the RBridge with the numerically higher
seven-byte IS-IS ID (LAN ID) keeps the nickname, and the other RBridge
MUST select a new nickname.

Notes:

Comparison is primarily by priority and then by IS-IS ID. Since pseudonodes can hold nicknames, the comparison must be by seven-byte IS-IS ID, not six-byte System ID.

Errata ID: 3003
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Donald E. Eastlake, 3rd
Date Reported: 2011-10-25
Verifier Name: Ralph Droms
Date Verified: 2013-03-09

Section 4.6.2 says:

   1. If the Outer.MacDA is All-IS-IS-RBridges and the Ethertype is
      L2-IS-IS, the frame is handled as described in Section 4.6.2.1.

It should say:

   1. If the Ethertype is L2-IS-IS and the Outer.MacDA is either
      All-IS-IS-RBridges or the unicast MAC address of the receiving 
      RBridge port, the frame is handled as described in Section 4.6.2.1

Notes:

TRILL IS-IS MTU PDUs may be unicast as described in Section 4.3.2 of RFC 6325 and Section 5 of RFC 6327. This was not allowed for in the wording of Section 4.6.2 of RFC 6325 but is corrected above.

Errata ID: 3004
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Donald E. Eastlake, 3rd
Date Reported: 2011-10-25
Verifier Name: Ralph Droms
Date Verified: 2013-03-09

Section 4.3.2 says:

                                    The MTU-probe MAY be multicast to
   All-RBridges, or unicast to a specific RBridge.  The MTU-ack is
   normally unicast to the source of the MTU-probe to which it responds
   but MAY be multicast to All-RBridges.

It should say:

                                     The MTU-probe MUST be multicast to
   All-IS-IS-RBridges or unicast to a specific RBridge.  The MTU-ack is
   normally unicast to the source of the MTU-probe to which it responds
   but MAY be multicast to All-IS-IS-RBridges.

Notes:

TRILL IS-IS MTU PDUs are IS-IS PDUs and, when multicast, must be sent to the All-IS-IS-RBridges multicast address.

Errata ID: 3052
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Donald E. Eastlake, 3rd
Date Reported: 2011-12-15
Verifier Name: Ralph Droms
Date Verified: 2013-03-09

Section 4.5.2 says:

(up to the maximum of {j,k})

It should say:

(up to k if j is zero or the minimum of ( j, k) if j is
non-zero)

Errata ID: 3053
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Donald E. Eastlake, 3rd
Date Reported: 2011-12-15
Verifier Name: Ralph Droms
Date Verified: 2013-03-09

Section 4.3.2 says:

If X is not greater than Sz, then RB1 sets the "failed minimum MTU
test" flag for RB2 in RB1's Hello. If size X succeeds, and X > Sz,
then RB1 advertises the largest tested X for each adjacency in the
TRILL Hellos RB1 sends on that link, and RB1 MAY advertise X as an
attribute of the link to RB2 in RB1's LSP.

It should say:

If X is not greater than or equal to Sz, then RB1 sets the "failed
minimum MTU test" flag for RB2 in RB1's Hello. If size X succeeds, and
X >= Sz, then RB1 advertises the largest tested X for each adjacency
in the TRILL Hellos RB1 sends on that link, and RB1 MAY advertise X as
an attribute of the link to RB2 in RB1's LSP.

Errata ID: 3508
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Donald E. Eastlake, 3rd
Date Reported: 2013-03-05
Verifier Name: Ralph Droms
Date Verified: 2013-03-09

Section 4.5.1 says:

In other words, the set of potential parents for N, for the tree
rooted at R, consists of those that give equally minimal cost paths
from N to R and that have distinct IS-IS IDs, based on what is
reported in LSPs.

It should say:

In other words, the set of potential parents for N, for the tree 
rooted at R, consists of those that give equally minimal cost paths 
from R to N and that have distinct IS-IS IDs, based on what is 
reported in LSPs.

Notes:

Link costs can be asymmetric. The above erroneous sentence is inconsistent with the rest of 4.5.1 and normal practice. Furthermore, it is important to fix this and resolve the inconsistency because, if all RBridges in a TRILL campus do not compute the same trees, the reverse path forwarding check for multi-destination TRILL Data packet routing can erroneously discard such packets.

Errata ID: 4573
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Donald Eastlake, 3rd
Date Reported: 2015-12-30
Verifier Name: Brian Haberman
Date Verified: 2016-01-15

Section 4.9.1 says:

   o  End-station service disable (trunk port) bit.  When this bit is
      set, all native frames received on the port and all native frames
      that would have been sent on the port are discarded.  (See
      Appendix B.)  (Note that, for this document, "native frames" does
      not include Layer 2 control frames.)  By default, ports are not
      restricted to being trunk ports.

      If a port with end-station service disabled reports, in a TRILL-
      Hello frame it sends out that port, which VLANs it provides end-
      station support for, it reports that there are none.

   o  TRILL traffic disable (access port) bit.  If this bit is set, the
      goal is to avoid sending any TRILL frames, except TRILL-Hello
      frames, on the port since it is intended only for native end-
      station traffic.  By default, ports are not restricted to being
      access ports.  This bit is reported in TRILL-Hello frames.  If RB1
      is the DRB and has this bit set in its TRILL-Hello, the DRB still
      appoints VLAN forwarders.  However, usually no pseudonode is
      reported, and none of the inter-RBridge links associated with that
      link are reported in LSPs.

      If the DRB RB1 does not have this bit set, but neighbor RB2 on the
      link does have the bit set, then RB1 does not appoint RB2 as
      appointed forwarder for any VLAN, and none of the RBridges
      (including the pseudonode) report RB2 as a neighbor in LSPs.

It should say:

   o  End-station service disable (trunk port) bit.  When this bit is
      set, all native frames received on the port and all native frames
      that would have been sent on the port are discarded.  (See
      Appendix B.)  (Note that, for this document, "native frames" does
      not include Layer 2 control frames.)  By default, ports are not
      restricted to being trunk ports.

      If the DRB RB1 does not have this bit set, but neighbor RB2 on the
      link does have the bit set, then RB1 does not appoint RB2 as
      appointed forwarder for any VLAN, and none of the RBridges
      (including the pseudonode) report RB2 as a neighbor in LSPs.

      If a port with end-station service disabled reports, in a TRILL-
      Hello frame it sends out that port, which VLANs it provides end-
      station support for, it reports that there are none.

   o  TRILL traffic disable (access port) bit.  If this bit is set, the
      goal is to avoid sending any TRILL frames, except TRILL-Hello
      frames, on the port since it is intended only for native end-
      station traffic.  By default, ports are not restricted to being
      access ports.  This bit is reported in TRILL-Hello frames.  If RB1
      is the DRB and has this bit set in its TRILL-Hello, the DRB still
      appoints VLAN forwarders.  However, usually no pseudonode is
      reported, and none of the inter-RBridge links associated with that
      link are reported in LSPs.

Notes:

There is a paragraph in the wrong place so that it appears to apply to the wrong bit.

The second paragraph of bullet item 3 in Section 4.9.1 (the second bullet item at the top of page 72) is in the wrong place and appears to apply to the TRILL traffic disable (access port) bit. This text should instead be part of the previous bullet item and, in fact, applies to the end-station service disable (trunk port) bit.

RFC 6326, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", July 2011

Note: This RFC has been obsoleted by RFC 7176

Source of RFC: isis (rtg)

Errata ID: 2869
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Donald E. Eastlake, 3rd
Date Reported: 2011-07-26
Verifier Name: Stewart Bryant
Date Verified: 2011-09-14

Section 5.2 says:

      Registry Name: IS-IS Group Address Type Codes for TLV 10

It should say:

      Registry Name: IS-IS Group Address Type Codes for TLV 142

Notes:

Other numeric references for the Group Address TLV are 142, the correct value, but in this one instance, it is show as 10, which is actually the Authentication TLV type number.

RFC 6329, "IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging", April 2012

Source of RFC: isis (rtg)

Errata ID: 3503
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jan De Backer
Date Reported: 2013-02-28
Verifier Name: Adrian Farrel
Date Verified: 2013-02-28

Section 4.4 says:

   o  I-SID is the 24-bit I-Component Service ID advertised in the SPBM
      Service Identifier TLV.  It occupies the lower 24 bits of the SPBM
      multicast DA.  The I-SID value 0xfff is reserved for SPBM control
      traffic (refer to the default I-SID in [802.1aq]).

It should say:

   o  I-SID is the 24-bit I-Component Service ID advertised in the SPBM
      Service Identifier TLV.  It occupies the lower 24 bits of the SPBM
      multicast DA.  The I-SID value 0x0000ff is reserved for SPBM control
      traffic (refer to the default I-SID in [802.1aq]).

Notes:

The correct value of the I-SID for SPBM control traffic is decimal 255 or 0xff. As a 24 bit value this is 0x0000ff.

RFC 6330, "RaptorQ Forward Error Correction Scheme for Object Delivery", August 2011

Source of RFC: rmt (tsv)

Errata ID: 5548
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Eugene Kim
Date Reported: 2018-11-07
Verifier Name: Magnus Westerlund
Date Verified: 2020-06-02

Section 3.3.2 says:

   o  Transfer Length (F): 40-bit unsigned integer.  A non-negative
      integer that is at most 946270874880.  This is the transfer length
      of the object in units of octets.

...

      NOTE: The limit of 946270874880 on the transfer length is a
      consequence of the limitation on the symbol size to 2^^16-1, the
      limitation on the number of symbols in a source block to 56403,
      and the limitation on the number of source blocks to 2^^8.

It should say:

   o  Transfer Length (F): 40-bit unsigned integer.  A non-negative
      integer that is at most 942574504275.  This is the transfer length
      of the object in units of octets.

...

      NOTE: The limit of 942574504275 on the transfer length is a
      consequence of the limitation on the symbol size to 2^^16-1, the
      limitation on the number of symbols in a source block to 56403,
      and the limitation on the number of source blocks to 2^^8-1.

Notes:

Section 3.3.3 defines the number of source blocks (Z) as an unsigned 8-bit integer, whose maximum value is 2^^8-1 (255), and not 2^^8. This in turn changes the limit on the transfer length, which is now 56403*(2^^16-1)*(2^^8-1) = 942574504275.

RFC 6333, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", August 2011

Note: This RFC has been updated by RFC 7335

Source of RFC: softwire (int)

Errata ID: 5847
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mikael Abrahamsson
Date Reported: 2019-08-26
Verifier Name: Eric Vyncke
Date Verified: 2021-05-17

Section 5.3 says:

   However, as not all service providers will be able to increase their
   link MTU, the B4 element MUST perform fragmentation and reassembly if
   the outgoing link MTU cannot accommodate the extra IPv6 header.  The
   original IPv4 packet is not oversized.  The packet is oversized after
   the IPv6 encapsulation.  The inner IPv4 packet MUST NOT be
   fragmented.  Fragmentation MUST happen after the encapsulation of the
   IPv6 packet.  Reassembly MUST happen before the decapsulation of the
   IPv4 packet.  A detailed procedure has been specified in [RFC2473]
   Section 7.2.

It should say:

   However, as not all service providers will be able to increase their
   link MTU, the B4 element MUST perform fragmentation and reassembly if
   the outgoing link MTU cannot accommodate the extra IPv6 header.  The
   original IPv4 packet is not oversized.  The packet is oversized after
   the IPv6 encapsulation.  The inner IPv4 packet MUST NOT be
   fragmented.  Fragmentation MUST happen after the encapsulation of the
   IPv4 packet in the IPv6 packet.  Reassembly of the IPv6 packet MUST happen before the decapsulation of the
   IPv4 packet.  A detailed procedure has been specified in [RFC2473]
   Section 7.2 following point b) and ignoring the DF-bit setting.

Notes:

I do not have a corrected text. The above text doesn't say what RFC2473 section 7.2 says, so... what should it be? RFC2473 7.2 says to use the DF bit and decide whether to inner fragment or drop+send ICMP error. The above text seems to make normative statements that counter at least the DF=1 case in RFC2473 7.2. Also the text above says "Fragmentation MUST happen after the encapsulation of the IPv6 packet.". The IPv6 packet isn't encapsulated, so that sentence should be changed?

--- Verifier note ---
Following the discussion in https://mailarchive.ietf.org/arch/msg/softwires/bBQT97R7p1Ho4cUZIP2MFU5ZYJ4/ , the original intent is to avoid fragmenting the IPv4 packet before encapsulation.

Errata ID: 6584
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mohamed Boucadair
Date Reported: 2021-05-17
Verifier Name: Eric Vyncke
Date Verified: 2021-05-17

Section 6.3 says:

   As noted previously, fragmentation and reassembly need to be taken
   care of by the tunnel endpoints.  As such, the AFTR MUST perform
   fragmentation and reassembly if the underlying link MTU cannot
   accommodate the encapsulation overhead.  Fragmentation MUST happen
   after the encapsulation on the IPv6 packet.  Reassembly MUST happen
                           ^^^^^^^^^^^^^^^^^^
   before the decapsulation of the IPv6 header.  A detailed procedure
   has been specified in [RFC2473] Section 7.2.

It should say:

   As noted previously, fragmentation and reassembly need to be taken
   care of by the tunnel endpoints.  As such, the AFTR MUST perform
   fragmentation and reassembly if the underlying link MTU cannot
   accommodate the encapsulation overhead.  Fragmentation MUST happen
   after the IPv6 encapsulation.  Fragmentation MUST happen after the encapsulation of the
   IPv4 packet in the IPv6 packet.  Reassembly of the IPv6 packet MUST happen before the decapsulation of the
   IPv4 packet.  A detailed procedure has been specified in [RFC2473]
   Section 7.2 following point b) and ignoring the DF-bit setting.

Notes:

The original text is confusing as it seems to assume an extra encapsulation on the IPv6 packet, while this should be about adding an IPv6 header to an IPv4 packet.

-- verifier notes --
Following the discussion in https://mailarchive.ietf.org/arch/msg/softwires/bBQT97R7p1Ho4cUZIP2MFU5ZYJ4/ , the original intent is to avoid fragmenting the IPv4 packet before encapsulation.
See also errata 5874 on section 5.3 (the submitter's proposal has been updated by the verifier to be consistent with errata 5874).

RFC 6335, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", August 2011

Source of RFC: tsvwg (wit)

Errata ID: 3814
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Gorry Fairhurst
Date Reported: 2013-11-29
Verifier Name: Martin Stiemerling
Date Verified: 2015-12-16

Section 10.3.1 says:

Service codes are assigned on a "first come, first served" basis
according to Section 19.8 of the DCCP specification [RFC4340].

It should say:

Service Codes are generally assigned on a "first come, first
served" basis, according to the rules specified in Section 19.8
of the DCCP specification [RFC4340]. This also defines
exceptions to this policy. [RFC5595] updated the policy
to require Service Codes assignments
in a Standards-Track specification to be assigned from the
Specifications-Required portion of the Service Code registry.

Notes:

RFC 6335 should have noted in Section 10.3.1: Exceptions to the FCFS
policy are documented in RFC 4340. RFC 5595 updated the usage of the SC
values described in RFC 4340.

RFC 6345, "Protocol for Carrying Authentication for Network Access (PANA) Relay Element", August 2011

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: int

Errata ID: 2996
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Yoshihiro Ohba
Date Reported: 2011-10-13
Verifier Name: Brian Haberman
Date Verified: 2012-09-07

Section 2 says:

When the PRE receives the PRY message, it retrieves the PAA-
originated PANA message from the Relayed-Message AVP and the PaC's
IP address and UDP port number from and PaC-Information AVPs.  The
PAA-originated PANA message is sent to the PaC's IP address with
the source UDP port number set to the PANA port number (716) and
the destination UDP port number set to the UDP port number contained
in the Relayed-Message AVP.

It should say:

When the PRE receives the PRY message, it retrieves the PAA-
originated PANA message from the Relayed-Message AVP and the PaC's
IP address and UDP port number from and PaC-Information AVPs.  The
PAA-originated PANA message is sent to the PaC's IP address with
the source UDP port number set to the PANA port number (716) and
the destination UDP port number set to the UDP port number contained
in the PaC-Information AVP.

Notes:

(s/Relayed-Message/PaC-Information/ in the last sentence.) The reason for the change is that the UDP port number is contained in the PaC-Information AVP instead of the Relayed Message AVP.

RFC 6350, "vCard Format Specification", August 2011

Note: This RFC has been updated by RFC 6868

Source of RFC: vcarddav (app)

Errata ID: 3086
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Roberto Javier Godoy
Date Reported: 2012-01-09
Verifier Name: Peter Saint-Andre
Date Verified: 2012-01-23

Section 6.2.6 says:

     ANNIVERSARY-param = "VALUE=" ("date-and-or-time" / "text")
     ANNIVERSARY-value = date-and-or-time / text
       ; Value and parameter MUST match.

     ANNIVERSARY-param =/ altid-param / calscale-param / any-param
       ; calscale-param can only be present when ANNIVERSARY-value is
       ; date-and-or-time and actually contains a date or date-time.

It should say:

     ANNIVERSARY-param = ANNIVERSARY-param-date / ANNIVERSARY-param-text
     ANNIVERSARY-value = date-and-or-time / text
       ; Value and parameter MUST match.

     ANNIVERSARY-param-date = "VALUE=date-and-or-time"
     ANNIVERSARY-param-text = "VALUE=text" / language-param
     
     ANNIVERSARY-param =/ altid-param / calscale-param / any-param
       ; calscale-param can only be present when ANNIVERSARY-value is
       ; date-and-or-time and actually contains a date or date-time.

Notes:

language-param should be allowed when ANNIVERSARY is reset to a single text value (BDAY, defined in section 6.2.5 accepts language-param)

Errata ID: 3136
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kai Giebeler
Date Reported: 2012-02-25
Verifier Name: Peter Saint-Andre
Date Verified: 2012-02-27

Section 3.3. says:

   QSAFE-CHAR = WSP / "!" / %x23-7E / NON-ASCII
     ; Any character except CTLs, DQUOTE

   SAFE-CHAR = WSP / "!" / %x23-39 / %x3C-7E / NON-ASCII
     ; Any character except CTLs, DQUOTE, ";", ":"

   VALUE-CHAR = WSP / VCHAR / NON-ASCII
     ; Any textual character

It should say:

   QSAFE-CHAR = WSP / "!" / %x23-7E / NON-ASCII
     ; Any character except CTLs, DQUOTE but including HTAB

   SAFE-CHAR = WSP / "!" / %x23-39 / %x3C-7E / NON-ASCII
     ; Any character except CTLs, DQUOTE, ";", ":" but including HTAB

   VALUE-CHAR = WSP / VCHAR / NON-ASCII
     ; Any textual character including HTAB

Notes:

The ABNF is inconsistent with the textual decription regarding the HTAB character which is part of WSP and CTL

Alternatively HTAB could be excluded by replacing WSP by SP in at least QSAFE-CHAR and SAFE-CHAR.

PSA: During discussion on the VCARDDAV list, Barry Leiba noted: "His point for the first two is that HTAB is a CTL (according to RFC 5234), so the comment "any character except CTLs" excludes HTAB. But the grammar uses WSP, which *includes* HTAB (also RFC 5234). So the comment is not consistent with the grammar. Either change WSP to SP (thus excluding HTAB, as the comment says) or make the change he suggests to the comment, so it's consistent with the grammar. For the third item, VALUE-CHAR, I think the point is that it's not
clear whether HTAB is a "textual character", since that term isn't
formally defined. By saying "including HTAB" in the comment (since
it's included by WSP), it's clearer." Agreement on list that this is a correct erratum. -- Peter Saint-Andre

Errata ID: 3377
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Stefan Ganzer
Date Reported: 2012-10-12
Verifier Name: Barry Leiba
Date Verified: 2012-10-12

Section 4 says:

component = "\\" / "\," / "\;" / "\n" / WSP / NON-ASCII
               / %x21-2B / %x2D-3A / %x3C-5B / %x5D-7E

It should say:

COMPONENT-CHAR = "\\" / "\," / "\;" / "\n" / WSP / NON-ASCII
               / %x21-2B / %x2D-3A / %x3C-5B / %x5D-7E
	   ; Backslashes, commas, semicolons, and newlines must be encoded.

component = *COMPONENT-CHAR

Notes:

The property value data type "component" should be defined analogous to "text".

Errata ID: 3484
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Roberto Javier Godoy
Date Reported: 2013-02-17
Verifier Name: Barry Leiba
Date Verified: 2013-02-18

Section 4 says:

time          = hour [minute [second]] [zone]
              /  "-"  minute [second]  [zone]
              /  "-"   "-"    second   [zone]

It should say:

time          = hour [minute [second]] [zone]
              /  "-"  minute [second]  
              /  "-"   "-"    second   

Notes:

Truncated time representations are defined in ISO 8601:2000 subclause 5.3.1.4

From ISO 8601:2000 subclauses 5.3.3 and 5.4.3.2, the UTC designator and utc-offset may only be applied to the representations specified in 5.3.1.1 through 5.3.1.3 (i.e. Complete representation, representations with reduced precision, and representation of decimal fractions).

If follows that the UTC designator or utc-offset must not be written after a truncated representation (second and third line of the corrected ABNF). For instance, the following representation should not be allowed: --42Z (the 42th second of a minute in Coordinated Universal Time)

Errata ID: 3713
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Angstadt
Date Reported: 2013-08-29
Verifier Name: Barry Leiba
Date Verified: 2013-08-29

Section 5.9 says:

           FN:Rene van der Harten
           N;SORT-AS="Harten,Rene":van der Harten;Rene,J.;Sir;R.D.O.N.

           FN:Robert Pau Shou Chang
           N;SORT-AS="Pau Shou Chang,Robert":Shou Chang;Robert,Pau;;

           FN:Osamu Koura
           N;SORT-AS="Koura,Osamu":Koura;Osamu;;

           FN:Oscar del Pozo
           N;SORT-AS="Pozo,Oscar":del Pozo Triscon;Oscar;;

           FN:Chistine d'Aboville
           N;SORT-AS="Aboville,Christine":d'Aboville;Christine;;

           FN:H. James de Mann
           N;SORT-AS="Mann,James":de Mann;Henry,James;;

It should say:

           FN:Rene van der Harten
           N;SORT-AS="Harten,Rene":van der Harten;Rene;J.;Sir;R.D.O.N.

           FN:Robert Pau Shou Chang
           N;SORT-AS="Pau Shou Chang,Robert":Shou Chang;Robert;Pau;;

           FN:Osamu Koura
           N;SORT-AS="Koura,Osamu":Koura;Osamu;;;

           FN:Oscar del Pozo
           N;SORT-AS="Pozo,Oscar":del Pozo Triscon;Oscar;;;

           FN:Chistine d'Aboville
           N;SORT-AS="Aboville,Christine":d'Aboville;Christine;;;

           FN:H. James de Mann
           N;SORT-AS="Mann,James":de Mann;Henry;James;;

Notes:

The N properties in this example text are missing the "additional names" component.

Three of the properties have a "given name" component which contains two values. For these properties, the second value should be used as the value of the additional names component.

The other three properties do not have any additional names. For these properties, an empty component should be added (a semi-colon character should be added to the property value).

Errata ID: 3846
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: David Riggle
Date Reported: 2013-12-20
Verifier Name: Barry Leiba
Date Verified: 2013-12-23

Section 6.5.2 says:

           GEO:geo:37.386013,-122.082932

It should say:

           GEO:geo:37.386013\,-122.082932

Notes:

Section 3.4 states that all property values must have COMMA characters escaped with a BACKSLASH character. The GEO property value in the example contains a comma. Therefore it must be escaped with a backslash.

Errata ID: 3845
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: David Riggle
Date Reported: 2013-12-20
Verifier Name: Barry Leiba
Date Verified: 2013-12-23

Section 6.2.4 says:

       PHOTO:data:image/jpeg;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhv

It should say:

       PHOTO:data:image/jpeg;base64\,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhv

Notes:

Section 3.4 states that all property values must have COMMA characters escaped with a BACKSLASH character. The PHOTO property value in the example contains a comma. Therefore it must be escaped with a backslash. Note that there are several other uses of the "data:" URI scheme in the document that also need to be corrected.

Alternatively, a different format for base64 encoded data could be used in vCard 4.0. The ENCODING=b format used in vCard 3.0 wasn't so bad.


----- Verifier notes -----
This represents a difference from earlier versions of vCard, and the ABNF does not support escaping for URIs. This errata report is correct and verified, but a full correction to the issue will have to wait for a document update.

Errata ID: 2964
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-09-08
Verifier Name: Peter Saint-Andre
Date Verified: 2011-09-09

Section 3.3 says:

   param-value = *SAFE-CHAR / DQUOTE *QSAFE-CHAR DQUOTE

It should say:

   param-value = *SAFE-CHAR / ( DQUOTE *QSAFE-CHAR DQUOTE )

Notes:

This is to remove possibility of doubly understanding, eg.:

param-value = ( *SAFE-CHAR / DQUOTE ) *QSAFE-CHAR DQUOTE

or

param-value = *SAFE-CHAR / ( DQUOTE *QSAFE-CHAR DQUOTE )

with the latter being right. See also http://www.ietf.org/mail-archive/web/vcarddav/current/msg02318.html.

Errata ID: 3000
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-10-21
Verifier Name: Peter Saint-Andre
Date Verified: 2011-11-12

Section 10.3.4 says:

   The following table is to be used to initialize the property values
   registry.

            +----------+------------+-------------------------+
            | Property | Value      | Reference               |
            +----------+------------+-------------------------+
            | BEGIN    | VCARD      | RFC 6350, Section 6.1.1 |
            | END      | VCARD      | RFC 6350, Section 6.1.2 |
            | KIND     | individual | RFC 6350, Section 6.1.4 |
            | KIND     | group      | RFC 6350, Section 6.1.4 |
            | KIND     | org        | RFC 6350, Section 6.1.4 |
            | KIND     | location   | RFC 6350, Section 6.1.4 |
            +----------+------------+-------------------------+

It should say:

   The following table is to be used to initialize the property values
   registry.

            +----------+------------+-------------------------+
            | Property | Value      | Reference               |
            +----------+------------+-------------------------+
            | BEGIN    | VCARD      | RFC 6350, Section 6.1.1 |
            | END      | VCARD      | RFC 6350, Section 6.1.2 |
            | KIND     | individual | RFC 6350, Section 6.1.4 |
            | KIND     | group      | RFC 6350, Section 6.1.4 |
            | KIND     | org        | RFC 6350, Section 6.1.4 |
            | KIND     | location   | RFC 6350, Section 6.1.4 |
            | VERSION  | 4.0        | RFC 6350, Section 6.7.9 |
            +----------+------------+-------------------------+

Notes:

Here the registration of "4.0" value for VERSION is added, as it was discussed on WG mailing list. When the erratum is approved, I'll ask IANA to add an entry on the registry, correspondingly.

Errata ID: 3137
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kai Giebeler
Date Reported: 2012-02-25
Verifier Name: Peter Saint-Andre
Date Verified: 2012-02-27

Section 5.4. says:

The ALTID property MAY also be used in may contexts other than with
   the LANGUAGE parameter.

It should say:

The ALTID property MAY also be used in many contexts other than with
   the LANGUAGE parameter.

Errata ID: 3368
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stefan Ganzer
Date Reported: 2012-10-01
Verifier Name: Barry Leiba
Date Verified: 2012-10-01

Section 7.1.3 says:

BEGIN:VCARD
VERSION:4.0
EMAIL;PID=4.2,5.1:jdoe@example.com
CLIENTPIDMAP:1;urn:uuid:3eef374e-7179-4196-a914-27358c3e6527
CLIENTPIDMAP:2;urn:uuid:42bcd5a7-1699-4514-87b4-056edf68e9cc
END:VCARD

BEGIN:VCARD
VERSION:4.0
EMAIL;PID=5.1,5.2:john@example.com
CLIENTPIDMAP:1;urn:uuid:0c75c629-6a8d-4d5e-a07f-1bb35846854d
CLIENTPIDMAP:2;urn:uuid:3eef374e-7179-4196-a914-27358c3e6527
END:VCARD

It should say:

BEGIN:VCARD
VERSION:4.0
FN:J. Doe
EMAIL;PID=4.2,5.1:jdoe@example.com
CLIENTPIDMAP:1;urn:uuid:3eef374e-7179-4196-a914-27358c3e6527
CLIENTPIDMAP:2;urn:uuid:42bcd5a7-1699-4514-87b4-056edf68e9cc
END:VCARD

BEGIN:VCARD
VERSION:4.0
FN:J. Doe
EMAIL;PID=5.1,5.2:john@example.com
CLIENTPIDMAP:1;urn:uuid:0c75c629-6a8d-4d5e-a07f-1bb35846854d
CLIENTPIDMAP:2;urn:uuid:3eef374e-7179-4196-a914-27358c3e6527
END:VCARD

Notes:

Section 6.2.1 states that "[t]he [FN] property MUST be present in the vCard object."

Errata ID: 3748
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Philipp Kewisch
Date Reported: 2013-10-10
Verifier Name: Barry Leiba
Date Verified: 2013-10-10

Section 10.3.3 says:

The following table has been used to initialize the parameters registry.

It should say:

The following table has been used to initialize the data types registry.

Notes:

This is a copy/paste failure from the previous section.

Errata ID: 4246
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Enderlin
Date Reported: 2015-01-28
Verifier Name: Barry Leiba
Date Verified: 2015-02-01

Section 6.2.5 says:

             BDAY;19531015T231000Z

It should say:

             BDAY:19531015T231000Z

Notes:

A typo when declaring the third BDAY property example: It is a colon, not a semi-colon.

RFC 6351, "xCard: vCard XML Representation", August 2011

Note: This RFC has been updated by RFC 6868

Source of RFC: vcarddav (app)

Errata ID: 2994
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Simon Perreault
Date Reported: 2011-10-12
Verifier Name: Peter Saint-Andre
Date Verified: 2011-10-17

Section Appendix A says:

# 6.1.3
property-source = element source {
    element parameters { param-altid, param-pid, param-pref,
                         param-mediatype },
    value-uri
  }

It should say:

# 6.1.3
property-source = element source {
    element parameters { param-altid, param-pid, param-pref,
                         param-mediatype }?,
    value-uri
  }

Notes:

Parameters are optional, so there needs to be a ? at the end.

Errata ID: 3047
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Christian Mollekopf
Date Reported: 2011-12-08
Verifier Name: Peter Saint-Andre
Date Verified: 2011-12-09

Section Appendix A. says:

# 6.4.1
property-tel = element tel {
    element parameters {
      param-altid,
      param-pid,
      param-pref,
      element type {
        element text { "work" | "home" | "text" | "voice"
                     | "fax" | "cell" | "video" | "pager"
                     | "textphone" }+
      }?,
      param-mediatype
    }?,
    (value-text | value-uri)
  }

It should say:

# 6.4.1
property-tel = element tel {
    element parameters {
      param-altid,
      param-pid,
      param-pref,
      element type {
        element text { "work" | "home" | "text" | "voice"
                     | "fax" | "cell" | "video" | "pager"
                     | "textphone" | x-name | iana-token }+
      }?,
      param-mediatype
    }?,
    (value-text | value-uri)
  }

Notes:

x-name and iana-token is missing in a couple of explicit listings of values, the above is just an example. RFC6350 allows extending these values with own x-names though.

This should be corrected in:
param-type
param-calscale
property-tel

Errata ID: 4241
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Enderlin
Date Reported: 2015-01-26
Verifier Name: Barry Leiba
Date Verified: 2015-01-26

Section 5 says:

     BEGIN:VCARD
     VERSION:4.0
     contact.FN=...
     contact.EMAIL=...
     media.PHOTO=...
     CATEGORIES=...
     END:VCARD

It should say:

     BEGIN:VCARD
     VERSION:4.0
     contact.FN:...
     contact.EMAIL:...
     media.PHOTO:...
     CATEGORIES:...
     END:VCARD

Notes:

Property names and values are separated by a colon, not an equal sign.

Errata ID: 4243
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Enderlin
Date Reported: 2015-01-27
Verifier Name: Barry Leiba
Date Verified: 2015-01-27

Section 5.1 says:

   Examples:

     <x-my-prop>
       <parameters>
         <pref><integer>1</integer></pref>
       </parameters>
       <text>value goes here</text>
     </x-my-prop>

     <ext:my-prop
         ext:xmlns="http://example.com/extensions/my-vcard">
       <parameters>
         <pref><integer>1</integer></pref>
       </parameters>                 <!-- Core vCard elements  -->
       <text>value goes here</text>  <!-- are still accessible -->
     </ext:my-prop>

It should say:

   Examples:

     <x-my-prop>
       <parameters>
         <pref><integer>1</integer></pref>
       </parameters>
       <text>value goes here</text>
     </x-my-prop>

     <ext:my-prop
         xmlns:ext="http://example.com/extensions/my-vcard">
       <parameters>
         <pref><integer>1</integer></pref>
       </parameters>                 <!-- Core vCard elements  -->
       <text>value goes here</text>  <!-- are still accessible -->
     </ext:my-prop>

Notes:

The correct declaration of the "ext" namespace is "xmlns:ext", not "ext:xmlns".

Errata ID: 4247
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Enderlin
Date Reported: 2015-01-28
Verifier Name: Barry Leiba
Date Verified: 2015-02-01

Section Appendix A says:

# 4.3.2
value-time = element time {
    xsd:string { pattern = "(\d\d(\d\d(\d\d)?)?|-\d\d(\d\d?)|--\d\d)"
                         ~ "(Z|[+\-]\d\d(\d\d)?)?" }
  }

It should say:

# 4.3.2
value-time = element time {
    xsd:string { pattern = "(\d\d(\d\d(\d\d)?)?|-\d\d(\d\d)?|--\d\d)"
                         ~ "(Z|[+\-]\d\d(\d\d)?)?" }
  }

Notes:

The second element of the first disjunction is -\d\d(\d\d)?, not -\d\d(\d\d?) (the question mark is not well placed).

RFC 6352, "CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV)", August 2011

Note: This RFC has been updated by RFC 6764

Source of RFC: vcarddav (app)

Errata ID: 4784
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ricki Hirner
Date Reported: 2016-08-20
Verifier Name: Alexey Melnikov
Date Verified: 2016-08-25

Section 10.4 says:

attributes can be used on each variant of the
CALDAV:address-data XML element.

It should say:

attributes can be used on each variant of the
CARDDAV:address-data XML element.

Notes:

The address-data element is located in the CARDDAV namespace.

RFC 6365, "Terminology Used in Internationalization in the IETF", September 2011

Source of RFC: appsawg (app)

Errata ID: 2966
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2011-09-10
Verifier Name: Peter Saint-Andre
Date Verified: 2011-11-12

Section 2 says:

Malay is primarily written in
      Latin script today, but the earlier, Arabic-script-based, Jawa
      form is still in use

It should say:

Malay is primarily written in
      Latin script today, but the earlier, Arabic-script-based, Jawi
      form is still in use

Notes:

I don't know this script myself but it seems that, in english, it is always called Jawi (Jawa is the old name for the island it came from, so Jawi = script from Jawa).

This script (actually a variant of the arabic one) does not seem to be in ISO 15924 so I cannot offer an authoritative reference.

RFC 6367, "Addition of the Camellia Cipher Suites to Transport Layer Security (TLS)", September 2011

Note: This RFC has been updated by RFC 8996

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 3601
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Clement Zeller
Date Reported: 2013-04-20
Verifier Name: Sean Turner
Date Verified: 2013-05-01

Section 2.3 says:

CipherSuite TLS_PSK_WITH_CAMELLIA_128_GCM_SHA256        = {0xC0,0x8D};

It should say:

CipherSuite TLS_PSK_WITH_CAMELLIA_128_GCM_SHA256        = {0xC0,0x8E};

RFC 6368, "Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)", September 2011

Note: This RFC has been updated by RFC 7606, RFC 9494

Source of RFC: l3vpn (rtg)

Errata ID: 4309
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Guillaume Gaulon
Date Reported: 2015-03-20
Verifier Name: Alia Atlas
Date Verified: 2015-04-09

Section 7 says:

   In the traditional model, where External BGP sessions are used
   between the BGP/MPLS VPN PE and CE, the PE router identifies itself
   as belonging to the customer network autonomous system.

It should say:

   In the traditional model, where External BGP sessions are used
   between the BGP/MPLS VPN PE and CE, the PE router identifies itself
   as belonging to the provider network autonomous system.

Errata ID: 7834
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Hugues Le Bastard
Date Reported: 2024-03-01
Verifier Name: John Scudder
Date Verified: 2024-03-07

Section 5 says:

Using this mechanism isolates the customer network from the
attributes used in the customer network and vice versa.  Attributes
such as the route reflection cluster list attribute are segregated
such that customer network cluster identifiers won't be considered by
the customer network route reflectors and vice versa.

It should say:

Using this mechanism isolates the customer network from the
attributes used in the provider network and vice versa.  Attributes
such as the route reflection cluster list attribute are segregated
such that customer network cluster identifiers won't be considered by
the provider network route reflectors and vice versa.

Notes:

"customer network" is used twice instead of "provider network"

RFC 6371, "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", September 2011

Note: This RFC has been updated by RFC 6435

Source of RFC: mpls (rtg)

Errata ID: 3956
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Liu Lin
Date Reported: 2014-04-10
Verifier Name: Adrian Farrel
Date Verified: 2014-04-11

Section 3.2 says:

      When an SPME is instantiated after the transport path has been
      instantiated, the TTL distance to the MIPs may change for the
      short-pipe model of TTL copying, and may change for the uniform
      model if the SPME is not co-routed with the original path.

It should say:

       When an SPME is instantiated after the transport path has been
       instantiated, the TTL distance to the MIPs may change for the
       short-pipe model, and may change for the uniform model if the
       SPME is not co-routed with the original path.

Notes:

The original report notes that there is no TTL copying in short-pipe model and states confusion arising from the text. The suggestion was to change it to:

When an SPME is instantiated after the transport path has been
instantiated, the TTL distance to the MIPs may change for the
short-pipe model of no TTL copying, and may change for the uniform
model if the SPME is not co-routed with the original path.

The authors point out that the TTL copying mode in short-pipe is "no copying". This is true, but leaves some potential confusion in the text.

The corrected text removes all mention of TTL copying (which is not relevant in this case).

RFC 6374, "Packet Loss and Delay Measurement for MPLS Networks", September 2011

Note: This RFC has been updated by RFC 7214

Source of RFC: mpls (rtg)

Errata ID: 4000
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Stewart Bryant
Date Reported: 2014-05-27
Verifier Name: Alia Atlas
Date Verified: 2014-05-28

Section 3.5 says:

Upon receipt of a query message including an unrecognized mandatory 
TLV object, the recipient MUST respond with an Unsupported Mandatory 
TLV Object error code.

It should say:

In this specification an object that is classed as mandatory is 
one that the responder MUST either support or respond to indicating 
that it does not support. Thus upon receipt of a query message 
including an unrecognized mandatory TLV object, the recipient 
MUST respond with an Unsupported Mandatory TLV Object error 
code. Note that the term mandatory does not indicate mandatory 
to implement or mandatory to send.

Notes:

In discussion on the MPLS list there was concern about the meaning
of the term "mandatory" in this RFC. The use of the term is
somewhat unusual in an IETF context, but the quoted original
text makes it clear that there is no requirement to implement
mandatory objects, only to respond to the reception of one if
it is not supported.

RFC 6376, "DomainKeys Identified Mail (DKIM) Signatures", September 2011

Note: This RFC has been updated by RFC 8301, RFC 8463, RFC 8553, RFC 8616

Source of RFC: dkim (sec)

Errata ID: 3192
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Hawthorn
Date Reported: 2012-04-14
Verifier Name: Barry Leiba
Date Verified: 2012-04-14

Section Appendix A says:

   From: Joe SixPack <joe@football.example.com>
   To: Suzie Q <suzie@shopping.example.net>
   Subject: Is dinner ready?
   Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
   Message-ID: <20030712040037.46341.5F8J@football.example.com>

   Hi.

   We lost the game.  Are you hungry yet?

   Joe.

It should say:

   From: Joe SixPack <joe@football.example.com>
   To: Suzie Q <suzie@shopping.example.net>
   Subject: Is dinner ready?
   Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
   Message-ID: <20030712040037.46341.5F8J@football.example.com>

   Hi.

   We lost the game. Are you hungry yet?

   Joe.

Notes:

This text appears three times, in A.1, A.2, and A.3. Notice the double space after "game.", which renders the body hashes in A.2 and A.3 invalid.

The corrected text, which is the same as that in RFC 4871, removes the extra space.

Errata ID: 4810
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Juan Altmayer Pizzorno
Date Reported: 2016-09-26
Verifier Name: Stephen Farrell
Date Verified: 2016-09-27

Section 3.5 says:

x-sig-q-tag-args = qp-hdr-value

It should say:

x-sig-q-tag-args = dkim-quoted-printable  ; with ":" encoded

Notes:

sig-q-tag-methods are ":"-separated in sig-q-tag, so ":" shouldn't be permitted
within x-sig-q-tag-args. Note that qp-hdr-value (which I believe was originally
defined for sig-z-tag, which includes "|"-separated values) is defined as

qp-hdr-value = dkim-quoted-printable ; with "|" encoded

Errata ID: 5070
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Chris Newman
Date Reported: 2017-07-15
Verifier Name: Barry Leiba
Date Verified: 2019-04-30

Section 3.2 says:

   tag-spec  =  [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS]
   tag-name  =  ALPHA *ALNUMPUNC
   tag-value =  [ tval *( 1*(WSP / FWS) tval ) ]
                     ; Prohibits WSP and FWS at beginning and end

It should say:

   tag-spec  =  [FWS] tag-name [FWS] "=" [FWS] [tag-value [FWS]]
   tag-name  =  ALPHA *ALNUMPUNC
   tag-value =  tval *( 1*(WSP / FWS) tval )
                     ; Prohibits WSP and FWS at beginning and end

Notes:

The ABNF in the document permits two FWS rules to appear in the row. This results in permitting a line with only whitespace in the header which falls into obsolete syntax in RFC 5322 (Appendix B rule 12). The corrected text disallows this by eliding the second FWS when the tag-value is empty/omitted.

Errata ID: 5137
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Smith
Date Reported: 2017-10-03
Verifier Name: Alexey Melnikov
Date Verified: 2017-10-18

Section 3.6.1 says:

      key-k-tag        = %x76 [FWS] "=" [FWS] key-k-tag-type

It should say:

      key-k-tag        = %x6b [FWS] "=" [FWS] key-k-tag-type

Notes:

The key-k-tag should (presumably) start with the letter "k" to match the other key-LETTER-tag definitions and to match the "k=" heading. However, the ABNF specifies %76 which is the letter "v", not the letter "k". The correct value is %x6b.

Errata ID: 5252
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alastair Houghton
Date Reported: 2018-02-02
Verifier Name: Barry Leiba
Date Verified: 2019-04-30

Section 3.7 says:

   More formally, pseudo-code for the signature algorithm is:

   body-hash    =  hash-alg (canon-body, l-param)
   data-hash    =  hash-alg (h-headers, D-SIG, body-hash)
   signature    =  sig-alg (d-domain, selector, data-hash)

   where:

   body-hash:  is the output from hashing the body, using hash-alg.

   hash-alg:   is the hashing algorithm specified in the "a" parameter.

   canon-body: is a canonicalized representation of the body, produced
               using the body algorithm specified in the "c" parameter,
               as defined in Section 3.4 and excluding the
               DKIM-Signature field.

   l-param:    is the length-of-body value of the "l" parameter.

   data-hash:  is the output from using the hash-alg algorithm, to hash
               the header including the DKIM-Signature header, and the
               body hash.

   h-headers:  is the list of headers to be signed, as specified in the
               "h" parameter.

   D-SIG:      is the canonicalized DKIM-Signature field itself without
               the signature value portion of the parameter, that is, an
               empty parameter value.

It should say:

   More formally, pseudo-code for the signature algorithm is:

   body-hash    =  hash-alg (canon-body, l-param)
   data-hash    =  hash-alg (h-headers, D-SIG)
   signature    =  sig-alg (d-domain, selector, data-hash)

   where:

   body-hash:  is the output from hashing the body, using hash-alg.

   hash-alg:   is the hashing algorithm specified in the "a" parameter.

   canon-body: is a canonicalized representation of the body, produced
               using the body algorithm specified in the "c" parameter,
               as defined in Section 3.4 and excluding the
               DKIM-Signature field.

   l-param:    is the length-of-body value of the "l" parameter.

   data-hash:  is the output from using the hash-alg algorithm, to hash
               the header including the DKIM-Signature header, and the
               body hash.

   h-headers:  is the list of headers to be signed, as specified in the
               "h" parameter.

   D-SIG:      is the canonicalized DKIM-Signature field itself without
               the signature value portion of the parameter, that is, an
               empty parameter value, with no trailing CRLF.

Notes:

data-hash does not include body-hash (body-hash is already included by virtue of the "bh=" tag in D-SIG). Also, D-SIG should not include the trailing CRLF, unlike the headers in h-headers.

Errata ID: 5839
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Occil
Date Reported: 2019-08-18
Verifier Name: Murray Kucherawy
Date Verified: 2021-12-02

Section 3.4.2 says:

   o  Delete all WSP characters at the end of each unfolded header field
      value.

It should say:

   o  Delete the SP character, if present, at the end of each unfolded
      header field value before its final CRLF

Notes:

A prior step in this section suggests that header field values include the trailing CRLF. If that is the case, then a header field value can't end with WSP, which suggests that this step is incorrectly specified. The correction I give here restores the apparent intent of this step.

[MSK: The corrected text was modified after discussion on the WG mailing list.]

Errata ID: 6076
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Levine
Date Reported: 2020-04-01
Verifier Name: Benjamin Kaduk
Date Verified: 2020-04-01

Section .6 says:

      domain-name     = sub-domain 1*("." sub-domain)
                        ; from [RFC5321] Domain,
                        ; excluding address-literal

It should say:

      domain-name     = sub-domain 1*("." sub-domain)
                        ; from [RFC5321] Domain
                        

Notes:

In RFC5321 "domain" does not include address-literal. This mistake was copied from RFC4871
(which referred to the [RFC2821] Domain, which does include address-literal).
This report is just to flag it so we don't put it in the next revision.

Errata ID: 4287
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Phil Griffin (via DCrocker)
Date Reported: 2015-03-04
Verifier Name: Barry Leiba
Date Verified: 2015-03-04

Section 3.6.1 says:

   k= Key type (plain-text; OPTIONAL, default is "rsa").  Signers and
      Verifiers MUST support the "rsa" key type.  The "rsa" key type
      indicates that an ASN.1 DER-encoded [ITU-X660-1997] RSAPublicKey
      (see [RFC3447], Sections 3.1 and A.1.1) is being used in the "p="
      tag.  (Note: the "p=" tag further encodes the value using the
      base64 algorithm.)  Unrecognized key types MUST be ignored.

and in Section 9.1:

   [ITU-X660-1997]
              "Information Technology - ASN.1 encoding rules:
              Specification of Basic Encoding Rules (BER), Canonical
              Encoding Rules (CER) and Distinguished Encoding Rules
              (DER)", 1997.

It should say:

Both instances of "[ITU-X660-1997]" should be "[ITU-X690-1997]"

Notes:

This is just a typo: "660" should be "690". The text of the reference is correct, but the document number is wrong.

Errata ID: 4926
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Simon Ser
Date Reported: 2017-02-07
Verifier Name: Stephen Farrell
Date Verified: 2017-02-14

Section A.2, A.3 says:

DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com;
     c=simple/simple; q=dns/txt; i=joe@football.example.com;
     h=Received : From : To : Subject : Date : Message-ID;
     bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
     b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
     4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
     KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
     4bmp/YzhwvcubU4=;
Received: from client1.football.example.com  [192.0.2.1]
     by submitserver.example.com with SUBMISSION;
     Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
From: Joe SixPack <joe@football.example.com>
To: Suzie Q <suzie@shopping.example.net>
Subject: Is dinner ready?
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Message-ID: <20030712040037.46341.5F8J@football.example.com>

It should say:

DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com;
      c=simple/simple; q=dns/txt; i=joe@football.example.com;
      h=Received : From : To : Subject : Date : Message-ID;
      bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
      b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
      4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
      KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
      4bmp/YzhwvcubU4=;
Received: from client1.football.example.com  [192.0.2.1]
      by submitserver.example.com with SUBMISSION;
      Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
From: Joe SixPack <joe@football.example.com>
To: Suzie Q <suzie@shopping.example.net>
Subject: Is dinner ready?
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Message-ID: <20030712040037.46341.5F8J@football.example.com>

Notes:

The "simple" header canonicalization doesn't change the header fields in any way.

Folded header fields are missing one space of indentation (they have 5 spaces instead of 6), which makes the verification fail. Note that the plain text version of the RFC adds a prefix of three spaces before each line of text, which must be ignored.

Verifier note: this was disposed of as per the IETF DKIM mailing list discussion.

In section A.3, the indentation is changed again (5 spaces instead of 6 + the "b=" tag has 2 additional spaces of indentation).

Test cases:
- opendkim: https://github.com/cyrusimap/opendkim/blob/ab2934e131cbe670b49f11db9daf8cd1223e3839/libopendkim/tests/t-testdata.h#L74
- go-dkim: https://github.com/emersion/go-dkim/blob/master/verify_test.go#L9

RFC 6377, "DomainKeys Identified Mail (DKIM) and Mailing Lists", September 2011

Source of RFC: dkim (sec)

Errata ID: 4127
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Andrew Richards
Date Reported: 2014-10-09
Verifier Name: Barry Leiba
Date Verified: 2014-10-09

Section 3.3 says:

creating that signature.  Section 5.5 of [DKIM] lists
RFC5322.Subject as one that should be covered as it contains
important user-visible text, so this is expected to be an issue
for any list that makes such changes.

It should say:

creating that signature.  Section 5.4.1 of [DKIM] lists
RFC5322.Subject as one that should be covered as it contains
important user-visible text, so this is expected to be an issue
for any list that makes such changes.

Notes:

----- Verifier notes -----
The section reference was correct when the DKIM reference was RFC 4871, but as 6376 and 6377 were published together, the reference was not changed accordingly. Oops.

RFC 6386, "VP8 Data Format and Decoding Guide", November 2011

Source of RFC: INDEPENDENT

Errata ID: 3395
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Thomas Butter
Date Reported: 2012-10-30
Verifier Name: Nevil Brownlee
Date Verified: 2012-11-01

Section 20.16./p.239 says:

   void
   vp8_dixie_tokens_process_row(struct vp8_decoder_ctx *ctx,
                                unsigned int            partition,
                                unsigned int            row,
                                unsigned int            start_col,
                                unsigned int            num_cols)
   {
       struct token_decoder *tokens = &ctx->tokens[partition];
       short              coeffs = tokens->coeffs + 25 * 16 * start_col;

It should say:

   void
   vp8_dixie_tokens_process_row(struct vp8_decoder_ctx *ctx,
                                unsigned int            partition,
                                unsigned int            row,
                                unsigned int            start_col,
                                unsigned int            num_cols)
   {
       struct token_decoder *tokens = &ctx->tokens[partition];
       short              *coeffs = tokens->coeffs + 25 * 16 * start_col;

Notes:

It seems "coeffs" should be a pointer to a short instead of a short.

RFC 6396, "Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format", October 2011

Source of RFC: grow (ops)

Errata ID: 5511
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: James Clarke
Date Reported: 2018-10-01
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2018-10-02

Section Appendix A says:

|  BGP Update =

                ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
                00 3e 02 00 00 00 1f 40 01 01 02 40 02 0e 02 03
                00 00 fb f0 00 00 fb ff 00 00 fb f6 40 03 04 c6
                33 64 55 c0 08 04 fb f0 00 0e 18 cb 00 71

                 Figure 16: MRT BGP4MP_MESSAGE_AS4 Example

It should say:

|  BGP Update =

                ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
                00 3e 02 00 00 00 23 40 01 01 02 40 02 0e 02 03
                00 00 fb f0 00 00 fb ff 00 00 fb f6 40 03 04 c6
                33 64 bc c0 08 04 fb f0 00 0e 18 cb 00 71

                 Figure 16: MRT BGP4MP_MESSAGE_AS4 Example

Notes:

The total path attribute length is incorrectly encoded as 0x001F when it should be 0x0023 and the next hop ip address is incorrectly encoded as 0xc6336455 when it should be 0xc63364bc

Errata ID: 6640
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Claudio Jeker
Date Reported: 2021-07-13
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2021-07-16

Section Appendix A says:

      |   BGP Path Attributes =

              40 01 01 00 50 02 00 0e 02 03 00 00 fb f0 00 00
              fb ff 00 00 fb f6 80 0e 2b 00 02 01 20 20 01 0d
              b8 00 0d 00 ff 00 00 00 00 00 00 01 87 fe 80 00
              00 00 00 00 00 02 12 f2 ff fe 9f 1b 00 00 00 20
              20 01 0d b8

                  Figure 19: MRT RIB_IPV6_UNICAST Example

   The contents of the BGP Path Attribute field above are as follows:

   ORIGIN: IGP
   ASPATH: 64496 64511 64502
   MP_REACH_NLRI(IPv6 Unicast)
   NEXT_HOP: 2001:db8:d:ff::187
   NEXT_HOP: fe80::212:f2ff:fe9f:1b00
   NLRI: 2001:0DB8::/32

                  Figure 20: BGP Path Attribute Contents

It should say:

      |   BGP Path Attributes =

              40 01 01 00 50 02 00 0e 02 03 00 00 fb f0 00 00
              fb ff 00 00 fb f6 80 0e 21 20 20 01 0d b8 00 0d
              00 ff 00 00 00 00 00 00 01 87 fe 80 00 00 00 00
              00 00 02 12 f2 ff fe 9f 1b 00

                  Figure 19: MRT RIB_IPV6_UNICAST Example

   The contents of the BGP Path Attribute field above are as follows:

   ORIGIN: IGP
   ASPATH: 64496 64511 64502
   MP_REACH_NLRI(IPv6 Unicast)
   NEXT_HOP: 2001:db8:d:ff::187
   NEXT_HOP: fe80::212:f2ff:fe9f:1b00

                  Figure 20: BGP Path Attribute Contents

Notes:

The encoding of the MP_REACH_NLRI attribute is not in the form according to Section 4.3.4. RIB Entries:

There is one exception to the encoding of BGP attributes for the BGP
MP_REACH_NLRI attribute (BGP Type Code 14) [RFC4760]. Since the AFI,
SAFI, and NLRI information is already encoded in the RIB Entry Header
or RIB_GENERIC Entry Header, only the Next Hop Address Length and
Next Hop Address fields are included. The Reserved field is omitted.
The attribute length is also adjusted to reflect only the length of
the Next Hop Address Length and Next Hop Address fields.

The example includes a full MP_REACH_NLRI attribute. This is a common issue with TABLE_DUMP_V2 and parsers need to implement a workaround to support the broken form.

One way of solving this is to compare the attribute length of MP_REACH_NLRI with the first byte of the attribute.
If the value of the first byte is equal to the attribute lenght - 1 then it is the RFC encoding else assume that a full MP_REACH_NLRI attribute was dumped in which case the parser needs to skip the first 3 bytes to get to the nexthop.

RFC 6402, "Certificate Management over CMS (CMC) Updates", November 2011

Source of RFC: pkix (sec)

Errata ID: 3860
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2014-01-05
Verifier Name: Sean Turner
Date Verified: 2014-01-06

Section Appendix A says:

   EnrollmentMessageSyntax-2011-v88
    { iso(1) identified-organization(3) dod(6) internet(1)
      security(5) mechanisms(5) pkix(7) id-mod(0)
      id-mod-enrollMsgSyntax-2011-88(76) }

It should say:

   EnrollmentMessageSyntax-2011-v88
    { iso(1) identified-organization(3) dod(6) internet(1)
      security(5) mechanisms(5) pkix(7) id-mod(0)
      id-mod-enrollMsgSyntax-2011-88(75) }

Notes:

The ASN.1 modules in Appendix A.1 and Appendix A.2 use the same module identifier. This correction fixes this situation, and aligns with the module identifiers assignments.

Errata ID: 5931
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2019-12-07
Verifier Name: Benjamin Kaduk
Date Verified: 2019-12-11

Section Appendix A.1 says:

    id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 }
    id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 }
    id-kp-cmcArchive OBJECT IDENTIFIER ::= { id-kp 28 }

It should say:

    id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 }
    id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 }
    id-kp-cmcArchive OBJECT IDENTIFIER ::= { id-kp 29 }

Notes:

id-kp-cmcRA and id-kp-cmcArchive are supposed to be different values. This change matches what is already in Appendix A.2.

Errata ID: 6571
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2021-05-04
Verifier Name: Roman Danyliw
Date Verified: 2022-05-10

Section Appendix A.1 says:

         pendInfo               PendInfo,
         extendedFailInfo       SEQUENCE {

It should say:

         pendInfo               PendInfo,
         extendedFailInfo       [1] SEQUENCE {

Notes:

The ASN.1 module will not compile properly without a tag on one of these elements. The ASN.1 module in Appendix A.2 has a tag in this spot.

RFC 6407, "The Group Domain of Interpretation", October 2011

Source of RFC: msec (sec)

Errata ID: 3598
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Claude Briere de L'Isle
Date Reported: 2013-04-20
Verifier Name: Sean Turner
Date Verified: 2013-05-02

Section 5.5.1 says:

DST ID Prot (1 octet) -- Value describing an IP protocol ID (e.g.,
      UDP/TCP) [PROT-REG].  A value of zero means that the DST ID Prot
      field MUST be ignored.

It should say:

To be removed, this field does not exist

Notes:

M. Brian Weiss confirmed to me that "The description of "DST ID Prot (1 octet) on Page 32 is incorrect, no such field is meant to be in Figure 8. This is definitely errata. The bullet describing "DST ID Prot (1 octet)" should be removed"

Errata ID: 3599
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Claude Briere de L'Isle
Date Reported: 2013-04-20
Verifier Name: Sean Turner
Date Verified: 2013-05-02

Section 5.5.1 says:

o  DST ID Port (2 octets) -- Value specifying a port associated with
      the source ID.  A value of zero means that the DST ID Port field
      MUST be ignored.

It should say:

o  DST ID Port (2 octets) -- Value specifying a port associated with
      the destination ID.  A value of zero means that the DST ID Port field
      MUST be ignored.

Notes:

Brian Weiss wrote "You are correct, this should be "destination ID"".

RFC 6409, "Message Submission for Mail", November 2011

Note: This RFC has been updated by RFC 8314

Source of RFC: yam (app)

Errata ID: 3995
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tony Finch
Date Reported: 2014-05-22
Verifier Name: Barry Leiba
Date Verified: 2014-06-03

Section 8.7 says:

   NOTE: SMTP [SMTP-MTA] prohibits the use of domain name aliases in
   addresses and the session-opening announcement.  As with other SMTP
   requirements, RFC 5321 effectively prohibits an MSA from forwarding
   such messages into the public Internet.  Nonetheless, unconditionally
   resolving aliases could be harmful.  For example, if www.example.net
   and ftp.example.net are both aliases for mail.example.net, rewriting
   them could lose useful information.

It should say:

   NOTE: RFC 821 and RFC 1123 prohibited the use of domain name
   aliases in addresses and the session-opening announcement.
   Because of this it is still common for MTAs to canonicalize
   domains in email addresses.  However this requirement was dropped
   during the development of RFC 2821.  The current rules about 
   domain name aliases are set out in RFC 5321 section 2.3.5.

Notes:

This errata report is correct, but the above wording is not quite correct and needs to be examined carefully before a revised version goes into a revised document.

RFC 6410, "Reducing the Standards Track to Two Maturity Levels", October 2011

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: gen

Errata ID: 3095
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2012-01-23
Verifier Name: Barry Leiba
Date Verified: 2012-05-08

Section 2.2 says:

   After review and consideration of significant errata, the IESG will
   perform an IETF-wide Last Call of at least four weeks on the
   requested reclassification.  If there is consensus for
   reclassification, the RFC will be reclassified without publication of
   a new RFC.

It should say:

   After review and consideration of significant errata, the IESG will
   perform an IETF-wide Last Call of at least four weeks on the
   requested reclassification.  If there is consensus for
   reclassification, the RFC will be reclassified with or without
   publication of a new RFC.

Notes:

Some people seem to have interpreted this text in a more restrictive manner than intended by the authors. Advancement from Proposed Standard to Internet Standard does not require the publication of a new RFC. Reclassification of an existing RFC is allowed, but reclassification in conjunction with publication of a new RFC is also allowed.

RFC 6425, "Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping", November 2011

Source of RFC: mpls (rtg)

Errata ID: 3306
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mustapha Aissaoui
Date Reported: 2012-08-01
Verifier Name: Adrian Farrel
Date Verified: 2012-08-09

Section 3.1.1 says:

3.1.1 Identifying a P2MP MPLS TE LSP


   [RFC4379] defines how an MPLS TE LSP under test may be identified in
   an echo request.  A Target FEC Stack TLV is used to carry either an
   RSVP IPv4 Session or an RSVP IPv6 Session sub-TLV.

   In order to identify the P2MP MPLS TE LSP under test, the echo
   request message MUST carry a Target FEC Stack TLV, and this MUST
   carry exactly one of two new sub-TLVs: either an RSVP P2MP IPv4
   Session sub-TLV or an RSVP P2MP IPv6 Session sub-TLV.  These sub-TLVs
   carry fields from the RSVP-TE P2MP SESSION and SENDER_TEMPLATE
   objects [RFC4875] and so provide sufficient information to uniquely
   identify the LSP.

   The new sub-TLVs are assigned Sub-Type identifiers as follows, and
   are described in the following sections.

      Sub-Type #       Length              Value Field
      ----------       ------              -----------
              17         20                RSVP P2MP IPv4 Session
              18         56                RSVP P2MP IPv6 Session

It should say:

3.1.1. Identifying a P2MP MPLS TE LSP


   [RFC4379] defines how an MPLS TE LSP under test may be identified in
   an echo request.  A Target FEC Stack TLV is used to carry either an
   RSVP IPv4 Session or an RSVP IPv6 Session sub-TLV.

   In order to identify the P2MP MPLS TE LSP under test, the echo
   request message MUST carry a Target FEC Stack TLV, and this MUST
   carry exactly one of two new sub-TLVs: either an RSVP P2MP IPv4
   Session sub-TLV or an RSVP P2MP IPv6 Session sub-TLV.  These sub-TLVs
   carry fields from the RSVP-TE P2MP SESSION and SENDER_TEMPLATE
   objects [RFC4875] and so provide sufficient information to uniquely
   identify the LSP.

   The new sub-TLVs are assigned Sub-Type identifiers as follows, and
   are described in the following sections.

      Sub-Type #       Length              Value Field
      ----------       ------              -----------
              17         20                RSVP P2MP IPv4 Session
              18         44                RSVP P2MP IPv6 Session

Notes:

Dear authors of RFC 6425,
I believe the length of the "RSVP P2MP IPv6 Session Sub-TLV" in Section 3.1.1 should be 44 bytes and not 56 bytes to match the format shown in Section 3.1.1.2.

It may be the 56 byte figure was copied over from RFC 4379 which uses a 16-byte "IPv6 tunnel end point address" as the top field in the sub-TLV in the case of an IPv6 P2P RSVP session. With an IPv6 P2MP RSVP session that field is replaced with the P2MP-ID which is a 4-byte field only.

Mustapha.

RFC 6426, "MPLS On-Demand Connectivity Verification and Route Tracing", November 2011

Source of RFC: mpls (rtg)

Errata ID: 4012
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Gregory Mirsky
Date Reported: 2014-06-10
Verifier Name: Adrian Farrel
Date Verified: 2015-01-03

Section 7.6 says:

Missing section

It should say:

7.6 New Global Flags Bit

RFC 6425 defines a registry for "Global Flags" under the
"Multi-Protocol Label Switching (MPLS) Label Switched Path
(LSP) Ping Parameters" registry.

This document defines a new Global Flag, "Validate Reverse
Path (R)". IANA has added this flag to the registry as
follows:

   Bit number  |  Name                      | Reference
   ------------+----------------------------+--------------
      13       |  Validate Reverse Path     | [RFC 6426]

Notes:

"Global Flags" registry was created per request of RFC 6425 and did not yet existed when RFC 6426 was published leading to the fumbling of this allocation. This "race condition" has to be fixed to avoid possible name-space collision between RFC 6426 and new extensions to LSP ping.

Errata ID: 3660
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Joël Repiquet
Date Reported: 2013-06-17
Verifier Name: Adrian Farrel
Date Verified: 2013-06-17

Section 7.2 says:

   Value    Meaning                 Reference
   -----    -------------------     -----------------------------
   22       Static LSP              this document (Section 2.4.1)
   23       Static Pseudowire       this document (Section 2.4.2)

It should say:

   Value    Meaning                 Reference
   -----    -------------------     -----------------------------
   22       Static LSP              this document (Section 2.3.1)
   23       Static Pseudowire       this document (Section 2.3.2)

RFC 6428, "Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile", November 2011

Note: This RFC has been updated by RFC 7214

Source of RFC: mpls (rtg)

Errata ID: 3629
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alan Davey
Date Reported: 2013-05-20
Verifier Name: Adrian Farrel
Date Verified: 2013-05-21

Section 3.5.3 says:

The length is the length of the
following data: the Global_ID, Node Identifier, and Attachment
Circuit ID (AC_ID) are as per [9].

It should say:

The length is the length in octets of the 
data following the length field.  The Global_ID, Node Identifier, 
and Attachment Circuit ID (AC_ID) are as per [9].

Notes:

Original text gave the impression that the length related to only three fields, but it actually applies to all data following the Length field. It should also be noted that the length is counted in octets.

Errata ID: 4415
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Greg Mirsky
Date Reported: 2015-07-14
Verifier Name: Deborah Brungard
Date Verified: 2015-07-20

Section text says:

bfd.MinRxInterval

It should say:

bfd.RequiredMinRxInterval

Notes:

Throughout the text document refers to bfd.MinRxInterval even though RFC 5880 refers to this state variable as bfd.RequiredMinRxInterval.

RFC 6435, "MPLS Transport Profile Lock Instruct and Loopback Functions", November 2011

Source of RFC: mpls (rtg)

Errata ID: 3429
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: David Ball
Date Reported: 2012-12-12
Verifier Name: Adrian Farrel
Date Verified: 2013-01-26

Section 4 says:

The whole of Section 4

It should say:

4.  Loopback Function

   This section provides a description of the loopback function within        
   an MPLS network.  This function is achieved through management             
   commands, so there is no protocol specification necessary.  However,       
   the loopback function is dependent on the lock function, so it is          
   appropriate to describe it in this document.                               

   The loopback function is used to test the integrity of a transport   
   path from a MEP to any other node along the same transport path.     
   This is achieved by setting the target node into loopback mode for   
   that transport path, and  transmitting a pattern of test data from   
   the MEP.  The target node loops all data received on the transport   
   path back towards the sending MEP, which extracts the test data      
   and compares it with what it sent.                                   
                                                                        
   Loopback is a function that enables a given node on a transport      
   path to return traffic to the sending MEP for that transport path    
   when in the loopback mode.  This mode corresponds to the situation   
   where, at a given node, a forwarding plane loop is configured, and   
   the incoming direction of a transport path is cross-connected to the 
   outgoing reverse direction.  Therefore, except in the case of early  
   TTL expiry, traffic sent by the source will be received by that      
   source.                                                              
                                                                        
   Data-plane loopback is an out-of-service function, as required in     
   Section 2.2.5 of RFC 5860 [1].  This function loops back all traffic  
   (including user data and OAM).  The traffic can be originated from    
   one internal point at the ingress of a transport path within an       
   interface or inserted from an input port of an interface using        
   external test equipment.  The traffic is looped back unmodified       
   (other than normal per-hop processing such as TTL decrement) in the   
   direction of the point of origin by an interface at either an         
   intermediate node or a terminating node.                              

   It should be noted that the data-plane loopback function for a         
   given transport path can be applied to data-plane loopback points      
   residing on interfaces where there may be no MEP or MIP for that       
   transport path.                                                        
                                                                          
   For data-plane loopback at an intermediate point in a transport path,  
   the loopback needs to be configured to occur at either the ingress or  
   egress interface.  This can be done using the management plane.        
                                                                          
   The management plane can be used to configure the loopback function.   
   The management plane must ensure that the MEPs at either end of a      
   transport path are locked before it requests setting a given node of   
   that transport path into loopback mode.                                

   The nature of test data and the use of loopback traffic to measure
   packet loss, delay, and delay variation are outside the scope of this
   document.

Notes:

The changes here reflect a number of minor editorial clarifications.
The original Errata Report raised by David Ball has been extensively
debated by the working group resulting in these changes.

The motivation is that the published text has caused confusion about
exactly where the loopback function is applied. There was apparent
contradiction between paragraphs 2 and 7 which seemed to imply that
the loopback point must be a MEP or a MIP, while paragraph 5 seemded
to imply that loopback is performed at a point where there is no MEP
or MIP.

The working group agrees that the intent was to state that there may
or may not be a MEP or a MIP at the loopback point. I.e., that
loopback may be performed at any point along the transport path.

The new text updates paragraphs 2, 3, 5, and 7 to embody this
clarification.

Additionally, paragraphs 6 and 7 have received a minor change to
show the role of the "management plane" rather than "management" in
the control of loopback.

Errata ID: 4017
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Huub van Helvoort
Date Reported: 2014-06-19
Verifier Name: Adrian Farrel
Date Verified: 2014-06-23

Section 1 says:

Two useful Operations, Administration, and Maintenance (OAM)
functions in a transport network are "lock" and "loopback".  This
document discusses these functions in the context of MPLS networks.

It should say:

Two useful Operations, Administration, and Maintenance (OAM)
functions in a transport network are "lock" and "loopback".  This
document discusses these functions in the context of MPLS networks.

Further information about these abstract OAM functions in an MPLS
Transport Profile context can be found in RFC 6371 [6] where the
lock function is referred to as the "Lock Instruct function (LKI)"
and the loopback function is called "data-plane loopback."

Notes:

RFC6435 uses "LI" as acronym for "Lock Instruct" throughout the document.
RFC6371 uses "LKI" for "Lock Instruct" in sections 7.1, 7.1.1 and 7.1.2.
This may confuse the reader of both documents.
A similar confusion can occur for refering to the loopback function.

RFC 6442, "Location Conveyance for the Session Initiation Protocol", December 2011

Note: This RFC has been updated by RFC 8262, RFC 8787

Source of RFC: sipcore (rai)

Errata ID: 4236
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Richard Appleton
Date Reported: 2015-01-19
Verifier Name: Ben Campbell
Date Verified: 2018-01-25

Section 5.1, 5.2 says:

              <gbp:retransmission-allowed>false
              </gbp:retransmission-allowed>

It should say:

              <gbp:retransmission-allowed>no
              </gbp:retransmission-allowed>

Notes:

as per section 4.4

This location error is specific to having the PIDF-LO [RFC4119]
<retransmission-allowed> element set to "no". This location error is
stating it requires permission (i.e., PIDF-LO <retransmission-
allowed> element set to "yes")

and RFC4119 section 2.2.2

Errata ID: 5027
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Larry Reeder
Date Reported: 2017-05-31
Verifier Name: Ben Campbell
Date Verified: 2018-01-25

Section 5.1 says:

 --boundary1

   Content-Type: application/pidf+xml
   Content-ID: <target123@atlanta.example.com>
   <?xml version="1.0" encoding="UTF-8"?>
       <presence

It should say:

 --boundary1

   Content-Type: application/pidf+xml
   Content-ID: <target123@atlanta.example.com>

   <?xml version="1.0" encoding="UTF-8"?>
       <presence

Notes:

The PIDF-LO examples in RFC 6442 don't have an empty line between the message headers and the message body in the pidf+xml bodies.

RFC 2046, section 5.1 says this about multipart MIME body parts: " After its boundary delimiter line, each body part then consists of a header area, a blank line, and a body area".

This errata also applies to the example in section 5.2

RFC 6455, "The WebSocket Protocol", December 2011

Note: This RFC has been updated by RFC 7936, RFC 8307, RFC 8441

Source of RFC: hybi (app)

Errata ID: 3150
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Robert Munyer
Date Reported: 2012-03-07
Verifier Name: Peter Saint-Andre
Date Verified: 2012-03-22

Section 4.1 says:

AQIDBAUGBwgJCgsMDQ4PEC==

It should say:

AQIDBAUGBwgJCgsMDQ4PEA==

Notes:

The "test vector" for Sec-WebSocket-Key encoding, provided in RFC 6455 section 4.1, is wrong. It was processed by a base 64 encoder that was "improperly implemented" as mentioned in RFC 4648 section 3.5. Pad bits were not set to zero, which is a "MUST" requirement in RFC 4648, and was also required by many other RFCs, going back to RFC 989 in the 1980s. In the string "AQIDBAUGBwgJCgsMDQ4PEC==", the final C should be changed to A.

In a Sec-WebSocket-Key header sent by a properly implemented client, the last letter will always be A, Q, g or w.

Errata ID: 3433
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Eric Lawrence
Date Reported: 2012-12-20
Verifier Name: Barry Leiba
Date Verified: 2012-12-22

Section 11.3.2 says:

However, the |Sec-WebSocket-Extensions| header field MUST NOT appear
more than once in an HTTP response.

It should say:

The |Sec-WebSocket-Extensions| header field MAY appear multiple 
times in an HTTP response (which is logically the same as a single
|Sec-WebSocket-Extensions| header field that contains all values).

Notes:

Section 4.2.2 Step 5 subpart 6 (top of page 25) clearly explains that this header field may appear multiple times in the server's response: "If multiple extensions are to be used, they can all be listed in a single |Sec-WebSocket-Extensions| header field or split between multiple instances of the |Sec-WebSocket-Extensions| header field. This completes the server's handshake..."

Errata ID: 3473
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Adam Rice
Date Reported: 2013-01-31
Verifier Name: Barry Leiba
Date Verified: 2013-02-18

Section 4.1 says:

   2.  If the client already has a WebSocket connection to the remote
       host (IP address) identified by /host/ and port /port/ pair, even
       if the remote host is known by another name, the client MUST wait
       until that connection has been established or for that connection
       to have failed.  There MUST be no more than one connection in a
       CONNECTING state.  If multiple connections to the same IP address
       are attempted simultaneously, the client MUST serialize them so
       that there is no more than one connection at a time running
       through the following steps.

It should say:

   2.  If the client already has a WebSocket connection to the same IP
       address and port pair, even if the remote host is known by another
       name, the client MUST wait until that connection has been established
       or for that connection to have failed.  There MUST be no more than
       one connection in the CONNECTING state for any IP address and port
       pair.  If multiple connections to the same IP address and port pair
       are attempted simultaneously, the client MUST serialize them so that
       there is no more than one connection at a time running through the
       following steps.

Notes:

The original wording makes it ambiguous whether distinct ports on the same host are considered distinct for throttling purposes. The first sentence implies that the throttling should be applied per (host,port) pair, whereas the final sentence implies it is only based on IP address.

Implementations of both interpretations appear to exist in the wild.

I propose disambiguating in favour of the (host,port) interpretation, because the host-only interpretation allows for a potential denial-of-service attack targeted against hosts which drop packets to unused ports.

For example, an attacker from a different origin can create several hundred WebSockets to "wss://google.com:81/". Each one will attempt to connect in serial, and take tens of seconds to time out.

If the user then attempts to use an application which legitimately uses a WebSocket to "wss://google.com:443/", then due to the throttling to google.com it will not be able to connect until all of the attacker's connections have timed out.

The user will perceive that the legitimate application is malfunctioning, since there is no visible sign that they are being attacked. From the server end, the attack is only apparent in the firewall logs. The actual rate of SYN packets dropped will be small and unlikely to trigger an alert.

On the other hand, with the (host,port) interpretation, connections to google.com:81 do not block connections to google.com:443, and this attack is completely ineffective.

=== Verifier Notes ===

The subsequent paragraph already indicates what must be done in the case where the IP address cannot be determined, so this change should not create any difficulties in the case where the connection is tunnelled via an HTTP(S) or SOCKS5 proxy.

A separate concern has been raised that this section creates problems for WebSocket proxies and non-browser clients. That issue cannot be handled without changing the meaning of the text, so it would have to be dealt with in a document update.

RFC 6458, "Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)", December 2011

Source of RFC: tsvwg (wit)

Errata ID: 6111
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Tuexen
Date Reported: 2020-04-20
Verifier Name: Martin Duke
Date Verified: 2020-04-27

Throughout the document, when it says:

in Section 5.3.2

         SCTP_EOF:  Setting this flag invokes the SCTP graceful shutdown
            procedure on the specified association.  Graceful shutdown
            assures that all data queued by both endpoints is
            successfully transmitted before closing the association.

         SCTP_SENDALL:  This flag, if set, will cause a one-to-many
            style socket to send the message to all associations that
            are currently established on this socket.  For the one-to-
            one style socket, this flag has no effect.



in Section 5.3.4

      SCTP_EOF:  Setting this flag invokes the SCTP graceful shutdown
         procedures on the specified association.  Graceful shutdown
         assures that all data queued by both endpoints is successfully
         transmitted before closing the association.

      SCTP_SENDALL:  This flag, if set, will cause a one-to-many style
         socket to send the message to all associations that are
         currently established on this socket.  For the one-to-one style
         socket, this flag has no effect.



in Section 8.1.13

The sinfo_flags field is composed of a bitwise OR
of SCTP_UNORDERED, SCTP_EOF, and SCTP_SENDALL.



in Section 8.1.31

The snd_flags parameter is composed of a bitwise OR 
of SCTP_UNORDERED, SCTP_EOF, and SCTP_SENDALL.

It should say:

in Section 5.3.2

         SCTP_EOF:  Setting this flag invokes the SCTP graceful shutdown
            procedure on the specified association.  Graceful shutdown
            assures that all data queued by both endpoints is
            successfully transmitted before closing the association.

         SCTP_EOR: This flag, if set and explicit EOR marking (see
            Section 8.1.26) is enabled , indicates that the user data
            provided is the last part of a user message. If explicit
            EOR marking is disabled, this flag is not relevant, since the
            user data provided is a complete user message.

         SCTP_SENDALL:  This flag, if set, will cause a one-to-many
            style socket to send the message to all associations that
            are currently established on this socket.  For the one-to-
            one style socket, this flag has no effect.



in Section 5.3.4

      SCTP_EOF:  Setting this flag invokes the SCTP graceful shutdown
         procedures on the specified association.  Graceful shutdown
         assures that all data queued by both endpoints is successfully
         transmitted before closing the association.

      SCTP_EOR: This flag, if set and explicit EOR marking (see Section 8.1.26)
         is enabled , indicates that the user data provided is the last part of
         a user message. If explicit EOR marking is disabled, this flag is
         not relevant, since the user data provided is a complete user message.

      SCTP_SENDALL:  This flag, if set, will cause a one-to-many style
         socket to send the message to all associations that are
         currently established on this socket.  For the one-to-one style
         socket, this flag has no effect.



in Section 8.1.13

The sinfo_flags field is composed of a bitwise OR
of SCTP_UNORDERED, SCTP_EOF, SCTP_EOR, and SCTP_SENDALL.



in Section 8.1.31

The snd_flags parameter is composed of a bitwise OR
of SCTP_UNORDERED, SCTP_EOF, SCTP_EOR, and SCTP_SENDALL.

Notes:

The text is missing a description of how to use the SCTP_EOR flag in the Socket API. The problem was initially reported by wanglihe in https://www.rfc-editor.org/errata/eid6081

Errata ID: 6115
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Tuexen
Date Reported: 2020-04-20
Verifier Name: Martin Duke
Date Verified: 2020-04-27

Section 8.2.1 says:

sstat_state:  This contains the association's current state, i.e.,
      one of the following values:

      *  SCTP_CLOSED

      *  SCTP_BOUND

      *  SCTP_LISTEN

      *  SCTP_COOKIE_WAIT

      *  SCTP_COOKIE_ECHOED

      *  SCTP_ESTABLISHED

      *  SCTP_SHUTDOWN_PENDING

      *  SCTP_SHUTDOWN_SENT

      *  SCTP_SHUTDOWN_RECEIVED

      *  SCTP_SHUTDOWN_ACK_SENT

It should say:

sstat_state:  This contains the association's current state, i.e.,
      one of the following values:

      *  SCTP_CLOSED

      *  SCTP_LISTEN

      *  SCTP_COOKIE_WAIT

      *  SCTP_COOKIE_ECHOED

      *  SCTP_ESTABLISHED

      *  SCTP_SHUTDOWN_PENDING

      *  SCTP_SHUTDOWN_SENT

      *  SCTP_SHUTDOWN_RECEIVED

      *  SCTP_SHUTDOWN_ACK_SENT

Notes:

SCTP_BOUND is not a state of an SCTP association, so it should not be part of this list.

Errata ID: 6112
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Tuexen
Date Reported: 2020-04-20
Verifier Name: Martin Duke
Date Verified: 2020-04-27

Section 3.2 says:

The success or failure of sending the data message (with
possible SCTP_INITMSG ancillary data) will be signaled by the
SCTP_ASSOC_CHANGE event with SCTP_COMM_UP or SCTP_CANT_START_ASSOC.
If user data could not be sent (due to an SCTP_CANT_START_ASSOC),
the sender will also receive an SCTP_SEND_FAILED_EVENT event.

It should say:

The success or failure of sending the data message (with
possible SCTP_INITMSG ancillary data) will be signaled by the
SCTP_ASSOC_CHANGE event with SCTP_COMM_UP or SCTP_CANT_STR_ASSOC.
If user data could not be sent (due to an SCTP_CANT_STR_ASSOC),
the sender will also receive an SCTP_SEND_FAILED_EVENT event.

Notes:

The constant SCTP_CANT_START_ASSOC is not defined. The correct name is SCTP_CANT_STR_ASSOC.

Errata ID: 6980
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Tüxen
Date Reported: 2022-05-24
Verifier Name: RFC Editor
Date Verified: 2022-05-24

Section 8 says:

The field opt specifies which SCTP socket option to get.  It can get
any socket option currently supported that requests information
(either read/write options or read-only) such as

   SCTP_RTOINFO

   SCTP_ASSOCINFO

   SCTP_PRIMARY_ADDR

   SCTP_PEER_ADDR_PARAMS

   SCTP_DEFAULT_SEND_PARAM

   SCTP_MAX_SEG

   SCTP_AUTH_ACTIVE_KEY

   SCTP_DELAYED_SACK

   SCTP_MAX_BURST

   SCTP_CONTEXT

   SCTP_EVENT

   SCTP_DEFAULT_SNDINFO

   SCTP_DEFAULT_PRINFO

   SCTP_STATUS

   SCTP_GET_PEER_ADDR_INFO

   SCTP_PEER_AUTH_CHUNKS

   SCTP_LOCAL_AUTH_CHUNKS

It should say:

The field opt specifies which SCTP socket option to get.  It can get
any socket option currently supported that requests information
(either read/write options or read-only) such as

   SCTP_RTOINFO

   SCTP_ASSOCINFO

   SCTP_PRIMARY_ADDR

   SCTP_PEER_ADDR_PARAMS

   SCTP_DEFAULT_SEND_PARAM

   SCTP_MAXSEG

   SCTP_AUTH_ACTIVE_KEY

   SCTP_DELAYED_SACK

   SCTP_MAX_BURST

   SCTP_CONTEXT

   SCTP_EVENT

   SCTP_DEFAULT_SNDINFO

   SCTP_DEFAULT_PRINFO

   SCTP_STATUS

   SCTP_GET_PEER_ADDR_INFO

   SCTP_PEER_AUTH_CHUNKS

   SCTP_LOCAL_AUTH_CHUNKS

Notes:

The constant SCTP_MAX_SEG is not defined. It should be SCTP_MAXSEG.

Errata ID: 7547
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Tüxen
Date Reported: 2023-06-22
Verifier Name: RFC Editor
Date Verified: 2023-06-22

Section 9.12 says:

info:  A pointer to the buffer containing the attribute associated
   with the message to be sent.  The type is indicated by the
   info_type parameter.

It should say:

info:  A pointer to the buffer containing the attribute associated
   with the message to be sent.  The type is indicated by the
   infotype parameter.

Notes:

The name of the parameter is infotype, not info_type.
Thanks to Philipp Stanner for making me aware of this issue.

Errata ID: 7548
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Tüxen
Date Reported: 2023-06-22
Verifier Name: RFC Editor
Date Verified: 2023-06-22

Section 9.1 says:

info:  A pointer to the buffer to hold the attributes of the received
    message.  The structure type of info is determined by the
    info_type parameter.

infolen:  An in/out parameter describing the size of the info buffer.

infotype:  On return, *info_type is set to the type of the info
    buffer.  The current defined values are as follows:

    SCTP_RECVV_NOINFO:  If both SCTP_RECVRCVINFO and SCTP_RECVNXTINFO
       options are not enabled, no attribute will be returned.  If
       only the SCTP_RECVNXTINFO option is enabled but there is no
       next message in the buffer, no attribute will be returned.  In
       these cases, *info_type will be set to SCTP_RECVV_NOINFO.

It should say:

info:  A pointer to the buffer to hold the attributes of the received
    message.  The structure type of info is determined by the
    infotype parameter.

infolen:  An in/out parameter describing the size of the info buffer.

infotype:  On return, *infotype is set to the type of the info
    buffer.  The current defined values are as follows:

    SCTP_RECVV_NOINFO:  If both SCTP_RECVRCVINFO and SCTP_RECVNXTINFO
       options are not enabled, no attribute will be returned.  If
       only the SCTP_RECVNXTINFO option is enabled but there is no
       next message in the buffer, no attribute will be returned.  In
       these cases, *infotype will be set to SCTP_RECVV_NOINFO.

Notes:

The name of the parameter is infotype, not info_type.
Thanks to Philipp Stanner for making me aware of this issue.

RFC 6460, "Suite B Profile for Transport Layer Security (TLS)", January 2012

Note: This RFC has been updated by RFC 8996

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 3363
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2012-09-24
Verifier Name: Sean Turner
Date Verified: 2012-10-30

Section 4 says:

   One of these two cipher suites MUST be the first (most preferred)
   cipher suites in the ClientHello message.  A Suite B TLS client that
   offers interoperability with servers that are not Suite B compliant
   MAY offer additional cipher suites, but any additional cipher suites
   MUST appear after the two Suite B compliant cipher suites in the
   ClientHello message.

It should say:

   One of these two cipher suites MUST be the first (most preferred)
   cipher suites in the ClientHello message, ignoring the TLS Signaling
   Cipher Suite Value (SCSV) from RFC 5746 if it is present.  A Suite B
   TLS client that offers interoperability with servers that are not
   Suite B compliant MAY offer additional cipher suites, but any
   additional cipher suites MUST appear after the two Suite B
   compliant cipher suites in the ClientHello message.

Notes:

The SCSV defined in RFC 5746 is not considered a "true cipher suite". As a result, the inclusion of the SCSV will not result in the selection of an unexpected cipher suite. This clarification makes it clear that the use of the SCSV does not prevent an implementation from being considered Suite B compliant.

RFC 6470, "Network Configuration Protocol (NETCONF) Base Notifications", February 2012

Source of RFC: netconf (ops)

Errata ID: 3957
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin Bjorklund
Date Reported: 2014-04-11
Verifier Name: Benoit Claise
Date Verified: 2014-04-15

Section 2.2 says:

       uses common-session-parms {
         when "../confirm-event != 'timeout'";
       }

       leaf confirm-event {

It should say:

       uses common-session-parms {
         when "confirm-event != 'timeout'";
       }

       leaf confirm-event {

Notes:

"uses" does not define a node. RFC 6020, 7.19.5 specifies that the context node for "when" is the node above the "uses" statement:

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 "uses", "choice", or "case" node that is also a data
node.

RFC 6474, "vCard Format Extensions: Place of Birth, Place and Date of Death", December 2011

Source of RFC: vcarddav (app)

Errata ID: 4556
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sylvain Berfini
Date Reported: 2015-12-07
Verifier Name: Barry Leiba
Date Verified: 2015-12-12

Section 2.3 says:

DEATHDATE;19531015T231000Z

It should say:

DEATHDATE:19531015T231000Z

Notes:

A typo when declaring the third DEATHDATE property example: It is a colon, not a semi-colon.

Errata ID: 4557
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sylvain Berfini
Date Reported: 2015-12-07
Verifier Name: Barry Leiba
Date Verified: 2015-12-12

Section 2.1 says:

BIRTHPLACE;VALUE=uri:geo:46.769307,-71.283079

It should say:

BIRTHPLACE;VALUE=uri:geo:46.769307\,-71.283079

Notes:

Section 3.4 in RFC 6350 states that all property values must have COMMA characters escaped with a BACKSLASH character. The BIRTHPLACE property value in the example contains a comma. Therefore it must be escaped with a backslash.

Errata ID: 4559
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sylvain Berfini
Date Reported: 2015-12-07
Verifier Name: Barry Leiba
Date Verified: 2015-12-12

Section 2.2 says:

DEATHPLACE;VALUE=uri:geo:41.731944,-49.945833

It should say:

DEATHPLACE;VALUE=uri:geo:41.731944\,-49.945833

Notes:

Section 3.4 in RFC 6350 states that all property values must have COMMA characters escaped with a BACKSLASH character. The DEATHPLACE property value in the example contains a comma. Therefore it must be escaped with a backslash.

RFC 6475, "Proxy Mobile IPv6 Management Information Base", May 2012

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: int

Errata ID: 3699
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Amanda Baber
Date Reported: 2013-08-20
Verifier Name: Brian Haberman
Date Verified: 2013-10-29

Section 5.1 says:

http://www.iana.org/mobility-parameters

It should say:

http://www.iana.org/assignments/mobility-parameters

RFC 6482, "A Profile for Route Origin Authorizations (ROAs)", February 2012

Source of RFC: sidr (rtg)

Errata ID: 3166
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Andrew Chi
Date Reported: 2012-03-25
Verifier Name: Stewart Bryant
Date Verified: 2012-10-26

Section 4 says:

...EE certificate's IP address delegation extension.

It should say:

...EE certificate's IP address delegation extension.  The EE certificate
MUST NOT use "inherit" elements as described in [RFC3779].

Notes:

Having spoken to the authors, the authors' intent was to disallow "inherit" in ROA EE certificates in order to simplify validation of ROAs. Implementers agree, and as of March 2012, the three public validator implementations already enforce this.

This erratum simply states it explicitly, whereas the original text might be misread as leaving room for indirectly-specified resources via "inherit".

This errata was discussed by the WG, please see SIDR list archive.

Errata ID: 5881
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2019-10-23
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2019-10-24

Section Appendix A says:

   END

It should say:

   id-ct-routeOriginAuthz OBJECT IDENTIFIER ::= { 1 2 840 113549 1 9 16 1 24 }

   END

Notes:

The object identifier for the ROA content type is mentioned in the document, but it is not included in the ASN.1 Module.

Errata ID: 5609
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Kristoff
Date Reported: 2019-01-20
Verifier Name: RFC Editor
Date Verified: 2019-01-22

Section Table of Contents says:

   5. Security Considerations .........................................5
   6. Acknowledgments .................................................6
   7. References ......................................................6
      7.1. Normative References .......................................6
      7.2. Informative References .....................................6

It should say:

   5. Security Considerations .........................................5
   6. IANA Considerations .............................................6
   7. Acknowledgments .................................................6
   8. References ......................................................6
      8.1. Normative References .......................................6
      8.2. Informative References .....................................6

Notes:

The Table of Contents omits the "IANA Considerations" section, which should be section 6, which consequently causes the numbered sections to be follow be labeled incorrectly.

RFC 6485, "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI)", February 2012

Note: This RFC has been obsoleted by RFC 7935

Source of RFC: sidr (rtg)

Errata ID: 4339
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sandra Murphy
Date Reported: 2015-04-20
Verifier Name: Alvaro Retana
Date Verified: 2015-05-21

Section 2. says:

      In a certification request, the OID appears in the PKCS #10
      signatureAlgorithm field [RFC2986] or in the Certificate Request
      Message Format (CRMF) POPOSigningKey signature field [RFC4211].

It should say:

      In a certification request, the OID appears in the PKCS #10
      signatureAlgorithm field [RFC2986] or in the Certificate Request
      Message Format (CRMF) POPOSigningKey algorithmIdentifier field 
      [RFC4211].

Notes:

This is technically a technical change, as it would technically affect implementation, but I believe in fact it is just a typo. Only a very inexperienced implementor would put the RFC6485 algorithm OID in the signature field of the POPOSigningKey.

This problem was noted in a message to the sidr list https://www.ietf.org/mail-archive/web/sidr/current/msg06587.html and supported by another message https://www.ietf.org/mail-archive/web/sidr/current/msg06649.html

At noted in the message to the sidr list, RFC4211 says that the POPOSigningKey is:

POPOSigningKey ::= SEQUENCE {
poposkInput [0] POPOSigningKeyInput OPTIONAL,
algorithmIdentifier AlgorithmIdentifier,
signature BIT STRING }

The OID mentioned in the RFC6485 text is for the algorithm identifier and so should appear in the algorithmIdentifier field, not the signature field.

RFC 6487, "A Profile for X.509 PKIX Resource Certificates", February 2012

Note: This RFC has been updated by RFC 7318, RFC 8209

Source of RFC: sidr (rtg)

Errata ID: 3205
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: David Mandelberg
Date Reported: 2012-04-27
Verifier Name: Stewart Bryant
Date Verified: 2013-09-19

Section 5 says:

   An RPKI CA MUST include the two extensions, Authority Key Identifier
   and CRL Number, in every CRL that it issues.  RPs MUST be prepared to
   process CRLs with these extensions.  No other CRL extensions are
   allowed.

It should say:

   An RPKI CA MUST include the two extensions, Authority Key Identifier
   and CRL Number, in every CRL that it issues.  RPs MUST be prepared to
   process CRLs with these extensions.  No other CRL extensions are
   allowed. The extensions mentioned above MUST NOT appear more than 
   once each.

Notes:

The clarification:

"The extensions mentioned above MUST NOT appear more than once each."

is added.

Errata ID: 3238
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Stephen Kent
Date Reported: 2012-05-31
Verifier Name: Stewart Bryant
Date Verified: 2013-01-11

Section 6.3 says:

 ExtendedKeyUsage
         The CA MAY honor ExtendedKeyUsage extensions of keyCertSign and
         cRLSign if present, as long as this is consistent with the
         BasicConstraints SubjectType sub-field, when specified.

It should say:

 ExtendedKeyUsage
         The CA MAY honor ExtendedKeyUsage extensions in requests for EE
         certificates that are issued to routers or other devices, consistent with values
         specified in Standards Track RFCs that adopt this profile and that identify
         application-specific requirements that motivate the use of such EKUs.

Notes:

The current text appears to be the result of a "cut and paste" error. It is essentially identical to the text
for the Key Usage extension, and names two fields that appear in that extension, not in an EKU extension. The text I propose above parallels what appears in Section 4.8.5, which describes how an
EKU MAY be used in RPKI certificates.

Errata ID: 4080
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sean Turner
Date Reported: 2014-08-12
Verifier Name: Alia Atlas
Date Verified: 2014-12-04

Section 6.1.1 says:

This field MAY be omitted.  If present, the value of this field
SHOULD be empty (i.e., NULL), in which case the CA MUST
generate a subject name that is unique in the context of
certificates issued by this CA.  This field is allowed to be
non-empty only for a re-key/reissuance request, and only if the
CA has adopted a policy (in its Certificate Practice Statement
(CPS)) that permits reuse of names in these circumstances.

It should say:

This field
SHOULD be empty (i.e., NULL), in which case the CA MUST
generate a subject name that is unique in the context of
certificates issued by this CA.  This field is allowed to be
non-empty only for a re-key/reissuance request, and only if the
CA has adopted a policy (in its Certificate Practice Statement
(CPS)) that permits reuse of names in these circumstances.

Notes:

Submitted after consultation with the responsible AD and WG chairs.

The subject field included in the PKCS#10 request can't be omitted because the ASN.1 in RFC 2986 doesn’t allow subject to be omitted - there’s no “OPTIONAL” in the ASN.1:

CertificationRequestInfo ::= SEQUENCE {
version INTEGER { v1(0) } (v1,...),
subject Name,
subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }},
attributes [0] Attributes{{ CRIAttributes }}
}

In other words, four fields are included in every certificate request. If there’s no subject field it’s a NULL (see RFC5280 for omitting subjects) and if there’s no attributes it’s an empty sequence. version and subjectPKInfo (subject public key information) are always present.

RFC 6489, "Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)", February 2012

Source of RFC: sidr (rtg)

Errata ID: 3756
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: David Mandelberg
Date Reported: 2013-10-16
Verifier Name: Stewart Bryant
Date Verified: 2013-10-30

Section 2 says:

         This
         request MUST include the same SIA extension that is present in
         the CURRENT CA certificate.

It should say:

The AccessDescriptions with accessMethods of id-ad-caRepository in the
request's SIA extension MUST be the same as the AccessDescriptions with
accessMethods of id-ad-caRepository in the CURRENT CA certificate's SIA
extension.

Notes:

An RFC6487-compliant CA certificate's SIA extension has AccessDescriptions for both its repository (id-ad-caRepository) and its manifest (id-ad-rpkiManifest). Section 2 of RFC6489 also states, "While the 'current' and 'new' CA instances share a single repository publication point, each CA has its own CRL and its own manifest." This indicates that only the id-ad-caRepository AccessDescriptions should be identical, not the id-ad-rpkiManifest AccessDescriptions.

RFC 6494, "Certificate Profile and Certificate Management for SEcure Neighbor Discovery (SEND)", February 2012

Source of RFC: csi (int)

Errata ID: 3655
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Joël Repiquet
Date Reported: 2013-06-17
Verifier Name: Brian Haberman
Date Verified: 2013-06-18

Section 4 says:

   In Sections 2, 4.9.10, and 4.9.11 of [RFC6487], it is stated that
   RFC 3779 resource extensions MUST be marked as critical and MUST be
   present in all resource certificates.  SEND certificates MUST include
   the IP Address Delegation extension [RFC3779].  This extension MUST
   include at least one address block for the IPv6 Address Family
   (AFI=0002), as described in Section 4.9.10 of [RFC6487].  SEND
   certificates MUST NOT have more than one IP Address Delegation
   extension.

It should say:

   In Sections 2, 4.8.10, and 4.8.11 of [RFC6487], it is stated that
   RFC 3779 resource extensions MUST be marked as critical and MUST be
   present in all resource certificates.  SEND certificates MUST include
   the IP Address Delegation extension [RFC3779].  This extension MUST
   include at least one address block for the IPv6 Address Family
   (AFI=0002), as described in Section 4.8.10 of [RFC6487].  SEND
   certificates MUST NOT have more than one IP Address Delegation
   extension.

Notes:

Sections 4.9.10 and 4.9.11 do not exist in RFC 6487.

RFC 6506, "Supporting Authentication Trailer for OSPFv3", February 2012

Note: This RFC has been obsoleted by RFC 7166

Source of RFC: ospf (rtg)

Errata ID: 3335
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Manav Bhatia
Date Reported: 2012-09-05
Verifier Name: Stewart Bryant
Date Verified: 2013-01-07

Section 4.5 says:

If the Protocol-Specific Authentication Key (Ks) is L octets 
long, then Ko is equal to K. 

It should say:

If the Protocol-Specific Authentication Key (Ks) is L octets 
long, then Ko is equal to Ks. 

Notes:

The key K is never used in computing the digest. There is a class of cross protocol attacks that can be prevented if the original key K is appended with a few well known bytes. As a result, the key K is appended with a 2 octet crypto protocol ID to derive a new key Ks. Its this key that must always be used.

RFC 6512, "Using Multipoint LDP When the Backbone Has No Route to the Root", February 2012

Source of RFC: mpls (rtg)

Errata ID: 6754
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bert Van Ael
Date Reported: 2021-11-25
Verifier Name: James N Guichard
Date Verified: 2023-05-31

Section 3.2.1 says:

PE1 also has this Inter-AS I-PMSI A-D route.

It should say:

PE1 also has this Intra-AS I-PMSI A-D route.

Notes:

"PE1 also has this route" refers to "Although ASBR1 does not have a route to PE2, it does have a BGP Intra-AS Inclusive PMSI (I-PMSI) auto-discovery (A-D) route". Intra-AS mechanisms are used for auto-discovery/binding for Non-Segmented Inter-AS Tunnels.

Errata ID: 6313
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alexander Vainshtein
Date Reported: 2020-10-20
Verifier Name: Deborah Brungard
Date Verified: 2021-02-26

Section 3.2.1 says:

Since P1 has no root to PE2, PE1 needs to originate an mLDP message with a FEC element that identifies ASBR1 as the root.

It should say:

Since P1 has no route to PE2, PE1 needs to originate an mLDP message with a FEC element that identifies ASBR1 as the root.

Notes:

"no root to PE2" does not parse and looks as a typo.
And it is quite clear from the context that "no route to PE2" is intended.

RFC 6519, "RADIUS Extensions for Dual-Stack Lite", February 2012

Source of RFC: softwire (int)

Errata ID: 3372
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alan DeKok
Date Reported: 2012-10-08
Verifier Name: Ralph Droms
Date Verified: 2013-03-12

Section 3 says:

   In the scenario depicted in Figure 2, the Access-Request packet
   contains a Service-Type attribute with the value Authorize Only (17);
   thus, according to [RFC5080], the Access-Request packet MUST contain
   a State attribute.

It should say:

    In the scenario depicted in Figure 2, the Access-Request packet
   contains a Service-Type attribute with the value Call-Check (10).

Notes:

The document references RFC 5080. However, the use of the State attribute in this document is wrong. The text in RFC 5080 clearly says that State is used to tie an "Authorize Only" request to a previous authentication. The text requiring State in "Authorize Only" is surrounded by explanations describing *why* it's required.

The original text in RFC 6519 appears to say that adding State magically satisfies the requirements of 5080. But it ignores all of the surrounding text.

The NAS can't simply invent a State attribute, to satisfy the requirement of 5080. It MUST get the State from a previous Access-Accept. Since there's no previous Access-Accept here, the use of Authorize-Only and State is wrong.

RFC 2865 suggests the use of "Service-Type = Call Check" for this kind of authorization checking:

Call Check

Used by the NAS in an Access-Request packet to
indicate that a call is being received and
that the RADIUS server should send back an
Access-Accept to answer the call, or an
Access-Reject to not accept the call,
typically based on the Called-Station-Id or
Calling-Station-Id attributes. It is
recommended that such Access-Requests use the
value of Calling-Station-Id as the value of
the User-Name

RFC 6520, "Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension", February 2012

Note: This RFC has been updated by RFC 8447

Source of RFC: tls (sec)

Errata ID: 6825
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Shawna Fonua
Date Reported: 2022-01-30
Verifier Name: RFC Editor

Section Overview says:

HeartbeartResponse

It should say:

HeartbeatResponse

Notes:

There is a typo of an extra 'r' in "HeartbeatReponse"

RFC 6527, "Definitions of Managed Objects for Virtual Router Redundancy Protocol Version 3 (VRRPv3)", March 2012

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 3152
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Juergen Schoenwaelder
Date Reported: 2012-03-08
Verifier Name: Adrian Farrel
Date Verified: 2012-03-08

Section 10 says:

           REVISION "201202120000Z"    -- Feb 13, 2012

It should say:

           REVISION "201202130000Z"    -- Feb 13, 2012

Notes:

The revision data does not match the date given in the comment and the date of the LAST-UPDATED clause.

Errata ID: 4168
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: vrrpv3OperationsAcceptMode description seems not proper
Date Reported: 2014-11-06
Verifier Name: Adrian Farrel
Date Verified: 2014-12-09

Section 10 says:

       vrrpv3OperationsAcceptMode OBJECT-TYPE
           SYNTAX       TruthValue
           MAX-ACCESS   read-create
           STATUS       current
           DESCRIPTION
              "Controls whether a virtual router in master state
              will accept packets addressed to the address owner's
              IPv6 address as its own if it is not the IPv6 address
              owner.  Default is false(2).
              This object is not relevant for rows representing VRRP
              over IPv4 and should be set to false(2)."
           DEFVAL       { false }
           ::= { vrrpv3OperationsEntry 11 }

It should say:

       vrrpv3OperationsAcceptMode OBJECT-TYPE
           SYNTAX       TruthValue
           MAX-ACCESS   read-create
           STATUS       current
           DESCRIPTION
              "Controls whether a virtual router in master state
              will accept packets addressed to the address owner's
              address as its own if it is not the address
              owner.  Default is false(2).
           DEFVAL       { false }
           ::= { vrrpv3OperationsEntry 11 }

Notes:

The correction is to remove the specialization on IPv4 and IPv6.

The original description says not allow to set to True for IPv4. But in practice IPv4 has use case for acceptMode-as-true too.

Here is the related state-machine description on accept mode in VRRP RFC. Step 650 doesn't not distinguish IPv4 and IPv6.
(650) - MUST accept packets addressed to the IPvX address(es)
associated with the virtual router if it is the IPvX address owner
or if Accept_Mode is True. Otherwise, MUST NOT accept these
packets.

Errata ID: 5086
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: P Quentin Armitage
Date Reported: 2017-08-13
Verifier Name: RFC Editor
Date Verified: 2017-08-14

Section 10 says:

Errata 4168 states the modified text should be:

       vrrpv3OperationsAcceptMode OBJECT-TYPE
           SYNTAX       TruthValue
           MAX-ACCESS   read-create
           STATUS       current
           DESCRIPTION
              "Controls whether a virtual router in master state
              will accept packets addressed to the address owner's
              address as its own if it is not the address
              owner.  Default is false(2).
           DEFVAL       { false }
           ::= { vrrpv3OperationsEntry 11 }

It should say:

       vrrpv3OperationsAcceptMode OBJECT-TYPE
           SYNTAX       TruthValue
           MAX-ACCESS   read-create
           STATUS       current
           DESCRIPTION
              "Controls whether a virtual router in master state
              will accept packets addressed to the address owner's
              address as its own if it is not the address
              owner.  Default is false(2)."
           DEFVAL       { false }
           ::= { vrrpv3OperationsEntry 11 }

Notes:

The DESCRIPTION needs a closing quote at the end.

RFC 6532, "Internationalized Email Headers", February 2012

Source of RFC: eai (app)

Errata ID: 3153
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dave Thaler
Date Reported: 2012-03-09
Verifier Name: Peter Saint-Andre
Date Verified: 2012-03-21

Section 4 says:

The security impact of UTF-8 headers on email signature systems such
as Domain Keys Identified Mail (DKIM), S/MIME, and OpenPGP is
discussed in Section 14 of [RFC6530].

It should say:

The security impact of UTF-8 headers on email signature systems such
as Domain Keys Identified Mail (DKIM), S/MIME, and OpenPGP is
discussed in Section 13 of [RFC6530].

Notes:

Incorrect section number in reference.

RFC 6536, "Network Configuration Protocol (NETCONF) Access Control Model", March 2012

Note: This RFC has been obsoleted by RFC 8341

Source of RFC: netconf (ops)

Errata ID: 3409
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jernej Tuljak
Date Reported: 2012-11-15
Verifier Name: Benoit Claise
Date Verified: 2012-11-23

Section 3.4.6 says:

        *  The rule does not have a "rule-type" defined or the "rule-
           type" is "notification" and the "notification-name" is "*"
           and equals the name of the notification.

It should say:

        *  The rule does not have a "rule-type" defined or the "rule-
           type" is "notification" and the "notification-name" is "*"
           or equals the name of the notification.

Notes:

The "notification-name" element may either have a value of "*" OR contains the name of the notification. This typo appears in section 3.4.6, authorization step 7, second bullet.

Errata ID: 3862
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jernej Tuljak
Date Reported: 2014-01-10
Verifier Name: Benoit Claise
Date Verified: 2014-04-18

Section 3.5.2. says:

     typedef matchall-string-type {
       type string {
         pattern "\*";
       }
       description
         "The string containing a single asterisk '*' is used
          to conceptually represent all possible values
          for the particular leaf using this data type.";
     }

It should say:

     typedef matchall-string-type {
       type string {
         pattern '\*';
       }
       description
         "The string containing a single asterisk '*' is used
          to conceptually represent all possible values
          for the particular leaf using this data type.";
     }

Notes:

As per RFC6020, Section 6.1.3., a backslash within a double-quoted string introduces a special character. The only valid escape sequences inside a double-quoted YANG string are: \n, \t, \" and \\. As \* is not a valid escape sequence, a single quoted string should be used to specify the offending pattern statement's argument. The quotes could also be omitted.

Errata ID: 3863
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jernej Tuljak
Date Reported: 2014-01-10
Verifier Name: Benoit Claise
Date Verified: 2014-04-18

Section 3.5.2. says:

     typedef group-name-type {
       type string {
         length "1..max";
         pattern "[^\*].*";
       }
       description
         "Name of administrative group to which
          users can be assigned.";
     }

It should say:

     typedef group-name-type {
       type string {
         length "1..max";
         pattern '[^\*].*';
       }
       description
         "Name of administrative group to which
          users can be assigned.";
     }

Notes:

As per RFC6020, Section 6.1.3., a backslash within a double-quoted string introduces a special character. The only valid escape sequences inside a double-quoted YANG string are: \n, \t, \" and \\. As \* is not a valid escape sequence, a single quoted string should be used to specify the offending pattern statement's argument. The quotes could also be omitted.

RFC 6545, "Real-time Inter-network Defense (RID)", April 2012

Source of RFC: mile (sec)

Errata ID: 3939
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jim Schaad
Date Reported: 2014-03-29
Verifier Name: Stephen Farrell
Date Verified: 2014-05-08

Section 7.1.1 says:

      <iodef-rid:XMLDocument dtype="xml" meaning="xml">
       <IODEF-Document lang="en">
        <iodef:Incident purpose="traceback" restriction="need-to-know">
          <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
                           CERT-FOR-OUR-DOMAIN#207-1
          </iodef:IncidentID>

It should say:

      <iodef-rid:XMLDocument dtype="xml" meaning="xml">
       <iodef:IODEF-Document lang="en">
        <iodef:Incident purpose="traceback" restriction="need-to-know">
          <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
                           CERT-FOR-OUR-DOMAIN#207-1
          </iodef:IncidentID>

Notes:

The IODEF-Document node (both opening and closing) are missing the namespace prefix. Without this, the contents of the node will not be correctly validated.

(Change is in line 2 above. The closing tag change is the same, but is not part of the delta change above.)

Errata ID: 3940
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jim Schaad
Date Reported: 2014-03-29
Verifier Name: Stephen Farrell
Date Verified: 2014-05-08

Section 5.4 says:

<RID-Document version="2.0" lang="en-US"
      xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
      xmlns:xsi="http://www.w3c.org/2001/XMLSchema-instance"
      xsi:schemaLocation="urn:ietf:params:xml:ns:iodef-rid-2.0.xsd">

It should say:

<iodef-rid:RID version="2.0" lang="en-US"
      xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
      xmlns:xsi="http://www.w3c.org/2001/XMLSchema-instance"
      xsi:schemaLocation="urn:ietf:params:xml:ns:iodef-rid-2.0.xsd
http://www.iana.org/assignments/xml-registry/schema/iodef-rid-2.0.xsd">

Notes:

Two errors in the text are fixed:

1. The root node is incorrect. It does not have a namespace declared for the root node and there is no node named RID-Document in the schema that is declared. The correct root node is RID and it should have the rid v2 name space

2. The schemaLocation is a pair of text strings in this location. The first is the namespace and the second is a location to get the schema for that namespace. An alternative is to omit the attribute as any application that is loading this document should already have the schema and should never need to go out and fetch it.

Errata ID: 3410
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kathleen Moriarty
Date Reported: 2012-11-15
Verifier Name: Sean Turner
Date Verified: 2013-03-16

Section 5.2 says:

    AuthorizationStatus

         One.  REQUIRED.  ENUM.  The listed values are used to provide a
         response to the requesting CSIRT of the status of a Request,
         Report, or Query.

         1.  Approved.  The trace was approved and will begin in the
             current SP.

         2.  Denied.  The trace was denied in the current SP.  The next
             closest SP can use this message to filter traffic from the
             upstream SP using the example packet to help mitigate the
             effects of the attack as close to the source as possible.
             The Acknowledgement message must be passed back to the
             originator and a Result message must be used from the
             closest SP to the source in order to indicate actions taken
             in the IODEF History class.

It should say:

    AuthorizationStatus

         One.  REQUIRED.  ENUM.  The listed values are used to provide a
         response to the requesting CSIRT of the status of a Request,
         Report, or Query.

         1.  Approved.  The request was approved and will be processed
             and acted upon by the receiving SP or the report was
             approved for processing.

         2.  Denied.  The message was denied for processing by the 
             recipient for the reasons provided in the Justification.
             If the RID message was a Trace, the next closest SP can
             use this message to filter traffic from the upstream SP
             using the example packet to help mitigate the effects of
             the attack as close to the source as possible.  The
             Acknowledgement message must be passed back to the
             originator and a Result message must be used from the
             closest SP to the source in order to indicate actions taken
             in the IODEF History class.

Notes:

The definition for Approved and Denied was confusing to an implementer. Although the AuthorizationStatus was broadly defined and the message flows in 7 show the Acknowledgement applies to all messages, the Approved and Denied were being read as specific to Trace Requests.

Errata ID: 4303
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vincent
Date Reported: 2015-03-15
Verifier Name: Kathleen Moriarty
Date Verified: 2015-03-24

Section 7.2. says:

Therefore, MsgDestination is set to
   'InvestigationRequest' for the Request message and is included in the
   diagram below as "Investigation".

It should say:

Therefore, MsgType is set to
   'InvestigationRequest' for the Request message and is included in the
   diagram below as "Investigation".

Notes:

MsgDestination should be changed to MsgType, as in the example.

<iodef-rid:RIDPolicy MsgType="InvestigationRequest"
MsgDestination="SourceOfIncident">

RFC 6546, "Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS", April 2012

Source of RFC: mile (sec)

Errata ID: 3267
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Field
Date Reported: 2012-06-26
Verifier Name: Sean Turner
Date Verified: 2012-06-28

Section 3 says:

In paragraph 4 of section 3, fourth sentence:

   As RID messages MUST be
   sent using the POST method, the GET and HEAD methods have no
   particular meaning on a RID system; a RID system SHOULD answer
   'GET /' or 'HEAD /' with 204 No Content.

It should say:

Consistent with RFC 2616 section 10.4.6, a RID system MUST answer 
any HTTP request to Request-URI of '/' which uses an HTTP method 
other than 'POST' by producing an HTTP response with a status code 
of 405 Method Not Allowed.  The RID system HTTP response MUST also 
include an Allow header indicating that only the 'POST' method is 
supported.

Notes:

There has been a brief discussion of this errata on the MILE list, with the first message in the thread having been posted on June 5, 2012.

The corrected text that I have suggested above has been written as narrowly as possible, and remains consistent with the original functionality described in 6546.

Lacking support for 'GET' means that there is no way to verify if a RID endpoint is active, other than by doing a real request, i.e. a Report, or Query, etc. Thus, one might also consider supporting HEAD, e.g. for RID testing purposes, though that option has not been discussed yet. Note, however, that supporting HEAD potentially raises further issues since according to RFC 2616 the response headers to a HEAD request SHOULD be consistent with a GET, which is specifically not supported.

Errata ID: 3455
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Field
Date Reported: 2013-01-14
Verifier Name: Sean Turner
Date Verified: 2013-03-16

Section 3 says:

If a RID system receives an improper RID message in an HTTP Request,
it MUST return an appropriate 4xx Client Error result code to the 
requesting RID system.

It should say:

If a RID system receives an improper HTTP Request, it MUST return 
an appropriate 4xx Client Error result code to the requesting RID 
system.

Notes:

There has been some discussion of this issue on the MILE mailing list. Another possible option for the corrected text is to say nothing at all. That is, by changing the specification to focus on an improper HTTP request, rather than an improper RID message, the corrected text is simply a restatement of existing HTTP behavior. (Either way, this still does constitute a technical change since we would no longer be requiring the 400 status code when the error is with the *RID* content). On this technical point, we had consensus on the MILE mailing list: we SHOULD NOT require an HTTP 4xx status code when there is an error with the RID content itself (as opposed to the HTTP layer). HTTP 4xx status is reserved for errors occurring in the HTTP protocol layer. Errors in the RID content will be reported via the RID Acknowledgement message type, with appropriate choices for the RequestStatus element, and Justification attribute.

RFC 6549, "OSPFv2 Multi-Instance Extensions", March 2012

Source of RFC: ospf (rtg)

Errata ID: 4041
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jim Young
Date Reported: 2014-07-05
Verifier Name: Alia Atlas
Date Verified: 2014-07-07

Section 8 says:

8.  IANA Considerations

The size of the AuType field is reduced from 16 octets to 8 octets.
This changes the OSPF Authentication Codes registry in that the
values 256-65535 are no longer defined and are therefore deprecated.
There is no backward compatibility issue since this range of values
was previously defined as "Reserved and should not be assigned".

It should say:

8.  IANA Considerations

The size of the AuType field is reduced from 16 bits to 8 bits.
This changes the OSPF Authentication Codes registry in that the
values 256-65535 are no longer defined and are therefore deprecated.
There is no backward compatibility issue since this range of values
was previously defined as "Reserved and should not be assigned".

Notes:

Earlier in RFC6549 Section 2. OSPFv2 Instance Packet Encoding, Paragraph 2 states "All fields are as defined in [OSPFV2] except that the Instance ID field is new, and the AuType field is reduced to 8 bits from 16 bits without any change in meaning. The Instance ID field is defined as follows:". The proposed corrected text makes section 8 consistent with section 2.

RFC 6550, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", March 2012

Note: This RFC has been updated by RFC 9008, RFC 9010

Source of RFC: roll (rtg)

Errata ID: 3580
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tony Cheneau
Date Reported: 2013-04-04
Verifier Name: Adrian Farrel
Date Verified: 2013-04-10

Section 9.9.1 says:

   1.   Let C1 send a DAO containing a Target T with a Path Control
        10000000b.  Node N stores an entry associating 10000000b with
        the Path Control field for C1 and Target T.

   2.   Let C2 send a DAO containing a Target T with a Path Control
        00010000b.  Node N stores an entry associating 00010000b with
        the Path Control field for C1 and Target T.

   3.   Let C3 send a DAO containing a Target T with a Path Control
        00001100b.  Node N stores an entry associating 00001100b with
        the Path Control field for C1 and Target T.

It should say:

   1.   Let C1 send a DAO containing a Target T with a Path Control
        10000000b.  Node N stores an entry associating 10000000b with
        the Path Control field for C1 and Target T.

   2.   Let C2 send a DAO containing a Target T with a Path Control
        00010000b.  Node N stores an entry associating 00010000b with
        the Path Control field for C2 and Target T.

   3.   Let C3 send a DAO containing a Target T with a Path Control
        00001100b.  Node N stores an entry associating 00001100b with
        the Path Control field for C3 and Target T.

Notes:

Bullet 2 and 3 seem wrong. I believe "C1" should be replaced by "C2" in bullet 2 and "C1" should be replaced by "C3" in bullet 3.

This issue was initially reported by Federico Consoli on the ROLL WG mailing list.

Errata ID: 3287
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Duong Nguyen
Date Reported: 2012-07-18
Verifier Name: Adrian Farrel
Date Verified: 2012-07-29

Section 6.5.1 says:

     127-255:  Rejection; the node sending the DAO-ACK is unwilling to
               act as a parent.

It should say:

     128-255:  Rejection; the node sending the DAO-ACK is unwilling to
               act as a parent.

Notes:

The status code range of "Rejection" overlaps with status code range of "Not an outright rejection".
The text in the body of the document makes it clear that the "Corrected Text" suggested here is what was intended.

Errata ID: 3895
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lei Mou
Date Reported: 2014-02-17
Verifier Name: Adrian Farrel
Date Verified: 2014-02-24

Section 9.8 says:

1.  The DODAG Parent Address subfield of a Transmit Information
    option MUST be empty.

5. ...

   When a storing node generates a DAO, it uses the stored state of DAOs
   it has received to produce a set of RPL Target options and their
   associated Transmit Information options.

It should say:

1.  The DODAG Parent Address subfield of a Transit Information
    option MUST be empty.

5. ...

   When a storing node generates a DAO, it uses the stored state of DAOs
   it has received to produce a set of RPL Target options and their
   associated Transit Information options.

Notes:

There is no "Transmit Information option", It should be Transit Information option.

Errata ID: 6554
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2021-04-22
Verifier Name: Alvaro Retana
Date Verified: 2021-04-22

Section 9.9 says:

   2.  The node MUST logically construct groupings of its DAO parents
       while populating the Path Control field, where each group
       consists of DAO parents of equal preference.  Those groups MUST
       then be ordered according to preference, which allows for a
       logical mapping of DAO parents onto Path Control subfields (see
       Figure 27).  Groups MAY be repeated in order to extend over the
       entire bit width of the patch control field, but the order,
       including repeated groups, MUST be retained so that preference is
       properly communicated.

It should say:

   2.  The node MUST logically construct groupings of its DAO parents
       while populating the Path Control field, where each group
       consists of DAO parents of equal preference.  Those groups MUST
       then be ordered according to preference, which allows for a
       logical mapping of DAO parents onto Path Control subfields (see
       Figure 27).  Groups MAY be repeated in order to extend over the
       entire bit width of the path control field, but the order,
       including repeated groups, MUST be retained so that preference is
       properly communicated.

Notes:

Typo - patch instead of path

RFC 6551, "Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks", March 2012

Source of RFC: roll (rtg)

Errata ID: 3307
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Duong Nguyen
Date Reported: 2012-08-03
Verifier Name: Adrian Farrel
Date Verified: 2012-08-04

Section 2.1 says:

As far as the constraint is concerned, the object body
   will carry a Node Energy constraint object defined in Section 3.1
   indicating that nodes must be mains-powered:

It should say:

As far as the constraint is concerned, the object body
   will carry a Node Energy constraint object defined in Section 3.2
   indicating that nodes must be mains-powered:

Notes:

Node Energy object is mentioned in section 3.2

RFC 6555, "Happy Eyeballs: Success with Dual-Stack Hosts", April 2012

Note: This RFC has been obsoleted by RFC 8305

Source of RFC: v6ops (ops)

Errata ID: 3502
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Elle Plato
Date Reported: 2013-02-27
Verifier Name: Benoit Claise
Date Verified: 2013-03-10

Section 6 says:

   1.  Call getaddinfo(), which returns a list of IP addresses sorted by
       the host's address preference policy.

It should say:

   1.  Call getaddrinfo(), which returns a list of IP addresses sorted by
       the host's address preference policy.

Notes:

The r appears to be missing from the getaddrinfo() call. This may vary by language but C, POSIX and Perl seem to expect the r. I would think this is a trivial change, and would fall into the category of "Hold for Document Update".

Errata ID: 4728
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stefan Winter
Date Reported: 2016-07-05
Verifier Name: Joel Jaeggli
Date Verified: 2017-03-29

Section 1 says:

However, this does not scale well (to the number of DNS servers
worldwide or the number of content providers worldwide) and does
react to intermittent network path outages.

It should say:

However, this does not scale well (to the number of DNS servers
worldwide or the number of content providers worldwide) and does
not react to intermittent network path outages.

Notes:

The introduction makes a case against a whitelist of DNS servers because it does not scale well and is not flexible.
DNS server whitelists indeed to not react to intermittent network outages, so the only logical sentence to form is to state that they do not.
The "not" has been omitted, reversing the logical meaning of the sentence.

RFC 6558, "Sieve Extension for Converting Messages before Delivery", March 2012

Source of RFC: sieve (app)

Errata ID: 5561
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Thomas Schmid
Date Reported: 2018-11-25
Verifier Name: Alexey Melnikov
Date Verified: 2018-11-26

Section 3.2 says:

       require ["mime", "fileinto", "convert"];
       if header :mime :anychild :contenttype
                 "Content-Type" "image/tiff"
       {
        if (convert "image/tiff" "image/jpeg" ["pix-x=320","pix-y=240"])
        {
         fileinto "INBOX.pics";
        }
       }

It should say:

       require ["mime", "fileinto", "convert"];
       if header :mime :anychild :contenttype
                 "Content-Type" "image/tiff"
       {
        if convert "image/tiff" "image/jpeg" ["pix-x=320","pix-y=240"]
        {
         fileinto "INBOX.pics";
        }
       }

Notes:

the if condition is wrapped in parentheses which is invalid sieve syntax.

According to RFC 5288 a test has to start with and alpha numerical identifier.

Which is not true in this case. Either the parentheses need to be removed or any "anyof" or "allof" needs to be added.

RFC 6561, "Recommendations for the Remediation of Bots in ISP Networks", March 2012

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 4438
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Hoffman
Date Reported: 2015-08-08
Verifier Name: Roman Danyliw
Date Verified: 2022-01-19

Section 1.1.5 says:

   Domain Name System (DNS) fast fluxing occurs when a domain is bound
   in DNS using A records to multiple IP addresses, ...

It should say:

   Domain Name System (DNS) fast fluxing occurs when a domain is found
   in DNS using A records to multiple IP addresses, ...

RFC 6570, "URI Template", March 2012

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 6937
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Vincent Biret
Date Reported: 2022-04-18
Verifier Name: Francesca Palombini
Date Verified: 2022-05-06

Section 2.1 says:

   literals      =  %x21 / %x23-24 / %x26 / %x28-3B / %x3D / %x3F-5B
                   /  %x5D / %x5F / %x61-7A / %x7E / ucschar / iprivate
                   /  pct-encoded
                        ; any Unicode character except: CTL, SP,
                        ;  DQUOTE, "'", "%" (aside from pct-encoded),
                        ;  "<", ">", "\", "^", "`", "{", "|", "}"

It should say:

   literals      =  %x21 / %x23-24 / %x26-3B / %x3D / %x3F-5B
                   /  %x5D / %x5F / %x61-7A / %x7E / ucschar / iprivate
                   /  pct-encoded
                        ; any Unicode character except: CTL, SP,
                        ;  DQUOTE, "%" (aside from pct-encoded),
                        ;  "<", ">", "\", "^", "`", "{", "|", "}"

Note: using single quotes "'" in literals could limit the interoperability with content like HTML.

Notes:

Discussed with the RFC authors here https://github.com/uri-templates/uritemplate-test/issues/51

RFC 6576, "IP Performance Metrics (IPPM) Standard Advancement Testing", March 2012

Source of RFC: ippm (ops)

Errata ID: 3326
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Al Morton
Date Reported: 2012-08-20
Verifier Name: Wes Eddy
Date Verified: 2012-09-13

Section 3. says:

<none, this is an omission>

It should say:

New Section 3.7  Errata Evaluation

The process of evaluating each metric RFC MUST include an examination of the
current Errata for possible inclusion in the revised text.

Notes:

This omission pointed out by Brian Carpenter

RFC 6582, "The NewReno Modification to TCP's Fast Recovery Algorithm", April 2012

Source of RFC: tcpm (wit)

Errata ID: 6871
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Clive Bloom
Date Reported: 2022-03-07
Verifier Name: Martin Duke
Date Verified: 2024-03-12

Section 4.1 says:

If the Cumulative Acknowledgment field didn’t cover more than
recover, check to see if the congestion window is greater than
SMSS bytes and the difference between highest_ack and
prev_highest_ack is at most 4*SMSS bytes. If true, duplicate
ACKs indicate a lost segment (enter fast retransmit).
Otherwise, duplicate ACKs likely result from unnecessary
retransmissions (do not enter fast retransmit).

It should say:

If the Cumulative Acknowledgment field didn’t cover more than
recover, check to see if the congestion window is greater than
SMSS bytes and the difference between highest_ack and
prev_highest_ack is at most 3*SMSS bytes. If true, duplicate
ACKs indicate a lost segment (enter fast retransmit).
Otherwise, duplicate ACKs likely result from unnecessary
retransmissions (do not enter fast retransmit).

Notes:

RFC6582 (as well as RFC3782) references to Gur03 and GF04 papers as to the initial sources
of the heuristics both ACK-based and Timestamp-based. Neither of those
papers nor Gur03 nor GF04 defines difference between highest_ack and previous_highest_ack
of at least 4*SMSS bytes upon receiving the third duplicate ACK as an indication
of droped retransmitted segment. Instead, section III of GF04 says:

"The acknowledgment heuristic is based on an observation that if the
TCP sender unnecessarily retransmits at least three adjacent packets,
there will be a jump by at least four segments in a cumulative
acknowledgment field. The sender will have correctly retransmitted at least
one packet, to advance the cumulative acknowledgment field, and
unnecessarily retransmitted at least three more to result in three duplicate
acknowledgments. Following the advancement of the cumulative acknowledgment
field, the sender stores the value of the previous cumulative acknowledgment
as prev_highest_ack and stores the latest cumulative acknowledgment as
highest_ack. Upon receiving the third duplicate acknowledgment,
the sender invokes a Fast Retransmit if its congestion window is greater
than one MSS (Maximum Segment Size), and the difference between highest_ack
and prev_highest_ack is at most three MSS."

According to GF04 if TCP sender in absence of any droped acknowledgments upon receiving
the third duplicate ACK has difference between highest_ack and prev_highest ack values
of at most/i.e. no more than 3*SMSS bytes then this is explicite indication of droped retransmitted
segment and leads TCP sender to invoke Fast Retransmit, but current description of ACK-based
heuristic in RFC6582 section 4.1 in part of: "If the Cumulative Acknowledgment field didn’t cover more than recover, check to see if the congestion window is greater than
SMSS bytes and the difference between highest_ack and prev_highest_ack is at most 4*SMSS bytes.
If true, duplicate ACKs indicate a lost segment (enter fast retransmit). Otherwise, duplicate ACKs
likely result from unnecessary retransmissions (do not enter fast retransmit). ", makes TCP sender
to treat difference between highest_ack and prev_highest_ack of 4SMSS bytes upon receiving 3rd
duplicate ACK as indication of lost retransmitted segment but again according to GF04 this is NOT so,
and makes TCP sender to invoke Fast Retransmit when in fact those three duplicate acknowledgments
indicate unnecessarily retransmitted segments and have in their acknowledgment fields sequence
number which receiver expects to receive next but which sender has NOT sent yet, so Fast Retransmit
has no point in this case.

RFC 6588, "A URN Namespace for ucode", April 2012

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 3188
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2012-04-12
Verifier Name: Barry Leiba
Date Verified: 2012-04-13

Section 2, pg.3 says:

   Declaration of syntactic structure:

   The structure of the namespace for 'ucode' using the hexadecimal
   representation of the identifier is as follows using ABNF [RFC5234].

   UCODE-URN = "urn:ucode:" ucode-name
   ucode-name = "_" ucode-number
   ucode-number = 1*ucode-value
   ucode-value = 32HEXDIG
   HEXDIG         =  DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
   DIGIT          =  %x30-39
                  ; 0-9

It should say:

   Declaration of syntactic structure:

   The structure of the namespace for 'ucode' using the hexadecimal
   representation of the identifier is as follows using ABNF [RFC5234].

   UCODE-URN    = "urn:ucode:" ucode-name
   ucode-name   = "_" ucode-number
   ucode-number = 1*ucode-value
|  ucode-value  = 32UCHEXDIG
|  UCHEXDIG     = %x30-39 / 0x41-46   ; digits 0..9, uppercase A..F
|

Notes:

Note: The above clause is part of the 'ucode' URN Namespace
Registration Template, so the above correction needs
to be applied to the template archived at IANA as well.

Rationale: The maintainers of the namespace intended to admit
only uppercase letters in the hexadecimal representation,
in order to accomodate usage of assigned <ucode-value>s in
case-sensitive XML context; this is specified in other parts
of the RFC, but should be specified also in the formal definition.
According to the ABNF Standard, RFC 5234, string literals in ABNF
are explicitly case-insensitive (cf. page 5 of RFC 5234).

Errata ID: 3189
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2012-04-12
Verifier Name: Barry Leiba
Date Verified: 2012-04-13

Section 2, pg.4 says:

   Rules for lexical equivalence:

   The entire UCODE-URN is case-sensitive.

   NOTE: This is an additional restriction imposed on the ucode
   namespace by the requirements of some major applications of ucode in
   existence.  Only capital "A", "B", "C", ..., "F" are allowed as part
   of hexadecimal characters.

It should say:

   Rules for lexical equivalence:

|  The Namespace-Specific String (NSS) in 'ucode' URNs
|  (i.e. the <ucode-name> in the ABNF) is case-sensitive.
|  So this namespace imposes no additional lexical equivalences
|  beyond what is specified in RFC 2141 (i.e., according to
|  RFC 2141, the "urn:ucode:" part is case-insensitive, the NSS
|  is not).

Notes:

Note: The above clause is part of the 'ucode' URN Namespace
Registration Template, so the above correction needs
to be applied to the template archived at IANA as well.

Rationale: The RFC text violates Section 5 of RFC 2141, which
specifies that the case-insensitivity of the URI Scheme ("URN")
and the URN Namespace ID (NID) cannot be overridden by a URN
Namespace registration.
It was the intent of the maintainers of the 'ucode' namespace
to follow RFC 2141, but the language in the RFC has happened
to indicate otherwise.

The correction of the ABNF recorded in Errata Note #3188 makes
the original NOTE superflous, since the corrected ABNF now
precisely specifies what this NOTE intended to superimpose on
the original ABNF in the RFC.

RFC 6603, "Prefix Exclude Option for DHCPv6-based Prefix Delegation", May 2012

Source of RFC: dhc (int)

Errata ID: 4958
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sander Steffann
Date Reported: 2017-03-07
Verifier Name: Suresh Krishnan
Date Verified: 2017-03-08

Section 6.1 says:

6.1.  Requesting Router

   The requesting router behavior regarding the use of the
   OPTION_PD_EXCLUDE option is mostly identical to the steps described
   in Section 5.1, with the difference being the use of a DHCPv6 Request
   instead of an Solicit message.  The requesting router SHOULD include
   the OPTION_PD_EXCLUDE option code in the OPTION_ORO option for DHCPv6
   messages as described in Section 22.7 of [RFC3315].  The requesting
   router SHOULD include the OPTION_PD_EXCLUDE option code in the
   OPTION_ORO option for DHCPv6 messages as described in Section 22.7 of
   [RFC3315].

It should say:

6.1.  Requesting Router

   The requesting router behavior regarding the use of the
   OPTION_PD_EXCLUDE option is mostly identical to the steps described
   in Section 5.1, with the difference being the use of a DHCPv6 Request
   instead of an Solicit message.  The requesting router SHOULD include
   the OPTION_PD_EXCLUDE option code in the OPTION_ORO option for DHCPv6
   messages as described in Section 22.7 of [RFC3315].

Notes:

Minor editorial bug: the last sentence of that paragraph was duplicated.

RFC 6620, "FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses", May 2012

Source of RFC: savi (int)

Errata ID: 3926
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Leaf Yeh
Date Reported: 2014-03-21
Verifier Name: Ted Lemon
Date Verified: 2014-04-05

Section 3.2.3 says:

   +---------+  VP_NS, VP_DATA/2xNS                    +-----------+
   |         |---------------------------------------->|           |
   | NO_BIND |                                         | TENTATIVE |
   |         |<----------------------------------------|           |
   +---------+                    TP_NA, TP_NS/-       +-----------+
          ^                                                |
          |                                                | TimeOut
   Timeout|                                                |
          |                                                v
   +---------+  VP_NA/-                                +-----------+
   |         |---------------------------------------->|           |
   | TESTING |                                TP_NS/-  |           |
   |  TP-LT  |<----------------------------------------|   VALID   |
   |         |                           TimeOut/2xNS  |           |
   |         |<----------------------------------------|           |
   +---------+                                         +-----------+
     ^   |                                                ^    |
     |   |                                                |    |
     |   +---------------------      ---------------------+    |
     |       VP_NS/-          |     |  NP_NA, TimeOut/-        |
     |                        v     |                          |
     |                     +-----------+                       |
     |                     |           |                       |
     +---------------------|  TESTING  |<----------------------+
          VP_NS, VP_DATA/- |    VP     |  VP_DATA, VP_NS,
                           +-----------+  VP_NA/2xNS

                    Figure 2: Simplified State Machine

It should say:

   +---------+  VP_NS, VP_DATA/2xNS                    +-----------+
   |         |---------------------------------------->|           |
   | NO_BIND |                                         | TENTATIVE |
   |         |<----------------------------------------|           |
   +---------+                    TP_NA, TP_NS/-       +-----------+
          ^                                                |
          |                                                | TimeOut
   Timeout|                                                |
          |                                                v
   +---------+  VP_NA/-                                +-----------+
   |         |---------------------------------------->|           |
   | TESTING |                                TP_NS/-  |           |
   |  TP-LT  |<----------------------------------------|   VALID   |
   |         |                           TimeOut/2xNS  |           |
   |         |<----------------------------------------|           |
   +---------+                                         +-----------+
     ^   |                                                ^    |
     |   |                                                |    |
     |   +---------------------      ---------------------+    |
     |       VP_NS/-          |     |  VP_NA, TimeOut/-        |
     |                        v     |                          |
     |                     +-----------+                       |
     |                     |           |                       |
     +---------------------|  TESTING  |<----------------------+
          TP_NS, TP_DATA/- |    VP     |  VP_DATA, VP_NS,
                           +-----------+  VP_NA/2xNS

                    Figure 2: Simplified State Machine

Notes:

a. According to the description on the state machine at page 19,

<quote>
o If an NA message containing the IPAddr as the Target Address is
received through the Validating Port P as a reply to the DAD_NS
message, then the NA is forwarded as usual and the state is
changed to VALID. The LIFETIME is set to DEFAULT_LT.
</quote>

the state change from TESTING_VP to VALID should be triggered by the VP_NA (NA message containing the IPAddr as the Target Address is received through the Validating Port).


b. According to the description on the state machine at page 19,

<quote>
o If a data packet containing IPAddr as the source address is
received through a Trusted Port (i.e., other than port P), the
state is moved to TESTING_TP-LT, and the packet MAY be discarded.

o If a DAD_NS is received through a Trusted Port, the packet is
forwarded as usual, and the state is moved to TESTING_TP-LT.
</quote>

the state change from TESTING_VP to TESTING_TP-LT should be triggered by the TP_DATA (data packet containing IPAddr as the source address received through a Trusted Port), or by the TP_NS (DAD_NS is received through a Trusted Port).

RFC 6621, "Simplified Multicast Forwarding", May 2012

Source of RFC: manet (rtg)

Errata ID: 3499
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Errol Lloyd
Date Reported: 2013-02-26
Verifier Name: Adrian Farrel
Date Verified: 2013-02-28

Section B.4. says:

  1.  Initialize the set "MPR" to empty.

   2.  Initialize the set "N1" to include all 1-hop neighbors of "n0".

   3.  Initialize the set "N2" to include all 2-hop neighbors, excluding
       "n0" and any routers in "N1".  Nodes that are only reachable via
       "N1" routers with router priority values of NEVER are also
       excluded.

   4.  For each interface "y" in "N1", initialize a set "N2(y)" to
       include any interfaces in "N2" that are 1-hop neighbors of "y".

   5.  For each interface "x" in "N1" with a router priority value of
       "ALWAYS" (or using the CF relay algorithm), select "x" as an MPR:

       A.  Add "x" to the set "MPR" and remove "x" from "N1".

       B.  For each interface "z" in "N2(x)", remove "z" from "N2".

       C.  For each interface "y" in "N1", remove any interfaces in
           "N2(x)" from "N2(y)".

   6.  For each interface "z" in "N2", initialize the set "N1(z)" to
       include any interfaces in "N1" that are 1-hop neighbors of "z".

   7.  For each interface "x" in "N2" where "N1(x)" has only one member,
       select "x" as an MPR:

       A.  Add "x" to the set "MPR" and remove "x" from "N1".

       B.  For each interface "z" in "N2(x)", remove "z" from "N2" and
           delete "N1(z)".

       C.  For each interface "y" in "N1", remove any interfaces in
           "N2(x)" from "N2(y)".

   8.  While "N2" is not empty, select the interface "x" in "N1" with
       the largest router priority that has the number of members in
       "N_2(x)" as an MPR:

       A.  Add "x" to the set "MPR" and remove "x" from "N1".

       B.  For each interface "z" in "N2(x)", remove "z" from "N2".

       C.  For each interface "y" in "N1", remove any interfaces in
           "N2(x)" from "N2(y)".

It should say:

  1.  Initialize the set "MPR" to empty.

   2.  Initialize the set "N1" to include all 1-hop neighbors of "n0".

   3.  Initialize the set "N2" to include all 2-hop neighbors, excluding
       "n0" and any routers in "N1".  Nodes that are only reachable via
       "N1" routers with router priority values of NEVER are also
       excluded.

   4.  For each interface "y" in "N1", initialize a set "N2(y)" to
       include any interfaces in "N2" that are 1-hop neighbors of "y".

   5.  For each interface "x" in "N1" with a router priority value of
       "ALWAYS" (or using the CF relay algorithm), select "x" as an MPR:

       A.  Add "x" to the set "MPR" and remove "x" from "N1".

       B.  For each interface "z" in "N2(x)", remove "z" from "N2".

       C.  For each interface "y" in "N1", remove any interfaces in
           "N2(x)" from "N2(y)".

   6.  For each interface "z" in "N2", initialize the set "N1(z)" to
       include any interfaces in "N1" that are 1-hop neighbors of "z".

   7.  For each interface "w" in "N2" where "N1(w)" has only one member, "x",
       select "x" as an MPR:

       A.  Add "x" to the set "MPR" and remove "x" from "N1".

       B.  For each interface "z" in "N2(x)", remove "z" from "N2".

       C.  For each interface "y" in "N1", remove any interfaces in
           "N2(x)" from "N2(y)".

   8.  While "N2" is not empty, select the interface "x" in "N1" with
       the highest router priority [break ties in favor of the node with the 
       largest number of members in "N_2(x)"] as an MPR:

       A.  Add "x" to the set "MPR" and remove "x" from "N1".

       B.  For each interface "z" in "N2(x)", remove "z" from "N2".

       C.  For each interface "y" in "N1", remove any interfaces in
           "N2(x)" from "N2(y)".

Notes:

There are three changes:

On line 7, the first and second occurrences of x are replaced by w, and then x is given as the name of the sole member of N1(w).

On line 7B, the phrase 'delete "N1(z)" is dropped to be consistent with the rest of the algorithm.

On line 8 some rewording is done for clarification.

This errata prepared in consultation with Justin Dean and Gus Macker.

Errata ID: 3640
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Joseph Macker
Date Reported: 2013-06-06
Verifier Name: Adrian Farrel
Date Verified: 2013-06-06

Section A.4 says:

  4.  If "RtrPri(n0)" is greater than that of all tuples in the union
      of "N1" and "N2", then "n0" selects itself as a relay, and no
      further steps are taken.

It should say:

  4.  If "RtrPri(n0)" is greater than that of all tuples in
      "N1", then "n0" selects itself as a relay, and no
      further steps are taken.

Notes:

The initial verbal description of the E-CDS algorithm in first paragraph A.1 pg 40 is correct..as follows

1. If an SMF router has a higher ordinal (Router Priority, Router
ID) than all of its symmetric neighbors, it elects itself to act
as a forwarder for all received multicast packets.

But LATER in A.4 pseudocode Step 4 contains a bug. N2 (2 hop neighbors are included in this step). This pseudocode bug can cause incorrect behavior to occur.

Errata ID: 4098
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Joe Macker
Date Reported: 2014-09-04
Verifier Name: Adrian Farrel
Date Verified: 2014-11-18

Section Appendix B says:

This distributed relay set selection technique has been shown to 
approximate a minimal connected dominating set (MCDS) in [JLMV02].

It should say:

This distributed relay set selection technique has been shown to 
approximate a minimum connected dominating set (MCDS) in [JLMV02].

Notes:

Minimum connected dominating set [1] is the established terminology and
minimal was an editorial error.

[1] Sampathkumar, E.; Walikar, HB (1979),
"The connected domination number of a graph", J. Math. Phys. Sci 13 (6): 607–613.

RFC 6639, "Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-Based Management Overview", June 2012

Source of RFC: mpls (rtg)

Errata ID: 3925
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Liu Lin
Date Reported: 2014-03-21
Verifier Name: Adrian Farrel
Date Verified: 2014-03-21

Section 4.2.9 says:

The pwTDMPerfCurrentTable [RFC5604], pwTDMPerfIntervalTable
[RFC5604], and pwTDMPerf1DayIntervalTable [RFC5604] contain
statistical information accumulated per 15-minute, 24-hour, and 1-day
periods, respectively.

It should say:

The pwTDMPerfCurrentTable [RFC5604], pwTDMPerfIntervalTable
[RFC5604], and pwTDMPerf1DayIntervalTable [RFC5604] contain
statistical information accumulated per 15-minute, 24-hour, and 1-month
periods, respectively.

Notes:

1-day --> 1-month
RFC5604 section 6.1 states:
The TDM Performance Current Table (pwTDMPerfCurrentTable) contains TDM statistics for the current 15-minute period.
The TDM Performance Interval Table (pwTDMPerfIntervalTable) contains TDM statistics for historical intervals (usually 96 15-minute entries to cover a 24 hour period).
The TDM Performance One-Day Interval Table (pwTDMPerf1DayIntervalTable) contains TDM statistics for historical intervals accumulated per day. Usually 30 one-day entries to cover a monthly period.

RFC 6643, "Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG Modules", July 2012

Source of RFC: netmod (ops)

Errata ID: 4786
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin Björklund
Date Reported: 2016-08-24
Verifier Name: Benoit Claise
Date Verified: 2016-08-29

Section 9.1 says:

      If the current object belongs to a conceptual table,
      then a sequence of leaf statements is generated for each INDEX
      object of the conceptual table.  These leafs are named after the
      INDEX objects and of type leafref.

It should say:

      If the current object belongs to a conceptual table,
      then a sequence of leaf statements is generated for each INDEX
      object of the conceptual table, except that a leaf statement is
      not generated for the current object if it is also an INDEX
      object. These leafs are named after the INDEX objects and of type
      leafref.

Notes:

The original text would lead to duplicate leaf nodes if the current object is also part of the INDEX. Section 9.2 contains an example which shows such a situation, without any duplicates.

RFC 6655, "AES-CCM Cipher Suites for Transport Layer Security (TLS)", July 2012

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 3761
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sandeep S. Kumar
Date Reported: 2013-10-22
Verifier Name: Sean Turner
Date Verified: 2014-01-14

Section 3 says:

In DTLS, the 64-bit seq_num is the 16-bit epoch concatenated with the
48-bit seq_num.

It should say:

In DTLS, the 64-bit sequence number is the 16-bit epoch concatenated 
with the 48-bit sequence_number in the order they appear on the wire.

Notes:

In DTLS 1.2 (RFC 6347, Sec 4.3.1.), the 48 bit sequence number is indicated as sequence_number. There is no mention of seq_num in the DTLS RFC.
The additional ordering information is used to keep it consistent with MAC computation in DTLS RFC 6347, Sec 4.1.2.1.)

RFC 6669, "An Overview of the Operations, Administration, and Maintenance (OAM) Toolset for MPLS-Based Transport Networks", July 2012

Source of RFC: mpls (rtg)

Errata ID: 3392
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nurit Sprecher
Date Reported: 2012-10-24
Verifier Name: Adrian Farrel
Date Verified: 2012-11-04

Section 4 says:

  +------------------------+---------------------------------+---------+
  | Lock Instruct (LI)     | (1) G-ACh-based Loopback,       |[RFC6426]|
  |                        | (2) Lock Instruct (LI)          |         |
  +------------------------+---------------------------------+---------+
  | Lock Report (LKR)      | Flag in AIS message             |[RFC6426]|

It should say:

  +------------------------+---------------------------------+---------+
  | Lock Instruct (LI)     | (1) G-ACh-based Loopback,       |[RFC6435]|
  |                        | (2) Lock Instruct (LI)          |         |
  +------------------------+---------------------------------+---------+
  | Lock Report (LKR)      | Flag in MPLS Fault Management   |[RFC6427]|
  |                        | message                         |         |

Notes:

The RFC numbers were correct in version latest draft version (9), and obviously it is an editing mistake.

---

I updated the "Corrected Text" section of this Errata Report after receiving email from the submitter.

RFC 6672, "DNAME Redirection in the DNS", June 2012

Source of RFC: dnsext (int)

Errata ID: 5297
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Pieter Lexis
Date Reported: 2018-03-23
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2018-03-26

Section 5.3.4.1 says:

   ;; Header: QR AA RCODE=3(NXDOMAIN)
   ;; OPT PSEUDOSECTION:
   ; EDNS: version: 0, flags: do; udp: 4096

   ;; Question
   foo.bar.example.com. IN A
   ;; Authority
   bar.example.com. NSEC dub.example.com. A DNAME 
   bar.example.com. RRSIG NSEC [valid signature]

It should say:

   ;; Header: QR AA RCODE=3(NXDOMAIN)
   ;; OPT PSEUDOSECTION:
   ; EDNS: version: 0, flags: do; udp: 4096

   ;; Question
   foo.bar.example.com. IN A
   ;; Authority
   bar.example.com. NSEC dub.example.com. A DNAME RRSIG NSEC
   bar.example.com. RRSIG NSEC [valid signature]

Notes:

The NSEC record in the original text would in no case be valid as it denies it's own existence and the existence of the RRSIG, while the text indicates that " the validator can see that it is a BOGUS reply from an attacker that collated existing records from the DNS to create a confusing reply". This indicates that NSEC and RRSIG should be set in the NSEC bitmap.

Edit: Thread: https://www.ietf.org/mail-archive/web/dnsext/current/msg13879.html

Errata ID: 5298
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Pieter Lexis
Date Reported: 2018-03-02
Verifier Name: Eric Vyncke
Date Verified: 2023-08-03

Section 5.3.4.2 says:

   ;; Header: QR AA RCODE=3(NXDOMAIN)
   ;; OPT PSEUDOSECTION:
   ; EDNS: version: 0, flags: do; udp: 4096

   ;; Question
   cee.example.com. IN A
   ;; Authority
   bar.example.com. NSEC dub.example.com. A DNAME
   bar.example.com. RRSIG NSEC [valid signature]

It should say:

   ;; Header: QR AA RCODE=3(NXDOMAIN)
   ;; OPT PSEUDOSECTION:
   ; EDNS: version: 0, flags: do; udp: 4096

   ;; Question
   cee.example.com. IN A
   ;; Authority
   bar.example.com. NSEC dub.example.com. A DNAME RRSIG NSEC
   bar.example.com. RRSIG NSEC [valid signature]

Notes:

The NSEC record in the original text would in no case be valid as it denies it's own existence and the existence of the RRSIG, while the text indicates that " the validator can see that it is a BOGUS reply from an attacker that collated existing records from the DNS to create a confusing reply". This indicates that NSEC and RRSIG should be set in the NSEC bitmap

Edit: Thread - https://www.ietf.org/mail-archive/web/dnsext/current/msg13879.html

RFC 6679, "Explicit Congestion Notification (ECN) for RTP over UDP", August 2012

Note: This RFC has been updated by RFC 8311

Source of RFC: avtcore (wit)

Errata ID: 3586
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Magnus Westerlund
Date Reported: 2013-04-10
Verifier Name: Gonzalo Camarillo
Date Verified: 2013-04-17

Section 12.1 says:

   The Offer:

...
      a=ecn-capable-rtp: ice rtp ect=0 mode=setread
...

   The Answer:
...
      a=ecn-capable-rtp: ice ect=0 mode=readonly
...

It should say:

   The Offer:

...
      a=ecn-capable-rtp: ice,rtp ect=0; mode=setread
...

   The Answer:
...
      a=ecn-capable-rtp: ice ect=0; mode=readonly
...

Notes:

The examples does not match the ABNF rules for the a=ecn-capaable-rtp attribute. Two issues are present, first the init method list must be comma separated with no spaces, secondly any additional parameters shall be semi colon plus space separated. Therefore both a=ecn-capable-rtp lines have been corrected.

This is primarily an editorial issues but people needs to aware of the errors in the example.

RFC 6687, "Performance Evaluation of the Routing Protocol for Low-Power and Lossy Networks (RPL)", October 2012

Source of RFC: INDEPENDENT

Errata ID: 4842
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yasuyuki Tanaka
Date Reported: 2016-10-25
Verifier Name: Nevil Brownlee
Date Verified: 2017-07-20

Section 3 says:

RPL makes use of trickle timers: the protocol sets a minimum time
period with which the nodes start re-issuing DAOs, and this
minimum period is denoted by the trickle parameter Imin.

It should say:

RPL makes use of trickle timers: the protocol sets a minimum time
period with which the nodes start re-issuing DIOs, and this
minimum period is denoted by the trickle parameter Imin.

Notes:

"DAOs" in this sentence seems a typo; it should be "DIOs".

RFC 6704, "Forcerenew Nonce Authentication", August 2012

Source of RFC: dhc (int)

Errata ID: 4995
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Niels Widger
Date Reported: 2017-04-14
Verifier Name: Suresh Krishnan
Date Verified: 2017-04-19

Section 4 says:

   IANA has assigned the following new DHCPv4 option code from the
   registry "BOOTP Vendor Extensions and DHCP Options" maintained at
   http://www.iana.org/assignments/bootp-dhcp-parameters:

   Tag: 145

   Name: FORCERENEW_NONCE_CAPABLE

   Data length: 1

   Description: Forcerenew Nonce Capable

   Reference: this document

It should say:

   IANA has assigned the following new DHCPv4 option code from the
   registry "BOOTP Vendor Extensions and DHCP Options" maintained at
   http://www.iana.org/assignments/bootp-dhcp-parameters:

   Tag: 145

   Name: FORCERENEW_NONCE_CAPABLE

   Data length: n

   Description: Forcerenew Nonce Capable

   Reference: this document

Notes:

RFC 6704 Section 3.1.1 states that the FORCERENEW_NONCE_CAPABLE option is variable length and contains a list of algorithm types:

The FORCERENEW_NONCE_CAPABLE option contains code 145, length n, and
a sequence of algorithms the client supports:

Code Len Algorithms
+-----+-----+----+----+----+
| 145 | n | A1 | A2 | A3 | ....
+-----+-----+----+----+----+

Figure 1: FORCERENEW_NONCE_CAPABLE Option


Verifier's note(Suresh Krishnan - INT AD): This erratum is correct and it requires a change in the IANA registry. I authorize IANA to make this change.

RFC 6715, "vCard Format Extensions: Representing vCard Extensions Defined by the Open Mobile Alliance (OMA) Converged Address Book (CAB) Group", August 2012

Source of RFC: vcarddav (app)

Errata ID: 3342
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Angstadt
Date Reported: 2012-09-08
Verifier Name: Barry Leiba
Date Verified: 2012-09-08

Section 3.1 says:

Description:

When a property is multi-valued, INDEX can be used to indicate an ordering or sequence of the values.  INDEX values must be strictly positive.  Zero is not allowed.

It should say:

Description:

When a property is multi-valued, INDEX can be used to indicate an ordering or sequence of the values.  INDEX values must be strictly positive.  Zero is not allowed.

If an instance of a multi-valued property does not have an INDEX value, then it is included at the end of the ordered sequence, as if it had a very high INDEX value. 

Notes:

It is not clear how a list of properties should be sorted if some of them have INDEX parameters and others do not.  This errata submission proposes that properties without an INDEX parameter be pushed to the end of the sorted list, as if they had a very high INDEX value.

For example, the ordering of the following properties is very clear, since they all have INDEX parameters:

INTEREST;INDEX=3:art
INTEREST;INDEX=2:baseball
INTEREST;INDEX=4:music
INTEREST;INDEX=1:hockey

The above example would be sorted as follows:

INTEREST;INDEX=1:hockey
INTEREST;INDEX=2:baseball
INTEREST;INDEX=3:art
INTEREST;INDEX=4:music

However, the spec does not provide guidance on how to sort a list of properties if some properties have INDEX parameters and others do not.  This errata submission suggests that the properties missing the INDEX parameter be pushed to the end of the sorted list.  For example:

Unsorted:

INTEREST:art
INTEREST;INDEX=2:baseball
INTEREST:music
INTEREST;INDEX=1:hockey

Sorted:

INTEREST;INDEX=1:hockey
INTEREST;INDEX=2:baseball
INTEREST:art
INTEREST:music

...OR...

INTEREST;INDEX=1:hockey
INTEREST;INDEX=2:baseball
INTEREST:music
INTEREST:art

Verifier note:
Something like this was meant to be in the document, but was left out.

Errata ID: 3340
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Angstadt
Date Reported: 2012-09-08
Verifier Name: Barry Leiba
Date Verified: 2012-09-08

Section 3.1 says:

Examples:
ORG-URI;INDEX=1:http://mycompany.example1.com
ORG-URI;PREF=1;INDEX=2:http://mycompany.example2.com

It should say:

Examples:
ORG-DIRECTORY;INDEX=1:http://mycompany.example1.com
ORG-DIRECTORY;PREF=1;INDEX=2:http://mycompany.example2.com

Notes:

In the examples, the ORG-DIRECTORY property is incorrectly referred to as ORG-URI.

Errata ID: 3341
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Angstadt
Date Reported: 2012-09-08
Verifier Name: Barry Leiba
Date Verified: 2012-09-08

Section 5 says:

     +-------+------------------------+------------------------+
     | Name- |                        |                        |
     | space | Property               | Reference              |
     +-------+------------------------+------------------------+
     |       | EXPERTISE              | RFC 6715, Section 2.1  |
     |       | HOBBY                  | RFC 6715, Section 2.2  |
     |       | INTEREST               | RFC 6715, Section 2.3  |
     |       | ORG-URI                | RFC 6715, Section 2.4  |
     +-------+------------------------+------------------------+

It should say:

     +-------+------------------------+------------------------+
     | Name- |                        |                        |
     | space | Property               | Reference              |
     +-------+------------------------+------------------------+
     |       | EXPERTISE              | RFC 6715, Section 2.1  |
     |       | HOBBY                  | RFC 6715, Section 2.2  |
     |       | INTEREST               | RFC 6715, Section 2.3  |
     |       | ORG-DIRECTORY          | RFC 6715, Section 2.4  |
     +-------+------------------------+------------------------+

Notes:

The ORG-DIRECTORY property is incorrectly referred to as ORG-URI.

RFC 6716, "Definition of the Opus Audio Codec", September 2012

Note: This RFC has been updated by RFC 8251

Source of RFC: codec (rai)

Errata ID: 4853
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Rostislav Pehlivanov
Date Reported: 2016-11-02
Verifier Name: Ben Campbell
Date Verified: 2016-11-02

Section 5.1.1 says:

                                    rng
                        rng = rng - --- * (fh - fl)
                                    ft

It should say:

                                    rng
                        rng = rng - --- * (ft - fh)
                                    ft

Notes:

Equation should match with the one in the range decoder (section 4.1.2), however comparing the two and the reference implementation reveals the equation in section 5.1.1 to be incorrect.

RFC 6719, "The Minimum Rank with Hysteresis Objective Function", September 2012

Source of RFC: roll (rtg)

Errata ID: 7773
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Dominique Barthel
Date Reported: 2024-01-22
Verifier Name: John Scudder
Date Verified: 2024-02-07

Section 2.2 says:

If the cost 
of the path through the preferred parent and the worst parent is too 
large, a node MAY keep a smaller parent set than PARENT_SET_SIZE.

It should say:

If the difference in cost of the paths through the preferred parent 
and the worst parent is too large, a node MAY keep a smaller parent 
set than PARENT_SET_SIZE.

Notes:

This sentence is meant to explain that there is no benefit in keeping in the parent set neighbors that have too high a path cost compared to that of the preferred parent.
The original text omits the notion of difference in cost. It also contains a circular reference: indeed, the worst parent is the neighbor within the parent set that has the highest cost.

Verifier's note: the submitter also included this option:

```
or better yet

"A node MAY keep a parent set smaller than PARENT_SET_SIZE, so that
the difference in cost of the paths through the preferred parent and
the worst parent is not too large."
```

I agree this is a clearer way to express the concept and I think it should be considered if there's ever a bis prepared of the spec, however, I elected to verify the first option given because it represents the minimal change needed to make the document correct.

Errata ID: 7772
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dominique Barthel
Date Reported: 2024-01-22
Verifier Name: RFC Editor
Date Verified: 2024-01-22

Section 3.3 says:

to covert

It should say:

to convert

Notes:

describing the conversion of path cost into a rank value.

RFC 6724, "Default Address Selection for Internet Protocol Version 6 (IPv6)", September 2012

Source of RFC: 6man (int)

Errata ID: 3343
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Stephane Bortzmeyer
Date Reported: 2012-09-12
Verifier Name: Brian Haberman
Date Verified: 2012-09-12

Section 10.1 says:

Destination: 2001:db8:1::1
Candidate Source Addresses: 2001:db8:3::1 or fe80::1
Result: 2001:db8::1 (prefer appropriate scope)

It should say:

Destination: 2001:db8:1::1
Candidate Source Addresses: 2001:db8:3::1 or fe80::1
Result: 2001:db8:3::1 (prefer appropriate scope)

Notes:

2001:db8::1 is not even in the candidate set.

Errata ID: 3344
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stephane Bortzmeyer
Date Reported: 2012-09-12
Verifier Name: Brian Haberman
Date Verified: 2012-09-12

Section 10.1 says:

   Destination: 2001:db8:1::1
   Candidate Source Addresses: 2001:db8:1::2 or 2001:db8:3::2
   Result: 2001:db8:1:::2 (longest matching prefix)

It should say:

   Destination: 2001:db8:1::1
   Candidate Source Addresses: 2001:db8:1::2 or 2001:db8:3::2
   Result: 2001:db8:1::2 (longest matching prefix)

Notes:

Invalid IPv6 syntax

RFC 6728, "Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols", October 2012

Source of RFC: ipfix (ops)

Errata ID: 4843
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michal Vasko
Date Reported: 2016-10-26
Verifier Name: Benoit Claise
Date Verified: 2016-10-26

Section 6 says:

          leaf isFlowKey {
            when "(name(../../..) != 'immediateCache')
...
      leaf activeTimeout {
        when "(name(..) = 'timeoutCache') or
          (name(..) = 'naturalCache')" {
...
      leaf idleTimeout {
        when "(name(..) = 'timeoutCache') or
          (name(..) = 'naturalCache')" {
...
      leaf exportInterval {
        when "name(..) = 'permanentCache'" {

It should say:

          leaf isFlowKey {
            when "(local-name(../../..) != 'immediateCache')
...
      leaf activeTimeout {
        when "(local-name(..) = 'timeoutCache') or
          (local-name(..) = 'naturalCache')" {
...
      leaf idleTimeout {
        when "(local-name(..) = 'timeoutCache') or
          (local-name(..) = 'naturalCache')" {
...
      leaf exportInterval {
        when "local-name(..) = 'permanentCache'" {

Notes:

The XPath function name() returns fully-qualified name (with namespace), but the comparisons are done on simple node names, which are returned by the local-name() XPath function.

Errata ID: 4909
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Pavol Vican
Date Reported: 2017-01-16
Verifier Name: Benoit Claise
Date Verified: 2017-01-18

Section 6 says:

  pattern "\S+";

...

  pattern "\S(.*\S)?";

It should say:

  pattern '\S+';

...

  pattern '\S(.*\S)?';

Notes:

RFC 7950 in section 6.1.3 says that backslash has special meaning if it is in the double-quoted string. The only characters immediately following the backslash are n, t, \, ". Other characters are forbidden. This can be solved using single-quoted string or double backslash.

Errata ID: 4370
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Duggan
Date Reported: 2015-05-21
Verifier Name: Benoit Claise
Date Verified: 2015-05-21

Section 4.8 says:

   isFlowKey:  If this state parameter is present, this is a Flow Key
      field.
      This parameter is only available for non-Options Templates (i.e.,
      if setId is 2).

   isFlowKey:  If this state parameter is present, this is a scope
      field.
      This parameter is only available for Options Templates (i.e., if
      setId is 3).

It should say:

   isFlowKey:  If this state parameter is present, this is a Flow Key
      field.
      This parameter is only available for non-Options Templates (i.e.,
      if setId is 2).

   isScope:    If this state parameter is present, this is a scope
      field.
      This parameter is only available for Options Templates (i.e., if
      setId is 3).

RFC 6733, "Diameter Base Protocol", October 2012

Note: This RFC has been updated by RFC 7075, RFC 8553

Source of RFC: dime (ops)

Errata ID: 3805
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Lionel
Date Reported: 2013-11-18
Verifier Name: Benoit Claise
Date Verified: 2013-12-09

Section 3 says:

    Message Length

      The Message Length field is three octets and indicates the length
      of the Diameter message including the header fields and the padded
      AVPs.  Thus, the Message Length field is always a multiple of 4.

It should say:

    Message Length

      The Message Length field is three octets and indicates the number
      of octets of the Diameter message, including the header fields and
      the padded AVPs.  Thus, the Message Length field is always a 
      multiple of 4 octets.

Notes:

the actual text does not indicate the unit of length unit, which may lead to confusion and IOT issues, especially if someone considers bits instead of bytes.

Errata ID: 3806
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Lionel
Date Reported: 2013-11-18
Verifier Name: Benoit Claise
Date Verified: 2013-11-19

Section 2.7 says:

   Server Identifier

      The identity of one or more servers to which the message is to be
      routed.  This identity MUST also be present in the Host Identity
      field of the peer table (Section 2.6).  When the Local Action is
      set to RELAY or PROXY, this field contains the identity of the
      server(s) to which the message MUST be routed.  When the Local
      Action field is set to REDIRECT, this field contains the identity
      of one or more servers to which the message MUST be redirected.

It should say:

   Peer Identifier

      The identity of one or more peers to which the message is to be
      routed.  This identity MUST also be present in the Host Identity
      field of the peer table (Section 2.6).  When the Local Action is
      set to RELAY or PROXY, this field contains the identity of the
      peer(s) to which the message MUST be routed.  When the Local
      Action field is set to REDIRECT, this field contains the identity
      of one or more peers to which the message MUST be redirected.

Notes:

The host identified in a Routing Table entry is not necessarily a "server". It can also be a Relay, a redirect or a proxy agent. Using "peer" instead of "server" is more appropriate.

Errata ID: 3942
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Benoit Claise
Date Reported: 2014-04-01
Verifier Name: Benoit Claise
Date Verified: 2014-04-01

Section 8 says:

   When a Diameter server authorizes a user to implement network
   resources for a finite amount of time, and it is willing to extend
   the authorization via a future request, it MUST add the
   Authorization- Lifetime AVP to the answer message.

It should say:

   When a Diameter server authorizes a user to implement network
   resources for a finite amount of time, and it is willing to extend
   the authorization via a future request, it MUST add the
   Authorization-Lifetime AVP to the answer message.

Notes:

Authorization-Lifetime was mispelled

Errata ID: 3997
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jouni Korhonen
Date Reported: 2014-05-24
Verifier Name: Benoit Claise
Date Verified: 2014-06-04

Throughout the document, when it says:

Section 2.1.

   The base Diameter protocol is run on port 3868 for both TCP [RFC0793]
   and SCTP [RFC4960].  For TLS [RFC5246] and Datagram Transport Layer
   Security (DTLS) [RFC6347], a Diameter node that initiates a
   connection prior to any message exchanges MUST run on port 5658.  It
   is assumed that TLS is run on top of TCP when it is used, and DTLS is
   run on top of SCTP when it is used.

   If the Diameter peer does not support receiving TLS/TCP and DTLS/SCTP
   connections on port 5658 (i.e., the peer complies only with RFC
   3588), then the initiator MAY revert to using TCP or SCTP on port
   3868.  Note that this scheme is kept only for the purpose of backward
   compatibility and that there are inherent security vulnerabilities
   when the initial CER/CEA messages are sent unprotected (see
   Section 5.6).

   Diameter clients MUST support either TCP or SCTP; agents and servers
   SHOULD support both.

   A Diameter node MAY initiate connections from a source port other
   than the one that it declares it accepts incoming connections on, and
   it MUST always be prepared to receive connections on port 3868 for
   TCP or SCTP and port 5658 for TLS/TCP and DTLS/SCTP connections.
   When DNS-based peer discovery (Section 5.2) is used, the port numbers
   received from SRV records take precedence over the default ports
   (3868 and 5658).

Section 4.3.1.

      port               = ":" 1*DIGIT

                      ; One of the ports used to listen for
                      ; incoming connections.
                      ; If absent, the default Diameter port
                      ; (3868) is assumed if no transport
                      ; security is used and port 5658 when
                      ; transport security (TLS/TCP and DTLS/SCTP)
                      ; is used.

It should say:

Section 2.1.

   The base Diameter protocol is run on port 3868 for both TCP [RFC0793]
   and SCTP [RFC4960].  For TLS [RFC5246] and Datagram Transport Layer
   Security (DTLS) [RFC6347], a Diameter node that initiates a
   connection prior to any message exchanges MUST run on port 5868.  It
   is assumed that TLS is run on top of TCP when it is used, and DTLS is
   run on top of SCTP when it is used.

   If the Diameter peer does not support receiving TLS/TCP and DTLS/SCTP
   connections on port 5868 (i.e., the peer complies only with RFC
   3588), then the initiator MAY revert to using TCP or SCTP on port
   3868.  Note that this scheme is kept only for the purpose of backward
   compatibility and that there are inherent security vulnerabilities
   when the initial CER/CEA messages are sent unprotected (see
   Section 5.6).

   Diameter clients MUST support either TCP or SCTP; agents and servers
   SHOULD support both.

   A Diameter node MAY initiate connections from a source port other
   than the one that it declares it accepts incoming connections on, and
   it MUST always be prepared to receive connections on port 3868 for
   TCP or SCTP and port 5868 for TLS/TCP and DTLS/SCTP connections.
   When DNS-based peer discovery (Section 5.2) is used, the port numbers
   received from SRV records take precedence over the default ports
   (3868 and 5868).

Section 4.3.1.

      port               = ":" 1*DIGIT

                      ; One of the ports used to listen for
                      ; incoming connections.
                      ; If absent, the default Diameter port
                      ; (3868) is assumed if no transport
                      ; security is used and port 5868 when
                      ; transport security (TLS/TCP and DTLS/SCTP)
                      ; is used.

Notes:

RFC 6733 defined the Diameter port number for secure transport in IANA considerations Section 11.4. to be 5868. This is also in IANA port numbers registry "Service Name and Transport Protocol Port Number Registry". However, the RFC 6733 body text uses different port number in Sections 2.1. and 4.3.1. for secure transports. Since the IANA registry already contains the port number 5868 instead of the body text used value 5658, the values in Sections 2.1. and 4.3.1. should be 5868 instead of 5658.

Errata ID: 4615
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Lionel Morand
Date Reported: 2016-02-05
Verifier Name: Benoit Claise
Date Verified: 2016-05-17

Section 7.1.5 says:

   DIAMETER_AVP_UNSUPPORTED 5001

      The peer received a message that contained an AVP that is not
      recognized or supported and was marked with the 'M' (Mandatory)
      bit.  A Diameter message with this error MUST contain one or more
      Failed-AVP AVPs containing the AVPs that caused the failure.

It should say:

   DIAMETER_AVP_UNSUPPORTED 5001

      The peer received a message that contained an AVP that is not
      recognized or supported and was marked with the 'M' (Mandatory)
      bit.  A Diameter message with this error MUST contain one 
      Failed-AVP AVP containing the AVPs that caused the failure.

Notes:

The RFC6733 has clarified that only one instance of Failed-AVP AVP can be present in the command answer. One Failed-AVP AVP is enough because this AVP is defined as Grouped AVP that can contain multiple AVPs. In the present case, each of the nested AVPs in the Failed-AVP AVP are the AVPs that caused the failure.

Errata ID: 4808
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Zbigniew Rapnicki
Date Reported: 2016-09-22
Verifier Name: Benoit Claise
Date Verified: 2017-01-04

Section 1.1.3 says:

This document obsoletes RFC 3588 but is fully backward compatible
   with that document.

It should say:

This document obsoletes RFC 3588.

Notes:

When comparing the BNF for the answer messages CEA, DPA, DWA, RAA, STA and ASA it can be seen that FAILED-AVP avp is no longer marked with the * which means it can be present only once in the diameter message.
Previous specification (rfc3588) defines multiple FAILED-AVP avp usage in a single diameter message.
Similar case is for Vendor-Specific-Application-Id AVP definition.
Previous specification allows multiple usage of Vendor-Id avp in a single message while the new specification defines it as a single mandatory AVP:
rfc3588:
<Vendor-Specific-Application-Id> ::= < AVP Header: 260 >
1* [ Vendor-Id ]
0*1{ Auth-Application-Id }
0*1{ Acct-Application-Id }

rfc6733:
<Vendor-Specific-Application-Id> ::= < AVP Header: 260 >
{ Vendor-Id }
[ Auth-Application-Id ]
[ Acct-Application-Id ]

How this facts applies to the sentence about fully backward compatibility in the section 1.1.3?

Errata ID: 4887
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mikhail Zaytsev
Date Reported: 2016-12-13
Verifier Name: Benoit Claise
Date Verified: 2017-01-03

Section 6.2 says:

 When a request is locally processed, the following procedures MUST be
   applied to create the associated answer, in addition to any
   additional procedures that MAY be discussed in the Diameter
   application defining the command:

   o  The same Hop-by-Hop Identifier in the request is used in the
      answer.

   o  The local host's identity is encoded in the Origin-Host AVP.

   o  The Destination-Host and Destination-Realm AVPs MUST NOT be
      present in the answer message.

It should say:

 When a request is locally processed, the following procedures MUST be
   applied to create the associated answer, in addition to any
   additional procedures that MAY be discussed in the Diameter
   application defining the command:

   o  The same Hop-by-Hop Identifier in the request is used in the
      answer.

   o  The local host's identity is encoded in the Origin-Host AVP.

   o  The local realm's identity is encoded in the Origin-Realm AVP.

   o  The Destination-Host and Destination-Realm AVPs MUST NOT be
      present in the answer message.

Notes:

Unlike Origin-Host AVP, it is not stated explicitly that Origin-Realm AVP MUST be encoded in the associated answer. While both these AVPs MUST be present in all Diameter messages according to their descriptions.

Errata ID: 4803
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Holger Freyther
Date Reported: 2016-09-13
Verifier Name: Benoit Claise
Date Verified: 2017-07-27

Section 3.2 says:

In section 3.2

      header           = "<Diameter-Header:" command-id

                         [r-bit] [p-bit] [e-bit] [application-id]">"


In section 3.4

         header           = "<" "AVP-Header:" avpcode [vendor] ">"

It should say:

In section 3.2

      header           = "<Diameter Header:" command-id

                         [r-bit] [p-bit] [e-bit] [application-id]">"

In section 3.4

         header           = "<" "AVP Header:" avpcode [vendor] ">"

Notes:

Background:
There was an initial errata (kept for background information at the bottom of this note). After some discussion with the dime WG, this errata was modified.

This errata report is correct on the inconsistency regarding the definition of the command header and AVP header and how they are used in the rest of the document in the ABNF description of commands and Grouped AVPs.



For commands, the header is defined as follow:



header = "<Diameter-Header:" command-id

[r-bit] [p-bit] [e-bit] [application-id]">"



whereas "<Diameter Header:" is used when defining commands.



Same for Grouped AVP. It is defined as follow:



header = "<" "AVP-Header:" avpcode [vendor] ">"



whereas "<AVP Header:" is used when defining Grouped AVPs.



Considering that most (if not all) the ABNF descriptions have been copied from the commands and Grouped AVPs defined in the RFC3588 or RFC6733, I would be in favor to correct the specification by modifying the definition of the headers, i.e.



--> In section 3.2. Command Code Format Specification



OLD:



header = "<Diameter-Header:" command-id

[r-bit] [p-bit] [e-bit] [application-id]">"



NEW:



header = "<Diameter Header:" command-id

[r-bit] [p-bit] [e-bit] [application-id]">"





--> And in section 4.4



OLD:



header = "<" "AVP-Header:" avpcode [vendor] ">"



NEW:



header = "<" "AVP Header:" avpcode [vendor] ">"

=============================================================================

This initial errata is below:
Original text:
Example-Request ::= < Diameter Header: 9999999, REQ, PXY >
{ User-Name }
1* { Origin-Host }
* [ AVP ]

Corrected text:
<Example-Request> ::= < Diameter-Header: 9999999, REQ, PXY >
{ User-Name }
1* { Origin-Host }
* [ AVP ]

I converted the BNF into a PetitParser parser in Smalltalk/Pharo and noticed that example and grammar do not match. The first issue is with the example following the grammar but most definitions do not follow the BNF so maybe it is best to update the BNF.

header = "<Diameter-Header:" command-id
[r-bit] [p-bit] [e-bit] [application-id]">"

But "Diameter-Header:" is not used throughout the text so maybe it is better to update the grammar to "Diameter Header:".


command-def = "<" command-name ">" "::=" diameter-message

but the example is not using <> for the command-name ("Example-Request"). For the grouped-avp-def application is sometimes used with "<" name ">" and sometimes just name.

RFC 6739, "Synchronizing Service Boundaries and <mapping> Elements Based on the Location-to-Service Translation (LoST) Protocol", October 2012

Note: This RFC has been updated by RFC 8996

Source of RFC: ecrit (rai)

Errata ID: 3393
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Pearl Liang
Date Reported: 2012-10-25
Verifier Name: Robert Sparks
Date Verified: 2012-10-26

Section 10.3 says:

   <p>See <a href="[URL of published RFC]">RFC 6739
          </a>.</p>

It should say:

   <p>See <a href="http://www.rfc-editor.org/rfc/rfc6739.txt">RFC 6739
          </a>.</p>

Notes:

RFC Editor should have updated this text before publication.

RFC 6740, "Identifier-Locator Network Protocol (ILNP) Architectural Description", November 2012

Source of RFC: IRTF

Errata ID: 3959
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Andrew Yourtchenko
Date Reported: 2014-04-11
Verifier Name: Lars Eggert
Date Verified: 2015-06-03

Section 2.3 says:

   Instead, network-layer ILNP sessions have 4 components:

   - Source Locator(s) (L_S)
   - Source Identifier(s) (I_S)
   - Destination Locator(s) (L_D)
   - Destination Identifier(s) (L_S)

   and a tuple for an ILNP session would be:

      <ILNP: I_S, L_S, I_D, L_D>

   The phrase "ILNP session" refers to an ILNP-based network-layer
   session, having the 4 components in the definition above.

It should say:

   Instead, network-layer ILNP sessions have 4 components:

   - Source Locator(s) (L_S)
   - Source Identifier(s) (I_S)
   - Destination Locator(s) (L_D)
   - Destination Identifier(s) (I_D)

   and a tuple for an ILNP session would be:

      <ILNP: I_S, L_S, I_D, L_D>

   The phrase "ILNP session" refers to an ILNP-based network-layer
   session, having the 4 components in the definition above.

Notes:

The "L_S" for destination identifier looks like a simple typo.

RFC 6742, "DNS Resource Records for the Identifier-Locator Network Protocol (ILNP)", November 2012

Source of RFC: IRTF

Errata ID: 3413
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Miek Gieben
Date Reported: 2012-11-18
Verifier Name: Lars Eggert
Date Verified: 2012-12-10

Section 2.2.3. says:

host1.example.com. IN L32 10 10.1.02.0
host1.example.com. IN L32 20 10.1.04.0
host2.example.com. IN L32 10 10.1.08.0

It should say:

host1.example.com. IN L32 10 10.1.2.0
host1.example.com. IN L32 20 10.1.4.0
host2.example.com. IN L32 10 10.1.8.0

Notes:

"As L32 values have the same syntax and semantics as IPv4 routing
prefixes, when displayed for human readership, the values are
presented in the same dotted-decimal format as IPv4 addresses. An
example of this syntax is shown above."

If this is the case I don't get the prefixed 0. Is it octal? Which clashes with the description, or is there some hidden meaning for using an extra 0.
The other example in 2.2.3 also uses these ip4 addresses.

----
From the authors:
----
It was not the intention of the authors to include the
additional zero prefix in the third byte of the IP address.

Although the published text was not identical to the authors'
intent, we believe that the numerical values presented in the
examples are still correct. However, the use of the zero in
this way is not conventional.

It is worth nothing that RFC-990, page 5, for example,
explicitly says the IP address of the string "010.003.000.052"
is equal to the IP address of the string "10.3.0.52". The BNF
and specifications of RFC-1034 and RFC-1035 does not contradict
that, as far as we can tell.

We do note that inet_aton(3)/inet_ntoa(3) (and associated API)
of the C programming language *does* use a leading zero to flag
an octal number. This is also likely to be true for some other
languages, e.g. python's inet_aton() API. However, this use of
a leading zero to indicate octal is not always true. For example,
the Java language InetAddress object API ignores the leading zero
and treats the number as decimal.

So, at the very least, the example in its present form could cause
confusion, while the suggested correction would leave the example
as being clear and unambiguous.

The authors are grateful to Miek Gieben for spotting the ambiguity
and suggesting a correction.

RFC 6743, "ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)", November 2012

Source of RFC: IRTF

Errata ID: 5911
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Rick Payne
Date Reported: 2019-11-16
Verifier Name: Colin Perkins
Date Verified: 2022-12-27

Section 2.1 says:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Num of Locs  |    RESERVED   |           RESERVED            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Num of Locs  |   Operation   |           RESERVED            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

In RFC 6743, Section 2.1, page 7, in the packet diagram, the first field marked "RESERVED" should be marked "Operation", as it is in the introduction for Section 2.  This was a typographical error. The definition of the "Operation" field and the packet format in RFC 6743, Section 2, on pages 5 through 6 are correct and complete.

(The original errata suggested to change the packet header diagram in Section 2 to change the Operation field to RESERVED. After consulting with the authors, the correct fix is to correct the example in Section 2.1)

RFC 6749, "The OAuth 2.0 Authorization Framework", October 2012

Note: This RFC has been updated by RFC 8252, RFC 8996

Source of RFC: oauth (sec)

Errata ID: 3446
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nov Matake
Date Reported: 2013-01-07
Verifier Name: Stephen Farrell
Date Verified: 2013-03-16

Section 1 says:

o  Resource owners cannot revoke access to an individual third party
   without revoking access to all third parties, and must do so by
   changing the third party's password.

It should say:

o  Resource owners cannot revoke access to an individual third party
   without revoking access to all third parties, and must do so by
   changing their password.

Notes:

The text was originally "their" but changed to "the third party's" between the last draft and RFC.
However, "their" means "resource owners'", not "the third party's".

Errata ID: 3500
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Field
Date Reported: 2013-02-26
Verifier Name: Stephen Farrell
Date Verified: 2013-03-16

Section 4.1 says:

(E)  The authorization server authenticates the client, validates the
     authorization code, and ensures that the redirection URI
     received matches the URI used to redirect the client in
     step (C).  If valid, the authorization server responds back with
     an access token and, optionally, a refresh token.

It should say:

(E)  The authorization server authenticates the client, validates the
     authorization code, and ensures that the redirection URI
     received matches the URI used to redirect (the resource owner's user-agent) 
     to the client in step (C).  If valid, the authorization server 
     responds back with an access token and, optionally, a refresh token.

Notes:

The URI in question is the URI that was used to redirect the resource owner's user-agent back to the client to deliver the code. The original text in step (E) seems to say that this URI was used to redirect the client, but I think this is an ambiguous/imprecise use of the word "client." It was not the OAuth client that was redirected using that URI, it was the resource owner's user-agent that was redirected, *to* the client.

The parenthetical (the resource owner's user-agent) is more precise but may perhaps be too verbose. I think, at minimum, we must say "....the URI used to redirect *to* the client in step (C)."

Errata ID: 3904
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Takahiko Kawasaki
Date Reported: 2014-03-01
Verifier Name: Kathleen Moriarty
Date Verified: 2015-12-08

Section 11.2.2. says:

It should say:

   o  Parameter name: error
   o  Parameter usage location: authorization response, token response
   o  Change controller: IETF
   o  Specification document(s): RFC 6749

Notes:

"error" is missing and should be added to the list of Initial Registry Contents of OAuth Parameters Registry.

AD note: This is in the normative registry, although it doesn't appear in the final published RFC. The WG suspects there was a mistake that removed it from RFC 6749 prior to final publication. I've marked this as editorial since the IANA registry is normative, but also as verified.

Errata ID: 5708
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Brian Campbell
Date Reported: 2019-04-29
Verifier Name: Roman Danyliw
Date Verified: 2024-01-17

Section 3.1 and 3.2 says:

Parameters sent without a value MUST be treated as if they were
omitted from the request.  The authorization server MUST ignore
unrecognized request parameters.  Request and response parameters
MUST NOT be included more than once.

It should say:

Parameters sent without a value MUST be treated as if they were
omitted from the request.  The authorization server MUST ignore
unrecognized request parameters.  Request and response parameters
defined by this specification MUST NOT be included more than once.

Notes:

Adds the text "defined by this specification" to the last sentence to clarify that the restriction only applies to parameters defined in RFC 6749 and not to unrecognized parameters or parameters defined by extension.

Errata ID: 6613
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Daniel Barclay
Date Reported: 2021-06-17
Verifier Name: Benjamin Kaduk
Date Verified: 2021-07-18

Section 3.3 says:

The value of the scope parameter is expressed as a list of space-delimited, case-sensitive strings

It should say:

The value of the scope parameter is expressed as a space-delimited list of case-sensitive strings

Notes:

The original/current seems to be a bit confusing.

The value is not a collection of space-delimited strings (whatever a "space-delimited string" would be), but it a space-delimited (representation of) a collection of strings.

RFC 6751, "Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises Equipment (6a44)", October 2012

Source of RFC: INDEPENDENT

Errata ID: 3384
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Andreas Cudok
Date Reported: 2012-10-18
Verifier Name: Nevil Brownlee
Date Verified: 2014-01-20

Section 6.5.3 says:

CR-2 IPv6/IPv4 PACKET FROM A HOST OF THE SAME SITE
 
    <figure omitted>

If ALL the following conditions are satisfied (i.e., the packet comes
from a 6a44 client of the same site), the 6a44 client MUST
decapsulate the inner packet and treat it as a received IPv6 packet:
(1) the IPv4 packet contains a complete UDP datagram (protocol = 17,
offset = 0, more-fragment bit = 0); (2) both ports of the UDP
datagram are the 6a44 port, and the UDP payload is an IPv6 packet
(UDP length of at least 40 octets, version = 6); (3) the IPv6 source
address is one of the same site (the first 80 bits match those of the
6a44-client IPv6 address; (4) its last 32 bits are equal to the IPv4
source address; (5) the IPv6 destination address is the 6a44-client
IPv6 address.

It should say:

CR-2 IPv6/IPv4 PACKET FROM A HOST OF THE SAME SITE
 
    <figure omitted>

If ALL the following conditions are satisfied (i.e., the packet comes
from a 6a44 client of the same site), the 6a44 client MUST
decapsulate the inner packet and treat it as a received IPv6 packet:
(1) the IPv4 packet contains a complete IPv6 packet (protocol = 41,
offset = 0, more-fragment bit = 0); (2) the IPv6 source
address is one of the same site (the first 80 bits match those of the
6a44-client IPv6 address); (3) its last 32 bits are equal to the IPv4
source address and the IPv4 source address starts with the IPv4 link
prefix; (4) the IPv6 destination address is the 6a44-client
IPv6 address; (5) its last 32 bits are equal to the IPv4 destination
address.

Notes:

Bullet (2) in the original text has to be discarded because UDP is not used for IPv6 encapsulation in the case described by CR-2. The following bullet numbers got decremented by 1. Bullets (1) and (2)-(4) (after renumbering) were changed and bullet (5) was added taking information from CT-2 in section 6.5.2.

Thanks to Andreas for finding this.
In CR-2 of page 21 the text is inconsistent with the figure, which is right.
The proposed correction does eliminate this bug.

Errata ID: 3388
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Andreas Cudok
Date Reported: 2012-10-18
Verifier Name: Nevil Brownlee
Date Verified: 2014-01-20

Section 6.6.2 says:

RR4-5 INVALID IPv6/UDP/IPv4 PACKET

      For ANY other case, the 6a44 relay MUST discard the packet.

It should say:

RR4-5 INVALID IPv6/UDP/IPv4 PACKET

      For ANY other case, the 6a44 relay MUST discard the packet,
      and return to the UDP/IPv4 source an error-signalling bubble
      formatted according to Section 6.3

Notes:

Erratum modified by ISE after discussion with RFC authors.
The above has the advantage of error signaling in all cases where packets
from 6a44 clients cannot be forwarded, including if due to a change of
6a44-network IPv6 prefix.

The original Errata submission said:

RR4-5 INVALID IPv6/UDP/IPv4 PACKET: INCONSISTENT SOURCE ADDRESSES

If ALL the following conditions are satisfied, the 6a44 relay
MUST discard the packet and return to the source an
error-signaling bubble (i.e., with the "Bubble ID" field set
to 0) which conveys the up-to-date IPv6 prefix of the client:
(1) the IPv4 packet contains a complete UDP datagram (protocol
= 17, offset = 0, more-fragment bit = 0); (2) the UDP payload
is an IPv6 packet (length of at least 40 octets, version = 6);
(3) the IPv6 source address starts with the 6a44-network IPv6
prefix followed by a value (in the field that is composed of
bits 48-95) that is different from the UDP/IPv4 source address
of the received packet; (4) the IPv6 destination address is
not a Teredo address whose embedded IPv4 address is the
6a44-relay anycast address.

RR4-6 INVALID IPv6/UDP/IPv4 PACKET: ANY OTHER INVALID PACKET

For ANY other case, the 6a44 relay MUST silently discard the
packet.

The conditions when to send an error-signaling bubble must be exactly specified. This is done by the modified RR4-5 rule. The orginal rule has moved to RR4-6 and changed from "discard" to "silently discard", i.e. without returning an error-signaling bubble to the source.

The reference "(i.e., not conforming to R44-2 condition (3) in Section 6.6.2)" in section 6.3 (which is wrong anyway because rule R44-2 doesn't exist) should be replaced by "(i.e., conformig to RR4-5 condition in Section 6.6.2)"

This Errata replaces Errata ID 3385 with the wrong phrase "(in the field that is composed of bits 48-79)" being replaced by the correct one "(in the field that is composed of bits 48-95)".

RFC 6756, "Internet Engineering Task Force and International Telecommunication Union - Telecommunication Standardization Sector Collaboration Guidelines", September 2012

Note: This RFC has been updated by RFC 9141

Source of RFC: IAB

Errata ID: 3603
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Scott Mansfield
Date Reported: 2013-04-23
Verifier Name: Russ Housley
Date Verified: 2013-07-17

Section 2.6 says:

 Section 6.1.1 of RFC 2026 [7] describes the process for referencing
   other open standards (like ITU-T Recommendations) in IETF RFCs.

It should say:

 Section 7.1.1 of RFC 2026 [7] describes the process for referencing
   other open standards (like ITU-T Recommendations) in IETF RFCs.

RFC 6759, "Cisco Systems Export of Application Information in IP Flow Information Export (IPFIX)", November 2012

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: ops

Errata ID: 3909
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Andrew Feren
Date Reported: 2014-03-03
Verifier Name: Benoit Claise
Date Verified: 2014-04-17

Section 7.1.8 says:

   Description:
    Specifies if the Application ID is based on peer-to-peer
    technology.  Possible values are { "yes", "y", 1 },
    { "no", "n", 2 }, and { "unassigned", "u", 0 }.

It should say:

   Description:
    Specifies if the Application ID is based on peer-to-peer
    technology.  Possible values are { "yes", "y", 1 },
    { "no", "n", 2 }, and { "unassigned", "u", 0 }.

    Note that 0, 1, and 2 above are integer values; as UTF-8 
    characters they are U+0000(NUL), U+0001(SOH), and U+0002(STX). 
    WARNING: the overloading of a string value with an integer 
    representation that can take the value 0 requires careful 
    handling on collectors and exporters which use this value
    to signify the end of a string.

Notes:

Added clarifying text. The difference between a quoted and unquoted
digit (1 vs "1") is extremely subtle and easily missed.

See, for example,
http://www.ietf.org/mail-archive/web/ipfix/current/msg07151.html.

Errata ID: 3910
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Andrew Feren
Date Reported: 2014-03-03
Verifier Name: Benoit Claise
Date Verified: 2014-04-17

Section 7.1.9 says:

   Description:
     Specifies if the Application ID is used as a tunnel technology.
     Possible values are { "yes", "y", 1 }, { "no", "n", 2 },
     and { "unassigned", "u", 0 }.

It should say:

   Description:
     Specifies if the Application ID is used as a tunnel technology.
     Possible values are { "yes", "y", 1 }, { "no", "n", 2 },
     and { "unassigned", "u", 0 }.
 
     Note that 0, 1, and 2 above are integer values; as UTF-8 
     characters they are U+0000(NUL), U+0001(SOH), and U+0002(STX). 
     WARNING: the overloading of a string value with an integer 
     representation that can take the value 0 requires careful 
     handling on collectors and exporters which use this value
     to signify the end of a string.

Notes:

Added clarifying text. The difference between a quoted and unquoted
digit (1 vs "1") is extremely subtle and easily missed.

See, for example,
http://www.ietf.org/mail-archive/web/ipfix/current/msg07151.html.

Errata ID: 3911
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Andrew Feren
Date Reported: 2014-03-03
Verifier Name: Benoit Claise
Date Verified: 2014-04-17

Section 7.1.10 says:

   Description:
    Specifies if the Application ID is an encrypted networking
    protocol.  Possible values are { "yes", "y", 1 },
    { "no", "n", 2 }, and { "unassigned", "u", 0 }.

It should say:

   Description:
    Specifies if the Application ID is an encrypted networking
    protocol.  Possible values are { "yes", "y", 1 },
    { "no", "n", 2 }, and { "unassigned", "u", 0 }.

    Note that 0, 1, and 2 above are integer values; as UTF-8 
    characters they are U+0000(NUL), U+0001(SOH), and U+0002(STX). 
    WARNING: the overloading of a string value with an integer 
    representation that can take the value 0 requires careful 
    handling on collectors and exporters which use this value
    to signify the end of a string.

Notes:

Added clarifying text. The difference between a quoted and unquoted
digit (1 vs "1") is extremely subtle and easily missed.

See, for example,
http://www.ietf.org/mail-archive/web/ipfix/current/msg07151.html.

RFC 6765, "xDSL Multi-Pair Bonding (G.Bond) MIB", February 2013

Source of RFC: adslmib (ops)

Errata ID: 3592
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Edward Beili
Date Reported: 2013-04-15
Verifier Name: Benoit Claise
Date Verified: 2013-04-16

Section 8 says:

An object identifier for gBondMIB MODULE-IDENTITY has been allocated
by IANA in the MIB-2 transmission sub-tree (211).

This document defines the first version of the IANA-maintained IANA-
GBOND-TC-MIB module.  It is intended that each new G.998 bonding
scheme defined by the ITU-T Q4/SG15 working group and approved for
publication in a revision of ITU-T G.998.x will be added to the IANA-
maintained MIB module, provided that it is suitable for being managed
by the base objects in the GBOND-MIB module.  An object identifier
for ianaGBondTcMIB MODULE-IDENTITY has been allocated by IANA in the
MIB-2 transmission sub-tree (215).

It should say:

An object identifier for gBondMIB MODULE-IDENTITY has been allocated
by IANA in the MIB-2 sub-tree (211).

This document defines the first version of the IANA-maintained IANA-
GBOND-TC-MIB module.  It is intended that each new G.998 bonding
scheme defined by the ITU-T Q4/SG15 working group and approved for
publication in a revision of ITU-T G.998.x will be added to the IANA-
maintained MIB module, provided that it is suitable for being managed
by the base objects in the GBOND-MIB module.  An object identifier
for ianaGBondTcMIB MODULE-IDENTITY has been allocated by IANA in the
MIB-2 sub-tree (215).

RFC 6766, "xDSL Multi-Pair Bonding Using Time-Division Inverse Multiplexing (G.Bond/TDIM) MIB", February 2013

Source of RFC: adslmib (ops)

Errata ID: 3588
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Edward Beili
Date Reported: 2013-04-15
Verifier Name: Benoit Claise
Date Verified: 2013-04-16

Section 8. IANA Cons says:

IANA has allocated value 210 as the Object identifier for g9983MIB
MODULE-IDENTITY <http://www.iana.org/> in the MIB-2 transmission 
sub-tree.

It should say:

IANA has allocated value 210 as the Object identifier for g9983MIB 
MODULE-IDENTITY <http://www.iana.org/> under the MIB-2 tree.

Notes:

According to RFC6765, the ifType number 265 was registered for g9983.
According to the registration note for the ifType registry, for every ifType registration, the corresponding transmission number should be registered or marked "Reserved, therefore the value 265 in the Transmission Group registry should be marked as Reserved.

RFC 6767, "Ethernet-Based xDSL Multi-Pair Bonding (G.Bond/Ethernet) MIB", February 2013

Source of RFC: adslmib (ops)

Errata ID: 3589
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Edward Beili
Date Reported: 2013-04-15
Verifier Name: Benoit Claise
Date Verified: 2013-04-16

Section 8 says:

IANA has assigned 264 as the object identifier for the g9982MIB 
MODULE-IDENTITY in the MIB-2 transmission sub-tree 
<http://www.iana.org/>.

It should say:

IANA has assigned 209 as the object identifier for the g9982MIB 
MODULE-IDENTITY in the MIB-2 tree <http://www.iana.org/>.

Notes:

The following changes must be made by IANA in http://www.iana.org/assignments/smi-numbers/smi-numbers.xml :
1. The entry for the value of 209 under mib-2 shall be changed to:
209 g9982MIB G9982-MIB [RFC6767]
2. The entry for the value of 264 under transmission sub-tree shall be changed to:
264 Reserved Reserved

Errata ID: 3590
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Edward Beili
Date Reported: 2013-04-15
Verifier Name: Benoit Claise
Date Verified: 2013-04-16

Section 6 says:

    ::= { mib-2 264 }

It should say:

    ::= { mib-2 209 }

Notes:

The following changes must be made by IANA in http://www.iana.org/assignments/smi-numbers/smi-numbers.xml :
1. The entry for the value of 209 under mib-2 shall be changed to:
209 g9982MIB G9982-MIB [RFC6767]
2. The entry for the value of 264 under transmission sub-tree shall be changed to:
264 Reserved Reserved

Errata ID: 4417
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Yixi Lu
Date Reported: 2015-07-17
Verifier Name: Benoit Claise
Date Verified: 2015-07-17

Section 6 says:

g9982BasicGroup OBJECT-GROUP
     OBJECTS {
       g9982PortCapTcTypesSupported,
       g9982PortCapBacpSupported,
       g9982PortConfTcAdminType,
       g9982PortStatTcOperType,
       g9982PortStatRxErrors,
       g9982PortStatRxSmallFragments,
       g9982PortStatRxLargeFragments,
       g9982PortStatRxBadFragments,
       g9982PortStatRxLostFragments,
       g9982PortStatRxLostStarts,
       g9982PortStatRxLostEnds,
       g9982PortStatRxOverflows,
|      g9982BceStatTcInCodingErrors,
|      g9982BceStatTcInCrcErrors
     }
     STATUS      current

It should say:

g9982BasicGroup OBJECT-GROUP
     OBJECTS {
       g9982PortCapTcTypesSupported,
       g9982PortCapBacpSupported,
       g9982PortConfTcAdminType,
       g9982PortStatTcOperType,
       g9982PortStatRxErrors,
       g9982PortStatRxSmallFragments,
       g9982PortStatRxLargeFragments,
       g9982PortStatRxBadFragments,
       g9982PortStatRxLostFragments,
       g9982PortStatRxLostStarts,
       g9982PortStatRxLostEnds,
       g9982PortStatRxOverflows
     }
     STATUS      current

Notes:

"g9982BceStatTcInCodingErrors,g9982BceStatTcInCrcErrors" should not appear in g9982BasicGroup when they already exist in g9982BceGroup.

RFC 6768, "ATM-Based xDSL Bonded Interfaces MIB", February 2013

Source of RFC: adslmib (ops)

Errata ID: 3591
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Edward Beili
Date Reported: 2013-04-15
Verifier Name: Benoit Claise
Date Verified: 2013-04-16

Section 8 says:

IANA has assigned 208 as the object identifier for g9981MIB 
MODULE-IDENTITY in the MIB-2 transmission sub-tree 
<http://www.iana.org/>.

It should say:

IANA has assigned 208 as the object identifier for g9981MIB 
MODULE-IDENTITY in the MIB-2 tree <http://www.iana.org/>.

Notes:

Since the ifType value for g9981 is 263, the same value must be reserved under the transmission sub-tree in the IANA registry, see http://www.iana.org/assignments/smi-numbers/smi-numbers.xml

RFC 6773, "DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal", November 2012

Source of RFC: dccp (tsv)

Errata ID: 4352
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Hoffman
Date Reported: 2015-04-29
Verifier Name: RFC Editor
Date Verified: 2015-08-03

Section TOC says:

     3.9.  Service Codes and the DCCP Port Registry . . . . . . . . . 11
   4.  DCCP-UDP and Higher-Layer Protocols  . . . . . . . . . . . . . 11
     5.1.  Protocol Identification  . . . . . . . . . . . . . . . . . 12

It should say:

     3.9.  Service Codes and the DCCP Port Registry . . . . . . . . . 11
   4.  DCCP-UDP and Higher-Layer Protocols  . . . . . . . . . . . . . 11
   5.  Signalling the Use of DCCP-UDP . . . . . . . . . . . . . . . . 11
     5.1.  Protocol Identification  . . . . . . . . . . . . . . . . . 12

Notes:

There was a processing error when generating the table of contents.

RFC 6781, "DNSSEC Operational Practices, Version 2", December 2012

Source of RFC: dnsop (ops)

Errata ID: 4844
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Marcos Sanz
Date Reported: 2016-10-26
Verifier Name: Joel Jaeggli
Date Verified: 2017-03-29

Section 4.1.2 says:

   initial:  Initial version of the zone.  The parental DS points to
      DNSKEY_K_1.  Before the rollover starts, the child will have to
      verify what the TTL is of the DS RR that points to DNSKEY_K_1 --
      it is needed during the rollover, and we refer to the value as
      TTL_DS.

   new DNSKEY:  During the "new DNSKEY" phase, the zone administrator
      generates a second KSK, DNSKEY_K_2.  The key is provided to the
      parent, and the child will have to wait until a new DS RR has been
      generated that points to DNSKEY_K_2.  After that DS RR has been
      published on all servers authoritative for the parent's zone, the
      zone administrator has to wait at least TTL_DS to make sure that
      the old DS RR has expired from caches.

   DS change:  The parent replaces DS_K_1 with DS_K_2.

It should say:

initial:  Initial version of the zone.  The parental DS points to
    DNSKEY_K_1.  Before the rollover starts, the child will have to
    verify what the TTL is of the DS RR that points to DNSKEY_K_1 --
    it is needed during the rollover, and we refer to the value as
    TTL_DS.  Also, we refer to the TTL value of the DNSKEY_K_1 RR as
    TTL_DNSKEY.

new DNSKEY:  During the "new DNSKEY" phase, the zone administrator
    generates a second KSK, DNSKEY_K_2.  The new DNSKEY RRSet that
    includes DNSKEY_K_2 is published at the child.  After waiting at
    least TTL_DNSKEY, DNSKEY_K_2 (or the DS RR generated from it, that
    is DS_K_2) is provided to the parent.

DS change:  The parent replaces DS_K_1 with DS_K_2.  After that DS RR
    has been published on all servers authoritative for the parent's
    zone, the zone administrator has to wait at least TTL_DS to make
    sure that the old DS RR has expired from caches.

Notes:

I just corrected what is fundamentally flawed. RFC 7583 section 3.3.1 provides a much detailed explanation of the process.

Errata ID: 5174
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Andreas Cudok
Date Reported: 2017-10-29
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2017-10-30

Section Appendix B. says:

   is reduced to the following representation:

            SOA_2005092303
            RRSIG_Z_14(SOA_2005092303)
            DNSKEY_K_14
            DNSKEY_Z_15
            RRSIG_K_14(DNSKEY)
            RRSIG_Z_15(DNSKEY)

The rest of the zone data has the same signature as the SOA record,
   i.e., an RRSIG created with DNSKEY_K_14.

It should say:

   is reduced to the following representation:

            SOA_2005092303
            RRSIG_Z_14(SOA_2005092303)
            DNSKEY_Z_14
            DNSKEY_K_15
            RRSIG_Z_14(DNSKEY)
            RRSIG_K_15(DNSKEY)

The rest of the zone data has the same signature as the SOA record,
   i.e., an RRSIG created with DNSKEY_K_15.

Notes:

Note: K and Z were swapped.

RFC 6819, "OAuth 2.0 Threat Model and Security Considerations", January 2013

Source of RFC: oauth (sec)

Errata ID: 5965
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: David Piggott
Date Reported: 2020-01-23
Verifier Name: Benjamin Kaduk
Date Verified: 2020-01-30

Section 4.4.1.2 says:

Store access token hashes only (Section 5.1.4.1.3).

It should say:

Store authorization code hashes only (Section 5.1.4.1.3).

RFC 6822, "IS-IS Multi-Instance", December 2012

Note: This RFC has been obsoleted by RFC 8202

Source of RFC: isis (rtg)

Errata ID: 4519
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexander Okonnikov
Date Reported: 2015-11-02
Verifier Name: Alia Atlas
Date Verified: 2015-11-11

Section 2.4.1 and 4 says:

   MI-RTRs include the IID-TLV in the point-to-point Hello PDUs they
   originate.

------------------------------
Also in Section 4:

The following subsections describe the additional rules
   an MI-RTR MUST follow when establishing adjacencies.

It should say:

MI-RTRs include the IID-TLV in the point-to-point Hello PDUs associated
with non-zero instances that they originate.

-----------------------------
In Section 4:

The following subsections describe the additional rules an MI-RTR MUST
follow when establishing adjacencies for non-zero instances.

Notes:

The exception case (point-to-point hellos on a point-to-point IIHs on a point-to-point circuit (sic)) is discussed in Section 2.6.2.
The proposed text is therefore unnecessary. However, clarification is useful.

Errata ID: 4520
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexander Okonnikov
Date Reported: 2015-11-02
Verifier Name: Alia Atlas
Date Verified: 2015-11-11

Section 2.6.1 says:

   An MI-RTR will use the AllL1IS or AllL2IS ISIS MAC-layer address (as
   defined in [ISO10589]) as the destination address when sending an
   IS-IS PDU for the standard instance.  An MI-RTR will use one of two
   new dedicated layer 2 multicast addresses (AllL1MI-ISs or AllL2MI-
   ISs) as the destination address when sending an IS-IS PDU for any
   non-zero IID.  These addresses are specified in Section 6.  If
   operating in point-to-point mode on a broadcast circuit [RFC5309], an
   MI-RTR MUST use one of the two new multicast addresses as the
   destination address when sending point-to-point IIHs associated with
   a non-zero instance.  (Either address will do.)

   MI-RTRs MUST discard IS-IS PDUs received if either of the following
   is true:

   o  The destination multicast address is AllL1IS or AllL2IS and the
      PDU contains an IID-TLV.

   o  The destination multicast address is one of the two new addresses,
      and the PDU contains an IID-TLV with a zero value for the IID or
      has no IID-TLV.

   NOTE: If the multicast addresses AllL1IS and/or AllL2IS are
   improperly used to send IS-IS PDUs for non-zero IIDs, legacy systems
   will interpret these PDUs as being associated with IID #0.  This will
   cause inconsistencies in the LSDB in those routers, may incorrectly
   maintain adjacencies, and may lead to inconsistent DIS election.

It should say:

   An MI-RTR will use the AllL1ISs or AllL2ISs ISIS MAC-layer address
   (as defined in [ISO10589]) as the destination address when sending
   an IS-IS PDU for the standard instance.  An MI-RTR will use one of
   two new dedicated layer 2 multicast addresses (AllL1MI-ISs or
   AllL2MI-ISs) as the destination address when sending an IS-IS PDU
   for any non-zero IID.  These addresses are specified in Section 6.

   If operating in point-to-point mode on a broadcast circuit
   [RFC5309], an MI-RTR will use the AllL1ISs, AllL2ISs or AllISs
   MAC-layer address (as defined in [ISO10589]) as the destination
   address when sending an IS-IS PDU for the standard instance,
   and will use one of two new multicast addresses (AllL1MI-ISs or
   AllL2MI-ISs; either address will do) as the destination address
   when sending an IS-IS PDU for any non-zero IID.

   MI-RTRs MUST discard IS-IS PDUs received if either of the    
   following is true:

   o  The destination multicast address is AllL1ISs, AllL2ISs or 
      AllISs and the PDU contains an IID-TLV.

   o  The destination multicast address is one of the two new 
      addresses and the PDU contains an IID-TLV with a zero value for 
      the IID or has no IID-TLV.

   NOTE: If the multicast addresses AllL1ISs and/or AllL2ISs and/or 
   AllISs are improperly used to send IS-IS PDUs for non-zero IIDs, 
   legacy systems will interpret these PDUs as being associated with 
   IID #0.  This will cause inconsistencies in the LSDB in those 
   routers, may incorrectly maintain adjacencies, and may lead to 
   inconsistent DIS election.

Notes:

1. While operating in point-to-point mode over broadcast circuit, MI-RTR can use any of three multicast addresses for PDUs in standard instance - AllL1ISs, AllL2ISs or AllISs.

2. New multicast addresses must be used for all kinds of IS-IS PDUs, not only for IIHs

3. AllL1IS and AllL2IS are replaced by AllL1ISs and AllL2ISs, respectively (according to ISO 10589:2002).

RFC 6824, "TCP Extensions for Multipath Operation with Multiple Addresses", January 2013

Note: This RFC has been obsoleted by RFC 8684

Source of RFC: mptcp (tsv)

Errata ID: 3578
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kasper Dupont
Date Reported: 2013-04-01
Verifier Name: Martin Stiemerling
Date Verified: 2013-04-12

Section 3.1 says:

  Note that new subflows MUST NOT be established (using
   the process documented in Section 3.2) until a Digital Signature
   Standard (DSS) option has been successfully received across the path
   (as documented in Section 3.3).

It should say:

  Note that new subflows MUST NOT be established (using
   the process documented in Section 3.2) until a Data Sequence
   Signal (DSS) option has been successfully received across the path
   (as documented in Section 3.3).

Notes:

In this document DSS is indicated as short for both "Digital Signature Standard" and "Data Sequence Signal". I guess the reference to "Digital Signature Standard" was a mistake.

Errata ID: 4129
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Friedrich Haussmann
Date Reported: 2014-10-11
Verifier Name: Martin Stiemerling
Date Verified: 2016-01-12

Section B.1.1. says:

MPTCP.Checksum (flag):  This flag is set to true if at least one of
      the hosts has set the C bit in the MP_CAPABLE options exchanged
      during connection establishment, and is set to false otherwise.
      If this flag is set, the checksum must be computed in all DSS
      options.

It should say:

MPTCP.Checksum (flag):  This flag is set to true if at least one of
      the hosts has set the A bit in the MP_CAPABLE options exchanged
      during connection establishment, and is set to false otherwise.
      If this flag is set, the checksum must be computed in all DSS
      options.

Notes:

Checksum is not on bit "C", but instead on bit "A". There are no other instances of referring on bit "C" as the checksum. Bit "C" is unassigned in this version.

Other instances of bit "A" as checksum:
* Section 3.1. Connection Initiation, p. 16 f.
* Section 8. IANA Considerations, Table 3: MPTCP Handshake Algorithms, p. 56

RFC 6840, "Clarifications and Implementation Notes for DNS Security (DNSSEC)", February 2013

Note: This RFC has been updated by RFC 8749

Source of RFC: dnsext (int)

Errata ID: 4924
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Andrews
Date Reported: 2017-02-07
Verifier Name: Terry Manderson
Date Verified: 2017-03-01

Section IANA Conside says:

This document specifies no IANA Actions.

It should say:

Add this document as an additional reference for AD in the
DNS Parameters - DNS Header Flags registry.

Notes:

RFC6840 introduces new behaviour for AD in requests. This should be reflected in the DNS Header Flags registry otherwise it is likely DNS Implementors will overlook the new behaviour.

Errata ID: 4927
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Petr Špaček
Date Reported: 2017-02-08
Verifier Name: Terry Manderson
Date Verified: 2017-03-01

Section IANA Conside says:

(This document specifies no IANA Actions.)

It should say:

(Add following text:)
This document adds an additional reference for CD bit in the DNS
Parameters - DNS Header Flags registry.

Notes:

RFC6840 introduces new requirements for validating resolvers. This should be reflected in the DNS Header Flags registry otherwise it is likely DNS Implementors will overlook the new behaviour.

Errata ID: 4928
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Petr Špaček
Date Reported: 2017-02-08
Verifier Name: Terry Manderson
Date Verified: 2017-03-01

Section IANA Conside says:

(This document specifies no IANA Actions.)

It should say:

(Add following text:)
This document adds an additional reference for DO bit in the DNS
Parameters - DNS Header Flags registry.

Notes:

RFC6840 introduces new behaviour for DO bit in replies. This should be reflected in the DNS Header Flags registry otherwise it is likely DNS Implementors will overlook the new behaviour.

RFC 6844, "DNS Certification Authority Authorization (CAA) Resource Record", January 2013

Note: This RFC has been obsoleted by RFC 8659

Source of RFC: pkix (sec)

Errata ID: 3547
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sean Turner
Date Reported: 2013-03-15
Verifier Name: Stephen Farrell
Date Verified: 2013-03-16

Section s7.2 says:

auth         Reserved                [HB2011]
path         Reserved                [HB2011]
policy       Reserved                [HB2011]

It should say:

auth         Reserved                [RFC6844]
path         Reserved                [RFC6844]
policy       Reserved                [RFC6844]

Notes:

Better to use the datatracker history to find the values than the expired drafts.

Errata ID: 3528
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sean Turner
Date Reported: 2013-03-10
Verifier Name: Stephen Farrell
Date Verified: 2013-03-16

Section s7.3 says:

Reserved>

It should say:

Reserved

Notes:

The additional ">" is unnecessary.

Errata ID: 3532
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sean Turner
Date Reported: 2013-03-10
Verifier Name: Stephen Farrell
Date Verified: 2013-03-16

Section s7.3 says:

1-7          Reserved                 [RFC6844]

It should say:

1-7          Unassigned              [RFC6844]

Notes:

"Unassigned" is better than Reserved.

RFC 6846, "RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)", January 2013

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: tsv

Errata ID: 4490
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Didier Barvaux
Date Reported: 2015-10-04
Verifier Name: Magnus Westerlund
Date Verified: 2019-12-17

Section 8.2 says:

COMPRESSED sack3_irregular {
   discriminator =:= '00000011';
   block_1       =:= sack_block(ack_value);
   block_2       =:= sack_block(block_1.UVALUE && 0xFFFFFFFF);
   block_3       =:= sack_block(block_1.UVALUE && 0xFFFFFFFF);
   ENFORCE(length.UVALUE == 26);
 }

It should say:

COMPRESSED sack3_irregular {
   discriminator =:= '00000011';
   block_1       =:= sack_block(ack_value);
   block_2       =:= sack_block(block_1.UVALUE && 0xFFFFFFFF);
   block_3       =:= sack_block(block_2.UVALUE && 0xFFFFFFFF);
   ENFORCE(length.UVALUE == 26);
 }

Notes:

block_3 should be encoded with block_2.UVALUE as reference instead of block_1.UVALUE. All other sack[1-4]_list_item() and sack[1-4]_irregular() methods are defined this way.

RFC 6855, "IMAP Support for UTF-8", March 2013

Source of RFC: eai (app)

Errata ID: 4029
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Chris Newman
Date Reported: 2014-06-27
Verifier Name: Barry Leiba
Date Verified: 2016-02-23

Section 3 says:

   Once an IMAP client has enabled UTF-8 support with the "ENABLE
   UTF8=ACCEPT" command, it MUST NOT issue a "SEARCH" command that
   contains a charset specification.  If an IMAP server receives such a
   "SEARCH" command in that situation, it SHOULD reject the command with
   a "BAD" response (due to the conflicting charset labels).

It should say:

   Once an IMAP client has enabled UTF-8 support with the "ENABLE
   UTF8=ACCEPT" command, it MUST NOT issue a "SEARCH" command that
   contains a charset specification. If an IMAP server receives such a
   "SEARCH" command in that situation, it SHOULD reject the command with
   a "BAD" response (due to the conflicting charset labels). This also
   applies to any IMAP command or extension that includes an optional
   charset label and associated strings in the command arguments,
   including the MULTISEARCH extension. For commands with a mandatory
   charset field, such as SORT and THREAD, servers SHOULD reject charset
   values other than UTF-8 with a “BAD” response (due to the conflicting
   charset labels).

Notes:

This is a straightforward extrapolation of the existing text, but a literal reading of the existing text is silent about how to deal with this situation.

RFC 6857, "Post-Delivery Message Downgrading for Internationalized Email Messages", March 2013

Source of RFC: eai (app)

Errata ID: 3955
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Occil
Date Reported: 2014-04-10
Verifier Name: Barry Leiba
Date Verified: 2014-04-16

Section A says:

   Received: from ... by ...
   Received: from ... by ...
   From: =?UTF-8?Q?DISPLAY-LOCAL?=
         =?UTF-8?Q?NON-ASCII-LOCAL@example.com?= :;
   To:   =?UTF-8?Q?DISPLAY-REMOTE1?=
         =?UTF-8?Q?NON-ASCII-REMOTE1@example.net?= :;,
         =?UTF-8?Q?DISPLAY-REMOTE2?=
         =?UTF-8?Q?NON-ASCII-REMOTE2@example.com?= :;,
   Cc:   =?UTF-8?Q?DISPLAY-REMOTE3?=
         =?UTF-8?Q?NON-ASCII-REMOTE3@example.org?= :;

It should say:

   Received: from ... by ...
   Received: from ... by ...
   From: =?UTF-8?Q?DISPLAY-LOCAL?=
         =?UTF-8?Q?NON-ASCII-LOCAL=40example=2Ecom?= :;
   To:   =?UTF-8?Q?DISPLAY-REMOTE1?=
         =?UTF-8?Q?NON-ASCII-REMOTE1=40example=2Enet?= :;,
         =?UTF-8?Q?DISPLAY-REMOTE2?=
         =?UTF-8?Q?NON-ASCII-REMOTE2=40example=2Ecom?= :;,
   Cc:   =?UTF-8?Q?DISPLAY-REMOTE3?=
         =?UTF-8?Q?NON-ASCII-REMOTE3=40example=2Eorg?= :;

Notes:

The characters '@' and '.' cannot appear in an encoded-word occurring
in a phrase (see rule 3 of section 5 of RFC 2047), so they must be escaped
with '=40' and '=2E', respectively, in the Q encoding.

RFC 6860, "Hiding Transit-Only Networks in OSPF", January 2013

Source of RFC: ospf (rtg)

Errata ID: 3977
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Paluch
Date Reported: 2014-04-28
Verifier Name: Alia Atlas
Date Verified: 2014-05-12

Section 3 says:

   To hide a transit-only network in [OSPFv3], the IPv6 address prefixes
   are omitted from the router-LSA.  Consequently, when a Designated
   Router builds an intra-area-prefix-LSA referencing a network-LSA,
   these IPv6 address prefixes will be omitted.

It should say:

   To hide a transit-only network in [OSPFv3], the associated IPv6
   address prefixes MUST be omitted from the link-LSA. Consequently,
   when a Designated Router builds an intra-area-prefix-LSA referencing
   a network-LSA, these IPv6 address prefixes will be omitted.

Notes:

The change essentially reverts the paragraph back to the formulation from http://tools.ietf.org/html/draft-ietf-ospf-prefix-hiding-05#section-3 . Most importantly, the term "router-LSA" is replaced with "link-LSA", as there are already no prefixes carried in OSFPv3 router-LSA whatsoever, and the removal of transit-network prefixes influences link-LSAs and intra-area-prefix-LSAs. Also, the change reintroduces the keyword "MUST" that underlines the behavior that is crucial to the proper implementation of the feature.

RFC 6868, "Parameter Value Encoding in iCalendar and vCard", February 2013

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 4383
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Wierbosch
Date Reported: 2015-06-01
Verifier Name: Barry Leiba
Date Verified: 2015-06-01

Section 3.2 says:

   GEO;X-ADDRESS="Pittsburgh Pirates^n115 Federal St^nPitt
    sburgh, PA 15212":geo:40.446816,-80.00566

It should say:

   GEO;X-ADDRESS="Pittsburgh Pirates^n115 Federal St^nPitt
    sburgh, PA 15212":geo:40.446816\,-80.00566

Notes:

RFC 6350 Section 3.4 states that all property values must have COMMA characters escaped with a BACKSLASH character. The GEO property value in the example contains a comma. Therefore it must be escaped with a backslash.
(The GEO example in RFC 6350 is incorrect see Errata 3846)

RFC 6886, "NAT Port Mapping Protocol (NAT-PMP)", April 2013

Source of RFC: INDEPENDENT

Errata ID: 3618
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Stuart Cheshire
Date Reported: 2013-05-13
Verifier Name: Nevil Brownlee
Date Verified: 2013-05-23

Section 3.5 says:

   If the version in the request is not zero, then the NAT-PMP server
   MUST return the following "Unsupported Version" error response to the
   client:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vers = 0      | OP = 0        | Result Code = 1               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Seconds Since Start of Epoch (in network byte order)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

   If the version in the request is not zero, then the NAT-PMP server
   MUST return the following "Unsupported Version" error response to the
   client:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vers = 0      | OP = 128      | Result Code = 1               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Seconds Since Start of Epoch (in network byte order)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

Since this is a response, the top bit of the opcode SHOULD be set, making the opcode value 128. However, the document shows "OP = 0", which is a mistake. In all responses the top bit of the opcode SHOULD be set. However, some implementations have the same mistake as the document and do not do this. Others sensibly set the top bit since this is a reply. Hence, clients sending PCP requests to NAT-PMP servers should expect to receive both forms of reply.

RFC 6887, "Port Control Protocol (PCP)", April 2013

Note: This RFC has been updated by RFC 7488, RFC 7652, RFC 7843

Source of RFC: pcp (int)

Errata ID: 3621
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Stuart Cheshire
Date Reported: 2013-05-14
Verifier Name: Ted Lemon
Date Verified: 2013-05-15

Section 15.1 says:

   In requests where the requested Lifetime is 0, the Suggested External
   Address and Suggested External Port fields MUST be set to zero on
   transmission and MUST be ignored on reception, and these fields MUST
   be copied into the assigned external IP address and assigned external
   port of the response.

It should say:

   In requests where the requested Lifetime is 0, the Suggested External
   Port field MUST be set to zero on transmission and MUST be ignored on
   reception. The Suggested External Address field must be set to the
   appropriate all-zeros address, depending on whether the request is
   deleting a mapping for an External IPv4 address or an External IPv6
   address. Both the Suggested External Address and Suggested External
   Port fields are copied into the assigned external IP address and
   assigned external port of the response.

Notes:

Since a given internal address+port can have *two* mappings -- an IPv4 one and an IPv6 one -- the deletion request needs to signify which one is being deleted.

RFC 6890, "Special-Purpose IP Address Registries", April 2013

Note: This RFC has been updated by RFC 8190

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: int

Errata ID: 3921
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Masataka MAWATARI
Date Reported: 2014-03-17
Verifier Name: Ted Lemon
Date Verified: 2014-03-18

Section 2.2.3 says:

                    +----------------------+----------------+
                    | Attribute            | Value          |
                    +----------------------+----------------+
                    | Address Block        | 2001::/32      |
                    | Name                 | TEREDO         |
                    | RFC                  | [RFC4380]      |
                    | Allocation Date      | January 2006   |
                    | Termination Date     | N/A            |
                    | Source               | True           |
                    | Destination          | True           |
                    | Forwardable          | True           |
                    | Global               | False          |
                    | Reserved-by-Protocol | False          |
                    +----------------------+----------------+

                             Table 23: TEREDO

It should say:

                    +----------------------+----------------+
                    | Attribute            | Value          |
                    +----------------------+----------------+
                    | Address Block        | 2001::/32 [3]  |
                    | Name                 | TEREDO         |
                    | RFC                  | [RFC4380]      |
                    | Allocation Date      | January 2006   |
                    | Termination Date     | N/A            |
                    | Source               | True           |
                    | Destination          | True           |
                    | Forwardable          | True           |
                    | Global               | N/A [3]        |
                    | Reserved-by-Protocol | False          |
                    +----------------------+----------------+

                      [3] See [RFC4380] for details.

                             Table 23: TEREDO

Notes:

I think we can treat TEREDO(2001::/32) in the same way as 6to4 (2002::/16). Because both prefixes are used as the anycast prefix in the internet.
Suitable value of TEREDO is N/A that is the same value of 6to4.

So the global scope of TEREDO prefix (2001::/32) is not false.

If there is no TEREDO prefix(2001::/32) globally, the IPv6 packets from IPv6 host can't get to TEREDO relay router.

Errata ID: 6404
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Thomas
Date Reported: 2021-01-21
Verifier Name: Éric Vyncke
Date Verified: 2021-02-01

Section 2.2.2 says:

              +----------------------+----------------------------+
              | Attribute            | Value                      |
              +----------------------+----------------------------+
              | Address Block        | 0.0.0.0/8                  |
              | Name                 | "This host on this network"|
              | RFC                  | [RFC1122], Section 3.2.1.3 |
              | Allocation Date      | September 1981             |
              | Termination Date     | N/A                        |
              | Source               | True                       |
              | Destination          | False                      |
              | Forwardable          | False                      |
              | Global               | False                      |
              | Reserved-by-Protocol | True                       |
              +----------------------+----------------------------+

                    Table 1: "This host on this network"

It should say:

              +----------------------+----------------------------+
              | Attribute            | Value                      |
              +----------------------+----------------------------+
              | Address Block        | 0.0.0.0/8                  |
              | Name                 | "This network"             |
              | RFC                  | [RFC0791], Section 3.2     |
              | Allocation Date      | September 1981             |
              | Termination Date     | N/A                        |
              | Source               | True                       |
              | Destination          | False                      |
              | Forwardable          | False                      |
              | Global               | False                      |
              | Reserved-by-Protocol | True                       |
              +----------------------+----------------------------+

                          Table 1.a: "This network"

              +----------------------+----------------------------+
              | Attribute            | Value                      |
              +----------------------+----------------------------+
              | Address Block        | 0.0.0.0/32                 |
              | Name                 | "This host on this network"|
              | RFC                  | [RFC1122], Section 3.2.1.3 |
              | Allocation Date      | September 1981             |
              | Termination Date     | N/A                        |
              | Source               | True                       |
              | Destination          | False                      |
              | Forwardable          | False                      |
              | Global               | False                      |
              | Reserved-by-Protocol | True                       |
              +----------------------+----------------------------+

                          Table 1.b: "This host on this network"

Notes:

RFC1122 states that 0.0.0.0/32 is "this host on this network" while 0.0.0.0/8 is "this network".

---- Verifier note ----
After discussions with the authors, the original table must be split into TWO tables one for 0.0.0.0/8 and one for 0.0.0.0/32. IANA registry must also be updated.

Errata ID: 6881
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eugene Adell
Date Reported: 2022-03-14
Verifier Name: RFC Editor
Date Verified: 2022-03-14

Section 2.2.2 says:

   Tables 1 though 16, below, represent entries with which IANA has
   initially populated the IPv4 Special-Purpose Address Registry.

It should say:

   Tables 1 through 16, below, represent entries with which IANA has
   initially populated the IPv4 Special-Purpose Address Registry.

Notes:

obvious typo on word "through"

Errata ID: 6882
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eugene Adell
Date Reported: 2022-03-14
Verifier Name: RFC Editor
Date Verified: 2022-03-14

Section 2.2.3 says:

   Tables 17 through 28, below, represent entries with which the IANA
   has initially populated the IPv6 Special-Purpose Address Registry.

It should say:

   Tables 17 through 29, below, represent entries with which the IANA
   has initially populated the IPv6 Special-Purpose Address Registry.

Notes:

The last table (29) entry was populated at the same time than some others (loopback for example, RFC 4291)

RFC 6891, "Extension Mechanisms for DNS (EDNS(0))", April 2013

Source of RFC: dnsext (int)

Errata ID: 3604
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Olafur Gudmundsson
Date Reported: 2013-04-24
Verifier Name: Ted Lemon
Date Verified: 2013-04-24

Section 9.1 says:

9.1.  OPT Option Code Allocation Procedure

  OPT Option Codes are assigned by Expert Review.

  Assignment of Option Codes should be liberal, but duplicate
  functionality is to be avoided.

It should say:

9.1.  DNS EDNS0 Option Code Changes

  This document modifies the name of the existing registry DNS EDNS0 
  Options to DNS EDNS0 Option Codes (OPT) and updates the registration
  procedures to Expert Review.

  Assignment of Option Codes should be liberal, but duplicate
  functionality is to be avoided.

Notes:

In the publication process fixing this one minor mistake in clarifying the name of the registry fell through the cracks, the consequence of this is that IANA needs this errata to clarify the registry name.

RFC 6896, "SCS: KoanLogic's Secure Cookie Sessions for HTTP", March 2013

Source of RFC: INDEPENDENT

Errata ID: 3557
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: James Manger
Date Reported: 2013-03-18
Verifier Name: Nevil Brownlee
Date Verified: 2014-02-03

Section 3.1.1 says:

encoded as a HEX string holding the number
of seconds since the UNIX epoch

It should say:

encoded as a DECIMAL string holding the number
of seconds since the UNIX epoch

Notes:

The examples in Appendix A use decimal numbers for ATIME (eg ATIME: 1347265955), not hexadecimal.

Errata ID: 4085
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sven Herzberg
Date Reported: 2014-08-17
Verifier Name: Nevil Brownlee
Date Verified: 2014-12-22

Section Appendix A says:

   o  AES-CBC-128 key: "123456789abcdef"

It should say:

Appendix A.  Examples

   The examples in this section have been created using the 'scs' test
   tool bundled with LibSCS, a free and opensource reference
   implementation of the SCS protocol that can be found at
   (http://github.com/koanlogic/libscs).

A.1.  No Compression

   The following parameters:

   o  Plaintext cookie: "a state string"

   o  AES-CBC-128 key: 0123456789abcdef

   o  HMAC-SHA1 key: 12345678901234567890

   o  TID: tid

   o  ATIME: 1347265955

   o  IV:
      \xb4\xbd\xe5\x24\xf7\xf6\x9d\x44\x85\x30\xde\x9d\xb5\x55\xc9\x4f

   produce the following tokens:

   o  DATA: pzSOjcNui9-HWS_Qk1Pwpg

   o  ATIME: MTM0NzI2NTk1NQ

   o  TID: dGlk

   o  IV: tL3lJPf2nUSFMN6dtVXJTw

   o  AUTHTAG: uea1fgC67RmOxfpNz8gMbnPWfDA

A.2.  Use Compression

   The same parameters as above, except ATIME and IV:

   o  Plaintext cookie: "a state string"

   o  AES-CBC-128 key: 0123456789abcdef

   o  HMAC-SHA1 key: 12345678901234567890

   o  TID: tid

   o  ATIME: 1347281709

   o  IV:
      \x1d\xa7\x6f\xa0\xff\x11\xd7\x95\xe3\x4b\xfb\xa9\xff\x65\xf9\xc7

   produce the following tokens:

   o  DATA: gEnL9b92EEFBLg1qNVLoO9BpVh4GH9fyOo-NkV354JU

   o  ATIME: MTM0NzI4MTcwOQ

   o  TID: dGlk

   o  IV: HadvoP8R15XjS_up_2X5xw

   o  AUTHTAG: ak1Kq1MJV-VHZ5zaci9FsI78wSw

   In both cases, the resulting SCS cookie is obtained via ordered
   concatenation of the produced tokens, as described in Section 3.1.

Notes:

The key length for AES-CBC-128 is 128 bit (16 byte). The specified
string has a length of 15 bytes (and thus, cannot be used as the key).

This error is both in A.1. and A.2.

The corrected text above is a complete replacement (supplied by the Author) for
Appendix A, with corrected results.

RFC 6920, "Naming Things with Hashes", April 2013

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 4248
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Matthew Kerwin
Date Reported: 2015-01-28
Verifier Name: Barry Leiba
Date Verified: 2015-01-29

Section 8.2 says:

   | .well-known URL (split over 2 lines):                             |
   | http://example.com/.well-known/ni/sha256/                         |
   | UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q                       |

It should say:

   | .well-known URL (split over 2 lines):                             |
   | http://example.com/.well-known/ni/sha-256/                        |
   | UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q                       |

Notes:

The 'alg' part of the well-known URL should be the same as that of the ni URI ("sha-256"), but is missing the hyphen in the example.

RFC 6921, "Design Considerations for Faster-Than-Light (FTL) Communication", April 2013

Source of RFC: INDEPENDENT

Errata ID: 6505
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sanjeev Gupta
Date Reported: 2021-04-01
Verifier Name: Adrian Farrel
Date Verified: 2021-04-18

Section 4 says:

For protocols that do not work in this environment, the IESG should add work items to exiting working group charters or charter new working groups ...

It should say:

For protocols that do not work in this environment, the IESG should add work items to existing working group charters or charter new working groups

Notes:

Spelling mistake: exiting ->existing

RFC 6930, "RADIUS Attribute for IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", April 2013

Source of RFC: softwire (int)

Errata ID: 3616
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alan DeKok
Date Reported: 2013-05-08
Verifier Name: Ted Lemon
Date Verified: 2014-03-02

Section 4.2 says:

    0-1     0       0      0         0-1      2    User-Password

It should say:

     0-1     0       0      0         0      2    User-Password

Notes:

RFC 2866 does not allow User-Password to be in Accounting-Request messages.

Errata ID: 3622
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sheng Jiang
Date Reported: 2013-05-16
Verifier Name: Ted Lemon
Date Verified: 2013-07-08

Section 3 says:

Message-Authenticator (type 80) [RFC2865] SHOULD be used to protect 
both Access-Request and Access-Accept messages.

It should say:

Message-Authenticator (type 80) [RFC2869] SHOULD be used to protect 
both Access-Request and Access-Accept messages.

Notes:

The reference of Message-Authenticator was wrong

RFC 6933, "Entity MIB (Version 4)", May 2013

Source of RFC: eman (ops)

Errata ID: 4416
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Amanda Baber
Date Reported: 2015-07-16
Verifier Name: Benoit Claise
Date Verified: 2015-07-19

Section 3.2 says:

battery (14)

It should say:

battery(14)

RFC 6935, "IPv6 and UDP Checksums for Tunneled Packets", April 2013

Source of RFC: 6man (int)

Errata ID: 4006
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Andreas Cudok
Date Reported: 2014-06-05
Verifier Name: Brian Haberman
Date Verified: 2014-06-05

Section 5 says:

Middleboxes supporting IPv6 MUST follow requirements 9, 10, and 11
of the usage requirements specified in Section 5 of "Applicability
Statement for the Use of IPv6 UDP Datagrams with Zero Checksums"
[RFC6936].

It should say:

Middleboxes supporting IPv6 MUST follow requirements 8, 9, and 10
of the usage requirements specified in Section 5 of "Applicability
Statement for the Use of IPv6 UDP Datagrams with Zero Checksums"
[RFC6936].

RFC 6940, "REsource LOcation And Discovery (RELOAD) Base Protocol", January 2014

Source of RFC: p2psip (rai)

Errata ID: 3885
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Cullen Jennings
Date Reported: 2014-02-07
Verifier Name: Richard Barnes
Date Verified: 2014-02-15

Section 14.9 says:

   | Reserved                            | 0x8000..0xFFFE |  RFC 6940 |

It should say:

   | Reserved                            | 0x8000..0xFFFF |  RFC 6940 |

Notes:

Clearly there was some confusion and at least one of the authors thought that 0xFFFE was the largest 16 bit integer when in fact it should have been 0xFFFF. I would like to thank Pearl Liang for catching this mistake.

RFC 6944, "Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status", April 2013

Note: This RFC has been obsoleted by RFC 8624

Source of RFC: dnsext (int)

Errata ID: 4932
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Petr Špaček
Date Reported: 2017-02-12
Verifier Name: Terry Manderson
Date Verified: 2017-03-01

Section 3 says:

   This document lists the implementation status of cryptographic
   algorithms used with DNSSEC.  These algorithms are maintained in an
   IANA registry at http://www.iana.org/assignments/dns-sec-alg-numbers.
   Because this document establishes the implementation status of every
   algorithm, it has been listed as a reference for the registry itself.

It should say:

   This document lists the implementation status of cryptographic
   algorithms used with DNSSEC.  These algorithms are maintained in an
   IANA registry at http://www.iana.org/assignments/dns-sec-alg-numbers.
   Because this document establishes the implementation status of every
   algorithm, it has been listed as a reference for the registry itself.

   Given significance of status change of RSAMD5 algorithm, a reference
   to this RFC should be added to the registry.

Notes:

"RSAMD5 has an implementation status of Must Not Implement because of known weaknesses in MD5."

This is very important. An additional reference would lower likelihood that DNS Implementors will overlook the important piece of information.

Errata ID: 4083
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bodo Moeller
Date Reported: 2014-08-14
Verifier Name: Ted Lemon
Date Verified: 2014-08-14

Section 5.1 says:

N/A

It should say:

[RFC6605]   Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital Signature
            Algorithm (DSA) for DNSSEC", RFC 6605, April 2012.

Notes:

This Normative Reference is simply missing from the document, even though the algorithms from RFC 6605 are "Recommended to Implement" in RFC 6944. (Cf. how RFC 5933 is referenced, even though its algorithms are merely optional.)

RFC 6956, "Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library", June 2013

Source of RFC: forces (rtg)

Errata ID: 6643
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Argyrios Georgiou
Date Reported: 2021-07-17
Verifier Name: Alvaro Retana
Date Verified: 2021-08-12

Section 4 says:

The FE model [RFC5812] has specified predefined (built-in) atomic data types: char, uchar, int16, uint16, int32, uint32, int64, uint64, string[N], string, byte[N], boolean, octetstring[N], float16, float32, and float64.

It should say:

The FE model [RFC5812] has specified predefined (built-in) atomic data types: char, uchar, int16, uint16, int32, uint32, int64, uint64, string[N], string, byte[N], boolean, octetstring[N], float32, and float64.

Notes:

According to RFC5812, floating data types can only be float32 or float64.

RFC 6960, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", June 2013

Note: This RFC has been updated by RFC 8954

Source of RFC: pkix (sec)

Errata ID: 5891
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2019-11-02
Verifier Name: Benjamin Kaduk
Date Verified: 2019-11-06

Section Appendix B.2 says:

AuthorityInfoAccessSyntax, GeneralName, CrlEntryExtensions
FROM PKIX1Implicit-2009 -- From [RFC5912]
    {iso(1) identified-organization(3) dod(6) internet(1) security(5)
    mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)}

It should say:

AuthorityInfoAccessSyntax, GeneralName, CrlEntryExtensions, CRLReason
FROM PKIX1Implicit-2009 -- From [RFC5912]
    {iso(1) identified-organization(3) dod(6) internet(1) security(5)
    mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)}

Notes:

The CRLReason is not defined in the ASN.1 module, and it should have been imported from the one that is defined in RFC 5212. The ASN.1 compiler will generate an error without this correction.

RFC 6962, "Certificate Transparency", June 2013

Note: This RFC has been obsoleted by RFC 9162

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 3686
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Eran Messeri
Date Reported: 2013-07-26
Verifier Name: Stephen Farrell
Date Verified: 2014-07-03

Section 4.2 says:

chain:  An array of base64-encoded Precertificates.  The first
         element is the end-entity certificate; the second chains to the
         first and so on to the last, which is either the root
         certificate or a certificate that chains to a known root
         certificate.

It should say:

chain:  An array of base64-encoded Precertificate and certificates. 
         The first element is the end-entity precertificate; the second
         chains to the first and so on to the last, which is either the
         root certificate or a certificate that chains to a known root
         certificate. Only the first element in the array may be
         a precertificate.

Notes:

The current description of Add PreCertChain implies the array may consist of multiple Precertificates. In practice it only makes sense for the first element to be a Precertificate, the following elements should be proper certificates.

RFC 6969, "OSPFv3 Instance ID Registry Update", July 2013

Source of RFC: ospf (rtg)

Errata ID: 3975
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Peter Paluch
Date Reported: 2014-04-27
Verifier Name: Alia Atlas
Date Verified: 2014-05-07

Section 1 says:

   +---------+---------------------------------------------+-----------+
   | Value   | Description                                 | Reference |
   +---------+---------------------------------------------+-----------+
   | 0       | IPv6 unicast AF                             | [RFC5838] |
   | 1 - 31  | Base IPv6 Unicast AF dependent on local     | [RFC5838] |
   |         | policy                                      |           |
   | 32      | Base IPv6 Multicast                         | [RFC5838] |
   | 33-63   | IPv6 Multicast AFs dependent on local       | [RFC5838] |
   |         | policy                                      |           |
   | 64      | Base IPv4 Unicast AF                        | [RFC5838] |
   | 65-95   | IPv4 Unicast AFs dependent on local policy  | [RFC5838] |
   | 96      | Base IPv4 Multicast                         | [RFC5838] |
   | 97-127  | IPv4 Multicast AFs dependent on local       | [RFC5838] |
   |         | policy                                      |           |
   | 128-255 | Unassigned                                  | [RFC5838] |
   +---------+---------------------------------------------+-----------+

It should say:

   +---------+---------------------------------------------+-----------+
   | Value   | Description                                 | Reference |
   +---------+---------------------------------------------+-----------+
   | 0       | Base IPv6 Unicast AF                        | [RFC5838] |
   | 1 - 31  | IPv6 Unicast AFs dependent on local policy  | [RFC5838] |
   | 32      | Base IPv6 Multicast AF                      | [RFC5838] |
   | 33-63   | IPv6 Multicast AFs dependent on local       | [RFC5838] |
   |         | policy                                      |           |
   | 64      | Base IPv4 Unicast AF                        | [RFC5838] |
   | 65-95   | IPv4 Unicast AFs dependent on local policy  | [RFC5838] |
   | 96      | Base IPv4 Multicast                         | [RFC5838] |
   | 97-127  | IPv4 Multicast AFs dependent on local       | [RFC5838] |
   |         | policy                                      |           |
   | 128-255 | Unassigned                                  | [RFC5838] |
   +---------+---------------------------------------------+-----------+

Notes:

The term "Base" applies to Instance ID 0, not to IDs 1-31 which are additional IPv6 unicast AFs. Additionally, to keep the formatting consistent, the first letter in terms "Unicast" and "Multicast" is capitalized in each term instance. Also, in the description of values 1-31, "AF" is replaced with "AFs".

Errata ID: 3976
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Peter Palúch
Date Reported: 2014-04-27
Verifier Name: Alia Atlas
Date Verified: 2014-05-07

Section 2 says:

   +--------------------------+---------------+-----------------------+
   | Value                    | Description   | Reference             |
   +--------------------------+---------------+-----------------------+
   | 128-191                  | Unassigned    | 192-255               |
   | Reserved for Private Use | this document | Private Use [RFC5226] |
   +--------------------------+---------------+-----------------------+

It should say:

   +-------------+--------------------------+-------------------------+
   | Value       | Description              | Reference               |
   +-------------+--------------------------+-------------------------+
   | 128-191     | Unassigned               |                         |
   | 192-255     | Reserved for Private Use | This Document [RFC6969] |
   +-------------+--------------------------+-------------------------+

Notes:

The table was obviously misformatted.

RFC 6971, "Depth-First Forwarding (DFF) in Unreliable Networks", June 2013

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 3937
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ulrich Herberg
Date Reported: 2014-03-27
Verifier Name: Ted Lemon
Date Verified: 2014-03-27

Section 13.1.2 says:

OptDataLenDFF  - 8-bit unsigned integer.  Length of the option data
      field of this option, in octets, as specified in [RFC2460].  This
      value is set to 2 (two).

It should say:

OptDataLenDFF  - 8-bit unsigned integer.  Length of the option data
      field of this option, in octets, as specified in [RFC2460].  This
      value is set to 3 (three).

Notes:

In an earlier revision of the draft, the header was two bytes long. As a result of the IESG evaluation, the header became one octet longer (to include the version field), but I missed to update the header length.

RFC 6979, "Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)", August 2013

Source of RFC: INDEPENDENT

Errata ID: 3812
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Edward M Drayton
Date Reported: 2013-11-27
Verifier Name: Nevil Brownlee
Date Verified: 2014-02-03

Section 2.4 (page 8) says:

     If r turns out to be zero, a new k should be selected and r
       computed again (this is an utterly improbable occurrence).

   4.  The value s (modulo q) is computed:

          s = (h+x*r)/k mod q

It should say:

     If r turns out to be zero, a new k should be selected and r
       computed again (this is an utterly improbable occurrence).

   4.  The value s (modulo q) is computed:

          s = (h+x*r)/k mod q

     If s turns out to be zero, a new k should be selected and r
       and s computed again (a similarly improbable occurrence).

Notes:

My understanding is that if s is zero it has no multiplicative inverse so the signature cannot be verified. Worse, for DSA the private key can be computed directly from r and the public key components. (I'm not sure about ECDSA..)

If I'm right about this, section 3.4 and others are affected. If not, sorry for wasting your time :-(

RFC 7003, "RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Discard Metric Reporting", September 2013

Source of RFC: xrblock (rai)

Errata ID: 3735
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Dan Romascanu
Date Reported: 2013-09-24
Verifier Name: Gonzalo Camarillo
Date Verified: 2013-09-29

Section 6.1 says:

6.1.  New RTCP XR Block Type Value

   This document assigns the block type value 20 in the IANA "RTP
   Control Protocol Extended Reports (RTCP XR) Block Type Registry" to
   the "Burst/Gap Discard Metrics Block".

It should say:

6.1.  New RTCP XR Block Type Value

   This document assigns the block type value 21 in the IANA "RTP
   Control Protocol Extended Reports (RTCP XR) Block Type Registry" to
   the "Burst/Gap Discard Metrics Block".

Notes:

This error was introduced in the final editorial process before publication. The change is needed because the correct value, as assigned in the IANA "RTP
Control Protocol Extended Reports (RTCP XR) Block Type Registry", is 21.

RFC 7011, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", September 2013

Source of RFC: ipfix (ops)

Errata ID: 7875
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Katherine Prevost
Date Reported: 2024-03-28
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2024-04-04

Section 6.2 says:

   Reduced-size encoding MAY be applied to the following integer types:
   unsigned64, signed64, unsigned32, signed32, unsigned16, and signed16.
   The signed versus unsigned property of the reported value MUST be
   preserved.  The reduction in size can be to any number of octets
   smaller than the original type if the data value still fits, i.e., so
   that only leading zeroes are dropped.  For example, an unsigned64 can
   be reduced in size to 7, 6, 5, 4, 3, 2, or 1 octet(s).

It should say:

   Reduced-size encoding MAY be applied to the following integer types:
   unsigned64, signed64, unsigned32, signed32, unsigned16, and signed16.
   The signed versus unsigned property of the reported value MUST be
   preserved. The reduction in size can be to any number of octets
   smaller than the original type if the data value still fits, i.e., so
   that only leading zeroes are dropped (Or, in the case of negative
   signed values, so that only leading ones are dropped). For example,
   an unsigned64 can be reduced in size to 7, 6, 5, 4, 3, 2, or 1 octet(s).

Notes:

As written, the specification suggests that integer values may only be encoded using a reduced-size encoding if they have a run of zeroes at the beginning. However, the specification also describes being able to use reduced-size encoding for signed integer values—and only non-negative values of signed integers have a representation that begins with zeroes.

Either the text should clarify that negative values may never be expressed using a reduced-size encoding (which is what the strictest reading of the current text would suggest), or it should specify that leading ones may also be dropped for signed values, which makes it clear that they should be interpreted via sign extension of the high bit.

A quick survey of existing IPFIX implementations suggests that those which decode reduced-size encoding of integers at all produce the semantic equivalent of sign extension when they encounter a reduced-size encoding of a signed integer value.

--
WK: Thread (for posterity): https://mailarchive.ietf.org/arch/msg/ipfix/sBsLy-XYH8sQCEjnPSGoEKsRL9Y/

Errata ID: 4396
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rick Hofstede
Date Reported: 2015-06-19
Verifier Name: Benoit Claise
Date Verified: 2015-07-17

Section 3.1 says:

Incremental sequence counter modulo 2^32 of all IPFIX Data Records
sent in the current stream from the current Observation Domain by
the Exporting Process.

It should say:

Incremental sequence counter modulo 2^32 of all IPFIX Data Records
sent in the current stream from the current Observation Domain by
the Exporting Process, prior to the receipt of this IPFIX Message.

Notes:

The original specification can be interpreted in two ways:

(1) Incremental sequence counter modulo 2^32 of all IPFIX Data Records sent in the current stream from the current Observation Domain by the Exporting Process *up to* this Message.
(2) Incremental sequence counter modulo 2^32 of all IPFIX Data Records sent in the current stream from the current Observation Domain by the Exporting Process *up to and including* this Message.

It seems that only Section 10.3.2 — Reliability explains which of the two interpretations is right: In the case of UDP, the IPFIX Sequence Number contains the total number of IPFIX Data Records sent for the Transport Session *prior* to the receipt of this IPFIX Message, modulo 2^32.

In my opinion, it would be good to clarify the use of sequence numbers in Message headers already in the definition of sequence numbers in RFC 7011, namely in Section 3.1.

Discussed here: https://mailarchive.ietf.org/arch/msg/ipfix/AQKObQ2WA_zIXgRzdxRsDrIWjx0

RFC 7012, "Information Model for IP Flow Information Export (IPFIX)", September 2013

Source of RFC: ipfix (ops)

Errata ID: 3881
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Brian Trammell
Date Reported: 2014-02-05
Verifier Name: Benoit Claise
Date Verified: 2014-03-02

Section 3.1 says:

The current encodings of these data types for use with the IPFIX 
protocol are defined in [RFC7011]; encodings allowing the use of 
the IPFIX Information Elements [IANA-IPFIX] with other protocols 
may be defined in the future by referencing this document.

It should say:

The abstract data type definitions in this section are intended 
only to define the values which can be taken by Information 
Elements of each type. The encodings of these data types for 
use with the IPFIX protocol are defined in Section 6.1 of 
[RFC7011]; encodings allowing the use of the IPFIX Information 
Elements [IANA-IPFIX] with other protocols may be defined in 
the future by referencing this document. Note that for timestamp 
encodings (sections 3.1.15 - 3.1.18), it is the responsibility of 
the encoding to ensure that each representation has an 
unambiguous mapping to a moment in time (e.g. relative to a 
defined epoch).

Notes:

The separation of epoch selection between ADT and encoding in 7011 and 7012 (as compared to 5101 and 5102, which they obsolete, respectively) led to it being unclear that timestamp ADTs require a fixed reference epoch for interpretation. This change clarifies the point, replacing Errata ID 3852.

RFC 7020, "The Internet Numbers Registry System", August 2013

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 6664
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Currran
Date Reported: 2021-08-23
Verifier Name: Erik Kline
Date Verified: 2021-08-24

Section 3 says:

In cases where LIRs span multiple regions, those LIRs have established relationships with multiple RIRs. 

It should say:

In cases where LIRs span multiple regions, those LIRs have often established relationships with multiple RIRs.

Alternatetively:

In cases where LIRs span multiple regions, those LIRs often have established relationships with multiple RIRs.

Notes:

The statement about LIRs in multiple regions using multiple RIRs is remains likely for many instances but not universally - particularly given the inter-RIR transfer policies adopted since RFC7020's initial publication.

RFC 7030, "Enrollment over Secure Transport", October 2013

Note: This RFC has been updated by RFC 8951, RFC 8996

Source of RFC: pkix (sec)

Errata ID: 5904
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Justin Cranford
Date Reported: 2019-11-12
Verifier Name: Roman Danyliw
Date Verified: 2020-11-13

Section 4.1.3 says:

Content-Transfer-Encoding: base64

It should say:

Transfer-Encoding: base64

Notes:

Verifier Notes: Marked verified by the RFC Editor at the request of Roman Danyliw.
--------------------

Content-Transfer-Encoding is not a valid HTTP header. RFC 7030 is not compliant with RFC 2616.

- "MIME Content-Transfer-Encoding: base64" => Base64 Basic with CRLFs
- "HTTP Transfer-Encoding: base64" => Base64 Basic without CRLFs

This is traceable from RFC 7030 (EST) through RFC 2818 (TLS) to RFC 2616 (HTTP).

- RFC 7030 (EST): EST specifies how to transfer messages securely via HTTP over TLS (HTTPS) [RFC2818]
- RFC 2818 (TLS): HTTP [RFC2616] was originally used in the clear on the Internet.
- RFC 2616 (HTTP): HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC 2045.
- RFC 2616 (HTTP): HTTP/1.1 introduces the Transfer-Encoding header field (section 14.41).

RFC 7030 sections affected are:

- All references to Content-Transfer-Encoding are not valid: Sections 4.1.3, 4.3.1, 4.3.2, 4.4.2, 4.5.2, A.1, A.2, A.3, and A.4.
- All references to RFC 2045 are not valid: Sections 4.1.3, 4.3.1, 4.3.2, 4.4.2, 4.5.2, and 7.1.
- All references to "base64" need to be updated or removed: Sections 3.5, 4.1.3, 4.3.1, 4.3.2, 4.4.2, 4.5.2, and 7.1.

RFC 7030 fix options:

Option #1: Change all references from Content-Transfer-Encoding to Transfer-Encoding. A caveat is that "base64" has a different meaning in HTTP (no CRLFs) vs MIME (includes CRLFs).

Option #2: Remove all references to Content-Transfer-Encoding and base64. Responses would be transmitted as binary. This allows the response to be transported more efficiently without base64 size bloat, and it allows optional use of Content-Length header so the response can be parsed more efficiently knowing the length ahead of time.

RFC 7049, "Concise Binary Object Representation (CBOR)", October 2013

Note: This RFC has been obsoleted by RFC 8949

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 3764
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Peter Occil
Date Reported: 2013-10-24
Verifier Name: Barry Leiba
Date Verified: 2013-10-25

Section 2.4.2 says:

   C2                        -- Tag 2
      29                     -- Byte string of length 9
         010000000000000000  -- Bytes content

It should say:

   C2                        -- Tag 2
      49                     -- Byte string of length 9
         010000000000000000  -- Bytes content

Notes:

Major type 2, length 9 is encoded as 0x49, not 0x29.

Errata ID: 3770
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Peter Klavins
Date Reported: 2013-10-29
Verifier Name: Barry Leiba
Date Verified: 2013-10-31

Section 3.6 says:

   ...
   needed encoding (such as encoding "0" as 0b000_11101 followed by two
   bytes of 0x00) as long as the application can decode an integer of
   ...

It should say:

   ...
   needed encoding (such as encoding "0" as 0b000_11001 followed by two
   bytes of 0x00) as long as the application can decode an integer of
   ...

Notes:

Additional information value for 2-byte unsigned integer is 25, which encodes as 0b11001.

RFC 7052, "Locator/ID Separation Protocol (LISP) MIB", October 2013

Source of RFC: lisp (int)

Errata ID: 4256
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Isidor Kouvelas
Date Reported: 2015-02-04
Verifier Name: Brian Haberman
Date Verified: 2015-09-14

Section 7 says:

    REFERENCE
        "RFC 6830, Section 14.2 and
         LISP Canonical Address Format (LCAF), Work in Progress,
         March 2013."
    SYNTAX OCTET STRING (SIZE (5..39))

It should say:

    REFERENCE
        "RFC 6830, Section 14.2 and
         LISP Canonical Address Format (LCAF), Work in Progress,
         March 2013."
    SYNTAX OCTET STRING (SIZE (0..39))

Notes:

The minimum octet string length of 5 specified for the LispAddressType is incorrect. The smallest non-empty address is an IPv4 address that is not using the LCAF format to include an instance ID. This requires 8 octets (see example 1 above keeping in mind that the AFI requires 2 octets). However, in many places in the MIB definition the LispAddressType is used as the type for attributes where “unspecified” is a valid return. For example in lispEidRegistrationLastRegisterSender, an EID prefix that is configured on a Map-Server may not have any active registrations. To encode the absence of an address the minimum length of zero should be allowed.

Errata ID: 4235
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Isidor Kouvelas
Date Reported: 2015-01-17
Verifier Name: Brian Haberman
Date Verified: 2015-02-03

Section 7 says:

       Example 3: As an example where LCAF is used, suppose
       that the IPv4 EID-Prefix stored is 192.0.2.0/24 and it
       is part of LISP Instance ID 101.  In this case, the values
       within lispMapCacheEntry would be:

          lispMapCacheEidLength  = 11
          lispMapCacheEid = 16387, 7, 2, 101, 1, 192.0.2.0, 24
          ... [skip] ...

       where 11 is the total length in octets of the next object
       (lispMapCacheEID of type LispAddressType).  Then, the value
       16387 indicates the LCAF AF (see the
       IANA-ADDRESS-FAMILY-NUMBERS-MIB), the value 7 indicates that
       the LCAF AF is 7 octets in length in this case, 2 indicates
       that LCAF Type 2 encoding is used (see the LCAF document), 101
       gives the Instance ID, 1 gives the AFI (per the
       IANA-ADDRESS-FAMILY-NUMBERS-MIB) for an IPv4 address, 192.0.2.0
       is the IPv4 address, and 24 is the mask-length in bits.  Note
       that the lispMapCacheEidLength value of 11 octets is used to
       compute the length of the last field in lispMapCacheEid to be 1
       octet -- as computed by 11 - (2 + 1 + 1 + 1 + 1 + 4) = 1.

It should say:

       Example 3: As an example where LCAF is used, suppose
       that the IPv4 EID-Prefix stored is 192.0.2.0/24 and it
       is part of LISP Instance ID 101.  In this case, the values
       within lispMapCacheEntry would be:

          lispMapCacheEidLength  = 14
          lispMapCacheEid = 16387, 10, 2, 101, 1, 192.0.2.0, 24
          ... [skip] ...

       where 14 is the total length in octets of the next object
       (lispMapCacheEID of type LispAddressType).  Then, the value
       16387 indicates the LCAF AF (see the
       IANA-ADDRESS-FAMILY-NUMBERS-MIB), the value 10 indicates that
       the LCAF AF is 10 octets in length in this case, 2 indicates
       that LCAF Type 2 encoding is used (see the LCAF document), 101
       gives the Instance ID, 1 gives the AFI (per the
       IANA-ADDRESS-FAMILY-NUMBERS-MIB) for an IPv4 address, 192.0.2.0
       is the IPv4 address, and 24 is the mask-length in bits.  Note
       that the lispMapCacheEidLength value of 14 octets is used to
       compute the length of the last field in lispMapCacheEid to be 1
       octet -- as computed by 14 - (2 + 1 + 1 + 3 + 2 + 4) = 1.

Notes:

The Instance ID within the type 2 LCAF is 24 bits and requires 3 octets (incorrectly calculated as 1)
The AFI within the LCAF type 2 requires 2 octets (incorrectly calculated as 1)

Errata ID: 4304
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Isidor Kouvelas
Date Reported: 2015-03-17
Verifier Name: Brian Haberman
Date Verified: 2015-09-14

Section 7 says:

   lispEidRegistrationLastRegisterSenderLength OBJECT-TYPE
       SYNTAX     Integer32 (5..39)
       MAX-ACCESS read-only

It should say:

   lispEidRegistrationLastRegisterSenderLength OBJECT-TYPE
       SYNTAX     Integer32 (0..39)
       MAX-ACCESS read-only

Notes:

The lispEidRegistrationLastRegisterSender is the only use of the LispAddressType in a readable attribute. In order to be able to encode an unspecified address, the minimum length must be lowered to zero. For more information see errata 4256.

RFC 7108, "A Summary of Various Mechanisms Deployed at L-Root for the Identification of Anycast Nodes", January 2014

Source of RFC: INDEPENDENT

Errata ID: 4135
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mauricio Vergara Ereche
Date Reported: 2014-10-20
Verifier Name: Nevil Brownlee
Date Verified: 2014-10-21

Section 4 says:

Using HOSTNAME.BIND/CH/TXT (Section 4.2), ID.SERVER/CH/TXT
   (Section 4.3), or IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT or IDENTITY.L
   .ROOT-SERVERS/IN/A (Section 4.4)

It should say:

Using HOSTNAME.BIND/CH/TXT (Section 4.2), ID.SERVER/CH/TXT
   (Section 4.3), or IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT or IDENTITY.L
   .ROOT-SERVERS.ORG/IN/A (Section 4.4)

Notes:

Fixing missing .ORG in FQDN

RFC 7110, "Return Path Specified Label Switched Path (LSP) Ping", January 2014

Note: This RFC has been updated by RFC 7737

Source of RFC: mpls (rtg)

Errata ID: 4197
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: tom petch
Date Reported: 2014-12-09
Verifier Name: Adrian Farrel
Date Verified: 2014-12-09

Section 4 says:

The Reply Path TLV contains one or more nested sub-TLVs that can be
used

It should say:

The Reply Path TLV contains zero or more nested sub-TLVs that can be
used

Notes:

As section 4.2 correctly states, the Reply Path TLV can contain zero
sub-TLVs; this brings section 4 inline.

Errata ID: 4195
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: tom petch
Date Reported: 2014-12-09
Verifier Name: Adrian Farrel
Date Verified: 2014-12-09

Section 5.4 says:

When an echo reply is received, if the Reply Mode is "Reply via
Specified Path" and the Reply Path return code is "The echo reply was
sent successfully using the specified Reply Path", and if the return
path is an MPLS LSP.  The ingress LSR MUST perform FEC validation
(based on the FEC Stack information of the return path carried in the
Reply Path TLV) as an egress LSR does when receiving an echo request,
the FEC validation process (relevant to "ping" mode) defined in
Section 4.4.1 of [RFC4379] applies here.

When an echo reply is received with return code set to "Malformed
echo request received" and the Subcode set to zero.  It is possible
that the egress LSR may not know the "Reply via Specified Path" Reply
Mode, the operator may choose to re-perform another LSP ping by using
one of the four Reply Modes defined [RFC4379].

It should say:

When an echo reply is received, if the Reply Mode is "Reply via
Specified Path" and the Reply Path return code is "The echo reply was
sent successfully using the specified Reply Path", and if the return
path is an MPLS LSP, the ingress LSR MUST perform FEC validation
(based on the FEC Stack information of the return path carried in the
Reply Path TLV) as an egress LSR does when receiving an echo request,
the FEC validation process (relevant to "ping" mode) defined in
Section 4.4.1 of [RFC4379] applies here.

When an echo reply is received with return code set to "Malformed
echo request received" and the Subcode set to zero, it is possible
that the egress LSR may not know the "Reply via Specified Path" Reply
Mode; the operator may choose to re-perform another LSP ping by using
one of the four Reply Modes defined in [RFC4379].

Notes:

In the first two paragraphs of section 5.4, the conditional clauses and the main clause have been separated by periods, not commas, which creates uncertainty as to whether or not text of the main clause has been elided. This changes the periods into commas.

Errata ID: 4196
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: tom petch
Date Reported: 2014-12-09
Verifier Name: Adrian Farrel
Date Verified: 2014-12-09

Section 4.3.1 says:

the recommended type value is 26.

It should say:

the type value is 26.

Notes:

The WG commended a value of 26 to IANA for the "IPv4 RSVP Tunnel sub-TLV
Type" which IANA confirmed. Leaving in the 'recommended' introduces a
element of uncertainty that is best avoided.

RFC 7117, "Multicast in Virtual Private LAN Service (VPLS)", February 2014

Source of RFC: l2vpn (rtg)

Errata ID: 6724
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Benjamin Kaduk
Date Reported: 2021-10-26
Verifier Name: Andrew Alston
Date Verified: 2022-05-26

Section 7.2.2.4 says:

   If the received Inter-AS A-D route carries the PMSI Tunnel attribute
   with the Tunnel Identifier set to RSVP-TE P2MP LSP, then the ASBR
   that originated the route MUST establish an RSVP-TE P2MP LSP with the
   local PE/ASBR as a leaf.  This LSP MAY have been established before
   the local PE/ASBR receives the route, or it MAY be established after
   the local PE receives the route.

It should say:

   If the received Inter-AS A-D route carries the PMSI Tunnel attribute
   with the Tunnel Type set to RSVP-TE P2MP LSP, then the ASBR
   that originated the route MUST establish an RSVP-TE P2MP LSP with the
   local PE/ASBR as a leaf.  This LSP MAY have been established before
   the local PE/ASBR receives the route, or it MAY be established after
   the local PE receives the route.

Notes:

There is a defined Tunnel Type for RSVP-TE P2MP LSP, whereas the Tunnel Identifier field has a more complicated structure that depends on the Tunnel Type.

RFC 7139, "GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks", March 2014

Note: This RFC has been updated by RFC 7892

Source of RFC: ccamp (rtg)

Errata ID: 3944
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Fred Gruman
Date Reported: 2014-04-02
Verifier Name: Adrian Farrel
Date Verified: 2014-04-11

Section 5.1 says:

      ODUk.ts       Minimum          Nominal          Maximum
      -----------------------------------------------------------
      ODU2.ts    1,249,384.632    1,249,409.620     1,249,434.608
      ODU3.ts    1,254,678.635    1,254,703.729     1,254,728.823
      ODU4.ts    1,301,683.217    1,301,709.251     1,301,735.285

              Table 1: Actual TS Bit Rate of ODUk (in Kbps)

It should say:

      ODTUk.ts       Minimum          Nominal           Maximum
      ------------------------------------------------------------
      ODTU2.ts    1,249,384.632    1,249,409.620     1,249,434.608
      ODTU3.ts    1,254,678.635    1,254,703.729     1,254,728.823
      ODTU4.ts    1,301,683.217    1,301,709.251     1,301,735.285

              Table 1: Actual TS Bit Rate of ODUk (in Kbps)

Errata ID: 3945
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Fred Gruman
Date Reported: 2014-04-02
Verifier Name: Adrian Farrel
Date Verified: 2014-04-11

Section 7 says:

For the ingress node, a Path message with SE style SHOULD also be
sent for decreasing the ODUflex bandwidth.

It should say:

For the ingress node, a Path message with SE style MUST also be
sent for decreasing the ODUflex bandwidth.

Notes:

Section 7 requires that Shared Explicit (SE) MUST be used at the beginning when creating a resizable ODUflex connection. Thus, the SE style MUST also be used when signaling for bandwidth increase or decrease. The increase procedure mandates the use of SE style; however, the decrease procedure uses SHOULD. The decrease procedure should also make the SE signaling mandatory.

This change, that looks to be a change of substance, has been verified with the authors to be an editorial issue that was caused by not keeping the paragraphs in synch.

Errata ID: 3946
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Fred Gruman
Date Reported: 2014-04-02
Verifier Name: Adrian Farrel
Date Verified: 2014-04-11

Section 7 says:

After decreasing the bandwidth, the ingress node
SHOULD send a ResvErr message to tear down the old control state.

It should say:

After decreasing the bandwidth, the ingress node
SHOULD send a PathTear message to tear down the old control state.

Notes:

PathTear is the usual mechanism to teardown old control state. This is would also make the bandwidth decreasing procedure consistent with the bandwidth increasing procedure (bandwidth increasing procedure uses PathTear to teardown old control state.)

This change looks like a change of substance, but the authors confirm that their intent was to use the same process for both the increase and decrease in bandwidth.

Errata ID: 3928
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Adrian Farrel
Date Reported: 2014-03-22
Verifier Name: Adrian Farrel
Date Verified: 2014-03-22

Section 11 says:

      6        Och at 2.5 Gbps                       [RFC4328]

It should say:

      6        OCh at 2.5 Gbps                       [RFC4328]

Notes:

Trivial capitalization issue that is reflected in the IANA registry and could be tidied up as the registry action is still in the process of being completed.

RFC 7155, "Diameter Network Access Server Application", April 2014

Source of RFC: dime (ops)

Errata ID: 6119
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Luke Mewburn
Date Reported: 2020-04-24
Verifier Name: Robert Wilton
Date Verified: 2020-06-19

Throughout the document, when it says:

[Missing sections when RFC 4005 was obsoleted by RFC 7155]

It should say:

4.7 AVPs Used Only for Compatibility

   The AVPs defined in this section SHOULD only be used for backwards
   compatibility when a Diameter/RADIUS translation function is invoked
   and are not typically originated by Diameter systems during normal
   operations.

                                            +----------+
                                            | AVP Flag |
                                            |  Rules   |
                                            |----+-----|
                                            |MUST| MUST|
   Attribute Name           Section Defined |    |  NOT|
   -----------------------------------------|----+-----|
   Origin-AAA-Protocol      4.7.1           | M  |  V  |
   -----------------------------------------|----+-----|

4.7.1.  Origin-AAA-Protocol

   The Origin-AAA-Protocol AVP (AVP Code 408) is of the type Enumerated
   and should be inserted in a Diameter message translated by a gateway
   system from another AAA protocol, such as RADIUS.  It identifies the
   source protocol of the message to the Diameter system receiving the
   message.

   The supported values are:

         1       RADIUS

Notes:

The description of Origin-AAA-Protocol (AVP Code 408) is missing from RFC 7155. The AVP is documented in RFC 4005 section 9.3.6.

The proposed corrected text contains RFC 4005 section 9.3 as RFC 7155 section 4.7, and RFC 4005 section 9.3.6 as RFC 7155 section 4.7.1. All other AVPs in RFC 4005 section 9.3.x are not listed because they are documented in their relevant standards already.

RFC 7155 is listed as the Reference for Origin-AAA-Protocol in multiple locations in https://www.iana.org/assignments/aaa-parameters/aaa-parameters.xhtml

It appears that there may be an accidental omission of Origin-AAA-Protocol when RFC 7155 obsoleted RFC 4005.

The Origin-AAA-Protocol AVP is referenced in other sections in RFC 7155:
- 3.1. AA-Request (AAR) Command
- 3.2. AA-Answer (AAA) Command
- 3.3. Re-Auth-Request (RAR) Command
- 3.4. Re-Auth-Answer (RAA) Command
- 3.5. Session-Termination-Request (STR) Command
- 3.6. Session-Termination-Answer (STA) Command
- 3.7. Abort-Session-Request (ASR) Command
- 3.8. Abort-Session-Answer (ASA) Command
- 3.9. Accounting-Request (ACR) Command
- 3.10. Accounting-Answer (ACA) Command
- 5.1. AA-Request / AA-Answer AVP Table
- 5.2.1. Framed Access Accounting AVP Table
- 5.2.2. Non-Framed Access Accounting AVP Table

Errata ID: 5993
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michal Liptak
Date Reported: 2020-02-27
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2020-03-04

Throughout the document, when it says:

Redirected-Host*

It should say:

Redirect-Host*

Notes:

I did not find AVP Redirected-Host defined anywhere, however there is Redirect-Host in RFC 6733 (same with Redirected-Host-Usage)

[WK: Note that Errata 5993, 5994, 5995 are all related / similar. Readers are encouraged to read all 3 ]

Errata ID: 5994
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michal Liptak
Date Reported: 2020-02-27
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2020-03-04

Section 3.4 says:

Redirected-Host-Cache-Time

It should say:

Redirect-Max-Cache-Time

Notes:

As per RFC 6733 section 8.3.2

[WK: Note that Errata 5993, 5994, 5995 are all related / similar. Readers are encouraged to read all 3 ]

Errata ID: 5995
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michal Liptak
Date Reported: 2020-02-27
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2020-03-04

Throughout the document, when it says:

Connection-Info

It should say:

Connect-Info

Notes:

typo in AVP name

[WK: Note that Errata 5993, 5994, 5995 are all related / similar. Readers are encouraged to read all 3 ]

RFC 7159, "The JavaScript Object Notation (JSON) Data Interchange Format", March 2014

Note: This RFC has been obsoleted by RFC 8259

Source of RFC: json (app)

Errata ID: 3915
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Vasiliy Faronov
Date Reported: 2014-03-07
Verifier Name: Pete Resnick
Date Verified: 2014-05-16

Section 12 says:

   Since JSON's syntax is borrowed from JavaScript, it is possible to
   use that language's "eval()" function to parse JSON texts.

It should say:

   Since JSON's syntax is borrowed from JavaScript, it is possible to
   use that language's "eval()" function to parse most (but not all)
   JSON texts.

Notes:

This wording may be construed as meaning that every compliant JSON text is parseable as JavaScript, which is not the case: <http://timelessrepo.com/json-isnt-a-javascript-subset>. (Actually I would prefer this to be stated clearly elsewhere in the document, e.g. where it says "JSON's design goals were for it to be [...] a subset of JavaScript".)

--VERIFIER NOTES--
As per the above citation, there are characters (in particular line terminators like U+2028 and U+2029) which are permissible in JSON but not permissible in JavaScript. The corrected text makes this clearer.

Errata ID: 4264
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Federico do Pino
Date Reported: 2015-02-05
Verifier Name: Barry Leiba
Date Verified: 2015-03-01

Section 15.2 says:

   [Err3607]  RFC Errata, Errata ID 3607, RFC 3607,
              <http://www.rfc-editor.org>.

   [Err607]   RFC Errata, Errata ID 607, RFC 607,
              <http://www.rfc-editor.org>.

It should say:

   [Err3607]  RFC Errata, Errata ID 3607, for RFC 4627,
              <http://www.rfc-editor.org>.

   [Err607]   RFC Errata, Errata ID 607, for RFC 4627,
              <http://www.rfc-editor.org>.

Notes:

The references point to RFCs by the same numbers as the errata IDs, while the intention was to refer to errata (by the same IDs) reported for the previous JSON RFC, namely RFC 4627. (RFCs 607 and 3607 are completely unrelated.)

The links may also be replaced with direct links to the errata pages, for instance http://www.rfc-editor.org/errata_search.php?eid=607 and http://www.rfc-editor.org/errata_search.php?eid=3607

Errata ID: 4336
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Martin Pain
Date Reported: 2015-04-14
Verifier Name: Barry Leiba
Date Verified: 2015-04-14

Section Appendix A says:

[NO MENTION OF SECTION 3 OF RFC 4627]

It should say:

   o  Removed method of detection of character encoding from
      section 3 "Encoding" of RFC 4627.

       

Notes:

Appendix 1 (listing changes between RFC 4627 and RFC 7159) does not include any comment on the removal of this text from RFC 4627 section 3:

[START QUOTE]
Since the first two characters of a JSON text will always be ASCII
characters [RFC0020], it is possible to determine whether an octet
stream is UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE) by looking
at the pattern of nulls in the first four octets.

00 00 00 xx UTF-32BE
00 xx 00 xx UTF-16BE
xx 00 00 00 UTF-32LE
xx 00 xx 00 UTF-16LE
xx xx xx xx UTF-8
[END QUOTE]


The new section 8.1 "Character encoding" states that:

[START QUOTE]
JSON text SHALL be encoded in UTF-8, UTF-16, or UTF-32
[END QUOTE]

but, unlike RFC 4627 section 3, it does not say anything about how to distinguish which has been used when parsing a byte string as JSON.


RFC 7159 section 8.1 also says:

[START QUOTE]
Implementations MUST NOT add a byte order mark to the beginning of a
JSON text.
[END QUOTE]

which rules out using a byte order mark for this purpose.


Additionally, RFC 7159 section 11 says:

[START QUOTE]
Note: No "charset" parameter is defined for this registration.
Adding one really has no effect on compliant recipients.
[END QUOTE]

which rules out one means of communicating which character encoding is in use when communicating JSON over HTTP (namely a charset parameter on the media type), and implies that there is another means of detecting the character encoding, but does not say what it is.


I've reported this as an erratum on the appendix, as I expect there is an existing means of detecting which of the Unicode character encodings are in use, but I was expecting the appendix to reference it as part of an explanation of the removal of the text I quoted from RFC 4627 section 3 but no such explanation is present. It may be the case that the erratum ought to be against section 8.1 to provide a reference there.

RFC 7161, "Proxy Mobile IPv6 (PMIPv6) Multicast Handover Optimization by the Subscription Information Acquisition through the LMA (SIAL)", March 2014

Source of RFC: multimob (int)

Errata ID: 4146
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sri Gundavelli
Date Reported: 2014-10-28
Verifier Name: Brian Haberman
Date Verified: 2014-11-20

Section 4.2.2.1 says:

4.2.2.1.  Proxy Binding Update Message

   As result of the new defined flag, the PBU message format is updated
   as follows:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |           Sequence #          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |A|H|L|K|M|R|P|S|   Reserved    |            Lifetime           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                          Mobility Options                     .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

4.2.2.1.  Proxy Binding Update Message

   As result of the new defined flag, the PBU message format is updated
   as follows:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |           Sequence #          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |A|H|L|K|M|R|P|F|T|B|S| Reserved|            Lifetime           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                          Mobility Options                     .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

There is a mistake in the flags portion of the PBU/PBA messages.
It seems to be overlapping with flags defined in RFC5845. RFC5555. Both the specs were published many years before RFC7161.

Binding Update Flags

Registration Procedure(s)
Standards Action or IESG Approval
Reference
[RFC5213]
Available Formats

CSV
Flag Value Reference
A 0x8000 [RFC6275]
H 0x4000 [RFC6275]
L 0x2000 [RFC6275]
K 0x1000 [RFC6275]
M 0x0800 [RFC4140]
R 0x0400 [RFC3963]
P 0x0200 [RFC5213]
F 0x0100 [RFC5555]
T 0x0080 [RFC5845]
B 0x0040 [RFC6602]
S 0x0020 [RFC7161]


Compare Section 6.2 of RFC 5845 and Section 4.2.2.1 of RFC 7161.

Errata ID: 4147
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sri Gundavelli
Date Reported: 2014-10-28
Verifier Name: Brian Haberman
Date Verified: 2014-11-20

Section 4.2.2.2 says:

4.2.2.2.  Proxy Binding Acknowledgement Message

   As result of the new defined flag, the PBA message format is updated
   as follows:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |    Status     |K|R|P|S| Rsrvd |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Sequence #          |           Lifetime            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                        Mobility Options                       .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

4.2.2.2.  Proxy Binding Acknowledgement Message

   As result of the new defined flag, the PBA message format is updated
   as follows:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |    Status     |K|R|P|T|B|S|Res|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Sequence #          |           Lifetime            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                        Mobility Options                       .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

There is an error in the flags portion of the PBA.

Binding Acknowledgment Flags

Registration Procedure(s)
Standards Action or IESG Approval
Reference
[RFC5213]
Available Formats

CSV
Flag Value Reference
K 0x80 [RFC6275]
R 0x40 [RFC3963]
P 0x20 [RFC5213]
T 0x10 [RFC5845]
B 0x08 [RFC6602]
S 0x04 [RFC7161]


Compare Section 6.3 of RFC 5845 and Section 4.2.2.2 of RFC 7161.

RFC 7162, "IMAP Extensions: Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC)", May 2014

Source of RFC: qresync (app)

Errata ID: 5055
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Dirkjan Ochtman
Date Reported: 2017-06-28
Verifier Name: Alexey Melnikov
Date Verified: 2020-02-21

Section 3.1.2.1 says:

   C: A142 SELECT INBOX
   S: * 172 EXISTS
   S: * 1 RECENT
   S: * OK [UNSEEN 12] Message 12 is first unseen
   S: * OK [UIDVALIDITY 3857529045] UIDs valid
   S: * OK [UIDNEXT 4392] Predicted next UID
   S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
   S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
   S: * OK [HIGHESTMODSEQ 715194045007]
   S: A142 OK [READ-WRITE] SELECT completed

It should say:

   C: A142 SELECT INBOX
   S: * 172 EXISTS
   S: * 1 RECENT
   S: * OK [UNSEEN 12] Message 12 is first unseen
   S: * OK [UIDVALIDITY 3857529045] UIDs valid
   S: * OK [UIDNEXT 4392] Predicted next UID
   S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
   S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
   S: * OK [HIGHESTMODSEQ 715194045007] Ok
                                       ^^^
   S: A142 OK [READ-WRITE] SELECT completed

Notes:

RFC 7162 purports to extend RFC 3501 by adding the HIGHESTMODSEQ value as an option for the resp-text-code syntax. However, RFC 3501 only uses resp-text-code in the resp-text ABNF production, in which case it is always followed by a single space ("SP") and the "text" non-terminal, which expands to "1*TEXT-CHAR", as in non-empty text. As such, having a response code without any human-readable text suffix is illegal per the RFC 3501 spec, and the examples should be updated to be correct.

RFC 7170, "Tunnel Extensible Authentication Protocol (TEAP) Version 1", May 2014

Note: This RFC has been updated by RFC 9427

Source of RFC: emu (sec)

Errata ID: 5127
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tuure Vartiainen
Date Reported: 2017-09-25
Verifier Name: Paul Wouters
Date Verified: 2024-04-01

Section 5.2. says:

IMSK = First 32 octets of TLS-PRF(EMSK, "TEAPbindkey@ietf.org" |
     "\0" | 64)

It should say:

IMSK = First 32 octets of TLS-PRF(EMSK, "TEAPbindkey@ietf.org" |
     "\0", 64)

Notes:

According to

RFC5246 The Transport Layer Security (TLS) Protocol Version 1.2

5. HMAC and the Pseudorandom Function

"TLS's PRF is created by applying P_hash to the secret as:

PRF(secret, label, seed) = P_<hash>(secret, label + seed)"

Errata ID: 5128
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tuure Vartiainen
Date Reported: 2017-09-25
Verifier Name: Paul Wouters
Date Verified: 2024-04-01

Section 5.2. says:

IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys",
                IMSK[j], 60)

It should say:

IMCK[j] = the first 60 octets of TLS-PRF(S-IMCK[j-1],
              "Inner Methods Compound Keys",
              IMSK[j])

Notes:

According to

RFC5246 The Transport Layer Security (TLS) Protocol Version 1.2

5. HMAC and the Pseudorandom Function

"TLS's PRF is created by applying P_hash to the secret as:

PRF(secret, label, seed) = P_<hash>(secret, label + seed)"

Paul Wouters(AD): Corrected the text proposed by the original submitter, as it now appears in 7170bis

Errata ID: 5765
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jouni Malinen
Date Reported: 2019-06-28
Verifier Name: Roman Danyliw
Date Verified: 2022-03-18

Section 4.2.2 says:

   M

      Mandatory, set to one (1)

It should say:

   M

      0 (Optional)

Notes:

Authority-ID TLV is used only as an Outer TLV (in TEAP/Start) and Section 4.3.1 mandates all Outer TLVs to be marked as optional ("Outer TLVs MUST be marked as optional"). As such, Section 4.2.2 is incorrect in claiming the Authority-ID TLV to use M=1.

Errata ID: 5768
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jouni Malinen
Date Reported: 2019-06-29
Verifier Name: Paul Wouters
Date Verified: 2024-04-01

Section 5. says:

   The Compound MAC computation is as follows:

      CMK = CMK[j]
      Compound-MAC = MAC( CMK, BUFFER )

   where j is the number of the last successfully executed inner EAP
   method, MAC is the MAC function negotiated in TLS 1.2 [RFC5246], and
   BUFFER is created after concatenating these fields in the following
   order:

It should say:

The Compound MAC computation is as follows:

    Compound-MAC = the first 20 octets of MAC( CMK[n], BUFFER )

where n is the number of the last successfully executed inner method, MAC is the MAC function negotiated in TLS (e.g. TLS 1.2 in [RFC5246]), and BUFFER is created after concatenating these fields in the following order:

Notes:

This definition of how Compound MAC is computed is not compatible with the definition of Compound MAC fields in the Crypto-Binding TLV. Those fields have a fixed length of 20 octets based on Section 4.2.13 (and that TLV is claimed to have a fixed length of 76 octets). However, the MAC function negotiated in TLS have variable mac_length (e.g., MAC=SHA256 used HMAC-SHA256 with mac_length=32).

How is this supposed to work? Is Section 4.2.13 wrong in claiming that the Compound MAC fields are 20 octets? Or is Section 5.3 wrong in not specifying MAC() function to truncate the output to 20 octets? One of those need to be changed since the current design would work only with the mac_length=20 case (i.e., MAC=SHA with HMAC-SHA1).

Furthermore, that "TLS 1.2" part should not be hardcoding this to not allow TLS 1.3 or newer versions from being used.

It is also a bit strange to see the BUFFER include "The EAP Type sent by the other party in the first TEAP message." since that can only be EAP Type=TEAP, i.e., 55. If that is indeed a fixed value, it does not seem to add any protection for a negotiated parameter as a part of the crypto binding. Regardless, it would be good to be clearer in the text on how this "EAP Type" is to be encoded here (assumable it is a single octet field with value 0x37).

Paul Wouters(AD): Corrected Text provided by the WG and in 7170bis

Errata ID: 5775
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jouni Malinen
Date Reported: 2019-07-04
Verifier Name: Paul Wouters
Date Verified: 2024-04-01

Section 5. says:

   For authentication methods that generate keying material, further
   protection against man-in-the-middle attacks is provided through
   cryptographically binding keying material established by both TEAP
   Phase 1 and TEAP Phase 2 conversations.  After each successful inner
   EAP authentication, EAP EMSK and/or MSKs are cryptographically
   combined with key material from TEAP Phase 1 to generate a Compound
   Session Key (CMK).  The CMK is used to calculate the Compound MAC as
   part of the Crypto-Binding TLV described in Section 4.2.13, which
   helps provide assurance that the same entities are involved in all
   communications in TEAP.  During the calculation of the Compound MAC,
   the MAC field is filled with zeros.

   The Compound MAC computation is as follows:

      CMK = CMK[j]
      Compound-MAC = MAC( CMK, BUFFER )

   where j is the number of the last successfully executed inner EAP
   method, MAC is the MAC function negotiated in TLS 1.2 [RFC5246], and
   BUFFER is created after concatenating these fields in the following
   order:

It should say:

[Append to the end of section 5.3] 

If no key generating inner method is run then no EMSK or MSK will be generated. If an IMSK needs to be generated then the MSK and therefore the IMSK is set to all zeroes (i.e., IMSK = MSK = 32 octets of 0x00s).

Notes:

Section 5.3 does not describe how CMK is derived for the case where not inner EAP authentication method is executed (e.g., when Basic-Password-Auth is used at TLV level). Section 5.4 seems to address that case by implying that S-IMCK = session_key_seed (S-IMCK[0] does indeed have that value, but MSK/EMSK derivation uses S-IMCK[j], so use of S-IMCK here is slightly misleading). This seems to imply that MSK/EMSK derivation uses S-IMCK[0] and as such, Compound MAC derivation might use CMK[0], but CMK[0] is not defined (Section 5.2 defines CMK[j] for j=1..n-1, but not for j=0.

Furthermore, Section 4.2.13 is not clear on what Flags should be used in Crypto-Binding TLV when no inner EAP authentication method is executed. The only three values defined for Flags (1..3) all imply that either EMSK or MSK (or both) based Compound MAC is present, but there is no inner EAP method MSK/EMSK in this case since no such inner EAP method was executed. Maybe a new Flags value should be defined or alternatively, the MSK Compound MAC case could be extended to cover this no inner-EAP case with CMK[0] defined as proposed above to calculate the MSK Compound MAC.

Paul Wouters(AD): Corrected Text provided by the WG and in 7170bis

Errata ID: 5844
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jouni Malinen
Date Reported: 2019-08-24
Verifier Name: Paul Wouters
Date Verified: 2024-04-01

Section C.1 says:

                            <- Crypto-Binding TLV (Request),
                                Result TLV (Success),
                                (Optional PAC TLV)

       Crypto-Binding TLV(Response),
       Result TLV (Success),
       (PAC-Acknowledgement TLV) ->

It should say:

                            <- Intermediate-Result-TLV (Success),
                                Crypto-Binding TLV (Request),
                                Result TLV (Success),
                                (Optional PAC TLV)

       Intermediate-Result-TLV (Success),
       Crypto-Binding TLV(Response),
       Result TLV (Success),
       (PAC-Acknowledgement TLV) ->

Notes:

Section 3.3.2 implies that Intermediate-Result TLV is used after each round of Basic-Password-Auth-Req/Resp TLVs. However, the example sequence in C.1 does not show this. The proposed change in this errata adds the Intermediate-Result TLV indication here. Similar change should be done in C.2 (i.e., add Intermediate-Result TLV (Failure) to the messages that include Result TLV) since the language in 3.3.2 describe the indication to be used for both success and failure cases.

In addition to this change in C.1, it would be good to clarify the specification globally to avoid confusion about this case since almost all discussion regarding Intermediate-Result TLV currently is in the context of inner EAP authentication. 3.3.2 should have a MUST statement similar to 3.3.1. 3.6 should cover success or failure indications of basic password auth like it does EAP methods. 4.2.11 should note Intermediate-Result TLV is used with both inner EAP and basic password auth. 4.2.13 should mention basic password auth in the "regardless of whether there is an inner EAP method authentication or not" sentence.

Errata ID: 5845
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jouni Malinen
Date Reported: 2019-08-24
Verifier Name: Paul Wouters
Date Verified: 2024-04-01

Section 3.3.1 says:

   EAP method messages are carried within EAP-Payload TLVs defined in
   Section 4.2.10.  If more than one method is going to be executed in
   the tunnel, then upon method completion, the server MUST send an
   Intermediate-Result TLV indicating the result.

It should say:

   EAP method messages are carried within EAP-Payload TLVs defined in
   Section 4.2.10.  Upon method completion, the server MUST send an
   Intermediate-Result TLV indicating the result.

Notes:

Description of whether Intermediate-Result TLV is supposed to be used in the case where only a single inner EAP authentication method is used. Section 3.3.1 says "more than one method is going to be executed in the tunnel, then upon method completion, the server MUST send an Intermediate-Result TLV indicating the result", Section 3.3.3 says "The Crypto-Binding TLV and Intermediate-Result TLV MUST be included to perform cryptographic binding after each successful EAP method in a sequence of one or more EAP methods", 4.2.13 says "It MUST be included with the Intermediate-Result TLV to perform cryptographic binding after each successful EAP method in a sequence of EAP methods", Annex C.3 shows an example exchange with a single inner EAP authentication method with use of Intermediate-Result TLV.

It looks like the majority of the places discussion this topic implies that there is going to be an Intermediate-Result TLV after each inner EAP authentication method and the text in 3.3.1 is the only clear case of conflicting (or well, at least misleading if one were to claim it does not explicitly say MUST NOT for the one inner EAP authentication method case). As such, I'd conclude the Intermediate-Result TLV is indeed going to be exchanged after each EAP authentication method and the proposed text change to 3.3.1 covers that.

Errata ID: 6157
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Eliot Lear
Date Reported: 2020-05-04
Verifier Name: Roman Danyliw
Date Verified: 2022-03-17

Section 4.2.9 says:

  Status

      The Status field is one octet.  This indicates the result if the
      server does not process the action requested by the peer.

It should say:

  Status

      The Status field is one octet.  This indicates the result if the
      party who receives this TLV does not process the action.

Notes:

The status field is carried in the "Request-Action" frame. As is stated at the start of the section, the frame can be sent either by the server or the peer.

Errata ID: 7145
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Eliot Lear
Date Reported: 2022-10-05
Verifier Name: Paul Wouters
Date Verified: 2024-04-01

Section 3.3.3 says:

   The Crypto-Binding TLV MUST be exchanged and verified
   before the final Result TLV exchange, regardless of whether or not
   there is an inner EAP method authentication.

It should say:

   Except as noted below, the Crypto-Binding TLV MUST be exchanged and verified
   before the final Result TLV exchange, regardless of whether or not
   there is an inner EAP method authentication

Notes:

The text contradicts itself in the same paragraph, because it goes on to say:

The server may send the final Result TLV along with an
Intermediate-Result TLV and a Crypto-Binding TLV to indicate its
intention to end the conversation. If the peer requires nothing more
from the server, it will respond with a Result TLV indicating success
accompanied by a Crypto-Binding TLV and Intermediate-Result TLV if
necessary.

So there are actually several legal combinations here:

1. Server and peer perform a crypto-binding exchange in anticipation of later sending Result TLVs
2. The server and peer combine their crypto-binding and Result TLV in the same message.
3. One side initiates a crypto-binding TLV and the OTHER responds with both crypto-binding and Result TLV.

The practice seems to be to include the crypto-binding TLVs alongside Result TLVs.

Errata ID: 7259
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jouni Malinen
Date Reported: 2022-12-01
Verifier Name: Paul Wouters
Date Verified: 2024-04-01

Section 3.3.2 says:

   The use of EAP-FAST-GTC as defined in RFC 5421 [RFC5421] is NOT
   RECOMMENDED with TEAPv1 because EAP-FAST-GTC is not compliant with
   EAP-GTC defined in [RFC3748].  Implementations should instead make
   use of the password authentication TLVs defined in this
   specification.  The authentication server initiates password
   authentication by sending a Basic-Password-Auth-Req TLV defined in
   Section 4.2.14.  If the peer wishes to participate in password
   authentication, then it responds with a Basic-Password-Auth-Resp TLV
   as defined in Section 4.2.15 that contains the username and password.
   If it does not wish to perform password authentication, then it
   responds with a NAK TLV indicating the rejection of the Basic-
   Password-Auth-Req TLV.  Upon receiving the response, the server
   indicates the success or failure of the exchange using an
   Intermediate-Result TLV.  Multiple round trips of password
   authentication requests and responses MAY be used to support some
   "housecleaning" functions such as a password or pin change before a
   user is authenticated.

It should say:

   The use of EAP-FAST-GTC as defined in RFC 5421 [RFC5421] is NOT
   RECOMMENDED with TEAPv1 because EAP-FAST-GTC is not compliant with
   EAP-GTC defined in [RFC3748].  Implementations should instead make
   use of the password authentication TLVs defined in this
   specification.  The authentication server initiates password
   authentication by sending a Basic-Password-Auth-Req TLV defined in
   Section 4.2.14.  If the peer wishes to participate in password
   authentication, then it responds with a Basic-Password-Auth-Resp TLV
   as defined in Section 4.2.15 that contains the username and password.
   If it does not wish to perform password authentication, then it
   responds with a NAK TLV indicating the rejection of the Basic-
   Password-Auth-Req TLV.  Upon receiving the response, the server
   indicates the success or failure of the exchange using an
   Intermediate-Result TLV.  Multiple round trips of password
   authentication requests and responses MAY be used to support some
   "housecleaning" functions such as a password or pin change before a
   user is authenticated.

   If using EAP-MSCHAPv2 as an inner method, the EAP-FAST-MSCHAPv2
   variant defined in [RFC5422] MUST be used.

Notes:

While RFC 7170 does not really require this and would be technically correct as-is for this area, deployed implementations of EAP-TEAP seem to have used MSK/IMSK derivation for an inner EAP method in a manner that matches what was done with EAP-FAST. This could be called non-compliant, but for the sake of interoperability, it might make more sense to describe what is done in deployed implementation instead. The only technical difference here is in swapping the first and the second 16 octets of EAP-MSCHAPv2 MSK when it is used as the IMSK for EAP-TEAP.

RFC 7181, "The Optimized Link State Routing Protocol Version 2", April 2014

Note: This RFC has been updated by RFC 7183, RFC 7187, RFC 7188, RFC 7466

Source of RFC: manet (rtg)

Errata ID: 4874
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2016-12-01
Verifier Name: Alvaro Retana
Date Verified: 2017-02-23

Section 17.1 says:

   If the router changes its originator address, then:

   1.  If there is no Originator Tuple with:

       *  O_orig_addr = old originator address

       then create an Originator Tuple with:

       *  O_orig_addr := old originator address

       The Originator Tuple (existing or new) with:

       *  O_orig_addr = new originator address

       is then modified as follows:

       *  O_time := current time + O_HOLD_TIME

It should say:

   If the router changes its originator address, then:

   1.  If there is an Originator Tuple with:

       *  O_orig_addr = old originator address

       then modify it as follows:

       *  O_orig_addr := new originator address
       *  O_time := current time + O_HOLD_TIME

       otherwise create an Originator Tuple with:

       *  O_orig_addr := new originator address
       *  O_time := current time + O_HOLD_TIME

Notes:

At the time of the modification Originator Tuple with O_orig_addr = new originator address does not yet exist.

===
The Corrected text reflects consultation with the WG.

RFC 7186, "Security Threats for the Neighborhood Discovery Protocol (NHDP)", April 2014

Note: This RFC has been updated by RFC 7985

Source of RFC: manet (rtg)

Errata ID: 4034
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Thomas Clausen
Date Reported: 2014-07-02
Verifier Name: Adrian Farrel
Date Verified: 2014-07-20

Section 9.2 says:

   [RFC7185]  Herberg, U., Dearlove, C., and T. Clausen, "Integrity
              Protection for the Neighborhood Discovery Protocol (NHDP)
              and Optimized Link State Routing Protocol Version 2
              (OLSRv2)", RFC 7185, April 2014.

It should say:

   [RFC7183]   Herberg, U., Dearlove, C., and T. Clausen, "Integrity
               Protection for the Neighborhood Discovery Protocol (NHDP)
               and Optimized Link State Routing Protocol Version 2
               (OLSRv2)", RFC 7183, April 2014.

Notes:

Apparently, the wrong RFC number was cited: RFC7185 is "Rationale for the Use of Link Metrics in the Optimized Link State Routing Protocol Version 2 (OLSRv2)"

Additionally, all references to RFC7185 in the document (Section 1 and Section 6) should read RFC7183.

RFC 7196, "Making Route Flap Damping Usable", May 2014

Source of RFC: idr (rtg)

Errata ID: 4011
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Benoit Claise
Date Reported: 2014-06-10
Verifier Name: Alia Atlas
Date Verified: 2014-06-10

Section 3 says:

Table 1: Default RFD Parameters of Juniper and Cisco

It should say:

Table 1: The default RFD parameters for Cisco and Juniper 
         provided for the information of the reader.

Notes:

The RFC Editor Note (resulting from Barry and Benoit's DISCUSS) documented at https://datatracker.ietf.org/doc/draft-ietf-idr-rfd-usable/writeup/ has been forgotten.

RFC 7203, "An Incident Object Description Exchange Format (IODEF) Extension for Structured Cybersecurity Information", April 2014

Source of RFC: mile (sec)

Errata ID: 4517
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Takeshi Takahashi
Date Reported: 2015-10-31
Verifier Name: Kathleen Moriarty
Date Verified: 2015-11-01

Section 5.2 says:

The schema has the <sequence> </sequence> tags.

It should say:

The tags should be <xsd:sequence></xsd:sequence>.

Notes:

The schema is invalid without the correction.

The examples use <xsd:sequence>, but the actual schema just has <sequence> and does need to be fixed. With this errata update, the hope is the IANA registered schema can be updated.

Errata ID: 4518
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Takeshi Takahashi
Date Reported: 2015-10-31
Verifier Name: Kathleen Moriarty
Date Verified: 2015-11-01

Section Addresses says:

 Phone: +80 423 27 5862

It should say:

 Phone: +81 423 27 5862

Notes:

Number update from editor

RFC 7208, "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", April 2014

Note: This RFC has been updated by RFC 7372, RFC 8553, RFC 8616

Source of RFC: spfbis (app)

Errata ID: 5436
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Occil
Date Reported: 2018-07-23
Verifier Name: Alexey Melnikov
Date Verified: 2018-11-26

Throughout the document, when it says:

    header-field     = "Received-SPF:" [CFWS] result FWS [comment FWS]
                       [ key-value-list ] CRLF

It should say:

    header-field     = "Received-SPF:" [CFWS] result [ FWS comment ]
                       [ FWS key-value-list ] [FWS] CRLF

Notes:

As specified, this ABNF doesn't allow a header field value like result-FWS-comment with no FWS or key-value-list following it, a header field value which occurs very often in Received-SPF header fields I see in practice. (Note that FWS must contain at least one white space.) The corrected ABNF better follows practice in implementations.

Errata ID: 6721
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ale Vesely
Date Reported: 2021-10-25
Verifier Name: Murray Kucherawy
Date Verified: 2021-11-09

Section 8.4 says:

       550 5.7.1 SPF MAIL FROM check failed:
       550 5.7.1 The domain example.com explains:
       550 5.7.1 Please see http://www.example.com/mailpolicy.html

It should say:

       550-5.7.1 SPF MAIL FROM check failed:
       550-5.7.1 The domain example.com explains:
       550 5.7.1 Please see http://www.example.com/mailpolicy.html

Notes:

In addition, RFC 7208 does not give an example of rejection based on the HELO argument.

RFC 7209, "Requirements for Ethernet VPN (EVPN)", May 2014

Source of RFC: l2vpn (rtg)

Errata ID: 7151
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2022-10-11
Verifier Name: RFC Editor
Date Verified: 2022-10-12

Section 12 says:

   [RFC4364]  Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A
              Pre-Shared Key Extensible Authentication Protocol (EAP)
              Method", RFC 4764, January 2007.

It should say:

   [RFC4364]  Rosen, E., and Rekhter, Y., "BGP/MPLS IP Virtual Private 
              Networks (VPNs)", RFC 4364, February 2007.
              

Notes:

Incorrect document title and data.

RFC 7210, "Database of Long-Lived Symmetric Cryptographic Keys", April 2014

Source of RFC: karp (rtg)

Errata ID: 4016
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Denis Ovsienko
Date Reported: 2014-06-18
Verifier Name: Adrian Farrel
Date Verified: 2014-06-23

Section 2 says:

      SendLifetimeStart
         The SendLifetimeStart field specifies the earliest date and
         time in Coordinated Universal Time (UTC) at which this key
         should be considered for use when sending traffic.  The format
         is YYYYMMDDHHSSZ, where four digits specify the year, two
         digits specify the month, two digits specify the day, two
         digits specify the hour, two digits specify the minute, and two
         digits specify the second.  The "Z" is included as a clear
         indication that the time is in UTC.

      SendLifeTimeEnd
         The SendLifeTimeEnd field specifies the latest date and time at
         which this key should be considered for use when sending
         traffic.  The format is the same as the SendLifetimeStart
         field.

      AcceptLifeTimeStart
         The AcceptLifeTimeStart field specifies the earliest date and
         time in Coordinated Universal Time (UTC) at which this key
         should be considered for use when processing received traffic.
         The format is YYYYMMDDHHSSZ, where four digits specify the
         year, two digits specify the month, two digits specify the day,
         two digits specify the hour, two digits specify the minute, and
         two digits specify the second.  The "Z" is included as a clear
         indication that the time is in UTC.

It should say:

      SendLifetimeStart
         The SendLifetimeStart field specifies the earliest date and
         time in Coordinated Universal Time (UTC) at which this key
         should be considered for use when sending traffic.  The format
         is YYYYmmddHHMMSSZ, where four digits specify the year, two
         digits specify the month, two digits specify the day, two
         digits specify the hour, two digits specify the minute, and two
         digits specify the second.  The "Z" is included as a clear
         indication that the time is in UTC.

      SendLifeTimeEnd
         The SendLifeTimeEnd field specifies the latest date and time at
         which this key should be considered for use when sending
         traffic.  The format is the same as the SendLifetimeStart
         field.

      AcceptLifeTimeStart
         The AcceptLifeTimeStart field specifies the earliest date and
         time in Coordinated Universal Time (UTC) at which this key
         should be considered for use when processing received traffic.
         The format is YYYYmmddHHMMSSZ, where four digits specify the
         year, two digits specify the month, two digits specify the day,
         two digits specify the hour, two digits specify the minute, and
         two digits specify the second.  The "Z" is included as a clear
         indication that the time is in UTC.

Notes:

The date and time format in the original document omits minute even though the descriptive text indicates it should be included.

RFC 7223, "A YANG Data Model for Interface Management", May 2014

Note: This RFC has been obsoleted by RFC 8343

Source of RFC: netmod (ops)

Errata ID: 4405
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rob Wilton
Date Reported: 2015-06-29
Verifier Name: Benoit Claise
Date Verified: 2015-07-17

Section 1.2. says:

   o  Symbols after data node names: "?" means an optional node, "!"
      means a presence container, and "*" denotes a list and leaf-list.

It should say:

   o  Symbols after data node names: "?" means an optional node, "!"
      means a presence container, and "*" denotes either a list or a 
      leaf-list.

Notes:

Change "list and leaf-list" to "list or leaf-list"

RFC 7227, "Guidelines for Creating New DHCPv6 Options", May 2014

Source of RFC: dhc (int)

Errata ID: 4028
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dan Wing
Date Reported: 2014-06-26
Verifier Name: Ted Lemon
Date Verified: 2014-06-26

Section 5.1 says:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          option-code          |           option-len          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                         ipv6-address                          |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                         ipv6-address                          |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 1: Option with IPv6 Addresses

It should say:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          option-code          |           option-len          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                         ipv6-address                          |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                              ...                              :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 1: Option with IPv6 Addresses

Notes:

Original text shows two IPv6 addresses are required in an option. However, it should be possible to send just one IPv6 address.

RFC 7230, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", June 2014

Note: This RFC has been obsoleted by RFC 9110, RFC 9112

Note: This RFC has been updated by RFC 8615

Source of RFC: httpbis (wit)

Errata ID: 4169
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Simon Schueppel
Date Reported: 2014-11-09
Verifier Name: Barry Leiba
Date Verified: 2014-11-10

Section 7 says:

     #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]

     1#element => *( "," OWS ) element *( OWS "," [ OWS element ] )

   Empty elements do not contribute to the count of elements present.
   For example, given these ABNF productions:

     example-list      = 1#example-list-elmt
     example-list-elmt = token ; see Section 3.2.6

   Then the following are valid values for example-list (not including
   the double quotes, which are present for delimitation only):

     "foo,bar"
     "foo ,bar,"
     "foo , ,bar,charlie   "

It should say:

     #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]

     1#element => *( "," OWS ) element *( OWS "," [ OWS element ] )

   Empty elements do not contribute to the count of elements present.
   For example, given these ABNF productions:

     example-list      = 1#example-list-elmt
     example-list-elmt = token ; see Section 3.2.6

   Then the following are valid values for example-list (not including
   the double quotes, which are present for delimitation only):

     "foo,bar"
     "foo ,bar,"
     "foo , ,bar,charlie"

Notes:

"foo , ,bar,charlie " cannot be derived from 1#token (legacy list rule)
"foo , ,bar,charlie" can be derived from 1#token (legacy list rule)

Errata ID: 4251
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bjoern Hoehrmann
Date Reported: 2015-02-01
Verifier Name: Barry Leiba
Date Verified: 2015-02-01

Section 2.7.1 says:

     http-URI = "http:" "//" authority path-abempty [ "?" query ]
                [ "#" fragment ]

It should say:

     http-URI = "http:" "//" authority path-abempty [ "?" query ]

Notes:

Per http://tools.ietf.org/html/rfc3986#section-4.3 "URI scheme specifications must define their own syntax so that all strings matching their scheme-specific syntax will also match the <absolute-URI> grammar." See the discussion around http://mailarchive.ietf.org/arch/msg/apps-discuss/gZVRtgOUFyzOk68FgL1jHTzWG2s

Errata ID: 4252
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bjoern Hoehrmann
Date Reported: 2015-02-01
Verifier Name: Barry Leiba
Date Verified: 2015-02-01

Section 2.7.2. says:

     https-URI = "https:" "//" authority path-abempty [ "?" query ]
                 [ "#" fragment ]

It should say:

     https-URI = "https:" "//" authority path-abempty [ "?" query ]

Notes:

See erratum 4251 on the same document.

Errata ID: 4667
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alex Rousskov
Date Reported: 2016-04-13
Verifier Name: Alexey Melnikov
Date Verified: 2016-10-07

Section 4.1.1 says:

chunk-ext      = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )

It should say:

chunk-ext      = *( BWS  ";" BWS chunk-ext-name
                    [ BWS  "=" BWS chunk-ext-val ] )

Notes:

The infamous "implicit *LWS" syntax rule in RFC 2616 allowed whitespace between
";" and chunk-ext-name in chunk-ext. Some HTTP agents generate that whitespace.
In my experience, HTTP agents that can parse chunk extensions usually can handle
that whitespace. Moreover, ICAP, which generally relies on HTTP/1 for its message
syntax, uses that whitespace when defining the "ieof" chunk extension in RFC 3507
Section 4.5:

\r\n
0; ieof\r\n\r\n

IMHO, RFC 7230 should either allow BWS before chunk-ext-name or at the very least
explicitly document the HTTP/1 syntax change and its effect on parsers used for both
ICAP and HTTP/1 messages (a very common case for ICAP-supporting HTTP
intermediaries and ICAP services).

I also recommend adding BWS around "=", for consistency and RFC 2616 backward
compatibility reasons. HTTPbis RFCs already do that for transfer-parameter and
auth-param that have similar syntax.

Please also consider adding BWS _before_ ";" for consistency and RFC 2616 backward
compatibility reasons. HTTPbis RFCs already do that for transfer-extension,
accept-ext, t-ranking, and other constructs with similar syntax.

Errata ID: 4825
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alex Rousskov
Date Reported: 2016-04-13
Verifier Name: Alexey Melnikov
Date Verified: 2016-10-07

Section Appendix B says:

chunk-ext      = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )

It should say:

chunk-ext      = *( BWS  ";" BWS chunk-ext-name
                    [ BWS  "=" BWS chunk-ext-val ] )

Notes:

The infamous "implicit *LWS" syntax rule in RFC 2616 allowed whitespace between
";" and chunk-ext-name in chunk-ext. Some HTTP agents generate that whitespace.
In my experience, HTTP agents that can parse chunk extensions usually can handle
that whitespace. Moreover, ICAP, which generally relies on HTTP/1 for its message
syntax, uses that whitespace when defining the "ieof" chunk extension in RFC 3507
Section 4.5:

\r\n
0; ieof\r\n\r\n

IMHO, RFC 7230 should either allow BWS before chunk-ext-name or at the very least
explicitly document the HTTP/1 syntax change and its effect on parsers used for both
ICAP and HTTP/1 messages (a very common case for ICAP-supporting HTTP
intermediaries and ICAP services).

I also recommend adding BWS around "=", for consistency and RFC 2616 backward
compatibility reasons. HTTPbis RFCs already do that for transfer-parameter and
auth-param that have similar syntax.

Please also consider adding BWS _before_ ";" for consistency and RFC 2616 backward
compatibility reasons. HTTPbis RFCs already do that for transfer-extension,
accept-ext, t-ranking, and other constructs with similar syntax.

Errata ID: 4839
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Etan Kissling
Date Reported: 2016-10-23
Verifier Name: Alexey Melnikov
Date Verified: 2017-02-16

Section 4 says:

   Parameters are in the form of a name or name=value pair.

     transfer-parameter = token BWS "=" BWS ( token / quoted-string )

It should say:

   Parameters are in the form of a name=value pair.

     transfer-parameter = token BWS "=" BWS ( token / quoted-string )

Notes:

The ABNF does not allow the form of a name.

Errata ID: 4050
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Daisuke Miyakawa
Date Reported: 2014-07-11
Verifier Name: Barry Leiba
Date Verified: 2014-07-12

Section 3.2.4 says:

A server MUST reject any received request message that contains
whitespace between a header field-name and colon with a response code
of 400 (Bad Request).

It should say:

A server MUST reject any received request message that contains
whitespace between a header field-name and colon with a status code
of 400 (Bad Request).

Notes:

Basically HTTP RFCs seem to prefer "status code" over "response code". RFC 7231 Section 6 uses status code or "Response Status Code", but rarely uses the term "response code" (though it uses it, once). Some technical books actually refer those codes as "response codes". I tend to be confused with the mixture of those two terms.

Errata ID: 4205
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Semyon Kholodnov
Date Reported: 2014-12-23
Verifier Name: Barry Leiba
Date Verified: 2014-12-25

Section 6.3 says:

   o  If the received protocol is HTTP/1.0, the "keep-alive" connection
      option is present, the recipient is not a proxy, and the recipient
      wishes to honor the HTTP/1.0 "keep-alive" mechanism, the
      connection will persist after the current response; otherwise,

It should say:

  o  If the received protocol is HTTP/1.0, the "keep-alive" connection
     option is present in a message that is not a request to a proxy,
     and the recipient wishes to honor the HTTP/1.0 "keep-alive"
     mechanism, the connection will persist after the current response;
     otherwise,

Notes:

The correction makes it clearer that the reference is meant to be client-to-proxy and not proxy-to-server.

RFC 7231, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", June 2014

Note: This RFC has been obsoleted by RFC 9110

Source of RFC: httpbis (wit)

Errata ID: 4225
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bjoern Hoehrmann
Date Reported: 2015-01-09
Verifier Name: Barry Leiba
Date Verified: 2015-01-17

Section A. C & A. D says:

     field-name    = <comment, see [RFC7230], Section 3.2>

It should say:

     field-name    = <field-name, see [RFC7230], Section 3.2>

Notes:

field-name does not follow the `comment` production. The section number is correct.

RFC 7232, "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", June 2014

Note: This RFC has been obsoleted by RFC 9110

Source of RFC: httpbis (wit)

Errata ID: 5162
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2017-10-20
Verifier Name: Alexey Melnikov
Date Verified: 2017-10-20

Section A says:

   The ETag header field ABNF has been changed to not use quoted-string,
   thus avoiding escaping issues.  (Section 2.3)

It should say:

   The ETag header field ABNF has been changed to not use quoted-string,
   thus avoiding escaping issues. Furthermore, it now disallows the
   space character. (Section 2.3)

Notes:

(This entry in the changes section is incomplete)

RFC 7233, "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", June 2014

Note: This RFC has been obsoleted by RFC 9110

Source of RFC: httpbis (wit)

Errata ID: 4664
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Amichai Rothman
Date Reported: 2016-04-13
Verifier Name: Alexey Melnikov
Date Verified: 2017-02-23

Section 4.4 says:

The 416 (Range Not Satisfiable) status code indicates that none of
the ranges in the request's Range header field (Section 3.1) overlap
the current extent of the selected resource or that the set of ranges
requested has been rejected due to invalid ranges or an excessive
request of small or overlapping ranges.

It should say:

The 416 (Range Not Satisfiable) status code indicates that none of
the ranges in the request's Range header field (Section 3.1) overlap
the current extent of the selected representation or that the set of
ranges requested has been rejected due to invalid ranges or an excessive
request of small or overlapping ranges.

Notes:

The overlap may depend on the representation, not only the resource, as is the case with byte ranges.

Errata ID: 5474
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kalin Gyokov
Date Reported: 2018-08-21
Verifier Name: Alexey Melnikov
Date Verified: 2018-09-04

Section 4.4. says:

For byte ranges, failing to overlap the current extent means that the
   first-byte-pos of all of the byte-range-spec values were greater than
   the current length of the selected representation.

It should say:

For byte ranges, failing to overlap the current extent means that the
   first-byte-pos of all of the byte-range-spec values were greater than
   or equal to the current length of the selected representation.
   ^^^^^^^^^^^

Notes:

If the length of the representation is 500 bytes, then the range of the entire representation is 0-499. Then a range starting at byte position 500 fails to overlap the representation.

Errata ID: 4707
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2016-06-09
Verifier Name: Alexey Melnikov
Date Verified: 2016-06-10

Section Appendix C says:

The following core rules are included by reference, as defined in
Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return),
CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double
quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any
8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII
character).

It should say:

The following core rules are included by reference, as defined in
Appendix B.1 of [RFC5234]: ALPHA (letters), CHAR (single character),
CR (carriage return),
CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double
quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any
8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII
character).

Notes:

CHAR is used in Section 4.2 but not mentioned here.

RFC 7234, "Hypertext Transfer Protocol (HTTP/1.1): Caching", June 2014

Note: This RFC has been obsoleted by RFC 9111

Source of RFC: httpbis (wit)

Errata ID: 4674
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vasiliy Faronov
Date Reported: 2016-04-21
Verifier Name: Alexey Melnikov
Date Verified: 2016-04-26

Section 5.4 says:

   When sending a no-cache request, a client ought to include both the
   pragma and cache-control directives, unless Cache-Control: no-cache
   is purposefully omitted to target other Cache-Control response
                                                         ^^^^^^^^
   directives at HTTP/1.1 caches.

It should say:

   When sending a no-cache request, a client ought to include both the
   pragma and cache-control directives, unless Cache-Control: no-cache
   is purposefully omitted to target other Cache-Control request
                                                         ^^^^^^^
   directives at HTTP/1.1 caches.

Notes:

"other Cache-Control response directives" was probably intended to be "other Cache-Control request directives," because a request cannot have response directives.

RFC 7240, "Prefer Header for HTTP", June 2014

Note: This RFC has been updated by RFC 8144

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 4439
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin Thomson
Date Reported: 2015-08-09
Verifier Name: Barry Leiba
Date Verified: 2016-02-23

Section 2 says:

     preference = token [ BWS "=" BWS word ]
                  *( OWS ";" [ OWS parameter ] )
     parameter  = token [ BWS "=" BWS word ]

It should say:

     preference = preference-parameter *( OWS ";" [ OWS
                  preference-parameter ] )
     preference-parameter = parameter / token

Notes:

Section 1.1 incorrectly states that "word" is defined in RFC 7230. It is not. Therefore, the syntax is completely under-specified.

The "parameter" rule, as defined in RFC 7231, is used in lots of other header field definitions successfully. The only drawback is that "parameter" doesn't permit the use of "OWS" either side of the "=" character.

This change would also require changes to Section 1.1.

Errata ID: 4316
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Matthew Kerwin
Date Reported: 2015-03-27
Verifier Name: Barry Leiba
Date Verified: 2015-03-28

Section 1.1 says:

within Sections 3.2.1 and 3.2.4 of [RFC7230]; as well as the
"delta-seconds" rule defined in Section 8.1.3 of [RFC7231].

It should say:

within Sections 3.2.1 and 3.2.4 of [RFC7230]; as well as the
"delay-seconds" rule defined in Section 7.1.3 of [RFC7231].

Notes:

The reference to "delta-seconds" seems to come from an earlier version of the HTTP-bis draft. This was changed to "delay-seconds" in later versions, and the section number changed.

RFC 7241, "The IEEE 802/IETF Relationship", July 2014

Note: This RFC has been updated by RFC 9141

Source of RFC: IAB

Errata ID: 4058
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: James Lepp
Date Reported: 2014-07-21
Verifier Name: Russ Housley
Date Verified: 2014-08-27

Section 2.4 says:

(three IEEE 802 plenaries plus three
IETF 802 interim meetings each year,
compared to three IETF plenaries per year)

It should say:

(three IEEE 802 plenaries plus three
IEEE 802 interim meetings each year,
compared to three IETF plenaries per year)

Notes:

"IETF 802 interim" should read "IEEE 802 interim"

RFC 7252, "The Constrained Application Protocol (CoAP)", June 2014

Note: This RFC has been updated by RFC 7959, RFC 8613, RFC 8974, RFC 9175

Source of RFC: core (wit)

Errata ID: 4948
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Klaus Hartke
Date Reported: 2017-02-22
Verifier Name: Francesca Palombini
Date Verified: 2023-01-18

Section 5.6 says:

For a presented request, a CoAP endpoint MUST NOT use a stored
response, unless:

o  the presented request method and that used to obtain the stored
   response match,

o  all options match between those in the presented request and those
   of the request used to obtain the stored response (which includes
   the request URI), except that there is no need for a match of any
   request options marked as NoCacheKey (Section 5.4) or recognized
   by the Cache and fully interpreted with respect to its specified
   cache behavior (such as the ETag request option described in
   Section 5.10.6; see also Section 5.4.2), and

o  the stored response is either fresh or successfully validated as
   defined below.

The set of request options that is used for matching the cache entry
is also collectively referred to as the "Cache-Key".

It should say:

For a presented request, a CoAP endpoint MUST NOT use a stored
response, unless:

o  the presented request method and that used to obtain the stored
   response match,

o  all options match between those in the presented request and those
   of the request used to obtain the stored response (which includes
   the request URI), except that there is no need for a match of any
   request options marked as NoCacheKey (Section 5.4) or recognized
   by the Cache and fully interpreted with respect to its specified
   cache behavior (such as the ETag request option described in
   Section 5.10.6; see also Section 5.4.2), 

o  the payload of the presented request and the payload of the
   request used to obtain the stored response match, and

o  the stored response is either fresh or successfully validated as
   defined below.

The set of request options that is used for matching the cache entry
plus (if applicable) the request payload are also collectively referred
to as the "Cache-Key".

Notes:

CoAP servers may return error responses in reply to requests that are invalid at the CoAP level (e.g., 4.02 Bad Option if the client includes an unrecognized option) or at the application level above (e.g., 4.00 Bad Request if the client includes a malformed payload according to application semantics).

If the error response does not depend on the request payload, then it is desirable that repeated requests that differ only in the payload can be satisfied with the same cached response. E.g., repeated requests for a non-existing resource should result in a cached 4.04 Not Found response as often as possible, regardless of the payload, rather than hit the server every time.

If the error response depends on the request payload, then it is not desirable that cached responses are reused for repeated requests that differ only in the payload. E.g., a client should not receive an error response for a valid request payload because another client sent an identical request but with a malformed request payload. In this case, including the request payload in the Cache-Key would give the expected result.

The original text does not include the request in the Cache-Key, which may lead to unexpected results. The corrected text changes that.

Since CoAP does not provide any indication in responses to distinguish between the two cases, caches generally cannot determine whether the response depends on the request payload or not and thus must always include the request payload in the Cache-Key to give the expected result. (As an exception, a cache at an origin server may be able to determine whether a cached response depends on the request payload or not, and thus can reuse responses accordingly. This already applies to responses that do not depend on the request method.)

Errata ID: 4949
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Klaus Hartke
Date Reported: 2017-02-22
Verifier Name: Francesca Palombini
Date Verified: 2023-01-18

Section 5.10.7 says:

If any
of these reserved option numbers occurs in addition to Location-Path
and/or Location-Query and are not supported, then a 4.02 (Bad Option)
error MUST be returned.

It should say:

If any
of these reserved option numbers occurs in addition to Location-Path
and/or Location-Query and are not supported, then the response MUST
be rejected (Sections 4.2 and 4.3).

Notes:

The Location-* options are used in responses. A client cannot return a 4.02 (Bad Option) response in reply to a response. The correct behavior is to reject the response.

Errata ID: 5078
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jim Schaad
Date Reported: 2017-08-07
Verifier Name: Francesca Palombini
Date Verified: 2023-01-18

Section 7.2.1 says:

The Content-Format code
attribute MAY include a space-separated sequence of Content-Format
codes, indicating that multiple content-formats are available.  The
syntax of the attribute value is summarized in the production "ct-
value" in Figure 12, where "cardinal", "SP", and "DQUOTE" are defined
as in [RFC6690].

It should say:

The Content-Format code
attribute MAY include a space-separated sequence of Content-Format
codes, indicating that multiple content-formats are available.
The Content-Format code attribute MUST NOT appear more than once in a 
link.  The syntax of the attribute value is summarized in the 
production "ct-value" in Figure 12, where "cardinal", "SP", and 
"DQUOTE" are defined as in [RFC6690].

Notes:

Insert a sentence that says that the code MUST NOT appear more than once. This appears to be what was intended, but not stated, by the authors since it supports the space separated values to appear in a single attribute value.

Errata ID: 4954
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Klaus Hartke
Date Reported: 2017-02-28
Verifier Name: Francesca Palombini
Date Verified: 2023-01-18

Section 12.3 says:

CoAP does not include a separate way to convey content-encoding
information with a request or response, and for that reason the
content-encoding is also specified for each identifier (if any).  If
multiple content-encodings will be used with a media type, then a
separate Content-Format identifier for each is to be registered.
Similarly, other parameters related to an Internet media type, such
as level, can be defined for a CoAP Content-Format entry.

+--------------------------+----------+----+------------------------+
| Media type               | Encoding | ID | Reference              |
+--------------------------+----------+----+------------------------+

It should say:

CoAP does not include a separate way to convey content-coding
information with a request or response, and for that reason the
content-coding is also specified for each identifier (if any).  If
multiple content-codings will be used with a media type, then a
separate Content-Format identifier for each is to be registered.
Similarly, other parameters related to an Internet media type, such
as level, can be defined for a CoAP Content-Format entry.

+--------------------------+----------------+----+------------------+
| Content type             | Content coding | ID | Reference        |
+--------------------------+----------------+----+------------------+

Notes:

A CoAP Content-Format is the combination of an Internet Media Type with an HTTP Content Coding, as correctly explained in the first paragraphs of Section 12.3. However, the next paragraph (the original text above) incorrectly uses the term "content-encoding". The correct term is "content-coding", as shown in the corrected text.

Examples for _valid_ CoAP Content-Format registrations:

- media type "text/plain; charset=iso-8859-1" with content-coding "deflate"

- media type "image/png" with content-coding "" (no content-coding)

- media type "image/png" with content-coding "identity" (same as previous, no content-coding)

- media type "application/example+xml" with content-coding "exi"

Examples for _invalid_ CoAP Content-Format registrations:

- media type "application/coap-group+json" with content-coding "UTF-8" (UTF-8 is a character encoding, not a content-coding; should be media type "application/coap-group+json; charset=utf-8" with content-coding "identity")

- media type "audio/opus" with content-coding "identity" ("audio/opus" has a required parameter "rate"; should be media type "audio/opus; rate=48000" with content-coding "identity")

- media type "application/example+xml" with content-coding "identity, exi" (too many content-codings; should be media type "application/example+xml" with content-coding "identity" and, separately, media type "application/example+xml" with content-coding "exi")

- media type "application/example+exi" with content-coding "identity" ("+exi" is not a registered structured syntax suffix at the time of writing of this erratum)

- media type "video/ogg" with content-coding "exi" (EXI is a content-coding for XML information)

RFC 7260, "GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration", June 2014

Source of RFC: ccamp (rtg)

Errata ID: 4106
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Gregory Mirsky
Date Reported: 2014-09-08
Verifier Name: Adrian Farrel
Date Verified: 2014-12-07

Section 5.5.2 says:

   IANA has created the "OAM Sub-TLVs" sub-registry of the "RSVP-TE OAM
   Configuration Registry" as follows:

   Range       | Note                         | Registration Procedures
   ------------+------------------------------|------------------------
   0-31        | Generic Sub-TLVs             | IETF Review
   32-65534    | Technology-specific Sub-TLVs | IETF Review
   65535-65536 | Experimental Sub-TLVs        | Reserved for
               |                              |   Experimental Use

   IANA has populated the registry as follows:

      Sub-TLV Type | Description                   | Reference
      -------------+-------------------------------+----------
          0        | Reserved                      | [RFC7260]
          1        | OAM Function Flags Sub-TLV    | [RFC7260]
          2-65534  | Unassigned                    |
      65535-65536  | Reserved for Experimental Use | [RFC7260]

It should say:

    IANA has created the "OAM Sub-TLVs" sub-registry of the "RSVP-TE OAM
    Configuration Registry" as follows:

    Range       | Note                         | Registration Procedures
    ------------+------------------------------|------------------------
    0-31        | Generic Sub-TLVs             | IETF Review
    32-65533    | Technology-specific Sub-TLVs | IETF Review
    65534-65535 | Experimental Sub-TLVs        | Reserved for
                |                              |   Experimental Use

    IANA has populated the registry as follows:

       Sub-TLV Type | Description                   | Reference
       -------------+-------------------------------+----------
           0        | Reserved                      | [RFC7260]
           1        | OAM Function Flags Sub-TLV    | [RFC7260]
           2-65533  | Unassigned                    |
       65534-65535  | Reserved for Experimental Use | [RFC7260]

Notes:

Because the Type field is two octets long the value 65536 is unrealizable.
Nevertheless, it was the intention of the working group to assign to values as experimental.

RFC 7270, "Cisco-Specific Information Elements Reused in IP Flow Information Export (IPFIX)", June 2014

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 5262
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2018-02-15
Verifier Name: Benoit Claise
Date Verified: 2018-02-16

Section 4.12 says:

        value : 0x89 = 137
        binary: 10001001
        decode: 10        -> Drop
                  001001  -> Fragmentation and DF set

It should say:

        value : 0x89 = 137
        binary: 10001001
        decode: 10        -> Drop
                  001001  -> Bad TTL

Notes:

Per the "Reason Code (status = 10b, Dropped)" table, "Fragmentation and DF set" is code 000101b:

10 000101b = 133 = Fragmentation and DF set

whereas code 001001b is "Bad TTL":

10 001001b = 137 = bad TTL


IANA's IPFIX registry has been updated accordingly: https://www.iana.org/assignments/ipfix.

RFC 7273, "RTP Clock Source Signalling", June 2014

Source of RFC: avtcore (wit)

Errata ID: 4450
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kevin Gross
Date Reported: 2015-08-18
Verifier Name: Ben Campbell
Date Verified: 2016-05-25

Section 4.8 says:

  ; PTP domain allowed characters: 0x21-0x7E (IEEE 1588-2002)
   ptp-domain-name = "domain-name=" 1*16ptp-domain-char
   ptp-domain-char = %x21-7E

   ; PTP domain allowed number range: 0-127 (IEEE 1588-2008)
   ptp-domain-nmbr = "domain-nmbr=" ptp-domain-dgts
   ptp-domain-dgts = ptp-domain-n1 / ptp-domain-n2 / ptp-domain-n3
   ptp-domain-n1   = DIGIT             ; 0-9
   ptp-domain-n2   = POS-DIGIT DIGIT   ; 10-99
   ptp-domain-n3   = ("10"/"11") DIGIT ; 100-119
                   / "12" %x30-37      ; 120-127

It should say:

   ; PTP domain allowed characters: 0x21-0x7E (IEEE 1588-2002)
   ptp-domain-name = 1*16ptp-domain-char
   ptp-domain-char = %x21-7E

   ; PTP domain allowed number range: 0-127 (IEEE 1588-2008)
   ptp-domain-nmbr = ptp-domain-dgts
   ptp-domain-dgts = ptp-domain-n1 / ptp-domain-n2 / ptp-domain-n3
   ptp-domain-n1   = DIGIT             ; 0-9
   ptp-domain-n2   = POS-DIGIT DIGIT   ; 10-99
   ptp-domain-n3   = ("10"/"11") DIGIT ; 100-119
                   / "12" %x30-37      ; 120-127

Notes:

There is an inconsistency between ABNF in section 4.8 and examples in section 5.5. Due to evidence that current implementations are working to what is shown in the examples, this is resolved by updating the ABNF specification.

Errata ID: 4548
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Fletcher
Date Reported: 2015-12-01
Verifier Name: Ben Campbell
Date Verified: 2016-05-25

Section 5.2 says:

A rate modifier may be specified.  The modifier is expressed as the
ratio of two integers and modifies the rate specified or implied by
the media description by this ratio.

It should say:

A rate modifier may be specified.  The modifier is expressed as the
ratio of two integers and multiplies the rate specified or implied by
the media description by this ratio.

Notes:

Original text says that the rate modifier \\\"modifies the rate\\\" but does not say how.

Verifier note: I think "Modified by a ratio" will be generally interpreted as "multiply...". This seems editorial.

RFC 7285, "Application-Layer Traffic Optimization (ALTO) Protocol", September 2014

Note: This RFC has been updated by RFC 9274

Source of RFC: alto (ops)

Errata ID: 6874
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mohamed BOUCADAIR
Date Reported: 2022-03-08
Verifier Name: Martin Duke
Date Verified: 2022-05-12

Section 14.2 says:

                   +-------------+---------------------+
                   | Identifier  | Intended Semantics  |
                   +-------------+---------------------+
                   | routingcost | See Section 6.1.1.1 |
                   | priv:       | Private use         |
                   +-------------+---------------------+

                        Table 3: ALTO Cost Metrics

It should say:

                   +-------------+---------------------+
                   | Identifier  | Intended Semantics  |
                   +-------------+---------------------+
                   | routingcost | See Section 6.1.1.1 |
                   +-------------+---------------------+

                        Table 3: ALTO Cost Metrics

Note: Identifiers prefixed with "priv:" are
reserved for Private Use (see Section 10.6)

Notes:

priv: is not a cost metric but a prefix

Errata ID: 6876
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mohamed BOUCADAIR
Date Reported: 2022-03-09
Verifier Name: Martin Duke
Date Verified: 2022-05-12

Section 14.3 says:

                    +------------+--------------------+
                    | Identifier | Intended Semantics |
                    +------------+--------------------+
                    | pid        | See Section 7.1.1  |
                    | priv:      | Private use        |
                    +------------+--------------------+
 
                   Table 4: ALTO Endpoint Property Types

It should say:

                    +------------+--------------------+
                    | Identifier | Intended Semantics |
                    +------------+--------------------+
                    | pid        | See Section 7.1.1  |
                    +------------+--------------------+
 
                   Table 4: ALTO Endpoint Property Types

 Note: Identifiers prefixed with "priv:" are
 reserved for Private Use (see Section 10.8.2.)

Notes:

priv: is not an identifier, but a prefix.

Errata ID: 6732
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Samuel Weiler
Date Reported: 2021-11-06
Verifier Name: RFC Editor
Date Verified: 2022-01-27

Section 15.3.2 says:

HTTP Digestion Authentication

It should say:

HTTP Digest Authentication

Notes:

I'm classifying this as editorial because the correction is so obvious; feel free to reclassify it.

RFC 7292, "PKCS #12: Personal Information Exchange Syntax v1.1", July 2014

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 4356
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Will Bond
Date Reported: 2015-05-05
Verifier Name: Stephen Farrell
Date Verified: 2016-10-12

Appendix B.2 says:

   6.  For i=1, 2, ..., c, do the following:

       A.  Set A2=H^r(D||I). (i.e., the r-th hash of D||1,
           H(H(H(... H(D||I))))

       B.  Concatenate copies of Ai to create a string B of length v
           bits (the final copy of Ai may be truncated to create B).

It should say:

   6.  For i=1, 2, ..., c, do the following:

       A.  Set A_i=H^r(D||I). (i.e., the r-th hash of D||I,
           H(H(H(... H(D||I))))

       B.  Concatenate copies of A_i to create a string B of length v
           bits (the final copy of A_i may be truncated to create B).

Notes:

Step 6A explains a number of rounds of hashing D concatenated with I, however the i.e. clause shows concatenating D with 1 in one place. Also, Step 6A has been changed from "A2" to "A_i", and Step 6B has been changed from "Ai" to "A_i".

[David Thompson sent additional corrections, which have been incorporated above.]

Errata ID: 5795
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2019-07-28
Verifier Name: Benjamin Kaduk
Date Verified: 2019-08-01

Section Appendix C says:

   pkcs-12PbeParams ::= SEQUENCE {
       salt        OCTET STRING,
       iterations  INTEGER
   }

It should say:

   Pkcs-12PbeParams ::= SEQUENCE {
       salt        OCTET STRING,
       iterations  INTEGER
   }

Notes:

ASN.1 types must begin with a capital letter.

This might have been caught earlier if the parameters structure were included in the ASN.1 module, which is part of Appendix D.

Errata ID: 7257
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Takashi Kato
Date Reported: 2022-11-25
Verifier Name: RFC Editor
Date Verified: 2022-11-28

Section Appendix D. says:

 -- CRLBag
 CRLBag ::= SEQUENCE {
     crlId     BAG-TYPE.&id ({CRLTypes}),
     crltValue [0] EXPLICIT BAG-TYPE.&Type ({CRLTypes}{@crlId})
 }

It should say:

 -- CRLBag
 CRLBag ::= SEQUENCE {
     crlId     BAG-TYPE.&id ({CRLTypes}),
     crlValue [0] EXPLICIT BAG-TYPE.&Type ({CRLTypes}{@crlId})
 }

Notes:

There's excess `t` in `crlValue`

RFC 7296, "Internet Key Exchange Protocol Version 2 (IKEv2)", October 2014

Note: This RFC has been updated by RFC 7427, RFC 7670, RFC 8247, RFC 8983, RFC 9370

Source of RFC: ipsecme (sec)

Errata ID: 6940
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: warren.wang
Date Reported: 2022-04-21
Verifier Name: Paul Wouters
Date Verified: 2023-07-28

Section .10 says:

o SPI Size (1 octet) - Length in octets of the SPI as defined by the
 IPsec protocol ID or zero if no SPI is applicable. For a
 notification concerning the IKE SA, the SPI Size MUST be zero and
 the field must be empty.

It should say:

o SPI Size (1 octet) - Length in octets of the SPI as defined by the
 IPsec protocol ID or zero if no SPI is applicable. For a
 notification concerning the IKE SA, the SPI Size MUST be zero and
 the SPI field must be empty.

Notes:

the field must be empty -> the SPI field must be empty

additional question: so for a notification concerning the IKE SA, the Protocol ID field still shall be zero?

Yes, for IKE SA notifications the SPI can be seen from the header, thus there is no point of repeating the SPIs in notify payload. The Protocol ID field of the notification payload indicates which type of SPI is inside the notification payload, thus if there is no SPI in there, then there is no point of having Protocol ID either.

Errata ID: 6667
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Qingyuan Gu
Date Reported: 2021-08-30
Verifier Name: Benjamin Kaduk
Date Verified: 2021-09-01

Section 3.3 says:

   the different groups.  For example, to propose ESP with (3DES or
   AES-CBC) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain
   two Transform Type 1 candidates (one for 3DES and one for AEC-CBC)
   and two Transform Type 3 candidates (one for HMAC_MD5 and one for
   HMAC_SHA).

It should say:

   the different groups.  For example, to propose ESP with (3DES or
   AES-CBC) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain
   two Transform Type 1 candidates (one for 3DES and one for AES-CBC)
   and two Transform Type 3 candidates (one for HMAC_MD5 and one for
   HMAC_SHA).

Notes:

"AES" is misspelled as "AEC".

RFC 7305, "Report from the IAB Workshop on Internet Technology Adoption and Transition (ITAT)", July 2014

Source of RFC: IAB

Errata ID: 4086
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2014-08-18
Verifier Name: Russ Housley
Date Verified: 2014-08-27

Section 2 says:

that come to mind being IPv6 [RFC2480]

It should say:

that come to mind being IPv6 [RFC2460]

Notes:

Correct RFC number in the reference.

RFC 7306, "Remote Direct Memory Access (RDMA) Protocol Extensions", June 2014

Source of RFC: storm (tsv)

Errata ID: 4443
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Chen Wumao
Date Reported: 2015-08-10
Verifier Name: Martin Stiemerling
Date Verified: 2015-10-31

Section A.2 says:

   |              DDP (Atomic Operation Request) Queue Number      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        DDP (Atomic Operation Request) Message Sequence Number |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             DDP (Atomic Operation Request) Message Offset     |

It should say:

   |             DDP (Atomic Operation Response) Queue Number      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       DDP (Atomic Operation Response) Message Sequence Number |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            DDP (Atomic Operation Response) Message Offset     |

RFC 7320, "URI Design and Ownership", July 2014

Note: This RFC has been obsoleted by RFC 8820

Source of RFC: appsawg (app)

Errata ID: 4063
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dale Worley
Date Reported: 2014-07-25
Verifier Name: Barry Leiba
Date Verified: 2014-07-28

Section 2.1 and 5.2 says:

Section 2.1 says "MUST do so by modifying [BCP115]".

Section 5.2 says

   [BCP115]   Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
              Registration Procedures for New URI Schemes", RFC 4395,
              BCP 115, February 2006.

It should say:

Section 2.1 should say "MUST do so by modifying [BCP35]".

Section 5.2 should say

   [BCP35]    Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
              Registration Procedures for New URI Schemes", RFC 4395,
              BCP 35, February 2006.

Notes:

RFC 4395 is BCP 35, not BCP 115. See the entry in bcp-index.txt:

0115 [BCP number 115 is retired. It was mistakenly assigned to RFC
4395. RFC 4395 is BCP 35.]

RFC 7331, "Bidirectional Forwarding Detection (BFD) Management Information Base", August 2014

Source of RFC: bfd (rtg)

Errata ID: 4214
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jeffrey Haas
Date Reported: 2014-12-30
Verifier Name: Adrian Farrel
Date Verified: 2015-01-03

Section Various says:

bfdSessionTable, bfdSessionPerfTable 

It should say:

bfdSessTable, bfdSessPerfTable

Notes:

Throughout the document, bfdSessionTable and bfdSessionPerfTable are used in various text. The underlying MIB OBJECT-TYPEs are bfdSessTable and bfdSessPerfTable. While these discrepancies occur within the MIB module itself, they do not do so in any component that impacts compilation of the MIB module.

RFC 7348, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", August 2014

Source of RFC: INDEPENDENT

Errata ID: 4990
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kaustubh Kelkar
Date Reported: 2017-04-06
Verifier Name: Nevil Brownlee
Date Verified: 2017-07-20

Section 5 says:

Outer IPv4 Header:
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|  IHL  |Type of Service|          Total Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Identification        |Flags|      Fragment Offset    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Time to Live |Protocl=17(UDP)|   Header Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Outer Source IPv4 Address               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Outer Destination IPv4 Address              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

Outer IPv4 Header:
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|  IHL  |Type of Service|          Total Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Identification        |Flags|      Fragment Offset    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Time to Live |Protocol=17(UDP)|   Header Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Outer Source IPv4 Address               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Outer Destination IPv4 Address              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

Minor spelling mistake while writing "procotol"

RFC 7361, "LDP Extensions for Optimized MAC Address Withdrawal in a Hierarchical Virtual Private LAN Service (H-VPLS)", September 2014

Source of RFC: l2vpn (rtg)

Errata ID: 4380
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: rainsword
Date Reported: 2015-05-29
Verifier Name: Deborah Brungard
Date Verified: 2015-06-24

Section 5.2 says:

   At least one of the following sub-TLVs MUST be included in the MAC
   Flush Parameters TLV if the C-flag is set to 1:

   o  PBB B-MAC List Sub-TLV:

      Type: 0x0407

      Length: Value length in octets.  At least one B-MAC address MUST
      be present in the list.

      Value: One or a list of 48-bit B-MAC addresses.  These are the
      source B-MAC addresses associated with the B-VPLS instance that
      originated the MAC withdraw message.  It will be used to identify
      the C-MAC(s) mapped to the B-MAC(s) listed in the sub-TLV.

   o  PBB I-SID List Sub-TLV:

      Type: 0x0408

      Length: Value length in octets.  Zero indicates an empty I-SID
      list.  An empty I-SID list means that the flushing applies to all
      the I-SIDs mapped to the B-VPLS indicated by the FEC TLV.

      Value: One or a list of 24-bit I-SIDs that represent the
      I-component FIB(s) where the MAC flushing needs to take place.

It should say:

   At least one of the following sub-TLVs MUST be included in the MAC
   Flush Parameters TLV if the C-flag is set to 1:

   o  PBB B-MAC List Sub-TLV:

      Type: 0x01
      Length: Value length in octets.  At least one B-MAC address MUST
      be present in the list.

      Value: One or a list of 48-bit B-MAC addresses.  These are the
      source B-MAC addresses associated with the B-VPLS instance that
      originated the MAC withdraw message.  It will be used to identify
      the C-MAC(s) mapped to the B-MAC(s) listed in the sub-TLV.

   o  PBB I-SID List Sub-TLV:

      Type: 0x02
      Length: Value length in octets.  Zero indicates an empty I-SID
      list.  An empty I-SID list means that the flushing applies to all
      the I-SIDs mapped to the B-VPLS indicated by the FEC TLV.

      Value: One or a list of 24-bit I-SIDs that represent the
      I-component FIB(s) where the MAC flushing needs to take place.

Notes:

Type definition was error. The PBB B-MAC List Sub-TLV abd I-SID List Sub-TLV are only support for one byte, as defined in section 5.1.1 MAC flush parameters TLV.
This error was imported from draft-ietf-l2vpn-vpls-ldp-mac-opt-12. For this version, it submit the 2 sub-tlv to IANA for alloc id. But the two kinds tlv were sub-tlv, not LDP TLV

RFC 7366, "Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", September 2014

Source of RFC: tls (sec)

Errata ID: 4212
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Gutmann
Date Reported: 2014-12-27
Verifier Name: Stephen Farrell
Date Verified: 2015-03-30

Section 3 says:

   In TLS [2] notation, the MAC calculation for TLS 1.0 without
   the explicit Initialization Vector (IV) is:

   MAC(MAC_write_key, seq_num +
       TLSCipherText.type +
       TLSCipherText.version +
       TLSCipherText.length +
       ENC(content + padding + padding_length));

   and for TLS 1.1 and greater with an explicit IV is:

   MAC(MAC_write_key, seq_num +
       TLSCipherText.type +
       TLSCipherText.version +
       TLSCipherText.length +
       IV +
       ENC(content + padding + padding_length));

It should say:

Note that the length value used for the MAC computation differs from 
the value of the 'uint16 length' field in the TLSCiphertext record as 
encoded on the wire.  The encoded TLSCiphertext record contains both 
the ciphtertext and the MAC, while the MAC calculation is performed 
only over the ciphertext.  The length value encoded in the 
TLSCiphertext record is therefore 'length' while the length value 
used in the MAC calculation is 'length - SecurityParameters.mac_length'.

More formally, if:

  TLSCiphertext.enc_content = ENC(content + padding + padding_length)

then in TLS notation the MAC calculation for TLS 1.0 without the 
explicit Initialization Vector (IV) is:

   MAC(MAC_write_key, seq_num +
       TLSCipherText.type +
       TLSCipherText.version +
       length of (TLSCiphertext.enc_content) +
       TLSCiphertext.enc_content);

and for TLS 1.1 and greater with an explicit IV is:

   MAC(MAC_write_key, seq_num +
       TLSCipherText.type +
       TLSCipherText.version +
       length of (IV + TLSCiphertext.enc_content) +
       IV +
       TLSCiphertext.enc_content);

Notes:

After the RFC was published a new set of implementers (who hadn't been part of the pre-publication interop testing) pointed out that the text covering the use of length values could be interpreted in two different ways. This correction attempts to remove the ambiguity by making explicit what's MACd vs. what's encoded on the wire.

RFC 7386, "JSON Merge Patch", October 2014

Note: This RFC has been obsoleted by RFC 7396

Source of RFC: appsawg (app)

Errata ID: 4132
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2014-10-15
Verifier Name: Barry Leiba
Date Verified: 2014-10-16

Section 2 says:

define MergePatch(Target, Patch):
       if Patch is an Object:
         if Target is not an Object:
       Target = {} # Ignore the contents and set it to an empty Object
         for each Name/Value pair in Patch:
       if Value is null:
         if Name exists in Target:
           remove the Name/Value pair from Target
       else:
         Target[Name] = MergePatch(Target[Name], Value)
         return Target
       else:
         return Patch

It should say:

   define MergePatch(Target, Patch):
     if Patch is an Object:
       if Target is not an Object:
         Target = {} # Ignore the contents and set it to an empty Object
       for each Name/Value pair in Patch:
         if Value is null:
           if Name exists in Target:
             remove the Name/Value pair from Target
         else:
           Target[Name] = MergePatch(Target[Name], Value)
       return Target
     else:
       return Patch

Notes:

Indentation of the pseudo-code example was correct in the Internet-Drafts but was messed up in the final version. For instance, "Target = {}" should be under the two ifs. (Reported by James H. Manger on the appsawg mailing list.)

This is a technical erratum, rather than editorial, because the correct indentation is essential to understanding the pseudocode.

RFC 7394, "Definition of Time to Live TLV for LSP-Ping Mechanisms", November 2014

Source of RFC: mpls (rtg)

Errata ID: 4297
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Himanshu Shah
Date Reported: 2015-03-10
Verifier Name: Adrian Farrel
Date Verified: 2015-03-10

Section 3.1 says:

3.1. TTL TLV Format


   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type = 32769                 |   Length = 8                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Value       |   Reserved    |   Flags                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 1: Time To Live TLV Format

It should say:

3.1. TTL TLV Format


   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type = 32769                 |   Length = 4                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Value       |   Reserved    |   Flags                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 1: Time To Live TLV Format

Notes:

In an LSP Ping TTL, Length value should show length of the value fields only. See RFC 4379 section 3.

RFC 7401, "Host Identity Protocol Version 2 (HIPv2)", April 2015

Note: This RFC has been updated by RFC 8002, RFC 9374

Source of RFC: hip (int)

Errata ID: 4408
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tom Henderson
Date Reported: 2015-07-03
Verifier Name: Brian Haberman
Date Verified: 2015-09-14

Section 4.4.4 says:

     .   +---------+  recv I2, send R2                       |         |
   +---->| I1-SENT |--------------------------------------+  |         |
   |     +---------+            +----------------------+  |  |         |
   |          | recv R2,        | recv I2, send R2     |  |  |         |
   |          v send I2         |                      v  v  v         |
   |       +---------+          |                    +---------+       |
   |  +--->| I2-SENT |----------+     +--------------| R2-SENT |<---+  |
   |  |    +---------+                |              +---------+    |  |

It should say:

     .   +---------+  recv I2, send R2                       |         |
   +---->| I1-SENT |--------------------------------------+  |         |
   |     +---------+            +----------------------+  |  |         |
   |          | recv R1,        | recv I2, send R2     |  |  |         |
   |          v send I2         |                      v  v  v         |
   |       +---------+          |                    +---------+       |
   |  +--->| I2-SENT |----------+     +--------------| R2-SENT |<---+  |
   |  |    +---------+                |              +---------+    |  |

Notes:

This state machine figure is informative. Normative (correct) specification for the I1-SENT to I2-SENT state transition (due to recv R1 event) is in Section 6.8.

Errata ID: 6654
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2021-08-04
Verifier Name: Eric Vyncke
Date Verified: 2021-08-05

Section 5.3.3 says:

   If present in the I1 packet, the Initiator MUST include an unmodified
   copy of the R1_COUNTER parameter received in the corresponding R1
   packet into the I2 packet.

It should say:

   If present in the R1 packet, the Initiator MUST include an unmodified
   copy of the R1_COUNTER parameter received in the corresponding R1
   packet into the I2 packet.

Notes:

Packet name error, must be R1

RFC 7404, "Using Only Link-Local Addressing inside an IPv6 Network", November 2014

Source of RFC: opsec (ops)

Errata ID: 4183
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Andreas Cudok
Date Reported: 2014-11-16
Verifier Name: joel jaeggli
Date Verified: 2015-04-20

Section 2.3 says:

Hardware dependency: LLAs have usually been based on 64-bit Extended
Unique Identifiers (EUI-64); hence, they change when the Message
Authentication Code (MAC) address is changed.

It should say:

Hardware dependency: LLAs have usually been based on 64-bit Extended
Unique Identifiers (EUI-64); hence, they change when the Media
Access Control (MAC) address is changed.

Errata ID: 4182
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2014-11-16
Verifier Name: joel jaeggli
Date Verified: 2015-04-20

Section 2.1 says:

Telnet [RFC0495]

It should say:

Telnet [RFC0854]

Notes:

Isn't STD 8 (RFC 854) the official telnet specification?

RFC 7407, "A YANG Data Model for SNMP Configuration", December 2014

Source of RFC: netmod (ops)

Errata ID: 4240
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin Björklund
Date Reported: 2015-01-23
Verifier Name: Benoit Claise
Date Verified: 2015-01-23

Section 4.8 says:

     augment /snmp:snmp/snmp:target {
       when "snmp:v1 or snmp:v2c";

It should say:

     augment /snmp:snmp/snmp:target {

Notes:

The nodes refered to in the "when" expression do not exist.
(They were there in an early draft version, but when they were moved, we forgot to fix the "when" expression).

RFC 7413, "TCP Fast Open", December 2014

Source of RFC: tcpm (wit)

Errata ID: 4238
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Matthew Luckie
Date Reported: 2015-01-22
Verifier Name: Martin Stiemerling
Date Verified: 2015-11-02

Section 4.1.1 says:

   Kind            1 byte: value = 34
   Length          1 byte: range 6 to 18 (bytes); limited by
                           remaining space in the options field.
                           The number MUST be even.
   Cookie          0, or 4 to 16 bytes (Length - 2)

It should say:

   Kind            1 byte: value = 34
   Length          1 byte: range 2 to 18 (bytes); limited by
                           remaining space in the options field.
                           The number MUST be even.
   Cookie          0, or 4 to 16 bytes in length (Length - 2)

Notes:

A Nil cookie is a fast open option with no cookie value. A length range of 6 to 18 bytes excludes a Nil cookie.

Errata ID: 4239
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Matthew Luckie
Date Reported: 2015-01-22
Verifier Name: Martin Stiemerling
Date Verified: 2015-10-31

Section 4.2.1 says:

   1. The client sends a SYN packet with a Fast Open option with a
      Length field of 0 (empty cookie field).

It should say:

   1. The client sends a SYN packet with a Fast Open option with a
      Length field of 2 (empty cookie field).

Notes:

A Nil fast-open option has an option length of 2. A length field of zero would mean an invalid TCP option.

Errata ID: 5373
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Vladimir Nicolici
Date Reported: 2018-05-31
Verifier Name: Mirja Kühlewind
Date Verified: 2018-06-14

Section 4.1.3.1. says:

   For any negative responses, the client SHOULD disable Fast Open on
   the specific path (the source and destination IP addresses and ports)
   at least temporarily.

It should say:

   For any negative responses, the client SHOULD disable Fast Open on
   the specific path (the source and destination IP addresses 
   and the destination port) at least temporarily.

Notes:

The original language seems to imply that the cached negative response should only affect connections if they are initiated from the same source port and source IP.

Since the client source port can change for subsequent TCP connections, and it's unlikely that just changing the source port would result in a successful TCP FO connection when a previous connection from a different source port failed, associating the cached negative response with the source port is probably not very useful, and could actually be detrimental to performance and reliability, depending on the implementation.

If the implementation would decide to check the source port when matching negative cached responses to a new connection, it would negatively impact performance when the source port changes, because the implementation wouldn't find a matching negative response in the cache.

Furthermore, if each connection retry is made from a different source port, checking the source port when matching the cached negative responses would make the client unable to connect to the server, until all possible source ports are included in cached negative responses.

This means it's much better not recommending to associate the source port to the cached negative responses, to prevent any confusion and possible implementation issues.

Either that, or add additional clarification, describing exactly how a negative cached response should be matched to a subsequent connection attempt.

RFC 7420, "Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module", December 2014

Source of RFC: pce (rtg)

Errata ID: 4673
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mahendra Singh Negi
Date Reported: 2016-04-20
Verifier Name: Deborah Brungard
Date Verified: 2016-07-12

Section 4.1 says:

pcePcepSessState OBJECT-TYPE
       SYNTAX      INTEGER {
                      tcpPending(1),
                      openWait(2),
                      keepWait(3),
                      sessionUp(4)
                   }
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The current state of the session.

            The set of possible states excludes the idle state since
            entries do not exist in this table in the idle state."
       ::= { pcePcepSessEntry 3 }

It should say:

pcePcepSessState OBJECT-TYPE
       SYNTAX      INTEGER {
		      idle(0),
                      tcpPending(1),
                      openWait(2),
                      keepWait(3),
                      sessionUp(4)
                   }
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The current state of the session."
       ::= { pcePcepSessEntry 3 }	

Notes:

As per security consideration, if PCE needs to allow incomming connections from only known PCCs.
Source addresses of PCCs are configured on PCE. If PCEP session on PCE goes down with configured PCCs.
PCE needs to raise notification pcePcepSessDown (i.e. details mentioned below).
Issue is whiling sending the notification pcePcepSessDown, as session state (pcePcepSessState) defined in RFC doesn't include idle state.
I suggest to include idle(0) state for pcePcepSessState.


pcePcepSessDown NOTIFICATION-TYPE
OBJECTS {
pcePcepSessState,
pcePcepSessStateLastChange
}
STATUS current
DESCRIPTION
"This notification is sent when the value of
pcePcepSessState leaves the sessionUp state."
::= { pcePcepNotifications 2 }

RFC 7422, "Deterministic Address Mapping to Reduce Logging in Carrier-Grade NAT Deployments", December 2014

Source of RFC: INDEPENDENT

Errata ID: 4211
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2014-12-26
Verifier Name: Nevil Brownlee
Date Verified: 2015-02-17

Section 2.3 says:

As noted in RFC 6292 [RFC6292], accurate timekeeping
   (e.g., use of NTP or Simple NTP) is vital).

It should say:

As noted in RFC 6269 [RFC6269], accurate timekeeping
   (e.g., use of NTP or Simple NTP) is vital.

RFC 7426, "Software-Defined Networking (SDN): Layers and Architecture Terminology", January 2015

Source of RFC: IRTF

Errata ID: 5301
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2018-03-24
Verifier Name: RFC Editor
Date Verified: 2018-03-27

Section 3.1 says:

   All planes mentioned above are connected via interfaces (indicated
   with "Y" in Figure 1.  An interface may take multiple roles depending
   on whether the connected planes reside on the same (physical or
   virtual) device.  If the respective planes are designed so that they
   do not have to reside in the same device, then the interface can only
   take the form of a protocol.  If the planes are collocated on the

It should say:

   All planes mentioned above are connected via interfaces (indicated
   with "Y" in Figure 1). An interface may take multiple roles depending
   on whether the connected planes reside on the same (physical or
   virtual) device.  If the respective planes are designed so that they
   do not have to reside in the same device, then the interface can only
   take the form of a protocol.  If the planes are collocated on the

Notes:

The closing bracket is missing in the second line.

RFC 7430, "Analysis of Residual Threats and Possible Fixes for Multipath TCP (MPTCP)", July 2015

Source of RFC: mptcp (tsv)

Errata ID: 4565
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Fabrizio Demaria
Date Reported: 2015-12-14
Verifier Name: Martin Stiemerling
Date Verified: 2016-01-12

Section 6 says:

   Summary of the attack:

      Type of attack: An attacker that can intercept the SYN/JOIN
      message can alter the source address being added.

      Type of attacker: partial-time on-path eavesdropper

   Description:

   The attacker is present along the path when the SYN/JOIN exchange
   takes place.  This allows the attacker to add any new address it
   wants to by simply substituting the source address of the SYN/JOIN
   packet for one it chooses.  This vulnerability was readily identified
   when designing the MPTCP security solution [RFC6181], and the threat
   was considered acceptable.

It should say:

   Summary of the attack:

      Type of attack: An attacker that can intercept the SYN/JOIN
      message can alter the source address being added.

      Type of attacker: partial-time on-path active attacker

   Description:

   The attacker is present along the path when the SYN/JOIN exchange
   takes place.  This allows the attacker to add any new address it
   wants to by simply substituting the source address of the SYN/JOIN
   packet for one it chooses.  This vulnerability was readily identified
   when designing the MPTCP security solution [RFC6181], and the threat
   was considered acceptable.

Notes:

As noted in section 1, an active attacker is able to change, discard, or delay some of the packets of the MPTCP session. This coincide with the description of the SYN/JOIN attack in section 6.

RFC 7432, "BGP MPLS-Based Ethernet VPN", February 2015

Note: This RFC has been updated by RFC 8584, RFC 9161

Source of RFC: l2vpn (rtg)

Errata ID: 5554
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ali Sajassi
Date Reported: 2018-11-16
Verifier Name: Martin Vigoureux
Date Verified: 2018-11-27

Section 7 says:

Clarifications to following sub-sections:
Section 7.1
Section 7.2
Section 7.5

It should say:

Section 7.1:
Add below text to the section 7.1 regarding the encoding
of MPLS label field:

"The value of the 20-bit MPLS label is encoded in the high-order 
20 bits of the 3 octets MPLS Label field."

Section 7.2:
Add below text to the section 7.2 regarding the encoding 
of both the MPLS label fields:

"The value of the 20-bit MPLS label is encoded in the high-order
20 bits of the 3 octets MPLS Label1 and MPLS Label2 fields."

Section 7.5:
Add below text to the section 7.5 regarding the encoding of 
ESI Label field:

"The value of the 20-bit MPLS label is encoded in the high-order
20 bits of the 3 octets ESI Label field."

Notes:

MPLS label is a 20-bit value and is stored in a 3 bytes field in a packet.
The 20-bit MPLS label value is generally stored in higher order 20 bits
of the 3 octet label field. The exact encoding to be followed for storing
MPLS label values are not explicitly mentioned in the RFC 7432 under
section 7.1, 7.2 and 7.5 for different types of EVPN routes. This lead to
ambiguity in different implementations. Hence a clarification is required.

RFC 7434, "Interworking ISDN Call Control User Information with SIP", January 2015

Source of RFC: cuss (rai)

Errata ID: 4242
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: RFC Editor
Date Reported: 2015-01-26
Verifier Name: Ben Campbell
Date Verified: 2015-06-10

Section 13 says:

      ASN.1 Identifier: 1.3.6.1.8.4.x

It should say:

      ASN.1 Identifier: 1.3.6.1.8.4.26

Notes:

The IANA-assigned value should be filled in.

RFC 7439, "Gap Analysis for Operating IPv6-Only MPLS Networks", January 2015

Source of RFC: mpls (rtg)

Errata ID: 4595
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Adrian Farrel
Date Reported: 2016-01-15
Verifier Name: Deborah Brungard
Date Verified: 2016-02-08

Section 3.5 says:

   RFC 3811 [RFC3811] defines the textual conventions for MPLS.  These
   lack support for IPv6 in defining MplsExtendedTunnelId and
   MplsLsrIdentifier.  These textual conventions are used in the MPLS-TE
   MIB specification [RFC3812], the GMPLS-TE MIB specification [RFC4802]
   and the FRR extension [RFC6445].  "Definitions of Textual Conventions
   (TCs) for Multiprotocol Label Switching (MPLS) Management" [MPLS-TC]
   tries to resolve this gap by marking this textual convention as
   obsolete.

It should say:

   RFC 3811 [RFC3811] defines the textual conventions for MPLS.  These
   lack support for IPv6 in defining MplsExtendedTunnelId.  This textual
   conventions is used in the MPLS-TE MIB specification [RFC3812], the 
   GMPLS-TE MIB specification [RFC4802], and the FRR extension
   [RFC6445].  "Definitions of Textual Conventions (TCs) for 
   Multiprotocol Label Switching (MPLS) Management" [MPLS-TC] tries
   to resolve this gap by marking this textual convention as obsolete.

Notes:

Section 3.5 comments about MplsLsrIdentifier.
It says that RFC 3811 "lack[s] support for IPv6 in defining MplsExtendedTunnelId and MplsLsrIdentifier." It also says that "[MPLS-TC] tries to resolve this gap by marking this textual convention as obsolete."

Note that the second quote refers to just one TC.

Looking at 3811, 5036, and (most importantly) 7552, it seems to me that the LSR Identifier is *always* a 32 bit quantity regardless of whether the LDP system is v4-only, v4/v6, or v6-only.

Furthermore, draft-manral-mpls-rfc3811bis (i.e., [MPLS-TC]) clearly shows no
change to MplsLsrIdentifier while marking MplsExtendedTunnelId as obsolete.

Notwithstanding that draft-manral-mpls-rfc3811bis appears to have been abandoned in state "candidate for WG adoption", it looks to me that RFC 7439 has an error we could call a typo.

RFC 7457, "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)", February 2015

Source of RFC: uta (sec)

Errata ID: 4403
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sebastian Schinzel
Date Reported: 2015-06-28
Verifier Name: Stephen Farrell
Date Verified: 2015-06-29

Section 2.7 says:

While the Bleichenbacher attack has been mitigated in TLS 1.0,
the Klima attack, which relies on a version-check oracle, is only
mitigated by TLS 1.1.

It should say:

The Bleichenbacher attack has been first addressed in TLS 1.0. This
mitigation closed the error message-based attack, but opened a
potentially exploitable timing leak [*] which has been addressed in
TLS 1.2. The Klima attack, which relies on a version-check oracle,
is mitigated by TLS 1.1.

[*]: Revisiting SSL/TLS Implementations: New Bleichenbacher Side
Channels and Attacks. Meyer, Somorovsky, Weiss, Schwenk, Schinzel,
Tews.  23rd Usenix Security Symposium 2014.

Notes:

RFC 7457 states: "While the Bleichenbacher attack has been mitigated
in TLS 1.0, the Klima attack, which relies on a version-check oracle,
is only mitigated by TLS 1.1."

RFC 2246 (TLS 1.0) states: "The best way to avoid vulnerability
to this attack is to treat incorrectly formatted messages in a
manner indistinguishable from correctly formatted RSA blocks. Thus,
when it receives an incorrectly formatted RSA block, a server should
generate a random 48-byte value and proceed using it as the premaster
secret. Thus, the server will act identically whether the received
RSA block is correctly encoded or not."

This does not safely prevent Bleichenbacher style attacks. To rephrase
it: implementations should generate and proceed with a random PMS
if (implied "*and only if*") an incorrectly formatted message was
received. This opens a timing side channel that we successfully
exploited in several TLS implementations that comply with RFC 2246
(see [1], [2]).

This timing side channel was first addressed in TLS 1.2 (RFC 5246),
which gives the following timing-constant algorithm to prevent
Bleichenbacher's attack: "1. Generate a string R of 46 random bytes
2. Decrypt the message to recover the plaintext M 3. If the PKCS#1
padding is not correct, or the length of message
M is not exactly 48 bytes:
pre_master_secret = ClientHello.client_version || R
else If ClientHello.client_version <= TLS 1.0, and version
number check is explicitly disabled:
pre_master_secret = M
else:
pre_master_secret = ClientHello.client_version || M[2..47]"

Thus, it is not TLS 1.0 which safely prevents Bleichenbacher attacks,
but TLS 1.2.

RFC 7464, "JavaScript Object Notation (JSON) Text Sequences", February 2015

Source of RFC: json (app)

Errata ID: 5860
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Benjamin Kaduk
Date Reported: 2019-09-18
Verifier Name: Alexey Melnikov
Date Verified: 2019-09-23

Section 2.2 says:

   Note that on some systems it"s possible to input RS by typing

It should say:

   Note that on some systems it's possible to input RS by typing

Notes:

The contraction "it's" needs a single apostrophe, not a double-quote mark.

RFC 7468, "Textual Encodings of PKIX, PKCS, and CMS Structures", April 2015

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 4508
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sean Leonard
Date Reported: 2015-10-20
Verifier Name: Stephen Farrell
Date Verified: 2016-06-10

Section 3 says:

  preeb      = "-----BEGIN " label "-----" ; unlike [RFC1421] (A)BNF,
                                           ; eol is not required (but
  posteb     = "-----END " label "-----"   ; see [RFC1421], Section 4.4)

It should say:

  preeb      = "-----" %x42.45.47.49.4E " " label "-----" 

  posteb     = "-----" %x45.4E.44 " " label"-----"
                         ; unlike [RFC1421] (A)BNF, eol is not required
                         ; (but see [RFC1421], Section 4.4)

OR:

  preeb      = %s"-----BEGIN " label "-----" ; unlike [RFC1421] (A)BNF,
                                             ; eol is not required (but
  posteb     = %s"-----END " label "-----"   ; see [RFC1421],
                                             ; Section 4.4)

...with reference to RFC 7405.

Notes:

The encapsulation boundaries are case-sensitive, including (especially) the BEGIN and END characters. Nearly all implementations enforce the case sensitivity of BEGIN and END on input, and all surveyed implementations output all-caps.

RFC 7469, "Public Key Pinning Extension for HTTP", April 2015

Source of RFC: websec (app)

Errata ID: 4354
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kirit Saelensminde
Date Reported: 2015-05-04
Verifier Name: Barry Leiba
Date Verified: 2015-05-05

Section 3 says:

   As in Section 2.4, the token refers to the algorithm name, and the
   quoted-string refers to the base64 encoding of the SPKI Fingerprint.
   When formulating the JSON POST body, the UA MUST either use single-
   quoted JSON strings or use double-quoted JSON strings and backslash-
   escape the embedded double quotes in the quoted-string part of the
   known-pin.

....

      'pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM="',

It should say:

   As in Section 2.4, the token refers to the algorithm name, and the
   quoted-string refers to the base64 encoding of the SPKI Fingerprint.
   When formulating the JSON POST body, the UA MUST use double-quoted
   JSON strings and backslash-escape the embedded double quotes in the
   quoted-string part of the known-pin.

....

      "pin-sha256=\"d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM=\"",

Notes:

This RFC seems to think that single quotes are permissible in JSON. This is not the case. See http://tools.ietf.org/html/rfc7159#section-7

Errata ID: 4658
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jxck
Date Reported: 2016-04-08
Verifier Name: Barry Leiba
Date Verified: 2016-04-08

Section 3. Reporting Pin Validation Failure says:

  {
    "date-time": "2014-04-06T13:00:50Z",
    "hostname": "www.example.com",
    "port": 443,
    "effective-expiration-date": "2014-05-01T12:40:50Z"

It should say:

  {
    "date-time": "2014-04-06T13:00:50Z",
    "hostname": "www.example.com",
    "port": 443,
    "effective-expiration-date": "2014-05-01T12:40:50Z",
 

Notes:

Missing comma after "effective-expiration-date": "2014-05-01T12:40:50Z" in JSON at Figure 8: Pin Validation Failure Report Example

RFC 7477, "Child-to-Parent Synchronization in DNS", March 2015

Source of RFC: dnsop (ops)

Errata ID: 4307
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Donald Eastlake 3rd
Date Reported: 2015-03-19
Verifier Name: Kathleen Moriarty
Date Verified: 2015-03-31

Section sec 2, page 4 says:

nonpunishable data

It should say:

nonpublishable data

Notes:

confusing typo, confirmed with author.

RFC 7479, "Using Ed25519 in SSHFP Resource Records", March 2015

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 4328
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2015-04-05
Verifier Name: Stephen Farrell
Date Verified: 2015-04-05

Section 2 says:

    ssh.example.com IN SSHFP 4 2 ( a87f1b687ac0e57d2a081a2f2826723
                                     34d90ed316d2b818ca9580ea384d924
                                     01 )

It should say:

    ssh.example.com. IN SSHFP 4 2 ( a87f1b687ac0e57d2a081a2f2826723
                                     34d90ed316d2b818ca9580ea384d924
                                     01 )

Notes:

There was a missing "." after .com

Otherwise, the name server will complete the relative name, with unexpected results. (Yes, I know, it depends on how the $ORIGIN is set. Nevertheless, it is strange.)

RFC 7482, "Registration Data Access Protocol (RDAP) Query Format", March 2015

Note: This RFC has been obsoleted by RFC 9082

Source of RFC: weirds (app)

Errata ID: 5621
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Klensin
Date Reported: 2019-02-01
Verifier Name: Adam Roach
Date Verified: 2019-03-05

Section 2.1 says:

IDN: Internationalized Domain Name

IDNA: Internationalized Domain Names in Applications, a protocol
      for the handling of IDNs.

It should say:

IDN: Internationalized Domain Name, a [fully-qualified] domain name
containing one or more labels that are intended to include one or more
Unicode code points outside the ASCII range (cf. "domain name",
"fully-qualified domain name" and "internationalized domain name" in
RFC 8499).

IDNA: Internationalized Domain Names in Applications, a protocol for
the handling of IDNs.  In this document, "IDNA" refers specifically to
the version of those specifications known as "IDNA2008" [RFC5980].

Notes:

While the proposed new text above borders on the painfully pedantic, failure to be specific about these things undermines the technical validity and consistency of the text (making this a technical issue rather than exclusively an editorial one like a missing reference). IDNA2008 [RFC5890 Section 2.3.2.3] is very precise about what an "IDN" is (a definition incorporated by reference in RFC 6365 and consistent with the definition in RFC 8499) , but there are other things around that, e.g., assume either that "IDN" refers to a label, not an FQDN; that an ASCII label, even one in ACE form, does not make the FQDN in which it is imbedded an IDN; that all of the label components of an IDN must be U-labels or A-labels, etc. Without the definition being clear, some of the statements in the document make no sense.

A reference to 8499 is suggested above because it is the most recent authoritative definition (and because I didn't write it), but 5980 would be equally legitimate if the authors prefer.

Pinning down the IDNA definition is even more important. While there are IDNA2008 references further on in the document, if the question of what the generic term "IDNA" means is left to the imagination of the reader, then the specification is missing language about what to do if, e.g., a query is inconsistent with the U-label form of what is stored in the registry database without mapping. The opportunity for that sort of problem is clearly created by the "performs any local case mapping deemed necessary" statement in Section 6.1 of the document, at least unless that case mapping is constrained to not be applied to domain name labels (which the text definitely does not say).

RFC 7483, "JSON Responses for the Registration Data Access Protocol (RDAP)", March 2015

Note: This RFC has been obsoleted by RFC 9083

Source of RFC: weirds (app)

Errata ID: 4503
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Scott Hollenbeck
Date Reported: 2015-10-14
Verifier Name: Barry Leiba
Date Verified: 2016-01-21

Section 5.2 and 5.3 says:

In Section 5.2:

"ldhName" : "ns1.xn--fo-5ja.example",
"unicodeName" : "ns1.foo.example",

In Section 5.3:

"ldhName" : "xn--fo-5ja.example",
"unicodeName" : "foo.example",

"ldhName" : "xn--fo-cka.example",
"unicodeName" : "foo.example"

"ldhName" : "xn--fo-fka.example",
"unicodeName" : "foo.example"

"ldhName": "xn--fo-8ja.example",
"unicodeName" : "foo.example"

It should say:

In Section 5.2:

"ldhName" : "ns1.xn--fo-5ja.example",
"unicodeName" : "ns1.fóo.example",

In Section 5.3:

"ldhName" : "xn--fo-5ja.example",
"unicodeName" : "fóo.example",

"ldhName" : "xn--fo-cka.example",
"unicodeName" : "fõo.example"

"ldhName" : "xn--fo-fka.example",
"unicodeName" : "föo.example"

"ldhName" : "xn--fo-8ja.example",
"unicodeName" : "fôo.example"

Notes:

The unicodeName examples in RFC 7483 are invalid per RFC 5890. Here's an example from Section 5.2 on page 23:

"unicodeName" : "ns1.foo.example",

Section 3 of 7483 says this about Unicode names:

"Unicode names: Textual representations of DNS names where one or more of the labels are U-labels as described by [RFC5890]."

5890 says: "A "U-label" is an IDNA-valid string of Unicode characters, in Normalization Form C (NFC) and including at least one non-ASCII character, expressed in a standard Unicode Encoding Form (such as UTF-8)."

The examples in 7483 contain all ASCII characters. Syntactically valid examples are shown in the corrected text.

RFC 7484, "Finding the Authoritative Registration Data (RDAP) Service", March 2015

Note: This RFC has been obsoleted by RFC 9224

Note: This RFC has been updated by RFC 8521

Source of RFC: weirds (app)

Errata ID: 5460
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Pieter Vandepitte
Date Reported: 2018-08-14
Verifier Name: Murray Kucherawy
Date Verified: 2021-12-02

Section 8 says:

      In the case of a domain object, the client may first query the DNS
      to see if the respective entry has been delegated or if it is
      mistyped information by the user.  The DNS query could be to fetch
      the NS records for the TLD domain.  If the DNS answer is negative,
      then there is no need to fetch the new version of the registry.
      However, if the DNS answer is positive, this may mean that the
      currently cached registry is no longer current.  The client could
      then fetch the registry, parse, and then do the normal matching as
      specified above.  This method may not work for all types of RDAP
      objects.

Notes:

I would remove the whole section. The point is: if the DNS answer is positive, then you need to fetch the registry. But if the answer is negative, this does not mean anything because it it possible that a registered domain is not delegated.

Errata ID: 5461
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Pieter Vandepitte
Date Reported: 2018-08-14
Verifier Name: Murray Kucherawy
Date Verified: 2021-12-02

Section 4 says:

{
       "version": "1.0",
       "publication": "YYYY-MM-DDTHH:MM:SSZ",
       "description": "Some text",
       "services": [
         [
           ["net", "com"],
           [
             "https://registry.example.com/myrdap/"
           ]
         ],
         [
           ["org", "mytld"],
           [
             "http://example.org/"
           ]
         ],
         [
           ["xn--zckzah"],
           [
             "https://example.net/rdapxn--zckzah/",
             "http://example.net/rdapxn--zckzah/"
           ]
         ]
       ]
   }

It should say:

{
       "version": "1.0",
       "publication": "YYYY-MM-DDTHH:MM:SSZ",
       "description": "Some text",
       "services": [
         [
           ["net", "com"],
           [
             "https://registry.example.com/myrdap/"
           ]
         ],
         [
           ["org", "mytld"],
           [
             "http://example.org/"
           ]
         ],
         [
           ["xn--zckzah"],
           [
             "https://example.net/rdap/xn--zckzah/",
             "http://example.net/rdap/xn--zckzah/"
           ]
         ]
       ]
   }

Notes:

Include a slash between rdap and xn--zckzah. rdapxn--zckzah is not a valid a-label

RFC 7489, "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", March 2015

Note: This RFC has been updated by RFC 8553, RFC 8616

Source of RFC: INDEPENDENT

Errata ID: 5365
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Gary Palmer
Date Reported: 2018-05-22
Verifier Name: Eliot Lear (ISE)
Date Verified: 2022-09-30

Section 7.2.1.1 says:

     mail.receiver.example!example.com!1013662812!1013749130.gz

It should say:

     mail.receiver.example!example.com!1013662812!1013749130.xml.gz

Notes:

The specification states that the suffix should be "xml" for an uncompressed file, and "xml.gz" for a compressed file. The example filename is missing the "xml" component of the suffix

Errata ID: 5371
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Cris van Pelt
Date Reported: 2018-05-28
Verifier Name: Eliot Lear (ISE)
Date Verified: 2022-09-30

Section 7.2.1.1 says:

The aggregate data MUST be an XML file that SHOULD be subjected to
GZIP compression.

It should say:

The aggregate data MUST be an XML file that SHOULD be subjected to
GZIP compression (described in [RFC1952]).

Notes:

The term "GZIP compression" is not defined in the text. To clarify, maintain compatibility with future (potentially incompatible) gzip versions, and to bring the document in line with other RFCs (e.g. 3712, 6713, 6968), a reference to RFC 1952 ("GZIP file format specification version 4.3") should be added.

This is assuming RFC 1952 was the author's intent.

Errata ID: 5440
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Levine
Date Reported: 2018-07-25
Verifier Name: Adrian Farrel
Date Verified: 2018-07-26

Section 7.1, B.2.1, B.2.3, B.2.4 says:

==7.1==
In particular, the "v=DMARC1" tag is

comes back containing a tag of "v=DMARC1",

containing at least "v=DMARC1"

==B.2.1==

The version of DMARC being used is "DMARC1" ("v=DMARC1")

==B.2.3==

with the value "=DMARC1".

     % dig +short TXT example.com._report._dmarc.thirdparty.example.net
     "v=DMARC1"

     example.com._report._dmarc   IN   TXT    "v=DMARC1"

==B.2.4==

        o  The version of DMARC being used is "DMARC1" ("v=DMARC1")

It should say:

==7.1==
In particular, the "v=DMARC1;" tag is

comes back containing a tag of "v=DMARC1;",

containing at least "v=DMARC1;"

==B.2.1==

The version of DMARC being used is "DMARC1" ("v=DMARC1;")

==B.2.3==

with the value "v=DMARC1;".

     % dig +short TXT example.com._report._dmarc.thirdparty.example.net
     "v=DMARC1;"

     example.com._report._dmarc   IN   TXT    "v=DMARC1;"

==B.2.4==

   o  The version of DMARC being used is "DMARC1" ("v=DMARC1;")

Notes:

The ABNF of dmarc-record in section 6.4 says that there has to be a semicolon after v=DMARC1, but several of the examples for the _report._dmarc record are missing the semicolon.

Errata ID: 6439
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Norton
Date Reported: 2021-02-23
Verifier Name: Adrian Farrel
Date Verified: 2021-02-24

Section 7.1 says:

For example, if a DMARC policy query for "blue.example.com" contained
"rua=mailto:reports@red.example.net", the host extracted from the
latter ("red.example.net") does not match "blue.example.com", so this
procedure is enacted.

It should say:

For example, if a DMARC policy query for "blue.example.com" contained
"rua=mailto:reports@red.example.net", the Organizational Domain of the
host extracted from the latter ("example.net") does not match the
Organizational Domain "example.com", so this procedure is enacted.

Notes:

Section 7.1 (third paragraph) is clear that it is the Organizational Domains which are to be compared in order to make a determination on the need to perform validation steps. The example incorrectly makes this determination by comparing the hostnames instead of the Organizational Domains.

RFC 7508, "Securing Header Fields with S/MIME", April 2015

Source of RFC: INDEPENDENT

Errata ID: 5875
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2019-10-15
Verifier Name: Adrian Farrel
Date Verified: 2019-11-06

Section Appendix A says:

     mod-SMimeSecureHeadersV1
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
       pkcs-9(9) smime(16) modules(0) secure-headers-v1(65) }

     DEFINITIONS IMPLICIT TAGS ::=

     BEGIN

It should say:

     Mod-SMimeSecureHeadersV1
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
       pkcs-9(9) smime(16) modules(0) secure-headers-v1(65) }

     DEFINITIONS IMPLICIT TAGS ::=

     BEGIN

Notes:

The ASN.1 module name must begin with a capital letter.

RFC 7510, "Encapsulating MPLS in UDP", April 2015

Source of RFC: mpls (rtg)

Errata ID: 4350
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Adrian Farrel
Date Reported: 2015-04-27
Verifier Name: Alia Atlas
Date Verified: 2015-04-28

Section 7 says:

Absent

It should say:

7.1  BGP Tunnel Encapsulation Attribute Tunnel Type

   IANA maintains a registry called "Border Gateway Protocol (BGP)
   Parameters" with a sub-registry called "BGP Tunnel Encapsulation
   Attribute Tunnel Types".  IANA has previously allocated a code point
   called "MPLS in UDP Encapsulation" with value 13. IANA has added
   this document as a further reference for that code point.

Notes:

This text reflects a pre-publication agreement to include a request to IANA for the action that it describes.

Note that the text supplied here shows the use of the past tense as is normal in an RFC that reports IANA action.

RFC 7511, "Scenic Routing for IPv6", April 2015

Source of RFC: INDEPENDENT

Errata ID: 4322
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Joe Klein
Date Reported: 2015-04-01
Verifier Name: Nevil Brownlee
Date Verified: 2015-06-30

Section 4 says:

It should say:

Additional security considerations of overexposure to solar 
radiation, or buffer-bloat in culturally important places, 
leading to excessive delayed packets, directly attributed
to forgetting sunscreen, excessive adult beverages, etc, 
WILL result in a decreased reliability.

There are no actions requested at this time.

Errata ID: 4321
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Brian Carpenter
Date Reported: 2015-04-01
Verifier Name: Nevil Brownlee
Date Verified: 2015-06-30

Section 2.1 says:

0 - Don't use Avian IP Carrier links (maybe the packet is
    afraid of pigeons).

It should say:

0 - Don't use Avian IP Carrier links (maybe the packet is
    afraid of avians).

Notes:

Neither RFC 1149 nor RFC 6214 mandates any particular species. If it is
required to specify a given species, an additional Species ID field
would be needed in the option.

Errata ID: 4325
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: André Melancia
Date Reported: 2015-04-02
Verifier Name: Nevil Brownlee
Date Verified: 2015-06-30

Section 1 says:

This document defines another way to deal with Green IT for traffic
and network engineers and will hopefully aid the wellbeing of a
myriad of network packets around the world.  It proposes Scenic
Routing, which incorporates the green-ness of a network path into the
routing decision.  A routing engine implementing Scenic Routing
should therefore choose paths based on Avian IP Carriers [RFC1149]
and/or wireless technologies so the packets will get out of the
miles/kilometers of dark fibers that are in the ground and get as
much fresh-air time and sunlight as possible.

It should say:

This document defines another way to deal with Green IT for traffic
and network engineers and will hopefully aid the wellbeing of a
myriad of network packets around the world.  It proposes Scenic
Routing, which incorporates the green-ness of a network path into the
routing decision.  A routing engine implementing Scenic Routing
should therefore choose paths based on IP over Avian Carriers with
Quality of Service [RFC2549] and/or wireless technologies so the 
packets will get out of the miles/kilometers of dark fibers that are
in the ground and get as much fresh-air time and sunlight as possible.

Notes:

Although RFC2549 ("IP over Avian Carriers with Quality of Service") does not obsolete RFC1149, the recommendations in the former improve Scenic Routing quality considerably, contributing to a subsequently more positive result in the TCP Mood option defined in [RFC5841].

Errata ID: 4333
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: William ML Leslie
Date Reported: 2015-04-12
Verifier Name: Nevil Brownlee
Date Verified: 2015-06-30

Section 2 says:

      The lowest-order two bits (XY) are currently unused and reserved
      for future use.

It should say:

      The lowest-order two bits (XY) are currently unused and reserved
      for a rainy day.

Notes:

Packets should be free to use spare SRO parameter bits during work hours (for bits in leu) or in their own spare time.

RFC 7518, "JSON Web Algorithms (JWA)", May 2015

Source of RFC: jose (sec)

Errata ID: 6612
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sebastián Ramírez
Date Reported: 2021-06-16
Verifier Name: Benjamin Kaduk
Date Verified: 2021-06-25

Section .4 says:

   2.  Turn R and S into octet sequences in big-endian order, with each
       array being be 32 octets long.  The octet sequence
       representations MUST NOT be shortened to omit any leading zero
       octets contained in the values.

It should say:

   2.  Turn R and S into octet sequences in big-endian order, with each
       array being 32 octets long.  The octet sequence
       representations MUST NOT be shortened to omit any leading zero
       octets contained in the values.

Notes:

"being be" should be changed to "being"

RFC 7525, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", May 2015

Note: This RFC has been obsoleted by RFC 9325

Note: This RFC has been updated by RFC 8996

Source of RFC: uta (sec)

Errata ID: 4353
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Xiaoyin Liu
Date Reported: 2015-05-04
Verifier Name: Barry Leiba
Date Verified: 2015-05-07

Section 7.2 says:

[RFC7507]  Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher
           Suite Value (SCSV) for Preventing Protocol Downgrade
           Attacks", RFC 7507, April 2015.

It should say:

[RFC7507]  Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher
           Suite Value (SCSV) for Preventing Protocol Downgrade
           Attacks", RFC 7507, April 2015,
           <http://www.rfc-editor.org/info/rfc7507>.

Notes:

The original text lacks the link to the RFC7507 information page.

Errata ID: 5685
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Thijs Alkemade
Date Reported: 2019-04-05
Verifier Name: RFC Editor
Date Verified: 2024-02-15

Section 7 says:

   [TLS-XMPP] Saint-Andre, P. and a. alkemade, "Use of Transport Layer
              Security (TLS) in the Extensible Messaging and Presence
              Protocol (XMPP)", Work in Progress,
              draft-ietf-uta-xmpp-07, April 2015.

It should say:

   [TLS-XMPP] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer
              Security (TLS) in the Extensible Messaging and Presence
              Protocol (XMPP)", Work in Progress,
              draft-ietf-uta-xmpp-07, April 2015.

Notes:

Fixed my name.

RFC 7530, "Network File System (NFS) Version 4 Protocol", March 2015

Note: This RFC has been updated by RFC 7931, RFC 8587

Source of RFC: nfsv4 (wit)

Errata ID: 4471
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Marcel Telka
Date Reported: 2015-09-12
Verifier Name: Martin Stiemerling
Date Verified: 2015-12-16

Section 16.10.4. says:

   In the case that the lock is denied, the owner, offset, and length of
   a conflicting lock are returned.

It should say:

   In the case that the lock is denied, the owner, offset, length, and
   type of a conflicting lock are returned.

Notes:

The locktype in LOCK4denied is not specified for the LOCK operation. See 16.11.4. for similar wording for LOCKT.

Errata ID: 4329
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marcel Telka
Date Reported: 2015-04-07
Verifier Name: Martin Stiemerling
Date Verified: 2015-04-17

Section 21.1. says:

   [openg_symlink]
              The Open Group, "Section 3.372 of Chapter 3 of Base
              Definitions of The Open Group Base Specifications
              Issue 7", IEEE Std 1003.1, 2013 Edition (HTML Version),
              ISBN 1937218287, April 2013, <http://www.opengroup.org/>.

It should say:

   [openg_symlink]
              The Open Group, "Section 3.375 of Chapter 3 of Base
              Definitions of The Open Group Base Specifications
              Issue 7", IEEE Std 1003.1, 2013 Edition (HTML Version),
              ISBN 1937218287, April 2013, <http://www.opengroup.org/>.

Errata ID: 5471
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tigran Mkrtchyan
Date Reported: 2018-08-18
Verifier Name: RFC Editor
Date Verified: 2024-02-02

Section 16.16.5 says:

 o  NFS4ERR_BAD_RECLAIM is returned if the other error conditions do
      not apply and the server has no record of the delegation whose
      reclaim is being attempted.

It should say:

 o  NFS4ERR_RECLAIM_BAD is returned if the other error conditions do
      not apply and the server has no record of the delegation whose
      reclaim is being attempted.

Notes:

The the defined error is NFS4ERR_RECLAIM_BAD


---
RFC Editor Note: This also appears in Section 10.2.1. See https://www.rfc-editor.org/errata/eid5472.

Errata ID: 5472
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tigran Mkrtchyan
Date Reported: 2018-08-18
Verifier Name: RFC Editor
Date Verified: 2024-02-02

Section 10.2.1 says:

   When NFS4ERR_EXPIRED is returned, the server MAY retain information
   about the delegations held by the client, deleting those that are
   invalidated by a conflicting request.  Retaining such information
   will allow the client to recover all non-invalidated delegations
   using the claim type CLAIM_DELEGATE_PREV, once the
   SETCLIENTID_CONFIRM is done to recover.  Attempted recovery of a
   delegation that the client has no record of, typically because they
   were invalidated by conflicting requests, will result in the error
   NFS4ERR_BAD_RECLAIM.  Once a reclaim is attempted for all delegations
   that the client held, it SHOULD do a DELEGPURGE to allow any
   remaining server delegation information to be freed.

It should say:

   When NFS4ERR_EXPIRED is returned, the server MAY retain information
   about the delegations held by the client, deleting those that are
   invalidated by a conflicting request.  Retaining such information
   will allow the client to recover all non-invalidated delegations
   using the claim type CLAIM_DELEGATE_PREV, once the
   SETCLIENTID_CONFIRM is done to recover.  Attempted recovery of a
   delegation that the client has no record of, typically because they
   were invalidated by conflicting requests, will result in the error
   NFS4ERR_RECLAIM_BAD.  Once a reclaim is attempted for all delegations
   that the client held, it SHOULD do a DELEGPURGE to allow any
   remaining server delegation information to be freed.

Notes:

The defined error code is NFS4ERR_RECLAIM_BAD


--
RFC Editor Note: This also appears in 16.16.5. See https://www.rfc-editor.org/errata/eid5471.

RFC 7539, "ChaCha20 and Poly1305 for IETF Protocols", May 2015

Note: This RFC has been obsoleted by RFC 8439

Source of RFC: IRTF

Errata ID: 4371
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Adam Eijdenberg
Date Reported: 2015-05-21
Verifier Name: Lars Eggert
Date Verified: 2015-06-03

Section 2.8.1 says:

         mac_data |= num_to_4_le_bytes(aad.length)
         mac_data |= num_to_4_le_bytes(ciphertext.length)

It should say:

         mac_data |= num_to_8_le_bytes(aad.length)
         mac_data |= num_to_8_le_bytes(ciphertext.length)

Notes:

Per section 2.8 the lengths should be 64-bit (8 bytes), not 4.

After this change the pseudo-code output matches the test vectors shown in 2.8.2.

Errata ID: 4700
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin Thomson
Date Reported: 2016-05-24
Verifier Name: Lars Eggert
Date Verified: 2016-06-08

Section 2.8 says:

    The output from the AEAD is twofold:

   o  A ciphertext of the same length as the plaintext.
   o  A 128-bit tag, which is the output of the Poly1305 function.

It should say:

    The output from the AEAD is the concatenation of:

   o  A ciphertext of the same length as the plaintext.
   o  A 128-bit tag, which is the output of the Poly1305 function.

Notes:

Section 2.1 of RFC 5116 defines the AEAD interface, and that interface produces a single output, C (or an error).

Errata ID: 4858
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Timm Korte
Date Reported: 2016-11-10
Verifier Name: Lars Eggert
Date Verified: 2016-11-13

Section 2.8. says:

 1.  The amount of encrypted data possible in a single invocation is
     2^32-1 blocks of 64 bytes each, because of the size of the block
     counter field in the ChaCha20 block function.  This gives a total
     of 247,877,906,880 bytes, or nearly 256 GB.

It should say:

 1.  The amount of encrypted data possible in a single invocation is
     2^32-1 blocks of 64 bytes each, because of the size of the block
     counter field in the ChaCha20 block function.  This gives a total
     of 274,877,906,880 bytes, or nearly 256 GB.

Notes:

There is an error in the result of the P_MAX = ((2^32) - 1) * 64 calculation.
The correct value is 2_74_,877,906,880 while the document states 2_47_,877,906,880.
This error has already been adopted by multiple implementations as P_MAX value.

Errata ID: 4861
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Timm Korte
Date Reported: 2016-11-10
Verifier Name: Lars Eggert
Date Verified: 2016-11-13

Section 2.8. says:

   o  C_MAX = P_MAX + tag length = 247,877,906,896 octets.

It should say:

   o  C_MAX = P_MAX + tag length = 274,877,906,896 octets.

Notes:

When reviewing errata 4858, Adam Langely and Yoav Nir identified that this text should also be changed.

(This errata was created by duplicating 4858 in the system by Lars Eggert.)

RFC 7540, "Hypertext Transfer Protocol Version 2 (HTTP/2)", May 2015

Note: This RFC has been obsoleted by RFC 9113

Note: This RFC has been updated by RFC 8740

Source of RFC: httpbis (wit)

Errata ID: 5031
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2017-06-07
Verifier Name: Alexey Melnikov
Date Verified: 2017-06-19

Section 3.5 says:

   That is, the connection preface starts with the string "PRI *
   HTTP/2.0\r\n\r\nSM\r\n\r\n"). 
                              ^ 

It should say:

   That is, the connection preface starts with the string "PRI *
   HTTP/2.0\r\n\r\nSM\r\n\r\n".  

Notes:

Typo

RFC 7542, "The Network Access Identifier", May 2015

Source of RFC: radext (sec)

Errata ID: 5462
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alan DeKok
Date Reported: 2018-08-14
Verifier Name: Benjamin Kaduk
Date Verified: 2019-12-11

Section 3 says:

The "utf8-realm" SHOULD be supplied by the "next hop" or "home"
system that also supplies the routing information necessary for
packets to reach the next hop.

It should say:

The "utf8-realm" SHOULD be supplied by the "next hop" or "home"
system that also supplies the routing information necessary for
packets to reach the next hop.

The final home system SHOULD validate the NAI in the received packet
against the list of Realms hosted by the home system.  If no match
is found, the request SHOULD be rejected.

Notes:

It doesn't explicitly say that home systems only authenticate users for their own realms. It may help to have this stated explicitly.

Some text will also be added to draft-ietf-radext-coa-proxy in order to make this clearer.

RFC 7544, "Mapping and Interworking of Diversion Information between Diversion and History-Info Header Fields in the Session Initiation Protocol (SIP)", August 2015

Source of RFC: INDEPENDENT

Errata ID: 4481
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Amrita Bhatt
Date Reported: 2015-09-22
Verifier Name: Nevil Brownlee
Date Verified: 2016-03-17

Section 7.3 says:

   |       |       |INV C  |      |       |       |     |      |       |
   |       |       |------>|      |       |       |     |      |       |
   |       |       |History-Info: |       |       |     |      |       |
   |       |       <sip:proxyP1>;index=1, |       |     |      |       |
   |       |       <sip:userB>;index=1.1;rc=1,    |     |      |       |
   |       |       <sip:proxyP2;cause=302>;index=1.1.1;mp=1.1  |       |
   |       |       |       |      |       |       |     |      |       |
   |       |       |       |INV C |       |       |     |      |       |
   |       |       |       |----->|       |       |     |      |       |
   |       |       | Diversion:   |       |       |     |      |       |
   |       |     <sip:userB>;reason=unconditional;counter=1;privacy=off|
   |       |       |       |History-Info: |       |     |      |       |
   |       |       |       <sip:proxyP1>;index=1, |     |      |       |
   |       |       |       <sip:userB>;index=1.1;rc=1,  |      |       |
   |       |       |       <sip:proxyP2;cause=302>;index=1.1.1;mp=1.1  |
   |       |       |       |      |       |       |     |      |       |

It should say:

   |       |       |INV C  |      |       |       |     |      |       |
   |       |       |------>|      |       |       |     |      |       |
   |       |       |History-Info: |       |       |     |      |       |
   |       |       <sip:proxyP1>;index=1, |       |     |      |       |
   |       |       <sip:userB>;index=1.1;rc=1,    |     |      |       |
   |       |       <sip:userC;cause=302>;index=1.1.1;mp=1.1    |       |
   |       |       |       |      |       |       |     |      |       |
   |       |       |       |INV C |       |       |     |      |       |
   |       |       |       |----->|       |       |     |      |       |
   |       |       | Diversion:   |       |       |     |      |       |
   |       |     <sip:userB>;reason=unconditional;counter=1;privacy=off|
   |       |       |       |History-Info: |       |     |      |       |
   |       |       |       <sip:proxyP1>;index=1, |     |      |       |
   |       |       |       <sip:userB>;index=1.1;rc=1,  |      |       |
   |       |       |       <sip:userC;cause=302>;index=1.1.1;mp=1.1    |
   |       |       |       |      |       |       |     |      |       |

Notes:

Since the call is being diverted to userC, the last hi-targeted-to-uri should be that of userC instead of proxyP2.
This is same as example shown in section 3.4 which has userC in last hi-targeted-to-uri where the AS B is diverting the call.

RFC 7555, "Proxy MPLS Echo Request", June 2015

Source of RFC: mpls (rtg)

Errata ID: 4411
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Loa Andersson
Date Reported: 2015-07-08
Verifier Name: Deborah Brungard
Date Verified: 2015-07-08

Section 7 says:

<ToC>
7.3. Downstream Address Mapping Registry .......................25

<Section 7.3>
7.3. Downstream Address Mapping Registry

<Section 7.4>
When a code point is assigned that is not also assigned in the
Downstream Address Mapping Registry, the code point there must be
marked "Reserved".

Section 7.4

5        Reserved                                     RFC 7555
6        IPv4 Protocol Adj       4          0         RFC 7555
7        IPv6 Protocol Adj      16          0         RFC 7555

It should say:

<ToC>
7.3. Downstream Mapping Address Type Registry ..................25

<Section 7.3>
7.3. Downstream Mapping Address Type Registry

<Section 7.4>
When a code point is assigned that is not also assigned in the
Downstream Mapping Address Type Registry, the code point there 
must be marked "Reserved".

<Section 7.4>
5       Reserved                                   [RFC 6426, RFC 7555]
6       IPv4 Protocol Adj       4          0       [RFC 7555]
7       IPv6 Protocol Adj      16          0       [RFC 7555]

RFC 7567, "IETF Recommendations Regarding Active Queue Management", July 2015

Source of RFC: aqm (tsv)

Errata ID: 5639
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Roland Bless
Date Reported: 2019-02-18
Verifier Name: Mirja Kühlewind
Date Verified: 2019-02-18

Section 1.1 and 7.2 says:

1.1

The original fix for Internet meltdown was provided by Van Jacobsen.
Beginning in 1986, Jacobsen developed the congestion avoidance

7.2

[Flo92]    Floyd, S. and V. Jacobsen, "On Traffic Phase Effects in
           Packet-Switched Gateways", 1992,
           <http://www.icir.org/floyd/papers/phase.pdf>.

[Flo94]    Floyd, S. and V. Jacobsen, "The Synchronization of
           Periodic Routing Messages", 1994,
           <http://ee.lbl.gov/papers/sync_94.pdf>.

It should say:

1.1

The original fix for Internet meltdown was provided by Van Jacobson.
Beginning in 1986, Jacobson developed the congestion avoidance

7.2

[Flo92]    Floyd, S. and V. Jacobson, "On Traffic Phase Effects in
           Packet-Switched Gateways", 1992,
            <http://www.icir.org/floyd/papers/phase.pdf>.

[Flo94]    Floyd, S. and V. Jacobson, "The Synchronization of
           Periodic Routing Messages", 1994,
           <http://ee.lbl.gov/papers/sync_94.pdf>.

Notes:

Typographical error / misspelled name of Mr. Van Jacobson

Errata ID: 7574
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sean Sarfati
Date Reported: 2023-07-26
Verifier Name: RFC Editor
Date Verified: 2023-07-26

Section 2.4 says:

also the result of synchronization or other timing effects

It should say:

also the result of synchronization or other timing effects.

Notes:

Add sentence-ending period.

RFC 7574, "Peer-to-Peer Streaming Peer Protocol (PPSPP)", July 2015

Source of RFC: ppsp (tsv)

Errata ID: 4724
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sung Hei Kim, Chang Kyu Lee
Date Reported: 2016-07-01
Verifier Name: Spencer Dawkins
Date Verified: 2017-08-21

Section 1.3 says:

swarm ID
Unique identifier for a swarm of peers, in PPSPP a sequence of
bytes. For video on demand with content integrity protection
enabled, the identifier is the so-called root hash of a Merkle
hash tree over the content. For live streaming, the swarm ID is
a public key.

It should say:

swarm ID
Unique identifier for a swarm of peers, in PPSPP a sequence of
bytes. For video on demand, the identifier is the so-called root hash
of a Merkle hash tree over the content. For live streaming, the 
swarm ID is a public key.

Notes:

According to chapter 5 and chapter 6.1, it seems that it is not mandatory to use content integrity protection scheme.
The definition of swarm ID in the original text does not define how the ID is used in environment with the content integrity protection disabled.
It is possible to add new description on how swarm ID is defined in the content integrity protection scheme is disabled.
Or, it is possible to remove the parts regarding content integrity protection.

We propose to remove "with content integrity protection enabled" part.

Spencer: confirmed in conversations with Victor Grishchenko <victor.grishchenko@gmail.com> on the PPSP mailing list.

Errata ID: 4725
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sung Hei Kim, Chang Kyu Lee
Date Reported: 2016-07-01
Verifier Name: Spencer Dawkins
Date Verified: 2017-08-21

Section 5 says:

PPSPP can use different methods for protecting the integrity of the
content while it is being distributed via the peer-to-peer network.
More specifically, PPSPP can use different methods for receiving
peers to detect whether a requested chunk has been maliciously
modified by the sending peer. In benign environments, content
integrity protection can be disabled.

For static content, PPSPP currently defines one method for protecting
integrity, called the Merkle Hash Tree scheme. If PPSPP operates
over the Internet, this scheme MUST be used. If PPSPP operates in a
benign environment, this scheme MAY be used. So the scheme is
mandatory to implement, to satisfy the requirement of strong security
for an IETF protocol [RFC3365]. An extended version of the scheme is
used to efficiently protect dynamically generated content (live
streams), as explained below and in Section 6.1.

It should say:

PPSPP can use different methods for protecting the integrity of the
content while it is being distributed via the peer-to-peer network.
More specifically, PPSPP can use different methods for receiving
peers to detect whether a requested chunk has been maliciously
modified by the sending peer.

For static content, PPSPP currently defines one method for protecting
integrity, called the Merkle Hash Tree scheme.
The scheme is mandatory to implement, to satisfy the requirement of 
strong security for an IETF protocol [RFC3365]. An extended version
of the scheme is used to efficiently protect dynamically generated
content (live streams), as explained below and in Section 6.1.

Notes:

RFC 7574 (PPSP-PP) defines how the peers exchange chunks regarding content integrity protection scheme. It describes the relationship of the DATA and INTEGRITY messages.
But, it does not describes how peers exchange chunks when the content integrity protection scheme is disabled.
Thus, to the readers, it seems that content integrity protection scheme is very important part of PPSP-PP and must be used in order to implement PPSP-PP.
I think the RFC 7574 (PPSP-PP) should be changed to clearly express that the content integrity protection scheme must be used in PPSP-PP.
The proposed changes is to remove options regarding the use of content integrity protection.

Spencer: confirmed in conversations with Victor Grishchenko <victor.grishchenko@gmail.com> on the PPSP mailing list.

Errata ID: 4726
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sung Hei Kim, Chang Kyu Lee
Date Reported: 2016-07-01
Verifier Name: Spencer Dawkins
Date Verified: 2017-08-21

Section 6.1 says:

In the "Unified Merkle Tree" method, PPSPP combines the Merkle Hash
Tree scheme for static content with signatures to unify the video-on-
demand and live streaming scenarios. The use of Merkle hash trees
reduces the number of signing and verification operations, hence
providing a similar signature amortization to the approach described
in [SIGMCAST]. If PPSPP operates over the Internet, the "Unified
Merkle Tree" method MUST be used. If the protocol operates in a
benign environment, the "Unified Merkle Tree" method MAY be used. So
this method is mandatory to implement.

It should say:

In the "Unified Merkle Tree" method, PPSPP combines the Merkle Hash
Tree scheme for static content with signatures to unify the video-on-
demand and live streaming scenarios. The use of Merkle hash trees
reduces the number of signing and verification operations, hence
providing a similar signature amortization to the approach described
in [SIGMCAST].

Notes:

RFC 7574 (PPSP-PP) defines how the peers exchange chunks regarding content integrity protection scheme. It describes the relationship of the DATA and INTEGRITY messages.
But, it does not describes how peers exchange chunks when the content integrity protection scheme is disabled.
Thus, to the readers, it seems that content integrity protection scheme is very important part of PPSP-PP and must be used in order to implement PPSP-PP.
I think the RFC 7574 (PPSP-PP) should be changed to clearly express that the content integrity protection scheme must be used in PPSP-PP.
The proposed changes is to remove options regarding the use of content integrity protection.

Spencer: confirmed in conversations with Victor Grishchenko <victor.grishchenko@gmail.com> on the PPSP mailing list.

Errata ID: 4880
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sung Hei Kim, Chang Kyu Lee
Date Reported: 2016-12-07
Verifier Name: Spencer Dawkins
Date Verified: 2017-08-21

Section 7.5 says:

   A peer MUST include the content integrity method used by a swarm.
   The code for this option is 3.  Defined values are listed in Table 4.

                   +--------+-------------------------+
                   | Method | Description             |
                   +--------+-------------------------+
                   | 0      | No integrity protection |
                   | 1      | Merkle Hash Tree        |
                   | 2      | Sign All                |
                   | 3      | Unified Merkle Tree     |
                   | 4-255  | Unassigned              |
                   +--------+-------------------------+

            Table 4: PPSPP Content Integrity Protection Methods

It should say:

   A peer MUST include the content integrity method used by a swarm.
   The code for this option is 3.  Defined values are listed in Table 4.

                   +--------+-------------------------+
                   | Method | Description             |
                   +--------+-------------------------+
                   | 0      | Unassigned              |
                   | 1      | Merkle Hash Tree        |
                   | 2      | Sign All                |
                   | 3      | Unified Merkle Tree     |
                   | 4-255  | Unassigned              |
                   +--------+-------------------------+

            Table 4: PPSPP Content Integrity Protection Methods

Notes:

As stated in the first sentence of chapter 7.5, “A peer MUST include the content integrity method used by a swarm.”, “No integrity protection” must not be one of the option for PPSPP content integrity protection method. Or, IETF 7574 must define PPSP-PP that does not use the integrity protection method.

The proposed is to remove option of “No integrity protection” in Table 4.

Spencer: confirmed in conversations with Victor Grishchenko <victor.grishchenko@gmail.com> on the PPSP mailing list.

RFC 7578, "Returning Values from Forms: multipart/form-data", July 2015

Source of RFC: appsawg (art)

Errata ID: 4676
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Egon Eckert
Date Reported: 2016-04-26
Verifier Name: Alexey Melnikov
Date Verified: 2016-04-26

Section 4.6. says:

       --AaB03x
       content-disposition: form-data; name="_charset_"

       iso-8859-1
       --AaB03x--
       content-disposition: form-data; name="field1"

       ...text encoded in iso-8859-1 ...
       AaB03x--

It should say:

       --AaB03x
       content-disposition: form-data; name="_charset_"

       iso-8859-1
       --AaB03x
       content-disposition: form-data; name="field1"

       ...text encoded in iso-8859-1 ...
       --AaB03x--

Notes:

Boundary hyphens were misplaced, I think. The second boundary delimiter should not have them on the end of the line, and the last boundary delimiter should have them on the beginning of the line too.

RFC 7584, "Session Traversal Utilities for NAT (STUN) Message Handling for SIP Back-to-Back User Agents (B2BUAs)", July 2015

Source of RFC: straw (art)

Errata ID: 4413
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Brett Tate
Date Reported: 2015-07-10
Verifier Name: Ben Campbell
Date Verified: 2015-07-13

Section 4.4 says:

   Because of forking, a B2BUA might receive multiple answers for a
   single outbound INVITE.  When this occurs, the B2BUA SHOULD follow
   Sections 3.2 or 3.3 for all of those received answers.

It should say:

   Because of forking, a B2BUA might receive multiple answers for a
   single outbound INVITE.  When this occurs, the B2BUA SHOULD follow
   Sections 4.2 or 4.3 for all of those received answers.

Notes:

Sections 3.2 and 3.3 do not exist. The normative statement should indicate sections 4.2 and 4.3.

RFC 7593, "The eduroam Architecture for Network Roaming", September 2015

Source of RFC: INDEPENDENT

Errata ID: 4968
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Linus Nordberg
Date Reported: 2017-03-14
Verifier Name: Nevil Brownlee
Date Verified: 2017-07-20

Section 2.1 says:

Authentication in eduroam is achieved by using a combination of IEEE
802.1X [IEEE.802.1X] and EAP [RFC4372] (the latter carried over
RADIUS for guest access; see Section 2.2).

It should say:

Authentication in eduroam is achieved by using a combination of IEEE
802.1X [IEEE.802.1X] and EAP [RFC3748] (the latter carried over
RADIUS for guest access; see Section 2.2).

Notes:

EAP is 3748, not 4372.

Errata ID: 4969
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Linus Nordberg
Date Reported: 2017-03-14
Verifier Name: Nevil Brownlee
Date Verified: 2017-07-20

Section 2.1.2 says:

   The use of the Extensible Authentication Protocol (EAP) [RFC4372]

It should say:

   The use of the Extensible Authentication Protocol (EAP) [RFC3748]

Notes:

EAP is 3748, not 4372.

RFC 7595, "Guidelines and Registration Procedures for URI Schemes", June 2015

Note: This RFC has been updated by RFC 8615

Source of RFC: appsawg (art)

Errata ID: 4420
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Graham Klyne
Date Reported: 2015-07-17
Verifier Name: Barry Leiba
Date Verified: 2015-07-17

Section 4 says:

   o  If no permanent, citable specification for the scheme definition
      is included, credible reasons for not providing it SHOULD be
      given.

   o  The scheme definition SHOULD include clear security considerations
      (Section 3.7) or explain why a full security analysis is not
      available (e.g., in a third-party scheme registration).

   o  If the scheme definition does not meet the guidelines laid out in
      Section 3, the differences and reasons SHOULD be noted.

It should say:

Submitters are also encouraged to provide the following information as 
appropriate:

   o  If no permanent, citable specification for the scheme definition
      is included, credible reasons for not providing it.

   o  Clear security considerations (cf. Section 3.7), or an explanation
      of  why a security analysis is not available (e.g., in a third-
      party scheme registration).

   o  A note of and reasons for any deviations from the guidelines for 
      permanent registrations laid out in Section 3.

Notes:

The original text states a number of normative requirements on provisional registration of URI schemes, but the procedure for these ("first come first served") cannot reasonably be expected to check that they are satisfied. The revision proposed here changes the text to encourage submitters to provide this information, without giving it force of a normative requirement.

For more details, see:
https://mailarchive.ietf.org/arch/msg/apps-discuss/wsEAsWC1viE8YL1WfGkaW_NzMpg

The document editor has agreed the original text does not reflect the intent of the registration procedure:
https://mailarchive.ietf.org/arch/msg/apps-discuss/uPb33G9duZlrwNcdCFUJmvcPLgk

RFC 7598, "DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients", July 2015

Note: This RFC has been updated by RFC 8539

Source of RFC: softwire (int)

Errata ID: 4865
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ian Farrer
Date Reported: 2016-11-15
Verifier Name: Terry Manderson
Date Verified: 2017-03-01

Section 4.3 says:

dmr-prefix6-len: 8 bits long; expresses the bitmask length of the 
IPv6 prefix specified in the dmr-ipv6-prefix field.  Allowed
values range from 0 to 128.

It should say:

dmr-prefix6-len: 8 bits long; expresses the bitmask length of the 
IPv6 prefix specified in the dmr-ipv6-prefix field.  Allowed
values range from 0 to 96.

Notes:

This field is used to provision the default mapping rule prefix length, which is defined in section 5.1 of RFC7599:
The DMR IPv6 prefix length SHOULD be 64 bits long by default and in any case MUST NOT exceed 96 bits.

RFC 7599, "Mapping of Address and Port using Translation (MAP-T)", July 2015

Source of RFC: softwire (int)

Errata ID: 5225
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ole Troan
Date Reported: 2018-01-03
Verifier Name: Éric Vyncke
Date Verified: 2020-01-08

Section 6 says:

In the case of an IPv4 prefix, the IPv4 address field is right-padded
with zeros up to 32 bits.  The PSID is left-padded with zeros to
create a 16-bit field.  For an IPv4 prefix or a complete IPv4
address, the PSID field is zero.

It should say:

The PSID is left-padded with zeros to
create a 16-bit field.  For an IPv4 prefix or a complete IPv4
address, the PSID field is zero.

Notes:

This text has been copied from RFC7597 (MAP-E). While it is correct in the context of MAP-E, for MAP-T the complete IPv4 source address must be embedded in the interface-identifier for correct translation in the case of an IPv4 prefix. Right padding the prefix with zeroes would lead to the translated packet having all zeroes in its source address.

Errata ID: 5324
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Shachar Rosenberg
Date Reported: 2018-04-11
Verifier Name: Eric Vyncke
Date Verified: 2019-12-25

Section Appendix A says:

Example 5:

PSID:                    0x20 (provisioned with DHCPv6)

It should say:

Example 5:

PSID:                    0x34 (provisioned with DHCPv6)

Notes:

In IPv4, IPv6 and port ranges presented in the example the PSID matches to 0x34 and not 0x20:

PSID: 0x34
Available ports (63 ranges): 1232-1235, 2256-2259, ...... ,
63696-63699, 64720-64723
IPv6 address of MAP CE: 2001:db8:0012:3400:0000:c000:0212:0034

Errata ID: 7160
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Overcash
Date Reported: 2022-10-12
Verifier Name: Eric Vyncke
Date Verified: 2022-10-13

Section 10.1 says:

Translating an IPv4 packet to carry it across the MAP domain will increase its size (typically by 20 bytes).

It should say:

Translating an IPv4 packet to carry it across the MAP domain will increase its size (typically either 20 or 28 bytes with fragmentation).

Notes:

In the context of MTU, it is important to account for packet fragmentation. If an IPv4 packet is fragmented, the size will increase by 28 bytes during translation. The IPv6 header is 20 bytes larger than the IPv4 header, and in addition the 8 byte IPv6 Fragmentation Header must be added.

----
Verifier note
==========
with help of Yong Cui: fragmentation indeed needs to be taken into account.

RFC 7600, "IPv4 Residual Deployment via IPv6 - A Stateless Solution (4rd)", July 2015

Source of RFC: softwire (int)

Errata ID: 4430
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michelle Cotton
Date Reported: 2015-07-28
Verifier Name: RFC Editor
Date Verified: 2015-07-28

Section 6 says:

(need to add the below text)

It should say:

This address is to be used only as IPv4 source of an ICMP error 
packet whose cause originated within a tunnel across an IPv6-only 
domain. As such, it should never be used as a destination 
(and consequently never forwarded). When receiving an IPv4 
packet with this address as source, no specific action that would 
reserve this address for this protocol is required (dealing as usual 
with the error cause specified in the ICMP packet is sufficient).

Notes:

While processing the IANA Actions for this document, the authors requested that the above text be added to the IANA Considerations section. The published version does not include this text.

Verifier Notes: The RFC Editor missed adding this text per the message from the IANA.

Errata ID: 4661
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Masao Uebayashi
Date Reported: 2016-04-10
Verifier Name: Terry Manderson
Date Verified: 2016-05-12

Section 3 says:

BR(s) and/or N4T64+

It should say:

BR(s) and/or NAT64+

Notes:

A minor typo in Figure 1 (s/N4T64+/NAT64+/).

RFC 7601, "Message Header Field for Indicating Message Authentication Status", August 2015

Note: This RFC has been obsoleted by RFC 8601

Source of RFC: appsawg (art)

Errata ID: 4671
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ale
Date Reported: 2016-04-18
Verifier Name: Alexey Melnikov
Date Verified: 2016-08-25

Section 2.3 says:

   The "ptype" in the ABNF above indicates the general type of property
   being described by the result being reported, upon which the reported
                                             ^^^^^
   result was based.  Coupled with the "property", which is more
   specific, they indicate from which particular part of the message the
   reported data were extracted.
                    ^^^^

It should say:

   The "ptype" in the ABNF above indicates the general type of property
   being described by the value being reported, upon which the reported
                                             ^^^^^
   result was based.  Coupled with the "property", which is more
   specific, they indicate from which particular part of the message the
   reported "pvalue"s were extracted.
                    ^^^^^^^^

Notes:

The original text can be understood in multiple ways, depending on the meaning attributed to the term "result". The corrected text I submit is one of the possible interpretations. Note that if the first appearance of the term is assumed to be the ABNF "result", then ptype becomes an attribute of method, thereby setting a limit of one ptype per resinfo, as coincidentally it actually is.

RFC 7605, "Recommendations on Using Assigned Transport Port Numbers", August 2015

Source of RFC: tsvwg (wit)

Errata ID: 4437
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Klensin
Date Reported: 2015-08-07
Verifier Name: RFC Editor
Date Verified: 2015-08-21

Section Abstract says:

It provides designer guidance to requesters or users of port numbers on
how to interact with IANA using the processes defined in RFC 6335;
thus, this document complements (but does not update) that document.
It provides guidelines for designers regarding how to interact with
the IANA processes defined in RFC 6335, thus serving to complement
(but not update) that document.

It should say:

It provides designer guidance to requesters or users of port numbers on
how to interact with IANA using the processes defined in RFC 6335;
thus, this document complements (but does not update) that document.

Notes:

I think those two sentences say exactly the same thing and that the presence of both indicates that someone wasn't paying quite enough attention during AUTH48 or earlier. If they are intended to communicate different information, it isn't clear what that is and the result is massively confusing.

-- Verifier Notes --
The sentence was duplicated by mistake.

RFC 7616, "HTTP Digest Access Authentication", September 2015

Source of RFC: httpauth (sec)

Errata ID: 4495
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tuomo Untinen
Date Reported: 2015-10-09
Verifier Name: Kathleen Moriarty
Date Verified: 2015-12-08

Section 3.9.1. says:

   Both client and
   server know that the username for this document is "Mufasa" and the
   password is "Circle of Life" (with one space between each of the
   three words).

It should say:

   Both client and
   server know that the username for this document is "Mufasa" and the 
   password is "Circle of Life" (with one space between 
   each of the three words and non-capital o in word of).

Notes:

In RFC 2617, the password was "Circle Of Life" with capital O in the word "Of". Also, RFC 7616 section 3.4.5 mentions the password "Circle Of Life" with capital O in the word "Of". It can be difficult to notice a non-capital o from an example password as it is elsewhere capital O.

RFC 7622, "Extensible Messaging and Presence Protocol (XMPP): Address Format", September 2015

Source of RFC: xmpp (art)

Errata ID: 4534
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sam Whited
Date Reported: 2015-11-14
Verifier Name: Barry Leiba
Date Verified: 2019-07-02

Section 3.2.2 says:

   An entity that performs enforcement in XMPP domainpart slots MUST
   prepare a string as described in Section 3.2.1 and MUST also apply
   the normalization, case-mapping, and width-mapping rules defined in
   [RFC5892].

It should say:

  An entity that performs enforcement in XMPP domainpart slots MUST
  prepare a string as described in Section 3.2.1 and MUST also apply
  the normalization, case-mapping, and width-mapping rules defined in
  [RFC5895].

Notes:

RFC 5892 is just a list of codepoints; the rules to which it is referring (and that are referred to in the ABNF and other places in the document) are in RFC 5895.

Errata ID: 4560
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Peter Saint-Andre
Date Reported: 2015-12-07
Verifier Name: Barry Leiba
Date Verified: 2015-12-12

Section 3.5 says:

   | 18| <juliet@example.com/ foo>    | Leading space in resourcepart |

It should say:

[nothing]

Notes:

Example 18 is wrong because a leading space is currently allowed by RFC 7622 (at least, it is not disallowed by the OpaqueString profile defined in RFC 7613). It is true that leading and trailing spaces are disallowed by the Nickname profile, but we do not reference that here. This example should be removed in any updates to RFC 7622.

RFC 7630, "HMAC-SHA-2 Authentication Protocols in the User-based Security Model (USM) for SNMPv3", October 2015

Note: This RFC has been obsoleted by RFC 7860

Source of RFC: opsawg (ops)

Errata ID: 4509
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Johannes Merkle
Date Reported: 2015-10-20
Verifier Name: Benoit Claise
Date Verified: 2015-10-20

Section 8 and 10 says:

snmpModules 235

It should say:

mib-2 235

Notes:

IANA registered snmpUsmHmacSha2MIB under mib-2.235 (as advised by the MIB doctors), but the document mentions snmpModules.235

RFC 7636, "Proof Key for Code Exchange by OAuth Public Clients", September 2015

Source of RFC: oauth (sec)

Errata ID: 5687
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Collin Sauve
Date Reported: 2019-04-09
Verifier Name: Benjamin Kaduk
Date Verified: 2019-04-14

Section 5 says:

Server implementations of this specification MAY accept OAuth2.0
clients that do not implement this extension.  If the "code_verifier"
is not received from the client in the Authorization Request, servers
supporting backwards compatibility revert to the OAuth 2.0 [RFC6749]
protocol without this extension.

As the OAuth 2.0 [RFC6749] server responses are unchanged by this
specification, client implementations of this specification do not
need to know if the server has implemented this specification or not
and SHOULD send the additional parameters as defined in Section 4 to
all servers.

It should say:

Server implementations of this specification MAY accept OAuth2.0
clients that do not implement this extension.  If the "code_challenge"
is not received from the client in the Authorization Request, servers
supporting backwards compatibility revert to the OAuth 2.0 [RFC6749]
protocol without this extension.

As the OAuth 2.0 [RFC6749] server responses are unchanged by this
specification, client implementations of this specification do not
need to know if the server has implemented this specification or not
and SHOULD send the additional parameters as defined in Section 4 to
all servers.

Notes:

The code_verifier is not sent in the authorization request.

RFC 7642, "System for Cross-domain Identity Management: Definitions, Overview, Concepts, and Requirements", September 2015

Source of RFC: scim (sec)

Errata ID: 7696
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Masaya Watanabe
Date Reported: 2023-11-10
Verifier Name: RFC Editor
Date Verified: 2023-11-10

Section 3.4 says:

The user selects some attributes and authorizes the transfer of data via authorization protocols (e.g., OAuth, SAML), so selected attributes of the user are transferred from the user's account in directory service A to the website of replying party B at the time of the user's first visit to that site.

It should say:

The user selects some attributes and authorizes the transfer of data via authorization protocols (e.g., OAuth, SAML), so selected attributes of the user are transferred from the user's account in directory service A to the website of relying party B at the time of the user's first visit to that site.

Notes:

"relying party", not "replying party"

RFC 7643, "System for Cross-domain Identity Management: Core Schema", September 2015

Source of RFC: scim (sec)

Errata ID: 5990
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Shelley Baker
Date Reported: 2020-02-26
Verifier Name: Barry Leiba
Date Verified: 2020-02-26

Section 8.2 says:

  "addresses": [
    {
      "type": "work",
      "streetAddress": "100 Universal City Plaza",
      "locality": "Hollywood",
      "region": "CA",
      "postalCode": "91608",
      "country": "USA",
      "formatted": "100 Universal City Plaza\nHollywood, CA 91608 USA",
      "primary": true
    },
    {
      "type": "home",
      "streetAddress": "456 Hollywood Blvd",
      "locality": "Hollywood",
      "region": "CA",
      "postalCode": "91608",
      "country": "USA",
      "formatted": "456 Hollywood Blvd\nHollywood, CA 91608 USA"
    }
  ],

It should say:

  "addresses": [
    {
      "type": "work",
      "streetAddress": "100 Universal City Plaza",
      "locality": "Hollywood",
      "region": "CA",
      "postalCode": "91608",
      "country": "US",
      "formatted": "100 Universal City Plaza\nHollywood, CA 91608 USA",
      "primary": true
    },
    {
      "type": "home",
      "streetAddress": "456 Hollywood Blvd",
      "locality": "Hollywood",
      "region": "CA",
      "postalCode": "91608",
      "country": "US",
      "formatted": "456 Hollywood Blvd\nHollywood, CA 91608 USA"
    }
  ],

Notes:

Section 4.1.2 requires the use of the ISO 3166-1 "alpha-2" code format for the "country" attribute; however, sections 8.2 and 8.3 incorrectly specify "USA" instead of "US" for the "country" attribute.

Errata ID: 5991
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Shelley Baker
Date Reported: 2020-02-26
Verifier Name: Barry Leiba
Date Verified: 2020-02-26

Section 8.3 says:

  "addresses": [
    {
      "streetAddress": "100 Universal City Plaza",
      "locality": "Hollywood",
      "region": "CA",
      "postalCode": "91608",
      "country": "USA",
      "formatted": "100 Universal City Plaza\nHollywood, CA 91608 USA",
      "type": "work",
      "primary": true
    },
    {
      "streetAddress": "456 Hollywood Blvd",
      "locality": "Hollywood",
      "region": "CA",
      "postalCode": "91608",
      "country": "USA",
      "formatted": "456 Hollywood Blvd\nHollywood, CA 91608 USA",
      "type": "home"
     }
  ],

It should say:

  "addresses": [
    {
      "streetAddress": "100 Universal City Plaza",
      "locality": "Hollywood",
      "region": "CA",
      "postalCode": "91608",
      "country": "US",
      "formatted": "100 Universal City Plaza\nHollywood, CA 91608 USA",
      "type": "work",
      "primary": true
    },
    {
      "streetAddress": "456 Hollywood Blvd",
      "locality": "Hollywood",
      "region": "CA",
      "postalCode": "91608",
      "country": "US",
      "formatted": "456 Hollywood Blvd\nHollywood, CA 91608 USA",
      "type": "home"
     }
  ],

Notes:

Section 4.1.2 requires the use of the ISO 3166-1 "alpha-2" code format for the "country" attribute; however, sections 8.2 and 8.3 incorrectly specify "USA" instead of "US" for the "country" attribute.

RFC 7644, "System for Cross-domain Identity Management: Protocol", September 2015

Source of RFC: scim (sec)

Errata ID: 6893
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Phil Hunt
Date Reported: 2022-03-24
Verifier Name: RFC Editor
Date Verified: 2022-03-25

Section 7.5.2 says:

HTTP/1.1 403 Forbidden

  {
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
    "detail":
          "Query filter involving 'name' is restricted or confidential",
    "scimType": "sensitive",
    "status": "404"
  }

It should say:

HTTP/1.1 403 Forbidden

  {
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
    "detail":
          "Query filter involving 'name' is restricted or confidential",
    "scimType": "sensitive",
    "status": "403"
  }

Notes:

The error "status" value in the figure is wrong. It should be "403", consistent with the normative text and the HTTP Status at the start of the figure.

RFC 7662, "OAuth 2.0 Token Introspection", October 2015

Source of RFC: oauth (sec)

Errata ID: 4764
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Brian Campbell
Date Reported: 2016-08-04
Verifier Name: Roman Danyliw
Date Verified: 2024-01-17

Section 3.1 says:

OAuth registration client metadata names and descriptions are
registered by

It should say:

OAuth token introspection response parameters are registered by

Notes:

The original text erroneously mentions registration of client metadata names, however, this RFC 7662 is about about token introspection and this section is about registration of token introspection response parameters (client metadata name registration is RFC 7591).

RFC 7664, "Dragonfly Key Exchange", November 2015

Source of RFC: IRTF

Errata ID: 5754
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Araki Makoto
Date Reported: 2019-06-16
Verifier Name: Colin Perkins
Date Verified: 2020-06-06

Section 3.2.2 says:

      do {
        base = H(max(Alice,Bob) | min(Alice,Bob) | password | counter)
        temp = KDF-n(seed, "Dragonfly Hunting And Pecking")
        seed = (temp mod (p - 1)) + 1

It should say:

      do {
        base = H(max(Alice,Bob) | min(Alice,Bob) | password | counter)
        temp = KDF-n(base, "Dragonfly Hunting And Pecking")
        seed = (temp mod (p - 1)) + 1

Notes:

A variable "seed" is passed to the function KDF-n before defined. It should be the variable "base" instead of "seed". The variable "base" is passed to KDF-n in Figure 1.

Verified by Kenny Paterson and Dan Harkins, June 2019.

Errata ID: 5455
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Darshak Thakore
Date Reported: 2018-08-12
Verifier Name: Colin Perkins
Date Verified: 2019-04-09

Section 3.4 says:

The Commit Exchange consists of an exchange of data that is the
   output of the random function, H(), the key confirmation key, and the
   two scalars and two elements exchanged in the Commit Exchange.

It should say:

The Confirm Exchange consists of an exchange of data that is the
   output of the random function, H(), the key confirmation key, and the
   two scalars and two elements exchanged in the Commit Exchange.

Notes:

The sentence is explaining what will be exchanged in the Confirm Exchange but incorrectly calls it the Commit Exchange (seems like an editorial oversight)

RFC 7665, "Service Function Chaining (SFC) Architecture", October 2015

Source of RFC: sfc (rtg)

Errata ID: 4528
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Igor Duarte Cardoso
Date Reported: 2015-11-09
Verifier Name: Alia Atlas
Date Verified: 2015-11-11

Section 6 says:

packets at certain points on certain service chains, the control
mechanism MUST verify that appropriate protective treatment of
NSH information is available from the point where the
information is added to the point where it will be removed.  If
such mechanisms are unavailable, error notifications SHOULD be
generated.

It should say:

packets at certain points on certain service chains, the control
mechanism MUST verify that appropriate protective treatment of
SFC encapsulation information is available from the point where the
information is added to the point where it will be removed.  If
such mechanisms are unavailable, error notifications SHOULD be
generated.

Notes:

NSH has not been introduced earlier in the document. Moreover, the reference to NSH itself seems to have been a tiny mistake that slipped.
The corrected text replaces NSH with SFC encapsulation.

RFC 7666, "Management Information Base for Virtual Machines Controlled by a Hypervisor", October 2015

Source of RFC: opsawg (ops)

Errata ID: 4710
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: jean-marie Kubek
Date Reported: 2016-06-15
Verifier Name: Benoit Claise
Date Verified: 2016-06-17

Section 6.2 IANA MIB says:

IANAStorageMediaType ::= TEXTUAL-CONVENTION
       STATUS       current
       DESCRIPTION
               "The media type of a storage device:

               unknown(1)     The media type is unknown, e.g., because
                              the implementation failed to obtain the
                              media type from the hypervisor.

               other(2)       The media type is other than those
                              defined in this conversion.

It should say:

IANAStorageMediaType ::= TEXTUAL-CONVENTION
       STATUS       current
       DESCRIPTION
               "The media type of a storage device:

                 other(1)       The media type is other than those
                                defined in this conversion.

                 unknown(2)     The media type is unknown, e.g., because
                                the implementation failed to obtain the
                                media type from the hypervisor.

Notes:

Inversion of other and unknown integer values in the description of the IANAStorageMediaType TEXTUAL-CONVENTION.

FIrst referenced at IANA RT as [IANA #913286] Incoherency in IANA-STORAGE-MEDIA-TYPE-MIB

RFC 7667, "RTP Topologies", November 2015

Source of RFC: avtcore (wit)

Errata ID: 6641
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Philipp Hancke
Date Reported: 2021-07-13
Verifier Name: Francesca Palombini
Date Verified: 2023-11-07

Section 4.1 says:

Media Translators, Mesh with independent RTP Sessions, mixers, SFUs,

It should say:

Media Translators, Mesh with independent RTP Sessions, mixers, SFMs,

Notes:

The document defines and uses the term "Selective Forwarding Middlebox" instead of "Selective Forwarding Unit".

RFC 7672, "SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)", October 2015

Source of RFC: dane (sec)

Errata ID: 5395
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Matt McCutchen
Date Reported: 2018-06-16
Verifier Name: Benjamin Kaduk
Date Verified: 2018-06-16

Section 2.1.1 says:

   DNS records that would be
   classified "indeterminate" in the sense of [RFC4035] are simply
   classified as "insecure".

It should say:

   DNS records that would be
   classified "indeterminate" in the sense of [RFC4033] are simply
   classified as "insecure".

RFC 7679, "A One-Way Delay Metric for IP Performance Metrics (IPPM)", January 2016

Source of RFC: ippm (ops)

Errata ID: 6831
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2022-02-03
Verifier Name: RFC Editor

Section 7 says:

   The text above constitutes a revision to RFC 2769, which is now an
   Internet Standard.  This section tracks the changes from [RFC2679].

It should say:

   The text above constitutes a revision to RFC 2679, which is now an
   Internet Standard.  This section tracks the changes from [RFC2679].

Notes:

Typo in RFC number (2769 instead 2679).

RFC 7683, "Diameter Overload Indication Conveyance", October 2015

Note: This RFC has been updated by RFC 8581

Source of RFC: dime (ops)

Errata ID: 4549
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jan Kayser
Date Reported: 2015-12-01
Verifier Name: Benoit Claise
Date Verified: 2016-05-17

Section 4.3 says:

The overloaded realm is identified by the Destination-Realm AVP 
of the message containing the OLR.

It should say:

The overloaded realm is identified by the Origin-Realm AVP
of the message containing the OLR.

Notes:

When the overload report is of type "REALM_REPORT", the overloaded realm is identified by the Origin-Realm AVP of the Diameter command i.e. the realm of the originator of the Diameter command with the overload report.

RFC 7696, "Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms", November 2015

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 5142
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Denis Ovsienko
Date Reported: 2017-10-04
Verifier Name: Roman Danyliw
Date Verified: 2024-01-17

Section 2.7 says:

Performance is always a factor is selecting cryptographic algorithms.

It should say:

Performance is always a factor in selecting cryptographic algorithms.

Notes:

A simple typo.

Errata ID: 5143
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Denis Ovsienko
Date Reported: 2017-10-04
Verifier Name: Roman Danyliw
Date Verified: 2024-01-17

Section 2.2.3 says:

reasonable to expect that a the status of a MUST-

It should say:

reasonable to expect that the status of a MUST-

Notes:

Typo

RFC 7706, "Decreasing Access Time to Root Servers by Running One on Loopback", November 2015

Note: This RFC has been obsoleted by RFC 8806

Source of RFC: dnsop (ops)

Errata ID: 4755
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: John W. O'Brien
Date Reported: 2016-08-01
Verifier Name: joel jaeggli
Date Verified: 2016-08-01

Section 2 says:

The system MUST be able to run an authoritative server on one of
the IPv4 loopback addresses (that is, an address in the range
127/8 for IPv4 or ::1 in IPv6).

It should say:

The system MUST be able to run an authoritative server on one of
the IP loopback addresses (that is, an address in the range
127/8 for IPv4 or ::1 in IPv6).

Notes:

reviewed

RFC 7707, "Network Reconnaissance in IPv6 Networks", March 2016

Source of RFC: opsec (ops)

Errata ID: 5175
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kevin Tyers
Date Reported: 2017-10-30
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2017-10-31

Section 5.1.4. says:

the response would
   contain an RCODE of 0 (no error).  Otherwise, the response would
   contain an RCODE of 4 (NXDOMAIN).

It should say:

the response would
   contain an RCODE of 0 (no error).  Otherwise, the response would
   contain an RCODE of 3 (NXDOMAIN).

Notes:

In RFC1035 section 4.1.1. it states that an RCODE of 3 is 'Name Error' aka NXDOMAIN. RCODE 4 is "Not Implemented". RFC 7707 incorrectly refers to NXDOMAIN as RCODE 4 instead of RCODE 3.

Here is the output of testing this in Wireshark:
.... .... .... 0011 = Reply code: No such name (3)

RFC 7714, "AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP)", December 2015

Source of RFC: avtcore (wit)

Errata ID: 4938
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Paul E. Jones
Date Reported: 2017-02-16
Verifier Name: Murray Kucherawy
Date Verified: 2023-11-08

Section 11 says:

A Key Derivation Function (KDF) is used to derive all of the required
encryption and authentication keys from a secret value shared by the
endpoints.  The AEAD_AES_128_GCM algorithm MUST use the (128-bit)
AES_CM PRF KDF described in [RFC3711].  AEAD_AES_256_GCM MUST use the
AES_256_CM_PRF KDF described in [RFC6188].

It should say:

A Key Derivation Function (KDF) is used to derive all of the required
encryption and authentication keys from a secret value shared by the
endpoints.  The AEAD_AES_128_GCM algorithm MUST use the (128-bit)
AES_CM PRF KDF described in [RFC3711].  AEAD_AES_256_GCM MUST use the
AES_256_CM_PRF KDF described in [RFC6188].  Since the KDF functions in
those RFCs assume as input a 112-bit master salt, the 96-bit master
salt specified in this document must be multiplied by 2^16 to form the
112-bit salt used as the master salt in those key derivation functions.

Notes:

The salt specified in RFC 7714 is 96 bits in length, but intended for use in KDF functions defined in RFC 3711. This led to different interpretations when implementing this RFC. A more complete description was presented on the avtcore mailing list (https://mailarchive.ietf.org/arch/msg/avt/IRfLuNKglD3qhqwSz3v3t0CG6fA) and, after some dialog, there seemed to be agreement to adopt the approach most widely implemented (https://mailarchive.ietf.org/arch/msg/avt/-C1cIWQXpyzS2KfBjGR6B2kK92w). This suggested text is intended to reflect that agreement. In effect, 16 zero bits are padded to the right of the salt value defined in RFC 7714 (creating a 112 bit salt value) before it is used as described in the KDF functions defined in RFC 3711 that require a 112 bit salt value.

RFC 7728, "RTP Stream Pause and Resume", February 2016

Source of RFC: avtext (art)

Errata ID: 5540
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nicholas Wilson
Date Reported: 2018-11-02
Verifier Name: Ben Campbell
Date Verified: 2018-11-05

Section 8.2. PAUSED says:

   PAUSED SHALL contain a fixed-length 32-bit parameter at the start of
   the Type Specific field with the extended RTP sequence number of the
   last RTP packet sent before the RTP stream was paused, in the same
   format as the extended highest sequence number received
   (Section 6.4.1 of [RFC3550]).

It should say:

   PAUSED SHALL contain a fixed-length 32-bit parameter at the start of
   the Type Specific field with the extended RTP sequence number of the
   last RTP packet sent before the RTP stream was paused, in the same
   format as the extended highest sequence number received
   (Section 6.4.1 of [RFC3550]), or, if no packet has been sent, the
   value one less than the sequence number that will be chosen for the
   next packet sent (modulo 2^32).

Notes:

The paragraph leaves the value of the parameter undefined when the stream is paused before any data has been sent.

RFC 7748, "Elliptic Curves for Security", January 2016

Source of RFC: IRTF

Errata ID: 4730
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Adam Langley
Date Reported: 2016-07-05
Verifier Name: Lars Eggert
Date Verified: 2016-07-05

Section 4.1 says:

V(P)  147816194475895447910205935684099868872646061346164752889648818
37755586237401

It should say:

V(P)  431144251710685529207648989359339670393703861982038067307639101
66200978582548

Notes:

The Montgomery form of the curve is generally used with a ladder, where the v coordinate is unused and unspecified. Thus I picked the smaller of the two possible values for v.

However, the curve is birationally equivalent to edwards25519, where both coordinates of the base point are used and are already in widespread use. Sadly, picking the smaller of the values for v ends up mapping to the negative of the base point on edwards25519.

This change replaces v with -v so that it matches up.

Errata ID: 7625
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tomasz Mioduszewski
Date Reported: 2023-08-31
Verifier Name: Stanislav Smyshlyaev
Date Verified: 2023-09-04

Section 5 says:

swap ^= k_t

It should say:

swap = swap XOR k_t

Notes:

The '^' symbol is used inconsistently. In the line `swap ^= k_t` this symbol means the XOR operation, while later, e.g. in line `x_3 = (DA + CB)^2`, it indicates exponentiation. Pseudocode in this document also denotes the XOR operation in the following way: `x_2 = x_2 XOR dummy`. The inconsistent use of the '^' symbol may cause confusion. If one were to perform the operation `swap = swap (to the power of) k_t` instead of `swap = swap XOR k_t`, they would get incorrect results.

Errata ID: 5028
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Adam Langley
Date Reported: 2017-06-02
Verifier Name: Stanislav Smyshlyaev
Date Verified: 2020-12-15

Section 5.2 says:

Input u-coordinate as a number (base 10):

It should say:

Decoded u-coordinate as a number (base 10):

Notes:

It is unclear that the base 10 numbers are the decoded values (i.e. after masking). That should have been made more explicit to reduce confusion.

Errata ID: 7095
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: James Muir
Date Reported: 2022-08-18
Verifier Name: RFC Editor
Date Verified: 2024-01-22

Appendix A says:

This section specifies the procedure that was used to generate the
above curves; specifically, it defines how to generate the parameter
A of the Montgomery curve y^2 = x^3 + A*x^2 + x.

It should say:

This section specifies the procedure that was used to generate the
above curves; specifically, it defines how to generate the parameter
A of the Montgomery curve v^2 = u^3 + A*u^2 + u.

Notes:

For consistency with the other parts of the document (e.g. Section 3), use the variables u and v in the Montgomery curve equation.

RFC 7749, "The "xml2rfc" Version 2 Vocabulary", February 2016

Note: This RFC has been obsoleted by RFC 7991

Source of RFC: IAB

Errata ID: 4614
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2016-02-05
Verifier Name: RFC Editor
Date Verified: 2017-02-13

Section 5 says:

   <?xml version="1.0"?>

   <!DOCTYPE rfc [

     <!-- allow later RFC 2629 reference using "&rfc2629;" -->
     <!-- the data will be fetched from xml2rfc.ietf.org -->
     <!ENTITY rfc2629 PUBLIC
     "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2629.xml">
   ]>

It should say:

   <?xml version="1.0"?>

   <!DOCTYPE rfc [

     <!-- allow later RFC 2629 reference using "&rfc2629;" -->
     <!-- the data will be fetched from xml2rfc.ietf.org -->
     <!ENTITY rfc2629 SYSTEM
     "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2629.xml">
   ]>

Notes:

A "PUBLIC" entity would need an additional "PubidLiteral" (which could be an empty string); but it's simpler to use a "SYSTEM" entity instead.

See <https://www.w3.org/TR/2008/REC-xml-20081126/#sec-external-ent>.

[Verified per request of J. Reschke and H. Flanagan.]

Errata ID: 4715
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jim Schaad
Date Reported: 2016-06-20
Verifier Name: Robert Sparks
Date Verified: 2018-02-09

Section 2.22.3 says:

 The value is a free-form text that allows counter values to be
      inserted using a "percent-letter" format.  For instance, "[REQ%d]"
      generates labels of the form "[REQ1]", where "%d" inserts the item
      number as a decimal number.

It should say:

 The value is a free-form text that allows counter values to be
      inserted using a "percent-letter" format.  For instance, 
"format [REQ%d]"
      generates labels of the form "[REQ1]", where "%d" inserts the item
      number as a decimal number.

Notes:

The string format must prefix the style text in order for it to be recognized and used. This means that the example given is incorrect as it will not generate the requested output.

It is possible that explanatory text to the effect of the string format being required is needed as well, however modification of the example should be sufficient.

Errata ID: 4850
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Heather Flanagan
Date Reported: 2016-10-31
Verifier Name: Robert Sparks
Date Verified: 2018-02-09

Section A.4. says:

A.4.  The "consensus" Attribute

   For some of the publication streams (see Appendix A.3), the "Status
   of This Memo" section depends on whether there was a consensus to
   publish (again, see Section 3.2.2 of [RFC5741]).

   The "consensus" attribute ("yes"/"no", defaulting to "yes") can be
   used to supply this information.  The effect for the various
   streams is:

   o  "independent" and "IAB": none.

   o  "IETF": mention that there was an IETF consensus.

   o  "IRTF": mention that there was a research group consensus (where
      the name of the research group is extracted from the <workgroup>
      element).

It should say:

A.4.  The "consensus" Attribute

   For some of the publication streams (see Appendix A.3), the "Status
   of This Memo" section depends on whether there was a consensus to
   publish (again, see Section 3.2.2 of [RFC5741]).

   The "consensus" attribute ("yes"/"no", defaulting to "yes") can be
   used to supply this information.  The effect for the various
   streams is:

   o  "independent": none.

   o  "IAB": mention that there was an IAB consensus.

   o  "IETF": mention that there was an IETF consensus.

   o  "IRTF": mention that there was a research group consensus (where
      the name of the research group is extracted from the <workgroup>
      element).

Notes:

IAB documents may or may not include a consensus statement. See https://www.rfc-editor.org/materials/status-memos.txt, numbers 9-12.

Errata ID: 5394
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2018-06-15
Verifier Name: Mirja Kühlewind
Date Verified: 2024-01-11

Section 2.33.3 says:

   Note that the file extension is not part of the draft, so in general
   it should end with the current draft number ("-", plus two digits).

It should say:

   Note that the file extension is not part of the draft name, so in
   general it should end with the current draft number ("-", plus two
   digits).

Notes:

replace "draft" by "draft name"

RFC 7752, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", March 2016

Note: This RFC has been obsoleted by RFC 9552

Note: This RFC has been updated by RFC 9029

Source of RFC: idr (rtg)

Errata ID: 6587
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alvaro Retana
Date Reported: 2021-05-18
Verifier Name: John Scudder
Date Verified: 2022-05-14

Section 1 says:

   Mechanisms through which topologies can be aggregated or virtualized
   are outside the scope of this document

It should say:

   Mechanisms through which topologies can be aggregated or virtualized
   are outside the scope of this document.

Notes:

This sentence has no period.

RFC 7761, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", March 2016

Note: This RFC has been updated by RFC 8736, RFC 9436

Source of RFC: pim (rtg)

Errata ID: 5342
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Frank Hua Li
Date Reported: 2018-04-28
Verifier Name: Alvaro Retana
Date Verified: 2018-05-24

Section 4.4.2 says:

set KeepaliveTimer(S,G) to RP_Keepalive_Period;

It should say:

set KeepaliveTimer(S,G) to max(Keepalive_Period, RP_Keepalive_Period);

Notes:

The normal keepalive period for the KAT(S,G) defaults to 210 seconds. However, at the RP, the keepalive period must be at least the Register_Suppression_Time, or the RP may time out the (S,G) state before the next Null-Register arrives. Thus, the KAT(S,G) is set to max(Keepalive_Period, RP_Keepalive_Period) when a Register-Stop is sent.

====
Note that the text above comes from §4.11.

Errata ID: 7857
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alexander Okonnikov
Date Reported: 2024-03-19
Verifier Name: RFC Editor
Date Verified: 2024-03-20

Section 4.6.5 says:

     bool lost_assert(S,G,I) {
       if ( RPF_interface(S) == I ) {
          return FALSE
       } else {
          return ( AssertWinner(S,G,I) != NULL AND
                   AssertWinner(S,G,I) != me  AND
                   (AssertWinnerMetric(S,G,I) is better
                      than spt_assert_metric(S,I) )
       }
     }

It should say:

     bool lost_assert(S,G,I) {
       if ( RPF_interface(S) == I ) {
          return FALSE
       } else {
          return ( AssertWinner(S,G,I) != NULL AND
                   AssertWinner(S,G,I) != me  AND
                   AssertWinnerMetric(S,G,I) is better
                      than spt_assert_metric(S,I) )
       }
     }

Notes:

Excessive parenthesis before 'AssertWinnerMetric(S,G,I)'.

RFC 7770, "Extensions to OSPF for Advertising Optional Router Capabilities", February 2016

Source of RFC: ospf (rtg)

Errata ID: 7524
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: James N Guichard
Date Reported: 2023-05-24
Verifier Name: John Scudder
Date Verified: 2023-05-24

Section 5.4 says:

   o  The values are defined in Section 2.6.  All Router Informational
      Capability TLV additions are to be assigned through IETF Review
      [IANA-GUIDE].

It should say:

   o  The values are defined in Section 2.5.  All Router Informational
      Capability Bit additions are to be assigned through IETF Review
      [IANA-GUIDE].

Notes:

Router Informational Capabilities bits are defined in section 2.5 of the document and NOT section 2.6, and they are bits, not TLVs.

See also https://mailarchive.ietf.org/arch/msg/lsr/pc0-mos28aQ7D59ijCBDWLctAXE/

RFC 7788, "Home Networking Control Protocol", April 2016

Note: This RFC has been updated by RFC 8375

Source of RFC: homenet (int)

Errata ID: 4677
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tim Wicinski
Date Reported: 2016-04-26
Verifier Name: Terry Manderson
Date Verified: 2016-05-12

Section 8 says:

   A network-wide
   zone is appended to all single labels or unqualified zones in order
   to qualify them. ".home" is the default; however, an administrator
   MAY configure the announcement of a Domain-Name TLV (Section 10.6)
   for the network to use a different one.

It should say:

   A network-wide
   zone is appended to all single labels or unqualified zones in order 
   to qualify them.  A default value for this TLV MUST be set, although 
   the default value of the Domain-Name TLV (Section 10.6) is out of 
   scope of this document, and an administrator MAY configure the 
   announcement of a Domain-Name TLV for the network.

Notes:

It may appear that the use of the label ".home" is unofficially assigning this to be added to the Special Use Domain Registry. That registry can only be updated using the process outlined in RFC6761, therefore the text identifying ".home" as the default network-wide zone is in error.

It is unclear of the IESG and the IETF in publishing this proposed standard if the intent was to use ".home" as an example or placeholder until a name can be reserved.

AD Note: A default label is a requirement for HNCP and its interoperability. As such the Homenet chosen label, ".home", is a strong candidate for the RFC6761 process. The WG will be directed to follow this process and seek (again) the consensus on the ".home" label and work with other IETF WGs as appropriate.

Errata ID: 5021

Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Dirk Feytons
Date Reported: 2017-05-19
Verifier Name: Eric Vyncke
Date Verified: 2021-01-03
Report Text:

RFC 7787 (DNCP) in section 9 defines DNCP_NODE_IDENTIFIER_LENGTH as being bytes, not bits.

-- Verifier note --
Indeed, section 9 of RFC 7787 clearly specifies "DNCP_NODE_IDENTIFIER_LENGTH: The fixed length of a node identifier (in bytes)."

---

Errata ID: 5113
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Denis Ovsienko
Date Reported: 2017-09-13
Verifier Name: Eric Vyncke
Date Verified: 2021-01-03

Section 10 says:

10.2.2.  DHCPv6-Data TLV

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type: DHCPv6-Data (37)     |          Length: > 0          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

[...]

10.2.3.  DHCPv4-Data TLV

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type: DHCPv4-Data (38)    |          Length: > 0          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

10.2.2.  DHCPv6-Data TLV

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type: DHCPv6-Data (38)     |          Length: > 0          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

[...]

10.2.3.  DHCPv4-Data TLV

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type: DHCPv4-Data (37)    |          Length: > 0          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

Section 13 (IANA Considerations) of the document says:

37: DHCPv4-Data

38: DHCPv6-Data

Those code points from Section 13 are in the "HNCP TLV Types" IANA registry as well as in the current source code of shncpd and tcpdump. The code points shown in Sections 10.2.2 and 10.2.3 were likely swapped by mistake.

-- Verifier note --
The IANA registry for HNCP TLV types (https://www.iana.org/assignments/dncp-registry/dncp-registry.xhtml#hncp-tlv-types) has indeed 37 for DHCPv4 and the open source SHNCPD has the same https://github.com/jech/shncpd/blob/master/receive.c

RFC 7800, "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)", April 2016

Source of RFC: oauth (sec)

Errata ID: 6187
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Pete Resnick
Date Reported: 2020-05-26
Verifier Name: Benjamin Kaduk
Date Verified: 2020-05-31

Section 7.1 says:

   [JWK]      Jones, M., "JSON Web Key (JWK)", RFC 7517,
              DOI 10.17487/RFC7157, May 2015,
              <http://www.rfc-editor.org/info/rfc7517>.

It should say:

   [JWK]      Jones, M., "JSON Web Key (JWK)", RFC 7517,
              DOI 10.17487/RFC7517, May 2015,
              <http://www.rfc-editor.org/info/rfc7517>.

Notes:

DOI has a typo: 7157 instead of 7517.

RFC 7801, "GOST R 34.12-2015: Block Cipher "Kuznyechik"", March 2016

Source of RFC: INDEPENDENT

Errata ID: 4660
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2016-04-08
Verifier Name: Nevil Brownlee
Date Verified: 2017-07-20

Section 3.2 says:

   delta: V_8 -> Q  bijective mapping that maps a binary string from V_8
           into an element from field Q as follows: string
           z_7||...||z_1||z_0, where z_i in {0, 1}, i = 0, ..., 7,
           corresponds to the element z_0+(z_1*theta)+...+(z_7*theta^7)
           belonging to Z,

It should say:

   delta: V_8 -> Q  bijective mapping that maps a binary string from V_8
           into an element from field Q as follows: string
           z_7||...||z_1||z_0, where z_i in {0, 1}, i = 0, ..., 7,
           corresponds to the element z_0+(z_1*theta)+...+(z_7*theta^7)
           belonging to Q,

RFC 7807, "Problem Details for HTTP APIs", March 2016

Note: This RFC has been obsoleted by RFC 9457

Source of RFC: appsawg (art)

Errata ID: 6178
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Gary Peck
Date Reported: 2020-05-18
Verifier Name: Barry Leiba
Date Verified: 2020-05-19

Section 3 says:

   The ability to convey problem-specific extensions allows more than
   one problem to be conveyed.  For example:

   HTTP/1.1 400 Bad Request
   Content-Type: application/problem+json
   Content-Language: en

   {
   "type": "https://example.net/validation-error",
   "title": "Your request parameters didn't validate.",
   "invalid-params": [ {
                         "name": "age",
                         "reason": "must be a positive integer"
                       },
                       {
                         "name": "color",
                         "reason": "must be 'green', 'red' or 'blue'"}
                     ]
   }

It should say:

   The ability to convey problem-specific extensions allows more than
   one problem to be conveyed.  For example:

   HTTP/1.1 400 Bad Request
   Content-Type: application/problem+json
   Content-Language: en

   {
   "type": "https://example.net/validation-error",
   "title": "Your request parameters didn't validate.",
   "invalid_params": [ {
                         "name": "age",
                         "reason": "must be a positive integer"
                       },
                       {
                         "name": "color",
                         "reason": "must be 'green', 'red' or 'blue'"}
                     ]
   }

Notes:

The "invalid-params" member in the example is named incorrectly. According to Section 4, it should contain an "_" rather than a "-" in its name:

> If such additional members are defined, their names SHOULD start with
> a letter (ALPHA, as per [RFC5234], Appendix B.1) and SHOULD consist
> of characters from ALPHA, DIGIT ([RFC5234], Appendix B.1), and "_"
> (so that it can be serialized in formats other than JSON), and they
> SHOULD be three characters or longer.

RFC 7816, "DNS Query Name Minimisation to Improve Privacy", March 2016

Note: This RFC has been obsoleted by RFC 9156

Source of RFC: dnsop (ops)

Errata ID: 4644
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Robert Edmonds
Date Reported: 2016-03-24
Verifier Name: Joel Jaeggli
Date Verified: 2017-03-29

Section 6 says:

QNAME minimisation can decrease performance in some cases -- for
instance, for a deep domain name (like
www.host.group.department.example.com, where 
host.group.department.example.com is hosted on example.com's name
servers).  Let's assume a resolver that knows only the name servers of
.example.  Without QNAME minimisation, it would send these .example name
servers a query for www.host.group.department.example.com and
immediately get a specific referral or an answer, without the need for
more queries to probe for the zone cut.  For such a name, a cold
resolver with QNAME minimisation will, depending on how QNAME
minimisation is implemented, send more queries, one per label.  Once the
cache is warm, there will be no difference with a traditional resolver.
Actual testing is described in [Huque-QNAME-Min].  Such deep domains are
especially common under ip6.arpa.

It should say:

QNAME minimisation can decrease performance in some cases -- for 
instance, for a deep domain name (like
www.host.group.department.example.com, where 
host.group.department.example.com is hosted on example.com's name
servers).  Let's assume a resolver that knows only the name servers of
.example.com.  Without QNAME minimisation, it would send these 
.example.com name servers a query for 
www.host.group.department.example.com and immediately get a specific
referral or an answer, without the need for more queries to probe for
the zone cut.  For such a name, a cold resolver with QNAME minimisation
will, depending on how QNAME minimisation is implemented, send more
queries, one per label.  Once the cache is warm, there will be no
difference with a traditional resolver.  Actual testing is described in
[Huque-QNAME-Min].  Such deep domains are especially common under
ip6.arpa.

Notes:

Changed ".example" to ".example.com".

RFC 7836, "Guidelines on the Cryptographic Algorithms to Accompany the Usage of Standards GOST R 34.10-2012 and GOST R 34.11-2012", March 2016

Source of RFC: INDEPENDENT

Errata ID: 6197
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Billy Brumley
Date Reported: 2020-06-03
Verifier Name: Adrian Farrel
Date Verified: 2020-07-01

Section 3 says:

When a point on an elliptic curve is given to an input of a hash
function, affine coordinates for short Weierstrass form are used (see
Section 5): an x coordinate value is fed first, a y coordinate value
is fed second, both in little-endian format.

It should say:

When a point on an elliptic curve is given to an input of a hash
function, affine coordinates for short Weierstrass form are used (see
Section 5): an x coordinate value is fed first, a y coordinate value
is fed second, both in little-endian format. If the point to be fed
to the hash function is zero point, the calculation MUST NOT be performed
and an error SHOULD be reported on a protocol level.

Notes:

A new sentence added at the end of the paragraph explicitly defines the processing in case when the zero point is fed to the hash function.

Errata ID: 6198
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Billy Brumley
Date Reported: 2020-06-03
Verifier Name: Adrian Farrel
Date Verified: 2020-07-01

Section 4.3.1 says:

KEK_VKO (x, y, UKM) is calculated using the formulas:

    KEK_VKO (x, y, UKM) = H_256 (K (x, y, UKM)),

    K (x, y, UKM) = (m/q*UKM*x mod q)*(y*P),

It should say:

KEK_VKO (x, y, UKM) is calculated using the formulas:

    KEK_VKO (x, y, UKM) = H_256 (K (x, y, UKM)),

    K (x, y, UKM) = (m/q*(UKM*x mod q))*(y*P),

Notes:

For now the original text may be interpreted in the wrong way that both multiplications inside the brackets should be performed modulo q. However, multiplication by m/q must be a simple integer multiplication, without reduction modulo q, to eliminate small subgroup component of the input elliptic curve point. The proposed text modification clarifies the correct types and order of multiplication.

Errata ID: 6199
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Billy Brumley
Date Reported: 2020-06-03
Verifier Name: Adrian Farrel
Date Verified: 2020-07-01

Section 4.3.2 says:

KEK_VKO (x, y, UKM) is calculated using the formulas:

    KEK_VKO (x, y, UKM) = H_512 (K (x, y, UKM)),

    K (x, y, UKM) = (m/q*UKM*x mod q)*(y*P),

It should say:

KEK_VKO (x, y, UKM) is calculated using the formulas:

    KEK_VKO (x, y, UKM) = H_512 (K (x, y, UKM)),

    K (x, y, UKM) = (m/q*(UKM*x mod q))*(y*P),

Notes:

For now the original text may be interpreted in the wrong way that both multiplications inside the brackets should be performed modulo q. However, multiplication by m/q must be a simple integer multiplication, without reduction modulo q, to eliminate small subgroup component of the input elliptic curve point. The proposed text modification clarifies the correct types and order of multiplication.

Errata ID: 6200
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Billy Brumley
Date Reported: 2020-06-03
Verifier Name: Adrian Farrel
Date Verified: 2020-07-01

Section 4.3.1 says:

where m and q are the parameters of an elliptic curve defined in the
GOST R 34.10-2012 [GOST3411-2012] standard (m is an elliptic curve
points group order, q is an order of a cyclic subgroup), P is a non-
zero point of the subgroup; P is defined by a protocol.

It should say:

where m and q are the parameters of an elliptic curve defined in the
GOST R 34.10-2012 [GOST3411-2012] standard (m is an elliptic curve
points group order, q is an order of a cyclic subgroup), P is a non-
zero point of the subgroup; P is defined by a specification of an elliptic
curve or by a protocol. Note that in most practical cases the private key
y is unknown so the point (y*P) is just a pair of coordinates, which
MUST be checked for satisfying the curve equation before calculating
the K value.

Notes:

The proposed text clarifies the P point specification ways and the need to check the public key of one side for belonging to the elliptic curve used by the opposite side.

Errata ID: 6201
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Billy Brumley
Date Reported: 2020-06-03
Verifier Name: Adrian Farrel
Date Verified: 2020-07-01

Section 4.3.2 says:

where m and q are the parameters of an elliptic curve defined in the
GOST R 34.10-2012 [GOST3411-2012] standard (m is an elliptic curve
points group order, q is an order of a cyclic subgroup), P is a non-
zero point of the subgroup; P is defined by a protocol.

It should say:

where m and q are the parameters of an elliptic curve defined in the
GOST R 34.10-2012 [GOST3411-2012] standard (m is an elliptic curve
points group order, q is an order of a cyclic subgroup), P is a non-
zero point of the subgroup; P is defined by a specification of an elliptic
curve or by a protocol. Note that in most practical cases the private key
y is unknown so the point (y*P) is just a pair of coordinates, which
MUST be checked for satisfying the curve equation before calculating
the K value.

Notes:

The proposed text clarifies the P point specification ways and the need to check the public key of one side for belonging to the elliptic curve used by the opposite side.

RFC 7839, "Access-Network-Identifier Option in DHCP", June 2016

Source of RFC: dhc (int)

Errata ID: 7016
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alan DeKok
Date Reported: 2022-07-07
Verifier Name: Eric Vyncke
Date Verified: 2022-07-12

Section 4.4.1 says:

   Length
      4

   Operator-Identifier
      The Operator-Identifier is a variable-length Private Enterprise
      Number (PEN) ...

It should say:

   Length
      4

   Operator-Identifier
      The Operator-Identifier is a 32-bit Private Enterprise
      Number (PEN) ...

Notes:

Either the length is 4, and the contents are 32-bits. Or the length is >1, and the length is variable.

My guess is that the intention is to have a fixed length. The variable-length encoding from RFC 6757 is likely not needed here.


*** verifier note ***
See Bernie Volz's reply in https://mailarchive.ietf.org/arch/msg/dhcwg/Y4yaYwaqxS0B2nWw5f4xER2fSMk/

RFC 7841, "RFC Streams, Headers, and Boilerplates", May 2016

Note: This RFC has been updated by RFC 9280

Source of RFC: IAB

Errata ID: 5248
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Klensin
Date Reported: 2018-01-31
Verifier Name: Robert Sparks
Date Verified: 2018-02-02

Section A.2.2 says:

Documents approved for publication
by the [stream approver -- currently, one of: "IAB",
"IRSG", or "RFC Editor"] are not a candidate for any level of
Internet Standard; ...

It should say:

Documents approved for publication by the [stream approver
-- currently, one of: "IAB", "IRSG", or "RFC Editor"] are
not candidates for any level of Internet Standard; ...

Notes:

--- Verifier Notes : The originally submitted "Corrected Text" is below. The Corrected Text was edited to make it clear which option was chosen. ---

Documents approved for publication by the [stream approver
-- currently, one of: "IAB", "IRSG", or "RFC Editor"] are
not candidates for any level of Internet Standard; ...

--or--

A document approved for publication by the [stream approver
-- currently, one of: "IAB", "IRSG", or "RFC Editor"] is
not a candidate for any level of Internet Standard; ...

--- End Verifier Notes ---
The present sentence is egregiously bad English, at roughly the "every fourth-grader is English-speaking countries is expected to know better" level. Having it in this document and, because of what it specifies, in every non-IETF-stream RFC, reflects badly on the IAB, the RFC Editor, and the RFC Series. In addition, because we do not explicitly differentiate between boilerplate text and text supplied and approved by authors, it may reflect badly on individual document authors.

If it is not possible for this erratum to be quickly reviewed and approved, with the RFC Editor allowed to make this (and if necessary other) clearly editorial change to boilerplate text for documents published after today, I suggest that explicit notes be added to "Status of this Memo" sections going forward that identify the boilerplate text and its sources. For example, a new first sentence should be added immediately after "Status of this Memo" that says "This section and the one on Copyright that follows, are as specified by the Internet Architecture Board [RFC7841] and the Trustees of the IETF Trust."

The problem identified here may suggest that, when 7841 and similar documents are revised, it may be better to establish principles and leave specific text to agreements between the relevant bodies and the RFC Editor rather than building exact text to be used into archival and hard-to-revise documents.

RFC 7849, "An IPv6 Profile for 3GPP Mobile Devices", May 2016

Source of RFC: INDEPENDENT

Errata ID: 4702
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Denis Ovsienko
Date Reported: 2016-05-28
Verifier Name: Nevil Brownlee
Date Verified: 2016-06-08

Section Abstract says:

   This document defines a profile that is a superset of the connection
   to IPv6 cellular networks defined in the IPv6 for Third Generation
   Partnership Project (3GPP) Cellular Hosts document.  This document
   defines a profile that is a superset of the connections to IPv6
   cellular networks defined in "IPv6 for Third Generation Partnership
   Project (3GPP) Cellular Hosts" (RFC 7066).

   Both mobile hosts and mobile devices with the capability to share
   their 3GPP mobile connectivity are in scope.

It should say:

   This document defines a profile that is a superset of the connection 
   to IPv6 cellular networks defined in "IPv6 for Third Generation  
   Partnership Project (3GPP) Cellular Hosts" (RFC 7066).  This document 
   defines an IPv6 profile that a number of operators recommend in order 
   to connect 3GPP mobile devices to an IPv6-only or dual-stack wireless 
   network (including a 3GPP cellular network) with a special focus on 
   IPv4 service continuity features. 

   Both mobile hosts and mobile devices with the capability to share 
   their 3GPP mobile connectivity are in scope.  

Notes:

The first occurrence seems to be an older duplicate.

RFC 7852, "Additional Data Related to an Emergency Call", July 2016

Source of RFC: ecrit (art)

Errata ID: 6849
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: James Benner
Date Reported: 2022-02-12
Verifier Name: Murray Kucherawy
Date Verified: 2022-05-16

Section 11.7 says:

Example(s):  TEL;VALUE=uri;TYPE="main,voice";PREF=1:tel:+1-418-656-90
      00

It should say:

Example(s):  TEL;VALUE=uri;TYPE="main-number,voice";PREF=1:tel:+1-418-656-90
      00

Notes:

The type value is specified as "main-number" but in the example is simply "main".

Errata ID: 7679
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tom Hsu
Date Reported: 2023-10-16
Verifier Name: Murray Kucherawy
Date Verified: 2023-11-07

Section 6.1 says:

An example
   Call-Info header field for this would be:

   Call-Info:  https://www.example.com/23sedde3;
       purpose="EmergencyCallData.ProviderInfo"

It should say:

An example
   Call-Info header field for this would be:

   Call-Info:  https://www.example.com/23sedde3;
       purpose=EmergencyCallData.ProviderInfo

Notes:

Remove double quote on purpose attribute. It's a token type instead of "String" type.

RFC 7854, "BGP Monitoring Protocol (BMP)", June 2016

Note: This RFC has been updated by RFC 8671, RFC 9069, RFC 9515

Source of RFC: grow (ops)

Errata ID: 7194
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ahmed Elhassany
Date Reported: 2022-10-30
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2022-11-03

Section 10.8 says:

   Information type values 0 through 32767 MUST be assigned using the
   "Standards Action" policy, and values 32768 through 65530 using the
   "Specification Required" policy, defined in [RFC5226].  Values 65531
   through 65534 are Experimental, and values 0 and 65535 are Reserved.

It should say:

   Information type values 0 through 127 MUST be assigned using the
   "Standards Action" policy, and values 128 through 250 using the
   "Specification Required" policy, defined in [RFC5226].  Values 251
   through 254 are Experimental, and values 0 and 255 are Reserved.

Notes:

In Section 4.9 Peer Down Notification. The "Reason" field is defined as one octet, while the IANA consideration section is defining values as 2-octets range. This errata suggests updating the IANA registry, instead of the size of the "Reason" field in the Peer Down Notification message to avoid breaking existing implementations that use one-octet reason.

[WK]: See thread https://mailarchive.ietf.org/arch/msg/grow/s-qcQpAkFVK3beirNYqY4MYfbFw/ for tracking. IANA has confirmed that they can update registries from verified errata.

Errata ID: 7703
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Dhananjay S. Patki
Date Reported: 2023-11-16
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2023-12-11

Section 4.2 says:

      *  The L flag, if set to 1, indicates that the message reflects
         the post-policy Adj-RIB-In (i.e., its path attributes reflect
         the application of inbound policy).  It is set to 0 if the
         message reflects the pre-policy Adj-RIB-In.  Locally sourced
         routes also carry an L flag of 1.  See Section 5 for further
         detail.  This flag has no significance when used with route
         mirroring messages (Section 4.7).

It should say:

      *  The L flag, if set to 1, indicates that the message reflects
         the post-policy Adj-RIB-In (i.e., its path attributes reflect
         the application of inbound policy).  It is set to 0 if the
         message reflects the pre-policy Adj-RIB-In.  Locally sourced
         routes also carry an L flag of 1.  See Section 5 for further
         detail.  This flag has significance only when used with Route
         Monitoring messages.

Notes:

The L flag is used to indicate whether the route monitoring update reflects Adj-RIB-In pre-policy or post-policy (RFC 7854), or Adj-RIB-Out pre-policy or post-policy (RFC 8671). It does not apply to any message other than the Route Monitoring message.

Errata ID: 4722
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2016-06-28
Verifier Name: Joel Jaeggli
Date Verified: 2017-03-29

Section 3.1 4.8 7 says:

Stats Reports

It should say:

Statistics Reports

Notes:

The message of type 1 is called "Statistics Report" in the IANA registry https://www.iana.org/assignments/bmp-parameters/bmp-parameters.xml#message-types (I used it as the reference) and in sections 4.1 and 10.1 but "Stats Report" in sections 3.1, 4.8 and 7.

RFC 7855, "Source Packet Routing in Networking (SPRING) Problem Statement and Requirements", May 2016

Source of RFC: spring (rtg)

Errata ID: 5385
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: James Bensley
Date Reported: 2018-06-08
Verifier Name: RFC Editor
Date Verified: 2018-06-08

Section 1 says:

   Hence, the policy is instantiated in the packet header and does not
   requires any policy state in midpoints and tail-ends.

It should say:

   Hence, the policy is instantiated in the packet header and does not
   require any policy state in midpoints and tail-ends.

Notes:

require/requires - singular/plural.
Verifier Notes: subject/verb agreement error.

RFC 7868, "Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP)", May 2016

Source of RFC: INDEPENDENT

Errata ID: 5030
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Travis P. Bonfigli
Date Reported: 2017-06-06
Verifier Name: Nevil Brownlee
Date Verified: 2017-07-20

Section 6.7.4 says:

6.7.4.  0x0004 - SOFTWARE_VERSION_TYPE

           Field                        Length
           Vender OS major version        1
           Vender OS minor version        1
           EIGRP major revision           1
           EIGRP minor revision           1

   The EIGRP TLV Version fields are used to determine TLV format
   versions.  Routers using Version 1.2 TLVs do not understand Version
   2.0 TLVs, therefore Version 2.0 routers must send the packet with
   both TLV formats in a mixed network.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            0x0004             |            0x000C             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Vendor Major V.|Vendor Minor V.| EIGRP Major V.| EIGRP Minor V.|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

6.7.4.  0x0004 - SOFTWARE_VERSION_TYPE

           Field                        Length
           Vender OS major version        1
           Vender OS minor version        1
           EIGRP major revision           1
           EIGRP minor revision           1

   The EIGRP TLV Version fields are used to determine TLV format
   versions.  Routers using Version 1.2 TLVs do not understand Version
   2.0 TLVs, therefore Version 2.0 routers must send the packet with
   both TLV formats in a mixed network.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            0x0004             |            0x0008             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Vendor Major V.|Vendor Minor V.| EIGRP Major V.| EIGRP Minor V.|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

Hello! In looking over the TLV construct in Section 6.7.4 0x0004 - SOFTWARE_VERSION_TYPE it appears that they might be a 'typo' with respect to the 'Length' value provided in the RFC diagram. The current value is shown as 0x000C (12 bytes), but in reality it appears that it should be 0x0008 (8 bytes) given the format/length of the specific TLV being discussed. Thank you.

Cheers,
Travis

Errata ID: 5952
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christopher Hart
Date Reported: 2019-12-30
Verifier Name: Adrian Farrel
Date Verified: 2020-01-19

Section 6.5 says:

   RS-Flag (0x04): The Restart flag is set in the HELLO and the UPDATE
      packets during the restart period.  The router looks at the RS-
      Flag to detect if a neighbor is restarting.  From the restarting
      routers perspective, if a neighboring router detects the RS-Flag
      set, it will maintain the adjacency, and will set the RS-Flag in
      its UPDATE packet to indicated it is doing a soft restart.

It should say:

   RS-Flag (0x04): The Restart flag is set in the HELLO and the UPDATE
      packets during the restart period.  A router looks at the RS-
      Flag to detect if a neighbor is restarting.  From the restarting
      router's perspective, if a neighboring router detects the RS-
      Flag is set, the neighboring router will maintain the adjacency
      with the restarting router. The restarting router will set the
      RS-Flag in its UPDATE packet to indicate it is performing a soft
      restart.

Notes:

Cleaning up the grammar for the RS-Flag portion of Section 6.5. The grammar used in the original text can be ambiguously interpreted as to whether the restarting router initially sets the RS-Flag in its Update packet, or the neighboring router initially sets the RS-Flag in its Update packet.

Errata ID: 6086
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rafał Cygnarowski
Date Reported: 2020-04-11
Verifier Name: RFC Editor
Date Verified: 2020-04-21

Section 5.4.2. says:

   Routes learned
   though interfaces that EIGRP is NOT using to reach the destination
   may have the route advertised out those interfaces.

It should say:

   Routes learned
   through interfaces that EIGRP is NOT using to reach the destination
   may have the route advertised out those interfaces.

Notes:

Typo in 'through' word.

Errata ID: 6092
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rafał Cygnarowski
Date Reported: 2020-04-12
Verifier Name: Adrian Farrel
Date Verified: 2020-04-22

Section 6.7.7. says:

0x0007 - PEER_ TERMINATION_TYPE

It should say:

0x0007 - PEER_TERMINATION_TYPE

Notes:

Removed extra space in section title.

Errata ID: 6318
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stanislav Asanov
Date Reported: 2020-10-24
Verifier Name: Adrian Farrel
Date Verified: 2020-10-24

Section 6.6.1 says:

Type Low: 1 octet that defines the TLV Opcode; see TLV Definitions in
   Section 3.

It should say:

Type Low: 1 octet that defines the TLV Opcode; see TLV Definitions in
   Sections 6.7, 6.8, and 6.9.

Notes:

There are no TLV definitions in Section 3. The TLV Opcodes are defined in Sections 6.7, 6.8, 6.9.

Errata ID: 6320
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stanislav Asanov
Date Reported: 2020-10-26
Verifier Name: Adrian Farrel
Date Verified: 2020-10-27

Section 6.9.3.8.1 says:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       0x07    |       Offset  | Next-Hop Addr. (Upper 2 bytes)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IPv4 Address (Lower 2 bytes)  |       RID (Upper 2 bytes)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        RID (Upper 2 bytes)    | Admin Tag (Upper 2 bytes)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Admin Tag (Upper 2 bytes)     |Extern Protocol| Flags Field   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       0x07    |       Offset  | Next-Hop Addr. (Upper 2 bytes)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next-Hop Addr. (Lower 2 bytes)|       RID (Upper 2 bytes)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        RID (Lower 2 bytes)    | Admin Tag (Upper 2 bytes)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Admin Tag (Lower 2 bytes)     |Extern Protocol| Flags Field   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

1. There is no subfield named "IPv4 Address" in AddPath field. The label in the 5th and 6th octets of the AddPath field is a typo, and it should read "Next-Hop Addr. (Lower 2 bytes)".
2. The subfield "RID (Upper 2 bytes)" is repeated in the AddPath field, and there is no subfield for lower 2 bytes of RID. The same with "Admin Tag (Upper 2 bytes)" subfield.

Errata ID: 6322
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stanislav Asanov
Date Reported: 2020-10-27
Verifier Name: Adrian Farrel
Date Verified: 2020-10-29

Section 6.9.3.8.2. says:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       0x07     |       Offset |         Next-Hop Address      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   |                            (16 octets)                        |
   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
   |                               |       RID (Upper 2 byes)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        RID (Upper 2 byes)     | Admin Tag (Upper 2 byes)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Admin Tag (Upper 2 byes)      | Extern Protocol | Flags Field |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       0x07     |       Offset |         Next-Hop Address      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   |                            (16 octets)                        |
   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
   |                               |       RID (Upper 2 bytes)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        RID (Lower 2 bytes)    | Admin Tag (Upper 2 bytes)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Admin Tag (Lower 2 bytes)     | Extern Protocol | Flags Field |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

The subfield "RID (Upper 2 bytes)" is repeated in the AddPath with IPv6 Next Hop field, and there is no subfield for lower 2 bytes of RID. The same with "Admin Tag (Upper 2 bytes)" subfield. Typo in the word "bytes".

Errata ID: 6852
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eren Elçin
Date Reported: 2022-02-15
Verifier Name: RFC Editor

Section 6.8.6.3 says:

This TLV is used to provide community tags for specific IPv4 destinations.

It should say:

This TLV is used to provide community tags for specific IPv6 destinations.

Notes:

It is under the IPv6 section of the RFC. IPv4 and IPv6 sections are really similiar and consecutively written, so its highly probable that after copy pasting the common information for both IPv4 and IPv6 to each other, forget to change that part from IPv4 to IPv6.

Errata ID: 6853
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eren Elçin
Date Reported: 2022-02-16
Verifier Name: RFC Editor
Date Verified: 2022-04-06

Section 6.9.3.8.1. says:

Next-Hop Address: An IPv4 address represented by four 8-bit values
      (total 4 octets).  If the value is zero (0), the IPv6 address from
      the received IPv4 header is used as the next hop for the route.
      Otherwise, the specified IPv4 address will be used.

It should say:

Next-Hop Address: An IPv4 address represented by four 8-bit values
      (total 4 octets).  If the value is zero (0), the IPv4 address from
      the received IPv4 header is used as the next hop for the route.
      Otherwise, the specified IPv4 address will be used.

Notes:

The address format in this Packet format at this section of the RFC is made for IPv4 type addresses. So, "IPv6 address from the received IPv4 header" should be "IPv4 address from the received IPv4 header".

RFC 7871, "Client Subnet in DNS Queries", May 2016

Source of RFC: dnsop (ops)

Errata ID: 4735
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Robert Edmonds
Date Reported: 2016-07-08
Verifier Name: Joel Jaeggli
Date Verified: 2017-03-29

Section 13 says:

   7.   Due its internal implementation, ANS finds a response that is
        tailored for the whole /16 of the client that performed the
        query.

   8.   ANS adds an ECS option in the response, containing:
[...]
        *  SCOPE PREFIX-LENGTH set to 0x30, indicating a /48 network.

It should say:

   7.   Due its internal implementation, ANS finds a response that is
        tailored for the whole /48 of the client that performed the
        query.

   8.   ANS adds an ECS option in the response, containing:
[...]
        *  SCOPE PREFIX-LENGTH set to 0x30, indicating a /48 network.

Notes:

The prose description in step 7 does not match the ECS option described in step 8. Either both should say "/16" or both should say "/48". Probably /48 was meant, since a /16 would be a huge amount of IPv6 address space.

RFC 7872, "Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World", June 2016

Source of RFC: v6ops (ops)

Errata ID: 4729
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2016-07-05
Verifier Name: Joel Jaeggli
Date Verified: 2017-03-29

Section A.1 says:

The domain names corresponding to the WIPv6LD dataset is
      available at
      <http://www.si6networks.com/datasets/wipv6day-domains.txt>.

It should say:

given that this was a set of names used for a one time test 
it would not be expected to change.

a stable reference to it would be:

"https://web.archive.org/web/20150313063829/
http://www.si6networks.com/datasets/wipv6day-domains.txt"

note line truncated due to 72 char limit

Notes:

% wget http://www.si6networks.com/datasets/wipv6day-domains.txt
--2016-07-05 11:56:27-- http://www.si6networks.com/datasets/wipv6day-domains.txt
Resolving www.si6networks.com (www.si6networks.com)... 2001:67c:27e4::14, 91.239.96.14
Connecting to www.si6networks.com (www.si6networks.com)|2001:67c:27e4::14|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://www.si6networks.com/datasets/wipv6day-domains.txt [following]
--2016-07-05 11:56:28-- https://www.si6networks.com/datasets/wipv6day-domains.txt
Connecting to www.si6networks.com (www.si6networks.com)|2001:67c:27e4::14|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2016-07-05 11:56:28 ERROR 404: Not Found.

RFC 7889, "The IMAP APPENDLIMIT Extension", May 2016

Source of RFC: imapapnd (art)

Errata ID: 5726
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stan Kalisch
Date Reported: 2019-05-20
Verifier Name: Barry Leiba
Date Verified: 2019-05-20

Section 3.2 says:

   C: t1 LIST "" % RETURN (STATUS (APPENDLIMIT))
   S: * LIST () "."  "INBOX"
   S: * STATUS "INBOX" (APPENDLIMIT 257890)
   S: t1 OK List completed.

It should say:

   C: t1 LIST "" % RETURN (STATUS (APPENDLIMIT))
   S: * LIST () "." "INBOX"
   S: * STATUS "INBOX" (APPENDLIMIT 257890)
   S: t1 OK List completed.

Notes:

Line 198 contains two spaces between ""."" and ""INBOX"" instead of one. While I had the instinct to mark this as editorial, this sample server response, whose genesis appears to be RFC 5819, ended up in two IDs (which were corrected before they became RFCs) as well. In any event, given that this response also violates the ABNF, and given the RFC Ed.'s guideline on ambiguity, I'm just marking it as technical. I'll leave it to others more familiar with the practical issues for various implementers to make the final determination on how to label it.

----- Verifier notes -----
Yes, this is an error: it comes from a combination of the RFC Editor style of double-spacing between sentences, the construction of the examples in XML in a manner that doesn't distinguish them from sentences, and the fact that it's nearly impossible to notice the situation when one is giving a final review.

Editorial, though, because it's in examples. The ABNF is the authoritative place, and that's correct.

RFC 7906, "NSA's Cryptographic Message Syntax (CMS) Key Management Attributes", June 2016

Source of RFC: INDEPENDENT

Errata ID: 5850
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2019-08-29
Verifier Name: Adrian Farrel
Date Verified: 2021-06-01

Section Appendix A says:

   id-enumeratedRestrictiveAttributes OBJECT IDENTIFIER ::=
     { 2 16 840 1 101 2 1 8 3 4 }

   id-enumeratedPermissiveAttributes OBJECT IDENTIFIER ::=
     { 2 16 840 1 101 2 1 8 3 1 }

   EnumeratedTag ::= SEQUENCE {
     tagName          OBJECT IDENTIFIER,
     attributeList    SET OF SecurityAttribute }

   SecurityAttribute ::= INTEGER (0..MAX)

It should say:

   id-enumeratedRestrictiveAttributes OBJECT IDENTIFIER ::=
     { 2 16 840 1 101 2 1 8 3 4 }

   id-enumeratedPermissiveAttributes OBJECT IDENTIFIER ::=
     { 2 16 840 1 101 2 1 8 3 1 }

   EnumeratedTag ::= SEQUENCE {
     tagName          OBJECT IDENTIFIER,
     attributeList    SET OF SecurityAttribute }

    id-informativeAttributes OBJECT IDENTIFIER ::=
      { 2 16 840 1 101 2 1 8 3 3 }

    InformativeTag ::= SEQUENCE {
      tagName     OBJECT IDENTIFIER,
      attributes  FreeFormField }

    FreeFormField ::= CHOICE {
      bitSetAttributes    BIT STRING,
      securityAttributes  SET OF SecurityAttribute }

   SecurityAttribute ::= INTEGER (0..MAX)

Notes:

RFC 7906, Section 17.1 includes the definition of the Informative Tag, but it does not appear in the ASN.1 module in Appendix A. This change adds the Informative Tag to the ASN.1 module.

RFC 7914, "The scrypt Password-Based Key Derivation Function", August 2016

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 5871
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2019-10-07
Verifier Name: Benjamin Kaduk
Date Verified: 2019-10-10

Section 7.1 says:

   scrypt-0 {1 3 6 1 4 1 11591 4 10}

   DEFINITIONS ::= BEGIN

   id-scrypt OBJECT IDENTIFIER ::= {1 3 6 1 4 1 11591 4 11}

   scrypt-params ::= SEQUENCE {
       salt OCTET STRING,
       costParameter INTEGER (1..MAX),
       blockSize INTEGER (1..MAX),
       parallelizationParameter INTEGER (1..MAX),
       keyLength INTEGER (1..MAX) OPTIONAL
   }

   PBES2-KDFs ALGORITHM-IDENTIFIER ::=
          { {scrypt-params IDENTIFIED BY id-scrypt}, ... }

   END

It should say:

   Module-scrypt-0 {1 3 6 1 4 1 11591 4 10}

   DEFINITIONS ::= BEGIN

   IMPORTS
     ALGORITHM-IDENTIFIER
       FROM PKCS5v2-0 -- [RFC2898]
         { iso(1) member-body(2) us(840) rsadsi(113549)
           pkcs(1) pkcs-5(5) modules(16) pkcs5v2-0(1) } ;

   id-scrypt OBJECT IDENTIFIER ::= {1 3 6 1 4 1 11591 4 11}

   Scrypt-params ::= SEQUENCE {
       salt OCTET STRING,
       costParameter INTEGER (1..MAX),
       blockSize INTEGER (1..MAX),
       parallelizationParameter INTEGER (1..MAX),
       keyLength INTEGER (1..MAX) OPTIONAL
   }

   PBES2-KDFs ALGORITHM-IDENTIFIER ::=
          { {Scrypt-params IDENTIFIED BY id-scrypt}, ... }

   END

Notes:

The ASN.1 module does not compile without some minor corrections.

First, ALGORITHM-IDENTIFIER needs to be defined. The simplest solution is to IMPORT it from RFC 2898.

Second, the module name and the scrypt-params structure name must begin with capital letters. Small changes are made to meet these ASN.1 requirements.

Errata ID: 6972
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Gacel Perfinian
Date Reported: 2022-05-11
Verifier Name: Paul Wouters
Date Verified: 2024-01-17

Section 2 says:

At the current time, r=8 and p=1 appears to yield good results, but as memory latency and CPU parallelism increase, it is likely that the optimum values for both r and p will increase.

It should say:

At the current time, r=8 and p=1 appears to yield good results, but as memory latency decrease and CPU parallelism increase, it is likely that the optimum values for both r and p will increase.

Notes:

The wording in itself is a bit unclear, but the phrase "but as memory latency and CPU parallelism increase" might be interpreted as "but as memory latency increase and CPU parallelism increase", which in combination with the following phrase "it is likely that the optimum values for both r and p will increase" is inconsistent with how scrypt operates. All other things being equal (including but not limited to the parameters used and CPU or ASIC performance), the scrypt algorithm have an inverse-proportional relationship to memory latency, especially if the low-latency memory can contain all of the temporary computational data the algorithm needs.

Paul Wouters(AD): This seems correct, but as scrypt has been surpassed by argon2 (RFC9106) marked as Verified as no document update is expected for scrypt.

RFC 7915, "IP/ICMP Translation Algorithm", June 2016

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: ops

Errata ID: 6955
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Dan Gilboa Waizman
Date Reported: 2022-05-06
Verifier Name: Robert Wilton
Date Verified: 2024-01-12

Section 4.5 says:

Calculating an IPv6 checksum and forwarding the packet (which has performance implications).

It should say:

Calculating an UDP checksum and forwarding the packet (which has performance implications).

Notes:

IPv6 doesn't have a checksum. The text appears to refer to the UDP checksum

RFC 7919, "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)", August 2016

Source of RFC: tls (sec)

Errata ID: 7579
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tim Geiser
Date Reported: 2023-07-31
Verifier Name: Paul Wouters
Date Verified: 2024-03-21

Section Appendix A says:

The primes in these finite field groups are all safe primes; that is,
a prime p is a safe prime when q = (p-1)/2 is also prime.  Where e is
the base of the natural logarithm and square brackets denote the
floor operation, the groups that initially populate this registry are
derived for a given bit length b by finding the lowest positive
integer X that creates a safe prime p where:

 p = 2^b - 2^{b-64} + {[2^{b-130} e] + X } * 2^64 - 1

It should say:

The primes in these finite field groups are all safe primes; that is,
a prime p is a safe prime when q = (p-1)/2 is also prime.  Where e is
the base of the natural logarithm and square brackets denote the
floor operation, the groups that initially populate this registry are
derived for a given bit length b by finding the lowest positive
integer X that creates a safe prime p where:

 p = 2^b - 2^{b-64} + {[2^{b-130} * e] + X } * 2^64 - 1

Notes:

The multiplication sign ('*' in ASCII) is missing in the explanatory introduction of Appendix A that describes the equation used for deriving the primes. It is correct in all five concrete derivations A.1 through A.5

RFC 7929, "DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP", August 2016

Source of RFC: dane (sec)

Errata ID: 4796
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Daniel Kahn Gillmor
Date Reported: 2016-09-08
Verifier Name: Stephen Farrell
Date Verified: 2016-09-08

Section 3 says:

   6.  The domain name (the "right-hand side" of the email address,
       called the "domain" in [RFC5322]) is appended to the result of
       step 2 to complete the prepared domain name.

It should say:

   6.  The domain name (the "right-hand side" of the email address,
       called the "domain" in [RFC5322]) is appended to the result of
       step 5 to complete the prepared domain name.

Notes:

Technically, it should be step 5, not step 2: after step 2, there is no _openpgpkey label in the composed domain name. step 5 adds the _openpgpkey label.

Errata ID: 4768
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: James Manger
Date Reported: 2016-08-08
Verifier Name: Stephen Farrell
Date Verified: 2016-08-08

Section 5.3. says:

For example, if the OPENPGPKEY RR query for hugh@example.com
(8d57[...]b7._openpgpkey.example.com) yields a CNAME to
8d57[...]b7._openpgpkey.example.net, and an OPENPGPKEY RR for
8d57[...]b7._openpgpkey.example.net exists,

It should say:

For example, if the OPENPGPKEY RR query for hugh@example.com
(c93f[...]d6._openpgpkey.example.com) yields a CNAME to
c93f[...]d6._openpgpkey.example.net, and an OPENPGPKEY RR for
c93f[...]d6._openpgpkey.example.net exists,

Notes:

The example hash 8d57[...]b7 is wrong. It has been calculated with the wrong hash algorithm: SHA-224, instead of SHA-256. The correct hash is c93f[...]d6, which is shown in the example in section 3.

RFC 7932, "Brotli Compressed Data Format", July 2016

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 5948
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bret Abel
Date Reported: 2019-12-28
Verifier Name: Benjamin Kaduk
Date Verified: 2019-12-31

Section 3.5 says:

   Note that a code of 16 that follows an immediately preceding 16
   modifies the previous repeat count, which becomes the new repeat
   count.  The same is true for a 17 following a 17.  A sequence of
   three or more 16 codes in a row or three of more 17 codes in a row is
   possible, modifying the count each time.  Only the final repeat count
   is used.  The modification only applies if the same code follows.  A
   16 repeat does not modify an immediately preceding 17 count nor vice
   versa.

It should say:

   Note that a code of 16 that follows an immediately preceding 16
   modifies the previous repeat count, which becomes the new repeat
   count.  The same is true for a 17 following a 17.  A sequence of
   three or more 16 codes in a row or three or more 17 codes in a row is
   possible, modifying the count each time.  Only the final repeat count
   is used.  The modification only applies if the same code follows.  A
   16 repeat does not modify an immediately preceding 17 count nor vice
   versa.

Notes:

"three of more" should be "three or more"

RFC 7940, "Representing Label Generation Rulesets Using XML", August 2016

Source of RFC: lager (art)

Errata ID: 5986
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: KIM Kyongsok
Date Reported: 2020-02-22
Verifier Name: Barry Leiba
Date Verified: 2020-02-22

Section 6.3.1 says:

   A simple rule to match a label where all characters are members of
   some class called "preferred-codepoint":          

       <rule name="preferred-label">
           <start />
           <class by-ref="preferred-codepoint" count="1"/>
           <end />
       </rule>

It should say:

   A simple rule to match a label where all characters are members of
   some class called "preferred-codepoint":           

       <rule name="preferred-label">
           <start />
           <class by-ref="preferred-codepoint" count="1+"/>
           <end />
       </rule>

Notes:

Currently the value for count is 1, which means that the rule will match a label composed of only one char.
However, since the rule is supposed to match a label composed one or more chars, the value ofr count must be "1+" .

Errata ID: 5987
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: KIM Kyongsok
Date Reported: 2020-02-22
Verifier Name: Barry Leiba
Date Verified: 2020-02-22

Section 5.3.1 says:

   Variant code points are specified using one of more "var" elements as
   children of a "char" element.  

It should say:

   Variant code points are specified using one or more "var" elements as
   children of a "char" element.  

Notes:

Based on the context, "one or more" seems correct, NOT "one of more".

Errata ID: 6102
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Bauland
Date Reported: 2020-04-14
Verifier Name: Barry Leiba
Date Verified: 2020-04-14

Section 5.4.2. says:

Any "char", "range", or "variant" element in the "data" section may contain an OPTIONAL "comment" attribute.

It should say:

Any "char", "range", or "var" element in the "data" section may contain an OPTIONAL "comment" attribute.

Notes:

The variant element is <var> not <variant>.

Errata ID: 6105
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Bauland
Date Reported: 2020-04-14
Verifier Name: Barry Leiba
Date Verified: 2020-04-14

Section 7.2.1. says:

A label "yy" would have the variants "xy", "yx", and "xx".  Because the variant mapping from "y" to "x" is of type "allocatable" and a mapping from "y" to "y" is not defined, the labels "xy" and "yx" trigger the "any-variant" condition on the third label.

It should say:

A label "yy" would have the variants "xy", "yx", and "xx".  Because the variant mapping from "y" to "x" is of type "allocatable" and a mapping from "y" to "y" is not defined, the labels "xy" and "yx" trigger the "any-variant" condition on the third action.

Notes:

The "third label" at the end of the sentence makes no sense in this context, instead it should read that the condition of the "third action" is triggered.

Errata ID: 6106
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Asmus Freytag
Date Reported: 2020-04-14
Verifier Name: Barry Leiba
Date Verified: 2020-04-14

Section 7.2.1 says:

Nevertheless, they do participate in the permutation of variant
   labels for n-repertoire labels 

It should say:

Nevertheless, they do participate in the permutation of variant
   labels for in-repertoire labels 

Notes:

The intention is the contrast to "out-of-repertoire"; no term "n-repertoire" is defined.

RFC 7945, "Information-Centric Networking: Evaluation and Security Considerations", September 2016

Source of RFC: IRTF

Errata ID: 6428
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jie Li
Date Reported: 2021-02-14
Verifier Name: Colin Perkins
Date Verified: 2021-02-16

Throughout the document, when it says:

This RFC represents the consensus of the <insert_name> Research Group of the Internet Research Task Force (IRTF). 

It should say:

This RFC represents the consensus of the Information-Centric Networking Research Group (ICNRG) of the Internet Research Task Force (IRTF). 

Notes:

<insert_name> should be replaced by real name.

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

RFC 7951, "JSON Encoding of Data Modeled with YANG", August 2016

Source of RFC: netmod (ops)

Errata ID: 7020
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jernej Tuljak
Date Reported: 2022-07-11
Verifier Name: Rob Wilton
Date Verified: 2023-10-02

Section 6.8 says:

An "identityref" value is represented as a string -- the name of an
identity.  If the identity is defined in a module other than the leaf
node containing the identityref value, the namespace-qualified form
(Section 4) MUST be used.  Otherwise, both the simple and namespace-
qualified forms are permitted.

It should say:

An "identityref" value is represented as a string -- the name of an
identity.  If the identity is defined in a module other than the leaf or
leaf-list node containing the identityref value, the namespace-qualified
form (Section 4) MUST be used.  Otherwise, both the simple and namespace-
qualified forms are permitted.

Notes:

The original text omitted leaf-list nodes, which may also be of "identityref" type.

RFC 7953, "Calendar Availability", August 2016

Source of RFC: calext (art)

Errata ID: 5420
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julian Cowley
Date Reported: 2018-07-14
Verifier Name: Alexey Melnikov
Date Verified: 2018-07-26

Section 3.1 says:

   availabilityprop  = *(
                    ;
                    ; the following are REQUIRED
                    ; but MUST NOT occur more than once
                    ;
                    dtstamp / uid
                    ;
                    ; the following are OPTIONAL
                    ; but MUST NOT occur more than once
                    ;
                    busytype / class / created / description /
                    dtstart / last-mod / location / organizer /
                    priority /seq / summary / url /
                    ;
                    ; Either 'dtend' or 'duration' MAY appear
                    ; in an 'availableprop', but 'dtend' and
                             ^^^^^^^^^^^^^
                    ; 'duration' MUST NOT occur in the same
                    ; 'availabilityprop'.
                    ; 'duration' MUST NOT be present if
                    ; 'dtstart' is not present
                    ;
                    dtend / duration /
                    ;
                    ; the following are OPTIONAL
                    ; and MAY occur more than once
                    ;
                    categories / comment / contact /
                    x-prop / iana-prop
                    ;
                    )

It should say:

   availabilityprop  = *(
                    ;
                    ; the following are REQUIRED
                    ; but MUST NOT occur more than once
                    ;
                    dtstamp / uid
                    ;
                    ; the following are OPTIONAL
                    ; but MUST NOT occur more than once
                    ;
                    busytype / class / created / description /
                    dtstart / last-mod / location / organizer /
                    priority /seq / summary / url /
                    ;
                    ; Either 'dtend' or 'duration' MAY appear
                    ; in an 'availabilityprop', but 'dtend' and
                             ^^^^^^^^^^^^^^^^
                    ; 'duration' MUST NOT occur in the same
                    ; 'availabilityprop'.
                    ; 'duration' MUST NOT be present if
                    ; 'dtstart' is not present
                    ;
                    dtend / duration /
                    ;
                    ; the following are OPTIONAL
                    ; and MAY occur more than once
                    ;
                    categories / comment / contact /
                    x-prop / iana-prop
                    ;
                    )

Notes:

The text 'availableprop' is a typo and should be 'availabilityprop' instead. The text is only concerned with 'dtend' and 'duration' in the VAVAILABILITY component, and has nothing to do with the AVAILABLE component and its associated 'availableprop'.

RFC 7958, "DNSSEC Trust Anchor Publication for the Root Zone", August 2016

Source of RFC: INDEPENDENT

Errata ID: 5932
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Paul Hoffman
Date Reported: 2019-12-11
Verifier Name: Adrian Farrel
Date Verified: 2020-01-26

Section 2.1.2 says:

  Note that the KeyDigest element is optional; if it
  is not given, the trust anchor can be used until a KeyDigest element
  covering the same DNSKEY record, but having a validUntil attribute,
  is trusted by the relying party.

It should say:

  Note that the validUntil attribute of the KeyDigest element is
  optional. If the relying party is using a trust anchor that has a
  KeyDigest element that does not have a validUntil attribute, it can
  change to a trust anchor with a KeyDigest element that does have a
  validUntil attribute, as long as that trust anchor's validUntil
  attribute is in the future and the DNSKEY elements of the KeyDigest
  are the same as the previous trust anchor.

Notes:

It is the validUntil attribute that is optional, not the KeyDigest element. Also, it was noted that the sentence did not clearly explain the logic.

RFC 7959, "Block-Wise Transfers in the Constrained Application Protocol (CoAP)", August 2016

Note: This RFC has been updated by RFC 8323

Source of RFC: core (wit)

Errata ID: 7523
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christian Amsüss
Date Reported: 2023-05-24
Verifier Name: Murray Kucherawy
Date Verified: 2023-07-08

Section 3 says:

   then the block number (NUM), more bit (M), and block size exponent
   (2**(SZX+4)) separated by slashes.  For example, a Block2 Option

It should say:

   then the block number (NUM), more bit (M), and block size
   (2**(SZX+4)) separated by slashes.  For example, a Block2 Option

Notes:

The examples are given in the style of "2:1/1/128", wher 128 is the size (2**(SZX+4)), not the size exponent -- it contains the size exponent in the expression, but the full expression is the size.

(Reporting this as an erratum because the use of "SZX" for "size" instead of "size exponent" has some potential for spreading and creating confusion; for example in Wireshark at https://gitlab.com/wireshark/wireshark/-/merge_requests/10763)

RFC 7970, "The Incident Object Description Exchange Format Version 2", November 2016

Source of RFC: mile (sec)

Errata ID: 5351
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Logan Widick
Date Reported: 2018-05-07
Verifier Name: Roman Danyliw
Date Verified: 2022-01-20

Section 2.16 says:

The attributes of the iodef:ExtensionType type are:

   name
      Optional.  STRING.  A free-form name of the field or data element.

   dtype
      Required.  ENUM.  The data type of the element content.  The
      default value is "string".  These values are maintained in the
      "ExtensionType-dtype" IANA registry per Section 10.2.

      1.   boolean.  The element content is of type BOOLEAN.

      2.   byte.  The element content is of type BYTE.

      3.   bytes.  The element content is of type HEXBIN.

      4.   character.  The element content is of type CHARACTER.

      5.   date-time.  The element content is of type DATETIME.

      6.   ntpstamp.  Same as date-time.

      7.   integer.  The element content is of type INTEGER.

      8.   portlist.  The element content is of type PORTLIST.

      9.   real.  The element content is of type REAL.

      10.  string.  The element content is of type STRING.

      11.  file.  The element content is a base64-encoded binary file
           encoded as a BYTE[] type.

      12.  path.  The element content is a file-system path encoded as a
           STRING type.

      13.  frame.  The element content is a Layer 2 frame encoded as a
           HEXBIN type.

      14.  packet.  The element content is a Layer 3 packet encoded as a
           HEXBIN type.

      15.  ipv4-packet.  The element content is an IPv4 packet encoded
           as a HEXBIN type.

      16.  ipv6-packet.  The element content is an IPv6 packet encoded
           as a HEXBIN type.

      17.  url.  The element content is of type URL.

      18.  csv.  The element content is a comma-separated value (CSV)
           list per Section 2 of [RFC4180] encoded as a STRING type.

      19.  winreg.  The element content is a Microsoft Windows registry
           key encoded as a STRING type.

      20.  xml.  The element content is XML.  See Section 5.2.

      21.  ext-value.  A value used to indicate that this attribute is
           extended and the actual value is provided using the
           corresponding ext-* attribute.  See Section 5.1.1.

It should say:

The attributes of the iodef:ExtensionType type are:

   name
      Optional.  STRING.  A free-form name of the field or data element.

   dtype
      Required.  ENUM.  The data type of the element content.  The
      default value is "string".  These values are maintained in the
      "ExtensionType-dtype" IANA registry per Section 10.2.

      1.   boolean.  The element content is of type BOOLEAN.

      2.   byte.  The element content is of type BYTE.

      3.   bytes.  The element content is of type HEXBIN[].

      4.   character.  The element content is of type CHARACTER.

      5.   date-time.  The element content is of type DATETIME.

      6.   ntpstamp.  Same as date-time.

      7.   integer.  The element content is of type INTEGER.

      8.   portlist.  The element content is of type PORTLIST.

      9.   real.  The element content is of type REAL.

      10.  string.  The element content is of type STRING.

      11.  file.  The element content is a base64-encoded binary file
           encoded as a BYTE[] type.

      12.  path.  The element content is a file-system path encoded as a
           STRING type.

      13.  frame.  The element content is a Layer 2 frame encoded as a
           HEXBIN[] type.

      14.  packet.  The element content is a Layer 3 packet encoded as a
           HEXBIN[] type.

      15.  ipv4-packet.  The element content is an IPv4 packet encoded
           as a HEXBIN[] type.

      16.  ipv6-packet.  The element content is an IPv6 packet encoded
           as a HEXBIN[] type.

      17.  url.  The element content is of type URL.

      18.  csv.  The element content is a comma-separated value (CSV)
           list per Section 2 of [RFC4180] encoded as a STRING type.

      19.  winreg.  The element content is a Microsoft Windows registry
           key encoded as a STRING type.

      20.  xml.  The element content is XML.  See Section 5.2.

      21.  ext-value.  A value used to indicate that this attribute is
           extended and the actual value is provided using the
           corresponding ext-* attribute.  See Section 5.1.1.

Notes:

Section 2.5.2 (explanation of HEXBIN and HEXBIN[] types) says:
" A binary octet encoded as a character tuple consistent of two
hexadecimal digits is represented in the information model by the
HEXBIN data type. A sequence of these octets is of the HEXBIN[] data
type.
The HEXBIN and HEXBIN[] data types are implemented in the data model
as an "xs:hexBinary" type per Section 3.2.15 of [W3C.SCHEMA.DTYPES]."

If I am reading that section correctly, HEXBIN is for hex-encoded things that decode to exactly one byte, while HEXBIN[] is for hex-encoded things that decode to one or more bytes. Thus, things that may decode to multiple bytes should be HEXBIN[], not HEXBIN.

The extension types in Section 2.16 that are currently HEXBIN should probably be HEXBIN[]. The name "bytes" implies decoding to multiple bytes (so it should be HEXBIN[]). Frames and packets (regardless of layer) tend to be multiple bytes long (so they should be HEXBIN[] as well).

Errata ID: 5543
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Takeshi Takahashi
Date Reported: 2018-11-04
Verifier Name: Alexey Melnikov
Date Verified: 2018-11-05

Section 8 says:

    <xs:element name="Confidence">
      <xs:complexType>
        <xs:attribute name="rating"
                      type="confidence-rating-type" use="required"/>
        <xs:attribute name="ext-rating"
                      type="xs:string" use="optional"/>
      </xs:complexType>
    </xs:element>

It should say:

    <xs:element name="Confidence">
      <xs:complexType>
        <xs:simpleContent>
          <xs:extension base="xs:float">
            <xs:attribute name="rating"
                          type="confidence-rating-type" use="required"/>
            <xs:attribute name="ext-rating"
                          type="xs:string" use="optional"/>
          </xs:extension>
        </xs:simpleContent>
      </xs:complexType>
    </xs:element>

Notes:

Section 3.12.5 says as follows:
"The content of the class is of type REAL and specifies a numerical
assessment in the confidence of the data when the value of the rating
attribute is "numeric". Otherwise, this element MUST be empty."

The current schema does not allow the confidence class to have the content (REAL type), thus the correction (note the addition of "<xs:extension base="xs:float">") is proposed.

Errata ID: 5544
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Takeshi Takahashi
Date Reported: 2018-11-04
Verifier Name: Alexey Melnikov
Date Verified: 2018-11-05

Section 8 says:

 <xs:element name="Node">
      <xs:complexType>
        <xs:sequence>
          <xs:choice maxOccurs="unbounded">
            <xs:element ref="iodef:DomainData"
                        minOccurs="0" maxOccurs="unbounded"/>
            <xs:element ref="iodef:Address"
                        minOccurs="0" maxOccurs="unbounded"/>
          </xs:choice>
          <xs:element ref="iodef:PostalAddress" minOccurs="0"/>
          <xs:element ref="iodef:Location"
                      minOccurs="0" maxOccurs="unbounded"/>
          <xs:element ref="iodef:Counter"
                      minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
      </xs:complexType>
    </xs:element>

It should say:

 <xs:element name="Node">
      <xs:complexType>
        <xs:sequence>
          <xs:choice maxOccurs="unbounded">
            <xs:element ref="iodef:DomainData"
                        maxOccurs="unbounded"/>
            <xs:element ref="iodef:Address"
                        maxOccurs="unbounded"/>
          </xs:choice>
          <xs:element ref="iodef:PostalAddress" minOccurs="0"/>
          <xs:element ref="iodef:Location"
                      minOccurs="0" maxOccurs="unbounded"/>
          <xs:element ref="iodef:Counter"
                      minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
      </xs:complexType>
    </xs:element>

Notes:

Section 3.18 says as follows:

"DomainData
Zero or more. The domain (DNS) information associated with this
node. If an Address is not provided, at least one DomainData MUST
be specified. See Section 3.19.

Address
Zero or more. The hardware, network, or application address of
the node. If a DomainData is not provided, at least one Address
MUST be specified. See Section 3.18.1."

To comply with the above definition, "minOccurs" attribute for both DomainData and Address elements need to be removed. (Current schema allows to omit both of the elements, but the RFC says that at least one of them need to be presented.)

Errata ID: 5583
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Takeshi Takahashi
Date Reported: 2018-12-25
Verifier Name: Roman Danyliw
Date Verified: 2022-01-20

Section 8 says:

    <xs:simpleType name="action-type">
      <xs:restriction base="xs:NMTOKEN">
        <xs:enumeration value="nothing"/>
        <xs:enumeration value="contact-source-site"/>
        <xs:enumeration value="contact-target-site"/>
        <xs:enumeration value="contact-sender"/>
        <xs:enumeration value="investigate"/>
        <xs:enumeration value="block-host"/>
        <xs:enumeration value="block-network"/>
        <xs:enumeration value="block-port"/>
        <xs:enumeration value="rate-limit-host"/>
        <xs:enumeration value="rate-limit-network"/>
        <xs:enumeration value="rate-limit-port"/>
        <xs:enumeration value="redirect-traffic"/>
        <xs:enumeration value="honeypot"/>
        <xs:enumeration value="upgrade-software"/>
        <xs:enumeration value="rebuild-asset"/>
        <xs:enumeration value="harden-asset"/>
        <xs:enumeration value="remediate-other"/>
        <xs:enumeration value="status-triage"/>
        <xs:enumeration value="status-new-info"/>
        <xs:enumeration value="watch-and-report"/>
        <xs:enumeration value="defined-coa"/>

It should say:

    <xs:simpleType name="action-type">
      <xs:restriction base="xs:NMTOKEN">
        <xs:enumeration value="nothing"/>
        <xs:enumeration value="contact-source-site"/>
        <xs:enumeration value="contact-target-site"/>
        <xs:enumeration value="contact-sender"/>
        <xs:enumeration value="investigate"/>
        <xs:enumeration value="block-host"/>
        <xs:enumeration value="block-network"/>
        <xs:enumeration value="block-port"/>
        <xs:enumeration value="rate-limit-host"/>
        <xs:enumeration value="rate-limit-network"/>
        <xs:enumeration value="rate-limit-port"/>
        <xs:enumeration value="redirect-traffic"/>
        <xs:enumeration value="honeypot"/>
        <xs:enumeration value="upgrade-software"/>
        <xs:enumeration value="rebuild-asset"/>
        <xs:enumeration value="harden-asset"/>
        <xs:enumeration value="remediate-other"/>
        <xs:enumeration value="status-triage"/>
        <xs:enumeration value="status-new-info"/>
        <xs:enumeration value="watch-and-report"/>
        <xs:enumeration value="training"/>
        <xs:enumeration value="defined-coa"/>

Notes:

The narrative text in Section 3.1.5 defined an enumerated value of "training" for the action attribute, but the schema omitted it.

Errata ID: 5422
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Takeshi Takahashi
Date Reported: 2018-07-15
Verifier Name: Alexey Melnikov
Date Verified: 2018-11-05

Section 8 says:

<xs:simpleType name="bulkobservable-type-type">
      <xs:restriction base="xs:NMTOKEN">
        <xs:enumeration value="asn"/>
        <xs:enumeration value="atm"/>
        <xs:enumeration value="e-mail"/>
        <xs:enumeration value="ipv4-addr"/>
        <xs:enumeration value="ipv4-net"/>
        <xs:enumeration value="ipv4-net-mask"/>
        <xs:enumeration value="ipv6-addr"/>
        <xs:enumeration value="ipv6-net"/>
        <xs:enumeration value="ipv6-net-mask"/>
        <xs:enumeration value="mac"/>
        <xs:enumeration value="site-uri"/>
        <xs:enumeration value="domain-name"/>
        <xs:enumeration value="domain-to-ipv4"/>
        <xs:enumeration value="domain-to-ipv6"/>
        <xs:enumeration value="domain-to-ipv4-timestamp"/>
        <xs:enumeration value="domain-to-ipv6-timestamp"/>
        <xs:enumeration value="ipv4-port"/>
        <xs:enumeration value="ipv6-port"/>
        <xs:enumeration value="windows-reg-key"/>
        <xs:enumeration value="file-hash"/>
        <xs:enumeration value="email-x-mailer"/>
        <xs:enumeration value="email-subject"/>
        <xs:enumeration value="http-user-agent"/>
        <xs:enumeration value="http-request-uri"/>
        <xs:enumeration value="mutex"/>
        <xs:enumeration value="file-path"/>
        <xs:enumeration value="user-name"/>
      </xs:restriction>
    </xs:simpleType>

It should say:

<xs:simpleType name="bulkobservable-type-type">
      <xs:restriction base="xs:NMTOKEN">
        <xs:enumeration value="asn"/>
        <xs:enumeration value="atm"/>
        <xs:enumeration value="e-mail"/>
        <xs:enumeration value="ipv4-addr"/>
        <xs:enumeration value="ipv4-net"/>
        <xs:enumeration value="ipv4-net-mask"/>
        <xs:enumeration value="ipv6-addr"/>
        <xs:enumeration value="ipv6-net"/>
        <xs:enumeration value="ipv6-net-mask"/>
        <xs:enumeration value="mac"/>
        <xs:enumeration value="site-uri"/>
        <xs:enumeration value="domain-name"/>
        <xs:enumeration value="domain-to-ipv4"/>
        <xs:enumeration value="domain-to-ipv6"/>
        <xs:enumeration value="domain-to-ipv4-timestamp"/>
        <xs:enumeration value="domain-to-ipv6-timestamp"/>
        <xs:enumeration value="ipv4-port"/>
        <xs:enumeration value="ipv6-port"/>
        <xs:enumeration value="windows-reg-key"/>
        <xs:enumeration value="file-hash"/>
        <xs:enumeration value="email-x-mailer"/>
        <xs:enumeration value="email-subject"/>
        <xs:enumeration value="http-user-agent"/>
        <xs:enumeration value="http-request-uri"/>
        <xs:enumeration value="mutex"/>
        <xs:enumeration value="file-path"/>
        <xs:enumeration value="user-name"/>
        <xs:enumeration value="ext-value"/>
      </xs:restriction>
    </xs:simpleType>

Notes:

The main body text says that the enum values of the type attribute of bulkobservable class include “ext-value”. The schema was not consistentent with the body text, thus corrected.

Errata ID: 5423
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Takeshi Takahashi
Date Reported: 2018-07-15
Verifier Name: Alexey Melnikov
Date Verified: 2018-11-05

Section 8 says:

<xs:element name="ThreatActor">
      <xs:complexType>
        <xs:sequence>
          <xs:element ref="iodef:ThreatActorID"
                      minOccurs="0" maxOccurs="unbounded"/>
          <xs:element ref="iodef:URL" maxOccurs="unbounded"/>
          <xs:element ref="iodef:Description"
                      minOccurs="0" maxOccurs="unbounded"/>
          <xs:element ref="iodef:AdditionalData"
                      minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:attribute name="restriction"
                      type="iodef:restriction-type" use="optional"/>
        <xs:attribute name="ext-restriction"
                      type="xs:string" use="optional"/>
      </xs:complexType>
    </xs:element>

It should say:

<xs:element name="ThreatActor">
      <xs:complexType>
        <xs:sequence>
          <xs:element ref="iodef:ThreatActorID"
                      minOccurs="0" maxOccurs="unbounded"/>
          <xs:element ref="iodef:URL"
                      minOccurs="0" maxOccurs="unbounded"/>
          <xs:element ref="iodef:Description"
                      minOccurs="0" maxOccurs="unbounded"/>
          <xs:element ref="iodef:AdditionalData"
                      minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:attribute name="restriction"
                      type="iodef:restriction-type" use="optional"/>
        <xs:attribute name="ext-restriction"
                      type="xs:string" use="optional"/>
      </xs:complexType>
    </xs:element>

Notes:

The number of URL occurance could be zero, according to the main body text.
The minOccurs of the URL in the TreatActorclass was defined.
(The default value of minOccurs is one, not zero.)

RFC 7991, "The "xml2rfc" Version 3 Vocabulary", December 2016

Source of RFC: IAB

Errata ID: 5052
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Henrik Levkowetz
Date Reported: 2017-06-25
Verifier Name: Robert Sparks
Date Verified: 2018-02-09

Section B.1 says:

<x:include href="file://home/chris/ietf/drafts/commontext.xml"/>

It should say:

<xi:include href="file://home/chris/ietf/drafts/commontext.xml"/>

Notes:

Section B.1. talks about using XInclude for inclusion of external materials, instead of using entity references or processing instructions to include materials. It shows an example namespace declaration:

xmlns:xi="http://www.w3.org/2001/XInclude"

and then continues with various examples using <xi:include/>, except that in one case, an 'i" has been dropped from the "xi:", giving <x:include...>.

Errata ID: 5618
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kent Watsen
Date Reported: 2019-01-31
Verifier Name: Mirja Kühlewnd (IAB/RSAB chair)
Date Verified: 2024-03-14

Section 2.5.6 says:

It is an error to have both a "src" attribute and content in the
<artwork> element.

Notes:

This sentence needs to be removed because the second paragraph in Section 2.5 says that the "textual content acts as a fallback" for the "src" attribute.

Errata ID: 5887
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Rolf van Kleef
Date Reported: 2019-10-30
Verifier Name: Mirja Kühlewnd (IAB/RSAB chair)
Date Verified: 2024-03-14

Section Appendix C says:

xref =
  element xref {
    attribute xml:base { text }?,
    attribute xml:lang { text }?,
    attribute target { xsd:IDREF },
    [ a:defaultValue = "false" ]
    attribute pageno { "true" | "false" }?,
    [ a:defaultValue = "default" ]
    attribute format { "default" | "title" | "counter" | "none" }?,
    attribute derivedContent { text }?,
    text
  }

It should say:

xref =
  element xref {
    attribute xml:base { text }?,
    attribute xml:lang { text }?,
    attribute target { xsd:IDREF },
    [ a:defaultValue = "false" ]
    attribute pageno { "true" | "false" }?,
    [ a:defaultValue = "default" ]
    attribute format { "default" | "title" | "counter" | "none" }?,
    attribute derivedContent { text }?,
    attribute relative { text }?,
    attribute section { text }?,
    [ a:defaultValue = "of" ]
    attribute sectionFormat { "of" | "comma" | "parens" | "bare" }?,
    text
  }

Notes:

In section 1.3.2: New Attributes for Existing Elements, the attributes 'relative', 'section', and 'sectionFormat' are added to the xref element. This is, however, not reflected in appendix C.

This same mistake is reflected in appendix D.

Errata ID: 6387
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2021-01-18
Verifier Name: Mirja Kühlewiind (IAB Chair)
Date Verified: 2021-02-04

Section 2.48 says:

   When rendered, source code is always shown in a monospace font.  When
   <sourcecode> is a child of <figure> or <section>, it provides full
   control of horizontal whitespace and line breaks.  When formatted, it
   is indented relative to the left margin of the enclosing element.  It
   is thus useful for source code and formal languages (such as ABNF
   [RFC5234] or the RNC notation used in this document).  (When
   <sourcecode> is a child of other elements, it flows with the text
   that surrounds it.)  Tab characters (U+0009) inside of this element
   are prohibited.

It should say:

   When rendered, source code is always shown in a monospace font. 
   Furthermore, it provides full
   control of horizontal whitespace and line breaks.
   Tab characters (U+0009) inside of this element
   are prohibited.

Notes:

The text hints at uses of <sourcecode> as inline element, but the grammar does not allow any such use.

Errata ID: 6424
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Levine
Date Reported: 2021-02-09
Verifier Name: Mirja Kühlewind (IAB Chair)
Date Verified: 2021-03-05

Section 2.6 says:

   o  <list> elements (Section 3.4)

Notes:

The <list> element should be removed in 2.6. as it is deprecated and only occurs under <t>.

Errata ID: 5914
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jeffrey Yasskin
Date Reported: 2019-11-19

Section A.3 says:

The consensus attribute can be used to supply this information.  The
   acceptable values are "true" (the default) and "false"; "yes" and
   "no" from v2 are deprecated.

It should say:

The consensus attribute can be used to supply this information.  The
   acceptable values are "true" and "false" (the default); "yes" and
   "no" from v2 are deprecated.

Notes:

Section 2.45.2. "consensus" Attribute says,

>>>>>>
Affects the generated boilerplate. Note that the values of "no" and
"yes" are deprecated and are replaced by "false" (the default) and
"true".

See [RFC7841] for more information.

Allowed values:

o "no"

o "yes"

o "false" (default)

o "true"
<<<<<<

Which is the opposite default from what A.3 currently claims. These should be consistent.

RFC 7997, "The Use of Non-ASCII Characters in RFCs", December 2016

Source of RFC: IAB

Errata ID: 6319
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: David Paul
Date Reported: 2020-10-26
Verifier Name: Mirja Kühlewind
Date Verified: 2020-10-27

Section 3.5 says:

   Table 3: A sample of legal passwords

   +------------------------------------+------------------------------+
   | # | Password                       | Notes                        |
   +------------------------------------+------------------------------+
   | 12| <correct horse battery staple> | ASCII space is allowed       |
   +------------------------------------+------------------------------+
   | 13| <Correct Horse Battery Staple> | Different from example 12    |
   +------------------------------------+------------------------------+
   | 14| <&#x3C0;&#xDF;&#xE5;>          | Non-ASCII letters are OK     |
   |   |                                | (e.g., GREEK SMALL LETTER    |
   |   |                                | PI, U+03C0)                  |
   +------------------------------------+------------------------------+
   | 15| <Jack of &#x2666;s>            | Symbols are OK (e.g., BLACK  |
   |   |                                | DIAMOND SUIT, U+2666)        |
   +------------------------------------+------------------------------+
   | 16| <foo&#x1680;bar>               | OGHAM SPACE MARK, U+1680, is |
   |   |                                | mapped to U+0020 and thus    |
   |   |                                | the full string is mapped to |
   |   |                                | <foo bar>                    |
   +------------------------------------+------------------------------+

   Preferred text:

   Table 3: A sample of legal passwords

   +------------------------------------+------------------------------+
   | # | Password                       | Notes                        |
   +------------------------------------+------------------------------+
   | 12| <correct horse battery staple> | ASCII space is allowed       |
   +------------------------------------+------------------------------+
   | 13| <Correct Horse Battery Staple> | Different from example 12    |
   +------------------------------------+------------------------------+
   | 14| <(See PDF for non-ASCII        | Non-ASCII letters are OK     |
   |   |   character string)>           | (e.g., GREEK SMALL LETTER    |
   |   |                                | PI, U+03C0; LATIN SMALL      |
   |   |                                | LETTER SHARP S, U+00DF; THAI |
   |   |                                | DIGIT SEVEN, U+0E57)         |
   +------------------------------------+------------------------------+
   | 15| <Jack of (See PDF for non-     | Symbols are OK (e.g., BLACK  |
   |   |  ASCII character string)s>     | DIAMOND SUIT, U+2666)        |
   +------------------------------------+------------------------------+
   | 16| <foo(See PDF for non-ASCII     | OGHAM SPACE MARK, U+1680, is |
   |   |  character string)bar>         | mapped to U+0020 and thus    |
   |   |                                | the full string is mapped to |
   |   |                                | <foo bar>                    |
   +------------------------------------+------------------------------+

It should say:

   Table 3: A sample of legal passwords

   +------------------------------------+------------------------------+
   | # | Password                       | Notes                        |
   +------------------------------------+------------------------------+
   | 12| <correct horse battery staple> | ASCII space is allowed       |
   +------------------------------------+------------------------------+
   | 13| <Correct Horse Battery Staple> | Different from example 12    |
   +------------------------------------+------------------------------+
   | 14| <&#x3C0;&#xDF;&#xE5;>          | Non-ASCII letters are OK     |
   |   |                                | (e.g., GREEK SMALL LETTER    |
   |   |                                | PI, U+03C0)                  |
   +------------------------------------+------------------------------+
   | 15| <Jack of &#x2666;s>            | Symbols are OK (e.g., BLACK  |
   |   |                                | DIAMOND SUIT, U+2666)        |
   +------------------------------------+------------------------------+
   | 16| <foo&#x1680;bar>               | OGHAM SPACE MARK, U+1680, is |
   |   |                                | mapped to U+0020 and thus    |
   |   |                                | the full string is mapped to |
   |   |                                | <foo bar>                    |
   +------------------------------------+------------------------------+

   Preferred text:

   Table 3: A sample of legal passwords

   +------------------------------------+------------------------------+
   | # | Password                       | Notes                        |
   +------------------------------------+------------------------------+
   | 12| <correct horse battery staple> | ASCII space is allowed       |
   +------------------------------------+------------------------------+
   | 13| <Correct Horse Battery Staple> | Different from example 12    |
   +------------------------------------+------------------------------+
   | 14| <(See PDF for non-ASCII        | Non-ASCII letters are OK     |
   |   |   character string)>           | (e.g., GREEK SMALL LETTER    |
   |   |                                | PI, U+03C0; LATIN SMALL      |
   |   |                                | LETTER SHARP S, U+00DF;      |
   |   |                                | LATIN SMALL LETTER A WITH    |
   |   |                                | RING ABOVE, U+00E5)          |
   +------------------------------------+------------------------------+
   | 15| <Jack of (See PDF for non-     | Symbols are OK (e.g., BLACK  |
   |   |  ASCII character string)s>     | DIAMOND SUIT, U+2666)        |
   +------------------------------------+------------------------------+
   | 16| <foo(See PDF for non-ASCII     | OGHAM SPACE MARK, U+1680, is |
   |   |  character string)bar>         | mapped to U+0020 and thus    |
   |   |                                | the full string is mapped to |
   |   |                                | <foo bar>                    |
   +------------------------------------+------------------------------+

Notes:

Observe the #14 row of both tables:

The Notes column in the second table describes a different third Unicode code point than what appears in the Password column of the first table. As the first table is a direct excerpt from RFC7613, it should not be modified and so the second table should be corrected to contain a proper corresponding example.

RFC 8006, "Content Delivery Network Interconnection (CDNI) Metadata", December 2016

Source of RFC: cdni (wit)

Errata ID: 5150
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kevin J. Ma
Date Reported: 2017-10-08
Verifier Name: Alexey Melnikov
Date Verified: 2017-10-18

Section 6.10 says:

         "generic-metadata-type": "MI.SourceMetadata",
         "generic-metadata-value": {
           "sources": [
             {
               "endpoint": ["acq1.ucdn.example"],
               "protocol": "http/1.1"
             },
             {
               "endpoint": ["acq2.ucdn.example"],
               "protocol": "http/1.1"
             }
           ]
         }

It should say:

         "generic-metadata-type": "MI.SourceMetadata",
         "generic-metadata-value": {
           "sources": [
             {
               "endpoints": ["acq1.ucdn.example"],
               "protocol": "http/1.1"
             },
             {
               "endpoints": ["acq2.ucdn.example"],
               "protocol": "http/1.1"
             }
           ]
         }

Notes:

The SourceMetadata object contains an array of "sources", which in turn contains an array of "endpoints". The example in section 6.10 uses the singular "endpoint" instead of the plural "endpoints". The examples in sections 4.2.1 and 4.2.1.1 correctly use the plural "endpoints" for the property name, as defined in section 4.2.1.1.

Errata ID: 7657
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kazuki Takashima
Date Reported: 2023-09-26
Verifier Name: Francesca Palombini
Date Verified: 2023-11-07

Section 6.10 says:

   {
     "metadata": [
       {
         "generic-metadata-type": "MI.TimeWindowACL",
         "generic-metadata-value": {
           "times": [
             "windows": [
               {
                 "start": "1213948800",
                 "end": "1478047392"
               }
             ],
             "action": "allow"
           ]
         }
       }
     ]
   }

It should say:

   {
     "metadata": [
       {
         "generic-metadata-type": "MI.TimeWindowACL",
         "generic-metadata-value": {
           "times": [
              {
                "windows": [
                  {
                    "start": 1213948800,
                    "end": 1478047392
                  }
                ],
                "action": "allow"
              }
           ]
         }
       }
     ]
   }

Notes:

1. The "times" property of the TimeWindowACL object has an array of TimeWindowRule type, so I changed it to "windows" and "action" are contained in braces.
2. The "start" and "end" property of the TimeWindow object have a Time type, which is an alias of Integer. So I changed their values ("1213948800", "1478047392") to Integer (1213948800, 1478047392).

RFC 8007, "Content Delivery Network Interconnection (CDNI) Control Interface / Triggers", December 2016

Source of RFC: cdni (wit)

Errata ID: 5053
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kevin J. Ma
Date Reported: 2017-06-27
Verifier Name: Barry Leiba
Date Verified: 2021-01-22

Section 5.2.3 says:

| canceling |
| canceled  |

It should say:

| cancelling |
| cancelled  |

Notes:

In the final editing phase, I believe it was agreed that text would use the American spelling with 1 "l", but that the actual status strings would use 2 "l"s. In sections 2.3, 4.3, 4.5, and Appendix A, the quoted status strings all use 2 "l"s. The first column of the table in section 5.2.3 is providing the JSON string values, which should match the quoted status strings in sections 2.3, 4.3, 4.5, and Appendix A and have 2 "l"s.

Errata ID: 5054
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kevin J. Ma
Date Reported: 2017-06-27
Verifier Name: Barry Leiba
Date Verified: 2021-01-22

Section 5.2.7 says:

| ecanceled    |

It should say:

| ecancelled   |

Notes:

In the final editing phase, I believe it was agreed that text would use the American spelling with 1 "l", but that the status strings would use 2 "l"s. This should apply to the error codes as well. The first column of the table in section 5.2.7 is providing the Error Code values, which like the status code strings in sections 2.3, 4.3, 4.5, 5.2.3, and Appendix A, should have 2 "l"s. Note: The IANA registry has the error code as "ecancelled" with 2 "l"s. http://www.iana.org/assignments/cdni-parameters/cdni-parameters.xhtml#error-codes

Note: This errata also applies to Appendix A.

Errata ID: 6385
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Guillaume Bichot
Date Reported: 2021-01-12
Verifier Name: Barry Leiba
Date Verified: 2021-01-22

Section 4.1 says:

   When a CI/T Trigger Command is accepted, the uCDN MUST create a new
   Trigger Status Resource that will convey a specification of the CI/T
   Command and its current status.  The HTTP response to the dCDN MUST
   have status code 201 and MUST convey the URI of the Trigger Status
   Resource in the Location header field [RFC7231].

It should say:

   When a CI/T Trigger Command is accepted, the dCDN MUST create a new
   Trigger Status Resource that will convey a specification of the CI/T
   Command and its current status.  The HTTP response to the uCDN MUST
   have status code 201 and MUST convey the URI of the Trigger Status
   Resource in the Location header field [RFC7231].

Notes:

There has been an accidental switch between "uCDN" and "dCDN" terms in this statement. If my understanding is correct, when the uCDN post a CI/T command to the dCDN, the latter must create a trigger status resource and returns in the response (HTTP code 201) “Location” header the URI of that status resource.

Errata ID: 5064
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kevin J. Ma
Date Reported: 2017-07-07
Verifier Name: Barry Leiba
Date Verified: 2021-01-22

Section 6.2.5 says:

6.2.5.  Deleting Trigger Status Resources

   The uCDN can delete completed and failed Trigger Status Resources to
   reduce the size of the collections, as described in Section 4.4.  For
   example, to delete the "preposition" request from earlier examples:

It should say:

6.2.5.  Canceling or Deleting Trigger Status Resources

   The uCDN can cancel pending or active Trigger Status Resource
   processing, as described in Section 4.3.  For example, to cancel
   the "preposition" request from earlier examples:

   REQUEST:

     POST /triggers HTTP/1.1
     User-Agent: example-user-agent/0.1
     Host: dcdn.example.com
     Accept: */*
     Content-Type: application/cdni; ptype=ci-trigger-command
     Content-Length: 91

     {
       "cancel" : [ "https://dcdn.example.com/triggers/0" ],
       "cdn-path" : [ "AS64496:1" ]
     }

   RESPONSE:

     HTTP/1.1 200 OK
     Content-Length: 0
     Server: example-server/0.1
     Date: Wed, 04 May 2016 08:50:00 GMT

   The uCDN can also delete completed and/or failed Trigger Status
   Resources to reduce the size of the collections, as described in
   Section 4.4.  For example, to delete the "preposition" request from
   earlier examples:

Notes:

There is no example for canceling a trigger. Section 4.3 does not specify what the response payload should be for cancel responses. An explicit example would help clarify the intent of an empty response. A cancel example probably warrants its own section, but for the purposes of simplifying this errata, it has been combined with the delete example.

RFC 8011, "Internet Printing Protocol/1.1: Model and Semantics", January 2017

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 6617
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Smith Kennedy
Date Reported: 2021-06-22
Verifier Name: Benjamin Kaduk
Date Verified: 2021-06-23

Section 4.2.2 says:

   This OPTIONAL operation is identical to the Print-Job operation
   (Section 4.2.1), except that a Client supplies a URI reference to the
   Document data using the "document-uri" (uri) operation attribute (in
   Group 1) rather than including the Document data itself.  Before
   returning the response, the Printer MUST validate that the Printer
   supports the retrieval method (e.g., 'http', 'ftp', etc.) implied by
   the URI and MUST check for valid URI syntax.  If the Client-supplied
   URI scheme is not supported, i.e., the value is not in the Printer's
   "referenced-uri-scheme-supported" attribute, the Printer MUST reject
   the request and return the 'client-error-uri-scheme-not-supported'
   status-code.

It should say:

   This OPTIONAL operation is identical to the Print-Job operation
   (Section 4.2.1), except that a Client supplies a URI reference to the
   Document data using the "document-uri" (uri) operation attribute (in
   Group 1) rather than including the Document data itself.  Before
   returning the response, the Printer MUST validate that the Printer
   supports the retrieval method (e.g., 'http', 'ftp', etc.) implied by
   the URI and MUST check for valid URI syntax.  If the Client-supplied
   URI scheme is not supported, i.e., the value is not in the Printer's
   "reference-uri-scheme-supported" attribute, the Printer MUST reject
   the request and return the 'client-error-uri-scheme-not-supported'
   status-code.

Notes:

'referenced-uri-scheme-supported' --> 'reference-uri-scheme-supported'

RFC 8013, "Forwarding and Control Element Separation (ForCES) Inter-FE Logical Functional Block (LFB)", February 2017

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rtg

Errata ID: 6938
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Pedro Tammela
Date Reported: 2022-04-19
Verifier Name: Alvaro Retana
Date Verified: 2022-04-20

Section 5.1.1 says:

Caution needs to be exercised on how low the resulting reported link MTU could be: for IPv4 packets, the minimum size is 64 octets [RFC791] and for IPv6 the minimum size is 1280 octets [RFC2460].

It should say:

Caution needs to be exercised on how low the resulting reported link MTU could be: for IPv4 the recommended minimum size is 576 octets [RFC1122] and for IPv6 the minimum size is 1280 octets [RFC2460].

Notes:

The original text mixed minimum packet size with minimum MTU size.

Errata ID: 5357
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2018-05-13
Verifier Name: RFC Editor
Date Verified: 2018-05-15

Section 5.1.1 says:

      configuration.  In essence, the control plane when explicitly
      making a decision for the MTU settings of the egress port is
      implicitly deciding how much metadata will be allowed.  Caution
      needs to be exercised on how low the resulting reported link MTU
      could be: for IPv4 packets, the minimum size is 64 octets [RFC791]
      and for IPv6 the minimum size is 1280 octets [RFC2460].

It should say:

      configuration).  In essence, the control plane when explicitly
      making a decision for the MTU settings of the egress port is
      implicitly deciding how much metadata will be allowed.  Caution
      needs to be exercised on how low the resulting reported link MTU
      could be: for IPv4 packets, the minimum size is 64 octets [RFC791]
      and for IPv6 the minimum size is 1280 octets [RFC2460].

Notes:

The closing parenthesis is missing.

RFC 8017, "PKCS #1: RSA Cryptography Specifications Version 2.2", November 2016

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 5111
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Wu
Date Reported: 2017-09-11
Verifier Name: Kathleen Moriarty
Date Verified: 2018-03-19

Section A.2.3 says:

   The object identifier id-RSASSA-PSS identifies the RSASSA-PSS
   encryption scheme.

It should say:

   The object identifier id-RSASSA-PSS identifies the RSASSA-PSS
   signature scheme.

Notes:

RSASSA-PSS is a signature scheme, it has no encrypt/decrypt operations.
This errata also applies to RFC 3447 (Section A.2.3)
Verified by Burt Kaliski

Errata ID: 5154
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Joost Rijneveld
Date Reported: 2017-10-12
Verifier Name: Kathleen Moriarty
Date Verified: 2018-03-18

Section A.2.4 says:

SHA-256          sha224WithRSAEncryption     ::= {pkcs-1 14}

It should say:

SHA-224          sha224WithRSAEncryption     ::= {pkcs-1 14}

Notes:

Good catch. Confirmed.

Background: The addition of SHA224 support to PKCS #1 required a few minor technical updates in PKCS #1 v2.2 compared to v2.1, and to the corresponding RFC8017 compared to RFC3447. PKCS #1 v2.2 got the correct update, but RFC8017 didn't -- presumably a copy-and-paste error. My oversight in reviewing the edits. Thanks, Joost, for pointing it out.

Errata ID: 5235
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Joern Heissler
Date Reported: 2018-01-14
Verifier Name: Kathleen Moriarty
Date Verified: 2018-03-18

Section 8.1.1 says:

Errors:  "message too long;" "encoding error"

It should say:

Errors:  "message too long"; "encoding error"

Notes:

The semicolon needs to be placed outside of the quoted strings.

Errata ID: 5577
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dave Thompson
Date Reported: 2018-12-16
Verifier Name: Benjamin Kaduk
Date Verified: 2019-01-05

Section B.1 says:

   As of today, the best (known) collision attacks against these hash
   functions are generic attacks with complexity 2L/2, where L is the
   bit length of the hash output.  For the signature schemes in this
   document, a collision attack is easily translated into a signature
   forgery.  Therefore, the value L / 2 should be at least equal to the
   desired security level in bits of the signature scheme (a security
   level of B bits means that the best attack has complexity 2B).  The

It should say:

   As of today, the best (known) collision attacks against these hash
   functions are generic attacks with complexity 2^(L/2), where L is the
   bit length of the hash output.  For the signature schemes in this
   document, a collision attack is easily translated into a signature
   forgery.  Therefore, the value L / 2 should be at least equal to the
   desired security level in bits of the signature scheme (a security
   level of B bits means that the best attack has complexity 2^B).  The

Notes:

Superscripting presumably lost in translation from the original. RFC 3447 (for v2.1) had these correct. To a person familiar with the art they are obvious typos (Editorial) but to other readers they could change the meaning.

Errata ID: 7405
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Daniel Kahn Gillmor
Date Reported: 2023-03-25
Verifier Name: RFC Editor
Date Verified: 2023-04-27

Section 11.2, 7.2 says:

"HAASTAD"

and

"Haastad, J"

It should say:

"HASTAD"

and

"Hastad, J"

Notes:

https://epubs.siam.org/doi/10.1137/0217019 indicates that the author of "Solving Simultaneous Modular Equations of Low Degree" is "Johan Hastad", not "Johan Haastad".

RFC 8018, "PKCS #5: Password-Based Cryptography Specification Version 2.1", January 2017

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 5808
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2019-08-13
Verifier Name: Benjamin Kaduk
Date Verified: 2019-08-22

Section Appendix C says:

   PBKDF2-PRFs ALGORITHM-IDENTIFIER ::= {
     {NULL IDENTIFIED BY id-hmacWithSHA1},
     {NULL IDENTIFIED BY id-hmacWithSHA224},
     {NULL IDENTIFIED BY id-hmacWithSHA256},
     {NULL IDENTIFIED BY id-hmacWithSHA384},
     {NULL IDENTIFIED BY id-hmacWithSHA512},
     {NULL IDENTIFIED BY id-hmacWithSHA512-224},
     {NULL IDENTIFIED BY id-hmacWithSHA512-256},
     ...
   }

It should say:

   PBKDF2-PRFs ALGORITHM-IDENTIFIER ::= {
     {NULL IDENTIFIED BY id-hmacWithSHA1}        |
     {NULL IDENTIFIED BY id-hmacWithSHA224}      |
     {NULL IDENTIFIED BY id-hmacWithSHA256}      |
     {NULL IDENTIFIED BY id-hmacWithSHA384}      |
     {NULL IDENTIFIED BY id-hmacWithSHA512}      |
     {NULL IDENTIFIED BY id-hmacWithSHA512-224}  |
     {NULL IDENTIFIED BY id-hmacWithSHA512-256},
     ...
   }

Notes:

For the ASN.1 Module to compile properly, six commas need to be replaced with "|" in the definition of PBKDF2-PRFs.

Errata ID: 5809
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2019-08-13
Verifier Name: Benjamin Kaduk
Date Verified: 2019-08-22

Section Appendix C says:

   SupportingAlgorithms ALGORITHM-IDENTIFIER ::= {
      {NULL IDENTIFIED BY id-hmacWithSHA1}                   |
      {OCTET STRING (SIZE(8)) IDENTIFIED BY desCBC}          |
      {OCTET STRING (SIZE(8)) IDENTIFIED BY des-EDE3-CBC}    |
      {RC2-CBC-Parameter IDENTIFIED BY rc2CBC}               |
      {RC5-CBC-Parameters IDENTIFIED BY rc5-CBC-PAD},        |
      {OCTET STRING (SIZE(16)) IDENTIFIED BY aes128-CBC-PAD} |
      {OCTET STRING (SIZE(16)) IDENTIFIED BY aes192-CBC-PAD} |
      {OCTET STRING (SIZE(16)) IDENTIFIED BY aes256-CBC-PAD},
       ...
   }

It should say:

   SupportingAlgorithms ALGORITHM-IDENTIFIER ::= {
      {NULL IDENTIFIED BY id-hmacWithSHA1}                   |
      {OCTET STRING (SIZE(8)) IDENTIFIED BY desCBC}          |
      {OCTET STRING (SIZE(8)) IDENTIFIED BY des-EDE3-CBC}    |
      {RC2-CBC-Parameter IDENTIFIED BY rc2CBC}               |
      {RC5-CBC-Parameters IDENTIFIED BY rc5-CBC-PAD}         |
      {OCTET STRING (SIZE(16)) IDENTIFIED BY aes128-CBC-PAD} |
      {OCTET STRING (SIZE(16)) IDENTIFIED BY aes192-CBC-PAD} |
      {OCTET STRING (SIZE(16)) IDENTIFIED BY aes256-CBC-PAD},
       ...
   }

Notes:

For the ASN.1 Module to compile properly, the extra comma needs to be removed in the definition of SupportingAlgorithms.

Errata ID: 6156
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Triton Circonflexe
Date Reported: 2020-05-00
Verifier Name: Benjamin Kaduk
Date Verified: 2020-05-07

Section Appendix A.2 says:

      PBKDF2-PRFs ALGORITHM-IDENTIFIER ::= {
        {NULL IDENTIFIED BY id-hmacWithSHA1},
        {NULL IDENTIFIED BY id-hmacWithSHA224},
        {NULL IDENTIFIED BY id-hmacWithSHA256},
        {NULL IDENTIFIED BY id-hmacWithSHA384},
        {NULL IDENTIFIED BY id-hmacWithSHA512},
        {NULL IDENTIFIED BY id-hmacWithSHA512-224},
        {NULL IDENTIFIED BY id-hmacWithSHA512-256},
        ...
      }

It should say:

      PBKDF2-PRFs ALGORITHM-IDENTIFIER ::= {
        {NULL IDENTIFIED BY id-hmacWithSHA1}        |
        {NULL IDENTIFIED BY id-hmacWithSHA224}      |
        {NULL IDENTIFIED BY id-hmacWithSHA256}      |
        {NULL IDENTIFIED BY id-hmacWithSHA384}      |
        {NULL IDENTIFIED BY id-hmacWithSHA512}      |
        {NULL IDENTIFIED BY id-hmacWithSHA512-224}  |
        {NULL IDENTIFIED BY id-hmacWithSHA512-256},
        ...
      }

Notes:

For the ASN.1 Module to compile properly, six commas need to be replaced with "|" in the definition of PBKDF2-PRFs.
Errata 5808 targets the complete ASN.1 module, here this is just an extract copied in PBKDF2 description.

RFC 8027, "DNSSEC Roadblock Avoidance", November 2016

Source of RFC: dnsop (ops)

Errata ID: 4877
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2016-12-04
Verifier Name: Warren Kumari
Date Verified: 2017-03-26

Section 3.1.13 says:

(a server today that supports this is alltypes.res.dnssecready.org).

It should say:

[No text]

Notes:

The domain name was deleted in 2015... Relying on it was noted in https://www.mail-archive.com/dnsop@ietf.org/msg12129.html

If someone wants to reactivate the service, I just reserved the domain. I wlll of course redirect/transfer/whatever it gratis.

RFC 8029, "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures", March 2017

Note: This RFC has been updated by RFC 8611, RFC 9041

Source of RFC: mpls (rtg)

Errata ID: 7639
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Greg Mirsky
Date Reported: 2023-09-11
Verifier Name: Andrew Alston
Date Verified: 2023-11-12

Section 4.5 says:

If the Reply Mode in the echo request is "Reply via an
IPv4 UDP packet with Router Alert", then the IP header MUST contain
the Router Alert IP Option of value 0x0 [RFC2113] for IPv4 or 69
[RFC7506] for IPv6.

It should say:

If the Reply Mode in the echo request is "Reply via an
IPv4/IPv6 UDP packet with Router Alert", then the IP header MUST contain
the Router Alert IP Option of value 0x0 [RFC2113] for IPv4 or 69
[RFC7506] for IPv6.

Notes:

The description of the Reply Mode recorded in the IANA "Reply Modes" sub-registry of the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry is "Reply via an IPv4/IPv6 UDP packet with Router Alert".

Errata ID: 7892
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Loa Andersson
Date Reported: 2024-04-15
Verifier Name: James Guichard
Date Verified: 2024-04-16

Throughout the document, when it says:

Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures

It should say:

Detecting Multiprotocol Label Switched Data-Plane Failures
or 
Detecting Multiprotocol Label Switching (MPLS) Data-Plane Failures.

Notes:

MPLS expands to "Multiprotocol Label Switching", not to "Multiprotocol Label Switched".

Either we can remove the abbreviation in the title or s/Switched/Switching, either of the
alternatives work.

RFC 8032, "Edwards-Curve Digital Signature Algorithm (EdDSA)", January 2017

Source of RFC: IRTF

Errata ID: 5930
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Daniel Bleichenbacher
Date Reported: 2019-12-06
Verifier Name: Colin Perkins
Date Verified: 2021-05-24

Section 6 says:

def verify(public, msg, signature):
    if len(public) != 32:
        raise Exception("Bad public key length")
    if len(signature) != 64:
        Exception("Bad signature length")

It should say:

def verify(public, msg, signature):
    if len(public) != 32:
        raise Exception("Bad public key length")
    if len(signature) != 64:
        raise Exception("Bad signature length")

Notes:

Missing raise before Exception

Errata ID: 5519
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Susumu Endoh
Date Reported: 2018-10-10
Verifier Name: Colin Perkins
Date Verified: 2019-04-09

Section 5.1.7 says:

Decode the first half as a point R, and the second half as an integer S,
in the range 0 <= s < L.

It should say:

Decode the first half as a point R, and the second half as an integer S,
in the range 0 <= S < L.

Notes:

original document expression is ' 0 <= s < L', but it must be '0 <= S < L'. upper/lower case problem.

Errata ID: 6851
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Martin Thomson
Date Reported: 2022-02-15
Verifier Name: RFC Editor

Section 8.7 says:

   As an API consideration, this means that any Initialize Update
   Finalize (IFU) verification interface is prone to misuse.

It should say:

   As an API consideration, this means that any Initialize Update
   Finalize (IUF) verification interface is prone to misuse.

Notes:

Typo in acronym.

RFC 8033, "Proportional Integral Controller Enhanced (PIE): A Lightweight Control Scheme to Address the Bufferbloat Problem", February 2017

Source of RFC: aqm (tsv)

Errata ID: 5095
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Liang Tian
Date Reported: 2017-08-24
Verifier Name: Mirja Kühlewind
Date Verified: 2020-03-04

Section 5.2 says:

      if PIE->in_measurement_ == TRUE:
         PIE->dq_count_ = PIE->dq_count_ + deque_pkt_size;
         if PIE->dq_count_ >= DQ_THRESHOLD then
            weight = DQ_THRESHOLD/2^16
            PIE->avg_dq_time_ = (now - PIE->measurement_start_) *
                                weight + PIE->avg_dq_time_ *
                                (1 - weight);
            PIE->dq_count_ = 0;
            PIE->measurement_start_ = now
         else
            PIE->in_measurement_ = FALSE;

It should say:

      if PIE->in_measurement_ == TRUE:
         PIE->dq_count_ = PIE->dq_count_ + deque_pkt_size;
         if PIE->dq_count_ >= DQ_THRESHOLD then
            weight = DQ_THRESHOLD/2^16
            PIE->avg_dq_time_ = (now - PIE->measurement_start_) *
                                weight + PIE->avg_dq_time_ *
                                (1 - weight);
            PIE->in_measurement_ = FALSE;

Notes:

There should not be an "else" because if PIE->dq_count_ >= DQ_THRESHOLD, this measurement is over: avg_dq_time is calculated and in_measurement is set to FALSE; otherwise dq_count has been increased before this "if" and now we wait for next packet. Resetting dq_count and measurement_start is not necessary because they will be set again when a new measurement begins.

RFC 8040, "RESTCONF Protocol", January 2017

Note: This RFC has been updated by RFC 8527

Source of RFC: netconf (ops)

Errata ID: 5255
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Balazs Lengyel
Date Reported: 2018-02-06
Verifier Name: Benoit Claise
Date Verified: 2018-02-06

Section 3.5.3. says:

If there are multiple key leaf values, the path 
segment is constructed by having the list name, 
followed by the value of each leaf identified 
in the "key" statement, encoded in the order
specified in the YANG "key" statement.  Each key 
leaf value except the last one is followed by 
a comma character.

It should say:

If there are multiple key leaf values, the path 
segment is constructed by having the list name,  
followed by an "=" character, 
followed by the value of each leaf identified 
in the "key" statement, encoded in the order
specified in the YANG "key" statement.  Each key 
leaf value except the last one is followed by 
a comma character.

Notes:

When describing the encoding of key values for a list, in the case of multiple keys the "=" equal sign is not mentioned although it is used in the examples.

Errata ID: 5566
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin Björklund
Date Reported: 2018-12-03
Verifier Name: Ignas Bagdonas
Date Verified: 2019-07-09

Section B.3.2 says:

          "player" : {
            "gap" : 0.5
          }

It should say:

          "player" : {
            "gap" : "0.5"
          }

Notes:

The quoted text occurs twice; p 128 and p 130.

The leaf "gap" is defined as type decimal64 in A.1. According to RFC 7951, section 6.1, a decimal64 type is represented as a string in JSON.

Errata ID: 5756
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kent Watsen
Date Reported: 2019-06-21
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2019-07-01

Section 8 says:

  module ietf-system {
    leaf system-reset {
      type empty;
    }
  }

It should say:

  module ietf-system {
    leaf system-restart {
      type empty;
    }
  }

Notes:

The section on page 84 discusses the "system-restart" RPC from RFC 7317, but the conceptual example has "system-reset". Fix: s/system-reset/system-restart/.

Errata ID: 6277
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kent Watsen
Date Reported: 2020-09-03
Verifier Name: Rob Wilton
Date Verified: 2023-10-02

Section 4.8.5 says:

The default value is "last".

It should say:

The default value is “last”, except when used with PUT 
and the target resource already exists, in which case the 
default is to replace the target resource without altering
its position in the "ordered-by user” list or leaf-list.

Notes:

The "last" default is intended for when creating a new element.

A PUT operation that replaces a list or leaf-list entry should not move the entry unless the "insert" parameter is explicitly passed.

Errata ID: 6473
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kyoung-Hwan Yun
Date Reported: 2021-03-10
Verifier Name: Rob Wilton
Date Verified: 2024-01-15

Section B.3.2 says:

   Example 3: depth=3

   To limit the depth level to the target resource plus two child
   resource layers, the value "3" is used.

      GET /restconf/data/example-jukebox:jukebox?depth=3 HTTP/1.1
      Host: example.com
      Accept: application/yang-data+json

   The server might respond as follows:

      HTTP/1.1 200 OK
      Date: Thu, 26 Jan 2017 20:56:30 GMT
      Server: example-server
      Cache-Control: no-cache
      Content-Type: application/yang-data+json

      {
        "example-jukebox:jukebox" : {
          "library" : {
            "artist" : {}
          },
          "playlist" : [
            {
              "name" : "Foo-One",
              "description" : "example playlist 1",
              "song" : {}
            }
          ],
          "player" : {
            "gap" : 0.5
          }
        }
      }

It should say:

   Example 3: depth=3

   To limit the depth level to the target resource plus two child
   resource layers, the value "3" is used.

      GET /restconf/data/example-jukebox:jukebox?depth=3 HTTP/1.1
      Host: example.com
      Accept: application/yang-data+json

   The server might respond as follows:

      HTTP/1.1 200 OK
      Date: Thu, 26 Jan 2017 20:56:30 GMT
      Server: example-server
      Cache-Control: no-cache
      Content-Type: application/yang-data+json

      {
        "example-jukebox:jukebox" : {
          "library" : {
            "artist" : []
          },
          "playlist" : [
            {
              "name" : "Foo-One",
              "description" : "example playlist 1",
              "song" : []
            }
          ],
          "player" : {
            "gap" : 0.5
          }
        }
      }

Notes:

"artist" and "song" are defined as list. Therefore, according to RFC 7951, they should be encoded as array instead of object.

Errata ID: 7311
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Per Andersson
Date Reported: 2023-01-18
Verifier Name: Robert Wilton
Date Verified: 2024-01-12

Section 7 says:

              +-------------------------+------------------+
              | error-tag               | status code      |
              +-------------------------+------------------+
(...)
              | unknown-attribute       | 400              |
              |                         |                  |
              | bad-element             | 400              |
(...)

It should say:

              +-------------------------+------------------+
              | error-tag               | status code      |
              +-------------------------+------------------+
(...)
              | unknown-attribute       | 400              |
              |                         |                  |
              | missing-element         | 400              |
              |                         |                  |
              | bad-element             | 400              |
(...)

Notes:

Add missing-element to the table Mapping from <error-tag> to Status Code
in Section 7.

The NETCONF error-tag missing-element is not listed in the table mapping
error-tag to HTTP status code. This seems to be a mistake since all other
error-tags are listed (even the obsolete partial-operation which should not
be used according to RFC 6241).

Errata ID: 7866
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Andy Bierman
Date Reported: 2024-03-23
Verifier Name: Mahesh Jethanandani
Date Verified: 2024-04-03

Section Multiple says:

Text occurs in three places

1)    Section 3.5.3

      The leaf-list value is specified as a string, using the canonical
      representation for the YANG data type.  Any reserved characters
      MUST be percent-encoded, according to Sections 2.1 and 2.5 of
      [RFC3986].


2)    Section 3.5.3

      The key value is specified as a string, using the canonical
      representation for the YANG data type.  Any reserved characters
      MUST be percent-encoded, according to Sections 2.1 and 2.5 of
      [RFC3986]. 


3)    Section 5.1

      The contents of any query parameter value MUST be encoded according
      to Section 3.4 of [RFC3986].  Any reserved characters MUST be
      percent-encoded, according to Sections 2.1 and 2.5 of [RFC3986].

It should say:

1)    Section 3.5.3

      The leaf-list value is specified as a string, using the canonical
      representation for the YANG data type.  Any reserved characters
      MUST be percent-encoded, according to Sections 2.1, 2.2, and 2.5 of
      [RFC3986].

2)    Section 3.5.3

      The key value is specified as a string, using the canonical
      representation for the YANG data type.  Any reserved characters
      MUST be percent-encoded, according to Sections 2.1, 2.2, and 2.5 of
      [RFC3986]. 

3)    Section 5.1
      
      The contents of any query parameter value MUST be encoded according
      to Section 3.4 of [RFC3986].  Any reserved characters MUST be
      percent-encoded, according to Sections 2.1, 2.2, and 2.5 of [RFC3986].

Notes:

The reserved character list is defined in section 2.2 of RFC 3986

Errata ID: 5504
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Andy Bierman
Date Reported: 2018-09-22
Verifier Name: Ignas Bagdonas
Date Verified: 2019-04-30

Section B.3.8 says:

      GET /mystreams/NETCONF?start-time=2014-10-25T10%3A02%3A00Z\
         &stop-time=2014-10-25T12%3A31%3A00Z

It should say:

      GET /streams/NETCONF?start-time=2014-10-25T10%3A02%3A00Z\
         &stop-time=2014-10-25T12%3A31%3A00Z

Notes:

The node 'mystreams' is incorrect.

RFC 8045, "RADIUS Extensions for IP Port Configuration and Reporting", January 2017

Source of RFC: radext (sec)

Errata ID: 5009
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Andrew Feren
Date Reported: 2017-05-02
Verifier Name: Benoit Claise
Date Verified: 2017-07-27

Section 7.1 says:

   o  sourceTransportPortsLimit:

      *  Name: sourceTransportPortsLimit

      *  Element ID: 458

      *  Description: This Information Element contains the maximum
         number of IP source transport ports that can be used by an end
         user when sending IP packets; each user is associated with one
         or more (source) IPv4 or IPv6 addresses.  This Information
         Element is particularly useful in address-sharing deployments
         that adhere to REQ-4 of [RFC6888].  Limiting the number of
         ports assigned to each user ensures fairness among users and
         mitigates the denial-of-service attack that a user could launch
         against other users through the address-sharing device in order
         to grab more ports.

      *  Data type: unsigned16

      *  Data type semantics: totalCounter

It should say:

   o  sourceTransportPortsLimit:

      *  Name: sourceTransportPortsLimit

      *  Element ID: 458

      *  Description: This Information Element contains the maximum
         number of IP source transport ports that can be used by an end
         user when sending IP packets; each user is associated with one
         or more (source) IPv4 or IPv6 addresses.  This Information
         Element is particularly useful in address-sharing deployments
         that adhere to REQ-4 of [RFC6888].  Limiting the number of
         ports assigned to each user ensures fairness among users and
         mitigates the denial-of-service attack that a user could launch
         against other users through the address-sharing device in order
         to grab more ports.

      *  Data type: unsigned16

      *  Data type semantics: quantity

Notes:

Only change is

* Data type semantics: totalCounter
to
* Data type semantics: quantity

The description is pretty clear that this IE is a maximum value and not a counter.

RFC 8058, "Signaling One-Click Functionality for List Email Headers", January 2017

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: art

Errata ID: 5559
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Etan Wexler
Date Reported: 2018-11-22
Verifier Name: Alexey Melnikov
Date Verified: 2018-11-26

Section 8.3 says:

   Header in Email

   List-Unsubscribe:
       <mailto:listrequest@example.com?subject=unsubscribe>,
       <https://example.com/unsubscribe.html/opaque123456789>
   List-Unsubscribe-Post: List-Unsubscribe=One-Click


   Resulting POST request

   POST /unsubscribe.html/opaque=123456789 HTTP/1.1
                                ^

It should say:

   Header in Email

   List-Unsubscribe:
       <mailto:listrequest@example.com?subject=unsubscribe>,
       <https://example.com/unsubscribe.html/opaque123456789>
   List-Unsubscribe-Post: List-Unsubscribe=One-Click


   Resulting POST request

   POST /unsubscribe.html/opaque123456789 HTTP/1.1

Notes:

The extraneous equality sign (“=”) between “opaque” and “123456789” appears in the target of the HTTP message but not in the “https” URI in the “List-Unsubscribe” field of the mail snippet.

RFC 8059, "PIM Join Attributes for Locator/ID Separation Protocol (LISP) Environments", January 2017

Source of RFC: pim (rtg)

Errata ID: 7512
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alvaro Retana
Date Reported: 2023-05-08
Verifier Name: RFC Editor
Date Verified: 2023-05-08

Section 5.1 says:

   Receiver RLOC:   The RLOC address on which the receiver ETR wishes to
      receiver the unicast-encapsulated flow.

It should say:

   Receiver RLOC:   The RLOC address on which the receiver ETR wishes to
      receive the unicast-encapsulated flow.

Notes:

The second "receiver" should be "receive".

RFC 8060, "LISP Canonical Address Format (LCAF)", February 2017

Note: This RFC has been updated by RFC 9306

Source of RFC: lisp (rtg)

Errata ID: 7252
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2022-11-16
Verifier Name: Alvaro Retana
Date Verified: 2023-02-08

Section 4.6 says:

   RLOC Probe bit (P):  this is the RLOC Probe bit that means the
      Reencap Hop allows RLOC-probe messages to be sent to it.  When the
      R bit is set to 0, RLOC-probes must not be sent.  When a Reencap
      Hop is an anycast address then multiple physical Reencap Hops are
      using the same RLOC address.  In this case, RLOC-probes are not
      needed because when the closest RLOC address is not reachable,
      another RLOC address can be reachable.

It should say:

   RLOC Probe bit (P):  this is the RLOC Probe bit that means the
      Reencap Hop allows RLOC-probe messages to be sent to it.  When the
      P bit is set to 0, RLOC-probes must not be sent.  When a Reencap
      Hop is an anycast address then multiple physical Reencap Hops are
      using the same RLOC address.  In this case, RLOC-probes are not
      needed because when the closest RLOC address is not reachable,
      another RLOC address can be reachable.

Notes:

The R bit is the Revoke bit (see Section 4.7)

RFC 8072, "YANG Patch Media Type", February 2017

Source of RFC: netconf (ops)

Errata ID: 5131
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Robert Wilton
Date Reported: 2017-09-28
Verifier Name: Benoit Claise
Date Verified: 2017-10-12

Section 2.2 says:

Regarding section 2.2 of RFC 8072, the third paragraph states:


                                       ... If the edit does not identify
    any existing resource instance and the operation for the edit is not
    "create", then the request MUST NOT be processed and a "404 Not
    Found" error response MUST be sent by the server.

It should say:

                                      ... If the edit does not identify
   any existing resource instance and the operation for the edit is
   "delete" or "move" then the request MUST NOT be processed and a
   "404 Not Found" error response MUST be sent by the server.

Notes:

As per the second paragraph of section 2.2 of RFC 8072, the operations are expected to mirror the semantics of the "operation" attribute described in Section 7.2 of [RFC6241].

The spec also doesn't specify what happens if it is a "create" operation and the resource already exists. It should probably also state that "400 Bad Request" is returned.

RFC 8078, "Managing DS Records from the Parent via CDS/CDNSKEY", March 2017

Source of RFC: dnsop (ops)

Errata ID: 5049
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ondřej Caletka
Date Reported: 2017-06-23
Verifier Name: Warren Kumari
Date Verified: 2017-08-10

Section 4 says:

   The contents of the CDS or CDNSKEY RRset MUST contain one RR and only
   contain the exact fields as shown below.

      CDS 0 0 0 0

      CDNSKEY 0 3 0 0

   The keying material payload is represented by a single 0.  This
   record is signed in the same way as regular CDS/CDNSKEY RRsets are
   signed.

   Strictly speaking, the CDS record could be "CDS X 0 X 0" as only the
   DNSKEY algorithm is what signals the DELETE operation, but for
   clarity, the "0 0 0 0" notation is mandated -- this is not a
   definition of DS digest algorithm 0.  The same argument applies to
   "CDNSKEY 0 3 0 0"; the value 3 in the second field is mandated by
   [RFC4034], Section 2.1.2.

It should say:

   The contents of the CDS or CDNSKEY RRset MUST contain one RR and only
   contain the exact fields as shown below.

      CDS 0 0 0 00

      CDNSKEY 0 3 0 AA==

   The keying material payload is represented by a single octet with
   the value 00. This record is signed in the same way as regular
   CDS/CDNSKEY RRsets are signed.

   Strictly speaking, the CDS record could be "CDS X 0 X X" as only the
   DNSKEY algorithm is what signals the DELETE operation, but for
   clarity, the "0 0 0 00" notation is mandated -- this is not a
   definition of DS digest algorithm 0.  The same argument applies to
   "CDNSKEY 0 3 0 AA=="; the value 3 in the second field is mandated by
   [RFC4034], Section 2.1.2.

Notes:

RFC 7344 defines both CDS and CDNSKEY record wire and presentation format to be identical to DS and DNSKEY wire and presentation format defined in RFC 4034.

In case of CDNSKEY record, RFC 4034 section 2.2 requires that:
> The Public Key field MUST be represented as a Base64 encoding of the Public Key.

As Base64 encoding encodes 6 bits into one character, one character alone can never be a valid Base64 sequence. The proper encoding of one-byte long sequence with binary value of 00 is AA==.

In case of CDS record, RFC 4034 section 5.3 requires that:
> The Digest MUST be represented as a sequence of case-insensitive hexadecimal digits

Although the value of a single 0 fulfils this requirement per se, it's not properly parsable by many implementations since it is expected to be even number of hex digits to align with octet boundaries in the wire format. So proper form of CDS record should contain two zeroes in place of the digest.


[ AD Note: Discussion on the DNSOP list: - https://www.ietf.org/mail-archive/web/dnsop/current/msg20267.html ]

RFC 8080, "Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC", February 2017

Source of RFC: curdle (sec)

Errata ID: 4935
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tom Thorogood
Date Reported: 2017-02-16
Verifier Name: Stephen Farrell
Date Verified: 2017-02-16

Section 6 says:

6.  Examples

6.1.  Ed25519 Examples

Private-key-format: v1.2
Algorithm: 15 (ED25519)
PrivateKey: ODIyNjAzODQ2MjgwODAxMjI2NDUxOTAyMDQxNDIyNjI=

example.com. 3600 IN DNSKEY 257 3 15 (
             l02Woi0iS8Aa25FQkUd9RMzZHJpBoRQwAQEX1SxZJA4= )

example.com. 3600 IN DS 3613 15 2 (
             3aa5ab37efce57f737fc1627013fee07bdf241bd10f3b1964ab55c78e79
             a304b )

example.com. 3600 IN MX 10 mail.example.com.

example.com. 3600 IN RRSIG MX 3 3600 (
             1440021600 1438207200 3613 example.com. (
             Edk+IB9KNNWg0HAjm7FazXyrd5m3Rk8zNZbvNpAcM+eysqcUOMIjWoevFkj
             H5GaMWeG96GUVZu6ECKOQmemHDg== )



Sury & Edmonds               Standards Track                    [Page 3]

RFC 8080                    EdDSA for DNSSEC               February 2017


Private-key-format: v1.2
Algorithm: 15 (ED25519)
PrivateKey: DSSF3o0s0f+ElWzj9E/Osxw8hLpk55chkmx0LYN5WiY=

example.com. 3600 IN DNSKEY 257 3 15 (
             zPnZ/QwEe7S8C5SPz2OfS5RR40ATk2/rYnE9xHIEijs= )

example.com. 3600 IN DS 35217 15 2 (
             401781b934e392de492ec77ae2e15d70f6575a1c0bc59c5275c04ebe80c
             6614c )

example.com. 3600 IN MX 10 mail.example.com.

example.com. 3600 IN RRSIG MX 3 3600 (
             1440021600 1438207200 35217 example.com. (
             5LL2obmzdqjWI+Xto5eP5adXt/T5tMhasWvwcyW4L3SzfcRawOle9bodhC+
             oip9ayUGjY9T/rL4rN3bOuESGDA== )

6.2.  Ed448 Examples

Private-key-format: v1.2
Algorithm: 16 (ED448)
PrivateKey: xZ+5Cgm463xugtkY5B0Jx6erFTXp13rYegst0qRtNsOYnaVpMx0Z/c5EiA9x
            8wWbDDct/U3FhYWA

example.com. 3600 IN DNSKEY 257 3 16 (
             3kgROaDjrh0H2iuixWBrc8g2EpBBLCdGzHmn+G2MpTPhpj/OiBVHHSfPodx
             1FYYUcJKm1MDpJtIA )

example.com. 3600 IN DS 9713 16 2 (
             6ccf18d5bc5d7fc2fceb1d59d17321402f2aa8d368048db93dd811f5cb2
             b19c7 )

example.com. 3600 IN MX 10 mail.example.com.

example.com. 3600 IN RRSIG MX 3 3600 (
             1440021600 1438207200 9713 example.com. (
             Nmc0rgGKpr3GKYXcB1JmqqS4NYwhmechvJTqVzt3jR+Qy/lSLFoIk1L+9e3
             9GPL+5tVzDPN3f9kAwiu8KCuPPjtl227ayaCZtRKZuJax7n9NuYlZJIusX0
             SOIOKBGzG+yWYtz1/jjbzl5GGkWvREUCUA )











Sury & Edmonds               Standards Track                    [Page 4]

RFC 8080                    EdDSA for DNSSEC               February 2017


Private-key-format: v1.2
Algorithm: 16 (ED448)
PrivateKey: WEykD3ht3MHkU8iH4uVOLz8JLwtRBSqiBoM6fF72+Mrp/u5gjxuB1DV6NnPO
            2BlZdz4hdSTkOdOA

example.com. 3600 IN DNSKEY 257 3 16 (
             kkreGWoccSDmUBGAe7+zsbG6ZAFQp+syPmYUurBRQc3tDjeMCJcVMRDmgcN
             Lp5HlHAMy12VoISsA )

example.com. 3600 IN DS 38353 16 2 (
             645ff078b3568f5852b70cb60e8e696cc77b75bfaaffc118cf79cbda1ba
             28af4 )

example.com. 3600 IN MX 10 mail.example.com.

example.com. 3600 IN RRSIG MX 3 3600 (
             1440021600 1438207200 38353 example.com. (
             +JjANio/LIzp7osmMYE5XD3H/YES8kXs5Vb9H8MjPS8OAGZMD37+LsCIcjg
             5ivt0d4Om/UaqETEAsJjaYe56CEQP5lhRWuD2ivBqE0zfwJTyp4WqvpULbp
             vaukswvv/WNEFxzEYQEIm9+xDlXj4pMAMA )

It should say:

6.  Examples

6.1.  Ed25519 Examples

Private-key-format: v1.2
Algorithm: 15 (ED25519)
PrivateKey: ODIyNjAzODQ2MjgwODAxMjI2NDUxOTAyMDQxNDIyNjI=

example.com. 3600 IN DNSKEY 257 3 15 (
             l02Woi0iS8Aa25FQkUd9RMzZHJpBoRQwAQEX1SxZJA4= )

example.com. 3600 IN DS 3613 15 2 (
             3aa5ab37efce57f737fc1627013fee07bdf241bd10f3b1964ab55c78e79
             a304b )

example.com. 3600 IN MX 10 mail.example.com.

example.com. 3600 IN RRSIG MX 15 2 3600 (
             1440021600 1438207200 3613 example.com. (
             oL9krJun7xfBOIWcGHi7mag5/hdZrKWw15jPGrHpjQeRAvTdszaPD+QLs3f
             x8A4M3e23mRZ9VrbpMngwcrqNAg== )



Sury & Edmonds               Standards Track                    [Page 3]

RFC 8080                    EdDSA for DNSSEC               February 2017


Private-key-format: v1.2
Algorithm: 15 (ED25519)
PrivateKey: DSSF3o0s0f+ElWzj9E/Osxw8hLpk55chkmx0LYN5WiY=

example.com. 3600 IN DNSKEY 257 3 15 (
             zPnZ/QwEe7S8C5SPz2OfS5RR40ATk2/rYnE9xHIEijs= )

example.com. 3600 IN DS 35217 15 2 (
             401781b934e392de492ec77ae2e15d70f6575a1c0bc59c5275c04ebe80c
             6614c )

example.com. 3600 IN MX 10 mail.example.com.

example.com. 3600 IN RRSIG MX 15 2 3600 (
             1440021600 1438207200 35217 example.com. (
             zXQ0bkYgQTEFyfLyi9QoiY6D8ZdYo4wyUhVioYZXFdT410QPRITQSqJSnzQ
             oSm5poJ7gD7AQR0O7KuI5k2pcBg== )

6.2.  Ed448 Examples

Private-key-format: v1.2
Algorithm: 16 (ED448)
PrivateKey: xZ+5Cgm463xugtkY5B0Jx6erFTXp13rYegst0qRtNsOYnaVpMx0Z/c5EiA9x
            8wWbDDct/U3FhYWA

example.com. 3600 IN DNSKEY 257 3 16 (
             3kgROaDjrh0H2iuixWBrc8g2EpBBLCdGzHmn+G2MpTPhpj/OiBVHHSfPodx
             1FYYUcJKm1MDpJtIA )

example.com. 3600 IN DS 9713 16 2 (
             6ccf18d5bc5d7fc2fceb1d59d17321402f2aa8d368048db93dd811f5cb2
             b19c7 )

example.com. 3600 IN MX 10 mail.example.com.

example.com. 3600 IN RRSIG MX 16 2 3600 (
             1440021600 1438207200 9713 example.com. (
             3cPAHkmlnxcDHMyg7vFC34l0blBhuG1qpwLmjInI8w1CMB29FkEAIJUA0am
             xWndkmnBZ6SKiwZSAxGILn/NBtOXft0+Gj7FSvOKxE/07+4RQvE581N3Aj/
             JtIyaiYVdnYtyMWbSNyGEY2213WKsJlwEA )











Sury & Edmonds               Standards Track                    [Page 4]

RFC 8080                    EdDSA for DNSSEC               February 2017


Private-key-format: v1.2
Algorithm: 16 (ED448)
PrivateKey: WEykD3ht3MHkU8iH4uVOLz8JLwtRBSqiBoM6fF72+Mrp/u5gjxuB1DV6NnPO
            2BlZdz4hdSTkOdOA

example.com. 3600 IN DNSKEY 257 3 16 (
             kkreGWoccSDmUBGAe7+zsbG6ZAFQp+syPmYUurBRQc3tDjeMCJcVMRDmgcN
             Lp5HlHAMy12VoISsA )

example.com. 3600 IN DS 38353 16 2 (
             645ff078b3568f5852b70cb60e8e696cc77b75bfaaffc118cf79cbda1ba
             28af4 )

example.com. 3600 IN MX 10 mail.example.com.

example.com. 3600 IN RRSIG MX 16 2 3600 (
             1440021600 1438207200 38353 example.com. (
             E1/oLjSGIbmLny/4fcgM1z4oL6aqo+izT3urCyHyvEp4Sp8Syg1eI+lJ57C
             SnZqjJP41O/9l4m0AsQ4f7qI1gVnML8vWWiyW2KXhT9kuAICUSxv5OWbf81
             Rq7Yu60npabODB0QFPb/rkW3kUZmQ0YQUA )

Notes:

The script used to generate the examples (see https://gitlab.labs.nic.cz/labs/ietf/blob/master/dnskey.py) contains two errors that make the RRSIG records in the example section invalid.
1. The script fails to print the algorithm identifier (15 & 16, TBD1 & TBD2 in earlier drafts) for RRSIGs, and
2. the implementation of label counting includes the root zone as a label, giving an incorrect count of 3 rather than 2.

The first bug is more cosmetic but does result in unparsable RRSIG records, while the second bug causes invalid signatures to be produced.

With these two bugs corrected (and no other changes) the script produces valid examples which are included in the correction above. They have been successfully tested with an independent implementation of RFC 8080 based on https://github.com/miekg/dns & https://godoc.org/golang.org/x/crypto/ed25519 .

RFC 8085, "UDP Usage Guidelines", March 2017

Note: This RFC has been updated by RFC 8899

Source of RFC: tsvwg (wit)

Errata ID: 7106
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Adam Wall
Date Reported: 2022-08-31
Verifier Name: Martin Duke
Date Verified: 2022-09-22

Section 3.4 says:

More description of the set of checks performed using the checksum field is provided in Section 3.1 of [RFC6396].

It should say:

More description of the set of checks performed using the checksum field is provided in Section 3.1 of [RFC6936].

Notes:

The wrong RFC was referenced under "Checksum Guidelines" Section 3.4, including the same wrong RFC information within the "Informative References" Section 8.2.

RFC 8086, "GRE-in-UDP Encapsulation", March 2017

Source of RFC: tsvwg (wit)

Errata ID: 5006
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Donald Eastlake
Date Reported: 2017-04-28
Verifier Name: RFC Editor
Date Verified: 2017-06-12

Section 8 says:

   Section 3.1.9 of [RFC8085] discusses the congestion considerations
   for design and use of UDP tunnels;

It should say:

   Section 3.1.11 of [RFC8085] discusses the congestion considerations
   for design and use of UDP tunnels;

Notes:

There appears to be an incorrect reference to 3.1.9 that should refer to 3.1.11.

RFC 8087, "The Benefits of Using Explicit Congestion Notification (ECN)", March 2017

Source of RFC: aqm (tsv)

Errata ID: 7586
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin Duke
Date Reported: 2023-08-02
Verifier Name: Martin Duke
Date Verified: 2024-01-18

Section 1 says:

The  ECT(0) codepoint '01' and the ECT(1) codepoint '10' both indicate
that the transport protocol using the IP layer supports the use of
ECN.

It should say:

The  ECT(0) codepoint '10' and the ECT(1) codepoint '01' both indicate
that the transport protocol using the IP layer supports the use of
ECN.

Notes:

Figure 1, immediately afterwards, has the correct codepoints, which are consistent with RFC 3168.

RFC 8095, "Services Provided by IETF Transport Protocols and Congestion Control Mechanisms", March 2017

Source of RFC: taps (wit)

Errata ID: 5285
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Wesley Eddy
Date Reported: 2018-03-12
Verifier Name: Mirja Kühlewind
Date Verified: 2018-03-12

Section section 3.1 says:

3.1 Transport Control Protocol (TCP)

It should say:

3.1 Transmission Control Protocol (TCP)

Notes:

The acronym-expansion for TCP is incorrect in the section title, but is correct in other text within the document.

Errata ID: 6710
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jie Zhang
Date Reported: 2021-10-15
Verifier Name: RFC Editor
Date Verified: 2022-01-27

Section 3.11.1 says:

Error detection and verification of the protocol control information
relies on the on the underlying transport (e.g., UDP checksum).

It should say:

Error detection and verification of the protocol control information
relies on the underlying transport (e.g., UDP checksum).

Notes:

There is a redundant "on the".

RFC 8103, "Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS)", February 2017

Source of RFC: curdle (sec)

Errata ID: 5353
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kevin Israel
Date Reported: 2018-05-10
Verifier Name: Benjamin Kaduk
Date Verified: 2018-05-11

Section 6 says:

   The amount of encrypted data possible in a single invocation of
   AEAD_CHACHA20_POLY1305 is 2^32-1 blocks of 64 octets each, because of
   the size of the block counter field in the ChaCha20 block function.
   This gives a total of 247,877,906,880 octets, which is likely to be
   sufficient to handle the size of any CMS content type.  Note that the
   ciphertext length field in the authentication buffer will accommodate
   2^64 octets, which is much larger than necessary.

It should say:

   The amount of encrypted data possible in a single invocation of
   AEAD_CHACHA20_POLY1305 is 2^32-1 blocks of 64 octets each, because of
   the size of the block counter field in the ChaCha20 block function.
   This gives a total of 274,877,906,880 octets, which is likely to be
   sufficient to handle the size of any CMS content type.  Note that the
   ciphertext length field in the authentication buffer will accommodate
   2^64 octets, which is much larger than necessary.

Notes:

The calculated total number of octets that can be encrypted in a single invocation is incorrect. See RFC Errata, Erratum ID 4858, RFC 7539.

RFC 8110, "Opportunistic Wireless Encryption", March 2017

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 5427
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexandru Lupascu
Date Reported: 2018-07-17
Verifier Name: Benjamin Kaduk
Date Verified: 2018-08-23

Section 3 says:

To add an opportunistic encryption mode of access to [IEEE802.11], it
   is necessary to perform a Diffie-Hellman key exchange during 802.11
   authentication and use the resulting pairwise secret with the 4-way
   handshake.

It should say:

To add an opportunistic encryption mode of access to [IEEE802.11], it
   is necessary to perform a Diffie-Hellman key exchange during 802.11
   association and use the resulting pairwise secret with the 4-way
   handshake.

Notes:

As stated in Section 4.4, the Diffie-Hellman key exchange is completed in the 802.11 association step and NOT in the 802.11 authentication step: "Once the client and AP have finished 802.11 association, they then complete the Diffie-Hellman key exchange ...".

Errata ID: 5951
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: David Goodall
Date Reported: 2019-12-30
Verifier Name: Barry Leiba
Date Verified: 2020-01-02

Section 4.4 Table 2 says:

HMAC-SHA-521

It should say:

HMAC-SHA-512

RFC 8122, "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", March 2017

Note: This RFC has been updated by RFC 8844

Source of RFC: mmusic (art)

Errata ID: 5683
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sean Leonard
Date Reported: 2019-04-04
Verifier Name: RFC Editor
Date Verified: 2019-05-16

Section 8 says:

             Table 1: IANA Hash Function Textual Name Registry

It should say:

             Table 1: IANA "Hash Function Textual Names" Registry

Notes:

The name of the registry is the "Hash Function Textual Names" registry.

RFC 8146, "Adding Support for Salted Password Databases to EAP-pwd", April 2017

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 5454
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Edward Huff
Date Reported: 2018-08-09
Verifier Name: Benjamin Kaduk
Date Verified: 2018-08-09

Section 2.2 says:

salted-password = Hash(password | salt)

It should say:

salted-password = Hash(password || salt)

Notes:

Elsewhere in this document || is used to denote concatenation.

RFC 8147, "Next-Generation Pan-European eCall", May 2017

Source of RFC: ecrit (art)

Errata ID: 7752
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Andreas Wehrmann
Date Reported: 2024-01-09
Verifier Name: Murray Kucherawy
Date Verified: 2024-03-18

Section 11 says:

<?xml version="1.0"?>
<xs:schema
    targetNamespace="urn:ietf:params:xml:ns:EmergencyCallData:control"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns:pi="urn:ietf:params:xml:ns:EmergencyCallData:control"
    xmlns:xml="http://www.w3.org/XML/1998/namespace"
    elementFormDefault="qualified"
    attributeFormDefault="unqualified">
    
    <xs:import namespace="http://www.w3.org/XML/1998/namespace"/>
    
    <xs:element name="EmergencyCallData.Control"
        type="pi:controlType"/>
    
    <xs:complexType name="controlType">
        <xs:complexContent>
            <xs:restriction base="xs:anyType">
                <xs:choice>
                    <xs:element name="capabilities"
                        type="pi:capabilitiesType"/>
                    <xs:element name="request" type="pi:requestType"/>
                    <xs:element name="ack" type="pi:ackType"/>
                    <xs:any namespace="##any" processContents="lax"
                        minOccurs="0"
                        maxOccurs="unbounded"/>
                </xs:choice>
                <xs:anyAttribute/>
            </xs:restriction>
        </xs:complexContent>
    </xs:complexType>
    
    <xs:complexType name="ackType">
        <xs:complexContent>
            <xs:restriction base="xs:anyType">
                <xs:sequence minOccurs="1" maxOccurs="unbounded">
                    <xs:element name="actionResult" minOccurs="0"
                        maxOccurs="unbounded">
                        <xs:complexType>
                            <xs:attribute name="action"
                                type="xs:token"
                                use="required"/>
                            <xs:attribute name="success"
                                type="xs:boolean"
                                use="required"/>
                            <xs:attribute name="reason"
                                type="xs:token">
                                <xs:annotation>
                                    <xs:documentation>
                                        conditionally mandatory
                                        when @success="false"
                                        to indicate reason code
                                        for a failure
                                    </xs:documentation>
                                </xs:annotation>
                            </xs:attribute>
                            <xs:attribute name="details"
                                type="xs:string"/>
                            <xs:anyAttribute
                                processContents="skip"/>
                        </xs:complexType>
                    </xs:element>
                    <xs:any namespace="##any" processContents="lax"
                        minOccurs="0"
                        maxOccurs="unbounded"/>
                </xs:sequence>
                <xs:attribute name="ref"
                    type="xs:anyURI"
                    use="required"/>
                
                <xs:attribute name="received"
                    type="xs:boolean"/>
                <xs:anyAttribute/>
            </xs:restriction>
        </xs:complexContent>
    </xs:complexType>
    
    <xs:complexType name="capabilitiesType">
        <xs:complexContent>
            <xs:restriction base="xs:anyType">
                <xs:sequence minOccurs="1" maxOccurs="unbounded">
                    <xs:element name="request"
                        type="pi:requestType"
                        minOccurs="1"
                        maxOccurs="unbounded"/>
                    <xs:any namespace="##any" processContents="lax"
                        minOccurs="0"
                        maxOccurs="unbounded"/>
                </xs:sequence>
                <xs:anyAttribute/>
            </xs:restriction>
        </xs:complexContent>
    </xs:complexType>
    
    <xs:complexType name="requestType">
        <xs:complexContent>
            <xs:restriction base="xs:anyType">
                <xs:choice minOccurs="1" maxOccurs="unbounded">
                    <xs:element name="text" minOccurs="0"
                        maxOccurs="unbounded">
                        <xs:complexType>
                            <xs:simpleContent>
                                <xs:extension base="xs:string">
                                    <xs:anyAttribute
                                        namespace="##any"
                                        processContents="skip"/>
                                </xs:extension>
                            </xs:simpleContent>
                        </xs:complexType>
                    </xs:element>
                    <xs:any namespace="##any" processContents="lax"
                        minOccurs="0"
                        maxOccurs="unbounded"/>
                </xs:choice>
                <xs:attribute name="action" type="xs:token"
                    use="required"/>
                
                <xs:attribute name="int-id" type="xs:unsignedInt"/>
                <xs:attribute name="persistence"
                    type="xs:duration"/>
                <xs:attribute name="datatype" type="xs:token"/>
                <xs:attribute name="supported-values"
                    type="xs:string"/>
                <xs:attribute name="element-id" type="xs:token"/>
                <xs:attribute name="requested-state"
                    type="xs:token"/>
                <xs:anyAttribute/>
            </xs:restriction>
        </xs:complexContent>
    </xs:complexType>
</xs:schema>

It should say:

<?xml version="1.0"?>
<xs:schema
    targetNamespace="urn:ietf:params:xml:ns:EmergencyCallData:control"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns:pi="urn:ietf:params:xml:ns:EmergencyCallData:control"
    xmlns:xml="http://www.w3.org/XML/1998/namespace"
    elementFormDefault="qualified"
    attributeFormDefault="unqualified">
    
    <xs:import namespace="http://www.w3.org/XML/1998/namespace"/>
    
    <xs:element name="EmergencyCallData.Control"
        type="pi:controlType"/>
    
    <xs:complexType name="controlType">
        <xs:complexContent>
            <xs:restriction base="xs:anyType">
                <xs:choice>
                    <xs:element name="capabilities"
                        type="pi:capabilitiesType"/>
                    <xs:element name="request" type="pi:requestType"/>
                    <xs:element name="ack" type="pi:ackType"/>
                    <xs:any namespace="##other" processContents="lax"
                        minOccurs="0"
                        maxOccurs="unbounded"/>
                </xs:choice>
                <xs:anyAttribute/>
            </xs:restriction>
        </xs:complexContent>
    </xs:complexType>
    
    <xs:complexType name="ackType">
        <xs:complexContent>
            <xs:restriction base="xs:anyType">
                <xs:sequence minOccurs="1" maxOccurs="unbounded">
                    <xs:element name="actionResult" minOccurs="0"
                        maxOccurs="unbounded">
                        <xs:complexType>
                            <xs:attribute name="action"
                                type="xs:token"
                                use="required"/>
                            <xs:attribute name="success"
                                type="xs:boolean"
                                use="required"/>
                            <xs:attribute name="reason"
                                type="xs:token">
                                <xs:annotation>
                                    <xs:documentation>
                                        conditionally mandatory
                                        when @success="false"
                                        to indicate reason code
                                        for a failure
                                    </xs:documentation>
                                </xs:annotation>
                            </xs:attribute>
                            <xs:attribute name="details"
                                type="xs:string"/>
                            <xs:anyAttribute
                                processContents="skip"/>
                        </xs:complexType>
                    </xs:element>
                    <xs:any namespace="##other" processContents="lax"
                        minOccurs="0"
                        maxOccurs="unbounded"/>
                </xs:sequence>
                <xs:attribute name="ref"
                    type="xs:anyURI"
                    use="required"/>
                
                <xs:attribute name="received"
                    type="xs:boolean"/>
                <xs:anyAttribute/>
            </xs:restriction>
        </xs:complexContent>
    </xs:complexType>
    
    <xs:complexType name="capabilitiesType">
        <xs:complexContent>
            <xs:restriction base="xs:anyType">
                <xs:sequence minOccurs="1" maxOccurs="unbounded">
                    <xs:element name="request"
                        type="pi:requestType"
                        minOccurs="1"
                        maxOccurs="unbounded"/>
                    <xs:any namespace="##other" processContents="lax"
                        minOccurs="0"
                        maxOccurs="unbounded"/>
                </xs:sequence>
                <xs:anyAttribute/>
            </xs:restriction>
        </xs:complexContent>
    </xs:complexType>
    
    <xs:complexType name="requestType">
        <xs:complexContent>
            <xs:restriction base="xs:anyType">
                <xs:choice minOccurs="1" maxOccurs="unbounded">
                    <xs:element name="text" minOccurs="0"
                        maxOccurs="unbounded">
                        <xs:complexType>
                            <xs:simpleContent>
                                <xs:extension base="xs:string">
                                    <xs:anyAttribute
                                        namespace="##any"
                                        processContents="skip"/>
                                </xs:extension>
                            </xs:simpleContent>
                        </xs:complexType>
                    </xs:element>
                    <xs:any namespace="##other" processContents="lax"
                        minOccurs="0"
                        maxOccurs="unbounded"/>
                </xs:choice>
                <xs:attribute name="action" type="xs:token"
                    use="required"/>
                
                <xs:attribute name="int-id" type="xs:unsignedInt"/>
                <xs:attribute name="persistence"
                    type="xs:duration"/>
                <xs:attribute name="datatype" type="xs:token"/>
                <xs:attribute name="supported-values"
                    type="xs:string"/>
                <xs:attribute name="element-id" type="xs:token"/>
                <xs:attribute name="requested-state"
                    type="xs:token"/>
                <xs:anyAttribute/>
            </xs:restriction>
        </xs:complexContent>
    </xs:complexType>
</xs:schema>

Notes:

The complex types "controlType", "ackType", "capabilitiesType" and "requestType" define extension points by using xs:any with namespace ##any. This violates the "Unique Particle Attribution" rule for XSD 1.0 (see: https://www.w3.org/wiki/UniqueParticleAttribution) and shows up as an error in some tools.

I suggest changing the namespace to ##other like it's done in other schemas (for example, RFC7865 defines extension points in this way: https://datatracker.ietf.org/doc/html/rfc7865#section-9 ).

[Verifier note:]

Replace all four occurrences of:

<xs:any namespace="##any" processContents="lax">

with:

<xs:any namespace="##other" processContents="lax">

RFC 8148, "Next-Generation Vehicle-Initiated Emergency Calls", May 2017

Source of RFC: ecrit (art)

Errata ID: 6500
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lars Eggert
Date Reported: 2021-03-29
Verifier Name: Murray Kucherawy
Date Verified: 2022-05-23

Section 14.1 says:

      Change controller:  The IESG <ietf@ietf.org>

It should say:

      Change controller:  The IESG <iesg@ietf.org>

Notes:

The current text has the email address of the "IETF discuss" list for the IESG, which is incorrect.

RFC 8152, "CBOR Object Signing and Encryption (COSE)", July 2017

Note: This RFC has been obsoleted by RFC 9052, RFC 9053

Source of RFC: cose (sec)

Errata ID: 5066
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jim Schaad
Date Reported: 2017-07-11
Verifier Name: Benjamin Kaduk
Date Verified: 2020-10-07

Section 14 says:

   o  The restriction applies to the encoding of the Sig_structure, the
      Enc_structure, and the MAC_structure.

It should say:

   o  The restriction applies to the encoding of the COSE_KDF_Context, 
      Sig_structure, the Enc_structure, and the MAC_structure.

Notes:

When listing the set of structure that need to be canonically encoded, I missed this one.

Verifier Notes: this is being fixed in draft-ietf-cose-rfc8152bis-algs.

Errata ID: 5545
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Francesca Palombini
Date Reported: 2018-11-05
Verifier Name: Benjamin Kaduk
Date Verified: 2019-01-16

Section 7.1 says:

   +---------+-------+----------------+------------+-------------------+
   | Name    | Label | CBOR Type      | Value      | Description       |
   |         |       |                | Registry   |                   |
   +---------+-------+----------------+------------+-------------------+
   | kty     | 1     | tstr / int     | COSE Key   | Identification of |
   |         |       |                | Common     | the key type      |
   |         |       |                | Parameters |                   |
   |         |       |                |            |                   |
   | kid     | 2     | bstr           |            | Key               |
   |         |       |                |            | identification    |
   |         |       |                |            | value -- match to |
   |         |       |                |            | kid in message    |
   |         |       |                |            |                   |
   | alg     | 3     | tstr / int     | COSE       | Key usage         |
   |         |       |                | Algorithms | restriction to    |
   |         |       |                |            | this algorithm    |
   |         |       |                |            |                   |
   | key_ops | 4     | [+ (tstr/int)] |            | Restrict set of   |
   |         |       |                |            | permissible       |
   |         |       |                |            | operations        |
   |         |       |                |            |                   |
   | Base IV | 5     | bstr           |            | Base IV to be     |
   |         |       |                |            | xor-ed with       |
   |         |       |                |            | Partial IVs       |
   +---------+-------+----------------+------------+-------------------+

                          Table 3: Key Map Labels

It should say:

   +---------+-------+----------------+------------+-------------------+
   | Name    | Label | CBOR Type      | Value      | Description       |
   |         |       |                | Registry   |                   |
   +---------+-------+----------------+------------+-------------------+
   | kty     | 1     | tstr / int     | COSE Key   | Identification of |
   |         |       |                | Types      | the key type      |
   |         |       |                |            |                   |
   |         |       |                |            |                   |
   | kid     | 2     | bstr           |            | Key               |
   |         |       |                |            | identification    |
   |         |       |                |            | value -- match to |
   |         |       |                |            | kid in message    |
   |         |       |                |            |                   |
   | alg     | 3     | tstr / int     | COSE       | Key usage         |
   |         |       |                | Algorithms | restriction to    |
   |         |       |                |            | this algorithm    |
   |         |       |                |            |                   |
   | key_ops | 4     | [+ (tstr/int)] |            | Restrict set of   |
   |         |       |                |            | permissible       |
   |         |       |                |            | operations        |
   |         |       |                |            |                   |
   | Base IV | 5     | bstr           |            | Base IV to be     |
   |         |       |                |            | xor-ed with       |
   |         |       |                |            | Partial IVs       |
   +---------+-------+----------------+------------+-------------------+

                          Table 3: Key Map Labels

Notes:

The value registry for kty should be COSE Key Types, as indicated in the text following Table 3. This change affects the IANA registry: https://www.iana.org/assignments/cose/cose.xhtml#key-common-parameters

Errata ID: 5650
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jim Schaad
Date Reported: 2019-03-11
Verifier Name: Benjamin Kaduk
Date Verified: 2019-03-11

Section Section 13.2 says:

   | crv  | 1     | -1    | int /  | EC identifier - Taken from the    |
   |      |       |       | tstr   | "COSE Key Common Parameters"      |
   |      |       |       |        | registry                          |

It should say:

   | crv  | 1     | -1    | int /  | EC identifier - Taken from the    |
   |      |       |       | tstr   | "COSE Elliptic Curves" registry   |

Notes:

The set of curve identifiers lives in the COSE Elliptic Curves registry and not in the COSE Key Common Parameters registry.

Errata ID: 5669
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Marco Tiloca
Date Reported: 2019-03-23
Verifier Name: Benjamin Kaduk
Date Verified: 2019-03-25

Section 16.7 says:

Value:  This is the value used to identify the curve.  These values
   MUST be unique.  The value can be a positive integer, a negative
   integer, or a string.

Description:  This field contains a brief description of the curve.

References:  This contains a pointer to the public specification for
   the curve if one exists.

It should say:

Value:  This is the value used to identify the key type.  These values
   MUST be unique.  The values are positive integers.

Description:  This field contains a brief description of the key type.

References:  This contains a pointer to the public specification for
   the key type if one exists.

Notes:

This Registry is about Key Types, but the current text refers to curves.

The value identifying a key type can be only a positive integer.

Errata ID: 6209
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: JimSchaad
Date Reported: 2020-06-16
Verifier Name: Benjamin Kaduk
Date Verified: 2020-06-17

Section 9 says:

can be used to prove the identity

It should say:

cannot be used to prove the identity

Notes:

MACs cannot be used to prove identity to a third party. There is a missing "not" in the sentence.

Errata ID: 6487
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Thomas Fossati
Date Reported: 2021-03-18
Verifier Name: Benjamin Kaduk
Date Verified: 2021-07-21

Section C.7 says:

In order the keys are:

   o  An EC key with a kid of "meriadoc.brandybuck@buckland.example"

   o  An EC key with a kid of "peregrin.took@tuckborough.example"

   o  An EC key with a kid of "bilbo.baggins@hobbiton.example"

   o  An EC key with a kid of "11"

It should say:

In order the keys are:

   o  An EC key with a kid of "meriadoc.brandybuck@buckland.example"

   o  An EC key with a kid of "11"

   o  An EC key with a kid of "bilbo.baggins@hobbiton.example"

   o  An EC key with a kid of "peregrin.took@tuckborough.example"

Notes:

The order of this list does not match the actual keys listed subsequently.

RFC 8162, "Using Secure DNS to Associate Certificates with Domain Names for S/MIME", May 2017

Source of RFC: dane (sec)

Errata ID: 6544
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kaspar Etter
Date Reported: 2021-04-14
Verifier Name: Roman Danyliw
Date Verified: 2022-01-20

Section 1 says:

Others to want mitigate the difficulty of finding certificates from outside the enterprise.

It should say:

Others want to mitigate the difficulty of finding certificates from outside the enterprise.

Notes:

Wrong order of words.

RFC 8163, "Transmission of IPv6 over Master-Slave/Token-Passing (MS/TP) Networks", May 2017

Source of RFC: 6lo (int)

Errata ID: 5996
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kerry Lynn
Date Reported: 2020-02-27
Verifier Name: Erik Kline
Date Verified: 2021-08-06

Section Appendix B. says:

       /*
        * Sanity check the encoding to prevent the while() loop below
        * from overrunning the output buffer.
        */
       if (read_index + code > length)
         return 0;

It should say:

       /*
        * Sanity check the encoding to prevent the while() loop below
        * from overrunning the output buffer.
        */
       if (code == 0 || read_index + code > length)
         return 0;

Notes:

This was submitted as a change to [BACnet], Annex T, by James Butler. The normative procedure for decoding COBS is correct in [BACnet], 9.10.3.2(a) but this bug appears in the informative example in Annex T. Since the purpose of COBS encoding is to eliminate all zero bytes from the data, the presence of a zero indicates an error.

RFC 8175, "Dynamic Link Exchange Protocol (DLEP)", June 2017

Source of RFC: manet (rtg)

Errata ID: 6472
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Rick Taylor
Date Reported: 2021-03-10
Verifier Name: Alvaro Retana
Date Verified: 2022-05-26

Section 12.4, para 2 says:

A Peer Offer Signal MUST be encoded within a UDP packet.  The IP source and destination fields in the packet MUST be set by swapping the values received in the Peer Discovery Signal.  The Peer Offer Signal completes the discovery process; see Section 7.1.

It should say:

A Peer Offer Signal MUST be encoded within a UDP packet. The IP source and destination fields (addresses and ports) in the packet MUST be set by swapping the values received in the Peer Discovery Signal, with the exception that the new source address on the Offer Signal, which was the well-known destination address, becomes a local IP from the DLEP modem. The source port remains the well-known port from the Peer Discovery Signal. The Peer Offer signal contains zero or more connection points as described in 13.2 and 13.3 completes the discovery process; see Section 7.1 

Notes:

The original text will not result in a valid unicast IP packet.

=====
AD Note: The original text is clearly wrong. There has been discussion in the WG about the proper wording for the "corrected text". Given that the current text results in an invalid packet, I am marking this report as Verified.

https://mailarchive.ietf.org/arch/msg/manet/h8Sa924gn6ZmAZ7XNp-5UUrZlAY/

Errata ID: 6877
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Izar
Date Reported: 2022-03-10
Verifier Name: Alvaro Retana
Date Verified: 2022-03-10

Section 12.2. says:

All status code values less than 100 have a failure mode of 'Continue'; all other status codes have a failure mode of 'Terminate'.

It should say:

All status code values less than 128 have a failure mode of 'Continue'; all other status codes have a failure mode of 'Terminate'.

Notes:

"Table 2: DLEP Status Codes" indicates that all status code values less than 128 have failure mode 'Continue'.

RFC 8179, "Intellectual Property Rights in IETF Technology", May 2017

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: gen

Errata ID: 5311
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stuart Cheshire
Date Reported: 2018-03-28
Verifier Name: Lars Eggert
Date Verified: 2021-03-31

Section 5.4.2. says:

an IPR
disclosure must be updated or a new disclosure made promptly after
any of the following has occurred: ...
(4) a material change to the IETF
Document covered by the Disclosure that causes the Disclosure to
be covered by additional IPR.

It should say:

an IPR
disclosure must be updated or a new disclosure made promptly after
any of the following has occurred: ...
(4) a material change to the IETF
Document covered by the Disclosure that causes the *Document* to
be covered by additional IPR.

Notes:

The changed word is indicated by asterisks. Section 5.4.2 (Updating IPR Disclosures) of RFC 8179 is talking about IPR that covers IETF Documents, not IPR that covers IETF Disclosures.

Errata ID: 5312
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stuart Cheshire
Date Reported: 2018-03-28
Verifier Name: Lars Eggert
Date Verified: 2021-03-31

Section 5.7 says:

If a Contribution is oral and is not followed promptly by a written
disclosure of the same material, and if such oral Contribution would
be subject to a requirement that an IPR Disclosure be made (had such
oral Contribution been written), then the Contributor must accompany
such oral Contribution with an oral declaration that he/she is aware
of relevant IPR in as much detail as reasonably possible or file an
IPR Declaration with respect to such oral Contribution that otherwise
complies with the provisions of Sections 5.1 to 5.6 above.

It should say:

If a Contribution is oral and is not followed promptly by a written
*Contribution* of the same material, and if such oral Contribution would
be subject to a requirement that an IPR Disclosure be made (had such
oral Contribution been written), then the Contributor must accompany
such oral Contribution with an oral declaration that he/she is aware
of relevant IPR in as much detail as reasonably possible or file an
IPR Declaration with respect to such oral Contribution that otherwise
complies with the provisions of Sections 5.1 to 5.6 above.

Notes:

The changed word is indicated by asterisks. RFC 8179 provides clear definitions of the terms it uses, particularly the important term “Contribution”. In this case, Section 5.7 (Disclosures for Oral Contributions) is talking very specifically about a written “Contribution”, as defined in Section 1, not a “disclosure”. This interpretation of what this text was intending to say is supported by the (non-normative) change summary given in Section 13, which says, “However, if an oral contribution is made and it is not followed by a written contribution, then...” Note use of the term, “written contribution”, not “written disclosure”.

RFC 8182, "The RPKI Repository Delta Protocol (RRDP)", July 2017

Source of RFC: sidr (rtg)

Errata ID: 7239
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Job Snijders
Date Reported: 2022-11-04
Verifier Name: John Scudder
Date Verified: 2023-02-08

Section 3.2 says:

Certificate Authorities that use RRDP MUST include an instance of an
SIA AccessDescription extension in resource certificates they
produce, in addition to the ones defined in [RFC6487]:

It should say:

Certificate Authorities that use RRDP MUST include an instance of an
SIA AccessDescription extension in CA resource certificates they
produce, in addition to the ones defined in [RFC6487]:

Notes:

Between draft-ietf-sidr-delta-protocol-04 and draft-ietf-sidr-delta-protocol-05 a bit of text was removed (perhaps because it was considered redundant). But, unfortunately that snippet helped establish important context as to what types of certificates are expected to contain the id-ad-rpkiNotify accessMethod inside the Subject Information Access extension. The text that was removed:

"""
Relying Parties that do not support this delta protocol MUST MUST NOT
reject a CA certificate merely because it has an SIA extension
containing this new kind of AccessDescription.
"""

From the removed text is is clear that id-ad-rpkiNotify was only expected to show up on CA certificates. However, without the above text, Section 3.2 of RFC 8182 is somewhat ambiguous whether 'resource certificates' is inclusive of EE certificates or not.

RFC 6487 Section 4.8.8.2 sets expectations that only id-ad-signedObject is expected to show up in the SIA of EE certificates "Other AccessMethods MUST NOT be used for an EE certificates's SIA."

The ambiguity in RFC8182 led to one RIR including id-ad-rpkiNotify in the SIA of the EE certificate of all signed objects they produce (such as ROAs). The RIR indicated they'll work to remove id-ad-rpkiNotify from all EE certificates their CA implementation produces.

It should be noted that the presence of id-ad-rpkiNotify in EE certificates is superfluous; Relying Parties can't use the rpkiNotify accessMethod in EE certificates for any purpose in the validation decision tree.

(Verifying this Errata does not block a future transition from rsync to https; as RFC6487 Section 4.8.8.2 leaves room for additional instances of id-ad-signedObject with non-rsync URIs)

RFC 8188, "Encrypted Content-Encoding for HTTP", June 2017

Source of RFC: httpbis (wit)

Errata ID: 5051
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2017-06-24
Verifier Name: RFC Editor
Date Verified: 2017-06-24

Section 6.1 says:

   [FIPS180-4]
              National Institute of Standards and Technology, "Secure
              Hash Standard (SHS)", FIPS PUB 180-4,
              DOI 10.6028/NIST.FIPS180-4, August 2015,
              <http://nvlpubs.nist.gov/nistpubs/FIPS/
              NIST.FIPS.180-4.pdf>.

It should say:

   [FIPS180-4]
              National Institute of Standards and Technology, "Secure
              Hash Standard (SHS)", FIPS PUB 180-4,
              DOI 10.6028/NIST.FIPS.180-4, August 2015,
              <http://nvlpubs.nist.gov/nistpubs/FIPS/
              NIST.FIPS.180-4.pdf>.

Notes:

(incorrect DOI)

RFC 8200, "Internet Protocol, Version 6 (IPv6) Specification", July 2017

Source of RFC: 6man (int)

Errata ID: 5945
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bob Hinden
Date Reported: 2019-12-24
Verifier Name: Suresh Krishnan
Date Verified: 2020-02-03

Section 4.5 says:

4.5.  Fragment Header

   The Fragment header is used by an IPv6 source to send a packet larger
   than would fit in the path MTU to its destination.  (Note: unlike
   IPv4, fragmentation in IPv6 is performed only by source nodes, not by
   routers along a packet's delivery path -- see [RFC8200].)  The
   Fragment header is identified by a Next Header value of 44 in the
   immediately preceding header and has the following format:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |   Reserved    |      Fragment Offset    |Res|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Identification                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Next Header         8-bit selector.  Identifies the initial header
                          type of the Fragmentable Part of the original
                          packet (defined below).  Uses the same values
                          as the IPv4 Protocol field [IANA-PN].

      Reserved            8-bit reserved field.  Initialized to zero for
                          transmission; ignored on reception.

      Fragment Offset     13-bit unsigned integer.  The offset, in
                          8-octet units, of the data following this
                          header, relative to the start of the
                          Fragmentable Part of the original packet.

      Res                 2-bit reserved field.  Initialized to zero for
                          transmission; ignored on reception.

      M flag              1 = more fragments; 0 = last fragment.

      Identification      32 bits.  See description below.

   In order to send a packet that is too large to fit in the MTU of the
   path to its destination, a source node may divide the packet into
   fragments and send each fragment as a separate packet, to be
   reassembled at the receiver.

   For every packet that is to be fragmented, the source node generates
   an Identification value.  The Identification must be different than
   that of any other fragmented packet sent recently* with the same
   Source Address and Destination Address.  If a Routing header is
   present, the Destination Address of concern is that of the final
   destination.


      *  "recently" means within the maximum likely lifetime of a
         packet, including transit time from source to destination and
         time spent awaiting reassembly with other fragments of the same
         packet.  However, it is not required that a source node knows
         the maximum packet lifetime.  Rather, it is assumed that the
         requirement can be met by implementing an algorithm that
         results in a low identification reuse frequency.  Examples of
         algorithms that can meet this requirement are described in
         [RFC7739].

   The initial, large, unfragmented packet is referred to as the
   "original packet", and it is considered to consist of three parts, as
   illustrated:

   original packet:

   +------------------+-------------------------+---//----------------+
   |  Per-Fragment    | Extension & Upper-Layer |   Fragmentable      |
   |    Headers       |       Headers           |      Part           |
   +------------------+-------------------------+---//----------------+

      The Per-Fragment headers must consist of the IPv6 header plus any
      extension headers that must be processed by nodes en route to the
      destination, that is, all headers up to and including the Routing
      header if present, else the Hop-by-Hop Options header if present,
      else no extension headers.

      The Extension headers are all other extension headers that are not
      included in the Per-Fragment headers part of the packet.  For this
      purpose, the Encapsulating Security Payload (ESP) is not
      considered an extension header.  The Upper-Layer header is the
      first upper-layer header that is not an IPv6 extension header.
      Examples of upper-layer headers include TCP, UDP, IPv4, IPv6,
      ICMPv6, and as noted ESP.

      The Fragmentable Part consists of the rest of the packet after the
      upper-layer header or after any header (i.e., initial IPv6 header
      or extension header) that contains a Next Header value of No Next
      Header.

   The Fragmentable Part of the original packet is divided into
   fragments.  The lengths of the fragments must be chosen such that the
   resulting fragment packets fit within the MTU of the path to the
   packet's destination(s).  Each complete fragment, except possibly the
   last ("rightmost") one, is an integer multiple of 8 octets long.

   The fragments are transmitted in separate "fragment packets" as
   illustrated:

   original packet:

   +-----------------+-----------------+--------+--------+-//-+--------+
   |  Per-Fragment   |Ext & Upper-Layer|  first | second |    |  last  |
   |    Headers      |    Headers      |fragment|fragment|....|fragment|
   +-----------------+-----------------+--------+--------+-//-+--------+

   fragment packets:

   +------------------+---------+-------------------+----------+
   |  Per-Fragment    |Fragment | Ext & Upper-Layer |  first   |
   |    Headers       | Header  |   Headers         | fragment |
   +------------------+---------+-------------------+----------+

   +------------------+--------+-------------------------------+
   |  Per-Fragment    |Fragment|    second                     |
   |    Headers       | Header |   fragment                    |
   +------------------+--------+-------------------------------+
                         o
                         o
                         o
   +------------------+--------+----------+
   |  Per-Fragment    |Fragment|   last   |
   |    Headers       | Header | fragment |
   +------------------+--------+----------+

   The first fragment packet is composed of:

      (1)  The Per-Fragment headers of the original packet, with the
           Payload Length of the original IPv6 header changed to contain
           the length of this fragment packet only (excluding the length
           of the IPv6 header itself), and the Next Header field of the
           last header of the Per-Fragment headers changed to 44.

      (2)  A Fragment header containing:

              The Next Header value that identifies the first header
              after the Per-Fragment headers of the original packet.

              A Fragment Offset containing the offset of the fragment,
              in 8-octet units, relative to the start of the
              Fragmentable Part of the original packet.  The Fragment
              Offset of the first ("leftmost") fragment is 0.

              An M flag value of 1 as this is the first fragment.

              The Identification value generated for the original
              packet.

      (3)  Extension headers, if any, and the Upper-Layer header.  These
           headers must be in the first fragment.  Note: This restricts
           the size of the headers through the Upper-Layer header to the
           MTU of the path to the packet's destinations(s).

      (4)  The first fragment.

   The subsequent fragment packets are composed of:

      (1)  The Per-Fragment headers of the original packet, with the
           Payload Length of the original IPv6 header changed to contain
           the length of this fragment packet only (excluding the length
           of the IPv6 header itself), and the Next Header field of the
           last header of the Per-Fragment headers changed to 44.

      (2)  A Fragment header containing:

              The Next Header value that identifies the first header
              after the Per-Fragment headers of the original packet.

              A Fragment Offset containing the offset of the fragment,
              in 8-octet units, relative to the start of the
              Fragmentable Part of the original packet.

              An M flag value of 0 if the fragment is the last
              ("rightmost") one, else an M flag value of 1.

              The Identification value generated for the original
              packet.

      (3)  The fragment itself.

   Fragments must not be created that overlap with any other fragments
   created from the original packet.

   At the destination, fragment packets are reassembled into their
   original, unfragmented form, as illustrated:

   reassembled original packet:

   +---------------+-----------------+---------+--------+-//--+--------+
   | Per-Fragment  |Ext & Upper-Layer|  first  | second |     | last   |
   |    Headers    |     Headers     |frag data|fragment|.....|fragment|
   +---------------+-----------------+---------+--------+-//--+--------+

   The following rules govern reassembly:

      An original packet is reassembled only from fragment packets that
      have the same Source Address, Destination Address, and Fragment
      Identification.

      The Per-Fragment headers of the reassembled packet consists of all
      headers up to, but not including, the Fragment header of the first
      fragment packet (that is, the packet whose Fragment Offset is
      zero), with the following two changes:

         The Next Header field of the last header of the Per-Fragment
         headers is obtained from the Next Header field of the first
         fragment's Fragment header.

         The Payload Length of the reassembled packet is computed from
         the length of the Per-Fragment headers and the length and
         offset of the last fragment.  For example, a formula for
         computing the Payload Length of the reassembled original packet
         is:

            PL.orig = PL.first - FL.first - 8 + (8 * FO.last) + FL.last


            where
            PL.orig  =  Payload Length field of reassembled packet.
            PL.first =  Payload Length field of first fragment packet.
            FL.first =  length of fragment following Fragment header of
                        first fragment packet.
            FO.last  =  Fragment Offset field of Fragment header of last
                        fragment packet.
            FL.last  =  length of fragment following Fragment header of
                        last fragment packet.

         The Fragmentable Part of the reassembled packet is constructed
         from the fragments following the Fragment headers in each of
         the fragment packets.  The length of each fragment is computed
         by subtracting from the packet's Payload Length the length of
         the headers between the IPv6 header and fragment itself; its
         relative position in Fragmentable Part is computed from its
         Fragment Offset value.

         The Fragment header is not present in the final, reassembled
         packet.

         If the fragment is a whole datagram (that is, both the Fragment
         Offset field and the M flag are zero), then it does not need
         any further reassembly and should be processed as a fully
         reassembled packet (i.e., updating Next Header, adjust Payload
         Length, removing the Fragment header, etc.).  Any other
         fragments that match this packet (i.e., the same IPv6 Source
         Address, IPv6 Destination Address, and Fragment Identification)
         should be processed independently.

   The following error conditions may arise when reassembling fragmented
   packets:

      o  If insufficient fragments are received to complete reassembly
         of a packet within 60 seconds of the reception of the first-
         arriving fragment of that packet, reassembly of that packet
         must be abandoned and all the fragments that have been received
         for that packet must be discarded.  If the first fragment
         (i.e., the one with a Fragment Offset of zero) has been
         received, an ICMP Time Exceeded -- Fragment Reassembly Time
         Exceeded message should be sent to the source of that fragment.

      o  If the length of a fragment, as derived from the fragment
         packet's Payload Length field, is not a multiple of 8 octets
         and the M flag of that fragment is 1, then that fragment must
         be discarded and an ICMP Parameter Problem, Code 0, message
         should be sent to the source of the fragment, pointing to the
         Payload Length field of the fragment packet.

      o  If the length and offset of a fragment are such that the
         Payload Length of the packet reassembled from that fragment
         would exceed 65,535 octets, then that fragment must be
         discarded and an ICMP Parameter Problem, Code 0, message should
         be sent to the source of the fragment, pointing to the Fragment
         Offset field of the fragment packet.

      o  If the first fragment does not include all headers through an
         Upper-Layer header, then that fragment should be discarded and
         an ICMP Parameter Problem, Code 3, message should be sent to
         the source of the fragment, with the Pointer field set to zero.

      o  If any of the fragments being reassembled overlap with any
         other fragments being reassembled for the same packet,
         reassembly of that packet must be abandoned and all the
         fragments that have been received for that packet must be
         discarded, and no ICMP error messages should be sent.

         It should be noted that fragments may be duplicated in the
         network.  Instead of treating these exact duplicate fragments
         as overlapping fragments, an implementation may choose to
         detect this case and drop exact duplicate fragments while
         keeping the other fragments belonging to the same packet.

   The following conditions are not expected to occur frequently but are
   not considered errors if they do:

      The number and content of the headers preceding the Fragment
      header of different fragments of the same original packet may
      differ.  Whatever headers are present, preceding the Fragment
      header in each fragment packet, are processed when the packets
      arrive, prior to queueing the fragments for reassembly.  Only
      those headers in the Offset zero fragment packet are retained in
      the reassembled packet.

      The Next Header values in the Fragment headers of different
      fragments of the same original packet may differ.  Only the value
      from the Offset zero fragment packet is used for reassembly.

      Other fields in the IPv6 header may also vary across the fragments
      being reassembled.  Specifications that use these fields may
      provide additional instructions if the basic mechanism of using
      the values from the Offset zero fragment is not sufficient.  For
      example, Section 5.3 of [RFC3168] describes how to combine the
      Explicit Congestion Notification (ECN) bits from different
      fragments to derive the ECN bits of the reassembled packet.
      

It should say:

4.5.  Fragment Header

   The Fragment header is used by an IPv6 source to send a packet larger
   than would fit in the path MTU to its destination.  (Note: unlike
   IPv4, fragmentation in IPv6 is performed only by source nodes, not by
   routers along a packet's delivery path -- see [RFC8200].)  The
   Fragment header is identified by a Next Header value of 44 in the
   immediately preceding header and has the following format:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |   Reserved    |      Fragment Offset    |Res|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Identification                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Next Header         8-bit selector.  Identifies the initial header
                          type of the Fragmentable Part of the original
                          packet (defined below).  Uses the same values
                          as the IPv4 Protocol field [IANA-PN].

      Reserved            8-bit reserved field.  Initialized to zero for
                          transmission; ignored on reception.

      Fragment Offset     13-bit unsigned integer.  The offset, in
                          8-octet units, of the data following this
                          header, relative to the start of the
                          Fragmentable Part of the original packet.

      Res                 2-bit reserved field.  Initialized to zero for
                          transmission; ignored on reception.

      M flag              1 = more fragments; 0 = last fragment.

      Identification      32 bits.  See description below.

   In order to send a packet that is too large to fit in the MTU of the
   path to its destination, a source node may divide the packet into
   fragments and send each fragment as a separate packet, to be
   reassembled at the receiver.

   For every packet that is to be fragmented, the source node generates
   an Identification value.  The Identification must be different than
   that of any other fragmented packet sent recently* with the same
   Source Address and Destination Address.  If a Routing header is
   present, the Destination Address of concern is that of the final
   destination.

      *  "recently" means within the maximum likely lifetime of a
         packet, including transit time from source to destination and
         time spent awaiting reassembly with other fragments of the same
         packet.  However, it is not required that a source node knows
         the maximum packet lifetime.  Rather, it is assumed that the
         requirement can be met by implementing an algorithm that
         results in a low identification reuse frequency.  Examples of
         algorithms that can meet this requirement are described in
         [RFC7739].

   The initial, large, unfragmented packet is referred to as the
   "original packet", and it is considered to consist of two parts, as
   illustrated:

   original packet:

   +------------------+-----------------------------//----------------+
   |  Per-Fragment    |               Fragmentable                    |
   |    Headers       |                   Part                        |
   +------------------+-----------------------------//----------------+

      The Per-Fragment headers must consist of the IPv6 header plus any
      extension headers that must be processed by nodes en route to the
      destination, that is, all headers up to and including the Routing
      header if present, else the Hop-by-Hop Options header if present,
      else no extension headers.

      The Fragmentable Part consists of the rest of the packet, that is,
      any extension headers that need be processed only by the final
      destination node(s), plus the upper-layer header and data.

   The Fragmentable Part of the original packet is divided into
   fragments.  The lengths of the fragments must be chosen such that the
   resulting fragment packets fit within the MTU of the path to the
   packet's destination(s).  Each complete fragment, except possibly the
   last ("rightmost") one, is an integer multiple of 8 octets long.

   The fragments are transmitted in separate "fragment packets" as
   illustrated:

   original packet:

    +------------------+--------------+--------------+--//--+----------+
    |  Per-Fragment    |    first     |    second    |      |   last   |
    |   Headers        |   fragment   |   fragment   | .... | fragment |
    +------------------+--------------+--------------+--//--+----------+

   fragment packets:

   +------------------+--------+--------------+
   |  Per-Fragment    |Fragment|    first     |
   |    Headers       | Header |   fragment   |
   +------------------+--------+--------------+

   +------------------+--------+--------------+
   |  Per-Fragment    |Fragment|    second    |
   |    Headers       | Header |   fragment   |
   +------------------+--------+--------------+
                         o
                         o
                         o
   +------------------+--------+----------+
   |  Per-Fragment    |Fragment|   last   |
   |    Headers       | Header | fragment |
   +------------------+--------+----------+

   The first fragment packet is composed of:

      (1)  The Per-Fragment headers of the original packet, with the
           Payload Length of the original IPv6 header changed to contain
           the length of this fragment packet only (excluding the length
           of the IPv6 header itself), and the Next Header field of the
           last header of the Per-Fragment headers changed to 44.

      (2)  A Fragment header containing:

              The Next Header value that identifies the first header
              after the Per-Fragment headers of the original packet.

              A Fragment Offset containing the offset of the fragment,
              in 8-octet units, relative to the start of the
              Fragmentable Part of the original packet.  The Fragment
              Offset of the first ("leftmost") fragment is 0.

              An M flag value of 1 as this is the first fragment.

              The Identification value generated for the original
              packet.

      (3)  Extension headers, if any, and the Upper-Layer header.  These
           headers must be in the first fragment.  Note: This restricts
           the size of the headers through the Upper-Layer header to the
           MTU of the path to the packet's destinations(s).

           Extension headers are all other extension headers that are
           not included in the Per-Fragment headers part of the packet.
           For this purpose, the Encapsulating Security Payload (ESP) is
           not considered an extension header.  The Upper-Layer header
           is the first upper-layer header that is not an IPv6 extension
           header.  Examples of upper-layer headers include TCP, UDP,
           IPv4, IPv6, ICMPv6, and as noted ESP.

      (4)  The remainder of the first fragment.

   The subsequent fragment packets are composed of:

      (1)  The Per-Fragment headers of the original packet, with the
           Payload Length of the original IPv6 header changed to contain
           the length of this fragment packet only (excluding the length
           of the IPv6 header itself), and the Next Header field of the
           last header of the Per-Fragment headers changed to 44.

      (2)  A Fragment header containing:

              The Next Header value that identifies the first header
              after the Per-Fragment headers of the original packet.

              A Fragment Offset containing the offset of the fragment,
              in 8-octet units, relative to the start of the
              Fragmentable Part of the original packet.

              An M flag value of 0 if the fragment is the last
              ("rightmost") one, else an M flag value of 1.

              The Identification value generated for the original
              packet.

      (3)  The fragment itself.

   Fragments must not be created that overlap with any other fragments
   created from the original packet.

   At the destination, fragment packets are reassembled into their
   original, unfragmented form, as illustrated:

   reassembled original packet:

   +------------------+----------------------//------------------------+
   |  Per-Fragment    |                 Fragmentable                   |
   |    Headers       |                     Part                       |
   +------------------+----------------------//------------------------+

   The following rules govern reassembly:

      An original packet is reassembled only from fragment packets that
      have the same Source Address, Destination Address, and Fragment
      Identification.

      The Per-Fragment headers of the reassembled packet consists of all
      headers up to, but not including, the Fragment header of the first
      fragment packet (that is, the packet whose Fragment Offset is
      zero), with the following two changes:

         The Next Header field of the last header of the Per-Fragment
         headers is obtained from the Next Header field of the first
         fragment's Fragment header.

         The Payload Length of the reassembled packet is computed from
         the length of the Per-Fragment headers and the length and
         offset of the last fragment.  For example, a formula for
         computing the Payload Length of the reassembled original packet
         is:

            PL.orig = PL.first - FL.first - 8 + (8 * FO.last) + FL.last


            where
            PL.orig  =  Payload Length field of reassembled packet.
            PL.first =  Payload Length field of first fragment packet.
            FL.first =  length of fragment following Fragment header of
                        first fragment packet.
            FO.last  =  Fragment Offset field of Fragment header of last
                        fragment packet.
            FL.last  =  length of fragment following Fragment header of
                        last fragment packet.

         The Fragmentable Part of the reassembled packet is constructed
         from the fragments following the Fragment headers in each of
         the fragment packets.  The length of each fragment is computed
         by subtracting from the packet's Payload Length the length of
         the headers between the IPv6 header and fragment itself; its
         relative position in Fragmentable Part is computed from its
         Fragment Offset value.

         The Fragment header is not present in the final, reassembled
         packet.

         If the fragment is a whole datagram (that is, both the Fragment
         Offset field and the M flag are zero), then it does not need
         any further reassembly and should be processed as a fully
         reassembled packet (i.e., updating Next Header, adjust Payload
         Length, removing the Fragment header, etc.).  Any other
         fragments that match this packet (i.e., the same IPv6 Source
         Address, IPv6 Destination Address, and Fragment Identification)
         should be processed independently.

   The following error conditions may arise when reassembling fragmented
   packets:

      o  If insufficient fragments are received to complete reassembly
         of a packet within 60 seconds of the reception of the first-
         arriving fragment of that packet, reassembly of that packet
         must be abandoned and all the fragments that have been received
         for that packet must be discarded.  If the first fragment
         (i.e., the one with a Fragment Offset of zero) has been
         received, an ICMP Time Exceeded -- Fragment Reassembly Time
         Exceeded message should be sent to the source of that fragment.

      o  If the length of a fragment, as derived from the fragment
         packet's Payload Length field, is not a multiple of 8 octets
         and the M flag of that fragment is 1, then that fragment must
         be discarded and an ICMP Parameter Problem, Code 0, message
         should be sent to the source of the fragment, pointing to the
         Payload Length field of the fragment packet.

      o  If the length and offset of a fragment are such that the
         Payload Length of the packet reassembled from that fragment
         would exceed 65,535 octets, then that fragment must be
         discarded and an ICMP Parameter Problem, Code 0, message should
         be sent to the source of the fragment, pointing to the Fragment
         Offset field of the fragment packet.

      o  If the first fragment does not include all headers through an
         Upper-Layer header, then that fragment should be discarded and
         an ICMP Parameter Problem, Code 3, message should be sent to
         the source of the fragment, with the Pointer field set to zero.

      o  If any of the fragments being reassembled overlap with any
         other fragments being reassembled for the same packet,
         reassembly of that packet must be abandoned and all the
         fragments that have been received for that packet must be
         discarded, and no ICMP error messages should be sent.

         It should be noted that fragments may be duplicated in the
         network.  Instead of treating these exact duplicate fragments
         as overlapping fragments, an implementation may choose to
         detect this case and drop exact duplicate fragments while
         keeping the other fragments belonging to the same packet.

   The following conditions are not expected to occur frequently but are
   not considered errors if they do:

      The number and content of the headers preceding the Fragment
      header of different fragments of the same original packet may
      differ.  Whatever headers are present, preceding the Fragment
      header in each fragment packet, are processed when the packets
      arrive, prior to queueing the fragments for reassembly.  Only
      those headers in the Offset zero fragment packet are retained in
      the reassembled packet.

      The Next Header values in the Fragment headers of different
      fragments of the same original packet may differ.  Only the value
      from the Offset zero fragment packet is used for reassembly.

      Other fields in the IPv6 header may also vary across the fragments
      being reassembled.  Specifications that use these fields may
      provide additional instructions if the basic mechanism of using
      the values from the Offset zero fragment is not sufficient.  For
      example, Section 5.3 of [RFC3168] describes how to combine the
      Explicit Congestion Notification (ECN) bits from different
      fragments to derive the ECN bits of the reassembled packet.

Notes:

This errata replaces and resolves the issues raised in Errata 5170, 5171, 5172, 5173. Credit goes to Fernando Gont for reporting the issues raised in these errata. They correctly reported that the text in Section 4.5 of RFC8200 defined Fragment Offset as pointing to “Fragmentable Part”, this was an error and should have pointed to “Extension & Upper-Layer Headers”.

After review by the 6man working group the conclusion was to fix the issue in a more general way than what was proposed in Errata 5170, 5171, 5172, 5173, hence the need for a new errata.

Errata ID: 5256
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2018-02-06
Verifier Name: Suresh Krishnan
Date Verified: 2020-02-03

Section 4.8 says:

      Hdr Ext Len           8-bit unsigned integer.  Length of the
                            Destination Options header in 8-octet units,
                            not including the first 8 octets.

It should say:

      Hdr Ext Len           8-bit unsigned integer.  Length of the
                            extension header in 8-octet units,
                            not including the first 8 octets.

Notes:

Copy-paste error.

RFC 8214, "Virtual Private Wire Service Support in Ethernet VPN", August 2017

Source of RFC: bess (rtg)

Errata ID: 6743
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Adrian Farrel
Date Reported: 2021-11-19
Verifier Name: Andrew Alston
Date Verified: 2022-05-26

Section 4 says:

          Ethernet                                          Ethernet
          Native   |<--------- EVPN Instance ----------->|  Native
          Service  |                                     |  Service
          (AC)     |     |<-PSN1->|       |<-PSN2->|     |  (AC)
             |     V     V        V       V        V     V  |
             |     +-----+      +-----+  +-----+   +-----+  |
      +----+ |     | PE1 |======|ASBR1|==|ASBR2|===| PE3 |  |    +----+
      |    |-------+-----+      +-----+  +-----+   +-----+-------|    |
      | CE1| |                                              |    |CE2 |
      |    |-------+-----+      +-----+  +-----+   +-----+-------|    |
      +----+ |     | PE2 |======|ASBR3|==|ASBR4|===| PE4 |  |    +----+
           ^       +-----+      +-----+  +-----+   +-----+          ^
           |   Provider Edge 1        ^        Provider Edge 2      |
           |                          |                             |
           |                          |                             |
           |              EVPN Inter-provider point                 |
           |                                                        |
           |<---------------- Emulated Service -------------------->|

                   Figure 3: EVPN-VPWS Deployment Model

It should say:

          Ethernet                                          Ethernet
          Native   |<--------- EVPN Instance ----------->|  Native
          Service  |                                     |  Service
          (AC)     |     |<-PSN1->|       |<-PSN2->|     |  (AC)
             |     V     V        V       V        V     V  |
             |     +-----+      +-----+  +-----+   +-----+  |
      +----+ |     | PE1 |======|ASBR1|==|ASBR2|===| PE3 |  |    +----+
      |    |-------+-----+      +-----+  +-----+   +-----+-------|    |
      | CE1| |                                              |    |CE2 |
      |    |-------+-----+      +-----+  +-----+   +-----+-------|    |
      +----+ |     | PE2 |======|ASBR3|==|ASBR4|===| PE4 |  |    +----+
           ^       +-----+      +-----+  +-----+   +-----+       ^
           |   Provider Edge 1        ^        Provider Edge 2   |
           |                          |                          |
           |                          |                          |
           |              EVPN Inter-provider point              |
           |                                                     |
           |<---------------- Emulated Service ----------------->|

                   Figure 3: EVPN-VPWS Deployment Model

Notes:

The right-hand end of the Emulated Service should be aligned with the provider-facing AC port on CE2 and not placed in the middle of CE2.
Although this may appear to be a minor editorial issue, the technical consequences are significant.

RFC 8216, "HTTP Live Streaming", August 2017

Source of RFC: INDEPENDENT

Errata ID: 7283
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexander Batischev
Date Reported: 2022-12-22
Verifier Name: Eliot Lear (ISE)
Date Verified: 2023-01-04

Section 8.10 says:

   #EXTM3U
   ...
   #EXT-X-DATERANGE:ID="splice-6FFFFFF0",START-DATE="2014-03-05T11:
   15:00Z",PLANNED-DURATION=59.993,SCTE35-OUT=0xFC002F0000000000FF0
   00014056FFFFFF000E011622DCAFF000052636200000000000A0008029896F50
   000008700000000

   ... Media Segment declarations for 60s worth of media

   #EXT-X-DATERANGE:ID="splice-6FFFFFF0",DURATION=59.993,SCTE35-IN=
   0xFC002A0000000000FF00000F056FFFFFF000401162802E6100000000000A00
   08029896F50000008700000000
   ...

It should say:

   #EXTM3U
   ...
   #EXT-X-DATERANGE:ID="splice-6FFFFFF0",START-DATE="2014-03-05T11:
   15:00Z",PLANNED-DURATION=59.993,SCTE35-OUT=0xFC002F000000000000F
   F000014056FFFFFF000E081622DCAFF000052636200000000000A0008029896F
   50000008700000000

   ... Media Segment declarations for 60s worth of media

   #EXT-X-DATERANGE:ID="splice-6FFFFFF0",DURATION=59.993,SCTE35-IN=
   0xFC002A000000000000FF00000F056FFFFFF000408162802E6100000000000A
   0008029896F50000008700000000
   ...

Notes:

Both examples contain the same two mistakes. Let's look at the first example and find the first mistake:

1. 12 bits at offset 12 are section_length, and they equal 0x02F. This indicates that the rest of the section should take up 47 bytes, but actually there is only 46 bytes;
2. 12 bits at offset 92 are splice_command_length, and they equal 0x405. This indicates that there should be 1029 bytes after splice_command_type, which is clearly wrong since there are only 20 bytes there;
3. 8 bits at offset 104 are splice_command_type, and they equal 0x6F. This is not a valid command type. Since this is an SCTE35-IN tag, it's a splice_insert() event and we expect to see 0x05 in those bits. This conjecture is supported by the fact that 0x6F appears to be the first byte of the splice_event_id field.

It looks like a byte is missing somewhere between bit positions 24 and 92. In the corrected text, I took the liberty of inserting 0x00 at bit offset 24. This changes the section length to the declared 47 bytes; splice_command_length becomes 0x14 which is the expected 20 bytes; and splice_command_type becomes 0x05 which is the expected splice_insert() type. Accidentally this also changes pts_adjustment from 0xFF to 0x00; this shouldn't hurt because we don't know what PTSes the HLS segments contain, anyway.

With this fix applied, we can see the second mistake: the bit at offset 168 is time_specified_flag of the splice_time() contained within splice_insert(), and it's zero. This implies that there is no PTS inside splice_time(), which is clearly wrong, since the #EXT-X-DATERANGE displays the START-DATE. In the corrected text, I flipped this bit to 1. Again, without knowing the PTSes inside the segments, I can't tell if this gives us a correct pts_time, but at least the break_duration() now gives expected duration of 59.993 seconds.

The second example contains the same two mistakes, and the corrected text contains the same two fixes:

1. at bit offset 24, a new 0x00 byte is inserted;
2. at bit offset 168, zero bit is flipped to one.

Errata ID: 5158
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Daniel Tashjian
Date Reported: 2017-10-17
Verifier Name: Adrian Farrel
Date Verified: 2018-04-11

Section 4.3.4.1 says:

The value is a quoted-string that specifies an ordered, backslash-
separated ("/") list of parameters.

It should say:

The value is a quoted-string that specifies an ordered, forward slash-
separated ("/") list of parameters.

Notes:

Confirmed by authors that this is a forward slash.

Errata ID: 5263
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sebastian Hubbard
Date Reported: 2018-02-20
Verifier Name: Adrian Farrel
Date Verified: 2018-04-08

Section 12.2 says:

   [SampleEnc]
              Apple Inc., "MPEG-2 Stream Encryption Format for HTTP Live
              Streaming",
              <https://developer.apple.com/library/ios/documentation/
              AudioVideo/Conceptual/HLS_Sample_Encryption/>.

It should say:

   [SampleEnc]
              Apple Inc., "MPEG-2 Stream Encryption Format for HTTP Live
              Streaming",
              <https://developer.apple.com/library/content/
              documentation/AudioVideo/Conceptual/HLS_Sample_Encryption/
              Encryption/Encryption.html>.

Notes:

The [SampleEnc] reference is currently a broken link.

Errata ID: 6430
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ahmet Katranci
Date Reported: 2021-02-14
Verifier Name: Adrian Farrel
Date Verified: 2021-02-16

Section 11.2 says:

[M3U]      Nullsoft, Inc., "The M3U Playlist format, originally
           invented for the Winamp media player",
           <https://en.wikipedia.org/w/
           index.php?title=M3U7amp;oldid=786631666>.

It should say:

[M3U]      "M3U (MP3 URL)", <https://en.wikipedia.org/wiki/M3U>.

Notes:

The original reference is to an archived page, and the reference title includes subjective opinion about the reference.
The new reference is current, stable, and avoids opinion.

RFC 8228, "Guidance on Designing Label Generation Rulesets (LGRs) Supporting Variant Labels", August 2017

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 5670
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Asmus Freytag
Date Reported: 2019-03-23
Verifier Name: Alexey Melnikov
Date Verified: 2019-03-25

Section 13 says:

In this document, the symbol "r-n" means "a reflexive 
(identity) mapping of type 'n'".

It should say:

In this document, the symbol "r-k" means "a reflexive
(identity) mapping of type 'k'".

Notes:

The notation "r-n" is used a few lines later for "r-neither". Therefore, a different letter needs to be used for a generic placeholder for all types. "k" seems appropriate.

Errata ID: 5671
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Asmus Freytag
Date Reported: 2019-03-23
Verifier Name: Alexey Melnikov
Date Verified: 2019-03-25

Section 17 says:

The following shows such an example resulting in conflicting 
reflexive variants:

It should say:

The following shows such an example resulting in conflicting 
variant dispositions:

Notes:

typo

Errata ID: 6107
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Asmus Freytag
Date Reported: 2020-04-14
Verifier Name: Barry Leiba
Date Verified: 2020-04-14

Section 14 says:

Because no variant label with any code point outside the repertoire
   could ever be allocated, the only logical choice for the non-
   reflexive mappings to out-of-repertoire code points is "blocked".

It should say:

Because no variant label with any code point outside the repertoire
   would ever be allocated in this example, the only logical choice for the non-
   reflexive mappings to out-of-repertoire code points is "blocked".

Notes:

As written the sentence makes an absolute claim that isn't in accordance with RFC7940. While not usual, there are circumstances where allowing allocatable variants for a code point that has a reflexive "out-of-repertoire-var" mapping may make sense. Therefore, the statement needs to be read as restricted to the specific scenario or example under discussion.

RFC 8231, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", September 2017

Note: This RFC has been updated by RFC 8786, RFC 9353

Source of RFC: pce (rtg)

Errata ID: 5376
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Hari Krushna Kotni
Date Reported: 2018-06-01
Verifier Name: Deborah Brungard
Date Verified: 2018-06-05

Section 7.2 says:

In case of SRP-ID-number wrapping, the last
   SRP-ID-number before the wrapping MUST be explicitly acknowledged, to
   avoid a situation where SRP-ID-numbers remain unacknowledged after
   the wrap.  This means that the PCC may need to issue two PCUpd
   messages on detecting a wrap.

It should say:

In case of SRP-ID-number wrapping, the last
   SRP-ID-number before the wrapping MUST be explicitly acknowledged, to
   avoid a situation where SRP-ID-numbers remain unacknowledged after
   the wrap.  This means that the PCC may need to issue two PCRpt
   messages on detecting a wrap.

Notes:

incase of srp id wrap, once PCC detects it, PCC needs to issue PCRpt message not PCUpd message.

Errata ID: 5970
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Subham Burnwal
Date Reported: 2020-01-31
Verifier Name: Deborah Brungard
Date Verified: 2020-07-13

Section 8.5 says:

19       Invalid Operation

                Error-value
                1:   Attempted LSP Update Request for a non-delegated
                     LSP.  The PCEP-ERROR object is followed by the LSP
                     object that identifies the LSP.

It should say:

19       Invalid Operation

                Error-value
                1:   Attempted LSP Update Request for a non-delegated
                     LSP.

Notes:

RFC 8231 Section 6.3 - LSP Object is not part of PCErr message.

Errata ID: 6231
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Dhruv Dhody
Date Reported: 2020-07-13
Verifier Name: Deborah Brungard
Date Verified: 2020-09-29

Section 8.5 says:

      20       LSP State Synchronization Error

                Error-value
                1:   A PCE indicates to a PCC that it cannot process (an
                     otherwise valid) LSP State Report.  The PCEP-ERROR
                     object is followed by the LSP object that
                     identifies the LSP.

It should say:

      20       LSP State Synchronization Error

                Error-value
                1:   A PCE indicates to a PCC that it cannot process (an
                     otherwise valid) LSP State Report.  

Notes:

This is a companion errata to https://www.rfc-editor.org/errata/eid5970 which identified the issue in Error-type 19 Error-value 1. The same issue exists for Error-type 20 Error-value 1 i.e. LSP Object is not part of the PCErr message.

Errata ID: 6289
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Dhruv Dhody
Date Reported: 2020-09-14
Verifier Name: Deborah Brungard
Date Verified: 2020-09-29

Section 7.3.2 says:

   Length (16 bits): indicates the total length of the TLV in octets and
   MUST be greater than 0.  The TLV MUST be zero-padded so that the TLV
   is 4-octet aligned.

It should say:

   Length (16 bits): indicates the length of the value portion of the 
   TLV in octets and MUST be greater than 0.  The TLV MUST be zero-
   padded so that the TLV is 4-octet aligned.

Notes:

The "total length of the TLV" is incorrect, as in PCEP the TLV formatting is as per RFC 5440 which requires the length to be of the value portion only. The other text such as "MUST be greater than 0", the padding rules along with "without a NULL terminator" also point to the fact that the intention of the authors/WG was not "total" (and it is simply a mistake).

Errata ID: 5492
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Upendra Singh
Date Reported: 2018-09-05
Verifier Name: Deborah Brungard
Date Verified: 2019-02-11

Section 6.1 says:

Under section 6.1, PCRpt message is defined.
In definition of path,

    Where:
      <path>::= <intended-path>
                [<actual-attribute-list><actual-path>]
                <intended-attribute-list>

It should say:

Where:
      <path>::= <intended-path>
                [<actual-attribute-list><actual-path>]
                [<intended-attribute-list>]

Notes:

The change aligns the RBNF with the following text in the document (section 6.1) -

Note that the intended-attribute-list is optional and
thus may be omitted.

Errata ID: 6012
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dhruv Dhody
Date Reported: 2020-03-10
Verifier Name: Deborah Brungard
Date Verified: 2020-07-13

Section 5.8.3 says:

   If the PCC receives a PCUpd message for an LSP object
   identified with a PLSP-ID that does not exist on the PCC, it MUST
   generate a PCErr with Error-type=19 (Invalid Operation), error-value
   3, (Attempted LSP Update Request for an LSP identified by an unknown
   PSP-ID) (see Section 8.5).

It should say:

   If the PCC receives a PCUpd message for an LSP object
   identified with a PLSP-ID that does not exist on the PCC, it MUST
   generate a PCErr with Error-type=19 (Invalid Operation), error-value
   3, (Attempted LSP Update Request for an LSP identified by an unknown
   PLSP-ID) (see Section 8.5).

Notes:

s/PSP-ID/PLSP-ID/

Thanks to Rebecca Vanrheenen from RFC Editor team for spotting this while editing another I-D.

RFC 8235, "Schnorr Non-interactive Zero-Knowledge Proof", September 2017

Source of RFC: INDEPENDENT

Errata ID: 6353
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Feng Hao
Date Reported: 2020-12-10
Verifier Name: Adrian Farrel
Date Verified: 2021-06-01

Section 2.2 and 3.2 says:

-- b -> check 1) A is a valid public key
Information Flows in Schnorr Identification Scheme over Finite Field

-- b -> check 1) A is a valid public key
Information Flows in Schnorr Identification Scheme over Elliptic Curve

It should say:

-- r -> check 1) A is a valid public key
Information Flows in Schnorr Identification Scheme over Finite Field

-- r -> check 1) A is a valid public key
Information Flows in Schnorr Identification Scheme over Elliptic Curve

Notes:

In both diagrams, in the third flow, what Alice sends to Bob should be r (not b). This is a typo, which should be clear from the context of the rest diagram and the main body text. Christoph Egger first informed me of this typo.

RFC 8239, "Data Center Benchmarking Methodology", August 2017

Source of RFC: bmwg (ops)

Errata ID: 5652
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2019-03-12
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2019-09-06

Section 3.2 says:

      o  Last iteration: Ingress port N-2 sending line rate to egress
         port N-1, while port N is sending a known low amount of
         oversubscription traffic (1% recommended) with the same packet
         size to egress port N.  Measure the buffer size value by
         multiplying the number of extra frames sent by the frame size.

It should say:

      o  Last iteration: Ingress port N-2 sending line rate to egress
         port N-1, while port N is sending a known low amount of
         oversubscription traffic (1% recommended) with the same packet
         size to egress port N-1.  Measure the buffer size value by
         multiplying the number of extra frames sent by the frame size.

Notes:

Incorrect number of the output port for oversubscription traffic.

[WK]: See https://mailarchive.ietf.org/arch/msg/bmwg/_zZOrFmBwGq3dc5Pfb833tmLSGk for additional context.

RFC 8272, "TinyIPFIX for Smart Meters in Constrained Networks", November 2017

Source of RFC: INDEPENDENT

Errata ID: 5959
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Corinna Schmitt
Date Reported: 2020-01-20
Verifier Name: Adrian Farrel
Date Verified: 2020-01-26

Section 6.1 says:

Value = 15; look up extended SetID field, shifting enabled.

It should say:

Value = 15; look up extended SetID field, Shifting disabled.

Notes:

Typo error identified by RFC authors during new implementation in RIOT OS.

Errata ID: 5782
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Gernot Vormayr
Date Reported: 2019-07-15
Verifier Name: Adrian Farrel
Date Verified: 2019-07-17

Section 6.1 says:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |E|E| SetID |        Length     | Sequence      | Ext. Sequenz  |
    |1|2|Lookup |                   | Number        |  Number       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 9: TinyIPFIX Message Header Format if E1 = 0 and E2 = 1

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |1|1| SetID |        Length     | Sequence      | Ext. Sequenz  |
    | | |Lookup |                   | Number        |  Number       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Ext. SetID    |
    +-+-+-+-+-+-+-+-+

      Figure 10: TinyIPFIX Message Header Format if E1 = E2 = 1

It should say:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0|1| SetID |        Length     | Sequence      | Ext. Sequence |
    | | |Lookup |                   | Number        |  Number       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 9: TinyIPFIX Message Header Format if E1 = 0 and E2 = 1

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |1|1| SetID |        Length     | Sequence      | Ext. Sequence |
    | | |Lookup |                   | Number        |  Number       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Ext. SetID    |
    +-+-+-+-+-+-+-+-+

      Figure 10: TinyIPFIX Message Header Format if E1 = E2 = 1

Notes:

Figure 9: In Figures 7,8,10 E1 and E2 is replaced with the actual values (can be seen in Figure 10 in the submission; 1,1), while in Figure 9 this was missed (probably copy-paste-error): Is E1, E2; should be 0, 1

Figure 9 and Figure 10: In the rest of the RFC and all the other figures, the field is called "Ext. Sequence Number" and not "Ext. Sequenz Number" (Looks like a translation error).

RFC 8276, "File System Extended Attributes in NFSv4", December 2017

Source of RFC: nfsv4 (wit)

Errata ID: 7050
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Anton Rang
Date Reported: 2022-07-26
Verifier Name: RFC Editor
Date Verified: 2022-07-26

Section 1 says:

   This document discusses (in Section 5) the reasons that NFSv4-named
   attributes, as currently standardized in [RFC5661], are unsuitable
   for representing xattrs.  Instead, it describes a separate protocol

It should say:

   This document discusses (in Section 6) the reasons that NFSv4-named
   attributes, as currently standardized in [RFC5661], are unsuitable
   for representing xattrs.  Instead, it describes a separate protocol

Notes:

The reference to the discussion of named attributes has the wrong section number.

RFC 8281, "Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model", December 2017

Source of RFC: pce (rtg)

Errata ID: 6301
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Samuel Sidor
Date Reported: 2020-10-06
Verifier Name: Deborah Brungard
Date Verified: 2020-11-02

Section 5.1 says:

     <PCE-initiated-lsp-request> ::= (<PCE-initiated-lsp-instantiation>|
                                      <PCE-initiated-lsp-deletion>)

     <PCE-initiated-lsp-instantiation> ::= <SRP>
                                           <LSP>
                                           [<END-POINTS>]
                                           <ERO>
                                           [<attribute-list>]

     <PCE-initiated-lsp-deletion> ::= <SRP>
                                      <LSP>

It should say:

     <PCE-initiated-lsp-request> ::= (<PCE-initiated-lsp-instantiation>|
                                      <PCE-initiated-lsp-deletion-or-reclamation>)

     <PCE-initiated-lsp-instantiation> ::= <SRP>
                                           <LSP>
                                           [<END-POINTS>]
                                           <ERO>
                                           [<attribute-list>]

     <PCE-initiated-lsp-deletion-or-reclamation> ::= <SRP>
                                                     <LSP>

Notes:

Update needed to solve ambiguity for any extra object included after SRP and LSP objects in reclaim delegation request, which is coming from:

https://tools.ietf.org/html/rfc8281#section-6
A PCE (either the original or one of its backups) sends a PCInitiate
message that includes just the SRP and LSP objects and carries the
PLSP-ID of the LSP it wants to take control of.

RFC 8287, "Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes", December 2017

Note: This RFC has been updated by RFC 8690, RFC 9214

Source of RFC: mpls (rtg)

Errata ID: 6389
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: James Bensley
Date Reported: 2021-01-19
Verifier Name: Deborah Brungard
Date Verified: 2021-02-26

Section 5.2 says:

5.2.  IPv6 IGP-Prefix Segment ID

   The IPv6 IGP-Prefix Segment ID is defined in [SR].  The format is as
   specified below:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                         IPv6 Prefix                           |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Prefix Length  |    Protocol   |              Reserved         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv6 Prefix

      This field carries the IPv6 prefix to which the Segment ID is
      assigned.  In case of an Anycast Segment ID, this field will carry
      the IPv4 Anycast address.

It should say:

5.2.  IPv6 IGP-Prefix Segment ID

   The IPv6 IGP-Prefix Segment ID is defined in [SR].  The format is as
   specified below:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                         IPv6 Prefix                           |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Prefix Length  |    Protocol   |              Reserved         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv6 Prefix

      This field carries the IPv6 prefix to which the Segment ID is
      assigned.  In case of an Anycast Segment ID, this field will carry
      the IPv6 Anycast address.

Notes:

Copy-pasta reusing the IPv4 IGP-Prefix Segment ID description for the IPv6 IGP-Prefix Segment ID description, and in the case of an IPv6 Anycast Segment ID it states that an IPv4 prefix should be entered into the IPv6 Prefix field.

RFC 8288, "Web Linking", October 2017

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: art

Errata ID: 5878
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jinoh Kang
Date Reported: 2019-10-22
Verifier Name: Barry Leiba
Date Verified: 2019-10-24

Section B.2 says:

       15.  Let star_param_names be the set of param_names in the
            (param_name, param_value) tuples of link_parameters where
            the last character of param_name is an asterisk ("*").
       16.  For each star_param_name in star_param_names:
            1.  Let base_param_name be star_param_name with the last
                character removed.
            2.  If the implementation does not choose to support an
                internationalised form of a parameter named
                base_param_name for any reason (including, but not
                limited to, it being prohibited by the parameter's
                specification), remove all tuples from link_parameters
                whose first member is star_param_name, and skip to the
                next star_param_name.
            3.  Remove all tuples from link_parameters whose first
                member is base_param_name.
            4.  Change the first member of all tuples in link_parameters
                whose first member is star_param_name to
                base_param_name.

It should say:

       15.  Let star_param_names be the set of param_names in the
            (param_name, param_value) tuples of target_attributes where
            the last character of param_name is an asterisk ("*").
       16.  For each star_param_name in star_param_names:
            1.  Let base_param_name be star_param_name with the last
                character removed.
            2.  If the implementation does not choose to support an
                internationalised form of a parameter named
                base_param_name for any reason (including, but not
                limited to, it being prohibited by the parameter's
                specification), remove all tuples from target_attributes
                whose first member is star_param_name, and skip to the
                next star_param_name.
            3.  Remove all tuples from target_attributes whose first
                member is base_param_name.
            4.  Change the first member of all tuples in target_attributes
                whose first member is star_param_name to
                base_param_name.

Notes:

The modified link_parameters value is not used, but target_attributes is. Additionally, the normative part of the document states that the RFC 8187 decoding scheme MAY be used for target attributes (especially extension attributes), not the ones that belong to the general link model.

Errata ID: 5319
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jeffrey Yasskin
Date Reported: 2018-04-04
Verifier Name: Francesca Palombini
Date Verified: 2023-11-27

Section 1.1 says:

   This document uses the Augmented Backus-Naur Form (ABNF) [RFC5234]
   notation of [RFC7230], including the #rule, and explicitly includes
   the following rules from it: quoted-string, token, SP (space), BWS
   (bad whitespace), OWS (optional whitespace), RWS (required
   whitespace), LOALPHA, DIGIT.

It should say:

   This document uses the Augmented Backus-Naur Form (ABNF) [RFC5234]
   notation of [RFC7230], including the #rule, and explicitly includes
   the following rules from it: quoted-string, token, SP (space), BWS
   (bad whitespace), OWS (optional whitespace), RWS (required
   whitespace), DIGIT. It also uses the following additional rule:

   LOALPHA = %x61-7A

   

Notes:

I can't find a definition of LOALPHA in RFC5234 or RFC7230. I see a definition in RFC2616, which seems to have been dropped in the update.

RFC 8300, "Network Service Header (NSH)", January 2018

Note: This RFC has been updated by RFC 9451

Source of RFC: sfc (rtg)

Errata ID: 5939
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alissa Cooper
Date Reported: 2019-12-18
Verifier Name: RFC Editor
Date Verified: 2019-12-19

Section 8.2.1 says:

Given that NSH is transport independent, as mentioned above, 
a secure transport, such as IPsec can be used for carry NSH.

It should say:

Given that NSH is transport independent, as mentioned above, 
a secure transport, such as IPsec, can be used for carrying NSH.

Notes:

Grammar issue: "carry" should be "carrying".

RFC 8306, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths", November 2017

Note: This RFC has been updated by RFC 9353

Source of RFC: pce (rtg)

Errata ID: 5622
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Adrian FARREL
Date Reported: 2019-02-04
Verifier Name: Deborah Brungard
Date Verified: 2019-02-04

Section 3.13 says:

   The total PCEP message length, including the common header, is
   16 bytes.

It should say:

   The total PCEP message length, including the common header, is
   (2^16)-1 bytes.

Notes:

The message length field is 16 bits, so the maximum message length is (2^16)-1.

RFC 8311, "Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation", January 2018

Source of RFC: tsvwg (wit)

Errata ID: 5399
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: David Black
Date Reported: 2018-06-19
Verifier Name: Spencer Dawkins
Date Verified: 2018-11-16

Section 7 says:

(n/a, this errata adds an additional IANA Consideration)

It should say:

To reflect the experimental use of ECT(1) envisioned by this memo,
IANA has added the following footnote to the ECN Field registry
<https://www.iana.org/assignments/dscp-registry/
dscp-registry.xhtml#ecn-field>:

ECT(1) is for experimental use only [RFC8311, Section 4.2]

Notes:

The Corrected Text is written as if IANA has already added the footnote, which will be done upon approval of this errata, citing this approved errata as justification.

(From Spencer - this could have been Held for Document Update, but I think Verified is just about as correct)

Errata ID: 5649
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bob Briscoe
Date Reported: 2019-03-10
Verifier Name: Mirja Kühlewind
Date Verified: 2019-03-11

Section 3. says:

see Appendix B.1 of [ECN-L4S].

It should say:

see Appendix C.1 of [ECN-L4S].

Notes:

At the end of Section 8. there is another reference to the same information in the same Appendix:

See Appendix C.1 of [ECN-L4S] for discussion of alternatives to the
ECN nonce.

So we have to change one to be consistent with the other. Let's use C.1, because that is the current number of the appendix in the relevant draft.

RFC 8324, "DNS Privacy, Authorization, Special Uses, Encoding, Characters, Matching, and Root Structure: Time for Another Look?", February 2018

Source of RFC: INDEPENDENT

Errata ID: 5268
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tim Chown
Date Reported: 2018-02-28
Verifier Name: Adrian Farrel
Date Verified: 2018-03-10

Section 3.1 says:

"The current
   case where this problem rears its head involves attempts at solutions
   that return both TYPE A (IPv4) and type AAA (IPv6) addresses
   collectively. "

It should say:

"The current
   case where this problem rears its head involves attempts at solutions
   that return both TYPE A (IPv4) and type AAAA (IPv6) addresses
   collectively. "

Notes:

Simple typo.

RFC 8325, "Mapping Diffserv to IEEE 802.11", February 2018

Note: This RFC has been updated by RFC 8622

Source of RFC: tsvwg (wit)

Errata ID: 7588
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Stephen [kiwin] PALM
Date Reported: 2023-08-02
Verifier Name: Martin Duke
Date Verified: 2024-01-18

Section 2.3 says:

There are mappings provided in [IEEE.802.11-2016], Annex V Tables V-1 and V2,

It should say:

There are mappings provided in [IEEE.802.11-2016], Annex R Tables R-1 and R-2,

Notes:

It is Annex R in both the 2016 and 2020 editions

RFC 8326, "Graceful BGP Session Shutdown", March 2018

Source of RFC: grow (ops)

Errata ID: 5402
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Scudder
Date Reported: 2018-06-21
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2018-07-30

Section C.2.2. says:

      4.  If, for any reason, RR3 processes the withdraw generated in
          step 3 before processing the update generated in step 2, RR3
          transiently suffers from unreachability for the affected
          prefix.

It should say:

      4.  If, for any reason, RR2 processes the withdraw generated in
          step 3 before processing the update generated in step 2, RR2
          transiently suffers from unreachability for the affected
          prefix.

Notes:

The original text names RR3, but it should be RR2. This becomes evident when one works through the example using a diagram.

RFC 8327, "Mitigating the Negative Impact of Maintenance through BGP Session Culling", March 2018

Source of RFC: grow (ops)

Errata ID: 5280
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Job Snijders
Date Reported: 2018-03-07
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2018-03-07

Section 1 says:

BGP Session Culling is the practice of ensuring BGP sessions are
forcefully torn down before maintenance activities on a lower-layer
network commence -- activities that otherwise would affect the flow
of data between the BGP speakers.  BGP Session Culling is the
practice of ensuring BGP sessions are forcefully torn down before
commencing maintenance activities (that otherwise would affect the
flow of data between the BGP speakers) on a lower-layer network.

It should say:

BGP Session Culling is the practice of ensuring BGP sessions are
forcefully torn down before maintenance activities on a lower-layer
network commence -- activities that otherwise would affect the flow
of data between the BGP speakers.

Notes:

The original version of a corrected sentence was left in the document in the editing phase

RFC 8331, "RTP Payload for Society of Motion Picture and Television Engineers (SMPTE) ST 291-1 Ancillary Data", February 2018

Source of RFC: payload (art)

Errata ID: 5310
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Anthony Malizia
Date Reported: 2018-03-28
Verifier Name: Ben Campbell
Date Verified: 2018-03-29

Section 2, Figure 1 says:

Data_Count=0x84

Data_Count=0x105

It should say:

Data_Count=0x104

Data_Count=0x205

Notes:

In the example described in section 2, the first ANC packet is said to have 4 User_Data_Words, and the second packet is said to have 5 User_Data_Words. The values in Figure 1 for the Data_Count fields do not have the correct parity bits according to the definition of Data_Count described in section 2.1.

4 = 0b0000'0100, with parity bits 0b01'0000'0100 = 0x104

5 = 0b0000'0101, with parity bits 0b10'0000'0101 = 0x205

RFC 8336, "The ORIGIN HTTP/2 Frame", March 2018

Source of RFC: httpbis (wit)

Errata ID: 5378
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lucas Pardue
Date Reported: 2018-06-04
Verifier Name: Alexey Melnikov
Date Verified: 2018-06-10

Section 2.1 says:

   +-------------------------------+-------------------------------+
   |         Origin-Len (16)       | ASCII-Origin?               ...
   +-------------------------------+-------------------------------+

   Specifically:

   Origin-Len:  An unsigned, 16-bit integer indicating the length, in
      octets, of the ASCII-Origin field.

   Origin:  An OPTIONAL sequence of characters containing the ASCII
      serialization of an origin ([RFC6454], Section 6.2) that the
      sender asserts this connection is or could be authoritative for.

It should say:

   +-------------------------------+-------------------------------+
   |         Origin-Len (16)       | ASCII-Origin?               ...
   +-------------------------------+-------------------------------+

   Specifically:

   Origin-Len:  An unsigned, 16-bit integer indicating the length, in
      octets, of the ASCII-Origin field.

   ASCII-Origin:  An OPTIONAL sequence of characters containing the
   ^^^^^^
      ASCII serialization of an origin ([RFC6454], Section 6.2) that the
      sender asserts this connection is or could be authoritative for.

Notes:

The term used in the description of the Frame fields is inconsistent with the figure. I.E. the figure uses "ASCII-Origin" while the text uses "Origin". ASCII-Origin is used elsewhere in the document.

RFC 8342, "Network Management Datastore Architecture (NMDA)", March 2018

Source of RFC: netmod (ops)

Errata ID: 5362
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rohit R Ranade
Date Reported: 2018-05-17
Verifier Name: Ignas Bagdonas
Date Verified: 2018-05-21

Section 2 says:

The convention adopted by the interfaces
   data model [RFC8343] and the IP data model [RFC8344] was to use two
   separate branches rooted at the root of the data tree: one branch for
   configuration data objects and one branch for operational state data
   objects.

It should say:

The convention adopted by the interfaces
   data model [RFC7223] and the IP data model [RFC7277] was to use two
   separate branches rooted at the root of the data tree: one branch for
   configuration data objects and one branch for operational state data
   objects.

Notes:

The duplication of definition and separation of operational state data and configuration data happened in RFC7223 and RFC7277. RFC8343 and RFC8344 have corrected this using NMDA architecture.

The Informative References section should point to RFCs 7223 and 7277.

RFC 8345, "A YANG Data Model for Network Topologies", March 2018

Source of RFC: i2rs (rtg)

Errata ID: 6900
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mohamed Boucadair
Date Reported: 2022-03-29
Verifier Name: Alvaro Retana
Date Verified: 2022-06-22

Section Appendix C says:

"network-id": "otn-hc",

It should say:

"network-id": "foo:otn-hc",

Notes:

This is to match the network-id type:

typedef network-id {
type inet:uri;
description
"Identifier for a network. The precise structure of the
network-id will be up to the implementation. The identifier
SHOULD be chosen such that the same network will always be
identified through the same identifier, even if the data model
is instantiated in separate datastores. An implementation MAY
choose to capture semantics in the identifier -- for example,
to indicate the type of network.";
}

RFC 8360, "Resource Public Key Infrastructure (RPKI) Validation Reconsidered", April 2018

Source of RFC: sidr (rtg)

Errata ID: 5638
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alberto Leiva Popper
Date Reported: 2019-02-13
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2019-02-13

Section 4.2.4.4 says:

   7.  Compute the VRS-IP and VRS-AS set values as indicated below:

       *  If the IP Address Delegation extension is present in
          certificate x and x=1, set the VRS-IP to the resources found
          in this extension.

       *  If the IP Address Delegation extension (...)

       *  If the IP Address Delegation extension (...)

       *  If the IP Address Delegation extension is present in
          certificate x and x=1, set the VRS-IP to the resources found
          in this extension.

       *  If the AS Identifier Delegation extension (...)

       *  If the AS Identifier Delegation extension (...)

It should say:

   7.  Compute the VRS-IP and VRS-AS set values as indicated below:

       *  If the IP Address Delegation extension is present in
          certificate x and x=1, set the VRS-IP to the resources found
          in this extension.

       *  If the IP Address Delegation extension (...)

       *  If the IP Address Delegation extension (...)

       *  If the AS Identifier Delegation extension is present in
          certificate x and x=1, set the VRS-AS to the resources found
          in this extension.

       *  If the AS Identifier Delegation extension (...)

       *  If the AS Identifier Delegation extension (...)

Notes:

There seems to be a copy-paste error.

There are two bullet points explaining the initialization of VRS-IP, and none explaining the initialization of VRS-AS.

All the evidence suggests that the two extensions (IP Address Delegation and AS Identifier Delegation) are meant to be handled similarly, so I believe that the last three bullet points are supposed to perfectly mirror the first three.

Errata ID: 5870
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2019-10-04
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2019-10-08

Section 4.2.3 says:

       ext-pe-autonomousSysIds-v2 EXTENSION ::= {
         SYNTAX ASIdentifiers
         IDENTIFIED BY id-pe-autonomousSysIds-v2
       }

       id-pe-autonomousSysIds OBJECT IDENTIFIER ::= { id-pe 29 }

It should say:

       ext-pe-autonomousSysIds-v2 EXTENSION ::= {
         SYNTAX ASIdentifiers
         IDENTIFIED BY id-pe-autonomousSysIds-v2
       }

       id-pe-autonomousSysIds-v2 OBJECT IDENTIFIER ::= { id-pe 29 }

Notes:

The "-v2" is missing from the identifier. It is needed for the ASN.1 module to compile properly.

RFC 8366, "A Voucher Artifact for Bootstrapping Protocols", May 2018

Source of RFC: anima (ops)

Errata ID: 6646
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Aman Mangal
Date Reported: 2021-07-22
Verifier Name: Rob Wilton
Date Verified: 2024-01-15

Section 5.2 says:

   {
     "ietf-voucher:voucher": {
       "created-on": "2016-10-07T19:31:42Z",
       "expires-on": "2016-10-21T19:31:42Z",
       "assertion": "verified",
       "serial-number": "JADA123456789",
       "idevid-issuer": "base64encodedvalue==",
       "pinned-domain-cert": "base64encodedvalue==",
       "domain-cert-revocation-checks": "true",
       "last-renewal-date": "2017-10-07T19:31:42Z"
     }
   }

It should say:

   {
     "ietf-voucher:voucher": {
       "created-on": "2016-10-07T19:31:42Z",
       "expires-on": "2016-10-21T19:31:42Z",
       "assertion": "verified",
       "serial-number": "JADA123456789",
       "idevid-issuer": "base64encodedvalue==",
       "pinned-domain-cert": "base64encodedvalue==",
       "domain-cert-revocation-checks": true,
       "last-renewal-date": "2017-10-07T19:31:42Z"
     }
   }

Notes:

domain-cert-revocation-checks is defined as boolean in the YANG specification in section 5.3 of the same RFC 8366. Boolean value in JSON are represented using true/false without the quotes.

Errata ID: 7289
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2022-12-26
Verifier Name: RFC Editor
Date Verified: 2023-01-06

Section 1 says:

   This document only defines the voucher artifact, leaving it to other
   documents to describe specialized protocols for accessing it.  Some
   bootstrapping protocols using the voucher artifact defined in this
   document include: [ZERO-TOUCH], [SECUREJOIN], and [KEYINFRA]).

It should say:

   This document only defines the voucher artifact, leaving it to other
   documents to describe specialized protocols for accessing it.  Some
   bootstrapping protocols using the voucher artifact defined in this
   document include: [ZERO-TOUCH], [SECUREJOIN], and [KEYINFRA].

Notes:

Unnecessary parenthesis at the end.

RFC 8373, "Negotiating Human Language in Real-Time Communications", May 2018

Note: This RFC has been updated by RFC 8865

Source of RFC: slim (art)

Errata ID: 5374
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Dan Chiba
Date Reported: 2018-05-31
Verifier Name: Alexey Melnikov
Date Verified: 2018-06-10

Section 5.4. says:

   An offer or answer indicating written Greek both ways:

      m=text 45020 RTP/AVP 103 104
      a=hlang-send:gr
      a=hlang-recv:gr

It should say:

   An offer or answer indicating written Greek both ways:

      m=text 45020 RTP/AVP 103 104
      a=hlang-send:el
      a=hlang-recv:el

Notes:

The language tag to represent Greek is "el" per BCP 47.

The IANA language subtag registry has the following entry for Greek:

Type: language
Subtag: el
Description: Modern Greek (1453-)
Added: 2005-10-16

https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry

Errata ID: 5387
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Dan Chiba
Date Reported: 2018-05-31
Verifier Name: Alexey Melnikov
Date Verified: 2018-06-10

Section 5.4. says:

      m=text 45020 RTP/AVP 103 104
      a=hlang-send:sp pt

      m=audio 49250 RTP/AVP 20
      a=hlang-recv:sp pt

   An answer for the above offer, indicating text in which the callee
   will receive written Spanish and audio in which the callee will send
   spoken Spanish.  (The answering party has no video capability):

      m=video 0 RTP/AVP 31 32
      m=text 45020 RTP/AVP 103 104
      a=hlang-recv:sp

      m=audio 49250 RTP/AVP 20
      a=hlang-send:sp

and later on the same page:

   An answer for the above offer, indicating text in which the callee
   will receive written Spanish, audio in which the callee will send
   spoken Spanish, and supplemental video:

      m=text 45020 RTP/AVP 103 104
      a=hlang-recv:sp

      m=audio 49250 RTP/AVP 20
      a=hlang-send:sp

      m=video 51372 RTP/AVP 31 32

It should say:

      m=text 45020 RTP/AVP 103 104
      a=hlang-send:es pt

      m=audio 49250 RTP/AVP 20
      a=hlang-recv:es pt

   An answer for the above offer, indicating text in which the callee
   will receive written Spanish and audio in which the callee will send
   spoken Spanish.  (The answering party has no video capability):

      m=video 0 RTP/AVP 31 32
      m=text 45020 RTP/AVP 103 104
      a=hlang-recv:es

      m=audio 49250 RTP/AVP 20
      a=hlang-send:es

and later on the same page:

   An answer for the above offer, indicating text in which the callee
   will receive written Spanish, audio in which the callee will send
   spoken Spanish, and supplemental video:

      m=text 45020 RTP/AVP 103 104
      a=hlang-recv:es

      m=audio 49250 RTP/AVP 20
      a=hlang-send:es

      m=video 51372 RTP/AVP 31 32

Notes:

The language tag to represent Spanish is "es" per BCP 47.

The IANA language subtag registry has the following entry for Spanish:

Type: language
Subtag: es
Description: Spanish
Description: Castilian
Added: 2005-10-16

https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry

RFC 8391, "XMSS: eXtended Merkle Signature Scheme", May 2018

Source of RFC: IRTF

Errata ID: 5572
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Franziskus Kiefer
Date Reported: 2018-12-10
Verifier Name: Colin Perkins
Date Verified: 2019-04-09

Section 4.1.5 says:

Input: WOTS+ public key pk, address ADRS, seed SEED

It should say:

Input: WOTS+ public key pk, seed SEED, address ADRS

Notes:

ltree is called twice as ltree(pk, seed, adr).

Errata ID: 5573
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Franziskus Kiefer
Date Reported: 2018-12-10
Verifier Name: Colin Perkins
Date Verified: 2019-04-09

Section 4.1.6 says:

Output: n-byte root node - top node on Stack

It should say:

Output: n-byte root node - top node on Stack or -1

Notes:

The algorithm can fail and might return -1 instead of a root node

Errata ID: 6024
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Andreas Hülsing
Date Reported: 2020-03-18
Verifier Name: Colin Perkins
Date Verified: 2020-06-23

Section 5 says:

This section provides basic parameter sets that are assumed to cover most relevant applications.  Parameter sets for two classical security levels are defined.  Parameters with n = 32 provide a classical security level of 256 bits.  Parameters with n = 64 provide a classical security level of 512 bits.  Considering quantum-computer-aided attacks, these output sizes yield post-quantum security of 128 and 256 bits, respectively.

It should say:

This section provides basic parameter sets that are assumed to cover most relevant applications. Parameter sets for two classical security levels are defined using the cryptographic functions SHA2 and SHAKE.  Parameters with SHA2 and n = 32 provide a classical security level of 256 bits. Parameters with SHA2 and n = 64 provide a classical security level of 512 bits.  Considering quantum-computer-aided attacks, these parameters yield post-quantum security of 128 and 256 bits, respectively. Parameters with SHAKE and n = 32 provide a classical security level of 128 bits.  Parameters with SHAKE and n = 64 provide a classical security level of 256 bits.  Considering quantum-computer-aided attacks, these parameters yield post-quantum security of 86 and 170 bits, respectively. 

Notes:

Traditionally, a hash function with n-bit outputs is assumed to have n-bit security against classical preimage and second-preimage attacks, and n/2-bit security against classical collision attacks. For adversaries with access to a quantum computer, these bounds change to n/2 and n/3 bits when only counting queries to the hash function. This also applies to SHA2 and SHA3. In contrast, SHAKE follows a different reasoning. SHAKE with an internal state of n bits and an output length of n bits achieves n/2 bit security against classical preimage, second-preimage and collision attacks. For quantum attacks security changes to n/3 bits. The reason is that SHAKE allows for meet-in-the-middle preimage attacks that reduce to a collision search on the internal state.

In consequence, SHAKE-128 cannot provide more security than NIST post-quantum security level II.

(Errata submitted by Andreas Hülsing; notes slightly revised after Crypto Forum review by Scott Fluhrer; verified by CFRG Chairs and IRTF Chair)

Errata ID: 7412
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Rafael Misoczki
Date Reported: 2023-04-02
Verifier Name: Colin Perkins
Date Verified: 2023-04-10

Section 2.6 (Algorithm 1) says:

bits += 8;

It should say:

bits = 8;

Notes:

"bits += 8;" is misleading and results in one useless addition.

This is true because this instruction appears after the program ensured that "bits == 0".

Therefore, "bits = 8;" is the actual instruction that should be executed here.

RFC 8400, "Extensions to RSVP-TE for Label Switched Path (LSP) Egress Protection", June 2018

Source of RFC: teas (rtg)

Errata ID: 5400
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Martin Thomson
Date Reported: 2018-06-21
Verifier Name: Deborah Brungard
Date Verified: 2018-06-29

Section 8 says:

IETF Review [8216]

It should say:

IETF Review [8126]

Notes:

This looks like a simple typo. RFC 8216 is "HTTP Live Streaming"; the intent seems to be "Guidelines for Writing an IANA Considerations Section in RFCs".

RFC 8402, "Segment Routing Architecture", July 2018

Note: This RFC has been updated by RFC 9256

Source of RFC: spring (rtg)

Errata ID: 7671
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alvaro Retana
Date Reported: 2023-10-09
Verifier Name: James N Guichard
Date Verified: 2023-10-09

Section 4.1 says:

   A likely use case for the BGP-Prefix segment is an IGP-free hyper-
   scale spine-leaf topology where connectivity is learned solely via
   BGP [RFC7938]

It should say:

   A likely use case for the BGP-Prefix segment is an IGP-free hyper-
   scale spine-leaf topology where connectivity is learned solely via
   BGP [RFC7938].

Notes:

The period is missing at the end of the sentence.

RFC 8407, "Guidelines for Authors and Reviewers of Documents Containing YANG Data Models", October 2018

Note: This RFC has been updated by RFC 8819

Source of RFC: netmod (ops)

Errata ID: 5693
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mobashshera Rasool
Date Reported: 2019-04-15
Verifier Name: Ignas Bagdonas
Date Verified: 2019-04-30

Section 4.17 says:

Note that the set of features within a module
   is easily discovered by the reader, but the set of related modules
   within the entire YANG library is not as easy to identity.  Module
   names with a common prefix can help readers identity the set of
   related modules, but this assumes the reader will have discovered and
   installed all the relevant modules.

It should say:

Note that the set of features within a module
   is easily discovered by the reader, but the set of related modules
   within the entire YANG library is not as easy to identify.  Module
   names with a common prefix can help readers identify the set of
   related modules, but this assumes the reader will have discovered and
   installed all the relevant modules.

Notes:

The word identity is not correct here. It should be identify to give the sentence correct meaning.

Errata ID: 5800
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: tom Petch
Date Reported: 2019-07-31
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2019-09-06

Section appendix b says:

       "WG Web:   <http://datatracker.ietf.org/wg/your-wg-name/>
.....
        (http://trustee.ietf.org/license-info).

It should say:

       "WG Web:   <https://datatracker.ietf.org/wg/your-wg-name/>
.....
        (https://trustee.ietf.org/license-info).

Notes:

Appendix A rightly says that these URL should have a scheme of https:
but Appendix B wrongly specifies http:

[WK]: I'm marking this as 'Verified' (instead of "Hold for Document Update") as it is in a template which is likely to be copied and pasted, and this seems like it may get more visibility.

Errata ID: 6899
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mohamed Boucadair
Date Reported: 2022-03-29
Verifier Name: RFC Editor
Date Verified: 2022-04-06

Section Appendix A says:

   o  License -- verify that the document contains the Simplified BSD
      License in each YANG module or submodule.  Some guidelines related
      to this requirement are described in Section 3.1.  Make sure that
      the correct year is used in all copyright dates.  Use the approved
      text from the latest TLP document, which can be found at:

It should say:

   o  License -- verify that the document contains the Revised BSD
      License in each YANG module or submodule.  Some guidelines related
      to this requirement are described in Section 3.1.  Make sure that
      the correct year is used in all copyright dates.  Use the approved
      text from the latest TLP document, which can be found at:

Notes:

https://trustee.ietf.org/documents/trust-legal-provisions/tlp-5/ says:

==
Note: in prior versions of these provisions, the software license was erroneously called the “Simplified BSD License” rather than the “Revised BSD License”, and many documents that refer to these provisions copied the erroneous name. The IETF Trust corrected the error on September 21, 2021. The license text itself was always that of the Revised BSD License and has not changed.
==
--VERIFIER NOTES--
Verified per discussion with John Levine and individuals in the netmod WG. “Simplified” is what was used when RFC 8407 was published. However, this RFC is providing guidance for authors and reviewers of future documents.

RFC 8410, "Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure", August 2018

Note: This RFC has been updated by RFC 9295

Source of RFC: curdle (sec)

Errata ID: 7384
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2023-03-12
Verifier Name: Deb Cooley
Date Verified: 2024-04-11

Section 9 says:

    sa-Ed25519 SIGNATURE-ALGORITHM ::= {
       IDENTIFIER id-Ed25519
        PARAMS ARE absent
        PUBLIC-KEYS {pk-Ed25519}
        SMIME-CAPS { IDENTIFIED BY id-Ed25519 }
    }

    pk-Ed25519 PUBLIC-KEY ::= {
        IDENTIFIER id-Ed25519
        -- KEY no ASN.1 wrapping --
        PARAMS ARE absent
        CERT-KEY-USAGE {digitalSignature, nonRepudiation,
                        keyCertSign, cRLSign}
        PRIVATE-KEY CurvePrivateKey
    }

It should say:

    sa-Ed25519 SIGNATURE-ALGORITHM ::= {
       IDENTIFIER id-Ed25519
        PARAMS ARE absent
        PUBLIC-KEYS {pk-Ed25519}
        SMIME-CAPS { IDENTIFIED BY id-Ed25519 }
    }

    pk-Ed25519 PUBLIC-KEY ::= {
        IDENTIFIER id-Ed25519
        -- KEY no ASN.1 wrapping --
        PARAMS ARE absent
        CERT-KEY-USAGE {digitalSignature, nonRepudiation,
                        keyCertSign, cRLSign}
        PRIVATE-KEY CurvePrivateKey
    }

   sa-Ed448 SIGNATURE-ALGORITHM ::= {
      IDENTIFIER id-Ed448
       PARAMS ARE absent
       PUBLIC-KEYS {pk-Ed448}
       SMIME-CAPS { IDENTIFIED BY id-Ed448 }
   }

   pk-Ed448 PUBLIC-KEY ::= {
       IDENTIFIER id-Ed448
       -- KEY no ASN.1 wrapping --
       PARAMS ARE absent
       CERT-KEY-USAGE {digitalSignature, nonRepudiation,
                       keyCertSign, cRLSign}
       PRIVATE-KEY CurvePrivateKey
   }

Notes:

The definitions for sa-Ed448 and pk-Ed448 are missing from RFC 8410.

Errata ID: 6738
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Daniel Minder
Date Reported: 2021-11-16
Verifier Name: Benjamin Kaduk
Date Verified: 2021-12-03

Section 7 says:

   OneAsymmetricKey ::= SEQUENCE {
      version Version,
      privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,
      privateKey PrivateKey,
      attributes [0] IMPLICIT Attributes OPTIONAL,
      ...,
      [[2: publicKey [1] IMPLICIT PublicKey OPTIONAL ]],
      ...
   }

It should say:

   OneAsymmetricKey ::= SEQUENCE {
      version Version,
      privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,
      privateKey PrivateKey,
      attributes [0] Attributes OPTIONAL,
      ...,
      [[2: publicKey [1] PublicKey OPTIONAL ]],
      ...
   }

Notes:

This is an incorrect quote from RFC 5958.

RFC 8415, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", November 2018

Source of RFC: dhc (int)

Errata ID: 6183
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Fernando Gont
Date Reported: 2020-05-19
Verifier Name: Erik Kline
Date Verified: 2020-05-21

Section 18.3.8 says:

   After all the addresses have been processed, the server generates a
   Reply message by setting the "msg-type" field to REPLY and copying
   the transaction ID from the Decline message into the "transaction-id"
   field.  The client includes a Status Code option (see Section 21.13)
   with the value Success, a Server Identifier option (see Section 21.3)
   with the server's DUID, and a Client Identifier option (see
   Section 21.2) with the client's DUID

It should say:

   After all the addresses have been processed, the server generates a
   Reply message by setting the "msg-type" field to REPLY and copying
   the transaction ID from the Decline message into the "transaction-id"
   field.  The server includes a Status Code option (see Section 21.13)
   with the value Success, a Server Identifier option (see Section 21.3)
   with the server's DUID, and a Client Identifier option (see
   Section 21.2) with the client's DUID

Notes:

The corrected text replaces "client" with "server".

I would like to thank Timothy Winters <tim@qacafe.com> for confirming that this is a bug in the specification.

RFC 8419, "Use of Edwards-Curve Digital Signature Algorithm (EdDSA) Signatures in the Cryptographic Message Syntax (CMS)", August 2018

Source of RFC: curdle (sec)

Errata ID: 5869
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2019-10-02
Verifier Name: Roman Danyliw
Date Verified: 2022-01-20

Section 2.3 says:

      hashalgs  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2)
                              country(16) us(840) organization(1)
                              gov(101) csor(3) nistalgorithm(4) 2 }

It should say:

      hashAlgs  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2)
                              country(16) us(840) organization(1)
                              gov(101) csor(3) nistalgorithm(4) 2 }

Notes:

The "hashAlgs" requires a capital letter for the other definitions in the section.

RFC 8422, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier", August 2018

Note: This RFC has been updated by RFC 8996

Source of RFC: tls (sec)

Errata ID: 5703
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Frank Theinen
Date Reported: 2019-04-23
Verifier Name: Benjamin Kaduk
Date Verified: 2019-05-01

Section 5.10. says:

All RSA signatures must be generated and verified according to
   Section 7.2 of [RFC8017].

It should say:

All RSA signatures must be generated and verified according to
   Section 8.2 of [RFC8017].

Notes:

Section 7.2 of RFC 8017 describes the RSAES-PKCS1-v1_5 encryption scheme. Section 8.2 of RFC 8017 describes the RSASSA-PKCS1-v1_5 signature scheme. The original text contradicts the natural expectation and is probably wrong. If it was intended, there should have been a thorough explanation (like in the well-known case of IKEv1 using the encryption scheme for signing).

Errata ID: 6002
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Rich Salz
Date Reported: 2020-03-02
Verifier Name: Benjamin Kaduk
Date Verified: 2020-03-05

Section 9 says:

   IANA has assigned two values in the "TLS SignatureAlgorithm" registry
   for ed25519 (7) and ed448 (8) with this document as reference.  This
   keeps compatibility with TLS 1.3.

It should say:

   IANA has assigned two values in the "TLS SignatureAlgorithm" registry
   for ed25519 (7) and ed448 (8) with DTLS-OK set to "Y" and this document
   as reference.  This keeps compatibility with TLS 1.3.

Notes:

IANA had consulted with Yoav, one of the authors (and a TLS registry expert), who explicitly told them to use DTLS-OK of "Y", but this clarification was not reflected in the final RFC. This also matches the text in the subsequent paragraph.

RFC 8427, "Representing DNS Messages in JSON", July 2018

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: art

Errata ID: 5439
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Richard Gibson
Date Reported: 2018-07-24
Verifier Name: Barry Leiba
Date Verified: 2020-11-25

Section 2.6 says:

   o  If the member name does not end in "HEX", the value is a domain
      name encoded as DNS labels consisting of UTF-8 codepoints from
      U+0000 to U+007F.  Within a label, codepoints above U+007F and the
      codepoint U+002E (ASCII period) MUST be expressed using JSON's
      escaping rules within this set of codepoints.  Separation between
      labels is indicated with a period (codepoint U+002E).
      Internationalized Domain Name (IDN) labels are always expressed in
      their A-label form, as described in [RFC5890].

It should say:

   o  If the member name does not end in "HEX", the value is a domain
      name encoded in common display format as DNS labels separated by
      U+002E "." characters. Internationalized Domain Name (IDN) labels
      are always expressed in their A-label form, as described in
      [RFC5890]. Label characters with code points equal to U+0022
      QUOTATION MARK or U+005C REVERSE SOLIDUS or less than U+0020 SPACE
      MUST be expressed using the JSON escaping rules of [RFC8259].
      U+002E "." and U+005C "\" characters within labels MUST be
      preceded by a backslash escape as specified by [RFC1035] (and that
      backslash must itself be escaped for use in a JSON string,
      resulting in either the three-character sequence "\\." or the
      four-character sequence "\\\\", respectively).

Notes:

The Original Text appears to specify inclusion of raw characters less than U+0020 in JSON strings, which is disallowed by section 7 of RFC 8259.

Further, as specifically noted in section 8 of RFC 8259, "implementations that compare strings with escaped characters unconverted may incorrectly find that "a\\b" and "a\u005Cb" are not equal", a fact logically deducible from the preceding "when all the strings represented in a JSON text are composed entirely of Unicode characters [UNICODE] (however escaped), then that JSON text is interoperable in the sense that all software implementations that parse it will agree on the contents of names and of string values in objects and arrays" text. Therefore, _correct_ JSON implementations must not distinguish e.g. "a.b.example." from "a\u002Eb.example.", as seems to be required by the Original Text.

RFC 8439, "ChaCha20 and Poly1305 for IETF Protocols", June 2018

Source of RFC: IRTF

Errata ID: 5689
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Stefan Heiss
Date Reported: 2019-04-11
Verifier Name: Colin Perkins
Date Verified: 2019-04-15

Section 2.5.1 says:

for i=1 upto ceil(msg length in bytes / 16)
   n = le_bytes_to_num(msg[((i-1)*16)..(i*16)] | [0x01])
   a += n
   a = (r * a) % p
   end

It should say:

for i=1 upto ceil(msg length in bytes / 16)
   j = min(i*16-1, msg length in bytes - 1)
   n = le_bytes_to_num(msg[((i-1)*16)..j] | [0x01])
   a += n
   a = (r * a) % p
   end

Notes:

Correction of Errata 5675

Errata ID: 5989
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Lê Minh Đăng
Date Reported: 2020-02-26
Verifier Name: Stanislav Smyshlyaev
Date Verified: 2021-04-28

Section 2.4.1 says:

encrypted_message +=  block ^ key_stream
...
encrypted_message += (block^key_stream)[0..len(plaintext)%64]

It should say:

encrypted_message |= block ^ key_stream
...
encrypted_message |= (block^key_stream)[0..len(plaintext)%64]

Notes:

The encrypted_message is the result of concatenation of blocks.
"|" and "|=" are used for concatenation elsewhere in the document, changing "+=" to "|=" will reduce ambiguity.

Errata ID: 6025
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: James Muir
Date Reported: 2020-03-21
Verifier Name: Stanislav Smyshlyaev
Date Verified: 2021-11-17

Section 3 says:

A constant-time but not optimal approach would be to naively implement the arithmetic operations for 288-bit integers, because even a naive implementation will not exceed 2^288 in the multiplication of (acc+block) and r.

It should say:

It is possible to create a constant-time, but not optimal, implementation by implementing arithmetic operations for 256-bit integers, because even a naive implementation will not exceed 2^256 in the multiplication of (acc+block) and r (note that we have r < 2^124 because r is "clamped").

Notes:

There are two issues 1) 288 bits is too big, and 2) a naive implementation of 288 bit integer arithmetic isn't necessarily constant time.

#1: 288 seems to be tied to the machine int size and assumes 32-bit integers (288 is nine 32-bit integers). It is probably better to give a number independent of the machine int size. It is possible to compute Poly1305 using 255 bit arithmetic. Padded blocks of the message are in the range 2^8, 2^8 +1,..., 2^129 -1. Assuming that the partial reduction step always reduces the accumulator to 130 bits, we have acc < 2^130, so acc+block < 2^131. r is a 16 byte value, but some of its bits are "clampled", so we have r < 2^124. Thus (acc+block)*r < 2^255; so we can get by with 255 bit big-integer arithmetic (probably 256 bits is more convenient to work with).

#2: big-integer arithmetic can be implemented in constant time, but perhaps not in a obvious or naive way. Keeping things constant time seems to depend on the characteristics of the underlying processor.

Errata ID: 6257
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alan Presser
Date Reported: 2020-08-18
Verifier Name: Stanislav Smyshlyaev
Date Verified: 2021-04-13

Section 2.5.2 says:

Adding s, we get this number, and serialize if to get the tag:

It should say:

Adding s, we get this number, and serialize it to get the tag:

Notes:

It's a trivial typo. Change "if" to "it".

RFC 8446, "The Transport Layer Security (TLS) Protocol Version 1.3", August 2018

Source of RFC: tls (sec)

Errata ID: 5483
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Patrick Kelsey
Date Reported: 2018-08-28
Verifier Name: Paul Wouters
Date Verified: 2024-03-29

Section 4.2.8.2 says:

For X25519 and X448, the contents of the public value are the byte
string inputs and outputs of the corresponding functions defined in
[RFC7748]: 32 bytes for X25519 and 56 bytes for X448.

It should say:

For X25519 and X448, the contents of the public value are the byte
string outputs of the corresponding functions defined in [RFC7748]: 32
bytes for X25519 and 56 bytes for X448.

Notes:

Per Section 7.4.2 of this RFC and Section 6 of RFC7748, the byte string inputs to the corresponding ECDH scalar multiplication function are the private key and the u-coordinate of the standard public base point, the former of which of course must not be transmitted and the latter of which is a known constant.

Paul Wouters (AD): Resolved but with the following Corrected Text:

For X25519 and X448, the contents of the public value is the K_A or
K_B value described in Section 6 of [RFC7748]. This is 32 bytes for
X25519 and 56 bytes for X448.

From another perspective, including the byte string inputs in the contents of the public value would contradict the resulting content sizes given at the end of the cited paragraph as well as the statement in Section 7.4.2 that the public key put into the KeyShareEntry is the output of ECDH scalar multiplication function.

Errata ID: 5868
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Hubert Kario
Date Reported: 2019-10-02
Verifier Name: Paul Wouters
Date Verified: 2024-03-21

Section 4.2.3 says:

   ECDSA algorithms:  Indicates a signature algorithm using ECDSA
      [ECDSA], the corresponding curve as defined in ANSI X9.62 [ECDSA]
      and FIPS 186-4 [DSS], and the corresponding hash algorithm as
      defined in [SHS].  The signature is represented as a DER-encoded
      [X690] ECDSA-Sig-Value structure.

It should say:

   ECDSA algorithms:  Indicates a signature algorithm using ECDSA
      [ECDSA], the corresponding curve as defined in ANSI X9.62 [ECDSA]
      and FIPS 186-4 [DSS], and the corresponding hash algorithm as
      defined in [SHS].  The signature is represented as a DER-encoded
      [X690] ECDSA-Sig-Value structure as defined in [RFC4492].

Notes:

There is a possibility for confusion as the ECDSA-Sig-Value has two conflicting definitions in authoritative standards. TLS always used the following (see RFC4492):

ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}

but the publicly accessible SECG SEC1 v2.0 (https://www.secg.org/sec1-v2.pdf) defines it like this:

ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER,
a INTEGER OPTIONAL,
y CHOICE { b BOOLEAN, f FieldElement } OPTIONAL
}

I think using the RFC5480 in the Corrected Text would be cleaner than RFC4492, but the former is not an existing reference, so we would need to update section 12 also.

Errata ID: 6123
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-24
Verifier Name: Paul Wouters
Date Verified: 2024-03-29

Section 2 says:

The handshake protocol allows peers to negotiate a protocol version, select cryptographic algorithms, optionally authenticate each other, and establish shared secret keying material.

Notes:

Only client authentication is optional (albeit, server authentication is implicit for PSK-only key exchange mode)

Paul Wouters(AD): corrected with the following text:

The handshake protocol allows peers to negotiate a protocol version, select cryptographic algorithms, authenticate each other (with client authentication being optional), and establish shared secret keying material.

Errata ID: 6142
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-29
Verifier Name: Paul Wouters
Date Verified: 2024-03-21

Section 4.6.1. says:

Clients MUST NOT cache tickets for longer than 7 days

It should say:

Clients MUST NOT use tickets for longer than 7 days

Notes:

"MUST NOT cache" is surely overly zealous and may unnecessarily result in non-compliant implementations

Errata ID: 6146
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-29
Verifier Name: Paul Wouters
Date Verified: 2024-03-21

Section 4.2.10. says:

The TLS version number

It should say:

The selected TLS version number

Errata ID: 7303
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Eric Lawrence
Date Reported: 2023-01-12
Verifier Name: Paul Wouters
Date Verified: 2024-03-29

Section 6.1 says:

This alert notifies the recipient that the sender will not send any more messages on this connection. 

It should say:

This alert notifies the recipient that the sender will not send any more messages on this connection. close_notify alerts should be sent with a severity level of WARNING.

Notes:

Apparently, TLS/1.0 specified these should be set to WARNING, not FATAL, but this text got lost somewhere along the way. https://github.com/pion/dtls/issues/195

OpenSSL/NSS both send as WARNING, and servers that have tried sending as FATAL have encountered compatibility problems with clients which treat FATAL alerts differently than WARNING alerts: e.g. https://source.chromium.org/chromium/chromium/src/+/main:third_party/boringssl/src/ssl/tls_record.cc;l=591;drc=c0872c02015009bf3dbab0a83c0452d141e8e9cf?q=tls_open_record&ss=chromium%2Fchromium%2Fsrc

Paul Wouters(AD): Resolved but with the following Corrected Text:

close_notify: This alert notifies the recipient that the sender will not send any more messages on this connection. Any data received after a closure alert has been received MUST be ignored. This alert MUST be sent with AlertLevel=warning.

Errata ID: 7250
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alan DeKok
Date Reported: 2022-11-14
Verifier Name: Paul Wouters
Date Verified: 2024-03-29

Section 4.6.1 says:

   The client MAY use this PSK for future handshakes by including the
   ticket value in the "pre_shared_key" extension in its ClientHello
   (Section 4.2.11).

It should say:

(to add)

  Where the client does not support session tickets, this extension MUST be ignored.

Notes:

I've seen a TLS implementation which doesn't implement session tickets. That's fine, but the implementation doesn't *ignore* session tickets it receives. Instead, it treats reception of the ticket as un recoverable error, and drops the TLS connection.

It's also worth adding a note to section 4.2 at the bottom of page 38. To note that in general, f an extension isn't supported AND doesn't materially affect the TLS exchange, THEN it should be ignored.

i.e. there's nothing in the spec which mentions Postel's law "be conservative in what you send, be liberal in what you accept". So implementors reading this document are free to do all kinds of odd things.

In addition, the text in Section 4.2 at the bottom of page 38 says:

"
Designers
and implementors should be aware of the fact that until the
handshake has been authenticated, active attackers can modify
messages and insert, remove, or replace extensions.
"

The implicit conclusion here is that an implementation receiving extensions must sanity check them. e.g. an attacker adding an undefined / unknown extension should not cause the entire session to be torn down.

Paul Wouters(AD): Resolved but with the Corrected Text:

The client MAY use this PSK for future handshakes by including the ticket value in the "pre_shared_key" extension in its ClientHello (Section 4.2.11). Clients which receive a NewSessionTicket message but do not support resumption MUST silently ignore this message.

Errata ID: 5976
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rich Salz
Date Reported: 2020-02-04
Verifier Name: Benjamin Kaduk
Date Verified: 2020-03-07

Section 11 says:

   This document updates an entry in the TLS Certificate Types registry
   originally created in [RFC6091] and updated in [RFC8447].  IANA has
   updated the entry for value 1 to have the name "OpenPGP_RESERVED",
   "Recommended" value "N", and comment "Used in TLS versions prior
   to 1.3."

It should say:

   This document updates two entries in the TLS Certificate Types registry
   originally created in [RFC6091] and updated in [RFC8447].  IANA has
   updated the entry for value 1 to have the name "OpenPGP_RESERVED",
   "Recommended" value "N", and comment "Used in TLS versions prior
   to 1.3."  IANA has updated the entry for value 0 to have the name
   "X509", "Recommended" value "Y", and comment "Was X.509 before TLS 1.3".

Notes:

The protocol description language changed the spelling used for "X509", and the registry should be updated to match.

Errata ID: 6122
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-24
Verifier Name: Paul Wouters
Date Verified: 2024-03-21

Section 1.2 says:

The key derivation functions have been redesigned.

It should say:

The key derivation function has been redesigned.

Errata ID: 6139
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-29
Verifier Name: Paul Wouters
Date Verified: 2024-03-29

Section 4.4.2.2. says:

As servers MAY require the presence of the "server_name" extension, clients
SHOULD send this extension, when applicable.

It should say:

As servers MAY require the presence of the "server_name" extension, client
SHOULD send this extension.

Notes:

Since it is unclear when it is applicable for a server to send the extension, dropping "when applicable"
seems appropriate. Alternatively, giving some extra guidance would be useful.

Paul Wouters(AD): Resolved with alternative Corrected Text:

As servers MAY require the presence of the "server_name" extension, clients SHOULD send this extension when the server is identified by name.

Errata ID: 6141
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-29
Verifier Name: Paul Wouters
Date Verified: 2024-03-21

Section 4.4.3 says:

   -  The context string

It should say:

   -  The context string (defined below)

Errata ID: 7774
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rebecca VanRheenen
Date Reported: 2024-01-22
Verifier Name: RFC Editor
Date Verified: 2024-01-22

Section 4.1.3 says:

ServerHello.Random

It should say:

ServerHello.random

Notes:

Lowercase "random".

This report was created/verified per Paul Wouter's note at https://www.rfc-editor.org/errata/eid7769.

RFC 8452, "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption", April 2019

Source of RFC: IRTF

Errata ID: 5854
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tony Arcieri
Date Reported: 2019-09-05
Verifier Name: Colin Perkins
Date Verified: 2020-06-06

Section Appendix A says:

...mulX_POLYVAL of it is 3931819bf271fada0503eb52574ca5f2.

It should say:

...mulX_POLYVAL of it is 3931819bf271fada0503eb52574ca572.

Notes:

The last hex byte is typoed (f2, should be 72).

Confirmed this was the case on the CFRG mailing list (2019-09-05)

RFC 8466, "A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery", October 2018

Source of RFC: l2sm (ops)

Errata ID: 5615
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2019-01-28
Verifier Name: Ignas Bagdonas
Date Verified: 2019-07-09

Section 5.10.1 says:

   The svc-bandwidth parameter must include a "cos-id" parameter if the
   "type" is set to "bw-per-cos".  The cos-id can be assigned based on
   either (1) the IEEE 802.1p value [IEEE-802-1D] in the C-tag or
   (2) the Differentiated Services Code Point (DSCP) in the Ethernet
   frame header.  Service frames are metered against the bandwidth
   profile based on the cos-id.

It should say:

   The svc-bandwidth parameter must include a "cos-id" parameter if the
   "type" is set to "bw-per-cos".  The cos-id can be assigned based on
   either (1) the IEEE 802.1p value [IEEE-802-1D] in the C-tag or
   (2) the Differentiated Services Code Point (DSCP) in the IP
   header.  Service frames are metered against the bandwidth
   profile based on the cos-id.

Notes:

The DSCP field is part of the IP packet header, not the Ethernet frame руфвук.

Errata ID: 6922
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mohamed Boucadair
Date Reported: 2022-04-05
Verifier Name: Rob Wilton
Date Verified: 2023-10-02

Section 5.5.2.1 says:

...
             <network-access-id>LA1</network-access-id>
                <service>
                  <svc-bandwidth>
                     <bandwidth>
                       <direction>input-bw</direction>
                        <type>bw-per-cos</type>
                         <cir>450000000</cir>
                         <cbs>20000000</cbs>
                         <eir>1000000000</eir>
                         <ebs>200000000</ebs>
                     </bandwidth>
                    </svc-bandwidth>
...
            <network-access-id>LA2</network-access-id>
                <service>
                  <svc-bandwidth>
                     <bandwidth>
                       <direction>input-bw</direction>
                        <type>bw-per-cos</type>
                         <cir>450000000</cir>
                         <cbs>20000000</cbs>
                         <eir>1000000000</eir>
                         <ebs>200000000</ebs>

It should say:

...
             <network-access-id>LA1</network-access-id>
                <service>
                  <svc-bandwidth>
                     <bandwidth>
                       <direction>input-bw</direction>
                        <type>bw-per-cos</type>
                         <cos-id>10</cos-id>
                         <cir>450000000</cir>
                         <cbs>20000000</cbs>
                         <eir>1000000000</eir>
                         <ebs>200000000</ebs>
                     </bandwidth>
                    </svc-bandwidth>
...
            <network-access-id>LA2</network-access-id>
                <service>
                  <svc-bandwidth>
                     <bandwidth>
                       <direction>input-bw</direction>
                        <type>bw-per-cos</type>
                         <cos-id>10</cos-id>
                         <cir>450000000</cir>
                         <cbs>20000000</cbs>
                         <eir>1000000000</eir>
                         <ebs>200000000</ebs>

Notes:

The cos-id must be included when the bandwidth type is set to "bw-per-cos".

Errata ID: 6683
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mohamed Boucadair
Date Reported: 2021-09-14
Verifier Name: Robert Wilton
Date Verified: 2024-01-12

Section 5.10.2.1 says:

   QoS classification rules are handled by "qos-classification-policy".
   qos-classification-policy is an ordered list of rules that match a
   flow or application and set the appropriate target CoS
   (target-class-id).  The user can define the match using a
   more specific flow definition (based on Layer 2 source and
   destination MAC addresses, cos, dscp, cos-id, color-id, etc.).  A
   "color-id" will be assigned to a service frame to identify its QoS
   profile conformance.  A service frame is "green" if it is conformant
   with the "committed" rate of the bandwidth profile.  A service frame
   is "yellow" if it exceeds the "committed" rate but is conformant with
   the "excess" rate of the bandwidth profile.  Finally, a service frame
   is "red" if it is conformant with neither the "committed" rate nor
   the "excess" rate of the bandwidth profile.

It should say:

   QoS classification rules are handled by "qos-classification-policy".
   qos-classification-policy is an ordered list of rules that match a
   flow or application and set the appropriate target CoS
   (target-class-id).  The user can define the match using a
   more specific flow definition (based on Layer 2 source and
   destination MAC addresses, dscp, color-type, etc.).  A
   "color-type" will be assigned to a service frame to identify its QoS
   profile conformance.  A service frame is "green" if it is conformant
   with the "committed" rate of the bandwidth profile.  A service frame
   is "yellow" if it exceeds the "committed" rate but is conformant with
   the "excess" rate of the bandwidth profile.  Finally, a service frame
   is "red" if it is conformant with neither the "committed" rate nor
   the "excess" rate of the bandwidth profile.

Notes:

There is no "color-id" under "qos-classification-policy". The text should refer to "color-type" given that the "qos-classification-policy" substree is as follows:

+--rw service
| +--rw qos {qos}?
| | +--rw qos-classification-policy
| | | +--rw rule* [id]
| | | +--rw id string
| | | +--rw (match-type)?
| | | | +--:(match-flow)
| | | | | +--rw match-flow
| | | | | +--rw dscp? inet:dscp
| | | | | +--rw dot1q? uint16
| | | | | +--rw pcp? uint8
| | | | | +--rw src-mac? yang:mac-address
| | | | | +--rw dst-mac? yang:mac-address
| | | | | +--rw color-type? identityref
| | | | | +--rw target-sites*
| | | | | | svc-id {target-sites}?
| | | | | +--rw any? empty
| | | | | +--rw vpn-id? svc-id
| | | | +--:(match-application)
| | | | +--rw match-application? identityref
| | | +--rw target-class-id? string

The same applies for "cos" and "cos-id".

The corrected text uses "color-type" instead of "color-id" and removes "cos" and "cos-id" from the flow definition examples.

RFC 8486, "Ambisonics in an Ogg Opus Container", October 2018

Source of RFC: codec (art)

Errata ID: 7342
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Carsten Bormann
Date Reported: 2023-02-11
Verifier Name: RFC Editor
Date Verified: 2023-02-13

Section 8 says:

8.  IANA Considerations

   IANA has added 17 new assignments to the "Opus Channel Mapping
   Families^a registry.

It should say:

8.  IANA Considerations

   IANA has added 17 new assignments to the "Opus Channel Mapping
   Families" registry.

Notes:

There is a backspace character enclosed with ^ and a in place of what should be a typewriter quote character.

RFC 8489, "Session Traversal Utilities for NAT (STUN)", February 2020

Source of RFC: tram (tsv)

Errata ID: 6268
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jared Williams
Date Reported: 2020-08-30
Verifier Name: Magnus Westerlund
Date Verified: 2020-10-19

Section Appendix B.1 says:

        00 01 00 9c      Request type and message length
        21 12 a4 42      Magic cookie
        78 ad 34 33   }
        c6 ad 72 c0   }  Transaction ID
        29 da 41 2e   }
        00 1e 00 20      USERHASH attribute header
        4a 3c f3 8f   }
        ef 69 92 bd   }
        a9 52 c6 78   }
        04 17 da 0f   }  Userhash value (32 bytes)
        24 81 94 15   }
        56 9e 60 b2   }
        05 c4 6e 41   }
        40 7f 17 04   }
        00 15 00 29      NONCE attribute header
        6f 62 4d 61   }
        74 4a 6f 73   }
        32 41 41 41   }
        43 66 2f 2f   }
        34 39 39 6b   }  Nonce value and padding (3 bytes)
        39 35 34 64   }
        36 4f 4c 33   }
        34 6f 4c 39   }
        46 53 54 76   }
        79 36 34 73   }
        41 00 00 00   }
        00 14 00 0b      REALM attribute header
        65 78 61 6d   }
        70 6c 65 2e   }  Realm value (11 bytes) and padding (1 byte)
        6f 72 67 00   }
        00 1c 00 20      MESSAGE-INTEGRITY-SHA256 attribute header
        e4 68 6c 8f   }
        0e de b5 90   }
        13 e0 70 90   }
        01 0a 93 ef   }  HMAC-SHA256 value
        cc bc cc 54   }
        4c 0a 45 d9   }
        f8 30 aa 6d   }
        6f 73 5a 01   }
 

It should say:

   Password Algorithm: SHA-256 (0x0002), and parameters len (0)

      00 01 00 90     Request type and message length
      21 12 a4 42     Magic cookie
      78 ad 34 33  }
      c6 ad 72 c0  }  Transaction ID
      29 da 41 2e  }
      00 1e 00 20     USERHASH attribute header
      4a 3c f3 8f  }
      ef 69 92 bd  }
      a9 52 c6 78  }
      04 17 da 0f  }  Userhash value (32  bytes)
      24 81 94 15  }
      56 9e 60 b2  }
      05 c4 6e 41  }
      40 7f 17 04  }
      00 15 00 29     NONCE attribute header
      6f 62 4d 61  }
      74 4a 6f 73  }
      32 41 41 41  }
      43 66 2f 2f  }
      34 39 39 6b  }  Nonce value and padding (3 bytes)
      39 35 34 64  }
      36 4f 4c 33  }
      34 6f 4c 39  }
      46 53 54 76  }
      79 36 34 73  }
      41 00 00 00  }
      00 14 00 0b     REALM attribute header
      65 78 61 6d  }
      70 6c 65 2e  }  Realm value (11  bytes) and padding (1 byte)
      6f 72 67 00  }
      00 1d 00 04     PASSWORD-ALGORITHM attribute header
      00 02 00 00     PASSWORD-ALGORITHM value (4 bytes)
      00 1c 00 20     MESSAGE-INTEGRITY-SHA256 attribute header
      b5 c7 bf 00  }
      5b 6c 52 a2  }
      1c 51 c5 e8  }
      92 f8 19 24  }  HMAC-SHA256 value
      13 62 96 cb  }
      92 7c 43 14  }
      93 09 27 8c  }
      c6 51 8e 65  }

Notes:

The message length in the test vector (first line, value: 9c) is the absolute length of the whole test vector. However from section 5. STUN Message Structure

"The message length MUST contain the size of the message in bytes, not
including the 20-byte STUN header."

So the message length in the header should be 20 bytes less than absolute length of the whole message.

0x9C - 20 = 0x88.

Also the section was missing an indication of what password algorithm that was to be used to derive the password. As SHA-256 was used, and is not the default the PASSWORD-ALGORITHM attribute is required. Thus, this corrected message contains that STUN attribute.

The corrected message has a recalculated Message-Integrity-SHA256 attribute.

Errata ID: 6290
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jared Williams
Date Reported: 2020-09-14
Verifier Name: Magnus Westerlund
Date Verified: 2020-09-15

Section 18.1 says:

Bits are assigned starting from the most significant side of the bit
set, so Bit 0 is the leftmost bit and Bit 23 is the rightmost bit.

It should say:

Bits are assigned starting from the least significant side of the bit
set, so Bit 0 is the rightmost bit, and Bit 23 is the leftmost bit.

RFC 8493, "The BagIt File Packaging Format (V1.0)", October 2018

Source of RFC: INDEPENDENT

Errata ID: 5556
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Devin Edmison
Date Reported: 2018-11-20
Verifier Name: Adrian Farrel
Date Verified: 2018-11-27

Section 1.3 says:

 bag checksum algorithm:  The name of a cryptographic checksum
      algorithm that has been normalized for use in a manifest or tag
      manifest file name (e.g., "sha512") as described in Section 2.4.

It should say:

 bag checksum algorithm:  The name of a cryptographic checksum
      algorithm that has been normalized for use in a manifest or tag
      manifest file name.  See Section 2.4.

Notes:

Remove confusing example and leave with reference to section that provides normative explanation.

RFC 8505, "Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery", November 2018

Note: This RFC has been updated by RFC 8928, RFC 8929, RFC 9010

Source of RFC: 6lo (int)

Errata ID: 5574
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Pascal Thubert
Date Reported: 2018-12-11
Verifier Name: Erik Kline
Date Verified: 2021-04-29

Section 9.1. says:

ARO Status

It should say:

Bit

Notes:

Title of the first column in table 2 should be ‘Bit’ as opposed to ‘ARO Status’.

RFC 8519, "YANG Data Model for Network Access Control Lists (ACLs)", March 2019

Source of RFC: netmod (ops)

Errata ID: 7312
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mohamed Boucadair
Date Reported: 2023-01-18
Verifier Name: Robert Wilton
Date Verified: 2024-01-12

Section A.1 says:

   The "example-newco-acl" module is an example of a company's
   proprietary model that augments the "ietf-acl" module.  It shows how
   to use 'augment' with an XML Path Language (XPath) expression to add
   additional match criteria, actions, and default actions for when no
   ACE matches are found.  All these are company proprietary extensions
   or system feature extensions.  "example-newco-acl" is just an
   example, and it is expected that vendors will create their own
   proprietary models.

It should say:

   The "example-newco-acl" module is an example of a company's
   proprietary model that augments the "ietf-access-control-list" module.  It shows how
   to use 'augment' with an XML Path Language (XPath) expression to add
   additional match criteria, actions, and default actions for when no
   ACE matches are found.  All these are company proprietary extensions
   or system feature extensions.  "example-newco-acl" is just an
   example, and it is expected that vendors will create their own
   proprietary models.

Notes:

There is no "ietf-acl" module in the document.

Errata ID: 7313
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mohamed Boucadair
Date Reported: 2023-01-18
Verifier Name: Robert Wilton
Date Verified: 2024-01-12

Section A.1 says:

   The following figure is the tree diagram of example-newco-acl.  In
   this example, /ietf-acl:acls/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/
   ietf-acl:matches are augmented with two new choices: protocol-
   payload-choice and metadata.  The protocol-payload-choice uses a
   grouping with an enumeration of all supported protocol values.
   Metadata matches apply to fields associated with the packet, that are
   not in the packet header, such as overall packet length.  In another
   example, /ietf-acl:acls/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/
   ietf-acl:actions are augmented with a new choice of actions.

It should say:

   The following figure is the tree diagram of example-newco-acl.  In
   this example, /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches
   are augmented with two new choices: protocol-payload-choice and
   metadata.  The protocol-payload-choice uses a
   grouping with an enumeration of all supported protocol values.
   Metadata matches apply to fields associated with the packet, that are
   not in the packet header, such as overall packet length.  In another
   example, /acl:acls/acl:acl/acl:aces/acl:ace/acl:actions 
   are augmented with a new choice of actions.

Notes:

The prefix is "acl" not "ietf-acl"

==
module ietf-access-control-list {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-access-control-list";
prefix acl;
...
==

RFC 8520, "Manufacturer Usage Description Specification", March 2019

Source of RFC: opsawg (ops)

Errata ID: 5664
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Leslie Daigle
Date Reported: 2019-03-18
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2019-03-23

Throughout the document, when it says:

Universal Resource Locator

Universal Resource Name

It should say:

Uniform Resource Locator

Uniform Resource Name

Notes:

Note that there are multiple instances throughout the document.

There haven't been UNIVERSAL resource locators, identifiers, or names for twenty years. I've labeled these as technical errata because they refer to something that doesn't exist.

Errata ID: 6295
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nick Lamb
Date Reported: 2020-09-23
Verifier Name: Rob Wilton
Date Verified: 2020-09-24

Section 4.1 says:

For example, if one saw the line "manufacturer" : "flobbidy.example.com",
then all Things that registered with a MUD URL that contained flobbity.example.com in its authority section would match.

It should say:

For example, if one saw the line "manufacturer" : "flobbity.example.com",
then all Things that registered with a MUD URL that contained flobbity.example.com in its authority section would match.

Notes:

Taken at face value it implies somehow a MUD Manager knows about a relationship between two different names flobbidy.example.com and flobbity.example.com in an unexplained way, the correction removes this confusion.

Errata ID: 7173
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Zeno Heeb
Date Reported: 2022-10-20
Verifier Name: Rob Wilton
Date Verified: 2024-01-15

Section 9 says:

Within each access list, access is permitted to packets flowing to or from the Thing that can be mapped to the domain name of "service.bms.example.com".

It should say:

Within each access list, access is permitted to packets flowing to or from the Thing that can be mapped to the domain name of "test.example.com".

Notes:

The subdomain in the Figure does not correspond to the one in the text.

Errata ID: 7819
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2024-02-23
Verifier Name: Rob Wilton
Date Verified: 2024-02-26

Section 13.1 says:

Note: A MUD file may need to be re-signed if the signature expires.

It should say:

Note: A MUD file may need to be re-signed if the certificate needed
to validate the signature expires.

Notes:

The signature does not expire, but the certificate does.

Errata ID: 5702
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stuart Cheshire
Date Reported: 2019-04-22
Verifier Name: Ignas Bagdonas
Date Verified: 2019-04-24

Section 16 says:

   implementors should take into
   account what other information they are advertising through
   mechanisms such as Multicast DNS (mDNS) [RFC6872]

It should say:

   implementors should take into
   account what other information they are advertising through
   mechanisms such as Multicast DNS (mDNS) [RFC6762]

Notes:

Incorrect reference for Multicast DNS (mDNS).

RFC 8528, "YANG Schema Mount", March 2019

Source of RFC: netmod (ops)

Errata ID: 5797
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Andy Bierman
Date Reported: 2019-07-29
Verifier Name: Ignas Bagdonas
Date Verified: 2019-08-08

Section A.2 says:

   {
     "ietf-interfaces:interfaces": {
       "interface": [
         {
           "name": "eth0",
           "type": "iana-if-type:ethernetCsmacd",
           "enabled": true,
           "ietf-logical-network-element:bind-lne-name": "eth0"
         }
       ]
     },

It should say:

   {
     "ietf-interfaces:interfaces": {
       "interface": [
         {
           "name": "eth0",
           "type": "iana-if-type:ethernetCsmacd",
           "enabled": true,
           "ietf-logical-network-element:bind-lne-name": "lne-1"
         }
       ]
     },

Notes:

leafref is for an LNE name, not an interface name

RFC 8531, "Generic YANG Data Model for Connection-Oriented Operations, Administration, and Maintenance (OAM) Protocols", April 2019

Source of RFC: lime (ops)

Errata ID: 5719
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2019-05-05
Verifier Name: Ignas Bagdonas
Date Verified: 2019-05-07

Section 4.4 says:

   There are several RPC commands defined for the purpose of OAM.  In
   this section, we present a snippet of the Continuity Check command
   for illustration purposes.  Please refer to Section 4.5 for the
   complete data hierarchy and Section 5 for the YANG module.

It should say:

   There are several RPC commands defined for the purpose of OAM.  In
   this section, we present a snippet of the Continuity Check command
   for illustration purposes.  Please refer to Section 4.7 for the
   complete data hierarchy and Section 5 for the YANG module.

Notes:

Incorrect Section No.

RFC 8536, "The Time Zone Information Format (TZif)", February 2019

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 6435
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2021-02-20
Verifier Name: Barry Leiba
Date Verified: 2021-02-21

Section 5.2 says:

   >> Response <<

   HTTP/1.1 200 OK
   Date: Fri, 01 Jun 2018 14:52:23 GMT
   Content-Type: application/json; charset="utf-8"
   Content-Length: xxxx

It should say:

   >> Response <<

   HTTP/1.1 200 OK
   Date: Fri, 01 Jun 2018 14:52:23 GMT
   Content-Type: application/json
   Content-Length: xxxx

Notes:

There is no charset parameter on application/json. See https://tools.ietf.org/html/rfc8259#section-11 (last sentence).

RFC 8552, "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", March 2019

Source of RFC: dnsop (ops)

Errata ID: 6551
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jason Mills
Date Reported: 2021-04-19
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2021-04-19

Section 4 says:

RFC 8552                      DNS AttrLeaf                    March 2019


4.  IANA Considerations

   IANA has established the "Underscored and Globally Scoped DNS Node
   Names" registry.  This section describes the registry, the
   definitions, the initial entries, the use of_ta and _example, and the
   use of [RFC8126] as guidance for expert review.  IANA has also
   updated the "Enumservices Registrations" registry with a pointer to
   this document.

It should say:

RFC 8552                      DNS AttrLeaf                    March 2019


4.  IANA Considerations

   IANA has established the "Underscored and Globally Scoped DNS Node
   Names" registry.  This section describes the registry, the
   definitions, the initial entries, the use of _ta and _example, and the
   use of [RFC8126] as guidance for expert review.  IANA has also
   updated the "Enumservices Registrations" registry with a pointer to
   this document.

Notes:

"the use of_ta and _example" is missing a single whitespace before `_ta`, corrected it should read:

"the use of _ta and _example"

Errata ID: 6772
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Robert Royals
Date Reported: 2021-12-03
Verifier Name: RFC Editor
Date Verified: 2021-12-06

Section 2 says:

   Only global underscored node names are registered in the "Underscored
   and Globally Scoped DNS Node Names" registry.  From the example
   above, that would mean _service1, _service2, _service3, _service 4,
   and _authority would be listed in the IANA registry.

It should say:

   Only global underscored node names are registered in the "Underscored
   and Globally Scoped DNS Node Names" registry.  From the example
   above, that would mean _service1, _service2, _service3, _service4,
   and _authority would be listed in the IANA registry.

Notes:

Typographical error with an unwanted space character between "_service" and "4"

Errata ID: 6777
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Robert Royals
Date Reported: 2021-12-06
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2021-12-06

Section 4 says:

   IANA has established the "Underscored and Globally Scoped DNS Node
   Names" registry.  This section describes the registry, the
   definitions, the initial entries, the use of_ta and _example, and the

It should say:

   IANA has established the "Underscored and Globally Scoped DNS Node
   Names" registry.  This section describes the registry, the
   definitions, the initial entries, the use of _ta and _example, and the

Notes:

There should be a space character between "of" and "_ta" in "of_ta".

Errata ID: 7064
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bernie Hoeneisen
Date Reported: 2022-08-02
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2022-08-19

Section 4.1.2. says:

 | URI        | _acct                 | [RFC6118]     |

It should say:

 | URI        | _acct                 | [RFC7566]     |

Notes:

Wrong reference. Note that is also has an impact to the IANA registry: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names

---
Readers are encouraged to read the below email thread (and may also want to read RFC6118 for additional information):
https://mailarchive.ietf.org/arch/msg/dnsop/TuoV8FmCf1l_pKr500Fo0AI8tVM/

Errata ID: 7065
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bernie Hoeneisen
Date Reported: 2022-08-02
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2024-01-15

Section 4.2.1 says:

          | URI        | _iax                  | [RFC6118]     |

It should say:

          | URI        | _iax                  | [RFC6315]     |

Notes:

Wrong reference. Note that is also has an impact to the IANA registry: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names

Errata ID: 7066
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bernie Hoeneisen
Date Reported: 2022-08-02
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2024-01-29

Section 4.1.2. says:

          | URI        | _dccp                 | [RFC7566]     |

It should say:

         | URI        | _dccp                 | [RFC4340]     |

Notes:

Wrong reference. RFC7566 does not even mention "dccp".

Note that this also has an impact to the IANA registry: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names


[ Warren Kumari (Ops AD): Please see the thread for resolution: https://mailarchive.ietf.org/arch/msg/dnsop/WFMXL5dY8sniHwVtkPfcqvWk3nI/

This was added as "part of a list used to "reserve" the names of (transport) protocols, so that constructs like _25._quic.example.com could be constructed where the _name denotes the protocol and not the name of something." . I am requesting that the IANA update the reference to match. ]

Errata ID: 7067
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bernie Hoeneisen
Date Reported: 2022-08-02
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2024-01-29

Section 4.1.2. says:

          | URI        | _sctp                 | [RFC6118]     |

It should say:

          | URI        | _sctp                 | [RFC4340]     |

Notes:

Wrong reference. RFC6118 does not even mention "sctp".

Note that this also has an impact to the IANA registry: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names

[ Warren Kumari (Ops AD): Please also see Errata 7066, and the thread https://mailarchive.ietf.org/arch/msg/dnsop/WFMXL5dY8sniHwVtkPfcqvWk3nI/

This was added as "part of a list used to "reserve" the names of (transport) protocols, so that constructs like _25._quic.example.com could be constructed where the _name denotes the protocol and not the name of something." . I am requesting that the IANA update the reference to match. ]

Errata ID: 7068
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bernie Hoeneisen
Date Reported: 2022-08-02
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2024-01-31

Section 4.1.2 says:

          | URI        | _tcp                  | [RFC6118]     |
          | URI        | _udp                  | [RFC6118]     |

It should say:

| URI        | _tcp                 | [RFC4340]     |
| URI        | _udp                 | [RFC4340]     |

Notes:

Wrong reference. RFC6118 does not even mention "tcp" nor "udp".

Note that this also has an impact to the IANA registry: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names

[ Warren Kumari (Ops AD): Please also see Errata 7066, and the thread https://mailarchive.ietf.org/arch/msg/dnsop/WFMXL5dY8sniHwVtkPfcqvWk3nI/

This was added as "part of a list used to "reserve" the names of (transport) protocols, so that constructs like _25._quic.example.com could be constructed where the _name denotes the protocol and not the name of something." . IANA will update the reference. ]

RFC 8555, "Automatic Certificate Management Environment (ACME)", March 2019

Source of RFC: acme (sec)

Errata ID: 5729
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Rob Stradling
Date Reported: 2019-05-22
Verifier Name: Roman Danyliw.com
Date Verified: 2024-01-11

Section 7.5.1 says:

The client indicates to the server that it is ready for the challenge
validation by sending an empty JSON body ("{}") carried in a POST
request to the challenge URL (not the authorization URL).

It should say:

The client indicates to the server that it is ready for the challenge
validation by sending a POST request to the challenge URL (not the
authorization URL), where the body of the POST request is a JWS object
whose JSON payload is a response object (see Section 8).  For all
challenge types defined in this document, the response object is the
empty JSON object ("{}").

Notes:

It's clear from other text in section 7.5.1 that the "empty JSON body" is interpreted by the ACME server as a "response object". (The first function of this erratum is to clarify this point).

Section 8 says that "The definition of a challenge type includes...Contents of response objects", and section 7.5.1 notes that "the challenges in this document do not define any response fields, but future specifications might define them". (The second function of this erratum is to permit clients to send response objects that contain response fields).

Errata ID: 5732
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Rob Stradling
Date Reported: 2019-05-23
Verifier Name: Paul Wouters
Date Verified: 2024-02-22

Section 8 says:

A challenge object with an error MUST have status
equal to "invalid".

It should say:

A challenge object with an error MUST have status
equal to "processing" or "invalid".

Notes:

Section 8.2 says that 'The server MUST add an entry to the "error" field in the challenge after each failed validation query'. However, if the challenge must then become "invalid", it is never possible to retry any validation query (because "invalid" is a final state for a challenge object).
This erratum is necessary to permit validation query retries to ever happen.

Errata ID: 5983
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jason Baker
Date Reported: 2020-02-14
Verifier Name: Benjamin Kaduk
Date Verified: 2020-02-29

Section 9.1 says:

   A file of this type contains one or more certificates encoded with
   the PEM textual encoding, according to [RFC7468].  The textual
   encoding of certificates in this file MUST use the strict encoding
   and MUST NOT include explanatory text.  The ABNF for this format is
   as follows, where "stricttextualmsg" and "eol" are as defined in
   Section 3 of RFC 7468:

   certchain = stricttextualmsg *(eol stricttextualmsg)

It should say:

   A file of this type contains one or more certificates encoded with
   the PEM textual encoding, according to [RFC7468].  The textual
   encoding of certificates in this file MUST use the strict encoding
   and MUST NOT include explanatory text.  The ABNF for this format is
   as follows, where "stricttextualmsg" is as defined in
   Section 3 of RFC 7468:

   certchain = stricttextualmsg *(stricttextualmsg)

Notes:

Examples within RFC 8555 indicate that only one EOL should be present between entries in the PEM chain.

RFC 7468 already defines a stricttextualmsg as ending with EOL
stricttextualmsg = preeb eol
strictbase64text
posteb eol

If a second EOL is to be added before each strict textual message this would result in a blank line between entries. The prior example in https://tools.ietf.org/html/rfc8555#section-7.4.2 indicates an intention for only one EOL marker to be used:
-----BEGIN CERTIFICATE-----
[End-entity certificate contents]
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
[Issuer certificate contents]
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
[Other certificate contents]
-----END CERTIFICATE-----

Errata ID: 6364
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Evangelos Karatsiolis
Date Reported: 2020-12-23
Verifier Name: Deb Cooley
Date Verified: 2024-03-22

Section 7.1.4 says:

   wildcard (optional, boolean):  This field MUST be present and true
      for authorizations created as a result of a newOrder request
      containing a DNS identifier with a value that was a wildcard
      domain name.  For other authorizations, it MUST be absent.
      Wildcard domain names are described in Section 7.1.3.

It should say:

   wildcard (optional, boolean):  This field MUST be present and true
      for authorizations created as a result of a newOrder request
      containing a DNS identifier with a value that was a wildcard
      domain name.  For other authorizations, it MUST be absent or
      false.  For pre-authorizations, it MUST be absent or false.
      Wildcard domain names are described in Section 7.1.3.

Notes:

This section states that the wildcard field must be absent for other authorizations, but the example in this section has an explicitly set wildcard field with value false. The proposed change allows both options, either omitting it or explicitly setting it to false. Also a sentence has been added to explicitly describe the behavior for pre-authorizations.

Errata ID: 7565
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Paul Breed
Date Reported: 2023-07-13
Verifier Name: Roman Danyliw
Date Verified: 2024-01-11

Section 8.1 says:

 The "Thumbprint" step indicates the computation specified in
   [RFC7638], using the SHA-256 digest [FIPS180-4].  As noted in
   [RFC7518] any prepended zero octets in the fields of a JWK object
   MUST be stripped before doing the computation.

It should say:

The "Thumbprint" step indicates the computation specified in
   [RFC7638], using the SHA-256 digest [FIPS180-4].  As noted in
   [RFC7518] any additional prepended zero octets in the fields of a JWK object
   MUST be stripped before doing the computation.  
   Fixed length fields such as found in ECDSA keys should be their natural length and 
   leading zero octets should not be stripped.

Notes:

This comment was really aimed at the leading 0 octet sometimes used with RSA, but the comment is not RSA specific. ECDSA keys can have fixed length fields (X,Y) where there can be leading zeros. This led me astray in implementing an ECDSA thumbprint routine for ACME. The result was that 1/128 ECDSA keys failed to generate t humbp[rint as leading zeros were removed.

Errata ID: 5733
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rob Stradling
Date Reported: 2019-05-23
Verifier Name: Roman Danyliw.com
Date Verified: 2024-01-11

Section 8.3 says:

POST /acme/chall/prV_B7yEyA4

It should say:

POST /acme/chall/prV_B7yEyA4 HTTP/1.1

Errata ID: 5734
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rob Stradling
Date Reported: 2019-05-23
Verifier Name: Roman Danyliw.com
Date Verified: 2024-01-11

Section 8.4 says:

POST /acme/chall/Rg5dV14Gh1Q

It should say:

POST /acme/chall/Rg5dV14Gh1Q HTTP/1.1

Errata ID: 5735
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rob Stradling
Date Reported: 2019-05-23
Verifier Name: Roman Danyliw.com
Date Verified: 2024-01-11

Section 8.3 says:

GET /.well-known/acme-challenge/LoqXcYV8...jxAjEuX0

It should say:

GET /.well-known/acme-challenge/LoqXcYV8...jxAjEuX0 HTTP/1.1

Errata ID: 6016
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Benjamin Wilson
Date Reported: 2020-03-13
Verifier Name: Benjamin Kaduk
Date Verified: 2020-03-13

Section 7.3.5 says:

holder of the new key to take over the account form the holder of the

It should say:

holder of the new key to take over the account from the holder of the

Notes:

Should be "from" instead of "form"

Errata ID: 6103
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Theodor Nolte
Date Reported: 2020-04-14
Verifier Name: Roman Danyliw.com
Date Verified: 2024-01-11

Section 7.1. says:

   o  A "newAccount" resource (Section 7.3)

   o  A "newOrder" resource (Section 7.4)

It should say:

   o  A "newAccount" resource (Section 7.3)

   o  A "newAuthz" resource (Section 7.4)

   o  A "newOrder" resource (Section 7.4)

Notes:

The item for the "newAuthz" resource is missing in the list of resources.

Errata ID: 6104
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Theodor Nolte
Date Reported: 2020-04-14
Verifier Name: Roman Danyliw.com
Date Verified: 2024-01-11

Section 6.7.1 says:

   in the problem document.

HTTP/1.1 403 Forbidden
Content-Type: application/problem+json
Link: <https://example.com/acme/directory>;rel="index"

{
    "type": "urn:ietf:params:acme:error:malformed",
    "detail": "Some of the identifiers requested were rejected",
    "subproblems": [
        {
            "type": "urn:ietf:params:acme:error:malformed",
            "detail": "Invalid underscore in DNS name \"_example.org\"",
            "identifier": {
                "type": "dns",
                "value": "_example.org"
            }
        },
        {
            "type": "urn:ietf:params:acme:error:rejectedIdentifier",
            "detail": "This CA will not issue for \"example.net\"",
            "identifier": {
                "type": "dns",
                "value": "example.net"
            }
        }
    ]
}

It should say:

   in the problem document.

   HTTP/1.1 403 Forbidden
   Content-Type: application/problem+json
   Link: <https://example.com/acme/directory>;rel="index"

   {
       "type": "urn:ietf:params:acme:error:malformed",
       "detail": "Some of the identifiers requested were rejected",
       "subproblems": [
           {
               "type": "urn:ietf:params:acme:error:malformed",
               "detail": "Invalid underscore in DNS name \"_example.org\"",
               "identifier": {
                   "type": "dns",
                   "value": "_example.org"
               }
           },
           {
               "type": "urn:ietf:params:acme:error:rejectedIdentifier",
               "detail": "This CA will not issue for \"example.net\"",
               "identifier": {
                   "type": "dns",
                   "value": "example.net"
               }
           }
       ]
   }

Notes:

The indenting of the code block of the HTTP reply is not aligned.

RFC 8558, "Transport Protocol Path Signals", April 2019

Source of RFC: IAB

Errata ID: 5747
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2019-06-05
Verifier Name: Mirja Kühlewind
Date Verified: 2024-01-11

Section 4 says:

Intermediate path elements should not add visible signals that
      identify the user, origin node, or origin network [RFC8164].

It should say:

Intermediate path elements should not add visible signals that
      identify the user, origin node, or origin network [RFC8165].

Notes:

This was a typo.

RFC 8561, "A YANG Data Model for Microwave Radio Link", June 2019

Source of RFC: ccamp (rtg)

Errata ID: 6842
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ye Min
Date Reported: 2022-02-08
Verifier Name: John Scudder
Date Verified: 2022-04-08

Section Annex A.3 says:

 "name": "RLT-A:CT-2",
...
           "tx-frequency": 10618000,

It should say:

 "name": "RLT-A:CT-2",
...
           "tx-frequency": 10728000,

Notes:

A.3 describes the XPIC configuration. The tx-frequency for the two CTs under XPIC configuration should be the same, both should be 10728000.

This should be a copy&paste error from A.2 2+0 configuration.

See also the ccamp mailing list: https://mailarchive.ietf.org/arch/msg/ccamp/_VITOVYwAGg_4M2FHntaLpRTHKs/

RFC 8572, "Secure Zero Touch Provisioning (SZTP)", April 2019

Source of RFC: netconf (ops)

Errata ID: 6684
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alex Krichevsky
Date Reported: 2021-09-14
Verifier Name: Rob Wilton
Date Verified: 2021-09-22

Section 8.1 says:

   The DHCPv4 server MAY include a single instance of the
   OPTION_V4_SZTP_REDIRECT option in DHCP messages it sends.  Servers
   MUST NOT send more than one instance of the OPTION_V4_SZTP_REDIRECT
   option.

It should say:

   The DHCPv4 server MAY include OPTION_V4_SZTP_REDIRECT in DHCP messages it sends.

Notes:

The original text contradicts the statement in the same section:
"If the length of the 'bootstrap-server-list' field is too large to
fit into a single option, then OPTION_V4_SZTP_REDIRECT MUST be split
into multiple instances of the option according to the process
described in [RFC3396]."

Errata ID: 6616
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Srihari Ramanathan
Date Reported: 2021-06-18
Verifier Name: Rob Wilton
Date Verified: 2021-06-21

Section 4.2.3 says:

   For device-independent queries, the three bootstrapping artifacts
   defined in Section 3 are encoded into the SVR records as follows.

   Artifact to SRV Record Mapping:

      Conveyed Information:  This artifact is not supported directly.
         Instead, the essence of unsigned redirect information is mapped
         to SVR records per [RFC2782].

It should say:

   For device-independent queries, the three bootstrapping artifacts
   defined in Section 3 are encoded into the SRV records as follows.

   Artifact to SRV Record Mapping:

      Conveyed Information:  This artifact is not supported directly.
         Instead, the essence of unsigned redirect information is mapped
         to SRV records per [RFC2782].

Notes:

In both places "SVR" should obviously read "SRV".

Errata ID: 6807
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lijun Liao
Date Reported: 2022-01-04
Verifier Name: RFC Editor
Date Verified: 2022-04-06

Section 3.3 says:

   When unencrypted, the ownership voucher artifact is as defined in
   [RFC8366].  As described, it is a CMS structure whose topmost content
   type MUST be the OID id-signedData (1.2.840.113549.1.7.2), whose
   eContentType MUST be OID id-ct-animaJSONVoucher
   (1.2.840.113549.1.9.16.1), or the OID id-data (1.2.840.113549.1.7.1).
   When the OID id-data is used, the encoding (JSON, XML, etc.) SHOULD
   be communicated externally.  In either case, the associated content
   is an octet string containing ietf-voucher data in the expected
   encoding.

   When encrypted, the topmost content type of the ownership voucher
   artifact's CMS structure MUST be the OID id-envelopedData
   (1.2.840.113549.1.7.3), and the encryptedContentInfo's content type
   MUST be the OID id-signedData (1.2.840.113549.1.7.2), whose
   eContentType MUST be OID id-ct-animaJSONVoucher
   (1.2.840.113549.1.9.16.1), or the OID id-data (1.2.840.113549.1.7.1).
   When the OID id-data is used, the encoding (JSON, XML, etc.) SHOULD
   be communicated externally.  In either case, the associated content
   is an octet string containing ietf-voucher data in the expected
   encoding.

It should say:

   When unencrypted, the ownership voucher artifact is as defined in
   [RFC8366].  As described, it is a CMS structure whose topmost content
   type MUST be the OID id-signedData (1.2.840.113549.1.7.2), whose
   eContentType MUST be OID id-ct-animaJSONVoucher
   (1.2.840.113549.1.9.16.1.40), or the OID id-data (1.2.840.113549.1.7.1).
   When the OID id-data is used, the encoding (JSON, XML, etc.) SHOULD
   be communicated externally.  In either case, the associated content
   is an octet string containing ietf-voucher data in the expected
   encoding.

   When encrypted, the topmost content type of the ownership voucher
   artifact's CMS structure MUST be the OID id-envelopedData
   (1.2.840.113549.1.7.3), and the encryptedContentInfo's content type
   MUST be the OID id-signedData (1.2.840.113549.1.7.2), whose
   eContentType MUST be OID id-ct-animaJSONVoucher
   (1.2.840.113549.1.9.16.1.40), or the OID id-data (1.2.840.113549.1.7.1).
   When the OID id-data is used, the encoding (JSON, XML, etc.) SHOULD
   be communicated externally.  In either case, the associated content
   is an octet string containing ietf-voucher data in the expected
   encoding.

Notes:

The OID for id-ct-animaJSONVoucher is 1.2.840.113549.1.9.16.1.40.

--VERIFIER NOTES--
Author verified errata is correct and also appears in http://oid-info.com/get/1.2.840.113549.1.9.16.1.40

Errata ID: 6933
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dimitris Athanasopoulos
Date Reported: 2022-04-14
Verifier Name: RFC Editor
Date Verified: 2022-04-14

Section section-7.2 says:

   Content-Type: application/yang.data+xml

It should say:

   Content-Type: application/yang-data+xml

Notes:

Note the diff: "yang.data" vs "yang-data"

There are 5 occurrences of the same errata in Section7.2.

As per RESTCONF Protocol [rfc8040] valid Media Types are:
a) application/yang-data+xml
b) application/yang-data+json

References:
https://datatracker.ietf.org/doc/html/rfc8040#section-11.3
https://www.iana.org/assignments/media-types/media-types.xhtml

RFC 8577, "Signaling RSVP-TE Tunnels on a Shared MPLS Forwarding Plane", April 2019

Source of RFC: mpls (rtg)

Errata ID: 5743
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vishnu Pavan Beeram
Date Reported: 2019-05-30
Verifier Name: Deborah Brungard
Date Verified: 2019-05-30

Section 11.3 says:

   IANA manages the "Record Route Object Sub-object Flags" registry as
   part of the "Resource Reservation Protocol-Traffic Engineering (RSVP-
   TE) Parameters" registry located at <http://www.iana.org/assignments/
   rsvp-te-parameters>.  Prior to this document, this registry did not
   include Label Sub-object Flags.  This document creates the addition
   of a new subregistry for Label Sub-object Flags as shown below.

      Flag  Name                    Reference

      0x1   Global Label            [RFC3209]
      0x02  TE Link Label           [RFC8577], Section 9.3
      0x04  Delegation Label        [RFC8577], Section 9.5

It should say:

   IANA manages the "Record Route Object Sub-object Flags" registry as
   part of the "Resource Reservation Protocol-Traffic Engineering (RSVP-
   TE) Parameters" registry located at <http://www.iana.org/assignments/
   rsvp-te-parameters>.  Prior to this document, this registry did not
   include Label Sub-object Flags.  This document creates the addition
   of a new subregistry for Label Sub-object Flags as shown below.

      Flag  Name                    Reference

      0x1   Global Label            [RFC3209]
      0x02  TE Link Label           [RFC8577], Section 9.3
      0x04  Delegation Label        [RFC8577], Section 9.5
 
  All assignments in this sub-registry are to be performed via
  Standards Action.

Notes:

This errata is being reported as a response to the following email from IANA.

**
Authors/WG Chairs/ADs for RFC 8577,

During the publication process, the registration procedures were unintentionally removed from the document. Is this something that an errata should be submitted for?

In version 9 of the document, it says: All assignments in this sub-registry are to be performed via Standards Action.

In the published RFC this sentence does not appear to be there.

Please advise.

Thank you,

Michelle Cotton
Protocol Parameters Engagement Sr. Manager

RFC 8579, "Sieve Email Filtering: Delivering to Special-Use Mailboxes", May 2019

Source of RFC: extra (art)

Errata ID: 5877
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Stephan Bosch
Date Reported: 2019-10-18
Verifier Name: Barry Leiba
Date Verified: 2019-10-19

Section 6 says:

require "imapsieve";
require "special-use";
require "environment";
require "variables";

if environment :contains "imap.mailbox" "*" {
    set "mailbox" "${1}";
}

if allof(
    environment "imap.cause" "COPY",
    specialuse_exists "${mailbox}" "\\Junk") {
    redirect "spam-report@example.org";
}

It should say:

require "imapsieve";
require "special-use";
require "environment";
require "variables";

if environment :matches "imap.mailbox" "*" {
    set "mailbox" "${1}";
}

if allof(
    environment "imap.cause" "COPY",
    specialuse_exists "${mailbox}" "\\Junk") {
    redirect "spam-report@example.org";
}

Notes:

The final example is using the ":contains" match type to extract a match variable, which will not work. It should use ":matches" instead.

RFC 8586, "Loop Detection in Content Delivery Networks (CDNs)", April 2019

Source of RFC: httpbis (wit)

Errata ID: 5704
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2019-04-25
Verifier Name: Francesca Palombini
Date Verified: 2022-11-09

Section 1.2 says:

   This specification uses the Augmented Backus-Naur Form (ABNF)
   notation of [RFC5234] with a list extension, defined in Section 7 of
   [RFC7230], that allows for compact definition of comma-separated
   lists using a '#' operator (similar to how the '*' operator indicates
   repetition).  Additionally, it uses a token (OWS), uri-host, and port
   rules from [RFC7230] and the parameter rule from [RFC7231].

It should say:

   This specification uses the Augmented Backus-Naur Form (ABNF)
   notation of [RFC5234] with a list extension, defined in Section 7 of
   [RFC7230], that allows for compact definition of comma-separated
   lists using a '#' operator (similar to how the '*' operator indicates
   repetition).  Additionally, it uses the token, OWS, uri-host and port
   rules from [RFC7230] and the parameter rule from [RFC7231].

Notes:

The last sentence apparently was mangled during AUTH48. The correct version is from draft-ietf-httpbis-cdn-loop-02. "token", "OWS", "uri-host" and "port" are all ABNF rules.

RFC 8610, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", June 2019

Source of RFC: cbor (art)

Errata ID: 6526
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sean Bartell
Date Reported: 2021-04-11
Verifier Name: Francesca Palombini
Date Verified: 2021-04-12

Section G.2 says:

   The escaping rules of JSON strings are applied equivalently for
   text-based byte strings, e.g., "\" stands for a single backslash and
   "'" stands for a single quote.  Whitespace is included literally,
   i.e., the previous section does not apply to text-based byte strings.

It should say:

   The escaping rules of JSON strings are applied equivalently for
   text-based byte strings, e.g., "\\" stands for a single backslash and
   "\'" stands for a single quote.  Whitespace is included literally,
   i.e., the previous section does not apply to text-based byte strings.

Notes:

"\" and "'" need a backslash to escape them.

RFC 8620, "The JSON Meta Application Protocol (JMAP)", July 2019

Note: This RFC has been updated by RFC 9404

Source of RFC: jmap (art)

Errata ID: 5791
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Neil Jhaveri
Date Reported: 2019-07-02
Verifier Name: Alexey Melnikov
Date Verified: 2019-09-23

Section 2.1 says:

"capabilities": {
  "urn:ietf:params:jmap:core": {
    "maxSizeUpload": 50000000,
    "maxConcurrentUpload": 8,
    "maxSizeRequest": 10000000,
    "maxConcurrentRequest": 8,
    "maxCallsInRequest": 32,
    "maxObjectsInGet": 256,
    "maxObjectsInSet": 128,
    "collationAlgorithms": [
      "i;ascii-numeric",
      "i;ascii-casemap",
      "i;unicode-casemap"
    ]
  },
  "urn:ietf:params:jmap:mail": {}
  "urn:ietf:params:jmap:contacts": {},
  "https://example.com/apis/foobar": {
    "maxFoosFinangled": 42
  }
}

It should say:

"capabilities": {
  "urn:ietf:params:jmap:core": {
    "maxSizeUpload": 50000000,
    "maxConcurrentUpload": 8,
    "maxSizeRequest": 10000000,
    "maxConcurrentRequests": 8,
    "maxCallsInRequest": 32,
    "maxObjectsInGet": 256,
    "maxObjectsInSet": 128,
    "collationAlgorithms": [
      "i;ascii-numeric",
      "i;ascii-casemap",
      "i;unicode-casemap"
    ]
  },
  "urn:ietf:params:jmap:mail": {},
  "urn:ietf:params:jmap:contacts": {},
  "https://example.com/apis/foobar": {
    "maxFoosFinangled": 42
  }
}

Notes:

In the capabilities section of the example Session Resource response, "maxConcurrentRequest" should be "maxConcurrentRequests".

In addition, the following line is missing a trailing comma:
"urn:ietf:params:jmap:mail": {}

RFC 8632, "A YANG Data Model for Alarm Management", September 2019

Source of RFC: ccamp (rtg)

Errata ID: 6866
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Reshad Rahman
Date Reported: 2022-03-04
Verifier Name: John Scudder
Date Verified: 2022-05-10

Section 6 says:

      container older-than {
        presence "Age specification";
        description
          "Matches the 'last-status-change' leaf in the alarm.";
        choice age-spec {

It should say:

      container older-than {
        presence "Age specification";
        description
          "Matches the 'last-changed' leaf in the alarm.";
        choice age-spec {

Notes:

There is no last-status-change leaf in alarm (and it seems there never was).

See also https://mailarchive.ietf.org/arch/msg/ccamp/wmCgk0DQq0lG6S_e59W-MKW8EOQ/

RFC 8650, "Dynamic Subscription to YANG Events and Datastores over RESTCONF", November 2019

Source of RFC: netconf (ops)

Errata ID: 7400
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mohamed Boucadair
Date Reported: 2023-03-21
Verifier Name: Rob Wilton
Date Verified: 2023-10-02

Section Appendix A.3 says:

   POST /restconf/operations
        /ietf-subscribed-notifications:establish-subscription
   {
      "ietf-subscribed-notifications:input": {
         "stream": "NETCONF",
         "stream-xpath-filter":
           "/ietf-vrrp:vrrp-protocol-error-event[
             protocol-error-reason='checksum-error']/",
      }
   }

       Figure 16: Establishing a Subscription Error Reason via XPath

...

   POST /restconf/operations
        /ietf-subscribed-notifications:modify-subscription
   {
      "ietf-subscribed-notifications:input": {
         "stream": "NETCONF",
         "stream-subtree-filter": {
           "/ietf-vrrp:vrrp-protocol-error-event" : {}
         }
      }
   }
                Figure 17: Example "modify-subscription" RPC

It should say:

   POST /restconf/operations
        /ietf-subscribed-notifications:establish-subscription

   {
      "ietf-subscribed-notifications:input": {
         "stream": "NETCONF",
         "stream-xpath-filter":
           "/ietf-vrrp:vrrp-protocol-error-event[
             protocol-error-reason='checksum-error']/"
      }
   }

       Figure 16: Establishing a Subscription Error Reason via XPath

...

   POST /restconf/operations
        /ietf-subscribed-notifications:modify-subscription

   {
      "ietf-subscribed-notifications:input": {
         "stream": "NETCONF",
         "stream-subtree-filter": {
           "/ietf-vrrp:vrrp-protocol-error-event" : {}
         }
      }
   }
                Figure 17: Example "modify-subscription" RPC

Notes:

* There is a missing CRLF in both figures as per RFC9112:

--
HTTP-message = start-line CRLF
*( field-line CRLF )
CRLF
[ message-body ]
--

* The last item in the JSON of figure 16 includes a trailing "," while it shouldn't.

Errata ID: 6369
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Muly Ilan
Date Reported: 2020-12-24
Verifier Name: Robert Wilton
Date Verified: 2024-01-12

Section A.2.1 says:

A.2.1.  "subscription-modified"

   A "subscription-modified" encoded in JSON would look like:

   {
     "ietf-restconf:notification" : {
       "eventTime": "2007-09-01T10:00:00Z",
       "ietf-subscribed-notifications:subscription-modified": {
         "id": 39,
         "uri": "https://example.com/restconf/subscriptions/22"
         "stream-xpath-filter": "/example-module:foo",
         "stream": {
            "ietf-netconf-subscribed-notifications" : "NETCONF"
         }
       }
     }
   }

It should say:

A.2.1.  "subscription-modified"

   A "subscription-modified" encoded in JSON would look like:

   {
     "ietf-restconf:notification" : {
       "eventTime": "2007-09-01T10:00:00Z",
       "ietf-subscribed-notifications:subscription-modified": {
         "id": 39,
         "uri": "https://example.com/restconf/subscriptions/39"
         "stream-xpath-filter": "/example-module:foo",
         "stream": {
            "ietf-netconf-subscribed-notifications" : "NETCONF"
         }
       }
     }
   }

Notes:

Change the URI to match the ID.

Errata ID: 6379
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Muly Ilan
Date Reported: 2021-01-03
Verifier Name: Rob Wilton
Date Verified: 2021-01-05

Section A.1.1 says:

   Upon receipt of the successful response, the subscriber does a GET to
   the provided URI to start the flow of notification messages.  When
   the publisher receives this, the subscription is moved to the active
   state (c).

   GET /restconf/subscriptions/22

             Figure 5: "establish-subscription" Subsequent POST

It should say:

   Upon receipt of the successful response, the subscriber does a GET to
   the provided URI to start the flow of notification messages.  When
   the publisher receives this, the subscription is moved to the active
   state (c).

   GET /restconf/subscriptions/22

             Figure 5: "establish-subscription" Subsequent GET

Notes:

Substitute POST by GET in the figure caption

RFC 8664, "Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing", December 2019

Source of RFC: pce (rtg)

Errata ID: 6753
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Shuping Peng
Date Reported: 2021-11-25
Verifier Name: John Scudder
Date Verified: 2022-01-10

Section 4.3.1 says:

If the F bit is set to zero
      (see below), then the NT field has no meaning and MUST be ignored
      by the receiver. 

It should say:

If the F bit is set to one
      (see below), then the NT field has no meaning and MUST be ignored
      by the receiver. 

Notes:

Later it says, when this F bit is set to 1, the NAI value is absent, so the NT field has no meaning.
F: When this bit is set to 1, the NAI value in the subobject
body is absent. The F bit MUST be set to 1 if NT=0;
otherwise, it MUST be set to zero. The S and F bits MUST NOT
both be set to 1.

RFC 8665, "OSPF Extensions for Segment Routing", December 2019

Source of RFC: ospf (rtg)

Errata ID: 6838
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Praveen Kumar
Date Reported: 2022-02-05
Verifier Name: John Scudder
Date Verified: 2022-02-07

Section 6.1 says:

            B-Flag:  Backup Flag.  If set, the Adj-SID refers to an
               adjacency that is eligible for protection (e.g., using IP
               Fast Reroute or MPLS-FRR (MPLS-Fast Reroute) as described
               in Section 2.1 of [RFC8402].

It should say:

            B-Flag:  Backup Flag.  If set, the Adj-SID refers to an
               adjacency that is eligible for protection (e.g., using IP
               Fast Reroute or MPLS-FRR (MPLS-Fast Reroute) as described
               in Section 3.4 of [RFC8402].

Notes:

I don't see any section 2.1 in RFC 8402. Reference of section 2.1 of RFC 8402 seems incorrect. It should be section 3.4 as per my understanding. Kindly fix it if possible.

RFC 8667, "IS-IS Extensions for Segment Routing", December 2019

Source of RFC: lsr (rtg)

Errata ID: 7722
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: John Scudder
Date Reported: 2023-12-07
Verifier Name: Andrew Alston
Date Verified: 2023-12-08

Section 2.1.1.1 says:

2.1.1.1.  V-Flag and L-Flag

It should say:

2.1.1.1.  V-Flag, L-Flag, and the SID/Index/Label Field

Notes:

Since the SID/Index/Label field is defined in this subsection, it's misleading for the title to mention only the flags and is a disservice to readers using the document as a reference.

This is also discussed in https://mailarchive.ietf.org/arch/msg/lsr/56_LEEZvHDHrnkC98f7BtpOkkY0/ where Acee also suggests a broader clarification. The narrowly-scoped change reflected in this erratum seems sufficient to fix the problem I encountered; in my view, it doesn't preclude an additional erratum for some of the other matters that were mentioned by Acee if there's support for that as well.

Thanks to Tony Li for suggesting the wording.

<Andrew Note> I agree this helps clarify the text which could easily have otherwise been misread - hence the verification of the errata

RFC 8668, "Advertising Layer 2 Bundle Member Link Attributes in IS-IS", December 2019

Source of RFC: isis (rtg)

Errata ID: 6957
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Praveen Kumar
Date Reported: 2022-05-09
Verifier Name: John Scudder
Date Verified: 2022-05-10

Section 5 says:

The name of the IANA registry for Sub-TLVs for TLVs 22, 23, 141, 222,
and 223 has been changed to include sub-TLV 25.

It should say:

The name of the IANA registry for Sub-TLVs for TLVs 22, 23, 141, 222,
and 223 has been changed to include TLV 25.

Notes:

25 is top-level TLV. By mistake, it is written as sub-TLV.

(See also https://mailarchive.ietf.org/arch/msg/lsr/LvcOMxMuJW40ThHJeV3nOjl-0HY/)

RFC 8669, "Segment Routing Prefix Segment Identifier Extensions for BGP", December 2019

Source of RFC: idr (rtg)

Errata ID: 6681
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Benjamin Kaduk
Date Reported: 2021-09-08
Verifier Name: Alvaro Retana
Date Verified: 2021-09-08

In the Acknowledgements, it says:

   The authors would like to thank Peter Yee, Tony Przygienda, Mirja
   Kuhlewind, Alexey Melnikov, Eric Rescorla, Suresh Krishnan, Warren
   Kumari, Ben Campbell Sue Hares, and Martin Vigoureux for IDR Working
   Group last call, IETF Last Call, directorate, and IESG reviews.

It should say:

   The authors would like to thank Peter Yee, Tony Przygienda, Mirja
   Kuhlewind, Alexey Melnikov, Eric Rescorla, Suresh Krishnan, Warren
   Kumari, Ben Campbell, Sue Hares, and Martin Vigoureux for IDR Working
   Group last call, IETF Last Call, directorate, and IESG reviews.

Notes:

missing comma

RFC 8684, "TCP Extensions for Multipath Operation with Multiple Addresses", March 2020

Source of RFC: mptcp (tsv)

Errata ID: 6609
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Krishna Khanal
Date Reported: 2021-06-14
Verifier Name: Martin Duke
Date Verified: 2024-01-19

Section B.3 says:

   initiator                                                    listener
       |                                                           |
       |    S  0(20) <MP_CAPABLE>, <TFO cookie>                    |
       | --------------------------------------------------------> |
       |                                                           |
       |    S. 0(0) ack 21 <MP_CAPABLE>                            |
       | <-------------------------------------------------------- |
       |                                                           |
       |    .  1(100) ack 21 <DSS ack=1 seq=1 ssn=1 dlen=100>      |
       | <-------------------------------------------------------- |
       |                                                           |
       |    .  21(0) ack 1 <MP_CAPABLE>                            |
       | --------------------------------------------------------> |
       |                                                           |
       |    .  21(20) ack 101 <DSS ack=101 seq=1 ssn=1 dlen=20>    |
       | --------------------------------------------------------> |
       |                                                           |

                    Figure 19: The Listener Supports TFO

It should say:

initiator                                                    listener
       |                                                           |
       |    S  0(20) <MP_CAPABLE>, <TFO cookie>                    |
       | --------------------------------------------------------> |
       |                                                           |
       |    S. 0(0) ack 21 <MP_CAPABLE>                            |
       | <-------------------------------------------------------- |
       |                                                           |
       |    .  1(100) ack 21 <DSS seq=1 ssn=1 dlen=100, M=1, A=0>  |
       | <-------------------------------------------------------- |
       |                                                           |
       |    .  21(0) ack 1 <MP_CAPABLE>                            |
       | --------------------------------------------------------> |
       |                                                           |
       |    .  21(20) ack 101 <DSS ack=101 seq=1 ssn=1 dlen=20>    |
       | --------------------------------------------------------> |
       |                                                           |

                    Figure 19: The Listener Supports TFO

Notes:

The example for TCP Fastopen with MPTCPv1 in RFC8684, Appendix-B.3 shows the listener sending an incorrect data-ack in its first data packet to the initiator sent immediately after its SYN-ACK.
At this point, the listener has not received the initiator's key, so it cannot generate the data-ack in it's response packets.
The correct behaviour would be to set flag 'A' to 0 and exclude sending data-ack until the initiator's key is received.

RFC 8700, "Fifty Years of RFCs", December 2019

Source of RFC: IAB

Errata ID: 5946
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Matthäus Wander
Date Reported: 2019-12-26
Verifier Name: Mirja Kühlewind
Date Verified: 2024-01-11

Section 2 says:

   +--------------------+----------+-----------------------------------+
   | [RFC0748]          | April    | First April 1st RFC               |
   |                    | 1977     | published                         |
   +--------------------+----------+-----------------------------------+

It should say:

   +--------------------+----------+-----------------------------------+
   | [RFC0748]          | April    | First April 1st RFC               |
   |                    | 1978     | published                         |
   +--------------------+----------+-----------------------------------+

Notes:

RFC 748 carries the date "1 April 1978".

Errata ID: 5992
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Nicole Ortizo
Date Reported: 2020-02-26
Verifier Name: Mirja Kühlewind
Date Verified: 2024-01-11

Section 3.1. says:

would be several years before
   ideas like mobile code, remote procedure calls, ActiveX, JAVA, and
   Representational State Transfer (RESTful) interfaces appeared.

It should say:

would be several years before
   ideas like mobile code, remote procedure calls, ActiveX, Java, and
   Representational State Transfer (RESTful) interfaces appeared.

Notes:

Java doesn't stand for anything else. It's a name not an acronym.

RFC 8707, "Resource Indicators for OAuth 2.0", February 2020

Source of RFC: oauth (sec)

Errata ID: 6810
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Jan Goebel
Date Reported: 2022-01-05
Verifier Name: Roman Danyliw
Date Verified: 2022-01-20

Section 4 says:

In typical OAuth deployments the authorization sever is in a position
to observe and track a significant amount of user and client behavior.

It should say:

In typical OAuth deployments, the authorization server is in a position
to observe and track a significant amount of user and client behavior.

Notes:

1. typo: sever -> server
2. I think we also need a comma after "In typical OAuth deployments" because it is an introductory phrase, but maybe a native English speaker can confirm.

RFC 8709, "Ed25519 and Ed448 Public Key Algorithms for the Secure Shell (SSH) Protocol", February 2020

Source of RFC: curdle (sec)

Errata ID: 6164
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: HARUYAMA Seigo
Date Reported: 2020-05-11
Verifier Name: Benjamin Kaduk
Date Verified: 2020-05-16

Section 6 says:

6.  Signature Format

   The "ssh-ed25519" key format has the following encoding:

   string  "ssh-ed25519"

   string  signature

   Here, 'signature' is the 64-octet signature produced in accordance
   with [RFC8032], Section 5.1.6.

   The "ssh-ed448" key format has the following encoding:

   string  "ssh-ed448"

   string  signature

   Here, 'signature' is the 114-octet signature produced in accordance
   with [RFC8032], Section 5.2.6.

It should say:

6.  Signature Format

   The "ssh-ed25519" signature format has the following encoding:

   string  "ssh-ed25519"

   string  signature

   Here, 'signature' is the 64-octet signature produced in accordance
   with [RFC8032], Section 5.1.6.

   The "ssh-ed448" signature format has the following encoding:

   string  "ssh-ed448"

   string  signature

   Here, 'signature' is the 114-octet signature produced in accordance
   with [RFC8032], Section 5.2.6.

Notes:

s/key format/signature format/

RFC 8727, "JSON Binding of the Incident Object Description Exchange Format", August 2020

Source of RFC: mile (sec)

Errata ID: 7334
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Carsten Bormann
Date Reported: 2023-02-06
Verifier Name: Roman Danyliw
Date Verified: 2023-03-29

Section 6 says:

          {iodef-BusinessImpact => BusinessImpact /

It should say:

          {iodef-BusinessImpact => BusinessImpact} /

Notes:

A closing brace is missing in this line of the rule for "Assessment".

RFC 8754, "IPv6 Segment Routing Header (SRH)", March 2020

Source of RFC: 6man (int)

Errata ID: 7081
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Tianran Zhou
Date Reported: 2022-08-11
Verifier Name: Erik Kline
Date Verified: 2023-07-23

Section 4.1.1 says:

A reduced SRH does not contain the first segment of the related SR
Policy (the first segment is the one already in the DA of the IPv6
header), and the Last Entry field is set to n-2, where n is the
number of elements in the SR Policy.

It should say:

A reduced SRH does not contain the first segment of the related SR
Policy (the first segment is the one already in the DA of the IPv6
header), and the Last Entry field is set to n-2, where n is the
number of elements in the SR Policy.

When an SRH includes TLVs and only one 128-bit Segment, the reduced
SRH MUST NOT be used to avoid errors of SRH TLV processing defined
in section 2.1. 

Notes:

When only one single Segment is included in the SRH, the last entry will be 0 forever, so a segment endpoint node cannot specify whether the last Segment is included or removed from the SRH.

As defined in section 2.1, only when the header length of SRH larger then (0+1)*2, the TLVs will be processed.
1. When the Segment is removed, Segment Lefts = Last Entry = 0, each segment endpoint node will skip the bytes 8-16, and then process the following bytes following the TLV processing rules, which will cause errors.
2. When the segment is not removed, Segment Lefts = Last Entry = 0, each segment endpoint will process the TLVs correctly from byte 8+16.

Choosing option 2 can avoid processing error of SRH TLVs and be compatible with the current hardware implementation. Thus option 1 MUST be avoid in implementation.

Errata ID: 7102
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Darren Dukes
Date Reported: 2022-08-23
Verifier Name: Erik Kline
Date Verified: 2023-06-06

Section 2 says:

Segments Left:  Defined in [RFC8200], Section 4.4.

It should say:

Segments Left:  Defined in [RFC8200], Section 4.4.
Specifically, for the SRH, the number of unprocessed 
128-bit entries in the Segment List.

Notes:

RFC8754 describes “The encoding of IPv6 segments in the SRH” where IPv6 segments are defined in RFC8402. RFC8402 describes binding SIDs and adjacency SIDs for SRv6. Both these SID types identify more than a single explicitly listed intermediate node to be visited.

The current definition of Segments Left only indicates it is defined in RFC8200, and RFC8200 defines it as “Number of route segments remaining, i.e., number of explicitly listed intermediate nodes still to be visited before reaching the final destination”.

Previous versions of draft-ietf-6man-segment-routing-header (0-11) referenced RFC2460/RFC8200 and described the Segments Left field by use in the SRH; as an index into the Segment List. This was removed in later versions (12/13) to consolidate the use of segments left to be specific to the segment processed (now section 4.3.1). However, that removed the definition of its meaning in the SRH which led to the current issue.

The corrected text restores the meaning of Segments Left for the SRH in relation to Segment List (which is not defined in RFC8200), while still leaving its use during segment processing to the segment definition (section 4.3.1 or future documents).

RFC 8773, "TLS 1.3 Extension for Certificate-Based Authentication with an External Pre-Shared Key", March 2020

Source of RFC: tls (sec)

Errata ID: 7598
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Russ Housley
Date Reported: 2023-08-11
Verifier Name: RFC Editor
Date Verified: 2024-04-09

Section 5.1 says:

When the "psk_key_exchange_modes" extension is included in the
ServerHello message, servers MUST select the psk_dhe_ke mode
for the initial handshake.

It should say:

When the "psk_key_exchange_modes" extension is included in the
ClientHello message, servers MUST select the psk_dhe_ke mode
for the initial handshake.

Notes:

According to RFC 8446, the "psk_key_exchange_modes" extension only appears in the ClientHello message. Further, the slides presented on this topic at IETF 101show the "psk_key_exchange_modes" extension in the ClientHello message and no other place. It is pretty clear that this is an editorial error.

RFC 8777, "DNS Reverse IP Automatic Multicast Tunneling (AMT) Discovery", April 2020

Source of RFC: mboned (ops)

Errata ID: 6218
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Brian Wellington
Date Reported: 2020-07-01
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2020-07-17

Section 4.3.2 says:

10   IN TYPE260  \# (
       18 ; length
       0a ; precedence=10
       02 ; D=0, relay type=2, an IPv6 address
       20010db800000000000000000000000f ) ; 2001:db8::15
10   IN TYPE260  \# (
       24 ; length
       80 ; precedence=128
       83 ; D=1, relay type=3, a wire-encoded domain name
       09616d7472656c617973076578616d706c6503636f6d ) ; domain name

It should say:

10   IN TYPE260  \# (
       18 ; length
       0a ; precedence=10
       02 ; D=0, relay type=2, an IPv6 address
       20010db8000000000000000000000015 ) ; 2001:db8::15
10   IN TYPE260  \# (
       25 ; length
       80 ; precedence=128
       83 ; D=1, relay type=3, a wire-encoded domain name
       09616d7472656c617973076578616d706c6503636f6d00 ) ; domain name

Notes:

In the first example, the IPv6 address is incorrectly encoded.

In the second example, the trailing root label of the domain name was not included, and should be. This also increases the length by 1 byte.

Errata ID: 6688
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Dick Franks
Date Reported: 2021-09-19
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2021-10-05

Section 5 says:

   +-------+---------------------------------------+
   | 3     | A wire-encoded domain name is present |
   +-------+---------------------------------------+
   | 4-255 | Unassigned                            |
   +-------+---------------------------------------+

      Table 2: Initial Contents of the "Relay Type
                    Field" Registry

   Values 0, 1, 2, and 3 are further explained in Sections 4.2.3 and
   4.2.4.  Relay type numbers 4 through 255 can be assigned with a
   policy of Specification Required (as described in [RFC8126]).

It should say:

   +-------+---------------------------------------+
   | 3     | A wire-encoded domain name is present |
   +-------+---------------------------------------+
   | 4-127 | Unassigned                            |
   +-------+---------------------------------------+

      Table 2: Initial Contents of the "Relay Type
                    Field" Registry

   Values 0, 1, 2, and 3 are further explained in Sections 4.2.3 and
   4.2.4.  Relay type numbers 4 through 127 can be assigned with a
   policy of Specification Required (as described in [RFC8126]).

Notes:

Relay Type is a 7 bit field, the MS bit of the wire-format octet contains the D-bit.

[Update: 2021-10-05 - AD: Confirmed that you can't fit 8 bits into a 7 bit field - see: https://mailarchive.ietf.org/arch/msg/mboned/cdzHm6Uxwuua5zsOONHtK-RmdU8/ ]

Errata ID: 6155
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Jake Holland
Date Reported: 2020-05-01
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2021-04-27

Section Appendix A says:

   <CODE BEGINS>
     $ cat translate.py
     #!/usr/bin/env python3
     import sys
     name=sys.argv[1]
     wire=''
     for dn in name.split('.'):
       if len(dn) > 0:
         wire += ('%02x' % len(dn))
         wire += (''.join('%02x'%ord(x) for x in dn))
     print(len(wire)//2) + 2
     print(wire)

     $ ./translate.py amtrelays.example.com
     24
     09616d7472656c617973076578616d706c6503636f6d
   <CODE ENDS>

It should say:

   <CODE BEGINS>
     $ cat translate.py
     #!/usr/bin/env python3
     import sys
     name=sys.argv[1]
     wire=''
     for dn in name.split('.'):
       if len(dn) > 0:
         wire += ('%02x' % len(dn))
         wire += (''.join('%02x'%ord(x) for x in dn))
     print(len(wire)//2 + 2)
     print(wire)

     $ ./translate.py amtrelays.example.com
     24
     09616d7472656c617973076578616d706c6503636f6d
   <CODE ENDS>

Notes:

The original sample code gives a runtime error when executed. The +2 should have been inside the parenthesis for the print function.

RFC 8782, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification", May 2020

Note: This RFC has been obsoleted by RFC 9132

Source of RFC: dots (sec)

Errata ID: 6449
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Mohamed Boucadair
Date Reported: 2021-03-02
Verifier Name: Benjamin Kaduk
Date Verified: 2021-03-02

Section 7.1 says:

   The Server Name Indication (SNI) extension [RFC6066] i defines a
   mechanism for a client to tell a (D)TLS server the name of the server
   it wants to contact.

It should say:

   The Server Name Indication (SNI) extension [RFC6066] defines a
   mechanism for a client to tell a (D)TLS server the name of the server
   it wants to contact.

Notes:

extra "i"

RFC 8783, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification", May 2020

Source of RFC: dots (sec)

Errata ID: 6496
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Mohamed Boucadair
Date Reported: 2021-03-26
Verifier Name: Roman Danyliw
Date Verified: 2022-01-19

Section 7.3 says:

   A DOTS client can also issue a GET request with a "content" query
   parameter set to 'non-config' to exclusively retrieve non-
   configuration data bound to a given ACL as shown in Figure 30.  A
   response to this GET request is shown in Figure 31.

     GET /restconf/data/ietf-dots-data-channel:dots-data\
         /dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\
         /acl=test-acl-ipv6-udp?content=non-config HTTP/1.1
     Host: example.com
     Accept: application/yang-data+json

It should say:

   A DOTS client can also issue a GET request with a "content" query
   parameter set to 'nonconfig' to exclusively retrieve non-
   configuration data bound to a given ACL as shown in Figure 30.  A
   response to this GET request is shown in Figure 31.

     GET /restconf/data/ietf-dots-data-channel:dots-data\
         /dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\
         /acl=test-acl-ipv6-udp?content=nonconfig HTTP/1.1
     Host: example.com
     Accept: application/yang-data+json

Notes:

RFC8040 defines this value for the "content" Query Parameter (RFC 4.8.1):

| nonconfig | Return only non-configuration descendant data nodes |

RFC 8785, "JSON Canonicalization Scheme (JCS)", June 2020

Source of RFC: INDEPENDENT

Errata ID: 6292
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Matt Langston
Date Reported: 2020-09-20
Verifier Name: Adrian Farrel
Date Verified: 2020-09-22

Section 3.2.2.2 says:

see Section 24.3.2.2 of [ECMA-262]

It should say:

see Section 24.5.2.2 of [ECMA-262]

RFC 8792, "Handling Long Lines in Content of Internet-Drafts and RFCs", June 2020

Source of RFC: netmod (ops)

Errata ID: 6739
Status: Verified
Type: Editorial
Publication Format(s) : PDF, HTML
Reported By: Martin Thomson
Date Reported: 2021-11-18
Verifier Name: RFC Editor
Date Verified: 2021-11-18

Section 7.1.2 says:

Exceptionally long lines MAY be folded multiple times.

It should say:

Exceptionally long lines MAY be folded multiple times.

Notes:

The "MAY" in this text lacks a bcp14 XML tag. This is apparent in the non-text renderings.

--VERIFIER NOTES--
This also applies to section 8.1.2

RFC 8794, "Extensible Binary Meta Language", July 2020

Source of RFC: cellar (art)

Errata ID: 7189
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Steve Lhomme
Date Reported: 2022-10-30
Verifier Name: Murray Kucherawy
Date Verified: 2023-07-10

Section 17.1. says:

   One-octet Element IDs MUST be between 0x81 and 0xFE.  These items are
   valuable because they are short, and they need to be used for
   commonly repeated elements.  Element IDs are to be allocated within
   this range according to the "RFC Required" policy [RFC8126].

   The following one-octet Element IDs are RESERVED: 0xFF and 0x80.

   Values in the one-octet range of 0x00 to 0x7F are not valid for use
   as an Element ID.

   Two-octet Element IDs MUST be between 0x407F and 0x7FFE.  Element IDs
   are to be allocated within this range according to the "Specification
   Required" policy [RFC8126].

   The following two-octet Element IDs are RESERVED: 0x7FFF and 0x4000.

   Values in the two-octet ranges of 0x0000 to 0x3FFF and 0x8000 to
   0xFFFF are not valid for use as an Element ID.

   Three-octet Element IDs MUST be between 0x203FFF and 0x3FFFFE.
   Element IDs are to be allocated within this range according to the
   "First Come First Served" policy [RFC8126].

   The following three-octet Element IDs are RESERVED: 0x3FFFFF and
   0x200000.

   Values in the three-octet ranges of 0x000000 to 0x1FFFFF and 0x400000
   to 0xFFFFFF are not valid for use as an Element ID.

   Four-octet Element IDs MUST be between 0x101FFFFF and 0x1FFFFFFE.
   Four-octet Element IDs are somewhat special in that they are useful
   for resynchronizing to major structures in the event of data
   corruption or loss.  As such, four-octet Element IDs are split into
   two categories.  Four-octet Element IDs whose lower three octets (as
   encoded) would make printable 7-bit ASCII values (0x20 to 0x7E,
   inclusive) MUST be allocated by the "Specification Required" policy.
   Sequential allocation of values is not required: specifications
   SHOULD include a specific request and are encouraged to do early
   allocations.

   To be clear about the above category: four-octet Element IDs always
   start with hex 0x10 to 0x1F, and that octet may be chosen so that the
   entire VINT has some desirable property, such as a specific CRC.  The
   other three octets, when ALL having values between 0x20 (32, ASCII
   Space) and 0x7E (126, ASCII "~"), fall into this category.

   Other four-octet Element IDs may be allocated by the "First Come
   First Served" policy.

   The following four-octet Element IDs are RESERVED: 0x1FFFFFFF and
   0x10000000.

   Values in the four-octet ranges of 0x00000000 to 0x0FFFFFFF and
   0x20000000 to 0xFFFFFFFF are not valid for use as an Element ID.

It should say:

   One-octet Element IDs MUST be between 0x80 and 0xFE.  These items are
   valuable because they are short, and they need to be used for
   commonly repeated elements.  Element IDs are to be allocated within
   this range according to the "RFC Required" policy [RFC8126].

   The following one-octet Element ID is RESERVED: 0xFF.

   Values in the one-octet range of 0x00 to 0x7F are not valid for use
   as an Element ID.

   Two-octet Element IDs MUST be between 0x407F and 0x7FFE.  Element IDs
   are to be allocated within this range according to the "Specification
   Required" policy [RFC8126].

   The following two-octet Element ID is RESERVED: 0x7FFF.

   Values in the two-octet ranges of 0x0000 to 0x4000 and 0x8000 to
   0xFFFF are not valid for use as an Element ID.

   Three-octet Element IDs MUST be between 0x203FFF and 0x3FFFFE.
   Element IDs are to be allocated within this range according to the
   "First Come First Served" policy [RFC8126].

   The following three-octet Element ID is RESERVED: 0x3FFFFF.

   Values in the three-octet ranges of 0x000000 to 0x200000 and 0x400000
   to 0xFFFFFF are not valid for use as an Element ID.

   Four-octet Element IDs MUST be between 0x101FFFFF and 0x1FFFFFFE.
   Four-octet Element IDs are somewhat special in that they are useful
   for resynchronizing to major structures in the event of data
   corruption or loss.  As such, four-octet Element IDs are split into
   two categories.  Four-octet Element IDs whose lower three octets (as
   encoded) would make printable 7-bit ASCII values (0x20 to 0x7E,
   inclusive) MUST be allocated by the "Specification Required" policy.
   Sequential allocation of values is not required: specifications
   SHOULD include a specific request and are encouraged to do early
   allocations.

   To be clear about the above category: four-octet Element IDs always
   start with hex 0x10 to 0x1F, and that octet may be chosen so that the
   entire VINT has some desirable property, such as a specific CRC.  The
   other three octets, when ALL having values between 0x20 (32, ASCII
   Space) and 0x7E (126, ASCII "~"), fall into this category.

   Other four-octet Element IDs may be allocated by the "First Come
   First Served" policy.

   The following four-octet Element ID is RESERVED: 0x1FFFFFFF.

   Values in the four-octet ranges of 0x00000000 to 0x10000000 and
   0x20000000 to 0xFFFFFFFF are not valid for use as an Element ID.

Notes:

Allow 0x80 EBML ID (and similar) since it's used in Matroska.

This changes the rules for the IANA registry.

See https://github.com/ietf-wg-cellar/ebml-specification/pull/408

RFC 8806, "Running a Root Server Local to a Resolver", June 2020

Source of RFC: dnsop (ops)

Errata ID: 7692
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Deliang Chang
Date Reported: 2023-10-31
Verifier Name: RFC Editor
Date Verified: 2023-10-31

Section 3 says:

   There is a risk that a system using a local authoritative server for
   the root zone cannot refresh the contents of the root zone before the
   expire time in the SOA.  A system using a local authoritative server
   for the root zone MUST NOT serve stale data for the root zone.  To
   mitigate the risk that stale data is served, the local root server
   MUST immediately switch to using non-local root servers when it
   detects that it would be serving state data.

It should say:

   There is a risk that a system using a local authoritative server for
   the root zone cannot refresh the contents of the root zone before the
   expire time in the SOA.  A system using a local authoritative server
   for the root zone MUST NOT serve stale data for the root zone.  To
   mitigate the risk that stale data is served, the local root server
   MUST immediately switch to using non-local root servers when it
   detects that it would be serving stale data.

Notes:

Based on the context, it seems that in the last sentence the intended word is "stale" as in stale data, instead of "state". So, I believe there might be a typo in the text, and the correct interpretation would be to swith back to the non-local root when stale data is detected.

RFC 8824, "Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)", June 2021

Source of RFC: lpwan (int)

Errata ID: 7389
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF
Reported By: Marco Tiloca
Date Reported: 2023-03-19
Verifier Name: Eric Vyncke
Date Verified: 2023-08-03

Section 3.1 says:

For example, the Uri-Path option is
mandatory in the request, and it might not be present in the
response.

It should say:

For example, the Uri-Path option can
be used in the request, while it is not used in the response.

Notes:

The Uri-Path option is not mandatory in a CoAP request, and it is not supposed to be used in a CoAP response.

Errata ID: 7397
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF
Reported By: Marco Tiloca
Date Reported: 2023-03-19
Verifier Name: Eric Vyncke
Date Verified: 2023-08-03

Section 7.2 says:

These classes point out that the Outer option contains the OSCORE
option and that the message is OSCORE protected; this option carries
the information necessary to retrieve the Security Context.

It should say:

As per these classes, the Outer options comprise the OSCORE option,
which indicates that the message is OSCORE protected and carries
the information necessary to retrieve the Security Context.

Notes:

"Outer options" should be in the plural, to refer to the set of CoAP options left unencrypted. Such a set comprises also the OSCORE option, which is the actual indicator of the message being protected with OSCORE.

Errata ID: 7396
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF
Reported By: Marco Tiloca
Date Reported: 2023-03-19
Verifier Name: Eric Vyncke
Date Verified: 2023-08-03

Section 7.1 says:

Note that a client located in an Application Server sending a request
to a server located in the Device may not be compressed through this
Rule, since the MID might not start with 7 bits equal to 0.

It should say:

Note that, if a client is located in an Application Server and sends a
request to a server located in the Device, then the request may not be
compressed through this Rule, since the MID might not start with 7 bits
equal to 0.

Notes:

In the old text, "compressed" seems referred to "client" rather than to "request" as intended.

RFC 8843, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", January 2021

Note: This RFC has been obsoleted by RFC 9143

Source of RFC: mmusic (art)

Errata ID: 6431
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: EungRok Lee
Date Reported: 2021-02-16
Verifier Name: Barry Leiba
Date Verified: 2021-02-17

Section 15 says:

A media recipient informs the media sender about the identification-
tag associated with an "m=" section through the use of a 'id'
attribute [RFC5888].

It should say:

A media recipient informs the media sender about the identification-
tag associated with an "m=" section through the use of a 'mid'
attribute [RFC5888].

Notes:

As you can see In section 2. Terminology, Identification-tag is a unique token value that is used to identify an "m=" section. The SDP **'mid'** attribute [RFC5888] in an "m=" section carries the unique identification-tag assigned to that "m=" section. I think the 'm' is missing.

Errata ID: 6437
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: EungRok Lee
Date Reported: 2021-02-23
Verifier Name: Murray Kucherawy
Date Verified: 2021-09-01

Section 9.2 says:

   *  If the packet has a MID, and the packet's extended sequence number
      is greater than that of the last MID update, as discussed in
      [RFC7941], Section 4.2.2, update the MID associated with the RTP
      stream to match the MID carried in the RTP packet, and then update
      the mapping tables to include an entry that maps the SSRC of that
      RTP stream to the "m=" section for that MID.

It should say:

   *  If the packet has a MID, and the packet's extended sequence number
      is greater than that of the last MID update, as discussed in
      [RFC7941], Section 4.2.6, update the MID associated with the RTP
      stream to match the MID carried in the RTP packet, and then update
      the mapping tables to include an entry that maps the SSRC of that
      RTP stream to the "m=" section for that MID.

Notes:

In RFC7941 section "4.2.2. MTU and Packet Expansion", it doesn't mention about extended sequence number of packets. Section "4.2.6. Update Flaps" describes how to update SDES item using extended sequence number.

RFC 8851, "RTP Payload Format Restrictions", January 2021

Source of RFC: mmusic (art)

Errata ID: 7132
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Byron Campen
Date Reported: 2022-09-14
Verifier Name: Murray Kucherawy
Date Verified: 2022-10-13

Section 10 says:

rid-id            = 1*(alpha-numeric / "-" / "_")

It should say:

rid-id            = 1*255(alpha-numeric)

Notes:

The BNF should be consistent with the rules for the RtpStreamId/RepairedRtpStreamId SDES from RFC 8852 section 3:

"As with all SDES items, RtpStreamId and RepairedRtpStreamId are limited to a total of 255 octets in length. RtpStreamId and RepairedRtpStreamId are constrained to contain only alphanumeric characters. For avoidance of doubt, the only allowed byte values for these IDs are decimal 48 through 57, 65 through 90, and 97 through 122."

RFC 8878, "Zstandard Compression and the 'application/zstd' Media Type", February 2021

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 6441
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Felix Handte
Date Reported: 2021-02-25
Verifier Name: Barry Leiba
Date Verified: 2021-03-08

Section Appendix A says:

A.1.  Literals Length Code Table

                +=======+========+================+======+
                | State | Symbol | Number_Of_Bits | Base |
                +=======+========+================+======+
                |   0   |   0    |       0        |  0   |
                +-------+--------+----------------+------+
                |   0   |   0    |       4        |  0   |
                +-------+--------+----------------+------+
[...]

A.2.  Match Length Code Table

                +=======+========+================+======+
                | State | Symbol | Number_Of_Bits | Base |
                +=======+========+================+======+
                |   0   |   0    |       0        |  0   |
                +-------+--------+----------------+------+
                |   0   |   0    |       6        |  0   |
                +-------+--------+----------------+------+

[...]

A.3.  Offset Code Table

                +=======+========+================+======+
                | State | Symbol | Number_Of_Bits | Base |
                +=======+========+================+======+
                |   0   |   0    |       0        |  0   |
                +-------+--------+----------------+------+
                |   0   |   0    |       5        |  0   |
                +-------+--------+----------------+------+

It should say:

A.1.  Literals Length Code Table

                +=======+========+================+======+
                | State | Symbol | Number_Of_Bits | Base |
                +=======+========+================+======+
                |   0   |   0    |       4        |  0   |
                +-------+--------+----------------+------+
[...]

A.2.  Match Length Code Table

                +=======+========+================+======+
                | State | Symbol | Number_Of_Bits | Base |
                +=======+========+================+======+
                |   0   |   0    |       6        |  0   |
                +-------+--------+----------------+------+

[...]

A.3.  Offset Code Table

                +=======+========+================+======+
                | State | Symbol | Number_Of_Bits | Base |
                +=======+========+================+======+
                |   0   |   0    |       5        |  0   |
                +-------+--------+----------------+------+

Notes:

Each of the three tables in Appendix A contain two entries for state 0, the first of which in each case incorrectly reports the Number_Of_Bits as 0. The all-zero rows should be removed.

Errata ID: 6442
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Felix Handte
Date Reported: 2021-02-25
Verifier Name: Barry Leiba
Date Verified: 2021-03-08

Section 3.1.1.5 says:

   The following table shows the values of the Repeated_Offsets as a
   series of sequences are applied to them:

   +=======+==========+===========+===========+===========+============+
   |offset_|literals_ | Repeated_ | Repeated_ | Repeated_ |Comment     |
   | value |  length  |  Offset1  |  Offset2  |  Offset3  |            |
   +=======+==========+===========+===========+===========+============+
   |       |          |     1     |     4     |     8     |starting    |
   |       |          |           |           |           |values      |
   +-------+----------+-----------+-----------+-----------+------------+
   |   1114|    11    |    1111   |     1     |     4     |non-repeat  |
   +-------+----------+-----------+-----------+-----------+------------+
   |      1|    22    |    1111   |     1     |     4     |repeat 1; no|
   |       |          |           |           |           |change      |
   +-------+----------+-----------+-----------+-----------+------------+
   |   2225|    22    |    2222   |    1111   |     1     |non-repeat  |
   +-------+----------+-----------+-----------+-----------+------------+
   |   1114|   111    |    1111   |    2222   |    1111   |non-repeat  |
   +-------+----------+-----------+-----------+-----------+------------+
   |   3336|    33    |    3333   |    1111   |    2222   |non-repeat  |
   +-------+----------+-----------+-----------+-----------+------------+
   |      2|    22    |    1111   |    3333   |    2222   |repeat 2;   |
   |       |          |           |           |           |swap 1 & 2  |
   +-------+----------+-----------+-----------+-----------+------------+
   |      3|    33    |    2222   |    1111   |    3333   |repeat 3;   |
   |       |          |           |           |           |rotate 3 to |
   |       |          |           |           |           |1           |
   +-------+----------+-----------+-----------+-----------+------------+
   |      1|    0     |    2221   |    2222   |    1111   |insert      |
   |       |          |           |           |           |resolved    |
   |       |          |           |           |           |offset      |
   +-------+----------+-----------+-----------+-----------+------------+
   |      1|    0     |    2222   |    2221   |    3333   |repeat 2    |
   +-------+----------+-----------+-----------+-----------+------------+

                         Table 18: Repeated_Offsets

It should say:

   The following table shows the values of the Repeated_Offsets as a
   series of sequences are applied to them:

   +=======+==========+===========+===========+===========+============+
   |offset_|literals_ | Repeated_ | Repeated_ | Repeated_ |Comment     |
   | value |  length  |  Offset1  |  Offset2  |  Offset3  |            |
   +=======+==========+===========+===========+===========+============+
   |       |          |     1     |     4     |     8     |starting    |
   |       |          |           |           |           |values      |
   +-------+----------+-----------+-----------+-----------+------------+
   |   1114|    11    |    1111   |     1     |     4     |non-repeat  |
   +-------+----------+-----------+-----------+-----------+------------+
   |      1|    22    |    1111   |     1     |     4     |repeat 1; no|
   |       |          |           |           |           |change      |
   +-------+----------+-----------+-----------+-----------+------------+
   |   2225|    22    |    2222   |    1111   |     1     |non-repeat  |
   +-------+----------+-----------+-----------+-----------+------------+
   |   1114|   111    |    1111   |    2222   |    1111   |non-repeat  |
   +-------+----------+-----------+-----------+-----------+------------+
   |   3336|    33    |    3333   |    1111   |    2222   |non-repeat  |
   +-------+----------+-----------+-----------+-----------+------------+
   |      2|    22    |    1111   |    3333   |    2222   |repeat 2;   |
   |       |          |           |           |           |swap 1 & 2  |
   +-------+----------+-----------+-----------+-----------+------------+
   |      3|    33    |    2222   |    1111   |    3333   |repeat 3;   |
   |       |          |           |           |           |rotate 3 to |
   |       |          |           |           |           |1           |
   +-------+----------+-----------+-----------+-----------+------------+
   |      3|    0     |    2221   |    2222   |    1111   |insert      |
   |       |          |           |           |           |resolved    |
   |       |          |           |           |           |offset      |
   +-------+----------+-----------+-----------+-----------+------------+
   |      1|    0     |    2222   |    2221   |    3333   |repeat 2    |
   +-------+----------+-----------+-----------+-----------+------------+

                         Table 18: Repeated_Offsets

Notes:

The offset_value in the second-to-last line in the table should be 3, not 1. This line intends to demonstrate the property described earlier in the section that when the sequence's literals_length is 0, an offset_value of 3 resolves to Repeated_Offset1 - 1 and is inserted at the head of the Repeated_Offsets. This is the behavior that is reflected in the rest of the row, which an offset_value of 1 would not trigger (the resolved offset would be 2222, not 2221, and the Repeated_Offsets would remain unchanged, as demonstrated in the 3rd row of the table).

(I wrote this table and it read 3 in the version I provided to the document authors--a typo was introduced somewhere.)

RFC 8881, "Network File System (NFS) Version 4 Minor Version 1 Protocol", August 2020

Source of RFC: nfsv4 (wit)

Errata ID: 7324
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: YangJing
Date Reported: 2023-01-29
Verifier Name: RFC Editor
Date Verified: 2023-01-30

Section 4.2.3 says:

   FH4_VOL_RENAME  The filehandle will expire during rename.  This
      includes a rename by the requesting client or a rename by any
      other client.  If FH4_VOL_ANY is set, FH4_VOL_RENAME is redundant.

It should say:

   FH4_VOL_RENAME  The filehandle will expire during rename.  This
      includes a rename by the requesting client or a rename by any
      other client.  If FH4_VOLATILE_ANY is set, FH4_VOL_RENAME
      is redundant.

Notes:

FH4_VOL_ANY is not defined in this document. It should be FH4_VOLATILE_ANY

RFC 8886, "Secure Device Install", September 2020

Source of RFC: opsawg (ops)

Errata ID: 6298
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Stéphane Bortzmeyer
Date Reported: 2020-10-05
Verifier Name: Robert Wilton
Date Verified: 2024-01-12

Section A.1.1 says:

openssl ecparam -out privatekey.key -name prime256v1 -genkey

It should say:

openssl ecparam -out key.pem -name prime256v1 -genkey

Notes:

The rest of the appendix expects the name key.pem.

Errata ID: 6300
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Stéphane Bortzmeyer
Date Reported: 2020-10-05
Verifier Name: Robert Wilton
Date Verified: 2024-01-12

Section A.3.2 says:

   $ openssl smime -decrypt -in SN19842256.enc -inform pkcs7\
      -out config.cfg -inkey key.pem

It should say:

   $ openssl smime -decrypt -in SN19842256.enc -inform PEM\
      -out config.cfg -inkey key.pem

Notes:

Otherwise, OpenSSL fails with:

smime: Invalid format "pkcs7" for -inform
smime: Use -help for summary.

RFC 8894, "Simple Certificate Enrolment Protocol", September 2020

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 6372
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Russ Housley
Date Reported: 2020-12-28
Verifier Name: Roman Danyliw
Date Verified: 2022-01-19

Section 3.3.3 says:

   The messageData for this type consists of an
   IssuerAndSubject:

   issuerAndSubject ::= SEQUENCE {
       issuer     Name,
       subject    Name
       }

It should say:

   The messageData for this type consists of an
   IssuerAndSubject:

   IssuerAndSubject ::= SEQUENCE {
       issuer     Name,
       subject    Name
       }

Notes:

For the ASN.1 to compile properly, the definition must begin with a capital letter.

RFC 8906, "A Common Operational Problem in DNS Servers: Failure to Communicate", September 2020

Source of RFC: dnsop (ops)

Errata ID: 6783
Status: Verified
Type: Editorial
Publication Format(s) : HTML
Reported By: Mukund Sivaraman
Date Reported: 2021-12-14
Verifier Name: RFC Editor
Date Verified: 2021-12-14

Section 8.2.3 says:

as unknown EDNS options are supposed to be ignored by the
   server (Section 6.1.1 of [RFC6891]).

It should say:

as unknown EDNS options are supposed to be ignored by the
   server (Section 6.1.2 of [RFC6891]).

Notes:

Reference to the section in RFC 6891 is incorrect. There's no information on what to do with unknown options in RFC 6891 section 6.1.1.

RFC 8910, "Captive-Portal Identification in DHCP and Router Advertisements (RAs)", September 2020

Source of RFC: capport (art)

Errata ID: 6620
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Vittorio Gambaletta (VittGam)
Date Reported: 2021-06-23
Verifier Name: Erik Kline
Date Verified: 2021-06-24

Section 2 says:

   A captive portal MAY do content negotiation (Section 3.4 of
   [RFC7231]) and attempt to redirect clients querying without an
   explicit indication of support for the captive portal API content
   type (i.e., without application/capport+json listed explicitly
   anywhere within an Accept header field as described in Section 5.3 of
   [RFC7231]).  In so doing, the captive portal SHOULD redirect the
   client to the value associated with the "user-portal-url" API key.
   When performing such content negotiation (Section 3.4 of [RFC7231]),
   implementors of captive portals need to keep in mind that such
   responses might be cached, and therefore SHOULD include an
   appropriate Vary header field (Section 7.1.4 of [RFC7231]) or set the
   Cache-Control header field in any responses to "private" or a more
   restrictive value such as "no-store" (Section 5.2.2.3 of [RFC7234]).

It should say:

   A captive portal MAY do content negotiation (Section 3.4 of
   [RFC7231]) and attempt to redirect clients querying without an
   explicit indication of support for the captive portal API content
   type (i.e., without application/captive+json listed explicitly
   anywhere within an Accept header field as described in Section 5.3 of
   [RFC7231]).  In so doing, the captive portal SHOULD redirect the
   client to the value associated with the "user-portal-url" API key.
   When performing such content negotiation (Section 3.4 of [RFC7231]),
   implementors of captive portals need to keep in mind that such
   responses might be cached, and therefore SHOULD include an
   appropriate Vary header field (Section 7.1.4 of [RFC7231]) or set the
   Cache-Control header field in any responses to "private" or a more
   restrictive value such as "no-store" (Section 5.2.2.3 of [RFC7234]).

Notes:

In RFC8908 the relevant Content-Type is defined as "application/captive+json" and not "application/capport+json".

RFC 8912, "Initial Performance Metrics Registry Entries", November 2021

Source of RFC: ippm (ops)

Errata ID: 6758
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Nikolai Malykh
Date Reported: 2021-11-28
Verifier Name: Martin Duke
Date Verified: 2021-12-01

Section 4.4.2 says:

   Percent_LossRatio:  The numeric value of the result is expressed in
      units of lost packets to total packets times 100%, as a positive
      value of type decimal64 with fraction digits = 9 (see Section 9.3
      of [RFC6020]) with a resolution of 0.0000000001.

It should say:

   Percent_LossRatio:  The numeric value of the result is expressed in
      units of lost packets to total packets times 100%, as a positive
      value of type decimal64 with fraction digits = 9 (see Section 9.3
      of [RFC6020]) with a resolution of 0.000000001.

Notes:

An extra 0 in the value of the resolution of the loss ratio.

The error is repeated in sections 7.4.2.6, 8.4.2.6, 9.4.2.4

RFC 8956, "Dissemination of Flow Specification Rules for IPv6", December 2020

Source of RFC: idr (rtg)

Errata ID: 7571
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Pawel Foremski
Date Reported: 2023-07-24
Verifier Name: John Scudder
Date Verified: 2024-01-12

Section 3.8.1 says:

+======+======================+=========================+==========+
| len  | destination          | source                  | ul-proto |
+======+======================+=========================+==========+
| 0x12 | 01 20 00 20 01 0d bb | 02 68 40 12 34 56 78 9a | 03 81 06 |
+------+----------------------+-------------------------+----------+
                                 Table 1

It should say:

+======+======================+=========================+==========+
| len  | destination          | source                  | ul-proto |
+======+======================+=========================+==========+
| 0x12 | 01 20 00 20 01 0d b8 | 02 68 40 12 34 56 78 9a | 03 81 06 |
+------+----------------------+-------------------------+----------+
                                 Table 1

Notes:

The last byte in the "destination" column of Table 1 in 3.8.1 should be "b8", not "bb".

RFC 8963, "Evaluation of a Sample of RFCs Produced in 2018", January 2021

Source of RFC: INDEPENDENT

Errata ID: 6407
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Julian Reschke
Date Reported: 2021-01-22
Verifier Name: Adrian Farrel
Date Verified: 2021-01-23

Section 3.5 says:

   Comparing the final draft and published RFC shows a minor set of copy
   edits, mostly for style.  However, the author recalls a painful
   process.  The RFC includes many charts and graphs that were very
   difficult to format correctly in the author's production process that
   involved conversions from markdown to XML, and then from XML to text.
   The author had to get substantial help from the RFC Editor.

It should say:

   Comparing the final draft and published RFC shows a minor set of copy
   edits, mostly for style.  However, the author recalls a painful
   process.  The RFC includes a ladder diagram that the author found
   difficult to format correctly in the author's production process that
   involved conversions from markdown to XML, and then from XML to text.
   The author recalls getting substantial help from the RFC Editor.

Notes:

The RFC actually does not contain any graphs or charts. The only piece of artwork is in an HTTP message exchange (in Section 5.1 of RFC 8441).

RFC 8969, "A Framework for Automating Service and Network Management with YANG", January 2021

Source of RFC: opsawg (ops)

Errata ID: 6904
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Mohamed Boucadair
Date Reported: 2022-03-30
Verifier Name: RFC Editor
Date Verified: 2022-03-30

Section A.3 says:

     +-------------------------------+-------------------------------+
     |      Topology YANG modules    |     Tunnel YANG modules       |
     +-------------------------------+-------------------------------+
     |  +------------------+         |                               |
     |  |Network Topologies|         | +------+  +-----------+       |
     |  |       Model      |         | |Other |  | TE Tunnel |       |
     |  +--------+---------+         | |Tunnel|  +----+------+       |
     |           |   +---------+     | +------+       |              |
     |           +---+Service  |     |     +----------+---------+    |
     |           |   |Topology |     |     |          |         |    |
     |           |   +---------+     |     |          |         |    |
     |           |   +---------+     |+----+---+ +----+---+ +---+---+|
     |           +---+Layer 3  |     ||MPLS-TE | |RSVP-TE | | SR-TE ||
     |           |   |Topology |     || Tunnel | | Tunnel | |Tunnel ||
     |           |   +---------+     |+--------+ +--------+ +-------+|
     |           |   +---------+     |                               |
     |           +---+TE       |     |                               |
     |           |   |Topology |     |                               |
     |           |   +---------+     |                               |
     |           |   +---------+     |                               |
     |           +---+Layer 3  |     |                               |
     |               |Topology |     |                               |
     |               +---------+     |                               |
     +-------------------------------+-------------------------------+

It should say:

     +-------------------------------+-------------------------------+
     |      Topology YANG modules    |     Tunnel YANG modules       |
     +-------------------------------+-------------------------------+
     |  +------------------+         |                               |
     |  |Network Topologies|         | +------+  +-----------+       |
     |  |       Model      |         | |Other |  | TE Tunnel |       |
     |  +--------+---------+         | |Tunnel|  +----+------+       |
     |           |   +---------+     | +------+       |              |
     |           +---+Service  |     |     +----------+---------+    |
     |           |   |Topology |     |     |          |         |    |
     |           |   +---------+     |     |          |         |    |
     |           |   +---------+     |+----+---+ +----+---+ +---+---+|
     |           +---+Layer 3  |     ||MPLS-TE | |RSVP-TE | | SR-TE ||
     |           |   |Topology |     || Tunnel | | Tunnel | |Tunnel ||
     |           |   +---------+     |+--------+ +--------+ +-------+|
     |           |   +---------+     |                               |
     |           +---+TE       |     |                               |
     |           |   |Topology |     |                               |
     |           |   +---------+     |                               |
     |           |   +---------+     |                               |
     |           +---+Layer 2  |     |                               |
     |               |Topology |     |                               |
     |               +---------+     |                               |
     +-------------------------------+-------------------------------+

Notes:

"Layer 3 Topology" is cited twice. "Layer 2 Topology" is missing as per the text right after Figure 9.

RFC 8971, "Bidirectional Forwarding Detection (BFD) for Virtual eXtensible Local Area Network (VXLAN)", December 2020

Source of RFC: bfd (rtg)

Errata ID: 6427
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Donald E. Eastlake, III
Date Reported: 2021-02-13
Verifier Name: Martin Vigoureux
Date Verified: 2021-03-02

Throughout the document, when it says:

00-52-02

It should say:

00-00-0E-00-52-02

Notes:

This is a 48-bit unicast MAC address. It starts with the IANA OUI ("00-00-0E"). There are two instances that should be corrected if this document is revised or replaced. But I don't think this fix is worth re-issuing the document. If someone one looks this up in the IANA assignment table, it says there that the unicast numbers all actually start with 00-00-0E.

RFC 8984, "JSCalendar: A JSON Representation of Calendar Data", July 2021

Source of RFC: calext (art)

Errata ID: 6872
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Robert Stepanek
Date Reported: 2022-03-07
Verifier Name: Francesca Palombini
Date Verified: 2022-03-20

Section 4.4.3. says:

   "private":  The details of the object are hidden; only the basic time
      and metadata are shared.  The following properties MAY be shared;
      any other properties MUST NOT be shared:

      *  @type

      *  created

      *  due

      *  duration

      *  estimatedDuration

      *  freeBusyStatus

      *  privacy

      *  recurrenceOverrides (Only patches that apply to another
         permissible property are allowed to be shared.)

      *  sequence

      *  showWithoutTime

      *  start

      *  timeZone

      *  timeZones

      *  uid

      *  updated

It should say:

   "private":  The details of the object are hidden; only the basic time
      and metadata are shared.  The following properties MAY be shared;
      any other properties MUST NOT be shared:
 
      *  @type
 
      *  created
 
      *  due
 
      *  duration
 
      *  estimatedDuration
 
      *  excluded
 
      *  excludedRecurrenceRules
 
      *  freeBusyStatus
 
      *  privacy
 
      *  recurrenceId
 
      *  recurrenceIdTimeZone
 
      *  recurrenceOverrides (Only patches that apply to another
         permissible property are allowed to be shared.)
 
      *  recurrenceRules
 
      *  sequence
 
      *  showWithoutTime
 
      *  start
 
      *  timeZone
 
      *  timeZones
 
      *  uid
 
      *  updated

Notes:

Adds the excluded, excludedRecurrenceRules, recurrenceId, recurrenceIdTimeZone and recurrenceRules properties to the list of shared properties of private events.

Only the combination of all recurrence properties allows to generate the full recurrence set for the event.

Omitting the properties was an oversight during the initial publication of this RFC.

Errata ID: 6873
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Robert Stepanek
Date Reported: 2022-03-07
Verifier Name: Francesca Palombini
Date Verified: 2022-03-20

Section 4.3.2. says:

Identifies the time zone of the main JSCalendar object, of which this
JSCalendar object is a recurrence instance.  This property MUST be
set if the "recurrenceId" property is set.  It MUST NOT be set if the
"recurrenceId" property is not set.

It should say:

Identifies the time zone of the main JSCalendar object, of which this
JSCalendar object is a recurrence instance.  It MUST NOT be set if the
"recurrenceId" property is not set.

Notes:

A recurrence instance may be in floating time, in which case the value of the "recurrenceIdTimeZone" property is null. As null is the default value of the "recurrenceIdTimeZone" property, it is NOT required to be set if "recurrenceId" is set.

RFC 8986, "Segment Routing over IPv6 (SRv6) Network Programming", February 2021

Source of RFC: spring (rtg)

Errata ID: 6809
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Yuya Kawakami
Date Reported: 2022-01-05
Verifier Name: Andrew Alston
Date Verified: 2022-05-26

Section 4.10 says:

When N receives a packet whose IPv6 DA is S and S is a local End.DX2
SID

It should say:

When N receives a packet whose IPv6 DA is S and S is a local End.DX2V
SID

Notes:

Looks like a typo in the original text

RFC 8992, "Autonomic IPv6 Edge Prefix Management in Large-Scale Networks", May 2021

Source of RFC: anima (ops)

Errata ID: 6591
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Brian Carpenter
Date Reported: 2021-05-25
Verifier Name: Rob Wilton
Date Verified: 2021-06-08

Section 6 says:

objective = ["PrefixManager.Params", objective-flags, any]

It should say:

objective = ["PrefixManager.Params", objective-flags, loop-count, any]

Notes:

Clarifying an omission in the original. All GRASP Objective Options must include a loop-count as required by the format defined in section 2.10 of RFC 8990.

RFC 8994, "An Autonomic Control Plane (ACP)", May 2021

Source of RFC: anima (ops)

Errata ID: 7071
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Corey Bonnell
Date Reported: 2022-08-04
Verifier Name: Rob Wilton
Date Verified: 2024-01-15

Section 6.2.2 says:

   The acp-node-name in Figure 2 is the ABNF definition ("Augmented BNF
   for Syntax Specifications: ABNF" [RFC5234]) of the ACP Node Name.  An
   ACP certificate MUST carry this information.  It MUST contain an
   otherName field in the X.509 Subject Alternative Name extension, and
   the otherName MUST contain an AcpNodeName as described in
   Section 6.2.2.

It should say:

   The acp-node-name in Figure 2 is the ABNF definition ("Augmented BNF
   for Syntax Specifications: ABNF" [RFC5234]) of the ACP Node Name.  An
   ACP certificate MUST carry this information.  It MUST contain an
   otherName field in the X.509 Subject Alternative Name extension, and
   the otherName MUST contain an AcpNodeName as described in
   Section 6.2.2.1.

Notes:

David von Oheimb discovered [1] that section 6.2.2 is self-referential and incorrect regarding the section reference to the ASN.1 module.

The correct section number is 6.2.2.1.

[1] https://mailarchive.ietf.org/arch/msg/spasm/-ymZk94KFzzolZSsJh6HONnypXQ/

RFC 8995, "Bootstrapping Remote Secure Key Infrastructure (BRSKI)", May 2021

Source of RFC: anima (ops)

Errata ID: 6716
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Max Pritikin
Date Reported: 2021-10-19
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2021-10-19

Section 5.8.3 says:

A registrar MAY be configured to ignore (i.e., override
the above policy) the history of the device, but it is RECOMMENDED
that this only be configured if hardware-assisted (i.e., Transport
Performance Metrics (TPM) anchored) Network Endpoint Assessment (NEA)
[RFC5209] is supported.

It should say:

A registrar MAY be configured to ignore (i.e., override
the above policy) the history of the device, but it is RECOMMENDED
that this only be configured if hardware-assisted (i.e., Trusted 
Platform Module (TPM) anchored) Network Endpoint Assessment (NEA)
 [RFC5209] is supported.

Notes:

The logical expansion of 'TPM' in this parenthetical example is the Trusted Platform Module.

Errata ID: 6834
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Esko Dijk
Date Reported: 2022-02-03
Verifier Name: Rob Wilton
Date Verified: 2024-01-15

Section 8.5 says:

   *  version

   *  Status

   *  Reason

   *  reason-context

It should say:

   *  version

   *  status

   *  reason

   *  reason-context

Notes:

The CDDL models in section 5.7 and 5.9.4 define the key values with lowercase first character; and the examples in those sections use the same. It seems that during final editing it was forgotten to update Section 8.5.

Errata ID: 7576
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Michael Richardson
Date Reported: 2023-07-26
Verifier Name: Rob Wilton
Date Verified: 2023-11-09

Section 4.3 says:

   objective-value = text       ; name of the (list of) supported
                                ; protocols: "EST-TLS" for RFC 7030.

It should say:

   objective-value = text       ; name of the supported protocol,
                                ; e.g., "EST-TLS" for RFC 7030.

Notes:

This objective does not support a list of supported protocols.
The comment in the example might lead people to conclude they can do that.

Errata ID: 6736
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, HTML
Reported By: Michael Richardson
Date Reported: 2021-11-13
Verifier Name: RFC Editor
Date Verified: 2022-01-27

Section 5.5 says:

MASA implementations SHOULD anticipate future media ntypes but, 
of course, will simply fail the request if those types are not 
yet known.

It should say:

MASA implementations SHOULD anticipate future media types but, 
of course, will simply fail the request if those types are not 
yet known.

Notes:

"ntypes" is not a word

RFC 8996, "Deprecating TLS 1.0 and TLS 1.1", March 2021

Source of RFC: tls (sec)

Errata ID: 7103
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Martin Thomson
Date Reported: 2022-08-24
Verifier Name: Paul Wouters
Date Verified: 2024-01-17

Throughout the document, when it says:

<a href="https://www.rfc-editor.org/rfc/rfc%E2%80%8B%204162"
class="eref">​ 4162</a>

It should say:

<a href="https://www.rfc-editor.org/rfc/rfc4162"
class="eref">​4162</a>

Notes:

(Note: the line wrapping here is mine; the errata tool assumes that this is text, so it won't accept long lines.)

The text for this specification is OK, but the HTML rendering has some hard-to-notice errors in the "Updates" field in the metadata block that is being caused by errors in the XML source.

The XML source includes a number of Unicode zero width space characters (U+200B) after commas in the rfc@updates attribute. xml2rfc is unable to handle these characters correctly, treating them - and the space that follows - as part of the RFC number. It generates the bad link as you see above.

This can be addressed in xml2rfc, maybe, but this is probably not XML we want to permit.

Paul Wouters (AD): Verified, as this RFC won't get any updates.

Errata ID: 7796
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Gaëtan Leurent
Date Reported: 2024-02-03
Verifier Name: RFC Editor
Date Verified: 2024-02-05

Section 10.2 says:

[Bhargavan2016] Bhargavan, K. and G. Leuren,

It should say:

[Bhargavan2016] Bhargavan, K. and G. Leurent,

Notes:

The last name "Leurent" is misspelt is the references.

RFC 9000, "QUIC: A UDP-Based Multiplexed and Secure Transport", May 2021

Source of RFC: quic (wit)

Errata ID: 6811
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Martin Thomson
Date Reported: 2022-01-06
Verifier Name: Zaheduzzaman Sarker
Date Verified: 2022-02-18

Section 5.1.1 says:

                                         The sequence number of the
   initial connection ID is 0.  If the preferred_address transport
   parameter is sent, the sequence number of the supplied connection ID
   is 1.

   Additional connection IDs are communicated to the peer using
   NEW_CONNECTION_ID frames (Section 19.15).  The sequence number on
   each newly issued connection ID MUST increase by 1.  

It should say:

                                         The sequence number of the
   initial connection ID is 0.  If the preferred_address transport
   parameter is sent, the sequence number of the supplied connection ID
   is 1.  The sequence number for NEW_CONNECTION_ID frames starts at 2
   when the preferred_address transport parameter is sent and 1
   otherwise.

   Additional connection IDs are communicated to the peer using
   NEW_CONNECTION_ID frames (Section 19.15).  The sequence number on
   each newly issued connection ID MUST increase by 1.

Notes:

It is not sufficiently clear that the (implied) sequence number for the preferred_address transport parameter is taken from the sequence only when the transport parameter is present.

The original text might be read to imply that the first NEW_CONNECTION_ID frame always starts with 2, though maybe only at a server. The proposed addition is much more explicit.

RFC 9002, "QUIC Loss Detection and Congestion Control", May 2021

Source of RFC: quic (wit)

Errata ID: 7539
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Sergey Kandaurov
Date Reported: 2023-06-07
Verifier Name: Zaheduzzaman Sarker
Date Verified: 2023-06-13

Section 5. says:

smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * adjusted_rtt
rttvar_sample = abs(smoothed_rtt - adjusted_rtt)
rttvar = 3/4 * rttvar + 1/4 * rttvar_sample

It should say:

rttvar_sample = abs(smoothed_rtt - adjusted_rtt)
rttvar = 3/4 * rttvar + 1/4 * rttvar_sample
smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * adjusted_rtt

Notes:

Per Appendix A.7 of this RFC and Section 2 of the referred RFC 6298,
rttvar should be computed before updating smoothed_rtt itself.

RFC 9008, "Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data Plane", April 2021

Source of RFC: roll (rtg)

Errata ID: 7543
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Mathis Marion
Date Reported: 2023-06-14
Verifier Name: John Scudder
Date Verified: 2024-01-12

Section 6 says:

As the Rank information in the RPI artifact is changed at each hop, it
will typically be zero when it arrives at the DODAG root.

It should say:

As the Rank information in the RPI artifact is changed at each hop, it
will typically be non-zero when it arrives at the DODAG root.

Notes:

The SenderRank is 0 if:
- The packet comes from Internet (and has an RPI)
- The packet has not been forwarded (ie. if the source is a direct child of the DODAG root), as RFC 6550 section 11.2 tells to set SenderRank to 0 at the source.

The typical case is rather a packet that arrives at the DODAG root from a child node forwarding a packet, in which case SenderRank is set to DAGRank(rank) > 0.

Errata ID: 6557
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Pascal Thubert
Date Reported: 2021-04-23
Verifier Name: Alvaro Retana
Date Verified: 2021-04-23

Section 11.1 says:

DODAG Configuration Option Flag to Indicate the RPI Flag Day

It should say:

DODAG Configuration Option Flag to Set the Value of the RPI Option Type 

Notes:

The point of the new flag is to avoid a flag day.

This text is as the name for Tables 1 and 26 on sections 4.1.3 and 11.1, respectively.

RFC 9010, "Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) Leaves", April 2021

Source of RFC: roll (rtg)

Errata ID: 6556
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Nikolai Malykh
Date Reported: 2021-04-23
Verifier Name: Alvaro Retana
Date Verified: 2021-04-23

Section 4.1 says:

   [RFC6775] also introduces the Address Registration Option (ARO),
   which is carried in the unicast Neighbor Solicitation (NS) and
   Neighbor Advertisement (NA) messages between the 6LoWPAN Node (6LN)
   and the 6LoWPAN router (6LR).  It also defines the Duplicate Address
   Request (DAR) and Duplicate Address Confirmation (DAC) messages
   between the 6LR and the 6LBR).  In an LLN, the 6LBR is the central
   repository of all the Registered Addresses in its domain and the
   source of truth for uniqueness and ownership.

It should say:

   [RFC6775] also introduces the Address Registration Option (ARO),
   which is carried in the unicast Neighbor Solicitation (NS) and
   Neighbor Advertisement (NA) messages between the 6LoWPAN Node (6LN)
   and the 6LoWPAN router (6LR).  It also defines the Duplicate Address
   Request (DAR) and Duplicate Address Confirmation (DAC) messages
   between the 6LR and the 6LBR.  In an LLN, the 6LBR is the central
   repository of all the Registered Addresses in its domain and the
   source of truth for uniqueness and ownership.

Notes:

Extra closing parenthesis

RFC 9013, "OSPF Advertisement of Tunnel Encapsulations", April 2021

Source of RFC: ospf (rtg)

Errata ID: 6576
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Sabrina Tanamal
Date Reported: 2021-05-07
Verifier Name: RFC Editor

Section 7.2 says:

| 3           | Endpoint             | RFC 9013            |

It should say:

| 3           | Tunnel Egress Endpoint| RFC 9013           |
 

Notes:

The description of value 3 should have been updated to match updates throughout the text.

[verified by the RFC Editor per discussion with the authors]

RFC 9022, "Domain Name Registration Data (DNRD) Objects Mapping", May 2021

Source of RFC: regext (art)

Errata ID: 7566
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Daniel McCarron
Date Reported: 2023-07-18
Verifier Name: RFC Editor
Date Verified: 2023-07-19

Section 4.6.3-1 says:

When the internalized form ("int") is provided

It should say:

When the internationalized form ("int") is provided

Notes:

I believe the word "internalized" should be "internationalized", as it is elsewhere in the section when referring to "int".

RFC 9051, "Internet Message Access Protocol (IMAP) - Version 4rev2", August 2021

Source of RFC: extra (art)

Errata ID: 7323
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Nicholas Evans
Date Reported: 2023-01-26
Verifier Name: Murray Kucherawy
Date Verified: 2023-07-28

Section 6.4.4.4. says:

        S: B283 NO [BADCHARSET UTF-8] KOI8-R is not supported

It should say:

        S: B283 NO [BADCHARSET (KOI8-R)] KOI8-R is not supported

Notes:

The BADCHARSET response code is described in 7.1 as "Optionally followed by a parenthesized list of charsets", and in the formal syntax as:

resp-text-code =/ "BADCHARSET" [SP "(" charset *(SP charset) ")" ]

Although a client's parser might use a generic resp-text-code (atom [SP 1*<any TEXT-CHAR except "]">]) as a fallback, the server should parenthesize even when only one charset is sent.

RFC 9073, "Event Publishing Extensions to iCalendar", August 2021

Source of RFC: calext (art)

Errata ID: 6829
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Ken Murchison
Date Reported: 2022-02-02
Verifier Name: Francesca Palombini
Date Verified: 2022-11-23

Section 7.1 says:

      partprop     = *(
                     ;
                     ; The following are REQUIRED
                     ; but MUST NOT occur more than once.
                     ;
                     participanttype / uid /
                     ;
                     ; The following are OPTIONAL
                     ; but MUST NOT occur more than once.
                     ;
                     calendaraddress / created / description / dtstamp /
                     geo / last-mod / priority / seq /
                     status / summary / url /
                     ;
                     ; The following are OPTIONAL
                     ; and MAY occur more than once.
                     ;
                     attach / categories / comment
                     contact / location / rstatus / related /
                     resources / strucloc / strucres /
                     styleddescription / sdataprop / iana-prop
                     ;
                     )

It should say:

      partprop     = *(
                     ;
                     ; The following are REQUIRED
                     ; but MUST NOT occur more than once.
                     ;
                     participanttype / uid /
                     ;
                     ; The following are OPTIONAL
                     ; but MUST NOT occur more than once.
                     ;
                     calendaraddress / created / description / dtstamp /
                     geo / last-mod / priority / seq /
                     status / summary / url /
                     ;
                     ; The following are OPTIONAL
                     ; and MAY occur more than once.
                     ;
                     attach / categories / comment
                     contact / location / rstatus / related /
                     resources /
                     styleddescription / sdataprop / iana-prop
                     ;
                     )

Notes:

'structloc' and 'structres' are not defined in this document. These are leftover artifacts from a draft version of this specification and were replaced by 'locationc' and 'resourcec'

Errata ID: 7381
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Olaf Bartelt
Date Reported: 2023-03-09
Verifier Name: Francesca Palombini
Date Verified: 2023-11-09

Section 7.2 says:

   Format Definition:  This component is defined by the following
      notation:

      locationc    = "BEGIN" ":" "VLOCATION" CRLF
                     locprop
                     "END" ":" "VLOCATION" CRLF

      locprop      = *(
                     ;
                     ; The following are REQUIRED
                     ; but MUST NOT occur more than once.
                     ;
                     uid /
                     ;
                     ; The following are OPTIONAL
                     ; but MUST NOT occur more than once.
                     ;
                     description / geo / loctype / name
                     ;
                     ; The following are OPTIONAL
                     ; and MAY occur more than once.
                     ;
                     sdataprop / iana-prop
                  )

It should say:

   Format Definition:  This component is defined by the following
      notation:

      locationc    = "BEGIN" ":" "VLOCATION" CRLF
                     locprop
                     "END" ":" "VLOCATION" CRLF

      locprop      = *(
                     ;
                     ; The following are REQUIRED
                     ; but MUST NOT occur more than once.
                     ;
                     uid /
                     ;
                     ; The following are OPTIONAL
                     ; but MUST NOT occur more than once.
                     ;
                     description / geo / loctype / name / url /
                     ;
                     ; The following are OPTIONAL
                     ; and MAY occur more than once.
                     ;
                     sdataprop / iana-prop
                  )

Notes:

The url property is missing or the specification clahes with RFC 9074, where in section 8.2 in the example it reads:

BEGIN:VLOCATION
UID:123456-abcdef-98765432
NAME:Office
URL:geo:40.443,-79.945;u=10
END:VLOCATION

Either "geo" was intended as a geo uri as defined in RFC 5870 (instead of the geographic position from RFC 2445/5545) or "url" should be added as a valid property (or RFC 9074 is wrong).

--

Verifier's notes: A "/" was missing after "name" and was added after "url" in this same errata.

RFC 9083, "JSON Responses for the Registration Data Access Protocol (RDAP)", June 2021

Source of RFC: regext (art)

Errata ID: 7094
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Scott Hollenbeck
Date Reported: 2022-08-17
Verifier Name: Murray Kucherawy
Date Verified: 2022-11-29

Section 2.1 says:

If The Registry of the Moon desires to express information not found
in this specification, it might select "lunarNIC" as its identifying
prefix and insert, as an example, the member named
"lunarNIC_beforeOneSmallStep" to signify registrations occurring
before the first moon landing and the member named
"lunarNIC_harshMistressNotes" that contains other descriptive text.

Consider the following JSON response with JSON names, some of which
should be ignored by clients without knowledge of their meaning.

{
  "handle" : "ABC123",
  "lunarNIC_beforeOneSmallStep" : "TRUE THAT!",
  "remarks" :
  [
    {
      "description" :
      [
        "She sells sea shells down by the sea shore.",
        "Originally written by Terry Sullivan."
      ]
    }
  ],
  "lunarNIC_harshMistressNotes" :
  [
    "In space,",
    "nobody can hear you scream."
  ]
}
Figure 2

It should say:

If The Registry of the Moon desires to express information not found
in this specification, it might select "lunarNIC_level_0" as its
identifying prefix and insert, as an example, the member named
"lunarNIC_level_0_beforeOneSmallStep" to signify registrations occurring
before the first moon landing and the member named
"lunarNIC_level_0_harshMistressNotes" that contains other descriptive
text.

Consider the following JSON response with JSON names, some of which
should be ignored by clients without knowledge of their meaning.

{
  "handle" : "ABC123",
  "lunarNIC_level_0_beforeOneSmallStep" : "TRUE THAT!",
  "remarks" :
  [
    {
      "description" :
      [
        "She sells sea shells down by the sea shore.",
        "Originally written by Terry Sullivan."
      ]
    }
  ],
  "lunarNIC_level_0_harshMistressNotes" :
  [
    "In space,",
    "nobody can hear you scream."
  ]
}
Figure 2

Notes:

The original text uses the string identifier "lunarNIC" as the prefix for an example extension. This is inconsistent with the example given in Section 4.1, where "lunarNIC_level_0" is used as an example of a registered identifier for an RDAP extension. This inconsistency can lead implementers to believe that the registered identifier and the extension prefix can be inconsistent, when the intent of the specification is that they should be consistent. This inconsistency can cause significant misunderstanding of the technical specification and might result in faulty implementations if not corrected. Changing the examples in Section 2.1 aligns the text with the example in Section 4.1, demonstrating that the extension prefix and the registered identifier should be one and the same.

RFC 9085, "Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing", August 2021

Note: This RFC has been updated by RFC 9356

Source of RFC: idr (rtg)

Errata ID: 7736
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Ketan Talaulikar
Date Reported: 2023-12-20
Verifier Name: John Scudder
Date Verified: 2024-01-16

Section 2.3.5 says:

   A Prefix NLRI, that has been advertised with a Range TLV, is
   considered a normal routing prefix (i.e., prefix reachability) only
   when there is also an IGP metric TLV (TLV 1095) associated it.
   Otherwise, it is considered only as the first prefix in the range for
   prefix-to-SID mapping advertisement.

It should say:

   A Prefix NLRI, that has been advertised with a Range TLV, is
   considered a normal routing prefix (i.e., prefix reachability) only
   when there is also a Prefix Metric TLV (TLV 1155) associated with it.
   Otherwise, it is considered only as the first prefix in the range for
   prefix-to-SID mapping advertisement.

Notes:

The current text is referring to the wrong BGP-LS TLV. Since the Range TLV is associated with a Prefix NLRI, the "Prefix Metric TLV (TLV 1155)" should be referenced here since the "IGP metric TLV (TLV 1095)" is associated with a Link NLRI.

Verifier note: in addition to the fix proposed by Ketan, I added a preposition: "associated with it", and corrected an indefinite article: "a Prefix".

Errata ID: 7734
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Alexandru Bran
Date Reported: 2023-12-18
Verifier Name: John Scudder
Date Verified: 2024-01-12

Section 2.3.5 says:

11 or 12 octets depending on the label or index encoding of the SID.

It should say:

15 or 16 octets depending on the label or index encoding of the SID.

Notes:

Length of the TLV does not account for the Prefix-SID Sub-TLVs type and length fields: 2 octets each = 4 octets in total.
This is valid for all variants: IS-IS, OSPFv2 and OSPFv3.

Note: see also https://mailarchive.ietf.org/arch/msg/idr/G_3KN-XXqyXbSXO1doiNJbK_gIA/

Errata ID: 6666
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Ketan Talaulikar
Date Reported: 2021-08-27
Verifier Name: Alvaro Retana
Date Verified: 2021-09-03

Section 2.3.1 says:

   Flags:  1-octet value that should be set as:

      *  IS-IS Prefix-SID flags as defined in Section 2.1.1 of
         [RFC8667].

      *  OSPFv2 Prefix-SID flags as defined in Section 5 of [RFC8665].

      *  OSPFv3 Prefix-SID flags as defined in Section 6 of [RFC8665].

It should say:

   Flags:  1-octet value that should be set as:

      *  IS-IS Prefix-SID flags as defined in Section 2.1.1 of
         [RFC8667].

      *  OSPFv2 Prefix-SID flags as defined in Section 5 of [RFC8665].

      *  OSPFv3 Prefix-SID flags as defined in Section 6 of [RFC8666].

Notes:

The reference to the OSPFv3 spec in the text above needs to be corrected to RFC8666 instead of RFC8665.

This editorial error seems to have crept in during the RFC publication process. The draft version submitted by the WG and reviewed by the IESG has the correct text : https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-segment-routing-ext-18#section-2.3.1

RFC 9102, "TLS DNSSEC Chain Extension", August 2021

Source of RFC: INDEPENDENT

Errata ID: 6860
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Shumon Huque
Date Reported: 2022-02-24
Verifier Name: Eliot Lear (ISE)
Date Verified: 2022-03-17

Section 12 says:

   IANA has made the following assignment in the "TLS ExtensionType
   Values" registry:

      +=======+================+=========+=============+===========+
      | Value | Extension Name | TLS 1.3 | Recommended | Reference |
      +=======+================+=========+=============+===========+
      |    59 | dnssec_chain   | CH      | No          | RFC 9102  |
      +-------+----------------+---------+-------------+-----------+

It should say:

   IANA has made the following assignment in the "TLS ExtensionType
   Values" registry:

      +=======+================+=========+=============+===========+
      | Value | Extension Name | TLS 1.3 | Recommended | Reference |
      +=======+================+=========+=============+===========+
      |    59 | dnssec_chain   | CH, CT  | No          | RFC 9102  |
      +-------+----------------+---------+-------------+-----------+

Notes:

In TLS1.3, the dnssec_chain extension appears in the Certificate message from the server. Hence "CT" needs to be added to the "TLS 1.3" column.

RFC 9106, "Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications", September 2021

Source of RFC: IRTF

Errata ID: 7721
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: David Finnie
Date Reported: 2023-12-07
Verifier Name: RFC Editor
Date Verified: 2023-12-07

Section 3.2 says:

   6.  If the number of passes t is larger than 1, we repeat step 5.  We
       compute B[i][0] and B[i][j] for all i raging from (and including)
       0 to (not including) p and for all j ranging from (and including)
       1 to (not including) q.  However, blocks are computed differently
       as the old value is XORed with the new one:

       B[i][0] = G(B[i][q-1], B[l][z]) XOR B[i][0];
       B[i][j] = G(B[i][j-1], B[l][z]) XOR B[i][j].

It should say:

   6.  If the number of passes t is larger than 1, we repeat step 5.  We
       compute B[i][0] and B[i][j] for all i ranging from (and
       including) 0 to (not including) p and for all j ranging from (and
       including) 1 to (not including) q.  However, blocks are computed
       differently as the old value is XORed with the new one:

       B[i][0] = G(B[i][q-1], B[l][z]) XOR B[i][0];
       B[i][j] = G(B[i][j-1], B[l][z]) XOR B[i][j].

Notes:

Firstly: nice, clear RFC. Well done.

I know it's really minor, and we all like to have "fun with flags", but..."ranging" rather than "raging" :-)

RFC 9110, "HTTP Semantics", June 2022

Source of RFC: httpbis (wit)

Errata ID: 7138
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Yousouf Taghzouti
Date Reported: 2022-09-23
Verifier Name: Francesca Palombini
Date Verified: 2022-11-09

Section 12.5.1 says:

The media type quality factor associated with a given type is 
determined by finding the media range with the highest precedence 
that matches the type. For example,

Accept: text/*;q=0.3, text/plain;q=0.7, text/plain;format=flowed,
       text/plain;format=fixed;q=0.4, */*;q=0.5

would cause the following values to be associated:

Table 5: 

Media Type	                Quality Value
text/plain;format=flowed	      1
text/plain	                     0.7
text/html	                     0.3
image/jpeg	                     0.5
text/plain;format=fixed	             0.4
text/html;level=3	             0.7

It should say:

The media type quality factor associated with a given type is 
determined by finding the media range with the highest precedence 
that matches the type. For example,

Accept: text/*;q=0.3, text/plain;q=0.7, text/plain;format=flowed,
       text/plain;format=fixed;q=0.4, */*;q=0.5

would cause the following values to be associated:

Table 5: 

Media Type	                Quality Value
text/plain;format=flowed	      1
text/plain	                     0.7
text/html	                     0.3
image/jpeg	                     0.5
text/plain;format=fixed	             0.4
text/html;level=3	             0.3

Notes:

To illustrate how the media type quality factor associated with a given type is determined, the following example is given:

Accept: text/*;q=0.3, text/plain;q=0.7, text/plain;format=flowed, text/plain;format=fixed;q=0.4, */*;q=0.5

The last row of the result table (table 5) presenting the values to be associated cannot be deduced (MediaType: text/html;level=3, Quality Value: 0.7), since only "text/*;q=0.3" and "*/*;q=0.5" are possible values and as explained in the RFC "text/*;q=0.3" should take precedence.

In section 5.3.2 of RFC7231, a similar example is given, where the last row of the table is correct (text/html;level=3 | 0.7) since in that example the accept header contains (text/html;q=0.7).

Errata ID: 7306
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Julian Reschke
Date Reported: 2023-01-13
Verifier Name: Francesca Palombini
Date Verified: 2023-10-23

Section 14.1.1 says:

  ranges-specifier = range-unit "=" range-set
  range-set        = 1#range-spec
  range-spec       = int-range
                   / suffix-range
                   / other-range

It should say:

  ranges-specifier = range-unit "=" OWS range-set
  range-set        = 1#range-spec
  range-spec       = int-range
                   / suffix-range
                   / other-range

Notes:

The ABNF is inconsistent with one of the examples given in 14.1.2

bytes= 0-999, 4500-5499, -1000

The bug in the ABNF was likely introduced when converting away from "implied linear whitespace".

See also <https://github.com/whatwg/fetch/issues/1070#issuecomment-1361800123>.

Errata ID: 7419
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Dave Shawley
Date Reported: 2023-04-11
Verifier Name: Francesca Palombini
Date Verified: 2023-10-23

Section 8.3.2 says:

   In the fields defined by this document, charset names appear either
   in parameters (Content-Type), or, for Accept-Encoding, in the form of
   a plain token.

It should say:

   In the fields defined by this document, charset names appear either
   in parameters (Content-Type), or, for Accept-Charset, in the form of
   a plain token.

Notes:

Accept-Encoding is the preferred list of response content codings. Accept-Charset is the preferred list of response charsets.

Errata ID: 7109
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Gary Wilson Jr.
Date Reported: 2022-08-31
Verifier Name: Francesca Palombini
Date Verified: 2022-11-09

Section 15.4.9 says:

   The 308 (Permanent Redirect) status code indicates that the target
   resource has been assigned a new permanent URI and any future
   references to this resource ought to use one of the enclosed URIs.

It should say:

   The 308 (Permanent Redirect) status code indicates that the target
   resource has been assigned a new permanent URI and any future
   references to this resource ought to use one of the enclosed URIs.
   The user agent MUST NOT change the request method if it performs
   an automatic redirection to that URI.

and/or add note as is present in RFC 7538, e.g.:

      Note: This status code is similar to 301 (Moved Permanently)
      (Section 15.4.2), except that it does not allow changing
      the request method from POST to GET.

Notes:

The current text in this section for 308 Permanent Redirect does not include any mention of the user agent not changing the request method. I am suggesting that similar wording be used as in 15.4.8. 307 Temporary Redirect and/or a note added similar to the one present in RFC 7538 but excluded from this section's current text. Whichever is chosen, it would be good to make the wording/notes consistent across both the 307 and 308 status code sections.

Errata ID: 7105
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Tomoyuki Sahara
Date Reported: 2022-08-26
Verifier Name: Francesca Palombini
Date Verified: 2022-11-01

Section B.1. says:

B.1.  Changes from RFC 2818

   None.

It should say:

B.1.  Changes from RFC 2818

   The use of CN-ID has been deprecated.

Notes:

In RFC2818:

If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used.

CN-ID may be used (when a subjectAltName of type dNSName is not present).

In RFC9110:

A reference identity of type CN-ID MUST NOT be used by clients.

CN-ID is not used at all. It is a change from RFC2818.

RFC 9112, "HTTP/1.1", June 2022

Source of RFC: httpbis (wit)

Errata ID: 7744
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: sequpt
Date Reported: 2023-12-31
Verifier Name: RFC Editor
Date Verified: 2024-01-03

Section 1.2 says:

obs-text      = <obs-text, see [HTTP], Section 5.6.4>

It should say:

obs-text      = <obs-text, see [HTTP], Section 5.5>

Notes:

'obs-text' is used in the rules defined in 5.6.4 but is only defined in 5.5.
This error also appears in 'Appendix A. Collected ABNF'.

RFC 9113, "HTTP/2", June 2022

Source of RFC: httpbis (wit)

Errata ID: 7013
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Moto Ishizawa
Date Reported: 2022-07-06
Verifier Name: RFC Editor
Date Verified: 2022-07-06

Section 6.1 says:

      |  Note: An endpoint that learns of stream closure after sending
      |  all data can close a stream by sending a STREAM frame with a
      |  zero-length Data field and the END_STREAM flag set.  This is
      |  only possible if the endpoint does not send trailers, as the
      |  END_STREAM flag appears on a HEADERS frame in that case; see
      |  Section 8.1.

It should say:

      |  Note: An endpoint that learns of stream closure after sending
      |  all data can close a stream by sending a DATA frame with a
      |  zero-length Data field and the END_STREAM flag set.  This is
      |  only possible if the endpoint does not send trailers, as the
      |  END_STREAM flag appears on a HEADERS frame in that case; see
      |  Section 8.1.

Notes:

Since STREAM frame is not defined in HTTP/2, I assume this is a DATA frame. This is probably a typo, possibly confused with the QUIC specification.

RFC 9114, "HTTP/3", June 2022

Source of RFC: quic (wit)

Errata ID: 7014
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: David Schinazi
Date Reported: 2022-07-06
Verifier Name: Zaheduzzaman Sarker
Date Verified: 2022-09-27

Section 4.3.1 says:

   ":path":  Contains the path and query parts of the target URI (the
      "path-absolute" production and optionally a ? character (ASCII
      0x3f) followed by the "query" production; see Sections 3.3 and 3.4
      of [URI].

It should say:

   ":path":  Contains the path and query parts of the target URI (the
      "absolute-path" production and optionally a ? character (ASCII
      0x3f) followed by the "query" production; see Section 4.1 of
      [HTTP] and Section 3.4 of [URI].

Notes:

There is a conflict between RFC 9114 and RFCs 9110,9112,9113. RFC 9114 disallows paths that start with "//" whereas the others allow them. Research seems to indicate that this was not intentional. More details on the mailing list discussion: https://lists.w3.org/Archives/Public/ietf-http-wg/2022JulSep/0014.html

Errata ID: 7780
Status: Verified
Type: Technical
Publication Format(s) : TEXT, HTML
Reported By: Lucas Pardue
Date Reported: 2024-01-24
Verifier Name: Francesca Palombini
Date Verified: 2024-01-29

Section 7.2.6 says:

The GOAWAY frame applies to the entire connection,
not a specific stream. A client MUST treat a
GOAWAY frame on a stream other than the control
stream as a connection error of type
H3_FRAME_UNEXPECTED.

It should say:

The GOAWAY frame applies to the entire connection,
not a specific stream. An endpoint MUST treat a
GOAWAY frame on a stream other than the control
stream as a connection error of type
H3_FRAME_UNEXPECTED.

Notes:

HTTP/3 originally only supported GOAWAY from server to client. In this PR we added the ability to also send GOAWAY from client to server https://github.com/quicwg/base-drafts/pull/3129/files. Unfortunately we didn't update the highlighted text to cover the situation where a server receives a GOAWAY on a different stream.

FWIW the implementation I am responsible for already applies the rule to request streams.

RFC 9115, "An Automatic Certificate Management Environment (ACME) Profile for Generating Delegated Certificates", September 2021

Source of RFC: acme (sec)

Errata ID: 7336
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Carsten Bormann
Date Reported: 2023-02-06
Verifier Name: Roman Danyliw.com
Date Verified: 2024-01-11

Section Appendix A says:

   oid = text .regexp "([0-2])((\.0)|(\.[1-9][0-9]*))*"

It should say:

   oid = text .regexp "([0-2])((\\.0)|(\\.[1-9][0-9]*))*"

Notes:

Backslashes need to be doubled in CDDL strings (as they are done in Appendix B).

An alternative fix would be to replace \\. by [.]

Note that the equivalent fix is not required for

regtext = text .regexp "([^\*].*)|([\*][^\*].*)|([\*][\*].+)"

as the fact that the single backslashes have no effect is irrelevant here — the backslashes are not needed in the character classes [...].
As an editorial enhancement, the backslashes could be entirely removed from this line.

RFC 9116, "A File Format to Aid in Security Vulnerability Disclosure", April 2022

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 6946
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Edwin Balani
Date Reported: 2022-04-28
Verifier Name: RFC Editor
Date Verified: 2022-04-28

Section 4 says:

   unsigned       =  *line (contact-field eol) ; one or more required
                     *line (expires-field eol) ; exactly one required
                     *line [lang-field eol] *line ; exactly one optional
                     ; order of fields within the file is not important
                     ; except that if contact-field appears more
                     ; than once, the order of those indicates
                     ; priority (see Section 3.5.3)

It should say:

   unsigned       =  *line (contact-field eol) ; one or more required
                     *line (expires-field eol) ; exactly one required
                     *line [lang-field eol] *line ; exactly one optional
                     ; order of fields within the file is not important
                     ; except that if contact-field appears more
                     ; than once, the order of those indicates
                     ; priority (see Section 2.5.3)

Notes:

Reference to Section 2.5.3 (describing ordering semantics of the Contact field) mistakenly given in ABNF comments as "Section 3.5.3"

RFC 9124, "A Manifest Information Model for Firmware Updates in Internet of Things (IoT) Devices", January 2022

Source of RFC: suit (sec)

Errata ID: 6891
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Øyvind Rønningstad
Date Reported: 2022-03-02
Verifier Name: RFC Editor
Date Verified: 2022-03-24

Section 4.3.18 says:

4.3.18.  REQ.SEC.KEY.ROTATION: Protected Storage of Signing Keys

It should say:

4.3.18.  REQ.SEC.KEY.ROTATION: Rotation of Signing Keys

Notes:

The current text is duplicated from the heading of 4.3.17.

RFC 9134, "RTP Payload Format for ISO/IEC 21122 (JPEG XS)", October 2021

Source of RFC: avtcore (wit)

Errata ID: 6752
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Tim Bruylants
Date Reported: 2021-11-24
Verifier Name: Murray Kucherawy
Date Verified: 2023-11-08

Section 4.2 says:

As specified in [RFC3550] and [RFC4175], the RTP timestamp
designates the sampling instant of the first octet of the video
frame to which the RTP packet belongs.  Packets SHALL NOT include
data from multiple video frames, and all packets belonging to the
same video frame SHALL have the same timestamp.  Several
successive RTP packets will consequently have equal timestamps if
they belong to the same video frame (that is until the marker bit
is set to 1, marking the last packet of the video frame), and the
timestamp is only increased when a new video frame begins.

It should say:

As specified in [RFC3550] and [RFC4175], the RTP timestamp
designates the sampling instant of the first octet of the video
frame/field to which the RTP packet belongs.  Packets SHALL NOT include
data from multiple video frames/fields, and all packets belonging to the
same video frame/field SHALL have the same timestamp.  Several
successive RTP packets will consequently have equal timestamps if
they belong to the same video frame/field (that is until the marker bit
is set to 1, marking the last packet of the video frame/field), and the
timestamp is only increased when a new video frame/field begins.

Notes:

This RFC follows RFC4175 (and also SMPTE2110) for timestamping RTP packets. The intent has always been to have unique timestamps per progressive video frame and/or per interlaced video field (two fields of a frame MUST be allowed to have different timestamps). This is correctly reflected by the marker bit (M) that is used to indicate the last packet of a frame/field (which is correctly explained in this RFC). However, the accompanied text about the timestamp in section 4.2 does not properly formulate this for the interlaced mode case (it was an editorial oversight), which can cause confusion to implementers of this RFC.

RFC 9135, "Integrated Routing and Bridging in Ethernet VPN (EVPN)", October 2021

Source of RFC: bess (rtg)

Errata ID: 7683
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Denis Vrkic
Date Reported: 2023-10-19
Verifier Name: John Scudder
Date Verified: 2024-02-09

Section 4.2. says:

  2.  However, if PE2 is configured for asymmetric IRB mode, PE2 will
       advertise TS4 MAC/IP information in a MAC/IP Advertisement route
       with a zero Label2 field and no Route Target identifying IP-VRF1.
       In this case, PE2 will install TS4 information in its ARP table
       and BT1.  When a packet from TS2 to TS4 arrives at PE1, a longest
       prefix match on IP-VRF1's route table will yield the local IRB
       interface to BT1, where a subsequent ARP and bridge table lookup
       will provide the information for an asymmetric forwarding mode to
       PE2.

It should say:

  2.  However, if PE2 is configured for asymmetric IRB mode, PE2 will
       advertise TS4 MAC/IP information in a MAC/IP Advertisement route
       with a zero Label2 field and no Route Target identifying IP-VRF1.
       In this case, PE1 will install TS4 information in its ARP table
       and BT1.  When a packet from TS2 to TS4 arrives at PE1, a longest
       prefix match on IP-VRF1's route table will yield the local IRB
       interface to BT1, where a subsequent ARP and bridge table lookup
       will provide the information for an asymmetric forwarding mode to
       PE2.

Notes:

PE1 will use ARP table for forwarding traffic to PE2 - seems like typo

Errata ID: 7684
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Denis Vrkic
Date Reported: 2023-10-19
Verifier Name: John Scudder
Date Verified: 2024-02-12

Section 6.1 says:

 This route is advertised along with the following extended community:

   *  Tunnel Type Extended Community

It should say:

 This route is advertised along with the following extended community:

   *  Encapsulation Extended Community

Notes:

I guess that solud be Encapsulation Extended Community (or maybe Tunnel Encapsulation Attribute)

Verifier notes:
See https://mailarchive.ietf.org/arch/msg/bess/TgQR3NHd6wgcYow0B76i7ToBmr0/

RFC 9142, "Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH)", January 2022

Source of RFC: curdle (sec)

Errata ID: 7799
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Ben S
Date Reported: 2024-02-07
Verifier Name: Paul Wouters
Date Verified: 2024-02-07

Section 1.2.1 says:

+============+=============================+
| Curve Name | Estimated Security Strength |
+============+=============================+
| nistp256   | 128 bits                    |
+------------+-----------------------------+
| nistp384   | 192 bits                    |
+------------+-----------------------------+
| nistp521   | 512 bits                    |
+------------+-----------------------------+
| curve25519 | 128 bits                    |
+------------+-----------------------------+
| curve448   | 224 bits                    |
+------------+-----------------------------+

It should say:

+============+=============================+
| Curve Name | Estimated Security Strength |
+============+=============================+
| nistp256   | 128 bits                    |
+------------+-----------------------------+
| nistp384   | 192 bits                    |
+------------+-----------------------------+
| nistp521   | 256 bits                    |
+------------+-----------------------------+
| curve25519 | 128 bits                    |
+------------+-----------------------------+
| curve448   | 224 bits                    |
+------------+-----------------------------+

Notes:

P-521 has approximately 256 bits of security (rather than 512), as per Table 1 of Section 6.1.1 of FIPS 186-5, and Section 9 Paragraph 5 of RFC 5656.

Errata ID: 7126
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Jacob Nevins
Date Reported: 2022-09-12
Verifier Name: RFC Editor
Date Verified: 2022-09-13

Section 1.2.1 says:

The curve25519 and curve488 security-level numbers are in [RFC7748].

It should say:

The curve25519 and curve448 security-level numbers are in [RFC7748].

Notes:

"curve488" should be "curve448". (From context, this is unlikely to cause significant confusion for readers, since "Curve488" does not represent a well-known primitive and is not mentioned in the reference, whereas Curve448 is well-known and referred to in the reference and elsewhere in this document.)

RFC 9151, "Commercial National Security Algorithm (CNSA) Suite Profile for TLS and DTLS 1.2 and 1.3", April 2022

Source of RFC: INDEPENDENT

Errata ID: 7724
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: James Mayclin
Date Reported: 2023-12-08
Verifier Name: Eliot Lear
Date Verified: 2024-01-04

Section 5.2 says:

      If RSASSA-PSS is supported (using rsa_pss_rsae_sha384 for
      example), then the implementation MUST assert rsaEncryption as the
      public key algorithm, the hash algorithm (used for both mask
      generation and signature generation) MUST be SHA-384, the mask
      generation function 1 (MGF1) from [RFC8017] MUST be used, and the
      salt length MUST be 48 octets.

It should say:

      If RSASSA-PSS is supported then the hash algorithm (used for both
      mask generation and signature generation) MUST be SHA-384, the 
      mask generation function 1 (MGF1) from [RFC8017] MUST be used, 
      and the salt length MUST be 48 octets. If rsa_pss_rsae_sha384 is 
      used then the implementation MUST assert rsaEncryption as the 
      public key algorithm. If rsa_pss_pss_sha384 is used then the 
      implementation MUST assert RSASSA-PSS as the public key algorithm.

Notes:

RFC9151 explicitly allows both rsa_pss_pss_sha384 and rsa_pss_rsae_sha384 RSASSA-PSS signatures (Sections 6.2, 6.3, 6.4, 7.1, 7.2). This conflicts with the requirement that “the implementation MUST assert rsaEncryption as the public key algorithm” because rsa_pss_pss_sha384 uses RSASSA-PSS as the public key algorithm.

The proposed corrected text updates the requirement to include the correct public key algorithm for rsa_pss_pss_sha384 signatures. The wording closely follows the language used in Section 4.2.3 of RFC 8446.

RFC 9180, "Hybrid Public Key Encryption", February 2022

Source of RFC: IRTF

Errata ID: 6941
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: CJ
Date Reported: 2022-04-21
Verifier Name: Stanislav Smyshlyaev
Date Verified: 2022-05-12

Section 6.1 says:

In many cases, applications encrypt only a single message
to a recipient's public key. This section provides templates
for HPKE APIs that implement stateless "single-shot"
encryption and decryption using APIs specified in
Sections 5.1.1 and 5.2:

It should say:

In many cases, applications encrypt only a single message
to a recipient's public key. This section provides templates
for HPKE APIs that implement stateless "single-shot"
encryption and decryption using APIs specified in
Sections 5.1 and 5.2:

Notes:

5.1.1 -> 5.1: I think the description of the single-shot APIs should refer to the entire HPKE modes hence Section 5.1, instead of Section 5.1.1 which is about the base mode only.

RFC 9187, "Sequence Number Extension for Windowed Protocols", January 2022

Source of RFC: INDEPENDENT

Errata ID: 6827
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Erik Auerswald
Date Reported: 2022-02-02
Verifier Name: Adrian Farrel
Date Verified: 2022-02-06

Section 5 says:

The following C code is provided as a verified example of SNE from 16
to 32 bits.

It should say:

The following C code is provided as a verified example of SNE from 32
to 64 bits.

Notes:

The code takes 32 bits sequence numbers and extends them to 64 bits.

Errata ID: 6828
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Erik Auerswald
Date Reported: 2022-02-02
Verifier Name: Adrian Farrel
Date Verified: 2022-02-06

Section 5 says:

char *prompt = "Input hex numbers only (0x is optional)\n\n")

It should say:

char *prompt = "Input hex numbers only (0x is optional)\n\n"

Notes:

The closing parenthesis at the end of the line is a syntax error for the C programming language:

$ cc compute_sne.c
compute_sne.c: In function ‘main’:
compute_sne.c:78:64: error: expected ‘,’ or ‘;’ before ‘)’ token

RFC 9196, "YANG Modules Describing Capabilities for Systems and Datastore Update Notifications", February 2022

Source of RFC: netconf (ops)

Errata ID: 7260
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2022-12-05
Verifier Name: RFC Editor
Date Verified: 2022-12-05

Section 5.2 says:

   <CODE ENDS>

   <CODE ENDS>

It should say:

   <CODE ENDS>

Notes:

Duplicate line of text

RFC 9197, "Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)", May 2022

Source of RFC: ippm (ops)

Errata ID: 6992
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2022-06-15
Verifier Name: RFC Editor
Date Verified: 2022-06-15

Section 7.3 says:

   Bit:  desired bit to be allocated in the 8-bit flags field of the
      Pre-allocated Trace Option-Type and Incremental Trace Option-Type

It should say:

   Bit:  desired bit to be allocated in the 4-bit flags field of the
      Pre-allocated Trace Option-Type and Incremental Trace Option-Type

Notes:

The size of the Flags field is 4 bits, not 8.

RFC 9216, "S/MIME Example Keys and Certificates", April 2022

Source of RFC: lamps (sec)

Errata ID: 6993
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2022-06-15
Verifier Name: RFC Editor
Date Verified: 2022-06-16

Section 8 says:

Email Address:  dna@smime.example

It should say:

Email Address:  dana@smime.example

Notes:

Decoding the certificate shoes that the Subject Alternative Name contains an email address of dana@smime.example.

RFC 9225, "Software Defects Considered Harmful", April 2022

Source of RFC: INDEPENDENT

Errata ID: 6911
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Kyoung-Hwan Yun
Date Reported: 2022-04-01
Verifier Name: RFC Editor
Date Verified: 2022-04-06

Section 4 says:

4. Best Current Practises

It should say:

4. Best Current Practices

Notes:

These rest of the document uses the US spelling "practice". The reported text is inconsistent by using a British variant spelling.

--VERIFIER NOTES--
This entry has been updated from its original submission to show the correct information. Instances of "practice" should be "practise" for consistency with the British spelling used throughout.

RFC 9235, "TCP Authentication Option (TCP-AO) Test Vectors", May 2022

Source of RFC: tcpm (wit)

Errata ID: 7032
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: csaba mate
Date Reported: 2022-07-25
Verifier Name: Martin Duke
Date Verified: 2024-01-18

Section 4.1.1 says:

     45 e0 00 4c dd 0f 40 00 ff 06 bf 6b 0a 0b 0c 0d
     ac 1b 1c 1d e9 d7 00 b3 fb fb ab 5a 00 00 00 00
     e0 02 ff ff ca c4 00 00 02 04 05 b4 01 03 03 08
     04 02 08 0a 00 15 5a b7 00 00 00 00 1d 10 3d 54
     2e e4 37 c6 f8 ed e6 d7 c4 d6 02 e7

It should say:

     45 e0 00 4c dd 0f 40 00 ff 06 bf 6b 0a 0b 0c 0d
     ac 1b 1c 1d e9 d7 00 b3 fb fb ab 5a 00 00 00 00
     e0 02 ff ff d4 5e 00 00 02 04 05 b4 01 03 03 08
     04 02 08 0a 00 15 5a b7 00 00 00 00 1d 10 3d 54
     2e e4 37 c6 f8 ed e6 d7 c4 d6 02 e7

Notes:

the final tcp checksum was not computed correctly. it should be correct on the line, regardless if tcp-ao is in place ot nor.

Errata ID: 7033
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Michael Tüxen
Date Reported: 2022-07-25
Verifier Name: Martin Duke
Date Verified: 2024-01-18

Section 4.1.2 says:

   IPv4/TCP:

     45 e0 00 4c 65 06 40 00 ff 06 37 75 ac 1b 1c 1d
     0a 0b 0c 0d 00 b3 e9 d7 11 c1 42 61 fb fb ab 5b
     e0 12 ff ff 37 76 00 00 02 04 05 b4 01 03 03 08
     04 02 08 0a 84 a5 0b eb 00 15 5a b7 1d 10 54 3d
     ee ab 0f e2 4c 30 10 81 51 16 b3 be

It should say:

   IPv4/TCP:

     45 e0 00 4c 65 06 40 00 ff 06 37 75 ac 1b 1c 1d
     0a 0b 0c 0d 00 b3 e9 d7 11 c1 42 61 fb fb ab 5b
     e0 12 ff ff 86 cb 00 00 02 04 05 b4 01 03 03 08
     04 02 08 0a 84 a5 0b eb 00 15 5a b7 1d 10 54 3d
     ee ab 0f e2 4c 30 10 81 51 16 b3 be

Notes:

The TCP checksum shown (0x3776) is wrong, it should be 0x86cb.

Errata ID: 7034
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Michael Tüxen
Date Reported: 2022-07-25
Verifier Name: Martin Duke
Date Verified: 2024-01-18

Section 4.1.3 says:

   IPv4/TCP:

     45 e0 00 87 36 a1 40 00 ff 06 65 9f 0a 0b 0c 0d
     ac 1b 1c 1d e9 d7 00 b3 fb fb ab 5b 11 c1 42 62
     c0 18 01 04 a1 62 00 00 01 01 08 0a 00 15 5a c1
     84 a5 0b eb 1d 10 3d 54 70 64 cf 99 8c c6 c3 15
     c2 c2 e2 bf ff ff ff ff ff ff ff ff ff ff ff ff
     ff ff ff ff 00 43 01 04 da bf 00 b4 0a 0b 0c 0d
     26 02 06 01 04 00 01 00 01 02 02 80 00 02 02 02
     00 02 02 42 00 02 06 41 04 00 00 da bf 02 08 40
     06 00 64 00 01 01 00

It should say:

   IPv4/TCP:

     45 e0 00 87 36 a1 40 00 ff 06 65 9f 0a 0b 0c 0d
     ac 1b 1c 1d e9 d7 00 b3 fb fb ab 5b 11 c1 42 62
     c0 18 01 04 8c de 00 00 01 01 08 0a 00 15 5a c1
     84 a5 0b eb 1d 10 3d 54 70 64 cf 99 8c c6 c3 15
     c2 c2 e2 bf ff ff ff ff ff ff ff ff ff ff ff ff
     ff ff ff ff 00 43 01 04 da bf 00 b4 0a 0b 0c 0d
     26 02 06 01 04 00 01 00 01 02 02 80 00 02 02 02
     00 02 02 42 00 02 06 41 04 00 00 da bf 02 08 40
     06 00 64 00 01 01 00

Notes:

The TCP checksum shown (0xa162) is wrong, it should be 0x8cde.

Errata ID: 7035
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Michael Tüxen
Date Reported: 2022-07-25
Verifier Name: Martin Duke
Date Verified: 2024-01-18

Section 4.1.4 says:

   IPv4/TCP:

     45 e0 00 87 1f a9 40 00 ff 06 7c 97 ac 1b 1c 1d
     0a 0b 0c 0d 00 b3 e9 d7 11 c1 42 62 fb fb ab 9e
     c0 18 01 00 40 0c 00 00 01 01 08 0a 84 a5 0b f5
     00 15 5a c1 1d 10 54 3d a6 3f 0e cb bb 2e 63 5c
     95 4d ea c7 ff ff ff ff ff ff ff ff ff ff ff ff
     ff ff ff ff 00 43 01 04 da c0 00 b4 ac 1b 1c 1d
     26 02 06 01 04 00 01 00 01 02 02 80 00 02 02 02
     00 02 02 42 00 02 06 41 04 00 00 da c0 02 08 40
     06 00 64 00 01 01 00

It should say:

   IPv4/TCP:

     45 e0 00 87 1f a9 40 00 ff 06 7c 97 ac 1b 1c 1d
     0a 0b 0c 0d 00 b3 e9 d7 11 c1 42 62 fb fb ab 9e
     c0 18 01 00 a4 3c 00 00 01 01 08 0a 84 a5 0b f5
     00 15 5a c1 1d 10 54 3d a6 3f 0e cb bb 2e 63 5c
     95 4d ea c7 ff ff ff ff ff ff ff ff ff ff ff ff
     ff ff ff ff 00 43 01 04 da c0 00 b4 ac 1b 1c 1d
     26 02 06 01 04 00 01 00 01 02 02 80 00 02 02 02
     00 02 02 42 00 02 06 41 04 00 00 da c0 02 08 40
     06 00 64 00 01 01 00

Notes:

The TCP checksum shown (0x400c) is wrong, it should be 0xa43c.

Errata ID: 7036
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Michael Tüxen
Date Reported: 2022-07-25
Verifier Name: Martin Duke
Date Verified: 2024-01-18

Section 4.2.1 says:

   IPv4/TCP:

     45 e0 00 4c 53 99 40 00 ff 06 48 e2 0a 0b 0c 0d
     ac 1b 1c 1d ff 12 00 b3 cb 0e fb ee 00 00 00 00
     e0 02 ff ff 54 1f 00 00 02 04 05 b4 01 03 03 08
     04 02 08 0a 00 02 4c ce 00 00 00 00 1d 10 3d 54
     80 af 3c fe b8 53 68 93 7b 8f 9e c2

It should say:

   IPv4/TCP:

     45 e0 00 4c 53 99 40 00 ff 06 48 e2 0a 0b 0c 0d
     ac 1b 1c 1d ff 12 00 b3 cb 0e fb ee 00 00 00 00
     e0 02 ff ff c2 bf 00 00 02 04 05 b4 01 03 03 08
     04 02 08 0a 00 02 4c ce 00 00 00 00 1d 10 3d 54
     80 af 3c fe b8 53 68 93 7b 8f 9e c2

Notes:

The TCP checksum shown (0x541f) is wrong, it should be 0xc2bf.

Errata ID: 7037
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Michael Tüxen
Date Reported: 2022-07-25
Verifier Name: Martin Duke
Date Verified: 2024-01-18

Section 4.2.2 says:

   IPv4/TCP:

     45 e0 00 4c 32 84 40 00 ff 06 69 f7 ac 1b 1c 1d
     0a 0b 0c 0d 00 b3 ff 12 ac d5 b5 e1 cb 0e fb ef
     e0 12 ff ff 38 8e 00 00 02 04 05 b4 01 03 03 08
     04 02 08 0a 57 67 72 f3 00 02 4c ce 1d 10 54 3d
     09 30 6f 9a ce a6 3a 8c 68 cb 9a 70

It should say:

   IPv4/TCP:

     45 e0 00 4c 32 84 40 00 ff 06 69 f7 ac 1b 1c 1d
     0a 0b 0c 0d 00 b3 ff 12 ac d5 b5 e1 cb 0e fb ef
     e0 12 ff ff f2 60 00 00 02 04 05 b4 01 03 03 08
     04 02 08 0a 57 67 72 f3 00 02 4c ce 1d 10 54 3d
     09 30 6f 9a ce a6 3a 8c 68 cb 9a 70

Notes:

The TCP checksum shown (0x388e) is wrong, it should be 0xf260.

Errata ID: 7038
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Michael Tüxen
Date Reported: 2022-07-25
Verifier Name: Martin Duke
Date Verified: 2024-01-18

Section 4.2.3 says:

   IPv4/TCP:

     45 e0 00 87 a8 f5 40 00 ff 06 f3 4a 0a 0b 0c 0d
     ac 1b 1c 1d ff 12 00 b3 cb 0e fb ef ac d5 b5 e2
     c0 18 01 04 6c 45 00 00 01 01 08 0a 00 02 4c ce
     57 67 72 f3 1d 10 3d 54 71 06 08 cc 69 6c 03 a2
     71 c9 3a a5 ff ff ff ff ff ff ff ff ff ff ff ff
     ff ff ff ff 00 43 01 04 da bf 00 b4 0a 0b 0c 0d
     26 02 06 01 04 00 01 00 01 02 02 80 00 02 02 02
     00 02 02 42 00 02 06 41 04 00 00 da bf 02 08 40
     06 00 64 00 01 01 00

It should say:

   IPv4/TCP:

     45 e0 00 87 a8 f5 40 00 ff 06 f3 4a 0a 0b 0c 0d
     ac 1b 1c 1d ff 12 00 b3 cb 0e fb ef ac d5 b5 e2
     c0 18 01 04 bf b0 00 00 01 01 08 0a 00 02 4c ce
     57 67 72 f3 1d 10 3d 54 71 06 08 cc 69 6c 03 a2
     71 c9 3a a5 ff ff ff ff ff ff ff ff ff ff ff ff
     ff ff ff ff 00 43 01 04 da bf 00 b4 0a 0b 0c 0d
     26 02 06 01 04 00 01 00 01 02 02 80 00 02 02 02
     00 02 02 42 00 02 06 41 04 00 00 da bf 02 08 40
     06 00 64 00 01 01 00

Notes:

The TCP checksum shown (0x6c45) is wrong, it should be 0xbfb0.

Errata ID: 7039
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Michael Tüxen
Date Reported: 2022-07-25
Verifier Name: Martin Duke
Date Verified: 2024-01-18

Section 4.2.4 says:

   IPv4/TCP:

     45 e0 00 87 54 37 40 00 ff 06 48 09 ac 1b 1c 1d
     0a 0b 0c 0d 00 b3 ff 12 ac d5 b5 e2 cb 0e fc 32
     c0 18 01 00 46 b6 00 00 01 01 08 0a 57 67 72 f3
     00 02 4c ce 1d 10 54 3d 97 76 6e 48 ac 26 2d e9
     ae 61 b4 f9 ff ff ff ff ff ff ff ff ff ff ff ff
     ff ff ff ff 00 43 01 04 da c0 00 b4 ac 1b 1c 1d
     26 02 06 01 04 00 01 00 01 02 02 80 00 02 02 02
     00 02 02 42 00 02 06 41 04 00 00 da c0 02 08 40
     06 00 64 00 01 01 00

It should say:

   IPv4/TCP:

     45 e0 00 87 54 37 40 00 ff 06 48 09 ac 1b 1c 1d
     0a 0b 0c 0d 00 b3 ff 12 ac d5 b5 e2 cb 0e fc 32
     c0 18 01 00 45 8c 00 00 01 01 08 0a 57 67 72 f3
     00 02 4c ce 1d 10 54 3d 97 76 6e 48 ac 26 2d e9
     ae 61 b4 f9 ff ff ff ff ff ff ff ff ff ff ff ff
     ff ff ff ff 00 43 01 04 da c0 00 b4 ac 1b 1c 1d
     26 02 06 01 04 00 01 00 01 02 02 80 00 02 02 02
     00 02 02 42 00 02 06 41 04 00 00 da c0 02 08 40
     06 00 64 00 01 01 00

Notes:

The TCP checksum shown (0x46b6) is wrong, it should be 0x458c.

Errata ID: 7040
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Michael Tüxen
Date Reported: 2022-07-25
Verifier Name: Martin Duke
Date Verified: 2024-01-18

Section 5.1.1 says:

   IP/TCP:

     45 e0 00 4c 7b 9f 40 00 ff 06 20 dc 0a 0b 0c 0d
     ac 1b 1c 1d c4 fa 00 b3 78 7a 1d df 00 00 00 00
     e0 02 ff ff 5a 0f 00 00 02 04 05 b4 01 03 03 08
     04 02 08 0a 00 01 7e d0 00 00 00 00 1d 10 3d 54
     e4 77 e9 9c 80 40 76 54 98 e5 50 91

It should say:

   IP/TCP:

     45 e0 00 4c 7b 9f 40 00 ff 06 20 dc 0a 0b 0c 0d
     ac 1b 1c 1d c4 fa 00 b3 78 7a 1d df 00 00 00 00
     e0 02 ff ff 46 41 00 00 02 04 05 b4 01 03 03 08
     04 02 08 0a 00 01 7e d0 00 00 00 00 1d 10 3d 54
     e4 77 e9 9c 80 40 76 54 98 e5 50 91

Notes:

The TCP checksum shown (0x5a0f) is wrong, it should be 0x4641.

Errata ID: 7041
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Michael Tüxen
Date Reported: 2022-07-25
Verifier Name: Martin Duke
Date Verified: 2024-01-18

Section 5.1.2 says:

   IPv4/TCP:

     45 e0 00 4c 4b ad 40 00 ff 06 50 ce ac 1b 1c 1d
     0a 0b 0c 0d 00 b3 c4 fa fa dd 6d e9 78 7a 1d e0
     e0 12 ff ff f3 f2 00 00 02 04 05 b4 01 03 03 08
     04 02 08 0a 93 f4 e9 e8 00 01 7e d0 1d 10 54 3d
     d6 ad a7 bc 4c dd 53 6d 17 69 db 5f

It should say:

   IPv4/TCP:

     45 e0 00 4c 4b ad 40 00 ff 06 50 ce ac 1b 1c 1d
     0a 0b 0c 0d 00 b3 c4 fa fa dd 6d e9 78 7a 1d e0
     e0 12 ff ff e5 44 00 00 02 04 05 b4 01 03 03 08
     04 02 08 0a 93 f4 e9 e8 00 01 7e d0 1d 10 54 3d
     d6 ad a7 bc 4c dd 53 6d 17 69 db 5f

Notes:

The TCP checksum shown (0xf3f2) is wrong, it should be 0xe544.

Errata ID: 7042
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Michael Tüxen
Date Reported: 2022-07-25
Verifier Name: Martin Duke
Date Verified: 2024-01-18

Section 5.1.3 says:

   IPv4/TCP:

     45 e0 00 87 fb 4f 40 00 ff 06 a0 f0 0a 0b 0c 0d
     ac 1b 1c 1d c4 fa 00 b3 78 7a 1d e0 fa dd 6d ea
     c0 18 01 04 95 05 00 00 01 01 08 0a 00 01 7e d0
     93 f4 e9 e8 1d 10 3d 54 77 41 27 42 fa 4d c4 33
     ef f0 97 3e ff ff ff ff ff ff ff ff ff ff ff ff
     ff ff ff ff 00 43 01 04 da bf 00 b4 0a 0b 0c 0d
     26 02 06 01 04 00 01 00 01 02 02 80 00 02 02 02
     00 02 02 42 00 02 06 41 04 00 00 da bf 02 08 40
     06 00 64 00 01 01 00

It should say:

   IPv4/TCP:

     45 e0 00 87 fb 4f 40 00 ff 06 a0 f0 0a 0b 0c 0d
     ac 1b 1c 1d c4 fa 00 b3 78 7a 1d e0 fa dd 6d ea
     c0 18 01 04 ed f3 00 00 01 01 08 0a 00 01 7e d0
     93 f4 e9 e8 1d 10 3d 54 77 41 27 42 fa 4d c4 33
     ef f0 97 3e ff ff ff ff ff ff ff ff ff ff ff ff
     ff ff ff ff 00 43 01 04 da bf 00 b4 0a 0b 0c 0d
     26 02 06 01 04 00 01 00 01 02 02 80 00 02 02 02
     00 02 02 42 00 02 06 41 04 00 00 da bf 02 08 40
     06 00 64 00 01 01 00

Notes:

The TCP checksum shown (0x9505) is wrong, it should be 0xedf3.

Errata ID: 7043
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Michael Tüxen
Date Reported: 2022-07-25
Verifier Name: Martin Duke
Date Verified: 2024-01-18

Section 5.1.4 says:

   IPv4/TCP:

     45 e0 00 87 b9 14 40 00 ff 06 e3 2b ac 1b 1c 1d
     0a 0b 0c 0d 00 b3 c4 fa fa dd 6d ea 78 7a 1e 23
     c0 18 01 00 e7 db 00 00 01 01 08 0a 93 f4 e9 e8
     00 01 7e d0 1d 10 54 3d f6 d9 65 a7 83 82 a7 48
     45 f7 2d ac ff ff ff ff ff ff ff ff ff ff ff ff
     ff ff ff ff 00 43 01 04 da c0 00 b4 ac 1b 1c 1d
     26 02 06 01 04 00 01 00 01 02 02 80 00 02 02 02
     00 02 02 42 00 02 06 41 04 00 00 da c0 02 08 40
     06 00 64 00 01 01 00

It should say:

   IPv4/TCP:

     45 e0 00 87 b9 14 40 00 ff 06 e3 2b ac 1b 1c 1d
     0a 0b 0c 0d 00 b3 c4 fa fa dd 6d ea 78 7a 1e 23
     c0 18 01 00 0c ef 00 00 01 01 08 0a 93 f4 e9 e8
     00 01 7e d0 1d 10 54 3d f6 d9 65 a7 83 82 a7 48
     45 f7 2d ac ff ff ff ff ff ff ff ff ff ff ff ff
     ff ff ff ff 00 43 01 04 da c0 00 b4 ac 1b 1c 1d
     26 02 06 01 04 00 01 00 01 02 02 80 00 02 02 02
     00 02 02 42 00 02 06 41 04 00 00 da c0 02 08 40
     06 00 64 00 01 01 00

Notes:

The TCP checksum shown (0xe7db) is wrong, it should be 0x0cef.

Errata ID: 7044
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Michael Tüxen
Date Reported: 2022-07-25
Verifier Name: Martin Duke
Date Verified: 2024-01-18

Section 5.2.1 says:

   IPv4/TCP:

     45 e0 00 4c f2 2e 40 00 ff 06 aa 4c 0a 0b 0c 0d
     ac 1b 1c 1d da 1c 00 b3 38 9b ed 71 00 00 00 00
     e0 02 ff ff 70 bf 00 00 02 04 05 b4 01 03 03 08
     04 02 08 0a 00 01 85 e1 00 00 00 00 1d 10 3d 54
     c4 4e 60 cb 31 f7 c0 b1 de 3d 27 49

It should say:

   IPv4/TCP:

     45 e0 00 4c f2 2e 40 00 ff 06 aa 4c 0a 0b 0c 0d
     ac 1b 1c 1d da 1c 00 b3 38 9b ed 71 00 00 00 00
     e0 02 ff ff 2b 31 00 00 02 04 05 b4 01 03 03 08
     04 02 08 0a 00 01 85 e1 00 00 00 00 1d 10 3d 54
     c4 4e 60 cb 31 f7 c0 b1 de 3d 27 49

Notes:

The TCP checksum shown (0x70bf) is wrong, it should be 0x2b31.

Errata ID: 7045
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Michael Tüxen
Date Reported: 2022-07-25
Verifier Name: Martin Duke
Date Verified: 2024-01-18

Section 5.2.2 says:

   IPv4/TCP:

     45 e0 00 4c 6c c0 40 00 ff 06 2f bb ac 1b 1c 1d
     0a 0b 0c 0d 00 b3 da 1c d3 84 4a 6f 38 9b ed 72
     e0 12 ff ff e4 45 00 00 02 04 05 b4 01 03 03 08
     04 02 08 0a ce 45 98 38 00 01 85 e1 1d 10 54 3d
     3a 6a bb 20 7e 49 b1 be 71 36 db 90

It should say:

   IPv4/TCP:

     45 e0 00 4c 6c c0 40 00 ff 06 2f bb ac 1b 1c 1d
     0a 0b 0c 0d 00 b3 da 1c d3 84 4a 6f 38 9b ed 72
     e0 12 ff ff 3a b4 00 00 02 04 05 b4 01 03 03 08
     04 02 08 0a ce 45 98 38 00 01 85 e1 1d 10 54 3d
     3a 6a bb 20 7e 49 b1 be 71 36 db 90

Notes:

The TCP checksum shown (0xe445) is wrong, it should be 0x3ab4.

Errata ID: 7046
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Michael Tüxen
Date Reported: 2022-07-25
Verifier Name: Martin Duke
Date Verified: 2024-01-18

Section 5.2.3 says:

   IPv4/TCP:

     45 e0 00 87 ee 91 40 00 ff 06 ad ae 0a 0b 0c 0d
     ac 1b 1c 1d da 1c 00 b3 38 9b ed 72 d3 84 4a 70
     c0 18 01 04 88 51 00 00 01 01 08 0a 00 01 85 e1
     ce 45 98 38 1d 10 3d 54 75 85 e9 e9 d5 c3 ec 85
     7b 96 f8 37 ff ff ff ff ff ff ff ff ff ff ff ff
     ff ff ff ff 00 43 01 04 da bf 00 b4 0a 0b 0c 0d
     26 02 06 01 04 00 01 00 01 02 02 80 00 02 02 02
     00 02 02 42 00 02 06 41 04 00 00 da bf 02 08 40
     06 00 64 00 01 01 00

It should say:

   IPv4/TCP:

     45 e0 00 87 ee 91 40 00 ff 06 ad ae 0a 0b 0c 0d
     ac 1b 1c 1d da 1c 00 b3 38 9b ed 72 d3 84 4a 70
     c0 18 01 04 f2 ec 00 00 01 01 08 0a 00 01 85 e1
     ce 45 98 38 1d 10 3d 54 75 85 e9 e9 d5 c3 ec 85
     7b 96 f8 37 ff ff ff ff ff ff ff ff ff ff ff ff
     ff ff ff ff 00 43 01 04 da bf 00 b4 0a 0b 0c 0d
     26 02 06 01 04 00 01 00 01 02 02 80 00 02 02 02
     00 02 02 42 00 02 06 41 04 00 00 da bf 02 08 40
     06 00 64 00 01 01 00

Notes:

The TCP checksum shown (0x8851) is wrong, it should be 0xf2ec.

Errata ID: 7047
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Michael Tüxen
Date Reported: 2022-07-25
Verifier Name: Martin Duke
Date Verified: 2024-01-18

Section 5.2.4 says:

   IPv4/TCP:

     45 e0 00 87 6a 21 40 00 ff 06 32 1f ac 1b 1c 1d
     0a 0b 0c 0d 00 b3 da 1c d3 84 4a 70 38 9b ed 72
     c0 18 01 00 04 49 00 00 01 01 08 0a ce 45 98 38
     00 01 85 e1 1d 10 54 3d 5c 04 0f d9 23 33 04 76
     5c 09 82 f4 ff ff ff ff ff ff ff ff ff ff ff ff
     ff ff ff ff 00 43 01 04 da c0 00 b4 ac 1b 1c 1d
     26 02 06 01 04 00 01 00 01 02 02 80 00 02 02 02
     00 02 02 42 00 02 06 41 04 00 00 da c0 02 08 40
     06 00 64 00 01 01 00

It should say:

   IPv4/TCP:

     45 e0 00 87 6a 21 40 00 ff 06 32 1f ac 1b 1c 1d
     0a 0b 0c 0d 00 b3 da 1c d3 84 4a 70 38 9b ed 72
     c0 18 01 00 4b e9 00 00 01 01 08 0a ce 45 98 38
     00 01 85 e1 1d 10 54 3d 5c 04 0f d9 23 33 04 76
     5c 09 82 f4 ff ff ff ff ff ff ff ff ff ff ff ff
     ff ff ff ff 00 43 01 04 da c0 00 b4 ac 1b 1c 1d
     26 02 06 01 04 00 01 00 01 02 02 80 00 02 02 02
     00 02 02 42 00 02 06 41 04 00 00 da c0 02 08 40
     06 00 64 00 01 01 00

Notes:

The TCP checksum shown (0x0449) is wrong, it should be 0x4be9.

RFC 9252, "BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)", July 2022

Source of RFC: bess (rtg)

Errata ID: 7134
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Ketan Talaulikar
Date Reported: 2022-09-15
Verifier Name: James N Guichard
Date Verified: 2023-05-31

Section 6.4 says:

                  +---------------------------------------+
                  |  RD (8 octets)                        |
                  +---------------------------------------+
                  |  Ethernet Tag ID (4 octets)           |
                  +---------------------------------------+
                  |  IP Address Length (1 octet)          |
                  +---------------------------------------+
                  |  Originating Router's IP Address      |
                  |          (4 or 16 octets)             |
                  +---------------------------------------+

                        Figure 10: EVPN Route Type 4

It should say:

                  +---------------------------------------+
                  |  RD (8 octets)                        |
                  +---------------------------------------+
                  |Ethernet Segment Identifier (10 octets)|
                  +---------------------------------------+
                  |  IP Address Length (1 octet)          |
                  +---------------------------------------+
                  |  Originating Router's IP Address      |
                  |          (4 or 16 octets)             |
                  +---------------------------------------+

                        Figure 10: EVPN Route Type 4

Notes:

The 2nd field in the figure should be "Ethernet Segment Identifier" of size 10 octets instead of the "Ethernet Tag ID" of size 4 octets.

RFC7432 is the EVPN specification for Ethernet Segment Route (Type 4) and hence the format in section 7.4 of RFC7432 is the correct one.
RFC9252 has an error when showing the encoding format of this EVPN Route Type 4 as a reminder in Figure 10 in section 6.4.

This is an editorial error.

RFC 9260, "Stream Control Transmission Protocol", June 2022

Source of RFC: tsvwg (wit)

Errata ID: 7148
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Michael Tüxen
Date Reported: 2022-10-06
Verifier Name: Martin Duke
Date Verified: 2022-10-06

Section 3.3.3 says:

A receiver of an INIT ACK chunk with the a_rwnd value set to a
value smaller than 1500 MUST discard the packet, SHOULD send a
packet in response containing an ABORT chunk and using the
Initiate Tag as the Verification Tag, and MUST NOT change the
state of any existing association.

It should say:

If an endpoint in the COOKIE-WAIT state receives an INIT ACK chunk
with the a_rwnd value set to a value smaller than 1500, it MUST
destroy the TCB and SHOULD send an ABORT chunk.  If such an
INIT ACK chunk is received in any state other than CLOSED or
COOKIE-WAIT, it SHOULD be discarded silently (see Section 5.2.3).

Notes:

The handling of a_rwnd < 1500 should be similar to the handling of OS = 0 or MIS = 0.

Errata ID: 7387
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Michael Tüxen
Date Reported: 2023-03-16
Verifier Name: Martin Duke
Date Verified: 2023-04-27

Section 5.2.4.1 says:

   Endpoint A                                          Endpoint Z
   <-------------- Association is established---------------------->
   Tag=Tag_A                                             Tag=Tag_Z
   <--------------------------------------------------------------->
   {A crashes and restarts}
   {app sets up an association with Z}
   (build TCB)
   INIT [I-Tag=Tag_A'
         & other info]  --------\
   (Start T1-init timer)         \
   (Enter COOKIE-WAIT state)      \---> (find an existing TCB,
                                         populate TieTags if needed,
                                         compose Cookie_Z with Tie-Tags
                                         and other info)
                                   /--- INIT ACK [Veri Tag=Tag_A',
                                  /               I-Tag=Tag_Z',
   (Cancel T1-init timer) <------/                Cookie_Z]
                                        (leave original TCB in place)
   COOKIE ECHO [Veri=Tag_Z',
                Cookie_Z]-------\
   (Start T1-init timer)         \
   (Enter COOKIE-ECHOED state)    \---> (Find existing association,
                                         Tie-Tags in Cookie_Z match
                                         Tie-Tags in TCB,
                                         Tags do not match, i.e.,
                                         case X X M M above,
                                         Announce Restart to ULP
                                         and reset association).
                                  /---- COOKIE ACK
   (Cancel T1-init timer, <------/
    Enter ESTABLISHED state)
   {app sends 1st user data; strm 0}
   DATA [TSN=Initial TSN_A
       Strm=0,Seq=0 & user data]--\
   (Start T3-rtx timer)            \
                                    \->
                                 /--- SACK [TSN Ack=init TSN_A,Block=0]
   (Cancel T3-rtx timer) <------/

It should say:

   Endpoint A                                          Endpoint Z
   <-------------- Association is established---------------------->
   Tag=Tag_A                                             Tag=Tag_Z
   <--------------------------------------------------------------->
   {A crashes and restarts}
   {app sets up an association with Z}
   (build TCB)
   INIT [I-Tag=Tag_A'
         & other info]  --------\
   (Start T1-init timer)         \
   (Enter COOKIE-WAIT state)      \---> (find an existing TCB,
                                         populate TieTags if needed,
                                         compose Cookie_Z with Tie-Tags
                                         and other info)
                                   /--- INIT ACK [Veri Tag=Tag_A',
                                  /               I-Tag=Tag_Z',
   (Cancel T1-init timer) <------/                Cookie_Z]
                                        (leave original TCB in place)
   COOKIE ECHO [Veri=Tag_Z',
                Cookie_Z]-------\
   (Start T1-cookie timer)       \
   (Enter COOKIE-ECHOED state)    \---> (Find existing association,
                                         Tie-Tags in Cookie_Z match
                                         Tie-Tags in TCB,
                                         Tags do not match, i.e.,
                                         case X X M M above,
                                         Announce Restart to ULP
                                         and reset association).
                                  /---- COOKIE ACK
   (Cancel T1-cookie timer, <----/
    Enter ESTABLISHED state)
   {app sends 1st user data; strm 0}
   DATA [TSN=Initial TSN_A
       Strm=0,Seq=0 & user data]--\
   (Start T3-rtx timer)            \
                                    \->
                                 /--- SACK [TSN Ack=init TSN_A,Block=0]
   (Cancel T3-rtx timer) <------/

Notes:

A packet containing an COOKIE-ECHO chunk is protected against loss by the T1-cookie timer, not the T1-init timer.

Errata ID: 7147
Status: Verified
Type: Editorial
Publication Format(s) : HTML
Reported By: Michael Tüxen
Date Reported: 2022-10-06
Verifier Name: RFC Editor
Date Verified: 2022-10-10

Section 3.2 says:

          +----+--------------------------------------------------+
          | 00 | Stop processing this SCTP packet and discard the |
          |    | unrecognized chunk and all further chunks.       |
          +----+--------------------------------------------------+
          | 01 | Stop processing this SCTP packet, discard the    |
          |    | unrecognized chunk and all further chunks, and   |
          |    | report the unrecognized chunk in an ERROR chunk  |
          |    | using the 'Unrecognized Chunk Type' error cause. |
          +----+--------------------------------------------------+
          | 10 | Skip this chunk and continue processing.         |
          +----+--------------------------------------------------+
          | 11 | Skip this chunk and continue processing, but     |
          |    | report it in an ERROR chunk using the            |
          |    | 'Unrecognized Chunk Type' error cause.           |
          +----+--------------------------------------------------+

It should say:

          +----+--------------------------------------------------+
          | 00 | Stop processing this SCTP packet and discard the |
          |    | unrecognized chunk and all further chunks.       |
          +----+--------------------------------------------------+
          | 01 | Stop processing this SCTP packet, discard the    |
          |    | unrecognized chunk and all further chunks, and   |
          |    | report the unrecognized chunk in an ERROR chunk  |
          |    | using the "Unrecognized Chunk Type" error cause. |
          +----+--------------------------------------------------+
          | 10 | Skip this chunk and continue processing.         |
          +----+--------------------------------------------------+
          | 11 | Skip this chunk and continue processing, but     |
          |    | report it in an ERROR chunk using the            |
          |    | "Unrecognized Chunk Type" error cause.           |
          +----+--------------------------------------------------+

Notes:

In the rest of the document, error cause names are enclosed in double quotes, not in single quotes.

RFC 9276, "Guidance for NSEC3 Parameter Settings", August 2022

Source of RFC: dnsop (ops)

Errata ID: 7104
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Stefan Ubbink
Date Reported: 2022-08-26
Verifier Name: RFC Editor
Date Verified: 2022-08-26

Section 2.2 says:

Smaller zones, or large
but relatively static zones, are encouraged to not use the opt-opt
flag and to take advantage of DNSSEC's authenticated denial of
existence.

It should say:

Smaller zones, or large
but relatively static zones, are encouraged to not use the opt-out
flag and to take advantage of DNSSEC's authenticated denial of
existence.

Notes:

There is a typo, "opt-opt" should be "opt-out".

RFC 9285, "The Base45 Data Encoding", August 2022

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 7078
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2022-08-10
Verifier Name: RFC Editor
Date Verified: 2022-08-10

Section 4 says:

   QR codes have a limited ability to store binary data.  In practice,
   binary data have to be encoded in characters according to one of the
   modes already defined in the standard for QR codes.  The easiest mode
   to use in called Alphanumeric mode (see Section 7.3.4 and Table 2 of
   [ISO18004].  Unfortunately Alphanumeric mode uses 45 different
   characters which implies neither Base32 nor Base64 are very effective
   encodings.

It should say:

   QR codes have a limited ability to store binary data.  In practice,
   binary data have to be encoded in characters according to one of the
   modes already defined in the standard for QR codes.  The easiest mode
   to use in called Alphanumeric mode (see Section 7.3.4 and Table 2 of
   [ISO18004]).  Unfortunately Alphanumeric mode uses 45 different
   characters which implies neither Base32 nor Base64 are very effective
   encodings.

Notes:

Missing closing bracket.

RFC 9286, "Manifests for the Resource Public Key Infrastructure (RPKI)", June 2022

Source of RFC: sidrops (ops)

Errata ID: 7118
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Job Snijders
Date Reported: 2022-09-03
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2022-09-06

Section Appendix A says:

fileList           SEQUENCE SIZE (0..MAX) OF FileAndHash

It should say:

fileList           SEQUENCE SIZE (1..MAX) OF FileAndHash

Notes:

Section 7 specifies " A CA's manifest will always contain at least one entry"; therefor, a fileList sequence of size 0 is invalid.

RFC 9291, "A YANG Network Data Model for Layer 2 VPNs", September 2022

Source of RFC: opsawg (ops)

Errata ID: 7162
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Nikolai Malykh
Date Reported: 2022-10-13
Verifier Name: Rob Wilton
Date Verified: 2022-10-14

Section 9 says:

   'ethernet-segments' and 'vpn-services':  An attacker who is able to
      access network nodes can undertake various attacks, such as
      deleting a running L2VPN service, interrupting all the traffic of
      a client.  In addition, an attacker may modify the attributes of a
      running service (e.g., QoS, bandwidth) or an ES, leading to
      malfunctioning of the service and therefore to SLA violations.  In
      addition, an attacker could attempt to create an L2VPN service,
      add a new network access, or intercept/redirect the traffic to a
      non-authorized node.  In addition to using NACM to prevent
      authorized access, such activity can be detected by adequately
      monitoring and tracking network configuration changes.

It should say:

   'ethernet-segments' and 'vpn-services':  An attacker who is able to
      access network nodes can undertake various attacks, such as
      deleting a running L2VPN service, interrupting all the traffic of
      a client.  In addition, an attacker may modify the attributes of a
      running service (e.g., QoS, bandwidth) or an ES, leading to
      malfunctioning of the service and therefore to SLA violations.  In
      addition, an attacker could attempt to create an L2VPN service,
      add a new network access, or intercept/redirect the traffic to a
      non-authorized node.  In addition to using NACM to prevent
      unauthorized access, such activity can be detected by adequately
      monitoring and tracking network configuration changes.

Notes:

Typo in last sentence, should be "unauthorized".

Errata ID: 7163
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2022-10-13
Verifier Name: RFC Editor
Date Verified: 2022-10-13

Section A.2 says:

                      Figure 25: An Example of VPLS

It should say:

                      Figure 25: An Example of VPWS

Notes:

Typo

RFC 9303, "Locator/ID Separation Protocol Security (LISP-SEC)", October 2022

Source of RFC: lisp (rtg)

Errata ID: 7423
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Nikolai Malykh
Date Reported: 2023-04-15
Verifier Name: James N Guichard
Date Verified: 2023-04-19

Section 6.9 says:

ITR MUST set the 'EID HMAC ID' field to 0 before computing the HMAC.

It should say:

ITR MUST set the 'EID HMAC' field to 0 before computing the HMAC.

Notes:

0 (zero) must be set in the 'EID HMAC' field, not in the 'EID HMAC ID' field

RFC 9316, "Intent Classification", October 2022

Source of RFC: IRTF

Errata ID: 7178
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Nikolai Malykh
Date Reported: 2022-10-22
Verifier Name: Colin Perkins
Date Verified: 2022-10-23

Section 1.1 says:

   Furthermore, this document is already proving to be extremely
   relevant to the research community as it has been used as the basis
   for proposing self-generated Intent-based systems [Bezahaf19], for
   advancing Virtual Network Function (VNF) placement solutions based on
   Internet-Based Networks (IBNs) that rely on defining user intent
   profiles corresponding to abstract network services [Leivadeas21],
   for improving existing solutions in provisioning intent-based
   networks, for proposing new approaches to service management
   [Davoli21], and even for defining grammars for users to specify the
   high-level requirements for blockchain selection in the form of
   intent [Padovan20].  As well, the document has been mentioned in
   surveys addressing the topic of intelligent intent-based autonomous
   networks [Mehmood21] [Szilagyi21].

It should say:

   Furthermore, this document is already proving to be extremely
   relevant to the research community as it has been used as the basis
   for proposing self-generated Intent-based systems [Bezahaf19], for
   advancing Virtual Network Function (VNF) placement solutions based on
   Intent-Based Networks (IBNs) that rely on defining user intent
   profiles corresponding to abstract network services [Leivadeas21],
   for improving existing solutions in provisioning intent-based
   networks, for proposing new approaches to service management
   [Davoli21], and even for defining grammars for users to specify the
   high-level requirements for blockchain selection in the form of
   intent [Padovan20].  As well, the document has been mentioned in
   surveys addressing the topic of intelligent intent-based autonomous
   networks [Mehmood21] [Szilagyi21].

Notes:

Typo (Internet-Based instead Intent-Based)

Errata ID: 7182
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2022-10-26
Verifier Name: RFC Editor
Date Verified: 2022-10-26

Section 3 says:

   Other definitions relevant to this document, such as intent scope,
   intent network scope, intent abstraction, intent abstraction, and
   intent life cycle are available in Section 5.

It should say:

   Other definitions relevant to this document, such as intent scope,
   intent network scope, intent abstraction, and intent life cycle 
   are available in Section 5.

Notes:

Unnecessary repeat "intent abstraction"

RFC 9350, "IGP Flexible Algorithm", February 2023

Source of RFC: lsr (rtg)

Errata ID: 7406
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Barry Friedman
Date Reported: 2023-03-28
Verifier Name: John Scudder
Date Verified: 2023-04-13

Section 5.1 says:

The IS-IS FAD sub-TLV MAY be advertised in a
Label Switched Path (LSP) of any number.

It should say:

The IS-IS FAD sub-TLV MAY be advertised in a
Link State PDU (LSP) of any number.

Notes:

I assume LSP is meant to refer to the PDU carrying the FAD, not a Label Switched Path.

RFC 9380, "Hashing to Elliptic Curves", August 2023

Source of RFC: IRTF

Errata ID: 7844
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Lynne Bartholomew
Date Reported: 2024-03-07
Verifier Name: RFC Editor
Date Verified: 2024-03-08

Section 10.6 says:

({#hashtofield-expand-xmd}, step 10)

It should say:

(Section 5.3.1, step 10)

Notes:

Same issue as Erratum #7144 for RFC 9277: a typo in the markdown (curly-bracketed entry that should have been converted to an xref entry in the XML) that got through the publication process.

RFC 9399, "Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates", May 2023

Source of RFC: lamps (sec)

Errata ID: 7534
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Preston Locke
Date Reported: 2023-06-05
Verifier Name: RFC Editor
Date Verified: 2023-06-05

Section 6 says:

   After a certification path is successfully validated, the replying
   party trusts the information that the CA includes in the certificate,
   including any certificate extensions.

It should say:

   After a certification path is successfully validated, the relying
   party trusts the information that the CA includes in the certificate,
   including any certificate extensions.

Notes:

The phrase "replying party" is a typo and should be "relying party"

Errata ID: 7535
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Preston Locke
Date Reported: 2023-06-05
Verifier Name: RFC Editor
Date Verified: 2023-06-05

Section 6 says:

   Consequently, if relying party software accepts a CA, then it should
   be prepared to (unquestioningly) display the associated logotypes to
   its human user, given that it is configured to do so.  Information
   about the logotypes is provided so that the replying party software
   can select the one that will best meet the needs of the human user.
   This choice depends on the abilities of the human user, as well as
   the capabilities of the platform on which the replaying party
   software is running.

It should say:

   Consequently, if relying party software accepts a CA, then it should
   be prepared to (unquestioningly) display the associated logotypes to
   its human user, given that it is configured to do so.  Information
   about the logotypes is provided so that the relying party software
   can select the one that will best meet the needs of the human user.
   This choice depends on the abilities of the human user, as well as
   the capabilities of the platform on which the relying party
   software is running.

Notes:

The phrases "replying party" and "replaying party" are typos and should be "relying party"

Errata ID: 7536
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Preston Locke
Date Reported: 2023-06-05
Verifier Name: RFC Editor
Date Verified: 2023-06-05

Section 6 says:

   Care is needed when designing replying party software to ensure that
   an appropriate context of logotype information is provided.

It should say:

   Care is needed when designing relying party software to ensure that
   an appropriate context of logotype information is provided.

Notes:

The phrase "replying party" is a typo and should be "relying party"

RFC 9449, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", September 2023

Source of RFC: oauth (sec)

Errata ID: 7646
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Michiel Albracht
Date Reported: 2023-09-18
Verifier Name: RFC Editor
Date Verified: 2023-09-18

Section 4.2 says:

When the authentication server or resource server provides a DPoP-Nonce

It should say:

When the authorization server or resource server provides a DPoP-Nonce

Notes:

authentication server must be authorization server

RFC 9463, "DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)", November 2023

Source of RFC: add (int)

Errata ID: 7804
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: David Härdeman
Date Reported: 2024-02-09
Verifier Name: Eric Vyncke
Date Verified: 2024-03-17

Section 6.1 says:

Note that the "Addr Length", "ipv6-address(es)", and "Service 
Parameters (SvcParams)" fields are not present if the ADN-only mode 
is used (Section 3.1.6).

It should say:

Note that the "Addr Length", "ipv6-address(es)", "SvcParams 
Length", and "Service Parameters (SvcParams)" fields are not 
present if the ADN-only mode is used (Section 3.1.6).

Notes:

The paragraph is presumably copied from section 4.1 (DHCPv6 Encrypted DNS Option), and omits the "SvcParams Length" field, which is only present in the IPv6 RA Encrypted DNS Option. Mandating the presence of a superfluous length field when using the ADN-only mode seems like an oversight.

Errata ID: 7784
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Tomek Mrugalski
Date Reported: 2024-01-25
Verifier Name: RFC Editor
Date Verified: 2024-01-25

Section 3.1.5 says:

dohpath:  Used to supply a relative DoH URI Template (Section 5.1 of
      [RFC9461]).

It should say:

dohpath:  Used to supply a relative DoH URI Template (Section 5 of
      [RFC9461]).

Notes:

Just a minor reference correction. There is no Section 5.1 in RFC 9461. The dohpath parameter is defined in Section 5.

RFC 9480, "Certificate Management Protocol (CMP) Updates", November 2023

Source of RFC: lamps (sec)

Errata ID: 7822
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: John Gray
Date Reported: 2024-02-26
Verifier Name: Paul Wouters
Date Verified: 2024-02-26

Section A.2 says:

PKIHeader ::= SEQUENCE {
       pvno                INTEGER     { cmp1999(1), cmp2000(2),
                                         cmp2012(3) },

It should say:

PKIHeader ::= SEQUENCE {
       pvno                INTEGER     { cmp1999(1), cmp2000(2),
                                         cmp2021(3) },

Notes:

There is a typo in the ASN.1 module regarding the cmp version. This was noticed in the RFC 4210-bis draft document and has been corrected there, but also affects this document which has already been published.

RFC 9481, "Certificate Management Protocol (CMP) Algorithms", November 2023

Source of RFC: lamps (sec)

Errata ID: 7800
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Russ Housley
Date Reported: 2024-02-07
Verifier Name: RFC Editor
Date Verified: 2024-02-07

Section 6.2.3 says:

   The KMAC algorithm is defined in [RFC8702] and FIPS SP 800-185
   [NIST.SP.800-185]].

It should say:

   The KMAC algorithm is defined in [RFC8702] and NIST SP 800-185
   [NIST.SP.800-185].

Notes:

Correct two errors. First, the referenced document is a Special Publication, not a FIPS. Second, there are two closing brackets, but there should only be one.

RFC 9487, "Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX)", November 2023

Source of RFC: opsawg (ops)

Errata ID: 7728
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Ahmed Elhassany
Date Reported: 2023-12-12
Verifier Name: Rob Wilton
Date Verified: 2024-01-15

Section 5.1.10 says:

5.1.10.  srhSegmentIPv6LocatorLength

   ElementID:  501
   Name:  srhSegmentIPv6LocatorLength
   Data Type Semantics:  default
   Description:  The length of the SRH segment IPv6 locator specified as
      the number of significant bits.  Together with srhSegmentIPv6, it
      enables the calculation of the SRv6 Locator.
   Additional Information:  See Section 3.1 of [RFC8986] for more
      details about the SID format.
   Reference:  RFC 9487

It should say:

5.1.10.  srhSegmentIPv6LocatorLength

   ElementID:  501
   Name:  srhSegmentIPv6LocatorLength
   Abstract Data Type:  unsigned8
   Data Type Semantics:  default
   Description:  The length of the SRH segment IPv6 locator specified as
      the number of significant bits.  Together with srhSegmentIPv6, it
      enables the calculation of the SRv6 Locator.
   Additional Information:  See Section 3.1 of [RFC8986] for more
      details about the SID format.
   Reference:  RFC 9487

Notes:

I'm not an expert on RFC8986, I assumed it's unsigned8 but need help to check this is the case indeed

RFC 9505, "A Survey of Worldwide Censorship Techniques", November 2023

Source of RFC: IRTF

Errata ID: 7707
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Nikolai Malykh
Date Reported: 2023-11-21
Verifier Name: Colin Perkins
Date Verified: 2023-11-27

Section 10 says:

   [Senft-2013]
              , Crete-Nishihata, M., Dalek, J., Hardy, S., Hilts, A.,
              Kleemola, K., Ng, J., Poetranto, I., Senft, A., Sinpeng,
              A., Sonne, B., and G. Wiseman, "Asia Chats: Analyzing
              Information Controls and Privacy in Asian Messaging
              Applications", November 2013,
              <https://citizenlab.org/2013/11/asia-chats-analyzing-
              information-controls-privacy-asian-messaging-
              applications/>.

It should say:

   [Senft-2013]
              Crete-Nishihata, M., Dalek, J., Hardy, S., Hilts, A.,
              Kleemola, K., Ng, J., Poetranto, I., Senft, A., Sinpeng,
              A., Sonne, B., and G. Wiseman, "Asia Chats: Analyzing
              Information Controls and Privacy in Asian Messaging
              Applications", November 2013,
              <https://citizenlab.org/2013/11/asia-chats-analyzing-
              information-controls-privacy-asian-messaging-
              applications/>.

Notes:

Unnecessary comma at the beginning.

RFC 9513, "OSPFv3 Extensions for Segment Routing over IPv6 (SRv6)", December 2023

Source of RFC: lsr (rtg)

Errata ID: 7766
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: tom petch
Date Reported: 2024-01-16
Verifier Name: John Scudder
Date Verified: 2024-01-16

Section 6 says:

   The AC-bit (value 0x80) in the OSPFv3 PrefixOptions field [RFC5340]
   is defined to advertise the anycast property:

                          0  1  2  3  4  5  6  7
                         +--+--+--+--+--+--+--+--+
                         |AC|EL| N|DN| P| x|LA|NU|
                         +--+--+--+--+--+--+--+--+

                   Figure 2: OSPFv3 Prefix Options Field

It should say:

   The AC-bit (value 0x80) in the OSPFv3 PrefixOptions field [RFC5340]
   is defined to advertise the anycast property:

                          0  1  2  3  4  5  6  7
                         +--+--+--+--+--+--+--+--+
                         |AC| E| N|DN| P| x|LA|NU|
                         +--+--+--+--+--+--+--+--+

                   Figure 2: OSPFv3 Prefix Options Field

Notes:

Bit 1 is defined in RFC9089 section 6 as
* Bit 0x40 in the "OSPFv3 Prefix Options (8 bits)" registry has been
allocated to the E-Flag (ELC Flag).
It is not the EL bit or flag.

Verifier note: I added a space before the E in Tom's proposed correction, to make the diagram line up.

RFC 9514, "Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing over IPv6 (SRv6)", December 2023

Source of RFC: idr (rtg)

Errata ID: 7737
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Ketan Talaulikar
Date Reported: 2023-12-20
Verifier Name: John Scudder
Date Verified: 2024-01-16

Section 5.1 says:

   The IPv6 Prefix matching the locator may also be advertised as prefix
   reachability by the underlying routing protocol.  In this case, the
   Prefix NLRI would also be associated with the Prefix Metric TLV
   [RFC7752] that carries the routing metric for this prefix.  A Prefix
   NLRI that has been advertised with a SRv6 Locator TLV is also
   considered a normal routing prefix (i.e., prefix reachability) only
   when there is also an IGP Metric TLV (TLV 1095) associated it.
   Otherwise, it is only considered an SRv6 Locator advertisement.

It should say:

   The IPv6 Prefix matching the locator may also be advertised as prefix
   reachability by the underlying routing protocol.  In this case, the
   Prefix NLRI would also be associated with the Prefix Metric TLV
   [RFC7752] that carries the routing metric for this prefix.  A Prefix
   NLRI that has been advertised with a SRv6 Locator TLV is also
   considered a normal routing prefix (i.e., prefix reachability) only
   when there is also a Prefix Metric TLV (TLV 1155) associated with it.
   Otherwise, it is only considered an SRv6 Locator advertisement.

Notes:

The current text is referring to the wrong BGP-LS TLV. Since the SRv6 Locator TLV is associated with a Prefix NLRI, the "Prefix Metric TLV (TLV 1155)" should be referenced here since the "IGP metric TLV (TLV 1095)" is associated with a Link NLRI.

Verifier note: In addition to the fix proposed by Ketan, I added a preposition: "associated with it".

RFC 9522, "Overview and Principles of Internet Traffic Engineering", January 2024

Source of RFC: teas (rtg)

Errata ID: 7815
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2024-02-20
Verifier Name: RFC Editor
Date Verified: 2024-02-20

Section 5.1.3.7 says:

   IP Flow Information Export (IPFIX) [RFC5470] defines an architecture
   that is very similar to the RTFM architecture and includes Metering,
   Exporting, and Collecting Processes.  [RFC5472] describes the
   applicability of IPFIX and makes a comparison with RTFM, pointing out
   that, architecturally, while RTM talks about devices, IPFIX deals
   with processes to clarify that multiple of those processes may be co-
   located on the same machine.  The IPFIX protocol [RFC7011] is widely
   implemented.

It should say:

   IP Flow Information Export (IPFIX) [RFC5470] defines an architecture
   that is very similar to the RTFM architecture and includes Metering,
   Exporting, and Collecting Processes.  [RFC5472] describes the
   applicability of IPFIX and makes a comparison with RTFM, pointing out
   that, architecturally, while RTFM talks about devices, IPFIX deals
   with processes to clarify that multiple of those processes may be co-
   located on the same machine.  The IPFIX protocol [RFC7011] is widely
   implemented.

Notes:

Missing a letter in the acronym RTFM.

RTM > RTFM

RFC 9526, "Simple Provisioning of Public Names for Residential Networks", January 2024

Source of RFC: homenet (int)

Errata ID: 7792
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Samuel K. Lam
Date Reported: 2024-01-30
Verifier Name: RFC Editor
Date Verified: 2024-01-31

The Abstract says:

Home Naming Authority (NHA)

It should say:

Homenet Naming Authority (HNA)

Notes:

In the second paragraph of this RFC's Abstract:

"Home" should be corrected to "Homenet", and
"(NHA)" should be corrected to "(HNA)".

The rest of this RFC uses
"Homenet Naming Authority (HNA)"
as opposed to
"Home Naming Authority (NHA)".

RFC 9537, "Redacted Fields in the Registration Data Access Protocol (RDAP) Response", March 2024

Source of RFC: regext (art)

Errata ID: 7876
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Jasdip Singh
Date Reported: 2024-03-30
Verifier Name: Orie Steele
Date Verified: 2024-04-12

Section 4.2 says:

Figure 13:

  {
    "rdapConformance": [
      "rdap_level_0"
    ],
    "domainSearchResults":[
      {
        "objectClassName": "domain",
        "handle": "ABC121",
        "ldhName": "example1.com",
        "links":[
          {
            "value":"https://example.com/rdap/domain/example1.com",
            "rel":"self",
            "href":"https://example.com/rdap/domain/example1.com",
            "type":"application/rdap+json"
          },
          {
            "value":"https://example.com/rdap/domain/example1.com",
            "rel":"related",
            "href":"https://example.com/rdap/domain/example1.com",
            "type":"application/rdap+json"
          }
        ]
      },
      {
        "objectClassName": "domain",
        "handle": "ABC122",
        "ldhName": "example2.com",
        "links":[
          {
            "value":"https://example.com/rdap/domain/example2.com",
            "rel":"self",
            "href":"https://example.com/rdap/domain/example2.com",
            "type":"application/rdap+json"
          },
          {
            "value":"https://example.com/rdap/domain/example2.com",
            "rel":"related",
            "href":"https://example.com/rdap/domain/example2.com",
            "type":"application/rdap+json"
          }
        ]
      }
    ]
  }

Figure 14:

  {
    "rdapConformance": [
      "rdap_level_0",
      "redacted"
    ],
    "domainSearchResults":[
      {
        "objectClassName": "domain",
        "ldhName": "example1.com",
        "links":[
          {
            "value":"https://example.com/rdap/domain/example1.com",
            "rel":"self",
            "href":"https://example.com/rdap/domain/example1.com",
            "type":"application/rdap+json"
          },
          {
            "value":"https://example.com/rdap/domain/example1.com",
            "rel":"related",
            "href":"https://example.com/rdap/domain/example1.com",
            "type":"application/rdap+json"
          }
        ],
        "redacted": [
          {
            "name": {
              "type": "Registry Domain ID"
            },
            "prePath": "$.domainSearchResults[0].handle",
            "pathLang": "jsonpath",
            "method": "removal",
            "reason": {
              "type": "Server policy"
            }
          }
        ]
      },
      {
        "objectClassName": "domain",
        "ldhName": "example2.com",
        "links":[
          {
            "value":"https://example.com/rdap/domain/example2.com",
            "rel":"self",
            "href":"https://example.com/rdap/domain/example2.com",
            "type":"application/rdap+json"
          },
          {
            "value":"https://example.com/rdap/domain/example2.com",
            "rel":"related",
            "href":"https://example.com/rdap/domain/example2.com",
            "type":"application/rdap+json"
          }
        ],
        "redacted": [
          {
            "name": {
              "description": "Registry Domain ID"
            },
            "prePath": "$.domainSearchResults[1].handle",
            "pathLang": "jsonpath",
            "method": "removal",
            "reason": {
              "description": "Server policy"
            }
          }
        ]
      }
    ]
  }

It should say:

Figure 13:

  {
    "rdapConformance": [
      "rdap_level_0"
    ],
    "domainSearchResults":[
      {
        "objectClassName": "domain",
        "handle": "ABC121",
        "ldhName": "example1.com",
        "links":[
          {
            "value":"https://example.com/rdap/domain/example1.com",
            "rel":"self",
            "href":"https://example.com/rdap/domain/example1.com",
            "type":"application/rdap+json"
          },
          {
            "value":"https://example.com/rdap/domain/example1.com",
            "rel":"related",
            "href":"https://example.net/rdap/v1/domain/example1.com",
            "type":"application/rdap+json"
          }
        ]
      },
      {
        "objectClassName": "domain",
        "handle": "ABC122",
        "ldhName": "example2.com",
        "links":[
          {
            "value":"https://example.com/rdap/domain/example2.com",
            "rel":"self",
            "href":"https://example.com/rdap/domain/example2.com",
            "type":"application/rdap+json"
          },
          {
            "value":"https://example.com/rdap/domain/example2.com",
            "rel":"related",
            "href":"https://example.net/rdap/v1/domain/example2.com",
            "type":"application/rdap+json"
          }
        ]
      }
    ]
  }

Figure 14:

  {
    "rdapConformance": [
      "rdap_level_0",
      "redacted"
    ],
    "domainSearchResults":[
      {
        "objectClassName": "domain",
        "ldhName": "example1.com",
        "links":[
          {
            "value":"https://example.com/rdap/domain/example1.com",
            "rel":"self",
            "href":"https://example.com/rdap/domain/example1.com",
            "type":"application/rdap+json"
          },
          {
            "value":"https://example.com/rdap/domain/example1.com",
            "rel":"related",
            "href":"https://example.net/rdap/v1/domain/example1.com",
            "type":"application/rdap+json"
          }
        ],
        "redacted": [
          {
            "name": {
              "type": "Registry Domain ID"
            },
            "prePath": "$.domainSearchResults[0].handle",
            "pathLang": "jsonpath",
            "method": "removal",
            "reason": {
              "type": "Server policy"
            }
          }
        ]
      },
      {
        "objectClassName": "domain",
        "ldhName": "example2.com",
        "links":[
          {
            "value":"https://example.com/rdap/domain/example2.com",
            "rel":"self",
            "href":"https://example.com/rdap/domain/example2.com",
            "type":"application/rdap+json"
          },
          {
            "value":"https://example.com/rdap/domain/example2.com",
            "rel":"related",
            "href":"https://example.net/rdap/v1/domain/example2.com",
            "type":"application/rdap+json"
          }
        ],
        "redacted": [
          {
            "name": {
              "description": "Registry Domain ID"
            },
            "prePath": "$.domainSearchResults[1].handle",
            "pathLang": "jsonpath",
            "method": "removal",
            "reason": {
              "description": "Server policy"
            }
          }
        ]
      }
    ]
  }

Notes:

Noticed that the "self" and "related" links in Figure 13 and Figure 14 examples have the same "href" value. From RFC 9083: A "related" link relation MUST NOT include an "href" URI that is the same as the "self" link relation "href" URI to reduce the risk of infinite client processing loops. (The new "href" values for the "related" links are per James Gould's earlier suggestion.)

RFC 9539, "Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS", February 2024

Source of RFC: dprive (int)

Errata ID: 7831
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Kevin P. Fleming
Date Reported: 2024-02-29
Verifier Name: Paul Wouters
Date Verified: 2024-03-04

Section 4.6.1 says:

E-status[X] is success and (T0 - E-last-response[X]) < persistence.

It should say:

E-status[X] is success and (T0 - E-last-response[X]) < E-persistence.

Notes:

The formula should reference the persistence value for the protocol in use.

Errata ID: 7832
Status: Verified
Type: Technical
Publication Format(s) : TEXT, HTML
Reported By: Kevin P. Fleming
Date Reported: 2024-02-29
Verifier Name: Paul Wouters
Date Verified: 2024-03-04

Section 4.6.3 says:

*  E-status[X] is either fail or timeout and (T0 - E-completed[X]) >
      damping, or

It should say:

*  E-status[X] is either fail or timeout and (T0 - E-completed[X]) >
      E-damping, or

Notes:

The formula should reference the damping value for the protocol in use.

RFC 9552, "Distribution of Link-State and Traffic Engineering Information Using BGP", December 2023

Source of RFC: idr (rtg)

Errata ID: 7789
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, HTML
Reported By: Long Dao
Date Reported: 2024-01-30
Verifier Name: RFC Editor
Date Verified: 2024-01-31

Section 5.3.1.1 says:

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              Type             |             Length            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |O|T|E|B|R|V|   |
  +-+-+-+-+-+-+-+-+

It should say:

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              Type             |             Length            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |O|A|E|B|R|V|   |
  +-+-+-+-+-+-+-+-+

Notes:

"T" flag should be changed to "A" to match the description below

Status: Reported (762)

RFC 2, "Host software", April 1969

Source of RFC: Legacy

Errata ID: 5613
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Emil Fihman
Date Reported: 2019-01-27

Throughout the document, when it says:

[unknown title]
[page 1 missing]

It should say:

Title: Host Software
Author: Bill Duvall
Installation: Standford Research Institute
Date: 9 April 1969
Network Working Group Request for Comment: 2

Notes:

On https://tools.ietf.org/html/rfc2
it says:

[unknown title]
[page 1 missing]

However, page 1 has resurfaced here: https://write.as/365-rfcs/update-scans-of-early-rfcs
in particular: https://tinysubversions.com/pics/rfc-update-01-03.png

More scans area available here: https://www.computerhistory.org/collections/catalog/102661172

Please adjust the online version(s) accordingly.

RFC 270, "Correction to BBN Report No. 1822 (NIC NO 7958)", January 1972

Source of RFC: Legacy

Errata ID: 5655
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Darius Kazemi
Date Reported: 2019-03-13

Throughout the document, when it says:

Notes:

The normative text version of RFC 270 is missing four attached pages that are referenced in the RFC. A PDF scan of the complete RFC 270 is available at https://www.rfc-editor.org/info/rfc270

RFC 304, "Data Management System Proposal for the ARPA Network", February 1972

Source of RFC: Legacy

Errata ID: 5885
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Darius Kazemi
Date Reported: 2019-10-28

Throughout the document, when it says:

n/a, see note

It should say:

n/a, see note

Notes:

Page 8 of the text version of the RFC is out of order compared to the original document. Page 8 begins "The keyword statements of the language..." and ends "...the Rename Convention in the file transfer protocol."

This text should be inserted on page 3, right after "Maintenance of the files must be provided with the delete and add function applied to the container referenced data." and before "A second consideration in a catalog".

Readers can reference the scan at https://www.rfc-editor.org/rfc/rfc304.pdf for the correct ordering of sections.

RFC 822, "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES", August 1982

Note: This RFC has been obsoleted by RFC 2822

Note: This RFC has been updated by RFC 1123, RFC 2156, RFC 1327, RFC 1138, RFC 1148

Source of RFC: Legacy
Area Assignment: app

Errata ID: 7573
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ulrich Windl
Date Reported: 2023-07-24

Section 3.1.1 says:

        inserted.  Thus, the single line
            To:  "Joe & J. Harvey" <ddd @Org>, JJV @ BBN
        can be represented as:
            To:  "Joe & J. Harvey" <ddd @ Org>,
                    JJV@BBN
        and
            To:  "Joe & J. Harvey"
                            <ddd@ Org>, JJV
             @BBN
        and
            To:  "Joe &
             J. Harvey" <ddd @ Org>, JJV @ BBN

It should say:

        inserted.  Thus, the single line
            To:  "Joe & J. Harvey" <ddd @Org>, JJV @ BBN
        can be represented as:
            To:  "Joe & J. Harvey" <ddd @ Org>,
             JJV@BBN
        and
            To:  "Joe & J. Harvey"
             <ddd@ Org>, JJV
             @BBN
        and
            To:  "Joe &
             J. Harvey" <ddd @ Org>, JJV @ BBN

Notes:

Possibly arising from mis-interpreting RFC 733 section III.B.a (Folding and unfolding of headers) which says: "The general rule is that wherever there can be linear-white-space (NOT simply LWSP-chars), a CRLF immediately followed by AT LEAST one LWSP-char can instead be inserted."
This may be interpreted that when folding at one while space character an arbitrary amount of white space characters may be inserted at the next line, also saying that one white space in a header is equivalent to multiple white space characters.
subsequent revisions (RFC 2822, RFC 5322) are increasingly more clear on that:
"The general rule is that wherever this specification allows for folding white space (not simply WSP characters), a CRLF may be inserted before any WSP."

RFC 823, "DARPA Internet gateway", September 1982

Source of RFC: Legacy

Errata ID: 6824
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Greg Skinner
Date Reported: 2022-01-28

Throughout the document, when it says:

[10] Rosen,  E.,  "Exterior  Gateway  Protocol,"  IEN-209,   Bolt
          Beranek and Newman Inc., August 1982.

It should say:

[10] Rosen,  E.,  "Exterior  Gateway  Protocol,"  IEN-209,   Bolt
          Beranek and Newman Inc., August 1982, not issued.

Notes:

RFC823 references IEN-209, which was not issued, and won't be (https://www.rfc-editor.org/ien/scanned/ien209.pdf). I encourage discussion of whether it should reference RFC827 instead.

RFC 865, "Quote of the Day Protocol", May 1983

Source of RFC: Legacy

Errata ID: 7377
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Conroy Bogle
Date Reported: 2023-03-06

Section 865 says:

"...Once a connection is established 
 a short message is sent out 
 the connection..."

It should say:

"...Once a connection is established 
 a short message is sent out '<via>' <from> <to> <of> 
 the connection..."

Notes:

A minor grammatical error, perhaps due to the author thinking in code.

RFC 916, "Reliable Asynchronous Transfer Protocol (RATP)", October 1984

Source of RFC: Legacy

Errata ID: 7321
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Jules Maselbas
Date Reported: 2023-01-25

Section 5.3 says:

If SYN was set we assume that the other end crashed and has
attempted to open a new connection.  We respond by sending a
legal reset:

   <SN=received AN><AN=received SN+1 modulo 2><CTL=RST, ACK>

This will cause the other end, currently in the SYN-SENT state,
to close.  Flush the retransmission queue, inform the user
"Error: Connection reset", discard the packet, delete the TCB,
and go to the CLOSED state without any further processing.

If neither RST, FIN, nor SYN flags were set it is assumed that
this packet is a duplicate of one already received.  Send an
ACK back:

It should say:

If the SYN flag was set but the ACK was not set then we assume
that the other end crashed and has attempted to open a new connection.
We respond by sending a legal reset:

   <SN=received AN><AN=received SN+1 modulo 2><CTL=RST, ACK>

This will cause the other end, currently in the SYN-SENT state,
to close.  Flush the retransmission queue, inform the user
"Error: Connection reset", discard the packet, delete the TCB,
and go to the CLOSED state without any further processing.

If neither RST nor FIN flags were set, or if SYN and ACK flags
were set, it is assumed that this packet is a duplicate of one
already received.  Send an ACK back:

Notes:

Side A Side B
1. CLOSED LISTEN
2. [OPEN request]
SYN_SENT --> <SN=0><CTL=SYN> --> SYN_RECEIVED
3. ESTABLISHED <-- <SN=0><AN=1><CTL=SYN,ACK> <--
4. --> <SN=1><AN=0><CTL=ACK> ...
5. ... <SN=0><AN=1><CTL=SYN,ACK> <-- (retransmit)
6. (packet sent by A at 4. finally arrives to B)
... --> ESTABLISHED
7. (packet resent by B at 5. finally arrives to A)
CLOSED (C2) <-- ...
8. --> <SN=1><AN=1><CTL=RST> --> (connection reset)

The Figure above illustrate the current issue RATP can face during the
three-way handshake, and how behavior C2 can cause a connection to be
closed immediately after being established.

In the Figure above, side A try to establish a connection with side B,
which is in the LISTEN state. Commented line:
1. side A is in the CLOSED state and side B is in the LISTEN state;
2. side A open a new connection and send a SYN packet and is received by
side B which enters the SYN_RECEIVED state and send back a SYN-ACK;
3. side A receive the SYN-ACK packet from B;
4. side A respond with an ACK packet and move to the ESTABLISHED state.
Meanwhile;
5. side B hasn't received yet the ACK from side A and decide to
retransmit the SYN-ACK packet;
6. side B finally receive the ACK from side A and move to the
ESTABLISHED state;
7. side A finally receive the duplicated SYN-ACK packet from side B,
execute behavior C2: the received packet doesn't have the expected
SN and has the SYN flag set, thus respond by sending a legal reset.
8. side B receive the reset and close the connection.

One solution could be to tweak the initial RTO value of side B in order
to prevent sending a duplicated SYN-ACK packet, however the initial RTT
value is likely inaccurate during the handshake. This solution seems a
bit brittle.

The second solution would be to consider that a host has crashed only if
the packet received has the SYN flag set but not the ACK flag. The
rational is that the first step during handshake is to send a packet
only containing the SYN flag, however a packet containing both ACK and
SYN flags must have come after the initial handshake exchange and can
be considered as a duplicated and be dropped.

I propose the following changes:
[Page 29]
- If SYN was set we assume that the other end crashed and has
- attempted to open a new connection. We respond by sending a
- legal reset:
+ If the SYN flag was set but the ACK was not set then we assume
+ that the other end crashed and has attempted to open a new connection.
+ We respond by sending a legal reset:

[Page 30]
- If neither RST, FIN, nor SYN flags were set it is assumed that
- this packet is a duplicate of one already received. Send an
- ACK back:
+ If neither RST nor FIN flags were set, or if SYN and ACK flags
+ were set, it is assumed that this packet is a duplicate of one
+ already received. Send an ACK back:

RFC 959, "File Transfer Protocol", October 1985

Note: This RFC has been updated by RFC 2228, RFC 2640, RFC 2773, RFC 3659, RFC 5797, RFC 7151

Source of RFC: Legacy
Area Assignment: app

Errata ID: 7430
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Gordon Steemson
Date Reported: 2023-04-23

Section 5.2 says:

The direction of the transfer and the port used will be determined by the FTP service command.

It should say:

The direction of the transfer will be determined by the FTP service command.

Notes:

Per RFC 1123 (section "4.1.2.12 Connections"), the clause "and the port used" was a remnant of an earlier version of the standard, and ought to have been removed during the rewrite that produced RFC 959. Admittedly, RFC 1123 does only use the term "should" in saying to ignore the wording, as the behaviour described had been correct at one time -- but that time was meant to have ended 38 years ago. For the few brave souls who attempt to program FTP support in the modern day, this really ought to explicitly annotate the actual RFC.

RFC 1071, "Computing the Internet checksum", September 1988

Note: This RFC has been updated by RFC 1141

Source of RFC: Legacy
Area Assignment: int

Errata ID: 4918
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Cihangir Akturk
Date Reported: 2017-01-26

Section 4.1 says:

while( count > 1 )  {
        /*  This is the inner loop */
        sum += * (unsigned short) addr++;
        count -= 2;
}

It should say:

while( count > 1 )  {
        /*  This is the inner loop */
        sum += * (unsigned short *) addr;
        addr += 2;
        count -= 2;
}

Notes:

- In the original text, code incorrectly casts from pointer to integer.
- Increments addr pointer by 1. Because unsigned short is two bytes, it should have been incremented by 2 instead.

RFC 1157, "Simple Network Management Protocol (SNMP)", May 1990

Source of RFC: Legacy

Errata ID: 7878
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: neo
Date Reported: 2024-04-02

Section 4.1.3.1 says:

GetResponse (( ipRouteDest.9.1.2.3 =  "9.1.2.3" ),
                         ( ipRouteNextHop.9.1.2.3 = "99.0.0.3" ),
                         ( ipRouteMetric1.9.1.2.3 = 3 ))

It should say:

GetResponse (( ipRouteDest.9.1.2.3 =  "9.1.2.3" ),
                         ( ipRouteNextHop.9.1.2.3 = "99.0.0.3" ),
                         ( ipRouteMetric.9.1.2.3 = 3 ))

Notes:

ipRouteMetric1.9.1.2.3 should be ipRouteMetric. 9.1.2.3

RFC 1288, "The Finger User Information Protocol", December 1991

Source of RFC: Legacy

Errata ID: 6706
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Smith
Date Reported: 2021-10-11

Section 2.3 says:

   The Finger query specification is defined:

        {Q1}    ::= [{W}|{W}{S}{U}]{C}

        {Q2}    ::= [{W}{S}][{U}]{H}{C}

        {U}     ::= username

        {H}     ::= @hostname | @hostname{H}

        {W}     ::= /W

        {S}     ::= <SP> | <SP>{S}

        {C}     ::= <CRLF>

It should say:

   The Finger query specification is defined:

        {Q1}    ::= [{W}{S}][{U}]{C}

        {Q2}    ::= [{W}{S}][{U}]{H}{C}

        {U}     ::= username

        {H}     ::= @hostname | @hostname{H}

        {W}     ::= /W

        {S}     ::= <SP> | <SP>{S}

        {C}     ::= <CRLF>

Notes:

Query format one is intended to do a FINGER request, optionally supplying a username and optionally supplying a "/W ". These optional switches are orthogonal; you can specify one or the other or both.

The original BNF makes the /W switch mandatory when supplying a user name.

I've checked the source code for several Finger server implementations; they all accept /W as optional.

RFC 1321, "The MD5 Message-Digest Algorithm", April 1992

Note: This RFC has been updated by RFC 6151

Source of RFC: pem (sec)

Errata ID: 7814
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Nilstrieb
Date Reported: 2024-02-19

Appendix A.1 says:

/* POINTER defines a generic pointer type */
typedef unsigned char *POINTER;

/* UINT2 defines a two byte word */
typedef unsigned short int UINT2;

/* UINT4 defines a four byte word */
typedef unsigned long int UINT4;

It should say:

#include <stdint.h>

/* POINTER defines a generic pointer type */
typedef unsigned char *POINTER;

/* UINT2 defines a two byte word */
typedef uint16_t UINT2;

/* UINT4 defines a four byte word */
typedef uint32_t UINT4;

Notes:

On some modern systems like x86-64 Linux, unsigned long int is 8 bytes, which causes the original implementation to be incorrect.

RFC 1345, "Character Mnemonics and Character Sets", June 1992

Source of RFC: 822ext (app)

Errata ID: 6037
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip Børgesen
Date Reported: 2020-04-01

Section 5 says:

  &charset EBCDIC-AT-DE
  &rem source: IBM 3270 Char Set Ref Ch 10, GA27-2837-9, April 1987
  &code 0
  NU SH SX EX ET EQ AK BL BS HT LF VT FF CR SO SI
  DL D1 D2 D3 D4 NK SY EB CN EM SB EC FS GS RS US
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  SP ?? ?? ?? ?? ?? ?? ?? ?? ?? A: .  <  (  +  !
  &  ?? ?? ?? ?? ?? ?? ?? ?? ?? U: DO *  )  ;  '>
  -  /  ?? ?? ?? ?? ?? ?? ?? ?? o: ,  %  _  >  ?
  ?? ?? ?? ?? ?? ?? ?? ?? ?? '! :  Nb SE '  =  "
  ?? a  b  c  d  e  f  g  h  i  ?? ?? ?? ?? ?? ??
  ?? j  k  l  m  n  o  p  q  r  ?? ?? ?? ?? ?? ??
  ?? ss s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  a: A  B  C  D  E  F  G  H  I  ?? ?? ?? ?? ?? ??
  u: J  K  L  M  N  O  P  Q  R  ?? ?? ?? ?? ?? ??
  O: ?? S  T  U  V  W  X  Y  Z  ?? ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? ?? ?? ?? ?? DT

It should say:

  &charset EBCDIC-AT-DE
  &rem source: IBM 3270 Char Set Ref Ch 10, GA27-2837-9, April 1987
  &rem source: IBM Corporate Standard, C-S 3-3220-002
  &code 0
  NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
  DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
  __ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
  ?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB
  SP ?? ?? ?? ?? ?? ?? ?? ?? ?? A: .  <  (  +  !
  &  ?? ?? ?? ?? ?? ?? ?? ?? ?? U: DO *  )  ;  '>
  -  /  ?? ?? ?? ?? ?? ?? ?? ?? o: ,  %  _  >  ?
  ?? ?? ?? ?? ?? ?? ?? ?? ?? '! :  Nb SE '  =  "
  ?? a  b  c  d  e  f  g  h  i  ?? ?? ?? ?? ?? ??
  ?? j  k  l  m  n  o  p  q  r  ?? ?? ?? ?? ?? ??
  ?? ss s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  a: A  B  C  D  E  F  G  H  I  ?? ?? ?? ?? ?? ??
  u: J  K  L  M  N  O  P  Q  R  ?? ?? ?? ?? ?? ??
  O: ?? S  T  U  V  W  X  Y  Z  ?? ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? ?? ?? ?? ?? __
  &duplicate 1F __

Notes:

The EBCDIC character sets do not use the ASCII control codes.
Based on [1] the EBCDIC control codes located at hex 00-3F are

NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
__ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB

with __ marking control codes with no ISO 10646 mapping.
The control code at hex 1F can depending on context either mean "Interchange Unit Separator" or "Intermediate Transmission Block" but only the prior has an ISO 10646 mapping (mnemonic US). The "&duplicate 1F __" part marks the alternative character with no available mapping. Note that in EBCDIC the "Delete" character is located at hex 07 while hex FF is "Eight Ones", another character with no ISO 10646 equivalent.

For the sake of completeness I note that the originally listed source [2] only specifies a subset of the character codes in hex range 00-3F (see Figure 10-1), namely:

NU ?? ?? ?? ?? HT ?? ?? __ ?? ?? ?? FF CR ?? ??
?? D1 D2 D3 ?? NL ?? ?? ?? EM ?? ?? FS GS RS ??
?? ?? ?? ?? ?? ?? ?? ?? __ __ ?? ?? __ ?? ?? ??
?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? D4 ?? ?? SB

References:
[1]: IBM Corporate Standard, C-S 3-3220-002 (May 1990) -- archived IBM excerpt available at https://web.archive.org/web/20180911044845/https://www-01.ibm.com/software/globalization/cdra/appendix_g1.html
[2]: IBM 3270 Information Display System Character Set Reference, GA27-2837-9 (April 1987) -- copy available at http://bitsavers.trailing-edge.com/pdf/ibm/3270/GA27-2837-9_3270_Character_Set_Reference_Apr87.pdf

Errata ID: 6038
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip Børgesen
Date Reported: 2020-04-01

Section 5 says:

  &charset EBCDIC-AT-DE-A
  &rem source: IBM 3270 Char Set Ref Ch 10, GA27-2837-9, April 1987
  &code 0
  NU SH SX EX ET EQ AK BL BS HT LF VT FF CR SO SI
  DL D1 D2 D3 D4 NK SY EB CN EM SB EC FS GS RS US
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  SP ?? ?? ?? ?? ?? ?? ?? ?? ?? o: .  <  (  +  !!
  &  ?? ?? ?? ?? ?? ?? ?? ?? ?? u: U: *  )  ;  NO
  -  /  ?? ?? ?? ?? ?? ?? ?? ?? ss ,  %  _  >  ?
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? :  A: O: '  =  a:
  ?? a  b  c  d  e  f  g  h  i  ?? ?? ?? ?? ?? ??
  ?? j  k  l  m  n  o  p  q  r  ?? ?? ?? ?? ?? ??
  ?? ?? s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? A  B  C  D  E  F  G  H  I  ?? ?? ?? ?? ?? ??
  ?? J  K  L  M  N  O  P  Q  R  ?? ?? ?? ?? ?? ??
  ?? ?? S  T  U  V  W  X  Y  Z  ?? ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? ?? ?? ?? ?? DT

It should say:

  &charset EBCDIC-AT-DE-A
  &rem source: IBM 3270 Char Set Ref Ch 10, GA27-2837-9, April 1987
  &rem source: IBM Corporate Standard, C-S 3-3220-002
  &code 0
  NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
  DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
  __ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
  ?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB
  SP ?? ?? ?? ?? ?? ?? ?? ?? ?? o: .  <  (  +  !!
  &  ?? ?? ?? ?? ?? ?? ?? ?? ?? u: U: *  )  ;  NO
  -  /  ?? ?? ?? ?? ?? ?? ?? ?? ss ,  %  _  >  ?
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? :  A: O: '  =  a:
  ?? a  b  c  d  e  f  g  h  i  ?? ?? ?? ?? ?? ??
  ?? j  k  l  m  n  o  p  q  r  ?? ?? ?? ?? ?? ??
  ?? ?? s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? A  B  C  D  E  F  G  H  I  ?? ?? ?? ?? ?? ??
  ?? J  K  L  M  N  O  P  Q  R  ?? ?? ?? ?? ?? ??
  ?? ?? S  T  U  V  W  X  Y  Z  ?? ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? ?? ?? ?? ?? __
  &duplicate 1F __

Notes:

The EBCDIC character sets do not use the ASCII control codes.
Based on [1] the EBCDIC control codes located at hex 00-3F are

NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
__ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB

with __ marking control codes with no ISO 10646 mapping.
The control code at hex 1F can depending on context either mean "Interchange Unit Separator" or "Intermediate Transmission Block" but only the prior has an ISO 10646 mapping (mnemonic US). The "&duplicate 1F __" part marks the alternative character with no available mapping. Note that in EBCDIC the "Delete" character is located at hex 07 while hex FF is "Eight Ones", another character with no ISO 10646 equivalent.

For the sake of completeness I note that the originally listed source [2] only specifies a subset of the character codes in hex range 00-3F (see Figure 10-1), namely:

NU ?? ?? ?? ?? HT ?? ?? __ ?? ?? ?? FF CR ?? ??
?? D1 D2 D3 ?? NL ?? ?? ?? EM ?? ?? FS GS RS ??
?? ?? ?? ?? ?? ?? ?? ?? __ __ ?? ?? __ ?? ?? ??
?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? D4 ?? ?? SB

References:
[1]: IBM Corporate Standard, C-S 3-3220-002 (May 1990) -- archived IBM excerpt available at https://web.archive.org/web/20180911044845/https://www-01.ibm.com/software/globalization/cdra/appendix_g1.html
[2]: IBM 3270 Information Display System Character Set Reference, GA27-2837-9 (April 1987) -- copy available at http://bitsavers.trailing-edge.com/pdf/ibm/3270/GA27-2837-9_3270_Character_Set_Reference_Apr87.pdf

Errata ID: 6039
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip Børgesen
Date Reported: 2020-04-01

Section 5 says:

  &charset EBCDIC-CA-FR
  &rem source: IBM 3270 Char Set Ref Ch 10, GA27-2837-9, April 1987
  &code 0
  NU SH SX EX ET EQ AK BL BS HT LF VT FF CR SO SI
  DL D1 D2 D3 D4 NK SY EB CN EM SB EC FS GS RS US
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  SP ?? a> ?? ?? ?? ?? ?? c, ?? a! .  <  (  +  !
  &  ?? e> e: ?? ?? i> i: ?? ?? '' DO *  )  ;  '>
  -  /  A> ?? A! ?? ?? ?? C, ?? u! ,  %  _  >  ?
  ?? E' E> E: ?? I> I: ?? ?? '! :  Nb At '  =  "
  ?? a  b  c  d  e  f  g  h  i  ?? ?? ?? ?? ?? ??
  ?? j  k  l  m  n  o  p  q  r  ?? ?? ?? ?? ?? ??
  ?? ': s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  e' A  B  C  D  E  F  G  H  I  ?? o> ?? ?? ?? ??
  e! J  K  L  M  N  O  P  Q  R  ?? u> u: ?? ?? ??
  ', ?? S  T  U  V  W  X  Y  Z  ?? O> ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? U> U: U! ?? DT

It should say:

  &charset EBCDIC-CA-FR
  &rem source: IBM 3270 Char Set Ref Ch 10, GA27-2837-9, April 1987
  &rem source: IBM Corporate Standard, C-S 3-3220-002
  &code 0
  NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
  DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
  __ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
  ?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB
  SP ?? a> ?? ?? ?? ?? ?? c, ?? a! .  <  (  +  !
  &  ?? e> e: ?? ?? i> i: ?? ?? '' DO *  )  ;  '>
  -  /  A> ?? A! ?? ?? ?? C, ?? u! ,  %  _  >  ?
  ?? E' E> E: ?? I> I: ?? ?? '! :  Nb At '  =  "
  ?? a  b  c  d  e  f  g  h  i  ?? ?? ?? ?? ?? ??
  ?? j  k  l  m  n  o  p  q  r  ?? ?? ?? ?? ?? ??
  ?? ': s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  e' A  B  C  D  E  F  G  H  I  ?? o> ?? ?? ?? ??
  e! J  K  L  M  N  O  P  Q  R  ?? u> u: ?? ?? ??
  ', ?? S  T  U  V  W  X  Y  Z  ?? O> ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? U> U: U! ?? __
  &duplicate 1F __

Notes:

The EBCDIC character sets do not use the ASCII control codes.
Based on [1] the EBCDIC control codes located at hex 00-3F are

NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
__ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB

with __ marking control codes with no ISO 10646 mapping.
The control code at hex 1F can depending on context either mean "Interchange Unit Separator" or "Intermediate Transmission Block" but only the prior has an ISO 10646 mapping (mnemonic US). The "&duplicate 1F __" part marks the alternative character with no available mapping. Note that in EBCDIC the "Delete" character is located at hex 07 while hex FF is "Eight Ones", another character with no ISO 10646 equivalent.

For the sake of completeness I note that the originally listed source [2] only specifies a subset of the character codes in hex range 00-3F (see Figure 10-1), namely:

NU ?? ?? ?? ?? HT ?? ?? __ ?? ?? ?? FF CR ?? ??
?? D1 D2 D3 ?? NL ?? ?? ?? EM ?? ?? FS GS RS ??
?? ?? ?? ?? ?? ?? ?? ?? __ __ ?? ?? __ ?? ?? ??
?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? D4 ?? ?? SB

References:
[1]: IBM Corporate Standard, C-S 3-3220-002 (May 1990) -- archived IBM excerpt available at https://web.archive.org/web/20180911044845/https://www-01.ibm.com/software/globalization/cdra/appendix_g1.html
[2]: IBM 3270 Information Display System Character Set Reference, GA27-2837-9 (April 1987) -- copy available at http://bitsavers.trailing-edge.com/pdf/ibm/3270/GA27-2837-9_3270_Character_Set_Reference_Apr87.pdf

Errata ID: 6040
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip Børgesen
Date Reported: 2020-04-01

Section 5 says:

  &charset EBCDIC-DK-NO
  &rem source: IBM 3270 Char Set Ref Ch 10, GA27-2837-9, April 1987
  &code 0
  NU SH SX EX ET EQ AK BL BS HT LF VT FF CR SO SI
  DL D1 D2 D3 D4 NK SY EB CN EM SB EC FS GS RS US
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  SP ?? ?? ?? ?? ?? ?? ?? ?? ?? Nb .  <  (  +  !
  &  ?? ?? ?? ?? ?? ?? ?? ?? ?? Cu AA *  )  ;  '>
  -  /  ?? ?? ?? ?? ?? ?? ?? ?? o/ ,  %  _  >  ?
  ?? ?? ?? ?? ?? ?? ?? ?? ?? '! :  AE O/ '  =  "
  ?? a  b  c  d  e  f  g  h  i  ?? ?? ?? ?? ?? ??
  ?? j  k  l  m  n  o  p  q  r  ?? ?? ?? ?? ?? ??
  ?? u: s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ae A  B  C  D  E  F  G  H  I  ?? ?? ?? ?? ?? ??
  aa J  K  L  M  N  O  P  Q  R  ?? ?? ?? ?? ?? ??
  // ?? S  T  U  V  W  X  Y  Z  ?? ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? ?? ?? ?? ?? DT

It should say:

  &charset EBCDIC-DK-NO
  &rem source: IBM 3270 Char Set Ref Ch 10, GA27-2837-9, April 1987
  &rem source: IBM Corporate Standard, C-S 3-3220-002
  &code 0
  NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
  DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
  __ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
  ?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB
  SP ?? ?? ?? ?? ?? ?? ?? ?? ?? Nb .  <  (  +  !
  &  ?? ?? ?? ?? ?? ?? ?? ?? ?? Cu AA *  )  ;  '>
  -  /  ?? ?? ?? ?? ?? ?? ?? ?? o/ ,  %  _  >  ?
  ?? ?? ?? ?? ?? ?? ?? ?? ?? '! :  AE O/ '  =  "
  ?? a  b  c  d  e  f  g  h  i  ?? ?? ?? ?? ?? ??
  ?? j  k  l  m  n  o  p  q  r  ?? ?? ?? ?? ?? ??
  ?? u: s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ae A  B  C  D  E  F  G  H  I  ?? ?? ?? ?? ?? ??
  aa J  K  L  M  N  O  P  Q  R  ?? ?? ?? ?? ?? ??
  // ?? S  T  U  V  W  X  Y  Z  ?? ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? ?? ?? ?? ?? __
  &duplicate 1F __

Notes:

The EBCDIC character sets do not use the ASCII control codes.
Based on [1] the EBCDIC control codes located at hex 00-3F are

NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
__ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB

with __ marking control codes with no ISO 10646 mapping.
The control code at hex 1F can depending on context either mean "Interchange Unit Separator" or "Intermediate Transmission Block" but only the prior has an ISO 10646 mapping (mnemonic US). The "&duplicate 1F __" part marks the alternative character with no available mapping. Note that in EBCDIC the "Delete" character is located at hex 07 while hex FF is "Eight Ones", another character with no ISO 10646 equivalent.

For the sake of completeness I note that the originally listed source [2] only specifies a subset of the character codes in hex range 00-3F (see Figure 10-1), namely:

NU ?? ?? ?? ?? HT ?? ?? __ ?? ?? ?? FF CR ?? ??
?? D1 D2 D3 ?? NL ?? ?? ?? EM ?? ?? FS GS RS ??
?? ?? ?? ?? ?? ?? ?? ?? __ __ ?? ?? __ ?? ?? ??
?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? D4 ?? ?? SB

References:
[1]: IBM Corporate Standard, C-S 3-3220-002 (May 1990) -- archived IBM excerpt available at https://web.archive.org/web/20180911044845/https://www-01.ibm.com/software/globalization/cdra/appendix_g1.html
[2]: IBM 3270 Information Display System Character Set Reference, GA27-2837-9 (April 1987) -- copy available at http://bitsavers.trailing-edge.com/pdf/ibm/3270/GA27-2837-9_3270_Character_Set_Reference_Apr87.pdf

Errata ID: 6041
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip Børgesen
Date Reported: 2020-04-01

Section 5 says:

  &charset EBCDIC-DK-NO-A
  &rem source: IBM 3270 Char Set Ref Ch 10, GA27-2837-9, April 1987
  &code 0
  NU SH SX EX ET EQ AK BL BS HT LF VT FF CR SO SI
  DL D1 D2 D3 D4 NK SY EB CN EM SB EC FS GS RS US
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  SP ?? ?? ?? ?? ?? ?? ?? ?? ?? o/ .  <  (  +  !!
  &  ?? ?? ?? ?? ?? ?? ?? ?? ?? aa AA *  )  ;  NO
  -  /  ?? ?? ?? ?? ?? ?? ?? ?? BB ,  %  _  >  ?
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? :  AE O/ '  =  ae
  ?? a  b  c  d  e  f  g  h  i  ?? ?? ?? ?? ?? ??
  ?? j  k  l  m  n  o  p  q  r  ?? ?? ?? ?? ?? ??
  ?? ?? s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? A  B  C  D  E  F  G  H  I  ?? ?? ?? ?? ?? ??
  ?? J  K  L  M  N  O  P  Q  R  ?? ?? ?? ?? ?? ??
  ?? ?? S  T  U  V  W  X  Y  Z  ?? ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? ?? ?? ?? ?? DT

It should say:

  &charset EBCDIC-DK-NO-A
  &rem source: IBM 3270 Char Set Ref Ch 10, GA27-2837-9, April 1987
  &rem source: IBM Corporate Standard, C-S 3-3220-002
  &code 0
  NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
  DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
  __ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
  ?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB
  SP ?? ?? ?? ?? ?? ?? ?? ?? ?? o/ .  <  (  +  !!
  &  ?? ?? ?? ?? ?? ?? ?? ?? ?? aa AA *  )  ;  NO
  -  /  ?? ?? ?? ?? ?? ?? ?? ?? BB ,  %  _  >  ?
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? :  AE O/ '  =  ae
  ?? a  b  c  d  e  f  g  h  i  ?? ?? ?? ?? ?? ??
  ?? j  k  l  m  n  o  p  q  r  ?? ?? ?? ?? ?? ??
  ?? ?? s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? A  B  C  D  E  F  G  H  I  ?? ?? ?? ?? ?? ??
  ?? J  K  L  M  N  O  P  Q  R  ?? ?? ?? ?? ?? ??
  ?? ?? S  T  U  V  W  X  Y  Z  ?? ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? ?? ?? ?? ?? __
  &duplicate 1F __

Notes:

The EBCDIC character sets do not use the ASCII control codes.
Based on [1] the EBCDIC control codes located at hex 00-3F are

NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
__ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB

with __ marking control codes with no ISO 10646 mapping.
The control code at hex 1F can depending on context either mean "Interchange Unit Separator" or "Intermediate Transmission Block" but only the prior has an ISO 10646 mapping (mnemonic US). The "&duplicate 1F __" part marks the alternative character with no available mapping. Note that in EBCDIC the "Delete" character is located at hex 07 while hex FF is "Eight Ones", another character with no ISO 10646 equivalent.

For the sake of completeness I note that the originally listed source [2] only specifies a subset of the character codes in hex range 00-3F (see Figure 10-1), namely:

NU ?? ?? ?? ?? HT ?? ?? __ ?? ?? ?? FF CR ?? ??
?? D1 D2 D3 ?? NL ?? ?? ?? EM ?? ?? FS GS RS ??
?? ?? ?? ?? ?? ?? ?? ?? __ __ ?? ?? __ ?? ?? ??
?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? D4 ?? ?? SB

References:
[1]: IBM Corporate Standard, C-S 3-3220-002 (May 1990) -- archived IBM excerpt available at https://web.archive.org/web/20180911044845/https://www-01.ibm.com/software/globalization/cdra/appendix_g1.html
[2]: IBM 3270 Information Display System Character Set Reference, GA27-2837-9 (April 1987) -- copy available at http://bitsavers.trailing-edge.com/pdf/ibm/3270/GA27-2837-9_3270_Character_Set_Reference_Apr87.pdf

Errata ID: 6042
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip Børgesen
Date Reported: 2020-04-01

Section 5 says:

  &charset EBCDIC-FI-SE
  &rem source: IBM 3270 Char Set Ref Ch 10, GA27-2837-9, April 1987
  &code 0
  NU SH SX EX ET EQ AK BL BS HT LF VT FF CR SO SI
  DL D1 D2 D3 D4 NK SY EB CN EM SB EC FS GS RS US
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  SP ?? ?? ?? ?? ?? ?? ?? ?? ?? SE .  <  (  +  !
  &  ?? ?? ?? ?? ?? ?? ?? ?? ?? Cu AA *  )  ;  '>
  -  /  ?? ?? ?? ?? ?? ?? ?? ?? o: ,  %  _  >  ?
  ?? ?? ?? ?? ?? ?? ?? ?? ?? e' :  A: O: '  =  "
  ?? a  b  c  d  e  f  g  h  i  ?? ?? ?? ?? ?? ??
  ?? j  k  l  m  n  o  p  q  r  ?? ?? ?? ?? ?? ??
  ?? u: s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  a: A  B  C  D  E  F  G  H  I  ?? ?? ?? ?? ?? ??
  aa J  K  L  M  N  O  P  Q  R  ?? ?? ?? ?? ?? ??
  E' ?? S  T  U  V  W  X  Y  Z  ?? ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? ?? ?? ?? ?? DT

It should say:

  &charset EBCDIC-FI-SE
  &rem source: IBM 3270 Char Set Ref Ch 10, GA27-2837-9, April 1987
  &rem source: IBM Corporate Standard, C-S 3-3220-002
  &code 0
  NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
  DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
  __ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
  ?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB
  SP ?? ?? ?? ?? ?? ?? ?? ?? ?? SE .  <  (  +  !
  &  ?? ?? ?? ?? ?? ?? ?? ?? ?? Cu AA *  )  ;  '>
  -  /  ?? ?? ?? ?? ?? ?? ?? ?? o: ,  %  _  >  ?
  ?? ?? ?? ?? ?? ?? ?? ?? ?? e' :  A: O: '  =  "
  ?? a  b  c  d  e  f  g  h  i  ?? ?? ?? ?? ?? ??
  ?? j  k  l  m  n  o  p  q  r  ?? ?? ?? ?? ?? ??
  ?? u: s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  a: A  B  C  D  E  F  G  H  I  ?? ?? ?? ?? ?? ??
  aa J  K  L  M  N  O  P  Q  R  ?? ?? ?? ?? ?? ??
  E' ?? S  T  U  V  W  X  Y  Z  ?? ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? ?? ?? ?? ?? __
  &duplicate 1F __

Notes:

The EBCDIC character sets do not use the ASCII control codes.
Based on [1] the EBCDIC control codes located at hex 00-3F are

NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
__ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB

with __ marking control codes with no ISO 10646 mapping.
The control code at hex 1F can depending on context either mean "Interchange Unit Separator" or "Intermediate Transmission Block" but only the prior has an ISO 10646 mapping (mnemonic US). The "&duplicate 1F __" part marks the alternative character with no available mapping. Note that in EBCDIC the "Delete" character is located at hex 07 while hex FF is "Eight Ones", another character with no ISO 10646 equivalent.

For the sake of completeness I note that the originally listed source [2] only specifies a subset of the character codes in hex range 00-3F (see Figure 10-1), namely:

NU ?? ?? ?? ?? HT ?? ?? __ ?? ?? ?? FF CR ?? ??
?? D1 D2 D3 ?? NL ?? ?? ?? EM ?? ?? FS GS RS ??
?? ?? ?? ?? ?? ?? ?? ?? __ __ ?? ?? __ ?? ?? ??
?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? D4 ?? ?? SB

References:
[1]: IBM Corporate Standard, C-S 3-3220-002 (May 1990) -- archived IBM excerpt available at https://web.archive.org/web/20180911044845/https://www-01.ibm.com/software/globalization/cdra/appendix_g1.html
[2]: IBM 3270 Information Display System Character Set Reference, GA27-2837-9 (April 1987) -- copy available at http://bitsavers.trailing-edge.com/pdf/ibm/3270/GA27-2837-9_3270_Character_Set_Reference_Apr87.pdf

Errata ID: 6043
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip Børgesen
Date Reported: 2020-04-01

Section 5 says:

  &charset EBCDIC-FI-SE-A
  &rem source: IBM 3270 Char Set Ref Ch 10, GA27-2837-9, April 1987
  &code 0
  NU SH SX EX ET EQ AK BL BS HT LF VT FF CR SO SI
  DL D1 D2 D3 D4 NK SY EB CN EM SB EC FS GS RS US
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  SP ?? ?? ?? ?? ?? ?? ?? ?? ?? o: .  <  (  +  !!
  &  ?? ?? ?? ?? ?? ?? ?? ?? ?? aa AA *  )  ;  NO
  -  /  ?? ?? ?? ?? ?? ?? ?? ?? BB ,  %  _  >  ?
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? :  A: O: '  =  a:
  ?? a  b  c  d  e  f  g  h  i  ?? ?? ?? ?? ?? ??
  ?? j  k  l  m  n  o  p  q  r  ?? ?? ?? ?? ?? ??
  ?? ?? s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? A  B  C  D  E  F  G  H  I  ?? ?? ?? ?? ?? ??
  ?? J  K  L  M  N  O  P  Q  R  ?? ?? ?? ?? ?? ??
  ?? ?? S  T  U  V  W  X  Y  Z  ?? ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? ?? ?? ?? ?? DT

It should say:

  &charset EBCDIC-FI-SE-A
  &rem source: IBM 3270 Char Set Ref Ch 10, GA27-2837-9, April 1987
  &rem source: IBM Corporate Standard, C-S 3-3220-002
  &code 0
  NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
  DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
  __ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
  ?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB
  SP ?? ?? ?? ?? ?? ?? ?? ?? ?? o: .  <  (  +  !!
  &  ?? ?? ?? ?? ?? ?? ?? ?? ?? aa AA *  )  ;  NO
  -  /  ?? ?? ?? ?? ?? ?? ?? ?? BB ,  %  _  >  ?
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? :  A: O: '  =  a:
  ?? a  b  c  d  e  f  g  h  i  ?? ?? ?? ?? ?? ??
  ?? j  k  l  m  n  o  p  q  r  ?? ?? ?? ?? ?? ??
  ?? ?? s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? A  B  C  D  E  F  G  H  I  ?? ?? ?? ?? ?? ??
  ?? J  K  L  M  N  O  P  Q  R  ?? ?? ?? ?? ?? ??
  ?? ?? S  T  U  V  W  X  Y  Z  ?? ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? ?? ?? ?? ?? __
  &duplicate 1F __

Notes:

The EBCDIC character sets do not use the ASCII control codes.
Based on [1] the EBCDIC control codes located at hex 00-3F are

NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
__ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB

with __ marking control codes with no ISO 10646 mapping.
The control code at hex 1F can depending on context either mean "Interchange Unit Separator" or "Intermediate Transmission Block" but only the prior has an ISO 10646 mapping (mnemonic US). The "&duplicate 1F __" part marks the alternative character with no available mapping. Note that in EBCDIC the "Delete" character is located at hex 07 while hex FF is "Eight Ones", another character with no ISO 10646 equivalent.

For the sake of completeness I note that the originally listed source [2] only specifies a subset of the character codes in hex range 00-3F (see Figure 10-1), namely:

NU ?? ?? ?? ?? HT ?? ?? __ ?? ?? ?? FF CR ?? ??
?? D1 D2 D3 ?? NL ?? ?? ?? EM ?? ?? FS GS RS ??
?? ?? ?? ?? ?? ?? ?? ?? __ __ ?? ?? __ ?? ?? ??
?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? D4 ?? ?? SB

References:
[1]: IBM Corporate Standard, C-S 3-3220-002 (May 1990) -- archived IBM excerpt available at https://web.archive.org/web/20180911044845/https://www-01.ibm.com/software/globalization/cdra/appendix_g1.html
[2]: IBM 3270 Information Display System Character Set Reference, GA27-2837-9 (April 1987) -- copy available at http://bitsavers.trailing-edge.com/pdf/ibm/3270/GA27-2837-9_3270_Character_Set_Reference_Apr87.pdf

Errata ID: 6044
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip Børgesen
Date Reported: 2020-04-01

Section 5 says:

  &charset EBCDIC-FR
  &rem source: IBM 3270 Char Set Ref Ch 10, GA27-2837-9, April 1987
  &code 0
  NU SH SX EX ET EQ AK BL BS HT LF VT FF CR SO SI
  DL D1 D2 D3 D4 NK SY EB CN EM SB EC FS GS RS US
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  SP ?? ?? ?? ?? ?? ?? ?? ?? ?? DG .  <  (  +  !
  &  ?? ?? ?? ?? ?? ?? ?? ?? ?? SE DO *  )  ;  '>
  -  /  ?? ?? ?? ?? ?? ?? ?? ?? u! ,  %  _  >  ?
  ?? ?? ?? ?? ?? ?? ?? ?? ?? '! :  Pd a! '  =  "
  ?? a  b  c  d  e  f  g  h  i  ?? ?? ?? ?? ?? ??
  ?? j  k  l  m  n  o  p  q  r  ?? ?? ?? ?? ?? ??
  ?? ': s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  e' A  B  C  D  E  F  G  H  I  ?? ?? ?? ?? ?? ??
  e! J  K  L  M  N  O  P  Q  R  ?? ?? ?? ?? ?? ??
  c, ?? S  T  U  V  W  X  Y  Z  ?? ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? ?? ?? ?? ?? DT

It should say:

  &charset EBCDIC-FR
  &rem source: IBM 3270 Char Set Ref Ch 10, GA27-2837-9, April 1987
  &rem source: IBM Corporate Standard, C-S 3-3220-002
  &code 0
  NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
  DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
  __ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
  ?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB
  SP ?? ?? ?? ?? ?? ?? ?? ?? ?? DG .  <  (  +  !
  &  ?? ?? ?? ?? ?? ?? ?? ?? ?? SE DO *  )  ;  '>
  -  /  ?? ?? ?? ?? ?? ?? ?? ?? u! ,  %  _  >  ?
  ?? ?? ?? ?? ?? ?? ?? ?? ?? '! :  Pd a! '  =  "
  ?? a  b  c  d  e  f  g  h  i  ?? ?? ?? ?? ?? ??
  ?? j  k  l  m  n  o  p  q  r  ?? ?? ?? ?? ?? ??
  ?? ': s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  e' A  B  C  D  E  F  G  H  I  ?? ?? ?? ?? ?? ??
  e! J  K  L  M  N  O  P  Q  R  ?? ?? ?? ?? ?? ??
  c, ?? S  T  U  V  W  X  Y  Z  ?? ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? ?? ?? ?? ?? __
  &duplicate 1F __

Notes:

The EBCDIC character sets do not use the ASCII control codes.
Based on [1] the EBCDIC control codes located at hex 00-3F are

NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
__ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB

with __ marking control codes with no ISO 10646 mapping.
The control code at hex 1F can depending on context either mean "Interchange Unit Separator" or "Intermediate Transmission Block" but only the prior has an ISO 10646 mapping (mnemonic US). The "&duplicate 1F __" part marks the alternative character with no available mapping. Note that in EBCDIC the "Delete" character is located at hex 07 while hex FF is "Eight Ones", another character with no ISO 10646 equivalent.

For the sake of completeness I note that the originally listed source [2] only specifies a subset of the character codes in hex range 00-3F (see Figure 10-1), namely:

NU ?? ?? ?? ?? HT ?? ?? __ ?? ?? ?? FF CR ?? ??
?? D1 D2 D3 ?? NL ?? ?? ?? EM ?? ?? FS GS RS ??
?? ?? ?? ?? ?? ?? ?? ?? __ __ ?? ?? __ ?? ?? ??
?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? D4 ?? ?? SB

References:
[1]: IBM Corporate Standard, C-S 3-3220-002 (May 1990) -- archived IBM excerpt available at https://web.archive.org/web/20180911044845/https://www-01.ibm.com/software/globalization/cdra/appendix_g1.html
[2]: IBM 3270 Information Display System Character Set Reference, GA27-2837-9 (April 1987) -- copy available at http://bitsavers.trailing-edge.com/pdf/ibm/3270/GA27-2837-9_3270_Character_Set_Reference_Apr87.pdf

Errata ID: 6045
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip Børgesen
Date Reported: 2020-04-01

Section 5 says:

  &charset EBCDIC-IT
  &rem source: IBM 3270 Char Set Ref Ch 10, GA27-2837-9, April 1987
  &code 0
  NU SH SX EX ET EQ AK BL BS HT LF VT FF CR SO SI
  DL D1 D2 D3 D4 NK SY EB CN EM SB EC FS GS RS US
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  SP ?? ?? ?? ?? ?? ?? ?? ?? ?? DG .  <  (  +  !
  &  ?? ?? ?? ?? ?? ?? ?? ?? ?? e' DO *  )  ;  '>
  -  /  ?? ?? ?? ?? ?? ?? ?? ?? o! ,  %  _  >  ?
  ?? ?? ?? ?? ?? ?? ?? ?? ?? u! :  Pd SE '  =  "
  ?? a  b  c  d  e  f  g  h  i  ?? ?? ?? ?? ?? ??
  ?? j  k  l  m  n  o  p  q  r  ?? ?? ?? ?? ?? ??
  ?? i! s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  a! A  B  C  D  E  F  G  H  I  ?? ?? ?? ?? ?? ??
  e! J  K  L  M  N  O  P  Q  R  ?? ?? ?? ?? ?? ??
  c, ?? S  T  U  V  W  X  Y  Z  ?? ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? ?? ?? ?? ?? DT

It should say:

  &charset EBCDIC-IT
  &rem source: IBM 3270 Char Set Ref Ch 10, GA27-2837-9, April 1987
  &rem source: IBM Corporate Standard, C-S 3-3220-002
  &code 0
  NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
  DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
  __ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
  ?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB
  SP ?? ?? ?? ?? ?? ?? ?? ?? ?? DG .  <  (  +  !
  &  ?? ?? ?? ?? ?? ?? ?? ?? ?? e' DO *  )  ;  '>
  -  /  ?? ?? ?? ?? ?? ?? ?? ?? o! ,  %  _  >  ?
  ?? ?? ?? ?? ?? ?? ?? ?? ?? u! :  Pd SE '  =  "
  ?? a  b  c  d  e  f  g  h  i  ?? ?? ?? ?? ?? ??
  ?? j  k  l  m  n  o  p  q  r  ?? ?? ?? ?? ?? ??
  ?? i! s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  a! A  B  C  D  E  F  G  H  I  ?? ?? ?? ?? ?? ??
  e! J  K  L  M  N  O  P  Q  R  ?? ?? ?? ?? ?? ??
  c, ?? S  T  U  V  W  X  Y  Z  ?? ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? ?? ?? ?? ?? __
  &duplicate 1F __

Notes:

The EBCDIC character sets do not use the ASCII control codes.
Based on [1] the EBCDIC control codes located at hex 00-3F are

NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
__ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB

with __ marking control codes with no ISO 10646 mapping.
The control code at hex 1F can depending on context either mean "Interchange Unit Separator" or "Intermediate Transmission Block" but only the prior has an ISO 10646 mapping (mnemonic US). The "&duplicate 1F __" part marks the alternative character with no available mapping. Note that in EBCDIC the "Delete" character is located at hex 07 while hex FF is "Eight Ones", another character with no ISO 10646 equivalent.

For the sake of completeness I note that the originally listed source [2] only specifies a subset of the character codes in hex range 00-3F (see Figure 10-1), namely:

NU ?? ?? ?? ?? HT ?? ?? __ ?? ?? ?? FF CR ?? ??
?? D1 D2 D3 ?? NL ?? ?? ?? EM ?? ?? FS GS RS ??
?? ?? ?? ?? ?? ?? ?? ?? __ __ ?? ?? __ ?? ?? ??
?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? D4 ?? ?? SB

References:
[1]: IBM Corporate Standard, C-S 3-3220-002 (May 1990) -- archived IBM excerpt available at https://web.archive.org/web/20180911044845/https://www-01.ibm.com/software/globalization/cdra/appendix_g1.html
[2]: IBM 3270 Information Display System Character Set Reference, GA27-2837-9 (April 1987) -- copy available at http://bitsavers.trailing-edge.com/pdf/ibm/3270/GA27-2837-9_3270_Character_Set_Reference_Apr87.pdf

Errata ID: 6046
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip Børgesen
Date Reported: 2020-04-01

Section 5 says:

  &charset EBCDIC-PT
  &rem source: IBM 3270 Char Set Ref Ch 10, GA27-2837-9, April 1987
  &code 0
  NU SH SX EX ET EQ AK BL BS HT LF VT FF CR SO SI
  DL D1 D2 D3 D4 NK SY EB CN EM SB EC FS GS RS US
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  SP ?? ?? ?? ?? ?? ?? ?? ?? ?? <( .  <  (  +  !
  &  ?? ?? ?? ?? ?? ?? ?? ?? ?? )> DO *  )  ;  '>
  -  /  ?? ?? ?? ?? ?? ?? ?? ?? o? ,  %  _  >  ?
  ?? ?? ?? ?? ?? ?? ?? ?? ?? '! :  A? O? '  =  "
  ?? a  b  c  d  e  f  g  h  i  ?? ?? ?? ?? ?? ??
  ?? j  k  l  m  n  o  p  q  r  ?? ?? ?? ?? ?? ??
  ?? c, s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  a? A  B  C  D  E  F  G  H  I  ?? ?? ?? ?? ?? ??
  '' J  K  L  M  N  O  P  Q  R  ?? ?? ?? ?? ?? ??
  C, ?? S  T  U  V  W  X  Y  Z  ?? ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? ?? ?? ?? ?? DT

It should say:

  &charset EBCDIC-PT
  &rem source: IBM 3270 Char Set Ref Ch 10, GA27-2837-9, April 1987
  &rem source: IBM Corporate Standard, C-S 3-3220-002
  &code 0
  NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
  DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
  __ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
  ?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB
  SP ?? ?? ?? ?? ?? ?? ?? ?? ?? <( .  <  (  +  !
  &  ?? ?? ?? ?? ?? ?? ?? ?? ?? )> DO *  )  ;  '>
  -  /  ?? ?? ?? ?? ?? ?? ?? ?? o? ,  %  _  >  ?
  ?? ?? ?? ?? ?? ?? ?? ?? ?? '! :  A? O? '  =  "
  ?? a  b  c  d  e  f  g  h  i  ?? ?? ?? ?? ?? ??
  ?? j  k  l  m  n  o  p  q  r  ?? ?? ?? ?? ?? ??
  ?? c, s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  a? A  B  C  D  E  F  G  H  I  ?? ?? ?? ?? ?? ??
  '' J  K  L  M  N  O  P  Q  R  ?? ?? ?? ?? ?? ??
  C, ?? S  T  U  V  W  X  Y  Z  ?? ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? ?? ?? ?? ?? __
  &duplicate 1F __

Notes:

The EBCDIC character sets do not use the ASCII control codes.
Based on [1] the EBCDIC control codes located at hex 00-3F are

NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
__ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB

with __ marking control codes with no ISO 10646 mapping.
The control code at hex 1F can depending on context either mean "Interchange Unit Separator" or "Intermediate Transmission Block" but only the prior has an ISO 10646 mapping (mnemonic US). The "&duplicate 1F __" part marks the alternative character with no available mapping. Note that in EBCDIC the "Delete" character is located at hex 07 while hex FF is "Eight Ones", another character with no ISO 10646 equivalent.

For the sake of completeness I note that the originally listed source [2] only specifies a subset of the character codes in hex range 00-3F (see Figure 10-1), namely:

NU ?? ?? ?? ?? HT ?? ?? __ ?? ?? ?? FF CR ?? ??
?? D1 D2 D3 ?? NL ?? ?? ?? EM ?? ?? FS GS RS ??
?? ?? ?? ?? ?? ?? ?? ?? __ __ ?? ?? __ ?? ?? ??
?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? D4 ?? ?? SB

References:
[1]: IBM Corporate Standard, C-S 3-3220-002 (May 1990) -- archived IBM excerpt available at https://web.archive.org/web/20180911044845/https://www-01.ibm.com/software/globalization/cdra/appendix_g1.html
[2]: IBM 3270 Information Display System Character Set Reference, GA27-2837-9 (April 1987) -- copy available at http://bitsavers.trailing-edge.com/pdf/ibm/3270/GA27-2837-9_3270_Character_Set_Reference_Apr87.pdf

Errata ID: 6047
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip Børgesen
Date Reported: 2020-04-01

Section 5 says:

  &charset EBCDIC-ES
  &rem source: IBM 3270 Char Set Ref Ch 10, GA27-2837-9, April 1987
  &code 0
  NU SH SX EX ET EQ AK BL BS HT LF VT FF CR SO SI
  DL D1 D2 D3 D4 NK SY EB CN EM SB EC FS GS RS US
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  SP ?? ?? ?? ?? ?? ?? ?? ?? ?? Ct .  <  (  +  !!
  &  ?? ?? ?? ?? ?? ?? ?? ?? ?? !  Pt *  )  ;  NO
  -  /  ?? ?? ?? ?? ?? ?? ?? ?? n? ,  %  _  >  ?
  ?? ?? ?? ?? ?? ?? ?? ?? ?? '! :  N? At '  =  "
  ?? a  b  c  d  e  f  g  h  i  ?? ?? ?? ?? ?? ??
  ?? j  k  l  m  n  o  p  q  r  ?? ?? ?? ?? ?? ??
  ?? ': s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  (! A  B  C  D  E  F  G  H  I  ?? ?? ?? ?? ?? ??
  !) J  K  L  M  N  O  P  Q  R  ?? ?? ?? ?? ?? ??
  // ?? S  T  U  V  W  X  Y  Z  ?? ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? ?? ?? ?? ?? DT

It should say:

  &charset EBCDIC-ES
  &rem source: IBM 3270 Char Set Ref Ch 10, GA27-2837-9, April 1987
  &rem source: IBM Corporate Standard, C-S 3-3220-002
  &code 0
  NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
  DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
  __ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
  ?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB
  SP ?? ?? ?? ?? ?? ?? ?? ?? ?? Ct .  <  (  +  !!
  &  ?? ?? ?? ?? ?? ?? ?? ?? ?? !  Pt *  )  ;  NO
  -  /  ?? ?? ?? ?? ?? ?? ?? ?? n? ,  %  _  >  ?
  ?? ?? ?? ?? ?? ?? ?? ?? ?? '! :  N? At '  =  "
  ?? a  b  c  d  e  f  g  h  i  ?? ?? ?? ?? ?? ??
  ?? j  k  l  m  n  o  p  q  r  ?? ?? ?? ?? ?? ??
  ?? ': s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  (! A  B  C  D  E  F  G  H  I  ?? ?? ?? ?? ?? ??
  !) J  K  L  M  N  O  P  Q  R  ?? ?? ?? ?? ?? ??
  // ?? S  T  U  V  W  X  Y  Z  ?? ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? ?? ?? ?? ?? __
  &duplicate 1F __

Notes:

The EBCDIC character sets do not use the ASCII control codes.
Based on [1] the EBCDIC control codes located at hex 00-3F are

NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
__ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB

with __ marking control codes with no ISO 10646 mapping.
The control code at hex 1F can depending on context either mean "Interchange Unit Separator" or "Intermediate Transmission Block" but only the prior has an ISO 10646 mapping (mnemonic US). The "&duplicate 1F __" part marks the alternative character with no available mapping. Note that in EBCDIC the "Delete" character is located at hex 07 while hex FF is "Eight Ones", another character with no ISO 10646 equivalent.

For the sake of completeness I note that the originally listed source [2] only specifies a subset of the character codes in hex range 00-3F (see Figure 10-1), namely:

NU ?? ?? ?? ?? HT ?? ?? __ ?? ?? ?? FF CR ?? ??
?? D1 D2 D3 ?? NL ?? ?? ?? EM ?? ?? FS GS RS ??
?? ?? ?? ?? ?? ?? ?? ?? __ __ ?? ?? __ ?? ?? ??
?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? D4 ?? ?? SB

References:
[1]: IBM Corporate Standard, C-S 3-3220-002 (May 1990) -- archived IBM excerpt available at https://web.archive.org/web/20180911044845/https://www-01.ibm.com/software/globalization/cdra/appendix_g1.html
[2]: IBM 3270 Information Display System Character Set Reference, GA27-2837-9 (April 1987) -- copy available at http://bitsavers.trailing-edge.com/pdf/ibm/3270/GA27-2837-9_3270_Character_Set_Reference_Apr87.pdf

Errata ID: 6048
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip Børgesen
Date Reported: 2020-04-01

Section 5 says:

  &charset EBCDIC-ES-A
  &rem source: IBM 3270 Char Set Ref Ch 10, GA27-2837-9, April 1987
  &code 0
  NU SH SX EX ET EQ AK BL BS HT LF VT FF CR SO SI
  DL D1 D2 D3 D4 NK SY EB CN EM SB EC FS GS RS US
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  SP ?? ?? ?? ?? ?? ?? ?? ?? ?? Ct .  <  (  +  !!
  &  ?? ?? ?? ?? ?? ?? ?? ?? ?? !  Pt *  )  ;  NO
  -  /  ?? ?? ?? ?? ?? ?? ?? ?? BB ,  %  _  >  ?
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? :  N? At '  =  n?
  ?? a  b  c  d  e  f  g  h  i  ?? ?? ?? ?? ?? ??
  ?? j  k  l  m  n  o  p  q  r  ?? ?? ?? ?? ?? ??
  ?? ?? s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? A  B  C  D  E  F  G  H  I  ?? ?? ?? ?? ?? ??
  ?? J  K  L  M  N  O  P  Q  R  ?? ?? ?? ?? ?? ??
  ?? ?? S  T  U  V  W  X  Y  Z  ?? ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? ?? ?? ?? ?? DT

It should say:

  &charset EBCDIC-ES-A
  &rem source: IBM 3270 Char Set Ref Ch 10, GA27-2837-9, April 1987
  &rem source: IBM Corporate Standard, C-S 3-3220-002
  &code 0
  NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
  DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
  __ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
  ?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB
  SP ?? ?? ?? ?? ?? ?? ?? ?? ?? Ct .  <  (  +  !!
  &  ?? ?? ?? ?? ?? ?? ?? ?? ?? !  Pt *  )  ;  NO
  -  /  ?? ?? ?? ?? ?? ?? ?? ?? BB ,  %  _  >  ?
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? :  N? At '  =  n?
  ?? a  b  c  d  e  f  g  h  i  ?? ?? ?? ?? ?? ??
  ?? j  k  l  m  n  o  p  q  r  ?? ?? ?? ?? ?? ??
  ?? ?? s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? A  B  C  D  E  F  G  H  I  ?? ?? ?? ?? ?? ??
  ?? J  K  L  M  N  O  P  Q  R  ?? ?? ?? ?? ?? ??
  ?? ?? S  T  U  V  W  X  Y  Z  ?? ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? ?? ?? ?? ?? __
  &duplicate 1F __

Notes:

The EBCDIC character sets do not use the ASCII control codes.
Based on [1] the EBCDIC control codes located at hex 00-3F are

NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
__ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB

with __ marking control codes with no ISO 10646 mapping.
The control code at hex 1F can depending on context either mean "Interchange Unit Separator" or "Intermediate Transmission Block" but only the prior has an ISO 10646 mapping (mnemonic US). The "&duplicate 1F __" part marks the alternative character with no available mapping. Note that in EBCDIC the "Delete" character is located at hex 07 while hex FF is "Eight Ones", another character with no ISO 10646 equivalent.

For the sake of completeness I note that the originally listed source [2] only specifies a subset of the character codes in hex range 00-3F (see Figure 10-1), namely:

NU ?? ?? ?? ?? HT ?? ?? __ ?? ?? ?? FF CR ?? ??
?? D1 D2 D3 ?? NL ?? ?? ?? EM ?? ?? FS GS RS ??
?? ?? ?? ?? ?? ?? ?? ?? __ __ ?? ?? __ ?? ?? ??
?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? D4 ?? ?? SB

References:
[1]: IBM Corporate Standard, C-S 3-3220-002 (May 1990) -- archived IBM excerpt available at https://web.archive.org/web/20180911044845/https://www-01.ibm.com/software/globalization/cdra/appendix_g1.html
[2]: IBM 3270 Information Display System Character Set Reference, GA27-2837-9 (April 1987) -- copy available at http://bitsavers.trailing-edge.com/pdf/ibm/3270/GA27-2837-9_3270_Character_Set_Reference_Apr87.pdf

Errata ID: 6049
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip Børgesen
Date Reported: 2020-04-01

Section 5 says:

  &charset EBCDIC-ES-S
  &rem source: IBM 3270 Char Set Ref Ch 10, GA27-2837-9, April 1987
  &code 0
  NU SH SX EX ET EQ AK BL BS HT LF VT FF CR SO SI
  DL D1 D2 D3 D4 NK SY EB CN EM SB EC FS GS RS US
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  SP ?? ?? ?? ?? ?? ?? ?? ?? ?? Ct .  <  (  +  !!
  &  ?? ?? ?? ?? ?? ?? ?? ?? ?? !  DO *  )  ;  NO
  -  /  ?? ?? ?? ?? ?? ?? ?? ?? n? ,  %  _  >  ?
  ?? ?? ?? ?? ?? ?? ?? ?? ?? '! :  N? At '  =  "
  ?? a  b  c  d  e  f  g  h  i  ?? ?? ?? ?? ?? ??
  ?? j  k  l  m  n  o  p  q  r  ?? ?? ?? ?? ?? ??
  ?? ': s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  (! A  B  C  D  E  F  G  H  I  ?? ?? ?? ?? ?? ??
  !) J  K  L  M  N  O  P  Q  R  ?? ?? ?? ?? ?? ??
  // ?? S  T  U  V  W  X  Y  Z  ?? ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? ?? ?? ?? ?? DT

It should say:

  &charset EBCDIC-ES-S
  &rem source: IBM 3270 Char Set Ref Ch 10, GA27-2837-9, April 1987
  &rem source: IBM Corporate Standard, C-S 3-3220-002
  &code 0
  NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
  DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
  __ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
  ?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB
  SP ?? ?? ?? ?? ?? ?? ?? ?? ?? Ct .  <  (  +  !!
  &  ?? ?? ?? ?? ?? ?? ?? ?? ?? !  DO *  )  ;  NO
  -  /  ?? ?? ?? ?? ?? ?? ?? ?? n? ,  %  _  >  ?
  ?? ?? ?? ?? ?? ?? ?? ?? ?? '! :  N? At '  =  "
  ?? a  b  c  d  e  f  g  h  i  ?? ?? ?? ?? ?? ??
  ?? j  k  l  m  n  o  p  q  r  ?? ?? ?? ?? ?? ??
  ?? ': s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  (! A  B  C  D  E  F  G  H  I  ?? ?? ?? ?? ?? ??
  !) J  K  L  M  N  O  P  Q  R  ?? ?? ?? ?? ?? ??
  // ?? S  T  U  V  W  X  Y  Z  ?? ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? ?? ?? ?? ?? __
  &duplicate 1F __

Notes:

The EBCDIC character sets do not use the ASCII control codes.
Based on [1] the EBCDIC control codes located at hex 00-3F are

NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
__ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB

with __ marking control codes with no ISO 10646 mapping.
The control code at hex 1F can depending on context either mean "Interchange Unit Separator" or "Intermediate Transmission Block" but only the prior has an ISO 10646 mapping (mnemonic US). The "&duplicate 1F __" part marks the alternative character with no available mapping. Note that in EBCDIC the "Delete" character is located at hex 07 while hex FF is "Eight Ones", another character with no ISO 10646 equivalent.

For the sake of completeness I note that the originally listed source [2] only specifies a subset of the character codes in hex range 00-3F (see Figure 10-1), namely:

NU ?? ?? ?? ?? HT ?? ?? __ ?? ?? ?? FF CR ?? ??
?? D1 D2 D3 ?? NL ?? ?? ?? EM ?? ?? FS GS RS ??
?? ?? ?? ?? ?? ?? ?? ?? __ __ ?? ?? __ ?? ?? ??
?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? D4 ?? ?? SB

References:
[1]: IBM Corporate Standard, C-S 3-3220-002 (May 1990) -- archived IBM excerpt available at https://web.archive.org/web/20180911044845/https://www-01.ibm.com/software/globalization/cdra/appendix_g1.html
[2]: IBM 3270 Information Display System Character Set Reference, GA27-2837-9 (April 1987) -- copy available at http://bitsavers.trailing-edge.com/pdf/ibm/3270/GA27-2837-9_3270_Character_Set_Reference_Apr87.pdf

Errata ID: 6050
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip Børgesen
Date Reported: 2020-04-01

Section 5 says:

  &charset EBCDIC-UK
  &rem source: IBM 3270 Char Set Ref Ch 10, GA27-2837-9, April 1987
  &code 0
  NU SH SX EX ET EQ AK BL BS HT LF VT FF CR SO SI
  DL D1 D2 D3 D4 NK SY EB CN EM SB EC FS GS RS US
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  SP ?? ?? ?? ?? ?? ?? ?? ?? ?? DO .  <  (  +  !!
  &  ?? ?? ?? ?? ?? ?? ?? ?? ?? !  Pd *  )  ;  NO
  -  /  ?? ?? ?? ?? ?? ?? ?? ?? BB ,  %  _  >  ?
  ?? ?? ?? ?? ?? ?? ?? ?? ?? '! :  Nb At '  =  "
  ?? a  b  c  d  e  f  g  h  i  ?? ?? ?? ?? ?? ??
  ?? j  k  l  m  n  o  p  q  r  ?? ?? ?? ?? ?? ??
  ?? '- s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  (! A  B  C  D  E  F  G  H  I  ?? ?? ?? ?? ?? ??
  !) J  K  L  M  N  O  P  Q  R  ?? ?? ?? ?? ?? ??
  // ?? S  T  U  V  W  X  Y  Z  ?? ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? ?? ?? ?? ?? DT

It should say:

  &charset EBCDIC-UK
  &rem source: IBM 3270 Char Set Ref Ch 10, GA27-2837-9, April 1987
  &rem source: IBM Corporate Standard, C-S 3-3220-002
  &code 0
  NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
  DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
  __ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
  ?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB
  SP ?? ?? ?? ?? ?? ?? ?? ?? ?? DO .  <  (  +  !!
  &  ?? ?? ?? ?? ?? ?? ?? ?? ?? !  Pd *  )  ;  NO
  -  /  ?? ?? ?? ?? ?? ?? ?? ?? BB ,  %  _  >  ?
  ?? ?? ?? ?? ?? ?? ?? ?? ?? '! :  Nb At '  =  "
  ?? a  b  c  d  e  f  g  h  i  ?? ?? ?? ?? ?? ??
  ?? j  k  l  m  n  o  p  q  r  ?? ?? ?? ?? ?? ??
  ?? '- s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  (! A  B  C  D  E  F  G  H  I  ?? ?? ?? ?? ?? ??
  !) J  K  L  M  N  O  P  Q  R  ?? ?? ?? ?? ?? ??
  // ?? S  T  U  V  W  X  Y  Z  ?? ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? ?? ?? ?? ?? __
  &duplicate 1F __

Notes:

The EBCDIC character sets do not use the ASCII control codes.
Based on [1] the EBCDIC control codes located at hex 00-3F are

NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
__ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB

with __ marking control codes with no ISO 10646 mapping.
The control code at hex 1F can depending on context either mean "Interchange Unit Separator" or "Intermediate Transmission Block" but only the prior has an ISO 10646 mapping (mnemonic US). The "&duplicate 1F __" part marks the alternative character with no available mapping. Note that in EBCDIC the "Delete" character is located at hex 07 while hex FF is "Eight Ones", another character with no ISO 10646 equivalent.

For the sake of completeness I note that the originally listed source [2] only specifies a subset of the character codes in hex range 00-3F (see Figure 10-1), namely:

NU ?? ?? ?? ?? HT ?? ?? __ ?? ?? ?? FF CR ?? ??
?? D1 D2 D3 ?? NL ?? ?? ?? EM ?? ?? FS GS RS ??
?? ?? ?? ?? ?? ?? ?? ?? __ __ ?? ?? __ ?? ?? ??
?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? D4 ?? ?? SB

References:
[1]: IBM Corporate Standard, C-S 3-3220-002 (May 1990) -- archived IBM excerpt available at https://web.archive.org/web/20180911044845/https://www-01.ibm.com/software/globalization/cdra/appendix_g1.html
[2]: IBM 3270 Information Display System Character Set Reference, GA27-2837-9 (April 1987) -- copy available at http://bitsavers.trailing-edge.com/pdf/ibm/3270/GA27-2837-9_3270_Character_Set_Reference_Apr87.pdf

Errata ID: 6051
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip Børgesen
Date Reported: 2020-04-01

Section 5 says:

  &charset EBCDIC-US
  &rem source: IBM 3270 Char Set Ref Ch 10, GA27-2837-9, April 1987
  &code 0
  NU SH SX EX ET EQ AK BL BS HT LF VT FF CR SO SI
  DL D1 D2 D3 D4 NK SY EB CN EM SB EC FS GS RS US
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  SP ?? ?? ?? ?? ?? ?? ?? ?? ?? Ct .  <  (  +  !!
  &  ?? ?? ?? ?? ?? ?? ?? ?? ?? !  DO *  )  ;  NO
  -  /  ?? ?? ?? ?? ?? ?? ?? ?? BB ,  %  _  >  ?
  ?? ?? ?? ?? ?? ?? ?? ?? ?? '! :  Nb At '  =  "
  ?? a  b  c  d  e  f  g  h  i  ?? ?? ?? ?? ?? ??
  ?? j  k  l  m  n  o  p  q  r  ?? ?? ?? ?? ?? ??
  ?? '? s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  (! A  B  C  D  E  F  G  H  I  ?? ?? ?? ?? ?? ??
  !) J  K  L  M  N  O  P  Q  R  ?? ?? ?? ?? ?? ??
  // ?? S  T  U  V  W  X  Y  Z  ?? ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? ?? ?? ?? ?? DT

It should say:

  &charset EBCDIC-US
  &rem source: IBM 3270 Char Set Ref Ch 10, GA27-2837-9, April 1987
  &rem source: IBM Corporate Standard, C-S 3-3220-002
  &code 0
  NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
  DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
  __ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
  ?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB
  SP ?? ?? ?? ?? ?? ?? ?? ?? ?? Ct .  <  (  +  !!
  &  ?? ?? ?? ?? ?? ?? ?? ?? ?? !  DO *  )  ;  NO
  -  /  ?? ?? ?? ?? ?? ?? ?? ?? BB ,  %  _  >  ?
  ?? ?? ?? ?? ?? ?? ?? ?? ?? '! :  Nb At '  =  "
  ?? a  b  c  d  e  f  g  h  i  ?? ?? ?? ?? ?? ??
  ?? j  k  l  m  n  o  p  q  r  ?? ?? ?? ?? ?? ??
  ?? '? s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  (! A  B  C  D  E  F  G  H  I  ?? ?? ?? ?? ?? ??
  !) J  K  L  M  N  O  P  Q  R  ?? ?? ?? ?? ?? ??
  // ?? S  T  U  V  W  X  Y  Z  ?? ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? ?? ?? ?? ?? __
  &duplicate 1F __

Notes:

The EBCDIC character sets do not use the ASCII control codes.
Based on [1] the EBCDIC control codes located at hex 00-3F are

NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
__ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB

with __ marking control codes with no ISO 10646 mapping.
The control code at hex 1F can depending on context either mean "Interchange Unit Separator" or "Intermediate Transmission Block" but only the prior has an ISO 10646 mapping (mnemonic US). The "&duplicate 1F __" part marks the alternative character with no available mapping. Note that in EBCDIC the "Delete" character is located at hex 07 while hex FF is "Eight Ones", another character with no ISO 10646 equivalent.

For the sake of completeness I note that the originally listed source [2] only specifies a subset of the character codes in hex range 00-3F (see Figure 10-1), namely:

NU ?? ?? ?? ?? HT ?? ?? __ ?? ?? ?? FF CR ?? ??
?? D1 D2 D3 ?? NL ?? ?? ?? EM ?? ?? FS GS RS ??
?? ?? ?? ?? ?? ?? ?? ?? __ __ ?? ?? __ ?? ?? ??
?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? D4 ?? ?? SB

References:
[1]: IBM Corporate Standard, C-S 3-3220-002 (May 1990) -- archived IBM excerpt available at https://web.archive.org/web/20180911044845/https://www-01.ibm.com/software/globalization/cdra/appendix_g1.html
[2]: IBM 3270 Information Display System Character Set Reference, GA27-2837-9 (April 1987) -- copy available at http://bitsavers.trailing-edge.com/pdf/ibm/3270/GA27-2837-9_3270_Character_Set_Reference_Apr87.pdf

Errata ID: 6052
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip Børgesen
Date Reported: 2020-04-01

Section 5 says:

  &charset IBM038
  &rem source: IBM 3174 Character Set Ref, GA27-3831-02, March 1990
  &alias EBCDIC-INT
  &alias cp038
  &code 0
  NU SH SX EX ET EQ AK BL BS HT LF VT FF CR SO SI
  DL D1 D2 D3 D4 NK SY EB CN EM SB EC FS GS RS US
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  SP ?? ?? ?? ?? ?? ?? ?? ?? ?? <( .  <  (  +  !
  &  ?? ?? ?? ?? ?? ?? ?? ?? ?? )> DO *  )  ;  '>
  -  /  ?? ?? ?? ?? ?? ?? ?? ?? BB ,  %  _  >  ?
  ?? ?? ?? ?? ?? ?? ?? ?? ?? '! :  Nb At '  =  "
  ?? a  b  c  d  e  f  g  h  i  ?? ?? ?? ?? ?? ??
  ?? j  k  l  m  n  o  p  q  r  ?? ?? ?? ?? ?? ??
  ?? '? s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  (! A  B  C  D  E  F  G  H  I  ?? ?? ?? ?? ?? ??
  !) J  K  L  M  N  O  P  Q  R  ?? ?? ?? ?? ?? ??
  // ?? S  T  U  V  W  X  Y  Z  ?? ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? ?? ?? ?? ?? DT

It should say:

  &charset IBM038
  &rem source: IBM 3174 Character Set Ref, GA27-3831-02, March 1990
  &rem source: IBM Corporate Standard, C-S 3-3220-002
  &alias EBCDIC-INT
  &alias cp038
  &code 0
  NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
  DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
  __ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
  ?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB
  SP ?? ?? ?? ?? ?? ?? ?? ?? ?? <( .  <  (  +  !
  &  ?? ?? ?? ?? ?? ?? ?? ?? ?? )> DO *  )  ;  '>
  -  /  ?? ?? ?? ?? ?? ?? ?? ?? BB ,  %  _  >  ?
  ?? ?? ?? ?? ?? ?? ?? ?? ?? '! :  Nb At '  =  "
  ?? a  b  c  d  e  f  g  h  i  ?? ?? ?? ?? ?? ??
  ?? j  k  l  m  n  o  p  q  r  ?? ?? ?? ?? ?? ??
  ?? '? s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  (! A  B  C  D  E  F  G  H  I  ?? ?? ?? ?? ?? ??
  !) J  K  L  M  N  O  P  Q  R  ?? ?? ?? ?? ?? ??
  // ?? S  T  U  V  W  X  Y  Z  ?? ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? ?? ?? ?? ?? __
  &duplicate 1F __

Notes:

The EBCDIC character sets do not use the ASCII control codes.
Based on [1] the EBCDIC control codes located at hex 00-3F are

NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
__ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB

with __ marking control codes with no ISO 10646 mapping.
The control code at hex 1F can depending on context either mean "Interchange Unit Separator" or "Intermediate Transmission Block" but only the prior has an ISO 10646 mapping (mnemonic US). The "&duplicate 1F __" part marks the alternative character with no available mapping. Note that in EBCDIC the "Delete" character is located at hex 07 while hex FF is "Eight Ones", another character with no ISO 10646 equivalent.

References:
[1]: IBM Corporate Standard, C-S 3-3220-002 (May 1990) -- archived IBM excerpt available at https://web.archive.org/web/20180911044845/https://www-01.ibm.com/software/globalization/cdra/appendix_g1.html

Errata ID: 6053
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip Børgesen
Date Reported: 2020-04-01

Section 5 says:

  &charset IBM274
  &rem source: IBM 3174 Character Set Ref, GA27-3831-02, March 1990
  &alias EBCDIC-BE
  &alias CP274
  &code 0
  NU SH SX EX ET EQ AK BL BS HT LF VT FF CR SO SI
  DL D1 D2 D3 D4 NK SY EB CN EM SB EC FS GS RS US
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  SP ?? ?? ?? ?? ?? ?? ?? ?? ?? <( .  <  (  +  !
  &  ?? ?? ?? ?? ?? ?? ?? ?? ?? )> DO *  )  ;  '>
  -  /  ?? ?? ?? ?? ?? ?? ?? ?? u! ,  %  _  >  ?
  ?? ?? ?? ?? ?? ?? ?? ?? ?? '! :  Nb a! '  =  "
  ?? a  b  c  d  e  f  g  h  i  ?? ?? ?? ?? ?? ??
  ?? j  k  l  m  n  o  p  q  r  ?? ?? ?? ?? ?? ??
  ?? ': s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  e' A  B  C  D  E  F  G  H  I  ?? ?? ?? ?? ?? ??
  e! J  K  L  M  N  O  P  Q  R  ?? ?? ?? ?? ?? ??
  c, ?? S  T  U  V  W  X  Y  Z  ?? ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? ?? ?? ?? ?? DT

It should say:

  &charset IBM274
  &rem source: IBM 3174 Character Set Ref, GA27-3831-02, March 1990
  &rem source: IBM Corporate Standard, C-S 3-3220-002
  &alias EBCDIC-BE
  &alias CP274
  &code 0
  NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
  DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
  __ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
  ?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB
  SP ?? ?? ?? ?? ?? ?? ?? ?? ?? <( .  <  (  +  !
  &  ?? ?? ?? ?? ?? ?? ?? ?? ?? )> DO *  )  ;  '>
  -  /  ?? ?? ?? ?? ?? ?? ?? ?? u! ,  %  _  >  ?
  ?? ?? ?? ?? ?? ?? ?? ?? ?? '! :  Nb a! '  =  "
  ?? a  b  c  d  e  f  g  h  i  ?? ?? ?? ?? ?? ??
  ?? j  k  l  m  n  o  p  q  r  ?? ?? ?? ?? ?? ??
  ?? ': s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  e' A  B  C  D  E  F  G  H  I  ?? ?? ?? ?? ?? ??
  e! J  K  L  M  N  O  P  Q  R  ?? ?? ?? ?? ?? ??
  c, ?? S  T  U  V  W  X  Y  Z  ?? ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? ?? ?? ?? ?? __
  &duplicate 1F __

Notes:

The EBCDIC character sets do not use the ASCII control codes.
Based on [1] the EBCDIC control codes located at hex 00-3F are

NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
__ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB

with __ marking control codes with no ISO 10646 mapping.
The control code at hex 1F can depending on context either mean "Interchange Unit Separator" or "Intermediate Transmission Block" but only the prior has an ISO 10646 mapping (mnemonic US). The "&duplicate 1F __" part marks the alternative character with no available mapping. Note that in EBCDIC the "Delete" character is located at hex 07 while hex FF is "Eight Ones", another character with no ISO 10646 equivalent.

References:
[1]: IBM Corporate Standard, C-S 3-3220-002 (May 1990) -- archived IBM excerpt available at https://web.archive.org/web/20180911044845/https://www-01.ibm.com/software/globalization/cdra/appendix_g1.html

Errata ID: 6054
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip Børgesen
Date Reported: 2020-04-01

Section 5 says:

  &charset IBM281
  &rem source: IBM 3174 Character Set Ref, GA27-3831-02, March 1990
  &alias EBCDIC-JP-E
  &alias cp281
  &code 0
  NU SH SX EX ET EQ AK BL BS HT LF VT FF CR SO SI
  DL D1 D2 D3 D4 NK SY EB CN EM SB EC FS GS RS US
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  SP ?? ?? ?? ?? ?? ?? ?? ?? ?? Pd .  <  (  +  !!
  &  ?? ?? ?? ?? ?? ?? ?? ?? ?? !  Ye *  )  ;  NO
  -  /  ?? ?? ?? ?? ?? ?? ?? ?? BB ,  %  _  >  ?
  ?? ?? ?? ?? ?? ?? ?? ?? ?? '! :  Nb At '  =  "
  ?? a  b  c  d  e  f  g  h  i  ?? ?? ?? ?? ?? ??
  ?? j  k  l  m  n  o  p  q  r  ?? ?? ?? ?? ?? ??
  ?? '- s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  (! A  B  C  D  E  F  G  H  I  ?? ?? ?? ?? ?? ??
  !) J  K  L  M  N  O  P  Q  R  ?? ?? ?? ?? ?? ??
  DO ?? S  T  U  V  W  X  Y  Z  ?? ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? ?? ?? ?? ?? DT

It should say:

  &charset IBM281
  &rem source: IBM 3174 Character Set Ref, GA27-3831-02, March 1990
  &rem source: IBM Corporate Standard, C-S 3-3220-002
  &alias EBCDIC-JP-E
  &alias cp281
  &code 0
  NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
  DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
  __ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
  ?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB
  SP ?? ?? ?? ?? ?? ?? ?? ?? ?? Pd .  <  (  +  !!
  &  ?? ?? ?? ?? ?? ?? ?? ?? ?? !  Ye *  )  ;  NO
  -  /  ?? ?? ?? ?? ?? ?? ?? ?? BB ,  %  _  >  ?
  ?? ?? ?? ?? ?? ?? ?? ?? ?? '! :  Nb At '  =  "
  ?? a  b  c  d  e  f  g  h  i  ?? ?? ?? ?? ?? ??
  ?? j  k  l  m  n  o  p  q  r  ?? ?? ?? ?? ?? ??
  ?? '- s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  (! A  B  C  D  E  F  G  H  I  ?? ?? ?? ?? ?? ??
  !) J  K  L  M  N  O  P  Q  R  ?? ?? ?? ?? ?? ??
  DO ?? S  T  U  V  W  X  Y  Z  ?? ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? ?? ?? ?? ?? __
  &duplicate 1F __

Notes:

The EBCDIC character sets do not use the ASCII control codes.
Based on [1] the EBCDIC control codes located at hex 00-3F are

NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
__ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB

with __ marking control codes with no ISO 10646 mapping.
The control code at hex 1F can depending on context either mean "Interchange Unit Separator" or "Intermediate Transmission Block" but only the prior has an ISO 10646 mapping (mnemonic US). The "&duplicate 1F __" part marks the alternative character with no available mapping. Note that in EBCDIC the "Delete" character is located at hex 07 while hex FF is "Eight Ones", another character with no ISO 10646 equivalent.

References:
[1]: IBM Corporate Standard, C-S 3-3220-002 (May 1990) -- archived IBM excerpt available at https://web.archive.org/web/20180911044845/https://www-01.ibm.com/software/globalization/cdra/appendix_g1.html

Errata ID: 6055
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip Børgesen
Date Reported: 2020-04-01

Section 5 says:

  &charset IBM290
  &rem source: IBM 3174 Character Set Ref, GA27-3831-02, March 1990
  &alias cp290
  &alias EBCDIC-JP-kana
  &code 0
  NU SH SX EX ET EQ AK BL BS HT LF VT FF CR SO SI
  DL D1 D2 D3 D4 NK SY EB CN EM SB EC FS GS RS US
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  SP ._ <' >' ,_ .6 Wo a6 i6 u6 Pd .  <  (  +  !!
  &  e6 o6 YA YU YO TU ?? -6 ?? !  Ye *  )  ;  NO
  -  /  ?? ?? ?? ?? ?? ?? ?? ?? BB ,  %  _  >  ?
  ?? ?? ?? ?? ?? ?? ?? ?? ?? '! :  Nb At '  =  "
  ?? A6 I6 U6 E6 O6 Ka Ki Ku Ke Ko ?? Sa Si Su Se
  So Ta Ti Tu Te To Na Ni Nu Ne No ?? ?? Ha Hi Hu
  ?? '- He Ho Ma Mi Mu Me Mo Ya Yu ?? Yo Ra Ri Ru
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? Re Ro Wa N6 "5 05
  ?? A  B  C  D  E  F  G  H  I  ?? ?? ?? ?? ?? ??
  ?? J  K  L  M  N  O  P  Q  R  ?? ?? ?? ?? ?? ??
  DO ?? S  T  U  V  W  X  Y  Z  ?? ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? ?? ?? ?? ?? DT

It should say:

  &charset IBM290
  &rem source: IBM 3174 Character Set Ref, GA27-3831-02, March 1990
  &rem source: IBM Corporate Standard, C-S 3-3220-002
  &alias cp290
  &alias EBCDIC-JP-kana
  &code 0
  NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
  DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
  __ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
  ?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB
  SP ._ <' >' ,_ .6 Wo a6 i6 u6 Pd .  <  (  +  !!
  &  e6 o6 YA YU YO TU ?? -6 ?? !  Ye *  )  ;  NO
  -  /  ?? ?? ?? ?? ?? ?? ?? ?? BB ,  %  _  >  ?
  ?? ?? ?? ?? ?? ?? ?? ?? ?? '! :  Nb At '  =  "
  ?? A6 I6 U6 E6 O6 Ka Ki Ku Ke Ko ?? Sa Si Su Se
  So Ta Ti Tu Te To Na Ni Nu Ne No ?? ?? Ha Hi Hu
  ?? '- He Ho Ma Mi Mu Me Mo Ya Yu ?? Yo Ra Ri Ru
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? Re Ro Wa N6 "5 05
  ?? A  B  C  D  E  F  G  H  I  ?? ?? ?? ?? ?? ??
  ?? J  K  L  M  N  O  P  Q  R  ?? ?? ?? ?? ?? ??
  DO ?? S  T  U  V  W  X  Y  Z  ?? ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? ?? ?? ?? ?? __
  &duplicate 1F __

Notes:

The EBCDIC character sets do not use the ASCII control codes.
Based on [1] the EBCDIC control codes located at hex 00-3F are

NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
__ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB

with __ marking control codes with no ISO 10646 mapping.
The control code at hex 1F can depending on context either mean "Interchange Unit Separator" or "Intermediate Transmission Block" but only the prior has an ISO 10646 mapping (mnemonic US). The "&duplicate 1F __" part marks the alternative character with no available mapping. Note that in EBCDIC the "Delete" character is located at hex 07 while hex FF is "Eight Ones", another character with no ISO 10646 equivalent.

References:
[1]: IBM Corporate Standard, C-S 3-3220-002 (May 1990) -- archived IBM excerpt available at https://web.archive.org/web/20180911044845/https://www-01.ibm.com/software/globalization/cdra/appendix_g1.html

Errata ID: 6056
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip Børgesen
Date Reported: 2020-04-01

Section 5 says:

  &charset IBM905
  &rem source: IBM 3174 Character Set Ref, GA27-3831-02, March 1990
  &alias CP905
  &alias ebcdic-cp-tr
  &code 0
  NU SH SX EX ET EQ AK BL BS HT LF VT FF CR SO SI
  DL D1 D2 D3 D4 NK SY EB CN EM SB EC FS GS RS US
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  SP ?? a> a: a! a' ?? c. (! n? C, .  <  (  +  !
  &  e' e> e: e! i' i> i: i! ss G( I. *  )  ;  '>
  -  /  A> A: A! A' ?? C. <( N? s, ,  %  _  >  ?
  ?? E' E> E: E! I' I> I: I! i. :  O: S, '  =  U:
  '( a  b  c  d  e  f  g  h  i  h/ c> s> u( ?? !!
  DG j  k  l  m  n  o  p  q  r  h> g> j> '; ?? Cu
  My o: s  t  u  v  w  x  y  z  H/ C> S> U( ?? At
  .M Pd z. !) Z. SE )> ?? 12 DO H> G> J> ': '' *X
  c, A  B  C  D  E  F  G  H  I  -- o> '? o! o' g.
  g( J  K  L  M  N  O  P  Q  R  '! u> // u! u' ??
  u: -: S  T  U  V  W  X  Y  Z  2S O> Nb O! O' G.
  0  1  2  3  4  5  6  7  8  9  3S U> "  U! U' DT

It should say:

  &charset IBM905
  &rem source: IBM 3174 Character Set Ref, GA27-3831-02, March 1990
  &rem source: IBM Corporate Standard, C-S 3-3220-002
  &alias CP905
  &alias ebcdic-cp-tr
  &code 0
  NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
  DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
  __ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
  ?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB
  SP ?? a> a: a! a' ?? c. (! n? C, .  <  (  +  !
  &  e' e> e: e! i' i> i: i! ss G( I. *  )  ;  '>
  -  /  A> A: A! A' ?? C. <( N? s, ,  %  _  >  ?
  ?? E' E> E: E! I' I> I: I! i. :  O: S, '  =  U:
  '( a  b  c  d  e  f  g  h  i  h/ c> s> u( ?? !!
  DG j  k  l  m  n  o  p  q  r  h> g> j> '; ?? Cu
  My o: s  t  u  v  w  x  y  z  H/ C> S> U( ?? At
  .M Pd z. !) Z. SE )> ?? 12 DO H> G> J> ': '' *X
  c, A  B  C  D  E  F  G  H  I  -- o> '? o! o' g.
  g( J  K  L  M  N  O  P  Q  R  '! u> // u! u' ??
  u: -: S  T  U  V  W  X  Y  Z  2S O> Nb O! O' G.
  0  1  2  3  4  5  6  7  8  9  3S U> "  U! U' __
  &duplicate 1F __

Notes:

The EBCDIC character sets do not use the ASCII control codes.
Based on [1] the EBCDIC control codes located at hex 00-3F are

NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
__ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB

with __ marking control codes with no ISO 10646 mapping.
The control code at hex 1F can depending on context either mean "Interchange Unit Separator" or "Intermediate Transmission Block" but only the prior has an ISO 10646 mapping (mnemonic US). The "&duplicate 1F __" part marks the alternative character with no available mapping. Note that in EBCDIC the "Delete" character is located at hex 07 while hex FF is "Eight Ones", another character with no ISO 10646 equivalent.

References:
[1]: IBM Corporate Standard, C-S 3-3220-002 (May 1990) -- archived IBM excerpt available at https://web.archive.org/web/20180911044845/https://www-01.ibm.com/software/globalization/cdra/appendix_g1.html

Errata ID: 6057
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip Børgesen
Date Reported: 2020-04-01

Section 5 says:

  &charset IBM037
  &rem source: IBM NLS RM Vol2 SE09-8002-01, March 1990
  &alias cp037
  &alias ebcdic-cp-us
  &alias ebcdic-cp-ca
  &alias ebcdic-cp-wt
  &alias ebcdic-cp-nl
  &code 0
  NU SH SX EX ET EQ AK BL BS HT LF VT FF CR SO SI
  DL D1 D2 D3 D4 NK SY EB CN EM SB EC FS GS RS US
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  SP NS a> a: a! a' a? aa c, n? Ct .  <  (  +  !!
  &  e' e> e: e! i' i> i: i! ss !  DO *  )  ;  NO
  -  /  A> A: A! A' A? AA C, N? BB ,  %  _  >  ?
  o/ E' E> E: E! I' I> I: I! '! :  Nb At '  =  "
  O/ a  b  c  d  e  f  g  h  i  << >> d- y' th +-
  DG j  k  l  m  n  o  p  q  r  -a -o ae ', AE Cu
  My '? s  t  u  v  w  x  y  z  !I ?I D- Y' TH Rg
  '> Pd Ye .M Co SE PI 14 12 34 <( )> '- ': '' *X
  (! A  B  C  D  E  F  G  H  I  -- o> o: o! o' o?
  !) J  K  L  M  N  O  P  Q  R  1S u> u: u! u' y:
  // -: S  T  U  V  W  X  Y  Z  2S O> O: O! O' O?
  0  1  2  3  4  5  6  7  8  9  3S U> U: U! U' DT

It should say:

  &charset IBM037
  &rem source: IBM NLS RM Vol2 SE09-8002-01, March 1990
  &rem source: IBM Corporate Standard, C-S 3-3220-002
  &alias cp037
  &alias ebcdic-cp-us
  &alias ebcdic-cp-ca
  &alias ebcdic-cp-wt
  &alias ebcdic-cp-nl
  &code 0
  NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
  DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
  __ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
  ?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB
  SP NS a> a: a! a' a? aa c, n? Ct .  <  (  +  !!
  &  e' e> e: e! i' i> i: i! ss !  DO *  )  ;  NO
  -  /  A> A: A! A' A? AA C, N? BB ,  %  _  >  ?
  o/ E' E> E: E! I' I> I: I! '! :  Nb At '  =  "
  O/ a  b  c  d  e  f  g  h  i  << >> d- y' th +-
  DG j  k  l  m  n  o  p  q  r  -a -o ae ', AE Cu
  My '? s  t  u  v  w  x  y  z  !I ?I D- Y' TH Rg
  '> Pd Ye .M Co SE PI 14 12 34 <( )> '- ': '' *X
  (! A  B  C  D  E  F  G  H  I  -- o> o: o! o' o?
  !) J  K  L  M  N  O  P  Q  R  1S u> u: u! u' y:
  // -: S  T  U  V  W  X  Y  Z  2S O> O: O! O' O?
  0  1  2  3  4  5  6  7  8  9  3S U> U: U! U' __
  &duplicate 1F __

Notes:

The EBCDIC character sets do not use the ASCII control codes.
Based on [1] the EBCDIC control codes located at hex 00-3F are

NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
__ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB

with __ marking control codes with no ISO 10646 mapping.
The control code at hex 1F can depending on context either mean "Interchange Unit Separator" or "Intermediate Transmission Block" but only the prior has an ISO 10646 mapping (mnemonic US). The "&duplicate 1F __" part marks the alternative character with no available mapping. Note that in EBCDIC the "Delete" character is located at hex 07 while hex FF is "Eight Ones", another character with no ISO 10646 equivalent.

References:
[1]: IBM Corporate Standard, C-S 3-3220-002 (May 1990) -- archived IBM excerpt available at https://web.archive.org/web/20180911044845/https://www-01.ibm.com/software/globalization/cdra/appendix_g1.html

Errata ID: 6058
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip Børgesen
Date Reported: 2020-04-01

Section 5 says:

  &charset IBM273
  &rem source: IBM NLS RM Vol2 SE09-8002-01, March 1990
  &alias CP273
  &code 0
  NU SH SX EX ET EQ AK BL BS HT LF VT FF CR SO SI
  DL D1 D2 D3 D4 NK SY EB CN EM SB EC FS GS RS US
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  SP NS a> (! a! a' a? aa c, n? A: .  <  (  +  !
  &  e' e> e: e! i' i> i: i! '? U: DO *  )  ;  '>
  -  /  A> <( A! A' A? AA C, N? o: ,  %  _  >  ?
  o/ E' E> E: E! I' I> I: I! '! :  Nb SE '  =  "
  O/ a  b  c  d  e  f  g  h  i  << >> d- y' th +-
  DG j  k  l  m  n  o  p  q  r  -a -o ae ', AE Cu
  My ss s  t  u  v  w  x  y  z  !I ?I D- Y' TH Rg
  Ct Pd Ye .M Co At PI 14 12 34 NO !! '- ': '' *X
  a: A  B  C  D  E  F  G  H  I  -- o> BB o! o' o?
  u: J  K  L  M  N  O  P  Q  R  1S u> !) u! u' y:
  O: -: S  T  U  V  W  X  Y  Z  2S O> // O! O' O?
  0  1  2  3  4  5  6  7  8  9  3S U> )> U! U' DT

It should say:

  &charset IBM273
  &rem source: IBM NLS RM Vol2 SE09-8002-01, March 1990
  &rem source: IBM Corporate Standard, C-S 3-3220-002
  &alias CP273
  &code 0
  NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
  DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
  __ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
  ?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB
  SP NS a> (! a! a' a? aa c, n? A: .  <  (  +  !
  &  e' e> e: e! i' i> i: i! '? U: DO *  )  ;  '>
  -  /  A> <( A! A' A? AA C, N? o: ,  %  _  >  ?
  o/ E' E> E: E! I' I> I: I! '! :  Nb SE '  =  "
  O/ a  b  c  d  e  f  g  h  i  << >> d- y' th +-
  DG j  k  l  m  n  o  p  q  r  -a -o ae ', AE Cu
  My ss s  t  u  v  w  x  y  z  !I ?I D- Y' TH Rg
  Ct Pd Ye .M Co At PI 14 12 34 NO !! '- ': '' *X
  a: A  B  C  D  E  F  G  H  I  -- o> BB o! o' o?
  u: J  K  L  M  N  O  P  Q  R  1S u> !) u! u' y:
  O: -: S  T  U  V  W  X  Y  Z  2S O> // O! O' O?
  0  1  2  3  4  5  6  7  8  9  3S U> )> U! U' __
  &duplicate 1F __

Notes:

The EBCDIC character sets do not use the ASCII control codes.
Based on [1] the EBCDIC control codes located at hex 00-3F are

NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
__ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB

with __ marking control codes with no ISO 10646 mapping.
The control code at hex 1F can depending on context either mean "Interchange Unit Separator" or "Intermediate Transmission Block" but only the prior has an ISO 10646 mapping (mnemonic US). The "&duplicate 1F __" part marks the alternative character with no available mapping. Note that in EBCDIC the "Delete" character is located at hex 07 while hex FF is "Eight Ones", another character with no ISO 10646 equivalent.

References:
[1]: IBM Corporate Standard, C-S 3-3220-002 (May 1990) -- archived IBM excerpt available at https://web.archive.org/web/20180911044845/https://www-01.ibm.com/software/globalization/cdra/appendix_g1.html

Errata ID: 6059
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip Børgesen
Date Reported: 2020-04-01

Section 5 says:

  &charset IBM275
  &rem source: IBM NLS RM Vol2 SE09-8002-01, March 1990
  &alias EBCDIC-BR
  &alias cp275
  &code 0
  NU SH SX EX ET EQ AK BL BS HT LF VT FF CR SO SI
  DL D1 D2 D3 D4 NK SY EB CN EM SB EC FS GS RS US
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  SP ?? ?? ?? ?? ?? ?? ?? ?? ?? E' .  <  (  +  !
  &  ?? ?? ?? ?? ?? ?? ?? ?? ?? DO C, *  )  ;  '>
  -  /  ?? ?? ?? ?? ?? ?? ?? ?? c, ,  %  _  >  ?
  ?? ?? ?? ?? ?? ?? ?? ?? ?? a? :  O? A? '  =  "
  ?? a  b  c  d  e  f  g  h  i  ?? ?? ?? ?? ?? ??
  ?? j  k  l  m  n  o  p  q  r  ?? ?? ?? ?? ?? ??
  ?? '? s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  o? A  B  C  D  E  F  G  H  I  ?? ?? ?? ?? ?? ??
  e' J  K  L  M  N  O  P  Q  R  ?? ?? ?? ?? ?? ??
  // ?? S  T  U  V  W  X  Y  Z  ?? ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? ?? ?? ?? ?? DT

It should say:

  &charset IBM275
  &rem source: IBM NLS RM Vol2 SE09-8002-01, March 1990
  &rem source: IBM Corporate Standard, C-S 3-3220-002
  &alias EBCDIC-BR
  &alias cp275
  &code 0
  NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
  DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
  __ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
  ?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB
  SP ?? ?? ?? ?? ?? ?? ?? ?? ?? E' .  <  (  +  !
  &  ?? ?? ?? ?? ?? ?? ?? ?? ?? DO C, *  )  ;  '>
  -  /  ?? ?? ?? ?? ?? ?? ?? ?? c, ,  %  _  >  ?
  ?? ?? ?? ?? ?? ?? ?? ?? ?? a? :  O? A? '  =  "
  ?? a  b  c  d  e  f  g  h  i  ?? ?? ?? ?? ?? ??
  ?? j  k  l  m  n  o  p  q  r  ?? ?? ?? ?? ?? ??
  ?? '? s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  o? A  B  C  D  E  F  G  H  I  ?? ?? ?? ?? ?? ??
  e' J  K  L  M  N  O  P  Q  R  ?? ?? ?? ?? ?? ??
  // ?? S  T  U  V  W  X  Y  Z  ?? ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  ?? ?? ?? ?? ?? __
  &duplicate 1F __

Notes:

The EBCDIC character sets do not use the ASCII control codes.
Based on [1] the EBCDIC control codes located at hex 00-3F are

NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
__ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB

with __ marking control codes with no ISO 10646 mapping.
The control code at hex 1F can depending on context either mean "Interchange Unit Separator" or "Intermediate Transmission Block" but only the prior has an ISO 10646 mapping (mnemonic US). The "&duplicate 1F __" part marks the alternative character with no available mapping. Note that in EBCDIC the "Delete" character is located at hex 07 while hex FF is "Eight Ones", another character with no ISO 10646 equivalent.

References:
[1]: IBM Corporate Standard, C-S 3-3220-002 (May 1990) -- archived IBM excerpt available at https://web.archive.org/web/20180911044845/https://www-01.ibm.com/software/globalization/cdra/appendix_g1.html

Errata ID: 6060
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip Børgesen
Date Reported: 2020-04-01

Section 5 says:

  &charset IBM277
  &rem source: IBM NLS RM Vol2 SE09-8002-01, March 1990
  &alias EBCDIC-CP-DK
  &alias EBCDIC-CP-NO
  &code 0
  NU SH SX EX ET EQ AK BL BS HT LF VT FF CR SO SI
  DL D1 D2 D3 D4 NK SY EB CN EM SB EC FS GS RS US
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  SP NS a> a: a! a' a? !) c, n? Nb .  <  (  +  !
  &  e' e> e: e! i' i> i: i! ss Cu AA *  )  ;  '>
  -  /  A> A: A! A' A? DO C, N? o/ ,  %  _  >  ?
  BB E' E> E: E! I' I> I: I! '! :  AE O/ '  =  "
  At a  b  c  d  e  f  g  h  i  << >> d- y' th +-
  DG j  k  l  m  n  o  p  q  r  -a -o (! ', <( )>
  My u: s  t  u  v  w  x  y  z  !I ?I D- Y' TH Rg
  Ct Pd Ye .M Co SE PI 14 12 34 NO !! '- ': '' *X
  ae A  B  C  D  E  F  G  H  I  -- o> o: o! o' o?
  aa J  K  L  M  N  O  P  Q  R  1S u> '? u! u' y:
  // -: S  T  U  V  W  X  Y  Z  2S O> O: O! O' O?
  0  1  2  3  4  5  6  7  8  9  3S U> U: U! U' DT

It should say:

  &charset IBM277
  &rem source: IBM NLS RM Vol2 SE09-8002-01, March 1990
  &rem source: IBM Corporate Standard, C-S 3-3220-002
  &alias EBCDIC-CP-DK
  &alias EBCDIC-CP-NO
  &code 0
  NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
  DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
  __ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
  ?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB
  SP NS a> a: a! a' a? !) c, n? Nb .  <  (  +  !
  &  e' e> e: e! i' i> i: i! ss Cu AA *  )  ;  '>
  -  /  A> A: A! A' A? DO C, N? o/ ,  %  _  >  ?
  BB E' E> E: E! I' I> I: I! '! :  AE O/ '  =  "
  At a  b  c  d  e  f  g  h  i  << >> d- y' th +-
  DG j  k  l  m  n  o  p  q  r  -a -o (! ', <( )>
  My u: s  t  u  v  w  x  y  z  !I ?I D- Y' TH Rg
  Ct Pd Ye .M Co SE PI 14 12 34 NO !! '- ': '' *X
  ae A  B  C  D  E  F  G  H  I  -- o> o: o! o' o?
  aa J  K  L  M  N  O  P  Q  R  1S u> '? u! u' y:
  // -: S  T  U  V  W  X  Y  Z  2S O> O: O! O' O?
  0  1  2  3  4  5  6  7  8  9  3S U> U: U! U' __
  &duplicate 1F __

Notes:

The EBCDIC character sets do not use the ASCII control codes.
Based on [1] the EBCDIC control codes located at hex 00-3F are

NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
__ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB

with __ marking control codes with no ISO 10646 mapping.
The control code at hex 1F can depending on context either mean "Interchange Unit Separator" or "Intermediate Transmission Block" but only the prior has an ISO 10646 mapping (mnemonic US). The "&duplicate 1F __" part marks the alternative character with no available mapping. Note that in EBCDIC the "Delete" character is located at hex 07 while hex FF is "Eight Ones", another character with no ISO 10646 equivalent.

References:
[1]: IBM Corporate Standard, C-S 3-3220-002 (May 1990) -- archived IBM excerpt available at https://web.archive.org/web/20180911044845/https://www-01.ibm.com/software/globalization/cdra/appendix_g1.html

Errata ID: 6061
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip Børgesen
Date Reported: 2020-04-01

Section 5 says:

  &charset IBM278
  &rem source: IBM NLS RM Vol2 SE09-8002-01, March 1990
  &alias CP278
  &alias ebcdic-cp-fi
  &alias ebcdic-cp-se
  &code 0
  NU SH SX EX ET EQ AK BL BS HT LF VT FF CR SO SI
  DL D1 D2 D3 D4 NK SY EB CN EM SB EC FS GS RS US
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  SP NS a> (! a! a' a? !) c, n? SE .  <  (  +  !
  &  '! e> e: e! i' i> i: i! ss Cu AA *  )  ;  '>
  -  /  A> Nb A! A' A? DO C, N? o: ,  %  _  >  ?
  o/ E' E> E: E! I' I> I: I! e' :  A: O: '  =  "
  O/ a  b  c  d  e  f  g  h  i  << >> d- y' th +-
  DG j  k  l  m  n  o  p  q  r  -a -o ae ', AE )>
  My u: s  t  u  v  w  x  y  z  !I ?I D- Y' TH Rg
  Ct Pd Ye .M Co <( PI 14 12 34 NO !! '- ': '' *X
  a: A  B  C  D  E  F  G  H  I  -- o> BB o! o' o?
  aa J  K  L  M  N  O  P  Q  R  1S u> '? u! u' y:
  // -: S  T  U  V  W  X  Y  Z  2S O> At O! O' O?
  0  1  2  3  4  5  6  7  8  9  3S U> U: U! U' DT

It should say:

  &charset IBM278
  &rem source: IBM NLS RM Vol2 SE09-8002-01, March 1990
  &rem source: IBM Corporate Standard, C-S 3-3220-002
  &alias CP278
  &alias ebcdic-cp-fi
  &alias ebcdic-cp-se
  &code 0
  NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
  DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
  __ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
  ?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB
  SP NS a> (! a! a' a? !) c, n? SE .  <  (  +  !
  &  '! e> e: e! i' i> i: i! ss Cu AA *  )  ;  '>
  -  /  A> Nb A! A' A? DO C, N? o: ,  %  _  >  ?
  o/ E' E> E: E! I' I> I: I! e' :  A: O: '  =  "
  O/ a  b  c  d  e  f  g  h  i  << >> d- y' th +-
  DG j  k  l  m  n  o  p  q  r  -a -o ae ', AE )>
  My u: s  t  u  v  w  x  y  z  !I ?I D- Y' TH Rg
  Ct Pd Ye .M Co <( PI 14 12 34 NO !! '- ': '' *X
  a: A  B  C  D  E  F  G  H  I  -- o> BB o! o' o?
  aa J  K  L  M  N  O  P  Q  R  1S u> '? u! u' y:
  // -: S  T  U  V  W  X  Y  Z  2S O> At O! O' O?
  0  1  2  3  4  5  6  7  8  9  3S U> U: U! U' __
  &duplicate 1F __

Notes:

The EBCDIC character sets do not use the ASCII control codes.
Based on [1] the EBCDIC control codes located at hex 00-3F are

NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
__ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB

with __ marking control codes with no ISO 10646 mapping.
The control code at hex 1F can depending on context either mean "Interchange Unit Separator" or "Intermediate Transmission Block" but only the prior has an ISO 10646 mapping (mnemonic US). The "&duplicate 1F __" part marks the alternative character with no available mapping. Note that in EBCDIC the "Delete" character is located at hex 07 while hex FF is "Eight Ones", another character with no ISO 10646 equivalent.

References:
[1]: IBM Corporate Standard, C-S 3-3220-002 (May 1990) -- archived IBM excerpt available at https://web.archive.org/web/20180911044845/https://www-01.ibm.com/software/globalization/cdra/appendix_g1.html

Errata ID: 6062
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip Børgesen
Date Reported: 2020-04-01

Section 5 says:

  &charset IBM280
  &rem source: IBM NLS RM Vol2 SE09-8002-01, March 1990
  &alias CP280
  &alias ebcdic-cp-it
  &code 0
  NU SH SX EX ET EQ AK BL BS HT LF VT FF CR SO SI
  DL D1 D2 D3 D4 NK SY EB CN EM SB EC FS GS RS US
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  SP NS a> a: (! a' a? aa // n? DG .  <  (  +  !
  &  )> e> e: !) i' i> i: '? ss e' DO *  )  ;  '>
  -  /  A> A: A! A' A? AA C, N? o! ,  %  _  >  ?
  o/ E' E> E: E! I' I> I: I! u! :  Pd SE '  =  "
  O/ a  b  c  d  e  f  g  h  i  << >> d- y' th +-
  <( j  k  l  m  n  o  p  q  r  -a -o ae ', AE Cu
  My i! s  t  u  v  w  x  y  z  !I ?I D- Y' TH Rg
  Ct Nb Ye .M Co At PI 14 12 34 NO !! '- ': '' *X
  a! A  B  C  D  E  F  G  H  I  -- o> o: BB o' o?
  e! J  K  L  M  N  O  P  Q  R  1S u> u: '! u' y:
  c, -: S  T  U  V  W  X  Y  Z  2S O> O: O! O' O?
  0  1  2  3  4  5  6  7  8  9  3S U> U: U! U' DT

It should say:

  &charset IBM280
  &rem source: IBM NLS RM Vol2 SE09-8002-01, March 1990
  &rem source: IBM Corporate Standard, C-S 3-3220-002
  &alias CP280
  &alias ebcdic-cp-it
  &code 0
  NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
  DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
  __ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
  ?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB
  SP NS a> a: (! a' a? aa // n? DG .  <  (  +  !
  &  )> e> e: !) i' i> i: '? ss e' DO *  )  ;  '>
  -  /  A> A: A! A' A? AA C, N? o! ,  %  _  >  ?
  o/ E' E> E: E! I' I> I: I! u! :  Pd SE '  =  "
  O/ a  b  c  d  e  f  g  h  i  << >> d- y' th +-
  <( j  k  l  m  n  o  p  q  r  -a -o ae ', AE Cu
  My i! s  t  u  v  w  x  y  z  !I ?I D- Y' TH Rg
  Ct Nb Ye .M Co At PI 14 12 34 NO !! '- ': '' *X
  a! A  B  C  D  E  F  G  H  I  -- o> o: BB o' o?
  e! J  K  L  M  N  O  P  Q  R  1S u> u: '! u' y:
  c, -: S  T  U  V  W  X  Y  Z  2S O> O: O! O' O?
  0  1  2  3  4  5  6  7  8  9  3S U> U: U! U' __
  &duplicate 1F __

Notes:

The EBCDIC character sets do not use the ASCII control codes.
Based on [1] the EBCDIC control codes located at hex 00-3F are

NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
__ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB

with __ marking control codes with no ISO 10646 mapping.
The control code at hex 1F can depending on context either mean "Interchange Unit Separator" or "Intermediate Transmission Block" but only the prior has an ISO 10646 mapping (mnemonic US). The "&duplicate 1F __" part marks the alternative character with no available mapping. Note that in EBCDIC the "Delete" character is located at hex 07 while hex FF is "Eight Ones", another character with no ISO 10646 equivalent.

References:
[1]: IBM Corporate Standard, C-S 3-3220-002 (May 1990) -- archived IBM excerpt available at https://web.archive.org/web/20180911044845/https://www-01.ibm.com/software/globalization/cdra/appendix_g1.html

Errata ID: 6063
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip Børgesen
Date Reported: 2020-04-01

Section 5 says:

  &charset IBM284
  &rem source: IBM NLS RM Vol2 SE09-8002-01, March 1990
  &alias CP284
  &alias ebcdic-cp-es
  &code 0
  NU SH SX EX ET EQ AK BL BS HT LF VT FF CR SO SI
  DL D1 D2 D3 D4 NK SY EB CN EM SB EC FS GS RS US
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  SP NS a> a: a! a' a? aa c, BB <( .  <  (  +  !!
  &  e' e> e: e! i' i> i: i! ss )> DO *  )  ;  NO
  -  /  A> A: A! A' A? AA C, Nb n? ,  %  _  >  ?
  o/ E' E> E: E! I' I> I: I! '! :  N? At '  =  "
  O/ a  b  c  d  e  f  g  h  i  << >> d- y' th +-
  DG j  k  l  m  n  o  p  q  r  -a -o ae ', AE Cu
  My ': s  t  u  v  w  x  y  z  !I ?I D- Y' TH Rg
  Ct Pd Ye .M Co SE PI 14 12 34 '> !  '- '? '' *X
  (! A  B  C  D  E  F  G  H  I  -- o> o: o! o' o?
  !) J  K  L  M  N  O  P  Q  R  1S u> u: u! u' y:
  // -: S  T  U  V  W  X  Y  Z  2S O> O: O! O' O?
  0  1  2  3  4  5  6  7  8  9  3S U> U: U! U' DT

It should say:

  &charset IBM284
  &rem source: IBM NLS RM Vol2 SE09-8002-01, March 1990
  &rem source: IBM Corporate Standard, C-S 3-3220-002
  &alias CP284
  &alias ebcdic-cp-es
  &code 0
  NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
  DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
  __ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
  ?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB
  SP NS a> a: a! a' a? aa c, BB <( .  <  (  +  !!
  &  e' e> e: e! i' i> i: i! ss )> DO *  )  ;  NO
  -  /  A> A: A! A' A? AA C, Nb n? ,  %  _  >  ?
  o/ E' E> E: E! I' I> I: I! '! :  N? At '  =  "
  O/ a  b  c  d  e  f  g  h  i  << >> d- y' th +-
  DG j  k  l  m  n  o  p  q  r  -a -o ae ', AE Cu
  My ': s  t  u  v  w  x  y  z  !I ?I D- Y' TH Rg
  Ct Pd Ye .M Co SE PI 14 12 34 '> !  '- '? '' *X
  (! A  B  C  D  E  F  G  H  I  -- o> o: o! o' o?
  !) J  K  L  M  N  O  P  Q  R  1S u> u: u! u' y:
  // -: S  T  U  V  W  X  Y  Z  2S O> O: O! O' O?
  0  1  2  3  4  5  6  7  8  9  3S U> U: U! U' __
  &duplicate 1F __

Notes:

The EBCDIC character sets do not use the ASCII control codes.
Based on [1] the EBCDIC control codes located at hex 00-3F are

NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
__ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB

with __ marking control codes with no ISO 10646 mapping.
The control code at hex 1F can depending on context either mean "Interchange Unit Separator" or "Intermediate Transmission Block" but only the prior has an ISO 10646 mapping (mnemonic US). The "&duplicate 1F __" part marks the alternative character with no available mapping. Note that in EBCDIC the "Delete" character is located at hex 07 while hex FF is "Eight Ones", another character with no ISO 10646 equivalent.

References:
[1]: IBM Corporate Standard, C-S 3-3220-002 (May 1990) -- archived IBM excerpt available at https://web.archive.org/web/20180911044845/https://www-01.ibm.com/software/globalization/cdra/appendix_g1.html

Errata ID: 6064
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip Børgesen
Date Reported: 2020-04-01

Section 5 says:

  &charset IBM285
  &rem source: IBM NLS RM Vol2 SE09-8002-01, March 1990
  &alias CP285
  &alias ebcdic-cp-gb
  &code 0
  NU SH SX EX ET EQ AK BL BS HT LF VT FF CR SO SI
  DL D1 D2 D3 D4 NK SY EB CN EM SB EC FS GS RS US
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  SP NS a> a: a! a' a? aa c, n? DO .  <  (  +  !!
  &  e' e> e: e! i' i> i: i! ss !  Pd *  )  ;  NO
  -  /  A> A: A! A' A? AA C, N? BB ,  %  _  >  ?
  o/ E' E> E: E! I' I> I: I! '! :  Nb At '  =  "
  O/ a  b  c  d  e  f  g  h  i  << >> d- y' th +-
  DG j  k  l  m  n  o  p  q  r  -a -o ae ', AE Cu
  My '? s  t  u  v  w  x  y  z  !I ?I D- Y' TH Rg
  Ct <( Ye .M Co SE PI 14 12 34 '> )> '- ': '' *X
  (! A  B  C  D  E  F  G  H  I  -- o> o: o! o' o?
  !) J  K  L  M  N  O  P  Q  R  1S u> u: u! u' y:
  // -: S  T  U  V  W  X  Y  Z  2S O> O: O! O' O?
  0  1  2  3  4  5  6  7  8  9  3S U> U: U! U' DT

It should say:

  &charset IBM285
  &rem source: IBM NLS RM Vol2 SE09-8002-01, March 1990
  &rem source: IBM Corporate Standard, C-S 3-3220-002
  &alias CP285
  &alias ebcdic-cp-gb
  &code 0
  NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
  DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
  __ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
  ?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB
  SP NS a> a: a! a' a? aa c, n? DO .  <  (  +  !!
  &  e' e> e: e! i' i> i: i! ss !  Pd *  )  ;  NO
  -  /  A> A: A! A' A? AA C, N? BB ,  %  _  >  ?
  o/ E' E> E: E! I' I> I: I! '! :  Nb At '  =  "
  O/ a  b  c  d  e  f  g  h  i  << >> d- y' th +-
  DG j  k  l  m  n  o  p  q  r  -a -o ae ', AE Cu
  My '? s  t  u  v  w  x  y  z  !I ?I D- Y' TH Rg
  Ct <( Ye .M Co SE PI 14 12 34 '> )> '- ': '' *X
  (! A  B  C  D  E  F  G  H  I  -- o> o: o! o' o?
  !) J  K  L  M  N  O  P  Q  R  1S u> u: u! u' y:
  // -: S  T  U  V  W  X  Y  Z  2S O> O: O! O' O?
  0  1  2  3  4  5  6  7  8  9  3S U> U: U! U' __
  &duplicate 1F __

Notes:

The EBCDIC character sets do not use the ASCII control codes.
Based on [1] the EBCDIC control codes located at hex 00-3F are

NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
__ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB

with __ marking control codes with no ISO 10646 mapping.
The control code at hex 1F can depending on context either mean "Interchange Unit Separator" or "Intermediate Transmission Block" but only the prior has an ISO 10646 mapping (mnemonic US). The "&duplicate 1F __" part marks the alternative character with no available mapping. Note that in EBCDIC the "Delete" character is located at hex 07 while hex FF is "Eight Ones", another character with no ISO 10646 equivalent.

References:
[1]: IBM Corporate Standard, C-S 3-3220-002 (May 1990) -- archived IBM excerpt available at https://web.archive.org/web/20180911044845/https://www-01.ibm.com/software/globalization/cdra/appendix_g1.html

Errata ID: 6065
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip Børgesen
Date Reported: 2020-04-01

Section 5 says:

  &charset IBM297
  &rem source: IBM NLS RM Vol2 SE09-8002-01, March 1990
  &alias cp297
  &alias ebcdic-cp-fr
  &code 0
  NU SH SX EX ET EQ AK BL BS HT LF VT FF CR SO SI
  DL D1 D2 D3 D4 NK SY EB CN EM SB EC FS GS RS US
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  SP NS a> a: At a' a? aa // n? DG .  <  (  +  !
  &  (! e> e: !) i' i> i: i! ss SE DO *  )  ;  '>
  -  /  A> A: A! A' A? AA C, N? u! ,  %  _  >  ?
  o/ E' E> E: E! I' I> I: I! My :  Pd a! '  =  "
  O/ a  b  c  d  e  f  g  h  i  << >> d- y' th +-
  <( j  k  l  m  n  o  p  q  r  -a -o ae ', AE Cu
  '! ': s  t  u  v  w  x  y  z  !I ?I D- Y' TH Rg
  Ct Nb Ye .M Co )> PI 14 12 34 NO !! '- '? '' *X
  e' A  B  C  D  E  F  G  H  I  -- o> o: o! o' o?
  e! J  K  L  M  N  O  P  Q  R  1S u> u: BB u' y:
  c, -: S  T  U  V  W  X  Y  Z  2S O> O: O! O' O?
  0  1  2  3  4  5  6  7  8  9  3S U> U: U! U' DT

It should say:

  &charset IBM297
  &rem source: IBM NLS RM Vol2 SE09-8002-01, March 1990
  &rem source: IBM Corporate Standard, C-S 3-3220-002
  &alias cp297
  &alias ebcdic-cp-fr
  &code 0
  NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
  DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
  __ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
  ?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB
  SP NS a> a: At a' a? aa // n? DG .  <  (  +  !
  &  (! e> e: !) i' i> i: i! ss SE DO *  )  ;  '>
  -  /  A> A: A! A' A? AA C, N? u! ,  %  _  >  ?
  o/ E' E> E: E! I' I> I: I! My :  Pd a! '  =  "
  O/ a  b  c  d  e  f  g  h  i  << >> d- y' th +-
  <( j  k  l  m  n  o  p  q  r  -a -o ae ', AE Cu
  '! ': s  t  u  v  w  x  y  z  !I ?I D- Y' TH Rg
  Ct Nb Ye .M Co )> PI 14 12 34 NO !! '- '? '' *X
  e' A  B  C  D  E  F  G  H  I  -- o> o: o! o' o?
  e! J  K  L  M  N  O  P  Q  R  1S u> u: BB u' y:
  c, -: S  T  U  V  W  X  Y  Z  2S O> O: O! O' O?
  0  1  2  3  4  5  6  7  8  9  3S U> U: U! U' __
  &duplicate 1F __

Notes:

The EBCDIC character sets do not use the ASCII control codes.
Based on [1] the EBCDIC control codes located at hex 00-3F are

NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
__ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB

with __ marking control codes with no ISO 10646 mapping.
The control code at hex 1F can depending on context either mean "Interchange Unit Separator" or "Intermediate Transmission Block" but only the prior has an ISO 10646 mapping (mnemonic US). The "&duplicate 1F __" part marks the alternative character with no available mapping. Note that in EBCDIC the "Delete" character is located at hex 07 while hex FF is "Eight Ones", another character with no ISO 10646 equivalent.

References:
[1]: IBM Corporate Standard, C-S 3-3220-002 (May 1990) -- archived IBM excerpt available at https://web.archive.org/web/20180911044845/https://www-01.ibm.com/software/globalization/cdra/appendix_g1.html

Errata ID: 6066
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip Børgesen
Date Reported: 2020-04-01

Section 5 says:

  &charset IBM420
  &rem source: IBM NLS RM Vol2 SE09-8002-01, March 1990
  &rem IBM NLS RM p 11-11
  &alias cp420
  &alias ebcdic-cp-ar1
  &code 0
  NU SH SX EX ET EQ AK BL BS HT LF VT FF CR SO SI
  DL D1 D2 D3 D4 NK SY EB CN EM SB EC FS GS RS US
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  SP  NS  3+  3+; ++  ??  H'  aM  aM. aH  Ct  .   <   (   +   !!
  &   aH. wH  ??  ??  yH  a+  a+. b+  b+, !   DO  *   )   ;   NO
  -   /   tm  t+  t+, tk  tk, g+  g+, hk  BB  ,   %   _   >   ?
  hk, x+  x+, d+  dk  r+  z+  s+  s+, ,+  :   Nb  At  '   =   "
  sn  a   b   c   d   e   f   g   h   i   sn, c+  c+, dd  dd, tj
  zH  j   k   l   m   n   o   p   q   r   e+  e+. e+, e+; i+  i+.
  i+, -:  s   t   u   v   w   x   y   z   i+; f+  f+, q+  q+, k+
  k+, l+  lM- lM. lH- lH. ??  ??  la- la. l+, m+  m+, n+  n+, h+
  ;+  A   B   C   D   E   F   G   H   I   --  h+, ??  h+; ??  w+
  ?+  J   K   L   M   N   O   P   Q   R   j+  j+. y+  y+. y+, 0a
  *X  ??  S   T   U   V   W   X   Y   Z   1a  2a  ??  3a  4a  5a
  0   1   2   3   4   5   6   7   8   9   ??  6a  7a  8a  9a  DT

It should say:

  &charset IBM420
  &rem source: IBM NLS RM Vol2 SE09-8002-01, March 1990
  &rem source: IBM Corporate Standard, C-S 3-3220-002
  &rem IBM NLS RM p 11-11
  &alias cp420
  &alias ebcdic-cp-ar1
  &code 0
  NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
  DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
  __ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
  ?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB
  SP  NS  3+  3+; ++  ??  H'  aM  aM. aH  Ct  .   <   (   +   !!
  &   aH. wH  ??  ??  yH  a+  a+. b+  b+, !   DO  *   )   ;   NO
  -   /   tm  t+  t+, tk  tk, g+  g+, hk  BB  ,   %   _   >   ?
  hk, x+  x+, d+  dk  r+  z+  s+  s+, ,+  :   Nb  At  '   =   "
  sn  a   b   c   d   e   f   g   h   i   sn, c+  c+, dd  dd, tj
  zH  j   k   l   m   n   o   p   q   r   e+  e+. e+, e+; i+  i+.
  i+, -:  s   t   u   v   w   x   y   z   i+; f+  f+, q+  q+, k+
  k+, l+  lM- lM. lH- lH. ??  ??  la- la. l+, m+  m+, n+  n+, h+
  ;+  A   B   C   D   E   F   G   H   I   --  h+, ??  h+; ??  w+
  ?+  J   K   L   M   N   O   P   Q   R   j+  j+. y+  y+. y+, 0a
  *X  ??  S   T   U   V   W   X   Y   Z   1a  2a  ??  3a  4a  5a
  0   1   2   3   4   5   6   7   8   9   ??  6a  7a  8a  9a  __
  &duplicate 1F __

Notes:

The EBCDIC character sets do not use the ASCII control codes.
Based on [1] the EBCDIC control codes located at hex 00-3F are

NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
__ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB

with __ marking control codes with no ISO 10646 mapping.
The control code at hex 1F can depending on context either mean "Interchange Unit Separator" or "Intermediate Transmission Block" but only the prior has an ISO 10646 mapping (mnemonic US). The "&duplicate 1F __" part marks the alternative character with no available mapping. Note that in EBCDIC the "Delete" character is located at hex 07 while hex FF is "Eight Ones", another character with no ISO 10646 equivalent.

References:
[1]: IBM Corporate Standard, C-S 3-3220-002 (May 1990) -- archived IBM excerpt available at https://web.archive.org/web/20180911044845/https://www-01.ibm.com/software/globalization/cdra/appendix_g1.html

Errata ID: 6067
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip Børgesen
Date Reported: 2020-04-01

Section 5 says:

  &charset IBM423
  &rem source: IBM NLS RM Vol2 SE09-8002-01, March 1990
  &alias cp423
  &alias ebcdic-cp-gr
  &code 0
  NU SH SX EX ET EQ AK BL BS HT LF VT FF CR SO SI
  DL D1 D2 D3 D4 NK SY EB CN EM SB EC FS GS RS US
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  SP A* B* G* D* E* Z* Y* H* I* <( .  <  (  +  !
  &  K* L* M* N* C* O* P* R* S* )> DO *  )  ;  '>
  -  /  T* U* F* X* Q* W* ?? ?? ?? ,  %  _  >  ?
  ?? A% E% Y% ?? I% O% U% W% '! :  Pd SE '  =  "
  A: a  b  c  d  e  f  g  h  i  a* b* g* d* e* z*
  O: j  k  l  m  n  o  p  q  r  y* h* i* k* l* m*
  U: ': s  t  u  v  w  x  y  z  n* c* o* p* r* *s
  ?? a% e% y% j* i% o% u% v* w% s* t* u* f* x* q*
  %' y= z= s% je sc c% =' JU A= B= C= D= E= F= G=
  ', A  B  C  D  E  F  G  H  I  ?? w* A> a! a: e>
  '' J  K  L  M  N  O  P  Q  R  +- e' e! e: i> i:
  DG ?? S  T  U  V  W  X  Y  Z  12 o: o> u> u! u:
  0  1  2  3  4  5  6  7  8  9  y: c, C, ?? ?? DT

It should say:

  &charset IBM423
  &rem source: IBM NLS RM Vol2 SE09-8002-01, March 1990
  &rem source: IBM Corporate Standard, C-S 3-3220-002
  &alias cp423
  &alias ebcdic-cp-gr
  &code 0
  NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
  DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
  __ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
  ?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB
  SP A* B* G* D* E* Z* Y* H* I* <( .  <  (  +  !
  &  K* L* M* N* C* O* P* R* S* )> DO *  )  ;  '>
  -  /  T* U* F* X* Q* W* ?? ?? ?? ,  %  _  >  ?
  ?? A% E% Y% ?? I% O% U% W% '! :  Pd SE '  =  "
  A: a  b  c  d  e  f  g  h  i  a* b* g* d* e* z*
  O: j  k  l  m  n  o  p  q  r  y* h* i* k* l* m*
  U: ': s  t  u  v  w  x  y  z  n* c* o* p* r* *s
  ?? a% e% y% j* i% o% u% v* w% s* t* u* f* x* q*
  %' y= z= s% je sc c% =' JU A= B= C= D= E= F= G=
  ', A  B  C  D  E  F  G  H  I  ?? w* A> a! a: e>
  '' J  K  L  M  N  O  P  Q  R  +- e' e! e: i> i:
  DG ?? S  T  U  V  W  X  Y  Z  12 o: o> u> u! u:
  0  1  2  3  4  5  6  7  8  9  y: c, C, ?? ?? __
  &duplicate 1F __

Notes:

The EBCDIC character sets do not use the ASCII control codes.
Based on [1] the EBCDIC control codes located at hex 00-3F are

NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
__ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB

with __ marking control codes with no ISO 10646 mapping.
The control code at hex 1F can depending on context either mean "Interchange Unit Separator" or "Intermediate Transmission Block" but only the prior has an ISO 10646 mapping (mnemonic US). The "&duplicate 1F __" part marks the alternative character with no available mapping. Note that in EBCDIC the "Delete" character is located at hex 07 while hex FF is "Eight Ones", another character with no ISO 10646 equivalent.

References:
[1]: IBM Corporate Standard, C-S 3-3220-002 (May 1990) -- archived IBM excerpt available at https://web.archive.org/web/20180911044845/https://www-01.ibm.com/software/globalization/cdra/appendix_g1.html

Errata ID: 6068
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip Børgesen
Date Reported: 2020-04-01

Section 5 says:

  &charset IBM424
  &rem source: IBM NLS RM Vol2 SE09-8002-01, March 1990
  &alias cp424
  &alias ebcdic-cp-he
  &code 0
  NU SH SX EX ET EQ AK BL BS HT LF VT FF CR SO SI
  DL D1 D2 D3 D4 NK SY EB CN EM SB EC FS GS RS US
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  SP A+ B+ G+ D+ H+ W+ Z+ X+ Tj Ct .  <  (  +  !!
  &  J+ K% K+ L+ M% M+ N% N+ S+ !  DO *  )  ;  NO
  -  /  E+ P% P+ Zj ZJ Q+ R+ Sh BB ,  %  _  >  ?
  ?? T+ ?? ?? NS ?? ?? ?? == '! :  Nb At '  =  "
  ?? a  b  c  d  e  f  g  h  i  << >> ?? ?? ?? ??
  DG j  k  l  m  n  o  p  q  r  ?? ?? ?? ', ?? Cu
  My '? s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? Rg
  '> Pd Ye .M Co SE PI 14 12 34 <( )> '- ': '' *X
  (! A  B  C  D  E  F  G  H  I  -- ?? ?? ?? ?? ??
  !) J  K  L  M  N  O  P  Q  R  1S ?? ?? ?? ?? ??
  // -: S  T  U  V  W  X  Y  Z  2S ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  3S ?? ?? ?? ?? DT

It should say:

  &charset IBM424
  &rem source: IBM NLS RM Vol2 SE09-8002-01, March 1990
  &rem source: IBM Corporate Standard, C-S 3-3220-002
  &alias cp424
  &alias ebcdic-cp-he
  &code 0
  NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
  DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
  __ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
  ?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB
  SP A+ B+ G+ D+ H+ W+ Z+ X+ Tj Ct .  <  (  +  !!
  &  J+ K% K+ L+ M% M+ N% N+ S+ !  DO *  )  ;  NO
  -  /  E+ P% P+ Zj ZJ Q+ R+ Sh BB ,  %  _  >  ?
  ?? T+ ?? ?? NS ?? ?? ?? == '! :  Nb At '  =  "
  ?? a  b  c  d  e  f  g  h  i  << >> ?? ?? ?? ??
  DG j  k  l  m  n  o  p  q  r  ?? ?? ?? ', ?? Cu
  My '? s  t  u  v  w  x  y  z  ?? ?? ?? ?? ?? Rg
  '> Pd Ye .M Co SE PI 14 12 34 <( )> '- ': '' *X
  (! A  B  C  D  E  F  G  H  I  -- ?? ?? ?? ?? ??
  !) J  K  L  M  N  O  P  Q  R  1S ?? ?? ?? ?? ??
  // -: S  T  U  V  W  X  Y  Z  2S ?? ?? ?? ?? ??
  0  1  2  3  4  5  6  7  8  9  3S ?? ?? ?? ?? __
  &duplicate 1F __

Notes:

The EBCDIC character sets do not use the ASCII control codes.
Based on [1] the EBCDIC control codes located at hex 00-3F are

NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
__ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB

with __ marking control codes with no ISO 10646 mapping.
The control code at hex 1F can depending on context either mean "Interchange Unit Separator" or "Intermediate Transmission Block" but only the prior has an ISO 10646 mapping (mnemonic US). The "&duplicate 1F __" part marks the alternative character with no available mapping. Note that in EBCDIC the "Delete" character is located at hex 07 while hex FF is "Eight Ones", another character with no ISO 10646 equivalent.

References:
[1]: IBM Corporate Standard, C-S 3-3220-002 (May 1990) -- archived IBM excerpt available at https://web.archive.org/web/20180911044845/https://www-01.ibm.com/software/globalization/cdra/appendix_g1.html

Errata ID: 6069
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip Børgesen
Date Reported: 2020-04-01

Section 5 says:

  &charset IBM500
  &rem source: IBM NLS RM Vol2 SE09-8002-01, March 1990
  &alias CP500
  &alias ebcdic-cp-be
  &alias ebcdic-cp-ch
  &code 0
  NU SH SX EX ET EQ AK BL BS HT LF VT FF CR SO SI
  DL D1 D2 D3 D4 NK SY EB CN EM SB EC FS GS RS US
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  SP NS a> a: a! a' a? aa c, n? <( .  <  (  +  !
  &  e' e> e: e! i' i> i: i! ss )> DO *  )  ;  '>
  -  /  A> A: A! A' A? AA C, N? BB ,  %  _  >  ?
  o/ E' E> E: E! I' I> I: I! '! :  Nb At '  =  "
  O/ a  b  c  d  e  f  g  h  i  << >> d- y' th +-
  DG j  k  l  m  n  o  p  q  r  -a -o ae ', AE Cu
  My '? s  t  u  v  w  x  y  z  !I ?I D- Y' TH Rg
  Ct Pd Ye .M Co SE PI 14 12 34 NO !! '- ': '' *X
  (! A  B  C  D  E  F  G  H  I  -- o> o: o! o' o?
  !) J  K  L  M  N  O  P  Q  R  1S u> u: u! u' y:
  // -: S  T  U  V  W  X  Y  Z  2S O> O: O! O' O?
  0  1  2  3  4  5  6  7  8  9  3S U> U: U! U' DT

It should say:

  &charset IBM500
  &rem source: IBM NLS RM Vol2 SE09-8002-01, March 1990
  &rem source: IBM Corporate Standard, C-S 3-3220-002
  &alias CP500
  &alias ebcdic-cp-be
  &alias ebcdic-cp-ch
  &code 0
  NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
  DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
  __ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
  ?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB
  SP NS a> a: a! a' a? aa c, n? <( .  <  (  +  !
  &  e' e> e: e! i' i> i: i! ss )> DO *  )  ;  '>
  -  /  A> A: A! A' A? AA C, N? BB ,  %  _  >  ?
  o/ E' E> E: E! I' I> I: I! '! :  Nb At '  =  "
  O/ a  b  c  d  e  f  g  h  i  << >> d- y' th +-
  DG j  k  l  m  n  o  p  q  r  -a -o ae ', AE Cu
  My '? s  t  u  v  w  x  y  z  !I ?I D- Y' TH Rg
  Ct Pd Ye .M Co SE PI 14 12 34 NO !! '- ': '' *X
  (! A  B  C  D  E  F  G  H  I  -- o> o: o! o' o?
  !) J  K  L  M  N  O  P  Q  R  1S u> u: u! u' y:
  // -: S  T  U  V  W  X  Y  Z  2S O> O: O! O' O?
  0  1  2  3  4  5  6  7  8  9  3S U> U: U! U' __
  &duplicate 1F __

Notes:

The EBCDIC character sets do not use the ASCII control codes.
Based on [1] the EBCDIC control codes located at hex 00-3F are

NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
__ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB

with __ marking control codes with no ISO 10646 mapping.
The control code at hex 1F can depending on context either mean "Interchange Unit Separator" or "Intermediate Transmission Block" but only the prior has an ISO 10646 mapping (mnemonic US). The "&duplicate 1F __" part marks the alternative character with no available mapping. Note that in EBCDIC the "Delete" character is located at hex 07 while hex FF is "Eight Ones", another character with no ISO 10646 equivalent.

References:
[1]: IBM Corporate Standard, C-S 3-3220-002 (May 1990) -- archived IBM excerpt available at https://web.archive.org/web/20180911044845/https://www-01.ibm.com/software/globalization/cdra/appendix_g1.html

Errata ID: 6070
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip Børgesen
Date Reported: 2020-04-01

Section 5 says:

  &charset IBM870
  &rem source: IBM NLS RM Vol2 SE09-8002-01, March 1990
  &alias CP870
  &alias ebcdic-cp-roece
  &alias ebcdic-cp-yu
  &code 0
  NU SH SX EX ET EQ AK BL BS HT LF VT FF CR SO SI
  DL D1 D2 D3 D4 NK SY EB CN EM SB EC FS GS RS US
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  SP NS ?? a: ?? a' a( c< c, c' <( .  <  (  +  !
  &  e' ?? e: u0 i' ?? l< l' ss )> DO *  )  ;  '>
  -  /  ?? A: '" A' ?? C< C, C' !! ,  %  _  >  ?
  '< E' ?? E: U0 I' ?? L< L' '! :  Nb At '  =  "
  '( a  b  c  d  e  f  g  h  i  s' n< d/ y' r< ??
  DG j  k  l  m  n  o  p  q  r  l/ n' s< ', '; Cu
  a; '? s  t  u  v  w  x  y  z  S' N< D/ Y' R< ??
  .M A; z. ?? Z. SE PI z< z' Z< Z' N' S< ': '' *X
  (! A  B  C  D  E  F  G  H  I  -- o> o: r' o' o"
  !) J  K  L  M  N  O  P  Q  R  E< u" u: t< u' e<
  // -: S  T  U  V  W  X  Y  Z  d< O> O: R' O' O"
  0  1  2  3  4  5  6  7  8  9  D< U" U: T< U' DT

It should say:

  &charset IBM870
  &rem source: IBM NLS RM Vol2 SE09-8002-01, March 1990
  &rem source: IBM Corporate Standard, C-S 3-3220-002
  &alias CP870
  &alias ebcdic-cp-roece
  &alias ebcdic-cp-yu
  &code 0
  NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
  DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
  __ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
  ?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB
  SP NS ?? a: ?? a' a( c< c, c' <( .  <  (  +  !
  &  e' ?? e: u0 i' ?? l< l' ss )> DO *  )  ;  '>
  -  /  ?? A: '" A' ?? C< C, C' !! ,  %  _  >  ?
  '< E' ?? E: U0 I' ?? L< L' '! :  Nb At '  =  "
  '( a  b  c  d  e  f  g  h  i  s' n< d/ y' r< ??
  DG j  k  l  m  n  o  p  q  r  l/ n' s< ', '; Cu
  a; '? s  t  u  v  w  x  y  z  S' N< D/ Y' R< ??
  .M A; z. ?? Z. SE PI z< z' Z< Z' N' S< ': '' *X
  (! A  B  C  D  E  F  G  H  I  -- o> o: r' o' o"
  !) J  K  L  M  N  O  P  Q  R  E< u" u: t< u' e<
  // -: S  T  U  V  W  X  Y  Z  d< O> O: R' O' O"
  0  1  2  3  4  5  6  7  8  9  D< U" U: T< U' __
  &duplicate 1F __

Notes:

The EBCDIC character sets do not use the ASCII control codes.
Based on [1] the EBCDIC control codes located at hex 00-3F are

NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
__ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB

with __ marking control codes with no ISO 10646 mapping.
The control code at hex 1F can depending on context either mean "Interchange Unit Separator" or "Intermediate Transmission Block" but only the prior has an ISO 10646 mapping (mnemonic US). The "&duplicate 1F __" part marks the alternative character with no available mapping. Note that in EBCDIC the "Delete" character is located at hex 07 while hex FF is "Eight Ones", another character with no ISO 10646 equivalent.

References:
[1]: IBM Corporate Standard, C-S 3-3220-002 (May 1990) -- archived IBM excerpt available at https://web.archive.org/web/20180911044845/https://www-01.ibm.com/software/globalization/cdra/appendix_g1.html

Errata ID: 6071
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip Børgesen
Date Reported: 2020-04-01

Section 5 says:

  &charset IBM871
  &rem source: IBM NLS RM Vol2 SE09-8002-01, March 1990
  &alias CP871
  &alias ebcdic-cp-is
  &code 0
  NU SH SX EX ET EQ AK BL BS HT LF VT FF CR SO SI
  DL D1 D2 D3 D4 NK SY EB CN EM SB EC FS GS RS US
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  SP NS a> a: a! a' a? aa c, n? th .  <  (  +  !
  &  e' e> e: e! i' i> i: i! ss AE DO *  )  ;  O:
  -  /  A> A: A! A' A? AA C, N? BB ,  %  _  >  ?
  o/ E' E> E: E! I' I> I: I! d- :  Nb D- '  =  "
  O/ a  b  c  d  e  f  g  h  i  << >> '! y' (! +-
  DG j  k  l  m  n  o  p  q  r  -a -o !) ', )> Cu
  My o: s  t  u  v  w  x  y  z  !I ?I At Y' <( Rg
  Ct Pd Ye .M Co SE PI 14 12 34 NO !! '- ': // *X
  TH A  B  C  D  E  F  G  H  I  -- o> '? o! o' o?
  ae J  K  L  M  N  O  P  Q  R  1S u> u: u! u' y:
  '' -: S  T  U  V  W  X  Y  Z  2S O> '> O! O' O?
  0  1  2  3  4  5  6  7  8  9  3S U> U: U! U' DT

It should say:

  &charset IBM871
  &rem source: IBM NLS RM Vol2 SE09-8002-01, March 1990
  &rem source: IBM Corporate Standard, C-S 3-3220-002
  &alias CP871
  &alias ebcdic-cp-is
  &code 0
  NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
  DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
  __ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
  ?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB
  SP NS a> a: a! a' a? aa c, n? th .  <  (  +  !
  &  e' e> e: e! i' i> i: i! ss AE DO *  )  ;  O:
  -  /  A> A: A! A' A? AA C, N? BB ,  %  _  >  ?
  o/ E' E> E: E! I' I> I: I! d- :  Nb D- '  =  "
  O/ a  b  c  d  e  f  g  h  i  << >> '! y' (! +-
  DG j  k  l  m  n  o  p  q  r  -a -o !) ', )> Cu
  My o: s  t  u  v  w  x  y  z  !I ?I At Y' <( Rg
  Ct Pd Ye .M Co SE PI 14 12 34 NO !! '- ': // *X
  TH A  B  C  D  E  F  G  H  I  -- o> '? o! o' o?
  ae J  K  L  M  N  O  P  Q  R  1S u> u: u! u' y:
  '' -: S  T  U  V  W  X  Y  Z  2S O> '> O! O' O?
  0  1  2  3  4  5  6  7  8  9  3S U> U: U! U' __
  &duplicate 1F __

Notes:

The EBCDIC character sets do not use the ASCII control codes.
Based on [1] the EBCDIC control codes located at hex 00-3F are

NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
__ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB

with __ marking control codes with no ISO 10646 mapping.
The control code at hex 1F can depending on context either mean "Interchange Unit Separator" or "Intermediate Transmission Block" but only the prior has an ISO 10646 mapping (mnemonic US). The "&duplicate 1F __" part marks the alternative character with no available mapping. Note that in EBCDIC the "Delete" character is located at hex 07 while hex FF is "Eight Ones", another character with no ISO 10646 equivalent.

References:
[1]: IBM Corporate Standard, C-S 3-3220-002 (May 1990) -- archived IBM excerpt available at https://web.archive.org/web/20180911044845/https://www-01.ibm.com/software/globalization/cdra/appendix_g1.html

Errata ID: 6072
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip Børgesen
Date Reported: 2020-04-01

Section 5 says:

  &charset IBM880
  &rem source: IBM NLS RM Vol2 SE09-8002-01, March 1990
  &alias cp880
  &alias EBCDIC-Cyrillic
  &code 0
  NU SH SX EX ET EQ AK BL BS HT LF VT FF CR SO SI
  DL D1 D2 D3 D4 NK SY EB CN EM SB EC FS GS RS US
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  SP ?? d% g% io ?? ds ii yi j% <( .  <  (  +  !
  &  lj nj ts kj ?? dz =" N0 D% )> DO *  )  ;  '>
  -  /  G% IO ?? DS II YI J% LJ BB ,  %  _  >  ?
  NJ Ts KJ ?? ?? DZ ju a= b= ?? :  Nb At '  =  "
  c= a  b  c  d  e  f  g  h  i  d= e= f= g= h= i=
  j= j  k  l  m  n  o  p  q  r  k= l= m= n= o= p=
  ja ?? s  t  u  v  w  x  y  z  r= s= t= u= z% v=
  %' y= z= s% je sc c% =' JU A= B= C= D= E= F= G=
  ?? A  B  C  D  E  F  G  H  I  H= I= J= K= L= M=
  ?? J  K  L  M  N  O  P  Q  R  N= O= P= JA R= S=
  // Cu S  T  U  V  W  X  Y  Z  T= U= Z% V= %" Y=
  0  1  2  3  4  5  6  7  8  9  Z= S% JE Sc C% DT

It should say:

  &charset IBM880
  &rem source: IBM NLS RM Vol2 SE09-8002-01, March 1990
  &rem source: IBM Corporate Standard, C-S 3-3220-002
  &alias cp880
  &alias EBCDIC-Cyrillic
  &code 0
  NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
  DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
  __ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
  ?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB
  SP ?? d% g% io ?? ds ii yi j% <( .  <  (  +  !
  &  lj nj ts kj ?? dz =" N0 D% )> DO *  )  ;  '>
  -  /  G% IO ?? DS II YI J% LJ BB ,  %  _  >  ?
  NJ Ts KJ ?? ?? DZ ju a= b= ?? :  Nb At '  =  "
  c= a  b  c  d  e  f  g  h  i  d= e= f= g= h= i=
  j= j  k  l  m  n  o  p  q  r  k= l= m= n= o= p=
  ja ?? s  t  u  v  w  x  y  z  r= s= t= u= z% v=
  %' y= z= s% je sc c% =' JU A= B= C= D= E= F= G=
  ?? A  B  C  D  E  F  G  H  I  H= I= J= K= L= M=
  ?? J  K  L  M  N  O  P  Q  R  N= O= P= JA R= S=
  // Cu S  T  U  V  W  X  Y  Z  T= U= Z% V= %" Y=
  0  1  2  3  4  5  6  7  8  9  Z= S% JE Sc C% __
  &duplicate 1F __

Notes:

The EBCDIC character sets do not use the ASCII control codes.
Based on [1] the EBCDIC control codes located at hex 00-3F are

NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
__ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB

with __ marking control codes with no ISO 10646 mapping.
The control code at hex 1F can depending on context either mean "Interchange Unit Separator" or "Intermediate Transmission Block" but only the prior has an ISO 10646 mapping (mnemonic US). The "&duplicate 1F __" part marks the alternative character with no available mapping. Note that in EBCDIC the "Delete" character is located at hex 07 while hex FF is "Eight Ones", another character with no ISO 10646 equivalent.

References:
[1]: IBM Corporate Standard, C-S 3-3220-002 (May 1990) -- archived IBM excerpt available at https://web.archive.org/web/20180911044845/https://www-01.ibm.com/software/globalization/cdra/appendix_g1.html

Errata ID: 6073
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip Børgesen
Date Reported: 2020-04-01

Section 5 says:

  &charset IBM918
  &rem source: IBM NLS RM Vol2 SE09-8002-01, March 1990
  &alias CP918
  &alias ebcdic-cp-ar2
  &code 0
  NU SH SX EX ET EQ AK BL BS HT LF VT FF CR SO SI
  DL D1 D2 D3 D4 NK SY EB CN EM SB EC FS GS RS US
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  SP  NS  ,+  ;+  ?+  aH  a+  a+. ??  b+  <(  .   <   (   +   !
  &   b+, p+  ??  tm  t+  t+, ??  ??  tk  )>  DO  *   )   ;   '>
  -   /   tk, g+  g+, ??  ??  hk  hk, x+  '!  ,   %   _   >   ?
  0a  1a  2a  3a  4a  5a  6a  7a  8a  9a  :   Nb  At  '   =   "
  x+, a   b   c   d   e   f   g   h   i   d+  ??  dk  r+  ??  z+
  ??  j   k   l   m   n   o   p   q   r   s+  s+, sn  sn, c+  c+,
  dd  '?  s   t   u   v   w   x   y   z   dd, tj  zH  e+  e+. e+,
  e+; i+  i+. i+, i+; f+  f+, q+  q+, k+  k+, !!  ??  ??  l+  l+.
  (!  A   B   C   D   E   F   G   H   I   --  ??  m+  m+, ??  n+
  !)  J   K   L   M   N   O   P   Q   R   n+, ??  w+  ??  ??  ??
  //  ??  S   T   U   V   W   X   Y   Z   H'  ??  ??  ??  ??  ??
  0   1   2   3   4   5   6   7   8   9   ??  ??  ??  3+  3+; DT

It should say:

  &charset IBM918
  &rem source: IBM NLS RM Vol2 SE09-8002-01, March 1990
  &rem source: IBM Corporate Standard, C-S 3-3220-002
  &alias CP918
  &alias ebcdic-cp-ar2
  &code 0
  NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
  DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
  __ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
  ?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB
  SP  NS  ,+  ;+  ?+  aH  a+  a+. ??  b+  <(  .   <   (   +   !
  &   b+, p+  ??  tm  t+  t+, ??  ??  tk  )>  DO  *   )   ;   '>
  -   /   tk, g+  g+, ??  ??  hk  hk, x+  '!  ,   %   _   >   ?
  0a  1a  2a  3a  4a  5a  6a  7a  8a  9a  :   Nb  At  '   =   "
  x+, a   b   c   d   e   f   g   h   i   d+  ??  dk  r+  ??  z+
  ??  j   k   l   m   n   o   p   q   r   s+  s+, sn  sn, c+  c+,
  dd  '?  s   t   u   v   w   x   y   z   dd, tj  zH  e+  e+. e+,
  e+; i+  i+. i+, i+; f+  f+, q+  q+, k+  k+, !!  ??  ??  l+  l+.
  (!  A   B   C   D   E   F   G   H   I   --  ??  m+  m+, ??  n+
  !)  J   K   L   M   N   O   P   Q   R   n+, ??  w+  ??  ??  ??
  //  ??  S   T   U   V   W   X   Y   Z   H'  ??  ??  ??  ??  ??
  0   1   2   3   4   5   6   7   8   9   ??  ??  ??  3+  3+; __
  &duplicate 1F __

Notes:

The EBCDIC character sets do not use the ASCII control codes.
Based on [1] the EBCDIC control codes located at hex 00-3F are

NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
__ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB

with __ marking control codes with no ISO 10646 mapping.
The control code at hex 1F can depending on context either mean "Interchange Unit Separator" or "Intermediate Transmission Block" but only the prior has an ISO 10646 mapping (mnemonic US). The "&duplicate 1F __" part marks the alternative character with no available mapping. Note that in EBCDIC the "Delete" character is located at hex 07 while hex FF is "Eight Ones", another character with no ISO 10646 equivalent.

References:
[1]: IBM Corporate Standard, C-S 3-3220-002 (May 1990) -- archived IBM excerpt available at https://web.archive.org/web/20180911044845/https://www-01.ibm.com/software/globalization/cdra/appendix_g1.html

RFC 1350, "The TFTP Protocol (Revision 2)", July 1992

Note: This RFC has been updated by RFC 1782, RFC 1783, RFC 1784, RFC 1785, RFC 2347, RFC 2348, RFC 2349

Source of RFC: Legacy
Area Assignment: app

Errata ID: 7167
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Christophe Deleuze
Date Reported: 2022-10-15

Section 6 says:

   The end of a transfer is marked by a DATA packet that contains
   between 0 and 511 bytes of data (i.e., Datagram length < 516).

It should say:

   The end of a transfer is marked by a DATA packet that contains
   between 0 and 511 bytes of data (i.e., Datagram length < 524).

Notes:

After careful reading it seems clear to me that "Datagram" here refers to the UDP datagram.

"Datagram" is used to refer to UDP in several places (section 1: "the Internet User Datagram protocol (UDP or Datagram)", section 3: "Since Datagram is implemented", "the Datagram layer", Figure 3.1, Figure "Order of headers" at beginning of Appendix).

UDP header + TFTP header + 512 bytes of data is 8+4+512 = 524.

Note this errata conflicts with errata #4971

RFC 1459, "Internet Relay Chat Protocol", May 1993

Note: This RFC has been updated by RFC 2810, RFC 2811, RFC 2812, RFC 2813, RFC 7194

Source of RFC: Legacy
Area Assignment: app

Errata ID: 7029
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: wizzwizz4
Date Reported: 2022-07-19

Section 4.2.3.2 says:

:MODE WiZ -w                    ; turns reception of WALLOPS messages
                                off for WiZ.

It should say:

MODE WiZ -w                     ; turns reception of WALLOPS messages
                                off for WiZ.

Notes:

:MODE WiZ -w is a WiZ message from MODE, but WiZ is not an IRC command.

RFC 1557, "Korean Character Encoding for Internet Messages", December 1993

Source of RFC: Legacy

Errata ID: 5482
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Occil
Date Reported: 2018-08-27

Section Formal Syn. says:

   segment         = SO 1*(one-of-94 one-of-94 SI

It should say:

   segment         = SO 1*(one-of-94 one-of-94) SI

Notes:

Missing parenthesis in ABNF

RFC 1624, "Computation of the Internet Checksum via Incremental Update", May 1994

Source of RFC: Legacy
Area Assignment: art

Errata ID: 4782
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ihsan Ulla Sharief
Date Reported: 2016-08-18

Section 3 says:

   The problem is avoided by not assuming this property.  The correct
   equation is given below:

          HC' = ~(C + (-m) + m')    --    [Eqn. 3]
              = ~(~HC + ~m + m')

It should say:

   The problem is avoided by not assuming this property.  The correct
   equation is given below:

          HC' = ~(C + (-m) + m')    --    [Eqn. 3]
              = ~(~HC + ~m + m')

Notes:

The RFC is for computing incremental checksum and ensuring the computed checksum does not result in 0xFFFF (representing -0). However, when in cases where the original value (m) has not changed, and original header checksum (HC) is 0, it will change the fianl checksum value to 0xFFFF (against the intent of this RFC).

Example:
m = 0x5555
~m = 0xAAAA
m' = 0x5555
Checksum (HC) = 0x0000
Checksum compliment (~HC) = 0xFFFF
incremental checksum = ~(~HC + ~m + m') ~(0xFFFF + 0xAAAA + 0x5555) = ~(0x0000) = 0xFFFF

Solution:
Need to explicitly mention that the incremental checksum computation should be done only when there is change in value (ie, m != m').

Errata ID: 5864
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: J.A. Bezemer
Date Reported: 2019-09-25

Section 3 says:

(end of section 3 Discussion)

It should say:

(Add text at end of section 3 Discussion:)

Where "+" denotes 1's complement addition, in which carry bits are added
to the low-order bits of the sum. For machines employing e.g. 32-bit
arithmetic, the 1's complement addition of three 16-bit words A and B
and C is accomplished as follows:

        sum = A + B + C
        while (sum > 0xFFFF) {
            sum = (sum & 0xFFFF) + (sum >> 16)
        }

Notes:

The existing Errata ID: 4782 does not appear to correctly implement 1's complement addition.

Its example should read as follows:

~(~HC + ~m + m')
~(~0x0000 + ~0x5555 + 0x5555)
~(0xFFFF + 0xAAAA + 0x5555)
~(0x1FFFE) -- 32bit
~(0xFFFE + 0x1) -- carry foldaround
~(0xFFFF)
0x0000

A different example showing multiple carry foldaround is replacing a 0x5555 value by 0x5556 where the original header checksum was 0x0000:

~(~HC + ~m + m')
~(~0x0000 + ~0x5555 + 0x5556)
~(0xFFFF + 0xAAAA + 0x5556)
~(0x1FFFF) -- 32bit
~(0xFFFF + 0x1) -- carry foldaround
~(0x10000) -- 32bit
~(0x0000 + 0x1) -- carry foldaround
~(0x0001)
0xFFFE

Errata ID: 5865
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: J.A. Bezemer
Date Reported: 2019-09-25

Section 3 says:

(end of section 3 Discussion)

It should say:

(Add text after end of section 3 Discussion:)

3.1 Considerations for larger-bitsize machines

In above equations, "+" denotes 1's complement addition, in which any
high-order carry bits are added to the low-order bits of the sum, when
executed in 16-bit arithmetic.

When implementing on machines with larger bitsize words, the 1's complement
addition can be accomplished by explicity folding back the carry bits.
For this to work, all negation operations must be limited to the relevant
16 bits only, for example by means of exclusive-or by 0xFFFF. The following
routine can be used:

        HCnew = (HCorig xor 0xFFFF) + (valueorig xor 0xFFFF) + valuenew
        while (HCnew > 0xFFFF) {
                HCnew = (HCnew & 0xFFFF) + (HCnew >> 16)
        }
        HCnew = (HCnew xor 0xFFFF)

where valueorig and valuenew contain the original and new 16-bit (aligned)
payload values, and HCorig and HCnew are the 16-bit header checksum values,
all as least-significant 16 bits inside a larger-bitsize word using
corresponding arithmetic. As long as the bitsize is large enough that the
summations do not overflow, no negative values will be generated and any
binary arithmetic can be used.

Notes:

This updates the previous Errata ID: 5864 by including details on the bit-limited negation, which was probably a(nother) cause of the failing result in Errata ID: 4782.

RFC 1818, "Best Current Practices", August 1995

Source of RFC: Legacy
Area Assignment: gen

Errata ID: 3755
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dale Worley
Date Reported: 2013-10-16

Section header says:

[Existing header does not contain "Updates".]

It should say:

Updates: 1796

Notes:

RFC 1796 defines the "status" datum of RFCs. The "category" datum is similar, except that "Draft Standard", "Proposed Standard", and "Internet Standard" statuses are merged in the "Standards Track" category.

RFC 1818 introduces the "Best Current Practice" status/category, but its metadata does not state that it updates RFC 1796 and consequently RFC 1796's metadata does not state that it is updated by RFC 1818.

This lack of pointers shows up in rfc-index.txt, making it difficult to track down the current list of categories/statuses.

RFC 1912, "Common DNS Operational and Configuration Errors", February 1996

Source of RFC: Legacy

Errata ID: 5381
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jonathan Teague
Date Reported: 2018-06-06
Edited by: Warren Kumari (Ops AD)
Date Edited: 2018-06-06

Section 2.4 says:

A CNAME record is not allowed to coexist with any other data.  In
   other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you
   can't also have an MX record for suzy.podunk.edu, or an A record, or
   even a TXT record.

It should say:

A CNAME record is not allowed to coexist with any other data.  In
   other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you
   can't also have an MX record for suzy.podunk.xx, or an A record, or
   even a TXT record.

Notes:

The .edu is a typo and should be corrected to .xx

RFC 1951, "DEFLATE Compressed Data Format Specification version 1.3", May 1996

Source of RFC: Legacy

Errata ID: 7764
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Hiroki Kobayashi
Date Reported: 2024-01-15

Section 3.2.5 says:

The extra bits should be interpreted as a machine integer 
stored with the most-significant bit first, e.g., bits 1110 
represent the value 14.

It should say:

The extra bits should be interpreted as a machine integer 
stored with the least-significant bit first, e.g., bits 0111 
represent the value 14.

Notes:

In tools like infgen, unlike huffman codes which are reversed after read (https://github.com/madler/infgen/blob/2d2300507d24b398dfc7482f3429cc0061726c8b/infgen.c#L893-L901), extra bits are read as-is (in the LSB-first order) and never get reversed: https://github.com/madler/infgen/blob/2d2300507d24b398dfc7482f3429cc0061726c8b/infgen.c#L1038

RFC 2046, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", November 1996

Note: This RFC has been updated by RFC 2646, RFC 3798, RFC 5147, RFC 6657, RFC 8098

Source of RFC: 822ext (app)

Errata ID: 6776
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Brian Antos
Date Reported: 2021-12-05

Section 5.1.1 says:

NOTE:  The CRLF preceding the boundary delimiter line is conceptually
   attached to the boundary so that it is possible to have a part that
   does not end with a CRLF (line  break).  Body parts that must be
   considered to end with line breaks, therefore, must have two CRLFs
   preceding the boundary delimiter line, the first of which is part of
   the preceding body part, and the second of which is part of the
   encapsulation boundary.

It should say:

NOTE:  The CRLF preceding the boundary delimiter line is conceptually
   attached to the boundary so that it is possible to have a part that
   does not end with a CRLF (line  break).  Body parts that must be
   considered to end with line breaks, therefore, must have two CRLFs
   preceding the boundary delimiter line, the first of which is part of
   the preceding body part, and the second of which is part of the
   encapsulation boundary.

The requirement that the encapsulation boundary begins  with
a  CRLF  implies  that  the  body of a multipart entity must
itself begin with a CRLF before the first encapsulation line
--  that  is, if the "preamble" area is not used, the entity
headers must be followed by TWO CRLFs.  This is  indeed  how
such  entities  should be composed.  A tolerant mail reading
program, however, may interpret a  body  of  type  multipart
that  begins  with  an encapsulation line NOT initiated by a
CRLF  as  also  being  an  encapsulation  boundary,  but   a
compliant  mail  sending  program  must  not  generate  such
entities.

Notes:

Recommend re-introducing the wording from the original RFC (1341) regarding preceding CRLF and the first delimiter line. Current RFC is ambiguous about handling the initial line without it.

Errata ID: 6800
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Daniel Shahaf
Date Reported: 2021-12-27

Section 5.1.4 says:

                                    In the case where one of the
   alternatives is itself of type "multipart" and contains unrecognized
   sub-parts, the user agent may choose either to show that alternative,
   an earlier alternative, or both.

It should say:

                                    In the case where one of the
   alternatives is itself of type "multipart" and contains unrecognized
   sub-parts, the user agent may choose to either show that alternative,
   show an earlier alternative, or let the user choose which alternative
   to show.

Notes:

The quoted sentence conflicts with the following sentence later in the same section:

What is most critical, however, is that the user not
automatically be shown multiple versions of the same data. Either
the user should be shown the last recognized version or should be
given the choice.

I assume the correction should be as proposed, but other options are conceivable.

RFC 2131, "Dynamic Host Configuration Protocol", March 1997

Note: This RFC has been updated by RFC 3396, RFC 4361, RFC 5494, RFC 6842

Source of RFC: dhc (int)

Errata ID: 5100
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Fan Wei
Date Reported: 2017-08-29

Section 4.1 says:

Normally, DHCP servers and BOOTP relay agents attempt to deliver
DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using
uicast delivery.

It should say:

Normally, DHCP servers and BOOTP relay agents attempt to deliver
DHCPOFFER, DHCPACK messages directly to the client using
unicast delivery.

Notes:

According to prior part description in section 4.1: "In all cases, when ’giaddr’ is zero, the server broadcasts any DHCPNAK messages to 0xffffffff.", the DHCP server should not send DHCPNAK in unicast to client unless 'giaddr' is not zero.

Errata ID: 7776
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Imrane
Date Reported: 2024-01-23

Section 4.3.1 says:

Client identifier         MUST NOT     MUST NOT           MAY

It should say:

Client identifier         MUST NOT     MUST NOT           MUST NOT

Notes:

In the "Options" list in Table 3 ("Fields and options used by DHCP server"), the "Client identifier" option has "MUST NOT" for both DHCPOFFER and DHCPACK; however, for DHCPNAK, it has "MAY".

"Client identifier" should be a "MUST NOT" for DHCPNAK as well.

It seems that the field should only be used by a client and never by a server, and if that's true for the OFFER and ACK, then it should be even more correct for the NAK.

"Vendor class identifier" has a MAY for all three messages, so maybe it was a typo in the previous option because of the repetitive input in the next one.

RFC 2183, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", August 1997

Note: This RFC has been updated by RFC 2184, RFC 2231

Source of RFC: Legacy

Errata ID: 5330
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Daniel Beardsmore
Date Reported: 2018-04-20

Section 2 says:

   NOTE ON PARAMETER VALUE LENGHTS: A short (length <= 78 characters)
   parameter value containing only non-`tspecials' characters SHOULD be
   represented as a single `token'.  A short parameter value containing
   only ASCII characters, but including `tspecials' characters, SHOULD
   be represented as `quoted-string'.  Parameter values longer than 78
   characters, or which contain non-ASCII characters, MUST be encoded as
   specified in [RFC 2184].

It should say:

   NOTE ON PARAMETER VALUE LENGTHS: A short (length <= 78 characters)
   parameter value formed solely from characters valid for a `token'
   SHOULD be represented as a single `token', and not as a
   `quoted-string'.  Parameter values longer than 78 characters, or
   which contain non-ASCII characters, MUST be encoded as specified in
   [RFC 2184].

Notes:

The RFC seems to assume that token = ASCII - tspecials. Token in fact is defined more strictly: token := 1*<any (US-ASCII) CHAR except SPACE, CTLs, or tspecials>.

Consequently, a value with spaces (such as "Some file.txt"), which is a value without any tspecials, is expected to be recorded as a token, when in fact this is impossible. The same applies to CTLs.

I've written the corrected text according to the apparent intent, to avoid quotes around the value when they are unnecessary. You may wish to revise the correction for clarity or to better suit the intent of this restriction.

RFC 2231, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", November 1997

Source of RFC: Legacy

Errata ID: 5701
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Paul Freeman
Date Reported: 2019-04-19

Section 7 says:

regular-parameter-name := attribute [section]

It should say:

regular-parameter-name := attribute

Notes:

It seems to me that there is no need for a [section] value to be appended to a regular-parameter-name, and that the existing rule that allows for this violates the intent of the text in Section 3 that states "The asterisk character ("*") followed by a decimal count is employed to indicate that multiple parameters are being used to encapsulate a single parameter value". With the existing rule, it is unclear how to treat the [section] value in this case. (e.g., Is it to be considered as part of the attribute name, or is it to be ignored?)

RFC 2324, "Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)", April 1998

Note: This RFC has been updated by RFC 7168

Source of RFC: INDEPENDENT

Errata ID: 7570
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Hugo Heger
Date Reported: 2023-07-22

Section 3 says:

coffee-scheme = ( "koffie"                   ; Afrikaans, Dutch
                | "q%C3%A6hv%C3%A6"          ; Azerbaijani
                | "%D9%82%D9%87%D9%88%D8%A9" ; Arabic
                | "akeita"                   ; Basque
                | "koffee"                   ; Bengali
                | "kahva"                    ; Bosnian
                | "kafe"                     ; Bulgarian, Czech
                | "caf%C3%E8"                ; Catalan, French, Galician
                | "%E5%92%96%E5%95%A1"       ; Chinese
                | "kava"                     ; Croatian
                | "k%C3%A1va                 ; Czech
                | "kaffe"                    ; Danish, Norwegian, Swedish
                | "coffee"                   ; English
                | "kafo"                     ; Esperanto
                | "kohv"                     ; Estonian
                | "kahvi"                    ; Finnish
                | "%4Baffee"                 ; German
                | "%CE%BA%CE%B1%CF%86%CE%AD" ; Greek
                | "%E0%A4%95%E0%A5%8C%E0%A4%AB%E0%A5%80" ; Hindi
                | "caff%C3%A8"               ; Italian
                | "%E3%82%B3%E3%83%BC%E3%83%92%E3%83%BC" ; Japanese
                | "%EC%BB%A4%ED%94%BC"       ; Korean
                | "%D0%BA%D0%BE%D1%84%D0%B5" ; Russian
                | "%E0%B8%81%E0%B8%B2%E0%B9%81%E0%B8%9F" ; Thai
                )

It should say:

coffee-scheme = ( "koffie"                               ; Afrikaans, Dutch
                | "q%C3%A6hv%C3%A6"                      ; Azerbaijani
                | "%D9%82%D9%87%D9%88%D8%A9"             ; Arabic
                | "akeita"                               ; Basque
                | "koffee"                               ; Bengali
                | "kahva"                                ; Bosnian
                | "kafe"                                 ; Bulgarian, Czech
                | "caf%C3%E8"                            ; Catalan, French, Galician
                | "%E5%92%96%E5%95%A1"                   ; Chinese
                | "kava"                                 ; Croatian
                | "k%C3%A1va                             ; Czech
                | "kaffe"                                ; Danish, Norwegian, Swedish
                | "coffee"                               ; English
                | "kafo"                                 ; Esperanto
                | "kohv"                                 ; Estonian
                | "kahvi"                                ; Finnish
                | "%4Baffee"                             ; German
                | "%CE%BA%CE%B1%CF%86%CE%AD"             ; Greek
                | "%E0%A4%95%E0%A5%8C%E0%A4%AB%E0%A5%80" ; Hindi
                | "caff%C3%A8"                           ; Italian
                | "%E3%82%B3%E3%83%BC%E3%83%92%E3%83%BC" ; Japanese
                | "%EC%BB%A4%ED%94%BC"                   ; Korean
                | "caf%C3%A9"                            ; Portuguese
                | "%D0%BA%D0%BE%D1%84%D0%B5"             ; Russian
                | "%E0%B8%81%E0%B8%B2%E0%B9%81%E0%B8%9F" ; Thai
                )

Notes:

Added missing Portuguese URI ("café") in coffe-scheme (techinical);
Fix mixed indentation with spaces (editorial);
Depends Editorial Errata ID 7293;

Errata ID: 7293
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Cristian Antonuccio
Date Reported: 2022-12-29

Section 3 says:

coffee-scheme = ( "koffie"                      ; Afrikaans, Dutch
                  | "q%C3%A6hv%C3%A6"          ; Azerbaijani
                  | "%D9%82%D9%87%D9%88%D8%A9" ; Arabic
               | "akeita"                   ; Basque
               | "koffee"                   ; Bengali
               | "kahva"                    ; Bosnian
               | "kafe"                     ; Bulgarian, Czech
               | "caf%C3%E8"                ; Catalan, French, Galician
                  | "%E5%92%96%E5%95%A1"       ; Chinese
                  | "kava"                     ; Croatian
               | "k%C3%A1va                 ; Czech
               | "kaffe"                    ; Danish, Norwegian, Swedish
               | "coffee"                   ; English
               | "kafo"                     ; Esperanto
                  | "kohv"                     ; Estonian
               | "kahvi"                    ; Finnish
               | "%4Baffee"                 ; German
               | "%CE%BA%CE%B1%CF%86%CE%AD" ; Greek
               | "%E0%A4%95%E0%A5%8C%E0%A4%AB%E0%A5%80" ; Hindi
               | "%E3%82%B3%E3%83%BC%E3%83%92%E3%83%BC" ; Japanese
               | "%EC%BB%A4%ED%94%BC"       ; Korean
               | "%D0%BA%D0%BE%D1%84%D0%B5" ; Russian
               | "%E0%B8%81%E0%B8%B2%E0%B9%81%E0%B8%9F" ; Thai
               )

It should say:

coffee-scheme = ( "koffie"                   ; Afrikaans, Dutch
                | "q%C3%A6hv%C3%A6"          ; Azerbaijani
                | "%D9%82%D9%87%D9%88%D8%A9" ; Arabic
                | "akeita"                   ; Basque
                | "koffee"                   ; Bengali
                | "kahva"                    ; Bosnian
                | "kafe"                     ; Bulgarian, Czech
                | "caf%C3%E8"                ; Catalan, French, Galician
                | "%E5%92%96%E5%95%A1"       ; Chinese
                | "kava"                     ; Croatian
                | "k%C3%A1va                 ; Czech
                | "kaffe"                    ; Danish, Norwegian, Swedish
                | "coffee"                   ; English
                | "kafo"                     ; Esperanto
                | "kohv"                     ; Estonian
                | "kahvi"                    ; Finnish
                | "%4Baffee"                 ; German
                | "%CE%BA%CE%B1%CF%86%CE%AD" ; Greek
                | "%E0%A4%95%E0%A5%8C%E0%A4%AB%E0%A5%80" ; Hindi
                | "caff%C3%A8"               ; Italian
                | "%E3%82%B3%E3%83%BC%E3%83%92%E3%83%BC" ; Japanese
                | "%EC%BB%A4%ED%94%BC"       ; Korean
                | "%D0%BA%D0%BE%D1%84%D0%B5" ; Russian
                | "%E0%B8%81%E0%B8%B2%E0%B9%81%E0%B8%9F" ; Thai
                )

Notes:

Added missing Italian URI "caffè".
Fixed indentation with spaces.
Source for spelling: https://www.treccani.it/vocabolario/caffe/

RFC 2328, "OSPF Version 2", April 1998

Note: This RFC has been updated by RFC 5709, RFC 6549, RFC 6845, RFC 6860, RFC 7474, RFC 8042, RFC 9355, RFC 9454

Source of RFC: ospf (rtg)

Errata ID: 7850
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Lindem
Date Reported: 2024-03-15

Section 10.7/A.3.5 says:

Section 10.7

        Each LSA specified in the Link State Request packet should be
        located in the router's database, and copied into Link State
        Update packets for transmission to the neighbor.  These LSAs
        should NOT be placed on the Link state retransmission list for
        the neighbor.  If an LSA cannot be found in the database,
        something has gone wrong with the Database Exchange process, and
        neighbor event BadLSReq should be generated.
 
Section A.3.5 

    Link State Update packets are multicast on those physical networks
    that support multicast/broadcast.  In order to make the flooding
    procedure reliable, flooded LSAs are acknowledged in Link State
    Acknowledgment packets.  If retransmission of certain LSAs is
    necessary, the retransmitted LSAs are always sent directly to the
    neighbor.  For more information on the reliable flooding of LSAs,
    consult Section 13.

It should say:

Section 10.7
        
        Each LSA specified in the Link State Request packet should be
        located in the router's database, and copied into Link State
        Update packets for transmission directly to the neighbor, 
        i.e., unicast on all interface types except point-to-point
        interfaces where all OSPF packets are sent to the address
        AllSPFRouters.  These LSAs should NOT be placed on the Link
        state retransmission list for the neighbor.  If an LSA cannot
        be found in the database, something has gone wrong with the
        Database Exchange process, and neighbor event BadLSReq should
        be generated.

Section A.3.5 
    
    Link State Update packets are multicast on those physical networks
    that support multicast/broadcast.  In order to make the flooding
    procedure reliable, flooded LSAs are acknowledged in Link State
    Acknowledgment packets.  If retransmission of certain LSAs is
    necessary, the retransmitted LSAs are always sent directly to the
    neighbor.  For more information on the reliable flooding of LSAs,
    consult Section 13. Link State Update packets are also sent
    directly to the neighbor in response to Link State Request
    packets as specified in Section 10.7.
   

Notes:

Clarify that OSPF Link State Updates sent in response to OSPF Link Requests should be unicast.

Errata ID: 7851
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Acee Lindem
Date Reported: 2024-03-15

Section 8.1 says:

        Retransmissions of Link State Update packets are ALWAYS sent
        directly to the neighbor. On multi-access networks, this means
        that retransmissions should be sent to the neighbor's IP
        address.

       

It should say:

        Retransmissions of Link State Update packets and Link State
        Update packets sent in response to Link State Request packets
        are ALWAYS sent directly to the neighbor. On multi-access
        networks, this means that retransmissions should be sent to
        the neighbor's IP address.

       

Notes:

One more place requiring clarification with respect to the Link State Update packets sent in response to Link State Request packets.

RFC 2361, "WAVE and AVI Codec Registries", June 1998

Source of RFC: Legacy
Area Assignment: rai

Errata ID: 5122
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: David Russo
Date Reported: 2017-09-24

Section Appendix A says:

WAVE form Registration Number (hex):    0x00111

It should say:

WAVE form Registration Number (hex):    0x0111

Notes:

The registration number can be no more than four hexadecimal places (i.e. two bytes) long, according to WAVE format specifications.

Errata ID: 5123
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: David Russo
Date Reported: 2017-09-24

Section Appendix A says:

WAVE form wFormatTag ID:        WAVE_FORMAT_ CREATIVE_FASTSPEECH10

It should say:

WAVE form wFormatTag ID:        WAVE_FORMAT_CREATIVE_FASTSPEECH10

Errata ID: 5126
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: David Russo
Date Reported: 2017-09-24

Section Appendix A says:

Codec ID in the IANA Namespace:         audio/vnd.wave;codec=1401
WAVE form wFormatTag ID:                WAVE_FORMAT_ISIAUDIO

It should say:

Codec ID in the IANA Namespace:         audio/vnd.wave;codec=1401
WAVE form wFormatTag ID:                WAVE_FORMAT_ISIAUDIO_2

Notes:

Codec 1401 has an ID of "WAVE_FORMAT_ISIAUDIO_2" according to "mmreg.h", from which it presumably derives. "WAVE_FORMAT_ISIAUDIO" is already the ID of codec 88, which appears earlier in the appendix.

RFC 2397, "The "data" URL scheme", August 1998

Source of RFC: Legacy

Errata ID: 5923
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Richard Gibson
Date Reported: 2019-11-29

Section 3 says:

3. Syntax

       dataurl    := "data:" [ mediatype ] [ ";base64" ] "," data
       mediatype  := [ type "/" subtype ] *( ";" parameter )
       data       := *uric
       parameter  := attribute "=" value

   where "uric" is imported from [RFC2396], and "type", "subtype",
   "attribute" and "value" are the corresponding tokens from [RFC2045],
   represented using URL escaped encoding of [RFC2396] as necessary.

   Attribute values in [RFC2045] are allowed to be either represented as
   tokens or as quoted strings. However, within a "data" URL, the
   "quoted-string" representation would be awkward, since the quote mark
   is itself not a valid urlchar. For this reason, parameter values
   should use the URL Escaped encoding instead of quoted string if the
   parameter values contain any "tspecial".

It should say:

3. Syntax

       dataurl    := "data:" [ mediatype ] [ ";base64" ] "," data
       mediatype  := [ type "/" subtype ] *( ";" parameter )
       data       := *uric
       parameter  := attribute "=" value
       value      := token

   where "uric" is imported from [RFC2396], and "type", "subtype",
   "attribute" and "token" are the corresponding syntax from [RFC2045],
   with values represented using %xx escaped encoding of [RFC2396] as
   necessary.

   Parameter values in [RFC2045] are allowed to be either represented as
   tokens or as quoted strings. However, within a "data" URL, the
   "quoted-string" representation would be awkward, since the quote mark
   is itself not a valid urlchar. For this reason, parameter values are
   required to be represented as tokens and %xx encoding MUST be used for
   "tspecials" characters within them.

Notes:

Section 3 is not clear about excluding the "quoted-string" production completely as opposed to permitting it through percent-encoding, resulting in ambiguity for interpretation of URLs such as "data:text/example;foo=%22bar%22,*baz*". But Section 5 refers to accepted changes that 'eliminate "quoted printable" as an encoding since it would not easily yield valid URLs without additional %xx encoding, which itself is sufficient', so it seems that the intent is to *replace* quoted-string and always interpret percent-encoded characters as content (i.e., that my example corresponds with `Content-Type: text/example; foo="\"bar\""` rather than `Content-Type: text/example;foo="bar").

RFC 2526, "Reserved IPv6 Subnet Anycast Addresses", March 1999

Source of RFC: ipngwg (int)

Errata ID: 7807
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Phu Dang Kim
Date Reported: 2024-02-10

Section 2 says:

In particular, for IPv6 address
   types required to have 64-bit interface identifiers in EUI-64 format,
   the universal/local bit MUST be set to 0 (local)

It should say:

In particular, for IPv6 address
   types required to have 64-bit interface identifiers in EUI-64 format,
   the universal/local bit MUST be set to 1 (local)

Notes:

local 1 not 0 (https://datatracker.ietf.org/doc/html/rfc4291#section-2.6)

RFC 2549, "IP over Avian Carriers with Quality of Service", April 1999

Source of RFC: INDEPENDENT

Errata ID: 6206
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Derek McCullough
Date Reported: 2020-06-07

Throughout the document, when it says:

Multicasting is supported, but requires the implementation of a clone
device.  Carriers may be lost if they are based on a tree as it is
being pruned.  The carriers propagate via an inheritance tree.  The
carriers have an average TTL of 15 years, so their use in expanding
ring searches is limited.

Additional quality of service discussion can be found in a Michelin's
guide.

It should say:

Multicasting is supported, but requires the implementation of a clone
device.  Carriers may be lost if they are based on a tree as it is
being pruned.  The carriers propagate via an inheritance tree.  The
carriers have an average TTL of 15 years, so their use in expanding
ring searches is limited.

NOTE: Geese are for UDP only, as they are indifferent to any query,
regardless of target. Expect all Geese allocated traffic to be one
way only.

Additional quality of service discussion can be found in a Michelin's
guide.

Notes:

Geese have not been thoroughly considered for their jerk-ishness and need to be included in the documentation as a warning to anyone considering utilization of aviary modes of data transportation.

RFC 2631, "Diffie-Hellman Key Agreement Method", June 1999

Source of RFC: smime (sec)

Errata ID: 6302
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Abdullah Talayhan
Date Reported: 2020-10-07

Section 2.2.1.1 says:

3. Set N’= L/1024

It should say:

3. Set N = L/1024

Notes:

The definition of N' is not used in the document. On line 19 of the algorithm, we have "If counter < (4096 * N) then go to 8.". Hence, either the definition on line 3 has to be N instead of N', or it should be N' instead of N on line 19.

RFC 2634, "Enhanced Security Services for S/MIME", June 1999

Note: This RFC has been updated by RFC 5035

Source of RFC: smime (sec)

Errata ID: 6562
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: David von Oheimb
Date Reported: 2021-04-28

Section 5.4 says:

   The first certificate identified in the sequence of certificate
   identifiers MUST be the certificate used to verify the signature. The
   encoding of the ESSCertID for this certificate SHOULD include the
   issuerSerial field. If other constraints ensure that
   issuerAndSerialNumber will be present in the SignerInfo, the
   issuerSerial field MAY be omitted. The certificate identified is used
   during the signature verification process. If the hash of the
   certificate does not match the certificate used to verify the
   signature, the signature MUST be considered invalid.

   If more than one certificate is present in the sequence of
   ESSCertIDs, the certificates after the first one limit the set of
   authorization certificates that are used during signature validation.

It should say:

   The sequence of certificate identifiers MUST contain at least one element.
   The first certificate identified MUST be the certificate used to verify the signature.
   The encoding of the ESSCertID for this certificate SHOULD include the
   issuerSerial field. If other constraints ensure that
   issuerAndSerialNumber will be present in the SignerInfo, the
   issuerSerial field MAY be omitted. The certificate identified is used
   during the signature verification process. If the hash of the
   certificate does not match the certificate used to verify the
   signature, the signature MUST be considered invalid.

   If more than one certificate identifier is present in the sequence of ESSCertIDs,
   all certificates referenced there MUST be part of the signature validation chain.

Notes:

Some aspects of the 'certs' field of a SigningCertificate attribute:

SigningCertificate ::= SEQUENCE {
certs SEQUENCE OF ESSCertID,
policies SEQUENCE OF PolicyInformation OPTIONAL
}

described in the sentences quoted above are very vague.
This lead to major confusion and wrong implementations.
As meanwhile has been clarified, they should be re-phrased;
see suggested new version above.

(One may further mandate/clarify that the certificate identifiers must be given in the same order
as they are expected in the validation chain, but I think this is not important because
the order should not play a critical role and will be determined by the validation chain anyway.)

RFC 2638, "A Two-bit Differentiated Services Architecture for the Internet", July 1999

Source of RFC: Legacy

Errata ID: 5359
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Greg Skinner
Date Reported: 2018-05-15

Section 9 says:

[10] D. Clark and W. Fang, "Explicit Allocation of Best Effort packet
       Delivery Service", IEEE/ACM Transactions on Networking, August,
       1998, Vol6, No 4, pp. 362-373. also at: http://
       diffserv.lcs.mit.edu/Papers/exp-alloc-ddc-wf.pdf

It should say:

[10] D. Clark and W. Fang, "Explicit Allocation of Best Effort
packet Delivery Service", IEEE/ACM Transactions on Networking,
August, 1998, Vol6, No 4, pp. 362-373. also at:
https://web.archive.org/web/20000816232212/
http://diffserv.lcs.mit.edu:80/Papers/exp-alloc-ddc-wf.pdf 

Notes:

The diffserv.lcs.mit.edu web server is no longer available. However, the paper can be accessed via the Internet Archive. (I needed to split the last sentence of the corrected text so it would be accepted by the errata tool.) If using Internet Archive links is not permitted or recommended, I would accept just omitting the last sentence ("also at: ...) altogether. The article is available at https://dl.acm.org/citation.cfm?id=288401&dl=ACM&coll=DL, but it is behind a paywall.

RFC 3062, "LDAP Password Modify Extended Operation", February 2001

Source of RFC: Legacy
Area Assignment: app

Errata ID: 4899
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Rick van Rein
Date Reported: 2017-01-09

Section 2 says:

   PasswdModifyRequestValue ::= SEQUENCE {
     userIdentity    [0]  OCTET STRING OPTIONAL
     oldPasswd       [1]  OCTET STRING OPTIONAL
     newPasswd       [2]  OCTET STRING OPTIONAL }

It should say:

   PasswdModifyRequestValue ::= SEQUENCE {
     userIdentity    [0]  OCTET STRING OPTIONAL,
     oldPasswd       [1]  OCTET STRING OPTIONAL,
     newPasswd       [2]  OCTET STRING OPTIONAL }

Notes:

The missing commas are probably just a typo in the formal specifications, but it is pleasant if they are acceptable to ASN.1 compilers.

RFC 3091, "Pi Digit Generation Protocol", April 2001

Source of RFC: INDEPENDENT

Errata ID: 4965
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Jesse Friedman
Date Reported: 2017-03-12

Throughout the document, when it says:

1.     TCP Based Digit Generator Service

   One REQUIRED PIgen service is defined as a stateless TCP service.  A
   server listens on TCP port 314159.

...

1.1.   Approximate Service

   An OPTIONAL PIgen service is defined as a stateless TCP service.  A
   server listens on TCP port 220007.

...

2.     UDP Based Digit Generator Service

   An OPTIONAL PIgen service is defined as a stateless UDP service.  A
   server listens on UDP port 314159.

...

2.2.   Approximate Service

   An OPTIONAL PIgen service is defined as a stateless UDP service.  A
   server listens on UDP port 220007.

It should say:

1.     TCP Based Digit Generator Service

   One REQUIRED PIgen service is defined as a stateless TCP service.  A
   server listens on TCP port 31415.

...

1.1.   Approximate Service

   An OPTIONAL PIgen service is defined as a stateless TCP service.  A
   server listens on TCP port 22007.

...

2.     UDP Based Digit Generator Service

   An OPTIONAL PIgen service is defined as a stateless UDP service.  A
   server listens on UDP port 31415.

...

2.2.   Approximate Service

   An OPTIONAL PIgen service is defined as a stateless UDP service.  A
   server listens on UDP port 22007.

Notes:

Ports as specified in the original text exceed 16-bit integer space, violating TCP (RFC793 3.1) and UDP (RFC768, "Format"). As it stands, this error prevents development of fully-compliant implementations of this protocol.
Note that in this correction I have elected not to round the TCP and UDP ports in sec. 1 and 2 to 31416 - this is to better-preserve the immediate recognizability of the port as the PIgen service.
Also note that the IP multicast group address specified in sec. 3 exceeds the 32-bit address space specified in RFC 791 sec. 2.3. I have abstained from proposing a correction to this, as I could not think of an IANA-compliant address that still incorporates digits of pi.

Errata ID: 5217
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Luís Câmara
Date Reported: 2017-12-26

Section 3 says:

   An OPTIONAL PIgen service is defined as a stateless UDP service.  A
   random distribution of digits of Pi are sent using the payload format
   described in section 2.1.2. to the IP multicast group
   314.159.265.359.

It should say:

   An OPTIONAL PIgen service is defined as a stateless UDP service.  A
   random distribution of digits of Pi are sent using the payload format
   described in section 2.1.2. to the IPv6 multicast group
   ff0e:3141:5926:5358:9793:2384:6264:3833.

Notes:

314.159.265.359 is not a valid IPv4 address, because it contains octets larger than 255. Using IPv6 multicast allows 28 digits of Pi in the address and will accelerate the transition to it.

RFC 3261, "SIP: Session Initiation Protocol", June 2002

Note: This RFC has been updated by RFC 3265, RFC 3853, RFC 4320, RFC 4916, RFC 5393, RFC 5621, RFC 5626, RFC 5630, RFC 5922, RFC 5954, RFC 6026, RFC 6141, RFC 6665, RFC 6878, RFC 7462, RFC 7463, RFC 8217, RFC 8591, RFC 8760, RFC 8898, RFC 8996

Source of RFC: sip (rai)

Errata ID: 4275
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Chao Wang
Date Reported: 2015-02-19

Section 15 says:

The caller's UA MAY send a BYE for either confirmed or early dialogs

It should say:

The caller's UA MUST send a BYE for confirmed dialogs

Notes:

In general, BYE shall be handled in the same way as CANCEL if it is for early dialogs.
In case, when BYE is on the way to the destination, the callee probably accepts INVITE, the race condition will occure.
If we follow the procedure as CANCEL, caller shall send ACK for 200 OK and immediately release the session using BYE.
So two BYEs will be triggered in the case, it does not make sense.

Errata ID: 4553
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Christer Holmberg
Date Reported: 2015-12-04

Section 20.11 says:

The handling parameter, handling-param, describes how the UAS should
react if it receives a message body whose content type or disposition
type it does not understand.  The parameter has defined values of
"optional" and "required".  If the handling parameter is missing, the
value "required" SHOULD be assumed.  The handling parameter is
described in RFC 3204 [19].

It should say:

The handling parameter, handling-param, describes how the UAS should
react if it receives a message body whose content type or disposition
type it does not understand.  The parameter has defined values of
"optional" and "required".  If the handling parameter is missing, or if
the Content-Disposition header field is missing, the value "required" 
MUST be assumed.  The handling parameter is described in RFC 3204 [19].

Notes:

SIPCORE discussion: https://mailarchive.ietf.org/arch/msg/sipcore/bn-pRgDyGL2FP_M7eYpyT35zNp4

Errata ID: 5653
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Vimal Chandra Tewari
Date Reported: 2019-03-12

Section 17.1.1.2 says:

Notes:

When a INVITE client transaction transitions to Proceeding state (upon receiving a provisional response), the request retransmission stops (for an unreliable transport) i.e. Timer A is stopped.
However in Proceeding state, Timer B, i.e. Transaction Timeout Timer can still fire if no final response is received in stipulated time in which case the TU should be informed and the transaction should transition to Terminated state.
"Figure 5: INVITE client transaction" in RFC 3261 does not show the Timer B expiry event in Proceeding state. This means that we are saying there is a guarantee that a final response will always be received in Proceeding state which may not always be the case.
In my opinion, the Proceeding state in Figure 5 should be updated to include a Timer B event.

Errata ID: 6645
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Matt Hertogs
Date Reported: 2021-07-20

Section 23.3 says:

Content-Disposition: attachment; filename=smime.p7m
           handling=required

It should say:

Content-Disposition: attachment; filename=smime.p7m;
           handling=required

Notes:

The example for Content-Disposition header is incorrectly formatted according to the BNF.
It is missing a semicolon between each disp-param.
(Relevant section of BNF posted below)

Content-Disposition = "Content-Disposition" HCOLON
disp-type *( SEMI disp-param )
disp-type = "render" / "session" / "icon" / "alert"
/ disp-extension-token
disp-param = handling-param / generic-param
handling-param = "handling" EQUAL
( "optional" / "required"
/ other-handling )
other-handling = token
disp-extension-token = token

This also occurs in 23.4.3

Errata ID: 6793
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Mojtaba Esfandiari.S
Date Reported: 2021-12-21

Section 8.1.1.5 says:

The CSeq header field serves as a way to identify and order
   transactions.  It consists of a sequence number and a method.  The
   method MUST match that of the request.  For non-REGISTER requests
   outside of a dialog, the sequence number value is arbitrary.  The
   sequence number value MUST be expressible as a 32-bit unsigned
   integer and MUST be less than 2**31.  As long as it follows the above
   guidelines, a client may use any mechanism it would like to select
   CSeq header field values.

It should say:

The CSeq header field serves as a way to identify and order
   transactions.  It consists of a sequence number and a method.  The
   method MUST match that of the request.  For non-REGISTER requests
   outside of a dialog, the sequence number value is arbitrary. For requests with its credentials after receiving a
   401 (Unauthorized) or 407 (Proxy Authentication Required) response,
  the CSeq header field value MUST increment. The
   sequence number value MUST be expressible as a 32-bit unsigned
   integer and MUST be less than 2**31.  As long as it follows the above
   guidelines, a client may use any mechanism it would like to select
   CSeq header field values.

Notes:

For more clarity and more understanding, It would be nice to have a quiet bit of update in RFC 3261 section 8.1.1.5. Because, the word "arbitrary" in the CSeq value may be confused with the same value as before.

Errata ID: 7529
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Shraddha Soni
Date Reported: 2023-05-29

Section 25.1 says:

This is intended to behave exactly as HTTP/1.1 as described in RFC 2616 [8].
The SWS construct is used when linear white space is optional, generally between tokens and separators.

      LWS  =  [*WSP CRLF] 1*WSP ; linear whitespace

It should say:

This is intended to behave exactly as HTTP/1.1 as described in RFC 2616 [8].
The SWS construct is used when linear white space is optional, generally between tokens and separators.

      LWS  =  [CRLF] 1*WSP ; linear whitespace

Notes:

RFC 2616 states
LWS = [CRLF] 1*( SP | HT )

RFC 2234 states
WSP = SP / HTAB
; white space
RFC 3261 is referencing both for BNF to follow, but looks like a new BNF is stated. So either it should not reference to follow RFC 2616 exactly or follow the same BNF as 2616.

RFC 3262, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", June 2002

Source of RFC: sip (rai)

Errata ID: 4605
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Christer Holmberg
Date Reported: 2016-01-05

Section 3, 4 says:

Section 3:

   The provisional response to be sent reliably is constructed by the
   UAS core according to the procedures of Section 8.2.6 of RFC 3261.
   In addition, it MUST contain a Require header field containing the
   option tag 100rel, and MUST include an RSeq header field.  The value
   of the header field for the first reliable provisional response in a
   transaction MUST be between 1 and 2**31 - 1.  It is RECOMMENDED that
   it be chosen uniformly in this range.  The RSeq numbering space is
   within a single transaction.  This means that provisional responses
   for different requests MAY use the same values for the RSeq number.


Section 4:

   If a provisional response is received for an initial request, and
   that response contains a Require header field containing the option
   tag 100rel, the response is to be sent reliably.  If the response is
   a 100 (Trying) (as opposed to 101 to 199), this option tag MUST be
   ignored, and the procedures below MUST NOT be used.

   The provisional response MUST establish a dialog if one is not yet
   created.

   Assuming the response is to be transmitted reliably, the UAC MUST
   create a new request with method PRACK.  This request is sent within
   the dialog associated with the provisional response (indeed, the
   provisional response may have created the dialog).  PRACK requests
   MAY contain bodies, which are interpreted according to their type and
   disposition.

   Note that the PRACK is like any other non-INVITE request within a
   dialog.  In particular, a UAC SHOULD NOT retransmit the PRACK request
   when it receives a retransmission of the provisional response being
   acknowledged, although doing so does not create a protocol error.

   Once a reliable provisional response is received, retransmissions of
   that response MUST be discarded.  A response is a retransmission when
   its dialog ID, CSeq, and RSeq match the original response.  The UAC
   MUST maintain a sequence number that indicates the most recently
   received in-order reliable provisional response for the initial
   request.  This sequence number MUST be maintained until a final
   response is received for the initial request.  Its value MUST be
   initialized to the RSeq header field in the first reliable
   provisional response received for the initial request.

   Handling of subsequent reliable provisional responses for the same
   initial request follows the same rules as above, with the following
   difference: reliable provisional responses are guaranteed to be in
   order.  As a result, if the UAC receives another reliable provisional
   response to the same request, and its RSeq value is not one higher
   than the value of the sequence number, that response MUST NOT be
   acknowledged with a PRACK, and MUST NOT be processed further by the
   UAC.  An implementation MAY discard the response, or MAY cache the
   response in the hopes of receiving the missing responses.

It should say:

Section 3:

   The provisional response to be sent reliably is constructed by the
   UAS core according to the procedures of Section 8.2.6 of RFC 3261.
   In addition, it MUST contain a Require header field containing the
   option tag 100rel, and MUST include an RSeq header field.  The
   value of the header field for the first reliable provisional 
   response in a transaction MUST be between 1 and 2**31 - 1.  It is
   RECOMMENDED that it be chosen uniformly in this range. The RSeq 
   numbering space is within a single transaction. This means that
   the RSeq value of a provisional response within a fork of a request
   is independent of the RSeq value of a provisional response within 
   any other fork of that request, or for the responses for any other
   request. It thus may be higher, lower, or the same as any other such
   RSeq value.


Section 4:

   If a provisional response is received for an initial request, and
   that response contains a Require header field containing the option
   tag 100rel, the response was sent by the UAS reliably.  If the
   response is a 100 (Trying) (as opposed to 101 to 199), this option
   tag MUST be ignored, and the procedures below MUST NOT be used.

   The provisional response MUST establish a dialog if one is not yet
   created.

   Assuming the response was transmitted reliably by the UAS, the UAC
   MUST create a new request with method PRACK.  This request is sent
   within the dialog associated with the provisional response (indeed,
   the provisional response may have created the dialog). PRACK 
   requests MAY contain bodies, which are interpreted according to
   their type and disposition.

   Note that the PRACK is like any other non-INVITE request within a
   dialog. In particular, a UAC SHOULD NOT retransmit the PRACK request
   when it receives a retransmission of the provisional response being
   acknowledged, although doing so does not create a protocol error.

   Once a reliable provisional response is received, retransmissions of
   that response MUST be discarded.  A response is a retransmission 
   when its dialog ID, CSeq, and RSeq match the original response. The
   UAC MUST maintain, independently for each dialog ID, a sequence
   number that indicates the most recently received in-order reliable
   provisional response for the initial request.  This sequence number
   MUST be maintained until a final response is received for the
   initial request. Its value MUST, for each dialog (or early dialog),
   be initialized to the RSeq header field in the first reliable
   provisional response, associated with the dialog, received for the
   initial request.

   Subsequent reliable provisional responses for the same initial
   request are guaranteed  to have been generated by the UAS in the
   order of their RSeq values and must be acknowledged in that order.
   As a result, if the UAC receives another reliable provisional
   response to the same request, and its RSeq value is one higher than
   the value of the previously received RSeq value in the dialog (or 
   early dialog), then the new RSeq value is saved and the response is
   handled as described above. If the RSeq value is not one higher than
   the value of the sequence number, that response MUST NOT be
   acknowledged with a PRACK, and MUST NOT be processed further by the
   UAC. An implementation MAY discard the response, or MAY cache the
   response to be processed (and acknowledged) after receiving the
   missing responses.

RFC 3264, "An Offer/Answer Model with Session Description Protocol (SDP)", June 2002

Note: This RFC has been updated by RFC 6157, RFC 8843, RFC 9143

Source of RFC: mmusic (rai)

Errata ID: 5177
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Sandeep Kumar Aitha
Date Reported: 2017-11-03

Section 5.1 says:

Section 5.1 says:
However, for sendonly and sendrecv streams, the answer might indicate
different payload type numbers for the same codecs, in which case,
the offerer MUST send with the payload type numbers from the answer.

Section 6.2 says:
In the case of RTP, if a particular codec was referenced with a
specific payload type number in the offer, that same payload type
number SHOULD be used for that codec in the answer.

It should say:

Only one of the above statements can be correct.

Notes:

Above two statements are conflicting.
The answerer should be able to either map the payload type to a different codec or not.

Errata ID: 7597
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Hugo Tunius
Date Reported: 2023-08-11

Section 6.1 says:

   The interpretation of fmtp parameters in an offer depends on the
   parameters.  In many cases, those parameters describe specific
   configurations of the media format, and should therefore be processed
   as the media format value itself would be.  This means that the same
   fmtp parameters with the same values MUST be present in the answer if
   the media format they describe is present in the answer.  Other fmtp
   parameters are more like parameters, for which it is perfectly
   acceptable for each agent to use different values.  In that case, the
   answer MAY contain fmtp parameters, and those MAY have the same
   values as those in the offer, or they MAY be different.  SDP
   extensions that define new parameters SHOULD specify the proper
   interpretation in offer/answer.

It should say:

   The interpretation of fmtp parameters in an offer depends on the
   parameters.  In many cases, those parameters describe specific
   configurations of the media format, and should therefore be processed
   as the media format value itself would be.  This means that the same
   fmtp parameters with the same values MUST be present in the answer if
   the media format they describe is present in the offer.  Other fmtp
   parameters are more like parameters, for which it is perfectly
   acceptable for each agent to use different values.  In that case, the
   answer MAY contain fmtp parameters, and those MAY have the same
   values as those in the offer, or they MAY be different.  SDP
   extensions that define new parameters SHOULD specify the proper
   interpretation in offer/answer.

Notes:

This indicated that the same fmtp parameters with the same values MUST be present in the answer if the media format they describe is present in the **answer**.

I believe the second instance of **answer** should be replace with **offer**, otherwise the quoted text does not makes sense I think.

RFC 3323, "A Privacy Mechanism for the Session Initiation Protocol (SIP)", November 2002

Source of RFC: sip (rai)

Errata ID: 5184
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: DONG O YI
Date Reported: 2017-11-16

Section 4.2 Expre... says:

Privacy-hdr  =  "Privacy" HCOLON priv-value *(";" priv-value)

It should say:

Privacy-hdr  =  "Privacy" HCOLON priv-value *("," priv-value)

Notes:

RFC3261 says,

Specifically, any SIP header whose grammar is of the form

header = "header-name" HCOLON header-value *(COMMA header-value)

allows for combining header fields of the same name into a comma-
separated list.

So, RFC3323 conflicts RFC3261.

RFC 3325, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", November 2002

Note: This RFC has been updated by RFC 5876, RFC 8217

Source of RFC: sip (rai)

Errata ID: 7794
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Christos Diamantis
Date Reported: 2024-02-02

Section 10.2 says:

The next proxy removes the P-Asserted-Identity 
header field and the request for Privacy before forwarding this 
request onward to the biloxi.com proxy server which it does not trust.

It should say:

The next proxy removes the P-Asserted-Identity 
header field but does not remove the request for Privacy before forwarding this 
request onward to the biloxi.com proxy server which it does not trust.

Notes:

As stated in ETSI TS 124 607 V17.0.0 (2022-04),
section 4.3.3 Requirements on the terminating network side:
NOTE 1: The priv-value "id" in the Privacy header is not expected be removed when removing any P-Asserted-Identity header as described in 3GPP TS 24.229 subclauses 4.4.2 (The priv-value "id" shall not be removed from the Privacy header field when SIP signalling crosses the boundary of the trust domain) and 5.4.3.3.
and also,
section 4.5.2.9 Actions at the AS serving the terminating UE:
The priv-value "id" in the Privacy header will be used by the terminating UE to distinguish the request of OIR by the originating user.

RFC 3339, "Date and Time on the Internet: Timestamps", July 2002

Source of RFC: impp (app)

Errata ID: 5783
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Felipe Gasper
Date Reported: 2019-07-15

Section 5.6 says:

   date-time       = full-date "T" full-time

...

      NOTE: ISO 8601 defines date and time separated by "T".
      Applications using this syntax may choose, for the sake of
      readability, to specify a full-date and full-time separated by
      (say) a space character.

Notes:

This specification seems ambiguous; the ABNF allows only “T”/“t” as the separator, but the “NOTE:” paragraph describes acceptability of other separators.

It’s unclear what “this syntax” refers to: if “this” refers to ISO 8601, then it seems irrelevant, but if “this” means RFC 3339, then the paragraph conflicts with the ABNF.

I’m not sure of the proper fix because I don’t know the intended meaning.

RFC 3402, "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", October 2002

Source of RFC: urn (app)

Errata ID: 7049
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Timothy McSweeney
Date Reported: 2022-07-25

Section 4 says:

      One such case can be found in the URI
      Resolution application which defines the 'p' flag which states
      that the next step is 'protocol specific' and thus outside of the
      scope of DDDS.

It should say:

      One such case can be found in the URI
      Resolution application which defines the 'P' flag which states
      that the next step is 'protocol specific' and thus outside of the
      scope of DDDS.

Notes:

Capital "P" is used for the flag in the URI Resolution Application RFC3404

RFC 3445, "Limiting the Scope of the KEY Resource Record (RR)", December 2002

Note: This RFC has been obsoleted by RFC 4033, RFC 4034, RFC 4035

Source of RFC: dnsext (int)

Errata ID: 7836
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ted Lemon
Date Reported: 2024-03-04

Throughout the document, when it says:

Updates: RFC2535

It should say:

Updates: RFC2535, RFC2931

Notes:

This is based on our experience that when writing draft-ietf-dnssd-srp, we had no idea that the KEY RR format was updated, because there was no reference to the updated format in the datatracker page for RFC2931. I think it makes sense to say that 3445 updates 2931, because it does so explicitly.

RFC 3501, "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", March 2003

Note: This RFC has been obsoleted by RFC 9051

Note: This RFC has been updated by RFC 4466, RFC 4469, RFC 4551, RFC 5032, RFC 5182, RFC 5738, RFC 6186, RFC 6858, RFC 7817, RFC 8314, RFC 8437, RFC 8474, RFC 8996

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 6637
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: TornaxO7
Date Reported: 2021-07-10

Section 9 says:

envelope        = "(" env-date SP env-subject SP env-from SP
                  env-sender SP env-reply-to SP env-to SP env-cc SP
                  env-bcc SP env-in-reply-to SP env-message-id ")"

It should say:

envelope        = "(" env-date SP env-subject SP env-from SP
                  env-sender SP env-reply-to SP env-to SP env-cc SP
                  env-bcc SP env-in-reply-to SP env-message-id SP 
                  env-references ")"

Notes:

Section 2.3.5 says:

A parsed representation of the [RFC-2822] header of the message.
Note that the IMAP Envelope structure is not the same as an
[SMTP] envelope.

Althought RFC-2822 is obsolete by RFC-5322 now, both says that the envelope should inlcude a "References:" header-field but the definition of the envelope in section 9 of RFC-3501 (see the part in "Original Text" above) doesn't include the "references" field.

RFC 3507, "Internet Content Adaptation Protocol (ICAP)", April 2003

Source of RFC: INDEPENDENT

Errata ID: 5893
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Steve Hill
Date Reported: 2019-11-04

Section 4.5 says:

100 Continue.  If the entire encapsulated HTTP body did not fit in the preview, the ICAP client MUST send the remainder of its ICAP message, starting from the first chunk after the preview.  If the entire message fit in the preview (detected by the "EOF" symbol explained below), then the ICAP server MUST NOT respond with 100 Continue.

It should say:

100 Continue.  If the entire encapsulated HTTP body did not fit in the preview, the ICAP client MUST send the remainder of its ICAP message, starting from the first chunk after the preview.  If the entire message fit in the preview (detected by the "EOF" symbol explained below), then the ICAP client MUST ignore a 100 Continue response.

Notes:

Originally, the ICAP server was prohibited from sending a 100 Continue if the entire HTTP body fits in the preview. However, the ICAP server cannot know if the entire body fits in the preview until the whole preview has been received. An ICAP server cannot begin loop-back streaming of the HTTP transaction until the whole preview has been received, because it cannot know whether or not it is appropriate to send a "100 Continue" first. This severely impacts situations where an HTTP server is producing a very slow data stream and therefore causes the preview to take a long time.

The corrected text makes it permissible for an ICAP server to blindly send a "100 Continue" before it knows whether or not it is appropriate, and requires the ICAP client to ignore the "100 Continue" in the event that it turned out to not be appropriate.

A server that sends a "100 Continue" response before receiving the final preview chunk will be able to note the presence or absence of the ieof chunk extension when the final preview chunk later arrives, and therefore determine whether that marks the end of the ICAP request or whether to expect the client to immediately begin streaming the non-preview data.

RFC 3515, "The Session Initiation Protocol (SIP) Refer Method", April 2003

Note: This RFC has been updated by RFC 7647, RFC 8217

Source of RFC: sip (rai)

Errata ID: 4652
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Brett Tate
Date Reported: 2016-03-30

Section 2.1 says:

The Refer-To header field MAY be encrypted as part of end-to-end
encryption.

It should say:

If the URI contains a comma, question mark or semicolon, the URI
MUST be enclosed in angle brackets (< and >).

The Refer-To header field MAY be encrypted as part of end-to-end
encryption.

Notes:

If addr-spec is used when there are parameters, it is ambiguous if the parameters are URI parameters or header parameters. For consistency with RFC 3261 section 20, the same bracket rule is indicated even if comma and question mark do not cause an issue.

RFC 3579, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", September 2003

Note: This RFC has been updated by RFC 5080

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 6154
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Alan DeKok
Date Reported: 2020-05-01
Edited by: Eliot Lear
Date Edited: 2022-04-01

Section 2.1 says:

   EAP-Start is indicated by sending an EAP-Message attribute with a
   length of 2 (no data).

It should say:

   EAP-Start is indicated by sending an EAP-Message attribute with a
   length of 3.  The single byte of data SHOULD be set to zero on
   transmission and MUST be ignored on receipt.  RADIUS clients MUST
   NOT send EAP-Message attributes of length 2, as attributes with no
   value are not permitted in RADIUS.  However, for historical reasons
   and for compatibility with existing practice, RADIUS servers MUST
   accept EAP-Messages of length 2, and treat them as EAP-Start.

Notes:

RFC 2865 Section 5 says that empty attributes must be omitted:

text 1-253 octets containing UTF-8 encoded 10646 [7]
characters. Text of length zero (0) MUST NOT be sent;
omit the entire attribute instead.

Section 3.1 of RFC 3579 also says that the EAP-Message attribute cannot be sent with length 2:

...
Type

79 for EAP-Message

Length

>= 3
...

In practice, few devices seem to send EAP-Message with Length 2.

Errata ID: 6259
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Alan DeKok
Date Reported: 2020-08-20
Edited by: Eliot Lear
Date Edited: 2022-04-01

Section 2.1 says:

  Where the initial EAP-Request sent by the NAS is for an
  authentication Type (4 or greater), the peer MAY respond with a Nak
  indicating that it would prefer another authentication method that is
  not implemented locally.  

It should say:

  Where the initial EAP-Request sent by the NAS is for an
  authentication Type (4 or greater), the peer MAY respond with a Nak
  indicating that it would prefer another authentication method. In this
  case, the NAS should send an Access-Request encapsulating the
  received EAP-Response/Nak.  This allows a peer to suggest another
  EAP method where the NAS is configured to send a default EAP
  type (such as MD5-Challenge) which may not be appropriate.

Notes:

Clarify what happens when a NAK is received and correct the "not" in the original text.

RFC 3665, "Session Initiation Protocol (SIP) Basic Call Flow Examples", December 2003

Source of RFC: sipping (rai)

Errata ID: 5294
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Yehoshua Gev
Date Reported: 2018-03-22

Section 3.1 says:

BYE sip:alice@client.atlanta.example.com SIP/2.0

It should say:

BYE sip:alice@client.atlanta.example.com;transport=tcp SIP/2.0

Notes:

In Example 3.1, the URI of the Contact header field of the INVITE request (F1) containes a parameter "transport=tcp".
According to section 12.2.1.1 of RFC 3261, this URI should be used as the Request-URI for Bob sending requests within this dialog.
As there is no explicit text about omitting parameters from the URI, the Request-URI should contain the "transport=tcp" parameter.
Hence, the Request-URI of the BYE request (F5) should contain the parameter.

It seems that the this problem was reported some years ago in the sip-implementors list:
https://lists.cs.columbia.edu/pipermail/sip-implementors/2006-July/013507.html

The same problem appear in other examples, specifically 3.2 and 3.6.

Errata ID: 6242
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Johan Kuuse
Date Reported: 2020-07-27

Section 3.9 says:

SIP/2.0  486 Busy Here

It should say:

SIP/2.0 486 Busy Here

Notes:

At three different locations in section 3.9, there are two space characters between the SIP version and the Status Code, instead of one space.

According to RFC 3261, section 7.2, the Status line of a SIP Response, each element is separated by a single SP character.

Errata ID: 6984
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Xiaoxi Li
Date Reported: 2022-05-31

Section 3.2 says:

   F5 INVITE Proxy 1 -> Proxy 2

   INVITE sip:bob@biloxi.example.com SIP/2.0
   Via: SIP/2.0/TCP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
    ;received=192.0.2.101
   Max-Forwards: 69

   F7 INVITE Proxy 2 -> Bob

   INVITE sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/TCP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1
   Via: SIP/2.0/TCP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1
    ;received=192.0.2.111
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
    ;received=192.0.2.101
   Max-Forwards: 68

   F16 ACK Proxy 1 -> Proxy 2

   ACK sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/TCP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b76
    ;received=192.0.2.101
   Max-Forwards: 69

   F17 ACK Proxy 2 -> Bob

   ACK sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/TCP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1

   Via: SIP/2.0/TCP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1
    ;received=192.0.2.111
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b76
    ;received=192.0.2.101
   Max-Forwards: 68
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl

It should say:

the branch id in the topmost Via header(s) in the F16 F17 messages shouldn't be the same as the via headers added in F5 F7 messages.

the ACK message shall only copy the same branch id in Via if it's for non-200 ok responses. 

this example deviates from the description in RFC 3261 chapter 16.6

Notes:

the branch id in the topmost Via header(s) in the F16 F17 messages shouldn't be the same as the via headers added in F5 F7 messages.

the ACK message shall only copy the same branch id in Via if it's for non-200 ok responses.

this example deviates from the description in RFC 3261 chapter 16.6

RFC 3720, "Internet Small Computer Systems Interface (iSCSI)", April 2004

Note: This RFC has been obsoleted by RFC 7143

Note: This RFC has been updated by RFC 3980, RFC 4850, RFC 5048, RFC 7146

Source of RFC: ips (tsv)

Errata ID: 7622
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Wu Kaiqiang
Date Reported: 2023-08-31

Section 12.1 says:

   +---------------------------------------------+
   | Name          | Description     | Generator |
   +---------------------------------------------+
   | CRC32C        | 32 bit CRC      |0x11edc6f41|
   +---------------------------------------------+
   | None          | no digest                   |
   +---------------------------------------------+

It should say:

   +---------------------------------------------+
   | Name          | Description     | Generator |
   +---------------------------------------------+
   | CRC32C        | 32 bit CRC      |0x1edc6f41|
   +---------------------------------------------+
   | None          | no digest                   |
   +---------------------------------------------+

Notes:

The polynomial should be 0x1edc6f41, not 0x11edc6f41 (which include more 1)

RFC 3743, "Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean", April 2004

Source of RFC: INDEPENDENT

Errata ID: 5279
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Francisco Arias
Date Reported: 2018-03-06

Section 5.1 says:

CodePoint = 4*8DIGIT  [ "(" Reflist ")" ]

It should say:

CodePoint = 4*8HEXDIG  [ "(" Reflist ")" ]

Notes:

Per RFC 5234, the definition for "DIGIT" in ABNF encompasses only decimal digits (i.e., 0-9), while "HEXDIG" includes the hexadecimal digits (i.e., 0-F).

Section 4 of RFC 3743 includes example Language Variant Tables that describe the code points using hexadecimal, not decimal. Looking at tables published in IANA, they seem to use hexadecimal too. It would appear that the use of "DIGIT" instead of "HEXDIGIT" in section 5.1 was an error.

RFC 3797, "Publicly Verifiable Nominations Committee (NomCom) Random Selection", June 2004

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 7030
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Rich Salz
Date Reported: 2022-07-19

Throughout the document, when it says:

Step 2 of section 4 says:
   Order the values from each source from smallest to the largest
   and concatenate them and suffix the result with a "/".

The "Resultant Key String" in section 6, shows the numbers with a period after each number:
  9319./2.5.8.10.12./9.18.26.34.41.45./

It should say:

Step 2 of section 4 should say
  Order the values from each source from smallest to largest, append a
  "." after each value, and concatenate them and suffix the result
  with a "/"

Notes:

Seems easiest to fix the description, otherwise the worked example is wrong.

RFC 3875, "The Common Gateway Interface (CGI) Version 1.1", October 2004

Source of RFC: INDEPENDENT

Errata ID: 5266
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Denny O'Breham
Date Reported: 2018-02-25

Section 4.1.17 says:

SERVER_SOFTWARE = 1*( product | comment )

It should say:

SERVER_SOFTWARE = 1*( *( SP | HT ) ( product | comment ) )

Notes:

It seems actual usage separates products and comments with spaces such as «Apache/2.4.27 (Win32) OpenSSL/1.1.0f PHP/7.1.9». The definition «1*rule» in section 2.1 doesn't include implicit optional (required?) spaces as a separator.

The proposed definition is backward compatible with the original.

RFC 3986, "Uniform Resource Identifier (URI): Generic Syntax", January 2005

Note: This RFC has been updated by RFC 6874, RFC 7320, RFC 8820

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 4547
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: siva elango ramaswamy
Date Reported: 2015-12-01

Section 5.4.2 says:

5.4.2.  Abnormal Examples

   Although the following abnormal examples are unlikely to occur in
   normal practice, all URI parsers should be capable of resolving them
   consistently.  Each example uses the same base as that above.

   Parsers must be careful in handling cases where there are more ".."
   segments in a relative-path reference than there are hierarchical
   levels in the base URI's path.  Note that the ".." syntax cannot be
   used to change the authority component of a URI.

      "../../../g"    =  "http://a/g"
      "../../../../g" =  "http://a/g"

It should say:

5.4.2.  Abnormal Examples

   Although the following abnormal examples are unlikely to occur in
   normal practice, all URI parsers should be capable of resolving them
   consistently.  Each example uses the same base as that above.

   Parsers must be careful in handling cases where there are more ".."
   segments in a relative-path reference than there are hierarchical
   levels in the base URI's path.  Note that the ".." syntax cannot be
   used to change the authority component of a URI.

      "../../../g"    =  "http://a/../g"
      "../../../../g" =  "http://a/../../g"

Notes:

The example which was taken from RFC 1808 had proper resolved URL ( 5.2 ).

As the base URL has two levels ( http://a/b/c/ ) and if the relative url's have two ".." segments then from the resolved URI both the hierarchical levels can be removed to form the resolved URL, as below:

../../g = http://a/g

and if there are more ".." segments than hierarchical level in base URI's path... then the number of ".." segments that doesn't have corresponding segments in base URI should be left as is in the resolved URI, like below

"../../../g" = "http://a/../g"

Errata ID: 4789
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Dinar Qurbanov
Date Reported: 2016-08-31

Section 5.2.3 says:

   o  If the base URI has a defined authority component and an empty
      path, then return a string consisting of "/" concatenated with the
      reference's path; otherwise,

It should say:

   o  If the base URI has a defined authority component and an empty 
      path, or if the base URI's path is ending with "/..", then return 
      a string consisting of base's path concatenated with "/" and then 
      concatenated with the reference's path; otherwise,

Notes:

this is about case when reference does not have scheme and authority and its path is not starting with "/".

Errata ID: 4942
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: r. de raat
Date Reported: 2017-02-19

Section 3.2.2. Host says:

Such a name consists of a sequence of domain labels separated by ".",
each domain label starting and ending with an alphanumeric character
and possibly also containing "-" characters.  The rightmost domain
label of a fully qualified domain name in DNS may be followed by a
single "." and should be if it is necessary to distinguish between
the complete domain name and some local domain.

   reg-name    = *( unreserved / pct-encoded / sub-delims )

If the URI scheme defines a default for host, then that default

It should say:

Such a name consists of a sequence of domain labels separated by ".",
each domain label starting and ending with an alphanumeric character
and possibly also containing "-" characters.  The rightmost domain
label of a fully qualified domain name in DNS may be followed by a
single "." and should be if it is necessary to distinguish between
the complete domain name and some local domain.

   reg-name    = *( unreserved / pct-encoded / "-" / ".")

If the URI scheme defines a default for host, then that default

Notes:

sub-delims are defined as "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" these are not characters that are allowed in host, domain or tld names, in addition the sub-delims do not sontain the "-" and "."
therefore the reg-name (fully qualified domain name) definition is incorrect

The same issue appears in "Appendix A."

Errata ID: 5428
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Kevin Layer
Date Reported: 2018-07-17

Section 4.2 says:

      relative-part = "//" authority path-abempty
                    / path-absolute
                    / path-noscheme
                    / path-empty

It should say:

      relative-part = "//" authority path-abempty
                    / path-absolute
                    / path-noscheme
		    / path-abempty    ; this was added
                    / path-empty

Notes:

As written, the ABNF excludes "/" being a valid URI. It is hard to believe that href="/" when converted to a URI, would be illegal.

RFC 3995, "Internet Printing Protocol (IPP): Event Notifications and Subscriptions", March 2005

Source of RFC: ipp (app)

Errata ID: 7516
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Tarak Parikh
Date Reported: 2023-05-15

Section 5.3 page 19 says:

   For Pull Delivery Methods, a client MUST supply "notify-recipient-
   uri" and MAY omit any of the rest of the attributes in column 1 of
   Table 1 in a Subscription Creation Request.  For Push Delivery
   Methods, a client MUST supply "notify-pull-method" and MAY omit any
   of the rest of the attributes in column 1 of Table 1 in a
   Subscription Creation Request.  A client MUST NOT supply both
   "notify-recipient-uri" and "notify-pull-method" attributes in the
   same Subscription Creation Request.

It should say:

   For Push Delivery Methods, a client MUST supply "notify-recipient-
   uri" and MAY omit any of the rest of the attributes in column 1 of
   Table 1 in a Subscription Creation Request.  For Pull Delivery
   Methods, a client MUST supply "notify-pull-method" and MAY omit any
   of the rest of the attributes in column 1 of Table 1 in a
   Subscription Creation Request.  A client MUST NOT supply both
   "notify-recipient-uri" and "notify-pull-method" attributes in the
   same Subscription Creation Request.

Notes:

notify-recipient-uri is used for Push notification method and notify-pull-method is used for pull notification method based on the paragraph based on the second paragraph in section 5.3 paragraph 2 "The "notify-recipient-uri" attribute is for use with Push Delivery
Methods. The "notify-pull-method" attribute is for use with Pull
Delivery Methods."
But in 4th Paragraph for client requirements there is a mistake. It mentions pull requires notification-recipient-uri instead of push requires and similarly verbage is wrong for push as well which indicates clients must use notify-pull-method

RFC 4028, "Session Timers in the Session Initiation Protocol (SIP)", April 2005

Source of RFC: sip (rai)

Errata ID: 4744
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Chao Wang
Date Reported: 2016-07-19

Section 3 says:

   A UAC starts by sending an INVITE.  This includes a Supported header
   field with the option tag 'timer', indicating support for this
   extension.

It should say:

   A UAC starts by sending an INVITE.  This includes a Supported header
   field with the option tag 'timer', indicating support for this
   extension.If UAC or UAS knows one negotiation of session timer is 
   ongoing, it SHALL not start a new one.

Notes:

Add one more sentence here "If UAC knows one negotiation of session timer is ongoing, it SHALL not start a new one."
Actually in the scenarios of session set-up or session modification, it is easy to see the message exchange of UPDATE and (re-)INVITE, according to this RFC, both of them are allowed for the negotiation of session timer, the decision shall be taken on their own 200 OK. Normally the negotiation of session time of (re-)INVITE is started at first and the UPDATE's will be taken place, from UAS perspective, it needs to treat two negotiations of session timer in-parallel, since there is no kind of mechanism to protect the parameters carried in (re-)INVITE and UPDATE being inconsistent, it brings a problem on UAS that the result of two negotiations might be different specially for the parameter of refresher and also the inconsistency will cause UAS to meet a conflict while it is deciding the parameters especially for refresher on 200 OK of (re-)INVITE. In order to avoid this problem, it is better to disallow a net negotiation of session timer until the ongoing one is finished.

RFC 4042, "UTF-9 and UTF-18 Efficient Transformation Formats of Unicode", April 2005

Source of RFC: INDEPENDENT

Errata ID: 7868
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Davide Cavagnino
Date Reported: 2024-03-24

Section 2 says:

and codepoints in the range U+1000 - U+10FFFF (remainder of
   [UNICODE]) are represented by three nonets.

It should say:

and codepoints in the range U+10000 - U+10FFFF (remainder of
   [UNICODE]) are represented by three nonets.

Notes:

It seems to me that a 0 is lacking in the definition of a range.

Errata ID: 7869
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Davide Cavagnino
Date Reported: 2024-03-24

Section 4 says:

the range U+E0000 - U+EFFFF are copied as values 0x30000 - 0x3ffff;
   that is, these values are shifted by 0x70000.

It should say:

the range U+E0000 - U+EFFFF are copied as values 0x30000 - 0x3ffff;
   that is, these values are shifted by 0xB0000.

Notes:

It seems to me that the difference between the original and mapped ranges is 0xB0000

RFC 4122, "A Universally Unique IDentifier (UUID) URN Namespace", July 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 4975
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Joseph Boon
Date Reported: 2017-03-22

Section 4.1 says:

The UUID format is 16 octets; some bits of the eight octet variant 
field specified below determine finer structure.

It should say:

The UUID format is 16 octets; some bits of the variant 
field specified below determine finer structure.

Notes:

The original wording implies the variant field is 8 octets long. It is between 1 and 3 bits long. An alternative correction would be:

"The UUID format is 16 octets; some bits of the variant
field in octet 8 specified below determine finer structure."

Errata ID: 5560
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: GLOBAL UUID DATABASE
Date Reported: 2018-11-25

Section 4.1.1 says:

   The following table lists the contents of the variant field, where
   the letter "x" indicates a "don't-care" value.

   Msb0  Msb1  Msb2  Description

    0     x     x    Reserved, NCS backward compatibility.

    1     0     x    The variant specified in this document.

It should say:

   The following table lists the contents of the variant field, where
   the letter "x" indicates a "don't-care" value.

   Msb0  Msb1  Msb2  Description

    0     x     x    Reserved, NCS backward compatibility.

    1     0     0    The variant specified in this document.

Notes:

If Msb2 is a « don't-care » value, this means it's not wrong to set the bit to 0 or 1.
In the case of UUIDv3 and UUIDv5, this does not specify if the bit from the hash output should be left untouched or not.
It's not stated that it's illegal to reset it to 0 when setting Msb0 and Msb1 altogether (as libuuid does), since it's a « don't-care » value.
But letting it untouched whenever it's set to 1 by the hash output (as the Python stdlib does) causes two UUIDv{3,5} to be different for the same input namespaces and data. (Example: NS=Nil UUID, data = 0x44 («D»).

The RFC should enforce the value of the bit to 0 or 1, or clarify if it should be left untouched depending on the context-dependent data (Clock ID {1,2}, hash output {3,5}, random input {4}). (Which would mean it's then just a libuuid bug to forcibly set Msb2 to 0 when it should be untouched.)

See also : https://uuid.pirate-server.com/blog/brother-uuids-or-why-uuids-are-not-unique.html

Errata ID: 6225
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Daniel Marschall
Date Reported: 2020-07-07

Section 4.3 says:

ISO Object IDs (OIDs)

It should say:

Object Identifiers (OIDs)

Notes:

An Object Identifier (OID) is an identification mechanism jointly developed by ITU-T and ISO/IEC.

It makes no sense saying that it is an "ISO OID". Actually, it can be very confusing, because people could think that "ISO OID" means an OID which is a descendant of { iso(1) }, which would exclude OIDs descending from { itu-t(0) } and { joint-iso-itu-t(2) }.

Also in Appendix C, "Name string is an ISO OID" should be changed to "Name string is an OID".

Maybe it would also be good to mention how the OID should be formatted. I guess the intention of the author is the normal dot-notation "2.999" which is passed as ASCII text to the name-based UUID generation function.

RFC 4134, "Examples of S/MIME Messages", July 2005

Source of RFC: smime (sec)

Errata ID: 7125
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Dmitry Baryshkov
Date Reported: 2022-09-11

Section B says:

***5.2.bin***

|* Example 5.2.bin
|>5.2.bin
|MIIBZQYJKoZIhvcNAQcDoIIBVjCCAVICAQIxggEAMIG9AgEAMCYwEjEQMA4GA1UEAxMHQ2
|FybFJTQQIQRjRrx4AAVrwR024uzV1x0DANBgkqhkiG9w0BAQEFAASBgJQmQojGi7Z4IP+C
|VypBmNFoCDoEp87khtgyff2N4SmqD3RxPx+8hbLQt9i3YcMwcap+aiOkyqjMalT03VUC0X
|BOGv+HYI3HBZm/aFzxoq+YOXAWs5xlGerZwTOc9j6AYlK4qXvnztR5SQ8TBjlzytm4V7zg
|+TGrnGVNQBNw47Ewoj4CAQQwDQQLTWFpbExpc3RSQzIwEAYLKoZIhvcNAQkQAwcCAToEGH
|cUr5MSJ/g9HnJVHsQ6X56VcwYb+OfojTBJBgkqhkiG9w0BBwEwGgYIKoZIhvcNAwIwDgIC
|AKAECJwE0hkuKlWhgCBeKNXhojuej3org9Lt7n+wWxOhnky5V50vSpoYRfRRyw==
|<5.2.bin

It should say:

***5.2.bin***

|* Example 5.2.bin
|>5.2.bin
|MIIBIwYJKoZIhvcNAQcDoIIBFDCCARACAQAxgcAwgb0CAQAwJjASMRAwDgYDVQQDEwdDYX
|JsUlNBAhBGNGvHgABWvBHTbi7NXXHQMA0GCSqGSIb3DQEBAQUABIGAhUK+4wsu5Q8JqiTK
|3trB0wm4Jysly9Vx+8mc2/CybqCKXxydSu2YnRU5JgEaLmvwRDmJNzxvx0phCwsnd6r51J
|ek0iE/wj8g1NwQ6dY/ANucgkfWfpb/Em6HhKC67YEPVm2mHeurw7ehufhfi8wbSuUUNgZh
|0MdkX2lnkalQ7tgwSAYJKoZIhvcNAQcBMBkGCCqGSIb3DQMCMA0CAToECOhwgeLvxRVXgC
|AGUwp7jVwWDczVdtaLWdZFjBoaDOYe895DVgCbQIw4XQ==
|<5.2.bin

Notes:

The base64 encoding in the Appending B doesn't correspond to the data in the section 5.2. Provided base64 was generated using data in the section 5.2 instead.

RFC 4180, "Common Format and MIME Type for Comma-Separated Values (CSV) Files", October 2005

Note: This RFC has been updated by RFC 7111

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 5345
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Abed BenBrahim
Date Reported: 2018-04-30

Section 2 says:

6.  Fields containing line breaks (CRLF), double quotes, and commas 
should be enclosed in double-quotes.

It should say:

6.  Fields containing line breaks (CRLF), double quotes, and commas 
must be enclosed in double-quotes.

Notes:

CSV is clearly unparsable if commas are not enclosed in double quotes.

Errata ID: 6230
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Marco Diniz Sousa
Date Reported: 2020-07-13

Section 2 says:

The last record in the file may or may not have an ending line break.

file = [header CRLF] record *(CRLF record) [CRLF]

It should say:

The last record in the file must have an ending line break.

file = [header CRLF] record *(CRLF record) CRLF

Notes:

The grammar seems to be ambiguous in the case below:
- Records have just one field;
- The last record may have an empty value.

File:
---
header1CRLF
aCRLF
bCRLF
EOF
---

In the file above, we do not know if we have four records (header1, a, b and an empty value) with the last record not ending with a line break; or if we have three records (header1, a and b) with the last record ending with a line break.

The grammar allows empty fields:
non-escaped = *TEXTDATA

According to RFC 2234:
"Default values are 0 and infinity so that *<element> allows any number, including zero;"

Errata ID: 7572
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Robert Hairgrove
Date Reported: 2023-07-24

Section 7.2 Informative Ref says:

[4]  Repici, J., "HOW-TO: The Comma Separated Value (CSV) File
        Format", 2004,
        <http://www.creativyst.com/Doc/Articles/CSV/CSV01.htm>.

It should say:

[4]  Repici, J., "HOW-TO: The Comma Separated Value (CSV) File
        Format", 2004-2010,
        <https://www.creativyst.com/Doc/Articles/CSV/CSV01.shtml>.

Notes:

Suggested corrected text updates the link which uses the TLS-conforming URL for the creativyst.com site and the date range of publication. It seems that some browsers might not cleanly redirect to the HTTPS address.

RFC 4226, "HOTP: An HMAC-Based One-Time Password Algorithm", December 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 5129
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Gerrit Jansen van Vuuren
Date Reported: 2017-09-27

Section Appendix D says:

Count    Hexadecimal    Decimal        HOTP
   0        4c93cf18       1284755224     755224
   1        41397eea       1094287082     287082
   2         82fef30        137359152     359152
   3        66ef7655       1726969429     969429
   4        61c5938a       1640338314     338314
   5        33c083d4        868254676     254676
   6        7256c032       1918287922     287922
   7         4e5b397         82162583     162583
   8        2823443f        673399871     399871
   9        2679dc69        645520489     520489

It should say:

Count     Hexadecimal    Decimal        HOTP
   0         4c93cf18      1284755224    755224
   1         75a48a19      1973717529    717529
   2         bacb7fa       195868666     868666
   3         66c28227      1724023335    023335
   4         2904c900      688179456     179456
   5         237e783d      595490877     490877
   6         3c9cd285      1016910469    910469
   7         24fb960c      620467724     467724
   8         1b3c89f6      456952310     952310
   9         16374098      372719768     719768

Notes:

From https://www.ietf.org/rfc/rfc4226.txt, Appendix D, page 31

a. There is no mention of the parameters that were used to run the reference implementation to provide to test data. These should be:

codeDigits: 6, addCheckSum: false, truncationOffset: 0.

b. The hashes correspond. And the first row of Table2 (i.e for Count==0) correspond, but for Count 1...9 the values for Hex, Decimal and Hotp do not correspond with the values of the reference implementation.

I am using JDK 1.8.0_144

As a test I have done a copy and paste 'as is' from the reference implementation and run it with sysout statements to print the truncation and otp values for each counter.

The only changes made are: System.out and use of counter=movingFactor to print the movingFactor. None of which alter the logic. Note the differences in test data were found before adding the debug info.

Please see:
https://github.com/gerritjvv/cryptoplayground/tree/master/hmac/java/hmac/src/test/java/org/funsec/hmac

UnitTest method:
https://github.com/gerritjvv/cryptoplayground/blob/master/hmac/java/hmac/src/test/java/org/funsec/hmac/HTOPTest.java#L83

Reference Impl:
https://github.com/gerritjvv/cryptoplayground/blob/master/hmac/java/hmac/src/test/java/org/funsec/hmac/HOTPRef.java

Errata ID: 6756
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Nicholas Gaya
Date Reported: 2021-11-28

Section 5.3 says:

Let OffsetBits be the low-order 4 bits of String[19]

It should say:

Let OffsetBits be the low-order 4 bits of the last byte of String

Notes:

This change does not affect the computation for 20-byte HMAC-SHA-1 digests. However when using the HMAC-SHA-256 or HMAC-SHA-512 functions as suggested in RFC-6238, the 19th byte and the last byte may differ.

The proposed change matches the reference implementations of both RFC-4226 and RFC-6238 and removes potential ambiguity as to whether implementations should use the 19th byte or the last byte of the digest to determine the offset for dynamic truncation.

Errata ID: 6702
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Darian Miller
Date Reported: 2021-10-03

Section 5.2 says:

The Key (K), the Counter (C), and Data values are hashed high-order byte first.

It should say:

When hashing, the Key (K) value is provided in little-endian format while the Counter (C) value is in big-endian format.

Notes:

This byte reversal for the Counter (movingFactor) value is indeed demonstrated in the RFC's reference implementation code within Appendix C but this fact is not mentioned within RFC text body.

byte[] text = new byte[8];
for (int i = text.length - 1; i >= 0; i--) {
text[i] = (byte) (movingFactor & 0xff);
movingFactor >>= 8;
}


This specific issue is called out in a related wikipedia article:
https://en.wikipedia.org/wiki/HMAC-based_one-time_password: "counter must be big endian"


This can also be verified by looking at archived source of Google Authenticator on GitHub: https://github.com/google/google-authenticator/blob/51781910ae2bb1abf8ac51b290272f86f3651235/mobile/ios/Classes/OTPGenerator.m

Related code snippet:
(counter = NSSwapHostLongLongToBig(counter);)


FreeOTP also reverses the byte order of the counter
https://github.com/freeotp/freeotp-android/blob/eb2f12f33a38235433fd83e0ad3eb15affae871f/app/src/main/java/org/fedorahosted/freeotp/Token.java

code comment "// Encode counter in network byte order"
The code uses a Byte buffer which defaults to big_endian order.

Errata ID: 7651
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ashley R. Thomas
Date Reported: 2023-09-21

Section 5.3 says:

   The Truncate function performs Step 2 and Step 3, i.e., the dynamic
   truncation and then the reduction modulo 10^Digit.  The purpose of
   the dynamic offset truncation technique is to extract a 4-byte
   dynamic binary code from a 160-bit (20-byte) HMAC-SHA-1 result.

    DT(String) // String = String[0]...String[19]
     Let OffsetBits be the low-order 4 bits of String[19]
     Offset = StToNum(OffsetBits) // 0 <= OffSet <= 15
     Let P = String[OffSet]...String[OffSet+3]
     Return the Last 31 bits of P

It should say:

   The Truncate function performs Step 2 and Step 3, i.e., the dynamic
   truncation and then the reduction modulo 10^Digit.  The purpose of
   the dynamic offset truncation technique is to extract a 4-byte
   dynamic binary code from a 160-bit (20-byte) HMAC-SHA-1 result.

    DT(String) // String = String[0]...String[19]
     Let OffsetBits be the low-order 4 bits of String[19]
     Offset = StToNum(OffsetBits) // 0 <= OffSet <= 15
|    Let P = String[Offset*8]...String[Offset*8+31]
     Return the Last 31 bits of P

Notes:

The uncorrected text uses String as a byte string amidst correct uses of it as a bit string. Section 5.1. clearly states, "A string always means a binary string, meaning a sequence of zeros and ones." The RFC seems to intend that either "string" or "String" is a bit string, not a byte string, so the use of "String" as a byte string in the uncorrected text seems incorrect, out of place, as if a typo.

Another apparent typo is use of camel case "OffSet" instead of simply "Offset". There is no distinction within the RFC that camel case "OffSet" has any meaning beyond another spelling for "Offset".

Thank you for considering this erratum and for this very straightforward, easy to understand, positively impactful RFC.

RFC 4235, "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", November 2005

Note: This RFC has been updated by RFC 7463, RFC 8996

Source of RFC: sipping (rai)

Errata ID: 4237
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Xiaofeng Xu
Date Reported: 2015-01-19

Section 4.4 says:

<xs:complexType name="participant">
          <xs:sequence>
            <xs:element name="identity" type="tns:nameaddr"
              minOccurs="0" maxOccurs="1"/>
            <xs:element name="target" minOccurs="0" maxOccurs="1">
              <xs:complexType>
                <xs:sequence>
                  <xs:element name="param" minOccurs="0"
                    maxOccurs="unbounded">
                    <xs:complexType>
                      <xs:attribute name="pname" type="xs:string"
                        use="required"/>
                      <xs:attribute name="pval" type="xs:string"
                        use="required"/>
                    </xs:complexType>
                  </xs:element>
                </xs:sequence>
                <xs:attribute name="uri" type="xs:string"
                                           use="required"/>
              </xs:complexType>
            </xs:element>
            <xs:element name="session-description" type="tns:sessd"
              minOccurs="0" maxOccurs="1"/>
            <xs:element name="cseq" type="xs:nonNegativeInteger"
              minOccurs="0" maxOccurs="1"/>
            <xs:any namespace="##other" processContents="lax"
              minOccurs="0" maxOccurs="unbounded"/>
          </xs:sequence>
        </xs:complexType>

It should say:

<xs:complexType name="participant">
          <xs:sequence>
            <xs:element name="identity" type="tns:nameaddr"
              minOccurs="0" maxOccurs="unbounded"/>
            <xs:element name="target" minOccurs="0" maxOccurs="1">
              <xs:complexType>
                <xs:sequence>
                  <xs:element name="param" minOccurs="0"
                    maxOccurs="unbounded">
                    <xs:complexType>
                      <xs:attribute name="pname" type="xs:string"
                        use="required"/>
                      <xs:attribute name="pval" type="xs:string"
                        use="required"/>
                    </xs:complexType>
                  </xs:element>
                </xs:sequence>
                <xs:attribute name="uri" type="xs:string"
                                           use="required"/>
              </xs:complexType>
            </xs:element>
            <xs:element name="session-description" type="tns:sessd"
              minOccurs="0" maxOccurs="1"/>
            <xs:element name="cseq" type="xs:nonNegativeInteger"
              minOccurs="0" maxOccurs="1"/>
            <xs:any namespace="##other" processContents="lax"
              minOccurs="0" maxOccurs="unbounded"/>
          </xs:sequence>
        </xs:complexType>

Notes:

The identity element is defined as maxOccurs="1" in the XML schema. However, in the section 4.1.6 of RFC4235, it says "Note that multiple identities (for example a sip: URI and a tel: URI) could be included if they all correspond to the participant". This seems to contradict with the XML schema.

RFC 4291, "IP Version 6 Addressing Architecture", February 2006

Note: This RFC has been updated by RFC 5952, RFC 6052, RFC 7136, RFC 7346, RFC 7371, RFC 8064

Source of RFC: ipv6 (int)

Errata ID: 5716
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Dennis Ferguson
Date Reported: 2019-05-01

Section 2.5 says:

   A slightly sophisticated host (but still rather simple) may
   additionally be aware of subnet prefix(es) for the link(s) it is
   attached to, where different addresses may have different values for
   n:

It should say:

   For Link-Local unicast addresses, which comprise a flat address
   space that is reused on every link, the consideration above is all
   that is relevant. For Global Unicast addresses, however, a slightly
   sophisticated host (but still rather simple) may additionally be
   aware of subnet prefix(es) for the link(s) it is attached to, where
   different addresses may have different values for n:

Notes:

Text in several sections of 4291 seem to be logically inconsistent with respect to Link-Local unicast addresses. The inconsistency spans Sections 2.1, 2.5 and 2.5.6.

Section 2.5 says that unicast addresses, including Link-Local unicast addresses, on links a host is attached to have the following internal structure, providing a definition for "subnet prefix":

| n bits | 128-n bits |
+-------------------------------+---------------------------------+
| subnet prefix | interface ID |
+-------------------------------+---------------------------------+

Section 2.5.6 specifies that Link-Local unicast addresses have the following format:

| 10 |
| bits | 54 bits | 64 bits |
+----------+-------------------------+----------------------------+
|1111111010| 0 | interface ID |
+----------+-------------------------+----------------------------+

Applying the Section 2.5 definition, Link-Local unicast addresses hence have a subnet prefix of fe80::/64 on every link.

Section 2.1 says this about the addressing model:

Currently, IPv6 continues the IPv4 model in that a subnet prefix is
associated with one link.

Clearly the use of a same Link-Local unicast subnet prefix on every link is inconsistent with an addressing model that requires a subnet prefix to be unique to one link. The plain reading of this text is that it disagrees with itself, so either something needs to change to bring it into agreement or some explanation of how this is in fact consistent needs to be made. Since I don't know what the intent of this was I don't really know what needs fixing.

The proposed text hence reflects my personal biases; while I understand subnet prefix uniqueness to be foundational to the forwarding behaviour of Global Unicasts I have no idea what a "subnet prefix" even means in the context of Link-Local unicasts. The proposed text hence modifies Section 2.5 to exclude Link-Local addresses from the part of that section defining a "subnet prefix" and instead be defines them to provide a flat address space that is reused on every link. That is, Link-Local addresses are defined without a subnet prefix.

This leaves the Section 2.1 statement about subnet prefixes, and the forwarding behaviour implied by that, applicable to Global Unicast addresses but inapplicable to Link-Local addresses. Given this Section 2.5.6 can be read to be solely a constraint on Link-Local address construction, i.e. requiring SLAAC and other methods of Link-Local configuration to only produce addresses from that subset, without any implication for forwarding behaviour that "subnet prefix" might suggest.

That this general topic seems to produce periodic flurries of concern might be an indication that greater clarity in specification here might be useful.

Errata ID: 6596
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin D Kealey
Date Reported: 2021-06-03

Section 2.2 says:

   2. Due to some methods of allocating certain styles of IPv6
      addresses, it will be common for addresses to contain long strings
      of zero bits.  In order to make writing addresses containing zero
      bits easier, a special syntax is available to compress the zeros.
      The use of "::" indicates one or more groups of 16 bits of zeros.
      The "::" can only appear once in an address.  The "::" can also be
      used to compress leading or trailing zeros in an address.

It should say:

EITHER

   2. Due to some methods of allocating certain styles of IPv6
      addresses, it will be common for addresses to contain long strings
      of zero bits.  In order to make writing addresses containing zero
      bits easier, a special syntax is available to compress the zeros.
      The use of "::" indicates one or more "0" pieces, or two or more when
      leading or trailing. The "::" can only appear once in an address.

OR

   2. Due to some methods of allocating certain styles of IPv6
      addresses, it will be common for addresses to contain long strings
      of zero bits.  In order to make writing addresses containing zero
      bits easier, a special syntax is available to compress the zeros.
      The use of "::" indicates one or more pieces of 16 bits of zeros,
      or two or more when leading or trailing. The "::" can only appear
      once in an address.

Notes:

1. The existing wording would permit "::" to be used in leading or trailing position to compress a single 16-bit piece, leading to the conclusion that "::0:0:0:0:0:0:1" is a valid way to write the loopback address, with eight colons.

Many consumers of textual IPv6 addresses would reject this out of hand as "too many colons", and it seems questionable that such an interpretation was ever intended. Enforcing this on producers would improve interoperability.

2. The preceding paragraphs defines "piece", but the undefined term "group" is used in this paragraph, so by changing that term I hope to clarify that this is a textual substitution, necessarily aligned to a multiple of 16 bits.

I am uncomfortable with the phrasing "pieces of 16 bits of zeros", but I offer it as a single-word change to effect my point (2); I leave it to the discretion of the editor which of my alternatives to adopt.

RFC 4402, "A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism", February 2006

Note: This RFC has been obsoleted by RFC 7802

Source of RFC: kitten (sec)

Errata ID: 3888
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Benjamin Kaduk
Date Reported: 2014-02-12

Section 2 says:

PRF+(K, L, S) = truncate(L, T1 || T2 || .. || Tn)

It should say:

PRF+(K, L, S) = truncate(L, T0 || T1 || .. || Tn)

Notes:

Implementors have started the counter for the PRF+ construction at 0, not 1.

RFC 4443, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", March 2006

Note: This RFC has been updated by RFC 4884

Source of RFC: ipv6 (int)

Errata ID: 6153
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Töma Gavrichenkov
Date Reported: 2020-05-01

Section 3.1 says:

3.1.  Destination Unreachable Message

   [..]

   If the reason for the failure to deliver is that the destination is
   beyond the scope of the source address, the Code field is set to 2.
   This condition can occur only when the scope of the source address is
   smaller than the scope of the destination address (e.g., when a
   packet has a link-local source address and a global-scope destination
   address) and the packet cannot be delivered to the destination
   without leaving the scope of the source address.

It should say:

3.1.  Destination Unreachable Message

   [..]

   If the reason for the failure to deliver is that the destination is
   beyond the scope zone of the source address, the Code field is set to
   2.  The scope zone of the destination address is determined by the
   scope of the address and arrival interface of the packet, as specified
   in [IPv6-SCOPE, Section 9].  Similarly, the scope zone of the source
   address is determined by the scope of the address and arrival
   interface of the packet.  This condition can occur only when
   transmitting the packet on the chosen next-hop interface would cause
   the packet to leave the zone of the source address, i.e., cross a zone
   boundary of the scope of the source address.

7.1.  Normative References

   [..]

   [IPv6-SCOPE] Deering, S., Haberman, B., Jinmei, T., Nordmark, E.,
                and B. Zill, "IPv6 Scoped Address Architecture", RFC
                4007, March 2005.   

Notes:

https://tools.ietf.org/html/rfc4007#section-9

Scope zone is not scope.

Consider a case when the source IP is link-local and the destination is global, yet the routing happens in the same VLAN. Per RFC 4007, the packet should be transmitted; however, RFC 4443 allows for an ambiguity which is already causing vendors to reject packets in this case.

RFC 4452, "The "info" URI Scheme for Information Assets with Identifiers in Public Namespaces", April 2006

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 7674
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Fabian Cohen
Date Reported: 2023-10-11

Section 4.1 says:

info-URI        = info-scheme ":" info-identifier [ "#" fragment ]

It should say:

info-URI        = info-scheme ":" info-identifier [ "#" Absolute]

Notes:

In practice, it is possible to generate a URI reference to a relative path of a web service. But in many cases, problems exist in resolving names and reverse name resolution.

Problems exist in the journal/truncated information of the relative URL (e.g., thomas-signe.co).

Good practice/compliance is to use the absolute path and correct reference in the Root Domain and reverse lookup.

RFC 4458, "Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR)", April 2006

Note: This RFC has been updated by RFC 8119

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rai

Errata ID: 4266
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Franz Edler
Date Reported: 2015-02-09

Section 2.2 Cause says:

                +---------------------------------+-------+
                | Redirecting Reason              | Value |
                +---------------------------------+-------+
                | Unknown/Not available           | 404   |
                | User busy                       | 486   |
                | No reply                        | 408   |
                | Unconditional                   | 302   |
                | Deflection during alerting      | 487   |
                | Deflection immediate response   | 480   |
                | Mobile subscriber not reachable | 503   |
                +---------------------------------+-------+

It should say:

                +---------------------------------+-------+
                | Redirecting Reason              | Value |
                +---------------------------------+-------+
                | Unknown                         | 404   |
                | User busy                       | 486   |
                | No reply                        | 408   |
                | Not available                   | 503   |
                | Unconditional                   | 302   |
                | Deflection during alerting      | 487   |
                | Deflection immediate response   | 480   |
                | Mobile subscriber not reachable | 503   |
                +---------------------------------+-------+

Notes:

The two redirect reasons "Unknown" and "Not available" are totally different in their meaning. In the first case the user is unknown, whereas in the second case it is a valid address but not reachable.

Unfortunately 3GPP TS 24.604 "Communication Diversion" refers to RFC 4458 and in case of "communication forwarding not logged in" it therefore requests cause value 404 in the meaning of "not available". This cause value is mapped to "unknown" in interworking SIP to ISUP (3GPP TS 29.163 Table 7.4.6.2.2.4) and therefore a missed call notification cannot be sent to a subscriber which is not logged in.

"Not available" should use the same value as "Mobile subscriber not reachable".

RFC 4470, "Minimally Covering NSEC Records and DNSSEC On-line Signing", April 2006

Source of RFC: dnsext (int)

Errata ID: 6734
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Andrews
Date Reported: 2021-11-12

Section 4 says:

   The first of these NSEC RRs proves that no exact match for
   foo.example.com exists, and the second proves that there is no
   wildcard in example.com.

It should say:

TBD

Notes:

"the second proves that there is no wildcard in example.com" is incorrect.

\)\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG )

Actually proves that *.example.com exists as it is part of the next field. It is an empty non-terminal wildcard. '\000.domain' can only be used to prove no data exists at 'domain', not that 'domain' doesn't exist.

RFC 4506, "XDR: External Data Representation Standard", May 2006

Source of RFC: nfsv4 (wit)

Errata ID: 6382
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ed Schouten
Date Reported: 2021-01-08

Section 6.3 says:

      declaration:
           type-specifier identifier
         | type-specifier identifier "[" value "]"
         | type-specifier identifier "<" [ value ] ">"
         | "opaque" identifier "[" value "]"
         | "opaque" identifier "<" [ value ] ">"
         | "string" identifier "<" [ value ] ">"
         | type-specifier "*" identifier
         | "void"

[...]

      struct-body:
         "{"
            ( declaration ";" )
            ( declaration ";" )*
         "}"

[...]

      type-def:
           "typedef" declaration ";"
         | "enum" identifier enum-body ";"
         | "struct" identifier struct-body ";"
         | "union" identifier union-body ";"

It should say:

None

Notes:

This grammar permits statements like:

typedef void;
struct foo { void; };

rpcgen doesn't allow this, failing with the following error message:

voids allowed only inside union and program definitions with one argument

Errata ID: 7101
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Dylan Allbee
Date Reported: 2022-08-21

Section 4.3 says:

Enumerations have the same representation as signed integers.
Enumerations are handy for describing subsets of the integers.
Enumerated data is declared as follows:

    enum { name-identifier = constant, ... } identifier;

For example, the three colors red, yellow, and blue could be
described by an enumerated type:

    enum { RED = 2, YELLOW = 3, BLUE = 5 } colors;

It should say:

...

    enum identifier { name-identifier = constant, ... } ;
         ^^^^^^^^^^

...

    enum colors { RED = 2, YELLOW = 3, BLUE = 5 } ;
         ^^^^^^ 

Notes:

The grammar for this definition, as specified in 6.3, is:

type-def:
"typedef" declaration ";"
| "enum" identifier enum-body ";"
| "struct" identifier struct-body ";"
| "union" identifier union-body ";"

It is unclear whether the original intent was for identifies to precede or succeed the definition bodies. The example in section 7 shows: enum filekind { ... }

And several RFCs which depend on 4506 have also followed that pattern, such as this example from RFC 5531, section 8.2: enum auth_flavor { ... }

RFC 4511, "Lightweight Directory Access Protocol (LDAP): The Protocol", June 2006

Source of RFC: ldapbis (app)

Errata ID: 5292
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Markus Ansmann
Date Reported: 2018-03-21

Section 4.5.1/Appx.B says:

Filter ::= CHOICE {
and [0] SET SIZE (1..MAX) OF filter Filter,
or [1] SET SIZE (1..MAX) OF filter Filter,
not [2] Filter,

It should say:

Filter ::= CHOICE {
and [0] SET SIZE (1..MAX) OF filter Filter,
or [1] SET SIZE (1..MAX) OF filter Filter,
not [2] EXPLICIT Filter,

Notes:

As currently written, the specification requires IMPLICIT tagging for the not-filter. This, according to ITU-T X.690, Section 8.14.3, Example "Type5", requires the [2]-tag of the not-filter to overwrite the tag of the negated filter, making reliable identification of the type of the negated filter impossible. Thus, the definition of the not-filter needs to specify EXPLICIT tagging. Alternatively, the filter could be specified as

not [2] SEQUENCE { filter Filter },

or (to match the definition of "and" and "or")

not [2] SET SIZE (1..1) OF filter Filter,

This applies to both, Section 4.5.1 and Appendix B.

RFC 4556, "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", June 2006

Note: This RFC has been updated by RFC 6112, RFC 8062, RFC 8636

Source of RFC: krb-wg (sec)

Errata ID: 3820
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nicolas Williams
Date Reported: 2013-12-05

Section 3.2.2 says:

      The type of the otherName field is AnotherName.  The type-id field
      of the type AnotherName is id-pkinit-san:

       id-pkinit-san OBJECT IDENTIFIER ::=
         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
           x509SanAN (2) }

It should say:

      The type of the otherName field is AnotherName.  The type-id field
      of the type AnotherName is id-kerberos-san:

       id-kerberos-san OBJECT IDENTIFIER ::=
         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
           x509SanAN (2) }

Notes:

The certificate subject alternative name (SAN) type added by RFC4556 is and has been used more generically than its symbolic name denotes.

Note that there is no risk in using id-pkinit-san for non-PKINIT purposes as presence of that SAN is -naturally- insufficient by itself to cause an AS to issue a ticket to the client for the named principal. RFC4556 is quite clear on this point.

Therefore id-pkinit-san should have been named id-kerberos-san, and should be referred to as id-kerberos-san going forward. (If there was a registry of PKIX certificate extensions we would additionally ask IANA to updte it.)

There are a few other mentions of id-pkinit-san in RFC4556, all of which should read id-kerberos-san instead.

RFC 4566, "SDP: Session Description Protocol", July 2006

Note: This RFC has been obsoleted by RFC 8866

Source of RFC: mmusic (rai)

Errata ID: 5595
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Gavin Scallan
Date Reported: 2019-01-08

Section 5 says:

An example SDP description is:

      v=0
      o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
      s=SDP Seminar
      i=A Seminar on the session description protocol
      u=http://www.example.com/seminars/sdp.pdf
      e=j.doe@example.com (Jane Doe)
      c=IN IP4 224.2.17.12/127
      t=2873397496 2873404696
      a=recvonly
      m=audio 49170 RTP/AVP 0
      m=video 51372 RTP/AVP 99
      a=rtpmap:99 h263-1998/90000

It should say:

An example SDP description is:

      v=0
      o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
      s=SDP Seminar
      i=A Seminar on the session description protocol
      u=http://www.example.com/seminars/sdp.pdf
      e=j.doe@example.com (Jane Doe)
      c=IN IP4 224.2.17.12/127
      a=recvonly
      t=2873397496 2873404696
      m=audio 49170 RTP/AVP 0
      m=video 51372 RTP/AVP 99
      a=rtpmap:99 h263-1998/90000

Notes:

In section 5 it indicates that the SDP lines MUST appear in the exact order given at the top of Page 9.
The order that is shown indicates that the Session Attributes appear before the Time Description.

However in the example included in this section which explains that Media Attributes have precedence over Session Attributes for a media stream contradicts the order as the Session Attribute of sendonly is included below the Time Description.

Either the example is incorrect, or the normative description is poorly explained and some variability in the order of lines in the SDP is allowed.

Errata ID: 6022
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Megan Ruggiero
Date Reported: 2020-03-16

Section 9 says:

   ; sub-rules of 'e=', see RFC 2822 for definitions
   email-address        = address-and-comment / dispname-and-address
                          / addr-spec
   address-and-comment  = addr-spec 1*SP "(" 1*email-safe ")"
   dispname-and-address = 1*email-safe 1*SP "<" addr-spec ">"

   ; sub-rules of 'p='
   phone-number =        phone *SP "(" 1*email-safe ")" /
                         1*email-safe "<" phone ">" /
                         phone

It should say:

   ; sub-rules of 'e=', see RFC 2822 for definitions
   email-address        = address-and-comment / dispname-and-address
                          / addr-spec
   address-and-comment  = addr-spec 1*SP "(" 1*email-safe ")"
   dispname-and-address = 1*email-safe 1*SP "<" addr-spec ">"

   ; sub-rules of 'p='
   phone-number =        phone *SP "(" 1*email-safe ")" /
                         1*email-safe 1*SP "<" phone ">" /
                         phone

Notes:

There's an inconsistency between the definitions of dispname-and-address and phone-number. I am not sure if this is intentional or not, and in practice this doesn't change what's matched (as email-safe includes spaces), but I thought it'd be worth mentioning since I myself got tripped up when translating the grammar.

Alternatively, perhaps 1*SP should be removed from dispname-and-address.

RFC 4568, "Session Description Protocol (SDP) Security Descriptions for Media Streams", July 2006

Source of RFC: mmusic (rai)

Errata ID: 6291
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: David Nguyen
Date Reported: 2020-09-16

Section 7.1.4 says:

If the offerer includes an IP address and/or port that differs from
   that used previously for a media stream (or FEC stream), the offerer
   MUST include a new master key with the offer (and in so doing, it
   will be creating a new crypto context where the ROC is set to zero).      
   Similarly, if the answerer includes an IP address and/or port that
   differs from that used previously for a media stream (or FEC stream),
   the answerer MUST include a new master key with the answer (and hence
   create a new crypto context with the ROC set to zero).  The reason
   for this is that when the answerer receives an offer or the offerer
   receives an answer with an updated IP address and/or port, it is not
   possible to determine if the other side has access to the old crypto
   context parameters (and in particular the ROC).  For example, if one
   side is a decomposed media gateway, or if a SIP back-to-back user
   agent is involved, it is possible that the media endpoint changed and
   no longer has access to the old crypto context.  By always requiring
   a new master key in this case, the answerer/offerer will know that
   the ROC is zero for this offer/answer, and any key lifetime
   constraints will trivially be satisfied too.  Another consideration
   here applies to media relays; if the relay changes the media endpoint
   on one side transparently to the other side, the relay cannot operate
   as a simple packet reflector but will have to actively engage in SRTP
   packet processing and transformation (i.e., decryption and re-
   encryption, etc.).
Finally, note that if the new offer is rejected, the old crypto
   parameters remain in place.

Notes:

(and in so doing, it
will be creating a new crypto context where the ROC is set to zero).
-Which crypto context for which direction? Logically this would be the crypto context for media towards the new IP address ?

(and hence
create a new crypto context with the ROC set to zero).
-What if the offerer stays the same and only the answerer changes the IP address?
New crypto context in direction towards new IP address?

By always requiring
a new master key in this case, the answerer/offerer will know that
the ROC is zero for this offer/answer,
-Is this resetting crypto context for both directions of media flow?

Is this section based on having offer and answerer both change the IP address.
What if the offerer did not change the IP address but the answerer does change it.
What is the expected behavior for media/crypto context/ROC for both sides?

What is expected for IP address of 0.0.0.0 for hold, should this reset crypto context as well?

How should all of this be handled for the case of switching to MoH server and then back to original call?
SBC ------------- CUCM ------------ EXP (signaling)
SBC --------------------------------- EXP (media stream 1)
SBC --------------------------------- MOH (media stream 2)

SBC ------------- CUCM ------------ EXP
<--------------------SDP with IP1ofEXP part of early offer from SBC
Crypto context for media towards EXP
<--------------------SDP with IP2ofMoH part of delayed offer from CUCM and additional early offer CUCM. CUCM initiates MoH signaling towards SBC.
Crypto context for media towards MoH (only SBC and MoH know about this)
<--------------------SDP with IP1ofEXP part of delayed offer from CUCM
Crypto context for media towards EXP. Should this be the same as the original if SSRC did not change for media from SBC towards Expressway?

Errata ID: 6808
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Fritz
Date Reported: 2022-01-05

Section 9.2 says:

srtp-crypto-suite   = "AES_CM_128_HMAC_SHA1_32" /
                            "F8_128_HMAC_SHA1_32" /
                            "AES_CM_128_HMAC_SHA1_80" /
                            srtp-crypto-suite-ext

It should say:

srtp-crypto-suite   = "AES_CM_128_HMAC_SHA1_32" /
                            "F8_128_HMAC_SHA1_80" /
                            "AES_CM_128_HMAC_SHA1_80" /
                            srtp-crypto-suite-ext

Notes:

Section 6.2.3 uses 80 bit for F8 (IANA registration)

RFC 4592, "The Role of Wildcards in the Domain Name System", July 2006

Source of RFC: dnsext (int)

Errata ID: 5119
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Karst Koymans
Date Reported: 2017-09-21

Section 4.7 says:

4.7.  NSEC RRSet at a Wildcard Domain Name

   Wildcard domain names in DNSSEC signed zones will have an NSEC RRSet.
   Synthesis of these records will only occur when the query exactly
   matches the record.  Synthesized NSEC RRs will not be harmful as they
   will never be used in negative caching or to generate a negative
   response [RFC2308].

It should say:

4.7.  NSEC RRSet at a Wildcard Domain Name

   Wildcard domain names in DNSSEC signed zones will have an NSEC RRSet.
   NSEC RRSets must not be synthesized from this wildcard NSEC.

Notes:

Synthesizing these records would destroy the semantics of the NSEC chain and could be very harmful if implementations would cache them and use them for "Aggressive Use of DNSSEC-Validated Cache" (RFC 8198).

RFC 4645, "Initial Language Subtag Registry", September 2006

Source of RFC: ltru (app)

Errata ID: 7605
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Timothy McSweeney
Date Reported: 2023-08-16

Section 3 says:

The IANA language subtag registry can be found at
   <http://www.iana.org/numbers.html> under "Language Tags".

It should say:

The IANA language subtag registry can be found at
   <https://www.iana.org/protocols> under "Language Tags", or
    <https://www.iana.org/assignments/language-tags/language-tags.xhtml>

Notes:

Language tags and sub tags are obsolete

RFC 4648, "The Base16, Base32, and Base64 Data Encodings", October 2006

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 4889
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Umberto Rustichelli
Date Reported: 2016-12-14

Section 6 says:

When fewer than 40 input bits
are available in an input group, bits with value zero are added (on
the right) to form an integral number of 5-bit groups.

It should say:

When fewer than 40 input bits
are available in an input group, bits with value zero are added (on
the right) to form an integral number of 8-bit groups.

Notes:

8-bit instead of 5-bit.
What follows the correction clearly shows that the final input group must be 8, 16, 24, 32 or 40 bit long, that is, a multiple of 8, not of 5.
Also examples of commonly-used Base32 encoders/decoders seem to show this behaviour.
Also, I would not say "When fewer than 40 input bits are available in an input group" but rather "When fewer than 40 input bits are available in the final input group", to better clarify and not to change the subject ambiguously, unless this is intentionally applicable to any input lot.

RFC 4707, "Netnews Administration System (NAS)", October 2006

Source of RFC: INDEPENDENT

Errata ID: 5817
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2019-08-18

Section 6.3.3.3 says:

   date-answer =  "511" [answertext] CRLF
                  text CRLF
                  "." CRLF

It should say:

   date-answer =  "511" [answertext] CRLF
                  [1*text CRLF]
                  "." CRLF

Notes:

I suggest [1*text CRLF] that is to say a possible non-empty line.
We need at least *text anyway (several characters), as shown in the example in Section 6.3.3.3.

Errata ID: 5820
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2019-08-18

Section 6.3.3.5 says:

   quit-answer = "201" [answertext] CRLF

It should say:

   quit-answer = "201" [answertext] CRLF
                 [1*text CRLF]
                 "." CRLF

Notes:

The QUIT command is the only one whose answer does not follow the general ABNF description of answers requiring them to end with a ("." CRLF) line.
I suggest either fixing quit-answer to the above corrected text, or modifying Section 6.1.1 to take into account a special case for QUIT.

Errata ID: 5824
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2019-08-18

Throughout the document, when it says:

Section 6.3.3.8:

   hier-answer =/ "510" [answertext] CRLF
                  *(text CRLF)
                  "." CRLF
   hier-answer =/ "401" [answertext] CRLF
                  *(text CRLF)
                  "." CRLF

   hierdata    =  "Name:" WSP text CRLF
                  "Status:" WSP text CRLF
                  *(header ":" WSP text CRLF)
                  [("Ctl-PGP-Key:" CRLF PGP-answer /
                    "Mod-PGP-Key:" CRLF PGP-answer)]

Section 6.3.3.9:

   data-answer =/ "510" [answertext] CRLF
                  text CRLF
                  "." CRLF
   data-answer =/ "401" [answertext] CRLF
                  text CRLF
                  "." CRLF

   datadata    =  "Name:" WSP text CRLF
                  "Status:" WSP text CRLF
                  *(header ":" WSP text CRLF)
                  [("Ctl-PGP-Key:" CRLF PGP-answer /
                    "Mod-PGP-Key:" CRLF PGP-answer)]

It should say:

Section 6.3.3.8:

   hier-answer =/ "510" [answertext] CRLF
                  [1*text CRLF]
                  "." CRLF
   hier-answer =/ "401" [answertext] CRLF
                  [1*text CRLF]
                  "." CRLF

   hierdata    =  "Name:" WSP name CRLF
                  "Status:" WSP list-status CRLF
                  *(header ":" WSP *text CRLF)
                  [("Ctl-PGP-Key:" CRLF PGP-answer /
                    "Mod-PGP-Key:" CRLF PGP-answer)]

Section 6.3.3.9:

   data-answer =/ "510" [answertext] CRLF
                  [1*text CRLF]
                  "." CRLF
   data-answer =/ "401" [answertext] CRLF
                  [1*text CRLF]
                  "." CRLF

   datadata    =  "Name:" WSP name CRLF
                  "Status:" WSP list-status CRLF
                  *(header ":" WSP *text CRLF)
                  [("Ctl-PGP-Key:" CRLF PGP-answer /
                    "Mod-PGP-Key:" CRLF PGP-answer)]

Notes:

I suggest [1*text CRLF], that is to say a possible non-empty line, for hier-answer and data-answer with 501 or 401 response codes.
We need at least *text anyway (several characters), as shown in the examples in Section 6.3.3.8 and 6.3.3.9.

As for hierdata and datadata, the text keyword used thrice alone is also not right.

Errata ID: 5825
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2019-08-18

Throughout the document, when it says:

Section 6.3.3.10:

   username =  *1( VCHAR ) / "0" ; Length of VCHAR >= 1

   password =  *1( VCHAR ) / "0" ; Length of VCHAR >= 1

[...]

   getp-answer =/ "213" [answertext] CRLF
                  text CRLF
                  "." CRLF
   getp-answer =/ "430" [answertext] CRLF
                  text CRLF
                  "." CRLF
   getp-answer =/ "411" [answertext] CRLF
                  text CRLF
                  "." CRLF
   getp-answer =/ "510" [answertext] CRLF
                  text CRLF
                  "." CRLF

   getpdata   =   "Name:" WSP text CRLF
                  "Status:" WSP text CRLF
                  "Serial:" WSP timestamp CRLF
                  *(header ":" WSP text CRLF)
                  [("Ctl-PGP-Key:" CRLF PGP-answer /
                    "Mod-PGP-Key:" CRLF PGP-answer)]

Section 6.3.3.11:

   geta-answer =/ "215" [answertext] CRLF
                   text CRLF
                   "." CRLF
   geta-answer =/ "430" [answertext] CRLF
                  text CRLF
                  "." CRLF
   geta-answer =/ "411" [answertext] CRLF
                  text CRLF
                  "." CRLF
   geta-answer =/ "510" [answertext] CRLF
                  text CRLF
                  "." CRLF

   getadata   =   "Name:" WSP text CRLF
                  "Status:" WSP text CRLF
                  "Serial:" WSP timestamp CRLF
                  *(header ":" WSP text CRLF)
                  [("Ctl-PGP-Key:" CRLF PGP-answer/
                    "Mod-PGP-Key:" CRLF PGP-answer)]

It should say:

Section 6.3.3.10:

   username =  1*VCHAR / "0"

   password =  1*VCHAR / "0"

[...]

   getp-answer =/ "213" [answertext] CRLF
                  [1*text CRLF]
                  "." CRLF
   getp-answer =/ "430" [answertext] CRLF
                  [1*text CRLF]
                  "." CRLF
   getp-answer =/ "411" [answertext] CRLF
                  [1*text CRLF]
                  "." CRLF
   getp-answer =/ "510" [answertext] CRLF
                  [1*text CRLF]
                  "." CRLF

   getpdata   =   "Name:" WSP name CRLF
                  "Status:" WSP list-status CRLF
                  "Serial:" WSP timestamp CRLF
                  *(header ":" WSP *text CRLF)
                  [("Ctl-PGP-Key:" CRLF PGP-answer /
                    "Mod-PGP-Key:" CRLF PGP-answer)]

Section 6.3.3.11:

   geta-answer =/ "215" [answertext] CRLF
                  [1*text CRLF]
                  "." CRLF
   geta-answer =/ "430" [answertext] CRLF
                  [1*text CRLF]
                  "." CRLF
   geta-answer =/ "411" [answertext] CRLF
                  [1*text CRLF]
                  "." CRLF
   geta-answer =/ "510" [answertext] CRLF
                  [1*text CRLF]
                  "." CRLF

   getadata   =   "Name:" WSP name CRLF
                  "Status:" WSP list-status CRLF
                  "Serial:" WSP timestamp CRLF
                  *(header ":" WSP *text CRLF)
                  [("Ctl-PGP-Key:" CRLF PGP-answer /
                    "Mod-PGP-Key:" CRLF PGP-answer)]

Notes:

For username and password, RFC 4234 defines VCHAR as %x21-7E, that is to say only one character.

I suggest [1*text CRLF], that is to say a possible non-empty line, for getp-answer and geta-answer with 213, 215, 430, 411 and 510 response codes.
We need at least *text anyway (several characters), as shown in the examples in Sections 6.3.3.10 and 6.3.3.11.

As for getpdata and getadata, the text keyword used thrice alone is also not right.

Errata ID: 5833
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2019-08-18
Edited by: Adrian Farrel
Date Edited: 2019-08-18

Section 6.3.4 says:

   Header: Source

   Used for:    hierarchy
   Mandatory:   no
   Inheritable: yes
   Repeatable:  no

It should say:

   Header: Source

   Used for:    hierarchy
   Mandatory:   no
   Inheritable: yes
   Repeatable:  yes

Notes:

This header is repeatable, as stated in Section 11.

However, it is currently unclear whether section 6.3.4 is correct (note use of the singular in the explanatory text) of whether section 11 is correct.

Errata ID: 5835
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2019-08-18

Section 6.7 says:

   PGP keys for Ctrl-PGP-Key and Mod-PGP-Key are transmitted in the
   following structure:

   PGP-answer = "V" SP Version CRLF
                "U" SP User-ID CRLF
                "B" SP Bits CRLF
                "I" SP Key-ID CRLF
                "F" SP Finger CRLF
                *("L" SP Location CRLF)
                *("K-" Keyblock CRLF)
                "K" SP Keyblock CRLF

   Version  = text
   User-ID  = text
   Bits     = text
   Key-ID   = text
   Finger   = text
   Location = text
   Keyblock = text

It should say:

   PGP keys for Ctl-PGP-Key and Mod-PGP-Key are transmitted in the
   following structure:

   PGP-answer = [*("U" SP User-ID CRLF)]
                ["B" SP Bits CRLF]
                ["I" SP Key-ID CRLF]
                [*("L" SP Location CRLF)]
                ["F" SP Finger CRLF]
                "V" SP Version CRLF
                1*("K-" Keyblock CRLF)
                "K" SP Keyblock CRLF

   Version  = 1*text
   User-ID  = 1*text
   Bits     = 1*text
   Key-ID   = 1*text
   Finger   = 1*text
   Location = 1*text
   Keyblock = 1*text

Notes:

Several fixes :
1- Spelling of "Ctl-PGP-Key" at the first line.
2- Several UIDs are possible for a given key.
3- We need several characters (text is only a byte, so use 1*text).
4- Only Version and Keyblocks are mandatory.
5- Re-arrange the lines of PGP-answer to match the example in the same Section.

Errata ID: 5837
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2019-08-18

Section 6.1.2 says:

   Answers of the type 1xx, 2xx, 4xx, and
   5xx can have a text after the numerical code.  3xx answers contain
   one or more parameters with data; the exact format is explained in
   the description of the commands.

Notes:

These sentences are not clear.
I suggest to just remove them, or reformulate them if they really have importance.
The 202 response code for VERS also has a parameter with data (the current protocol level) for instance.
And 6xx response codes are not mentioned.

RFC 4745, "Common Policy: A Document Format for Expressing Privacy Preferences", February 2007

Source of RFC: geopriv (rai)

Errata ID: 5208
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Randall Gellens
Date Reported: 2017-12-14

Section 7 says:

   The access to data items needs to be matched with the rule set stored
   at the PS.  Each instance of a request has different attributes
   (e.g., the identity of the requestor) that are used for
   authorization.  A rule in a rule set might have a number of
   conditions that need to be met before executing the remaining parts
   of a rule (i.e., actions and transformations).  Details about rule
   matching are described in Section 10.  This document specifies only a
   few conditions (i.e., identity, sphere, and validity).  Further
   condition elements can be added via extensions to this document.  If
   a child element of the <conditions> element is in a namespace that is
   not known or not supported, then this child element evaluates to
   FALSE.

It should say:

   The access to data items needs to be matched with the rule set stored
   at the PS.  Each instance of a request has different attributes
   (e.g., the identity of the requestor) that are used for
   authorization.  A rule in a rule set might have a number of
   conditions that need to be met before executing the remaining parts
   of a rule (i.e., actions and transformations).  Details about rule
   matching are described in Section 10.  This document specifies only a
   few conditions (i.e., identity, sphere, and validity).  Further
   condition elements can be added via extensions to this document.  If
   a child element of the <conditions> element is in a namespace that is
   not known or not supported, then this child element evaluates to
   FALSE.  A rule without a <conditions> element evaluates to TRUE.
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

(Only change is new sentence at end.)

Notes:

The schema in RFC 4745 (Common Policy: A Document Format for Expressing Privacy Preferences) allows the <conditions> element to be omitted. The RFC should say that omitted <conditions> evaluates to TRUE, as the alternative (omitted <conditions> evaluating to FALSE) makes no sense. Omitted <conditions> as TRUE allows for a rule that is always executed, while evaluating as FALSE would create a rule that is never executed, a meaningless thing.

RFC 4758, "Cryptographic Token Key Initialization Protocol (CT-KIP) Version 1.0 Revision 1", November 2006

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 5628
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Conrad Meyer
Date Reported: 2019-02-09

Section 3.5 says:

K_TOKEN = CT-KIP-PRF (R_C, "Key generation" || k || R_S, dsLen)

It should say:

K_TOKEN = CT-KIP-PRF (R_C, k || "Key generation" || R_S, dsLen)

Notes:

Here the RFC is simply incorrect w.r.t. the reference implementation (RSA's proprietary software).

The corrected text matches the reference implementation.

There are several more errata along these lines. With (all) the corrections, it becomes possible to implement 3rd party RFC4758 clients and servers that interact correctly with RSA clients and servers from the RFC text.

Errata ID: 5629
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Conrad Meyer
Date Reported: 2019-02-09

Section 3.8.6 says:

MAC = CT-KIP-PRF (K_AUTH, "MAC 2 computation" || R_C, dsLen)

It should say:

MAC = CT-KIP-PRF (K_AUTH, "MAC 2 Computation" || R_C, dsLen)

Notes:

Note the capitalization of the "C" in "Computation."

Here the RFC is simply incorrect w.r.t. the reference implementation (RSA's proprietary software); the corrected text matches the reference implementation.

Errata ID: 5630
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Conrad Meyer
Date Reported: 2019-02-09

Section D.2.2 says:

F (k, s, i) = OMAC1-AES (k, INT (i) || s)

It should say:

F (k, s, i) = OMAC1-AES (k, s || INT (i))

Notes:

The corrected text matches the (only) reference implementation; the RFC text does not.

Errata ID: 5631
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Conrad Meyer
Date Reported: 2019-02-09

Section D.2.1 says:

For tokens supporting this realization of CT-KIP-PRF, the following
URI may be used to identify this algorithm in CT-KIP:

http://www.rsasecurity.com/rsalabs/otps/schemas/2005/12/
ct-kip#ct-kip-prf-aes

It should say:

For tokens supporting this realization of CT-KIP-PRF, either of
the following URIs may be used to identify this algorithm in CT-KIP:

http://www.rsasecurity.com/rsalabs/otps/schemas/2005/12/
ct-kip#ct-kip-prf-aes

http://www.rsasecurity.com/rsalabs/otps/schemas/2005/11/
ct-kip#ct-kip-prf-aes

Notes:

It seems some versions of the reference implementation use the 2005/11 date and some the 2005/12 one. Both refer to the same PRF construction.

RFC 4791, "Calendaring Extensions to WebDAV (CalDAV)", March 2007

Note: This RFC has been updated by RFC 5689, RFC 6638, RFC 6764, RFC 7809, RFC 7953, RFC 8996

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 4840
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ricki Hirner
Date Reported: 2016-10-25

Section 5.3.4 says:

A response to a GET request targeted at a calendar object resource
MUST contain an ETag response header field indicating the current
value of the strong entity tag of the calendar object resource.

It should say:

A response to a GET request targeted at a calendar object resource
MUST contain an ETag response header field indicating the current
value of the strong entity tag of the calendar object resource.

Note that using another content coding (Content-Encoding) than
"identity" (for instance, when a compressed version of the resource
is sent) will cause the ETag reported by GET to change and make it
unusable for If-Match etc.

Notes:

Content-Encoding (in opposite to Transfer-Encoding) changes strong ETags, see RFC 7232 2.3.3 for an example. So if you GET a resource with another content coding than "identity" (for instance, "gzip"), the (strong) ETag could be "abc-gzip" instead of "abc". If you then send a conditional request (which requires a strong ETag) with If-Match: "abc-gzip", it may not work as expected. The solution seems to be to use Transfer-Encoding whenever possible.

Errata ID: 5481
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Stefanie Schirmer
Date Reported: 2018-08-27

Section 7.8.5 says:

>> Response <<

   HTTP/1.1 207 Multi-Status
   Date: Sat, 11 Nov 2006 09:32:12 GMT
   Content-Type: application/xml; charset="utf-8"
   Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <D:multistatus xmlns:D="DAV:"
                  xmlns:C="urn:ietf:params:xml:ns:caldav">
     <D:response>
       <D:href>http://cal.example.com/bernard/work/abcd4.ics</D:href>
       <D:propstat>
         <D:prop>
           <D:getetag>"fffff-abcd4"</D:getetag>
           <C:calendar-data>BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Client//EN
   BEGIN:VTODO
   DTSTAMP:20060205T235300Z
   DUE;TZID=US/Eastern:20060106T120000
   LAST-MODIFIED:20060205T235308Z
   SEQUENCE:1
   STATUS:NEEDS-ACTION
   SUMMARY:Task #2
   UID:E10BA47467C5C69BB74E8720@example.com
   BEGIN:VALARM
   ACTION:AUDIO
   TRIGGER;RELATED=START:-PT10M
   END:VALARM
   END:VTODO
   END:VCALENDAR
   </C:calendar-data>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
       </D:propstat>
     </D:response>
   </D:multistatus>

It should say:

>> Response <<

   HTTP/1.1 207 Multi-Status
   Date: Sat, 11 Nov 2006 09:32:12 GMT
   Content-Type: application/xml; charset="utf-8"
   Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <D:multistatus xmlns:D="DAV:"
                  xmlns:C="urn:ietf:params:xml:ns:caldav">
     <D:response>
       <D:href>http://cal.example.com/bernard/work/abcd5.ics</D:href>
       <D:propstat>
         <D:prop>
           <D:getetag>"fffff-abcd5"</D:getetag>
           <C:calendar-data>BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Client//EN
   BEGIN:VTIMEZONE
   LAST-MODIFIED:20040110T032845Z
   TZID:US/Eastern
   BEGIN:DAYLIGHT
   DTSTART:20000404T020000
   RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
   TZNAME:EDT
   TZOFFSETFROM:-0500
   TZOFFSETTO:-0400
   END:DAYLIGHT
   BEGIN:STANDARD
   DTSTART:20001026T020000
   RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
   TZNAME:EST
   TZOFFSETFROM:-0400
   TZOFFSETTO:-0500
   END:STANDARD
   END:VTIMEZONE
   BEGIN:VTODO
   DTSTAMP:20060205T235300Z
   DUE;TZID=US/Eastern:20060106T120000
   LAST-MODIFIED:20060205T235308Z
   SEQUENCE:1
   STATUS:NEEDS-ACTION
   SUMMARY:Task #2
   UID:E10BA47467C5C69BB74E8720@example.com
   BEGIN:VALARM
   ACTION:AUDIO
   TRIGGER;RELATED=END:-PT10M
   END:VALARM
   END:VTODO
   END:VCALENDAR
   </C:calendar-data>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
       </D:propstat>
     </D:response>
   </D:multistatus>

Notes:

The timezone is missing from the response in Section 7.8.5.

This is probably related to the previous errata (Errata ID: 4154, Errata ID: 4158, Errata ID: 4159), which all corrected the result to return abcd5.ics instead of abcd4.ics (which contains no timezone).

From rfc4791, Section 4.1.:

Calendar object resources contained in calendar collections MUST NOT
contain more than one type of calendar component (e.g., VEVENT,
VTODO, VJOURNAL, VFREEBUSY, etc.) with the exception of VTIMEZONE
components, which **MUST be specified for each unique TZID parameter
value specified in the iCalendar object.**

Errata ID: 5846
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Дилян Палаузов
Date Reported: 2019-08-25

Section 5.2.3 says:

Conformance:  This property MAY be defined on any calendar
 collection.  If defined, it MUST be protected and SHOULD NOT be
 returned by a PROPFIND DAV:allprop request (as defined in Section
 12.14.1 of [RFC2518]).

Description: ... Any attempt by the client to store calendar object
 resources with component types not listed in this property, if it
 exists, MUST result in an error, with the
 CALDAV:supported-calendar-component precondition (Section 5.3.2.1)
 being violated.  Since this property is protected, it cannot be
 changed by clients using a PROPPATCH request.  However, clients can
 initialize the value of this property when creating a new calendar
 collection with MKCALENDAR. 

It should say:

Conformance:  This property MAY be defined on any calendar
 collection.  If defined, it MAY be protected and SHOULD NOT be
 returned by a PROPFIND DAV:allprop request (as defined in Section
 12.14.1 of [RFC2518]).

Description: ... Any attempt by the client to store calendar object
 resource with component types not listed in this property, if it
 exists, MUST result in an error, with the
 CALDAV:supported-calendar-component precondition (Section 5.3.2.1)
 being violated.  Clients can initialize the value of this property
 when creating a new calendar collection with MKCALENDAR. …

Notes:

The protected status of supported-calendar-component-set is removed, so that CUAs can add component types to existing callendars, like VAVAILABILITY, which component types were not defined, when the calendar was created.

RFC 4862, "IPv6 Stateless Address Autoconfiguration", September 2007

Note: This RFC has been updated by RFC 7527

Source of RFC: ipv6 (int)

Errata ID: 7509
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Jonathan Johnson
Date Reported: 2023-05-05

Section 5.3 says:

A link-local address is formed by combining the well-known link-local prefix FE80::0 [RFC4291] (of appropriate length) with an interface identifier as follows:

It should say:

A link-local address is formed by combining the well-known link-local prefix FE80::/10 [RFC4291] (of appropriate length) with an interface identifier as follows:

Notes:

The prefix text should be in CIDR notation, as the referenced RFC4921 sec. 2.4 lists it in CIDR notation. Further, FE80::0 describes an address, not a prefix.

Errata ID: 6709
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mark Smith
Date Reported: 2021-10-14

Throughout the document, when it says:

Abstract

   This document specifies the steps a host takes in deciding how to
   autoconfigure its interfaces in IP version 6.  The autoconfiguration
   process includes generating a link-local address, generating global
   addresses via stateless address autoconfiguration, and the Duplicate
   Address Detection procedure to verify the uniqueness of the addresses
   on a link.

It should say:

Abstract

   This document specifies the steps a host takes in deciding how to
   autoconfigure its interfaces in IP version 6.  The autoconfiguration
   process includes generating a link-local address, generating global
   addresses via stateless address autoconfiguration (SLAAC), and the Duplicate
   Address Detection procedure to verify the uniqueness of the addresses
   on a link.

Notes:

IPv6 Stateless Address Autoconfiguration is very widely known by the acronym SLAAC, yet surprisingly that acronym doesn't appear anywhere in RFC4862. It would be best to include and use it in a future update to RFC4862.

RFC 4868, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", May 2007

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 5507
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: f. Le Pouliquen
Date Reported: 2018-09-27

Section 2.7.2.2. says:

Test Case AUTH384-4:
   Key =          0102030405060708090a0b0c0d0e0f10
                  1112131415161718191a1b1c1d1e1f20
                  0a0b0c0d0e0f10111213141516171819

It should say:

Test Case AUTH384-4:
   Key =          0102030405060708090a0b0c0d0e0f10
                  1112131415161718191a1b1c1d1e1f20
                  2122232425262728292a2b2c2d2e2f30

Notes:

as the keys increase from case 256 to 384 and to 512, they have the same base.

RFC 4880, "OpenPGP Message Format", November 2007

Note: This RFC has been updated by RFC 5581

Source of RFC: openpgp (sec)

Errata ID: 7889
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Daniel Kahn Gillmor
Date Reported: 2024-04-10

Section 5.2.3.23 says:

Note that any signature may be revoked, including a certification on 
some other person's key.

It should say:

Note that any certification may be revoked, including a certification on 
some other person's key.

Notes:

the only three types of revocation that are specified in OpenPGP are:

0x20: Key revocation signature
The signature is calculated directly on the key being revoked. A
revoked key is not to be used. Only revocation signatures by the
key being revoked, or by an authorized revocation key, should be
considered valid revocation signatures.

0x28: Subkey revocation signature
The signature is calculated directly on the subkey being revoked.
A revoked subkey is not to be used. Only revocation signatures
by the top-level signature key that is bound to this subkey, or
by an authorized revocation key, should be considered valid
revocation signatures.

0x30: Certification revocation signature
This signature revokes an earlier User ID certification signature
(signature class 0x10 through 0x13) or direct-key signature
(0x1F). It should be issued by the same key that issued the
revoked signature or an authorized revocation key. The signature
is computed over the same data as the certificate that it
revokes, and should have a later creation date than that
certificate.

There is no explicit mechanism to revoke a document signature (as opposed to a certification signature), so it makes no sense to claim that "any signature may be revoked".

This was observed by Andrew Gallagher in https://gitlab.com/dkg/openpgp-revocation/-/issues/15, and is still an issue in the successor to RFC 4880, draft-ietf-openpgp-crypto-refresh ☹

RFC 4918, "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", June 2007

Note: This RFC has been updated by RFC 5689

Source of RFC: webdav (app)

Errata ID: 4431
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Worik Stanton
Date Reported: 2015-08-02

Throughout the document, when it says:

Notes:

The phrase: "live properties defined in this specification." is used throughout RFC4918 but there is no place they are defined.

Careful reading can deduce what they may be, but that is not satisfactory. It would be better to actually define them.

Errata ID: 4435
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Worik Stanton
Date Reported: 2015-08-05

Section 9.8.5 says:

It should say:

The 404 (Not Found) status code indicates that the origin server did
   not find a current representation for the target resource or is not
   willing to disclose that one exists.  A 404 status code does not
   indicate whether this lack of representation is temporary or
   permanent; the 410 (Gone) status code is preferred over 404 if the
   origin server knows, presumably through some configurable means, that
   the condition is likely to be permanent.

   

Notes:

The case of the resource being copied not existing is not covered. I assume that a 404 error is appropriate, but that is my assumption.

Errata ID: 4440
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Worik Stanton
Date Reported: 2015-08-09

Section 9.8 says:

Notes:

There are several ambiguities in this section. Here is one.

Copying a resource to a defined collection:

From To Result
/a/c/d /b/ /b/d

This is the logical interpretation and does not conflict with the specifications. But...

From To Result
/a/c/d /b/ /d (/b/ is overwritten)

This perverse but does not conflict either. Trashing he complete collection in this way cannot be right, but it is not in conflict with anything I can find in section 9.8. The closest I can find is:

"When a collection is overwritten, the membership of the destination collection after the successful COPY request MUST be the same membership as the source collection immediately before the COPY."

This does not explicitly prohibit overwriting a collection with a non-collection.


The specification uses "in the destination.." and "at the destination..." interchangeably.

"The COPY method creates a duplicate of the source resource identified by the Request-URI, in the destination resource identified by the URI in the Destination header." This suggests the first

The specification also says: "When the source resource is not a collection, the result of the COPY method is the creation of a new resource at the destination whose state and behavior match that of the source resource as closely as possible." This could mean the second.

Possibly copying a non-collection resource to a collection resource should not be allowed (but I can find no such prohibition)

RFC 4944, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", September 2007

Note: This RFC has been updated by RFC 6282, RFC 6775, RFC 8025, RFC 8066, RFC 8931

Source of RFC: 6lowpan (int)

Errata ID: 6194
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Tommaso Pecorella
Date Reported: 2020-05-30

Section 6 says:

However, in the
   resultant interface identifier, the "Universal/Local" (U/L) bit SHALL
   be set to zero in keeping with the fact that this is not a globally
   unique value.

It should say:

However, in the
   resultant interface identifier, the "Universal/Local" (U/L) bit SHALL
   be set to one in keeping with the fact that this is not a globally
   unique value.

Notes:

IEEE (see https://standards.ieee.org/content/dam/ieee-standards/standards/web/documents/tutorials/eui.pdf) states that:
"the second least significant bit of Octet 0 (the U/L bit) indicates universal (U/L=0) or local (U/L=1) administration of the address."

Thus, the U/L bit in the "pseudo 48-bit address" shall have its U/L bit set to one, not to zero.

RFC 4948, "Report from the IAB workshop on Unwanted Traffic March 9-10, 2006", August 2007

Source of RFC: IAB

Errata ID: 6249
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Greg Skinner
Date Reported: 2020-08-06

Section 1 says:

Over one and half days of intensive discussions

It should say:

Over one and one half days of intensive discussions

Notes:

missing text

RFC 4998, "Evidence Record Syntax (ERS)", August 2007

Source of RFC: ltans (sec)

Errata ID: 7411
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Florian Fischer
Date Reported: 2023-03-31

Section 5.2. says:

   4.  Concatenate each h(i) with ha(i) and generate hash values
       h(i)' = H (h(i)+ ha(i)).  For multi-document groups, this is:
       h(i_a)' = H (h(i_a)+ ha(i))
       h(i_b)' = H (h(i_b)+ ha(i)), etc.

It should say:

   4.  Concatenate each h(i) with ha(i) in binary ascending order and generate hash values
       h(i)' = H (h(i)+ ha(i)).  For multi-document groups, this is:
       h(i_a)' = H (h(i_a)+ ha(i))
       h(i_b)' = H (h(i_b)+ ha(i)), etc.

Notes:

In RFC 4998 HashTree-Renewal is specified in an ambiguous manner.

Skipping sorting before concatenating is a deviation from all other steps in RFC 4998 where hashes are concatenated.

This conclusion is supported by RFC 4998 "Figure 4" that illustrates the steps above and the explanation that follows. The relevant part is this:

h2a' = H( binary sorted and concatenated (h2a, ha(2)))

...

h2c' = H( binary sorted and concatenated (h2c, ha(2)))

So the illustration and its explanation clearly states the sorting before concatenation.

RFC 5035, "Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility", August 2007

Source of RFC: smime (sec)

Errata ID: 6566
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: David von Oheimb
Date Reported: 2021-04-29

Section 3 says:

   certs
      contains the list of certificates that are to be used in
      validating the message.  The first certificate identified in the
      sequence of certificate identifiers MUST be the certificate used
      to verify the signature.  The encoding of the ESSCertIDv2 for this
      certificate SHOULD include the issuerSerial field.  If other
      constraints ensure that issuerAndSerialNumber will be present in
      the SignerInfo, the issuerSerial field MAY be omitted.  The
      certificate identified is used during the signature verification
      process.  If the hash of the certificate does not match the
      certificate used to verify the signature, the signature MUST be
      considered invalid.

      If more than one certificate is present, subsequent certificates
      limit the set of certificates that are used during validation.

It should say:

   certs
      contains the list of certificates that are to be used in
      validating the message. It MUST contain at least one element.
      The first certificate identified in the
      sequence of certificate identifiers MUST be the certificate used
      to verify the signature.  The encoding of the ESSCertIDv2 for this
      certificate SHOULD include the issuerSerial field.  If other
      constraints ensure that issuerAndSerialNumber will be present in
      the SignerInfo, the issuerSerial field MAY be omitted.  The
      certificate identified is used during the signature verification
      process.  If the hash of the certificate does not match the
      certificate used to verify the signature, the signature MUST be
      considered invalid.

      If more than one certificate identifier is present in the sequence of ESSCertIDv2s,
      all certificates referenced there MUST be part of the signature validation chain.

Notes:

Some aspects of the 'certs' field of a SigningCertificateV2 attribute:

SigningCertificateV2 ::= SEQUENCE {
certs SEQUENCE OF ESSCertIDv2,
policies SEQUENCE OF PolicyInformation OPTIONAL
}

described in the sentences quoted above are rather vague.
This lead to major confusion and wrong implementations.
As meanwhile has been clarified, they should be re-phrased;
see suggested new version above.

(One may further mandate/clarify that the certificate identifiers must be given in the same order
as they are expected in the validation chain, but I think this is not important because
the order should not play a critical role and will be determined by the validation chain anyway.)

RFC 5077, "Transport Layer Security (TLS) Session Resumption without Server-Side State", January 2008

Note: This RFC has been obsoleted by RFC 8446

Note: This RFC has been updated by RFC 8447

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 4800
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Joseph Birr-Pixton
Date Reported: 2016-09-10

Section 4 says:

      struct {
          uint32 ticket_lifetime_hint;
          opaque ticket<0..2^16-1>;
      } NewSessionTicket;

(...)

   The ticket is structured as follows:

      struct {
          opaque key_name[16];
          opaque iv[16];
          opaque encrypted_state<0..2^16-1>;
          opaque mac[32];
      } ticket;

(...)

      struct {
          ProtocolVersion protocol_version;
          CipherSuite cipher_suite;
          CompressionMethod compression_method;
          opaque master_secret[48];
          ClientIdentity client_identity;
          uint32 timestamp;
      } StatePlaintext;

      enum {
         anonymous(0),
         certificate_based(1),
         psk(2)
     } ClientAuthenticationType;

      struct {
          ClientAuthenticationType client_authentication_type;
          select (ClientAuthenticationType) {
              case anonymous: struct {};
              case certificate_based:
                  ASN.1Cert certificate_list<0..2^24-1>;
              case psk:
                  opaque psk_identity<0..2^16-1>;   /* from [RFC4279] */
          };
       } ClientIdentity;

Notes:

The ticket construction recommended in section 4 appears to be unimplementable in two respects:

1. Tickets are up to 2^16-1 bytes in length, given they appear in both the client hello extension and the NewSessionTicket handshake message. The recommended format defines a ticket of up to 16+16+32+2+2^16-1 bytes in length. This does not fit.

2. The recommended format allows for up to 2^16-1 bytes of state plaintext in the encrypted_state field. The suggested StatePlaintext is up to 2+2+1+48+1+4+3+2^24-1 bytes in length. This does not fit.

RFC 5091, "Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems", December 2007

Note: This RFC has been updated by RFC 8996

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 4335
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Scott Ruoti
Date Reported: 2015-04-13

Section 201 says:

e': G1' x G1'' -> G2

It should say:

e' : G1' X G1'' -> G2

Notes:

This is the only way to give type correctness.
e: G1' x G1'' -> G2
phi: G1' -> G1''
e'(A, B) = e(A, phi(B))
There for B must be an element of G' so that it can be passed as input to phi(B).

RFC 5116, "An Interface and Algorithms for Authenticated Encryption", January 2008

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 4338
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Maarten Bodewes
Date Reported: 2015-04-19

Section 3.2.1 says:

      +-------------------+--------------------+---------------+
      |    Fixed-Common   |   Fixed-Distinct   |    Counter    |
      +-------------------+--------------------+---------------+
       <---- implicit ---> <------------ explicit ------------>

                 Figure 2: Partially implicit nonce format

      The rationale for the partially implicit nonce format is as
      follows.  This method of nonce construction incorporates the best
      known practice; it is used by both GCM Encapuslating Security
      Payload (ESP) [RFC4106] and CCM ESP [RFC4309], in which the Fixed
      field contains the Salt value and the lowest eight octets of the
      nonce are explicitly carried in the ESP packet.  In GCM ESP, the
      Fixed field must be at least four octets long, so that it can
      contain the Salt value.  In CCM ESP, the Fixed field must be at
      least three octets long for the same reason.  This nonce
      generation method is also used by several counter mode variants
      including CTR ESP.

It should say:

      +-------------------+------------------------------------+
      |    Fixed-Common   |           Fixed-Distinct           |
      +-------------------+------------------------------------+
       <---- implicit ---> <------------ explicit ------------->

                 Figure 2: Partially implicit nonce format

      The rationale for the partially implicit nonce format is as
      follows.  This method of nonce construction incorporates the best
      known practice; it is used by both GCM Encapuslating Security
      Payload (ESP) [RFC4106] and CCM ESP [RFC4309], in which the
      Fixed-Common field contains the Salt value and the lowest eight
      octets of the nonce are explicitly carried in the ESP packet. In
      GCM ESP, the Fixed-Common field must be at least four octets
      long, so that it can contain the Salt value.  In CCM ESP, the
      Fixed-Common field must be at least three octets long for the
      same reason.  This nonce generation method is also used by
      several counter mode variants including CTR ESP.

Notes:

The counter is generally not considered part of the nonce.

The counter itself is not /send/ as part of the nonce, so the figure doesn't comply with the sentence in the text above: "We call the portion of the nonce that is stored or sent with the ciphertext the explicit part." Furthermore the text above also reads: "lowest eight octets of the nonce are explicitly carried in the ESP packet"

The referred to documents (e.g. RFC 4106) also explicitly specify a 12 byte nonce.

The GCM documentation recommends using a nonce of 96 bits (12 bytes) and then proceeds to build a counter (specified as J0) out of that. If the nonce is considered 128 bits instead then J0 is created using a GMAC invocation, which is probably not what was meant by this specification.

Finally, the text about GCM ESP and CCM ESP didn't distinguish between Fixed-Common and Fixed Distinct. It seems clear to me that Fixed-Common was meant the text below Figure 2. (If this should be in a separate Report, please let me know - the text between these parentheses may be removed of course)

Errata ID: 5219
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Brian Smith
Date Reported: 2017-12-28

Section 5.1, 5.2 says:

P_MAX is 2^36 - 31 octets

It should say:

P_MAX is 2^36 - 32 octets

Notes:

There is an off-by-one error in the specification of the maximum input size for AES-GCM.

NIST SP-800-38D [1] Section 5.2.1.1 says:

len(P) ≤ 2^39-256


(2^39-256) / 8 = 2^36 - 32

See also RFC 7539 Errata 4858.

[1] http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf

Errata ID: 6415
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Jordan Smith
Date Reported: 2021-01-29

Section 3.2 says:

  Implementations
   SHOULD support 12-octet nonces in which the Counter field is four
   octets long.

It should say:

  Implementations
   SHOULD support 12-octet nonces in which the Fixed field is four
   octets long.

Notes:

The ascii diagram given shows the Fixed portion being smaller and the examples given in https://tools.ietf.org/id/draft-mcgrew-iv-gen-01.html also show that the Fixed portion is 4 bytes.

Also an 8 byte counter gives 2^64, where a 4 byte counter would only give 2^32

Errata ID: 5233
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lars Maier
Date Reported: 2018-01-10

Section 5.3 says:

An AEAD_AES_128_CCM ciphertext is exactly 16 octets longer than its
 corresponding plaintext.

It should say:

An AEAD_AES_128_CCM ciphertext is exactly 2 octets longer than its
 corresponding plaintext.

Notes:

As described in NIST SP 800-38c the length of the MAC is given in bits. The algorithm specified therein at 6.2 returns a string of PLen + TLen bits.

RFC 5155, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", March 2008

Note: This RFC has been updated by RFC 6840, RFC 6944, RFC 9077, RFC 9157, RFC 9276

Source of RFC: dnsext (int)

Errata ID: 4993
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Dick Franks
Date Reported: 2017-04-13

Section Appendix A says:

  ; H(example)       = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom
  ; H(a.example)     = 35mthgpgcu1qg68fab165klnsnk3dpvl
  ; H(ai.example)    = gjeqe526plbf1g8mklp59enfd789njgi
  ; H(ns1.example)   = 2t7b4g4vsa5smi47k61mv5bv1a22bojr
  ; H(ns2.example)   = q04jkcevqvmu85r014c7dkba38o0ji5r
  ; H(w.example)     = k8udemvp1j2f7eg6jebps17vp3n8i58h
  ; H(*.w.example)   = r53bq7cc2uvmubfu5ocmm6pers9tk9en
  ; H(x.w.example)   = b4um86eghhds6nea196smvmlo4ors995
  ; H(y.w.example)   = ji6neoaepv8b5o6k4ev33abha8ht9fgc
  ; H(x.y.w.example) = 2vptu5timamqttgl4luu9kg21e0aor3s
  ; H(xx.example)    = t644ebqk9bibcna874givr6joj62mlhv
- ; H(2t7b4g4vsa5smi47k61mv5bv1a22bojr.example)
- ;                  = kohar7mbb8dc2ce8a9qvl8hon4k53uhi
  example. 3600  IN SOA  ns1.example. bugs.x.w.example. 1 3600 300 (
                         3600000 3600 )
                 NS      ns1.example.
                 NS      ns2.example.
                 MX      1 xx.example.
                 DNSKEY  256 3 7 AwEAAaetidLzsKWUt4swWR8yu0wPHPiUi8LU (
                         sAD0QPWU+wzt89epO6tHzkMBVDkC7qphQO2h
                         TY4hHn9npWFRw5BYubE= )
                 DNSKEY  257 3 7 AwEAAcUlFV1vhmqx6NSOUOq2R/dsR7Xm3upJ (
                         j7IommWSpJABVfW8Q0rOvXdM6kzt+TAu92L9
                         AbsUdblMFin8CVF3n4s= )
                 NSEC3PARAM 1 0 12 aabbccdd:1
  0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
                         2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
                         SOA NSEC3PARAM RRSIG )
! 2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. A 192.0.2.127
!                NSEC3   1 1 12 aabbccdd (
                         2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG )
  2vptu5timamqttgl4luu9kg21e0aor3s.example. NSEC3 1 1 12 aabbccdd (
                         35mthgpgcu1qg68fab165klnsnk3dpvl MX RRSIG )
  35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd (
                         b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG )
  a.example.     NS      ns1.a.example.
                 NS      ns2.a.example.
                 DS      58470 5 1 (
                         3079F1593EBAD6DC121E202A8B766A6A4837206C )
  ns1.a.example. A       192.0.2.5
  ns2.a.example. A       192.0.2.6
  ai.example.    A       192.0.2.9
                 HINFO   "KLH-10" "ITS"
                 AAAA    2001:db8:0:0:0:0:f00:baa9
  b4um86eghhds6nea196smvmlo4ors995.example. NSEC3 1 1 12 aabbccdd (
                         gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG )
  c.example.     NS      ns1.c.example.
                 NS      ns2.c.example.
  ns1.c.example. A       192.0.2.7
  ns2.c.example. A       192.0.2.8
  gjeqe526plbf1g8mklp59enfd789njgi.example. NSEC3 1 1 12 aabbccdd (
                         ji6neoaepv8b5o6k4ev33abha8ht9fgc HINFO A AAAA
                         RRSIG )
  ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. NSEC3 1 1 12 aabbccdd (
                         k8udemvp1j2f7eg6jebps17vp3n8i58h )
  k8udemvp1j2f7eg6jebps17vp3n8i58h.example. NSEC3 1 1 12 aabbccdd (
!                        kohar7mbb8dc2ce8a9qvl8hon4k53uhi )
! kohar7mbb8dc2ce8a9qvl8hon4k53uhi.example. NSEC3 1 1 12 aabbccdd (
!                        q04jkcevqvmu85r014c7dkba38o0ji5r A RRSIG )
  ns1.example.   A       192.0.2.1
  ns2.example.   A       192.0.2.2
  q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd (
                         r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG )
  r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. NSEC3 1 1 12 aabbccdd (
                         t644ebqk9bibcna874givr6joj62mlhv MX RRSIG )
  t644ebqk9bibcna874givr6joj62mlhv.example. NSEC3 1 1 12 aabbccdd (
                         0p9mhaveqvm6t7vbl5lop2u3t2rp3tom HINFO A AAAA
                         RRSIG )
  *.w.example.   MX      1 ai.example.
  x.w.example.   MX      1 xx.example.
  x.y.w.example. MX      1 xx.example.
  xx.example.    A       192.0.2.10
                 HINFO   "KLH-10" "TOPS-20"
                 AAAA    2001:db8:0:0:0:0:f00:baaa

It should say:

  ; H(example)       = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom
  ; H(a.example)     = 35mthgpgcu1qg68fab165klnsnk3dpvl
  ; H(ai.example)    = gjeqe526plbf1g8mklp59enfd789njgi
  ; H(ns1.example)   = 2t7b4g4vsa5smi47k61mv5bv1a22bojr
  ; H(ns2.example)   = q04jkcevqvmu85r014c7dkba38o0ji5r
  ; H(w.example)     = k8udemvp1j2f7eg6jebps17vp3n8i58h
  ; H(*.w.example)   = r53bq7cc2uvmubfu5ocmm6pers9tk9en
  ; H(x.w.example)   = b4um86eghhds6nea196smvmlo4ors995
  ; H(y.w.example)   = ji6neoaepv8b5o6k4ev33abha8ht9fgc
  ; H(x.y.w.example) = 2vptu5timamqttgl4luu9kg21e0aor3s
  ; H(xx.example)    = t644ebqk9bibcna874givr6joj62mlhv
  example. 3600  IN SOA  ns1.example. bugs.x.w.example. 1 3600 300 (
                         3600000 3600 )
                 NS      ns1.example.
                 NS      ns2.example.
                 MX      1 xx.example.
                 DNSKEY  256 3 7 AwEAAaetidLzsKWUt4swWR8yu0wPHPiUi8LU (
                         sAD0QPWU+wzt89epO6tHzkMBVDkC7qphQO2h
                         TY4hHn9npWFRw5BYubE= )
                 DNSKEY  257 3 7 AwEAAcUlFV1vhmqx6NSOUOq2R/dsR7Xm3upJ (
                         j7IommWSpJABVfW8Q0rOvXdM6kzt+TAu92L9
                         AbsUdblMFin8CVF3n4s= )
                 NSEC3PARAM 1 0 12 aabbccdd:1
  0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
                         2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
                         SOA NSEC3PARAM RRSIG )
! 2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. NSEC3   1 1 12 aabbccdd (
                         2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG )
  2vptu5timamqttgl4luu9kg21e0aor3s.example. NSEC3 1 1 12 aabbccdd (
                         35mthgpgcu1qg68fab165klnsnk3dpvl MX RRSIG )
  35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd (
                         b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG )
  a.example.     NS      ns1.a.example.
                 NS      ns2.a.example.
                 DS      58470 5 1 (
                         3079F1593EBAD6DC121E202A8B766A6A4837206C )
  ns1.a.example. A       192.0.2.5
  ns2.a.example. A       192.0.2.6
  ai.example.    A       192.0.2.9
                 HINFO   "KLH-10" "ITS"
                 AAAA    2001:db8:0:0:0:0:f00:baa9
  b4um86eghhds6nea196smvmlo4ors995.example. NSEC3 1 1 12 aabbccdd (
                         gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG )
  c.example.     NS      ns1.c.example.
                 NS      ns2.c.example.
  ns1.c.example. A       192.0.2.7
  ns2.c.example. A       192.0.2.8
  gjeqe526plbf1g8mklp59enfd789njgi.example. NSEC3 1 1 12 aabbccdd (
                         ji6neoaepv8b5o6k4ev33abha8ht9fgc HINFO A AAAA
                         RRSIG )
  ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. NSEC3 1 1 12 aabbccdd (
                         k8udemvp1j2f7eg6jebps17vp3n8i58h )
  k8udemvp1j2f7eg6jebps17vp3n8i58h.example. NSEC3 1 1 12 aabbccdd (
!                        q04jkcevqvmu85r014c7dkba38o0ji5r )
  ns1.example.   A       192.0.2.1
  ns2.example.   A       192.0.2.2
  q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd (
                         r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG )
  r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. NSEC3 1 1 12 aabbccdd (
                         t644ebqk9bibcna874givr6joj62mlhv MX RRSIG )
  t644ebqk9bibcna874givr6joj62mlhv.example. NSEC3 1 1 12 aabbccdd (
                         0p9mhaveqvm6t7vbl5lop2u3t2rp3tom HINFO A AAAA
                         RRSIG )
  *.w.example.   MX      1 ai.example.
  x.w.example.   MX      1 xx.example.
  x.y.w.example. MX      1 xx.example.
  xx.example.    A       192.0.2.10
                 HINFO   "KLH-10" "TOPS-20"
                 AAAA    2001:db8:0:0:0:0:f00:baaa

Notes:

The obligatory RRSIG records have been omitted for clarity.

The zone prior to NSEC3 signing seems to have contained an unexpected
2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. A 192.0.2.127
which was then lovingly included in the NSEC3 chain.

The error is readily detectable from the list of hashes of the original owner names. The source zone prior to signing can never contain a hashed name.

For completeness, B5 also needs a corresponding amendment, although this does not invalidate the proof presented therein.

RFC 5198, "Unicode Format for Network Interchange", March 2008

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 7531
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Gordon Steemson
Date Reported: 2023-06-01

Section section 2, page 3 says:

3. The control characters in the ASCII range (U+0000 to U+001F and U+007F to U+009F) SHOULD generally be avoided.

It should say:

3. The control characters in the ASCII range (U+0000 to U+001F, and U+007F) SHOULD generally be avoided.

Notes:

Characters in the range U+0080 to U+009F are explicitly noted in the following text as lying outside the ASCII range, and in fact they are discussed separately at that point (which, given the phrasing error pointed out here, currently is duplicate coverage). They do not pertain to any range of ASCII characters and should not be treated as such.

RFC 5260, "Sieve Email Filtering: Date and Index Extensions", July 2008

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 6349
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ken Murchison
Date Reported: 2020-12-06

Section 6.1 says:

     require ["date", "relational", "index"];
     if date :value "gt" :index 2 :zone "-0500" "received"
             "iso8601" "2007-02-26T09:00:00-05:00",
     { redirect "aftercutoff@example.org"; }

It should say:

     require ["date", "relational", "index"];
     if date :value "gt" :index 2 :zone "-0500" "received"
             "iso8601" "2007-02-26T09:00:00-05:00"
     { redirect "aftercutoff@example.org"; }

Notes:

There is a stray comma at the end of the date test.

RFC 5272, "Certificate Management over CMS (CMC)", June 2008

Note: This RFC has been updated by RFC 6402

Source of RFC: pkix (sec)

Errata ID: 7379
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Jaime Hablutzel
Date Reported: 2023-03-08

Throughout the document, when it says:

2.2. Protocol Requests/Responses says:

> Simple PKI Response
> ...
> encapsulatedContentInfo is absent.

4.1. Simple PKI Response says:

> The Simple PKI Response consists of a SignedData with no EncapsulatedContentInfo
and no SignerInfo.

It should say:

2.2. Protocol Requests/Responses should say:

> Simple PKI Response
> ...
> encapContentInfo eContent field is absent.

4.1. Simple PKI Response should say:

> The Simple PKI Response consists of a SignedData with no eContent field in the EncapsulatedContentInfo and no SignerInfo.

Notes:

This change is required for consistency with RFC 8551:

> 3.8. Creating a Certificate Management Message
> The certificate management message or MIME entity is used to
> transport certificates and/or Certificate Revocation Lists (CRLs),
> such as in response to a registration request.
> Step 1. The certificates and/or CRLs are made available to the CMS
> generating process that creates a CMS object of type
> SignedData. The SignedData encapContentInfo eContent field
> MUST be absent, and the signerInfos field MUST be empty.

Additionally, RFC 3852 doesn't allow for the absence of the EncapsulatedContentInfo in a SignedData:

> The signed-data content type shall have ASN.1 type SignedData:
> SignedData ::= SEQUENCE {
> version CMSVersion,
> digestAlgorithms DigestAlgorithmIdentifiers,
> encapContentInfo EncapsulatedContentInfo,
> certificates [0] IMPLICIT CertificateSet OPTIONAL,
> crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
> signerInfos SignerInfos }

Errata ID: 7628
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Piotr Popis
Date Reported: 2023-09-04

Section 3.2.1.3.1. says:

AuthenticatedData content type is used by this document for:

The id-cmc-authData control (Section 6.16), and

The top-level wrapper in environments where an encryption-only key is being certified.

It should say:

AuthenticatedData content type is used by this document for:

The id-cmc-authData control (Section 6.16), and

The top-level wrapper in environments where an encryption-only key is being certified or where a shared-secret exists, but a PKI-based trust (needed for SignedData) has not yet been established.

Notes:

For consistency with the same paragraph and the rest of the document.

Errata ID: 7629
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Piotr Popis
Date Reported: 2023-09-04

Section 3.2.1.3.4. says:

For the PKI Response, SignedData allows the server to sign the returning data, if any exists, and to carry the certificates and CRLs corresponding to the PKI Request.  If no data is being returned beyond the certificates and CRLs, the EncapsulatedInfo and SignerInfo fields are not populated.

It should say:

For the PKI Response, SignedData allows the server to sign the returning data, if any exists, and to carry the certificates and CRLs corresponding to the PKI Request.  If no data is being returned beyond the certificates and CRLs, the eContent field in the EncapsulatedContentInfo and SignerInfo fields are not populated.

Only if the server is unable to sign the response (and unable to use any RecipientInfo options of the AuthenticatedData content type), and at the same time it should send a negative response, Full PKI Response SignedData type containing a CMC Status Info control MUST be returned using a CMCFailInfo with a value of internalCAError and a bodyPartID of 0, and the eContent field in the EncapsulatedContentInfo as well as SignerInfo fields MUST not be populated.

Notes:

This change is needed to comply with Errata ID 7379 (the first para) and covers the case (the second para) where the server shall send a negative response (Full PKI Response) as it is unable to sign the certificate and at the same time it is unable to sign the response itself (e.g. due to a loss in connection to the HSM).

Errata ID: 4775
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kees-Jan Hermans
Date Reported: 2016-08-11

Section B.1 says:

eContentType = id-ct-PKIData

It should say:

eContentType = id-cct-PKIData

Notes:

This is repeated a few times throughout Appendix B.

RFC 5280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", May 2008

Note: This RFC has been updated by RFC 6818, RFC 8398, RFC 8399, RFC 9549

Source of RFC: pkix (sec)

Errata ID: 3986
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Sandra Murphy
Date Reported: 2014-05-13

Section 4.1.1.3 says:

4.1.1.3.  signatureValue

   The signatureValue field contains a digital signature computed upon
   the ASN.1 DER encoded tbsCertificate.  The ASN.1 DER encoded
   tbsCertificate is used as the input to the signature function.  This
   signature value is encoded as a BIT STRING and included in the
   signature field.  The details of this process are specified for each
   of the algorithms listed in [RFC3279], [RFC4055], and [RFC4491].

It should say:

4.1.1.3.  signatureValue

   The signatureValue field contains a digital signature computed upon
   the ASN.1 DER encoded tbsCertificate.  The ASN.1 DER encoded
   tbsCertificate is used as the input to the signature function. The 
   output of the signature function is encoded as a BIT STRING and 
   included in the signatureValue field.  The details of this process 
   are specified for each of the algorithms listed in [RFC3279], 
   [RFC4055], and [RFC4491].

Notes:

The "included in the signature field" should have been "included in the signatureValue field". A field called "signature" does exist in the 5280 structure, but it is not intended to hold the value of the result of the signature function. The sentence was reworded for word flow (and to avoid using "signature value" and "signatureValue" in the same sentence).

Errata ID: 5802
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Nikos Mavrogiannopoulos
Date Reported: 2019-08-06

Section 4.2.1.12 says:

   id-kp-serverAuth             OBJECT IDENTIFIER ::= { id-kp 1 }
   -- TLS WWW server authentication
   -- Key usage bits that may be consistent: digitalSignature,
   -- keyEncipherment or keyAgreement

   id-kp-clientAuth             OBJECT IDENTIFIER ::= { id-kp 2 }
   -- TLS WWW client authentication
   -- Key usage bits that may be consistent: digitalSignature
   -- and/or keyAgreement

It should say:

   id-kp-serverAuth             OBJECT IDENTIFIER ::= { id-kp 1 }
   -- TLS server authentication
   -- Key usage bits that may be consistent: digitalSignature,
   -- keyEncipherment or keyAgreement

   id-kp-clientAuth             OBJECT IDENTIFIER ::= { id-kp 2 }
   -- TLS client authentication
   -- Key usage bits that may be consistent: digitalSignature
   -- and/or keyAgreement

Notes:

The proposed change removes the WWW part of the description. In practice these object identifiers are used for server and client applications, but not necessarily web applications. In particular:
- openssl verification considers them unconditionally even if the server is not a web server or the client a web client
- There is no object identifier that can be used for protocols like SMTP, IMAP, POP3, LDAP, radius, ...; in practice all these protocols are deployed with the identifiers for WWW
- Standards like common criteria assume that these object identifiers are for generic server and clients [0].

[0]. https://www.niap-ccevs.org/MMO/PP/-442-/#FCS_TLSC_EXT.1.1

Errata ID: 5938
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Yuting Chen
Date Reported: 2019-12-15

Section 6.1 says:

The primary goal of path validation is to verify the binding between
a subject distinguished name or a subject alternative name and
subject public key, as represented in the target certificate, based
on the public key of the trust anchor. In most cases, the target

It should say:

  The primary goal of path validation is to verify the binding between
| a subject distinguished name and/or a subject alternative name and
  subject public key, as represented in the target certificate, based
  on the public key of the trust anchor. In most cases, the target

Notes:

The correction conforms to the first paragraph, Sec. 6, "Certification
path processing verifies the binding between the subject distinguished
name and/or subject alternative name and subject public key."

In addition, it is not very clear in RFC 5280, given a certificate with
a non-empty subject DN and an SAN extension instance (critical or
non-critical), which one (the subject DN, the SAN extension, or they
both) should be bound to the subject public key during path validation.
More explanations are needed.

Errata ID: 6414
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Rob Stradling
Date Reported: 2021-01-28

Section 4.2.1.12 says:

   id-kp-serverAuth             OBJECT IDENTIFIER ::= { id-kp 1 }
   -- TLS WWW server authentication
   -- Key usage bits that may be consistent: digitalSignature,
   -- keyEncipherment or keyAgreement

It should say:

   id-kp-serverAuth             OBJECT IDENTIFIER ::= { id-kp 1 }
   -- TLS WWW server authentication
   -- Key usage bits that may be consistent: digitalSignature
   -- and/or (keyEncipherment or keyAgreement)

Notes:

In https://github.com/zmap/zlint/issues/553 there's been some disagreement and confusion about how to correctly interpret the "or" in the Original Text. "You can only set one of these three bits" is one interpretation, and it's hard to argue that this interpretation is inconsistent with the Original Text.

However, digitalSignature+keyEncipherment makes sense for an RSA leaf certificate, and digitalSignature+keyAgreement makes sense for an ECC leaf certificate. Both are widely used, to enable ephemeral and non-ephemeral TLS ciphersuites in conjunction with a single server certificate.

Given that RFC5480 section 3 explicitly permits digitalSignature+keyAgreement in an ECC leaf certificate, I think it's likely that my proposed Corrected Text conveys the RFC5280 authors' intended meaning.

Errata ID: 6830
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Corey Bonnell
Date Reported: 2022-02-02

Section Appendix A.1 says:

-- Note - upper bounds on string types, such as TeletexString, are
-- measured in characters.  Excepting PrintableString or IA5String, a
-- significantly greater number of octets will be required to hold
-- such a value.  As a minimum, 16 octets, or twice the specified
-- upper bound, whichever is the larger, should be allowed for
-- TeletexString.  For UTF8String or UniversalString at least four
-- times the upper bound should be allowed.

It should say:

-- Note - upper bounds on string types, such as TeletexString, are
-- measured in characters.  Excepting PrintableString or IA5String, a
-- significantly greater number of octets will be required to hold
-- such a value.  As a minimum, 16 octets, or twice the specified
-- upper bound, whichever is the larger, should be allowed for
-- TeletexString.  For UTF8String or UniversalString, four
-- times the upper bound should be allowed.

Notes:

"at least four times" is likely a holdover from RFC 3280, as the same text exists in that RFC. In RFC 3280, the definition of UTF-8 in UTF8String was normatively referencing RFC 2279, which allowed for a maximum of 6 octets to represent a single Unicode character in UTF-8. However, RFC 5280 was updated to normatively reference RFC 3629, which restricts the allowed set of characters in a UTF-8 string to match those allowed in UTF-16 (i.e., the BMP and 16 supplementary planes as opposed to all 32k planes). As a result, the maximum length for a single RFC 3629 UTF-8 character is 4 octets, rendering the guidance of "at least four times" wholly unnecessary; "four times" is sufficient in all cases.

Errata ID: 7164
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Aaron Gable
Date Reported: 2022-10-14

Section 5.2.5 says:

   If the distributionPoint field is absent, the CRL MUST contain
   entries for all revoked unexpired certificates issued by the CRL
   issuer, if any, within the scope of the CRL.

It should say:

   If the distributionPoint field is absent, the CRL MUST contain
   entries for all revoked unexpired certificates issued by the CRL
   issuer.

Notes:

The removed phrase does not appear in the original text that this requirement is derived from, ITU-T Rec. X.509 (08/2005) Section 8.6.2.2: "If the issuing distribution point field, the AA issuing distribution point field, and the CRL scope field are all absent, the CRL shall contain entries for all revoked unexpired public-key certificates issued by the CRL issuer."

The removed phrase does not serve to create a stricter requirement; rather it creates a looser requirement which allows a CRL which does contain entries for all revoked unexpired certificates *within its scope* to not include the distributionPoint field. Given that the distributionPoint field serves an important security purpose in preventing substitution attacks, it is unlikely that this loosening was the intent of the original authors.

Errata ID: 7634
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Nick Harper
Date Reported: 2023-09-08

Section 4.1 says:

   Certificate  ::=  SEQUENCE  {
        tbsCertificate       TBSCertificate,
        signatureAlgorithm   AlgorithmIdentifier,
        signatureValue       BIT STRING  }

It should say:

   Certificate  ::=  SEQUENCE  {
        tbsCertificate       TBSCertificate,
        signatureAlgorithm   AlgorithmIdentifier,
        signature            BIT STRING  }

Notes:

The definition in section 4.1 disagrees with the definition in appendix A.1 (page 116) on whether the name of the field containing the signature is "signatureValue" or "signature". This error appears in RFC 3280 and RFC 2459 as well.

The versions of X.509 in force when RFCs 2459, 3280, and 5280 were published use neither of those names. (Those versions of X.509 considered a signature to be an encrypted hash and called the field "encrypted".) The current version, ITU-T X.509 (10/2019), defines this field to be "signature" in section 6.2.1. (X.509 defines the Certificate type using a component type of SIGNATURE, which has two fields named "algorithmIdentifier" and "signature".)

In addition to changing the field name in the definition of the Certificate type in section 4.1, the title and text of subsection 4.1.1.3 should be updated to replace "signatureValue" with "signature".

Errata ID: 7661
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Benjamin Strauss
Date Reported: 2023-09-28

Section 3.5 says:

      (g)  cross-certification:  Two CAs exchange information used in
           establishing a cross-certificate.  A cross-certificate is a
           certificate issued by one CA to another CA that contains a CA
           signature key used for issuing certificates.

It should say:

      (g)  cross-certification:  Two CAs exchange information used in
           establishing a cross-certificate.

Notes:

The removed sentence is factually inaccurate and misleading: "A cross-certificate is a certificate issued by one CA to another CA that contains a CA signature key used for issuing certificates."
A "signature key used for issuing certificates" would be a private key. A certificate simply does not contain a private key. A definition of "cross-certificate" for the purpose of this RFC is already provided in section 3.2, so there is no point in elaborating here.
(The definition given in section 3.2 conflicts with the narrower, and more generally used, definition given in RFC 4949, but that is beside the point.)

RFC 5282, "Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol", August 2008

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 5109
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Andrew Cagney
Date Reported: 2017-09-08

Section 8. says:

8.  IKEv2 Algorithm Selection

   This section applies to the use of any authenticated encryption
   algorithm with the IKEv2 Encrypted Payload and is unique to that
   usage.

   IKEv2 (Section 3.3.3 of [RFC4306]) specifies that both an encryption
   algorithm and an integrity checking algorithm are required for an IKE
   SA (Security Association).  This document updates [RFC4306] to
   require that when an authenticated encryption algorithm is selected
   as the encryption algorithm for any SA (IKE or ESP), an integrity
   algorithm MUST NOT be selected for that SA.  This document further
   updates [RFC4306] to require that if all of the encryption algorithms
   in any proposal are authenticated encryption algorithms, then the
   proposal MUST NOT propose any integrity transforms.

It should say:

8.  IKEv2 Algorithm Selection

IKEv2 [rfc7296], section 3.3. Security Association Payload, specifies
AEAD algorithm selection.

Notes:

RFC-7296 and RFC-5282 contradict each other (yet RFC-7296 cites RFC-5282 without any
clarification):

- RFC-7296 explicitly disallows mixing AEAD and non-AEAD algorithms in a single
proposal; RFC-5282 does not (and strongly implies it is allowed)

- RFC-7296 allows 'none' integrity in an AEAD-only proposal; RFC-5282 does not

RFC 5322, "Internet Message Format", October 2008

Note: This RFC has been updated by RFC 6854

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 5918
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Marcus Bointon
Date Reported: 2019-11-26

Section 2.2 says:

Header fields are lines beginning with a field name, followed by a
   colon (":"), followed by a field body, and terminated by CRLF.  A
   field name MUST be composed of printable US-ASCII characters (i.e.,
   characters that have values between 33 and 126, inclusive), except
   colon.

Notes:

I'm reporting an omission rather than a correction. The description of field names in S2.2 does not describe any length limit, but it implicitly prohibits folding by not permitting WSP chars in the name. 3.6.8 defines an ABNF for field-name, but does not specify a length limit either.

As far as I can see this means that field names should be limited to 77 characters – the field name and a trailing : – after which the field body can start after FWS on the next line.

I suspect this will be open to some debate, so I'm not sure what to suggest as a correction beyond that. Nor do I know whether common clients & servers impose their own arbitrary limits on field names.

Errata ID: 6639
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Brennan Vincent
Date Reported: 2021-07-12

Section 3.3 says:

   zone            =   (FWS ( "+" / "-" ) 4DIGIT) / obs-zone

It should say:

   zone            =   (FWS ( "+" / "-" ) 4DIGIT) / [FWS] obs-zone

Notes:

The current syntax does not allow space before an obs-zone. Thus, it rejects header items like:

Date: Mon, 12 Jul 2021 18:32:01 GMT

which are still being produced today by, for example, mail(1) on FreeBSD.

Errata ID: 6921
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: John Klensin
Date Reported: 2022-04-05

Section 2.1 says:

composed of characters with values in the range of 1 through 127 and interpreted as US-ASCII [ANSI.X3-4.1986] characters.

It should say:

composed of ASCII characters [RFC20] with values in the range from 0/1 to 7/15.

   --OR--

composed of octets with decimal values in the range from 1 through 127 and interpreted as US-ASCII [ANSI.X3-4.1986] characters.

Notes:

See previous erratum about "US-ASCII" versus "ASCII" or "RFC20" and apply as needed to the suggested text.

While there are several ways to fix the problem being reported here, the "range of 1 through 127" has no meaning without some qualification as to what the numbers mean. One could infer from the original form that the range is interpreted according to something in the standard, but that standard, unlike, e.g., Unicode, never uses a linear sequence of numbers to refer to code points, only the Column/Row notation shown above (plus, of course, the actual seven-bit binary coding).

Errata ID: 7382
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Paolo Schiro
Date Reported: 2023-03-11

Section 3.2.3 says:

ccontent        =   ctext / quoted-pair / comment

comment         =   "(" *([FWS] ccontent) [FWS] ")"

It should say:

ccontent        =   ctext / quoted-pair

comment         =   "(" *([FWS] ccontent) [FWS] ")"

Notes:

Trying to getting all possible originator formats a reader can get stuck into a circular dependency between "comment" and "ccontent" definitions.
Since "ccontent" is referenced in the "comment" definition only circular dependency should be cut there I suppose.

RFC 5360, "A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP)", October 2008

Note: This RFC has been updated by RFC 8217

Source of RFC: sip (rai)

Errata ID: 4650
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Brett Tate
Date Reported: 2016-03-29

Section 5.9.3 says:

The following is an example of a Permission-Missing header field:

It should say:

If the URI contains a comma, question mark or semicolon, the
URI MUST be enclosed in angle brackets (< and >).

The following is an example of a Permission-Missing header field:

Notes:

Comma and semicolon can cause decode ambiguities when the header contains addr-spec values instead of name-addr values. For consistency with RFC 3261 section 20, the same bracket rule is indicated to resolve the ambiguity.

RFC 5424, "The Syslog Protocol", March 2009

Source of RFC: syslog (sec)

Errata ID: 5010
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Job Snijders
Date Reported: 2017-05-05

Section 8.1 says:

This document guards against the technical issues outlined in UTR36 by
REQUIRING "shortest form" encoding for syslog applications.

It should say:

"Shortest Form" encoding is REQUIRED for syslog applications to guard
against the technical issues outlined in UTR36.

Notes:

"REQUIRING" is not a RFC 2119 keyword.

Errata ID: 6927
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ulrich Windl
Date Reported: 2022-04-07

Section 6 says:

SD-NAME         = 1*32PRINTUSASCII
                  ; except '=', SP, ']', %d34 (")
...

PRINTUSASCII    = %d33-126

It should say:

SD-NAME         = 1*32PRINTUSASCII
                  ; except '=', SP, ']', %d34 (")
...
PRINTUSASCII    = %d32-126

Notes:

When excluding SP %d32 from PRINTUSASCII, then it does not make sense to state "except ..SP .."
There are more issues with the grammar:
SD_NAME forbids ']', but it should also forbid '['

Errata ID: 4967
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Muhammad Usman
Date Reported: 2017-03-14

Section 6.2.1 says:

4             security/authorization messages
10            security/authorization messages

It should say:

"10             security/authorization messages" should be removed

Notes:

There is a double entry in the facility list.

Errata ID: 6647
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Anonymous User
Date Reported: 2021-07-23

Section 6.2.1 says:

4             security/authorization messages
10            security/authorization messages

It should say:

4             security/authorization messages (note 1)
10            security/authorization messages (note 1)

Note 1 - Various operating systems have been found to utilize
         facilities 4 and 10 for security/authorization
         messages which seem to be similar.

Notes:

Not including the note (adapted from the one in RFC3164) causes errata like the one with ID 4967 to be erroneously reported.

RFC 5453, "Reserved IPv6 Interface Identifiers", February 2009

Source of RFC: 6man (int)

Errata ID: 5589
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Brian Carpenter
Date Reported: 2019-01-02

Section 3 says:

   +-----------------------------------------+-------------------------+
   |        Interface Identifier Range       |       Description       |
   +-----------------------------------------+-------------------------+
   |           0000:0000:0000:0000           |  Subnet-Router Anycast  |
   |                                         |        [RFC4291]        |
   |                                         |                         |
   | FDFF:FFFF:FFFF:FF80-FDFF:FFFF:FFFF:FFFF | Reserved Subnet Anycast |
   |                                         |    Addresses[RFC2526]   |
   +-----------------------------------------+-------------------------+

                       Table 1: Current Assignments

It should say:

   +-----------------------------------------+-------------------------+
   |        Interface Identifier Range       |       Description       |
   +-----------------------------------------+-------------------------+
   |           0000:0000:0000:0000           |  Subnet-Router Anycast  |
   |                                         |        [RFC4291]        |
   |                                         |                         |
   | FDFF:FFFF:FFFF:FF80-FDFF:FFFF:FFFF:FFFF | Reserved Subnet Anycast |
   | FFFF:FFFF:FFFF:FF80-FFFF:FFFF:FFFF:FFFF |    Addresses[RFC2526]   |
   +-----------------------------------------+-------------------------+

                       Table 1: Current Assignments

Notes:

Both these ranges are in fact reserved by Section 2 of RFC2526. Under current recommendations [RFC7217] the FDFF range is no longer recommended for routine use, and the FFFF range is equally likely to occur in a pseudo-random 64-bit IID. Credit to Kerry Lynn for pointing this out.

RFC 5465, "The IMAP NOTIFY Extension", February 2009

Source of RFC: lemonade (app)

Errata ID: 4833
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Chris Newman
Date Reported: 2016-10-17

Section 5.2, 7 says:

Section 5.2 paragraph 4:
   ...  The FETCH response(s) MUST follow any
   ESEARCH ADDTO responses.

Section 7 paragraph 2:
   Note that the EXISTS response MUST precede any FETCH responses, and
   together they MUST precede the ESEARCH response.

Notes:

As the RFC is internally inconsistent on this point, servers can have either behavior. I know of at least one deployed implementation that follows the MUST in section 7 rather than the one in section 5.2.

At this point I can't suggest specific corrected text, so this is a hold-for-document-update issue.

RFC 5480, "Elliptic Curve Cryptography Subject Public Key Information", March 2009

Note: This RFC has been updated by RFC 8813

Source of RFC: pkix (sec)

Errata ID: 4170
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Annie Yousar
Date Reported: 2014-11-11

Section 4 says:

   ---------+----------+------------+-----------
   256      | 512      | SHA-512    | secp521r1
   ---------+----------+------------+-----------

It should say:

   ---------+----------+------------+-----------
   256      | 512+     | SHA-512    | secp521r1
   ---------+----------+------------+-----------

Notes:

The first table in section 4 (p. 9) provides the right text. The corresponding line in the table on p. 10 is the wrong one. In fact the key size is exactly 521 and not only 512+. Therefore 512+ in both tables could also be replaced by 521.

RFC 5502, "The SIP P-Served-User Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem", April 2009

Note: This RFC has been updated by RFC 8217, RFC 8498

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rai

Errata ID: 4648
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Brett Tate
Date Reported: 2016-03-29

Section 6 says:

EQUAL, HCOLON, SEMI, name-addr, addr-spec, and generic-param are
defined in RFC 3261 [2].

It should say:

EQUAL, HCOLON, SEMI, name-addr, addr-spec, and generic-param are
defined in RFC 3261 [2].

If the URI contains a comma, question mark or semicolon, the URI MUST
be enclosed in angle brackets (< and >).

Notes:

If addr-spec is used when there are parameters, it is ambiguous if the parameters are URI parameters or served-user-param. For consistency with RFC 3261 section 20, the same bracket rule is indicated even if comma and question mark do not cause an issue.

Errata ID: 4827
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Dale R. Worley
Date Reported: 2016-10-11

Section 6 says:

   sessioncase-param        = "sescase" EQUAL "orig" / "term"
   registration-state-param = "regstate" EQUAL "unreg" / "reg"

It should say:

   sessioncase-param        = "sescase" EQUAL ( "orig" / "term" )
   registration-state-param = "regstate" EQUAL ( "unreg" / "reg" )

Notes:

The ABNF as written does not take into account that concatenation binds tighter than alternation.

RFC 5531, "RPC: Remote Procedure Call Protocol Specification Version 2", May 2009

Note: This RFC has been updated by RFC 9289

Source of RFC: nfsv4 (wit)

Errata ID: 6255
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ed Schouten
Date Reported: 2020-08-12

Section 9 says:

         union reply_body switch (reply_stat stat) {
         case MSG_ACCEPTED:
            accepted_reply areply;
         case MSG_DENIED:
            rejected_reply rreply;
         } reply;

It should say:

         union reply_body switch (reply_stat stat) {
         case MSG_ACCEPTED:
            accepted_reply areply;
         case MSG_DENIED:
            rejected_reply rreply;
         };

Notes:

The XDR grammar doesn't allow stating this:

union type_name switch (...) { ...} member_name;

You only have these two forms:

union type_name switch (...) { ...};
union switch (...) { ...} member_name;

RFC 5537, "Netnews Architecture and Protocols", November 2009

Note: This RFC has been updated by RFC 8315

Source of RFC: usefor (app)

Errata ID: 4468
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2015-09-08

Section 3.5 says:

   An injecting agent processes proto-articles as follows:

[...]

   2.   It MUST reject any proto-article that does not have the proper
        mandatory header fields for a proto-article, that has Injection-
        Info or Xref header fields, that has a Path header field
        containing the "POSTED" <diag-keyword>, or that is not
        syntactically valid as defined by [RFC5536].

It should say:

   An injecting agent processes proto-articles as follows:

[...]

   2.   It MAY modify header fields so that the proto-article conforms
        to [RFC5536].  If made, such modifications SHOULD be as
        minimal as possible.  The usual changes are the removal of
        empty header fields and a bit of cleaning in folding or the
        syntax used.

   3.   It MUST reject any proto-article that does not have the proper
        mandatory header fields for a proto-article, that has Injection-
        Info or Xref header fields, that has a Path header field
        containing the "POSTED" <diag-keyword>, or that is not
        syntactically valid as defined by [RFC5536].

Notes:

Subsequent items should be renumbered at the same time.

Rationale: most of server software has been removing empty header fields and made syntax cleaning for ages. Some news clients do rely on that "feature" of removing empty header fields, i.e by putting empty Followup-To, Summary and Keywords header fields into each article opened in the editor and not removing them if empty when posting the article.

Though RFC 1849 (Son-of-1036) says the posting agent SHOULD delete empty headers, in practice the relayer (injecting agent) took care of that when not done by the posting agent.

This erratum describes a variation from the standard and could be taken into account in a revision of RFC 5537, if it happens.

RFC 5538, "The 'news' and 'nntp' URI Schemes", April 2010

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 4708
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: stream9
Date Reported: 2016-06-11

Section 4 says:

newsURL         = "news:" [ server "/" ] ( article / newsgroups )

It should say:

newsURL         = "news:" [ server "/" ] [ article / newsgroups ]

Notes:

Neither <article> nor <newsgroups> allow empty entries, but in the example there is an empty entry.

news://news.server.example/

Which means the as same as

news://news.server.example/*

RFC 5545, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", September 2009

Note: This RFC has been updated by RFC 5546, RFC 6868, RFC 7529, RFC 7953, RFC 7986, RFC 9073, RFC 9074, RFC 9253

Source of RFC: calsify (app)

Errata ID: 6316
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ken Murchison
Date Reported: 2020-10-22

Section 3.8.5.1 says:

    Value Type:  The default value type for this property is DATE-TIME.
       The value type can be set to DATE.

It should say:

    Value Type:  The default value type for this property is DATE-TIME.
       The value type can be set to DATE.  This property MUST have the same
       value type as the "DTSTART" property contained within the
       recurring component.  Furthermore, this property MUST be specified
       as a date with local time if and only if the "DTSTART" property
       contained within the recurring component is specified as a date
       with local time.

Notes:

EXDATE excludes a specific instance of a recurring event and therefore should have the same value type as DTSTART. This is analogous to RECURRENCE-ID which overrides a specific instance and has the same value type as DTSTART.

I will note however that there is iCalendar data in the wild with DTSTART;VALUE=DATE-TIME and EXDATE;VALUE=DATE. If this errata is rejected as incorrect, then a new errata should be opened with additional text describing how EXDATE;VALUE=DATE is supposed to be handled when DTSTART;VALUE=DATE-TIME. For instance, does EXDATE;VALUE=DATE exclude ALL instances of a FREQ=HOURLY recurrence on the given day?

RFC 5570, "Common Architecture Label IPv6 Security Option (CALIPSO)", July 2009

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 4545
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: R. Atkinson
Date Reported: 2015-11-24

Section 5.1.7 says:

It should say:

Add the following clarifying text:

While the code listed in RFC 1662 Appendix C reportedly does not 
natively use IETF Network Byte Order, the CRC generated using the 
algorithm from RFC 1662, Appendix C, MUST be stored on-the-wire 
in Network Byte Order in the "16-bit Checksum Field" defined by 
RFC 5570, Section 5.1.7, in order to remain consistent with all 
other fields in the RFC 5570 CALIPSO option.  

Network Byte Order is defined in RFC 791, Appendix B.

As an implementation note, at least one implementer has found 
that in his implementation it is easiest to use the RFC 1662,
Appendix C code as-is for the purposes of generating and calculating 
the checksum.  That implementation reportedly has code that on 
packet creation writes the generated checksum into this field --in 
Network Byte Order-- prior to packet transmission.  The same 
implementation reportedly has code that on packet reception reads
the transmitted checksum in Network Byte Order and then locally 
transforms the value into RFC 1662, Appendix C, byte order 
(i.e. for the purpose of checksum verification upon packet reception
as per RFC 5570, Section 5.1, paragraph 2).

Notes:

An implementer was confused about whether Network Byte Order applied
to all fields in the CALIPSO option defined in RFC 5570. This erratum clarifies
that Network Byte Order does apply to all fields in the RFC 5570 CALIPSO
option.

RFC 5576, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", June 2009

Source of RFC: mmusic (rai)

Errata ID: 7544
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philipp Hancke
Date Reported: 2023-06-15

Section 4.2 says:

Every <ssrc-id> listed in an "ssrc-group" attribute MUST be defined by a corresponding "ssrc:" line in the same media description

It should say:

Every <ssrc-id> listed in an "ssrc-group" attribute MUST be defined by a corresponding "ssrc:" line in the same media description and MUST appear only once in this ssrc-group

Notes:

The goal is to clarify that something like
a=ssrc-group:FID 1234 1234
is not valid. While this is demuxable (in the BUNDLE sense) it would require chaining of ssrc-demuxing and payload type demuxing which is a lot of complexity.
The uniqueness is already implied by the following sentence (emphasis is mine):
The SDP media attribute "ssrc-group" expresses a relationship among *several* sources of an RTP session
earlier in the section.

RFC 5580, "Carrying Location Objects in RADIUS and Diameter", August 2009

Note: This RFC has been updated by RFC 8559

Source of RFC: geopriv (rai)

Errata ID: 5465
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Alan DeKok
Date Reported: 2018-08-15

Section 5 says:

 0-1     0-1    0      0         0+         126  Operator-Name

It should say:

 0+     0      0      0         0+         126  Operator-Name

Notes:

Section 4.1 says:

The Operator-Name Attribute SHOULD be sent in Access-Request and
Accounting-Request messages where the Acc-Status-Type is set to
Start, Interim, or Stop.

The table in Section 5 does not appear to match this.

- Access-Request is marked 0-1. It should be marked 0+, to allow packets to contain both E212 and REALM values for Operator-Name

- there is no discussion of Operator-Name in Access-Accept. So it's not clear why the table lists 0-1 for that packet

- The table allows 0+ for Accounting-Request, so it's not clear why it's 0-1 for Access-Request

RFC 5598, "Internet Mail Architecture", July 2009

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 5925
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: David Crocker
Date Reported: 2019-12-02

Section 1.2 says:

{addition to the end of the section. there might be a better way to handle this, but this is my best guess. Note that this also means that RFC 5598 should also be modified to have the status of updating RFC 5321.}

It should say:

Sections 5.1 and 5.3 of this document supersede Section 3.9 of RFC 5321. 

Notes:

RFC 5598 is intended to document existing email architecture and terminology. It's explicit discussion of aliases and mailing lists represent a community consensus view.

The language in RFC 5321 dates back to RFC 821 and its differences from what is stated in RFC 5598 do /not/ represent a modern view of email architecture, nor should a hop-by-hop transport-like protocol make statements about higher-level, end-to-end services, any more than IP should dictate details for TCP (or SMTP).

Errata ID: 7150
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Dave Crocker
Date Reported: 2022-10-08

Section 4 says:

Figure 5: Protocols and Services

It should say:

Figure 5: Protocols and Services (with reporting details)

Notes:

Figure 5 is careful to list each of the architectural components from an author to a recipient. However there are multiple places in that sequence that can generate a report back to the author or originating system. The diagram showing these is overly simplistic and for example, does not show the requisite submission or delivery agents needed for such return reporting.

Fixing this will require some thoughtful reworking of the diagram.

RFC 5636, "Traceable Anonymous Certificate", August 2009

Source of RFC: pkix (sec)

Errata ID: 5935
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2019-12-12

Section Appendix A says:

   -- Imports from RFC 3280 [PROFILE], Appendix A.1
              AlgorithmIdentifier, Certificate, CertificateList,
              CertificateSerialNumber, Name FROM PKIX1Explicit88
                   { iso(1) identified-organization(3) dod(6)
                     internet(1) security(5) mechanisms(5) pkix(7)
                      mod(0) pkix1-explicit(18) }

   -- Imports from CMS
            ContentInfo, SignedData FROM
            CryptographicMessageSyntax2004{ iso(1)
            member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
            smime(16) modules(0) cms-2004(24)}

It should say:

   -- Imports from CMS
            ContentInfo, ContentType FROM
            CryptographicMessageSyntax2004{ iso(1)
            member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
            smime(16) modules(0) cms-2004(24)} ;

Notes:

None of the imports from RFC 3280 are used. The import list from RFC 3852 should not include SignedData, and it should include ContentType. A semi-colon is needed at the end of the IMPORTS statement.

Errata ID: 5936
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2019-12-12

Section Appendix A says:

DEFINITIONS IMPLICIT TAGS ::=

It should say:

RFC5636Module
DEFINITIONS IMPLICIT TAGS ::=

Notes:

A module name is needed for the module to properly compile.

RFC 5646, "Tags for Identifying Languages", September 2009

Source of RFC: ltru (app)

Errata ID: 5457
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Occil
Date Reported: 2018-08-12

Section 2.2.9 says:

   A tag is considered "valid" if it satisfies these conditions:

   o  The tag is well-formed.

   o  Either the tag is in the list of grandfathered tags or all of its
      primary language, extended language, script, region, and variant
      subtags appear in the IANA Language Subtag Registry as of the
      particular registry date.

   o  There are no duplicate variant subtags.

   o  There are no duplicate singleton (extension) subtags.

It should say:

   A tag is considered "valid" if it satisfies these conditions:

   o  The tag is well-formed.

   o  Either the tag is in the list of grandfathered tags or all of its
      primary language, extended language, script, region, and variant
      subtags appear in the IANA Language Subtag Registry as of the
      particular registry date.

   o  There are no duplicate variant subtags.

   o  There are no duplicate singleton (extension) subtags.

   o  There is no more than one extended language subtag.

Notes:

Sec. 2.2.2 contains an additional validity requirement (point 4): the existence of no more than one extended language subtag. This is not reflected in the definition of validity given in sec. 2.2.9 of the RFC.

RFC 5651, "Layered Coding Transport (LCT) Building Block", October 2009

Source of RFC: rmt (tsv)

Errata ID: 7638
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Sam Hurst
Date Reported: 2023-09-11

Section 2 says:

   Beyond support for congestion control, LCT provides a number of
   fields and supports functionality commonly required by many
   protocols.  For example, LCT provides a Transmission Session ID that
   can be used to identify to which session each received packet
   belongs.  This is important because a receiver may be joined to many
   sessions concurrently, and thus it is very useful to be able to
   demultiplex packets as they arrive according to the session to which
   they belong.  As another example, there are optional fields within
   the LCT packet header for identifying the object about which
   information is carried in the packet payload.

It should say:

   Beyond support for congestion control, LCT provides a number of 
   fields and supports functionality commonly required by many 
   protocols.  For example, LCT provides a Transport Session ID that 
   can be used to identify to which session each received packet 
   belongs.  This is important because a receiver may be joined to many 
   sessions concurrently, and thus it is very useful to be able to 
   demultiplex packets as they arrive according to the session to which 
   they belong.  As another example, there are optional fields within 
   the LCT packet header for identifying the object about which 
   information is carried in the packet payload.

Notes:

There is an inconsistency in the definition of the TSI acronym. There are 6 instances of TransPORT session identifier/ID, and 2 instances of TransMISSION session identifier/ID. The other instance is in section 3, paragraph 3 ("One of the required fields is the TransMISSION Session ID (TSI).")

RFC 5662, "Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description", January 2010

Source of RFC: nfsv4 (wit)

Errata ID: 7667
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Pali Rohár
Date Reported: 2023-10-06

Section 2 says:

   /// /*
   ///  * Program number is in the transient range since the client
   ///  * will assign the exact transient program number and provide
   ///  * that to the server via the SETCLIENTID operation.
   ///  */
   /// program NFS4_CALLBACK {

It should say:

   /// /*
   ///  * Program number is in the transient range since the client
   ///  * will assign the exact transient program number and provide
   ///  * that to the server via the CREATE_SESSION or
   ///  * BACKCHANNEL_CTL operations.
   ///  */
   /// program NFS4_CALLBACK {

Notes:

SETCLIENTID operation is NFSv4.0 specific operation. NFSv4.1 uses CREATE_SESSION or BACKCHANNEL_CTL operation for setting backchannel parameters.

Errata ID: 7669
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Pali Rohár
Date Reported: 2023-10-06

Section 2 says:

   /// /*
   ///  * From RFC 2203
   ///  */
   /// enum rpc_gss_svc_t {
   ///         RPC_GSS_SVC_NONE        = 1,
   ///         RPC_GSS_SVC_INTEGRITY   = 2,
   ///         RPC_GSS_SVC_PRIVACY     = 3
   /// };
   ///
   /// struct rpcsec_gss_info {
   ///         sec_oid4        oid;
   ///         qop4            qop;
   ///         rpc_gss_svc_t   service;
   /// };

It should say:

   /// /*
   ///  * From RFC 2203
   ///  */
   /// enum rpc_gss_service_t {
   ///         /* Note: the enumerated value for 0 is reserved. */
   ///         rpc_gss_svc_none        = 1,
   ///         rpc_gss_svc_integrity   = 2,
   ///         rpc_gss_svc_privacy     = 3
   /// };
   ///
   /// struct rpcsec_gss_info {
   ///         sec_oid4            oid;
   ///         qop4                qop;
   ///         rpc_gss_service_t   service;
   /// };

Notes:

Mentioned RFC 2203 (and also its updates RFC 5403 and RFC 7861) does not have any enum rpc_gss_svc_t. Instead it has enum rpc_gss_service_t and all enum values are lowercase.

RFC 5664, "Object-Based Parallel NFS (pNFS) Operations", January 2010

Source of RFC: nfsv4 (wit)

Errata ID: 2017
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Benny Halevy
Date Reported: 2010-01-26

Section 5.4.2 says:

N = L / (W-P * stripe_unit)
L' = N * (W * stripe_unit) +
    (L % (W-P * stripe_unit))

It should say:

N = L / ((W-P) * stripe_unit)
L' = N * (W * stripe_unit) +
    (L % ((W-P) * stripe_unit))

Notes:

Missing parenthesis around lower precedence expression

Errata ID: 2018
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Benny Halevy
Date Reported: 2010-01-26

Section 5.4.3 says:

N = L / (W-1 * stripe_unit)

It should say:

N = L / ((W-1) * stripe_unit)

Notes:

Missing parenthesis around lower precedence expression

Errata ID: 2019
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Benny Halevy
Date Reported: 2010-01-26

Section 5.4.4 says:

The equations given above for embedded parity can be used to
map a file offset to the correct component object by setting the
number of parity components to 2 instead of 1 for RAID4 or RAID5.

It should say:

The equations given above for embedded parity can be used to
map a file offset to the correct component object by setting the
number of parity components to 2 instead of 1 for RAID5.

Notes:

Clarify that the RAID_PQ algorithm extends the rotated parity scheme as specified for RAID_5.

RFC 5665, "IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats", January 2010

Source of RFC: nfsv4 (wit)

Errata ID: 2016
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-01-26

Section 5.2.3.5 says:

5.2.3.5.  Uaddr Format for ICMP over IPv4 and IPv6

   As ICMP is not a true transport, there is no uaddr format for ICMP.
   The netid assignments "icmp" and "icmp6" and their shared uaddr
   "format" are listed to prevent any registrant from allocating the
   netids "icmp" and "icmp6" for a purpose that would likely cause
   confusion.

It should say:

5.2.3.5.  Uaddr Format for ICMP over IPv4 and IPv6

   As ICMP is not a true transport, there are no netid assignments
   "icmp" and "icmp6" and there is no need for a dummy uaddr format
   for ICMP.

Notes:

Rationale:
The RFC text in Section 5.2.3.5. is outdated and does not correspond
to the revised design decision documented in Section 5.1 to _not_
register "icmp" and "icmp6" netids.

Section 5.1 says:

o To prevent confusion with the control protocol by the same name
[9], netids with the prefix "ICMP" are Reserved.

and

2. [...]
Constant names with the prefix "NC_STDS",
"NC_FCFS", "NC_PRIV", "NC_EXPE", and "NC_ICMP" are Reserved.

Since there are no such registry entries (see Table 2 in Section 5.1.1),
there also is no dummy shared Uaddr Format for ICMP in the Uaddr Format
registry (see Table 3 in Section 5.2.1), and hence the Original text is
moot.

An alternative to the above Corrected Text would be to delete the
entire subsection 5.2.3.5. in the RFC.

_____
Closely related:

Notes regarding the current IANA registries originated in RFC 5665

[[ This part of the Errata Note should be deleted by the verifier
after verification and corrective action by IANA. ]]

a) IANA has misrepresented the registration policy in the netid registry.

Both namespaces are split into two parts, governed respectively
by "Standards Action" and "First Come First Served" policy.

IANA has split the 'netid' registry into two sub-registries
(BTW: not sure this makes sense, since the namespace is shared),
but the first registry, "ONC RPC Netids (First Come First Served)"
confusingly says:
Registration Procedures
Standards Action
as well.

b) "RESERVED" values and patterns

IANA did not make note of the various "reserved" values specified
in the RFC. All these reservations should preferably be stated in
"Note"s attached to the registries to remind readers and prospective
registrant of the reservations.
Maybe, a short hint to the RFC suffices in both cases:

"Note: RFC 5665 specifies various reserved values and name prefixes
for this registry."

c) Columnar alignment

In the "ONC RPC Netids (First Come First Served)" registry,
apparently the content of the "Point of Contact" column is missing,
and the entries for the "cross reference" column are misaligned.

In the "ONC RPC Netids (Standards Action)" registry and the
"NC RPC Uaddr Format Registry", the left alignment of the
cross reference table cell entries below the (centered) column
heading (and thus visually almost under the "Point of Contact"
column heading) also is rather confusing.
In general, using the _same_ (often: left) horizontal alignment
of column headings and table cells would be preferable.

RFC 5698, "Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC)", November 2009

Source of RFC: ltans (sec)

Errata ID: 6948
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2022-04-29

Section Appendix C and D says:

        version          INTEGER               DEFAULT   {v1(1)},

It should say:

        version          INTEGER  { v1(1) }    DEFAULT   v1,

Notes:

The syntax for version in the TBSPolicy structure is incorrect. The replacement line works in both Appendix C (Informative) and Appendix D (Normative).

RFC 5705, "Keying Material Exporters for Transport Layer Security (TLS)", March 2010

Note: This RFC has been updated by RFC 8446, RFC 8447

Source of RFC: tls (sec)

Errata ID: 4395
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Rick van Rein
Date Reported: 2015-06-16

Section 4 says:

   If no context is provided, it then computes:

           PRF(SecurityParameters.master_secret, label,
               SecurityParameters.client_random +
               SecurityParameters.server_random
               )[length]

   If context is provided, it computes:

           PRF(SecurityParameters.master_secret, label,
               SecurityParameters.client_random +
               SecurityParameters.server_random +
               context_value_length + context_value
               )[length]

It should say:

   If no context is provided, it then computes:

           PRF(SecurityParameters.master_secret, label,
               SecurityParameters.client_random +
               SecurityParameters.server_random
               )[0..length-1]

   If context is provided, it computes:

           PRF(SecurityParameters.master_secret, label,
               SecurityParameters.client_random +
               SecurityParameters.server_random +
               context_value_length + context_value
               )[0..length-1]

Notes:

The current notation is not in line with that of RFC 5246, where the [0..N-1] notation is used on a PRF outcome in Sections 7.4.9 and 8.1 and similar [A..B] notation is also used elsewhere. This makes me believe that the current text is technically wrong, and not in line with the intentions stated informally below it,

The output is a pseudorandom bit string of length bytes generated
from the master_secret.

RFC 5740, "NACK-Oriented Reliable Multicast (NORM) Transport Protocol", November 2009

Source of RFC: rmt (tsv)

Errata ID: 6405
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ronald in 't Velt
Date Reported: 2021-01-21

Section 4.2.1 says:

For NORM_OBJECT_FILE and NORM_OBJECT_STREAM objects, the data segment length and offset can be calculated using the block partitioning algorithm described in the
FEC Building Block [RFC5052] document. For NORM_OBJECT_STREAM objects, the length and offset is obtained from the segment’s corresponding embedded "payload_len" and "payload_offset" fields.

It should say:

For NORM_OBJECT_FILE and NORM_OBJECT_DATA objects, the data segment length and offset can be calculated using the block partitioning algorithm described in the
FEC Building Block [RFC5052] document. For NORM_OBJECT_STREAM objects, the length and offset is obtained from the segment’s corresponding embedded "payload_len" and "payload_offset" fields.

Notes:

The partitioning algorithm specified in RFC 5052 and referenced here applies only to NORM_OBJECT_FILE and NORM_OBJECT_DATA objects, not to NORM_OBJECT_STREAM objects. In fact, these sentences at the very end of section 4.2.1 merely try to reiterate what has already been said earlier in the same section with reference to the header fields 'payload_len', 'payload_msg_start' and 'payload_offset': "For objects of types NORM_OBJECT_FILE and NORM_OBJECT_DATA, these fields are unnecessary since the receiver can calculate the payload length and offset information from the "fec_payload_id" using the REQUIRED block partitioning algorithm described in the FEC Building Block [RFC5052] document."

RFC 5751, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", January 2010

Note: This RFC has been obsoleted by RFC 8551

Source of RFC: smime (sec)

Errata ID: 4273
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Gutmann
Date Reported: 2015-02-18

Section Global says:

Notes:

RFC 5751 contains several S/MIME sample messages, prefixed with the text "A sample message would be". These samples aren't actually valid S/MIME messages but merely contain 141 bytes of random garbage. In other words the S/MIME "sample messages" aren't actually sample messages.

RFC 5753, "Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)", January 2010

Source of RFC: smime (sec)

Errata ID: 4777
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Jim Schaad
Date Reported: 2016-08-13

Section 3.1.1 says:

-  originator MUST be the alternative originatorKey.  The
      originatorKey algorithm field MUST contain the id-ecPublicKey
      object identifier (see Section 7.1.2).  The parameters associated
      with id-ecPublicKey MUST be absent, ECParameters, or NULL.  The
      parameters associated with id-ecPublicKey SHOULD be absent or
      ECParameters, and NULL is allowed to support legacy
      implementations.  The previous version of this document required
      NULL to be present.  If the parameters are ECParameters, then they
      MUST be namedCurve.  The originatorKey publicKey field MUST
      contain the DER encoding of the value of the ASN.1 type ECPoint
      (see Section 7.2), which represents the sending agent's ephemeral
      EC public key.  The ECPoint in uncompressed form MUST be
      supported.

It should say:

-  originator MUST be the alternative originatorKey.  The
      originatorKey algorithm field MUST contain the id-ecPublicKey
      object identifier (see Section 7.1.2).  The parameters associated
      with id-ecPublicKey MUST be absent, ECParameters, or NULL.  The
      parameters associated with id-ecPublicKey SHOULD be absent or
      ECParameters, and NULL is allowed to support legacy
      implementations.  The previous version of this document required
      NULL to be present.  If the parameters are ECParameters, then they
      MUST be namedCurve.  The originatorKey publicKey field MUST
      contain the encoded public key as defined in [X9.62].  The hybred
      form MUST NOT be used.  The ECPoint in uncompressed form MUST be
      supported.  This mirrors the same format used in public key 
      certificates as defined in Section 2.2 of [RFC5480].

Notes:

There is a problem in that for ECPoints, the public key is defined to be encoded differently in this document than it is in a public key certificate. The difference is the presence of the ASN.1 OCTET STRING wrapper.

OpenSSL and BouncyCastle both use the unwrapped version per Dr. Stephen Henson note to me in mail.

This error is also present in sections 3.1.2, 3.1.3, 3.2.1, 3.2.2, 7.2

RFC 5755, "An Internet Attribute Certificate Profile for Authorization", January 2010

Source of RFC: pkix (sec)

Errata ID: 6567
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2021-05-01

Section Appendix B says:

   GeneralName, GeneralNames, id-ce, AuthorityKeyIdentifier,
   AuthorityInfoAccessSyntax, CRLDistributionPoint
     FROM PKIX1Implicit88

It should say:

   GeneralName, GeneralNames, id-ce, AuthorityKeyIdentifier,
   AuthorityInfoAccessSyntax
     FROM PKIX1Implicit88

Notes:

CRLDistributionPoint is part of the IMPORTS statement, but it is not used in the definitions that follow.

RFC 5801, "Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family", July 2010

Note: This RFC has been updated by RFC 9266

Source of RFC: sasl (sec)

Errata ID: 5081
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Rick van Rein
Date Reported: 2017-08-09

Section 3.1 says:

                                    If any padding or non-alphabet
   characters are encountered, the name is not a GS2 family mechanism
   name.

It should say:

                                    If any padding or non-alphanumerical
   characters are encountered, the name is not a GS2 family mechanism
   name.

RFC 5802, "Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms", July 2010

Note: This RFC has been updated by RFC 7677, RFC 9266

Source of RFC: sasl (sec)

Errata ID: 5271
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: David Golden
Date Reported: 2018-03-02

Section 5.1, 7 says:

Section 5.1:

   o  e: This attribute specifies an error that occurred during
      authentication exchange.  It is sent by the server in its final
      message and can help diagnose the reason for the authentication
      exchange failure.  On failed authentication, the entire server-
      final-message is OPTIONAL; specifically, a server implementation
      MAY conclude the SASL exchange with a failure without sending the
      server-final-message.  This results in an application-level error
      response without an extra round-trip.  If the server-final-message
      is sent on authentication failure, then the "e" attribute MUST be
      included.

Section 7:

   server-first-message =
                     [reserved-mext ","] nonce "," salt ","
                     iteration-count ["," extensions]

It should say:

Section 5.1:

   o  e: This attribute specifies an error that occurred during
      authentication exchange.  It is sent by the server in its first
      or final message and can help diagnose the reason for the
      authentication exchange failure.  On failed authentication, the
      entire server-first-message or server-final-message is OPTIONAL;
      specifically, a server implementation MAY conclude the SASL
      exchange with a failure without sending the a message.  This
      results in an application-level error response without an extra
      round-trip.  If a server message is sent on authentication
      failure, then the "e" attribute MUST be included.

Section 7:

   server-first-message-bare =
                     [reserved-mext ","] nonce "," salt ","
                     iteration-count

   server-first-message = (server-error / server-first-message-bare)
                     ["," extensions]

Notes:

Many of the server-error message options in the formal syntax apply to fields received in the client-first message, e.g. "invalid-username-encoding" or "extensions-not-supported". There is no existing provision in the formal syntax for a server to return a server-error in response to a client-first message. The intent of the server-error field appears to include responses to the client-first message and there are no meaningful responses to such errors. E.g. what salt and iteration count should be returned in the case of invalid-username-encoding? Therefore, this proposed errata allows server-error to be returned as the server-first-message and amends the explanatory text of section 5.1 accordingly.

Errata ID: 5580
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Wang Xin
Date Reported: 2018-12-19

Section 7 says:

   server-error-value = "invalid-encoding" /
                  "extensions-not-supported" /  ; unrecognized 'm' value
                  "invalid-proof" /
                  "channel-bindings-dont-match" /
                  "server-does-support-channel-binding" /
                    ; server does not support channel binding
                  "channel-binding-not-supported" /
                  "unsupported-channel-binding-type" /
                  "unknown-user" /
                  "invalid-username-encoding" /
                    ; invalid username encoding (invalid UTF-8 or
                    ; SASLprep failed)
                  "no-resources" /
                  "other-error" /
                  server-error-value-ext
           ; Unrecognized errors should be treated as "other-error".
           ; In order to prevent information disclosure, the server
           ; may substitute the real reason with "other-error".

It should say:

   server-error-value = "invalid-encoding" /
                  "extensions-not-supported" /  ; unrecognized 'm' value
                  "invalid-proof" /
                  "channel-bindings-dont-match" /
                  "server-does-support-channel-binding" /
                    ; the client thinks the server does not support 
                    ; channel binding, but the server does
                  "channel-binding-not-supported" /
                  "unsupported-channel-binding-type" /
                  "unknown-user" /
                  "invalid-username-encoding" /
                    ; invalid username encoding (invalid UTF-8 or
                    ; SASLprep failed)
                  "no-resources" /
                  "other-error" /
                  server-error-value-ext
           ; Unrecognized errors should be treated as "other-error".
           ; In order to prevent information disclosure, the server
           ; may substitute the real reason with "other-error".

Notes:

See Section 6, "If the flag is set to "y" and the server supports channel binding, the server MUST fail authentication. "
I assume the server-error-value "server-does-support-channel-binding" is designed for such situation.

RFC 5805, "Lightweight Directory Access Protocol (LDAP) Transactions", March 2010

Source of RFC: INDEPENDENT

Errata ID: 5245
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Emmanuel Lecharny
Date Reported: 2018-01-28

Section 3.4 says:

"The server returns an End Transaction Response with a resultCode of
   success (0) and no responseValue to indicate all the requested
   updates were applied."

It should say:

The server returns an End Transaction Response with a resultCode of
   success (0) and optionally a responseValue with updateControls, 
if any to indicate all the requested updates were applied.

Notes:

The original text mention that the responseValue should not be sent back when the commit was successful, which would makes the updateControls useless. As the caller would need to get back the controls result for each operation having a control, we need to send them back when the transaction is successful.

Errata ID: 5246
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Emmanuel Lecharny
Date Reported: 2018-01-28

Section 2.3 says:

      txnEndRes ::= SEQUENCE {
           messageID MessageID OPTIONAL,
                -- msgid associated with non-success resultCode
           updatesControls SEQUENCE OF updateControls SEQUENCE {
                messageID MessageID,
                     -- msgid associated with controls
                controls  Controls
           } OPTIONAL
      }

It should say:

      TxnEndRes ::= SEQUENCE {
           messageID MessageID OPTIONAL,
                -- msgid associated with non-success resultCode
           updatesControls SEQUENCE OF updateControl SEQUENCE {
                messageID MessageID,
                     -- msgid associated with controls
                controls  Controls
           } OPTIONAL
      }

      UpdateControl SEQUENCE {
                messageID MessageID,
                     -- msgid associated with controls
                controls  Controls
      }

Notes:

The type after SEQUENCE OF should be different than the name used before SEQUENCE OF, to avoid confusion.
'txnEndRes' should also be 'TxnEndRes' as it's a typeReference, so it should start with a upper case, accordingly to the ASN.1 grammar specification

RFC 5831, "GOST R 34.11-94: Hash Function Algorithm", March 2010

Note: This RFC has been updated by RFC 6986

Source of RFC: INDEPENDENT

Errata ID: 5739
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Vitaly Chikunov
Date Reported: 2019-05-25

Section 6 says:

      3.4 SIGMA := SIGMA (+)' M[s]

It should say:

      3.4 SIGMA := SIGMA (+)' M_s

Notes:

M[s] is not defined, and GOST R 34.11-94 also says M_s.

RFC 5843, "Additional Hash Algorithms for HTTP Instance Digests", April 2010

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: art

Errata ID: 4418
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Michal Bozon
Date Reported: 2015-07-17

Section 1.1 says:

   Digest: SHA-256=MWVkMWQxYTRiMzk5MDQ0MzI3NGU5NDEyZTk5OWY1ZGFmNzgyZTJlO
   DYzYjRjYzFhOTlmNTQwYzI2M2QwM2U2MQ==

It should say:

   Digest: SHA-256=HtHRpLOZBEMnTpQS6Zn12veC4uhjtMwamfVAwmPQPmE=

Notes:

The example SHA-256 message digest in the original document is not base64(sha256(M)), but it is base64(hexlify(sha256(M))).
Therefore the example is incorrect and misleading,
the digest is much longer than it sould be.

That base64 encoding of binary hash digest has to be used,
instead of the base64 encoding of the hexlified hash,
can be verified by checking RFC3230 section 4.2.

RFC 5869, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", May 2010

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 5161
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dale R. Worley
Date Reported: 2017-10-20

Section 2.3 says:

(where the constant concatenated to the end of each T(n) is a
single octet.)

It should say:

(where the constant concatenated to the end of each T(n) is a
single octet with value mod(n, 256).)

Notes:

It's clear what the values of the octets are supposed to be, but the text doesn't actually say what they are.

RFC 5878, "Transport Layer Security (TLS) Authorization Extensions", May 2010

Note: This RFC has been updated by RFC 8447, RFC 8996

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 3515
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ben Laurie
Date Reported: 2013-03-08

Section 3.3 says:

struct {
  AuthzDataFormat authz_format;
  select (AuthzDataFormat) {
    case x509_attr_cert: X509AttrCert;
    case saml_assertion: SAMLAssertion;
    case x509_attr_cert_url: URLandHash;
    case saml_assertion_url: URLandHash;
  }
} AuthorizationDataEntry;

enum {
  x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2),
  saml_assertion_url(3), (255)
} AuthzDataFormat;opaque X509AttrCert<1..2^16­1>;

opaque SAMLAssertion<1..2^16­1>;

struct {
  opaque url<1..2^16­1>;
  HashAlgorithm hash_alg;
  select (hash_alg) {
    case md5: MD5Hash;
    case sha1: SHA1Hash;
    case sha224: SHA224Hash;
    case sha256: SHA256Hash;
    case sha384: SHA384Hash;
    case sha512: SHA512Hash;
  } hash;
} URLandHash;

It should say:

struct {
  AuthzDataFormat authz_format;
  uint16 authz_data_length;
  select (AuthzDataFormat) {
    case x509_attr_cert: X509AttrCert;
    case saml_assertion: SAMLAssertion;
    case x509_attr_cert_url: URLandHash;
    case saml_assertion_url: URLandHash;
  }
} AuthorizationDataEntry;

authz_data_length This field is the length (in bytes) of the data 
selected by AuthzDataFormat.

enum {
  x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2),
  saml_assertion_url(3), (255)
} AuthzDataFormat;

opaque X509AttrCert[authz_data_length];

opaque SAMLAssertion[authz_data_length];

struct {
  opaque url<1..2^16­1>;
  HashAlgorithm hash_alg;
  select (hash_alg) {
    case md5: MD5Hash;
    case sha1: SHA1Hash;
    case sha224: SHA224Hash;
    case sha256: SHA256Hash;
    case sha384: SHA384Hash;
    case sha512: SHA512Hash;
  } hash;
} URLandHash;

Example: similarly to the example on p. 7, authorization data 
consisting of an X509 attribute cert

a SAML assertion URL is encoded as

17 # Handshake.msg_type == supplemental_data(23)
00 00 38 # Handshake.length = 56
00 00 53 # length of SupplementalData.supp_data = 53
40 02 # SupplementalDataEntry.supp_data_type = 16386
00 31 # SupplementalDataEntry.supp_data_length = 49
00 # authz_format = x509_attr_cert(0)
00 05 # authz_data_length = 5
aa aa aa aa aa # X509AttrCert fictitious: "aa aa aa aa aa"
01 # authz_format = saml_assertion_url(3)
00 26 # authz_data_length = 38
00 03 # length of URLAndHash url
bb bb bb # url fictitious: "bb bb bb"
04 # hash_alg = sha256(4)
00 01 02 03 # sha256 hash: "00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
04 05 06 07 # 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f"
08 09 0a 0b #
0c 0d 0e 0f #
10 11 12 13 #
14 15 16 17 #
18 19 1a 1b #
1c 1d 1e 1f #

Notes:

Proposed change: Allow opaque parsing of AuthorizationData entries. As AuthorizationData
may be intended for use by applications rather than the handshake itself, it is desirable that TLS
servers and clients be able to parse this data without being aware of its structure.

RFC 5891, "Internationalized Domain Names in Applications (IDNA): Protocol", August 2010

Source of RFC: idnabis (app)

Errata ID: 7375
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Nicholas Olsen
Date Reported: 2023-03-02

Section 1 says:

Section: Appendix B.2

Original Text:

AuthorityInfoAccessSyntax, GeneralName, CrlEntryExtensions
FROM PKIX1Implicit-2009 -- From [RFC5912]
    {iso(1) identified-organization(3) dod(6) internet(1) security(5)
    mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(5

It should say:

AuthorityInfoAccessSyntax, GeneralName, CrlEntryExtensions, CRLReason
FROM PKIX1Implicit-2009 -- From [RFC5912]
    {iso(1) identified-organization(3) dod(6) internet(1) security(5)
    mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)}

Notes:

Said to

RFC 5903, "Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2", June 2010

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 5764
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mohit Sethi
Date Reported: 2019-06-27

Section 8 says:

Sections 8.1, 8.2 and 8.3 say "We suppose
that the response Diffie-Hellman private key is:"

It should say:

"We suppose that the responder's Diffie-Hellman private key is:"

Notes:

While the text did not cause me any problems in testing my P-256 implementation, it did initially confuse me. IKE has initiator and responder. The way the text is currently phrased, it seems as if the private key is sent in response to a message from the initiator.

RFC 5910, "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)", May 2010

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 6863
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Patrick Mevzek
Date Reported: 2022-02-25

Section 4.3, 5.1.2, 5.2.1 says:

   <secDNS:dsData>
     <secDNS:keyTag>12345</secDNS:keyTag>
     <secDNS:alg>3</secDNS:alg>
     <secDNS:digestType>1</secDNS:digestType>
     <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
     <secDNS:keyData>
       <secDNS:flags>257</secDNS:flags>
       <secDNS:protocol>3</secDNS:protocol>
       <secDNS:alg>1</secDNS:alg>
       <secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey>
     </secDNS:keyData>
    </secDNS:dsData>

It should say:

   <secDNS:dsData>
     <secDNS:keyTag>12345</secDNS:keyTag>
     <secDNS:alg>3</secDNS:alg>
     <secDNS:digestType>1</secDNS:digestType>
     <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
     <secDNS:keyData>
       <secDNS:flags>257</secDNS:flags>
       <secDNS:protocol>3</secDNS:protocol>
       <secDNS:alg>3</secDNS:alg>
       <secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey>
     </secDNS:keyData>
    </secDNS:dsData>

Notes:

The DS alg value must match the underlying (inside) DNSKEY alg value.

From RFC 5910 respectively:
- A <secDNS:alg> element that contains an algorithm value as
described in Section 5.1.2 of RFC 4034 [RFC4034].
and
- A <secDNS:alg> element that contains an algorithm number field
value as described in Section 2.1.3 of RFC 4034 [RFC4034].

Section 5.1.2 of RFC 4034 says:
The algorithm number used by the DS RR is identical to the algorithm
number used by RRSIG and DNSKEY RRs.


The three occurrences are just examples so do not change the meaning of the specification, yet incorrect examples can create confusion.

RFC 5912, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", June 2010

Note: This RFC has been updated by RFC 6960, RFC 9480

Source of RFC: pkix (sec)

Errata ID: 4145
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Pierce Leonberger
Date Reported: 2014-10-23

Section 14 says:

  --  3.  A more complex version, but one that automatically ties
  --      together both the signature algorithm and the
  --      signature value for automatic decoding.
  --
  SIGNED{ToBeSigned} ::= SEQUENCE {
     toBeSigned           ToBeSigned,
     algorithmIdentifier  SEQUENCE {
         algorithm        SIGNATURE-ALGORITHM.
                            &id({SignatureAlgorithms}),
         parameters       SIGNATURE-ALGORITHM.
                            &Params({SignatureAlgorithms}
                              {@algorithmIdentifier.algorithm}) OPTIONAL
     },
     signature BIT STRING (CONTAINING SIGNATURE-ALGORITHM.&Value(
                              {SignatureAlgorithms}
                              {@algorithmIdentifier.algorithm}))
  }

It should say:

  SIGNED{ToBeSigned} ::= SEQUENCE {
     toBeSigned           ToBeSigned,
     algorithmIdentifier  SEQUENCE {
         algorithm        SIGNATURE-ALGORITHM.
                            &id({SignatureAlgorithms}),
         parameters       SIGNATURE-ALGORITHM.
                            &Params({SignatureAlgorithms}
                              {@algorithmIdentifier.algorithm}) OPTIONAL
     },
     signature BIT STRING 
  }

Notes:

I *believe* the 3rd option for SIGNED{} is invalid. The "signature" BIT STRING contains an OpenType which references an optional class field. It's possible to define objects with no type and OpenTypes must refer to a type. There's no mechanism to allow an OpenType to reference random bytes (not ASN.1 encoded).

I understand the intent is to allow for automatic decoding, but unless the "&Value" is required in SIGNATURE-ALGORITHM this will not work. Requiring it will not work because not all signature algorithms require the signature value to be encoded (e.g. RSA). The syntax would be valid is if "signature" was OPTIONAL (obviously not desirable).

So I propose we revert "signature" to "BIT STRING" without constraints.

Errata ID: 4244
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Richard Nicholas
Date Reported: 2015-01-27

Section 14 says:

  at-x520StateOrProvinceName ATTRIBUTE ::=
      { TYPE DirectoryString {ub-state-name}
          IDENTIFIED BY id-at-stateOrProvinceName }
  X520StateOrProvinceName ::= DirectoryString {ub-state-name}

  at-x520OrganizationName ATTRIBUTE ::=
      { TYPE DirectoryString {ub-organization-name}
          IDENTIFIED BY id-at-organizationName }
  X520OrganizationName ::= DirectoryString {ub-organization-name}

  at-x520OrganizationalUnitName ATTRIBUTE ::=
      { TYPE DirectoryString  {ub-organizational-unit-name}
          IDENTIFIED BY id-at-organizationalUnitName }
  X520OrganizationalUnitName ::= DirectoryString
                                     {ub-organizational-unit-name}

It should say:

  at-x520StateOrProvinceName ATTRIBUTE ::=
      { TYPE X520StateOrProvinceName
          IDENTIFIED BY id-at-stateOrProvinceName }
  X520StateOrProvinceName ::= DirectoryString {ub-state-name}

  at-x520OrganizationName ATTRIBUTE ::=
      { TYPE X520OrganizationName IDENTIFIED BY id-at-organizationName }
  X520OrganizationName ::= DirectoryString {ub-organization-name}

  at-x520OrganizationalUnitName ATTRIBUTE ::=
      { TYPE X520OrganizationalUnitName
          IDENTIFIED BY id-at-organizationalUnitName }
  X520OrganizationalUnitName ::= DirectoryString
                                     {ub-organizational-unit-name}

Notes:

The definitions of the three ATTRIBUTE objects (at-x520StateOrProvinceName, at-x520OrganizationName, at-x520OrganizationalUnitName) should be changed to reference the existing type definitions. This change will eliminate the extra type definition in each of those objects as well as make those object definitions consistent with the definitions for the at-x520LocalityName and at-x520CommonName ATTRIBUTE objects.

RFC 5915, "Elliptic Curve Private Key Structure", June 2010

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 5008
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Brian Smith
Date Reported: 2017-04-30

Section 3 says:

Though the ASN.1 indicates that the parameters field is OPTIONAL,
implementations that conform to this document MUST always include
the parameters field.

It should say:

Though the ASN.1 indicates that the parameters field is OPTIONAL,
whether the parameters field is optional, required, or forbidden
depends on the context. When serializing an ECPrivateKey into a PKCS#8
file, the parameters field MUST NOT be included in the serialization.
(This is required to interoperate with PKCS#11.)

When parsing an ECPrivateKey within a PKCS#8 file, when the parser
encounters an ECPrivateKey without a parameters field, the parser MUST
use the parameters from the PKCS#8 privateKeyAlgorithm field, and MUST
NOT reject the key solely due to the missing parameters field.

When parsing an ECPrivateKey within a PKCS#8 file, when the parser 
encounters an ECPrivateKey with a parameters field present, the parser
SHOULD reject the key if the ECPrivateKey parameters do not exactly
match the the PKCS#8 privateKeyAlgorithm parameters.

More generally, these rules should be followed whenever parsing an
ECPrivateKey within a larger structure that contains the parameters.

Notes:

Section 1 notes that we must put "id-ecPublicKey, id-ecDH, or id-ecMQV (from [RFC5480]) with the namedCurve as the parameters in the privateKeyAlgorithm field;"

Thus, in a PKCS#8 file containing an ECC private key, there's no need to include the parameters in the ECPrivateKey field, because they are already in the privateKeyAlgorithm field.

PKCS#11 says "Since the EC domain parameters are placed in the PKCS #8’s privateKeyAlgorithm field, the optional parameters field in an ECPrivateKey must be omitted." - http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/pkcs11-curr-v2.40.pdf

Further, with OpenSSL 1.0.2h and the OpenSSL trunk, the `openssl genpkey` command only encode the parameters in the PKCS#8 privateKeyAlgorithm, not in the parameters field of the ECPrivateKey:

openssl genpkey -algorithm EC \
-pkeyopt ec_paramgen_curve:P-256 \
-pkeyopt ec_param_enc:named_curve | \
openssl pkcs8 -topk8 -nocrypt -outform der > p256-private-key.pk8

Thus, a parser that wishes to interoperate with OpenSSL cannot enforce the MUST requirement here.

RFC 5931, "Extensible Authentication Protocol (EAP) Authentication Using Only a Password", August 2010

Note: This RFC has been updated by RFC 8146

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 5681
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Dan Harkins
Date Reported: 2019-03-31

Section 2.8.3 says:

2.8.3 Fixing the Password Element

   Fixing the Password Element involves an iterative hunting-and-pecking
   technique using the prime from the negotiated group's domain
   parameter set and an ECC- or FFC-specific operation depending on the
   negotiated group. 

2.8.3.1.  ECC Operation for PWE

   The group-specific operation for ECC groups uses pwd-value, pwd-seed,
   and the equation for the curve to produce the Password Element.
   First, pwd-value is used directly as the x-coordinate, x, with the
   equation for the elliptic curve, with parameters a and b from the
   domain parameter set of the curve, to solve for a y-coordinate, y.
   If there is no solution to the quadratic equation, this operation
   fails and the hunting-and-pecking process continues.  If a solution
   is found, then an ambiguity exists as there are technically two
   solutions to the equation and pwd-seed is used to unambiguously
   select one of them.  If the low-order bit of pwd-seed is equal to the
   low-order bit of y, then a candidate PWE is defined as the point
   (x, y); if the low-order bit of pwd-seed differs from the low-order
   bit of y, then a candidate PWE is defined as the point (x, p - y),
   where p is the prime over which the curve is defined.  The candidate
   PWE becomes PWE, and the hunting and pecking terminates successfully.

   Algorithmically, the process looks like this:

      found = 0
      counter = 1
      do {
        pwd-seed = H(token | peer-ID | server-ID | password | counter)
        pwd-value = KDF(pwd-seed, "EAP-pwd Hunting And Pecking", len(p))
        if (pwd-value < p)
        then
          x = pwd-value
          if ( (y = sqrt(x^3 + ax + b)) != FAIL)
          then
            if (LSB(y) == LSB(pwd-seed))
            then
              PWE = (x, y)
            else
              PWE = (x, p-y)
            fi
            found = 1
          fi
        fi
        counter = counter + 1
      } while (found == 0)

                    Figure 3: Fixing PWE for ECC Groups


2.8.3.2.  FFC Operation for pwe

   The group-specific operation for FFC groups takes pwd-value, and the
   prime, p, and order, r, from the group's domain parameter set (see
   Section 2.2.1 when the order is not part of the defined domain
   parameter set) to directly produce a candidate Password Element, pwe,
   by exponentiating the pwd-value to the value ((p-1)/r) modulo the
   prime.  If the result is greater than one (1), the candidate pwe
   becomes pwe, and the hunting and pecking terminates successfully.

   Algorithmically, the process looks like this:

      found = 0
      counter = 1
      do {
        pwd-seed = H(token | peer-ID | server-ID | password | counter)
        pwd-value = KDF(pwd-seed, "EAP-pwd Hunting And Pecking", len(p))
        if (pwd-value < p)
        then
          pwe = pwd-value ^ ((p-1)/r) mod p
          if (pwe > 1)
          then
            found = 1
          fi
        fi
        counter = counter + 1
      } while (found == 0)

                    Figure 4: Fixing PWE for FFC Groups

It should say:

2.8.3 Fixing the Password Element

   Fixing the Password Element involves an iterative hunting-and-pecking
   technique using the prime from the negotiated group's domain
   parameter set and an ECC- or FFC-specific operation depending on the
   negotiated group. 

   To thwart side-channel attacks that attempt to determine the number
   of iterations of the hunting-and-pecking loop used to find the PE for
   a given password, a security parameter, k, is used that ensures that
   at least k iterations are always performed.  The probability that one
   requires more than n iterations of the hunting-and-pecking loop to
   find an ECC PE is roughly (q/2p)^n and to find an FFC PE is roughly
   (q/p)^n, both of which rapidly approach zero (0) as n increases.  The
   security parameter, k, SHOULD be set sufficiently large such that the
   probability that finding the PE would take more than k iterations is
   sufficiently small. It is RECOMMENDED that an implementation set the
   security parameter, k, to a value of at least forty (40) which will
   put the probability that more than forty iterations are needed in the
   order of one in one trillion (1:1,000,000,000,000)

2.8.3.1.  ECC Operation for PWE

   The group-specific operation for ECC groups uses pwd-value, pwd-seed,
   and the equation for the curve to produce the Password Element.
   First, pwd-value is used directly as an x-coordinate, v, with the
   equation for the elliptic curve, with parameters a and b from the
   domain parameter set of the curve, to check whether v^3 + a*v + b
   is a quadratic residue modulo p.  

   If it is a quadratic non residue, this operation fails and the
   hunting-and-pecking process continues. If it is a quadratic residue,
   then the x-coordinate is saved and the current seed is stored. When
   the hunting-and-pecking loop terminates, the x-coordinate is used
   with the equation of the curve to solve for a y-coordinate.  An
   ambiguity exists since two values for the y-coordinate would be
   valid, and the low-order bit of the stored base is used to
   unambiguously determine the correct y-coordinate. The resulting
   (x,y) pair becomes PWE.

   Algorithmically, the process looks like this:

      found = 0
      counter = 1
      do {
        pwd-seed = H(token | peer-ID | server-ID | password | counter)
        pwd-value = KDF(pwd-seed, "EAP-pwd Hunting And Pecking", len(p))
        if (pwd-value < p)
        then
	  v = pwd-value
          if ((v^3 + av + b)) is a quadratic residue)
          then
            if ( found == 0 )
	    then
	       x = v
	       save = pwd-seed
	       found = 1
	    fi
          fi
        fi
        counter = counter + 1
      } while ((found == 0) || (counter < k))
      y = sqrt(x^3 + ax + b)
      if ( lsb(y) == lsb(save))
      then
        PWE = (x, y)
      else
        PWE = (x, p-y)
      fi

                    Figure 3: Fixing PWE for ECC Groups

   Checking whether a value is a quadratic residue modulo a prime can
   leak information about that value in a side-channel attack.
   Therefore, it is RECOMMENDED that the technique used to determine if
   the value is a quadratic residue modulo p blind the value with a
   random number so that the blinded value can take on all numbers
   between 1 and p-1 with equal probability while not changing its
   quadratic residuosity.  Determining the quadratic residue in a
   fashion that resists leakage of information is handled by flipping a
   coin and multiplying the blinded value by either a random quadratic
   residue or a random quadratic nonresidue and checking whether the
   multiplied value is a quadratic residue (qr) or a quadratic
   nonresidue (qnr) modulo p, respectively.  The random residue and
   nonresidue can be calculated prior to hunting and pecking by
   calculating the Legendre symbol on random values until they are
   found:

      do {
        qr = random() mod p
      } while ( lgr(qr, p) != 1)

      do {
        qnr = random() mod p
      } while ( lgr(qnr, p) != -1)

   Algorithmically, the masking technique to find out whether or not a
   value is a quadratic residue looks like this:

      is_quadratic_residue (val, p) {
          r = (random() mod (p - 1)) + 1
          num = (val * r * r) mod p
          if ( lsb(r) == 1 )
             num = (num * qr) mod p
             if ( lgr(num, p) == 1)
             then
                return TRUE
             fi
          else
             num = (num * qnr) mod p
             if ( lgr(num, p) == -1)
             then
                return TRUE
             fi
          fi
          return FALSE
      }


2.8.3.2.  FFC Operation for pwe

   The group-specific operation for FFC groups takes pwd-value, and the
   prime, p, and order, r, from the group's domain parameter set (see
   Section 2.2.1 when the order is not part of the defined domain
   parameter set) to directly produce a candidate Password Element, pwe,
   by exponentiating the pwd-value to the value ((p-1)/r) modulo the
   prime.  If the result is greater than one (1), the candidate pwe
   becomes pwe, and the hunting and pecking continues.

   Algorithmically, the process looks like this:

      found = 0
      counter = 1
      do {
        pwd-seed = H(token | peer-ID | server-ID | password | counter)
        pwd-value = KDF(pwd-seed, "EAP-pwd Hunting And Pecking", len(p))
        if (pwd-value < p)
        then
          temp = pwd-value ^ ((p-1)/r) mod p
          if (temp > 1)
          then
            found = 1
	    pwe = temp
          fi
        fi
        counter = counter + 1
      } while ((found == 0) || (counter < k))

                    Figure 4: Fixing PWE for FFC Groups

Notes:

The key exchange in EAP-pwd is dragonfly which was described in RFC 7664. During the standardization of RFC 7664, comments were received to prevent a side-channel attack against the hunting-and-pecking loop and the technique used in RFC 7664 should be done in RFC 5931 to prevent side-channel attack.

RFC 5939, "Session Description Protocol (SDP) Capability Negotiation", September 2010

Note: This RFC has been updated by RFC 6871

Source of RFC: mmusic (rai)

Errata ID: 5042
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Typo in example
Date Reported: 2017-06-16

Section 4.2 says:

m=audio 59000 UDP/TLS/RTP/AVP 98

It should say:

m=audio 59000 UDP/TLS/RTP/SAVP 98

Notes:

The example missed an S in the mine type. The list of allowed types is at https://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml#sdp-parameters-2 and UDP/TLS/RTP/AVP is not a registered device. Because this is over TLS, it is a SRTP (not RTP) and should use SAVP not AVP.

RFC 5942, "IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes", July 2010

Source of RFC: 6man (int)

Errata ID: 6417
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ted Lemon
Date Reported: 2021-01-29

Section 4 says:

In bullet item 4, the behavior for hosts when the default router list is empty is specified in a way that means that no prefix can ever be considered on-link.  4.b says that address resolution (which I take to mean neighbor discovery) should not be performed for any non-link-local address.

It is entirely possible for an on-link, non-default router to advertise an on-link prefix. In this case, the prefix should be considered on-link, and address resolution should be permitted. I don't see a way to read the text to allow this.

It should say:

I think the confusion is in 4.b, which should read:

The host MUST NOT perform address resolution for non-link-local addresses that are not known to be on-link as described in section 3, part 1.

Notes:

I don't know if the problem is that "non-link-local" should have been "non-on-link" or if the authors just weren't taking RFC4191 into consideration, but in the presence of RFC4191, requiring a default router before a prefix can be considered on-link renders perfectly valid configurations non-functional.

RFC 5952, "A Recommendation for IPv6 Address Text Representation", August 2010

Source of RFC: 6man (int)

Errata ID: 4985
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Julian de Prado
Date Reported: 2017-03-31

Section 2.2 says:

In cases where there is more than one field of only zeros, there is a
choice of how many fields can be shortened.

2001:db8:0:0:0::1
2001:db8:0:0::1
2001:db8:0::1
2001:db8::1

It should say:

In cases where there is more than one field of only zeros,there is a
choice of how many fields can be shortened, but must be shortened to 
its maximum capability.

2001:db8:0:0:0::1 is NOT acceptable
2001:db8:0:0::1 is NOT acceptable
2001:db8:0::1 is NOT acceptable
2001:db8::1 is CORRECT

Notes:

Applying section 4.2.1

Errata ID: 6272
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Felipe Gasper
Date Reported: 2020-09-02

Section 4.2.1 says:

The line

> The use of the symbol "::" MUST be used to its maximum capability.

… contradicts the next section, which states that single-0 fields are not reduced.

i.e., this:

> 2001:db8:0:1:1:1:1:1

… is longer than:

> 2001:db8::1:1:1:1:1

Thus, the standard does not, in all cases, require that "::" be used to its maximum capability.

It should say:

The first line of 4.2.1 should be amended to be consistent with section 4.2.2

> The use of the symbol "::" MUST be used to its maximum capability to reduce consecutive 16-bit 0 fields.

RFC 5954, "Essential Correction for IPv6 ABNF and URI Comparison in RFC 3261", August 2010

Source of RFC: sip (rai)

Errata ID: 4929
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: David van Moolenbroek
Date Reported: 2017-02-08

Section 3.1 says:

   Because the <hexpart> production rule is defined such that two of its
   alternatives already include the "::" token, this may yield to the
   faulty construction of an IPv6-mapped IPv4 address with an extra
   colon when expanding those alternatives.

It should say:

   Because the <hexpart> production rule is defined such that two of its
   alternatives already include the "::" token, this may yield to the
   faulty construction of an IPv4-mapped IPv6 address with an extra
   colon when expanding those alternatives.

Notes:

The text refers to an IPv6 address, and thus should use the proper term "IPv4-mapped IPv6 address," in line with the section title, the rest of the document, and (in particular) RFC 4291.

RFC 5958, "Asymmetric Key Packages", August 2010

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 5962
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Kevin Braun
Date Reported: 2020-01-22

Section Appendix A says:

   PrivateKeyAlgorithms ALGORITHM ::= {
     ... -- Extensible
   }

   KeyEncryptionAlgorithms ALGORITHM ::= {
     ... -- Extensible
   }

It should say:

   PrivateKeyAlgorithms PUBLIC-KEY ::= {
     ... -- Extensible
   }

   KeyEncryptionAlgorithms CONTENT-ENCRYPTION ::= {
     ... -- Extensible
   }

Notes:

The above given information object sets are used in defining types PrivateKeyAlgorithmIdentifier and EncryptionAlgorithmIdentifier:

PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier
{ PUBLIC-KEY,
{ PrivateKeyAlgorithms } }

EncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
{ CONTENT-ENCRYPTION,
{ KeyEncryptionAlgorithms } }

The parameterized type AlgorithmIdentifier has two parameters, one an information object class and the other an information object set. The information object set must be contain objects of the given class, or else the table constraint in AlgorithmIdentifier will not be valid. This requirement is not met as PrivateKeyAlgorithms and KeyEncryptionAlgorithms are currently defined, and therefore the definition is not valid according to ITU-T X.682.

An alternative correction would be to change the type definitions to specify "ALGORITHM" in the invocation of the parameterized type AlgorithmIdentifier.

RFC 5965, "An Extensible Format for Email Feedback Reports", August 2010

Note: This RFC has been updated by RFC 6650

Source of RFC: marf (app)

Errata ID: 5446
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Martijn van der Lee
Date Reported: 2018-07-30

Section B.2 says:

Authentication-Results: mail.example.com;
                  spf=fail smtp.mail=somespammer@example.com

It should say:

Authentication-Results: mail.example.com;
                  spf=fail smtp.mail=somespammer@example.net

Notes:

The TLD of the spammer's emailaddress should be `.net` as in the rest of the example.

RFC 6030, "Portable Symmetric Key Container (PSKC)", October 2010

Source of RFC: keyprov (sec)

Errata ID: 3811
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ivan Micanovic
Date Reported: 2013-11-25

Section 4.1. says:

All the elements listed above (and those defined in the future)
      obey a simple structure in that they MUST support child elements
      to convey the data value in either plaintext or encrypted format:

      Plaintext:  The <PlainValue> element carries a plaintext value
         that is typed, for example, to xs:integer.

      Encrypted:  The <EncryptedValue> element carries an encrypted
         value.

Notes:

In case that <Counter>, <Time>, <TimeInterval> or <TimeDrift> are encrypted in the PSKC file, the standard doesn't say anything about how to interpret this encrypted data.
After decrypting those values we have byte array.

Example:
Counter plain text value: 10000 decimal

In the case that this value is encrypted and later decrypted what should we expect?
Byte content 0x27 0x10 or 0x01 0x00 0x00 or something else?

1. Byte content 0x27 0x10 is interpreted as 10000 decimal if this bytes are interpreted as binary data (Big endian).
2. Byte content 0x01 0x00 0x00 is interpreted as 10000 decimal if this bytes are interpreted as hex data (Big endian).
Each hex digit will be mapped to a resulting decimal digit. From my point of view this way is a bit confusing.

My proposal to solve this issue is described in 1.

Errata ID: 4643
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Arthur de Jong
Date Reported: 2016-03-19

Section 4.3.4 says:

...
      'CheckDigit':  This attribute indicates whether a device needs to
         check the appended Luhn check digit, as defined in
         [ISOIEC7812], contained in a challenge.
...
      'CheckDigit':  This attribute indicates whether the device needs
         to append a Luhn check digit, as defined in [ISOIEC7812], to
         the response.
...

It should say:

...
      'CheckDigits':  This attribute indicates whether a device needs to
         check the appended Luhn check digit, as defined in
         [ISOIEC7812], contained in a challenge.
...
      'CheckDigits':  This attribute indicates whether the device needs
         to append a Luhn check digit, as defined in [ISOIEC7812], to
         the response.
...

Notes:

The text notes the singular CheckDigit while the schema specifies the plural CheckDigits. Either the text or the schema should be changed. Some implementations in the while seem to use the plural form.

Errata ID: 5034
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Arthur de Jong
Date Reported: 2017-06-08

Section 6.1 says:

 Camellia128    | http://www.w3.org/2001/04/xmldsig-more#camellia128
 Camellia192    | http://www.w3.org/2001/04/xmldsig-more#camellia192
 Camellia256    | http://www.w3.org/2001/04/xmldsig-more#camellia256

It should say:

 Camellia128-CBC| http://www.w3.org/2001/04/xmldsig-more#camellia128-cbc
 Camellia192-CBC| http://www.w3.org/2001/04/xmldsig-more#camellia192-cbc
 Camellia256-CBC| http://www.w3.org/2001/04/xmldsig-more#camellia256-cbc

Notes:

The original URIs are not defined in RFC 4051 but the URIs with -cbc appended are which and those are what was probably meant.

Errata ID: 7006
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Flavio Poletti
Date Reported: 2022-06-26

Section 4.1 says:

      ValueMAC:  The <ValueMAC> element is populated with a Message
         Authentication Code (MAC) generated from the encrypted value in
         case the encryption algorithm does not support integrity
         checks.  The example shown in Figure 2 illustrates the usage of
         the <Data> element with two child elements, namely <Secret> and
         <Counter>.  Both elements carry a plaintext value within the
         <PlainValue> child element.

It should say:

      ValueMAC:  The <ValueMAC> element is populated with a Message
         Authentication Code (MAC) generated from the encrypted value in
         case the encryption algorithm does not support integrity
         checks.

      The example shown in Figure 2 illustrates the usage of the <Data>
      element with one child element <Secret>.  This element carries a
      plaintext value within the <PlainValue> child element.

Notes:

There are two issues:
- the comment about the example should be in a standalone paragraph and not as a continuation of the explanation for ValueMAC
- the example in Figure 2 does *not* include <Counter>. The correction might be done to Figure 2, adding an XML fragment for <Counter> inside <Data>.

RFC 6056, "Recommendations for Transport-Protocol Port Randomization", January 2011

Source of RFC: tsvwg (wit)

Errata ID: 7873
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Štěpán Němec
Date Reported: 2024-03-27

Section 3.3.3 says:

(this "separation of the
ephemeral port space" means that transport-protocol instances with
different remote endpoints will not have different sequences of port
numbers, i.e., will not be part of the same ephemeral port sequence
as in the case of the traditional BSD ephemeral port selection
algorithm)

It should say:

(this "separation of the
ephemeral port space" means that transport-protocol instances with
different remote endpoints will have different sequences of port
numbers, i.e., will not be part of the same ephemeral port sequence
as in the case of the traditional BSD ephemeral port selection
algorithm)

Notes:

Drop the first "not", otherwise the two parts of the sentence (before and after "i.e.") are contradictory and the whole parenthetical doesn't match the context.

RFC 6063, "Dynamic Symmetric Key Provisioning Protocol (DSKPP)", December 2010

Source of RFC: keyprov (sec)

Errata ID: 5314
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Walter Summonte
Date Reported: 2018-03-29

Section 3.4.1.1. says:

checksum of 0x356, resulting in a Checksum TLV of "334D5"

It should say:

checksum of 0xEA4C, resulting in a Checksum TLV of "304EA4C"

Notes:

The ALG_ISO3309_CRC16 should be based on polynomial : x^16+x^12+x^5+1

width=16 poly=0x1021 init=0x0000 refin=false refout=false xorout=0xffff

It should it be zero left padded

RFC 6066, "Transport Layer Security (TLS) Extensions: Extension Definitions", January 2011

Note: This RFC has been updated by RFC 8446, RFC 8449, RFC 9325

Source of RFC: tls (sec)

Errata ID: 5658
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Owen Friel
Date Reported: 2019-03-14

Section 3 says:

It should say:

When a client uses DNS SRV to discover and connect to a server, the 
client SHOULD include the "source domain" in the "host_name" and SHOULD
NOT include the "derived domain", where "source domain" and "derived
domain" are defined in RFC6125. 

Notes:

The original text is all fine, but it is missing some additional clarifying text on use of SNI when a client users DNS SRV to discover the service it is connecting to.

RFC 6068, "The 'mailto' URI Scheme", October 2010

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 4706
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: stream9
Date Reported: 2016-06-08

Section 2.3 says:

3.  Whitespace and comments within <local-part> and <domain> MUST NOT
    be used.  They would not have any operational semantics.

It should say:

3.  Whitespace and comments within <local-part> and <domain> MUST NOT
    be used except quoted whitespace in <quoted-string>. 
    They would not have any operational semantics.

Notes:

<local-part> contain <quoted-string> and <quoted-string> contains <quoted-pair> according to definition in RFC 5322.

quoted-pair = ("\" (VCHAR / WSP)) / obs-qp

As definition above, <quoted-pair> contains whitespace <WSP> which according to RFC 6068, MUST NOT be used.

But example in RFC 6068 section 6.2 contain quoted whitespace. So I guess this is an exception.

RFC 6090, "Fundamental Elliptic Curve Cryptography Algorithms", February 2011

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 6329
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yannik Klubertanz
Date Reported: 2020-11-06

Section F.1. says:

     if P is (@,@),
        R = Q
     else if Q is (@,@),
        R = P
     else if P is not equal to Q and x1 is equal to x2,
        R = (@,@)
     else if P is not equal to Q and x1 is not equal to x2,
        x3 = ((y2-y1)/(x2-x1))^2 - x1 - x2 mod p and
        y3 = (x1-x3)*(y2-y1)/(x2-x1) - y1 mod p
     else if P is equal to Q and y1 is equal to 0,
        R = (@,@)
     else    // P is equal to Q and y1 is not equal to 0
        x3 = ((3*x1^2 + a)/(2*y1))^2 - 2*x1 mod p and
        y3 = (x1-x3)*(3*x1^2 + a)/(2*y1) - y mod p.

It should say:

     if P is (@,@),
        R = Q
     else if Q is (@,@),
        R = P
     else if P is not equal to Q and x1 is equal to x2,
        R = (@,@)
     else if P is not equal to Q and x1 is not equal to x2,
        x3 = ((y2-y1)/(x2-x1))^2 - x1 - x2 mod p and
        y3 = (x1-x3)*(y2-y1)/(x2-x1) - y1 mod p
     else if P is equal to Q and y1 is equal to 0,
        R = (@,@)
     else    // P is equal to Q and y1 is not equal to 0
        x3 = ((3*x1^2 + a)/(2*y1))^2 - 2*x1 mod p and
        y3 = (x1-x3)*(3*x1^2 + a)/(2*y1) - y1 mod p.

Notes:

In the last case in the pseudocode, there's a typo. It should be "y1" mod p instead of "y mod p".

RFC 6120, "Extensible Messaging and Presence Protocol (XMPP): Core", March 2011

Note: This RFC has been updated by RFC 7590, RFC 8553

Source of RFC: xmpp (rai)

Errata ID: 4228
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Georg Sauthoff
Date Reported: 2015-01-10

Section A.6. says:

     <xs:element name='subject'>
       <xs:complexType>
         <xs:simpleContent>
           <xs:extension base='xs:string'>
             <xs:attribute ref='xml:lang' use='optional'/>
           </xs:extension>
         </xs:simpleContent>
       </xs:complexType>
     </xs:element>

     <xs:element name='thread'>
       <xs:complexType>
         <xs:simpleContent>
           <xs:extension base='xs:NMTOKEN'>
             <xs:attribute name='parent'
                           type='xs:NMTOKEN'
                           use='optional'/>
           </xs:extension>
         </xs:simpleContent>
       </xs:complexType>
     </xs:element>














Saint-Andre                  Standards Track                  [Page 202]

 
RFC 6120                        XMPP Core                     March 2011


     <xs:element name='subject'>
       <xs:complexType>
         <xs:simpleContent>
           <xs:extension base='xs:NMTOKEN'>
             <xs:attribute name='parent'
                           type='xs:NMTOKEN'
                           use='optional'/>
           </xs:extension>
         </xs:simpleContent>
       </xs:complexType>
     </xs:element>

It should say:

     <xs:element name='subject'>
       <xs:complexType>
         <xs:simpleContent>
           <xs:extension base='xs:string'>
             <xs:attribute ref='xml:lang' use='optional'/>
           </xs:extension>
         </xs:simpleContent>
       </xs:complexType>
     </xs:element>

     <xs:element name='thread'>
       <xs:complexType>
         <xs:simpleContent>
           <xs:extension base='xs:NMTOKEN'>
             <xs:attribute name='parent'
                           type='xs:NMTOKEN'
                           use='optional'/>
           </xs:extension>
         </xs:simpleContent>
       </xs:complexType>
     </xs:element>














Saint-Andre                  Standards Track                  [Page 202]

 
RFC 6120                        XMPP Core                     March 2011

Notes:

The issue is that the definition of the referenced element 'subject' is duplicated.

This can be easily tested via a command like:

$ xmllint --schema XMLSchema_1.1.xsd server.xsd --noout
server.xsd:84: element element: Schemas validity error : Element '{http://www.w3.org/2001/XMLSchema}element': Duplicate key-sequence ['subject'] in key identity-constraint '{http://www.w3.org/2001/XMLSchema}element'.
server.xsd fails to validate

The corrected text contains one possible edit how to make the XSD of the server namespace valid again. Of course, another possibility would be to remove the first definition of the 'subject' element.

I've eliminated the second definition because the first one equals the one from section A.5. (Client Namespace).

RFC 6125, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", March 2011

Note: This RFC has been obsoleted by RFC 9525

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 5654
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Owen Friel
Date Reported: 2019-03-13

Section 7.4 says:

   A more recent approach, formally specified in [TLS-EXT], is for the
   client to use the TLS "Server Name Indication" (SNI) extension when
   sending the client_hello message, stipulating the DNS domain name it
   desires or expects of the service.  The service can then return the
   appropriate certificate in its Certificate message, and that
   certificate can represent a single DNS domain name.

It should say:

   A more recent approach, formally specified in [TLS-EXT], is for the
   client to use the TLS "Server Name Indication" (SNI) extension when
   sending the client_hello message, stipulating the DNS domain name it
   desires or expects of the service.  The service can then return the
   appropriate certificate in its Certificate message, and that
   certificate can represent a single DNS domain name. The client SHOULD
   include the "source domain" in the SNI extension and SHOULD NOT
   include the “derived domain”.

Notes:

There is nothing wrong with the text, however its missing some clarifying text.

When a client discovers a service using SRV, when it is doing TLS it should include the "source domain" in the SNI extension and SHOULD NOT include the “derived domain” in SNI. Now, this is obviously the correct thing to do. However, it doesnt explicitly state this anywhere in the RFC, or in RFC6066.

Errata ID: 5673
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael James
Date Reported: 2019-03-25

Throughout the document, when it says:

   If the certificate will be used for only a single type of application
   service, then the service provider is encouraged to request a
   certificate that includes a DNS-ID and, if appropriate for the
   application service type, an SRV-ID or URI-ID that limits the
   deployment scope of the certificate to only the defined application
   service type.

It should say:

   If the certificate will be used for only a single type of application
   service, the service provider is encouraged to request a
   certificate that includes a DNS-ID and, if appropriate for the
   application service type, an SRV-ID or URI-ID that limits the
   deployment scope of the certificate to only the defined application
   service type.

Notes:

All the sentences in the RFC (not just the one above) are written as pseudo code using IF...THEN. Normative English sentence structure the IF is a Conjunction for a Subordinating Clause. The THEN after the comma should be dropped to start the subject or main clause of the sentence.

Errata ID: 6325
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: tom petch
Date Reported: 2020-11-06

Section 10.2 says:

  [X.520]          International Telecommunications Union, "Information
                    Technology - Open Systems Interconnection - The
                    Directory: Selected attribute types", ITU-
                    T Recommendation X.509, ISO Standard 9594-6,
                    August 2005.

It should say:

  [X.520]          International Telecommunications Union, "Information
                    Technology - Open Systems Interconnection - The
                    Directory: Selected attribute types", ITU-
                    T Recommendation X.520, ISO Standard 9594-6,
                    August 2005.

Notes:

Selected attribute types is X.520 not X.509

RFC 6143, "The Remote Framebuffer Protocol", March 2011

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rai

Errata ID: 4951
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Simon Kissane
Date Reported: 2017-02-26

Section 7.2.2 says:

   The client encrypts the challenge with DES, using a password supplied
   by the user as the key.  To form the key, the password is truncated
   to eight characters, or padded with null bytes on the right.  The
   client then sends the resulting 16-byte response:

It should say:

   The client encrypts the challenge with DES, using a password supplied
   by the user as the key.  To form the key, the password is truncated
   to eight characters, or padded with null bytes on the right; then the
   bits of each byte of the key are reversed. The client then sends the
   resulting 16-byte response:

Notes:

Added text "; then the bits of each byte of the key are reversed" is essential to implementation of a VNC client or server which interoperates with existing VNC clients or servers, but the text fails to mention this.

See https://www.vidarholen.net/contents/junk/vnc.html

I confirmed the claims of the above web page while writing my own VNC server. I implemented VNC authentication without mirroring the bytes of the DES key and TigerVNC 1.5.0 could not authenticate to my VNC server. When I added code to mirror each byte of the DES key as described by the above web page, TigerVNC 1.5.0 could authenticate to my test VNC server.

RFC 6154, "IMAP LIST Extension for Special-Use Mailboxes", March 2011

Source of RFC: morg (app)

Errata ID: 5265
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Roy A. Gilmore
Date Reported: 2018-02-25

Throughout the document, when it says:

Notes:

In RFC6154, the special-use attributes are consistently shown with initial capitals, but there doesn't appear to be any guidance whether the special-use attributes are case-sensitive, case-insensitive, or implementation defined. This could lead to interoperability issues.

Errata ID: 5581
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Not clear whether SPECIAL-USE implies LIST-EXTENDED
Date Reported: 2018-12-21

Section 5.2 says:

     C: t1 CAPABILITY
     S: * CAPABILITY IMAP4rev1 SPECIAL-USE
     S: t1 OK done

It should say:

     C: t1 CAPABILITY
     S: * CAPABILITY IMAP4rev1 SPECIAL-USE LIST-EXTENDED
     S: t1 OK done

Notes:

Is it okay for a server to support SPECIAL-USE without supporting LIST-EXTENDED? The example seems to imply this, but it's not clear from the RFC text. Section 2 starts with: "For the extended list command [RFC5258]", but doesn't say the server MUST support LIST-EXTENDED.

RFC 6164, "Using 127-Bit IPv6 Prefixes on Inter-Router Links", April 2011

Note: This RFC has been updated by RFC 6547

Source of RFC: 6man (int)

Errata ID: 5080
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: toerless Eckert
Date Reported: 2017-08-08

Throughout the document, when it says:

Request for Comments: 6164
Category: Standards Track

It should say:

Request for Comments: 6164
Category: Standards Track
Updates: RFC4291

Notes:

The solution described in RFC6164 updates RFC4291 because it violates the requirement of RFC4291 section 2.5.1 for the IIDs to be 64-bit long and be constructed from EUI-64 format.

Please feel free to reconfirm with 6man WG. In Prague, the suggestion was made that all documents introducing solutions that are not compliant with this requirement must be tracked as updated to RFC6164. When i asked on the list recently, i was given the suggestion to file an Errata as i am doing right now.

Note that i think that i do not think that "just wait for rfc4291bis" would be a good answer to this errata because rfc6164 of course predates it, and even more so, correct proedural tracking of rfc4291 updates can potentially help the process of getting to rfc4291bis.

RFC 6174, "Definition of IETF Working Group Document States", March 2011

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 7747
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: John Klensin
Date Reported: 2024-01-01

Section 4.2.10 says:

An I-D in this state may be under review by the IESG, it may have been approved and be in the RFC Editor's queue, or it may have been published as an RFC.  Other possibilities exist too.  The document may be "Dead" (in the IESG state machine) or in a "Do Not Publish" state.

It should say:

An I-D in this state may be under review by the IESG, it may be awaiting or in IETF Last Call,  may have been approved and be in the RFC Editor's queue, or it may have been published as an RFC.  Other possibilities, most of which show less progress, exist too.  For example, the document may be "Dead" (in the IESG state machine) or in a "Do Not Publish" state.

Notes:

I think this is actually an editorial problem in the traditional sense of the term, but it is not "a spelling, grammar, punctuation, or syntax error" and hence is probably "Technical" as defined above.

Section 4.2.10 of this document, and hence the description of the corresponding "WG Status" entry in the datatracker (<https://datatracker.ietf.org/doc/help/state/draft-stream-ietf/>) leave out the all-important "In Last Call" and the states leading up to it. That is a potential source of confusion for newcomers and even experienced participants who have concentrated more on getting work done than on the intricacies of IETF processes and process-related terminology. While, because of Appendix A and references to it, the change is less important for this document than for the datatracker excerpt, a change like the above could considerably reduce those opportunities for confusion.

At the same time, while I think a fix to the datatracker is fairly important, I believe this change should be relatively low priority unless someone insists that the datatracker material cannot be changed without updating this document.

RFC 6228, "Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog", May 2011

Source of RFC: sipcore (rai)

Errata ID: 4886
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Brett Tate
Date Reported: 2016-12-13

Section 5 says:

   If the Supported header field of an initial dialog initiation request
   does not contain a "199" option-tag, the UAC MUST NOT send a 199
   response on any early dialog associated with the request.

It should say:

   If the Supported header field of an initial dialog initiation request
   does not contain a "199" option-tag, the UAS MUST NOT send a 199
   response on any early dialog associated with the request.

Notes:

Changed "UAC" to "UAS" since the UAC does not send responses.

RFC 6230, "Media Control Channel Framework", May 2011

Source of RFC: mediactrl (rai)

Errata ID: 7596
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Kim Hermansson
Date Reported: 2023-08-11

Section 9.1 says:

ext-header = hname ":" SP hval CRLF

It should say:

ext-header = hname ":" SP hval

Notes:

Same as errata 1954 (RFC 4975); the rule:

headers = header-name CRLF

already suffixes every header with a CRLF. The result is that the extension headers are followed by 2 CRLFs, introducing empty lines inside the header segment. This appears to be unintended, since none of the other headers have a terminating CRLF in their production rules, only the ext-header.

RFC 6234, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", May 2011

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 5240
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yeong-u Kim (K.)
Date Reported: 2018-01-21

Section 6 says:

6.1.  SHA-224 and SHA-256 Initialization

   For SHA-224, the initial hash value, H(0), consists of the following
   32-bit words in hex:

      H(0)0 = c1059ed8
      H(0)1 = 367cd507
      H(0)2 = 3070dd17
      H(0)3 = f70e5939
      H(0)4 = ffc00b31
      H(0)5 = 68581511
      H(0)6 = 64f98fa7
      H(0)7 = befa4fa4

It should say:

6.1.  SHA-224 and SHA-256 Initialization

   For SHA-224, the initial hash value, H(0), consists of the following
   32-bit words in hex.  These words were obtained by taking the second
   32 bits of the fractional parts of the square roots of the ninth
   through sixteenth prime numbers.

      H(0)0 = c1059ed8
      H(0)1 = 367cd507
      H(0)2 = 3070dd17
      H(0)3 = f70e5939
      H(0)4 = ffc00b31
      H(0)5 = 68581511
      H(0)6 = 64f98fa7
      H(0)7 = befa4fa4

Notes:

The explanation for the way in which the initial hash value of SHA-224 was obtained is missing.

Errata ID: 6523
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: David Óscar Solé González
Date Reported: 2021-04-08

Section 6.4 says:

   For i = 1 to N

      1. Prepare the message schedule W:
         For t = 0 to 15
            Wt = M(i)t
         For t = 16 to 79
            Wt = SSIG1(W(t-2)) + W(t-7) + SSIG0(W(t-15)) + W(t-16)

      2. Initialize the working variables:
         a = H(i-1)0
         b = H(i-1)1
         c = H(i-1)2
         d = H(i-1)3
         e = H(i-1)4
         f = H(i-1)5
         g = H(i-1)6
         h = H(i-1)7

      3. Perform the main hash computation:
         For t = 0 to 79
            T1 = h + BSIG1(e) + CH(e,f,g) + Kt + Wt
            T2 = BSIG0(a) + MAJ(a,b,c)
            h = g
            g = f
            f = e
            e = d + T1
            d = c
            c = b
            b = a
            a = T1 + T2

         4. Compute the intermediate hash value H(i)
            H(i)0 = a + H(i-1)0
            H(i)1 = b + H(i-1)1
            H(i)2 = c + H(i-1)2
            H(i)3 = d + H(i-1)3
            H(i)4 = e + H(i-1)4
            H(i)5 = f + H(i-1)5
            H(i)6 = g + H(i-1)6
            H(i)7 = h + H(i-1)7

It should say:

   For i = 1 to N

      1. Prepare the message schedule W:
         For t = 0 to 15
            Wt = M(i)t
         For t = 16 to 79
            Wt = SSIG1(W(t-2)) + W(t-7) + SSIG0(W(t-15)) + W(t-16)

      2. Initialize the working variables:
         a = H(i-1)0
         b = H(i-1)1
         c = H(i-1)2
         d = H(i-1)3
         e = H(i-1)4
         f = H(i-1)5
         g = H(i-1)6
         h = H(i-1)7

      3. Perform the main hash computation:
         For t = 0 to 79
            T1 = h + BSIG1(e) + CH(e,f,g) + Kt + Wt
            T2 = BSIG0(a) + MAJ(a,b,c)
            h = g
            g = f
            f = e
            e = d + T1
            d = c
            c = b
            b = a
            a = T1 + T2

      4. Compute the intermediate hash value H(i)
         H(i)0 = a + H(i-1)0
         H(i)1 = b + H(i-1)1
         H(i)2 = c + H(i-1)2
         H(i)3 = d + H(i-1)3
         H(i)4 = e + H(i-1)4
         H(i)5 = f + H(i-1)5
         H(i)6 = g + H(i-1)6
         H(i)7 = h + H(i-1)7

Notes:

Identation correction on point 4. as it may lead to confussion and reader may think that point (4) may be done inside a loop (begining on point (3).

RFC 6238, "TOTP: Time-Based One-Time Password Algorithm", May 2011

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 4249
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: David Woodhouse
Date Reported: 2015-01-30

Section 4.2 says:

The provisioning flow is out of scope of this document; refer to
[RFC6030] for such provisioning container specifications.

Notes:

It's insufficient to simply refer to RFC6030 here. See RFC6030 §4.3.4 where it states that the precise semantics of fields such as the <Suite> element are defined according to the algorithm profile. It does provide in §10 the definitions for HOTP and PIN algorithms — but it doesn't give them for TOTP because the standardisation of TOTP came later.

So *someone* needs to tell us what strings to put in the <Suite> element to indicate SHA1/SHA256/SHA512 etc. Either an update to RFC6030, or I would have thought it was better done with a section in RFC6238... which is missing.

Am I missing something?

Errata ID: 4530
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Simone Campagna
Date Reported: 2015-11-11

Section Appendix A says:

 public static String generateTOTP(String key,
             String time,
             String returnDigits){
         return generateTOTP(key, time, returnDigits, "HmacSHA1");
     }

Notes:

Function will be recursive on his self. Maybe forget a second condition or statement?

Errata ID: 5132
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Gerrit Jansen van Vuuren
Date Reported: 2017-09-28

Section Appendix B says:

The test token shared secret uses the ASCII string value
   "12345678901234567890"

It should say:

The test token used for each SHA mode is:
// Seed for HMAC-SHA1 - 20 bytes
         String seed = "3132333435363738393031323334353637383930";
         // Seed for HMAC-SHA256 - 32 bytes
         String seed32 = "3132333435363738393031323334353637383930" +
         "313233343536373839303132";
         // Seed for HMAC-SHA512 - 64 bytes
         String seed64 = "3132333435363738393031323334353637383930" +
         "3132333435363738393031323334353637383930" +
         "3132333435363738393031323334353637383930" +
         "31323334";

Notes:

The text suggests that the secret "12345678901234567890" is used, when in fact this value cannot be found in the reference implementation test generation code and leads to different values (as is expected). The actual secret used is called seed, seed32 and seed64 in the reference implementation test generation code.

Errata ID: 7271
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Charly Coste
Date Reported: 2022-12-14

Section Appendix A says:

         result = Integer.toString(otp);
         while (result.length() < codeDigits) {
             result = "0" + result;
         }

It should say:

         result = Long.toString(10000000000L + otp);
         result = result.substring(11 - codeDigits);

Notes:

The generation of an OTP should run in constant time to ensure that an attacker can't use an observable timing discrepancy to infer the value of any of the generated digits.
This proposed correction has been applied to the pyotp and rotp implementations in https://github.com/pyauth/pyotp/pull/148 and https://github.com/mdp/rotp/pull/119

Errata ID: 4881
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Malte Simon
Date Reported: 2016-12-07

Section 8.2 says:

   [CN]       Coron, J. and D. Naccache, "An Accurate Evaluation of
              Maurer's Universal Test", LNCS 1556, February 1999,
              <http://www.gemplus.com/smart/rd/publications/pdf/
              CN99maur.pdf>.

It should say:

   [CN]       Coron, J. and D. Naccache, "An Accurate Evaluation of
              Maurer's Universal Test", Selected Areas in Cryptography: 
              SAC 1998, Lecture Notes in Computer Science Vol. 1556, 
              pp. 57-71, DOI: 10.1007/3-540-48892-8_5, February 1999,
              <http://www.jscoron.fr/publications/universal.pdf>.

Notes:

Gemplus (today Gemalto) no longer provide thie linked research paper.

RFC 6241, "Network Configuration Protocol (NETCONF)", June 2011

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

Source of RFC: netconf (ops)

Errata ID: 7624
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Jernej Tuljak
Date Reported: 2023-08-31

Section 4.3. says:

     <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <rpc-error>
         <error-type>rpc</error-type>
         <error-tag>missing-attribute</error-tag>
         <error-severity>error</error-severity>
         <error-info>
           <bad-attribute>message-id</bad-attribute>
           <bad-element>rpc</bad-element>
         </error-info>
       </rpc-error>
     </rpc-reply>

It should say:

     <nc:rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
       <nc:rpc-error>
         <nc:error-type>rpc</nc:error-type>
         <nc:error-tag>missing-attribute</nc:error-tag>
         <nc:error-severity>error</nc:error-severity>
         <nc:error-info>
           <nc:bad-attribute>message-id</nc:bad-attribute>
           <nc:bad-element>nc:rpc</nc:bad-element>
         </nc:error-info>
       </nc:rpc-error>
     </nc:rpc-reply>

Notes:

The original error response is referring to the NETCONF messages layer attribute "message-id", which does not belong to any XML namespace. The response is not properly encoding xs:QName values of elements "bad-attribute" and "bad-element" by placing them both into the default XML namespace. Proposed new text (while verbose) ensures that the values are placed into their respective proper XML namespaces.

RFC 6265, "HTTP State Management Mechanism", April 2011

Source of RFC: httpstate (app)

Errata ID: 6719
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip Gladstone
Date Reported: 2021-10-22

Section 4.1.1 says:

max-age-av        = "Max-Age=" non-zero-digit *DIGIT

It should say:

max-age-av           = "Max-Age=" non-negative-integer
non-negative-integer = zero-digit / (non-zero-digit *DIGIT)
zero-digit           = %x30

Notes:

In section 5.2.2, there is the following text on the value of the max-age:

> Let delta-seconds be the attribute-value converted to an integer.
>
> If delta-seconds is less than or equal to zero (0), let expiry-time
> be the earliest representable date and time.

If max-age is an integer greater than 0, then the entire sentence is meaningless. It is a common practice to use max-age=0 to expire a cookie immediately. I think that the ABNF is incorrect. However, I don't see any reason to permit negative values.

Errata ID: 7604
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ted Zhu
Date Reported: 2023-08-15

Section 3. Overview says:

User agents MAY ignore Set-Cookie headers contained in
responses with 100-level status codes but MUST process Set-Cookie
headers contained in other responses (including responses with 400-
and 500-level status codes).

It should say:

Cookie-enabled user agents MAY ignore Set-Cookie headers contained in
responses with 100-level status codes but MUST process Set-Cookie
headers contained in other responses (including responses with 400-
and 500-level status codes).

Notes:

The concern is that the sentence in its original form may be read to mean that all conforming user agents MUST process Set-Cookie headers contained in non 100-level responses, when, differing behavior is allowed as described in sections 5.2 and 7.2:

Section 5.2, paragraph 1: "When a user agent receives a Set-Cookie header field in an HTTP response, the user agent MAY ignore the Set-Cookie header field in its entirety."

Section 7.2, paragraph 2: "When cookies are disabled, ... the user agent MUST NOT process Set-Cookie headers in inbound HTTP responses."

The suggested correction is one possible way to alleviate this erratum concern. However, the erratum author does not know if this is the most optimal disambiguation method.

Errata ID: 5518
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Peter Wu
Date Reported: 2018-10-09

Section 4.1.1 says:

 cookie-octet      = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
                       ; US-ASCII characters excluding CTLs,
                       ; whitespace DQUOTE, comma, semicolon,
                       ; and backslash

It should say:

 cookie-octet      = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
                       ; US-ASCII characters excluding CTLs,
                       ; whitespace, DQUOTE, comma, semicolon,
                       ; and backslash

Notes:

Missing comma separator between "whitespace" and "DQUOTE".

Errata ID: 6093
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Attila Gulyas
Date Reported: 2020-04-12

Section 3 says:

Origin servers SHOULD NOT fold multiple Set-Cookie header fields into a single header field.  The usual mechanism for folding HTTP headers fields (i.e., as defined in [RFC2616]) might change the semantics of the Set-Cookie header field because the %x2C (",") character is used by Set-Cookie in a way that conflicts with such folding.

It should say:

Origin servers SHOULD NOT combine multiple Set-Cookie header fields into a single header field.  The usual mechanism for combining HTTP headers fields (i.e., as defined in [RFC2616]) might change the semantics of the Set-Cookie header field because the %x2C (",") character is used by Set-Cookie in a way that conflicts with such actions.

Notes:

RFC 6265 currently uses the verb "folding" when it refers to combining multiple header fields into one, which is ambiguous in the context of the HTTP/1 specs (both by RFC2616 and RFC 7230) where "folding" consistently refers to line folding, and the verb "combine" is used to describe merging same headers. Having a light HTTP knowledge, I naively started looking up "folding" in the HTTP specs, and was immediately confused by the results, others will probably be as well (especially is English is not their native tongue).

Examples to prove this consistency:
+ RFC 2616, Section 4.2, Message Headers, but searching for the for the word "combine" will bring up special cases.
+ RFC 7230, Section 3.2.2, Field Order
+ RFC 2616, Section 2.2, Basic Rules
+ RFC 7230, Section 3.2.4, Field Parsing

Thank you!

RFC 6270, "The 'tn3270' URI Scheme", June 2011

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 6502
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lars Eggert
Date Reported: 2021-03-29

Section 4 says:

      Author/Change controller: IETF <ietf@ietf.org>

It should say:

      Author/Change controller: IESG <iesg@ietf.org>

Notes:

If "the IETF" is supposed to be the change controller, that role is then held by the IESG (which also has a different email address.)

RFC 6282, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", September 2011

Note: This RFC has been updated by RFC 8066

Source of RFC: 6lowpan (int)

Errata ID: 4814
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dale R. Worley
Date Reported: 2016-09-27

Section 1 says:

Additionally, a Hop Limit value of 255 is often used to verify that a
communication occurs over a single-hop.

It should say:

Additionally, a Hop Limit value of 1 is often used to verify that a
communication occurs over a single-hop.

Notes:

The other Hop Limit values in this paragraph may also be mistaken.
The document treats the values 1, 64, and 255 specially, but fixing
this sentence would leave no reason for the value 255 to be treated
specially, so I expect that 255 is the value intended for another
sentence.

RFC 6287, "OCRA: OATH Challenge-Response Algorithm", June 2011

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 3730
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Simon Josefsson
Date Reported: 2013-09-17

Section 5.2 says:

   This table summarizes all possible values for the CryptoFunction:

     +---------------+--------------------+-------------------------+
     |      Name     | HMAC Function Used |  Size of Truncation (t) |
     +---------------+--------------------+-------------------------+
     |  HOTP-SHA1-t  |      HMAC-SHA1     | 0 (no truncation), 4-10 |
     | HOTP-SHA256-t |     HMAC-SHA256    | 0 (no truncation), 4-10 |
     | HOTP-SHA512-t |     HMAC-SHA512    | 0 (no truncation), 4-10 |
     +---------------+--------------------+-------------------------+

It should say:

   This table summarizes all possible values for the CryptoFunction:

     +---------------+--------------------+-------------------------+
     |      Name     | HMAC Function Used |  Size of Truncation (t) |
     +---------------+--------------------+-------------------------+
     |  HOTP-SHA1-t  |      HMAC-SHA1     | 0 (no truncation), 4-9  |
     | HOTP-SHA256-t |     HMAC-SHA256    | 0 (no truncation), 4-9  |
     | HOTP-SHA512-t |     HMAC-SHA512    | 0 (no truncation), 4-9  |
     +---------------+--------------------+-------------------------+

Notes:

The change disallows 10 digit OCRA codes. The reason for this is subtle and could be discussed. An alternative to disallowing 10 digit codes is to add a Security Consideration discussion about the behaviour when 10 is used.

The Truncate function defined in RFC 4226 section 5.3 works on 31-bit numbers and uses modulo 10^Digit. When Digit=10, that means 10^10. However, 2^31 is smaller than 10^10. This means that the output code can never take on values 2^31..10^10 which causes a significant bias in the number of valid codes.

The entire security analysis in RFC 4226 assumes this is not the case. For example quoting section A.5 "Security Analysis of HOTP": "Suppose m = 10^Digit < 2^31,".

To clarify, there is no attack enabled by this flaw. OCRA with 10 digit codes just doesn't offer as good security as it could. 10 digits is only roughly twice as secure as 9 digit codes instead of 10 times as one would expect.

Errata ID: 3899
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Marcus Bring
Date Reported: 2014-02-24

Section Appendix A. says:

// Put the bytes of "time" to the message
// Input is text value of minutes
    if(timeStampLength > 0){
        bArray = hexStr2Bytes(timeStamp);
        System.arraycopy(bArray, 0, msg, ocraSuiteLength + 1 +
            counterLength + questionLength +
            passwordLength + sessionInformationLength,
            bArray.length);
    }

It should say:

// Put the bytes of "time" to the message
// Input is HEX encoded value of minutes
    if(timeStampLength > 0){
        bArray = hexStr2Bytes(timeStamp);
        System.arraycopy(bArray, 0, msg, ocraSuiteLength + 1 +
            counterLength + questionLength +
            passwordLength + sessionInformationLength,
            bArray.length);
    }

Notes:

The timestamp should be HEX encoded since hexStr2Bytes() is used. Otherwise it will fail to generate the correct OTP

Errata ID: 4114
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Marc Girault
Date Reported: 2014-09-16

Section 7 says:

R = OCRA(K, {[C] | Q | [P | S | T]})

RS = OCRA(K, [C] | QC | QS | [S | T])

OCRA(K, [C] | QC | QS | [S | T]) != RS 

RC = OCRA(K, [C] | QS | QC | [P | S | T])

OCRA(K, [C] | QS | QC | [P|S|T]) != RC 

SIGN = OCRA(K, [C] | QS | [P | T])

RS = OCRA(K, [C] | QC | QS | [T]

OCRA(K, [C] | QC | QS | [T]) != RS

SIGN = OCRA( K, [C] | QS | QC | [P | T])

OCRA(K, [C] | QS | QC | [P|T]) != SIGN 

It should say:

R = CryptoFunction(K, OCRASuite | 00 | [C] | Q | [P | S | T])

RS = CryptoFunction(K, OCRASuite | 00 | [C] | QC | QS | [S | T])

CryptoFunction(K, OCRASuite | 00 | [C] | QC | QS | [S | T]) != RS 

RC = CryptoFunction(K, OCRASuite | 00 | [C] | QS | QC | [P | S | T])

CryptoFunction(K, OCRASuite | 00 | [C] | QS | QC | [P|S|T]) != RC

SIGN = CryptoFunction(K, OCRASuite | 00 | [C] | QS | [P | T])

RS = CryptoFunction(K, OCRASuite | 00 | [C] | QC | QS | [T]

CryptoFunction(K, OCRASuite | 00 | [C] | QC | QS | [T]) != RS  

SIGN = CryptoFunction( K, OCRASuite | 00 | [C] | QS | QC | [P | T])

CryptoFunction(K, OCRASuite | 00 | [C] | QS | QC | [P|T]) != SIGN

Notes:

Page 5, DataInput is defined as the concatenation of OCRASuite, byte 00 and five parameters. Pages 11 and subsequent ones, it is defined as the concatenation of only those five parameters, omitting OCRASuite and byte 00. This is technically inconsistent.

The proposed new text anticipates positive verification of errata n°4113 and supersedes it.

Errata ID: 5625
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Emanuele Giacomelli
Date Reported: 2019-02-07

Section Appendix A says:

// put selected bytes into result int
int offset = hash[hash.length - 1] & 0xf;

int binary =
  ((hash[offset] & 0x7f) << 24) |
  ((hash[offset + 1] & 0xff) << 16) |
  ((hash[offset + 2] & 0xff) << 8) |
  (hash[offset + 3] & 0xff);

int otp = binary % DIGITS_POWER[codeDigits];

result = Integer.toString(otp);
while (result.length() < codeDigits) {
  result = "0" + result;
}
return result;

It should say:

if (codeDigits > 0) {
  // put selected bytes into result int
  int offset = hash[hash.length - 1] & 0xf;

  int binary =
      ((hash[offset] & 0x7f) << 24) |
      ((hash[offset + 1] & 0xff) << 16) |
      ((hash[offset + 2] & 0xff) << 8) |
      (hash[offset + 3] & 0xff);

  int otp = binary % DIGITS_POWER[codeDigits];

  result = Integer.toString(otp);
  while (result.length() < codeDigits) {
      result = "0" + result;
  }
  return result;
} else {
  return asHex(hash);
}

Notes:

The code does not honor what the RFC says in section 5.2:

3. t=0 means that no truncation is performed and the full HMAC value
is used for authentication purposes

and still applies dynamic truncation to suites requesting "0" digits.
As a result, the computation performs a "modulo 1" operation causing
the code to always return 0 for such suites.

The proposed patch explicitly disables dynamic truncation for such suites and returns the full HMAC
encoded as a Base16 string. The "asHex" function is the same defined in Appendix B.

Errata ID: 4112
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marc Girault
Date Reported: 2014-09-16

Section 5 says:

OCRA = CryptoFunction(K, DataInput)

It should say:

R = CryptoFunction(K, DataInput)

Notes:

The acronym “OCRA” is used page 5 as the output of the CryptoFunction, page 9 as the name of a (family of) algorithm(s), in diagrams of pages 11, 13, 14 and 16 as a cryptographic function. This is inconsistent.

Errata ID: 4113
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marc Girault
Date Reported: 2014-09-16

Section 7 says:

R = OCRA(K, {[C] | Q | [P | S | T]})

RS = OCRA(K, [C] | QC | QS | [S | T])

OCRA(K, [C] | QC | QS | [S | T]) != RS -> STOP

RC = OCRA(K, [C] | QS | QC | [P | S | T])

OCRA(K, [C] | QS | QC | [P|S|T]) != RC -> STOP

SIGN = OCRA(K, [C] | QS | [P | T])

RS = OCRA(K, [C] | QC | QS | [T]

OCRA(K, [C] | QC | QS | [T]) != RS -> STOP 

SIGN = OCRA( K, [C] | QS | QC | [P | T])

OCRA(K, [C] | QS | QC | [P|T]) != SIGN -> STOP 

It should say:

R = CryptoFunction(K, {[C] | Q | [P | S | T]})

RS = CryptoFunction(K, [C] | QC | QS | [S | T])

CryptoFunction(K, [C] | QC | QS | [S | T]) != RS -> STOP

RC = CryptoFunction(K, [C] | QS | QC | [P | S | T])

CryptoFunction(K, [C] | QS | QC | [P|S|T]) != RC -> STOP

SIGN = CryptoFunction(K, [C] | QS | [P | T])

RS = CryptoFunction(K, [C] | QC | QS | [T]

CryptoFunction(K, [C] | QC | QS | [T]) != RS -> STOP 

SIGN = CryptoFunction( K, [C] | QS | QC | [P | T])

CryptoFunction(K, [C] | QS | QC | [P|T]) != SIGN -> STOP 

Notes:

The acronym “OCRA” is used page 5 as the output of the CryptoFunction, page 9 as the name of a (family of) algorithm(s), in diagrams of pages 11, 13, 14 and 16 as a cryptographic function. This is inconsistent.

Errata ID: 4115
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marc Girault
Date Reported: 2014-09-16

Section 5 says:

DataInput = {OCRASuite | 00 | C | Q | P | S | T} where:

   o  OCRASuite is a value representing the suite of operations to
      compute an OCRA response

It should say:

DataInput = {OCRASuite | 00 | [C] | Q | [P | S | T]) where:

   o  [] indicates a value is optional

   o  OCRASuite is a value representing the suite of operations to
      compute an OCRA response

Notes:

It is useful to know as early as possible which parameters are optional or not, especially as it is not exhaustively specified page 6.

Errata ID: 4116
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marc Girault
Date Reported: 2014-09-16

Section 5 says:

5.1.  DataInput Parameters

It should say:

5.1.  DataInput 

Notes:

DataInput means two different things in (contents of) section 5.1 and (title of) section 6.3. This is inconsistent.

Errata ID: 4117
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marc Girault
Date Reported: 2014-09-16

Section 6.3 says:

6.3.  DataInput

It should say:

6.3.  DataInput Parameters

Notes:

DataInput means two different things in (contents of) section 5.1 and (title of) section 6.3. This is inconsistent.

Errata ID: 4401
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Anthony
Date Reported: 2015-06-25

Section 6.4 says:

"OCRA-1:HOTP-SHA1-4:QH8-S512" means version 1 of OCRA with HMAC-
SHA1 function, truncated to a 4-digit value, using a random
hexadecimal challenge up to 8 nibbles and a session value of 512
bytes

It should say:

"OCRA-1:HOTP-SHA1-4:QH08-S512" means version 1 of OCRA with HMAC-
SHA1 function, truncated to a 4-digit value, using a random
hexadecimal challenge up to 8 nibbles and a session value of 512
bytes

Notes:

I have changed "QH8" to "QH08".

Errata ID: 5133
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mathieu Lechat
Date Reported: 2017-09-29

Section 6.3 says:

The input for S is further qualified by the length of the session
data in bytes.  The client and server could agree to any length but
the typical values are:

It should say:

The input for S is further qualified by the length of the session
data in bytes.  The client and server could agree to any length up to
512 but the typical values are:

Notes:

Section 6.3 it is said the session data can be any length, as it is three digits this means it could be from 000 to 999. However in section 5.1 it is said session data cannot exceed 512 bytes so this should be reflected.

RFC 6347, "Datagram Transport Layer Security Version 1.2", January 2012

Note: This RFC has been obsoleted by RFC 9147

Note: This RFC has been updated by RFC 7507, RFC 7905, RFC 8996, RFC 9146

Source of RFC: tls (sec)

Errata ID: 3917
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin Thomson
Date Reported: 2014-03-14

Section 4.2.1 says:

   struct {
     ProtocolVersion client_version;
     Random random;
     SessionID session_id;
     opaque cookie<0..2^8-1>;                             // New field
     CipherSuite cipher_suites<2..2^16-1>;
           CompressionMethod compression_methods<1..2^8-1>;
   } ClientHello;

It should say:

   struct {
     ProtocolVersion client_version;
     Random random;
     SessionID session_id;
     opaque cookie<0..2^8-1>;                             // New field
     CipherSuite cipher_suites<2..2^16-1>;
     CompressionMethod compression_methods<1..2^8-1>;
     select (extensions_present) {
       case false:
         struct {};
       case true:
         Extension extensions<0..2^16-1>;
     };
   } ClientHello;

Notes:

This also affects Section 4.3.2 where the same structure is repeated.

Extensions are a part of TLS. They are also part of DTLS in practice, but the RFC omits them. The corrected text includes the relevant part of the ClientHello from RFC 5246.

Errata ID: 4103
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Manuel Pégourié-Gonnard
Date Reported: 2014-09-08

Section 4.2.1 says:

   [p. 15]            DTLS 1.2 server implementations SHOULD use DTLS
   version 1.0 regardless of the version of TLS that is expected to be
   negotiated.

   [p. 16]                                The server MUST use the same
   version number in the HelloVerifyRequest that it would use when
   sending a ServerHello.

   [p. 15]      DTLS 1.2 and 1.0 clients MUST use the version solely to
   indicate packet formatting (which is the same in both DTLS 1.2 and
   1.0) and not as part of version negotiation.  In particular, DTLS 1.2
   clients MUST NOT assume that because the server uses version 1.0 in
   the HelloVerifyRequest that the server is not DTLS 1.2 or that it
   will eventually negotiate DTLS 1.0 rather than DTLS 1.2.

   [p. 16]                 Upon receipt of the ServerHello, the client
   MUST verify that the server version values match.

It should say:

   [p. 15]            DTLS 1.2 server implementations MAY use DTLS
   version 1.0 regardless of the version of TLS that is expected to be
   negotiated, or the version that is expected to be negotiated.

   [p. 15]      DTLS 1.2 and 1.0 clients MUST use the version solely to
   indicate packet formatting (which is the same in both DTLS 1.2 and
   1.0) and not as part of version negotiation.  In particular, DTLS 1.2
   clients MUST NOT assume that because the server uses version 1.0 in
   the HelloVerifyRequest that the server is not DTLS 1.2 or that it
   will eventually negotiate DTLS 1.0 rather than DTLS 1.2.

   [p. 16] [Delete text relating to HelloVerifyRequest.server_version]

Notes:

The statements on the bottom of page 15 and on the top of page 16 are mutually contradictory. It looks like the statements on page 16 were copied from RFC 4347, but the intention was to replace them with the version from page 15 in this revision of the standard.

Errata ID: 5186
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Chen Wumao
Date Reported: 2017-11-28

Section 4.2.4 says:

[p17]                                                 In order to avoid
   sequence number duplication in case of multiple HelloVerifyRequests,
   the server MUST use the record sequence number in the ClientHello as
   the record sequence number in the HelloVerifyRequest.

[p17]                  In order to avoid sequence number duplication in
   case of multiple cookie exchanges, the server MUST use the record
   sequence number in the ClientHello as the record sequence number in
   its initial ServerHello. 

It should say:

[p17]                                                 In order to avoid
   sequence number duplication in case of multiple HelloVerifyRequests,
   the server MUST use the message_seq in the ClientHello as
   the message_seq in the HelloVerifyRequest.

[p17]                  In order to avoid sequence number duplication in
   case of multiple cookie exchanges, the server MUST use the 
   message_seq in the ClientHello as the message_seq in
   its initial ServerHello. 

Notes:

the "record sequence number" here should be message_seq.

Errata ID: 4104
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Manuel Pégourié-Gonnard
Date Reported: 2014-09-08

Section 4.1 says:

   [Page 8]                                                   In order
   to ensure that any given sequence/epoch pair is unique,
   implementations MUST NOT allow the same epoch value to be reused
   within two times the TCP maximum segment lifetime.  In practice, TLS
   implementations rarely rehandshake; therefore, we do not expect this
   to be a problem.

It should say:

[Delete these two sentences.]

Notes:

Page 9 starts with: "Similarly, implementations MUST NOT allow the epoch to wrap" which is a stronger requirement (not allowing to wrap at all vs not allowing reuse within some period), so the weaker requirement should be eliminated to avoid confusion.

Errata ID: 4105
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Manuel Pégourié-Gonnard
Date Reported: 2014-09-08

Section 4.1.2.1 says:

                                                                      In
   DTLS, the receiving implementation MAY simply discard the offending
   record and continue with the connection.  This change is possible
   because DTLS records are not dependent on each other in the way that
   TLS records are.

   In general, DTLS implementations SHOULD silently discard records with
   bad MACs or that are otherwise invalid.  They MAY log an error.  If a
   DTLS implementation chooses to generate an alert when it receives a
   message with an invalid MAC, it MUST generate a bad_record_mac alert
   with level fatal and terminate its connection state.  Note that
   because errors do not cause connection termination, DTLS stacks are
   more efficient error type oracles than TLS stacks.  Thus, it is
   especially important that the advice in Section 6.2.3.2 of [TLS12] be

It should say:

See section 4.1.2.7.
[And merge the last two sentences above in section 4.1.2.7.]

Notes:

Some text is duplicated between 4.1.2.1 and 4.1.2.7, which my cause confusion or give rise to diverging updates in future revisions of this document.

Errata ID: 4642
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dale R. Worley
Date Reported: 2016-03-18

Section 4.1 says:

   version
      The version of the protocol being employed.  This document
      describes DTLS version 1.2, which uses the version { 254, 253 }.
      The version value of 254.253 is the 1's complement of DTLS version
      1.2.  This maximal spacing between TLS and DTLS version numbers
      ensures that records from the two protocols can be easily
      distinguished.  It should be noted that future on-the-wire version
      numbers of DTLS are decreasing in value (while the true version
      number is increasing in value.)

It should say:

Replace "1's complement of DTLS version" with "1's complement
of TLS version":

   version
      The version of the protocol being employed.  This document
      describes DTLS version 1.2, which uses the version { 254, 253 }.
      The version value of 254.253 is the 1's complement of TLS version
      1.2.  This maximal spacing between TLS and DTLS version numbers
      ensures that records from the two protocols can be easily
      distinguished.  It should be noted that future on-the-wire version
      numbers of DTLS are decreasing in value (while the true version
      number is increasing in value.)

Notes:

Clearly this won't confuse the reader, but it is incorrect as written and should be corrected at some time.

Errata ID: 5026
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Timm Korte
Date Reported: 2017-05-31

Section 4.1 says:

   length
      Identical to the length field in a TLS 1.2 record.  As in TLS 1.2,
      the length should not exceed 2^14.

It should say:

   length
      Identical to the length field in a TLS 1.2 record.  As in TLS 1.2,
      the length MUST NOT exceed 2^14.

Notes:

The originial comment on length in RFC 5246, 6.2.1 is:
length
The length (in bytes) of the following TLSPlaintext.fragment. The
length MUST NOT exceed 2^14.
so it has to be "MUST NOT" - instead of "should not" as currently stated.

Errata ID: 5903
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Martin Thomson
Date Reported: 2019-11-12

Section 1 says:

   with the exception that there is no DTLS version of SSLv2 or SSLv3,

It should say:

   with the exception that there is no DTLS version of SSLv2, SSLv3, or TLS 1.0,

Notes:

DTLS has versions that match TLS 1.1, 1.2, and (soon) 1.3. DTLS 1.0 corresponds to TLS 1.1.

RFC 6350, "vCard Format Specification", August 2011

Note: This RFC has been updated by RFC 6868

Source of RFC: vcarddav (app)

Errata ID: 4901
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Rick van Rein
Date Reported: 2017-01-10

Section 10.1 says:

   IANA has registered the following Media Type (in
   <http://www.iana.org/>) and marked the text/directory Media Type as
   DEPRECATED.

...

      In addition, the following media types are known to have been used
      to refer to vCard data.  They should be considered deprecated in
      favor of text/vcard.

      *  text/directory
      *  text/directory; profile=vcard
      *  text/x-vcard

It should say:

   IANA has registered the following Media Type (in
   <http://www.iana.org/>).

...

      In addition, the following media types are known to have been used
      to refer to vCard data.  They should be considered deprecated in
      favor of text/vcard.

      *  text/directory
      *  text/directory; profile=vcard
      *  text/x-vcard

Notes:

The first section needs correction, I quoted the second without change because I believe it carries the true intention; this looks like a mix-up of language between author and IANA.

This is a specification of media type for the vCard data format. Once vCards were carried along with the text/directory media type, and that _use_ is to be deprecated, but not the _entire_ media type. This media type applies to a completely different topic, namely LDAP, and it can't be right that a (former) usage of this media type leads to its retraction.

I posted this with IANA too, correspondence with them should use [IANA #944546] in the subject header.

Errata ID: 6746
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: b4D8
Date Reported: 2021-11-19

Section 8 says:

TZ:-0500

It should say:

TZ;VALUE=utc-offset:-0500
or
TZ:EST

Notes:

As specified in section 6.5.1.: "The default is a single text value. It can also be reset to a single URI or utc-offset value." Accordingly, the "utc-offset" value data-type should be explicitely set or the property value should be interpreted as text.

The section 6.5.1. further states that "utc-offset values SHOULD NOT be used" so probably using the timezone as an example is more consistent.

Errata ID: 6812
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Emily Love Mills (she/her)
Date Reported: 2022-01-06
Edited by: RFC Editor

Section 6.2.7 says:

   Examples:

     GENDER:M
     GENDER:F
     GENDER:M;Fellow
     GENDER:F;grrrl
     GENDER:O;intersex
     GENDER:;it's complicated

It should say:

   Examples:

     GENDER:M
     GENDER:F
     GENDER:M;Transgender Man
     GENDER:F;Transfeminine
     GENDER:O;Intersex
     GENDER:;Agender

Notes:

This errata replaces the imaginary gender identities with examples of actual diverse gender identities.

Errata ID: 6864
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: James Benner
Date Reported: 2022-02-27

Section 6.1.3 says:

SOURCE:ldap://ldap.example.com/cn=Babs%20Jensen,%20o=Babsco,%20c=US

It should say:

SOURCE:ldap://ldap.example.com/cn=Babs%20Jensen\,%20o=Babsco\,%20c=US

Notes:

Section 3.4 states that all property values must have COMMA characters escaped with a BACKSLASH character. The SOURCE property value in the example contains a comma. Therefore it must be escaped with a backslash.

Errata ID: 7061
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ken Murchison
Date Reported: 2022-07-29

Section 8 says:

    TEL;VALUE=uri;TYPE="work,voice";PREF=1:tel:+1-418-656-9254;ext=102
    TEL;VALUE=uri;TYPE="work,cell,voice,video,text":tel:+1-418-262-6501

It should say:

    TEL;VALUE=uri;TYPE=work,voice;PREF=1:tel:+1-418-656-9254;ext=102
    TEL;VALUE=uri;TYPE=work,cell,voice,video,text:tel:+1-418-262-6501

Notes:

While the given TYPE parameters are grammatically correct, in their current form they don't portray what I believe to be the intent of the example. In their current form, both TYPE parameters have just a single value because of the quoting. Since TYPE can be multi-valued, I believe the intent of the example was for these parameters to have 3 and 5 values respectively which is accomplished by the corrected text.

Unfortunately, even though examples are only informative (the ABNF is always normative), the mistake in the example has led to implementations in the wild that perform the same quoting but also assume that the parameter should be treated as multi-valued.

Errata ID: 7316
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Charles Burkitt
Date Reported: 2023-01-23

Section 5.4 says:

TITLE;ALTID=1;LANGUAGE=fr:Patron
TITLE:LANGUAGE=en:Boss
(Second line should probably have ALTID=1.)

It should say:

TITLE;ALTID=1;LANGUAGE=fr:Patron
TITLE;LANGUAGE=en:Boss
(Second line should probably have ALTID=1.)

Notes:

The colon between TITLE and LANGUAGE should be a semicolon.

Errata ID: 7856
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ryan Castellucci
Date Reported: 2024-03-18

Section 6.2.7 says:

   Special notes:  The components correspond, in sequence, to the sex
      (biological), and gender identity.  Each component is optional.

It should say:

   Special notes:  The components correspond, in sequence, to the sex
      and gender identity.  Each component is optional.

Notes:

The term "biological" in regards to sex does not have a widely agreed upon meaning, and is primarily used to discriminate against transgender people.

Including the "biological" qualifier serves no purpose.

RFC 6351, "xCard: vCard XML Representation", August 2011

Note: This RFC has been updated by RFC 6868

Source of RFC: vcarddav (app)

Errata ID: 6577
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Sergei S. Betke
Date Reported: 2021-05-08

Section Appendix A says:

# 6.2.7
property-gender = element gender {
    element sex { "" | "M" | "F" | "O" | "N" | "U" },
    element identity { text }?
  }

It should say:

# 6.2.7
property-gender = element gender {
    element sex { "M" | "F" | "O" | "N" | "U" }?,
    element identity { text }?
  }

Notes:

RFC 6350: The components correspond, in sequence, to the sex (biological), and gender identity. Each component is OPTIONAL.

Errata ID: 6578
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Sergei S. Betke
Date Reported: 2021-05-08

Section Appendix A says:

# 6.3.1
param-label = element label { value-text }?
property-adr = element adr {
    element parameters { param-language, param-altid, param-pid,
                         param-pref, param-type, param-geo, param-tz,
                         param-label }?,
    element pobox { text }+,
    element ext { text }+,
    element street { text }+,
    element locality { text }+,
    element region { text }+,
    element code { text }+,
    element country { text }+
  }

It should say:

# 6.3.1
param-label = element label { value-text }?
property-adr = element adr {
    element parameters { param-language, param-altid, param-pid,
                         param-pref, param-type, param-geo, param-tz,
                         param-label }?,
    element pobox { text }?,
    element ext { text }?,
    element street { text }?,
    element locality { text }?,
    element region { text }?,
    element code { text }?,
    element country { text }?
  }

Notes:

Multiply values for one address component does not allowed!

RFC 6350: Special notes: The structured type value consists of a sequence of address components. The component values MUST be specified in their corresponding position.
When a component value is missing, the associated component separator MUST still be specified.

RFC 6352, "CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV)", August 2011

Note: This RFC has been updated by RFC 6764

Source of RFC: vcarddav (app)

Errata ID: 4610
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sylvain Berfini
Date Reported: 2016-02-02

Section 8.7 says:

The request MUST include a Depth: 0 header; however, the actual
      scope of the REPORT is determined as described above.

It should say:

The request MUST include a Depth: 1 header; however, the actual
      scope of the REPORT is determined as described above.

Notes:

All examples of a addressbook-multiget query use Depth: 1 header, but the 8.7 section says it must be Depth: 0. I believe the mistake is in the documentation.

RFC 6376, "DomainKeys Identified Mail (DKIM) Signatures", September 2011

Note: This RFC has been updated by RFC 8301, RFC 8463, RFC 8553, RFC 8616

Source of RFC: dkim (sec)

Errata ID: 6674
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Christian Böhme
Date Reported: 2021-09-01

Section Appendix C says:

This results in the file rsa.public containing the key information
similar to this:

-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkM
oGeLnQg1fWn7/zYtIxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/R
tdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToI
MmPSPDdQPNUYckcQ2QIDAQAB
-----END PUBLIC KEY-----

This public-key data (without the BEGIN and END tags) is placed in
the DNS:

$ORIGIN _domainkey.example.org.
brisbane IN  TXT  ("v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ"
                   "KBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYt"
                   "IxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v"
                   "/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhi"
                   "tdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB")

It should say:

This results in the file rsa.public containing the key information
similar to this (long output lines truncated):

openssl asn1parse -i -inform PEM -in rsa.public
    0:d=0  hl=3 l= 159 cons: SEQUENCE          
    3:d=1  hl=2 l=  13 cons:  SEQUENCE          
    5:d=2  hl=2 l=   9 prim:   OBJECT            :rsaEncryption
   16:d=2  hl=2 l=   0 prim:   NULL              
   18:d=1  hl=3 l= 141 prim:  BIT STRING

openssl asn1parse -i -inform PEM -in rsa.public -strparse 18
    0:d=0  hl=3 l= 137 cons: SEQUENCE          
    3:d=1  hl=3 l= 129 prim:  INTEGER           :F02113FF502DD206C126…
  135:d=1  hl=2 l=   3 prim:  INTEGER           :010001

The result of

openssl asn1parse -i -inform PEM -in rsa.public -offset 22 -out /dev/stdout -noout | openssl base64

is then placed in the DNS:

$ORIGIN _domainkey.example.org.
brisbane IN  TXT  ("v=DKIM1; p=MIGJAoGBAPAhE/9QLdIGwSYapn1klbf8OQ"
                   "ygZ4udCDV9afv/Ni0jE3ZKcUKPE4Iob2/dviNh9xM2HmK"
                   "NKyrrfW4Ei0truh36/9G10LZTMnWVZP3jupH5FxpzaBu2"
                   "j80yonR/N9WMfg64qGK11j21/qZzAaNo0FxZOggyY9I8N"
                   "1A81RhyRxDZAgMBAAE=")

Notes:

Empirical evidence suggests that MSPs have taken the command lines in
Appendix C literally, and, by doing so, have deviated from the specification
laid out in Section 3.6.1. for the k= and p= tags.

Specifically, the openssl rsa command, used with its -pubout option
as demonstrated in Appendix C, produces a SubjectPublicKeyInfo-typed result
instead of a RSAPublicKey-typed one. It does so for both DER and PEM
arguments to the -outform option.

What is more, had Section 3.6.1., p= tag, specified a base64-encoded
SubjectPublicKeyInfo-typed value instead of a RSAPublicKey-typed one,
Section 3.6.1., k= tag, could have been dispensed of entirely, since
the SubjectPublicKeyInfo type contains an AlgorithmIdentifier-typed
attribute for that purpose.

That indeed an RSAPublicKey-typed result for the p= tag was intended
by RFC 6376 can be confirmed by comparison with RFC 8463, Section 4.2.,
which specifies that a "raw" Ed25519 public key be used, instead of
a SubjectPublicKeyInfo-typed one such as defined in RFC 8410,
Section 4. Subject Public Key Fields.

The Corrected Text uses the same public key data from the Original Text.

Errata ID: 7001
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ori Bernstein
Date Reported: 2022-06-21

Section 3.6.1 says:

   k= Key type (plain-text; OPTIONAL, default is "rsa").  Signers and
      Verifiers MUST support the "rsa" key type.  The "rsa" key type
      indicates that an ASN.1 DER-encoded [ITU-X660-1997] RSAPublicKey
      (see [RFC3447], Sections 3.1 and A.1.1) is being used in the "p="
      tag.

It should say:

   k= Key type (plain-text; OPTIONAL, default is "rsa").  Signers and
      Verifiers MUST support the "rsa" key type.  The "rsa" key type
      indicates that an ASN.1 DER-encoded [ITU-X660-1997] SubjectPublicKeyInfo
      (see [RFC5280], Section 4.1) is being used in the "p="
      tag.

Notes:

The format specified for RSA keys is not what is used
either in the wild, or in the examples in this RFC.

The current citation for the RSAPublicKey format is
listed below for reference:

RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER -- e
}

Taking the example public key in this RFC document:

-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkM
oGeLnQg1fWn7/zYtIxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/R
tdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToI
MmPSPDdQPNUYckcQ2QIDAQAB
-----END PUBLIC KEY-----

We can decode it as asn.1, and see that it is not in the format
specified:

$ openssl asn1parse -i -inform pem -in /home/ori/ykey.pem
0:d=0 hl=3 l= 159 cons: SEQUENCE
3:d=1 hl=2 l= 13 cons: SEQUENCE
5:d=2 hl=2 l= 9 prim: OBJECT :rsaEncryption
16:d=2 hl=2 l= 0 prim: NULL
18:d=1 hl=3 l= 141 prim: BIT STRING

The openssl documentation unhelpfully says that it's generated
in the "traditional SSLEay format". Poking around, that seems
to correspond to SubjectPublicKeyInfo in RFC5280:

SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING }

When generating a key that conforms to the RSAPublicKey
encoding, multiple sites (including gmail) reject the key,
claiming a failure to parse the tag -- this is also the
error that openssl has when attempting to parse an RSA
public key in this format; for example:

-----BEGIN PUBLIC KEY-----
MIGJAoGBAOPkeIi7+kBDwxOlfJFeWygu5Txt43ddLdY8AfWxLIHtQObNhgsxuaWh
UUhlftnJWcafJg6V8HVyvd4i+3D0l/PLHu89bIkGnH0ts/weIvQJ+Rx/hVZtS/H1
vkHRmiPnO5gaDi/jvfAFWcG4BiJgkEcUovKbmWAxYzGBqe/8um23AgMBAAE=
-----END PUBLIC KEY-----

$ openssl asn1parse -i -inform pem -in /home/ori/key.pem
0:d=0 hl=3 l= 137 cons: SEQUENCE
3:d=1 hl=3 l= 129 prim: INTEGER :E3E47888BBFA404·.
135:d=1 hl=2 l= 3 prim: INTEGER :010001
$ openssl rsa -pubin -in /home/ori/key.pem -text
unable to load Public Key
140290635060544:error:0D0680A8:asn1 encoding routines:asn1_check_tlen:wrong tag:../crypto/asn1/tasn_dec.c:1149:
140290635060544:error:0D07803A:asn1 encoding routines:asn1_item_embed_d2i:nested asn1 error:../crypto/asn1/tasn_dec.c:309:Type=X509_ALGOR
140290635060544:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:../crypto/asn1/tasn_dec.c:646:Field=algor, Type=X509_PUBKEY
140290635060544:error:0906700D:PEM routines:PEM_ASN1_read_bio:ASN1 lib:../crypto/pem/pem_oth.c:33:

While in theory it would be better to fix the examples,
I think that ship has sailed, and it's better instead
to fix the citation in the specification.

RFC 6381, "The 'Codecs' and 'Profiles' Parameters for "Bucket" Media Types", August 2011

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 5473
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Occil
Date Reported: 2018-08-20

Section 3.2 says:

   The 'codecs' parameter takes either of two forms.  The first form is
   used when the value does not contain any octets that require
   encoding.  The second form uses [RFC2231] to allow arbitrary octets
   to be encoded.  With either form, quotes allow for commas and other
   characters in <tspecials> (quotes MAY be used even when not
   required).

 [...]

   The BNF syntax is as follows:

 [...]

      fancy-list  := DQUOTE [charset] "'" [language] "'" id-list DQUOTE
                  ; Parsers MAY ignore <language>
                  ; Parsers MAY support only US-ASCII and UTF-8

It should say:

   The 'codecs' parameter takes either of two forms.  The first form is
   used when the value does not contain any octets that require
   encoding.  The second form uses [RFC2231] to allow arbitrary octets
   to be encoded.  With the first form only, quotes allow for commas and other
   characters in <tspecials> (quotes MAY be used even when not
   required).

 [...]

   The BNF syntax is as follows:

 [...]

      fancy-list  := [charset] "'" [language] "'" fancy-id-list
                  ; Parsers MAY ignore <language>
                  ; Parsers MAY support only US-ASCII and UTF-8
      fancy-id-list     := id-encoded *( "%2c" id-encoded )

Notes:

RFC 6381's definition of "codecs" (and "profiles") conflicts with the generic syntax for RFC 2231 section 4 character set and language information. Notably, RFC 2231 (which changes the syntax in RFC 2045 in a manner relevant here) disallows quoted strings as the attribute value if a parameter name ends with an asterisk (see the productions "extended-initial-value" and "extended-other-values" in RFC 2231). Thus, for example, the example

codecs*="''%25%20xz, gork"

is ill-formed under RFC 2231, since it uses a quoted-string in a parameter name ending in "*".

This erratum shows the correction only in section 3.1, but conforming corrections may need to be made elsewhere in the document.

Errata ID: 5524
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Alex Converse
Date Reported: 2018-10-12

Section 3.3 says:

   One of the OTI values for 'mp4a' is 40 (identifying MPEG-4 audio).
   For this value, the third element identifies the audio
   ObjectTypeIndication (OTI) as defined in [MP4A] (including
   amendments), expressed as a decimal number.

It should say:

   One of the OTI values for 'mp4a' is 40 (identifying MPEG-4 audio).
   For this value, the third element identifies the AudioObjectType 
   (AOT) as defined in [MP4A] (including amendments), expressed as a 
   decimal number.

Notes:

[MP4A] "Information technology--Coding of audio-visual objects -- 3: Audio", ISO/IEC 14496-3:2009. Only speaks of ObjectTypeIndications in the context of systems OTIs in the previous paragraph and never mentions "audio ObjectTypeIndication". In the example that follows the third element is an "AudioObjectType".

Errata ID: 6013
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Dai Rees
Date Reported: 2020-03-10

Section 3.3 says:

For example, MPEG-4 Visual Simple Profile Level 0 has the value 9, so a complete string for MPEG-4 Visual Simple Profile Level 0 would be "mp4v.20.9".

[...]

Content-Type: video/3gpp2; codecs="mp4v.20.9, mp4a.E1"
    (MPEG-4 Visual Simple Profile Level 0 plus 13K voice)

It should say:

For example, MPEG-4 Part 2 Visual "Simple Profile" Level 0 has the value 8, so a complete string for MPEG-4 Part 2 Visual "Simple Profile" Level 0 would be "mp4v.20.8".

[...]

Content-Type: video/3gpp2; codecs="mp4v.20.8, mp4a.E1"
    (MPEG-4 Visual Simple Profile Level 0 plus 13K voice)

Notes:

The MPEG-4 Visual Part 2, Annex G table G.1 lists the "Simple Profile/Level 0" profile-and-level indication code as 00001000 (decimal 8), and states that the indication code 00001001 (decimal 9) is Reserved.

RFC6381 gives an example stating "MPEG-4 Visual Simple Profile Level 0 has the value 9" - but this is incorrect because the specification states the value 9 is reserved and that Simple Profile with Level 0 is 8.

RFC 6386, "VP8 Data Format and Decoding Guide", November 2011

Source of RFC: INDEPENDENT

Errata ID: 5534
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ard Oerlemans
Date Reported: 2018-10-18

Section 19.1 says:

unsigned char *c = pbi->source;
unsigned int tmp;

tmp = (c[2] << 16) | (c[1] << 8) | c[0];

key_frame = tmp & 0x1;
version = (tmp >> 1) & 0x7;
show_frame = (tmp >> 4) & 0x1;
first_part_size = (tmp >> 5) & 0x7FFFF;

It should say:

unsigned char *c = pbi->source;
unsigned int tmp;

tmp = (c[2] << 16) | (c[1] << 8) | c[0];

key_frame = !(tmp & 0x1);
version = (tmp >> 1) & 0x7;
show_frame = (tmp >> 4) & 0x1;
first_part_size = (tmp >> 5) & 0x7FFFF;

Notes:

In section 9.1, where the frame tag is described, the field for the key frame is defined as "A 1-bit frame type (0 for key frames, 1 for interframes)."

The code block in section 19.1 interprets the bit in the opposite way: 1 for key frames and 0 for interframes.

Errata ID: 7370
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Nico Weber
Date Reported: 2023-02-25

Section 19.1 says:

The start_code is a constant 3-byte pattern having value 0x9d012a.

It should say:

The start_code is a constant 3-byte pattern having value 0x2a019d.

Notes:

The bytes in the file are 9D 01 2A, but if they are read little-endian like `tmp = (c[2] << 16) | (c[1] << 8) | c[0];` as is done for frame_tag just before, then start_code will end up as 0x2a019d in an uint32_t.

Alternatively, it could say "...having value 0x9d 0x01 0x2a".

Errata ID: 7519
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Nico Weber
Date Reported: 2023-05-22

Section 9.3 says:

       a.  L(1), the mode of segment feature data
           (segment_feature_mode), can be absolute-value mode (0) or
           delta value mode (1).

It should say:

       a.  L(1), the mode of segment feature data
           (segment_feature_mode), can be delta value mode (0) or
           absolute-value mode (1).

Notes:

9.3 lists the meanings of the bits the wrong way round.

Section 19.2 has it the right way round:

"""
o segment_feature_mode indicates the feature data update mode, 0 for
delta and 1 for the absolute value
"""

That is, at the moment two sections in the spec directly contradict each other. Section 19.2 is right, section 9.3 is wrong from what I can tell.

RFC 6415, "Web Host Metadata", October 2011

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 4811
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Dale R. Worley
Date Reported: 2016-09-26

Section 3.1.1 says:

   The XRD "Link" element, when used with the "href" attribute, conveys
   a link relation between the host described by the document and a
   common target URI.

It should say:

   The XRD "Link" element, when used with the "href" attribute, conveys
   a link relation between the host described by the document and a
   common target URI-reference.

Notes:

The erratum changes the text to allow the value of the href attribute to be a URI-reference, that is, either a URI or a relative-reference.

It appears that the new text is what has always been intended, because RFC 6415 is taken from Extensible Resource Descriptor (XRD) Version 1.0
(http://docs.oasis-open.org/xri/xrd/v1.0/xrd-1.0.html) sections 2.6 and 1.5.2, which specifies the value to be an "anyURI" in the XML schema datatypes, which includes relative URIs. "URI-reference" in RFC 3986 is equivalent to "anyURI" in XML schema datatypes.

This erratum now matters, because draft-ietf-netconf-restconf makes significant use of href values that are relative URLs. Also, see the discussion at https://www.ietf.org/mail-archive/web/netconf/current/msg11768.html

RFC 6455, "The WebSocket Protocol", December 2011

Note: This RFC has been updated by RFC 7936, RFC 8307, RFC 8441

Source of RFC: hybi (app)

Errata ID: 4672
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Anton Dunaev
Date Reported: 2016-04-18

Section 5.6 says:

   Data frames (e.g., non-control frames) are identified by opcodes
   where the most significant bit of the opcode is 0.  Currently defined
   opcodes for data frames include 0x1 (Text), 0x2 (Binary).  Opcodes
   0x3-0x7 are reserved for further non-control frames yet to be
   defined.

   Data frames carry application-layer and/or extension-layer data.  The
   opcode determines the interpretation of the data:

   Text

      The "Payload data" is text data encoded as UTF-8.  Note that a
      particular text frame might include a partial UTF-8 sequence;
      however, the whole message MUST contain valid UTF-8.  Invalid
      UTF-8 in reassembled messages is handled as described in
      Section 8.1.

   Binary

      The "Payload data" is arbitrary binary data whose interpretation
      is solely up to the application layer.

It should say:

   Data frames (i.e., non-control frames) are identified by opcodes
   where the most significant bit of the opcode is 0.  Currently defined
   opcodes for data frames include 0x00 (Continuation), 0x1 (Text) and
   0x2 (Binary).  Opcodes 0x3-0x7 are reserved for further non-control
   frames yet to be defined.

   Data frames carry application-layer and/or extension-layer data.  The
   opcode determines the interpretation of the data:

   Text

      The "Payload data" is text data encoded as UTF-8.  Note that a
      particular text frame might include a partial UTF-8 sequence;
      however, the whole message MUST contain valid UTF-8.  Invalid
      UTF-8 in reassembled messages is handled as described in
      Section 8.1.

   Binary

      The "Payload data" is arbitrary binary data whose interpretation
      is solely up to the application layer.

   Continuation

      These frames MUST be always preceeded by either Text or Binary
      frame with FIN bit clear (See Section 5.2). The "Payload data"
      contains next fragment (See section 5.4) of the message whose
      transmission were opened by the latest Text or Binary frame and
      MUST be interpreted in the same way as the initial fragment of
      the message.

Notes:

For any other opcode defined frames are explicitly listed and described in either Section 5.5 or Section 5.6. But continuation frame is not.

Formally it matches definition of data frame (given in section 5.6) as the most significant bit of its opcode is 0. Logically it should be data frame too. But it is unclear whether there are two categories of frames (data and control) or the Continuation frame represents the third.

One could guess though that Continuation frame is a data frame from the content of the section 5.5.1 stating that "An endpoint MAY delay sending a Close frame until its current message is sent (for instance, if the majority of a fragmented message is already sent, an endpoint MAY send the remaining fragments before sending a Close frame)". This fragment clarifies that Close frame is sent after an endpoint finished message transmission. Thus such interpreation would be consistent with the Section 5.5.1 stating that "The application MUST NOT send any more data frames after sending a Close frame".

Errata ID: 4919
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Jefferson Carpenter
Date Reported: 2017-01-28

Section 7.4.1 says:

1001 indicates that an endpoint is "going away", such as a server
      going down or a browser having navigated away from a page.

It should say:

(unsure)

Notes:

This status code apparently covers two entirely different situations: a server going down, and a browser having navigated away. What is meant by "going away", why can't these be 2 different status codes? That info should be present in the RFC text.

Errata ID: 7608
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Esmond Pitt
Date Reported: 2023-08-19

Section 7.1.1 says:

The underlying TCP connection, in most normal cases, SHOULD be closed
   first by the server, so that it holds the TIME_WAIT state and not the
   client (as this would prevent it from re-opening the connection for 2
   maximum segment lifetimes (2MSL), while there is no corresponding
   server impact as a TIME_WAIT connection is immediately reopened upon
   a new SYN with a higher seq number).  

It should say:

The underlying TCP connection, in most normal cases, SHOULD be closed
   first by the server, so that the TIME_WAIT occurs at the
   client, not at the server.  

Notes:

1. There is no such thing as a 'TIME_WAIT connection'.
2. TCP connections are never reused.
3. It is better for the TIME_WAIT *port* states to accumulate at the clients rather than at the server, as this distributes them among the client base and avoids possible resource exhaustion at the server (NB *not* port exhaustion, as the server is only using one port).
4. The part about 'as this would prevent it [the client] from re-opening the connection' is only true if the client is using a fixed local port number, which never works anyway.
5. The part about ' a TIME_WAIT connection is immediately reopened upon
a new SYN with a higher seq number' is nonsense.

Errata ID: 6997
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Daniel Egger
Date Reported: 2022-06-17

Section 4.3, 9.1 says:

      extension-param = token [ "=" (token | quoted-string) ]
           ; When using the quoted-string syntax variant, the value
           ; after quoted-string unescaping MUST conform to the
           ; 'token' ABNF.

It should say:

      extension-param = token [ "=" (token | quoted-string) ]

Notes:

The text reads as if any quoted-string which was supplied as a value has to follow the same rules as a token. That precludes the use of any token separators inside a quoted-string which is the whole reason why quoted-string exists as explained in RFC 2616:

Many HTTP/1.1 header field values consist of words separated by LWS
or special characters. These special characters MUST be in a quoted
string to be used within a parameter value (as defined in section
3.6).

Errata ID: 7262
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Demi Y
Date Reported: 2022-12-09

Section 5.5.1 says:

Following the 2-byte integer, the body MAY contain UTF-8-encoded data
with value /reason/, the interpretation of which is not defined by
this specification.  This data is not necessarily human readable but
may be useful for debugging or passing information relevant to the
script that opened the connection.  As the data is not guaranteed to
be human readable, clients MUST NOT show it to end users.

It should say:

> Following the 2-byte integer, the body MAY contain data which MUST
be UTF-8-encoded with value /reason/, the interpretation of which is
not defined by this specification.

> As the interpretation is not defined here, clients MAY show it to
end users.

----- OR -----

> Following the 2-byte integer, the body MAY contain arbitrary data,
the interpretation of which is not defined by this specification.

> As the interpretation is not defined here, clients MAY hide it
from end users.

Notes:

The RFC is unclear on whether or not close-frames can contain binary data for the /reason/.

In section 5.2, "Application data" is defined as "arbitrary".

Section 5.5.1 also says about the /reason/:
> This data is not necessarily human readable ...
> As the data is not guaranteed to be human readable ...

Ok, but what if it is?

As per RFC 2119, The "MUST NOT show it to end users" here is not a mere suggestion.
It implies some sort of inherent danger or contract breaking that would occur if the data were "shown" (undefined term), as if passing along UTF-8 text in a controlled manner could cause harm to their application.

Due to the "MUST NOT", the "MAY contain UTF-8-encoded data" here is ambiguous. It implies it could be something other than UTF-8, like binary data, which would be unsafe to blindly "show" to the "end user" (undefined term). There is no clear reason as to why it (emphatically) "MUST NOT" be shown to "end users".

Who is the client and who is the "end user"? This is the only occurrence of "end user" in the RFC. Is the "client" the browser, and the "end user" the developer trying to debug their application, but "MUST NOT" see close /reason/s? In practice, the close reason is of course exposed by browsers. But then is the end user the non-developer who triggers an unexpected error on the server, and has no way to report a bug since the server's error /reason/ MUST NOT be shown to them? Why MUSTN'T it be shown? Is it because it MAY contain binary data?

Clarification is needed on whether or not the /reason/ can contain arbitrary binary data. And the imperative restriction on what the undefined "end user" can be "shown" should be loosened.

Errata ID: 5288
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: champkeh
Date Reported: 2018-03-20

Section 5.2 says:

frame-payload-length-16 = %x0000-FFFF ; 16 bits in length

frame-payload-length-63 = %x0000000000000000-7FFFFFFFFFFFFFFF
                        ; 64 bits in length

frame-masking-key       = 4( %x00-FF )
                        ; present only if frame-masked is 1
                        ; 32 bits in length

It should say:

frame-payload-length-16 = %x0000-FFFF ; 16 bits in length

frame-payload-length-63 = %x0000000000000000-7FFFFFFFFFFFFFFF
                        ; 64 bits in length

frame-masking-key       = %x00000000-FFFFFFFF
                        ; present only if frame-masked is 1
                        ; 32 bits in length

Notes:

frame-masking-key is 32bits in length

RFC 6497, "BCP 47 Extension T - Transformed Content", February 2012

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 7179
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Frederic G. Marand
Date Reported: 2022-10-24

Section 2.5.c says:

There are three dated versions of the UNGEGN transliteration
          specification for Hebrew to Latin.  They can be represented by
          the following language tags:

          +  und-Hebr-t-und-latn-m0-ungegn-1972

          +  und-Hebr-t-und-latn-m0-ungegn-1977

          +  und-Hebr-t-und-latn-m0-ungegn-2007

It should say:

Either:

There are three dated versions of the UNGEGN transliteration
          specification for Hebrew to Latin.  They can be represented by
          the following language tags:

          +  und-Latn-t-und-hebr-m0-ungegn-1972

          +  und-Latn-t-und-hebr-m0-ungegn-1977

          +  und-Latn-t-und-hebr-m0-ungegn-2007

Or:

There are three dated versions of the UNGEGN transliteration
          specification for Hebrew from Latin.  They can be represented by
          the following language tags:

          +  und-Hebr-t-und-latn-m0-ungegn-1972

          +  und-Hebr-t-und-latn-m0-ungegn-1977

          +  und-Hebr-t-und-latn-m0-ungegn-2007

Notes:

The examples provided in the RFC are for "undefined language using hebrew script, transliterated from undefined language using latin script, following the UNGEGN revision of 1972/1977/2007.

However the text says these examples are for Hebrew to Latin, although these examples are for Latin to Hebrew. The text should either change the example description from "for Hebrew from Latin", or swap the language tags as suggested.

RFC 6531, "SMTP Extension for Internationalized Email", February 2012

Source of RFC: eai (app)

Errata ID: 7580
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Scott Hollenbeck
Date Reported: 2023-07-31

Sections 3.3 and 3.7.3 say:

The <Mailbox> ABNF rule is imported from RFC 5321 and updated in 
order to support the internationalized email address.

The following ABNF rules imported from RFC 5321, Section 4.1.2, are 
updated directly or indirectly by this document:

This document updates <Mailbox> and <Domain> to support non-ASCII 
characters.

It should say:

The <Mailbox> ABNF rule is imported from RFC 5321 and extended in 
order to support the internationalized email address.

The following ABNF rules imported from RFC 5321, Section 4.1.2, are 
extended directly or indirectly by this document:

This document extends <Mailbox> and <Domain> to support non-ASCII 
characters.

Notes:

The original text can be incorrectly interpreted to suggest that the definitions found in RFC 6531 formally update the definitions found in RFC 5321. RFC 6531 does not formally update RFC 5321. As such, a word like "extends" may be less prone to misinterpretation than "updates".

RFC 6532, "Internationalized Email Headers", February 2012

Source of RFC: eai (app)

Errata ID: 6036
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Alessandro Vesely
Date Reported: 2020-04-01

Throughout the document, when it says:

A section 3.2bis, "Syntax Extensions to RFC 2045", is missing.

It should say:

In particular, Section 5.1 of RFC 2045, "Syntax of the Content-Type Header Field", deserves an extension:

    token /= UTF8-non-ascii

similar to the extensions given to various text types given in Section 3.2.

Notes:

Various header fields are defined in terms of the grammar defined in RFC 2045. In particular, the missing extension of token was reported for Authentication-Results:
https://mailarchive.ietf.org/arch/msg/dmarc/g1U__axJW5I6OenEuwD48nwptzU

RFC 6545, "Real-time Inter-network Defense (RID)", April 2012

Source of RFC: mile (sec)

Errata ID: 5614
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Logan Widick
Date Reported: 2019-01-28

Section 5.1 says:

TrafficType

      One or many.  REQUIRED.  The values for the attribute "type" are
      meant to assist in determining if a trace is appropriate for the
      SP receiving the request to continue the trace.  Multiple values
      may be selected for this element; however, where possible, it
      should be restricted to one value that most accurately describes
      the traffic type.

   type

      One or many.  REQUIRED.  ENUM.  The attribute type is used to
      identify the type of information included in the RID message or
      the type of incident.

It should say:

TrafficType

      One or many.  REQUIRED.  The values for the attribute "type" are
      meant to assist in determining if a trace is appropriate for the
      SP receiving the request to continue the trace.  Multiple values
      may be selected for this element; however, where possible, it
      should be restricted to one value that most accurately describes
      the traffic type.

   type

      One.  REQUIRED.  ENUM.  The attribute type is used to
      identify the type of information included in the RID message or
      the type of incident.

Notes:

This is the "similar
issue [that] is also present with the way that the TrafficType is defined
on pages 19-20" that was mentioned in the original submission for errata id 5588.

The text as written (with "One or many" instances of the "type" attribute) suggests that
<TrafficType type="Attack" type="Network"/>
would be legal.

However, the schema (Section 8) and the fact that a single XML tag can't contain more than one instance of a given attribute (see https://www.w3.org/TR/xml/#uniqattspec, "An attribute name MUST NOT appear more than once in the same start-tag or empty-element tag") indicate that the above example of a TrafficType is not legal, and would need to be replaced with:
<TrafficType type="Attack"/>
<TrafficType type="Network"/>

RFC 6594, "Use of the SHA-256 Algorithm with RSA, Digital Signature Algorithm (DSA), and Elliptic Curve DSA (ECDSA) in SSHFP Resource Records", April 2012

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 6202
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: IWAMOTO Kouichi
Date Reported: 2020-06-03

Section 5.1 says:

5.1.  RSA Public Key

   A public key with the following value in OpenSSH format [RFC4716]
   would appear as follows:

It should say:

5.1.  RSA Public Key
                                                                                   
   A public key with the following value in secure shell public key file
   format [RFC4716] would appear as follows:

Notes:

RFC4716 defines secure shell public key file format, not OpenSSH format.

Section 5.2 and 5.3 have the same issue.

RFC 6616, "A Simple Authentication and Security Layer (SASL) and Generic Security Service Application Program Interface (GSS-API) Mechanism for OpenID", May 2012

Source of RFC: kitten (sec)

Errata ID: 7074
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Nadja Reitzenstein
Date Reported: 2022-08-06

Section 2.1 says:

The nonce value MUST be at least 2^32 bits and large enough to 
handle well in excess of the number of concurrent transactions 
a SASL server shall see.

It should say:

The nonce value MUST be at least 32 bits and large enough to 
handle well in excess of the number of concurrent transactions 
a SASL server shall see.

Notes:

A nonce of 512MiB is rather excessive to be generated for every authenticating client.

As this nonce also has to be transported within the URI sent to both the SASL client and called by the OIDC IdP the Note in section 3.2.1 of RFC 2616 seems to apply:
"Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations might not properly support these lengths."

A lower bound requirement of 32 bits for the nonce seems more appropiate; most platforms are able to efficiently handle 32-bit integers and is still likely to prevent a brute-force attack given the HTTP request overhead.

RFC 6637, "Elliptic Curve Cryptography (ECC) in OpenPGP", June 2012

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 7140
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christoph Grüninger
Date Reported: 2022-09-27

Throughout the document, when it says:

-

It should say:

Updates: 4480

Notes:

RFC 6637 updates RFC 4880 (adds algorithms to OpenPGP), but it does not contain "Updates: 4480" in the header.
RFC 5581, that does also add algorithms to OpenPGP provides this link.

People might miss this update when reading RFC 4880.

RFC 6652, "Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format", June 2012

Source of RFC: marf (app)

Errata ID: 6579
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Benjamin Schwarze
Date Reported: 2021-05-11

Section 3. says:

spf-rp-tag = "rp=" 1*12DIGIT "/" 1*12DIGIT

It should say:

spf-rp-tag = "rp=" "100" / 1*2DIGIT

Notes:

As explained in paragraph 3, the value of the "rp" modifier should be an integer value between 0 and 100. However, the specified abnf does not fit this requirement.

RFC 6655, "AES-CCM Cipher Suites for Transport Layer Security (TLS)", July 2012

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 3987
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Manuel Pégourié-Gonnard
Date Reported: 2014-05-14

Section 4 says:

             CipherSuite TLS_PSK_DHE_WITH_AES_128_CCM_8 = {0xC0,0xAA}
             CipherSuite TLS_PSK_DHE_WITH_AES_256_CCM_8 = {0xC0,0xAB}

It should say:

             CipherSuite TLS_DHE_PSK_WITH_AES_128_CCM_8 = {0xC0,0xAA}
             CipherSuite TLS_DHE_PSK_WITH_AES_256_CCM_8 = {0xC0,0xAB}

Notes:

Since these suites use the DHE_PSK key exchange, their name should start with TLS_DHE_PSK, not TLS_PSK_DHE, which is inconsistent with the general naming scheme of ciphersuites, and with the names of their CCM (as opposed to CCM_8) counterparts.

Errata ID: 3990
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Manuel Pégourié-Gonnard
Date Reported: 2014-05-16

Section 6.2 says:

   ... The input and output lengths are as for
   AEAD_AES_128_CCM.  An AEAD_AES_128_CCM_8 ciphertext is exactly 8
   octets longer than its corresponding plaintext.

It should say:

   ... The input and output lengths are as for
   AEAD_AES_128_CCM.  An AEAD_AES_256_CCM_8 ciphertext is exactly 8
   octets longer than its corresponding plaintext.

Notes:

This section is about AEAD_AES_256_CCM_8, so it should describe the length of a cihpertext with this cipher, not with An AEAD_AES_128_CCM_8 (which was the object of the prevous section).

RFC 6680, "Generic Security Service Application Programming Interface (GSS-API) Naming Extensions", August 2012

Source of RFC: kitten (sec)

Errata ID: 4337
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Benjamin Kaduk
Date Reported: 2015-04-18

Section 7.5 says:

   This function outputs the value(s) associated with a given GSS name
   object for a given name attribute.

It should say:

   This function outputs the value(s) associated with a given GSS name
   object for a given name attribute.  It is permitted to block pending
   network interactions when the attr input is not an attribute which
   would be included in the attrs output of a call to GSS_Inquire_name()
   on the same name input.

Notes:

RFC 6680 makes no mention of blocking or not blocking on network interaction, though RFC 2743 does. This seems like the most reasonable interpretation of what is currently in RFC 6680. Calls which are not explicitly permitted to block are assumed to be not permitted to block.

RFC 6724, "Default Address Selection for Internet Protocol Version 6 (IPv6)", September 2012

Source of RFC: 6man (int)

Errata ID: 6971
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Brian Carpenter
Date Reported: 2022-05-10

Section 2.2 says:

We define the common prefix length CommonPrefixLen(S, D) of a source
address S and a destination address D as the length of the longest
prefix (looking at the most significant, or leftmost, bits) that the
two addresses have in common, up to the length of S's prefix (i.e.,
the portion of the address not including the interface ID).  For
example, CommonPrefixLen(fe80::1, fe80::2) is 64.

It should say:

We define the common prefix length CommonPrefixLen(S, D) of a source
address S and a destination address D as the length of the longest
prefix (looking at the most significant, or leftmost, bits) that the
two addresses have in common, up to the length of S's prefix (i.e.,
for most IPv6 addresses,
the portion of the address not including the interface ID).  For
example, CommonPrefixLen(fe80::1, fe80::2) is 64. For two IPv4-mapped
addresses in ::ffff:0:0/96, CommonPrefixLen() may be up to 128.

Notes:

1) Not all IPv6 address formats have a well-defined interface index.
2) In particular, the original text is inapplicable to IPv4-mapped addresses.
3) N.B.: In practice it seems that some implementations simply do a longest match up to /128 and that works fine.

RFC 6733, "Diameter Base Protocol", October 2012

Note: This RFC has been updated by RFC 7075, RFC 8553

Source of RFC: dime (ops)

Errata ID: 6171
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Valentin Micic
Date Reported: 2020-05-13

Section 6.1.3 says:

A relay or proxy agent MUST check for forwarding loops when receiving
requests.  A loop is detected if the server finds its own identity in
a Route-Record AVP.  When such an event occurs, the agent MUST answer
with the Result-Code AVP set to DIAMETER_LOOP_DETECTED.

It should say:

A relay or proxy agent MUST check for forwarding loops when receiving
requests. A loop is detected if a relay or proxy agent finds its own
identity in a Route-Record AVP.  When such an event occurs, the agent
MUST answer with the Result-Code AVP set to DIAMETER_LOOP_DETECTED.

Notes:

The term "server" used to identify party which is to detect its own identity as a part of Route-Record AVP is semantically too close to the term Diameter Server. If "relay or proxy agent MUST check", the question is what would be the consequence of such action if the (Diameter) "server" is to do the "detecting"?

Errata ID: 6832
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Kshitij Dutt
Date Reported: 2022-02-03

Section 7.1.4 says:

DIAMETER_OUT_OF_SPACE 4002

      A Diameter node received the accounting request but was unable to
      commit it to stable storage due to a temporary lack of space.

It should say:

DIAMETER_OUT_OF_SPACE 4002

      A Diameter node received the request but was unable to
      commit it to stable storage due to a temporary lack of space.

Notes:

Original text signifies accounting application explicitly. It can be any of Accounting or Authorization.

RFC 6749, "The OAuth 2.0 Authorization Framework", October 2012

Note: This RFC has been updated by RFC 8252, RFC 8996

Source of RFC: oauth (sec)

Errata ID: 4679
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Yi EungJun
Date Reported: 2016-04-29

Throughout the document, when it says:

     Content-Type: application/json;charset=UTF-8

It should say:

     Content-Type: application/json

Notes:

application/json does not have charset parameter.

Errata ID: 4745
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Clark Downum
Date Reported: 2016-07-20

Section 5.2 says:

error
         REQUIRED.  A single ASCII [USASCII] error code from the
         following:

         invalid_request
               The request is missing a required parameter, includes an
               unsupported parameter value (other than grant type),
               repeats a parameter, includes multiple credentials,
               utilizes more than one mechanism for authenticating the
               client, or is otherwise malformed.

         invalid_client
               Client authentication failed (e.g., unknown client, no
               client authentication included, or unsupported
               authentication method).  The authorization server MAY
               return an HTTP 401 (Unauthorized) status code to indicate
               which HTTP authentication schemes are supported.  If the
               client attempted to authenticate via the "Authorization"
               request header field, the authorization server MUST
               respond with an HTTP 401 (Unauthorized) status code and
               include the "WWW-Authenticate" response header field
               matching the authentication scheme used by the client.

         invalid_grant
               The provided authorization grant (e.g., authorization
               code, resource owner credentials) or refresh token is
               invalid, expired, revoked, does not match the redirection
               URI used in the authorization request, or was issued to
               another client.

         unauthorized_client
               The authenticated client is not authorized to use this
               authorization grant type.

         unsupported_grant_type
               The authorization grant type is not supported by the
               authorization server.

         invalid_scope
               The requested scope is invalid, unknown, malformed, or
               exceeds the scope granted by the resource owner.

         Values for the "error" parameter MUST NOT include characters
         outside the set %x20-21 / %x23-5B / %x5D-7E.

It should say:

error
         REQUIRED.  A single ASCII [USASCII] error code from the
         following:

         invalid_request
               The request is missing a required parameter, includes an
               unsupported parameter value (other than grant type),
               repeats a parameter, includes multiple credentials,
               utilizes more than one mechanism for authenticating the
               client, or is otherwise malformed.

         invalid_client
               Client authentication failed (e.g., unknown client, no
               client authentication included, or unsupported
               authentication method).  The authorization server MAY
               return an HTTP 401 (Unauthorized) status code to indicate
               which HTTP authentication schemes are supported.  If the
               client attempted to authenticate via the "Authorization"
               request header field, the authorization server MUST
               respond with an HTTP 401 (Unauthorized) status code and
               include the "WWW-Authenticate" response header field
               matching the authentication scheme used by the client.

         invalid_grant
               The provided authorization grant (e.g., authorization
               code, resource owner credentials) or refresh token is
               invalid, expired, revoked, does not match the redirection
               URI used in the authorization request, or was issued to
               another client.

         unauthorized_client
               The authenticated client is not authorized to use this
               authorization grant type.

         unsupported_grant_type
               The authorization grant type is not supported by the
               authorization server.

         invalid_scope
               The requested scope is invalid, unknown, malformed, or
               exceeds the scope granted by the resource owner.

         server_error
               The authorization server encountered an unexpected
               condition that prevented it from fulfilling the request.
               (This error code is needed because a 500 Internal Server
               Error HTTP status code cannot be returned to the client
               via an HTTP redirect.)

         temporarily_unavailable
               The authorization server is currently unable to handle
               the request due to a temporary overloading or maintenance
               of the server.  (This error code is needed because a 503
               Service Unavailable HTTP status code cannot be returned
               to the client via an HTTP redirect.)

         Values for the "error" parameter MUST NOT include characters
         outside the set %x20-21 / %x23-5B / %x5D-7E.

Notes:

This is simply adding the server_error and temporarily_unavailable errors in other responses responses to the access token response for non-implicit grant types.

Errata ID: 4749
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Phil Hunt
Date Reported: 2016-07-26

Section 2.3.1 says:

Clients in possession of a client password MAY use the HTTP Basic
authentication scheme as defined in [RFC2617] to authenticate with
the authorization server.  The client identifier is encoded using the
"application/x-www-form-urlencoded" encoding algorithm per
Appendix B, and the encoded value is used as the username; the client
password is encoded using the same algorithm and used as the
password.  The authorization server MUST support the HTTP Basic
authentication scheme for authenticating clients that were issued a
client password.

It should say:

Clients in possession of a client password MAY use the HTTP Basic
authentication scheme as defined in [RFC2617] to authenticate with
the authorization server.  The client identifier is encoded using the
"application/x-www-form-urlencoded" encoding algorithm per
Appendix B, and the encoded value is used as the username; the client
password is encoded using the same algorithm and used as the
password. The url encoded values are then encoded as defined in
[RFC2617]. The authorization server MUST support the HTTP Basic
authentication scheme for authenticating clients that were issued a
client password.

Notes:

It was not clear to some implementers that the intention is a 2-step encoding. First for special characters and second the 2617 base 64 encoding. Implementers thought 6749 was in conflict with 2617.

To avoid inter-op issues, a new clarifying sentence is proposed.
"The url encoded values are then encoded as defined in [RFC2617]."

Errata ID: 4819
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Lars Kemmann
Date Reported: 2016-10-05

Section 4.2.2 says:

HTTP/1.1 302 Found
Location: http://example.com/cb#
          access_token=2YotnFZFEjr1zCsicMWpAA
          &state=xyz&token_type=example&expires_in=3600

It should say:

HTTP/1.1 302 Found
Location: http://client.example.com/cb#
          access_token=2YotnFZFEjr1zCsicMWpAA
          &state=xyz&token_type=example&expires_in=3600

Notes:

In the example for section 4.2.1, the request was made with a `redirect_uri` parameter value of `redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb`. If I understand correctly, the `client` subdomain should be included in the `Location` header in the response.

Errata ID: 5234
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Randip Kumar Malakar
Date Reported: 2018-01-12

Section 2.1. says:

   public
      Clients incapable of maintaining the confidentiality of their
      credentials (e.g., clients executing on the device used by the
      resource owner, such as an installed native application or a web
      browser-based application), and incapable of secure client
      authentication via any other means.

It should say:

   public
      Clients incapable of maintaining the confidentiality of their
      credentials (e.g., clients executing on the device used by the
      third-party (not resource owner but another end user), such as an
      installed native application or a web
      browser-based application), and incapable of secure client
      authentication via any other means.

Notes:

I think in case of public client type, it should state as "e.g. the clients executing on the device used by third-party and not the actual resource owner" as mentioned in the original RFC. I let the author or experts to review my remark. Thanks.

Errata ID: 5332
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Donald F Coffin
Date Reported: 2018-04-24

Section 4.1 says:

(B)  The authorization server authenticates the resource owner (via
     the user-agent) and establishes whether the resource owner
     grants or denies the client's access request.

It should say:

(B)  The authorization server validates the request to ensure that 
     all required parameters are present and valid.  If the request 
     is valid, the authorization server authenticates the resource 
     owner and obtains an authorization decision (by asking the 
     resource owner via the user-agent or by use of other 
     established approval means).

Notes:

"Section 4.1 Authorization Code Grant (B)" conflicts with "Section 4.1.1 Authorization
Request". The current verbiage implies the resource owner should be authenticated
prior to "The authorization server validates the request to ensure that all required
parameters are present and valid". Such implementations lead to overly complex
user experiences when the Authorization Server determines the request is invalid.

Errata ID: 5793
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin May
Date Reported: 2019-07-25

Section 2.3.1 says:

   Alternatively, the authorization server MAY support including the
   client credentials in the request-body using the following
   parameters:

It should say:

   In addition to that, the authorization server MAY support including
   the client credentials in the request-body using the following
   parameters:

Notes:

Given that the authorization MUST support the HTTP Basic authentication scheme in the paragraphs just before this one, using the word "alternatively" here can be understood as "instead of", which is not the intention and can lead to confusion for implementors.

This intention is further highlighted by the use of the word MAY in the paragraph above.

Errata ID: 5873
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ludwig Seitz
Date Reported: 2019-10-11

Section 11.4 says:

It should say:

11.4.2 Initial Registry Contents

The OAuth Extensions Error registry's initial contents are:

o Error name: invalid_request
o Error usage location: authorization code grant error response, implicit grant error response, token error response
o Related protocol extension: authorization code grant, implicit grant, any access token type
o Change controller: IETF
o Specification document(s): RFC 6749

o Error name: unauthorized_client
o Error usage location: authorization code grant error response, implicit grant error response, token error response
o Related protocol extension: authorization code grant, implicit grant, any access token type
o Change controller: IETF
o Specification document(s): RFC 6749

o Error name: access_denied
o Error usage location: authorization code grant error response, implicit grant error response
o Related protocol extension: authorization code grant, implicit grant
o Change controller: IETF
o Specification document(s): RFC 6749

o Error name: unsupported_response_type
o Error usage location: authorization code grant error response, implicit grant error response
o Related protocol extension: authorization code grant, implicit grant
o Change controller: IETF
o Specification document(s): RFC 6749

o Error name: invalid_scope
o Error usage location: authorization code grant error response, implicit grant error response, token error response
o Related protocol extension: authorization code grant, implicit grant, any access token type
o Change controller: IETF
o Specification document(s): RFC 6749

o Error name: server_error
o Error usage location: authorization code grant error response, implicit grant error response
o Related protocol extension: authorization code grant, implicit grant
o Change controller: IETF
o Specification document(s): RFC 6749

o Error name: temporarily_unavailable
o Error usage location: authorization code grant error response, implicit grant error response
o Related protocol extension: authorization code grant, implicit granto Change controller: IETF
o Specification document(s): RFC 6749

o Error name: invalid_client
o Error usage location: token error response
o Related protocol extension: any access token type
o Change controller: IETF
o Specification document(s): RFC 6749

o Error name: invalid_grant
o Error usage location: token error response
o Related protocol extension: any access token type
o Change controller: IETF
o Specification document(s): RFC 6749

o Error name: unsupported_grant_type
o Error usage location: token error response
o Related protocol extension: any access token type
o Change controller: IETF
o Specification document(s): RFC 6749

Notes:

It seems that the values specified in sections 4.1.2.1.,4.2.2.1. and 5.2. should have been added to the registry but were forgotten.
This errata suggests "any access token type" for "Related protocol extension" for the error codes of 5.2 since they seem to apply to any errors returned from the token endpoint, no matter which access token type is involved.

Errata ID: 6017
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Osipov
Date Reported: 2020-03-15

Section 2.3.1 says:

Clients in possession of a client password MAY use the HTTP Basic
   authentication scheme as defined in [RFC2617] to authenticate with
   the authorization server.  The client identifier is encoded using the
   "application/x-www-form-urlencoded" encoding algorithm per
   Appendix B, and the encoded value is used as the username; the client
   password is encoded using the same algorithm and used as the
   password.

It should say:

Clients in possession of a client password MAY use the HTTP Basic
   authentication scheme as defined in [RFC7617] to authenticate with
   the authorization server.

Notes:

RFC 2617 has been superseded by RFC7617 which clearly defines in section 2.1 how a charset can be provided to solve the usecase described with encoding.

The original text of this RFC violates the approach described for Basic authentication.

Errata ID: 7429
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Gasan Guseinov
Date Reported: 2023-04-20

Section 2 says:

Before initiating the protocol, the client registers with the
   authorization server.  The means through which the client registers
   with the authorization server are beyond the scope of this
   specification but typically involve end-user interaction with an HTML
   registration form.

It should say:

Before initiating the protocol, the client registers with the
   authorization server.  The means through which the client registers
   with the authorization server are beyond the scope of this
   specification but typically involve client developer interaction with an HTML
   registration form.

Notes:

As described in 1.1 resource owner if person is referred to as end user. Resource owner is not responsible for registering a client with authorization server, but the client developer is.

Errata ID: 7642
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Wilhelm Fast
Date Reported: 2023-09-17

Section 1 says:

 Instead, she authenticates directly with a server trusted by the photo-sharing service (authorization server), which issues the printing service delegation-
specific credentials (access token).

It should say:

Instead, she directly authenticates with a trusted server, the authorization server, which issues delegation-specific credentials, known as access tokens, to the printing service for controlled and secure access.

Notes:

The sentence is confusing, and the reader might confuse the Authorization Server with the Resource Server.

Errata ID: 7631
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Daiki Usami
Date Reported: 2023-09-05

Section 3.2.1 says:

This protects the client from substitution of the authentication code.

It should say:

This protects the client from substitution of the authorization code.

Notes:

It will be a bit confusing to figure out if it is a MAC or an authorization code.

Errata ID: 7716
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Alex Wilson
Date Reported: 2023-11-29

Section 4.2.2 says:

   For example, the authorization server redirects the user-agent by
   sending the following HTTP response (with extra line breaks for
   display purposes only):

     HTTP/1.1 302 Found
     Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA
               &state=xyz&token_type=example&expires_in=3600

It should say:

   For example, the authorization server redirects the user-agent by
   sending the following HTTP response (with extra line breaks for
   display purposes only):

     HTTP/1.1 302 Found
     Location: http://client.example.com/cb?access_token=2YotnFZFEjr1zCsicMWpAA
               &state=xyz&token_type=example&expires_in=3600

Notes:

- Host example.com should be client.example.com to be consistent with other examples.
- A hash is used for the query parameters when a question mark should have been used.

RFC Editor Note: The first point above is a duplicate of EID 4819, which is currently still in Reported state (see https://www.rfc-editor.org/errata/eid4819).

Errata ID: 7715
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Alex Wilson
Date Reported: 2023-11-29

Section 4.2.2.1 says:

   HTTP/1.1 302 Found
   Location: https://client.example.com/cb#error=access_denied&state=xyz

It should say:

   HTTP/1.1 302 Found
   Location: https://client.example.com/cb?error=access_denied&state=xyz

Notes:

For query parameters, the hash should be a question mark.

Errata ID: 7823
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexander Stumpf
Date Reported: 2024-02-26

Section 3.2.1 says:

   Confidential clients or other clients issued client credentials MUST
   authenticate with the authorization server as described in
   Section 2.3 when making requests to the token endpoint.  Client
   authentication is used for:

   o  Enforcing the binding of refresh tokens and authorization codes to
      the client they were issued to.  Client authentication is critical
      when an authorization code is transmitted to the redirection
      endpoint over an insecure channel or when the redirection URI has
      not been registered in full.

It should say:

   Confidential clients or other clients issued client credentials MUST
   authenticate with the authorization server as described in
   Section 2.3 when making requests to the token endpoint.  Client
   authentication is used for:

   o  Enforcing the binding of refresh tokens, authorization codes, and
      (in the case of the Client Credentials Grant as described in
      Section 4.4) the access token to the client they were issued to.
      Client authentication is critical when an authorization code is
      transmitted to the redirection endpoint over an insecure channel
      or when the redirection URI has not been registered in full.

Notes:

Section 4.4.2 requires for the "client_credentials" grant type that the client is authenticated to the authorization server according to section 3.2.1. The reason for this authentication is (or so I assume) that the to-be-issued access token shall be bound to the correct (authenticated) client. Otherwise, the client could authenticate with valid credentials as "client A" and request a token for "client B", and would still be in accordance with the RFC, which is probably not intended.

Errata ID: 4697
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ludwig Seitz
Date Reported: 2016-05-19

Section 7.1 says:

For example, the "bearer" token type defined in [RFC6750] is utilized
   by simply including the access token string in the request:

It should say:

For example, the "Bearer" token type defined in [RFC6750] is utilized
   by simply including the access token string in the request:

Notes:

RFC6750 defines the "Bearer" token type not the "bearer" token type.

Errata ID: 4945
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Abhimanyu Singh Gaur
Date Reported: 2017-02-21

Section 4.1.4 says:

If the access token request is valid and authorized, the
   authorization server issues an access token and optional refresh
   token as described in Section 5.1.  If the request client
   authentication failed or is invalid, the authorization server returns
   an error response as described in Section 5.2.

It should say:

If the access token request is valid and authorized, the
   authorization server issues an access token and optional refresh
   token as described in Section 5.1.  If the request failed client
   authentication or is invalid, the authorization server returns
   an error response as described in Section 5.2.

Notes:

In the 2nd line, "request failed" makes more sense than the original text.
The 1st paragraph of section 5 in the document and the para just before section 5 also state "If the request failed client authentication or ..." instead of what is currently mentioned in section 4.1.4.

It is just a typing mistake, I think the words got exchanged during typing.
Please, correct it.

Errata ID: 5379
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: James Manger
Date Reported: 2018-06-06

Section 5.1, 4.2.2 says:

expires_in
         RECOMMENDED.  The lifetime in seconds of the access token.  For
         example, the value "3600" denotes ...

It should say:

expires_in
         RECOMMENDED.  The lifetime in seconds of the access token.  For
         example, the value 3600 denotes ...

Notes:

The "expires_in" member in JSON must be a numeric value, not a string. Unfortunately quite a few implementations have got this wrong. A likely reason is the quoted value "3600" in the RFC where "expires_in" is defined. The quotes in the text version of the RFC are only an artefact of the marked-up as a protocol value in the RFC production chain.

Errata ID: 6614
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Daniel Barclay
Date Reported: 2021-06-17

Section 5.1 says:

... adding the following parameters to the entity-body of the HTTP response ...

It should say:

... adding the following parameters as members to the JSON object in the entity-body of the HTTP response ...

Notes:

Saying "adding the following parameters to the entity-body" seems to be confusing,
implying that HTTP entity bodies have parameters (at the level of semantics defined by HTTP), which they don't.

The corrected text doesn't necessarily need to be what I proposed in the "Corrected Text" field, but it should probably at least refer to the data or (JSON) object inside the entity body instead of just referring to the entity body.

Errata ID: 6615
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Daniel Barclay
Date Reported: 2021-06-17

Throughout the document, when it says:

Condition descriptions like "The authorization server ... validates the authorization grant, and if valid, issues an access token."
 

It should say:

Adjusted descriptions like "The authorization server ... validates the authorization grant, and if it is valid, issues an access token."

Notes:

The wording pattern "A validates B, and if valid, does X" means "A validates B, and if A is valid, does X" and is confusing.

Those descriptions' wording should be adjusted, probably to the pattern "A validates B, and if it is valid, does X" (or whatever else actually says what was meant to be specified).

There are many occurrences with literally "and if valid"; it looks (from a quick search) like most, but not all, need adjustment. There are also several cases of "and if" followed by something other than "valid"--some seem correct, but a few might need adjustment.

RFC 6750, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", October 2012

Note: This RFC has been updated by RFC 8996

Source of RFC: oauth (sec)

Errata ID: 5335
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Kavindu Dodanduwa
Date Reported: 2018-04-26

Section 2.1 says:

b64token

It should say:

token68

Notes:

Usage of b64token is confusing. Definition is self explanatory but could be easily confused with Base64.

RFC7235 defines token68. Following some old RFC draft discussions (http://w3-org.9356.n7.nabble.com/p7-rename-b64token-to-token68-to-avoid-misunderstandings-td108256.html) I found that b64token was renamed to token68.

I believe it's appropriate to use naming of token68 (instead of b64token) in RFC6750. So that it is less confusing as well as refers to an existing standard.

Errata ID: 6161
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Herbert Valerio Riedel
Date Reported: 2020-05-08

Section 4 says:

4.  Example Access Token Response

   Typically, a bearer token is returned to the client as part of an
   OAuth 2.0 [RFC6749] access token response.  An example of such a
   response is:

     HTTP/1.1 200 OK
     Content-Type: application/json;charset=UTF-8

It should say:

4.  Example Access Token Response

   Typically, a bearer token is returned to the client as part of an
   OAuth 2.0 [RFC6749] access token response.  An example of such a
   response is:

     HTTP/1.1 200 OK
     Content-Type: application/json

Notes:

The IANA registration (see https://tools.ietf.org/html/rfc8259#section-11) does not support any parameters for the `application/json` media type. The `charset=UTF-8` parameter used in the example is therefore non-compliant and ought to be omitted.

RFC 6781, "DNSSEC Operational Practices, Version 2", December 2012

Source of RFC: dnsop (ops)

Errata ID: 6692
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Jarle Fredrik Greipsland
Date Reported: 2021-09-22

Section Appendix D says:

    ------------------------------------------------------------
    new DS             |        pre-publish                    |
    ------------------------------------------------------------
    Parent:
     NS_A                            NS_A
     DS_A DS_B                       DS_A DS_B
    ------------------------------------------------------------
    Child at A:            Child at A:        Child at B:
     SOA_A0                 SOA_A1             SOA_B0
     RRSIG_Z_A(SOA)         RRSIG_Z_A(SOA)     RRSIG_Z_B(SOA)

     NS_A                   NS_A               NS_B
     RRSIG_Z_A(NS)          NS_B               RRSIG_Z_B(NS)
                            RRSIG_Z_A(NS)

     DNSKEY_Z_A             DNSKEY_Z_A         DNSKEY_Z_A
                            DNSKEY_Z_B         DNSKEY_Z_B
     DNSKEY_K_A             DNSKEY_K_A         DNSKEY_K_B
     RRSIG_K_A(DNSKEY)      RRSIG_K_A(DNSKEY)  RRSIG_K_A(DNSKEY)
                            RRSIG_K_B(DNSKEY)  RRSIG_K_B(DNSKEY)
    ------------------------------------------------------------

It should say:

    ------------------------------------------------------------
    new DS             |        pre-publish                    |
    ------------------------------------------------------------
    Parent:
     NS_A                            NS_A
     DS_A DS_B                       DS_A DS_B
    ------------------------------------------------------------
    Child at A:            Child at A:        Child at B:
     SOA_A0                 SOA_A1             SOA_B0
     RRSIG_Z_A(SOA)         RRSIG_Z_A(SOA)     RRSIG_Z_B(SOA)

     NS_A                   NS_A               NS_B
     RRSIG_Z_A(NS)          NS_B               RRSIG_Z_B(NS)
                            RRSIG_Z_A(NS)

     DNSKEY_Z_A             DNSKEY_Z_A         DNSKEY_Z_A
                            DNSKEY_Z_B         DNSKEY_Z_B
     DNSKEY_K_A             DNSKEY_K_A         DNSKEY_K_B
     RRSIG_K_A(DNSKEY)      RRSIG_K_A(DNSKEY)  RRSIG_K_B(DNSKEY)
    ------------------------------------------------------------

Notes:

Figure 15 in Appendix D is depicting the phases of a double DS KSK rollover operator change. One rationale for applying this approach is to avoid the exchange of signatures (RRSIGs) between operators, and limit exchanges to the public parts of the ZSKs in use. In the pre-publish phase in the figure, it is shown that Child A publishes a signature over the DNSKEY RRset generated by Child B's KSK, and that Child B publishes a signature over the DNSKEY RRset generated by Child A's KSK. This is contrary to the rationale given for this method, and also not required, since the pre-published double DS RRs at the parent zone should enable a validator to validate the signature generated by any of the two KSKs in use, thus one RRSIG RR for the DNSKEY RRset is sufficient at each child. Therefore, the RRSIG_K_B(DNSKEY) RR should be removed from Child A, and the RRSIG_K_A(DNSKEY) should be removed from Child B.

RFC 6787, "Media Resource Control Protocol Version 2 (MRCPv2)", November 2012

Source of RFC: speechsc (rai)

Errata ID: 6999
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Andreas Häber
Date Reported: 2022-06-20

Section 9.20 says:

S->C:   MRCP/2.0 ... INTERPRETATION-COMPLETE 543266 200 COMPLETE
           Channel-Identifier:32AECB23433801@speechrecog
           Completion-Cause:000 success
           Content-Type:application/nlsml+xml
           Content-Length:...

           <?xml version="1.0"?>
           <result xmlns="urn:ietf:params:xml:ns:mrcpv2"
                   xmlns:ex="http://www.example.com/example"
                   grammar="session:request1@form-level.store">
               <interpretation>
                   <instance name="Person">
                       <ex:Person>
                           <ex:Name> Andre Roy </ex:Name>
                       </ex:Person>
                   </instance>
                   <input>   may I speak to Andre Roy </input>
               </interpretation>
           </result>

It should say:

S->C:   MRCP/2.0 ... INTERPRETATION-COMPLETE 543266 COMPLETE
           Channel-Identifier:32AECB23433801@speechrecog
           Completion-Cause:000 success
           Content-Type:application/nlsml+xml
           Content-Length:...

           <?xml version="1.0"?>
           <result xmlns="urn:ietf:params:xml:ns:mrcpv2"
                   xmlns:ex="http://www.example.com/example"
                   grammar="session:request1@form-level.store">
               <interpretation>
                   <instance name="Person">
                       <ex:Person>
                           <ex:Name> Andre Roy </ex:Name>
                       </ex:Person>
                   </instance>
                   <input>   may I speak to Andre Roy </input>
               </interpretation>
           </result>

Notes:

event-line does *not* include a status-code.

Errata ID: 5308
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Xiong Chao
Date Reported: 2018-03-28

Section 5.1 says:

S->C:   MRCP/2.0 634 INTERPRETATION-COMPLETE 543266 200 COMPLETE

It should say:

S->C:   MRCP/2.0 634 INTERPRETATION-COMPLETE 543266 COMPLETE

Notes:

The definition of event-line in Section 5.5 NOT include status-code.

Errata ID: 5313
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Xiong Chao
Date Reported: 2018-03-29

Section 9.8 says:

   C->S:MRCP/2.0 ... DEFINE-GRAMMAR 543258
   Channel-Identifier:32AECB23433801@speechrecog
   Content-Type:application/srgs+xml
   Content-ID:<helpgrammar@root-level.store>
   Content-Length:...

   <?xml version="1.0"?>

   <!-- the default grammar language is US English -->
   <grammar xmlns="http://www.w3.org/2001/06/grammar"
            xml:lang="en-US" version="1.0">

         <rule id="request">
               I need help
         </rule>

   S->C:MRCP/2.0 ... 543258 200 COMPLETE

It should say:

   C->S:MRCP/2.0 ... DEFINE-GRAMMAR 543258
   Channel-Identifier:32AECB23433801@speechrecog
   Content-Type:application/srgs+xml
   Content-ID:<helpgrammar@root-level.store>
   Content-Length:...

   <?xml version="1.0"?>

   <!-- the default grammar language is US English -->
   <grammar xmlns="http://www.w3.org/2001/06/grammar"
            xml:lang="en-US" version="1.0">

         <rule id="request">
               I need help
         </rule>

   </grammar>

   S->C:MRCP/2.0 ... 543258 200 COMPLETE

Notes:

</grammar> is missing

Errata ID: 5315
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Xiong Chao
Date Reported: 2018-03-30

Section 11.11 says:

   C->S:  MRCP/2.0 ... QUERY-VOICEPRINT 314163
          Channel-Identifier:32AECB23433801@speakverify
          Repository-URI:http://www.example.com/voiceprints/
          Voiceprint-Identifier:johnsmith

It should say:

   C->S:  MRCP/2.0 ... QUERY-VOICEPRINT 314163
          Channel-Identifier:32AECB23433801@speakverify
          Repository-URI:http://www.example.com/voiceprints/
          Voiceprint-Identifier:johnsmith.voiceprint

RFC 6788, "The Line-Identification Option", November 2012

Source of RFC: 6man (int)

Errata ID: 7077
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Fernando Gont
Date Reported: 2022-08-09

Section 6.2 says:

The link-layer destination address of the outer IPv6 datagram containing the outer IPv6 datagram MUST be resolved using regular Neighbor Discovery procedures.

It should say:

The link-layer destination address of the outer IPv6 datagram MUST be resolved using regular Neighbor Discovery procedures.

Notes:

The corrected text removes the text duplication with is technically incorrect. The text may also be fixed as:

The link-layer destination address of the outer IPv6 datagram containing the tunneled Router Advertisement MUST be resolved using regular Neighbor Discovery procedures.

RFC 6797, "HTTP Strict Transport Security (HSTS)", November 2012

Source of RFC: websec (app)

Errata ID: 5204
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Nick Dilßner
Date Reported: 2017-12-13

Section 6.1.2 says:

includeSubDomains

It should say:

include-sub-domains

or

includesubdomains

Notes:

- In Section 6.1 the Strict-Transport-Security is defined as follows:

Strict-Transport-Security = "Strict-Transport-Security" ":" [ directive ] *( ";" [ directive ] )

- valueless Directive "includeSubDomains" is defined as a optional directive
- a directive is definied as followed:

directive = directive-name [ "=" directive-value ]

- so "includeSubDomains" is only a directive-name which is defined as "token"
- according to "[RFC2616], Section 2.2" a token is any octet from 0 - 127 except CTL's (octets 0 - 31 + 127) and separators which NOT exclude '-' (octet 45)


So all Fine? Yes, BUT at [RFC6797], Section 6.1 the "overall reuqirements for directives", Rule 3 defines:

3. Directive names are case-insensitive.

And there is no other specification in Section 6.1.2 or has a IANA policy definition [RFC5226] like it is defined for additionals.



- That means the "directive-name" includeSubDomains is "case-insensitive"!

The "case-sensitive" camelized directive-name is misleading, because of many other definitions with "-", like seen in all examples or in Header Field itself.


- to aware the clear understanding the "directive definition" in section 6.1.2 and ALL occurences needs to be renamend.

the minimum of renaming is "includesubdomains" OR "INCLUDESUBDOMAINS", but this is not readable anymore.
- So it should be renamed like other valuless directives for Example the "schemes-source's" directives at "Content-Security-Policy", which means:

"include-sub-domains"


Best Regards

Nick

Errata ID: 5372
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Claudio Saavedra
Date Reported: 2018-05-29

Section 8.1 says:

o  Update the UA's cached information for the Known HSTS Host if
      either or both of the max-age and includeSubDomains header field
      value tokens are conveying information different than that already
      maintained by the UA.

It should say:

o  Update the UA's cached information for the Known HSTS Host.

Notes:

Section 8.1 states:

Update the UA's cached information for the Known HSTS Host if either
or both of the max-age and includeSubDomains header field value
tokens are conveying information different than that already
maintained by the UA.

The way I understand this is that if a HSTS host keeps sending the same values to a conforming client, this should not update the information cached and hence the cached information will expire after max-age seconds have passed since the _first_reception_ of this header.

However, section 11.2 states:

The "constant value into the future" approach can be accomplished by
constantly sending the same max-age value to UAs.

For example, a max-age value of 7776000 seconds is 90 days:

Strict-Transport-Security: max-age=7776000

Note that each receipt of this header by a UA will require the UA to
update its notion of when it must delete its knowledge of this Known
HSTS Host.

This seems to contradict what I quoted from section 8.1. If the server constantly sends a max-age of 7776000 and includeSubDomains is not changed (which is implicit in the example), then by 8.1 the cache
information won't be updated.

I believe that the desired implementation behavior is as described in 11.2, that is, UA must update the cached information, regardless of whether either of the max-age or includeSubDomains header field values are different from what is already maintained by the UA.

RFC 6803, "Camellia Encryption for Kerberos 5", November 2012

Source of RFC: krb-wg (sec)

Errata ID: 4326
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Greg Hudson
Date Reported: 2015-04-02

Section 10 says:

   Sample encryptions (all using the default cipher state):

   Plaintext: (empty)
   128-bit Camellia key:
       1D C4 6A 8D 76 3F 4F 93 74 2B CB A3 38 75 76 C3
   Random confounder:
       B6 98 22 A1 9A 6B 09 C0 EB C8 55 7D 1F 1B 6C 0A
   Ciphertext:
       C4 66 F1 87 10 69 92 1E DB 7C 6F DE 24 4A 52 DB
       0B A1 0E DC 19 7B DB 80 06 65 8C A3 CC CE 6E B8

   Plaintext: 1
   Random confounder:
       6F 2F C3 C2 A1 66 FD 88 98 96 7A 83 DE 95 96 D9
   128-bit Camellia key:
       50 27 BC 23 1D 0F 3A 9D 23 33 3F 1C A6 FD BE 7C
   Ciphertext:
       84 2D 21 FD 95 03 11 C0 DD 46 4A 3F 4B E8 D6 DA
       88 A5 6D 55 9C 9B 47 D3 F9 A8 50 67 AF 66 15 59
       B8

   Plaintext: 9 bytesss
   Random confounder:
       A5 B4 A7 1E 07 7A EE F9 3C 87 63 C1 8F DB 1F 10
   128-bit Camellia key:
       A1 BB 61 E8 05 F9 BA 6D DE 8F DB DD C0 5C DE A0
   Ciphertext:
       61 9F F0 72 E3 62 86 FF 0A 28 DE B3 A3 52 EC 0D
       0E DF 5C 51 60 D6 63 C9 01 75 8C CF 9D 1E D3 3D
       71 DB 8F 23 AA BF 83 48 A0

   Plaintext: 13 bytes byte
   Random confounder:
       19 FE E4 0D 81 0C 52 4B 5B 22 F0 18 74 C6 93 DA
   128-bit Camellia key:
       2C A2 7A 5F AF 55 32 24 45 06 43 4E 1C EF 66 76
   Ciphertext:
       B8 EC A3 16 7A E6 31 55 12 E5 9F 98 A7 C5 00 20
       5E 5F 63 FF 3B B3 89 AF 1C 41 A2 1D 64 0D 86 15
       C9 ED 3F BE B0 5A B6 AC B6 76 89 B5 EA

   Plaintext: 30 bytes bytes bytes bytes byt 
   Random confounder:
       CA 7A 7A B4 BE 19 2D AB D6 03 50 6D B1 9C 39 E2
   128-bit Camellia key:
       78 24 F8 C1 6F 83 FF 35 4C 6B F7 51 5B 97 3F 43
   Ciphertext:
       A2 6A 39 05 A4 FF D5 81 6B 7B 1E 27 38 0D 08 09
       0C 8E C1 F3 04 49 6E 1A BD CD 2B DC D1 DF FC 66
       09 89 E1 17 A7 13 DD BB 57 A4 14 6C 15 87 CB A4
       35 66 65 59 1D 22 40 28 2F 58 42 B1 05 A5

   Plaintext: (empty)
   Random confounder:
       3C BB D2 B4 59 17 94 10 67 F9 65 99 BB 98 92 6C
   256-bit Camellia key:
       B6 1C 86 CC 4E 5D 27 57 54 5A D4 23 39 9F B7 03
       1E CA B9 13 CB B9 00 BD 7A 3C 6D D8 BF 92 01 5B
   Ciphertext:
       03 88 6D 03 31 0B 47 A6 D8 F0 6D 7B 94 D1 DD 83
       7E CC E3 15 EF 65 2A FF 62 08 59 D9 4A 25 92 66

   Plaintext: 1
   Random confounder:
       DE F4 87 FC EB E6 DE 63 46 D4 DA 45 21 BB A2 D2
   256-bit Camellia key:
       1B 97 FE 0A 19 0E 20 21 EB 30 75 3E 1B 6E 1E 77
       B0 75 4B 1D 68 46 10 35 58 64 10 49 63 46 38 33
   Ciphertext:
       2C 9C 15 70 13 3C 99 BF 6A 34 BC 1B 02 12 00 2F
       D1 94 33 87 49 DB 41 35 49 7A 34 7C FC D9 D1 8A
       12

   Plaintext: 9 bytesss
   Random confounder:
       AD 4F F9 04 D3 4E 55 53 84 B1 41 00 FC 46 5F 88
   256-bit Camellia key:
       32 16 4C 5B 43 4D 1D 15 38 E4 CF D9 BE 80 40 FE
       8C 4A C7 AC C4 B9 3D 33 14 D2 13 36 68 14 7A 05
   Ciphertext:
       9C 6D E7 5F 81 2D E7 ED 0D 28 B2 96 35 57 A1 15
       64 09 98 27 5B 0A F5 15 27 09 91 3F F5 2A 2A 9C
       8E 63 B8 72 F9 2E 64 C8 39

   Plaintext: 13 bytes byte
   Random confounder:
       CF 9B CA 6D F1 14 4E 0C 0A F9 B8 F3 4C 90 D5 14
   256-bit Camellia key:
       B0 38 B1 32 CD 8E 06 61 22 67 FA B7 17 00 66 D8
       8A EC CB A0 B7 44 BF C6 0D C8 9B CA 18 2D 07 15
   Ciphertext:
       EE EC 85 A9 81 3C DC 53 67 72 AB 9B 42 DE FC 57
       06 F7 26 E9 75 DD E0 5A 87 EB 54 06 EA 32 4C A1
       85 C9 98 6B 42 AA BE 79 4B 84 82 1B EE

   Plaintext: 30 bytes bytes bytes bytes byt
   Random confounder:
       64 4D EF 38 DA 35 00 72 75 87 8D 21 68 55 E2 28
   256-bit Camellia key:
       CC FC D3 49 BF 4C 66 77 E8 6E 4B 02 B8 EA B9 24
       A5 46 AC 73 1C F9 BF 69 89 B9 96 E7 D6 BF BB A7
   Ciphertext:
       0E 44 68 09 85 85 5F 2D 1F 18 12 52 9C A8 3B FD
       8E 34 9D E6 FD 9A DA 0B AA A0 48 D6 8E 26 5F EB
       F3 4A D1 25 5A 34 49 99 AD 37 14 68 87 A6 C6 84
       57 31 AC 7F 46 37 6A 05 04 CD 06 57 14 74

It should say:

   Sample encryptions (all using the default cipher state):

   Plaintext: (empty)
   Random confounder:
       B6 98 22 A1 9A 6B 09 C0 EB C8 55 7D 1F 1B 6C 0A
   128-bit Camellia key:
       1D C4 6A 8D 76 3F 4F 93 74 2B CB A3 38 75 76 C3
   Key usage: 0
   Ciphertext:
       C4 66 F1 87 10 69 92 1E DB 7C 6F DE 24 4A 52 DB
       0B A1 0E DC 19 7B DB 80 06 65 8C A3 CC CE 6E B8

   Plaintext: 1
   Random confounder:
       6F 2F C3 C2 A1 66 FD 88 98 96 7A 83 DE 95 96 D9
   128-bit Camellia key:
       50 27 BC 23 1D 0F 3A 9D 23 33 3F 1C A6 FD BE 7C
   Key usage: 1
   Ciphertext:
       84 2D 21 FD 95 03 11 C0 DD 46 4A 3F 4B E8 D6 DA
       88 A5 6D 55 9C 9B 47 D3 F9 A8 50 67 AF 66 15 59
       B8

   Plaintext: 9 bytesss
   Random confounder:
       A5 B4 A7 1E 07 7A EE F9 3C 87 63 C1 8F DB 1F 10
   128-bit Camellia key:
       A1 BB 61 E8 05 F9 BA 6D DE 8F DB DD C0 5C DE A0
   Key usage: 2
   Ciphertext:
       61 9F F0 72 E3 62 86 FF 0A 28 DE B3 A3 52 EC 0D
       0E DF 5C 51 60 D6 63 C9 01 75 8C CF 9D 1E D3 3D
       71 DB 8F 23 AA BF 83 48 A0

   Plaintext: 13 bytes byte
   Random confounder:
       19 FE E4 0D 81 0C 52 4B 5B 22 F0 18 74 C6 93 DA
   128-bit Camellia key:
       2C A2 7A 5F AF 55 32 24 45 06 43 4E 1C EF 66 76
   Key usage: 3
   Ciphertext:
       B8 EC A3 16 7A E6 31 55 12 E5 9F 98 A7 C5 00 20
       5E 5F 63 FF 3B B3 89 AF 1C 41 A2 1D 64 0D 86 15
       C9 ED 3F BE B0 5A B6 AC B6 76 89 B5 EA

   Plaintext: 30 bytes bytes bytes bytes byt 
   Random confounder:
       CA 7A 7A B4 BE 19 2D AB D6 03 50 6D B1 9C 39 E2
   128-bit Camellia key:
       78 24 F8 C1 6F 83 FF 35 4C 6B F7 51 5B 97 3F 43
   Key usage: 4
   Ciphertext:
       A2 6A 39 05 A4 FF D5 81 6B 7B 1E 27 38 0D 08 09
       0C 8E C1 F3 04 49 6E 1A BD CD 2B DC D1 DF FC 66
       09 89 E1 17 A7 13 DD BB 57 A4 14 6C 15 87 CB A4
       35 66 65 59 1D 22 40 28 2F 58 42 B1 05 A5

   Plaintext: (empty)
   Random confounder:
       3C BB D2 B4 59 17 94 10 67 F9 65 99 BB 98 92 6C
   256-bit Camellia key:
       B6 1C 86 CC 4E 5D 27 57 54 5A D4 23 39 9F B7 03
       1E CA B9 13 CB B9 00 BD 7A 3C 6D D8 BF 92 01 5B
   Key usage: 0
   Ciphertext:
       03 88 6D 03 31 0B 47 A6 D8 F0 6D 7B 94 D1 DD 83
       7E CC E3 15 EF 65 2A FF 62 08 59 D9 4A 25 92 66

   Plaintext: 1
   Random confounder:
       DE F4 87 FC EB E6 DE 63 46 D4 DA 45 21 BB A2 D2
   256-bit Camellia key:
       1B 97 FE 0A 19 0E 20 21 EB 30 75 3E 1B 6E 1E 77
       B0 75 4B 1D 68 46 10 35 58 64 10 49 63 46 38 33
   Key usage: 1
   Ciphertext:
       2C 9C 15 70 13 3C 99 BF 6A 34 BC 1B 02 12 00 2F
       D1 94 33 87 49 DB 41 35 49 7A 34 7C FC D9 D1 8A
       12

   Plaintext: 9 bytesss
   Random confounder:
       AD 4F F9 04 D3 4E 55 53 84 B1 41 00 FC 46 5F 88
   256-bit Camellia key:
       32 16 4C 5B 43 4D 1D 15 38 E4 CF D9 BE 80 40 FE
       8C 4A C7 AC C4 B9 3D 33 14 D2 13 36 68 14 7A 05
   Key usage: 2
   Ciphertext:
       9C 6D E7 5F 81 2D E7 ED 0D 28 B2 96 35 57 A1 15
       64 09 98 27 5B 0A F5 15 27 09 91 3F F5 2A 2A 9C
       8E 63 B8 72 F9 2E 64 C8 39

   Plaintext: 13 bytes byte
   Random confounder:
       CF 9B CA 6D F1 14 4E 0C 0A F9 B8 F3 4C 90 D5 14
   256-bit Camellia key:
       B0 38 B1 32 CD 8E 06 61 22 67 FA B7 17 00 66 D8
       8A EC CB A0 B7 44 BF C6 0D C8 9B CA 18 2D 07 15
   Key usage: 3
   Ciphertext:
       EE EC 85 A9 81 3C DC 53 67 72 AB 9B 42 DE FC 57
       06 F7 26 E9 75 DD E0 5A 87 EB 54 06 EA 32 4C A1
       85 C9 98 6B 42 AA BE 79 4B 84 82 1B EE

   Plaintext: 30 bytes bytes bytes bytes byt
   Random confounder:
       64 4D EF 38 DA 35 00 72 75 87 8D 21 68 55 E2 28
   256-bit Camellia key:
       CC FC D3 49 BF 4C 66 77 E8 6E 4B 02 B8 EA B9 24
       A5 46 AC 73 1C F9 BF 69 89 B9 96 E7 D6 BF BB A7
   Key usage: 4
   Ciphertext:
       0E 44 68 09 85 85 5F 2D 1F 18 12 52 9C A8 3B FD
       8E 34 9D E6 FD 9A DA 0B AA A0 48 D6 8E 26 5F EB
       F3 4A D1 25 5A 34 49 99 AD 37 14 68 87 A6 C6 84
       57 31 AC 7F 46 37 6A 05 04 CD 06 57 14 74

Notes:

The encryption test vectors were missing key usage numbers.

RFC 6844, "DNS Certification Authority Authorization (CAA) Resource Record", January 2013

Note: This RFC has been obsoleted by RFC 8659

Source of RFC: pkix (sec)

Errata ID: 6715
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jaime Hablutzel
Date Reported: 2021-10-18

Section 3 says:

If the domain name holder specifies one or more iodef properties, a
certificate issuer MAY report invalid certificate requests to that
address.

It should say:

If the domain name holder specifies one or more iodef properties, a
certificate issuer MAY report invalid certificate requests to those
addresses.

Notes:

"address" should be plural.

RFC 6857, "Post-Delivery Message Downgrading for Internationalized Email Messages", March 2013

Source of RFC: eai (app)

Errata ID: 6573
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Kaspar Etter
Date Reported: 2021-05-05

Section A says:

   From: =?UTF-8?Q?DISPLAY-LOCAL?=
         =?UTF-8?Q?NON-ASCII-LOCAL=40example=2Ecom?= :;

It should say:

   From: =?UTF-8?Q?DISPLAY-LOCAL_?=
         =?UTF-8?Q?NON-ASCII-LOCAL=40example=2Ecom?= :;

Notes:

Taking the original text from Errata 3955 (https://www.rfc-editor.org/errata/eid3955), the two encoded-words decode to: DISPLAY-LOCALNON-ASCII-LOCAL@example.com :; (According to section 6.2 of RFC 2047, linear whitespace between adjacent encoded-words is ignored.) This is clearly not desirable and thus a space should be encoded at the end of all display names in appendix A.

Errata ID: 6930
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: John Klensin
Date Reported: 2022-04-10

Section 3.1.8 says:

The <addr-spec> element that contains non-ASCII strings may appear in two forms as:

   "<" addr-spec ">"

   or

   addr-spec

   Rewrite both as:

   ENCODED-WORD " :;"

It should say:

The <addr-spec> element that contains non-ASCII strings may appear in two forms as:

   "<"  local-part "@" domain ">"

   or

   local-part "@" domain

   If the <local-part> contains non-ASCII characters, rewrite both to:

   ENCODED-WORD "@" domain

   If the <domain> contains non-ASCII characters in any of its labels, they MUST appear in A-label form as described in Section 3.1.6.

If the <addr-spec> is part of a <mailbox> specification that contains a <display-name>, the display name should be handled as per the discussion in Section 3.1.5 and the <mailbox> and <addr-spec> containing non-ASCII characters  MUST appear as

   DISPLAY-NAME "<" ENCODED-WORD "@" domain ">"

for consistency with RFC 5322.

Notes:

Recommend "Hold for document update" and see the extensive comments on Erratum 6573.

The text above, while correct, is fairly horrible and might make the confusion between the requirements of Sections 3.1.5 and 3.1.8 even worse. A complete rewrite of this section and possibly 3.1.5 would be a better fix. Note the prohibition on Encoded Words in <addr-spec> in RFC 2047, which requires updating. Also note that the " :;" construction, which is correct in Section 3.1.7, does not belong in the above.

It also not clear to me why, under some principle of minimal change, the brackets should not be just left alone if they appear in the original with no adjacent display-name.

RFC 6868, "Parameter Value Encoding in iCalendar and vCard", February 2013

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 4374
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Worik Stanton
Date Reported: 2015-05-21

Section 3 says:

   When parsing iCalendar or vCard parameter values, the following
   apply:

   o  the character sequence ^n (U+005E, U+006E) is decoded into an
      appropriate formatted line break according to the type of system
      being used

   o  the character sequence ^^ (U+005E, U+005E) is decoded into the ^
      character (U+005E)

   o  the character sequence ^' (U+005E, U+0027) is decoded into the "
      character (U+0022)

   o  if a ^ (U+005E) character is followed by any character other than
      the ones above, parsers MUST leave both the ^ and the following
      character in place

It should say:

   When parsing iCalendar or vCard parameter values, the following
   apply:

   o  first all occurrences of the character sequence ^n (U+005E,
      U+006E) is decoded into an appropriate formatted line break
      according to the type of system being used

   o  second all occurrences of the character sequence ^' (U+005E,
      U+0027) is decoded into the " character (U+0022)

   o  third all occurrences of the character sequence ^^ (U+005E,
      U+005E) is decoded into the ^ character (U+005E)

   o  if a ^ (U+005E) character is followed by any character other than
      the ones above, parsers MUST leave both the ^ and the following
      character in place

Notes:

It is unclear how a string like: FOO=^^n should be decoded.

Possibly FOO=^n or FOO=^\n or FOO=\n

Section 3 implies that ^n is converted first, then ^^, then ^'. But it is not explicit. Also this leads to a contradiction. FOO=^^n will become FOO=\n, not what is expected.

An equally reasonable interpretation is to proceed from the left and convert as encountered.

The first gives FOO=\n the second FOO=^n.

In the absence of an explicit definition of the order of interpretation it is impossible to decide which to use.

RFC 6901, "JavaScript Object Notation (JSON) Pointer", April 2013

Source of RFC: appsawg (app)

Errata ID: 5745
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sven Willenbücher
Date Reported: 2019-06-04

Section 5 says:

The following JSON strings evaluate to the accompanying values:

    "/i\\j"      5
    "/k\"l"      6

It should say:

The following JSON strings evaluate to the accompanying values:

    /i\j      5
    /k"l      6

Notes:

In JSON itself some special characters like the backslash and the double quote character can be escaped using a backslash. A similar escaping was not described for JSON pointers. Therefore it is not clear to me why such an escaping is needed in JSON pointers too. Maybe the additional double quotes around the example JSON pointers enforce this. In the corrected text I have stated my view on this.

RFC 6940, "REsource LOcation And Discovery (RELOAD) Base Protocol", January 2014

Source of RFC: p2psip (rai)

Errata ID: 5530
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Chen
Date Reported: 2018-10-16

Section 10.7.4.4 says:

P SHOULD then send a Ping for its own Node-ID routed through B.

It should say:

P SHOULD then send a Ping for its own Resource-ID n+1 routed through B.

Notes:

10.7.4.4 says, "repeat the discovery process used in the initial join", which refers to the 2nd paragraph after 10.5.9:

"It SHOULD send a Ping directed at Resource-ID n+1 (directly after its own Resource-ID)."

Ping Node-ID is simply wrong. This correction makes it consistent with 10.5.9. Credit goes to xramtsov in the mailing list.

RFC 6960, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", June 2013

Note: This RFC has been updated by RFC 8954

Source of RFC: pkix (sec)

Errata ID: 6165
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Yury Strozhevsky
Date Reported: 2020-05-11

Section 1 says:

---

It should say:

   o  Appendix B.1 provides correct KeyHash type processing description. Now SHA-1 hash must be calculated for responder's public key ASN.1 value without tag, length and unused bits.

Notes:

The RFC6960 changes OCSP protocol in part of KeyHash type calculation. In RFC2560 there is the description:
KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
(excluding the tag and length fields)

But in Appendix B.1, which is the major OCSP descriptive module, stated:
KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
-- (i.e., the SHA-1 hash of the value of the
-- BIT STRING subjectPublicKey [excluding
-- the tag, length, and number of unused
-- bits] in the responder's certificate)

The difference is in what would be under SHA-1 hash. In RFC2560 KeyHash would be calculated for entire BIT STRING value, with "unused bits" byte (first byte in BIT STRING value), but Appendix B.1 in RFC6960 states that SHA-1 hash must be calculated for BIT STRING value without "unused bits".

Errata ID: 6166
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Yury Strozhevsky
Date Reported: 2020-05-11

Section Appendix B.2 says:

KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
                         -- (excluding the tag and length fields)

It should say:

KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
                         -- (i.e., the SHA-1 hash of the value of the
                         -- BIT STRING subjectPublicKey [excluding
                         -- the tag, length, and number of unused
                         -- bits] in the responder's certificate)

Notes:

These two descriptions of KeyHash produce different SHA-1 hashes due to different values: one is pure BIT STRING value block, with "unused bits" byte, but other - without "unused byte". Also the Appendix B.2 must be aligned with Appendix B.1 information.

Errata ID: 6167
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Yury Strozhevsky
Date Reported: 2020-05-11

Section 4.2.1 says:

   KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
   (excluding the tag and length fields)

It should say:

KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
                         -- (i.e., the SHA-1 hash of the value of the
                         -- BIT STRING subjectPublicKey [excluding
                         -- the tag, length, and number of unused
                         -- bits] in the responder's certificate)

Notes:

Same explanationa as for https://www.rfc-editor.org/errata/eid6166

RFC 6961, "The Transport Layer Security (TLS) Multiple Certificate Status Request Extension", June 2013

Note: This RFC has been obsoleted by RFC 8446

Source of RFC: tls (sec)

Errata ID: 4882
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ashwini Oruganti
Date Reported: 2016-12-10

Section 2.2 says:

opaque OCSPResponse<0..2^24-1>;

It should say:

opaque OCSPResponse<1..2^24-1>;

Notes:

- The text below the definition states:
Only one OCSP response, with a length of at least one byte, may be sent for status_type "ocsp".

- `OCSPResponse` was originally (correctly) defined in RFC6066 (https://tools.ietf.org/html/rfc6066#section-8) with a lower bound of 1 byte.

RFC 6962, "Certificate Transparency", June 2013

Note: This RFC has been obsoleted by RFC 9162

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 4204
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Paul Hadfield
Date Reported: 2014-12-18

Section 3.1 says:

   "precertificate_chain" is a chain of additional certificates required
   to verify the Precertificate submission.  The first certificate MAY
   be a valid Precertificate Signing Certificate and MUST certify the
   first certificate.  Each following certificate MUST directly certify
   the one preceding it.  The final certificate MUST be a root
   certificate accepted by the log.

It should say:

   "precertificate_chain" is a chain of additional certificates required
   to verify the Precertificate submission.  The first certificate MAY
   be a valid Precertificate Signing Certificate and MUST certify the
   Precertificate.  Each following certificate MUST directly certify
   the one preceding it.  The final certificate MUST be a root
   certificate accepted by the log.

Notes:

It seems to be a cut and paste error that affects the meaning.

Errata ID: 4286
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Laurie
Date Reported: 2015-03-04

Section 3 says:

When a valid certificate is submitted to a log, the log MUST
immediately return a Signed Certificate Timestamp (SCT).

It should say:

When a valid certificate or Precertificate is submitted to a log, the
log MUST immediately return a Signed Certificate Timestamp (SCT).

RFC 7009, "OAuth 2.0 Token Revocation", August 2013

Source of RFC: oauth (sec)

Errata ID: 6663
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ashvin Narayanan
Date Reported: 2021-08-22

Section 2.1 says:

The client constructs the request by including the following
   parameters using the "application/x-www-form-urlencoded" format in
   the HTTP request entity-body:

   token   REQUIRED.  The token that the client wants to get revoked.

   token_type_hint  OPTIONAL.  A hint about the type of the token
           submitted for revocation.  Clients MAY pass this parameter in
           order to help the authorization server to optimize the token
           lookup.  If the server is unable to locate the token using
           the given hint, it MUST extend its search across all of its
           supported token types.  An authorization server MAY ignore
           this parameter, particularly if it is able to detect the
           token type automatically.  This specification defines two
           such values:

           * access_token: An access token as defined in [RFC6749],
             Section 1.4

           * refresh_token: A refresh token as defined in [RFC6749],
             Section 1.5

           Specific implementations, profiles, and extensions of this
           specification MAY define other values for this parameter
           using the registry defined in Section 4.1.2.

   The client also includes its authentication credentials as described
   in Section 2.3. of [RFC6749].

   For example, a client may request the revocation of a refresh token
   with the following request:

     POST /revoke HTTP/1.1
     Host: server.example.com
     Content-Type: application/x-www-form-urlencoded
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW

     token=45ghiukldjahdnhzdauz&token_type_hint=refresh_token

   The authorization server first validates the client credentials (in
   case of a confidential client) and then verifies whether the token
   was issued to the client making the revocation request.  If this
   validation fails, the request is refused and the client is informed
   of the error by the authorization server as described below.

It should say:

The client calls the revocation endpoint using an HTTP
   POST [RFC7231] request with the following parameters sent as
   "application/x-www-form-urlencoded" data in the request body:

   token   REQUIRED.  The token that the client wants to get revoked.

   token_type_hint  OPTIONAL.  A hint about the type of the token
           submitted for revocation.  Clients MAY pass this parameter in
           order to help the authorization server to optimize the token
           lookup.  If the server is unable to locate the token using
           the given hint, it MUST extend its search across all of its
           supported token types.  An authorization server MAY ignore
           this parameter, particularly if it is able to detect the
           token type automatically.  This specification defines two
           such values:

           * access_token: An access token as defined in [RFC6749],
             Section 1.4

           * refresh_token: A refresh token as defined in [RFC6749],
             Section 1.5

           Specific implementations, profiles, and extensions of this
           specification MAY define other values for this parameter
           using the registry defined in Section 4.1.2.

   The client MUST also include in the request, the access token it received 
   from the authorization server. It must do so in the same way as it  would  
   when accessing a protected resource, as describe in [RFC6749], Section 7.

   The following is a non-normative example request in which the client uses 
   its access token to revoke the associated refresh token:

     POST /revoke HTTP/1.1
     Host: server.example.com
     Content-Type: application/x-www-form-urlencoded
     Authorization: Bearer czZCaGRSa3F0MzpnWDFmQmF0M2JW

     token=45ghiukldjahdnhzdauz&token_type_hint=refresh_token

   The following is a non-normative example request in which the client uses 
   its access token to revoke the same access token:

     POST /revoke HTTP/1.1
     Host: server.example.com
     Content-Type: application/x-www-form-urlencoded
     Authorization: Bearer czZCaGRSa3F0MzpnWDFmQmF0M2JW

     token=czZCaGRSa3F0MzpnWDFmQmF0M2JW&token_type_hint=access_token

   The authorization server MUST validate the access token used by the        
   client to authorize its call to the revocation endpoint, including 
   ensuring that it is not expired or revoked. 
   Additionally, the authorization server MUST also validate whether the
   access token used for authorization is part of the same grant  as the 
   token being revoked. If validation fails, the request is  refused and 
   the client is informed of the error by the authorization server. 
   In the case of a bearer token, the authorization server SHOULD respond  
   with an HTTP 401 code as described in OAuth 2.0 Bearer Token Usage 
   [RFC6750], Section 3. 
   Errors based on other types of tokens are beyond the scope of this 
   specification.
    

Notes:

It appears as though the authors of RFC7009 have failed to consider that requests to revoke are likely to come from non-confidential clients and such, would lack authentication credentials. Regardless of the type of client however, authentication should not be required. The OAuth 2.0 specification (RFC6749) does not specify verifying that the access token belongs to the client accessing protected resources, of which revocation is one. It is the role of the access token alone to signify authorization required to make requests to protected resources. If this is an issue for revocation, then it is an issue for all protected resources and counter measures may be proposed in a separate RFC rather than broadening the scope of this particular RFC. As per the original text itself, "This specification in general does not intend to provide countermeasures against token theft and abuse." Additionally, "If an attacker is able to successfully guess a public client's client_id and one of their tokens, or a private client's credentials and one of their tokens, they could do much worse damage by using the token elsewhere than by revoking it. If they chose to revoke the token, the legitimate client will lose its authorization grant and will need to prompt the user again. No further damage is done and the guessed token is now worthless."
Note that the client_id is not meant to be private information to begin with, so relying on an attacker "guessing" it should not be seen as a security countermeasure. This section of RFC7009 will be referenced in a subsequent errata.

RFC 7027, "Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS)", October 2013

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 4254
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Annie Yousar
Date Reported: 2015-02-03

Section 1 says:

   pseudo-random way and comply with the security requirements of
|  relevant standards from ISO [ISO1] [ISO2], ANSI [ANSI1], NIST [FIPS],
|  and SecG [SEC2].

 

It should say:

   pseudo-random way and comply with the security requirements of
|  relevant standards from ISO [ISO1], ANSI [ANSI1], NIST [FIPS],
|  and SECG [SEC2].

Notes:

The referenced by [ISO2] standard ISO/IEC 15946-2:2002 was already withdrawn at 2007-11-07 and is therefore no more relevant.
The industry consortium Standards for Efficient Cryptography Group uses itself the abbreviation SECG, see http://www.secg.org.

RFC 7030, "Enrollment over Secure Transport", October 2013

Note: This RFC has been updated by RFC 8951, RFC 8996

Source of RFC: pkix (sec)

Errata ID: 5926
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Justin Cranford
Date Reported: 2019-12-03

Section A.1 to A.4 says:

   HTTP/1.1 200 OK
   Status: 200 OK
   Content-Type: application/pkcs7-mime
   Content-Transfer-Encoding: base64
   Content-Length: 4246

It should say:

   HTTP/1.1 200 OK
   Status: 200 OK
   Content-Type: application/pkcs7-mime
   Transfer-Encoding: base64

Notes:

EST examples in appendix A.1 through A.4 have incorrect "Content-Length". That header is mutually exclusive with "Transfer-Encoding" according to HTTP 1.1 RFC 2616. If a clients receives both headers, "Transfer-Encoding" header takes precedence and the erroneous "Content-Length" header must be ignored.

HTTP 1.1 RFC 2616 Section 4.4 (https://tools.ietf.org/html/rfc2616#section-4.4)

3.If a Content-Length header field (section 14.13) is present, its
decimal value in OCTETs represents both the entity-length and the
transfer-length. The Content-Length header field MUST NOT be sent
if these two lengths are different (i.e., if a Transfer-Encoding
header field is present). If a message is received with both a
Transfer-Encoding header field and a Content-Length header field,
the latter MUST be ignored.


EST RFC 7030 is non-compliant with HTTP 1.1 RFC 2616.

Please remove erroneous "Content-Length" header from all affected EST response examples in Appendixes A.1 through to A.4. This is incorrect and misleading.

Please make this fix at same time the erroneous "Content-Transfer-Encoding" header is corrected to be "Transfer-Encoding", as reported in a different errata.

Errata ID: 5779
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Simon Edänge
Date Reported: 2019-07-13

Section A.4 says:

 Because the DecryptKeyIdentifier attribute is not included in this
   request, the response does not include additional encryption beyond
   the TLS session.  The EST server response is:

   HTTP/1.1 200 OK
   Status: 200 OK
   Content-Type: multipart/mixed ; boundary=estServerExampleBoundary
   Content-Length: 3219

   This is the preamble.  It is to be ignored, though it
   is a handy place for estServer to include an explanatory note,
   including contact or support information.
   --estServerExampleBoundary
   Content-Type: application/pkcs8
   Content-Transfer-Encoding: base64

It should say:

 Because the DecryptKeyIdentifier attribute is not included in this
   request, the response does not include additional encryption beyond
   the TLS session.  The EST server response is:

   HTTP/1.1 200 OK
   Status: 200 OK
   Content-Type: multipart/mixed; boundary=estServerExampleBoundary
   Content-Length: 3219

   This is the preamble.  It is to be ignored, though it
   is a handy place for estServer to include an explanatory note,
   including contact or support information.
   --estServerExampleBoundary
   Content-Type: application/pkcs8
   Content-Transfer-Encoding: base64

Notes:

Content-Type: multipart/mixed ; boundary=estServerExampleBoundary

The ; has a space, believe it or not, we implemented it that way.

Content-Type: multipart/mixed; boundary=estServerExampleBoundary

RFC 7044, "An Extension to the Session Initiation Protocol (SIP) for Request History Information", February 2014

Source of RFC: sipcore (rai)

Errata ID: 5014
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Dinoop Paloli
Date Reported: 2017-05-10

Section 9.1 and 10.3 says:

Notes:

Ambiguity exists regarding the handling of missing history info entry

Section 9.1 says,
If the Request-URI of the incoming request does not match the hi
-targeted-to-uri in the last hi-entry (i.e., the previous SIP entity
that sent the request did not include a History-Info header field),
the SIP entity MUST add an hi-entry to the end of the cache on
behalf of the previous SIP entity

According to that, for example, if request is received with,
Request URI : sip:peter@example.com
and History info : <sip:bob@example.com>;index=1
<sip:alice@example>;index=1.1
<sip:jain@example>;index=1.1.1
<sip:dave@example>;index=1.1.2

Then processing entity has to add an history info in to cache on behalf of previous entity as,
History info : <sip:bob@example.com>;index=1
<sip:alice@example>;index=1.1
<sip:jain@example>;index=1.1.1
<sip:dave@example>;index=1.1.2
<sip:peter@example.com>;index=1.1.2.1

But in section 10.3 basic rules 6 states,
If the request clearly has a gap in the hi-entry
(i.e., the last hi-entry and Request-URI differ), the entity
adding an hi-entry MUST add a single index with a value of "0"
(i.e., the non negative integer zero) prior to adding the
appropriate index for the action to be taken. For example, if
the index of the last hi-entry in the request received was 1.1.2
and there was a missing hi-entry and the request was being
forwarded to the next hop, the resulting index will be 1.1.2.0.1.

But as per 9.1 stated above, once an entity receive a request with missing history info
it has to add an entry to cache on behalf of previous one.
So referring the previous example the added index would be 1.1.2.1
And by applying the rule in 10.3, the index for the new request created by this entity would be 1.1.2.1.0.1 not 1.1.2.0.1

Errata ID: 5442
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ted Zhou
Date Reported: 2018-07-27

Section 9.3,10.2 says:

9.3   
   When a SIP entity receives a non-100 response or a request times out,
   the SIP entity performs the following steps:

      If the response is not a 100 or 2xx response, the SIP entity adds
      one or more Reason header fields to the hi-targeted-to-uri in the
      (newly) cached hi-entry reflecting the SIP response code in the
      non-100 or non-2xx response, per the procedures of Section 10.2.

10.2
   A Reason header field is added when the hi-entry is added to the
   cache based upon the receipt of a SIP response that is neither a 100
   nor a 2xx response, as described in Section 9.3. 

It should say:

9.3   
   When a SIP entity receives a non-18x response or a request times out,
   the SIP entity performs the following steps:

      If the response is not a 18x or 2xx response, the SIP entity adds
      one or more Reason header fields to the hi-targeted-to-uri in the
      (newly) cached hi-entry reflecting the SIP response code in the
      non-18x or non-2xx response, per the procedures of Section 10.2.

10.2
   A Reason header field is added when the hi-entry is added to the
   cache based upon the receipt of a SIP response that is neither a 18x
   nor a 2xx response, as described in Section 9.3. 

Notes:

I see we have several places using "100" or "non-100". I think the correct one should be "18x" or "non-18x".
Or, we can use "1xx" or "non-1xx".

100 means "100 Tring", it's not accurate.

Errata ID: 4345
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: chao wang
Date Reported: 2015-04-22

Section 6.2 says:

6.2.  User Agent Server (UAS) Behavior

   When receiving a request, a UAS MUST follow the procedures defined in
   Section 9.2.

It should say:

6.2.  User Agent Server (UAS) Behavior

   When receiving a request, a UAS MUST follow the procedures defined in
   Section 9.1.

Notes:

In fact, the subject of 9.2 is "Sending a Request with History-Info", according to the original text, it wants to refer to how to handle a received request in UAS, the right reference shall be section 9.1 (9.1. Receiving a Request).

RFC 7084, "Basic Requirements for IPv6 Customer Edge Routers", November 2013

Note: This RFC has been updated by RFC 9096

Source of RFC: v6ops (ops)

Errata ID: 7699
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Alin Nastac
Date Reported: 2023-11-14

Section 4.3 says:

   L-3:   An IPv6 CE router MUST advertise itself as a router for the
          delegated prefix(es) (and ULA prefix if configured to provide
          ULA addressing) using the "Route Information Option" specified
          in Section 2.3 of [RFC4191].  This advertisement is
          independent of having or not having IPv6 connectivity on the
          WAN interface.

It should say:

   L-3:   An IPv6 CE router MUST advertise itself as a router for the
          delegated prefix(es) (and ULA prefix if configured to provide
          ULA addressing) using the "Route Information Option" specified
          in Section 2.3 of [RFC4191], but only when correspondent "Prefix 
          Information Option" is not using the entire prefix delegation or
          its on-link flag is unset. This advertisement is independent of
          having or not having IPv6 connectivity on the WAN interface.

Notes:

When both on-link "Prefix Information Option" and "Route Information Option" will contain the same prefix, hosts that receive such Router Advertisements will have to add 2 almost identical routes in their routing tables:
- PIO route set to "PD/64 dev <incoming_interface>"
- RIO route set to "PD/64 dev <incoming_interface> nexthop <router_ll_address>"

In best case scenario, PIO will take precedence and RIO will have no effect.

In worst case scenario, RIO will take precedence and PIO route will have no effect, which will be equivalent with host ignoring the on-link flag of the PIO.

Errata ID: 7700
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Alin Nastac
Date Reported: 2023-11-14

Section 4.3 says:

   L-14:  The IPv6 CE router MUST send an ICMPv6 Destination Unreachable
          message, code 5 (Source address failed ingress/egress policy)
          for packets forwarded to it that use an address from a prefix
          that has been invalidated.

It should say:

   L-14:  The IPv6 CE router MUST send an ICMPv6 Destination Unreachable
          message, code 5 (Source address failed ingress/egress policy)
          for packets forwarded to it that use an address from a prefix
          that has been deprecated.

Notes:

The prefix route still need to exist on CPE to allow sending ICMPv6 errors back to the offending host.

Only deprecated prefixes (preferred lifetime=0, valid lifetime > 0) still have such route installed in CPE.

RFC 7105, "Using Device-Provided Location-Related Measurements in Location Configuration Protocols", January 2014

Source of RFC: geopriv (rai)

Errata ID: 6553
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Andy Brezinsky
Date Reported: 2021-04-20

Section 5.1 says:

An example of an LLDP measurement is shown in Figure 4.  This shows
an adjacent node (chassis) that is identified by the IP address
192.0.2.45 (hexadecimal c000022d), and the port on that node is
numbered using an agent circuit ID [RFC3046] of 162 (hexadecimal a2).

  <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
        time="2008-04-29T14:33:58">
    <lldp xmlns="urn:ietf:params:xml:ns:geopriv:lm:lldp">
      <chassis type="4">c000022d</chassis>
      <port type="6">a2</port>
    </lldp>
  </measurements>

It should say:

An example of an LLDP measurement is shown in Figure 4.  This shows
an adjacent node (chassis) that is identified by the IP address
192.0.2.45 (hexadecimal 01c000022d, with the leading octet set to the
IANA Address Family Numbers enumeration value for IPv4 [RFC1700]), and 
the port on that node is numbered using an agent circuit ID [RFC3046] of 
162 (hexadecimal a2).

  <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
        time="2008-04-29T14:33:58">
    <lldp xmlns="urn:ietf:params:xml:ns:geopriv:lm:lldp">
      <chassis type="5">01c000022d</chassis>
      <port type="6">a2</port>
    </lldp>
  </measurements>

Notes:

There are two issues identified with this example.

First, it wasn't clear what the original purpose of the 'type' field was. Upon further investigation, they were intended to carry the Chassis ID Subtype and Port ID Subtype of the respective elements. Given that, Chassis ID Subtype of '4' is the incorrect subtype for a Network Address. The correct Chassis ID Subtype defined in IEEE Std 802.1AB-2016 Table 8-2 ('chassis ID subtype enumeration') is '5'. The Port ID Subtype enumeration for Network Address is '4' and may be where the incorrect value was copied from.

Second, the example encoding of the IP Address 192.168.2.45 is missing the first octet designating the IANA Address Family Number. The example provided should be corrected to '01c000022d'.

IEEE Std 802.1AB-2016 Table 8-2 (a) notes: "networkAddress is an octet string that identifies a particular network address family and an associated network address that are encoded in network octet order. An IP address, for > example, would be encoded with the first octet containing the IANA Address Family Numbers enumeration value for the specific address type and octets 2 through n containing the > address value (for example, the encoding for C0-00-02-0A would indicate the IPv4 address 192.0.2.10)."

As it relates to the type of this erratum, Section 5.1 notes:

> Values are provided as hexadecimal sequences. The Device MUST report
> the values directly as they were provided by the adjacent node.
> Attempting to adjust or translate the type of identifier is likely to
> cause the measurement data to be useless.

Since clients already must hexadecimal encode the value that is reported without adjusting or translating it, only the example should be incorrect. However because people may have written their code to match the example directly, I'm leaving this as a technical type.

RFC 7116, "Licklider Transmission Protocol (LTP), Compressed Bundle Header Encoding (CBHE), and Bundle Protocol IANA Registries", February 2014

Source of RFC: IRTF

Errata ID: 7000
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ed Birrane
Date Reported: 2022-06-21

Section 3.2 says:

Section 3.2:
The CBHE specification [RFC6260] defines concepts of 'Node Number' and 'Service Number' that require registries managed by IANA.

Section 3.2.1:
IANA has set up a registry to manage CBHE Node Numbers.  This registry, titled "CBHE Node Numbers", has been added to the list of registries associated with the Bundle Protocol.

Section 3.2.2:
IANA has set up a registry to manage CBHE Service Numbers.  This registry, titled   "CBHE Service Numbers", has been added to the list of registries associated with the Bundle Protocol.

It should say:

Section 3.2:
The CBHE specification [RFC6260] defines concepts of 'Node Number' and 'Service Number' associated with the IPN naming scheme that require registries managed by IANA.

Section 3.2.1:
IANA has set up a registry to manage IPN Scheme Node Numbers.  This registry, titled "IPN Node Numbers", has been added to the list of registries associated with the Bundle Protocol.

Section 3.2.2:
IANA has set up a registry to manage IPN Scheme Service Numbers.  This registry, titled   "IPN Service Numbers", has been added to the list of registries associated with the Bundle Protocol.

Notes:

The Compressed Bundle Header Encoding (CBHE) RFC6260 defines node numbers and service numbers for the IPN naming scheme. Therefore, the registries created by RFC7116 should have been titled "IPN Node Numbers" and "IPN Service Numbers" instead of "CBHE Node Numbers" and "CBHE Service Numbers".

The IANA registries should be renamed, replacing CBHE with IPN to reflect this. This clarification is particularly important as BPv7 (RFC9171) can use the IPN naming scheme but does not have a concept of CBHE.

RFC 7118, "The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)", January 2014

Source of RFC: sipcore (rai)

Errata ID: 5937
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Roman Shpount
Date Reported: 2019-12-14

Section 8.2 says:

INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
From: sip:alice@example.com;tag=asdyka899
To: sip:bob@example.com
Call-ID: asidkj3ss
CSeq: 1 INVITE
Max-Forwards: 70
Supported: path, outbound, gruu
Route: <sip:proxy.example.com:443;transport=ws;lr>
Contact: <sip:alice@example.com;gr=urn:uuid:f81-7dec-14a06cf1;ob>
Content-Type: application/sdp


F2 100 Trying  proxy.example.com -> Alice (transport WSS)

SIP/2.0 100 Trying
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
From: sip:alice@example.com;tag=asdyka899
To: sip:bob@example.com
Call-ID: asidkj3ss
CSeq: 1 INVITE


F3 INVITE  proxy.example.com -> Bob (transport UDP)

INVITE sip:bob@203.0.113.22:5060 SIP/2.0
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKhjhjqw32c
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
Record-Route: <sip:proxy.example.com;transport=udp;lr>,
 <sip:h7kjh12s@proxy.example.com:443;transport=wss;lr>
From: sip:alice@example.com;tag=asdyka899
To: sip:bob@example.com
Call-ID: asidkj3ss
CSeq: 1 INVITE
Max-Forwards: 69
Supported: path, outbound, gruu
Contact: <sip:alice@example.com;gr=urn:uuid:f81-7dec-14a06cf1;ob>
Content-Type: application/sdp

F4 200 OK  Bob -> proxy.example.com (transport UDP)

SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKhjhjqw32c
 ;received=192.0.2.10
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
Record-Route: <sip:proxy.example.com;transport=udp;lr>,
 <sip:h7kjh12s@proxy.example.com:443;transport=ws;lr>
From: sip:alice@example.com;tag=asdyka899
To: sip:bob@example.com;tag=bmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 INVITE
Contact: <sip:bob@203.0.113.22:5060;transport=udp>
Content-Type: application/sdp


F5 200 OK  proxy.example.com -> Alice (transport WSS)

SIP/2.0 200 OK
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
Record-Route: <sip:proxy.example.com;transport=udp;lr>,
 <sip:h7kjh12s@proxy.example.com:443;transport=ws;lr>
From: sip:alice@example.com;tag=asdyka899
To: sip:bob@example.com;tag=bmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 INVITE
Contact: <sip:bob@203.0.113.22:5060;transport=udp>
Content-Type: application/sdp


F6 ACK  Alice -> proxy.example.com (transport WSS)

ACK sip:bob@203.0.113.22:5060;transport=udp SIP/2.0
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090
Route: <sip:h7kjh12s@proxy.example.com:443;transport=ws;lr>,
 <sip:proxy.example.com;transport=udp;lr>,
From: sip:alice@example.com;tag=asdyka899
To: sip:bob@example.com;tag=bmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 ACK
Max-Forwards: 70

F7 ACK  proxy.example.com -> Bob (transport UDP)

ACK sip:bob@203.0.113.22:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKhwpoc80zzx
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090
From: sip:alice@example.com;tag=asdyka899
To: sip:bob@example.com;tag=bmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 ACK
Max-Forwards: 69


F8 BYE  Bob -> proxy.example.com (transport UDP)

BYE sip:alice@example.com;gr=urn:uuid:f81-7dec-14a06cf1;ob SIP/2.0
Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001
Route: <sip:proxy.example.com;transport=udp;lr>,
 <sip:h7kjh12s@proxy.example.com:443;transport=ws;lr>
From: sip:bob@example.com;tag=bmqkjhsd
To: sip:alice@example.com;tag=asdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE
Max-Forwards: 70


F9 BYE  proxy.example.com -> Alice (transport WSS)

BYE sip:alice@example.com;gr=urn:uuid:f81-7dec-14a06cf1;ob SIP/2.0
Via: SIP/2.0/WSS proxy.example.com:443;branch=z9hG4bKmma01m3r5
Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001
From: sip:bob@example.com;tag=bmqkjhsd
To: sip:alice@example.com;tag=asdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE
Max-Forwards: 69


F10 200 OK  Alice -> proxy.example.com (transport WSS)

SIP/2.0 200 OK
Via: SIP/2.0/WSS proxy.example.com:443;branch=z9hG4bKmma01m3r5
Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001
From: sip:bob@example.com;tag=bmqkjhsd
To: sip:alice@example.com;tag=asdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE


F11 200 OK  proxy.example.com -> Bob (transport UDP)

SIP/2.0 200 OK
Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001
From: sip:bob@example.com;tag=bmqkjhsd
To: sip:alice@example.com;tag=asdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE

It should say:

F1 INVITE  Alice -> proxy.example.com (transport WSS)

INVITE sips:bob@example.com SIP/2.0
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
From: sips:alice@example.com;tag=asdyka899
To: sips:bob@example.com
Call-ID: asidkj3ss
CSeq: 1 INVITE
Max-Forwards: 70
Supported: path, outbound, gruu
Route: <sips:proxy.example.com:443;transport=wss;lr>
Contact: <sips:alice@example.com;gr=urn:uuid:f81-7dec-14a06cf1;ob>
Content-Type: application/sdp


F2 100 Trying  proxy.example.com -> Alice (transport WSS)

SIP/2.0 100 Trying
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
From: sips:alice@example.com;tag=asdyka899
To: sips:bob@example.com
Call-ID: asidkj3ss
CSeq: 1 INVITE


F3 INVITE  proxy.example.com -> Bob (transport TLS)

INVITE sips:bob@203.0.113.22 SIP/2.0
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bKhjhjqw32c
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
Record-Route: <sips:proxy.example.com;lr>,
 <sips:h7kjh12s@proxy.example.com:443;transport=ws;lr>
From: sip:alice@example.com;tag=asdyka899
To: sips:bob@example.com
Call-ID: asidkj3ss
CSeq: 1 INVITE
Max-Forwards: 69
Supported: path, outbound, gruu
Contact: <sips:alice@example.com
 ;gr=urn:uuid:f81-7dec-14a06cf1;ob>
Content-Type: application/sdp

F4 200 OK  Bob -> proxy.example.com (transport TLS)

SIP/2.0 200 OK
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bKhjhjqw32c
 ;received=192.0.2.10
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
Record-Route: <sips:proxy.example.com;lr>,
 <sips:h7kjh12s@proxy.example.com:443;transport=ws;lr>
From: sips:alice@example.com;tag=asdyka899
To: sips:bob@example.com;tag=bmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 INVITE
Contact: <sips:bob@203.0.113.22>
Content-Type: application/sdp


F5 200 OK  proxy.example.com -> Alice (transport WSS)

SIP/2.0 200 OK
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
Record-Route: <sips:proxy.example.com;lr>,
 <sips:h7kjh12s@proxy.example.com:443;transport=ws;lr>
From: sips:alice@example.com;tag=asdyka899
To: sips:bob@example.com;tag=bmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 INVITE
Contact: <sips:bob@203.0.113.22>
Content-Type: application/sdp


F6 ACK  Alice -> proxy.example.com (transport WSS)

ACK sips:bob@203.0.113.22 SIP/2.0
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090
Route: <sips:h7kjh12s@proxy.example.com:443;transport=ws;lr>,
 <sips:proxy.example.com;lr>,
From: sips:alice@example.com;tag=asdyka899
To: sips:bob@example.com;tag=bmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 ACK
Max-Forwards: 70

F7 ACK  proxy.example.com -> Bob (transport TLS)

ACK sips:bob@203.0.113.22 SIP/2.0
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bKhwpoc80zzx
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090
From: sips:alice@example.com;tag=asdyka899
To: sips:bob@example.com;tag=bmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 ACK
Max-Forwards: 69


F8 BYE  Bob -> proxy.example.com (transport TLS)

BYE sips:alice@example.com;gr=urn:uuid:f81-7dec-14a06cf1;ob SIP/2.0
Via: SIP/2.0/TLS 203.0.113.22;branch=z9hG4bKbiuiansd001
Route: <sips:proxy.example.com;lr>,
 <sips:h7kjh12s@proxy.example.com:443;transport=ws;lr>
From: sips:bob@example.com;tag=bmqkjhsd
To: sips:alice@example.com;tag=asdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE
Max-Forwards: 70


F9 BYE  proxy.example.com -> Alice (transport WSS)

BYE sips:alice@example.com;gr=urn:uuid:f81-7dec-14a06cf1;ob SIP/2.0
Via: SIP/2.0/WSS proxy.example.com:443;branch=z9hG4bKmma01m3r5
Via: SIP/2.0/TLS 203.0.113.22;branch=z9hG4bKbiuiansd001
From: sips:bob@example.com;tag=bmqkjhsd
To: sips:alice@example.com;tag=asdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE
Max-Forwards: 69


F10 200 OK  Alice -> proxy.example.com (transport WSS)

SIP/2.0 200 OK
Via: SIP/2.0/WSS proxy.example.com:443;branch=z9hG4bKmma01m3r5
Via: SIP/2.0/TLS 203.0.113.22;branch=z9hG4bKbiuiansd001
From: sips:bob@example.com;tag=bmqkjhsd
To: sips:alice@example.com;tag=asdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE


F11 200 OK  proxy.example.com -> Bob (transport TLS)

SIP/2.0 200 OK
Via: SIP/2.0/TLS 203.0.113.22;branch=z9hG4bKbiuiansd001
From: sips:bob@example.com;tag=bmqkjhsd
To: sips:alice@example.com;tag=asdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE

Notes:

This example states that WSS protocol is used, but Route header specifies SIP URI with transport=ws. which would mean WS (insecure Web Socket). Furthermore, if SIPS URI is used in Route header, then all other URI must be SIPS as well and message cannot be forwarded over UDP, SIPS over TLS must be used instead. I have modified the entire example to use SIPS and TLS, instead of SIP and UDP.

RFC 7155, "Diameter Network Access Server Application", April 2014

Source of RFC: dime (ops)

Errata ID: 6029
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Luke Mewburn
Date Reported: 2020-03-25

Section 4.4 says:

   QoS-Filter-Rule             4.4.9        |    |     |

It should say:

   QoS-Filter-Rule             4.4.9        | M  |  V  |

Notes:

The row "QoS-Filter-Rule" does not define AVP Flag Rules for "M" or "V":
- The V Flag MUST NOT be used for this AVP.
- There may be some debate whether the M Flag can be retrospectively added to the MUST column, versus leaving it out (implied "MAY" ?).

The changes are consistent with all other AVPs in this RFC.

RFC 7193, "The application/cms Media Type", April 2014

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 6819
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2022-01-18

Section 4 says:

   digestData                  |[RFC5652] | 1.2.840.113549.1.9.16.1.5
   encryptedData               |[RFC5652] | 1.2.840.113549.1.9.16.1.6
   envelopedData               |[RFC5652] | 1.2.840.113549.1.9.16.1.3
   signedData                  |[RFC5652] | 1.2.840.113549.1.9.16.1.2

It should say:

   digestData                  |[RFC5652] | 1.2.840.113549.1.7.5
   encryptedData               |[RFC5652] | 1.2.840.113549.1.7.6
   envelopedData               |[RFC5652] | 1.2.840.113549.1.7.3
   signedData                  |[RFC5652] | 1.2.840.113549.1.7.2

Notes:

Four of the object identifiers in the table are incorrect. The correct ones are provided above. In addition, IANA has been notified about the error.

RFC 7208, "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", April 2014

Note: This RFC has been updated by RFC 7372, RFC 8553, RFC 8616

Source of RFC: spfbis (app)

Errata ID: 4751
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ken Mortimer
Date Reported: 2016-07-27

Section 5.5 says:

This mechanism matches if

o  the <target-name> is a subdomain of a validated domain name, or

o  the <target-name> and a validated domain name are the same.

It should say:

This mechanism matches if

o  a validated domain name is a subdomain of the <target-name>, or

o  the <target-name> and a validated domain name are the same.

Notes:

The first bullet point is in contradiction to the description of the ptr mechanism evaluation in the preceding paragraph:
"Check all validated domain names to see if they either match the <target-name> domain or are a subdomain of the <target-name> domain. If any do, this mechanism matches. If no validated domain name can be found, or if none of the validated domain names match or are a subdomain of the <target-name>, this mechanism fails to match."

Errata ID: 5227
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: David Garfield
Date Reported: 2018-01-04

Section 5.5 says:

   The <ip>'s name is looked up using this procedure:

   o  Perform a DNS reverse-mapping for <ip>: Look up the corresponding
      PTR record in "in-addr.arpa." if the address is an IPv4 address
      and in "ip6.arpa." if it is an IPv6 address.

   o  For each record returned, validate the domain name by looking up
      its IP addresses.  To prevent DoS attacks, the PTR processing
      limits defined in Section 4.6.4 MUST be applied.  If they are
      exceeded, processing is terminated and the mechanism does not
      match.

   o  If <ip> is among the returned IP addresses, then that domain name
      is validated.

   Check all validated domain names to see if they either match the
   <target-name> domain or are a subdomain of the <target-name> domain.
   If any do, this mechanism matches.  If no validated domain name can
   be found, or if none of the validated domain names match or are a
   subdomain of the <target-name>, this mechanism fails to match.  If a
   DNS error occurs while doing the PTR RR lookup, then this mechanism
   fails to match.  If a DNS error occurs while doing an A RR lookup,
   then that domain name is skipped and the search continues.

   This mechanism matches if

   o  the <target-name> is a subdomain of a validated domain name, or

   o  the <target-name> and a validated domain name are the same.

   For example, "mail.example.com" is within the domain "example.com",
   but "mail.bad-example.com" is not.

It should say:

   The <ip>'s name is looked up using this procedure:

   o  Perform a DNS reverse-mapping for <ip>: Look up the corresponding
      PTR record in "in-addr.arpa." if the address is an IPv4 address
      and in "ip6.arpa." if it is an IPv6 address.

   Check all domain names to see if they either match the
   <target-name> domain or are a subdomain of the <target-name>
   domain.  If any do, this domain name can be validated.  If no
   domain name can be found, or if none of the domain names match or
   are a subdomain of the <target-name>, this mechanism fails to
   match.  If a DNS error occurs while doing the PTR RR lookup, then
   this mechanism fails to match.

   This mechanism may match if

   o  the <target-name> is a subdomain of a domain name, or

   o  the <target-name> and a domain name are the same.

   For example, "mail.example.com" is within the domain "example.com",
   but "mail.bad-example.com" is not.


   The domain names received must also be validated for the mechanism
   to match.

   o For each matched record, validate the domain name by looking up
      its IP addresses.  To prevent DoS attacks, the PTR processing
      limits defined in Section 4.6.4 MUST be applied.  If they are
      exceeded, processing is terminated and the mechanism does not
      match.

   o  If <ip> is among the returned IP addresses, then that domain name
      is validated.

   If a DNS error occurs while doing an A RR lookup, then that domain
   name is skipped and the search continues.


   The mechanism matches if a domain name is found that properly
   matches the target name and can be properly validated.  While these
   tests can be done in either order, performing the match before
   validating prevents needless DNS queries being performed.

Notes:

As specified, the RFC calls for all names to be validated, even those that can be immediately discarded because they do not match. The RFC should call for the local-only operation to be done first. While it may be argued that the RFC doesn't require the order, implementers shouldn't be misled.

My corrected text probably needs editorial work.

I have not fixed errata 4751 in my corrected text.

Errata ID: 5228
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: David Garfield
Date Reported: 2018-01-04

Section 5.5 says:

   Note: This mechanism is slow, it is not as reliable as other
   mechanisms in cases of DNS errors, and it places a large burden on
   the .arpa name servers.  If used, proper PTR records have to be in
   place for the domain's hosts and the "ptr" mechanism SHOULD be one of
   the last mechanisms checked.  After many years of SPF deployment
   experience, it has been concluded that it is unnecessary and more
   reliable alternatives should be used instead.  It is, however, still
   in use as part of the SPF protocol, so compliant check_host()
   implementations MUST support it.

It should say:

   Note: This mechanism is not as reliable as other
   mechanisms in cases of DNS errors.
   If used, proper PTR records have to be in
   place for the domain's hosts and the "ptr" mechanism SHOULD be one of
   the last mechanisms checked.  After many years of SPF deployment
   experience, it has been concluded that it is unnecessary and more
   reliable alternatives should be used instead.  It is, however, still
   in use as part of the SPF protocol, so compliant check_host()
   implementations MUST support it.

Notes:

I have not reflowed the text so it can be more clear what I changed.

This mechanism is slow

In fact, if all the DNS records are in place, Errata 5227 is accounted
for, and the single PTR query is discounted, this mechanism produces
no more additional DNS queries than mechanism "a". I.e. it produces
one A (or AAAA) query. It is not slow.

it places a large burden on the .arpa name servers

In fact, it requires 1 PTR query, for however many ptr mechanisms are
in the SPF record. Further, most mail servers already do this PTR
query, to report the information on the "Received" line. Even if a
seperate daemon is used to the SPF check, the data should already be
in a local caching name server.

Errata ID: 5550
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Borislav Petrov
Date Reported: 2018-11-09

Section 2.3. says:

   Note that requirements for the domain presented in the EHLO or HELO
   command are not always clear to the sending party, and SPF verifiers
   have to be prepared for the identity to be an IP address literal (see
   [RFC5321], Section 4.1.3) or simply be malformed.  This SPF check can
   only be performed when the "HELO" string is a valid, multi-label
   domain name.

Notes:

It looks like that those who have HELO <IP Address> or <malformed> will have result "none" (and pass) but those that have HELO <hostname> and have not yet published their hostname (A record) as allowed sender will get fail. This becomes a very common case for all messages which are DSNs. The whole idea that it is better to have your HELO malformed than a valid hostname which identifies the system is wrong. The point is to fight spam but you actually make it easier for spammers to just have the EHLO malformed and send with <> reverse-path rather than having some proper EHLO/HELO which is subject to other verifications like rDNS, etc.

Errata ID: 5843
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Jesus Donaldo Osornio
Date Reported: 2019-08-22

Section 9.1 says:

Received-SPF: pass (mybox.example.org: domain of
    myname@example.com designates 192.0.2.1 as permitted sender)
       receiver=mybox.example.org; client-ip=192.0.2.1;
       mechanism=ip4:192.0.2.1; envelope-from="myname@example.com";
       helo=foo.example.com;

It should say:

Received-SPF: pass (mybox.example.org: domain of
    myname@example.com designates 192.0.2.1 as permitted sender)
       receiver=mybox.example.org; client-ip=192.0.2.1;
       mechanism="ip4:192.0.2.1"; envelope-from="myname@example.com";
       helo=foo.example.com;

Notes:

There's an error in the last example of this section:
By the definition of key-value-pair, a "value" can only be a dot-atom or a quoted-string.
The string ip4:192.0.2.1 in the mechanism key is not a legal dot-atom, so it should be surrounded by double quotes, to be a quoted-string instead

Errata ID: 6216
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: David Bürgin
Date Reported: 2020-06-26

Section A.4 says:

ptr._spf.example.com.  SPF  "v=spf1 -ptr +all"

It should say:

ptr._spf.example.com.  TXT  "v=spf1 -ptr:example.com +all"

Notes:

The example in appendix A.4, 'Multiple Requirements Example', does not
work as intended.

In the example, the SPF record at ptr._spf.example.com contains the
directive '-ptr'.

When this directive is evaluated, the <target-name> is equal to
'ptr._spf.example.com'. An input <ip> such as 192.0.2.10, which has a
PTR record pointing to 'example.com', will fail to match, as that domain
is not equal to nor a subdomain of 'ptr._spf.example.com'. In other
words, given the DNS setup of appendix A, there are no inputs that
fulfil the requirement for matching this ptr mechanism.

The example can be fixed by supplying an appropriate <domain-spec>:
replace '-ptr' with '-ptr:example.com'.

Errata ID: 6595
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Benjamin Schwarze
Date Reported: 2021-06-03

Section 4.6.4 says:

As described at the end of Section 11.1, there may be cases where it
is useful to limit the number of "terms" for which DNS queries return
either a positive answer (RCODE 0) with an answer count of 0, or a
"Name Error" (RCODE 3) answer.  These are sometimes collectively
referred to as "void lookups".  SPF implementations SHOULD limit
"void lookups" to two.  An implementation MAY choose to make such a
limit configurable.  In this case, a default of two is RECOMMENDED.
Exceeding the limit produces a "permerror" result.

It should say:

-- Addition to the original paragraph --

ADMDs should be aware that the void lookup limit can easily be exceeded by using sender-specific macros ("s", "l", "o", "i", "h") in more than 2 terms.

The following example will lead to an permerror in the most implementations if the <ip> is not found in any of the lists:
  v=spf1 exists:%{ir}.list1.example.net exists:%{ir}.list2.example.net exists:%{ir}.list3.example.net -all

Notes:

In addition to the above suggestion, I still see a contradiction between the "void lookup limit" and the "exists" mechanism. The functionality of "exists" includes (in my opinion) the negative response (RCODE 3). But the "void lookup limit" allows this to occur only twice. This limits the use of "exists" very much.

Admittedly: I have no good idea how to solve this. :-)

Errata ID: 4841
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alessandro Vesely
Date Reported: 2016-10-25

Section 3.5. says:

      EXAMPLE.COM.          MX      10      A.EXAMPLE.COM
      *.EXAMPLE.COM.        MX      10      A.EXAMPLE.COM
      A.EXAMPLE.COM.        MX      10      A.EXAMPLE.COM
      *.A.EXAMPLE.COM.      MX      10      A.EXAMPLE.COM

It should say:

      EXAMPLE.COM.          MX      10      A.EXAMPLE.COM.
      *.EXAMPLE.COM.        MX      10      A.EXAMPLE.COM.
      A.EXAMPLE.COM.        MX      10      A.EXAMPLE.COM.
      *.A.EXAMPLE.COM.      MX      10      A.EXAMPLE.COM.

Notes:

This is an editorial errata, since it is a punctuation error.

It is not technical, because the example might have implied an $ORIGIN of "." or some other strange setting, while a normative reference --rfc 1035-- makes it very clear that "[d]omain names that end in a dot are called absolute, and are taken as complete." Hence no technical meaning is affected.

Errata ID: 6433
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kaspar Etter
Date Reported: 2021-02-17

Section 3 says:

   Each SPF record is placed in the DNS tree at the owner name it
   pertains to, not in a subdomain under the owner name.  This is
   similar to how SRV records [RFC2782] are done.

It should say:

   Each SPF record is placed in the DNS tree at the owner name it
   pertains to, not in a subdomain under the owner name.  This is
   different from how SRV records [RFC2782] are done.

Notes:

SRV records are placed at specific subdomains, which is not the case for SPF records. (I've chosen Editorial instead of Technical because the meaning of this paragraph should be clear from the context and thus this feels more like a typo.)

RFC 7239, "Forwarded HTTP Extension", June 2014

Source of RFC: appsawg (app)

Errata ID: 5067
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Vasiliy Faronov
Date Reported: 2017-07-12

Throughout the document, when it says:

proxy

It should say:

message-forwarding agent

Notes:

According to RFC 7230 Section 2.3, an HTTP "proxy" is a message-forwarding agent that is selected by the client. But this specification (as is clear from Section 1) uses the word "proxy" to refer also to message-forwarding agents that are *not* selected by the client.

Errata ID: 5275
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: W. Trevor King
Date Reported: 2018-03-06

Section 4 says:

Forwarded   = 1#forwarded-element

It should say:

Forwarded   = forwarded-element *(OWS "," OWS forwarded-element)
OWS = <Defined in [RFC7230], Section 3.2.3>

Notes:

Currently the only mention of commas in the RFC is in the text:

> A proxy server that wants to add a new "Forwarded" header field value can either append it to the last existing "Forwarded" header field after a comma separator or add a new field at the end of the header block.

This should be reflected in the ABNF. The original ABNF suggests you just smash the forwarded-elements together with no delimiters.

RFC 7240, "Prefer Header for HTTP", June 2014

Note: This RFC has been updated by RFC 8144

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 4625
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Vasiliy Faronov
Date Reported: 2016-02-24

Section 3 says:

     applied-pref = token [ BWS "=" BWS word ]

It should say:

     applied-pref = preference-parameter
                    ; see Errata ID: 4439

Notes:

This updates the syntax of the Preference-Applied header field in accordance with a previous erratum to this document, which fixed the Prefer header field.

Errata ID: 4955
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Vasiliy Faronov
Date Reported: 2017-03-01

Section 2.1 says:

     Prefer: Lenient

It should say:

     Prefer: Handling="lenient"

Notes:

"Prefer: Lenient" is a valid header that specifies an (unregistered) preference named "lenient" with an empty value.

On the other hand, this document defines a preference named "handling", which can take the value "lenient" to indicate lenient processing, which is the stated intent of this example.

There is no provision for specifying a preference by its *value*, as opposed to by its *name*.

Errata ID: 5282
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Sawood Alam
Date Reported: 2018-03-07

Section 1.1 says:

   This specification uses the Augmented Backus-Naur Form (ABNF)
   notation of [RFC5234] and includes, by reference, the "token",
   "word", "OWS", and "BWS" rules and the #rule extension as defined
   within Sections 3.2.1 and 3.2.4 of [RFC7230]; as well as the
   "delta-seconds" rule defined in Section 8.1.3 of [RFC7231]

It should say:

   This specification uses the Augmented Backus-Naur Form (ABNF)
   notation of [RFC5234] and includes rules, by reference, the "token"
   as defined in Sections 3.2.6 of [RFC7230], "OWS" and "BWS" as defined
   in Sections 3.2.3 of [RFC7230], and the #rule extension as defined in
   Sections 7 of [RFC7230]; as well as the "delta-seconds" rule defined
   in Section 8.1.3 of [RFC7231].

Notes:

Mapping of the keywords with the section numbers is incorrect. The correct mapping is as following:
"token" => Section 3.2.6 of RFC7320;
"word" => Not defined in RFC7320, but reported at Errata ID: 4439;
"OWS" and "BWS" => Section 3.2.3 of RFC7320;
"the #rule extension" => Section 7 of RFC7320;

RFC 7250, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", June 2014

Source of RFC: tls (sec)

Errata ID: 5013
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: i
Date Reported: 2017-05-10
Edited by: Roman Danyliw
Date Edited: 2024-03-18

Section 7 says:

   IANA has allocated two new TLS extensions, client_certificate_type
   and server_certificate_type, from the "TLS ExtensionType Values"
   subregistry defined in [RFC5246].

It should say:

   IANA has allocated two new code points, 19 (0x13) and 20 (0x14), for
   client_certificate_type and server_certificate_type, respectively,
   in the "TLS ExtensionType Values" subregistry defined in [RFC5246].

RFC 7254, "A Uniform Resource Name Namespace for the Global System for Mobile Communications Association (GSMA) and the International Mobile station Equipment Identity (IMEI)", May 2014

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rai

Errata ID: 5303
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Dale R. Worley
Date Reported: 2018-03-26

Section 3 says:

         gsma-urn-char         = ALPHA / DIGIT
                                 / "-" / "." / "_" / "%" / ":"

It should say:

         gsma-urn-char         = ALPHA / DIGIT
                                 / "-" / "." / "_" / pct-encoded / ":"

Notes:

As written, the RFC allows the URN to contain a "%" without consideration of the following characters, which is contrary to the syntax of URNs. Where the grammar shows "%", it really wants "pct-encoded". Though you'll probably have to update the references to provide the definition of pct-encoded -- that seems to have been introduced in RFC 3986.

RFC 7265, "jCal: The JSON Format for iCalendar", May 2014

Note: This RFC has been updated by RFC 7529

Source of RFC: jcardcal (app)

Errata ID: 6360
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Julian Cowley
Date Reported: 2020-12-20

Throughout the document, when it says:

Notes:

In RFC 5545, one of the allowable values for the VERSION property is a minimum version and a maximum version, separated by a semicolon (;). The value type is TEXT. When the jCal value is converted back to iCalendar, the text is subject to escape with a backslash. This yields a result which is not valid for the VERSION property.

Example:

[ "version", {}, "text", "2.0;2.9" ]

becomes

VERSION:2.0\;2.9

which is invalid because it contains the backslash.

Errata ID: 4862
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sean Bartell
Date Reported: 2016-11-10

Section 3.6.1 says:

   Example:

   ["attach", {}, "binary", "SGVsbG8gV29ybGQh"]

It should say:

   Example:

   ["attach", {"encoding": "BASE64"}, "binary", "SGVsbG8gV29ybGQh"]

Notes:

The ENCODING=BASE64 parameter must be preserved for BINARY values; no part of the RFC allows removing it.

RFC 7270, "Cisco-Specific Information Elements Reused in IP Flow Information Export (IPFIX)", June 2014

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 7775
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2024-01-23

Section 4.12 says:

Abstract Data Type:  unsigned32

It should say:

Abstract Data Type:  unsigned8

Notes:

Section 4.12 describes an 8-bit forwardingStatus field, and xrefs CCO-NF9FMT where FORWARDING STATUS has a length of 1 (ie, 8 bits).

IANA's IPFIX registry lists the Abstract Data Type for forwardingStatus as "unsigned8".

The "unsigned32" Abstract Data Type is out of sync with these other documents.

RFC 7292, "PKCS #12: Personal Information Exchange Syntax v1.1", July 2014

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 4832
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jim Wigginton
Date Reported: 2016-10-15

Section B.4 says:

pbeWithSHAAnd128BitRC4           OBJECT IDENTIFIER ::= {pkcs-12PbeIds 1}
pbeWithSHAAnd40BitRC4            OBJECT IDENTIFIER ::= {pkcs-12PbeIds 2}
pbeWithSHAAnd3-KeyTripleDES-CBC  OBJECT IDENTIFIER ::= {pkcs-12PbeIds 3}
pbeWithSHAAnd2-KeyTripleDES-CBC  OBJECT IDENTIFIER ::= {pkcs-12PbeIds 4}
pbeWithSHAAnd128BitRC2-CBC       OBJECT IDENTIFIER ::= {pkcs-12PbeIds 5}
pbewithSHAAnd40BitRC2-CBC        OBJECT IDENTIFIER ::= {pkcs-12PbeIds 6}

It should say:

pbeWithSHAAnd128BitRC4           OBJECT IDENTIFIER ::= {pkcs-12PbeIds 1}
pbeWithSHAAnd40BitRC4            OBJECT IDENTIFIER ::= {pkcs-12PbeIds 2}
pbeWithSHAAnd3-KeyTripleDES-CBC  OBJECT IDENTIFIER ::= {pkcs-12PbeIds 3}
pbeWithSHAAnd2-KeyTripleDES-CBC  OBJECT IDENTIFIER ::= {pkcs-12PbeIds 4}
pbeWithSHAAnd128BitRC2-CBC       OBJECT IDENTIFIER ::= {pkcs-12PbeIds 5}
pbeWithSHAAnd40BitRC2-CBC        OBJECT IDENTIFIER ::= {pkcs-12PbeIds 6}

Notes:

All the other OID names have a camelcase With. The last one, however (pbewithSHAAnd40BitRC2-CBC), has a lowercase with.

RFC 7303, "XML Media Types", July 2014

Source of RFC: appsawg (app)

Errata ID: 4578
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin Dürst
Date Reported: 2016-01-05

Section 4.2 says:

In addition to the changes described above, the change controller has
been changed to be the World Wide Web Consortium (W3C).

It should say:

In addition to the changes described above, the change controller for
the '+xml' Structured Syntax Suffix has been changed to be the World
Wide Web Consortium (W3C).

Notes:

At https://mailarchive.ietf.org/arch/msg/lager/hRVFkda9GKFTYeBcmK2Ge9OdvoA, the sentence was misread to apply to all registrations with a +xml suffix, rather than only to the registration of the suffix itself.

RFC 7315, "Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3GPP", July 2014

Note: This RFC has been updated by RFC 7913, RFC 7976

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: art

Errata ID: 4474
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Christer Holmberg
Date Reported: 2015-09-14

Section 5.4 says:

extension-access-info  = gen-value

It should say:

extension-access-info  = generic-param

Notes:

Most of the pre-defined access-info values are following the generic-param syntax. New access-info values (extensions) should also be allowed to follow the generic-param syntax, in order to allow both for a name and value of the extension.

Errata ID: 4540
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Dongo Yi
Date Reported: 2015-11-20

Section 5.1 says:

5.1. P-Associated-URI Header Syntax


   The syntax of the P-Associated-URI header field is described as
   follows:

         P-Associated-URI       = "P-Associated-URI" HCOLON
                                  [p-aso-uri-spec]
                                  *(COMMA p-aso-uri-spec)
         p-aso-uri-spec         = name-addr *(SEMI ai-param)
         ai-param               = generic-param

It should say:

5.1. P-Associated-URI Header Syntax


   The syntax of the P-Associated-URI header field is described as
   follows:

         P-Associated-URI       = "P-Associated-URI" HCOLON
                                  (p-aso-uri-spec)
                                  *(COMMA p-aso-uri-spec)
         p-aso-uri-spec         = name-addr *(SEMI ai-param)
         ai-param               = generic-param

Notes:

P-Associated-URI cannot include an empty header value (which was able to be included according to RFC 3455)

- Background.

The policy of P-Associated-URI has been updated from RFC 3455.
RFC 3455 : 4.1.2.2 Procedures at the registrar
...
In case the address-of-record under registration does not have any
other SIP or SIPS URIs associated, the registrar MUST include an
empty P-Associated-URI header value.


RFC 7315 : 4.1.2.2 Procedures at the Registrar
...
If the address-of-record under registration does not have any
associated URIs, the P-Associated-URI header field SHALL NOT be
included.
...

Moreover, we can say RFC 3455 has same errata based on this analysis.

Errata ID: 4447
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Roland Jesske
Date Reported: 2015-08-17

Section 4.6.3.1. says:

	4.6.3.1. Procedures at the Proxy
	
	
	Procedures described within 4.5.2.2 apply. A transit-ioi MAY be
	added or modified by a proxy. A deletion of the transit-ioi or a
	entry within the tranist-ioi could appear depending on the network
	
	policy and trust rules. This is also valid by replacing the transit-
	ioi with a void value.

It should say:

4.6.3.1. Procedures at the Proxy


Procedures described within Section 4.6.2.2 apply. A transit-ioi MAY
be added or modified by a proxy. A deletion of the transit-ioi or a
entry within the tranist-ioi could appear depending on the network

policy and trust rules. This is also valid by replacing the
transit-ioi with a void value.

Notes:

Problem is that the Reader is lead to the wrong procedures.

Errata ID: 4448
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Roland Jesske
Date Reported: 2015-08-17

Section 4.6.4.2. says:

4.6.4.2.  Procedures at the Proxy

   Procedures described within Section 4.5.2.2 apply.  A related-icid
   and "related-icid-generated-at" MAY be added or modified by a proxy.
   A deletion of the elements could appear depending on the network
   policy and trust rules.

It should say:

4.6.4.2.  Procedures at the Proxy

   Procedures described within Section 4.6.2.2 apply.  A related-icid
   and "related-icid-generated-at" MAY be added or modified by a proxy.
   A deletion of the elements could appear depending on the network
   policy and trust rules.

Notes:

This pointer to a wrong section may lead to a wrong implementation

RFC 7405, "Case-Sensitive String Support in ABNF", December 2014

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: art

Errata ID: 5334
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: YU HengChun
Date Reported: 2018-04-25

Section 2.2 says:

2.2.  ABNF Definition of ABNF - char-val

         char-val       =  case-insensitive-string /
                           case-sensitive-string

         case-insensitive-string =
                           [ "%i" ] quoted-string

         case-sensitive-string =
                           "%s" quoted-string

         quoted-string  =  DQUOTE *(%x20-21 / %x23-7E) DQUOTE
                                ; quoted string of SP and VCHAR
                                ;  without DQUOTE

It should say:

2.2.  ABNF Definition of ABNF - char-val

         char-val       =  case-insensitive-string /
                           case-sensitive-string

         case-insensitive-string =
                                DQUOTE *(%x20-21 / %x23-7E) DQUOTE
                                ; quoted string of SP and VCHAR
                                ;  without DQUOTE

         case-sensitive-string  =
                                QUOTE *(%x20-26 / %x28-7E) QUOTE
                                ; quoted string of SP and VCHAR
                                ;  without QUOTE

         QUOTE       = %x27     ; '

Notes:

Use "%s' / '%i' hard to write. In addition to writing more characters, there are the following problems:

rule = (%s"if" / %s"elif") condition (%s"then" / LF)

Why not use single quotes directly?

rule = ('if' / 'elif') condition ('then' / LF)

Even if single quotation marks cannot be used, the workaround can be complicated:

rule = %s( "if" / "elif" ) condition (%s"then" / LF)

RFC 7457, "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)", February 2015

Source of RFC: uta (sec)

Errata ID: 4592
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Matthäus Wander
Date Reported: 2016-01-10

Section 2.6 says:

The TIME attack can be mitigated by disabling TLS compression.  We
are not aware of mitigations at the TLS protocol level to the BREACH
attack, and so application-level mitigations are needed (see
[BREACH]).

It should say:

The CRIME attack can be mitigated by disabling TLS compression.  We
are not aware of mitigations at the TLS protocol level to the TIME and
BREACH attacks, and so application-level mitigations are needed (see
[BREACH]).

Notes:

As explained in the second paragraph in 2.6, the TIME attack makes use of HTTP-level response compression (in fact, it does not matter on which layer the compression occurs, but exploitation of HTTP-level response compression has been demonstrated). Hence, it cannot be mitigated by disabling TLS compression alone.

Instead, CRIME can be mitigated by disabling TLS compression, as it exploits TLS-level compression of requests.

Errata ID: 4894
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2016-12-22

Section 2.2 says:

   STARTTLS and similar mechanisms are vulnerable to downgrade attacks,
   whereby the attacker simply removes the STARTTLS indication from the
   (unprotected) request.  This cannot be mitigated unless HSTS-like
   solutions are added.

Notes:

The second paragraph in Section 2.2 ("STARTTLS Command Injection Attack") should have been in Section 2.1 ("SSL Stripping") because it concerns the attack known as "SSL Stripping".

Note that Section 3.2 of RFC 7525 refers to Section 2.1 (and not 2.2) of this RFC, when speaking about lack of advertise support for TLS.

RFC 7464, "JavaScript Object Notation (JSON) Text Sequences", February 2015

Source of RFC: json (app)

Errata ID: 5998
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Claes Wallin
Date Reported: 2020-03-01

Section 2.3 says:

in contexts where, for example, data that is appended to log files to log files is truncated by the filesystem

It should say:

in contexts where, for example, data that is appended to log files is truncated by the filesystem

Notes:

the text "to log files" is accidentally duplicated within the sentence

RFC 7468, "Textual Encodings of PKIX, PKCS, and CMS Structures", April 2015

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 7697
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Stefan Brüns
Date Reported: 2023-11-10

Section 5.3 says:

   This section does not disturb the official application/pkix-cert
   registration [RFC2585] in any way (which states that "each '.cer'
   file contains exactly one certificate, encoded in DER format"), but
   merely articulates a widespread, de facto alternative.

It should say:

   This section does not disturb the official application/pkix-cert
   registration [RFC2585] in any way (which states that "each '.cer'
   file contains exactly one certificate, encoded in DER format").
   
   PEM encoded certificates should use the application/pkix-cert+pem
   IANA registration. This distinguishes it from plain DER encoded data
   and also denotes it uses an encoding following syntax and semantics
   of the application/pem media type.  

Notes:

The current statement allows two possible interpretations:

1. As PEM wraps DER format, a PEM encoded certificate is also DER encoded. Thus application/pkix-cert is the correct media type also for PEM encoded certificates.

2. "Exactly one certificate in DER format" precludes any additional encoding, e.g. PEM. Thus application/pkix-cert is not valid for PEM encoded certificates.

In case 2 is the correct interpretation, a distinct media type for PEM encoded data should be registered with IANA. This media type should be used as a structured syntax type for all PEM wrapped key and certificate types. E.g.:

- application/pem
- application/pkix-cert+pem
- application/x-x509-ca-cert+pem

The latter two would be an amendment to RFC 2585 and and RFC 8894 respectively.

The "+pem" suffix used conforms to RFC 6838 "structured syntax".

OpenPGP ascii armor (RFC 4880) and SSH public key (RFC 4716) are *not* subtypes of PEM.

RFC 7469, "Public Key Pinning Extension for HTTP", April 2015

Source of RFC: websec (app)

Errata ID: 5377
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2018-06-02

Section 2.3.4 says:

2.3.4.  HTTP-Equiv <Meta> Element Attribute

   UAs MUST NOT heed http-equiv="Public-Key-Pins" or
   http-equiv="Public-Key-Pins-Report-Only" attribute settings on <meta>
   elements [W3C.REC-html401-19991224] in received content.

It should say:

(remove the section)

Notes:

The spec attempts to make a normative requirement on HTML consumers. It can't do that; that's the role of the HTML spec.

In addition to that, this is already covered by what recent HTML specs say about http-equiv extensibility.

RFC 7483, "JSON Responses for the Registration Data Access Protocol (RDAP)", March 2015

Note: This RFC has been obsoleted by RFC 9083

Source of RFC: weirds (app)

Errata ID: 4980
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Scott Hollenbeck
Date Reported: 2017-03-24

Section 5.5 says:

country -- a string containing the name of the two-character
country code of the autnum

It should say:

country -- a string containing the two-character country
code of the autnum

Notes:

As described in Section 3, country codes should consistently be represented as two-character string values. Note that this differs from the "full name" format used in jCard representations of entity objects.

Errata ID: 5667
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Andrew Newton
Date Reported: 2019-03-22

Section 4.8 says:

identifier -- a public identifier of the type denoted by "type"

It should say:

identifier -- a string denoting a public identifier of the type 
              related to "type"

Notes:

While the example given in section 4.8 shows "identifier" being a string, the prose description does not clearly state it.

Errata ID: 6158
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Scott Hollenbeck
Date Reported: 2020-05-06

Section 10.2.3 says:

Description: The object instance was transferred from one registrant to another.

It should say:

Description: The object instance was transferred from one registrar to another.

Notes:

I believe the corrected text is what was intended for this particular registry value, and is what is being implemented by operators today. Registrant-to-registrant transfers are also possible, but they're not performed using EPP and are not logged as an event action. The text in the RFC should be changed and the description of the action in the IANA registry should also be changed.

Errata ID: 4859
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marcos Sanz
Date Reported: 2016-11-10

Section 5.3 says:

"network" :
     {
       "objectClassName" : "ip network",
       "handle" : "XXXX-RIR",
       "startAddress" : "192.0.2.0",
       "endAddress" : "192.0.2.255",
       "ipVersion" : "v6",

It should say:

"network" :
     {
       "objectClassName" : "ip network",
       "handle" : "XXXX-RIR",
       "startAddress" : "192.0.2.0",
       "endAddress" : "192.0.2.255",
       "ipVersion" : "v4",

Errata ID: 5666
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Andrew Newton
Date Reported: 2019-03-22

Section 3 says:

handle:           DNRs and RIRs have registry-unique identifiers that
                     may be used to specifically reference an object
                     instance.  The semantics of this data type as found
                     in this document are to be a registry-unique
                     reference to the closest enclosing object where the
                     value is found.  The data type names "registryId",
                     "roid", "nic-handle", "registrationNo", etc., are
                     terms often synonymous with this data type.  In
                     this document, the term "handle" is used.  The term
                     exposed to users by clients is a presentation issue
                     beyond the scope of this document.

It should say:

handle:           DNRs and RIRs have registry-unique identifiers that
                     may be used to specifically reference an object
                     instance.  The semantics of this data type as found
                     in this document are to be a registry-unique
                     reference to the closest enclosing object where the
                     value is found.  The data type names "registryId",
                     "roid", "nic-handle", "registrationNo", etc., are
                     terms often synonymous with this data type.  In
                     this document, the term "handle" is used.  The term
                     exposed to users by clients is a presentation issue
                     beyond the scope of this document. This value is a 
                     simple string.

Notes:

All uses of handle in section 5 call "handle" out as being a string, but if a reader were to only read section 3 they would not know it.

RFC 7489, "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", March 2015

Note: This RFC has been updated by RFC 8553, RFC 8616

Source of RFC: INDEPENDENT

Errata ID: 5220
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Steven Hilton
Date Reported: 2017-12-31
Edited by: Adrian Farrel
Date Edited: 2021-06-01

Section A.6. says:

A.6.  Organizational Domain Discovery Issues

   Although protocols like ADSP are useful for "protecting" a specific
   domain name, they are not helpful at protecting subdomains.  If one
   wished to protect "example.com" by requiring via ADSP that all mail
   bearing an RFC5322.From domain of "example.com" be signed, this would
   "protect" that domain; however, one could then craft an email whose
   RFC5322.From domain is "security.example.com", and ADSP would not
   provide any protection.  One could use a DNS wildcard, but this can
   undesirably interfere with other DNS activity; one could add ADSP
   records as fraudulent domains are discovered, but this solution does
   not scale and is a purely reactive measure against abuse.

   The DNS does not provide a method by which the "domain of record", or
   the domain that was actually registered with a domain registrar, can
   be determined given an arbitrary domain name.  Suggestions have been
   made that attempt to glean such information from SOA or NS resource
   records, but these too are not fully reliable, as the partitioning of
   the DNS is not always done at administrative boundaries.

   When seeking domain-specific policy based on an arbitrary domain
   name, one could "climb the tree", dropping labels off the left end of
   the name until the root is reached or a policy is discovered, but
   then one could craft a name that has a large number of nonsense
   labels; this would cause a Mail Receiver to attempt a large number of
   queries in search of a policy record.  Sending many such messages
   constitutes an amplified denial-of-service attack.

   The Organizational Domain mechanism is a necessary component to the
   goals of DMARC.  The method described in Section 3.2 is far from
   perfect but serves this purpose reasonably well without adding undue
   burden or semantics to the DNS.  If a method is created to do so that
   is more reliable and secure than the use of a public suffix list,
   DMARC should be amended to use that method as soon as it is generally
   available.

It should say:

A.6.  Organizational Domain Discovery Issues

   Although protocols like ADSP are useful for "protecting" a specific
   domain name, they are not helpful at protecting subdomains.  If one
   wished to protect "example.com" by requiring via ADSP that all mail
   bearing an RFC5322.From domain of "example.com" be signed, this would
   "protect" that domain; however, one could then craft an email whose
   RFC5322.From domain is "security.example.com", and ADSP would not
   provide any protection.  One could use a DNS wildcard, but this can
   undesirably interfere with other DNS activity; one could add ADSP
   records as fraudulent domains are discovered, but this solution does
   not scale and is a purely reactive measure against abuse.

   The DNS does not provide a method by which the "domain of record", or
   the domain that was actually registered with a domain registrar, can
   be determined given an arbitrary domain name.  Suggestions have been
   made that attempt to glean such information from SOA or NS resource
   records, but these too are not fully reliable, as the partitioning of
   the DNS is not always done at administrative boundaries.

   When seeking domain-specific policy based on an arbitrary domain
   name, one could "climb the tree", dropping labels off the left end of
   the name until the root is reached or a policy is discovered, but
   then one could craft a name that has a large number of nonsense
   labels; this would cause a Mail Receiver to attempt a large number of
   queries in search of a policy record.  Sending many such messages
   constitutes an amplified denial-of-service attack.

   Certain TLDs could be classified as a Organizational Domains. The 
   benefits to those organizations do not yet justify the necessary 
   modifications to this document. An few organizations may 
   prefer the simplified reporting and DNS configuration of a 
   TLD Organizational Domain. This would require modifications to 
   this document and DMARC receivers for a capability that may not even
   be desired by those organizations that strictly control a TLD.

   The Organizational Domain mechanism is a necessary component to the
   goals of DMARC.  The method described in Section 3.2 is far from
   perfect but serves this purpose reasonably well without adding undue
   burden or semantics to the DNS.  If a method is created to do so that
   is more reliable and secure than the use of a public suffix list,
   DMARC should be amended to use that method as soon as it is generally
   available.

Notes:

RFC7489 does not address Organizational Top Level Domains. There are advantages and disadvantages to using a strictly controlled TLD as an Organizational Domain.

Advantages:
Simplified reporting for nonexistent domains
Simplified external reporting to another email address with the same TLD
Reduced need for multiple wildcard TXT records

Disadvantages:
Decreased flexibility for subdomains
A "_dmarc.tld" record is not be a dotless domain, but may not be recommended
Significant changes to current DMARC processing systems
New requirement to manage which TLDs are eligible to be Organizational Domains
Organizations with a strictly controlled TLD may not desire this change

Errata ID: 5221
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Steven Hilton
Date Reported: 2017-12-31
Edited by: Adrian Farrel
Date Edited: 2021-06-01

Section Appendix C. says:

       <xs:pattern value="((1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5]).){3}
                   (1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])|
                   ([A-Fa-f0-9]{1,4}:){7}[A-Fa-f0-9]{1,4}"/>

It should say:

       <xs:pattern value="^((1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5]).){3}
                   (1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])$|
                   ^(([0-9A-Fa-f]{1,4}:){7}[A-Fa-f0-9]{1,4})$|
                   ^(([0-9A-Fa-f]{1,4}:){1,1}(:[0-9A-Fa-f]{1,4}){1,6})$|
                   ^(([0-9A-Fa-f]{1,4}:){1,2}(:[0-9A-Fa-f]{1,4}){1,5})$|
                   ^(([0-9A-Fa-f]{1,4}:){1,3}(:[0-9A-Fa-f]{1,4}){1,4})$|
                   ^(([0-9A-Fa-f]{1,4}:){1,4}(:[0-9A-Fa-f]{1,4}){1,3})$|
                   ^(([0-9A-Fa-f]{1,4}:){1,5}(:[0-9A-Fa-f]{1,4}){1,2})$|
                   ^(([0-9A-Fa-f]{1,4}:){1,6}(:[0-9A-Fa-f]{1,4}){1,1})$|
                   ^((([0-9A-Fa-f]{1,4}:){1,7}|:):)$|
                   ^(:(:[0-9A-Fa-f]{1,4}){1,7})$|
                   ^(((([0-9A-Fa-f]{1,4}:){6})
                     (25[0-5]|2[0-4]\d|[0-1]?\d?\d)
                     (\.(25[0-5]|2[0-4]\d|[0-1]?\d?\d)){3}))$|
                   ^((([0-9A-Fa-f]{1,4}:){5}[0-9A-Fa-f]{1,4}:
                     (25[0-5]|2[0-4]\d|[0-1]?\d?\d)
                     (\.(25[0-5]|2[0-4]\d|[0-1]?\d?\d)){3}))$|
                   ^(([0-9A-Fa-f]{1,4}:){5}:[0-9A-Fa-f]{1,4}:
                     (25[0-5]|2[0-4]\d|[0-1]?\d?\d)
                     (\.(25[0-5]|2[0-4]\d|[0-1]?\d?\d)){3})$|
                   ^(([0-9A-Fa-f]{1,4}:){1,1}(:[0-9A-Fa-f]{1,4}){1,4}:
                     (25[0-5]|2[0-4]\d|[0-1]?\d?\d)
                     (\.(25[0-5]|2[0-4]\d|[0-1]?\d?\d)){3})$|
                   ^(([0-9A-Fa-f]{1,4}:){1,2}(:[0-9A-Fa-f]{1,4}){1,3}:
                     (25[0-5]|2[0-4]\d|[0-1]?\d?\d)
                     (\.(25[0-5]|2[0-4]\d|[0-1]?\d?\d)){3})$|
                   ^(([0-9A-Fa-f]{1,4}:){1,3}(:[0-9A-Fa-f]{1,4}){1,2}:
                     (25[0-5]|2[0-4]\d|[0-1]?\d?\d)
                     (\.(25[0-5]|2[0-4]\d|[0-1]?\d?\d)){3})$|
                   ^(([0-9A-Fa-f]{1,4}:){1,4}(:[0-9A-Fa-f]{1,4}){1,1}:
                     (25[0-5]|2[0-4]\d|[0-1]?\d?\d)
                     (\.(25[0-5]|2[0-4]\d|[0-1]?\d?\d)){3})$|
                   ^((([0-9A-Fa-f]{1,4}:){1,5}|:):
                     (25[0-5]|2[0-4]\d|[0-1]?\d?\d)
                     (\.(25[0-5]|2[0-4]\d|[0-1]?\d?\d)){3})$|
                   ^(:(:[0-9A-Fa-f]{1,4}){1,5}:
                     (25[0-5]|2[0-4]\d|[0-1]?\d?\d)
                     (\.(25[0-5]|2[0-4]\d|[0-1]?\d?\d)){3})$"/>

Notes:

The document does not address compressed IPv6 addresses, and the IPv6 regular expression pattern does provided in the proposed XML validation does not match compressed IPv6 addresses.

I recommend using a more comprehensive regular expression, adding another note to the appendix that the IPv6 pattern is only included for brevity, or modifying the document to require fully expanded IPv6 addresses.

Credit for the IPv6 regular expression above goes to Vernon Mauery (http://vernon.mauery.com/content/projects/linux/ipv6_regex).

Errata ID: 5229
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Steven Hilton
Date Reported: 2018-01-07

Section Appendix C says:

   <!-- The DMARC policy that applied to the messages in
        this report. -->
   <xs:complexType name="PolicyPublishedType">
     <xs:all>
       <!-- The domain at which the DMARC record was found. -->
       <xs:element name="domain" type="xs:string"/>
       <!-- The DKIM alignment mode. -->
       <xs:element name="adkim" type="AlignmentType"
                   minOccurs="0"/>
       <!-- The SPF alignment mode. -->
       <xs:element name="aspf" type="AlignmentType"
                   minOccurs="0"/>
       <!-- The policy to apply to messages from the domain. -->
       <xs:element name="p" type="DispositionType"/>
       <!-- The policy to apply to messages from subdomains. -->
       <xs:element name="sp" type="DispositionType"/>
       <!-- The percent of messages to which policy applies. -->
       <xs:element name="pct" type="xs:integer"/>
       <!-- Failure reporting options in effect. -->
       <xs:element name="fo" type="xs:string"/>
     </xs:all>
   </xs:complexType>

It should say:

   <!-- The DMARC policy that applied to the messages in
        this report. -->
   <xs:complexType name="PolicyPublishedType">
     <xs:all>
       <!-- The domain at which the DMARC record was found. -->
       <xs:element name="domain" type="xs:string"/>
       <!-- The DKIM alignment mode. -->
       <xs:element name="adkim" type="AlignmentType"
                   minOccurs="0"/>
       <!-- The SPF alignment mode. -->
       <xs:element name="aspf" type="AlignmentType"
                   minOccurs="0"/>
       <!-- The policy to apply to messages from the domain. -->
       <xs:element name="p" type="DispositionType"/>
       <!-- The policy to apply to messages from subdomains. -->
       <xs:element name="sp" type="DispositionType"/
                   minOccurs="0"/>
       <!-- The percent of messages to which policy applies. -->
       <xs:element name="pct" type="xs:integer"/>
       <!-- Failure reporting options in effect. -->
       <xs:element name="fo" type="xs:string"/
                   minOccurs="0"/>
     </xs:all>
   </xs:complexType>

Notes:

Per section 6.3, "adkim", "aspf", "sp", "pct", and "fo" are optional. All but "sp" have a default value, which is inconsistently applied in Appendix C.

If the Subdomain Policy (sp) is required in aggregate reports, I recommend clarification on how to provide this information for domains that do not publish this information.
For example:
- If a subdomain policy is published on a subdomain of an organizational domain, return an 'ignored' subdomain policy in the aggregate report
- If a subdomain policy is NOT published on an organizational domain, recommend returning the effective subdomain policy in the aggregate report, which is the domain policy per section 6.3
- Recommend addition of the "fo" tag only if the "ruf" tag is published.

Errata ID: 5495
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Scott Kitterman
Date Reported: 2018-09-08

Section 6.6.3 step 1 says:

   1.  Mail Receivers MUST query the DNS for a DMARC TXT record at the
       DNS domain matching the one found in the RFC5322.From domain in
       the message.  A possibly empty set of records is returned.

It should say:

   1.  Mail Receivers MUST query the DNS for a DMARC TXT record at the
       DNS domain matching the _dmarc subdomain of the one found in
       the RFC5322.From domain in the message.  A possibly empty set
       of records is returned.

Notes:

Section 6.1. DMARC Policy Record states that DMARC records are 'stored as DNS TXT records in subdomains named "_dmarc"'. The policy discovery procedure needs to match. As I read it, it currently doesn't.

Errata ID: 5773
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Freddie Leeman
Date Reported: 2019-07-03

Section Appendix C says:

   <!-- The DMARC policy that applied to the messages in
        this report. -->
   <xs:complexType name="PolicyPublishedType">
     <xs:all>
       <!-- The domain at which the DMARC record was found. -->
       <xs:element name="domain" type="xs:string"/>
       <!-- The DKIM alignment mode. -->
       <xs:element name="adkim" type="AlignmentType"
                   minOccurs="0"/>
       <!-- The SPF alignment mode. -->
       <xs:element name="aspf" type="AlignmentType"
                   minOccurs="0"/>
       <!-- The policy to apply to messages from the domain. -->
       <xs:element name="p" type="DispositionType"/>
       <!-- The policy to apply to messages from subdomains. -->
       <xs:element name="sp" type="DispositionType"/>
       <!-- The percent of messages to which policy applies. -->
       <xs:element name="pct" type="xs:integer"/>
       <!-- Failure reporting options in effect. -->
       <xs:element name="fo" type="xs:string"/>
     </xs:all>
   </xs:complexType>

It should say:

   <!-- The DMARC policy that applied to the messages in
        this report. -->
   <xs:complexType name="PolicyPublishedType">
     <xs:all>
       <!-- The domain at which the DMARC record was found. -->
       <xs:element name="domain" type="xs:string"/>
       <!-- The DKIM alignment mode. -->
       <xs:element name="adkim" type="AlignmentType"/>
       <!-- The SPF alignment mode. -->
       <xs:element name="aspf" type="AlignmentType"/>
       <!-- The policy to apply to messages from the domain. -->
       <xs:element name="p" type="DispositionType"/>
       <!-- The policy to apply to messages from subdomains. -->
       <xs:element name="sp" type="DispositionType"/>
       <!-- The percent of messages to which policy applies. -->
       <xs:element name="pct" type="xs:integer"/>
       <!-- Failure reporting options. -->
       <xs:element name="fo" type="xs:string" />
     </xs:all>
   </xs:complexType>

Notes:

The name "PolicyPublishedType" suggests that the elements within it represent the domain's published policy. But the comment from element "fo" describes itself as "Failure reporting options IN EFFECT".

A lot of organizations do not send failure (forensic) reports and do not publish the "fo" element in their aggregate reports (Google, Yahoo!, Zoho) . This is reasonable since the description says "in effect". But the field also has a (default) MinOccurs of 1 because MinOccurs is not defined. So by omitting the element, the reports from these organizations are in violation of the guidelines.

Should an aggregate report have a mandatory "fo" element, even if the organization doesn't do failure (forensic) reporting? If so, than the comment "<!-- Failure reporting options in effect. -->" should be "<!-- Failure reporting options. -->". And if not, than the minOccurs="0" should be added to the "fo" element to allow it to be optional.

Even if DMARC policy options are OPTIONAL and not specified, the messages are processed by the receiver with the default values. This is also the case for adkim and aspf, which also have a minOccurs of 0.

So i would suggest the following:

The PolicyPublishedType describe the policy that is applied tot the messages in the reports. Elements that are not defined by the domain's DMARC policy should be filled with the default values, as they would also be processed that way. So when adkim is not configured in the policy, the report should state value "r" as this is the default value. Same applies to aspf ("r"), sp (same as "p"), pct (100) and fo (0). Even if an organization doesn't send out failure reports it MUST mention the "fo" value from the domain's policy, or, when not specified, the default value of 0.

Errata ID: 6729
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Scott Kitterman
Date Reported: 2021-11-01

Section 3.2 says:

   3.  Search the public suffix list for the name that matches the
       largest number of labels found in the subject DNS domain.  Let
       that number be "x".

It should say:

   3.  Search the ICANN DOMAINS section of the public suffix list for
       the name that matches the largest number of labels found in the
       subject DNS domain.  Let that number be "x".

Notes:

The PSL includes both public and private domains. RFC 7489 should have limited name matching to the public, ICANN DOMAINS section of the PSL. As an example, using the current PSL, the organizational domain for example.s3.dualstack.ap-northeast-1.amazonaws.com is example.s3.dualstack.ap-northeast-1.amazonaws.com, not amazonaws.com since it is listed in the private section of the PSL. This is clearly the wrong result.

Errata ID: 7099
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Cris van Pelt
Date Reported: 2018-05-28

Section 7.2.1.1 says:

   The extension MUST be "xml" for a plain XML file, or "xml.gz" for an
   XML file compressed using GZIP.

   "unique-id" allows an optional unique ID generated by the Mail
   Receiver to distinguish among multiple reports generated
   simultaneously by different sources within the same Domain Owner.

   For example, this is a possible filename for the gzip file of a
   report to the Domain Owner "example.com" from the Mail Receiver
   "mail.receiver.example":

     mail.receiver.example!example.com!1013662812!1013749130.gz

It should say:

   The extension MUST be "xml" for a plain XML file, or "xml.gz" for an
   XML file compressed using GZIP.

   "unique-id" allows an optional unique ID generated by the Mail
   Receiver to distinguish among multiple reports generated
   simultaneously by different sources within the same Domain Owner.

   For example, this is a possible filename for the gzip file of a
   report to the Domain Owner "example.com" from the Mail Receiver
   "mail.receiver.example":

     mail.receiver.example!example.com!1013662812!1013749130.xml.gz

Notes:

The example filename uses an invalid extension (not one of "xml", "xml.gz").

Errata ID: 7100
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Cris van Pelt
Date Reported: 2018-05-28

Section 7.2.1.1 says:

   The extension MUST be "xml" for a plain XML file, or "xml.gz" for an
   XML file compressed using GZIP.

   "unique-id" allows an optional unique ID generated by the Mail
   Receiver to distinguish among multiple reports generated
   simultaneously by different sources within the same Domain Owner.

   For example, this is a possible filename for the gzip file of a
   report to the Domain Owner "example.com" from the Mail Receiver
   "mail.receiver.example":

     mail.receiver.example!example.com!1013662812!1013749130.gz

It should say:

   The extension MUST be "xml" for a plain XML file, or "xml.gz" for an
   XML file compressed using GZIP.

   "unique-id" allows an optional unique ID generated by the Mail
   Receiver to distinguish among multiple reports generated
   simultaneously by different sources within the same Domain Owner.

   For example, this is a possible filename for the gzip file of a
   report to the Domain Owner "example.com" from the Mail Receiver
   "mail.receiver.example":

     mail.receiver.example!example.com!1013662812!1013749130.xml.gz

Notes:

The example filename uses an invalid extension (not one of "xml", "xml.gz").

Errata ID: 7865
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Fränz Friederes
Date Reported: 2024-03-23

Appendix C says:

<!-- Credit to Roger L. Costello for IPv4 regex
    http://mailman.ic.ac.uk/pipermail/xml-dev/1999-December/
          018018.html -->
<!-- Credit to java2s.com for IPv6 regex
    http://www.java2s.com/Code/XML/XML-Schema/
          IPv6addressesareeasiertodescribeusingasimpleregex.htm -->
<xs:simpleType name="IPAddress">
  <xs:restriction base="xs:string">
    <xs:pattern value="((1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5]).){3}
                (1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])|
                ([A-Fa-f0-9]{1,4}:){7}[A-Fa-f0-9]{1,4}"/>
  </xs:restriction>
</xs:simpleType>

It should say:

<!-- Credit to Roger L. Costello for IPv4 regex
    http://mailman.ic.ac.uk/pipermail/xml-dev/1999-December/
          018050.html -->
<!-- Credit to java2s.com for IPv6 regex
    http://www.java2s.com/Code/XML/XML-Schema/
          IPv6addressesareeasiertodescribeusingasimpleregex.htm -->
<xs:simpleType name="IPAddress">
  <xs:restriction base="xs:string">
    <xs:pattern value="((1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\.){3}
                (1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])|
                ([A-Fa-f0-9]{1,4}:){7}[A-Fa-f0-9]{1,4}"/>
  </xs:restriction>
</xs:simpleType>

Notes:

The IPv4 regex contains a period "." that should be corrected to an escaped period "\." As stated in the follow up message of the one referenced in the IPv4 regex credit: "I just realized that there is a bug [...] The period (.) is a special character meaning 'any character'. To indicate that we want a period and not 'any character' the period must be escaped with a backslash, i.e., \." Following the XML schema provided in the original Appendix C, strings like "1a1a1a1" and "1111111" are considered valid IPv4 addresses, although they are not usable.

RFC 7493, "The I-JSON Message Format", March 2015

Source of RFC: json (app)

Errata ID: 5354
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Anders Rundgren
Date Reported: 2018-05-10

Section 2.2 says:

An I-JSON sender cannot expect a receiver to treat an integer whose
absolute value is greater than 9007199254740991 (i.e., that is
outside the range [-(2**53)+1, (2**53)-1]) as an exact value.

It should say:

An I-JSON sender cannot expect a receiver to treat an integer whose
absolute value is greater than 9007199254740992 (i.e., that is
outside the range [-(2**53), (2**53)]) as an exact value.

Notes:

The limit is presumably derived from ECMAScript which says:

"The value of Number.MAX_SAFE_INTEGER is the largest integer n such that n and n + 1 are both exactly representable as a Number value"

However, Number.MAX_SAFE_INTEGER is 9007199254740991.

Errata ID: 6861
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Chris Morgan
Date Reported: 2022-02-25

Section 2.1 says:

   Object member names, and string values in arrays and object members,
   MUST NOT include code points that identify Surrogates or
   Noncharacters as defined by [UNICODE].

It should say:

   Object member names, and string values,
   MUST NOT include code points that identify Surrogates or
   Noncharacters as defined by [UNICODE].

Notes:

The expression “string values in arrays and object members” is overly qualified, excluding cases where the *entire message* is a string value, which should clearly be covered also. So the qualification “in arrays and object members” should be removed.

Supporting citations:

RFC 7493, section 2: “An I-JSON message is a JSON text, as defined by RFC 7159.”

RFC 7159, section 2: “A JSON text is a serialized value. Note that certain previous specifications of JSON constrained a JSON text to be an object or an array. […]”

RFC 7159, section 2:

JSON-text = ws value ws

RFC 7159, section 3:

value = false / null / true / object / array / number / string

RFC 7512, "The PKCS #11 URI Scheme", April 2015

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 4813
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Sean Leonard
Date Reported: 2016-09-27

Section 2.4 says:

   o  If the value contains "|<absolute-command-path>", the
      implementation SHOULD read the PIN from the output of an
      application specified with absolute path "<absolute-command-
      path>".  Note that character "|" representing a pipe does not have
      to be percent-encoded in the query component of a PKCS #11 URI.

It should say:

(Eliminate)

Notes:

The "|" character is not a valid URI [RFC3986] character. Strings that include "|" are not URIs and therefore are not valid pkcs11: URIs.

The ABNF in Section 2.3 also needs to be updated to remove "|".

Section 2.3 Original:
pk11-query-res-avail = pk11-res-avail / "/" / "?" / "|"

Section 2.3 Corrected:
pk11-query-res-avail = pk11-res-avail / "/" / "?"

RFC 7515, "JSON Web Signature (JWS)", May 2015

Source of RFC: jose (sec)

Errata ID: 7767
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Jeffrey Yasskin
Date Reported: 2024-01-17

Section 6 says:

These Header Parameters MUST
   be integrity protected if the information that they convey is to be
   utilized in a trust decision; however, if the only information used
   in the trust decision is a key, these parameters need not be
   integrity protected, since changing them in a way that causes a
   different key to be used will cause the validation to fail.

It should say:

These Header Parameters MUST
   be integrity protected if the information that they convey is to be
   utilized in a trust decision.

Notes:

See the discussion for https://www.rfc-editor.org/errata/eid7719 at https://mailarchive.ietf.org/arch/msg/jose/I3_IuEfFSyiHWap7Pyn1BFAb4QM/. The deleted text is incorrect for both signature schemes and encryption schemes.

You could consider adding text like "Note that some algorithms allow multiple keys to validate or decrypt the same signature or encrypted data." to prevent readers from making the same bad assumption as the original RFC authors, but it doesn't seem necessary if doing so is contentious. Similarly, it's probably ok to simply delete the whole "Original Text" if that seems better to the reviewers.

RFC 7516, "JSON Web Encryption (JWE)", May 2015

Source of RFC: jose (sec)

Errata ID: 7719
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Jeffrey Yasskin
Date Reported: 2023-12-01

Section 6 says:

The key identification methods for this specification are the same as
those defined in Section 6 of [JWS], except that the key being
identified is the public key to which the JWE was encrypted.

It should say:

??? <I don't know the proper correction.>

Notes:

Section 6 of [JWS] says "these parameters need not be integrity protected, since changing them in a way that causes a different key to be used will cause the validation to fail."

I don't know if this is true for signature schemes (that is, RFC 7515 might have the same erratum), but this is only true for encryption schemes if the algorithm is key-committing. See https://www.ietf.org/archive/id/draft-irtf-cfrg-aead-properties-02.html#name-key-commitment.

Errata ID: 6018
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kinan Diraneyya
Date Reported: 2020-03-16

Throughout the document, when it says:

initialization vector

It should say:

initialization value

Notes:

RFCs 7516 through 7520 (inclusive) all used the deprecated (as dictated by RFC 4949) term "initialization vector" in place of the newer term "initialization value".

RFC 7517, "JSON Web Key (JWK)", May 2015

Source of RFC: jose (sec)

Errata ID: 6907
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Weijun Wang
Date Reported: 2022-03-30

Section C.7 says:

C.7.  Additional Authenticated Data

   Let the Additional Authenticated Data encryption parameter be
   ASCII(BASE64URL(UTF8(JWE Protected Header))).  This value is:

   [123, 34, 97, 108, 103, 34, 58, 34, 80, 66, 69, 83, 50, 45, 72, 83,
   50, 53, 54, 43, 65, 49, 50, 56, 75, 87, 34, 44, 34, 112, 50, 115, 34,
   58, 34, 50, 87, 67, 84, 99, 74, 90, 49, 82, 118, 100, 95, 67, 74,
   117, 74, 114, 105, 112, 81, 49, 119, 34, 44, 34, 112, 50, 99, 34, 58,
   52, 48, 57, 54, 44, 34, 101, 110, 99, 34, 58, 34, 65, 49, 50, 56, 67,
   66, 67, 45, 72, 83, 50, 53, 54, 34, 44, 34, 99, 116, 121, 34, 58, 34,
   106, 119, 107, 43, 106, 115, 111, 110, 34, 125]

It should say:

C.7.  Additional Authenticated Data

   Let the Additional Authenticated Data encryption parameter be
   ASCII(BASE64URL(UTF8(JWE Protected Header))).  The value is:

   [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 81, 81, 107, 86,
   84, 77, 105, 49, 73, 85, 122, 73, 49, 78, 105, 116, 66, 77, 84, 73,
   52, 83, 49, 99, 105, 76, 67, 74, 119, 77, 110, 77, 105, 79, 105, 73,
   121, 86, 48, 78, 85, 89, 48, 112, 97, 77, 86, 74, 50, 90, 70, 57, 68,
   83, 110, 86, 75, 99, 109, 108, 119, 85, 84, 70, 51, 73, 105, 119,
   105, 99, 68, 74, 106, 73, 106, 111, 48, 77, 68, 107, 50, 76, 67, 74,
   108, 98, 109, 77, 105, 79, 105, 74, 66, 77, 84, 73, 52, 81, 48, 74,
   68, 76, 85, 104, 84, 77, 106, 85, 50, 73, 105, 119, 105, 89, 51, 82,
   53, 73, 106, 111, 105, 97, 110, 100, 114, 75, 50, 112, 122, 98, 50,
   52, 105, 102, 81]

Notes:

The array in the original text is the content of JWE Protected Header. The corrected text shows the content of the AAD parameter.

RFC 7519, "JSON Web Token (JWT)", May 2015

Note: This RFC has been updated by RFC 7797, RFC 8725

Source of RFC: oauth (sec)

Errata ID: 5906
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Erdem Memisyazici
Date Reported: 2019-11-13

Section 7.2 says:

   Finally, note that it is an application decision which algorithms may
   be used in a given context.  Even if a JWT can be successfully
   validated, unless the algorithms used in the JWT are acceptable to
   the application, it SHOULD reject the JWT.

It should say:

   Finally, note that it is an application decision which algorithms may
   be used in a given context.  Even if a JWT can be successfully
   validated, unless the algorithms used in the JWT are acceptable to
   the application, it MUST reject the JWT.

Notes:

A vulnerability exists in certain implementations in the wild where applications simply look for valid JWT tokens which includes the "none" algorithm (https://medium.com/swlh/hacking-json-web-tokens-jwts-9122efe91e4a). A fairly popular library is auth0's java-jwt and at verification (https://github.com/auth0/java-jwt/blob/master/lib/src/main/java/com/auth0/jwt/JWTVerifier.java) quite reasonably you cannot initialize the class without an algorithm. Given all capital SHOULD may be interpreted as a recommendation and as this RFC dictates the algorithm "none" MUST be implemented as a default algorithm under Section 8, one could argue JWTVerifier in the example doesn't have to verifyAlgorithm leading to the vulnerability pointed out in the first article while still complying by the specification. There is no good reason why an algorithm unacceptable to the application must not be rejected as it does more harm than good and all popular library implementations interpret it as such.

Errata ID: 7720
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Timothy Vergenz
Date Reported: 2023-12-01

Section 4.1.6 says:

4.1.6.  "iat" (Issued At) Claim

The "iat" (issued at) claim identifies the time at which the JWT was
issued.  This claim can be used to determine the age of the JWT.  Its
value MUST be a number containing a NumericDate value.  Use of this
claim is OPTIONAL.

It should say:

4.1.6.  "iat" (Issued At) Claim

The "iat" (issued at) claim identifies the time at which the JWT was
issued.  This claim can be used to determine the age of the JWT.  Its
value MUST be a number containing a NumericDate value.  Use of this
claim is OPTIONAL. Implementors MUST NOT reject otherwise-valid JWTs
with "iat" claims that appear to be from the future; token issuers
desiring this behavior may require it by including an "nbf" claim.

Notes:

There is substantial confusion and disagreement among JWT library implementors about whether to reject JWTs with `iat` claims that appear to be from the future due to clock drift. This confusion has led to over half a dozen Github issues & PRs over the years in libraries in many different ecosystems, and lots of strong disagreement among library developers and users.

Based on a sample of the top Google search results for jwt client libraries in 11 different language ecosystems, the majority (7) of the libraries sampled do not reject future `iat` claims, while the remaining 4 *do* reject future `iat` claims by default. Of those 4 who do, *all* of them have had Github issues filed (by different unique users) in which the user was having a JWT unexpectedly rejected by a token validator using the library whose clock had drifted from that of the token issuer enough to trigger `iat`-based rejection.

I propose we update the spec to explicitly prohibit rejection of future-`iat` JWTs (especially since token issuers have always been able to opt into this behavior using an `nbf` claim). Since this RFC has been published and cannot be edited, a new superseding RFC will have to be published and this one deprecated in order for the suggested change to make it out of the errata and into an actual RFC doc.

I'm not sure if this merits a full RFC republish -- but as a data point for impact consideration, it's worth noting that this confusion has almost certainly wasted at least multiple hours per person (on average) of *dozens* of developers' time over the years, and led to at least half a dozen production bugs that I've seen mentioned. One of these bugs cropped up in my own organization on 2023-11-31 and has been observed previously but was misunderstood and not resolved; the 2023-11-31 occurence involved 10+ people in discussion. One Github issue I saw described an elongated full web server outage attributed to this confusion which cropped up during a leap-second-related clock drift issue. I'm filing this errata request on calendar day 3+ of discussing this issue in my organization (if you include past times this issue has cropped up).

Thanks for your consideration! I look forward to hearing back.

RFC 7520, "Examples of Protecting Content Using JSON Object Signing and Encryption (JOSE)", May 2015

Source of RFC: jose (sec)

Errata ID: 7680
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Filip Skokan
Date Reported: 2023-10-17

Section 5.9 says:

   This example illustrates encrypting content that is first compressed.
   It reuses the AES symmetric key, key encryption algorithm, and
   content encryption algorithm from Section 5.8.

   Note that whitespace is added for readability as described in
   Section 1.1.

It should say:

   This example illustrates encrypting content that is first compressed.
   It reuses the AES symmetric key, key encryption algorithm, and
   content encryption algorithm from Section 5.8.

   Note that DEFLATE [RFC1951] is not a deterministic algorithm; its
   implementations must properly round-trip but are not required to
   produce the same compressed data; it might not be possible to exactly
   replicate the results in this section.

   Note that whitespace is added for readability as described in
   Section 1.1.

Notes:

This added text is aligned with other non-deterministic algorithms in sections 4.2, 4.3, 5.1, 5.2, 5.13, and 6. It gives the reader a heads up that the results might not be replicable, e.g. when using a modern zlib deflate implementation which uses ANZAC++ hash in favour of hardware accelerated hashing function (i.e. CRC32) to insert symbols in the dictionary during compression.

Errata ID: 4802
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Florent Morselli
Date Reported: 2016-09-13

Section 5.7.5 says:

The figure 150 is:

   {
     "protected": "eyJhbGciOiJBMjU2R0NNS1ciLCJpdiI6IktrWVQwR1hfMm
         pIbGZxTl8iLCJraWQiOiIxOGVjMDhlMS1iZmE5LTRkOTUtYjIwNS0yYj
         RkZDFkNDMyMWQiLCJ0YWciOiJrZlBkdVZRM1QzSDZ2bmV3dC0ta3N3Ii
         wiZW5jIjoiQTEyOENCQy1IUzI1NiJ9",
     "encrypted_key": "lJf3HbOApxMEBkCMOoTnnABxs_CvTWUmZQ2ElLvYNo
         k",
     "iv": "gz6NjyEFNm_vm8Gj6FwoFQ",
     "ciphertext": "Jf5p9-ZhJlJy_IQ_byKFmI0Ro7w7G1QiaZpI8OaiVgD8E
         qoDZHyFKFBupS8iaEeVIgMqWmsuJKuoVgzR3YfzoMd3GxEm3VxNhzWyW
         tZKX0gxKdy6HgLvqoGNbZCzLjqcpDiF8q2_62EVAbr2uSc2oaxFmFuIQ
         HLcqAHxy51449xkjZ7ewzZaGV3eFqhpco8o4DijXaG5_7kp3h2cajRfD
         gymuxUbWgLqaeNQaJtvJmSMFuEOSAzw9Hdeb6yhdTynCRmu-kqtO5Dec
         4lT2OMZKpnxc_F1_4yDJFcqb5CiDSmA-psB2k0JtjxAj4UPI61oONK7z
         zFIu4gBfjJCndsZfdvG7h8wGjV98QhrKEnR7xKZ3KCr0_qR1B-gxpNk3
         xWU",
     "tag": "NvBveHr_vonkvflfnUrmBQ"
   }

But the protected header in the figure 145 is:

   eyJhbGciOiJBMjU2R0NNS1ciLCJraWQiOiIxOGVjMDhlMS1iZmE5LTRkOTUtYj
   IwNS0yYjRkZDFkNDMyMWQiLCJ0YWciOiJrZlBkdVZRM1QzSDZ2bmV3dC0ta3N3
   IiwiaXYiOiJLa1lUMEdYXzJqSGxmcU5fIiwiZW5jIjoiQTEyOENCQy1IUzI1Ni
   J9

And the figure 147 indicates the tag is "DKW7jrb4WaRSNfbXVPlT5g".

It should say:

The figure 150 should be:

The figure 150 is:

   {
     "protected": "eyJhbGciOiJBMjU2R0NNS1ciLCJraWQiOiIxOGVjMDhlMS
      1iZmE5LTRkOTUtYjIwNS0yYjRkZDFkNDMyMWQiLCJ0YWciOiJrZlBkdVZRM
      1QzSDZ2bmV3dC0ta3N3IiwiaXYiOiJLa1lUMEdYXzJqSGxmcU5fIiwiZW5j
      IjoiQTEyOENCQy1IUzI1NiJ9",
     "encrypted_key": "lJf3HbOApxMEBkCMOoTnnABxs_CvTWUmZQ2ElLvYNo
         k",
     "iv": "gz6NjyEFNm_vm8Gj6FwoFQ",
     "ciphertext": "Jf5p9-ZhJlJy_IQ_byKFmI0Ro7w7G1QiaZpI8OaiVgD8E
         qoDZHyFKFBupS8iaEeVIgMqWmsuJKuoVgzR3YfzoMd3GxEm3VxNhzWyW
         tZKX0gxKdy6HgLvqoGNbZCzLjqcpDiF8q2_62EVAbr2uSc2oaxFmFuIQ
         HLcqAHxy51449xkjZ7ewzZaGV3eFqhpco8o4DijXaG5_7kp3h2cajRfD
         gymuxUbWgLqaeNQaJtvJmSMFuEOSAzw9Hdeb6yhdTynCRmu-kqtO5Dec
         4lT2OMZKpnxc_F1_4yDJFcqb5CiDSmA-psB2k0JtjxAj4UPI61oONK7z
         zFIu4gBfjJCndsZfdvG7h8wGjV98QhrKEnR7xKZ3KCr0_qR1B-gxpNk3
         xWU",
     "tag": "DKW7jrb4WaRSNfbXVPlT5g"
   }

Notes:

Wrong JSON Flattened Representation

RFC 7530, "Network File System (NFS) Version 4 Protocol", March 2015

Note: This RFC has been updated by RFC 7931, RFC 8587

Source of RFC: nfsv4 (wit)

Errata ID: 4639
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Stephen Butler
Date Reported: 2016-03-16

Section 5.9 says:

To provide a greater degree of compatibility with NFSv3, which
identified users and groups by 32-bit unsigned user identifiers and
group identifiers, owner and group strings that consist of ASCII-
encoded decimal numeric values with no leading zeros can be given a
special interpretation by clients and servers that choose to provide
such support.

It should say:

To provide a greater degree of compatibility with NFSv3, which
identified users and groups by 32-bit unsigned user identifiers and
group identifiers, owner and group strings that consist of UTF-8
encoded decimal numeric values with no leading zeros can be given a
special interpretation by clients and servers that choose to provide
such support.

Notes:

The start of section 5.9 says:

The RECOMMENDED attributes "owner" and "owner_group" (and also users
and groups used as values of the who field within nfs4ace structures
used in the acl attribute) are represented in the form of UTF-8
strings.

I believe in the case of the digits 0-9 the ASCII encoding is the same as the UTF-8 encoding but it may cause possible confusion by not maintaining consistency.

Errata ID: 4742
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Manju Karthik
Date Reported: 2016-07-15

Section section-6.2. says:

https://tools.ietf.org/html/rfc7530#section-6.2.1

   The client can use the OPEN or ACCESS
   operations to check access without modifying or reading data or
   metadata.

It should say:

   The client can use the OPEN or ACCESS
   operations to check access without modifying or reading data.

Notes:

Whenever client does OPEN/ACCESS call, there is an inadvertent change in the Last Access time of the file. Hence we think that the Metadata is modified due to OPEN/ACCESS call. Hence the Suggestion is to change the text as above.

Errata ID: 5407
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Viral Mehta
Date Reported: 2018-06-24

Section 16.36 says:

The write
   verifier is a cookie that the client can use to determine whether the
   server has changed instance (boot) state between a call to WRITE and
   a subsequent call to either WRITE or COMMIT.  This cookie must be
   consistent during a single instance of the NFSv4 protocol service and
   must be unique between instances of the NFSv4 protocol server, where
   uncommitted data may be lost.

It should say:

The write
   verifier is a cookie that the client can use to determine whether the
   server has changed instance (boot) state between a call to WRITE and
   a subsequent call to either WRITE or COMMIT.  This cookie must be
   consistent during a single instance of the NFSv4 protocol service and
   must be unique between instances of the NFSv4 protocol server, where
   uncommitted data may be lost. The server implementation should not
   assume that the cookie is on per file basis.

Notes:

Different NFS client implementation has chosen to interpret above statement differently. Semantically, it is correct to track cookie on per file basis since both WRITE and COMMIT happens on a single file handle. But, RFC wording says that the cookie should be maintained on a per server instance basis. Either way, I believe the RFC can be more clearer for both client and server implementer.

Errata ID: 5531
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Sylvain Etienne
Date Reported: 2018-10-16

Section 10.4.6. says:

   o  When the callback path is down, the server MUST NOT revoke the
      delegation if one of the following occurs:

      *  (...)

      *  The client has not issued a RENEW operation for some period of
         time after the server attempted to recall the delegation.  This
         period of time MUST NOT be less than the value of the
         lease_time attribute.

It should say:

   o  When the callback path is down, the server MUST NOT revoke the
      delegation if one of the following occurs:

      *  (...)

      *  The client has not issued a RENEW operation for some period of
         time after the server attempted to recall the delegation.  This
         period of time MUST be less than the value of the
         lease_time attribute.

Notes:

It does not make sense to revoke the delegation before lease_time period expiration and to not revoke it after.

Errata ID: 7595
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: David Noveck
Date Reported: 2023-08-10

Section 13.1.7 says:

13.1.7.  Name Errors

   Names in NFSv4 are UTF-8 strings.  When the strings are not of length
   zero, the error NFS4ERR_INVAL results.  When they are not valid
   UTF-8, the error NFS4ERR_INVAL also results, but servers may
   accommodate file systems with different character formats and not
   return this error.  Besides this, there are a number of other errors
   to indicate specific problems with names.

13.1.7.1.  NFS4ERR_BADCHAR (Error Code 10040)

   A UTF-8 string contains a character that is not supported by the
   server in the context in which it is being used.

13.1.7.2.  NFS4ERR_BADNAME (Error Code 10041)

   A name string in a request consisted of valid UTF-8 characters
   supported by the server, but the name is not supported by the server
   as a valid name for current operation.  An example might be creating
   a file or directory named ".." on a server whose file system uses
   that name for links to parent directories.

   This error should not be returned due to a normalization issue in a
   string.  When a file system keeps names in a particular normalization
   form, it is the server's responsibility to do the appropriate
   normalization, rather than rejecting the name.

It should say:

13.1.7.  Name Errors

Names in NFSv4 often are UTF-8 strings. However, in order to provide
compatibility with NFSv3 and with local filesystems that do not impose any such
restrictions on the form of name strings, UTF-8-unaware file systems are
supported.  For such file systems,  the server is, for the most part, unaware of
the encoding of names chosen by the client and is therefore unable to support
normalization-related processing or case-insensitivity.  In order to provide
proper support for the errors NFS4ERR_BADCHAR and NFS4ERR_BADNAME, the encoding
used by clients MUST use the same encoding as UTF-8 for all printable ASCII
characters.

For file systems which are UTF-8-aware,  when strings are not valid UTF-8
strings,  the error NFS4ERR_INVAL results.  As a result, clients can determine
whether the current file system is UTF-8-aware by looking up a string which is
not valid UTF-8 (e..g. the single byte 0x80)  and using an error return of
NFS4ERR_INVAl as indicating that only valid UTF-8 strings may be used.

When a string of length zero is passed, the error NFS4ERR_INVAL also results. 
but servers may accommodate file systems with different character formats and
return this error only in this case.  Besides this, there are a number of other
errors to indicate specific problems with names.

13.1.7.1.  NFS4ERR_BADCHAR (Error Code 10040)

A UTF-8 string contains a character that is not supported by the server file
system as part of a  file name.  For example, the forward slash is often
reserved for use to indicate multiple names within a path, making the creation
of file or directory names with embedded slashes problematic.

13.1.7.2.  NFS4ERR_BADNAME (Error Code 10041)

A name string in a request consists of a valid string supported by the server,
whether UTF-8 or otherwise, but the name is not supported by the server as a
valid name for the current operation.  An example might be creating a file or
directory named ".." on a server whose file system uses that name for links to
parent directories.  This error MUST NOT result in case in which  a 
(UTF-8-aware) server file system prefers a particular normalization for strings.
In such cases, it is the server's responsibility to do the appropriate
normalization, rather than rejecting the name.

Notes:

It has been brought to my attention that there is a fundamental contradiction between the idea
(derived from NFSv3) that file name strings can be opaque, and the existence of the errors
NFS4ERR_BADCHAR and NFS4ERR_BADNAME, which, by their nature presume at least some
knowledge of the character encoding being used.

This has not turned out to be a problem in practice because clients always use encodings that
meet certain criteria explained in the replacement text. However, these criteria need to be
documented clearly and appropriate warnings given. These criteria were observed by
implementers of NFSv3 but are not explicitly mentioned in RFC1813.

Errata ID: 4828
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marcel Telka
Date Reported: 2016-10-11

Section 16.24.4. says:

   The arguments contain a cookie value that represents where the
   READDIR should start within the directory.  A value of 0 (zero) for
   the cookie is used to start reading at the beginning of the
   directory.  For subsequent READDIR requests, the client specifies a
   cookie value that is provided by the server in a previous READDIR
   request.

It should say:

   The arguments contain a cookie value that represents where the
   READDIR should start within the directory.  A value of 0 (zero) for
   the cookie is used to start reading at the beginning of the
   directory.  For subsequent READDIR requests, the client specifies a
   cookie value that is provided by the server in a previous READDIR
   reply.

Notes:

The new cookie is provided by the server in a reply, not in a request.

Errata ID: 4934
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marcel Telka
Date Reported: 2017-02-15

Section 9.1.7. says:

   When a request is received, its sequence number (r) is compared to
   that of the last one received (L).  Only if it has the correct next
   sequence, normally L + 1, is the request processed beyond the point
   of seqid checking.  Given a properly functioning client, the response
   to (r) must have been received before the last request (L) was sent.

It should say:

   When a request is received, its sequence number (r) is compared to
   that of the last one received (L).  Only if it has the correct next
   sequence, normally L + 1, is the request processed beyond the point
   of seqid checking.  Given a properly functioning client, the response
   to (L) must have been received before the subsequent request (r) was
   sent.

RFC 7564, "PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols", May 2015

Note: This RFC has been obsoleted by RFC 8264

Source of RFC: precis (app)

Errata ID: 4568
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Sam Whited
Date Reported: 2015-12-20

Section 3 says:

Preparation entails only ensuring that the characters in an
individual string are allowed by the underlying PRECIS string
class.

It should say:

Preparation entails applying some or none of the rules specified for a
particular string class or profile thereof to an individual string, and
ensuring that characters in the resulting string are allowed by the
underlying PRECIS string class.

Notes:

The original text makes it sound like preparation is ONLY validating that the characters in a string are allowed in the underlying PRECIS string class, however, some profiles (for example, see the UsernameCaseMapped profile) specify that some of the rules must be applied first (in the case of UsernameCaseMapped, preparation includes first applying the Width rule).

RFC 7578, "Returning Values from Forms: multipart/form-data", July 2015

Source of RFC: appsawg (art)

Errata ID: 5616
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Philip McGrath
Date Reported: 2019-01-30

Section 4.5 says:

For example, a form with a text field in
which a user typed "Joe owes <eu>100", where <eu> is the Euro symbol,
might have form data returned as:
    --AaB03x
    content-disposition: form-data; name="field1"
    content-type: text/plain;charset=UTF-8
    content-transfer-encoding: quoted-printable

    Joe owes =E2=82=AC100.
    --AaB03x

It should say:

For example, a form with a text field in
which a user typed "Joe owes <eu>100", where <eu> is the Euro symbol,
might have form data returned as:
    --AaB03x
    content-disposition: form-data; name="field1"
    content-type: text/plain;charset=UTF-8
    content-transfer-encoding: quoted-printable

    Joe owes <eu>100.
    --AaB03x

Notes:

Section 4.7 says that "Senders SHOULD NOT generate any parts with a Content-Transfer-Encoding header field."

Errata ID: 7385
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Eugene Adell
Date Reported: 2023-03-13

Section 4.5 says:

       --AaB03x
       content-disposition: form-data; name="field1"
       content-type: text/plain;charset=UTF-8
       content-transfer-encoding: quoted-printable

       Joe owes =E2=82=AC100.
       --AaB03x

It should say:

       --AaB03x
       content-disposition: form-data; name="field1"
       content-type: text/plain;charset=UTF-8

       Joe owes %E2%82%AC100
       --AaB03x

Notes:

Errata ID: 5616 is in status Reported but is failing to correct adequately.
The Content-Transfer-Encoding is Deprecated so the corresponding line should not appear (section 4.7)
UTF-8 characters are supposed to be percent-encoded (section 2)
The endoint point is removed as it's not in the quoted phrase
We can keep the ending boundary as we are not sure if more parameters would follow (Errata ID: 4676).

RFC 7591, "OAuth 2.0 Dynamic Client Registration Protocol", July 2015

Source of RFC: oauth (sec)

Errata ID: 7782
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Tim Würtele
Date Reported: 2024-01-25

Section 3.2.1 says:

client_id
      REQUIRED.  OAuth 2.0 client identifier string.  It SHOULD NOT be
      currently valid for any other registered client, though an
      authorization server MAY issue the same client identifier to
      multiple instances of a registered client at its discretion.

It should say:

client_id
      REQUIRED.  OAuth 2.0 client identifier string.  It MUST NOT be
      currently valid for any other registered client, though an
      authorization server MAY issue the same client identifier to
      multiple instances of a registered client at its discretion.

Notes:

Allowing the same client_id for multiple clients is a contradiction to:

1. This document, Section 1.3, (D), 2nd bullet point: "a client identifier that is unique at the server"

2. This document, Section 3.1: "The authorization server assigns this client a unique client identifier"

3. (normative reference) RFC 6749, Section 2.2: "The authorization server issues the registered client a client identifier -- a unique string representing the registration information provided by the client. [...] The client identifier is unique to the authorization server."

4. (non-normative reference) OpenID Connect Dynamic Client Registration 1.0 incorporating errata set 2, Section 2: "Clients have metadata associated with their unique Client Identifier at the Authorization Server."; Section 3.1: "The Authorization Server assigns this Client a unique Client Identifier"; Section 3.2: "client_id REQUIRED. Unique Client Identifier. It MUST NOT be currently valid for any other registered Client. "

RFC 7601, "Message Header Field for Indicating Message Authentication Status", August 2015

Note: This RFC has been obsoleted by RFC 8601

Source of RFC: appsawg (art)

Errata ID: 5435
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Occil
Date Reported: 2018-07-23

Section 2.2 says:

resinfo = [CFWS] ";" methodspec [ CFWS reasonspec ]
               *( CFWS propspec )

It should say:

resinfo = [CFWS] ";" methodspec [ CFWS reasonspec ]
            [ CFWS 1*propspec ]

Notes:

Since propspec includes optional CFWS at end, parsing the current version of resinfo will result in at most one propspec even if methodspec is followed by more than one propspec.

RFC 7616, "HTTP Digest Access Authentication", September 2015

Source of RFC: httpauth (sec)

Errata ID: 4897
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Chaim Geretz
Date Reported: 2016-12-29

Section 3.9.2 says:

3.9.2.  Example with SHA-512-256, Charset, and Userhash

   The following example assumes that an access-protected document is
   being requested from the server via a GET request.  The URI for the
   request is "http://api.example.org/doe.json".  Both client and server
   know the userhash of the username, support the UTF-8 character
   encoding scheme, and use the SHA-512-256 algorithm.  The username for
   the request is a variation of "Jason Doe", where the 'a' actually is
   Unicode code point U+00E4 ("LATIN SMALL LETTER A WITH DIAERESIS"),
   and the first 'o' is Unicode code point U+00F8 ("LATIN SMALL LETTER O
   WITH STROKE"), leading to the octet sequence using the UTF-8 encoding
   scheme:

      J  U+00E4 s  U+00F8 n      D  o  e
      4A C3A4   73 C3B8   6E 20 44  6F 65

   The password is "Secret, or not?".

   The first time the client requests the document, no Authorization
   header field is sent, so the server responds with:

   HTTP/1.1 401 Unauthorized
   WWW-Authenticate: Digest
       realm="api@example.org",
       qop="auth",
       algorithm=SHA-512-256,
       nonce="5TsQWLVdgBdmrQ0XsxbDODV+57QdFR34I9HAbC/RVvkK",
       opaque="HRPCssKJSGjCrkzDg8OhwpzCiGPChXYjwrI2QmXDnsOS",
       charset=UTF-8,
       userhash=true





Shekh-Yusef, et al.          Standards Track                   [Page 19]

RFC 7616            HTTP Digest Access Authentication     September 2015


   The client can prompt the user for the required credentials and send
   a new request with following Authorization header field:

   Authorization: Digest
       username="488869477bf257147b804c45308cd62ac4e25eb717
          b12b298c79e62dcea254ec",
       realm="api@example.org",
       uri="/doe.json",
       algorithm=SHA-512-256,
       nonce="5TsQWLVdgBdmrQ0XsxbDODV+57QdFR34I9HAbC/RVvkK",
       nc=00000001,
       cnonce="NTg6RKcb9boFIAS3KrFK9BGeh+iDa/sm6jUMp2wds69v",
       qop=auth,
       response="ae66e67d6b427bd3f120414a82e4acff38e8ecd9101d
          6c861229025f607a79dd",
       opaque="HRPCssKJSGjCrkzDg8OhwpzCiGPChXYjwrI2QmXDnsOS",
       userhash=true

   If the client cannot provide a hashed username for any reason, the
   client can try a request with this Authorization header field:

   Authorization: Digest
       username*=UTF-8''J%C3%A4s%C3%B8n%20Doe,
       realm="api@example.org",
       uri="/doe.json",
       algorithm=SHA-512-256,
       nonce="5TsQWLVdgBdmrQ0XsxbDODV+57QdFR34I9HAbC/RVvkK",
       nc=00000001,
       cnonce="NTg6RKcb9boFIAS3KrFK9BGeh+iDa/sm6jUMp2wds69v",
       qop=auth,
       response="ae66e67d6b427bd3f120414a82e4acff38e8ecd9101d
          6c861229025f607a79dd",
       opaque="HRPCssKJSGjCrkzDg8OhwpzCiGPChXYjwrI2QmXDnsOS",
       userhash=false

It should say:

3.9.2.  Example with SHA-512-256, Charset, and Userhash

   The following example assumes that an access-protected document is
   being requested from the server via a GET request.  The URI for the
   request is "http://api.example.org/doe.json".  Both client and server
   know the userhash of the username, support the UTF-8 character
   encoding scheme, and use the SHA-512-256 algorithm.  The username for
   the request is a variation of "Jason Doe", where the 'a' actually is
   Unicode code point U+00E4 ("LATIN SMALL LETTER A WITH DIAERESIS"),
   and the first 'o' is Unicode code point U+00F8 ("LATIN SMALL LETTER O
   WITH STROKE"), leading to the octet sequence using the UTF-8 encoding
   scheme:

      J  U+00E4 s  U+00F8 n      D  o  e
      4A C3A4   73 C3B8   6E 20 44  6F 65

   The password is "Secret, or not?".

   The first time the client requests the document, no Authorization
   header field is sent, so the server responds with:

   HTTP/1.1 401 Unauthorized
   WWW-Authenticate: Digest
       realm="api@example.org",
       qop="auth",
       algorithm=SHA-512-256,
       nonce="5TsQWLVdgBdmrQ0XsxbDODV+57QdFR34I9HAbC/RVvkK",
       opaque="HRPCssKJSGjCrkzDg8OhwpzCiGPChXYjwrI2QmXDnsOS",
       charset=UTF-8,
       userhash=true





Shekh-Yusef, et al.          Standards Track                   [Page 19]

RFC 7616            HTTP Digest Access Authentication     September 2015


   The client can prompt the user for the required credentials and send
   a new request with following Authorization header field:

   Authorization: Digest
       username="793263caabb707a56211940d90411ea4a575adeccb
          7e360aeb624ed06ece9b0b",
       realm="api@example.org",
       uri="/doe.json",
       algorithm=SHA-512-256,
       nonce="5TsQWLVdgBdmrQ0XsxbDODV+57QdFR34I9HAbC/RVvkK",
       nc=00000001,
       cnonce="NTg6RKcb9boFIAS3KrFK9BGeh+iDa/sm6jUMp2wds69v",
       qop=auth,
       response="3798d4131c277846293534c3edc11bd8a5e4cdcbff78
          b05db9d95eeb1cec68a5",
       opaque="HRPCssKJSGjCrkzDg8OhwpzCiGPChXYjwrI2QmXDnsOS",
       userhash=true

   If the client cannot provide a hashed username for any reason, the
   client can try a request with this Authorization header field:

   Authorization: Digest
       username*=UTF-8''J%C3%A4s%C3%B8n%20Doe,
       realm="api@example.org",
       uri="/doe.json",
       algorithm=SHA-512-256,
       nonce="5TsQWLVdgBdmrQ0XsxbDODV+57QdFR34I9HAbC/RVvkK",
       nc=00000001,
       cnonce="NTg6RKcb9boFIAS3KrFK9BGeh+iDa/sm6jUMp2wds69v",
       qop=auth,
       response="3798d4131c277846293534c3edc11bd8a5e4cdcbff78
          b05db9d95eeb1cec68a5",
       opaque="HRPCssKJSGjCrkzDg8OhwpzCiGPChXYjwrI2QmXDnsOS",
       userhash=false

Notes:

If the SHA512/256 algorithm first mentioned in Section 3.2 is to be implemented as defined in FIPS 180.4 Section 6.7 the values of username and response need to be corrected.

Changes start at page 19 of the RFC.

I created this as technical errata since the current values given in the example are for a SHA512/256 algorithm implemented as described in Section 7 of both FIPS 180-3 and FIPS 180-4

Errata ID: 7005
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Patrick Ni
Date Reported: 2022-06-23

Section 3.9.1 says:

uri="/dir/index.html",

It should say:

uri="http://www.example.org/dir/index.html",

Notes:

[1] In Section 3.4, uri -> The Effective Request URI (Section 5.5 of [RFC7230]) of the HTTP request;

[2] In Section 5.5 of [RFC7230]: The components of the effective request URI, once determined as above, can be combined into absolute-URI form by concatenating the scheme, "://", authority, and combined path and query component

[3] uri="/dir/index.html" is an absolute-path, not an Effective Request URI

Errata ID: 6704
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bruce Florman
Date Reported: 2021-10-05

Section 3.4.1 says:

3.4.1.  Response

   If the qop value is "auth" or "auth-int":

         response = <"> < KD ( H(A1), unq(nonce)
                                      ":" nc
                                      ":" unq(cnonce)
                                      ":" unq(qop)
                                      ":" H(A2)
                             ) <">

   See below for the definitions for A1 and A2.

It should say:

3.4.1.  Response

   If the qop value is "auth" or "auth-int":

         response = <"> < KD ( H(A1), unq(nonce)
                                      ":" nc
                                      ":" unq(cnonce)
                                      ":" unq(qop)
                                      ":" H(A2)
                             ) > <">

   See below for the definitions for A1 and A2.

Notes:

The open angle bracket following the initial double quote, probably needs a matching close angle bracket before the final double quote. This typographical error appears to have been copied from section 3.2.2.1 of RFC 2617, but the close angle bracket does appear in the corresponding single line of text in section 2.1.2 of RFC 2069 that defines the response-digest production there. However, it's not clear to me that the angle brackets contribute to the clarity of the response production here, so simply removing the unmatched open might be a better solution.

RFC 7635, "Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization", August 2015

Source of RFC: tram (tsv)

Errata ID: 5059
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Taylor Brandstetter
Date Reported: 2017-07-05

Section 6.2 says:

   key_length:  Length of the session key in octets.  The key length of
      160 bits MUST be supported (i.e., only the 160-bit key is used by
      HMAC-SHA-1 for message integrity of STUN messages).  The key
      length facilitates the hash agility plan discussed in Section 16.3
      of [RFC5389].

It should say:

   key_length:  Length of the session key in octets.

Notes:

RFC2104 section 2 states:

The authentication key K can be of any length up to B, the
block length of the hash function. Applications that use keys longer
than B bytes will first hash the key using H and then use the
resultant L byte string as the actual key to HMAC.

Meaning any key length is allowed. The fact that the hash output is 20 bytes doesn't mean the key needs to be 20 bytes as well.

Errata ID: 5060
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Taylor Brandstetter
Date Reported: 2017-07-05

Section Appendix B says:

   [STUN] supports hash agility and accomplishes this agility by
   computing message integrity using both HMAC-SHA-1 and
   HMAC-SHA-256-128.  The client signals the algorithm supported by it
   to the authorization server in the 'alg' parameter defined in
   [POP-KEY-DIST].  The authorization server determines the length of
   the mac_key based on the HMAC algorithm conveyed by the client.  If
   the client supports both HMAC-SHA-1 and HMAC-SHA-256-128, then it
   signals HMAC-SHA-256-128 to the authorization server, gets a 256-bit
   key from the authorization server, and calculates a 160-bit key for
   HMAC-SHA-1 using SHA1 and taking the 256-bit key as input.

It should say:

   [STUN] supports hash agility and accomplishes this agility by
   computing message integrity using both HMAC-SHA-1 and
   HMAC-SHA-256-128.  The client signals the algorithm supported by it
   to the authorization server in the 'alg' parameter defined in
   [POP-KEY-DIST].  The authorization server determines the length of
   the mac_key based on the HMAC algorithm conveyed by the client.  If
   the client supports both HMAC-SHA-1 and HMAC-SHA-256-128, then it
   signals HMAC-SHA-256-128 to the authorization server, and gets a
   256-bit key from the authorization server, which can be used to
   compute both the HMAC-SHA-1 and HMAC-SHA-256-128 hashes. If the
   client only supports HMAC-SHA-1, the authorization server could
   return a 160-bit key, as keys longer than the HMAC-SHA-1 output
   size of 160-bits would not significantly increase the function's
   strength.

Notes:

The SHA-1 block size is 512 bits, so a 256-bit key does not need to be shortened to compute a HMAC-SHA-1 hash.

Also added an example for "if the client only supports HMAC-SHA-1", to make the hash agility logic more clear.

RFC 7636, "Proof Key for Code Exchange by OAuth Public Clients", September 2015

Source of RFC: oauth (sec)

Errata ID: 6179
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Dmitry Khlebnikov
Date Reported: 2020-05-18

Section 7.3 says:

7.3.  Salting the code_challenge

   To reduce implementation complexity, salting is not used in the
   production of the code challenge, as the code verifier contains
   sufficient entropy to prevent brute-force attacks.  Concatenating a
   publicly known value to a code verifier (containing 256 bits of
   entropy) and then hashing it with SHA256 to produce a code challenge
   would not increase the number of attempts necessary to brute force a
   valid value for code verifier.

   While the "S256" transformation is like hashing a password, there are
   important differences.  Passwords tend to be relatively low-entropy
   words that can be hashed offline and the hash looked up in a
   dictionary.  By concatenating a unique though public value to each
   password prior to hashing, the dictionary space that an attacker
   needs to search is greatly expanded.

   Modern graphics processors now allow attackers to calculate hashes in
   real time faster than they could be looked up from a disk.  This
   eliminates the value of the salt in increasing the complexity of a
   brute-force attack for even low-entropy passwords.

Notes:

The section misrepresents the information about "salting" and the whole idea
of "salting" is not applicable to a standalone hash. I suggest to drop the entire
section as irrelevant to the rest of the standard.

For some reason the section implies that "salting" is protecting and increasing
entropy of a single hash, which is not what "salting" is about and is not the
reason for the technique. The section is also making a speculative assumptions
about the low-entropy tendency in password hashes and makes an incorrect
conclusion on the benefits of "salting" for a password hash.

One could argue that the entropy and the complexity required to bruteforce a hash
and a salted hash for the same password (where the same hashing algorithm is
applied) are approximately the same in most cases (or just slightly more
complex for the salted version if the producer of the hash used a non-standard
routine in relation of mixing in the salt, e.g. instead of appending the salt
it inserts in in the middle of the password to be hashed). In any case, that
public data is already known to the attacker and it is just a matter of the
configuration for the bruteforcing tool (such as JohnTheRipper) to incorporate
the knowledge.

Just as an illustration: consider an example password ('abc'), an example salt
('123'), and that the hash is generated using a concatinated version of these
two (e.g. HASH('abc123')). Since the salt is included with the hash in plain
text, the bruteforcer would just need to set their tool up with the "^.*123$"
pattern making the salt essentially a string terminator which is not affecting
the bruteforce effort in any way).

More and more people I meet are confused about the problem area the "salting"
technique was invented to address: it is to increase the entropy of a set of
passwords, so the same password would not result in the same hash value, with
the primary goal is to prevent attackers to be able to re-use pre-calculated
hashes (e.g. rainbow hash tables) or, in the early stages of the attack, to
make it impossible to quickly assess what hashes the attacker should focus on
(e.g. when you have 1000 hashes and without salts you can easily spot that
some hashes are the same, which means breaking these one would gain much more
in comparison to unique hashes in the same set).

This being said, I am suggesting to drop section 7.3 completely as irrelevant,
since what we currently have is very confusing and seeds unnecessary and
wrong ideas that "salting" can improve the security of a single hash by itself.

Errata ID: 6471
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Tom Crossland
Date Reported: 2021-03-10

Section 7.1 says:

The client SHOULD create a "code_verifier" with a minimum of 256 bits
of entropy.  This can be done by having a suitable random number
generator create a 32-octet sequence.  The octet sequence can then be
base64url-encoded to produce a 43-octet URL safe string to use as a
"code_challenge" that has the required entropy.

It should say:

The client SHOULD create a "code_verifier" with a minimum of 256 bits
of entropy.  This can be done by having a suitable random number
generator create a 32-octet sequence.  The octet sequence can then be
base64url-encoded to produce a 43-octet URL safe string to use as a
"code_verifier" that has the required entropy.

Notes:

The "32-octet sequence" referenced in the original text seems to be inconsistent with Section 4.1, which states that the minimum length of the code_verifier is 43 characters. It would be consistent by changing "code_challenge" to "code_verifier".

RFC 7643, "System for Cross-domain Identity Management: Core Schema", September 2015

Source of RFC: scim (sec)

Errata ID: 4979
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: asgs
Date Reported: 2017-03-24

Section 8.5 says:

"location": "https://example.com/v2/ServiceProviderConfig",

It should say:

"location": "https://example.com/v2/ServiceProviderConfigs"

Notes:

Per the details provided on the SCIM website http://www.simplecloud.info/#overview, the endpoint should be /ServiceProviderConfigs. A trailing "s" is missing. The SCIM implementations of major service providers like Facebook, Salesforce, Slack implement /ServiceProviderConfigs

Also, it would be better to replace all occurrences of the word "ServiceProviderConfig" with "ServiceProviderConfigs" wherever applicable, so as to remain sync with the endpoint.

Errata ID: 5368
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Brendan McCollam
Date Reported: 2018-05-24

Section 8.7.1 says:

  {
    "id" : "urn:ietf:params:scim:schemas:core:2.0:Group",
    "name" : "Group",
    "description" : "Group",
    "attributes" : [
      {
        "name" : "displayName",
        "type" : "string",
        "multiValued" : false,
        "description" : "A human-readable name for the Group.
REQUIRED.",
        "required" : false,
        "caseExact" : false,
        "mutability" : "readWrite",
        "returned" : "default",
        "uniqueness" : "none"
      },

It should say:

  {
    "id" : "urn:ietf:params:scim:schemas:core:2.0:Group",
    "name" : "Group",
    "description" : "Group",
    "attributes" : [
      {
        "name" : "displayName",
        "type" : "string",
        "multiValued" : false,
        "description" : "A human-readable name for the Group.
REQUIRED.",
        "required" : true,
        "caseExact" : false,
        "mutability" : "readWrite",
        "returned" : "default",
        "uniqueness" : "none"
      },

Notes:

On page 68, in the JSON example schema for the Group resource, the displayName attribute is highlighted as REQUIRED in the "description" but the value of the "required" field is false. Given that section 4.2 also indicates displayName is a required attribute for Group resources, I believe the conflict in section 8.7.1 is best corrected by changing the value of the "required" attribute to true.

Errata ID: 5606
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Takashi Kato
Date Reported: 2019-01-16

Section 8.7.1 says:

          {
            "name" : "type",
            "type" : "string",
            "multiValued" : false,
            "description" : "The attribute's data type.
              Valid values include 'string', 'complex', 'boolean',
              'decimal', 'integer', 'dateTime', 'reference'.",
            "required" : true,
            "canonicalValues" : [
              "string",
              "complex",
              "boolean",
              "decimal",
              "integer",
              "dateTime",
              "reference"
            ],
            "caseExact" : false,
            "mutability" : "readOnly",
            "returned" : "default",
            "uniqueness" : "none"
          },

It should say:

          {
            "name" : "type",
            "type" : "string",
            "multiValued" : false,
            "description" : "The attribute's data type.
              Valid values include 'string', 'complex', 'boolean',
              'decimal', 'integer', 'dateTime', 'reference', 'binary'.",
            "required" : true,
            "canonicalValues" : [
              "string",
              "complex",
              "boolean",
              "decimal",
              "integer",
              "dateTime",
              "reference",
              "binary"
            ],
            "caseExact" : false,
            "mutability" : "readOnly",
            "returned" : "default",
            "uniqueness" : "none"
          },

Notes:

On page 83, the "canonicalValues" definition of "type" attribute missing "binary".

Errata ID: 5607
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Takashi Kato
Date Reported: 2019-01-16

Section 8.7.2 says:

              {
                "name" : "referenceTypes",
                "type" : "string",
                "multiValued" : false,
                "description" : "Used only with an attribute of type
                  'reference'.  Specifies a SCIM resourceType that a
                  reference attribute MAY refer to, e.g., 'User'.",
                "required" : false,
                "caseExact" : true,
                "mutability" : "readOnly",
                "returned" : "default",
                "uniqueness" : "none"
              }

It should say:

              {
                "name" : "referenceTypes",
                "type" : "string",
                "multiValued" : true,
                "description" : "Used only with an attribute of type
                  'reference'.  Specifies a SCIM resourceType that a
                  reference attribute MAY refer to, e.g., 'User'.",
                "required" : false,
                "caseExact" : true,
                "mutability" : "readOnly",
                "returned" : "default",
                "uniqueness" : "none"
              }

Notes:

On page 90, the multiValued of resourceTypes should be true.

Errata ID: 5999
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Shelley Baker
Date Reported: 2020-03-02

Section 8.7.1 says:

"id" : "urn:ietf:params:scim:schemas:core:2.0:User",
"name" : "User",
"description" : "User Account",

"id" : "urn:ietf:params:scim:schemas:core:2.0:Group",
"name" : "Group",
"description" : "Group",

"id" : "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User",
"name" : "EnterpriseUser",
"description" : "Enterprise User"

It should say:

"schemas": ["urn:ietf:params:scim:schemas:core:2.0:Schema"],
"id" : "urn:ietf:params:scim:schemas:core:2.0:User",
"name" : "User",
"description" : "User Account",

"schemas": ["urn:ietf:params:scim:schemas:core:2.0:Schema"],
"id" : "urn:ietf:params:scim:schemas:core:2.0:Group",
"name" : "Group",
"description" : "Group",

"schemas": ["urn:ietf:params:scim:schemas:core:2.0:Schema"],
"id" : "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User",
"name" : "EnterpriseUser",
"description" : "Enterprise User"

Notes:

The "schemas" attribute is missing from the example JSON representation schema resources. According to Sections 2.1 and Section 3, the "schemas" attribute is a REQUIRED and MUST be provided.

Errata ID: 6000
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Shelley Baker
Date Reported: 2020-03-02

Section 8.7.1 says:

      {
        "name" : "x509Certificates",
        "type" : "complex",
        "multiValued" : true,
        "description" : "A list of certificates issued to the User.",
        "required" : false,
        "caseExact" : false,
        "subAttributes" : [
          {
            "name" : "value",
            "type" : "binary",
            "multiValued" : false,
            "description" : "The value of an X.509 certificate.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readWrite",
            "returned" : "default",
            "uniqueness" : "none"
          },

It should say:

      {
        "name" : "x509Certificates",
        "type" : "complex",
        "multiValued" : true,
        "description" : "A list of certificates issued to the User.",
        "required" : false,
        "caseExact" : false,
        "subAttributes" : [
          {
            "name" : "value",
            "type" : "binary",
            "multiValued" : false,
            "description" : "The value of an X.509 certificate.",
            "required" : false,
            "caseExact" : true,
            "mutability" : "readWrite",
            "returned" : "default",
            "uniqueness" : "none"
          },

Notes:

Section 2.3.6 indicates that "binary is case exact." The "x509Certificates" binary "value" subattribute's "caseExact" characteristic is currently listed as "false", but should be "true".

Errata ID: 6001
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Shelley Baker
Date Reported: 2020-03-02

Section 8.7.1 says:

      {
        "name" : "profileUrl",
        "type" : "reference",
        "referenceTypes" : ["external"],
        "multiValued" : false,
        "description" : "A fully qualified URL pointing to a page representing the User's online profile.",
        "required" : false,
        "caseExact" : false,
        "mutability" : "readWrite",
        "returned" : "default",
        "uniqueness" : "none"
      },


      {
        "name" : "photos",
        "type" : "complex",
        "multiValued" : true,
        "description" : "URLs of photos of the User.",
        "required" : false,
        "subAttributes" : [
          {
            "name" : "value",
            "type" : "reference",
            "referenceTypes" : ["external"],
            "multiValued" : false,
            "description" : "URL of a photo of the User.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readWrite",
            "returned" : "default",
            "uniqueness" : "none"
          },


          {
            "name" : "$ref",
            "type" : "reference",
            "referenceTypes" : [
              "User",
              "Group"
            ],
            "multiValued" : false,
            "description" : "The URI of the corresponding 'Group' resource to which the user belongs.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readOnly",
            "returned" : "default",
            "uniqueness" : "none"
          },

It should say:

      {
        "name" : "profileUrl",
        "type" : "reference",
        "referenceTypes" : ["external"],
        "multiValued" : false,
        "description" : "A fully qualified URL pointing to a page representing the User's online profile.",
        "required" : false,
        "caseExact" : true,
        "mutability" : "readWrite",
        "returned" : "default",
        "uniqueness" : "none"
      },


      {
        "name" : "photos",
        "type" : "complex",
        "multiValued" : true,
        "description" : "URLs of photos of the User.",
        "required" : false,
        "subAttributes" : [
          {
            "name" : "value",
            "type" : "reference",
            "referenceTypes" : ["external"],
            "multiValued" : false,
            "description" : "URL of a photo of the User.",
            "required" : false,
            "caseExact" : true,
            "mutability" : "readWrite",
            "returned" : "default",
            "uniqueness" : "none"
          },


          {
            "name" : "$ref",
            "type" : "reference",
            "referenceTypes" : [
              "User",
              "Group"
            ],
            "multiValued" : false,
            "description" : "The URI of the corresponding 'Group' resource to which the user belongs.",
            "required" : false,
            "caseExact" : true,
            "mutability" : "readOnly",
            "returned" : "default",
            "uniqueness" : "none"
          },

Notes:

Section 2.3.7 indicates that "A reference is case exact." Section 8.7.1 defines a number of "reference" attributes that incorrectly have the "caseExact" characteristic set to "false"; these should instead be "true."

Errata ID: 6004
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Shelley Baker
Date Reported: 2020-03-03

Section 8.7.1 says:

      {
        "name" : "name",
        "type" : "complex",
        ...
        "uniqueness" : "none"
      },
      ...
      {
        "name" : "emails",
        "type" : "complex",
        ...
        "uniqueness" : "none"
      },
      ...
      {
        "name" : "addresses",
        "type" : "complex",
        ...
        "uniqueness" : "none"
      },

It should say:

      {
        "name" : "name",
        "type" : "complex",
        ...
      },
      ...
      {
        "name" : "emails",
        "type" : "complex",
        ...
      },
      ...
      {
        "name" : "addresses",
        "type" : "complex",
        ...
      },

Notes:

The "emails", "name", and "addresses" complex user attributes have a "uniqueness" characteristic defined. According to Section 2.3.8, complex attributes have no uniqueness. No other complex attributes in Section 8.7.1 specify a "uniqueness" characteristic. For compliance with Section 2.3.8 and consistency with other attribute definitions, the "uniqueness" sub-attribute for these complex attributes should be removed.

Errata ID: 6007
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Shelley Baker
Date Reported: 2020-03-04

Section 8.7.1 says:

      {
        "name" : "preferredLanguage",
        "type" : "string",
        "multiValued" : false,
        "description" : "Indicates the User's preferred written or
spoken language.  Generally used for selecting a localized user
interface; e.g., 'en_US' specifies the language English and country
US.",
        "required" : false,
        "caseExact" : false,
        "mutability" : "readWrite",
        "returned" : "default",
        "uniqueness" : "none"
      },

It should say:

      {
        "name" : "preferredLanguage",
        "type" : "string",
        "multiValued" : false,
        "description" : "Indicates the User's preferred written or
spoken language.  Generally used for selecting a localized user
interface; e.g., 'en-US' specifies the language English and country
US.",
        "required" : false,
        "caseExact" : false,
        "mutability" : "readWrite",
        "returned" : "default",
        "uniqueness" : "none"
      },

Notes:

The "preferredLanguage" attribute, as defined in Section 4.1.1, follows RFC 7231's "Accept-Language" format, where "en_US" would not be syntactically valid, since language tags are separated by hyphens, not underscores.

Errata ID: 6011
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Shelley Baker
Date Reported: 2020-03-09

Section 8.7.1 says:

      {
        "name" : "members",
        "type" : "complex",
        "multiValued" : true,
        "description" : "A list of members of the Group.",
        "required" : false,
        "subAttributes" : [
          {
            "name" : "value",
            "type" : "string",
            "multiValued" : false,
            "description" : "Identifier of the member of this Group.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "immutable",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "$ref",
            "type" : "reference",
            "referenceTypes" : [
              "User",
              "Group"
            ],
            "multiValued" : false,
            "description" : "The URI corresponding to a SCIM resource
that is a member of this Group.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "immutable",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "type",
            "type" : "string",
            "multiValued" : false,
            "description" : "A label indicating the type of resource,
e.g., 'User' or 'Group'.",
            "required" : false,
            "caseExact" : false,
            "canonicalValues" : [
              "User",
              "Group"
            ],
            "mutability" : "immutable",
            "returned" : "default",
            "uniqueness" : "none"
          }
        ],
        "mutability" : "readWrite",
        "returned" : "default"
      }

It should say:

      {
        "name" : "members",
        "type" : "complex",
        "multiValued" : true,
        "description" : "A list of members of the Group.",
        "required" : false,
        "subAttributes" : [
          {
            "name" : "value",
            "type" : "string",
            "multiValued" : false,
            "description" : "Identifier of the member of this Group.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "immutable",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "$ref",
            "type" : "reference",
            "referenceTypes" : [
              "User",
              "Group"
            ],
            "multiValued" : false,
            "description" : "The URI corresponding to a SCIM resource
that is a member of this Group.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "immutable",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "type",
            "type" : "string",
            "multiValued" : false,
            "description" : "A label indicating the type of resource,
e.g., 'User' or 'Group'.",
            "required" : false,
            "caseExact" : false,
            "canonicalValues" : [
              "User",
              "Group"
            ],
            "mutability" : "immutable",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name": "display",
            "type": "string",
            "multiValued": false,
            "description": "A human-readable name for the group member, primarily used for display purposes.",
            "required": false,
            "caseExact": false,
            "mutability": "readOnly",
            "returned": "default",
            "uniqueness": "none"
          }
        ],
        "mutability" : "readWrite",
        "returned" : "default"
      }

Notes:

The group "members" attribute should define a "display" sub-attribute.

* Section 2.4 defines a standard multi-valued read-only attribute of "display".
* The Group Representation example in Section 8.4 also includes the "members.display" sub-attribute.
* This discussion in the SCIM mailing list [1] also indicates that this should be fixed.

[1] https://mailarchive.ietf.org/arch/msg/scim/EH99Gxn-hDluihMNtWLIekuFCs8/

Errata ID: 6403
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Andrew Webb
Date Reported: 2021-01-21

Section 4.3 says:

      value  The "id" of the SCIM resource representing the user's
         manager.  RECOMMENDED.

      $ref  The URI of the SCIM resource representing the User's
         manager.  RECOMMENDED.

It should say:

      value  The "id" of the SCIM resource representing the user's
         manager.  REQUIRED.

      $ref  The URI of the SCIM resource representing the User's
         manager.  REQUIRED.

Notes:

The descriptions of the sub-attributes "value" and "$ref" on pages 71 and 72 indicate that these two are required, not recommended.

E.g. "The id of the SCIM resource representing
the User's manager. REQUIRED."

Given that no other value in the RFC is RECOMMENDED, it would seem likely that these two sub-sttributes should be REQUIRED and not RECOMMENDED.

Errata ID: 7522
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Leonardo Speranzon
Date Reported: 2023-05-23

Section 8.7.2 says:

{
        "name" : "schemaExtensions",
        "type" : "complex",
        "multiValued" : false,
        "description" : "A list of URIs of the resource type's schema
          extensions.",
        "required" : true,
        "mutability" : "readOnly",
        "returned" : "default",
        "subAttributes" : [
          {
            "name" : "schema",
            "type" : "reference",
            "referenceTypes" : ["uri"],
            "multiValued" : false,
            "description" : "The URI of a schema extension.",
            "required" : true,
            "caseExact" : true,
            "mutability" : "readOnly",
            "returned" : "default",
            "uniqueness" : "none"
          },

It should say:

{
        "name" : "schemaExtensions",
        "type" : "complex",
        "multiValued" : true,
        "description" : "A list of URIs of the resource type's schema
          extensions.",
        "required" : true,
        "mutability" : "readOnly",
        "returned" : "default",
        "subAttributes" : [
          {
            "name" : "schema",
            "type" : "reference",
            "referenceTypes" : ["uri"],
            "multiValued" : false,
            "description" : "The URI of a schema extension.",
            "required" : true,
            "caseExact" : true,
            "mutability" : "readOnly",
            "returned" : "default",
            "uniqueness" : "none"
          },

Notes:

The description of "schemaExtensions" say that it is a list and also its name is plural. This contradict the value of "multiValued" setted to false. I believe that the "multiValued" attribute should be setted to "true".

Errata ID: 6005
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Shelley Baker
Date Reported: 2020-03-03

Section 8.7.1 says:

      {
        "name" : "addresses",
        "type" : "complex",
        "multiValued" : true,
        "description" : "A physical mailing address for this User. Canonical type values of 'work', 'home', and 'other'.  This attribute is a complex type with the following sub-attributes.",
        "required" : false,
        "subAttributes" : [
          {
            "name" : "formatted",
            "type" : "string",
            "multiValued" : false,
            "description" : "The full mailing address, formatted for display or use with a mailing label.  This attribute MAY contain newlines.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readWrite",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "streetAddress",
            "type" : "string",
            "multiValued" : false,
            "description" : "The full street address component, which may include house number, street name, P.O. box, and multi-line extended street address information.  This attribute MAY contain newlines.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readWrite",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "locality",
            "type" : "string",
            "multiValued" : false,
            "description" : "The city or locality component.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readWrite",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "region",
            "type" : "string",
            "multiValued" : false,
            "description" : "The state or region component.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readWrite",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "postalCode",
            "type" : "string",
            "multiValued" : false,
            "description" : "The zip code or postal code component.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readWrite",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "country",
            "type" : "string",
            "multiValued" : false,
            "description" : "The country name component.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readWrite",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "type",
            "type" : "string",
            "multiValued" : false,
            "description" : "A label indicating the attribute's function, e.g., 'work' or 'home'.",
            "required" : false,
            "caseExact" : false,
            "canonicalValues" : [
              "work",
              "home",
              "other"
            ],
            "mutability" : "readWrite",
            "returned" : "default",
            "uniqueness" : "none"
          }
        ],
        "mutability" : "readWrite",
        "returned" : "default",
        "uniqueness" : "none"
      },

It should say:

      {
        "name" : "addresses",
        "type" : "complex",
        "multiValued" : true,
        "description" : "A physical mailing address for this User. Canonical type values of 'work', 'home', and 'other'.  This attribute is a complex type with the following sub-attributes.",
        "required" : false,
        "subAttributes" : [
          {
            "name" : "formatted",
            "type" : "string",
            "multiValued" : false,
            "description" : "The full mailing address, formatted for display or use with a mailing label.  This attribute MAY contain newlines.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readWrite",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "streetAddress",
            "type" : "string",
            "multiValued" : false,
            "description" : "The full street address component, which may include house number, street name, P.O. box, and multi-line extended street address information.  This attribute MAY contain newlines.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readWrite",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "locality",
            "type" : "string",
            "multiValued" : false,
            "description" : "The city or locality component.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readWrite",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "region",
            "type" : "string",
            "multiValued" : false,
            "description" : "The state or region component.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readWrite",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "postalCode",
            "type" : "string",
            "multiValued" : false,
            "description" : "The zip code or postal code component.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readWrite",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "country",
            "type" : "string",
            "multiValued" : false,
            "description" : "The country name component.",
            "required" : false,
            "caseExact" : false,
            "mutability" : "readWrite",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "type",
            "type" : "string",
            "multiValued" : false,
            "description" : "A label indicating the attribute's function, e.g., 'work' or 'home'.",
            "required" : false,
            "caseExact" : false,
            "canonicalValues" : [
              "work",
              "home",
              "other"
            ],
            "mutability" : "readWrite",
            "returned" : "default",
            "uniqueness" : "none"
          },
          {
            "name" : "primary",
            "type" : "boolean",
            "multiValued" : false,
            "description" : "A Boolean value indicating the 'primary' or preferred attribute value for this attribute, e.g., the preferred mailing address.  The primary attribute value 'true' MUST appear no more than once.",
            "required" : false,
            "mutability" : "readWrite",
            "returned" : "default"
          }
        ],
        "mutability" : "readWrite",
        "returned" : "default",
        "uniqueness" : "none"
      },

Notes:

The "addresses" user attribute should specify a "primary" sub-attribute. "addresses" is a multi-valued attribute. According to Section 2.4, multi-valued attributes include a "primary" sub-attribute. The "primary" sub-attribute text even mentions this attribute's use for mailing "addresses."

Errata ID: 6727
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Will Springer
Date Reported: 2021-10-28

Section 8.7.2 says:

      {
        "name" : "description",
        "type" : "string",
        "multiValued" : false,
        "description" : "The schema's human-readable name.  When
          applicable, service providers MUST specify the name,
          e.g., 'User'.",
        "required" : false,
        "caseExact" : false,
        "mutability" : "readOnly",
        "returned" : "default",
        "uniqueness" : "none"
      },

It should say:

      {
        "name" : "description",
        "type" : "string",
        "multiValued" : false,
        "description" : "The schema's human-readable description.  When
          applicable, service providers MUST specify the description.",
        "required" : false,
        "caseExact" : false,
        "mutability" : "readOnly",
        "returned" : "default",
        "uniqueness" : "none"
      },

Notes:

The previous description was that for the "name" attribute. Updated to the standard text for the "description" attribute.

RFC 7644, "System for Cross-domain Identity Management: Protocol", September 2015

Source of RFC: scim (sec)

Errata ID: 4670
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Vassilis Michalitsis
Date Reported: 2016-04-15

Section 3.4.2.2 says:

Filters MUST be evaluated using the following order of operations, in
   order of precedence:

   1.  Grouping operators

   2.  Logical operators - where "not" takes precedence over "and",
       which takes precedence over "or"

   3.  Attribute operators

It should say:

Filters MUST be evaluated using the following order of operations, in
   order of precedence:

   1.  Grouping operators

   2.  Attribute operators

   3.  Logical operators - where "not" takes precedence over "and",
       which takes precedence over "or"

Notes:

It seems that the precedence of logical and attribute precedence is reversed? The filter filter=title sw "M" and userType eq "Employee" is meant to be interpreted as filter=(title sw "M") and (userType eq "Employee").
This is also the "expected" behaviour consistent with most other languages - with the notable exception of unary "or" which in SCIM is disambiguated as it can only apply to a parenthesized filter expression.

Errata ID: 4690
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Phil Hunt
Date Reported: 2016-05-10

Section 3.4.2.2 says:

valFilter = attrExp / logExp / *1"not" "(" valFilter ")"

It should say:

valFilter = attrExp / valLogExp / *1"not" "(" valFilter ")"

valLogExp = attrExp SP ("and" / "or") SP attrExp

Notes:

Figure 1 contains the ABNF for SCIM filters. The term "logExp" specifies "FILTER" as an option which unintentionally allows recursion. A valFilter should only allow simple sub-attribute expressions and simple logic. Nesting of valuePath (e.g. attr[a eq b and attr[c eq d]]) should not be possible.

Errata ID: 4978
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: asgs
Date Reported: 2017-03-24

Section 4 says:

/ServiceProviderConfig

It should say:

/ServiceProviderConfigs

Notes:

Per the details provided on the SCIM website http://www.simplecloud.info/#overview, the endpoint should be /ServiceProviderConfigs. A trailing "s" is missing. The SCIM implementations of major service providers like Facebook, Salesforce, Slack implement /ServiceProviderConfigs

Errata ID: 5050
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Phil Hunt
Date Reported: 2017-06-23

Section 3.7.3 says:

       {
         "method": "PATCH",
         "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
         "version": "W/\"edac3253e2c0ef2\"",
         "data": {[
           {
               "op": "remove",
               "path": "nickName"
           },
           {
               "op": "add",
               "path": "userName",
               "value": "Dave"
           }
         ]}
       },

It should say:

       {
         "method": "PATCH",
         "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
         "version": "W/\"edac3253e2c0ef2\"",
         "data": {
           "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
           "Operations": [
               {
                  “schemas”:["
                  "op": "remove",
                  "path": "nickName"
               },
               {
                  "op": "add",
                  "path": "userName",
                  "value": "Dave"
               }
           ]
         }
       },

Notes:

The example figure is incorrect. It should show the actual patch operation request body in the JSON attribute "data" as it would be expressed in its own HTTP request payload. Instead it shows the values of the "operations" attribute. See sec 3.7 definition of "data".

Errata ID: 5295
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Marcel van den Dungen
Date Reported: 2018-03-22

Section 3.5.2.1 says:

If the user was already a member of this group, no changes should be
made to the resource, and a success response should be returned.
The server responds with either the entire updated Group or no
response body:

   HTTP/1.1 204 No Content
   Authorization: Bearer h480djs93hd8
   ETag: W/"b431af54f0671a2"
   Location:
   "https://example.com/Groups/acbf3ae7-8463-...-9b4da3f908ce"

It should say:

If the user was already a member of this group, no changes should be
made to the resource, and a success response should be returned.
The server responds with either the entire updated Group or no
response body:

   HTTP/1.1 204 No Content
   ETag: W/"b431af54f0671a2"

Notes:

The Authorization header is a request header and should not be included in a response.
The Location header is used to redirect a client to a new location or indicate the location of a new resource. Neither is the case here, so the header should be omitted.

Also, it's unclear from the text whether it's valid to respond with 204 No Content if the user was successfully added to the group.

Errata ID: 6010
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Shelley Baker
Date Reported: 2020-03-09

Section 4 says:

"totalResults":2,
"itemsPerPage":10,

It should say:

"totalResults":2,
"itemsPerPage":2,

Notes:

Per Section 3.4.2.4, "itemsPerPage" specifies the number of query results returned in a page. In Section 4 Figure 9, the page contains only 2 items, so the "itemsPerPage" should be 2 not 10.

Errata ID: 7319
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: James Linnell
Date Reported: 2023-01-25

Section 3.4.2.2 says:

     FILTER    = attrExp / logExp / valuePath / *1"not" "(" FILTER ")"

     valuePath = attrPath "[" valFilter "]"
                 ; FILTER uses sub-attributes of a parent attrPath

     valFilter = attrExp / logExp / *1"not" "(" valFilter ")"

It should say:

     FILTER    = attrExp / logExp / valuePath / *1("not" SP) "(" FILTER ")"

     valuePath = attrPath "[" valFilter "]"
                 ; FILTER uses sub-attributes of a parent attrPath

     valFilter = attrExp / logExp / *1("not" SP) "(" valFilter ")"

Notes:

Note the following example filter listed further down in section 3.4.2.2:

filter=userType ne "Employee" and not (emails co "example.com" or
emails.value co "example.org")

There is a space between the "not" and the opening parenthesis, which is not allowed in the listed ABNF grammar. The corrected text includes a mandatory space between these two tokens.

It may be desired to use `*1("not" *1SP) "("` instead, for backwards compatibility reasons. This would allow for an optional space after a "not" keyword. Or, it may be desired to instead edit the example to remove the space, preserving the original intent of the listed grammar.

Errata ID: 7322
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: James Linnell
Date Reported: 2023-01-26

Section 3.4.2.2 says:

    valFilter = attrExp / logExp / *1"not" "(" valFilter ")"

It should say:

    valFilter = attrExp / valLogExp / *1"not" "(" valFilter ")"

    valLogExp = valFilter SP ("and" / "or") SP valFilter

Notes:

This is a correction to Errata 4690 for this RFC. Errata 4690 introduced the following `valLogExp`:

valLogExp = attrExp SP ("and" / "or") SP attrExp

However, this fails to allow the following filter expression:

emails[type eq "work" or (type eq "home" and value ew "@example.com")]

because 4690's `valLogExp`'s recursion into `attrExp` would not allow for the parenthetical expression. The fixed `valLogExp` correctly recurs back into `valFilter` to allow for an `attrExp`, or a joined `logExp`, or a parenthtical.

While this example is not in the list of other exceptions in Section 3.4.2.2, the original use of `logExp` and the recurred `FILTER` would suggest that this example is within the original intent of the document.

RFC 7659, "Definitions of Managed Objects for Network Address Translators (NATs)", October 2015

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 5705
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Igor Ryzhov
Date Reported: 2019-04-25

Section 4 says:

This notification is triggered when an address pool's usage
becomes less than or equal to the value of the
natv2PoolThresholdUsageLow object for that pool, unless the
notification has been disabled by setting the value of the
threshold to -1.  It is reported subject to the rate
limitation specified by natv2PortMapNotificationInterval.

It should say:

This notification is triggered when an address pool's usage
becomes less than or equal to the value of the
natv2PoolThresholdUsageLow object for that pool, unless the
notification has been disabled by setting the value of the
threshold to -1.  It is reported subject to the rate
limitation specified by natv2PoolNotificationInterval.

Notes:

Description is pointing on nonexistent object natv2PortMapNotificationInterval. It should be natv2PoolNotificationInterval.

Errata ID: 5706
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Igor Ryzhov
Date Reported: 2019-04-25

Section 4 says:

This notification is triggered when an address pool's usage
becomes greater than or equal to the value of the
natv2PoolThresholdUsageHigh object for that pool, unless
the notification has been disabled by setting the value of
the threshold to -1.  It is reported subject to the rate
limitation specified by natv2PortMapNotificationInterval.

It should say:

This notification is triggered when an address pool's usage
becomes greater than or equal to the value of the
natv2PoolThresholdUsageHigh object for that pool, unless
the notification has been disabled by setting the value of
the threshold to -1.  It is reported subject to the rate
limitation specified by natv2PoolNotificationInterval.

Notes:

Description is pointing on nonexistent object natv2PortMapNotificationInterval. It should be natv2PoolNotificationInterval.

RFC 7662, "OAuth 2.0 Token Introspection", October 2015

Source of RFC: oauth (sec)

Errata ID: 7607
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Fulong Sun
Date Reported: 2023-08-17

Section 2.2 says:

a given token has been issued by this authorization server, has not been revoked by the resource owner, and is within its given time window of validity

It should say:

a given token has been issued by this authorization server, has not been revoked by the resource owner or client, and is within its given time window of validity

Notes:

RFC 7009 defined a given token can be revoke by client, so should write client here.

RFC 7683, "Diameter Overload Indication Conveyance", October 2015

Note: This RFC has been updated by RFC 8581

Source of RFC: dime (ops)

Errata ID: 5277
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Lionel Morand
Date Reported: 2018-03-06

Section 7.2 says:

7.2.  OC-Feature-Vector AVP

   The OC-Feature-Vector AVP (AVP Code 622) is of type Unsigned64 and
   contains a 64-bit flags field of announced capabilities of a DOIC
   node.  The value of zero (0) is reserved.

   The OC-Feature-Vector sub-AVP is used to announce the DOIC features
   supported by the DOIC node, in the form of a flag-bits field in which
   each bit announces one feature or capability supported by the node.
   The absence of the OC-Feature-Vector AVP in request messages
   indicates that only the default traffic abatement algorithm described
   in this specification is supported.  The absence of the OC-Feature-
   Vector AVP in answer messages indicates that the default traffic
   abatement algorithm described in this specification is selected
   (while other traffic abatement algorithms may be supported), and no
   features other than abatement algorithms are supported.


   The following capability is defined in this document:

   OLR_DEFAULT_ALGO (0x0000000000000001)

      When this flag is set by the a DOIC reacting node, it means that
      the default traffic abatement (loss) algorithm is supported.  When
      this flag is set by a DOIC reporting node, it means that the loss
      algorithm will be used for requested overload abatement.

It should say:

7.2.  OC-Feature-Vector AVP

   The OC-Feature-Vector AVP (AVP Code 622) is of type Unsigned64 and
   contains a 64-bit flags field of announced capabilities of a DOIC
   node.  The value of zero (0) is reserved.

      Note: The value of zero (0) any DOIC node supports at least the 
            Loss algorithm. Therefore, the OC-Feature-Vector AVP 
            cannot be sent with no bit set.

   The OC-Feature-Vector sub-AVP is used to announce the DOIC features
   supported by the DOIC node, in the form of a flag-bits field in which
   each bit announces one feature or capability supported by the node.
   The absence of the OC-Feature-Vector AVP in request messages
   indicates that only the default traffic abatement algorithm described
   in this specification is supported.  The absence of the OC-Feature-
   Vector AVP in answer messages indicates that the default traffic
   abatement algorithm described in this specification is selected
   (while other traffic abatement algorithms may be supported), and no
   features other than abatement algorithms are supported.

   The following capability is defined in this document:

+---+------------------+----------------------------------------------+
|bit|  Feature Name    |  Description                                 |
+---+------------------+----------------------------------------------+
| 0 | OLR_DEFAULT_ALGO |When set by a DOIC reacting node, it means    |
|   |                  |that the default traffic abatement (loss)     |
|   |                  |algorithm is supported. When set by a DOIC    |
|   |                  |reporting node, it means that the loss        |
|   |                  |algorithm will be used for requested overload |
|   |                  |abatment.                                     |
+---+------------------+----------------------------------------------+

Notes:

The OC-Feature-Vector AVP is a 64-bit flag field and not a set of values (one per feature). Using the hexadecimal notation, it gives the feeling that there is a unique value for the OC-Feature-Vector AVP per supported capability, hich is incorrect. It is only required to define the use of each bit. This errata report has an impact on the associated IANA regisrty.

Errata ID: 5278
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Lionel Morand
Date Reported: 2018-03-06
Edited by: Robert Wilton
Date Edited: 2024-01-12

Section 9.2 says:

9.2.  New Registries

   Two new registries have been created in the "AVP Specific Values"
   sub-registry under the "Authentication, Authorization, and Accounting
   (AAA) Parameters" registry.

   A new "OC-Feature-Vector AVP Values (code 622)" registry has been
   created.  This registry contains the following:

      Feature Vector Value Name

      Feature Vector Value

      Specification defining the new value

   See Section 7.2 for the initial Feature Vector Value in the registry.
   This specification defines the value.  New values can be added to the
   registry using the Specification Required policy [RFC5226].

   A new "OC-Report-Type AVP Values (code 626)" registry has been
   created.  This registry contains the following:

      Report Type Value Name

      Report Type Value

      Specification defining the new value

   See Section 7.6 for the initial assignment in the registry.  New
   types can be added using the Specification Required policy [RFC5226].

It should say:

9.2.  New Registries

   Two new registries have been created in the "AVP Specific Values"
   sub-registry under the "Authentication, Authorization, and Accounting
   (AAA) Parameters" registry.

   A new "OC-Feature-Vector AVP Values (code 622)" registry has been
   created.  This registry contains the following:

      Assigned Bit

      Feature Name

      Specification defining the new capability

   See Section 7.2 for the initial assigned bit in the registry.
   This specification defines the capbility announced by the setting of 
   this bit.  New values can be added to the registry using the 
   Specification Required policy [RFC5226].

   A new "OC-Report-Type AVP Values (code 626)" registry has been
   created.  This registry contains the following:

      Report Type Value Name

      Report Type Value

      Specification defining the new value

   See Section 7.6 for the initial assignment in the registry.  New
   types can be added using the Specification Required policy [RFC5226].

Notes:

This errata report is linked to the following errata report: Errata ID: 5277
The IANA registry created for the OC-Feature-Vector AVP Values (code 622) should only describe the use of the bit assigned to a given feature. There is no AVP value assigned to a given feature. The associated IANA registry should provide a table describing the setting of the bit assigned to a given feature/capability.

RFC 7686, "The ".onion" Special-Use Domain Name", October 2015

Source of RFC: dnsop (ops)

Errata ID: 6761
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter van Dijk
Date Reported: 2021-11-29

Section 2 says:

   5.  Authoritative DNS Servers: Authoritative servers MUST respond to
       queries for .onion with NXDOMAIN.

   6.  DNS Server Operators: Operators MUST NOT configure an
       authoritative DNS server to answer queries for .onion.  If they
       do so, client software is likely to ignore any results (see
       above).

It should say:

   5.  Authoritative DNS Servers: Authoritative servers MUST respond non-authoritatively to
       queries for names in .onion.

   6.  DNS Server Operators: Operators MUST NOT configure an
       authoritative DNS server to answer authoritatively to queries for names in .onion.  If they
       do so, client software is likely to ignore any results (see
       above).

Notes:

The original text for 5 and 6 is conflicting. A name server cannot respond with NXDOMAIN (which is an authoritative answer) without having a zone configured to serve that NXDOMAIN from. Clearly the intent of the text is that clients will not find authoritative answers to .onion queries anywhere in the DNS.

RFC 7692, "Compression Extensions for WebSocket", December 2015

Source of RFC: hybi (art)

Errata ID: 4982
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Straver
Date Reported: 2017-03-28

Section 7.1.1.1 says:

A server MAY include the "server_no_context_takeover" extension
parameter in an extension negotiation response even if the extension
negotiation offer being accepted by the extension negotiation
response didn't include the "server_no_context_takeover" extension
parameter.

It should say:

A server MAY include the "server_no_context_takeover" extension
parameter in an extension negotiation response even if the extension
negotiation offer being accepted by the extension negotiation
response didn't include the "server_no_context_takeover" extension
parameter.
A client SHOULD treat the "server_no_context_takeover" extension
parameter in an extension negotiation response as a hint with no
requirement to provide an implementation, and MUST NOT treat this
parameter, if included in the response, as an invalid configuration.

Notes:

It is currently possible for a client and a server to implement per spec and fail to make a connection.

There is no requirement for a client to implement this purely optional parameter, nor to understand this parameter if not implemented. If not supported, this would result in an invalid configuration. As a result, point 7 mandates that the socket connection MUST be closed.
This will only occur if a client has no implementation for this parameter and does not understand/accept the parameter, and the server sends an unsolicited "server_no_context_takeover" parameter in its response, which is allowed.

RFC 7700, "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames", December 2015

Note: This RFC has been obsoleted by RFC 8266

Source of RFC: precis (art)

Errata ID: 4570
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Sam Whited
Date Reported: 2015-12-23

Section 2.3 says:

An entity that performs enforcement according to this profile MUST
   prepare a string as described in Section 2.2 and MUST also apply the
   following rules specified in Section 2.1 in the order shown:

   1.  Additional Mapping Rule
   2.  Normalization Rule
   3.  Directionality Rule

   After all of the foregoing rules have been enforced, the entity MUST
   ensure that the nickname is not zero bytes in length (this is done
   after enforcing the rules to prevent applications from mistakenly
   omitting a nickname entirely, because when internationalized
   characters are accepted, a non-empty sequence of characters can
   result in a zero-length nickname after canonicalization).

It should say:

An entity that performs enforcement according to this profile MUST
   prepare a string as described in Section 2.2 and MUST also apply the
   following rules specified in Section 2.1 in the order shown:

   1.  Additional Mapping Rule
   2.  Case Mapping Rule
   3.  Normalization Rule

   After all of the foregoing rules have been enforced, the entity MUST
   ensure that the nickname is not zero bytes in length (this is done
   after enforcing the rules to prevent applications from mistakenly
   omitting a nickname entirely, because when internationalized
   characters are accepted, a non-empty sequence of characters can
   result in a zero-length nickname after canonicalization).

Notes:

There is no directionality rule to be applied during enforcement as the directionality rule is part of NFKC, the case mapping rule (as mentioned in section 2.1).

RFC 7711, "PKIX over Secure HTTP (POSH)", November 2015

Source of RFC: xmpp (art)

Errata ID: 6338
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Bastien Lacoste
Date Reported: 2020-11-17

Section 6 says:

The POSH client MUST NOT cache results (reference or fingerprints)
indefinitely.  If the source domain returns a reference, the POSH
client MUST use the lower of the two "expires" values when
determining how long to cache results (i.e., if the reference
"expires" value is lower than the fingerprints "expires" value, honor
the reference "expires" value).  Once the POSH client considers the
results stale, it needs to perform the entire POSH operation again,
starting with the HTTPS GET request to the source domain.  The POSH
client MAY use a lower value than any provided in the "expires"
member(s), or not cache results at all.

It should say:

Add the following:

If the source returns an invalid reference, the POSH client SHALL NOT cache the results (reference or fingerprint) and SHALL perform the entire POSH operation again whenever performing any further retry.

Notes:

If reference is lost (eg x509 certificate) and if POSH client does not refresh fingerprint then it fails until expiration of old fingerprints... which will prevent the client to access a service because of caching, although references was updated on source domain.

RFC 7714, "AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP)", December 2015

Source of RFC: avtcore (wit)

Errata ID: 7858
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Doug Gibbons
Date Reported: 2024-03-20

Section 17 says:

   The examples in this section are all based upon the same RTCP packet:

            81c8000e 4d617273 4e545031 4e545031
            52545020 0000042a 0000eb98 4c756e61
            deadbeef deadbeef deadbeef deadbeef
            deadbeef

   with 32-bit SRTCP index 000005d4.

It should say:

   The examples in this section are all based upon the same RTCP packet:

	    81c8000d 4d617273 4e545031 4e545032
            52545020 0000042a 0000e930 4c756e61
            deadbeef deadbeef deadbeef deadbeef
            deadbeef

   with 32-bit SRTCP index 000005d4.

Notes:

The text at the beginning of Section 17 presents a sample RTCP packet which it expects to be used in subsequent examples. However, all the examples indicate they are based on the packet in the corrected text.

RFC 7729, "Forwarding and Control Element Separation (ForCES) Logical Functional Block (LFB) Subsidiary Management", December 2015

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 5678
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2019-03-28

Section 8.1 says:

Omitted

It should say:

   [RFC7121]  Ogawa, K., Wang, W., Haleplidis, E., and J. Hadi Salim,
              "High Availability within a Forwarding and Control Element
              Separation (ForCES) Network Element", RFC 7121,
              February 2014, <http://www.rfc-editor.org/info/rfc7121>.

Notes:

The document referenced in section 2.2 is not specified.

RFC 7748, "Elliptic Curves for Security", January 2016

Source of RFC: IRTF

Errata ID: 7096
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: James Muir
Date Reported: 2022-08-18

Section Appendix A says:

# section A.1 sage code:

       for A in xrange(3, int(1e9)):
           if (A-2) % 4 != 0:
             continue

# section A.3 sage code:

       for uInt in range(1, 1e3):
         u = F(uInt)

It should say:

# section A.1 sage code:

       for A in xsrange(3, int(1e9)):
           if (A-2) % 4 != 0:
             continue

# section A.3 sage code:

       for uInt in xsrange(1, int(1e3)):
         u = F(uInt)

Notes:

"xrange" is not recognized by Sage with python 3, so the script from section A.1 fails with a syntax error (using "xrange" likely worked fine for Sage with python 2). The suggested changes in A.3 are just for consistency.

Errata ID: 7824
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Jose Luis Amador Moreno
Date Reported: 2024-02-27

Section 5.2 says:

   Input scalar:
     203d494428b8399352665ddca42f9de8fef600908e0d461cb021f8c5
     38345dd77c3e4806e25f46d3315c44e0a5b4371282dd2c8d5be3095f
   Input scalar as a number (base 10):
     633254335906970592779259481534862372382525155
     252028961056404001332122152890562527156973881
     968934311400345568203929409663925541994577184
   Input u-coordinate:
     0fbcc2f993cd56d3305b0b7d9e55d4c1a8fb5dbb52f8e9a1e9b6201b
     165d015894e56c4d3570bee52fe205e28a78b91cdfbde71ce8d157db
   Input u-coordinate as a number (base 10):
     622761797758325444462922068431234180649590390
     024811299761625153767228042600197997696167956
     134770744996690267634159427999832340166786063
   Output u-coordinate:
     884a02576239ff7a2f2f63b2db6a9ff37047ac13568e1e30fe63c4a7
     ad1b3ee3a5700df34321d62077e63633c575c1c954514e99da7c179d

It should say:

   Input scalar:
     203d494428b8399352665ddca42f9de8fef600908e0d461cb021f8c5
     38345dd77c3e4806e25f46d3315c44e0a5b4371282dd2c8d5be3095f
   Input scalar as a number (base 10):
     633254335906970592779259481534862372382525155
     252028961056404001332122152890562527156973881
     968934311400345568203929409663925541994577184
   Input u-coordinate:
     1e37b1e6368991ebce5815bf6b567cedfec0d32246815a6707f02c4a
     61247656f5df569f02613cc5bcedf7a924424ff063c9c0aff5b395ae
   Input u-coordinate as a number (base 10):
     495683502945530038677307449626580741146441879
     406119444019011021926629134928724388368946852
     962833749157931574628774133988199037473470238
   Output u-coordinate:
     d34142faca68f7a3ddf805fa39cc706d5ab3f5633ceff5e6462b775d
     ef45f33083461dcf821cc3f0f74a813277e6895a35d958feef79a5bf

Notes:

Regarding Section 5.2, X448, second vector, the given input u-coordinate is not part of a valid point on the Montgomery form of Curve448.

I suggest replacing the point with a valid one: (2^447 + 100)*G

See the SageMath code (permalink): https://web.archive.org/web/20240227114733/https://pastebin.com/yAuzvEJG

Errata ID: 7879
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Nawras Hussein Sabbry
Date Reported: 2024-04-02

Section 5 says:

z_2 = E * (AA + a24 * E)

It should say:

z_2 = E * (BB + a24 * E)

Notes:

In the for loop on page 8, the variable AA should be replaced with BB in Z_2. This modification is necessary because the mathematical formula for point doubling on the Montgomery curve according to (https://en.wikipedia.org/wiki/Montgomery_curve#Montgomery_arithmetic) indicates that Z2n (equivalent to Z_2 in this case) is calculated as follows: Z2n = 4XnZn((Xn-Zn)^2 + ((A+2)/4)(4XnZn)). It is observed in this equation that the operation in the (Xn-Zn)^2 part involves subtraction similar to the variable B, while the operation in the variable A involves addition. Considering this discrepancy, it is suggested to substitute AA with BB for correctness.

RFC 7801, "GOST R 34.12-2015: Block Cipher "Kuznyechik"", March 2016

Source of RFC: INDEPENDENT

Errata ID: 6928
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin Vaaden
Date Reported: 2022-04-09
Edited by: RFC Editor
Date Edited: 2022-04-13

Section 4.2 says:

   l(a_15,...,a_0) = nabla(148*delta(a_15) + 32*delta(a_15) +
   133*delta(a_13) + 16*delta(a_12) + 194*delta(a_11) +
   192*delta(a_10) + 1*delta(a_9) + 251*delta(a_8) + 1*delta(a_7) +
   192*delta(a_6) + 194*delta(a_5) + 16*delta(a_4) + 133*delta(a_3) +
   32*delta(a_2) + 148*delta(a_1) +1*delta(a_0)),

It should say:

   l(a_15,...,a_0) = nabla(148*delta(a_15) + 32*delta(a_14) +
   133*delta(a_13) + 16*delta(a_12) + 194*delta(a_11) +
   192*delta(a_10) + 1*delta(a_9) + 251*delta(a_8) + 1*delta(a_7) +
   192*delta(a_6) + 194*delta(a_5) + 16*delta(a_4) + 133*delta(a_3) +
   32*delta(a_2) + 148*delta(a_1) +1*delta(a_0)),

Notes:

While I do not have access to the original GOST R 34.12-2015, I believe from implementations I've seen that '32*delta(a_15)' on the first line should be '32*delta(a_14)', unless a_15 is meant to be used twice and a_14 is to be discarded.

RFC 7804, "Salted Challenge Response HTTP Authentication Mechanism", March 2016

Source of RFC: httpauth (sec)

Errata ID: 5496
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Occil
Date Reported: 2018-09-08

Section 2.2 says:

   o  Normalize(str): Apply the Preparation and Enforcement steps
      according to the OpaqueString profile (see [RFC7613]) to a UTF-8
      [RFC3629] encoded "str".  The resulting string is also in UTF-8.
      Note that implementations MUST either implement OpaqueString
      profile operations from [RFC7613] or disallow the use of non
      US-ASCII Unicode codepoints in "str".  The latter is a particular
      case of compliance with [RFC7613].

It should say:

   o  Normalize(str): Apply the Preparation and Enforcement steps
      according to the OpaqueString profile (see [RFC7613]) to a UTF-8
      [RFC3629] encoded "str".  The resulting string is also in UTF-8.
      Note that implementations MUST either implement OpaqueString
      profile operations from [RFC7613] or disallow the use of Unicode 
      codepoints not ranging from U+0020 to U+007E in "str".  The latter
      is a particular case of compliance with [RFC7613].

Notes:

Control code points (including the ASCII controls U+0000 to U+001F as well as U+007F) are disallowed in the PRECIS FreeformClass, which the OpaqueString profile uses. Thus it's not enough to just disallow non-US-ASCII codepoints (rather than implement the full OpaqueString profile) to comply with a subset of the OpaqueString profile.

Errata ID: 6558
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Stephan Bosch
Date Reported: 2021-04-24

Section 5 says:

   C: GET /resource HTTP/1.1
   C: Host: server.example.com
   C: Authorization: SCRAM-SHA-256 sid=AAAABBBBCCCCDDDD,
          data=Yz1iaXdzLHI9ck9wck5HZndFYmVSV2diTkVrcU8laHZZRHBXVWEyUmFUQ
             0FmdXhGSWxqKWhObEYscD1kSHpiWmFwV0lrNGpVaE4rVXRlOXl0YWc5empm
             TUhnc3FtbWl6N0FuZFZRPQo=
   C: [...]

   S: HTTP/1.1 200 Ok
   S: Authentication-Info: sid=AAAABBBBCCCCDDDD,
          data=dj02cnJpVFJCaTIzV3BSUi93dHVwK21NaFVaVW4vZEI1bkxUSlJzamw5N
             Uc0PQo=
   S: [...Other header fields and resource body...]

It should say:

   C: GET /resource HTTP/1.1
   C: Host: server.example.com
   C: Authorization: SCRAM-SHA-256 sid=AAAABBBBCCCCDDDD,
          data="Yz1iaXdzLHI9ck9wck5HZndFYmVSV2diTkVrcU8laHZZRHBXVWEyUmFUQ
              0FmdXhGSWxqKWhObEYscD1kSHpiWmFwV0lrNGpVaE4rVXRlOXl0YWc5empm
              TUhnc3FtbWl6N0FuZFZRPQo="
   C: [...]

   S: HTTP/1.1 200 Ok
   S: Authentication-Info: sid=AAAABBBBCCCCDDDD,
          data="dj02cnJpVFJCaTIzV3BSUi93dHVwK21NaFVaVW4vZEI1bkxUSlJzamw5N
             Uc0PQo="
   S: [...Other header fields and resource body...]

Notes:

The "data" parameter values for the example client request and server response are not quoted, even though these values do not comply with the HTTP token syntax (these both contain a final '='). This means that these examples are in fact invalid.

Found at least one server that implemented their HTTP SCRAM mechanism based on this example, expecting the data parameter to be unquoted and producing it unquoted as well.

Errata ID: 6633
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ben Hollberg
Date Reported: 2021-07-09

Section 5 says:

   This is a simple example of a SCRAM-SHA-256 authentication exchange
   (no support for channel bindings, as this feature is not currently
   supported by HTTP).  Username 'user' and password 'pencil' are used.
   Note that long lines are folded for readability.

   C: GET /resource HTTP/1.1
   C: Host: server.example.com
   C: [...]

   S: HTTP/1.1 401 Unauthorized
   S: WWW-Authenticate: Digest realm="realm1@example.com",
          Digest realm="realm2@example.com",
          Digest realm="realm3@example.com",
          SCRAM-SHA-256 realm="realm3@example.com",
          SCRAM-SHA-256 realm="testrealm@example.com"
   S: [...]

   C: GET /resource HTTP/1.1
   C: Host: server.example.com
   C: Authorization: SCRAM-SHA-256 realm="testrealm@example.com",
          data=biwsbj11c2VyLHI9ck9wck5HZndFYmVSV2diTkVrcU8K
   C: [...]

   S: HTTP/1.1 401 Unauthorized
   S: WWW-Authenticate: SCRAM-SHA-256
           sid=AAAABBBBCCCCDDDD,
           data=cj1yT3ByTkdmd0ViZVJXZ2JORWtxTyVodllEcFdVYTJSYVRDQWZ1eEZJ
              bGopaE5sRixzPVcyMlphSjBTTlk3c29Fc1VFamI2Z1E9PSxpPTQwOTYK
   S: [...]

   C: GET /resource HTTP/1.1
   C: Host: server.example.com
   C: Authorization: SCRAM-SHA-256 sid=AAAABBBBCCCCDDDD,
          data=Yz1iaXdzLHI9ck9wck5HZndFYmVSV2diTkVrcU8laHZZRHBXVWEyUmFUQ
             0FmdXhGSWxqKWhObEYscD1kSHpiWmFwV0lrNGpVaE4rVXRlOXl0YWc5empm
             TUhnc3FtbWl6N0FuZFZRPQo=
   C: [...]

   S: HTTP/1.1 200 Ok
   S: Authentication-Info: sid=AAAABBBBCCCCDDDD,
          data=dj02cnJpVFJCaTIzV3BSUi93dHVwK21NaFVaVW4vZEI1bkxUSlJzamw5N
             Uc0PQo=
   S: [...Other header fields and resource body...]


   In the above example, the first client request contains a "data"
   attribute that base64 decodes as follows:

      n,,n=user,r=rOprNGfwEbeRWgbNEkqO

   The server then responds with a "data" attribute that base64 decodes
   as follows:

      r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hNlF,s=W22ZaJ0SNY7soE
      sUEjb6gQ==,i=4096

   The next client request contains a "data" attribute that base64
   decodes as follows:

      c=biws,r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hNlF,p=dHzbZap
      WIk4jUhN+Ute9ytag9zjfMHgsqmmiz7AndVQ=

   The final server response contains a "data" attribute that base64
   decodes as follows:

      v=6rriTRBi23WpRR/wtup+mMhUZUn/dB5nLTJRsjl95G4=

It should say:

   This is a simple example of a SCRAM-SHA-256 authentication exchange
   (no support for channel bindings, as this feature is not currently
   supported by HTTP).  Username 'user' and password 'pencil' are used.
   Note that long lines are folded for readability.

   C: GET /resource HTTP/1.1
   C: Host: server.example.com
   C: [...]

   S: HTTP/1.1 401 Unauthorized
   S: WWW-Authenticate: Digest realm="realm1@example.com",
          Digest realm="realm2@example.com",
          Digest realm="realm3@example.com",
          SCRAM-SHA-256 realm="realm3@example.com",
          SCRAM-SHA-256 realm="testrealm@example.com"
   S: [...]

   C: GET /resource HTTP/1.1
   C: Host: server.example.com
   C: Authorization: SCRAM-SHA-256 realm="testrealm@example.com",
          data=biwsbj11c2VyLHI9ck9wck5HZndFYmVSV2diTkVrcU8=
   C: [...]

   S: HTTP/1.1 401 Unauthorized
   S: WWW-Authenticate: SCRAM-SHA-256
           sid=AAAABBBBCCCCDDDD,
           data=cj1yT3ByTkdmd0ViZVJXZ2JORWtxTyVodllEcFdVYTJSYVRDQWZ1eEZJ
              bGopaE5sRixzPVcyMlphSjBTTlk3c29Fc1VFamI2Z1E9PSxpPTQwOTY=
   S: [...]

   C: GET /resource HTTP/1.1
   C: Host: server.example.com
   C: Authorization: SCRAM-SHA-256 sid=AAAABBBBCCCCDDDD,
          data=Yz1iaXdzLHI9ck9wck5HZndFYmVSV2diTkVrcU8laHZZRHBXVWEyUmFUQ
             0FmdXhGSWxqKWhObEYscD1kSHpiWmFwV0lrNGpVaE4rVXRlOXl0YWc5empm
             TUhnc3FtbWl6N0FuZFZRPQo=
   C: [...]

   S: HTTP/1.1 200 Ok
   S: Authentication-Info: sid=AAAABBBBCCCCDDDD,
          data=dj02cnJpVFJCaTIzV3BSUi93dHVwK21NaFVaVW4vZEI1bkxUSlJzamw5N
             Uc0PQo=
   S: [...Other header fields and resource body...]


   In the above example, the first client request contains a "data"
   attribute that base64 decodes as follows:

      n,,n=user,r=rOprNGfwEbeRWgbNEkqO

   The server then responds with a "data" attribute that base64 decodes
   as follows:

      r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hNlF,s=W22ZaJ0SNY7soE
      sUEjb6gQ==,i=4096

   The next client request contains a "data" attribute that base64
   decodes as follows:

      c=biws,r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hNlF,p=dHzbZap
      WIk4jUhN+Ute9ytag9zjfMHgsqmmiz7AndVQ=

   The final server response contains a "data" attribute that base64
   decodes as follows:

      v=6rriTRBi23WpRR/wtup+mMhUZUn/dB5nLTJRsjl95G4=

Notes:

The original base64 encoded values of the client first message and server first message are wrong.
Notice that these values end in K. These values base64 decode to strings that end in new line characters.

The original base64 encoded values of the client final message and server final message are correct.
Notice that these values end in =. These values base64 decode to string that do not end in new line characters.

It appears that during the base64 encoding of the client first message and server first message, the newline characters were accidentally included.
The correct base64 encoding is as follows:

n,,n=user,r=rOprNGfwEbeRWgbNEkqO base64 encodes to biwsbj11c2VyLHI9ck9wck5HZndFYmVSV2diTkVrcU8=

r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hNlF,s=W22ZaJ0SNY7soEsUEjb6gQ==,i=4096 base64 encodes to cj1yT3ByTkdmd0ViZVJXZ2JORWtxTyVodllEcFdVYTJSYVRDQWZ1eEZJbGopaE5sRixzPVcyMlphSjBTTlk3c29Fc1VFamI2Z1E9PSxpPTQwOTY=

RFC 7807, "Problem Details for HTTP APIs", March 2016

Note: This RFC has been obsoleted by RFC 9457

Source of RFC: appsawg (art)

Errata ID: 5515
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Steven
Date Reported: 2018-10-05

Section 3.1 says:

   o  "type" (string) - A URI reference [RFC3986] that identifies the
      problem type.  This specification encourages that, when
      dereferenced, it provide human-readable documentation for the
      problem type (e.g., using HTML [W3C.REC-html5-20141028]).  When
      this member is not present, its value is assumed to be
      "about:blank".

It should say:

   o  "type" (string) - A URI reference [RFC3986] that identifies the
      problem type.  This specification encourages that, when
      dereferenced, it provide human-readable documentation for the
      problem type (e.g., using HTML [W3C.REC-html5-20141028]).  When
      this member is missing or null, its value is assumed to be
      "about:blank".

Notes:

JSON objects with a null "type" are syntactically correct, but there is no information on how it should be handled.

{
"type": null,
"status": 404,
"title": "Not Found"
}

It makes sense to treat null as an alias of "about:blank" and that's how I think it should be documented.

RFC 7848, "Mark and Signed Mark Objects Mapping", June 2016

Source of RFC: eppext (art)

Errata ID: 5061
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Nicos Gollan
Date Reported: 2017-07-06

Section 2.2 says:

      *  One or more <mark:protection> elements that contain the
         countries and region of the country where the mark is
         protected.  The <mark:protection> element contains the
         following child elements:

         +  A <mark:cc> element that contains the two-character code of
            the country in which the mark is protected.  This is a two-
            character code from [ISO3166-2].

         +  An OPTIONAL <mark:region> element that contains the name of
            a city, state, province, or other geographic region of
            <mark:country> in which the mark is protected.

         +  Zero or more OPTIONAL <mark:ruling> elements that contain
            the two-character code of the national territory in which
            the statute or treaty is applicable.  This is a two-
            character code from [ISO3166-2].

         +  Zero or more OPTIONAL <mark:label> elements; see definition
            in the <mark:trademark> section above.

It should say:

      *  One or more <mark:protection> elements that contain the
         countries and region of the country where the mark is
         protected.  The <mark:protection> element contains the
         following child elements:

         +  A <mark:cc> element that contains the two-character code of
            the country in which the mark is protected.  This is a two-
            character code from [ISO3166-2].

         +  An OPTIONAL <mark:region> element that contains the name of
            a city, state, province, or other geographic region of
            <mark:country> in which the mark is protected.

         +  Zero or more OPTIONAL <mark:ruling> elements that contain
            the code from [ISO3166-2] of the national territory in which
            the statute or treaty is applicable.

      *  Zero or more OPTIONAL <mark:label> elements; see definition
         in the <mark:trademark> section above.

Notes:

ISO 3166-2 subdivisions are not strictly two-character codes, but can be numeric or contain more than two characters, so the description of the <mark:ruling> element needs to be changed.

Additionally, the indentation of the <mark:label> element makes it appear as a child of <mark:protection>, which is in contradiction to the XML schema on pages 17 and 18.

Errata ID: 5062
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nicos Gollan
Date Reported: 2017-07-06

Throughout the document, when it says:

All occurrences citing [ISO3166-2]

It should say:

Replace with [ISO3166]

Notes:

The RFC mistakenly references ISO 3166-2 for general country codes which is incorrect. Country codes are defined in ISO 3166-1, the 2-character codes used throughout this document in ISO 3166-1 alpha-2, administrative subdivisions in ISO 3166-2. The actual content of the citation points to the general standards "family" already.

RFC 7854, "BGP Monitoring Protocol (BMP)", June 2016

Note: This RFC has been updated by RFC 8671, RFC 9069, RFC 9515

Source of RFC: grow (ops)

Errata ID: 7133
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: John Scudder
Date Reported: 2022-09-14

Section 5 says:

   In BMP's normal operating mode, after the BMP session is up, Route
   Monitoring messages are used to provide a snapshot of the Adj-RIB-In
   of each monitored peer.  This is done by sending all routes stored in
   the Adj-RIB-In of those peers using standard BGP Update messages,
   encapsulated in Route Monitoring messages.  There is no requirement
   on the ordering of messages in the peer dumps.  When the initial dump
   is completed for a given peer, this MUST be indicated by sending an
   End-of-RIB marker for that peer (as specified in Section 2 of
   [RFC4724], plus the BMP encapsulation header).  See also Section 9.

It should say:

Regrettably, there is no straightforward correction. Please see the notes for details.

Notes:

BMP is specified in the indicated text as sending "an End-of-RIB marker for that peer". The problem is that End-of-RIB (EoR) markers aren't specified in RFC 4724 as being per-peer, but per address family (AF), thus it doesn't make sense to talk about sending a single EoR to indicate BMP completion, except in the special case where BMP is only transporting routes for a single address family.

This problem also occurs in Section 3.3:

encapsulated in Route Monitoring messages. Once it has sent all the
routes for a given peer, it MUST send an End-of-RIB message for that
peer; when End-of-RIB has been sent for each monitored peer, the
initial table dump has completed. (A monitoring station that only
wants to gather a table dump could close the connection once it has
gathered an End-of-RIB or Peer Down message corresponding to each
Peer Up message.)

but the underlying fault is in Section 5, so that's what I've referenced above.

There are various fixes that could be applied. Some of them include:

1. Remove all references to EoR. Don't require that an EoR be sent in §5, don't talk about what to do with it in §3.3. I'm not very fond of this option, its only merit is that it's simple to specify the textual changes.

2. Update §5 to note that an EoR has to be sent per AF, and update §3.3 similarly, including in the parenthetical comment noting that the station would have to gather an EoR per AF that's supported on the session.

3. Introduce a new BMP message "end of initial BMP convergence" to provide the functionality. Probably this would be in addition to the fixes in #2, since it's still useful to know that a given AF dump has completed. But introduction of the new message would provide a simpler and probably more reliable way for the monitoring station to know that BMP-level synchronization had completed.

It seems to me that the best way to address this will be with either a new spec that updates RFC 7854, or an rfc7854bis. For this reason, I suggest this erratum should be verified as "hold for document update", since the solution requires more WG discussion and consensus than an erratum can provide.

This issue was first reported by Vincent Bernat in https://mailarchive.ietf.org/arch/msg/idr/FOEcdxtI03CdgDrn497NBFSpz-s/, and see also https://mailarchive.ietf.org/arch/msg/grow/o16w8s5Ba9J4MdIipbxIqDiZrCI/

RFC 7862, "Network File System (NFS) Version 4 Minor Version 2 Protocol", November 2016

Note: This RFC has been updated by RFC 8178

Source of RFC: nfsv4 (wit)

Errata ID: 6945
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Thomas Haynes
Date Reported: 2022-04-27

Section 11.2 says:

+----------------+--------------------------------------------------+
  | COPY           | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED,           |
  |                | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID,             |
  |                | NFS4ERR_DEADSESSION, NFS4ERR_DELAY,              |
  |                | NFS4ERR_DELEG_REVOKED, NFS4ERR_DQUOT,            |
  |                | NFS4ERR_EXPIRED, NFS4ERR_FBIG,                   |
  |                | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, NFS4ERR_INVAL, |
  |                | NFS4ERR_IO, NFS4ERR_ISDIR, NFS4ERR_LOCKED,       |
  |                | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE,             |
  |                | NFS4ERR_NOSPC, NFS4ERR_OFFLOAD_DENIED,           |
  |                | NFS4ERR_OLD_STATEID, NFS4ERR_OPENMODE,           |
  |                | NFS4ERR_OP_NOT_IN_SESSION,                       |
  |                | NFS4ERR_PARTNER_NO_AUTH,                         |
  |                | NFS4ERR_PARTNER_NOTSUPP, NFS4ERR_PNFS_IO_HOLE,   |
  |                | NFS4ERR_PNFS_NO_LAYOUT, NFS4ERR_REP_TOO_BIG,     |
  |                | NFS4ERR_REP_TOO_BIG_TO_CACHE,                    |
  |                | NFS4ERR_REQ_TOO_BIG, NFS4ERR_RETRY_UNCACHED_REP, |
  |                | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT,               |
  |                | NFS4ERR_STALE, NFS4ERR_SYMLINK,                  |
  |                | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_TYPE         |
  +----------------+--------------------------------------------------+
  | COPY_NOTIFY    | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED,           |
  |                | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID,             |
  |                | NFS4ERR_DEADSESSION, NFS4ERR_DELAY,              |
  |                | NFS4ERR_DELEG_REVOKED, NFS4ERR_EXPIRED,          |
  |                | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, NFS4ERR_INVAL, |
  |                | NFS4ERR_IO, NFS4ERR_ISDIR, NFS4ERR_LOCKED,       |
  |                | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE,             |
  |                | NFS4ERR_OLD_STATEID, NFS4ERR_OPENMODE,           |
  |                | NFS4ERR_OP_NOT_IN_SESSION, NFS4ERR_PNFS_IO_HOLE, |
  |                | NFS4ERR_PNFS_NO_LAYOUT, NFS4ERR_REP_TOO_BIG,     |
  |                | NFS4ERR_REP_TOO_BIG_TO_CACHE,                    |
  |                | NFS4ERR_REQ_TOO_BIG, NFS4ERR_RETRY_UNCACHED_REP, |
  |                | NFS4ERR_SERVERFAULT, NFS4ERR_STALE,              |
  |                | NFS4ERR_SYMLINK, NFS4ERR_TOO_MANY_OPS,           |
  |                | NFS4ERR_WRONG_TYPE                               |

It should say:

+----------------+--------------------------------------------------+
  | COPY           | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED,           |
  |                | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID,             |
  |                | NFS4ERR_DEADSESSION, NFS4ERR_DELAY,              |
  |                | NFS4ERR_DELEG_REVOKED, NFS4ERR_DQUOT,            |
  |                | NFS4ERR_EXPIRED, NFS4ERR_FBIG,                   |
  |                | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, NFS4ERR_INVAL, |
  |                | NFS4ERR_IO, NFS4ERR_ISDIR, NFS4ERR_LOCKED,       |
  |                | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE,             |
  |                | NFS4ERR_NOSPC, NFS4ERR_OFFLOAD_DENIED,           |
  |                | NFS4ERR_OLD_STATEID, NFS4ERR_OPENMODE,           |
  |                | NFS4ERR_OP_NOT_IN_SESSION,                       |
  |                | NFS4ERR_PARTNER_NO_AUTH, NFS4ERR_NOTSUPP                        |
  |                | NFS4ERR_PARTNER_NOTSUPP, NFS4ERR_PNFS_IO_HOLE,   |
  |                | NFS4ERR_PNFS_NO_LAYOUT, NFS4ERR_REP_TOO_BIG,     |
  |                | NFS4ERR_REP_TOO_BIG_TO_CACHE,                    |
  |                | NFS4ERR_REQ_TOO_BIG, NFS4ERR_RETRY_UNCACHED_REP, |
  |                | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT,               |
  |                | NFS4ERR_STALE, NFS4ERR_SYMLINK,                  |
  |                | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_TYPE         |
  +----------------+--------------------------------------------------+
  | COPY_NOTIFY    | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED,           |
  |                | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID,             |
  |                | NFS4ERR_DEADSESSION, NFS4ERR_DELAY,              |
  |                | NFS4ERR_DELEG_REVOKED, NFS4ERR_EXPIRED,          |
  |                | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, NFS4ERR_INVAL, |
  |                | NFS4ERR_IO, NFS4ERR_ISDIR, NFS4ERR_LOCKED,       |
  |                | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTSUPP            |
  |                | NFS4ERR_OLD_STATEID, NFS4ERR_OPENMODE,           |
  |                | NFS4ERR_OP_NOT_IN_SESSION, NFS4ERR_PNFS_IO_HOLE, |
  |                | NFS4ERR_PNFS_NO_LAYOUT, NFS4ERR_REP_TOO_BIG,     |
  |                | NFS4ERR_REP_TOO_BIG_TO_CACHE,                    |
  |                | NFS4ERR_REQ_TOO_BIG, NFS4ERR_RETRY_UNCACHED_REP, |
  |                | NFS4ERR_SERVERFAULT, NFS4ERR_STALE,              |
  |                | NFS4ERR_SYMLINK, NFS4ERR_TOO_MANY_OPS,           |
  |                | NFS4ERR_WRONG_TYPE                               |

Notes:

Both COPY and COPY_NOTIFY are optional new operations for NFSv4.2. Hence they both should support the NFS4ERR_NOTSUPP error code.

RFC 7868, "Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP)", May 2016

Source of RFC: INDEPENDENT

Errata ID: 5242
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Innokentiy Solntsev
Date Reported: 2018-01-24
Edited by: Adrian Farrel
Date Edited: 2020-04-22

Section 5.6.2.5 says:

                                                                K5
      metric =[(K1*Net-Throughput) + Latency)+(K6*ExtAttr)] * ------
                                                              K4+Rel

It should say:

                                                        K5
      metric =[Net-Throughput+Latency+(K6*ExtAttr)] * ------
                                                      K4+Rel

Notes:

1. Round brackets aren't balanced.
2. There shouldn't be K1, as Net-Throughput already includes it.

Errata ID: 5691
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Gabriel Torres
Date Reported: 2019-04-14

Section 5.6.1.1 says:

The calculated EIGRP bandwidth (BW) metric is then:

               256 * (10^7)/BW = 256 * {(10^7)/10,000}
                               = 256 * 1000
                               = 256,000

   And the calculated EIGRP delay metric is then:

            256 * sum of delay = 256 * 100 * 10 microseconds
                               = 25,600 (in tens of microseconds)

It should say:

The calculated EIGRP bandwidth (BW) metric is then:

               (10^7)/BW = {(10^7)/10,000}
                         = 1,000

   And the calculated EIGRP delay metric is then:

               sum of delay = 1 ms = 100 tens of microseconds

   Thus the composite metric is:

               256 * 1000 * 100 = 25,600,000

Notes:

The 256 should be multiplied by the sum of the bandwidth and the delay, and not multiplied by each individual parameter.

1 ms = 1,000 microseconds = 100 tens of microseconds

Errata ID: 6084
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Rafał Cygnarowski
Date Reported: 2020-04-10

Section 5.6.2.3. says:

   The formula for the conversion for Max-Throughput value directly from
   the interface without consideration of congestion-based effects is as
   follows:

                                  (EIGRP_BANDWIDTH * EIGRP_WIDE_SCALE)
        Max-Throughput = K1 *     ------------------------------------
                                       Interface Bandwidth (kbps)


   If K2 is used, the effect of congestion as a measure of load reported
   by the interface will be used to simulate the "available Throughput"
   by adjusting the maximum Throughput according to the formula:

                                           K2 * Max-Throughput
        Net-Throughput = Max-Throughput + ---------------------
                                              256 - Load

It should say:

   The formula for the conversion for Max-Throughput value directly from
   the interface without consideration of congestion-based effects is as
   follows:

                           EIGRP_BANDWIDTH * EIGRP_WIDE_SCALE
        Max-Throughput =  ------------------------------------
                               Interface Bandwidth (kbps)


   If K2 is used, the effect of congestion as a measure of load reported
   by the interface will be used to simulate the "available Throughput"
   by adjusting the maximum Throughput according to the formula:

                                                K2 * Max-Throughput
        Net-Throughput = K1 * Max-Throughput + ---------------------
                                                     256 - Load

Notes:

K1 can't be a part of Max-Throughput as it affects Net-Throughput twice. Moreover: in case of K1=0, K2 become ignored as it will be multiplied by 0.

Together with errata ID: 5242 which fixes metric formula {metric =[Net-Throughput+Latency+(K6*ExtAttr)] * K5/(K4+Rel) }, results become correct and are same as on live equipment.

Errata ID: 6088
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Rafał Cygnarowski
Date Reported: 2020-04-12

Section 6.1. says:

   EIGRP IPv4 will transmit HELLO packets using either the unicast
   destination of a neighbor or using a multicast host group address [7]
   with a source address EIGRP IPv4 multicast address [13].

It should say:

   EIGRP IPv4 will transmit HELLO packets using either the unicast
   destination of a neighbor or using a multicast host group address [7]
   with a destination address EIGRP IPv4 multicast address [13].

Notes:

Multicast address is a destination address.

Errata ID: 6090
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Rafał Cygnarowski
Date Reported: 2020-04-12

Section 5.6.2.5. says:

metric = (K1 * min(Throughput)) + (K3 * sum(Latency)) }

It should say:

metric = K1 * Max-Throughput + Latency

Notes:

This errata is consequence of:
- erratas 5242 and 6084,
- inconsistency of using (Max-)Throughput and Latency variables,
- using additional min() and sum() functions which are not used in formula where all K-values takes effect ( metric =[Net-Throughput+Latency+(K6*ExtAttr)] * K5/(K4+Rel)) .

The Max-Throughput variable defined in 5.6.2.3. is a little bit unfortunate, as in fact it is minimum of maximum available throughput of all network segments in the path.

I removed also K3 value from the metric as it is already embraced in Latency calculation in 5.6.2.4.

I decided to use this formula as it is mathematically correct and is least intrusive but the best would be to review notations from 5.6.2.3. up to .5 and remove all inaccuracies. Also highlighting usage of K-Values in final metric calculation would make this document more readable, eg. metric = K1 * Throughtput + K3 * Latency - which shows best how K-values affect metric.

RFC 7913, "P-Access-Network-Info ABNF Update", June 2016

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 6678
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Dinoop Paloli
Date Reported: 2021-09-06

Throughout the document, when it says:

NA

It should say:

NA

Notes:

As per the Introduction section,

"As the P-Access-Network-Info header field is mainly used in networks
defined by the 3rd-Generation Partnership Project (3GPP), where new
values following the 'generic-param' rule have been defined
[TS.3GPP.24.229], the update is not considered to cause issues with
backward compatibility. "

This is not true and there is backward compatibility issue due to change in ABNF form of extension-access-info from gen-value to generic-param

For eg:

As per the old RFC the following header was valid,
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=23456789ABCDE; "a=c";

See the parameter "a=c" which was allowed as part of "gen-value = token / host / quoted-string"

But generic-param has to be in the form
generic-param = token [ EQUAL gen-value ]

due to this a simple quoted string become invalid.

This causes backward compatibility of new SIP stacks and old networks.

RFC 7914, "The scrypt Password-Based Key Derivation Function", August 2016

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 5971
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Tobias Nießen
Date Reported: 2020-02-02

Section 2 says:

The CPU/Memory cost parameter N ("costParameter") must be larger than 1, a power of 2, and less than 2^(128 * r / 8).

It should say:

The CPU/Memory cost parameter N ("costParameter") must be larger than 1, and a power of 2.

Notes:

The presented limit on N was incorrectly derived from the original scrypt publication. The correct theoretical upper limit on N is 2^(128 * r) for r < 5, and 2^512 for all other values of r. Thus, the least upper bound is 2^128, which far exceeds all possible values for N in the foreseeable future, making the limit irrelevant for current implementations.

Errata ID: 5972
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Tobias Nießen
Date Reported: 2020-02-02

Section 5 says:

Input:
         r       Block size parameter.
         B       Input octet vector of length 128 * r octets.
         N       CPU/Memory cost parameter, must be larger than 1,
                 a power of 2, and less than 2^(128 * r / 8).

It should say:

Input:
         r       Block size parameter.
         B       Input octet vector of length 128 * r octets.
         N       CPU/Memory cost parameter, must be larger than 1,
                 and a power of 2.

Notes:

The presented limit on N was incorrectly derived from the original scrypt publication. The correct theoretical upper limit on N is 2^(128 * r) for r < 5, and 2^512 for all other values of r. Thus, the least upper bound is 2^128, which far exceeds all possible values for N in the foreseeable future, making the limit irrelevant for current implementations.

Errata ID: 5973
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Tobias Nießen
Date Reported: 2020-02-02

Section 6 says:

Input:
         P       Passphrase, an octet string.
         S       Salt, an octet string.
         N       CPU/Memory cost parameter, must be larger than 1,
                 a power of 2, and less than 2^(128 * r / 8).
         r       Block size parameter.
         p       Parallelization parameter, a positive integer
                 less than or equal to ((2^32-1) * hLen) / MFLen
                 where hLen is 32 and MFlen is 128 * r.
         dkLen   Intended output length in octets of the derived
                 key; a positive integer less than or equal to
                 (2^32 - 1) * hLen where hLen is 32.

It should say:

Input:
         P       Passphrase, an octet string.
         S       Salt, an octet string.
         N       CPU/Memory cost parameter, must be larger than 1,
                 and a power of 2.
         r       Block size parameter.
         p       Parallelization parameter, a positive integer
                 less than or equal to ((2^32-1) * hLen) / MFLen
                 where hLen is 32 and MFlen is 128 * r.
         dkLen   Intended output length in octets of the derived
                 key; a positive integer less than or equal to
                 (2^32 - 1) * hLen where hLen is 32.

Notes:

The presented limit on N was incorrectly derived from the original scrypt publication. The correct theoretical upper limit on N is 2^(128 * r) for r < 5, and 2^512 for all other values of r. Thus, the least upper bound is 2^128, which far exceeds all possible values for N in the foreseeable future, making the limit irrelevant for current implementations.

Errata ID: 6452
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: John Comeau
Date Reported: 2021-03-05

Section 5 says:

     3. for i = 0 to N - 1 do
          j = Integerify (X) mod N
                 where Integerify (B[0] ... B[2 * r - 1]) is defined
                 as the result of interpreting B[2 * r - 1] as a
                 little-endian integer.

It should say:

     3. for i = 0 to N - 1 do
          j = Integerify (X) mod N
                 where Integerify (B[0] ... B[2 * r - 1]) is defined
                 as the result of interpreting B[r] ... B[r + 3] as a
                 little-endian integer.

Notes:

The original description of Integerify looks, to a programmer, as though a single byte (the final octet) is being converted to an integer (as with the Python `ord` operation). But that wouldn't make sense with the term "little-endian", which has meaning only with multiple-byte words. So the likely conclusion would be that this was a typographical error, and that the entire string X (or B) should be treated as an integer [e.g., Python3 int.from_bytes(b'\xff\xff\xff\xff\xff\xff\xff\xff', 'little')]. However, this interpretation of Integerify gives results that do not match the test vectors.

By looking at other people's code (https://github.com/ricmoo/pyscrypt in particular) I found that using the 4 bytes beginning halfway through the octet string gives results which do match the test vectors.

RFC 7931, "NFSv4.0 Migration: Specification Update", July 2016

Source of RFC: nfsv4 (wit)

Errata ID: 4822
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: David Noveck
Date Reported: 2016-10-06

Section 5.8 says:

Note that the NFSv4.0 specification requires the server to make 
sure that such verifiers are very unlikely to be regenerated.
Given that it is already highly unlikely that the clientid4 XC is 
duplicated by distinct servers, the probability that SCn is 
duplicated as well has to be considered vanishingly small.  Note 
also that the callback update procedure can be repeated multiple 
times to reduce the probability of further spurious matches.

It should say:

Although the NFSv4.0 specification requires the server to make 
sure that such verifiers are very unlikely to be regenerated, 
different servers may use the same approach to the construction 
of such verifiers, raising the probability that two distinct 
servers might inadvertently assign the same verifier value. The 
fact that the servers in question have assigned the same 
clientid4 may raise this probability.  In order to guard 
against the possibility that such assignments might cause two 
distinct servers to be incorrectly considered the same, 
the SETCLIENTID procedure mentioned above needs to be repeated.  
Repeating the procedure once  is sufficient to ensure that the 
successive confirm values SCn, SCn'  generated by these repeated 
SETCLIENTID operations cannot all collide with a verifier 
previously received by the client when communicating with IPn.

Notes:

It appears that the original text underestimated the probability inadvertant of duplication of clientid4's and verifiers. Existing servers while conforming to to RFC7530, may generate the same sequence of clientid4's when they all happen to be rebooted at the same time. The new text deals with this possibility and ensures that two different servers cannot be considered the same.

RFC 7932, "Brotli Compressed Data Format", July 2016

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 6977
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Sean Bartell
Date Reported: 2022-05-21

Section 9.3 says:

      Block type code for next distance block type, appears only if
         NBLTYPESD >= 2 and the previous distance block count is zero

      Block count code + extra bits for next distance block count,
         appears only if NBLTYPESD >= 2 and the previous distance block
         count is zero

It should say:

      Block type code for next distance block type, appears only if
         NBLTYPESD >= 2 and the previous distance block count is zero
         and the distance code is not an implicit 0, as indicated by
         the insert-and-copy length code

      Block count code + extra bits for next distance block count,
         appears only if NBLTYPESD >= 2 and the previous distance block
         count is zero and the distance code is not an implicit 0, as
         indicated by the insert-and-copy length code

Notes:

Corrected to match section 10 and the reference implementation, which do not update the distance block count when the distance is implicitly 0.

RFC 7940, "Representing Label Generation Rulesets Using XML", August 2016

Source of RFC: lager (art)

Errata ID: 5167
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Phil Pennock
Date Reported: 2017-10-24

Section 4.3.7 says:

   Whenever an LGR depends on character properties from a given version
   of the Unicode Standard, the version number used in creating the LGR
   MUST be listed in the form x.y.z, where x, y, and z are positive
   decimal integers (see [Unicode-Versions]).

It should say:

   Whenever an LGR depends on character properties from a given version
   of the Unicode Standard, the version number used in creating the LGR
   MUST be listed in the form x.y.z, where x, y, and z are non-negative
   decimal integers (see [Unicode-Versions]).

Notes:

A zero needs to be allowed in the version numbering, as included in the example below. Zero is neither positive nor negative. "0, 1, 2, ..." are the "non-negative decimal integers". Positive decimal integers start at 1.

Thus for "6.3.0" to be a valid example, the constraint needs to be "non-negative" rather than "positive".

RFC 7946, "The GeoJSON Format", August 2016

Source of RFC: geojson (art)

Errata ID: 5069
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Clark Archer
Date Reported: 2017-07-14

Section 3.1.6 says:

3.1.6.  Polygon

   To specify a constraint specific to Polygons, it is useful to
   introduce the concept of a linear ring:

   o  A linear ring is a closed LineString with four or more positions.

   o  The first and last positions are equivalent, and they MUST contain
      identical values; their representation SHOULD also be identical.

   o  A linear ring is the boundary of a surface or the boundary of a
      hole in a surface.

   o  A linear ring MUST follow the right-hand rule with respect to the
      area it bounds, i.e., exterior rings are counterclockwise, and
      holes are clockwise.

   Note: the [GJ2008] specification did not discuss linear ring winding
   order.  For backwards compatibility, parsers SHOULD NOT reject
   Polygons that do not follow the right-hand rule.

   Though a linear ring is not explicitly represented as a GeoJSON
   geometry type, it leads to a canonical formulation of the Polygon
   geometry type definition as follows:

   o  For type "Polygon", the "coordinates" member MUST be an array of
      linear ring coordinate arrays.

   o  For Polygons with more than one of these rings, the first MUST be
      the exterior ring, and any others MUST be interior rings.  The
      exterior ring bounds the surface, and the interior rings (if
      present) bound holes within the surface.

It should say:

3.1.6.  Polygon

   To specify a constraint specific to Polygons, it is useful to
   introduce the concept of a linear ring:

   o  A linear ring is a closed LineString with four or more positions.

   o  The first and last positions are equivalent, and they MUST contain
      identical values; their representation SHOULD also be identical.

   o  A linear ring is the boundary of a surface or the boundary of a
      hole in a surface.

   o  A linear ring MUST follow the right-hand rule with respect to the
      area it bounds, i.e., exterior rings are clockwise, and holes are
      counterclockwise.

   Note: the [GJ2008] specification did not discuss linear ring winding
   order.  For backwards compatibility, parsers SHOULD NOT reject
   Polygons that do not follow the right-hand rule.

   Though a linear ring is not explicitly represented as a GeoJSON
   geometry type, it leads to a canonical formulation of the Polygon
   geometry type definition as follows:

   o  For type "Polygon", the "coordinates" member MUST be an array of
      linear ring coordinate arrays.

   o  For Polygons with more than one of these rings, the first MUST be
      the exterior ring, and any others MUST be interior rings.  The
      exterior ring bounds the surface, and the interior rings (if
      present) bound holes within the surface.

Notes:

This is only for the bullet point describing the right-hand rule for linear rings. It seems like the clockwise/counterclockwise descriptions are the opposite of the right-hand rule. Walking an exterior ring in a counterclockwise direction would have the exterior of the ring to the right of the observer.

Errata ID: 7261
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: mark hedley
Date Reported: 2022-12-08

Section 4 says:

An OPTIONAL third-position element SHALL be the height in meters above or below the 
WGS84 reference ellipsoid.

It should say:

An OPTIONAL third-position element SHALL be the height in meters above or below the 
EGM2008 geoid vertical datum, the height is defined with respect to the EGM2008 
vertical coordinate reference system (providing close approximation to altitude above 
global mean sea level).

Notes:

Vertical coordinates, where used within GeoJSON shall be interpreted as with respect to the EGM2008 vertical datum. Transformations from WGS84 vertical coordinate values to EGM2008 coordinate values shall not be implemented (unless by prior arrangement between involved parties) .

There is specification information within the EPSG registry on both the EGM2008 vertical datum:
https://epsg.org/crs_3855/EGM2008-height.html
and on the compound of WGS84 latitude longitude with EGM2008 altitude
https://epsg.org/crs_9518/WGS-84-EGM2008-height.html

Common usage of altitude vertical coordinates is with respect to mean sea level. However, the original text within rfc7946 state that a vertical coordinate is with respect to the WGS84 reference ellipsoid.

The WGS84 reference ellipsoid is an oblate spheroid that only partially approximates mean sea level. The EGM2008 (superseding EGM96) vertical datum provides
"Zero-height surface resulting from the application of the EGM2008 geoid model to the WGS 84 ellipsoid." (https://epsg.org/crs_3855/EGM2008-height.htm)
EGM2008 closely models mean sea level as a global vertical datum.

Distortions are global position dependent, discrepancies can range from less than a metre to 10s of metres. For example, at a location of (50.218 -5.327 (WGS84)) the discrepancy between a WGS84 vertical coordinate and a EGM2008 vertical coordinate is 53.4 metres.
This is a really significant vertical discrepancy for a positional coordinate.

The update within this errata matches the specification to the widespread and common use of vertical position with respect to mean sea level, as measured by national mapping agencies and satellite earth observations.

Errata ID: 7253
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Tim Schaub
Date Reported: 2022-11-18

Section 5.2 says:

Consider a set of point Features within the Fiji archipelago,
straddling the antimeridian between 16 degrees S and 20 degrees S.
The southwest corner of the box containing these Features is at 20
degrees S and 177 degrees E, and the northwest corner is at 16
degrees S and 178 degrees W.

It should say:

Consider a set of point Features within the Fiji archipelago,
straddling the antimeridian between 16 degrees S and 20 degrees S.
The southwest corner of the box containing these Features is at 20
degrees S and 177 degrees E, and the northeast corner is at 16
degrees S and 178 degrees W.

Notes:

In the antimeridian-crossing example, the text says that the "northwest" corner is at 16 degrees S and 178 degrees W. It should say this is the "northeast" corner instead.

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.

RFC 7970, "The Incident Object Description Exchange Format Version 2", November 2016

Source of RFC: mile (sec)

Errata ID: 5398
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Logan Widick
Date Reported: 2018-06-19

Section 3.29.2 says:

   The AlternativeIndicatorID class lists alternative identifiers for an
   indicator.
   
   +-------------------------+
   | AlternativeIndicatorID  |
   +-------------------------+
   | ENUM restriction        |<>--{1..*}--[ IndicatorReference ]
   | STRING ext-restriction  |
   +-------------------------+

                Figure 61: The AlternativeIndicatorID Class

   The aggregate class of the AlternativeIndicatorID class is:

   IndicatorReference
      One or more.  A reference to an indicator.  See Section 3.29.7.

   The attributes of the AlternativeIndicatorID class are:

   restriction
      Optional.  ENUM.  See Section 3.3.1.

   ext-restriction
      Optional.  STRING.  A means by which to extend the restriction
      attribute.  See Section 5.1.1.

It should say:

   
   The AlternativeIndicatorID class lists alternative identifiers for an
   indicator.
   
   +-------------------------+
   | AlternativeIndicatorID  |
   +-------------------------+
   | ENUM restriction        |<>--{1..*}--[ IndicatorID ]
   | STRING ext-restriction  |
   +-------------------------+

                Figure 61: The AlternativeIndicatorID Class

   The aggregate class of the AlternativeIndicatorID class is:

   IndicatorID
      One or more.  An alternative ID for the indicator. 
      See Section 3.29.1.

   The attributes of the AlternativeIndicatorID class are:

   restriction
      Optional.  ENUM.  See Section 3.3.1.

   ext-restriction
      Optional.  STRING.  A means by which to extend the restriction
      attribute.  See Section 5.1.1.

Notes:

Change: Update Section 3.29.1 to show that AlternativeIndicatorID contains IndicatorIDs, not IndicatorReferences.

From the notations part of the introduction (Section 1.2), the UML diagrams in Section 3 are non-normative, and the "IODEF Data Model (XML Schema)" in Section 8 is normative.
If my understanding of the text is correct, this means that if the UML diagrams conflict with the schema in Section 8, the schema in Section 8 is correct, and the UML diagrams must be changed to align with the schema in Section 8.

Page 153 of the document contains the (normative) AlternativeIndicatorID schema from Section 8:

<xs:element name="AlternativeIndicatorID">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:IndicatorID" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="restriction"
type="iodef:restriction-type" use="optional"/>
<xs:attribute name="ext-restriction"
type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>

From the above schema, the AlternativeIndicatorID is a sequence of IndicatorID, not the sequence of IndicatorReference implied by Section 3.29.2 (Figure 61 and the accompanying text). Thus, if I understand the document correctly, Section 3.29.2 must be changed to something more like the "Corrected Text" in this report.

Errata ID: 5582
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Takeshi Takahashi
Date Reported: 2018-12-25

Section 8 says:

    <xs:simpleType name="contact-role-type">
      <xs:restriction base="xs:NMTOKEN">
        <xs:enumeration value="creator"/>
        <xs:enumeration value="reporter"/>
        <xs:enumeration value="admin"/>
        <xs:enumeration value="tech"/>
        <xs:enumeration value="provider"/>
        <xs:enumeration value="user"/>
        <xs:enumeration value="billing"/>
        <xs:enumeration value="legal"/>
        <xs:enumeration value="abuse"/>
        <xs:enumeration value="irt"/>
        <xs:enumeration value="cc"/>
        <xs:enumeration value="cc-irt"/>
        <xs:enumeration value="leo"/>
        <xs:enumeration value="vendor"/>
        <xs:enumeration value="vendor-services"/>

It should say:

    <xs:simpleType name="contact-role-type">
      <xs:restriction base="xs:NMTOKEN">
        <xs:enumeration value="creator"/>
        <xs:enumeration value="reporter"/>
        <xs:enumeration value="admin"/>
        <xs:enumeration value="tech"/>
        <xs:enumeration value="provider"/>
        <xs:enumeration value="user"/>
        <xs:enumeration value="billing"/>
        <xs:enumeration value="legal"/>
        <xs:enumeration value="abuse"/>
        <xs:enumeration value="irt"/>
        <xs:enumeration value="cc"/>
        <xs:enumeration value="cc-irt"/>
        <xs:enumeration value="leo"/>
        <xs:enumeration value="vendor"/>
        <xs:enumeration value="vendor-support"/>

Notes:

In section 3.9, the body text says that the role attribute can take the value "vendor-support," but the schema says that the role can take the value "vendor-services." This inconsistency needs to be solved.

Errata ID: 5590
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Logan Widick
Date Reported: 2019-01-04

Section 3.18 says:

   The Node class identifies a system, asset, or network and its
   location.

   +---------------+
   | Node          |
   +---------------+
   |               |<>--{0..*}--[ DomainData    ]
   |               |<>--{0..*}--[ Address       ]
   |               |<>--{0..1}--[ PostalAddress ]
   |               |<>--{0..*}--[ Location      ]
   |               |<>--{0..*}--[ Counter       ]
   +---------------+

                         Figure 34: The Node Class

   The aggregate classes of the Node class are:

   DomainData
      Zero or more.  The domain (DNS) information associated with this
      node.  If an Address is not provided, at least one DomainData MUST
      be specified.  See Section 3.19.

   Address
      Zero or more.  The hardware, network, or application address of
      the node.  If a DomainData is not provided, at least one Address
      MUST be specified.  See Section 3.18.1.

   PostalAddress
      Zero or one.  POSTAL.  The postal address of the node.

   Location
      Zero or more.  ML_STRING.  A free-form text description of the
      physical location of the node.  This description may provide a
      more detailed description of where at the address specified by the
      PostalAddress class this node is found (e.g., room number, rack
      number, or slot number in a chassis).

It should say:

   The Node class identifies a system, asset, or network and its
   location.

   +---------------+
   | Node          |
   +---------------+
   |               |<>--{0..*}--[ DomainData    ]
   |               |<>--{0..*}--[ Address       ]
   |               |<>--{0..1}--[ PostalAddress ]
   |               |<>--{0..*}--[ Location      ]
   |               |<>--{0..*}--[ Counter       ]
   +---------------+

                         Figure 34: The Node Class

   The aggregate classes of the Node class are:

   DomainData
      Zero or more.  The domain (DNS) information associated with this
      node.  If an Address is not provided, at least one DomainData MUST
      be specified.  See Section 3.19.

   Address
      Zero or more.  The hardware, network, or application address of
      the node.  If a DomainData is not provided, at least one Address
      MUST be specified.  See Section 3.18.1.

   PostalAddress
      Zero or one.  The postal address of the node. See Section 3.9.2.

   Location
      Zero or more.  ML_STRING.  A free-form text description of the
      physical location of the node.  This description may provide a
      more detailed description of where at the address specified by the
      PostalAddress class this node is found (e.g., room number, rack
      number, or slot number in a chassis).

Notes:

According to "Section 8: The IODEF Data Model (XML Schema)", the Node class structure is the following:
<xs:element name="Node">
<xs:complexType>
<xs:sequence>
<xs:choice maxOccurs="unbounded">
<xs:element ref="iodef:DomainData"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Address"
minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
<xs:element ref="iodef:PostalAddress" minOccurs="0"/>
<xs:element ref="iodef:Location"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Counter"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>

Note that the schema is referring to the PostalAddress class (iodef:PostalAddress) instead of the "PAddress" (POSTAL) member of the PostalAddress class. Also, the UML diagram (Figure 34) and other parts of Section 3.18 refer to the PostalAddress class instead of the "PAddress" (POSTAL) member of the PostalAddress class. Thus, the "PostalAddress" field of the Node class is most likely an instance of the PostalAddress class, and not the POSTAL type stated in the text.

The corrected text ("The aggregate classes of the Node class are... PostalAddress") includes a reference to the PostalAddress class ("See Section 3.9.2") instead of the "POSTAL." type.

Errata ID: 6163
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: François Poirotte
Date Reported: 2020-05-10

Section 7.2 says:

 An example of C2 domains from a given campaign.

   <?xml version="1.0" encoding="UTF-8"?>
   <!-- A list of C2 domains associated with a campaign -->
   <IODEF-Document version="2.00" xml:lang="en"
      xmlns="urn:ietf:params:xml:ns:iodef-2.0"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation=
      "http://www.iana.org/assignments/xml-registry/schema/
       iodef-2.0.xsd">
     <Incident purpose="watch" restriction="green">
       <IncidentID name="csirt.example.com">897923</IncidentID>
         <RelatedActivity>
           <ThreatActor>
             <ThreatActorID>
             TA-12-AGGRESSIVE-BUTTERFLY
             </ThreatActorID>
             <Description>Aggressive Butterfly</Description>
           </ThreatActor>
           <Campaign>
             <CampaignID>C-2015-59405</CampaignID>
             <Description>Orange Giraffe</Description>
           </Campaign>
         </RelatedActivity>
         <GenerationTime>2015-10-02T11:18:00-05:00</GenerationTime>
         <Description>Summarizes the Indicators of Compromise
           for the Orange Giraffe campaign of the Aggressive
           Butterfly crime gang.
         </Description>
         <Assessment>
           <BusinessImpact type="breach-proprietary"/>
         </Assessment>
         <Contact type="organization" role="creator">
           <ContactName>CSIRT for example.com</ContactName>
           <Email>
             <EmailTo>contact@csirt.example.com</EmailTo>
           </Email>
         </Contact>
         <IndicatorData>
           <Indicator>
             <IndicatorID name="csirt.example.com" version="1">
             G90823490
             </IndicatorID>
             <Description>C2 domains</Description>
             <StartTime>2014-12-02T11:18:00-05:00</StartTime>
             <Observable>
               <BulkObservable type="fqdn">

It should say:

 An example of C2 domains from a given campaign.

   <?xml version="1.0" encoding="UTF-8"?>
   <!-- A list of C2 domains associated with a campaign -->
   <IODEF-Document version="2.00" xml:lang="en"
      xmlns="urn:ietf:params:xml:ns:iodef-2.0"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation=
      "http://www.iana.org/assignments/xml-registry/schema/
       iodef-2.0.xsd">
     <Incident purpose="watch" restriction="green">
       <IncidentID name="csirt.example.com">897923</IncidentID>
         <RelatedActivity>
           <ThreatActor>
             <ThreatActorID>
             TA-12-AGGRESSIVE-BUTTERFLY
             </ThreatActorID>
             <Description>Aggressive Butterfly</Description>
           </ThreatActor>
           <Campaign>
             <CampaignID>C-2015-59405</CampaignID>
             <Description>Orange Giraffe</Description>
           </Campaign>
         </RelatedActivity>
         <GenerationTime>2015-10-02T11:18:00-05:00</GenerationTime>
         <Description>Summarizes the Indicators of Compromise
           for the Orange Giraffe campaign of the Aggressive
           Butterfly crime gang.
         </Description>
         <Assessment>
           <BusinessImpact type="breach-proprietary"/>
         </Assessment>
         <Contact type="organization" role="creator">
           <ContactName>CSIRT for example.com</ContactName>
           <Email>
             <EmailTo>contact@csirt.example.com</EmailTo>
           </Email>
         </Contact>
         <IndicatorData>
           <Indicator>
             <IndicatorID name="csirt.example.com" version="1">
             G90823490
             </IndicatorID>
             <Description>C2 domains</Description>
             <StartTime>2014-12-02T11:18:00-05:00</StartTime>
             <Observable>
               <BulkObservable type="domain-name">

Notes:

Neither the IODEF Data Model (XML Schema) in section 8 nor the main body in section 3.29.3.1 define a type named "fqdn" for the BulkObservable class.
Instead, section 3.29.3.1 states that the "domain-name" type is used to denote "A fully qualified domain name or part of a name (e.g., fqdn.example.com, example.com).". The XML schema agrees with that.

The example in section 7.2 was changed to comply with this definition.

Errata ID: 6168
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: François Poirotte
Date Reported: 2020-05-11

Section 2.17 says:

There is no original text (new section)

It should say:

2.17.  Boolean

A boolean is represented in the information model by the BOOLEAN
data type.  

The BOOLEAN data type is implemented in the data model as an
"xs:boolean" type per Section 3.2.2 of [W3C.SCHEMA.DTYPES].

Notes:

Section 2.16 defines "boolean" as a valid value for the "dtype" attribute, stating that "The element content is of type BOOLEAN.".
This is reinforced by the definition of "dtype-type" inside the XML schema in section 8 where "boolean" is indeed listed as a valid value.
However, the BOOLEAN type is never actually defined in the RFC.

This change adds a new section (tentatively named 2.17) under section 2 which defines the BOOLEAN type based on the definition of other types used by the RFC.

It might be preferable to put the new section near the beginning of section 2 with other primitive datatypes like INTEGER and REAL.
Please note that this change also impacts the table of contents.

Errata ID: 6169
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: François Poirotte
Date Reported: 2020-05-11

Section 4.4 says:

4.4.  Incompatibilities with v1

   The IODEF data model in this document makes a number of changes to
   [RFC5070].  These changes were largely additive -- classes and
   enumerated values were added.  However, some incompatibilities
   between [RFC5070] and this new specification were introduced.  These
   incompatibilities are as follows:

   o  The IODEF-Document@version attribute is set to "2.0".

It should say:

4.4.  Incompatibilities with v1

   The IODEF data model in this document makes a number of changes to
   [RFC5070].  These changes were largely additive -- classes and
   enumerated values were added.  However, some incompatibilities
   between [RFC5070] and this new specification were introduced.  These
   incompatibilities are as follows:

   o  The IODEF-Document@version attribute is set to "2.00".

Notes:

The XML schema in section 8, the main text in section 3.1 and every other occurrence in the document state that the IODEF-Document@version attribute has a fixed value of "2.00".

The impact of this change on the overall technical meaning is limited since the incompatibility with IODEF v1 still remains, plus, every other reference to this attribute is correct.

Errata ID: 6170
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: François Poirotte
Date Reported: 2020-05-11

Section 3.29.3.1 says:

   The attributes of the BulkObservable class are:

   type
      Optional.  ENUM.  The type of the observable listed in the child
      ObservableList class.  These values are maintained in the
      "BulkObservable-type" IANA registry per Section 10.2.

      1.   asn.  Autonomous System Number (per the Address@category
           attribute).

      2.   atm.  Asynchronous Transfer Mode (ATM) address (per the
           Address@category attribute).

      3.   e-mail.  Email address (per the Address@category attribute).

      4.   ipv4-addr.  IPv4 host address in dotted-decimal notation,
           e.g., 192.0.2.1 (per the Address@category attribute).

      5.   ipv4-net.  IPv4 network address in dotted-decimal notation,
           slash, significant bits, e.g., 192.0.2.0/24 (per the
           Address@category attribute).

      6.   ipv4-net-mask.  IPv4 network address in dotted-decimal
           notation, slash, network mask in dotted-decimal notation,
           i.e., 192.0.2.0/255.255.255.0 (per the Address@category
           attribute).

      7.   ipv6-addr.  IPv6 host address, e.g., 2001:DB8::3 (per the
           Address@category attribute).

      8.   ipv6-net.  IPv6 network address, slash, significant bits,
           e.g., 2001:DB8::/32 (per the Address@category attribute).

      9.   ipv6-net-mask.  IPv6 network address, slash, network mask
           (per the Address@category attribute).

      10.  mac.  Media Access Control (MAC) address, i.e., a:b:c:d:e:f
           (per the Address@category attribute).

      11.  site-uri.  A URL or URI for a resource (per the
           Address@category attribute).

      12.  domain-name.  A fully qualified domain name or part of a name
           (e.g., fqdn.example.com, example.com).

      13.  domain-to-ipv4.  A mapping of FQDN to IPv4 address specified
           as a comma-separated list (e.g., "fqdn.example.com,
           192.0.2.1").

      14.  domain-to-ipv6.  A mapping of FQDN to IPv6 address specified
           as a comma-separated list (e.g., "fqdn.example.com,
           2001:DB8::3").

      15.  domain-to-ipv4-timestamp.  Same as domain-to-ipv4 but with a
           timestamp (in the DATETIME format) of the resolution (e.g.,
           "fqdn.example.com, 192.0.2.1, 2015-06-11T00:38:31-06:00").

      16.  domain-to-ipv6-timestamp.  Same as domain-to-ipv6 but with a
           timestamp (in the DATETIME format) of the resolution (e.g.,
           "fqdn.example.com, 2001:DB8::3, 2015-06-11T00:38:31-06:00").

      17.  ipv4-port.  An IPv4 address, port, and protocol tuple (e.g.,
           192.0.2.1, 80, TCP).  The protocol name corresponds to the
           "Keyword" column in the "Assigned Internet Protocol Numbers"
           registry [IANA.Protocols].

      18.  ipv6-port.  An IPv6 address, port, and protocol tuple (e.g.,
           2001:DB8::3, 80, TCP).  The protocol name corresponds to the
           "Keyword" column in the "Assigned Internet Protocol Numbers"
           registry [IANA.Protocols].

      19.  windows-reg-key.  A Microsoft Windows registry key.

      20.  file-hash.  A file hash.  The format of this hash is
           described in the Hash class that MUST be present in a sibling
           BulkObservableFormat class.

It should say:

   The attributes of the BulkObservable class are:

   type
      Optional.  ENUM.  The type of the observable listed in the child
      ObservableList class.  These values are maintained in the
      "BulkObservable-type" IANA registry per Section 10.2.

      1.   asn.  Autonomous System Number (per the Address@category
           attribute).

      2.   atm.  Asynchronous Transfer Mode (ATM) address (per the
           Address@category attribute).

      3.   e-mail.  Email address (per the Address@category attribute).

      4.   ipv4-addr.  IPv4 host address in dotted-decimal notation,
           e.g., 192.0.2.1 (per the Address@category attribute).

      5.   ipv4-net.  IPv4 network address in dotted-decimal notation,
           slash, significant bits, e.g., 192.0.2.0/24 (per the
           Address@category attribute).

      6.   ipv4-net-mask.  IPv4 network address in dotted-decimal
           notation, slash, network mask in dotted-decimal notation,
           i.e., 192.0.2.0/255.255.255.0 (per the Address@category
           attribute).

      7.   ipv6-addr.  IPv6 host address, e.g., 2001:DB8::3 (per the
           Address@category attribute).

      8.   ipv6-net.  IPv6 network address, slash, significant bits,
           e.g., 2001:DB8::/32 (per the Address@category attribute).

      9.   ipv6-net-mask.  IPv6 network address, slash, network mask
           (per the Address@category attribute).

      10.  mac.  Media Access Control (MAC) address, i.e., a:b:c:d:e:f
           (per the Address@category attribute).

      11.  site-uri.  A URL or URI for a resource (per the
           Address@category attribute).

      12.  domain-name.  A fully qualified domain name or part of a name
           (e.g., fqdn.example.com, example.com).

      13.  domain-to-ipv4.  A mapping of FQDN to IPv4 address specified
           as a comma-separated list (e.g., "fqdn.example.com,
           192.0.2.1").

      14.  domain-to-ipv6.  A mapping of FQDN to IPv6 address specified
           as a comma-separated list (e.g., "fqdn.example.com,
           2001:DB8::3").

      15.  domain-to-ipv4-timestamp.  Same as domain-to-ipv4 but with a
           timestamp (in the DATETIME format) of the resolution (e.g.,
           "fqdn.example.com, 192.0.2.1, 2015-06-11T00:38:31-06:00").

      16.  domain-to-ipv6-timestamp.  Same as domain-to-ipv6 but with a
           timestamp (in the DATETIME format) of the resolution (e.g.,
           "fqdn.example.com, 2001:DB8::3, 2015-06-11T00:38:31-06:00").

      17.  ipv4-port.  An IPv4 address, port, and protocol tuple (e.g.,
           192.0.2.1, 80, TCP).  The protocol name corresponds to the
           "Keyword" column in the "Assigned Internet Protocol Numbers"
           registry [IANA.Protocols].

      18.  ipv6-port.  An IPv6 address, port, and protocol tuple (e.g.,
           2001:DB8::3, 80, TCP).  The protocol name corresponds to the
           "Keyword" column in the "Assigned Internet Protocol Numbers"
           registry [IANA.Protocols].

      19.  windows-reg-key.  A Microsoft Windows registry key.

      20.  file-hash.  A file hash.  The format of this hash is
           described in the Hash class that MUST be present in the child
           BulkObservableFormat class.

Notes:

The description for the "file-hash" type implies that the BulkObservableFormat class (3.29.3.1.1) is a sibling of the BulkObservable class (section 3.29.3.1).

This is simply not the case:
* BulkObservable only appears as an aggregate class of Observable (3.29.3)
* BulkObservableFormat is not one of Observable's aggregate classes

Since the BulkObservable class actually has an aggregate class named BulkObservableFormat, the intent was probably to just use that child class to define the hash's format.

Errata ID: 6177
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: François Poirotte
Date Reported: 2020-05-17

Section 3.26 says:

3.26.  HashData Class

   The HashData class describes different types of hashes on a given
   object (e.g., file, part of a file, email).

   +--------------------------+
   | HashData                 |
   +--------------------------+
   | ENUM scope               |<>--{0..1}--[ HashTargetID ]
   |                          |<>--{0..*}--[ Hash         ]
   |                          |<>--{0..*}--[ FuzzyHash    ]
   +--------------------------+

                       Figure 54: The HashData Class

It should say:

3.26.  HashData Class

   The HashData class describes different types of hashes on a given
   object (e.g., file, part of a file, email).

   +--------------------------+
   | HashData                 |
   +--------------------------+
   | ENUM scope               |<>--{0..1}--[ HashTargetID ]
   | STRING ext-scope         |<>--{0..*}--[ Hash         ]
   |                          |<>--{0..*}--[ FuzzyHash    ]
   +--------------------------+

                       Figure 54: The HashData Class

Notes:

Both the main body inside section 3.26 & the XML schema in section 8 mention "ext-scope" as a valid attribute of the HashData class, but the attribute was missing from the UML diagram in section 3.26.

(The attribute is necessary so that the "scope" attribute of HashData can be extended using the principles edicted in section 5.1.1)

RFC 7976, "Updates to Private Header (P-Header) Extension Usage in Session Initiation Protocol (SIP) Requests and Responses", September 2016

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: art

Errata ID: 5393
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Roland Jesske
Date Reported: 2018-06-15

Section 3 says:

3.  Updates to RFC 7315

   This section implements the update to Section 5.7 of RFC 7315, in
   order to implement the misalignment fixes and the 3GPP requirements
   described in Section 2.

   Old text:

   The P-Associated-URI header field can appear in SIP REGISTER method
   and 2xx resonses [sic].  The P-Called-Party-ID header field can
   appear in SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE
   methods and all responses.  The P-Visited-Network-ID header field can
   appear in all SIP methods except ACK, BYE, and CANCEL and all
   responses.  The P-Access-Network-Info header field can appear in all
   SIP methods except ACK and CANCEL.  The P-Charging-Vector header
   field can appear in all SIP methods except CANCEL.  The
   P-Charging-Function-Addresses header field can appear in all SIP
   methods except ACK and CANCEL.

   New text:

   The P-Associated-URI header field can appear in SIP REGISTER 2xx
   responses.  The P-Called-Party-ID header field can appear in the SIP
   INVITE, OPTIONS, PUBLISH, REFER, SUBSCRIBE, and MESSAGE methods.  The
   P-Visited-Network-ID header field can appear in all SIP methods
   except ACK, BYE, CANCEL, NOTIFY, PRACK, INFO, and UPDATE.  The
   P-Access-Network-Info header field can appear in all SIP methods and
   non-100 responses, except in CANCEL methods, CANCEL responses, and
   ACK methods triggered by non-2xx responses.  The P-Charging-Vector
   header field can appear in all SIP methods and non-100 responses,
   except in CANCEL methods, CANCEL responses, and ACK methods triggered
   by non-2xx responses.  The P-Charging-Function-Addresses header field
   can appear in all SIP methods and non-100 responses, except in CANCEL
   methods, CANCEL responses, and ACK methods.

It should say:

3.  Updates to RFC 7315

   This section implements the update to Section 5.7 of RFC 7315, in
   order to implement the misalignment fixes and the 3GPP requirements
   described in Section 2.

   Old text:

   The P-Associated-URI header field can appear in SIP REGISTER method
   and 2xx resonses [sic].  The P-Called-Party-ID header field can
   appear in SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE
   methods and all responses.  The P-Visited-Network-ID header field can
   appear in all SIP methods except ACK, BYE, and CANCEL and all
   responses.  The P-Access-Network-Info header field can appear in all
   SIP methods except ACK and CANCEL.  The P-Charging-Vector header
   field can appear in all SIP methods except CANCEL.  The
   P-Charging-Function-Addresses header field can appear in all SIP
   methods except ACK and CANCEL.

   New text:

   The P-Associated-URI header field can appear in SIP REGISTER 2xx
   responses.  The P-Called-Party-ID header field can appear in the SIP
   INVITE, OPTIONS, PUBLISH, REFER, SUBSCRIBE, and MESSAGE methods.  The
   P-Visited-Network-ID header field can appear in all SIP methods
   except ACK, BYE, CANCEL, NOTIFY, PRACK, INFO, and UPDATE and all
   responses exept 100.  The
   P-Access-Network-Info header field can appear in all SIP methods and
   non-100 responses, except in CANCEL methods, CANCEL responses, and
   ACK methods triggered by non-2xx responses.  The P-Charging-Vector
   header field can appear in all SIP methods and non-100 responses,
   except in CANCEL methods, CANCEL responses, and ACK methods triggered
   by non-2xx responses.  The P-Charging-Function-Addresses header field
   can appear in all SIP methods and non-100 responses, except in CANCEL
   methods, CANCEL responses, and ACK methods.

Notes:

The Third Generation Partnership Project (3GPP) has identified cases
where the private header field P-Visited-Network-ID SIP private
header extensions, which is defined in RFC 7315 and updated by RFC
7976, needs to be included in SIP requests and responses. This
eratta updates RFC 7976, in order to allow inclusion of the P-
Visited-Network-ID header field in responses exept 100.
The issue was also discussed within a 3GPP - IETF coordination meeting.

RFC 7991, "The "xml2rfc" Version 3 Vocabulary", December 2016

Source of RFC: IAB

Errata ID: 6574
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2021-05-06

Section 5 says:

   Using escaping:
   <sourcecode>
      allowed-chars = "." | "," | "&amp;" | "&lt;" | "&gt;" | "|"
   </sourcecode>

It should say:

   Using escaping:
   <sourcecode>
      allowed-chars = "." | "," | "&amp;" | "&lt;" | ">" | "|"
   </sourcecode>

Notes:

The example suggests that ">" needs to be escaped in absence of CDATA. This is not correct. This is a problem, as the intent of this section is to actually describe escaping *precisely*.

RFC 7996, "SVG Drawings for RFCs: SVG 1.2 RFC", December 2016

Source of RFC: IAB

Errata ID: 6213
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Levine
Date Reported: 2020-06-23

Section 1 says:

      Graphics may include ASCII art and a more complex form to be
      defined, such as SVG line art [SVG].

It should say:

      Graphics may include ASCII art and a more complex form to be
      defined, such as SVG line art [W3C.REC-SVG11-20110816].

Notes:

There is no [SVG] reference. I think that's the most likely candidate.
Sending this in so we don't forget to fix it in a future revision.

RFC 7997, "The Use of Non-ASCII Characters in RFCs", December 2016

Source of RFC: IAB

Errata ID: 7808
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Klensin
Date Reported: 2024-02-10

Section 1 says:

Please review the PDF version of this draft.

It should say:

Please review the "PDF with images" version of this draft.

Notes:

This may not be precisely an erratum, but this seems like the right place to report and record it. While the above statement points to the PDF version (as explained further on, to be able to see the non-ASCII characters), if one goes to https://www.rfc-editor.org/search/rfc_search_detail.php for this RFC and clicks on "PDF" one gets a PDF rendering that is substantially identical to the text version, i.e., the non-ASCII characters do not appear. "PDF with images" works, but that is not what the specification says.

And, while I'm whining, the use of the term "draft" in that sentence is inappropriate and should have been caught during editing.

RFC 7998, ""xml2rfc" Version 3 Preparation Tool Description", December 2016

Source of RFC: IAB

Errata ID: 7169
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Carsten Bormann
Date Reported: 2022-10-16

Section 5.5.1 says:

   5.  If an <artwork> element has type='binary-art', the data needs to
       be in an "src" attribute with a URI scheme of "data:".  If the
       "src" URI scheme is "file:", "http:", or "https:", resolve the
       URL.  Replace the "src" attribute with a "data:" URI, and add an
       "originalSrc" attribute with the value of the URI.  For the
       "http:" and "https:" URI schemes, the mediatype of the "data:"
       URI will be the Content-Type of the HTTP response.  For the
       "file:" URI scheme, the mediatype of the "data:" URI needs to be
       guessed with heuristics (this is possibly a bad idea).  This also
       fails for content that includes binary images but uses a type
       other than "binary-art".  Note: since this feature can't be used
       for RFCs at the moment, this entire feature might be

It should say:

   5.  There is no step 5.

Notes:

binary-art is an undefined concept in RFC799x. This paragraph appears to be a remnant of an earlier attempt to accommodate something called that way, but the process didn't even result in a complete sentence (and certainly not any semantics).
'binary-art' needs to be removed from RFC 7998 (and its apocryphal mention in RFC 7991) as its presence is actively confusing.

RFC 8011, "Internet Printing Protocol/1.1: Model and Semantics", January 2017

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 6085
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Thomas Urban
Date Reported: 2020-04-10

Section 5.1.4 says:

The 'keyword' attribute syntax is a sequence of characters, of length
1 to 255, containing only the US-ASCII [RFC20] encoded values for
lowercase letters ("a"-"z"), digits ("0"-"9"), hyphen ("-"), dot
("."), and underscore ("_").  The first character MUST be a lowercase
letter.

It should say:

The 'keyword' attribute syntax is a sequence of characters, of length 
1 to 255, containing only the US-ASCII [RFC20] encoded values for 
uppercase letters ("A"-"Z"), lowercase letters ("a"-"z"), digits ("0"-"9"), 
hyphen ("-"), dot ("."), and underscore ("_"). The first character SHOULD be 
a lowercase letter, and all letters SHOULD be lowercase. 

Notes:

First, the "keyword" syntax is applicable to values of enumerations according to Section 5.1.5 stating

Each value has an associated 'keyword' name.

However, Section 5.4.15 is declaring some enum-type attribute with names per integer value using uppercase letters in violation of Section 5.1.4. Those names are commonly used all over the specification and thus it is rather common to assume those values are meant to be keyword-compliant names of given enumeration.

Second, Section 5.1.4 is stating

The first character MUST be a lowercase letter.

referring to "a"-"z" according to enumeration of accepted characters given right before that. In opposition to that statement 5.4.14 is declaring

The following standard 'keyword' values are defined in this document:

* '1.0' [..]
* '1.1' [..]

Neither of the two "keywords" start with a lowercase letter.

RFC 8016, "Mobility with Traversal Using Relays around NAT (TURN)", November 2016

Source of RFC: tram (tsv)

Errata ID: 7418
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Md Nazmus Shakeeb
Date Reported: 2023-04-11

Section 3.2.1 says:

If the client's IP address or source port has changed and the client wants to retain the existing allocation, the client includes the MOBILITY-TICKET
attribute received in the Allocate success response in the Refresh
request.  If there has been no IP address or source port number
change, the client MUST NOT include a MOBILITY-TICKET attribute, as
this would be rejected by the server and the client would need to
retransmit the Refresh request without the MOBILITY-TICKET attribute

It should say:

When the client wants to retain the existing allocation, the client includes the MOBILITY-TICKET attribute received in the Allocate success response in the Refresh
request.  If there has been no IP address or source port number
change, the client MUST NOT include a MOBILITY-TICKET attribute, as
this would be rejected by the server and the client would need to
retransmit the Refresh request without the MOBILITY-TICKET attribute

Notes:

Here client's IP address and port are the STUN-mapped IP address and port.

How client will know that its IP address or source port has been changed?

It can be changed transparently where the client is not aware of it.

One way is to query it by STUN binding request before sending every STUN message
but this is not a feasible solution because of the huge overhead.

The best will be if the turnserver can inform the client about the changes.

The RFC should consider this otherwise it will not be very useful.

RFC 8028, "First-Hop Router Selection by Hosts in a Multi-Prefix Network", November 2016

Source of RFC: 6man (int)

Errata ID: 6035
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Fernando Gont
Date Reported: 2020-04-01

Section 3.1 says:

It should say:

In the context of this document, it is clear that the prefix information becomes more associated with the sending router, than with the link as a whole. As such, the PIO lifetimes should be interpreted to indicate the view of the router sending the Router Advertisement, as opposed to absolute information about a prefix.

For example, if two routers (say, Router A and Router B), advertise the prefix 2001:db8::/64 as:

* Router A:
A=1, L=1, PIO: 2001:db8::/64, Valid Lifetime=0, Preferred Lifetime=0

* Router B:
A=1, L=1, PIO: 2001:db8::/64, Valid Lifetime=X, Preferred Lifetime=Z

then, addresses should be configured/maintained with a Valid Lifetime of X, and a Preferred Lifetime of Z. Furthermore, the prefix should be considered on-link with a Valid Lifetime of X.  And Router B should be employed as the preferred next hop for packets sourced from the prefix 2001:db8::/64, since it advertises the prefix with a non-zero Valid Lifetime and non-zero Preferred Lifetime (as opposed to Router A).

As long as one router on the local subnet considers a prefix to be Valid (and possibly Preferred), the prefix should be considered Valid (and Preferred, if applicable). Similarly, as long as one router on the local subnet considers the prefix to be on-link and/or usable for auto-configuration, the prefix should be considered as such.

Notes:

This is not a bug in RFC 8028, but rather a clarification on what's likely a desired behavior. As such, and if considered appropriate, this errata is meant to be "held for document update".

I would like to thank Fred Baker and Brian Carpenter for taking the time to answer my questions on RFC 8028.

Errata ID: 7009
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Brian Carpenter
Date Reported: 2022-06-30

Section Abstract says:

However, the selection of the source address for a
packet is done before the first-hop router for that packet is chosen.

It should say:

However, the selection of the source address for a
packet is done in some cases before the first-hop router
for that packet is chosen.

Notes:

This change recognizes the fact that while server applications commonly
bind to a specific source address before sending a packet, client
applications commonly do not do so. (Also see following erratum.)

Errata ID: 7010
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Brian Carpenter
Date Reported: 2022-06-30

Section 3.3 says:

There is an interaction with Default Address Selection [RFC6724].

It should say:

There is an interaction with Default Address Selection [RFC6724] in the
case that an application does not explicitly specify the source address
to be used.

Notes:

This change recognizes the fact that while server applications commonly
bind to a specific source address before sending a packet, client
applications commonly do not do so. (See previous erratum)

RFC 8032, "Edwards-Curve Digital Signature Algorithm (EdDSA)", January 2017

Source of RFC: IRTF

Errata ID: 5968
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Valeria Nikolaenko
Date Reported: 2020-01-28

Section 3.1 says:

3.1.  Encoding

   An integer 0 < S < L - 1 is encoded in little-endian form as a b-bit
   string ENC(S).

It should say:

3.1.  Encoding

   An integer 0 <= S <= L - 1 is encoded in little-endian form as a b-bit
   string ENC(S).

Notes:

The range of the scalar should include the end-points: 0 and L-1.

Errata ID: 6306
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Dmitry Khovratovich
Date Reported: 2020-10-15

Section 5.1.7 says:

       Decode the first half as a
       point R, and the second half as an integer S, in the range
       0 <= s < L.  Decode the public key A as point A'.  If any of the
       decodings fail (including S being out of range), the signature is
       invalid.

   2.  Compute SHA512(dom2(F, C) || R || A || PH(M)), and interpret the
       64-octet digest as a little-endian integer k.

   3.  Check the group equation [8][S]B = [8]R + [8][k]A'.  It's
       sufficient, but not required, to instead check [S]B = R + [k]A'.

It should say:

       Decode the first half R as a
       point R', and the second half as an integer S, in the range
       0 <= S < L.  Decode the public key A as point A'.  If any of the
       decodings fail (including S being out of range), the signature is
       invalid.

   2.  Compute SHA512(dom2(F, C) || R || A || PH(M)), and interpret the
       64-octet digest as a little-endian integer k.

   3.  Check the group equation [8][S]B = [8]R' + [8][k]A'.  It's
       sufficient, but not required, to instead check [S]B = R' + [k]A'.

Notes:

1) public key R' and its encoding R are confused
2) s changed to S (this errata has been reported already)

Errata ID: 6348
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: David Benjamin
Date Reported: 2020-12-02

Section 3.4 says:

Compute h = H(ENC(R) || ENC(A) || M), and check the group
equation [2^c * S] B = 2^c * R + [2^c * h] A in E.

It should say:

Compute h = H(ENC(R) || ENC(A) || M), and check the group
equation [2^c * S] B = [2^c] R + [2^c * h] A in E.

Notes:

Section 2 uses a separate notation, [n]X, for point multiplication, so this operation should use the brackets.

Errata ID: 7031
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Benson Muite
Date Reported: 2022-07-24

Section 7.1 says:

   These test vectors are taken from [ED25519-TEST-VECTORS] (but we
   removed the public key as a suffix of the private key and removed the
   message from the signature) and [ED25519-LIBGCRYPT-TEST-VECTORS].

   -----TEST 1

   ALGORITHM:
   Ed25519

   SECRET KEY:
   9d61b19deffd5a60ba844af492ec2cc4
   4449c5697b326919703bac031cae7f60

   PUBLIC KEY:
   d75a980182b10ab7d54bfed3c964073a
   0ee172f3daa62325af021a68f707511a

   MESSAGE (length 0 bytes):

   SIGNATURE:
   e5564300c360ac729086e2cc806e828a
   84877f1eb8e5d974d873e06522490155
   5fb8821590a33bacc61e39701cf9b46b
   d25bf5f0595bbe24655141438e7a100b

   -----TEST 2

   ALGORITHM:
   Ed25519

   SECRET KEY:
   4ccd089b28ff96da9db6c346ec114e0f
   5b8a319f35aba624da8cf6ed4fb8a6fb

   PUBLIC KEY:
   3d4017c3e843895a92b70aa74d1b7ebc
   9c982ccf2ec4968cc0cd55f12af4660c

   MESSAGE (length 1 byte):
   72

   SIGNATURE:
   92a009a9f0d4cab8720e820b5f642540
   a2b27b5416503f8fb3762223ebdb69da
   085ac1e43e15996e458f3613d0f11d8c
   387b2eaeb4302aeeb00d291612bb0c00



Josefsson & Liusvaara         Informational                    [Page 24]


RFC 8032                EdDSA: Ed25519 and Ed448            January 2017


   -----TEST 3

   ALGORITHM:
   Ed25519

   SECRET KEY:
   c5aa8df43f9f837bedb7442f31dcb7b1
   66d38535076f094b85ce3a2e0b4458f7

   PUBLIC KEY:
   fc51cd8e6218a1a38da47ed00230f058
   0816ed13ba3303ac5deb911548908025

   MESSAGE (length 2 bytes):
   af82

   SIGNATURE:
   6291d657deec24024827e69c3abe01a3
   0ce548a284743a445e3680d7db5ac3ac
   18ff9b538d16f290ae67f760984dc659
   4a7c15e9716ed28dc027beceea1ec40a

   -----TEST 1024

   ALGORITHM:
   Ed25519

   SECRET KEY:
   f5e5767cf153319517630f226876b86c
   8160cc583bc013744c6bf255f5cc0ee5

   PUBLIC KEY:
   278117fc144c72340f67d0f2316e8386
   ceffbf2b2428c9c51fef7c597f1d426e

   MESSAGE (length 1023 bytes):
   08b8b2b733424243760fe426a4b54908
   632110a66c2f6591eabd3345e3e4eb98
   fa6e264bf09efe12ee50f8f54e9f77b1
   e355f6c50544e23fb1433ddf73be84d8
   79de7c0046dc4996d9e773f4bc9efe57
   38829adb26c81b37c93a1b270b20329d
   658675fc6ea534e0810a4432826bf58c
   941efb65d57a338bbd2e26640f89ffbc
   1a858efcb8550ee3a5e1998bd177e93a
   7363c344fe6b199ee5d02e82d522c4fe
   ba15452f80288a821a579116ec6dad2b
   3b310da903401aa62100ab5d1a36553e
   06203b33890cc9b832f79ef80560ccb9
   a39ce767967ed628c6ad573cb116dbef
   efd75499da96bd68a8a97b928a8bbc10
   3b6621fcde2beca1231d206be6cd9ec7
   aff6f6c94fcd7204ed3455c68c83f4a4
   1da4af2b74ef5c53f1d8ac70bdcb7ed1
   85ce81bd84359d44254d95629e9855a9
   4a7c1958d1f8ada5d0532ed8a5aa3fb2
   d17ba70eb6248e594e1a2297acbbb39d
   502f1a8c6eb6f1ce22b3de1a1f40cc24
   554119a831a9aad6079cad88425de6bd
   e1a9187ebb6092cf67bf2b13fd65f270
   88d78b7e883c8759d2c4f5c65adb7553
   878ad575f9fad878e80a0c9ba63bcbcc
   2732e69485bbc9c90bfbd62481d9089b
   eccf80cfe2df16a2cf65bd92dd597b07
   07e0917af48bbb75fed413d238f5555a
   7a569d80c3414a8d0859dc65a46128ba
   b27af87a71314f318c782b23ebfe808b
   82b0ce26401d2e22f04d83d1255dc51a
   ddd3b75a2b1ae0784504df543af8969b
   e3ea7082ff7fc9888c144da2af58429e
   c96031dbcad3dad9af0dcbaaaf268cb8
   fcffead94f3c7ca495e056a9b47acdb7
   51fb73e666c6c655ade8297297d07ad1
   ba5e43f1bca32301651339e22904cc8c
   42f58c30c04aafdb038dda0847dd988d
   cda6f3bfd15c4b4c4525004aa06eeff8
   ca61783aacec57fb3d1f92b0fe2fd1a8
   5f6724517b65e614ad6808d6f6ee34df
   f7310fdc82aebfd904b01e1dc54b2927
   094b2db68d6f903b68401adebf5a7e08
   d78ff4ef5d63653a65040cf9bfd4aca7
   984a74d37145986780fc0b16ac451649
   de6188a7dbdf191f64b5fc5e2ab47b57
   f7f7276cd419c17a3ca8e1b939ae49e4
   88acba6b965610b5480109c8b17b80e1
   b7b750dfc7598d5d5011fd2dcc5600a3
   2ef5b52a1ecc820e308aa342721aac09
   43bf6686b64b2579376504ccc493d97e
   6aed3fb0f9cd71a43dd497f01f17c0e2
   cb3797aa2a2f256656168e6c496afc5f
   b93246f6b1116398a346f1a641f3b041
   e989f7914f90cc2c7fff357876e506b5
   0d334ba77c225bc307ba537152f3f161
   0e4eafe595f6d9d90d11faa933a15ef1
   369546868a7f3a45a96768d40fd9d034
   12c091c6315cf4fde7cb68606937380d
   b2eaaa707b4c4185c32eddcdd306705e
   4dc1ffc872eeee475a64dfac86aba41c
   0618983f8741c5ef68d3a101e8a3b8ca
   c60c905c15fc910840b94c00a0b9d0

   SIGNATURE:
   0aab4c900501b3e24d7cdf4663326a3a
   87df5e4843b2cbdb67cbf6e460fec350
   aa5371b1508f9f4528ecea23c436d94b
   5e8fcd4f681e30a6ac00a9704a188a03

   -----TEST SHA(abc)

   ALGORITHM:
   Ed25519

   SECRET KEY:
   833fe62409237b9d62ec77587520911e
   9a759cec1d19755b7da901b96dca3d42

   PUBLIC KEY:
   ec172b93ad5e563bf4932c70e1245034
   c35467ef2efd4d64ebf819683467e2bf

   MESSAGE (length 64 bytes):
   ddaf35a193617abacc417349ae204131
   12e6fa4e89a97ea20a9eeee64b55d39a
   2192992a274fc1a836ba3c23a3feebbd
   454d4423643ce80e2a9ac94fa54ca49f

   SIGNATURE:
   dc2a4459e7369633a52b1bf277839a00
   201009a3efbf3ecb69bea2186c26b589
   09351fc9ac90b3ecfdfbc7c66431e030
   3dca179c138ac17ad9bef1177331a704
   -----

It should say:

   These test vectors are taken from [ED25519-TEST-VECTORS] (but we
   removed the public key as a suffix of the private key and removed the
   message from the signature) and [ED25519-LIBGCRYPT-TEST-VECTORS]. Test
   vectors 100-111 are taken from "Taming the many EdDSAs" by Konstantinos 
   Chalkias, François Garillot, and Valeria Nikolaenko 
   https://eprint.iacr.org/2020/1244

   -----TEST 1

   ALGORITHM:
   Ed25519

   SECRET KEY:
   9d61b19deffd5a60ba844af492ec2cc4
   4449c5697b326919703bac031cae7f60

   PUBLIC KEY:
   d75a980182b10ab7d54bfed3c964073a
   0ee172f3daa62325af021a68f707511a

   MESSAGE (length 0 bytes):

   SIGNATURE:
   e5564300c360ac729086e2cc806e828a
   84877f1eb8e5d974d873e06522490155
   5fb8821590a33bacc61e39701cf9b46b
   d25bf5f0595bbe24655141438e7a100b

   -----TEST 2

   ALGORITHM:
   Ed25519

   SECRET KEY:
   4ccd089b28ff96da9db6c346ec114e0f
   5b8a319f35aba624da8cf6ed4fb8a6fb

   PUBLIC KEY:
   3d4017c3e843895a92b70aa74d1b7ebc
   9c982ccf2ec4968cc0cd55f12af4660c

   MESSAGE (length 1 byte):
   72

   SIGNATURE:
   92a009a9f0d4cab8720e820b5f642540
   a2b27b5416503f8fb3762223ebdb69da
   085ac1e43e15996e458f3613d0f11d8c
   387b2eaeb4302aeeb00d291612bb0c00



Josefsson & Liusvaara         Informational                    [Page 24]


RFC 8032                EdDSA: Ed25519 and Ed448            January 2017


   -----TEST 3

   ALGORITHM:
   Ed25519

   SECRET KEY:
   c5aa8df43f9f837bedb7442f31dcb7b1
   66d38535076f094b85ce3a2e0b4458f7

   PUBLIC KEY:
   fc51cd8e6218a1a38da47ed00230f058
   0816ed13ba3303ac5deb911548908025

   MESSAGE (length 2 bytes):
   af82

   SIGNATURE:
   6291d657deec24024827e69c3abe01a3
   0ce548a284743a445e3680d7db5ac3ac
   18ff9b538d16f290ae67f760984dc659
   4a7c15e9716ed28dc027beceea1ec40a

   -----TEST 1024

   ALGORITHM:
   Ed25519

   SECRET KEY:
   f5e5767cf153319517630f226876b86c
   8160cc583bc013744c6bf255f5cc0ee5

   PUBLIC KEY:
   278117fc144c72340f67d0f2316e8386
   ceffbf2b2428c9c51fef7c597f1d426e

   MESSAGE (length 1023 bytes):
   08b8b2b733424243760fe426a4b54908
   632110a66c2f6591eabd3345e3e4eb98
   fa6e264bf09efe12ee50f8f54e9f77b1
   e355f6c50544e23fb1433ddf73be84d8
   79de7c0046dc4996d9e773f4bc9efe57
   38829adb26c81b37c93a1b270b20329d
   658675fc6ea534e0810a4432826bf58c
   941efb65d57a338bbd2e26640f89ffbc
   1a858efcb8550ee3a5e1998bd177e93a
   7363c344fe6b199ee5d02e82d522c4fe
   ba15452f80288a821a579116ec6dad2b
   3b310da903401aa62100ab5d1a36553e
   06203b33890cc9b832f79ef80560ccb9
   a39ce767967ed628c6ad573cb116dbef
   efd75499da96bd68a8a97b928a8bbc10
   3b6621fcde2beca1231d206be6cd9ec7
   aff6f6c94fcd7204ed3455c68c83f4a4
   1da4af2b74ef5c53f1d8ac70bdcb7ed1
   85ce81bd84359d44254d95629e9855a9
   4a7c1958d1f8ada5d0532ed8a5aa3fb2
   d17ba70eb6248e594e1a2297acbbb39d
   502f1a8c6eb6f1ce22b3de1a1f40cc24
   554119a831a9aad6079cad88425de6bd
   e1a9187ebb6092cf67bf2b13fd65f270
   88d78b7e883c8759d2c4f5c65adb7553
   878ad575f9fad878e80a0c9ba63bcbcc
   2732e69485bbc9c90bfbd62481d9089b
   eccf80cfe2df16a2cf65bd92dd597b07
   07e0917af48bbb75fed413d238f5555a
   7a569d80c3414a8d0859dc65a46128ba
   b27af87a71314f318c782b23ebfe808b
   82b0ce26401d2e22f04d83d1255dc51a
   ddd3b75a2b1ae0784504df543af8969b
   e3ea7082ff7fc9888c144da2af58429e
   c96031dbcad3dad9af0dcbaaaf268cb8
   fcffead94f3c7ca495e056a9b47acdb7
   51fb73e666c6c655ade8297297d07ad1
   ba5e43f1bca32301651339e22904cc8c
   42f58c30c04aafdb038dda0847dd988d
   cda6f3bfd15c4b4c4525004aa06eeff8
   ca61783aacec57fb3d1f92b0fe2fd1a8
   5f6724517b65e614ad6808d6f6ee34df
   f7310fdc82aebfd904b01e1dc54b2927
   094b2db68d6f903b68401adebf5a7e08
   d78ff4ef5d63653a65040cf9bfd4aca7
   984a74d37145986780fc0b16ac451649
   de6188a7dbdf191f64b5fc5e2ab47b57
   f7f7276cd419c17a3ca8e1b939ae49e4
   88acba6b965610b5480109c8b17b80e1
   b7b750dfc7598d5d5011fd2dcc5600a3
   2ef5b52a1ecc820e308aa342721aac09
   43bf6686b64b2579376504ccc493d97e
   6aed3fb0f9cd71a43dd497f01f17c0e2
   cb3797aa2a2f256656168e6c496afc5f
   b93246f6b1116398a346f1a641f3b041
   e989f7914f90cc2c7fff357876e506b5
   0d334ba77c225bc307ba537152f3f161
   0e4eafe595f6d9d90d11faa933a15ef1
   369546868a7f3a45a96768d40fd9d034
   12c091c6315cf4fde7cb68606937380d
   b2eaaa707b4c4185c32eddcdd306705e
   4dc1ffc872eeee475a64dfac86aba41c
   0618983f8741c5ef68d3a101e8a3b8ca
   c60c905c15fc910840b94c00a0b9d0

   SIGNATURE:
   0aab4c900501b3e24d7cdf4663326a3a
   87df5e4843b2cbdb67cbf6e460fec350
   aa5371b1508f9f4528ecea23c436d94b
   5e8fcd4f681e30a6ac00a9704a188a03

   -----TEST SHA(abc)

   ALGORITHM:
   Ed25519

   SECRET KEY:
   833fe62409237b9d62ec77587520911e
   9a759cec1d19755b7da901b96dca3d42

   PUBLIC KEY:
   ec172b93ad5e563bf4932c70e1245034
   c35467ef2efd4d64ebf819683467e2bf

   MESSAGE (length 64 bytes):
   ddaf35a193617abacc417349ae204131
   12e6fa4e89a97ea20a9eeee64b55d39a
   2192992a274fc1a836ba3c23a3feebbd
   454d4423643ce80e2a9ac94fa54ca49f

   SIGNATURE:
   dc2a4459e7369633a52b1bf277839a00
   201009a3efbf3ecb69bea2186c26b589
   09351fc9ac90b3ecfdfbc7c66431e030
   3dca179c138ac17ad9bef1177331a704
   -----
-----Test 100

ALGORITHM:
Ed25519

MESSAGE:
8c93255d71dcab10e8f379c26200f3c7bd5f09d9bc3068d3ef4edeb4853022b6

PUBLIC KEY:
c7176a703d4dd84fba3c0b760d10670f2a2053fa2c39ccc64ec7fd7792ac03fa

SIGNATURE:
c7176a703d4dd84fba3c0b760d10670f2a2053fa2c39ccc64ec7fd7792ac037a0000000000000000000000000000000000000000000000000000000000000000

-----Test 101

ALGORITHM:
Ed25519

MESSAGE:
9bd9f44f4dcc75bd531b56b2cd280b0bb38fc1cd6d1230e14861d861de092e79

PUBLIC KEY:
c7176a703d4dd84fba3c0b760d10670f2a2053fa2c39ccc64ec7fd7792ac03fa

SIGNATURE:
f7badec5b8abeaf699583992219b7b223f1df3fbbea919844e3f7c554a43dd43a5bb704786be79fc476f91d3f3f89b03984d8068dcf1bb7dfc6637b45450ac04

-----Test 102

ALGORITHM:
Ed25519

MESSAGE:
aebf3f2601a0c8c5d39cc7d8911642f740b78168218da8471772b35f9d35b9ab

PUBLIC KEY:
f7badec5b8abeaf699583992219b7b223f1df3fbbea919844e3f7c554a43dd43

SIGNATURE:
c7176a703d4dd84fba3c0b760d10670f2a2053fa2c39ccc64ec7fd7792ac03fa8c4bd45aecaca5b24fb97bc10ac27ac8751a7dfe1baff8b953ec9f5833ca260e

-----Test 103

ALGORITHM:
Ed25519

MESSAGE:
9bd9f44f4dcc75bd531b56b2cd280b0bb38fc1cd6d1230e14861d861de092e79

PUBLIC KEY:
cdb267ce40c5cd45306fa5d2f29731459387dbf9eb933b7bd5aed9a765b88d4d

SIGNATURE:
9046a64750444938de19f227bb80485e92b83fdb4b6506c160484c016cc1852f87909e14428a7a1d62e9f22f3d3ad7802db02eb2e688b6c52fcd6648a98bd009

-----Test 104

ALGORITHM:
Ed25519

MESSAGE:
e47d62c63f830dc7a6851a0b1f33ae4bb2f507fb6cffec4011eaccd55b53f56c

PUBLIC KEY:
cdb267ce40c5cd45306fa5d2f29731459387dbf9eb933b7bd5aed9a765b88d4d

SIGNATURE:
160a1cb0dc9c0258cd0a7d23e94d8fa878bcb1925f2c64246b2dee1796bed5125ec6bc982a269b723e0668e540911a9a6a58921d6925e434ab10aa7940551a09

-----Test 105

ALGORITHM:
Ed25519

MESSAGE:
e47d62c63f830dc7a6851a0b1f33ae4bb2f507fb6cffec4011eaccd55b53f56c

PUBLIC KEY:
cdb267ce40c5cd45306fa5d2f29731459387dbf9eb933b7bd5aed9a765b88d4d

SIGNATURE:
21122a84e0b5fca4052f5b1235c80a537878b38f3142356b2c2384ebad4668b7e40bc836dac0f71076f9abe3a53f9c03c1ceeeddb658d0030494ace586687405

-----Test 106

ALGORITHM:
Ed25519

MESSAGE:
85e241a07d148b41e47d62c63f830dc7a6851a0b1f33ae4bb2f507fb6cffec40

PUBLIC KEY:
442aad9f089ad9e14647b1ef9099a1ff4798d78589e66f28eca69c11f582a623

SIGNATURE:
e96f66be976d82e60150baecff9906684aebb1ef181f67a7189ac78ea23b6c0e547f7690a0e2ddcd04d87dbc3490dc19b3b3052f7ff0538cb68afb369ba3a514

-----Test 107

ALGORITHM:
Ed25519

MESSAGE:
85e241a07d148b41e47d62c63f830dc7a6851a0b1f33ae4bb2f507fb6cffec40

PUBLIC KEY:
442aad9f089ad9e14647b1ef9099a1ff4798d78589e66f28eca69c11f582a623

SIGNATURE:
8ce5b96c8f26d0ab6c47958c9e68b937104cd36e13c33566acd2fe8d38aa19427e71f98a473474f2f13f06f97c20d58cc3f54b8bd0d272f42b695dd7e89a8c22

-----Test 108

ALGORITHM:
Ed25519

MESSAGE:
9bedc267423725d473888631ebf45988bad3db83851ee85c85e241a07d148b41

PUBLIC KEY:
f7badec5b8abeaf699583992219b7b223f1df3fbbea919844e3f7c554a43dd43

SIGNATURE:
ecffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff03be9678ac102edcd92b0210bb34d7428d12ffc5df5f37e359941266a4e35f0f

-----Test 109

ALGORITHM:
Ed25519

MESSAGE:
9bedc267423725d473888631ebf45988bad3db83851ee85c85e241a07d148b41

PUBLIC KEY:
f7badec5b8abeaf699583992219b7b223f1df3fbbea919844e3f7c554a43dd43

SIGNATURE:
ecffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffca8c5b64cd208982aa38d4936621a4775aa233aa0505711d8fdcfdaa943d4908

-----Test 110

ALGORITHM:
Ed25519

MESSAGE:
e96b7021eb39c1a163b6da4e3093dcd3f21387da4cc4572be588fafae23c155b

PUBLIC KEY:
ecffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff

SIGNATURE:
a9d55260f765261eb9b84e106f665e00b867287a761990d7135963ee0a7d59dca5bb704786be79fc476f91d3f3f89b03984d8068dcf1bb7dfc6637b45450ac04

-----Test 111

ALGORITHM:
Ed25519

MESSAGE:
39a591f5321bbe07fd5a23dc2f39d025d74526615746727ceefd6e82ae65c06f

PUBLIC KEY:
ecffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff

SIGNATURE:
a9d55260f765261eb9b84e106f665e00b867287a761990d7135963ee0a7d59dca5bb704786be79fc476f91d3f3f89b03984d8068dcf1bb7dfc6637b45450ac04

Notes:

Some of these vectors are not expected to validate. See https://github.com/novifinancial/ed25519-speccheck and Taming the many EdDSAs by Konstantinos Chalkias, François Garillot, and Valeria Nikolaenko https://eprint.iacr.org/2020/1244

RFC 8037, "CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE)", January 2017

Source of RFC: jose (sec)

Errata ID: 5329
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Neil Madden
Date Reported: 2018-04-17

Section 4 says:

The JSON Web Algorithm (JWA) ECDH-ES KDF construction does not mix
keys into the final shared secret.  In key exchange, such mixing
could be a bad mistake; whereas here either the receiver public key
has to be chosen maliciously or the sender has to be malicious in
order to cause problems.  In either case, all security evaporates.

It should say:

The JSON Web Algorithm (JWA) ECDH-ES KDF construction does not mix
keys into the final shared secret unless they are included in the 
"apu" or "apv" claims. It is recommended to include the public keys 
of both parties in the key derivation. 

Notes:

There are two technical errors here.

Firstly, the JWA ECDH-ES KDF does allow for mixing keys into the final shared secret via the "apu" and "apv" claims. RFC 7518 (JWA) normatively references NIST SP.800-56A, which explicitly recommends doing this.

Secondly, it is not clear what the security issue is here, as there are known security issues in some cases from *not* mixing in public keys and other identifiers, as described in SP.800-56Ar3 Appendix B, and in the Security Considerations of RFC 7748 (another normative reference), which states:

"Thus
using a public key as an identifier and knowledge of a shared secret
as proof of ownership (without including the public keys in the key
derivation) might lead to subtle vulnerabilities."

RFC 8040, "RESTCONF Protocol", January 2017

Note: This RFC has been updated by RFC 8527

Source of RFC: netconf (ops)

Errata ID: 6215
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Kent Watsen
Date Reported: 2020-06-25

Section 4.3 says:

   If a retrieval request for a data resource representing a YANG
   leaf-list or list object identifies more than one instance and XML
   encoding is used in the response, then an error response containing a
   "400 Bad Request" status-line MUST be returned by the server.  The
   error-tag value "invalid-value" is used in this case.  Note that a
   non-configuration list is not required to define any keys.  In this
   case, the retrieval of a single list instance is not possible.

Notes:

This whole paragraph should be removed because, according to Section 3.5 (Data Resource), the "list" and "leaf-leaf" themselves are not a data resources:

A data resource represents a YANG data node that is a descendant node
of a datastore resource. Each YANG-defined data node can be uniquely
targeted by the request-line of an HTTP method. Containers, leafs,
leaf-list entries, list entries, anydata nodes, and anyxml nodes are
data resources.

No GET, PUT, POST, DELETE, or PATCH example in the RFC illustrates an operation on a "list" or "leaf-list" directly (i.e., without a key, which would then represent an element of the list or leaf-list).

Errata ID: 7884
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Jernej Tuljak
Date Reported: 2024-04-05

Section 3.5.3. says:

   The following example shows how reserved characters are
   percent-encoded within a key value.  The value of "key1" contains
   a comma, single-quote, double-quote, colon, double-quote, space,
   and forward slash (,'":" /).  Note that double-quote is not a
   reserved character and does not need to be percent-encoded.  The
   value of "key2" is the empty string, and the value of "key3" is the
   string "foo".

   Example URL:

      /restconf/data/example-top:top/list1=%2C%27"%3A"%20%2F,,foo

It should say:

   The following example shows how specific characters are
   percent-encoded within a key value.  The value of "key1" contains
   a comma, single-quote, double-quote, colon, double-quote, space,
   and forward slash (,'":" /).  Note that double-quote and space are
   not reserved characters but also do not correspond to characters in
   the unreserved set and therefore need to be percent-encoded.  The
   value of "key2" is the empty string, and the value of "key3" is the
   string "foo".

   Example URL:

      /restconf/data/example-top:top/list1=%2C%27%22%3A%22%20%2F,,foo

Notes:

As explained in RFC3986, the restricted set of URI characters consists of reserved characters, unreserved characters and percent-encodings. If a character does not belong to either reserved characters or unreserved characters it can only appear as a percent-encoding in a valid URI. This restricted set of characters is defined by RFC3986, Appendix A, and does not include double-quote and space characters.

RFC 8058, "Signaling One-Click Functionality for List Email Headers", January 2017

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: art

Errata ID: 5117
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Gerald W. Lester
Date Reported: 2017-09-15

Section 8.3 says:

Content-Type: multipart/form-data; boundary=---FormBoundaryjWmhtjORrn

It should say:

Content-Type: multipart/form-data; boundary=-FormBoundaryjWmhtjORrn 

RFC 8089, "The "file" URI Scheme", February 2017

Source of RFC: appsawg (art)

Errata ID: 6501
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lars Eggert
Date Reported: 2021-03-29

Section 6 says:

   Change Controller:
      IETF <ietf@ietf.org>

It should say:

   Change Controller:
      IESG <iesg@ietf.org>

Notes:

If "the IETF" is supposed to be the change controller, that role is then held by the IESG (which also has a different email address.)

RFC 8110, "Opportunistic Wireless Encryption", March 2017

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 6182
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Jouni Malinen
Date Reported: 2020-05-19

Section 4.2 says:

   +----------+--------+-------------------+-------------+-------------+
   |   OUI    | Suite  |   Authentication  |     Key     |     Key     |
   |          |  Type  |        Type       |  Management |  derivation |
   |          |        |                   |     Type    |     type    |
   +----------+--------+-------------------+-------------+-------------+
   | 00-0F-AC |   18   |   Opportunistic   |     This    |  [RFC5869]  |
   |          |        |      Wireless     |   document  |             |
   |          |        |     Encryption    |             |             |
   +----------+--------+-------------------+-------------+-------------+

                             Table 1: OWE AKM

It should say:

   +----------+-------+------------------+-------------+---------------+
   |   OUI    | Suite |  Authentication  |     Key     |      Key      |
   |          |  Type |       Type       |  Management |   derivation  |
   |          |       |                  |     Type    |      type     |
   +----------+-------+------------------+-------------+---------------+
   | 00-0F-AC |   18  |  Opportunistic   |     This    | [IEEE802.11], |
   |          |       |     Wireless     |   document  | 12.7.1.7.2    |
   |          |       |    Encryption    |             |               |
   +----------+-------+------------------+-------------+---------------+

                             Table 1: OWE AKM

Notes:

The combination of IEEE Std 802.11-2016 and IETF RFC 8110 leaves it
somewhat vague how the PTK is to be derived from the PMK when using OWE.

IEEE 802.11 performs PTK derivation as part of the 4-way handshake using
a KDF with following parameters: KDF-Hash-Length(K, Label, Context).

RFC 5869 defines HKDF with HKDF-Extract(salt, IKM) -> PRK,
HKDF-Expand(PRK, info, L) -> OKM. It is not clear what would be "salt"
and "info" for these functions without mapping from the IEEE 802.11
terms (e.g., those "Label" and "Context"). Such mapping is missing from
RFC 8110.

Either the additional needed details for PTK derivation would need to be
provided for the OWE AKM or the IEEE 802.11 KDF would need to be used
instead of HKDF for the PTK derivation part (while other key derivations
for OWE could continue to use HKDF since they are fully defined in the
RFC).

Since there are already deployed OWE implementations that use the IEEE
802.11 KDF for this, this errata entry is suggesting a change to address
the alternative that matches such implementations.

RFC 8148, "Next-Generation Vehicle-Initiated Emergency Calls", May 2017

Source of RFC: ecrit (art)

Errata ID: 6978
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Randall Gellens
Date Reported: 2022-05-23

Section 15.1. Normative Ref says:

               <https://www.apcointl.org/
              resources/telematics/aacn-and-veds.html>

It should say:

           https://www.apcointl.org/resources/telematics/aacnveds/
           veds-scheme-a-supporting-documentation/

Notes:

The URL was changed during the RFC preparation process.

RFC 8152, "CBOR Object Signing and Encryption (COSE)", July 2017

Note: This RFC has been obsoleted by RFC 9052, RFC 9053

Source of RFC: cose (sec)

Errata ID: 6597
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Anders Rundgren
Date Reported: 2021-06-03

Section 12.5.1. says:

The RFC is unclear to whether Concat KDF or HKDF is to be used:

In table 20 there is an entry:
ECDH-ES +  -31   | HKDF -  | yes        | A256KW | ECDH ES w/    |
   | A256KW    |       | SHA-256 |            |        | Concat KDF    |
   |           |       |         |            |        | and AES Key   |
   |           |       |         |            |        | Wrap w/       |
   |           |       |         |            |        | 256-bit key  

That is, the table talks both about Concat and HKDF.

The IANA registry for this algorithm says Concat KDF

Jim's sample code for algorithm -31 says HKDF.

It should say:

I have no corrected text to offer since I don't have the answer to the question raised.

Concat is referred to once and without any external references.  In JOSE, Concat denotes a NIST standard which is quite different to HKDF.

Notes:

It is pretty vital for interoperability knowing if Concat KDF or HKDF is to be used.

Errata ID: 6909
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Thomas Fossati
Date Reported: 2022-03-31
Edited by: RFC Editor

Section 3.1 says:

Generic_Headers = (
    ? 1 => int / tstr,  ; algorithm identifier
    ? 2 => [+label],    ; criticality
    ? 3 => tstr / int,  ; content type
    ? 4 => bstr,        ; key identifier
    ? 5 => bstr,        ; IV
    ? 6 => bstr         ; Partial IV
)

It should say:

Generic_Headers = (
    ? 1 => int / tstr,  ; algorithm identifier
    ? 2 => [+label],    ; criticality
    ? 3 => tstr / int,  ; content type
    ? 4 => bstr,        ; key identifier
    ? ( 5 => bstr //    ; IV
        6 => bstr )     ; Partial IV
)

Notes:

Section 3.1 says: "The "Initialization Vector" and "Partial Initialization Vector" header parameters MUST NOT both be present in the same security layer."

RFC 8166, "Remote Direct Memory Access Transport for Remote Procedure Call Version 1", June 2017

Note: This RFC has been updated by RFC 8797

Source of RFC: nfsv4 (wit)

Errata ID: 6528
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: David Noveck
Date Reported: 2021-04-12

Section 4.2.4 says:

A Requester MUST NOT send an RPC-over-RDMA header with the RDMA_ERROR
procedure.  A Responder MUST silently discard RDMA_ERROR procedures

It should say:

An RDMA_ERROR header cannot be sent without an assurance that, the receiver 
has posted a receive operation which its sending will satisfy.  In most cases, 
this means that a Requester (i.e. one sending RPC Calls) MUST NOT send an 
RPC-over-RDMA header with the RDMA_ERROR procedure.  Similarly, a Responder 
(i.e. one sending RPC Replies) MUST silently discard RDMA_ERROR procedures.

However, in the case of providing an RDMA_ERROR headers containing an error 
code of ERR_VERS, such a schema is not realizable, since there is no way for
a receiver who does not support a particular version, to determine whether 
an RPC Call or Reply is being sent, leaving the receiver uncertain as to whether 
it is being Addressed as a Requester or a Responder, leaving it unable to
participate in version negotiation.  In the case of version errors, the
implementation is to rely on the assumption that  forward direction requests 
are being done and reserve direction requests only done once the version is
properly negotiated.   As a result, such messages MUST NOT be sent by the 
client and MUST be silently discarded by servers.

Notes:

Even if one feels that this is not an appropriate correction, the existing text must be fixed somehow. In assuming that the terms Requester and Responder can be used this way in this context is likely to result in some implementers concluding that version errors can never be sent while other might be unabble to coonclude that given the effort expended in the spec to make such errors be interpretable by anf rpc-over-rdma version.

RFC 8200, "Internet Protocol, Version 6 (IPv6) Specification", July 2017

Source of RFC: 6man (int)

Errata ID: 6248
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Jingrong Xie
Date Reported: 2020-08-06

Section 4.5 says:

      The Per-Fragment headers must consist of the IPv6 header plus any
      extension headers that must be processed by nodes en route to the
      destination, that is, all headers up to and including the Routing
      header if present, else the Hop-by-Hop Options header if present,
      else no extension headers.

It should say:

      The Per-Fragment headers must consist of the IPv6 header plus any
      extension headers that must be processed by nodes en route to the
      destination. In the recommended order of extension headers listed 
      in section 4.1, the Per-Fragment headers include all headers up to 
      and including the Routing header if present, else the Hop-by-Hop 
      Options header if present, else no extension headers. In case the
      order of extension headers is specified, the Per-Fragment headers 
      include all headers that is required to be before the Fragment Header.

Notes:

1. As specified in in section 4.1 of RFC8200, the recommended order of existing extension headers could be revised, and there have been some examples in the RFCs that do such revision: RFC7837, RFC6275 and its related RFCs, RFC3775/RFC3776/RFC4784.
2. RFC6275 requires DoH carrying a special option to be placed before Fragmentation header. This gives an example how to support Fragmentation with the order of extension headers revised.
3. As specified in section 4.8 of RFC8200, new extension headers could be defined, and there may be some new Per-fragment header(s) defined requiring en route processing with fragmentation support.

RFC 8214, "Virtual Private Wire Service Support in Ethernet VPN", August 2017

Source of RFC: bess (rtg)

Errata ID: 6517
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexander ("Sasha") Vainshtein
Date Reported: 2021-04-05

Section 5 says:

   Finally, EVPN may employ data-plane egress link protection mechanisms
   not available in VPWS.  This can be done by the primary PE (on local
   AC down) using the label advertised in the per-EVI Ethernet A-D route
   by the backup PE to encapsulate the traffic and direct it to the
   backup PE.

It should say:

   Finally, EVPN may employ data-plane egress link protection mechanisms.
   This can be done by the primary PE (on local AC down) using the label 
   advertised in the per-EVI Ethernet A-D route by the backup PE to
   encapsulate the traffic and direct it to the backup PE.  Similar behavior
   for LDP-signaled PWs can be achieved using LDP extensions defined in RFC 8104, 
   but the EVPN-based solution is simpler to implement (e.g., does not require 
   context-specific label spaces) and operate.

Notes:

RFC 8104 "Pseudowire (PW) Endpoint Fast Failure Protection" defines a solution for egress PW endpoint protection that provides fast local protection against failure of the primary egress PE and failure of the Attachment Circuit of this PE, so that the claim that the data-plane egress link protection mechanisms are not available for LDP-signaled PWs is factually inaccurate. However, the solution defined in RFC 8104is much more complicated both from the POV of implementation and from the operational POV, while the EVPN-based solution is quite straightforward.

Errata ID: 7562
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexander ("Sasha") Vainshtein
Date Reported: 2023-07-13

Section 3.1 says:

In a multihoming All-Active scenario, there is no Designated Forwarder (DF) election, and all the PEs in the ES that are active and ready to forward traffic to/from the CE will set the P Flag.

It should say:

In a multihoming All-Active scenario, there is no Designated Forwarder (DF) election, and all the PEs in the ES that are active and ready to forward traffic to/from the CE SHOULD set the P Flag.

Notes:

The original text in the RFC does not express any requirement level ("will" is not a recognized IETF term for expressing requirement levels as defined in RFC 2119). The new test replaces "will" with "SHOULD".

SHOULD and not MUST is proposed to avoid potential issues with implementations that did not set P flag in the L2 Attributes Extended Community in All-Active multi-homing scenarios (since this was not required) and would suddenly become non-compliant if the text were changed to from "will" to MUST.

RFC 8224, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", February 2018

Note: This RFC has been updated by RFC 8946

Source of RFC: stir (art)

Errata ID: 5390
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Invalid restriction on when to add "mky"
Date Reported: 2018-06-14

Section 12.1 says:

When signing a request that contains a fingerprint of keying material
in SDP for DTLS-SRTP [RFC5763], this mechanism always provides a
signature over that fingerprint. 

It should say:

When signing a request that contains a fingerprint
of keying material in SDP, this mechanism always 
provides a signature over that fingerprint. 

Notes:

Attack vector described in 12.1 to justify addition of "mky" is applicable for scenarios, where a fingerprint in SDP is used for reasons other than DTLS-STRP as well.
Use of fingerprint for MSRP per RFCRFC4975 is an example of this.

From RFC4975:

14.4. Using TLS in Peer-to-Peer Mode

TLS can be used with a self-signed certificate as long as there is a
mechanism for both sides to ascertain that the other side used the
correct certificate. When used with SDP and SIP, the correct
certificate can be verified by passing a fingerprint of the
certificate in the SDP and ensuring that the SDP has suitable
integrity protection. When SIP is used to transport the SDP, the
integrity can be provided by the SIP Identity mechanism [17]. The
rest of this section describes the details of this approach.

Errata ID: 5391
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Invalid content for "iat"
Date Reported: 2018-06-14

Section 4.1 says:

      Third, the JSON key "iat" MUST appear.  The authentication service
      SHOULD set the value of "iat" to an encoding of the value of the
      SIP Date header field as a JSON NumericDate (as UNIX time, per
      [RFC7519], Section 2), though an authentication service MAY set
      the value of "iat" to its own current clock time.  If the
      authentication service uses its own clock time, then the use of
      the full form of PASSporT is REQUIRED.  In either case, the
      authentication service MUST NOT generate a PASSporT for a SIP
      request if the Date header is outside of its local policy for
      freshness (sixty seconds is RECOMMENDED).

It should say:

“4.1 PASSPorT Construction”:

Third, the JSON key "iat" MUST appear. 
The authentication service SHOULD set the 
value of "iat" to an encoding of the value of 
JWT generation as a JSON NumericDate 
(as UNIX time, per [RFC7519], Section 2).

Notes:

RFC7519 JSON Web Token (JWT)

4.1.6. "iat" (Issued At) Claim

The "iat" (issued at) claim identifies the time at which the JWT was
issued. This claim can be used to determine the age of the JWT. Its
value MUST be a number containing a NumericDate value. Use of this
claim is OPTIONAL.

This text clearly states that “iat” is for the generation time of JWS.

One may argue that origination of SIP dialog - on which Date header content is based - and JWT generation times would be very close to each other but this is not always true. JWT, for example, can be added only at administrative boundaries and a session may have started long before that,e .g. it involves user interaction with an IVR for announcement/PIN verification.

It should be noted that populating "iat" with JWT issuance time makes use of complete form mandatory. So, if this errata is accepted, there probably would be a need to remove compact form as an option.

Errata ID: 5715
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Alex Lee
Date Reported: 2019-05-01

Section 4.1 says:

o  Second, the JSON "dest" array MUST be populated.  If the
   destination identity is a telephone number, then the array MUST be
   populated with a JSON object containing a "tn" element with a
   value set to the value of the quoted destination identity, a
   canonicalized telephone number (see Section 8.3).  Otherwise, the
   array MUST be populated with a JSON object containing a "uri"
   element, set to the value of the addr-spec component of the
   To header field, which is the AoR to which the request is being
   sent, per the procedures in Section 8.5.  Multiple JSON objects
   are permitted in "dest" for future compatibility reasons.

...

The "orig" and "dest" arrays may contain identifiers of heterogeneous
type; for example, the "orig" array might contain a "tn" claim, while
the "dest" contains a "uri" claim.  Also note that in some cases, the
"dest" array may be populated with more than one value.  This could,
for example, occur when multiple "dest" identities are specified in a
meshed conference.  Defining how a SIP implementation would align
multiple destination identities in PASSporT with such systems is left
as a subject for future specifications.

It should say:

o  Second, the JSON "dest" object MUST be populated.  If the
   destination identity is a telephone number, then the object MUST
   contain a "tn" element with a value set to an array containing the
   value of the quoted destination identity, a
   canonicalized telephone number (see Section 8.3).  Otherwise, the
   object MUST contain a "uri" element, set to an array containing
   the value of the addr-spec component of the
   To header field, which is the AoR to which the request is being
   sent, per the procedures in Section 8.5.  Additional elements
   are permitted in "dest" for future compatibility reasons.

...

The "orig" and "dest" objects may contain identifiers of heterogeneous
type; for example, the "orig" object might contain a "tn" claim, while
the "dest" contains a "uri" claim.  Also note that in some cases, the
"dest" object may be populated with more than one claim, and its claim
value arrays may contain more than one value.  This could,
for example, occur when multiple "dest" identities are specified in a
meshed conference.  Defining how a SIP implementation would align
multiple destination identities in PASSporT with such systems is left
as a subject for future specifications.

Notes:

The description of the "dest" element does not match RFC8225 or the example that is provided in this section.

The terminology is a bit less clear than in RFC8225 section 5.2.1, in that no differentiation is made between the top level "claims" and embedded "identity claims". The proposed correction does not address this lack of clarity, however.

From RFC8225 section 5.2.1:

The "dest" claim is a JSON object with the claim name of "dest" and
MUST have at least one identity claim object. The "dest" claim value
is an array containing one or more identity claim JSON objects
representing the destination identities of any type (currently "tn"
or "uri"). If the "dest" claim value array contains both "tn" and
"uri" claim names, the JSON object should list the "tn" array first
and the "uri" array second. Within the "tn" and "uri" arrays, the
identity strings should be put in lexicographical order, including
the scheme-specific portion of the URI characters.

(The above text might need correction as well, because it refers to the '"dest" claim value array'.)

Errata ID: 6499
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Marc Petit-Huguenin
Date Reported: 2021-03-27

Section 4 says:

Identity = "Identity" HCOLON signed-identity-digest SEMI
          ident-info *( SEMI ident-info-params )
signed-identity-digest = 1*(base64-char / ".")
ident-info = "info" EQUAL ident-info-uri
ident-info-uri = LAQUOT absoluteURI RAQUOT
ident-info-params = ident-info-alg / ident-type /
    ident-info-extension
ident-info-alg = "alg" EQUAL token
ident-type = "ppt" EQUAL token
ident-info-extension = generic-param

base64-char = ALPHA / DIGIT / "/" / "+"

It should say:

Identity = "Identity" HCOLON signed-identity-digest SEMI
          ident-info *( SEMI ident-info-params )
signed-identity-digest = 1*(base64url-char / ".")
ident-info = "info" EQUAL ident-info-uri
ident-info-uri = LAQUOT absoluteURI RAQUOT
ident-info-params = ident-info-alg / ident-type /
    ident-info-extension
ident-info-alg = "alg" EQUAL token
ident-type = "ppt" EQUAL token
ident-info-extension = generic-param

base64url-char = ALPHA / DIGIT / "-" / "_"

Notes:

RFC 8225 makes it clear that the encoding is BASE4URL, not the standard BASE64 encoding.

RFC 8225, "PASSporT: Personal Assertion Token", February 2018

Source of RFC: stir (art)

Errata ID: 5392
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Invalid "iat" content
Date Reported: 2018-06-14

Section 5.1.1 says:

 
   The JSON claim MUST include the "iat" (Issued At) claim ([RFC7519],
   Section 4.1.6).  As defined, the "iat" claim should be set to the
   date and time of issuance of the JWT and MUST indicate the date and
   time of the origination of the personal communications.  The time
   value should be of the NumericDate format as defined in [RFC7519],
   Section 2.  This is included for securing the token against replay
   and cut-and-paste attacks, as explained further in Section 10
   ("Security Considerations").
 

It should say:

The JSON claim MUST include the "iat" (Issued At) 
claim ([RFC7519], Section 4.1.6).  As defined, the 
"iat" claim should be set to the date and time of 
issuance of the JWT. The time value should be of the 
NumericDate format as defined in [RFC7519], Section 2. 
This is included for securing the token against replay 
and cut-and-paste attacks, as explained further in 
Section 10 ("Security Considerations").

Notes:

It is mentioned that “iat” should be set based on issuance of JWT (which would be when PASSPorT is constructed). OTOH, it is also stated that it MUST indicate the date and time of the origination of the personal communication. The former seems to be the right approach as what we would like to protect against cut-and-paste attacks is the PASSPorT in the context of a particular communication session. The times for these two events are not necessarily the same/close enough to be considered the same.

RFC7519 JSON Web Token (JWT)

4.1.6. "iat" (Issued At) Claim

The "iat" (issued at) claim identifies the time at which the JWT was
issued. This claim can be used to determine the age of the JWT. Its
value MUST be a number containing a NumericDate value. Use of this
claim is OPTIONAL.

This text clearly states that “iat” is for the generation time of JWS.

Errata ID: 5985
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: James Manger
Date Reported: 2020-02-20

Section 7.1 says:

eyJkZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdCI
6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0

It should say:

eyJkZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdCI
6MTQ0MzIwODM0NSwib3JpZyI6eyJ0biI6IjEyMTU1NTUxMjEyIn19Cg

Notes:

The "iat" claim in the example's JWT payload is incorrectly encoded as a string (with double-quotes around its value), instead of a number (without double-quotes).
WRONG: Base64url( ... "iat":"1443208345", ... ) = ... 6IjE0NDMyMDgzNDUiLCJv ...
RIGHT: Base64url( ... "iat":1443208345, ... ) = ... 6MTQ0MzIwODM0NSwi ...

The same example appears in Appendix A, where it is correct. I assume the JWS signature in section 7.1 should also be replaced with the value from Appendix A.

RFC 8226, "Secure Telephone Identity Credentials: Certificates", February 2018

Note: This RFC has been updated by RFC 9118

Source of RFC: stir (art)

Errata ID: 5610
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2019-01-21

Section Appendix A says:

    JWTClaimPermittedValuesList ::= SEQUENCE SIZE (1..MAX) Of
                                      JWTClaimPermittedValues

It should say:

    JWTClaimPermittedValuesList ::= SEQUENCE SIZE (1..MAX) OF
                                      JWTClaimPermittedValues

Notes:

The ASN.1 Compiler require "OF" to be all capital letters.

RFC 8239, "Data Center Benchmarking Methodology", August 2017

Source of RFC: bmwg (ops)

Errata ID: 6763
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Leonard Yu
Date Reported: 2021-11-30

Section 3.2 says:

Last iteration: Ingress port 1 sending line rate to egress
port 2, ingress port 3 sending line rate to egress port 4, etc.
Ingress port N-1 and port N will oversubscribe, at 1% of line
rate, egress port N-3 and port N-2, respectively. Measure the
buffer size value by multiplying the number of extra frames
sent by the frame size for each egress port.

It should say:

Last iteration: Ingress port 1 sending line rate to egress
port 2, ingress port 3 sending line rate to egress port 4, etc.
Ingress port N-1 and port N will oversubscribe, at 1% of line
rate, egress port N-4 and port N-3, respectively. Measure the
buffer size value by multiplying the number of extra frames
sent by the frame size for each egress port.

Notes:

If
#1, 1->2, 3->4, 5->6, 7->8, ... and N-1->2, N->3
#2, 1->2, 3->4, 5->6, 7->8, ... and N-1->4, N->5

Then
#last, 1->2, 3->4, 5->6, 7->8, ... and N-1->N-4, N->N-3

Otherwise, the general equation won't satisfy #1 and #2

Errata ID: 6768
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Leonard Yu
Date Reported: 2021-12-01

Section 3.2 says:

3) Measure maximum port pair buffer sizes.

      o  First iteration: Ingress port 1 sending line rate to egress
         port 2, ingress port 3 sending line rate to egress port 4, etc.
         Ingress port N-1 and port N will oversubscribe, at 1% of line
         rate, egress port 2 and port 3, respectively.  Measure the
         buffer size value by multiplying the number of extra frames
         sent by the frame size for each egress port.

      o  Second iteration: Ingress port 1 sending line rate to egress
         port 2, ingress port 3 sending line rate to egress port 4, etc.
         Ingress port N-1 and port N will oversubscribe, at 1% of line
         rate, egress port 4 and port 5, respectively.  Measure the
         buffer size value by multiplying the number of extra frames
         sent by the frame size for each egress port.

      o  Last iteration: Ingress port 1 sending line rate to egress
         port 2, ingress port 3 sending line rate to egress port 4, etc.
         Ingress port N-1 and port N will oversubscribe, at 1% of line
         rate, egress port N-3 and port N-2, respectively.  Measure the
         buffer size value by multiplying the number of extra frames
         sent by the frame size for each egress port.

It should say:

3) Measure maximum port pair buffer sizes.

      o  First iteration: Ingress port 1 sending line rate to egress
         port 2, ingress port 3 sending line rate to egress port 4, etc.
         Ingress port N-1 and port N will oversubscribe, at 1% of line
         rate, egress port 1 and port 2, respectively.  Measure the
         buffer size value by multiplying the number of extra frames
         sent by the frame size for each egress port.

      o  Second iteration: Ingress port 1 sending line rate to egress
         port 2, ingress port 3 sending line rate to egress port 4, etc.
         Ingress port N-1 and port N will oversubscribe, at 1% of line
         rate, egress port 3 and port 4, respectively.  Measure the
         buffer size value by multiplying the number of extra frames
         sent by the frame size for each egress port.

      o  Last iteration: Ingress port 1 sending line rate to egress
         port 2, ingress port 3 sending line rate to egress port 4, etc.
         Ingress port N-1 and port N will oversubscribe, at 1% of line
         rate, egress port N-3 and port N-2, respectively.  Measure the
         buffer size value by multiplying the number of extra frames
         sent by the frame size for each egress port.

Notes:

The oversubscribed ports are a pair of ingress and egress ports. The oversubscribed ports in the texts describing the first are port 2 & 3, which are incorrect, should be port 1 & 2. The oversubscribed ports in the texts describing the second are port 4 & 5, which are incorrect, should be port 3 & 4.

RFC 8259, "The JavaScript Object Notation (JSON) Data Interchange Format", December 2017

Source of RFC: jsonbis (art)

Errata ID: 5218
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Vasiliy Faronov
Date Reported: 2017-12-28

Section 12 says:

JSON is a subset of JavaScript

It should say:

JSON is nearly a subset of JavaScript

Notes:

JSON is not a subset of JavaScript: there are syntactically valid JSON texts that are not syntactically valid JavaScript. Namely, JSON strings can contain unescaped U+2028 LINE SEPARATOR or U+2029 PARAGRAPH SEPARATOR characters, while JavaScript string literals cannot. Thus, a sequence of characters U+0022 U+2028 U+0022 matches this RFC's 'string' production, but does not match ECMA-262's 'Expression' production.

Errata ID: 5853
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Luca BRUNO
Date Reported: 2019-09-05

Section 11 says:

Note:  No "charset" parameter is defined for this registration.
    Adding one really has no effect on compliant recipients.

It should say:

Note:  No "charset" parameter is defined for this registration.
    JSON text is encoded as described in RFC 8259, Section 8.1.

Notes:

Last sentence of last note of section 11 should be amended, as it introduces confusion by going against other explicit statements, like the followings:
* RFC8259 sect. 8.1 defines that inner encoding is UTF-8
* RFC8259 sect. 11 defines no formal (optional/required) parameters for this registered type
* RFC6838 sect. 4.2.1 defines the common usage of a "charset" parameter as a "required" one (which isn't the case here)
* RFC6838 sect. 4.2.1 defines that "charset" should not be used if the inner payload already transports charset information (e.g. mandatory UTF-8, which is the case here)
* RFC6838 sect. 4.2.1 defines a "charset" parameter only for subtypes of the "text/*" hierarchy (which isn't the case here)

Errata ID: 7383
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Daniel Tegründe
Date Reported: 2023-03-12

Section 3. Values says:

      false = %x66.61.6c.73.65   ; false

      null  = %x6e.75.6c.6c      ; null

It should say:

      false = %x66.61.6C.73.65   ; false

      null  = %x6E.75.6C.6C      ; null

Notes:

Hex values should be capitalized https://www.rfc-editor.org/rfc/rfc5234#appendix-B.1

Errata ID: 7600
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Guillaume Fortin-Debigaré
Date Reported: 2023-08-11

Section 6 says:

   The representation of numbers is similar to that used in most
   programming languages.  A number is represented in base 10 using
   decimal digits.  It contains an integer component that may be
   prefixed with an optional minus sign, which may be followed by a
   fraction part and/or an exponent part.  Leading zeros are not
   allowed.

It should say:

   The representation of numbers is similar to that used in most
   programming languages.  A number is represented in base 10 using
   decimal digits.  It contains an integer component that may be
   prefixed with an optional minus sign, which may be followed by a
   fraction part and/or an exponent part.  Leading zeros in the
   integer component beyond the units digit are not allowed.

Notes:

The original wording about leading zeros contradicts the documented ABNF grammar for JSON numbers in the following cases:
- If the integer component is equal to 0 and the fractional component exists. (Examples: 0.1, 0.001)
- In the exponent part, after the letter E or e or the optional sign. (Example: 1E01)

Errata ID: 7603
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Guillaume Fortin-Debigaré
Date Reported: 2023-08-13

Section 1 says:

   A string is a sequence of zero or more Unicode characters [UNICODE].

It should say:

   A string is a sequence of zero or more Unicode code points [UNICODE].

Notes:

Surrogate code points are not Unicode characters, as explained here: https://www.unicode.org/glossary/#surrogate_character

However, a surrogate code point outside of a surrogate pair is allowed in JSON strings both in escaped and unescaped forms according to the ABNF grammar in section 7 and the warning in section 8.2, despite an UTF-8 incompatibility for the unescaped form. In addition, the original text contradicts ECMA-404 section 9, which states: "A string is a sequence of Unicode code points wrapped with quotation marks (U+0022). All code points may be placed within the quotation marks except for the code points that must be escaped: quotation mark (U+0022), reverse solidus (U+005C), and the control characters U+0000 to U+001F. "

Errata ID: 7617
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Guillaume Fortin-Debigaré
Date Reported: 2023-08-25

Section 6 says:

   Note that when such software is used, numbers that are integers and
   are in the range [-(2**53)+1, (2**53)-1] are interoperable in the
   sense that implementations will agree exactly on their numeric
   values.

It should say:

   Note that when such software parses numbers as rational numbers in
   decimal or scientific notation, they are interoperable in the sense
   that implementations will agree exactly on their numeric values. In
   particular, when such software is used, numbers that are integers and
   are in the range [-(2**53)+1, (2**53)-1] are interoperable in that
   sense.

Notes:

IEEE 754 does not consider negative zero and positive zero to be the same numeric value, even though it considers them equal. Despite this, JavaScript serializes negative zero as the JSON text "0", which contradicts the original text.

My suggested correction mentions "rational numbers in decimal or scientific notation" since it's never explicitly mentioned in the document how a number should be interpreted when parsed to maximize interoperability. This version addresses that concern at the same time.

Errata ID: 7650
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Lucas Tesson
Date Reported: 2023-09-20

Section 7 says:

      string = quotation-mark *char quotation-mark

      char = unescaped /
          escape (
              %x22 /          ; "    quotation mark  U+0022
              %x5C /          ; \    reverse solidus U+005C
              %x2F /          ; /    solidus         U+002F
              %x62 /          ; b    backspace       U+0008
              %x66 /          ; f    form feed       U+000C
              %x6E /          ; n    line feed       U+000A
              %x72 /          ; r    carriage return U+000D
              %x74 /          ; t    tab             U+0009
              %x75 4HEXDIG )  ; uXXXX                U+XXXX

It should say:

      string = quotation-mark *json-char quotation-mark

      json-char = unescaped /
          escape (
              %x22 /          ; "    quotation mark  U+0022
              %x5C /          ; \    reverse solidus U+005C
              %x2F /          ; /    solidus         U+002F
              %x62 /          ; b    backspace       U+0008
              %x66 /          ; f    form feed       U+000C
              %x6E /          ; n    line feed       U+000A
              %x72 /          ; r    carriage return U+000D
              %x74 /          ; t    tab             U+0009
              %x75 4HEXDIG )  ; uXXXX                U+XXXX

Notes:

RFC 5234 Section 2.1 "Rule Naming" notes that "rule names are case insensitive". It is explained that literal text strings enclosed in quotation marks are case insensitive, and have later been clarified by RFC 7405.
In RFC 5234 Appendix B, Section B.1 "Core Rules", the rule "CHAR" is already defined such that it constitutes the core of ABNF, thus no grammar can use those names regarding the previous explanation.

The goal of this errata is to propose an alternative for the "char" rule such that RFC 8259 can provide a valid grammar regarding the ABNF RFCs.

Errata ID: 7673
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Zachary Collier (Zamicol)
Date Reported: 2023-10-11

Section 7 says:

The representation of strings is similar to conventions used in the C family
of programming languages.  A string begins and ends with quotation marks. All
Unicode characters may be placed within the quotation marks, except for the
characters that MUST be escaped: quotation mark, reverse solidus, and the
control characters (U+0000 through U+001F).

It should say:

The representation of strings is similar to conventions used in the C family
of programming languages.  A string begins and ends with quotation marks.  All
Unicode characters may be placed within the quotation marks, except for the
characters that MUST be escaped: quotation mark, reverse solidus, and the
control characters (U+0000 through U+001F, U+007F, and U+0080 through
U+009F).

Notes:

There are 33 7-bit control characters, but the JSON RFC only listed 32 by
omitting the inclusion of the last control character in the 7-bit ASCII range,
'del.' However, JSON is not limited to 7-bit ASCII; it is Unicode. Unicode
encompasses 65 control characters from U+0080 to U+009F, totaling an additional
32 characters. The section that currently reads "U+0000 through U+001F" should
include these additional control characters reading as "U+0000 through U+001F,
U+007F, and U+0080 through U+009F"

Errata ID: 5210
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2017-12-16

Throughout the document, when it says:

Internet Engineering Task Force (IETF)                      T. Bray, Ed.
Request for Comments: 8259                                    Textuality
Obsoletes: 7159                                            December 2017
Category: Standards Track
ISSN: 2070-1721

It should say:

Internet Engineering Task Force (IETF)                      T. Bray, Ed.
Request for Comments: 8259                                    Textuality
STD: 90                                                    December 2017
Obsoletes: 7159
Category: Standards Track
ISSN: 2070-1721

Notes:

Missing "STD" entry in boilerplate.

Errata ID: 5318
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Joakim Erdfelt
Date Reported: 2018-04-04

Section 7 says:

      string = quotation-mark *char quotation-mark

      char = unescaped /
          escape (
              %x22 /          ; "    quotation mark  U+0022
              %x5C /          ; \    reverse solidus U+005C
              %x2F /          ; /    solidus         U+002F
              %x62 /          ; b    backspace       U+0008
              %x66 /          ; f    form feed       U+000C
              %x6E /          ; n    line feed       U+000A
              %x72 /          ; r    carriage return U+000D
              %x74 /          ; t    tab             U+0009
              %x75 4HEXDIG )  ; uXXXX                U+XXXX

      escape = %x5C              ; \

      quotation-mark = %x22      ; "

      unescaped = %x20-21 / %x23-5B / %x5D-10FFFF

It should say:

      string = quotation-mark *char quotation-mark

      char = unescaped /
          escape (
              %x22 /          ; "    quotation mark  U+0022
              %x5C /          ; \    reverse solidus U+005C
              %x2F /          ; /    solidus         U+002F
              %x62 /          ; b    backspace       U+0008
              %x66 /          ; f    form feed       U+000C
              %x6E /          ; n    line feed       U+000A
              %x72 /          ; r    carriage return U+000D
              %x74 /          ; t    tab             U+0009
              %x75 4HEXDIG )  ; uXXXX                U+XXXX

      escape = %x5C              ; \

      quotation-mark = %x22      ; "

      unescaped = %x20-21 / %x23-2E / %x30-5B / %x5D-10FFFF

Notes:

The solidus U+002F is listed as being escaped above, but is not excluded in the 'unescaped' sequence.

RFC 8264, "PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols", October 2017

Source of RFC: precis (art)

Errata ID: 5478
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Occil
Date Reported: 2018-08-26

Section 9.12 says:

   L: Control(cp) = True

It should say:

   L: General_Category(cp) = Cc

Notes:

Nothing in the Unicode Standard (including UAX 44) defines a property or function named Control. What is probably meant is the General_Category property value Control, which is abbreviated Cc.

RFC 8265, "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords", October 2017

Source of RFC: precis (art)

Errata ID: 5479
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Occil
Date Reported: 2018-08-26

Section 3.1 says:

   A userpart is allowed to contain only code
   points that are allowed by the PRECIS IdentifierClass defined in
   Section 4.2 of [RFC8264] and thus consists almost exclusively of
   letters and digits.

It should say:

   A userpart is allowed to contain only code
   points that are allowed by the PRECIS IdentifierClass defined in
   Section 4.2 of [RFC8264] (with respect to the userpart containing
   them, not to the username as a whole) and thus consists almost 
   exclusively of letters and digits.

Notes:

Because certain characters in IdentifierClass are CONTEXTO and are not valid unless the whole string doesn't contain certain other characters (an example is ARABIC-INDIC DIGITS), it is unclear whether the context-specific rules apply to the whole username or to individual userparts. However, section 3.5 strongly suggests that usernames (as opposed to userparts) are the matter of a higher-level protocol than this RFC. As a result, this erratum adds the text in parentheses to clarify that context-specific rules apply to individual userparts.

RFC 8270, "Increase the Secure Shell Minimum Recommended Diffie-Hellman Modulus Size to 2048 Bits", December 2017

Source of RFC: curdle (sec)

Errata ID: 5502
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eugene Adell
Date Reported: 2018-09-21

Section 5 says:

   A malicious client could cause a Denial of Service by intentionally
   making multiple connections that are less than 2048 bits in size.
   Therefore, operating systems SHOULD NOT log DH groups that are less
   than 2048 bits in size, as it would create an additional attack
   surface.

It should say:

   A malicious client could cause a Denial of Service by intentionally
   making multiple connections that are less than 2048 bits in size.
   Therefore, operating systems without any rate-limited logging 
   SHOULD NOT log DH groups that are less than 2048 bits in size, as it
   would create an additional attack surface.

Notes:

Instead of ignoring attacks, the administrator wants to know when one is taking place, particularly if it is an intense one which would lead to a denial of service, as suggested by the authors. Thus, using a rate-limited logging mechanism is an appropriate solution to keep records of the attack, and to notify the administrator in real-time then he can take actions if he wants to. As there might not be other ways to inform the administrator of an attack taking place, not logging at all is the last choice.

RFC 8275, "Allowing Inheritable NFSv4 Access Control Entries to Override the Umask", December 2017

Source of RFC: nfsv4 (wit)

Errata ID: 5198
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Neil Brown
Date Reported: 2017-12-05

Section 1 says:

The same solution should work for NFS.  However, the NFSv4 protocol
   does not currently give the client a way to transmit the umask of the
   process opening a file.  And clients have no way of atomically
   checking for inheritable permissions and applying the umask only when
   necessary.  As a result, the server receives an OPEN with a mode
   attribute that already has the umask applied.

It should say:

Implementing a comparable solution for NFS is not currently possible.
It cannot be implemented in the server as the server does not know
the umask, and the protocol does not allow the client to tell it.
It cannot be implemented in the client as the client cannot atomically
check the inheritable permissions on the containing directory and
apply the umask selectively. As a result, the server receives an
OPEN with a mode attribute that already has the umask applied.

Notes:

The intent of the paragraph is obscured by clumsy language. It is explaining how neither the server
nor the client can currently make the required decision, but this is not immediately obvious.

RFC 8276, "File System Extended Attributes in NFSv4", December 2017

Source of RFC: nfsv4 (wit)

Errata ID: 7007
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Yuri Radchenko
Date Reported: 2022-06-27

Section 8.4.5 says:

   | LISTXATTRS  | NFS4ERR_ACCESS, NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
   |             | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MOVED,           |
   |             | NFS4ERR_NAMETOOLONG, NFS4ERR_NOFILEHANDLE,          |
   |             | NFS4ERR_NOTSUPP, NFS4ERR_NOXATTR,                   |
   |             | NFS4ERR_OP_NOT_IN_SESSION, NFS4ERR_PERM,            |
   |             | NFS4ERR_REP_TOO_BIG, NFS4ERR_REP_TOO_BIG_TO_CACHE,  |
   |             | NFS4ERR_REQ_TOO_BIG, NFS4ERR_RETRY_UNCACHED_REP,    |
   |             | NFS4ERR_SERVERFAULT, NFS4ERR_STALE,                 |
   |             | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_TYPE            |

It should say:

   | LISTXATTRS  | NFS4ERR_ACCESS, NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
   |             | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MOVED,           |
   |             | NFS4ERR_NAMETOOLONG, NFS4ERR_NOFILEHANDLE,          |
   |             | NFS4ERR_NOTSUPP, NFS4ERR_NOXATTR,                   |
   |             | NFS4ERR_OP_NOT_IN_SESSION, NFS4ERR_PERM,            |
   |             | NFS4ERR_REP_TOO_BIG, NFS4ERR_REP_TOO_BIG_TO_CACHE,  |
   |             | NFS4ERR_REQ_TOO_BIG, NFS4ERR_RETRY_UNCACHED_REP,    |
   |             | NFS4ERR_SERVERFAULT, NFS4ERR_STALE,                 |
   |             | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_TYPE,           |
   |             | NFS4ERR_BAD_COOKIE                                  |

Notes:

rfc says
"The handling of a cookie is similar to that of the READDIR operation."
(8.4.3.4.)

It would be useful to include NFS4ERR_BAD_COOKIE status code into the list of LISTXATTRS statuses, 8.4.5. Valid Errors.

NFS for Linux included this status code.
see https://bugzilla.redhat.com/show_bug.cgi?id=2101371

Errata ID: 5195
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mantas Mikulenas
Date Reported: 2017-12-05

Section 3 says:

   Baloo, the file indexing and search framework for Key Distribution
   Exchange (KDE), has moved to storing metadata such as tags, ratings,
   and comments in file system xattrs instead of a custom database for
   simplicity.  Starting with KDE Plasma 5.1, NFS is no longer supported
   due to its lack of xattr support [KDE].

It should say:

   Baloo, the file indexing and search framework for K Desktop
   Environment (KDE), has moved to storing metadata such as tags,
   ratings, and comments in file system xattrs instead of a custom
   database for simplicity.  Starting with KDE Plasma 5.1, NFS is no
   longer supported due to its lack of xattr support [KDE].

Errata ID: 7004
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yuri Radchenko
Date Reported: 2022-06-23

Section 8.4.5 says:

   | LISTXATTRS  | NFS4ERR_ACCESS, NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
   |             | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MOVED,           |
   |             | NFS4ERR_NAMETOOLONG, NFS4ERR_NOFILEHANDLE,          |
   |             | NFS4ERR_NOTSUPP, NFS4ERR_NOXATTR,                   |
   |             | NFS4ERR_OP_NOT_IN_SESSION, NFS4ERR_PERM,            |
   |             | NFS4ERR_REP_TOO_BIG, NFS4ERR_REP_TOO_BIG_TO_CACHE,  |
   |             | NFS4ERR_REQ_TOO_BIG, NFS4ERR_RETRY_UNCACHED_REP,    |
   |             | NFS4ERR_SERVERFAULT, NFS4ERR_STALE,  

It should say:

   | LISTXATTRS  | NFS4ERR_ACCESS, NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
   |             | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MOVED,           |
   |             | NFS4ERR_NAMETOOLONG, NFS4ERR_NOFILEHANDLE,          |
   |             | NFS4ERR_NOTSUPP, NFS4ERR_NOXATTR,                   |
   |             | NFS4ERR_OP_NOT_IN_SESSION, NFS4ERR_PERM,            |
   |             | NFS4ERR_REP_TOO_BIG, NFS4ERR_REP_TOO_BIG_TO_CACHE,  |
   |             | NFS4ERR_REQ_TOO_BIG, NFS4ERR_RETRY_UNCACHED_REP,    |
   |             | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, NFS4ERR_TOOSMALL

Notes:

Section 8.4.3.3. DESCRIPTION says about NFS4ERR_TOOSMALL status code:

"If the server is unable
to return a single xattr name within the maxcount limit, the error
NFS4ERR_TOOSMALL will be returned to the client."

But this status code not specified in section 8.4.5. Valid Errors for LISTXATTRS operation.

RFC 8288, "Web Linking", October 2017

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: art

Errata ID: 5168
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sawood Alam
Date Reported: 2017-10-25

Section B.3 says:

input is modified to remove the parsed parameters.

It should say:

Input is modified to remove the parsed parameters.

Notes:

The first letter of the sentence is not capitalized.

Errata ID: 5169
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sawood Alam
Date Reported: 2017-10-25

Section B.4 says:

input is modified to remove the parsed string.

It should say:

Input is modified to remove the parsed string.

Notes:

The first letter of the sentence is not capitalized.

RFC 8291, "Message Encryption for Web Push", November 2017

Source of RFC: webpush (art)

Errata ID: 5230
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Martin Thomson
Date Reported: 2018-01-07

Section 5 says:

   Content-Length: 145

It should say:

   Content-Length: 144

Notes:

Reported here: https://github.com/webpush-wg/webpush-encryption/pull/22

RFC 8295, "EST (Enrollment over Secure Transport) Extensions", January 2018

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 7626
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Piotr Popis
Date Reported: 2023-09-04

Section 2.1.1. says:

0007 Start DS certificate enrollment: Indicates that the client needs
        to begin enrolling its DS certificate.  The PAL entry points to
        a /simpleenroll URI, which is defined in [RFC7030].

It should say:

0007 Start DS certificate enrollment: Indicates that the client needs
        to begin enrolling its DS certificate.  The PAL entry points to
        a /simpleenroll or a /fullcmc URI, both of which are defined in     [RFC7030].

Notes:

Without this change and taking the 0006 definition into consideration, one might assume that a Simple PKI Request doesn't require the /csrattrs URI to be done beforehand, but the enrollment with a Full PKI Request must be preceded by the /csrattrs URI, which is not required - see the rest of the document, especially Section 9 and [RFC7030].

RFC 8314, "Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access", January 2018

Note: This RFC has been updated by RFC 8997

Source of RFC: uta (sec)

Errata ID: 5326
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Chris Newman
Date Reported: 2018-04-13

Section 7.3 says:

   Historically, port 465 was briefly registered as the "smtps" port.
   This registration made no sense, as the SMTP transport MX
   infrastructure has no way to specify a port, so port 25 is always
   used.  As a result, the registration was revoked and was subsequently
   reassigned to a different service.  In hindsight, the "smtps"
   registration should have been renamed or reserved rather than
   revoked.  Unfortunately, some widely deployed mail software
   interpreted "smtps" as "submissions" [RFC6409] and used that port for
   email submission by default when an end user requested security
   during account setup.  If a new port is assigned for the submissions

It should say:

   Historically, port 465 was briefly registered as the "smtps" port.
   This registration was misleading because the "SMTP relay" service
   registered as "smtp" on port 25 can not use a different port because
   the SMTP transport MX infrastructure has no way to specify a port.
   As a result, the registration was revoked and was subsequently
   reassigned to a different service. In hindsight, the "smtps"
   registration should have been reserved or renamed to "submissions"
   (to parallel the "submission" SMTP service on port 587 [RFC6409])
   rather than revoked. Some widely deployed mail user agent software
   used the "smtps" port for the "submissions" service when an end user
   requested security during account setup.

Notes:

The "made no sense" statement is technically and factually incorrect. Not only is implicit TLS SMTP submission service on port 465 deployed and used, but the rest of the document recommends using it (thus contradicting the "made no sense" statement). When two ports provide the same service in both cleartext and implicit TLS, the naming convention is to use an "s" suffix for the implicit TLS port. So the problem with the "smtps" was it violated that naming convention.

The proposed errata corrects the technical/factual error and clarifies the distinction between the two different services (SMTP submission & SMTP relay) that both use SMTP.

RFC 8342, "Network Management Datastore Architecture (NMDA)", March 2018

Source of RFC: netmod (ops)

Errata ID: 5514
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Rohit R Ranade
Date Reported: 2018-10-05

Section C.1 says:

   <system
       xmlns="urn:example:system"
       xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">

     <hostname or:origin="or:learned">bar.example.com</hostname>

     <interface or:origin="or:intended">
       <name>eth0</name>
       <auto-negotiation>
         <enabled or:origin="or:default">true</enabled>
         <speed>1000</speed>
       </auto-negotiation>
       <speed>100</speed>
       <address>
         <ip>2001:db8::10</ip>
         <prefix-length>64</prefix-length>
       </address>
       <address or:origin="or:learned">
         <ip>2001:db8::1:100</ip>
         <prefix-length>64</prefix-length>
       </address>
     </interface>

     <interface or:origin="or:system">
       <name>lo0</name>
       <address>
         <ip>::1</ip>
         <prefix-length>128</prefix-length>
       </address>
     </interface>

   </system>

It should say:

   <system
       xmlns="urn:example:system"
       xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
       or:origin="or:intended">

     <hostname or:origin="or:learned">bar.example.com</hostname>

     <interface or:origin="or:intended">
       <name>eth0</name>
       <auto-negotiation>
         <enabled or:origin="or:default">true</enabled>
         <speed>1000</speed>
       </auto-negotiation>
       <speed>100</speed>
       <address>
         <ip>2001:db8::10</ip>
         <prefix-length>64</prefix-length>
       </address>
       <address or:origin="or:learned">
         <ip>2001:db8::1:100</ip>
         <prefix-length>64</prefix-length>
       </address>
     </interface>

     <interface or:origin="or:system">
       <name>lo0</name>
       <address>
         <ip>::1</ip>
         <prefix-length>128</prefix-length>
       </address>
     </interface>

   </system>

Notes:

There was no "origin" attribute to the "system" top-level container, though it is a configuration node.
As per the extension definition "The origin for any top-level configuration data nodes must be specified."

To choose an extension for top-level container in such cases, I would prefer one of the origin of its children and used "intended". , instead of "unknown".

This has already been discussed in the mail chain, but also mentioned here to help readers in future.

RFC 8391, "XMSS: eXtended Merkle Signature Scheme", May 2018

Source of RFC: IRTF

Errata ID: 6352
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Andreas Kretschmer
Date Reported: 2020-12-09

Section Appendix A says:

The WOTS+ signature and public key formats are formally defined using
XDR [RFC4506] in order to provide an unambiguous, machine readable
definition. 

It should say:

The WOTS+ signature and public key formats are defined in a syntax similar to XDR [RFC4506].

Notes:

The definition is not machine readable, e.g. github.com/stellar/xdrgen fails.
Reason:
- some Identifiers contain "/" and "-", RFC4506 allows only letter, digits and underbars
- some enum bodies end with ",}", RFC4506 requests "}" here
- some discriminated union definitions have incomplete declarations in the case-spec, e.g. the union xmss_ots_signature refers to the wotsp-sha2_256 without giving a type.
- The encoding of some unions in the reference implementation is different to the encoding specified in RFC4506. The 4-byte discriminant is missing.

Errata ID: 6821
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Gordon
Date Reported: 2022-01-24

Section 3.1.5 says:

"Note that the checksum may reach a maximum integer value of len_1 * (w - 1) * 2^8"

It should say:

"Note that the checksum may reach a maximum integer value of len_1 * (w - 1)"

Notes:

The "* 2^8" appears to be a mistake. If the checksum integers could reach those values, the checksum field would overflow, which would potentially allow an attacker to forge a message.

In reality, the correct maximum is just "len_1 * (w - 1)"

Errata ID: 7420
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Rafael Misoczki
Date Reported: 2023-04-11

Section 4.2.2 says:

// Generate reduced XMSS private keys
     ADRS = toByte(0, 32);
     for ( layer = 0; layer < d; layer++ ) {
        ADRS.setLayerAddress(layer);
        for ( tree = 0; tree <
              (1 << ((d - 1 - layer) * (h / d)));
              tree++ ) {
           ADRS.setTreeAddress(tree);
           for ( i = 0; i < 2^(h / d); i++ ) {
             wots_sk[i] = WOTS_genSK();
           }
           setXMSS_SK(SK_MT, wots_sk, tree, layer);
        }
     }

It should say:

// Generate reduced XMSS private keys
     ADRS = toByte(0, 32);
     for ( layer = 0; layer < d; layer++ ) {
        ADRS.setLayerAddress(layer);
        for ( tree = 0; tree <
              (1 << ((d - 1 - layer) * (h / d)));
              tree++ ) {
           ADRS.setTreeAddress(tree);
           for ( i = 0; i < 2^(h / d); i++ ) {
             wots_sk[i] = WOTS_genSK();
           }
           setXMSS_SK(SK_MT, wots_sk, tree, layer, ADRS);
        }
     }

Notes:

The ADRS variable is created and configured (layer address and tree address fields set) but it is not used anywhere in the for-loop.

It would be more precise if the setXMSS_SK function receives the ADRS variable so that implementers understand that both layer address and tree address fields must be set as defined in this for-loop in order to generate the correct XMSS private key in each iteration of this loop.

RFC 8407, "Guidelines for Authors and Reviewers of Documents Containing YANG Data Models", October 2018

Note: This RFC has been updated by RFC 8819

Source of RFC: netmod (ops)

Errata ID: 7416
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Mohamed Boucadair
Date Reported: 2023-04-07

Section 4.8 says:

      revision "2017-12-11" {
        description
          "Added support for YANG 1.1 actions and notifications tied to
           data nodes.  Clarify how NACM extensions can be used by other
           data models.";
        reference
          "RFC 8407: Network Configuration Protocol (NETCONF)
                     Access Control Model";
      }

It should say:

      revision "2017-12-11" {
        description
          "Added support for YANG 1.1 actions and notifications tied to
           data nodes.  Clarify how NACM extensions can be used by other
           data models.";
        reference
          "RFC UUUU: Network Configuration Access Control Model";
      }

Notes:

This example is supposed to illustrate the use of revisions in unpublished updates. Having an RFC under the reference clause is inconsistent:

o published: A stable release of a module or submodule. For
example, the "Request for Comments" described in Section 2.1 of
[RFC2026] is considered a stable publication.

o unpublished: An unstable release of a module or submodule. For
example the "Internet-Draft" described in Section 2.2 of [RFC2026]
is considered an unstable publication that is a work in progress,
subject to change at any time.

I suspect that RFC XXXX in draft-ietf-netmod-rfc6087bis was erroneously replaced by RFC 8407:

revision "2017-12-11" {
description
"Added support for YANG 1.1 actions and notifications tied to
data nodes. Clarify how NACM extensions can be used by other
data models.";
reference
"RFC XXXX: Network Configuration Protocol (NETCONF)
Access Control Model";
}

RFC 8410, "Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure", August 2018

Note: This RFC has been updated by RFC 9295

Source of RFC: curdle (sec)

Errata ID: 6229
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: David von Oheimb
Date Reported: 2020-07-12

Section 10.2 says:

An example of a self-issued PKIX certificate using Ed25519 to sign an
X25519 public key would be

Notes:

The given example certificate is self-issued but not self-signed (which is fine because its public key cannot be used for signing).
It includes a subjectKeyIdentifier but not an authorityKeyIdentifier.

For not self-signed certificates RFC 5280 requires in section 4.2.1.1 (https://tools.ietf.org/html/rfc5280#section-4.2.1.1) that the authorityKeyIdentifier is present.

Thus for such an example certificate the authorityKeyIdentifier MUST be added in order to be a conforming certificate.
Otherwise, cert chain validation will be mislead to assume that the certificate is self-signed (while usually not actually verifying this supposition).

Errata ID: 6263
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: David Ireland
Date Reported: 2020-08-24

Section 7 says:

NOTE: There exist some private key import functions that have not picked up the new ASN.1 structure OneAsymmetricKey that is defined in [RFC7748].

It should say:

NOTE: There exist some private key import functions that have not picked up the new ASN.1 structure OneAsymmetricKey that is defined in [RFC5958].

Notes:

RFC7748 does not define or even mention OneAsymmetricKey. The correct reference should be RFC5958 "Asymmetric Key Packages"

Errata ID: 6936
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ryan Culpepper
Date Reported: 2022-04-16

Section 10.2 says:

   -----BEGIN CERTIFICATE-----
   MIIBLDCB36ADAgECAghWAUdKKo3DMDAFBgMrZXAwGTEXMBUGA1UEAwwOSUVURiBUZX
   N0IERlbW8wHhcNMTYwODAxMTIxOTI0WhcNNDAxMjMxMjM1OTU5WjAZMRcwFQYDVQQD
   DA5JRVRGIFRlc3QgRGVtbzAqMAUGAytlbgMhAIUg8AmJMKdUdIt93LQ+91oNvzoNJj
   ga9OukqY6qm05qo0UwQzAPBgNVHRMBAf8EBTADAQEAMA4GA1UdDwEBAAQEAwIDCDAg
   BgNVHQ4BAQAEFgQUmx9e7e0EM4Xk97xiPFl1uQvIuzswBQYDK2VwA0EAryMB/t3J5v
   /BzKc9dNZIpDmAgs3babFOTQbs+BolzlDUwsPrdGxO3YNGhW7Ibz3OGhhlxXrCe1Cg
   w1AH9efZBw==
   -----END CERTIFICATE-----

It should say:

(re-encode certificate)

Notes:

The example certificate violates RFC 5280. Specifically, the
certificate contains a BasicConstraints extension that explicitly
encodes the cA field with a value of FALSE, but that is the default
value of the cA field, and the Extension extnValue is required to be
encoded using DER, which forbids including a field set to its default
value.

In addition, the PEM-encoded certificate violates RFC 7468, which
requires lines to be wrapped to 64 characters, but the example is
wrapped to 66-character lines.

Errata ID: 7070
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Alex Gaynor
Date Reported: 2022-08-02

Section 10.2 says:

   -----BEGIN CERTIFICATE-----
   MIIBLDCB36ADAgECAghWAUdKKo3DMDAFBgMrZXAwGTEXMBUGA1UEAwwOSUVURiBUZX
   N0IERlbW8wHhcNMTYwODAxMTIxOTI0WhcNNDAxMjMxMjM1OTU5WjAZMRcwFQYDVQQD
   DA5JRVRGIFRlc3QgRGVtbzAqMAUGAytlbgMhAIUg8AmJMKdUdIt93LQ+91oNvzoNJj
   ga9OukqY6qm05qo0UwQzAPBgNVHRMBAf8EBTADAQEAMA4GA1UdDwEBAAQEAwIDCDAg
   BgNVHQ4BAQAEFgQUmx9e7e0EM4Xk97xiPFl1uQvIuzswBQYDK2VwA0EAryMB/t3J5v
   /BzKc9dNZIpDmAgs3babFOTQbs+BolzlDUwsPrdGxO3YNGhW7Ibz3OGhhlxXrCe1Cg
   w1AH9efZBw==
   -----END CERTIFICATE-----

It should say:

A corrected encoding of the certificate.

Notes:

In addition to the mis-encoding described in 6936, there are additional misencodings. The critical field of X.509 extensions have `DEFAULT FALSE` (per RFC 5280). Default field values shall not be encoded in a DER sequence, but in the certificate encoding presented there these critical fields are encoded.

RFC 8414, "OAuth 2.0 Authorization Server Metadata", June 2018

Source of RFC: oauth (sec)

Errata ID: 7793
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Kristina Yasuda
Date Reported: 2024-01-31

Section 2 says:

response_types_supported
      REQUIRED.  JSON array containing a list of the OAuth 2.0
      "response_type" values that this authorization server supports.
      The array values used are the same as those used with the
      "response_types" parameter defined by "OAuth 2.0 Dynamic Client
      Registration Protocol" [RFC7591].

It should say:

response_types_supported
      JSON array containing a list of the OAuth 2.0
      "response_type" values that this authorization server supports.
      This is REQUIRED unless no grant types are supported
      that use the authorization endpoint. The array values used are
      the same as those used with the "response_types" parameter defined by
      "OAuth 2.0 Dynamic Client Registration Protocol" [RFC7591].

Notes:

For the authorization servers that only support grant types that do not use authorization endpoint (like client credentials grant), there is no value to put in the required `response_types_supported` parameter. At the same time, section 3.2 says that "Claims with zero elements MUST be omitted from the response." `authorization_endpoint`parameter is already required for the ASs that support grant types that use the authorization endpoint, so it should be the same for the `response_types_supported` parameter.

RFC 8417, "Security Event Token (SET)", July 2018

Source of RFC: secevent (sec)

Errata ID: 7175
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Nigel Somerfield
Date Reported: 2022-10-21

Section 2.1.4 says:

{
    "iss": "https://idp.example.com/",
    "jti": "756E69717565206964656E746966696572",
    "iat": 1508184845,
    "aud": "636C69656E745F6964",
    "events": {
  "https://schemas.openid.net/secevent/risc/event-type/account-disabled"
          : {
        "subject": {
          "subject_type": "iss-sub",
          "iss": "https://idp.example.com/",
          "sub": "7375626A656374"
        },
        "reason": "hijacking"
      }
    }
  }

                       Figure 4: Example RISC Event

   Notice that parameters to the event are included in the event
   payload, in this case, the "reason" and "cause-time" values.  The
   subject of the event is identified using the "subject" payload value,
   which itself is a JSON object.

It should say:

{
    "iss": "https://idp.example.com/",
    "jti": "756E69717565206964656E746966696572",
    "iat": 1508184845,
    "aud": "636C69656E745F6964",
    "events": {
  "https://schemas.openid.net/secevent/risc/event-type/account-disabled"
          : {
        "subject": {
          "subject_type": "iss-sub",
          "iss": "https://idp.example.com/",
          "sub": "7375626A656374"
        },
        "reason": "hijacking"
      }
    }
  }

                       Figure 4: Example RISC Event

   Notice that parameters to the event are included in the event
   payload, in this case, the "reason" value.  The
   subject of the event is identified using the "subject" payload value,
   which itself is a JSON object.

Notes:

The included RISC event example JSON object does not contain a "cause-time" member, however this is referred to in the explanation following the example. It would be valuable to either include the "cause-time" member, or to remove it from the explanation as per the above.

RFC 8439, "ChaCha20 and Poly1305 for IETF Protocols", June 2018

Source of RFC: IRTF

Errata ID: 6569
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: David Reed
Date Reported: 2021-05-03

Section 2.3 says:

o  A 32-bit block count parameter, treated as a 32-bit little-endian integer.

It should say:

o  A 32-bit block count parameter, treated as a 32-bit integer.

Notes:

The block count is not used as a little-endian integer. An example of this can be seen in the example test vector in section 2.3.2, where Block Count = 1, but the block count word of the initial state is 00000001.

Errata ID: 6989
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Mike Markowitz
Date Reported: 2022-06-10

Section 2.8.2 says:

Poly1305 r =  455e9a4057ab6080f47b42c052bac7b

It should say:

Poly1305 r = 8455e9a4057ab6080f47b42c052bac7b

Notes:

fist nibble of r appears to be missing

Errata ID: 7880
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Volker Diels-Grabsch
Date Reported: 2024-04-03

Section 2.4.1 says:

encrypted_message |= (block^key_stream)[0..len(plaintext)%64]

It should say:

encrypted_message |= (block^key_stream)[0..(len(plaintext)%64)-1]

Notes:

If the plaintext size is not a multiple of 64 bytes, there is an off-by-one error in appending the final block of the encrypted message. In the original version, the encrypted message would always be one byte larger than the plaintext.

The corrected version ensures that the encrypted message size is always equal to the plaintext size.

For completeness: If the plaintext size is a multiple of 64 bytes, the second part of the code is skipped. Hence, this off-by-one error is not triggered in that specific case.

(Non-)relation to correction 5989: The "original text", as quoted here, assumes that correction 5989 has already been applied. Correction 5989 deals with a different issue of this line of code, namely, the replacement of "+=" by "|=". This is completely orthogonal to the off-by-one error described here.

RFC 8445, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", July 2018

Note: This RFC has been updated by RFC 8863

Source of RFC: ice (art)

Errata ID: 7526
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eric Rescorla
Date Reported: 2023-05-28

Section 22.2 says:

.

It should say:

.

Notes:

The link to ICE-SIP-SDP is broken. It is a relative link:

[<a id="ref-ICE-SIP-SDP">ICE-SIP-SDP</a>]
Petit-Huguenin, M., Nandakumar, S., and A. Keranen,
"Session Description Protocol (SDP) Offer/Answer
procedures for Interactive Connectivity Establishment
(ICE)", Work in Progress,
<a href="./draft-ietf-mmusic-ice-sip-sdp-21">draft-ietf-mmusic-ice-sip-sdp-21</a>, June 2018.

But there is nothing at https://www.rfc-editor.org/rfc/draft-ietf-mmusic-ice-sip-sdp-21

RFC 8446, "The Transport Layer Security (TLS) Protocol Version 1.3", August 2018

Source of RFC: tls (sec)

Errata ID: 6136
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-28

Section 4.1.4 says:

   Upon receipt of a HelloRetryRequest, the client MUST check the
   legacy_version, legacy_session_id_echo, cipher_suite, and     
   legacy_compression_method as specified in Section 4.1.3 

Notes:

Section 4.1.3 defines no checks for legacy_version nor legacy_compression_method

Errata ID: 6143
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-29

Section 4.2.7 says:

As of TLS 1.3, servers are permitted to send the "supported_groups"
extension to the client.

Notes:

It is unclear whether servers are permitted to send the "supported_groups" extension to
the client without solicitation, i.e., when the client does not first send the extension to the
server. Clarification would be useful.

Errata ID: 6145
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-29

Section 4.2.10. says:

When a PSK is used and early data is allowed for that PSK

Notes:

I couldn't find restrictions that forbid early data for a PSK. Explaining where such restrictions
could exist would be useful. E.g., PSKs might be associated with data that forbids early data.

Errata ID: 6151
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-30

Section 4.4 says:

   | Post-     | ClientHello ... client  | client_application_traffic_ |
   | Handshake | Finished +              | secret_N                    |
   |           | CertificateRequest      |                             |

It should say:

   | Post-     | ClientHello ... client  | [sender]_application_traffic|
   | Handshake | Finished +              | _secret_N                   |
   |           | CertificateRequest      |                             |

Errata ID: 6152
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-05-01

Section 4 says:

Clients MUST check for ["supported_versions"] prior to
processing the rest of the ServerHello (although they will have to 
parse the ServerHello in order to read the extension). -- Section 4.2.1.

Upon receipt of a HelloRetryRequest, the client MUST check the
legacy_version, legacy_session_id_echo, cipher_suite, and
legacy_compression_method as specified in Section 4.1.3 and then
process the extensions, starting with determining the version using
"supported_versions". -- Section 4.1.4

Upon receiving a message with type server_hello, implementations MUST
first examine the Random value... -- Section 4.1.3.

Notes:

These requirements are seemingly conflicting. I suspect checking for "supported_versions" must
come first, since that may influence subsequent steps, e.g., checking legacy_compression_method
and the Random value. It doesn't seem to matter whether legacy_version, legacy_session_id_echo,
cipher_suite, and legacy_compression_method are checked before the Random value, so it doesn't
seem to matter which check is second and which is third. (Noting, as per one of my earlier reports,
dated 28 Apr, Section 4.1.3 defines no checks for legacy_version nor legacy_compression_method.
Perhaps the latter should be checked to be zero, aborting with alert illegal_parameter if it isn't, as per
Section 4.1.2.)

Errata ID: 7003
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2022-06-22

Section 4.6.1. says:

At any time after the server has received the client Finished message, it MAY send a NewSessionTicket message.

It should say:

At any time after the server has received both a "psk_key_exchange_modes" extension and a Finished message, it MAY send a NewSessionTicket message.

Notes:

Section 4.2.9. demands

In order to use PSKs, clients MUST also send a "psk_key_exchange_modes" extension.

Hence, an additional restriction is needed in Section 4.6.1.

Errata ID: 7073
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2022-08-06

Section 4.4 says:

These messages are encrypted under keys derived from the [sender]_handshake_traffic_secret.

It should say:

These messages are encrypted under keys derived from the [sender]_handshake_traffic_secret, except for post-handshake authentication

Notes:

There's an exception

Errata ID: 7620
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2023-08-28

Section 6.1 says:

Each party MUST send a "close_notify" alert before closing its write
side of the connection, unless it has already sent some error alert.
This does not have any effect on its read side of the connection.
Note that this is a change from versions of TLS prior to TLS 1.3 in
which implementations were required to react to a "close_notify" by
discarding pending writes and sending an immediate "close_notify"
alert of their own.  That previous requirement could cause truncation
in the read side.  Both parties need not wait to receive a
"close_notify" alert before closing their read side of the
connection, though doing so would introduce the possibility of
truncation.

It should say:

Each party MUST send a "close_notify" alert before closing its write
side of the connection, unless it has already sent some error alert.
This SHOULD NOT have any effect on the read side of the sender's connection;
parties SHOULD receive a "close_notify" alert before closing the read side of their connection.
Note that this is a change from versions of TLS prior to TLS 1.3 in
which receivers were required to react to a "close_notify" by
discarding pending writes and sending an immediate "close_notify"
alert of their own.  That previous requirement could cause truncation
in the read side.  Both parties need not wait to receive a
"close_notify" alert before closing their read side of the
connection, though doing so would introduce the possibility of
truncation.

Notes:

As-is there's a specification-level vulnerability: Specification-compliant implementations may be vulnerable to truncation attacks.

I suggest using SHOULD NOT & SHOULD for better signposting and to avoid specification-level vulnerability.

I also suggest minor tweaks for readability.

Errata ID: 6120
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-24

Section 1 says:

the underlying transport is a reliable, in-order data stream

It should say:

the underlying transport layer is a reliable, in-order stream delivery service

or

the underlying transport protocol is a reliable, in-order stream delivery service

or similar

Notes:

Similar elsewhere

Errata ID: 6121
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-24

Section 1 says:

cryptographic modes

It should say:

cryptographic algorithms

Errata ID: 6124
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-24

Section 2 says:

   In the Key Exchange phase, the client sends the ClientHello                  
   (Section 4.1.2) message, which contains a random nonce                       
   (ClientHello.random); its offered protocol versions; a list of               
   symmetric cipher/HKDF hash pairs; either a set of Diffie-Hellman key         
   shares (in the "key_share" (Section 4.2.8) extension), a set of              
   pre-shared key labels (in the "pre_shared_key" (Section 4.2.11)              
   extension), or both; and potentially additional extensions.   

It should say:

   In the Key Exchange phase, the client sends the ClientHello                  
   (Section 4.1.2) message, which contains a random nonce                       
   (ClientHello.random); its offered protocol versions; a list of               
   symmetric cipher/Hash algorithm pairs; either a set of Diffie-Hellman key         
   shares (in the "key_share" (Section 4.2.8) extension), a set of              
   pre-shared key labels (in the "pre_shared_key" (Section 4.2.11)              
   extension), or both; and potentially additional extensions.   

or

   In the Key Exchange phase, the client sends the ClientHello                  
   (Section 4.1.2) message, which contains a random nonce                       
   (ClientHello.random); its offered protocol versions; a list of               
   symmetric cipher/Hash algorithm (to be used with HKDF) pairs; either a set of Diffie-Hellman key         
   shares (in the "key_share" (Section 4.2.8) extension), a set of              
   pre-shared key labels (in the "pre_shared_key" (Section 4.2.11)              
   extension), or both; and potentially additional extensions.   

Errata ID: 6126
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-24

Section 4.1.1 says:

Note that if the PSK can be used without (EC)DHE, then
non-overlap in the "supported_groups" parameters need not be fatal, 
as it is in the non-PSK case discussed in the previous paragraph.

It should say:

Note that if the PSK can be used without (EC)DHE, then
non-overlap in the "supported_groups" parameters need not be fatal, 
as it is in the non-PSK case discussed in the previous paragraph, 
because PSK-only key exchange mode does not need supported_groups.

Notes:

If "the PSK can be used without (EC)DHE", then PSK-only key exchange mode can be used, which doesn't require supported_groups. This is perhaps worthy of explanation.

Errata ID: 6127
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-24

Section 4.1.2. says:

If a "key_share" extension was supplied in the HelloRetryRequest,
replacing the list of shares with a list containing a single
KeyShareEntry from the indicated group.

It should say:

If a "key_share" extension was supplied in the HelloRetryRequest,
replacing the list of shares with a list containing a single
KeyShareEntry from the indicated group. Note: A "key_share" 
extension may not be supplied in a HelloRetryRequest message 
when a server receives  an "early_data" (Section 4.2.10).

Errata ID: 6137
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-28

Section 4.2.10 says:

symmetric cipher suite

It should say:

cipher suite

Errata ID: 6140
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-29

Section 4.4.2.2. says:

This fallback chain SHOULD NOT use the deprecated SHA-1 hash
algorithm in general, but MAY do so if the client's advertisement
permits it, and MUST NOT do so otherwise.

It should say:

This fullback chain MUST NOT use the deprecated SHA-1 hash,
except if advertised by the client, in which case it MAY.

Notes:

The original text is difficult to read, eliminating the unnecessary "SHOULD NOT" seems to make it
easier.

Errata ID: 6144
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-29

Section 4.2.8. says:

Upon receipt of this extension in a HelloRetryRequest, the client
MUST verify that...the selected_group field does not
correspond to a group which was provided in the "key_share" extension
in the original ClientHello.

It should say:

Upon receipt of this extension in a HelloRetryRequest, the client
MUST verify that...a key share was not offered (in the "key_share" 
extension in the original ClientHello) for the group in the 
selected_group field.

Notes:

The original text requires knowledge of the "key_share" extension and is rather hard to read,
the proposed text should be easier to understand.

Errata ID: 6147
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-29

Section 4.2.10. says:

In order to accept early data, the server MUST have accepted a PSK
cipher suite....In addition, it MUST verify that the
following values are the same as those associated with the
selected PSK:

...

-  The selected cipher suite

Notes:

Accepting the "PSK cipher suite" surely implies the PSK is associated with the cipher suite, hence,
"The selected cipher suite" can be dropped.

Errata ID: 6148
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-29

Section 4.2.10 says:

The selected ALPN [RFC7301] protocol, if any

It should say:

The selected ALPN [RFC7301] protocol, if extension application_layer_protocol_negotiation is present

Errata ID: 6150
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-29

Throughout the document, when it says:

Note that certificate-based client authentication is not available 
in PSK handshake flows (including 0-RTT). 

It should say:

Note that certificate-based client authentication is not available 
in PSK handshake flows (including 0-RTT), post-handshake 
certificate-based client authentication is possible.

RFC 8447, "IANA Registry Updates for TLS and DTLS", August 2018

Source of RFC: tls (sec)

Errata ID: 6009
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Benjamin Kaduk
Date Reported: 2020-03-07

Section 14 says:

   o  Added a "Recommended" column to the registry.  X.509 and Raw

It should say:

   o  Added a "Recommended" column to the registry.  X509 and Raw

Notes:

Update to match https://www.rfc-editor.org/errata/eid5976

RFC 8448, "Example Handshake Traces for TLS 1.3", January 2019

Source of RFC: tls (sec)

Errata ID: 5645
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Anthony Mai
Date Reported: 2019-02-28

Section 2 says:

   Ephemeral private keys are shown as they are generated in the traces.

It should say:

   Ephemeral private keys are shown as they are generated in the traces.
Note that X25519 private keys are trimmed in accordance to [RFC 7748]
Section 5, before use. This is done by clearing bit 0 to 2 of the first
byte and bit 7 of the last byte. And then set bit 6 of the last byte.

Notes:

On page 3,5,16,20,29,43,44,55,57, there are ten X25519 ephemeral private
keys listed. None of these private key value, when used directly in X25519
calculation, will yield the associated public key listed. These private key
values are not the actual values used. Instead up to 5 bits are modified as
recommended by RFC 7748 section 5. Some implementations may choose NOT to
do such trimming, and it does not affect the connectivity, as the private
keys are never sent over the wire and does not affect network behavior.

Not clarifying how the X25519 private keys were modified before using could
cause serious confusion. I personally struggled for a day before figuring
out this little obscure detail.

RFC 8461, "SMTP MTA Strict Transport Security (MTA-STS)", September 2018

Source of RFC: uta (sec)

Errata ID: 6253
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Daniel Shahaf
Date Reported: 2020-08-08

Section 3.2 says:

CRLF-separated key/value pairs

It should say:

LF- or CRLF-separated key/value pairs

Notes:

Rationale:

1. The definition of 'sts-policy-term' in the grammar explicitly allows use of either CRLF or bare LF.

2. On page 8, one of the example says "<CRLF>" explicitly at the end of the first line, while the second line of that example and all lines of the other example have neither "<CRLF>" nor "<LF>" appended to them. That makes it ambiguous whether those lines are terminated by LF or by CRLF.

Errata ID: 6285
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Paul Buonopane
Date Reported: 2020-09-10

Section 3.1 says:

sts-field-delim = *WSP ";" *WSP

It should say:

sts-field-delim = ";" *WSP

Notes:

The following text appears within the same section:

> If multiple TXT records for "_mta-sts" are returned by the resolver, records that do not begin with "v=STSv1;" are discarded.

The current definition of sts-field-delim is incompatible with that instruction. Either the instruction needs to be changed, a new delimiter needs to be defined that doesn't permit whitespace before the semicolon, or sts-field-delim needs to be modified.

Errata ID: 7282
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Benjamin Schwarze
Date Reported: 2022-12-21

Section 3.2 says:

sts-policy-max-age-value = 1*10(DIGIT)

It should say:

sts-policy-max-age-value = 1*8(DIGIT)

Notes:

As described under 3.2 at point "max_age", the maximum lifetime of a policy may only be 31557600 seconds. Therefore 8 digits in the ABNF for "sts-policy-max-age-value" would be sufficient.

On the other hand, if values larger than 31557600 seconds are allowed, the text under "max_age" should be adjusted.

Errata ID: 6525
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kaspar Etter
Date Reported: 2021-04-10

Section 4.2 says:

The certificate presented by the receiving MTA MUST not be expired

It should say:

The certificate presented by the receiving MTA MUST NOT be expired

Notes:

NOT should be capitalized.

RFC 8467, "Padding Policies for Extension Mechanisms for DNS (EDNS(0))", October 2018

Source of RFC: dprive (int)

Errata ID: 7874
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: hello world
Date Reported: 2024-03-28

Section 6 says:

Note that even with encryption and padding, it might be trivial to identify that the observed traffic is DNS.

It should say:

Note that even with encryption and padding, it might be easy to identify that the observed traffic is DNS.

Notes:

easy to understand what that means.

RFC 8484, "DNS Queries over HTTPS (DoH)", October 2018

Source of RFC: doh (art)

Errata ID: 5603
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Carsten Bormann
Date Reported: 2019-01-15

Section 4.1 says:

   The URI Template defined in this document is processed without any
   variables when the HTTP method is POST.  When the HTTP method is GET,
   the single variable "dns" is defined as the content of the DNS
   request (as described in Section 6), encoded with base64url
   [RFC4648].

It should say:

   The URI Template defined in this document is processed without any
   variables when the HTTP method is POST.  When the HTTP method is GET,
   the single variable "dns" is defined as the content of the DNS
   request (as described in Section 6), encoded with base64url
   [RFC4648]. Padding characters for base64url MUST NOT be included.

Notes:

Note that Section 6 does say the same thing for a different usage of base64url, and note that the examples in 4.1.1 even explicitly state this, but the text that states the usual deviation from the default of RFC 4648 should be in the defining part as well. (This is almost, but not quite, an editorial erratum.)

Errata ID: 6033
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Mohamed Boucadair
Date Reported: 2020-03-30

Section 3 says:

   A DoH client MUST NOT use a different URI simply because it was
   discovered outside of the client's configuration (such as through
   HTTP/2 server push) or because a server offers an unsolicited
   response that appears to be a valid answer to a DNS query. 

It should say:

   A DoH client MUST NOT use a different URI that was discovered outside
   of the client's configuration (except via HTTP redirection discussed
   in Section 6.4 of [RFC7231]).  Also, the DoH client MUST ignore an
   unsolicited response (such as through HTTP/2 server push) that
   appears to be a valid answer to a DNS query unless that response
   comes from a configured URI (as described in Section 5.3).

Notes:

(1) The intent of this text is confusing.

(2) I checked the mailing list and found that the text was updated late in the publication process to address this comment: https://mailarchive.ietf.org/arch/msg/doh/f_V-tBgB-KRsLZhttx9tGt75cps/.

(3) The example provided in the thread (server push) is related to the second part of the OLD text. It is mistakenly attached to the first part.

(4) The push example may be interpreted as if server push is disallowed. This is conflicting with Section 5.3.

Hence, this change:

Also, the DoH client MUST ignore an
unsolicited response (such as through HTTP/2 server push) that
appears to be a valid answer to a DNS query ** unless that response
comes from a configured URI (as described in Section 5.3) **.

(5) An intuitive way to discover the URI outside the configuration is redirection. RFC8484 indicates clearly the following:

The described approach is more than a tunnel over HTTP. It
establishes default media formatting types for requests and responses
but uses normal HTTP content negotiation mechanisms for selecting
alternatives that endpoints may prefer in anticipation of serving new
use cases. In addition to this media type negotiation, it ** aligns
itself with HTTP features ** such as caching, **redirection**, proxying,
authentication, and compression.

Forbidding discovery of URI outside the configuration contradicts the above excerpt. The text is as such incorrect.

(6) Also, I suggest to remove "simply" from the text. Not sure what message is supposed to convey.

Errata ID: 6708
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Martin Thomson
Date Reported: 2021-10-14

Section 10 says:

The use of Online Certificate
   Status Protocol (OCSP) [RFC6960] servers or Authority Information
   Access (AIA) for Certificate Revocation List (CRL) fetching (see
   Section 4.2.2.1 of [RFC5280]) are examples of how this deadlock can
   happen.

It should say:

The use of Online Certificate Status Protocol (OCSP) [RFC6960] servers, Certificate Revocation List (CRL) distribution points (see Section 4.2.1.13 of [RFC5280]), or Authority Information Access (AIA) to retrieve issuer certificates (see Section 4.2.2.1 of [RFC5280]) are examples of how this deadlock can happen.

Notes:

The OCSP part is fine, but the AIA piece is wrong.

For context, there are three different ways (to my knowledge) that a client might make outbound connections in order to validate or build a certification path.

1. CRL - clients fetch CRLs from the designated location. This rarely happens any more as it is grossly inefficient, but it does still happen in some usages.

2. OCSP - clients query OCSP for the status of a certificate.

3. AIA chasing - this is where the TLS handshake doesn't include the full set of certificates required to validate the end-entity certificate, but the certificate includes a URL for that certificate.

AIA itself is a multi-purpose field. It can include multiple elements, one of which is the identity of an OCSP responder (the same one used in (2) above) and the other being the one used in (3). It does not include CRL distribution points, as the text implies.

RFC 8492, "Secure Password Ciphersuites for Transport Layer Security (TLS)", February 2019

Source of RFC: INDEPENDENT

Errata ID: 5727
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexander Freiherr von Buddenbrock
Date Reported: 2019-05-21

Section Appendix A says:

   username: fred
   password: barney

   ---- prior to running TLS-PWD ----

   server generates salt:

   96 3c 77 cd c1 3a 2a 8d 75 cd dd d1 e0 44 99 29
   84 37 11 c2 1d 47 ce 6e 63 83 cd da 37 e4 7d a3

   and a base:

   6e 7c 79 82 1b 9f 8e 80 21 e9 e7 e8 26 e9 ed 28
   c4 a1 8a ef c8 75 0c 72 6f 74 c7 09 61 d7 00 75

   ---- state derived during the TLS-PWD exchange ----

   client and server agree to use brainpoolP256r1

   client and server generate the PE:

   PE.x:
   29 b2 38 55 81 9f 9c 3f c3 71 ba e2 84 f0 93 a3
   a4 fd 34 72 d4 bd 2e 9d f7 15 2d 22 ab 37 aa e6

   server private and mask:

   private:
   21 d9 9d 34 1c 97 97 b3 ae 72 df d2 89 97 1f 1b
   74 ce 9d e6 8a d4 b9 ab f5 48 88 d8 f6 c5 04 3c
   mask:
   0d 96 ab 62 4d 08 2c 71 25 5b e3 64 8d cd 30 3f
   6a b0 ca 61 a9 50 34 a5 53 e3 30 8d 1d 37 44 e5

   client private and mask:

   private:
   17 1d e8 ca a5 35 2d 36 ee 96 a3 99 79 b5 b7 2f
   a1 89 ae 7a 6a 09 c7 7f 7b 43 8a f1 6d f4 a8 8b
   mask:
   4f 74 5b df c2 95 d3 b3 84 29 f7 eb 30 25 a4 88
   83 72 8b 07 d8 86 05 c0 ee 20 23 16 a0 72 d1 bd

   both parties generate premaster secret and master secret

   premaster secret:
   01 f7 a7 bd 37 9d 71 61 79 eb 80 c5 49 83 45 11
   af 58 cb b6 dc 87 e0 18 1c 83 e7 01 e9 26 92 a4
   master secret:
   65 ce 15 50 ee ff 3d aa 2b f4 78 cb 84 29 88 a1
   60 26 a4 be f2 2b 3f ab 23 96 e9 8a 7e 05 a1 0f
   3d 8c ac 51 4d da 42 8d 94 be a9 23 89 18 4c ad

   ---- ssldump output of exchange ----

   New TCP connection #1: Charlene Client <-> Sammy Server
   1 1  0.0018 (0.0018)  C>SV3.3(173)  Handshake
         ClientHello
           Version 3.3
           random[32]=
             52 8f bf 52 17 5d e2 c8 69 84 5f db fa 83 44 f7
             d7 32 71 2e bf a6 79 d8 64 3c d3 1a 88 0e 04 3d
           ciphersuites
           TLS_ECCPWD_WITH_AES_128_GCM_SHA256_PRIV
           TLS_ECCPWD_WITH_AES_256_GCM_SHA384_PRIV
           Unknown value 0xff
           compression methods
                     NULL
           extensions
           TLS-PWD unprotected name[5]=
             04 66 72 65 64
           elliptic curve point format[4]=
             03 00 01 02
           elliptic curve list[58]=
             00 38 00 0e 00 0d 00 1c 00 19 00 0b 00 0c 00 1b
             00 18 00 09 00 0a 00 1a 00 16 00 17 00 08 00 06
             00 07 00 14 00 15 00 04 00 05 00 12 00 13 00 01
             00 02 00 03 00 0f 00 10 00 11
   Packet data[178]=
     16 03 03 00 ad 01 00 00 a9 03 03 52 8f bf 52 17
     5d e2 c8 69 84 5f db fa 83 44 f7 d7 32 71 2e bf
     a6 79 d8 64 3c d3 1a 88 0e 04 3d 00 00 06 ff b3
     ff b4 00 ff 01 00 00 7a b8 aa 00 05 04 66 72 65
     64 00 0b 00 04 03 00 01 02 00 0a 00 3a 00 38 00
     0e 00 0d 00 1c 00 19 00 0b 00 0c 00 1b 00 18 00
     09 00 0a 00 1a 00 16 00 17 00 08 00 06 00 07 00
     14 00 15 00 04 00 05 00 12 00 13 00 01 00 02 00
     03 00 0f 00 10 00 11 00 0d 00 22 00 20 06 01 06
     02 06 03 05 01 05 02 05 03 04 01 04 02 04 03 03
     01 03 02 03 03 02 01 02 02 02 03 01 01 00 0f 00
     01 01

   1 2  0.0043 (0.0024)  S>CV3.3(94)  Handshake
         ServerHello
           Version 3.3
           random[32]=
             52 8f bf 52 43 78 a1 b1 3b 8d 2c bd 24 70 90 72
             13 69 f8 bf a3 ce eb 3c fc d8 5c bf cd d5 8e aa
           session_id[32]=
             ef ee 38 08 22 09 f2 c1 18 38 e2 30 33 61 e3 d6
             e6 00 6d 18 0e 09 f0 73 d5 21 20 cf 9f bf 62 88
           cipherSuite         TLS_ECCPWD_WITH_AES_128_GCM_SHA256_PRIV
           compressionMethod                   NULL
           extensions
           renegotiate[1]=
             00
           elliptic curve point format[4]=
             03 00 01 02
           heartbeat[1]=
             01
   Packet data[99]=
     16 03 03 00 5e 02 00 00 5a 03 03 52 8f bf 52 43
     78 a1 b1 3b 8d 2c bd 24 70 90 72 13 69 f8 bf a3
     ce eb 3c fc d8 5c bf cd d5 8e aa 20 ef ee 38 08
     22 09 f2 c1 18 38 e2 30 33 61 e3 d6 e6 00 6d 18
     0e 09 f0 73 d5 21 20 cf 9f bf 62 88 ff b3 00 00
     12 ff 01 00 01 00 00 0b 00 04 03 00 01 02 00 0f
     00 01 01

   1 3  0.0043 (0.0000)  S>CV3.3(141)  Handshake
         ServerKeyExchange
           params
             salt[32]=
               96 3c 77 cd c1 3a 2a 8d 75 cd dd d1 e0 44 99 29
               84 37 11 c2 1d 47 ce 6e 63 83 cd da 37 e4 7d a3
             EC parameters = 3
             curve id = 26
             element[65]=
               04 22 bb d5 6b 48 1d 7f a9 0c 35 e8 d4 2f cd 06
               61 8a 07 78 de 50 6b 1b c3 88 82 ab c7 31 32 ee
               f3 7f 02 e1 3b d5 44 ac c1 45 bd d8 06 45 0d 43
               be 34 b9 28 83 48 d0 3d 6c d9 83 24 87 b1 29 db
               e1
             scalar[32]=
               2f 70 48 96 69 9f c4 24 d3 ce c3 37 17 64 4f 5a
               df 7f 68 48 34 24 ee 51 49 2b b9 66 13 fc 49 21
   Packet data[146]=
     16 03 03 00 8d 0c 00 00 89 00 20 96 3c 77 cd c1
     3a 2a 8d 75 cd dd d1 e0 44 99 29 84 37 11 c2 1d
     47 ce 6e 63 83 cd da 37 e4 7d a3 03 00 1a 41 04
     22 bb d5 6b 48 1d 7f a9 0c 35 e8 d4 2f cd 06 61
     8a 07 78 de 50 6b 1b c3 88 82 ab c7 31 32 ee f3
     7f 02 e1 3b d5 44 ac c1 45 bd d8 06 45 0d 43 be
     34 b9 28 83 48 d0 3d 6c d9 83 24 87 b1 29 db e1
     00 20 2f 70 48 96 69 9f c4 24 d3 ce c3 37 17 64
     4f 5a df 7f 68 48 34 24 ee 51 49 2b b9 66 13 fc
     49 21

   1 4  0.0043 (0.0000)  S>CV3.3(4)  Handshake
         ServerHelloDone
   Packet data[9]=
     16 03 03 00 04 0e 00 00 00

   1 5  0.0086 (0.0043)  C>SV3.3(104)  Handshake
         ClientKeyExchange
           element[65]=
             04 a0 c6 9b 45 0b 85 ae e3 9f 64 6b 6e 64 d3 c1
             08 39 5f 4b a1 19 2d bf eb f0 de c5 b1 89 13 1f
             59 5d d4 ba cd bd d6 83 8d 92 19 fd 54 29 91 b2
             c0 b0 e4 c4 46 bf e5 8f 3c 03 39 f7 56 e8 9e fd
             a0
           scalar[32]=
             66 92 44 aa 67 cb 00 ea 72 c0 9b 84 a9 db 5b b8
             24 fc 39 82 42 8f cd 40 69 63 ae 08 0e 67 7a 48
   Packet data[109]=
     16 03 03 00 68 10 00 00 64 41 04 a0 c6 9b 45 0b
     85 ae e3 9f 64 6b 6e 64 d3 c1 08 39 5f 4b a1 19
     2d bf eb f0 de c5 b1 89 13 1f 59 5d d4 ba cd bd
     d6 83 8d 92 19 fd 54 29 91 b2 c0 b0 e4 c4 46 bf
     e5 8f 3c 03 39 f7 56 e8 9e fd a0 00 20 66 92 44
     aa 67 cb 00 ea 72 c0 9b 84 a9 db 5b b8 24 fc 39
     82 42 8f cd 40 69 63 ae 08 0e 67 7a 48

   1 6  0.0086 (0.0000)  C>SV3.3(1)  ChangeCipherSpec
   Packet data[6]=
     14 03 03 00 01 01

   1 7  0.0086 (0.0000)  C>SV3.3(40)  Handshake
   Packet data[45]=
     16 03 03 00 28 44 cd 3f 26 ed 64 9a 1b bb 07 c7
     0c 6d 3e 28 af e6 32 b1 17 29 49 a1 14 8e cb 7a
     0b 4b 70 f5 1f 39 c2 9c 7b 6c cc 57 20

   1 8  0.0105 (0.0018)  S>CV3.3(1)  ChangeCipherSpec
   Packet data[6]=
     14 03 03 00 01 01

   1 9  0.0105 (0.0000)  S>CV3.3(40)  Handshake
   Packet data[45]=
     16 03 03 00 28 fd da 3c 9e 48 0a e7 99 ba 41 8c
     9f fd 47 c8 41 2c fd 22 10 77 3f 0f 78 54 5e 41
     a2 21 94 90 12 72 23 18 24 21 c3 60 a4

   1 10 0.0107 (0.0002)  C>SV3.3(100)  application_data
   Packet data....

It should say:

   username: fred
   password: barney

   ---- prior to running TLS-PWD ----

   server generates salt:

   96 3c 77 cd c1 3a 2a 8d 75 cd dd d1 e0 44 99 29
   84 37 11 c2 1d 47 ce 6e 63 83 cd da 37 e4 7d a3

   and a base:

   6e 7c 79 82 1b 9f 8e 80 21 e9 e7 e8 26 e9 ed 28
   c4 a1 8a ef c8 75 0c 72 6f 74 c7 09 61 d7 00 75

   ---- state derived during the TLS-PWD exchange ----

   client and server agree to use brainpoolP256r1

   client and server generate the PE:

   PE.x:
   00 68 6b 0d 3f c4 98 94  dd 62 1e c0 4f 92 5e 02
   9b 2b 15 28 ed ed ca 46  00 72 54 28 1e 9a 6e dc

   server private and mask:

   private:
   21 d9 9d 34 1c 97 97 b3 ae 72 df d2 89 97 1f 1b
   74 ce 9d e6 8a d4 b9 ab f5 48 88 d8 f6 c5 04 3c
   mask:
   0d 96 ab 62 4d 08 2c 71 25 5b e3 64 8d cd 30 3f
   6a b0 ca 61 a9 50 34 a5 53 e3 30 8d 1d 37 44 e5

   client private and mask:

   private:
   17 1d e8 ca a5 35 2d 36 ee 96 a3 99 79 b5 b7 2f
   a1 89 ae 7a 6a 09 c7 7f 7b 43 8a f1 6d f4 a8 8b
   mask:
   4f 74 5b df c2 95 d3 b3 84 29 f7 eb 30 25 a4 88
   83 72 8b 07 d8 86 05 c0 ee 20 23 16 a0 72 d1 bd

   both parties generate premaster secret and master secret

   premaster secret:
   a1 3e 9e a0 d3 56 ab 1d  97 55 a0 f7 33 9e f1 c1
   21 b3 43 f5 2f f2 e6 7f  aa 4c 35 71 3b ed af b1

   master secret:
   f7 73 ba 1d dc a9 89 4c  8b 71 31 48 5a f9 5f dd
   06 83 5e 18 13 26 dd b7  8f 36 03 ef 78 75 67 fb
   01 e9 ad ba 7d e0 d6 0e  89 28 0b 43 74 8d 2f 53

   ---- ssldump output of exchange ----

New TCP connection #1: Charlene Client <-> Sammy Server
   1 1  0.0018 (0.0018)  C>SV3.3(173)  Handshake
         ClientHello
           Version 3.3
           random[32]=
             52 8f bf 52 17 5d e2 c8 69 84 5f db fa 83 44 f7
             d7 32 71 2e bf a6 79 d8 64 3c d3 1a 88 0e 04 3d
           ciphersuites
           TLS_ECCPWD_WITH_AES_128_GCM_SHA256_PRIV
           TLS_ECCPWD_WITH_AES_256_GCM_SHA384_PRIV
           Unknown value 0xff
           compression methods
                     NULL
           extensions
           TLS-PWD unprotected name[5]=
             04 66 72 65 64
           elliptic curve point format[4]=
             03 00 01 02
           elliptic curve list[58]=
             00 38 00 0e 00 0d 00 1c 00 19 00 0b 00 0c 00 1b
             00 18 00 09 00 0a 00 1a 00 16 00 17 00 08 00 06
             00 07 00 14 00 15 00 04 00 05 00 12 00 13 00 01
             00 02 00 03 00 0f 00 10 00 11
   Packet data[178]=
     16 03 03 00 ad 01 00 00 a9 03 03 52 8f bf 52 17
     5d e2 c8 69 84 5f db fa 83 44 f7 d7 32 71 2e bf
     a6 79 d8 64 3c d3 1a 88 0e 04 3d 00 00 06 ff b3
     ff b4 00 ff 01 00 00 7a b8 aa 00 05 04 66 72 65
     64 00 0b 00 04 03 00 01 02 00 0a 00 3a 00 38 00
     0e 00 0d 00 1c 00 19 00 0b 00 0c 00 1b 00 18 00
     09 00 0a 00 1a 00 16 00 17 00 08 00 06 00 07 00
     14 00 15 00 04 00 05 00 12 00 13 00 01 00 02 00
     03 00 0f 00 10 00 11 00 0d 00 22 00 20 06 01 06
     02 06 03 05 01 05 02 05 03 04 01 04 02 04 03 03
     01 03 02 03 03 02 01 02 02 02 03 01 01 00 0f 00
     01 01

1 2  0.0043 (0.0024)  S>CV3.3(94)  Handshake
         ServerHello
           Version 3.3
           random[32]=
             52 8f bf 52 43 78 a1 b1 3b 8d 2c bd 24 70 90 72
             13 69 f8 bf a3 ce eb 3c fc d8 5c bf cd d5 8e aa
           session_id[32]=
             ef ee 38 08 22 09 f2 c1 18 38 e2 30 33 61 e3 d6
             e6 00 6d 18 0e 09 f0 73 d5 21 20 cf 9f bf 62 88
           cipherSuite TLS_ECCPWD_WITH_AES_128_GCM_SHA256_PRIV
           compressionMethod                   NULL
           extensions
           renegotiate[1]=
             00
           elliptic curve point format[4]=
             03 00 01 02
           heartbeat[1]=
             01
   Packet data[99]=
     16 03 03 00 5e 02 00 00 5a 03 03 52 8f bf 52 43
     78 a1 b1 3b 8d 2c bd 24 70 90 72 13 69 f8 bf a3
     ce eb 3c fc d8 5c bf cd d5 8e aa 20 ef ee 38 08
     22 09 f2 c1 18 38 e2 30 33 61 e3 d6 e6 00 6d 18
     0e 09 f0 73 d5 21 20 cf 9f bf 62 88 ff b3 00 00
     12 ff 01 00 01 00 00 0b 00 04 03 00 01 02 00 0f
     00 01 01

1 3  0.0043 (0.0000)  S>CV3.3(141)  Handshake
         ServerKeyExchange
           params
             salt[32]=
               96 3c 77 cd c1 3a 2a 8d 75 cd dd d1 e0 44 99 29
               84 37 11 c2 1d 47 ce 6e 63 83 cd da 37 e4 7d a3
             EC parameters = 3
             curve id = 26
             element[65]=
                  04 7b de a7 7c 03 8e dc d5 66 16 99 81 c5 87 07
                  fa db a8 a8 d8 3e c9 0c 37 e3 c0 66 6a 5a 67 99
                  11 40 d6 85 1a 6c 81 a5 01 75 64 d5 26 b1 57 db
                  cd 97 a6 42 7c b0 e4 7e e5 ca a4 39 66 33 e0 51
                  31

             scalar[32]=
               2f 70 48 96 69 9f c4 24 d3 ce c3 37 17 64 4f 5a
               df 7f 68 48 34 24 ee 51 49 2b b9 66 13 fc 49 21
   Packet data[146]=
     16 03 03 00 8d 0c 00 00 89 00 20 96 3c 77 cd c1
     3a 2a 8d 75 cd dd d1 e0 44 99 29 84 37 11 c2 1d
     47 ce 6e 63 83 cd da 37 e4 7d a3 03 00 1a 41 04
     7b de a7 7c 03 8e dc d5 66 16 99 81 c5 87 07 fa
     db a8 a8 d8 3e c9 0c 37 e3 c0 66 6a 5a 67 99 11
     40 d6 85 1a 6c 81 a5 01 75 64 d5 26 b1 57 db cd
     97 a6 42 7c b0 e4 7e e5 ca a4 39 66 33 e0 51 31
     00 20 2f 70 48 96 69 9f c4 24 d3 ce c3 37 17 64
     4f 5a df 7f 68 48 34 24 ee 51 49 2b b9 66 13 fc
     49 21

1 4  0.0043 (0.0000)  S>CV3.3(4)  Handshake
         ServerHelloDone
   Packet data[9]=
     16 03 03 00 04 0e 00 00 00

1 5  0.0086 (0.0043)  C>SV3.3(104)  Handshake
         ClientKeyExchange
           element[65]=
             04 89 07 f2 0c a8 ff 2b ad bf a6 3e de c5 93 4d
             f1 ec ff 10 75 3f 7a a4 f7 50 ba 8a 2d bd 92 63
             33 3d af f9 43 a2 1c d0 79 d7 75 07 b9 27 82 ee
             77 98 91 98 b9 0a d7 78 de 38 46 c3 19 c7 bc d2
             45

           scalar[32]=
             66 92 44 aa 67 cb 00 ea 72 c0 9b 84 a9 db 5b b8
             24 fc 39 82 42 8f cd 40 69 63 ae 08 0e 67 7a 48
   Packet data[109]=
     16 03 03 00 68 10 00 00 64 41 04 89 07 f2 0c a8
     ff 2b ad bf a6 3e de c5 93 4d f1 ec ff 10 75 3f
     7a a4 f7 50 ba 8a 2d bd 92 63 33 3d af f9 43 a2
     1c d0 79 d7 75 07 b9 27 82 ee 77 98 91 98 b9 0a
     d7 78 de 38 46 c3 19 c7 bc d2 45 00 20 66 92 44
     aa 67 cb 00 ea 72 c0 9b 84 a9 db 5b b8 24 fc 39
     82 42 8f cd 40 69 63 ae 08 0e 67 7a 48

   1 6  0.0086 (0.0000)  C>SV3.3(1)  ChangeCipherSpec
   Packet data[6]=
     14 03 03 00 01 01

   1 7  0.0086 (0.0000)  C>SV3.3(40)  Handshake
   Packet data[45]=
     16 03 03 00 28 00 00 00 00 00 00 00 00 3f c4 e5
     87 f1 1c a6 1e ee f0 8f af ee c9 47 c4 9c 0e 24
     4a 93 56 ab 15 3f f3 4f 0d 43 4a 16 e5

   1 8  0.0105 (0.0018)  S>CV3.3(1)  ChangeCipherSpec
   Packet data[6]=
     14 03 03 00 01 01

   1 9  0.0105 (0.0000)  S>CV3.3(40)  Handshake
   Packet data[45]=
     16 03 03 00 28 00 00 00 00 00 00 00 00 f6 73 c4
     4f f1 62 61 cf d6 a0 e6 46 b0 7f 98 1a 6d 81 37
     24 86 99 42 ec 42 0d a3 76 30 53 c1 92

   1 10 0.0107 (0.0002)  C>SV3.3(100)  application_data
   Packet data....

Notes:

We believe we have found an error regarding the Password Element used in
the example in the appendix.
Curve used in the example: brainpoolP256r1
PE.x used in the example:
29 b2 38 55 81 9f 9c 3f c3 71 ba e2 84 f0 93 a3
a4 fd 34 72 d4 bd 2e 9d f7 15 2d 22 ab 37 aa e6

It appears that this is not a valid point on the given curve. Using
Magma (http://magma.maths.usyd.edu.au/calc/) and the values for
brainpool from https://tools.ietf.org/html/rfc5639#section-3.4 gives a
Legendre Symbol of -1, indicating that y^2 is not a quadratic residue
and therefore that PE.x is not a valid point on the curve. Code used:

a :=
56698187605326110043627228396178346077120614539475214109386828188763884139993;

b :=
17577232497321838841075697789794520262950426058923084567046852300633325438902;

x :=
18859714372486306827330584431184663996963158272766618598705097205657493809894;

p :=
76884956397045344220809746629001649093037950200943055203735601445031516197751;

y2 := (x*x*x + a*x + b) mod p;
ls := LegendreSymbol(y2, p);
print ls;

The PE.x in the example seems to be the PRF output in the third round in
the algorithm in 4.4.1 of the RFC.
In older revisions this value was used directly as the X-Coordinate.
However a) This has changed in newer revisions and
b) The output of the first round is already a valid point and should
therefore be used instead.

The client and server seem to use a different point than the given PE.x on the curve for
their key exchange. The actual value used can be calculated from the
given mask:
PE = (-element) * (mask^-1 mod q)
Actual PE.x:
A7 EE 9B 10 90 C5 DE AF AD FE A2 EC 93 50 1F B8
9E A4 CC 40 2D D5 CE 03 AF 59 FB 4C D1 9B 86 9B

Doing this for the client Element as well gives the same PE.
Using this PE and the given private values also results in the same
premaster secret in the example.

However, the PRF output of the first round (using the base in the
example) is:
AE 80 44 FE 9A 02 7F A3 26 0C B2 4D 26 FB EC FB
0C D3 1A 28 E0 08 79 98 47 6F 48 24 84 28 AA 1B
A1 4C 25 3C E3 00 CF E5
Resulting X-Coordinate ((pwd-tmp mod (p - 1)) + 1)):
00 68 6B 0D 3F C4 98 94 DD 62 1E C0 4F 92 5E 02
9B 2B 15 28 ED ED CA 46 00 72 54 28 1E 9A 6E DC
In decimal:
184490938790914521010164124495537968992184466437601025180409064591686528732
This gives us a Legendre Symbol of 1. This should be the correct PE to
use for the key exchange. The element of the server and client as well
as the premaster and master secret have been adjusted accordingly.

RFC 8521, "Registration Data Access Protocol (RDAP) Object Tagging", November 2018

Source of RFC: regext (art)

Errata ID: 5896
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Scott Hollenbeck
Date Reported: 2019-11-07

Section 3 says:

The bootstrap service registry for the RDAP service provider space is represented using the structure specified in Section 3 of RFC 7484 [RFC7484].

It should say:

The bootstrap service registry for the RDAP service provider space is based on the structure specified in Section 3 of RFC 7484 [RFC7484].

Notes:

The registry structure specific in RFC 8521 includes an additional contact information field that does not appear in the structure defined in RFC 7484. So, the 8521 registry is not "represented using the structure specified in Section 3 of RFC 7484". It extends the structure with the addition of the contact field.

Errata ID: 6310
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Scott Hollenbeck
Date Reported: 2020-10-19

Section 4 says:

RDAP responses that contain values described in this document MUST
   indicate conformance with this specification by including an
   rdapConformance [RFC7483] value of "rdap_objectTag_level_0".  The
   information needed to register this value in the "RDAP Extensions"
   registry is described in Section 5.2.

   The following is an example rdapConformance structure with the
   extension specified.

             "rdapConformance" :
             [
               "rdap_level_0",
               "rdap_objectTag_level_0"
             ]

It should say:

RDAP responses that contain values described in this document MUST
   indicate conformance with this specification by including an
   rdapConformance [RFC7483] value of "rdap_objectTag".  The
   information needed to register this value in the "RDAP Extensions"
   registry is described in Section 5.2.

   The following is an example rdapConformance structure with the
   extension specified.

             "rdapConformance" :
             [
               "rdap_level_0",
               "rdap_objectTag"
             ]

Notes:

The value of the rdapConformance tag MUST match the value in the IANA registry, which is "rdap_objectTag".

RFC 8536, "The Time Zone Information Format (TZif)", February 2019

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 6757
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Carl Gay
Date Reported: 2021-11-28

Section B.3 says:

   | 064    | 00 00 00 03  | isutccnt         | 1                      |
   | 068    | 00 00 00 03  | isstdcnt         | 1                      |
   | 072    | 00 00 00 00  | isleapcnt        | 0                      |
   | 076    | 00 00 00 03  | timecnt          | 1                      |
   | 080    | 00 00 00 03  | typecnt          | 1                      |
   | 084    | 00 00 00 08  | charcnt          | 4                      |

It should say:

   | 064    | 00 00 00 01  | isutccnt         | 1                      |
   | 068    | 00 00 00 01  | isstdcnt         | 1                      |
   | 072    | 00 00 00 00  | isleapcnt        | 0                      |
   | 076    | 00 00 00 01  | timecnt          | 1                      |
   | 080    | 00 00 00 01  | typecnt          | 1                      |
   | 084    | 00 00 00 04  | charcnt          | 4                      |

Notes:

The numbers 1 and 4 are incorrectly encoded as big-endian 32-bit integer values. I'm guessing that the example originally used more data and was then trimmed down (from 3 to 1 for isutccnt, isstdcnt, timecnt, and typecnt, and from 8 to 4 for charcnt) but the integer encodings were never updated.

Errata ID: 7681
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Jacob Pratt
Date Reported: 2023-10-17

Section B.2 says:

   | 135    | 00           | UT/local[0]      | 1 (UT)                 |
...
   | 141    | 00           | standard/wall[0] | 1 (standard)           |

It should say:

   | 135    | 00           | UT/local[0]      | 0 (local)              |
...
   | 141    | 00           | standard/wall[0] | 0 (wall)               |

Notes:

The field value is inconsistent with the hexadecimal octets. This change corrects it to be the same as for bytes 310 and 316 in the same section.

RFC 8554, "Leighton-Micali Hash-Based Signatures", April 2019

Source of RFC: IRTF

Errata ID: 7409
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Campbell
Date Reported: 2023-03-29

Section Section 6.4, Table 3 says:

   +---------+------------+---------+-------------+ 
   | ParmSet | KeyGenTime | SigSize | KeyLifetime | 
   +---------+------------+---------+-------------+ 
                         ... 

   | 15/10   | 6 sec      | 3172    | 9 hours     | 
   |         |            |         |             | 
   | 15/15   | 6 sec      | 3332    | 12 days     | 
   |         |            |         |             | 
   | 20/10   | 3 min      | 3332    | 12 days     | 
   |         |            |         |             | 
   | 20/15   | 3 min      | 3492    | 1 year      | 
   |         |            |         |             | 
   | 25/10   | 1.5 hour   | 3492    | 1 year      | 
   |         |            |         |             | 
   | 25/15   | 1.5 hour   | 3652    | 34 years    | 
   +---------+------------+---------+-------------+ 
 

It should say:

   +---------+------------+---------+-------------+ 
   | ParmSet | KeyGenTime | SigSize | KeyLifetime | 
   +---------+------------+---------+-------------+ 
                         ... 

   | 15/10   | 6 sec      | 3124    | 9 hours     | 
   |         |            |         |             | 
   | 15/15   | 6 sec      | 3284    | 12 days     | 
   |         |            |         |             | 
   | 20/10   | 3 min      | 3284    | 12 days     | 
   |         |            |         |             | 
   | 20/15   | 3 min      | 3444    | 1 year      | 
   |         |            |         |             | 
   | 25/10   | 1.5 hour   | 3444    | 1 year      | 
   |         |            |         |             | 
   | 25/15   | 1.5 hour   | 3604    | 34 years    | 
   +---------+------------+---------+-------------+ 

Notes:

The signature sizes for the two-level HSS parameters in Table 3 are all 48 bytes larger than they should be. It looks like they were computed assuming a 64-byte identifier I in the level-1 LMS public key pub[1], but the identifier was reduced to 16 bytes in draft -07. The signature sizes for the single-level HSS parameters are all correct because they do not have intermediate LMS public keys.

RFC 8555, "Automatic Certificate Management Environment (ACME)", March 2019

Source of RFC: acme (sec)

Errata ID: 5861
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: owen friel
Date Reported: 2019-09-23

Section 7.4.1 says:

It should say:

If a server receives a newAuthz request for an identifier where the authorization object already exists, whether created by CA provisioning on the ACME server or by the ACME server handling a previous newAuthz request from a client, the server returns a 200 (OK) response with the existing authorization URL in the Location header field and the existing JSON authorization object in the body.

Notes:

The above text (or similar) should be appended to the end of section 7.4.1

Errata ID: 7826
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Rob Stradling
Date Reported: 2024-02-28

Section 8.2 says:

The server MUST provide information about its retry state to the 
client via the "error" field in the challenge and the Retry-After 
HTTP header field in response to requests to the challenge resource.

It should say:

In responding to requests to the challenge resource while the status 
of the challenge remains "processing", the server MUST provide 
information about its retry state to the client via the "error" field 
in the challenge and the Retry-After HTTP header field.

Notes:

The current text seems to require the server to include the "error" field and Retry-After HTTP header in all responses to requests for a challenge resource, even before that challenge has moved from "pending" to "processing", and even after that challenge has moved from "processing" to "valid" or "invalid". However, the "State Transitions for Challenge Objects" diagram in Section 7.1.6 shows that it only makes sense for the server to communicate "its retry state" to the client when the challenge is "processing".

I've modelled the structure of my suggested Corrected Text on similar language in Section 7.5.1: "In responding to poll requests while the validation is still in progress, the server MUST...".

RFC 8572, "Secure Zero Touch Provisioning (SZTP)", April 2019

Source of RFC: netconf (ops)

Errata ID: 6691
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Alex Krichevsky
Date Reported: 2021-09-22

Section 8.1 says:

   The DHCPv4 server MAY include a single instance of the
   OPTION_V4_SZTP_REDIRECT option in DHCP messages it sends.  Servers
   MUST NOT send more than one instance of the OPTION_V4_SZTP_REDIRECT
   option.

It should say:

The DHCPv4 server MAY include OPTION_V4_SZTP_REDIRECT in DHCP messages it sends.

Notes:

The original text contradicts the statement in the same section:
"If the length of the 'bootstrap-server-list' field is too large to
fit into a single option, then OPTION_V4_SZTP_REDIRECT MUST be split
into multiple instances of the option according to the process
described in [RFC3396]."

RFC 8574, "cite-as: A Link Relation to Convey a Preferred URI for Referencing", April 2019

Source of RFC: INDEPENDENT

Errata ID: 5697
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2019-04-18

Section 6.3 says:

 type="text/ttl"/>

It should say:

 type="text/turtle"/>

Notes:

I don't find the type text/ttl registered. And, for me, FOAF is application/rdf+xml or text/turtle.

RFC 8584, "Framework for Ethernet VPN Designated Forwarder Election Extensibility", April 2019

Source of RFC: bess (rtg)

Errata ID: 5899
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Sean.Chen
Date Reported: 2019-11-12

Section 1.1 says:

BD: Broadcast Domain.  An EVI may be comprised of one BD
      (VLAN-based or VLAN Bundle services) or multiple BDs (VLAN-aware
      Bundle services).

It should say:

BD: Bridge Domain.  An EVI may be comprised of one BD
      (VLAN-based or VLAN Bundle services) or multiple BDs (VLAN-aware
      Bundle services).

Notes:

broadcast domain is not comprised in any services (VLAN-based or VLAN Bundle service).

Errata ID: 5900
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Frank Lu
Date Reported: 2019-11-12

Section 1.1 says:

BD: Broadcast Domain.  An EVI may be comprised of one BD
      (VLAN-based or VLAN Bundle services) or multiple BDs (VLAN-aware
      Bundle services).

It should say:

BD: Broadcast Domain.  An EVI may be comprised of one BD
      (VLAN-based) or multiple BDs (VLAN Bundle services 
or VLAN-aware Bundle services).

Notes:

By definition, tgere

Errata ID: 7811
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Luc André Burdet
Date Reported: 2024-02-15

Section 3.2 says:

   Where:

   o  DF(V) is defined to be the address Si (index i) for which
      Weight(V, Es, Si) is the highest; 0 <= i < N-1.

   o  BDF(V) is defined as that PE with address Sk for which the
      computed Weight is the next highest after the Weight of the DF.
      j is the running index from 0 to N-1; i and k are selected values.

It should say:

   Where:

   o  DF(V) is defined to be the address Si (index i) for which
      Weight(V, Es, Si) is the highest; 0 <= i <= N-1.

   o  BDF(V) is defined as that PE with address Sk for which the
      computed Weight is the next highest after the Weight of the DF.
      j is the running index from 0 to N-1; i and k are selected values.

Notes:

Paul Kyzivat raised a point while reviewing EVPN Port-Active draft, that really points to a possible algorithm errata in RFC8584 ;

Basically, when evaluating the DF for HRW,
> * DF(Es) is defined to be the address Si (index i) for which
> Weight(Es, Si) is the highest; 0 <= i < N-1.

Here,

if N=1, no remotes: 0 <= i < 0 -- ERROR

if N=2, 1 peer: 0 <= i < 1 -> possible values are only 0 meaning index 1 (the peer)’s weight is not considered.
Logically, this should be 0 <= i <= N-1 or 0 <= i < N ?

RFC 8588, "Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN)", May 2019

Source of RFC: stir (art)

Errata ID: 6656
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Rob Thomas
Date Reported: 2021-08-10

Section 6 says:

Protected Header
   {
      "alg":"ES256",
      "typ":"passport",
      "ppt":"shaken",
      "x5u":"https://cert.example.org/passport.cer"
   }
   Payload
   {
      "attest":"A"
      "dest":{"tn":["12155550131"]}
      "iat":"1443208345",
      "orig":{"tn":"12155550121"},
      "origid":"123e4567-e89b-12d3-a456-426655440000"
   }

It should say:

Protected Header
   {
      "alg":"ES256",
      "typ":"passport",
      "ppt":"shaken",
      "x5u":"https://cert.example.org/passport.cer"
   }
   Payload
   {
      "attest":"A"
      "dest":{"tn":["12155550131"]}
      "iat":1443208345,
      "orig":{"tn":"12155550121"},
      "origid":"123e4567-e89b-12d3-a456-426655440000"
   }

Notes:

As per RFC8225 (5.1.1), 'iat' is a NumericDate format, which is a number (commonly referred to as a utime). Section 9.4 also specifies that anything that is numeric must be encoded as a number.

RFC 8599, "Push Notification with the Session Initiation Protocol (SIP)", May 2019

Source of RFC: sipcore (art)

Errata ID: 7136
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Alex Vasilchenko
Date Reported: 2022-09-18

Section 1; 4.1.3 says:

In section 1. Introduction it says:
Example of a SIP REGISTER request in the flow above:

REGISTER sip:alice@example.com SIP/2.0
(the rest part of the message is omitted)

In section 4.1.4.  Sending Binding-Refresh Requests Using Non-push Mechanism it says:

Example of a SIP REGISTER request including a 'sip.pnsreg' media feature tag:

REGISTER sip:alice@example.com SIP/2.0
(the rest part of the message is omitted)

It should say:

In section 1. Introduction it should be:
Example of a SIP REGISTER request in the flow above:

REGISTER sip:example.com SIP/2.0
(the rest part of the message is omitted)

In section 4.1.4.  Sending Binding-Refresh Requests Using Non-push Mechanism it should be:

Example of a SIP REGISTER request including a 'sip.pnsreg' media feature tag:

REGISTER sip:example.com SIP/2.0
(the rest part of the message is omitted)

Notes:

The error is in R-URI:
REGISTER sip:alice@example.com SIP/2.0
It should be:
REGISTER sip:example.com SIP/2.0

According to RFC3261 - 10.2 Constructing the REGISTER Request - Request-URI: The Request-URI names the domain of the location service for which the registration is meant (for example, "sip:chicago.com"). The "userinfo" and "@" components of the SIP URI MUST NOT be present.

RFC 8601, "Message Header Field for Indicating Message Authentication Status", May 2019

Source of RFC: dmarc (art)

Errata ID: 6026
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: John Levine
Date Reported: 2020-03-22

Section 2.2 says:

     resinfo = [CFWS] ";" methodspec [ CFWS reasonspec ]
               [ CFWS 1*propspec ]

It should say:

     resinfo = [CFWS] ";" methodspec [ CFWS reasonspec ]
               *( CFWS propspec )

Notes:

When there is more than one propspec, they are separated by spaces. Every implementation I know puts in the spaces. This was correct in RFC 7601, but see unconfirmed erratum 5435 which introduced the mistake.

While we're at it, take out the [CFWS] at the end of the definition of pvalue which is redundant and confusing.

Errata ID: 6027
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: John Levine
Date Reported: 2020-03-22

Section Appendix B says:

                  spf=pass smtp.mailfrom=example.net

It should say:

                  spf=pass smtp.mailfrom=sender@example.net

Notes:

This error appears three places in Appendix B. smtp.mailfrom takes a mailbox, not a domain name.

The example in section 2.7.4 at the bottom of page 21 is OK.

Errata ID: 6790
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Scott Kitterman
Date Reported: 2021-12-21

Section 8 says:

   [DKIM]     Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
              "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
              RFC 6376, DOI 10.17487/RFC6376, September 2011,
              <https://www.rfc-editor.org/info/rfc6376>.

It should say:

   [DKIM]     Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
              "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
              RFC 6376, DOI 10.17487/RFC6376, September 2011,
              <https://www.rfc-editor.org/info/rfc6376>.

Notes:

In the next revision, this reference should be moved from Section 8.2, informative references, to Section 8.1, normative references. In Section 2.2, formal definition, the definition for domain-name is taken from RFC 6376, so it's not merely informative.

RFC 8620, "The JSON Meta Application Protocol (JMAP)", July 2019

Note: This RFC has been updated by RFC 9404

Source of RFC: jmap (art)

Errata ID: 6603
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Neil Jenkins
Date Reported: 2021-06-09

Section 5.6 says:

In the "upToId" request argument definition:

      If the sort and
      filter are both only on immutable properties, this allows the
      server to omit changes after this point in the results, which can
      significantly increase efficiency.  If they are not immutable,
      this argument is ignored.

In the "removed" response argument definition:

      If the sort and filter are both only on immutable properties and
      an "upToId" is supplied and exists in the results, any ids that
      were removed but have a higher index than "upToId" SHOULD be
      omitted.

In the "added" response argument definition:

      If the sort and filter are both only on immutable properties and
      an "upToId" is supplied and exists in the results, any ids that
      were added but have a higher index than "upToId" SHOULD be
      omitted.

It should say:

In the upToId argument definition:

      The server may be able to omit added or removed items that are 
      after the client's last cached id, making the update more efficient.

In the "removed" response argument definition:

      If an "upToId" is supplied and existed in the old results, any ids
      that were removed but had a higher index than "upToId" in those
      results SHOULD be omitted.  If the server cannot calculate this,
      the "upToId" MUST be ignored.

In the "added" response argument definition:

      If an "upToId" is supplied and exists in the new results, any ids
      that were added but have a higher index than "upToId" SHOULD be
      omitted.

Notes:

This errata fixes two issues with the upToId definition:

1. Using upToId doesn't require immutable properties in some server implementations; this is an implementation detail. The important thing is it's an optional optimisation that the server can ignore if it does not have the data to calculate it. The text has been updated to reflect this.

2. Clarify that for the "removed" argument, the indexes we are comparing for the upToId optimisation are of the ids in the *old* results. The original text is unclear and seems to imply you might compare with the index of the id in the new results, which will give an incorrect result.

Errata ID: 6604
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Neil Jenkins
Date Reported: 2021-06-09

Section 5.6 says:

   If it *splices out* all ids in the removed array that it has in its
   cached results, then:

      removed = [ "id2", "id31", ... ];
      fooIds => [ "id1", null, null, "id3", "id4", null, null, null ]

   and *splices in* (one by one in order, starting with the lowest
   index) all of the ids in the added array:

  added = [{ id: "id5", index: 0, ... }];
  fooIds => [ "id5", "id1", null, null, "id3", "id4", null, null, null ]

It should say:

   If it *splices out* all ids in the removed array that it has in its
   cached results, then:

      removed = [ "id2", "id31", ... ];
      fooIds => [ "id1", null, null, "id3", "id4", null, null, null ]

   and if any of the "removed" ids were not found, invalidates all
   cached ids after the first gap in the sparse array:

       fooIds => [ "id1", null, null, null, null, null, null, null ]

   and *splices in* (one by one in order, starting with the lowest
   index) all of the ids in the added array:

   added = [{ id: "id5", index: 0, ... }];
   fooIds => [ "id5", "id1", null, null, null, null, null, null, null ]

Notes:

Adds a critical step that was omitted from the description for how a client should process a "/queryUpdates" response. Without this step, the client could end up with ids in incorrect positions in its cached query results.

Errata ID: 6605
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Neil Jenkins
Date Reported: 2021-06-09

Section 5.5 says:

   o  position: "UnsignedInt"

      The zero-based index of the first result in the "ids" array within
      the complete list of query results.

It should say:

   o  position: "UnsignedInt"

      The zero-based index of the first result in the "ids" array within
      the complete list of query results.  If the "ids" array is empty,
      the value is undefined and MUST NOT be used by the client.

Notes:

The position response argument in "/query" is only defined when there is at least one id returned in the response. Make it clearer that when there are no ids returned, the client cannot rely on it being any particular value.

Errata ID: 6606
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Neil Jenkins
Date Reported: 2021-06-09

Section 3.3 says:

o  using: "String[]"

      The set of capabilities the client wishes to use.  The client MAY
      include capability identifiers even if the method calls it makes
      do not utilise those capabilities.  The server advertises the set
      of specifications it supports in the Session object (see
      Section 2), as keys on the "capabilities" property.

It should say:

o  using: "String[]"

      The set of capabilities the client wishes to use.  The client MAY
      include capability identifiers even if the method calls it makes
      do not utilise those capabilities.  The server advertises the set
      of specifications it supports in the Session object (see
      Section 2), as keys on the "capabilities" property.  The
      "urn:ietf:params:jmap:core" capability represents this document
      and MUST be included in the "using" list.  This is to allow a
      smooth upgrade path for future revisions to the core JMAP
      specification with different capability identifiers.

Notes:

The original text was unclear on whether the capability for this document (JMAP core) had to be included in the "using" list, or just those of extensions to JMAP core. Clarify that the "core" capability must also be included, and give the rationale.

Errata ID: 6607
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Neil Jenkins
Date Reported: 2021-06-09

Section 5.3 says:

   [...]                             In the case of records with
   references to the same type, the server MUST order the creates and
   updates within a single method call so that creates happen before
   their creation ids are referenced by another create/update/destroy in
   the same call.

It should say:

   [...]                             In the case of records with
   references to the same type, the server MUST order the creates and
   updates within a single method call so that creates happen before
   their creation ids are referenced by another create/update/destroy in
   the same call.

   A record may be updated/destroyed in the same request as it is
   created.  The update/destroy arguments may use creation ids as keys
   by prefixing the creation id with a "#".

Notes:

Clarify that it's explicitly permitted to update/destroy records created in the same request using the same mechanism as setting foreign keys in records.

RFC 8624, "Algorithm Implementation Requirements and Usage Guidance for DNSSEC", June 2019

Note: This RFC has been updated by RFC 9157

Source of RFC: dnsop (ops)

Errata ID: 6227
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Mats Dufberg
Date Reported: 2020-07-10

Section 6 says:

   This document has no IANA actions.

It should say:

   This document updates the IANA registry "Delegation Signer (DS) Resource 
   Record (RR) Type Digest Algorithms". The registry has been updated by
   the following table from section 3.3:

   +--------+-----------------+-------------------+-------------------+
   | Number | Mnemonics       | DNSSEC Delegation | DNSSEC Validation |
   +--------+-----------------+-------------------+-------------------+
   | 0      | NULL (CDS only) | MUST NOT [*]      | MUST NOT [*]      |
   | 1      | SHA-1           | MUST NOT          | MUST              |
   | 2      | SHA-256         | MUST              | MUST              |
   | 3      | GOST R 34.11-94 | MUST NOT          | MAY               |
   | 4      | SHA-384         | MAY               | RECOMMENDED       |
   +--------+-----------------+-------------------+-------------------+

   [*] - This is a special type of CDS record signaling removal of DS at
         the parent in [RFC8078].


   This document updates the IANA registry "DNS Security Algorithm Numbers". 
   The registry has been updated by the following table from section 3.1:

   +--------+--------------------+-----------------+-------------------+
   | Number | Mnemonics          | DNSSEC Signing  | DNSSEC Validation |
   +--------+--------------------+-----------------+-------------------+
   | 1      | RSAMD5             | MUST NOT        | MUST NOT          |
   | 3      | DSA                | MUST NOT        | MUST NOT          |
   | 5      | RSASHA1            | NOT RECOMMENDED | MUST              |
   | 6      | DSA-NSEC3-SHA1     | MUST NOT        | MUST NOT          |
   | 7      | RSASHA1-NSEC3-SHA1 | NOT RECOMMENDED | MUST              |
   | 8      | RSASHA256          | MUST            | MUST              |
   | 10     | RSASHA512          | NOT RECOMMENDED | MUST              |
   | 12     | ECC-GOST           | MUST NOT        | MAY               |
   | 13     | ECDSAP256SHA256    | MUST            | MUST              |
   | 14     | ECDSAP384SHA384    | MAY             | RECOMMENDED       |
   | 15     | ED25519            | RECOMMENDED     | RECOMMENDED       |
   | 16     | ED448              | MAY             | RECOMMENDED       |
   +--------+--------------------+-----------------+-------------------+

Notes:

The document clearly has the intention to update the IANA registers, which is also stated in the document, but not in section 6 ("IANA Considerations").

RFC 8627, "RTP Payload Format for Flexible Forward Error Correction (FEC)", July 2019

Source of RFC: payload (art)

Errata ID: 6334
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Jonathan Lennox
Date Reported: 2020-11-16

Section 7.1.1 says:

        a=fmtp:98; repair-window=200000

It should say:

        a=fmtp:98 repair-window=200000

Notes:

The example has invalid syntax for the SDP "fmtp" attribute.

Errata ID: 6335
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Jonathan Lennox
Date Reported: 2020-11-16

Section 7.1.2 says:

        a=fmtp:110; repair-window:200000

It should say:

        a=fmtp:110 repair-window:200000

Notes:

The example has invalid syntax for the SDP "fmtp" attribute.

RFC 8628, "OAuth 2.0 Device Authorization Grant", August 2019

Source of RFC: oauth (sec)

Errata ID: 5840
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Konstantin Lapine
Date Reported: 2019-08-19

Section 5.2 says:

An attacker who guesses the device code would be able to potentially
   obtain the authorization code once the user completes the flow.

It should say:

An attacker who guesses the device code would be able to potentially
   obtain the access token once the user completes the flow.

Notes:

The "authorization code" term is associated with Authorization Code Grant (defined in RFC 6749) and has the meaning of a temporary credential used by an OAuth 2.0 client to obtain the access token. Section 5.2 of RFC 8628 seems to refer to the steps of the device authorization flow during which the device code and the client identifier are exchanged for the access token (and the optional refresh token).

Alternative correction:

"An attacker who guesses the device code would be able to potentially obtain the access token and the optional refresh token once the user completes the flow."

RFC 8640, "Dynamic Subscription to YANG Events and Datastores over NETCONF", September 2019

Source of RFC: netconf (ops)

Errata ID: 6886
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Jernej Tuljak
Date Reported: 2022-03-16

Section A. 4. says:

 <rpc message-id="601" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
   <establish-subscription
     xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
     <stream>NETCONF</stream>
     <stream-xpath-filter xmlns="urn:ietf:params:xml:ns:yang:ietf-vrrp">
       /vrrp-protocol-error-event[
          vrrp:protocol-error-reason="vrrp:checksum-error"]
     </stream-xpath-filter>
   </establish-subscription>
 </rpc>

It should say:

 <rpc message-id="601" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
   <establish-subscription
     xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
     <stream>NETCONF</stream>
     <stream-xpath-filter xmlns:vrrp="urn:ietf:params:xml:ns:yang:ietf-vrrp">
       /vrrp:vrrp-protocol-error-event[
          derived-from-or-self(vrrp:protocol-error-reason, "vrrp:checksum-error")]
     </stream-xpath-filter>
   </establish-subscription>
 </rpc>

Notes:

The original example put <stream-xpath-filter> element in a wrong namespace, never defined a namespace binding for prefix "vrrp" and checked a value of type identityref by treating it as an XPath string literal (instead of using the XPath function from RFC 7950, which is allowed by type definition of leaf "stream-xpath-filter").

RFC 8650, "Dynamic Subscription to YANG Events and Datastores over RESTCONF", November 2019

Source of RFC: netconf (ops)

Errata ID: 6985
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Jernej Tuljak
Date Reported: 2022-06-01

Section A.1.1. says:

HTTP status code - 200

{
   "id": 22,
   "uri": "https://example.com/restconf/subscriptions/22"
}

It should say:

HTTP status code - 200

{
   "ietf-subscribed-notifications:output": {
      "id": 22,
      "ietf-restconf-subscribed-notifications:uri":
         "https://example.com/restconf/subscriptions/22"
   }
   
}

Notes:

Original text for Figure 4 does not comply with RFC8040, Section 3.6.2. Encoding Operation Resource Output Parameters.

Errata ID: 6367
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Muly Ilan
Date Reported: 2020-12-24

Section A.1.3 says:

A.1.3.  Deleting Dynamic Subscriptions

   The following demonstrates deleting a subscription.  This
   subscription may have been to either a stream or a datastore.

   POST /restconf/operations
        /ietf-subscribed-notifications:delete-subscription

   {
    "delete-subscription": {
       "id": "22"
    }
   }

It should say:

A.1.3.  Deleting Dynamic Subscriptions

   The following demonstrates deleting a subscription.  This
   subscription may have been to either a stream or a datastore.

   POST /restconf/operations
        /ietf-subscribed-notifications:delete-subscription

   {
    "ietf-subscribed-notifications:input": {
       "id": "22"
    }
   }

Notes:

Encoding of RPC input parameters should follow RFC 8040 section 3.6.1

RFC 8659, "DNS Certification Authority Authorization (CAA) Resource Record", November 2019

Source of RFC: lamps (sec)

Errata ID: 7139
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Brian Dickson
Date Reported: 2022-09-02

Section 4.2 says:

   parameters = (parameter *WSP ";" *WSP parameters) / parameter
   parameter = tag *WSP "=" *WSP value
   tag = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT))
   value = *(%x21-3A / %x3C-7E)

It should say:

   parameters = (parameter *WSP ";" *WSP parameters) / parameter
   parameter = parameter-tag *WSP "=" *WSP parameter-value
   parameter-tag = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT))
   parameter-value = *(%x21-3A / %x3C-7E)

Notes:

1. Original text uses "tag" and "value" in the ABNF is ambiguous or conflicting with the usage of "tag" and "value" in terms "Property Tag" and "Property Value" (which are in the main CAA context).

2. The text for "tag" (meaning Property Tag) in 4.1.1 reads:

Tag: A non-zero-length sequence of ASCII letters and numbers in
lowercase.

3. The Tag definition above does not have an ABNF definition. This can (and does) lead to confusion for implementers.

The above change to the ABNF removes the ambiguity, without changing the meaning of the ABNF itself.

Errata ID: 5934
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: IIDA Yosiaki
Date Reported: 2019-12-12

Section 7 says:

It also allows hyphens in Property Tags.

It should say:

It also allows hyphens in tags of Property Value of
issue and issuewild Property Tags.

Notes:

Subsection 4.1 explicitly prohibits hyphens in Property Tags.
While obsoleted RFC 6844 did not allow hyphens in tags of Property Value of issue and issuewild Property Tags, new ABNF definition in subsection 4.2 allows them.

RFC 8688, "A Session Initiation Protocol (SIP) Response Code for Rejected Calls", December 2019

Source of RFC: sipcore (art)

Errata ID: 6586
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Amrita Bhatt
Date Reported: 2021-05-18

Section 3 says:

                         +--------+         +-----------+
                         | Called |         |   Call    |
        +-----+          | Party  |         | Analytics |   +-----+
        | UAC |          | Proxy  |         |  Engine   |   | UAS |
        +-----+          +--------+         +-----------+   +-----+
           |  INVITE         |                    |            |
           | --------------> |  Is call OK?       |            |
           |                 |------------------->|            |
           |                 |                    |            |
           |                 |               Yes  |            |
           |                 |<-------------------|            |
           |                 |                    |            |
           |                 | INVITE             |            |
           |                 | ------------------------------> |
           |                 |                    |            |
           |                 |                    |       607  |
           |                 | <------------------------------ |
           |                 |                    |            |
           |                 |  Unwanted call     |            |
           |            607  | -----------------> |            |
           | <-------------- |  indicators        |            |
           |                 |                    |            |

It should say:

                         +--------+         +-----------+
                         | Called |         |   Call    |
        +-----+          | Party  |         | Analytics |   +-----+
        | UAC |          | Proxy  |         |  Engine   |   | UAS |
        +-----+          +--------+         +-----------+   +-----+
           |  INVITE         |                    |            |
           | --------------> |  Is call OK?       |            |
           |                 |------------------->|            |
           |                 |                    |            |
           |                 |               No   |            |
           |                 |<-------------------|            |
           |                 |                    |            |
           |                 |              	  |            |
           |                 |                    |            |
           |                 |                    |            |
           |            608  |                    |            |
           | <-------------- |                    |            |
           |                 |                    |            |

Notes:

"Figure 4: Rejected (608) Ladder Diagram" does not depict correct signalling flow.

RFC 8689, "SMTP Require TLS Option", November 2019

Source of RFC: uta (sec)

Errata ID: 7705
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Mechiel Lukkien
Date Reported: 2023-11-20

Section 4.2.1 says:

   4.  Establish a TLS-protected SMTP session with its peer SMTP server
       and authenticate the server's certificate as specified in
       [RFC6125] or [RFC7672], as applicable.  The hostname from the MX
       record lookup (or the domain name in the absence of an MX record
       where an A record is used directly) MUST match the DNS-ID or CN-
       ID of the certificate presented by the server.

It should say:

   4.  Establish a TLS-protected SMTP session with its peer SMTP server
       and authenticate the server's certificate as specified in
       [RFC6125] or [RFC7672], as applicable.

Notes:

The second sentence tries to explain/summarize the policies found in the RFCs referenced in the first sentence, about PKIX and DANE. But the explanation seems to accidentally sets new requirements that contradict behaviour specified by DANE: With DANE-EE TLSA records, no specific hostname validation must be done, instead verification is done based on (hash of) SPKI/entire certificate. (DANE-TA hostname verification is also a bit more nuanced). Since the requirements are accurately explained in the RFCs referenced in the first sentence, it seems better to completely remove the second sentence.

I would also like to point out that implementers may want to take care not to treat the situation where all TLSA records are "unusable" (as explained in DANE RFCs) as "authenticated with DANE", in line with "[...] or it MUST be verified successfully using DANE [...]" on line 197.

RFC 8693, "OAuth 2.0 Token Exchange", January 2020

Source of RFC: oauth (sec)

Errata ID: 7511
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Jesse Estum
Date Reported: 2023-05-08

Section 2.1 says:

Client authentication to the authorization server is done using the 
normal mechanisms provided by OAuth 2.0. Section 2.3.1 of [RFC6749] 
defines password-based authentication of the client, however, client 
authentication is extensible and other mechanisms are possible. For 
example, [RFC7523] defines client authentication using bearer JSON Web 
Tokens (JWTs) [JWT]. The supported methods of client authentication and 
whether or not to allow unauthenticated or unidentified clients are 
deployment decisions that are at the discretion of the authorization 
server.

It should say:

Client authentication to the authorization server is done using the 
normal mechanisms provided by OAuth 2.0. Section 2.3.1 of [RFC6749] 
defines password-based authentication of the client, however, client 
authentication is extensible and other mechanisms are possible. The 
supported methods of client authentication and whether or not to allow 
unauthenticated or unidentified clients are deployment decisions that 
are at the discretion of the authorization server. 

Notes:

The specific example of authentication with RFC7523 would require "grant_type" value of "urn:ietf:params:oauth:grant-type:jwt-bearer", however this directly conflicts with RFC8693 as it requires "grant_type" value of "urn:ietf:params:oauth:grant-type:token-exchange".

RFC 8702, "Use of the SHAKE One-Way Hash Functions in the Cryptographic Message Syntax (CMS)", January 2020

Source of RFC: lamps (sec)

Errata ID: 6188
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Panos Kampanakis
Date Reported: 2020-05-26

Section 3.4 says:

When calculating the KMAC output, the variable N is 0xD2B282C2, S is
an empty string, and L (the integer representing the requested output
length in bits) is 256 or 512 for KmacWithSHAKE128 or
KmacWithSHAKE256, respectively, in this specification.

It should say:

When calculating the KMAC output, the variable N is “KMAC” as defined 
in NIST SP800-185, S is an empty string, and L (the integer 
representing the requested output length in bits) is 256 or 512 for 
KmacWithSHAKE128 or KmacWithSHAKE256, respectively, in this 
specification.

Notes:

The originally described 0xD2B282C2 is the hex value of the binary representation (LSB first) of the string "KMAC" as defined in SP800-185. As it was pointed out to us, that representation was confusing and incorrect because NIST's KAT values include "KMAC" in hex format. Showing "KMAC" in binary (LSB first) is different than showing it in hex (MSB first). So, it is more accurate to keep the text generic as "KMAC" and point implementers to SP800-185.

Errata ID: 7276
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2022-12-15

Throughout the document, when it says:

... id-KmacWithSHAKE128 ...

... id-KmacWithSHAKE256 ...

It should say:

... id-KMACWithSHAKE128 ...

... id-KMACWithSHAKE256 ...

Notes:

The ASN.1 Module in RFC 8702 defines id-KMACWithSHAKE128 and id-KMACWithSHAKE256, but the body of the document uses "Kmac" instead of "KMAC". The different spelling appears in many places in the document.

Errata ID: 7288
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: David Ireland
Date Reported: 2022-12-26

Section 3.4 says:

If absent, the SHAKE256 output length used in KMAC is 
32 or 64 bytes, respectively, 

It should say:

If absent, the SHAKE128 or SHAKE256 output length 
used in KMAC is 32 or 64 bytes, respectively, 

Notes:

The adverb 'Respectively' requires two parallel structures. SHAKE128=>32, SHAKE256=>64.

RFC 8743, "Multiple Access Management Services Multi-Access Management Services (MAMS)", March 2020

Source of RFC: INDEPENDENT

Errata ID: 7265
Status: Reported
Type: Technical
Publication Format(s) : PDF
Reported By: Dacheng Huang
Date Reported: 2022-12-12

Section C.2.11. says:

ConvergenceConfig convergence_config

It should say:

ConvergenceConfig convergence_config <1..*>;

Notes:

the "convergence_config" field should be an array of ConvergenceConfig. And the description in the schemas of MX UP Setup Configuration Request in Chapter C.3.10 also confirms this point

Errata ID: 7266
Status: Reported
Type: Technical
Publication Format(s) : PDF
Reported By: Dacheng Huang
Date Reported: 2022-12-12

Section C.2.12 says:

Probe Delay: Average delay of probe message, in microseconds.

It should say:

null

Notes:

This data type does not include probe latency in the definition described later. This is also confirmed in the description in Chapter 8.6.

Errata ID: 7267
Status: Reported
Type: Technical
Publication Format(s) : PDF
Reported By: Dacheng Huang
Date Reported: 2022-12-12

Section C.4.8. says:

{
"connection_id": 0,
"connection_type": "LTE",
"udp_port": 8888,
"num_delivery_connections": 2,
"delivery_connections": [{
"connection_id": 0,
"connection_type": "LTE"
},
{
"connection_id": 1,
"connection_type": "Wi-Fi",
"adaptation_method": "UDP_without_DTLS",
"adaptation_method_param": {
"tunnel_ip_addr": "192.168.3.3",
"tunnel_end_port": "6000"
}
}
]
}

It should say:

{
	"connection_id": 0,
	"connection_type": "LTE",
	"num_active_mx_conf": 1,
	"convergence_config": [{
		"mx_configuration_id": 1,
		"convergence_method": "MPTCP",
		"convergence_method_params": {},
		"num_delivery_connections": 2,
		"delivery_connections": [{
				"connection_id": 0,
				"connection_type": "LTE"
			},
			{
				"connection_id": 1,
				"connection_type": "Wi-Fi",
				"adaptation_method": "UDP_without_DTLS",
				"adaptation_method_param": {
					"tunnel_ip_addr": "192.168.3.3",
					"tunnel_end_port": "6000"
				}
			}
		]
	}]
}

Notes:

The "udp_port" field should be deleted. And it is missing "num_active_mx_conf" field and "convergence_config" field.
The "num_delivery_connections" field and "delivery_connections" field should be in the item of "convergence_config" field

RFC 8774, "The Quantum Bug", April 2020

Source of RFC: INDEPENDENT

Errata ID: 6077
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ángel
Date Reported: 2020-04-01

Section 1 says:

time travel will never work (or it would already have been used).

It should say:

time travel is still not available in the consumer market.

Notes:

While the introduction section may allow some more leniency, its discarding of RFC6921 based on an unfounded dismissal of time travel shows a lack of the required technical competence that should be cardinal for a serious publication such as this [RFC 3935]. The simplistic "it would already have been used" misses any rigorous testing and falls for the fallacy best described by the 19th century aphorism Absence of Evidence Is Not Evidence of Absence [QUOTE-INV]. Not only do we lack any method to detect whether time travel has been used already (with 'already being used' defined as the timestamp of either point of the time travel journey being prior to the current point in time, i.e. satisfying a lesser-than operation when the representations of their TAI [IEEE1588] values are checked with the comparison defined in [RFC2550]) but there are also many sensible reasons for time travel invented in the future not leading (coronavirus-aside) to an interaction with 2020 human beings (much less to a widely known one), as has been thoroughly studied in [WHY-HAVENT].



[RFC6921] Hinden, R., "Design Considerations for Faster-Than-Light
(FTL) Communication", RFC 6921, DOI 10.17487/RFC6921,
April 2013, <https://www.rfc-editor.org/info/rfc6921>.

[QUOTE-INV] Quote Investigator "Absence of Evidence Is Not Evidence
of Absence", 17 September 2019

[IEEE1588] IEEE, "IEEE Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems",
IEEE Std 1588-2008, DOI 10.1109/IEEESTD.2008.4579760, July
2008.

[RFC2550] S. Glassman, M. Manasse, J. Mogul, "Y10K and Beyond", RFC 2550,
April 1999, <https://www.rfc-editor.org/info/rfc2550>

[WHY-HAVENT] World Building Community, "If time travel is possible in the
future, no matter how distant, why haven't they come back to
tell us?", August 2016
<https://worldbuilding.stackexchange.com/questions/51210/if-time-travel-is-possible-in-the-future-no-matter-how-distant-why-havent-the/51377>

RFC 8794, "Extensible Binary Meta Language", July 2020

Source of RFC: cellar (art)

Errata ID: 7185
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Steve Lhomme
Date Reported: 2022-10-30

Section 11.1.16 says:

       <xs:attribute name="maxOccurs" default="1">
         <xs:simpleType>
           <xs:restriction base="xs:integer">
             <xs:minInclusive value="0"/>
           </xs:restriction>
         </xs:simpleType>
       </xs:attribute>

It should say:

       <xs:attribute name="maxOccurs" default="unbounded">
         <xs:simpleType>
           <xs:union>
             <xs:simpleType>
               <xs:restriction base="xs:integer">
                 <xs:minInclusive value="0"/>
               </xs:restriction>
             </xs:simpleType>
             <xs:simpleType>
               <xs:restriction base="xs:string">
                 <xs:enumeration value="unbounded"/>
               </xs:restriction>
             </xs:simpleType>
           </xs:union>
         </xs:simpleType>
       </xs:attribute>

Notes:

maxOccurs doesn't have a defined default value and has no upper bound.

See https://github.com/ietf-wg-cellar/ebml-specification/issues/395

Errata ID: 7187
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Steve Lhomme
Date Reported: 2022-10-30

Section 15.1. says:

   Non-mandatory EBML Elements can be added in a new EBMLDocTypeVersion.
   Since they are not mandatory, they won't be found in older versions
   of the EBMLDocTypeVersion, just as they might not be found in newer
   versions.  This causes no compatibility issue.

It should say:

   Non-mandatory EBML Elements can be added in a new DocTypeVersion.
   Since they are not mandatory, they won't be found in older versions
   of the DocTypeVersion, just as they might not be found in newer
   versions.  This causes no compatibility issue.

Notes:

Use DocTypeVersion in the text rather than EBMLDocTypeVersion for more consistency.

See https://github.com/ietf-wg-cellar/ebml-specification/pull/405

Errata ID: 7190
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Steve Lhomme
Date Reported: 2022-10-30

Section 11.1.6.2. says:

   EBMLAtomName           = ALPHA / DIGIT 0*EBMLNameChar

It should say:

   EBMLAtomName           = (ALPHA / DIGIT) 0*EBMLNameChar

Notes:

Fix grouping in the EBMLAtomName

See https://github.com/ietf-wg-cellar/ebml-specification/pull/418

Errata ID: 7192
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Steve Lhomme
Date Reported: 2022-10-30

Section 7.6. says:

   The Date Element stores an integer in the same format as the Signed
   Integer Element that expresses a point in time referenced in
   nanoseconds from the precise beginning of the third millennium of the
   Gregorian Calendar in Coordinated Universal Time (also known as
   2001-01-01T00:00:00.000000000 UTC).  This provides a possible
   expression of time from 1708-09-11T00:12:44.854775808 UTC to
   2293-04-11T11:47:16.854775807 UTC.

It should say:

   The Date Element stores an integer in the same format as the Signed
   Integer Element that expresses a point in time referenced in
   nanoseconds from the precise beginning of the third millennium of the
   Gregorian Calendar in Coordinated Universal Time (also known as
   2001-01-01T00:00:00.000000000 UTC).  This provides a possible
   expression of time from September 1708 to April 2293.

   The integer stored represents the number of nanoseconds between the
   date to express and 2001-01-01T00:00:00.000000000 UTC, not counting
   leap seconds.  That is 86,400,000,000,000 nanoseconds for each day.
   Conversions from other date systems should ensure leap seconds are
   not counted in EBML values.

   The 2001-01-01T00:00:00.000000000 UTC date also corresponds to
   978307200 seconds in Unix time [POSIX].

Notes:

Add some notice about leap seconds not being counted as in POSIX. Remove bogus nanosecond values.

See https://github.com/ietf-wg-cellar/ebml-specification/pull/415

Errata ID: 7186
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Steve Lhomme
Date Reported: 2022-10-30

Section 10.2. says:

   The version of the EBML Body is found in EBMLDocTypeVersion.  A
   parser for the particular DocType format can read the EBML Document
   if it can read either the EBMLDocTypeVersion version of that format
   or a version equal or higher than the one found in
   EBMLDocTypeReadVersion.

It should say:

   The version of the EBML Body is found in DocTypeVersion.  A parser
   for the particular DocType format can read the EBML Document if it
   can read either the DocTypeVersion version of that format or a
   version equal or higher than the one found in DocTypeReadVersion.

Notes:

Use DocTypeVersion in the text rather than EBMLDocTypeVersion for more consistency.

See https://github.com/ietf-wg-cellar/ebml-specification/pull/405

Errata ID: 7188
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Steve Lhomme
Date Reported: 2022-10-30

Section 15.2. says:

   EBML Elements MAY be marked as deprecated in a new EBMLDocTypeVersion
   using the "maxver" attribute of the EBML Schema.  If such an Element
   is found in an EBML Document with a newer version of the
   EBMLDocTypeVersion, it SHOULD be discarded.

It should say:

   EBML Elements MAY be marked as deprecated in a new DocTypeVersion
   using the "maxver" attribute of the EBML Schema.  If such an Element
   is found in an EBML Document with a newer version of the
   DocTypeVersion, it SHOULD be discarded.

Notes:

Use DocTypeVersion in the text rather than EBMLDocTypeVersion for more consistency.

See https://github.com/ietf-wg-cellar/ebml-specification/pull/405

Errata ID: 7193
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Steve Lhomme
Date Reported: 2022-10-30

Section 19. says:

   [Matroska] Lhomme, S., Bunkus, M., and D. Rice, "Matroska Media
              Container Format Specifications", Work in Progress,
              Internet-Draft, draft-ietf-cellar-matroska-05, 17 April
              2020, <https://tools.ietf.org/html/draft-ietf-cellar-
              matroska-05>.

It should say:

   [Matroska] Lhomme, S., Bunkus, M., and D. Rice, "Matroska Media
              Container Format Specifications", Work in Progress,
              Internet-Draft, draft-ietf-cellar-matroska-05, 17 April
              2020, <https://tools.ietf.org/html/draft-ietf-cellar-
              matroska-05>.

   [POSIX]    IEEE and The Open Group, "Portable Operating System
              Interface (POSIX(R)) Base Specifications, Issue 7",
              DOI 10.1109/IEEESTD.2018.8277153, 31 January 2018,
              <https://standards.ieee.org/standard/1003_1-2017.html>.

Notes:

Added a reference to POSIX for the new nanosecond explanation.

See https://github.com/ietf-wg-cellar/ebml-specification/pull/415

RFC 8823, "Extensions to Automatic Certificate Management Environment for End-User S/MIME Certificates", April 2021

Source of RFC: acme (sec)

Errata ID: 7508
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Richard Wang
Date Reported: 2023-05-04

Section 3.1 and 3.2 says:

Figure 1:
  Message-ID: <A2299BB.FF7788@example.org>
  From: acme-generator@example.org
  To: alexey@example.com

Figure 2:
   Message-ID: <111-22222-3333333@example.com>
   In-Reply-To: <A2299BB.FF7788@example.org>
   From: alexey@example.com
   To: acme-generator@example.org

It should say:

Figure 1:
  Message-ID: <A2299BB.FF7788@example.com>
  From: acme-generator@example.com
  To: alexey@example.org

Figure 2:
   Message-ID: <111-22222-3333333@example.org>
   In-Reply-To: <A2299BB.FF7788@example.com>
   From: alexey@example.org
   To: acme-generator@example.com

Notes:

Accoording to RFC8555, the domain example.com used for ACME server, the example.org used for the Client.

RFC 8864, "Negotiation Data Channels Using the Session Description Protocol (SDP)", January 2021

Source of RFC: mmusic (art)

Errata ID: 7805
Status: Reported
Type: Technical
Publication Format(s) : HTML
Reported By: Harald Alvestrand
Date Reported: 2024-02-09

Section 6.1 says:

   In order to avoid SCTP Stream identifier collisions, in alignment
   with [RFC8832], the endpoint acting as a DTLS client (for the SCTP
   association used to realize data channels) MUST use even identifier
   values, and the endpoint acting as a DTLS server MUST use odd
   identifier values.

It should say:

[RFC8831] does not restrict the SCTP Stream identifiers for data
channels negotiated out-of-band. The endpoints are free to assign
any numbers to the negotiated data channels; collisions are handled
by the usual mechanisms used to avoid SDP signalling glare.

Notes:

The procedures of [RFC8832] are inappropriate in this case, because DCMAP indicates channels negotiated out-of-band and not via DCEP.

At initial offer, the DTLS direction attribute is ACTPASS, so the direction is not known. Thus, the RFC 8832 numbering rule is impossible to apply anyway.

RFC 8878, "Zstandard Compression and the 'application/zstd' Media Type", February 2021

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 7297
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Felix Handte
Date Reported: 2023-01-03

Section 3.1.1.3.1.1 says:

Size_Format == 01:  4 streams.  Both Regenerated_Size and
   Compressed_Size use 10 bits (values 0-1023).
   Literals_Section_Header uses 3 bytes.

Size_Format == 10:  4 streams.  Both Regenerated_Size and
   Compressed_Size use 14 bits (values 0-16383).
   Literals_Section_Header uses 4 bytes.

Size_Format == 11:  4 streams.  Both Regenerated_Size and
   Compressed_Size use 18 bits (values 0-262143).
   Literals_Section_Header uses 5 bytes.

It should say:

Size_Format == 01:  4 streams.  Both Regenerated_Size and
   Compressed_Size use 10 bits (values 6-1023).
   Literals_Section_Header uses 3 bytes.

Size_Format == 10:  4 streams.  Both Regenerated_Size and
   Compressed_Size use 14 bits (values 6-16383).
   Literals_Section_Header uses 4 bytes.

Size_Format == 11:  4 streams.  Both Regenerated_Size and
   Compressed_Size use 18 bits (values 6-262143).
   Literals_Section_Header uses 5 bytes.

Notes:

The calculation for the size of the fourth stream, specified in section 3.1.1.3.1.6, will underflow if the total size of the literals in the block is less than 6 bytes. So the 4-stream mode cannot be used in blocks with fewer than 6 literals. (Nor should it be, since it is strictly less efficient for very small literal sections.)

The source for this errata is https://github.com/facebook/zstd/pull/3398.

Errata ID: 7567
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Jordan Tucker
Date Reported: 2023-07-20

Section 3.1.1.3.1 says:

3.1.1.3.1.  Literals_Section_Header

It should say:

3.1.1.3.1.  Literals_Section

Notes:

Section 3.1.1.3.1 describes the Literals_Section mentioned in and linked from Section 3.1.1.3 Compressed Blocks. However, the section is labeled as Literals_Section_Header resulting in two sections both labeled Literals_Section_Header (sections 3.1.1.3.1 and 3.1.1.3.1.1).

RFC 8881, "Network File System (NFS) Version 4 Minor Version 1 Protocol", August 2020

Source of RFC: nfsv4 (wit)

Errata ID: 6308
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Calum Mackay
Date Reported: 2020-10-16

Section 18.32.3 says:

   *  The server MUST commit the data at a level at least as high as
      that committed.

It should say:

   *  The server MUST commit the data at a level at least as high as
      that requested.

Notes:

The meaning is probably obvious, but perhaps a MUST ought
to be unambiguous?

---

editorial: also, the point above this one uses the word "stronger"
where this point uses "high", both for the stability level.

The two lines should probably use the same word.

Errata ID: 6337
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Charles Lever
Date Reported: 2020-11-16

Section 18.33.1 says:

struct gss_cb_handles4 {
        rpc_gss_svc_t       gcbp_service; /* RFC 2203 */
        gsshandle4_t        gcbp_handle_from_server;
        gsshandle4_t        gcbp_handle_from_client;
};

It should say:

struct gss_cb_handles4 {
        rpc_gss_service_t   gcbp_service; /* RFC 2203 */
        gsshandle4_t        gcbp_handle_from_server;
        gsshandle4_t        gcbp_handle_from_client;
};

Notes:

RFC 2203 (and its successors) do not define rpc_gss_svc_t. I believe the rpc_gss_service_t type was intended.

Errata ID: 6865
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: David Noveck
Date Reported: 2022-02-28

Section 18.25.4 says:

The server MUST NOT delete the directory entry if the reply from 
OPEN had 
the flag OPEN4_RESULT_PRESERVE_UNLINKED set.

It should say:

If the reply from OPEN had the flag OPEN4_RESULT_PRESERVE_UNLINKED set,
The server 
MUST NOI delete the file contents until each directory entry is 
deleted and the file is no longer open.

Notes:

The existing second and third bullets are directly contradictory.

Errata ID: 7386
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Pali Rohár
Date Reported: 2023-03-13

Section 18.46.3. says:

                                                             Operations
   other than SEQUENCE, BIND_CONN_TO_SESSION, EXCHANGE_ID,
   CREATE_SESSION, and DESTROY_SESSION, MUST NOT appear as the first
   operation in a COMPOUND.

It should say:

                                                             Operations
   other than SEQUENCE, BIND_CONN_TO_SESSION, EXCHANGE_ID,
   CREATE_SESSION, DESTROY_SESSION, and DESTROY_CLIENTID, MUST NOT
   appear as the first operation in a COMPOUND.

Notes:

Section 18.50.3. DESCRIPTION of DESTROY_CLIENTID says

"DESTROY_CLIENTID MAY be preceded with a SEQUENCE"

and also says

"If DESTROY_CLIENTID is not prefixed by SEQUENCE, it MUST be the only operation in the COMPOUND request"

which implies that DESTROY_CLIENTID can appear as the first (and the only) operation in a COMPOUND.

Errata ID: 6611
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Seman.Shen
Date Reported: 2021-06-16

Section 18.37.3 says:

*                                             Otherwise, the error
   CB_BACK_CHAN_BUSY SHOULD be returned to indicate that there are
   CB_COMPOUNDs that need to be replied to.

It should say:

*                                                  Otherwise, the error
   NFS4ERR_BACK_CHAN_BUSY SHOULD be returned to indicate that there are
   CB_COMPOUNDs that need to be replied to.

Notes:

CB_BACK_CHAN_BUSY is not defined in this document.

RFC 8886, "Secure Device Install", September 2020

Source of RFC: opsawg (ops)

Errata ID: 6299
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2020-10-05

Section A.2.2 says:

 openssl smime -encrypt -aes-256-cbc -in SN19842256.cfg \
 -out SN19842256.enc \ 
 -outform PEM SN19842256.crt

It should say:

No corrected text, I think it requires more changes in the previous 
command.

Notes:

The command in the RFC fails with:

Error creating PKCS#7 structure
140616744621440:error:21082096:PKCS7 routines:PKCS7_RECIP_INFO_set:encryption not supported for this key type:crypto/pkcs7/pk7_lib.c:487:
140616744621440:error:21073078:PKCS7 routines:PKCS7_encrypt:error adding recipient:crypto/pkcs7/pk7_smime.c:458:

A rapid glance in some online discussions seem to indicate that you cannot S/MIME encrypt with elliptic curves.

With RSA for the key, the command in the RFC works fine.

RFC 8888, "RTP Control Protocol (RTCP) Feedback for Congestion Control", January 2021

Source of RFC: avtcore (wit)

Errata ID: 7894
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Harald Tveit Alvestrand
Date Reported: 2024-04-16

Section 3.1 says:

   RTCP Congestion Control Feedback Packets SHOULD include a report
   block for every active SSRC.

It should say:

   RTCP Congestion Control Feedback Packets SHOULD include a report
   block for every SSRC where packets have been received since the
   previous report was generated.

Notes:

The term "active" is ambiguous. Discussion on the avtcore mailing list indicates that this is the intended meaning.

RFC 8898, "Third-Party Token-Based Authentication and Authorization for Session Initiation Protocol (SIP)", September 2020

Source of RFC: sipcore (art)

Errata ID: 6495
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: EungRok Lee
Date Reported: 2021-03-26

Section 1.4.2 says:

   The registrar validates the access token.  If the access token is a
   reference token, the registrar MAY perform an introspection
   [RFC7662], as in steps [4] and [5], in order to obtain more
   information about the access token and its scope, per [RFC7662].
   Otherwise, after the registrar validates the token, it inspects its
   claims and acts upon it.

It should say:

   The registrar validates the access token.  If the access token is a
   reference token, the registrar MAY perform an introspection
   [RFC7662], as in steps [3] and [4], in order to obtain more
   information about the access token and its scope, per [RFC7662].
   Otherwise, after the registrar validates the token, it inspects its
   claims and acts upon it.

Notes:

As you can see figure 2, introspection is processed in steps [3] and [4].

RFC 8907, "The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol", September 2020

Source of RFC: opsawg (ops)

Errata ID: 7754
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Joao Fracarolli
Date Reported: 2024-01-10
Edited by: Robert Wilton
Date Edited: 2024-01-12

Section 5.1, 5.3, 6.1 says:

The rem_addr_len indicates the length of the port field, in bytes.

It should say:

The rem_addr_len indicates the length of the rem_addr field, in bytes.

Notes:

Substitute "port field" with "rem_addr field". The issue exists in both 5.1 and 6.1.

In addition, in section 5.3, it should be the user_msg_len field indicating the length of the user_msg field, in bytes. The diagram should also refer to "user_msg_len" rather than "user_msg len".

RFC 8955, "Dissemination of Flow Specification Rules", December 2020

Note: This RFC has been updated by RFC 8956, RFC 9117, RFC 9184

Source of RFC: idr (rtg)

Errata ID: 7654
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: John Scudder
Date Reported: 2023-09-22

Section 4 says:

   This NLRI information is encoded using MP_REACH_NLRI and
   MP_UNREACH_NLRI attributes, as defined in [RFC4760].  When
   advertising Flow Specifications, the Length of the Next-Hop Network
   Address MUST be set to 0.  The Network Address of the Next-Hop field
   MUST be ignored.

It should say:

   This NLRI information is encoded using MP_REACH_NLRI and
   MP_UNREACH_NLRI attributes, as defined in [RFC4760].  When
   advertising Flow Specifications, the "Length of Next Hop Network 
   Address" field MUST be set to 0.  The "Network Address of Next Hop" 
   field MUST be ignored.

Notes:

The fields are named incorrectly in the original text -- they don't match the field names they're referencing in RFC 4760. Most importantly there's no hyphen in the RFC 4760 field definitions, but there are other differences too.

RFC 8959, "The "secret-token" URI Scheme", January 2021

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 6440
Status: Reported
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Mark Nottingham
Date Reported: 2021-02-24

Section 2 says:

   GET /authenticated/stuff HTTP/1.1
   Host: www.example.com
   Authorization: Bearer
     secret-token:E92FB7EB-D882-47A4-A265-A0B6135DC842%20foo

It should say:

   POST /authenticated/stuff HTTP/1.1
   Host: www.example.com
   Content-Type: application/x-www-form-urlencoded

   access_token=secret-token:E92FB7EB-D882-47A4-A265-A0B6135DC842%20foo

Notes:

RFC7235 doesn't allow the ':' character in the token68 version of credentials, so the example given isn't technically allowed by either it or RFC6750 -- although it is known to be interoperable, because no known software enforces that arbitrary restriction.

This revised example shows a way to do it that is spec-conformant.

RFC 8966, "The Babel Routing Protocol", January 2021

Source of RFC: babel (rtg)

Errata ID: 7373
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Daniel Gröber
Date Reported: 2023-02-27

Section 3.8.2.2. says:

Additionally, since metric computation does not necessarily coincide
with the delay in propagating updates, a node might receive an
unfeasible update from a currently unselected neighbour that is
preferable to the currently selected route (e.g., because it has a
much smaller metric); in that case, the node SHOULD send a unicast
seqno request to the neighbour that advertised the preferable update.

It should say:

Additionally, since metric computation does not necessarily coincide
with the delay in propagating updates, a node might receive an
unfeasible update from a currently unselected neighbour that would
lead to the received route becoming selected were it feasible. In that
case, the node SHOULD send a unicast seqno request to the neighbour
that advertised the preferable update.

Notes:

As currently written the text does not recommend sending a seqno request when no route is currently selected because ".. that is preferable to the currently selected route" implies a selected route as a precondition.

We recommend reinstating some of the RFC6126 wording instead. (Thanks to Juliusz for pointing this out)

RFC 8976, "Message Digest for DNS Zones", February 2021

Source of RFC: dnsop (ops)

Errata ID: 6425
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Brian Wellington
Date Reported: 2021-02-10

Section A.3 says:

example.      86400  IN  ZONEMD  2018031900 241 1 (
                                 e1846540e33a9e41
                                 89792d18d5d131f6
                                 05fc283e )

It should say:

<A ZONEMD record with a digest of length 48>

Notes:

2.2.3 defines Hash Algorithm 1 as SHA384, and says that "the size of the Digest field is 48 octets". There is nothing in 2.2.3 (or 2.2.2, where Scheme is defined) that indicates that Scheme and Hash Algorithm are dependent on each other, so the fact that the Scheme value (241) is private should have no effect on the digest computed by Hash Algorithm 1.

RFC 8995, "Bootstrapping Remote Secure Key Infrastructure (BRSKI)", May 2021

Source of RFC: anima (ops)

Errata ID: 6648
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Richardson
Date Reported: 2021-07-27

Section 5.1 says:

   Use of TLS 1.3 (or newer) is encouraged.  TLS 1.2 or newer is
   REQUIRED on the pledge side.  TLS 1.3 (or newer) SHOULD be available
   on the registrar server interface, and the registrar client
   interface, but TLS 1.2 MAY be used.  TLS 1.3 (or newer) SHOULD be
   available on the MASA server interface, but TLS 1.2 MAY be used.

It should say:

Use of TLS 1.3 (or newer) is encouraged.  TLS 1.2 or newer is
REQUIRED on the pledge side.  TLS 1.3 (or newer) SHOULD be available
on the registrar server interface, and the registrar client
interface, but TLS 1.2 MAY be used.  When TLS 1.3 is used the use of
Server Name Indicator (SNI, [RFC6066]) is not required, per RFC8446 
section 9.2, this specification is an application profile specification.

A pledge connects to the Registrar using only an IP address and it will 
not have any idea of a correct SNI value. 
This also implies that the Registrar interface may not be virtual \
hosted using SNI.

Notes:

Another errata says that SNI is mandatory on MASA interface, and the distinction between the two is subtle.

Errata ID: 7263
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Rufus Buschart
Date Reported: 2022-12-09

Section 5.5 says:

idevid-issuer:  The Issuer value from the pledge IDevID certificate
  is included to ensure unique interpretation of the serial-number.
  In the case of a nonceless (offline) voucher-request, an
  appropriate value needs to be configured from the same out-of-band
  source as the serial-number.

It should say:

idevid-issuer:  The Issuer value from the pledge IDevID certificate
  SHOULD BE included to ensure unique interpretation of the serial-
  number.
  In the case of a nonceless (offline) voucher-request, an
  appropriate value MUST be configured from the same out-of-band
  source as the serial-number.

Notes:

The current language is no language according to RFC 2119.

RFC 9000, "QUIC: A UDP-Based Multiplexed and Secure Transport", May 2021

Source of RFC: quic (wit)

Errata ID: 7861
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Mike Bishop
Date Reported: 2024-03-20

Section 8.1.2 says:

If a server receives a client Initial that contains an invalid Retry
token but is otherwise valid...

It should say:

If a server receives a client Initial containing a valid Retry token
that does not authenticate the peer address...

Notes:

Valid tokens MUST be a) integrity-protected (Section 8.1.4) and distinguishable as to purpose (Section 8.1.1), i.e. tokens from a Retry packet vs. tokens from NEW_TOKEN frames. To satisfy address validation, they should enable the server to verify the client's transport address. This text does not specify which form of invalidity is being discussed -- failure of integrity protection or a mismatch between the contents of the token and the client's address.

Applying this text to all "invalid" tokens which appear to be Retry tokens does not allow for the scenario where the token was generated by another server / another QUIC implementation and is in fact unreadable. Such tokens, even if they appear to be Retry tokens, are supposed to be handled by the requirements in 8.1.3, i.e. ignore the token and handle the packet as if no token were present.

This section should be scoped only to tokens which are correctly formatted and readable by the server, but whose contents are not sufficient to prove the client's transport address is valid. Otherwise, the determination that the token is a Retry token cannot be trusted.

(This discrepancy appears in a multi-CDN context, where tokens generated by one CDN will sometimes be received by a different CDN; if these tokens appear to be "invalid Retry tokens", the connection is closed when the token should simply be ignored.)

Errata ID: 7365
Status: Reported
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: yongboy
Date Reported: 2023-02-23
Edited by: Zaheduzzaman Sarker
Date Edited: 2023-03-06

Section 12.4. says:

| 0x19       | RETIRE_CONNECTION_ID | Section 19.16 | __01 |      |

It should say:

| 0x19       | RETIRE_CONNECTION_ID | Section 19.16 | ___1 |      |

Notes:

Based on the context and section 12.5 ending says:

Note that it is not possible to send the following frames in 0-RTT
packets for various reasons: ACK, CRYPTO, HANDSHAKE_DONE, NEW_TOKEN,
PATH_RESPONSE, and RETIRE_CONNECTION_ID. A server MAY treat receipt
of these frames in 0-RTT packets as a connection error of type
PROTOCOL_VIOLATION.

So, I think the RETIRE_CONNECTION_ID frame should not appear in the 0-RTT packet, only contained in the 1-RTT package.

RFC 9051, "Internet Message Access Protocol (IMAP) - Version 4rev2", August 2021

Source of RFC: extra (art)

Errata ID: 7343
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Nicholas Evans
Date Reported: 2023-02-13

Section 9 says:

resp-cond-auth  = ("OK" / "PREAUTH") SP resp-text
                    ; Authentication condition

resp-cond-bye   = "BYE" SP resp-text

resp-cond-state = ("OK" / "NO" / "BAD") SP resp-text
                    ; Status condition

...

resp-text       = ["[" resp-text-code "]" SP] [text]

It should say:

resp-cond-auth  = ("OK" / "PREAUTH") [SP resp-text]
                    ; Authentication condition
                    ;
                    ; Servers SHOULD send the trailing SP when resp-text
                    ; is empty.
                    

resp-cond-bye   = "BYE" [SP resp-text]
                    ; Servers SHOULD send the trailing SP when resp-text
                    ; is empty.

resp-cond-state = ("OK" / "NO" / "BAD") [SP resp-text]
                    ; Status condition
                    ;
                    ; Servers SHOULD send the trailing SP when resp-text
                    ; is empty.

...


resp-text       = "[" resp-text-code "]" [SP [text]] / [text]
                    ; Servers SHOULD send then trailing SP when
                    ; resp-text-code is present but text is empty.

Notes:

Appendix E, Changes from RFC 3501 / IMAP4rev1, item 23 states that "resp-text ABNF non-terminal was updated to allow for empty text."

In the spirit of Appendix E. 23, resp-text should allow "[" resp-text-code "]" without a trailing SP. Similarly, resp-cond-auth, resp-cond-bye, and resp-cond-state should also allow the trailing SP to be dropped when resp-text is empty. In all of these cases, the missing SP does not change the semantics of the response, so clients should not require it to be present. However, for compatibility with clients that strictly adhere to the formal syntax as-is, servers should conservatively send the trailing SP even when text or resp-text is empty.

This aligns with existing practice, as some existing IMAP4rev1 servers already fail to send these trailing spaces, and some liberal clients already allow them to be missing.

Errata ID: 7246
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Mechiel Lukkien
Date Reported: 2022-11-12

Section 7.5.2. says:

   BINARY[<section-binary>]<<number>>
      An <nstring> or <literal8> expressing the content of the specified
      section after removing any encoding specified in the corresponding
      Content-Transfer-Encoding header field.  If <number> is present,
      it refers to the offset within the DECODED section data.

It should say:

   BINARY[<section-binary>]
      An <nstring> or <literal8> expressing the content of the specified
      section after removing any encoding specified in the corresponding
      Content-Transfer-Encoding header field.

Notes:

While a FETCH _request_ can be "partial" with <...> for both BODY[] and BINARY[], only a FETCH _response_ for BODY[] can have an optional offset. A FETCH _response_ for BINARY[] cannot have an optional offset. At least according to the ABNF, which I believe is leading.
See lines 6756 and 6757: msg-att-static = "BODY" section ["<" number ">"] SP nstring / "BINARY" section-binary SP (nstring / literal8)
And line 6987: section-binary = "[" [section-part] "]"

RFC 3516, IMAP4 Binary Content Extension, from which the original text was probably copied, appears to have the same issue but no errata.

Errata ID: 7518
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Joó Ádám
Date Reported: 2023-05-18

Section 4.1.1. says:

   A set of messages can be referenced by a sequence set containing
   either message sequence numbers or unique identifiers.  See Section 9
   for details.  A sequence set can contain ranges of sequence numbers
   (such as "5:50"), an enumeration of specific sequence numbers, or a
   combination of the above.  A sequence set can use the special symbol
   "*" to represent the maximum sequence number in the mailbox.  A
   sequence set never contains unique identifiers.

It should say:

Why am I required to fix someone else's sloppy writing?

Notes:

The first and last sentences are in direct contradiction. Clarification is needed.

Errata ID: 7593
Status: Reported
Type: Technical
Publication Format(s) : TEXT, HTML
Reported By: Simon Ser
Date Reported: 2023-08-07

Section 6.3.10 says:

  C: A001 NAMESPACE
  S: * NAMESPACE (("" "/")("#mh/" "/" "X-PARAM"
      ("FLAG1" "FLAG2"))) NIL NIL
  S: A001 OK NAMESPACE command completed

  C: A002 LIST (SPECIAL-USE) "" "*"
  S: * LIST (\NonExistent \Archive) "/" Archives
  S: * LIST (\NonExistent \Drafts) "/" Drafts
  S: * LIST (\NonExistent \Junk) "/" Junk
  S: * LIST (\NonExistent \Sent) "/" "Sent Mail"
  S: * LIST (\NonExistent \Trash) "/" "Deleted Items"
  S: A002 OK LIST Completed

  C: A003 LIST (SPECIAL-USE) "#mh/" "*"
  S: * LIST (\NonExistent \Archive) "/" "#mh/Archives"
  S: * LIST (\NonExistent \Drafts) "/" "#mh/Drafts"
  S: * LIST (\NonExistent \Junk) "/" "#mh/Junk"
  S: * LIST (\NonExistent \Sent) "/" "#mh/Sent Mail"
  S: * LIST (\NonExistent \Trash) "/" "#mh/Deleted Items"
  S: A003 OK LIST Completed

It should say:

  C: A001 NAMESPACE
  S: * NAMESPACE (("" "/")("#mh/" "/" "X-PARAM"
      ("FLAG1" "FLAG2"))) NIL NIL
  S: A001 OK NAMESPACE command completed

  C: A002 LIST "" "*"
  S: * LIST (\NonExistent \Archive) "/" Archives
  S: * LIST (\NonExistent \Drafts) "/" Drafts
  S: * LIST (\NonExistent \Junk) "/" Junk
  S: * LIST (\NonExistent \Sent) "/" "Sent Mail"
  S: * LIST (\NonExistent \Trash) "/" "Deleted Items"
  S: A002 OK LIST Completed

  C: A003 LIST "#mh/" "*"
  S: * LIST (\NonExistent \Archive) "/" "#mh/Archives"
  S: * LIST (\NonExistent \Drafts) "/" "#mh/Drafts"
  S: * LIST (\NonExistent \Junk) "/" "#mh/Junk"
  S: * LIST (\NonExistent \Sent) "/" "#mh/Sent Mail"
  S: * LIST (\NonExistent \Trash) "/" "#mh/Deleted Items"
  S: A003 OK LIST Completed

Notes:

The SPECIAL-USE LIST option is part of the IMAP4rev1 SPECIAL-USE extension, but has not been carried over in IMAP4rev2.

RFC 9054, "CBOR Object Signing and Encryption (COSE): Hash Algorithms", August 2022

Source of RFC: cose (sec)

Errata ID: 7335
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Carsten Bormann
Date Reported: 2023-02-06

Section 2.1 says:

       1 : int / tstr, # Algorithm identifier
       2 : bstr, # Hash value
       ? 3 : tstr, # Location of object that was hashed
       ? 4 : any   # object containing other details and things

It should say:

       1 : int / tstr, ; Algorithm identifier
       2 : bstr, ; Hash value
       ? 3 : tstr, ; Location of object that was hashed
       ? 4 : any   ; object containing other details and things

Notes:

The comment character for CDDL is a ";", not a "#".

RFC 9083, "JSON Responses for the Registration Data Access Protocol (RDAP)", June 2021

Source of RFC: regext (art)

Errata ID: 7093
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Scott Hollenbeck
Date Reported: 2022-08-17

Section 4.1 says:

The data structure named "rdapConformance" is an array of strings,
each providing a hint as to the specifications used in the construction
of the response.

It should say:

The data structure named "rdapConformance" is an array of strings,
each identifying a registered specification used in the construction
of the response.

Notes:

The original text uses the word "hint", which some people have interpreted to mean "not normative" and/or "can be ignored". This misinterpretation will likely cause significant misunderstanding of the technical specification and might result in faulty implementations if not corrected. The intention and meaning of this sentence is more clearly specified with the corrected text, noting that the array of string identifiers is directly associated with the set of specifications used to construct an RDAP response.

Errata ID: 7340
Status: Reported
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Rudi Floren
Date Reported: 2023-02-07

Section Appendix F says:

   *  Noted that all members of the "events" and "Public IDs" arrays are
      REQUIRED.

It should say:

   *  Noted which members of the "events" and "Public IDs" arrays are
      REQUIRED.

Notes:

According to the "events" array, not all members are REQUIRED.

RFC 9110, "HTTP Semantics", June 2022

Source of RFC: httpbis (wit)

Errata ID: 7870
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ben Kallus
Date Reported: 2024-03-24

Section 8.6 says:

   Likewise, a sender MUST NOT forward a message with a Content-Length
   header field value that does not match the ABNF above, with one
   exception: a recipient of a Content-Length header field value
   consisting of the same decimal value repeated as a comma-separated
   list (e.g, "Content-Length: 42, 42") MAY either reject the message as
   invalid or replace that invalid field value with a single instance of
   the decimal value, since this likely indicates that a duplicate was
   generated or combined by an upstream message processor.

It should say:

   Likewise, a sender MUST NOT send a message with a Content-Length
   header field value that does not match the ABNF above. A
   recipient of a Content-Length header field value consisting of
   the same decimal value repeated as a comma-separated list (e.g,
   "Content-Length: 42, 42") MAY either reject the message as invalid
   or replace that invalid field value with a single instance of the
   decimal value, since this likely indicates that a duplicate was
   generated or combined by an upstream message processor.

Notes:

This change aims to fix 2 issues with the text:

Issue #1
Recall the following from section 8.6:
> Likewise, a sender MUST NOT forward a message with a Content-Length header field value that does not match the ABNF above, ...

It wasn't immediately clear to me which of these was the intended meaning:
1. Upon receipt of a message with an invalid Content-Length value, senders MUST NOT forward the message.
2. Upon receipt of a message with an invalid Content-Length value, senders MUST NOT forward the message with the invalid value intact.

Mark Nottingham confirmed on GitHub that the intended meaning is option 2:
https://github.com/httpwg/http-core/issues/1113#issuecomment-1937914210

I propose that the word "forward" be changed to "send" to clear up the ambiguity.

Issue #2
We've just established that the intended meaning of the first half of the sentence in question is that malformed CL header values MUST NOT be forwarded intact.
An exception to this rule is (by definition) a situation in which invalid CL header values *are* permitted to be forwarded intact.
The "exception" described in the text does not allow for invalid header values to be forwarded intact, so it is a misuse of the word "exception."

To clear this up, I propose that the sentence be split in two, and that the word "exception" be removed.

RFC 9114, "HTTP/3", June 2022

Source of RFC: quic (wit)

Errata ID: 7238
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Jaikiran Pai
Date Reported: 2022-11-04

Section 4.2.2 says:

Because this limit is applied separately by each implementation that
processes the message, messages below this limit are not guaranteed
to be accepted.

It should say:

Because this limit is applied separately by each implementation that
processes the message, messages above this limit are not guaranteed
to be accepted.

Notes:

The section 4.2.2 specifies header size constraints and notes that implementations can send a SETTINGS frame with a SETTINGS_MAX_FIELD_SECTION_SIZE identifier to set a limit on the maximum size of the message header. Since this a maximum size, the sentence that states that intermediaries aren't guaranteed to accept a message below this limit seems odd and I think it should instead say "above this limit".

Errata ID: 7702
Status: Reported
Type: Technical
Publication Format(s) : HTML
Reported By: Lucas Pardue
Date Reported: 2023-11-15

Section 10.7 says:

   Where HTTP/2 employs PADDING frames and Padding fields in other
   frames to make a connection more resistant to traffic analysis,
   HTTP/3 can either rely on transport-layer padding or employ the
   reserved frame and stream types discussed in Sections 7.2.8 and
   6.2.3.  

It should say:

   Where HTTP/2 employs Padding fields in some
   frames to make a connection more resistant to traffic analysis,
   HTTP/3 can either rely on transport-layer padding or employ the
   reserved frame and stream types discussed in Sections 7.2.8 and
   6.2.3.  

Notes:

HTTP/2 doesn't define PADDING frames

RFC 9116, "A File Format to Aid in Security Vulnerability Disclosure", April 2022

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 7264
Status: Reported
Type: Technical
Publication Format(s) : HTML
Reported By: Michael Osipov
Date Reported: 2022-12-10

Section 2.5.5 says:

Expires: 2021-12-31T18:37:07z

It should say:

Expires: 2021-12-31T18:37:07Z

Notes:

The ISO 8601 zulu indicator MUST be an upper case Z, not a lower case one.

Errata ID: 7743
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Esa Jokinen
Date Reported: 2023-12-30

Section 4 says:

   CRLF             =  CR LF
                         ; Internet standard newline

It should say:

   CRLF             =  [CR] LF
                         ; Both CRLF and LF line separators can be used
                         ; (see Section 2.2) as long as the entire file
                         ; uses the chosen line separator.

Notes:

RFC 9116 section 2.2 accepts both CRLF and LF line separators. There is a contradiction in the ABNF Grammar as it suggests only CRLF would be allowed elsewhere whereas LF is an option in "cleartext" & "eol". For consistency, the CRLF should either be mandatory or optional on the entire file, and only CRLF or LF should be used in a single file instead of mixing them.

The referenced RFC 2046 (section 4.1.1) and 5198 (section 2) have chosen the CRLF sequence as a MUST. On the other hand, the context is OpenPGP Message Format that canonicalizes the signed text documents by converting LF to CRLF before signing (RFC 4880, 5.4.2), and the receiving software should convert them to native line endings (RFC 4880, 5.9).

This report respects the intent of section 2.2 to treat line separators more liberally and recognizes that it is not an issue in the context of RFC 4880. The goal is to describe this in the ABNF Grammar with the smallest possible change, resulting in "CRLF" being locally redefined as "[CR] LF".

RFC 9126, "OAuth 2.0 Pushed Authorization Requests", September 2021

Source of RFC: oauth (sec)

Errata ID: 6711
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Brian Campbell
Date Reported: 2021-10-15

Section 3. says:

   Clients MAY use the "request" parameter as defined in JAR [RFC9101]
   to push a Request Object JWT to the authorization server.  The rules
   for processing, signing, and encryption of the Request Object as
   defined in JAR [RFC9101] apply.  Request parameters required by a
   given client authentication method are included in the "application/
   x-www-form-urlencoded" request directly and are the only parameters
   other than "request" in the form body (e.g., mutual TLS client
   authentication [RFC8705] uses the "client_id" HTTP request parameter,
   while JWT assertion-based client authentication [RFC7523] uses
   "client_assertion" and "client_assertion_type").  All other request
   parameters, i.e., those pertaining to the authorization request
   itself, MUST appear as claims of the JWT representing the
   authorization request.

It should say:

  Clients MAY use the request and client_id parameters as defined in 
  JAR [RFC9101] to push a Request Object JWT to the authorization 
  server. The rules for processing, signing, and encryption of the 
  Request Object as defined in JAR [RFC9101] apply. Request parameters
  required by a given client authentication method are included in the
  application/x-www-form-urlencoded request directly and are the only 
  parameters other than request and client_id in the form body (e.g.,
  JWT assertion-based client authentication [RFC7523] uses 
  "client_assertion" and "client_assertion_type") HTTP request
  parameters). All authorization request parameters, i.e., those 
  pertaining to the authorization request itself, MUST appear as
  claims of the JWT representing the authorization request.

Notes:

That first paragraph of Sec 3 was not properly updated to come inline with JAR (now RFC9101) when it changed in draft -21 to require "client_id" in the authorization request in addition to in addition to "request" or "request_uri" - so is somewhat ambiguous in maybe suggesting that "client_id" isn't required. But it is required based on how PAR works and RFC9101 requiring "client_id".

Errata ID: 7254
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Joseph Heenan
Date Reported: 2022-11-18

Section 1.1 says:

POST /as/par HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

&response_type=code
&client_id=CLIENT1234&state=duk681S8n00GsJpe7n9boxdzen
<...>

It should say:

POST /as/par HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

response_type=code
&client_id=CLIENT1234&state=duk681S8n00GsJpe7n9boxdzen
<...>

Notes:

In the 'Introductory Example', the POST body to the par endpoint contains an unnecessary '&' at the start. (It's perhaps technically valid, but could potentially confuse readers.)

Errata ID: 7410
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Andrii Deinega
Date Reported: 2023-03-31

Section 1.1 says:

Uses "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2" in two examples.

It should say:

Use "urn:ietf:params:oauth:request_uri:bwc4JK-ESC0w8acc191e-Y1LTC2"
instead.

Notes:

Some may find the use of "urn:example:" a bit misleading.

RFC 9132, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification", September 2021

Source of RFC: dots (sec)

Errata ID: 7058
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Jan Lindblad
Date Reported: 2022-07-29

Section 5.3 says:

              uses data-channel:target {
                when "/dots-signal/scope/conflict-information/"
                   + "conflict-cause = 'overlapping-targets'";
              }

It should say:

              uses data-channel:target {
                when "../conflict-cause = 'overlapping-targets'";
              }

Notes:

The original YANG statements make the "uses" statement apply to all "list scope" instances as soon as there is at least one "scope" instance that has "conflict-cause" set to "overlapping-targets". I suspect this is not the author's intent.

The corrected YANG statements make the "uses" statement only apply to the specific "scope" instances that have "conflict-cause" set to "overlapping-targets". There are also other ways to fix this issue.

RFC 9167, "Registry Maintenance Notification for the Extensible Provisioning Protocol (EPP)", December 2021

Source of RFC: regext (art)

Errata ID: 7176
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2022-10-21

Section 5.1 says:

xmlns="https://www.w3.org/2001/XMLSchema"

It should say:

xmlns="http://www.w3.org/2001/XMLSchema"

Notes:

XML Schema standard https://www.w3.org/TR/xmlschema-1/ "The XML representation of schema components uses a vocabulary identified by the namespace name http://www.w3.org/2001/XMLSchema. "

RFC 9171, "Bundle Protocol Version 7", January 2022

Source of RFC: dtn (int)

Errata ID: 7272
Status: Reported
Type: Technical
Publication Format(s) : TEXT, HTML
Reported By: Brian Sipos
Date Reported: 2022-12-12

Section 4.2.5.1.1 says:

dtn-hier-part = "//" node-name name-delim demux ; a path-rootless

node-name = reg-name

demux = *VCHAR

It should say:

dtn-hier-part = "//" node-name name-delim demux [ "?" query ]

node-name = reg-name

demux = path-rootless / path-empty

Notes:

The demux portion of an EID should match only URI path segments and not match query or fragment URI parts. A fragment part should not actually be sent as encoded EID to be consistent with other URI uses (e.g. HTTP). The administrative endpoint is the allowed empty demux path.

Errata ID: 7337
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Carsten Bormann
Date Reported: 2023-02-06

Section Appendix B says:

   ; Actual CBOR data embedded in a byte string, with optional tag to
   indicate so.
 
...
 
   ; Extension block type, which does not specialize other than the
   code/number

...

   payload-block = payload-block-structure .within canonical-block-
   structure

It should say:

   ; Actual CBOR data embedded in a byte string, with optional tag to
   ; indicate so.

... 
 
   ; Extension block type, which does not specialize other than the
   ; code/number

...

   payload-block = payload-block-structure .within
                   canonical-block-structure

Notes:

Various line breaking events cause syntax errors while parsing Appendix B.

RFC 9172, "Bundle Protocol Security (BPSec)", January 2022

Source of RFC: dtn (int)

Errata ID: 7672
Status: Reported
Type: Technical
Publication Format(s) : TEXT, HTML
Reported By: Brian Sipos
Date Reported: 2023-10-10

Section 3.6 says:

Security Context Id:
 This field identifies the security context used to implement
 the security service represented by this block and applied to
 each security target.  This field SHALL be represented by a
 CBOR unsigned integer.  The values for this Id should come from
 the registry defined in Section 11.3.

It should say:

Security Context Id:
 This field identifies the security context used to implement
 the security service represented by this block and applied to
 each security target.  This field SHALL be represented by a
 CBOR unsigned or negative integer.  The values for this Id should
 come from the registry defined in Section 11.3.

Notes:

Per the IANA sub-registry in Section 11.3 the Context ID has "The value range: signed 16-bit integer." and negative values are reserved for private use, so the value can be either an unsigned or a negative integer.

RFC 9173, "Default Security Contexts for Bundle Protocol Security (BPSec)", January 2022

Source of RFC: dtn (int)

Errata ID: 7002
Status: Reported
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Ed Birrane
Date Reported: 2022-06-21

Section A.4.4.1 says:

This BCB has two targets: the payload block and BIB.

It should say:

This BCB has two targets: the payload block and BIB. 

NOTE: This example implies using a single Initialization Vector (IV) for
two separate encryptions (a BIB and the payload). This violates the 
requirement in Section 4.3.1 that the "initialization vector ... MUST 
NOT be reused for multiple encryptions using the same encryption key.". 
When using the BCB-AES-GCM security context containing a specified 
Initialization Vector, each BCB should have only one security target.  

Notes:

This is listed as "editorial" and not technical because the error appears in a non-normative portion of the document.

RFC 9180, "Hybrid Public Key Encryption", February 2022

Source of RFC: IRTF

Errata ID: 7121
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Shane Lontis
Date Reported: 2022-09-07

Section Appendix A says:

A.1.1
skEm
52c4a758a802cd8b936eceea314432798d5baf2d7e9235dc084ab1b9cfa2f736
skRm
4612c550263fc8ad58375df3f557aac531d26850903e55a9f23f21d8534e8ac8

A.1.2
skEm
463426a9ffb42bb17dbe6044b9abd1d4e4d95f9041cef0e99d7824eef2b6f588
skRm
c5eb01eb457fe6c6f57577c5413b931550a162c71a03ac8d196babbd4e5ce0fd

A.1.3
skEm
ff4442ef24fbc3c1ff86375b0be1e77e88a0de1e79b30896d73411c5ff4c3518
skRm
fdea67cf831f1ca98d8e27b1f6abeb5b7745e9d35348b80fa407ff6958f9137e
skSm
dc4a146313cce60a278a5323d321f051c5707e9c45ba21a3479fecdf76fc69dd

A.1.4
skEm
14de82a5897b613616a00c39b87429df35bc2b426bcfd73febcb45e903490768
skRm
cb29a95649dc5656c2d054c1aa0d3df0493155e9d5da6d7e344ed8b6a64a9423
skSm
fc1c87d2f3832adb178b431fce2ac77c7ca2fd680f3406c77b5ecdf818b119f4

A.2.1
skEm
f4ec9b33b792c372c1d2c2063507b684ef925b8c75a42dbcbf57d63ccd381600
skRm
8057991eef8f1f1af18f4a9491d16a1ce333f695d4db8e38da75975c4478e0fb

A.2.2
skEm
0c35fdf49df7aa01cd330049332c40411ebba36e0c718ebc3edf5845795f6321
skRm
77d114e0212be51cb1d76fa99dd41cfd4d0166b08caa09074430a6c59ef17879

A.2.3
skEm
c94619e1af28971c8fa7957192b7e62a71ca2dcdde0a7cc4a8a9e741d600ab13
skRm
3ca22a6d1cda1bb9480949ec5329d3bf0b080ca4c45879c95eddb55c70b80b82
skSm
2def0cb58ffcf83d1062dd085c8aceca7f4c0c3fd05912d847b61f3e54121f05

A.2.4
skEm
5e6dd73e82b856339572b7245d3cbb073a7561c0bee52873490e305cbb710410
skRm
7b36a42822e75bf3362dfabbe474b3016236408becb83b859a6909e22803cb0c
skSm
90761c5b0a7ef0985ed66687ad708b921d9803d51637c8d1cb72d03ed0f64418

A.7.1
skEm
095182b502f1f91f63ba584c7c3ec473d617b8b4c2cec3fad5af7fa6748165ed
skRm
33d196c830a12f9ac65d6e565a590d80f04ee9b19c83c87f2c170d972a812848

A.7.2
skEm
1d72396121a6a826549776ef1a9d2f3a2907fc6a38902fa4e401afdb0392e627
skRm
98f304d4ecb312689690b113973c61ffe0aa7c13f2fbe365e48f3ed09e5a6a0c

A.7.3
skEm
83d3f217071bbf600ba6f081f6e4005d27b97c8001f55cb5ff6ea3bbea1d9295
skRm
ed88cda0e91ca5da64b6ad7fc34a10f096fa92f0b9ceff9d2c55124304ed8b4a
skSm
c85f136e06d72d28314f0e34b10aadc8d297e9d71d45a5662c2b7c3b9f9f9405

A.7.4
skEm
a2b43f5c67d0d560ee04de0122c765ea5165e328410844db97f74595761bbb81
skRm
c4962a7f97d773a47bdf40db4b01dc6a56797c9e0deaab45f4ea3aa9b1d72904
skSm
6175b2830c5743dff5b7568a7e20edb1fe477fb0487ca21d6433365be90234d0

It should say:

A.1.1
skEm
50c4a758a802cd8b936eceea314432798d5baf2d7e9235dc084ab1b9cfa2f776
skRm
4012c550263fc8ad58375df3f557aac531d26850903e55a9f23f21d8534e8a48

A.1.2
skEm
403426a9ffb42bb17dbe6044b9abd1d4e4d95f9041cef0e99d7824eef2b6f548
skRm
c0eb01eb457fe6c6f57577c5413b931550a162c71a03ac8d196babbd4e5ce07d

A.1.3
skEm
f84442ef24fbc3c1ff86375b0be1e77e88a0de1e79b30896d73411c5ff4c3558
skRm
f8ea67cf831f1ca98d8e27b1f6abeb5b7745e9d35348b80fa407ff6958f9137e
skSm
d84a146313cce60a278a5323d321f051c5707e9c45ba21a3479fecdf76fc695d

A.1.4
skEm
10de82a5897b613616a00c39b87429df35bc2b426bcfd73febcb45e903490768
skRm
c829a95649dc5656c2d054c1aa0d3df0493155e9d5da6d7e344ed8b6a64a9463
skSm
f81c87d2f3832adb178b431fce2ac77c7ca2fd680f3406c77b5ecdf818b11974

A.2.1
skEm
f0ec9b33b792c372c1d2c2063507b684ef925b8c75a42dbcbf57d63ccd381640
skRm
8057991eef8f1f1af18f4a9491d16a1ce333f695d4db8e38da75975c4478e07b

A.2.2
skEm
0835fdf49df7aa01cd330049332c40411ebba36e0c718ebc3edf5845795f6361
skRm
70d114e0212be51cb1d76fa99dd41cfd4d0166b08caa09074430a6c59ef17879

A.2.3
skEm
c84619e1af28971c8fa7957192b7e62a71ca2dcdde0a7cc4a8a9e741d600ab53
skRm
38a22a6d1cda1bb9480949ec5329d3bf0b080ca4c45879c95eddb55c70b80b42
skSm
28ef0cb58ffcf83d1062dd085c8aceca7f4c0c3fd05912d847b61f3e54121f45

A.2.4
skEm
586dd73e82b856339572b7245d3cbb073a7561c0bee52873490e305cbb710450
skRm
7836a42822e75bf3362dfabbe474b3016236408becb83b859a6909e22803cb4c
skSm
90761c5b0a7ef0985ed66687ad708b921d9803d51637c8d1cb72d03ed0f64458

A.7.1
skEm
085182b502f1f91f63ba584c7c3ec473d617b8b4c2cec3fad5af7fa67481656d
skRm
30d196c830a12f9ac65d6e565a590d80f04ee9b19c83c87f2c170d972a812848

A.7.2
skEm
1872396121a6a826549776ef1a9d2f3a2907fc6a38902fa4e401afdb0392e667
skRm
98f304d4ecb312689690b113973c61ffe0aa7c13f2fbe365e48f3ed09e5a6a4c

A.7.3
skEm
80d3f217071bbf600ba6f081f6e4005d27b97c8001f55cb5ff6ea3bbea1d9255
skRm
e888cda0e91ca5da64b6ad7fc34a10f096fa92f0b9ceff9d2c55124304ed8b4a
skSm
c85f136e06d72d28314f0e34b10aadc8d297e9d71d45a5662c2b7c3b9f9f9445

A.7.4
skEm
a0b43f5c67d0d560ee04de0122c765ea5165e328410844db97f74595761bbb41
skRm
c0962a7f97d773a47bdf40db4b01dc6a56797c9e0deaab45f4ea3aa9b1d72944
skSm
6075b2830c5743dff5b7568a7e20edb1fe477fb0487ca21d6433365be9023450

Notes:

The introduction section in Appendix A states that
'Each key pair (skX, pkX) is written in its serialized form, where skXm = SerializePrivateKey(skX) '

For X25519 entries this means that values for skXm should be clamped in the following way to modify the first and last bytes:

skXm[0] &= 248;
skXm[skXmlen - 1] &= 127;
skXm[skXmlen - 1] |= 64;

(See Section 5 of https://www.ietf.org/rfc/rfc7748.txt)

Errata ID: 7251
Status: Reported
Type: Technical
Publication Format(s) : HTML
Reported By: Stephen Farrell
Date Reported: 2022-11-15

Section 7.2.1 says:

The RECOMMENDED limit for these values is 64 bytes. 

It should say:

The RECOMMENDED limit for these values is 66 bytes. (To enable
processing of all the test vectors in Appendix A.)

Notes:

Appendix A.6.1 and others have test vectors with an IKM that is 66 octets long. Seems easier to bump the recommended value by 2, rather than invalidate the test vectors, but the latter could also be done if/when 9180 is revised. Meanwhile, no harm for implementers to know this.

Errata ID: 7790
Status: Reported
Type: Technical
Publication Format(s) : TEXT, HTML
Reported By: Neil Madden
Date Reported: 2024-01-30

Section 9.1.2 says:

   A detailed computational analysis of HPKE's Auth mode single-shot
   encryption API has been done in [ABHKLR20].  The paper defines
   security notions for authenticated KEMs and for authenticated public
   key encryption, using the outsider and insider security terminology
   known from signcryption [SigncryptionDZ10].  The analysis proves that
   DHKEM's AuthEncap()/AuthDecap() interface fulfills these notions for
   all Diffie-Hellman groups specified in this document. 

It should say:

   A detailed computational analysis of HPKE's Auth mode single-shot
   encryption API has been done in [ABHKLR20].  The paper defines
   security notions for authenticated KEMs and for authenticated public
   key encryption, using the outsider and insider security terminology
   known from signcryption [SigncryptionDZ10].  The analysis proves that
   DHKEM's AuthEncap()/AuthDecap() interface fulfills the notions of 
   Outsider-CCA, Insider-CCA, and Outsider-Auth for all Diffie-Hellman 
   groups specified in this document. It does not fulfill the notion of
   Insider-Auth defined in the paper.

Notes:

The referenced paper defines four notions of security, Outsider-CCA, Insider-CCA, Outsider-Auth, and Insider-Auth. It proves that HPKE meets the first three, but, contrary to the current text of the RFC, it proves that it does *not* meet Insider-Auth security and that this is infeasible for HPKE. This is an important negative security result that should have been highlighted in the RFC.

RFC 9190, "EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3", February 2022

Source of RFC: emu (sec)

Errata ID: 7577
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Alan DeKok
Date Reported: 2023-07-29

Section 2.5 says:

   When an EAP-TLS server has successfully processed the TLS client
   Finished and sent its last handshake message (Finished or a post-
   handshake message), it sends an encrypted TLS record with application
   data 0x00.  The encrypted TLS record with application data 0x00 is a
   protected success result indication, as defined in [RFC3748] ...

It should say:

(append)

If the EAP-TLS peer does not see the protected success indication, it
MUST behave as if it had received an EAP Failure instead.

Notes:

This is largely a nit, but it's reasonable to say this.

The existing text discussed what the server must do, But it does not say what the
peer does if the server fails to behave this way,

RFC 9230, "Oblivious DNS over HTTPS", June 2022

Source of RFC: INDEPENDENT

Errata ID: 7142
Status: Reported
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Marwan Fayed
Date Reported: 2022-09-30
Edited by: Eliot Lear (ISE)
Date Edited: 2022-09-30

Section Acknowledgements says:

Paul Schmitt, Brian Swander, 

It should say:

Paul Schmitt, Sudheesh Singanamalla, Brian Swander, 

Notes:

Unintentional omission from list of acknowledgements.

RFC 9250, "DNS over Dedicated QUIC Connections", May 2022

Source of RFC: dprive (int)

Errata ID: 7883
Status: Reported
Type: Technical
Publication Format(s) : TEXT, HTML
Reported By: Lyra Naeseth
Date Reported: 2024-04-05

Section 7.5 says:

Implementations SHOULD use the mechanisms defined in Section 5.4 to
mitigate this attack.

It should say:

Implementations MUST use the padding mechanisms defined in Section 5.4
to mitigate this attack.

Notes:

Section 5.4 states that "[i]mplementations MUST protect against the traffic analysis attacks described in Section 7.5", but Section 7.5 describes that obligation as a "SHOULD". "MUST" is correct, and the inconsistent "SHOULD" in Section 7.5 is an error.

RFC 9252, "BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)", July 2022

Source of RFC: bess (rtg)

Errata ID: 7652
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ketan Talaulikar
Date Reported: 2023-09-22

Section 3.2.1 says:

   Transposition Offset indicates the bit position, and Transposition
   Length indicates the number of bits that are being taken out of the
   SRv6 SID value and encoded in the MPLS Label field.  The bits that
   have been shifted out MUST be set to 0 in the SID value.

It should say:

   Transposition Offset indicates the bit position and Transposition
   Length indicates the number of bits that are being taken out of the
   SRv6 SID value and put into high order bits of MPLS label field. The
   bits that have been shifted out MUST be set to 0 in the SID value.

Notes:

This errata reverses an editorial change that was made during the AUTH48 phase and restores the text that came from the WG and IESG review. Refer https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-15#page-10

This change was made during the AUTH48 since the "high order bits" was already covered under various subsections of Sec 6. However, readers have reported that there are other places in Sec 6 and Sec 5 where transposition also occurs and that the original text was still required.

Errata ID: 7817
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ketan Talaulikar
Date Reported: 2024-02-20

Section 3.2.1 says:

   As defined in [RFC8986], the sum of the Locator Block Length (LBL),
   Locator Node Length (LNL), Function Length (FL), and Argument Length
   (AL) fields MUST be less than or equal to 128 and greater than the
   sum of Transposition Offset and Transposition Length.

It should say:

   As defined in [RFC8986], the sum of the Locator Block Length (LBL),
   Locator Node Length (LNL), Function Length (FL), and Argument Length
   (AL) fields MUST be less than or equal to 128 and greater than or
   equal to the sum of Transposition Offset and Transposition Length.

Notes:

The sum of Trans Off and Trans Length can be equal to the LBL+LNL+FL+AL when the last part of the SID (function or argument) is getting transposed.

This is clear also from the example below in the next paragraph of the same section:

As an example, consider that the sum of the Locator Block and the
Locator Node parts is 64. For an SRv6 SID where the entire Function
part of size 16 bits is transposed, the transposition offset is set
to 64 and the transposition length is set to 16. While for an SRv6
SID for which the FL is 24 bits and only the lower order 20 bits are
transposed (e.g., due to the limit of the MPLS Label field size), the
transposition offset is set to 68 and the transposition length is set
to 20.

RFC 9257, "Guidance for External Pre-Shared Key (PSK) Usage in TLS", July 2022

Source of RFC: tls (sec)

Errata ID: 7643
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Heikki Vatiainen
Date Reported: 2023-09-17

Section 6.1. Stack Interface says:

   *  OpenSSL and BoringSSL: Applications can specify support for
      external PSKs via distinct ciphersuites in TLS 1.2 and below.
      Also, they can then configure callbacks that are invoked for PSK
      selection during the handshake.  These callbacks must provide a
      PSK identity and key.  The exact format of the callback depends on
      the negotiated TLS protocol version, with new callback functions
      added specifically to OpenSSL for TLS 1.3 [RFC8446] PSK support.
      The PSK length is validated to be between 1-256 bytes (inclusive).
      The PSK identity may be up to 128 bytes long.

It should say:

   *  OpenSSL and BoringSSL: Applications can specify support for
      external PSKs via distinct ciphersuites in TLS 1.2 and below.
      Also, they can then configure callbacks that are invoked for PSK
      selection during the handshake.  These callbacks must provide a
      PSK identity and key.  The exact format of the callback depends on
      the negotiated TLS protocol version, with new callback functions
      added specifically to OpenSSL for TLS 1.3 [RFC8446] PSK support.
      The PSK length is validated to be between 1-256 bytes (inclusive).
      The PSK identity may be up to 128 bytes long. OpenSSL 3.0
      increased PSK maximum length to 512 bytes and PSK identity maximum
      length to 256 bytes to match existing implementations and
      specifications.

Notes:

OpenSSL PSK length and PSK identity length were increased to 256 and 512 octets, respectively, for OpenSSL 3.0. There appear to be implementations and specifications that require these longer lengths. See here for more information:
https://github.com/openssl/openssl/pull/12777
https://github.com/openssl/openssl/pull/12771

RFC 9260, "Stream Control Transmission Protocol", June 2022

Source of RFC: tsvwg (wit)

Errata ID: 7852
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Tüxen
Date Reported: 2024-03-15

Section 8.5 says:

When receiving an SCTP packet, the endpoint MUST ensure that the
value in the Verification Tag field of the received SCTP packet
matches its own tag.

It should say:

When receiving an SCTP packet, the endpoint MUST first ensure that the
value in the Verification Tag field of the received SCTP packet
matches its own tag before processing any chunks or changing its state.

Notes:

State explicitly that the check of the verification tag needs to be done before any processing of the packet.

Thanks to Jake Ginesin, Max von Hippel, and Cristina Nita-Rotaru for reporting issue and discussing it with me.

RFC 9286, "Manifests for the Resource Public Key Infrastructure (RPKI)", June 2022

Source of RFC: sidrops (ops)

Errata ID: 7243
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Ties de Kock
Date Reported: 2022-11-07

Section 4.2.1. Manifest says:

   thisUpdate:
      This field contains the time when the manifest was created.  This
      field has the same format constraints as specified in [RFC5280]
      for the CRL field of the same name.  The issuer MUST ensure that
      the value of this field is more recent than any previously
      generated manifest.  Each RP MUST verify that this field value is
      greater (more recent) than the most recent manifest it has
      validated.  If this field in a purported "new" manifest is smaller
      (less recent) than previously validated manifests, the RP SHOULD
      use locally cached versions of objects, as described in
      Section 6.6.

It should say:

    thisUpdate:
      This field contains the time when the manifest was created. This
      field has the same format constraints as specified in [RFC5280]
      for the CRL field of the same name. The issuer MUST ensure that
      the value of this field is equal to the current time and higher or
      equal to the thisUpdate of any previously generated manifest. Each
      RP MUST verify that this field value is greater or equal to (as,
      or more recent) than the most recent manifest it has validated.
      Suppose this field in a purported "new" manifest is smaller (less
      recent) than previously validated manifests. In that case, the RP
      SHOULD use locally cached versions of objects, as described in
      Section 6.6.

Notes:

First of all: The previous text was not explicit that thisUpdate MUST contain the current time.

Second, in practice (e.g. multiple calls to a synchronous API) multiple manifests can be issued with the same thisUpdate. Under the previous text this would technically be misissuance. The propose text allows multiple manifests to be issued in the same second.

RFC 9291, "A YANG Network Data Model for Layer 2 VPNs", September 2022

Source of RFC: opsawg (ops)

Errata ID: 7143
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2022-10-03

Section 4 says:

   Figure 1 illustrates how the L2NM is used.  As a reminder, this
   figure is an expansion of the architecture presented in Section 3 of
   [RFC8466] and decomposes the box marked "orchestration" in that
   figure into three separate functional components called "Service
   Orchestration", "Network Orchestration", and "Domain Orchestration".

It should say:

   Figure 1 illustrates how the L2NM is used.  As a reminder, this
   figure is an expansion of the architecture presented in Section 4 of
   [RFC8466] and decomposes the box marked "orchestration" in that
   figure into three separate functional components called "Service
   Orchestration", "Network Orchestration", and "Domain Orchestration".

Notes:

Wrong reference to Section 3 [RFC8466] (must be Section 4).

RFC 9309, "Robots Exclusion Protocol", September 2022

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 7124
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Samuel K. Lam
Date Reported: 2022-09-10

Section 5.2 says:

In the following case,
/example/page/disallowed.gif MUST be used for the URI
example.com/example/page/disallow.gif.

It should say:

In the following case,
/example/page/disallowed.gif MUST be used for the URI
example.com/example/page/disallowed.gif.

Notes:

The two file names in that sentence ("disallowed.gif" and "disallow.gif")
doesn't match. i.e. "ed" is missing from the second file name.

This error renders the example given in section 5.2 incorrect.

Errata ID: 7128
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yoshiro Yoneya
Date Reported: 2022-09-13

Section 2.2.2. says:

   For example:

   +==================+=======================+=======================+
   | Path             | Encoded Path          | Path to Match         |
   +==================+=======================+=======================+
   | /foo/bar?baz=quz | /foo/bar?baz=quz      | /foo/bar?baz=quz      |
   +------------------+-----------------------+-----------------------+
   | /foo/bar?baz=    | /foo/bar?baz=         | /foo/bar?baz=         |
   | https://foo.bar  | https%3A%2F%2Ffoo.bar | https%3A%2F%2Ffoo.bar |
   +------------------+-----------------------+-----------------------+
   | /foo/bar/        | /foo/bar/%E3%83%84    | /foo/bar/%E3%83%84    |
   | U+E38384         |                       |                       |
   +------------------+-----------------------+-----------------------+
   | /foo/            | /foo/bar/%E3%83%84    | /foo/bar/%E3%83%84    |
   | bar/%E3%83%84    |                       |                       |
   +------------------+-----------------------+-----------------------+
   | /foo/            | /foo/bar/%62%61%7A    | /foo/bar/baz          |
   | bar/%62%61%7A    |                       |                       |
   +------------------+-----------------------+-----------------------+

It should say:

   For example:

   +==================+=======================+=======================+
   | Path             | Encoded Path          | Path to Match         |
   +==================+=======================+=======================+
   | /foo/bar?baz=quz | /foo/bar?baz=quz      | /foo/bar?baz=quz      |
   +------------------+-----------------------+-----------------------+
   | /foo/bar?baz=    | /foo/bar?baz=         | /foo/bar?baz=         |
   | https://foo.bar  | https%3A%2F%2Ffoo.bar | https%3A%2F%2Ffoo.bar |
   +------------------+-----------------------+-----------------------+
   | /foo/bar/        | /foo/bar/%E3%83%84    | /foo/bar/%E3%83%84    |
   | U+30C4           |                       |                       |
   +------------------+-----------------------+-----------------------+
   | /foo/            | /foo/bar/%E3%83%84    | /foo/bar/%E3%83%84    |
   | bar/%E3%83%84    |                       |                       |
   +------------------+-----------------------+-----------------------+
   | /foo/            | /foo/bar/%62%61%7A    | /foo/bar/baz          |
   | bar/%62%61%7A    |                       |                       |
   +------------------+-----------------------+-----------------------+

Notes:

The "Path" component of third example seems to indicate Unicode codepoint, rather than UTF-8 encoded hexadecimal. If it was, the correct codepoint for %E3%83%84 is U+30C4, or ツ (in Unicode form).

RFC 9321, "Signature Validation Token", October 2022

Source of RFC: INDEPENDENT

Errata ID: 7299
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stefan Santesson
Date Reported: 2023-01-04

Throughout the document, when it says:

In section A.3.3.

   The SVT Signature object MUST contain one instance of the "sig_data"
   claim (SignedData object) for each <ds:Reference> element in the
   <ds:SignedInfo> element.  The "sig_data" claim MUST contain the
   following elements:

In Sections B.2.3. and C.2.3.

   The SVT Signature object MUST contain one instance of the "sig_data"
   claim (SignedData object) with the following elements:

It should say:

In section A.3.3.

   The SVT Signature object MUST contain one instance of the
   "sig_data_ref" claim (SignedDataReference object) for each
   <ds:Reference> element in the <ds:SignedInfo> element.  The
   "sig_data_ref" claim MUST contain the following elements:

In Sections B.2.3. and C.2.3.

   The SVT Signature object MUST contain one instance of the
   "sig_data_ref" claim (SignedDataReference object) with the following
   elements:

Notes:

The SignedDataReference Claims Object Class defined in section 3.2.6. has been incorrectly referenced in the appendices of the document

As defined in section 3.2.6. the class name of the object is "SignedDataReference" and the claims name is "sig_data_ref".

RFC 9334, "Remote ATtestation procedureS (RATS) Architecture", January 2023

Source of RFC: rats (sec)

Errata ID: 7314
Status: Reported
Type: Technical
Publication Format(s) : PDF
Reported By: Muhammad Usama Sardar
Date Reported: 2023-01-20

Throughout the document, when it says:

Several. Please see notes 

It should say:

Several. Please see notes 

Notes:

There are various ambiguities in the RATS architecture. The text is not always clear about whether the discussion is about an entity or a role. For instance, in the example in §7.1, ``A'' and ``B'' are mentioned as Relying Party and Verifier, respectively, whereas these should be entities. Based on §7.1, as the Relying Party may need to have a built-in verifier for Verifier as well as Relying Party Owner, it is no longer a simple Relying Party role.

Some of the terms are not well-defined in the standard. For instance, \textit{environment} (§3.1) is neither defined nor referenced. Specifically, it is not compared and contrasted with \textit{entity} (§3) and \textit{sub-entity} (§3.3) as well as Claims. Similarly, the statement ``The Attester role is assigned to entities that create Evidence that is conveyed to a Verifier.'' (cf. §3) applies equally well to the Attesting Environment, so there is a need to compare and contrast Attester with Attesting Environment. Similarly, Reference Values are not precisely compared and contrasted with Endorsements.

The solutions presented in the standard are not always complete and precise. For example, in §11, if the Verifier's own Attestation Results are generated by the Verifier's Verifier, it leads to recursive problems. Similarly, the event defined in Table 1 as ``A Relying Party relays an Attestation Result to a Relying Party'' and represented as ``RR'' does not make sense in §A.2, where it is actually the Attester (not Relying Party) that relays the Attestation Result to the Relying Party in the Passport model. Moreover, some of the presented solutions do not precisely describe the \textit{clock}, for instance, in Appendix §A.2. In the context of CC, none of the commercially available TEEs currently provide a trusted clock, and thus the distinction with monotonically increasing counter should be explicit. Sometimes, no solution is presented at all, e.g., recursive problems mentioned in §12.1.2.1.

RFC 9338, "CBOR Object Signing and Encryption (COSE): Countersignatures", December 2022

Source of RFC: cose (sec)

Errata ID: 7338
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Carsten Bormann
Date Reported: 2023-02-06

Section 3.3 says:

           context : "CounterSignature" / "CounterSignature0" /
                     "CounterSignatureV2" / "CounterSignature0V2" /,

It should say:

           context : "CounterSignature" / "CounterSignature0" /
                     "CounterSignatureV2" / "CounterSignature0V2",

Notes:

A spurious slash (choice operator) causes a parsing error and needs to be removed before using the CDDL.

RFC 9458, "Oblivious HTTP", January 2024

Source of RFC: ohai (sec)

Errata ID: 7781
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Dan Gould
Date Reported: 2024-01-25

Appendix A says:

   The AEAD Seal() function is then used to encrypt the response, which
   is added to the randomized nonce value to produce the Encapsulated
   Response:

   c789e7151fcba46158ca84b04464910d86f9013e404feea014e7be4a441f234f
   857fbd

   The Oblivious Gateway Resource constructs a response with the same
   content:

   HTTP/1.1 200 OK
   Date: Wed, 27 Jan 2021 04:45:07 GMT
   Cache-Control: private, no-store
   Content-Type: message/ohttp-res
   Content-Length: 38

   <content is the Encapsulated Response>

It should say:

   The AEAD Seal() function is then used to encrypt the response, which
   is added to the randomized nonce value to produce the Encapsulated
   Response:

   c789e7151fcba46158ca84b04464910d86f9013e404feea014e7be4a441f234f
   857fbd

   The Oblivious Gateway Resource constructs a response with the same
   content:

   HTTP/1.1 200 OK
   Date: Wed, 27 Jan 2021 04:45:07 GMT
   Cache-Control: private, no-store
   Content-Type: message/ohttp-res
   Content-Length: 35

   <content is the Encapsulated Response>

Notes:

The Content-Length header in the example response is set to 38 while the given Encapsulated Response (c789e7151fcba46158ca84b04464910d86f9013e404feea014e7be4a441f234f
857fbd) has a length of 35

RFC 9483, "Lightweight Certificate Management Protocol (CMP) Profile", November 2023

Source of RFC: lamps (sec)

Errata ID: 7833
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: David von Oheimb
Date Reported: 2024-03-01

Section 4.1.6 says:

-- MUST be 0 for recipientInfo type PasswordRecipientInfo

It should say:

-- MUST be 3 for recipientInfo type PasswordRecipientInfo

Notes:

It turns out that we make a mistake interpreting CMS RFC 5652 section 6.1 (https://datatracker.ietf.org/doc/html/rfc5652#section-6.1).

AFAICS, this was due to a misleadingly formatted condition in that section:

IF ((originatorInfo is present) AND
___(any version 2 attribute certificates are present)) OR
___(any RecipientInfo structures include pwri) OR
___(any RecipientInfo structures include ori)
THEN version is 3

where for clarity the indentation of the 2nd line should be one more character to the right:

IF ((originatorInfo is present) AND
____(any version 2 attribute certificates are present)) OR
___(any RecipientInfo structures include pwri) OR
___(any RecipientInfo structures include ori)
THEN version is 3

(I replaced leading space chars by '_' to make sure the indentation comes across.)

So this can also be seen as an editorial erratum of RFC 5652.

RFC 9520, "Negative Caching of DNS Resolution Failures", December 2023

Source of RFC: dnsop (ops)

Errata ID: 7838
Status: Reported
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Xiang Li
Date Reported: 2024-03-06

Section 7.2 says:

[TuDoor]
...
DOI 10.1109/SP54263.2024.00046, 2024, 
<https://doi.ieeecomputersociety.org/10.1109/SP54263.2024.00046>.

It should say:

[TuDoor]
...
DOI 10.1109/SP54263.2024.00172, 2024, 
<https://doi.ieeecomputersociety.org/10.1109/SP54263.2024.00172>.

Notes:

The reference link has changed to 10.1109/SP54263.2024.00172 from 10.1109/SP54263.2024.00046

RFC 9564, "Faster Than Light Speed Protocol (FLIP)", April 2024

Source of RFC: INDEPENDENT

Errata ID: 7877
Status: Reported
Type: Technical
Publication Format(s) : HTML
Reported By: Brian Carpenter
Date Reported: 2024-04-01

Section 5 says:

Given that new SHA-256 hashes are not sequential but fully random,
replay attacks of future predictions are prevented.

It should say:

Given that new SHA-256 hashes are not sequential but significantly
hard to predict, replay attacks of future predictions are prevented
unless the attacker has sufficient computing power to fully model all
possible pseudo-random number generators and thereby predict all
possible hashes within a sufficiently short time.

Notes:

Thank you for citing RFC6709. However, I have shown** that the concept of randomness is a fallacy - in fact, what we call "randomness" is nothing other than unpredictability by a Turing machine within a finite time. An LLM is subject to this same constraint like any other Turing machine program. I suspect that this observation shows that FLIP is a flop.

** https://www.cs.auckland.ac.nz/research/groups/CDMTCS/researchreports/view-publication.php?selected-id=835

Status: Held for Document Update (2178)

RFC 2, "Host software", April 1969

Source of RFC: Legacy

Errata ID: 2061
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hsu Yun-Che
Date Reported: 2010-03-03
Held for Document Update by: ron bonica

Section Title says:

  [unknown title]

[page 1 missing]

It should say:

   HOST SOFTWARE

[page 1 missing]

Notes:

RFC0002 was actually titled "HOST SOFTWARE".
This missing historical information is provided by RFC0003.
Source: http://tools.ietf.org/html/rfc3
---------------------------------

RFC-3 "DOCUMENTATION CONVENTIONS"
Section: "OTHER NOTES"

Quote:
"Two notes (1 & 2) have been written so far. These are both titled HOST Software and are by Steve Crocker and Bill Duvall, separately."

RFC 20, "ASCII format for network interchange", October 1969

Source of RFC: Legacy

Errata ID: 3284
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Levine
Date Reported: 2012-07-13
Held for Document Update by: Barry Leiba

Section all says:

Cert

It should say:

Cerf

Notes:

Vint Cerf's name is spelled wrong in the footer at the bottom of each page. Not having a copy of the original, I don't know whether it was an original bug or a transcription error in 1999. BUt it's definitely kind of amusing.

Errata ID: 5106
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kuba Ober
Date Reported: 2017-09-07
Held for Document Update by: Alexey Melnikov
Date Held: 2017-09-21

Section 4.1 Control says:

   FF Form Feed (FE)                       FS File Separator IS)

It should say:

   FF Form Feed (FE)                       FS File Separator (IS)

Notes:

Missing parenthesis.

Errata ID: 6087
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Daniel N. Strychalski
Date Reported: 2020-04-12
Held for Document Update by: Barry Leiba
Date Held: 2020-04-12

Section First page says:

the attached page, copies from

It should say:

the attached pages, copied from

Notes:

It seems certain that the intended meaning was "the attached pages, which were copied from" (where it is customary to omit the words "which were"). The attachment referred to consists of five sheets photocopied from USAS X3.4-1968, USA Standard Code for Information Interchange.

RFC 57, "Thoughts and Reflections on NWG/RFC 54", June 1970

Source of RFC: Legacy

Errata ID: 1781
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Matthias Bärwolff
Date Reported: 2009-05-11
Held for Document Update by: ron bonica

Section I says:

singify

It should say:

signify

Errata ID: 1782
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Matthias Bärwolff
Date Reported: 2009-05-11
Held for Document Update by: ron bonica

Section II says:

wre

It should say:

were

RFC 59, "Flow Control - Fixed Versus Demand Allocation", June 1970

Source of RFC: Legacy

Errata ID: 1784
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Matthias Bärwolff
Date Reported: 2009-05-15
Held for Document Update by: ron bonica

Throughout the document, when it says:

"cease on link" flow control scheme
proposed in RFC 35 by UCLA

It should say:

"cease on link" flow control scheme
proposed in RFC 36 by UCLA

RFC 66, "NIC - third level ideas and other noise", August 1970

Note: This RFC has been obsoleted by RFC 123

Note: This RFC has been updated by RFC 80, RFC 93

Source of RFC: Legacy

Errata ID: 1772
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Matthias Bärwolff
Date Reported: 2009-05-04
Held for Document Update by: ron bonica

Throughout the document, when it says:

On 12 August 70, I met a BBN with representatives from BBN and MIT and
we discussed third llevel protocol.

It should say:

On 12 August 70, I met a BBN with representatives from BBN and MIT and
we discussed third level protocol.

RFC 86, "Proposal for a Network Standard Format for a Data Stream to Control Graphics Display", January 1971

Note: This RFC has been updated by RFC 125

Source of RFC: Legacy

Errata ID: 3212
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yi, EungJun
Date Reported: 2012-05-05
Held for Document Update by: Barry Leiba

Section page 2 says:

The imprecise specification of character size is intended to take cognizance                         
                                                                                                     
of the existance of character drawing hardware which is capable of producing                         
                                                                                                     
only one or a few character sizes.

It should say:

The imprecise specification of character size is intended to take cognizance                         
                                                                                                     
of the existence of character drawing hardware which is capable of producing                         
                                                                                                     
only one or a few character sizes.

Notes:

"existance" should be "existence"

RFC 89, "Some historic moments in networking", January 1971

Source of RFC: Legacy

Errata ID: 1814
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Matthias Bärwolff
Date Reported: 2009-07-20
Held for Document Update by: ron bonica

Section header says:

Metcalff

It should say:

Metcalfe

RFC 90, "CCN as a Network Service Center", January 1971

Source of RFC: Legacy

Errata ID: 4613
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Wang Haojian
Date Reported: 2016-02-05
Held for Document Update by: John Scudder
Date Held: 2024-01-12

Section G says:

G. SERVICE TO NETWORK
H. REFERENCES

It should say:

H. SERVICE TO NETWORK
I. REFERENCES

Notes:

There already "G. SPECIAL CONSIDERATIONS" , so "G. SERVICE TO NETWORK" should be "H. ..." and "H. REFERENCES" should be "I. ...."

RFC 542, "File Transfer Protocol", August 1973

Note: This RFC has been obsoleted by RFC 765

Note: This RFC has been updated by RFC 614, RFC 640

Source of RFC: Legacy

Errata ID: 3436
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2012-12-25
Held for Document Update by: Barry Leiba

Section Page 31 says:

         x7x  Mail Portocol results.

It should say:

         x7x  Mail Protocol results.

RFC 675, "Specification of Internet Transmission Control Program", December 1974

Note: This RFC has been obsoleted by RFC 7805

Source of RFC: Legacy

Errata ID: 5862
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mark Smith
Date Reported: 2019-09-24
Held for Document Update by: Barry Leiba
Date Held: 2019-09-24

Section 4.2.1 says:

4.2.1  INTERNETWORK PACKET FONMAT

It should say:

4.2.1  INTERNETWORK PACKET FORMAT

Notes:

Typo in the word "FONMAT" - unusual typo though, since the N key is quite a distance from the R key on a QWERTY keyboard.

----- Verifier notes -----
Almost certainly not a typo, but an OCR error from scanning in paper copies of old RFCs.

RFC 787, "Connectionless data transmission survey/tutorial", July 1981

Source of RFC: Legacy

Errata ID: 2795
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-05-02
Held for Document Update by: ron bonica

Section 1 says:

 The Reference Model was developed to serve as  a  framework  for
 the coordination of existing and future  standards  designed  to
 facilitate the interconnection of data processing systems.   The
 purpose of OSI is to enable  an  end-user  application  activity
 (called an "application  process")  located  in  a  system  that
 employs OSI procedures  and  protocols  (an  "open"  system)  to
 communicate with any other appication  process  located  in  any
 other open system.  It is not  the  intent  of  OSI  to  specify
 either the functions or the implementation  details  of  systems
 that provide the OSI capabilities.  Communication is achieved by
 mutual adherence  to  agreed-upon  (standardized)  services  and
 protocols; the only thing that an OSI entity in a given layer in
 one system needs to know about an OSI entity in the  same  layer

It should say:

 The Reference Model was developed to serve as  a  framework  for
 the coordination of existing and future  standards  designed  to
 facilitate the interconnection of data processing systems.   The
 purpose of OSI is to enable  an  end-user  application  activity
 (called an "application  process")  located  in  a  system  that
 employs OSI procedures  and  protocols  (an  "open"  system)  to
 communicate with any other application process  located  in  any
 other open system.  It is not  the  intent  of  OSI  to  specify
 either the functions or the implementation  details  of  systems
 that provide the OSI capabilities.  Communication is achieved by
 mutual adherence  to  agreed-upon  (standardized)  services  and
 protocols; the only thing that an OSI entity in a given layer in
 one system needs to know about an OSI entity in the  same  layer

Notes:

Typo in "application": s/appication/application

RFC 791, "Internet Protocol", September 1981

Note: This RFC has been updated by RFC 1349, RFC 2474, RFC 6864

Source of RFC: Legacy
Area Assignment: int

Errata ID: 4752
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Markus Klemm
Date Reported: 2016-07-29
Held for Document Update by: Terry Manderson
Date Held: 2017-03-01

Section 3.1. says:

The Option Length is the number of octets 
in the option counting the type, length, 
pointer, and overflow/flag octets (maximum length 40).

It should say:

The Option Length is the number of octets 
in the option counting the type, length, 
pointer, overflow/flag octets 
and timestamp area (maximum length 40).

Notes:

The original version implies that the length is only the sum of the constant fields, in this case, 4. This is in conflict with
A) All prior statements that the length is variable
B) The pointer with it >=5 constraint, implies the timestamp area is always full, which is the case when pointer > length
C) Any need to know how much timestamps will follow

Errata ID: 578
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yin Shuming
Date Reported: 2006-02-18
Held for Document Update by: ron bonica

Section 3.2 says:

Note that this is consistent with the the datagram total length field (of 
course, the header is counted in the total length and not in the 
fragments).

It should say:

Note that this is consistent with the datagram total length field (of 
course, the header is counted in the total length and not in the 
fragments).

Errata ID: 2295
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vishwas Manral
Date Reported: 2010-06-03
Held for Document Update by: ron bonica

Section Page 27 says:

For example, one could implement
a fragmentation procedure that repeatly divided large datagrams in
half until the resulting fragments were less than the maximum
transmission unit size.

It should say:

For example, one could implement
a fragmentation procedure that repeatedly divided large datagrams in
half until the resulting fragments were less than the maximum
transmission unit size.

Notes:

s/ repeatly/repeatedly/

Errata ID: 2294
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vishwas Manral
Date Reported: 2010-06-03
Held for Document Update by: ron bonica

Section Page 21 says:

If it is, it inserts its
own internet address as known in the environment into which this
datagram is being forwarded into the recorded route begining at
the octet indicated by the pointer, and increments the pointer
by four.

It should say:

If it is, it inserts its
own internet address as known in the environment into which this
datagram is being forwarded into the recorded route beginning at
the octet indicated by the pointer, and increments the pointer
by four.

Notes:

s/begining/beginning/g

Errata ID: 2519
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yaakov (J) Stein
Date Reported: 2010-09-14
Held for Document Update by: ron bonica

Section 3.1 says:

Total Length is the length of the datagram, measured in octets,
including internet header and data.  

It should say:

Total Length is the length of the datagram or fragment, measured in octets,
including internet header and data.  

Notes:

Section 2.3 makes it clear that during fragmentation the total length field is corrected to the length of the fragment. Wording such as "break a datagram into an almost arbitrary number of pieces" implies that "datagram" means the entire original packet. Thus, without the proposed correction, one may be led to believe that the total length contains the length of the original datagram.

Errata ID: 3074
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: ChengYan Wang
Date Reported: 2012-01-04
Held for Document Update by: Brian Haberman

Section 3.1 Page 12 says:

Bits   5:  0 = Normal Relibility, 1 = High Relibility.

It should say:

Bits   5:  0 = Normal Reliability, 1 = High Reliability.

Notes:

Spelling error.

Errata ID: 4126
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Federico do Pino
Date Reported: 2014-10-04
Held for Document Update by: Brian Haberman
Date Held: 2014-10-21

Section 2.3 says:

    If internet datagram marked don't fragment cannot be
    delivered to its destination without fragmenting it, it is to be
    discarded instead.

It should say:

    If an internet datagram marked don't fragment cannot be
    delivered to its destination without fragmenting it, it is to be
    discarded instead.

Notes:

Grammar mistake.

Errata ID: 5679
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Greg Skinner
Date Reported: 2019-03-30
Held for Document Update by: Benjamin Kaduk
Date Held: 2019-04-03

Section 3.1 says:

The time is measured in units of seconds, but since every module that
processes a datagram must decrease the TTL by at least one even if it
process the datagram in less than a second, the TTL must be thought of
only as an upper bound on the time a datagram may exist.

It should say:

The time is measured in units of seconds, but since every module that
processes a datagram must decrease the TTL by at least one even if it
processes the datagram in less than a second, the TTL must be thought
of only as an upper bound on the time a datagram may exist.

Notes:

Grammar mistake (s/process/processes)

RFC 792, "Internet Control Message Protocol", September 1981

Note: This RFC has been updated by RFC 950, RFC 4884, RFC 6633, RFC 6918

Source of RFC: Legacy
Area Assignment: int

Errata ID: 1231
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2008-01-04
Held for Document Update by: ron bonica

In the Introduction, it says:

no ICMP messages are sent about ICMP messages

It should say:

no ICMP messages are sent about ICMP error messages

Notes:

For instance, echo replies are sent about echo messages. The context of the original sentence indicates that the author only referred to error messages but the sentence itself is not clear and I've seen the editorial error reproduced in some places.

Errata ID: 1703
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2009-03-02
Held for Document Update by: ron bonica

On page 14, it says:

   IP Fields:

   Type

      8 for echo message;

It should say:

   ICMP Fields:

   Type

      8 for echo message;

Errata ID: 2935
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jeffrey Connell
Date Reported: 2011-08-13
Held for Document Update by: ron bonica

On page 17, it says:

The identifier and sequence number may be used by the echo sender
to aid in matching the replies with the requests.

It should say:

The identifier and sequence number may be used by the timestamp sender 
to aid in matching the replies with the requests.

Notes:

In the "Description" of the "Timestamp or Timestamp Reply" message. Appears to be a copy-paste error from the "Echo or Echo Reply" message's description.

Errata ID: 2936
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jeffrey Connell
Date Reported: 2011-08-13
Held for Document Update by: ron bonica

On page 19, it says:

The identifier and sequence number may be used by the echo sender
to aid in matching the replies with the requests.

It should say:

The identifier and sequence number may be used by the information request
sender to aid in matching the replies with the requests.

Notes:

In the "Description" of the "Information Request or Information Reply" message. Appears to be a copy-paste error from the "Echo or Echo Reply" message's description.

RFC 793, "Transmission Control Protocol", September 1981

Note: This RFC has been obsoleted by RFC 9293

Note: This RFC has been updated by RFC 1122, RFC 3168, RFC 6093, RFC 6528

Source of RFC: Legacy
Area Assignment: tsv

Errata ID: 1561
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Held for Document Update by: Wes Eddy

Section 3.2 says:

    LAST-ACK - represents waiting for an acknowledgment of the
    connection termination request previously sent to the remote TCP
    (which includes an acknowledgment of its connection termination
    request).

It should say:

    LAST-ACK - represents waiting for an acknowledgment of the
    connection termination request previously sent to the remote TCP
    (The connection termination request sent to the remote TCP included
    an acknowledgment of the connection termination request sent from
    the remote TCP).

Notes:

It is unclear what 'which' and 'its' refers to.

Errata ID: 1565
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Held for Document Update by: Wes Eddy

Section 3.8 says:

TCP/Lower-Level Interface

      Type of Service = Precedence: routine, Delay: normal, Throughput:
      normal, Reliability: normal; or 00000000.

It should say:

TCP/Lower-Level Interface

      Type of Service = Precedence, Delay: normal, Throughput:
      normal, Reliability: normal; or XXX00000.
      where XXX are the three bits determining precedence, e.g. 000
      means routine.

Notes:

The precedence is given by the user.

Errata ID: 1569
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Held for Document Update by: Wesley Eddy

Section 2.4 says:

The TCP/internet interface provides calls to send and receive
datagrams addressed to TCP modules in hosts anywhere in the internet
system.

It should say:

The TCP/internet interface provides calls to send datagrams addressed
to and receive datagrams addressed from TCP modules in hosts anywhere
in the internet system.

Notes:

scnr

Errata ID: 1571
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Held for Document Update by: Wesley Eddy

Section 3.1 says:

Maximum Segment Size Option Data:  16 bits

          If this option is present, then it communicates the maximum
          receive segment size at the TCP which sends this segment.
          This field must only be sent in the initial connection request
          (i.e., in segments with the SYN control bit set).  If this
          option is not used, any segment size is allowed.

It should say:

Maximum Segment Size Option Data:  16 bits

          If this option is present, then it communicates the maximum
          receive segment size at the TCP which sends this segment.
          This field may be sent in the initial connection request
          (i.e., in segments with the SYN control bit set) and must not
          be sent in other segments.  If this option is not used, any
          segment size is allowed.

Notes:

'must only' is ambiguous or even senseless.

Errata ID: 3300
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Botong Huang
Date Reported: 2012-07-30
Held for Document Update by: Wes Eddy
Date Held: 2012-09-13

Section 3.9 says:

SEGMENT ARRIVES
SYN-SENT STATE

If the ACK bit is set

          If SEG.ACK =< ISS, or SEG.ACK > SND.NXT, send a reset (unless
          the RST bit is set, if so drop the segment and return)

            <SEQ=SEG.ACK><CTL=RST>

          and discard the segment.  Return.

          If SND.UNA =< SEG.ACK =< SND.NXT then the ACK is acceptable.

It should say:

SEGMENT ARRIVES
SYN-SENT STATE

If the ACK bit is set

          If SEG.ACK =< ISS, or SEG.ACK > SND.NXT, send a reset (unless
          the RST bit is set, if so drop the segment and return)

            <SEQ=SEG.ACK><CTL=RST>

          and discard the segment.  Return.

          If SND.UNA < SEG.ACK =< SND.NXT then the ACK is acceptable.

Notes:

In SYN-SENT, SND.UNA == ISS, so the first line is contradictory to the last.

Verifier Notes:

This is being Held for Document Update rather than Verified because technically the algorithm is still correct, as the first check against ISS will fail and cause a reset to be generated. The second sentence that has an off-by-one error appears to be merely a paraphrasing.

In practice today, much code seems to be simplifying further and checking that SEG.ACK == SND.NXT, for stacks that are not sending data on the SYN, so I do not believe this text is leading to any significant issue with bugs or interoperability in the wild.

Errata ID: 3301
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Botong Huang
Date Reported: 2012-07-30
Held for Document Update by: Wes Eddy
Date Held: 2012-09-13

Section 3.9 says:

SEGMENT ARRIVES
Otherwise (Other States)
fifth check the ACK field
p71

     if the ACK bit is on

        SYN-RECEIVED STATE

          If SND.UNA =< SEG.ACK =< SND.NXT then enter ESTABLISHED state
          and continue processing.


            If the segment acknowledgment is not acceptable, form a
            reset segment,

              <SEQ=SEG.ACK><CTL=RST>

            and send it.

It should say:

SEGMENT ARRIVES
Otherwise (Other States)
fifth check the ACK field
p71

     if the ACK bit is on

        SYN-RECEIVED STATE

          If SND.UNA < SEG.ACK =< SND.NXT then enter ESTABLISHED state
          and continue processing.


            If the segment acknowledgment is not acceptable, form a
            reset segment,

              <SEQ=SEG.ACK><CTL=RST>

            and send it.

Notes:

In SYN-RECEIVE, SND.UNA == ISS. When the first ACK arrive with SEG.ACK == SND.UNA, it should be not accepted and thus transfer to ESTABLISHED state. This doesn't seem to be in rfc1122. Not sure if it is reported somewhere.


Verifier Note:
The side sending generating a packet that would erroneously check out would either be in error itself for generating the packet (not following the standard), or the packet would be extremely old (from a prior connection), and the responses should generate RSTs. Existing code seems to already be implementing this correctly, so I do not think there is an interoperability issue.

Errata ID: 3305
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Botong Huang
Date Reported: 2012-07-31
Held for Document Update by: Martin Stiemerling
Date Held: 2015-03-24

Section 3.9 says:

p70
SEGMENT ARRIVES
   Otherwise,
   first check sequence number

      SYN-RECEIVED STATE
      ESTABLISHED STATE
      FIN-WAIT-1 STATE
      FIN-WAIT-2 STATE
      CLOSE-WAIT STATE
      CLOSING STATE
      LAST-ACK STATE
      TIME-WAIT STATE

        Segments are processed in sequence.  Initial tests on arrival
        are used to discard old duplicates, but further processing is
        done in SEG.SEQ order.  If a segment's contents straddle the
        boundary between old and new, only the new parts should be
        processed.

        There are four cases for the acceptability test for an incoming
        segment:

        Segment Receive  Test
        Length  Window
        ------- -------  -------------------------------------------

           0       0     SEG.SEQ = RCV.NXT

           0      >0     RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND

          >0       0     not acceptable

          >0      >0     RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND
                      or RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND

It should say:

Added my Martin Stiemerling (TSV AD):
A document update will address this problem and the TCPM working is
expected to find a solution. 

Notes:

Not sure how to correct it systemmatically, so I just present the problem.

If in SYN-RECEIVED state, and received a SYN-ACK packet with no data as:
SEG.SEQ = IRS
SEG.ACK = ISS + 1

However in SYN-RECEIVED state, RCV.NXT = IRS + 1, which means the SYN-ACK packet will fail on the second test above. The SYN-ACK packet will be dropped and a ACK packet is sent in reply. As a result, we lost the SYN part, but it is fine because we've already received SYN packet once. However, we also lost the ACK part which is supposed to be the ACK of our SYN. Thus we will never reach the ESTABLISH state.

Errata ID: 4785
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Sanjeev Ranot
Date Reported: 2016-08-20
Held for Document Update by: Mirja Kühlewind
Date Held: 2016-09-01

Section 3.9 p. 72 says:

If the ACK is a duplicate
(SEG.ACK < SND.UNA), it can be ignored.

It should say:

If the ACK is a duplicate
(SEG.ACK =< SND.UNA), it can be ignored except when equality is met, 
then window should be updated. This can happen when there are 
segments in flight but the receiver shrinks its RCV.BUF to drop all 
of them and send an ACK carrying zero window update. Upon its 
arrival at the sending TCP, condition SND.UNA = SEG.ACK is met and 
we must update SND.WND <- 0. Then sender starts persist timer for 
sending zero-window probes [Ref. RFC 1122 Section 4.2.2.17, page 92]

Notes:

The condition is corrected as Duplicate ACK in
RFC 1122, Section 4.2.2.20 (g) p. 94. Accordingly old text must be
modified and new text should also be present to support the corrected
condition in RFC 793.

This is one case where duplicate acknowledgment cannot be ignored. i.e.
when SEG.ACK == SND.UNA and advertised window in the incoming ACK is 0
in which case sender needs to :
1. update window
2. start persist timer
3. send zero window probe segments.


Note:
Such ACKs should not be called as duplicates as it fails condition (e)
of definition of "DUPLICATE ACKNOWLEDGMENT" in Ref 5681 Section 2, pg 4

Errata ID: 2296
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vishwas Manral
Date Reported: 2010-06-03
Held for Document Update by: Wes Eddy

Section 3 says:

  The security paramaters may be used even in a non-secure environment
  (the values would indicate unclassified data), thus hosts in
  non-secure environments must be prepared to receive the security
  parameters, though they need not send them.

It should say:

  The security parameters may be used even in a non-secure environment
  (the values would indicate unclassified data), thus hosts in
  non-secure environments must be prepared to receive the security
  parameters, though they need not send them.

Notes:

s/paramaters/parameters/

Errata ID: 2297
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vishwas Manral
Date Reported: 2010-06-03
Held for Document Update by: Wes Eddy

Section 3.8 says:

    Any lower level protocol will have to provide the source address,
    destination address, and protocol fields, and some way to determine
    the "TCP length", both to provide the functional equivlent service
    of IP and to be used in the TCP checksum.

It should say:

    Any lower level protocol will have to provide the source address,
    destination address, and protocol fields, and some way to determine
    the "TCP length", both to provide the functional equivalent service
    of IP and to be used in the TCP checksum.

Notes:

s/equivlent/equivalent/

Errata ID: 2298
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vishwas Manral
Date Reported: 2010-06-03
Held for Document Update by: Wes Eddy

Section Page 74 says:

Once the TCP takes responsibility for the data it advances
RCV.NXT over the data accepted, and adjusts RCV.WND as
apporopriate to the current buffer availability

It should say:

Once the TCP takes responsibility for the data it advances
RCV.NXT over the data accepted, and adjusts RCV.WND as
appropriate to the current buffer availability

Notes:

s/apporopriate/appropriate/

Errata ID: 2748
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-03-13
Held for Document Update by: Wes Eddy

Section 2.8 says:

2.8.  Data Communication

  The data that flows on a connection may be thought of as a stream of
  octets.  The sending user indicates in each SEND call whether the data
  in that call (and any preceeding calls) should be immediately pushed
  through to the receiving user by the setting of the PUSH flag.

It should say:

2.8.  Data Communication

  The data that flows on a connection may be thought of as a stream of
  octets.  The sending user indicates in each SEND call whether the data
  in that call (and any preceding calls) should be immediately pushed
  through to the receiving user by the setting of the PUSH flag.

Notes:

s/preceeding/preceding

Errata ID: 2749
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-03-13
Held for Document Update by: Wes Eddy

Section 3.2 says:

 NOTE BENE:  this diagram is only a summary and must not be taken as
 the total specification.

It should say:

 NOTA BENE:  this diagram is only a summary and must not be taken as
 the total specification.

Notes:

The Latin phrase is correctly written 'Nota bene', but not 'Note bene'.

Errata ID: 2934
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Held for Document Update by: Wes Eddy
Date Held: 2011-08-13

Section 3.4 says:

Reset Generation
    3.  If the connection is in a synchronized state (ESTABLISHED,
    FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT),
    any unacceptable segment (out of window sequence number or
    unacceptible acknowledgment number) must elicit only an empty
    acknowledgment segment containing the current send-sequence number
    and an acknowledgment indicating the next sequence number expected
    to be received, and the connection remains in the same state.

    If an incoming segment has a security level, or compartment, or
    precedence which does not exactly match the level, and compartment,
    and precedence requested for the connection,a reset is sent and
    connection goes to the CLOSED state. The reset takes its sequence
    number from the ACK field of the incoming segment.

It should say:

Reset Generation
    3.  If the connection is in a synchronized state (ESTABLISHED,
    FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT),
    any unacceptable segment (out of window sequence number or
    unacceptable acknowledgment number) must elicit only an empty
    acknowledgment segment containing the current send-sequence number
    and an acknowledgment indicating the next sequence number expected
    to be received, and the connection remains in the same state.

    If an incoming segment has a security level, or compartment, or
    precedence which does not exactly match the level, and compartment,
    and precedence requested for the connection, a reset is sent and
    the connection goes to the CLOSED state.  The reset takes its sequence
    number from the ACK field of the incoming segment.
  

Notes:

Editorial errors:
1. Typo unacceptible -> unacceptable
2. wrong spacing and missing 'the'

Errata ID: 3213
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yi, EungJun
Date Reported: 2012-05-05
Held for Document Update by: Barry Leiba

Section 3.9 says:

Segments with higher begining sequence
numbers may be held for later processing.

It should say:

Segments with higher beginning sequence
numbers may be held for later processing.

Notes:

"begning" should be "beginning"

Errata ID: 4314
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramakrishna Rao DTV
Date Reported: 2015-03-26
Held for Document Update by: Martin Stiemerling
Date Held: 2015-04-14

Section 3.3 says:

Since the maximum segment
lifetime in the net is not likely to exceed a few tens of seconds,
this is deemed ample protection for foreseeable nets, even if data
rates escalate to l0's of megabits/sec.  At 100 megabits/sec, the
cycle time is 5.4 minutes which may be a little short, but still
within reason.

It should say:

Since the maximum segment
lifetime in the net is not likely to exceed a few tens of seconds,
this is deemed ample protection for foreseeable nets, even if data
rates escalate to 10's of megabits/sec.  At 100 megabits/sec, the
cycle time is 5.4 minutes which may be a little short, but still
within reason.

Notes:

s/l0/10

Errata ID: 4566
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Welzl
Date Reported: 2015-12-16
Held for Document Update by: Martin Stiemerling
Date Held: 2015-12-16

Section 3.9 says:

If the segment empties and carries an PUSH flag,

It should say:

If the segment empties and carries a PUSH flag,

Errata ID: 4580
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Masoud Valizadeh
Date Reported: 2016-01-05
Held for Document Update by: Martin Stiemerling
Date Held: 2016-01-12

Section 2.7 says:

This exchange has been termed a three-way hand shake.

It should say:

This exchange has been termed a three-way handshake.

Errata ID: 6305
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Shuo Chen
Date Reported: 2020-10-12
Held for Document Update by: Martin Duke
Date Held: 2020-10-12

Section 3.9 Page 67 says:

      fourth check the SYN bit

        This step should be reached only if the ACK is ok, or there is
        no ACK, and it the segment did not contain a RST.

It should say:

      fourth check the SYN bit

        This step should be reached only if the ACK is ok, or there is
        no ACK, and the segment did not contain a RST.

Notes:

In the last sentence, the 'it' in 'and it the segment' is redundant.

Errata ID: 6222
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Charles Deng
Date Reported: 2020-07-06
Held for Document Update by: Martin Duke
Date Held: 2020-07-07

Section 3.4 says:

  7.  SYN-SENT    <-- <SEQ=400><ACK=101><CTL=SYN,ACK>  <-- SYN-RECEIVED

  8.  ESTABLISHED --> <SEQ=101><ACK=401><CTL=ACK>      --> ESTABLISHED

                    Recovery from Old Duplicate SYN

                               Figure 9.

It should say:

  7.  ESTABLISHED <-- <SEQ=400><ACK=101><CTL=SYN,ACK>  <-- SYN-RECEIVED

  8.  ESTABLISHED --> <SEQ=101><ACK=401><CTL=ACK>      --> ESTABLISHED

                    Recovery from Old Duplicate SYN

                               Figure 9.

Notes:

To align with figure 7 in the same section, after TCP A get the SYN+ACK from TCP B, TCP A should enter ESTABLISHED state instead stay in SYN-SENT state.

Errata ID: 6281
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Merlin Büge
Date Reported: 2020-09-06
Held for Document Update by: Martin Duke
Date Held: 2020-10-12

Section 3.4 says:

  At line 4, TCP A responds with an empty segment containing an ACK for
  TCP B's SYN; and in line 5, TCP A sends some data.  Note that the
  sequence number of the segment in line 5 is the same as in line 4
  because the ACK does not occupy sequence number space (if it did, we
  would wind up ACKing ACK's!).

It should say:

  At line 4, TCP A responds with an empty segment containing an ACK for
  TCP B's SYN; and in line 5, TCP A sends some data.  Note that the
  sequence number of the segment in line 5 is the same as in line 4
  because the ACK does not occupy sequence number space (if it did, we
  would wind up ACKing ACKs!).

Notes:

last line: "ACK's" -> "ACKs"

Errata ID: 6282
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Merlin Büge
Date Reported: 2020-09-06
Held for Document Update by: Martin Duke
Date Held: 2020-10-12

Section 3.3 says:

  To avoid confusion we must prevent segments from one incarnation of a
  connection from being used while the same sequence numbers may still
  be present in the network from an earlier incarnation.  We want to
  assure this, even if a TCP crashes and loses all knowledge of the
  sequence numbers it has been using.  When new connections are created,
  an initial sequence number (ISN) generator is employed which selects a
  new 32 bit ISN.  The generator is bound to a (possibly fictitious) 32
  bit clock whose low order bit is incremented roughly every 4
  microseconds.  Thus, the ISN cycles approximately every 4.55 hours.
  Since we assume that segments will stay in the network no more than
  the Maximum Segment Lifetime (MSL) and that the MSL is less than 4.55
  hours we can reasonably assume that ISN's will be unique.

  For each connection there is a send sequence number and a receive
  sequence number.  The initial send sequence number (ISS) is chosen by
  the data sending TCP, and the initial receive sequence number (IRS) is
  learned during the connection establishing procedure.

  For a connection to be established or initialized, the two TCPs must
  synchronize on each other's initial sequence numbers.  This is done in
  an exchange of connection establishing segments carrying a control bit
  called "SYN" (for synchronize) and the initial sequence numbers.  As a
  shorthand, segments carrying the SYN bit are also called "SYNs".
  Hence, the solution requires a suitable mechanism for picking an
  initial sequence number and a slightly involved handshake to exchange
  the ISN's.

  The synchronization requires each side to send it's own initial
  sequence number and to receive a confirmation of it in acknowledgment
  from the other side.  Each side must also receive the other side's
  initial sequence number and send a confirming acknowledgment.

    1) A --> B  SYN my sequence number is X
    2) A <-- B  ACK your sequence number is X
    3) A <-- B  SYN my sequence number is Y
    4) A --> B  ACK your sequence number is Y

  Because steps 2 and 3 can be combined in a single message this is
  called the three way (or three message) handshake.

  A three way handshake is necessary because sequence numbers are not
  tied to a global clock in the network, and TCPs may have different
  mechanisms for picking the ISN's.  The receiver of the first SYN has
  no way of knowing whether the segment was an old delayed one or not,
  unless it remembers the last sequence number used on the connection
  (which is not always possible), and so it must ask the sender to
  verify this SYN.  The three way handshake and the advantages of a
  clock-driven scheme are discussed in [3].

It should say:

  To avoid confusion we must prevent segments from one incarnation of a
  connection from being used while the same sequence numbers may still
  be present in the network from an earlier incarnation.  We want to
  assure this, even if a TCP crashes and loses all knowledge of the
  sequence numbers it has been using.  When new connections are created,
  an initial sequence number (ISN) generator is employed which selects a
  new 32 bit ISN.  The generator is bound to a (possibly fictitious) 32
  bit clock whose low order bit is incremented roughly every 4
  microseconds.  Thus, the ISN cycles approximately every 4.55 hours.
  Since we assume that segments will stay in the network no more than
  the Maximum Segment Lifetime (MSL) and that the MSL is less than 4.55
  hours we can reasonably assume that ISNs will be unique.

  For each connection there is a send sequence number and a receive
  sequence number.  The initial send sequence number (ISS) is chosen by
  the data sending TCP, and the initial receive sequence number (IRS) is
  learned during the connection establishing procedure.

  For a connection to be established or initialized, the two TCPs must
  synchronize on each other's initial sequence numbers.  This is done in
  an exchange of connection establishing segments carrying a control bit
  called "SYN" (for synchronize) and the initial sequence numbers.  As a
  shorthand, segments carrying the SYN bit are also called "SYNs".
  Hence, the solution requires a suitable mechanism for picking an
  initial sequence number and a slightly involved handshake to exchange
  the ISNs.

  The synchronization requires each side to send it's own initial
  sequence number and to receive a confirmation of it in acknowledgment
  from the other side.  Each side must also receive the other side's
  initial sequence number and send a confirming acknowledgment.

    1) A --> B  SYN my sequence number is X
    2) A <-- B  ACK your sequence number is X
    3) A <-- B  SYN my sequence number is Y
    4) A --> B  ACK your sequence number is Y

  Because steps 2 and 3 can be combined in a single message this is
  called the three way (or three message) handshake.

  A three way handshake is necessary because sequence numbers are not
  tied to a global clock in the network, and TCPs may have different
  mechanisms for picking the ISNs.  The receiver of the first SYN has
  no way of knowing whether the segment was an old delayed one or not,
  unless it remembers the last sequence number used on the connection
  (which is not always possible), and so it must ask the sender to
  verify this SYN.  The three way handshake and the advantages of a
  clock-driven scheme are discussed in [3].

Notes:

The only change: s/ISN's/ISNs/g
"ISN's" has three matches in the whole RFC, all of them in this section, and all matches refer to the plural form of ISN.
ISN stands for "initial sequence number".
Sorry for all the bulk text.

Errata ID: 6476
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2021-03-12
Held for Document Update by: Martin Duke
Date Held: 2021-03-16

Section 3.8 says:

        connection.Implementers may want to give the user control of

It should say:

        connection. Implementers may want to give the user control of

Notes:

Missing space. 793bis is in progress and this text no longer exists.

Errata ID: 6477
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2021-03-12
Held for Document Update by: Martin Duke
Date Held: 2021-03-16

Section GLOSSARY says:

          unit of data transfered between a pair of TCP modules.

It should say:

          unit of data transferred between a pair of TCP modules.

Notes:

Misspelled "transferred".

(text does not exist in ongoing 793bis)

RFC 819, "The Domain Naming Convention for Internet User Applications", August 1982

Source of RFC: Legacy

Errata ID: 6608
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Greg Skinner
Date Reported: 2021-06-12
Held for Document Update by: Éric Vyncke
Date Held: 2021-06-12

Section Appendix C says:

Whenever a name server is called it may be a recursive server or an
interactive server.

It should say:

Whenever a name server is called it may be a recursive server or an
iterative server.

Notes:

Wording is changed to reflect the industry-accepted distinction between iterative and recursive name servers.

RFC 822, "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES", August 1982

Note: This RFC has been obsoleted by RFC 2822

Note: This RFC has been updated by RFC 1123, RFC 2156, RFC 1327, RFC 1138, RFC 1148

Source of RFC: Legacy
Area Assignment: app

Errata ID: 1083
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Backes
Date Reported: 2007-11-21
Held for Document Update by: Pete Resnick

Section 3.1.4. says:

                    Muhammed              atom
                    .                     special
                    (I am  the greatest)  comment
                    Ali                   atom
                    @                     atom
                    (the)                 comment
                    Vegas                 atom
                    .                     special
                    WBA                   atom

It should say:

                    Muhammed              atom
                    .                     special
                    (I am  the greatest)  comment
                    Ali                   atom
                    @                     special
                    (the)                 comment
                    Vegas                 atom
                    .                     special
                    WBA                   atom

Notes:

Apparently an artifact introduced by copying and incompletely adapting the example in RFC733, section III.B.e, which uses the atom "at" instead of the special "@".

Errata ID: 3408
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Thomas Lane
Date Reported: 2012-11-14
Held for Document Update by: Pete Resnick
Date Held: 2013-01-28

Section 3.3 says:

quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
                                            ; quoted chars.


[...]

domain-literal =  "[" *(dtext / quoted-pair) "]"

[...]

comment     =  "(" *(ctext / quoted-pair / comment) ")"

It should say:

quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
                                            ; quoted chars.
                                            ; Bare LF MUST NOT
                                            ; follow the
                                            ; quoted-pair \ CR


[...]

domain-literal =  "[" *(dtext / quoted-pair) "]" ; Bare LF MUST NOT
                                                 ; follow the
                                                 ; quoted-pair \ CR

[...]

comment     =  "(" *(ctext / quoted-pair / comment) ")" ; Bare LF MUST NOT
                                                        ; follow the
                                                        ; quoted-pair \ CR

Notes:

In Section B.1, the intent is made clear that an implementer should be able to read fields with minimal processing, and find their ends anywhere CRLF is not followed by a LWSP-char.

The current BNF allows the sequence \ CR LF, where \ CR is a quoted-pair, inside a quoted-string, domain-literal, or comment in a structured field. An unstructured field may be any sequence of text, so the last character of an unstructured field could be \, and the field would end with \ CR LF. So, robust minimal processing of fields does not work without this correction.

Example:

-- Unstructured field terminates here.
Subject: evil = "this \[CRLF]
[CRLF]

-- Structured field does not terminate here, as written.
Structured-Field: evil = "this \[CRLF] <-- quoted-pair, bare LF as qtext"
[CRLF]

Conclusion: The plan in appendix B does not work if the quoted-pair \ CR may be followed by a bare LF: the implementer would need to know whether a field is structured or unstructured to know where it terminates. So, this must just be an oversight.

I realize this oversight is eliminated in less obsolete documents 2822 and 5322, but (1) many other RFCs reference RFC 822 and not the less obsolete documents, and (2) the less obsolete documents do not specifically discuss this issue or release receivers from parsing messages generated according to this specification.

--VERIFIER NOTES--
It is unclear whether the original authors of 822 would have required no bare LF after a CR quoted-pair or would have changed appendix B to accommodate quoted-pairs. The IESG guidelines for errata say that errata on obsolete document that are still in use should be treated the same as errata on current documents. Since it's not clear where the error is, and since this has been dealt with in 2822/5322, this erratum is marked as "Hold".

Errata ID: 4584
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sebastian Haller
Date Reported: 2016-01-07
Held for Document Update by: Barry Leiba
Date Held: 2016-01-07

Section A.3.3 says:

     cc       :  Important folk:
                   Tom Softwood <Balsa@Tree.Root>,
                   "Sam Irving"@Other-Host;,
                 Standard Distribution:
                   /main/davis/people/standard@Other-Host,
                   "<Jones>standard.dist.3"@Tops-20-Host>;

It should say:

     cc       :  Important folk:
                   Tom Softwood <Balsa@Tree.Root>,
                   "Sam Irving"@Other-Host;,
                 Standard Distribution:
                   /main/davis/people/standard@Other-Host,
                   "<Jones>standard.dist.3"@Tops-20-Host;

or

                   <"Jones>standard.dist.3"@Tops-20-Host>;

or

                   <"<Jones>standard.dist.3"@Tops-20-Host>;

Notes:

According to 3.4.6 of the RFC, brackets must occur in matched pairs. There is not matching "<" for the closing ">" after "Tops-20-Host".

----- Verifier Notes -----
RFC 822 has long been obsolete, first by RFC 2822 and then by RFC 5322, and I hope everyone is using 5322 by now. The examples were completely re-done in 2822, and this issue is long gone.

RFC 854, "Telnet Protocol Specification", May 1983

Note: This RFC has been updated by RFC 5198

Source of RFC: Legacy
Area Assignment: app

Errata ID: 571
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: SungWoon Lee
Date Reported: 2006-08-18
Held for Document Update by: Alexey Melnikov
Date Held: 2010-09-02

Section 3 says:

Neither can unilaterally seize control from the other; rather the 
controlling end must relinguish its control explicitly.
                     ^^^^^^^^^^

It should say:

Neither can unilaterally seize control from the other; rather the 
controlling end must relinquish its control explicitly.
                     ^^^^^^^^^^

Errata ID: 6478
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2021-03-12
Held for Document Update by: Francesca Palombini
Date Held: 2021-03-15

Section [Page 12] says:

      have defined, but not reguired, meanings.  The actual code

It should say:

      have defined, but not required, meanings.  The actual code

Notes:

It should say "required" instead of "reguired".

RFC 864, "Character Generator Protocol", May 1983

Source of RFC: Legacy

Errata ID: 5333
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Richard Bos
Date Reported: 2018-04-25
Held for Document Update by: Benjamin Kaduk
Date Held: 2018-04-29

Throughout the document, when it says:

      One popular pattern is 72 chraracter lines of the ASCII printing
      characters.  There are 95 printing characters in the ASCII
      character set.  Sort the characters into an ordered sequence and

It should say:

      One popular pattern is 72 character lines of the ASCII printing
      characters.  There are 95 printing characters in the ASCII
      character set.  Sort the characters into an ordered sequence and

Notes:

Misspelling of 'character' in the first line.

RFC 882, "Domain names: Concepts and facilities", November 1983

Note: This RFC has been obsoleted by RFC 1034, RFC 1035

Note: This RFC has been updated by RFC 973

Source of RFC: Legacy

Errata ID: 5912
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sharbel Bousemaan
Date Reported: 2019-11-18
Held for Document Update by: Barry Leiba
Date Held: 2019-11-18

Section Page 14 says:

3.  In must provide redundant name servers.

It should say:

3.  It must provide redundant name servers.

RFC 917, "Internet subnets", October 1984

Source of RFC: Legacy

Errata ID: 3635
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Demirtzidis
Date Reported: 2013-05-30
Held for Document Update by: Ted Lemon

Section 2.1 says:

4. Self-encoding fixed-width field: A specific number of bits
   is is used for the subnet number. Subnets are in use if the
   high-order bit of this field is one; otherwise, the entire
   local address part is used for host number.

It should say:

4. Self-encoding fixed-width field: A specific number of bits
   is used for the subnet number. Subnets are in use if the
   high-order bit of this field is one; otherwise, the entire
   local address part is used for host number.

Notes:

I would like to report a small/minor grammatical error on page 5 of
RFC917. Point 4 of subsection 2.1 Note that the word "is" is repeated.

RFC 951, "Bootstrap Protocol", September 1985

Note: This RFC has been updated by RFC 1395, RFC 1497, RFC 1532, RFC 1542, RFC 5494

Source of RFC: Legacy
Area Assignment: int

Errata ID: 569
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: "Yin Shuming"
Date Reported: 2006-02-18
Held for Document Update by: ron bonica

Section 4 says:

How can the server send an IP datagram to the client, if the client doesnt 
know its own IP address (yet)?

It should say:

How can the server send an IP datagram to the client, if the client doesn't 
know its own IP address (yet)?

RFC 959, "File Transfer Protocol", October 1985

Note: This RFC has been updated by RFC 2228, RFC 2640, RFC 2773, RFC 3659, RFC 5797, RFC 7151

Source of RFC: Legacy
Area Assignment: app

Errata ID: 2411
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Anthony Bryan
Date Reported: 2010-08-03
Held for Document Update by: Peter Saint-Andre

Section 2.2 says:

      type

         The data representation type used for data transfer and
         storage.  Type implies certain transformations between the time
         of data storage and data transfer.  The representation types
         defined in FTP are described in the Section on Establishing
         Data Connections.

It should say:

      type

         The data representation type used for data transfer and
         storage.  Type implies certain transformations between the time
         of data storage and data transfer.  The representation types
         defined in FTP are described in the Section on Data Representation
         and Storage.

Notes:

The representation types defined in FTP are described in Section 3.1, Data Representation and Storage, or more specifically Section 3.1.1, Data Types.

Errata ID: 1941
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tomasz Kluza
Date Reported: 2009-11-09
Held for Document Update by: Peter Saint-Andre

Section 3.1.1.5. says:

(...)Therefore, these types have a second parameter
            specifying one of the following three formats:
3.1.1.5.1.  NON PRINT
(...)
3.1.1.5.2.  TELNET FORMAT CONTROLS
(...)
     
3.1.1.5.2.  CARRIAGE CONTROL (ASA)

It should say:

(...)Therefore, these types have a second parameter
            specifying one of the following three formats:
3.1.1.5.1.  NON PRINT
(...)
3.1.1.5.2.  TELNET FORMAT CONTROLS
(...)
     
3.1.1.5.3.  CARRIAGE CONTROL (ASA)

Notes:

Two Sections in the RFC have the same number in the document whereas the The Carriage Control (ASA) should have 3.1.1.5.3. in the structure of the RFC document since its a third format of the possible value for the parameter mention in the statement "Therefore, these types have a second parameter specifying one of the following three formats" ATM it has the same 3.1.1.5.2. as the Telnet Format Controls.

Errata ID: 2503
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Anthony Bryan
Date Reported: 2010-08-26
Held for Document Update by: Peter Saint-Andre

Section 5.3 says:

   5.3.  COMMANDS

      The commands are Telnet character strings transmitted over the
      control connections as described in the Section on FTP Commands.
      The command functions and semantics are described in the Section
      on Access Control Commands, Transfer Parameter Commands, FTP
      Service Commands, and Miscellaneous Commands.

It should say:

   5.3.  COMMANDS

      The commands are Telnet character strings transmitted over the
      control connections as described in the Section on FTP Commands.
      The command functions and semantics are described in the Section
      on Access Control Commands, Transfer Parameter Commands, and FTP
      Service Commands.

Notes:

There does not appear to be a section on Miscellaneous Commands, although SITE and NOOP are listed as "Miscellaneous Commands" in Section 5.4, Sequencing of Commands and Replies. SITE and NOOP are described in 4.1.3, FTP Service Commands.

RFC 1001, "Protocol standard for a NetBIOS service on a TCP/UDP transport: Concepts and methods", March 1987

Source of RFC: Legacy

Errata ID: 679
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Anvish
Date Reported: 2002-02-25
Held for Document Update by: ron bonica

 

I found something strange in rfc1001
Maybe my code is wrong, but it returns "Tge NetBIOS tame"
instead of "The NetBIOS name" when I try to encode
FEGHGFCAEOGFHEECEJEPFDCAHEGBGNGF

"For example, the NetBIOS name "The NetBIOS name" in the NetBIOS scope
"SCOPE.ID.COM" would be represented at level one by the ASCII

character string:

FEGHGFCAEOGFHEECEJEPFDCAHEGBGNGF.SCOPE.ID.COM"

It should say:

[not submitted]

Notes:

from pending

RFC 1002, "Protocol standard for a NetBIOS service on a TCP/UDP transport: Detailed specifications", March 1987

Source of RFC: Legacy
Area Assignment: int

Errata ID: 567
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sir Dystic
Date Reported: 2001-04-26
Held for Document Update by: Brian Haberman

Section 4.2.16 says:

WAIT FOR ACKNOWLEDGEMENT (WACK) RESPONSE

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          NULL (0x0020)        |         IN (0x0001)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

The values for the first field (the resource record type) are defined above
in section 4.2.1.3.  RESOURCE RECORD:

   NULL       0x000A   NULL Resource Record (See WAIT FOR
                       ACKNOWLEDGEMENT RESPONSE)
   NB         0x0020   NetBIOS general Name Service Resource Record
                       (See NB_FLAGS and NB_ADDRESS, below)

Notes:

The value for type NULL is defined as 0x000A and the
comment specifically mentions WACK responses. The value shown in the packet
layout is 0x0020, the value for NB resource records, the most common value
for this field. In truth, I can't get Windows boxes to respond to this
packet as documented with either value in that field.

RFC 1034, "Domain names - concepts and facilities", November 1987

Note: This RFC has been updated by RFC 1101, RFC 1183, RFC 1348, RFC 1876, RFC 1982, RFC 2065, RFC 2181, RFC 2308, RFC 2535, RFC 4033, RFC 4034, RFC 4035, RFC 4343, RFC 4035, RFC 4592, RFC 5936, RFC 8020, RFC 8482, RFC 8767, RFC 9471

Source of RFC: Legacy
Area Assignment: int

Errata ID: 755
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: John Kristoff
Date Reported: 2006-03-13
Held for Document Update by: Brian Haberman
Date Held: 2012-04-26

 

Section 6.1. ends this way:

  Relative and absolute domain names may be freely intermixed in a
  master

which is incomplete.  It's unclear exactly how that sentence may have
been intended to end, but minimally I would suggeste it at least
terminated with 'file.'.

Section 6.2.8. in the diagram shows 'QTYPE=A', but should be of
type 'CNAME' based on the context of the example.

It should say:

[see above]

Notes:

from pending

Errata ID: 5316
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Mukund Sivaraman
Date Reported: 2018-03-31
Held for Document Update by: Warren Kumari (Ops AD)
Date Held: 2018-04-09

Section 4.3.3 says:

A * label appearing in a query name has no special effect, but can be
used to test for wildcards in an authoritative zone; such a query is the
only way to get a response containing RRs with an owner name with * in
it.  The result of such a query should not be cached.

It should say:

A * label appearing in a query name has no special effect, but can be
used to test for wildcards in an authoritative zone; such a query is the
only way to get a response containing RRs with an owner name with * in
it.  The result of such a query should not be used to synthesize RRs.

Notes:

It is perfectly OK for an RR with a wildcard label '*' to be cached as long as it's not used to synthesize any RRs on a caching resolver. The DNS implementations BIND and Unbound both cache such RRsets with wildcard label in the owner name.

WK (OpsAD): Please see thread https://www.ietf.org/mail-archive/web/dnsop/current/msg22563.html for additional information.

Errata ID: 4270
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jean-Philippe Paradis
Date Reported: 2015-02-12
Held for Document Update by: Ted Lemon
Date Held: 2015-02-12

Section 2.4 says:

In the interests of performance, implementations may couple these
functions.  For example, a resolver on the same machine as a name server
might share a database consisting of the the zones managed by the name
server and the cache managed by the resolver.

It should say:

In the interests of performance, implementations may couple these
functions.  For example, a resolver on the same machine as a name server
might share a database consisting of the zones managed by the name
server and the cache managed by the resolver.

Notes:

Just a duplicate "the".

Errata ID: 4269
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jean-Philippe Paradis
Date Reported: 2015-02-12
Held for Document Update by: Ted Lemon
Date Held: 2015-02-12

Section 2.3 says:

The organization of the domain system derives from some assumptions
about the needs and usage patterns of its user community and is designed
to avoid many of the the complicated problems found in general purpose
database systems.

It should say:

The organization of the domain system derives from some assumptions
about the needs and usage patterns of its user community and is designed
to avoid many of the complicated problems found in general purpose
database systems.

Notes:

Just a duplicate "the".

Errata ID: 4229
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sun Congyou
Date Reported: 2015-01-11
Held for Document Update by: Ted Lemon
Date Held: 2015-01-14

Section 4.2.2 says:

[RFC-1033] catalogs available DNS software an discusses administration 
procedures.

It should say:

[RFC-1033] catalogs available DNS software and discusses administration 
procedures.

Errata ID: 4230
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sun Congyou
Date Reported: 2015-01-11
Held for Document Update by: Ted Lemon
Date Held: 2015-01-14

Section 4.3.3 says:

   - When the query name or a name between the wildcard domain and
     the query name is know to exist.

It should say:

   - When the query name or a name between the wildcard domain and
     the query name is known to exist.

Errata ID: 4511
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Han Ge Xin
Date Reported: 2015-10-23
Held for Document Update by: Terry Manderson
Date Held: 2015-11-01

Section 3.6 says:

identifies a mail exchange for the domain. See [RFC-974 for details.

It should say:

identifies a mail exchange for the domain. See [RFC-974] for details.

Notes:

Just missing the "]"

Errata ID: 4893
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: anonymous
Date Reported: 2016-12-22
Held for Document Update by: Warren Kumari (Ops AD)
Date Held: 2018-04-01

Section 3.7.1 says:

For example, a mailer tying to send mail to Mockapetris@ISI.EDU might
ask the resolver for mail information about ISI.EDU, resulting in a
query for QNAME=ISI.EDU, QTYPE=MX, QCLASS=IN.

It should say:

For example, a mailer trying to send mail to Mockapetris@ISI.EDU might
ask the resolver for mail information about ISI.EDU, resulting in a
query for QNAME=ISI.EDU, QTYPE=MX, QCLASS=IN.

Notes:

Trying, not tying.

RFC 1035, "Domain names - implementation and specification", November 1987

Note: This RFC has been updated by RFC 1101, RFC 1183, RFC 1348, RFC 1876, RFC 1982, RFC 1995, RFC 1996, RFC 2065, RFC 2136, RFC 2181, RFC 2137, RFC 2308, RFC 2535, RFC 2673, RFC 2845, RFC 3425, RFC 3658, RFC 4033, RFC 4034, RFC 4035, RFC 4343, RFC 5936, RFC 5966, RFC 6604, RFC 7766, RFC 8482, RFC 8490, RFC 8767

Source of RFC: Legacy
Area Assignment: int

Errata ID: 1813
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: moritzh
Date Reported: 2009-07-19
Held for Document Update by: Brian Haberman

Section 5.3 says:

The following is an example file which might be used to define the
ISI.EDU zone.and is loaded with an origin of ISI.EDU:

@   IN  SOA     VENERA      Action\.domains (
                                 20     ; SERIAL
                                 7200   ; REFRESH
                                 600    ; RETRY
                                 3600000; EXPIRE
                                 60)    ; MINIMUM

        NS      A.ISI.EDU.
        NS      VENERA
        NS      VAXA
        MX      10      VENERA
        MX      20      VAXA

A       A       26.3.0.103

VENERA  A       10.1.0.52
        A       128.9.0.32

VAXA    A       10.2.0.27
        A       128.9.0.33


[...]

Note the use of the \ character in the SOA RR to specify the responsible
person mailbox "Action.domains@E.ISI.EDU".

It should say:

The following is an example file which might be used to define the
ISI.EDU zone.and is loaded with an origin of ISI.EDU:

@   IN  SOA     VENERA      Action\.domains (
                                 20     ; SERIAL
                                 7200   ; REFRESH
                                 600    ; RETRY
                                 3600000; EXPIRE
                                 60)    ; MINIMUM

        NS      A.ISI.EDU.
        NS      VENERA
        NS      VAXA
        MX      10      VENERA
        MX      20      VAXA

A       A       26.3.0.103

VENERA  A       10.1.0.52
        A       128.9.0.32

VAXA    A       10.2.0.27
        A       128.9.0.33


[...]

Note the use of the \ character in the SOA RR to specify the responsible
person mailbox "Action.domains@ISI.EDU".

Notes:

The introductory sentence and the following zone definition both correctly refer to the zone ISI.EDU. But the closing sentence noting the usage of "\." in the mailbox name erroneously expands the example to "Action.domains@E.ISI.EDU" instead of "Action.domains@ISI.EDU".

Errata ID: 3421
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Jeremy C. Reed
Date Reported: 2012-11-28
Held for Document Update by: Brian Haberman

Section 3.3.5 says:

The recommended policy for dealing with MD RRs found in
a master file is to reject them, or to convert them to MX RRs with a
preference of 10.

It should say:

The recommended policy for dealing with MF RRs found in
a master file is to reject them, or to convert them to MX RRs with a
preference of 10.

Notes:

3.3.5 about MF says "dealing with MD". It should probably say "dealing with MF". I assume this is a copy and paste error from earlier section about MD.

Errata ID: 5626
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Petr Špaček
Date Reported: 2019-02-07
Held for Document Update by: Warren Kumari (Ops AD)
Date Held: 2019-02-08

Section 5.2. says:

Several other validity checks that should be performed in addition to
insuring that the file is syntactically correct:

   1. All RRs in the file should have the same class.

   2. Exactly one SOA RR should be present at the top of the zone.

   3. If delegations are present and glue information is required,
      it should be present.

   4. Information present outside of the authoritative nodes in the
      zone should be glue information, rather than the result of an
      origin or similar error.

It should say:

Several other validity checks that should be performed in addition to
insuring that the file is syntactically correct:

   1. All RRs in the file should have the same class.

   2. Exactly one SOA RR should be present at the top of the zone.

   3. If delegations are present and glue information is required,
      it should be present.

   4. Information present outside of the authoritative nodes in the
      zone should be glue information, rather than the result of an
      origin or similar error.

   5. At least one NS RR must be present at the top of the zone.

Notes:

[ WK (OpsAD): This is correct, and should be considered / included if this RFC is updated. ]

RFC 1034 Section 4.2.1 vaguely specifies that NS RRs are expected to be found at zone apex but it is missing in the original algorithm above. This erratum adds explicit requirement for NS RR at zone apex.

Even more importantly this expectation was built into subsequent RFCs, e.g. RFC 2181 which would break if NS was present only in the parent zone but not in the child zone.

References to dnsop mailing list:
- https://mailarchive.ietf.org/arch/msg/dnsop/ipwko314FenUxrdzMl5vcick9wQ
- https://mailarchive.ietf.org/arch/msg/dnsop/JAS6TREsOh-b2J4rEAND6cds0Og

Errata ID: 2646
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2010-11-29
Held for Document Update by: Brian Haberman

Section 5.3 says:

The following is an example file which might be used to define the
ISI.EDU zone.and is loaded with an origin of ISI.EDU:

It should say:

The following is an example file which might be used to define the
ISI.EDU zone and is loaded with an origin of ISI.EDU:

Errata ID: 2691
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hirochika Asai
Date Reported: 2011-01-22
Held for Document Update by: Brian Haberman

Section 4.1.4 says:

In this scheme, an entire domain name or a list of labels at
the end of a domain name is replaced with a pointer to a prior occurance
of the same name.

It should say:

In this scheme, an entire domain name or a list of labels at
the end of a domain name is replaced with a pointer to a prior occurrence
of the same name.

Errata ID: 3230
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sam Bretheim
Date Reported: 2012-05-22
Held for Document Update by: Brian Haberman

Section 4.1.1 says:

RA              Recursion Available - this be is set or cleared in a

It should say:

RA              Recursion Available - this bit is set or cleared in a

Errata ID: 3691
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sam Bretheim
Date Reported: 2013-08-01
Held for Document Update by: Ted Lemon

Section 5.1 says:

\DDD            where each D is a digit is the octet corresponding to

It should say:

\DDD            where each D is a digit in the octet corresponding to

Errata ID: 4227
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sun Congyou
Date Reported: 2015-01-09
Held for Document Update by: Ted Lemon
Date Held: 2015-01-10

Section 4.2.1 says:

Messages sent using UDP user server port 53 (decimal).

It should say:

Messages sent using UDP use server port 53 (decimal).

Notes:

I'm very sorry for my previous mistake in errata ID 4226, this should be a correct one.

Errata ID: 5463
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Shulhan
Date Reported: 2018-08-14
Held for Document Update by: Warren Kumari (Ops AD)
Date Held: 2018-08-14

Section 4.1.3 says:

RDATA           a variable length string of octets that describes the
                resource.  The format of this information varies
                according to the TYPE and CLASS of the resource record.
                For example, the if the TYPE is A and the CLASS is IN,
                the RDATA field is a 4 octet ARPA Internet address.

It should say:

RDATA           a variable length string of octets that describes the
                resource.  The format of this information varies
                according to the TYPE and CLASS of the resource record.
                For example, if the TYPE is A and the CLASS is IN,
                the RDATA field is a 4 octet ARPA Internet address.

Notes:

The original text says "For example, the if the ...", where it should say, "For example, if the ...".

Errata ID: 5915
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alexander Dupuy
Date Reported: 2019-11-21
Held for Document Update by: Warren Kumari (Ops AD)
Date Held: 2021-01-26

Section 6.2 says:

When a response is so long that truncation is required, the truncation
should start at the end of the response and work forward in the
datagram.  Thus if there is any data for the authority section, the
answer section is guaranteed to be unique.

It should say:

When a response is so long that truncation is required, the truncation
should start at the end of the response and work forward in the
datagram.  Thus if there is any data for the authority section, the
answer section is guaranteed to be complete.

Notes:

It's not clear what it might mean for an answer section to be unique. However, by following the algorithm described of removing RRs from the back to the front, if any RRs remain in the authority (or additional) section, the answer section is guaranteed to be complete.

[ See thread at: https://mailarchive.ietf.org/arch/msg/dnsop/L_yjf4eyDRlkIOqaWULf1HUK8f0/ ]

Errata ID: 5974
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Xu Mingjie
Date Reported: 2020-02-03
Held for Document Update by: Warren Kumari (Ops AD)
Date Held: 2020-02-05

Section 3.4.2 says:

3.4.2. WKS RDATA format

    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    ADDRESS                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |       PROTOCOL        |                       |
    +--+--+--+--+--+--+--+--+                       |
    |                                               |
    /                   <BIT MAP>                   /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

where:

ADDRESS         An 32 bit Internet address

PROTOCOL        An 8 bit IP protocol number

<BIT MAP>       A variable length bit map.  The bit map must be a
                multiple of 8 bits long

It should say:

3.4.2. WKS RDATA format

    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    ADDRESS                    |
    |                                               |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |       PROTOCOL        |                       |
    +--+--+--+--+--+--+--+--+                       |
    |                                               |
    /                   <BIT MAP>                   /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

where:

ADDRESS         An 32 bit Internet address

PROTOCOL        An 8 bit IP protocol number

<BIT MAP>       A variable length bit map.  The bit map must be a
                multiple of 8 bits long

Notes:

There is an error in the ADDRESS field of WKS RDATA format. ADDRESS field should occupy two lines because it is 32 bit.

Errata ID: 5975
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Xu Mingjie
Date Reported: 2020-02-03
Held for Document Update by: Warren Kumari (Ops AD)
Date Held: 2020-02-05

Section 3.4.1 says:

3.4.1. A RDATA format

    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    ADDRESS                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

where:

ADDRESS         A 32 bit Internet address.

It should say:

3.4.1. A RDATA format

    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    ADDRESS                    |
    |                                               |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

where:

ADDRESS         A 32 bit Internet address.

Notes:

There is an error in the ADDRESS field of A RDATA format. ADDRESS field should occupy two lines because it is 32 bit.

Errata ID: 6260
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Merlin Büge
Date Reported: 2020-08-23
Held for Document Update by: Warren Kumari (Ops AD)
Date Held: 2020-08-24

Section 4.1.1 says:

ID              A 16 bit identifier assigned by the program that
                generates any kind of query.  This identifier is copied
                the corresponding reply and can be used by the requester
                to match up replies to outstanding queries.

It should say:

ID              A 16 bit identifier assigned by the program that
                generates any kind of query.  This identifier is copied
                to the corresponding reply and can be used by the
		requester to match up replies to outstanding queries.

Notes:

Alternative phrasing coule be "into the corresponding reply".

Errata ID: 6261
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Merlin Büge
Date Reported: 2020-08-23
Held for Document Update by: Warren Kumari (Ops AD)
Date Held: 2020-08-24

Section 4.1.1 says:

                                    1  1  1  1  1  1
      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                      ID                       |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |QR|   Opcode  |AA|TC|RD|RA|   Z    |   RCODE   |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    QDCOUNT                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    ANCOUNT                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    NSCOUNT                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    ARCOUNT                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

It should say:

                                    1  1  1  1  1  1
      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                      ID                       |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |QR|   OPCODE  |AA|TC|RD|RA|   Z    |   RCODE   |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    QDCOUNT                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    ANCOUNT                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    NSCOUNT                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    ARCOUNT                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Notes:

"OPCODE" is written in all-caps throughout this document.

Errata ID: 6262
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Merlin Büge
Date Reported: 2020-08-23
Held for Document Update by: Warren Kumari (Ops AD)
Date Held: 2020-08-24

Section 4.1.1 says:

OPCODE          A four bit field that specifies kind of query in this
                message.  This value is set by the originator of a query
                and copied into the response.  The values are:

It should say:

OPCODE          A four bit field that specifies the kind of query in
                this message.  This value is set by the originator of a
                query and copied into the response.  The values are:

Notes:

[WK]: Added 'the' in 'specifies kind of query'...

RFC 1042, "Standard for the transmission of IP datagrams over IEEE 802 networks", February 1988

Source of RFC: Legacy
Area Assignment: int

Errata ID: 1329
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Taunton
Date Reported: 2008-02-25
Held for Document Update by: Brian Haberman

Section Frame Format says:

      The minimum packet size used with ARP is 24 octets, which is 20
      (ARP with 2 octet hardware addresses and 4 octet protocol
      addresses) + 8 (LLC+SNAP header) = 24 octets (not including the
      MAC header).

It should say:

      The minimum packet size used with ARP is 28 octets, which is 20
      (ARP with 2 octet hardware addresses and 4 octet protocol
      addresses) + 8 (LLC+SNAP header) = 28 octets (not including the
      MAC header).

Errata ID: 1330
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Taunton
Date Reported: 2008-02-25
Held for Document Update by: Brian Haberman

Section Frame Format says:

      In typical situations, the packet size used with ARP is 32 octets,
      which is 28 (ARP with 6 octet hardware addresses and 4 octet
      protocol addresses) + 8 (LLC+SNAP header) = 32 octets (not
      including the MAC header).

It should say:

      In typical situations, the packet size used with ARP is 36 octets,
      which is 28 (ARP with 6 octet hardware addresses and 4 octet
      protocol addresses) + 8 (LLC+SNAP header) = 36 octets (not
      including the MAC header).

Notes:

Further instance of arithmetic error, previously reported in the preceding paragraph.

RFC 1055, "Nonstandard for transmission of IP datagrams over serial lines: SLIP", June 1988

Source of RFC: Legacy
Area Assignment: int

Errata ID: 4619
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Bradshaw
Date Reported: 2016-02-16
Held for Document Update by: Brian Haberman
Date Held: 2016-04-05

Section ABSTRACT says:

The TCP/IP protocol family runs over a variety of network media:
IEEE 802.3 (ethernet) and 802.5 (token ring) LAN's, X.25 lines,
satellite links, and serial lines.  There are standard encapsulations
for IP packets defined for many of these networks, but there is no
standard for serial lines.  SLIP, Serial Line IP, is a currently a de
facto standard, commonly used for point-to-point serial connections
running TCP/IP.  It is not an Internet standard.  Distribution of
this memo is unlimited.

It should say:

The TCP/IP protocol family runs over a variety of network media:
IEEE 802.3 (ethernet) and 802.5 (token ring) LAN's, X.25 lines,
satellite links, and serial lines.  There are standard encapsulations
for IP packets defined for many of these networks.  SLIP, Serial
Line IP, is commonly used for point-to-point serial connections
running TCP/IP. Distribution of this memo is unlimited.

Notes:

Status is INTERNET STANDARD however the title says it's non-standard and the abstract says "not a standard".

An update could also refer to PPP as a standard... I've removed the line saying there is no standard for serial lines.

RFC 1071, "Computing the Internet checksum", September 1988

Note: This RFC has been updated by RFC 1141

Source of RFC: Legacy
Area Assignment: int

Errata ID: 3133
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: chenhaospark
Date Reported: 2012-02-23
Held for Document Update by: Brian Haberman

Section 4.1 says:

           /*  Add left-over byte, if any */
       if( count > 0 )
               sum += * (unsigned char *) addr;

It should say:

           /*  Add left-over byte, if any */
       if( count > 0 )  {
               unsigned short left_over = 0;
               * (unsigned char *) &left_over = * (unsigned char *) addr;
               sum += left_over;
       }

Notes:

for big-endian

RFC 1122, "Requirements for Internet Hosts - Communication Layers", October 1989

Note: This RFC has been updated by RFC 1349, RFC 4379, RFC 5884, RFC 6093, RFC 6298, RFC 6633, RFC 6864, RFC 8029, RFC 9293

Source of RFC: Legacy
Area Assignment: int

Errata ID: 1740
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hannes Hennig
Date Reported: 2009-03-24
Held for Document Update by: Brian Haberman

Section 2.5 says:

                                                  |       | | | |S| |
                                                  |       | | | |H| |F
                                                  |       | | | |O|M|o
                                                  |       | |S| |U|U|o
                                                  |       | |H| |L|S|t
                                                  |       |M|O| |D|T|n
                                                  |       |U|U|M| | |o
                                                  |       |S|L|A|N|N|t
                                                  |       |T|D|Y|O|O|t
FEATURE                                           |SECTION| | | |T|T|e
--------------------------------------------------|-------|-|-|-|-|-|--

It should say:

                                                  |       | | | |S| |
                                                  |       | | | |H| |
                                                  |       | | | |O|M|F
                                                  |       | |S| |U|U|o
                                                  |       | |H| |L|S|o
                                                  |       |M|O| |D|T|t
                                                  |       |U|U|M| | |n
                                                  |       |S|L|A|N|N|o
                                                  |       |T|D|Y|O|O|t
FEATURE                                           |SECTION| | | |T|T|e
--------------------------------------------------|-------|-|-|-|-|-|--

Same on section 3.5 and 4.2.5.

Notes:

Footnote instead of "Footnotte" in eighth column.

Errata ID: 1936
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Thorsten Ulbricht
Date Reported: 2009-10-30
Held for Document Update by: Brian Haberman

Section 4.2.3.5 says:

            (d)  TCP SHOULD inform the application of the delivery
                 problem (unless such information has been disabled by
                 the application; see Section 4.2.4.1), when R1 is
                 reached and before R2.  This will allow a remote login
                 (User Telnet) application program to inform the user,
                 for example.

It should say:

            (e)  TCP SHOULD inform the application of the delivery
                 problem (unless such information has been disabled by
                 the application; see Section 4.2.4.1), when R1 is
                 reached and before R2.  This will allow a remote login
                 (User Telnet) application program to inform the user,
                 for example.

Notes:

The paragraph numbering got out of sequence. Letter (d) was used twice.

Errata ID: 4464
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Welzl
Date Reported: 2015-09-04
Held for Document Update by: Brian Haberman
Date Held: 2015-09-14

Section 4.2.4.2 says:

            It not required, but the application SHOULD be able to
            change the TOS during the connection lifetime.  TCP SHOULD

It should say:

            It is not required, but the application SHOULD be able to
            change the TOS during the connection lifetime.  TCP SHOULD

Notes:

just a typo (missing "is" as second word)

Errata ID: 4778
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sanjeev Ranot
Date Reported: 2016-08-18
Held for Document Update by: Martin Duke
Date Held: 2021-01-08

Section 4.2.3.4 says:

(3) or if at least a fraction Fs of the maximum window
    can be sent, i.e., if:
        [SND.NXT = SND.UNA and]

                min(D.U) >= Fs * Max(SND.WND);

It should say:

(3) or if at least a fraction Fs of the maximum window
    can be sent, i.e., if:
        [SND.NXT = SND.UNA and]

                min(D,U) >= Fs * Max(SND.WND);

Notes:

correct min(D.U) to min(D,U)

Errata ID: 5033
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eric Gray
Date Reported: 2017-06-08
Held for Document Update by: Eric Vyncke
Date Held: 2024-01-12

Section 2.3.2 says:

Section 2.3.2, and subsections 2.3.2.1 and 2.3.2.2, do not belong where 
they are in this RFC.

It should say:

Move the text in this section either under section 2.4, or in section 
3.

Notes:

ARP is a protocol used by Internet devices for the purpose of mapping Internet Addresses to MAC addresses. Link layer devices and associated protocols will only support and/or use ARP to the extent that they are also Internet devices (for example if participating in management protocols developed to operate between IP addressed devices).

Hence referring to ARP as a Link Layer Protocol will only continue to confuse the industry.

Because the number of references to ARP refering to Link.2, perhaps it would be easiest to move the text to section 2.4, adding a new subsection header 2.4.1 for the text currently in section 2.4, and renumbering current section 2.3.2 to 2.4.2 (as well as renumbering subsections 2.3.2.1 and 2.3.2.2 to 2.4.2.1 and 2.4.2.2, respectively).

Refering to ARP as a part of the Link/Internet Layer Interface is more accurate.

-- Verifier Note (EV) --

The erratum is correct, i.e., ARP is not a layer-2 protocol. The erratum reflects more the modern thinking though of ARP position in the OSI stack and does not impact the protocol itself.

Therefore, the status if "held for document update" even of RFC 1122 will probably never be updated in the world of NDP and IPv6.

Errata ID: 7507
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Antonio Cota
Date Reported: 2023-05-04
Held for Document Update by: Eric Vyncke
Date Held: 2023-08-03

Section 1.2 says:

 There are two important lessons that vendors of Internet host
 software have learned and which a new vendor should consider
 seriously.

It should say:

 There are four important lessons that vendors of Internet host
 software have learned and which a new vendor should consider
 seriously.

Notes:

I'm suggesting to replace "two" with "four" because below the 1.2 section there are 4 subsections (1.2.1, 1.2.2, 1.2.3 and 1.2.4) which lead to think that there are 4 "important lessons".

RFC 1138, "Mapping between X.400(1988) / ISO 10021 and RFC 822", December 1989

Note: This RFC has been obsoleted by RFC 2156, RFC 1327

Note: This RFC has been updated by RFC 1148

Source of RFC: Legacy

Errata ID: 6535
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Juli Mallett
Date Reported: 2021-04-13
Held for Document Update by: Benjamin Kaduk
Date Held: 2021-04-15

Throughout the document, when it says:

   4.7  IPMS Mappings ....... .................................   48

It should say:

   4.7  IPMS Mappings .........................................   48

Notes:

Space vs. punctuation.

RFC 1141, "Incremental updating of the Internet checksum", January 1990

Note: This RFC has been updated by RFC 1624

Source of RFC: Legacy
Area Assignment: int

Errata ID: 2102
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alexander Zimmermann
Date Reported: 2010-04-01
Held for Document Update by: Brian Haberman

Section Header says:

Network Working Group
Request for Comments: 1141
Obsoletes: RFC 1071

It should say:

Network Working Group
Request for Comments: 1141
Updates: RFC 1071

Notes:

The RFC-Editor said RFC 1141 updates and does not obsolete RFC 1071.

Errata ID: 6350
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Shu Xiao
Date Reported: 2020-12-08
Held for Document Update by: Eric Vyncke
Date Held: 2021-01-28

Section Description says:

ipptr->Checksum = (sum + (sum>>16)) /* add carry */

It should say:

ipptr->Checksum = (sum + (sum>>16)); /* add carry */

Notes:

There is a ";" missing at the end of code line, before comments.

RFC 1148, "Mapping between X.400(1988) / ISO 10021 and RFC 822", March 1990

Note: This RFC has been obsoleted by RFC 2156, RFC 1327

Source of RFC: Legacy

Errata ID: 6536
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Juli Mallett
Date Reported: 2021-04-13
Held for Document Update by: Benjamin Kaduk
Date Held: 2021-04-15

Throughout the document, when it says:

   4.7  IPMS Mappings ....... .................................   48

It should say:

   4.7  IPMS Mappings .........................................   48

Notes:

Space vs punctuation.

RFC 1180, "TCP/IP tutorial", January 1991

Source of RFC: Legacy
Area Assignment: int

Errata ID: 3456
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: John Morley
Date Reported: 2013-01-15
Held for Document Update by: Brian Haberman

Section 5.4 says:

The portion of the address that is used for network number and for
host number is defined by the upper bits in the 4-byte address.  All
example IP addresses in this tutorial are of type class C, meaning
that the upper 3 bits indicate that 21 bits are the network number
and 8 bits are the host number.  This allows 2,097,152 class C
networks up to 254 hosts on each network.

It should say:

The portions of the address that are used as network number and as
host number are defined by the netmask. All example IP addresses in
this tutorial are of type class C and have a netmask of 255.255.255.0,
meaning that the first three bytes (24 bits) represent the network
number and the last eight bits the host number. This allows 16,777,216
class C networks with up to 254 hosts on each network.

Notes:

The concept of IP address loses much of its meaning if the value of the
netmask is ignored. The paragraph as originally written doesn't make
sense, in particular "the upper 3 bits indicate that 21 bits are the network
number".

Errata ID: 4587
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Masoud Valizadeh
Date Reported: 2016-01-10
Held for Document Update by: Brian Haberman
Date Held: 2016-01-15

Section 2.2 says:

and if it is in a network application it is called 
a application message.

It should say:

and if it is in a network application it is called 
an application message.

Errata ID: 4590
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Masoud Valizadeh
Date Reported: 2016-01-10
Held for Document Update by: Brian Haberman
Date Held: 2016-01-15

Section 2.4 says:

It is seen from this structure that for computers with more than one
physical network interface, the IP module is both a n-to-m multiplexer 
and an m-to-n de-multiplexer.

It should say:

It is seen from this structure that for computers with more than one
physical network interface, the IP module is both an n-to-m multiplexer 
and an m-to-n de-multiplexer.

Errata ID: 4591
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Masoud Valizadeh
Date Reported: 2016-01-10
Held for Document Update by: Brian Haberman
Date Held: 2016-01-15

Section 3.1 says:

Each person has an unique name

It should say:

Each person has a unique name

RFC 1183, "New DNS RR Definitions", October 1990

Note: This RFC has been updated by RFC 5395, RFC 5864, RFC 6195, RFC 6895

Source of RFC: Legacy
Area Assignment: int

Errata ID: 1478
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Justin Pryzby
Date Reported: 2008-07-23
Held for Document Update by: Brian Haberman

Section 2 says:

you can discover it's Internet address

It should say:

you can discover its Internet address

Notes:

should be possessive not contractive.

RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual environments", December 1990

Note: This RFC has been updated by RFC 1349, RFC 5302, RFC 5304

Source of RFC: Legacy
Area Assignment: rtg

Errata ID: 683
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Joerg Ammon
Date Reported: 2003-03-04
Held for Document Update by: Stewart Bryant

Section 3.3 says:

In chapter '3.3 Addressing Routers in ISIS Packets' the RFC describes a
standard procedure
for deriving NSAP-addresses for IS in IP-only environments. However, the
DFI as well as the AA
are defined to be 'xx' and 'xx xx xx' respectively, which represents
neither a valid decimal nor
hexadecimal value.

It should say:

[not submitted]

Notes:

from pending

Errata ID: 3741
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jeffrey Zhang
Date Reported: 2013-10-01
Held for Document Update by: Adrian Farrel
Date Held: 2013-10-19

Section 5.3.5 says:

5.3.5 Level 2 Link State PDU
    ...
    IP Internal Reachability Information -- IP addresses within the
    routing domain reachable directly via one or more interfaces on
    this Intermediate system.

It should say:

    IP Internal Reachability Information -- IP addresses within the
    routing domain reachable directly via one or more interfaces on
    this Intermediate system, or indirectly via level 1 routing.
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Notes:

Currently, the relevant text in 5.3.2 and 5.3.5 are identical, but the 5.3.5 text should have the above text added.

This would match the following (see the last clause):

5.2 Overview of IP-Specific Information for IS-IS

The "IP Internal Reachability Information" field ...
If included in level 1 LSPs,
this field includes only entries directly reachable by the router
which originates the LSP, via one of its interfaces. If included in
level 2 LSPs, this field includes only entries reachable by the
router which originates the LSP, either via one of its interfaces, or
indirectly via level 1 routing.


I have marked this report as "held for document update" although I do not expect any new revision to RFC 1195. This "correction" is more of a clarification. The "corrected" text can be successfully deduced from the rest of the document such that nobody reading the document in its entirety would be led to make an incorrect and/or non-interoperable implementation.

Furthermore, any clarifications necessary have previously been published in the informational RFCs 3719 and in particular 3787.

However, there is some value in retaining this record for future enquiring minds (and to stop a similar report being raised in the future).

RFC 1320, "The MD4 Message-Digest Algorithm", April 1992

Note: This RFC has been obsoleted by RFC 6150

Source of RFC: pem (sec)

Errata ID: 3131
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sergey Panasenko
Date Reported: 2012-02-20
Held for Document Update by: Sean Turner

Section 3.4 says:

Note. The value 5A..99 is a hexadecimal 32-bit constant, written with
the high-order digit first. This constant represents the square root
of 2. The octal value of this constant is 013240474631.

The value 6E..A1 is a hexadecimal 32-bit constant, written with the
high-order digit first.  This constant represents the square root of
3. The octal value of this constant is 015666365641.

It should say:

Note. The value 5A..99 is a hexadecimal 32-bit constant, written with
the high-order digit first. This constant represents the square root
of 2 divided by 4. The octal value of this constant is 013240474631.

The value 6E..A1 is a hexadecimal 32-bit constant, written with the
high-order digit first.  This constant represents the square root of
3 divided by 4. The octal value of this constant is 015666365641.

Notes:

More precisely, the value 5A..99 is a result of the formula: HEX(TRUNC((SQRT(2)/4)*2^32)), where SQRT represents the square root, TRUNC is truncation of the fractional part, HEX is a hexadecimal representation. Similarly, the value 6E..A1 = HEX(TRUNC((SQRT(3)/4)*2^32)).

RFC 1321, "The MD5 Message-Digest Algorithm", April 1992

Note: This RFC has been updated by RFC 6151

Source of RFC: pem (sec)

Errata ID: 6193
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: User
Date Reported: 2020-05-29
Held for Document Update by: Paul Wouters
Date Held: 2024-01-12

Section A.4 says:

  printf
 ("Speed = %ld bytes/second\n",
  (long)TEST_BLOCK_LEN * (long)TEST_BLOCK_COUNT/(endTime-startTime));

It should say:

 if(endTime-startTime)
 printf
 ("Speed = %ld bytes/second\n",
  (long)TEST_BLOCK_LEN * (long)TEST_BLOCK_COUNT/(endTime-startTime));

Notes:

The result of endTime-startTime may be zero. The result is a division by zero. This check prevents this.

AD Note: Technically endTime-startTime is not a bool, so a better fix would be:
if ((endTime-startTime) !=0)

RFC 1322, "A Unified Approach to Inter-Domain Routing", May 1992

Source of RFC: bgp (rtg)

Errata ID: 1434
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2008-06-07
Held for Document Update by: Ross Callon

Section 3.3.1 says:

[Footnote: Although a domain's selection policies are not
   explicitly distributed, they have an impact on the routes available
   to other domains.  A route that may be preferred by a particular
   domain, and not prohibited by transit restrictions, may still be
   unavailable due to the selection policies of some intermediate
   domain.  The ability to compute and install alternative routes that
   may be lost using hop-by-hop routing (either LS of PV) is the
   critical functionality provided by SDR.].

It should say:

[Footnote: Although a domain's selection policies are not
   explicitly distributed, they have an impact on the routes available
   to other domains.  A route that may be preferred by a particular
   domain, and not prohibited by transit restrictions, may still be
   unavailable due to the selection policies of some intermediate
   domain.  The ability to compute and install alternative routes that
   may be lost using hop-by-hop routing (either LS or PV) is the
   critical functionality provided by SDR.].

RFC 1323, "TCP Extensions for High Performance", May 1992

Note: This RFC has been obsoleted by RFC 7323

Source of RFC: tcplw (tsv)

Errata ID: 4346
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Niels Laukens
Date Reported: 2015-04-24
Held for Document Update by: Martin Stiemerling
Date Held: 2015-10-01

Section 2.3 says:

      Since the max window is 2**S (where S is the scaling shift count)
      times at most 2**16 - 1 (the maximum unscaled window), the maximum
      window is guaranteed to be < 2*30 if S <= 14.  Thus, the shift
      count must be limited to 14 (which allows windows of 2**30 = 1
      Gbyte).  If a Window Scale option is received with a shift.cnt
      value exceeding 14, the TCP should log the error but use 14
      instead of the specified value.

It should say:

      Since the max window is 2**S (where S is the scaling shift count)
      times at most 2**16 - 1 (the maximum unscaled window), the maximum
      window is guaranteed to be < 2**30 if S <= 14.  Thus, the shift
      count must be limited to 14 (which allows windows of 2**30 = 1
      Gbyte).  If a Window Scale option is received with a shift.cnt
      value exceeding 14, the TCP should log the error but use 14
      instead of the specified value.

Notes:

Typo in the 3rd line: the window should be less than 2 to the power of 30, instead of 2 multiplied by 30.

Errata ID: 2278
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2010-05-19
Held for Document Update by: Wes Eddy

Section 1.1 says:

           Section 4 introduces a new TCP option, "Timestamps", and then
           defines a mechanism using this option that allows nearly
           every segment, including retransmissions, to be timed at
           negligible computational cost.  We use the mnemonic RTTM
           (Round Trip Time Measurement) for this mechanism, to
           distinguish it from other uses of the Timestamps option.

It should say:

           Section 3.2 introduces a new TCP option, "Timestamps", and then
           defines a mechanism using this option that allows nearly
           every segment, including retransmissions, to be timed at
           negligible computational cost.  We use the mnemonic RTTM
           (Round Trip Time Measurement) for this mechanism, to
           distinguish it from other uses of the Timestamps option.

Notes:

Incorrect reference to Section 4.

RFC 1345, "Character Mnemonics and Character Sets", June 1992

Source of RFC: 822ext (app)

Errata ID: 4272
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Harald Grumser
Date Reported: 2015-02-16
Held for Document Update by: Barry Leiba
Date Held: 2015-03-01

Section 5 says:

&charset ISO_8859-1:1987
...
NS !I Ct Pd Cu Ye BB SE ': Co -a << NO -- Rg '-

It should say:

&charset ISO_8859-1:1987
...
NS !I Ct Pd Cu Ye BB SE ': Co -a << NO -- Rg 'm

Notes:

Mnemonic '- (U+203E OVERLINE) should read 'm (U+00AF MACRON) here and in most other occurences of this mnemonic.

----- Verifier Notes -----
While this is correct as far as it goes -- that 'm is a better choice of mnemonic than '- is -- it is not appropriate as an erratum, because, for better or worse, the text that's there is what was intended when it was written. And as it stands, it doesn't really matter, as no one uses RFC 1345 any more, and hasn't for years. It's unlikely that an update will ever be done, but if one is, that's the time to make this correction throughout the document.

Errata ID: 2813
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-05-22
Held for Document Update by: Pete Resnick

Section 4 says:

   The character mnemonics hav been used to table a number of coded
   character sets.

It should say:

   The character mnemonics have been used to table a number of coded
   character sets.

Notes:

s/hav/have: a typo

Errata ID: 6074
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Philip Børgesen
Date Reported: 2020-04-01
Held for Document Update by: Barry Leiba
Date Held: 2020-04-03

Section 5 says:

  &charset IBM1026
  &rem source: IBM NLS RM Vol2 SE09-8002-01, March 1990
  &alias CP1026
  &code 0
  NU SH SX EX ET EQ AK BL BS HT LF VT FF CR SO SI
  DL D1 D2 D3 D4 NK SY EB CN EM SB EC FS GS RS US
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  SP NS a> a: a! a' a? aa (! n? C, .  <  (  +  !
  &  e' e> e: e! i' i> i: i! ss G( I. *  )  ;  '>
  -  /  A> A: A! A' A? AA <( N? s, ,  %  _  >  ?
  o/ E' E> E: E! I' I> I: I! i. :  O: S, '  =  U:
  O/ a  b  c  d  e  f  g  h  i  << >> !) '! BB +-
  DG j  k  l  m  n  o  p  q  r  -a -o ae '; AE Cu
  My o: s  t  u  v  w  x  y  z  !I ?I )> DO At Rg
  Ct Pd Ye .M Co SE PI 14 12 34 NO !! -M ': '' *X
  c, A  B  C  D  E  F  G  H  I  -- o> '? o! o' o?
  g( J  K  L  M  N  O  P  Q  R  1S u> // u! u' y:
  u: -: S  T  U  V  W  X  Y  Z  2S O> Nb O! O' O?
  0  1  2  3  4  5  6  7  8  9  3S U> "  U! U' DT

It should say:

  &charset IBM1026
  &rem source: IBM NLS RM Vol2 SE09-8002-01, March 1990
  &rem source: IBM Corporate Standard, C-S 3-3220-002
  &alias CP1026
  &code 0
  NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
  DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
  __ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
  ?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB
  SP NS a> a: a! a' a? aa (! n? C, .  <  (  +  !
  &  e' e> e: e! i' i> i: i! ss G( I. *  )  ;  '>
  -  /  A> A: A! A' A? AA <( N? s, ,  %  _  >  ?
  o/ E' E> E: E! I' I> I: I! i. :  O: S, '  =  U:
  O/ a  b  c  d  e  f  g  h  i  << >> !) '! BB +-
  DG j  k  l  m  n  o  p  q  r  -a -o ae '; AE Cu
  My o: s  t  u  v  w  x  y  z  !I ?I )> DO At Rg
  Ct Pd Ye .M Co SE PI 14 12 34 NO !! -M ': '' *X
  c, A  B  C  D  E  F  G  H  I  -- o> '? o! o' o?
  g( J  K  L  M  N  O  P  Q  R  1S u> // u! u' y:
  u: -: S  T  U  V  W  X  Y  Z  2S O> Nb O! O' O?
  0  1  2  3  4  5  6  7  8  9  3S U> "  U! U' __
  &duplicate 1F __

Notes:

The EBCDIC character sets do not use the ASCII control codes.
Based on [1] the EBCDIC control codes located at hex 00-3F are

NU SH SX EX __ HT __ DT __ __ __ VT FF CR SO SI
DL D1 D2 D3 __ NL BS __ CN EM __ __ FS GS RS US
__ __ __ __ __ LF EB EC __ __ __ __ __ EQ AK BL
?? ?? SY __ __ __ __ ET __ __ __ __ D4 NK ?? SB

with __ marking control codes with no ISO 10646 mapping.
The control code at hex 1F can depending on context either mean "Interchange Unit Separator" or "Intermediate Transmission Block" but only the prior has an ISO 10646 mapping (mnemonic US). The "&duplicate 1F __" part marks the alternative character with no available mapping. Note that in EBCDIC the "Delete" character is located at hex 07 while hex FF is "Eight Ones", another character with no ISO 10646 equivalent.

References:
[1]: IBM Corporate Standard, C-S 3-3220-002 (May 1990) -- archived IBM excerpt available at https://web.archive.org/web/20180911044845/https://www-01.ibm.com/software/globalization/cdra/appendix_g1.html

RFC 1350, "The TFTP Protocol (Revision 2)", July 1992

Note: This RFC has been updated by RFC 1782, RFC 1783, RFC 1784, RFC 1785, RFC 2347, RFC 2348, RFC 2349

Source of RFC: Legacy
Area Assignment: app

Errata ID: 1712
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Andy
Date Reported: 2009-03-11
Held for Document Update by: Alexey Melnikov

Section 3 says:

Acknowlegements

It should say:

Acknowledgements

RFC 1365, "An IP Address Extension Proposal", September 1992

Source of RFC: Legacy
Area Assignment: int

Errata ID: 3041
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Dean Swift
Date Reported: 2011-12-07
Held for Document Update by: Brian Haberman

Section 2 says:

   Class F-8G has the seven higher order bits set to 1111110, a 49 bit
   network number and a 8 bit host address.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|1|1|1|1|0|              net number                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 net number                    |  local part   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

   Class F-8G has the seven higher order bits set to 1111110, a 49 bit
   network number and a 8 bit host address.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|1|1|1|1|1|0|            net number                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 net number                    |  local part   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

Remaining bit patterns are unspecified but assumed to be reserved for future definition.

RFC 1459, "Internet Relay Chat Protocol", May 1993

Note: This RFC has been updated by RFC 2810, RFC 2811, RFC 2812, RFC 2813, RFC 7194

Source of RFC: Legacy
Area Assignment: app

Errata ID: 3355
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stephen Chavez
Date Reported: 2012-09-15
Held for Document Update by: Barry Leiba

Section 4.4.1 says:

The <receiver> parameter may also me a host mask  (#mask)  or  server
   mask  ($mask).  

It should say:

The <receiver> parameter may also be a host mask  (#mask)  or  server
   mask  ($mask).  

Errata ID: 3414
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kezhu Wang
Date Reported: 2012-11-25
Held for Document Update by: Barry Leiba

Section 4.1.3 says:

The USER message is used at the beginning of connection to specify
the username, hostname, servername and realname of s new user.

It should say:

The USER message is used at the beginning of connection to specify
the username, hostname, servername and realname of a new user.

Errata ID: 3938
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Myunggyun Jonathan Aldo Seo
Date Reported: 2014-03-28
Held for Document Update by: Barry Leiba
Date Held: 2014-05-07

Section 4.2.3.1 says:

   When using the 'o' and 'b' options, a restriction on a total of three
   per mode command has been imposed.  That is, any combination of 'o'
   and

It should say:

   When using the 'o' and 'b' options, a restriction on a total of three
   per mode command has been imposed.

Notes:

The sentence lacks the last part and does not explain what it expected to. The change removes the incomplete, useless sentence.

Errata ID: 4854
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Chase Smith
Date Reported: 2016-11-04
Held for Document Update by: Barry Leiba
Date Held: 2019-04-30

Section 6.2 says:

To reply to a NAMES message, a reply pair consisting
of RPL_NAMREPLY and RPL_ENDOFNAMES is sent by the
server back to the client.  If there is no channel
found as in the query, then only RPL_ENDOFNAMES is
returned.  The exception to this is when a NAMES
message is sent with no parameters and all visible
channels and contents are sent back in a series of
RPL_NAMEREPLY messages with a RPL_ENDOFNAMES to mark
the end.

It should say:

To reply to a NAMES message, a reply pair consisting
of RPL_NAMREPLY and RPL_ENDOFNAMES is sent by the
server back to the client.  If there is no channel
found as in the query, then only RPL_ENDOFNAMES is
returned.  The exception to this is when a NAMES
message is sent with no parameters and all visible
channels and contents are sent back in a series of
RPL_NAMREPLY messages with a RPL_ENDOFNAMES to mark
the end.

Notes:

RPL_NAMEREPLY does not exist anywhere else in the document, while RPL_NAMREPLY is used 4 times. This is likely a typo.

----- Verifier Notes -----
One of them is clearly a typo, but a little research shows that implementations differ as to which one they use. Best that this be revisited in the unlikely event that the spec is ever revised.

Errata ID: 5291
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Matías Fachal
Date Reported: 2018-03-20
Held for Document Update by: Barry Leiba
Date Held: 2019-04-30

Section 2.2 says:

Because of IRC's scandanavian origin, the characters {}| are
   considered to be the lower case equivalents of the characters []\,
   respectively.

It should say:

Because of IRC's scandinavian origin, the characters {}| are
   considered to be the lower case equivalents of the characters []\,
   respectively.

Notes:

The demonym for those of the Scandinavian region is "Scandinavian", not "Scandanavian", as far as I know.

RFC 1464, "Using the Domain Name System To Store Arbitrary String Attributes", May 1993

Source of RFC: Legacy

Errata ID: 5194
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Victor Toni
Date Reported: 2017-12-03
Held for Document Update by: Warren Kumari (Ops AD)
Date Held: 2017-12-06

Section 2. says:

   a=a          true            a`=a=true               "a`=a=true"
   a\=a false           a\`=a=false             "a\\`=a=false"

It should say:

   a=a          true            a`=a=true               "a`=a=true"
   a\=a         false           a\`=a=false             "a\\`=a=false"

Notes:

The second line needs an adjustment so that it aligns with the other lines.

RFC 1524, "A User Agent Configuration Mechanism For Multimedia Mail Format Information", September 1993

Source of RFC: Legacy

Errata ID: 5647
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Urs Janßen
Date Reported: 2019-03-08
Held for Document Update by: Benjamin Kaduk
Date Held: 2019-03-10

Section Appendix A says:

   The two characters "%s", if used, will be replaced by the name of a
   file for the actual mail body data.  In the case of the edit adn
   view-command, the body part will be passed to this command as
   standard input unless one or more instances of "%s" appear in the
   view-command, in which case %s will be replaced by the name of a file
   containing the body part, a file which may have to be created before
   the view-command program is executed.

It should say:

   The two characters "%s", if used, will be replaced by the name of a
   file for the actual mail body data.  In the case of the edit and
   view-command, the body part will be passed to this command as
   standard input unless one or more instances of "%s" appear in the
   view-command, in which case %s will be replaced by the name of a file
   containing the body part, a file which may have to be created before
   the view-command program is executed.

Notes:

Typo in "Appendix A; Semantics of executable commands; 3rd paragraph";
adn vs. and

RFC 1535, "A Security Problem and Proposed Correction With Widely Deployed DNS Software", October 1993

Source of RFC: Legacy
Area Assignment: int

Errata ID: 1084
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Justin Pryzby
Date Reported: 2007-11-27
Held for Document Update by: Sean Turner

Section Public vs... says:

   it it is possible to "intercept" the search by matching against an

It should say:

   it is possible to "intercept" the search by matching against an

Errata ID: 1085
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Justin Pryzby
Date Reported: 2007-11-27
Held for Document Update by: Brian Haberman

Section Solution(s) says:

starburst,astro.DESERTU.EDU,

It should say:

starburst.astro.DESERTU.EDU,

(only 90% sure about this change)

RFC 1633, "Integrated Services in the Internet Architecture: an Overview", June 1994

Source of RFC: Legacy
Area Assignment: tsv

Errata ID: 2272
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: jonsimchol
Date Reported: 2010-05-18
Held for Document Update by: Wes Eddy

Section 5.1.3 says:

Although receiver-initiated reservation is the natural choice
         for multicast sessions, the justification for receiver
         initiateion may appear weaker for unicast sessions, where the
         sender may be the logical session initiator.

It should say:

Although receiver-initiated reservation is the natural choice
         for multicast sessions, the justification for receiver
         initiation may appear weaker for unicast sessions, where the
         sender may be the logical session initiator.

Notes:

initiateion -> initiation

Errata ID: 2273
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: jonsimchol
Date Reported: 2010-05-18
Held for Document Update by: Wes Eddy

Section 5.1.3 says:

RSVP uses receiver-initiation of rservations [RSVP93b].  A
         receiver is assumed to learn the senders' offered flowspecs by
         a higher-level mechanism ("out of band"), it then generates its
         own desired flowspec and propagates it towards the senders,
         making reservations in each router along the way.

It should say:

RSVP uses receiver-initiation of reservations [RSVP93b].  A
         receiver is assumed to learn the senders' offered flowspecs by
         a higher-level mechanism ("out of band"), it then generates its
         own desired flowspec and propagates it towards the senders,
         making reservations in each router along the way.

Notes:

rservations -> reservations

RFC 1712, "DNS Encoding of Geographical Location", November 1994

Source of RFC: Legacy
Area Assignment: int

Errata ID: 541
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: "Coleman, Arthur"
Date Reported: 2006-03-09
Held for Document Update by: Brian Haberman

Section 3 says:

the definitions for Latitude and Longitude are swapped.

I believe this can be considered a typo as the actual values in the
resource record can (and should) be kept in their current order.=20

The correct descriptions are (in general terms):=20
    Latitude is the degrees North or South of the Equator and can be
referenced with a range of -90 to +90.=20
    Longitude is the degrees East or West of the prime meridian and can
be referenced with a range of -180 to +180.

Below is my attempt to write the errata.  If someone wants to make
suggestion about how the errata should be written, please tell me and I
will make a go at doing it as requested.

    Art Coleman   acoleman@verisign.com


In RFC 1712 the terms Latitude and Longitude are swapped in that each
was given the other's definition. =20
Also the preferred order of the terms is Latitude then Longitude.  In
addition to matching the terms with their correct definitions, this
ordering is also addressed.

In Section 3, page 3 is a table, it says:

        MSB                                        LSB=20
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+=20
        /                 LONGITUDE                  /=20
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+=20
        /                  LATITUDE                  /=20
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+=20
        /                  ALTITUDE                  /=20
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

It should say:

        MSB                                        LSB=20
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+=20
        /                  LATITUDE                  /=20
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+=20
        /                 LONGITUDE                  /=20
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+=20
        /                  ALTITUDE                  /=20
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Rational: It is only the terms that are being corrected, the value
ranges associated with the first (-90..90) and second (-180..180)
arguments are in the preferred order.


In Section 3, page 3 under 'where:', it says:

   LONGITUDE The real number describing the longitude encoded as a=20
             printable string. The precision is limited by 256 charcters

             within the range -90..90 degrees. Positive numbers=20
             indicate locations north of the equator.

   LATITUDE The real number describing the latitude encoded as a=20
            printable string. The precision is limited by 256 charcters=20
            within the range -180..180 degrees. Positive numbers=20
            indicate locations east of the prime meridian.

Is should say:

   LATITUDE The real number describing the latitude encoded as a=20
            printable string. The precision is limited by 256 characters

            within the range -90..90 degrees. Positive numbers=20
            indicate locations north of the equator.

   LONGITUDE The real number describing the longitude encoded as a=20
             printable string. The precision is limited by 256
characters=20
             within the range -180..180 degrees. Positive numbers=20
             indicate locations east of the prime meridian.

Rational: to match the terms with their correct definitions, and fix the
spelling of the word 'characters'.


In Section 4, page 3, it says:

   GPOS has the following format:=20
           <owner> <ttl> <class> GPOS <longitude> <latitude> <altitude>

It should say:

   GPOS has the following format:=20
           <owner> <ttl> <class> GPOS <latitude> <longitude> <altitude>

Rational: It is only the terms that are being corrected, the value
ranges associated with the first (-90..90) and second (-180..180)
arguments are in the preferred order.


In Section 4, page 4, it says:

   The owner, ttl, and class fields are optional and default to the last

   defined value if omitted. The longitude is a floating point number=20
   ranging from -90 to 90 with positive values indicating locations=20
   north of the equator.  For example Perth, Western Australia is=20
   located at 32^ 7` 19" south of the equator which would be specified=20
   as -32.68820.  The latitude is a number ranging from -180.0 to 180.0.

   For example Perth, Western Australia is located at 116^ 2' 25" east=20
   of the prime meridian which would be specified as 116.86520.  Curtin=20
   University, Perth is also 10 meters above sea-level.

It should say:

   The owner, ttl, and class fields are optional and default to the last

   defined value if omitted. The latitude is a floating point number=20
   ranging from -90 to 90 with positive values indicating locations=20
   north of the equator.  For example Perth, Western Australia is=20
   located at 32^ 7` 19" south of the equator which would be specified=20
   as -32.68820.  The longitude is a number ranging from -180.0 to
180.0.=20
   For example Perth, Western Australia is located at 116^ 2' 25" east=20
   of the prime meridian which would be specified as 116.86520.  Curtin=20
   University, Perth is also 10 meters above sea-level.

Rational: to match the terms with their correct definitions.

Notes:

from pending

RFC 1774, "BGP-4 Protocol Analysis", March 1995

Source of RFC: idr (rtg)

Errata ID: 3794
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramakrishna DTV
Date Reported: 2013-11-10
Held for Document Update by: Stewart Bryant
Date Held: 2013-11-22

Section 2 says:

   To allow graceful coexistence with EGP and OSPF, BGP provides support
   for carrying both EGP and OSPF derived exterior routes BGP also
   allows to carry statically defined exterior routes or routes derived
   by other IGP information.

It should say:

   To allow graceful coexistence with EGP and OSPF, BGP provides support
   for carrying both EGP and OSPF derived exterior routes. BGP also
   allows to carry statically defined exterior routes or routes derived
   by other IGP information.

Notes:

This is a run-on sentence, missing ".".

RFC 1812, "Requirements for IP Version 4 Routers", June 1995

Note: This RFC has been updated by RFC 2644, RFC 6633

Source of RFC: rreq (rtg)

Errata ID: 2704
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jeffrey Smith
Date Reported: 2011-02-03
Held for Document Update by: Stewart Bryant

Section 4.3.3.6 says:

A router MUST be prepared to receive, reassemble and echo an ICMP Echo Request
datagram at least as the maximum of 576 and the MTUs of all the connected networks.

It should say:

A router MUST be prepared to receive, reassemble and echo an ICMP Echo Request
datagram at least as large as the maximum of 576 and the MTUs of all the
connected networks.

Errata ID: 5553
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stefan Marksteiner
Date Reported: 2018-11-15
Held for Document Update by: Alvaro Retana
Date Held: 2019-03-24

Section 4.3.3.4 says:

When a router is forwarding a packet and the TTL field of the packet
is reduced to 0, the requirements of section [5.2.3.8] apply.

It should say:

When a router is forwarding a packet and the TTL field of the packet
is reduced to 0, the requirements of section [5.3.1] apply.

RFC 1855, "Netiquette Guidelines", October 1995

Source of RFC: run ()

Errata ID: 6520
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Adrian Wong
Date Reported: 2021-04-07
Held for Document Update by: Lars Eggert
Date Held: 2021-04-08

Section 3.1.2 says:

... Although many many mailing ...

It should say:

... Although many mailing ...

Notes:

Doubled words

Errata ID: 6521
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Adrian Wong
Date Reported: 2021-04-07
Held for Document Update by: Lars Eggert
Date Held: 2021-04-08

Section 3.3.1 says:

Make sure your Frequestly Asked Questions (FAQ) ...

It should say:

Make sure your Frequently Asked Questions (FAQ) ...

Notes:

Typographical error

RFC 1865, "EDI Meets the Internet Frequently Asked Questions about Electronic Data Interchange (EDI) on the Internet", January 1996

Source of RFC: edi (app)

Errata ID: 6537
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Juli Mallett
Date Reported: 2021-04-01
Held for Document Update by: RFC Editor
Date Held: 2024-02-16

The Table of Contents says:

   5.1.  What is a VAN?  ................... .......................  18

It should say:

   5.1.  What is a VAN?  ...........................................  18

Notes:

I don't know what a VAN is, but we can replace a space here with a period.

RFC 1878, "Variable Length Subnet Table For IPv4", December 1995

Source of RFC: Legacy
Area Assignment: int

Errata ID: 3147
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Cyril Pain-Barre
Date Reported: 2012-03-06
Held for Document Update by: Brian Haberman

Throughout the document, when it says:

Subnet Mask     # of nets    Net. Addr.  Host Addr Range  Brodcast Addr.
Bits of Subnet  hosts/subnet

255.255.128.0   2 nets        N.N.0.0     N.N.0-127.N      N.N.127.255
1 bit subnet    32766         N.N.128.0   N.N.128-254.N    N.N.254.255

255.255.192.0   4 nets        N.N.0.0     N.N.0-63.N       N.N.63.255
2 bit subnet    16382         N.N.64.0    N.N.64-127.N     N.N.127.255
                              N.N.128.0   N.N.128-191.N    N.N.191.255
                              N.N.192.0   N.N.192-254.N    N.N.254.255

255.255.224.0   8 nets        N.N.0.0     N.N.0-31.N       N.N.31.255
3 bit subnet    8190          N.N.32.0    N.N.32-63.N      N.N.63.255
                              N.N.64.0    N.N.64-95.N      N.N.95.255
                              N.N.96.0    N.N.96-127.N     N.N.127.255
                              N.N.128.0   N.N.128-159.N    N.N.159.255
                              N.N.160.0   N.N.160-191.N    N.N.191.255
                              N.N.192.0   N.N.192-223.N    N.N.223.255
                              N.N.224.0   N.N.224-254.N    N.N.254.255

255.255.240.0   16 nets       N.N.0.0     N.N.0-15.N       N.N.15.255
4 bit subnet    4094          N.N.16.0    N.N.16-31.N      N.N.31.255
                              N.N.32.0    N.N.32-47.N      N.N.47.255
                              N.N.48.0    N.N.48-63.N      N.N.63.255
                              N.N.64.0    N.N.64-79.N      N.N.79.255
                              N.N.80.0    N.N.80-95.N      N.N.95.255
                              N.N.96.0    N.N.96-111.N     N.N.111.255
                              N.N.112.0   N.N.112-127.N    N.N.127.255
                              N.N.128.0   N.N.128-143.N    N.N.143.255
                              N.N.144.0   N.N.144-159.N    N.N.159.255
                              N.N.160.0   N.N.160-175.N    N.N.175.255
                              N.N.176.0   N.N.176-191.N    N.N.191.255
                              N.N.192.0   N.N.192-207.N    N.N.207.255
                              N.N.208.0   N.N.208-223.N    N.N.223.255
                              N.N.224.0   N.N.224-239.N    N.N.239.255
                              N.N.240.0   N.N.240-254.N    N.N.254.255

255.255.248.0   32 nets       N.N.0.0     N.N.0-7.N        N.N.7.255
5 bit subnet    2046          N.N.8.0     N.N.8-15.N       N.N.15.255
                              N.N.16.0    N.N.16-23.N      N.N.23.255
                              N.N.24.0    N.N.24-31.N      N.N.31.255
                              N.N.32.0    N.N.32-39.N      N.N.39.255
                              N.N.40.0    N.N.40-47.N      N.N.47.255
                              N.N.48.0    N.N.48-55.N      N.N.55.255
                              N.N.56.0    N.N.56-63.N      N.N.63.255
                              N.N.64.0    N.N.64-71.N      N.N.71.255
                              N.N.72.0    N.N.72-79.N      N.N.79.255
                              N.N.80.0    N.N.80-87.N      N.N.87.255
                              N.N.88.0    N.N.88-95.N      N.N.95.255
                              N.N.96.0    N.N.96-103.N     N.N.103.255
                              N.N.104.0   N.N.104-111.N    N.N.111.255
                              N.N.112.0   N.N.112-119.N    N.N.119.255
                              N.N.120.0   N.N.120-127.N    N.N.127.255
                              N.N.128.0   N.N.128-135.N    N.N.135.255
                              N.N.136.0   N.N.136-143.N    N.N.143.255
                              N.N.144.0   N.N.144-151.N    N.N.151.255
                              N.N.152.0   N.N.152-159.N    N.N.159.255
                              N.N.160.0   N.N.160-167.N    N.N.167.255
                              N.N.168.0   N.N.168-175.N    N.N.175.255
                              N.N.176.0   N.N.176-183.N    N.N.183.255
                              N.N.184.0   N.N.184-191.N    N.N.191.255
                              N.N.192.0   N.N.192-199.N    N.N.199.255
                              N.N.200.0   N.N.200-207.N    N.N.207.255
                              N.N.208.0   N.N.208-215.N    N.N.215.255
                              N.N.216.0   N.N.216-223.N    N.N.223.255
                              N.N.224.0   N.N.224-231.N    N.N.231.255
                              N.N.232.0   N.N.232-239.N    N.N.239.255
                              N.N.240.0   N.N.240-247.N    N.N.247.255
                              N.N.248.0   N.N.248-254.N    N.N.254.255

255.255.252.0   64 nets       N.N.0.0     N.N.0-3.N        N.N.3.255
6 bit subnet    1022          N.N.4.0     N.N.4-7.N        N.N.7.255
                              N.N.8.0     N.N.8-11.N       N.N.11.255
                              N.N.12.0    N.N.12-15.N      N.N.15.255
                              N.N.240.0   N.N.240-243.N    N.N.243.255
                              N.N.244.0   N.N.244-247.N    N.N.247.255
                              N.N.248.0   N.N.248-251.N    N.N.251.255
                              N.N.252.0   N.N.252-254.N    N.N.254.255


255.255.254.0   128 nets      N.N.0.0     N.N.0-1.N        N.N.1.255
7 bit subnet    510           N.N.2.0     N.N.2-3.N        N.N.3.255
                              N.N.4.0     N.N.4-5.N        N.N.5.255
                              N.N.250.0   N.N.250-251.N    N.N.251.255
                              N.N.252.0   N.N.252-253.N    N.N.253.255
                              N.N.254.0   N.N.254.N        N.N.254.255


255.255.255.0   255 nets      N.N.0.0     N.N.0.N          N.N.0.255
8 bit subnet    253           N.N.1.0     N.N.1.N          N.N.1.255
                              N.N.252.0   N.N.252.N        N.N.252.255
                              N.N.253.0   N.N.253.N        N.N.253.255
                              N.N.254.0   N.N.254.N        N.N.254.255

It should say:

Subnet Mask     # of nets    Net. Addr.  Host Addr Range  Brodcast Addr.
Bits of Subnet  hosts/subnet

255.255.128.0   2 nets        N.N.0.0     N.N.0-127.N      N.N.127.255
1 bit subnet    32766         N.N.128.0   N.N.128-255.N    N.N.255.255

255.255.192.0   4 nets        N.N.0.0     N.N.0-63.N       N.N.63.255
2 bit subnet    16382         N.N.64.0    N.N.64-127.N     N.N.127.255
                              N.N.128.0   N.N.128-191.N    N.N.191.255
                              N.N.192.0   N.N.192-255.N    N.N.255.255

255.255.224.0   8 nets        N.N.0.0     N.N.0-31.N       N.N.31.255
3 bit subnet    8190          N.N.32.0    N.N.32-63.N      N.N.63.255
                              N.N.64.0    N.N.64-95.N      N.N.95.255
                              N.N.96.0    N.N.96-127.N     N.N.127.255
                              N.N.128.0   N.N.128-159.N    N.N.159.255
                              N.N.160.0   N.N.160-191.N    N.N.191.255
                              N.N.192.0   N.N.192-223.N    N.N.223.255
                              N.N.224.0   N.N.224-255.N    N.N.255.255

255.255.240.0   16 nets       N.N.0.0     N.N.0-15.N       N.N.15.255
4 bit subnet    4094          N.N.16.0    N.N.16-31.N      N.N.31.255
                              N.N.32.0    N.N.32-47.N      N.N.47.255
                              N.N.48.0    N.N.48-63.N      N.N.63.255
                              N.N.64.0    N.N.64-79.N      N.N.79.255
                              N.N.80.0    N.N.80-95.N      N.N.95.255
                              N.N.96.0    N.N.96-111.N     N.N.111.255
                              N.N.112.0   N.N.112-127.N    N.N.127.255
                              N.N.128.0   N.N.128-143.N    N.N.143.255
                              N.N.144.0   N.N.144-159.N    N.N.159.255
                              N.N.160.0   N.N.160-175.N    N.N.175.255
                              N.N.176.0   N.N.176-191.N    N.N.191.255
                              N.N.192.0   N.N.192-207.N    N.N.207.255
                              N.N.208.0   N.N.208-223.N    N.N.223.255
                              N.N.224.0   N.N.224-239.N    N.N.239.255
                              N.N.240.0   N.N.240-255.N    N.N.255.255

255.255.248.0   32 nets       N.N.0.0     N.N.0-7.N        N.N.7.255
5 bit subnet    2046          N.N.8.0     N.N.8-15.N       N.N.15.255
                              N.N.16.0    N.N.16-23.N      N.N.23.255
                              N.N.24.0    N.N.24-31.N      N.N.31.255
                              N.N.32.0    N.N.32-39.N      N.N.39.255
                              N.N.40.0    N.N.40-47.N      N.N.47.255
                              N.N.48.0    N.N.48-55.N      N.N.55.255
                              N.N.56.0    N.N.56-63.N      N.N.63.255
                              N.N.64.0    N.N.64-71.N      N.N.71.255
                              N.N.72.0    N.N.72-79.N      N.N.79.255
                              N.N.80.0    N.N.80-87.N      N.N.87.255
                              N.N.88.0    N.N.88-95.N      N.N.95.255
                              N.N.96.0    N.N.96-103.N     N.N.103.255
                              N.N.104.0   N.N.104-111.N    N.N.111.255
                              N.N.112.0   N.N.112-119.N    N.N.119.255
                              N.N.120.0   N.N.120-127.N    N.N.127.255
                              N.N.128.0   N.N.128-135.N    N.N.135.255
                              N.N.136.0   N.N.136-143.N    N.N.143.255
                              N.N.144.0   N.N.144-151.N    N.N.151.255
                              N.N.152.0   N.N.152-159.N    N.N.159.255
                              N.N.160.0   N.N.160-167.N    N.N.167.255
                              N.N.168.0   N.N.168-175.N    N.N.175.255
                              N.N.176.0   N.N.176-183.N    N.N.183.255
                              N.N.184.0   N.N.184-191.N    N.N.191.255
                              N.N.192.0   N.N.192-199.N    N.N.199.255
                              N.N.200.0   N.N.200-207.N    N.N.207.255
                              N.N.208.0   N.N.208-215.N    N.N.215.255
                              N.N.216.0   N.N.216-223.N    N.N.223.255
                              N.N.224.0   N.N.224-231.N    N.N.231.255
                              N.N.232.0   N.N.232-239.N    N.N.239.255
                              N.N.240.0   N.N.240-247.N    N.N.247.255
                              N.N.248.0   N.N.248-255.N    N.N.255.255

255.255.252.0   64 nets       N.N.0.0     N.N.0-3.N        N.N.3.255
6 bit subnet    1022          N.N.4.0     N.N.4-7.N        N.N.7.255
                              N.N.8.0     N.N.8-11.N       N.N.11.255
                              N.N.12.0    N.N.12-15.N      N.N.15.255
                              N.N.240.0   N.N.240-243.N    N.N.243.255
                              N.N.244.0   N.N.244-247.N    N.N.247.255
                              N.N.248.0   N.N.248-251.N    N.N.251.255
                              N.N.252.0   N.N.252-255.N    N.N.255.255


255.255.254.0   128 nets      N.N.0.0     N.N.0-1.N        N.N.1.255
7 bit subnet    510           N.N.2.0     N.N.2-3.N        N.N.3.255
                              N.N.4.0     N.N.4-5.N        N.N.5.255
                              N.N.250.0   N.N.250-251.N    N.N.251.255
                              N.N.252.0   N.N.252-253.N    N.N.253.255
                              N.N.254.0   N.N.254-255.N    N.N.255.255


255.255.255.0   256 nets      N.N.0.0     N.N.0.N          N.N.0.255
8 bit subnet    254           N.N.1.0     N.N.1.N          N.N.1.255
                              N.N.253.0   N.N.253.N        N.N.253.255
                              N.N.254.0   N.N.254.N        N.N.254.255
                              N.N.255.0   N.N.255.N        N.N.255.255

Notes:

Some parts of table 1-1 should be corrected as it is expected to include all-zeros and all-ones subnets.
Broadcast address is always N.N.255.255 in the all-ones subnet of a class B network N.N.0.0, for any number of subnetting bits.
The last host address of the all-ones subnet should always be N.N.255.254. Then, the row for each all-ones subnet is to be modified to include N.N.255.N.
Finally, the number of subnets for 8 bit subnet should be 256 (not 255), of 254 hosts each (not 253).

RFC 1918, "Address Allocation for Private Internets", February 1996

Note: This RFC has been updated by RFC 6761

Source of RFC: cidrd ()

Errata ID: 1419
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jack Parker
Date Reported: 2008-05-07
Held for Document Update by: Pete Resnick

Section 3 says:

   An enterprise that decides to use IP addresses out of the address
   space defined in this document can do so without any coordination
   with IANA or an Internet registry.

It should say:

An enterprise that decides to use IP addresses within the address 
space defined in this document can do so without any coordination 
with IANA or an Internet registry.

Notes:

There appears to be a slight difference in interpretation with the existing phrase, "out of the address space." This 'could' be interpreted to mean "outside of the address space," hence changing the meaning of the entire statement, if the section's context is not considered. In the interest of clarification, would it be possible to rephrase this particular section to "within the address space?" I'm aware of one case in particular where attorneys argued over this issue ad nauseum, regardless of the network architects attempting to intervene.

RFC 1925, "The Twelve Networking Truths", April 1996

Source of RFC: INDEPENDENT

Errata ID: 3104
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Nottingham
Date Reported: 2012-02-05
Held for Document Update by: Pete Resnick

Section 2. (2) says:

   (2)  No matter how hard you push and no matter what the priority,
        you can't increase the speed of light.

It should say:

   (2) If you try really hard, and have the right equipment (or 
       suitable funding), you might be able to increase the speed 
       of light. Or not, we're not sure yet.

Notes:

Experimental results suggest it may be possible to go faster; see:
http://arxiv.org/abs/1109.4897

It's true that these results have not been independently verified, and it's true that the speed of light was not observed to be increased (only exceeded), but there is now enough doubt involved to justify an errata (with a view to an update in a potential future BIS WG).

RFC 1928, "SOCKS Protocol Version 5", March 1996

Source of RFC: aft (sec)

Errata ID: 3947
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Scott Conrad VanderWoude
Date Reported: 2014-04-02
Held for Document Update by: Stephen Farrell
Date Held: 2014-05-08

Section 6 (page 6) says:

In is

It should say:

It is

RFC 1939, "Post Office Protocol - Version 3", May 1996

Note: This RFC has been updated by RFC 1957, RFC 2449, RFC 6186, RFC 8314

Source of RFC: Legacy
Area Assignment: app

Errata ID: 1088
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Joseph Bowbeer
Date Reported: 2007-11-29
Held for Document Update by: Peter Saint-Andre

Section 7 says:

Note that if the number of lines requested by the POP3
client is greater than than the number of lines in the
body, then the POP3 server sends the entire message. 

It should say:

Note that if the number of lines requested by the POP3
client is greater than the number of lines in the body,
then the POP3 server sends the entire message. 

Notes:

Extraneous "than" in discussion of TOP command.

RFC 1948, "Defending Against Sequence Number Attacks", May 1996

Note: This RFC has been obsoleted by RFC 6528

Source of RFC: Legacy
Area Assignment: sec

Errata ID: 2068
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Fernando Gont
Date Reported: 2010-03-05
Held for Document Update by: Sean Turner

Section References says:

   [6]  Jacobson, V., Braden, R., and L. Zhang, "TCP Extension for
        High-Speed Paths", RFC 1885, October 1990.

It should say:

   [6]  Jacobson, V., Braden, R., and L. Zhang, "TCP Extension for
        High-Speed Paths", RFC 1185, October 1990.

Notes:

RFC 1185 has been obsoleted by RFC 1323. RFC 1323 is currently being revised.

RFC 1995, "Incremental Zone Transfer in DNS", August 1996

Note: This RFC has been updated by RFC 9103

Source of RFC: dnsind (int)

Errata ID: 3196
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2012-04-18
Held for Document Update by: Brian Haberman

Section 2, pg.2 says:

   If an IXFR query with the same or newer version number than that of
   the server is received, it is replied to with a single SOA record of
|  the server's current version, just as in AXFR.
                               ^^^^^^^^^^^^^^^^^^
   [...]

   Thus, a client should first make an IXFR query using UDP.  If the
   query type is not recognized by the server, an AXFR (preceded by a
|  UDP SOA query) should be tried, ensuring backward compatibility.  [...]
   ^^^^

It should say:

   If an IXFR query with the same or newer version number than that of
   the server is received, it is replied to with a single SOA record of
|  the server's current version.

   [...]

   Thus, a client should first make an IXFR query using UDP.  If the
|  query type is not recognized by the server, an AXFR (preceded by an
|  SOA query) should be tried, ensuring backward compatibility.  [...]

Notes:

Rationale:
a) The behavior of the IXFR protocol described in the first paragraph
quoted above has been attributed falsely to AXFR; AXFR doesn't
behave like that (cf. the clarified AXFR specification in RFC 5936).
b) The SOA query may be performed over TCP as well, e.g., if there
already is an open TCP connection from the client to the server.

Historical Note:
The above issues have been identified by the submitter in 2008,
but no Errata have been filed so far. However, these already had
been observed in 1999 by Andreas Gustafsson, who, in the context of
the work on RFC 1995bis, recently has provided the DNSEXT WG access
to a privately archived DNSIND mailing list thread on RFC 1995,
in which these issues have been discussed in November 1999.
For the record, the technical issues in RFC 1995 that can be
addressed by Errata Notes are now being submitted this way.

RFC 1997, "BGP Communities Attribute", August 1996

Note: This RFC has been updated by RFC 7606, RFC 8642

Source of RFC: idr (rtg)

Errata ID: 3889
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramakrishna DTV
Date Reported: 2014-02-12
Held for Document Update by: Stewart Bryant
Date Held: 2014-03-02

Section 3 says:

   This document creates the COMMUNITIES path attribute is an optional
   transitive attribute of variable length.  The attribute consists of a
   set of four octet values, each of which specify a community.  All
   routes with this attribute belong to the communities listed in the
   attribute.

It should say:

   This document creates the COMMUNITIES path attribute, which is an 
   optional transitive attribute of variable length.  The attribute 
   consists of a set of four octet values, each of which specify a 
   community.  All routes with this attribute belong to the 
   communities listed in the attribute.

Notes:

Typo in first sentence. "which" is missing.

Errata ID: 3890
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramakrishna DTV
Date Reported: 2014-02-13
Held for Document Update by: Stewart Bryant
Date Held: 2014-03-02

Section 3 says:

   The community attribute values ranging from 0x0000000 through
   0x0000FFFF and 0xFFFF0000 through 0xFFFFFFFF are hereby reserved.

It should say:

   The community attribute values ranging from 0x00000000 through
   0x0000FFFF and 0xFFFF0000 through 0xFFFFFFFF are hereby reserved.

Notes:

Since community is a 32-bit value, 0x0000000 should be 0x00000000 to remove confusion.

Verifier note: It might be useful to tidy this when the text is updated, but the text is correct and there is no possibility of confusion if you read the whole sentence.

RFC 2003, "IP Encapsulation within IP", October 1996

Note: This RFC has been updated by RFC 3168, RFC 6864

Source of RFC: mobileip (int)

Errata ID: 1686
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2009-02-18
Held for Document Update by: Brian Haberman

Section 4.3 says:

   The encapsulator MAY handle the ICMP Redirect messages itself.  It
   MUST NOT not relay the Redirect to the sender of the original
   unencapsulated datagram.

It should say:

   The encapsulator MAY handle the ICMP Redirect messages itself.  It
   MUST NOT relay the Redirect to the sender of the original
   unencapsulated datagram.

RFC 2026, "The Internet Standards Process -- Revision 3", October 1996

Note: This RFC has been updated by RFC 3667, RFC 3668, RFC 3932, RFC 3978, RFC 3979, RFC 5378, RFC 5657, RFC 5742, RFC 6410, RFC 7100, RFC 7127, RFC 7475, RFC 8179, RFC 8789, RFC 9282

Source of RFC: poised95 (gen)

Errata ID: 2044
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lars Eggert
Date Reported: 2010-02-15
Held for Document Update by: Russ Housley

Section 10.4 says:

         The limited permissions granted above are perpetual and will
         not be revoked by the Internet Society or its successors or
         assigns.

It should say:

         The limited permissions granted above are perpetual and will
         not be revoked by the Internet Society or its successors or
         assignees.

Notes:

Assigns vs. assignees in the boilerplate text. xml2rfc generates the latter (which appears to be correct), idnits currently allows both variants.

The same change needs to be applied in Section 10.3.1 bullet item 7.

Errata ID: 6671
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jason Yundt
Date Reported: 2021-08-31
Held for Document Update by: Lars Eggert
Date Held: 2023-08-11

Section 13 says:

   [1]  Postel, J., "Internet Official Protocol Standards", STD 1,
        USC/Information Sciences Institute, March 1996.

   [2]  ANSI, Coded Character Set -- 7-Bit American Standard Code for
        Information Interchange, ANSI X3.4-1986.

   [3]  Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
        USC/Information Sciences Institute, October 1994.

   [4]  Postel, J., "Introduction to the STD Notes", RFC 1311,
        USC/Information Sciences Institute, March 1992.

   [5]  Postel, J., "Instructions to RFC Authors", RFC 1543,
        USC/Information Sciences Institute, October 1993.

   [6]  Huitema, C., J. Postel, and S. Crocker "Not All RFCs are
        Standards", RFC 1796, April 1995.

It should say:

   [1]  Postel, J., "Internet Official Protocol Standards", STD 1,
        USC/Information Sciences Institute, March 1996.

   [2]  ANSI, Coded Character Set -- 7-Bit American Standard Code for
        Information Interchange, ANSI X3.4-1986.

   [3]  Postel, J., "Introduction to the STD Notes", RFC 1311,
        USC/Information Sciences Institute, March 1992.

   [4]  Postel, J., "Instructions to RFC Authors", RFC 1543,
        USC/Information Sciences Institute, October 1993.

   [5]  Huitema, C., J. Postel, and S. Crocker "Not All RFCs are
        Standards", RFC 1796, April 1995.

Notes:

Reference number 3 is never used. If this change is made, then the inline citations will also have to be updated.

RFC 2030, "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", October 1996

Note: This RFC has been obsoleted by RFC 4330

Source of RFC: Legacy
Area Assignment: int

Errata ID: 516
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Ben Fountain
Date Reported: 2002-11-12
Held for Document Update by: Brian Haberman

Section 1 says:

   Each SNTP packet is transmitted as tht TS-Userdata
   parameter of a T-UNITDATA Request primitive.

It should say:

   Each SNTP packet is transmitted as the TS-Userdata
   parameter of a T-UNITDATA Request primitive.

Errata ID: 2479
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Dave Higton
Date Reported: 2010-08-20
Held for Document Update by: Brian Haberman

Section 4 says:

   MSF      Rugby (UK) Radio 60 kHz

It should say:

   MSF      Anthorn (UK) Radio 60 kHz

Notes:

The MSF transmitter was relocated from Rugby to Anthorn, in Cumbria, on 2007 March 31. See http://www.npl.co.uk/science-+-technology/time-and-frequency/npl-ensures-accurate-uk-time-for-the-next-15-years

Errata ID: 515
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: vijeeshep
Date Reported: 2005-12-16
Held for Document Update by: Brian Haberman

Section 5 says:

T  = ((T2 - T1) + (T3 - T4)) / 2.

It should say:

T  = ((T2 - T1) + (T4 - T3)) / 2.

Notes:

Because T4 always will be greater than (or equal to) T3

For example assume
T1 = 1
T2 = 3
T3 = 4
T4 = 6
Case 1: As per the given formula the local clock offset will be
T = ((3 - 1) + (4 - 6)) / 2 = 0 which is wrong
Case 2: As per the corrected formula the local clock offset will be
T = ((3 - 1)+ (6 - 4)) / 2 = 2 which is correct

Errata ID: 520
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Fountain
Date Reported: 2002-11-12
Held for Document Update by: Brian Haberman

Section 1 says:

   An important provision in this document is the reinterpretation of
   certain NTP Versino 4 header fields which provide for IPv6 and OSI
   addressing and optional anycast extensions designed specifically for
   multicast service. 

It should say:

   An important provision in this document is the reinterpretation of
   certain NTP Version 4 header fields which provide for IPv6 and OSI
   addressing and optional anycast extensions designed specifically for
   multicast service.

RFC 2042, "Registering New BGP Attribute Types", January 1997

Source of RFC: Legacy
Area Assignment: rtg

Errata ID: 3681
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: J. Noel Chiappa
Date Reported: 2013-07-12
Held for Document Update by: Stewart Bryant
Date Held: 2013-09-17

In the References, it says:

[3] Bates, T., Chandra, R, "BGP Route Reflection An alternative
    to full mesh IBGP", RFC 1998, June 1996.

It should say:

[3] Bates, T., Chandra, R., "BGP Route Reflection: An alternative
    to full mesh IBGP", RFC 1966, June 1996.

Notes:

Wrong RFC number for that document.

RFC 2045, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", November 1996

Note: This RFC has been updated by RFC 2184, RFC 2231, RFC 5335, RFC 6532

Source of RFC: 822ext (app)

Errata ID: 3442
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kwadronaut
Date Reported: 2013-01-03
Held for Document Update by: Barry Leiba
Date Held: 2013-01-03

Section 8. says:

   body is often desirable.  For example, it may be useful to mark an
   "image" body as "a picture of the Space Shuttle Endeavor."

It should say:

   body is often desirable.  For example, it may be useful to mark an
   "image" body as "a picture of the Space Shuttle Endeavour."

Notes:

That orbiter was called the Endeavour, little typo.

---
Verifier notes:
Little typo, indeed, and perhaps the draft's authors weren't aware of the NASA spelling. Still, little insignificant typos aren't what RFC errata are all about, so this goes in the "hold for document update" bin.

RFC 2046, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", November 1996

Note: This RFC has been updated by RFC 2646, RFC 3798, RFC 5147, RFC 6657, RFC 8098

Source of RFC: 822ext (app)

Errata ID: 4609
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Oleg Andriyanov
Date Reported: 2016-02-01
Held for Document Update by: Barry Leiba
Date Held: 2016-02-02

Section 3 says:

          particular, formats that employ embeddded binary

It should say:

          particular, formats that employ embedded binary

Notes:

"embeddded" has triple "d".

RFC 2047, "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", November 1996

Note: This RFC has been updated by RFC 2184, RFC 2231

Source of RFC: 822ext (app)

Errata ID: 5469
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Occil
Date Reported: 2018-08-17
Held for Document Update by: Barry Leiba
Date Held: 2019-04-30

Section 5 says:

    In this case the set of characters that may be used in a "Q"-encoded
    'encoded-word' is restricted to: <upper and lower case ASCII
    letters, decimal digits, "!", "*", "+", "-", "/", "=", and "_"
    (underscore, ASCII 95.)>

It should say:

In this case the set of characters that may be used in a "Q"-encoded
'encoded-text' is restricted to: <upper and lower case ASCII
letters, decimal digits, "!", "*", "+", "-", "/", "=" (only if
followed by two hexadecimal digits), and "_" (underscore, ASCII 95.)>

Notes:

This sentence discusses the use of encoded words within a phrase. However, the original text is wrong in at least two ways:

1. The production "encoded-word" also allows "?" to appear, as well as characters allowed in MIME "token"s.
2. Even in the "encoded-text" portion the "=" sign can't appear freely in Q-encoding, but must be followed by two hexadecimal characters (as stated later in section 5).

The correction given here changes "encoded-word" to "encoded-text" and adds text restricting where "=" can appear. Another plausible correction would be to add "?" and the other characters allowed in "tokens" (and leave the text "'q'-encoded 'encoded-word'" alone), but that would interfere with later RFCs, notably RFC 2231, that restrict the syntax of the charset component of encoded-words.

Errata ID: 2823
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Spiros Bousbouras
Date Reported: 2011-06-05
Held for Document Update by: Pete Resnick
Date Held: 2011-06-05

Section 8 says:

   The following examples illustrate how text containing 'encoded-word's
   which appear in a structured field body.

It should say:

   The following examples illustrate how text containing 'encoded-word's
   appears in a structured field body.

Errata ID: 4913
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Drinkwater
Date Reported: 2017-01-19
Held for Document Update by: Barry Leiba
Date Held: 2019-04-30

Section 8 says:

           Any amount of linear-space-white between 'encoded-word's,
           even if it includes a CRLF followed by one or more SPACEs,
           is ignored for the purposes of display.

It should say:

           Any amount of linear-white-space between 'encoded-word's,
           even if it includes a CRLF followed by one or more SPACEs,
           is ignored for the purposes of display.

Errata ID: 5692
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eugene Adell
Date Reported: 2019-04-14
Held for Document Update by: Barry Leiba
Date Held: 2019-04-30

Section Appendix says:

   + explicitly state that the MIME-Version is not requried to use
     'encoded-word's.

It should say:

   + explicitly state that the MIME-Version is not required to use
     'encoded-word's.

Notes:

a minor spelling mistake

RFC 2049, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", November 1996

Source of RFC: 822ext (app)

Errata ID: 5470
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Peter Occil
Date Reported: 2018-08-17
Held for Document Update by: Barry Leiba
Date Held: 2019-04-30

Section 2 says:

    (3)   Must treat any unrecognized Content-Transfer-Encoding
          as if it had a Content-Type of "application/octet-
          stream", regardless of whether or not the actual
          Content-Type is recognized.

It should say:

    (3)   Treat any MIME entity with an unrecognized
          Content-Transfer-Encoding
          as if it had a Content-Type of "application/octet-
          stream", regardless of whether or not the actual
          Content-Type is recognized.

Notes:

The original text spoke of a "Content-Transfer-Encoding" with a "Content-Type", which makes no sense. This paragraph was probably intended instead to apply to MIME entities (messages and body parts).

----- Verifier Notes -----
I think most readers will understand that something like "MIME entity with" was intentionally elided in the existing text, but it's worth recording this for consideration when the spec is revised.

RFC 2100, "The Naming of Hosts", April 1997

Source of RFC: INDEPENDENT

Errata ID: 5005
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Harris
Date Reported: 2017-04-28
Held for Document Update by: Warren Kumari (Ops AD)
Date Held: 2017-10-24

Section References says:

   [4]  Stearns, TS, _Old Possum's Book of Practical Cats_.

It should say:

   [4]  Eliot, TS, _Old Possum's Book of Practical Cats_.

Notes:

"Stearns" was T. S. Eliot's middle name. Old Possum's Book of Practical Cats was published under the name "T. S. Eliot".

Errata ID: 5165
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nick Nicholas
Date Reported: 2017-10-24
Held for Document Update by: Warren Kumari (Ops AD)
Date Held: 2017-10-24

Throughout the document, when it says:

    Such as pearly-gates.vatican, or else diplomatic-

It should say:

    Such as pearly-gates.vatican, or else diplomatic--

Notes:

For consistency with treatment of em-dash elsewhere

Errata ID: 5166
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nick Nicholas
Date Reported: 2017-10-24
Held for Document Update by: Warren Kumari (Ops AD)
Date Held: 2017-10-24

Throughout the document, when it says:

It's ineffable,
effable,
Effanineffable,
Deep and inscrutable,
singular
Name.

It should say:

Its ineffable,
effable,
Effanineffable,
Deep and inscrutable,
singular
Name.

Notes:

Is parodying T.S. Eliot's "*His* ineffable effable. Effanineffable"

RFC 2104, "HMAC: Keyed-Hashing for Message Authentication", February 1997

Note: This RFC has been updated by RFC 6151

Source of RFC: ipsec (sec)

Errata ID: 2794
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Kasper Dupont
Date Reported: 2011-05-02
Held for Document Update by: Sean Turner

Section Appendix says:

  key =         "Jefe"
  data =        "what do ya want for nothing?"
  data_len =    28 bytes
  digest =      0x750c783e6ab0b503eaa86e310a5db738

It should say:

  key =         "Jefe"
  key_len =     4
  data =        "what do ya want for nothing?"
  data_len =    28 bytes
  digest =      0x750c783e6ab0b503eaa86e310a5db738

Notes:

key_len was omitted from this test vector. The other test vectors specify both key_len and data_len.

Errata ID: 4809
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Erdem Memisyazici
Date Reported: 2016-09-23
Held for Document Update by: Stephen Farrell
Date Held: 2017-02-03

Section 2 says:

Applications that use keys longer
   than B bytes will first hash the key using H and then use the
   resultant L byte string as the actual key to HMAC.

It should say:

Applications MUST not use keys longer than B bytes.

Notes:

Using this approach creates an exploitable vulnerability where there are two known K instances, one the hashed key, and the other the key itself. As shown in the sample Java code below:

final byte[] keyBytes = KEY.getBytes();
final byte[] sha1 = HashUtil.sha1(keyBytes);
final String a = hmac_sha1(keyBytes, TEXT);
final String b = hmac_sha1(sha1, TEXT);

As demonstrated a equals b. To cite a real world vulnerability; for all keys longer than B, using password storage configurations which store the hash of the key for integrity checks, and store the key itself in a tamper proof device, there will exist plain text keys stored on both storage systems. Compromising a hash database should not reveal plain text secrets, which will only be true if an implementation first hashes the key and uses the resultant L byte string as the actual key to HMAC.

I suggest simply not allowing keys longer than B bytes, which will greatly improve the security of the standard.

Verifier notes: I started a thread [1] on the CFRG mailing list to discuss this. My reading of that thread leads me to conclude there there's consensus to not verify the erratum on the basis that the threat isn't that significant and a backwards incompatible change as would be required is not justified. However, if HMAC were to be updated in a manner that didn't require backwards compatibility then one would likely consider this. Hence marking this as "hold for document update"

Errata ID: 3694
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christopher Dearlove
Date Reported: 2013-08-14
Held for Document Update by: Sean Turner

Section References says:

"Keyed Hash Functions and Message Authentication"

It should say:

"Keying Hash Functions for Message Authentication"

Notes:

This is reference [BCK1]. It is also no longer directly available at the advertised URL, though can be found on that site. Alternatively it is easily available elsewhere, by searching with the quoted corrected title (which is why this erratum may help).

RFC 2119, "Key words for use in RFCs to Indicate Requirement Levels", March 1997

Note: This RFC has been updated by RFC 8174

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: gen

Errata ID: 2969
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: John Klensin
Date Reported: 2011-09-12
Held for Document Update by: Russ Housley

Section 1,3,4 says:

(1) "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" mean

(2) 1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean

(3) 3. SHOULD   This word, or the adjective "RECOMMENDED", mean

(4) 4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean

It should say:

(1) "The key words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", and "MAY" means

(2) 1. MUST   This word, or the term "SHALL", means

(3) 3. SHOULD   This word means

(4) 4. SHOULD NOT   This phrase means

Editorial note: The use of "mean" after a singular subject is simply wrong.  Subordinate phrases like ", or the term BLATHER," do nothing to change that.


 

Notes:

RFC 2026, to which RFC 2119 should be subordinate, carefully distinguishes between Technical Specifications (TS) and Applicability Statements (AS). Its Section 3.3 prescribes specific language to be used in ASs, with categories "Required", "Recommended", "Elective", "Limited Use", and "Not Recommended", while 2119's language, especially in its Section 6, fairly clearly apply to interoperability requirements within TS documents. Use of terms that 2026 requires for AS documents in a TS context (as synonyms for other, unambiguous, terms) is just an invitation to confusion, especially if the IETF continues to have hair-splitting arguments about the nature of requirements in particular contexts. Consequently, while the change proposed in erratum 419 (altering the definition phrase to reflect the language of Section 4) appears reasonable from an editorial standpoint, the correct fix is to remove the 2026 AS terms as acceptable synonyms from 2119 entirely. If people want to say "SHOULD NOT" and give it specific meaning, they should say "SHOULD NOT" rather than trying to use nearly-synonymous terms and hoping that the reader will figure out what was really met.

Errata ID: 5206
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hugo Gabriel Eyherabide
Date Reported: 2017-12-14
Held for Document Update by: Lars Eggert
Date Held: 2021-03-11

Section 5 says:

MAY   This word, or the adjective "OPTIONAL", mean

It should say:

MAY   This word, or the adjective "OPTIONAL", means

Notes:

This correction is analogous to that pointed out by Erratas 495, 498, 500 and 2969 for sections 1, 3 and 4, but for section. The correction replaces "mean" with "means"

RFC 2131, "Dynamic Host Configuration Protocol", March 1997

Note: This RFC has been updated by RFC 3396, RFC 4361, RFC 5494, RFC 6842

Source of RFC: dhc (int)

Errata ID: 488
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Robert Floyd Jr
Date Reported: 2006-03-23
Held for Document Update by: Brian Haberman

Section 1.2 says:

In other related work, the path minimum transmission unit (MTU) discovery
algorithm can determine the MTU of an arbitrary internet path [14].

It should say:

In other related work, the path maximum transmission unit (MTU) discovery
algorithm can determine the MTU of an arbitrary internet path [14].

Errata ID: 6618
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rubén L.M.
Date Reported: 2021-06-22
Held for Document Update by: Eric Vyncke
Date Held: 2022-05-30

Section 3.1 says:

                Server          Client          Server
            (not selected)                    (selected)

                  v               v               v
                  |               |               |
                  |     Begins initialization     |
                  |               |               |
                  | _____________/|\____________  |
                  |/DHCPDISCOVER | DHCPDISCOVER  \|
                  |               |               |
              Determines          |          Determines
             configuration        |         configuration
                  |               |               |
                  |\             |  ____________/ |
                  | \________    | /DHCPOFFER     |
                  | DHCPOFFER\   |/               |
                  |           \  |                |
                  |       Collects replies        |
                  |             \|                |
                  |     Selects configuration     |
                  |               |               |
                  | _____________/|\____________  |
                  |/ DHCPREQUEST  |  DHCPREQUEST\ |
                  |               |               |
                  |               |     Commits configuration
                  |               |               |
                  |               | _____________/|
                  |               |/ DHCPACK      |
                  |               |               |
                  |    Initialization complete    |
                  |               |               |
                  .               .               .
                  .               .               .
                  |               |               |
                  |      Graceful shutdown        |
                  |               |               |
                  |               |\ ____________ |
                  |               | DHCPRELEASE  \|
                  |               |               |
                  |               |        Discards lease
                  |               |               |
                  v               v               v
     Figure 3: Timeline diagram of messages exchanged between DHCP
               client and servers when allocating a new network address

It should say:

                Server          Client          Server
            (not selected)                    (selected)

                  v               v               v
                  |               |               |
                  |     Begins initialization     |
                  |               |               |
                  | _____________/|\_____________ |
                  |/DHCPDISCOVER  | DHCPDISCOVER \|
                  |               |               |
              Determines          |          Determines
             configuration        |         configuration
                  |               |               |
                  |\              |  ____________/|
                  | \_________    | /DHCPOFFER    |
                  |  DHCPOFFER\   |/              |
                  |            \  |               |
                  |       Collects replies        |
                  |              \|               |
                  |     Selects configuration     |
                  |               |               |
                  | _____________/|\____________  |
                  |/ DHCPREQUEST  |  DHCPREQUEST\ |
                  |               |               |
                  |               |     Commits configuration
                  |               |               |
                  |               | _____________/|
                  |               |/ DHCPACK      |
                  |               |               |
                  |    Initialization complete    |
                  |               |               |
                  .               .               .
                  .               .               .
                  |               |               |
                  |      Graceful shutdown        |
                  |               |               |
                  |               |\ ____________ |
                  |               | DHCPRELEASE  \|
                  |               |               |
                  |               |        Discards lease
                  |               |               |
                  v               v               v
     Figure 3: Timeline diagram of messages exchanged between DHCP
               client and servers when allocating a new network address

Notes:

alignment

RFC 2132, "DHCP Options and BOOTP Vendor Extensions", March 1997

Note: This RFC has been updated by RFC 3442, RFC 3942, RFC 4361, RFC 4833, RFC 5494

Source of RFC: dhc (int)

Errata ID: 487
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: "Tyler Tidman"
Date Reported: 2002-09-24
Held for Document Update by: Brian Haberman

Section 3.18 says:

3.18. Swap Server

   This specifies the IP address of the client's swap server.

   The code for this option is 16 and its length is 4.

    Code   Len    Swap Server Address
   +-----+-----+-----+-----+-----+-----+
   |  16 |  n  |  a1 |  a2 |  a3 |  a4 |
   +-----+-----+-----+-----+-----+-----+

It should say:

3.18. Swap Server

   This specifies the IP address of the client's swap server.

   The code for this option is 16 and its length is 4.

    Code   Len    Swap Server Address
   +-----+-----+-----+-----+-----+-----+
   |  16 |  4  |  a1 |  a2 |  a3 |  a4 |
   +-----+-----+-----+-----+-----+-----+

Errata ID: 2388
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Muhammad Yousaf
Date Reported: 2010-07-21
Held for Document Update by: Brian Haberman

Section 1.2 says:

A DHCP server of "server"is an Internet host that returns configuration parameters to DHCP clients.

It should say:

A DHCP server or "server" is an Internet host that returns configuration parameters to DHCP clients.

RFC 2136, "Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1997

Note: This RFC has been updated by RFC 3007, RFC 4035, RFC 4033, RFC 4034

Source of RFC: dnsind (int)

Errata ID: 2805
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Tony Finch
Date Reported: 2011-05-09
Held for Document Update by: Brian Haberman

Section 1.1.1 says:

   1.1.1. Two RRs are considered equal if their NAME, CLASS, TYPE,
   RDLENGTH and RDATA fields are equal.  Note that the time-to-live
   (TTL) field is explicitly excluded from the comparison.

It should say:

   1.1.1. Two RRs are considered equal if their NAME, CLASS, TYPE,
   RDLENGTH and RDATA fields are equal.  Compressed names in the RDATA
   must be decompressed before comparison. Note that the time-to-live
   (TTL) field is explicitly excluded from the comparison.

Notes:

Name compression depends on the context of the RR so RDATA cannot correctly be compared bytewise without taking this into account.

RFC 2141, "URN Syntax", May 1997

Note: This RFC has been obsoleted by RFC 8141

Source of RFC: urn (app)

Errata ID: 4064
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dave Thaler
Date Reported: 2014-07-25
Held for Document Update by: Barry Leiba
Date Held: 2014-07-28

Section 7 says:

Functional equivalence is determined by practice within a given
namespace and managed by resolvers for that namespeace.

It should say:

Functional equivalence is determined by practice within a given
namespace and managed by resolvers for that namespace.

Notes:

Namespace is misspelled

RFC 2142, "Mailbox Names for Common Services, Roles and Functions", May 1997

Source of RFC: Legacy
Area Assignment: app

Errata ID: 1082
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Frank Ellermann
Date Reported: 2007-11-20
Held for Document Update by: Peter Saint-Andre
Date Held: 2010-09-15

Section 5 says:

MAILBOX        SERVICE             SPECIFICATIONS
[...]
USENET         NNTP                [RFC977]
NEWS           NNTP                Synonym for USENET

It should say:

MAILBOX        SERVICE             SPECIFICATIONS
[...]
USENET         NNTP                [RFC1849]
NEWSMASTER     NNTP                Synonym for USENET

Notes:

RFC 977 (obsoleted by RFC 3977) as well as RFC 1036 (obsoleted by RFC.ietf-usefor-usefor) don't specify rôle accounts USENET or NEWS.

Section 1 states that "Other protocols have defacto standards for well known mailbox names, such as <USENET@domain> for NNTP (see [RFC977])", however the IETF USEFOR WG didn't add just as little as an informative reference to RFC 2142.

IESG NOTE (2010-09-15): The foregoing text is corrupted, however the intent is clearly that [son-of-1036] is the proper reference for the USENET mailbox convention; note that in March 2010 [son-of-1036] was published as RFC 1849. --Peter Saint-Andre

Errata ID: 1763
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nick Levinson
Date Reported: 2009-04-15
Held for Document Update by: Alexey Melnikov
Date Held: 2010-09-02

Section 1 says:

Most organizations do not need to support the full set of mailbox names defined
here, since not every organization will implement the all of the associated
                                                  ^^^
services.

It should say:

Most organizations do not need to support the full set of mailbox names defined
here, since not every organization will implement all of the associated services.

Errata ID: 1764
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nick Levinson
Date Reported: 2009-04-15
Held for Document Update by: Peter Saint-Andre
Date Held: 2010-09-15

Section 1 & 2 says:

top level domain

It should say:

organization's principal domain name

Notes:

1. The phrase "top level domain" seems to mean 'second-level and top level domains together', and perhaps 'third- to top level domains together' in cases like <example.co.uk>. It is erroneous now that _top level domain_ (_TLD_) is specifically only what comes after the last dot in a domain, and nonreserved TLDs are so registered at IANA.org.

2. I would rather someone else propose replacement phrasing.

3. This is submitted 2009-04-16.

EDITOR'S NOTE (2010-09-15): This matter was discussed on the app-discuss and dnsext mailing lists, and consensus emerged on the phrase "organization's principal domain name". --Peter Saint-Andre

RFC 2157, "Mapping between X.400 and RFC-822/MIME Message Bodies", January 1998

Source of RFC: mixer (app)

Errata ID: 1387
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Frank Ellermann
Date Reported: 2008-03-25
Held for Document Update by: Alexey Melnikov

Section 6.2 says:

ESC 21 41

It should say:

ESC 22 43

Notes:

ESC 21 41 invokes ISO-IR 7, an unrelated C0 set.
ESC 22 43 invokes ISO-IR 77, the C1 set of an old ISO 6429.

For details see <http://www.itscj.ipsj.or.jp/ISO-IR/2-5.htm>
(C0 sets) and <http://www.itscj.ipsj.or.jp/ISO-IR/2-6.htm> (C1).

RFC 2182, "Selection and Operation of Secondary DNS Servers", July 1997

Source of RFC: dnsind (int)

Errata ID: 4631
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Andrew Boling
Date Reported: 2016-03-02
Held for Document Update by: Terry Manderson
Date Held: 2016-05-12

Section 3.3 says:

     + While positive DNS results are usually cached, the lack of a
       result is not cached.  Thus, unnecessary inability to resolve
       creates an undesirable load on the net.

It should say:

     + While positive DNS results are usually cached, the lack of a
       result will either be cached with less frequency or not at all,
       depending on a server's caching behaviours and the
       operator's local configuration.  Thus, unnecessary inability to
       resolve creates an undesirable load on the net.

Notes:

BCP 16 predates RFC 2308 (Negative Caching of DNS Queries), and the blanket statement that "lack of a result is not cached" is inaccurate by modern standards.

AD Note:

1) The errata has been moved to editorial, as the outcome "undesirable load on the net" is the same.

2) The errata itself has been moved to hold for update. Change in deployment and technology over time will always affect documents already published. The Errata text is not spurious, and does add clarification but does not impact interoperability.

RFC 2202, "Test Cases for HMAC-MD5 and HMAC-SHA-1", September 1997

Source of RFC: Legacy
Area Assignment: sec

Errata ID: 3851
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Antonio Bueno
Date Reported: 2013-12-28
Held for Document Update by: Sean Turner
Date Held: 2014-01-12

Section 2 says:

test_case =     3
key =           0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
key_len         16
data =          0xdd repeated 50 times
data_len =      50
digest =        0x56be34521d144c88dbb8c733f0e8b3f6

test_case =     4
key =           0x0102030405060708090a0b0c0d0e0f10111213141516171819
key_len         25
data =          0xcd repeated 50 times
data_len =      50
digest =        0x697eaf0aca3a3aea3a75164746ffaa79

It should say:

test_case =     3
key =           0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
key_len =       16
data =          0xdd repeated 50 times
data_len =      50
digest =        0x56be34521d144c88dbb8c733f0e8b3f6

test_case =     4
key =           0x0102030405060708090a0b0c0d0e0f10111213141516171819
key_len =       25
data =          0xcd repeated 50 times
data_len =      50
digest =        0x697eaf0aca3a3aea3a75164746ffaa79

Notes:

Notice the equal signs missing after "key_len"

spt: I changed the classification to editorial and made it hold for document update because I don't believe implementers will be confused by the missing "=".

RFC 2205, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", September 1997

Note: This RFC has been updated by RFC 2750, RFC 3936, RFC 4495, RFC 5946, RFC 6437, RFC 6780

Source of RFC: rsvp (tsv)

Errata ID: 4732
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramakrishna DTV
Date Reported: 2016-07-06
Held for Document Update by: Magnus Westerlund
Date Held: 2019-05-08

Section Appendix A.5 says:

      Error Value

           A two-octet field containing additional information about the
                error.  Its contents depend upon the Error Type.

It should say:

       Error Value

           A two-octet field containing additional information about the
                error.  Its contents depend upon the Error Code.

Notes:

s/Error Type/Error Code

"Error Type" is neither defined nor used elsewhere in RFC 2205.

RFC 2209, "Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules", September 1997

Source of RFC: rsvp (tsv)

Errata ID: 4057
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramakrishna DTV
Date Reported: 2014-07-21
Held for Document Update by: Martin Stiemerling
Date Held: 2015-03-23

Section 1 says:

   This memo assumes the generic interface calls defined in [RFC 2005]
   and the following data structures.  An actual implementation may use
   additional or different data structures and interfaces.  The data
   structure fields that are shown are required unless they are
   explicitly labelled as optional.

It should say:

   This memo assumes the generic interface calls defined in [RFC 2205]
   and the following data structures.  An actual implementation may use
   additional or different data structures and interfaces.  The data
   structure fields that are shown are required unless they are
   explicitly labelled as optional.

Notes:

Replace "RFC 2005" with "RFC 2205".

The generic interface calls are defined in RFC 2205 and not in RFC 2005.

RFC 2213, "Integrated Services Management Information Base using SMIv2", September 1997

Source of RFC: intserv (tsv)

Errata ID: 479
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Orly Nicklass
Date Reported: 2005-09-12
Held for Document Update by: Wesley Eddy

Section 3 says:

            TimeInterval, TEXTUAL-CONVENTION, RowStatus,
            TruthValue                               FROM SNMPv2-TC

It should say:

            TimeInterval, TEXTUAL-CONVENTION, RowStatus,
            TruthValue, TestAndIncr            FROM SNMPv2-TC

RFC 2217, "Telnet Com Port Control Option", October 1997

Source of RFC: Legacy
Area Assignment: sec

Errata ID: 4407
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jeremy Visser
Date Reported: 2015-06-29
Held for Document Update by: Barry Leiba
Date Held: 2015-06-30

Section Discussion says:

By in large

It should say:

By and large

Notes:

"By in large" is an eggcorn. It should read "By and large".

RFC 2231, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", November 1997

Source of RFC: Legacy

Errata ID: 3269
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Chris Newman
Date Reported: 2012-06-28
Held for Document Update by: Barry Leiba

Section 3 says:

    (2)   the mechanism MUST NOT depend on parameter ordering
          since MIME states that parameters are not order
          sensitive.  Note that while MIME does prohibit
          modification of MIME headers during transport, it is
          still possible that parameters will be reordered when
          user agent level processing is done.

It should say:

    (2)   the mechanism MUST NOT depend on parameter ordering
          since MIME states that parameters are not order
          sensitive.  Note that while MIME does prohibit
          modification of MIME headers during transport, it is
          still possible that parameters will be reordered when
          user agent level processing is done.
     (3) the mechanism MUST NOT alter parameter values that are
          critical to existing MIME processors. This specifically includes
          the "boundary" parameter for multipart types and the "charset"
          parameter for text types.
        

Notes:

Earlier text in the section states "Any such mechanism MUST be compatible with existing MIME processors." The addition of a 3rd item clarifies an additional behavior that is necessary to achieve that requirement. It is a flaw in the RFC 2231 standard if it creates a message format that can not be processed by an RFC 2045 processor but can be processed by an RFC-2045-as-extended-by-2231 processor. I have seen a 2231 split boundary marker in the wild so this elaboration on the existing MUST appears to be necessary.

Note that I do not object if this errata is marked "hold for document update".

RFC 2234, "Augmented BNF for Syntax Specifications: ABNF", November 1997

Note: This RFC has been obsoleted by RFC 4234

Source of RFC: drums (app)

Errata ID: 765
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Keith McCloghrie
Date Reported: 2005-05-19
Held for Document Update by: Peter Saint-Andre

 

page 5:

        LINEAR WHITE SPACE:  Concatenation is ...
        ...
        ...
        ...
        ...                          ... to be freelyPand
        implicitlyPinterspersed around ...
        
presumably, each "P" character should be a parenthesis and a space ??

It should say:

[see above]

Notes:

from pending

RFC 2246, "The TLS Protocol Version 1.0", January 1999

Note: This RFC has been obsoleted by RFC 4346

Note: This RFC has been updated by RFC 3546, RFC 5746, RFC 6176, RFC 7465, RFC 7507, RFC 7919

Source of RFC: tls (sec)

Errata ID: 3482
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Florian Maury
Date Reported: 2013-02-11
Held for Document Update by: Sean Turner

Section 7.4.9. says:

The hash contained in finished messages sent by the server
incorporate Sender.server; those sent by the client incorporate
Sender.client. The value handshake_messages includes all handshake
messages starting at client hello up to, but not including, this
finished message. This may be different from handshake_messages in
Section 7.4.8 because it would include the certificate verify message
(if sent). Also, the handshake_messages for the finished message sent
by the client will be different from that for the finished message
sent by the server, because the one which is sent second will include
the prior one.

It should say:

The value handshake_messages includes all handshake messages starting
at client hello up to, but not including, this finished message. This 
may be different from handshake_messages in Section 7.4.8 because it 
would include the certificate verify message (if sent). Also, the
handshake_messages for the finished message sent by the client will 
be different from that for the finished message sent by the server, 
because the one which is sent second will include the prior one.

Notes:

The sentence about Sender.client and Sender.server is a remainder from the draft 2 and previous versions. The verification computation changed between draft 2 and draft 3 (as showed by rfcdiff http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-tls-protocol-03.txt ) but the sentence remained. It should be stripped as the Sender enumerated type is not even declared anymore.

RFC 2250, "RTP Payload Format for MPEG1/MPEG2 Video", January 1998

Source of RFC: avt (rai)

Errata ID: 782
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vishal B S
Date Reported: 2005-09-26
Held for Document Update by: Robert Sparks

Section 3.3 says:

 Payload Type: Distinct payload types should be assigned
          for video elementary streams and audio elementary streams.
          See [4] for payload type assignments.

        M bit:  For video, set to 1 on packet containing MPEG frame
          end code, 0 otherwise.  For audio, set to 1 on first packet of
          a "talk-spurt," 0 otherwise.

        PT:  MPEG video or audio stream ID.

It should say:

[see notes]

Notes:

Payload Type and PT mean the same in RTP header
So, there exists a repetition.

from pending

RFC 2253, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", December 1997

Note: This RFC has been obsoleted by RFC 4510, RFC 4514

Note: This RFC has been updated by RFC 3377

Source of RFC: asid (app)

Errata ID: 2664
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ross Shumway
Date Reported: 2010-12-08
Held for Document Update by: Alexey Melnikov

Throughout the document, when it says:

RFC 2253               LADPv3 Distinguished Names          December 1997

It should say:

RFC 2253               LDAPv3 Distinguished Names          December 1997

Notes:

This is a minor but annoying character transposition in the page headers.

RFC 2260, "Scalable Support for Multi-homed Multi-provider Connectivity", January 1998

Source of RFC: Legacy
Area Assignment: int

Errata ID: 1536
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Shiang-Ming Huang
Date Reported: 2008-10-03
Held for Document Update by: ron bonica

Section 7 says:

   Both the issue of address assignment and renumbering could be
   addressed by the appropriate use of network address translation
   (NAT). The use of NAT for multi-homed enterprises is the beyond the
   scope of this document.

It should say:

   Both the issue of address assignment and renumbering could be
   addressed by the appropriate use of network address translation
 | (NAT). The use of NAT for multi-homed enterprises is beyond the
   scope of this document.

RFC 2277, "IETF Policy on Character Sets and Languages", January 1998

Source of RFC: Legacy
Area Assignment: app

Errata ID: 1374
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Masatoshi Yamamoto
Date Reported: 2008-03-20
Held for Document Update by: Peter Saint-Andre

Section 4.1 says:

Many operations, including high quality formatting, text-to-speech
synthesis, searching, hyphenation, spellchecking and so on benefit
greatly from access to information about the language of a piece of
text. [WC 3.1.1.4].

It should say:

Many operations, including high quality formatting, text-to-speech
synthesis, searching, hyphenation, spellchecking and so on benefit
greatly from access to information about the language of a piece of
text. [WR 3.1.1.4].
       ^^

Notes:

"WC" --> "WR"

RFC 2288, "Using Existing Bibliographic Identifiers as Uniform Resource Names", February 1998

Source of RFC: urn (app)

Errata ID: 775
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-09-11
Held for Document Update by: Peter Saint-Andre

 

Once you have written RFC 2288 that defined three URN namespaces:
  ISSN, ISBN, and SICI.
The IANA "urn-namespaces" registry does not (and probably never
did) contain any pointers to RFC 2288.

Meanwhile, the 'ISSN' URN namespace definition has been restated
in RFC 3044, including an IANA registration -- according to and
using the template specified in RFC 2611 (BCP 33) [that in the
meantime has been obsoleted itself by RFC 3406 (BCP 66)] --,
and 'ISSN' currently appears as formal URN namespace #3 in the
IANA URN namespaces registry.

Similarly, the 'ISBN' URN namespace definition has been restated
in RFC 3187, including an IANA registration -- according to and
using the template specified in RFC 2611 --, and 'ISBN' currently
appears as formal URN namespace #9 in the IANA registry.

Now, RFC 2288 is *NOT* declared "Obsoleted" in the RFC index.
Contrary to that, the 'SICI' URN namespace does *NOT* appear
in the current IANA URN namespaces registry.
Thus the fate of the 'SICI' namespace and the status of RFC 2288
is questionable and unclear.

I suspect that RFC 2288 should be considered obsoleted, and
'SICI' should be considered deprecated.

So, what's to do in this case ?

According to my understanding of the established procedures,
the Informational RFC 2288 cannot easily be re-classified as
Historic, and a specific footnote about the deprecated 'SICI'
namespace would not be easily entered into the IANA registry.
Therefore, to make the situation clearly understandable for
everyone, it seems easiest to have the RFC-Ed add the note
   '(Obsoleted by 3044, RFC 3187)'
to the RFC index entry for RFC 2288.

It should say:

[see above]

Notes:

from pending

RFC 2296, "HTTP Remote Variant Selection Algorithm -- RVSA/1.0", March 1998

Source of RFC: http (app)

Errata ID: 4539
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Florian Best
Date Reported: 2015-11-19
Held for Document Update by: Barry Leiba
Date Held: 2015-11-19

Section 3.3 says:

   and if the request contains the Accept- headers

     Accept: text/html:q=1.0, */*:q=0.8
     Accept-Language: en;q=1.0, fr;q=0.5

It should say:

   and if the request contains the Accept- headers

     Accept: text/html;q=1.0, */*;q=0.8
     Accept-Language: en;q=1.0, fr;q=0.5

Notes:

(quality) parameter must be separated by ";" instead of ":".

RFC 2307, "An Approach for Using LDAP as a Network Information Service", March 1998

Source of RFC: Legacy
Area Assignment: app

Errata ID: 462
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Pierre Beyssac
Date Reported: 2004-11-25
Held for Document Update by: Peter Saint-Andre

Section 4 says:

        ( nisSchema.2.4 NAME 'ipProtocol' SUP top STRUCTURAL
          DESC 'Abstraction of an IP protocol. Maps a protocol number
                to one or more names. The distinguished value of the cn
                attribute denotes the protocol's canonical name'
          MUST ( cn $ ipProtocolNumber $ description )
          MAY description )

It should say:

        ( nisSchema.2.4 NAME 'ipProtocol' SUP top STRUCTURAL
          DESC 'Abstraction of an IP protocol. Maps a protocol number
                to one or more names. The distinguished value of the cn
                attribute denotes the protocol's canonical name'
          MUST ( cn $ ipProtocolNumber )
          MAY description )

RFC 2308, "Negative Caching of DNS Queries (DNS NCACHE)", March 1998

Note: This RFC has been updated by RFC 4035, RFC 4033, RFC 4034, RFC 6604, RFC 8020, RFC 8499, RFC 9499, RFC 9520

Source of RFC: dnsind (int)

Errata ID: 4627
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2016-02-26
Held for Document Update by: Brian Haberman
Date Held: 2016-03-01

Section 9 says:

   The history of the early CHIVES work (Section 9.1) was supplied by
   Rob Austein <sra@epilogue.com> and is reproduced here in the form in
   which he supplied it [MPA].

   Sometime around the spring of 1985, I mentioned to Paul Mockapetris
   that our experience with his JEEVES DNS resolver had pointed out the
   need for some kind of negative caching scheme.  Paul suggested that
   we simply cache authoritative errors, using the SOA MINIMUM value for
   the zone that would have contained the target RRs.  I'm pretty sure
   that this conversation took place before RFC-973 was written, but it
   was never clear to me whether this idea was something that Paul came
   up with on the spot in response to my question or something he'd
   already been planning to put into the document that became RFC-973.
   In any case, neither of us was entirely sure that the SOA MINIMUM
   value was really the right metric to use, but it was available and
   was under the control of the administrator of the target zone, both
   of which seemed to us at the time to be important feature.

It should say:

   The history of the early CHIVES work (Section 9.1) was supplied by
   Rob Austein <sra@epilogue.com> and is reproduced here in the form in
   which he supplied it [MPA].

9.1 CHIVES 
   Sometime around the spring of 1985, I mentioned to Paul Mockapetris
   that our experience with his JEEVES DNS resolver had pointed out the
   need for some kind of negative caching scheme.  Paul suggested that
   we simply cache authoritative errors, using the SOA MINIMUM value for
   the zone that would have contained the target RRs.  I'm pretty sure
   that this conversation took place before RFC-973 was written, but it
   was never clear to me whether this idea was something that Paul came
   up with on the spot in response to my question or something he'd
   already been planning to put into the document that became RFC-973.
   In any case, neither of us was entirely sure that the SOA MINIMUM
   value was really the right metric to use, but it was available and
   was under the control of the administrator of the target zone, both
   of which seemed to us at the time to be important feature.

Notes:

Section name are referenced but absent.

Errata ID: 4628
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2016-02-26
Held for Document Update by: Brian Haberman
Date Held: 2016-03-01

Section References says:

It should say:

[MPA] ??? 

Notes:

Section 9 says
The history of the early CHIVES work (Section 9.1) was supplied by
Rob Austein <sra@epilogue.com> and is reproduced here in the form in
which he supplied it [MPA].

But [MPA] reference not included into Reference section.
I can't find original publication (Rob Austein) referenced by [MPA]

Errata ID: 4632
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2016-03-02
Held for Document Update by: Brian Haberman
Date Held: 2016-03-02

Section 11 says:

   For such an attack to be successful, the NXDOMAIN indiction must be
   injected into a parent server (or a busy caching resolver).  One way
   this might be done by the use of a CNAME which results in the parent
   server querying an attackers server.  Resolvers that wish to prevent
   such attacks can query again the final QNAME ignoring any NS data in
   the query responses it has received for this query.

It should say:

   For such an attack to be successful, the NXDOMAIN indication must be
   injected into a parent server (or a busy caching resolver).  One way
   this might be done by the use of a CNAME which results in the parent
   server querying an attackers server.  Resolvers that wish to prevent
   such attacks can query again the final QNAME ignoring any NS data in
   the query responses it has received for this query.

Notes:

A typo in the word "indication".

Errata ID: 4983
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2017-03-28
Held for Document Update by: Éric Vyncke
Date Held: 2024-01-12

Section 1 says:

   "QNAME" - the name in the query section of an answer, or where this
   resolves to a CNAME, or CNAME chain, the data field of the last
   CNAME.

It should say:

   "QNAME" - the name in the query section (RFC 1034, section 3.7.1).

Notes:

RFC 2308 is the only RFC that defines QNAME this way. Original definition in RFC 1034 is clear, and is used by all other RFC since. (This point was raised during the development of RFC 8020, and is now discussed in the context of draft-ietf-dnsop-terminology-bis)

-- verifier note --

RFC 8499 (replacing draft-ietf-dnsop-terminology-bis) notes that there are indeed several definitions of "QNAME".

RFC 2317, "Classless IN-ADDR.ARPA delegation", March 1998

Source of RFC: dnsind (int)

Errata ID: 1474
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Justin Pryzby
Date Reported: 2008-07-17
Held for Document Update by: Brian Haberman

Section 4 says:

the the first component

It should say:

the first component

RFC 2319, "Ukrainian Character Set KOI8-U", April 1998

Source of RFC: INDEPENDENT

Errata ID: 2812
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-05-22
Held for Document Update by: ron bonica

Section Abstract says:

Abstract

   This document provides information about character encoding KOI8-U
   (KOI8 Ukrainian) wich is a de-facto standard in Ukrainian Internet
   community.  KOI8-U is compatible with KOI8-R (RFC 1489) in all
   Russian letters and extends it with four Ukrainian letters which
   locations are compliant with ISO-IR-111.  The official site of KOI8-U
   Working Group is http://www.net.ua.

It should say:

Abstract

   This document provides information about character encoding KOI8-U
   (KOI8 Ukrainian) which is a de-facto standard in Ukrainian Internet
   community.  KOI8-U is compatible with KOI8-R (RFC 1489) in all
   Russian letters and extends it with four Ukrainian letters which
   locations are compliant with ISO-IR-111.  The official site of KOI8-U
   Working Group is http://www.net.ua.

Notes:

A typo in "which": s/wich/which

RFC 2322, "Management of IP numbers by peg-dhcp", April 1998

Source of RFC: INDEPENDENT

Errata ID: 5753
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Adam Schumacher
Date Reported: 2019-06-14
Held for Document Update by: Warren Kumari (Ops AD)
Date Held: 2019-06-14

Section Security says:

But, once the peg is attached to a network cable, 
the chance to loose the peg is minimized.

It should say:

But, once the peg is attached to a network cable, 
the chance to lose the peg is minimized.

Notes:

Although there is a possibility that the author intended to use the verb form of "loose", implying that there would be a chance to unbind the peg to go about its own business, it's more likely that they intended to refer to the situation where the peg is lost, rather than simply released.

RFC 2327, "SDP: Session Description Protocol", April 1998

Note: This RFC has been obsoleted by RFC 4566

Note: This RFC has been updated by RFC 3266

Source of RFC: mmusic (rai)

Errata ID: 458
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Richard Walters
Date Reported: 2005-08-01
Held for Document Update by: Robert Sparks

Section 6 says:

      An example of a static payload type is u-law PCM coded single
      channel audio sampled at 8KHz.  This is completely defined in the
      RTP Audio/Video profile as payload type 0, so the media field for
      such a stream sent to UDP port 49232 is:

                            m=video 49232 RTP/AVP 0

      An example of a dynamic payload type is 16 bit linear encoded
      stereo audio sampled at 16KHz.  If we wish to use dynamic RTP/AVP
      payload type 98 for such a stream, additional information is
      required to decode it:

                           m=video 49232 RTP/AVP 98

It should say:

      An example of a static payload type is u-law PCM coded single
      channel audio sampled at 8KHz.  This is completely defined in the
      RTP Audio/Video profile as payload type 0, so the media field for
      such a stream sent to UDP port 49232 is:

                            m=audio 49232 RTP/AVP 0

      An example of a dynamic payload type is 16 bit linear encoded
      stereo audio sampled at 16KHz.  If we wish to use dynamic RTP/AVP
      payload type 98 for such a stream, additional information is
      required to decode it:

                           m=audio 49232 RTP/AVP 98

Notes:

The examples refer to audio but show the media type as "video". I believe
the author intended to put "m=audio" but "m=video" was put in by mistake.

Errata ID: 1093
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jim Bell
Date Reported: 2007-12-17
Held for Document Update by: Robert Sparks

Section 6 says:

The following unit specification characters are allowed:

                         d - days (86400 seconds)
                        h - minutes (3600 seconds)
                         m - minutes (60 seconds)

It should say:

The following unit specification characters are allowed:

                         d - days (86400 seconds)
                        h - hours (3600 seconds)
                         m - minutes (60 seconds)

Notes:

I believe the author means "h" for "hours" and "m" for "minutes" unambiguously.

RFC 2328, "OSPF Version 2", April 1998

Note: This RFC has been updated by RFC 5709, RFC 6549, RFC 6845, RFC 6860, RFC 7474, RFC 8042, RFC 9355, RFC 9454

Source of RFC: ospf (rtg)

Errata ID: 3645
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Preet D'Souza
Date Reported: 2013-06-07
Held for Document Update by: Stewart Bryant
Date Held: 2013-09-19

Section 2.1.2 says:

Figure 2: A sample Autonomous System

                                **FROM**

                 |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|
                 |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9|
              ----- ---------------------------------------------
              RT1|  |  |  |  |  |  |  |  |  |  |  |  |0 |  |  |  |
              RT2|  |  |  |  |  |  |  |  |  |  |  |  |0 |  |  |  |
              RT3|  |  |  |  |  |6 |  |  |  |  |  |  |0 |  |  |  |
              RT4|  |  |  |  |8 |  |  |  |  |  |  |  |0 |  |  |  |
              RT5|  |  |  |8 |  |6 |6 |  |  |  |  |  |  |  |  |  |
              RT6|  |  |8 |  |7 |  |  |  |  |5 |  |  |  |  |  |  |
              RT7|  |  |  |  |6 |  |  |  |  |  |  |  |  |0 |  |  |
          *   RT8|  |  |  |  |  |  |  |  |  |  |  |  |  |0 |  |  |
          *   RT9|  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |0 |
          T  RT10|  |  |  |  |  |7 |  |  |  |  |  |  |  |0 |0 |  |
          O  RT11|  |  |  |  |  |  |  |  |  |  |  |  |  |  |0 |0 |
          *  RT12|  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |0 |
          *    N1|3 |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
               N2|  |3 |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
               N3|1 |1 |1 |1 |  |  |  |  |  |  |  |  |  |  |  |  |
               N4|  |  |2 |  |  |  |  |  |  |  |  |  |  |  |  |  |
               N6|  |  |  |  |  |  |1 |1 |  |1 |  |  |  |  |  |  |
               N7|  |  |  |  |  |  |  |4 |  |  |  |  |  |  |  |  |
               N8|  |  |  |  |  |  |  |  |  |3 |2 |  |  |  |  |  |
               N9|  |  |  |  |  |  |  |  |1 |  |1 |1 |  |  |  |  |
              N10|  |  |  |  |  |  |  |  |  |  |  |2 |  |  |  |  |
              N11|  |  |  |  |  |  |  |  |3 |  |  |  |  |  |  |  |
              N12|  |  |  |  |8 |  |2 |  |  |  |  |  |  |  |  |  |
              N13|  |  |  |  |8 |  |  |  |  |  |  |  |  |  |  |  |
              N14|  |  |  |  |8 |  |  |  |  |  |  |  |  |  |  |  |
              N15|  |  |  |  |  |  |9 |  |  |  |  |  |  |  |  |  |
               H1|  |  |  |  |  |  |  |  |  |  |  |10|  |  |  |  |

It should say:

Figure 2: A sample Autonomous System

                                **FROM**

                 |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|
                 |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9|
              ----- ---------------------------------------------
              RT1|  |  |  |  |  |  |  |  |  |  |  |  |0 |  |  |  |
              RT2|  |  |  |  |  |  |  |  |  |  |  |  |0 |  |  |  |
              RT3|  |  |  |  |  |6 |  |  |  |  |  |  |0 |  |  |  |
              RT4|  |  |  |  |8 |  |  |  |  |  |  |  |0 |  |  |  |
              RT5|  |  |  |8 |  |6 |6 |  |  |  |  |  |  |  |  |  |
              RT6|  |  |8 |  |7 |  |  |  |  |5 |  |  |  |  |  |  |
              RT7|  |  |  |  |6 |  |  |  |  |  |  |  |  |0 |  |  |
          *   RT8|  |  |  |  |  |  |  |  |  |  |  |  |  |0 |  |  |
          *   RT9|  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |0 |
          T  RT10|  |  |  |  |  |7 |  |  |  |  |  |  |  |0 |0 |  |
          O  RT11|  |  |  |  |  |  |  |  |  |  |  |  |  |  |0 |0 |
          *  RT12|  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |0 |
          *    N1|3 |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
               N2|  |3 |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
               N3|1 |1 |1 |1 |  |  |  |  |  |  |  |  |  |  |  |  |
               N4|  |  |2 |  |  |  |  |  |  |  |  |  |  |  |  |  |
               N6|  |  |  |  |  |  |1 |1 |  |1 |  |  |  |  |  |  |
               N7|  |  |  |  |  |  |  |4 |  |  |  |  |  |  |  |  |
               N8|  |  |  |  |  |  |  |  |  |3 |2 |  |  |  |  |  |
               N9|  |  |  |  |  |  |  |  |1 |  |1 |1 |  |  |  |  |
              N10|  |  |  |  |  |  |  |  |  |  |  |2 |  |  |  |  |
              N11|  |  |  |  |  |  |  |  |3 |  |  |  |  |  |  |  |
              N12|  |  |  |  |8 |  |2 |  |  |  |  |  |  |  |  |  |
              N13|  |  |  |  |8 |  |  |  |  |  |  |  |  |  |  |  |
              N14|  |  |  |  |8 |  |  |  |  |  |  |  |  |  |  |  |
              N15|  |  |  |  |  |  |9 |  |  |  |  |  |  |  |  |  |
               H1|  |  |  |  |  |  |  |  |  |  |  |10|  |  |  |  |
               Ia|  |  |  |  |  |  |  |  |  |5 |  |  |  |  |  |  |
               Ib|  |  |  |  |  |7 |  |  |  |  |  |  |  |  |  |  |

Notes:

Notes:

section 2.1.2

Page 20, Figure 2 : A sample Autonomous System.
Two additions have been made to the orginal text which are reflected in the Corrected text.
The last two rows for interfaces Ia and Ib have been added.
The reason for the same is as explained below.

By definition of point-to-point links under OSPF, for serial interfaces defined by IP addresses, router RT6 should advertise a stub network to Ib whereas router RT10 should advertise a stub network to Ia .

Verifier's note: RFC 2328 is not wrong without the stubs links.
However, it does no harm to include them.

This table should be looked at in any future revision of this
RFC.

Errata ID: 2394
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Andrea Ceschia
Date Reported: 2010-07-29
Held for Document Update by: Stewart Bryant
Date Held: 2012-10-26

Section 3.4. says:

Table 5: Backbone distances calculated by Routers RT3 and RT4

                              dist  from   dist  from
                              RT3          RT4

                   to  Ia     20           27
                   to  Ib     15           22

It should say:

Table 5: Backbone distances calculated by Routers RT3 and RT4.

                              dist  from   dist  from
                              RT3          RT4

                   to  Ia     15           22
		   to  Ib     20           27

Notes:

From RT3 and RT4 perspective the Ia is the nearest interface while Ib is at the remote side of the link connecting RT6 to RT10.

Errata ID: 1420
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2008-05-11
Held for Document Update by: Stewart Bryant

Section 11.3 says:

The routing table entries changes that
would be caused by the addition of this virtual link are shown
in Table 14.

It should say:

N/A

Notes:

But Table 14 is exiled in another section, section 12, where it has nothing to do. I assume some processor tried to avoid splitting the table and displaced it too far.

Errata ID: 1833
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dande Rajasekhar
Date Reported: 2009-08-19
Held for Document Update by: Stewart Bryant

Section 2.1.1 says:

Figure 1b illustrates the link-state database representation
	    of a Point-to-MultiPoint network. On the left side of the
	    figure, a Point-to-MultiPoint network is pictured. It is
	    assumed that all routers can communicate directly, except
	    for	routers	RT4 and	RT5. I3	though I6 indicate the routers'

It should say:

Figure 1b illustrates the link-state database representation
	    of a Point-to-MultiPoint network. On the left side of the
	    figure, a Point-to-MultiPoint network is pictured. It is
	    assumed that all routers can communicate directly, except
	    for	routers	RT4 and	RT5. I3	through I6 indicate the routers'

Notes:

Should be I3 *through* I6

Errata ID: 4257
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eugene M. Kim
Date Reported: 2015-02-04
Held for Document Update by: Alia Atlas
Date Held: 2015-03-03

Section 2.1.1 says:

In NBMA mode, OSPF emulates operation over a broadcast
network: a Designated Router is elected for the NBMA
network, and the Designated Router originates an LSA for the
network. The graph representation for broadcast networks and
NBMA networks is identical. This representation is pictured
in the middle of Figure 1a.

It should say:

In NBMA mode, OSPF emulates operation over a broadcast
network: a Designated Router is elected for the NBMA
network, and the Designated Router originates an LSA for the
network. The graph representation for broadcast networks and
NBMA networks is identical. This representation is pictured
in the bottom of Figure 1a.

Notes:

The bottom, not middle, of Figure 1a depicts the identical graph representation of broadcast and NBMA networks.

RFC 2334, "Server Cache Synchronization Protocol (SCSP)", April 1998

Source of RFC: ion (int)

Errata ID: 1922
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michelle Cotton
Date Reported: 2009-10-21
Held for Document Update by: Brian Haberman

Section B.3.1.2 says:

   The default hash algorithm to be supported is HMAC-MD5-128 [11]. HMAC
   is safer than normal keyed hashes. Other hash algorithms MAY be
   supported by def.

   IANA will assign the numbers to identify the algorithm being used as
   described in Section C.

It should say:

   The default hash algorithm to be supported is HMAC-MD5-128 [11]. HMAC
   is safer than normal keyed hashes. Other hash algorithms MAY be
   supported by def.

Notes:

Removed last paragraph in section B.3.1.2. After doing a review of RFC2334 for any incomplete IANA actions, IANA contacted an author to confirm if a registry for the algorithms needed to be set-up. Joel Halpern confirmed that it the actual purpose of the section is only to make sure that there is something eveyrone can use for interoperability. He suggested I submit an errata for the removal of the last paragraph.

RFC 2350, "Expectations for Computer Security Incident Response", June 1998

Source of RFC: grip (ops)

Errata ID: 3498
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Koen Van Impe
Date Reported: 2013-02-25
Held for Document Update by: Benoit Claise

Section 3.6 says:

3.6 Incident Reporting Forms

...

One example of such a form is the Incident Reporting Form provided by
   the CERT Coordination Center:

   - ftp://info.cert.org/incident_reporting_form

It should say:

...

 - https://www.cert.be/pro/report-incident

Notes:

The URL with an example of an Incident Reporting Form is wrong. The hostname 'info.cert.org' no longer resolves. CERT.be still has a copy of a sample Incident Reporting Form.

Errata ID: 3902
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christian Keil
Date Reported: 2014-02-26
Held for Document Update by: Benoit Claise
Date Held: 2014-04-15

Section Appendix B says:

[...]

  Other documents of interest for the discussion of CSIRTs and their
  tasks are available by anonymous FTP. A collection can be found on:

  - ftp://ftp.cert.dfn.de/pub/docs/csir/
    Please refer to file 01-README for further information about
    the content of this directory.

[...]

   - http://www.cert.dfn.de/eng/team/kpk/certbib.html
     This document contains an annotated bibliography of available
     material, documents and files about the operation of CSIRTs
     with links to many of the referenced items.

It should say:

[...]

  Other documents of interest for the discussion of CSIRTs and their
  tasks are available from the CERT Coordination Center and ENISA

  - https://www.cert.org/incident-management/csirt-development/index.cfm
    A collection of documents by the CERT Coordination Center on CSIRT
    Development.

  - http://www.enisa.europa.eu/activities/cert/support
    This page contains practice material that aims at helping EU Member
    States, but also other stakeholders, to smoothly establish and
    operate CERTs / CSIRTs.

Notes:

The previously referenced resources do not exist anymore. They should be either removed or replaced by references to the available resources from CERT and ENISA.

Errata ID: 3903
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christian Keil
Date Reported: 2014-02-26
Held for Document Update by: Benoit Claise
Date Held: 2014-04-15

Section Appendix C says:

[...]

  Many of the European teams, regardless of whether they are members
  of FIRST or not, are listed by countries on a page maintained by
  the German CSIRT:

  - http://www.cert.dfn.de/eng/csir/europe/certs.html

It should say:

[...]

  Many of the European teams, regardless of whether they are members
  of FIRST or not, are listed by countries on a page maintained by
  the Trusted Introducer Service (TI):

  - http://www.trusted-introducer.org/directory/index.html

Notes:

The list of European teams is no longer maintained by DFN-CERT but by TI.

RFC 2361, "WAVE and AVI Codec Registries", June 1998

Source of RFC: Legacy
Area Assignment: rai

Errata ID: 1255
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Cullen Jennings
Date Reported: 2008-01-11
Held for Document Update by: Robert Sparks

In Appendix A, it says:

  A.104   DVM

It should say:

  A.104   AC3 DVM

Notes:

Change to match the change being made to the IANA registry. This corrects the name so that when people search for the codepoint for the AC3 codec, they find this (which is the commonly used code point for AC3 instead of code point 0x0092)

Errata ID: 5125
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: David Russo
Date Reported: 2017-09-24
Held for Document Update by: RFC Editor
Date Held: 2024-02-15

Section Appendix A says:

A.40    Rockwell Digit LK

It should say:

A.40    Rockwell DigiTalk

Notes:

The existing text matches what appears in the Internet-Draft (https://datatracker.ietf.org/doc/draft-fleischman-codec-subtree/01/) and the IANA registry (https://www.iana.org/assignments/wave-avi-codec-registry/).

RFC 2367, "PF_KEY Key Management API, Version 2", July 1998

Source of RFC: Legacy

Errata ID: 6534
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Juli Mallett
Date Reported: 9999-04-13
Held for Document Update by: Benjamin Kaduk
Date Held: 2021-04-13

Throughout the document, when it says:

          Acknowledgments ............,............................. 52

It should say:

          Acknowledgments .......................................... 52

Notes:

Correct punctuation (stray comma)

RFC 2384, "POP URL Scheme", August 1998

Source of RFC: Legacy

Errata ID: 2942
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Frank Ellermann
Date Reported: 2011-08-18
Held for Document Update by: Peter Saint-Andre
Date Held: 2011-11-15

Section 7 says:

   The URL:

        <pop://baz;AUTH=SCRAM-MD5@foo.bar>

   Results in the following client commands:

        <connect to foo.bar, port 110>

        S: +OK POP3 server ready <1896.697170952@foo.bar>
        C: AUTH SCRAM-MD5 AGNocmlzADx0NG40UGFiOUhCMEFtL1FMWEI3MmVnQGVsZW

It should say:

   The URL:

        <pop://baz;AUTH=CRAM-MD5@foo.bar>

   Results in the following client commands:

        <connect to foo.bar, port 110>

        S: +OK POP3 server ready <1896.697170952@foo.bar>
        C: AUTH CRAM-MD5 AGNocmlzADx0NG40UGFiOUhCMEFtL1FMWEI3MmVnQGVsZW

Notes:

The name of the SASL mechanism based on RFC 2222 when this RFC was published is CRAM-MD5 specified in RFC 2195. This is unrelated to the SCRAM-family of SASL mechanisms specified in RFC 5802. Section 4 in RFC 2384 explains the intended SASL POP mechanism names; notably no "S" to indicate SASL.

VERIFIER NOTE: We could change "SCRAM-MD5" to "CRAM-MD5", but we would need to modify the Base64 at the same time. This should be done through a document update or a separate erratum.

RFC 2385, "Protection of BGP Sessions via the TCP MD5 Signature Option", August 1998

Note: This RFC has been obsoleted by RFC 5925

Note: This RFC has been updated by RFC 6691

Source of RFC: idr (rtg)

Errata ID: 4432
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Florin Frigioiu
Date Reported: 2015-08-04
Held for Document Update by: Alvaro Retana
Date Held: 2015-08-05

Section 4.3 says:

   The total header size is also an issue.  The TCP header specifies
   where segment data starts with a 4-bit field which gives the total
   size of the header (including options) in 32-byte words.  This means
   that the total size of the header plus option must be less than or
   equal to 60 bytes -- this leaves 40 bytes for options.

It should say:

   The total header size is also an issue.  The TCP header specifies
   where segment data starts with a 4-bit field which gives the total
   size of the header (including options) in 32-bit words.  This means
   that the total size of the header plus option must be less than or
   equal to 60 bytes -- this leaves 40 bytes for options.

Notes:

Correction for '32-byte words' to '32-bit words'.

RFC 2387, "The MIME Multipart/Related Content-type", August 1998

Source of RFC: mhtml (app)

Errata ID: 3386
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Thomas Lane
Date Reported: 2012-10-18
Held for Document Update by: Barry Leiba

Section 5.1 says:

The example below, uses a single data block.

     Content-Type: Multipart/Related; boundary=example-1
             start="<950120.aaCC@XIson.com>";
             type="Application/X-FixedRecord"
             start-info="-o ps"

It should say:

The example below, uses a single data block.

     Content-Type: Multipart/Related; boundary=example-1;
             start="<950120.aaCC@XIson.com>";
             type="Application/X-FixedRecord";
             start-info="-o ps"

<OR>

The example below, uses a single data block.

     Content-Type: Multipart/Related
             ;boundary=example-1
             ;start="<950120.aaCC@XIson.com>"
             ;type="Application/X-FixedRecord"
             ;start-info="-o ps"

Notes:

Missing ";"s in parameter list.


RFC 2045 says:

content := "Content-Type" ":" type "/" subtype
*(";" parameter)

Errata ID: 3387
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Thomas Lane
Date Reported: 2012-10-18
Held for Document Update by: Barry Leiba

Section 5.2 says:

Content-Type: Multipart/Related; boundary=example-2;
             start="<950118.AEBH@XIson.com>"
             type="Text/x-Okie"

It should say:

Content-Type: Multipart/Related; boundary=example-2;
             start="<950118.AEBH@XIson.com>";
             type="Text/x-Okie"

<OR>

Content-Type: Multipart/Related
              ;boundary=example-2
              ;start="<950118.AEBH@XIson.com>"
              ;type="Text/x-Okie"

Notes:

Another missing ';' [see erratum for Section 5.1].

Errata ID: 5048
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Adrian Kennard
Date Reported: 2017-06-22
Held for Document Update by: Barry Leiba
Date Held: 2019-04-30

Section 3.4 says:

related-param   := [ ";" "start" "=" cid ]
                        [ ";" "start-info"  "="
                           ( cid-list / value ) ]
                        [ ";" "type"  "=" type "/" subtype ]
                        ; order independent

It should say:

Unsure of best way to express this, but this syntax does not seem
to allow for the values to be in quotes. e.g. type="text/html"
rather than type=text/html

Notes:

Basically, the examples all have quotes around the values, e.g. type="Application/X-FixedRecord" rather than type=Application/X-FixedRecord

It appears that Yahoo email cannot accept type=text/html as per "syntax" in 3.4, but will accept type="text/html" which is consistent with the examples

The examples in the RFC currently do not comply with the RFC.

----- Verifier Notes -----
I think the last sentence in the submitter's notes is the correct one: it's the examples that are wrong, not the ABNF -- the values are not intended to be in quotes. In any case, this needs to be dealt with in a revision of the document, so we're sure we get it right and consider what multiple implementations are doing.

Errata ID: 3389
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Thomas Lane
Date Reported: 2012-10-18
Held for Document Update by: Barry Leiba

Section 6 says:

MIME User Agents that do recognize Multipart/Related entities but are
unable to process the given type should give the user the option of
suppressing the entire Multipart/Related body part shall be.

It should say:

MIME User Agents that do recognize Multipart/Related entities but are
unable to process the given type SHOULD give the user the option of
suppressing the entire Multipart/Related [some grammatically well-formed English].

Notes:

Capitalize the keyword SHOULD.

the entire Multipart/Related body part? the entire Multipart/Related body? all the Multipart/Related content? the entire Multipart/Related body, or just the particular body part of unrecognized type? I'm not sure what this was originally intended to say, just that what's there is a typo.

Errata ID: 3574
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Robert Lee
Date Reported: 2013-03-29
Held for Document Update by: Barry Leiba
Date Held: 2013-03-29

Section 6.4 says:

   It is suggested that MUAs that use configuration mechanisms, see
   [CFG] for an example, refer to Multipart/Related as Multi-
   part/Related/<type>, were <type> is the value of the "type"
   parameter.

It should say:

   It is suggested that MUAs that use configuration mechanisms
   refer to Multipart/Related as Multipart/Related/<type>,
   where <type> is the value of the "type" parameter. See [CFG]
   for examples of configuration mechanism usage in MUAs.

Notes:

Changed "were" to "where". Also reworded the "CFG" reference to be easier to read.

=== Verifier notes ===
Minor typos and insignificant rewording -- goes into "held for document update".

RFC 2388, "Returning Values from Forms: multipart/form-data", August 1998

Note: This RFC has been obsoleted by RFC 7578

Source of RFC: Legacy
Area Assignment: app

Errata ID: 2011
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2010-01-21
Held for Document Update by: Peter Saint-Andre

Section boilerplate says:

Network Working Group                                         L. Masinter
Request for Comments: 2388                              Xerox Corporation
Category: Standards Track                                     August 1998

It should say:

Network Working Group                                         L. Masinter
Request for Comments: 2388                              Xerox Corporation
Updates: 1867                                                 August 1998
Category: Standards Track

Notes:

RFC 2388 updated the definition of multipart/form-data, which was previously defined in RFC 1867. It appears the RFC Index should reflect that.

Errata ID: 5410
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sébastien Puyet
Date Reported: 2018-06-26
Held for Document Update by: Alexey Melnikov
Date Held: 2018-07-26

Section 4.1 says:

   As with other multipart types, a boundary is selected that does not
   occur in any of the data. Each field of the form is sent, in the
   order defined by the sending appliction and form, as a part of the
   multipart stream.  Each part identifies the INPUT name within the
   original form. Each part should be labelled with an appropriate
   content-type if the media type is known (e.g., inferred from the file
   extension or operating system typing information) or as
   "application/octet-stream".

It should say:

   As with other multipart types, a boundary is selected that does not
   occur in any of the data. Each field of the form is sent, in the
   order defined by the sending application and form, as a part of the
   multipart stream.  Each part identifies the INPUT name within the
   original form. Each part should be labelled with an appropriate
   content-type if the media type is known (e.g., inferred from the file
   extension or operating system typing information) or as
   "application/octet-stream".

Notes:

A typo is present in the second sentence, the word "appliction" should be "application".

Alexey: why this is correct, this is unlikely to get readers confused. So marking it as "held for document update".

RFC 2391, "Load Sharing using IP Network Address Translation (LSNAT)", August 1998

Source of RFC: Legacy
Area Assignment: tsv

Errata ID: 1847
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yin Gaosong
Date Reported: 2009-09-07
Held for Document Update by: Wes Eddy

The Abstract says:

NATs have traditionally been been used to allow private network
domains to connect to Global networks using as few as one globally 
unique IP address.

It should say:

NATs have traditionally been used to allow private network
domains to connect to Global networks using as few as one globally 
unique IP address.

Notes:

repetition of "been"

RFC 2392, "Content-ID and Message-ID Uniform Resource Locators", August 1998

Source of RFC: mhtml (app)

Errata ID: 3382
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Thomas Lane
Date Reported: 2012-10-17
Held for Document Update by: Barry Leiba

Section 2 says:

Content-Type: multipart/related; boundary="boundary-example-1";
                   type=Text/HTML

--boundary-example 1
     Content-Type: Text/HTML; charset=US-ASCII

It should say:

Content-Type: multipart/related; boundary="boundary-example-1";
                   type=Text/HTML

--boundary-example-1
     Content-Type: Text/HTML; charset=US-ASCII

Notes:

Missing dash in first boundary string. I omitted the page break that was between the Content-Type header and the boundary.

Errata ID: 6175
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Witten (mfwitten)
Date Reported: 2020-05-16
Held for Document Update by: Barry Leiba
Date Held: 2020-05-16

Section 2 says:

However, in many systems that store messages,
body parts are not indexed independently
their context (message).

It should say:

However, in many systems that store messages,
body parts are not indexed independently of
their context (message).

Notes:

The word "of" is missing after "independently" in "independently their context".

RFC 2396, "Uniform Resource Identifiers (URI): Generic Syntax", August 1998

Note: This RFC has been obsoleted by RFC 3986

Note: This RFC has been updated by RFC 2732

Source of RFC: Legacy
Area Assignment: app

Errata ID: 1933
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Skip Geel
Date Reported: 2009-10-25
Held for Document Update by: Peter Saint-Andre
Date Held: 2010-11-11

Section appendix B says:

^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?

It should say:

/^(([^:\/?#]+):)?(\/\/([^\/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?/

Notes:

A Regular Expression is delimited by the slash ("/"). Within it a slash should be preceded by a back-slash ("\").

Peter: This also applies to RFC 3986.

RFC 2397, "The "data" URL scheme", August 1998

Source of RFC: Legacy

Errata ID: 3214
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2012-05-06
Held for Document Update by: Barry Leiba

Section 3 says:

   Attribute values in [RFC2045] are allowed to be either represented as
   tokens or as quoted strings. However, within a "data" URL, the
   "quoted-string" representation would be awkward, since the quote mark
   is itself not a valid urlchar. For this reason, parameter values
   should use the URL Escaped encoding instead of quoted string if the
   parameter values contain any "tspecial".

Notes:

This advice does not work when the character is a delimiter such as ";".

Example media type:

text/plain;foo="bar;charset=iso-8859-1";charset=UTF-8

...represented as-is in data uri:

data:text/plain;foo=%22bar;charset=iso-8859-1%22;charset=UTF-8,...

...but following the advice from Section 3:

data:text/plain;foo=bar;charset=iso-8859-1;charset=UTF-8,...

which makes the charset parameter ambiguous.

Proposal for document update:

1) Keep the text pointing out double quotes will look awkward.

2) Insist on them being handled as per RFC 2045, when present.

3) Either remove the last sentence (after checking whether it's done in practice), or clarify which additional non-token characters are allowed here.

Errata ID: 4124
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Xue Fuqiao
Date Reported: 2014-09-26
Held for Document Update by: Barry Leiba
Date Held: 2014-09-27

Section 2 says:

   The <mediatype> is an Internet media type specification (with
   optional parameters.)

It should say:

   The <mediatype> is an Internet media type specification (with
   optional parameters).

Notes:

Periods go inside parentheses only if an entire sentence is inside the parentheses.

RFC 2410, "The NULL Encryption Algorithm and Its Use With IPsec", November 1998

Source of RFC: ipsec (sec)

Errata ID: 1925
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Thorsten Ulbricht
Date Reported: 2009-10-22
Held for Document Update by: Pasi Eronen

Section 7 says:

   [DOI]        Piper, D., "The Internet IP Security Domain of
                Interpretation for ISAKMP", RFC 2408, November 1998.

It should say:

   [DOI]        Piper, D., "The Internet IP Security Domain of
                Interpretation for ISAKMP", RFC 2407, November 1998.

RFC 2412, "The OAKLEY Key Determination Protocol", November 1998

Source of RFC: ipsec (sec)

Errata ID: 3960
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Daniel Kahn Gillmor
Date Reported: 2014-04-11
Held for Document Update by: Stephen Farrell
Date Held: 2014-05-08

Section 2.8 & Appx E says:

Section 2.8:

   [...] In order to maximize this, one can
   choose "strong" or Sophie Germaine primes, P = 2Q + 1, where P and Q
   are prime.  However, if P = kQ + 1, where k is small, then the
   strength of the group is still considerable.  These groups are known
   as Schnorr subgroups, and they can be found with much less
   computational effort than Sophie-Germaine primes.

   [...]

      [...]  For Sophie Germain primes, if the
      generator is a square, then there are only two elements in the
      subgroup: 1 and g^(-1) (same as g^(p-1)) which we have already
      recommended avoiding. 

Appendix E:

   [...] The
   primes are chosen to be Sophie Germain primes (i.e., (P-1)/2 is also
   prime), to have the maximum strength against the square-root attack
   on the discrete logarithm problem.

It should say:

Section 2.8:
   [...] In order to maximize this, one can
   choose safe primes, P = 2Q + 1, where P and Q
   are prime.  However, if P = kQ + 1, where k is small, then the
   strength of the group is still considerable.  These groups are known
   as Schnorr subgroups, and they can be found with much less
   computational effort than safe primes.

   [...]

      [...]  For safe primes, if the
      generator is a square, then there are only two elements in the
      subgroup: 1 and g^(-1) (same as g^(p-1)) which we have already
      recommended avoiding. 

Appendix E:
   [...] The
   primes are chosen to be safe primes (i.e., (P-1)/2 is also
   prime), to have the maximum strength against the square-root attack
   on the discrete logarithm problem.

Notes:

This is a terminology clarification.

For primes P and Q related such that P = 2Q + 1, P is a "safe prime" and Q is a "Sophie Germain prime" The draft gets this definition backward. The draft also suggests that "strong" primes are equivalent to Sophie Germain primes, which is not necessarily the case.

Section 2.8 also misspells "Germain" with an extra e at the end twice.

see for example: http://www.ams.org/journals/mcom/1996-65-213/S0025-5718-96-00670-9/S0025-5718-96-00670-9.pdf

RFC 2418, "IETF Working Group Guidelines and Procedures", September 1998

Note: This RFC has been updated by RFC 3934, RFC 7475, RFC 7776, RFC 8717, RFC 9141

Source of RFC: Poisson (gen)

Errata ID: 6130
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alvaro Retana
Date Reported: 2020-04-27
Held for Document Update by: Lars Eggert
Date Held: 2021-03-11

Section 3.3 says:

[4th paragraph in §3.3]

...   
   level of consensus.  The most common method used is for the working
   group chair to state what he or she believes to be the consensus view
   and. at the same time, requests comments from the list about the
   stated conclusion.

It should say:

...   
   level of consensus.  The most common method used is for the working
   group chair to state what he or she believes to be the consensus view
   and, at the same time, requests comments from the list about the
   stated conclusion.


s/and./and,

Notes:

Nit related to a misplaced "." instead of a ",".

RFC 2421, "Voice Profile for Internet Mail - version 2", September 1998

Note: This RFC has been obsoleted by RFC 3801

Source of RFC: Legacy
Area Assignment: app

Errata ID: 441
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2002-01-07
Held for Document Update by: Peter Saint-Andre

Appendix B says:

   SOUND;TYPE=32KADPCM;ENCODING=URI: CID:<part1@VM2-4321>
   REV:19951031T222710Z
   VERSION: 3.0
   END:VCARD

   --MessageBoundary_

It should say:

   SOUND;TYPE=32KADPCM;ENCODING=URI: CID:<part1@VM2-4321>
   REV:19951031T222710Z
   VERSION: 3.0
   END:VCARD

   --MessageBoundary--

Notes:

RFC 2046 multipart message close delimiter syntax.

Errata ID: 445
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2002-01-31
Held for Document Update by: Peter Saint-Andre

Section 15 says:

    Content-type: message/disposition-notification

    Reporting-UA: gregs-laptop.dallas.company.com (Unified FooMail 3.0)

    Original-Recipient: rfc822;22722@vm.company.com

It should say:

    Content-type: message/disposition-notification

    Reporting-UA: gregs-laptop.dallas.company.com (Unified FooMail 3.0)
    Original-Recipient: rfc822;22722@vm.company.com

Notes:

RFC 2298 does not permit extra CRLFs between fields
in a MDN. See the BNF in RFC 2298 section 3 (note that the CRLFs
there are the ones that terminate each header field).

RFC 2426, "vCard MIME Directory Profile", September 1998

Note: This RFC has been obsoleted by RFC 6350

Source of RFC: asid (app)

Errata ID: 1547
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Markus Lorenz
Date Reported: 2008-10-09
Held for Document Update by: Alexey Melnikov
Date Held: 2010-05-21

Section 4 says:

   img-inline-value     = binary-value
        ;Value MUST be "b" encoded image content

   img-inline-param
   ^^^^^^^^^^^^^^^^

   img-inline-param     = ("VALUE" "=" "binary")
                        / ("ENCODING" "=" "b")
                        / ("TYPE" "=" param-value
        ;TYPE value MUST be an IANA registered image type

It should say:

   img-inline-value     = binary-value
        ;Value MUST be "b" encoded image content

   img-inline-param     = ("VALUE" "=" "binary")
                        / ("ENCODING" "=" "b")
                        / ("TYPE" "=" param-value)
        ;TYPE value MUST be an IANA registered image type

Notes:

There is a definition of parameter "img-inline-param" without any assignment to it. The correct definition of "img-inline-param" follows in the next line.

Alexey: Also added a missing ")" at the end of img-inline-param definition.

Errata ID: 436
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vincent Ricard
Date Reported: 2002-08-01
Held for Document Update by: Peter Saint-Andre

Page 33 says:

   ;For name="CATEGORIES"
   param        = text-param
        ; Only text parameters allowed

   value        = text-list

It should say:

   ;For name="CATEGORIES"
   param        = text-param
        ; Only text parameters allowed

   value        = text-value-list

Errata ID: 437
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vincent Ricard
Date Reported: 2002-08-01
Held for Document Update by: Peter Saint-Andre

Section 4 says:

   ;For name="NICKNAME"
   param        = text-param
        ; Text parameters allowed
   value        = text-list

It should say:

   ;For name="NICKNAME"
   param        = text-param
        ; Text parameters allowed
   value        = text-value-list

Errata ID: 438
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vincent Ricard
Date Reported: 2002-08-01
Held for Document Update by: Peter Saint-Andre

Section 4 (p. 33) says:

  ;For name="CATEGORIES"
   param        = text-param
        ; Only text parameters allowed

   value        = text-list

Notes:

It should say:
;For name="CATEGORIES"
param = text-param
; Only text parameters allowed

value = text-value-list
</CORR>

Errata ID: 439
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vincent Ricard
Date Reported: 2002-08-01
Held for Document Update by: Peter Saint-Andre

Section 4 says:

   ;For name="NICKNAME"
   param        = text-param
        ; Text parameters allowed
   value        = text-list

It should say:

   ;For name="NICKNAME"
   param        = text-param
        ; Text parameters allowed
   value        = text-value-list

RFC 2445, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", November 1998

Note: This RFC has been obsoleted by RFC 5545

Source of RFC: calsch (app)

Errata ID: 3792
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Seak, Teng-Fong
Date Reported: 2013-11-10
Held for Document Update by: Barry Leiba
Date Held: 2013-11-10

Section 5 says:

     BEGIN:VCALENDAR PRODID:-//xyz Corp//NONSGML PDA Calendar Verson
     1.0//EN VERSION:2.0 BEGIN:VEVENT DTSTAMP:19960704T120000Z
     UID:uid1@host.com ORGANIZER:MAILTO:jsmith@host.com
     DTSTART:19960918T143000Z DTEND:19960920T220000Z STATUS:CONFIRMED
     CATEGORIES:CONFERENCE SUMMARY:Networld+Interop Conference
     DESCRIPTION:Networld+Interop Conference
       and Exhibit\nAtlanta World Congress Center\n
      Atlanta, Georgia END:VEVENT END:VCALENDAR

It should say:

     BEGIN:VCALENDAR
     PRODID:-//xyz Corp//NONSGML PDA Calendar Verson1.0//EN
     VERSION:2.0
     BEGIN:VEVENT
     DTSTAMP:19960704T120000Z
     UID:uid1@host.com
     ORGANIZER:MAILTO:jsmith@host.com
     DTSTART:19960918T143000Z
     DTEND:19960920T220000Z
     STATUS:CONFIRMED
     CATEGORIES:CONFERENCE
     SUMMARY:Networld+Interop Conference
     DESCRIPTION:Networld+Interop Conference
       and Exhibit\nAtlanta World Congress Center\n
      Atlanta, Georgia
     END:VEVENT
     END:VCALENDAR

Notes:

CRLF are missing in every content line. The example violates at least the very first definition of iCalendar object stated at section 4.4

icalobject = 1*("BEGIN" ":" "VCALENDAR" CRLF
icalbody
"END" ":" "VCALENDAR" CRLF)

----- Verifier Notes -----
Yes, and this was fixed in the updated document, RFC 5545. RFC 2445 has been
obsolete since 2009.

Errata ID: 3722
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfie John
Date Reported: 2013-09-11
Held for Document Update by: Barry Leiba
Date Held: 2013-09-11

Section 4.8.7.3 says:

Conformance: This property can be specified in the "EVENT", "VTODO",
"VJOURNAL" or "VTIMEZONE" calendar components.

It should say:

Conformance: This property can be specified in the "VEVENT", "VTODO",
"VJOURNAL" or "VTIMEZONE" calendar components.

Notes:

Verifier notes:
I'm marking this "hold for document update", according to the IESG's policy on errata
handling... but note that this document has already been updated: it is obsoleted by
RFC 5545, and this version (RFC 2445) should no longer be used. (And this typo was
corrected in RFC 5545, I'm happy to say.)

RFC 2446, "iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries", November 1998

Note: This RFC has been obsoleted by RFC 5546

Source of RFC: calsch (app)

Errata ID: 1709
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: David Riggle
Date Reported: 2009-03-07
Held for Document Update by: Lisa Dusseault

Section 4.4.7 says:

Error! Bookmark not defined

It should say:

various

Notes:

The "Error! Bookmark not defined" string appears 5 times near the end of section 4.4.7. It appears in place of actual data in the examples.

http://www.ietf.org/rfc/rfc2446.txt

RFC 2453, "RIP Version 2", November 1998

Note: This RFC has been updated by RFC 4822

Source of RFC: ripv2 (rtg)

Errata ID: 1054
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nataraja Kumar Kota
Date Reported: 2007-08-27
Held for Document Update by: Adrian Farrel
Date Held: 2010-08-21

Section 3.4.4 says:

RIP implementations must also limit the rate which
of triggered updates may be trandmitted.

It should say:

RIP implementations must also limit the rate at
which triggered updates may be transmitted.

Errata ID: 5197
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vitaly Sinilin
Date Reported: 2017-12-05
Held for Document Update by: Alvaro Retana
Date Held: 2017-12-08

Section 3.8 says:

Every 30 seconds, the RIP process is awakened to send an unsolicited
Response message containing the complete routing table (see section
3.9 on Split Horizon) to every neighboring router.

It should say:

Every 30 seconds, the RIP process is awakened to send an unsolicited
Response message containing the complete routing table (see section
3.4.3 on Split Horizon) to every neighboring router.

Notes:

There are a few more invalid references to section 3.9 instead of section 3.4.3 in the text.

RFC 2460, "Internet Protocol, Version 6 (IPv6) Specification", December 1998

Note: This RFC has been obsoleted by RFC 8200

Note: This RFC has been updated by RFC 5095, RFC 5722, RFC 5871, RFC 6437, RFC 6564, RFC 6935, RFC 6946, RFC 7045, RFC 7112

Source of RFC: ipngwg (int)

Errata ID: 2541
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Brian Carpenter
Date Reported: 2010-10-03
Held for Document Update by: Ralph Droms

Section 6 says:

(Nothing about this omission.)

It should say:

Compared to RFC 1883, this specification reduces the size of the 
flow label field to 20 bits. The references to a 24 bit flow label 
field on pages 87 and 88 of RFC 2205 are updated accordingly.

Notes:

RFC 2460 updates RFC 2205.

Errata ID: 4279
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2015-02-24
Held for Document Update by: Brian Haberman
Date Held: 2015-03-09

Section 3 says:

   Hop Limit            8-bit unsigned integer.  Decremented by 1 by
                        each node that forwards the packet. The packet
                        is discarded if Hop Limit is decremented to
                        zero.

It should say:

TBD

Notes:

The original text overlooks the case that a node receives a packet which already has a hop limit of zero (eg, coming from a misbehaving node, or malicious traffic). Following the instructions in that case would result in decrementing the hop limit from 0 to -1 (so, 255), then forwarding the packet.

The text also doesn't state what a non-forwarding node (ie, a host) should do upon reception of a packet which already has a hop limit of zero: should the packet be accepted or dropped?


* While the above issues are worth discussing, they are beyond the scope of an erratum. Discussion on updating the text to handle Hop Limits from malicious or misbehaving nodes should be taken up within the working group. *

Errata ID: 4657
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Fernando Gont
Date Reported: 2016-04-07
Held for Document Update by: Suresh Krishnan
Date Held: 2017-01-29

Section 4 says:

It should say:

   Extension headers must never be inserted by any node other than the
   source of the packet.  IP Encapsulation must be used to meet any
   requirement for inserting headers, for example, as defined in
   [RFC2473].

Notes:

This is being handled in the 2460bis work.

Errata ID: 4662
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Brian Carpenter
Date Reported: 2016-04-11
Held for Document Update by: Suresh Krishnan
Date Held: 2017-01-29

Section 4 says:

With one exception, extension headers are not examined or processed
by any node along a packet's delivery path, until the packet reaches
the node (or each of the set of nodes, in the case of multicast)
identified in the Destination Address field of the IPv6 header.

It should say:

With one exception, extension headers are not examined, processed,
modified, inserted or deleted
by any node along a packet's delivery path, until the packet reaches
the node (or each of the set of nodes, in the case of multicast)
identified in the Destination Address field of the IPv6 header.

Notes:

This is being handled in the 2460bis work.

RFC 2492, "IPv6 over ATM Networks", January 1999

Note: This RFC has been updated by RFC 8064

Source of RFC: ion (int)

Errata ID: 1327
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Fernando Gont
Date Reported: 2008-02-18
Held for Document Update by: Brian Haberman

Section 3 says:

   This use of PVC links does not mandate, nor does it prohibit the use
   of extensions to the Neighbor Discovery protocol which may be
   developed for either general use of for use in PVC connections (for
   example, Inverse Neighbor Discovery).

It should say:

   This use of PVC links does not mandate, nor does it prohibit the use
   of extensions to the Neighbor Discovery protocol which may be
   developed for either general use or for use in PVC connections (for
   example, Inverse Neighbor Discovery).

RFC 2516, "A Method for Transmitting PPP Over Ethernet (PPPoE)", February 1999

Source of RFC: Legacy
Area Assignment: int

Errata ID: 2546
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Igor Idziejczak
Date Reported: 2010-10-06
Held for Document Update by: Brian Haberman

Section 4 says:

The DESTINATION_ADDR field contains either a unicast 
Ethernet destination address, or the Ethernet broadcast address 
(0xffffffff).

It should say:

The DESTINATION_ADDR field contains either a unicast 
Ethernet destination address, or the Ethernet broadcast address 
(0xffffffffffff).

Notes:

the ethernet broadcast address is 48bit so in hex 0xffffffffffff

Errata ID: 5635
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Chris Fletcher
Date Reported: 2019-02-11
Held for Document Update by: Eric Vyncke
Date Held: 2021-01-28

Section Appendix A says:

If there is data, and the first octet of the data is nonzero, then
it MUST be a printable UTF-8 string which explains the nature of
the error.  This string MAY NOT be NULL terminated.

It should say:

If there is data, and the first octet of the data is nonzero, then
it MUST be a printable UTF-8 string which explains the nature of
the error.  This string MUST NOT be NULL terminated.

Notes:

Keyword "MAY NOT" should be "MUST NOT" to comply with RFC 2119.

-- Verifier note --
The use of "MAY NOT" is not covered by RFC 2219 but the text is nevertheless clear. See point 2 of https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/

Errata ID: 427
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Saravanan Kesavan
Date Reported: 2006-10-06
Held for Document Update by: Brian Haberman

Section 9 says:

Host MAC address using a key known only to the Access > Concentrator.

It should say:

Host MAC address using a key known only to the Access Concentrator.

Notes:

There is an unnecessary ">" symbol.

Errata ID: 789
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Saravanan Kesavan
Date Reported: 2006-10-06
Held for Document Update by: Brian Haberman

Section 9 says:

   While the AC-Cookie is useful against some DOS attacks, it can not
   protect against all DOS attacks and an Access Concentrator MAY employ
   other means to protect resources.

   While the AC-Cookie is useful against some DOS attacks, it can not
   protect against all DOS attacks and an Access Concentrator MAY employ
   other means to protect resources.

It should say:

   While the AC-Cookie is useful against some DOS attacks, it can not
   protect against all DOS attacks and an Access Concentrator MAY employ
   other means to protect resources.

Notes:

sentence is repeated.

Errata ID: 1333
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Praveen Bhamidipati
Date Reported: 2008-02-26
Held for Document Update by: Brian Haberman

Section 4 says:

The SOURCE_ADDR field MUST contains the Ethernet MAC address of the
source device.

It should say:

The SOURCE_ADDR field MUST contain the Ethernet MAC address of the 
source device.

Notes:

The word "contains" should be "contain"

RFC 2544, "Benchmarking Methodology for Network Interconnect Devices", March 1999

Note: This RFC has been updated by RFC 6201, RFC 6815, RFC 9004

Source of RFC: Legacy
Area Assignment: ops

Errata ID: 5203
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: James Bensley
Date Reported: 2017-12-13
Held for Document Update by: Warren Kumari (Ops AD)
Date Held: 2017-12-14

Section 26.3 says:

Note: See section 18 for the maximum frame rates that SHOULD be used.

It should say:

Note: See section 20 for the maximum frame rates that SHOULD be used.

Notes:

Section 18 is "Multiple frame sizes", section 20 is "Maximum frame rate".

Errata ID: 5207
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Benoît Monin
Date Reported: 2017-12-14
Held for Document Update by: Warren Kumari (Ops AD)
Date Held: 2017-12-31

Section 25 says:

The DUT SHOULD be able to respond to address resolution requests sent
by the DUT wherever the protocol requires such a process.

It should say:

The DUT and tester SHOULD both be able to respond to address
resolution requests wherever the protocol requires such a
process.

Notes:

DUT responding to its own address resolution requests does not make sense.

[Original corrected text was "The DUT SHOULD be able to respond to address resolution requests sent by the tester wherever the protocol requires such a process." - after discussions with the BMWG I edited the corrected text as above - the tester also needs to respond, as otherwise the DUT will age out its resolution -- WK ]

Errata ID: 1484
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2008-08-08
Held for Document Update by: ron bonica

Section C.2.4.1 Lear says:

   This request should be
   seen as coming from the immediate destination of the test frame
   stream. (i.e. the phantom router (Figure 2) or the end node if
   adjacent network routing is being used.) It is assumed that the
   router will cache the MAC address of the requesting device.  The ARP
   request should be sent 5 seconds before the test frame stream starts
   in each trial.  Trial lengths of longer than 50 seconds may require
   that the router be configured for an extended ARP timeout.
          +--------+            +------------+
          |        |            |  phantom   |------ P LAN A
IN A------|   DUT  |------------|            |------ P LAN B
          |        |   OUT A    |  router    |------ P LAN C
          +--------+            +------------+

                                 Figure 2

It should say:

   This request should be
   seen as coming from the immediate destination of the test frame
   stream. (i.e. the phantom router (Figure 4) or the end node if
   adjacent network routing is being used.) It is assumed that the
   router will cache the MAC address of the requesting device.  The ARP
   request should be sent 5 seconds before the test frame stream starts
   in each trial.  Trial lengths of longer than 50 seconds may require
   that the router be configured for an extended ARP timeout.
          +--------+            +------------+
          |        |            |  phantom   |------ P LAN A
IN A------|   DUT  |------------|            |------ P LAN B
          |        |   OUT A    |  router    |------ P LAN C
          +--------+            +------------+

                                 Figure 4

Errata ID: 1488
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2008-08-15
Held for Document Update by: ron bonica

Section 26.2 says:

The latency is timestamp B minus timestamp A as per the relevant definition frm RFC 1242, namely latency as defined for store and forward devices or latency as defined for bit forwarding devices.

It should say:

The latency is timestamp B minus timestamp A as per the relevant definition from RFC 1242, namely latency as defined for store and forward devices or latency as defined for bit forwarding devices.

Errata ID: 1490
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2008-08-19
Held for Document Update by: ron bonica

Section C.2.4.2 says:

   If the test does not involve adjacent net routing the tester must
   supply proper routing information using a routing update.  A single
   routing update is used before each trial on each "destination" port
   (see section C.24).

It should say:

   If the test does not involve adjacent net routing the tester must
   supply proper routing information using a routing update.  A single
   routing update is used before each trial on each "destination" port
   (see section C.2.6.2).

Errata ID: 2711
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Wang Haojian
Date Reported: 2011-02-11
Held for Document Update by: ron bonica

Section Appendix C says:

Notes:

Is there something wrong in the sub section title ?
C.2.5 is missing while the C.2.6.1 and C.2.6.2 exists ?

RFC 2548, "Microsoft Vendor-specific RADIUS Attributes", March 1999

Source of RFC: radius (ops)

Errata ID: 3918
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kazuhiko Mino
Date Reported: 2014-03-14
Held for Document Update by: Benoit Claise
Date Held: 2014-03-17

Section 2.4.2 says:

         Call the shared secret S, the pseudo-random 128-bit Request
         Authenticator (from the corresponding Access-Request packet) R,
         and the contents of the Salt field A.  Break P into 16 octet
         chunks p(1), p(2)...p(i), where i = len(P)/16.  Call the
         ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C.
         Intermediate values b(1), b(2)...c(i) are required.

It should say:

         Call the shared secret S, the pseudo-random 128-bit Request
         Authenticator (from the corresponding Access-Request packet) R,
         and the contents of the Salt field A.  Break P into 16 octet
         chunks p(1), p(2)...p(i), where i = len(P)/16.  Call the
         ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C.
         Intermediate values b(1), b(2)...b(i) are required.

Errata ID: 3919
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kazuhiko Mino
Date Reported: 2014-03-14
Held for Document Update by: Benoit Claise
Date Held: 2014-03-17

Section 2.4.3 says:

         Call the shared secret S, the pseudo-random 128-bit Request
         Authenticator (from the corresponding Access-Request packet) R,
         and the contents of the Salt field A.  Break P into 16 octet
         chunks p(1), p(2)...p(i), where i = len(P)/16.  Call the
         ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C.
         Intermediate values b(1), b(2)...c(i) are required.

It should say:

         Call the shared secret S, the pseudo-random 128-bit Request
         Authenticator (from the corresponding Access-Request packet) R,
         and the contents of the Salt field A.  Break P into 16 octet
         chunks p(1), p(2)...p(i), where i = len(P)/16.  Call the
         ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C.
         Intermediate values b(1), b(2)...b(i) are required.

RFC 2560, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", June 1999

Note: This RFC has been obsoleted by RFC 6960

Note: This RFC has been updated by RFC 6277

Source of RFC: pkix (sec)

Errata ID: 3251
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Daniel Barclay
Date Reported: 2012-06-11
Held for Document Update by: Sean Turner

Section 4.2.2.2 says:

...  They MUST reject the response if the certificate required to validate
the signature on the response fails to meet at least one of the following
criteria:

   1. ...
   2. ...
   3. ...

It should say:

...  They MUST reject the response if it is not the case that the
certificate required to validate the signature on the response meets at 
least one of the following criteria:

   1. ...
   2. ...
   3. ...

Notes:

The "fails to meet at least one ... " part of the original wording is ambiguous.

It can sound like the grouping is "(fails to meet) at least one ..." rather than the (apparently) intended "fails to (meet at least one)".

Note: The submitted corrected text needs further improvement. I think it eliminates the ambiguity, but it currently is harder to follow.

Errata ID: 3252
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Daniel Barclay
Date Reported: 2012-06-11
Held for Document Update by: Sean Turner
Date Held: 2012-06-28

Section 4.2.2.2.1 says:

... CAs issuing such a certificate should realized that a compromise of the
responder's key, is as serious as the compromise of a CA key used to sign 
CRLs, at least for the validity period of this certificate. ...

It should say:

... CAs issuing such a certificate should realized that a compromise of the
responder's key is as serious as the compromise of a CA key used to sign 
CRLs, at least for the validity period of this certificate. ...

Notes:

That first comma was extraneous.

SPT: I also swapped realized/realize.

Errata ID: 3253
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Daniel Barclay
Date Reported: 2012-06-11
Held for Document Update by: Sean Turner

Section 5 says:

For this service to be effective, certificate using systems must connect to
the certificate status service provider. 

It should say:

For this service to be effective, certificate-using systems must connect to
the certificate status service provider. 

Notes:

(Alternatively, that could be "..., systems using certificates must ..."

RFC 2595, "Using TLS with IMAP, POP3 and ACAP", June 1999

Note: This RFC has been updated by RFC 4616, RFC 7817, RFC 8314

Source of RFC: Legacy
Area Assignment: app

Errata ID: 1076
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Joseph Shraibman
Date Reported: 2007-11-14
Held for Document Update by: Alexey Melnikov
Date Held: 2010-09-03

Section 2.4 says:

- A "*" wildcard character MAY be used as the left-most name
     component in the certificate.  For example, *.example.com would
     match a.example.com, foo.example.com, etc. but would not match
     example.com.

It should say:

- A "*" wildcard character MAY be used for the left-most name
     components in the certificate.  For example, *.example.com would
     match a.example.com, foo.example.com, etc. but would not match
     example.com or foo.bar.example.com.  *.*.example.com would match 
     foo.bar.example.com but would not match foo.example.com.

Notes:

It seems the original wording unintentionally disallowed certificates with *.* wildcards.

Alexey: The submitted errata indicated that multiple wildcards were allowed (e.g., *.*.a.com matches foo.bar.a.com but not foo.com). This is too large of a change to make with an errata. The Security and Application ADs feel a consensus call would be required to make that change. Further, the current practice is to allow only one at the leftmost position. This is being documented in draft-saintandre-tls-server-id-check and its intended to be a BCP.

Errata ID: 3398
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: David Caley
Date Reported: 2012-11-02
Held for Document Update by: Barry Leiba

Section 2.2 says:

Implementations are encouraged to have flexability with respect to
the minimal encryption strength or cipher suites permitted.

It should say:

Implementations are encouraged to have flexibility with respect to
the minimal encryption strength or cipher suites permitted.

RFC 2597, "Assured Forwarding PHB Group", June 1999

Note: This RFC has been updated by RFC 3260

Source of RFC: diffserv (tsv)

Errata ID: 413
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bud
Date Reported: 2005-05-24
Held for Document Update by: Wes Eddy

Section 1 says:

For example, if traffic conditioning actions at the ingress of the
provider DS domain make sure that an AF class in the DS nodes is only
moderately loaded by packets with the lowest drop precedence value
and is not overloaded by packets with the two lowest drop precedence
values, then the AF class can offer a high level of forwarding
assurance for packets that are within the subscribed profile (i.e.,
marked with the lowest drop precedence value) and offer up to two
lower levels of forwarding assurance for the excess traffic.

It should say:

For example, if traffic conditioning actions at the ingress of the
provider DS domain make sure that an AF class in the DS nodes is only
moderately loaded by packets with the lowest drop precedence value
and is not overloaded by packets with the two higher drop precedence
values, then the AF class can offer a high level of forwarding
assurance for packets that are within the subscribed profile (i.e.,
marked with the lowest drop precedence value) and offer up to two
lower levels of forwarding assurance for the excess traffic.

RFC 2598, "An Expedited Forwarding PHB", June 1999

Note: This RFC has been obsoleted by RFC 3246

Source of RFC: diffserv (tsv)

Errata ID: 1708
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2009-03-06
Held for Document Update by: Wes Eddy
Date Held: 2011-08-17

Section A.3.1 says:

   We chose these two since they"re the best and worst cases,
   respectively, for jitter and we wanted to supply rough guidelines for
   EF implementers choosing to use WRR or similar mechanisms.

It should say:

   We chose these two since they're the worst and best cases,
   respectively, for jitter and we wanted to supply rough guidelines for
   EF implementers choosing to use WRR or similar mechanisms.

Notes:

Fix double-quotes to apostrophe and note order of "best" and "worst"

RFC 2606, "Reserved Top Level DNS Names", June 1999

Note: This RFC has been updated by RFC 6761

Source of RFC: dnsind (int)

Errata ID: 7741
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tromler
Date Reported: 2023-12-25
Held for Document Update by: Éric Vyncke
Date Held: 2024-01-12

Throughout the document, when it says:

Reserved Top Level DNS Names
invalid DNS names

It should say:

Reserved Top Level domain Names
invalid domain names

Notes:

There is no such concept as a DNS name, nor is it found in any RFC. The correct concept is a domain name.


--RFC Editor Note:--
The term “DNS name” does appear in a number of RFCs, including recent ones (e.g., RFCs 9498, 9476, and 9178). It also appears in 6761, which updates 2606.

-- Verifier note --

The shortcut "DNS name" is indeed not in RFC 8499 (DNS terminology) but is also often used as a short cut.

RFC 2616, "Hypertext Transfer Protocol -- HTTP/1.1", June 1999

Note: This RFC has been obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235

Note: This RFC has been updated by RFC 2817, RFC 5785, RFC 6266, RFC 6585

Source of RFC: http (app)

Errata ID: 3407
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Thomas Lane
Date Reported: 2012-11-14
Held for Document Update by: Barry Leiba
Date Held: 2012-11-27

Section 2.2 says:

   Comments can be included in some HTTP header fields by surrounding
   the comment text with parentheses. Comments are only allowed in
   fields containing "comment" as part of their field value definition.
   In all other fields, parentheses are considered part of the field
   value.

       comment        = "(" *( ctext | quoted-pair | comment ) ")"
       ctext          = <any TEXT excluding "(" and ")">

   A string of text is parsed as a single word if it is quoted using
   double-quote marks.

       quoted-string  = ( <"> *(qdtext | quoted-pair ) <"> )
       qdtext         = <any TEXT except <">>

   The backslash character ("\") MAY be used as a single-character
   quoting mechanism only within quoted-string and comment constructs.

       quoted-pair    = "\" CHAR

It should say:

   Comments can be included in some HTTP header fields by surrounding
   the comment text with parentheses. Comments are only allowed in
   fields containing "comment" as part of their field value definition.
   In all other fields, parentheses are considered part of the field
   value.

       comment        = "(" *( ctext | quoted-pair | comment ) ")"
       ctext          = <any TEXT excluding "\", "(" and ")">

   A string of text is parsed as a single word if it is quoted using
   double-quote marks.

       quoted-string  = ( <"> *(qdtext | quoted-pair ) <"> )
       qdtext         = <any TEXT excluding "\" and <">>

   The backslash character ("\") MAY be used as a single-character
   quoting mechanism only within quoted-string and comment constructs.

       quoted-pair    = "\" CHAR

Notes:

Allowing "\" in qdtext and ctext creates ambiguous semantics.

Consider:
" \" (\ was a qdtext, so string has terminated)
" \""(\ is part of the quoted pair \")
" \ " (Is this an escaped space or a bare backslash?)
" \\"" (first \ is qdtext and second \ is part of quoted-pair \")

Analogous examples would work for ctext and comment, as well.

It looks to me as though the intended meaning was for the implementer to consider "\" part of a quoted-pair whenever possible. It's always possible, so the obvious fix would be to exclude it from ctext and qdtext, and use \\ whenever the user desires a textual backslash.

--- VERIFIER NOTES ---
This issue is already being dealt with in the HTTP 1.1 work in the HTTPBIS working group. The 2616 updates, which will be published soon, will include fixes for this.

Errata ID: 892
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: WooJin Chung
Date Reported: 2006-10-31
Held for Document Update by: Peter Saint-Andre

Section 4.4 says:

4.  If the message uses the media type "multipart/byteranges", and the
     ransfer-length is not otherwise specified, then this self-
     elimiting media type defines the transfer-length.

It should say:

4.  If the message uses the media type "multipart/byteranges", and the
     transfer-length is not otherwise specified, then this self-
     elimiting media type defines the transfer-length.

Errata ID: 1483
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Martin Kong
Date Reported: 2008-08-06
Held for Document Update by: Peter Saint-Andre

Section 3.6 says:

   The Internet Assigned Numbers Authority (IANA) acts as a registry for
   transfer-coding value tokens. Initially, the registry contains the
   following tokens: "chunked" (section 3.6.1), "identity" (section
   3.6.2), "gzip" (section 3.5), "compress" (section 3.5), and "deflate"
   (section 3.5).

It should say:

   The Internet Assigned Numbers Authority (IANA) acts as a registry for
   transfer-coding value tokens. Initially, the registry contains the
   following tokens: "chunked" (section 3.6.1), "identity" (section
   3.5), "gzip" (section 3.5), "compress" (section 3.5), and "deflate"
   (section 3.5).

Notes:

The tokens for Content-Codings are defined in section 3.5. These include the identity token.

Errata ID: 1619
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Heming Hou
Date Reported: 2008-11-25
Held for Document Update by: Peter Saint-Andre

Section 4.4 says:

   4.If the message uses the media type "multipart/byteranges", and the
     ransfer-length is not otherwise specified, then this self-
     elimiting media type defines the transfer-length. This media type
     UST NOT be used unless the sender knows that the recipient can arse
     it; the presence in a request of a Range header with ultiple byte-
     range specifiers from a 1.1 client implies that the lient can parse
     multipart/byteranges responses.

It should say:

   4.If the message uses the media type "multipart/byteranges", and the
     transfer-length is not otherwise specified, then this self-
     delimiting media type defines the transfer-length. This media type
     MUST NOT be used unless the sender knows that the recipient can parse
     it; the presence in a request of a Range header with multiple byte-
     range specifiers from a 1.1 client implies that the client can parse
     multipart/byteranges responses.

Notes:

> "ransfer-length" should be "transfer-length"
> "self-elimiting" should be "self-delimiting";
> "UST"should be "MUST";
> "arse"should be "parse";
> "ultiple"should be "multiple";
> "lient"should be "client";

Errata ID: 3206
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: ValCot
Date Reported: 2012-04-27
Held for Document Update by: Barry Leiba

Section 1.3 says:

   variant
      A resource may have one, or more than one, representation(s)
      associated with it at any given instant. Each of these
      representations is termed a `varriant'.  Use of the term `variant'
      does not necessarily imply that the resource is subject to content
      negotiation.

It should say:

   variant
      A resource may have one, or more than one, representation(s)
      associated with it at any given instant. Each of these
      representations is termed a `variant'.  Use of the term `variant'
      does not necessarily imply that the resource is subject to content
      negotiation.

Notes:

"varriant" Is this misspelling?

RFC 2626, "The Internet and the Millennium Problem (Year 2000)", June 1999

Source of RFC: 2000 (ops)

Errata ID: 2754
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-03-25
Held for Document Update by: Ron Bonica

Section 2; 5.1; 6 says:

{1 - Section 2}

[...] It should also be noted that the research was performd on RFCs 1
   through 2128.  At that time the IESG was charted with not allowing [...]


{2 - Section 5.1}

5.1 Fixed Solution

   A number of organizations and groups have suggested a fixed solution
   to the problem of two digit years.  Given a two-digit year YY, if YY
   is greater than or equal to 50, the year shall be interpreted as
   19YY; and where YY is less than 50, the year shall be intrepreted as
   20YY.


{3 - Section 6}

6. Methodology

   The first task was dividing the types of RFC's into logical groups
   rather than the strict numeric publishing order.  Sixteen specific
   areas were identified.  They are: "Autoconfiguration" , "Directory
   Services", "Disk Sharing", "Games and Chat" ,"Information Services &
   File Transfer", "Network & Transport Layer", "Electronic Mail",
   "NTP", Name Serving", "Network Management", "News", "Real Time
   Services", "Routing", "Security", "Virtual Terminal", and "Other".
   In addition to these categories, many hundreds of RFC's were
   immediately eliminated based on content.  That is not to say that all
   Informational RFC's were not considered, many did contain some
   technical content or overview whichdemanded scrutiny.

It should say:

{1 - Section 2}

[...] It should also be noted that the research was performed on RFCs 1
   through 2128.  At that time the IESG was charted with not allowing [...]


{2 - Section 5.1}

5.1 Fixed Solution

   A number of organizations and groups have suggested a fixed solution
   to the problem of two digit years.  Given a two-digit year YY, if YY
   is greater than or equal to 50, the year shall be interpreted as
   19YY; and where YY is less than 50, the year shall be interpreted as
   20YY.


{3 - Section 6}

6. Methodology

   The first task was dividing the types of RFC's into logical groups
   rather than the strict numeric publishing order.  Sixteen specific
   areas were identified.  They are: "Autoconfiguration" , "Directory
   Services", "Disk Sharing", "Games and Chat" ,"Information Services &
   File Transfer", "Network & Transport Layer", "Electronic Mail",
   "NTP", Name Serving", "Network Management", "News", "Real Time
   Services", "Routing", "Security", "Virtual Terminal", and "Other".
   In addition to these categories, many hundreds of RFC's were
   immediately eliminated based on content.  That is not to say that all
   Informational RFC's were not considered, many did contain some
   technical content or overview which demanded scrutiny.

Notes:

{1} A typo in "performed".
{2} A typo in "interpreted".
{3} A typo in "which demanded".

Errata ID: 2755
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-03-25
Held for Document Update by: Ron Bonica

Section 12.1; 12.2 says:

{1 - Section 12.1}

12.1 Summary

   The RFC's which were categorized into this group were the Internet
   Protocol (IP) versions four and six, the Transmission Control
   Protocol (TCP), the User Datagram Protocol (UDP), the Point-to-Point
   Protocol (PPP) and its extensions, Internet Control Message Protocol
   (ICMP), the Address Resolution Protocol (ARP) and Remote Procedure
   Call (RPC) protocol.  A variety of less known protocols were also
   examined.

   After careful review of the nearly 400 RFC's in this catagory, no
   millennium or year 2000 problems were found.


{2 - Section 12.2}

   [...]

   RFC 2097 on the PPP NetBIOS Frame Control Protocol discuesses several
   timer and timeouts in Section 2.1, none of which suffers from a year
   2000 problem.

   [...]

   RFC 791 on the Internet Protocol defines a packet type 68 which is an
   Internet Timestamp, which defines a 32-bit field which contains the
   number of milliseconds since midnght UT.

It should say:

{1 - Section 12.1}

12.1 Summary

   The RFC's which were categorized into this group were the Internet
   Protocol (IP) versions four and six, the Transmission Control
   Protocol (TCP), the User Datagram Protocol (UDP), the Point-to-Point
   Protocol (PPP) and its extensions, Internet Control Message Protocol
   (ICMP), the Address Resolution Protocol (ARP) and Remote Procedure
   Call (RPC) protocol.  A variety of less known protocols were also
   examined.

   After careful review of the nearly 400 RFC's in this category, no
   millennium or year 2000 problems were found.


{2 - Section 12.2}

   [...]

   RFC 2097 on the PPP NetBIOS Frame Control Protocol discusses several
   timer and timeouts in Section 2.1, none of which suffers from a year
   2000 problem.

   [...]

   RFC 791 on the Internet Protocol defines a packet type 68 which is an
   Internet Timestamp, which defines a 32-bit field which contains the
   number of milliseconds since midnight UT.

Notes:

{1} A typo in "category".
{2} 1) A typo in "discusses";
2) A typo in "midnight".

RFC 2631, "Diffie-Hellman Key Agreement Method", June 1999

Source of RFC: smime (sec)

Errata ID: 5954
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Paul Janson
Date Reported: 2020-01-02
Held for Document Update by: Benjamin Kaduk
Date Held: 2020-01-13

Section 2.1.5. says:

     1. Verify that y lies within the interval [2,p-1]. If it does not,
        the key is invalid.
     2. Compute y^q mod p. If the result == 1, the key is valid.
        Otherwise the key is invalid.

It should say:

     1. Verify that y lies within the interval [2,p-1]. If it does not,
        the key is invalid.
     2. Compute y^q mod p. If the result == 1, the key is valid.
        Otherwise the key is invalid.
     3. Verify that y does not match g.

Notes:

Validating that (g == received y) needs to be an additional exclusion to the valid range [2,p-1]. If party 'a' accepts received public key 'yb' matching 'g', then ZZ matches public key 'ya'. i.e. if yb = 2, then xb = 1, therefore ZZ = ya^1 = ya

Errata ID: 1060
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Javier Ader
Date Reported: 2007-09-13
Held for Document Update by: Tim Polk

 

This reference is cited in Section 1, but does not appear in the
References section. It should be added:

[DH76]  W. Diffie and M. E. Hellman, "New Directions in Cryptography",
        IEEE Transactions on Information Theory, vol. IT-22, Nov. 1976, 
        pp: 644-654.

RFC 2637, "Point-to-Point Tunneling Protocol (PPTP)", July 1999

Source of RFC: pppext (int)

Errata ID: 6288
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Casper van Eersel
Date Reported: 2020-09-13
Held for Document Update by: Eric Vyncke
Date Held: 2023-08-03

Section 2.14 says:

Th Call ID assigned by the PNS to this call.

It should say:

The Call ID assigned by the PNS to this call.

Notes:

A missing ‘e’ in ‘Th’.

RFC 2640, "Internationalization of the File Transfer Protocol", July 1999

Source of RFC: ftpext (app)

Errata ID: 5444
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: David LAMBERT
Date Reported: 2018-07-28
Held for Document Update by: Barry Leiba
Date Held: 2019-04-30

Section 4.3.1 says:

        C> LANG fr
        S> 200 Le response sera changez au francais

        C> feat
        S> 211- <quelconque descriptif texte>
        S>  ...
        S>  LANG EN;FR*
        S>  ...
        S> 211 end

It should say:

        C> LANG fr
        S> 200 Les réponses seront en français

        C> feat
        S> 211- <texte descriptif quelconque>
        S>  ...
        S>  LANG EN;FR*
        S>  ...
        S> 211 end

Notes:

I'm natively speaking French, and the original text is not correct.
In particular, some words stayed in English, and word order is not the same in French.

The correction make the hypothesis that UTF-8 is allowed in reply messages, which is not specified in the RFC (see other errata).

RFC 2661, "Layer Two Tunneling Protocol "L2TP"", August 1999

Source of RFC: pppext (int)

Errata ID: 2049
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Wang Haojian
Date Reported: 2010-02-22
Held for Document Update by: Brian Haberman

Section 1.2 says:

DSLAM

Digital Subscriber Line (DSL) Access Module

It should say:

DSLAM

Digital Subscriber Line (DSL) Access Multiplexer

Notes:

I think 'Multiplexer' is more appropriate

RFC 2663, "IP Network Address Translator (NAT) Terminology and Considerations", August 1999

Source of RFC: nat (tsv)

Errata ID: 1432
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Harald Hubich
Date Reported: 2008-05-29
Held for Document Update by: Wesley Eddy

Section 4.3. says:

b) After twice-NAT translation, in private network

          SA: 200.200.200.1     DA: 172.16.1.100

It should say:

b) After twice-NAT translation, in private network

          DA: 200.200.200.1     SA: 172.16.1.100

Notes:

tricky :)

RFC 2675, "IPv6 Jumbograms", August 1999

Source of RFC: ipngwg (int)

Errata ID: 2175
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeierc
Date Reported: 2010-04-28
Held for Document Update by: Brian Haberman

Section 4. says:

receiver derive the actual UDP packet length from the IPv6 payload
length.  (Note that, prior to this modification, zero was not a legal

It should say:

receiver derive the actual UDP packet length from the Jumbo Payload
Length.  (Note that, prior to this modification, zero was not a legal

Notes:

The IPv6 payload length is 0.

RFC 2679, "A One-way Delay Metric for IPPM", September 1999

Note: This RFC has been obsoleted by RFC 7679

Source of RFC: ippm (ops)

Errata ID: 398
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Andrew Main
Date Reported: 2002-11-18
Held for Document Update by: Lars Eggert
Date Held: 2009-04-07

Section 5.1 says:

   Then the 50th percentile would be 110 msec, since 90 msec and 100
   msec are smaller and 110 msec and 'undefined' are larger.

It should say:

   Then the 50th percentile would be 110 msec, since 90 msec and 100
   msec are smaller and 500 msec and 'undefined' are larger.  See
   Section 11.3 of [1] for computing percentiles.

Notes:

See the list of samples immediately preceding that paragraph.

RFC 2680, "A One-way Packet Loss Metric for IPPM", September 1999

Note: This RFC has been obsoleted by RFC 7680

Source of RFC: ippm (ops)

Errata ID: 3186
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Benoit Claise
Date Reported: 2012-04-11
Held for Document Update by: Wes Eddy

Section 1 says:

The structure of the memo is as follows:

   +  A 'singleton' analytic metric, called Type-P-One-way-Loss, is
      introduced to measure a single observation of packet transmission
      or loss.

It should say:

The structure of the memo is as follows:

   +  A 'singleton' analytic metric, called Type-P-One-way-Packet-Loss, is
      introduced to measure a single observation of packet transmission
      or loss.

RFC 2681, "A Round-trip Delay Metric for IPPM", September 1999

Source of RFC: ippm (ops)

Errata ID: 397
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Andrew Main
Date Reported: 2002-11-18
Held for Document Update by: Lars Eggert
Date Held: 2009-05-14

Section 4.1 says:

Then the 50th percentile would be 110 msec, since 90 msec and 100
msec are smaller and 110 msec and 'undefined' are larger.

It should say:

Then the 50th percentile would be 110 msec, since 90 msec and 100 msec
are smaller and 500 msec and 'undefined' are larger.  See Section 11.3
of [1] for computing percentiles.

Notes:

Corrected text suggested by Matt Zekauskas (matt@internet2.edu).

RFC 2683, "IMAP4 Implementation Recommendations", September 1999

Note: This RFC has been updated by RFC 7162

Source of RFC: Legacy

Errata ID: 3165
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christian Ketterer
Date Reported: 2012-03-23
Held for Document Update by: Barry Leiba

Section 3.4.12 says:

If the client chooses to try to take
advantage of this possibility it must be prepared to use the other
method in the even that the more convenient one fails.

It should say:

If the client chooses to try to take
advantage of this possibility it must be prepared to use the other
method in the event that the more convenient one fails.

Notes:

"t" missing from "event"

RFC 2700, "Internet Official Protocol Standards", August 2000

Note: This RFC has been obsoleted by RFC 2800

Source of RFC: Legacy

Errata ID: 2781
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-04-17
Held for Document Update by: ron bonica

Section TOC says:

2.  Contacts . . . . . . . . . . . . . . . . . . . . . . . . .   2

It should say:

2.  Resources  . . . . . . . . . . . . . . . . . . . . . . . .   2

RFC 2702, "Requirements for Traffic Engineering Over MPLS", September 1999

Source of RFC: mpls (rtg)

Errata ID: 3172
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2012-04-02
Held for Document Update by: Adrian Farrel
Date Held: 2012-04-03

Section 3.1 says:

   An induced MPLS graph consists of a set of LSRs which comprise the
   nodes of the graph and a set of LSPs which provide logical point to
   point connectivity between the LSRs, and hence serve as the links of
   the induced graph. it may be possible to construct hierarchical
   induced MPLS graphs based on the concept of label stacks (see [1]).

It should say:

   An induced MPLS graph consists of a set of LSRs which comprise the
   nodes of the graph and a set of LSPs which provide logical point to
   point connectivity between the LSRs, and hence serve as the links of
   the induced graph. It may be possible to construct hierarchical
   induced MPLS graphs based on the concept of label stacks (see [1]).

Notes:

Typo. Capitalisation at start of sentence.

RFC 2712, "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)", October 1999

Source of RFC: tls (sec)

Errata ID: 5432
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Eugene Adell
Date Reported: 2018-07-20
Held for Document Update by: Paul Wouters
Date Held: 2024-01-12

Section Appendix says:

It should say:

Appendix

   RFC 2712 introduces new cipher suites values, starting with the
   cipher value { 0x00, 0x1E }.
   This cipher value was earlier known as a Fortezza cipher suite,
   and this could lead to a conflict.

Notes:

Errata 5409 was rejected and I was suggested to post another one at this place.

RFC 2712 (Addition of Kerberos Cipher Suites to Transport Layer Security) in its Draft 01 version introduces new cipher suites values, among them three are colliding with the Fortezza cipher suites. The Draft 02 version partially corrects that, by shifting all of the Kerberos cipher suites values by two.
This omission of the third Fortezza cipher suite has never been corrected, and this remains in the same state in the final RFC 2712. As a result, the cipher suite value { 0x00, 0x1E } is now officially known as a Kerberos one.

Although not documented themselves by any RFC, the two non conflicting Fortezza cipher suites are mentioned in the same note in the TLS protocol RFC (2246, 4346, 5246). This gives an explanation on how the Kerberos cipher suite values were chosen.

RFC 2740, "OSPF for IPv6", December 1999

Note: This RFC has been obsoleted by RFC 5340

Source of RFC: ospf (rtg)

Errata ID: 393
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Acee Lindem
Date Reported: 2003-02-22
Held for Document Update by: Stewart Bryant

Section 2.5 says:

   Link-local unicast addresses are assigned from the IPv6 address
   range FF80/10.

It should say:

   Link-local unicast addresses are assigned from the IPv6 address
   range FE80::/10.

Notes:

The IPv6 link-local address range is incorrect.

RFC 2743, "Generic Security Service Application Program Interface Version 2, Update 1", January 2000

Note: This RFC has been updated by RFC 5554, RFC 5896

Source of RFC: cat (sec)

Errata ID: 2758
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Martin Rex
Date Reported: 2011-03-29
Held for Document Update by: Stephen Farrell

Section 2.1.4 says:

   o  actual_mechs SET OF OBJECT IDENTIFIER, -- if returned, caller must
   -- release with GSS_Release_oid_set()

   o  initiator_time_rec INTEGER -- in seconds, or reserved value for
   -- INDEFINITE

   o  acceptor_time_rec INTEGER -- in seconds, or reserved value for
   -- INDEFINITE

   o  cred_usage INTEGER, -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
   -- 2=ACCEPT-ONLY

   o  mech_set SET OF OBJECT IDENTIFIER -- full set of mechanisms
   -- supported by resulting credential.

   Return major_status codes:

It should say:

   o  actual_mechs SET OF OBJECT IDENTIFIER, -- full set of mechanisms
   -- supported by resulting credential.  If returned, caller must
   -- release with GSS_Release_oid_set()

   o  initiator_time_rec INTEGER -- in seconds, or reserved value for
   -- INDEFINITE

   o  acceptor_time_rec INTEGER -- in seconds, or reserved value for
   -- INDEFINITE

   Return major_status codes:

Notes:

There appears to be accidentally duplicated text trailing the list of output parameters in section 2.1.4: GSS_Add_cred call (top of page 38).

The parameter "cred_usage" is an input-only parameter and also listed under input parameters, and the parameter "mech_set" is a duplicate of the actual_mechs output parameter. Compare GSS-API C-Bindings document rfc2744, section 5.3. gss_add_cred

-Martin

Errata ID: 3797
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Benjamin Kaduk
Date Reported: 2013-11-12
Held for Document Update by: Stephen Farrell
Date Held: 2014-05-08

Section 2.4.5 says:

   Outputs:

   o  major_status INTEGER,

   o  minor_status INTEGER,

   o  output_name INTERNAL NAME  -- caller must release with
   -- GSS_Release_name()

   Return major_status codes:

   o  GSS_S_COMPLETE indicates that a valid name representation is
   output in output_name and described by the type value in
   output_name_type.

It should say:

   Outputs:

   o  major_status INTEGER,

   o  minor_status INTEGER,

   o  output_name INTERNAL NAME  -- caller must release with
   -- GSS_Release_name()

   Return major_status codes:

   o  GSS_S_COMPLETE indicates that a valid name representation is
   output in output_name.

Notes:

The description of the GSS_S_COMPLETE return value from GSS_Import_name() indicates that the contents of the output_name field are "described by the type value in output_name_type". There is no such output_name_type parameter.

RFC 2744, "Generic Security Service API Version 2 : C-bindings", January 2000

Note: This RFC has been updated by RFC 5896

Source of RFC: cat (sec)

Errata ID: 1620
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Harris
Date Reported: 2008-11-25
Held for Document Update by: Sean Turner

Section 5.15 says:

   Since some application-level protocols may wish to use tokens emitted
   by gss_wrap() to provide "secure framing", implementations must
   support derivation of MICs from zero-length messages.

It should say:

   Since some application-level protocols may wish to use tokens emitted
   by gss_get_mic() to provide "secure framing", implementations must
   support derivation of MICs from zero-length messages.

RFC 2802, "Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP)", April 2000

Source of RFC: trade (app)

Errata ID: 3210
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2012-05-03
Held for Document Update by: Barry Leiba

Section 5.2.2 et al. says:

urn:ietf-org:hmac

It should say:

urn:ietf:params:hmac 

Notes:

The URN used in 2 instances in Section 5.2.2 has never been
registered -- not even the URN Namespace 'ietf-org' !

The Corrected Text is based on RFC 2648 and RFC 3553,
but by barely suggesting this potentially correct URN
(in the spirit of these RFCs), it is still not yet
registered with IANA!

So this correction should be Held for Update, and any successor
of the RFC should provide the necessary registration of this URN
with IANA.

Similarly, the other URNs used in the RFC,
urn:ibm-com:dom-hash
urn:nist-gov:sha1
urn:fips:sha1
urn:rsasdi-com:rsa-encryption
urn:X500:X509v3
urn:nist-gov:dsa
urn:ansi-org:ecdsa
all are entirely hypothetical; all the URN Namespaces used
there have never been registered so far -- even 12 years after
the publication of RFC 2802.

RFC 2804, "IETF Policy on Wiretapping", May 2000

Source of RFC: IAB

Errata ID: 1874
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Matthias Bärwolff
Date Reported: 2009-09-10
Held for Document Update by: Danny McPherson

Section 4 says:

centered around

It should say:

revolved around

Notes:

I don't mean to split hairs here, but, really, something cannot center around something, only revolve. Feel free to reject this report, however.

RFC 2812, "Internet Relay Chat: Client Protocol", April 2000

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 991
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Stefan Hoffmeister
Date Reported: 2007-06-10
Held for Document Update by: Peter Saint-Andre
Date Held: 2010-06-24

Section 2.3.1 says:

shortname  =  ( letter / digit ) *( letter / digit / "-" )
              *( letter / digit )
              ; as specified in RFC 1123 [HNAME]

It should say:

shortname  =  ( letter / digit ) [ *( letter / digit / "-" ) ( letter / digit ) ]

Notes:

>From RFC 1123:

2.1 Host Names and Numbers

The syntax of a legal Internet host name was specified in RFC-952
[DNS:4]. One aspect of host name syntax is hereby changed: the
restriction on the first character is relaxed to allow either a
letter or a digit. Host software MUST support this more liberal
syntax.


In RFC 952 the definition of a shortname looks like this

<name> ::=3D <let>[*[<let-or-digit-or-hyphen>]<let-or-digit>]

from pending

Errata ID: 2306
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Timo Buhrmester
Date Reported: 2010-06-18
Held for Document Update by: Peter Saint-Andre

Section 1.3 says:

   Space is used as parameter separator and command is used as a list item
   separator by the protocol). 

It should say:

   Space is used as parameter separator and comma is used as a list item
   separator by the protocol). 

Errata ID: 3246
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jakob Kramer
Date Reported: 2012-06-06
Held for Document Update by: Barry Leiba

Section 3.1.8 says:

   :Trillian SQUIT cm22.eng.umd.edu :Server out of control ; Command
                                   from Trillian from to disconnect
                                   "cm22.eng.umd.edu" from the net with
                                   comment "Server out of control".

It should say:

   :Trillian SQUIT cm22.eng.umd.edu :Server out of control
                                     ; Command from Trillian to disconnect
                                     "cm22.eng.umd.edu" from the net with
                                     comment "Server out of control".

Notes:

A "from" too much. (I also inserted a new line break to make it look nicer and lined the comments up.)

Errata ID: 3786
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Diman Todorov
Date Reported: 2013-11-05
Held for Document Update by: Barry Leiba
Date Held: 2013-11-05

Section 3. says:

If multiple parameters is presented, then each MUST be checked for
validity and appropriate responses MUST be sent back to the client.

It should say:

If multiple parameters are present, then each MUST be checked for
validity and appropriate responses MUST be sent back to the client.

Notes:

We don't use errata for minor, obvious typos.

RFC 2817, "Upgrading to TLS Within HTTP/1.1", May 2000

Note: This RFC has been updated by RFC 7230, RFC 7231

Source of RFC: tls (sec)

Errata ID: 4187
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Roy T. Fielding
Date Reported: 2014-11-20
Held for Document Update by: Stephen Farrell
Date Held: 2015-03-24

Section 7.2 says:

   The Draft Standard for HTTP/1.1 [1] specifies that these tokens obey
   the production for 'product':

      product         = token ["/" product-version]
      product-version = token

[...]

   This specification defines the protocol token "TLS/1.0" as the
   identifier for the protocol specified by The TLS Protocol [6].

It should say:

   The Draft Standard for HTTP/1.1 [1] specifies that these tokens obey
   the production for 'product':

      product         = token ["/" product-version]
      product-version = token

[...]

   This specification defines the product token "TLS" as the
   identifier for the protocol specified by The TLS Protocol [6].
   When a specific version of TLS is desired, it is indicated by
   appending a slash ("/") and the TLS version number as the
   product-version (e.g., "TLS/1.0").

Notes:

This erratum clarifies that "TLS" is the product token and any TLS version number (currently DIGIT "." DIGIT) is the product-version token. This has already been corrected in the Upgrade Token Registry.

RFC 2818, "HTTP Over TLS", May 2000

Note: This RFC has been obsoleted by RFC 9110

Note: This RFC has been updated by RFC 5785, RFC 7230

Source of RFC: tls (sec)

Errata ID: 1077
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Joseph Shraibman
Date Reported: 2007-11-14
Held for Document Update by: Sean Turner
Date Held: 2010-08-10

Section 3.1 says:

    Matching is performed using the matching rules specified by
   [RFC2459].  If more than one identity of a given type is present in
   the certificate (e.g., more than one dNSName name, a match in any one
   of the set is considered acceptable.) Names may contain the wildcard
   character * which is considered to match any single domain name
   component or component fragment. E.g., *.a.com matches foo.a.com but
   not bar.foo.a.com. f*.com matches foo.com but not bar.com.

It should say:

   Matching is performed using the matching rules specified by
   [RFC2459].  If more than one identity of a given type is present in
   the certificate (e.g., more than one dNSName name), a match in any one
   of the set is considered acceptable.  Names may contain the wildcard
   character * which is considered to match any single domain name
   component or component fragment. E.g., *.a.com matches foo.a.com but
   not bar.foo.a.com and f*.com matches foo.com but not bar.com.

Notes:

The submitted errata indicated that multiple wildcards were allowed (e.g., *.*.a.com matches foo.bar.a.com but not foo.com). This is too large of a change to make with an errata. The Security and Application ADs feel a consensus call would be required to make that change. Further, the current practice is to allow only one at the leftmost position. This is being documented in draft-saintandre-tls-server-id-check-09 and its intended to be a BCP.

The errata does however correct a misplaced parentheses, and uses semi-colons to separate examples.

RFC 2820, "Access Control Requirements for LDAP", May 2000

Source of RFC: ldapext (app)

Errata ID: 382
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hallvard B Furuseth
Date Reported: 2005-01-06
Held for Document Update by: Peter Saint-Andre

The abstract says:

   This document describes the fundamental requirements of an access
   control list (ACL) model for the Lightweight Directory Application
   Protocol (LDAP) directory service.  

It should say:

   This document describes the fundamental requirements of an access
   control list (ACL) model for the Lightweight Directory Access
   Protocol (LDAP) directory service.  

Notes:

RFC 2821, "Simple Mail Transfer Protocol", April 2001

Note: This RFC has been obsoleted by RFC 5321

Note: This RFC has been updated by RFC 5336

Source of RFC: drums (app)

Errata ID: 760
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Wayne Schlitt
Date Reported: 2005-05-12
Held for Document Update by: Alexey Melnikov

Section 2.4.1 says:

In several places, RFC2821 refers to "section 2.4.1.".
Unfortunately there *is* no section 2.4.1.  To be quite honest, I'm
really not sure what the intended section number is.  It doesn't
appear obvious to me.

It should say:

[not submitted]

Notes:

from pending

RFC 2825, "A Tangled Web: Issues of I18N, Domain Names, and the Other Internet protocols", May 2000

Source of RFC: IAB

Errata ID: 3124
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Gabriel Montenegro
Date Reported: 2012-02-16
Held for Document Update by: IAB-Chair

Section 3.3 says:

   Also, the Simple Network Management Protocol (SNMP) uses the textual
   representation defined in [RFC2579].  While that specification does
   allow for UTF-8-based domain names, an informal survey of deployed
   implementations of software libraries being used to build SNMP-
   compliant software uncovered the fact that few (if any) implement it.

It should say:

   Also, the Simple Network Management Protocol (SNMP) uses the textual
   representation defined in [RFC2579].  That specification does not
   allow for UTF-8-based domain names, and an informal survey of deployed
   implementations of software libraries being used to build SNMP-
   compliant software confirmed the fact that few (if any) implement 
   it.

Notes:

RFC2579 is pretty clear about ASCII-only here. Whereas using SnmpAdminString in RFC2571 could allow for UTF-8 in the interest of i18n, that is not what is being discussed here.

RFC 2827, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", May 2000

Note: This RFC has been updated by RFC 3704

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 2244
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Justin Pryzby
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner

Section 1 says:

By mentioning the method, he was concerned about encouraging it's use.

It should say:

By mentioning the method, he was concerned about encouraging its use.

Notes:

/it's/ s/'//

RFC 2849, "The LDAP Data Interchange Format (LDIF) - Technical Specification", June 2000

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 2258
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Flavio Poletti
Date Reported: 2010-05-13
Held for Document Update by: Peter Saint-Andre

Throughout the document, when it says:

Example 3: A file containing a base-64-encoded value

version: 1
dn: cn=Gern Jensen, ou=Product Testing, dc=airius, dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Gern Jensen
cn: Gern O Jensen
sn: Jensen
uid: gernj
telephonenumber: +1 408 555 1212
description:: V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVl
IGlzIGJhc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdG
VyIGluIGl0IChhIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQg
b3V0IG1vcmUu

It should say:

Example 3: A file containing a base-64-encoded value

version: 1
dn: cn=Gern Jensen, ou=Product Testing, dc=airius, dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Gern Jensen
cn: Gern O Jensen
sn: Jensen
uid: gernj
telephonenumber: +1 408 555 1212
description:: V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVl
 IGlzIGJhc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdG
 VyIGluIGl0IChhIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQg
 b3V0IG1vcmUu

Notes:

There is no section numbering in this RFC, hence the "GLOBAL".

Note 10 in "Notes on LDIF Syntax" says that base64-encoded values are subject to the same folding rules explained in Note 2. Note 2 requires folded lines to begin with a space character.

This modification was introduced passing from draft-good-ldap-ldif to RFC 2849.

Errata ID: 3646
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Boris Kleint
Date Reported: 2013-06-11
Held for Document Update by: Barry Leiba
Date Held: 2013-08-21

Section Note 4 says:

Any dn or rdn that contains characters other than those
defined as "SAFE-UTF8-CHAR", or begins with a character other
than those defined as "SAFE-INIT-UTF8-CHAR",

It should say:

Any dn or rdn that contains characters other than those
defined as "SAFE-CHAR", or begins with a character other
than those defined as "SAFE-INIT-CHAR",

Notes:

This appears in note 4 of "Notes on LDIF Syntax".

---- Verifier notes ----
Note 4 has double text, one of which allows more than the other. But the ABNF
doesn't have that ambiguity. This is really something that can only be fixed by
revising the spec. It's simply not clear what the intent was.

RFC 2852, "Deliver By SMTP Service Extension", June 2000

Source of RFC: Legacy
Area Assignment: app

Errata ID: 2300
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alexey Melnikov
Date Reported: 2010-06-04
Held for Document Update by: Peter Saint-Andre

Section 4 says:

   by-parameter = "BY="by-value
   by-value     = by-time";"by-mode[by-trace]

It should say:

   by-parameter = "BY=" by-value
                       ^
   by-value     = by-time ";" by-mode [by-trace]
                         ^   ^       ^

Notes:

This is not a valid ABNF. BAP (ABNF parser) complains:

error: Concatenation of adjacent elements is not allowed (missing whitespace?)

So extra spaces need to be inserted.

RFC 2858, "Multiprotocol Extensions for BGP-4", June 2000

Note: This RFC has been obsoleted by RFC 4760

Source of RFC: idr (rtg)

Errata ID: 369
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2006-01-19
Held for Document Update by: Stewart Bryant

Section 8 says:

    As specified in this document, the MPL_REACH_NLRI and MP_UNREACH_NLRI
    attributes contain the Subsequence Address Family Identifier (SAFI)
    field. The SAFI name space is defined in Section 9. ...

Notes:

There isn't SAFI name space definition in RFC 2858. This name name space
definition presents in obsoleted RFC 2283 but completely removed from
RFC 2858.

Errata ID: 370
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tom Petch
Date Reported: 2005-02-04
Held for Document Update by: Stewart Bryant

IANA Considerations say:

"...  The SAFI name space is defined in Section 9...."

It should say:

"...  The SAFI name space is defined in Section 5...."

RFC 2865, "Remote Authentication Dial In User Service (RADIUS)", June 2000

Note: This RFC has been updated by RFC 2868, RFC 3575, RFC 5080, RFC 6929, RFC 8044

Source of RFC: radius (ops)

Errata ID: 6915
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Oleg Pekar
Date Reported: 2022-04-02
Held for Document Update by: Rob Wilton
Date Held: 2024-02-09

Section 5 says:

      The Value field is zero or more octets and contains information
      specific to the Attribute.

It should say:

      The Value field is one or more octets and contains information
      specific to the Attribute.

Notes:

Section "5. Attributes" is ambiguous when it talks about the attribute value size:

First it says: "The Value field is zero or more octets", then it provides 5 possible value data types none of which allows a zero length value. For 'text' type it says: "Text of length zero (0) MUST NOT be sent; omit the entire attribute instead" and the same for 'string' type.

Section "5.26. Vendor-Specific" also says about the value of a vendor-specific attribute "The String field is one or more octets".

Thus the RFC allows empty values for attributes in general but prohibits for any declared types of the attributes.

RFC 2866, "RADIUS Accounting", June 2000

Note: This RFC has been updated by RFC 2867, RFC 5080, RFC 5997

Source of RFC: radius (ops)

Errata ID: 5417
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Nick Lowe
Date Reported: 2018-07-06
Held for Document Update by: Ignas Bagdonas
Date Held: 2019-10-28

Section 5.11 says:

      This attribute is a unique Accounting ID to make it easy to link
      together multiple related sessions in a log file.  Each session
      linked together would have a unique Acct-Session-Id but the same
      Acct-Multi-Session-Id.  It is strongly recommended that the Acct-
      Multi-Session-Id contain UTF-8 encoded 10646 [7] characters.

It should say:

      This attribute is a unique Accounting ID to make it easy to link
      together multiple related sessions in a log file.  Each session
      linked together would have a unique Acct-Session-Id but the same
      Acct-Multi-Session-Id.  The start and stop records for a given
      session MUST have the same Acct-Multi-Session-Id.  An
      Access-Request packet MAY contain Acct-Multi-Session-Id; if it
      does, then the NAS MUST use the same Acct-Multi-Session-Id in
      the Accounting-Request packets for that session.  It is strongly
      recommended that the Acct-Multi-Session-Id contain UTF-8 encoded
      10646 [7] characters.

Notes:

RFC2866 does not make clear that an Access-Request packet MAY contain Acct-Multi-Session-Id in section 5.11 as it does for the Acct-Session-Id in section 5.5 or that consistency is expected between the start and stop records.

RFC 2883, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", July 2000

Source of RFC: tsvwg (wit)

Errata ID: 6355
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eugene Adell
Date Reported: 2020-12-14
Held for Document Update by: Martin Duke
Date Held: 2020-12-22

Section 5.2 says:

   The use of D-SACK allows the sender to detect some cases (e.g., when
   no ACK packets have been lost) when a a Fast Retransmit was due to
   packet reordering instead of packet loss.  This allows the TCP sender

It should say:

   The use of D-SACK allows the sender to detect some cases (e.g., when
   no ACK packets have been lost) when a Fast Retransmit was due to
   packet reordering instead of packet loss.  This allows the TCP sender

Notes:

redundant word

RFC 2898, "PKCS #5: Password-Based Cryptography Specification Version 2.0", September 2000

Note: This RFC has been obsoleted by RFC 8018

Source of RFC: Legacy

Errata ID: 3170
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: nobody@example.invalid
Date Reported: 2012-03-29
Held for Document Update by: Stephen Farrell

Section Abstract says:

   Other cryptographic techniques based on passwords, such as password-
   based key entity authentication and key establishment protocols

It should say:

   Other cryptographic techniques based on passwords, such as password-
   based entity authentication and key establishment protocols

Notes:

"key entity authentication" appears to be a typo. Or, at least, missing a hyphen.

Errata ID: 3324
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Simon Josefsson
Date Reported: 2012-08-16
Held for Document Update by: Sean Turner

Section A.2 says:

   The fields of type PKDF2-params have the following meanings:

It should say:

   The fields of type PBKDF2-params have the following meanings:

RFC 2910, "Internet Printing Protocol/1.1: Encoding and Transport", September 2000

Note: This RFC has been obsoleted by RFC 8010

Note: This RFC has been updated by RFC 3380, RFC 3381, RFC 3382, RFC 3510, RFC 3995, RFC 7472

Source of RFC: ipp (app)

Errata ID: 4100
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Sweet
Date Reported: 2014-09-05
Held for Document Update by: Barry Leiba
Date Held: 2014-09-17

Section 8.1.2 says:

   IPP Printers SHOULD support Transport Layer Security (TLS) [RFC2246]
   for Server Authentication and Operation Privacy. IPP Printers MAY
   also support TLS for Client Authentication.  If an IPP Printer
   supports TLS, it MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
   cipher suite as mandated by RFC 2246 [RFC2246].  All other cipher
   suites are OPTIONAL.  An IPP Printer MAY support Basic Authentication
   (described in HTTP/1.1 [RFC2617])  for Client Authentication if the
   channel is secure. TLS with the above mandated cipher suite can
   provide such a secure channel.

   If a IPP client supports TLS, it MUST support the
   TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as mandated by RFC
   2246 [RFC2246].  All other cipher suites are OPTIONAL.

It should say:

   IPP Printers SHOULD support Transport Layer Security (TLS) [RFC2246]
   for Server Authentication and Operation Privacy. IPP Printers MAY
   also support TLS for Client Authentication.  An IPP Printer MAY
   support Basic Authentication (described in HTTP/1.1 [RFC2617]) for
   Client Authentication if the channel is secure.

Notes:

Per the PWG IPP WG discussions at the August 2014 F2F, any mention of cipher suites in RFC 2910 is inappropriate. In particular, the cipher suite mentioned is no longer mandatory in TLS/1.2.

----- Verifier notes -----
While the cipher suites listed were correct when RFC 2910 was written, the list of required/recommended cipher suites has changed since then, to the point that some what were required at the time are specifically *not* recommended now. For that reason, RFC 2910 is in need of an update. This errata report will serve to note that, until such time as the update is done and a new RFC is published.

RFC 2911, "Internet Printing Protocol/1.1: Model and Semantics", September 2000

Note: This RFC has been obsoleted by RFC 8011

Note: This RFC has been updated by RFC 3380, RFC 3382, RFC 3996, RFC 3995, RFC 7472

Source of RFC: ipp (app)

Errata ID: 3072
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Sweet
Date Reported: 2012-01-04
Held for Document Update by: Barry Leiba

Section 4.2.4 says:

This attribute is relevant only if a job consists of two or more
documents. This attribute MUST be supported with at least one value

It should say:

This attribute is relevant to jobs consisting of one or more
documents. This attribute MUST be supported with at least one value

Notes:

Per consensus of the IPP working group in the Printer Working Group, the "multiple-document-handling" attribute *is* applicable to single-document jobs since it is the only common attribute that can be used to request copy collation.

The other collation attribute ("sheet-collate" from RFC3381])interacts with "multiple-document-handling" in some non-obvious ways and requires clients and printers to support two different attributes for simple collation. The "sheet-collate" attribute also does not address how finishing options are applied to copies while "multiple-document-handling" does.

RFC 2919, "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists", March 2001

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 2499
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tony Hansen
Date Reported: 2010-08-23
Held for Document Update by: Peter Saint-Andre

Section 2 and 3 says:

[DRUMS]

It should say:

[RFC2822]

Notes:

When going from draft-chandhok-listid-04.txt to the RFC, various references were updated. The [DRUMS] reference to 2822 was updated to [RFC2822] within the References section, but was not changed within the text.

RFC 2962, "An SNMP Application Level Gateway for Payload Address Translation", October 2000

Source of RFC: nat (tsv)

Errata ID: 4981
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Taehee Yoo
Date Reported: 2017-03-25
Held for Document Update by: Magnus Westerlund
Date Held: 2019-03-26

Section 6 says:

very week

It should say:

very weak

RFC 2978, "IANA Charset Registration Procedures", October 2000

Source of RFC: Legacy

Errata ID: 6265
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: John Klensin
Date Reported: 2020-08-25
Held for Document Update by: Barry Leiba
Date Held: 2020-08-25

Section 3.1 says:

Proposed charsets are not formally registered and must not be used; the "x-" prefix specified in RFC 2045 can be used until registration is complete.

It should say:

Proposed charsets are not formally registered and must not be used.

Notes:

This section contains a recommendation for temporary use of charset names with an "X-" prefix. Given the problems those have caused and the general prohibition in RFC 6648, probably that provision should be considered updated and removed by 6648. Given that the review period is only two weeks, it would seem that there is little reason for for having proposed charsets floating around anyway.

Comment: Despite Alexey's 2018 comment on erratum 5433, perhaps it is time to create a revised document, not only to incorporate the syntax corrections of prior errata and to get rid of the "X-" advice, but to put in some text that actively discourages new registrations and uses of charsets that are not based on Unicode.

===== Verifier notes =====
This was not incorrect when the RFC was published, so it doesn't fit into "errata". That said, John is correct that (1) we should consider that BCP 178 has changed this as noted, and (2) we probably should do a document update. I am, therefore, marking this as "held for document update".

RFC 2985, "PKCS #9: Selected Object Classes and Attribute Types Version 2.0", November 2000

Source of RFC: Legacy
Area Assignment: sec

Errata ID: 3769
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sean Leonard
Date Reported: 2013-10-27
Held for Document Update by: Sean Turner
Date Held: 2014-01-14

Section 5.2.1 says:

   emailAddress ATTRIBUTE ::= {
           WITH SYNTAX IA5String (SIZE(1..pkcs-9-ub-emailAddress))
           EQUALITY MATCHING RULE pkcs9CaseIgnoreMatch
           ID pkcs-9-at-emailAdress
   }

It should say:

   emailAddress ATTRIBUTE ::= {
           WITH SYNTAX IA5String (SIZE(1..pkcs-9-ub-emailAddress))
           EQUALITY MATCHING RULE pkcs9CaseIgnoreMatch
           ID pkcs-9-at-emailAddress
   }

Notes:

The ASN.1 is correct in Appendix A: ASN.1 Module.

spt: For those who missed it there is a "d" missing from the pkcs-9-at-emailAddress in the original text. As it's in the text and not the module, I'll mark this as hold for document as well as reclassifying it as editorial.

RFC 3022, "Traditional IP Network Address Translator (Traditional NAT)", January 2001

Source of RFC: nat (tsv)

Errata ID: 2047
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: cloengard
Date Reported: 2010-02-21
Held for Document Update by: Wes Eddy

Section 2.2 says:

... sends the packet to it's primary router. ...
=========================>                      

It should say:

... sends the packet to its primary router. ...

Notes:

it's => its: use possessive form, not contraction

RFC 3029, "Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols", February 2001

Source of RFC: pkix (sec)

Errata ID: 6445
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2021-02-26
Held for Document Update by: Paul Wouters
Date Held: 2024-01-12

Section Appendix E says:

Version ::= Integer

It should say:

Version ::= INTEGER

Notes:

INTEGER must be in all capital letters for the ASN.1 Module to compile.

Paul Wouters (AD): However "Version" does not appear to be reference elsewhere in the module. The "version" fields use an explicit "INTEGER"

RFC 3031, "Multiprotocol Label Switching Architecture", January 2001

Note: This RFC has been updated by RFC 6178, RFC 6790

Source of RFC: mpls (rtg)

Errata ID: 6240
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Jitendra Kumar Sharma
Date Reported: 2020-07-27
Held for Document Update by: Deborah Brungard
Date Held: 2021-02-26

Section 3.10 says:

3.10. The Next Hop Label Forwarding Entry (NHLFE)

   The "Next Hop Label Forwarding Entry" (NHLFE) is used when forwarding
   a labeled packet.  It contains the following information:

   1. the packet's next hop

   2. the operation to perform on the packet's label stack; this is one
      of the following operations:

      a) replace the label at the top of the label stack with a
         specified new label

      b) pop the label stack

      c) replace the label at the top of the label stack with a
         specified new label, and then push one or more specified new
         labels onto the label stack.

   It may also contain:

      d) the data link encapsulation to use when transmitting the packet

      e) the way to encode the label stack when transmitting the packet

      f) any other information needed in order to properly dispose of
         the packet.

   Note that at a given LSR, the packet's "next hop" might be that LSR
   itself.  In this case, the LSR would need to pop the top level label,
   and then "forward" the resulting packet to itself.  It would then
   make another forwarding decision, based on what remains after the
   label stacked is popped.  This may still be a labeled packet, or it
   may be the native IP packet.

   This implies that in some cases the LSR may need to operate on the IP
   header in order to forward the packet.

   If the packet's "next hop" is the current LSR, then the label stack
   operation MUST be to "pop the stack".

It should say:

3.10. The Next Hop Label Forwarding Entry (NHLFE)

   The "Next Hop Label Forwarding Entry" (NHLFE) is used when forwarding
   a labeled packet on an LSR or an unlabeled packet on an Ingress MPLS router. It 
   contains the following information:

   1. the packet's next hop

   2. the operation to perform on the packet's label stack; this is one
      of the following operations:

      a) replace the label at the top of the label stack with a
         specified new label

      b) pop the label stack

      c) replace the label at the top of the label stack with a
         specified new label, and then push one or more specified new
         labels onto the label stack.

      d) push a new label on an unlabeled packet


   It may also contain:

      e) the data link encapsulation to use when transmitting the packet

      f) the way to encode the label stack when transmitting the packet

      g) any other information needed in order to properly dispose of
         the packet.

   Note that at a given LSR, the packet's "next hop" might be that LSR
   itself.  In this case, the LSR would need to pop the top level label,
   and then "forward" the resulting packet to itself.  It would then
   make another forwarding decision, based on what remains after the
   label stacked is popped.  This may still be a labeled packet, or it
   may be the native IP packet.

   This implies that in some cases the LSR may need to operate on the IP
   header in order to forward the packet.

   If the packet's "next hop" is the current LSR, then the label stack
   operation MUST be to "pop the stack".

Notes:

Section 3.10 defines NHLFE, and it sounds from the definition that this piece of information is used by an MPLS router only when packet is already labeled. Now, when section 3.12 (FTN) defines the relationship between FEC and NHLFE, the definition of NHLFE in section 3.10 does not align with FTN definition.

Errata ID: 6450
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Duane L. Anderson
Date Reported: 2021-03-00
Held for Document Update by: Andrew Alston
Date Held: 2022-05-26

Throughout the document, when it says:

2.2. Terminology defines the terms

        Layer 2         layer 2 the protocol layer under layer 3 
                        (which therefore offers the services used by layer 3)
        Layer 3         the protocol layer at which IP and its associated 
                        routing protocols operate

2.3. Acronyms and Abbreviations defines 

        L2              Layer 2
        L3              Layer 3

However, in 3.14. Scope and Uniqueness of Labels, 4.3. Label Stacks and Implicit Peering, 4.5. LSP Trees as Multipoint-to-Point Entities, and 4.6. LSP Tunneling between BGP Border Routers, L1, L2 and L3 are used as differentiating names for certain labels attached to packets. 

Of course, in 3.23. Time-to-Live (TTL), L2 is used to refer to layer 2 frame header and to a layer 2 switch, which is correct. 

However, in 4.3. Label Stacks and Implicit Peering, the term level 1 is used to refer to the LIFO (stack) ordinal number of a label then named L1 and given a protocol layer 2 protocol of layer 2 (L2). Furthermore, labels named L2 and then L1 are pushed onto the stack of labels prefixed to the packet. To top it all off the packet's stack attribute as protocol level 2 (L2). 

Of course, in 3.17. LSP Next Hop, 4.1.5. The Implicit NULL Label, 5.1.1.2. PushConditional, 5.1.1.4. PulledConditional, 5.1.2.2. RequestWhenNeeded, 5.1.3. Upstream LSR: NotAvailable Procedure, 5.1.4. Upstream LSR: Release Procedure, 5.1.4.2. NoReleaseOnChange, 5.1.5. Upstream LSR: labelUse Procedure, 5.2.2. Schemes for LSRs that do not Support Label Merging, refer to L3 meaning level 3, which is correct. 

Furthermore, in 3.1. Labels, 3.2. Upstream and Downstream LSRs, 3.4. Label Assignment and Distribution, 3.5. Attributes of a Label Binding, 3.14. Scope and Uniqueness of Labels, 4.1.2.2. Distributing Labels, 5.1.5. Upstream LSR: labelUse Procedure, 5.1.5.2. UseIfLoopNotDetected, 5.1.6. Downstream LSR: Withdraw Procedure

 * L is used as a name for a certain label attached to packet, and 

 * L is used as a arbitrary value assigned to a label attached to a packet

It should say:

I have not provided any corrected text as I've literally "highlighted" 44 places in a pdf format file of RFC 3031 that are ambiguous. 

As there is no facility to attach a file to this Report Errata for RFC3031 form, i will send the file commented pdf file upon request. 

Notes:

My rational for highlighting (no pun intended) these problems is that the overloading of the L2, L3 abbreviations layer 2 and layer 3, with the names L1, L2, L3 and L for labels, plus the use of L1 and L2 as indexed names for the ordinal position of a label prefixed to a payload, then to use L2 and L3 as to actually mean layer 2 and layer is uh ... sloppy.


Honestly, I can't understand how RFC 3031 has been posted for twenty years and that it is on the Standards Track and no one has found these problems.

Its similar to when someone publishes a mathematical treatise and use the same set of variable names {x, y, z, t} over and over again in different contexts spread throughout the paper. Its intractable and practically gibberish.

I apologize if my criticism is harsh regarding this problem but I spent a considerable amount of my time reading this document trying to make sense of it before I realized that the fault is not mine but it is of the document.

[Andrew] This seems to wide and generalized to be a simple errata, as such I am marking this as held for document update.

Errata ID: 2803
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: maligree
Date Reported: 2011-05-08
Held for Document Update by: Adrian Farrel

Section 3.1 says:

Ru will label with packet with label value L

It should say:

Ru will label the packet with label value L

Errata ID: 2967
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: fl
Date Reported: 2011-09-11
Held for Document Update by: Adrian Farrel

Section 3.20 says:

When order control is used, each LSR should adopt, for a given set of
FECs, the granularity used by its next hop for those FECs.

It should say:

When ordered control is used, each LSR should adopt, for a given set of
FECs, the granularity used by its next hop for those FECs.

Errata ID: 2992
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bala Venkata
Date Reported: 2011-10-12
Held for Document Update by: Adrian Farrel

Section 3.12 says:

If the FTN maps a particular label to a set of NHLFEs that contains
more than one element, exactly one element of the set must be chosen
before the packet is forwarded. The procedures for choosing an
element from the set are beyond the scope of this document. Having
the FTN map a label to a set containing more than one NHLFE may be
useful if, e.g., it is desired to do load balancing over multiple
equal-cost paths.

It should say:

If the FTN maps a particular FEC to a set of NHLFEs that contains
more than one element, exactly one element of the set must be chosen
before the packet is forwarded. The procedures for choosing an
element from the set are beyond the scope of this document. Having
the FTN map a FEC to a set containing more than one NHLFE may be
useful if, e.g., it is desired to do load balancing over multiple
equal-cost paths.

Notes:

Since FTN is used for packets that arrive unlabeled (as ILM is used for label-NHLFEs), this section should be corrected. It says that "FTN maps a particular label to a set of NHLFEs"

RFC 3032, "MPLS Label Stack Encoding", January 2001

Note: This RFC has been updated by RFC 3443, RFC 4182, RFC 5332, RFC 3270, RFC 5129, RFC 5462, RFC 5586, RFC 7274, RFC 9017

Source of RFC: mpls (rtg)

Errata ID: 2162
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2010-04-15
Held for Document Update by: Adrian Farrel

Section 3.1 says:

         Suppose that an unlabeled IP datagram is received at a
         particular LSR, and that the the LSR pushes on a label before
         forwarding the datagram.  Such a datagram will be called an
         Initially Labeled IP Datagram at that LSR.

It should say:

         Suppose that an unlabeled IP datagram is received at a
         particular LSR, and that the LSR pushes on a label before
         forwarding the datagram.  Such a datagram will be called an
         Initially Labeled IP Datagram at that LSR.

Notes:

Doubled "the"

RFC 3056, "Connection of IPv6 Domains via IPv4 Clouds", February 2001

Source of RFC: ngtrans (ops)

Errata ID: 2070
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vishwas Manral
Date Reported: 2010-03-09
Held for Document Update by: Dan Romascanu

Section Abstract says:

   The motivation for this method is to allow isolated IPv6 domains or
   hosts, attached to an IPv4 network which has no native IPv6 support,
   to communicate with other such IPv6 domains or hosts with minimal
   manual configuration, before they can obtain natuve IPv6
   connectivity. 

It should say:

   The motivation for this method is to allow isolated IPv6 domains or
   hosts, attached to an IPv4 network which has no native IPv6 support,
   to communicate with other such IPv6 domains or hosts with minimal
   manual configuration, before they can obtain native IPv6
   connectivity. 

Notes:

s/natuve/native/

RFC 3058, "Use of the IDEA Encryption Algorithm in CMS", February 2001

Source of RFC: smime (sec)

Errata ID: 5913
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2019-11-19
Held for Document Update by: Benjamin Kaduk
Date Held: 2019-11-23

Section 2 says:

     IDEA-CBC OBJECT IDENTIFIER
       ::= { iso(1) identified-organization(3)
           usdod(6) oid(1) private(4) enterprises(1)
           ascom(188) systec(7) security(1) algorithms(1) 2 }

It should say:

     id-IDEA-CBC OBJECT IDENTIFIER
       ::= { iso(1) identified-organization(3)
           usdod(6) oid(1) private(4) enterprises(1)
           ascom(188) systec(7) security(1) algorithms(1) 2 }

Notes:

ASN.1 requires that such an identifier begin with a lower case letter. The prefix of "id-" is a common approach to meeting this requirement for an OBJECT IDENTIFIER.

RFC 3065, "Autonomous System Confederations for BGP", February 2001

Note: This RFC has been obsoleted by RFC 5065

Source of RFC: idr (rtg)

Errata ID: 339
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2006-01-25
Held for Document Update by: Stewart Bryant

Appendix A says:

    The most notable change from [1] is that of reversing the values
    AS_CONFED_SEQUENCE(4) and AS_CONFED_SET(3) to those defined in
    section "AS_CONFED Segment Type Extension".  The reasoning for this
    is that in the initial implementation, which was already widely
    deployed, they were implemented backwards from [4], and as such,
    subsequent implementations implemented them backwards as well.  In
    order to foster interoperability and compliance with deployed
    implementations, they've therefore been changed here as well. 

It should say:

    The most notable change from [4] is that of reversing the values
    AS_CONFED_SEQUENCE(4) and AS_CONFED_SET(3) to those defined in
    section "AS_CONFED Segment Type Extension".  The reasoning foridely
    deployed, they were implemented backwards from [4], and as such,
    subsequent implementations implemented them backwards as well.  In
    order to foster interoperability and compliance with deployed
    implementations, they've therefore been changed here as well.

Notes:

Sorry for mistype error in my previous message.
There is a mistype error in line 1 of Appendix A (RFC 3065). reference
to document [1] is wrong and must be changed to [4].

RFC 3107, "Carrying Label Information in BGP-4", May 2001

Note: This RFC has been obsoleted by RFC 8277

Note: This RFC has been updated by RFC 6790

Source of RFC: mpls (rtg)

Errata ID: 4582
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: David Lamparter
Date Reported: 2016-01-06
Held for Document Update by: Deborah Brungard
Date Held: 2016-02-11

Throughout the document, when it says:

[... section 3: ...]
   A BGP speaker can withdraw a previously advertised route (as well as
   the binding between this route and a label) by either (a) advertising
   a new route (and a label) with the same NLRI as the previously
   advertised route, or (b) listing the NLRI of the previously
   advertised route in the Withdrawn Routes field of an Update message.
   The label information carried (as part of NLRI) in the Withdrawn
   Routes field should be set to 0x800000.  (Of course, terminating the
   BGP session also withdraws all the previously advertised routes.)

4. Advertising Multiple Routes to a Destination

   A BGP speaker may maintain (and advertise to its peers) more than one
   route to a given destination, as long as each such route has its own
   label(s).

   The encoding described above allows a single BGP Update message to
   carry multiple routes, each with its own label(s).

   In the case where a BGP speaker advertises multiple routes to a
   destination, if a route is withdrawn, and a label(s) is specified at
   the time of withdrawal, only the corresponding route with the
   corresponding label is withdrawn.  If a route is withdrawn, and no
   label is specified at the time of withdrawal, then only the
   corresponding unlabeled route is withdrawn; the labeled routes are
   left in place.
[...]

It should say:

-- ALTERNATE 1: require label value --

   A BGP speaker can withdraw a previously advertised route by either
   (a) advertising a new route with the same NLRI (including label) as
   the previously advertised route, or (b) listing the NLRI of the
   previously advertised route in the Withdrawn Routes field of an
   Update message.  The label information carried (as part of NLRI) in
   the Withdrawn Routes field MUST be set to the value previously
   announced.  (Of course, terminating the BGP session also withdraws
   all the previously advertised routes.)

   The binding between route and label cannot be updated to change the
   label without withdrawing the old label and sending an update with
   the new label.

[keep section 4 unchanged]

-- ALTERNATE 2: drop multiple label support --

   A BGP speaker can withdraw a previously advertised route (as well as
   the binding between this route and a label) by either (a) advertising
   a new route (and a label) with the same prefix as the previously
   advertised route, or (b) listing the NLRI of the previously
   advertised route in the Withdrawn Routes field of an Update message.
   The label information carried (as part of NLRI) in the Withdrawn
   Routes field should be set to 0x800000.  (Of course, terminating the
   BGP session also withdraws all the previously advertised routes.)

[remove section 4, remove capability "4" in section 5]

-- ALTERNATE 3: clarify implications of capability "4" --

[optionally, change section 3:]
   The label information carried (as part of NLRI) in the Withdrawn
   Routes field SHOULD be set to the value previously announced.

[insert section 5.1:]
5.1. Implications of Multiple Routes Capability

   Implementing the "multiple routes" capability introduced above
   slightly changes the processing of update and withdraw messages to
   requiring an exact match on the label, i.e. including it in NLRI
   comparisons.

   To ensure interoperability, an implementation that has this
   capability SHOULD NOT send updates with different label values on a
   session whose peer does not advertise the capability.  The peer would
   in this case only hold the latest update, possibly introducing label
   oscillations.  Further, the implementation MUST process incoming
   updates and withdraws on such sessions as if their labels were
   wildcards, removing any previous routes with the same prefix.  It
   MUST NOT hold the same prefix with any but the last seen label value
   on these sessions.

Notes:

This issue was previously discussed in
https://osdir.com/ml/ietf.idr/2004-06/msg00010.html
https://osdir.com/ml/ietf.idr/2004-06/msg00018.html

Sections 3 and 4 are inherently conflicting. The conflict is:

Section 3 states a withdraw "should" be sent with a null label/BoS=1. This means it's not possible to withdraw a specific labeled route, instead all routes with the given prefix would need to be withdrawn. However, section 4 specifies exact-match behavior for processing updates and withdraws.

Also, the Section 3 text is semantically/editorially wrong in itself, saying (shortened) "withdraw [...] binding [... by] new route (and a label) with the same NLRI". However, the label is part of the NLRI; an update with the same NLRI could thus not withdraw the binding, only possibly cause it to not be selected as best path anymore by updating attributes.

I have not checked what other implementations do; Quagga (which only implements this as route reflector):
- does not implement SAFI 4, but applies the behavior on SAFI 128 (VPN)
- does not advertise capability 4
- excludes the label value from all comparisons
- will only keep the last label value received
- will set the label on withdraws to all zeroes (ignoring the recommended value)

Note that, as with Quagga, this also affects BGP-VPN implementations since these essentially inherit the behavior. Also note that the "Multiple Routes Capability" is global over all AFI/SAFI pairs.


P.S.: Out of curiosity / for IDR mailing list: for anyone implementing 3107 or 4364: does your implementation include/advertise the "multiple routes" capability?

RFC 3122, "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification", June 2001

Source of RFC: ipngwg (int)

Errata ID: 2819
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Luis MG
Date Reported: 2011-06-02
Held for Document Update by: Brian Haberman

Section 3.1 says:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length   |                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+        -       -       -        +
   |                          Reserved                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Length    |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       -       -       -       +
   |                          Reserved                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

The length field is 8 bits long, not 7. The diagram is wrong as the field should end in the 16th bit of the word.

Errata ID: 3695
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Arnold Plankl
Date Reported: 2013-08-14
Held for Document Update by: Ted Lemon

Section 2.2 says:

   The sender node MUST send the following options in the Advertisement
   message:

   Source Link-Layer Address The link-layer address of the sender.

It should say:

   The sender node MUST send the following options in the Advertisement
   message:

        Source Link-Layer Address 
           The link-layer address of the sender.

Notes:

The same format for the source link-layer address option as for the target link-layer address option (insert tab).

RFC 3143, "Known HTTP Proxy/Caching Problems", June 2001

Source of RFC: Legacy
Area Assignment: app

Errata ID: 1634
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2008-12-13
Held for Document Update by: Alexey Melnikov
Date Held: 2010-11-06

Section 2.2.2 says:

2.2.2 Interception proxies prevent introduction of new HTTP methods

   Name
      Interception proxies prevent introduction of new HTTP methods

   Classification
      Architecture

   Description
      A proxy that receives a request with a method unknown to it is
      required to generate an HTTP 501 Error as a response.  HTTP
      methods are designed to be extensible so there may be applications
      deployed with initial support just for the user agent and origin
      server.  An interception proxy that hijacks requests which include
      new methods destined for servers that have implemented those
      methods creates a de-facto firewall where none may be intended.

   Significance
      Medium within interception proxy environments.

   Implications
      Renders new compliant applications useless unless modifications
      are made to proxy software.  Because new methods are not required
      to be globally standardized it is impossible to keep up to date in
      the general case.

   Solution(s)
      Eliminate the need for interception proxies.  A client receiving a
      501 in a traditional HTTP environment may either choose to repeat
      the request to the origin server directly, or perhaps be
      configured to use a different proxy.

   Workaround
      Level 5 switches (sometimes called Level 7 or application layer
      switches) can be used to keep HTTP traffic with unknown methods
      out of the proxy.  However, these devices have heavy buffering
      responsibilities, still require TCP sequence number spoofing, and
      do not interact well with persistent connections.

      The HTTP/1.1 specification allows a proxy to switch over to tunnel
      mode when it receives a request with a method or HTTP version it
      does not understand how to handle.

   Contact
      Patrick McManus <mcmanus@AppliedTheory.com>
      Henrik Nordstrom <hno@hem.passagen.se> (HTTP/1.1 clarification)

It should say:

- none -

Notes:

The whole subsection needs to be removed. There is no requirement in RFC2616 for proxies to generate a 501 status for unknown methods.

Mark Nottingham wrote: I don't think that deleting this section is the right answer; some interception proxies *do* prevent the introduction of new methods; it's just the text about 501 that's wrong.

RFC 3161, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", August 2001

Note: This RFC has been updated by RFC 5816

Source of RFC: pkix (sec)

Errata ID: 844
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stefan Doerpinghaus
Date Reported: 2007-01-31
Held for Document Update by: Tim Polk

Section 2.4.2 says:

   unacceptedExtension (16),
     -- the requested extension is not supported by the TSA
    addInfoNotAvailable (17)
      -- the additional information requested could not be understood
      -- or is not available
    systemFailure       (25)
      -- the request cannot be handled due to system failure  }

It should say:

   unacceptedExtension (16),
     -- the requested extension is not supported by the TSA
    addInfoNotAvailable (17),
      -- the additional information requested could not be understood
      -- or is not available
    systemFailure       (25)
      -- the request cannot be handled due to system failure  }

Notes:

Missing comma after the descriptor of the OID of PKIFailureInfo,
at the end of line "addInfoNotAvailable (17).

from pending

RFC 3162, "RADIUS and IPv6", August 2001

Note: This RFC has been updated by RFC 8044

Source of RFC: Legacy
Area Assignment: ops

Errata ID: 3217
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Leaf Yeh
Date Reported: 2012-05-08
Held for Document Update by: RonBonica

Section 2 says:

3.2 Framed-Interface-Id

It should say:

2.2 Framed-Interface-Id

Notes:

Typo in the numbering of this section.

RFC 3168, "The Addition of Explicit Congestion Notification (ECN) to IP", September 2001

Note: This RFC has been updated by RFC 4301, RFC 6040, RFC 8311

Source of RFC: tsvwg (wit)

Errata ID: 2316
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2010-06-29
Held for Document Update by: Lars Eggert

Section 15 says:

   [RFC2408]    Maughan, D., Schertler, M., Schneider, M. and J. Turner,
                "Internet Security Association and Key Management
                Protocol (ISAKMP)", RFC 2409, November 1998.

It should say:

   [RFC2408]    Maughan, D., Schertler, M., Schneider, M. and J. Turner,
                "Internet Security Association and Key Management
                Protocol (ISAKMP)", RFC 2408, November 1998.

Notes:

Incorrect reference to RFC 2409

Errata ID: 4754
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bob Briscoe
Date Reported: 2016-07-31
Held for Document Update by: Mirja Kühlewind
Date Held: 2020-03-04

Section Header block says:

Updates: 2474, 2401, 2003, 793

It should say:

Updates: 2474, 2401, 2003, 2473, 793

Notes:

RFC 3168 updates RFC 2473 but does not indicate this in its header block.

Specifically, Section 9 of RFC 3168 defined processing of the ECN field for Encapsulated Packets, which updated section 6.4 of RFC 2473, where the creation of the "IPv6 Tunnel Packet Traffic Class" was specified. RFC3168 also updated the decapsulation behaviour of the ECN field in an IPv6 tunnel header, which had not been specified in RFC2473.

Note 1: As well as tagging RFC3168 with this erratum, RFC2473 needs to be tagged (in the RFC index and associated tools outputs) to indicate that it is updated by RFC3168.

Note 2: Originally, the "Updates:" header of RFC3168 did not contain "2003", which was added as a result of Errata ID 2660.

Note 3: The first sentence of section 9.1 in RFC3168 should also be modified as follows:
Original text:
The encapsulation of IP packet headers in tunnels is used in many
places, including IPsec and IP in IP [RFC2003].
Corrected text:
The encapsulation of IP packet headers in tunnels is used in many
places, including IPsec and IP in IP [RFC2003, 2473].
Comment:
Nowadays RFC2473 would be a normative reference, but RFC3168 pre-dated the categorisation of references into normative and informative.

Note 4: Section 9 of RFC3168 has since been updated by RFC6040. Nonetheless, that is already correctly identified in RFC6040.

This reported errata has be moved to "Held for Document Update". While the reported problem is correct and needs to be addressed, it is not just an errata but a larger oversight at publication time.

RFC 3196, "Internet Printing Protocol/1.1: Implementor's Guide", November 2001

Source of RFC: ipp (app)

Errata ID: 6538
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Juli Mallett
Date Reported: 2021-04-13
Held for Document Update by: RFC Editor
Date Held: 2024-02-16

The Table of Contents says:

   3.1.2.3.12  What charset to return when an unsupported charset is
               requested (Issue 1.19)?....... ....................... 52

It should say:

   3.1.2.3.12  What charset to return when an unsupported charset is
               requested (Issue 1.19)?............................... 52

Notes:

Spaces to full stops.

RFC 3208, "PGM Reliable Transport Protocol Specification", December 2001

Source of RFC: Legacy
Area Assignment: tsv

Errata ID: 1945
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alessandro Spinella
Date Reported: 2009-11-23
Held for Document Update by: Wes Eddy
Date Held: 2011-08-17

Section 1.2.5. says:

If receivers are several hops
   removed from the first PGM network element, the efficacy of NAK
   suppression may degrade.

It should say:

If receivers are several hops
   away from the first PGM network element, the efficacy of NAK
   suppression may degrade.

Notes:

This is simply a stylistic suggestion in the wording choice.

RFC 3209, "RSVP-TE: Extensions to RSVP for LSP Tunnels", December 2001

Note: This RFC has been updated by RFC 3936, RFC 4420, RFC 4874, RFC 5151, RFC 5420, RFC 5711, RFC 6780, RFC 6790, RFC 7274

Source of RFC: mpls (rtg)

Errata ID: 4733
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramakrishna DTV
Date Reported: 2016-07-06
Held for Document Update by: Deborah Brungard
Date Held: 2016-07-12

Section 4.3.2 says:

   To formalize the discussion, we call each group of nodes an abstract
   node.  Thus, we say that an explicit route is a specification of a
   set of abstract nodes to be traversed.  If an abstract node consists
   of only one node, we refer to it as a simple abstract node.

It should say:

   To formalize the discussion, we call each group of nodes an abstract
   node.  Thus, we say that an explicit route is a specification of a
   sequence of abstract nodes to be traversed.  If an abstract node 
   consists of only one node, we refer to it as a simple abstract node.

Notes:

s/set/sequence

A set implies ordering of abstract nodes is NOT important.
A sequence implies ordering of abstract nodes IS important.

In the rest of RFC 3209, this distinction is maintained, but not
in this paragraph.

RFC 3219, "Telephony Routing over IP (TRIP)", January 2002

Note: This RFC has been updated by RFC 8602

Source of RFC: iptel (rai)

Errata ID: 2634
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dale R. Worley
Date Reported: 2010-11-16
Held for Document Update by: Robert Sparks

Section 5.1.1.3 says:

      PentaDecimal-routing-number   = *pentadecimal-digit
-     pentadecimal-routing-digit    = PENTADECIMAL-DIGIT

It should say:

      PentaDecimal-routing-number   = *pentadecimal-digit
-     pentadecimal-digit            = PENTADECIMAL-DIGIT

Notes:

BNF variable "pentadecimal-routing-digit" should be "pentadecimal-digit", by analogy with section 5.1.1.2.

RFC 3224, "Vendor Extensions for Service Location Protocol, Version 2", January 2002

Source of RFC: Legacy

Errata ID: 3148
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Matthew Millar
Date Reported: 2012-03-06
Held for Document Update by: Pete Resnick

Section Abstract says:

This document udpates RFC 2608, "The Service
   Location Protocol."

It should say:

This document updates RFC 2608, "The Service
   Location Protocol."

RFC 3240, "Digital Imaging and Communications in Medicine (DICOM) - Application/dicom MIME Sub-type Registration", February 2002

Source of RFC: Legacy

Errata ID: 6023
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Luu Vinh Phuc
Date Reported: 2020-03-17
Held for Document Update by: Barry Leiba
Date Held: 2020-03-17

Section 1. DICOM Def says:

   Individual DICOM objects (such as images) may be encapulsated in
   files and exchanged by e-mail using the Media Type defined herein.
   In addition, a set of DICOM files may be described by an index file,
   DICOMDIR, which may accompany the files that it references.

It should say:

   Individual DICOM objects (such as images) may be encapsulated in
   files and exchanged by e-mail using the Media Type defined herein.
   In addition, a set of DICOM files may be described by an index file,
   DICOMDIR, which may accompany the files that it references.

Notes:

encapulsated => encapsulated

RFC 3260, "New Terminology and Clarifications for Diffserv", April 2002

Source of RFC: diffserv (tsv)

Errata ID: 3193
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sergey Antipov
Date Reported: 2012-04-16
Held for Document Update by: Wesley Eddy

Section 9 says:

      RFC 2497: revise to reflect understanding that, AF classes are
      instances of the AF PHB group, and are not collectively a PHB
      group.

It should say:

      RFC 2597: revise to reflect understanding that, AF classes are
      instances of the AF PHB group, and are not collectively a PHB
      group.

Notes:

There is a typo. This is the RFC 2597, which actually defines the AF PHB group. RFC 2497 have nothing to do with AF classes.

RFC 3261, "SIP: Session Initiation Protocol", June 2002

Note: This RFC has been updated by RFC 3265, RFC 3853, RFC 4320, RFC 4916, RFC 5393, RFC 5621, RFC 5626, RFC 5630, RFC 5922, RFC 5954, RFC 6026, RFC 6141, RFC 6665, RFC 6878, RFC 7462, RFC 7463, RFC 8217, RFC 8591, RFC 8760, RFC 8898, RFC 8996

Source of RFC: sip (rai)

Errata ID: 678
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Matthew S. Harris
Date Reported: 2006-08-14
Held for Document Update by: Cullen Jennings

Section 25.1 says:

On page 220, it says "The TEXT-UTF8-TRIM rule is used for descriptive
field contents that are n t quoted strings, where leading and trailing
LWS is not meaningful."  (And no, I'm not talking about the "n t"
typo.)  The rule for TEXT-UTF8-TRIM is

 TEXT-UTF8-TRIM  = 1*TEXT-UTF8char *(*LWS TEXT-UTF8char)
 TEXT-UTF8char = %x21-7E / UTF8-NONASCII

which pretty clearly says that the final character of TEXT-UTF8-TRIM
cannot be whitespace.  TEXT-UTF8-TRIM appears only as the value of a
header field, and the rule for message-header does not generate
trailing whitespace either.

So the text talks about trailing whitespace, which seems reasonable
because whitespace is allowed in many other places, but the grammar
does not allow it.  Was trailing whitespace intended?

It should say:

[not submitted]

Notes:

from pending

Errata ID: 832
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Marco Ambu
Date Reported: 2006-01-11
Held for Document Update by: Robert Sparks

 

I would like to show you an ambiguity in RFC 3261.

The ABNF for SIP in RFC 3261 page 227 defines header Accept as 
"Accept = "Accept" HCOLON [accept-range *(COMMA accept-range)].

Expanding this form we have:

Accept = "Accept" HCOLON [( (...) *(SEMI m-parameter) *(SEMI 
accept-param) ) *(COMMA accept-range)]

For example we can have

Accept: 
application/sdp;m_extension_parameter=value1;accept_extension_param=value2;q=0.5
We know from RFC 3261 that q is an accept-param.
We don't know how to consider the first two unknown parameters: how to 
distinguish from m-parameter and accept-param?

While in other cases RFC 3261 shows the rules to solve ambiguities (for 
example how to consider the parameters in a Contact URI if the URI is 
not enclosed in angular brackets) I have not found any suggestion for 
this specific case in RFC 3261.

It should say:

[not submitted]

Notes:

from pending

Errata ID: 1682
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Iñaki Baz Castillo
Date Reported: 2009-02-10
Held for Document Update by: Robert Sparks

Section 20.7 says:

Authorization: Digest username="Alice", realm="atlanta.com",
  nonce="84a4cc6f3082121f32b42a2187831a9e",
  response="7587245234b3434cc3412213e5f113a5432"

It should say:

Authorization: Digest username="Alice", realm="atlanta.com",
  nonce="84a4cc6f3082121f32b42a2187831a9e",
  response="7587245234b3434cc3412213e5f113a5"

Notes:

'response' field in original example has 35 hexadecimal characters while they must be 32:

dresponse = "response" EQUAL request-digest
request-digest = LDQUOT 32LHEX RDQUOT

Errata ID: 2769
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Iñaki Baz Castillo
Date Reported: 2011-04-08
Held for Document Update by: Robert Sparks

Section 17.1.2.2 says:

   MUST be passed to the transport layer for transmission.  If an
   unreliable transport is in use, the client transaction MUST set timer
   E to fire in T1 seconds.  If timer E fires while still in this state,
   the timer is reset, but this time with a value of MIN(2*T1, T2).
   When the timer fires again, it is reset to a MIN(4*T1, T2).  This
   process continues so that retransmissions occur with an exponentially
   increasing interval that caps at T2.

It should say:

   MUST be passed to the transport layer for transmission.  If an
   unreliable transport is in use, the client transaction MUST set timer
   E to fire in T1 seconds.  If timer E fires while still in this state,
   the timer is reset, but this time with a value of MIN(2*T1, T2).
   When the timer fires again, it is reset to a MIN(4*T1, T2). Multiplier
   on T1 doubles with each reset so that retransmissions occur with an
   exponentially increasing interval that caps at T2.

Notes:

The original text doesn't clarify that the multiplier of T1 is doubled with each timer reset, so it could be understood that the maximum value the timer takes is MIN(4*T1, T2) which is 2s (so the timer would never reach 4s and the resulting intervals would be 500ms, 1s, 2s, 2s, 2s, 2s, etc).

Errata ID: 3098
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alec Davis
Date Reported: 2012-01-27
Held for Document Update by: Robert Sparks
Date Held: 2012-01-27

Section 12.2.1.1 says:

A client could, for example, choose the 31 most significant bits of a 32-bit
 second clock as an initial sequence number.

It should say:

A client could, for example, choose the 31 least significant bits of a 32-bit
 second clock as an initial sequence number.

Notes:

Choosing the most sig 31 bits would violate 8.1.1.5, where initial CSeq number must be less than 2**31

8.1.1.5: The sequence number value MUST be expressible as a 32-bit unsigned integer and MUST be less than 2**31.


REVIEWER NOTE (rjsparks@nostrum.com) : It was explicitly the intent to point to the most significant bits. The confusion in this report is not recognizing that the intent is to treat those as a 31-bit integer (which by definition will be less than 2**31). Rather than reject the errata, I'm putting this in hold for document update so future revisions can clarify the point.

Errata ID: 3102
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alec Davis
Date Reported: 2012-02-01
Held for Document Update by: Robert Sparks

Section 12.2.1.1 says:

      With a length of 32 bits, a client could generate, within a single
      call, one request a second for about 136 years before needing to
      wrap around.  The initial value of the sequence number is chosen
      so that subsequent requests within the same call will not wrap
      around.

It should say:

      With a length of 32 bits, a client could generate, within a single
      call, one request a second for about 136 years before exhausting
      available sequence numbers. Sequence numbers must not wrap around to 0.
      The initial value of the sequence number (less than 2**31) is chosen
      so that subsequent requests within the same call will not exceed 2**32-1.
      

Notes:

Highlight that within a dialog sequence numbers;
1). can increment to 2**32-1
2). must not wrap around to 0

Errata ID: 3684
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Colin Fraizer
Date Reported: 2013-07-16
Held for Document Update by: Gonzalo Camarillo

Section 7.3 says:

 Specifically, any SIP header whose grammar is of the form

      header  =  "header-name" HCOLON header-value *(COMMA header-value)

   allows for combining header fields of the same name into a comma-
   separated list.  The Contact header field allows a comma-separated
   list unless the header field value is "*".

It should say:

 Specifically, any SIP header whose grammar is of the form

      header  =  header-name HCOLON header-value *(COMMA header-value)

   allows for combining header fields of the same name into a comma-
   separated list.  The Contact header field allows a comma-separated
   list unless the header field value is "*".

Notes:

That is, remove the double quotes around the word `header-name' in the ABNF.

Errata ID: 3875
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Varun Bharadwaj S V
Date Reported: 2014-01-31
Held for Document Update by: Richard Barnes
Date Held: 2014-02-15

Section 17 says:

17 Transcations

 - Additionally, in the case of an INVITE request, the client
transaction is responsible for generating the ACK request for any
final response accepting a 2xx response.

It should say:

17 Transcations

 - Additionally, in the case of an INVITE request, the client
transaction is responsible for generating the ACK request for any
final response excepting a 2xx response.

Notes:

Client transaction should generate the ACK except for 2xx responses.It should not accept & generate the ACK for 2xx response.
For Server transaction RFC says - "In the case of an INVITE transaction, it absorbs the ACK request for any final response excepting a 2xx response."

Errata ID: 5598
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Roman Shpount
Date Reported: 2019-01-11
Held for Document Update by: Ben Campbell
Date Held: 2019-02-14

Section 25.1 says:

display-name   =  *(token LWS)/ quoted-string

It should say:

display-name   =  token *(LWS token)/ quoted-string

Notes:

There is a contradiction between the ABNF rule and specification.

The name-addr ABNF rule in RFC 3261 specifies:

name-addr = [ display-name ] LAQUOT addr-spec RAQUOT
addr-spec = SIP-URI / SIPS-URI / absoluteURI
display-name = *(token LWS)/ quoted-string

Based on this, LWS is always required between token and the "<" and the following Name-Address value is invalid: foo<sip:foo@bar.com>

At the same time section 20.10 says:

There may or may not be LWS between the display-name and the "<".

This implies that foo<sip:foo@bar.com> should be acceptable.

I propose to change ABNF rule for display-name to allow no LWS between last token and the "<"

Errata ID: 1471
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Iñaki Baz Castillo
Date Reported: 2008-07-14
Held for Document Update by: Robert Sparks

Section 17 says:

Additionally, in the case of an INVITE request, the client
transaction is responsible for generating the ACK request for any
final response accepting a 2xx response.

It should say:

Additionally, in the case of an INVITE request, the client
transaction is responsible for generating the ACK request for any
final response excepting a 2xx response.

Notes:

"accepting a 2xx response" => "excepting a 2xx response"

Errata ID: 1472
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Iñaki Baz Castillo
Date Reported: 2008-07-14
Held for Document Update by: Robert Sparks

Section 25.1 says:

The TEXT-UTF8-TRIM rule is used for descriptive field 
contents that are n t quoted strings,

It should say:

The TEXT-UTF8-TRIM rule is used for descriptive field 
contents that are not quoted strings,

Notes:

"are n t" => "are not"

Errata ID: 3237
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kevin P. Fleming
Date Reported: 2012-05-31
Held for Document Update by: Robert Sparks

Section 8.1.3.5 says:

   In all of the above cases, the request is retried by creating a new
   request with the appropriate modifications.  This new request
   constitutes a new transaction and SHOULD have the same value of the
   Call-ID, To, and From of the previous request, but the CSeq should
   contain a new sequence number that is one higher than the previous.

It should say:

   In all of the above cases, the request is retried by creating a new 
   request with the appropriate modifications.  This new request 
   constitutes a new transaction and SHOULD have the same value of the 
   Call-ID, To, and From of the previous request, but the CSeq SHOULD 
   contain a new sequence number that is one higher than the previous.

Notes:

We have had one implementor claim that they are not required to increment CSeq when retrying the request because the RFC says 'should' and not 'SHOULD'. Based on current IETF discussions, though, these should probably be changed to MUST anyway, but that's a much more substantive change throughout the whole RFC.

Errata ID: 4385
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Krisztian Sinka
Date Reported: 2015-06-02
Held for Document Update by: Ben Campbell
Date Held: 2015-06-05

Section 17.2.1 says:

                               |INVITE
                               |pass INV to TU
            INVITE             V send 100 if TU won't in 200ms
            send response+-----------+
                +--------|           |--------+101-199 from TU
                |        | Proceeding|        |send response
                +------->|           |<-------+
                         |           |          Transport Err.
                         |           |          Inform TU
                         |           |--------------->+
                         +-----------+                |

It should say:

                               |INVITE
                               |-
            INVITE             V send 100 if TU won't in 200ms
            send response+-----------+
                +--------|           |--------+101-199 from TU
                |        | Proceeding|        |send response
                +------->|           |<-------+
                         |           |          Transport Err.
                         |           |          Inform TU
                         |           |--------------->+
                         +-----------+                |

Notes:

The standard states about lifetime of the server transaction:

"Server transactions are created by the
core when a request is received, and transaction handling is desired
for that request (this is not always the case)."(17.2)

So this means that the server transaction is created by the TU (the core). This also means that it is useless to *pass INV to TU* due to that TU itself already has the request.

The same logic should apply to Figure 8. as well.

Errata ID: 4675
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bruce Florman
Date Reported: 2016-04-21
Held for Document Update by: Ben Campbell
Date Held: 2016-05-05

Section 8.1.1.3 says:

   Examples:

      From: "Bob" <sips:bob@biloxi.com> ;tag=a48s
      From: sip:+12125551212@phone2net.com;tag=887s
      From: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8

It should say:

   Examples:

      From: "Bob" <sips:bob@biloxi.com> ;tag=a48smh2
      From: sip:+12125551212@phone2net.com;tag=887s6pa
      From: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8mtf

Notes:

I know this is more than a little picayune, but...

Section 19.3 says:

When a tag is generated by a UA for insertion into a request or
response, it MUST be globally unique and cryptographically random
with at least 32 bits of randomness.

This implies that the tag value must be at least 32 bits in size.

Section 25.1 says:

token = 1*(alphanum / "-" / "." / "!" / "%" / "*"
/ "_" / "+" / "`" / "'" / "~" )
and
tag-param = "tag" EQUAL token

Although the actual representation of the tag value is implementation-specific, since there are only 72 characters available with which to encode it, a tag value with only four characters can represent a maximum of 72^4 distinct numeric values, which is less than the 2^32 values that can be represented by 32 bits by a factor of nearly 160.

Even if the implementation chooses to omit "leading zeros" (or something equivalent), the likelihood of three 32 bit random values all falling in the range of values that can be represented in four characters would be less than one in five million. So even if the given examples are theoretically possible for a conforming implementation, they seem rather misleading.

For a "typical" 32 bit random value, even with base74 encoding, the shortest tag value would require six characters. Given that all three examples (which are also repeated almost unchanged in section 20.20) contain no uppercase ALPHA characters in the tag values, the implied encoding is more likely something like base32 or base36, which would require at least seven characters to represent a typical 32 bit random value. So that's how I'm suggesting that the examples be amended.

RFC 3264, "An Offer/Answer Model with Session Description Protocol (SDP)", June 2002

Note: This RFC has been updated by RFC 6157, RFC 8843, RFC 9143

Source of RFC: mmusic (rai)

Errata ID: 2098
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Parveen Verma
Date Reported: 2010-03-30
Held for Document Update by: Robert Sparks

Section 10 says:

10.1 Basic Exchange

   Assume that the caller, Alice, has included the following description
   in her offer.  It includes a bidirectional audio stream and two
   bidirectional video streams, using H.261 (payload type 31) and MPEG
   (payload type 32).  The offered SDP is:

   v=0
   o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
   s=
   c=IN IP4 host.anywhere.com
   t=0 0
   m=audio 49170 RTP/AVP 0
   a=rtpmap:0 PCMU/8000
   m=video 51372 RTP/AVP 31
   a=rtpmap:31 H261/90000
   m=video 53000 RTP/AVP 32
   a=rtpmap:32 MPV/90000

It should say:

10.1 Basic Exchange

   Assume that the caller, Alice, has included the following description
   in her offer.  It includes a bidirectional audio stream and two
   bidirectional video streams, using H.261 (payload type 31) and MPEG
   (payload type 32).  The offered SDP is:

   v=0
   o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
   s=-
   c=IN IP4 host.anywhere.com
   t=0 0
   m=audio 49170 RTP/AVP 0
   a=rtpmap:0 PCMU/8000
   m=video 51372 RTP/AVP 31
   a=rtpmap:31 H261/90000
   m=video 53000 RTP/AVP 32
   a=rtpmap:32 MPV/90000

Notes:

The s= session name must have some values as per RFC 4566 Sec 5.3.
----------------------------------------------------------------
RFC 4566
5.3. Session Name ("s=")

s=<session name>

The "s=" field is the textual session name. There MUST be one and
only one "s=" field per session description. The "s=" field MUST NOT
be empty and SHOULD contain ISO 10646 characters (but see also the
"a=charset" attribute). If a session has no meaningful name, the
value "s= " SHOULD be used (i.e., a single space as the session name).
----------------------------------------------------------------
RFC 3264 also states in Section 5
"Unfortunately, SDP does not allow the "s=" line to be empty."

Even if we put "s= " , it becomes a bit difficult to read/understand in soft/printed copy.

The same error applies to all SDP examples given in Section 10

Errata ID: 2099
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Brett Tate
Date Reported: 2010-03-30
Held for Document Update by: Robert Sparks

Section 9 says:

   v=0
   o=carol 28908764872 28908764872 IN IP4 100.3.6.6
   s=-
   t=0 0
   c=IN IP4 192.0.2.4
   m=audio 0 RTP/AVP 0 1 3
   a=rtpmap:0 PCMU/8000
   a=rtpmap:1 1016/8000
   a=rtpmap:3 GSM/8000
   m=video 0 RTP/AVP 31 34
   a=rtpmap:31 H261/90000
   a=rtpmap:34 H263/90000

   Figure 1: SDP Indicating Capabilities

It should say:

   v=0
   o=carol 28908764872 28908764872 IN IP4 100.3.6.6
   s=-
   c=IN IP4 192.0.2.4
   t=0 0
   m=audio 0 RTP/AVP 0 1 3
   a=rtpmap:0 PCMU/8000
   a=rtpmap:1 1016/8000
   a=rtpmap:3 GSM/8000
   m=video 0 RTP/AVP 31 34
   a=rtpmap:31 H261/90000
   a=rtpmap:34 H263/90000

   Figure 1: SDP Indicating Capabilities

Notes:

Location of "c=" line is invalid per RFC 2327 and RFC 4566. The corrected text reflects the "c=" line within a valid location.

RFC 3278, "Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)", April 2002

Note: This RFC has been obsoleted by RFC 5753

Source of RFC: smime (sec)

Errata ID: 6542
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Juli Mallett
Date Reported: 2021-04-13
Held for Document Update by: Benjamin Kaduk
Date Held: 2021-04-15

Throughout the document, when it says:

   4  AuthenticatedData using ECC ............ ......................  8

It should say:

   4  AuthenticatedData using ECC ...................................  8

Notes:

Incorrect space in justification.

RFC 3279, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", April 2002

Note: This RFC has been updated by RFC 4055, RFC 4491, RFC 5480, RFC 5758, RFC 8692

Source of RFC: pkix (sec)

Errata ID: 6672
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Jaime Hablutzel
Date Reported: 2021-09-01
Held for Document Update by: Paul Wouters
Date Held: 2024-01-12

Section 2.3.5 says:

If the keyUsage extension is present in a CA or CRL issuer certificate which conveys an elliptic curve public key, any combination of the following values MAY be present:

digitalSignature;
nonRepudiation; and
keyAgreement.

If the keyAgreement value is present, either of the following values MAY be present:

encipherOnly; and
decipherOnly.

The keyUsage extension MUST NOT assert both encipherOnly and decipherOnly.

If the keyUsage extension is present in a CA certificate which conveys an elliptic curve public key, any combination of the following values MAY be present:

digitalSignature;
nonRepudiation;
keyAgreement;
keyCertSign; and
cRLSign.

It should say:

If the keyUsage extension is present in an end entity certificate which conveys an elliptic curve public key, any combination of the following values MAY be present:

digitalSignature;
nonRepudiation; and
keyAgreement.

If the keyAgreement value is present, either of the following values MAY be present:

encipherOnly; and
decipherOnly.

The keyUsage extension MUST NOT assert both encipherOnly and decipherOnly.

If the keyUsage extension is present in a CA or CRL issuer certificate which conveys an elliptic curve public key, any combination of the following values MAY be present:

digitalSignature;
nonRepudiation;
keyAgreement;
keyCertSign; and
cRLSign.

Notes:

- "a CA or CRL issuer certificate" is replaced by "an end entity certificate"
- "CA certificate" is replaced by "CA or CRL issuer certificate"

The need for this correction can be confirmed from RFC 5480, "3. Key Usage Bits".

Corrected wording has been copied from the section "2.3.1 RSA Keys" of this RFC 3279 itself.

Paul Wouters (AD): As 5480 updates 3279, this errata is resolved

Errata ID: 1909
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jim Wigginton
Date Reported: 2009-10-12
Held for Document Update by: Pasi Eronen
Date Held: 2010-02-22

Throughout the document, when it says:

Notes:

Replace "ansi-X9.62" with "ansi-X9-62" in Section 2.3.5.
Replace "id-public-key-type" with "id-publicKeyType" in Section 2.3.5.
Replace "sha-1WithRSAEncryption" with "sha1WithRSAEncryption" in Section 2.2.2.

RFC 3280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", April 2002

Note: This RFC has been obsoleted by RFC 5280

Note: This RFC has been updated by RFC 4325, RFC 4630

Source of RFC: pkix (sec)

Errata ID: 4972
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Rick van Rein
Date Reported: 2017-03-17
Held for Document Update by: Paul Wouters
Date Held: 2024-01-12

Section 4.2.1.5 says:

   id-ce-certificatePolicies OBJECT IDENTIFIER ::=  { id-ce 32 }

   anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificate-policies 0 }

It should say:

   id-ce-certificatePolicies OBJECT IDENTIFIER ::=  { id-ce 32 }

   anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificatePolicies 0 }

Notes:

The ASN.1 did not compile due to a missing identifier. The corrected text does also occur in A.2.

Paul Wouters (AD): This is resolved in RFC 5280 which obsoletes this RFC.

Errata ID: 2858
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jaime Hablutzel
Date Reported: 2011-07-12
Held for Document Update by: Sean Turner

Section 4.1.2.4 says:

   Exceptions to the December 31, 2003 UTF8 encoding requirements are as
   follows:

      (a)  CAs MAY issue "name rollover" certificates to support an
      orderly migration to UTF8String encoding.  Such certificates would
      include the CA's UTF8String encoded name as issuer and and the old
      name encoding as subject, or vice-versa.

It should say:

   Exceptions to the December 31, 2003 UTF8 encoding requirements are as
   follows:

      (a)  CAs MAY issue "name rollover" certificates to support an
      orderly migration to UTF8String encoding.  Such certificates would
      include the CA's UTF8String encoded name as issuer and the old
      name encoding as subject, or vice-versa.

Notes:

there is a duplicate 'and'

RFC 3289, "Management Information Base for the Differentiated Services Architecture", May 2002

Source of RFC: diffserv (tsv)

Errata ID: 2976
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Ina Singh
Date Reported: 2011-09-21
Held for Document Update by: Wesley Eddy

Section 3.4.5. says:

   diffServRandomDropInvProbMax represents Pmax (inverse).  This MIB
   does not represent Pmin (assumed to be zero unless otherwise
   represented).  In addition, since message memory is finite, queues
   generally have some upper bound above which they are incapable of
   storing additional traffic.  Normally this number is equal to Qclip,
   specified by diffServAlgDropQThreshold.

It should say:

       The average queue depth beyond which traffic has a probability
       indicated by diffServRandomDropProbMax of being dropped or
       marked. Note that this differs from the physical queue limit,
       which is stored in diffServAlgDropQThreshold. 

Notes:

diffServRandomDropInvProbMax should be removed

Attaching the e-mail confirmation from Fred :
==============================================


From: Fred Baker (fred)
Sent: Tuesday, September 20, 2011 10:54 PM
To: Ina Singh (inasingh)
Subject: Re: RFC3289/DiffesrvMIB SFS

Thanks for pointing this out. Correct me if I'm wrong; it looks to me like diffServRandomDropInvProbMax only shows up in the comment in section 3.4.5, and diffServRandomDropProbMax is used throughout the MIB. Yes, the comment should be fixed, but the MIB is itself correct with diffServRandomDropProbMax. Correct?

The right thing to do is file an erratum against RFC 3289, so that if it is edited in the future the error can be picked up, and implementers can see it.

http://www.ietf.org/iesg/statement/errata-processing.html describes the process.


On Sep 20, 2011, at 6:50 PM, Ina Singh (inasingh) wrote:

> Hey Fred,
>
> While implementing RFC3289/DiffesrvMIB SFS recently on IOS, we noticed the following error :
> It would seem that diffServRandomDropInvProbMax was replaced by
> diffServRandomDropProbMax (?) , but the reference to “diffServRandomDropInvProbMax” was not removed on subsequent versions.
>
> Can you please confirm, if so, what’s the procedure to correct it ..
>
> Thanks in advance for your help in this and appreciate your time..
>
> Ina
>
> Definition of "diffServRandomDropInvProbMax" upto version 7, here is a link for draft version 6.
>
> http://tools.ietf.org/html/draft-ietf-diffserv-mib-06
>
> iffServRandomDropInvProbMax OBJECT-TYPE
> SYNTAX Unsigned32
> MAX-ACCESS read-create
> STATUS current
> DESCRIPTION
> "The worst case random drop probability, expressed as
> the inverse of the drop probability. With special
> case of the value zero meaning zero probability of
> drop.
>
> For example, if every packet may be dropped in the
> worst case (100%), this has the value of
> 4,294,967,295."
> ::= { diffServRandomDropEntry 6 }
>
>
>
> In contrast to "diffServRandomDropProbMax" starting from version 8.
>
>
> diffServRandomDropProbMax OBJECT-TYPE
>
> SYNTAX Unsigned32 (0..1000)
> MAX-ACCESS read-create
> STATUS current
> DESCRIPTION
> "The worst case random drop probability, expressed in drops per
> thousand packets.
>
> For example, if in the worst case every arriving packet may be
> dropped (100%) for a period, this has the value 1000.
> Alternatively, if in the worst case only one percent (1%) of
> traffic may be dropped, it has the value 10."
> ::= { diffServRandomDropEntry 6 }

RFC 3305, "Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations", August 2002

Source of RFC: Legacy
Area Assignment: app

Errata ID: 1375
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: K. Ohwashi
Date Reported: 2008-03-20
Held for Document Update by: Peter Saint-Andre

Section 5 says:

   1. The W3C and IETF should jointly develop and endorse a model for
      URIs, URLs, and URNs consistent with the "Contemporary View"
      described in section 1, and which considers the additional URI
      issues listed or alluded to in section 3.

It should say:

   1. The W3C and IETF should jointly develop and endorse a model for
      URIs, URLs, and URNs consistent with the "Contemporary View"
      described in section 2, and which considers the additional URI
      issues listed or alluded to in section 3.

Errata ID: 2787
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: J. Clelland
Date Reported: 2011-04-20
Held for Document Update by: Pete Resnick
Date Held: 2011-05-16

Section 3.1.1 says:

The official register of URI scheme names is maintained by IANA, at
   http://www.iana.org/assignments/uri-schemes.

It should say:

The official register of URI scheme names is maintained by IANA, at
   http://www.iana.org/assignments/uri-schemes.html.

Notes:

The iana.org web site redirects appropriately, so this can be addressed in a future revision.

RFC 3312, "Integration of Resource Management and Session Initiation Protocol (SIP)", October 2002

Note: This RFC has been updated by RFC 4032, RFC 5027

Source of RFC: sip (rai)

Errata ID: 4883
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Shraddha Soni
Date Reported: 2016-12-12
Held for Document Update by: Ben Campbell
Date Held: 2016-12-13

Section 11 says:

Therefore, a user agent
   including preconditions in the SDP MUST support the PRACK and UPDATE
   methods. Consequently, it MUST include the "100rel" [7] tag in the
   Supported header field and SHOULD include an Allow header field with
   the "UPDATE" tag [5].

It should say:

Therefore, a user agent
   including preconditions in the SDP MUST support the PRACK and UPDATE
   methods. Consequently, it MUST include the "100rel" [7] tag in the
   Supported header field and MUST include an Allow header field with
   the "UPDATE" tag [5].

Notes:

As stated in first line in the mentioned paragraph, the user agent MUST support the UPDATE method, hence even in Allow header field also, UPDATE method MUST be included.

As per RFC 2119
"SHOULD -This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course. "

Here in precondition case, whether any chance of ignoring the UPDATE method happens ?

As per RFC 3261
Section 8.2.1 states -
"The Allow header field MUST list the set of methods supported by the UAS
generating the message. ... If the method is one supported by the server, processing continues."

and also in RFC 3261 Sections 20.5 states-
"All methods, including ACK and CANCEL, understood by the UA MUST be
included in the list of methods in the Allow header field, when
present."

Errata ID: 3117
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Beis Grigorios
Date Reported: 2012-02-08
Held for Document Update by: Robert Sparks

Section 8 says:

The port number of every "m=" line MUST be set to zero, but the connection address is arbitrary.

The desired status line corresponding to the precondition that
triggered the failure MUST use the "failure" strength-tag, as shown
in the example below:

      m=audio 20000 RTP/AVP 0
      a=des:qos failure e2e send

It should say:

The port number of every "m=" line MUST be set to zero, but the connection address is arbitrary.

The desired status line corresponding to the precondition that
triggered the failure MUST use the "failure" strength-tag, as shown
in the example below:

      m=audio 0 RTP/AVP 0
      a=des:qos failure e2e send

Notes:

The G711U codec's payload type 0 that appears in the m-line, probably led to the typo error with the incorrect port number (20000 instead of 0).

Errata ID: 3119
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Beis Grigorios
Date Reported: 2012-02-09
Held for Document Update by: Robert Sparks

Section 9 says:

m=audio 20000 RTP/AVP 0
a=des:foo unknown e2e send

It should say:

m=audio 0 RTP/AVP 0
a=des:foo unknown e2e send

Notes:

Same typo as Errata ID: 3117. The port number must be set to zero.

Errata ID: 4884
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Shraddha Soni
Date Reported: 2016-12-12
Held for Document Update by: Ben Campbell
Date Held: 2016-12-12

Section 7 says:

If a peer has requested confirmation on a particular stream, an agent
   MUST mark that stream with a flag in its local status table. 

It should say:

If a peer has requested confirmation on a particular stream, an agent 
   MUST mark that stream with a flag in its local status table.  

Notes:

The only place in RFC, where 'agent' is mentioned instead of 'User Agent'. Use of 'User agent' is more appropriate in SIP context as per RFC 3261.
Unable to submit the errata when corrected text is mentioned as "user agent" Hence pasting same text in original text. Have submitted feedback online for the webpage issue.

RFC 3315, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", July 2003

Note: This RFC has been obsoleted by RFC 8415

Note: This RFC has been updated by RFC 4361, RFC 5494, RFC 6221, RFC 6422, RFC 6644, RFC 7083, RFC 7227, RFC 7283, RFC 7550

Source of RFC: dhc (int)

Errata ID: 2509
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Suresh Krishnan
Date Reported: 2010-09-03
Held for Document Update by: Ralph Droms

Section 22.7 says:

A server MAY include an Option Request option in a 
Reconfigure option to indicate which options the client should 
request from the server.

It should say:

A server MAY include an Option Request option in a 
Reconfigure message to indicate which options the client should 
request from the server.

Notes:

There is no such thing as a "Reconfigure option". I believe that the intent was to refer to the Reconfigure message instead.

Errata ID: 295
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hideshi Enokihara
Date Reported: 2006-06-29
Held for Document Update by: Brian Haberman

Section 18.2.7 says:

   After all the addresses have been processed, the server generates a
   Reply message and includes a Status Code option with the value
   Success, a Server Identifier option with the server's DUID, and a
   Client Identifier option with the client's DUID.  For each IA in the
   Decline message for which the server has no binding information, the
   server adds an IA option using the IAID from the Release message and
   includes a Status Code option with the value NoBinding in the IA
   option.  No other options are included in the IA option.

It should say:

   After all the addresses have been processed, the server generates a
   Reply message and includes a Status Code option with the value
   Success, a Server Identifier option with the server's DUID, and a
   Client Identifier option with the client's DUID.  For each IA in the
   Decline message for which the server has no binding information, the
   server adds an IA option using the IAID from the Decline message and
   includes a Status Code option with the value NoBinding in the IA
   option.  No other options are included in the IA option.

Errata ID: 5450
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2018-08-03
Held for Document Update by: Éric Vyncke
Date Held: 2021-02-05

Section 18.2.5 says:

   The server MUST include a Server Identifier option containing the
   server's DUID in the Reply message.  If the client included a Client
   Identification option in the Information-request message, the server
   copies that option to the Reply message.

It should say:

   The server MUST include a Server Identifier option containing the
   server's DUID in the Reply message.  If the client included a Client
   Identifier option in the Information-request message, the server
   copies that option to the Reply message.

Notes:

Incorrect option name

-- Verifier note --
Indeed, minor typo in "Client Identification" rather than "Client Identifier".

RFC 3327, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", December 2002

Note: This RFC has been updated by RFC 5626

Source of RFC: sip (rai)

Errata ID: 2778
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Iñaki Baz Castillo
Date Reported: 2011-04-16
Held for Document Update by: Robert Sparks

Section 5.5.2 says:

   Message sequence for INVITE using Path:

   F1 Invite UA2 -> REGISTRAR

      INVITE UA1@EXAMPLEHOME.COM SIP/2.0
      Via: SIP/2.0/UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3R
      To: UA1 <sip:UA1@EXAMPLEHOME.COM>
      From: UA2 <sip:UA2@FOREIGN.ELSEWHERE.ORG>;tag=224497
      Call-ID: 48273181116@71.91.180.10
      CSeq: 29 INVITE
      Contact: <sip:UA2@71.91.180.10>
       . . .

It should say:

   Message sequence for INVITE using Path:

   F1 Invite UA2 -> REGISTRAR

      INVITE sip:UA1@EXAMPLEHOME.COM SIP/2.0
      Via: SIP/2.0/UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3R
      To: UA1 <sip:UA1@EXAMPLEHOME.COM>
      From: UA2 <sip:UA2@FOREIGN.ELSEWHERE.ORG>;tag=224497
      Call-ID: 48273181116@71.91.180.10
      CSeq: 29 INVITE
      Contact: <sip:UA2@71.91.180.10>
       . . .

Notes:

In all the example flow the Request URI is wrong as doesn't contain the URI scheme ("sip" / "sips").

RFC 3329, "Security Mechanism Agreement for the Session Initiation Protocol (SIP)", January 2003

Note: This RFC has been updated by RFC 8996

Source of RFC: sip (rai)

Errata ID: 2169
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Dawes
Date Reported: 2010-04-23
Held for Document Update by: Robert Sparks

Section 4.1 says:

The 200 OK response (6) for the INVITE and the ACK (7) are also sent
   over the TLS connection.  The ACK will contain the same Security-
   Verify header field as the INVITE (3).

It should say:

The 200 OK response (6) for the INVITE and the ACK (7) are also sent
   over the TLS connection.

Notes:

RFC3329 Section 2.6, Table 1: Summary of Header Usage. indicates that Security-Client, Security-Server, Security-Verify are "Not applicable" to the SIP ACK request.

RFC 3261 says (section 20) "Not applicable" means that the header
field MUST NOT be present in a request. If one is placed in a
request by mistake, it MUST be ignored by the UAS receiving the
request.

Errata ID: 2170
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Dawes
Date Reported: 2010-04-23
Held for Document Update by: Robert Sparks

Section 4.2 says:

The second INVITE (4) and the ACK (8) contain a Security-Verify
   header field that mirrors the Security-Server header field received
   in the 421.

It should say:

The second INVITE (4) contains a Security-Verify
   header field that mirrors the Security-Server header field received
   in the 421.

Notes:

RFC 3329 Section 2.6, Table 1: Summary of Header Usage. indicates that Security-Client, Security-Server, Security-Verify are "Not applicable" to the SIP ACK request.

RFC 3261 says "Not applicable" means that the header field MUST NOT be present in a request. If one is placed in a request by mistake, it MUST be ignored by the UAS receiving the request."

RFC 3330, "Special-Use IPv4 Addresses", September 2002

Note: This RFC has been obsoleted by RFC 5735

Source of RFC: Legacy
Area Assignment: int

Errata ID: 1436
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Frank Ellermann
Date Reported: 2008-06-12
Held for Document Update by: Ron Bonica

Section 3 says:

   0.0.0.0/8            "This" Network                 [RFC1700, page 4]
   10.0.0.0/8           Private-Use Networks                   [RFC1918]
   14.0.0.0/8           Public-Data Networks         [RFC1700, page 181]
   24.0.0.0/8           Cable Television Networks                    --
   39.0.0.0/8           Reserved but subject
                           to allocation                       [RFC1797]
   127.0.0.0/8          Loopback                       [RFC1700, page 5]
   128.0.0.0/16         Reserved but subject
                           to allocation                             --
   169.254.0.0/16       Link Local                                   --
   172.16.0.0/12        Private-Use Networks                   [RFC1918]
   191.255.0.0/16       Reserved but subject
                           to allocation                             --
   192.0.0.0/24         Reserved but subject
                           to allocation                             --
   192.0.2.0/24         Test-Net
   192.88.99.0/24       6to4 Relay Anycast                     [RFC3068]
   192.168.0.0/16       Private-Use Networks                   [RFC1918]
   198.18.0.0/15        Network Interconnect
                           Device Benchmark Testing            [RFC2544]
   223.255.255.0/24     Reserved but subject
                           to allocation                             --
   224.0.0.0/4          Multicast                              [RFC3171]
   240.0.0.0/4          Reserved for Future Use        [RFC1700, page 4]

It should say:

   0.0.0.0/8            "This" Network                [RFC1122, page 30]
   10.0.0.0/8           Private-Use Networks                   [RFC1918]
   14.0.0.0/8           Public-Data Networks         [RFC1700, page 181]
   24.0.0.0/8           Cable Television Networks                    --
   39.0.0.0/8           Reserved but subject
                           to allocation                       [RFC1797]
   127.0.0.0/8          Loopback                      [RFC1122, page 31]
   128.0.0.0/16         Reserved but subject
                           to allocation                             --
   169.254.0.0/16       Link Local                                   --
   172.16.0.0/12        Private-Use Networks                   [RFC1918]
   191.255.0.0/16       Reserved but subject
                           to allocation                             --
   192.0.0.0/24         Reserved but subject
                           to allocation                             --
   192.0.2.0/24         Test-Net
   192.88.99.0/24       6to4 Relay Anycast                     [RFC3068]
   192.168.0.0/16       Private-Use Networks                   [RFC1918]
   198.18.0.0/15        Network Interconnect
                           Device Benchmark Testing            [RFC2544]
   223.255.255.0/24     Reserved but subject
                           to allocation                             --
   224.0.0.0/4          Multicast                              [RFC3171]
   240.0.0.0/4          Reserved for Future Use        [RFC1112, page 3]

Notes:

RFC 1700, page 4, does not mention 240.0.0.0/4.

RFC 3331, "Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer", September 2002

Source of RFC: sigtran (rai)

Errata ID: 1425
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-05-16
Held for Document Update by: Robert Sparks

Section 3.3.4.1,p.53 says:

a)
|     The SDT Identifier is a 32-bit unsigned value which may only be
      significant to 12 or 14 bits depending on the SS7 variant which is
      supported by the MTP Level 3 at the ASP.  Insignificant SDT
      Identifier bits are coded 0.

b)
|     The SDL Identifier is a 32-bit unsigned value which may only be
      significant to 12 or 14 bits depending on the SS7 variant which
      is supported by the MTP Level 3 at the ASP.  Insignificant SDLI
      bits are coded 0.

It should say:

a)
|     The SDT Identifier is a 16-bit unsigned value which may only be
      significant to 12 or 14 bits depending on the SS7 variant which is
      supported by the MTP Level 3 at the ASP.  Insignificant SDT
      Identifier bits are coded 0.

b)
|     The SDL Identifier is a 16-bit unsigned value which may only be
      significant to 12 or 14 bits depending on the SS7 variant which
      is supported by the MTP Level 3 at the ASP.  Insignificant SDLI
      bits are coded 0.

Notes:

In both cases, the field width "32-bit" in the text does not match
the parameter breakdown in the immediately preceding artwork.
The above corrections are based on the assumption that the figures
are correct and the text is in error.

Errata ID: 1426
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-05-16
Held for Document Update by: Robert Sparks

Section 3.3.2.6,p.35 says:

   The sending node defines the Heartbeat Data field contents.  It may
   include a Heartbeat Sequence Number and/or time stamp, or other
   implementation specific details.

   The receiver of a Heartbeat message does not process this field as it
   is only of significance to the sender.  The receiver echoes the
   content of the Heartbeat Data in a BEAT ACK message.

It should say:

   The receiver of a Heartbeat message echoes the content of the
   Heartbeat Data field contained therein without further processing
   in the Heartbeat Data field of the Heartbeat Ack message.

Notes:

Apparently, the quoted text has been copied from 3.3.2.5 without
performing the appropriate rewording to accommodate the context
of 3.3.2.6 (BEAT ACK message).

RFC 3339, "Date and Time on the Internet: Timestamps", July 2002

Source of RFC: impp (app)

Errata ID: 5624
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Graham Klyne
Date Reported: 2019-02-06
Held for Document Update by: Orie Steele
Date Held: 2024-03-29

Section 5.6 says:

The following profile of ISO 8601 [ISO8601] dates SHOULD be used in
new protocols on the Internet.  This is specified using the syntax
description notation defined in [ABNF].

It should say:

The following profile of ISO 8601 [ISO8601] dates SHOULD be used in
new protocols on the Internet.  This is specified using the syntax
description notation defined in [ABNF].

The syntax production 'full-time' is intended for use in protocols 
that wish to convey precise timestamps (e.g. for logging or ordering 
of events).  Other productions (e.g. 'full-date', 'full-time', 
'partial-time' may be referenced by applications that have different 
requirements.

Notes:

There has been some misunderstanding of the intended scope of RFC3339; e.g. see [1]

The added paragraph clarifies the intent that RFC3339 definitions can be used by applications that don't need to convey a full date+time value.

[1] https://stackoverflow.com/a/522281/324122

Errata ID: 6533
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Juli Mallett
Date Reported: 2021-04-13
Held for Document Update by: RFC Editor
Date Held: 2024-02-16

The Table of Contents says:

   Appendix D. Leap Seconds ..............................,... 15

It should say:

   Appendix D. Leap Seconds .................................. 15

Notes:

comma to period

RFC 3344, "IP Mobility Support for IPv4", August 2002

Note: This RFC has been obsoleted by RFC 5944

Note: This RFC has been updated by RFC 4636, RFC 4721

Source of RFC: mobileip (int)

Errata ID: 4629
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2016-02-26
Held for Document Update by: Brian Haberman
Date Held: 2016-03-01

Section 2.1 says:

   If sent periodically, the nominal interval at which Agent
   Advertisements are sent SHOULD be no longer than 1/3 of the
   advertisement Lifetime given in the ICMP header.  This interval MAY
   be shorter than 1/3 the advertised Lifetime.  This allows a mobile
   node to miss three successive advertisements before deleting the
   agent from its list of valid agents.  The actual transmission time
   for each advertisement SHOULD be slightly randomized [10] in order to
   avoid synchronization and subsequent collisions with other Agent

   Advertisements that may be sent by other agents (or with other Router
   Advertisements sent by other routers).  Note that this field has no
   relation to the "Registration Lifetime" field within the Mobility
   Agent Advertisement Extension defined below.

It should say:

   If sent periodically, the nominal interval at which Agent
   Advertisements are sent SHOULD be no longer than 1/3 of the
   advertisement Lifetime given in the ICMP header.  This interval MAY
   be shorter than 1/3 the advertised Lifetime.  This allows a mobile
   node to miss three successive advertisements before deleting the
   agent from its list of valid agents.  The actual transmission time
   for each advertisement SHOULD be slightly randomized [10] in order to
   avoid synchronization and subsequent collisions with other Agent
   Advertisements that may be sent by other agents (or with other Router
   Advertisements sent by other routers).  Note that this field has no
   relation to the "Registration Lifetime" field within the Mobility
   Agent Advertisement Extension defined below.

Notes:

Excessive empty string.

RFC 3359, "Reserved Type, Length and Value (TLV) Codepoints in Intermediate System to Intermediate System", August 2002

Source of RFC: isis (rtg)

Errata ID: 1544
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-10-08
Held for Document Update by: Stewart Bryant

Section Abstract says:

|                             ...   This document summarizes all Table,
  Length and Value (TLV) codepoints [...]
                                                                 ^^^^^

It should say:

|                             ...   This document summarizes all Type,
  Length and Value (TLV) codepoints [...]
                                                                 ^^^^

Notes:

Rationale: wrong acronym expansion

If accepted, please update the RFC's Abstract in the full RFC index.

RFC 3370, "Cryptographic Message Syntax (CMS) Algorithms", August 2002

Note: This RFC has been updated by RFC 5754, RFC 8702

Source of RFC: smime (sec)

Errata ID: 1840
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2009-08-25
Held for Document Update by: Sean Turner

Section 8 says:

   [PKCS#1]    Kaliski, B, "PKCS #1: RSA Encryption, Version 2.0", RFC
               2437, October, 1998.

It should say:

   [PKCS#1]   Kaliski, B., "PKCS #1: RSA Encryption, Version 1.5.",
              RFC 2313, March 1998.

RFC 3372, "Session Initiation Protocol for Telephones (SIP-T): Context and Architectures", September 2002

Source of RFC: sipping (rai)

Errata ID: 4719
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Victor Gabriel Lopez Loyda
Date Reported: 2016-06-24
Held for Document Update by: Ben Campbell
Date Held: 2016-07-27

Throughout the document, when it says:

   In Figure 2 a VoIP cloud serves as a transit network for telephone
   calls originating in a pair of LECs, where SIP is employed as the
   VoIP protocol used to set up and tear down these VoIP calls.

It should say:

   In Figure 1 a VoIP cloud serves as a transit network for telephone
   calls originating in a pair of LECs, where SIP is employed as the
   VoIP protocol used to set up and tear down these VoIP calls.

Notes:

References to Figure 2; should refer to Figure 1 instead as Figure 2 depicts a different scenario.

RFC 3376, "Internet Group Management Protocol, Version 3", October 2002

Note: This RFC has been updated by RFC 4604

Source of RFC: idmr (rtg)

Errata ID: 4375
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Yechiel Rosengarten
Date Reported: 2015-05-26
Held for Document Update by: Alvaro Retana
Date Held: 2016-02-16

Section 8.13 says:

8.12. Older Version Querier Present Timeout

   The Older Version Querier Interval is the time-out for transitioning
   a host back to IGMPv3 mode once an older version query is heard.
   When an older version query is received, hosts set their Older
   Version Querier Present Timer to Older Version Querier Interval.

   This value MUST be ((the Robustness Variable) times (the Query
   Interval in the last Query received)) plus (one Query Response
   Interval).

It should say:

8.12. Older Version Querier Present Timeout

   The Older Version Querier Interval is the time-out for transitioning
   a host back to IGMPv3 mode once an older version query is heard.
   When an older version query is received, hosts set their Older
   Version Querier Present Timer to Older Version Querier Interval.

   This value MUST be ((the Robustness Variable) times (the Query
   Interval )) plus (one Query Response Interval in the last Query 
   received).

Notes:

The last query received is older version query.
As such - it does not include query interval.
It looks like it should be operator responsibility to configure identical robustness variable and query interval values network-wide for supporting older versions.

=== Alvaro Retana ===

The pim WG was consulted on the proposed text of this errata, but no clear direction was determined. In fact, no significant discussion took place.

Given that this issue doesn't seem to be causing a problem that the WG wants to address wight away, I'm disposing of this errata as "Held for Document Update". If this RFC is updated the WG must then address the issue.

https://mailarchive.ietf.org/arch/msg/pim/s9dMx_O3cFUyn38CHj81yw4Wp2o

Errata ID: 6725
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Nasir Ahmed
Date Reported: 2021-10-27
Held for Document Update by: Alvaro Retana
Date Held: 2022-01-31

Section 8.4 says:

8.4. Group Membership Interval

   The Group Membership Interval is the amount of time that must pass
   before a multicast router decides there are no more members of a
   group or a particular source on a network.

   This value MUST be ((the Robustness Variable) times (the Query
   Interval)) plus (one Query Response Interval).

It should say:

8.4. Group Membership Interval

   The Group Membership Interval is the amount of time that must pass
   before a multicast router decides there are no more members of a
   group or a particular source on a network.

   This value MUST be ((the Robustness Variable) times (the Query
   Interval)) plus (2 * Query Response Interval).

Notes:

A router resuming querier role (when current querier dies off) waits for other querier timer value to be expired. This value is ((the Robustness Variable) times (the Query Interval)) plus (one half of one Query Response Interval). This value by default comes as (2 * 125 + 10/2) = 255. Whereas GMI comes as (2 * 125 + 10) = 260. A group learnt with this value will have its group timer value set to expire from anywhere from 260 + 10 (min 260, max 270 due to random response from host in the interval of max response time delay after a query). Now a new router resuming a querier role will generate query after 255 sec. At this point of time the group timer left will be in the range of (260 - 255) 5sec to (270 - 255 ) 15sec. Since the query response can come anywhere between 10sec, Groups whose timer value is less will expire and will result in traffic drop. Therefore it is recommended to increase the default GMI value by one extra Query Response Interval. That is - ((the Robustness Variable) times (the Query
Interval)) plus (2 * Query Response Interval).

====
AD Notes:

I am changing the status of this report to Held for Document Update. The WG is discussing what the best way to address it is: https://mailarchive.ietf.org/arch/msg/pim/Im8go1fjyVad7jyhGg1bgnW93qM/

Errata ID: 5562
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Wim De Smet
Date Reported: 2018-11-26
Held for Document Update by: Alvaro Retana
Date Held: 2019-02-08

Section 6.2.1 says:

   When a router filter-mode for a group is EXCLUDE, the source record
   list contains two types of sources.  The first type is the set which
   represents conflicts in the desired reception state; this set must be
   forwarded by some router on the network.  The second type is the set
   of sources which hosts have requested to not be forwarded.  Appendix
   A describes the reasons for keeping this second set when in EXCLUDE
   mode.

It should say:

[see note]

Notes:

Appendix A.3 contains the following:
One of the ways to accomplish this is for routers to keep track of
all sources desired by hosts that are in INCLUDE mode even though the
router itself is in EXCLUDE mode.

Appendix A.3 makes clear that in EXCLUDE mode we need to keep track of the set of hosts that *are* desired (i.e. set A in section 6.4 or the "first type" in this paragraph). The second set (set B in section 6.4) is the set that will be reported to upstream routers, it is not the set which is needed for smooth switching to INCLUDE mode (the behavior described in appendix A). I believe that the intended description may have been "Appendix A describes the reasons for keeping two different sets when in EXCLUDE mode". At the very least, it appears to be set A (the "first set") which is intended in appendix A.

RFC 3382, "Internet Printing Protocol (IPP): The 'collection' attribute syntax", September 2002

Note: This RFC has been obsoleted by RFC 8010, RFC 8011

Source of RFC: ipp (app)

Errata ID: 3019
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Sweet
Date Reported: 2011-11-10
Held for Document Update by: Peter Saint-Andre

Section 7.4 says:

   The overall structure of the two collection values can be pictorially
   represented as:

      "media-col" =
        {  "media-color" =  'blue';
           "media-size" =
           {    "x-dimension" = 6;
                "y-dimension" = 4
             }
        },

   The full encoding is in table 5.  A simplified view of the encoding
   looks like this:

           Table 4 - Overview Encoding of "media-col" collection

      Tag Value             Name                  Value

      begCollection         media-col             ""

      memberAttrName        ""                    media-color

      keyword               ""                    blue

      memberAttrName        ""                    media-size

      begCollection         ""                    ""

      memberAttrName        ""                    x-dimension

      integer               ""                    6

      memberAttrName        ""                    y-dimension

      integer               ""                    4

      endCollection         ""                    ""

      endCollection         ""                    ""


           Table 5 - Example Encoding of "media-col" collection

      Octets       Symbolic Value  Protocol   comments
                                   field

      0x34         begCollection   value-tag  beginning of the "media-
                                              col" collection attribute

      0x0009                       name-      length of (collection)
                                   length     attribute name

      media-col    media-col       name       name of (collection)
                                              attribute

      0x0000                       value-     defined to be 0 for this
                                   length     type

                                              no value (since value-
                                              length was 0)

      0x4A         memberAttrName  value-tag  starts a new member
                                              attribute: "media-color"

      0x0000                       name-      defined to be 0 for this
                                   length     type, so part of 1setOf

                                              no name (since name-length
                                              was 0)

      0x000B                       value-     length of "media-color"
                                   length     keyword

      media-color  media-color     value      value is name of 1st
                                              member attribute


      0x44         keyword type    value-tag  keyword type

      0x0000                       name-      0 indicates 1setOf
                                   length

                                              no name (since name-length
                                              was 0)


      Octets       Symbolic Value  Protocol   comments
                                   field

      0x0004                       value-
                                   length

      blue         blue            value      value of 1st member
                                              attribute


      0x4A         memberAttrName  value-tag  starts a new member
                                              attribute: "media-size"

      0x0000                       name-      defined to be 0 for this
                                   length     type, so part of 1setOf

                                              no name (since name-length
                                              was 0)

      0x000A                       value-     length of "media-size"
                                   length     keyword

      media-size   media-size      value      Name of 2nd member
                                              attribute

      0x34         begCollection   value-tag  Beginning of the "media-
                                              size" collection attribute
                                              which is a sub-collection

      0x0000                       name-      0 indicates 1setOf
                                   length

                                              no name (since name-length
                                              was 0)

      0x0000                       value-     collection attribute names
                                   length     have no value

                                              no value (since value-
                                              length was 0)

      0x4A         memberAttrName  value-tag  starts a new member
                                              attribute: "x-dimension"



      Octets       Symbolic Value  Protocol   comments
                                   field

      0x0000                       name-      defined to be 0 for this
                                   length     type, so part of 1setOf

                                              no name (since name-length
                                              was 0)

      0x000B                       value-     length of "x-dimension"
                                   length     keyword

      x-dimension  x-dimension     value      name of  1st sub-
                                              collection member
                                              attribute


      0x21         integer type    value-tag  attribute type

      0x0000                       name-      0 indicates 1setOf
                                   length

                                              no name (since name-length
                                              was 0)

      0x0004                       value-     length of an integer = 4
                                   length

      0x0006                       value      value of  1st sub-
                                              collection member
                                              attribute

      0x4A         memberAttrName  value-tag  starts a new member
                                              attribute: "y-dimension"

      0x0000                       name-      defined to be 0 for this
                                   length     type, so part of 1setOf

                                              no name (since name-length
                                              was 0)

      0x000B                       value-     length of the "y-
                                   length     dimension" keyword


      Octets       Symbolic Value  Protocol   comments
                                   field

      y-dimension  y-dimension     value      name of  2nd sub-
                                              collection member
                                              attribute

      0x21         integer type    value-tag  attribute type

      0x0000                       name-      0 indicates 1setOf
                                   length

                                              no name (since name-length
                                              was 0)

      0x0004                       value-     length of an integer = 4
                                   length

      0x0004                       value      value of  2nd sub-
                                              collection member
                                              attribute

      0x37         endCollection   value-tag  end of the sub-collection

      0x0000                       name-      defined to be 0 for this
                                   length     type, so part of 1setOf

                                              no name (since name-length
                                              was 0)

      0x0000                       value-     defined to be 0 for this
                                   length     type

                                              no value (since value-
                                              length was 0)

      0x37         endCollection   value-tag  end of the 1st collection
                                              value in 1setOf

      0x0000                       name-      defined to be 0 for this
                                   length     type, so part of 1setOf


      Octets       Symbolic Value  Protocol   comments
                                   field

                                              no name (since name-length
                                              was 0)

      0x0000                       value-     defined to be 0 for this
                                   length     type

                                              no value (since value-
                                              length was 0)

It should say:

   The overall structure of the two collection values can be pictorially
   represented as:

      "media-col" =
        {  "media-color" =  'blue';
           "media-size" =
           {    "x-dimension" = 15240;
                "y-dimension" = 10160
             }
        },

   The full encoding is in table 5.  A simplified view of the encoding
   looks like this:

           Table 4 - Overview Encoding of "media-col" collection

      Tag Value             Name                  Value

      begCollection         media-col             ""

      memberAttrName        ""                    media-color

      keyword               ""                    blue

      memberAttrName        ""                    media-size

      begCollection         ""                    ""

      memberAttrName        ""                    x-dimension

      integer               ""                    15240

      memberAttrName        ""                    y-dimension

      integer               ""                    10160

      endCollection         ""                    ""

      endCollection         ""                    ""


           Table 5 - Example Encoding of "media-col" collection

      Octets       Symbolic Value  Protocol   comments
                                   field

      0x34         begCollection   value-tag  beginning of the "media-
                                              col" collection attribute

      0x0009                       name-      length of (collection)
                                   length     attribute name

      media-col    media-col       name       name of (collection)
                                              attribute

      0x0000                       value-     defined to be 0 for this
                                   length     type

                                              no value (since value-
                                              length was 0)

      0x4A         memberAttrName  value-tag  starts a new member
                                              attribute: "media-color"

      0x0000                       name-      defined to be 0 for this
                                   length     type, so part of 1setOf

                                              no name (since name-length
                                              was 0)

      0x000B                       value-     length of "media-color"
                                   length     keyword

      media-color  media-color     value      value is name of 1st
                                              member attribute


      0x44         keyword type    value-tag  keyword type

      0x0000                       name-      0 indicates 1setOf
                                   length

                                              no name (since name-length
                                              was 0)


      Octets       Symbolic Value  Protocol   comments
                                   field

      0x0004                       value-
                                   length

      blue         blue            value      value of 1st member
                                              attribute


      0x4A         memberAttrName  value-tag  starts a new member
                                              attribute: "media-size"

      0x0000                       name-      defined to be 0 for this
                                   length     type, so part of 1setOf

                                              no name (since name-length
                                              was 0)

      0x000A                       value-     length of "media-size"
                                   length     keyword

      media-size   media-size      value      Name of 2nd member
                                              attribute

      0x34         begCollection   value-tag  Beginning of the "media-
                                              size" collection attribute
                                              which is a sub-collection

      0x0000                       name-      0 indicates 1setOf
                                   length

                                              no name (since name-length
                                              was 0)

      0x0000                       value-     collection attribute names
                                   length     have no value

                                              no value (since value-
                                              length was 0)

      0x4A         memberAttrName  value-tag  starts a new member
                                              attribute: "x-dimension"



      Octets       Symbolic Value  Protocol   comments
                                   field

      0x0000                       name-      defined to be 0 for this
                                   length     type, so part of 1setOf

                                              no name (since name-length
                                              was 0)

      0x000B                       value-     length of "x-dimension"
                                   length     keyword

      x-dimension  x-dimension     value      name of  1st sub-
                                              collection member
                                              attribute


      0x21         integer type    value-tag  attribute type

      0x0000                       name-      0 indicates 1setOf
                                   length

                                              no name (since name-length
                                              was 0)

      0x0004                       value-     length of an integer = 4
                                   length

      0x3b88                       value      value of  1st sub-
                                              collection member
                                              attribute

      0x4A         memberAttrName  value-tag  starts a new member
                                              attribute: "y-dimension"

      0x0000                       name-      defined to be 0 for this
                                   length     type, so part of 1setOf

                                              no name (since name-length
                                              was 0)

      0x000B                       value-     length of the "y-
                                   length     dimension" keyword


      Octets       Symbolic Value  Protocol   comments
                                   field

      y-dimension  y-dimension     value      name of  2nd sub-
                                              collection member
                                              attribute

      0x21         integer type    value-tag  attribute type

      0x0000                       name-      0 indicates 1setOf
                                   length

                                              no name (since name-length
                                              was 0)

      0x0004                       value-     length of an integer = 4
                                   length

      0x27b0                       value      value of  2nd sub-
                                              collection member
                                              attribute

      0x37         endCollection   value-tag  end of the sub-collection

      0x0000                       name-      defined to be 0 for this
                                   length     type, so part of 1setOf

                                              no name (since name-length
                                              was 0)

      0x0000                       value-     defined to be 0 for this
                                   length     type

                                              no value (since value-
                                              length was 0)

      0x37         endCollection   value-tag  end of the 1st collection
                                              value in 1setOf

      0x0000                       name-      defined to be 0 for this
                                   length     type, so part of 1setOf


      Octets       Symbolic Value  Protocol   comments
                                   field

                                              no name (since name-length
                                              was 0)

      0x0000                       value-     defined to be 0 for this
                                   length     type

                                              no value (since value-
                                              length was 0)

Notes:

The "media-col" attribute was defined in PWG 5100.3 (ftp://ftp.pwg.org/pub/pwg/candidates/cs-ippprodprint10-20010212-5100.3.pdf) with units consistent with RFC 3805 - namely hundredths of millimeters. However, since the example in RFC 3382 was for the same attribute, many implementers have made mistakes by using the RFC 3382 example information instead of the normative definitions in PWG 5100.3.

These changes make the example in RFC 3382 match the normative definition in PWG 5100.3.

Errata ID: 3020
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Sweet
Date Reported: 2011-11-10
Held for Document Update by: Peter Saint-Andre

Section 5 says:

5 Example definition of a collection attribute

   In some printing environments, it is desirable to allow the client to
   select the media by its properties, e.g., weight, color, size, etc.,
   instead of by name.  In IPP/1.1 (see [RFC2911]), the "media (type3
   keyword | name) Job Template attribute allows selection by name.  It
   is tempting to extend the "media" attribute syntax to include
   "collection", but then existing clients could not understand default
   or supported media values that use the collection value.  To preserve
   interoperability, a new attribute MUST BE added, e.g., "media-col
   (collection)".  The following subsections contain a sample definition
   of a simplified "media-col" attribute.  The definition follows the
   rules in section 3.

It should say:

5 Example definition of a collection attribute

   In some printing environments, it is desirable to allow the client to
   select the media by its properties, e.g., weight, color, size, etc.,
   instead of by name.  In IPP/1.1 (see [RFC2911]), the "media (type3
   keyword | name) Job Template attribute allows selection by name.  It
   is tempting to extend the "media" attribute syntax to include
   "collection", but then existing clients could not understand default
   or supported media values that use the collection value.  To preserve
   interoperability, a new attribute MUST BE added, e.g., "media-col
   (collection)".  The following subsections contain a sample definition
   of a simplified "media-col" attribute.  The definition follows the
   rules in section 3. Note: The "media-col" attribute is normatively defined
   in the IPP Production Printing Attributes - Set 1 [PWG5100.3].

Notes:

Add normative reference to PWG 5100.3 which defines "media-col".

Errata ID: 3021
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Sweet
Date Reported: 2011-11-10
Held for Document Update by: Peter Saint-Andre

Section 5.1.2.1 says:

5.1.2.1  x-dimension (integer(0:MAX))

   This attribute identifies the width of the media in inch units along
   the X axis.

It should say:

5.1.2.1  x-dimension (integer(0:MAX))

   This attribute identifies the width of the media in hundredths of millimeters along
   the X axis.

Notes:

The units for x-dimension are normatively defined as hundredths of millimeters by PWG 5100.3 to be consistent with RFC 3805.

Errata ID: 3022
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Sweet
Date Reported: 2011-11-10
Held for Document Update by: Peter Saint-Andre

Section 5.1.2.2 says:

5.1.2.2  y-dimension (integer(0:MAX))

   This attribute identifies the height of the media in inch units along
   the Y axis.

It should say:

5.1.2.2  y-dimension (integer(0:MAX))

   This attribute identifies the height of the media in hundredths of millimeters along
   the Y axis.

Notes:

y-dimension is normatively defined as hundredths of millimeters by PWG 5100.3 to match RFC 3805.

Errata ID: 3024
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Sweet
Date Reported: 2011-11-10
Held for Document Update by: Peter Saint-Andre

Section Appendix A says:

Appendix A: Encoding Example of a Simple Collection (Informative)

   The overall structure of the collection value can be pictorially
   represented as:

      "media-size" =
        {  "x-dimension" = 6;
           "y-dimension" = 4
        }

   A simplified view of the encoding would look like this:

             Table 6 - Overview Encoding of simple collection

      Tag Value             Name                  Value

      begCollection         media-size            ""

      memberAttrName        ""                    x-dimension

      integer               ""                    6

      memberAttrName        ""                    y-dimension

      integer               ""                    4

      endCollection         ""                    ""

      Note: "" represents a name or value whose length is 0.

              Table 7 - Example Encoding of simple collection

      Octets       Symbolic Value  Protocol   comments
                                   field

      0x34         begCollection   value-tag  beginning of the "media-
                                              size" collection attribute

      0x000A                       name-      length of (collection)
                                   length     attribute name

      media-size   media-size      name       name of (collection)
                                              attribute








deBry, et. al.              Standards Track                    [Page 22]
 
RFC 3382         IPP: The 'collection' attribute syntax   September 2002


      Octets       Symbolic Value  Protocol   comments
                                   field

      0x0000                       value-     defined to be 0 for this
                                   length     type

                                              no value (since value-
                                              length was 0)

      0x4A         memberAttrName  value-tag  starts member attribute:
                                              "x-dimension"

      0x0000                       name-      defined to be 0 for this
                                   length     type, so part of 1setOf

                                              no name (since name-length
                                              was 0)

      0x000B                       value-     length of "x-dimension"
                                   length     keyword

      x-dimension  x-dimension     value      name of  1st collection
                                              member attribute


      0x21         integer type    value-tag  attribute type

      0x0000                       name-      0 indicates 1setOf
                                   length

                                              no name (since name-length
                                              was 0)

      0x0004                       value-     length of an integer = 4
                                   length

      0x0006                       value      value of  1st collection
                                              member attribute

      0x4A         memberAttrName  value-tag  starts a new member
                                              attribute: "y-dimension"

      0x0000                       name-      defined to be 0 for this
                                   length     type, so part of 1setOf

                                              no name (since name-length
                                              was 0)




deBry, et. al.              Standards Track                    [Page 23]
 
RFC 3382         IPP: The 'collection' attribute syntax   September 2002


      Octets       Symbolic Value  Protocol   comments
                                   field

      0x000B                       value-     length of the "y-
                                   length     dimension" keyword

      y-dimension  y-dimension     value      name of  2nd collection
                                              member attribute

      0x21         integer type    value-tag  attribute type

      0x0000                       name-      0 indicates 1setOf for
                                   length     media-size

                                              no name (since name-length
                                              was 0)

      0x0004                       value-     length of an integer = 4
                                   length

      0x0004                       value      value of  2nd collection
                                              member attribute

      0x37         endCollection   value-tag  end of the collection

      0x0000                       name-      defined to be 0 for this
                                   length     type, so part of 1setOf

                                              no name (since name-length
                                              was 0)

      0x0000                       value-     defined to be 0 for this
                                   length     type

                                              no value (since value-
                                              length was 0)

It should say:

Appendix A: Encoding Example of a Simple Collection (Informative)

   The overall structure of the collection value can be pictorially
   represented as:

      "media-size" =
        {  "x-dimension" = 15240;
           "y-dimension" = 10160
        }

   A simplified view of the encoding would look like this:

             Table 6 - Overview Encoding of simple collection

      Tag Value             Name                  Value

      begCollection         media-size            ""

      memberAttrName        ""                    x-dimension

      integer               ""                    15240

      memberAttrName        ""                    y-dimension

      integer               ""                    10160

      endCollection         ""                    ""

      Note: "" represents a name or value whose length is 0.

              Table 7 - Example Encoding of simple collection

      Octets       Symbolic Value  Protocol   comments
                                   field

      0x34         begCollection   value-tag  beginning of the "media-
                                              size" collection attribute

      0x000A                       name-      length of (collection)
                                   length     attribute name

      media-size   media-size      name       name of (collection)
                                              attribute








deBry, et. al.              Standards Track                    [Page 22]
 
RFC 3382         IPP: The 'collection' attribute syntax   September 2002


      Octets       Symbolic Value  Protocol   comments
                                   field

      0x0000                       value-     defined to be 0 for this
                                   length     type

                                              no value (since value-
                                              length was 0)

      0x4A         memberAttrName  value-tag  starts member attribute:
                                              "x-dimension"

      0x0000                       name-      defined to be 0 for this
                                   length     type, so part of 1setOf

                                              no name (since name-length
                                              was 0)

      0x000B                       value-     length of "x-dimension"
                                   length     keyword

      x-dimension  x-dimension     value      name of  1st collection
                                              member attribute


      0x21         integer type    value-tag  attribute type

      0x0000                       name-      0 indicates 1setOf
                                   length

                                              no name (since name-length
                                              was 0)

      0x0004                       value-     length of an integer = 4
                                   length

      0x3b88                       value      value of  1st collection
                                              member attribute

      0x4A         memberAttrName  value-tag  starts a new member
                                              attribute: "y-dimension"

      0x0000                       name-      defined to be 0 for this
                                   length     type, so part of 1setOf

                                              no name (since name-length
                                              was 0)




deBry, et. al.              Standards Track                    [Page 23]
 
RFC 3382         IPP: The 'collection' attribute syntax   September 2002


      Octets       Symbolic Value  Protocol   comments
                                   field

      0x000B                       value-     length of the "y-
                                   length     dimension" keyword

      y-dimension  y-dimension     value      name of  2nd collection
                                              member attribute

      0x21         integer type    value-tag  attribute type

      0x0000                       name-      0 indicates 1setOf for
                                   length     media-size

                                              no name (since name-length
                                              was 0)

      0x0004                       value-     length of an integer = 4
                                   length

      0x27b0                       value      value of  2nd collection
                                              member attribute

      0x37         endCollection   value-tag  end of the collection

      0x0000                       name-      defined to be 0 for this
                                   length     type, so part of 1setOf

                                              no name (since name-length
                                              was 0)

      0x0000                       value-     defined to be 0 for this
                                   length     type

                                              no value (since value-
                                              length was 0)

Notes:

Fix examples to use correct units, per PWG 5100.3 definition.

Errata ID: 3023
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Sweet
Date Reported: 2011-11-10
Held for Document Update by: Peter Saint-Andre

Section 12.1 says:

12.1 Normative References

It should say:

12.1 Normative References

[PWG5100.3]  K. Ocke, T. Hastings, "Internet Printing Protocol (IPP):
             Production Printing Attributes - Set 1", 
             ftp://ftp.pwg.org/pub/pwg/candidates/
             cs-ippprodprint10-20010212-5100.3.pdf, February 2001.

Notes:

Adding normative reference to PWG 5100.3 for media-col.

Errata ID: 3025
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Sweet
Date Reported: 2011-11-10
Held for Document Update by: Peter Saint-Andre

Section Appendix B says:

Appendix B: Encoding Example of 1setOf Collection (Informative)

   The overall structure of the collection value can be pictorially
   represented as:

      "media-size-supported" =
        {  "x-dimension" = 6;
           "y-dimension" = 4
        },
        {  "x-dimension" = 3;
           "y-dimension" = 5
        };

   A simplified view of the encoding would look like this:

             Table 8 - Overview Encoding of 1setOf collection

      Tag Value              Name                 Value

      begCollection          media-size-          ""
                             supported

      memberAttrName         ""                   x-dimension

      integer                ""                   6

      memberAttrName         ""                   y-dimension

      integer                ""                   4

      endCollection          ""                   ""

      begCollection          ""                   ""

      memberAttrName         ""                   x-dimension

      integer                ""                   3

      memberAttrName         ""                   y-dimension

      integer                ""                   5

      endCollection          ""                   ""








deBry, et. al.              Standards Track                    [Page 25]
 
RFC 3382         IPP: The 'collection' attribute syntax   September 2002


              Table 9 - Example Encoding of 1setOf collection

      Octets       Symbolic Value  Protocol   comments
                                   field

      0x34         begCollection   value-tag  beginning of the "media-
                                              size-supported (1setOf
                                              collection" attribute

      0x00014                      name-      length of (collection)
                                   length     attribute name

      media-size-  media-size-     name       name of (collection)
      supported    supported                  attribute

      0x0000                       value-     defined to be 0 for this
                                   length     type

                                              no value (since value-
                                              length was 0)

      0x4A         memberAttrName  value-tag  starts member attribute:
                                              "x-dimension"

      0x0000                       name-      defined to be 0 for this
                                   length     type, so part of 1setOf

                                              no name (since name-length
                                              was 0)

      0x000B                       value-     length of "x-dimension"
                                   length     keyword

      x-dimension  x-dimension     value      name of  1st collection
                                              member attribute

      0x21         integer type    value-tag  attribute type

      0x0000                       name-      0 indicates 1setOf
                                   length

                                              no name (since name-length
                                              was 0)








deBry, et. al.              Standards Track                    [Page 26]
 
RFC 3382         IPP: The 'collection' attribute syntax   September 2002


      Octets       Symbolic Value  Protocol   comments
                                   field

      0x0004                       value-     length of an integer = 4
                                   length

      0x0006                       value      value of  1st collection
                                              member attribute

      0x4A         memberAttrName  value-tag  starts member attribute:
                                              "y-dimension"

      0x0000                       name-      defined to be 0 for this
                                   length     type, so part of 1setOf

                                              no name (since name-length
                                              was 0)

      0x000B                       value-     length of the "y-
                                   length     dimension" keyword

      y-dimension  y-dimension     value      name of  2nd collection
                                              member attribute

      0x21         integer type    value-tag  attribute type

      0x0000                       name-      0 indicates 1setOf
                                   length

                                              no name (since name-length
                                              was 0)

      0x0004                       value-     length of an integer = 4
                                   length

      0x0004                       value      value of  2nd collection
                                              member attribute

      0x37         endCollection   value-tag  end of the collection

      0x0000                       name-      defined to be 0 for this
                                   length     type, so part of 1setOf

                                              no name (since name-length
                                              was 0)






deBry, et. al.              Standards Track                    [Page 27]
 
RFC 3382         IPP: The 'collection' attribute syntax   September 2002


      Octets       Symbolic Value  Protocol   comments
                                   field

      0x0000                       value-     defined to be 0 for this
                                   length     type

                                              no value (since value-
                                              length was 0)

      0x34         begCollection   value-tag  beginning of the 2nd
                                              member of the 1setOf
                                              "sizes-avail " collection
                                              attribute

      0x0000                       name-      Zero length name indicates
                                   length     this is member of previous
                                              attribute

                                   name       no name (since name-length
                                              was 0)

      0x0000                       value-     defined to be 0 for this
                                   length     type

                                              no value (since value-
                                              length was 0)

      0x4A         memberAttrName  value-tag  starts member attribute:
                                              "x-dimension"

      0x0000                       name-      defined to be 0 for this
                                   length     type, so part of 1setOf

                                              no name (since name-length
                                              was 0)

      0x000B                       value-     length of "x-dimension"
                                   length     keyword

      x-dimension  x-dimension     value      name of  1st collection
                                              member attribute

      0x21         integer type    value-tag  attribute type








deBry, et. al.              Standards Track                    [Page 28]
 
RFC 3382         IPP: The 'collection' attribute syntax   September 2002


      Octets       Symbolic Value  Protocol   comments
                                   field

      0x0000                       name-      0 indicates 1setOf
                                   length

                                              no name (since name-length
                                              was 0)

      0x0004                       value-     length of an integer = 4
                                   length

      0x0003                       value      value of  1st collection
                                              member attribute

      0x4A         memberAttrName  value-tag  starts member attribute:
                                              "y-dimension"

      0x0000                       name-      defined to be 0 for this
                                   length     type, so part of 1setOf

                                              no name (since name-length
                                              was 0)

      0x000B                       value-     length of the "y-
                                   length     dimension" keyword

      y-dimension  y-dimension     value      name of  2nd collection
                                              member attribute

      0x21         integer type    value-tag  attribute type

      0x0000                       name-      0 indicates 1setOf
                                   length

                                              no name (since name-length
                                              was 0)

      0x0004                       value-     length of an integer = 4
                                   length

      0x0005                       value      value of  2nd collection
                                              member attribute








deBry, et. al.              Standards Track                    [Page 29]
 
RFC 3382         IPP: The 'collection' attribute syntax   September 2002


      Octets       Symbolic Value  Protocol   comments
                                   field

      0x37         endCollection   value-tag  end of the 1setOf
                                              collection value

      0x0000                       name-      defined to be 0 for this
                                   length     type, so part of 1setOf

                                              no name (since name-length
                                              was 0)

      0x0000                       value-     defined to be 0 for this
                                   length     type

                                              no value (since value-
                                              length was 0)

It should say:

Appendix B: Encoding Example of 1setOf Collection (Informative)

   The overall structure of the collection value can be pictorially
   represented as:

      "media-size-supported" =
        {  "x-dimension" = 15240;
           "y-dimension" = 10160
        },
        {  "x-dimension" = 7620;
           "y-dimension" = 12700
        };

   A simplified view of the encoding would look like this:

             Table 8 - Overview Encoding of 1setOf collection

      Tag Value              Name                 Value

      begCollection          media-size-          ""
                             supported

      memberAttrName         ""                   x-dimension

      integer                ""                   15240

      memberAttrName         ""                   y-dimension

      integer                ""                   10160

      endCollection          ""                   ""

      begCollection          ""                   ""

      memberAttrName         ""                   x-dimension

      integer                ""                   7620

      memberAttrName         ""                   y-dimension

      integer                ""                   12700

      endCollection          ""                   ""








deBry, et. al.              Standards Track                    [Page 25]
 
RFC 3382         IPP: The 'collection' attribute syntax   September 2002


              Table 9 - Example Encoding of 1setOf collection

      Octets       Symbolic Value  Protocol   comments
                                   field

      0x34         begCollection   value-tag  beginning of the "media-
                                              size-supported (1setOf
                                              collection" attribute

      0x00014                      name-      length of (collection)
                                   length     attribute name

      media-size-  media-size-     name       name of (collection)
      supported    supported                  attribute

      0x0000                       value-     defined to be 0 for this
                                   length     type

                                              no value (since value-
                                              length was 0)

      0x4A         memberAttrName  value-tag  starts member attribute:
                                              "x-dimension"

      0x0000                       name-      defined to be 0 for this
                                   length     type, so part of 1setOf

                                              no name (since name-length
                                              was 0)

      0x000B                       value-     length of "x-dimension"
                                   length     keyword

      x-dimension  x-dimension     value      name of  1st collection
                                              member attribute

      0x21         integer type    value-tag  attribute type

      0x0000                       name-      0 indicates 1setOf
                                   length

                                              no name (since name-length
                                              was 0)








deBry, et. al.              Standards Track                    [Page 26]
 
RFC 3382         IPP: The 'collection' attribute syntax   September 2002


      Octets       Symbolic Value  Protocol   comments
                                   field

      0x0004                       value-     length of an integer = 4
                                   length

      0x3b88                       value      value of  1st collection
                                              member attribute

      0x4A         memberAttrName  value-tag  starts member attribute:
                                              "y-dimension"

      0x0000                       name-      defined to be 0 for this
                                   length     type, so part of 1setOf

                                              no name (since name-length
                                              was 0)

      0x000B                       value-     length of the "y-
                                   length     dimension" keyword

      y-dimension  y-dimension     value      name of  2nd collection
                                              member attribute

      0x21         integer type    value-tag  attribute type

      0x0000                       name-      0 indicates 1setOf
                                   length

                                              no name (since name-length
                                              was 0)

      0x0004                       value-     length of an integer = 4
                                   length

      0x27b0                       value      value of  2nd collection
                                              member attribute

      0x37         endCollection   value-tag  end of the collection

      0x0000                       name-      defined to be 0 for this
                                   length     type, so part of 1setOf

                                              no name (since name-length
                                              was 0)






deBry, et. al.              Standards Track                    [Page 27]
 
RFC 3382         IPP: The 'collection' attribute syntax   September 2002


      Octets       Symbolic Value  Protocol   comments
                                   field

      0x0000                       value-     defined to be 0 for this
                                   length     type

                                              no value (since value-
                                              length was 0)

      0x34         begCollection   value-tag  beginning of the 2nd
                                              member of the 1setOf
                                              "sizes-avail " collection
                                              attribute

      0x0000                       name-      Zero length name indicates
                                   length     this is member of previous
                                              attribute

                                   name       no name (since name-length
                                              was 0)

      0x0000                       value-     defined to be 0 for this
                                   length     type

                                              no value (since value-
                                              length was 0)

      0x4A         memberAttrName  value-tag  starts member attribute:
                                              "x-dimension"

      0x0000                       name-      defined to be 0 for this
                                   length     type, so part of 1setOf

                                              no name (since name-length
                                              was 0)

      0x000B                       value-     length of "x-dimension"
                                   length     keyword

      x-dimension  x-dimension     value      name of  1st collection
                                              member attribute

      0x21         integer type    value-tag  attribute type








deBry, et. al.              Standards Track                    [Page 28]
 
RFC 3382         IPP: The 'collection' attribute syntax   September 2002


      Octets       Symbolic Value  Protocol   comments
                                   field

      0x0000                       name-      0 indicates 1setOf
                                   length

                                              no name (since name-length
                                              was 0)

      0x0004                       value-     length of an integer = 4
                                   length

      0x1dc4                       value      value of  1st collection
                                              member attribute

      0x4A         memberAttrName  value-tag  starts member attribute:
                                              "y-dimension"

      0x0000                       name-      defined to be 0 for this
                                   length     type, so part of 1setOf

                                              no name (since name-length
                                              was 0)

      0x000B                       value-     length of the "y-
                                   length     dimension" keyword

      y-dimension  y-dimension     value      name of  2nd collection
                                              member attribute

      0x21         integer type    value-tag  attribute type

      0x0000                       name-      0 indicates 1setOf
                                   length

                                              no name (since name-length
                                              was 0)

      0x0004                       value-     length of an integer = 4
                                   length

      0x319c                       value      value of  2nd collection
                                              member attribute








deBry, et. al.              Standards Track                    [Page 29]
 
RFC 3382         IPP: The 'collection' attribute syntax   September 2002


      Octets       Symbolic Value  Protocol   comments
                                   field

      0x37         endCollection   value-tag  end of the 1setOf
                                              collection value

      0x0000                       name-      defined to be 0 for this
                                   length     type, so part of 1setOf

                                              no name (since name-length
                                              was 0)

      0x0000                       value-     defined to be 0 for this
                                   length     type

                                              no value (since value-
                                              length was 0)

Notes:

Update examples to match PWG 5100.3 definition.

RFC 3394, "Advanced Encryption Standard (AES) Key Wrap Algorithm", September 2002

Source of RFC: smime (sec)

Errata ID: 284
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-02-28
Held for Document Update by: Tim Polk

Section 2.1 says:

     P[i]          The ith plaintext key data block
     C[i]          The ith ciphertext data block
     A             The 64-bit integrity check register
     R[i]          An array of 64-bit registers where
                      i = 0, 1, 2, ..., n
     A[t], R[i][t] The contents of registers A and R[i] after encryption
                      step t.

It should say:

     P[i]          The ith (64-bit) plaintext key data block
                   where i = 1, 2, ..., n
     C[i]          The ith (64-bit) ciphertext data block
                   where i = 0, 1, 2, ..., n
     A             The 64-bit integrity check register
     R[i]          An array of 64-bit registers where
                   i = 1, 2, ..., n
    A[t], R[t][i]  The contents of registers A and R[i] after encryption
                   step t.

RFC 3398, "Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping", December 2002

Source of RFC: sipping (rai)

Errata ID: 2580
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Stephen James
Date Reported: 2010-10-19
Held for Document Update by: Gonzalo Camarillo
Date Held: 2011-01-27

Section 8.1.3 says:

Item 6.
The gateway also sends a CANCEL message to the SIP node to
terminate any initiation attempts.

It should say:

Drop this statement.

Section 8.1.3 item 6 should be updated to "The gateway also sends a
CANCEL message to the SIP node to terminate the initiation attempt if
a provisional response has been received."  The situation illustrated
in section 8.1.3 does not distinguish the "provisional response
received" case from the "provisional response not received" case, so
the commentary should cover both cases.  (The specific example
diagrammed shows the "no provisional response received" case.)

A similar change should be made to section 8.1.4 item 7, "The REL will
trigger a CANCEL request to the SIP node if a provisional response has
been received."

A similar change should be made to section 8.1.7 item 7, "Upon receipt
of a REL message before an INVITE final response, the gateway will
send a CANCEL towards the SIP node if a provisional response has been
received.

Notes:

No CANCEL is sent on INVITE transaction timeout. This is per 3261 "If no provisional response has been received, the CANCEL request MUST NOT be sent; rather, the client MUST wait for the arrival of a provisional response before sending the request."

Errata ID: 2161
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Andrew Miller
Date Reported: 2010-04-13
Held for Document Update by: Robert Sparks

Section 8.2.6.1 says:

504 Version Not Supported            127 Interworking (+)

It should say:

505 Version Not Supported            127 Interworking (+)

Notes:

504 appears twice with different text. From the context, it looks like the text in the second entry is correct, and the number is wrong.

Errata ID: 2977
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jeff Dyer
Date Reported: 2011-09-21
Held for Document Update by: Robert Sparks

Section 7.2.4.1 says:

(+) If the cause location is 'user' than the 6xx code could be given 
rather than the 4xx code (i.e., 403 becomes 603)

It should say:

(+) If the cause location is 'user', then the 6xx code could be given 
rather than the 4xx code (i.e., 403 becomes 603)

Notes:

"Than" is used for comparisons. "Then" is used to denote something follows in sequence.

Errata ID: 2980
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Pablo Varela
Date Reported: 2011-09-27
Held for Document Update by: Robert Sparks

Section 7.2 says:

                               +---------+
      +----------------------->|  Idle   |<---------------------+
      |                        +----+----+                      |
      |                             |                           |
      |                             | INVITE/6.2.1              |
      |                             V                           |
      |      T7/6.2.2   +-------------------------+   REL/6.2.4 |
      +<----------------+         Trying          +------------>+
      |                 +-+--------+------+-------+             |
      |    CANCEL/6.2.3 | |        |      |                     |
      +<----------------+ | E.ACM/ | ACM/ | CON/ANM             |
      |                   | 6.2.5  |6.2.6 | 6.2.7               |
      |                   V        |      |                     |
      | T9/6.2.8  +--------------+ |      |                     |
      +<----------+ Not alerting | |      |                     |
      |           +-------+------+ |      |                     |
      |  CANCEL/6.2.3 |   |        |      |                     |
      |<--------------+   | CPG/   |      |                     |
      |                   | 6.2.9  |      |                     |
      |                   V        V      |                     |
      |    T9/6.2.8     +---------------+ |    REL/6.2.4        |
      +<----------------+    Alerting   |-|-------------------->|
      |<----------------+--+-----+------+ |                     |
      |  CANCEL/6.2.3      |  ^  |        |                     |
      |               CPG/ |  |  | ANM/   |                     |
      |              6.2.9 +--+  | 6.2.7  |                     |
      |                          V        V                     |
      |                 +-------------------------+    REL/9.2  |
      |                 |     Waiting for ACK     |------------>|
      |                 +-------------+-----------+             |
      |                               |                         |
      |                               | ACK/6.2.10              |
      |                               V                         |
      |     BYE/9.1     +-------------------------+    REL/9.2  |
      +<----------------+        Connected        +------------>+
                        +-------------------------+

Notes:

References in figure to 6.2 should point to 7.1.

RFC 3401, "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", October 2002

Source of RFC: urn (app)

Errata ID: 2642
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-11-22
Held for Document Update by: Peter Saint-Andre

Section 4, pg. 3 says:

[[  last bullet: ]]

   o  "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform
      Resource Identifiers (URI) Resolution Application" (RFC 3404) [3].
      This Application uses the DDDS to resolve any URI to a set of
      endpoints or 'resolvers' that can give additional information
      about the URI independent of its particular URI scheme.

It should say:

   o  "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform
      Resource Identifiers (URI) Resolution Application" (RFC 3404) [3].
      This Application uses the DDDS to resolve any URI to a set of
      endpoints or 'resolvers' that can give additional information
      about the URI independent of its particular URI scheme.
|     "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA
|     Assignment Procedures" (RFC 3405) [4] contains supplementary
|     specification for this application and the DNS database that it
|     utilizes.

Notes:

Rationale:
Missing citiation for RFC 3405 [4]; since there's no other instance
of that citation in the entire RFC, without it, the presence of
entry [4] in the References would not conform to the RFC Style Guide.

Errata ID: 2641
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-11-22
Held for Document Update by: Peter Saint-Andre

Section 2, 2nd para says:

|  This document along with RFC 3402, RFC 3403 and RFC 3404 obsoletes
   RFC 2168 [8] and RFC 2915 [6], as well as updates RFC 2276 [5].  This
   document will be updated and or obsoleted when changes are made to
   the DDDS specifications.  Thus the reader is strongly encouraged to
|  check the IETF RFC repository for any documents that obsoletes or
|  updates this one.

It should say:

|  This document along with RFC 3402 [1], RFC 3403 [2], and RFC 3404 [3]
   obsoletes RFC 2168 [8] and RFC 2915 [6], as well as updates RFC 2276
   [5].  This document will be updated and or obsoleted when changes are
   made to the DDDS specifications.  Thus the reader is strongly
   encouraged to check the IETF RFC repository for any documents that
|  update or obsolete this one.

Notes:

Rationale:
a) missing citations,
b) grammar,
c) changed order according to expected temporal order and likelyhood
and thus, to match the preceding sentence.

RFC 3403, "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", October 2002

Source of RFC: urn (app)

Errata ID: 2868
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kevin Dean
Date Reported: 2011-07-21
Held for Document Update by: Peter Saint-Andre

Section 4.1 says:

SERVICES
A <character-string> that specifies the Service Parameters
applicable to this this delegation path. It is up to the
Application Specification to specify the values found in this
field.

It should say:

SERVICES
A <character-string> that specifies the Service Parameters
applicable to this delegation path. It is up to the
Application Specification to specify the values found in this
field.

Notes:

Duplicate "this".

RFC 3404, "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", October 2002

Source of RFC: urn (app)

Errata ID: 2923
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kevin Dean
Date Reported: 2011-08-05
Held for Document Update by: Peter Saint-Andre

Section 4 says:

This template defines the URI and URN Resolution DDDS Application
according to the rules and requirements found in [3]. The DDDS
database used by this Application is found in [4] which is the
document that defines the Naming Authority Pointer (NAPTR) DNS
Resource Record (RR) type.

It should say:

This template defines the URI and URN Resolution DDDS Application
according to the rules and requirements found in [2]. The DDDS
database used by this Application is found in [3] which is the
document that defines the Naming Authority Pointer (NAPTR) DNS
Resource Record (RR) type.

Notes:

Reference numbers are incorrect.

RFC 3407, "Session Description Protocol (SDP) Simple Capability Declaration", October 2002

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: tsv

Errata ID: 3070
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marc Petit-Huguenin
Date Reported: 2011-12-28
Held for Document Update by: Robert Sparks

Section 3 says:

v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=
c=IN IP4 128.96.41.1
t=0 0
m=audio 3456 RTP/AVP 18 96
a=rtpmap:96 telephone-event
a=fmtp:96 0-15,32-35
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18 96
a=cpar: a=fmtp:96 0-16,32-35
a=cdsc: 4 image udptl t38
a=cdsc: 5 image tcp t38

It should say:

v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=
c=IN IP4 128.96.41.1
t=0 0
m=audio 3456 RTP/AVP 18 96
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15,32-35
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18 96
a=cpar: a=fmtp:96 0-16,32-35
a=cdsc: 4 image udptl t38
a=cdsc: 5 image tcp t38

Notes:

According to RFC 4566 section 6, the clock rate is mandatory:

"a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding
parameters>]"

RFC 3410, "Introduction and Applicability Statements for Internet-Standard Management Framework", December 2002

Source of RFC: snmpv3 (ops)

Errata ID: 1559
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Carl Marcinik
Date Reported: 2008-10-11
Held for Document Update by: Dan Romascanu
Date Held: 2010-05-10

Section 6.4 says:

STD 62, RFC 3415, "View-based Access Control Model (VCAM) for the
Simple Network Management Protocol (SNMP)" [27], describes how
view-based access control can be applied within command responder
and notification originator applications.

It should say:

STD 62, RFC 3415, "View-based Access Control Model (VACM) for the
Simple Network Management Protocol (SNMP)" [27], describes how
view-based access control can be applied within command responder
and notification originator applications.

Notes:

--VERIFIER NOTES--
s / VCAM / VACM

Errata ID: 1560
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Carl Marcinik
Date Reported: 2008-10-11
Held for Document Update by: Dan Romascanu

Section 8.2 says:

Of course, it is important that users deploying multi-lingual systems
with insecure protocols exercise sufficient due diligence to insure
that configurations limit access via SNMPv1 and SNMPv2c
appropriately, in keeping with the organization’s security policy,
just as they should carefully limit access granted via SNMPv3 with a
security level of no authentication and no privacy which is roughly
equivalent from a security point of view.

It should say:

Of course, it is important that users deploying multi-lingual systems
with insecure protocols exercise sufficient due diligence to ensure
that configurations limit access via SNMPv1 and SNMPv2c
appropriately, in keeping with the organization’s security policy,
just as they should carefully limit access granted via SNMPv3 with a
security level of no authentication and no privacy which is roughly
equivalent from a security point of view.

Notes:

The sentence used "insure" when it should have used "ensure".

RFC 3413, "Simple Network Management Protocol (SNMP) Applications", December 2002

Source of RFC: snmpv3 (ops)

Errata ID: 6531
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Juli Mallett
Date Reported: 2021-04-13
Held for Document Update by: Robert Wilton
Date Held: 2021-04-13

Throughout the document, when it says:

   4.1.1   Tag Lists .....................,........................   29

It should say:

   4.1.1   Tag Lists ..............................................   29

Notes:

Improper punctuation.

Errata ID: 6532
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Juli Mallett
Date Reported: 2021-04-13
Held for Document Update by: Robert Wilton
Date Held: 2021-04-13

Throughout the document, when it says:

   4.1.2   Definitions ..................,.........................   30

It should say:

   4.1.2   Definitions ............................................   30

Notes:

Improper punctuation,

RFC 3414, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", December 2002

Note: This RFC has been updated by RFC 5590

Source of RFC: snmpv3 (ops)

Errata ID: 3612
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yitzchak M. Gottlieb
Date Reported: 2013-05-03
Held for Document Update by: Benoit Claise

Section 2.5.2 says:

   maxMessageSize
      The maximum message size as included in the message.  The User-bas
      User-based Security module uses this value to calculate the
      maxSizeResponseScopedPDU.

It should say:

   maxMessageSize
      The maximum message size as included in the message.  The
      User-based Security module uses this value to calculate the
      maxSizeResponseScopedPDU.

Notes:

The words "User-based" were moved to the second line but not fully removed from the first.

RFC 3428, "Session Initiation Protocol (SIP) Extension for Instant Messaging", December 2002

Note: This RFC has been updated by RFC 8591

Source of RFC: sip (rai)

Errata ID: 2261
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Brett Tate
Date Reported: 2010-05-13
Held for Document Update by: Robert Sparks

Section 10 says:

MESSAGE sip:user2@domain.com SIP/2.0
Via: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bK123dsghds
Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse;
                                           received=1.2.3.4
Max-Forwards: 69
From: sip:user1@domain.com;tag=49394
To: sip:user2@domain.com
Call-ID: asd88asd77a@1.2.3.4
CSeq: 1 MESSAGE
Content-Type: text/plain
Content-Length: 18

Watson, come here.

The message is received by user2, displayed, and a response is
generated, message F3, and sent to the proxy:

SIP/2.0 200 OK
Via: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bK123dsghds;
                                         received=192.0.2.1
Via: SIP/2.0/TCP user1pc.domain.com;;branch=z9hG4bK776sgdkse;
                                            received=1.2.3.4
From: sip:user1@domain.com;tag=49394
To: sip:user2@domain.com;tag=ab8asdasd9
Call-ID: asd88asd77a@1.2.3.4
CSeq: 1 MESSAGE
Content-Length: 0

Note that most of the header fields are simply reflected in the
response.  The proxy receives this response, strips off the top Via,
and forwards to the address in the next Via, user1pc.domain.com, the
result being message F4:

SIP/2.0 200 OK
Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse;
                                           received=1.2.3.4
From: sip:user1@domain.com;;tag=49394
To: sip:user2@domain.com;tag=ab8asdasd9
Call-ID: asd88asd77a@1.2.3.4
CSeq: 1 MESSAGE
Content-Length: 0

It should say:

MESSAGE sip:user2@user2pc.domain.com SIP/2.0
Via: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bK123dsghds
Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse;
                                           received=1.2.3.4
Max-Forwards: 69
From: sip:user1@domain.com;tag=49583
To: sip:user2@domain.com
Call-ID: asd88asd77a@1.2.3.4
CSeq: 1 MESSAGE
Content-Type: text/plain
Content-Length: 18

Watson, come here.

The message is received by user2, displayed, and a response is
generated, message F3, and sent to the proxy:

SIP/2.0 200 OK
Via: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bK123dsghds;
                                         received=192.0.2.1
Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse;
                                           received=1.2.3.4
From: sip:user1@domain.com;tag=49583
To: sip:user2@domain.com;tag=ab8asdasd9
Call-ID: asd88asd77a@1.2.3.4
CSeq: 1 MESSAGE
Content-Length: 0

Note that most of the header fields are simply reflected in the
response.  The proxy receives this response, strips off the top Via,
and forwards to the address in the next Via, user1pc.domain.com, the
result being message F4:

SIP/2.0 200 OK
Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse;
                                           received=1.2.3.4
From: sip:user1@domain.com;tag=49583
To: sip:user2@domain.com;tag=ab8asdasd9
Call-ID: asd88asd77a@1.2.3.4
CSeq: 1 MESSAGE
Content-Length: 0

Notes:

The corrected text changes F2's request-uri to reflect the binding.
The corrected text proxies received From tag instead of changing it.
The corrected text removes various extra semicolons show within example.

Errata ID: 3702
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Amanda Baber
Date Reported: 2013-08-20
Held for Document Update by: Richard Barnes

Section 12 says:

This specification registers the MESSAGE method in the
http://www.iana.org/assignments/sip-parameters/Method registry

It should say:

This specification registers the MESSAGE method in the
http://www.iana.org/assignments/sip-parameters "Methods and 
Response Codes" registry

RFC 3439, "Some Internet Architectural Guidelines and Philosophy", December 2002

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: tsv

Errata ID: 3179
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Robby Simpson
Date Reported: 2012-04-04
Held for Document Update by: Wesley Eddy

Section 2.2.1 says:

   it could be catastrophically disabled my microscopic alterations in a

It should say:

   it could be catastrophically disabled by microscopic alterations in a

Notes:

Typo: I believe "my" should have been "by"

Errata ID: 3180
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Robby Simpson
Date Reported: 2012-04-04
Held for Document Update by: Wesley Eddy

Section 2.2.1 says:

   very few large CPUs (as the point out, fortunately this is a very

It should say:

   very few large CPUs (as they point out, fortunately this is a very

Notes:

Typo: I believe "the" should have been "they"

RFC 3447, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", February 2003

Note: This RFC has been obsoleted by RFC 8017

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 2582
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-10-20
Held for Document Update by: Sean Turner

Section 8.1.2 says:

   4. If Result = "consistent," output "valid signature." Otherwise,
      output "invalid signature."

It should say:

   4. If Result = "consistent", output "valid signature".  Otherwise,
      output "invalid signature".

Notes:

This report acually addresses a previous report, EID=2177,
and provides an improved version of the corrected text.

Note to Verifier: Please merge this Errata Note with EID=2177;
i.e. update the Corrected Text there as shown above, and reject
this Errata Note.

RFC 3454, "Preparation of Internationalized Strings ("stringprep")", December 2002

Note: This RFC has been obsoleted by RFC 7564

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: int

Errata ID: 4577
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Loïc Jonas Etienne
Date Reported: 2016-01-04
Held for Document Update by: Brian Haberman
Date Held: 2016-04-05

Section 3.1 says:

   Some characters are only useful in line-based text, and are otherwise
   invisible and ignored.

   00AD; SOFT HYPHEN
   1806; MONGOLIAN TODO SOFT HYPHEN
   200B; ZERO WIDTH SPACE
   2060; WORD JOINER
   FEFF; ZERO WIDTH NO-BREAK SPACE

It should say:

   Some characters are only useful in line-based text, and are otherwise
   invisible and ignored.

   00AD; SOFT HYPHEN
   200B; ZERO WIDTH SPACE
   2060; WORD JOINER
   FEFF; ZERO WIDTH NO-BREAK SPACE

Notes:

This issue has been reported to the unicode consortium (http://www.unicode.org/L2/L2015/15277-pubrev.html), according to which: U+1806 is not a control character; RFC 3454 is mistaken in mapping it to nothing, since the character always has a distinct visual appearance; For more information about the character, see page 528 of Core Specification, Version 8.0.

Errata ID: 2686
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jehan Pagès
Date Reported: 2011-01-20
Held for Document Update by: Alexey Melnikov

Section 3.2 says:

The list of characters to add to the mapping table can determined 
by the following algorithm:

It should say:

The list of characters to add to the mapping table can be determined 
by the following algorithm:

Notes:

A small omission of a single word: "be" is missing.

RFC 3458, "Message Context for Internet Mail", January 2003

Note: This RFC has been updated by RFC 3938

Source of RFC: vpim (app)

Errata ID: 7540
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bernie Hoeneisen
Date Reported: 2023-06-07
Held for Document Update by: Orie Steele
Date Held: 2024-03-29

Section 8 says:

8. IANA Considerations

   Section 8.3 is a registration for a new top-level RFC 2822 [3]
   message header, "Message-Context".

   This document creates an extensible set of context types.  To promote
   interoperability and coherent interpretations of different types, a
   central repository has been established for well-known context types.

   The IANA has created a repository for context types called "Internet
   Message Context Types".  Following the policies outlined in [5], this
   repository is "Specification Required" by RFC.  Section 8.1 describes
   the initial values for this registry.

   To create a new message context type, you MUST publish an RFC to
   document the type.  In the RFC, include a copy of the registration
   template found in Section 8.2 of this document.  Put the template in
   your IANA Considerations section, filling-in the appropriate fields.
   You MUST describe any interoperability and security issues in your
   document.

8.1. Message Content Type Registrations

   Internet Message Content Types

It should say:

8. IANA Considerations

   Section 8.3 is a registration for a new top-level RFC 2822 [3]
   message header, "Message-Context".

   This document creates an extensible set of context classes.  To promote
   interoperability and coherent interpretations of different classes, a
   central repository has been established for well-known context classes.

   The IANA has created a repository for context classes called "Internet
   Message Context Classes".  Following the policies outlined in [5], this
   repository is "Specification Required" by RFC.  Section 8.1 describes
   the initial values for this registry.

   To create a new message context class, you MUST publish an RFC to
   document the class.  In the RFC, include a copy of the registration
   template found in Section 8.2 of this document.  Put the template in
   your IANA Considerations section, filling-in the appropriate fields.
   You MUST describe any interoperability and security issues in your
   document.

8.1. Message Context Class Registrations

   Internet Message Context Classes

Notes:

This document appears to mix up some terms:

1) Context vs. Content: While most of the document refers to 'Context', parts of the IANA Considerations Section use 'Content' for the same thing

2) class vs. type: While most of the document uses 'class', parts of the IANA Considerations Section use 'type' for the same thing

Important: The IANA Registry https://www.iana.org/assignments/message-header-types/message-header-types.xhtml also needs to be updated (given this errata is considered valid)

RFC 3461, "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", January 2003

Note: This RFC has been updated by RFC 3798, RFC 3885, RFC 5337, RFC 6533, RFC 8098

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 4222
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Ned Freed
Date Reported: 2015-01-06
Held for Document Update by: Barry Leiba
Date Held: 2015-03-01

Section 5.1 says:

   (b) If an SMTP client issues a RCPT command containing any valid
       NOTIFY and/or ORCPT parameters, a conforming SMTP server MUST
       return the same response as it would to the same RCPT command
       without those NOTIFY and/or ORCPT parameters.  A conforming SMTP
       server MUST NOT refuse a RCPT command based on the presence or
       absence of any of these parameters.

It should say:

   (b) If an SMTP client issues a RCPT command containing any valid
       NOTIFY and/or ORCPT parameters, a conforming SMTP server MUST NOT
       alter its response solely based on the use or nonuse of these
       parameters. A conforming SMTP server MUST NOT refuse a RCPT
       command based on the presence of any of these parameters for
       anything other than reasons of local policy.

Notes:

The text as written effectively precludes using the content of the ORCPT or
NOTIFY parameters in implementing local filtering policies in general and
AS/AV policies in particular. If, for example, a particular ORCPT value
is known to associated with a source of spam, rejecting messages on that basis
at RCPT TO time should not be prohibited. Similarly, a site may place a high
priority on avoiding the possibility of blow-back spam associated with the
use of NOTIFY=SUCCESS; it should again be possible to reject messages
requesting success receipts as a matter of local policy.

Errata ID: 6422
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Ned Freed
Date Reported: 2021-02-05
Held for Document Update by: Barry Leiba
Date Held: 2021-02-05

Section 9.3 says:

MTA names of type "dns" SHOULD be valid Internet domain names.
If such domain names are not available, a domain-literal
containing the internet protocol address is acceptable.  Such
domain names generally conform to the following syntax:

        domain = real-domain / domain-literal

        real-domain = sub-domain *("." sub-domain)

        sub-domain = atom

        domain-literal = "[" 1*3DIGIT 3("." 1*3DIGIT) "]"

where "atom" and "DIGIT" are defined in [2].

It should say:

MTA names of type "dns" SHOULD be valid Internet domain names.
If such domain names are not available, a domain-literal
containing the internet protocol address is acceptable.  Such
domain names generally conform to the following syntax:

        domain = real-domain / domain-literal

        real-domain = sub-domain *("." sub-domain)

        sub-domain = atom

where "atom" and "domain-literal" are defined in [2].

Notes:

Domain literals should not have been restricted to IPv4 addresses. Note that an alternate way to fix this that could be done without a revision or errata would be to published a short RFC that defines a new MTA name type, say "alit" that could then be used for address literals.

Errata ID: 6386
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mark Johnston
Date Reported: 2021-01-14
Held for Document Update by: Barry Leiba
Date Held: 2021-01-14

Section 4 says:

   NOTE: Although RFC 822 ABNF is used to describe the syntax of these
   parameters, they are not, in the language of that document,
   "structured field bodies".  Therefore, while parentheses MAY appear
   within an emstp-value, they are not recognized as comment delimiters.

It should say:

   NOTE: Although RFC 822 ABNF is used to describe the syntax of these
   parameters, they are not, in the language of that document,
   "structured field bodies".  Therefore, while parentheses MAY appear
   within an esmtp-value, they are not recognized as comment delimiters.

Notes:

"emstp-value" should be "esmtp-value"

RFC 3463, "Enhanced Mail System Status Codes", January 2003

Note: This RFC has been updated by RFC 3886, RFC 4468, RFC 4865, RFC 4954, RFC 5248

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 4368
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Klensin
Date Reported: 2015-05-15
Held for Document Update by: Barry Leiba
Date Held: 2015-05-15

Section 3.4 says:

X.3.2
[...]
Examples of such conditions include an immanent shutdown, 

It should say:

X.3.2
[...]
Examples of such conditions include an imminent shutdown, 

Notes:

This is an obvious typographic or editorial error. I understand that a correction to the relevant IANA registry is in progress, so this erratum is to preserve consistency and provide a marker in case the RFC is ever revised.

This issue was noticed in the process of reviewing IANA actions that affected this code but not the phrase in question. Alex van den Bogaerdt <alex@vandenbogaerdt.nl> found and reported this issue independently and at just about the same time. Chris Newman, Expert Reviewer for the corresponding IANA registry, suggested filing the erratum.

RFC 3470, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", January 2003

Note: This RFC has been updated by RFC 8996

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 3789
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Erik Wilde
Date Reported: 2013-11-07
Held for Document Update by: Barry Leiba
Date Held: 2014-01-14

Section 4.2 says:

It some cases, protocols have been defined

It should say:

In some cases, protocols have been defined

Notes:

Simple typo

----- Verifier notes -----
Simple typos just go into "hold for document update". Best to resist the urge to submit them, unless they're likely to cause confusion.

RFC 3474, "Documentation of IANA assignments for Generalized MultiProtocol Label Switching (GMPLS) Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Usage and Extensions for Automatically Switched Optical Network (ASON)", March 2003

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 6539
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Juli Mallett
Date Reported: 2021-04-13
Held for Document Update by: Benjamin Kaduk
Date Held: 2021-04-15

Throughout the document, when it says:

       9.1 Call Capability.........;.................................15

It should say:

       9.1 Call Capability...........................................15

Notes:

semicolon is not the expected punctuation here.

RFC 3492, "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", March 2003

Note: This RFC has been updated by RFC 5891

Source of RFC: idn (int)

Errata ID: 3026
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Mathias Bynens
Date Reported: 2011-11-11
Held for Document Update by: Brian Haberman

Section 7.1 says:

   (I) Russian (Cyrillic):
       U+043F u+043E u+0447 u+0435 u+043C u+0443 u+0436 u+0435 u+043E
       u+043D u+0438 u+043D u+0435 u+0433 u+043E u+0432 u+043E u+0440
       u+044F u+0442 u+043F u+043E u+0440 u+0443 u+0441 u+0441 u+043A
       u+0438
       Punycode: b1abfaaepdrnnbgefbaDotcwatmq2g4l

It should say:

   (I) Russian (Cyrillic):
       U+043F u+043E u+0447 u+0435 u+043C u+0443 u+0436 u+0435 u+043E
       u+043D u+0438 u+043D u+0435 u+0433 u+043E u+0432 u+043E u+0440
       u+044F u+0442 u+043F u+043E u+0440 u+0443 u+0441 u+0441 u+043A
       u+0438
       Punycode: b1abfaaepdrnnbgefbadotcwatmq2g4l

Notes:

The uppercase `D` in the encoded string appears to be a typo.

RFC 3495, "Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration", March 2003

Source of RFC: dhc (int)

Errata ID: 4128
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bernie Volz
Date Reported: 2014-10-10
Held for Document Update by: Brian Haberman
Date Held: 2015-04-22

Section 5.5. says:

   The PacketCable architecture requires an MTA to authenticate itself
   to the TSP's network via the Kerberos protocol.  A Kerberos Realm
   name is required at the MTA to permit a DNS lookup for the address of
   the TSP's Kerberos Key Distribution Center (KDC) entity.

   The Kerberos Realm name MUST be encoded per the domain style realm
   name described in RFC 1510 [5].  This realm name MUST be all capital
   letters and conform to the syntax described in RFC 1035 [3] section
   3.1.  The sub-option is encoded as follows:

       Code   Len   Kerberos Realm Name
      +-----+-----+-----+-----+   +-----+
      |  6  |  n  |  k1 |  k2 |...|  kn |
      +-----+-----+-----+-----+   +-----+

It should say:

   The PacketCable architecture requires an MTA to authenticate itself
   to the TSP's network via the Kerberos protocol.  A Kerberos Realm
   name is required at the MTA to permit a DNS lookup for the address of
   the TSP's Kerberos Key Distribution Center (KDC) entity.

   The Kerberos Realm name MUST be use a domain style realm name
   described in RFC 1510 [5].  This realm name MUST be all capital
   letters and be encoded as described in RFC 1035 [3] section 3.1.
   The sub-option is encoded as follows:

       Code   Len   Kerberos Realm Name
      +-----+-----+-----+-----+   +-----+
      |  6  |  n  |  k1 |  k2 |...|  kn |
      +-----+-----+-----+-----+   +-----+

   Where k1...kn is the "DNS wire" encoded realm name (see RFC 3315,
   section 8). Thus, the realm "BASIC.1" is encoded as
   "\005BASIC\0011\000".

Notes:

This text is not completely clear about how the realm name is to be encoded - as a 'string' or 'fqdn'.

RFC 1510 states:

Kerberos realms are encoded as GeneralStrings. Realms shall not
contain a character with the code 0 (the ASCII NUL). Most realms
will usually consist of several components separated by periods (.),
in the style of Internet Domain Names, or separated by slashes (/) in
the style of X.500 names.

And the reference to RFC 1035 section 3.1 is "conform to the syntax" which isn't the same as use this encoding - though I do agree that section 3.1 is mostly about "DNS wire encoding". It is just the use of "encoded" and "confirm to the syntax" combination that makes this unclear.

It is believed that the intended encoding is in DNS wire format. And, this should be clarified.

RFC 3501, "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", March 2003

Note: This RFC has been obsoleted by RFC 9051

Note: This RFC has been updated by RFC 4466, RFC 4469, RFC 4551, RFC 5032, RFC 5182, RFC 5738, RFC 6186, RFC 6858, RFC 7817, RFC 8314, RFC 8437, RFC 8474, RFC 8996

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 3093
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Joe Pallas
Date Reported: 2012-01-18
Held for Document Update by: Pete Resnick

Section 6.3.11 says:

           Note: There MAY be exceptions, e.g., draft messages, in
           which required [RFC-2822] header lines are omitted in
           the message literal argument to APPEND.  The full
           implications of doing so MUST be understood and
           carefully weighed.

It should say:

           Note: There may be exceptions, e.g., draft messages, in
           which required [RFC-2822] header lines are omitted in
           the message literal argument to APPEND.  The full
           implications of doing so must be understood and
           carefully weighed.

Notes:

Possibly the result of a search-and-replace, these occurrences of "must" and "may" are not RFC 2119 usages.

Errata ID: 6160
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Gene Smith
Date Reported: 2020-05-07
Held for Document Update by: Barry Leiba
Date Held: 2020-05-08

Section Page 89 says:

search          = "SEARCH" [SP "CHARSET" SP astring] 1*(SP search-key)
                    ; CHARSET argument to MUST be registered with IANA

It should say:

search          = "SEARCH" [SP "CHARSET" SP astring] 1*(SP search-key)
                    ; CHARSET argument MUST be registered with IANA

Notes:

An errata already exists for the first line above: astring replaced with charset. The 2nd line seems to have an extra word, "to".

RFC 3504, "Internet Open Trading Protocol (IOTP) Version 1, Errata", March 2003

Source of RFC: trade (app)

Errata ID: 2947
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-08-26
Held for Document Update by: Peter Saint-Andre

Section metadata says:

n/a

It should say:

The document should be marked as "Updates: 2801" as it makes several normative changes to IOTP spec.

RFC 3525, "Gateway Control Protocol Version 1", June 2003

Note: This RFC has been obsoleted by RFC 5125

Source of RFC: megaco (rai)

Errata ID: 257
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Chen Rui
Date Reported: 2005-04-28
Held for Document Update by: Robert Sparks

Appendix I says:

   MEGACO/1 [125.125.125.111]:55555 Reply = 50006 {
    Context = 5000 {Modify = A4445} }

It should say:

   MEGACO/1 [125.125.125.111]:55555 Reply = 50006 {
    Context = 5000 {Modify = A5555} }

RFC 3530, "Network File System (NFS) version 4 Protocol", April 2003

Note: This RFC has been obsoleted by RFC 7530

Source of RFC: nfsv4 (wit)

Errata ID: 3376
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Kanda Motohiro
Date Reported: 2012-10-10
Held for Document Update by: Martin Stiemerling

Section 9.6 says:

modified attributes may be returned to the server in the response
to a CB_RECALL call.

It should say:

modified attributes may be returned to the server in the response
to a CB_GETATTR call.

RFC 3549, "Linux Netlink as an IP Services Protocol", July 2003

Source of RFC: forces (rtg)

Errata ID: 6014
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Andrea Grisotto
Date Reported: 2020-03-10
Held for Document Update by: Alvaro Retana
Date Held: 2020-07-21

Section 2.3.3.2 says:

le attributes:

It should say:

Applicable attributes:

RFC 3550, "RTP: A Transport Protocol for Real-Time Applications", July 2003

Note: This RFC has been updated by RFC 5506, RFC 5761, RFC 6051, RFC 6222, RFC 7022, RFC 7160, RFC 7164, RFC 8083, RFC 8108, RFC 8860

Source of RFC: avt (rai)

Errata ID: 3263
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Pieter Demuytere
Date Reported: 2012-06-18
Held for Document Update by: Robert Sparks

Section 6.4.1 says:

cumulative number of packets lost: 24 bits
   The total number of RTP data packets from source SSRC_n that have
   been lost since the beginning of reception.  This number is
   defined to be the number of packets expected less the number of
   packets actually received, where the number of packets received
   includes any which are late or duplicates.  Thus, packets that
   arrive late are not counted as lost, and the loss may be negative
   if there are duplicates.  The number of packets expected is
   defined to be the extended last sequence number received, as
   defined next, less the initial sequence number received.  This may
   be calculated as shown in Appendix A.3.

It should say:

cumulative number of packets lost: 24 bits 
   The total number of RTP data packets from source SSRC_n that have 
   been lost since the beginning of reception. This number is 
   defined to be the number of packets expected less the number of 
   packets actually received, where the number of packets received 
   includes any which are late or duplicates. Thus, packets that 
   arrive late are not counted as lost, and the loss may be negative 
   if there are duplicates. The number of packets expected is 
   defined to be the extended highest sequence number received, as 
   defined next, less the initial sequence number received. This may 
   be calculated as shown in Appendix A.3.

Notes:

Changed

The number of packets expected is defined to be the extended last sequence number received...

Into

The number of packets expected is defined to be the extended highest sequence number received...

Errata ID: 4770
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Petr Vaněk
Date Reported: 2016-08-08
Held for Document Update by: Ben Campbell
Date Held: 2016-08-08

Section 3. says:

   RTP session: An association among a set of participants
      communicating with RTP.  A participant may be involved in multiple
      RTP sessions at the same time.  In a multimedia session, each
      medium is typically carried in a separate RTP session with its own
      RTCP packets unless the the encoding itself multiplexes multiple
      media into a single data stream.  A participant distinguishes
      multiple RTP sessions by reception of different sessions using
      different pairs of destination transport addresses, where a pair
      of transport addresses comprises one network address plus a pair
      of ports for RTP and RTCP.  All participants in an RTP session may
      share a common destination transport address pair, as in the case
      of IP multicast, or the pairs may be different for each
      participant, as in the case of individual unicast network
      addresses and port pairs.  In the unicast case, a participant may
      receive from all other participants in the session using the same
      pair of ports, or may use a distinct pair of ports for each.

It should say:

   RTP session: An association among a set of participants
      communicating with RTP.  A participant may be involved in multiple
      RTP sessions at the same time.  In a multimedia session, each
      medium is typically carried in a separate RTP session with its own
      RTCP packets unless the encoding itself multiplexes multiple
      media into a single data stream.  A participant distinguishes
      multiple RTP sessions by reception of different sessions using
      different pairs of destination transport addresses, where a pair
      of transport addresses comprises one network address plus a pair
      of ports for RTP and RTCP.  All participants in an RTP session may
      share a common destination transport address pair, as in the case
      of IP multicast, or the pairs may be different for each
      participant, as in the case of individual unicast network
      addresses and port pairs.  In the unicast case, a participant may
      receive from all other participants in the session using the same
      pair of ports, or may use a distinct pair of ports for each.

Notes:

typo: double the in 5th line.

RFC 3552, "Guidelines for Writing RFC Text on Security Considerations", July 2003

Note: This RFC has been updated by RFC 8996, RFC 9416

Source of RFC: IAB

Errata ID: 3562
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: James Abley
Date Reported: 2013-03-22
Held for Document Update by: Russ Housley

Section 3.3.5 says:

Note that it is only necessary to authenticate one side of the 
transaction in order to prevent man-in-the-middle attacks.  In such a
situation the the peers can establish an association in which only
one peer is authenticated.

It should say:

Note that it is only necessary to authenticate one side of the 
transaction in order to prevent man-in-the-middle attacks.  In such a
situation the peers can establish an association in which only
one peer is authenticated.

Notes:

Remove repetition of "the"

RFC 3587, "IPv6 Global Unicast Address Format", August 2003

Source of RFC: ipv6 (int)

Errata ID: 5153
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: ZHANG Hongyuan
Date Reported: 2017-10-12
Held for Document Update by: Erik Kline
Date Held: 2021-12-18

Section 3 says:

    | 3 |     45 bits         |  16 bits  |       64 bits              |
    +---+---------------------+-----------+----------------------------+
    |001|global routing prefix| subnet ID |       interface ID         |
    +---+---------------------+-----------+----------------------------+

It should say:

    | 3 |     45 bits         |  16 bits  |       64 bits              |
    +---+---------------------+-----------+----------------------------+
    |001|                     | subnet ID |       interface ID         |
    +---+---------------------+-----------+----------------------------+
    |<-global routing prefix->|

Notes:

In the last figure of Section 3. Address Format, the global routing prefix should inlcude the prefix 001 in order to be consistent with the first two figures in the same section.

=====

Alternatively, the description of the 45 bits within the diagram might be updated to clarify these are the /remaining bits/ of the global routing prefix.

RFC 3588, "Diameter Base Protocol", September 2003

Note: This RFC has been obsoleted by RFC 6733

Note: This RFC has been updated by RFC 5729, RFC 5719, RFC 6408

Source of RFC: aaa (ops)

Errata ID: 2101
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Diego Rosario Brogna
Date Reported: 2010-03-31
Held for Document Update by: Dan Romascanu

Section 3.2 says:

header           = "<" Diameter-Header:" command-id
                      [r-bit] [p-bit] [e-bit] [application-id]">"

It should say:

header           = "<Diameter-Header:" command-id
                      [r-bit] [p-bit] [e-bit] [application-id]">"

Errata ID: 2564
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hans Liu
Date Reported: 2010-10-14
Held for Document Update by: Dan Romascanu

Section 6.1.8 says:

In figure 6, the contents of some AVPs contains domain name 
mno.net, but the network realm is example.net.

It should say:

Need to fix the inconsistent domain name, change all example.net 
to mno.net, which is more differentiable from another domain 
example.com

Errata ID: 3250
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jack Teng
Date Reported: 2012-06-10
Held for Document Update by: Benoit Claise

Section 1.3 says:

As with proxy agents, redirect agents do not keep state with 
respect to sessions or NAS resources.

It should say:

As with relay agents, redirect agents do not keep state with 
respect to sessions or NAS resources.

RFC 3591, "Definitions of Managed Objects for the Optical Interface Type", September 2003

Source of RFC: vgmib (int)

Errata ID: 3211
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yi, EungJun
Date Reported: 2012-05-05
Held for Document Update by: RonBonica

Section 2.1. says:

The OTN layering, as described in Figure 1, can be extended to
accomodate such implementations by introducing another layer called
the OChGroup Layer.

It should say:

The OTN layering, as described in Figure 1, can be extended to
accommodate such implementations by introducing another layer called
the OChGroup Layer.

Notes:

"accomodate" should be "accommodate"

RFC 3592, "Definitions of Managed Objects for the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Type", September 2003

Source of RFC: vgmib (int)

Errata ID: 3742
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Anshul Chandra
Date Reported: 2013-10-04
Held for Document Update by: Benoit Claise
Date Held: 2013-10-26

Section 3.5 says:

increase the UAS count by 10 when it
determines that available time has been entered.

It should say:

increase the UAS count by 10 when it
determines that unavailable time has been entered.

Notes:

the word "available" should be changed to "unavailable";

RFC 3600, "Internet Official Protocol Standards", November 2003

Note: This RFC has been obsoleted by RFC 3700

Source of RFC: Legacy

Errata ID: 2779
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-04-17
Held for Document Update by: Ron Bonica

Section TOC says:

 2.  Contacts . . . . . . . . . . . . . . . . . . . . . . . . . . .  2

It should say:

 2.  Resources  . . . . . . . . . . . . . . . . . . . . . . . . . .  2

RFC 3605, "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", October 2003

Source of RFC: mmusic (rai)

Errata ID: 2292
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: linear
Date Reported: 2010-05-30
Held for Document Update by: Robert Sparks

Section 1 says:

The session invitation protocol (SIP, [RFC3261])

It should say:

The session initiation protocol (SIP, [RFC3261])

Notes:

SIP stand for Session Initiation Protocol, not invitation.

RFC 3611, "RTP Control Protocol Extended Reports (RTCP XR)", November 2003

Source of RFC: avt (rai)

Errata ID: 2262
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Kamil Sarac
Date Reported: 2010-05-14
Held for Document Update by: Robert Sparks

Section 4.6 says:

   min_jitter: 32 bits
         The minimum relative transit time between two packets in the
         above sequence number interval.  All jitter values are measured
         as the difference between a packet's RTP timestamp and the
         reporter's clock at the time of arrival, measured in the same
         units.

   max_jitter: 32 bits
         The maximum relative transit time between two packets in the
         above sequence number interval.

   mean_jitter: 32 bits
         The mean relative transit time between each two packet series
         in the above sequence number interval, rounded to the nearest
         value expressible as an RTP timestamp.

   dev_jitter: 32 bits
         The standard deviation of the relative transit time between
         each two packet series in the above sequence number interval.

It should say:

   min_jitter: 32 bits
         The minimum jitter measured for a pair of packets in the above
         sequence number interval.  The packet jitter is defined in [9,
         Section 6.4.1] and measured in timestamp units.

   max_jitter: 32 bits
         The maximum jitter measured for a pair of packets in the above
         sequence number interval.

   mean_jitter: 32 bits
         The mean jitter measured for a pair of packets in the above
         sequence number interval, rounded to the nearest
         value expressible as a timestamp.

   dev_jitter: 32 bits
         The standard deviation of the jitter measured for a pair of packets
         in the above sequence number interval.

Notes:

In the original RFC 3611 in Section 4.6 where it defines "min_jitter", the jitter definition is different from the one given in RFC3550. This errata report is to correct this difference by referring to RFC 3550 for the proper definition of jitter and revises the definitions of "min_jitter", "max_jitter", "mean_jitter", and "dev_jitter" fields.

Errata ID: 4386
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Tong Zhou
Date Reported: 2015-06-03
Held for Document Update by: Ben Campbell
Date Held: 2015-08-03

Section 4.7.2 says:

   For example, a 1 denotes a received packet, 0 a lost packet, and X a
   discarded packet in the following pattern covering 64 packets:

      11110111111111111111111X111X1011110111111111111111111X111111111
      |---------gap----------|--burst---|------------gap------------|

   The burst consists of the twelve packets indicated above, starting at
   a discarded packet and ending at a lost packet.  The first gap starts
   at the beginning of the session and the second gap ends at the time
   of the report.

   If the packet spacing is 10 ms and the Gmin value is the recommended
   value of 16, the burst duration is 120 ms, the burst density 0.33,
   the gap duration 230 ms + 290 ms = 520 ms, and the gap density 0.04.

It should say:

   For example, a 1 denotes a received packet, 0 a lost packet, and X a
   discarded packet in the following pattern covering 64 packets:

      11110111111111111111111X111X1011110111111111111111111X1111111111
      |---------gap----------|--burst---|------------gap------------|

   The burst consists of the twelve packets indicated above, starting at
   a discarded packet and ending at a lost packet.  The first gap starts
   at the beginning of the session and the second gap ends at the time
   of the report.

   If the packet spacing is 10 ms and the Gmin value is the recommended
   value of 16, the burst duration is 120 ms, the burst density 0.33,
   the gap duration 230 ms + 290 ms = 520 ms, and the gap density 0.04.

Notes:

The pattern in the example shows 63 packets rather than 64. Added a "1" at the end. Another option is to keep the pattern unchanged, and redo the math.

RFC 3625, "The QCP File Format and Media Types for Speech Data", September 2003

Source of RFC: INDEPENDENT

Errata ID: 5135
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Peter Smith
Date Reported: 2017-10-03
Held for Document Update by: Adrian Farrel
Date Held: 2021-06-01

Section 3 says:

   FMT             = %x66 %x6D %x74 %x20

   LABL            = %x6C %x61 %x62 %x6C

   OFFS            = %x6F %x66 %x66 %x73

   DATA            = %x64 %x61 %x74 %x61

   CNFG            = %x63 %x6E %x66 %x67

   TEXT            = %x74 %x65 %x78 %x74

It should say:

The values for FMT, LABL, OFFS, DATA, CNFG and TEXT all specify
lower-case text values, not upper-case.

Notes:

We can reduce the number of bad implementations by adding a small note mentioning that some of these values are lower case. The values appear at first glance to all be upper-case. A hasty implementer might carelessly use upper case values here instead of the correct lower-case values.

=ISE Note=
The observation is correct (that these six labels use lower case text values and that a careless implementer might miss that fact), but there is no editorial error in the document.
A future revision of this document might add such a note.

RFC 3626, "Optimized Link State Routing Protocol (OLSR)", October 2003

Source of RFC: manet (rtg)

Errata ID: 5092
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Denis Ovsienko
Date Reported: 2017-08-19
Held for Document Update by: Alvaro Retana
Date Held: 2017-08-23

Section 6.1 says:

      Reserved

         This field must be set to "0000000000000" to be in compliance
         with this specification.

It should say:

      Reserved

         This field must be set to zero to be in compliance with this 
         specification.

Notes:

Reserved takes 16+n*8 bits in this message, but the text specifies a 13-bit constant.

RFC 3633, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", December 2003

Note: This RFC has been obsoleted by RFC 8415

Note: This RFC has been updated by RFC 6603, RFC 7550

Source of RFC: dhc (int)

Errata ID: 248
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hideshi Enokihara
Date Reported: 2006-06-15
Held for Document Update by: Brian Haberman

Section 9 says:

   If a requesting router receives an IA_PD with T1 greater than T2, and
   both T1 and T2 are greater than 0, the client discards the IA_PD
   option and processes the remainder of the message as though the
   delegating router had not included the IA_PD option.

It should say:

   If a requesting router receives an IA_PD with T1 greater than T2, and
   both T1 and T2 are greater than 0, the requesting router discards the IA_PD
   option and processes the remainder of the message as though the
   delegating router had not included the IA_PD option.

Notes:

Errata ID: 1880
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yukiyo Akisada
Date Reported: 2009-09-15
Held for Document Update by: Brian Haberman

Section 9 says:

   If a delegating router receives an IA_PD with T1 greater than T2, and
   both T1 and T2 are greater than 0, the delegating router ignores the
   invalid values of T1 and T2 and processes the IA_PD as though the
   delegating router had set T1 and T2 to 0.

It should say:

   If a delegating router receives an IA_PD with T1 greater than T2, and
   both T1 and T2 are greater than 0, the delegating router ignores the
   invalid values of T1 and T2 and processes the IA_PD as though the
   requesting router had set T1 and T2 to 0.

Errata ID: 3736
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alexandru Petrescu (w/ text from R. Droms)
Date Reported: 2013-09-25
Held for Document Update by: Ted Lemon
Date Held: 2013-09-25

Section 14 says:

If a delegating router communicates with a requesting router through
a relay agent, the delegating router may need a protocol or other
out-of-band communication to add routing information for delegated
prefixes into the provider edge router.

It should say:

If a delegating router communicates with a requesting router through
a relay agent, the delegating router may need a protocol or other
out-of-band communication to configure routing information for delegated
prefixes on any router through which the requesting router may forward
traffic.

Notes:

This is a terminology correction. See discussion on the email list DHCWG of the DHC WG of IETF, 24 September 2013, http://www.ietf.org/mail-archive/web/dhcwg/current/msg14709.html

RFC 3647, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", November 2003

Source of RFC: pkix (sec)

Errata ID: 3299
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mezzetti, Gustavo
Date Reported: 2012-07-28
Held for Document Update by: Sean Turner
Date Held: 2012-07-28

Section 3.1 says:

A CP within this category often makes sets requirements
appropriate for a certain "level of assurance" provided
by certificates, relative to certificates issued pursuant
to related CPs.

It should say:

A CP within this category often sets requirements
appropriate for a certain "level of assurance" provided
by certificates, relative to certificates issued pursuant
to related CPs.

Notes:

r/makes sets/sets

RFC 3659, "Extensions to FTP", March 2007

Source of RFC: ftpext (app)

Errata ID: 1500
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maik Reiß (Reiss)
Date Reported: 2008-09-02
Held for Document Update by: Barry Leiba

Section 7.7.4 says:

7.7.4.  A More Complex Example
 ...
C> MLSD test
S> 150 BINARY connection open for MLSD test
D> Type=cdir;Perm=el;Unique=keVO1+ZF4; test
D> Type=pdir;Perm=e;Unique=keVO1+d?3; ..
D> Type=OS.unix=slink:/foobar;Perm=;Unique=keVO1+4G4; foobar

It should say:

7.7.4.  A More Complex Example
 ...
C> MLSD test
S> 150 BINARY connection open for MLSD test
D> Type=cdir;Perm=el;Unique=keVO1+ZF4; test
D> Type=pdir;Perm=e;Unique=keVO1+d?3; ..
D> Type=OS.unix=symlink;Perm=;Unique=keVO1+4G4; foobar
     ... more lines ...
D> Type=dir;Perm=;Unique=keVO1+4G4; /foobar; does originally point to here

Notes:

The sample sequence in chapter 7.7.4 uses an example which is completely wrong, because it violates the basic BNF rules of its own document.

Please, see the definition, which is violated:

7.2. Format of MLSx Response
The format of a response to an MLSx command is as follows:
...
entry = [ facts ] SP pathname
facts = 1*( fact ";" )
fact = factname "=" value
...

Remember, a fact may not contain ";" or SPC (" ")!
Now take a look into the bad example:


7.7.4. A More Complex Example
...
C> MLSD test
S> 150 BINARY connection open for MLSD test
D> Type=cdir;Perm=el;Unique=keVO1+ZF4; test
D> Type=pdir;Perm=e;Unique=keVO1+d?3; ..
D> Type=OS.unix=slink:/foobar;Perm=;Unique=keVO1+4G4; foobar


the last line uses the fact "Type=OS.unix=slink:/foobar;". While this line in special not violates the rules at the moment, it implies that "Type=OS.unix=slink:" starts printing the original link target of any given symbolic link. Not wrong till here, but in case a link points to an original directory which name contains a ";" or, most worse, a "; " sequence, it will
lead any client side PI into misinterpretation of the line.

Even more worse, some actual public servers already use this bad syntax. Some can be found at least in the Swiss. It looks like they are running proftpd under Linux operating system, but this is unconfirmed for now.


Solution:

The chapter 7 of the same document allows another approach to tell the client about the original destination of a symlink. This solution uses two lines of answer, see my example:

C> MLSD test
S> 150 BINARY connection open for MLSD test
D> Type=cdir;Perm=el;Unique=keVO1+ZF4; test
D> Type=pdir;Perm=e;Unique=keVO1+d?3; ..
D> Type=OS.unix=symlink;Perm=;Unique=keVO1+4G4; foobar points somewhere else
... more lines ...
D> Type=dir;Perm=;Unique=keVO1+4G4; /foobar; does originally point to here

because of the "Unique" fact, a client PI can now collect all lines with the fact "Type=OS.unix=symlink" and file it under an associative array (map, hastable) with "keVO1+4G4" as the access key. Once the client side parser again gets "Unique=keVO1+4G4", it now can record "/foobar; does point to here" as the original point where foobar points to.

This is exactly, what chapter 7.5.1.5 defines about the "Unique" fact. Please read:
Note: Where the underlying system supports a file type that is
essentially an indirect pointer to another file, the NVFS
representation of that type should normally be to represent the file
that the reference indicates. That is, the underlying basic file
will appear more than once in the NVFS, each time with the "unique"
fact (see immediately following section) containing the same value,
indicating that the same file is represented by all such names.


Useful to say, setting the slink into double quotes like suggested by some developers:

D> Type=OS.unix="slink:/foobar";Perm=;Unique=keVO1+4G4; foobar

would violate the same documents BNF rules (see RCHAR), as well it would require escaping of any DQUOTE in the link pathname itself. This, again, would violate RFC959 which not defines escaping of characters.


Finally, FTP does not support 2 pathnames at the same line at all. This convention sould never been broken.

Errata ID: 2850
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-06-29
Held for Document Update by: Peter Saint-Andre

Section 2.5 says:

   and each sequence of
   lines that begin "D> " was sent from the server-PI to the user-PI
   over a data connection created just to send those lines and closed
   immediately after.

It should say:

   and each sequence of
   lines that begin "D> " was sent from the server-DTP to the user-DTP
   over a data connection created just to send those lines and closed
   immediately after.

Notes:

In this case the acting parties are DTPs, not PIs.

Errata ID: 903
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-04-14
Held for Document Update by: Peter Saint-Andre

Section 9 says:

                                 [...].  Unless the "media-type" fact is
   provided in a MLSx response nor is any advice given here that would
   allow determining the content type.  [...]

It should say:

                                 [...].  Unless the "media-type" fact is
   provided in a MLSx response, no advice is given here that would allow
   determining the content type.  [...]

Notes:

This sentence apparently is garbled a bit.

from pending

Errata ID: 2496
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Anthony Bryan
Date Reported: 2010-08-21
Held for Document Update by: Peter Saint-Andre

Throughout the document, when it says:

3.2
...
Various 4xy replies are also possible in appropriate circumstances.

4.2
...
Various 4xy replies are also possible in appropriate circumstances.

7.2.1
   Many of the 4xy and 5xy responses defined in section 4.2 of STD 9,
   RFC 959 [3] are possible in response to the MLST and MLSD commands.
...
   Other replies (530, 553, 503, 504, and any of the 4xy replies) are
   also possible in appropriate circumstances.

It should say:

3.2
...
Various 4yz replies are also possible in appropriate circumstances.

4.2
...
Various 4yz replies are also possible in appropriate circumstances.

7.2.1
   Many of the 4yz and 5yz responses defined in section 4.2 of STD 9,
   RFC 959 [3] are possible in response to the MLST and MLSD commands.
...
   Other replies (530, 553, 503, 504, and any of the 4yz replies) are
   also possible in appropriate circumstances.

Notes:

RFC 959, Section 4.2 refers to these reply codes as 4yz and 5yz, instead of 4xy and 5xy.

RFC 3677, "IETF ISOC Board of Trustee Appointment Procedures", December 2003

Source of RFC: IAB

Errata ID: 3864
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2014-01-10
Held for Document Update by: Russ Housley
Date Held: 2014-03-02

Section 1 says:

   The Internet Society (ISOC) provides organizational and financial
   support for the IETF.  As stipulated in ISOC's by-laws the IETF is
   called upon to name 3 Trustees to its Board (BoT), with staggered 3
   year terms.  This requires that the IETF name one Trustee each year.

It should say:

   The Internet Society (ISOC) provides organizational and financial
   support for the IETF.  As stipulated in ISOC's by-laws the IETF is
   called upon to name four Trustees to its Board (BoT), each with a
   three-year term.  On a three year rotation, the IETF names two
   Trustees, one Trustee, and one Trustee.

Notes:

The Internet Society Bylaws changed on 22 July 2013. See http://www.internetsociety.org/who-we-are/governance-and-policies/amended-and-restated-laws-internet-society.

RFC 3693, "Geopriv Requirements", February 2004

Note: This RFC has been updated by RFC 6280, RFC 7459

Source of RFC: geopriv (rai)

Errata ID: 4621
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jay R. Ashworth
Date Reported: 2016-02-17
Held for Document Update by: Alissa Cooper
Date Held: 2016-02-18

Section 8.1 says:

This means that Geopriv may not as a general matter, 
secure the Target against general traffic analysis attacks 
or other forms of privacy violations.

It should say:

This means that Geopriv might not, as a general matter, 
secure the Target against general traffic analysis attacks 
or other forms of privacy violations.

Notes:

Aside from the missing comma on the parenthetical, the use of MAY NOT, even uncapitalized, appears to collide with RFC 2119: It's pretty clear the authors intended to say that there may exist conditions in which Geopriv won't secure targets, but the chosen wording, interpreted in context of 2119, means that Geopriv *will not* or *must not* secure Targets, and that interpretation is sort of bogus.

In short: May here is directive, rather than predictive/descriptive, which seems what was intended.

RFC 3696, "Application Techniques for Checking and Transformation of Names", February 2004

Source of RFC: INDEPENDENT

Errata ID: 4002
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Brandon Gabbert
Date Reported: 2014-05-28
Held for Document Update by: Nevil Brownlee
Date Held: 2014-08-25

Section 3 says:

   The exact rule is that any ASCII character, including control
   characters, may appear quoted, or in a quoted string.  When quoting
   is needed, the backslash character is used to quote the following
   character.  For example

      Abc\@def@example.com

   is a valid form of an email address.  Blank spaces may also appear,
   as in

      Fred\ Bloggs@example.com

   The backslash character may also be used to quote itself, e.g.,

      Joe.\\Blow@example.com

   In addition to quoting using the backslash character, conventional
   double-quote characters may be used to surround strings.  For example

      "Abc@def"@example.com

      "Fred Bloggs"@example.com

   are alternate forms of the first two examples above.

It should say:

   The exact rule is that any ASCII character, including control
   characters, may appear quoted, or in a quoted string.  When quoting
   is needed, the backslash character is used to quote the following
   character.  For example

      Abc\@def@example.com

   is a valid form of an email address.  Blank spaces may also appear,
   as in

      Fred\ Bloggs@example.com

   The backslash character may also be used to quote itself, e.g.,

      Joe.\\Blow@example.com

   In addition to quoting using the backslash character, conventional
   double-quote characters may be used to surround strings.  For example

      "Abc@def"@example.com

      "Fred Bloggs"@example.com

      "Joe.\\Blow"@example.com

   are alternate forms of the examples above.

Notes:

Errata 3563 is incorrect. The first two suggested additions it makes to the spec are actually already present in the original spec just one paragraph down. The third and final suggested addition (allowing an unquoted backslash in a quoted string), while appearing to comport with this RFC, violates RFC 2822 (the reference document for this section). While the suggested email address is valid, it is not equivalent to the original.

RFC 2822 sections 3.2.1, 3.2.2, and 3.2.5 define quoted-string as consisting of any unquoted ASCII character except for backslash and double quote, and any backslash-quoted ASCII character including backslash and double quote.

Thus, while it is correct that

"Joe.\Blow"@example.com

is a valid email address, it is not equivalent to

Joe.\\Blow@example.com

as the \B in the first should be interpreted as a quoted B, not as an illegally unquoted backslash followed by a B. The quoted equivalent of

Joe.\\Blow@example.com

is

"Joe.\\Blow"@example.com

This example was probably left out of the original spec because the quoted-string version differs from the original only in the quotes themselves.

Errata ID: 7592
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rémi Plénat
Date Reported: 2023-08-07
Held for Document Update by: RFC Editor
Date Held: 2024-04-09

Section 3 says:

acute accent ("`")

It should say:

backtick ("`")

Notes:

Acute accent would be in the other direction like in É.
This accent is usually mentioned as backtick or backquote.

===RPC Notes===

A bis doc should consider referring to "grave accent", "backtick", or "backquote".

From John Klensin:
"grave accent" is the term used both by Unicode and by the ASCII
standard (X3.4-1968, RFC 20, INCITS 4-1986[R2017], ISO 646 BV).
In Unicode-land and the surrounding vicinity, "backtick" is
often a combining character, U+0300, and backquote is, even more
often--and preferred by the Standard -- U+301D. Neither
backtick or backquote is used by Unicode to identify a
character, probably because of those ambiguities.

RFC 3706, "A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers", February 2004

Source of RFC: ipsec (sec)

Errata ID: 1626
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Joel Faber
Date Reported: 2008-12-03
Held for Document Update by: Pasi Eronen

Section 4.2 says:

   The disadvantage of this scheme is the reliance upon the peer to
   demonstrate liveliness.  To this end, peer B might never be
   interested in peer A's liveliness.  Nonetheless, if A is interested
   B's liveliness, B must be aware of this, and maintain the necessary
   state information to send periodic HELLOs to A.  The disadvantage of

It should say:

   The disadvantage of this scheme is the reliance upon the peer to
   demonstrate liveliness.  To this end, peer B might never be
   interested in peer A's liveliness.  Nonetheless, if A is interested in
   B's liveliness, B must be aware of this, and maintain the necessary
   state information to send periodic HELLOs to A.  The disadvantage of

Notes:

Add "in" to make "interested in B's liveliness".

RFC 3709, "Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates", February 2004

Note: This RFC has been obsoleted by RFC 9399

Note: This RFC has been updated by RFC 6170

Source of RFC: pkix (sec)

Errata ID: 2679
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexey Melnikov
Date Reported: 2010-12-22
Held for Document Update by: Sean Turner

Section 4.1 says:

LogotypeDetails ::= SEQUENCE {
   mediaType       IA5String, -- MIME media type name and optional
                              -- parameters
   logotypeHash    SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
   logotypeURI     SEQUENCE SIZE (1..MAX) OF IA5String }

Notes:

The mediaType is underspecified, as no specific syntax is given.
E.g. are spaces allowed before parameters? Also, my understanding is that IA5String disallows UTF-8, while media type parameters can possibly include UTF-8 values.

I would recommend referencing ABNF from Section 4.2 of RFC 4288.

Errata ID: 2325
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alexey Melnikov
Date Reported: 2010-07-13
Held for Document Update by: Tim Polk

Section 4.1 says:

   When using indirect addressing, the URI (refStructURI) pointing to
   the external data structure MUST point to a binary file containing
   the DER encoded data with the syntax LogotypeData.  The referenced
   file name SHOULD include a file extension of "LTD".

Notes:

There is no IETF process for only registering a file extension. IETF MIME type registry allows to register MIME types together with the corresponding file extensions. An update to this document should register a new MIME type for "LTD".

RFC 3711, "The Secure Real-time Transport Protocol (SRTP)", March 2004

Note: This RFC has been updated by RFC 5506, RFC 6904, RFC 9335

Source of RFC: avt (rai)

Errata ID: 3420
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Matthias Schertler
Date Reported: 2012-11-28
Held for Document Update by: Gonzalo Camarillo

Section 3.1. says:

   The "Encrypted Portion" of an SRTP packet consists of the encryption
   of the RTP payload (including RTP padding when present) of the
   equivalent RTP packet.

It should say:

   The "Encrypted Portion" of an SRTP packet consists of the encryption
   of the RTP payload (including RTP padding and RTP pad count when present)
   of the equivalent RTP packet.  

Notes:

In Figure 1 "RTP padding" and "RTP pad count" are different things. The text should use the same terminology in order to make clear that the padding count is encrypted.

Errata ID: 3712
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Christian S Oien
Date Reported: 2013-08-27
Held for Document Update by: Richard Barnes
Date Held: 2014-02-15

Section 4.3.2 says:

Replace the SRTP index by the 32-bit quantity: 0 || SRTCP index
 (i.e., excluding the E-bit, replacing it with a fixed 0-bit), and use
<label> = 0x03 for the SRTCP encryption key, <label> = 0x04 for the
SRTCP authentication key, and, <label> = 0x05 for the SRTCP salting
key.

It should say:

Replace the SRTP index by the 48-bit quantity: 000...0 || 0 || SRTCP
index (i.e., excluding the E-bit, replacing it with a fixed 0-bit and
padding the result so that it becomes 48 bits wide to match the size
of the SRTP index). Since this quantity and the SRTP index are both
48 bits wide, the labels are all located in the same octet in the IV.
The labels for the derivations of the SRTCP keys are as follows:   
<label> = 0x03 for the SRTCP encryption key, <label> = 0x04 for the 
SRTCP authentication key, and, <label> = 0x05 for the SRTCP salting 
key.

Notes:

Replacing with a 32-bit quantity means that the DIV operator will
yield a 32-bit quantity. Following the specification of key_id for SRTCP
the <label> will have 32 bits to its right when XOR'ing with master_salt.

The majority of implementations, including libsrtp, invokes this XOR with the
<label> at the same position as for SRTP. According to the specification
this should be done 16 bits to the right of this, when invoking for SRTCP.

Errata ID: 1958
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jaap Keuter
Date Reported: 2009-12-10
Held for Document Update by: Robert Sparks

Section 1 says:

   This document describes the Secure Real-time Transport Protocol
   (SRTP), a profile of the Real-time Transport Protocol (RTP), which
   can provide confidentiality, message authentication, and replay
   protection to the RTP traffic and to the control traffic for RTP,
   RTCP (the Real-time Transport Control Protocol) [RFC3350].

It should say:

   This document describes the Secure Real-time Transport Protocol
   (SRTP), a profile of the Real-time Transport Protocol (RTP), which
   can provide confidentiality, message authentication, and replay
   protection to the RTP traffic and to the control traffic for RTP,
   RTCP (the Real-time Transport Control Protocol) [RFC3550].

Notes:

Reference is made to the RFC pertaining RTP, which is 3550, not 3350.

Errata ID: 4425
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ross Finlayson
Date Reported: 2015-07-22
Held for Document Update by: Ben Campbell
Date Held: 2016-04-13

Section 3.4 says:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
     |V=2|P|    RC   |   PT=SR or RR   |             length          | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |

It should say:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
     |V=2|P|    RC   |   PT=SR or RR |             length          | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |

Notes:

The boundary between the "PT=SR or RR" and the "length" fields is wrong: The boundary is shown as being between bits 16 and 17; it should be between bits 15 and 16. I.e., the "PT=SR or RR" field should be 8 bits long, not 9.

This is just a minor bug, because the equivalent diagram in RFC 3550 (the normative reference for RTCP) is correct. Nonetheless, this bug should probably be added to the errata for RFC 3711

Errata ID: 4514
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bernhard Kirchen
Date Reported: 2015-10-29
Held for Document Update by: Ben Campbell
Date Held: 2015-10-30

Section 3.1 says:

The format of an SRTP packet is illustrated in Figure 1.

   0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+

It should say:

The format of an SRTP packet is illustrated in Figure 1.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+

Notes:

The bit index second decimal digit is shifted by two characters. These digits should align with the zeros in the second line.

RFC 3716, "IETF in the Large: Administration and Execution", March 2004

Source of RFC: IAB

Errata ID: 5528
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Jason Livingood
Date Reported: 2018-10-15
Held for Document Update by: Mirja Kühlewind
Date Held: 2024-01-11

Section 1.2 says:

focused on the IETF executive structure 

It should say:

focused on the IETF administrative structure 

Notes:

Should be changed in future versions to describe as administratively-focused, consistent with the organizational descriptions in IASA1 and IASA2. However, IASA1/2 were published after this RFC and therefore this was not an errata at the time of publication.

Errata ID: 5529
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Jason Livingood
Date Reported: 2018-10-15
Held for Document Update by: Mirja Kühlewind
Date Held: 2024-01-11

Section 2.1.3 says:

including the IETF Executive Director

It should say:

including the Managing Director, IETF Secretariat,

Notes:

The definition of what the IETF Executive Director is has changed under IASA2. This correction reflects the new job definition and title. However, IASA 2 was published after this RFC and therefore this was not an errata at the time of publication.

RFC 3739, "Internet X.509 Public Key Infrastructure: Qualified Certificates Profile", March 2004

Source of RFC: pkix (sec)

Errata ID: 7802
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2024-02-07
Held for Document Update by: Paul Wouters
Date Held: 2024-02-07

Section A.1 says:

   SemanticsInformation  ::= SEQUENCE {
       semanticsIndentifier        OBJECT IDENTIFIER OPTIONAL,
       nameRegistrationAuthorities NameRegistrationAuthorities OPTIONAL
       } -- At least one field shall be present

It should say:

   SemanticsInformation  ::= SEQUENCE {
       semanticsIdentifier         OBJECT IDENTIFIER OPTIONAL,
       nameRegistrationAuthorities NameRegistrationAuthorities OPTIONAL
       } -- At least one field shall be present

Notes:

The body of the document and Appendix A.2 use "semanticsIdentifier" for the name of the first item in the SEQUENCE. This change is needed to the normative ASN.1 module to be consistent.

Note: the typo is "Indentifier" instead of "Identifier".

Errata ID: 3216
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Annie Yousar
Date Reported: 2012-05-07
Held for Document Update by: Sean Turner

Section 3.2.6.1. says:

If a value of type SemanticsInformation is present in a QCStatement
where the statementID component is set to id-qcs-pkix-QCSyntax-v1 or
id-qcs-pkix-QCSyntax-v2, then at least one of the semanticsIdentifier
or nameRegistrationAuthorities fields must be present, as indicated.
Note that the statementInfo component need not be present in a 
QCStatement value even if the statementID component is set to id-
qcs-pkix-QCSyntax-v1 or id-qcs-pkix-QCSyntax-v2.

It should say:

If a value of type SemanticsInformation is present in a QCStatement
where the statementID component is set to id-qcs-pkixQCSyntax-v1 or
id-qcs-pkixQCSyntax-v2, then at least one of the semanticsIdentifier
or nameRegistrationAuthorities fields must be present, as indicated.
Note that the statementInfo component need not be present in a
QCStatement value even if the statementID component is set to 
id-qcs-pkixQCSyntax-v1 or id-qcs-pkixQCSyntax-v2.

Notes:

The extra minus sign "-" in pkix-QCSyntax should be deleted.
To avoid confusion of the minus sign with a hyphen "id-qcs-pkixQCSyntax-v1" should not be broken across lines.

RFC 3746, "Forwarding and Control Element Separation (ForCES) Framework", April 2004

Source of RFC: forces (rtg)

Errata ID: 5337
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2018-04-27
Held for Document Update by: Martin Vigoureux
Date Held: 2019-09-09

Section 5 says:

   [4] Section 5, requirement #9 dictates "Any proposed ForCES

It should say:

   [4] Section 4, requirement #9 dictates "Any proposed ForCES

Notes:

Incorrect reference to Section 5.

[Additional notes added at status change]
In fact The 5 to 4 change need to also be applied to these:
(see [4], Section 5, requirement #6)
(see [4] Section 5, requirement #11)
(See [4], Section 5, Requirement #3)
(see [4] Section 5, requirement #1)
(see [4] Section 5, requirements #12)
(see [4] Section 5, requirement #7)

Errata ID: 5338
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2018-04-27
Held for Document Update by: Martin Vigoureux
Date Held: 2019-09-09

Section 3.2 says:

   a change via asynchronous messages (see [4], Section 5, requirement
   #6).
...
   This architecture permits multiple FEs to be present in an NE.  [4]
   dictates that the ForCES Protocol must be able to scale to at least
   hundreds of FEs (see [4] Section 5, requirement #11).  Each of these
   FEs may potentially have a different set of packet processing
...
   When multiple FEs are present, ForCES requires that packets must be
   able to arrive at the NE by one FE and leave the NE via a different
   FE (See [4], Section 5, Requirement #3).  Packets that enter the NE

It should say:

   a change via asynchronous messages (see [4], Section 4, requirement
   #6).
...
   This architecture permits multiple FEs to be present in an NE.  [4]
   dictates that the ForCES Protocol must be able to scale to at least
   hundreds of FEs (see [4] Section 4, requirement #11).  Each of these
   FEs may potentially have a different set of packet processing
...
   When multiple FEs are present, ForCES requires that packets must be
   able to arrive at the NE by one FE and leave the NE via a different
   FE (See [4], Section 4, Requirement #3).  Packets that enter the NE

Notes:

Incorrect reference to Section 5.

see also: https://www.rfc-editor.org/verify_errata_select.php?eid=5338

Errata ID: 5339
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2018-04-27
Held for Document Update by: Martin Vigoureux
Date Held: 2019-09-09

Section 4.2.1 says:

   The ForCES Working Group has made a conscious decision that the first
   version of ForCES will be focused on "very close" CE/FE localities in
   IP networks.  Very Close localities consist of control and forwarding
   elements that are either components in the same physical box, or
   separated at most by one local network hop ([8]).  CEs and FEs can be
   connected by a variety of interconnect technologies, including
   Ethernet connections, backplanes, ATM (cell) fabrics, etc.  ForCES
   should be able to support each of these interconnects (see [4]
   Section 5, requirement #1).  When the CEs and FEs are separated
   beyond a single L3 routing hop, the ForCES Protocol will make use of
   an existing RFC 2914 [3] compliant L4 protocol with adequate
   reliability, security, and congestion control (e.g., TCP, SCTP) for
   transport purposes.

It should say:

   The ForCES Working Group has made a conscious decision that the first
   version of ForCES will be focused on "very close" CE/FE localities in
   IP networks.  Very Close localities consist of control and forwarding
   elements that are either components in the same physical box, or
   separated at most by one local network hop ([8]).  CEs and FEs can be
   connected by a variety of interconnect technologies, including
   Ethernet connections, backplanes, ATM (cell) fabrics, etc.  ForCES
   should be able to support each of these interconnects (see [4]
   Section 4, requirement #1).  When the CEs and FEs are separated
   beyond a single L3 routing hop, the ForCES Protocol will make use of
   an existing RFC 2914 [3] compliant L4 protocol with adequate
   reliability, security, and congestion control (e.g., TCP, SCTP) for
   transport purposes.

Notes:

https://www.rfc-editor.org/errata/eid5337

Errata ID: 5340
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2018-04-27
Held for Document Update by: Martin Vigoureux
Date Held: 2019-09-09

Section 4.3 says:

   FEs and CEs may join and leave NEs dynamically (see [4] Section 5,
   requirements #12).  When an FE or CE leaves the NE, the association
   with the NE is broken.  If the leaving party rejoins an NE later, to
   re-establish the association, it may need to re-enter the pre-
   association phase.  Loss of association can also happen unexpectedly
   due to a loss of connection between the CE and the FE.  Therefore,
   the framework allows the bi-directional transition between these two
   phases, but the ForCES Protocol is only applicable for the post-
   association phase.  However, the protocol should provide mechanisms
   to support association re-establishment.  This includes the ability
   for CEs and FEs to determine when there is a loss of association
   between them, and to restore association and efficient state
   (re)synchronization mechanisms (see [4] Section 5, requirement #7).
   Note that security association and state must also be re-established
   to guarantee the same level of security (including both
   authentication and authorization) exists before and after the
   association re-establishment.

It should say:

   FEs and CEs may join and leave NEs dynamically (see [4] Section 4,
   requirements #12).  When an FE or CE leaves the NE, the association
   with the NE is broken.  If the leaving party rejoins an NE later, to
   re-establish the association, it may need to re-enter the pre-
   association phase.  Loss of association can also happen unexpectedly
   due to a loss of connection between the CE and the FE.  Therefore,
   the framework allows the bi-directional transition between these two
   phases, but the ForCES Protocol is only applicable for the post-
   association phase.  However, the protocol should provide mechanisms
   to support association re-establishment.  This includes the ability
   for CEs and FEs to determine when there is a loss of association
   between them, and to restore association and efficient state
   (re)synchronization mechanisms (see [4] Section 4, requirement #7).
   Note that security association and state must also be re-established
   to guarantee the same level of security (including both
   authentication and authorization) exists before and after the
   association re-establishment.

Notes:

Incorrect reference to Section 5.

https://www.rfc-editor.org/errata/eid5337

RFC 3757, "Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", April 2004

Note: This RFC has been obsoleted by RFC 4033, RFC 4034, RFC 4035

Source of RFC: dnsext (int)

Errata ID: 4018
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2014-06-19
Held for Document Update by: Ted Lemon
Date Held: 2014-06-20

Section 1 says:

A SEP key either used to generate a
   DS RR or is distributed to resolvers that use the key as the root of
   a trusted subtree

It should say:

A SEP key _is_ either used to generate a
   DS RR or is distributed to resolvers that use the key as the root of
   a trusted subtree

Notes:

I am not a native english speaker so I may be wrong... But the first part of the sentence without a verb puzzles me.

I know that the RFC is theorically obsolete but RFC 4034 is very short on this secure entry point (SEP) and defers to the RFC 3757 it obsoletes.

RFC 3777, "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", June 2004

Note: This RFC has been obsoleted by RFC 7437

Note: This RFC has been updated by RFC 5078, RFC 5633, RFC 5680, RFC 6859

Source of RFC: nomcom (gen)

Errata ID: 232
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Frank Ellermann
Date Reported: 2006-08-31
Held for Document Update by: Tim Polk

Section 4 says:

  One possible selection method is described in RFC 2777 [1].

It should say:

  One possible selection method is described in RFC 3797 [1].

Notes:

References point to RFC 3797, not RFC 2777:
[1] Eastlake, 3rd, D., "Publicly Verifiable Nominations Committee
(Nomcom) Random Selection", RFC 3797, June 2004.

RFC 3797 has obsoleted RFC 2777

RFC 3779, "X.509 Extensions for IP Addresses and AS Identifiers", June 2004

Source of RFC: pkix (sec)

Errata ID: 7653
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Job Snijders
Date Reported: 2023-09-22
Held for Document Update by: Paul Wouters
Date Held: 2024-01-12

Section 3.2.3 says:

Section 3.2.3.8:
The ASRange type is a SEQUENCE consisting of a min and a max element,
and is used to specify a range of AS identifier values.

It should say:

Section 3.2.3.8:
The ASRange type is a SEQUENCE consisting of a min and a max element,
and is used to specify a range of AS identifier values. The min and max
elements MUST specify two distinct AS identifiers.

Notes:

The introduction in section 1 stresses that the objective of the encoding rules in section 2 and section 3
is to produce unique encoding and minimal size encoding of the information.

Allowing ASRanges where the minimum value is the same as the maximum value clearly violates the
objective of specifying a canonical form (in order to produce a unique representation); however the
specification as-is doesn't forbid min & max to be the same value. The corrected text addresses this.

Note: erratum edited per https://mailarchive.ietf.org/arch/msg/pkix/iZnCd58xgl1C47GSeFemAU9CF1g/

Errata ID: 1887
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Charles Bobo
Date Reported: 2009-09-21
Held for Document Update by: Tim Polk

Section References says:

   [RFC3513]   Hinden, R. and S. Deering, "Internet Protocol Version 6
               (IPv6) Addressing Architecture", RFC 3513, April 2003.

   [RFC3281]   Farrell, S. and R. Housley, "An Internet Attribute
               Certificate Profile for Authorization", RFC 3281, April
               2002.

   [S-BGP]     S. Kent, C. Lynn, and K. Seo, "Secure Border Gateway
               Protocol (S-BGP)," IEEE JSAC Special Issue on Network
               Security, April 2000.

It should say:

   [RFC3281]   Farrell, S. and R. Housley, "An Internet Attribute
               Certificate Profile for Authorization", RFC 3281, April
               2002.

   [RFC3513]   Hinden, R. and S. Deering, "Internet Protocol Version 6
               (IPv6) Addressing Architecture", RFC 3513, April 2003.

   [RFC4291]   R. Hinden, S. Deering, "IP Version 6 Addressing Architecture",
               RFC 4291, February 2006

   [S-BGP]     S. Kent, C. Lynn, and K. Seo, "Secure Border Gateway
               Protocol (S-BGP)," IEEE JSAC Special Issue on Network
               Security, April 2000.

Notes:

Section is "Informational References" but this doesn't fit in the Section field above.
References were out of alphabetical order -- RFC3281 should come before RFC3513.
Added reference RFC4291

RFC 3810, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", June 2004

Note: This RFC has been updated by RFC 4604

Source of RFC: magma (int)

Errata ID: 5977
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Toerless Eckert
Date Reported: 2020-02-05
Held for Document Update by: Eric Vyncke
Date Held: 2023-08-03

Throughout the document, when it says:

Notes:

I think PIM WG (which now owns this RFC) repeatedly re-confirmed in discussions that the intended interpretation of RFC3810 is that multicast receivers MUST report MLDv2 membership reports ALSO for link-local IPv6 addresses. Alas, this is still rejected by readers outside of PIM-WG, for example in current IESG review of a new new protocol spec that is stating that MLDv2 must be used to join the link-local IPv6 address of that protocol.

The problem seems to stem from the fact that there is no positively reaffirming text in MLDv2 RFC stating that MLDv2 MUST be used for all addresses scope 2..14 (except FF:01). Instead the text seems to only mentions exceptions (scope 0 and 1 and FF:01) unless i overlooked a passage explicitly reaffirming the need to use MLDv2 for scope 2.

Hence, this errata is editorial in nature to what i understand to be the desired meaning according to PIM-WG, but would be a technical change to what seems to be the interpretation by many implementers.


-------------- Verifier note --------
An errata is for minor change in well-defined sections. The proposed change is more global and should be addressed by a -bis or an update I-D.

Errata ID: 4773
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Lundkvist
Date Reported: 2016-08-11
Held for Document Update by: Alvaro Retana
Date Held: 2018-09-05

Section 5.1.6 says:

MISSING

It should say:

5.1.6.  Resv

   Initialized to zero by the sender; ignored by receivers.

Notes:

A description for the Resv field is missing. Section numbering indicates that this has been lost in editing.

== Alvaro Retana ==
Yes, §5.1.6 is missing. I think it is obvious that "Resv" and "Reserved" have the same meaning, so I'm disposing of this report to be considered when/if the document is updated.

RFC 3813, "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)", June 2004

Source of RFC: mpls (rtg)

Errata ID: 229
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stefan Winter
Date Reported: 2004-11-17
Held for Document Update by: Adrian Farrel

Description says:

       "For creating, modifying, and deleting this row.
        When a row in this table has a row in the active(1)
        state, no objects in this row except this object
        and the mplsXCStorageType can be modified. "

It should say:

       "For creating, modifying, and deleting this row.
        When a row in this table has a row in the active(1)
        state, no objects in this row except this object, the 
        mplsXCStorageType and the mplsXCAdminStatus can be modified."

RFC 3815, "Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)", June 2004

Source of RFC: mpls (rtg)

Errata ID: 3261
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Daniel Cohn
Date Reported: 2012-06-18
Held for Document Update by: Adrian Farrel

Section 3.5.9 says:

   The mplsLdpFecTable is a table which contains FEC (Forwarding
   Equivalence Class) information.  Each entry/row represents a single
   FEC Element.  There is also an LDP LSP FEC Table, mplsLdpLspFecTable,
   which associates FECs with the LSPs.

It should say:

   The mplsFecTable is a table which contains FEC (Forwarding
   Equivalence Class) information.  Each entry/row represents a single
   FEC Element.  There is also an LDP LSP FEC Table, mplsLdpLspFecTable,
   which associates FECs with the LSPs.

Notes:

Since draft-06 the mplsLdpFecTable has been renamed mplsFecTable

Errata ID: 3262
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Daniel Cohn
Date Reported: 2012-06-18
Held for Document Update by: Adrian Farrel

Section 4 says:

     mplsFecLastChange OBJECT-TYPE
         SYNTAX  TimeStamp
         MAX-ACCESS read-only
         STATUS current
         DESCRIPTION
             "The value of sysUpTime at the time of the most
             recent addition/deletion of an entry
             to/from the mplsLdpFectTable or
             the most recent change in values to any objects
             in the mplsLdpFecTable.

             If no such changes have occurred since the last
             re-initialization of the local management subsystem,
             then this object contains a zero value."
        ::= { mplsFecObjects 1 }

It should say:

     mplsFecLastChange OBJECT-TYPE
         SYNTAX  TimeStamp
         MAX-ACCESS read-only
         STATUS current
         DESCRIPTION
             "The value of sysUpTime at the time of the most
             recent addition/deletion of an entry
             to/from the mplsFecTable or
             the most recent change in values to any objects
             in the mplsFecTable.

             If no such changes have occurred since the last
             re-initialization of the local management subsystem,
             then this object contains a zero value."
        ::= { mplsFecObjects 1 }

Notes:

Since draft-06 mplsLdpFecTable has been renamed to mplsFecTable

RFC 3816, "Definitions of Managed Objects for RObust Header Compression (ROHC)", June 2004

Source of RFC: rohc (tsv)

Errata ID: 737
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-02-23
Held for Document Update by: Lars Eggert

 

1a)
  Section 4.1.2., near the bottom of page 5, says:

                                                  "...  But when
   accessing the rohcInstanceTable (and the rohcContextTable that shares
   a part of its index with the rohcInstanceTable) there are many cases
   where either a compressor contexts or a decompressor contexts are of
   interest.  ..."

  It should say:

                                                  "...  But when
   accessing the rohcInstanceTable (and the rohcContextTable that shares
   a part of its index with the rohcInstanceTable) there are many cases
|  where either a compressor context or a decompressor context are of
   interest.  ..."

1b)
  Section 4.3.1., near the bottom of page 8, says:

                 "...  For compressor contexts it optionally contains
   managed object containing the numbers of allowed and used packet
   sizes.  ..."

  It should say:

                 "...  For compressor contexts it optionally contains
|  managed objects containing the numbers of allowed and used packet
   sizes.  ..."


2) Textual issues in the ROHC-MIB definition

2a)
  The DESCRIPTION clause of the `RohcChannelIdentifierOrZero'
  TEXTUAL-CONVENTION (near the bottom of page 10),

         "A number identifying a channel.
          The value of 0 is indicates that
          no channel is identified."

   should be:

         "A number identifying a channel.
|         The value of 0 indicates that
          no channel is identified."

2b)
  The DESCRIPTION clause for `rohcChannelEntry' (extending from
  the last 2 lines on page 11 to page 12) contains inappropriate
  text -- obviously borrowed from the Script MIB (RFC 3165,
  page 18, last 3 lines) and unintentionally left un-edited:

     "An entry describing a particular script.  Every script that
      is stored in non-volatile memory is required to appear in
      this script table.

      Note ..."

  This should be replaced by appropriate text, e.g.,

|    "An entry describing a particular ROHC channel.

      Note ..."

  [ Please add whatever you consider appropriate here! ]

2c)
  The DESCRIPTION clause for `rohcChannelFeedbackFor', on page 13,
  seems to me to be not strict enough. Perhaps,

      "If no feedback information is transferred on this channel,
       then the value of this ID is 0.  If the channel type is set
       to notInUse(1), then the value of this object must be 0.
       If the channel type is rohc(2) and the value of this object
       is a valid channel ID, then feedback information is
       piggy-backed on the ROHC channel.  If the channel type is

  should be replaced by:

      "If no feedback information is transferred on this channel,
       then the value of this ID is 0.  If the channel type is set
       to notInUse(1), then the value of this object must be 0.
       If the channel type is rohc(2) and the value of this object
|      is non-zero, then feedback information for this channel is
|      piggy-backed and/or interspersed on the same ROHC channel;
|      hence the value of this object must be equal to the value
|      of the indexing rohcChannelID.  If the channel type is
       dedicatedFeedback(3), ..."

  [or similar].

  Rationale:
  As far as I understand RFC 3095 (Section 5.2.2 et al.),
  it is not possible to intersperse or/and piggyback feedback
  information of another channel on a ROHC channel carrying
  payload packets.

2d)
  The DESCRIPTION clause for `rohcInstanceVendor', on page 15,
  contains two issues. Its first sentence contains the word
  "description" instead of "compression", and the second sentence
  is subject to mis-interpretation due to unfortunate placement of
  the words "allocated for the vendor".
  I propose to change the text:

      "An object identifier that identifies the vendor who
       provides the implementation of robust header description.
       This object identifier SHALL point to the object identifier
       directly below the enterprise object identifier
       {1 3 6 1 4 1} allocated for the vendor. ...

  to better read:

      "An object identifier that identifies the vendor who
|      provides the implementation of robust header compression.
       This object identifier SHALL point to the object identifier
|      allocated for the vendor directly below the `enterprise'
|      object identifier {1 3 6 1 4 1}. ...


2e)
  The DESCRIPTION clause for `rohcInstanceContextStorageTime',
  on page 17, says:

                      ... .  The value of this object is used
     to initialize rohcContexStorageTime object when a new
     context is created.
     Changing ...

  where it should better say:

                      ... .  The value of this object is used
|    to initialize the rohcContexStorageTime object when a new
     context is created.
     Changing ...

2f)
  To better distinguish the counters for payload (i. e. IP) packets
  from the counters IR packets, I recommend to enhance the sentence:

      "Counter of all packets passing this instance."

  to read:

|     "Counter of all IP packets passing this instance."

  in the DESCRIPTION clauses of following two objects:

  o   `rohcInstancePackets'       (page 18),
  o   `rohcContextPackets'        (page 25).

2g)
  The DESCRIPTION clause for `rohcProfileVendor', on page 21,
  contains the same two issues as the DESCRIPTION clause for
  `rohcInstanceVendor'. Hence, the modification given above,
  under 2d), should be applied here as well.

2h)
  The DESCRIPTION clause for `rohcProfileNegotiated', on page 21,
  contains a small typo. It says:

     "When retrieved, this boolean object returns true
      if the profile has been negotiated to be used at
      the instance, i.e., is supported also be the
      corresponding compressor/decompressor."

  It should say:

     "When retrieved, this boolean object returns true
      if the profile has been negotiated to be used at
|     the instance, i.e., is supported also by the
      corresponding compressor/decompressor."

2i)
  The DESCRIPTION clause for `rohcContextStorageTime', on page 24,
  contains an improper self-reference. Therefore, replace the text:

               ... .  This object returns  the remaining time
      that the row may exist before it is aged out.  The object
      is initialized with the value of the  associated
      rohcContextStorageTime object.  After expiration ...

  by:

               ... .  This object returns the remaining time
      that the row may exist before it is aged out.  The object
      is initialized with the value of the associated
|     rohcInstanceContextStorageTime object.  After expiration ...

          ^^^^^^^^

2j)
  The DESCRIPTION clauses for `ContextAllPacketsMeanSize' and
  `rohcContextAllHeadersMeanSize', on page 28, are concluded with
  the sentence:

      The mean value is given in byte rounded to the next
      integer value."

  This should be:

      The mean value is given in bytes rounded to the next
      integer value."

  [ Note: I wished this RFC (and many other MIB RFCs, too) would
    make frequent use of the UNITS clause specified in STD 58 ! ]


3) Textual issues in the ROHC-RTP-MIB definition

3a)
  The DESCRIPTION clause for `rohcRtpContextNACKs', on page 42,
  says:

     "The number of all dynamic negative feedbacks (ACK) sent
      or received in this context, respectively.
      ..."

  It should say:

|    "The number of all dynamic negative feedbacks (NACK) sent
      or received in this context, respectively.
      ..."

3b)
  The DESCRIPTION clause for `rohcRtpContextSNACKs', on page 42,
  says:

     "The number of all static negative feedbacks (ACK) sent
      or received in this context, respectively.
      ..."

  It should say:

|    "The number of all static negative feedbacks (STATIC-NACK)
|     sent or received in this context, respectively.
      ..."

It should say:

[see above]

Notes:

from pending

RFC 3819, "Advice for Internet Subnetwork Designers", July 2004

Source of RFC: pilc (tsv)

Errata ID: 3051
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: tom petch
Date Reported: 2011-12-13
Held for Document Update by: Wes Eddy

Section 17 says:

e.g., to the Next-Hop Resolution Protocol [RFC2322

It should say:

e.g., to the Next-Hop Resolution Protocol [RFC2332

Notes:

RFC2322 is van den Hout, K., Koopal, A. and R. van Mook,"Management of IP numbers by peg-dhcp", RFC 2322, 1 April 1998.
RFC2332 is NBMA Next Hop Resolution Protocol (NHRP). J. Luciani, D. Katz, D.Piscitello, B. Cole, N. Doraswamy. April 1998

RFC 3820, "Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile", June 2004

Source of RFC: pkix (sec)

Errata ID: 2954
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Frank Cusack
Date Reported: 2011-08-31
Held for Document Update by: Sean Turner
Date Held: 2011-09-01

Section 5.1.2 says:

This implies that Steve must know in advance which other
identities may be involved in this distributed application, in
order to generate the appropriate ACs which are signed by Steve's
ECC.

It should say:

This implies that Steve must know in advance which other
identities may be involved in this distributed application, in
order to generate the appropriate ACs which are signed by Steve's
EEC.

Notes:

s/ECC/EEC/

Errata ID: 4039
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2014-07-03
Held for Document Update by: Kathleen Moriarty
Date Held: 2014-09-04

Section 7 says:

   OID                      Description
   ---                      -----------
   1.3.6.1.5.5.7.21.1       id-ppl-inheritALL
   1.3.6.1.5.5.7.21.2       id-ppl-independent

It should say:

   OID                      Description
   ---                      -----------
   1.3.6.1.5.5.7.21.0       id-ppl-anyLanguage
   1.3.6.1.5.5.7.21.1       id-ppl-inheritAll
   1.3.6.1.5.5.7.21.2       id-ppl-independent

Notes:

Two changes. First, include id-ppl-anyLanguage. Second, change "ALL" to "All"' to match the ASN.1 module.

RFC 3862, "Common Presence and Instant Messaging (CPIM): Message Format", August 2004

Source of RFC: impp (app)

Errata ID: 3625
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Sergio Garcia
Date Reported: 2013-05-17
Held for Document Update by: Barry Leiba
Date Held: 2013-06-10

Section ABNF defs says:

From-header = "From" ": " [ Formal-name ] "<" URI ">"
                        ; "From" is case-sensitive

It should say:

From-header = %d46 %d72 %d6f %d6g ": " [ Formal-name ] "<" URI ">"
                        ; "From" is case-sensitive

Notes:

All the ABNF from headers are not correct, from ABNF RFC:

Literal text is specified through the use of a string enclosed in quotation marks ("). These strings are case-insensitive and the character set used is (US-)ASCII. Therefore the string “abc” will match “abc”, “Abc”, “aBc”, “abC”, “ABc”, “AbC”, “aBC”, and “ABC”. For a case-sensitive match the explicit characters must be defined: to match “aBc” the definition will be %d97 %d66 %d99.

----------------------- Verifier notes -----------------------
This issue isn't limited to the From header, but applies throughout. However...

Customs for specifying ABNF have become more strict since RFC 3862 was written.
At the time of its writing, it was considered acceptable to use the mechanism here:
specify the string (which would normally be case-insensitive, according to RFC 2234)
and add a comment to note the case-sensitivity. In fact, it was specifically considered
more clear to do that than to specify sequences of hex characters. In addition to the
comments in the ABNF, this variance is noted in Sections 3 and 3.6:

<<
NOTE: Specified text values MUST be used as given, using exactly the
indicated upper- and lower-case letters. In this respect, the ABNF
usage here differs from RFC 2234 [6].
>>

Given that, this is clearly not an *error* in RFC 3862, though a different decision
might be made today, or whenever this document might be revised.

I am therefore marking this report as "held for document update".

Errata ID: 3011
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kaushik N V S
Date Reported: 2011-11-03
Held for Document Update by: Peter Saint-Andre

Section 5.2 says:

An Example Esing MIME multipart/signed

It should say:

An Example Using MIME multipart/signed

RFC 3875, "The Common Gateway Interface (CGI) Version 1.1", October 2004

Source of RFC: INDEPENDENT

Errata ID: 3556
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Christoph Anton Mitterer
Date Reported: 2013-03-18
Held for Document Update by: Nevil Brownlee
Date Held: 2014-02-03

Section 4.1.1 says:

   The AUTH_TYPE variable identifies any mechanism used by the server to
   authenticate the user.  It contains a case-insensitive value defined
   by the client protocol or server implementation.

   For HTTP, if the client request required authentication for external
   access, then the server MUST set the value of this variable from the
   'auth-scheme' token in the request Authorization header field.

      AUTH_TYPE      = "" | auth-scheme
      auth-scheme    = "Basic" | "Digest" | extension-auth
      extension-auth = token

   HTTP access authentication schemes are described in RFC 2617 [5].

It should say:

[see below]

Notes:

The current definition of AUTH_TYPE is flawed, namely then when several authentication methods have been used.
One example would be to have first some SSL/TLS client certificate authentication and then (afterwards) HTTP Basic Authentication.
Other examples are e.g. Apache HTTPD's SSL/FakeBasicAuth, where the SSL certs DN is mapped to the HTTP Basic Authentication username (i.e. the CGI REMOTE_USER variable).

Right now, AUTH_TYPE provides not syntax to encode several layers of authentication types, so the behaviour of webservers is basically undefined (e.g. Apache omits AUTH_TYPE in conjunction with SSL altogether (see https://issues.apache.org/bugzilla/show_bug.cgi?id=45058), which is also problematic, as much software depends on it).


I see two possible solutions:

1) Extend the syntax to allow lists of authentication types be specified.
A syntax like this would be possible:
<1st authentication type>;<2nd authentication type>;<3rd authentication type>
and so on, no trailing ";" required.
The ";" seems to be a possible largely backwards compatible separator as right now:
auth-scheme = "Basic" | "Digest" | extension-auth
extension-auth = token
with
token = 1*<any CHAR except CTLs or separators>
separator = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" |
"\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" |
"}" | SP | HT

In the example above (where first SSL client auth took place, then Basic auth) this would look like e.g. "TLS_client_certificate;Basic" (a name for SSL/TLS client certificate authentication would need to be found).


2) Define AUTH_TYPE explicitly to describe the authentication type at _plain_ HTTP level.
I would like this solution less, as it seems less mighty and future-proof.


Cheers,
Chris.

This erratum points out a flaw in RFC 3875, and suggests some improvements to it - of these, (1) seems the simplest. However, this change would require a new RFC, so I'm setting this to "Hold for update" now.

Nevil

Errata ID: 5880
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Zach Scott
Date Reported: 2019-10-23
Held for Document Update by: Adrian Farrel
Date Held: 2019-10-26

Section 4.3.2 says:

...that has a permanent affect, such a change in a database.

It should say:

...that has a permanent effect, such as a change in a database.

RFC 3877, "Alarm Management Information Base (MIB)", September 2004

Source of RFC: disman (ops)

Errata ID: 1819
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Enda Murphy
Date Reported: 2009-07-29
Held for Document Update by: Dan Romascanu

Section 5.2 says:

    -- The following are used with Processing error alarm.
                storageCapacityProblem (151),
                memoryMismatch  (152),
                corruptData  (153),
                outOfCPUCycles   (154),
                sfwrEnvironmentProblem  (155),
                sfwrDownloadFailure  (156),
                lossOfRealTimel (157),
    --A processing error alarm to be issued after the system has
    --reinitialised. This will indicate
    --to the management systems that the view they have of the managed
    --system may no longer
    --be valid. Usage example: The managed
    --system issues this alarm after a reinitialization with severity
    --warning to inform the
    --management system about the event. No clearing notification will
    --be sent.
                applicationSubsystemFailure (158),
                configurationOrCustomisationError (159),
                databaseInconsistency (160),
                fileError (161),
                outOfMemory (162),
                softwareError (163),
                timeoutExpired (164),
                underlayingResourceUnavailable (165),
                versionMismatch (166),
    --Values 168-200 are reserved for processing error alarm related
    -- probable causes.

It should say:

    -- The following are used with Processing error alarm.
                storageCapacityProblem (151),
                memoryMismatch  (152),
                corruptData  (153),
                outOfCPUCycles   (154),
                sfwrEnvironmentProblem  (155),
                sfwrDownloadFailure  (156),
                lossOfRealTime (157),
-- A processing error alarm to be issued if the system detects that it has lost the time in
-- the real time clock but  the clock itself is working. This could happen e.g. during a power 
-- cut in a small NE which does not have battery backup for the real time clock.
                reinitialized (158),
    --A processing error alarm to be issued after the system has
    --reinitialised. This will indicate
    --to the management systems that the view they have of the managed
    --system may no longer
    --be valid. Usage example: The managed
    --system issues this alarm after a reinitialization with severity
    --warning to inform the
    --management system about the event. No clearing notification will
    --be sent.
                applicationSubsystemFailure (159),
                configurationOrCustomisationError (160),
                databaseInconsistency (161),
                fileError (162),
                outOfMemory (163),
                softwareError (164),
                timeoutExpired (165),
                underlayingResourceUnavailable (166),
                versionMismatch (167),
    --Values 168-200 are reserved for processing error alarm related
    -- probable causes.

Notes:

It seems to be a copy/paste error from the M.3100 Standard PC text. The comment in the MIB after "lossOfRealTimel" (Note also rogue "l" at the end!) clearly refers to the PC string "reinitialized" instead. It is strange how the integers have continued on from 158 instead of retaining the original values, but anyway, it appears to be a mismatch between the two standards. Ironically I noticed it when I saw that "versionMismatch" had different values (166 and 167).

RFC 3886, "An Extensible Message Format for Message Tracking Responses", September 2004

Source of RFC: msgtrk (app)

Errata ID: 689
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2004-10-20
Held for Document Update by: Alexey Melnikov

Section 3.3.5, 3.3.6, 3.3.7 says:

(on page 7):

 a) in section 3.3.5 replace:

     "The Remote-MTA field is defined as in section Reference 2.3.5 of
      [RFC-DSN-STAT]." ...
                                                   ^^^^^^^^^^
    by:

     "The Remote-MTA field is defined as in section 2.3.5 of
      [RFC-DSN-STAT]." ...

 b) in section 3.3.6 replace:

     "The Last-Attempt-Date field is defined as in section Reference 2.3.7
      of [RFC-DSN-STAT]." ...
                                                          ^^^^^^^^^^
    by:

     "The Last-Attempt-Date field is defined as in section 2.3.7 of
      [RFC-DSN-STAT]." ...

 c) in section 3.3.7 replace:

     "The Will-Retry-Until field is defined as in section Reference 2.3.9
      of [RFC-DSN-STAT]." ...
                                                   ^^^^^^^^^^
    by:

     "The Will-Retry-Until field is defined as in section 2.3.9 of
      [RFC-DSN-STAT]." ...

It should say:

[see above]

Notes:

The first line of these sections seem to have inherited some
undue editing history inserting the appropriate references;
the word "Reference" should be removed in every case.

from pending

RFC 3891, "The Session Initiation Protocol (SIP) "Replaces" Header", September 2004

Source of RFC: sip (rai)

Errata ID: 213
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rb Srikanth
Date Reported: 2005-07-26
Held for Document Update by: Robert Sparks

Section 1 says:

  INVITE sip:bob@bobster.example.org
   To: <sip:bob@example.org>
   From: <sip:alice@phone2.example.org>;tag=8983
   Call-ID: 09870@phone2.example.org
   CSeq: 1 INVITE
   Contact: <sip:alice@phone2.example.org>
   Require: replaces
   Replaces: 425928@bobster.example.org;to-tag=7743;from-tag=6472
<mailto:425928@bobster.example.org;to-tag=7743;from-tag=6472>  

It should say:

  INVITE sip:bob@bobster.example.org
   To: <sip:bob@example.org>
   From: <sip:alice@phone2.example.org>;tag=8983
   Call-ID: 09870@phone2.example.org
   CSeq: 1 INVITE
   Contact: <sip:alice@phone2.example.org>
   Require: replaces
   Replaces: 425928@bobster.example.org;to-tag=8983;from-tag=7743
<mailto:425928@bobster.example.org;to-tag=8983;from-tag=7743>   

RFC 3923, "End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)", October 2004

Source of RFC: xmpp (app)

Errata ID: 2770
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Adam Wos
Date Reported: 2011-04-08
Held for Document Update by: Robert Sparks

Section 2 says:

   3.  The method MUST follow the required procedures (including the
       specific algorithms) defined in [CPIM] and [CPP].  In particular,
       these documents specify:

       *  Signing MUST use [SMIME] signatures with [CMS] SignedData.

       *  Encryption MUST use [SMIME] encryption with [CMS]
          EnvelopeData.
          ^^^^^^^^^^^^

It should say:

   3.  The method MUST follow the required procedures (including the
       specific algorithms) defined in [CPIM] and [CPP].  In particular,
       these documents specify:

       *  Signing MUST use [SMIME] signatures with [CMS] SignedData.

       *  Encryption MUST use [SMIME] encryption with [CMS]
          EnvelopedData.

RFC 3926, "FLUTE - File Delivery over Unidirectional Transport", October 2004

Note: This RFC has been obsoleted by RFC 6726

Source of RFC: rmt (tsv)

Errata ID: 698
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2004-11-10
Held for Document Update by: Magnus Westerlund

 

(1) On page 31, the Informative Reference "[21]" is inconsistent;
    author, title, and publication month / year match RFC 2047,
    *not* "RFC 1521" as stated there.

(2) The first use of reference "[21]" appears on page 27, in the
    10th line of the 2nd paragraph. There, "RFC 2047" _might_ be
    what you meant (together with [20] pointing to RFC 2048).

    Now, unfortunately, the current basic MIME specifications,
    RFC 2045..2049, do not contain a substantial general
    discussion of security issues.

    The RFC 2045 and RFC 2049 "Security Considerations" just
    refer to RFC 2046.
    But RFC 2046 for this purpose refers to two specific media
    type explanations / 'informal registrations' contained in
    the body of that memo, and to RFC 2048, which in turn
    does *NOT* contain a "Security Considerations" section.
(NB:
    - RFC 2048 just describes the registration PROCEDURES and
      states the Security Considerations *requirement* for any
      such registrations.
    - The formal ['skeleton'] Registrations for the basic MIME
      content types / subtypes from RFC 1521 - Appendix F -
      unfortunately have been lost on their [expected] way
      into RFC 2046. )

    RFC 2047, in particular, is an extreme:
      "Security issues are not discussed in this memo."
    (Section 10 on page 14).

    Therefore I suspect that "RFC 2047" might indeed NOT be
    what you wanted to refer to in loc. cit.  Perhaps the
    combination of RFC 2046 and RFC 2048 would have been
    the most appropriate selection for this citation.

(3) The second use of reference "[21]" in RFC 3926 appears
    2 lines further down in the same paragraph on page 27,
    explicitely referring to RFC 1521.
    The final statement there on RFC 1521,
       "... even though its protocol is obsoleted 
       by RFC 2048 [20]."

    as well does not seem to be very appropriate for me:
    It might be disputable whether one should talk about a
    "protocol" when talking about message/document format
    descriptions, but more substantially, the major part
    of RFC 1521 has been superseded by RFC 2046 - see (2)
    above - while RFC 2048 only supersedes Appendix E of
    RFC 1521, which at the time of its publication already
    had been "updated" (i.e. obsoleted) by RFC 1590.

Therefore, it might be appropriate to replace the impacted
bad Informative Reference citation [21] on page 31 of RFC 3926
by two citations (e.g. [21]' and [23]), one for RFC 1521 and
one for RFC 2046, and to modify the above mentioned phrase.

It should say:

[see above]

Notes:

from pending

RFC 3929, "Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF", October 2004

Note: This RFC has been updated by RFC 8717

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: gen

Errata ID: 5525
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Jason Livingood
Date Reported: 2018-10-15
Held for Document Update by: Lars Eggert
Date Held: 2021-03-11

Section 4.1.1 says:

the IETF executive director.

It should say:

the Managing Director, IETF Secretariat.

Notes:

The definition of what the IETF Executive Director is has changed under IASA2. This correction reflects the new job definition and title.

Errata ID: 5526
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Jason Livingood
Date Reported: 2018-10-15
Held for Document Update by: Lars Eggert
Date Held: 2021-03-11

Section 4.3 says:

the IETF Executive Director within

It should say:

the Managing Director, IETF Secretariat, within

Notes:

The definition of what the IETF Executive Director is has changed under IASA2. This correction reflects the new job definition and title.

Errata ID: 5527
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Jason Livingood
Date Reported: 2018-10-15
Held for Document Update by: Lars Eggert
Date Held: 2021-03-11

Section 4.3 says:

The IETF Executive Director then uses 

It should say:

The Managing Director, IETF Secretariat, then uses 

Notes:

The definition of what the IETF Executive Director is has changed under IASA2. This correction reflects the new job definition and title.

Errata ID: 4342
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Greg Skinner
Date Reported: 2015-04-21
Held for Document Update by: Lars Eggert
Date Held: 2021-03-11

Section 8.2 says:

[VOTE]     Center for Democracy and Voting. "Frequently Asked
              Questions about IRV", http://www.fairvote.org/irv/faq.htm.

It should say:

[VOTE]     Center for Democracy and Voting.
               "Frequently Asked Questions about IRV",
               http://www.fairvote.org/reforms/instant-runoff-voting/
               instant-runoff-voting-faq/

Notes:

This is a correction of the link to the Instant Runoff Voting FAQ to its current location.

RFC 3931, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", March 2005

Note: This RFC has been updated by RFC 5641

Source of RFC: l2tpext (int)

Errata ID: 3766
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Chaz Granholm
Date Reported: 2013-10-26
Held for Document Update by: Brian Haberman
Date Held: 2013-10-29

Section 8.2.3 says:

Further, it is far easier to change a compromised L2TPv3
   Cookie than a compromised IP address," and a cryptographically random
   [RFC1750] value is far less likely to be discovered by brute-force
   attacks compared to an IP address.

It should say:

Further, it is far easier to change a compromised L2TPv3
   Cookie than a compromised IP address, and a cryptographically random
   [RFC1750] value is far less likely to be discovered by brute-force
   attacks compared to an IP address.

Notes:

Erroneous quotation mark.

Errata ID: 6273
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Casper van Eersel
Date Reported: 2020-09-02
Held for Document Update by: Eric Vyncke
Date Held: 2020-09-03

Section 4.3 says:

See Section 5.4.3 for details on calculation of the Message Digest and construction of the Control Message Authentication Nonce and Message Digest AVPs.

It should say:

See Section 5.4.1 for details on calculation of the Message Digest and construction of the Control Message Authentication Nonce and Message Digest AVPs.

Notes:

The explanation of the (HMAC etc.) details is given in 5.4.1, not 5.4.3.

--- Reviewer / AD note ---
While the errata is correct, it does not impact implementation and is not really confusing so the status of 'verified' for IETF steam is not the right state.

Errata ID: 6274
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Casper van Eersel
Date Reported: 2020-09-02
Held for Document Update by: Eric Vyncke
Date Held: 2020-09-03

Section 4.3 says:

The integrity check is calculated as in Section 5.4.3, with an empty zero-length shared secret, local nonce, and remote nonce.

It should say:

The integrity check is calculated as in Section 5.4.1, with an empty zero-length shared secret, local nonce, and remote nonce.

Notes:

The calculation is covered in section 5.4.1.

--- Review AD note ---
While the errata is correct, it does not impact implementation and is not really confusing so the status of 'verified' for IETF steam is not the right state.

Errata ID: 6275
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Casper van Eersel
Date Reported: 2020-09-02
Held for Document Update by: Eric Vyncke
Date Held: 2020-09-03

Section 6.5 says:

See Section 4.2 for a description of the keepalive mechanism.

It should say:

See Section 4.4 for a description of the keepalive mechanism.

Notes:

Incorrect reference to section 4.2.

--- Reviewer / AD note ---
While the errata is correct, it does not impact implementation and is not really confusing so the status of 'verified' for IETF steam is not the right state.

RFC 3935, "A Mission Statement for the IETF", October 2004

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 7616
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Brian Carpenter
Date Reported: 2023-08-25
Held for Document Update by: RFC Editor
Date Held: 2024-04-09

Section 1 says:

Technical competence - the issues on which the IETF produces its
      documents are issues where the IETF has the competence needed to
      speak to them, and that the IETF is willing to listen to
      technically competent input from any source.

It should say:

Technical competence - the issues on which the IETF produces its
      documents are issues where the IETF has the competence needed to
      speak to them, and where the IETF is willing to listen to
      technically competent input from any source.

Notes:

The word "that" was the wrong part of speech and referred to nothing.
(I am reporting this now because this clause has been quoted at https://www.ietf.org/about/introduction/ where it jumped out at me.)

===RFC Editor Notes===
Another possible way to update:

Technical competence - the IETF produces its documents on issues
for which it has the competence needed to speak to them and the
willingness to listen to technically competent input from any source.

RFC 3939, "Calling Line Identification for Voice Mail Messages", December 2004

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 708
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-01-04
Held for Document Update by: Peter Saint-Andre

Section 8 says:

according to BCP 90
(= RFC 3864), the new IMAIL Header Fields, "Caller-ID" and
"Caller-Name", as well should get formal IANA registrations listed
in the RFC, using the templates from section 4.2. of RFC 3864 !

It should say:

[none submitted]

Notes:

Perhaps, a citation to BCP 90 would also have been appropriate.

from pending

Errata ID: 709
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-01-04
Held for Document Update by: Alexey Melnikov
Date Held: 2010-07-24

 

Minor textual improvements:

a) Change the first line of section 6.1., on page 6, from

  "The intent of these headers are to record telephone number that is
   sent by the analog phone system with an incoming call without
   alteration or interpretation." ...

to:

| "The intent of these headers are to record the telephone number that
                                             ^^^
   is sent by the analog phone system with an incoming call without
   alteration or interpretation." ...

b) In the first line of section '10. Acknowledgments', on page 9,
change:

  "The previous authors of versions of this document were Derrick Dunne
   and Jason Collins." ...

to:

| "The authors of previous versions of this document were Derrick Dunne
   and Jason Collins." ...

It should say:

[see above]

RFC 3942, "Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options", November 2004

Source of RFC: dhc (int)

Errata ID: 3204
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2012-04-27
Held for Document Update by: Ralph Droms

Section 6. IANA Cons says:

   4. change the listing of any options listed as "Tentatively-Assigned"
|     to "Unavailable" 18 months from this RFC's publication date and
      periodically thereafter as long as there is an option listed as
      "Tentatively-Assigned", if no un-expired Internet-Draft exists
      documenting the usage.

It should say:

   4. change the listing of any options listed as "Tentatively-Assigned"
|     to "Unassigned" 18 months from this RFC's publication date and
      periodically thereafter as long as there is an option listed as
      "Tentatively-Assigned", if no un-expired Internet-Draft exists
      documenting the usage.

Notes:

The body of the RFC clearly states in Section 4, bullet 4.
that the IANA action desired by the RFC is to make these code
points available for assignment after the 18-month grace period.

This Errata Note is tagged as "Technical" because the inconsistency
between the IANA Considerations and the body of the RFC apparently
has caused IANA to not follow the body and spirit of the RFC -- at
the time this Errata Note is being filed, there are several entries
left in the BOOTP+DHCP parameters option codes registry that should
have been cleaned up and made available for assignment since the
publication of RFC 3942 in November 2004.

RFC 3944, "H.350 Directory Services", December 2004

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 707
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-01-04
Held for Document Update by: Alexey Melnikov
Date Held: 2010-05-11

 

One general inconsistency observed throughout the text, is related
to the use of 'architecture' (singular) vs. 'architectures' (plural).
Since the H.350 series recommendations describe a *single*
[LDAP directory] architecture [extension], I propose to modify the
text to use the singular form in a consistent manner as noted below.

Further, there are a lot of places where I miss expected articles
('the' / 'a' / 'an') -- even in the text that is said to be copied
from the ITU-T Recommendations.
(1)

Change the first 4 (identical) lines of
-  'Abstract' on page 1,  and
-  '1. Scope' on page 3, from :

  "The International Telecommunications Union Standardization Sector
   (ITU-T) has created the H.350 series of Recommendations that specify
   directory services architectures in support of multimedia
   conferencing protocols.  The goal of the architecture is to" ...
                                        ^^^^^^^^^^^^^^^^!!
to:

  "The International Telecommunications Union Standardization Sector
   (ITU-T) has created the H.350 series of Recommendations that specify
|  a directory services architecture in support of multimedia
   conferencing protocols.  The goal of the architecture is to" ...


(2)

Change the second paragraph of '1. Scope' on page 3:

  "H.350 architectures are not intended to change the operation of
   multimedia conferencing protocols in any way.  Rather, they are meant
   to standardize the way the already defined protocol elements are
   stored in a directory, so that they can be accessed in a standardized
   manner."

to:

| "The H.350 architecture is not intended to change the operation of
|  multimedia conferencing protocols in any way.  Rather, it is meant
   to standardize the way the already defined protocol elements are
   stored in a directory, so that they can be accessed in a standardized
   manner."


(3)

In lines 2..4 of '4.1. Scope' on page 4, change:

                                   ... "Standardized directory services
   can support association of persons with endpoints, searchable white
   pages, and clickable dialling."  ...

to:

                                   ... "Standardized directory services
|  can support the association of persons with endpoints, searchable white
   pages, and clickable dialling."  ...


(4)

In the bottom half of the second paragraph of section 4.1. on
page 5, change:
                                                  ... "Each of these
   disparate systems can access the same underlying data source,
   reducing or eliminating the need to coordinate separate management of
   each system.  A significant benefit to the user is that the
   management of this data can be incorporated into existing customer
   management tools, allowing for quick and flexible scaling up of
   applications.  Indeed, many technology providers have already
   incorporate LDAP into their products, but have been forced to do so
   without benefit of a standardized schema." ...

to:
                                                  ... "Each of these
   disparate systems can access the same underlying data source,
|  reducing or eliminating the need to coordinate the separate management
   of each system.  A significant benefit to the user is that the
   management of this data can be incorporated into existing customer
   management tools, allowing for quick and flexible scaling up of
   applications.  Indeed, many technology providers have already
   incorporate LDAP into their products, but have been forced to do so
|  without the benefit of a standardized schema." ...


(5)

In lines 3..7 of the forth paragraph of section 4.1. on page 5,
change:
                                                 ... "LDAP provides a
   convenient storage location that can be accessed by both call server
   and endpoint; thus it is possible to use the directory to support
   endpoint configuration, which is important for simplified operation
   and supporting user mobility."

to:
                                                 ... "LDAP provides a
   convenient storage location that can be accessed by both call server
|  and endpoint; thus it is possible to use the directory to support the
   endpoint configuration, which is important for simplified operation
   and supporting user mobility."


(6)

In the bottom half of the sixth paragraph of section 4.1. on page 6,
change:
                                ... "Similarly, commObject contains a
   pointer, called commOwner, which points to the individual or resource
   that is associated with the commObject.  In this way, people or
   resources can be associated with endpoints.  The only change required
   in the enterprise directory is the addition of the simple object
   class commURI.  CommObject data may be instantiated in the same or in
   entirely separate directories, thus allowing flexibility in
   implementation."

to:

|                               ... "Similarly, each commObject contains a
   pointer, called commOwner, which points to the individual or resource
   that is associated with the commObject.  In this way, people or
   resources can be associated with endpoints.  The only change required
|  to the enterprise directory is the addition of the simple object
   class commURI.  CommObject data may be instantiated in the same or in
|  an entirely separate directory, thus allowing flexibility in
   implementation."


(7)

In the first lines of the final paragraph of section 4.1.2.1,
on page 9, change:

  "Note that this example and approach demonstrate extension of the
   general commObject object class, and not any individual H.350.x
   classes." ...

to:

| "Note that this example and approach demonstrate an extension of the
   general commObject object class, and not any individual H.350.x
   classes." ...


(8)

In the first line of section 4.2., on page 10, change:

  "Auxiliary object class that contains the commURI attribute." ...

to:

| "An Auxiliary object class that contains the commURI attribute." ...


(9)

Change the 'definition' clause of section 5.2.4., on page 20, from:

       "Address which specifies the domain location of SIP proxy within
   a domain.  RFC 3261 defines the role of the SIP proxy."

to:

|      "Address which specifies the domain location of a SIP proxy within
   a domain.  RFC 3261 defines the role of the SIP proxy."


(10)

In the first two lines of the second paragraph of section 7.,
on page 27, change:

  "H.350 does not alter the security architectures of any particular
   protocol."

to:

| "H.350 does not alter the security architecture of any particular
   protocol."

It should say:

[see above]

RFC 3959, "The Early Session Disposition Type for the Session Initiation Protocol (SIP)", December 2004

Source of RFC: sipping (rai)

Errata ID: 2050
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Daniel Rudolph
Date Reported: 2010-02-24
Held for Document Update by: Robert Sparks

Section 3 says:

UASs using the offer/answer exchange that will carry regular media
for sending and receiving early media can cause media clipping, as
described in Section 2.1.1 of [8].

It should say:

UASs using the offer/answer exchange that will carry regular media 
for sending and receiving early media can cause media clipping, as 
described in Section 2 of [8].

Notes:

There is no section 2.1.1 in RFC 3960 (=reference [8]).

RFC 3961, "Encryption and Checksum Specifications for Kerberos 5", February 2005

Note: This RFC has been updated by RFC 8429

Source of RFC: krb-wg (sec)

Errata ID: 6973
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Paul Miller
Date Reported: 2022-05-12
Held for Document Update by: Paul Wouters
Date Held: 2024-01-16

Section 6.2 says:

6.2.1:

   key-generation seed      8 bytes
   length

   random-to-key            des_random_to_key

6.2.2:

   key-generation seed      8 bytes
   length

   random-to-key            copy input, then fix parity bits

6.2.3:

   key-generation seed      8 bytes
   length

   random-to-key            copy input, then fix parity bits

It should say:

All sections:

   key-generation seed      7 bytes
   length

   random-to-key            des_random_to_key

Notes:

Section 6.2 describes the random-to-key operation as:

For generation of a key from a random bitstring, we start with a 56-
bit string and, as with the string-to-key operation above, insert
parity bits. If the result is a weak or semi-weak key, we modify it
by eXclusive-OR with the constant 0x00000000000000F0:

des_random_to_key(bitstring) {
return key_correction(add_parity_bits(bitstring));
}

For 6.2.1, the input should be 56-bits, not 64.
For 6.2.2 and 6.2.3, the random-to-key must also correct weak keys and not just the parity as currently described.

Of course, this is all purely of academic interest as the 10-year anniversary of RFC6649 deprecating single DES is coming up in a couple of weeks. The distinction between a "weak" single DES key and a correctly generated random key only matters if your adversary is restricted to using graphing calculators.

RFC 3965, "A Simple Mode of Facsimile Using Internet Mail", December 2004

Source of RFC: fax (app)

Errata ID: 206

Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-01-04
Held for Document Update by: Peter Saint-Andre
Report Text:

   
The Normative Reference [3] should be deleted from section 6.1., on page 10.

Rationale:   
   References [1] and [2] from RFC 2305 have been updated, from
   pointers to RFC 821 and RFC 822, to pointers to RFC 2821 and
   RFC 2822, respectively.  The (normative) updates to RFC 821 and RFC 822 contained in
   STD 3, RFC 1123 [3], have been incorporated into RFC 2821
   and RFC 2822, respectively, which obsolete their predecessors.
   Hence, the reference to RFC 1123 is no more needed in RFC 3965,
   and in fact it is not mentioned in the textual body any more.

---

Errata ID: 711
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-01-04
Held for Document Update by: Alexey Melnikov

 

a) Change the first sentence of section 2.1.3, on page 4, from:

  "An offramp gateway that operate as an MTA serving multiple users
   SHOULD use SMTP;" ...

to:

| "An offramp gateway that operates as an MTA serving multiple users
   SHOULD use SMTP;" ...

b) Change the first sentence of section 2.2.4, on page 4, from:

  "A single multi-page document SHOULD be sent as a single multi- page
   TIFF file, even though recipients MUST process multipart/mixed
   containing multiple TIFF files."

to:

| "A single multi-page document SHOULD be sent as a single multi-page
   TIFF file, even though recipients MUST process multipart/mixed
   containing multiple TIFF files."

c) Change section 5.1. on page 6 from:

  "This specification is based on use of existing Internet mail.  To
   maintain interoperability with Internet mail, any security to be
   provided should be part of the of the Internet security
   infrastructure, rather than a new mechanism or some other mechanism
   outside of the Internet infrastructure."

to:

| "This specification is based on the use of existing Internet mail.
   To maintain interoperability with Internet mail, any security to be
|  provided should be part of the Internet security infrastructure,
   rather than a new mechanism or some other mechanism outside of the
   Internet infrastructure."

d) Change the final sentence of section 5.2, on page 6, from:

                 ... "This section reviews relevant concerns about
   Internet mail for IFax environments, as well as considering the
   potential problems which can result of integrating the existing G3Fax
   service with Internet mail."

to:
                 ... "This section reviews relevant concerns about
   Internet mail for IFax environments, as well as considering the
|  potential problems which can result from integrating the existing
   G3Fax service with Internet mail."

e) Change the first paragraph of section 5.2.1, on page 6, from:

   "The actual sender of the message might not be the same as that
   specified in the Sender or From fields of the message content headers
   or the MAIL FROM address from the SMTP envelope."

to:

   "The actual sender of the message might not be the same as that
   specified in the Sender or From fields of the message content headers
|  or the MAIL FROM address in the SMTP envelope."

f) Change the second-to-last paragraph of section 5.2.2, on page 7,
from:

  "Originator authentication entails the use of weak or strong
   mechanisms, such as cleartext keywords or encryption-based
   data-signing, respectively, to determine and validate the identify
   of the sender and assess permissions accordingly."

to:

  "Originator authentication entails the use of weak or strong
   mechanisms, such as cleartext keywords or encryption-based
|  data-signing, respectively, to determine and validate the identity
   of the sender and assess permissions accordingly."

g) Change the first sentence of the last paragraph of section 5.2.3,
on page 8, from:

  "Typically authorization needs to be associated to specific senders
   and specific messages, in order to prevent a "replay" attack which
   causes and earlier authorization to enable a later dial-out by a
   different (and unauthorized) sender." ...

to:

| "Typically authorization needs to be associated with specific senders
   and specific messages, in order to prevent a "replay" attack which
|  causes an earlier authorization to enable a later dial-out by a
   different (and unauthorized) sender." ...

It should say:

[see above]

Notes:

from pending

RFC 3966, "The tel URI for Telephone Numbers", December 2004

Note: This RFC has been updated by RFC 5341

Source of RFC: iptel (rai)

Errata ID: 702
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2004-12-04
Held for Document Update by: Robert Sparks

Section 12 says:

Fate of "fax" and "modem" URI schemes

RFC 3966 re-defines the "tel" URI scheme and obsoletes RFC 2806
which defined (and registered) three URI schemes: "tel", "fax",
and "modem". Section 12 of RFC 3966 (on page 15) merely states:

"references to ... fax and modem URIs ... have been removed."


There are *no* IANA considerations included in RFC 3966 regarding
the latter URIs.

Hence it is not clear whether these URIs are to be regarded as
informally "deprecated" or "de-registered" by this RFC, and therefore
should be marked accordingly in the IANA 'URI Schemes' reqistry.

If however, by existing policy, URI schemes cannot be "deprecated"
or "de-registered", the RFC 3966 meta-information should be changed
to say "Updates: 2806" instead of "Obsoletes: 2806", and another
errata note should be filed to change the RFC 3966 heading
accordingly, to avoid the situation of having no more 'valid'
documentation for two registered URI schemes.

It should say:

[see above] 

Notes:

The fate of the "fax" and "modem" URI schemes should be made clear,
formally, and in an appropriate way.

Henning Schulzrinne:
Requires discussion in the IPTEL working group, where I suggest you
take this discussion. I have my personal opinions as to the deployment
and deployability of the 'fax' URI scheme, but that's not particularly
relevant. I suspect a separate document that performs the appropriate
designation (e.g., historical) would be called for, rather than changing
3996.


from pending

Errata ID: 4376
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: OKUMURA Shinji
Date Reported: 2015-05-26
Held for Document Update by: Ben Campbell
Date Held: 2015-06-09

Section 3 says:

phonedigit           = DIGIT / [ visual-separator ]
phonedigit-hex       = HEXDIG / "*" / "#" / [ visual-separator ]

It should say:

phonedigit           = DIGIT / visual-separator;
phonedigit-hex       = HEXDIG / "*" / "#" / visual-separator;

Notes:

An optional and alternative rule is typically meaningless.

RFC 3970, "A Traffic Engineering (TE) MIB", January 2005

Note: This RFC has been updated by RFC 9141

Source of RFC: Legacy
Area Assignment: ops

Errata ID: 734
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-02-25
Held for Document Update by: joel jaeggli
Date Held: 2017-03-29

Section 5, page 16 says:

   teTunnelLPOctets OBJECT-TYPE
       SYNTAX       Counter32
       MAX-ACCESS   read-only
       STATUS       current
       DESCRIPTION "The number of octets that have been forwarded over
                    the Tunnel.

                    Discontinuities in the value of this counter can
                    occur at re-initialization of the management system
                    and at other times, as indicated by the value of
                    teTunnelDiscontinuityTimer.
                   "
       ::= { teTunnelEntry 14 }

   teTunnelLPPackets OBJECT-TYPE
       SYNTAX       Counter32
       MAX-ACCESS   read-only
       STATUS       current
       DESCRIPTION "The number of packets that have been forwarded over
                    the Tunnel.
                    Discontinuities in the value of this counter can
                    occur at re-initialization of the management system
                    and at other times, as indicated by the value of
                    teTunnelDiscontinuityTimer.
                   "
       ::= { teTunnelEntry 15 }

It should say:

[not submitted]

Notes:

The DESCRIPTION clauses of
- teTunnelOctects and teTunnelLPOctects
- teTunnelPackets and teTunnelLPPackets
are pairwise identical, respectively.

There is no precise description of the precise meaning of
these "teTunnelLPxxx" objects.
Admittedly, one might guess from the SYNTAX clauses of these
objects that "LP" stands for 'lower part' -- meaning that the
value of a "teTunnelLPOctets" object should always equal the
value of the corresponding "teTunnelOctets" object MODULO 2^32
(and similarly for the "...Packets" objects), but this is not
stated in the text.

Furthermore, unfortunately the naming of these objects does
not conform to the conventional naming style used in (almost)
all IETF standards track MIB modules with High Capacity
counters, e. g. "xxxOctets" and "xxxHCOctets" .
The above interpretation would be more manifest if this
standard naming convention would have been followed.

Now, given that the naming of the objects cannot be changed
any more, it would certainly be useful to have a textual
clarification of these DESCRIPTIONs posted on the RFC Editor's
RFC-Errata web page.

[from pending]

RFC 3971, "SEcure Neighbor Discovery (SEND)", March 2005

Note: This RFC has been updated by RFC 6494, RFC 6495, RFC 6980

Source of RFC: send (int)

Errata ID: 3536
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-14
Held for Document Update by: Ralph Droms
Date Held: 2013-03-10

Section 6.4.1 says:

|     ICMP length (derived from the IP length) MUST be 8 or more octets.

It should say:

|  The ICMP length (derived from the IP length) MUST be greater than 8
   octets.

Notes:

The last paragraph of Section 6.4.1, at the bottom of page 31, has several issues.

First of all, this sentence apparently does *not* belong to the
discussion of `Valid Options` above it; hence, it should be indented
one step less.

Next, I propose to add an initial article, 'The'.

But most importantly, I suspect that the ICMP lenght specification,
>= 8 , in fact should be: > 8 .
Unfortunately I cannot find a precise statement specifying clearly
that the Trust Anchor option is mandatory in the Certification Path
Solicitation Message, but the explanation 9 lines before the end of
the section,

The first (or only) Trust Anchor option MUST contain a DER
Encoded X.501 Name; see Section 6.4.3.

IMHO in fact does imply this.

If that is correct, the final line should be updated as above.

Ralph Droms - verifier note:

As the current text is not incorrect and there is some question about the issue, I will mark the errata as "hold for document update"

Errata ID: 960
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-14
Held for Document Update by: Ralph Droms

Section 2 says:

   Neighbor Discovery Protocol (NDP)

|     The IPv6 Neighbor Discovery Protocol [7, 8].

      The Neighbor Discovery Protocol is a part of ICMPv6 [6].

It should say:

   Neighbor Discovery Protocol (NDP)

|     The IPv6 Neighbor Discovery Protocol [4, 5].

      The Neighbor Discovery Protocol is a part of ICMPv6 [6].

Notes:

wrong reference tags. See Section 12.1, on page 50; the proper references are RFC 2461 [4] and RFC 2462 [5].

Errata ID: 3533
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-14
Held for Document Update by: Ralph Droms

Section 2 says:

   Non-SEND node

      An IPv6 node that does not implement this specification but uses
      only the Neighbor Discovery protocol defined in RFCs 2461 and
|     2462, as updated, without security.

It should say:

   Non-SEND node

      An IPv6 node that does not implement this specification but uses
      only the Neighbor Discovery protocol defined in RFCs 2461 and
|     2462, without security.

Notes:

Perhaps, there once was a reference to some work in progress,
e.g., what has become RFC 4311, or the 2461bis and 2462bis I-Ds,
and this reference was been removed only partially. Cleanup!
For an alternative text change, see the next item.

Errata ID: 3534
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-14
Held for Document Update by: Ralph Droms

Section 3 says:

                         [...]  This section is not normative, and if
   this section and the original Neighbor Discovery RFCs are in
|  conflict, the original RFCs, as updated, take precedence.

It should say:

                         [...]  This section is not normative, and if
   this section and the original Neighbor Discovery RFCs are in
|  conflict, the original RFCs, or any updates to these, take
   precedence.

Notes:

It is unclear what has been intended here. The rationale for Errata ID 3533
might apply here as well.

Errata ID: 3537
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-14
Held for Document Update by: Ralph Droms
Date Held: 2013-03-10

Section 6.4.2 says:

   The ICMP length (derived from the IP length) MUST be 8 or more
   octets.

It should say:

   The ICMP length (derived from the IP length) MUST be greater than 8
   octets.

Notes:

Similar to the rationale for Errata ID 3536, I suspect that
the Certification Path Advertisement Message will always include
at least one Option.

Errata ID: 3541
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-14
Held for Document Update by: Ralph Droms

Section 6.4.6 says:

   If there are multiple missing certificates, additional CPS
|  messages can be sent after getting a response to first one.  However,
   the complete retrieval process may last at most CPS_RETRY_MAX
   seconds.

It should say:

   If there are multiple missing certificates, additional CPS
|  messages can be sent after getting a response to the first one.
   However, the complete retrieval process may last at most
   CPS_RETRY_MAX seconds.

Notes:

missing article

Errata ID: 3542
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-14
Held for Document Update by: Ralph Droms
Date Held: 2013-03-10

Section 7.4 says:

   This specification also does not apply to addresses
|  generated by the IPv6 stateless address autoconfiguration from a
   fixed interface identifiers (such as EUI-64).

...

|  The Target Address in Neighbor Advertisement is required to be equal
   to the source address of the packet, except in proxy Neighbor
   Discovery, which is not supported by this specification.

It should say:

   This specification also does not apply to addresses
|  generated by the IPv6 stateless address autoconfiguration from fixed
   interface identifiers (such as EUI-64).

...

|  The Target Address in a Neighbor Advertisement is required to be
   equal to the source address of the packet, except in proxy Neighbor
   Discovery, which is not supported by this specification.

Notes:

a spurious article and 2 missing articles

Verifier note (Ralph Droms): The first fix still isn't correct; should be:


This specification also does not apply to addresses
| generated by IPv6 stateless address autoconfiguration from fixed
interface identifiers (such as EUI-64).

Errata ID: 3543
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-14
Held for Document Update by: Ralph Droms

Section 9.1 says:

|  There may not be cryptographic binding in SEND between the link layer
   frame address and the IPv6 address.  An unsecured link layer could
   allow nodes to spoof the link layer address of other nodes.

It should say:

|  There may not be a cryptographic binding in SEND between the link
   layer frame address and the IPv6 address.  An unsecured link layer
   could allow nodes to spoof the link layer address of other nodes.

Notes:

missing article

RFC 3973, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", January 2005

Note: This RFC has been updated by RFC 8736, RFC 9436

Source of RFC: pim (rtg)

Errata ID: 4635
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rui Lin
Date Reported: 2016-03-08
Held for Document Update by: Alvaro Retana
Date Held: 2016-07-14

Section 4.1.2 says:

Upstream interface-specific:
       Graft/Prune State:
         State: One of {"NoInfo" (NI), "Pruned" (P), "Forwarding" (F),
                        "AckPending" (AP) }

It should say:

"NoInfo" (NI) is not defined as an upstream interface state in 4.4.1.

Notes:

Suggest to remove "NoInfo" (NI) here.

Errata ID: 5894
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ehsan Hemmati
Date Reported: 2019-11-06
Held for Document Update by: Alvaro Retana
Date Held: 2019-11-06

Section 4.4.1 says:

Forwarding (F)
       This is the starting state of the Upsteam(S,G) state machine.
       The state machine is in this state if it just started or if
       oiflist(S,G) != NULL.

It should say:

Forwarding (F)
       This is the starting state of the Upstream(S,G) state machine.
       The state machine is in this state if it just started or if
       oiflist(S,G) != NULL.

Notes:

Upsteam(S,G) is a typo and should be corrected as Upstream(S,G)

RFC 3977, "Network News Transfer Protocol (NNTP)", October 2006

Note: This RFC has been updated by RFC 6048

Source of RFC: nntpext (app)

Errata ID: 1527
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2008-09-24
Held for Document Update by: Lisa Dusseault

Section 3.2.1 says:

401: The client must change the state of the connection in some other
   manner.  The first argument of the response MUST be the capability
   label (see Section 5.2) of the facility that provides the
   necessary mechanism (usually an extension, which may be a private
   extension).  The server MUST NOT use this response code except as
   specified by the definition of the capability in question.

Notes:

The 401 code is never dealt with in the whole RFC 3977. Even the definition of the MODE-READER capability does not indicate when the 401 return code should be used.
It should be said that it MUST be used in answers to commands only available after having sent MODE READER. Maybe section 5.3.2 that described the MODE READER command, is the right place to use in order to specify that behaviour.

[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] IHAVE
[S] MODE-READER
[S] .
[C] POST
[S] 401 MODE-READER
[C] MODE READER
[S] 200 Reader mode, posting permitted
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] POST
[S] .
[C] POST
[S] 340 Input article; end with <CR-LF>.<CR-LF>
[C] From: "Demo User" <nobody@example.net>
[C] Newsgroups: misc.test
[C] Subject: I am just a test article
[C] Organization: An Example Net
[C]
[C] This is just a test article.
[C] .
[S] 240 Article received OK

Errata ID: 2003
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2010-01-14
Held for Document Update by: Peter Saint-Andre

Throughout the document, when it says:

(a)  Section 6.1.3.2, last paragraph about LAST:

   If the current article number is already the first article of the
   newsgroup, a 422 response MUST be returned.  If the current article
   number is invalid, a 420 response MUST be returned.  If the currently
   selected newsgroup is invalid, a 412 response MUST be returned.  In
   all three cases, the currently selected newsgroup and current article
   number MUST NOT be altered.


(b)  Section 6.1.4.2, last paragraph about NEXT:

   If the current article number is already the last article of the
   newsgroup, a 421 response MUST be returned.  In all other aspects
   (apart, of course, from the lack of 422 response), this command is
   identical to the LAST command (Section 6.1.3).

It should say:

(a)  Section 6.1.3.2, last paragraph about LAST:

   If the currently selected newsgroup is invalid, a 412 response MUST
   be returned.  If the currently selected newsgroup is valid but the
   current article number is invalid, a 420 response MUST be returned.
   If the current article number is valid and there is no previous article
   in the currently selected newsgroup, a 422 response MUST be returned.
   In all three cases, the currently selected newsgroup and current article
   number MUST NOT be altered.


(b)  Section 6.1.4.2, last paragraph about NEXT:

   If the current article number is valid and there is no next article
   in the currently selected newsgroup, a 421 response MUST be returned.
   In all other aspects (apart, of course, from the lack of 422 response),
   this command is identical to the LAST command (Section 6.1.3).

Notes:

RFC 3977 is unclear about the 421 and 422 response codes: the first article of a newsgroup is defined as its reported low water mark, and the last article as its reported high water mark (see Section 6.1.1.2). However, there MAY be no previous article in the group, although the current article number is not the reported low water mark (see the second paragraph of Section 6.1.3.2). Therefore, a 422 response code MUST also be returned in that case. A similar case for the next article and the 421 response code exists.

The notion of "previous" and "next" article is respectively defined in the first paragraph of Sections 6.1.3.2 and 6.1.4.2.

This erratum also reverses the order of 412, 420, and 421/422 so that it is clearer that an invalid newsgroup or article number takes precedence in determining the return code.

Errata ID: 2004
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2010-01-14
Held for Document Update by: Barry Leiba
Date Held: 2012-05-12

Throughout the document, when it says:

(a)  Section 6.2.1.1 about ARTICLE:

   Third form (current article number used)
     220 n message-id      Article follows (multi-line)
     412                   No newsgroup selected
     420                   Current article number is invalid


(b)  Section 6.2.1.2, last paragraph about ARTICLE:

   If the argument is a message-id and no such article exists, a 430
   response MUST be returned.  If the argument is a number or is omitted
   and the currently selected newsgroup is invalid, a 412 response MUST
   be returned.  If the argument is a number and that article does not
   exist in the currently selected newsgroup, a 423 response MUST be
   returned.  If the argument is omitted and the current article number
   is invalid, a 420 response MUST be returned.


(c)  Section 6.2.2.1 about HEAD:

   Third form (current article number used)
     221 n message-id      Headers follow (multi-line)
     412                   No newsgroup selected
     420                   Current article number is invalid


(d)  Section 6.2.3.1 about BODY:

   Third form (current article number used)
     222 n message-id      Body follows (multi-line)
     412                   No newsgroup selected
     420                   Current article number is invalid


(e)  Section 6.2.4.1 about STAT:

    Third form (current article number used)
     223 n message-id      Article exists
     412                   No newsgroup selected
     420                   Current article number is invalid


(f)  Section 8.3.1 about OVER:

   Third form (current article number used)
     224    Overview information follows (multi-line)
     412    No newsgroup selected
     420    Current article number is invalid


(g)  Section 8.3.2, last paragraph about OVER:

   If the argument is a message-id and no such article exists, a 430
   response MUST be returned.  If the argument is a range or is omitted
   and the currently selected newsgroup is invalid, a 412 response MUST
   be returned.  If the argument is a range and no articles in that
   number range exist in the currently selected newsgroup, including the
   case where the second number is less than the first one, a 423
   response MUST be returned.  If the argument is omitted and the
   current article number is invalid, a 420 response MUST be returned.


(h)  Section 8.5.1 about HDR:

   Third form (current article number used)
     225    Headers follow (multi-line)
     412    No newsgroup selected
     420    Current article number is invalid


(i)  Section 8.5.2, antepenultimate paragraph about HDR:

   If the second argument is a message-id and no such article exists, a
   430 response MUST be returned.  If the second argument is a range or
   is omitted and the currently selected newsgroup is invalid, a 412
   response MUST be returned.  If the second argument is a range and no
   articles in that number range exist in the currently selected
   newsgroup, including the case where the second number is less than
   the first one, a 423 response MUST be returned.  If the second
   argument is omitted and the current article number is invalid, a 420
   response MUST be returned.

It should say:

(a)  Section 6.2.1.1 about ARTICLE:

   Third form (current article number used)
     220 n message-id      Article follows (multi-line)
     412                   No newsgroup selected
     420                   Current article number is invalid
|    423                   No article with that number

(b)  Section 6.2.1.2, last paragraph about ARTICLE:

   If the argument is a message-id and no such article exists, a 430
   response MUST be returned.  If the argument is a number or is omitted,
   and the currently selected newsgroup is invalid, a 412 response MUST
   be returned.  If the argument is a number or is omitted, and that
   article does not exist in the currently selected newsgroup, a 423
   response MUST be returned.  If the argument is omitted and the currently
   selected newsgroup is valid but the current article number is invalid,
   a 420 response MUST be returned.


(c)  Section 6.2.2.1 about HEAD:

   Third form (current article number used)
     221 n message-id      Headers follow (multi-line)
     412                   No newsgroup selected
     420                   Current article number is invalid
|    423                   No article with that number


(d)  Section 6.2.3.1 about BODY:

   Third form (current article number used)
     222 n message-id      Body follows (multi-line)
     412                   No newsgroup selected
     420                   Current article number is invalid
|    423                   No article with that number


(e)  Section 6.2.4.1 about STAT:

    Third form (current article number used)
     223 n message-id      Article exists
     412                   No newsgroup selected
     420                   Current article number is invalid
|    423                   No article with that number


(f)  Section 8.3.1 about OVER:

   Third form (current article number used)
     224    Overview information follows (multi-line)
     412    No newsgroup selected
     420    Current article number is invalid
|    423    No article with that number


(g)  Section 8.3.2, last paragraph about OVER:

   If the argument is a message-id and no such article exists, a 430
   response MUST be returned.  If the argument is a range or is omitted,
   and the currently selected newsgroup is invalid, a 412 response MUST
   be returned.  If the argument is a range or is omitted, and no articles
   in that number range exist in the currently selected newsgroup, including
   the case where the second number is less than the first one, a 423
   response MUST be returned.  If the argument is omitted and the currently
   selected newsgroup is valid but the current article number is invalid,
   a 420 response MUST be returned.


(h)  Section 8.5.1 about HDR:

   Third form (current article number used)
     225    Headers follow (multi-line)
     412    No newsgroup selected
     420    Current article number is invalid
|    423    No article with that number


(i)  Section 8.5.2, antepenultimate paragraph about HDR:

   If the second argument is a message-id and no such article exists, a
   430 response MUST be returned.  If the second argument is a range or
   is omitted, and the currently selected newsgroup is invalid, a 412
   response MUST be returned.  If the second argument is a range or is
   omitted, and no articles in that number range exist in the currently
   selected newsgroup, including the case where the second number is less
   than the first one, a 423 response MUST be returned.  If the second
   argument is omitted and the currently selected newsgroup is valid but
   the current article number is invalid, a 420 response MUST be returned.

Notes:

RFC 3977 does not define the response code to answer when the third form of ARTICLE, BODY, HDR, HEAD, OVER, and STAT is used while the current article number is valid but does not exist. It is in fact 423: this response code is used by the NNTP reference implementation, as well as major widely used current implementations like INN.

All these commands define that when the argument (or the second argument for HDR) is omitted, the current article number is used.

If 420 is used instead of 423 for that case, RFC 3977 becomes inconsistent regarding the notion of an "invalid current article number", specially for the NEXT and LAST commands. That's why the 423 response code needs to be sent when the current article number is valid but does not exist.

Note that this erratum also takes into account the previously reported erratum 1524.
--VERIFIER NOTES--
Section 6.2.1.2 paragraph 6 says "a previously valid article number
MAY become invalid if the article has been removed". Therefore the correct
response in the situation being addressed would be 420, not 423.

This could be a case that might be considered if the document is updated, but certainly it's not a simple error in the document.

Errata ID: 2037
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2010-02-10
Held for Document Update by: Alexey Melnikov

Section 6.2.1.2 says:

   Note that a previously valid article number MAY become invalid if the
   article has been removed.  A previously invalid article number MAY
   become valid if the article has been reinstated, but this article
   number MUST be no less than the reported low water mark for that
   group.

It should say:

   Note that a previously valid article number MAY cease to refer to any
   article if that article has been removed, in which case use of that
   article number (explicitly or implicitly) will cause a 423 response.  A
   previously removed article may be reinstated (but its number MUST be no
   less than the reported low water mark for that group), in which case
   that number will once again refer to that article.

Notes:

The paragraph is misusing the term "invalid article number". The wording should have been something like the corrected text, suggested by Clive Feather.

Errata ID: 2311
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2010-06-24
Held for Document Update by: Alexey Melnikov

Section 8.3.2 says:

   For all fields, the value is processed by first removing all CRLF
   pairs (that is, undoing any folding and removing the terminating
   CRLF) and then replacing each TAB with a single space.  If there is
   no such header in the article, no such metadata item, or no header or
   item stored in the database for that article, the corresponding field
   MUST be empty.

It should say:

   For all fields, the value is processed by first removing all CRLF
   pairs (that is, undoing any folding and removing the terminating
   CRLF) and then replacing each TAB with a single space.  If there is
   no such header in the article, no such metadata item, or no header or
   item stored in the database for that article, the corresponding field
   MUST be empty.  If a given header occurs in the article more than once,
   only the content of the first occurrence is returned by OVER.

Notes:

The precision about using the first occurrence of a given header exists for the HDR command (Section 8.5.2). The same thing should be done for OVER, out of consistency between the two commands.

Note: Maybe future versions of the protocol should consider the notion of concatenation of header fields. (We could transform "Comments: Line 1\r\nComments: Line 2" into "Comments: Line 1 Line 2" in the overview field instead of losing information.)

Errata ID: 2312
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2010-06-24
Held for Document Update by: Alexey Melnikov

Section 8.5.2 says:

   If the information is available, it is returned as a multi-line data
   block following the 225 response code and contains one line for each
   article in the range that exists.

It should say:

   If the information is available, it is returned as a multi-line data
   block following the 225 response code and contains one line for each
   article in the range that exists, sorted in numerical order of article
   number.

Notes:

The precision about using a numerical order exists for the OVER command (Section 8.3.2). The same thing should be done for HDR, out of consistency between the two commands.

Errata ID: 1522
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2008-09-23
Held for Document Update by: Lisa Dusseault

Section 5.3.3 says:

Example of use of the MODE READER command on a transit-only server
(which therefore does not providing reading facilities):

It should say:

Example of use of the MODE READER command on a transit-only server
(which therefore does not provide reading facilities):

Errata ID: 1529
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Clive Feather
Date Reported: 2008-09-29
Held for Document Update by: Lisa Dusseault

Section 13 says:

Other people who contributed to this document include:

      Matthias Andree
      Greg Andruk
      Daniel Barclay
      Maurizio Codogno
      Mark Crispin
      Andrew Gierth
      Juergen Helbing
      Scott Hollenbeck
      Urs Janssen
      Charles Lindsey
      Ade Lovett
      David Magda
      Ken Murchison
      Francois Petillon
      Peter Robinson
      Rob Siemborski
      Howard Swinehart
      Ruud van Tol
      Jeffrey Vinocur
      Erik Warmelink

It should say:

Other people who contributed to this document include:

      Matthias Andree
      Greg Andruk
      Daniel Barclay
      Maurizio Codogno
      Mark Crispin
      Julien Elie
      Andrew Gierth
      Juergen Helbing
      Scott Hollenbeck
      Urs Janssen
      Charles Lindsey
      Ade Lovett
      David Magda
      Ken Murchison
      Francois Petillon
      Peter Robinson
      Rob Siemborski
      Howard Swinehart
      Ruud van Tol
      Jeffrey Vinocur
      Erik Warmelink

Notes:

On the basis that at least one of his reported errata is being accepted, insert Julien Elie into this list at the appropriate place.

In those versions that can cope, the first letter of his surname should carry an acute accent (U+00C9).

Errata ID: 2719
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2011-02-15
Held for Document Update by: Peter Saint-Andre

Section 7.2.3 says:

   [C] HELP
   [S] 100 Help text follows
   [S] This is some help text.  There is no specific
|  [S] formatting requirement for this test, though
   [S] it is customary for it to list the valid commands
   [S] and give a brief definition of what they do.
   [S] .

It should say:

   [C] HELP
   [S] 100 Help text follows
   [S] This is some help text.  There is no specific
|  [S] formatting requirement for this text, though
   [S] it is customary for it to list the valid commands
   [S] and give a brief definition of what they do.
   [S] .

Notes:

A simple typo "test" -> "text".

First reported by Alfred Hönes.

Errata ID: 2721
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2011-02-15
Held for Document Update by: Peter Saint-Andre

Section 14 says:

Section 14.1 (Normative References):

[RFC977]      Kantor, B. and P. Lapsley, "Network News Transfer
              Protocol", RFC 977, February 1986.

It should say:

Section 14.2 (Informative References):

[RFC977]      Kantor, B. and P. Lapsley, "Network News Transfer
              Protocol", RFC 977, February 1986.

Notes:

This Reference should be moved to the Informative References (Section 14.2) because:

* RFC 3977 is published as Proposed Standard, and it has formally obsoleted RFC 977, thus removing it from the Standards track.
* Normative References in a Standards Track RFC must be at a comparable (or higher) level on the IETF Standards Track (or at similar position in other Standards Bodies' scheme).
* All uses of the Ref. tag [RFC977] are non-normative in nature.

First reported by Alfred Hönes.

RFC 3986, "Uniform Resource Identifier (URI): Generic Syntax", January 2005

Note: This RFC has been updated by RFC 6874, RFC 7320, RFC 8820

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 2624
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Saint-Andre
Date Reported: 2010-11-11
Held for Document Update by: Peter Saint-Andre
Date Held: 2011-03-30

Section Appendix B says:

^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?

It should say:

/^(([^:\/?#]+):)?(\/\/([^\/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?/

Notes:

This is a copy of Erratum #1933, reported against RFC 2396.

Errata ID: 2033
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tanaka Akira
Date Reported: 2010-02-05
Held for Document Update by: Alexey Melnikov

Section 3.3. says:

      path-empty    = 0<pchar>

It should say:

      path-empty    = ""

Notes:

According to ABNF, 0<pchar> is interpreted as
zero repeatation of the prose-val: pchar.

However pchar is an non-terminal.
So I think the production should be follows:
path-empty = 0pchar

However this production means a empty string.
So
path-empty = ""
is more clear.

Appendix A. has also the same production.

Errata ID: 2933
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bjoern Hoehrmann
Date Reported: 2011-08-13
Held for Document Update by: Peter Saint-Andre
Date Held: 2012-02-27

Section 5.2.2. says:

T.path = merge(Base.path, R.path);

It should say:

T.path = merge(Base, R);

Notes:

In 5.2.3. the "If the base URI has a defined authority component" condition requires knowing the authority component, so passing just the path component is misleading.

During discussion of this issue, Roy Fielding noted: "No, this is not an error in the algorithm. The algorithm is just saying that you need to merge the two paths. The two paths are not parameters to a function, nor is the merge procedure limited to those two parameters." Saving this report as "Hold For Document Update" so that future implementers do not experience the same confusion.

RFC 3987, "Internationalized Resource Identifiers (IRIs)", January 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 3163
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Martin Duerst
Date Reported: 2012-03-23
Held for Document Update by: Pete Resnick

Section 1.4. says:

For example, я stands for CYRILLIC CAPITAL LETTER YA.

It should say:

For example, Я stands for CYRILLIC CAPITAL LETTER YA.

Notes:

The correct code point for CYRILLIC CAPITAL LETTER YA is U+042F. U+044F would be CYRILLIC SMALL LETTER YA. See http://www.unicode.org/charts/PDF/U0400.pdf.

Errata ID: 3297
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Martin Dürst
Date Reported: 2012-07-26
Held for Document Update by: Barry Leiba
Date Held: 2012-07-30

Section 10.2 says:

   [Duerst97]     Duerst, M., "The Properties and Promises of UTF-8",
                  Proc.  11th International Unicode Conference, San Jose
                  , September 1997,
                  <http://www.ifi.unizh.ch/mml/mduerst/papers/
                  PDF/IUC11-UTF-8.pdf>.

It should say:

   [Duerst97]     Duerst, M., "The Properties and Promises of UTF-8",
                  Proc.  11th International Unicode Conference, San Jose
                  , September 1997,
                  <http://www.sw.it.aoyama.ac.jp/2012/pub/
                  IUC11-UTF-8.pdf>.

Notes:

The Web site of the University of Zurich (my employer at the time of writing this paper) has been reorganized last year. I finally managed to retreive a copy of the paper and make it available again, at http://www.sw.it.aoyama.ac.jp/2012/pub/IUC11-UTF-8.pdf. It should be available there for the next 15-20 years. (I have already updated this in my internal copy of RFC3987bis.)

---
Reviewer's comments:
This change is absolutely needed, but it is not within the purview of the errata system. A valid erratum is something that would have been considered an error in the original document, had it been noticed at the time. This clearly does not qualify.

It really should be "rejected", but I'm going to mark it "held for document update", hoping that it's more likely to be noticed that way.

RFC 3996, "Internet Printing Protocol (IPP): The 'ippget' Delivery Method for Event Notifications", March 2005

Source of RFC: ipp (app)

Errata ID: 5413
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Sweet
Date Reported: 2018-06-28
Held for Document Update by: Alexey Melnikov
Date Held: 2018-07-26

Section 5.2.1 says:

   The value of this attribute MUST be at least as large as that of the
   Printer's "ippget-event-life" Printer Description attribute (see
   section 8.1).  The Printer MAY return a value that is larger than
   that of the "ippget-event-life" Printer Description attribute
   provided that the Printer increases the Event Life for this
   Subscription object so that Notification Recipients taking account of
   the larger value and polling with a longer interval will not miss
   events.  Note:  Implementing such an algorithm requires some hidden
   attributes in the Subscription object that are IMPLEMENTATION
   DEPENDENT.

It should say:

   If the value of this attribute is larger than that of the
   "ippget-event-life" Printer Description attribute, the Printer MUST
   increase the Event Life for this Subscription object so that
   Notification Recipients taking account of the larger value and
   polling with a longer interval will not miss events.  Note:
   Implementing such an algorithm requires some hidden state in the
   Subscription object that is IMPLEMENTATION DEPENDENT.

Notes:

The range of values allowed for the "notify-get-interval" attribute (0 to 2^31-1) is different from the "ippget-event-life" attribute (15 to 2^31-1), and implementations have ignored this requirement because it makes no sense. Furthermore, the use of MAY for larger values does not clearly capture the requirement to extend event lives in order to avoid missing notifications.

RFC 4005, "Diameter Network Access Server Application", August 2005

Note: This RFC has been obsoleted by RFC 7155

Source of RFC: aaa (ops)

Errata ID: 2563
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hans Liu
Date Reported: 2010-10-14
Held for Document Update by: Dan Romascanu

Section 10.1 says:

The occurrence of route-record AVP in AAA is 0+.

It should say:

The occurrence of route-record AVP in AAA should be 0 according to AAA definition of section 3.2.

Notes:

In 3GPP Rx application TS 29.214, AAA command contains no route-record AVP either. So section 10.1 of RFC4005 needs to be corrected.

RFC 4006, "Diameter Credit-Control Application", August 2005

Note: This RFC has been obsoleted by RFC 8506

Source of RFC: aaa (ops)

Errata ID: 3329
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kiran Jadhav
Date Reported: 2012-08-23
Held for Document Update by: Benoit Claise

Section 5.6.2 says:

" Note that the credit-control server may already have initiated the
above-described process for the first interrogation. However, the
user's account might be empty when this first interrogation is
performed. In this case, the subscriber can be offered a chance to
replenish the account and continue the service. The credit-control
client receives a Credit-Control-Answer or service specific
authorization answer with the Final-Unit-Indication and Validity-Time
AVPs but no Granted-Service-Unit. It immediately starts the graceful
service termination without sending any message to the server. An
example of this case is illustrated in Appendix A."

It should say:

" Note that the credit-control server may already have initiated the
above-described process for the first interrogation. However, the
user's account might be empty when this first interrogation is
performed. In this case, the subscriber can be offered a chance to
replenish the account and continue the service. The credit-control
client receives a Credit-Control-Answer or service specific
authorization answer with the Final-Unit-Indication and Validity-Time
AVPs but no Granted-Service-Unit AVP. It immediately starts the graceful
service termination without sending any message to the server. An
example of this case is illustrated in Appendix A."

Notes:

In the sentence "The credit-control
client receives a Credit-Control-Answer or service specific
authorization answer with the Final-Unit-Indication and Validity-Time
AVPs but no Granted-Service-Unit." it is important that we add the letters "AVP" after Granted-Service-Units as it is not clear whether the sentence refers to "Not sending Granted-Service-Unit AVP at all" or "sending GSU=0 (Granted-Service-Unit AVP with value 0".

Different OCS vendors interpret the sentence above in a different way, some do not send the Granted-Service-Unit AVP at all, while some others send the Granted_Service-Unit=0. And this causes problem in the call scenario where FUI+Redirect is sent together with GSU=0. This causes the call to enter a loop and terminate with an error.

RFC 4009, "The SEED Encryption Algorithm", February 2005

Note: This RFC has been obsoleted by RFC 4269

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 751
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-02-28
Held for Document Update by: Russ Housley

 

(A)
>
> Unfortunately, within a few lines in the RFC text, the variable name 'X'
> gets used for two very distinct purposes and contexts:
>
>   o   X = X0 || X1 || X2 || X3                            (2)
>       ... the 32 bit wide input to the function G
>
>   o   X used as formal argument in the defining equations for
>       the 'SS-boxes' SS0 ... SS3
>       ... a single octet (8 bit wide entity),
>           [application of the formulas - see (3) below - will
>            substitute X0, ..., X3 in turn for the arguments]
>
> Perhaps, it would have been better to use another symbol, e.g. 'x', for the
> latter purpose.
>
>
> (B)
>
> As far as I can see, feeding the definition of the SS-boxes given in the
> last 4 text/formule lines on page 3 into the formula on top of page 4,
>
>      Z = SS0(X0) ^ SS1(X1) ^ SS2(X2) ^ SS3(X3)            (3)
>
> does ***NOT*** yield the same result as using the primary defining formulas
> given for Z0  ... Z3  in the first formula block of section 2.2., together
> with
>
>      Z = Z0 || Z1 || Z2 || Z3                             (1).
>
> I suspect a mis-ordering in the use of m0 ... m3 in the equations defining
> SS0 ... SS3 :
>
> With regard to the formulas (1), (2), and (3) (as numbered above), the
> 'matrix' pattern of the 4x4 terms in braces { ... } , obtained from the
> formula block defining SS0 ... SS3 by substitution of Xi for the argument of
> SSi (i=0,1,2,3) - as required in (3) -, should be the matrix transpose of
> the pattern of the same terms in braces appearing in the formula block
> defining Z0 ... Z3 , e. g. the first 'column' of {...} terms for SSi()
> should contain the {...} terms appearing in the formula for Z0.
> But this is not the case.
>
> Therefore, I suspect that the last 6 text/formula lines on page 3 of RFC
> 4009 should in fact read (including the enhancement from (A)
> above):
>
>   "
>   To increase the efficiency of the G function, four extended S-boxes
>   'SS-box' (See Appendix A.2) are defined as follows:
>
>    SS0(x)= {S1(x) & m0} || {S1(x) & m1} || {S1(x) & m2} || {S1(x) & m3}
>    SS1(x)= {S2(x) & m1} || {S2(x) & m2} || {S2(x) & m3} || {S2(x) & m0}
>    SS2(x)= {S1(x) & m2} || {S1(x) & m3} || {S1(x) & m0} || {S1(x) & m1}
>    SS3(x)= {S2(x) & m3} || {S2(x) & m0} || {S2(x) & m1} || {S2(x) & m2}
>   "
>
>

> In this case, I also recommend to include a textual enhancement for the
> first sentence of section 2.3., replacing:
>
>     "The key schedule generates each round subkeys."
> by:
>     "The key schedule generates subkeys for each round."
>
> And finally, for completeness, it would have been useful as well to give
> additional Informational Reference(s) for the seedMAC (and the
> [seed]CBC) algorithm(s)/construct(s) mentioned in section 2.5. - e.g.  RFC
> 3610 (and RFC 2451 / NIST SP 800-38A) [?].

It should say:

[see above]

Notes:

from pending

Errata ID: 752
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-02-28
Held for Document Update by: Russ Housley

 

(C)

First, a formal issue with the ASN.1 given in the RFC text:

In the ASN.1 definitions in section 2.5., it would perhaps be more
natural and consistent with the requirements from the text (and the
ASN.1 comment already present there!) to give an explicit SIZE
restriction in the definition of the syntax of the initialization
vector for SEED in CBC mode (which indeed *MUST* be 16 octets long).
To this end, I recommend to replace the 7th text line of section 2.5.,

  "seedCDCParameter ::= OCTET STRING  -- 128-bit Initialization Vector"

by:

| "seedCDCParameter ::= OCTET STRING (SIZE(16))
|                       -- 128-bit Initialization Vector"


(D)

The text in section 2.2. talks about two basic 8x8 S-boxes, named
"S1" and "S2".  Contrary to that, Appendix A.1. (on page 7) gives
tables for "S-Box S0" and "S-Box S1".

It would be easier to change the headlines in Appendix A.1.,
but, given the numbering style of all other formula elements,
it is certainly be more appropriate and consistent to modify the
equations in section 2.2., replacing "S1" by "S0", and "S2" by "S1".

I'll give a full replacement text for section 2.2. below, covering
this issue as well.


[ Now, returning to the open issue ... ]
(B)

In short, sorry, I do NOT agree with your definition of the SS-boxes.
It does not conform with the primary definition of the function G.

Below, I'll give you a detailed step-by-step explanation, using a
concrete example, for the reasoning already presented in my first
mail.

Note: For brevity and due to the email line length restriction,
  in the subsequent reasoning, I will omit the braces '{ ... }'
  around the ANDed terms, making use of the usual precedence rule
  for multiplication over addition and the facts that
  - the '^' operation is the normal addition in the 8 / 32 dimensional
    vector spaces over GF(2) we are working on,
  - '&' representing the 8 / 32 fold tensor product of the scalar
    multiplication over GF(2) .

I repeat and extend the numeration of the formulas from my first
email, already applying item (D).

   X = X0 || X1 || X2 || X3                                       (2)

       ... the 32 bit wide input to the function G;

   Z = Z0 || Z1 || Z2 || Z3                                       (1)

       ... the 32 bit wide output of the function G applied to X;
           with the 8-bit wide components computed by the application
           of the two S-Boxes S0 and S1 via the equations:

   Z0 = S0(X0) & m0 ^ S1(X1) & m1 ^ S0(X2) & m2 ^ S1(X3) & m3     (1.0)
   Z1 = S0(X0) & m1 ^ S1(X1) & m2 ^ S0(X2) & m3 ^ S1(X3) & m0     (1.1)
   Z2 = S0(X0) & m2 ^ S1(X1) & m3 ^ S0(X2) & m0 ^ S1(X3) & m1     (1.2)
   Z3 = S0(X0) & m3 ^ S1(X1) & m0 ^ S0(X2) & m1 ^ S1(X3) & m2     (1.3)

    with    m0 = 0xFC , m1 = 0xF3 , m2 = 0xCF , and m3 = 0x3F     (1.4)


The alternate description of the Function G is to be

   Z = SS0(X0) ^ SS1(X1) ^ SS2(X2) ^ SS3(X3)                      (3)

where, below, I'll try "my" version of the SS-Box definition ...

   SS0(x) = S0(x) & m0 || S0(x) & m1 || S0(x) & m2 || S0(x) & m3  (4.0)
   SS1(x) = S1(x) & m1 || S1(x) & m2 || S1(x) & m3 || S1(x) & m0  (4.1)
   SS2(x) = S0(x) & m2 || S0(x) & m3 || S0(x) & m0 || S0(x) & m1  (4.2)
   SS3(x) = S1(x) & m3 || S1(x) & m0 || S1(x) & m1 || S1(x) & m2  (4.3)

... and the version from the text (with the formal changes already
    discussed properly applied) ...

   SS0(x) = S0(x) & m3 || S0(x) & m2 || S0(x) & m1 || S0(x) & m0  (5.0)
   SS1(x) = S1(x) & m0 || S1(x) & m3 || S1(x) & m2 || S1(x) & m1  (5.1)
   SS2(x) = S0(x) & m1 || S0(x) & m0 || S0(x) & m3 || S0(x) & m2  (5.2)
   SS3(x) = S1(x) & m2 || S1(x) & m1 || S1(x) & m0 || S1(x) & m3  (5.3)


With these notations, let's challenge the example octet sequence

   X0 = 0x09 , X1 = 0x11 , X2 = 0xE1 , X3 = 0xF9                  (6a)

i.e., by (2) :      X = (0x) 09 11 E1 F9                          (6b)

Applying the tables from Appendix A.1., we obtain  (*)  :

   S0(X0) = 0x43 ,
   S1(X1) = 0x62 ,
   S0(X2) = 0xB9 ,
   S1(X3) = 0x4C .


To first compute Z with the original definition of G, substituting
(*) and (1.4) into (1.0) .. (1.3), we obtain, step by step:

   Z0 = S0(X0) & m0 ^ S1(X1) & m1 ^ S0(X2) & m2 ^ S1(X3) & m3     (1.0)
      = 0x43 & 0xFC ^ 0x62 & 0xF3 ^ 0xB9 & 0xCF ^ 0x4C & 0x3F
      =     0x40    ^     0x62    ^     0x89    ^     0x0C
==>
   Z0 = 0xA7                                                      (7.0)

   Z1 = S0(X0) & m1 ^ S1(X1) & m2 ^ S0(X2) & m3 ^ S1(X3) & m0     (1.1)
      = 0x43 & 0xF3 ^ 0x62 & 0xCF ^ 0xB9 & 0x3F ^ 0x4C & 0xFC
      =     0x43    ^     0x42    ^     0x39    ^     0x4C
==>
   Z1 = 0x74                                                      (7.1)

   Z2 = S0(X0) & m2 ^ S1(X1) & m3 ^ S0(X2) & m0 ^ S1(X3) & m1     (1.2)
      = 0x43 & 0xCF ^ 0x62 & 0x3F ^ 0xB9 & 0xFC ^ 0x4C & 0xF3
      =     0x43    ^     0x22    ^     0xB8    ^     0x40
==>
   Z2 = 0x99                                                      (7.2)

   Z3 = S0(X0) & m3 ^ S1(X1) & m0 ^ S0(X2) & m1 ^ S1(X3) & m2     (1.3)
      = 0x43 & 0x3F ^ 0x62 & 0xFC ^ 0xB9 & 0xF3 ^ 0x4C & 0xCF
      =     0x03    ^     0x60    ^     0xB1    ^     0x4C
==>
   Z3 = 0x9E                                                      (7.3)

Putting (7.0) .. (7.3) together using (1), we get the byte sequence

   Z = Z0 || Z1 || Z2 || Z3                                       (1)
==>
   Z = (0x) A7 74 99 9E                                           (7)


Now let's see what happens when we apply "my" definition of the
SS-Boxes, substituting (6a), (*), and (1.4) into (4.0) .. (4.3) :

   SS0(X0) = S0(X0) & m0 || S0(X0) & m1 || S0(X0) & m2 || S0(X0) & m3
           = 0x43 & 0xFC || 0x43 & 0xF3 || 0x43 & 0xCF || 0x43 & 0x3F
           =     0x40    ||     0x43    ||     0x43    ||     0x03
==>
   SS0(X0) = (0x) 40 43 43 03                                     (8.0)

   SS1(X1) = S1(X1) & m1 || S1(X1) & m2 || S1(X1) & m3 || S1(X1) & m0
           = 0x62 & 0xF3 || 0x62 & 0xCF || 0x62 & 0x3F || 0x62 & 0xFC
           =     0x62    ||     0x42    ||     0x22    ||     0x60
==>
   SS1(X1) = (0x) 62 42 22 60                                     (8.1)

   SS2(X2) = S0(X2) & m2 || S0(X2) & m3 || S0(X2) & m0 || S0(X2) & m1
           = 0xB9 & 0xCF || 0xB9 & 0x3F || 0xB9 & 0xFC || 0xB9 & 0xF3
           =     0x89    ||     0x39    ||     0xB8    ||     0xB1
==>
   SS2(X2) = (0x) 89 39 B8 B1                                     (8.2)

   SS3(X3) = S1(X3) & m3 || S1(X3) & m0 || S1(X3) & m1 || S1(X3) & m2
           = 0x4C & 0x3F || 0x4C & 0xFC || 0x4C & 0xF3 || 0x4C & 0xCF
           =     0x0C    ||     0x4C    ||     0x40    ||     0x4C
==>
   SS3(X3) = (0x) 0C 4C 40 4C                                     (8.3)

Note: Please observe that the terms in (8.0) .. (8.3) are indeed
  the same terms as in (7.0) .. (7.3), but in 4x4 matrix transposed
  order -- as stated abstractly in my first email.

Summing up (8.0) .. (8.3) according to (3), we get what should be
the alternate definition of G(X) :

   Z = SS0(X0) ^ SS1(X1) ^ SS2(X2) ^ SS3(X3)                      (3)
     = (0x) 40 43 43 03  ^                         --  from (8.0)
       (0x) 62 42 22 60  ^                         --  from (8.1)
       (0x) 89 39 B8 B1  ^                         --  from (8.2)
       (0x) 0C 4C 40 4C                            --  from (8.3)
==>         -----------
   Z = (0x) A7 74 99 9E                                           (8)

Obviously, (8) indeed is identical to (7).


Finally, let's look for what we get with your definition of the
SS-Boxes, substituting (6a), (*), and (1.4) into (5.0) .. (5.3) :

   SS0(X0) = S0(X0) & m3 || S0(X0) & m2 || S0(X0) & m1 || S0(X0) & m0
           = 0x43 & 0x3F || 0x43 & 0xCF || 0x43 & 0xF3 || 0x43 & 0xFC
           =     0x03    ||     0x43    ||     0x43    ||     0x40
==>
   SS0(X0) = (0x) 03 43 43 40                                     (9.0)

   SS1(X1) = S1(X1) & m0 || S1(X1) & m3 || S1(X1) & m2 || S1(X1) & m1
           = 0x62 & 0xFC || 0x62 & 0x3F || 0x62 & 0xCF || 0x62 & 0xF3
           =     0x60    ||     0x22    ||     0x42    ||     0x62
==>
   SS1(X1) = (0x) 60 22 42 62                                     (9.1)

   SS2(X2) = S0(X2) & m1 || S0(X2) & m0 || S0(X2) & m3 || S0(X2) & m2
           = 0xB9 & 0xF3 || 0xB9 & 0xFC || 0xB9 & 0x3F || 0xB9 & 0xCF
           =     0xB1    ||     0xB8    ||     0x39    ||     0x89
==>
   SS2(X2) = (0x) B1 B8 39 89                                     (9.2)

   SS3(X3) = S1(X3) & m2 || S1(X3) & m1 || S1(X3) & m0 || S1(X3) & m3
           = 0x4C & 0xCF || 0x4C & 0xF3 || 0x4C & 0xFC || 0x4C & 0x3F
           =     0x4C    ||     0x40    ||     0x4C    ||     0x0C
==>
   SS3(X3) = (0x) 4C 40 4C 0C                                     (8.3)

Summing up (9.0) .. (9.3) according to (3), we get

   Z = SS0(X0) ^ SS1(X1) ^ SS2(X2) ^ SS3(X3)                      (3)
     = (0x) 03 43 43 40  ^                         --  from (9.0)
       (0x) 60 22 42 62  ^                         --  from (9.1)
       (0x) B1 B8 39 89  ^                         --  from (9.2)
       (0x) 4C 40 4C 0C                            --  from (9.3)
==>         -----------
   Z = (0x) 9E 99 74 A7                                           (9)

This is NOT the same as (7).


In fact, it is the byte-reversed sequence from (7) .

-- Bingo!
Taking a closer look at (5.0) .. (5.3), I now see that indeed the
terms in these equations are in the reverse concatenation sequence
compared to (4.0) .. (4.3) !

After a detailed inspection of the tables given in Appendix A.2.
of RFC 4009, it now becomes clear that -- disregarding the IETF
conventions to represent all binary data in network byte order,
and without any further notice of this fact -- these tables do NOT
represent octect sequences (as expected from the presentation of
above formula using octet concatenation, not arithmetic left-shift
or multiply-by-256 operations), BUT the hexadecimal representation
of the proper 4-octet sequences improperly cast into 32 bit numbers
on a 'little endian' processor, i.e., without using the ntohl()
intrinsic!

I suspect that your definition of the SS-boxes (5.0) .. (5.3) has
been inadvertently retrofitted to match the values given in the
tables in Appendix A.2., again re-formulating the printed byte
order (which is NOT the storage byte order [= octet concatenation
order] in a little endian processor) using the octet concatenation
notation / formalism.

Because definition of the function G according to section 2.2. does
not make use of 32-bit integer arithmetic operations, I recommend
to clarify the situation by
o   giving formula (4.0) .. (4.3) for the SS-Boxes, consistent
    with the other formulas, and
o   stating explicitely in Appendix A.2. that these tables give
    byte reversed presentations of the octet sequences to be
    used as the output of the SS-boxes.


To catch up, here's my proposed replacement text for the whole
section 2.2. of RFC 4009, covering the issues (A), (B), and (D)
mentioned so far:

---------------- cut here -------------------------------

2.2.  The Function G

   The function G has two layers: a layer of two 8x8 S-boxes, S0 and
   S1, and a layer of block permutation of sixteen 8-bit sub-blocks.
   The output octet sequence Z (= Z0 || Z1 || Z2 || Z3) of the
   function G with the four-octet input X (= X0 || X1 || X2 || X3)
   is as follows:

    Z0 = {S0(X0) & m0} ^ {S1(X1) & m1} ^ {S0(X2) & m2} ^ {S1(X3) & m3}
    Z1 = {S0(X0) & m1} ^ {S1(X1) & m2} ^ {S0(X2) & m3} ^ {S1(X3) & m0}
    Z2 = {S0(X0) & m2} ^ {S1(X1) & m3} ^ {S0(X2) & m0} ^ {S1(X3) & m1}
    Z3 = {S0(X0) & m3} ^ {S1(X1) & m0} ^ {S0(X2) & m1} ^ {S1(X3) & m2}

   where  m0 = 0xFC , m1 = 0xF3 , m2 = 0xCF , and m3 = 0x3F .

   To increase the efficiency of the calculation of the function G, four
   extended S-boxes with 4-octet output ('SS-boxes', see Appendix A.2.)
   are defined as follows:

    SS0(x) = {S0(x) & m0} || {S0(x) & m1} || {S0(x) & m2} || {S0(x) & m3}
    SS1(x) = {S1(x) & m1} || {S1(x) & m2} || {S1(x) & m3} || {S1(x) & m0}
    SS2(x) = {S0(x) & m2} || {S0(x) & m3} || {S0(x) & m0} || {S0(x) & m1}
    SS3(x) = {S1(x) & m3} || {S1(x) & m0} || {S1(x) & m1} || {S1(x) & m2}

   Hereby, the function G can be defined as follows:

      Z = G(X) = SS0(X0) ^ SS1(X1) ^ SS2(X2) ^ SS3(X3)  .

   This alternate definition of the function G is faster than the
   original definition but it takes 16 times the memory to store
   the four SS-boxes compared to the two original S-boxes.

---------------- cut here -------------------------------


Immediately below the headline of Appendix A.2., on page 8,
I propose to insert the following text (or similar):

   "The following tables specify the byte-reversed SS-box values,
    i.e., the first octet to be returned from the function G
    (named Z0 in section 2.2.), is obtained by XORing together
    the rightmost bytes from the appropriate entries looked up
    in the following four tables, etc."


(E)

The above discussion, and the observed deviation from the IETF
standard ('network') byte ordering convention, immediately raises
additional byte ordering concerns for
-  the definition of the round function F in section 2.1., and
-  the Key Schedule definition given in section 2.3.

The function G -- as defined in section 2.2. -- operates on a four-
octet sequence and returns a four-octet sequence, according to the
formulae labelled (1) and (2) above.

The definition of the round function F and the key schedule make use of
several multi-byte INTEGER arithmetic operations, in particular 32-bit
(mod 2^32) addition and subtraction, on input and output values of the
function G, and the key schedule uses circular shift operations on
concatenated (64 bit) intermediate key blocks.

With regard to the observations made above, I now suspect that some
of the implicit 'cast' operations (between octet sequences and multi-
byte integers) involved in the round functions and the key schedule
might also be formulated in a little-endian centric way, omitting the
necessary application of the htonl() and ntohl() intrinsics when
producing the test cases in Appendix B.  (I did not have the time
to verify that.)

For the sake of interoperability, it SHOULD be clarified whether the
formulae given for R0' and R1' in section 2.1., and for Ki0 and Ki1
in section 2.3., as well as the constant's values tabulated in the
latter section, are specified according to IEFT standard byte ordering
rules, or with implicit little-endian byte order in mind.

It should say:

[see above]

Notes:

from pending

Errata ID: 197
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-03-06
Held for Document Update by: Russ Housley

Section 2.5 says:

 seedCDCParameter ::= OCTET STRING  -- 128-bit Initialization Vector

It should say:

seedCDCParameter ::= OCTET STRING (SIZE(16))
                       -- 128-bit Initialization Vector

RFC 4010, "Use of the SEED Encryption Algorithm in Cryptographic Message Syntax (CMS)", February 2005

Source of RFC: smime (sec)

Errata ID: 196
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-02-28
Held for Document Update by: Tim Polk

Section 3.1 says:

    P[i]          The ith plaintext key data block
     C[i]          The ith ciphertext data block
     A             The 64-bit integrity check register
     R[i]          An array of 64-bit registers where
                   i = 0, 1, 2, ..., n
     A[t], R[i][t] The contents of registers A and R[i] after
                   encryption step t.

It should say:

    P[i]          The ith (64-bit) plaintext key data block
                  where i = 1, 2, ..., n
    C[i]          The ith (64-bit) ciphertext data block
                  where i = 0, 1, 2, ..., n
     A             The 64-bit integrity check register
     R[i]          An array of 64-bit registers where
                  i = 1, 2, ..., n
     A[t], R[t][i] The contents of registers A and R[i] after
                   encryption step t.

RFC 4013, "SASLprep: Stringprep Profile for User Names and Passwords", February 2005

Note: This RFC has been obsoleted by RFC 7613

Source of RFC: sasl (sec)

Errata ID: 3697
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Giovanni Cannata
Date Reported: 2013-08-17
Held for Document Update by: Sean Turner
Date Held: 2014-01-12

Section 5 says:

Indicator whether or not this is the newest version of the
profile: This is the first version of the SASPprep profile.

It should say:

Indicator whether or not this is the newest version of the
profile: This is the first version of the SASLprep profile.

Notes:

"SASLprep" has been erroneously misspelled "SASPprep".

RFC 4026, "Provider Provisioned Virtual Private Network (VPN) Terminology", March 2005

Source of RFC: l3vpn (int)

Errata ID: 195
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By:
Date Reported: 2006-08-17
Held for Document Update by: Stewart Bryant

Section 8.10 says:

   VPN Forwarding Instance (VFI) is a logical entity that resides in a
   PE that includes the router information base and forwarding
   information base for a VPN instance [L3VPN-FRAME].

It should say:

   VPN Forwarding Instance (VFI) is a logical entity that resides in a
   PE that includes the route information base and forwarding
   information base for a VPN instance [L3VPN-FRAME].

RFC 4028, "Session Timers in the Session Initiation Protocol (SIP)", April 2005

Source of RFC: sip (rai)

Errata ID: 1687
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Radha krishna Saragadam
Date Reported: 2009-02-19
Held for Document Update by: Robert Sparks

Section 9 says:

The UAS MUST NOT increase the value of the Session-Expires header field.

It should say:

same as session 8.1
   If the request doesn't indicate support for the session timer but
   contains a session interval that is too small, the UAS cannot
   usefully reject the request, as this would result in a call failure.
   Rather, the UAS SHOULD insert a Min-SE header field containing its
   minimum interval.  If a Min-SE header field is already present, the
   UAS SHOULD increase (but MUST NOT decrease) the value to its
   minimum interval.  The UAS MUST then increase the Session-Expires
   header field value to be equal to the value in the Min-SE header
   field

Notes:

----- Forwarded Message ----
From: Radha krishna <krishna_srk2003@yahoo.com>
To: Brett Tate <brett@broadsoft.com>; "sip-implementors@lists.cs.columbia.edu" <sip-implementors@lists.cs.columbia.edu>
Sent: Thursday, February 19, 2009 10:56:31 AM
Subject: Re: [Sip-implementors] Sending 422

Thanks Brett,

So I think same should be added for UAS

<Snip from RFC section 8.1>

If the request doesn't indicate support for the session timer but

contains a session interval that is too small, the proxy cannot
usefully
reject the request, as this would result in a call failure.
Rather, the
proxy SHOULD insert a Min-SE header field containing its
minimum
interval. If a Min-SE header field is already present, the
proxy SHOULD
increase (but MUST NOT decrease) the value to its
minimum interval. The
proxy MUST then increase the Session-Expires
header field value to be equal to the value in the
Min-SE header
field, as described above.
</Snip from RFC>


Regards
S.Radha krishna




________________________________
From: Brett Tate <brett@broadsoft.com>
To: Radha krishna <krishna_srk2003@yahoo.com>; "sip-implementors@lists.cs.columbia.edu" <sip-implementors@lists.cs.columbia.edu>
Sent: Wednesday, February 18, 2009 6:42:31 PM
Subject: RE: [Sip-implementors] Sending 422

It looks like Section 9 may have forgotten to indicate the behavior when UAC timer support not indicated. Section 8.1 allows a proxy to increase the Session-Expires; I see no reason why the same cannot be done by the UAS.

> -----Original Message-----
> From: sip-implementors-bounces@lists.cs.columbia.edu [mailto:sip-
> implementors-bounces@lists.cs.columbia.edu] On Behalf Of Radha krishna
> Sent: Tuesday, February 17, 2009 9:48 PM
> To: sip-implementors@lists.cs.columbia.edu
> Subject: [Sip-implementors] Sending 422
>
> Hi
>
> Consider the following topology
> UA1 ----- Call-stateful-proxy ------ UA2
>
> UA1 does not support session timer, Make a call to UA2. Call-
> stateful-proxy adds Session-Expires:100 header and forwards to UA2. UA2
> minimum session expires is 900. But in this case INVITE will not contain
> "support: timer". According section 9, UAS can reject with 422 only if
> there is a timer tag in supported header
>
> <Snip from RFC>
>
> If an incoming request contains a Supported header field with a value
> 'timer' and a Session Expires header field, the UAS MAY reject the
> INVITE request with a 422 (Session Interval Too Small) response if
> the session interval in the Session-Expires header field is smaller
> than the minimum interval defined by the UAS' local policy. When
> sending the 422 response, the UAS MUST include a Min-SE header field
> with the value of its minimum interval. This minimum interval MUST
> NOT be lower than 90 seconds.
> </Snip from RFC>
>
> Also UAS cannot increase the session expires duration
> <Snip from RFC>
> The UAS MUST
> NOT increase the value of the Session-Expires header field.
> </Snip from RFC>
>
> What should be the behavior of UAS here?
> 1) accept the call with 100 seconds?
> 2) Increase the duration to 900 seconds while sending 200 Ok?
> Note: Session timer should not be turned-off
>
> Regards
> S.Radha krishna
>
>
>
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors




_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

RFC 4034, "Resource Records for the DNS Security Extensions", March 2005

Note: This RFC has been updated by RFC 4470, RFC 6014, RFC 6840, RFC 6944, RFC 9077

Source of RFC: dnsext (int)

Errata ID: 2681
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Guillaume Bailey
Date Reported: 2011-01-05
Held for Document Update by: Brian Haberman

Section B says:

   The key tag is the same for all DNSKEY algorithm types except
   algorithm 1 (please see Appendix B.1 for the definition of the key
   tag for algorithm 1).  The key tag algorithm is the sum of the wire
   format of the DNSKEY RDATA broken into 2 octet groups.  First, the
   RDATA (in wire format) is treated as a series of 2 octet groups.
   These groups are then added together, ignoring any carry bits.

It should say:

   The key tag is the same for all DNSKEY algorithm types except
   algorithm 1 (please see Appendix B.1 for the definition of the key
   tag for algorithm 1).  The key tag algorithm is the sum of the wire
   format of the DNSKEY RDATA broken into 2 octet groups.  First, the
   RDATA (in wire format) is treated as a series of 2 octet groups.
   These groups are then added together with at least 32-bit precision,
   retaining any carry bits. The carry bits are then added to the result,
   and finally, only the lower 16 bits of the result are used as the key 
   tag.

Notes:

This change comes from the example implementation. The accumulator, ac, is required ("assumed") to be 32-bits or larger, and the carry bits are added to the accumulator before returning:

ac += (ac >> 16) & 0xFFFF;

RFC 4055, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", June 2005

Note: This RFC has been updated by RFC 5756

Source of RFC: pkix (sec)

Errata ID: 1677
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-02-02
Held for Document Update by: Tim Polk

Section 6, pg. 18 says:

      rSASSA-PSS-SHA512-Identifier  AlgorithmIdentifier  ::=  {
                              algorithm id-RSASSA-PSS,
|                             parameters rSSASSA-PSS-SHA512-params }
                                         ^^^^
      vvvv
|     rSSASSA-PSS-SHA512-params RSASSA-PSS-params ::= {
                              hashAlgorithm sha512Identifier,
                              maskGenAlgorithm mgf1SHA512Identifier,
                              saltLength 20,
                              trailerField 1  }

It should say:

      rSASSA-PSS-SHA512-Identifier  AlgorithmIdentifier  ::=  {
                              algorithm id-RSASSA-PSS,
|                             parameters rSASSA-PSS-SHA512-params }
                                         ^^^
      vvv
|     rSASSA-PSS-SHA512-params RSASSA-PSS-params ::= {
                              hashAlgorithm sha512Identifier,
                              maskGenAlgorithm mgf1SHA512Identifier,
                              saltLength 20,
                              trailerField 1  }

Notes:

repeated Typo; s/rSSA/rSA/

Errata ID: 2724
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sean Turner
Date Reported: 2011-02-16
Held for Document Update by: Tim Polk

Section 2.1 says:

  id-sha224  OBJECT IDENTIFIER  ::=  {{ joint-iso-itu-t(2)
                            country(16) us(840) organization(1) gov(101)
                            csor(3) nistalgorithm(4) hashalgs(2) 4 }

It should say:

  id-sha224  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2)
                            country(16) us(840) organization(1) gov(101)
                            csor(3) nistalgorithm(4) hashalgs(2) 4 }

Notes:

There's an extra "{". This is incorrect ASN.1. I marked it as editorial because the ASN.1 module does not contain this error.

Errata ID: 5199
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bernd Eckenfels
Date Reported: 2017-12-05
Held for Document Update by: Kathleen Moriarty
Date Held: 2018-03-18

Section 4.1 says:

The pSourceFunc field identifies the source (and possibly the value)
of the encoding parameters, commonly called P.

It should say:

The pSourceFunc field identifies the source (and possibly the value)
of the encoding parameters, commonly called P. (Note: it is referred
to as label L in [P1v2.1], and it is referred to as
P throughout [P1v2.0],
although the ASN.1 structures in both document use the letter “p”.)

Notes:

There is no place where P is linked to the parameter name L as used in
referenced [P1v2.1]
Per Burt Kaliski (and edited by Russ Housley):
"""
The text in Sec. 4.1 of RFC4055 including the syntax of RSAES-OAEP-params largely follows Sec. 11.2.1 of RFC2437 (PKCS #1 v2.0), which uses the term “encoding parameters P”, rather than the Sec. A.2.1 of RFC3447 (PKCS #1 v2.1), which uses the term “label L”. (RFC3560, the CMS profile for these algorithms, similarly follows RFC2437.)

RFC3447 acknowledges that “In previous versions of this specification, the term ‘encoding parameters’ was used”. Given that RFC4055 inserts “commonly called” before RFC2437’s “P”, it appears that RFC4055 is attempting to bridge between RFC3447 and RFC2437.
"""

I observe that RFC 2437, RFC 3447, and RFC 4055 all use the same ASN.1 structure for RSAES-OAEP-params. While the description of RSAES-OAEP in [P1v2.1] uses "L" instead of "P", this change in terminology did not carry through to the ASN.1 structure.

I think that this should not be classified as a technical errata. Perhaps a better text would be:

The pSourceFunc field identifies the source (and possibly the value)
of the encoding parameters, commonly called P. (Note: it is referred
to as label L in Section 7.1.1 of [P1v2.1], and it is referred to as P
throughout [P1v2.0] and Section A.2.1 of [P1v2.1].)

[P1v2.0] = RFC 2437

I don’t see an error here, so I think the corrected errata should be approved as editorial.

Errata ID: 5325
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ryan Sleevi
Date Reported: 2018-04-13
Held for Document Update by: Benjamin Kaduk
Date Held: 2018-10-10

Section 4055 says:

If the keyUsage extension is present in a certificate conveys an RSA
public key with the id-RSAES-OAEP object identifier, then the
keyUsage extension MUST contain only the following values:

It should say:

If the keyUsage extension is present in a certificate that conveys an
RSA public key with the id-RSAES-OAEP object identifier, then the
keyUsage extension MUST contain only the following values:

Notes:

The certificate, rather than the keyUsage extension, conveys the id-RSAES-OAEP OID.

This was likely a typo based on the wording of the previous paragraph, "When a certificate conveys an RSA public key". This aligns the language with the paragraph earlier in this section, "If the keyUsage extension is present in an end-entity certificate that conveys an RSA public key".

RFC 4069, "Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Single Carrier Modulation (SCM) Line Coding", May 2005

Source of RFC: adslmib (ops)

Errata ID: 6541
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Juli Mallett
Date Reported: 2021-04-13
Held for Document Update by: Robert Wilton
Date Held: 2021-04-13

Throughout the document, when it says:

       2.3.  Structure ..........................  ..................  3

It should say:

       2.3.  Structure ..............................................  3

Notes:

This time it was two spaces.

RFC 4072, "Diameter Extensible Authentication Protocol (EAP) Application", August 2005

Note: This RFC has been updated by RFC 7268, RFC 8044

Source of RFC: aaa (ops)

Errata ID: 1955
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Glen Zorn
Date Reported: 2009-12-03
Held for Document Update by: Dan Romascanu

Section 4.1.4 says:

   Note that not all link layers use this name, and currently most EAP
   methods do not generate it.  Since the NAS operates in pass-through
   mode, it cannot know the Key-Name before receiving it from the AAA
   server.  As a result, a Key-Name AVP sent in a Diameter-EAP-Request
   MUST NOT contain any data.  A home Diameter server receiving a
   Diameter-EAP-Request with a Key-Name AVP with non-empty data MUST
   silently discard the AVP.  

It should say:

   Note that not all link layers use this name, and currently most EAP
   methods do not generate it.  Since the NAS operates in pass-through
   mode, it cannot know the name of the key before receiving it from the AAA
   server.  As a result, an EAP-Key-Name AVP sent in a Diameter-EAP-Request
   MUST NOT contain any data.  A home Diameter server receiving a
   Diameter-EAP-Request containing an EAP-Key-Name AVP with non-empty data MUST
   silently ignore the AVP.  

Notes:

In the original text, the first occurrence of the string "Key-Name" apparently is meant to refer to the actual name of the key, rather than an AVP identifier, while the next two occurrences are obviously typos, since no Key-Name AVP is defined in the document. Also, the term "silently discard" is typically used in reference to messages; with reference to a single AVP, "silently ignore" seems more appropriate.

Errata ID: 1956
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Glen Zorn
Date Reported: 2009-12-03
Held for Document Update by: Dan Romascanu

Section 4.1.4 says:

In addition, the home Diameter server SHOULD include this AVP in 
Diameter-EAP-Response only if an empty EAP-Key-Name AVP was present in 
Diameter-EAP-Request.

It should say:

In addition, the home Diameter server SHOULD include this AVP in the 
Diameter-EAP-Answer message only if an empty EAP-Key-Name AVP was present in
the corresponding Diameter-EAP-Request.

Notes:

There's no such thing as a "Diameter-EAP-Response" message; the rephrasing is for purposes of clarification.

RFC 4073, "Protecting Multiple Contents with the Cryptographic Message Syntax (CMS)", May 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 762
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-05-17
Held for Document Update by: Sean Turner

 

In the module heading and in the IMPORTS clause of the ASN.1 module
of RFC 4073 (Appendix A on page 7), the textual label for the
sub-identifier 9 of the OBJECT IDENTIFIER 1.2.840.113549.1 is
spelled "pkcs-9(9)".
But, ALL other (#=4) appearances of this same sub-identifier in the
text of RFC 4073 use the spelling "pkcs9(9)" (without the '-').

I've tried to resolve this inconsistency going "back to the roots",
and unfortunately found a big mess! (see detailed list below)

Basically, PKCS#9 v2.0 from RSA Labs and its ASCII-fication RFC 2985
should be considered the primary reference because this spec contains
the definition of the OBJECT IDENTIFIER 1.2.840.113549.1.9 .
There, the spelling consistently is  "pkcs-9(9)" .

This notation style is strictly followed in all PKCS publications
from RSA (as far as I could verify), and in most RFCs related to
PKCS/CMS/PKIX. I've found 24 RFCs of this kind.

But there are two RFCs using the spelling "pkcs9(9)" (without the '-')
exclusively.

And finally, I found 8 RFCs - including RFC 4073 and your RFC 4049,
as well - using both spellings mixed without any recognizable pattern.

Here are the detailed results of my RFC scan - with shortened titles,
and some content oriented grouping applied:

'pkcs-9(9)' only :
----------------
  2985 - PKCS #9

  2311 - S/MIME v.2 Message Specification,
  2312 - S/MIME v.2 Certificate Handling,
  2633 - S/MIME v.3 Message Specification
  3114 - Company Classifying Policy via S/MIME Security Label
  3183 - Domain Security Services using S/MIME
  3850 - S/MIME v.3.1 Certificate Handling
  3855 - Transporting S/MIME Objects in X.400

  2459 - PKIX Certificate and CRL Profile  [ obsoleted by: 3280 ]
  3280 - PKIX Certificate and CRL Profile

  2511 - PKIX Certificate Request Messages
  3029 - PKIX Data Validation and Certification Server Protocols

  2797 - Certificate Mgmt Messages over CMS
  3161 - PKIX Time-Stamp Protocol

  3125 - Electronic Signature Policies

  3211 - Password-based Encryption for CMS  [ obsoleted by: 3369+3370 ]
  3274 - Compressed Data Content for CMS

  2875 - D-H Proof-of-Posession
  3185 - Reuse of CMS CEKs
  3217 - Triple-DES and RC2 Key Wrapping
  3370 - CMS Algorithms
  3537 - HMAC Key Wrapping with 3DES or AES
  3560 - RSAES-OAEP Key Transport in CMS
  3565 - Use of AES Encryption in CMS

'pkcs9(9)' only :
---------------
  3657 - Use of Camellia Encryption in CMS
  4010 - Use of SEED Encryption in CMS

mixed spelling :
--------------
  2630 - CMS  [ obsoleted by: 3369+3370 ]
  3369 - CMS  [ obsoleted by: 3852 ]
  3852 - CMS

  2634 - Enhanced Security Services for S/MIME
  3851 - S/MIME v.3.1 Message Specification

  3126 - Electronic Signature Formats for lon-term signatures

  4049 - BinaryTime

  4073 - Multiple Content in CMS

Note: I fear that there might exist similar inconsistencies for other
====  object identifiers (verification: t.b.d.)


So, what should be done?
It certainly would be VERY preferable to follow identifier naming
literally, always and strictly, once published in a normatively
referable way.
At least, we should ensure a consistent use of already defined
identifiers to be followed in future IETF publications.
Additionally, it might be considered to post Errata Notes for some
(or all non-obsoleted) RFCs in the 2nd and 3rd category above
(i.e., RFCs 2634, 3126, 3657, 3851, 3852, 4010, 4049, 4073).

It should say:

[see above]

Notes:

from pending

RFC 4086, "Randomness Requirements for Security", June 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 3105
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Florian Weimer
Date Reported: 2012-02-05
Held for Document Update by: Sean Turner

Section 6.2.2 says:

   If one uses no more than the:

         log  ( log  ( s  ) )
            2      2    i

   low-order bits, then predicting any additional bits from a sequence
   generated in this manner is provably as hard as factoring n.

It should say:

(see below)

Notes:

As noted by Koblitz and Menezes in "Another look at provable security II", <http://eprint.iacr.org/2006/229.pdf>, this recommendation is based on a misinterpretation of the big-O notation. The claim about provable security is therefore misleading.

Errata ID: 3426
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tony Hansen
Date Reported: 2012-12-10
Held for Document Update by: Pete Resnick

Section 7.2.1 says:

In the subsections below, the HMAC hash construct is simply referred
to as HMAC but, of course, a particular standard SHA function must be
selected in an particular use.

It should say:

In the subsections below, the HMAC hash construct is simply referred
to as HMAC but, of course, a particular standard SHA function must be 
selected in a particular use.

Notes:

a grammatical nit

Errata ID: 3427
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tony Hansen
Date Reported: 2012-12-10
Held for Document Update by: Pete Resnick

Section 7.2.1.1 says:

In the following sections, the notation give below is used:

It should say:

In the following sections, the notation given below is used:

Notes:

a grammatical nit

RFC 4102, "Registration of the text/red MIME Sub-Type", June 2005

Note: This RFC has been updated by RFC 6354

Source of RFC: avt (rai)

Errata ID: 1204
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Gunnar Hellstrom
Date Reported: 2007-12-27
Held for Document Update by: Robert Sparks

Section 4 says:

       m=text 11000 RTP/AVP 98 100

It should say:

       m=text 11000 RTP/AVP 100 98

Notes:

According to RFC 3264 Offer-answer model, section 5.1, the payload types in m-lines shall be listed in order of preference. The redundancy method shall be preferred as default as described in section 4 of RFC 4103. The example should show the most common use. Therefore the redundancy payload type 100 shall be given first in the example m-line.

RFC 4103, "RTP Payload for Text Conversation", June 2005

Note: This RFC has been updated by RFC 9071

Source of RFC: avt (rai)

Errata ID: 1203
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Gunnar Hellstrom
Date Reported: 2007-12-27
Held for Document Update by: Robert Sparks

Section 7.2 says:

      m=text 11000 RTP/AVP 98 100

It should say:

      m=text 11000 RTP/AVP 100 98

Notes:

According to RFC 3264 Offer-answer model, section 5.1, the payload types in m-lines shall be listed in order of preference. The redundancy method shall be preferred as default as described in section 4 of RFC 4103. The example should show the most common use. Therefore the redundancy payload type 100 shall be given first in the example m-line.

Errata ID: 1793
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Gunnar Hellstrom
Date Reported: 2009-06-16
Held for Document Update by: Robert Sparks

Section 7.1 says:

The value of the "R2 block length" would be set to zero in order to represent the empty T140block.

  0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P|X| CC=0  |M|  "RED" PT   |   sequence number of primary  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               timestamp of primary encoding "P"               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           synchronization source (SSRC) identifier            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|   T140 PT   |  timestamp offset of "R2" | "R2" block length |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|   T140 PT   |  timestamp offset of "R1" | "R1" block length |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   T140 PT   | "R1" T.140 encoded redundant data             |
   +-+-+-+-+-+-+-+-+                               +---------------+
   |                                               |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         +-+-+-+
   |              "P" T.140 encoded primary data             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

The value of the "R1 block length" would be set to zero in order to represent the empty T140block.

  0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P|X| CC=0  |M|  "RED" PT   |   sequence number of primary  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               timestamp of primary encoding "P"               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           synchronization source (SSRC) identifier            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|   T140 PT   |  timestamp offset of "R2" | "R2" block length |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|   T140 PT   |  timestamp offset of "R1" | "R1" block length |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   T140 PT   | "R2" T.140 encoded redundant data             |
   +-+-+-+-+-+-+-+-+                               +---------------+
   |                                               |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         +-+-+-+
   |              "P" T.140 encoded primary data             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

RFC 4113, "Management Information Base for the User Datagram Protocol (UDP)", June 2005

Source of RFC: ipv6 (int)

Errata ID: 187
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-06-20
Held for Document Update by: Brian Haberman

DESCRIPTION clause of 'udpEndpointRemotePort' says:

       The remote port number for this UDP endpoint.  If
       datagrams from any remote system are to be accepted,
       this value is zero.

It should say:

       The remote port number for this UDP endpoint.  If
       datagrams from any remote port are to be accepted,
       this value is zero.

Errata ID: 767
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-06-20
Held for Document Update by: Brian Haberman

 

The DESCRIPTION clause of 'udpEndpointRemoteAddressType',
    at the bottom of page 10,

       "The address type of udpEndpointRemoteAddress.  Only
       IPv4, IPv4z, IPv6, and IPv6z addresses are expected, or
       unknown(0) if datagrams for all remote IP addresses are
       accepted. ..."     

It should say:

       "The address type of udpEndpointRemoteAddress.  Only
       IPv4, IPv4z, IPv6, and IPv6z addresses are expected, or
       unknown(0) if datagrams from all remote IP addresses are
       accepted. ..."
                               ^^^^      

Notes:

from pending

RFC 4120, "The Kerberos Network Authentication Service (V5)", July 2005

Note: This RFC has been updated by RFC 4537, RFC 5021, RFC 5896, RFC 6111, RFC 6112, RFC 6113, RFC 6649, RFC 6806, RFC 7751, RFC 8062, RFC 8129, RFC 8429, RFC 8553

Source of RFC: krb-wg (sec)

Errata ID: 4399
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Thomas Maslen
Date Reported: 2015-06-24
Held for Document Update by: Paul Wouters
Date Held: 2024-01-16

Section 6.1 says:

All prefixes expect those beginning with used.

It should say:

??

Notes:

Hmmm, looks like part of the sentence ended up in /dev/null. (Also, was "expect" perhaps meant to be "except"?) It looks to me as though this happened between kerberos-clarifications-04 and -05. If I had to guess, it was probably trying to say that you can roll your own private-use prefixes (beginning with "X-" or "x-"), but any other prefixes must go through the official registry process, per RFC 6111?

Paul Wouters (AD): the -04 draft said: All prefixes must be assigned before they may be used. The -05 version is as in the RFC. It seems indeed that an exception was contemplated for specific prefixes starting with x- or X-. This can be read in The IANA Considerations section.

RFC 4122, "A Universally Unique IDentifier (UUID) URN Namespace", July 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 3546
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Askar Safin
Date Reported: 2013-03-14
Held for Document Update by: Barry Leiba
Date Held: 2013-03-20

Section 4.1.3 says:

The version number is in the most significant 4 bits of the time
stamp (bits 4 through 7 of the time_hi_and_version field).

It should say:

The version number is in the most significant 4 bits of the time
stamp (bits 0 through 3 of the time_hi_and_version field).

Notes:

We use network order (as far as I know, we use network order in this RFC both for bits and bytes). So, the most significant bits comes first and they are located in first bytes. So, 0 through 3.

---VERIFIER NOTES ---
This erratum is correct as far as it goes, but, given other text in the RFC, so is erratum 1957. There is a pervasive problem in this RFC with inconsistent and unclear usage of bit numbering, which switches between several conventions. The diagram in Section 4.1.2 uses left-to-right bit numbering (the most significant bit is numbered 0), but much of the text (such as in Section 4.2.2) uses right-to-left bit numbering (the least significant bit is numbered 0). Most of the text uses big-ending byte order (network byte order), but some seems to assume little-ending, probably mistakes that come from the authors' familiarity with that convention.

With respect to the text in question, the first sentence of Section 4.1.3, we have the following situation:

- The original text is correct if we assume right-to-left bit numbering and little-endian byte order.

- Erratum 1957 is correct if we assume right-to-left bit numbering and big-endian byte order. This change also makes the first sentence of Section 4.1.3 consistent with the sixth bullet in Section 4.2.2.

- Erratum 3546 is correct if we assume left-to-right bit numbering and big-endian byte order.

In the end, the real point is that this document needs a revision that carefully and thoroughly fixes every instance of byte numbering (or removes the byte numbering and refers only to "most significant" and "least significant"). Such a revision should also double-check the sample code in Appendix A to be sure it works in both big-ending and little-endian machines.

Happily, it's not likely that misunderstandings here will cause actual interoperability problems: this isn't a situation where things need to be disassembled and reassembled. The algorithm merely turns a UUID into a URN, and the URN is thereafter a "black box", an unchanged identifier. The only issue would be whether different interpretations of the document would turn two different UUIDs into the same URN, and, given the number of bits involved, the likelihood of collisions in practice is small.

Errata ID: 1957
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Sergey Shandar
Date Reported: 2009-12-03
Held for Document Update by: Barry Leiba
Date Held: 2013-03-20

Section 4.1.3 says:

The version number is in the most significant 4 bits of the time
stamp (bits 4 through 7 of the time_hi_and_version field).

It should say:

The version number is in the most significant 4 bits of the time
stamp (bits 12 through 15 of the time_hi_and_version field).

Notes:

time_hi_and_version is defined as 16 bit field.

--- VERIFIER NOTES ---
This change does make the text in Section 4.1.3 consistent with the sixth
bullet in Section 4.2.2. But the issue goes well beyond that: there is a real
problem with the bit numbering throughout the RFC. Please see erratum
3546 for more details.

Errata ID: 4976
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Joseph Boon
Date Reported: 2017-03-22
Held for Document Update by: Orie Steele
Date Held: 2024-03-29

Throughout the document, when it says:

Set the two most significant bits (bits 6 and 7) of the
clock_seq_hi_and_reserved to zero and one, respectively.

It should say:

Set the two most significant bits (bits 7 and 6) of the
clock_seq_hi_and_reserved to one and zero, respectively.

Notes:

The original wording appears in sections 4.2.2, 4.3, and 4.4. It can lead to confusion about which bit is most significant (6 or 7), and does not align neatly with the table of Variants in section 4.1.1 (which shows 1 followed by 0 for msb0 and msb1). The revised wording specifies the bits in msb order, which helps the reader more clearly correlate the bit values with section 4.1.1. It is noted that the revised wording would not match other parts of the document which give the lsb number first (e.g. "bits 32 through 47"), but this case is different because it is specifying fixed values for two bits, and the sentence starts with "Set the two most significant bits".

RFC 4140, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", August 2005

Note: This RFC has been obsoleted by RFC 5380

Source of RFC: mipshop (int)

Errata ID: 181
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Teemu Huovila
Date Reported: 2006-08-23
Held for Document Update by: Brian Haberman

Section 9.2 says:

This kind of dynamic hierarchy (or anchoring) is only recommended for cases where 
inter-AR u0movement is not frequent.

It should say:

This kind of dynamic hierarchy (or anchoring) is only recommended for cases where 
inter-AR movement is not frequent.

RFC 4151, "The 'tag' URI Scheme", October 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 178
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-11-06
Held for Document Update by: Alexey Melnikov
Date Held: 2010-05-11

Section 5 says:

[2] should refer to RFC 5234
[5] should refer to RFC 4122

Notes:

RFC 2234 was obsoleted by RFC 5234.

RFC 4156, "The wais URI Scheme", August 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 177

Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-09-11
Held for Document Update by: Alexey Melnikov
Report Text:

Section 2 should be consistent with the systematic use of the term "URI instead of "URL"

Rationale:
RFC 3986 (== STD 66), in section 1.1.3., at the bottom of page 7,
specifies:

       ...  Future specifications and related documentation should
   use the general term "URI" rather than the more restrictive terms
   "URL" and "URN" [RFC3305].

Admittedly, RFC1630 and RFC 1738 used the term "URL" -- but that
was long before RFC 3986!

---

RFC 4157, "The prospero URI Scheme", August 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 176

Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-09-11
Held for Document Update by: Alexey Melnikov
Report Text:

Section 2 should be consistent with the systematic use of the term "URI instead of "URL"

Rationale:
RFC 3986 (== STD 66), in section 1.1.3., at the bottom of page 7,
specifies:

... Future specifications and related documentation should
use the general term "URI" rather than the more restrictive terms
"URL" and "URN" [RFC3305].

Admittedly, RFC1630 and RFC 1738 used the term "URL" -- but that
was long before RFC 3986!

---

RFC 4165, "Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Peer-to-Peer Adaptation Layer (M2PA)", September 2005

Source of RFC: sigtran (rai)

Errata ID: 1629
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-12-05
Held for Document Update by: Robert Sparks

Section 1.2, pg.4 says:

                         vvvvv
|  Signal Transfer Point (STP) - A Signal Transfer Point as defined by
   MTP standards, e.g., [Q.700].

                   vvvvv
|  Signaling Point (STP) - A Signaling Point as defined by MTP
   standards, e.g., [Q.700].

It should say:

   Signal Transfer Point (STP) - A Signal Transfer Point as defined by
   MTP standards, e.g., [Q.700].

|  Signaling Point - A Signaling Point as defined by MTP standards,
   e.g., [Q.700].

Notes:

Overloading the same abbreviation in a single document does not
make sense.
The list of Abbreviations (Section 1.3) is in favor of the first
interpretation of "STP", and the second use would be surprising.
Further, the only other use of "STP" in the whole RFC --
in Section 1.5, at the bottom of page 6 -- also expands the
abbreviation according to the first explanation quoted above.
The whole document (besides the quotation above) does not use
an abbreviation for "Signaling Point"; therefore, the proper
resolution seems to be dropping the second instance of "(STP)".

RFC 4186, "Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)", January 2006

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: ops

Errata ID: 1576
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Guy Lespade
Date Reported: 2008-10-16
Held for Document Update by: ron bonica

Section 6.1 says:

Within this section, the 3rd paragraph on page 38 says:

   The receipt of a notification code with the S bit set to one (values
|  32768...65536) does not imply failure.  Notification code "Success"
   (32768) has been reserved as a general notification code to indicate
   successful authentication.

It should say:

   The receipt of a notification code with the S bit set to one (values
|  32768...65535) does not imply failure.  Notification code "Success"
   (32768) has been reserved as a general notification code to indicate
   successful authentication.

Notes:

Within this section, 2nd paragraph on page 38, values start from 0, so they end at 65535 (2^16 - 1).

RFC 4187, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", January 2006

Note: This RFC has been updated by RFC 5448, RFC 9048

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: int

Errata ID: 3968
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Huanggj
Date Reported: 2014-04-19
Held for Document Update by: Brian Haberman
Date Held: 2014-06-05

Section 9.3 says:

   When processing this message, the peer MUST process AT_RAND and
   AT_AUTN before processing other attributes.  Only if these attributes
   are verified to be valid, the peer derives keys and verifies AT_MAC.
   The operation in case an error occurs is specified in Section 6.3.1.

Notes:

The words "these attributes" in sentence "Only if these attributes are verified to be valid, the peer derives keys and verifies AT_MAC." is obscured. It's not clear which attributes are indicated. "AT_RAND and AT_AUTN" or "other attributes"?

Errata ID: 170
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-26
Held for Document Update by: ron bonica
Date Held: 2006-12-01

Section 4.2.5 says:

          |                            +------------------------------+
          |                            | Server does not accept       |
          |                            | The fast re-authentication   |
          |                            | Identity                     |
          |                            +------------------------------+
          |                                                       |
          :                                                       :
          :                                                       :


          :                                                       :
          :                                                       :
          |     EAP-Request/AKA-Identity                          |
          |     (AT_FULLAUTH_ID_REQ)                              |
          |<------------------------------------------------------|

It should say:

          |                            +------------------------------+
          |                            | Server does not accept       |
          |                            | The fast re-authentication   |
          |                            | Identity                     |
          |                            +------------------------------+
          |                                                       |
          |     EAP-Request/AKA-Identity                          |
          |     (AT_FULLAUTH_ID_REQ)                              |
          |<------------------------------------------------------|

Notes:

In Section 4.2.5, Figure 9 (on page 31) contains six lines that
might erroneously be misunderstod to indicate the omission of
some protocol steps (which is not the case).
I suspect that this is an artifact from a draft version where
Figure 9 was split over two pages; after joining the parts,
these continuation indicators have become ambiguous, and hence
should be deleted.

from pending

RFC 4188, "Definitions of Managed Objects for Bridges", September 2005

Source of RFC: bridge (ops)

Errata ID: 786
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-10-17
Held for Document Update by: Dan Romascanu

 

(1)

There is a significant inconsistency in the newly introduced
conformance information with respect to the new
'dot1dStpPortPathCost32' object:

The  bridgeCompliance4188 MODULE-COMPLIANCE  macro
(at the bottom of page 37 and the top of page 38) says:

    GROUP   dot1dStpPortGroup2
        DESCRIPTION
           "Implementation of this group is mandatory for
            bridges that support the Spanning Tree Protocol."

    GROUP   dot1dStpPortGroup3
        DESCRIPTION
           "Implementation of this group is mandatory for bridges
            that support the Spanning Tree Protocol and 32-bit path
            costs.  In particular, this includes devices supporting
            IEEE 802.1t and IEEE 802.1w."

Now (see upper half of page 34), both dot1dStpPortGroup2 and
dot1dStpPortGroup3 contain the object 'dot1dStpPortPathCost32'.
Thus the net result of the above text is that we have two
overlapping but different requirements for that object, and
that the object 'dot1dStpPortPathCost' is not covered by
the bridgeCompliance4188 statement at all.

But, looking at the description clauses for dot1dStpPortPathCost
(on top of page 22) and dot1dStpPortPathCost32 (on page 23)
I conjecture that the original intent was to ALWAYS have
dot1dStpPortPathCost instantiated in rows of the
dot1dStpPortTable (as before, per RFC 1493), and to take
(the new semantics of) the special (max.) value 65535 for
that object as an indication that dot1dStpPortPathCost32 has
also been instantiated in the respective row; therefore, I
expect that dot1dStpPortPathCost should be included in the
conditionally mandatory groups named in bridgeCompliance4188.

The easiest way to remedy this inconsistency would be to modify
the OBJECTS list of the OBJECT-GROUP dot1dStpPortGroup2 by
replacing 'dot1dStpPortPathCost32' by 'dot1dStpPortPathCost'.
But then the definition of dot1dStpPortGroup2 would-be-word
by word identical to the definition of dot1dStpPortGroup (!)
and it might be better to replace 'dot1dStpPortGroup' for
'dot1dStpPortGroup2' on the first line of the text fragment
cited above (bottom of page 37).

Perhaps, an OBJECT clause mentioning the new semantics of the
max. value for dot1dStpPortPathCost in the past-RFC1493
context migth be appropriate as well.

I think that a correction is needed for this issue and would
like to receive your comment before formally submitting an
errata note to the RFC editor.

a) Replace:

    dot1dTpPortInFrames OBJECT-TYPE
        ...
        DESCRIPTION
           "The number of frames that have been received by this
            port from its segment.  Note that a frame received on the
            interface corresponding to this port is only counted by
            this object if and only if it is for a protocol being
            processed by the local bridging function, including
            bridge management frames."

   by:

    dot1dTpPortInFrames OBJECT-TYPE
        ...
        DESCRIPTION
           "The number of frames that have been received by this
            port from its segment.  Note that a frame received on
            the interface corresponding to this port is counted by
            this object if and only if it is consumed by the local
            bridging function, including bridge management frames."

b) Replace:

    dot1dTpPortOutFrames OBJECT-TYPE
        ...
        DESCRIPTION
           "The number of frames that have been transmitted by this
            port to its segment.  Note that a frame transmitted on
            the interface corresponding to this port is only counted
            by this object if and only if it is for a protocol being
            processed by the local bridging function, including
            bridge management frames."
   by:

    dot1dTpPortOutFrames OBJECT-TYPE
        ...
        DESCRIPTION
           "The number of frames that have been transmitted by this
            port to its segment.  Note that a frame transmitted on
            the interface corresponding to this port is counted by
            this object if and only if it originates from a local
            bridging function, including bridge management frames."

It should say:

[see above]

Notes:

Please correct me if this proposal does not match the original
intent of these DESCRIPTIONs.
(Concern: If the bridge is manageable, the management agent might
reside on the bridge that in this case would have an IP address and
perform the SNMP protocol stack and/or other IP protocols as well.
It might be the case that it was intended to include such locally
destined/originated packets of non-IEEE802.1D functions into the
above counters as well.
Important remark: IEEE802.1D clause 14.6.1.1.3, e.g., includes
"BPDUs, frames addressed to the Bridge as an end station, and
frames that were submitted to the forwarding process" into the
'Frames Received' count! Therefore, the REFERENCE clauses pointing
to that 802.1D clause might be considered inappropriate as well,
for both objects.)


from pending

RFC 4191, "Default Router Preferences and More-Specific Routes", November 2005

Source of RFC: ipv6 (int)

Errata ID: 1838
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Glen Zorn
Date Reported: 2009-08-24
Held for Document Update by: Brian Haberman

Section 2.1 says:

   Default router preferences and preferences for more-specific routes
   are encoded the same way.

   Preference values are encoded as a two-bit signed integer, as
   follows:

      01      High
      00      Medium (default)
      11      Low
      10      Reserved - MUST NOT be sent

   Note that implementations can treat the value as a two-bit signed
   integer.

It should say:

   Default router preferences and preferences for more-specific routes
   are encoded the same way.

   Preference values are encoded in 2 bits, as
   follows:

      01      High
      00      Medium (default)
      11      Low
      10      Reserved - MUST NOT be sent

   Note that implementations can treat the value as a two-bit signed
   integer.

Notes:

The characterization of route preferences as a 2-bit integer is extremely confusing. Fortunately, -(0) is not used, but even so there seems to be little rationale for looking treating the preference as a signed rather than unsigned value.

RFC 4197, "Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks", October 2005

Source of RFC: pwe3 (int)

Errata ID: 1534
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Immad Mir
Date Reported: 2008-10-02
Held for Document Update by: Stewart Bryant

Section 4.3 says:

          +---------------+               +---------------+
          |      PE1      |               |      PE2      |
       K  |   +--+        |               |        +--+   |  G
       |  |   | J|        |               |        | H|   |  |
       v  |   v  |        |               |        v  |   |  v
   +---+  | +-+  +-+  +-+ |  +--+   +--+  | +-+  +-+  +-+ |  +---+
   |   |  | |P|  |D|  |P| |  |  |   |  |  | |P|  |E|  |P| |  |   |
   |   |<===|h|<:|e|<:|h|<:::|  |<::|  |<:::|h|<:|n|<=|h|<===|   |
   |   |  | |y|  |c|  |y| |  |  |   |  |  | |y|  |c|  |y| |  |   |
   | C |  | +-+  +-+  +-+ |  |  |   |  |  | +-+  +-+  +-+ |  | C |
   | E |  |               |  |S1|   |S2|  |               |  | E |
   | 1 |  | +-+  +-+  +-+ |  |  |   |  |  | +-+  +-+  +-+ |  | 2 |
   |   |  | |P|  |E|  |P| |  |  |   |  |  | |P|  |D|  |P| |  |   |
   |   |===>|h|=>|n|:>|h|:::>|  |::>|  |:::>|h|:>|e|=>|h|===>|   |
   |   |  | |y|  |c|  |y| |  |  |   |  |  | |y|  |c|  |y| |  |   |
   +---+  | +-+  +-+  +-+ |  +--+   +--+  | +-+  +-+  +-+ |  +---+
    ^  ^  |   |  ^        |               |        |  ^   |  ^  ^
    |  |  |   |B |        |<------+------>|        |  |   |  |  |
    |  A  |   +--+        |       |       |        +--+-E |  F  |
    |     +---------------+      +-+      +---------------+     |
    |             ^              |I|               ^            |
    |             |              +-+               |            |
    |             C                                D            |
    +-----------------------------L-----------------------------+

It should say:

          +---------------+               +---------------+
          |      PE1      |               |      PE2      |
       K  |   +--+        |               |        +--+   |  G
       |  |   | J|        |               |        | H|   |  |
       v  |   v  |        |               |        v  |   |  v
   +---+  | +-+  +-+  +-+ |  +--+   +--+  | +-+  +-+  +-+ |  +---+
   |   |  | |P|  |D|  |P| |  |  |   |  |  | |P|  |E|  |P| |  |   |
   |   |<===|h|<=|e|<:|h|<:::|  |<::|  |<:::|h|<:|n|<=|h|<===|   |
   |   |  | |y|  |c|  |y| |  |  |   |  |  | |y|  |c|  |y| |  |   |
   | C |  | +-+  +-+  +-+ |  |  |   |  |  | +-+  +-+  +-+ |  | C |
   | E |  |               |  |S1|   |S2|  |               |  | E |
   | 1 |  | +-+  +-+  +-+ |  |  |   |  |  | +-+  +-+  +-+ |  | 2 |
   |   |  | |P|  |E|  |P| |  |  |   |  |  | |P|  |D|  |P| |  |   |
   |   |===>|h|=>|n|:>|h|:::>|  |::>|  |:::>|h|:>|e|=>|h|===>|   |
   |   |  | |y|  |c|  |y| |  |  |   |  |  | |y|  |c|  |y| |  |   |
   +---+  | +-+  +-+  +-+ |  +--+   +--+  | +-+  +-+  +-+ |  +---+
    ^  ^  |   |  ^        |               |        |  ^   |  ^  ^
    |  |  |   |B |        |<------+------>|        |  |   |  |  |
    |  A  |   +--+        |       |       |        +--+-E |  F  |
    |     +---------------+      +-+      +---------------+     |
    |             ^              |I|               ^            |
    |             |              +-+               |            |
    |             C                                D            |
    +-----------------------------L-----------------------------+

Notes:

From the figure, the DEC on PE1 has an emulated input AND an emulated output. It appears that the PHY on PE1 converts the Emulated traffic into Attachment Circuit.
However, the DEC should have Emulated traffic at input and Attachment Circuit at the output. Therefore the output of DEC on PE1 should be '<=' not '<:'

RFC 4204, "Link Management Protocol (LMP)", October 2005

Note: This RFC has been updated by RFC 6898

Source of RFC: ccamp (rtg)

Errata ID: 823
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-12-20
Held for Document Update by: Adrian Farrel

 

(1)

Section 10 specifies the required behaviour of *aperiodic*
transmission retries with exponential backoff.

(1a)
Nevertheless, at various places the text talks about "periodically"
transmitting certain messages.  It should better say "repeated[ly]".

Examples for this issue are:
  -  Section 11.1.1, page 28 : introduction, and
     the paragraphs labelled "ConfSend:" and "Active:" ;
  -  Section 11.1.2, page 30, text for event '12a)' ;
  -  Section 11.2.1, page 32 : introduction, and
     the paragraphs labelled "Init:" and "Up:" ;
  -  Section 11.3.1, page 35 : paragraph labelled "Test:" ;
  -  Section 12.3.1, page 42, last paragraph;
  -  Section 12.4, page 43, last paragraph;
  -  Section 12.5.1, page 44, last paragraph;
  -  Section 12.5.4, first line on page 46;
  -  Section 12.5.6, final paragraph on page 46 (twice);
  -  Section 12.6.1, second paragraph on page 48.

(1b)
At the bottom of page 26, Section 10.1 defines the following
parameter:

   Rapid retry limit Rl:

      Rl is the maximum number of times a message will be transmitted
      without being acknowledged.

The naming of this variable is very unfortunate because in similar
contexts in protocol design, the "retry limit" customarily defines the
(maximum) number of *re*-tries -- with 0 meaning no retries at all,
1 meaning a single retry, etc.
The definition given means that the maximum number of retries will
be  <Rl> - 1 , thereby restricting the allowed range for <Rl> to 1
or above, excluding the value 0, without mentioning this fact.

Because Section 10.2 codifies the abovementioned definition and this
certainly should not be changed after the fact of publication as an
RFC, it might be advisable to post a warning note pointing to the
specific semantics of 'retry limit' with LMP, the admitted value
range, and in particular the use '1' for <Rl> to inhibit retries.


(2)

Section 12.2, on page 41, codifies an (unfortunately very popular)
design flaw: the 'Length' field in LMP objects is specified as
comprising the cumulative size of the object contents *and* the
object prefix (4 bytes).  This unnecessarily creates illegal
values (0..3) for 'Length' which must be checked for in all
implementations.  It would have been very muck preferrable to have
'Length' just giving the size of the object contents (in bytes),
whereby Length=0 would be the very mnemonic (and most efficiently
testable) condition for empty object content

[Note: In the case of LMP objects the 16 bit width of length does
 not constitute an artificial limitation to the size of the object
 contents, because the whole message must be shorter than 2**16
 bytes. This *is* a problem, e.g., for RADIUS with its single-octet
 'Length' !]


(3)

In Section 13.2, on page 51, the explanatory text after the diagram
for 'C-Type = 1' says:

  Node_Id:

     This identities the node that originated the LMP packet.
                ^
where it should say:

  Node_Id:

     This identifies the node that originated the LMP packet.
                ^
Similarly, following the diagram for 'C-Type = 2', the same section
says at the top of page 52:

   Node_Id:

      This identities the remote node.
                 ^
where it should say:

  Node_Id:

      This identifies the remote node.
                 ^

(4) Section 13.8

a) The explanation for "Flags:" on page 57 contains the improperly
indented and punctuated entry:

      vvv
         0x0002 Data Link Type

            If set, the data links to be verified are ports, otherwise
            they are component links
                                    ^
It should specify instead:

      0x0002 Data Link Type

            If set, the data links to be verified are ports, otherwise
            they are component links.
                                    ^

b) The explanation for "Verify Transport Mechanism:", on top of
page 58, contains:

      0x8000 Payload:Test Message transmitted in the payload
                    ^^
It should say:

      0x8000 Payload: Test Message transmitted in the payload
                    ^^^


(5) Wavelength encodings

This issue is related to:
  -  Section 13.8, on page 57/58,  and
  -  Section 13.12.1, on page 64 plus Section 13.12.1.2 on page 65.

Obviously -- and unfortunately --, RFC 4204 avoids specifying the
admissible encoding[s] and the related units for data elements
specifying Wavelengths.

I suspect there could not be reached consensus on a single encoding
style.  Nevertheless it would have been very desirable for the sake
of interoperability to specify a (small) set of standard encodings,
e.g.:
  -  IEEE floating point, units: meters;
  -  unsigned32, units: nanometers (or picometers?);
  -  unsigned32 implementation specific wavelength identifiers;
  -  0 always meaning: 'implicit / known by out-of-band methods'.

All occurences on 'Wavelength' data elements would have allowed for
the addition of some kind of 'wavelength encoding selector', e.g.
as a 2-/3-/4-bit subfield of the already present 'Flags' field,
or separate values of the already present 'subobject type'.


(6)
Section 13.12.1 says:

    This is used to identify the local Interface Switching Type of the TE link as defined in [RFC3471].

It should say:

    This is used to identify the local Interface Switching Type of the Data link as defined in [RFC3471]. 

(7)

Section 16, near the bottom of page 77, contains wording inconsistent
the remainder of this section and with other parts of the document.
The two paragraphs:

   The policy for allocating values out of the LMP Object Class name
   space is part of the definition of the specific Class instance.  When
   a Class is defined, its definition must also include a description of
   the policy under which the Object Class names are allocated.

   The policy for allocating values out of the LMP Sub-object Class name
   space is part of the definition of the specific Class instance.  When
   a Class is defined, its definition must also include a description of
   the policy under which sub-objects are allocated.

should better say:
                                                                vvvv
   The policy for allocating values out of the LMP Object Class type
   (C-type) name space is part of the definition of the specific Class
   instance.  When a Class is defined, its definition must also include
   a description of the policy under which the Object Class types are
   allocated.

   The policy for allocating values out of the LMP Sub-object Class type
   (C-type) name space is part of the definition of the specific Class
   instance.  When a Class is defined, its definition must also include
   a description of the policy under which sub-objects are allocated.

[Notes:
 The primary name space is the Class type (C-type) name space because
 its management is essential for interoperability; the class names are
 subordinated additional labels for the human reader and implementor.
 Above, I have added "(C-type)" for clarity; this is not absolutely
 necessary, if you dislike the repetition here.
]


(8)

There's another small typo in Section 16, at mid-page 82:
The headline:

   o CHANNEL_STATUS_REQUESTClass name (14)

should be:

   o CHANNEL_STATUS_REQUEST Class name (14)

It should say:

[see above] 

Notes:

from pending

RFC 4210, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", September 2005

Note: This RFC has been updated by RFC 6712, RFC 9480, RFC 9481

Source of RFC: pkix (sec)

Errata ID: 5731
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Lijun Liao
Date Reported: 2019-05-22
Held for Document Update by: Roman Danyliw
Date Held: 2022-04-27

Throughout the document, when it says:

N/A

It should say:

N/A

Notes:

In appendixes D.4, D.5, E.5 and E.6, the recipient field of requests and the sender field of responses are specified as "the name of the CA". It is no problem for CA which signs the CMP response.

However, as best practice, the CA's private key which is used to sign the certificates, is NOT RECOMMENDED to sign/decrypt the communication messages. In this case, another entity (private key + certificate) is used to decrypt the incoming messages and sign the outgoing ones.

The text and comment for the fields "recipient" in requests and "sender" in responses need to be corrected to the case described above. If you think the original text and comment are correct, then we need instruction on how to handle this case.

Errata ID: 2615
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2010-11-08
Held for Document Update by: Sean Turner

Section Appendix C says:

   -- **********
   -- * For the purposes of this specification, the ASN.1 comment
   -- * given in [CRMF] pertains not only to certTemplate, but
   -- * also to the altCertTemplate control.  That is,
   -- **********

It should say:

   -- **********
   -- * For the purposes of this specification, the ASN.1 comment
   -- * given in [CRMF] pertains not only to certTemplate, but
   -- * also to the altCertTemplate control. 
   -- **********

Errata ID: 2616
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2010-11-09
Held for Document Update by: Sean Turner

Section 5.1.3.1 says:

   Note: it is RECOMMENDED that the fields of PBMParameter remain
   constant throughout the messages of a single transaction (e.g.,
   ir/ip/certConf/pkiConf) in order to reduce the overhead associated
   with PasswordBasedMac computation).

It should say:

   Note: it is RECOMMENDED that the fields of PBMParameter remain
   constant throughout the messages of a single transaction (e.g.,
   ir/ip/certConf/pkiConf) in order to reduce the overhead associated
   with PasswordBasedMac computation.

Errata ID: 7888
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sylvain Etienne
Date Reported: 2024-04-09
Held for Document Update by: RFC Editor
Date Held: 2024-04-09

Section 5.3.2. says:

An Initialization response message contains as the PKIBody an
CertRepMessage data structure,

It should say:

An Initialization response message contains as the PKIBody a
CertRepMessage data structure,

Notes:

typo (an > a)

RFC 4211, "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", September 2005

Note: This RFC has been updated by RFC 9045

Source of RFC: pkix (sec)

Errata ID: 166
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Held for Document Update by: Sean Turner

Section 4.1 says:

     algorithmIdentifier  identifiers the signature algorithm and an
     associated parameters used to produce the POP value.

     signature  contains the POP value produce.

It should say:

     algorithmIdentifier  identifies the signature algorithm and
     associated parameters used to produce the POP value.

     signature  contains the POP value produced

Notes:

Errata ID: 2339
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Held for Document Update by: Tim Polk
Date Held: 2010-07-20

Section B says:

Near the middle of page 32, contains the following [commented out] ASN.1, and ASN.1 comment:

  -- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
         -- The contents of this type correspond to RFC 2279.
                                                        ^^^^

The RFC should say:

  -- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
         -- The contents of this type correspond to RFC 3629.

It should say:

[see above]     

Notes:

RFC 2279 has been obsoleted by RFC 3629 == STD 63 "long" ago.

I am aware of the fact that the UTF-8 definition in RFC 3629
syntactically and semantically by intention is a proper subset
of the definition in RFC 2279 (restriction to possible Unicode
codepoints with up to 24-bit representation).

Thus, it might be true that the reference to RFC 2279 has been
used intentionally in this ASN.1 comment, e.g., because RFC 3280
[PROFILE] (pre-3629!) referred to RFC 2279 in that context.
But, regarding the STD status of RFC 3629, a standards track RFC
like RFC 4211 should, in this case, present explicit arguments
for the deviation from STD 63. (It doesn't.)

Errata ID: 2347
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Held for Document Update by: Tim Polk
Date Held: 2010-07-20

Section 7.1 says:

Subsequently, near the top of page 24, the same section says:

                        vvvvvvvvv
   The %xx mechanism of [RFC1738] is used to encode '?' (%3f) and '%'
   (%25) if they are not being used for their reserved purpose.  Names
   MUST NOT start with a numeric character.

It should better say:

                        vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
   The %xx mechanism of Section 2.1 of STD 66 [RFC3986] is used to
   encode '?' (%3f) and '%' (%25) if they are not being used for their
   reserved purpose.  Names MUST NOT start with a numeric character.

It should say:

[see above]     

Notes:

Rationale: RFC 1738 has been obsoleted; the %-escaping method is now covered by the above mentioned section of that Internet Standard.

Errata ID: 2349
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Held for Document Update by: Tim Polk
Date Held: 2010-07-20

Section 10.2 says:

On page 27, contains the following Ref. as its final entry:

   [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
             Resource Locators (URL)", RFC 1738, December 1994.

It should say:

[see above]     

Notes:

According to Errata 2348, this should be removed, and a new Ref.
[RFC3986] added -- to be taken from rfc-ref.txt .
Given the nature and context of the use of this Ref. in section 7.1
-- see item (11) above -- and the STD Status of RFC 3986, then
perhaps it is advisable to place this new Ref. into Section 10.1,
Normative References, not in section 10.2, Informative References.

Errata ID: 2340
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Held for Document Update by: Sean Turner
Date Held: 2010-07-29

Section 4.2.1 says:

In the last paragraph on page 11 says:

      identifier contains a name that the CA/RA can associate with the
      requestor.  This will generally be either the DN of a certificate
      or a text token passed and known to both the requestor and the
      CA/RA.  ...

It should say:

identifier contains a name that the CA/RA can associate with the requestor.
This will generally be either a portion of either a subject name or subject
alternative name (either from an existing certificate or from the
certificate request) or a text token passed and known to both the requestor
and the CA/RA.  

Notes:

The location of the DN material will vary based on the question of whether
this is an archive operator or a POP operation.

Errata ID: 2342
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Held for Document Update by: Sean Turner
Date Held: 2010-07-20

Section 4.4 says:

In the first text line on page 15, says:

   The fields of PEMParameter have the following meaning:
                  ^

It should say:
                  v
   The fields of PBMParameter have the following meaning:

It should say:

[see above]     

Notes:

Rationale: an OCR problem???

Changed to editorial.

Errata ID: 2341
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Held for Document Update by: Sean Turner
Date Held: 2010-07-20

Section 4.4 says:

The ASN.1 fragment at the bottom of page 14, says:

      PBMParameter ::= SEQUENCE {
         salt                OCTET STRING,
         owf                 AlgorithmIdentifier,
         iterationCount      INTEGER,
         mac                 AlgorithmIdentifier
         )
        ^^^

It should say:

      PBMParameter ::= SEQUENCE {
         salt                OCTET STRING,
         owf                 AlgorithmIdentifier,
         iterationCount      INTEGER,
         mac                 AlgorithmIdentifier
         }

It should say:

[see above]     

Errata ID: 2343
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Held for Document Update by: Sean Turner
Date Held: 2010-07-20

Section 6.1 says:

In the first paragraph on page 19, refers to a wrong subsection; it says:

   The regToken control is used only for initialization of an end entity
   into the PKI, whereas the authenticator control (see section 7.2) can
                                                                ^
   be used for the initial as well as subsequent certification requests.

It should say:

   The regToken control is used only for initialization of an end entity
   into the PKI, whereas the authenticator control (see section 6.2) can
   be used for the initial as well as subsequent certification requests.

It should say:

[see above]     

Notes:

Changed to editorial.

Errata ID: 2344
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Held for Document Update by: Sean Turner
Date Held: 2010-07-20

Section 6.3 says:

In the upper half of page 20, says:

   The fields of PKIPublicationInfo have the following meaning:

      action indicates whether or not the requestor wishes the CA/RA to
      publish the certificate.  The values and their means are:
                                                        ^^

It should say:

   The fields of PKIPublicationInfo have the following meaning:

      action indicates whether or not the requestor wishes the CA/RA to
      publish the certificate.  The values and their meanings are:

It should say:

[see above]     

Notes:

Changed to editorial.

Errata ID: 2345
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Held for Document Update by: Tim Polk
Date Held: 2010-07-29

Section 6.3 says:

At the bottom of page 20, says:

  The fields of SinglePubInfo have the following meaning:

      pubMethod indicates the address type for the location at which the
      requestor desires the certificate to be placed by the CA/RA.

         dontCare indicates that the CA/RA can publish the certificate
         in whatever locations it chooses.  If dontCare is used, the
         pubInfos field MUST be omitted.
            ^^^^^

(To make the full context visible, I have shown more text than
would be necessary for the errata note.)
>From the context, I strongly suspect that the RFC text should say:

  The fields of SinglePubInfo have the following meaning:

      pubMethod indicates the address type for the location at which the
      requestor desires the certificate to be placed by the CA/RA.

         dontCare indicates that the CA/RA can publish the certificate
         in whatever locations it chooses.  If dontCare is used, the
         pubLocation field MUST be omitted.
            ^^^^^^^^

It should say:

[see above]     

Notes:

Rationale: pubInfos is a "SEQUENCE SIZE (1..MAX) OF SinglePubInfo".
I cannot imagine how a certain value of a SinglePubInfo instance
subfield can ever imply a MUST to omit the full enclosing structure,
pubInfos -- which would have removed this subfield as well :-) .
Perhaps, the text has been cloned from the explanation of the
'dontPublish' value of the PKIPublicationInfo.action filed given
just below the text excerpt reproduced under item (7) above
without fully applying the proper changes.

Errata ID: 2346
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Held for Document Update by: Sean Turner
Date Held: 2010-07-20

Section 6.4 says:

At the bottom of page 22, says:

   The fields of EncryptedKey have the following meaning:

      encryptedValue is longer used.  This field has been deprecated
      along with the EncryptedValue structure.

It should say:

   The fields of EncryptedKey have the following meaning:
                        vvvv
      encryptedValue  is no longer used.  This field has been
      deprecated along with the EncryptedValue structure.

It should say:

[see above]     

Notes:

Changed to editorial.

Errata ID: 2348
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Held for Document Update by: Sean Turner
Date Held: 2010-07-20

Section 9 says:

In the first paragraph on page 26, contains the sentence:

                                                     ...  The user can
   claim that an item was signed by the entity that generated the key as
   well as any entity that might have seen the key value during transfer
   from the generator the to EE.  ...
                      ^^^^^^
It should say:

                                                     ...  The user can
   claim that an item was signed by the entity that generated the key as
   well as any entity that might have seen the key value during transfer
   from the generator to the EE.  ...
                      ^^^^^^

It should say:

[see above]     

Notes:

Changed to editorial.

Errata ID: 2350
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Held for Document Update by: Sean Turner
Date Held: 2010-07-29

Section A.2 says:

In the last ASN.1 fragment on page 31, says:

   IP address (identifier "I"):
      <iname> ::= <oid>
                  ^^^^^

It should say:

[see above]     

Notes:

The text should clarify what is meant by <oid> which is not defined in this
document nor is it a standard BNF item. It should be considered if a BNF
reference should be added. It should be made clearer what the different
terminals mean.

Errata ID: 2595
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2010-10-29
Held for Document Update by: Sean Turner

Section 2.1 says:

   7.  Replaced Appendix A with a reference to [RFC2875].  The only
       difference is that the old text specified to use subject alt name
       instead of subject name if subject name was empty.  This is not
       possible for a CA certificate issued using PKIX.  It would
       however be useful to update RFC 2875 to have this fallback
       position.

   7.  Insert Appendix C describing why POP is necessary and what some
       of the different POP attacks are.

   8.  pop field in the CertReqMsg structure has been renamed to popo to
       avoid confusion between POP and pop.

   9.  The use of the EncryptedValue structure has been deprecated in
       favor of the EnvelopedData structure.

   10.  Add details on how private keys are to be structured when
       encrypted.

   11.  Allow for POP on key agreement algorithms other than DH.

It should say:

   7.  Replaced Appendix A with a reference to [RFC2875].  The only
       difference is that the old text specified to use subject alt name
       instead of subject name if subject name was empty.  This is not
       possible for a CA certificate issued using PKIX.  It would
       however be useful to update RFC 2875 to have this fallback
       position.

   8.  Insert Appendix C describing why POP is necessary and what some
       of the different POP attacks are.

   9.  pop field in the CertReqMsg structure has been renamed to popo to
       avoid confusion between POP and pop.

   10. The use of the EncryptedValue structure has been deprecated in
       favor of the EnvelopedData structure.

   11.  Add details on how private keys are to be structured when
       encrypted.

   12.  Allow for POP on key agreement algorithms other than DH.

Notes:

Item 7 erroneously repeated.

RFC 4213, "Basic Transition Mechanisms for IPv6 Hosts and Routers", October 2005

Source of RFC: v6ops (ops)

Errata ID: 2172
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Fernando Gont
Date Reported: 2010-04-25
Held for Document Update by: Ron Bonica

Section 4 says:

The issue and the remainder threats are discussed at more length in Security Considerations.

It should say:

This issue and the remainder threats are discussed at more length in Security Considerations.

RFC 4217, "Securing FTP with TLS", October 2005

Note: This RFC has been updated by RFC 8996

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 165
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-11-09
Held for Document Update by: Alexey Melnikov

Abstract says:

This document
   is intended to provide TLS support for FTP in a similar way to that
   provided for SMTP in RFC 2487, "SMTP Service Extension for Secure
   SMTP over Transport Layer Security", and HTTP in RFC 2817, "Upgrading
   to TLS Within HTTP/1.1.".

It should say:

This document
   is intended to provide TLS support for FTP in a similar way to that
   provided for SMTP in RFC 3207, "SMTP Service Extension for Secure
   SMTP over Transport Layer Security", and HTTP in RFC 2817, "Upgrading
   to TLS Within HTTP/1.1.".

Notes:

the remainder of the text (including the References section)
correctly refers to RFC 3207 that once had obsoleted RFC 2487

RFC 4226, "HOTP: An HMAC-Based One-Time Password Algorithm", December 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 2404
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-01-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-30

Section A.3 says:

   Oracle AuthO()
   --------------
      A = ALG(K,C)
      C = C + 1
      Return O to B

   Oracle VerO(A)
   --------------
      i = C
      While (i <= C + s - 1 and Win == FALSE) do
         If A == ALG(K,i) then Win = TRUE; C = i + 1
         Else i = i + 1
      Return Win to B

It should say:

   Oracle AuthO()
   --------------
      A = ALG(K,C)
      C = C + 1
|     Return A to B

   Oracle VerO(A)
   --------------
|     i = C'
|     While (i <= C' + s - 1 and Win == FALSE) do
|        If A == ALG(K,i) then Win = TRUE; C' = i + 1
         Else i = i + 1
      Return Win to B

Notes:

another typo, and continuation of Errata ID 2402.

Still in Appendix A.3, the text on the upper half of page 19 contains
a wrong (undefined) variable name 'O' which should be 'A' instead,
and it should be adapted according to [Errata ID 2402].

Errata ID: 2406
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-01-18
Held for Document Update by: Tim Polk
Date Held: 2011-03-27

Appendix A.4.3 says:

   Proposition 2 ------------- Suppose m = 10^Digit < 2^31, and let
   (q,r) = IntDiv(2^31,m).  Let B be any adversary attacking HOTP-IDEAL
   using v verification oracle queries and a <= 2^c - s authenticator
   oracle queries.  Then [...]

It should say:

  Proposition 2
  -------------

  Suppose m = 10^Digit < 2^31, and let (q,r) = IntDiv(2^31,m).  Let B
  be any adversary attacking HOTP-IDEAL using v verification oracle
  queries and a <= 2^c - s authenticator oracle queries.  Then  [...]

Errata ID: 2408
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-01-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-30

Section C says:

       // These are used to calculate the check-sum digits.
|      //                                0  1  2  3  4  5  6  7  8  9
       private static final int[] doubleDigits =
                       { 0, 2, 4, 6, 8, 1, 3, 5, 7, 9 };

It should say:

       // These are used to calculate the check-sum digits.
|      //                0  1  2  3  4  5  6  7  8  9
       private static final int[] doubleDigits =
                       { 0, 2, 4, 6, 8, 1, 3, 5, 7, 9 };

Notes:

formatting.

In Appendix C, the source text in the upper half of page 28
contains an improperly formatted comment -- obviously intended
to illustrate the subsequent declaration, the comment must be
aligned with that declaration.

Errata ID: 2401
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-01-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-30

Section A.1 says:

   Let IntDiv(a,b) denote the integer division algorithm that takes
|  input integers a, b where a >= b >= 1 and returns integers (q,r)
|
   the quotient and remainder, respectively, of the division of a by b.
   (Thus, a = bq + r and 0 <= r < b.)

It should say:

   Let IntDiv(a,b) denote the integer division algorithm that takes
|  input integers a, b where  b >= 1  and returns integers (q,r), the
   quotient and remainder, respectively, of the division of a by b.
   (Thus, a = bq + r and 0 <= r < b.)

Notes:

inappropriate restriction specified + formatting flaw.

On page 17, Appendix A.1:
The restriction "a >= b" is not necessary and in fact inappropriate; the additional blank line seems to be an artifact of the editing process. Thus, the above text should better read [as above].

Errata ID: 834
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-01-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-30

Section E.4 says:

   1) C-client >= C-server
   2) C-client - C-server <= s
   3) Check that HOTP client is valid HOTP(K,C-Client)
   4) If true, the server sets C to C-client + 1 and client is
      authenticated                           ^^^
                              ^^^             ^^^

It should say:

   1) C-client >= C-server
   2) C-client - C-server <= s
|  3) Check that HOTP client is valid HOTP(K,C-client)
|  4) If true, the server sets C-server to C-client + 1 and client is
      authenticated

Notes:

Lines up with Errata ID 2402.

The enumeration in Appendix E.4, on page 34, contains inconsistent
variable namings (cf. [Errata ID 2402]!).
To make it self-consistent, change as detailed.

Errata ID: 2405
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-01-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-30

Section A.4.1 says:

(6)  [ typos in mathematical text ]

Lemma 1 and its proof in Appendis A.4.1, on page 20, contains
several typos.

In Lemma 1, the line,

          P_{N,m}(z) = Pr [x mod m = z : x randomly pick in Z_{n}]
                                                              ^^^
should read:

          P_{N,m}(z) = Pr [x mod m = z : x randomly pick in Z_{N}]

This corrects the use of an undefined variable, n, by using the
variable N as expected from the LHS term.

In the Proof of Lemma 1, the case distinction for z contains an
improper relational operator at two places.
To adjust to the possible range of values (cf. item (2) above!),
the formula parts:

   P_{N,m}(z)  =  [ ... ]

                = mq/N * 1/m +
                   (N - mq)/N * 1 / (N - mq)     if 0 <= z < N - mq
|                  0                             if N - mq <= z <= m
                                                               ^^^^
                = q/N +
                   r/N * 1 / r                   if 0 <= z < N - mq
|                  0                             if r <= z <= m
                                                          ^^^^
should be modified to read:

   P_{N,m}(z)  =  [ ... ]

                = mq/N * 1/m +
                   (N - mq)/N * 1 / (N - mq)     if 0 <= z < N - mq
|                  0                             if N - mq <= z < m

                = q/N +
                   r/N * 1 / r                   if 0 <= z < N - mq
|                  0                             if r <= z < m

It should say:

see above

Notes:

typos

Errata ID: 2402
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-01-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-30

Section A.3 says:

   The scenario we are considering is that a user and server share a key
   K for ALG.  Both maintain a counter C, initially zero, and the user
   authenticates itself by sending ALG(K,C) to the server.  The latter
   accepts if this value is correct.

   In order to protect against accidental increment of the user counter,
   the server, upon receiving a value z, will accept as long as z equals
   ALG(K,i) for some i in the range C,...,C + s-1, where s is the
   resynchronization parameter and C is the server counter.  If it
   accepts with some value of i, it then increments its counter to i+1.
   If it does not accept, it does not change its counter value.

It should say:

   The scenario we are considering is that a user and server share a key
|  K for ALG.  Both maintain a counter C and C', respectively, initially
   zero, and the user authenticates itself by sending ALG(K,C) to the
   server.  The latter accepts if this value is correct.

   In order to protect against accidental increment of the user counter,
   the server, upon receiving a value z, will accept as long as z equals
|  ALG(K,i) for some i in the range C',...,C' + s-1, where s is the
|  resynchronization parameter and C' is the server counter.  If it
   accepts with some value of i, it then increments its counter to i+1.
   If it does not accept, it does not change its counter value.

Notes:

conflicting naming of variables.

re: the text of the 2nd and 3rd paragraph of Appendix A.3, on page 18

In Appendix A.3, unfortunately the necessary distinction between
the counter value kept with the user and the counter value kept
at the server is not preserved in the variable names introduced.
This leads to significant confusion.

I hereby propose a 'minimally invasive' text modification as
[shown] (Cf. Appendix E.3 for another notation).

Errata ID: 5792
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Jeffrey Goldberg
Date Reported: 2019-07-24
Held for Document Update by: Benjamin Kaduk
Date Held: 2019-07-29

Section 5.3 says:

Implementations MUST extract a 6-digit code at a minimum and possibly
7 and 8-digit code.  Depending on security requirements, Digit = 7 or
more SHOULD be considered in order to extract a longer HOTP value.

It should say:

Implementations MUST extract a 6-digit code at a minimum and possibly
7, 8 and 9-digit code.  Depending on security requirements, Digit = 7
or more SHOULD be considered in order to extract a longer HOTP value.
The code MUST NOT exceed 9 digits. 

Notes:

Although the detailed description of the dynamic truncation algorithm makes is clear that the code is generated from a 31 bit value, it is not explicitly stated in the main sections of the RFC that nine digits is the maximum number of digits supported by the algorithm.

The fact that nine digits is the maximum supported is alluded to in E.2, but this should be made more clear.

There are reports that TOTP implementations in the wild are supporting 10 digit codes. That mistaken behavior would be better discouraged by clarifying the limit of digits to 9.

Errata ID: 2400
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-01-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-30

Section 5.3 says:

   The reason for masking the most significant bit of P is to avoid
   confusion about signed vs. unsigned modulo computations.  Different
   processors perform these operations differently, and masking out the
|  signed bit removes all ambiguity.
       ^^
   Implementations MUST extract a 6-digit code at a minimum and possibly
   7 and 8-digit code.  Depending on security requirements, Digit = 7 or
   more SHOULD be considered in order to extract a longer HOTP value.

It should say:

   The reason for masking the most significant bit of P is to avoid
   confusion about signed vs. unsigned modulo computations.  Different
   processors perform these operations differently, and masking out the
|  sign bit removes all ambiguity.

   Implementations MUST extract a 6-digit code at a minimum and possibly
|  7 and 8-digit codes.  Depending on security requirements, Digit = 7
   or more SHOULD be considered in order to extract a longer HOTP value.

Notes:

Editorial fixes.

re: the text of Section 5.3, in the 2nd and 3rd paragraph on page 7.

Errata ID: 2403
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-01-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-30

Section A.3 says:

                                                    ...  It wins if the
   server accepts this accumulator.
                       ^^^^^^^^^^^

It should say:

                                                    ...  It wins if the
   server accepts this authenticator.

Notes:

typo. near the bottom of page 18, the 2nd-to-last paragraph of Appendix A.3
(on that page).

Errata ID: 2407
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-01-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-30

Section A.5 says:

   Let T denotes the time to perform one computation of H.  [...]
               ^

It should say:

   Let T denote the time to perform one computation of H.  [...]

Notes:

typo. within Appendix A.5, in the lower half of page 23, the text for
"Assumption 1".

Errata ID: 2409
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-01-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-30

Section C says:

In Appendix C, the source code on page 30 (lower half) and
page 31 contains improperly indented lines.

The following three line groups should be indented by 6 more character
positions to make them conformant to RFC style 'nice' format:

- on page 30:

     String result = null;
     int digits = addChecksum ? (codeDigits + 1) : codeDigits;

- on page 30:

     if ( (0<=truncationOffset) &&
            (truncationOffset<(hash.length-4)) ) {
         offset = truncationOffset;
     }

- on page 31:

     if (addChecksum) {
         otp =  (otp * 10) + calcChecksum(otp, codeDigits);
     }
     result = Integer.toString(otp);
     while (result.length() < digits) {
         result = "0" + result;
     }
     return result;

It should say:

 [see above]

Notes:

[ further formatting (indentation) issues ]

RFC 4229, "HTTP Header Field Registrations", December 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 161

Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-01-18
Held for Document Update by: Alexey Melnikov
Report Text:

Reference tags for RFC 2109 [5] should be replaced by reference tags for RFC 2965 [15].

Rationale:
RFC 2109 [5] has been obsoleted by RFC 2965 [15], and the latter
apparently contains the current specification for the Set-Cookie
(and the Set-Cookie2) Header Field.

Nevertheless, the registration for 'Set-Cookie' in Subsection
2.1.96 of RFC 4229 (on page 36) refers to RFC 2109 [5] as the
normative Specification document.

I suspect that this particular Registration should be updated
immediately to point to RFC 2965 [15] .

---

RFC 4230, "RSVP Security Properties", December 2005

Source of RFC: nsis (tsv)

Errata ID: 976
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-16
Held for Document Update by: Wes Eddy

Section 3.2 says:

   The sending system needs to maintain the following attributes in such
   a security association [1]:

      [...]

      o  Latest sequence number (received with this key identifier)

It should say:

   The sending system needs to maintain the following attributes in such
   a security association [1]:

     [...]

      o  Latest sequence number (sent with this key identifier)

Notes:

received --> sent

from pending

Errata ID: 977
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-16
Held for Document Update by: Wes Eddy

Section 3.4 says:

        [...].  The RSVP INTEGRITY object (outer object) covers the
   entire RSVP message, whereas the POLICY_DATA INTEGRITY object only
   covers objects within the POLICY_DATA element.

It should say:

[not submitted]

Notes:

The subsequent Figure 1 (on top of page 10)
does *not* depict this security relevant object at all.

Has there something been fost from Figure 1 ?


from pending

Errata ID: 2841
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marco Molteni
Date Reported: 2011-06-17
Held for Document Update by: Wes Eddy

Section 3.4 says:

In addition to host-based authentication with the INTEGRITY object inside the
RSVP message, user-based authentication is available as introduced in [2].

It should say:

In addition to host-based authentication with the INTEGRITY object inside the
RSVP message, user-based authentication is available as introduced in [7].

Notes:

This wrong cross-reference appears at least in the HTML version of RFC4230, at http://tools.ietf.org/html/rfc4230.

Reference [2] is "RSVP Extensions for Policy Control", RFC 2750, while it should be Reference [7] "Identity Representation for RSVP", RFC 3182.

RFC 4231, "Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", December 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 3853
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Antonio Bueno
Date Reported: 2013-12-30
Held for Document Update by: Sean Turner
Date Held: 2014-01-12

Section 4.4 says:

   Key            aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
                  aaaaaaaa                          (20 bytes)
   Data =         dddddddddddddddddddddddddddddddd
                  dddddddddddddddddddddddddddddddd
                  dddddddddddddddddddddddddddddddd
                  dddd                              (50 bytes)

It should say:

   Key  =         aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
                  aaaaaaaa                          (20 bytes)
   Data =         dddddddddddddddddddddddddddddddd
                  dddddddddddddddddddddddddddddddd
                  dddddddddddddddddddddddddddddddd
                  dddd                              (50 bytes)

Notes:

Notice the equal sign missing after "Key"

spt: This is clearly editorial and no implementer is going to be confused by this so I marked it hold for document update.

RFC 4234, "Augmented BNF for Syntax Specifications: ABNF", October 2005

Note: This RFC has been obsoleted by RFC 5234

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 2625
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-10-13
Held for Document Update by: Pete Resnick
Date Held: 2010-11-12

Section Appendix B.2 says:

   Externally, data are represented as "network virtual ASCII" (namely,
   7-bit US-ASCII in an 8-bit field), with the high (8th) bit set to
   zero.

It should say:

   Externally, data are represented as "network virtual ASCII" (namely,
   7-bit US-ASCII in an 8-bit field, with the high (8th) bit set to
   zero).

Notes:

This change should make it clear (as in RFC 2234) that the phrase,
"with the high (8th) bit set to zero" is an intrinsic part of the
full definition of "network virtual ASCII", and not the specification
of an exception -- or an additional manipulation for the purpose of
ABNF -- to "network virtual ASCII".

RFC 4235, "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", November 2005

Note: This RFC has been updated by RFC 7463, RFC 8996

Source of RFC: sipping (rai)

Errata ID: 780
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Nicolas-Peter Pohland
Date Reported: 2007-01-14
Held for Document Update by: Robert Sparks

Section 4.2 says:

   <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="urn:ietf:params:xml:ns:dialog-info"
     version="1" state="full">

It should say:

   <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
    xmlns:xsi=" <http://www.w3.org/2001/XMLSchema-instance>
http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="urn:ietf:params:xml:ns:dialog-info"
     version="1" state="full" entity="sip:alice@example.com">

Notes:

According to the schema in section 4.4 the attribute "entity" must appear on
element "dialog-info".

from pending

Errata ID: 785
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Nicolas-Peter Pohland
Date Reported: 2007-01-15
Held for Document Update by: Robert Sparks

Section 6.1 says:

      <?xml version="1.0"?>
      <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                   version="2"
                   state="full"
                   entity="sip:alice@example.com">
        <dialog id="as7d900as8" call-id="a84b4c76e66710"
                local-tag="1928301774" remote-tag="456887766"
                direction="initiator">
          <state>early</state>
        </dialog>
        <dialog id="as7d900as8" call-id="a84b4c76e66710"
                local-tag="1928301774" remote-tag="hh76a"
                direction="initiator">
          <state>early</state>
        </dialog>
      </dialog-info>

It should say:

      <?xml version="1.0"?>
      <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                   version="2"
                   state="full"
                   entity="sip:alice@example.com">
        <dialog id="1000" call-id="a84b4c76e66710"
                local-tag="1928301774" remote-tag="456887766"
                direction="initiator">
          <state>early</state>
        </dialog>
        <dialog id="1001" call-id="a84b4c76e66710"
                local-tag="1928301774" remote-tag="hh76a"
                direction="initiator">
          <state>early</state>
        </dialog>
      </dialog-info>

[[or something similar with the id values differing]]

Rationale:
 
Quote from RFC 4235:
 
"4.1.1.  Dialog Element
 
    ...
 
   For a caller, the id is created when an INVITE request is sent.  When
   a 1xx response with a tag, or a 2xx response is received, the dialog
   is formally created.  The id remains unchanged.  However, if an
   additional 1xx or 2xx is received, resulting in the creation of
   another dialog (and resulting FSM), that dialog is allocated a new
   id.

    ..."
 
The id of the dialog is a hash value of the call-id, local-tag and
remote-tag of the dialog. Therefore, the values of the ids in the example MUST not be identical.

Notes:

from pending

Errata ID: 1495
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Iñaki Baz Castillo
Date Reported: 2008-08-26
Held for Document Update by: Robert Sparks

Section 3.7.1 says:

[...]
non-2xx response for any other reason, all FSMs spawned from that
INVITE transition to the Terminated state with the event "rejected".

--------------

[...]
If the UAS receives a CANCEL
request and then generates a 487 response to the INVITE (which can
occur in the Proceeding and Early states), the FSM transitions to the
Terminated state with the event "cancelled".

It should say:

[...]
non-2xx response for any other reason, all FSMs spawned from that
INVITE transition to the Terminated state with the event "rejected".
During Early state the FSM transitions to the Terminate state if the UAC sends a BYE (corresponding to "local-bye" event).

-------------

[...]
If the UAS receives a CANCEL
request and then generates a 487 response to the INVITE (which can
occur in the Proceeding and Early states), the FSM transitions to the
Terminated state with the event "cancelled".
If the UAS receives a BYE request during the Early state the FSM transitions to the Terminated state with the event "remote-bye".

Notes:

Section 3.7.1 (The Dialog State Machine) and the Figure 3 forget the case in which a UAC sends a BYE during an early-dialog as RFC3261 allows:

RFC 3261:
----------------
15 Terminating a Session
When a BYE is received on a dialog, any session
associated with that dialog SHOULD terminate. A UA MUST NOT send a
BYE outside of a dialog. The caller's UA MAY send a BYE for either
confirmed or early dialogs, and the callee's UA MAY send a BYE on
confirmed dialogs, but MUST NOT send a BYE on early dialogs.
----------------

So it should be a new row in Figure 3 from "Early" to "Terminate" labeled "local-bye/remote-bye". It would be "local-bye" in case of UAC and "remote-bye" in case of UAS.

Errata ID: 1517
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Klaus Darilion
Date Reported: 2008-09-17
Held for Document Update by: Robert Sparks

Section 6.1 says:

      <?xml version="1.0"?>
      <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                   version="4"
                   state="partial"
                   entity="sip:alice@example.com">
        <dialog id="as7d900as8" call-id="a84b4c76e66710"
                local-tag="1928301774" remote-tag="hh76a"
                direction="initiator">
          <state event="cancelled">terminated</state>
        </dialog>
      </dialog-info>

It should say:

      <?xml version="1.0"?>
      <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                   version="4"
                   state="partial"
                   entity="sip:alice@example.com">
        <dialog id="as7d900as8" call-id="a84b4c76e66710"
                local-tag="1928301774" remote-tag="456887766"
                direction="initiator">
          <state event="cancelled">terminated</state>
        </dialog>
      </dialog-info>

Notes:

The dialog which was cancelled was the first dialog and its remote tag is 456887766 instead of hh76a

Errata ID: 2266
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: David Grant
Date Reported: 2010-05-18
Held for Document Update by: Robert Sparks

Section 4.4 says:

...
<xs:element name="route-set" minOccurs="0" maxOccurs="1">
   <xs:complexType>
      <xs:sequence>
         <xs:element name="hop" type="xs:string" minOccurs="1" maxOccurs="unbounded"/>
      </xs:sequence>
   </xs:complexType>
</xs:element>
...

It should say:

** Remove Element **

Notes:

The route-set element was removed between draft-ietf-sipping-dialog-package-03 and draft-ietf-sipping-dialog-package-04

Errata ID: 2267
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: David Grant
Date Reported: 2010-05-18
Held for Document Update by: Robert Sparks

Section 4.4 says:

<xs:element name="cseq" type="xs:nonNegativeInteger" 
minOccurs="0" maxOccurs="1"/>

It should say:

** Remove Element **

Notes:

The participant/cseq element was removed between draft-ietf-sipping-dialog-package-03 and draft-ietf-sipping-dialog-package-04

Errata ID: 2861
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin Thomson
Date Reported: 2011-07-13
Held for Document Update by: Gonzalo Camarillo

Section 4.4 says:

  <xs:element name="state">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="xs:string">

It should say:

  <xs:element name="state">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="tns:dialog-state">
...

  <xs:simpleType name="dialog-state">
    <xs:restriction base="xs:string">
      <xs:enumeration value="trying"/>
      <xs:enumeration value="proceeding"/>
      <xs:enumeration value="early"/>
      <xs:enumeration value="confirmed"/>
      <xs:enumeration value="terminated"/>
    </xs:restriction>
  </xs:simpleType>

Notes:

The RFC is rather coy about defining the exact syntax for the state element. The schema permits any content. It's fairly clear from the description in Section 3.7.1 what the permitted values are, but the case of the values is never explicitly stated. The text and diagram use title case consistently, and all the examples use lower case exclusively.

This is bad for interoperability. In practice, this is probably moot, since most implementations will use the lowercase form. Arguably, it would be valid to produce a value of "Early". An implementation seeking maximum interoperability would have to use case insensitive comparison to avoid a misinterpretation of the value.

RFC 4240, "Basic Network Media Services with SIP", December 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rai

Errata ID: 839
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-01-23
Held for Document Update by: Robert Sparks

 

(2)  [ minor textual improvement ]

In the final paragraph of section 3.3, on mid-page 11, perhaps
the words "most anything" should be replaced by "almost anything".


(3)  [ textual improvement ]

The last paragraph on page 12 (within Section 4.1.) apparently
contains a plural/singular inconsistency.
The text says:
                                         vvv                      vvv
   The media server presents the parameters as environment variables in
   the connection object.  Specifically, the parameter appears in the
   connection.sip tree.                             ^^^     ^^^

It should better say:

   The media server presents the parameters as environment variables in
|  the connection object.  Specifically, the parameters appear in the
   connection.sip tree.


(4)  [ inconsistent terminology ]

I suspect that section 5 contains an unintentional inconsistency
in the terminology used:
The syntax element represented by the 'uniqueIdentifier' part
of the example in the 9th line of Section 5 apparently is
referred to as the "conf-id value" in various places (once
on page 13, 11th text line from the bottom of the page, and
4 occurrences on page 14 (text lines 3, 9, 12, and 13).
But in the 'Formal Syntax' Section 5.2., this syntactic
element is named "instance-id" (see bottom of page 16).
It certainly would be preferrable to always use the same
terminology; you should decide which term should be used.


(5)  [ editorial artifact ]

The call flow diagram on page 15 unnecessarily 'overflows'
to page 16.  The two first text lines on page 16,

     |       |        |                  |                   |
     |       |        |                  |                   |

do not carry any useful information and might better have been
suppressed.


(6)  [ mismatch between diagram and explanation ]

Subsequently, near the top of page 16, the explanation of the
call flow diagram on page 15 says:

   Note that the above call flow does not show any 100 TRYING messages
   that would typically flow from the Application Server to the UACs;
   nor does it show the ACKs from the UACs to the Application Server or
   from the Application Server to the Media Server.

The latter is not true; the diagram in fact DOES show these ACKs !
Therefore, this paragraph should be shortened to just say:

   Note that the above call flow does not show any 100 TRYING messages
   that would typically flow from the Application Server to the UACs.


(7)  [ confusion between concrete and abstract parameter names ]

In the 'IANA Considerations' Section 6., on page 17, the
registered lines mix concrete (real) parameter names (like
'play') with the meta-parameter name 'extension' in a way
that might mislead the reader to taking 'extension' as a
concrete parameter name as well.
>From Section 3.3., it can clearly be seen that this is merely
a placeholder for any additional parameter that might be
standardized in the future.
I'm seriously in doubt whether it is a good idea to register
this meta-parameter.  Rather, future standards defining
concrete instances for the 'extension-param' should register
those concrete parameter names.

I therefore propose to delete the final line from the list,

   Parameter Name    Predefined Values    Reference
   --------------    -----------------    ---------
      .                      .               .
      .                      .               .
      .                      .               .
|  extension                 no           RFC 4240

and from the actual IANA registration performed.


(8)  [ legacy left in text? ]

The 3rd paragraph of Section 7, on page 17, says:

   This document explicitly addresses this issue.  The user names
   described in the text (namely annc, ivr, dialog, and conf) are
   available for whatever local use a given SIP user agent or proxy
   wishes for them.  [ ... ]

The user name, 'ivr', does not appear in the remainder of the text.
Admittedly omitting any detailed research, I suspect its occurrence
to be an improper left-over from earlier drafts.
Thus, this text should say:

   This document explicitly addresses this issue.  The user names
|  described in the text (namely annc, dialog, and conf) are
   available for whatever local use a given SIP user agent or proxy
   wishes for them.  [ ... ]

It should say:

[see above]  

Notes:

from pending

Errata ID: 154
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-01-23
Held for Document Update by: Robert Sparks

Section 3.3 says:

   A number of MIME registrations, which could be used here, have
   parameters, for instance, video/DV.  To accommodate this, and retain
   compatibility with the SIP URI structure, the MIME-type parameter
   separator (semicolon, %3b) and value separator (equal, %d3) MUST be
   escaped.  For example:                                 ^^^

   sip:annc@ms.example.net; \
       play=file://fs.example.net//clips/my-intro.dvi; \
       content-type=video/mpeg%3bencode%d3314M-25/625-50

It should say:

   A number of MIME registrations, which could be used here, have
   parameters, for instance, video/DV.  To accommodate this, and retain
   compatibility with the SIP URI structure, the MIME-type parameter
   separator (semicolon, %3b) and value separator (equal, %3d) MUST be
   escaped.  For example:

   sip:annc@ms.example.net; \
       play=file://fs.example.net//clips/my-intro.dvi; \
       content-type=video/mpeg%3bencode%3d314M-25/625-50

RFC 4244, "An Extension to the Session Initiation Protocol (SIP) for Request History Information", November 2005

Note: This RFC has been obsoleted by RFC 7044

Source of RFC: sip (rai)

Errata ID: 2608
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hadriel Kaplan
Date Reported: 2010-11-04
Held for Document Update by: Robert Sparks

Section 4.5 says:

                History-Info: <sip:Bob@P1.example.com>;index=1,
                   <sip:Bob@P2.example.com>; index=1.1,
                   <sip:User2@UA2.example.com?Reason=SIP;\
                    cause=408;text="RequestTimeout">;index=1.1.1,
                   <sip:User3@UA3.example.com?Reason=SIP; \
                    cause=487;text="Request Terminated">; index=1.1.2,
                   <sip:User4@UA4.example.com?Reason=SIP;\
                    cause=603;text="Decline">; index=1.1.3

It should say:

                History-Info: <sip:Bob@P1.example.com>;index=1,
                   <sip:Bob@P2.example.com>; index=1.1,
                   <sip:User2@UA2.example.com?Reason=SIP%3B\
                    cause%3D408%3Btext%3D%22RequestTimeout%22>;index=1.1.1,
                   <sip:User3@UA3.example.com?Reason=SIP%3B\
                    cause%3D487%3Btext%3D%22Request%20Terminated%22>; index=1.1.2,
                   <sip:User4@UA4.example.com?Reason=SIP%3B\
                    cause%3D603%3Btext%3D%22Decline%22>; index=1.1.3

Notes:

This is one of many incorrect examples in section 4.5, 4.5.1, 4.5.2, etc. The ";", "=", double-quotes, and space are not legal tokens in URI-embedded headers.

RFC 4252, "The Secure Shell (SSH) Authentication Protocol", January 2006

Note: This RFC has been updated by RFC 8308, RFC 8332

Source of RFC: secsh (sec)

Errata ID: 3268
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2012-06-28
Held for Document Update by: Sean Turner

Section 5.1 says:

   A request that requires further messages to be exchanged will be
   aborted by a subsequent request.  A client MUST NOT send a subsequent
   request if it has not received a response from the server for a
   previous request.  A SSH_MSG_USERAUTH_FAILURE message MUST NOT be
   sent for an aborted method.

It should say:

   A request that requires further messages to be exchanged will be
   aborted by a subsequent request.  In this case a client MUST NOT 
   send a subsequent request if it has not received a response from 
   the server for a previous request.  A SSH_MSG_USERAUTH_FAILURE 
   message MUST NOT be sent for an aborted method.

Notes:

The ambiguous wording, which can be confusing. See previous paragraph

RFC 4254, "The Secure Shell (SSH) Connection Protocol", January 2006

Note: This RFC has been updated by RFC 8308

Source of RFC: secsh (sec)

Errata ID: 3877
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jim Wigginton
Date Reported: 2014-02-02
Held for Document Update by: Kathleen Moriarty
Date Held: 2014-07-01

Section 6.10 says:

6.10.  Returning Exit Status

   When the command running at the other end terminates, the following
   message can be sent to return the exit status of the command.
   Returning the status is RECOMMENDED.  No acknowledgement is sent for
   this message.  The channel needs to be closed with
   SSH_MSG_CHANNEL_CLOSE after this message.

   The client MAY ignore these messages.

It should say:

6.10.  Returning Exit Status

   When the command running at the other end terminates, the following
   message can be sent to return the exit status of the command.
   Returning the status is RECOMMENDED.  No acknowledgement is sent for
   this message.  The channel needs to be closed by the server with
   SSH_MSG_CHANNEL_CLOSE after this message.

   The client MAY ignore these messages.

Notes:

Even though it can arguably be inferred from the text as written I think it'd make it more clear if the RFC explicitly said that the server is the one that should be sending the SSH_MSG_CHANNEL_CLOSE message.

RFC 4255, "Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints", January 2006

Source of RFC: secsh (sec)

Errata ID: 6621
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Shane Kerr
Date Reported: 2021-06-25
Held for Document Update by: Benjamin Kaduk
Date Held: 2021-07-19

Section 3.2 says:

   The RDATA of the presentation format of the SSHFP resource record
   consists of two numbers (algorithm and fingerprint type) followed by
   the fingerprint itself, presented in hex, e.g.:

       host.example.  SSHFP 2 1 123456789abcdef67890123456789abcdef67890

   The use of mnemonics instead of numbers is not allowed.

It should say:

   The RDATA of the presentation format of the SSHFP resource record
   consists of two numbers (algorithm and fingerprint type) followed by
   the fingerprint itself, presented in hex, e.g.:

       host.example.  SSHFP 2 1 123456789abcdef67890123456789abcdef67890

   The use of mnemonics instead of numbers is not allowed. Whitespace is
   allowed within the hexadecimal text.

Notes:

Many (most?) other DNS RFC's, for example RFC 4034, explicitly mention that whitespace is allowed in such encoded fields, whether hex or base64. RFC 4255 does not address this, so can be interpreted either way. For consistency and ease of implementation, I recommend allowing whitespace.

My proposed corrected text was copied verbatim from RFC 4034, and could possibly be edited to match the RFC 4255 text better, for example using "hex" instead of "hexadecimal text".

RFC 4270, "Attacks on Cryptographic Hashes in Internet Protocols", November 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 2659
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Lloyd Wood
Date Reported: 2010-12-04
Held for Document Update by: Stephen Farrell

Section 3 says:

      Integrity protection.  It is common to compare a hash value that
      is received out-of-band for a file with the hash value of the file
      after it is received over an unsecured protocol such as FTP.

It should say:

      Reliability checking and error detection.  It is common to compare a hash value that
      is received out-of-band for a file with the hash value of the file
      after it is received over an unsecured protocol such as FTP.

Notes:

"integrity protection" is a term with specific meaning to security researchers, and that meaning doesn't gel with how the rest of the world uses terms like 'integrity' or 'protection,' or with the rest of this bullet point. So, we swap the term out for something less contentious.

This came up in discussion with Martin Rex and the IESG. Martin writes:

> Integrity protection is terminology that is used in the
> security&cryptographic area and this defect of rfc-4270 is going
> to create misunderstandings.

So, filing an erratum.

RFC 4271, "A Border Gateway Protocol 4 (BGP-4)", January 2006

Note: This RFC has been updated by RFC 6286, RFC 6608, RFC 6793, RFC 7606, RFC 7607, RFC 7705, RFC 8212, RFC 8654, RFC 9072

Source of RFC: idr (rtg)

Errata ID: 5000
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: John Scudder
Date Reported: 2017-04-19
Held for Document Update by: Alvaro Retana
Date Held: 2017-04-27

Section 9.1.1 says:

      If the route is learned from an external peer, then the local BGP
      speaker computes the degree of preference based on preconfigured
      policy information.  If the return value indicates the route is
      ineligible, the route MAY NOT serve as an input to the next phase
      of route selection; otherwise, the return value MUST be used as
      the LOCAL_PREF value in any IBGP readvertisement.

It should say:

      If the route is learned from an external peer, then the local BGP
      speaker computes the degree of preference based on preconfigured
      policy information.  If the return value indicates the route is
      ineligible, the route MUST NOT serve as an input to the next phase
      of route selection; otherwise, the return value MUST be used as
      the LOCAL_PREF value in any IBGP readvertisement.

Notes:

The original text uses "MAY NOT" capitalized as if it were an RFC 2119 keyword. However, RFC 2119 does not have any defined meaning for "MAY NOT". If a reader were to interpret this text as suggesting it is optional -- meaning, in effect, "the route MAY serve as an input to the next phase of route selection" -- that would be wrong and potentially problematic.

The minimal correction would be to use lower-case "may not", which makes the proper meaning reasonably clear. However, the English construct "may not" is notoriously ambiguous, therefore the proposed correction is "MUST NOT".

=====
After consultation with the idr WG, it was confirmed that the correct interpretation (based on implementation experience) is "MUST NOT". --- Alvaro.

Errata ID: 5001
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: John Scudder
Date Reported: 2017-04-19
Held for Document Update by: Alvaro Retana
Date Held: 2017-04-27

Section 5 says:

   BGP implementations MUST recognize all well-known attributes.  Some
   of these attributes are mandatory and MUST be included in every
   UPDATE message that contains NLRI.  Others are discretionary and MAY
   or MAY NOT be sent in a particular UPDATE message.

It should say:

   BGP implementations MUST recognize all well-known attributes.  Some
   of these attributes are mandatory and MUST be included in every
   UPDATE message that contains NLRI.  Others are discretionary and may
   or may not be sent in a particular UPDATE message.

Notes:

The original text uses "MAY NOT" capitalized as if it were an RFC 2119 keyword. However, RFC 2119 does not have any defined meaning for "MAY NOT". In context, it is unlikely the reader would be at risk of misinterpreting the text, but nonetheless it's a misuse of RFC 2119 terminology and difficult to parse if reading closely.

(The replacement text was suggested by Eric Rosen; thanks.)

=====
I updated the Corrected Text to simply use lower case wording, eliminating any rfc2119-related confusion. -- Alvaro.

Errata ID: 6498
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Graham Paasch
Date Reported: 2021-03-27
Held for Document Update by: Alvaro Retana
Date Held: 2021-03-29

Section 5.1.5 says:

LOCAL_PREF is a well-known attribute that SHALL be included in all UPDATE messages that a given BGP speaker sends to other internal peers. 

It should say:

LOCAL_PREF is a well-known discretionary attribute that SHALL be included in all UPDATE messages that a given BGP speaker sends to other internal peers. 

Notes:

It is unclear from the text to which of the four path attribute categories LOCAL_PREF belongs. There was even submitted an errata to create a fifth category for this attribute, but it is clear from the definition of the categories, that this attribute is well known discretionary. All routers must be capable of sending or receiving the LOCAL_PREF attribute, however it is up to a routers discretion whether to include that attribute in an UPDATE message.

=====
[Verifier notes.]

This is a valid report. The terminology in rfc4271 is not ideal, so using "discretionary" with a required action can cause significant confusion, even if that is the correct term for this attribute. A future version of this RFC should consider updating/cleaning up the terminology.

Errata ID: 150
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2006-01-26
Held for Document Update by: Stewart Bryant
Date Held: 2011-08-02

Section 9.1.1 says:

The Phase 1 decision function is a separate process,f which completes 
when it has no further work to do.

It should say:

The Phase 1 decision function is a separate process, which completes 
when it has no further work to do.

Errata ID: 3264
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Anmol Khirbat
Date Reported: 2012-06-19
Held for Document Update by: Stewart Bryant

Section Appendix F.3 says:

Implementations that combine update messages (as described above in
Section 6.1) may prefer to see all path attributes presented in a
known order.

It should say:

Implementations that combine update messages (as described above in
Appendix F.1) may prefer to see all path attributes presented in a
known order.

Notes:

Section 6.1 does not say anything about combining update messages.

Errata ID: 3459
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lawrence Hui
Date Reported: 2013-01-16
Held for Document Update by: Stewart Bryant

Section 6.8 says:

If a pair of BGP speakers try to establish a BGP connection with each
other simultaneously, then two parallel connections well be formed.

It should say:

If a pair of BGP speakers try to establish a BGP connection with each
other simultaneously, then two parallel connections will be formed.

Notes:

This edit will replace the "well" with "will".

Errata ID: 3464
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lawrence Hui
Date Reported: 2013-01-17
Held for Document Update by: Stewart Bryant
Date Held: 2013-01-28

Section 9.1.1 says:

   The Phase 1 decision function is a separate process,f which completes
   when it has no further work to do.

It should say:

   The Phase 1 decision function is a separate process, which completes
   when it has no further work to do.

Notes:

This edit will remove the "f".

This is correct, but will not cause an interoperability issue, and thus can be fixed when the document is updated.

Errata ID: 3809
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramakrishna DTV
Date Reported: 2013-11-21
Held for Document Update by: Stewart Bryant
Date Held: 2013-11-22

Section 6 says:

   Before the invalid routes are deleted
   from the system, it advertises, to its peers, either withdraws for
   the routes marked as invalid, or the new best routes before the
   invalid routes are deleted from the system.

It should say:

   Before the invalid routes are deleted
   from the system, it advertises, to its peers, either withdraws for
   the routes marked as invalid, or the new best routes.

Notes:

The phrase "Before the invalid routes are deleted from the system" is unnecessarily repeated in the same sentence.

Errata ID: 4496
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alexander Okonnikov
Date Reported: 2015-10-10
Held for Document Update by: Alvaro Retana
Date Held: 2015-10-12

Section 9.1.1 says:

... If the return value indicates the route is
      ineligible, the route MAY NOT serve as an input to the next phase
      of route selection; ...

It should say:

... If the return value indicates the route is
      ineligible, the route MUST NOT serve as an input to the next phase
      of route selection; ...

Notes:

RFC 2119 does not define special word MAY NOT. Obviously, ineligible route must not be used in route selection.
====

Errata ID: 5421
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Greg Skinner
Date Reported: 2018-07-15
Held for Document Update by: Alvaro Retana
Date Held: 2018-11-04

Section 8.2.2 says:

If the local system receives a KeepaliveTimer_Expires event (Event
      11), the local system:

        - sends a KEEPALIVE message,

        - restarts the KeepaliveTimer, and

        - remains in the OpenConfirmed state.

It should say:

If the local system receives a KeepaliveTimer_Expires event (Event
      11), the local system:

        - sends a KEEPALIVE message,

        - restarts the KeepaliveTimer, and

        - remains in the OpenConfirm state.

Errata ID: 5766
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alvaro Retana
Date Reported: 2019-06-28
Held for Document Update by: Alvaro Retana
Date Held: 2019-06-28

Section 9.2 says:

   If, due to the limits on the maximum size of an UPDATE message (see
   Section 4), a single route doesn't fit into the message, the BGP
   speaker MUST not advertise the route to its peers and MAY choose to
   log an error locally.

It should say:

   If, due to the limits on the maximum size of an UPDATE message (see
   Section 4), a single route doesn't fit into the message, the BGP
   speaker MUST NOT advertise the route to its peers and MAY choose to
   log an error locally.

Notes:

The Normative text should be "MUST NOT", and not "MUST not" -- both words should be capitalized.

Errata ID: 6256
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Anton Yushkov
Date Reported: 2020-08-12
Held for Document Update by: Alvaro Retana
Date Held: 2020-08-18

Section 5.1.3 says:

3) When sending a message to an external peer X, and the peer is
multiple IP hops away from the speaker (aka "multihop EBGP"):
...
- By default, the BGP speaker SHOULD use the IP address of the interface that the speaker uses in the NEXT_HOP attribute to establish the BGP connection to peer X.

It should say:

3) When sending a message to an external peer X, and the peer is
multiple IP hops away from the speaker (aka "multihop EBGP"):
...
- By default, the BGP speaker SHOULD use the IP address of the interface that the speaker uses to establish the BGP connection to peer X in the NEXT_HOP attribute.

Notes:

confusing incorrect word order:
reading the original text, the reader might think that the BGP speaker is using the NEXT_HOP attribute as part of establishing a connection with the peer

RFC 4273, "Definitions of Managed Objects for BGP-4", January 2006

Source of RFC: idr (rtg)

Errata ID: 3782
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramakrishna DTV
Date Reported: 2013-11-04
Held for Document Update by: Stewart Bryant
Date Held: 2013-11-22

Section 5 says:

There are several management objects defined in this MIB that have a
MAX-ACCESS clause of read-write and/or read-create.

It should say:

There are several management objects defined in this MIB that have a
MAX-ACCESS clause of read-write.

Notes:

No object in this MIB has MAX-ACCESS clause of "read-create".

RFC 4274, "BGP-4 Protocol Analysis", January 2006

Source of RFC: idr (rtg)

Errata ID: 3777
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Held for Document Update by: Stewart Bryant
Date Held: 2013-10-30

 

(5)  like (4)

Section 6.1.2, on page 8, exhibits similar symptoms as noted above.
The RFC says:

   To quantify the worst-case memory requirements for BGP, we denote the
   total number of networks in the Internet as N, the mean AS distance
   of the Internet as M (distance at the level of an autonomous system,
   expressed in terms of the number of autonomous systems), the total
   number of unique AS paths as A.  Then the worst-case memory
   requirements (MR) can be expressed as

           MR = O(N + (M * A))

   Because a mean AS distance M is a slow moving function of the
   interconnectivity ("meshiness") of the Internet, for all practical
   purposes the worst-case router memory requirements are on the order
|  of the total number of networks in the Internet multiplied by the
|  number of peers that the local system is peering with.  [...]

Apparently, the first part of that text has been revised eliminating
the role of the peering count.  Thus the last sentence should have
been updated accordingly, to make it match the new formula.

The second paragraph thus perhaps should say:

   Because a mean AS distance M is a slow moving function of the
   interconnectivity ("meshiness") of the Internet, for all practical
   purposes the worst-case router memory requirements are on the order
|  of the total number of networks in the Internet.  [...]

Notes:

from errata 148

Rather than follow this suggestion (and drop the number of peers term out of the prose) it may be more would be more accurate to insert a number of peers term into the formula, e.g. MR = O(P * (N + (M * A))), where P is the number of peers.

This does not impact interoperability and thus should be looked at in any future update of the RFC.

Errata ID: 3776
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Held for Document Update by: Stewart Bryant
Date Held: 2013-10-30

 

(4)  inconsistency in updated text

The text of section 6.1 has been revised substantially from its
predecessor, RFC 1774.  Unfortunately, the modifications have
not been performed incompletely, leading to near-nonsense text.
Section 6.1, on page 7, says:

   Immediately after the initial BGP connection setup, BGP peers
   exchange complete sets of routing information.  If we denote the
   total number of routes in the Internet as N, the total path
   attributes (for all N routes) received from a peer as A, and assume
   that the networks are uniformly distributed among the autonomous
   systems, then the worst-case amount of bandwidth consumed during the
|  initial exchange between a pair of BGP speakers (P) is

|          BW = O((N + A) * P)
                         ^^^^                     ^^^^^

This makes no sense -- obviously you can't multiply by a non-numeric
quantity P, "a pair of BGP speakers".

I strongly suspect that it was the intention to say:

   Immediately after the initial BGP connection setup, BGP peers
   exchange complete sets of routing information.  If we denote the
   total number of routes in the Internet as N, the total path
   attributes (for all N routes) received from a peer as A, and assume
   that the networks are uniformly distributed among the autonomous
   systems, then the worst-case amount of bandwidth consumed during the
|  initial exchange between a pair of BGP speakers is

|          BW = O((N + A))

Please verify.

Notes:

from errata 148

This has no impact on interoperability. It should be looked at on any update of the RFC.

Errata ID: 148
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Held for Document Update by: Stewart Bryant
Date Held: 2013-10-30

 

The final paragraph on page 8,

   The following table illustrates typical memory requirements of a
   router running BGP.  We denote the average number of routes
   advertised by each peer as N, the total number of unique AS paths as
   A, the mean AS distance of the Internet as M (distance at the level
   of an autonomous system, expressed in terms of the number of
   autonomous systems), the number of octets required to store a network
   as R, and the number of bytes required to store one AS in an AS path
|  as P.  It is assumed that each network is encoded as four bytes, each
   AS is encoded as two bytes, and each networks is reachable via some
|  fraction of all the peers (# BGP peers/per net).  For purposes of the
|  estimates here, we will calculate MR = (((N * R) + (M * A) * P) * S).
                                                             ^^^^ ^^^^

and the table on page 9,
                                       vvvvvvvvvvvvvvvvvvv
|  # Networks  Mean AS Distance # ASes # BGP peers/per net   Memory Req
|      (N)             (M)        (A)          (P)              (MR)
   ----------  ---------------- ------ ------------------- -------------
     100,000           20         3,000         20           10,400,000
     100,000           20        15,000         20           20,000,000
     120,000           10        15,000        100           78,000,000
     140,000           15        20,000        100          116,000,000

exhibit additional issues:

- The text defines 'P' as
    "the number of bytes required to store one AS in an AS path"
  while apparently in the table (P) means
    "# BGP peers/per net".

- 'S' in the formula in the last line of page 9 is not defined
  anywhere in the text.

- "# BGP peers/per net" IMHO does not even make sense in the
  context of BGP, since BGP speakers represent ASes, not networks
  (prefixes).

I do not have a proposal for an easy way to get rid of these
inconsistencies.
Please check.

Notes:

There is clearly a problem with the text, but it does not impact interoperability and should be looked at when the RFC is revised.

Errata ID: 3774
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Held for Document Update by: Stewart Bryant
Date Held: 2013-10-30

 

(6)  typos / grammar

In Section 10, the second paragraph on page 13 says:

|  BGP uses TCP MD5 option for validating data and protecting against
   spoofing of TCP segments exchanged between its sessions.  The usage
   of TCP MD5 option for BGP is described at length in [RFC2385].  The
   TCP MD5 Key management is discussed in [RFC3562].  BGP data
|  encryption is provided using the IPsec mechanism, which encrypts the
|  IP payload data (including TCP and BGP data).  The IPsec mechanism
|  can be used in both the transport mode and the tunnel mode.  The
|  IPsec mechanism is described in [RFC2406].  Both the TCP MD5 option
|  and the IPsec mechanism are not widely deployed security mechanisms
   for BGP in today's Internet.  Hence, it is difficult to gauge their
|  real performance impact when using with BGP.  However, because both
|  the mechanisms are TCP- and IP-based security mechanisms, the Link
   Bandwidth, CPU utilization and router memory consumed by BGP would be
|  the same as any other TCP- and IP-based protocols.

It should say, correcting grammar and unclear semantics:

|  BGP uses the TCP MD5 option for validating data and protecting
   against spoofing of TCP segments exchanged between its sessions.  The
   usage of TCP MD5 option for BGP is described at length in [RFC2385].
   The TCP MD5 Key management is discussed in [RFC3562].  BGP data
|  encryption is provided using the IPsec ESP mechanism, which encrypts
|  the IP payload data (including TCP and BGP data).  The IPsec ESP
|  mechanism can be used in both transport mode and tunnel mode.  The
|  IPsec ESP mechanism is described in [RFC2406].  Both the TCP MD5
|  option and IPsec ESP are not widely deployed security mechanisms
   for BGP in today's Internet.  Hence, it is difficult to gauge their
|  real performance impact when used with BGP.  However, because both
|  mechanisms are TCP- and IP-based security mechanisms, the Link
   Bandwidth, CPU utilization and router memory consumed by BGP would be
   the same as any for other TCP- and IP-based protocols.

(I am in doubt whether the last sentence is appropriate;
 at least, "the same as" should better be replaced by "similar as".
 Preferrably, I would delete that sentence.)

Finally, the 4th paragraph on page 13,
                                                      v
|  Such flexible TCP- and IP-based security mechanisms, allow BGP to
   prevent insertion/deletion/modification of BGP data, any snooping of
   the data, session stealing, etc.  [...]

should say:

|  Such flexible TCP- and IP-based security mechanisms allow BGP to
   prevent insertion/deletion/modification of BGP data, any snooping of
   the data, session stealing, etc.  [...]

Notes:

from errata 148

Errata ID: 3773
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Held for Document Update by: Stewart Bryant
Date Held: 2013-10-30

 

(3)  typos (multiple missing articles)

Section 4 of RFC 4274, on page 6, says:

   Whenever a BGP speaker detects an error in a peer connection, it
   shuts down the peer and changes its FSM state to IDLE.  BGP speaker
   requires a Start event to re-initiate an idle peer connection.  If
   the error remains persistent and BGP speaker generates a Start event
   automatically, then it may result in persistent peer flapping.
   Although peer oscillation is found to be wide-spread in BGP
   implementations, methods for preventing persistent peer oscillations
   are outside the scope of base BGP specification.

It should say:

It should say:

   Whenever a BGP speaker detects an error in a peer connection, it
|  shuts down the peer and changes its FSM state to IDLE.  A BGP speaker
   requires a Start event to re-initiate an idle peer connection.  If
|  the error remains persistent and the BGP speaker generates a Start
   event automatically, then it may result in persistent peer flapping.
   Although peer oscillation is found to be wide-spread in BGP
   implementations, methods for preventing persistent peer oscillations
|  are outside the scope of the base BGP specification.

Notes:

from errata 148

Errata ID: 3772
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Held for Document Update by: Stewart Bryant
Date Held: 2013-10-30

 

(2)  typo

Section 2.3 contains (on page 5) the state description:

   ACTIVE:         State in which BGP peer is trying to acquire a peer
|                  by listening and accepting TCP connection.

It should say:

   ACTIVE:         State in which BGP peer is trying to acquire a peer
|                  by listening and accepting a TCP connection.
                                             ^^^

(An alternative correction, replacing 'connection' by 'connections',
 does not precisely reflect the desired behaviour.)

Notes:

from errata 148

Errata ID: 3771
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Held for Document Update by: Stewart Bryant
Date Held: 2013-10-30

 

(1)  typo (missing word)

The second paragraph of Section 2.2, on page 4 of RFC 4274, says:

   BGP uses an incremental update strategy to conserve bandwidth and
|  processing power.  That is, after initial exchange of complete
   routing information, a pair of BGP routers exchanges only the changes
   to that information.  [...]

It should say:

It should say:

   BGP uses an incremental update strategy to conserve bandwidth and
|  processing power.  That is, after the initial exchange of complete
   routing information, a pair of BGP routers exchanges only the changes
   to that information.  [...]

RFC 4275, "BGP-4 MIB Implementation Survey", January 2006

Source of RFC: idr (rtg)

Errata ID: 147
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Held for Document Update by: Stewart Bryant

Section 7 says:

   [RFC4274]  Haas, J. and S. Hares, Eds., "Definitions of Managed
              Objects for the Fourth Version of Border Gateway Protocol
              (BGP-4)", RFC 4274, January 2006.

It should say:

   [RFC4273]  Haas, J. and S. Hares, Eds., "Definitions of Managed
              Objects for BGP-4", RFC 4273, January 2006.

Notes:

All references in the text to RFC 4274 ( '[RFC4274]' )
should be changed to RFC 4273 ( '[RFC4273]' ).

RFC 4277, "Experience with the BGP-4 Protocol", January 2006

Source of RFC: idr (rtg)

Errata ID: 146
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-21
Held for Document Update by: Stewart Bryant
Date Held: 2013-02-28

 

(1)  Relationship to RFC 1773

While studying RFC 4277, and re-reading its predecessor, RFC 1773,
it became more and more unclear to me why RFC 1773 has not simply
been declared being obsoleted by RFC 4277 - or perhaps being done
so by RFC 4277 plus RFC 4276.

Almost all material contained in RFC 1773 has been expanded upon
in RFC 4277; only a few historical noted have been dropped -
which arguably are of no more interest from the point of view
of current standardization and implementation efforts.

Hence, RFC 4277 apparently is a perfect replacement for RFC 1773,
and it would have added to clarity about the status of the memos
making this visible in the RFC index by means of a pair of
related  OBSOLETED BY  and  OBSOLETES  notes.


(2)  Inconsistencies with References

There are a few issues with References in RFC 4277:

(2a)

RFC 1965 had been obsoleted by RFC 3065, as noted in the text,
and consistently, the Ref. [RFC1965] has been placed into the
Informative References (Section 22.2), whereas [RFC3065] has
been recorded as a Normative Reference.  That's pretty o.k.

A similar relation exists between RFC 1966 and RFC 2796 (that
had obsoleted the former), and the text contains a similar,
parallel treatment of this RFC pair as the pair noted above.
Nevertheless, the Ref. [RFC1966] has been placed in Section
22.1, Normative References.
That seems to be inappropriate and inconsistent; [RFC1996]
should have been filed as an Informative Reference.

(2b)

The first sentence of Section 3, on page 3, contains a citation to
"[BGP-MIB]" that can be assumed from the context to mean RFC 4273,
but there's no such entry in Section 22 !

Consistently with (2a) above, the Ref. [RFC1657] from Section 22.1
should better have been placed into Section 22.2, and instead of it,
a new entry [BGP-MIB] pointing to RFC 4273 inserted into the
Normative References, Section 22.1.


The following text might be considered for inclusion in an RFC
Errata Note for RFC 4277 to resolve isuues (2a) and (2b):

-----
RFC 4271, in Section 22.1, "Normative References", on page 17,
contains entries labeled  '[RFC1966]'  and  '[RFC1657]' .
These entries should have been placed into Section 22.2,
"Informative References", instead.

Additionally, another entry should be added to Section 22.1 :

   [BGP-MIB]   Haas, J., Ed. and S. Hares, Ed., "Definitions of Managed
               Objects for BGP-4", RFC 4273, January 2006.
-----


(3)  further errata (typos)

(3a)

The example network topology diagram in Section 8, on mid-page 8,

                     /---- transit B ----\
         end-customer                     transit A----
                     /---- transit C ----\

should say:

                     /---- transit B ----\
         end-customer                     transit A----
                     \---- transit C ----/

Rationale: cf. RFC 1773 !

(3b)

Conforming to standard IPsec terminology, the first sentence
in Section 17.2 of RFC 4277 (on page 14),

                                    vvv
   BGP can run over IPsec, either in a tunnel or in transport mode,
   where the TCP portion of the IP packet is encrypted.  [...]

should better say:
                                           vvvvvv
|  BGP can run over IPsec, either in tunnel mode or in transport mode,
   where the TCP portion of the IP packet is encrypted.  [...]

or even, omitting that first 'mode' entirely,

|  BGP can run over IPsec, either in tunnel or in transport mode, where
   the TCP portion of the IP packet is encrypted.  [...]

(3c)

The last sentence in Section 21 of RFC 4277, on page 16,

   Finally, we'd like to think the IDR WG for general and specific input
   that contributed to this document.

should say:
                           v
|  Finally, we'd like to thank the IDR WG for general and specific input
   that contributed to this document.

Notes:

from pending

RFC 4280, "Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers", November 2005

Source of RFC: dhc (int)

Errata ID: 145
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-12-20
Held for Document Update by: Brian Haberman

Section 4.1 says:

   Broadcast and Multicast Service Controller Domain Name List
   for DHCPv4

It should say:

   Broadcast and Multicast Service Controller Domain Name List
   Option for DHCPv4

Notes:

RFC 4282, "The Network Access Identifier", December 2005

Note: This RFC has been obsoleted by RFC 7542

Source of RFC: radext (sec)

Errata ID: 816
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-12-18
Held for Document Update by: Dan Romascanu

 

Unfortunately, the text of that RFC does not fully reflect the
established state of the IETF standards, by referring to obsolete
documents (e.g., ex STD 10, RFC 821) and ignoring effective updates,
e.g., STD 3, RFC 1123, and RFC 2821.

In particular, the text of RFC 4282 repeatedly (e.g. in Section
2.6.) emphasizes making a deviation from established standards
for host / domain names.

This is not true!
The pretended deviation in fact reflects the current standards.

The modification to RFC 952, RFC 821, et al. has already been
introduced into the IETF Standards by STD 3, RFC 1123 (Host
Requirements, Part II), published 16 years ago, in October 1989.
Section 2.1 of that RFC, on page 13, says:

    "One aspect of host name syntax is hereby changed: the
     restriction on the first character is relaxed to allow
     either a letter or a digit. Host software MUST support
     this more liberal syntax."

and continues saying:

    "Host software MUST handle host names of up to 63 characters
     and SHOULD handle host names of up to 255 characters."

Therefore, it would have been strongly advisable to point out
on page 6 of RFC 4282, in Section 2.2, first bullet, that the
named rules in RFC 2865 **DO NOT CONFORM** with STD 3 !!!

Note: IMHO, it is a fundamental design flaw of RADIUS and certain
other protocols using TLVs, AVPs, -- or however similar protocol
objects are named -- to specify that the 'length' information
(being stored in a single octet) is to comprise the cumulative
size of the Type, Length and Value fields, instead of just giving
the size of the Value (payload) field; the latter solution would
always allow to fully exhaust the total range of an 8-bit unsigned
Length and thereby allow payload octet strings of size 0..255 !


Similarly, RFC 4282 ignores the standardization state of the
proprietary historic tunnelling protocols that have served as
'precursors with major deficiencies to learn from' for the
development of L2TP, the only comparable protocol named in 
RFC 4282 that is on the IETF Standards Track.

  o   L2F [RFC2341] has been published for information only
      as a Historic RFC 'ab initio'.

  o   PPTP [RFC2637] has purposely been rejected by the IETF --
      because of its well known significant security flaws, among
      other issues, and the Informational RFC 2637 has been
      published with a very clear IESG Note to this end.

I am surprised that a new Standards Track RFC is getting published
that repeatedly refers to obsolete protocols equally as to official
protocols, in a manner that does not make clear the distinction.
The continued unreflected use of PPTP, in particular, is seen by
major security consultants as 'one of the most widespread trojan
horses' in the current Internet.  We should do everything to
communicate and emphasize the 1998/1999 decisions of the IETF and
IESG and the reasons behind it, and push the evolved standards!

It should say:

[see above]

Notes:

from pending

RFC 4283, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", November 2005

Source of RFC: mip6 (int)

Errata ID: 144
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-12-19
Held for Document Update by: Brian Haberman

Section 5 says:

   In addition, IANA has created a new namespace for the subtype field
   of the Mobile Node Identifier option.  The currently allocated values
   are as follows:

   NAI (defined in [RFC4282]).

It should say:

   In addition, IANA has created a new namespace for the subtype field
   of the Mobile Node Identifier option.  The currently allocated values
   are as follows:

      1  --  NAI (defined in [RFC4282]).

RFC 4285, "Authentication Protocol for Mobile IPv6", January 2006

Source of RFC: mip6 (int)

Errata ID: 143
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-02-03
Held for Document Update by: Brian Haberman

Section 2 says:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       |  Option Type  | Option Length |  Subtype      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Mobility SPI                                 |

It should say:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       |  Option Type  | Option Length |  Subtype      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Mobility SPI                                 |

RFC 4291, "IP Version 6 Addressing Architecture", February 2006

Note: This RFC has been updated by RFC 5952, RFC 6052, RFC 7136, RFC 7346, RFC 7371, RFC 8064

Source of RFC: ipv6 (int)

Errata ID: 1627
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yelland Mr Michael
Date Reported: 2007-03-02
Held for Document Update by: RFC Editor
Date Held: 2008-12-03

Section 2.7 says:

   Routers must not forward any multicast packets beyond of the scope
   indicated by the scop field in the destination multicast address.

It should say:

   Routers must not forward any multicast packets beyond the scope
   indicated by the scop field in the destination multicast address.

Notes:

extraneous "of"

RFC 4294, "IPv6 Node Requirements", April 2006

Note: This RFC has been obsoleted by RFC 6434

Note: This RFC has been updated by RFC 5095

Source of RFC: ipv6 (int)

Errata ID: 1915
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Thorsten Ulbricht
Date Reported: 2009-10-14
Held for Document Update by: Brian Haberman

Section 5.2 says:

5.3.3.  Use of Router Advertisements in Managed Environments

It should say:

5.2.3.  Use of Router Advertisements in Managed Environments

Errata ID: 1939
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Thorsten Ulbricht
Date Reported: 2009-11-03
Held for Document Update by: Brian Haberman

Section 12.1 says:

   [RFC-3484]     Frye, R., Levi, D., Routhier, S., and B. Wijnen,
                  "Coexistence between Version 1, Version 2, and Version
                  3 of the Internet-standard Network Management
                  Framework", BCP 74, RFC 3584, August 2003.

It should say:

   [RFC-3484]     Draves, R., "Default Address Selection for Internet
                  Protocol version 6 (IPv6)", RFC 3484, February
                  2003.

Notes:

wrong reference

RFC 4295, "Mobile IPv6 Management Information Base", April 2006

Source of RFC: mip6 (int)

Errata ID: 3551
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Held for Document Update by: Brian Haberman
Date Held: 2013-03-16

Section 5 says:

The DESCRIPTION clause of the mip6MnBLAcceptedTime OBJECT-TYPE,
on page 39, says:
                                                             v
|                  "The time at which the mobile node receives a binding
                    acknowledgment indicating that Binding Update has
                    been accepted (status code 0 or 1);
                    [...]

It should say:
                                                             v
|                  "The time at which the mobile node received a binding
                    acknowledgment indicating that Binding Update has
                    been accepted (status code 0 or 1);
                    [...]

or even better (similar to the mip6MnBLAccepted DESCRIPTION on the
same page):
                                                      vvvv       v
|                  "The time at which the mobile node has received a
                    binding acknowledgment indicating that Binding
                    Update has been accepted (status code 0 or 1);
                    [...]

Notes:

The items below are presented in RFC textual order.
I use change bars ('|' in column 1) and occasionally
up/down pointing marker lines ('^^^'/'vvv') to emphasize
the location of textual issues and/or proposed corrections.
Modified text has been re-adjusted to match RFC formatting
rules, where appropriate.

Errata ID: 3549
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Held for Document Update by: Brian Haberman
Date Held: 2013-03-16

 

It is accepted consensus in the IETF to use a common, mnemonic scheme
for the naming of tables, table rows, and columnar objects within
these rows, namely (variable text to be instantiated shown as <..>):

          <tableName>Table
            <tableName>Entry
              <tableName><Object1>
              <tableName><Object2>
               ...
              <tableName><Objectn>
or:
          <tableName>Table
            <tableName>Entry
              <tableNameShort><Object1>
              <tableNameShort><Object2>
               ...
              <tableNameShort><Objectn>
where
  <tableNameShort> is an abbreviated version of <tableName> .

Unfortunately, the mip6NodeTraffic counter table breaks this scheme.
Page 24 of RFC 4295 specifies:

        Mip6NodeTrafficEntry ::=
           SEQUENCE {
                 mip6NodeInOctets             Counter32,
|                mip6HCNodeInOctets           Counter64,
                 mip6NodeInPkts               Counter32,
|                mip6HCNodeInPkts             Counter64,
                 mip6NodeOutOctets            Counter32,
|                mip6HCNodeOutOctets          Counter64,
                 mip6NodeOutPkts              Counter32,
|                mip6HCNodeOutPkts            Counter64,
                 mip6NodeCtrDiscontinuityTime TimeStamp
           }

As can be seen, the irregularity is in the 'HC' (Counter64) names;
"mip6HCNodeXxx" should have been replaced by "mip6NodeHCXxx", i.e.,

        Mip6NodeTrafficEntry ::=
           SEQUENCE {
                 mip6NodeInOctets             Counter32,
|                mip6NodeHCInOctets           Counter64,
                 mip6NodeInPkts               Counter32,
|                mip6NodeHCInPkts             Counter64,
                 mip6NodeOutOctets            Counter32,
|                mip6NodeHCOutOctets          Counter64,
                 mip6NodeOutPkts              Counter32,
|                mip6NodeHCOutPkts            Counter64,
                 mip6NodeCtrDiscontinuityTime TimeStamp
           }

As the published irregular object names cannot be changed easily
after the fact, I hereby propose to introduce the regular object
names in a future update to the MIB module as *aliases* to the
irregular ones, bound to the same OIDs.
Of course,
-  the OBJECT-TYPE declarations of the four affected MIB objects,
   on page 25..28, and
-  the definition of the mip6NodeTrafficGroup OBJECT-GROUP,
   on page 81
would have to be adjusted accordingly.

( Perhaps, it would be best to change the symbolic object names
  in the above SEQUENCE definition, and in the OBJECT-TYPE and
  OBJECT-GROUP definitions, and add new OBJECT IDENTIFIER
  definitions to introduce the old, irregular names again,
  with the same OIDs, for backwards compatibility.)

Notes:

The items below are presented in RFC textual order.
I use change bars ('|' in column 1) and occasionally
up/down pointing marker lines ('^^^'/'vvv') to emphasize
the location of textual issues and/or proposed corrections.
Modified text has been re-adjusted to match RFC formatting
rules, where appropriate.

from pending

Errata ID: 3550
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Held for Document Update by: Brian Haberman
Date Held: 2013-03-16

 

The DESCRIPTION clause of the mip6MnHomeAddressState OBJECT-TYPE,
on page 30, suffers from a couple of word omissions.

The text:

                    home        -- mobile node is on the home network.
                    registered  -- mobile node is on a foreign network
                                   and is registered with the home
                                   agent.
                    pending     -- mobile node has sent registration
                                   request to the home agent and is
                                   waiting for the reply.
                    isolated    -- mobile node is isolated from network,
                                   i.e., it is not in its home network,
                                   it is not registered, and no
                                   registration ack is pending.

should perhaps better say:

|                   home        -- the mobile node is on the home
                                   network.
|                   registered  -- the mobile node is on a foreign
                                   network and is registered with the
                                   home agent.
|                   pending     -- the mobile node has sent a
                                   registration request to the home
                                   agent and is waiting for the reply.
|                   isolated    -- the mobile node is isolated from its
|                                  home network, i.e., it is not in its
                                   home network, it is not registered,
                                   and no registration ack is pending.

Notes:

The items below are presented in RFC textual order.
I use change bars ('|' in column 1) and occasionally
up/down pointing marker lines ('^^^'/'vvv') to emphasize
the location of textual issues and/or proposed corrections.
Modified text has been re-adjusted to match RFC formatting
rules, where appropriate.

from pending

Errata ID: 137
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Held for Document Update by: Brian Haberman
Date Held: 2013-03-16

 

(7)  description too unspecific, and punctuation

The DESCRIPTION clause of the mip6HaCompliance2 MODULE-COMPLIANCE,
on page 95, says:

                  "The compliance statement for SNMP entities
                   that implement the MOBILEIPV6-MIB and
                   support monitoring of the home agent
|                  functionality specifically the Home Agent List
|                  and the home-agent-registration-related statistics,
                   There are a number of INDEX objects [...]

for reasons as in item (5) and item (6) above,
it should better say:

                  "The compliance statement for SNMP entities
                   that implement the MOBILEIPV6-MIB and
|                  support detailed monitoring of the home agent
|                  functionality, specifically the Home Agent List
|                  and the home-agent-registration-related statistics.
                   There are a number of INDEX objects [...]


(8)  punctuation, and extraneous blank line

The DESCRIPTION clause of the mip6HaCompliance3 MODULE-COMPLIANCE,
on page 96, says:

                  "The compliance statement for SNMP entities
                   that implement the MOBILEIPV6-MIB and
                   support monitoring and control of the home agent
|                  functionality specifically the Home Agent List
|                  and the home-agent-registration-related statistics,
|
                   There are a number of INDEX objects [...]

It should say (see above items for rationale and similarity):

                  "The compliance statement for SNMP entities
                   that implement the MOBILEIPV6-MIB and
                   support monitoring and control of the home agent
|                  functionality, specifically the Home Agent List
|                  and the home-agent-registration-related statistics.
                   There are a number of INDEX objects [...]


(9)  punctuation, and extraneous blank line

The DESCRIPTION clause of the mip6HaReadOnlyCompliance2
MODULE-COMPLIANCE, on page 99, says:

                  "The compliance statement for SNMP entities
                   that implement the MOBILEIPV6-MIB without support
                   for read-write (i.e., in read-only mode) and
                   support monitoring of the home agent
|                  functionality specifically the Home Agent List
                   and the home-agent-registration-related statistics.
|
                   There are a number of INDEX objects [...]

It should say (see above items for rationale and similarity):

                  "The compliance statement for SNMP entities
                   that implement the MOBILEIPV6-MIB without support
                   for read-write (i.e., in read-only mode) and
                   support monitoring of the home agent
|                  functionality, specifically the Home Agent List
                   and the home-agent-registration-related statistics.
                   There are a number of INDEX objects [...]


(10) punctuation, and extraneous blank line

The DESCRIPTION clause of the mip6HaReadOnlyCompliance3
MODULE-COMPLIANCE, on page 101, says:

                  "The compliance statement for SNMP entities
                   that implement the MOBILEIPV6-MIB without support
                   for read-write (i.e., in read-only mode) and
?                  support monitoring and control of the home agent
|                  functionality specifically the Home Agent List
|                  and the home-agent-registration-related statistics,
|
                   There are a number of INDEX objects [...]

It should say (see above items for rationale and similarity):

                  "The compliance statement for SNMP entities
                   that implement the MOBILEIPV6-MIB without support
                   for read-write (i.e., in read-only mode) and
                   support monitoring and control of the home agent
|                  functionality, specifically the Home Agent List
|                  and the home-agent-registration-related statistics.
                   There are a number of INDEX objects [...]

Furthermore, arguably the words "and control" should better be
deleted since write access is not required.

Notes:

The items below are presented in RFC textual order.
I use change bars ('|' in column 1) and occasionally
up/down pointing marker lines ('^^^'/'vvv') to emphasize
the location of textual issues and/or proposed corrections.
Modified text has been re-adjusted to match RFC formatting
rules, where appropriate.

from pending

Errata ID: 3552
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Held for Document Update by: Brian Haberman
Date Held: 2013-03-16

 

The DESCRIPTION clause of the mip6MnCompliance2 MODULE-COMPLIANCE,
on page 93, says:

                  "The compliance statement for SNMP entities
                   that implement the MOBILEIPV6-MIB and
                   support monitoring of the mobile node
|                  functionality specifically the Discovery- and
|                  Registration-related statistics,
                   There are a number of INDEX objects [...]

It should say:

                  "The compliance statement for SNMP entities
                   that implement the MOBILEIPV6-MIB and
                   support monitoring of the mobile node
|                  functionality, specifically the Discovery- and
|                  Registration-related statistics.
                   There are a number of INDEX objects that cannot be

Notes:

The items below are presented in RFC textual order.
I use change bars ('|' in column 1) and occasionally
up/down pointing marker lines ('^^^'/'vvv') to emphasize
the location of textual issues and/or proposed corrections.
Modified text has been re-adjusted to match RFC formatting
rules, where appropriate.

from pending

RFC 4301, "Security Architecture for the Internet Protocol", December 2005

Note: This RFC has been updated by RFC 6040, RFC 7619

Source of RFC: ipsec (sec)

Errata ID: 135
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-01
Held for Document Update by: Pasi Eronen
Date Held: 2008-12-04

Appendix A2 says:

       Option/Extension Name                  Reference
       -----------------------------------    ---------
       MUTABLE BUT PREDICTABLE -- included in ICV calculation
         Routing (Type 0)                    [DH98]

       BIT INDICATES IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING
       TRANSIT)
         Hop-by-Hop options                  [DH98]
         Destination options                 [DH98]

       NOT APPLICABLE
         Fragmentation                       [DH98]

It should say:

       Option/Extension Name                  Reference
       -----------------------------------    ---------
       MUTABLE BUT PREDICTABLE
       -- included in ICV calculation
         Routing (Type 0)                       [DH98]

       BIT INDICATES IF OPTION IS MUTABLE
       (CHANGES UNPREDICTABLY DURING TRANSIT)
         Hop-by-Hop options                     [DH98]
         Destination options                    [DH98]

       NOT APPLICABLE
         Fragmentation                          [DH98]

Notes:

Perhaps it should be formatted as shown above to avoid the overlap of the columns.

Errata ID: 717
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-01
Held for Document Update by: Pasi Eronen
Date Held: 2010-03-11

 

(1)  [typo]

In section 4.1, on page 14, RFC 4301 says:

   DISCUSSION: Although the DSCP [NiBlBaBL98, Gro02] and Explicit
   Congestion Notification (ECN) [RaFlBl01] fields are not "selectors",
   as that term in used in this architecture, the sender will need a
   mechanism to direct packets with a given (set of) DSCP values to the
   appropriate SA.  This mechanism might be termed a "classifier".

It should say ( s/in used/is used/ ) :

   DISCUSSION: Although the DSCP [NiBlBaBL98, Gro02] and Explicit
   Congestion Notification (ECN) [RaFlBl01] fields are not "selectors",
|  as that term is used in this architecture, the sender will need a
   mechanism to direct packets with a given (set of) DSCP values to the
   appropriate SA.  This mechanism might be termed a "classifier".

(2)  [textual improvement]

In section 4.4.3.2, the last lines on page 45 say:

                                                      [...].  An entry
   used with certificate-based authentication MAY include additional
   data to facilitate certificate revocation status, e.g., a list of
 << page break >>
   appropriate OCSP responders or CRL repositories, [...]

This seems to make not much sense. It should perhaps say:

                                                      [...].  An entry
   used with certificate-based authentication MAY include additional
   data to facilitate certificate revocation status determination, e.g.,
   a list of appropriate OCSP responders or CRL repositories, [...]

(3)  [typo]

The second paragraph of section 4.4.3.3, on page 46, says:

   If the entry indicates that the IKE ID is to be used, then the PAD
   entry ID field defines the authorized set of IDs.  If the entry
   indicates that child SAs traffic selectors are to be used, then an
   additional data element is required, in the form of IPv4 and/or IPv6
   address ranges. [...]

It should say ( s/SAa/SA/ ) :

   If the entry indicates that the IKE ID is to be used, then the PAD
   entry ID field defines the authorized set of IDs.  If the entry
|  indicates that child SA traffic selectors are to be used, then an
   additional data element is required, in the form of IPv4 and/or IPv6
   address ranges. [...]

(4)  [textual consistency]

Below the table on page 59, section 5.1.2.2 says:

    Notes:

      (1) - (6) See Section 5.1.2.1.

It should say:

    Notes:

|     (1) - (3), (5), (6)  See Section 5.1.2.1.


(5)  [typo]

The second paragraph of App. D.2, on page 89, says:

                                                    [...]. (If we choose
   to allow carriage of fragments on transport mode SAs for IPv6, the
   problems arises in that context as well.)
          ^     ^^

There obviously is a singular/plural mismatch.
The text should say:
                                                    [...]. (If we choose
   to allow carriage of fragments on transport mode SAs for IPv6, the
|  problem arises in that context as well.)


(6)  Insufficient IPcomp integration

At the end of section 3.1, on page 10, RFC 4301 says:

   IPsec optionally supports negotiation of IP compression [SMPT01],
   motivated in part by the observation that when encryption is employed
   within IPsec, it prevents effective compression by lower protocol
   layers.

It has also been observed that payload compression can help counter
TPA.  Thus, there are at least two reasons for a tight integration
of IPComp with IPsec.
But I could not find any 'hook' in RFC 4301 (and in RFC 4302 / 4303
as well) for the concrete support of IPComp in ESP / AH IPsec SAs.

IKEv2 (RFC 4306) roughly allows negotiation of IPComp, but how shall
that be triggered and work, in an interoperable way, if there are no
architectural provisions for the support of IPComp designed in into
the IPsec databases (SPD, SAD) as described in RFC 4301 ????


(7)  Insufficient integration with QoS (DS)

The steps taken for the integration with Differentiated Services
are half-hearted.  The processing rules specified for the DSCP
field in the IP header[s] remain incomplete as long as there is
no specified interoperable way to use DSCP as an selector as well.

IMHO, the discussion on page 14 of RFC 4301 is misleading because
DS classification and treatment needs to be done independent from
IPsec treatment.
In many scenarios, e.g. on 'hosts' or 'QoS gateways' that must
perform fine-grained traffic classification, DS treatment must
be performed strictly before IPsec treatment in the outbound
case (and after IPsec in the inbound case), to make ULP fields
accessible to the DS classifiers.
IPsec should then be capable of guaranteeing the same security
treatment of all packets of certain traffic class to a given
destination.

I still have problems to imagine how DS integration could be
achieved with the processing model of section 5.1 of RFC 4301.

At the end of section 3.1, on page 10, RFC 4301 says:


(8)  Inconsistent DS Field handling specified in Section 5.1.2.x

The IPv6 related table in section 5.1.2.2 contains the line,

        DS Field         copied from inner hdr (5)    no change (9)

and the subsequent Notes give a lengthy explanation under (9).

Contrary to that, the corresponding table line for IPv4, in section
5.1.2.1 on page 57, is *not* linked to such a note.

I cannot see any reason precluding the application of the arguments
given in Note (9) of section 5.1.2.2 to the IPv4 case as well.

Have I missed any significant point there?


(9)  SA negotiation -- capability mismatch with IKEv2

See section 4.4.1.2, second paragraph.

It should say:

[see above]

Notes:

from pending

Errata ID: 1684
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2009-02-17
Held for Document Update by: Pasi Eronen

Section 4.5.3. says:

   Consider a situation in which a remote host (SH1) is using the
   Internet to gain access to a server or other machine (H2) and there
   is a security gateway (SG2), e.g., a firewall, through which H1's
   traffic must pass.

It should say:

   Consider a situation in which a remote host (SH1) is using the
   Internet to gain access to a server or other machine (H2) and there
   is a security gateway (SG2), e.g., a firewall, through which SH1's
   traffic must pass.

Errata ID: 1713
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2009-03-12
Held for Document Update by: Pasi Eronen

Section 12 says:

   The IANA has assigned the value (3) for the asn1-modules registry and
   has assigned the object identifier 1.3.6.1.5.8.3.1 for the SPD
   module.  See Appendix C, "ASN.1 for an SPD Entry".

It should say:

   The IANA has assigned the value (3) for the asn1-modules registry and
   has assigned the object identifier 1.3.6.1.5.5.8.3.1 for the SPD
   module.  See Appendix C, "ASN.1 for an SPD Entry".

Notes:

See http://www.iana.org/assignments/smi-numbers

Errata ID: 2179
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner

Section 4.4.2.2 says:

list of prot's

It should say:

list of prots

Notes:

This is not genitive. It's plural.

Errata ID: 2181
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Tim Polk

Section 4.4.3.1. says:

The Key ID field is defined as an OCTET string in IKE.  For this name
type, only exact-match syntax MUST be supported (since there is no
explicit structure for this ID type).  Additional matching functions
MAY be supported for this ID type.

It should say:

The Key ID field is defined as an OCTET string in IKE.  For this name
type, exact-match syntax MUST be supported (since there is no
explicit structure for this ID type).  Additional matching functions
MAY be supported for this ID type.

Notes:

'only A must be supported' is ambigous.
Does it mean 'A must be supportet and anything else must not be supportet', or does it mean 'A must be supportet and anything else may be supportet'. The next sentence clearifies that it is the second interpretation.

Errata ID: 2182
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Tim Polk

Section 4.4.3.2 says:

This document requires support for two required authentication data
types:

It should say:

This document requires support for two authentication data
types:

Notes:

pleonasm

RFC 4302, "IP Authentication Header", December 2005

Source of RFC: ipsec (sec)

Errata ID: 744
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-01
Held for Document Update by: Pasi Eronen

 

(1)

RFC 4301, in section 13, "Differences from RFC 2401", in the
second bulleted item (near the top of page 73) states:

   o There is no longer a requirement to support nested SAs or "SA
     bundles".  [...]

And later on, on page 74:

   o Support for AH in both IPv4 and IPv6 is no longer required.

Therefore, the paragraph on page 10 of RFC 4302,

   ESP and AH headers can be combined in a variety of modes.  The IPsec
   Architecture document describes the combinations of security
   associations that must be supported.
                     ^^^^^^^^^^^^^^^^^
entails more or less a "NOPE".  If something like the second
sentence is still desired, it might better say, e.g.,

   ESP and AH headers can be combined in a variety of modes.  The IPsec
   Architecture document briefly describes the methods to configure
   such combinations of security associations.


(2)

On page 25, Appendix A1 presents a table classifying the IPv4 options.
Within that table, the second column is partially misaligned.


(3)

On page 26, the table within Appendix A2 classifying the IPv6
extension headers,

       Option/Extension Name                  Reference
       -----------------------------------    ---------
       MUTABLE BUT PREDICTABLE -- included in ICV calculation
         Routing (Type 0)                    [DH98]

       BIT INDICATES IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING
       TRANSIT)
         Hop-by-Hop options                  [DH98]
         Destination options                 [DH98]

       NOT APPLICABLE
         Fragmentation                       [DH98]

perhaps would have better been formatted like:

       Option/Extension Name                  Reference
       -----------------------------------    ---------
       MUTABLE BUT PREDICTABLE
       -- included in ICV calculation
         Routing (Type 0)                       [DH98]

       BIT INDICATES IF OPTION IS MUTABLE
       (CHANGES UNPREDICTABLY DURING TRANSIT)
         Hop-by-Hop options                     [DH98]
         Destination options                    [DH98]

       NOT APPLICABLE
         Fragmentation                          [DH98]

to avoid the overlap of the columns.


(4)

In Appendix B2.1, at one place on page 30, the variable
"seqh" is mis-spelled as "seqH" (this is in the 6th-to-last
line of Appendix B2.1).


(5)

Appendix B, as a whole, is a [near] duplicate of Appendix A of
RFC 4303; the latter does not contain the typo from item (4)
above, and it contains extended and improved explanations in
the third subsection -- corresponding to page 32 of RFC 4302.

Readers and potential implementors need to read both Appendices
just to detect that they are in fact essentially the same spec.

IMHO, it would have been better to avoid this re-specification,
and instead have pointers to the (better, and mandatory!) ESP
Appendix placed into the AH RFC.
Having a single specification always avoids disagreement or
inconsistency, and it facilitates the maintenance of the spec.


(6)

Finally:
I would have appreciated the introduction of an explicit version
numbering for AH, e.g. rename:
      AH as per RFC 1826  to  AHv1,
      AH as per RFC 2402  to  AHv2  or  AHv2.0,   and
      AH as per RFC 4302  to  AHv3  or  AHv2.1
(or similar).

This would make it easier to specify / identify versions and/or
version specific behaviour in implementations, without having
to refer to the RFC numbers explicitely. (Similar numbering has
proven very useful with protocols like BGP, SNMP, IMAP, POP, etc.)

It should say:

[see above]

Notes:

from pending

Errata ID: 1644
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2008-12-25
Held for Document Update by: Pasi Eronen

Section B2 says:

Appendix B2 says:
     + Case A: Tl >= (W - 1). In this case, the window is within one
                              sequence number subspace.  (See Figure 1)
     + Case B: Tl < (W - 1).  In this case, the window spans two
                              sequence number subspaces.  (See Figure 2)

   In the figures below, the bottom line ("----") shows two consecutive
   sequence number subspaces, with zeros indicating the beginning of
   each subspace.  The two shorter lines above it show the higher-order
   bits that apply.  The "====" represents the window.  The "****"
   represents future sequence numbers, i.e., those beyond the current
   highest sequence number authenticated (ThTl).
        Th+1                         *********

        Th               =======*****

              --0--------+-----+-----0--------+-----------0--
                         Bl    Tl            Bl
                                        (Bl+2^32) mod 2^32

                            Figure 1 -- Case A


        Th                           ====**************

        Th-1                      ===

              --0-----------------+--0--+--------------+--0--
                                  Bl    Tl            Bl
                                                 (Bl+2^32) mod 2^32

                            Figure 2 -- Case B

It should say:

Must say:
     + Case A: Tl >= (W - 1). In this case, the window is within one
                              sequence number subspace.  (See Figure 2)
     + Case B: Tl < (W - 1).  In this case, the window spans two
                              sequence number subspaces.  (See Figure 3)

   In the figures below, the bottom line ("----") shows two consecutive
   sequence number subspaces, with zeros indicating the beginning of
   each subspace.  The two shorter lines above it show the higher-order
   bits that apply.  The "====" represents the window.  The "****"
   represents future sequence numbers, i.e., those beyond the current
   highest sequence number authenticated (ThTl).
        Th+1                         *********

        Th               =======*****

              --0--------+-----+-----0--------+-----------0--
                         Bl    Tl            Bl
                                        (Bl+2^32) mod 2^32

                            Figure 2 -- Case A


        Th                           ====**************

        Th-1                      ===

              --0-----------------+--0--+--------------+--0--
                                  Bl    Tl            Bl
                                                 (Bl+2^32) mod 2^32

                            Figure 3 -- Case B

Notes:

Wrong numbers for figures in Section B2.

Errata ID: 1645
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2008-12-26
Held for Document Update by: Pasi Eronen

Section B2.2 says:

      + Under Case A (Figure 1):
        If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th
        If Seql <  Bl (where Bl = Tl - W + 1), then Seqh = Th + 1

      + Under Case B (Figure 2):
        If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th - 1
        If Seql <  Bl (where Bl = Tl - W + 1), then Seqh = Th

It should say:

      + Under Case A (Figure 2):
        If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th
        If Seql <  Bl (where Bl = Tl - W + 1), then Seqh = Th + 1

      + Under Case B (Figure 3):
        If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th - 1
        If Seql <  Bl (where Bl = Tl - W + 1), then Seqh = Th

Notes:

Wrong numbering for figures

Errata ID: 2157
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Carsten Bormann
Date Reported: 2010-04-10
Held for Document Update by: Sean Turner

Section 2.5 says:

anti-reply

It should say:

anti-replay

Notes:

(End of first para.)
Obvious, but maybe confusing to learners.

RFC 4303, "IP Encapsulating Security Payload (ESP)", December 2005

Source of RFC: ipsec (sec)

Errata ID: 3876
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Yaron Sheffer
Date Reported: 2014-01-31
Held for Document Update by: Stephen Farrell
Date Held: 2014-05-08

Section Introduction says:

Using encryption-only for confidentiality is allowed by ESP. However, it
should be noted that in general, this will provide defense only against
passive attackers.  Using encryption without a strong integrity
mechanism on top of it (either in ESP or separately via AH) may render
the confidentiality service insecure against some forms of active
attacks [Bel96, Kra01].  Moreover, an underlying integrity service, such
as AH, applied before encryption does not necessarily protect the
encryption-only confidentiality against active attackers [Kra01]. ESP
allows encryption-only SAs because this may offer considerably better
performance and still provide adequate security, e.g., when higher-layer
authentication/integrity protection is offered independently. However,
this standard does not require ESP implementations to offer an
encryption-only service.

It should say:

Using encryption-only for confidentiality is allowed by ESP.
However, it should be noted that in general, this will provide defense
only against passive attackers.  Using encryption without a strong
integrity mechanism on top of it (either in ESP or separately via AH)
may render the confidentiality service insecure against some forms of
active attacks [Bel96, Kra01, DP07].  Moreover, applying AH
before encryption does not protect the encryption-only
confidentiality against active attackers [DP10]. ESP
allows encryption-only SAs primarily for compatibility with older
implementations, and because this may offer better performance.
It is noted (and has been demonstrated, e.g. in [DP07]) that
ESP in this mode does not provide adequate security even when
higher-layer authentication/integrity protection is offered
independently. This standard does not require ESP implementations to
offer an encryption-only service.

[DP07] Jean Paul Degabriele and Kenneth G. Paterson, Attacking the
IPsec Standards in Encryption-only Configurations, IACR 2007/125.

[DP10] Jean Paul Degabriele and Kenneth G. Paterson: On the
(in)security of IPsec in MAC-then-encrypt configurations.
ACM Conference on Computer and Communications Security 2010:
493-504. 

Notes:

The existing text asserts that ESP in encryption-only mode can in some cases provide "adequate security", even though the sense of the paragraph is in general against it. A series of papers published subsequently to the RFC demonstrate that this assertion is incorrect: active attackers can defeat the confidentiality guarantees, and such attacks are practical.

Errata ID: 721
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-01
Held for Document Update by: Pasi Eronen
Date Held: 2010-03-11

 

(1)

Section 2.1 of RFC 4303 re-states a lot of material from the
IPsec Architecture document, RFC 4301, without being able to
present all the details.  SPI selection has become a quite
complicated procedure with subtle details, which all can be
found in RFC 4301.

IMHO, it would have been very much preferrable to replace most
of the text in section 2.1 by a short referral to RFC 4301.
Any replication of specification entails the danger of
inconsistencies and raises the question of "truth weight"
for the concurring specifications; it is better to avoid
such "races" from the beginning.

This same issue applies to section 2.4 of RFC 2402. (By accident,
I have forgotten to mention it in my comments on that document.)

More concretely, I would have preferred the replacement of the
second up to the second-to-last paragraph of section 2.1 of RFC 4303,
on pages 10/11,

  For a unicast SA, the SPI can be used by itself to specify an SA, or
  it may be used in conjunction with the IPsec protocol type (in this
  ...

  ...
  ...
  ...

  ...
  multicast address, and source address.  An Any-Source Multicast group
  SA requires only an SPI and a destination multicast address as an
  identifier.

by a short note, e.g.

  All implementations of ESP MUST support the Security Association
  Database (SAD) as specified in the IPsec Archtecture document
  [Ken-Arch] and the SA lookup procedures for unicast traffic
  specified therein.  ESP implementations SHOULD support extensions
  to the SAD and the SA lookup procedures specified in documents
  amending [Ken-Arch], e.g. for multicast traffic or mobility support,
  if they intend to provide ESP support for such scenarios.

A similar change would be applicable to RFC 4302, section 2.4,
pages 6/7.


(2)

In section 3.4.3, on the lower half of page 29, RFC 4303 says:

                                                    [...].  In either
   case, if the integrity check fails, the receiver MUST discard the
   received IP datagram as invalid; this is an auditable event.  The
   audit log entry for this event SHOULD include the SPI value,
   [...]

Because the audit log details are in a separate sentence, the logical
hierarchy implied by using one semicolon and one full stop is brocken.
It would have been better to say:
                                                    [...].  In either
   case, if the integrity check fails, the receiver MUST discard the
|  received IP datagram as invalid.  This is an auditable event.  The
   audit log entry for this event SHOULD include the SPI value,
   [...]

Similar punctuation already is used in many places of the RFC.


(3)

As mentioned in section 7, section 3.4 has been reorganized from
RFC 2406.
During that process, the perhaps most important part of ESP inbound
packet processing has disappeared from the section headlines:
decryption !

To cover what's inside, and to make that locatable in the ToC,
perhaps the section headline,

 3.4.4.  Integrity Check Value Verification

on page 30, and in the ToC, should be modified to read:

 3.4.4.  Integrity Check Value Verification and Payload Decryption

I would like to recommend that you submit an RFC Errata Note to
catch this issue.


(4)

In section 3.4.4.2, the same issue as (2) above also applies to
the item numbered "2." on page 32.


(5)  References

RFC 4306 repeatedly refers to its predecessor, RFC 2406, but it omits
giving a formal (Informative) Reference to that document in Section
10.2 on page 37.

Perhaps it would also have been worth noting that a *full* version
of the research paper [Kra01] can be found on IACR ePrint, document
2001/040.


(6)  Appendix A

As mentioned in my comments on RFC 4302, this appendix is the more
complete and hence preferrable text compared to App. B of RFC 4302.
There is one exception:
The formatting of tha last part of A2.1 ia less pleasant.
To enhance readability, it is always preferrable not to break
simple expressions apart by line breaks, whenever possible.  In
this case, simple relational expressions are broken into 2 lines.

RFC 4303, on page 40, says:

   In checking for replayed packets,

      + Under Case A: If Seql >= Bl (where Bl = Tl - W + 1) AND Seql <=
        Tl, then check the corresponding bit in the window to see if
        this Seql has already been seen.  If yes, reject the packet.  If
        no, perform integrity check (see Appendix A2.2. below for
        determination of Seqh).

      + Under Case B: If Seql >= Bl (where Bl = Tl - W + 1) OR Seql <=
        Tl, then check the corresponding bit in the window to see if
        this Seql has already been seen.  If yes, reject the packet.  If
        no, perform integrity check (see Appendix A2.2. below for
        determination of Seqh).

The formatting in RFC 4302 of the same text (with the already
mentioned typo there corrected, and the Appendix name adapted),
is better:

   In checking for replayed packets,

      + Under Case A: If Seql >= Bl (where Bl = Tl - W + 1) AND
        Seql <= Tl, then check the corresponding bit in the window to
        see if this Seql has already been seen.  If yes, reject the
        packet.  If no, perform integrity check (see Appendix A2.2
        below for determination of Seqh).

      + Under Case B: If Seql >= Bl (where Bl = Tl - W + 1) OR
        Seql <= Tl, then check the corresponding bit in the window to
        see if this Seql has already been seen.  If yes, reject the
        packet.  If no, perform integrity check (see Appendix A2.2
        below for determination of Seqh).

But I would even have preferred this formatting:

   In checking for replayed packets,

      + Under Case A:
        If Seql >= Bl (where Bl = Tl - W + 1) AND Seql <= Tl,
        then check the corresponding bit in the window to see if this
        Seql has already been seen.  If yes, reject the packet.
        If no, perform integrity check (see Appendix A2.2 below for
        determination of Seqh).

      + Under Case B:
        If Seql >= Bl (where Bl = Tl - W + 1) OR Seql <= Tl,
        then check the corresponding bit in the window to see if this
        Seql has already been seen.  If yes, reject the packet.
        If no, perform integrity check (see Appendix A2.2 below for
        determination of Seqh).

It should say:

[see above]

Notes:

from pending

Errata ID: 859
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-01
Held for Document Update by: Pasi Eronen

 

The 'version numbering' issue (as reported as item (6) for RFC 4302)

I would have appreciated the introduction of an explicit version
numbering for ESP, e.g. rename:
      ESP as per RFC 1827  to  ESPv1,
      ESP as per RFC 2406  to  ESPv2  or  ESPv2.0,   and
      ESP as per RFC 4303  to  ESPv3  or  ESPv2.1
(or similar).

This would make it easier to specify / identify versions and/or
version specific behaviour in implementations, without having
to refer to the RFC numbers explicitely. (Similar numbering has
proven very useful with protocols like BGP, SNMP, IMAP, POP, etc.)

Notes:

from pending

RFC 4306, "Internet Key Exchange (IKEv2) Protocol", December 2005

Note: This RFC has been obsoleted by RFC 5996

Note: This RFC has been updated by RFC 5282

Source of RFC: ipsec (sec)

Errata ID: 2190
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner

Section 2.5. says:

Similarly, payload types that are not defined are reserved for future
use; implementations of version 2.0 MUST skip over those payloads and
ignore their contents.

It should say:

Similarly, payload types that are not defined are reserved for future
use.

Notes:

The behaviour of an implementation of version 2.0 depends on the critical flag. See next paragraph.

Errata ID: 2191
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner

Section 3.2. says:

whose type code appears in the first octet.  The reasoning behind
not setting the critical bit for payloads defined in this document
is that all implementations MUST understand all payload types
defined in this document and therefore must ignore the Critical
bit's value.  Skipped payloads are expected to have valid Next

It should say:

?

Notes:

Difficult to understand. More explanation needed:
An implementation of IKE which is older than 2.0 does not know about the
critical bit and will skip an unknown payload. This behaviour fits to
cleared critical bit.

Errata ID: 2192
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner

Section 3.3. says:

If there are multiple transforms with the same Transform Type, the
proposal is an OR of those transforms.  If there are multiple
Transforms with different Transform Types, the proposal is an AND of
the different groups.  For example, to propose ESP with (3DES or

It should say:

If there are multiple transforms with the same Transform Type, those
transforms constitute a group out of which exactly one transform is
to be chosen. If there are multiple of those groups, the proposal is
an AND of the choices out of the different groups.  For example, to
propose ESP with (3DES or

Notes:

Logically unclear. OR means AND/OR. But here you talk about XOR.
Furthermore has AND precedence before OR.

Errata ID: 2194
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner

Section 3.12. says:

identify the implementation as an aid in debugging.  A Vendor ID
payload MUST NOT change the interpretation of any information defined
in this specification (i.e., the critical bit MUST be set to 0).

It should say:

- delete it -

Notes:

According to 3.2 the critical bit has to be clear.
And the rest is trivial: To be compliant you have to comply.

Errata ID: 2195
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner

Section 3.15. says:

Some attributes MAY be multi-valued, in which case multiple attribute
values of the same type are sent and/or returned.  Generally, all
values of an attribute are returned when the attribute is requested.

It should say:

Some attributes MAY be multi-valued, in which case multiple
Configuration Attribute structures of the same type are sent and/or
returned.  Generally, all values of an attribute are returned when
the attribute is requested.

Notes:

The text may suggest that there may be multiple values in one
Configuration Attribute structure.

Errata ID: 1671
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2009-01-28
Held for Document Update by: Pasi Eronen

Section 3.1 says:

       --  V(ersion) (bit 4 of Flags) - This bit indicates that
           the transmitter is capable of speaking a higher major
           version number of the protocol than the one indicated
           in the major version number field.  Implementations of
           IKEv2 must clear this bit when sending and MUST ignore
           it in incoming messages.

It should say:

       --  V(ersion) (bit 4 of Flags) - This bit indicates that
           the transmitter is capable of speaking a higher major
           version number of the protocol than the one indicated
           in the major version number field.  Implementations of
           IKEv2 MUST clear this bit when sending and MUST ignore
           it in incoming messages.

Errata ID: 1672
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2009-01-29
Held for Document Update by: Pasi Eronen

Section 3.3.2 says:

      o  0 (last) or 3 (more) (1 octet) - Specifies whether this is the
         last Transform Substructure in the Proposal.  This syntax is
         inherited from ISAKMP, but is unnecessary because the last
         Proposal could be identified from the length of the SA.

It should say:

      o  0 (last) or 3 (more) (1 octet) - Specifies whether this is the
         last Transform Substructure in the Proposal.  This syntax is
         inherited from ISAKMP, but is unnecessary because the last
         Transform could be identified from the length of the Proposal.

Errata ID: 2196
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner

Section 3.15. says:

For some attributes (in this version of the specification only
internal addresses), multiple requests indicates a request that
multiple values be assigned.  For these attributes, the number of

It should say:

For some attributes (in this version of the specification only
internal addresses), multiple requests indicate a request that
multiple values be assigned.  For these attributes, the number of

Notes:

typo

RFC 4307, "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)", December 2005

Note: This RFC has been obsoleted by RFC 8247

Source of RFC: ipsec (sec)

Errata ID: 131
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-02-03
Held for Document Update by: Pasi Eronen

Section 3.1.3 says:

   IKEv2 defines several possible algorithms for Transfer Type 1
   (encryption).  These are defined below with their implementation
   status.

It should say:

   IKEv2 defines several possible algorithms for Transform Type 1
   (encryption).  These are defined below with their implementation
   status.

Errata ID: 685
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-02-03
Held for Document Update by: Pasi Eronen

Section 3.1.4 says:

Transfer Type 2 Algorithms are pseudo-random functions used to
generate random values when needed.

It should say:

Transform Type 2 Algorithms are pseudo-random functions used to
generate random values when needed.

Notes:

from pending

Errata ID: 687
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-02-03
Held for Document Update by: Pasi Eronen

Section 3.1.5 says:

Transfer Type 3 Algorithms are Integrity algorithms used to protect
data against tampering.

It should say:

Transform Type 3 Algorithms are Integrity algorithms used to protect
data against tampering.

Notes:

from pending

Errata ID: 688
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-02-03
Held for Document Update by: Pasi Eronen

 

Like other contemporary RFCs, RFC 4307 seems to have been infected
by a common 'virus'. In the case or RFC 4307, the first sentence of the Introduction has been inadvertantly split by a spurious blank line.

Notes:

from pending

Errata ID: 690
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-02-03
Held for Document Update by: Pasi Eronen

 

On pages 3 and 4 of RFC 4307, the text in Section 3.1.3 through
Section 3.1.5 contains three instances of the same typo,
talking about    [algorithms of] "Transfer Type <n>"  , where it
should refer to  [algorithms of] "Transform Type <n>".

Notes:

typo breaking IPsec terminology

from pending

RFC 4309, "Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)", December 2005

Source of RFC: ipsec (sec)

Errata ID: 130
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Aaron Cohen
Date Reported: 2006-01-05
Held for Document Update by: Pasi Eronen

Page heading says:

RFC 4309           Using AEC CCM Mode with IPsec ESP       December 2005

It should say:

RFC 4309           Using AES CCM Mode with IPsec ESP       December 2005

Notes:

In RFC 4309 the page headings have a typo AES is misspelled as AEC.

RFC 4312, "The Camellia Cipher Algorithm and Its Use With IPsec", December 2005

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 128

Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-02-03
Held for Document Update by: Russ Housley
Report Text:

Informative References need to be updated

Rationale:
RFC 4312 apparently has been published a bit later than, but
closely coordinated with, the new IPsec document suite (RFC 430x).

Accordingly, the Normative Reference [ESP] of RFC 4312 points to
the new ESP RFC 4303, as expected.

But surprisingly, the Informative References are not updated
similarly.
I would have expected [ARCH] pointing to RFC 4301 (that has
obsoleted RFC 2401), and at least an additional Ref. to IKEv2
(RFC 4306, which substantially amends/updates the old RFC 2409
[IKE]) -- with title and text of Section 4 slightly adapted.
The current text and Ref. [IKE] even might lead to the mis-
conception that the Camellia cipher would not be suitable for
use with IKEv2 (a statement certainly not intended by you).

---

RFC 4319, "Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines", December 2005

Source of RFC: adslmib (ops)

Errata ID: 2633
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Stefan Reichmuth
Date Reported: 2010-11-16
Held for Document Update by: Dan Romascanu

Section 3 says:

   hdsl2ShdslEndpointCurrAtn OBJECT-TYPE
      SYNTAX      Integer32(-127..128)

[...]

   hdsl2ShdslEndpointCurrSnrMgn OBJECT-TYPE
      SYNTAX      Integer32(-127..128)

It should say:

   hdsl2ShdslEndpointCurrAtn OBJECT-TYPE
      SYNTAX      Integer32(-128..127)

[...]

   hdsl2ShdslEndpointCurrSnrMgn OBJECT-TYPE
      SYNTAX      Integer32(-128..127)

Notes:

The data type for SNR margin and loop attenuation defined in ITU-T G.991.2 section 9.5.5.7.14 is signed char (-128..127). In particular for the attenuation value it is important that -128 is part of the allowed range, because this means 'not available'.

RFC 4322, "Opportunistic Encryption using the Internet Key Exchange (IKE)", December 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 2450
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-20
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 1.2 says:

The 2nd paragraph on page 3 says:

                     [...].  A future document [IPSECKEY] will describe
   a variation that complies with RFC 3445.  [...]

The reference  [IPSECKEY]  has been updated before publication of
RFC 4322 to point to RFC 4025 (cf. the first entry in Section 14.2,
on page 42).  Hence this wording in not appropriate and inconsistent.
The text should say:
                             vvvvvvvv                  vvv       v
|                    [...].  Another document [IPSECKEY] describes
   a variation that complies with RFC 3445.  [...]

Notes:

To facilitate the recognition of the text changes proposed,
I have added change bars ('|') in column 1, and up/down pointing
marker lines ('^^^'/'vvv').

Errata ID: 2453
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-20
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 3.2.7 says:

The second paragraph of that section refers to [RFC1034]:

   The DNS query and answer that lead to the expiring connection state
   are also examined.  The DNS query may become stale.  (A negative,
   i.e., no such record, answer is valid for the period of time given by
   the MINIMUM field in an attached SOA record.  See [RFC1034] section
   4.3.4.)  [...]

This reference is not very appropriate, and hence misleading.
RFC 1034, and in particular section 4.3.4 of RFC 1034, has been
substantially clarified and updated by RFC 2308.
The Abstract of RFC 2308 says:
   "This document ... replaces [RFC1034 Section 4.3.4]."
(The precise rule for determining the 'negative caching TTL' is a
bit more complicated, taking the minimum of SOA.MINIMUM and SOA.TTL.)

Therefore, RFC 4322 should better refer to RFC 2308, in this place,
perhaps with a detailed hint pointing to section 5 of RFC 2308.

Notes:

To facilitate the recognition of the text changes proposed,
I have added change bars ('|') in column 1, and up/down pointing
marker lines ('^^^'/'vvv').

RFC 4335, "The Secure Shell (SSH) Session Channel Break Extension", January 2006

Source of RFC: secsh (sec)

Errata ID: 1309
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-02-05
Held for Document Update by: Pasi Eronen

Section 3, 1st para says:

   The following channel-specific request can be sent over a session
   channel (as described in [4]) to request that the remote host perform
   a BREAK operation.

It should say:

   The following channel-specific request can be sent over a session
|  channel (as described in [5]) to request that the remote host perform
   a BREAK operation.

Notes:

The relevant information is in RFC 4254 [5], "SSH Connection Protocol",
in particular sections 5 and 6.
RFC 4253 [4] does not even mention the concept of session channels
to any notable detail.

Errata ID: 1310
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-02-05
Held for Document Update by: Pasi Eronen

Section 3, last para says:

   If the 'want_reply' boolean is set, the server MUST reply using an
   SSH_MSG_CHANNEL_SUCCESS or SSH_MSG_CHANNEL_FAILURE [5] message.  If a
   BREAK of any kind was preformed, SSH_MSG_CHANNEL_SUCCESS MUST be
   sent.  If no BREAK was preformed, SSH_MSG_CHANNEL_FAILURE MUST be
   sent.

It should say:

   If the 'want_reply' boolean is set, the server MUST reply using an
   SSH_MSG_CHANNEL_SUCCESS or SSH_MSG_CHANNEL_FAILURE [5] message.  If a
|  BREAK of any kind was performed, SSH_MSG_CHANNEL_SUCCESS MUST be
|  sent.  If no BREAK was performed, SSH_MSG_CHANNEL_FAILURE MUST be
   sent.

Notes:

s/preformed/performed/g

RFC 4337, "MIME Type Registration for MPEG-4", March 2006

Note: This RFC has been updated by RFC 6381

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rai

Errata ID: 121
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-19
Held for Document Update by: Robert Sparks

Section 5 says:

   Security considerations: See section 5 of RFC 4337.

It should say:

   Security considerations: See section 4 of RFC 4337.

Notes:

The Security Considerations *are* in Section 4 of RFC 4337.
Note: This must have been a last-minute "fix", the draft was o.k.

I recommend to have the IANA update the registrations accordingly.

RFC 4339, "IPv6 Host Configuration of DNS Server Information Approaches", February 2006

Source of RFC: dnsop (ops)

Errata ID: 120
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-02
Held for Document Update by: Ron Bonica

Section 5.3.3 says:

   4.  It is sub-optimal to utilize the radio resources in 3GPP networks
       for DHCPv6 messages if there is a simpler alternative is
       available.
 

It should say:

   4.  It is sub-optimal to utilize the radio resources in 3GPP networks
       for DHCPv6 messages if there is a simpler alternative available.

Notes:

from pending

RFC 4343, "Domain Name System (DNS) Case Insensitivity Clarification", January 2006

Note: This RFC has been updated by RFC 5890

Source of RFC: dnsext (int)

Errata ID: 6361
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Kaspar Etter
Date Reported: 2020-12-22
Held for Document Update by: Eric Vyncke
Date Held: 2021-01-04

Section 4.1 says:

No "case conversion" or "case folding" is done during such output operations, thus "preserving" case.

It should say:

?

Notes:

Whose case is preserved? The case of the label in the DNS query or the case of the label in the DNS database? In other words, if there is a DNS record for ietf.org and I query IETF.org, should the DNS response say ietf.org or IETF.org? I would expect it's the former so that the DNS administrator can inform the DNS requester about the preferred capitalization but I can't figure this out on the basis of the RFC. Does output case preservation refer to something else? All I observe is that tools like dig return the latter when I run 'dig IETF.org'. Maybe an errata is not the right place to ask for clarification but given the name of the RFC, I would expect to find a clear answer to this question in the RFC.

-- verifier note --
After discussion with the RFC author and the errata author, the conclusion is that the RFC isn't wrong but is arguably unclear for some readers.

Errata ID: 7290
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: John Klensin
Date Reported: 2022-12-26
Held for Document Update by: Murray Kucherawy
Date Held: 2023-06-01

Section 5 says:

A scheme has been adopted for "internationalized domain names" and "internationalized labels" as described in [RFC3490, RFC3454, RFC3491, and RFC3492]. It makes most of [UNICODE] available through a separate application level transformation from internationalized domain name to DNS domain name and from DNS domain name to internationalized domain name. Any case insensitivity that internationalized domain names and labels have varies depending on the script and is handled entirely as part of the transformation described in [RFC3454] and [RFC3491], which should be seen for further details.

It should say:

A scheme has been adopted for "internationalized domain name labels" (and "internationalized domain names" (IDNs) more generally) as described in [RFC5890, RFC5891, RFC5893, RFC5894], and documents that update and clarify them. It makes selected [UNICODE] characters and code point sequences available through a separate application level transformation from internationalized domain name to DNS domain name and from DNS domain name to internationalized domain name. Because of ambiguities among possible definitions of case and case relationships once one moves beyond ASCII, the IDNA specifications prohibit characters that could be interpreted as "upper case", making discussions of case insensitivity irrelevant. See the documents cited for further details.

Notes:

In trying to research something else, I reread RFC 4343. It still references IDNA2003 (RFC 3490ff) as the authority for IDNs and says a few things that are misleading, or worse, under IDNA2008. In retrospect, RFC 5890 should have updated 4343 and adjusted the language of its Section 5. The author of 5890 clearly screwed up (i.e., mea culpa) and the WG and broader IETF review, especially by DNS-related groups, did not catch the problem.

The "corrected" text above is merely an example of how this might be remedied. The issue is clearly (at least to me) one to be "held for document update" of either RFC 4343 or 5890 but it seems worth inserting a pointer into the errata list to warn those who might want to look for it.

Errata ID: 5112
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rich Tom
Date Reported: 2017-09-12
Held for Document Update by: Warren Kumari
Date Held: 2017-09-13

Section 3 says:

comparisons on name lookup for DNS queries should be case insensitive

It should say:

comparisons on name lookup for DNS queries must be case insensitive

Notes:

--- Original report ---
Some authoritative DNS servers and/or mitigation devices/software silently drop queries that have uppercase letters in them. Furthermore, the clarification of the case insensitive comparison in the following two sentences after that particular sentence use the term MUST. I suspect some readers of the RFC are reading the word "should" and aren't reading the rest of the paragraph.

---- WK Update ----
The full quote is: "According to the original DNS design decision, comparisons on name
lookup for DNS queries should be case insensitive [STD13]. ", and the title of this (RFC4343) is "Domain Name System (DNS) Case Insensitivity Clarification" -- seeing as the whole point of this document is to clarify the original spec, I think that readers will read the RFC2119 bits.

However, I do agree that this could be better worded, and future updates of this document should probably reword this to make it clearer.

RFC 4345, "Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol", January 2006

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 118
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Harris
Date Reported: 2006-02-07
Held for Document Update by: Sean Turner

Section 7.2 says:

   [MIRONOV]  Mironov, I., "(Not So) Random Shuffles of RC4", Advances
              in Cryptology -- CRYPTO 2002: 22nd Annual International
              Cryptology Conference, August 2002,
              <http://eprint.iacr.org/2002/067.pdf>.

It should say:

   [MIRONOV]  Mironov, I., "(Not So) Random Shuffles of RC4", Advances
              in Cryptology -- CRYPTO 2002: 22nd Annual International
              Cryptology Conference, August 2002, full version at
              <http://crypto.stanford.edu/~mironov/papers/rc4full.pdf>

RFC 4346, "The Transport Layer Security (TLS) Protocol Version 1.1", April 2006

Note: This RFC has been obsoleted by RFC 5246

Note: This RFC has been updated by RFC 4366, RFC 4680, RFC 4681, RFC 5746, RFC 6176, RFC 7465, RFC 7507, RFC 7919

Source of RFC: tls (sec)

Errata ID: 116

Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: David Hopwood
Date Reported: 2006-05-11
Held for Document Update by: Pasi Eronen
Report Text:

Following references should all be to Section 12:

Section 6:
# See Section 11 for IANA Considerations for ContentType values.

Section 7.2.2:
# See Section 11 for IANA Considerations for alert values.

Section 7.4:
# See Section 11 for IANA Considerations for these values.

Section 7.4.4:
# Additional information describing the role of IANA in the allocation
# of ClientCertificateType code points is described in Section 11.

from pending

---

Errata ID: 117
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-05-29
Held for Document Update by: Pasi Eronen
Date Held: 2009-09-25

 

(C2)  imprecise data description for `ciphersuites`

Section 7.4.1.2, on page 37 defines the syntax:

      uint8 CipherSuite[2];    /* Cryptographic suite selector */

According to the specifications given in Section 4.3, vectors
of type CipherSuite strictly must have byte lengths being a
multiple of 2.
This also means that the upper bound for a varaiable-length array
of type CipherSuite should always be a multiple of 2.
Hence, the declaration in Section 7.4.1.2, on top of page 38,

      struct {
          ProtocolVersion client_version;
          Random random;
          SessionID session_id;
          CipherSuite cipher_suites<2..2^16-1>;
          CompressionMethod compression_methods<1..2^8-1>;
      } ClientHello;

should better say:

      struct {
          ProtocolVersion client_version;
          Random random;
          SessionID session_id;
|         CipherSuite cipher_suites<2..2^16-2>;
          CompressionMethod compression_methods<1..2^8-1>;
      } ClientHello;

This issue recurs in Appendix A.4.1 (2nd line from bottom of p.57)
and at various places in other TLS RFCs, in particular in RFC 4347
and RFC 4366 -- see my errata messages for these RFCs.

Historical Note:
  In SSL 2.0, the CipherSuite construct was 3 bytes long.
  Because 3 divides 2^16-1,  <3..2^16-1>  was an appropriate size
  range then.  The issue has been introduced with SSL 3.0.


(C3)  missing Reference

Appendix B, at the bottom of page 66, contains the Glossary item:

   RC2
      A block cipher developed by Ron Rivest at RSA Data Security, Inc.
      [RSADSI] described in [RC2].

There is no such Reference "[RSADSI]" in the Informative References
Section, on pp. 82 ff. -- apparently, it has been prematurely deleted
from RFC 2246.  Perhaps, nothing would be lost when replacing the
above Glossary item by:

   RC2
      A block cipher developed by Ron Rivest described in [RC2].


(C4)  Outdated Normative Reference

RFC 4346 has been jointly published with RFC 4366, which has
obsoleted RFC 3546.
Therefore, it would have been much more consistent to replace,
in the Normative References Section, on page 82, the entry:

   [TLSEXT]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
              and T. Wright, "Transport Layer Security (TLS)
              Extensions", RFC 3546, June 2003.

by:

   [TLSEXT]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
              and T. Wright, "Transport Layer Security (TLS)
|             Extensions", RFC 4366, April 2006.
                               ^^^^^^^^^^^^^^^^

(C5)  unexpected / inappropriate Reference

Page 83 contains the inappropriate Informative Reference:

   [TCP]      Hellstrom, G. and P. Jones, "RTP Payload for Text
              Conversation", RFC 4103, June 2005.

This clearly should be:

|  [TCP]      Postel, J., "Transmission Control Protocol", STD 7,
|             RFC 793, September 1981.

(Cf. the single citation to [TCP], in the first paragraph of Section 1,
on page 4.)


Simple textual issues (errata)
==============================

(E1)  typo

The second paragraph of Section 3 of RFC 4346, on page 6, says:

   This document is not intended to supply any details of service
   definition or of interface definition, although it does cover select
   areas of policy as they are required for the maintenance of solid
   security.

It should perhaps say:

   This document is not intended to supply any details of service
   definition or of interface definition, although it does cover
|  selected areas of policy as they are required for the maintenance of
   solid security.

(E2)  copy-and-paste error (?)

At the bottom of page 11, Section 4.7 of RFC 4346 says:

   In public key encryption, a public key algorithm is used to encrypt
   data in such a way that it can be decrypted only with the matching
   private key.  A public-key-encrypted element is encoded as an opaque
   vector <0..2^16-1>, where the length is specified by the signing
   algorithm and key.

It should say:

   In public key encryption, a public key algorithm is used to encrypt
   data in such a way that it can be decrypted only with the matching
   private key.  A public-key-encrypted element is encoded as an opaque
|  vector <0..2^16-1>, where the length is specified by the encrypting
   algorithm and key.
                                                            ^^^^^^^^^^

(E3)  typo

The beginning of the first paragraph of Section 6.1, on page 15,

   A TLS connection state is the operating environment of the TLS Record
   Protocol.  It specifies a compression algorithm, and encryption
   algorithm, and a MAC algorithm.  In addition, the parameters for

should say (replacing "and" by "an"):

   A TLS connection state is the operating environment of the TLS Record
|  Protocol.  It specifies a compression algorithm, an encryption
   algorithm, and a MAC algorithm.  In addition, the parameters for


(E4)  word twister

Near the bottom of page 15, Section 6.1 says:

   compression algorithm
      An algorithm to be used for data compression.  This specification
      must include all information the algorithm requires compression.

It should perhaps say:

   compression algorithm
      An algorithm to be used for data compression.  This specification
|     must include all information the compression algorithm requires.


(E5)  improper indentation

In Section 7.4.1.1, on page 36, a headline is indented too much;
the text,

         Structure of this message:

             struct { } HelloRequest;

   Note: This message MUST NOT be included ...

should say:

|  Structure of this message:

             struct { } HelloRequest;

   Note: This message MUST NOT be included ...


(E6)  improper line (un)folding and irregular indentation

In Section 7.4.1.2, at the bottom of page 36, the text,

      struct {
         uint32 gmt_unix_time;
         opaque random_bytes[28];
      } Random;

   gmt_unix_time The current time and date in standard UNIX 32-bit
      format (seconds since the midnight starting Jan 1, 1970, GMT,
      ignoring leap seconds) according to the sender's internal clock.
      Clocks are not required to be set correctly by the basic TLS
      Protocol; higher-level or application protocols may define
      additional requirements.

         random_bytes
             28 bytes generated by a secure random number generator.

following the layout style followed in the remainder of the document
should be formatted as:

      struct {
         uint32 gmt_unix_time;
         opaque random_bytes[28];
      } Random;

|  gmt_unix_time
|     The current time and date in standard UNIX 32-bit
      format (seconds since the midnight starting Jan 1, 1970, GMT,
      ignoring leap seconds) according to the sender's internal clock.
      Clocks are not required to be set correctly by the basic TLS
      Protocol; higher-level or application protocols may define
      additional requirements.

|  random_bytes
|     28 bytes generated by a secure random number generator.


(E7)  improper line (un)folding

The last paragraph of Section 7.4.1.3, on page 40,

   compression_method The single compression algorithm selected by the
      server from the list in ClientHello.compression_methods.  For
      resumed sessions this field is the value from the resumed session
      state.

consistently should be formatted as:

|  compression_method
|     The single compression algorithm selected by the server from the
      list in ClientHello.compression_methods.  For resumed sessions
      this field is the value from the resumed session state.


(E8)  improper line (un)folding and irregular indentation

In Section 7.4.7.1, on page 48, the clauses,

      client_version The latest (newest) version supported by the
         client.  This is used to detect version roll-back attacks.
         Upon receiving the premaster secret, the server SHOULD check
         that this value matches the value transmitted by the client in
         the client hello message.

      random
          46 securely-generated random bytes.

consistently should be formatted as:

|     client_version
|        The latest (newest) version supported by the client.  This is
         used to detect version roll-back attacks.  Upon receiving the
         premaster secret, the server SHOULD check that this value
         matches the value transmitted by the client in the client hello
         message.

      random
|        46 securely-generated random bytes.

and subsequently, the clause,

      pre_master_secret
          This random value is generated by the client and is used to
          generate the master secret, as specified in Section 8.1.

should be:

      pre_master_secret
|        This random value is generated by the client and is used to
|        generate the master secret, as specified in Section 8.1.


(E9)  spurious text line

During the removal of the "EXPORT" ciper suites from Appendix C,
a text line from RFC 2246 has been left there inadvertently.
The table, at the bottom of page 68,

      Key
      Exchange
      Algorithm     Description                        Key size limit

      DHE_DSS       Ephemeral DH with DSS signatures   None
      DHE_RSA       Ephemeral DH with RSA signatures   None
      DH_anon       Anonymous DH, no signatures        None
      DH_DSS        DH with DSS-based certificates     None
      DH_RSA        DH with RSA-based certificates     None
|                                                      RSA = none
      NULL          No key exchange                    N/A
      RSA           RSA key exchange                   None

should say:

      Key
      Exchange
      Algorithm     Description                        Key size limit

      DHE_DSS       Ephemeral DH with DSS signatures   None
      DHE_RSA       Ephemeral DH with RSA signatures   None
      DH_anon       Anonymous DH, no signatures        None
      DH_DSS        DH with DSS-based certificates     None
      DH_RSA        DH with RSA-based certificates     None
      NULL          No key exchange                    N/A
      RSA           RSA key exchange                   None


(E10) improper language

During the addition of the third protocol variant, text in Appendix E
has become improper, stiil talking about "both" versions.

The second paragraph of Appendix E, on page 71,

   TLS versions 1.1 and 1.0, and SSL 3.0 are very similar; thus,
   supporting both is easy.  TLS clients who wish [...]
              ^^^^
should say, e.g.:

   TLS versions 1.1 and 1.0, and SSL 3.0 are very similar; thus,
|  supporting all is easy.  TLS clients who wish [...]
              ^^^


(E11) improper line (un)folding

Appendix E.1, near the bottom on page 73, contains the clause:

   challenge The client challenge to the server for the server to
      identify itself is a (nearly) arbitrary-length random.  The TLS
      server will right-justify the challenge data to become the
      ClientHello.random data (padded with leading zeroes, if
      necessary), as specified in this protocol specification.  If the
      length of the challenge is greater than 32 bytes, only the last 32
      bytes are used.  It is legitimate (but not necessary) for a V3
      server to reject a V2 ClientHello that has fewer than 16 bytes of
      challenge data.

This should be formatted as:

|  challenge
|     The client challenge to the server for the server to identify
      itself is a (nearly) arbitrary-length random.  The TLS server will
      right-justify the challenge data to become the ClientHello.random
      data (padded with leading zeroes, if necessary), as specified in
      this protocol specification.  If the length of the challenge is
      greater than 32 bytes, only the last 32 bytes are used.  It is
      legitimate (but not necessary) for a V3 server to reject a V2
      ClientHello that has fewer than 16 bytes of challenge data.



(E12) punctuation issues in References

The following Normative Reference entries on page 81/82 contain
syntactically inconsistent punctuation.

   [AES]      National Institute of Standards and Technology,
              "Specification for the Advanced Encryption Standard (AES)"
              FIPS 197.  November 26, 2001.
should say:
   [AES]      National Institute of Standards and Technology,
              "Specification for the Advanced Encryption Standard
|             (AES)", FIPS 197.  November 26, 2001.
                    ^

   [3DES]     W. Tuchman, "Hellman Presents No Shortcut Solutions To
              DES," IEEE Spectrum, v. 16, n. 7, July 1979, pp. 40-41.
should say:
   [3DES]     W. Tuchman, "Hellman Presents No Shortcut Solutions To
|             DES", IEEE Spectrum, v. 16, n. 7, July 1979, pp. 40-41.
                 ^^

   [DES]      ANSI X3.106, "American National Standard for Information
              Systems-Data Link Encryption," American National Standards
              Institute, 1983.
should say:
   [DES]      ANSI X3.106, "American National Standard for Information
|             Systems-Data Link Encryption", American National Standards
              Institute, 1983.
                                          ^^

   [DSS]      NIST FIPS PUB 186-2, "Digital Signature Standard,"
              National Institute of Standards and Technology, U.S.
              Department of Commerce, 2000.
should say:                                                   vv
|  [DSS]      NIST FIPS PUB 186-2, "Digital Signature Standard",
              National Institute of Standards and Technology, U.S.
              Department of Commerce, 2000.


   [SHA]      NIST FIPS PUB 180-2, "Secure Hash Standard," National
              Institute of Standards and Technology, U.S. Department of
              Commerce., August 2001.
should say:                                             vv
|  [SHA]      NIST FIPS PUB 180-2, "Secure Hash Standard", National
              Institute of Standards and Technology, U.S. Department of
              Commerce., August 2001.


Similarly, the following Informative Reference entry on page 83,

   [RSA]      R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
              Obtaining Digital Signatures and Public-Key
              Cryptosystems," Communications of the ACM, v. 21, n. 2,
              Feb 1978, pp.  120-126.

should say:

   [RSA]      R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
              Obtaining Digital Signatures and Public-Key
|             Cryptosystems", Communications of the ACM, v. 21, n. 2,
              Feb 1978, pp.  120-126.


(E13) mis-spelled author name in Informative Reference

The name of Alan O. Freier has been mis-spelled on page 83, in the
Informative Reference,

   [SSL3]     A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0
              Protocol", Netscape Communications Corp., Nov 18, 1996.

which should say:
                   vv
|  [SSL3]     A. Freier, P. Karlton, and P. Kocher, "The SSL 3.0
              Protocol", Netscape Communications Corp., Nov 18, 1996.

Notes:

(Item C1 split to separate Errata ID 1896)

All excerpts from the RFC text are taken keeping their original
formatting, and modified text is formatted in conformance with
RFC guidelines again.

I use change bars ('|' in column 1) and casual up/down pointing
tags ('^^^' / 'vvv' marks in extra lines) to emphasize the location
of textual issues and/or proposed textual enhancements/corrections.

from pending

RFC 4347, "Datagram Transport Layer Security", April 2006

Note: This RFC has been obsoleted by RFC 6347

Note: This RFC has been updated by RFC 5746, RFC 7507

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 115
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-05-29
Held for Document Update by: Russ Housley

 

(1)  typo

At the top of page 3, Section 1 of RFC 4347 says:

                [...].  Unfortunately, although application layer
   security protocols generally provide superior security properties
   (e.g., end-to-end security in the case of S/MIME), they typically
   requires a large amount of effort to design -- in contrast to the
   relatively small amount of effort required to run the protocol over
   TLS.

It should say:

                [...].  Unfortunately, although application layer
   security protocols generally provide superior security properties
   (e.g., end-to-end security in the case of S/MIME), they typically
|  require a large amount of effort to design -- in contrast to the
   relatively small amount of effort required to run the protocol over
   TLS.


(2)  imprecise data description for `ciphersuites`

This is an issue inherited from RFC 4346 -- see my errata submission
on that RFC.  For convenience, I repeat the details here.

Section 7.4.1.2 of RFC 4346 (on p. 12 of RFC 4346) defines the syntax:

      uint8 CipherSuite[2];    /* Cryptographic suite selector */

According to the specifications given in Section 4.3 of RFC 4346,
vectors of type CipherSuite strictly must have byte lengths being a
multiple of 2.
This also means that the upper bound for a varaiable-length array
of type CipherSuite should always be a multiple of 2.

Hence, the declaration in Section 4.2.1 of RFC 4347, on page 12,

      struct {
        ProtocolVersion client_version;
        Random random;
        SessionID session_id;
        opaque cookie<0..32>;                             // New field
        CipherSuite cipher_suites<2..2^16-1>;
        CompressionMethod compression_methods<1..2^8-1>;
      } ClientHello;

should say:

      struct {
        ProtocolVersion client_version;
        Random random;
        SessionID session_id;
        opaque cookie<0..32>;                             // New field
|       CipherSuite cipher_suites<2..2^16-2>;
        CompressionMethod compression_methods<1..2^8-1>;
      } ClientHello;

This change should be applied to the syntax summary in section 4.3.2,
on mid-page 21, as well.


(3)  missing white space

In Section 4.2.2 of RFC 4347, the lines on top of page 14,

          case hello_verify_request: HelloVerifyRequest;  // New type
          case server_hello:  ServerHello;
          case certificate:Certificate;
          case server_key_exchange: ServerKeyExchange;
          case certificate_request: CertificateRequest;
          case server_hello_done:ServerHelloDone;
          case certificate_verify:  CertificateVerify;
          case client_key_exchange: ClientKeyExchange;
          case finished:Finished;

should say:

          case hello_verify_request: HelloVerifyRequest;  // New type
          case server_hello:         ServerHello;
|         case certificate:          Certificate;
          case server_key_exchange:  ServerKeyExchange;
          case certificate_request:  CertificateRequest;
|         case server_hello_done:    ServerHelloDone;
          case certificate_verify:   CertificateVerify;
          case client_key_exchange:  ClientKeyExchange;
|         case finished:             Finished;

This change should be applied to the syntax summary in section 4.3.2,
on top of page 21, as well.


(4)  copy-and-paste issue (?)

On page 20, the first declaration in Section 4.3.2,

      enum {
        hello_request(0), client_hello(1), server_hello(2),
        hello_verify_request(3),                          // New field
        certificate(11), server_key_exchange (12),
        certificate_request(13), server_hello_done(14),
        certificate_verify(15), client_key_exchange(16),
        finished(20), (255)
      } HandshakeType;

should say, using the appropriate term:

      enum {
        hello_request(0), client_hello(1), server_hello(2),
|       hello_verify_request(3),                          // New value
        certificate(11), server_key_exchange (12),
        certificate_request(13), server_hello_done(14),
        certificate_verify(15), client_key_exchange(16),
        finished(20), (255)
      } HandshakeType;


(5)  Outdated Informative References

RFC 4347 has been published several months after the new IPsec RFCs.
It therefore would have been preferrable to have the following
references updated:

   [AH]   :  RFC 2402  -->  RFC 4302

   [ESP]  :  RFC 2406  -->  RFC 4303

BTW: The Ref. "[AH]" does *not* appear anywhere in the text!

Also, The DCCP RFCs have been published a few weeks before RFC 4347;
therefore, the following Ref. update would have been appropriate:

   [DCCP] :  "Work in Progress"  -->  RFC 4340, March 2006.


(6)  unexpected / inappropriate Reference

Page 23 contains the inappropriate Informative Reference:

   [PHOTURIS] Karn, P. and W. Simpson, "ICMP Security Failures
              Messages", RFC 2521, March 1999.

This clearly should be:

|  [PHOTURIS] Karn, P. and W. Simpson, "Photuris: Session-Key Management
|             Protocol", RFC 2522, March 1999.

(Cf. the citations to [PHOTURIS], in Section 4.2.1, on page 11.)

Notes:

All excerpts from the RFC text are taken keeping their original
formatting, and modified text is formatted in conformance with
RFC guidelines again.

I use change bars ('|' in column 1) and casual up/down pointing
tags ('^^^' / 'vvv' marks in extra lines) to emphasize the location
of textual issues and/or proposed textual enhancements/corrections.

from pending

RFC 4360, "BGP Extended Communities Attribute", February 2006

Note: This RFC has been updated by RFC 7153, RFC 7606

Source of RFC: idr (rtg)

Errata ID: 715
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-02-27
Held for Document Update by: Stewart Bryant
Date Held: 2013-09-19

 

Section 3.1. defines the Extended Community extended type classes
0x00ss and 0x40ss, as does Section 3.2. for the type classes 0x01ss
and 0x41ss, and Section 3.3. for the type classes 0x03ss and 0x43ss
(where 'ss' is the Sub-Type).
These classes are also covered by the IANA Considerations section.

Section 4. and Section 5. of RFC 4360 both define extended types
where "the value of the high-order octet of the Type field ... can
be 0x00, 0x01, or 0x02".
There is no formal definition for the latter case, Type = 0x02ss,
in the whole RFC, and the subtypes 0x0202 and 0x0203 are not covered
by the IANA considerations section.
>From text in Section 4. and 5., it can be concluded, that perhaps
the layout from Section 3.1. should be applicable in this case as
well, but that's all I could find!

Was type 0x02ss deprecated during the evolution of the draft,
or has the definition of that extended type been ommitted
accidentially from the RFC ?

It should say:

[see above]

Notes:

This was addressed by RFC5668.

RFC 4361, "Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)", February 2006

Note: This RFC has been updated by RFC 5494

Source of RFC: dhc (int)

Errata ID: 5424
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2018-07-16
Held for Document Update by: Eric Vyncke
Date Held: 2021-02-08

Section 3 says:

   DHCPv4 clients and servers that are implemented according to this
   document should be implemented as if the changes specified in
   sections 6.3 and 6.4 have been made to RFC 2131 and RFC 2132.  DHCPv4
   clients should, in addition, follow the behavior specified in section
   6.1.  DHCPv6 clients should follow the behavior specified in section
   6.2.  DHCPv4 servers should additionally follow the behavior
   specified in section 6.3.

It should say:

   DHCPv4 clients and servers that are implemented according to this
   document should be implemented as if the changes specified in
   sections 6.4 and 6.5 have been made to RFC 2131 and RFC 2132.  DHCPv4
   clients should, in addition, follow the behavior specified in section
   6.1.  DHCPv6 clients should follow the behavior specified in section
   6.2.  DHCPv4 servers should additionally follow the behavior
   specified in section 6.3.

Notes:

Incorrect links to sections of this document.

-- Verifier note --
The corrected text is indeed correct. As a normal reader will correct the text by herself and the error is not catastrophic, this errata is marked as "help for document update".

Errata ID: 5425
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2018-07-16
Held for Document Update by: Eric Vyncke
Date Held: 2021-02-08

Section 5 says:

   - DHCPv4 servers that do conform to this specification must
     interoperate correctly with DHCPv4 clients that do not conform to
     this specification, except that when configuring such clients,
     behaviors such as those described in section 2 may occur.

It should say:

   - DHCPv4 servers that do conform to this specification must
     interoperate correctly with DHCPv4 clients that do not conform to
     this specification, except that when configuring such clients,
     behaviors such as those described in section 4.2 may occur.

Notes:

Incorrect referenct to section 2.

-- Verifier note --
The original text should indeed refer to section 4.2 but it can be expected that the reader will auto-correct and as the error does not prevent interoperation, this errata is classified as "held for document update".

Errata ID: 5426
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2018-07-16
Held for Document Update by: Eric Vyncke
Date Held: 2021-02-08

Section 6 says:

   Here we specify changes to the behavior of DHCPv4 clients and
   servers.  We also specify changes to the wording in RFC 2131 and RFC
   2132.  DHCPv4 clients, servers, and relay agents that conform to this
   specification must implement RFC 2131 and RFC 2132 with the wording
   changes specified in sections 6.3 and 6.4.

It should say:

   Here we specify changes to the behavior of DHCPv4 clients and
   servers.  We also specify changes to the wording in RFC 2131 and RFC
   2132.  DHCPv4 clients, servers, and relay agents that conform to this
   specification must implement RFC 2131 and RFC 2132 with the wording
   changes specified in sections 6.4 and 6.5.

Notes:

Incorrect references to sections of this document.

-- Verifier note --
The original text should indeed refer to sections 6.4 and 6.5 but it can be expected that the reader will auto-correct and as the error does not prevent interoperation, this errata is classified as "held for document update".

RFC 4364, "BGP/MPLS IP Virtual Private Networks (VPNs)", February 2006

Note: This RFC has been updated by RFC 4577, RFC 4684, RFC 5462

Source of RFC: l3vpn (int)

Errata ID: 113
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-20
Held for Document Update by: ron bonica

 

(1)  Section 1 (Introduction)

The 1st paragraph on page 3 contains the sentence:

                       [...].  The PE routers distribute, to the CE
   routers in a particular VPN, the routes from other the CE routers in
   that VPN.  [...]

It should say:

                       [...].  The PE routers distribute, to the CE
|  routers in a particular VPN, the routes from the other CE routers in
   that VPN.  [...]
                                                ^^^^^^^^^


(2)  Section 3.3 (Populating the VRFs)

The last paragraph of Section 3.3, on mid-page 12, says:

   If an attachment circuit leads to a site which is in multiple VPNs,
   the attachment circuit may still associated with a single VRF, in
   which case the VRF will contain routes from the full set of VPNs of
   which the site is a member.

It should say:
                                   vvvv
   If an attachment circuit leads to a site which is in multiple VPNs,
|  the attachment circuit may still be associated with a single VRF, in
   which case the VRF will contain routes from the full set of VPNs of
   which the site is a member.


(3)  Section 6 (Maintaining Proper Isolation of VPNs)

At the bottom of page 26, and extending to page 27, the text says:

   The first condition ensure that any labeled packets received from
   non-backbone routers have a legitimate and properly assigned label at
<< page break >>
   the top of the label stack.  [...]

It should say:
                             vv
|  The first condition ensures that any labeled packets received from
   non-backbone routers have a legitimate and properly assigned label at
<< page break >>
   the top of the label stack.  [...]


(4)  Section 7 (How PEs Learn Routes from CEs)

The descrition of 'technique #4', on mid-page 28 says:

      4. The PE and CE routers may be BGP peers, and the CE router may
         use BGP (in particular, EBGP to tell the PE router the set of
         address prefixes that are at the CE router's site. (This
         technique can be used in stub VPNs or transit VPNs.)

It should say:
                                    vvv
      4. The PE and CE routers may be BGP peers, and the CE router may
|        use BGP (in particular, EBGP) to tell the PE router the set of
         address prefixes that are at the CE router's site. (This
         technique can be used in stub VPNs or transit VPNs.)


(5)  Section 9 (Carriers' Carriers)

The last paragraph at the bottom of page 31 contains the sentence:

                                                       [...].  All that
   is required is that the external routes be known to whatever routers
   are responsible for putting the label stack on a hitherto unlabeled
   packet and that there be label switched path that leads from those
   routers to their BGP peers at other sites.  [...]

It should say:

                                                       [...].  All that
   is required is that the external routes be known to whatever routers
   are responsible for putting the label stack on a hitherto unlabeled
|  packet and that there be a label switched path that leads from those
   routers to their BGP peers at other sites.  [...]
                           ^^^

Notes:

To facilitate the recognition of the text changes proposed,
I have added change bars ('|') in column 1, and up/down pointing
marker lines ('^^^'/'vvv').

from pending

Errata ID: 7180
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Angély
Date Reported: 2022-10-24
Held for Document Update by: John Scudder
Date Held: 2024-01-12

Section 4.3.4 says:

   Note that this VPN architecture does not require the capability to
   distribute unlabeled VPN-IPv4 addresses.

It should say:

   Note that this VPN architecture does not require the capability to
   distribute unlabeled IPv4 addresses.

Notes:

From my understanding, VPN-IPv4 addresses are necessarily labeled, but IPv4 adresses are not indeed. Section 10 seems to confirm the error by using the correct term: "distribute unlabeled IPv4 addresses to each other."

Additional note from verifier: this was reported as technical, but I have changed it to editorial following the guidelines in https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/ (“Technical errata are expected to be things that would likely cause significant misunderstandings of the technical specification and might result in faulty implementations if they are not corrected. Editorial errata are, as the name implies, editorial - for example, typos, missing commas, etc. Errors in examples will generally be editorial…”) Since the text in question is a “note that” I take the view that it’s similar in character to an example. Furthermore, I don’t think it’s likely the error would result in faulty implementations. Finally, the uncorrected text, while kind of silly, isn’t strictly speaking untrue, so I have chosen “hold for document update“ rather than “verified”.

RFC 4379, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", February 2006

Note: This RFC has been obsoleted by RFC 8029

Note: This RFC has been updated by RFC 5462, RFC 6424, RFC 6425, RFC 6426, RFC 6829, RFC 7506, RFC 7537, RFC 7743

Source of RFC: mpls (rtg)

Errata ID: 742
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Held for Document Update by: Adrian Farrel
Date Held: 2010-01-02

 

(1) [[posted separately.]]

(2)  Section 3.3.1 -- formating error

The second encoding diagram on page 27,

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0
   0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 0| +-+-+-
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1
   0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1 0 1
   0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-+-+-
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1 0 1 0 1
   0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-+-+-+-+-
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1 0 1 0 1 0 1
   0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-+-+-+-+-
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

should say:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


(3)  Section 4.4 -- word omission

On page 35, the RFC text contains the bullet:

   Best-return-code:  contains the return code for the echo reply packet
                      as currently best known.  As algorithm progresses,
                      this code may change depending on the results of
                      further checks that it performs.

It should say:

   Best-return-code:  contains the return code for the echo reply packet
|                     as currently best known.  As the algorithm
                      progresses, this code may change depending on the
                      results of further checks that it performs.


(4)  Section 4.4 -- word omission in pseudo-code comment

On page 38, within the pseudocode comment, the RFC says:

         [...]
         may be greater than Label-stack-depth.  To be consistent with
         the above stack-depths, the bottom is considered to entry 1.
         */

It should say:

         [...]
         may be greater than Label-stack-depth.  To be consistent with
|        the above stack-depths, the bottom is considered to be entry 1.
         */


(5)  Section 4.4 -- wrong internal section reference

The last paragraph of section 4.4 (Step 7.), on page 40, says:

      Send an MPLS echo reply with a Return Code of Best-return-code,
      and a Return Subcode of Best-rtn-subcode.  Include any TLVs
      created during the above process.  The procedures for sending
|     the echo reply are found in subsection 4.4.1.
                                             ^^^^^
It should say:

      Send an MPLS echo reply with a Return Code of Best-return-code,
      and a Return Subcode of Best-rtn-subcode.  Include any TLVs
      created during the above process.  The procedures for sending
|     the echo reply are found in subsection 4.5.


(6)  Section 5.1 -- outdated Normative Reference

On page 43, the tag  [NTP]  points to RFC 2030.
At the time of publication of RFC 4377, RFC 2030 already had been
obsoleted by RFC 4330.
Therefore, the text after  [NTP]  should be replaced by the
rfc-ref.txt entry for RFC 4330.


(7)  Section 6 -- typo

At the end of the second paragraph on page 4, the RFC says:

                                    [...].  However, to provide a
   stronger defense, an implementation MAY also validate the TimeStamp
|  Sent by requiring and exact match on this field.
                       ^

It should say:

                                    [...].  However, to provide a
   stronger defense, an implementation MAY also validate the TimeStamp
|  Sent by requiring an exact match on this field.

Notes:

from pending

Errata ID: 2978
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Zhi Zheng
Date Reported: 2011-09-21
Held for Document Update by: Adrian Farrel

Section 4.4 (p. 36) says:

      Else { 

          Retrieve the associated label operation from the 
          corresponding NLFE and proceed to step 4 (Label Operation 
          check). 

It should say:

      Else { 

          Retrieve the associated label operation from the 
          corresponding NHLFE and proceed to step 4 (Label Operation 
          check). 

Notes:

NLFE -> NHLFE

RFC 4380, "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", February 2006

Note: This RFC has been updated by RFC 5991, RFC 6081

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: tsv

Errata ID: 107
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-16
Held for Document Update by: Wes Eddy

 

(1)  Inconsistency on cryptographic algorithm (MAC) requirements

Within section 5.2.2, on the upper half of page 21, RFC 4380 states:

   To maximize interoperability, this specification defines a default
   algorithm in which the authentication value is computed according the
|  HMAC specification [RFC2104] and the SHA1 function [FIPS-180].
   Clients and servers may agree to use HMAC combined with a different
   function, or to use a different algorithm altogether, such as for
   example AES-XCBC-MAC-96 [RFC3566].

   The default authentication algorithm is based on the HMAC algorithm
   according to the following specifications:

|  - the hash function shall be the SHA1 function [FIPS-180].
   - the secret value shall be the shared secret with which the client
     was configured.

Contrary to that, within Section 7.2.1, in the paragraph extending
from page 39 to page 40, the same RFC says:

   If the shared secret contains sufficient entropy, the attacker would
   have to defeat the one-way function used to compute the
   authentication value.  This specification suggests a default
<<page break>>
|  algorithm combining HMAC and MD5.  If the protection afforded by MD5
   was not deemed sufficient, clients and servers can agree to use a
   different algorithm, e.g., SHA1.

I have been educated repeatedly that Security Considerations in RFCs
contain normative content when describing protocol behaviour.
Therefore, it should not happen that text in Security Considerations
contradicts normative content of other sections of an RFC.

Regarding the well known security issues that make MD5 appear much
weaker than SHA-1, according to contemporary comprehension by the
cryptographic community, the former specification (Section 5.2.2)
seems to be the better choice.
I therefore strongly recommend to publish an Author's Errata Note
for RFC 4380 correcting Section 7.2.1, replacing the snippit above
by text conforming to the rules specified in Section 5.2.2, e.g.:

   If the shared secret contains sufficient entropy, the attacker would
   have to defeat the one-way function used to compute the
|  authentication value.  This specification defines a default algorithm
|  combining HMAC and SHA-1.  Clients and servers can agree to use a
|  different message authentication algorithm, e.g. AES-XCBC-MAC-96.
|  See Section 5.2.2 for details.


(2)  Incomplete IANA Considerations

Section 9 of RFC 4380, on page 50, says:

   This memo documents a request to IANA to allocate a 32-bit Teredo
   IPv6 service prefix, as specified in Section 2.6, and a Teredo IPv4
   multicast address, as specified in Section 2.17.

It should say:

|  On requests documented in this memo, IANA has allocated a 32-bit
|  Teredo IPv6 service prefix, as specified in Section 2.6, a Teredo
|  IPv4 multicast address, as specified in Section 2.17, and a Teredo
|  UDP Port number, as specified in Section 2.7.

Rationale:
As per publication of the RFC, these assignments *have been* performed
by the IANA; I propose modified wording reflecting this fact.
Apparently, an IANA assignment also has been performed on behalf of the
Teredo proposal as documented in Section 2.7; for completeness, this
assignment should be mentioned in the IANA Considerations section as
well.  This will also serve as an easy-to-find "pointer" for readers
looking for the purpose of the assignment found in the IANA registry.


(3)  Various typos

I have found a couple of apparent typos in RFC 4380.  The sub-items
 below are pre-formatted for easy inclusion into an RFC errata note.


(3.1) Section 5.2.2, page 21

The first paragraph on page 21 contains the sentence:

                                           [...].  Before transmission,
   the authentication value is computed according to the specified
   algorithm; on reception, the same algorithm is used to compute a
   target value from the content of the receive packet.  [...]

It should say:

                                           [...].  Before transmission,
   the authentication value is computed according to the specified
   algorithm; on reception, the same algorithm is used to compute a
|  target value from the content of the received packet.  [...]
                                               ^

(3.2) Section 5.2.3, page 23

The second paragraph on page 23 [numbered list item 4)] says:

      [...].  The client SHOULD reply with a unicast Teredo bubble, sent
   to the source IPv4 address and source port of the local discovery
   bubble; the IPv6 source address of the bubble will be set to local
   Teredo IPv6 address; [...]

It should say:

      [...].  The client SHOULD reply with a unicast Teredo bubble, sent
   to the source IPv4 address and source port of the local discovery
|  bubble; the IPv6 source address of the bubble will be set to the local
   Teredo IPv6 address; [...]
                                                                ^^^^

(3.3) Section 5.2.7, page 27

The long paragraph in the middle of page 27 says:

                                              [...].  If the secondary
   qualification fails, the interval determination procedure will not be
   used, and the interval value will remain to the default value, 30
   seconds.  [...]

It should say:

                                              [...].  If the secondary
   qualification fails, the interval determination procedure will not be
|  used, and the interval value will remain at the default value, 30
   seconds.  [...]
                                           ^^^^

(3.4) Section 5.2.9, page 30

The last paragraph of Section 5.2.9 says:

            [...]  The nonce value and the date at which the packet was
   sent will be documented in a provisional peer entry for the IPV6
   destination.  The ICMPv6 packet will then be sent [...]

It should say:

            [...]  The nonce value and the date at which the packet was
|  sent will be documented in a provisional peer entry for the IPv6
   destination.  The ICMPv6 packet will then be sent [...]
                                                               ^^^^

(3.5) Section 7.2, page 39

The last sentence of Section 7.2 says:

      [...]  The attacker may have one of two objectives: it may try to
   deny service to the Teredo client by providing it with an address
   that is in fact unreachable, or it may try to insert itself as a
   relay for all client communications, effectively enabling a variety
   of "man-in-the-middle" attack.

It should say:

      [...]  The attacker may have one of two objectives: it may try to
   deny service to the Teredo client by providing it with an address
   that is in fact unreachable, or it may try to insert itself as a
   relay for all client communications, effectively enabling a variety
|  of "man-in-the-middle" attacks.
                                ^


(4)  Formatting issue

RFC 4380 contains a striking number of spurious blank lines inserted
in the middle of running text, interrupting proper paragraph formating.

Browsing through RFC 4380, I have found such spurious blank lines on
pages 23, 30, 33, 35, 41, 44, and 46.

Notes:

from pending

RFC 4384, "BGP Communities for Data Collection", February 2006

Source of RFC: grow (ops)

Errata ID: 106
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-02-27
Held for Document Update by: Ron Bonica

 

(1)

RFC 4384, in the table legend on page 6, and in Section 6,
at the bottom of page 9, refers to ISO 3166-2 for numeric
country codes.  This is not correct.

ISO 3166-2 specifies codes for *subdivisions* of countries,
e.g. the States of the U.S.A., or the provinces of Canada.

The numeric Country Codes apparently used in RFC 4384 in fact
are defined and maintained as a part of ISO 3166-1 !
That Standard contains 3 tables: 2-character, 3-character,
and numeric Country Codes.  Unfortunately, only the first
table (also used for ccTLDs in the DNS) is made publicly
(online) available by ISO; apparently this has generally
raised the impression that ISO 3166-1 just comprised that
single table.  (This might have been the background for
mentioning ISO 3166-2 in the RFC.)

ISO certainly would appreciate if many people bought the
ISO 3166-2 database when looking for the numeric country
codes, but probably neither ISOC/IETF nor the RFC author
would be participating in such earnings of ISO  :-)

Therefore, I propose to correct this flaw by means of an
RFC Errata Note, as follows:


RFC 4384, on mid-page 6, says:

    <CC> is the 10-bit ISO-3166-2 country code [ISO3166]

Where it should say:

    <CC> is the 10-bit ISO-3166-1 country code [ISO3166]
                               ^^^

Accordingly, the final sentence of Section 6, on page 9,
saying:

                             [...].  Henk Uijterwaal suggested the use
   of the ISO-3166-2 country codes.

should say:

                             [...].  Henk Uijterwaal suggested the use
   of the ISO-3166-1 numeric country codes.
                   ^^^^^^^^^


(2)

According to the explanation in Section 3 (page 5), the <Value>
filed is 16 bit wide, and the last sentence on page 5 in Section 4
emphasized the split format "<AS>:<Value>".  (The references to
<Value> in section 4.1 are consistent with that terminology.)

Therefore, in the table on page 6, the "<AS>:" leaders in the
column titled "Value" are inappropriate.
Perhaps, a 'minimally invasive' correction should modify the
headline, not the table entries:

The headline of the table on page 6,

       Category                                 Value

should say:

       Category                              <AS>:<Value>


(3)

The encoding diagram in section 4.2, on page 9, apparently
contains the concrete sample value, '0x10F2' (from the
immediately preceding example in Section 4.1), where it
probably should contain the abstract notion "<Value>".
The literal encoding as presented is misleading, hence
the following correction seems to be appropriate:

RFC 4384, in section 4.2 on page 9 contains the diagram:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      0x02     |    0x0008     |    Global Administrator       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Global Administrator (cont.)  |           0x10F2              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This diagram should say:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      0x02     |    0x0008     |    Global Administrator       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Global Administrator (cont.)  |           <Value>             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


(4)

RFC 4384 makes a Normative Reference to RFC 1771.
But, almost 3 weeks ahead of the publication of RFC 4384,
RFC 1771 has been obsoleted by RFC 4271.

Has this obsolete reference been made intentionally (I cannot
see any immediate reason for doing so) -- or is it just an
editorial oversight?

Notes:

from pending

RFC 4388, "Dynamic Host Configuration Protocol (DHCP) Leasequery", February 2006

Note: This RFC has been updated by RFC 6148

Source of RFC: dhc (int)

Errata ID: 104
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-02
Held for Document Update by: Ralph Droms
Date Held: 2013-03-09

Section 4.2 says:

(1)  [word omission]

The second paragraph of section 4.2 of RFC 4388 says:

   The DHCP Server MIB effort [DHCPMIB] grew out of traffic engineering
   and troubleshooting activities at large DHCP installations, and is
   primarily intended as a method of gathering performance statistics
   about servers the load presented to them.

It should perhaps better say:

   The DHCP Server MIB effort [DHCPMIB] grew out of traffic engineering
   and troubleshooting activities at large DHCP installations, and is
   primarily intended as a method of gathering performance statistics
|  about servers and the load presented to them.
                ^^^^^


(2)  [improper wording]

RFC 4388 repeatedly talks about

   "[an] IP address most recently accessed by a client"
                                  ^^^^^^^^^^^
where, IMHO, it should talk about

|  "[an] IP address most recently assigned to a client"
                                  ^^^^^^^^^^^
Rationale:
  The client may access any IP address at any time.  Such access
  is mostly unrelated to the protocol described in RFC 4338.

The affected places in the text I found are:
- Section 5, first paragraph of both the second and the third
  bulleted items, on page 10 / 11, respectively;
- Last paragraph on page 17 (within section 6.4.1).


(3)  [incomplete specification]

The second paragraph of Section 6.4.1, on page 17, says:

   In the event that an IP address appears in the "ciaddr" field of a
   DHCPLEASEQUERY message, if that IP address is one managed by the DHCP
   server, then that IP address MUST be set in the "ciaddr" field of a
   DHCPLEASEUNASSIGNED message.

It should in fact say:

   In the event that an IP address appears in the "ciaddr" field of a
   DHCPLEASEQUERY message, if that IP address is one managed by the DHCP
   server, then that IP address MUST be set in the "ciaddr" field of a
|  DHCPRELEASEACTIVE or DHCPLEASEUNASSIGNED message returned.
   ^^^^^^^^^^^^^^^^^^^^^                           ^^^^^^^^^

Rationale:
  From the remaining text, it can be inferred that the "ciaddr"
  field from the DHCPLEASEQUERY message should be copied to an
  DHCPRELEASEACTIVE reply message as well -- cf. section 6.4.2.

IMHO, this copy should be performed generally, i.e. also in the case
described by the subsequent paragraph:

   If the IP address is not managed by the DHCP server, then a
   DHCPLEASEUNKNOWN message must be returned.

that therefore might be amended to say:

   If the IP address is not managed by the DHCP server, then a
|  DHCPLEASEUNKNOWN message MUST be returned, with that IP address
|  set in the "ciaddr" field.

[The original 'must' should be a 'MUST' because the alternatives
are also specified as a 'MUST' -- or else the specification would
be incomplete.]

Taken together, it might be preferable to restate this fact by
only changing the first paragraph cited above as follows, and leave
the second paragraph unchanged with the exception of the 'must':

   In the event that an IP address appears in the "ciaddr" field of a
|  DHCPLEASEQUERY message, then that IP address MUST be set in the
|  "ciaddr" field of any reply returned.

|  If that IP address is one managed by the DHCP server, then it MUST
|  reply with a DHCPRELEASEACTIVE or DHCPLEASEUNASSIGNED message.

   If the IP address is not managed by the DHCP server, then a
|  DHCPLEASEUNKNOWN message MUST be returned.

Please comment on which alternative you prefer.

Notes:

This errata has been split to 3517 and 3518.

Verified status applies only to item (1).

Errata ID: 3517
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-02
Held for Document Update by: Ralph Droms
Date Held: 2013-03-09

Section 6.4.1 says:

(1)  [word omission]

The second paragraph of section 4.2 of RFC 4388 says:

   The DHCP Server MIB effort [DHCPMIB] grew out of traffic engineering
   and troubleshooting activities at large DHCP installations, and is
   primarily intended as a method of gathering performance statistics
   about servers the load presented to them.

It should perhaps better say:

   The DHCP Server MIB effort [DHCPMIB] grew out of traffic engineering
   and troubleshooting activities at large DHCP installations, and is
   primarily intended as a method of gathering performance statistics
|  about servers and the load presented to them.
                ^^^^^


(2)  [improper wording]

RFC 4388 repeatedly talks about

   "[an] IP address most recently accessed by a client"
                                  ^^^^^^^^^^^
where, IMHO, it should talk about

|  "[an] IP address most recently assigned to a client"
                                  ^^^^^^^^^^^
Rationale:
  The client may access any IP address at any time.  Such access
  is mostly unrelated to the protocol described in RFC 4338.

The affected places in the text I found are:
- Section 5, first paragraph of both the second and the third
  bulleted items, on page 10 / 11, respectively;
- Last paragraph on page 17 (within section 6.4.1).


(3)  [incomplete specification]

The second paragraph of Section 6.4.1, on page 17, says:

   In the event that an IP address appears in the "ciaddr" field of a
   DHCPLEASEQUERY message, if that IP address is one managed by the DHCP
   server, then that IP address MUST be set in the "ciaddr" field of a
   DHCPLEASEUNASSIGNED message.

It should in fact say:

   In the event that an IP address appears in the "ciaddr" field of a
   DHCPLEASEQUERY message, if that IP address is one managed by the DHCP
   server, then that IP address MUST be set in the "ciaddr" field of a
|  DHCPRELEASEACTIVE or DHCPLEASEUNASSIGNED message returned.
   ^^^^^^^^^^^^^^^^^^^^^                           ^^^^^^^^^

Rationale:
  From the remaining text, it can be inferred that the "ciaddr"
  field from the DHCPLEASEQUERY message should be copied to an
  DHCPRELEASEACTIVE reply message as well -- cf. section 6.4.2.

IMHO, this copy should be performed generally, i.e. also in the case
described by the subsequent paragraph:

   If the IP address is not managed by the DHCP server, then a
   DHCPLEASEUNKNOWN message must be returned.

that therefore might be amended to say:

   If the IP address is not managed by the DHCP server, then a
|  DHCPLEASEUNKNOWN message MUST be returned, with that IP address
|  set in the "ciaddr" field.

[The original 'must' should be a 'MUST' because the alternatives
are also specified as a 'MUST' -- or else the specification would
be incomplete.]

Taken together, it might be preferable to restate this fact by
only changing the first paragraph cited above as follows, and leave
the second paragraph unchanged with the exception of the 'must':

   In the event that an IP address appears in the "ciaddr" field of a
|  DHCPLEASEQUERY message, then that IP address MUST be set in the
|  "ciaddr" field of any reply returned.

|  If that IP address is one managed by the DHCP server, then it MUST
|  reply with a DHCPRELEASEACTIVE or DHCPLEASEUNASSIGNED message.

   If the IP address is not managed by the DHCP server, then a
|  DHCPLEASEUNKNOWN message MUST be returned.

Please comment on which alternative you prefer.

It should say:

(2)  [improper wording]

RFC 4388 repeatedly talks about

   "[an] IP address most recently accessed by a client"
                                  ^^^^^^^^^^^
where, IMHO, it should talk about

|  "[an] IP address most recently assigned to a client"
                                  ^^^^^^^^^^^
Rationale:
  The client may access any IP address at any time.  Such access
  is mostly unrelated to the protocol described in RFC 4338.

The affected places in the text I found are:
- Section 5, first paragraph of both the second and the third
  bulleted items, on page 10 / 11, respectively;
- Last paragraph on page 17 (within section 6.4.1).

Notes:

Split from errata 104

RFC 4389, "Neighbor Discovery Proxies (ND Proxy)", April 2006

Source of RFC: ipv6 (int)

Errata ID: 103
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-04-18
Held for Document Update by: Brian Haberman

 

(1)  typo??

The last paragraph of section 5 of RFC 4389, on page 12, says:

   A receives this NA, processing it as usual.  Hence it creates a
   neighbor entry for B on interface 2 in the REACHABLE state and
   records the link-layer address p1.

Since the packet described has been sent out by node P, on its
interface '1', to node A, and A has only a single interface
involved in the scenarion, with link layer address 'a' (as explained
at the beginning of section 5), "on interface 2" is improper in the
snippit above.  (This may be the result of incomplete adaptation
after a copy-and-paste operation.)  A minimal correction to resolve
this issue might be to name the receive interface by its link layer
address, hence changing the text above to say:

   A receives this NA, processing it as usual.  Hence it creates a
   neighbor entry for B on interface 'a' in the REACHABLE state and
   records the link-layer address p1.

or alternatively, more detailed:

   A receives this NA, processing it as usual.  Hence it creates a
   neighbor entry for B on the interface with link layer address 'a'
   in the REACHABLE state and records the link-layer address p1.


(2)  typo!

The 3rd paragraph of Section 9, on page 13, says:

   This document does not introduce any new mechanisms for the
   protection of proxy Neighbor Discovery.  That is, it does not provide
   a mechanism from authorizing certain devices to act as proxies, and
   it does not provide extensions to SEND to make it possible to use
   both SEND and proxies at the same time.  [...]

It should perhaps better say ( applying 's/from/for/' ) :

   This document does not introduce any new mechanisms for the
   protection of proxy Neighbor Discovery.  That is, it does not provide
|  a mechanism for authorizing certain devices to act as proxies, and
   it does not provide extensions to SEND to make it possible to use
   both SEND and proxies at the same time.  [...]


(3)  outdated reference

In Section 11, Normative References, RFC 4389 contains the entry
(on page 14) [ICMPv6], pointing to RFC 2463.
But exactly 3 weeks before RFC 4389, RFC 4443 has been published
obsoleting and replacing RFC 2463.  Hence that entry should have
been updated to properly point to RFC 4443 instead.


If you agree with my 'diagnosis', I recommend that you submit an
Author's Errata Note for RFC 4389 covering the three issues
listed above.  But if you prefer, I can instead submit an Errata
Note on my own, with your consent mailed to the RFC-Editor.

Notes:

from pending

RFC 4398, "Storing Certificates in the Domain Name System (DNS)", March 2006

Note: This RFC has been updated by RFC 6944

Source of RFC: dnsext (int)

Errata ID: 2460
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Paul Freeman
Date Reported: 2010-08-07
Held for Document Update by: Brian Haberman

Section 2 says:

2.  The CERT Resource Record

   The CERT resource record (RR) has the structure given below.  Its RR
   type code is 37.

                       1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             type              |             key tag           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   algorithm   |                                               /
   +---------------+            certificate or CRL                 /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|

It should say:

2.  The CERT Resource Record

   The CERT resource record (RR) has the structure given below.  Its RR
   type code is 37.

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             type              |             key tag           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   algorithm   |                                               /
   +---------------+            certificate or CRL                 /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|

Notes:

In Section 2 (The CERT Resource Record) the table describing the wire format of the CERT RR is misaligned in such a way that it could lead to technical ambiguity of field positions within the packet structure.

RFC 4407, "Purported Responsible Address in E-Mail Messages", April 2006

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 100
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-05-16
Held for Document Update by: Alexey Melnikov

 

(1)
On page 3 of RFC 4407, the third paragraph,

   Note that the results of this algorithm are only as truthful as the
   headers contained in the message; if a message contains fraudulent or
   incorrect headers, this algorithm will yield an incorrect result.
   [...]

should say:

   Note that the results of this algorithm are only as truthful as the
|  header fields contained in the message; if a message contains
|  fraudulent or incorrect header fields, this algorithm will yield an
   incorrect result.
   [...]


(2)
On page 3, the first sentence in Section 2,

   The PRA of a message is determined by the following algorithm:

should say more precisely:

   The PRA of a message is determined by the following algorithm,
   applied to the message header (i.e., the first mail header within
   the message, in case of a MIME message):


(3)
Subsequently, within the description of the six steps of the
algorithm (on page 3/4), the term `header` should always be replaced
by `header field`, and `headers` should always be replaced by
`header fields` (total of 16 occurrences).


(4)
On page 4 (just below the emumerated algorithm steps), the paragraph,

   For the purposes of this algorithm, a header field is "non-empty" if
   and only if it contains any non-whitespace characters.  Header fields
   that are otherwise relevant but contain only whitespace are ignored
   and treated as if they were not present.

should say:

   For the purposes of this algorithm, a header field is "non-empty" if
|  and only if its body contains any non-whitespace characters.  Header
|  fields that are otherwise relevant but contain only whitespace bodies
   are ignored and treated as if they were not present.

(5)
Immediately following the paragraph mentioned above in item (4), still
on page 4, the substitutions from item (3) above should be applied to
the next two paragraphs and the last paragraph of Section 2 as well
(total of 8 occurrences).


(6)
On page 5, the first paragraph of section 3,

   The PRA, as described by this document, is extracted from message
   headers that have historically not been verified.  Thus, anyone using
   the PRA for any purpose MUST be aware that the headers from which it
   is derived might be fraudulent, malicious, malformed, and/or
   incorrect.  [...]

should say (apply item (3) above twice):

   The PRA, as described by this document, is extracted from message
|  header fields that have historically not been verified.  Thus, anyone
|  using the PRA for any purpose MUST be aware that the header fields
   from which it is derived might be fraudulent, malicious, malformed,
   and/or incorrect.  [...]

and the second paragraph of Section 3,

   A message's PRA will often be extracted from a header field that is
   not normally displayed by existing mail user agent software.  If the
   PRA is used as part of a mechanism to authenticate the message's
   origin, the message SHOULD NOT be displayed with an indication of its
   authenticity (positive or negative) without the PRA header field also
   being displayed.

should say:

   A message's PRA will often be extracted from a header field that is
   not normally displayed by existing mail user agent software.  If the
   PRA is used as part of a mechanism to authenticate the message's
   origin, the message SHOULD NOT be displayed with an indication of its
|  authenticity (positive or negative) without the PRA header field body
   also being displayed.

Notes:

The RFC adds to the trouble of mis-used
terminology from the Internet Message Format (IMF) framework;
it repeatedly confuses the precisely defined terms, 'header',
'header field', and 'header field body'.

The most recent summary of the IETF standardized IMF terminology
(from RFC 2822 et al.) can be found on page 3 of RFC 4249:


3.1.1. Standard Terminology

Terms related to the Internet Message Format are defined in
[N2.RFC2822]. Authors specifying extension header fields should use
the same terms in the same manner in order to provide clarity and
* avoid confusion. For example, a "header" [I1.FYI18], [N2.RFC2822] is
* comprised of "header fields", each of which has a "field name" and
* usually has a "field body". Each message may have multiple
* "headers", viz. a message header and MIME-part [N4.RFC2046] headers.

* A message header has a Date header field (i.e., a field with field
* name "Date"). However, there is no "Date header"; use of such non-
* standard terms is likely to lead to confusion, possibly resulting in
* interoperability failures of implementations.


For details, see Sections 2.1 and 2.2 of RFC 2822 and other places.
I also recommend the terminology sections in RFC 4021 and RFC 3864.

from pending

RFC 4408, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1", April 2006

Note: This RFC has been obsoleted by RFC 7208

Note: This RFC has been updated by RFC 6652

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 994
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Frank Ellermann
Date Reported: 2007-11-06
Held for Document Update by: Alexey Melnikov
Date Held: 2010-07-01

 

See this page for discussion of errata for RFC 4408:
<http://www.openspf.org/RFC_4408/Errata>

Notes:

Alexey: if there is interest in revising the document, then it should be updated to incorporate some changes suggested on the above web page.

Errata ID: 99
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Wayne Schlitt
Date Reported: 2006-05-16
Held for Document Update by: Alexey Melnikov
Date Held: 2010-05-11

 

1) On page 1, in the IESG notes, "aParticipants" should be
   "Participants".

2) On page 40, the US-ASCII normative reference has an incorrectly
   indented second paragraph.  Instead of:

   [US-ASCII] American National Standards Institute (formerly United
              States of America Standards Institute), "USA Code for
              Information Interchange, X3.4", 1968.

   ANSI X3.4-1968 has been replaced by newer versions with slight
              modifications, but the 1968 version remains definitive for
              the Internet.

   it should be:

   [US-ASCII] American National Standards Institute (formerly United
              States of America Standards Institute), "USA Code for
              Information Interchange, X3.4", 1968.

              ANSI X3.4-1968 has been replaced by newer versions with
              slight modifications, but the 1968 version remains
              definitive for the Internet.

RFC 4409, "Message Submission for Mail", April 2006

Note: This RFC has been obsoleted by RFC 6409

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 2393
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-05-16
Held for Document Update by: Peter Saint-Andre
Date Held: 2010-07-24

Section 7 says:

The list of SMTP extensions provided on page 10 of RFC 4409
unfortunately is incomplete.  As far as I can see, the following
RFCs with SMTP extensions predate the publication of RFC 4409:

  o  RFC 2645  -- ATRN
  o  RFC 2852  -- DELIVERBY
  o  RFC 3865 (+ RFC 4095)  -- NO-SOLICITING
  o  RFC 4141  -- CONPERM, CONNEG
[ o  RFC 4405 ]

Notes:

Quickly browsing these RFCs, I found that only RFC 4405 has
followed the specification in Section 7 of RFC 2476 (literally
carried over to RFC 4409):

Future SMTP extensions SHOULD explicitly specify if they are valid on
the Submission port.

and contains a definitive statement to this end.
RFC 4405 therefore arguably might be excluded from the list.

It would have been useful to have a complete list, with the
proper applicability keywords for the above SMTP extensions.

Errata ID: 98
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-05-16
Held for Document Update by: Peter Saint-Andre
Date Held: 2010-07-24

 

Issues with References:

a) Section 12 of RFC 4409 contains the entry:

   [ESMTP]           Klensin, J., Freed, N., Rose, M., Stefferud, E.,
                     and D. Crocker, "SMTP Service Extensions", STD 10,
                     RFC 1869, November 1995.

   `STD 10` in fact should be `(ex) STD 10` according to rfcxx00.txt .
   The material from RFC 1869 has been incorporated into RFC 2821,
   and RFC 1869 has been reclassified to Historic.

   Therefore, this reference should not have been listed as a
   Normative Reference.  The Ref. to RFC 2821 in fact catches all.


   Section 12 of RFC 4409, under [SMTP-MTA] also contains the entry:

                     Partridge, C., "Mail routing and the domain
                     system", STD 10, RFC 974, January 1986.

   `STD 10` in fact should better have been `(ex) STD 14` --
   rfcxx00.txt says: "Now Historic."                  ^^

   The non-obsolete material from RFC 974 has been incorporated
   into RFC 2821 and RFC 974 has been reclassified as Historic.

   Therefore, this reference should not have been listed as a
   Normative Reference.  The Ref. to RFC 2821 in fact catches all.


   Finally, the subsequent entry,

                     Braden, R., "Requirements for Internet Hosts -
                     Application and Support", STD 3, RFC 1123, October
                     1989.

   also is not needed any more, because the SMTP related material
   in RFC 1123 has been revised and incorporated into RFC 2821
   as well.  The Ref. to RFC 2821 in fact catches all.


b) Section 13 of RFC 4409, under [MESSAGE-FORMAT] contains the entry:

                     Braden, R., "Requirements for Internet Hosts -
                     Application and Support", STD 3, RFC 1123, October
                     1989.

   Similarly to the last item above, the IMF related material from
   RFC 1233 has been revised and incorporated into RFC 2822; thus
   this Ref. is not really needed any more.
   The Ref. to RFC 2822 in fact catches all.


c) Section 13 of RFC 4409 contains the entry:

   [IPSEC]           Kent, S. and R. Atkinson, "Security Architecture
                     for the Internet Protocol", RFC 2401, November
                     1998.

   This Ref. was already outdated at the time of publication of
   RFC 4409; it should point to the current IPSEC Architecture
   document, RFC 4301 !

   BTW:
   This apparently is a `viral` legacy issue -- RFC 2476 also
   contained an outdated Ref., to the predecessor of RFC 2401 !

RFC 4410, "Selectively Reliable Multicast Protocol (SRMP)", February 2006

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: tsv

Errata ID: 97
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-14
Held for Document Update by: Wes Eddy

 

(1)  [contradiction in specification]

The last paragraph of Section 2, on page 6 of RFC 4410, says:

   SRMP is intended for general use under applications that need its
                             vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
|  services and may exist in parallel instances on the same host.  The
   UDP port is therefore established ad hoc from available application
   ports; accordingly, it would not be appropriate to have a well-known
   port for SRMP.

Contrary to that, the first paragraph of Section 4.7, on page 15,
says:
   vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
|  Each host will have a single instance of SRMP supporting all of its
   applications.  Thus, the sender's source rate is the sum of the rates
   of all the clients of the same multicast group.

What's true ?   What's been intended ???


(2)  [simple erratum: inconsistent spelling]

At the bottom of page 7, Section 3.2 says:

   Receiver_Timestamp:
|     16 bits   Echo of the Receiver_Time_Stamp field (in milliseconds)
                of the receiver feedback message.  If the sender has
                time delay between receiving the feedback and echoing
                the timestamp, it MUST adjust the Receiver_Timestamp
                value to compensate.

To adjust with the diagram on top of page 7 and the remainder of the
text, 'Receiver_Time_Stamp' should be spelled out 'Receiver_Timestamp'
here as well.
Thus, the RFC should say:

   Receiver_Timestamp:
|     16 bits   Echo of the Receiver_Timestamp field (in milliseconds)
                of the receiver feedback message.  If the sender has
                time delay between receiving the feedback and echoing
                the timestamp, it MUST adjust the Receiver_Timestamp
                value to compensate.


(3)  [inconsistent message layout - danger of interoperability problems]

The diagram of the Bundle Header Format (Section 3.2, on page 7),

      0              8              16             24             32
      +--------------+--------------+--------------+--------------+
      |Version| Type |fb_nr | flag  |        bundle_SN            |
      +--------------+--------------+--------------+--------------+
      |                       Sender_ID                           |
      +--------------+--------------+--------------+--------------+
      |                       Receiver_ID                         |
      +--------------+--------------+--------------+--------------+
      |       Sender_Timestamp      |    Receiver_Timestamp       |
      +--------------+--------------+--------------+--------------+
      |            ...                                            |


and the diagram of the Feedback Message Format (Section 3.3, on page 9),

      0              8              16             24             32
      +--------------+--------------+--------------+--------------+
      |Version| Type | fb_nr| flag  |             X_r             |
      +--------------+--------------+--------------+--------------+
      |       Sender_Timestamp      |    Receiver_Timestamp       |
      +--------------+--------------+--------------+--------------+
      |                       Sender_ID                           |
      +--------------+--------------+--------------+--------------+
      |                      Receiver_ID                          |
      +--------------+--------------+--------------+--------------+

show a surprising inconsistency in the order of the (otherwise
comparable) words {Sender_ID, Receiver_ID, S/R_Timestamps} .
I suspect that this might give rise to implementation faults,
leading to interoperability problems.
It better would have been avoided from the beginning by using
the same order of the fields.

BTW: It strikes that in Section 3.2, the sequence of the field
explanations does not agree with the order in the diagram (as is
the case throughout the remainder of the RFC); instead, the
explanations of just those four fields is given in the order
of the diagram and explanation sequence in Section 3.3.
Therefore, the reader could be lead to the conjecture that the
diagram in Section 3.2 is in error and in fact should be aligned
with the diagram in Section 3.3.


(4)  [simple erratum: word twister]

In Section 3.6, near the top of page 12, the RFC says:

   Length:
      16 bits  Length of the payload data in octets (does not the
               include header).

It should say:

   Length:
|     16 bits  Length of the payload data in octets (does not include
|              the header).


(5)  [simple errata: inconsistent terminology]

Contrary to the remainder of the RFC text, Section 3.7 uses the
field name "Sender Address".  To avoid the unfortunate embedded
space character, and to align this section with the remainder
of the RFC, the term "Sender_ID" should be used.
Therefore:

a) the diagram on page 12,

      0              8              16             24             32
      +--------------+--------------+--------------+--------------+
      |Version| Type |111 |  00000  |          reserved           |
      +--------------+--------------+--------------+--------------+
      |                            DSN                            |
      +--------------+--------------+--------------+--------------+
|     |                      Sender Address                       |
      +--------------+--------------+--------------+--------------+

should be corrected to say:

      0              8              16             24             32
      +--------------+--------------+--------------+--------------+
      |Version| Type |111 |  00000  |          reserved           |
      +--------------+--------------+--------------+--------------+
      |                            DSN                            |
      +--------------+--------------+--------------+--------------+
|     |                         Sender_ID                         |
      +--------------+--------------+--------------+--------------+

b) the explanation (at the bottom of page 12),

|  Sender_ID:
|     The IP address of the sender of the message being NACKed.

should be corrected to say:

|  Sender_ID:
|     The ID of the sender of the message being NACKed.

See also item (6) below for the full rationale.


(6)  [incomplete specification - IPv4-centric]

In Section 4.2, the second paragraph on page 14 says:

   Also, the bundle length MUST NOT exceed LENGTH_MAX.  If adding a new
   SRMP message will produce a greater length, the SRMP daemon MUST
   initialize a new bundle for the new SRMP messages, and the current
|  bundle should be transmitted immediately.  The recommended value for
|  LENGTH_MAX is 1454 bytes (Ethernet MTU minus IP and UDP header
|  lengths).

Similarly, the first paragraph of Section 4.6, on page 15, says:

   TFMCC is designed for traffic with a fixed message size.  The maximum
|  bundle size (including header) for SRMP is set to a configurable
|  maximum, typically 1454 bytes (Ethernet MTU minus IP and UDP header
|  lengths).  The bundle size will be used in a TCP throughput equation,
   to get a desired source rate.  However, in SRMP, the message size is
   variable because:

Without mention, the marked phrases are strictly IPv4-centric;
they do not apply to the case of IPv6.

The latter scenario is not excluded in the text, and the phrase,
"IPv4 addresses may be used." in the description of all Sender_ID
and Receiver_ID fields supports the suspicion that IPv6 in fact
was intended to be supported.

Please supply improved wording for both text fragments.


(7)  [simple erratum: grammar (singular/plural mismatch)]

The first paragraph of Section 5, on page 17, says:

   SRMP operates in three distinct transmission modes in order to
   deliver varying levels of reliability: Mode 0 for multicast data that
|  does not require reliable transmission, Mode 1 for data that must be
   received reliably by all members of a multicast group, and Mode 2 for
   data that must be received reliably by a single dynamically
   determined member of a multicast group.

It should say:

   SRMP operates in three distinct transmission modes in order to
   deliver varying levels of reliability: Mode 0 for multicast data that
|  do not require reliable transmission, Mode 1 for data that must be
   received reliably by all members of a multicast group, and Mode 2 for
   data that must be received reliably by a single dynamically
   determined member of a multicast group.

Rationale: "data" *is" plural.

Notes:

from pending

RFC 4423, "Host Identity Protocol (HIP) Architecture", May 2006

Note: This RFC has been obsoleted by RFC 9063

Source of RFC: hip (int)

Errata ID: 4320
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Hoffman
Date Reported: 2015-03-31
Held for Document Update by: Terry Manderson
Date Held: 2015-03-31

Section 3.1 says:

   | pair         | public and private keys.  For example,             |
   |              | Rivest-Shamir-Adelman (RSA) and Digital Signature  |
   |              | Algorithm (DSA) key pairs are such key pairs.      |

It should say:

   | pair         | public and private keys.  For example,             |
   |              | Rivest-Shamir-Adleman (RSA) and Digital Signature  |
   |              | Algorithm (DSA) key pairs are such key pairs.      |

Notes:

Misspelling of one of the inventors' names.

RFC 4425, "RTP Payload Format for Video Codec 1 (VC-1)", February 2006

Source of RFC: avt (rai)

Errata ID: 96
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-06
Held for Document Update by: Robert Sparks

Informative References say:

   [14] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg,
        "SIP: Session Initiation Protocol", RFC 2543, March 1999.

It should say:

   [14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., 
        Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation 
        Protocol", RFC 3261, June 2002.

Notes:

Informative reference points to RFC 2543, but this has been outdated by RFC 3261.
RFC 4425 gives an Informative Reference [14] to the SIP
specification, used only once, in section 4.7; but the
citation in section 10.2 points to the far outdated RFC 2543
that has been superseded by RFC 3261 on Jul 2 2002.
Because this obsolescence has happened so long ago, I have
conjectured that it must have been ignored purposely following
subtle considerations, and it is not an editorial oversight.

RFC 4427, "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", March 2006

Source of RFC: ccamp (rtg)

Errata ID: 1834
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vishwas Manral
Date Reported: 2009-08-20
Held for Document Update by: Adrian Farrel
Date Held: 2009-08-24

Section 4.6 says:

   E. M:N (M, N > 1, N >= M) type:

   A set of M specific recovery LSPs/spans protects a set of up to N
   specific working LSPs/spans.  The two sets are explicitly identified.
   Extra traffic can be transported over the M recovery LSPs/spans when
   available.  All the LSPs/spans must start and end at the same nodes.

It should say:

   E. M:N (M, N > 1, N >= M > 1) type:

   A set of M specific recovery LSPs/spans protects a set of up to N
   specific working LSPs/spans.  The two sets are explicitly identified.
   Extra traffic can be transported over the M recovery LSPs/spans when
   available.  All the LSPs/spans must start and end at the same nodes.

Notes:

M > 1 is not specified

[Adrian Farrel]
M > 1 was intended by the language "M, N > 1"
This has been confused by the othe use of a comma

Errata ID: 1835
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vishwas Manral
Date Reported: 2009-08-20
Held for Document Update by: Adrian Farrel
Date Held: 2009-08-24

Section 6.3 says:

6.3. M:N (M, N > 1, N >= M) Protection


   M:N protection has N working LSPs/spans carrying normal traffic and M
   protection LSP/span that may carry extra-traffic.

It should say:

6.3. M:N (M, N > 1, N >= M > 1) Protection


   M:N protection has N working LSPs/spans carrying normal traffic and M
   protection LSP/span that may carry extra-traffic.

Notes:

M > 1 is added

[Adrian Farrel]
M > 1 was intended by the language "M, N > 1"
This has been confused by the other use of a comma

RFC 4429, "Optimistic Duplicate Address Detection (DAD) for IPv6", April 2006

Note: This RFC has been updated by RFC 7527

Source of RFC: ipv6 (int)

Errata ID: 1625
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Shiang-Ming Huang
Date Reported: 2008-12-03
Held for Document Update by: Jari Arkko
Date Held: 2008-12-03

Section 2.1 says:

   [RFC2462] introduces the concept of Tentative (in 5.4) and Deprecated
 | (in 5.5.4) addresses.  Addresses that are neither are said to be
   Preferred.  Tentative addresses may not be used for communication,
   and Deprecated addresses should not be used for new communications.
   These address states may also be used by other standards documents,
   for example, Default Address Selection [RFC3484].

It should say:

   [RFC2462] introduces the concept of Tentative (in 5.4) and Deprecated
 | (in 5.5.4) addresses.  Addresses that are neither Tentative nor Deprecated are said to be
   Preferred.  Tentative addresses may not be used for communication,
   and Deprecated addresses should not be used for new communications.
   These address states may also be used by other standards documents,
   for example, Default Address Selection [RFC3484].

RFC 4430, "Kerberized Internet Negotiation of Keys (KINK)", March 2006

Source of RFC: kink (sec)

Errata ID: 93
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-06
Held for Document Update by: Pasi Eronen
Date Held: 2009-04-30

 

[editorial nits moved to errata ID 1770]

(7)  Section 4.2.7 (page 22/23)

(7a) Item (1b) above applies, and plaintext vs. ciphertext is unclear.

The initial text and Figure 13 unfortunately do not properly make
the distinction between unencrypted (plaintext) and encrypted
(ciphertext) values and fields.
The presentation on page 22 needs clarification, according to the
note given on page 23:

   The coverage of the encrypted data begins at InnerNextPload so that
   the first payload's type is kept confidential.  Thus, the number of
   encrypted octets is PayloadLength - 4.

On page 22, the text and Figure 13,

|  The KINK_ENCRYPT payload encapsulates other KINK payloads and is
|  encrypted using the session key and the algorithm specified by its
   etype.  This payload MUST be the final one in the outer payload chain
|  of the message.  The KINK_ENCRYPT payload MUST be encrypted before
   the final KINK checksum is applied.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|   +---------------+---------------+---------------+---------------+
|   | Next Payload  |   RESERVED    |         Payload Length        |
    +---------------+---------------+---------------+---------------+
    | InnerNextPload|                   RESERVED2                   |
    +---------------+---------------+---------------+---------------+
    |                         Payload (variable)                    |
    +---------------+---------------+---------------+---------------+

|                    Figure 13:  KINK_ENCRYPT Payload

should say:

|  The KINK_ENCRYPT payload encapsulates other KINK payloads and its
|  value is encrypted using the session key and the algorithm specified
   by its etype.  This payload MUST be the final one in the outer
|  payload chain of the message.  The plaintext KINK_ENCRYPT payload
|  value MUST be encrypted before the final KINK checksum is applied.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +---------------+---------------+---------------+---------------+
    | Next Payload  |   RESERVED    |         Payload Length        |
    +---------------+---------------+---------------+---------------+
|   |                                                               |
|   ~       encrypted KINK_ENCRYPT Payload value (variable)         ~
|   |                                                               |
    +---------------+---------------+---------------+---------------+

|                    Figure 13a:  KINK_ENCRYPT Payload

(I have chosen the more descriptive filed name,
'encrypted KINK_ENCRYPT Payload value' over the more fuzzy term,
'encryption payload' used in the text on page 23.)

After the first bullet on page 23,

     o    Next Payload, RESERVED, Payload Length -- Defined in the
          beginning of this section.  This payload is the last one in a
          message, and accordingly, the Next Payload field must be
          KINK_DONE (0).

The following text and figure should be inserted:

     o    encrypted KINK_ENCRYPT Payload value -- This is the
          encrypted form of the plaintext form of the KINK_ENCRYPT
          Payload value in the following format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +---------------+---------------+---------------+---------------+
    | InnerNextPload|                   RESERVED2                   |
    +---------------+---------------+---------------+---------------+
    |                   KINK Payloads (variable)                    |
    +---------------+---------------+---------------+---------------+

|          Figure 13b:  unencrypted KINK_ENCRYPT Payload value

   Fields:


(7b)  typo, and (7a) continued

The final paragraph of Section 4.2.7, on page 23, says:

                     vvvvvvvvvvvvvvvvvv
|  The format of the encryption payload follows the normal Kerberos
   semantics.  Its content is the output of an encrypt function defined
   in the Encryption Algorithm Profile section of [KCRYPTO].  Parameters
   such as encrypt function itself, specific-key, and initial state are
   defined with the etype.  [...]
   itself and there may be some garbage data at the end of the decrypted
   plaintext.  A KINK implementation MUST be prepared to ignore such
   padding after the last sub-payload inside the KINK_ENCRYPT payload.
   [...]

It should say:

                     vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
|  The format of the encrypted KINK_ENCRYPT Payload value follows the
   normal Kerberos semantics.  Its content is the output of an encrypt
   function defined in the Encryption Algorithm Profile section of
|  [KCRYPTO].  Parameters such as the encrypt function itself, specific-
   key, and initial state are defined with the etype.  [...]

Notes:

Items (1)..(7) have been revised on the author's comments received.
In particular, item (7) has been revised substantially to achieve
a selfconsistent presentation in accordance with the author's intent.
I propose to incorporate the above items (1)..(7) and (9) directly
into an RFC Errata Note.
Item (8), and perhaps item (7) as well, still needs judgement from
the RFC authors.

------------------------------------------------
ERRATA RESPONSE:
From: Unknown Name (though from this email: Shouichi.Sakane@jp.yokogawa.com)
Could someone verify 1a, 4b and 9b ?

from pending

Errata ID: 1770
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-06
Held for Document Update by: Pasi Eronen
Date Held: 2009-04-30

 

(1)  Section 4.2.1 (page 17)

(1a)  typo (word omission)

The final sentence in the 3rd paragraph of Section 4.2.1 says:

                                                            [...].  A
   principal name is case sensitive, and "fqdn" part MUST be lowercase
   as described in [KERBEROS].

It should say:
                                        vvvvv
                                                            [...].  A
|  principal name is case sensitive, and the "fqdn" part MUST be
   lowercase as described in [KERBEROS].

(1b)  see (0) above

The subsequent text, above Figure 7,

   vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
|  The value field of this payload has the following format:

should say:

   vvvvvvvvvvvv
|  This payload has the following format:


(2)  Section 4.2.2 (page 18)

Like (1b) above, the text above Figure 8,

   vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
|  The value field of this payload has the following format:

should say:

   vvvvvvvvvvvv
|  This payload has the following format:


(3)  Section 4.2.3 (page 19)

Like (1b) above, the text above Figure 9,

   vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
|  The value field of this payload has the following format:

should say:

   vvvvvvvvvvvv
|  This payload has the following format:


(4)  Section 4.2.4 (page 20)

(4a) Like (1b) above, the text above Figure 10,

   vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
|  The value field of this payload has the following format:

should say:

   vvvvvvvvvvvv
|  This payload has the following format:

(4b) The second bullet of the subsequent explanations,

     o    PrincName -- The name of the principal that the initiator
          wants to communicate with.  It is assumed that the initiator
          knows the responder's principal name (including the realm
|         name) in the same way as the non-User-to-User case.  The TGT
          returned MUST NOT be an inter-realm TGT and its cname and
          crealm MUST match the requested principal name, so that the
          initiator can rendezvous with the responder at the responder's
          realm.

should say (filling in a missing word):

     o    PrincName -- The name of the principal that the initiator
          wants to communicate with.  It is assumed that the initiator
          knows the responder's principal name (including the realm
|         name) in the same way as in the non-User-to-User case.  The
          TGT returned MUST NOT be an inter-realm TGT and its cname and
          crealm MUST match the requested principal name, so that the
          initiator can rendezvous with the responder at the responder's
          realm.


(5)  Section 4.2.5 (page 21)

Like (1b) above, the text above Figure 11,

   vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
|  The value field of this payload contains the TGT requested in a
   previous KINK_TGT_REQ payload of a GETTGT command.

should say:

   vvvvvvvvvvvv
|  This payload contains the TGT requested in a previous KINK_TGT_REQ
   payload of a GETTGT command.


(6)  Section 4.2.6 (page 21)

Like (1b) above, the text above Figure 12,

   vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
|  The value field of this payload has the following format:

should say:

   vvvvvvvvvvvv
|  This payload has the following format:

[see errata ID 93 for item 7]

(8)  Section 4.2.8

The text of this section twice, and redundantly, specifies
on page 23 :

                          [...].  The error code is in network order.

and on page 24 :

     o    ErrorCode -- One of the following values in the network byte
          order:
          [...]

This looks like a big exception.  But in fact, that is the general
rule as set in the first sentence of Section 4, on page 13!
At best, the former sentence should be deleted, and the latter
bullet changed to say:

     o    ErrorCode -- One of the following values:
          [...]

If it is preferred to not delete the former sentence and the latter
clause, at least the "the" in "in the network byte order" should be
deleted.


(9)  further word omissions in running text

(9a) The first paragraph of Section 6.6, on page 32, says:

   A GETTGT command is only used to carry a Kerberos TGT and is not
   related to SA management; therefore, it contains only KINK_TGT_REQ
   payload and does not contain any DOI-specific payload.

It should say:

   A GETTGT command is only used to carry a Kerberos TGT and is not
|  related to SA management; therefore, it contains only a KINK_TGT_REQ
   payload and does not contain any DOI-specific payload.

(9b) The first paragraph of Section 7, on page 32, says:

   KINK uses the same key derivation mechanisms defined in section 5.5
   of [IKE], which is:

It should say:
                                               vvvv
|  KINK uses the same key derivation mechanisms as defined in section
   5.5 of [IKE], which is:

Notes:

[split everything except item 7 away from errata ID 93]

(0) Rationale for most non-trivial issues listed below:
==============

The initial text of Section 4.2 (on page 16) says:

Immediately following the header, there is a list of
Type/Length/Value (TLV) payloads. There can be any number of
payloads following the header. Each payload MUST begin with a
payload header. Each payload header is built on the generic payload
header. Any data immediately follows the generic header. Payloads
are all implicitly aligned to 4-octet boundaries, though the payload
length field MUST accurately reflect the actual number of octets in
the payload.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+
| value (variable) |
+---------------+---------------+---------------+---------------+

Figure 6: Format of a KINK Payload

Fields:

[...]


To sum up: a KINK payload consists of a (generic) payload header
and the (payload) value field.

Unfortunately, the subsequent sub-sections 4.2.* inadvertently
seem to pretend that there exists another copy of the payload
header within the payload value, which certainly was not intended.

It was the intent of the authors to always show and describe the
full payloads in these sections.
Therefore, the repeated text stating to the contrary that it will
show the payload *value*, has to be changed.


I use change bars ('|' in column 1) and (occasionally) up/down
pointing marker lines to emphasize the location of textual issues
in the snippits from the RFC text and/or the proposed modified text.
Modified text has been adjusted according to RFC formatting policy.

Items (1)..(7) have been revised on the author's comments received.
In particular, item (7) has been revised substantially to achieve
a selfconsistent presentation in accordance with the author's intent.
I propose to incorporate the above items (1)..(7) and (9) directly
into an RFC Errata Note.
Item (8), and perhaps item (7) as well, still needs judgement from
the RFC authors.

------------------------------------------------
ERRATA RESPONSE:
From: Unknown Name (though from this email: Shouichi.Sakane@jp.yokogawa.com)
Could someone verify 1a, 4b and 9b ?


from pending

RFC 4433, "Mobile IPv4 Dynamic Home Agent (HA) Assignment", March 2006

Source of RFC: mip4 (int)

Errata ID: 92
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Brian Haberman

Section 5.3.1 says:

   The following table summarizes the behavior of the Assigned HA, based
   on the value of the destination IP address and Home Agent field of
   the Registration Request.

   Dest IP Addr   HA field      Processing at Assigned HA
   ------------  ------------ ----------------------------------
...

     Table 1: Registration Request Handling at Assigned HA

It should say:

   The following table summarizes the behavior of the Requested HA,
   based on the value of the destination IP address and the Home Agent
   Address field of the Registration Request.

   Dest IP Addr   HA field      Processing at Requested HA
   ------------  ------------ ----------------------------------
...
     Table 1: Registration Request Handling at the Requested HA

Notes:

According to, e.g., the explanations in bullet 1 of Section 5.3,
"Assigned HA" is not correct; the term to be used is "Requested HA";
it will eventually become the "Assigned HA" if the conditions
mentioned are met, but the behaviour described strictly applies
to the "Requested HA" role.

from pending

RFC 4439, "Fibre Channel Fabric Address Manager MIB", March 2006

Source of RFC: imss (ops)

Errata ID: 89
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Held for Document Update by: Dan Romascanu

The DESCRIPTION clause for the t11FamAutoReconfigure OBJECT-TYPE macro invocation says:

           If value of this object is 'true', the switch will
           send an RCF (ReConfigureFabric) to rebuild the
           Fabric.

It should say:

           If the value of this object is 'true', the switch will
           send an RCF (ReConfigureFabric) to rebuild the
           Fabric.

RFC 4443, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", March 2006

Note: This RFC has been updated by RFC 4884

Source of RFC: ipv6 (int)

Errata ID: 88
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-04-19
Held for Document Update by: Brian Haberman

 

(1)  text omission ???

I suspect that something went wrong in the publication process
for RFC 4443, leading to significant text omission.

Symptoms:

o  Text on top of page 5 apparently *continues* specifications
   that are not in the published text;

o  Appendix A contains the change item:

   - Added specification that all ICMP error messages shall have exactly
     32 bits of type-specific data, so that receivers can reliably find
     the embedded invoking packet even when they don't recognize the
     ICMP message Type.

   I could not find any text in the body of the RFC corresponding
   to this statement.

Therefore, I suspect that general specifications for ICMPv6 error
messages have been dropped inadvertently from the end of Section
2.1, at the bottom of page 4 in the published text, or that even
a subsection dealing with the peculiar requirements for ICMPv6
error messages has been dropped, just leaving in the published text
the single sentence at top of page 5.

I expect the missing text to depict the general structure of the
Message Body of ICMPv6 error messages with all related explanations,
according to the above mentioned change note.

Appendix A also states:

   - Removed the general packet format from Section 2.1.  It refers to
     Sections 3 and 4 for packet formats now.

This is not literally true.  The general format *is* in Section 2.1.
But in fact, it would be logical to have the (missing) specifications
for error messages -- including the 4 lines of test on top of page 5 --
incorporated into (the start of) Section 3 (*before* the heading for
Section 3.1.) instead of the end of Section 2.1.


(2)  possible textual improvement

in the lower third of page 3, Section 2.1 says:

   The code field depends on the message type.  It is used to create an
   additional level of message granularity.

It should perhaps better say:

   The code field depends on the message type.  It is used to create an
   additional level of message type granularity.
                              ^^^^^^

(3)  reference to old IPsec Architecture document

Section 5.1, at the bottom of page 15, has been updated to point
to the new IPsec Architecture document, RFC 4301, via the reference
tag [SEC-ARCH].  But immediately below, in the first paragraph of
Section 5.2, on top of page 16, the RFC text says:

   ICMP messages may be subject to various attacks.  A complete
   discussion can be found in the IP Security Architecture [IPv6-SA].
   [...]

It remains unclear why the reference is made to the previous IPsec
Architecture document, RFC 2401, in this case.
In fact, RFC 4301 has simplified ICMP handling by the introduction
of ICMP Type+Code as a Traffic Selector for the SPD, and therefore
contains restructured text on ICMP message processing.
Nevertheless, as far as I can see, RFC 4301 has not removed
significant ICMP security related material from RFC 2401.
Thus, IMHO there is no reason to explicitely refer to the obsoleted
specification, RFC 2401 [IPv6-SA], instead of the current one,
RFC 4301 [SEC-ARCH].


(4)  more issues with references

According to Appendix A, RFC 4443 has

   - Separated References into Normative and Informative.

The latest RFC Authoring Internet draft revisions
(cf. draft-rfc-editor-rfc2223bis-xx
 and draft-hoffman-rfc-author-guide-01)
all have included the definition:
     Normative references specify documents that must be read
     to understand or implement the technology in the document,
     or whose technology must be present for the technology in
     the new RFC to work.  [...] an informative reference might
     provide background or historical information to the reader.
     [...]

The separation performed does not match this definition.

(4a)
RFC 4443 refers to RFC 792 and RFC 1122 to point out the analogy
to ICMP[v4], but it is a self-contained specification, and ICMPv6
does not rely on the implementation of ICMP[v4] -- IPv6 only nodes
are possible and even expected for the (far?) future.
Therefore, the references [RFC-792] and [RFC-1122] should better
have been placed into section 7.2, Informative References, instead
of Section 7.1, Normative References.

(4b)
RFC 4443 also lists in Section 7.1, Normative References, the
reference to its obsoleted predecessor, RFC 2463 [RFC-2463].
This is a fatal lock on the Standards Track for RFC 4443:
RFC 4443 can *not* be advanced above the level of RFC 2463,
if the written procedures are taken literally !
(Also, RFC 4443 contains all material from RFC 2463, and thus
RFC 2463 is not needed to understand and/or implement RFC 4443.)

Therefore, all references to obsoleted documents should be
named Informative, and in the case of RFC 4443, [RFC-2463]
should have been moved into Section 7.2 as well.

(4c)
The old IPv6 Addressing Architecture document, RFC 3513, has been
replaced by RFC 4291, published more than 5 weeks before RFC 4443.

Therefore, in Section 7.2 of RFC 4443, the Informative Reference
[IPv6-ADDR] should be have been changed to point to RFC 4291
instead of the obsolete RFC 3513.

(4d)
When following my recommendations in item (3) above, the
Informative Reference [IPv6-SA] is not needed any more;
its role has been taken over by the Reference [SEC-ARCH].


(5)  misleading change note

The second bulleted item in Appendix A,

   - Corrected typos in Section 2.4, where references to sub-bullet e.2
     were supposed to be references to e.3.

apparently is not correct; it must have been introduced in the
draft history, referring to a change in the draft.
The references in RFC 2463 to sub-bullet (e.2) were correct.
RFC 4443 has inserted a new item (e.2) into the list, incrementing
the numbers of the previous sub-bullet (e.2) and all subsequent
sub-bullets, thus making it necessary to increment the references.
Perhaps, the latter had not been done in an early draft revision,
and has then been corrected in a later one.
Thus, the above change note should not have been included in RFC 4443.

Notes:

from pending

Errata ID: 1918
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Thorsten Ulbricht
Date Reported: 2009-10-19
Held for Document Update by: Brian Haberman

Section 7.2 says:

   [IPv6-ESP]   Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
                4203, December 2005.

It should say:

   [IPv6-ESP]   Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
                4303, December 2005.

Errata ID: 1926
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Thorsten Ulbricht
Date Reported: 2009-10-23
Held for Document Update by: Brian Haberman

Section 7.2 says:

   [IPv6-ADDR]  Hinden, R. and S. Deering, "Intpernet Protocol Version 6
                (IPv6) Addressing Architecture", RFC 3513, April 2003.

It should say:

   [IPv6-ADDR]  Hinden, R. and S. Deering, "Internet Protocol Version 6
                (IPv6) Addressing Architecture", RFC 3513, April 2003.

Errata ID: 3201
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: David Gräff
Date Reported: 2012-04-25
Held for Document Update by: Brian Haberman

Section 7.2 says:

   [IPv6-ESP]   Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
                4203, December 2005.

It should say:

   [IPv6-ESP]   Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
                4303, December 2005.

Notes:

Wrong RFC reference.

RFC 4444, "Management Information Base for Intermediate System to Intermediate System (IS-IS)", April 2006

Source of RFC: isis (rtg)

Errata ID: 3321
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-05-29
Held for Document Update by: Adrian Farrel
Date Held: 2012-08-16

 

(1)  erratum: disfigured object name

In the DESCRIPTION clause of the isisCircLevelType OBJECT-TYPE macro
instance, on mid-page 32, the sentence

                                        [...].  Thus, if the
             isisSysTpe is level2 and the isisCircLevelType
             for a circuit is level1, the circuit will not send
             or receive IS-IS packets.  [...]

should say:
                    vvvvvvvvv
                                        [...].  Thus, if the
|            isisSysLevelType is level2 and the isisCircLevelType
             for a circuit is level1, the circuit will not send
             or receive IS-IS packets.  [...]

(5)  errata(?): overly restrictive RowStatus object descriptions

Some tables with conceptual rows that can be dynamically added
or deleted, contain a control object with SYNTAX RowStatus
and other control objects, e.g. with SYNTAX IsisAdminState.

I expect that the latter objects have been intended to control
the activity of "live" table rows, without the need to deactivate
these rows via the RowStatus object before setting the AdminState
to "on" or "off", so much the more the support for the
'notInServcie' state of the RowStatus objects is explicitely
"not required".  Therefore, I strongly suspect that some RowStatus
object DESCRIPTION clauses have unintentionally been worded overly
restrictive and should been corrected to allow AdminStatus changes.

Some other such clauses contain statements that are void due to the
lack of accessible objects in those tables they could be applied to.

I have identified the following instances of these issues:

(5.1)

The DESCRIPTION clause of the isisManAreaAddrExistState OBJECT-TYPE
macro instance, on page 18, says:

        DESCRIPTION
            "The state of the isisManAreaAddrEntry.  If the
             isisSysAdminState for this Intermediate System is 'on' and
             an attempt is made to set this object to the value
             'destroy' or 'notInService' when this is the only
             isisManAreaAddrEntry in state 'active' for this
             Intermediate System should return inconsistentValue.
|
|            A row entry cannot be modified when the value of this
|            object is 'active'."

The last sentence is void, because the conceptual table rows of the
IsisManAreaAddrTable do not contain any other accessible objects
than the RowStatus object proper, isisManAreaAddrExistState.
Therefore, this clause should be shortened to say:

        DESCRIPTION
            "The state of the isisManAreaAddrEntry.  If the
             isisSysAdminState for this Intermediate System is 'on' and
             an attempt is made to set this object to the value
             'destroy' or 'notInService' when this is the only
             isisManAreaAddrEntry in state 'active' for this
             Intermediate System should return inconsistentValue."

(5.2)

The DESCRIPTION clause of the isisRedistributeAddrExistState
OBJECT-TYPE macro instance, on pp. 23/24, says:

        DESCRIPTION
            "The existence state of this summary address.  Support
<page break>
             for createAndWait and notInService is not required.
|
|            A row entry cannot be modified when the value of this
|            object is 'active'."

The last sentence is void, because the conceptual table rows of the
IsisRedistributeAddrTable do not contain any other accessible objects
than the RowStatus object proper, isisRedistributeAddrExistState.
Therefore, this clause should be shortened to say:

        DESCRIPTION
            "The existence state of this summary address.  Support
|            for 'createAndWait' and 'notInService' is not required."

(6)  erratum (typo)

The DESCRIPTON clause of the isisRASNPAMask OBJECT-TYPE declaration,
on page 61, says:

        DESCRIPTION
            "A bit mask with 1 bit indicating the positions in the
             effective destination address from which embedded SNPA
             information is to be extracted.  [...]

It should say:
                                 vvv
        DESCRIPTION
|           "A bit mask with 1 bits indicating the positions in the
             effective destination address from which embedded SNPA
             information is to be extracted.  [...]


(7)  erratum: disfigured object names

The last paragraph on page 62, within the DESCRIPTION clause of the
isisIPRAEntry OBJECT-TYPE declaration says:

             Implementers need to be aware that if the total number
             of elements (octets or sub-identifiers) in
             isisIPRADestr, isisIPRADestPrefixLen, and
             isisIPRANextHopIndex is too great, then OIDs of column
             instances in this table will have more than 128
             subidentifiers and cannot be accessed using SNMPv1,
<page break>
             [...]

It should perhaps say:

             Implementers need to be aware that if the total number
             of elements (octets or sub-identifiers) in
|            isisIPRADestType, isisIPRADest, isisIPRADestPrefixLen,
             and isisIPRANextHopIndex is too great, then OIDs of
             column instances in this table will have more than 128
             subidentifiers and cannot be accessed using SNMPv1,
             [...]

Notes:

This Errata Note is duplicated from EID 87 to separate out issues of different categories.

All excerpts from the RFC text are taken literally, keeping their
original formatting, and modified text is formatted in conformance
with RFC guidelines again.

I use change bars ('|' in column 1) and casual up/down pointing
tags ('^^^' / 'vvv' marks in extra lines) to emphasize the location
of textual issues and/or proposed textual enhancements/corrections.

RFC 4447, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", April 2006

Note: This RFC has been obsoleted by RFC 8077

Note: This RFC has been updated by RFC 6723, RFC 6870, RFC 7358

Source of RFC: pwe3 (int)

Errata ID: 3554
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Brian Haberman
Date Held: 2013-03-16

Section 5.2 says:

-  Group ID

   An arbitrary 32-bit value that represents a group of PWs that is
   used to create groups in the PW space.  The group ID is intended
   to be used as a port index, or a virtual tunnel index.  To
   simplify configuration, a particular PW ID at ingress could be
   part of the virtual tunnel for transport to the egress router.

It should say:

-  Group ID

   An arbitrary 32-bit value that represents a group of PWs that is
   used to create groups in the PW space.  The group ID is intended
   to be used as a port index, or a virtual tunnel index.  To
|  simplify configuration, a particular PW Group ID at ingress could
   be part of the virtual tunnel for transport to the egress router.

Notes:

"PW ID" should in fact be "PW Group ID"

Errata ID: 938
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Brian Haberman
Date Held: 2013-03-16

Section 5.3.2.2 says:

5.3.2.2.  PW Grouping TLV

It should say:

5.3.2.2.  PW Grouping ID TLV

Notes:

change to section title, for terminological consistency

Errata ID: 86
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Stewart Bryant

Abstract says:

   It is also possible to use pseudowires to
   provide low-rate Time Division Multiplexed and a Synchronous Optical
   NETworking circuit emulation over an MPLS-enabled network.  This
   document specifies a protocol for establishing and maintaining the
   pseudowires, using extensions to Label Distribution Protocol (LDP).
   Procedures for encapsulating Layer 2 PDUs are specified in a set of
   companion documents.

It should say:

   It is also possible to use pseudowires to
|  provide low-rate Time Division Multiplexed and Synchronous Optical
   NETworking circuit emulation over an MPLS-enabled network.  This
   document specifies a protocol for establishing and maintaining the
|  pseudowires, using extensions to the Label Distribution Protocol
   (LDP).  Procedures for encapsulating Layer 2 PDUs are specified in a
   set of companion documents.

Notes:

use of articles

Errata ID: 3555
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Brian Haberman
Date Held: 2013-03-16

Section 5.3.2 says:

(2nd-to-last paragraph on page 13)

   The PW information length field contains the length of the SAII,
   TAII, and AGI, combined in octets.  If this value is 0, then it
|  references all PWs using the specified grouping ID.  In this case,
   there are no other FEC element fields (AGI, SAII, etc.) present, nor
   any interface parameters TLVs.

It should say:

   The PW information length field contains the length of the SAII,
   TAII, and AGI, combined in octets.  If this value is 0, then it
|  references all PWs using the grouping ID (specifed in the PW grouping
|  ID TLV).  In this case, there are no other FEC element fields (AGI,
   SAII, etc.) present, nor any interface parameters TLVs.

Notes:

To make the context more clear

Errata ID: 3115
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Stewart Bryant
Date Held: 2012-02-07

Section 5.1 says:

(page 8, the first 2 tables)

   This document specifies the following new TLVs to be used with LDP:

   TLV                    Specified in Section     Defined for Message
   ===================================================================
   PW Status TLV                  5.4.2            Notification
   PW Interface Parameters TLV    5.3.2.1          FEC
   PW Grouping  ID TLV            5.3.2.2          FEC


   Additionally, the following new FEC element types are defined:

   FEC Element Type        Specified in Section    Defined for Message
   ===================================================================
   0x80                            5.2             FEC
   0x81                            5.3             FEC

It should say:

   This document specifies the following new TLVs to be used with LDP:

   TLV                      Specified in Section   Defined for Message
   ===================================================================
   PW Status TLV                    5.4.2          Notification
|  PW Interface Parameters TLV      5.3.2.1        with FEC TLV
|  PW Grouping ID TLV               5.3.2.2        with FEC TLV


   Additionally, the following new FEC element types are defined:

|  FEC Element Type     FEC Element Name          Specified in Section
   ===================================================================
|  0x80                 PWid                               5.2
|  0x81                 Generalized PWid                   5.3

Notes:

wrong term(s) used in table(s).
Apparently, "FEC" is not appropriate in the last column of the first
table, and "Defined for Message" makes no sense in the second table,
where only "FEC" appears, as "FEC" is not an LDP message, it is a TLV.
Perhaps, the latter column is dispensable, in favor of a new column
showing the name of the FEC element.

-- VERIFIER NOTES --
The editors should look at this if there is an update.

The table is a quick index to information about a specific FEC and likely will be removed in a future version of this RFC.

Errata ID: 3114
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Stewart Bryant
Date Held: 2012-02-07

Section 5.4.2 says:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   Notification (0x0001)     |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Message ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Status (TLV)                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      PW Status TLV                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           PWId FEC TLV or Generalized ID FEC TLV              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   Notification (0x0001)     |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Message ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Status (TLV)                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      PW Status TLV                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |      FEC TLV with  PWId or Generalized PWId FEC Element       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |                      PW Grouping ID TLV                       |
|  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

message diagram incomplete.

Rationale:
a) using defined terms verbatim
b) final TLV added: PW Grouping ID TLV

-- VERIFIER NOTES --
The editors should consider this in an future revision, but as the PW Grouping ID TLV is optional it could be addressed in the diagram or with a note.

Errata ID: 3112
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Stewart Bryant
Date Held: 2012-02-07

Section 6.2 says:

                          [...].  If one endpoint prefers to use the
   control word but the other does not, the one that prefers not to use
|  it is has no extra protocol to execute; it just waits for a Label
   Mapping message that has c=0.

It should say:

                          [...].  If one endpoint prefers to use the
   control word but the other does not, the one that prefers not to use
|  it has no extra protocol to execute; it just waits for a Label
   Mapping message that has c=0.

Notes:

typo (spurious word)

Errata ID: 1530
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vishwas Manral
Date Reported: 2008-09-29
Held for Document Update by: Stewart Bryant

Section 3 says:

  This document specifies all the procedures necessary to set up and 
  maintain the pseudowires needed to support "unswitched" point-to-
  point services, where each end of the pseudowire is provisioned 
  with the identify of the other endpoint.
                 ^^

It should say:

  This document specifies all the procedures necessary to set up and 
  maintain the pseudowires needed to support "unswitched" point-to-
  point services, where each end of the pseudowire is provisioned 
  with the identity of the other endpoint.
                 ^^

Notes:

None

RFC 4448, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", April 2006

Note: This RFC has been updated by RFC 5462, RFC 8469

Source of RFC: pwe3 (int)

Errata ID: 85
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-05-25
Held for Document Update by: Stewart Bryant

 

1)  a subtle typo

Section 4.5 of RFC 4448, on top of page 12, says:

   The Ethernet PW management model follows the general PW management
   model defined in [RFC3985] and [PWE3-MIB].  Many common PW management
   facilities are provided here, with no additional Ethernet specifics
   necessary.  Ethernet-specific parameters are defined in an additional
   MIB module, [PW-MIB].

It should say, replacing "here" by "there":

   The Ethernet PW management model follows the general PW management
   model defined in [RFC3985] and [PWE3-MIB].  Many common PW management
|  facilities are provided there, with no additional Ethernet specifics
   necessary.  Ethernet-specific parameters are defined in an additional
   MIB module, [PW-MIB].


(2)  terminological issue / violation of reference model

Section 4.4.1 of RFC 4448, on pp. 9/10, says:

--- snip ---
   When the PE receives an Ethernet frame, and the frame has a VLAN tag,
   we can distinguish two cases:

      1. The tag is service-delimiting.  This means that the tag was
         placed on the frame by some piece of service provider-operated
         equipment, and the tag is used by the service provider to
         distinguish the traffic.  For example, LANs from different
         customers might be attached to the same service provider
         switch, which applies VLAN tags to distinguish one customer's
         traffic from another's, and then forwards the frames to the PE.

      2. The tag is not service-delimiting.  This means that the tag was
         placed in the frame by a piece of customer equipment, and is
         not meaningful to the PE.

   Whether or not the tag is service-delimiting is determined by local
   configuration on the PE.
--- snip ---

IMHO, this is a very unfortunate explanation.

a) The term, "service delimiting", apparently here is defined
   by the origin of the tag, not by its function.
   I do not believe that this is the appropriate way to deal with;
   later on in RFC 4448, it (reasonably) seems to be permitted
   that a service-delimiting tag has been provided by a CE device!

b) The situation described in bullet 1), with a provider owned
   switch, removes the PW terminating entity from the provider
   *edge*, turning it from a "PE" device into a "P" device,
   which is highly inconsistent with the service model developed
   in Section 1 of RFC 4448, and leads to a clash in terminology.
   To stay within that model, the "coloring" function described
   in bullet 1) must conceptionally be performed by the NSP
   function *within* the (PW terminating) PE device. (And it might
   as well be performed in customer equipment, i.e. at the CE.)

Perhaps, the above text should be improved.
I'll try at a first proposal:

--- snip ---
   When the PE receives an Ethernet frame, and the frame has a VLAN tag,
   we can distinguish two cases:

      1. The tag is service-delimiting.
	 This means that the tag was introduced for the single purpose
	 of identifying the frame for the PW service, e.g., to select a
	 specific PW for transmission of the frame.  A service-
	 delimiting tag may have been added on the CE side or in the
         (conceptual) NSP function of the PE edge.
	 Ordinarily, any service-delimiting tag will not be transmitted
	 over the PW, i.e., it will be removed before PW encapsulation.

      2. The tag is not service-delimiting.  This means that the tag is
         not meaningful to the PW endpoints and must be transmitted over
	 the PW.
	 Such tag usually was placed in the frame by a piece of customer
	 equipment, but it might as well be added or modified by the NSP
	 function of the PW terminating PE device.

   Whether or not the tag is service-delimiting is determined by local
   configuration on the PE.
--- snip ---

Notes:

from pending

RFC 4449, "Securing Mobile IPv6 Route Optimization Using a Static Shared Key", June 2006

Source of RFC: mip6 (int)

Errata ID: 820
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marc Blanchet
Date Reported: 2007-01-09
Held for Document Update by: Brian Haberman

 

The title of RFC 4449 is: 

Securing Mobile IPv6 Route Optimization Using a Static Shared Key

However, the pages title is: 

RFC 4449           Shared Data for Precomputable Kbm           June 2006

It should say:

[not submitted]

Notes:

They differ sufficiently enough that a reader think that he is
not reading the right document!

from pending

RFC 4452, "The "info" URI Scheme for Information Assets with Identifiers in Public Namespaces", April 2006

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 2700
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-02-01
Held for Document Update by: Pete Resnick

Section 10.1 says:

 [RFC4395]  Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
            Registration Procedures for New URI Schemes", BCP 115, RFC
            4395, February 2006.

It should say:

 [RFC4395]  Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
            Registration Procedures for New URI Schemes", BCP 35, RFC
            4395, February 2006.

Notes:

RFC 4395 is not BCP 115, but BCP 35

RFC 4456, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", April 2006

Note: This RFC has been updated by RFC 7606

Source of RFC: idr (rtg)

Errata ID: 3778
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramakrishna DTV
Date Reported: 2013-10-30
Held for Document Update by: Stewart Bryant
Date Held: 2013-10-31

Section 5 says:

The Non-Client peer must be fully meshed but the Client
   peers need not be fully meshed.

It should say:

The Non-Client peers must be fully meshed but the Client
   peers need not be fully meshed.

Notes:

This is a typo. Figure 4 shows multiple Non-Client peers.
But the text is referring to "The Non-Client peer". It should be
"The Non-Client peers".

RFC 4458, "Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR)", April 2006

Note: This RFC has been updated by RFC 8119

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rai

Errata ID: 3359
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Doug Sauder
Date Reported: 2012-09-19
Held for Document Update by: Robert Sparks

Section 6.1 says:

    INVITE sip:voicemail@example.com;\
           target=sip:+15555551002%40example.com;user=phone;\
           cause=486  SIP/2.0

It should say:

    INVITE sip:voicemail@example.com;\
           target=sip:+15555551002%40example.com%3Buser=phone;\
           cause=486  SIP/2.0

Notes:

The ";user=phone" characters should be part of the target parameter value. The semicolon is not allowed in the pvalue syntax and must be escaped.

This same correction is needed in other sections as well: 6.2, 6.4.

RFC 4462, "Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol", May 2006

Note: This RFC has been updated by RFC 8732, RFC 9142

Source of RFC: secsh (sec)

Errata ID: 1621
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Harris
Date Reported: 2008-11-25
Held for Document Update by: Pasi Eronen

Section 9 says:

   In order for the "external-keyx" user authentication method to be
   used, it MUST have access to user authentication information obtained
   as a side-effect of the key exchange.  If this information is
   unavailable, the authentication MUST fail.

It should say:

   In order for the "gssapi-keyex" user authentication method to be
   used, it MUST have access to user authentication information obtained
   as a side-effect of the key exchange.  If this information is
   unavailable, the authentication MUST fail.

Notes:

As mentioned in section 8, the "external-keyx" name was used by an earlier version of thespec, but got replaced by "gssapi-keyex" before publication.

RFC 4479, "A Data Model for Presence", July 2006

Source of RFC: simple (rai)

Errata ID: 2963
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Raphael Bossek
Date Reported: 2011-09-08
Held for Document Update by: Robert Sparks

Section 7.1. says:

<dm:deviceID>mac:8asd7d7d70</dm:deviceID>
...
<dm:deviceID>mac:8asd7d7d70</dm:deviceID>

It should say:

Replace both with

<dm:deviceID>urn:uuid:698137d0-b395-11e0-aff2-0800200c9a66</dm:deviceID>

Notes:

As mentioned in Errata ID 2131 and 2962 a valid URN as defined in RFC3406: Uniform Resource Names (URN) Namespace Definition Mechanisms should be used for <dm:deviceID>. This is not the case for this example.
RFC 4479 in section 3.4. Device RECOMMENDS version 1 UUIDs for the <deviceID> element: "For devices with a MAC address, version 1 UUIDs are RECOMMENDED, as they result in a time-based identifier that makes use of the MAC address."

Errata ID: 80
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-11
Held for Document Update by: Robert Sparks

Section 3 says:

   It is central to this model that each attribute
   is affiliated with the service, person, or device because they
   describe that service, presentity, or device.  This is in contrast to
   a model whereby the attributes are associated with the service,
   presentity, or device because they were reported by that service,
   presentity, or device. 

It should say:

   It is central to this model that each attribute
   is affiliated with the service, person, or device because they
   describe that service, person, or device.  This is in contrast to
   a model whereby the attributes are associated with the service,
   person, or device because they were reported by that service,
   person, or device.  

Notes:

Regarding the definition from Section 2, on top of page 4 of the RFC,

Presentity: A presentity combines devices, services, and person
information for a complete picture of a user's presence status on
the network.

IMHO the term "presentity" should have been replaced by "person" to keep this text passage
consistent with the terminology introduced in Section 2.

Errata ID: 2131
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Martin Thomson
Date Reported: 2010-04-05
Held for Document Update by: Robert Sparks

Section 7.1 says:

   <presence xmlns="urn:ietf:params:xml:ns:pidf"
    xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
    xmlns:rp="urn:ietf:params:xml:ns:pidf:rpid"
    xmlns:caps="urn:ietf:params:xml:ns:pidf:caps"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

It should say:

   <presence xmlns="urn:ietf:params:xml:ns:pidf"
    xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
    xmlns:rp="urn:ietf:params:xml:ns:pidf:rpid"
    xmlns:caps="urn:ietf:params:xml:ns:pidf:caps"
    entity="pres:presentity@example.com">

Notes:

The entity attribute of the <presence> element is mandatory. It contains a URI that identifies the presentity.

The namespace prefix binding for "http://www.w3.org/2001/XMLSchema-instance" is not used in the example and need not appear.

Not corrected here: the example uses an undefined URI scheme, mac:, to identify a device.

RFC 4480, "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)", July 2006

Source of RFC: simple (rai)

Errata ID: 2961
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Raphael Bossek
Date Reported: 2011-09-07
Held for Document Update by: Robert Sparks

Section 4. says:

<rpid:sphere>bowling league</rpid:sphere>

It should say:

<rpid:sphere><bowlingleague/></rpid:sphere>

Notes:

The <sphere> content type is 'element-only'; it's not valid to use tokens. It's possible to use XML elements from other XML namespace (e.g. <bowlingleague/>) or choose one of the following: <rpid:work/>, <rpid:home/>, <rpid:unknown/>

Errata ID: 2962
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Raphael Bossek
Date Reported: 2011-09-08
Held for Document Update by: Robert Sparks

Section 4. says:

<dm:deviceID>urn:device:0003ba4811e3</dm:deviceID>
...
<dm:deviceID>urn:x-mac:0003ba4811e3</dm:deviceID>
...
<dm:deviceID>urn:device:0003ba4811e3</dm:deviceID>

It should say:

Replace all three with

<dm:deviceID>urn:uuid:698137d0-b395-11e0-aff2-0800200c9a66</dm:deviceID>

Notes:

"urn:device" is a not registered URN namespace as defined by RFC3406: Uniform Resource Names (URN) Namespace Definition Mechanisms. "urn:x-mac" is an experimental URN namespace. All <dm:deviceID> address point to the same device.
RFC 4479 in section 3.4. Device RECOMMENDS version 1 UUIDs for the <deviceID> element: "For devices with a MAC address, version 1 UUIDs are RECOMMENDED, as they result in a time-based identifier that makes use of the MAC address."

Errata ID: 3121
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Saint-Andre
Date Reported: 2012-02-14
Held for Document Update by: Richard Barnes
Date Held: 2013-04-16

Section 7.2 says:

                 <xs:element name="looking-for-work"
                   type="empty" />
                 <xs:element name="meal"
                   type="empty" />

It should say:

                 <xs:element name="looking-for-work"
                   type="empty" />
                 <xs:element name="lunch"
                   type="empty" />
                 <xs:element name="meal"
                   type="empty" />

Notes:

Erratum #2959 claimed that the element "lunch" needs to be removed from the specification since it is not included in the schema. However, the schema was in error. This erratum corrects the schema so that, if approved, IANA can update the information at http://www.iana.org/assignments/xml-registry/schema/pidf/status/rpid.xsd

Implementors using the schema as updated by this erratum should note that if they produce documents that include the "lunch" element, then these documents might be rejected as invalid by implementations using the original schema.

RFC 4483, "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", May 2006

Source of RFC: sip (rai)

Errata ID: 79
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-06-20
Held for Document Update by: Robert Sparks

 

(1)  Inconsistent Ref. to URI Specification

The text of RFC 4483 repeatedly refers to  "RFC2396 [7]" .
This is misleading.
Every occurrence of "RFC 2396" should be replaced by "RFC 3986".

Note: Section 10.1. Normative References, holds the proper
      reference to STD 66, RFC 3986 in its item [7] !


(2)  Outdated Ref. to HTTP 1.1 Specification

Item [4] of Section 10.1 Normative References, points to the
outdated original specification for HTTP 1.1, RFC 2016,
which has been obsoleted by RFC 2616, 7 years ago.

Since the HTTP ETAG mechanism (referred to in the text of RFC 4483)
has been clarified substantially in RFC 2616, the reference to
"RFC2068 [4]" in Section 4, near the bottom of page 5 of RFC 4483,
should bhave been "RFC2616 [4]", and the item [4] of Section 10.1,
on page 15 of RFC 4483, should be replaced by a citation of RFC 2616
according to `rfc-ref.txt`.


(3)  (Mis)Use of SIP Terminology

Unfortunately, RFC 4483 substantially adds to the confusion
of precisely defined SIP (and other) terminology.

In particular, *all* occurrences of the term "Header[s]" in RFC 4483
should be corrected to say "Header Field[s]".

RFC 4485, published just 2 weeks ahead of RFC 4483, explicitely
poses the requirement for SIP extension documents to follow the
established SIP terminology -- cf. Section 4.3 of RFC 4485
(page 10), which says:

   Careful attention must be paid to the actual usage of terminology.
   Many documents misuse the terms header, header field, and header
   field values, for example.  Document authors SHOULD do a careful
   review of their documents for proper usage of these terms.

See also RFC 4249, Section 3.1.1 (page 3) for a similar statement on
the proper usage of these terms in the context of IMF and MIME, and
related (extension) specifications.

Notes:

from pending

RFC 4490, "Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS)", May 2006

Source of RFC: smime (sec)

Errata ID: 1465
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Serguei Leontiev
Date Reported: 2008-07-09
Held for Document Update by: Tim Polk

Section 4.1.1 says:

Using the secret key corresponding to the originatorKey publicKey and
the recipient's public key, the algorithm VKO GOST R 34.10-94 or VKO
GOST R 34.10-2001 (described in [CPALGS]) is applied to produce the
KEK.

It should say:

Using the private key corresponding to the originatorKey publicKey and
the recipient's public key, the algorithm VKO GOST R 34.10-94 or VKO
GOST R 34.10-2001 (described in [CPALGS]) is applied to produce the
KEK.

Notes:

Russian-English terminology translation bug

Errata ID: 1466
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Serguei Leontiev
Date Reported: 2008-07-09
Held for Document Update by: Tim Polk

Section 4.2.1 says:

Using the secret key corresponding to the GostR3410-
TransportParameters ephemeralPublicKey and the recipient's public
key, the algorithm VKO GOST R 34.10-94 or VKO GOST R 34.10-2001
(described in [CPALGS]) is applied to produce the KEK.

It should say:

Using the private key corresponding to the GostR3410-
TransportParameters ephemeralPublicKey and the recipient's public
key, the algorithm VKO GOST R 34.10-94 or VKO GOST R 34.10-2001
(described in [CPALGS]) is applied to produce the KEK.

Notes:

Russian-English terminology translation bug

Errata ID: 5099
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2017-08-28
Held for Document Update by: Kathleen Moriarty
Date Held: 2018-03-19

Section 12.1 says:

   [GOST3431004] "Information technology. Cryptographic Data Security.
                 Formation and verification processes of (electronic)
                 digital signature based on Asymmetric Cryptographic
                 Algorithm.", GOST 34.310-2004, Council for
                 Standardization, Metrology and Certification of the
                 Commonwealth of Independence States (EASC), Minsk,
                 2004. (In Russian)

It should say:

   [GOST3431004] "Information technology. Cryptographic Data Security.
                 Formation and verification processes of [electronic]
                 digital signature.", GOST 34.310-2004, Council for
                 Standardization, Metrology and Certification of the
                 Commonwealth of Independence States (EASC), Minsk,
                 2004. (In Russian)

Notes:

Incorrect standard name.

RFC 4492, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", May 2006

Note: This RFC has been obsoleted by RFC 8422

Note: This RFC has been updated by RFC 5246, RFC 7027, RFC 7919

Source of RFC: tls (sec)

Errata ID: 2392
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Brian Smith
Date Reported: 2010-07-23
Held for Document Update by: Sean Turner

Section 5.2 says:

The server's Supported Point Formats Extension has the same structure
as the client's Supported Point Formats Extension (see
Section 5.1.2).  Items in elliptic_curve_list here are ordered
according to the server's preference (favorite choice first).  Note
that the server may include items that were not found in the client's
list (e.g., the server may prefer to receive points in compressed
format even when a client cannot parse this format: the same client
may nevertheless be capable of outputting points in compressed
format).

It should say:

The server's Supported Point Formats Extension has the same structure
as the client's Supported Point Formats Extension (see
Section 5.1.2).  Items in ec_point_format_list here are ordered
according to the server's preference (favorite choice first).  Note
that the server may include items that were not found in the client's
list (e.g., the server may prefer to receive points in compressed
format even when a client cannot parse this format: the same client
may nevertheless be capable of outputting points in compressed
format).

Notes:

ec_point_format_list is the field in the Supported Point Formats Extension. elliptic_curve_list is the field in the Supported Elliptic Curves Extension.

Errata ID: 4633
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kurt Roeckx
Date Reported: 2016-03-02
Held for Document Update by: Stephen Farrell
Date Held: 2016-09-12

Section 5.1.1 says:

        struct {
            NamedCurve elliptic_curve_list<1..2^16-1>
        } EllipticCurveList;

It should say:

        struct {
            NamedCurve elliptic_curve_list<2..2^16-1>
        } EllipticCurveList;

Notes:

The count is in bytes, not items.

RFC 4506, "XDR: External Data Representation Standard", May 2006

Source of RFC: nfsv4 (wit)

Errata ID: 76
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-05-24
Held for Document Update by: Martin Stiemerling

 

(1) Section 6.2, page 18 - typo (word omission)

The words in the 9th line of the text,

    [...] "followed by one or hexadecimal digits" [...]

should say:

    [...] "followed by one or more hexadecimal digits" [...]
                             ^^^^^^

(2) Section 8, 2nd paragraph (page 22) - typo

The RFC says:

   Care must be take to properly encode and decode data to avoid
   attacks.  [...]

it should say:
                    vv
   Care must be taken to properly encode and decode data to avoid
   attacks.  [...]


(3) Subtle inconsistency between Section 6.1 and Section 6.2

On page 17, Section 6.1 states the Notational Convention:

   (2) Terminal symbols are strings of characters surrounded by
       double quotes.
       ^^^^^^
Nevertheless, throughout the new Section 6.2 (on page 18), all
terminal symbols, e.g. the "generalized digits" -- the terminals
to build octal, decimal, and hexadecimal constants, are specified
as characters surrounded by *single* quotes.
                             ^^^^^^
Although this style perhaps was inspired by the `C` language,
IMHO, its use is inconsistent in that context.

Notes:

from pending

RFC 4509, "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)", May 2006

Source of RFC: dnsext (int)

Errata ID: 2752
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Matt McCutchen
Date Reported: 2011-03-23
Held for Document Update by: Brian Haberman

Section RFC header says:

It should say:

Updates: 4035

Notes:

This document should update RFC 4035 because the statement in section 3, "Validator implementations SHOULD ignore DS RRs containing SHA-1 digests if DS RRs with SHA-256 digests are present in the DS RRset", modifies the rules for authenticating referrals in RFC 4035 section 5.2.

RFC 4512, "Lightweight Directory Access Protocol (LDAP): Directory Information Models", June 2006

Source of RFC: ldapbis (app)

Errata ID: 74
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-07
Held for Document Update by: Alexey Melnikov
Date Held: 2010-05-21

 

(E1)  text truncation (?)

Apparently, the text of the first paragraph of Section 3.2,
on page 18 of RFC 4512, has been truncated inadvertently.
The RFC text says:

   A subentry is a "special sort of entry, known by the Directory, used
   to hold information associated with a subtree or subtree refinement"
|  [X.501].  Subentries are used in Directory to hold for administrative
|  and operational purposes as defined in [X.501].  Their use in LDAP is
   detailed in [RFC3672].

I suspect that it should in fact say:

   A subentry is a "special sort of entry, known by the Directory, used
   to hold information associated with a subtree or subtree refinement"
|  [X.501].  Subentries are used in the Directory to hold attributes for
|  administrative and operational purposes as defined in [X.501].  Their
   use in LDAP is detailed in [RFC3672].


(E2)  typo

In Section 4.1.7.1, near the bottom of page 30, the explanation,

     FORM is specifies the name form associated with this DIT structure
         rule;

should say:

|    FORM specifies the name form associated with this DIT structure
         rule;


(E3)  typo

The first paragraph of Section 5.1, on page 36, says:

   An LDAP server SHALL provide information about itself and other
   information that is specific to each server.  This is represented as
   a group of attributes located in the root DSE, which is named with
|  the DN with zero RDNs (whose [RFC4514] representation is as the
   zero-length string).

It should say:

   An LDAP server SHALL provide information about itself and other
   information that is specific to each server.  This is represented as
   a group of attributes located in the root DSE, which is named with
|  the DN with zero RDNs (whose [RFC4514] representation is the zero-
   length string).


(E4)  word omission

The second paragraph of Section A.2.1, on page 49, says:

   The <descr> syntax was changed to disallow semicolon (U+003B)
   characters in order to appear to be consistent its natural language
   specification "descr is the syntactic representation of an object
   descriptor, which consists of letters and digits, starting with a
   letter".  In a related change, the statement "an AttributeDescription
   can be used as the value in a NAME part of an
   AttributeTypeDescription" was deleted.  RFC 2252 provided no
   specification of the semantics of attribute options appearing in NAME
   fields.

It should say:

   The <descr> syntax was changed to disallow semicolon (U+003B)
|  characters in order to appear to be consistent with its natural
   language specification "descr is the syntactic representation of an
   object descriptor, which consists of letters and digits, starting
   with a letter".
   In a related change, the statement "an AttributeDescription can be
   used as the value in a NAME part of an AttributeTypeDescription" was
   deleted.  RFC 2252 provided no specification of the semantics of
   attribute options appearing in NAME fields.


And these are my side notes for future consideration.
There are a couple of missing articles in the RFC text.
I have noted the following places:


(N1)

In Section 4.1.1, on page 24, the explanation,

   where:
     <numericoid> is object identifier assigned to this object class;
     [...]

should better say:

   where:
|    <numericoid> is the object identifier assigned to this object
         class;
     [...]


(N2)

In Section 4.1.2,

a) on page 25, the literally same correction as (N1) applies, and

b) the explanation:

     SYNTAX identifies value syntax by object identifier and may suggest
         a minimum upper bound;

should better say:

|    SYNTAX identifies the value syntax by its object identifier and may
         suggest a minimum upper bound;

c) Finally, on top of page 26, the paragraph,

   If SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING
   fields, if not specified, take their value from the supertype.

should better say:

|  If the SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING
   fields, if not specified, take their value from the supertype.


(N3)

In Section 4.1.3, on page 27, -- similarly to (N1) --
the explanation,

   where:
     <numericoid> is object identifier assigned to this matching rule;
     [...]

should better say:

   where:
     <numericoid> is the object identifier assigned to this matching
         rule;
     [...]


(N4)

In Section 4.1.7.2, on page 31, -- again like in (N1) --
the explanation,

   where:
     <numericoid> is object identifier that identifies this name form;
     [...]

should better say:

   where:
     <numericoid> is the object identifier that identifies this name
         form;
     [...]


(N5)

The final sentence of Section 4.2, i.e. the 3rd paragraph on page 33,
says:

   The following subsections provide attribute type definitions for each
   of schema definition attribute types.

It should say:

   The following subsections provide attribute type definitions for each
|  of the schema definition attribute types.

Notes:

Source: apps

Errata ID: 2281
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-07
Held for Document Update by: Peter Saint-Andre
Date Held: 2010-05-21

Section A.3 says:

The second paragraph of Section A.3, at the bottom of page 50, says:

   Section 5.1 of RFC 2256 provided the definition of the 'objectClass'
   attribute type.  This was integrated into Section 2.4.1 of this
   document.  The statement "One of the values is either 'top' or
   'alias'" was replaced with statement that one of the values is 'top'
   as entries belonging to 'alias' also belong to 'top'.

It should say:

   Section 5.1 of RFC 2256 provided the definition of the 'objectClass'
|  attribute type.  This was integrated into Section 3.3 of this
   document.  The statement "One of the values is either 'top' or
   'alias'" was replaced with statement that one of the values is 'top'
   as entries belonging to 'alias' also belong to 'top'.

Notes:

Apparently, 'Section 3.3' would have been much more appropriate than
'Section 2.4.1'.

Source: apps

RFC 4514, "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", June 2006

Source of RFC: ldapbis (app)

Errata ID: 73
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-07
Held for Document Update by: Alexey Melnikov
Date Held: 2010-05-21

Section 4 says:

   This example shows the method of escaping of a special characters
   appearing in a common name:

It should say:

   This example shows the method of escaping of special characters
   appearing in a common name:

Notes:

Source: apps

RFC 4515, "Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters", June 2006

Source of RFC: ldapbis (app)

Errata ID: 72
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-06-23
Held for Document Update by: Alexey Melnikov
Date Held: 2010-05-21

Section 4 says:

   The first example shows use of the matching rule "caseExactMatch."

It should say:

   The first example shows use of the matching rule "caseExactMatch".

Notes:

Source: apps

Errata ID: 840
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-06-23
Held for Document Update by: Alexey Melnikov
Date Held: 2010-05-21

Section 2 says:

The ASN.1 term, `AttributeValue`, has been replaced by
`AssertionValue` wherever it was used previously.
Hence, in Section 2 (on page 3) of RFC 4515

- the ASN.1 line

        AttributeValue ::= OCTET STRING

  is not needed any more and might have been omitted, and

- in the subsequent explanation, the sentence,

        [...]  The AttributeValue and AssertionValue OCTET STRING have
   the form defined in [RFC4517].  [...]

  might have been shortened to say:

        [...]  The AssertionValue OCTET STRING has the form defined ib
   [RFC4517].  [...]

Notes:

Source: apps

RFC 4516, "Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator", June 2006

Source of RFC: ldapbis (app)

Errata ID: 71
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-06-23
Held for Document Update by: Alexey Melnikov
Date Held: 2010-05-21

Section Appendix A.2 says:

   Changed the text indicate that RFC 2255 is replaced ...

It should say:

   Changed the text to indicate that RFC 2255 is replaced ...

Notes:

RFC 4519, "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", June 2006

Source of RFC: ldapbis (app)

Errata ID: 70
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-07
Held for Document Update by: Alexey Melnikov

Appendix A says:

      18. Removed Section 2.4 (Source).  Replaced the source table with
          explicit references for each definition.

It should say:

      18. Removed Section 4 (Source).  Replaced the source table with
          explicit references for each definition.

RFC 4521, "Considerations for Lightweight Directory Access Protocol (LDAP) Extensions", June 2006

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 69
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-06-22
Held for Document Update by: Peter Saint-Andre

 

(1)  Section 2.5 (page 5) -- Ref. tags

The text,
                                      vvvvvvvv
   Numerous elements of LDAP are described using ASN.1 [X.680] and are
|  encoded using a particular subset [Protocol, Section 5.2] of the
   Basic Encoding Rules (BER) [X.690].  To allow reuse of
   parsers/generators used in implementing the LDAP "core" technical
   specification [RFC4510], it is RECOMMENDED that extension elements
   (e.g., extension specific contents of controlValue, requestValue,
   responseValue fields) described by ASN.1 and encoded using BER be
|  subjected to the restrictions of [Protocol, Section 5.2].
                                     ^^^^^^^^
should say:

   Numerous elements of LDAP are described using ASN.1 [X.680] and are
|  encoded using a particular subset [RFC4511, Section 5.1] of the
   Basic Encoding Rules (BER) [X.690].  To allow reuse of
   parsers/generators used in implementing the LDAP "core" technical
   specification [RFC4510], it is RECOMMENDED that extension elements
   (e.g., extension specific contents of controlValue, requestValue,
   responseValue fields) described by ASN.1 and encoded using BER be
|  subjected to the restrictions of [RFC4511, Section 5.1].

[ Note: the tags *and* the section numbers need correction! ]


(2)  Section 3.1 (page 6), 3rd and 4th paragraph -- Ref. tags

The text:

   An existing operation MAY be extended to return IntermediateResponse
|  messages [Protocol, Section 4.13].
             ^^^^^^^^                                   vvvvvvvv
   Specifications of controls SHALL NOT attach additional semantics to
|  the criticality of controls beyond those defined in [Protocol,
   Section 4.1.11].  A specification MAY mandate the criticality take on
   a particular value (e.g., TRUE or FALSE), where appropriate.

should say:

   An existing operation MAY be extended to return IntermediateResponse
|  messages [RFC4511, Section 4.13].

   Specifications of controls SHALL NOT attach additional semantics to
|  the criticality of controls beyond those defined in [RFC4511, Section
   4.1.11].  A specification MAY mandate the criticality take on a
   particular value (e.g., TRUE or FALSE), where appropriate.


(3)  Section 3.1.2 (page 7), 3rd paragraph -- typo

The text:

   It is RECOMMENDED that designers consider alternative mechanisms for
   providing the function.  For example, an extended operation issued
   subsequent to the Start TLS operation (hence, protected by the
   security layers negotiated by the Start TLS operation) might be used
|  to provided the desired function.
             ^
should say:

   It is RECOMMENDED that designers consider alternative mechanisms for
   providing the function.  For example, an extended operation issued
   subsequent to the Start TLS operation (hence, protected by the
   security layers negotiated by the Start TLS operation) might be used
|  to provide the desired function.


(4)  Section 3.1.4 (page 8), 2nd bullet -- typo

The text:
                                                  vvvv
|     -  consistency: The resulting DIT state must be conform to schema
         and other constraints.

should say:

|     -  consistency: The resulting DIT state must conform to schema and
         other constraints.


(5)  Section 3.2 (page 8) -- Ref. tag

The text:
                        vvvvvvvv
|  Extended Operations [Protocol, Section 4.12] are the RECOMMENDED
   mechanism for defining new operations.  [...]

should say:

|  Extended Operations [RFC4511, Section 4.12] are the RECOMMENDED
   mechanism for defining new operations.  [...]


(6)  Section 3.4 (page 9), 1st paragraph -- Ref. tag

The text:
                              vvvvvvvv
|  Unsolicited notifications [Protocol, Section 4.4] offer a capability
   for the server to notify the client of events not associated with the
   operation currently being processed.

should say:

|  Unsolicited notifications [RFC4511, Section 4.4] offer a capability
   for the server to notify the client of events not associated with the
   operation currently being processed.


(7)  Section 4 (page 9) -- Ref. tags

The text:
                                  vvvvvvvv
|  LDAP allows limited extension [Protocol, Section 4] of the LDAP ASN.1
|  definition [Protocol, Appendix B] to be made.
               ^^^^^^^^
should say:

|  LDAP allows limited extension [RFC4511, Section 4] of the LDAP ASN.1
|  definition [RFC4511, Appendix B] to be made.


(8)  Section 5 (page 10), 1st paragraph -- Ref. tag

The text:

   Extensions defining LDAP schema elements SHALL provide schema
|  definitions conforming with syntaxes defined in [Models, Section
   4.1].  [...]
                                                    ^^^^^^
should say:

   Extensions defining LDAP schema elements SHALL provide schema
|  definitions conforming with syntaxes defined in [RFC4512, Section
   4.1].  [...]


(9)  Section 9.1 (page 13) -- duplicate entry

The entry at the bottom of page 13,

   [RFC4512]  Zeilenga, K., "Lightweight Directory Access Protocol
              (LDAP): Directory Information Models", RFC 4512, June
              2006.

should be deleted.
This entry is a duplicate, and it recurs on page 14, at the proper
place according to the collation order (by ascending RFC#).

Notes:

Most important issue:
Apparently, the update of the Reference tags within the text has
been performed incompletely after the assignment of RFC numbers
to those many LDAP I-Ds, leaving 'unsatisfied' tags in the text
(not listed in the References Sections), wherever these tags give
detailed citations, specifying a section or an Appendix there.

The errata detail items below are listed in textual order.
I use change bars and tag lines to emphasize the corrections
proposed and/or the issues in the original text.
Changed text is re-adjusted to conform to RFC formatting rules.

from pending

RFC 4524, "COSINE LDAP/X.500 Schema", June 2006

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 68
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-07
Held for Document Update by: Peter Saint-Andre

 

(1)  referential inconsistency

The second paragraph of Section 1, on page 3 of RFC 4524, says:

   In the years that followed, X.500 Directory Services have evolved to
   incorporate new capabilities and even new protocols.  In particular,
   the Lightweight Directory Access Protocol (LDAP) [RFC4510] was
   introduced in the early 1990s [RFC1487], with Version 3 of LDAP
   introduced in the late 1990s [RFC2251] and subsequently revised in
|  2005 [RFC4510].

It should say:

   In the years that followed, X.500 Directory Services have evolved to
   incorporate new capabilities and even new protocols.  In particular,
   the Lightweight Directory Access Protocol (LDAP) [RFC4510] was
   introduced in the early 1990s [RFC1487], with Version 3 of LDAP
   introduced in the late 1990s [RFC2251] and subsequently revised in
|  2006 [RFC4510].
      ^

(Rationale: RFC 451x and RFC 452x have been published in June 2006.)


(2)  typos

(2a) The third paragraph of Section 1, on page 3 of RFC 4524, says:

|  While much of the material in RFC 1274 has been superceded by
   subsequently published ITU-T Recommendations and IETF RFCs, [...]

It should say:
                                                        v
|  While much of the material in RFC 1274 has been superseded by
   subsequently published ITU-T Recommendations and IETF RFCs, [...]

(2b) The third paragraph of Section 1.1, on page 3, says:

   The description of the 'domain' object class provided in this
|  document supercedes that found in RFC 2247.  That is, Section 3.4 of
   this document replaces Section 5.2 of [RFC2247].

It should say:

   The description of the 'domain' object class provided in this
|  document supersedes that found in RFC 2247.  That is, Section 3.4 of
   this document replaces Section 5.2 of [RFC2247].


(3)  extraneous (duplicated) text

Within Section 3.1 of RFC 4524, the first line on page 14,

   3.3.  documentSeriesExample:

should say:

      Example:


(4)  incomplete information

Within Appendix A of RFC 4524, I miss a note describing the fate
of the 'pilotOrganization' object class (RFC 1274, Section 8.3.13).

Kurt:
  For completeness, it would be nice if you could provide
  supplementary text (similar to, and perhaps to be inserted
  after, section A.3 of RFC 4524) detailing the intentions of
  the authors regarding that object class.

Notes:

RFC 451x and RFC 452x have been published in June 2006.

from pending

RFC 4529, "Requesting Attributes by Object Class in the Lightweight Directory Access Protocol", June 2006

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 66
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-06
Held for Document Update by: Alexey Melnikov

Section 1 says:

   The control may be attached to any update operation to support
   conditional addition, deletion, modification, and renaming of the
   target object.  The asserted condition is evaluated as an integral
   part the operation.

It should say:

   The control may be attached to any update operation to support
   conditional addition, deletion, modification, and renaming of the
   target object.  The asserted condition is evaluated as an integral
|  part of the operation.
       ^^^^

Notes:

from pending

Errata ID: 853
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-06
Held for Document Update by: Alexey Melnikov
Date Held: 2010-09-02

Section 3 says:

   When the control is attached to an LDAP request, the processing of
   the request is conditional on the evaluation of the Filter as applied
   against the target of the operation.  If the Filter evaluates to
   TRUE, then the request is processed normally.  If the Filter
   evaluates to FALSE or Undefined, then assertionFailed (122)
   resultCode is returned, and no further processing is performed.

It should say:

   When the control is attached to an LDAP request, the processing of
   the request is conditional on the evaluation of the Filter as applied
   against the target of the operation.  If the Filter evaluates to
   TRUE, then the request is processed normally.  If the Filter
|  evaluates to FALSE or Undefined, then the assertionFailed (122)
   resultCode is returned, and no further processing is performed.

Notes:

Missing an article.

RFC 4534, "Group Security Policy Token v1", June 2006

Source of RFC: msec (sec)

Errata ID: 942
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Sean Turner
Date Held: 2010-08-14

Section B.5.7 says:

On page 26, defines:

     SubGCKSInfo ::= SEQUENCE {
       subGCKSScheme OBJECT IDENTIFIER,
|      sGCKSContent  OCTET STRING
     }

It should say:

Add the following clarification immediately after the ASN.1:

The OCTET STRING in each of these is an opaque blob whose
processing is subsequently defined in the vendor or domain-specific types.

Notes:

Whereas the subsequent definitions in B.5.7.{1,2} define the syntax
of two possible instantiations of SubGCKSInfo, with syntax NULL and
SEQUENCE { ... }, respectively, for the sGCKSContent element.
Again, that doesn't match!

Errata ID: 2351
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Sean Turner
Date Held: 2010-08-14

Section B.5.4 says:

On page 24, defines:

     RekeyMethod ::= SEQUENCE {
       rekeyMethodType  OBJECT IDENTIFIER,
|      rekeyMethodInfo  OCTET STRING
     }

It should say:

Add the following clarification immediately after the ASN.1:

The OCTET STRING in each of these is an opaque blob whose
processing is subsequently defined in the vendor or domain-specific types.

Notes:

Why doesn't it use the "ANY DEFINED BY ..." syntax construct for
'rekeyMethodInfo' ?

Subsequent definitions in B.5.4.{1,2} define the syntax of
two possible instantiations of RekeyMethod, with syntax NULL
and INTEGER, respectively, for the rekeyMethodInfo element.
That doesn't match!

Errata ID: 2352
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Sean Turner
Date Held: 2010-08-14

Section B.5.6 says:

On page 25, defines:

     Reliability ::= SEQUENCE {
       reliabilityMechanism   OBJECT IDENTIFIER,
|      reliabilityMechContent OCTET STRING
     }

   The reliability mechanism is defined by an OBJECT IDENTIFIER and the
   information needed to operate that mechanism is defined as
|  reliabilityMechContent and is an OCTET STRING (as before).

It should say:

Add the following clarification immediately after last paragraph:

The OCTET STRING in each of these is an opaque blob whose
processing is subsequently defined in the vendor or domain-specific types.

Notes:

whereas the subsequent definitions in B.5.6.{1,2,3} define the syntax
of three possible instantiations of Reliability, with syntax NULL,
INTEGER, and IA5String, respectively, for the reliabilityMechContent
element.
Again, that doesn't match!

Errata ID: 2371
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Tim Polk
Date Held: 2010-07-20

 

Sections B.5.6.1 and B.5.6.2, on page 25, talk about
[the reliability of] the "networks", where the text apparently
should talk about [the reliability of] the "transports"
(3 instances).

Errata ID: 2372
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section C.2 says:

In the ASN.1 module of Section C.2, the IMPORTS clause on page 31
contains an unneeded object name and ID (perhaps copied-and-pasted
from other ASN.1 modules).

The current text is:

     IMPORTS
       LifeDate
|        FROM PolicyToken {1.3.6.1.5.5.12.0.1}
|
|      KeyIdentifier
|        FROM PKIX1Implicit88 { iso(1) identified-organization(3)
|          dod(6) internet(1) security(5) mechanisms(5) pkix(7)
|          id-mod(0) id-pkix1-implicit(19) };

It should say:

This text should be shortened to just say:

     IMPORTS
       LifeDate
|        FROM PolicyToken {1.3.6.1.5.5.12.0.1};

Errata ID: 64
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Tim Polk
Date Held: 2010-07-20

 

There are three terminology issues

a)
The combination of the two roles of "Group Controller" and
"Key Server" is usually abbreviated as  "GC/KS" , and such
does RFC 4534.  Consistently, the full expansion should be
spelled  "Group Controller / Key Server"  to match the "/"
present in the acronym and to avoid the mis-understandable
unstructured word grouping, "Group Controller Key Server".

This affects Section 3.2, in the second line on page 7, and
the second line of Section B.1.1, on page 13.

b)
IMHO, the wording, "[the] rekey" is sluggish and should be
replaced by "[the] rekeying".
This affects the Section titles,
"3.3. Rekey Policy", that better should be: "3.3. Rekeying Policy"
as well as
    "B.5. GSAKMPv1 Rekey Policy"  and all
    "B.5.*. Rekey ___"  , and
    "B.6. GSAKMPv1 Rekey Policy ASN.1 Module"

Other changes:
  "rekey protocol" --> "rekeying protocol"  and
  "rekey message"  --> "rekeying message"    (Section 3, page 5),
  "Rekey SA"       --> "Rekeying SA"   and
  "During Rekey,"  --> "During Rekeying,"    (Section 3.3, page 7),
  "Rekey SAs"      --> "Rekeying SAs"        (Appendix B, page 13),
  "Rekey Protocol" --> "Rekeying Protocol" (2x) ,
  "rekey policy"   --> "rekeying policy"   (2x) ,
  "rekey messages" --> "rekeying messages" ,
  "rekey event"    --> "rekeying event"    (2x) ,
  "rekey message"  --> "rekeying message" ,
  "rekey interval" --> "rekeying interval" ,
  "rekey process"  --> "rekeying process" ,
  "the rekey"      --> "the rekeying" ,
  "rekey delivery" --> "rekeying delivery" ,
  "handle rekey."  --> "handle rekeying." ,  (all in B.5., on page 22),
  etc. ...
  "

Notes:

from pending

Errata ID: 2368
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Tim Polk
Date Held: 2010-07-20

 

Within Section B.1.3.1, the last paragraph on page 16 is unexpectedly
partially indented.

The RFC says:

   OpInfo provides configuration data for the operation of GSAKMP
       registration.  timeOut indicates the elapsed amount of time
       before a sent message is considered to be misrouted or lost.  It
       is specified as the timestamp type LifeDate, previously defined
       in the core token.  terse informs a GC/KS whether the group
       should be operated in terse (TRUE) or verbose (FALSE) mode.  The
       optional timestamp field indicates whether a timestamp (TRUE) or
       a nonce (FALSE) is used for anti-replay protection.  If the field
       is absent, the use of nonces is the default mode for GSAKMP
       registration.

It should say:

   OpInfo provides configuration data for the operation of GSAKMP
   registration.  timeOut indicates the elapsed amount of time before a
   sent message is considered to be misrouted or lost.  It is specified
   as the timestamp type LifeDate, previously defined in the core token.
   terse informs a GC/KS whether the group should be operated in terse
   (TRUE) or verbose (FALSE) mode.  The optional timestamp field
   indicates whether a timestamp (TRUE) or a nonce (FALSE) is used for
   anti-replay protection.  If the field is absent, the use of nonces is
   the default mode for GSAKMP registration.

It should say:

It should say:

   OpInfo provides configuration data for the operation of GSAKMP
   registration.  timeOut indicates the elapsed amount of time before a
   sent message is considered to be misrouted or lost.  It is specified
   as the timestamp type LifeDate, previously defined in the core token.
   terse informs a GC/KS whether the group should be operated in terse
   (TRUE) or verbose (FALSE) mode.  The optional timestamp field
   indicates whether a timestamp (TRUE) or a nonce (FALSE) is used for
   anti-replay protection.  If the field is absent, the use of nonces is
   the default mode for GSAKMP registration.

Errata ID: 2370
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Tim Polk
Date Held: 2010-07-20

 

Section B.5.4.2, on page 24, says:
                                           v
|  The GSAKMP protocol specification defined an interpretation of the
   Logical Key Hierarchy (LKH) protocol as a rekey method.  [...]

It should say:

It should say:
                                           v
|  The GSAKMP protocol specification defines an interpretation of the
   Logical Key Hierarchy (LKH) protocol as a rekey method.  [...]

Errata ID: 2369
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Tim Polk
Date Held: 2010-07-20

 

Section B.5.4.1, on page 24, says:
                                           vv       vvv
|  The group defined to work without a rekey protocols supporting it is
   supported by the rekeyMethodType NONE.  [...]

It should say:

It should say:
                                            vvvv       vv
|  The group defined to work without a rekeying protocol supporting it
   is supported by the rekeyMethodType NONE.  [...]

Errata ID: 2367
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Tim Polk
Date Held: 2010-07-20

 

In section 3.4, on page 8, the RFC says:

                                  [...].  There are several protocols
   that could make use of group keys, ranging from simple security
|  applications that only need key for encryption and/or integrity
   protection to more complex configurable security protocols such as
   IPsec and Secure Real-time Transport Protocol (SRTP) [RFC3711].  [..]

It should say:

It should say:

                                  [...].  There are several protocols
   that could make use of group keys, ranging from simple security
|  applications that only need a key for encryption and/or integrity
   protection to more complex configurable security protocols such as
   IPsec and Secure Real-time Transport Protocol (SRTP) [RFC3711].  [..]

RFC 4544, "Definitions of Managed Objects for Internet Small Computer System Interface (iSCSI)", May 2006

Note: This RFC has been obsoleted by RFC 7147

Source of RFC: ips (tsv)

Errata ID: 1638
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-04
Held for Document Update by: Lars Eggert
Date Held: 2008-12-19

 

(1)  outdated text

Within Section 6, the first paragraph on top of page 5 says:

   It is worthwhile to note that this is an iSCSI MIB module and as such
   reflects only iSCSI objects.  This module does not contain
   information about the SCSI-layer attributes of a device.  If a SCSI
|  layer is present, the SCSI MIB module, currently under development,
   may be used to manage SCSI information for a device.

The last apparently sentence is outdated.  There already is an
appropriate Informative Reference given on page 81 of the RFC.
The RFC should say:

   It is worthwhile to note that this is an iSCSI MIB module and as such
   reflects only iSCSI objects.  This module does not contain
   information about the SCSI-layer attributes of a device.  If a SCSI
|  layer is present, the SCSI MIB module [RFC4455] may be used to manage
   SCSI information for a device.
                                        ^^^^^^^^^^^


(3)  4 similar typos

The DESCRIPTION clause of the iscsiInstSsnFailures  OBJECT-TYPE,
on page 20 of RFC 4544, says:

    DESCRIPTION
        "This object counts the number of times a session belonging
|       to this instance has been failed.  If this counter has
        suffered a discontinuity, the time of the last discontinuity
        is indicated in iscsiInstDiscontinuityTime."

It should better say:

    DESCRIPTION
        "This object counts the number of times a session belonging
|       to this instance has failed.  If this counter has suffered a
        discontinuity, the time of the last discontinuity is indicated
        in iscsiInstDiscontinuityTime."

The DESCRIPTION clause of the iscsiInstSsnDigestErrors OBJECT-TYPE,
on page 22 of RFC 4544, says:

    DESCRIPTION
|       "The count of sessions that were failed due to receipt of
        a PDU containing header or data digest errors.  If this
        counter has suffered a discontinuity, the time of the last
        discontinuity is indicated in iscsiInstDiscontinuityTime."

It should better say:

    DESCRIPTION
|       "The count of sessions that failed due to receipt of
        a PDU containing header or data digest errors.  If this
        counter has suffered a discontinuity, the time of the last
        discontinuity is indicated in iscsiInstDiscontinuityTime."

The DESCRIPTION clause of the iscsiInstSsnCxnTimeoutErrors OBJECT-TYPE,
on page 22 of RFC 4544, says:

    DESCRIPTION
|       "The count of sessions that were failed due to a sequence
        exceeding a time limit.  If this counter has suffered a
        discontinuity, the time of the last discontinuity
        is indicated in iscsiInstDiscontinuityTime."

It should better say:

    DESCRIPTION
|       "The count of sessions that failed due to a sequence
        exceeding a time limit.  If this counter has suffered a
        discontinuity, the time of the last discontinuity
        is indicated in iscsiInstDiscontinuityTime."

The DESCRIPTION clause of the iscsiInstSsnFormatErrors OBJECT-TYPE,
on page 23 of RFC 4544, says:

    DESCRIPTION
|       "The count of sessions that were failed due to receipt of
        a PDU that contained a format error.  If this counter has
        suffered a discontinuity, the time of the last discontinuity
        is indicated in iscsiInstDiscontinuityTime."

It should better say:

    DESCRIPTION
|       "The count of sessions that failed due to receipt of
        a PDU that contained a format error.  If this counter has
        suffered a discontinuity, the time of the last discontinuity
        is indicated in iscsiInstDiscontinuityTime."


(4)  incomplete descriptions

Within the Target Attributes Table, the objects
    iscsiTgtLastFailureType,
    iscsiTgtLastIntrFailureName,
    iscsiTgtLastIntrFailureAddrType, and
    iscsiTgtLastIntrFailureAddr
apparently have no meaningful value if no error has occurred (yet).
The DESCRIPTION clauses for these objects, on page 38/39 of RFC 4544,
do not indicate the behaviour of these objects in this case, i.e.,
when the iscsiTgtLastFailureTime instance in a given conceptual
row has the value zero.
The respective DESCRIPTION clauses should indicate whether these
objects
  -   should not be instantiated
or
  -   have a certain default value (t.b.d.)
in this case.


A similar issue holds for the objects in the Initiator Attributes
Table,
    iscsiIntrLastFailureType,
    iscsiIntrLastTgtFailureName,
    iscsiIntrLastTgtFailureAddrType, and
    iscsiIntrLastTgtFailureAddr
(The corresponding DESCRIPTIONS can be found on page 46/47.)


(5)  row creation / storageType restriction

Various tables contain rows that can be created/deleted dynamically.
Repeatedly, for these tables the DESCRIPTION clauses for the
corresponding StorageType objects contain the sentence
(e.g., for iscsiTgtAuthStorageType, on page 44):

                                  [...].  Rows in this table that were
         created through an external process may have a storage type of
         readOnly or permanent.

It is not clear from the text what precisely 'external process'
means, and therefore it remains open whether/why the restriction
on values `readOnly` or `permanent` makes sense.


(6)  unpleasant alignment

Any future update to this RFC should correct the unpleasant
staggered tabular alignment of the following row-structure
( SEQUENCE { ... } ) declarations for:
  o  IscsiPortalAttributesEntry,
  o  IscsiInitiatorAttributesEntry, and
  o  IscsiInitiatorLoginStatsEntry


(7)  Semantic gap in Initiator Login Stats Table ??

The Initiator Login Stats Table somehow is a "dual" of the
Target Login Stats Table.
Therefore, I miss an object in the Initiator Login Stats Table
corresponding to iscsiTgtLoginAuthorizeFails, counting received
Login Response PDUs with status class 0x202.

RFC 4545, "Definitions of Managed Objects for IP Storage User Identity Authorization", May 2006

Source of RFC: ips (tsv)

Errata ID: 60
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-06-29
Held for Document Update by: Lars Eggert

 

(1)  typo in Abstract

The Abstract, on page 1 of RFC 4545, contains the sentence:

   [...]
   In particular, it defines objects for managing user identities and
|  the names, addresses, and credentials required manage access control,
   for use with various protocols.  [...]

The text should say (filling in the missing 'to'):

   In particular, it defines objects for managing user identities and
|  the names, addresses, and credentials required to manage access
   control, for use with various protocols.  [...]


(2)  typo in Section 5

The first paragraph of Section 5, on page 4 of RFC 4545, says:

   The User-based Security Model (USM) [RFC3414] also defines the
   concept of a user, defining authentication and privacy protocols and
   their credentials.  The definition of USM includes the SNMP-USER-
|  BASED-SM-MIB module allows configuration of SNMPv3 user credentials
   to protect SNMPv3 messages.  [...]

The text should say (filling in the missing 'that'):

   The User-based Security Model (USM) [RFC3414] also defines the
   concept of a user, defining authentication and privacy protocols and
   their credentials.  The definition of USM includes the SNMP-USER-
|  BASED-SM-MIB module that allows configuration of SNMPv3 user
   credentials to protect SNMPv3 messages.  [...]


(3)  clarification in Section 7

The first paragraph of Section 7, on page 5 of RFC 4545, says:

|  This MIB module structure is intended to allow the configuration of a
   list of user identities, each with a list of names, addresses,
|  credentials, and certificates that, when combined, will distinguish
   that identity.

The wording should be enhanced, and the reference to certificates
should be removed -- these apparently have been excluded from the
MIB in the published version.

Therefore, the text should perhaps better say:

|  This MIB module's structure is intended to allow the configuration of
   a list of user identities, each with a list of names, addresses, and
|  credentials that, when combined, will distinguish that identity.


(4)  improper DESCRIPTION text

The DESCRIPTION clause for the ipsAuthIdentAddrAttributesTable
OBJECT-TYPE, on page 19, says:

       DESCRIPTION
           "A list of address ranges that are allowed to serve
           as the endpoint addresses of a particular identity.
           An address range includes a starting and ending address
|          and an optional netmask, and an address type indicator,
           which can specify whether the address is IPv4, IPv6,
           FC-WWPN, or FC-WWNN."

This text improperly mentions the use of netmasks, which has been
explicitely excluded from the MIB module, as can be seen from the
subsequent IpsAuthIdentAddrAttributesEntry syntax, and as explained
in the last paragraph of Section 7.5, on page 8 of the RFC.

Therefore, this clause should say:

       DESCRIPTION
           "A list of address ranges that are allowed to serve
           as the endpoint addresses of a particular identity.
           An address range includes a starting and ending address,
|          and an address type indicator, which can specify whether
           the address is IPv4, IPv6, FC-WWPN, or FC-WWNN."


(5)  redundant MIB objects -- serious danger of inconsistency

Conceptually, rows of the ipsAuthCredChap, ipsAuthCredSrp, and
ipsAuthCredKerberos tables are a variant record (union in "C")
contained in the corresponding rows of the ipsAuthCredential table.
The DESCRIPTION clauses make clear, that the 'life' of the former
table rows is directly coupled to the 'life' of the latter rows --
for example, the DESCRIPTION clause of the ipsAuthCredAuthMethod
OBJECT-TYPE says:

           When a row is created in this table, a corresponding
           row must be created by the management station
           in a corresponding table specified by this value.

           When a row is deleted from this table, the corresponding
           row must be automatically deleted by the agent in
           the corresponding table specified by this value.

IMHO, it is inconsistent to have the agent delete the row, but
let the management station create the row; the SETting of an
ipsAuthCredAuthMethod object should create the corresponding row.
According to this explanantion and the identical indexing structure
of the four tables, the agent thus is directed to maintain exactly
one of those variant rows, matching the current value of a given
ipsAuthCredAuthMethod instance.

In the published version of the IPS-AUTH-MIB module, the rows
of the basic ipsAuthCredentialAttributesTable contains objects of
RowStatus and StorageType syntax that are used to create/activate/
delete an ipsAuthCredentialAttributesEntry conceptual row, and to
specify the persistence behaviour of that row, respectively.

Therefore, IMHO it makes no sense, and it entails the danger of
fundamental semantic inconsistencies in the MIB module, to also
maintain objects of RowStatus and StorageType syntax in the
variant table rows.
E.g.,
- no `active` row can exist in the ipsAuthCredChapAttributesTable
  without a corresponding `active` row in the
  ipsAuthCredentialAttributesTable;
- no ipsAuthCredChapAttributesEntry can be created by the manager,
  that MUST be done automatically by the agent when the
  ipsAuthCredAuthMethod instance is set to ipsAuthMethodChap;
- the ipsAuthCredentialAttributesEntry should be set inactive,
  if desired, and not the ipsAuthCredChapAttributesEntry;
- the StorageType of both entries MUST be exactly the same.

Therefore, IMHO the objects
  o   ipsAuthCredChapRowStatus,
  o   ipsAuthCredChapStorageType,
  o   ipsAuthCredSrpRowStatus,
  o   ipsAuthCredSrpStorageType,
  o   ipsAuthCredKerbRowStatus,  and
  o   ipsAuthCredKerbStorageType
should be deprecated as soon as possible, and its MAX-ACCESS
changed to read-only, with explanation added to the DESCRIPTION
clauses that the values of these objects (if implemented), are
agent maintained mirrors of the corresponding ipsAuthCredRowStatus
and ipsAuthCredStorageType objects, respectively.

Additionally, it should be specified that a ipsAuthCredRowStatus
instance must not be set to `active` unless the proper credentials
have been set in the appropriate ipsAuthCred* "detail" row.

If it is decided that automatic row creation by the agent should
not be specified for backwards compatibility, at least the
ipsAuthCred*StorageType objects should be deprecated.


(6)  clarification in compliance statement

The DESCRIPTION clause of the ipsAuthComplianceV1 MODULE-COMPLIANCE
says:

       DESCRIPTION
           "Initial version of compliance statement based on
           initial version of this MIB module.

           The Instance and Identity groups are mandatory;
           at least one of the other groups (Name, Address,
|          Credential, Certificate) is also mandatory for
           any given implementation."

Similar to item (3) above, the reference to 'Certificate' is
inappropriate and should be deleted; additionally, the plural
form of 'Credential' should be used.

Thus, this clause should say:

       DESCRIPTION
           "Initial version of compliance statement based on
           initial version of this MIB module.

           The Instance and Identity groups are mandatory;
           at least one of the other groups (Name, Address,
|          Credentials) is also mandatory for any given
           implementation."


(7)  incomplete citations

The following References are incomplete according to RFC-Ed policy;
they should be amended by  "STD 62, "  just before the RFC number.

In Section 11, on page 40, the entry:

   [RFC3411]  Harrington, D., Presuhn, R., and B. Wijnen, "An
              Architecture for Describing Simple Network Management
              Protocol (SNMP) Management Frameworks", RFC 3411, December
              2002.

should say:

   [RFC3411]  Harrington, D., Presuhn, R., and B. Wijnen, "An
              Architecture for Describing Simple Network Management
              Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
              December 2002.

In Section 12, on page 41, the entry:

   [RFC3414]  Blumenthal, U. and B. Wijnen, "User-based Security Model
              (USM) for version 3 of the Simple Network Management
              Protocol (SNMPv3)", RFC 3414, December 2002.

should say:

   [RFC3414]  Blumenthal, U. and B. Wijnen, "User-based Security Model
              (USM) for version 3 of the Simple Network Management
              Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.

Notes:

I make use of change bars ('|' in column 1) to emphasize the
location of textual issues and/or proposed textual changes.
Modified text is re-adjusted according to RFC formatting rules.

The items below are listed (and enumerated) in RFC text sequence.
Item (5) apparently is a serious issue.
All other items are simple errata.

from pending

RFC 4556, "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", June 2006

Note: This RFC has been updated by RFC 6112, RFC 8062, RFC 8636

Source of RFC: krb-wg (sec)

Errata ID: 3157
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Tom Yu
Date Reported: 2012-03-15
Held for Document Update by: Stephen Farrell

Section 3.2.1 says:

   8.  The client's Diffie-Hellman public value (clientPublicValue) is
       included if and only if the client wishes to use the Diffie-
       Hellman key agreement method.  The Diffie-Hellman domain
       parameters [IEEE1363] for the client's public key are specified
       in the algorithm field of the type SubjectPublicKeyInfo
       [RFC3279], and the client's Diffie-Hellman public key value is
       mapped to a subjectPublicKey (a BIT STRING) according to
       [RFC3279].  When using the Diffie-Hellman key agreement method,
       implementations MUST support Oakley 1024-bit Modular Exponential
       (MODP) well-known group 2 [RFC2412] and Oakley 2048-bit MODP
       well-known group 14 [RFC3526] and SHOULD support Oakley 4096-bit
       MODP well-known group 16 [RFC3526].

       The Diffie-Hellman field size should be chosen so as to provide
       sufficient cryptographic security [RFC3766].

       When MODP Diffie-Hellman is used, the exponents should have at
       least twice as many bits as the symmetric keys that will be
       derived from them [ODL99].

It should say:

   8.  The client's Diffie-Hellman public value (clientPublicValue) is
       included if and only if the client wishes to use the Diffie-
       Hellman key agreement method.  The Diffie-Hellman domain
       parameters [IEEE1363] for the client's public key are specified
       in the algorithm field of the type SubjectPublicKeyInfo
       [RFC3279], and the client's Diffie-Hellman public key value is
       mapped to a subjectPublicKey (a BIT STRING) according to
       [RFC3279].  When using the Diffie-Hellman key agreement method,
       implementations MUST support Oakley 1024-bit Modular Exponential
       (MODP) well-known group 2 [RFC2412] and Oakley 2048-bit MODP
       well-known group 14 [RFC3526] and SHOULD support Oakley 4096-bit
       MODP well-known group 16 [RFC3526].

       Some implementations are known to omit the mandatory Q value
       from the DomainParameters (in the algorithm value of the
       clientPublicValue) when using the well-known MODP groups 14 and
       16, which can cause an ASN.1 decoding error for the
       DomainParamters value.  While [RFC3526] does not explicitly
       specify the Q value for the well-known MODP groups 14 and 16,
       the prime modulus of each of these groups is a safe prime --
       having the form P = 2Q + 1, where P and Q are prime.
       Therefore, the Q value for each of these moduli is the
       corresponding Sophie Germain prime, and it is equal to (P-1)/2.

       The Diffie-Hellman field size should be chosen so as to provide
       sufficient cryptographic security [RFC3766].

       When MODP Diffie-Hellman is used, the exponents should have at
       least twice as many bits as the symmetric keys that will be
       derived from them [ODL99].

Notes:

The new paragraph identifies an interoperability problem where an
implementation omits the Q value (required in the DomainParameters
type defined in RFC3370) of a Diffie-Hellman group when participating
in PKINIT. This happens for two well-known IKEv2 MODP groups that are
defined in RFC3526, probably because RFC3526 does not explicitly state
the Q values for the moduli. The moduli are safe primes, so the new
text specifies how to compute their Q values (which are the
corresponding Sophie Germain primes).

RFC 4557, "Online Certificate Status Protocol (OCSP) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", June 2006

Source of RFC: krb-wg (sec)

Errata ID: 58
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tom Petch
Date Reported: 2006-10-31
Held for Document Update by: Sean Turner

Section 3 says:

The corresponding padata-value field [RFC4120] contains the DER [X60]
   encoding of the following ASN.1 type:

It should say:

The corresponding padata-value field [RFC4120] contains the DER [X690]
   encoding of the following ASN.1 type:

RFC 4566, "SDP: Session Description Protocol", July 2006

Note: This RFC has been obsoleted by RFC 8866

Source of RFC: mmusic (rai)

Errata ID: 1795
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Leandro Lucarella
Date Reported: 2009-06-19
Held for Document Update by: Robert Sparks

Section 9 says:

   decimal-uchar =       DIGIT
                         / POS-DIGIT DIGIT
                         / ("1" 2*(DIGIT))
                         / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT)
                         / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5"))

It should say:

   decimal-uchar =       DIGIT
                         / POS-DIGIT DIGIT
                         / ("1" 2(DIGIT))
                         / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT)
                         / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5"))

Notes:

The "*" is removed from the 3rd line.

The current RFC accepts any number starting with "1" and followed by
2 or more digits (like 1000 or 123456789) as a valid "decimal-uchar"
because of this error, because "1" 2*(DIGIT) means 2 or more digits
following a "1". The correction, 2(DIGIT) means *exactly* 2 digits
following a "1", which covers the range 100-199.

Errata ID: 2517
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Victor S. Osipov
Date Reported: 2010-09-13
Held for Document Update by: Robert Sparks

Section 5.14 says:

If the <proto> sub-field is "RTP/AVP" or "RTP/SAVP" the <fmt> 
sub-fields contain RTP payload type numbers.  When a list of 
payload type numbers is given, this implies that all of these 
payload formats MAY be used in the session, but the first of these 
formats SHOULD be used as the default format for the session.

It should say:

If the <proto> sub-field is "RTP/AVP" or "RTP/SAVP" the <fmt> 
sub-fields contain RTP payload type numbers.  When a list of 
payload type numbers is given, this implies that all of these 
payload formats MAY be used in the session, and these payload 
formats are listed in order of preference, with the first format listed 
being preferred; in that case the first acceptable payload format 
from the beginning of the list SHOULD be used for the session.

Notes:

The word ‘default‘ is improper here, because payload format is not implied, but explicitly indicated. This may lead to a misunderstanding and confusion.
The corrections are proposed in order to avoid confusion and to give complete clear instructions in case of multiple payload type numbers indicated.

Errata ID: 4903
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Jxck
Date Reported: 2017-01-12
Held for Document Update by: Orie Steele
Date Held: 2024-04-01

Section 9 says:

   ; SDP Syntax
   session-description = proto-version
                         origin-field
                         session-name-field
                         information-field
                         uri-field
                         email-fields
                         phone-fields
                         connection-field
                         bandwidth-fields
                         time-fields
                         key-field
                         attribute-fields
                         media-descriptions

   connection-field =    [%x63 "=" nettype SP addrtype SP
                         connection-address CRLF]
                         ;a connection field must be present
                         ;in every media description or at the
                         ;session-level

   media-descriptions =  *( media-field
                         information-field
                         *connection-field
                         bandwidth-fields
                         key-field
                         attribute-fields )

It should say:

   ; SDP Syntax
   session-description = proto-version
                         origin-field
                         session-name-field
                         information-field
                         uri-field
                         email-fields
                         phone-fields
                         [connection-field]
                         bandwidth-fields
                         time-fields
                         key-field
                         attribute-fields
                         media-descriptions

   connection-field =    %x63 "=" nettype SP addrtype SP
                         connection-address CRLF
                         ;a connection field must be present
                         ;in every media description or at the
                         ;session-level

   media-descriptions =  *( media-field
                         information-field
                         *connection-field
                         bandwidth-fields
                         key-field
                         attribute-fields )

Notes:

in BNF of SDP,
connection-field itself is optional [0, 1], but media-description has multiple [0,) connection-field.
it seems conflict, because multiple of optional fields doesn't finish because multiple filed can't find when to end.

so change connection-field itself not optional (remove []) and, replace session-descriptions connection-field as optional.

RFC 4567, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", July 2006

Source of RFC: mmusic (rai)

Errata ID: 56
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Held for Document Update by: Robert Sparks

The abstract says:

   General guidelines are also given on how the framework should be used
   together with SIP and RTSP.  The usage with the Multimedia Internet
   KEYing (MIKEY) key management protocol is also defined.

It should say:

   General guidelines are also given on how the framework should be used
   together with SIP and SAP.  The usage with the Multimedia Internet
   KEYing (MIKEY) key management protocol is also defined.

Notes:

As can be seen from the title and the body of the RFC, and
as has been correctly stated in the first paragraph of the Abstract,
the RFC primarily deals with SDP and RTSP; it "also" considers the use
of the SDP extensions with SIP (Section 4.1.2) and SAP (Section 4.1.3).
Hence, SAP should be mentioned in the second paragraph of the Abstract
instead of RTSP.

Errata ID: 809
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Held for Document Update by: Robert Sparks

 

(1) [[posted separately.]]
 
(2)  inappropriate text (cut&paste error?)

On page 6, the explanation below the ABNF in Section 3.2 says:

   where KMPID is as defined in Section 3 of this memo, "base64" as
   defined in [SDPnew], and "URI" as defined in Section 3 of [RFC3986].

It should say:

   where KMPID is as defined in Section 3 of this memo and "URI" as
   defined in Section 3 of [RFC3986].

Rationale: "base64" does not appear in the ABNF of Section 3.2 !


(3)  incomplete sentence

The first paragraph of Section 4.1.1, on page 8, says:

   The processing when SDP is used is slightly different according to
   the way SDP is transported, and if it uses an offer/answer or
   announcement.  The processing can be divided into four different
   steps:

It should say:

   The processing when SDP is used is slightly different according to
   the way SDP is transported, and if it uses an offer/answer or
|  announcement model.  The processing can be divided into four
   different steps:


(4)  misleading word omission

Within Section 5.4, the explanation at top of page 21,

   Each RTSP header is inserted in the SETUP related to the audio and
   video separately:

should be clarified to say:

|  A key management RTSP header is inserted in the SETUP related to the
   audio and video separately:


(5)  suspected inconsistency

The last paragraph of Section 7, on page 22, says:

   The server will need to be able to know the identity of the client
   before creating and sending a MIKEY message.  [...]

IMHO, it is not clear how this fits with the text on page 14.
Perhaps, a 3-way handshake with client auth in DESCRIBE could
be considered.


(6)  inconsistency between ABNF and IANA registrations

Perhaps, a late change to the ABNF in the body of the RFC has lead
to inconsistencies in the filled out IANA registration templates
as presented in Section 9.1 and 9.3; in particular, the hypothetical
attribute name "key-mgmt-att-field" referred to in fact should be just
"key-mgmt"; "key-mgmt-att-field" is the name of the ABNF production
rule (introduced in  Section 3.1) for this literal; in the template
the literal name of the attribute is needed.

Therefore:

In Section 9.1, near the bottom of page 25, change

      SDP Attribute Field ("att-field"):

        Name:               key-mgmt-att-field

to say:

      SDP Attribute Field ("att-field"):

        Name:               key-mgmt

and in Section 9.3, on page 26, change

   Purpose:        Usage of MIKEY with the key-mgmt-att-field
                    attribute and the keymgmt RTSP header

to say:

|  Purpose:        Usage of MIKEY with the key-mgmt SDP attribute
                    and the keymgmt RTSP header

[ I also have added "SDP" for additional clarification. ]


(7)  missing articles

The first paragraph of the Abstract, on page 1 of RFC 4567, says:

   This document defines general extensions for Session Description
   Protocol (SDP) and Real Time Streaming Protocol (RTSP) to carry
   messages, as specified by a key management protocol, in order to
   secure the media.  [...]

It should say:

|  This document defines general extensions for the Session Description
|  Protocol (SDP) and the Real Time Streaming Protocol (RTSP) to carry
   messages, as specified by a key management protocol, in order to
   secure the media.  [...]


(8)  missing article

Near the top of page 7, the paragraph,

   We define one new RTSP status code to report error due to any failure
   during the key management processing (Section 4.2):

should say:

|  We define one new RTSP status code to report an error due to any
   failure during the key management processing (Section 4.2):


(9)  missing article

Within Section 4.2, the last bullet on page 15 says:

   * Key management responses for the initial establishment of security
     parameters for an individual media SHALL only be included in SETUP
     for the corresponding media stream.

It should say:

   * Key management responses for the initial establishment of security
|    parameters for an individual media SHALL only be included in the
     SETUP for the corresponding media stream.


(10)  typo (singular/plural mismatch)

Within Section 5.2, the explanation of the example, in the lower
half of page 19,

   The client checks the validity of the received MIKEY message, and, in
   case of successful verification, it accept the message.  [...]

should say:

   The client checks the validity of the received MIKEY message, and, in
|  case of successful verification, it accepts the message.  [...]

Notes:

from pending

RFC 4571, "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport", July 2006

Source of RFC: avt (rai)

Errata ID: 54
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-11
Held for Document Update by: Robert Sparks

Section 1 says:

   The Audio/Video Profile (AVP, [RFC3550]) for the Real-time Transport
   Protocol (RTP, [RFC3551]) does not define a method for framing RTP
   and RTP Control Protocol (RTCP) packets onto connection-oriented
   transport protocols (such as TCP).  However, earlier versions of

It should say:

   The Audio/Video Profile (AVP, [RFC3551]) for the Real-time Transport
   Protocol (RTP, [RFC3550]) does not define a method for framing RTP
   and RTP Control Protocol (RTCP) packets onto connection-oriented
   transport protocols (such as TCP).  However, earlier versions of

Notes:

Apparently, the RFC numbers have been permuted inadvertently.

RFC 4577, "OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)", June 2006

Source of RFC: l3vpn (int)

Errata ID: 4659
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Chao Fu
Date Reported: 2016-04-08
Held for Document Update by: Martin Vigoureux
Date Held: 2018-05-22

Section 4.1.4 says:

   If a PE attaches to a CE via a link that is in a non-zero area, then
   the PE serves as an ABR for that area.

It should say:

   PE always serves as an ABR if it attaches to a CE.

Notes:

Even the PE attaches to a CE via a link that is in backbone area, it should also be thought as an ABR. Otherwise the CE cannot calculate the type 3 LSAs from PE because there is no ABR.

Section 4.2.3 has the similar description and should also be updated:
"If a PE has a link that belongs to a non-zero area, the PE functions
as an Area Border Router (ABR) for that area."

--VERIFIER'S NOTES--
After discussing with authors, a more preferred revision of the text could be:
Since OSPF VPN-IPv4 routes are advertised as inter-area summary (type 3) LSAs, a PE will act as an ABR for attached CEs.

Errata ID: 53
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Held for Document Update by: Ralph Droms
Date Held: 2013-03-12

 

(2)  [orphaned inter-section references]

Section 4.2.4 of RFC 4577 contains three (3) distinct references
to itself.  This cannot have been intended.

Within Section 4.2.2, the last two paragraphs on page 11 say:

                                                           vvvvv
   A Domain Identifier is an eight-byte quantity that is a valid BGP
|  Extended Communities attribute, as specified in Section 4.2.4.  If a
   particular OSPF instance has a non-NULL Domain Identifier, when
   routes from that OSPF instance are distributed by BGP as VPN-IPv4
   routes, the routes MUST carry the Domain Identifier Extended
   Communities attribute that corresponds to the OSPF instance's Primary
   Domain Identifier.  If the OSPF instance's Domain Identifier is NULL,
   the Domain Identifier Extended Communities attribute MAY be omitted
   when routes from that OSPF instance are distributed by BGP;
   alternatively, a value of the Domain Identifier Extended Communities
|  attribute that represents NULL (see Section 4.2.4) MAY be carried
   with the route.
                                               ^^^^^
   If the OSPF instances of an OSPF domain are given one or more non-
   NULL Domain Identifiers, this procedure allows us to determine
   whether a particular OSPF-originated VPN-IPv4 route belongs to the
   same domain as a given OSPF instance.  We can then determine whether
   the route should be redistributed to that OSPF instance as an inter-
   area route or as an OSPF AS-external route.  Details can be found in
|  Sections 4.2.4 and 4.2.8.1.
            ^^^^^

I am not sure what really was intended to say.  Perhaps, the
second instance of "4.2.4" should be replaced by "4.2.6".

Please check and supply corrected text.

Notes:

The references to section 4.2.4 should be changed to 4.2.6

Errata ID: 3110
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Held for Document Update by: Stewart Bryant
Date Held: 2012-02-07

 

(1)  [typo?]

Section 4.2.1 of RFC 4577, in the last paragraph on page 9, says:

   Generally, though not necessarily, if the PE attaches to several CEs
   in the same OSPF domain, it will associate the interfaces to those
   PEs with a single VRF.

I strongly suspect that the final "PEs" is a typo, and should be
replaced by "CEs".
Thus, the RFC should say:

   Generally, though not necessarily, if the PE attaches to several CEs
   in the same OSPF domain, it will associate the interfaces to those
|  CEs with a single VRF.


(3)  [typo: punctuation]

Section 4.2.7 of RFC 4577, on page 16, says:

   This section describes the protocol and procedures necessary for the
|  support of "Sham Links," as defined herein.  Support for sham links
   is an OPTIONAL feature of this specification.

It should say:

   This section describes the protocol and procedures necessary for the
|  support of "Sham Links", as defined herein.  Support for sham links
   is an OPTIONAL feature of this specification.


(4)  [typo: grammar]

In Section 4.2.7.1, the last paragraph on page 16 says:

   If it is desired to have OSPF prefer the routes through the backbone
   over the routes through the backdoor link, then the routes through
|  the backbone must be appear to be intra-area routes.  [...]
                ^^^^^^^^^^^^^^

It should say:

   If it is desired to have OSPF prefer the routes through the backbone
   over the routes through the backdoor link, then the routes through
|  the backbone must appear to be intra-area routes.  [...]
                ^^^^^^^^^^^

(5)  [typo: inconsistent spelling/capitalization]

In Section 4.2.7.1, the second paragraph on page 17 contains
the sentence:
                                           vvvvvvvvv
                             [...].  If the VRF is associated with only
|  a single OSPF instance, and if the PE's router id in that OSPF
   instance is an IP address, then the Sham Link Endpoint Address MAY
   default to that Router ID.  [...]

Consistently with all other occurrences of the term, "Router ID"
in this memo, it should say:

                             [...].  If the VRF is associated with only
|  a single OSPF instance, and if the PE's Router ID in that OSPF
   instance is an IP address, then the Sham Link Endpoint Address MAY
   default to that Router ID.  [...]


(6)  [word omission]

The 4th paragraph of Section 4.2.7.2, near the bottom of page 17,
says:

   A sham link connecting two VRFs is considered up if and only if a
   route to the 32-bit remote endpoint address of the sham link has been
|  installed in VRF.

It should say:

   A sham link connecting two VRFs is considered up if and only if a
   route to the 32-bit remote endpoint address of the sham link has been
|  installed in the VRF.

Notes:

from pending

RFC 4583, "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", November 2006

Note: This RFC has been obsoleted by RFC 8856

Source of RFC: mmusic (rai)

Errata ID: 712
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-12-30
Held for Document Update by: Robert Sparks

 

(1)  [clarification]

Section 4 of RFC 4583, near the top of page 4, says:

   If an 'm' line in an offer contains a 'floorctrl' attribute, the
   answerer MUST include one in the corresponding 'm' line in the
   answer.  [...]

It should better say:

   If a SDP media description in an offer contains a 'floorctrl'
   attribute, the answerer accepting that media MUST include one in the
   corresponding media description of the answer.  [...]


(2)  [clarification]

Section 6 of RFC 4583, on mid-page 5, says:

   The 'floorid' attribute is used in BFCP 'm' lines.  [...]

It should better say:

   The 'floorid' attribute is used in the SDP media description for BFCP
   media.  [...]


Please comment.

It should say:

[not submitted]

Notes:

It's always the abuse of language, talking about an SDP attribute
as being used "in" an SDP 'm' line, where in fact the attribute is
just a media-level attribute, occurring as a standalone line in an
SDP media description, i.e. the SDP part introduced by the particular
'm' line.

This is, at best, a bit confusing.

from pending

RFC 4586, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback: Results of the Timing Rule Simulations", July 2006

Source of RFC: avt (rai)

Errata ID: 50
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-17
Held for Document Update by: Robert Sparks

Section 4.1 says:

   We can see that in configurations where both agents use the new
   timing rules each of them uses, at most, about 2.5% of the session
   bandwidth for RTP, which sums up to 5% of the session bandwidth for
   both.

It should say:

   We can see that in configurations where both agents use the new
   timing rules each of them uses, at most, about 2.5% of the session
   bandwidth for RTCP, which sums up to 5% of the session bandwidth for
   both.  

Notes:

RTP -> RTCP

from pending

Errata ID: 766
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-17
Held for Document Update by: Cullen Jennings

Section 7.3 says:

|  We have shown that the limitations of RTP AVPF profile do not
   generate such high delay in the feedback messages that the
   performance of NEWPRED is degraded for sessions from 32 kbps to 2
   Mbps.

It should say:

|  We have shown that the limitations of the RTP AVPF profile do not
   generate such high delay in the feedback messages that the
   performance of NEWPRED is degraded for sessions from 32 kbps to 2
   Mbps.  

Notes:

missing article

from pending

RFC 4587, "RTP Payload Format for H.261 Video Streams", August 2006

Source of RFC: avt (rai)

Errata ID: 49
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-31
Held for Document Update by: Robert Sparks

 

(1)  "Updates" relationship missing in RFC header & RFC index

In the Introduction (3rd paragraph on page 3) the RFC says:

   This document obsoletes RFC 2032 and updates the "video/h261" media
   type that was registered in RFC 3555.

Similar wording is in Section 6.1 (see below).

Therefore, I expect that the RFC heading should have been amended
by a "Updates: 3555" line, and that this relationship be visible in
the RFC index.


(2)  Misleading packetization specification

On page 4, in the first paragraph of Section 3.2, RFC 4587 says:

   [..].  The 512-bit frames are then interlaced with an audio stream
   and transmitted over px 64 kbps circuits according to specification
   H.221 [H221].
                        ^^^^^^^^^^

For clarity, it should say:

   [..].  The 512-bit frames are then interlaced with an audio stream
   and transmitted over p x 64 kbps circuits according to specification
   H.221 [H221].
                        ^^^^^^^^^^^

(and/or replace the 'x' by an asterisk, '*' !)

(2')
The same issue recurs on page 15, in the first item of Section 11.1,
the Normative Reference, [H261] .


(3)  Improper frequency specification

According to the applicable ISO standards on Measures and Weights,
there is never a special sign to be written between the numeric value
and the physical unit of any dimensioned physical value.
(Preferrably, there should not even be any white space between.)

Therefore, in Section 4.1 of RFC 4587, at the bottom of page 5,
where the RFC says:

         [...].  For H.261 video streams, the RTP timestamp is based on
|    a 90-kHz clock.  This clock rate is a multiple of the natural H.261
     frame rate (i.e., 30000/1001 or approximately 29.97 Hz).  [...]

it in fact should say:

         [...].  For H.261 video streams, the RTP timestamp is based on
|    a 90 kHz clock.  This clock rate is a multiple of the natural H.261
     frame rate (i.e., 30000/1001 or approximately 29.97 Hz).  [...]

(Rigorous application of the above principles, taking 'bit' as a unit
specification, would also forbid data amount spellings like "512-bit"
in item (2) above!)


(4)  misaligned 'ruler lines' above data format diagrams

According to legacy and current RFC author guidelines, the ruler lines
above the two data format diagrams on page 6 (within Section 4.1):

|      0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

should be indented as follows:

|       0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


(5)  improper wording (2 instances)

Near the top of page 7, the explanations for the (I) and (V) bits
both contain the sentence:

                   vvvvvvv
       [...].  The meaning of this bit should not be changed during the
      course of the RTP session.

This is abuse of language.
The *meaning* of the bit -- i.e., the bit *values* -- is given in the
text preceding the quoted sentence, and thus intrinsically cannot be
changed during the course of the RTP session.
What in fact should not be changed during the RTP session is the
*value* of these bits!

Therefore, the RFC should say (in both places):

                   vvvvv
|      [...].  The value of this bit should not be changed during the
      course of the RTP session.


(6)  typo

In Section 5, on page 9, the last sentence of the bullet (3) says:

                                [...].  This mode is particularly
        efficient in point-to-point connection or when the number of
        decoders is low.

It should say:
                                [...].  This mode is particularly
|       efficient in a point-to-point connection or when the number of
        decoders is low.

or:
                                [...].  This mode is particularly
|       efficient in point-to-point connections or when the number of
        decoders is low.


(7)  misleading section headlines

In the RFC text, Section

  6.  IANA Considerations

contains the following sub-sections:

  6.1.  Media Type Registrations

  6.1.1.  Registration of MIME Media Type video/H261

  6.2.  SDP Parameters

  6.2.1.  Usage with the SDP Offer Answer Model

Only Section 6.1[.1] contains information addressed to the IANA.
Therefore, for clarity (and to avoid undue burden for the IANA),
the first two of the headlines quoted above should effectively be
exchanged.  And, there is only one (1) registration!
Hence, singular should be used.

Furthermore, the text of Section 6.1 contains improper wording
and has no trailing fullstop (dot) character:

|  This section describes the media types and names associated with this
|  payload format.  The section updates the previous registered version
   in RFC 3555 [RFC3555].  This registration uses the template defined
|  in RFC 4288 [RFC4288]

Thus, the headline

6.  IANA Considerations

should be corrected to say, e.g.:

6.  Media Type video/H261

and

6.1.  Media Type Registrations

   [... paragraph quoted above ... ]

should be replaced by:

6.1  IANA Considerations

|  This section describes the media type and parameters associated with
|  this payload format.  It updates the previous registered version in
   RFC 3555 [RFC3555].  This registration uses the template defined
|  in RFC 4288 [RFC4288].


(8)  typo

The last sentence (of the last bullet) of Section 6.2, on page 12,
says:
                                     [...].  These parameters are
      expressed as a MIME media type string, in the form of as a
      semicolon-separated list of parameters
                                                           ^^^^
It should say:
                                     [...].  These parameters are
|     expressed as a MIME media type string, in the form of a
      semicolon-separated list of parameters


(9)  typo and misleading wording in Section 6.2.1

The first paragraph of Section 6.2.1, on page 12, says:

   When H.261 is offered over RTP using SDP in an Offer/Answer model
   [RFC3264] the following considerations are necessary.

This could easily be misunderstood as talking about an
'SDP offer over RTP'.
The RFC should say instead (exchanging two pairs of words):

   When H.261 over RTP is offered using SDP in an Offer/Answer model
   [RFC3264] the following considerations are necessary.

Subsequently, the paragraph with the headline "Picture sizes and MPI",

   Supported picture sizes and their corresponding minimum picture
   interval (MPI) information for H.261 can be combined.  All picture
   sizes may be advertised to the other party, or only a subset of it.
   Using the recvonly or sendrev direction attribute, a terminal SHOULD
   announce those picture sizes (with their MPIs) that it is willing to
   receive.  For example, CIF=2 means that receiver can receive a CIF
   picture and that the frame rate SHALL be less then 15 frames per
   second.

Should be corrected and clarified to say:

   Supported picture sizes and their corresponding minimum picture
   interval (MPI) information for H.261 can be combined.  All picture
   sizes may be advertised to the other party, or only a subset of it.
|  Using the recvonly or sendrec direction attribute, a terminal SHOULD
   announce those picture sizes (with their MPIs) that it is willing to
|  receive.  For example, CIF=2 means that the SDP sender can receive a
   CIF picture and that the frame rate SHALL be less then 15 frames per
   second.

(There is no 'sendrev' direction attribute, and it is important to
explicitely differentiate between senders and receivers of SDP and
media, respectively!)

Finally, the second paragraph on page 13,

   An example of media representation in SDP is as follows CIF at 15
   frames per second, QCIF at 30 frames per second and annex D

should better say:

|  An example of media representation in SDP is as follows:
   CIF at 15 frames per second, QCIF at 30 frames per second and annex D

or, perhaps even better:

|  An example of media representation in SDP, for CIF at 15 frames per
|  second, QCIF at 30 frames per second and annex D, is as follows:

Notes:

from pending

RFC 4592, "The Role of Wildcards in the Domain Name System", July 2006

Source of RFC: dnsext (int)

Errata ID: 46
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Held for Document Update by: Brian Haberman

 

(1)  [improper/misleading wording]

In the explanations to the Example in Section 2.2.1, RFC 4592
(near the top of page 9) says:

|  The following responses would not be synthesized from any of the
|  wildcards in the zone:

This wording is improper/misleading.
Perhaps, the RFC should better say:

|  The following queries would not cause RRs to be synthesized for the
|  answer from any of the wildcards in the zone:


(2)  [typo]

The last paragraph of Section 2.2.2, on page 10, says:

   As RFC 1034 also defines "an authoritative name error indicating that
|  the name does not exist" in section 4.3.1, so this apparently is not
   the intent of the original definition, justifying the need for an
   updated definition in the next section.

"As ..., so ..." is redundant.
Thus, the RFC should say instead:

   As RFC 1034 also defines "an authoritative name error indicating that
|  the name does not exist" in section 4.3.1, this apparently is not the
   intent of the original definition, justifying the need for an updated
   definition in the next section.


(3)  [typo]

In Section 3.3.1, the 4th paragraph, on page 12, says:

   A source of synthesis does not guarantee having a RRSet to use for
   synthesis.  The source of synthesis could be an empty non-terminal.

It should say:

|  A source of synthesis does not guarantee having an RRSet to use for
   synthesis.  The source of synthesis could be an empty non-terminal.


(4)  [typo]

In Section 3.3.3, the last paragraph on page 13 says:

   This is essentially the same text in part 'a' covering the processing
   of CNAME RRSets.

It should say:

|  This is essentially the same text as in part 'a' covering the
   processing of CNAME RRSets.


(5)  [incomplete change in example?]

In Section 4.4, the second-to-last paragraph on page 16 says:

   The DNAME specification is not clear on whether DNAME records in a
   cache are used to rewrite queries.  In some interpretations, the
   rewrite occurs; in others, it does not.  Allowing for the occurrence
   of rewriting, queries for "sub.a.b.example. A" may be rewritten as
|  "sub.foo.bar.tld. A" by the former caching server and may be
|  rewritten as "sub.a.foo.bar.tld. A" by the latter.  Coherency is
   lost, and an operational nightmare ensues.

"tld." does never appear in the preceding text; apparently it has
been replaced there by "example.net."
Therefore, the RFC should say instead:

   The DNAME specification is not clear on whether DNAME records in a
   cache are used to rewrite queries.  In some interpretations, the
   rewrite occurs; in others, it does not.  Allowing for the occurrence
   of rewriting, queries for "sub.a.b.example. A" may be rewritten as
|  "sub.foo.bar.example.net. A" by the former caching server and may be
|  rewritten as "sub.a.foo.bar.example.net. A" by the latter.  Coherency
   is lost, and an operational nightmare ensues.

Notes:

from pending

RFC 4595, "Use of IKEv2 in the Fibre Channel Security Association Management Protocol", July 2006

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 738
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Held for Document Update by: Russ Housley

Section 7.1 says:

   [NIST.180-1.1995]
              National Institute of Standards and Technology, "Secure
              Hash Standard", NIST 180-1, April 1995.

It should say:

   [NIST.180-2.2002]
              National Institute of Standards and Technology, "Secure
              Hash Standard", NIST 180-2, August 2002.

Notes:

The current revision of the NIST's Secure Hash Standard is
"FIPS-PUB 180-2 + Change Notice 1",
issued "2004 Feb 25", which has added SHA-224 to the repertoire.

If NIST publications are used as References in IETF publications,
current revisions should be used.

In the case of SHA-1, perhaps preferrably, RFC 3174 is available
as a (secondary) dedicated reference that will not change.

RFC 4601, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", August 2006

Note: This RFC has been obsoleted by RFC 7761

Note: This RFC has been updated by RFC 5059, RFC 5796, RFC 6226

Source of RFC: pim (rtg)

Errata ID: 1104
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.1.6 says:

immediate_olist(*,G) =
       joins(*,G) (+) pim_include(*,G) (-) lost_assert(*,G)

It should say:

immediate_olist(*,G) =
       ( joins(*,G) (+) pim_include(*,G) ) (-) lost_assert(*,G)

-or-

immediate_olist(*,G) =
       joins(*,G) (+) ( pim_include(*,G) (-) lost_assert(*,G) )

Notes:

Left or right associativity is not established at the beginning of this document, so it is necessary to clarify which operation happens first: (+) or (-).

Errata ID: 1105
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.1.6 says:

immediate_olist(S,G) =
       joins(S,G) (+) pim_include(S,G) (-) lost_assert(S,G)

It should say:

immediate_olist(S,G) =
       ( joins(S,G) (+) pim_include(S,G) ) (-) lost_assert(S,G)

-or-

immediate_olist(S,G) =
       joins(S,G) (+) ( pim_include(S,G) (-) lost_assert(S,G) )

Notes:

Left or right associativity is not established at the beginning of this document, so it is necessary to clarify which operation happens first: (+) or (-).

Errata ID: 1106
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.1.6 says:

inherited_olist(S,G,rpt) =
           ( joins(*,*,RP(G)) (+) joins(*,G) (-) prunes(S,G,rpt) )
       (+) ( pim_include(*,G) (-) pim_exclude(S,G))
       (-) ( lost_assert(*,G) (+) lost_assert(S,G,rpt) )

It should say:

inherited_olist(S,G,rpt) =
           ( ( ( joins(*,*,RP(G)) (+) joins(*,G) ) (-) prunes(S,G,rpt) )
       (+) ( pim_include(*,G) (-) pim_exclude(S,G)) )
       (-) ( lost_assert(*,G) (+) lost_assert(S,G,rpt) )
Or:
inherited_olist(S,G,rpt) =
           ( ( joins(*,*,RP(G)) (+) joins(*,G) ) (-) prunes(S,G,rpt) )
       (+) ( ( pim_include(*,G) (-) pim_exclude(S,G))
       (-) ( lost_assert(*,G) (+) lost_assert(S,G,rpt) ) )
Or:
inherited_olist(S,G,rpt) =
           ( ( joins(*,*,RP(G)) (+) ( joins(*,G) (-) prunes(S,G,rpt) ) )
       (+) ( pim_include(*,G) (-) pim_exclude(S,G)) )
       (-) ( lost_assert(*,G) (+) lost_assert(S,G,rpt) )
Or:
inherited_olist(S,G,rpt) =
           ( joins(*,*,RP(G)) (+) ( joins(*,G) (-) prunes(S,G,rpt) ) )
       (+) ( ( pim_include(*,G) (-) pim_exclude(S,G))
       (-) ( lost_assert(*,G) (+) lost_assert(S,G,rpt) ) )

Notes:

Left or right associativity is not established at the beginning of this document, so it is necessary to clarify which operations happens first.

Errata ID: 1107
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.1.6 says:

   inherited_olist(S,G) =
       inherited_olist(S,G,rpt) (+)
       joins(S,G) (+) pim_include(S,G) (-) lost_assert(S,G)

It should say:

   inherited_olist(S,G) =
       inherited_olist(S,G,rpt) (+)
       joins(S,G) (+) ( pim_include(S,G) (-) lost_assert(S,G) )
Or:
   inherited_olist(S,G) =
       ( inherited_olist(S,G,rpt) (+)
       joins(S,G) (+) pim_include(S,G) ) (-) lost_assert(S,G)
Or:
   inherited_olist(S,G) =
       inherited_olist(S,G,rpt) (+)
       ( ( joins(S,G) (+) pim_include(S,G) ) (-) lost_assert(S,G) )

Notes:

Left or right associativity is not established at the beginning of this document, so it is necessary to clarify which operations happens first.

Errata ID: 1110
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.2.1 says:

void
     CheckSwitchToSpt(S,G) {
       if ( ( pim_include(*,G) (-) pim_exclude(S,G)
              (+) pim_include(S,G) != NULL )
            AND SwitchToSptDesired(S,G) ) {

It should say:

void
     CheckSwitchToSpt(S,G) {
       if ( ( ( pim_include(*,G) (-) pim_exclude(S,G) )
              (+) pim_include(S,G) != NULL )
            AND SwitchToSptDesired(S,G) ) {

Or:

void
     CheckSwitchToSpt(S,G) {
       if ( ( pim_include(*,G) (-) ( pim_exclude(S,G)
              (+) pim_include(S,G) != NULL ) )
            AND SwitchToSptDesired(S,G) ) {

Notes:

Left or right associativity is not established at the beginning of this document, so it is necessary to clarify which operations happens first.

Errata ID: 1113
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.3.1/6.1.1 says:

   The Generation_Identifier (GenID) Option SHOULD be included in all
   Hello messages.  The GenID option contains a randomly generated
   32-bit value that is regenerated each time PIM forwarding is started
   or restarted on the interface, including when the router itself
   restarts.  When a Hello message with a new GenID is received from a
   neighbor, any old Hello information about that neighbor SHOULD be
   discarded and superseded by the information from the new Hello
   message.  This may cause a new DR to be chosen on that interface.

Notes:

Section 6.1.1, item 2 only considers the possibility of falsified Designated Router election results, it does not consider state thrash due to falsified Hello messages with new Generation_Identifier Options.

Errata ID: 1114
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.3.1 says:

   Before an interface goes down or changes primary IP address, a Hello
   message with a zero HoldTime should be sent immediately (with the old
   IP address if the IP address changed).  This will cause PIM neighbors
   to remove this neighbor (or its old IP address) immediately.  After
   an interface has changed its IP address, it MUST send a Hello message
   with its new IP address.  If an interface changes one of its
   secondary IP addresses, a Hello message with an updated Address_List
   option and a non-zero HoldTime should be sent immediately.  This will
   cause PIM neighbors to update this neighbor's list of secondary
   addresses immediately.

Notes:

Section 6.1.1, item 2 only considers the possibility of falsified Designated Router election results, it does not consider forged Hello messages with zero HoldTime or with altered Address_List options.

Errata ID: 1118
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.5.1 says:

+------------++-------------+-------------+--------------+-------------+
|            ||-> J state   | -> PP state | -            | -> NI state |
|Join (J)    ||restart      | start Prune-|              |             |
|            ||Expiry Timer | Pending     |              |             |
|            ||             | Timer       |              |             |
+------------++-------------+-------------+--------------+-------------+
|Prune-      ||-> J state   | -> PP state | -> NI state  | -> NI state |
|Pending (PP)||restart      |             | Send Prune-  |             |
|            ||Expiry Timer |             | Echo(*,*,RP) |             |
+------------++-------------+-------------+--------------+-------------+

Notes:

In state Join, when event “Receive Prune (*,*,RP)” occurs and also in state Prune Pending, when event “Expiry Timer Expires” occurs, a situation occurs where an interface will be pruned possibly more rapidly than expected as in J state, when prune is received, PP state is entered and Prune-pending timer is started, but Expiry timer is not reset/halted/etc and this does have an effect in PP state. This issue is not handled in the detailed description on page 48. Is this intentional?

Errata ID: 1119
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.5.1 says:

          The action "Send PruneEcho(*,*,RP)" is triggered when the
          router stops forwarding on an interface as a result of a
          prune.  A PruneEcho(*,*,RP) is simply a Prune(*,*,RP) message
          sent by the upstream router on a LAN with its own address in
          the Upstream Neighbor Address field.  Its purpose is to add
          additional reliability so that if a Prune that should have
          been overridden by another router is lost locally on the LAN,
          then the PruneEcho may be received and cause the override to
          happen.  A PruneEcho(*,*,RP) need not be sent on an interface
          that contains only a single PIM neighbor during the time this
          state machine was in Prune-Pending state.

Notes:

Forged PruneEcho messages could operate as a form of Denial-of-Service (effectively the same as a Prune(*,*,RP) in this context). The issue is resolved by using AH, but it is not listed as one of the forged message types in section 6.1.1.

Errata ID: 1121
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.5.4 says:

     Prune-Pending (PP)
          The router has received a Prune(S,G,rpt) on this interface
          from a downstream neighbor and is waiting to see whether the
          prune will be overridden by another downstream router.  For
          forwarding purposes, the Prune-Pending state functions exactly
          like the NoInfo state.

Notes:

If a single Prune(S,G,rpt) stops forwarding, then traffic can be interrupted even when it is still needed. There is a random delay between 0 and Effective_Override_Interval(I) (0 – 2.5 seconds by specification defaults) in which traffic stops until it is overridden and traffic starts flowing again. This appears to be an optimization for efficiency vs. reliability. I believe that this should be noted and made into an optional optimization.

Errata ID: 1122
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.5.4 says:

   On unnumbered interfaces on point-to-point links, the router's
   address should be the same as the source address it chose for the
   Hello message it sent over that interface.  However, on point-to-
   point links we also recommend that PIM Join/Prune messages with an
   upstream neighbor address field of all zeros are also accepted.

It should say:

   On unnumbered interfaces on point-to-point links, the router's
   address SHOULD be the same as the source address it chose for the
   Hello message it sent over that interface.  However, on point-to-
   point links we also RECOMMEND that PIM Join/Prune messages with an
   upstream neighbor address field of all zeros are also accepted.

Notes:

RFC 2119 keywords are not capitalized.

Errata ID: 1123
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.5.4 says:

   these state transitions in this state machine must not occur,
   although seeing such a packet may cause state transitions in other
   state machines.

It should say:

   these state transitions in this state machine MUST NOT occur,
   although seeing such a packet may cause state transitions in other
   state machines.

Notes:

RFC 2119 keywords are not capitalized.

Errata ID: 1124
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.5.4 says:

          The compound Join/Prune message contains a Prune(S,G,rpt).

          The (S,G,rpt) downstream state machine on interface I
          transitions back to the Prune state.  The Expiry Timer (ET) is
          restarted, set to maximum of its current value and the
          HoldTime from the triggering Join/Prune message.

It should say:

          A compound Join/Prune message containing a Prune(S,G<rpt) is 
          received on interface I with its Upstream Neighbor Address 
          set to the router’s primary IP address on I.

          The (S,G,rpt) downstream state machine on interface I
          transitions back to the Prune state.  The Expiry Timer (ET) is
          restarted, set to maximum of its current value and the
          HoldTime from the triggering Join/Prune message.

Notes:

This section does not consider “Upstream Neighbor Address” as does “Receive Prune(S,G,rpt)” in “Transitions from Prune State” on page 60 or “Receive Prune(S,G,rpt)” in “Transitions from Prune-Pending State” on page 59. Is that information not important in this state transition?

Errata ID: 1128
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.6.1 says:

CouldAssert(S,G,I) =
     SPTbit(S,G)==TRUE
     AND (RPF_interface(S) != I)
     AND (I in ( ( joins(*,*,RP(G)) (+) joins(*,G) (-) prunes(S,G,rpt) )
                 (+) ( pim_include(*,G) (-) pim_exclude(S,G) )
                 (-) lost_assert(*,G)
                 (+) joins(S,G) (+) pim_include(S,G) ) )

It should say:

Too many possibilities to list.

Notes:

Left or right associativity is not established at the beginning of this document, so it is necessary to clarify which operation happens first: (+) or (-).

Errata ID: 1133
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.9.2 says:

     Holdtime is the amount of time a receiver must keep the neighbor
     reachable, in seconds.  If the Holdtime is set to '0xffff', the
     receiver of this message never times out the neighbor.  This may be
     used with dial-on-demand links, to avoid keeping the link up with
     periodic Hello messages.

Notes:

Holdtime is tunable by the sender and is required to be kept by the receiver. This coupled with the “infinity” metric 0xffff produces the conditions necessary for a Denial of Service to be possible. This is not addressed in section 6.1.1 (Forged Link-Local Messages) or 6.4 (Denial-of-Service Attacks). Additionally, utilizing AH will not solve this issue as Hello messages instantiate state upon receipt and this state constitutes the “service” that is abused in this form of attack. A tunable option to accept a maximum Holdtime for security purposes would resolve this condition.

Errata ID: 1135
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Sections 6.4 and A.2

   The rationale for this is that there is no way in PIM-SM to prune
   traffic off the (*,*,RP) tree, except by Joining the (*,G) tree and
   then pruning each source individually.

Notes:

The paragraph beginning “The rationale for this…” describes a condition where a small cause can have a great effect – a (*,*,RP) join could cause state that, if it is not needed, requires a (*,G) join and many prunes for each source. This is mentioned as the last point in section 6.4, but section 6.4 fails to mention that “undoing” this state requires a join followed by multiple prunes.

Errata ID: 1142
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.1.3 says:

  We recommend storing this information if

It should say:

  We RECOMMEND storing this information if

Notes:

RFC 2119 keyword is not capitalized.

Errata ID: 1143
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.1.3 says:

none

It should say:

PIM (*,G) Join/Prune state begins with a Join(*,G) sent to the RP.  The metric to 
the RP is kept in the MRIB.  Because the RP for this group can be any of several 
PIM routers, the source of the metric information in the MRIB is populated by any 
of the mechanisms discussed in section 4.7.

Notes:

PIM state begins with a join for a group sent towards the RP. It is not readily evident that the BSR keeps a list of current RPs for use in the hash function to map groups onto these RPs in order to seed our state.

Errata ID: 1145
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.1.4 says:

  However, we
   recommend storing this information if possible, as it reduces latency
   converging to stable operating conditions after a failure causing a
   change of DR.  This information is used by the pim_include(S,G) macro
   described in Section 4.1.6.

It should say:

  However, we
   RECOMMEND storing this information if possible, as it reduces latency
   converging to stable operating conditions after a failure causing a
   change of DR.  This information is used by the pim_include(S,G) macro
   described in Section 4.1.6.

Notes:

RFC 2119 keyword is not capitalized.

Errata ID: 1146
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.1.5 says:

However, we recommend storing this
   information if possible, as it reduces latency converging to stable
   operating conditions after a failure causing a change of DR.  This
   information is used by the pim_exclude(S,G) macro described in
   Section 4.1.6.

It should say:

However, we RECOMMEND storing this
   information if possible, as it reduces latency converging to stable
   operating conditions after a failure causing a change of DR.  This
   information is used by the pim_exclude(S,G) macro described in
   Section 4.1.6.

Notes:

RFC 2119 keyword is not capitalized.

Errata ID: 1151
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.3.1 says:

   PIM implementers should enforce a lower bound on the permitted values
   for this delay to allow for scheduling and processing delays within
   their router.  

It should say:

   PIM implementers SHOULD enforce a lower bound on the permitted values
   for this delay to allow for scheduling and processing delays within
   their router.  

Notes:

RFC 2119 keyword is not capitalized.

Errata ID: 1152
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.4.2 says:

   Note (+): Implementations are advised not to make this a special
      case, but to arrange that this path rejoin the normal packet
      forwarding path.  

It should say:

   Note (+): Implementations are SHOULD NOT to make this a special
      case, but to arrange that this path rejoin the normal packet
      forwarding path.  

Notes:

RFC 2119 keyword is not capitalized.

Errata ID: 1154
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.5.1 says:

   The transition events "Receive Join(*,*,RP)" and "Receive
   Prune(*,*,RP)" imply receiving a Join or Prune targeted to this
   router's primary IP address on the received interface.  If the
   upstream neighbor address field is not correct, these state
   transitions in this state machine must not occur, although seeing
   such a packet may cause state transitions in other state machines.

   On unnumbered interfaces on point-to-point links, the router's
   address should be the same as the source address it chose for the
   Hello message it sent over that interface.  However, on point-to-
   point links we also recommend that for backwards compatibility

It should say:

   The transition events "Receive Join(*,*,RP)" and "Receive
   Prune(*,*,RP)" imply receiving a Join or Prune targeted to this
   router's primary IP address on the received interface.  If the
   upstream neighbor address field is not correct, these state
   transitions in this state machine MUST NOT occur, although seeing
   such a packet MAY cause state transitions in other state machines.

   On unnumbered interfaces on point-to-point links, the router's
   address should be the same as the source address it chose for the
   Hello message it sent over that interface.  However, on point-to-
   point links it is also RECOMMENDED that for backwards compatibility

Notes:

RFC 2119 keywords are not capitalized.

Errata ID: 1156
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.5.2 says:

  If the upstream neighbor address
   field is not correct, these state transitions in this state machine
   must not occur, although seeing such a packet may cause state
   transitions in other state machines.

It should say:

  If the upstream neighbor address
   field is not correct, these state transitions in this state machine
   MUST NOT occur, although seeing such a packet MAY cause state
   transitions in other state machines.

Notes:

RFC 2119 keywords are not capitalized.

Errata ID: 1157
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.5.2 says:

   point links we also recommend that for backwards compatibility PIM
   Join/Prune messages with an upstream neighbor address field of all
   zeros are also accepted.

It should say:

   point links we also recommend that for backwards compatibility PIM
   Join/Prune messages with an upstream neighbor address field of all
   zeros are also accepted.

Notes:

RFC 2119 keywords are not capitalized.

Errata ID: 1159
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.5.4 says:

Figure 5.

Notes:

Why isn’t (S,G) state considered for the (S,G,rpt) state machine (depicted in Figure 5 on page 58)? Wouldn’t an (S,G) join have an effect up on (S,G,rpt)?

Errata ID: 1160
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.5.4 says:

     Receive Prune(S,G,rpt)
          The compound Join/Prune message contains a Prune(S,G,rpt).

          The (S,G,rpt) downstream state machine on interface I
          transitions back to the Prune-Pending state.  The Expiry Timer
          (ET) is restarted, set to maximum of its current value and the
          HoldTime from the triggering Join/Prune message.

It should say:

None suggested.

Notes:

Infinite toggle for every pair of routers where one wants (*,G) and the other wants (*,G) and (S,G,rpt). State moves from Prune -> PruneTmp -> NI -> Prune for the (S,G,rpt) state machine. This causes upstream thrash with Join(S,G,rpt) followed by Prune(S,G,rpt) in continual succession. Which causes Prune (S,G,rpt) state to be state limited to never actually enter Prune state (NI -> PP -> NI).

Errata ID: 1161
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.5.6 says:

     bool JoinDesired(*,G) {
        if (immediate_olist(*,G) != NULL OR
            (JoinDesired(*,*,RP(G)) AND
             AssertWinner(*, G, RPF_interface(RP(G))) != NULL))
            return TRUE
        else
            return FALSE
     }

   JoinDesired(*,G) is true when the router has forwarding state that
   would cause it to forward traffic for G using shared tree state.
   Note that although JoinDesired is true, the router's sending of a
   Join(*,G) message may be suppressed by another router sending a
   Join(*,G) onto the upstream interface.

Notes:

When would immediate_olist(*,G) be NULL and forwarding state exist?

Errata ID: 1162
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.5.7 says:

     RPF'(*,G) changes not due to an Assert
          An event occurred that caused the next hop towards the RP for
          G to change.  This may be caused by a change in the MRIB
          routing database or the group-to-RP mapping.  Note that this
          transition does not occur if an Assert is active and the
          upstream interface does not change.

          The upstream (*,G) state machine remains in Joined state.
          Send Join(*,G) to the new upstream neighbor, which is the new
          value of RPF'(*,G).  Send Prune(*,G) to the old upstream
          neighbor, which is the old value of RPF'(*,G).  Use the new
          value of RP(G) in the Prune(*,G) message or all zeros if RP(G)
          becomes unknown (old value of RP(G) may be used instead to
          improve behavior in routers implementing older versions of
          this spec).  Set the Join Timer (JT) to expire after
          t_periodic seconds.

Notes:

Sending the Prune(*,G) may help state issues, but if the change in MRIB was spurious or there was a situation where a difference of opinion in lower route costs exists, some traffic may be dropped until the MRIB becomes consistent again.

Errata ID: 1166
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.5.7 says:

          The upstream (S,G) state machine remains in Joined state.  If
          the Join Timer is set to expire in more than t_override
          seconds, reset it so that it expires after t_override seconds.

It should say:

          The upstream (S,G) state machine remains in Joined state.  If
          the Join Timer is set to expire in more than t_override
          seconds, reset it so that it expires after t_override seconds.  If the 
          Join Timer is set to expire in less than t_override seconds, leave it   
          unchanged.

Notes:

It would make the Join Timer clearer to understand if an explicit statement was made indicating that if the Join Timer is less than t_override, it should be left unchanged. This needs to be made for “See Prune(S,G) to RPF’(S,G)”, “See Prune(S,G,rpt) to RPF’(S,G)”, and “See Prune(*,G) to RPF’(S,G)”.

Errata ID: 1167
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.5.7 says:

          The upstream (S,G) state machine remains in Joined state.
          Send Join(S,G) to the new upstream neighbor, which is the new
          value of RPF'(S,G).  Send Prune(S,G) to the old upstream
          neighbor, which is the old value of RPF'(S,G).  Set the Join
          Timer (JT) to expire after t_periodic seconds.

Notes:

Sending the Prune(*,G) may help state issues, but if the change in MRIB was spurious or there was a situation where a difference of opinion in lower route costs exists, some traffic may be dropped until the MRIB becomes consistent again.

Errata ID: 1168
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.5.8 says:

       # Note: we joined the shared tree, but there was an (S,G) assert
       # and the source tree RPF neighbor is different.

Notes:

In the comments on the “else” clause, why would we think that we were on the shared tree if the SPTbit is false?

Errata ID: 1169
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.5.9 says:

   In addition, there is an (S,G,rpt) Override Timer, OT(S,G,rpt), which
   is used to delay triggered Join(S,G,rpt) messages to prevent
   implosions of triggered messages.

Notes:

What does “implosions of triggered messages” refer to?

Errata ID: 1170
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.5.9 says:

+------------++--------------------------------------------------------+
|            ||                           Event                        |
|            ++--------------+--------------+-------------+------------+
|Prev State  || PruneDesired | PruneDesired | RPTJoin     | inherited_ |
|            || (S,G,rpt)    | (S,G,rpt)    | Desired(G)  | olist      |
|            || ->True       | ->False      | ->False     | (S,G,rpt)  |
|            ||              |              |             | ->non-NULL |
+------------++--------------+--------------+-------------+------------+
|RPTNotJoined|| -> P state   | -            | -           | -> NP state|
|(G) (NJ)    ||              |              |             |            |
+------------++--------------+--------------+-------------+------------+
|Pruned      || -            | -> NP state  | -> NJ state | -          |
|(S,G,rpt)   ||              | Send Join    |             |            |
|(P)         ||              | (S,G,rpt)    |             |            |
+------------++--------------+--------------+-------------+------------+
|NotPruned   || -> P state   | -            | -> NJ state | -          |
|(S,G,rpt)   || Send Prune   |              | Cancel OT   |            |
|(NP)        || (S,G,rpt);   |              |             |            |
|            || Cancel OT    |              |             |            |
+------------++--------------+--------------+-------------+------------+

Notes:

In the intersection of “RPTNotJoined(G)” and “PruneDesired(S,G,rpt) -> True”, the state table indicates that the result is to move into “Pruned(S,G,rpt)” state. This occurs again in the text on pages 80 and 81. Why would join state be entered for (*,G) simply in order to prune (S,G,rpt)?

Errata ID: 1181
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.6.5 says:

       Rationale: This avoids keeping state alive on the (S,G) tree when
       only (*,G) downstream members are left.  Also, it avoids sending
       (S,G,rpt) joins to a router that is not on the (*,G) tree.  This
       behavior might be confusing although this specification does
       indicate that such a join should be dropped.

It should say:

       Rationale: This avoids keeping state alive on the (S,G) tree when
       only (*,G) downstream members are left.  Also, it avoids sending
       (S,G,rpt) joins to a router that is not on the (*,G) tree.  This
       behavior might be confusing although this specification does
       indicate that such a join SHOULD be dropped.

Notes:

RFC 2119 keyword is not capitalized.

Errata ID: 1183
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.9.5 says:

   Holdtime
        The amount of time a receiver must keep the Join/Prune state
        alive, in seconds.  If the Holdtime is set to '0xffff', the
        receiver of this message should hold the state until canceled by
        the appropriate canceling Join/Prune message, or timed out
        according to local policy.  This may be used with dial-on-demand
        links, to avoid keeping the link up with periodic Join/Prune
        messages.

        Note that the HoldTime must be larger than the
        J/P_Override_Interval(I).

It should say:

   Holdtime
        The amount of time a receiver MUST keep the Join/Prune state
        alive, in seconds.  If the Holdtime is set to '0xffff', the
        receiver of this message SHOULD hold the state until canceled by
        the appropriate canceling Join/Prune message, or timed out
        according to local policy.  This MAY be used with dial-on-demand
        links, to avoid keeping the link up with periodic Join/Prune
        messages.

        Note that the HoldTime MUST be larger than the
        J/P_Override_Interval(I).

Notes:

RFC 2119 keywords are not capitalized.

Errata ID: 1184
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.9.5.1 says:

  Each wildcard group set may contain one or more
        (*,*,RP) source list entries in either the Joined or Pruned
        lists.

        A (*,*,RP) source list entry may only exist in a wildcard group
        set.  When added to a Joined source list, this type of source
        entry expresses the router's interest in receiving traffic for
        all groups mapping to the specified RP.  

It should say:

  Each wildcard group set MAY contain one or more
        (*,*,RP) source list entries in either the Joined or Pruned
        lists.

        A (*,*,RP) source list entry MAY only exist in a wildcard group
        set.  When added to a Joined source list, this type of source
        entry expresses the router's interest in receiving traffic for
        all groups mapping to the specified RP.  

Notes:

RFC 2119 keywords are not capitalized.

Errata ID: 1185
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.9.5.1 says:

  Each group-
        specific set may contain (*,G), (S,G,rpt), and (S,G) source list
        entries in the Joined or Pruned lists.

     (*,G)
          The (*,G) source list entry is used in Join/Prune messages
          sent towards the RP for the specified group.  It expresses
          interest (or lack thereof) in receiving traffic sent to the
          group through the Rendezvous-Point shared tree.  There may
          only be one such entry in both the Joined and Pruned lists of
          a group-specific set.

          (*,G) source list entries have the Source-Address set to the
          address of the RP for group G, the Source-Address Mask-Len set
          to the full length of the IP address, and both the WC and RPT
          bits of the Encoded-Source-Address set.

     (S,G,rpt)
          The (S,G,rpt) source list entry is used in Join/Prune messages
          sent towards the RP for the specified group.  It expresses
          interest (or lack thereof) in receiving traffic through the
          shared tree sent by the specified source to this group.  For
          each source address, the entry may exist in only one of the
          Joined and Pruned source lists of a group-specific set, but
          not both.

          (S,G,rpt) source list entries have the Source-Address set to
          the address of the source S, the Source-Address Mask-Len set
          to the full length of the IP address, and the WC bit cleared
          and the RPT bit set in the Encoded-Source-Address.

     (S,G)
          The (S,G) source list entry is used in Join/Prune messages
          sent towards the specified source.  It expresses interest (or
          lack thereof) in receiving traffic through the shortest path
          tree sent by the source to the specified group.  For each
          source address, the entry may exist in only one of the Joined
          and Pruned source lists of a group-specific set, but not both.

It should say:

  Each group-
        specific set MAY contain (*,G), (S,G,rpt), and (S,G) source list
        entries in the Joined or Pruned lists.

     (*,G)
          The (*,G) source list entry is used in Join/Prune messages
          sent towards the RP for the specified group.  It expresses
          interest (or lack thereof) in receiving traffic sent to the
          group through the Rendezvous-Point shared tree.  There MUST 
          be one such entry in both the Joined and Pruned lists of
          a group-specific set.

          (*,G) source list entries have the Source-Address set to the
          address of the RP for group G, the Source-Address Mask-Len set
          to the full length of the IP address, and both the WC and RPT
          bits of the Encoded-Source-Address set.

     (S,G,rpt)
          The (S,G,rpt) source list entry is used in Join/Prune messages
          sent towards the RP for the specified group.  It expresses
          interest (or lack thereof) in receiving traffic through the
          shared tree sent by the specified source to this group.  For
          each source address, the entry MUST exist in only one of the
          Joined and Pruned source lists of a group-specific set, but
          not both.

          (S,G,rpt) source list entries have the Source-Address set to
          the address of the source S, the Source-Address Mask-Len set
          to the full length of the IP address, and the WC bit cleared
          and the RPT bit set in the Encoded-Source-Address.

     (S,G)
          The (S,G) source list entry is used in Join/Prune messages
          sent towards the specified source.  It expresses interest (or
          lack thereof) in receiving traffic through the shortest path
          tree sent by the source to the specified group.  For each
          source address, the entry MUST exist in only one of the Joined
          and Pruned source lists of a group-specific set, but not both.

Notes:

RFC 2119 keywords are not capitalized.

Errata ID: 1192
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.9.5.2 says:

  This list of
   (S,G,rpt) Pruned source-list entries MUST not be split in multiple
   messages.

It should say:

  This list of
   (S,G,rpt) Pruned source-list entries MUST NOT be split in multiple
   messages.

Notes:

RFC 2119 keyword is not capitalized.

Errata ID: 1193
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.9.5.2 says:

   If only N (S,G,rpt) Prune entries fit into a maximum-sized Join/Prune
   message, but the router has more than N (S,G,rpt) Prunes to add, then
   the router MUST choose to include the first N (numerically smallest
   in network byte order) IP addresses.

Notes:

Only N (S,G,rpt) Prune entries are transmitted in the biggest Join/Prune message, what about the remaining (S,G,rpt) entries? Are they ignored? Is a second message generated? This should be made clear.

Errata ID: 1194
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 4.9.5.2 says:

  Assert messages may also be sent in response
   to an Assert message from another router.

It should say:

  Assert messages MAY also be sent in response
   to an Assert message from another router.

Notes:

RFC 2119 keyword is not capitalized.

Errata ID: 1195
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 6.2 says:

   Either static configuration of IP addresses or an IPsec security
   association may be used.  

It should say:

   Either static configuration of IP addresses or an IPsec security
   association MAY be used.  

Notes:

RFC 2119 keyword is not capitalized.

Errata ID: 1198
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 6.3.2.2 says:

   In order to simplify the management problem, it may be acceptable to
   use the same authentication algorithm and authentication parameters,
   regardless of the sending RP and regardless of the destination DR.
   Although a unique SA is needed for each DR, the same authentication

It should say:

   In order to simplify the management problem, it MAY be acceptable to
   use the same authentication algorithm and authentication parameters,
   regardless of the sending RP and regardless of the destination DR.
   Although a unique SA is needed for each DR, the same authentication

Notes:

RFC 2119 keyword is not capitalized.

Errata ID: 1200
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 6.4 says:

   -  Forging a (*,*,RP) join presents a possibility for a denial-of-
      service attack by causing all traffic in the domain to flow to the
      PMBR issuing the join.  (*,*,RP) behavior is included here
      primarily for backwards compatibility with prior revisions of the
      spec.  However, the implementation of (*,*,RP) and PMBR is
      optional.  When using (*,*,RP), the security concerns should be
      carefully considered.

It should say:

   -  Forging a (*,*,RP) join presents a possibility for a denial-of-
      service attack by causing all traffic in the domain to flow to the
      PMBR issuing the join.  (*,*,RP) behavior is included here
      primarily for backwards compatibility with prior revisions of the
      spec.  However, the implementation of (*,*,RP) and PMBR is
      optional.  When using (*,*,RP), the security concerns SHOULD be
      carefully considered.

Notes:

RFC 2119 keyword is not capitalized.

Errata ID: 1201
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22

Section 6 says:

See note.

It should say:

	IPsec usage is recommended to secure PIM messages, but PIM relies upon an 
MRIB populated outside of PIM and it should be noted that for PIM security to be 
effective, securing the sources of change to the MRIB in a similar fashion to 
IPsec is required to be consistent and secure.

Notes:

An additional note should be made with regard to PIM security, possibly as
section 6.3.3?

Errata ID: 1094
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward

Section Table of Con says:

A.2.  Sources Internal to the PIM-SM Domain ...................144

It should say:

A.2. Sources Internal to the PIM-SM Domain ...................144

Notes:

One extra space is listed after the heading and before the item.

Errata ID: 1095
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward

Section List of Figu says:

Figure 1. Per-(S,G) register state machine at a DR ................38

It should say:

Figure 1. Per-(S,G) register state machine at a DR ................39

Notes:

Figure 1 occurs on page 39, is listed as occurring on page 38.

Errata ID: 1096
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward

Section List of Figu says:

Figure 4. Downstream per-interface (S,G) state machine ............53

It should say:

Figure 4. Downstream per-interface (S,G) state machine ............54

Notes:

Figure 1 occurs on page 54, is listed as occurring on page 53.

Errata ID: 1097
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward

Section List of Figu says:

Figure 5. Downstream per-interface (S,G,rpt) state machine ........57

It should say:

Figure 5. Downstream per-interface (S,G,rpt) state machine ........58

Notes:

Figure 1 occurs on page 58, is listed as occurring on page 57.

Errata ID: 1098
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward

Section List of Figu says:

Figure 6. Upstream (*,*,RP) state machine .........................62

It should say:

Figure 6. Upstream (*,*,RP) state machine ......................63-64

Notes:

Figure 1 occurs on pages 63-64, is listed as occurring on page 62.

Errata ID: 1101
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel

Section List of Figu says:

Figure 9. Upstream (S,G,rpt) state machine for triggered
             messages ................................................77

It should say:

Figure 9. Upstream (S,G,rpt) state machine for triggered
             messages ................................................78

Notes:

Figure 1 occurs on page 78, is listed as occurring on page 77.

Errata ID: 1108
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward

Section 4.2 says:

Second, we check to see if the SPTbit should be set because we've now
   switched from the RP tree to the SPT.

It should say:

See notes

Notes:

The dependent clause does not follow from the independent clause.

Errata ID: 1109
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward

Section 4.2 says:

Data-triggered PIM-Assert messages sent from the above forwarding
   code should be rate-limited in a implementation-dependent manner.

It should say:

Data-triggered PIM-Assert messages sent from the above forwarding
   code should be rate-limited in an implementation-dependent manner.

Notes:

Misspelling

Errata ID: 1111
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel

Section 4.2.2 says:

3.  Noone wants the packet on the RP tree.

It should say:

3.  No one wants the packet on the RP tree.

Notes:

Misspelling

Errata ID: 1112
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel

Section 4.3.1 says:

     We note that some implementations do not send Hello messages on
     point-to-point interfaces.  This is non-compliant behavior.  A
     compliant PIM router MUST send Hello messages, even on point-to-
     point interfaces.

It should say:

   We note that some implementations do not send Hello messages on
   point-to-point interfaces.  This is non-compliant behavior.  A
   compliant PIM router MUST send Hello messages, even on point-to-
   point interfaces.

Notes:

It is not clear why this text is indented.

Errata ID: 1115
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel

Section 4.3.2 says:

     We note that some PIM implementations do not send Hello messages on
     point-to-point interfaces and thus cannot perform DR election on
     such interfaces.  This is non-compliant behavior.  DR election MUST
     be performed on ALL active PIM-SM interfaces.

It should say:

See notes.

Notes:

Are the different references to PIM and PIM-SM intentional? Does PIM-DM enter into this?

Errata ID: 1116
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel

Section 4.3.3 says:

In addition to the information recorded for the DR Election, the
   following per neighbor information is obtained from the LAN Prune
   Delay Hello option:

It should say:

In addition to the information recorded for the DR Election, the
   following per-neighbor information is obtained from the LAN Prune
   Delay Hello option:

Notes:

Misspelling.

Errata ID: 1117
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel

Section 4.3.3 says:

   When all routers on a link are in a position to negotiate a
   Propagation Delay different from the default, the largest value from
   those advertised by each neighbor is chosen.  The function for
   computing the Effective_Propagation_Delay of interface I is:

…

   When all routers on a link are in a position to negotiate an Override
   Interval different from the default, the largest value from those
   advertised by each neighbor is chosen.  The function for computing
   the Effective Override Interval of interface I is:

It should say:

   When all routers on a link are in a position to negotiate a
   Propagation Delay different from the default, the largest value from
   those advertised by each neighbor is chosen.  The function for
   computing the Effective Propagation Delay of interface I is:

…

   When all routers on a link are in a position to negotiate an Override
   Interval different from the default, the largest value from those
   advertised by each neighbor is chosen.  The function for computing
   the Effective Override Interval of interface I is:

Notes:

Inconsistency. Either “Effective_Override_Interval” should be used or “Effective Override Interval” should be used.

Errata ID: 1126
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel

Section 4.5.7 says:

See pages 72-76

It should say:

See notes

Notes:

The figure given on pages 72-73 lists additional state changes, the last three of which are “RPF’(S,G) changes not due to an Assert”, “RPF’(S,G) GenID changes”, “RPF’(S,G) changes due to an Assert”, but the order given in the descriptions after the diagram on pages 74-76 lists the last three as: “RPF’(S,G) changes due to an Assert”, “RPF’(S,G) changes not due to an Assert”, and “RPF’(S,G) GenID changes.”

Errata ID: 1127
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel

Section 4.5.9 says:

See pages 78-80

It should say:

See notes

Notes:

The figure given on page 78 lists additional state changes. The order given does not match the order given in the detailed descriptions that follow on pages 79-80.

Errata ID: 1129
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel

Section 4.6.1 says:

     An (S,G) data packet arrives on interface I, AND
          CouldAssert(S,G,I)==TRUE
          An (S,G) data packet arrived on an downstream interface that
          is in our (S,G) outgoing interface list.  We optimistically
          assume that we will be the assert winner for this (S,G), and
          so we transition to the "I am Assert Winner" state and perform
          Actions A1 (below), which will initiate the assert negotiation
          for (S,G).

It should say:

     An (S,G) data packet arrives on interface I, AND
          CouldAssert(S,G,I)==TRUE
          An (S,G) data packet arrived on a downstream interface that
          is in our (S,G) outgoing interface list.  We optimistically
          assume that we will be the assert winner for this (S,G), and
          so we transition to the "I am Assert Winner" state and perform
          Actions A1 (below), which will initiate the assert negotiation
          for (S,G).

Notes:

Misspelling.

Errata ID: 1130
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel

Section 4.6.1 says:

     A4:  Send AssertCancel(S,G).
          Delete assert info (AssertWinner(S,G,I) and
          AssertWinnerMetric(S,G,I) will then return their default
          values).

     A5:  Delete assert info (AssertWinner(S,G,I) and
          AssertWinnerMetric(S,G,I) will then return their default
          values).

It should say:

     A4:  Send AssertCancel(S,G).
          Delete assert info (AssertWinner(S,G,I) and
          AssertWinnerMetric(S,G,I) will then return to their default
          values).

     A5:  Delete assert info (AssertWinner(S,G,I) and
          AssertWinnerMetric(S,G,I) will then return to their default
          values).

Notes:

Missing words.

Errata ID: 1131
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel

Section 4.7.2 says:

   The protocol requires that all routers hash to the same RP within a
   domain (except for transients).  The following hash function must be
   used in each router:

It should say:

See notes.

Notes:

The term “transients” is not defined in section 2.1. Does this refer to the same “transients” as in RFC 1112, section2, paragraph 3?

Errata ID: 1134
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel

Section 4.9.2 says:

The T bit specifies the ability of the
     sending router to disable joins suppression.  

It should say:

The T bit specifies the ability of the
     sending router to disable join suppression.  

Notes:

Misspelling.

Errata ID: 1136
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel

Section Index says:

Not reproduced here.

It should say:

Due to the number of change recommendations to the index, I am not reproducing the index entries here.  The list of definitions that I was able to determine are given below.  Some definitions are not given and these are marked below.

Address_List	31*
Assert(*,G)	128*
Assert(S,G)	128*
AssertCancel(*,G)	99*
AssertCancel(S,G) 	99*
AssertTimer(*,G,I) 	not listed X
AssertTimer(S,G,I) 	not listed X
AssertTrackingDesired(*,G,I)	93*
AssertTrackingDesired(S,G,I) 	86*
AssertWinner(*,G,I)	100*
AssertWinner(S,G,I)	100*
AssertWinnerMetric(*,G,I)	101*
AssertWinnerMetric(S,G,I)	101*
assert_metric	98*
Assert_Override_Interval	132*
Assert_Time	132*
AT(*,G,I)	129*
AT(S,G,I)	129*
CheckSwitchToSpt(S,G) 	28*
CouldAssert(*,G,I)	93*
CouldAssert(S,G,I)	86*
CouldRegister(S,G)	41*
Default_Hello_Holdtime	not listed X
DirectlyConnected(S) 	27*
DownstreamJPState(*,*,RP,I) 	45* (state of FSM in section 4.5.1)
DownstreamJPState(*,G,I) 	49* (state of FSM in section 4.5.2)
DownstreamJPState(S,G,I) 	53* (state of FSM in section 4.5.3)
DownstreamJPState(S,G,rpt,I)	56* (state of FSM in section 4.5.4)
DR(I)	33*
dr_is_better(a,b,I)	33*
DR_Priority	31*
Effective_Override_Interval(I)	36*
Effective_Propagation_Delay(I)		35*
ET(*,*,RP,I)	128*
ET(*,G,I)	128*
ET(S,G,I)	129*
ET(S,G,rpt,I)	129*
GenID	31*
Hash_Function	not listed X
Hello_Holdtime		131*
Hello_Period	130*
HT(I)	31*
IGMP	6*
immediate_olist(*,*,RP)	22*
immediate_olist(*,G)	22*
immediate_olist(S,G)	22*
infinite_assert_metric()	99*
inherited_olist(S,G)	22*
inherited_olist(S,G,rpt)	22*
I_Am_Assert_Loser(*,G,I)	not listed X
I_Am_Assert_Loser(S,G,I)	not listed X
I_am_DR(I)	33*
I_am_RP(G)	44*
J/P_Holdtime	131*
J/P_Override_Interval(I)	132*
JoinDesired(*,*,RP)	64*
JoinDesired(*,G)	68*
JoinDesired(S,G)	73*
joins(*,*,RP(G))	not listed X
joins(*,*,RP)	23*
joins(*,G)	23*
joins(S,G)	23*
JT(*,*,RP)	129*
JT(*,G)		129*
JT(S,G)		129*
KAT(S,G)	129*
KeepaliveTimer(S,G)	not listed X
Keepalive_Period	134*
lan_delay_enabled(I)	35*
LAN_Prune_Delay	not listed X
local_receiver_exclude(S,G,I)	23*
local_receiver_include(*,G,I)	not listed X
local_receiver_include(S,G,I)	not listed X
lost_assert(*,G)		24*
lost_assert(*,G,I)	100*
lost_assert(S,G)		24*
lost_assert(S,G,I)	100*
lost_assert(S,G,rpt)	24*
lost_assert(S,G,rpt,I)	100*
MBGP	6*
MFIB	6*
MLD	6*
MRIB	6*
MRIB.next_hop(host)	25*
my_assert_metric(*,G,I)	not listed X
my_assert_metric(S,G,I)	98*
NBR(Interface,IP_address)	not listed X
NLT(N,I)	not listed X
OT(S,G,rpt)	77*
Override_Interval(I)	130? (Why is it termed a “variable”?)
packet_arrives_on_rp_tunnel(pkt)	43*
pim_exclude(S,G)	22*
pim_include(*,G)	22*
pim_include(S,G)	22*
PPT(*,*,RP,I)	not listed X
PPT(*,G,I)	not listed X
PPT(S,G,I)	not listed X
PPT(S,G,rpt,I)	not listed X
Propagation_Delay(I)	130? (Why is it termed a “variable”?)
Propagation_delay_default	130*
PruneDesired(S,G,rpt)	79*
prunes(S,G,rpt)		23*
Register-Stop(*,G)	not listed X
Register-Stop(S,G)	not listed X
Register-StopTimer(S,G)	not listed X
Register_Probe_Time	135*
Register_Suppression_Time	135*
RP(G)	not listed X
RPF	6*
RPF’(*,G)	24*
RPF’(S,G)	25*
RPF’(S,G,rpt)	24*
RPF_interface	not listed X
RPF_interface(host)	not listed X
RPFJoinDesired(G)	79*
rpt_assert_metric(G,I)	not listed X
RST(S,G)	135?
SPTbit(S,G)	not listed X
spt_assert_metric(S,I)	98*
SSM	106*
Suppression_Enabled(I)		36*
SwitchToSptDesired(S,G)	28*
TIB	6*
Triggered_Hello_Delay		130*
t_joinsuppress	not listed X
t_override	133*
t_override_default	130*
t_periodic	133*
t_suppressed	133*
Update_SPTbit(S,G,iif)		29*
UpstreamJPState(S,G)		not listed X

Notes:

The locations of the definitions of functions are not given. Given that there are so many functions, it would be useful to have a notation that indicates this. I propose adding a “*” next to the page reference that contains the definition of that function as well as adding an explanatory note to the index, such as:

For function definitions, see the pages marked with an asterisk (*).

Errata ID: 1137
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel

Section Index says:

Index not reproduced here.

It should say:

Due to the number of change recommendations to the index, I am not reproducing the index entries here.

AssertTimer(*,G,I) page 16 (no explicit function reference is found, but it is referred to on the page)
AssertTimer(*,G,I) page 24 (missing on the page referred)
AssertTimer(*,G,I) page 132 (missing on the page referred)

AssertTimer(S,G,I) page 18 (no explicit function reference is found, but it is referred to on the page)
AssertTimer(S,G,I) page 24 (missing on the page referred)
AssertTimer(S,G,I) page 132 (missing on the page referred)

AssertWinner(*,G,I) page 16 (no explicit function reference is found, but it is referred to on the page)

AssertWinner(S,G,I) page 18 (no explicit function reference is found, but it is referred to on the page)
AssertWinner(S,G,I) page 100 (duplicate reference)

AssertWinnerMetric(*,G,I) page 16 (no explicit function reference is found, but it is referred to on the page)

AssertWinnerMetric(S,G,I) page 18 (no explicit function reference is found, but it is referred to on the page)

AT(*,G,I) page 16 (no explicit function reference is found, but it is referred to on the page)
AT(*,G,I) page 24 (missing on the page referred)
AT(*,G,I) page 91 (no explicit function reference is found, but it is referred to on the page)

AT(S,G,I) page 18 (no explicit function reference is found, but it is referred to on the page)
AT(S,G,I) page 24 (missing on the page referred)
AT(S,G,I) page 84 (no explicit function reference is found, but it is referred to on the page)

CouldRegister(S,G) page 39 (no explicit function reference is found, but it is referred to on the page)

DirectlyConnected(S) page 27 (duplicate reference)

dr_is_better(a,b,I) page 33 (duplicate reference)

ET(*,*,RP,I) page 15 (no explicit function reference is found, but it is referred to on the page)
ET(*,*,RP,I) page 46 (no explicit function reference is found, but it is referred to on the page)

ET(*,G,I) page 16 (no explicit function reference is found, but it is referred to on the page)
ET(*,G,I) page 50 (no explicit function reference is found, but it is referred to on the page)

ET(S,G,I) page 18 (no explicit function reference is found, but it is referred to on the page)
ET(S,G,I) page 53 (no explicit function reference is found, but it is referred to on the page)

ET(S,G,rpt,I) page 20 (no explicit function reference is found, but it is referred to on the page)
ET(S,G,rpt,I) page 57 (no explicit function reference is found, but it is referred to on the page)
ET(S,G,rpt,I) page 59 (no explicit function reference is found, but it is referred to on the page)

Hash_Function page 12 (no explicit function reference is found, but it is referred to on the page)
Hash_Function page 105 (no explicit function reference is found, but it is referred to on the page)

IGMP page 17 (missing on the page referred)
IGMP page 23 (missing on the page referred)
IGMP page 105 (missing on the page referred)

J/P_Holdtime page 47 (no explicit function reference is found, but it is referred to on the page)
J/P_Holdtime page 51 (no explicit function reference is found, but it is referred to on the page)
J/P_Holdtime page 55 (no explicit function reference is found, but it is referred to on the page)
J/P_Holdtime page 59 (no explicit function reference is found, but it is referred to on the page)
J/P_Holdtime page 65 (no explicit function reference is found, but it is referred to on the page)
J/P_Holdtime page 69 (no explicit function reference is found, but it is referred to on the page)
J/P_Holdtime page 74 (no explicit function reference is found, but it is referred to on the page)
J/P_Holdtime page 121 (no explicit function reference is found, but it is referred to on the page)
J/P_Holdtime page 133 (no explicit function reference is found, but it is referred to on the page)

JoinDesired(*,G) page 17 (missing on the page referred)

joins(*,*,RP) page 86 (missing on the page referred)
joins(*,*,RP) page 93 (missing on the page referred)

JT(*,*,RP) page 15 (no explicit function reference is found, but it is referred to on the page)

JT(*,G) page 16 (no explicit function reference is found, but it is referred to on the page)

JT(S,G) page 18 (no explicit function reference is found, but it is referred to on the page)

KAT(S,G) page 18 (no explicit function reference is found, but it is referred to on the page)
KAT(S,G) page 26 (missing on the page referred)
KAT(S,G) page 27 (missing on the page referred)
KAT(S,G) page 28 (missing on the page referred)
KAT(S,G) page 41 (missing on the page referred)
KAT(S,G) page 43 (missing on the page referred)
KAT(S,G) page 73 (missing on the page referred)
KAT(S,G) page 108 (missing on the page referred)

KeepaliveTimer(S,G) page 18 (no explicit function reference is found, but it is referred to on the page)
KeepaliveTimer(S,G) page 26 (missing on the page referred)
KeepaliveTimer(S,G) page 27 (duplicate reference)
KeepaliveTimer(S,G) page 108 (missing on the page referred)
KeepaliveTimer(S,G) page 129 (missing on the page referred)
KeepaliveTimer(S,G) page 134 (missing on the page referred)

LAN_Prune_Delay page 31 (no explicit function reference is found, but it is referred to on the page)

local_receiver_include(S,G,I) page 23 (missing on the page referred)

Next line duplicates the previous line (reference on page 144 is correct)

MFIB page 13 (missing on the page referred)

MLD page 17 (missing on the page referred)
MLD page 23 (missing on the page referred)
MLD page 105 (missing on the page referred)

MRIB page 66 (duplicate reference)
MRIB page 75 (missing on the page referred)

NBR(Interface,IP address) page 37 (missing on the page referred)

OT(S,G,rpt) page 20 (no explicit function reference is found, but it is referred to on the page)

Override_Interval(I) page 14 (missing on the page referred)
Override_Interval(I) page 34 (missing on the page referred)
Override_Interval(I) page 132 (missing on the page referred)

pim_exclude(S,G) page 22 (duplicate reference)

pim_include(*,G) page 22 (duplicate reference)

pim_include(S,G) page 22 (duplicate reference)

PPT(*,*,RP,I) page 15 (no explicit function reference is found, but it is referred to on the page)
PPT(*,*,RP,I) page 46 (missing on the page referred)

PPT(*,G,I) page 16 (no explicit function reference is found, but it is referred to on the page)
PPT(*,G,I) page 50 (missing on the page referred)

PPT(S,G,I) page 18 (no explicit function reference is found, but it is referred to on the page)
PPT(S,G,I) page 53 (missing on the page referred)

PPT(S,G,rpt,I) page 20 (no explicit function reference is found, but it is referred to on the page)
PPT(S,G,rpt,I) page 57 (missing on the page referred)
PPT(S,G,rpt,I) page 59 (missing on the page referred)

Propagation_Delay(I) page 31 (missing on the page referred)
Propagation_Delay(I) page 132 (missing on the page referred)

Register-StopTimer(S,G) page 38 (missing on the page referred)
Register-StopTimer(S,G) page 39 (missing on the page referred)
Register-StopTimer(S,G) page 129 (missing on the page referred)
Register-StopTimer(S,G) page 135 (no explicit function reference is found, but it is referred to on the page)

RP(G)  page 5 (missing on the page referred)
RP(G) page 99 (missing on the page referred)

RPF’(*,G) page 101 (missing on the page referred)

RPF’(S,G) page 101 (missing on the page referred)

rpt_assert_metric(G,I) page 99 (missing on the page referred)

RST(S,G) page 38 (missing on the page referred)
RST(S,G) page 39 (missing on the page referred)

SPTbit(S,G) page 19 (no explicit function reference is found, but it is referred to on the page)
SPTbit(S,G) page 53 (no explicit function reference is found, but it is referred to on the page)
SPTbit(S,G) page 86 (duplication reference)
SPTbit(S,G) page 108 (missing on the page referred)

SSM page 10 (missing on the page referred)

SwitchToSptDesired(S,G) page 28 (duplicate reference)

t_joinsuppress page 64 (missing on the page referred)
t_joinsuppress page 68 (missing on the page referred)

t_suppressed page 73 (missing on the page referred)

Notes:

The items above are referred to in the Index, but were not found at the locations specified in the Index.

Errata ID: 1138
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel

Section Index says:

Not reproduced here.

It should say:

Due to the number of change recommendations to the index, I am not reproducing the index entries here.

GenID page 14

RPF page 15 

IGMP page 16
MLD page 16

JoinDesired(*,G) page 17
MRIB page 17

IGMP page 19

pim_exclude(S,G) page 21
immediate_olist(S,G) page 21
inherited_olist(S,G) page 21
inherited_olist(S,G,rpt) page 21
immediate_olist(*,*,RP) page 21
immediate_olist(*,G) page 21

lost_assert(S,G,rpt) page 22
inherited_olist(S,G,rpt) page 22
local_receiver_include(*,G,I) page 22
local_receiver_include(S,G,I) page 22
IGMP page 22
MLD page 22

NBR(Interface,IP_address) page 24

I_Am_Assert_Loser(S,G,I) page 25
AssertWinner(S,G,I) page 25
RPF_interface(Interface,IP_address) page 25
RPF’(*,G) page 25
RPF’(S,G,rpt) page 25
RPF’(*,G) page 25
Assert(S,G) page 25
RPF_interface(host) page 25
RP(G) page 25
I_Am_Assert_Loser(*,G,I) page 25

RPF_interface(host) page 26
MRIB page 26

RP(G) page 27

inherited_olist(S,G) page 28
inherited_olist(S,G,rpt) page 28
Update_SPTbit(S,G,iif) page 28
UpstreamJPState(S,G) page 28
Keepalive_Period page 28

RP(G) page 29
I_Am_Assert_Loser(S,G,I) page 29
Assert(S,G) page 29

RPF’(S,G) page 30
RPF’(*,G) page 30
Assert(S,G) page 30
JoinDesired(S,G) page 30

GenID page 32

MRIB page 37

Register_Probe_Time page 40
Register_Suppression_Time page 40

Register-Stop(S,G) page 42

inherited_olist(S,G,rpt) page 43

KeepaliveTimer(S,G) page 44
inherited_olist(S,G) page 44

RPF_interface(host) page 62

JoinDesired(*,*,RP) page 63
t_periodic page 63
MRIB page 63
t_joinsuppress page 63
t_override page 63

RPF_interface(host) page 64

JoinDesired(*,*,RP) page 65
immediate_olist(*,*,RP) page 65
NBR(Interface,IP_address) page 65
RPF_interface(host) page 65
MRIB page 65
t_periodic page 65
t_override page 65

RPF_interface(host) page 66
t_periodic page 66
t_override page 66

JoinDesired(*,G) page 67
t_periodic page 67
t_joinsuppress page 67
t_override page 67

JoinDesired(*,*,RP) page 68
AssertWinner(*,G,I) page 68

JoinDesired(*,G) page 69
immediate_olist(*,G) page 69 
RPF’(*,G) page 69
t_periodic page 69
RP(G) page 69

t_override page 70
RPF_interface(host) page 70
RP(G) page 70
t_periodic page 70

MRIB page 71

JoinDesired(S,G) page 72
t_periodic page 72
SPTbit(S,G) page 72
RPF’(S,G) page 72 
t_joinsuppress page 72
t_override page 72

RPF’(S,G) page 73

JoinDesired(S,G) page 74
inherited_olist(S,G) page 74
RPF’(S,G) page 74

t_override page 75
RPF’(S,G) page 75
RPF_interface(host) page 75

t_periodic page 76
t_override page 76

PruneDesired(S,R,rpt) page 78
RPTJoinDesired(G) page 78
inherited_olist(S,G,rpt) page 78
RPF’(S,G,rpt) page 78 
RPF’(*,G) page 78

RP(G) page 79

t_override page 80
RPF’(S,G,rpt) page 80
RPF’(*,G) page 80

RPF’(S,G,rpt) page 81 
PruneDesired(S,G,rpt) page 81

Assert(*,G) page 82
RPF’(*,G) page 82
JoinDesired(*,G) page 82
JoinDesired(*,*,RP) page 82

AssertTrackingDesired(S,G,I) page 84

RPF_interface(host) page 85

joins(*,*,RP) page 86
lost_assert(S,G,I) page 86

GenID page 89

RPF_interface(host) page 90
Assert(S,G) page 90
UpstreamJPState(S,G) page 90

AssertTrackingDesired(*,G,I) page 92

joins(*,*,RP) page 93

GenID page 96

RPF_interface(host) page 97
RP(G) page 97
Assert(*,G) page 97

rpt_assert_metric(G,I) page 98
infinite_assert_metric() page 98
rpt_assert_metric(G,I) page 98

MRIB page 99

RP(G) page 100
AssertWinnerMetric(S,G,I) page 100
Assert(S,G) page 100
Assert(*,G) page 100

Assert(S,G) page 101
Assert(*,G) page 101
AssertWinner(S,G,I) page 101
MRIB page 101

RPF’(*,G) page 102

IGMP page 104
MLD page 104

SSM page 107

SSM page 108
Assert(S,G) page 108

Triggered_Hello_Delay page 131
Default_Hello_Holdtime page 131
Hello_Period page 131
JT(*,G) page 131

AssertTimer(*,G,I) page 132
AssertTimer(S,G,I) page 132

Effective_Override_Interval(I) page 133

Register_Suppression_Time page 134
Register_Probe_Time page 134

SSM page 137

RPF_interface(host) page 144 

local_receiver_include(S,G,I) page 145
local_receiver_include(*,G,I) page 145
DownstreamJPState(*,G,I) page 145
DownstreamJPState(S,G,rpt,I) page 145

Notes:

Functions were found in the document that were mentioned in the Index, but there was no reference given in the Index.

Errata ID: 1139
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel

Section Index says:

Not reproduced here

It should say:

Due to the number of change recommendations to the index, I am not reproducing the index entries here.

NotJoined(*,*,RP) page 15

NotJoined(*,G) page 16

NotJoined(S,G) page 18

Prune(*,*,RP) page 15

Join(*,G) page 17
Prune(*,G) page 17

Join(S,G) page 19
Prune(S,G) page 19

Prune(S,G,rpt) page 21
Join(*,G) page 21

Prune(S,G,rpt) page 25
Join(*,G) page 25

Join(S,G) page 29
Prune(S,G,rpt) page 29

Prune(*,*,RP) page 46
Join(*,*,RP) page 46

Join(*,*,RP) page 47
Prune(*,*,RP) page 47

Prune(*,*,RP) page 48
Join(*,*,RP) page 48

Prune(*,*,RP) page 49
Join(*,G) page 49
Prune(*,G) page 49

Join(*,G) page 50
Prune(*,G) page 50

Join(*,G) page 51
Prune(*,G) page 51

Join(*,G) page 52

Prune(*,G) page 52

Join(S,G) page 54
Prune(S,G) page 54

PruneEcho(*,*,RP) page 46

PruneEcho(*,*,RP) page 48

PruneEcho(*,*,RP) page 49

PruneEcho(*,G) page 50

PruneEcho(*,G) page 52

PruneEcho(S,G) page 54

Join(S,G) page 55
Prune(S,G) page 55

PruneEcho(S,G) page 56
Prune(S,G) page 56

Prune(S,G,rpt) page 57

Join(*,G) page 58
Join(S,G,rpt) page 58
Prune(S,G,rpt) page 58

Prune(S,G,rpt) page 59
Join(*,G) page 59
Join(S,G,rpt) page 59

Join(*,G) page 60
Join(S,G,rpt) page 60
Prune(S,G,rpt) page 60

Prune(S,G,rpt) page 61
Prune(*,G) page 61
Join(*,*,RP) page 61
Join(*,G) page 61

Join(*,*,RP) page 62
Prune(*,*,RP) page 62

Prune(*,*,RP) page 63

Join(*,*,RP) page 64
Prune(*,*,RP) page 64

Prune(*,*,RP) page 65

Join(*,*,RP) page 65

Join(*,*,RP) page 63

Join(*,*,RP) page 66
Prune(*,*,RP) page 66

Join(*,G) page 66
Prune(*,G) page 66

Join(*,G) page 67
Prune(*,G) page 67

Join(S,G) page 73
Prune(*,G) page 73

Join(*,G) page 68
Prune(*,G) page 68

Prune(*,G) page 69
Join(*,G) page 69

Join(*,G) page 70
Prune(*,G) page 70

Join(S,G) page 71
Prune(S,G) page 71
Prune(S,G,rpt) page 71

Join(S,G) page 74
Prune(S,G) page 74

Prune(*,G) page 75 
Prune(S,G,rpt) page 75

Join(S,G) page 76
Prune(S,G) page 76

Prune(S,G,rpt) page 76
Join(*,G) page 76
Join(S,G,rpt) page 76

Join(S,G,rpt) page 77

Prune(S,G,rpt) page 78
Join(S,G,rpt) page 78
Prune(S,G) page 78

Join(S,G,rpt) page 79
Prune(S,G,rpt) page 79

Prune(S,G) page 80
Join(S,G,rpt) page 80
Prune(S,G,rpt) page 80

Prune(S,G,rpt) page 81
Join(*,G) page 81
Join(*,*,RP) page 81
Join(S,G,rpt) page 81

Prune(S,G,rpt) page 82
Join(*,G) page 82
Prune(S,G,rpt) page 82
Join(*,*,RP) page 82
Prune(*,G) page 82
Prune(*,*,RP) page 82

Join(*,*,RP) page 83
Prune(S,G,rpt) page 83

Join(S,G) page 85

Join(S,G) page 90

Join(*,G) page 93
Join(*,*,RP) page 93

Join(*,G) page 97
Join(*,*,RP) page 97

Join(*,G) page 101
Join(S,G) page 101

Join(S,G) page 102
Join(*,*,RP) page 102
Join(*,G) page 102
Prune(S,G,rpt) page 102
Join(S,G,rpt) page 102

Join(*,G) page 125
Prune(*,G) page 125
Join(S,G,rpt) page 125
Prune(S,G,rpt) page 125
Join(S,G) page 125
Prune(S,G) page 125
Join(*,*,RP) page 125
Prune(*,*,RP) page 125

Join(S,G) page 143

Join(*,*,RP) page 144

Joined(*,*,RP) page 15

Joined(*,G) page 16

Joined(S,G) page 18 

Join(S,G) page 72

Prune(S,G) page 72
Prune(S,G,rpt) page 72

Join(S,G,rpt) page 82

IGMPv3 page 19

IGMPv3 page 20

IGMPv3 page 21

RPTNotJoined(G) page 20
NotPruned(S,G,rpt) page 20
Pruned(S,G,rpt) page 20

RPTNotJoined(G) page 77

Pruned(S,G,rpt) page 77
NotPruned(S,G,rpt) page 77

RPTNotJoined(G) page 78
Pruned(S,G,rpt) page 78
NotPruned(S,G,rpt) page 78

RPTNotJoined(host) page 80

RPTNotJoined(host) page 81
Pruned(S,G,rpt) page 81
NotPruned(S,G,rpt) page 81

immediate_olist(S,G,rpt) page 21

PMBR(S,G) page 43

RP_Keepalive_Period page 43

next_hop(host) page 63

next_hop(host) page 65

next_hop(host) page 66

Assert(*,*,RP) page 82

pref(S) page 98
metric(S) page 98

my_ip_address(I) page 98

pref(S) page 99
metric(S) page 99

my_ip_address(I) page 99

Value(G,M,C) page 105
C(i) page 105

pref(S) page 128
metric(S) page 128

Notes:

Some functions were found in the document that did not have any entry in the Index. These are itemized above.

Errata ID: 1140
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel

Section 2.1 says:

   Upstream
         Towards the root of the tree.  The root of tree may be either
         the source or the RP, depending on the context.

It should say:

   Upstream
         Towards the root of the tree.  The root of the tree may be either
         the source or the RP, depending on the context.

Notes:

Misspelling.

Errata ID: 1141
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel

Section 3.6 says:

  This
   election is performed using PIM Assert messages, which resolve the
   problem in favor of the upstream router that has (S,G) state; or, if
   neither or both router has (S,G) state, then the problem is resolved
   in favor of the router with the best metric to the RP for RP trees,
   or the best metric to the source to source-specific trees.

It should say:

  This
   election is performed using PIM Assert messages, which resolve the
   problem in favor of the upstream router that has (S,G) state; or, if
   neither or both router has (S,G) state, then the problem is resolved
   in favor of the router with the best metric to the RP for RP trees,
   or the best metric to the source for source-specific trees.

Notes:

Word choice.

Errata ID: 1144
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel

Section 4.1.4 says:

   Local membership is the result of the local source-specific
   membership mechanism (such as IGMP version 3) running on that
   interface and specifying that this particular source should be
   included.  As stored here, this state is the resulting state after
   any IGMPv3 inconsistencies have been resolved.  It need not be kept
   if this router is not the DR on that interface unless this router won
   a (S,G) assert on this interface for this group.

It should say:

   Local membership is the result of the local source-specific
   membership mechanism (such as IGMP version 3) running on that
   interface and specifying that this particular source should be
   included.  As stored here, this state is the resulting state after
   any IGMPv3 inconsistencies have been resolved.  It need not be kept
   if this router is not the DR on that interface unless this router won
   an (S,G) assert on this interface for this group.

Notes:

Misspelling.

Errata ID: 1147
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel

Section 4.2 says:

      RPF_interface(RP) is the interface the MRIB indicates would be
      used to route packets to RP, except at the RP when it is the

It should say:

      RPF_interface(RP) is the interface the MRIB indicates would be
      used to route packets to the RP, except at the RP when it is the

Notes:

Missing word.

Errata ID: 1149
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel

Section 4.2.2 says:

   Basically, Update_SPTbit will set the SPTbit if we have the
   appropriate (S,G) join state, and if the packet arrived on the
   correct upstream interface for S, and if one or more of the following
   conditions applies:

It should say:

See notes

Notes:

Should “Basically, Update_SPTbit will set” be “Basically, Update_SPTbit(S,G,iif) will set”?

Errata ID: 1150
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel

Section 4.3.1 says:

   The LAN Prune Delay Option SHOULD be included in all Hello messages
   sent on multi-access LANs.  This option advertises a router's
   capability to use values other than the defaults for the
   Propagation_Delay and Override_Interval, which affect the setting of
   the Prune-Pending, Upstream Join, and Override Timers (defined in
   Section 4.10).

It should say:

   The LAN Prune Delay Option SHOULD be included in all Hello messages
   sent on multi-access LANs.  This option advertises a router's
   capability to use values other than the defaults for the
   Propagation_Delay(I) and Override_Interval, which affect the setting of
   the Prune-Pending, Upstream Join, and Override Timers (defined in
   Section 4.10).

Notes:

Misspelling.

Errata ID: 1155
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel

Section 4.5.1 says:

PIM
   Join/Prune messages with an upstream neighbor address field of all
   zeros are also accepted.

It should say:

PIM
   Join/Prune messages with an upstream neighbor address field of all
   zeros also be accepted.

Notes:

Word choice.

Errata ID: 1163
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel

Section 4.5.7 says:

If a (S,G) Assert occurs on the upstream interface,

It should say:

If an (S,G) Assert occurs on the upstream interface,

Notes:

Misspelling.

Errata ID: 1164
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel

Section 4.5.7 says:

and this changes
   the this router's idea of the upstream neighbor,

It should say:

and this changes
   the router's idea of the upstream neighbor,

-or-

and this changes
   this router's idea of the upstream neighbor,

Notes:

Word choice.

Errata ID: 1165
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel

Section 4.5.7 says:

   In addition, if MRIB changes

It should say:

   In addition, if the MRIB changes

Notes:

Missing word.

Errata ID: 1172
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel

Section 4.5.9 says:

  If the router was previously in RPTNotJoined(G)
      state, then there is no need to trigger an action in this state
      machine because sending a Prune(S,G,rpt) is handled by the rules
      for sending the Join(*,G) or Join(*,*,RP).

It should say:

See notes.

Notes:

A reference to a page would be very helpful at the end of the event description in reference to the “rules for sending the Join(*,G) or Join(*,*,RP).”

Errata ID: 1175
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Date Held: 2013-11-03

Section 4.6.2 says:

  It must not
      forward packets for G onto interface I with the exception of
      traffic from sources for which is has (S,G) "I am Assert Winner"
      state.

It should say:

  It must not
      forward packets for G onto interface I with the exception of
      traffic from sources for which it has (S,G) "I am Assert Winner"
      state.

Notes:

Misspelling ("is" -> "it").

Errata ID: 1178
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel

Section 4.6.2 says:

See notes.

It should say:

See notes.

Notes:

The figure given on page 92 lists state changes which are “Assert Timer Expires”, “Receive Inferior Assert”, “Receive Preferred Assert”, and “CouldAssert(*,G,I) -> FALSE”, but the order given in the descriptions after the diagram on page 95 does not match this order.

Errata ID: 1179
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel

Section 4.6.2 says:

     A4:  Send AssertCancel(*,G).
          Delete assert info (AssertWinner(*,G,I) and
          AssertWinnerMetric(*,G,I) will then return their default
          values).

     A5:  Delete assert info (AssertWinner(*,G,I) and
          AssertWinnerMetric(*,G,I) will then return their default
          values).

It should say:

     A4:  Send AssertCancel(*,G).
          Delete assert info (AssertWinner(*,G,I) and
          AssertWinnerMetric(*,G,I) will then return to their default
          values).

     A5:  Delete assert info (AssertWinner(*,G,I) and
          AssertWinnerMetric(*,G,I) will then return to their default
          values).

Notes:

Missing words.

Errata ID: 1180
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel

Section 4.6.5 says:

  In this case, it needs to ignore the assert state
   if it will win the assert once the SPTbit is set.

It should say:

  In this case, it needs to ignore the assert state
   if it will win the assert once the SPT bit is set.

Notes:

Misspelling.

Errata ID: 1182
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel

Section 4.9 says:

Type Types for specific PIM messages.  PIM Types are:

It should say:

Type
 Types for specific PIM messages.  PIM Types are:

Notes:

Spacing.

Errata ID: 1186
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel

Section 4.9.5.1 says:

   o Combining a (*,G) Join and a (S,G,rpt) Join entry in the same
     message is redundant as the (*,G) entry covers the information
     provided by the (S,G,rpt) entry.

It should say:

   o Combining a (*,G) Join and an (S,G,rpt) Join entry in the same
     message is redundant as the (*,G) entry covers the information
     provided by the (S,G,rpt) entry.

Notes:

Misspelling.

Errata ID: 1187
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel

Section 4.9.5.1 says:

   o The same applies for a (*,G) Prunes and (S,G,rpt) Prunes.

It should say:

   o The same applies for a (*,G) Prune and (S,G,rpt) Prunes.

Notes:

Misspelling.

Errata ID: 1188
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel

Section 4.9.5.1 says:

   o The combination of a (*,G) Prune and a (S,G,rpt) Join is also not
     generated.

It should say:

   o The combination of a (*,G) Prune and an (S,G,rpt) Join is also not
     generated.

Notes:

Misspelling.

Errata ID: 1189
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel

Section 4.9.5.1 says:

  o As Join/Prune messages are targeted to a single PIM neighbor,
     including both a (S,G) Join and a (S,G,rpt) Prune in the same
     message is usually redundant.  

It should say:

  o As Join/Prune messages are targeted to a single PIM neighbor,
     including both an (S,G) Join and an (S,G,rpt) Prune in the same
     message is usually redundant.  

Notes:

Misspellings.

Errata ID: 1190
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel

Section 4.9.5.1 says:

   o The combination of a (S,G) Prune and a (S,G,rpt) Join could
     possibly be used by a router to switch from receiving a particular
     source on the shortest-path tree back to receiving it on the shared
     tree (provided that the RPF neighbor for the shortest-path and
     shared trees is common).  However, Sparse-Mode PIM does not provide
     a mechanism for explicitly switching back to the shared tree.

It should say:

   o The combination of an (S,G) Prune and an (S,G,rpt) Join could
     possibly be used by a router to switch from receiving a particular
     source on the shortest-path tree back to receiving it on the shared
     tree (provided that the RPF neighbor for the shortest-path and
     shared trees is common).  However, Sparse-Mode PIM does not provide
     a mechanism for explicitly switching back to the shared tree.

Notes:

Misspellings.

Errata ID: 1196
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Date Held: 2011-05-09

Section 6.3.2.1 says:

   In this "single shared key" mode of operation, the network
   administrator must choose an SPI for each DR that will be used to
   send it PIM protocol packets.  

It should say:

See notes.

Notes:

What does “it” refer to?

s/it/the/

Errata ID: 1197
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel

Section 6.3.2.1 says:

The Security Policy Database at every
   DR is configured to select an SA (including the authentication
   algorithm, authentication parameters, and this SPI) when sending
   Register messages to this RP.

It should say:

The Security Policy Database at every
   DR is configured to select an SA (including the authentication
   algorithm, authentication parameters, and this SPI) when sending
   Register messages to an RP.

Notes:

Word choice.

Errata ID: 1199
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Date Held: 2009-08-26

Section 6.4 says:

   There are a number of possible denial-of-service attacks against PIM
   that can be caused by generating false PIM protocol messages or even
   by generating data false traffic.

It should say:

See notes.

Notes:

What does “or even by generating data false traffic” mean?

[Adrian Farrel] Clearly "or even by generating false data traffic."

Errata ID: 1202
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel

Section A.2 says:

   o If the router receives a (S,G) prune alert, it will need to set
     DownstreamJPState(S,G,rpt,I) to PRUNE on the discard interface.

It should say:

   o If the router receives an (S,G) prune alert, it will need to set
     DownstreamJPState(S,G,rpt,I) to PRUNE on the discard interface.

Notes:

Misspelling.

Errata ID: 2662
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ang Way Chuang
Date Reported: 2010-12-08
Held for Document Update by: Adrian Farrel

Section 4.1.4 says:

PIM (S,G) Join/Prune state is the result of receiving PIM (S,G)
Join/Prune messages on this interface and is specified in Section
4.5.2. 

It should say:

PIM (S,G) Join/Prune state is the result of receiving PIM (S,G)
Join/Prune messages on this interface and is specified in Section
4.5.3. 

Notes:

Section 4.5.2 deals with (*,G) Join/Prune messages, not (S,G) Join/Prune messages.

Errata ID: 4027
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramakrishna DTV
Date Reported: 2014-06-26
Held for Document Update by: Alia Atlas
Date Held: 2014-07-01

Section 4.8.2 says:

     if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined ) {
         oiflist = inherited_olist(S,G)
     } else if( iif is in inherited_olist(S,G) ) {
         send Assert(S,G) on iif
     }

     oiflist = oiflist (-) iif
     forward packet on all interfaces in oiflist

It should say:

     oiflist = NULL

     if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined ) {
         oiflist = inherited_olist(S,G)
     } else if( iif is in inherited_olist(S,G) ) {
         send Assert(S,G) on iif
     }

     oiflist = oiflist (-) iif
     forward packet on all interfaces in oiflist

Notes:

The followng line is missing:

oiflist = NULL

Without this, it may lead to accessing uninitialized variable
oiflist. This line is present in Section 4.2 from which the simplified
SSM specific pseudo code is derived.

RFC 4606, "Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", August 2006

Note: This RFC has been updated by RFC 6344

Source of RFC: ccamp (rtg)

Errata ID: 2804
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Held for Document Update by: Adrian Farrel
Date Held: 2012-04-03

 

(2)  typo

In Section 3, at the bottom of page 11, the RFC says:

                     [...].  The standard definition for virtual
   concatenation allows each virtual concatenation components to travel
   over diverse paths.  [...]
                                                            ^
It should say:

                     [...].  The standard definition for virtual
|  concatenation allows each virtual concatenation component to travel
   over diverse paths.  [...]

or perhaps better:

                     [...].  The standard definition for virtual
|  concatenation allows the virtual concatenation components to travel
   over diverse paths.  [...]

(4)  inconsistency in examples

Still within Section 3, in the lower half of page 15,
under the headline:

   Examples of Labels

there are multiple occurrances of an index shift that makes the text
inconsistent with the tables on page 14 and the upper half of page 15.
E.g., "Kth-1" for "K>0" would result in "0th, 1st, 2nd" where the
appropriate table (at tho bottom of page 14) gives "1st, 2nd, 3rd" :

    K    SDH VC-4
   ---------------
    0    other
    1    1st TUG-3
    2    2nd TUG-3
    3    3rd TUG-3

Hence,
a)
                                                   vv
|  Example 2: the label for the VC-3 within the Kth-1 TUG-3 within
              the VC-4 in the Sth AUG-1 is: S>0, U=0, K>0, L=0, M=0.

should be corrected to say:

|  Example 2: the label for the VC-3 within the Kth TUG-3 within the
              VC-4 in the Sth AUG-1 is: S>0, U=0, K>0, L=0, M=0.

b)
                                   vv
|  Example 3: the label for the Uth-1 STS-1_SPE/VC-3 within the Sth
              STS-3/AUG-1 is: S>0, U>0, K=0, L=0, M=0.

should be corrected to say:

|  Example 3: the label for the Uth STS-1_SPE/VC-3 within the Sth
              STS-3/AUG-1 is: S>0, U>0, K=0, L=0, M=0.

c)
                                                   vv
|  Example 4: the label for the VT6/VC-2 in the Lth-1 VT Group/TUG-2
|             in the Uth-1 STS-1_SPE/VC-3 within the Sth STS-3/AUG-1
                        ^^
              is: S>0, U>0, K=0, L>0, M=0.

should be corrected to say:

|  Example 4: the label for the VT6/VC-2 in the Lth VT Group/TUG-2
|             in the Uth STS-1_SPE/VC-3 within the Sth STS-3/AUG-1
              is: S>0, U>0, K=0, L>0, M=0.

and
d)
                                                              vv
|  Example 5: the label for the 3rd VT1.5_SPE/VC-11 in the Lth-1 VT
|             Group/TUG-2 within the Uth-1 STS-1_SPE/VC-3 within the
                                        ^^
              Sth STS-3/AUG-1 is: S>0, U>0, K=0, L>0, M=8.

should be corrected to say:

|  Example 5: the label for the 3rd VT1.5_SPE/VC-11 in the Lth VT
|             Group/TUG-2 within the Uth STS-1_SPE/VC-3 within the
              Sth STS-3/AUG-1 is: S>0, U>0, K=0, L>0, M=8.


(5)  incomplete example

In Annex 1, at the bottom of page 21, the last list item says:

   10.  An STS-1-3v SPE signal is formed by the application of RCC with
        value 0, NVC with value 3 (virtual concatenation of 3
        components), MT with value 1, and T with value 0 to an STS-1 SPE
        Elementary Signal.

This text does not specify the significant NCC value.
It should say instead:

   10.  An STS-1-3v SPE signal is formed by the application of RCC with
|       value 0, NCC with value 0, NVC with value 3 (virtual
        concatenation of 3 components), MT with value 1, and T with
        value 0 to an STS-1 SPE Elementary Signal.

Notes:

This Erratum was duplicated from Erratum 43 in order to separate the issues raised. Note that the remaining issues in this Erratum are typos or within examples, hence the Erratum is reclassified as Editorial.

RFC 4616, "The PLAIN Simple Authentication and Security Layer (SASL) Mechanism", August 2006

Note: This RFC has been updated by RFC 8996

Source of RFC: sasl (sec)

Errata ID: 2629
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2010-11-12
Held for Document Update by: Tim Polk

Section 1 says:

   Specifications for IETF protocols that indicate that this
   mechanism is an applicable authentication mechanism MUST mandate that
   implementations support an strong data security service, such as TLS.

It should say:

   Specifications for IETF protocols that indicate that this
   mechanism is an applicable authentication mechanism MUST mandate that
   implementations support a strong data security service, such as TLS.

Notes:

Just a typo in "a strong data security service".

RFC 4627, "The application/json Media Type for JavaScript Object Notation (JSON)", July 2006

Note: This RFC has been obsoleted by RFC 7159

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 3607
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Bjoern Hoehrmann
Date Reported: 2013-04-27
Held for Document Update by: Barry Leiba
Date Held: 2013-05-01

Section 6 says:

   A JSON text can be safely passed into JavaScript's eval() function
   (which compiles and executes a string) if all the characters not
   enclosed in strings are in the set of characters that form JSON
   tokens.  This can be quickly determined in JavaScript with two
   regular expressions and calls to the test and replace methods.

      var my_JSON_object = !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test(
             text.replace(/"(\\.|[^"\\])*"/g, ''))) &&
         eval('(' + text + ')');

It should say:

[OBSOLETE]

Notes:

Executing the following code in Microsoft Internet Explorer 9

var text = "\
+{ \"valueOf\": self[\"location\"],\
\"toString\": [][\"join\"],\
0: \"javascript:alert('EXPLOIT')\",\
\"length\": 1\
}"

var my_JSON_object = !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test(
text.replace(/"(\\.|[^"\\])*"/g, ''))) &&
eval('(' + text + ')');

results in an "alert" message of "EXPLOIT", i.e. part of the data is executed as if it was executable code, which the validation code in the RFC is supposed to rule out.

Credit is due to Stefano Di Paola's http://blog.mindedsecurity.com/2011/08/ye-olde-crockford-json-regexp-is.html article, and possibly others the reporter does not know of.

----- NOTES FROM THE DOCUMENT AUTHOR -----
That section is completely obsolete. The recommendation now is to not use eval at all, and instead use JSON.parse.

That section should be replaced entirely with language independent advice on proper encoding and decoding, including avoidance of concatenation to construct JSON texts.

----- NOTES FROM THE VERIFIER -----
The resolution of this is more involved than can be handled by errata, and a document update is planned soon... so this will be "held for document update." It's important to note that the premise is correct: the "eval()" mechanism is NOT RECOMMENDED, and this text will be entirely replaced when the document is updated.

RFC 4632, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", August 2006

Source of RFC: grow (ops)

Errata ID: 1577
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Tony Li
Date Reported: 2008-10-23
Held for Document Update by: Ron Bonica

Section 3.1 says:

   For example, the legacy "Class B" network 172.16.0.0, with an implied
   network mask of 255.255.0.0, is defined as the prefix 172.16.0.0/16,
   the "/16" indicating that the mask to extract the network portion of
   the prefix is a 32-bit value where the most significant 16 bits are
   ones and the least significant 16 bits are zeros.  Similarly, the
   legacy "Class C" network number 192.168.99.0 is defined as the prefix
   192.168.99.0/24; the most significant 24 bits are ones and the least
   significant 8 bits are zeros.

It should say:

   For example, the legacy "Class B" network 172.16.0.0, with an implied
   network mask of 255.255.0.0, is defined as the prefix 172.16.0.0/16,
   the "/16" indicating that the mask to extract the network portion of
   the prefix is a 32-bit value where the most significant 16 bits are
   ones and the least significant 16 bits are zeros.  Similarly, the
   legacy "Class C" network number 192.168.99.0 is defined as the prefix
   192.168.99.0/24; the most significant 24 bits are ones and the least
   significant 8 bits are zeros.

   In cases where a prefix has 1, 2, or 3 trailing insignificant
   octets, it is permissible to elide the insignificant octets and
   trailing '.' separators. Thus, 172.16.0.0/16 may also be represented
   as 172.16/16, and 192.168.99.0/24 is equivalent to 192.168.99/24.

Notes:

This adds some clarifying text and documents a common convention for displaying prefixes. It was never the intention of the authors to exclude the alternative notation and it has since come into vogue. It should be explicitly documented as being acceptable.

Errata ID: 1824
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dande Rajasekhar
Date Reported: 2009-08-05
Held for Document Update by: Ron Bonica

Section 6.1 says:

To make this example more realistic, assume that C4 and C5 are multi-
   homed through some other service provider, "PB".  Further assume the
   existence of a site, "C7", that was originally connected to "RB" but
   that has moved to "PA".  For this reason, it has a block of network
   numbers that are assigned out PB's block of (the next) 2048 x /24.

   o  C7.  Assign 10.32.0 through 10.32.15.  This block is described by
      the route 10.32.0.0/20 (mask 255.255.240.0).

For the multi-homed sites, assume that C4 is advertised as primary
   via "RA" and secondary via "RB"; and that C5 is primary via "RB" and
   secondary via "RA".  In addition, assume that "RA" and "RB" are both
   connected to the same transit service provider, "BB".

   Graphically, this topology looks something like this:

   10.24.0.0 -- 10.24.7.0__         __10.32.0.0 - 10.32.15.0
   C1: 10.24.0.0/21        \       /  C7: 10.32.0.0/20
                            \     /
                             +----+                              +----+
   10.24.16.0 - 10.24.31.0_  |    |                              |    |
   C2: 10.24.16.0/20       \ |    |  _10.24.12.0 - 10.24.15.0__  |    |
                            \|    | / C4: 10.24.12.0/20        \ |    |
                             |    |/                            \|    |
   10.24.8.0 - 10.24.11.0___/| PA |\                             | PB |
   C3: 10.24.8.0/22          |    | \__10.24.32.0 - 10.24.33.0___|    |
                             |    |    C5: 10.24.32.0/23         |    |
                             |    |                              |    |
   10.24.34.0 - 10.24.35.0__/|    |                              |    |
   C6: 10.24.34.0/23         |    |                              |    |
                             +----+                              +----+
                               ||                                  ||
   routing advertisements:     ||                                  ||
                               ||                                  ||
           10.24.12.0/22 (C4)  ||              10.24.12.0/22 (C4)  ||
           10.32.0.0/20 (C7)   ||              10.24.32.0/23 (C5)  ||
           10.24.0.0/13 (PA)   ||              10.32.0.0/13 (PB)   ||
                               ||                                  ||
                               VV                                  VV
                            +---------- BACKBONE NETWORK BB ----------+

It should say:

To make this example more realistic, assume that C4 and C5 are multi-
   homed through some other service provider, "PB".  Further assume the
   existence of a site, "C7", that was originally connected to "PB" but
   that has moved to "PA".  For this reason, it has a block of network
   numbers that are assigned out PB's block of (the next) 2048 x /24.

   o  C7.  Assign 10.32.0 through 10.32.15.  This block is described by
      the route 10.32.0.0/20 (mask 255.255.240.0).

For the multi-homed sites, assume that C4 is advertised as primary
   via "PA" and secondary via "PB"; and that C5 is primary via "PB" and
   secondary via "PA".  In addition, assume that "PA" and "PB" are both
   connected to the same transit service provider, "BB".

   Graphically, this topology looks something like this:

   10.24.0.0 -- 10.24.7.0__         __10.32.0.0 - 10.32.15.0
   C1: 10.24.0.0/21        \       /  C7: 10.32.0.0/20
                            \     /
                             +----+                              +----+
   10.24.16.0 - 10.24.31.0_  |    |                              |    |
   C2: 10.24.16.0/20       \ |    |  _10.24.12.0 - 10.24.15.0__  |    |
                            \|    | / C4: 10.24.12.0/20        \ |    |
                             |    |/                            \|    |
   10.24.8.0 - 10.24.11.0___/| PA |\                             | PB |
   C3: 10.24.8.0/22          |    | \__10.24.32.0 - 10.24.33.0___|    |
                             |    |    C5: 10.24.32.0/23         |    |
                             |    |                              |    |
   10.24.34.0 - 10.24.35.0__/|    |                              |    |
   C6: 10.24.34.0/23         |    |                              |    |
                             +----+                              +----+
                               ||                                  ||
   routing advertisements:     ||                                  ||
                               ||                                  ||
           10.24.12.0/22 (C4)  ||              10.24.12.0/22 (C4)  ||
           10.32.0.0/20 (C7)   ||              10.24.32.0/23 (C5)  ||
           10.24.0.0/13 (PA)   ||              10.32.0.0/13 (PB)   ||
                               ||                                  ||
                               VV                                  VV
                            +---------- BACKBONE NETWORK BB ----------+

Notes:

All the reference of "RA" and "RB" to be replaced with "PA" and "PB".

RFC 4634, "US Secure Hash Algorithms (SHA and HMAC-SHA)", July 2006

Note: This RFC has been obsoleted by RFC 6234

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 2415
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.1 says:

The initial Description in the file, on page 18 of the RFC, says:

                                             vvvvvvvvvvvvvvvvvv
 *  Description:
 *      This file implements the Secure Hash Signature Standard
 *      algorithms as defined in the National Institute of Standards
 *      and Technology Federal Information Processing Standards
 *      Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2
 *      published on August 1, 2002, and the FIPS PUB 180-2 Change
 *      Notice published on February 28, 2004.

It should say:

It should say:

 *  Description:
|*      This file implements the Secure Hash Algorithms
 *      as defined in the National Institute of Standards
 *      and Technology Federal Information Processing Standards
 *      Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2
 *      published on August 1, 2002, and the FIPS PUB 180-2 Change
 *      Notice published on February 28, 2004.

Notes:

Avoiding the term "Signature" in accordance with the Standards
mentioned. The NIST consistently uses the acronyms "SHA" for
"Secure Hash Algorithm" and "SHS" for "Secure Hash Standard"
and precisely distinguished between these two terms.

Errata ID: 2426
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.2.2 says:

Similar to item (9) above, the Description comment of SHA224Result
contains improper wording and unpleasent formatting. Additionally,
counting 28 elements as ranging from the "0th" up to the "28th" is
unpleasant and wrong -- it would indicate 29 elements (octets) !

On mid-page 36, the RFC says:

 * Description:
 *   This function will return the 224-bit message
 *   digest into the Message_Digest array provided by the caller.
 *   NOTE: The first octet of hash is stored in the 0th element,
 *      the last octet of hash in the 28th element.

For correctness and consistency, and for improved readability,
it should say:

 * Description:
 *   This function will return the 224-bit message digest
 *   into the Message_Digest array provided by the caller.
 *   NOTE:
 *    The first octet of the hash is stored in the element with index 0,
 *    the last octet of the hash in the element with index 27.

Errata ID: 37
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.2.1 says:

The Description of SHA1PadMessage, on page 30, says:

 * Description:
 *   According to the standard, the message must be padded to an
 *   even 512 bits. The first padding bit must be a '1'. The last
 *   64 bits represent the length of the original message. All bits
 *   in between should be 0. This helper function will pad the
 *   message according to those rules by filling the Message_Block
 *   array accordingly. When it returns, it can be assumed that the
 *   message digest has been computed.

For clarity, it should say:

 * Description:
|*   According to the standard, the message must be padded to the next
|*   proper multiple of 512 bits. The first padding bit must be a '1'.
 *   The last 64 bits represent the length of the original message.
 *   All bits in between should be 0. This helper function will pad
 *   the message according to those rules by filling the Message_Block
 *   array accordingly. When it returns, it can be assumed that the
 *   message digest has been computed.

Errata ID: 2421
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.2.1 says:

The Description of SHA1ProcessMessageBlock, on page 31, says:

 * Parameters:
 *   None.

This is not true, as can be seen subsequently in the source code.
The RFC should say:

 * Parameters:
 *   context: [in/out]
 *     The SHA context to update

Errata ID: 2422
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.2.2 says:

The initial Description in this file, on page 33, says:

 * Description:
 *   This file implements the Secure Hash Signature Standard
 *   algorithms as defined in the National Institute of Standards
 *   and Technology Federal Information Processing Standards
 *   Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2
 *   published on August 1, 2002, and the FIPS PUB 180-2 Change
 *   Notice published on February 28, 2004.

It should say:

 * Description:
 *   This file implements the Secure Hash Algorithms SHA-224 and
 *   SHA-256, as defined in the National Institute of Standards
 *   and Technology Federal Information Processing Standards
 *   Publication (FIPS PUB) 180-2 published on August 1, 2002, and
 *   the FIPS PUB 180-2 Change Notice published on February 28, 2004.

Rationale:

FIPS-PUB 180-1 only specified SHA-1, neither SHA-224 nor SHA-256.
FIPS-PUB 180-2 has introduced SHA-256 (and SHA-384 and SHA-512 as
well), and SHA-224 has been introduced by the "Change Notice 1".
Thus, citation of FIPS PUB 180-1 is void and inappropriate in the
context of SHA-224 and SHA-256.
Avoiding the term "Signature" also conforms to the above Standards
-- cf. item (4) and (5) above.
Restricting the text to the scope of the file -- cf. item (5) above.

Errata ID: 2423
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.2.2 says:

The comment text, near the bottom of page 33, says:

 * Caveats:
 *   SHA-224 and SHA-256 are designed to work with messages less
 *   than 2^64 bits long. This implementation uses SHA224/256Input()
 *   to hash the bits that are a multiple of the size of an 8-bit
 *   character, and then uses SHA224/256FinalBits() to hash the
 *   final few bits of the input.

It should better say -- cf. item (6) above:

 * Caveats:
 *   SHA-224 and SHA-256 are designed to work with messages less
 *   than 2^64 bits long. This implementation uses SHA224/256Input()
 *   to hash the bits that are a multiple of the size of an 8-bit
|*   character, and then optionally uses SHA224/256FinalBits()
 *   to hash the final few bits of the input.

Errata ID: 2424
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.2.2 says:

On mid-page 34, there is the code:

/*
 * add "length" to the length
 */
static uint32_t addTemp;
#define SHA224_256AddLength(context, length)               \
  (addTemp = (context)->Length_Low, (context)->Corrupted = \
    (((context)->Length_Low += (length)) < addTemp) &&     \
    (++(context)->Length_High == 0) ? 1 : 0)

It should say (modifying the last line):

/*
 * add "length" to the length
 */
static uint32_t addTemp;
#define SHA224_256AddLength(context, length)               \
  (addTemp = (context)->Length_Low, (context)->Corrupted = \
    (((context)->Length_Low += (length)) < addTemp) &&     \
    (++(context)->Length_High == 0) ? shaInputTooLong : shaSuccess )

Rationale:  Same as for item (7) above.

Errata ID: 2427
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.2.2 says:

Similar to item (9) and (16) above, the Description of SHA256Result
contains improper wording and unpleasent formatting. Additionally,
counting 32 elements as ranging from the "0th" up to the "32nd" is
unpleasant and wrong -- it would indicate 33 elements (octets) !

On page 39, the RFC says:

 * Description:
 *   This function will return the 256-bit message
 *   digest into the Message_Digest array provided by the caller.
 *   NOTE: The first octet of hash is stored in the 0th element,
 *      the last octet of hash in the 32nd element.

For correctness and consistency, and for improved readability,
it should say:

 * Description:
 *   This function will return the 256-bit message digest
 *   into the Message_Digest array provided by the caller.
 *   NOTE:
 *    The first octet of the hash is stored in the element with index 0,
 *    the last octet of the hash in the element with index 31.

Errata ID: 2429
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.2.2 says:

The Description of SHA224_256PadMessage, near the bottom of page 40,
says:

 * Description:
 *   According to the standard, the message must be padded to an
 *   even 512 bits. The first padding bit must be a '1'. The
 *   last 64 bits represent the length of the original message.
 *   All bits in between should be 0. This helper function will pad
 *   the message according to those rules by filling the
 *   Message_Block array accordingly. When it returns, it can be
 *   assumed that the message digest has been computed.

For clarity, it should say (cf. item (10) above):

 * Description:
|*   According to the standard, the message must be padded to the next
|*   proper multiple of 512 bits. The first padding bit must be a '1'.
 *   The last 64 bits represent the length of the original message.
 *   All bits in between should be 0. This helper function will pad
 *   the message according to those rules by filling the
 *   Message_Block array accordingly. When it returns, it can be
 *   assumed that the message digest has been computed.

Errata ID: 2435
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.2.3 says:

Within the '#ifdef USE_32BIT_ONLY' macro definition branch of the
file, on mid-page 50 the RFC says:

/*
 * add "length" to the length
 */
static uint32_t addTemp[4] = { 0, 0, 0, 0 };
#define SHA384_512AddLength(context, length) (                        \
    addTemp[3] = (length), SHA512_ADDTO4((context)->Length, addTemp), \
    (context)->Corrupted = (((context)->Length[3] == 0) &&            \
       ((context)->Length[2] == 0) && ((context)->Length[1] == 0) &&  \
       ((context)->Length[0] < 8)) ? 1 : 0 )

It should say:

/*
 * add "length" to the length
 */
static uint32_t addTemp[4] = { 0, 0, 0, 0 };
#define SHA384_512AddLength(context, length) (                        \
    addTemp[3] = (length), SHA512_ADDTO4((context)->Length, addTemp), \
    (context)->Corrupted = (((context)->Length[0] < addTemp[3]) &&    \
       ((context)->Length[1] == 0) && ((context)->Length[1] == 0) &&  \
       ((context)->Length[0] == 0)) ? shaInputTooLong : shaSuccess )

Rationale:

The context words  Lenght[0] ... Length[3]  represent the unsigned
128-bit-wide running (bit-)length of the message text hash so far,
in most-significant word first order.
The code fragment above is intended to add to this value the
unsigned 32-bit value (uint32_t) length, and to detect overflow
(to 2^128 and above).
The given code is wrong.
(Apparently it has never been tested with messages long enough to
exhibit this misbehaviour.)
Other parts of the sample code show how this can be done correctly
in the case of long accumulators consisting of two 32-bit words
-- cf. the code snippits in item (7) and (14) above, and item (27)
below, as well,
The replacement code corrects this issue.

Furthermore, the original code suffers from the same problem as
in item (7) and (14) above; this has been corrected accordingly,
as well.

Errata ID: 2437
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.2.3 says:

The sample code presents almost all formal function arguments of type
array with predefined (constant) length with this explicit length.
Contrary to that, the function prototypes for SHA384_512Reset do not
supply the expected size of the formal argument 'H0'.
This inconsistency should be corrected -- as in item (18) above.

There are two instances of the issue (see item (xx) below for
another two similar instances, with the function declarations):

(28a)
Within the function prototype definition part of the
  '#ifdef USE_32BIT_ONLY'
branch of the sample code, near the bottom of page 50, the RFC says:

static int SHA384_512Reset(SHA512Context *context, uint32_t H0[]);

For consistency and clarity, it should say:

static int SHA384_512Reset(SHA512Context *context,
                           uint32_t H0[SHA512HashSize/4]);

(28b)
Within the function prototype definition part of the
  '#else /* !USE_32BIT_ONLY */'
branch of the sample code, near the bottom of page 51, the RFC says:

static int SHA384_512Reset(SHA512Context *context, uint64_t H0[]);

For consistency and clarity, it should say:

static int SHA384_512Reset(SHA512Context *context,
                           uint64_t H0[SHA512HashSize/8]);

Errata ID: 2441
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.2.3 says:

Similar to item (9), (16), (17), (22), (29), and (30) above, the
Description of SHA384_512ResultN contains improper wording.
Additionally, counting 48/64 elements as ranging from the "0th" up to
the "48th/64nd" is unpleasant and wrong -- that erroneously indicates
49/65 elements (octets) !

On page 65/66, the RFC says:

 * Description:
 *   This helper function will return the 384-bit or 512-bit message
<< page break >>
 *   digest into the Message_Digest array provided by the caller.
 *   NOTE: The first octet of hash is stored in the 0th element,
 *      the last octet of hash in the 48th/64th element.

For correctness, it should say:

 * Description:
 *   This helper function will return the 384-bit or 512-bit message
<< page break >>
 *   digest into the Message_Digest array provided by the caller.
 *   NOTE:
 *    The first octet of the hash is stored in the element with index 0,
 *    the last octet of the hash in the element with index 47/63.

Errata ID: 2413
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 3 says:

The last two text lines of Section 3, on mid-page 6, say:
                                 v
|            ROTL^n(x) = ROTR^(w-x)(x)

             ROTR^n(x) = ROTL^(w-n)(x)

It should say:

They should say:
                                 v
|            ROTL^n(x) = ROTR^(w-n)(x)

             ROTR^n(x) = ROTL^(w-n)(x)

Errata ID: 747
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.2.2 says:

The Description of SHA224_256ProcessMessageBlock, on top of page 42,
says:

 * Description:
 *   This function will process the next 512 bits of the message
 *   stored in the Message_Block array.

Consistently with the remainder of the test, it should say:

 * Description:
|*   This helper function will process the next 512 bits of the
 *   message stored in the Message_Block array.

Errata ID: 2430
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.2.2 says:

Near the bottom of page 43, the Description of SHA224_256Reset says:

 * Description:
 *   This helper function will initialize the SHA256Context in
 *   preparation for computing a new SHA256 message digest.

For completeness and consistency, it should say:

 * Description:
 *   This helper function will initialize the SHA256Context in
|*   preparation for computing a new SHA-224 or SHA-256 message digest.
                                     ^^^^^^^^^^    ^

Errata ID: 2432
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.2.3 says:

The initial Description in this file, on page 45, says:

 * Description:
 *   This file implements the Secure Hash Signature Standard
 *   algorithms as defined in the National Institute of Standards
 *   and Technology Federal Information Processing Standards
 *   Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2
 *   published on August 1, 2002, and the FIPS PUB 180-2 Change
 *   Notice published on February 28, 2004.

It should say:

 * Description:
 *   This file implements the Secure Hash Algorithms SHA-384 and
 *   SHA-512, as defined in the National Institute of Standards
 *   and Technology Federal Information Processing Standards
 *   Publication (FIPS PUB) 180-2 published on August 1, 2002, and
 *   the FIPS PUB 180-2 Change Notice published on February 28, 2004.

Rationale:

FIPS-PUB 180-1 only specified SHA-1, neither SHA-384 nor SHA-512.
FIPS-PUB 180-2 has introduced SHA-384 and SHA-512 (and SHA-256 as
well), and the "Change Notice 1" has introduced SHA-224.
Thus, citation of FIPS PUB 180-1 is void and inappropriate in the
context of SHA-384 and SHA-512.
Avoiding the term "Signature" also conforms to the above Standards
-- cf. item (4), (5), and (12) above.
Restricting the text to the scope of the file -- cf. item (5) and
(12) above.

Errata ID: 2436
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.2.3 says:

Within the '#ifndef USE_32BIT_ONLY' macro definition branch of the
file, on mid-page 51 the RFC says:

/*
 * add "length" to the length
 */
static uint64_t addTemp;
#define SHA384_512AddLength(context, length)                   \
   (addTemp = context->Length_Low, context->Corrupted =        \
    ((context->Length_Low += length) < addTemp) &&             \
    (++context->Length_High == 0) ? 1 : 0)

It should say:

/*
 * add "length" to the length
 */
static uint64_t addTemp;
#define SHA384_512AddLength(context, length)                   \
   (addTemp = (context)->Length_Low, (context)->Corrupted =    \
    (((context)->Length_Low += length) < addTemp) &&           \
    (++(context)->Length_High == 0) ? shaInputTooLong : shaSuccess )

Rationale:

Same as for item (7) and (14) above, cf. item (26) as well.

Additionally, parentheses have been added around all invocations of
the macro argument `context` to protect it against various artifacts,
as has been done consistently in the remainder of the sample code.

Errata ID: 2438
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.2.3 says:

Similar to item (9), (16), (17), and (22) above, the Description
of SHA384Result contains improper wording and unpleasent formatting.
Additionally, counting 48 elements as ranging from the "0th" up to the
"48th" is unpleasant and wrong -- indicating 49 elements (octets) !

Near the bottom of page 53, the RFC says:

 * Description:
 *   This function will return the 384-bit message
 *   digest into the Message_Digest array provided by the caller.
 *   NOTE: The first octet of hash is stored in the 0th element,
 *      the last octet of hash in the 48th element.

For correctness and consistency, and for improved readability,
it should say:

 * Description:
 *   This function will return the 384-bit message digest
 *   into the Message_Digest array provided by the caller.
 *   NOTE:
 *    The first octet of the hash is stored in the element with index 0,
 *    the last octet of the hash in the element with index 47.

Errata ID: 2445
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.3 says:

On mid-page 75, the comment within the function hmacReset says:

   * The HMAC transform looks like:
   *
   * SHA(K XOR opad, SHA(K XOR ipad, text))
   *
   * where K is an n byte key.
   * ipad is the byte 0x36 repeated blocksize times
   * opad is the byte 0x5c repeated blocksize times
   * and text is the data being protected.

It should say:

   * The HMAC transform looks like:
   *
   * SHA(K XOR opad, SHA(K XOR ipad, text))
   *
|  * where K is an n byte key, 0-padded to a total of blocksize bytes,
|  * ipad is the byte 0x36 repeated blocksize times,
|  * opad is the byte 0x5c repeated blocksize times,
   * and text is the data being protected.

Rationale:

Without the addition, the 'XOR' operations in the formula are
undefined.  Additionally, punctuation is made uniform.

Errata ID: 2447
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.4 says:

The initial Description of the file, as presented on page 78,
contains in its first paragraph the lines:

 *      the seven tests documented for each algorithm in
 *        "The Secure Hash Algorithm Validation System (SHAVS)",
 *        three of which are bit-level tests
 *        (http://csrc.nist.gov/cryptval/shs/SHAVS.pdf)

For clarity, it should better say:

 *      the seven tests documented for each algorithm in
|*        "The Secure Hash Algorithm Validation System (SHAVS)"
|*        (http://csrc.nist.gov/cryptval/shs/SHAVS.pdf),
|*        three of which are bit-level tests

Errata ID: 2449
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.4 says:

On mid-page 91, there is the comment:

/*
 * Print the string, converting non-printable characters to hex "## ".
 */

It should say:

/*
 * Print the string, converting all characters to hex "## ".
 */

Rationale:

There is a significant mismatch between the comment and the
subsequent code.
This is being resolved by the replacement text.

Errata ID: 748
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.2.3 says:

Similar to item (9), (16), (17), (22), and (29) above, the Description
of SHA512Result contains improper wording and unpleasent formatting.
Additionally, counting 64 elements as ranging from the "0th" up to the
"64th" is unpleasant and wrong -- indicating 65 elements (octets) !

Near the bottom of page 44, the RFC says:

 * Description:
 *   This function will return the 512-bit message
 *   digest into the Message_Digest array provided by the caller.
 *   NOTE: The first octet of hash is stored in the 0th element,
 *      the last octet of hash in the 64th element.


For correctness and consistency, and for improved readability,
it should say:

 * Description:
 *   This function will return the 512-bit message digest
 *   into the Message_Digest array provided by the caller.
 *   NOTE:
 *    The first octet of the hash is stored in the element with index 0,
 *    the last octet of the hash in the element with index 63.

Errata ID: 2439
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.2.3 says:

The Description of SHA384_512PadMessage, on page 58, says:

 * Description:
 *   According to the standard, the message must be padded to an
 *   even 1024 bits. The first padding bit must be a '1'. The
 *   last 128 bits represent the length of the original message.
 *   All bits in between should be 0. This helper function will
 *   pad the message according to those rules by filling the
 *   Message_Block array accordingly. When it returns, it can be
 *   assumed that the message digest has been computed.

For clarity, it should say (cf. items (10) and (19) above):

 * Description:
|*   According to the standard, the message must be padded to the next
|*   proper multiple of 1024 bits. The first padding bit must be a '1'.
 *   The last 128 bits represent the length of the original message.
 *   All bits in between should be 0. This helper function will
 *   pad the message according to those rules by filling the
 *   Message_Block array accordingly. When it returns, it can be
 *   assumed that the message digest has been computed.

Errata ID: 2443
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.3 says:

The code for (the message oriented) function hmac,
on page 73/74, reads:

int hmac(SHAversion whichSha, const unsigned char *text, int text_len,
    const unsigned char *key, int key_len,
    uint8_t digest[USHAMaxHashSize])
<< page break >>
{
  HMACContext ctx;
  return hmacReset(&ctx, whichSha, key, key_len) ||
         hmacInput(&ctx, text, text_len) ||
         hmacResult(&ctx, digest);
}

It should say:

int hmac(SHAversion whichSha,
         const unsigned char *message_array, int length,
         const unsigned char *key, int key_len,
         uint8_t digest[USHAMaxHashSize])
<< page break >>
{
  HMACContext ctx;
  return hmacReset(&ctx, whichSha, key, key_len) ||
         hmacInput(&ctx, message_array, length) ||
         hmacResult(&ctx, digest);
}

Rationale:

The argument names `message_array` and `length` are used
throughout the sample code, including the Description of the
function hmac, on page 73.
The code shown above was not aligned with this practise and
hence inconsistent with the Description.
This has been resolved by the proposed update, bay changing
the names of 'text' and 'text_len'.

>>>>>  NOTE / Caution :
>>>>>
>>>>>  Similar (and additional) inconsistencies between the
>>>>>  argument names in the 'Parameters:' documentation
>>>>>  and the variable names used in the subsequent code
>>>>>  exist for all hmac* functions, on pages 74..77 ;
>>>>>  in particular, the described 'context' is always
>>>>>  named `ctx` in the code.
>>>>>  Also, capitalization of the leading "HMAC"/"hmac"
>>>>>  in the function names is totally inconsistent.
>>>>>
>>>>>  Resolution of these issues is left as an exercise
>>>>>  to the reader of this note -- or the author of any
>>>>>  future update of the sample code.
>>>>>
>>>>>  Furthermore, the use of "characters" as units of the
>>>>>  message_text in the descriptions is dangerous in the
>>>>>  days of Unicode and UTF-8; "characters" should better
>>>>>  be replaced by "octets" throughout hmac.c !

Errata ID: 750
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.4 says:

on mid-page 96, the code section,

  if (bitcount > 0)
    err = keyarray ? hmacFinalBits(&hmac, bits, bitcount) :
                   USHAFinalBits(&sha, bits, bitcount);
  if (err != shaSuccess) {
    fprintf(stderr, "hashfile(): %s Error %d.\n",
            keyarray ? "hmacResult" : "shaResult", err);
    if (hashfp != stdin) fclose(hashfp);
    return err;
  }

should in fact say:

  if (bitcount > 0)
    err = keyarray ? hmacFinalBits(&hmac, bits, bitcount) :
                   USHAFinalBits(&sha, bits, bitcount);
  if (err != shaSuccess) {
    fprintf(stderr, "hashfile(): %s Error %d.\n",
            keyarray ? "hmacFinalBits" : "shaFinalBits", err);
    if (hashfp != stdin) fclose(hashfp);
    return err;
  }

Rationale:

Self-evident; perhaps cloning error.

Errata ID: 2412
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 3 says:

Section 3 of RFC 4634, on page 5, defines the elementary word
operations to be used subsequently in the text, including the
left shift operation, '<<'.  Unfortunately, the right shift
operation '>>' is used frequently as well, but not defined
in Section 3.

I propose to amend the second paragraph of Section 3, on page 5,

   In the operations below, x<<n is obtained as follows: discard the
   left-most n bits of x and then pad the result with n zeroed bits on
   the right (the result will still be the same number of bits).

It should say:

to read:

   In the operations below, x<<n is obtained as follows: discard the
   left-most n bits of x and then pad the result with n zeroed bits on
   the right (the result will still be the same number of bits).
|  Similarly, x>>n is obtained as follows: discard the right-most n bits
|  of x and then prepend the result with n zeroed bits on the left (the
|  result will still be the same number of bits).

Errata ID: 2428
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.2.2 says:

The sample code presents almost all formal function arguments of type
array with predefined (constant) length with this explicit length.
Contrary to that, the definition of SHA256Result does not supply
the expected size of the formal argument 'Message_Digest'.

At the bottom of page 39, RFC 4634 says:

int SHA256Result(SHA256Context *context, uint8_t Message_Digest[])
{

For consistency and clarity, it should say:

int SHA256Result(SHA256Context *context,
                 uint8_t Message_Digest[SHA256HashSize])
{

Errata ID: 2431
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.2.2 says:

Similar to item (9), (16), and (17) above, the Description of
SHA224_256ResultN contains improper wording. Additionally,
counting 28/32 elements as ranging from the "0th" up to the
"28th/32nd" is unpleasant and wrong -- that erroneously indicates
29/33 elements (octets) !

Near the bottom of page 44, the RFC says:

 * Description:
 *   This helper function will return the 224-bit or 256-bit message
 *   digest into the Message_Digest array provided by the caller.
 *   NOTE: The first octet of hash is stored in the 0th element,
 *      the last octet of hash in the 28th/32nd element.

For correctness and consistency, it should say:

 * Description:
 *   This helper function will return the 224-bit or 256-bit message
 *   digest into the Message_Digest array provided by the caller.
 *   NOTE:
 *    The first octet of the hash is stored in the element with index 0,
 *    the last octet of the hash in the element with index 27/31.

Errata ID: 2433
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.2.3 says:

The comment text, near the top of page 46, says:

 * Caveats:
 *   SHA-384 and SHA-512 are designed to work with messages less
 *   than 2^128 bits long. This implementation uses
 *   SHA384/512Input() to hash the bits that are a multiple of the
 *   size of an 8-bit character, and then uses SHA384/256FinalBits()
 *   to hash the final few bits of the input.

It should better say -- cf. item (6) and (13) above:

 * Caveats:
 *   SHA-384 and SHA-512 are designed to work with messages less
 *   than 2^128 bits long. This implementation uses SHA384/512Input()
 *   to hash the bits that are a multiple of the size of an 8-bit
|*   character, and optionally then uses SHA384/256FinalBits()
 *   to hash the final few bits of the input.

Errata ID: 2442
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.2.3 says:

The Description for USHAResult, on top of page 69, says:

 * Description:
 *   This function will return the 160-bit message digest into the
 *   Message_Digest array provided by the caller.
 *   NOTE: The first octet of hash is stored in the 0th element,
 *      the last octet of hash in the 19th element.

It should say:

 * Description:
 *   This function will return the message digest of the appropriate
 *   bit size, as returned by USHAHashSizeBits(whichSHA) for the
 *   'whichSHA' value used in the preceeding call to USHAReset,
 *   into the Message_Digest array provided by the caller.

Rationale:

The given text roughly matches the SHA-1 case, it is wrong for all
other cases.  The arguments presented for items (9), (16), (17),
(22), (29), (30), and (33) above apply as well.
The changed text tries to remain precise while avoiding too much
repetition of facts presented elsewhere in the sample code.

Errata ID: 2444
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.3 says:

The Description of hmacResult, on top of page 77, says:

 * Description:
 *   This function will return the N-byte message digest into the
 *   Message_Digest array provided by the caller.
 *   NOTE: The first octet of hash is stored in the 0th element,
 *      the last octet of hash in the Nth element.

It should perhaps just say:

 * Description:
 *   This function will return the N-byte message digest into the
 *   Message_Digest array provided by the caller.

Rationale:
Cf. items (9), (16), (17), (22), (29), (30), and (33) above.
Full replacement text for the last two lines is deemed unnecessary.

Errata ID: 2446
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.3 says:

The Description of hmacResult, on top of page 77, says:

 * Description:
 *   This function will return the N-byte message digest into the
 *   Message_Digest array provided by the caller.
 *   NOTE: The first octet of hash is stored in the 0th element,
 *      the last octet of hash in the Nth element.

It should perhaps just say:

 * Description:
 *   This function will return the N-byte message digest into the
 *   Message_Digest array provided by the caller.

Rationale:
Cf. items (9), (16), (17), (22), (29), (30), and (33) above.
Full replacement text for the last two lines is deemed unnecessary.

Errata ID: 2418
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.2.1 says:

Near the top of page 25, there is the code:

/*
 * add "length" to the length
 */
static uint32_t addTemp;
#define SHA1AddLength(context, length)                     \
    (addTemp = (context)->Length_Low,                      \
     (context)->Corrupted =                                \
        (((context)->Length_Low += (length)) < addTemp) && \
        (++(context)->Length_High == 0) ? 1 : 0)

It should say:

It should say (modifying the last line):

/*
 * add "length" to the length
 */
static uint32_t addTemp;
#define SHA1AddLength(context, length)                     \
    (addTemp = (context)->Length_Low,                      \
     (context)->Corrupted =                                \
        (((context)->Length_Low += (length)) < addTemp) && \
        (++(context)->Length_High == 0) ? shaInputTooLong : shaSuccess )

Notes:

As can be found on page 19 (upper half), sha.h contains:

#ifndef _SHA_enum_
#define _SHA_enum_
/*
* All SHA functions return one of these values.
*/
enum {
shaSuccess = 0,
shaNull, /* Null pointer parameter */
shaInputTooLong, /* input data too long */
shaStateError, /* called Input after FinalBits or Result */
shaBadParam /* passed a bad parameter */
};
#endif /* _SHA_enum_ */

This leaves it to the compiler to assign values, but ordinarily,
shaNull will be assigned the value 1,
shaInputTooLong will be assigned the value 2, etc. ...

The value assigned to context->Corrupted in the #define listed
above will later on repeatedly be used to generate return values,
via code lines:
return context->Corrupted;

These return values are expected to be SHA_enum values.
In the case where Corrupted gets assigned the value 0, it apparently
was intended to eventually get the return value 'shaSuccess', and
in the case where Corrupted gets assigned the value 1, it apparently
was intended to eventually get the return value 'shaInputTooLong'.
With the code shown above, the former will work, but the latter
will usually *not* work as intended.

To obtain portable source code behaving as documented, the proposed
change has to be applied.

Errata ID: 1301
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Jan Andres
Date Reported: 2008-01-21
Held for Document Update by: Sean Turner

Section 6.2 says:

      1. Prepare the message schedule W:
         For t = 0 to 15
            Wt = M(i)t
         For t = 16 to 63
            Wt = SSIG1(W(t-2)) + W(t-7) + SSIG0(t-15) + W(t-16)

It should say:

      1. Prepare the message schedule W:
         For t = 0 to 15
            Wt = M(i)t
         For t = 16 to 63
            Wt = SSIG1(W(t-2)) + W(t-7) + SSIG0(W(t-15)) + W(t-16)

Notes:

Cf. FIPS180-2, section 6.2.2.
(http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf)

Errata ID: 1302
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Jan Andres
Date Reported: 2008-01-21
Held for Document Update by: Sean Turner

Section 6.4 says:

      1. Prepare the message schedule W:
         For t = 0 to 15
            Wt = M(i)t
         For t = 16 to 79
            Wt = SSIG1(W(t-2)) + W(t-7) + SSIG0(t-15) + W(t-16)

It should say:

      1. Prepare the message schedule W:
         For t = 0 to 15
            Wt = M(i)t
         For t = 16 to 79
            Wt = SSIG1(W(t-2)) + W(t-7) + SSIG0(W(t-15)) + W(t-16)

Notes:

Cf. FIPS180-2, section 6.3.2.
(http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf)

Errata ID: 2417
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.2.1 says:

The comment text, at the bottom of page 24, says:

 *  Caveats:
 *      SHA-1 is designed to work with messages less than 2^64 bits
 *      long. This implementation uses SHA1Input() to hash the bits
 *      that are a multiple of the size of an 8-bit character, and then
 *      uses SHA1FinalBits() to hash the final few bits of the input.
 */

It should say:

It should better say:

 *  Caveats:
 *      SHA-1 is designed to work with messages less than 2^64 bits
 *      long. This implementation uses SHA1Input() to hash the bits
 *      that are a multiple of the size of an 8-bit character, and then
|*      optionally uses SHA1FinalBits() to hash the final few bits of
 *      the input.
 */

Errata ID: 2414
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8 says:

In the introductory text in Section 8, function prototype arguments
are inconsistently presented; all should be presented in ANSI-C style
consistently.
Also, the indentation of two lines breaks the otherwise consistent
layout.

On mid-page 16, the lines,

   Functions:
|                 int SHA$$$Reset(SHA$$$Context *);
            Reset the hash context state
|     int SHA$$$Input(SHA$$$Context *, const uint8_t *octets,
                  unsigned int bytecount);
            Incorporate bytecount octets into the hash.

should read:

   Functions:
|     int SHA$$$Reset(SHA$$$Context *context);
            Reset the hash context state
|     int SHA$$$Input(SHA$$$Context *context, const uint8_t *octets,
                  unsigned int bytecount);
            Incorporate bytecount octets into the hash.

and on page 17, the lines,

   Functions:
|     int USHAReset(USHAContext *, SHAversion whichSha);
            Reset the hash context state.
|     int USHAInput(USHAContext *,
                  const uint8_t *bytes, unsigned int bytecount);
            Incorporate bytecount octets into the hash.
|     int USHAFinalBits(USHAContext *,
                  const uint8_t bits, unsigned int bitcount);
|                 Incorporate bitcount bits into the hash.

should read:

   Functions:
|     int USHAReset(USHAContext *context, SHAversion whichSha);
            Reset the hash context state.
|     int USHAInput(USHAContext *context,
                  const uint8_t *bytes, unsigned int bytecount);
            Incorporate bytecount octets into the hash.
|     int USHAFinalBits(USHAContext *context,
                  const uint8_t bits, unsigned int bitcount);
|           Incorporate bitcount bits into the hash.

Notes:

inconsistent prototypes, unpleasant/inconsistent indentation

Errata ID: 2416
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.2.1 says:

The initial Description in the file, on page 24 of the RFC, says:

                                             vvvvvvvvvvvvvvvvvv
 *  Description:
 *      This file implements the Secure Hash Signature Standard
 *      algorithms as defined in the National Institute of Standards
 *      and Technology Federal Information Processing Standards
 *      Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2
 *      published on August 1, 2002, and the FIPS PUB 180-2 Change
 *      Notice published on February 28, 2004.

It should say:

It should say:

 *  Description:
|*      This file implements the Secure Hash Algorithm SHA-1
 *      as defined in the National Institute of Standards
 *      and Technology Federal Information Processing Standards
 *      Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2
 *      published on August 1, 2002, and the FIPS PUB 180-2 Change
 *      Notice published on February 28, 2004.

Notes:

See Errata 2415.
Also replace "algorithms" by "Algorithm SHA-1" to properly match
the description with the scope of the file.

Errata ID: 2440
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.2.3 says:

The sample code presents almost all formal function arguments of type
array with predefined (constant) length with this explicit length.
Contrary to that, the function definitions for SHA384_512Reset do not
supply the expected size of the formal argument 'H0'.
This inconsistency should be corrected -- as in items (18) and (28)
above.

Near the top of page 65, RFC 4634 says:

#ifdef USE_32BIT_ONLY
static int SHA384_512Reset(SHA512Context *context, uint32_t H0[])
#else /* !USE_32BIT_ONLY */
static int SHA384_512Reset(SHA512Context *context, uint64_t H0[])
#endif /* USE_32BIT_ONLY */

For consistency and clarity, it should say:

#ifdef USE_32BIT_ONLY
static int SHA384_512Reset(SHA512Context *context,
                           uint32_t H0[SHA512HashSize/4]);
#else /* !USE_32BIT_ONLY */
static int SHA384_512Reset(SHA512Context *context,
                           uint64_t H0[SHA512HashSize/8]);
#endif /* USE_32BIT_ONLY */

Errata ID: 2419
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.2.1 says:

Througout the sample source code, ANSI-C style is used for the
function prototypes, i.e. giving type and name for function
arguments.  This rule is broken on mid-page 25, just below
the offending snippit from item (5) above.
For consistency and portability, the source code fragment:

/* Local Function Prototypes */
static void SHA1Finalize(SHA1Context *context, uint8_t Pad_Byte);
static void SHA1PadMessage(SHA1Context *, uint8_t Pad_Byte);
static void SHA1ProcessMessageBlock(SHA1Context *);

should better say, amending the last two lines:

/* Local Function Prototypes */
static void SHA1Finalize(SHA1Context *context, uint8_t Pad_Byte);
static void SHA1PadMessage(SHA1Context *context, uint8_t Pad_Byte);
static void SHA1ProcessMessageBlock(SHA1Context *context);

Errata ID: 2420
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.2.1 says:

The Description comments for the SHA$$$Result functions repeatedly
contains improper wording and unpleasent formatting.
See below for significant flaws.
This change is proposed for the sake of consistency.

The Description of SHA1Result on page 28, says:

 * Description:
 *   This function will return the 160-bit message digest into the
 *   Message_Digest array provided by the caller.
 *   NOTE: The first octet of hash is stored in the 0th element,
 *      the last octet of hash in the 19th element.

For correctness and consistency, it should better say:

 * Description:
 *   This function will return the 160-bit message digest
 *   into the Message_Digest array provided by the caller.
 *   NOTE:
 *    The first octet of the hash is stored in the element with index 0,
 *    the last octet of the hash in the element with index 19.

[The additional line break has been added to keep the first part
of the last sentence on a single line, under RFC formatting rules.]

Errata ID: 2448
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.4 says:

On mid-page 82, the RFC text defines the constant:

#define PRINTBASE64 4

which is never used in the subsequent test driver code
(Base64 output is not supported).
Hence, this line should be deleted.

Errata ID: 2425
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.2.2 says:

On top of page 35, the Description of SHA224Reset says:

                                          vvv
 * Description:
 *   This function will initialize the SHA384Context in preparation
 *   for computing a new SHA224 message digest.

It should say:

 * Description:
|*   This function will initialize the SHA224Context in preparation
 *   for computing a new SHA224 message digest.

Errata ID: 2434
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.2.3 says:

The first line on page 50 says:

#else /* !USE_32BIT_ONLY */

It should say:

#else /* !USE_MODIFIED_MACROS */

Rationale:  Look at the #if[n]def structure of the file.

RFC 4636, "Foreign Agent Error Extension for Mobile IPv4", October 2006

Source of RFC: mip4 (int)

Errata ID: 824
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Held for Document Update by: Brian Haberman

Section 8 says:

   The extension in this document improves the security features of
   Mobile IPv4 by allowing the mobile node to be assured of the
   authenticity of the information supplied within a Registration
   Request. 

It should say:

   The extension in this document improves the security features of
   Mobile IPv4 by allowing the mobile node to be assured of the
   authenticity of the information supplied within a Registration
   Reply. 

Notes:

From the body of the RFC, I would have expected to find "Reply"
as the last word of that sentence -- cf. Section 1, 2nd sentence,
and Section 4, 1st sentence.

from pending

RFC 4640, "Problem Statement for bootstrapping Mobile IPv6 (MIPv6)", September 2006

Source of RFC: mip6 (int)

Errata ID: 811
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Held for Document Update by: Brian Haberman

 

(1)  typo/grammar

On page 3 of RFC 4640, the seconf paragraph of Section 1.2 says:

   Typically, bootstrapping happens when a mobile node does not have all
   the information it needs to set up the Mobile IPv6 service.  This
   includes, but is not limited to, situations in which the mobile node
   does not having any information when it boots up for the first time
   (out of the box), or does not retain any information during reboots.

It should say:

   Typically, bootstrapping happens when a mobile node does not have all
   the information it needs to set up the Mobile IPv6 service.  This
   includes, but is not limited to, situations in which the mobile node
|  does not have any information when it boots up for the first time
   (out of the box), or does not retain any information during reboots.


(2)  missing line break

Near the end of Section 1.3, on page 5, there should be an additional
blank line above the term "Home Mobility Service Provider".


(3)  typo

On page 6, the last sub-bullet of the first bulleted list in Section 3
says:

      *  IPsec Security Association (SA) between MN and HA, Intenet Key
         Exchange Protocol (IKE) pre-shared secret between MN and HA

It should say:
                                                                v
|     *  IPsec Security Association (SA) between MN and HA, Internet Key
         Exchange Protocol (IKE) pre-shared secret between MN and HA


(4)  grammar (singluar/plural mismatch)

The first sentence of Section 5.1.3, on page 9, says:
                                                      vv
|  The home agent discovery protocol does not support an "opportunistic"
|  or local discovery mechanisms in an ASP's local access network.  [..]
                               ^
It either should say:

   The home agent discovery protocol does not support an "opportunistic"
|  or local discovery mechanism in an ASP's local access network.  [..]

or it should say:

|  The home agent discovery protocol does not support "opportunistic" or
   local discovery mechanisms in an ASP's local access network.  [..]

Please decide what was intended.


(5)  missing articles

The last paragraph of Section 5.3.1, on page 11, says:

   Bootstrapping does not explicitly try to solve this problem of home
   network renumbering when MN is in dormant mode.  If the MN can
   configure itself after it 'comes back on' by reinitiating the
   bootstrapping process, then network renumbering problem is fixed as a
   side effect.

It should better say:

   Bootstrapping does not explicitly try to solve this problem of home
|  network renumbering when the MN is in dormant mode.  If the MN can
   configure itself after it 'comes back on' by reinitiating the
|  bootstrapping process, then the network renumbering problem is fixed
   as a side effect.


(6)  missing article

The second paragraph of Section 7, on page 13, says:

   For each scenario, the underlying assumptions are described.  The
   basic assumption is that there is a trust relationship between mobile
   user and the MSA.  Typically, [...]

It should better say:

   For each scenario, the underlying assumptions are described.  The
|  basic assumption is that there is a trust relationship between the
   mobile user and the MSA.  Typically, [...]


(7)  missing article

The second paragraph of Section 7.2, on page 14, says:

   Figure 1 describes an AAA design example for integrated ASP scenario.

It should better say:

   Figure 1 describes an AAA design example for the integrated ASP
   scenario.


(8)  flawed artwork

Figure 2, on page 15,

                +--------------+   +--------+
                |              |   |Serving |
                | ASP          |   | MSP    |
   +----+    +-----+           |   | +----+ |
   | MN |--- | NAS |           |   | | HA | |  +-------------------+
   +----+    +-----+           |===| +----+ |  | MSA               |
                | \            |   |    \   || (e.g., corporate NW)|
                |  \ +------+  |   |     \     | +-------+         |
                |   -|AAA-NA|  |   |      -------|AAA-MIP|         |
                |    +------+  |   |        |  | +-------+         |
                +------------  +   +--------+  +-------------------+

should perhaps be corrected/improved to:

                +--------------+   +--------+
                |              |   |Serving |
                | ASP          |   | MSP    |
   +----+    +-----+           |   | +----+ |
   | MN |--- | NAS |           |   | | HA | |  +-------------------+
   +----+    +-----+           |===| +----+ |  | MSA (e.g.,        |
                | \            |   |    \   |  |      corporate NW)|
                |  \ +------+  |   |     \  |  | +-------+         |
                |   -|AAA-NA|  |   |      -------|AAA-MIP|         |
                |    +------+  |   |        |  | +-------+         |
                +------------  +   +--------+  +-------------------+

[ Note: I intentionally have refrained from horizontally extending
  the box on the rigth side of the figure, which would have been
  possible while still conforming to RFC formatting rules. ]



(9)  word omissions

Within the large first paragraph of Section 9.1, at the bottom of
page 17, there are two word omissions:

In the 2nd line of the paragraph, replace

	  ... between the home agent and mobile node
by:
          ... between the home agent and the mobile node

and in the 5th line from the bottom of the page, insert "be", changing

                                   [...].  The best way to minimize the
   probability of such a compromise is to have the cryptographic
   material only known or calculable by the two end nodes that share the
   SA -- in this case, the home agent and mobile node.  [...]

to:
                                   [...].  The best way to minimize the
   probability of such a compromise is to have the cryptographic
|  material only be known or calculable by the two end nodes that share
   the SA -- in this case, the home agent and mobile node.  [...]


(10) [[posted separately.]]

Notes:

from pending

RFC 4641, "DNSSEC Operational Practices", September 2006

Note: This RFC has been obsoleted by RFC 6781

Source of RFC: dnsop (ops)

Errata ID: 814
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Ron Bonica

Section 7.1 says:

   [3]   Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System
         KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP)
         Flag", RFC 3757, May 2004.

It should say:

[should be omitted.]

Notes:

RFC 3757 has been formally obsoleted by (and incorporated into)
the new DNSSEC RFCs, RFC 4033..4035.
Therefore, RFC 3757 should not appear as a Normative Reference
in new RFCs any more.

The two instances where [3] is cited in the text,
- page 6, Section 3.1, first paragraph, and
- page 24, Section 4.1.1, second paragraph
should have been changed to refer to [5], RFC 4034, instead.


from pending

Errata ID: 2391
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tony Finch
Date Reported: 2010-07-23
Held for Document Update by: Ron Bonica

Section Appendix C says:

Notes:

There are some NSEC-related errors in the example zone. The NSEC record is missing from the zone apex (though its RRSIG is present). The TTL on the NSEC and RRSIG NSEC records for a.example.net should be the same as the zone's SOA minimum TTL, i.e. 28800 not 86400.

RFC 4642, "Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)", October 2006

Note: This RFC has been updated by RFC 8143, RFC 8996

Source of RFC: nntpext (app)

Errata ID: 1520
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2008-09-23
Held for Document Update by: Lisa Dusseault

Section 1 says:

TLS is complimentary to both simple authentication-only
SASL mechanisms and deployed clear-text password
login commands.

It should say:

TLS is complementary to both simple authentication-only
SASL mechanisms and deployed clear-text password
login commands.

RFC 4644, "Network News Transfer Protocol (NNTP) Extension for Streaming Feeds", October 2006

Source of RFC: nntpext (app)

Errata ID: 1995
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2010-01-10
Held for Document Update by: Alexey Melnikov
Date Held: 2010-01-11

Section 1.1 says:

This document assumes you familiarity with NNTP [NNTP].

It should say:

This document assumes familiarity with NNTP [NNTP].

Notes:

A simple typo.
Also note that earlier drafts on which this RFC is based used "This document assumes you are familiar with NNTP [NNTP]."

RFC 4650, "HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY)", September 2006

Source of RFC: msec (sec)

Errata ID: 2377
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Tim Polk
Date Held: 2010-07-20

 

(6) missing comma, causing possible mis-interpretation

The last sentence of Section 3, at the bottom of page 9, says:

                                        [...].  The HMAC SHALL be
   computed over the entire message, excluding the MAC field using
   auth_key; see also section 4.2.

It should say:

It should say:

                                        [...].  The HMAC SHALL be
|  computed over the entire message, excluding the MAC field, using
   auth_key; see also section 4.2.

or perhaps even better and clearer:

                                        [...].  The HMAC SHALL be
|  computed (using auth_key) over the entire message excluding the MAC
|  field; see also section 4.2.

Notes:

from pending

Errata ID: 2379
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Tim Polk
Date Held: 2010-07-20

 

 missing comma, causing possible mis-interpretation


The last sentence of the second paragraph of Section 4.2,
on page 12, says:

          [...].  The HMAC is then calculated over the entire MIKEY
   message, excluding the MAC field using auth_key as described in [2]
   section 5.2, and then stored within the MAC field.

It should say:

It should say:

          [...].  The HMAC is then calculated over the entire MIKEY
|  message, excluding the MAC field, using auth_key as described in [2]
   section 5.2, and then stored within the MAC field.

or perhaps even better and clearer:

|         [...].  The HMAC is then calculated using auth_key, over the
|  entire MIKEY message, excluding the MAC field, as described in [2]
   section 5.2, and then stored within the MAC field.

Notes:

from pending

Errata ID: 33
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Tim Polk
Date Held: 2010-07-20

 

(1) word omission

In Section 1, the first text line on page 2 says:

   There is work done in IETF to develop key management schemes.  [..]

It should say:

It should say:

|  There is work done in the IETF to develop key management schemes.
   [..]

Notes:

from pending

Errata ID: 2373
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Tim Polk
Date Held: 2010-07-20

 

In Section 1, the last indented paragraph on page 4 says:

      However, the Diffie-Hellman key agreement protocol is known for
      its subtle security strengths in that it is able to provide full
      perfect forward secrecy (PFS) and further have to both parties
      actively involved in session key generation.  This special
      security property (despite the somewhat higher computational
      costs) makes Diffie-Hellman techniques attractive in practice.

It should say:

It should say:

      However, the Diffie-Hellman key agreement protocol is known for
      its subtle security strengths in that it is able to provide full
|     perfect forward secrecy (PFS) and further have both parties
      actively involved in session key generation.  This special
      security property (despite the somewhat higher computational
      costs) makes Diffie-Hellman techniques attractive in practice.

Errata ID: 2374
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Tim Polk
Date Held: 2010-07-20

 

typo (line folding problem?)

The second paragraph of Section 2, on page 7, says:

   DHHMAC is applicable in a peer-to-peer group where no access to a
   public-key infrastructure can be assumed to be available.  Rather,
   pre- shared master secrets are assumed to be available among the
   entities in such an environment.

It should say:

It should say:

   DHHMAC is applicable in a peer-to-peer group where no access to a
   public-key infrastructure can be assumed to be available.  Rather,
|  pre-shared master secrets are assumed to be available among the
   entities in such an environment.

Notes:

from pending

Errata ID: 2375
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Tim Polk
Date Held: 2010-07-20

 

In Section 2.1, the last paragraph on page 7 says:

   a) SIP [13] and SDP, where the encoded MIKEY messages are
      encapsulated and transported in SDP containers of the SDP
      offer/answer see RFC 3264 [27]) handshake, as described in [4];

It should say:

It should say:

   a) SIP [13] and SDP, where the encoded MIKEY messages are
      encapsulated and transported in SDP containers of the SDP
|     offer/answer (see RFC 3264 [27]) handshake, as described in [4];

or perhaps even better:

   a) SIP [13] and SDP, where the encoded MIKEY messages are
      encapsulated and transported in SDP containers of the SDP
|     offer/answer handshake (see RFC 3264 [27]), as described in [4];

Notes:

from pending

Errata ID: 2376
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Sean Turner
Date Held: 2010-07-30

Section 3 says:

Figure 1 in Section 3, on page 8, says:

               Initiator                        Responder

   I_message = HDR, T, RAND, [IDi], IDr,
               {SP}, DHi, KEMAC
                    ----------------------->   R_message = HDR, T,
                                                [IDr], IDi, DHr,
                                                DHi, KEMAC
                    <----------------------

It should say:

To avoid optional empty protocol elements,
it should perhaps better say:

               Initiator                        Responder

|  I_message = HDR, T, RAND, [IDi,] IDr,
               {SP}, DHi, KEMAC
                    ----------------------->   R_message = HDR, T,
|                                               [IDr,] IDi, DHr,
                                                DHi, KEMAC
                    <----------------------



 Similar corrections would be suitable in Section 3.1 for Figure 2,
on page 10.

Notes:

error in message syntax notation:

Errata ID: 2378
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Tim Polk
Date Held: 2010-07-20

 

Extraneous (duplicate) word error:

In Section 4.1, the last sentence on page 11, says:

   Other defined next payload values defined in [2] SHALL not be applied
   to DHHMAC.

It should say:

It should say:

|  Other next payload values defined in [2] SHALL not be applied to
   DHHMAC.

Notes:

from pending

Errata ID: 2380
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Tim Polk
Date Held: 2010-07-20

 

missing article:

The last paragraph on page 13, i.e. the 2nd bullet in Section 5.2, says:

   * Eavesdropping of other, transmitted keying information: DHHMAC
     protocol does not explicitly transmit the TGK at all.  [...]

It should say:

It should say:

|  * Eavesdropping of other, transmitted keying information: The DHHMAC
     protocol does not explicitly transmit the TGK at all.  [...]

Notes:

from pending

Errata ID: 2381
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Tim Polk
Date Held: 2010-07-20

 

 [missing "/"]

The 3rd paragraph on page 14, i.e. the 4th bullet in Section 5.2, says:

   * Man-in-the-middle attacks: Such attacks threaten the security of
     exchanged, non-authenticated messages.  Man-in-the-middle attacks
     usually come with masquerade and or loss of message integrity (see
     below).  [...]

It should say:

It should say:

   * Man-in-the-middle attacks: Such attacks threaten the security of
     exchanged, non-authenticated messages.  Man-in-the-middle attacks
|    usually come with masquerade and/or loss of message integrity (see
     below).  [...]

Notes:

from pending

Errata ID: 2382
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Tim Polk
Date Held: 2010-07-20

 

(11) missing comma (potential for mis-interpretation)

The second paragraph on page 15 (within Section 5.2) says:

   * Identity protection: Like MIKEY, identity protection is not a major
     design requirement for MIKEY-DHHMAC, either; see [2].  No security
     protocol is known so far that is able to provide the objectives of
     DHHMAC as stated in section 5.3, including identity protection
     within just a single roundtrip.  [...]

It should say:

It should say:

   * Identity protection: Like MIKEY, identity protection is not a major
     design requirement for MIKEY-DHHMAC, either; see [2].  No security
     protocol is known so far that is able to provide the objectives of
|    DHHMAC as stated in section 5.3, including identity protection,
     within just a single roundtrip.  [...]

Notes:

from pending

Errata ID: 2383
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Tim Polk
Date Held: 2010-07-20

 

(12) extraneous word

The 3rd paragraph on page 18 (within Section 5.3) says:

     If a very high security level is desired for long-term secrecy of
     the negotiated Diffie-Hellman shared secret, longer hash values may
     be deployed, such as SHA256, SHA384, or SHA512 provide, possibly in
|    conjunction with stronger Diffie-Hellman groups.  This is left as
     for further study.

It should say:

It should say:
     
|                                              [...].  This is left for
     further study.

Notes:

from pending

Errata ID: 2384
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Tim Polk
Date Held: 2010-07-20

 

(13) extraneous words (left over from changing the sentence?)

The last lines on page 18 (within Section 5.3) say:

     Public-key infrastructures may not always be available in certain
     environments, nor may they be deemed adequate for real-time
     multimedia applications when additional steps are taken for
     certificate validation and certificate revocation methods with
     additional roundtrips into account.

It should say:

The RFC should say:

     Public-key infrastructures may not always be available in certain
     environments, nor may they be deemed adequate for real-time
     multimedia applications when additional steps are taken for
     certificate validation or certificate revocation methods require
     additional roundtrips.

Notes:

Minor edits to corrected text by Tim Polk.

Errata ID: 2386
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Tim Polk
Date Held: 2010-07-20

 

(14) outdated Informative Reference

This RFC  references the now-outdated RFC 1750.
All new RFCs should refer to BCP 106, RFC 4086, instead of RFC 1750!

It should say:

Item [8] in Section 8.2, at the bottom of page 22 of RFC 4650,
should be replaced by the proper RFC-style citation for RFC 4086.

Notes:

from pending

RFC 4653, "Improving the Robustness of TCP to Non-Congestion Events", August 2006

Source of RFC: tcpm (wit)

Errata ID: 1653
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Arnd Hannemann
Date Reported: 2009-01-15
Held for Document Update by: Lars Eggert

Section 0 says:

   8. Acknowledgments ................................................14
   9. IANA Considerations ............................................14
   10. References ....................................................14
      10.1. Normative References .....................................14
      10.2. Informative References ...................................15

It should say:

   8. Acknowledgments ................................................14
   9. References .....................................................14
      9.1. Normative References ......................................14
      9.2. Informative References ....................................15

Notes:

Typo in table of contents

RFC 4654, "TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification", August 2006

Source of RFC: rmt (tsv)

Errata ID: 3274
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dongwook Kim
Date Reported: 2012-07-02
Held for Document Update by: Wesley Eddy

Section 5.3 says:

If a loss interval, A, is determined to have started with packet
sequence number S_A and the next loss interval, B, started with
packet sequence number S_B, then the number of packets in loss
interval A is given by (S_B - S_A).

It should say:

If a loss event, A, is determined to have started with packet
sequence number S_A and the next loss event, B, started with
packet sequence number S_B, then the number of packets in the loss
interval between A and B is given by (S_B - S_A).

RFC 4660, "Functional Description of Event Notification Filtering", September 2006

Note: This RFC has been updated by RFC 6665

Source of RFC: simple (rai)

Errata ID: 921
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-08
Held for Document Update by: Robert Sparks

 

(1) [[posted separately.]]

(2)  general issue: presentation/formatting of XML text

Although it carries no functional relevance, uniform formatting
and consistent indentation of XML text significantly adds to
the readability and furthers the understanding of the structure.
Unfortunately, there are many places in the two RFCs where --
perhaps as a result of the use of various tools in the publication
process -- non-uniform and inconsistent indentation in XML text
impedes the readability of the XML schemata and the XML examples.

At a minimum, pairing opening and closing XML tags, if on different
lines, should be indented by the same amount of white space,
and XML elements on the same hierarchical level (within another
XML element) should be indented equally.

For brevity of this message, I omit detailing the numerous places
affected I have marked in my printed copies of the two RFCs.


(3)  repeated word replications and grammar  (RFC 4660)

The second paragraph of Section 3.3.1 of RFC 4660, at the bottom
of page 3, says:

   A SUBSCRIBE request destined to a list URI [4] MAY include multiple
   filters specific to individual resources.  This is achieved by
   including multiple <filter> elements with different URIs of resources
|  in each of those elements.  This resource specific resource-specific
|  filter are processed first before any list specific list-specific
|  filter, if any.  The list specific list-specific filter may or may
   not include a URI.

It should perhaps say:

   A SUBSCRIBE request destined to a list URI [4] MAY include multiple
   filters specific to individual resources.  This is achieved by
   including multiple <filter> elements with different URIs of resources
|  in each of those elements.  This resource-specific filter is
|  processed first, before any list-specific filter, if any.  The
|  list-specific filter may or may not include a URI.


(4)  distorting extra blank line   (RFC4660)

The example scenario description in Section 4.1 of RFC 4660,
on top of page 8, are made less comprehensible by the additional
blank line in between:

   List1 (list1@example.com) on RLS1 has: bob@example.com

   list2@biloxi.com

Should perhaps better say:

   List1 (list1@example.com) on RLS1 has: bob@example.com
   list2@biloxi.com

or even better:

   List1 (list1@example.com) on RLS1 has:
     bob@example.com list2@biloxi.com


(5)  inappropriate Section headlines   (RFC4660)

The ToC and the body of RFC 4660 (on page 9) contains the Section
headlines:

 5.  Server Operation

 5.1.  NOTIFY Bodies

should better say:

 5.  Notifier Operation

 5.1   SUBSCRIBE Bodies

Rationale:

Obviously, these titles are inappropriate.

a) The document deals with two kinds of 'server' roles:
     *  Resource List Server (RLS),  and
     *  SIP servers in the Notifier role
   Since Section 4 deals with RLS behaviour (and does tell so
   in its headline), and Section 5 deals with Notifier behaviour,
   the latter should tell so as well, and not pretend to be
   applicable to server operation in general.

b) NOTIFY bodies/content are dealt with in Section 5.3 ff.
   As can be seen immediately, Section 5.1 talks about
   SUBSCRIBE bodies.


(6)  typo/grammar  (RFC 4660)

Within Section 5.2.1, at the bottom of page 10, RFC 4660 says:

                                 [...].  Notifiers belonging to the
|  domain MUST apply the filter to all notifications it sends for that
   subscription, unless policy dictates otherwise.
                                                     ^^^^^^^^
It should say:

                                 [...].  Notifiers belonging to the
|  domain MUST apply the filter to all notifications they send for that
   subscription, unless policy dictates otherwise.
                                                     ^^^^^^^^^


(7)  placement of text ??   (RFC 4660)

The first paragraph of Section 5.3, on page 11,

   Upon receiving the SUBSCRIBE with the filter, the notifier SHOULD
   retain the filter as long as the subscription persists.  The filter
   MAY be incorporated within an existing subscription (in an active
   dialog) by sending a re-SUBSCRIBE that includes the filter in the
   body.

apparently should have been moved up to the end of Section 5.2
because it is related to behaviour during
   "Notifier Processing of SUBSCRIBE Requests" == Section 5.2


(8)  improper use of articles  (RFC 4660)

There are two related issues with text in the 2nd and 3rd paragraph
of Section 5.3, on mid-page 11:

   If the response sent to the SUBSCRIBE was a "202" and the "202" was
|  chosen because the filter could not be accepted that time, the NOTIFY
   MAY be used to terminate the subscription if the filter is found
   unacceptable.

|  As described in [3], the NOTIFY message MAY contain a body that
   describes the state of the resource.  This body is in one of the
   formats listed in the Accept header field of the SUBSCRIBE, or in the
   package-specific default if the Accept header field is omitted.

The first occurrence of "the NOTIFY" is improper because this is the
first place the text talks about a NOTIFY message in this context.
The definite article should either be omitted entirely, or better
be replaced by "a NOTIFY message".
The second "the NOTIFY" is improper because it (re-)states a general
property of all NOTIFY messages, not of a specific NOTIFY message.
Therefore, the above text should say:

   If the response sent to the SUBSCRIBE was a "202" and the "202" was
|  chosen because the filter could not be accepted that time, a NOTIFY
   maeeage MAY be used to terminate the subscription if the filter is
   found unacceptable.

|  As described in [3], a NOTIFY message MAY contain a body that
   describes the state of the resource.  This body is in one of the
   formats listed in the Accept header field of the SUBSCRIBE, or in the
   package-specific default if the Accept header field is omitted.


(9)  missing articles  (RFC 4660)

Within Section 7.1.3, near the top of page 20, where RFC 4660 says:

   Notification containing both tuples is sent to the subscriber in this
   case:

it should better say:

|  A Notification containing both tuples is sent to the subscriber in
   this case:

and within Section 7.2.3, in the upper half of page 26, where the RFC
says:

   Notification to the subscriber is created, taking into account the
   <trigger> and <what> elements:

it should better say:

|  A Notification to the subscriber is created, taking into account the
   <trigger> and <what> elements:

Notes:

from pending

RFC 4661, "An Extensible Markup Language (XML)-Based Format for Event Notification Filtering", September 2006

Source of RFC: simple (rai)

Errata ID: 925
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Robert Sparks

 

significant issues with filter syntax  ( ABNF in RFC 4661 )

Many of the filter examples in RFC 4661 and RFC 4660 do not conform
with the ABNF presented in Section 5, on page 11, of RFC 4661.
Further, that ABNF allows unexpected, strange instantiations of
'elem-path', and there's at least one significant semantical
ambiguity in the syntax described.

Because I am a bloody XML and XML XPATH layman, I am not in a
position to exactly diagnose what is wrong, and to quickly propose
suitable corrections, in a way that keeps the specification as
close to XPATH as possible.

I just present some of the strange outcomes of strict application
of the RFC 4661 ABNF and a few pointers to examples in the RFC
text that do not conform with that syntax.

a) ambiguous semantics / insufficient syntax

The ABNF production,

   expression = "[" (elem-expr / attr-expr)
                         1*[oper (elem-expr / attr-expr)] "]"
entails

   oper = "and" / "or"

Accordingly, these rules allow to build up expressions containing
multiple terms of the form  '(elem-expr / attr-expr)'  separated
by "and" and/or "or" operators.
There are no operator precedence rules specified, and there's no
possibility to insert parentheses to build sub-expressions / groups
to enforce the desired operator precedence.
Thus, it remains unclear whether, e.g., an expression of the form,
     [ <expr1> or <expr2> and <expr3> ]
means:
     [ <expr1> or ( <expr2> and <expr3> ) ]
(corresponding to commonly used precedence rules),
or:
     [ ( <expr1> or <expr2> ) and <expr3> ]
(corresponding to simple left-to-right operator evaluation).

b)  strange productions (#1)

The ABNF production,

   elem-path = (element / "*") 1*["/" / "*" / element] ["*" / element]

together with:

   element = [ns] string
   ns = string ":"

admits 'elem-path' values of strange and unexpected forms, e.g.,

   ****
   *<ns_string1>:<elem_string1><elem_string2><ns_strind3>:<elem_string3>

without any intervening separator characters.

I am quite sure that this was not intended.

Looking at the 'elem-path' production, it can be observed:
The construction '1*[ ... ]' apparently does not make much
sense; since a group in brackets, '[ ... ]', means "optional",
this construction would be equivalent to the simpler '*( ...)'.
Perhaps, the  '1*[ ... ]' group should look similar to the
'1*( ... )'  group in
   elem-reference =  "/" 1*("/" / "/*" / ("/" element))
including the required "/" in all alternatives.
This also make the final, optional group questionable.

c)  strange productions (#2)

The ABNF productions,
   reference = elem-reference / attr-reference
   attr-reference = reference attribute
together with:
   attribute = "@" [ns] string
   ns = string ":"
admits 'reference' values with multiple attribute references like
   <elem-reference>@<ns1>:<attr1>@<attr2>@<attr3>@<ns4>:<attr4>

I am quite sure that this was not intended.

c)  front end of examples not matching the syntax

Successive substitution of the ABNF productions of RFC 4661 leads
to the following observations:

  *  each 'elem-reference' must start with a double-slash, "//" ;
  *  each 'reference' starts with an 'elem-reference',
     and hence it must start with a double-slash;
  *  each 'selection' starts with a 'reference,
     and hence it must start with a double-slash.

Many examples do not conform to this restriction, starting from
the short examples at the bottom of page 11 up to many of the
detailed XML examples in both RFCs.

d)  back end of examples not matching the syntax

Further observations from the ABNF:
  *  (un-escaped) square brackets, "[" and "]" only appear
     in the 'expression' production, forming the leading and
     the trailing character of it, respectively;
  *  each 'selection' contains at most one 'expression', and
     this 'expression' is the trailing part of the 'selection;
  *  hence, each 'selection' contains at most one matching pair
     of square brackets, and if it does, the "]" must be the
     last character of it.

There are examples given, e.g. in Section 6.1 of RFC 4661,
on top of page 13, and in Section 6.6 of RFC 4661, on page 15,
where this restriction is not adhered to!


Final conclusion:  Apparently, all (or most) examples presented
are expected to be crafted as intended, i.e. with valid syntax.
Hence, the ABNF needs to be substantially reworked to allow
production of these examples, and to really produce exactly what
it should.  Otherwise, implementations based on the ABNF will
drastically fail, will not conform to the intended behaviour,
and will not be interoperable with implementations not based
on the ABNF of RFC 4661.

Notes:

from pending

Errata ID: 31
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-08
Held for Document Update by: Robert Sparks

Section 11.2 says:

   [17]  Roach, A. B., Campbell, B., and J. Rosenberg, "A Session
         Initiation Protocol (SIP) Event Notification Extension for
         Resource Lists", RFC 4663, September 2006.

It should say:

   [17]  Roach, A. B., Campbell, B., and J. Rosenberg, "A Session
         Initiation Protocol (SIP) Event Notification Extension for
         Resource Lists", RFC 4662, August 2006.

Errata ID: 923
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Robert Sparks

Section 6.5 says:

   A user wants to know if a group of his friends is available for
   gaming.  He orders notifications about the current status and future
   changes of the game-specific presence information.

It should say:

   A user wants to know if a group of his friends is available for
   gaming.  He orders notifications about the current status and future
|  changes of the (hypothetical) game-specific presence information.

Notes:

The example in Section 6.5 of RFC 4661 makes us of an XML namespace
"game-ext".
I strongly suspect that this is a hypothetical namespace; at least,
it currently does not appear in the IANA XML namespace sub-registry.
If this is the case, this fact should have been communicated to the
RFC reader, e.g. by changing the text above.

from pending

RFC 4664, "Framework for Layer 2 Virtual Private Networks (L2VPNs)", September 2006

Source of RFC: l2vpn (int)

Errata ID: 30
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-07
Held for Document Update by: Stewart Bryant

Section 2.1 says:

                  Attachment        PSN           Attachment
                   Circuits        tunnel          Circuits
                                     +
           +-----+                 pseudo                    +-----+
           |     |                  wire                     |     |
           | CE1 |--+                                     +--| CE2 |
           |     |  |    +-----+   +-----+     +-----+    |  |     |
           +-----+  +----|---- |   |  P  |     | ----+----+  +-----+
                         |VPWS\---|-----|-----|/VPWS|
                         | PE1 |===|=====|=====| PE2 |
                         |    /|---|-----|-----|\\    |
           +-----+  +----|---- |   |     |     | ----|----+  +-----+
           |     |  |    +-----+   +-----+     +-----+    |  |     |
           | CE3 |--+                                     +--| CE4 |
           |     |                                           |     |
           +-----+                                           +-----+

It should say:

                  Attachment        PSN           Attachment
                   Circuits        tunnel          Circuits
                                     +
           +-----+                 pseudo                    +-----+
           |     |                  wire                     |     |
           | CE1 |--+                                     +--| CE2 |
           |     |  |    +-----+   +-----+     +-----+    |  |     |
           +-----+  +----|---- |   |  P  |     | ----+----+  +-----+
                         |VPWS\|---|-----|-----|/VPWS|
                         | PE1 |===|=====|=====| PE2 |
                         |    /|---|-----|-----|\    |
           +-----+  +----|---- |   |     |     | ----|----+  +-----+
           |     |  |    +-----+   +-----+     +-----+    |  |     |
           | CE3 |--+                                     +--| CE4 |
           |     |                                           |     |
           +-----+                                           +-----+

Notes:

from pending

Errata ID: 902
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-07
Held for Document Update by: Stewart Bryant

 

(1) [[posted separately.]]

(2)  improper indentation

The final paragraphs of Section 2.2, on page 8,

        There may be other models as well, some of which are
        combinations of the 3 models above.  Different models may have
        different characteristics, and different scopes of
        applicability.

        Each VPLS solution should specify the model or models that it is
        supporting.  Each solution should also specify the necessary
        bridge functionality that its bridge modules must support.

        This framework does not specify the way in which bridge control
        protocols are used on the Emulated LANs.

apparently should not be (visually) part of the "Model 3" explanation.
Therefore, the same indentation level should be used as before for
the body of the section, above the model enumeration:

   There may be other models as well, some of which are combinations of
   the 3 models above.  Different models may have different
   characteristics, and different scopes of applicability.

   Each VPLS solution should specify the model or models that it is
   supporting.  Each solution should also specify the necessary bridge
   functionality that its bridge modules must support.

   This framework does not specify the way in which bridge control
   protocols are used on the Emulated LANs.


(3)  missing word

On page 20, in the first list item of Section 3.2.7.1, the text,

      - Customer Traffic Prioritization: L2VPN services could be best
        effort or QoS guaranteed.  Traffic from one customer might need
        to be prioritized over others when sharing same network
        resources.  [...]

should say:

      - Customer Traffic Prioritization: L2VPN services could be best
        effort or QoS guaranteed.  Traffic from one customer might need
|       to be prioritized over others when sharing the same network
        resources.  [...]
                                                  ^^^^^

(4)  extraneous word

In section 3.4, the 2nd-to-last paragraph on page 30 says:

   A further issue arises if the PE bridges run bridge control protocols
   with each other over the Emulated LAN.  Bridge control protocols are
|  generally designed to run in over a real LAN and may presume, for
   their proper functioning, certain characteristics of the LAN, such as
   low latency and sequential delivery.  [...]

It should better say:

   A further issue arises if the PE bridges run bridge control protocols
   with each other over the Emulated LAN.  Bridge control protocols are
|  generally designed to run over a real LAN and may presume, for
   their proper functioning, certain characteristics of the LAN, such as
   low latency and sequential delivery.  [...]


(5)  typo

In section 3.4.3, the 2nd paragrph on page 34 says:

   Relative to the VPLS there are three different possibilities for
   allocate functions to a device in such a position in the provider
   network:

It should better say:

   Relative to the VPLS there are three different possibilities for
|  allocating functions to a device in such a position in the provider
   network:


(6)  typo

In Section 4, the 5th paragraph on page 38 says:

   Thus, for inter-SP control connections, it is advisable to use some
   sort of cryptographic authentication procedure.  Control protocols
|  which used TCP may use the TCP MD5 option to provide a measure of
   PE-PE authentication; this requires at least one shared secret
   between SPs.  [...]

It should better say:

   Thus, for inter-SP control connections, it is advisable to use some
   sort of cryptographic authentication procedure.  Control protocols
|  which use TCP may use the TCP MD5 option to provide a measure of
   PE-PE authentication; this requires at least one shared secret
   between SPs.  [...]


(7)  outdated References

Section 7, on page 41, contains two outdated Informative References:

RFC 1771 has been obsoleted by RFC 4271, and RFC 2796 has been
obsoleted by RFC 4456, where both new RFCs have been published
far ahead of RFC 4664.

Therefore,
-  the tag "[RFC1771]" should have been replaced by "[RFC4271]", and
-  the tag "[RFC2796]" should have been replaced by "[RFC4456]"
(throughout the body of RFC 4664), and the related entries
in Section 7 updated accordingly.

Notes:

from pending

Errata ID: 5644
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2019-02-25
Held for Document Update by: Deborah Brungard
Date Held: 2019-03-23

Section 3.4.3 says:

   Relative to the VPLS there are three different possibilities for
   allocate functions to a device in such a position in the provider
   network:

It should say:

   Relative to the VPLS there are two different possibilities for
   allocating functions to a device in such a position in the provider
   network:

RFC 4666, "Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)", September 2006

Source of RFC: sigtran (rai)

Errata ID: 2065
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: AMIR KHAN
Date Reported: 2010-03-04
Held for Document Update by: Robert Sparks

Section 3.8.2 says:

The Notify message contains the following parameters:

      Status                     Mandatory
      ASP Identifier             Conditional
      Routing Context            Optional
      INFO String                Optional

It should say:

The Notify message contains the following parameters:

      Status                     Mandatory
      ASP Identifier             Conditional
      Routing Context            Conditional <Changed>
      INFO String                Optional

Notes:

Considering the scenario below I think the Routing Context in Notify must be conditional.

If ASP1 is Actively processing traffic for both AS1(Override) and AS2(Loadshare) and another ASP2 of AS1 becomes ACTIVE. Then I think it becomes mandatory for SG to send Notify message ("Alternate ASP Active") with AS1 Routing Context. ASP1 will use this Notify (containing AS1 Routing Context) to become INACTIVE for AS1, without this AS1 Routing Context ASP1 will become INACTIVE for both AS1 and AS2, which is not desired here.

Also please go through mailing list with subject line "M3UA Notification and Routing Context" for more on this.

Errata ID: 4475
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Valentin Micic
Date Reported: 2015-09-14
Held for Document Update by: Ben Campbell
Date Held: 2015-10-31

Section 3.6.1, Pg 53 says:

The optional SI [7,8] field contains one or more Service
      Indicators from the values described in the MTP3-User Identity
      field of the DUPU message.  The absence of the SI parameter in the
      Routing Key indicates the use of any SI value, excluding of course
      MTP management.  Where an SI parameter does not contain a multiple
      of four SIs, the parameter is padded out to 32-byte alignment.

It should say:

The optional SI [7,8] field contains one or more Service
      Indicators from the values described in the MTP3-User Identity
      field of the DUPU message.  The absence of the SI parameter in the
      Routing Key indicates the use of any SI value, excluding of course
      MTP management.  Where an SI parameter does not contain a multiple
      of four SIs, the parameter is padded out to 32-bit alignment.

Notes:

It seems obvious that diagram is referring to 32-bit and not 32-byte (as in 32-octets) alignment.

RFC 4668, "RADIUS Authentication Client MIB for IPv6", August 2006

Source of RFC: radext (sec)

Errata ID: 867
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-06
Held for Document Update by: Dan Romascanu

 

misleading RFC title, including abuse of defined terms
(for RFCs 4668 - 4671)

IMHO, the RFC titles, "RADIUS ... MIB for IPv6" are misleading.
In fact, the new RFCs extend the RADIUS MIB modules to cover
IPv6, but they are not IPv6 specific!
Perhaps, better wording would have been "... for IPv4 and IPv6".

Furthermore, a very 'popular' clash of terms shines up here.
As specified in RFC 3410 and Part 1 of STD 62, RFC 3411, and
re-stated in the boilerplate Section 3, "The Internet-Standard
Management Framework", of all four RFCs, there's just one single
Management Information Base (MIB) comprised of various "MIB modules".
Thus, throughout the titles and the text bodies of the RFCs, the
proper term, "RADIUS ... MIB module" should be used instead of the
rather sluggish "RADIUS ... MIB".

Notes:

from pending

Errata ID: 884
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-06
Held for Document Update by: Dan Romascanu

Section 7 says:

hundredths of a second

It should say:

centiseconds

Notes:

Why not use the common ISO-standard unit-multiple name, "centiseconds" (abbreviation: "cs"), instead of the long-winded "hundredths of a second" ?

This applies to the DESCRIPTION clauses of
- radiusAuthClientRoundTripTime (RFC 4668, page 8),
- radiusAuthClientExtRoundTripTime (RFC 4668, page 13)

from pending

RFC 4671, "RADIUS Accounting Server MIB for IPv6", August 2006

Source of RFC: radext (sec)

Errata ID: 881
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-06
Held for Document Update by: Dan Romascanu

Section 7 says:

[[DESCRIPTION clause of the radiusAuthServResetTime OBJECT-TYPE declaration]]

                "If the server has a persistent state (e.g., a process)
                 and supports a 'reset' operation (e.g., can be told to
                 re-read configuration files), this value will be the
                 time elapsed (in hundredths of a second) since the
                 server was 'reset.'  For software that does not
                 have persistence or does not support a 'reset'
                 operation, this value will be zero."

It should say:

                "If the server has a persistent state (e.g., a process)
                 and supports a 'reset' operation (e.g., can be told to
                 re-read configuration files), this value will be the
                 time elapsed (in hundredths of a second) since the
                 server was 'reset'.  For software that does not
                 have persistence or does not support a 'reset'
                 operation, this value will be zero."

Notes:

This does not conform to the 'rational quoting' style required
by the RFC authoring guidelines.

from pending

Errata ID: 882
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-06
Held for Document Update by: Dan Romascanu

Section 7 says:

hundredths of a second

It should say:

centiseconds

Notes:

Why not use the common ISO-standard unit-multiple name, "centiseconds" (abbreviation: "cs"), instead of the long-winded "hundredths of a second" ?

This applies to the DESCRIPTION clauses of
- radiusAccServUpTime (RFC 4671, page 7),
- radiusAccServResetTime (RFC 4671, page 7),

from pending

RFC 4673, "RADIUS Dynamic Authorization Server MIB", September 2006

Source of RFC: radext (sec)

Errata ID: 891
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-06
Held for Document Update by: Dan Romascanu

Section 4 says:

[[DESCRIPTION clause of the radiusDynAuthServCoAUserSessChanged on page 15]]

       DESCRIPTION
             "The number of user sessions authorization
              changed for the CoA-Requests received from this
              Dynamic Authorization Client.

It should say:

       DESCRIPTION
|            "The number of user sessions with authorization
              changed for the CoA-Requests received from this
              Dynamic Authorization Client.  [...]

Notes:

word omission

from pending

RFC 4675, "RADIUS Attributes for Virtual LAN and Priority Support", September 2006

Source of RFC: radext (sec)

Errata ID: 24
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2006-09-19
Held for Document Update by: Dan Romascanu

Section 2.3 says:

       The String field is at least one octet in length and contains the
       VLAN Name as defined in [IEEE-802.1Q] clause 12.10.2.1.3 (a).
       [RFC3629] UTF-8 encoded 10646 characters are RECOMMENDED, but a
       robust implementation SHOULD support the field as undistinguished
       octets.

It should say:

       The String field is at least one octet in length and contains the
       VLAN Name as defined in [IEEE-802.1Q] clause 12.10.2.1.3 (a).
       [RFC3629] UTF-8 encoded ISO 10646 characters are RECOMMENDED, but a
       robust implementation SHOULD support the field as undistinguished
       octets.

RFC 4676, "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", October 2006

Note: This RFC has been obsoleted by RFC 4776

Source of RFC: geopriv (rai)

Errata ID: 23
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-02
Held for Document Update by: Robert Sparks

Section 1 says:

   In addition, if a network provides civic location information via
   both DHCPv4 and DHCPv6, the information conveyed by two protocols
   MUST be the same.

It should say:

   In addition, if a network provides civic location information via
   both DHCPv4 and DHCPv6, the information conveyed by the two protocols
   MUST be the same.

RFC 4683, "Internet X.509 Public Key Infrastructure Subject Identification Method (SIM)", October 2006

Source of RFC: pkix (sec)

Errata ID: 2356
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-20

Section 4.5 says:

Still on page 10, Section 4.5 has two instances of a missing article.

(4a)
The 1st paragraph of Section 4.5 says:

   It may be required that the CA (not just the RA) verifies SII before
|  issuing a certificate.  To meet this requirement, RA SHOULD encrypt
   the SIItype, SII, and SIM and send the result to the CA by a secure
   channel.  The user SHOULD also encrypt the same values and send the
   result to the CA in his or her certificate request message.  Then the
   CA compares these two results for verifying the user's SII.

It should say:

   It may be required that the CA (not just the RA) verifies SII before
|  issuing a certificate.  To meet this requirement, the RA SHOULD
   encrypt the SIItype, SII, and SIM and send the result to the CA by a
   secure channel.  The user SHOULD also encrypt the same values and
   send the result to the CA in his or her certificate request message.
   Then the CA compares these two results for verifying the user's SII.

(4b)
The 2nd paragraph of Section 4.5 says:

|  Where the results from RA and the user are the EPEPSI.

It should say:

|  Where the results from the RA and the user are the EPEPSI.

It should say:

See above.

Errata ID: 2361
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-21

Section 11.2 says:

The first entry in Section 11.2 (at the bottom of page 15) says:

   [LDAPBIS STRPREP] Zeilenga, K., "LDAP: Internationalized String
                     Preparation", Work in Progress.

It should say:

See below.

Notes:

Apparently, this should have been replaced by the proper quotation
for RFC 4518 from rfc-ref.txt.

Rationale: RFC 4518 has been published four months before RFC 4683!

Errata ID: 2363
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-21

Section A says:

Near the bottom of page 18, the RFC says:

|      -- The content of this type conforms to RFC 2279
                                               ^^^^^^^^
It should say:

|      -- The content of this type conforms to STD 63, RFC 3629

It should say:

See above.

Errata ID: 2353
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-20

Section 2 says:

On page 6 of RFC 4683, I found two typos:

(1a)
The first sentence,

|  The following cryptography symbols are defined in this document.
                            ^
should say:

|  The following cryptographic symbols are defined in this document.
                            ^^
(1b)
The 6th entry,

       PEPSI      Privacy-Enhanced Protected Subject Information.
                  Calculated from the input value P, R, SIItype, SII
|                 using two iteration of H().
                                    ^
should say:

       PEPSI      Privacy-Enhanced Protected Subject Information.
                  Calculated from the input value P, R, SIItype, SII
|                 using two iterations of H().
                                    ^^

It should say:

See above.

Errata ID: 2354
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-21

Section 4.2 says:

The first paragraph of Section 4.2, on page 9 of RFC 4683 says:

   The user selects a password as one of the input values for computing
   the SIM.  The strength of the password is critical to protection of
|  the user's SII, in the following sense.  If an attacker has a
|  candidate SII value, and wants to determine whether the SIM value in
|  a specific subject certificate, P is the only protection for the SIM.
   [...]

The marked (3rd) sentence does not parse; apparently something is
missing, or the word "whether" has to be deleted, as follows:

                                    [...].  If an attacker has a
|  candidate SII value, and wants to determine the SIM value in a
   specific subject certificate, P is the only protection for the SIM.
   [...]

It should say:

See above.

Errata ID: 2360
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-21

Section 8 says:

The 3rd paragraph of RFC 4683 says:

   This protocol assumes that Bob is a trustworthy relying party who
|  will not reuse the Alice's information.  [...]
                  ^^^^
It should say:

   This protocol assumes that Bob is a trustworthy relying party who
|  will not reuse Alice's information.  [...]

It should say:

See above.

Errata ID: 2357
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-21

Section 5.1 says:

The first paragraph of Section 5.1 (on mid-page 11) says:

   This section specifies the syntax for the SIM name form included in
|  the subjectAltName extension.  The SIM is composed of the three
   fields:  the hash algorithm identifier, the authority-chosen random
   value, and the value of the PEPSI itself.

It should say:

   This section specifies the syntax for the SIM name form included in
|  the subjectAltName extension.  The SIM is composed of three fields:
   the hash algorithm identifier, the authority-chosen random value, and
   the value of the PEPSI itself.

It should say:

See above.

RFC 4684, "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)", November 2006

Source of RFC: l3vpn (int)

Errata ID: 962
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tom Petch
Date Reported: 2006-11-29
Held for Document Update by: Brian Haberman

Section 3.2 says:

and the Next-hop attribute shall be set of the local
address for that session.

It should say:

[see below]

Notes:

Changing 'set of' to 'set to' does not help as it begs the question what
session? Route reflectors have BGP sessions with route reflector clients, other
route reflectors and with other BGP speakers that are not involved with route
reflection. Looking at the I-D, this is precisely the end of a line and I
wonder if it is a line or two of text that has gone missing. So change of to to
and I might raise an erratum on the grounds that it does not make sense:-)

from pending

Errata ID: 963
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tom Petch
Date Reported: 2006-11-29
Held for Document Update by: Brian Haberman

Section 4 says:

As the origin-as field cannot be interpreted as a prefix.

It should say:

[see below]

Notes:

I cannot parse as a sentence (note that, in this memo, 'as' is sometimes the English conjunction, sometimes an abbreviation for Autonomous System)

from pending

RFC 4695, "RTP Payload Format for MIDI", November 2006

Note: This RFC has been obsoleted by RFC 6295

Source of RFC: avt (rai)

Errata ID: 861
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-02-28
Held for Document Update by: Robert Sparks

Appendix A

[[From the lines in the modified ABNF]]

   P        = %x51
   Q        = %x52

It should say:

   P        = %x50
   Q        = %x51

Notes:

ASCII, `man ascii` on any UNIX system, RFC 20, et al.
(There must have been some EBCDIC spirit pouring into the ASCII world.)

from pending

RFC 4698, "IRIS: An Address Registry (areg) Type for the Internet Registry Information Service", October 2006

Source of RFC: crisp (app)

Errata ID: 16
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-07
Held for Document Update by: Peter Saint-Andre

Section 4 says:

   o  Most specific: Given a set of networks, the network or networks
      that are more specific than zero or more specific of the other
      networks in the set, and that are not less specific of any of the
      networks in the set.

   o  Least specific: Given a set of networks, the network or networks
      that are not more specific to any of the other networks in the
      set.

It should say:

   o  Most specific: Given a set of networks, the network or networks
      that are more specific than zero or more of the other networks in
      the set, and that are not less specific than any of the networks
      in the set.

   o  Least specific: Given a set of networks, the network or networks
      that are not more specific than any of the other networks in the
      set.

Notes:

from pending

Errata ID: 893
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-07
Held for Document Update by: Peter Saint-Andre

Section 4 says:

If there are exact
match networks in the set from (1), they both must appear in the
result set. 

It should say:

If there are exact
match networks in the set from (1), they all must appear in the
result set. 

Notes:

from pending

Errata ID: 894
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-07
Held for Document Update by: Alexey Melnikov
Date Held: 2010-05-20

Section 7.2 says:

   Using reverse
   DNS tree presents problems for IP address delegation (for example,
   delegations do not fall into byte boundaries, unlike reverse DNS),
   and DNS does not currently contain any information regarding
   autonomous system delegation.

It should say:

   Using the reverse
   DNS tree presents problems for IP address delegation (for example,
   delegations do not fall into byte boundaries, unlike reverse DNS),
   and DNS does not currently contain any information regarding
   autonomous system delegation.

Notes:

missing article

Source: apps

RFC 4701, "A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)", October 2006

Note: This RFC has been updated by RFC 5494

Source of RFC: dnsext (int)

Errata ID: 15
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-02
Held for Document Update by: Brian Haberman

Section 6 says:

   However, it should be noted that an attacker that has some knowledge,
   such as of MAC addresses commonly used in DHCP client identification
   data, may be able to discover the client's DHCP identify by using a
   brute-force attack.  

It should say:

   However, it should be noted that an attacker that has some knowledge,
   such as of MAC addresses commonly used in DHCP client identification
   data, may be able to discover the client's DHCP identity by using a
   brute-force attack.  

RFC 4707, "Netnews Administration System (NAS)", October 2006

Source of RFC: INDEPENDENT

Errata ID: 5811
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2019-08-18
Held for Document Update by: Adrian Farrel
Date Held: 2019-08-18

Section 2 says:

   The organizational structure of NAS is hierarchical; this means that
   a NAS root server collects data from the sub-servers that are
   authoritative for certain hierarchies.

It should say:

   The organizational structure of NAS is hierarchical; this means that
   an NAS root server collects data from the sub-servers that are
   authoritative for certain hierarchies.

Notes:

For consistency throughout the document, spell "an NAS root server" instead of "a NAS root server".

Errata ID: 5812
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2019-08-18
Held for Document Update by: Adrian Farrel
Date Held: 2019-08-18

Section 4 says:

   An attached time stamp makes it possible to distinguish between
   new and old data and to avoid loops in the propagation.

It should say:

   An attached timestamp makes it possible to distinguish between
   new and old data and to avoid loops in the propagation.

Notes:

For consistency throughout the document, spell "timestamp" instead of "time stamp".

Errata ID: 5818
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2019-08-18
Held for Document Update by: Adrian Farrel
Date Held: 2019-08-18

Section 6.3.3.4 says:

   This version number MUST not be higher
   than that requested by the client.

It should say:

   This version number MUST NOT be higher
   than that requested by the client.

Notes:

Capitalized "NOT" is needed per RFC 2119.

Errata ID: 5828
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2019-08-18
Held for Document Update by: Adrian Farrel
Date Held: 2019-08-18

Section 6.3.3.10 says:

   pgp-ascii-armor-start and the pgp-ascii-armor-end are built according
   to [RFC2440], Section 6.2., "Forming ASCII Armor".

It should say:

   pgp-ascii-armor-start and pgp-ascii-armor-end are built according
   to [RFC2440], Section 6.2, "Forming ASCII Armor".

Errata ID: 5829
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2019-08-18
Held for Document Update by: Adrian Farrel
Date Held: 2019-08-18

Section 6.3.3.10 says:

       Newsgroup-Type: Announce
       Date-Create: 19950725182040
       Name: humanities.classics
       [...]
       -----BEGIN PGP SIGNATURE-----
       Version: GnuPG v1.0.7 (IRIX64)

It should say:

       Newsgroup-Type: Announce
       Date-Create: 19950725182040

       Name: humanities.classics
       [...]
       -----BEGIN PGP SIGNATURE-----
       Version: GnuPG v1.0.7 (IRIX64)

Notes:

In the first example, an empty separation line is missing before the beginning of the description of another newsgroup.

Errata ID: 5830
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2019-08-18
Held for Document Update by: Adrian Farrel
Date Held: 2019-08-18

Section 6.3.4 says:

   Description: Name of a newsgroup

   Example:     Status: Hierarchy-Complete

   Example:     Status: Group-Moderated

   Comment:     The value can be used as default value for the
                "Followup-To:" header on postings to a moderated group.
                This value is only useful on groups that are moderated
                (Status Group-Moderated) and have a dedicated discussion
                group.

   Comment:     If there is no "Mod-Sub-Adr" for a moderated newsgroup,
                "Mod-Wildcard" of the hierarchy is used.  This is useful
                only for moderated groups (Status Group-Moderated).

   Comment:     If there is no code "Mod-Adm-Adr" for a moderated
                newsgroup, "Mod-Wildcard" of the hierarchy is used.
                This is useful only for moderated groups
                (Status Group-Moderated).

   Example:     Encoding text/plain

   Description: Name of the hierarchy that replaced a removed hierarchy
                if status is "Hierarchy-Obsolete" or will replace a
                hierarchy if the date of removal is in the future.

   Description: Name of the newsgroup or newsgroups that will replace a
                removed newsgroup if status is  "Group-Removed" or will
                replace the newsgroup if the date of removal is in the
                future.

It should say:

   Description: Name of a newsgroup.

   Example:     Status: Complete

   Example:     Status: Moderated

   Comment:     The value can be used as default value for the
                "Followup-To:" header field on postings to a moderated
                group.  This value is only useful on groups that are
                moderated (Status "Moderated") and have a dedicated
                discussion group.

   Comment:     If there is no "Mod-Sub-Adr" for a moderated newsgroup,
                "Mod-Wildcard" of the hierarchy is used.  This is useful
                only for moderated groups (Status "Moderated").

   Comment:     If there is no code "Mod-Adm-Adr" for a moderated
                newsgroup, "Mod-Wildcard" of the hierarchy is used.
                This is useful only for moderated groups
                (Status "Moderated").

   Example:     Encoding: text/plain

   Description: Name of the hierarchy that replaced a removed hierarchy
                if status is "Obsolete" or will replace a
                hierarchy if the date of removal is in the future.

   Description: Name of the newsgroup or newsgroups that will replace a
                removed newsgroup if status is "Removed" or will
                replace the newsgroup if the date of removal is in the
                future.

Notes:

Several fixes in syntax and also in spelling of keywords.

Errata ID: 5832
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2019-08-18
Held for Document Update by: Adrian Farrel
Date Held: 2019-08-18

Section 6.3.4 says:

   Serial
[...]
   Used for:    newsgroup
   Mandatory:   no
   Inheritable: no
   Repeatable:  no

It should say:

   Serial
[...]
   Used for:    newsgroup
   Mandatory:   no
   Repeatable:  no

Notes:

"Inheritable" does not apply to newsgroups.

RFC 4717, "Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks", December 2006

Source of RFC: pwe3 (int)

Errata ID: 2917
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-10-17
Held for Document Update by: Stewart Bryant
Date Held: 2011-08-05

 

(2)  Section 5.1.2 -- misleading specification due to omission.

On top of page 9, Section 5.1.2 says:

   The next 4 bits provide space for carrying protocol-specific flags.
   These are defined in the protocol-specific details below.
|
|  The next 6 bits provide a length field, which is used as follows:
   [...]

'The next 6 bits' is misleading; as indicated in the (unnumbered)
figure at the bottom of page 8, there is a 2-bit 'Res' field between
the Flags field and the Length field; unfortunately, the text lacks
any description of that field.
To fill this gap, the above text should be amended to say:

   The next 4 bits provide space for carrying protocol-specific flags.
   These are defined in the protocol-specific details below.

|  The subsequent 2-bit Res field is reserved; it SHOULD be set to 0
|  by the sending PE and ignored by the receiving PE.
|
|  The next 6 bits provide a length field, which is used as follows:
   [...]

Note: 'SHOULD' is appropriate as future (optional) specifications
      might assign semantics to that field.


(3)  Section 5.4 -- word omission

Section 5.4 (on page 10 of RFC 4717) says:

   The setting of the TTL value in the PW label is application
|  dependent.  In any case, [RFC3032] TTL processing procedure,
   including handling of expired TTLs, MUST be followed.

It should say:

   The setting of the TTL value in the PW label is application
|  dependent.  In any case, the [RFC3032] TTL processing procedure,
   including handling of expired TTLs, MUST be followed.


(4)  Section 6.3 -- word omission

On page 14, Section 6.3 of RFC 4717 contains the numbered item:

|      -iv. The Length of AAL5 frame may exceed the MTU of the PSN.
            This requires fragmentation, which may not be available to
            all nodes at the PW endpoint.

The RFC should say:

|      -iv. The Length of an AAL5 frame may exceed the MTU of the PSN.
            This requires fragmentation, which may not be available to
            all nodes at the PW endpoint.


(5)  Section 7.4 -- distorting typo

The initial text of Section 7.4 (on page 17 of RFC 4717) contains
the line:

|    - (b) On the ATM side of the PW
                                  ^^
This is misleading.  It certainly should say:

|    - (b) On the ATM side of the PE
                                  ^^

(6)  Section 8 -- misleading short text / lack of precision

Section 8 of RFC 4717 (on page 18) says:

   The N-to-one mode (N >= 1) described in this document allows a
   service provider to offer an ATM PVC- or SVC-based service across a
   network.  The encapsulation allows multiple ATM VCCs or VPCs to be
   carried within a single PSN tunnel.  A service provider may also use
   N-to-one mode to provision either one VCC or one VPC on a tunnel.
   This section defines the VCC and VPC cell relay services over a PSN
   and their applicability.

For clarity and added precision, it should say:

   The N-to-one mode (N >= 1) described in this document allows a
   service provider to offer an ATM PVC- or SVC-based service across a
|  packet switched network.  The encapsulation allows multiple ATM VCCs
   or VPCs to be carried within a single PSN tunnel.  A service provider
   may also use N-to-one mode to provision either one VCC or one VPC on
   a tunnel.  This section defines the VCC and VPC cell relay services
   over a PSN and their applicability.


(7)  Section 8.1 -- various clarifications


(7b)  inprecise wording not reflecting requirements language elsewhere

In Section 8.1, the 3rd paragraph below Figure 4 (on mid-page 19)
says:

|  As shown above, in Figure 4, the ATM Control Word is inserted before
|  the ATM service payload.  It may contain a length field and a
   sequence number field in addition to certain control bits needed to
   carry the service.

Taken literally, this text is misleading and partially contradicts
the requirements specified in Section 5.1 (in the second paragraph
on page 7).  In particular, the entire ATM control word (the 3rd word
in Figure 4) is optional, and *not* the various bit fields therein.
To properly reflect these requirements, the RFC should says instead:

|  As shown above, in Figure 4, the optional ATM Control Word (if
|  present) is inserted before the ATM service payload. It contains a
   length field and a sequence number field in addition to certain
   control bits needed to carry the service.

(7c)  bad grammar

Within Section 8.1, the last paragraph on page 20 says:

     * When multiple VCCs or VPCs are transported in one pseudowire,
       VPI/VCI values MUST be unique.  When the multiple VCCs or VPCs
|      are from different a physical transmission path, it may be
                         ^^^                          ^
       necessary to assign unique VPI/VCI values to the ATM connections.
       If they are from the same physical transmission path, the VPI/VCI
       values are unique.

It should say:

     * When multiple VCCs or VPCs are transported in one pseudowire,
       VPI/VCI values MUST be unique.  When the multiple VCCs or VPCs
|      are from different physical transmission paths, it may be
                         ^                          ^^
       necessary to assign unique VPI/VCI values to the ATM connections.
       If they are from the same physical transmission path, the VPI/VCI
       values are unique.



(8)  Sections 9.3 ff. -- alignment flaws in artwork

(8a)
Within Section 9.3, the top part of Figure 8 on page 24 contains
a misaligned border;

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               PSN Transport Header (As Required)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |                      Pseudowire Header                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | [...]

should be:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               PSN Transport Header (As Required)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |                      Pseudowire Header                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | [...]

The same flaw recurs ...

(8b)  within Section 9.4.1, in Figure 9 on page 25;
(8c)  within Section 9.4.1, in Figure 10 on page 26;
(8d)  within Section 11.1, in Figure 12 on page 29;


(9)  Section 9.4.1 -- word omission

On mid-page 25, the bullet,

     * VCI Bits

|      The 16-bit Virtual Circuit Identifier (VCI) incorporates ATM
       Layer VCI value of the cell.

should say:

     * VCI Bits

|      The 16-bit Virtual Circuit Identifier (VCI) incorporates the ATM
       Layer VCI value of the cell.


(10)  Section 10.1 -- multiple mis-specifications

(10a)
As will be explained below, the initial part of Section 10.1
(on page 27) comprises several issues.

The RFC says:

|  The AAL5 CPCS-SDU is prepended by the following header:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |  Res  |T|E|C|U|Res|  Length   |   Sequence Number (Optional)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              "                                |
   |                     ATM cell or AAL5 CPCS-SDU                 |
   |                              "                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 11: AAL5 CPCS-SDU Encapsulation

It should say:

|  The AAL5 CPCS-SDU or OAM cell is prepended the ATM Control Word:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |0 0 0 0|T|E|C|U|Res|  Length   |     Sequence Number (or 0)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|    Figure 11: Control Word used with AAL5 CPCS-SDU Encapsulation

Rationale:

(a.1)
The text is wrong and misleading; the figure does not (merely) show
'the prepended header' (i.e., the "ATM Control Word", according to
other parts of this RFC), but the payload as well!
The top level structure of the encapsulation is specified in Figure 4;
hence, it suffices to specify the details of the Control Word here.
Accordingly, the above replacement omits the payload and presents
a modified figure caption.

(a.2)
The 4 most significant bits of the ATM Control Word MUST be all zero.
Denoting the field as 'reserved' is misleading; future specifications
MUST NOT change the value.  See Section 5.1.2 of this RFC, RFC 4385,
and the recently published RFC 4928 for additional explanation!

(a.3)
The 'Sequence Number' field is *not* optional in the control word,
as erroneously might be deduced from the original version of the
figure; it MUST always be present; according to Section 5.1.2, only
the *processing* of this field is optional, and the reserved value 0
is *not* a valid sequence number; it indicates non-use of sequence
number processing.  Hence, the lower half of the ATM Control Word
either contains a sequence number or 0.


(10c)  incomplete specification

The description of the fields in Figure 11 is incomplete.
As a service to the reader, for completeness the following
text should be added at the end of Section 10.1:

|  For a description of the Length and Sequence Number fields, see
|  Section 5.1.2.


(11)  Section 11.1 -- surprising/confusing specification details

(11b)  lack of precision

Below Figure 12, the RFC text on page 29 says:

   The M, V, Res, and C bits are as defined earlier for VCC One-to-one
   cell mode.

For clarity and completeness, it should say:

   The M, V, Res, and C bits are as defined earlier for VCC One-to-one
|  cell mode.  M must be set to 1 and V must be set to 0 for AAL5 PDU
|  Encapsulation; further details regarding the C bit are given below.




(13)  Section 11.2.2 -- significant typo (wrong bit field name)

Section 11.2.2 (on page 31) contains the bullet:

      -iii. The least significant bit for the last ATM cell in the PSN
|           frame is set to the value of the UU bit of Figure 12.
                                             ^^
It should say:

      -iii. The least significant bit for the last ATM cell in the PSN
|           frame is set to the value of the U bit of Figure 12.
                                             ^


(15)  Abuse of language

'AAL5' stands for "ATM Adaptation Layer 5".  Hence, the wording
"ATM AAL5" is a replication considered a rough abuse of language.

All occurrences of "ATM AAL5" in the RFC should be corrected to "AAL5".

Notes:

This is sections 2, 3, 4, 5, 6, 7b, 7c, 8, 9, 10(a), 10(a1), 10(a2), 10(a3), 10(c), 11(b), 13, and 15 of errata 999

Errata ID: 2079
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hu Haitao
Date Reported: 2010-03-18
Held for Document Update by: Stewart Bryant

Section 6.3 says:

       -ii. If the ALL5 PDU is scrambled using ATM security standards, a
            PE will not be able to extract the ALL5 SDU, and therefore
            the whole PDU will be dropped.

It should say:

       -ii. If the AAL5 PDU is scrambled using ATM security standards, a
            PE will not be able to extract the AAL5 SDU, and therefore
            the whole PDU will be dropped.

RFC 4721, "Mobile IPv4 Challenge/Response Extensions (Revised)", January 2007

Source of RFC: mip4 (int)

Errata ID: 856
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-02-14
Held for Document Update by: Brian Haberman

 

(1)  Ruler line misalignment

In Section 2, on page 4, the two ruler lines on top of Figure 1
are misaligned; they should be indented one more column.

The same issue holds for Figure 2 in Section 4, on page 11,
and for Figure 3 in Section 5, on page 12.


(2)  missing article

In the first paragraph of Section 3.1, on page 5,
    "... specified in Mobile IP specification ..."
should better say:
    "... specified in the Mobile IP specification ..." .
                     ^^^^^

(3)  Inconsistent/incomplete change of terminology

RFC 4721 has changed the terms used to specify various protocol
elements.  Yet these changes have not been performed consistently
throughout the memo.

I have observed the following places where updates have been omitted:

- Section 3.1, page 6, 4th paragraph:
   "(MN-AAA)"  should say:  "(Mobile-AAA)"

- Section 3.5, page 11, 3rd paragraph:
   "MN-AAA"  should say:  "Mobile-AAA"

- Section 11, last paragraph on page 16:
   "MN-AAA"  should say:  "Mobile-AAA"

- Section 11, first paragraph on page 17:
   "Mobile Node - Foreign Agent (MN-FA)"  should say:  "Mobile-Foreign"

- Appendix B, first line on page 22:

     BAD_AUTHENTICATION
  should say:
     'mobile node failed authentication'

- Appendix E, on page 24:

     send_error(STALE_CHALLENGE)
  should say:
     send_error(stale_challenge)

  and

     send_error(UNKNOWN_CHALLENGE);
  should say:
     send_error(unknown_challenge);

Also, Appendix D makes repeated use of "MN-FA Authentication",
but that is not so closely related to the extension now named
differently, and thus can perhaps be left unchanged.


(4)  Section 11 -- logical grouping

In Section 11, the (new) final paragraph is an adjunct to the fourth
indented paragraph (second paragraph on page 17) and should better
have been unified with that one; the new codes are already covered
by the wording there!


(5)  Appendix A -- typo

In the 7th bullet (onpage 20), "compare to" should say: "compared to" .

It should say:

[not submitted]

Notes:

I would like to submit a few comments, drawing your attention
to some textual flaws left over in the text.
These might not be worth of an RFC Errata Note, but you should
at least make note thereof, for consideration in any future work
derived from this specification.

from pending

RFC 4724, "Graceful Restart Mechanism for BGP", January 2007

Note: This RFC has been updated by RFC 8538

Source of RFC: idr (rtg)

Errata ID: 6217
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Nir Chako
Date Reported: 2020-06-29
Held for Document Update by: Alvaro Retana
Date Held: 2020-07-21

Section 7 says:

Since with this proposal a new connection can cause an old one to be
terminated, it might seem to open the door to denial of service
attacks.  However, it is noted that unauthenticated BGP is already
known to be vulnerable to denials of service through attacks on the
TCP transport.  The TCP transport is commonly protected through use
of [BGP-AUTH].  Such authentication will equally protect against
denials of service through spurious new connections.

If an attacker is able to successfully open a TCP connection
impersonating a legitimate peer, the attacker's connection will
replace the legitimate one, potentially enabling the attacker to
advertise bogus routes.  We note, however, that the window for such a
route insertion attack is small since through normal operation of the
protocol the legitimate peer would open a new connection, in turn
causing the attacker's connection to be terminated.  Thus, this
attack devolves to a form of denial of service.

It is thus concluded that this proposal does not change the
underlying security model (and issues) of BGP-4.

We also note that implementations may allow use of graceful restart
to be controlled by configuration.  If graceful restart is not
enabled, naturally the underlying security model of BGP-4 is
unchanged.

It should say:

Since with this proposal a new connection can cause an old one to be
terminated, it might seem to open the door to denial of service
attacks.  However, it is noted that unauthenticated BGP is already
known to be vulnerable to denials of service through attacks on the
TCP transport.  The TCP transport is commonly protected through use
of [BGP-AUTH].  Such authentication will equally protect against
denials of service through spurious new connections.

If an attacker is able to successfully open a TCP connection
impersonating a legitimate peer, the attacker's connection will
replace the legitimate one, potentially enabling the attacker to
advertise bogus routes.  We note, however, that the window for such a
route insertion attack is small since through normal operation of the
protocol the legitimate peer would open a new connection, in turn
causing the attacker's connection to be terminated.  Thus, this
attack devolves to a form of denial of service.

However, it is possible to downgrade the session so it will be
devoided of capabilities via the NOTIFICATION message for OPEN
messages with an Unsupported Optional Parameter subcode.
RFC5492 specifies that if a peer receives this type of NOTIFICATION
message, it SHOULD try to re-establish the BGP connection without
capabilities and, among other things, reduce the use of Graceful
Restart Capability.
Therefore, in this situation, if the attacker is the first to
establish a BGP connection with the peer, he might secure his route
advertising position.
This time, the legitimate peer won't be able to open a new
connection and terminate the attacker's connection.
Thus, this attack devolves into a form of a man-in-the-middle attack.

It is thus concluded that this proposal does not change the
underlying security model (and issues) of BGP-4.

We also note that implementations may allow use of graceful restart
to be controlled by configuration.  If graceful restart is not
enabled, naturally the underlying security model of BGP-4 is
unchanged.

Notes:

The change in this section is the addition of a paragraph between paragraph 2 and paragraph 3 in the original section which describes an attack process where the attacker can gain a permanent grip on the connection

Errata ID: 4193
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Scudder
Date Reported: 2014-12-04
Held for Document Update by: Alia Atlas
Date Held: 2014-12-04

Section 4.2 says:

See Section 8 for a description of this behavior

It should say:

See Section 5 for a description of this behavior

RFC 4730, "A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)", November 2006

Source of RFC: sipping (rai)

Errata ID: 2265
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: David Grant
Date Reported: 2010-05-18
Held for Document Update by: Robert Sparks

Section 10.2 says:

NOTIFY sip:ap@client.subB.example.com SIP/2.0
Via: SIP/2.0/UDP subA.example.com;branch=3qo3j0ouq
To: <sip:ap@subB.example.com>;tag=978675
From: <sip:gw@subA.example.com>;tag=9783453
Call-ID: 12345601@subA.example.com
CSeq: 3001 NOTIFY
Contact: <sip:gw27@subA.example.com>
Event: kpml
Subscription-State: active;expires=3442
Max-Forwards: 70
Content-Type: application/kpml-response+xml
Content-Length: 271

<?xml version="1.0" encoding="UTF-8"?>
<kpml-response xmlns="urn:ietf:params:xml:ns:kpml-response"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation=
        "urn:ietf:params:xml:ns:kpml-response kpml-response.xsd"
      version="1.0"
      code="200" text="OK"
      digits="9999888877776666"/>

It should say:

NOTIFY sip:ap@client.subB.example.com SIP/2.0
Via: SIP/2.0/UDP subA.example.com;branch=3qo3j0ouq
To: <sip:ap@subB.example.com>;tag=978675
From: <sip:gw@subA.example.com>;tag=9783453
Call-ID: 12345601@subA.example.com
CSeq: 3001 NOTIFY
Contact: <sip:gw27@subA.example.com>
Event: kpml
Subscription-State: active;expires=3442
Max-Forwards: 70
Content-Type: application/kpml-response+xml
Content-Length: 271

<?xml version="1.0" encoding="UTF-8"?>
<kpml-response xmlns="urn:ietf:params:xml:ns:kpml-response"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation=
        "urn:ietf:params:xml:ns:kpml-response kpml-response.xsd"
      version="1.0"
      code="200" text="OK"
      digits="9999888877776666" tag="card"/>

Notes:

The tag attribute is shown in the call-flow diagram, but not reproduced in the SIP message itself.

RFC 4740, "Diameter Session Initiation Protocol (SIP) Application", November 2006

Source of RFC: aaa (ops)

Errata ID: 2246
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Miguel A. Garcia
Date Reported: 2010-05-06
Held for Document Update by: Dan Romascanu

Section 9.12.1 says:

The SIP-User-Data AVP (AVP Code 390) is of type UTF8String and
contains a string that identifies the type of user data included in
the SIP-User-Data AVP (Section 9.12).

It should say:

The SIP-User-Data-Type AVP (AVP Code 390) is of type UTF8String and
                 ^^^^^
contains a string that identifies the type of user data included in
the SIP-User-Data AVP (Section 9.12).

RFC 4750, "OSPF Version 2 Management Information Base", December 2006

Source of RFC: ospf (rtg)

Errata ID: 2788
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vladica Stanisic
Date Reported: 2011-04-25
Held for Document Update by: Stewart Bryant

Section 3 says:

ospfVirtNbrEvents OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times this virtual link has
changed its state or an error has occurred.
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at other
times as indicated by the value of ospfDiscontinuityTime."
::= { ospfVirtNbrEntry 6 }

It should say:

ospfVirtNbrEvents OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times this virtual neighbor has
changed its state or an error has occurred.
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at other
times as indicated by the value of ospfDiscontinuityTime."
::= { ospfVirtNbrEntry 6 }

RFC 4752, "The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism", November 2006

Source of RFC: sasl (sec)

Errata ID: 5532
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Borun Song
Date Reported: 2018-10-18
Held for Document Update by: Benjamin Kaduk
Date Held: 2018-10-18

Section 3.2 says:

   with the first octet containing a bit-mask specifying the security
   layers supported by the server and the second through fourth octets
   containing in network byte order the maximum size output_token the
   server is able to receive (which MUST be 0 if the server does not
   support any security layer).

It should say:

   with the first octet containing a bit-mask specifying the security
   layers supported by the server and the second through fourth octets
   containing in network byte order the maximum size output_message the
   server is able to receive (which MUST be 0 if the server does not
   support any security layer).

Notes:

‘output_token’ should be 'output_message' here, since 'output_token' is an output of GSS_Init_sec_context while here we are talking about the maximum data length that GSS_Unwrap (GSS_Wrap of the oppsite side) can handle

RFC 4760, "Multiprotocol Extensions for BGP-4", January 2007

Note: This RFC has been updated by RFC 7606

Source of RFC: idr (rtg)

Errata ID: 1778
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2009-05-05
Held for Document Update by: Stewart Bryant

Section 3 says:

   An UPDATE message SHOULD NOT include the same address prefix (of the
   same <AFI, SAFI>) in more than one of the following fields: WITHDRAWN
   ROUTES field, Network Reachability Information fields, MP_REACH_NLRI
   field, and MP_UNREACH_NLRI field.  The processing of an UPDATE
   message in this form is undefined.

It should say:

   An UPDATE message SHOULD NOT include the same address prefix (of the
   same <AFI, SAFI>) in more than one of the following fields: WITHDRAWN
   ROUTES field, Network Layer Reachability Information fields, MP_REACH_NLRI
   field, and MP_UNREACH_NLRI field.  The processing of an UPDATE
   message in this form is undefined.

Errata ID: 3849
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramakrishna DTV
Date Reported: 2013-12-25
Held for Document Update by: Stewart Bryant
Date Held: 2014-03-02

Section 3 says:

   The next hop information carried in the MP_REACH_NLRI path attribute
   defines the Network Layer address of the router that SHOULD be used
   as the next hop to the destinations listed in the MP_NLRI attribute
   in the UPDATE message.

It should say:

   The next hop information carried in the MP_REACH_NLRI path attribute
   defines the Network Layer address of the router that SHOULD be used
   as the next hop to the destinations listed in the NLRI field of the 
   MP_REACH_NLRI attribute in the UPDATE message.

Notes:

There is no attribute named "MP_NLRI".

Whilst this should be looked at in any update of the text, the correct term is clear from the context.

Errata ID: 3848
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramakrishna DTV
Date Reported: 2013-12-23
Held for Document Update by: Stewart Bryant
Date Held: 2014-03-02

Section 3 says:

   (b) to permit a router to advertise the Network Layer address of the
       router that should be used as the next hop to the destinations
       listed in the Network Layer Reachability Information field of the
       MP_NLRI attribute.

It should say:

   (b) to permit a router to advertise the Network Layer address of the
       router that should be used as the next hop to the destinations
       listed in the Network Layer Reachability Information field of the
       MP_REACH_NLRI attribute.

Notes:

There is no attribute named "MP_NLRI".

Whilst this should be corrected in any revision of the text, the correct term is clear from the context.

Errata ID: 5120
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dale Worley
Date Reported: 2017-09-23
Held for Document Update by: Alvaro Retana
Date Held: 2017-11-06

Section global says:

section 3:  ... each NLRI ... [2 occurrences]

section 5:  The Network Layer Reachability information is encoded as ...

It should say:

... each NLRI item ...

When the Subsequent Address Family Identifier field is set to one of
the values defined in this document (1 or 2), the NLRI field is encoded
as ...

Notes:

The text in section 3 makes it clear that the NLRI encoding in section 5 is only
specified for SAFI 1 and 2, but the text in section 5 does not state this. This tends
to cause readers to believe that section 5 applies to any SAFI. (See, e.g.,
draft-ietf-mpls-rfc3107bis.) (However, other RFCs do specify similar encoding structures
for some other SAFIs; see, e.g., RFC 3107.)

The wording "each NLRI" is incorrect, as NLRI is a field and there is only one of them in an UPDATE message.

RFC 4762, "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", January 2007

Source of RFC: l2vpn (int)

Errata ID: 4834
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Prakash Ragunathan
Date Reported: 2016-10-18
Held for Document Update by: Deborah Brungard
Date Held: 2016-11-08

Section 9.1 says:

For
   example, if a customer site A, is shut down, eventually the other PEs
   should unlearn A's MAC address.

It should say:

For example, if a customer site is shut down, eventually the other PEs
should unlearn the MAC address(es) of this site.

Notes:

Prakash noted the customer site name is not mentioned in example. Suggested naming the site (A1) gives clear info than just stating "customer site A".
After discussion with the Chairs and Authors, the above text was agreed.

RFC 4778, "Operational Security Current Practices in Internet Service Provider Environments", January 2007

Source of RFC: opsec (ops)

Errata ID: 843
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-01-22
Held for Document Update by: Ron Bonica

 

Studying the recently published RFC 4788 (EVRCB)
authored by you, and comparing it with similar recent
publications,  I'm surprised to find a quite unusual
syntax used in the 'a=fmtp' SDP lines there.

Usually, media type parameters included into 'a=fmtp' SDP lines
are separated by semicolons as in the MIME type declaration.

The most recent RFC formally specifying this behaviour was
RFC 4749, Section 6.2 of which says:

   o  Any remaining parameters go in the SDP "a=fmtp" attribute by
      copying them directly from the media type string as a semicolon
      separated list of parameter=value pairs.

As another example, RFC 4396, in section 9.1, explicitely specifies
the syntax as:
        a=fmtp:<dynamic payload type>
               <parameter name>=<value>[,<value>]
               [; <parameter name>=<value>]

Note: This is *not* ABNF, as can be ssen from the context there.
      Matching RFC-4234 ABNF should have been stated there as:
        a=fmtp:<dynamic-payload-type>
               <parameter-name> "=" <value> *("," <value>)
               *(";" <parameter-name> "=" <value> *("," <value>))

This was common practice over many years.

Section 6.7 of RFC 4788 deviates from this practice, omitting
the semicolon in the examples.  From the prose description,
it is not quite clear whether the phrase,
    "... copying it directly from the MIME media type string"
was meant to comprise the separating semicolons often considered
part of MIME type parameters as well, or not.
Unfortunately, no precise formal description (ABNF) is given.
The examples given all omit the usual semicolons, e.g.:

     a=fmtp:97 silencesupp=1 dtxmax=32 dtxmin=12 hangover=1
                            ^         ^         ^

Has this omission been done intentionally?

If yes, what have been the reasons to do so?
  I fear that the unusual definition might cause
  interoperability problems; at least it makes the use
  of uniform parsing of 'a=fmtp' SDP lines impossible.

It should say:

[not submitted]

Notes:

from pending

RFC 4783, "GMPLS - Communication of Alarm Information", December 2006

Source of RFC: ccamp (rtg)

Errata ID: 971
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-16
Held for Document Update by: Adrian Farrel

 

(1)  Section 3.1.1

(1a) -- enhancement

In the past, it has turned out to be a useful practice to
present constant values in diagrams of message (parts)
wherever appropriate.  That practice is a service to the
reader and it enhances the readability of the document.

Therefore, I would have appreciated fo find the constant values
listed in the TLV diagrams in section 3.1.1, on pages 6-8.

For instance, in the upper half of page 6, RFC 4783 says:

   The Reference Count TLV has the following format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     |              Type             |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Reference Count                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It might better have said:

   The Reference Count TLV has the following format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     |           Type = 512          |           Length = 8          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Reference Count                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

(1b) -- typo / grammar / terminology

Near the end of Section 3.1.1, in the explanation for the Error
String field in the Error String TLV, at the top of page 9,
the RFC says:

                                     [...].  The contents of error
         string are implementation dependent.  [...]

It should better say either:

                                     [...].  The contents of error
|        strings are implementation dependent.  [...]
               ^
or, directly quoting the proper name of the field:
                                                             v
|                                    [...].  The contents of Error
|        String are implementation dependent.  [...]
         ^


(2)  Section 5 -- typo/grammar + missing article

On page 15, the RFC text in Section 5 says:

   IANA administered assignment of new values for namespaces defined in
   this document and reviewed in this section.

It should better say:

   vvvv
|  The IANA administered assignment of new values for namespaces defined
|  in this document is reviewed in this section.
                    ^^

(3)  Section 5.2 -- alignment and ref. tagging

On page 16, Section 5.2 says:

   IANA made the following assignments in the "Interface_ID Types"
   section of the "GMPLS Signaling Parameters" registry located at
   http://www.iana.org/assignments/gmpls-sig-parameters.

      512 8 REFERENCE_COUNT     RFC 4783
      513 8 SEVERITY            RFC 4783
      514 8 GLOBAL_TIMESTAMP    RFC 4783
      515 8 LOCAL_TIMESTAMP     RFC 4783
      516 variable ERROR_STRING RFC 4783

There are multiple problems with that text:

a) Tabular alignment should be maintained for readability.

b) The IANA file contails full references, and hence the
   reference tags should be written in the usual [RFCxxxx] style.

c) The referenced "Interface_ID Types" section of the IANA file
   contains a third column entitled "Format"; yet, the above text
   does not specify the intended content of that column for the
   newly registered values.  Consequently, IANA has entered (by
   copy & paste from previous entries?) the nonsensical value
   "See below" into this column, for all 5 new lines ('below'
   in the IANA file, there is only the new section according to
   Section 5.3 of this RFC, and the References section!)

To address all these issues, including filling in the missing
column, the RFC should perhaps better say in Section 5.2
(substitute alternate text if you prefer):

   IANA made the following assignments in the "Interface_ID Types"
   section of the "GMPLS Signaling Parameters" registry located at
   http://www.iana.org/assignments/gmpls-sig-parameters.

|  Type   Length  Format        Description                    Reference
|  -----  ------  ------------  -----------------------------  ---------
|    512       8  see RFC 4873  REFERENCE_COUNT                [RFC4783]
|    513       8  see RFC 4873  SEVERITY                       [RFC4783]
|    514       8  see RFC 4873  GLOBAL_TIMESTAMP               [RFC4783]
|    515       8  see RFC 4873  LOCAL_TIMESTAMP                [RFC4783]
|    516  varies  see RFC 4873  ERROR_STRING                   [RFC4783]

I strongly recommend to address this issue by an RFC Errata Note
and have the IANA update the "Interface_ID Types" section
accordingly.


(4)  Section 5.3

(4a) -- ref. tagging

As in item (3) b) above, the text in the table in Section 5.3
(on mid-page 16),
                                                v
|  Value       Name                              Reference
   ----------- -------------------------------- -----------------
   0x80000000  Reflect (R)                      [RFC3473/RFC3471]
   0x00000010  Inhibit Alarm Communication (I)  RFC 4783
   0x00000004  Testing (T)                      [RFC3473/RFC3471]
   [...]

should better say (also adjusting an alignment flaw):

|  Value       Name                             Reference
   ----------- -------------------------------- -----------------
   0x80000000  Reflect (R)                      [RFC3473/RFC3471]
|  0x00000010  Inhibit Alarm Communication (I)  [RFC4783]
   0x00000004  Testing (T)                      [RFC3473/RFC3471]
   [...]

(4b) -- missing IANA policy statement

Additionally, the RFC did not specify the assignment policy
for this new sub-reistry.  Should it be "Standards Action" ?

This should be formally decided, communicated to the IANA, and
documented in an associated note in the registry file.


(5)  Section 5.4 -- ref. tagging

Similarly as in (4a) above, the new registry line presented
in Section 5.4, near the bottom of page 16 says:

   31  Alarms                               RFC 4783

It should say:

   31  Alarms                               [RFC4783]

It should say:

[see above]

Notes:

from pending

RFC 4790, "Internet Application Protocol Collation Registry", March 2007

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 2851
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-07-01
Held for Document Update by: Pete Resnick

Section 3.4 says:

    other-uri        =  <absoluteURI>
                     ;  excluding the IANA collation namespace.

It should say:

     other-uri       =  absolute-URI
                     ;  excluding the IANA collation namespace.

   The ABNF production "absolute-URI" is imported from URI: Generic Syntax [4].

Notes:

In the current definition it is assumed "absoluteURI" is a <prose-val> of RFC 4234. However it actually refers to the <absolute-URI> of RFC 3986, which I propose to be fixed.

RFC 4804, "Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels", February 2007

Source of RFC: tsvwg (wit)

Errata ID: 972
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-16
Held for Document Update by: Wes Eddy

 

(1)  Section 4.2 -- word omissions

Within Section 4.2, the first paragraph on page 11 says:

                                                        [...].  The
   Router Alert is not set in the E2E Path message.
|              ^
It should say:

                                                        [...].  The
   Router Alert bit is not set in the E2E Path message.
|              ^^^^^

Equally, tha first line of the third paragraph on page 11,
                                                           v
|  Regardless of the encapsulation method, the Router Alert is not set.

should say:
                                                           vvvvv
|  Regardless of the encapsulation method, the Router Alert bit is not
   set.


(2)  Section 4.4 -- another word omission

As above, in the second-to-last paragraph of Section 4.4, on page 12,
the RFC says:
                                                 [...].  The
|  Deaggregator also sets the Router Alert.
                                          ^
It should say:
                                                 [...].  The
|  Deaggregator also sets the Router Alert bit.
                                          ^^^^^

(3)  Section 4.5 -- typo / spurious word

The second paragraph of section 4.5, on mid-page 12, says:

                                                            [...].  This
   includes performing admission control for the segment downstream of
   the Deaggregator and forwarding the E2E Resv message to the PHOP
|  signaled earlier in the E2E Path message and which identifies the
   Aggregator.  [...]
                                           ^^^^^
It should say:
                                                            [...].  This
   includes performing admission control for the segment downstream of
   the Deaggregator and forwarding the E2E Resv message to the PHOP
|  signaled earlier in the E2E Path message which identifies the
   Aggregator.  [...]
                                           ^

(4)  Section 4.6 -- yet another word omission

On page 14, the last sentence of Section 4.6 says:

                                           [...].  The Deaggregator also
|  sets the Router Alert.
                        ^
It should say:
                                           [...].  The Deaggregator also
|  sets the Router Alert bit.
                        ^^^^^

(5)  Section 4.9 --  missing articles

Within Section 4.9, the last footnote on page 15 says:

     (4)  Aggregator selects final TE tunnel, checks that there is
          sufficient bandwidth on TE tunnel, and forwards E2E Resv to
          PHOP.  If final tunnel is different from tunnel tentatively
          selected, the Aggregator re-sends an E2E Path with an updated
          IF_ID RSVP_HOP and possibly an updated ADSPEC.

It should say:

     (4)  Aggregator selects final TE tunnel, checks that there is
|         sufficient bandwidth on the TE tunnel, and forwards E2E Resv
|         to the PHOP.  If the final tunnel is different from the tunnel
          tentatively selected, the Aggregator re-sends an E2E Path with
          an updated IF_ID RSVP_HOP and possibly an updated ADSPEC.


(6)  Section 6 -- word omissions, and punctuation

The text in the numbered items in Section 6 consists of full
sentences starting with a capital letter.  Therefore all these
paragraphs should terminate in a full-stop.  Also, the word
'tuple' is missing twice.  Hence:

The RFC says (on page 16):

      (1)  The E2E RSVP reservation is a per-flow reservation where the
|          flow is characterized by the usual 5-tuple
                                                     ^
      (2)  The E2E reservation is an aggregate reservation for multiple
           flows as described in [RSVP-AGG] or [RSVP-GEN-AGG] where the
           set of flows is characterized by the <source address,
|          destination address, DSCP>
                                     ^
      (3)  The E2E reservation is a reservation for an IPsec protected
           flow.  For example, where the flow is characterized by the
|          <source address, destination address, SPI> as described in
           [RSVP-IPSEC].
                                                     ^
It should say:

      (1)  The E2E RSVP reservation is a per-flow reservation where the
|          flow is characterized by the usual 5-tuple.
                                                     ^
      (2)  The E2E reservation is an aggregate reservation for multiple
           flows as described in [RSVP-AGG] or [RSVP-GEN-AGG] where the
           set of flows is characterized by the <source address,
|          destination address, DSCP> tuple.
                                     ^^^^^^^
      (3)  The E2E reservation is a reservation for an IPsec protected
           flow.  For example, where the flow is characterized by the
|          <source address, destination address, SPI> tuple as described
           in [RSVP-IPSEC].
                                                     ^^^^^^^

(7)  Section 8 -- typos

(7a)

The 7th text line of Section 18, on mid-page 18, says:

|  The mechanisms protect [...]
      ^
It should say:

|  These mechanisms protect [...]
      ^^^

(7b)

The 4th paragraph on page 19 says:

   Section 5 of [RSVP-AGG] also discusses a security issue specific to
   RSVP aggregation related to the necessary modification of the IP
|  Protocol number in RSVP E2E Path messages that traverses the
   aggregation region.  [...]
                                                          ^^
It should say:

   Section 5 of [RSVP-AGG] also discusses a security issue specific to
   RSVP aggregation related to the necessary modification of the IP
|  Protocol number in RSVP E2E Path messages that traverse the
   aggregation region.  [...]
                                                          ^

It should say:

[see above]

Notes:

from pending

RFC 4823, "FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet", April 2007

Note: This RFC has been updated by RFC 8996

Source of RFC: ediint (app)

Errata ID: 2283
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-14
Held for Document Update by: Alexey Melnikov
Date Held: 2010-05-21

Section 9 says:

Quoting S/MIME Version 2 for encryption strength and 40-bit encryption
is ridiculously outdated, IMHO !
Unfortunately, it is still necessary to remind readers that 56-bit
strength (DES) is much too weak today!

Notes:

Source: apps

Errata ID: 955
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-14
Held for Document Update by: Alexey Melnikov
Date Held: 2010-05-21

 

(A)

First of all, it is annoying to find this RFC notoriously neglecting
contemporary standard IETF terminology, using the sluggish and
confusing "header" where in fact "header field" should be used.

Please refer to RFC 2822, RFC 3864, RFC 4021, and RFC 4249
for the proper definitions of the established IETF terminology.

To quote from page 3 of RFC 4249:

3.1.1.  Standard Terminology

   Terms related to the Internet Message Format are defined in
   [N2.RFC2822].  Authors specifying extension header fields should use
   the same terms in the same manner in order to provide clarity and
   avoid confusion.  For example, a "header" [I1.FYI18], [N2.RFC2822] is
   comprised of "header fields", each of which has a "field name" and
   usually has a "field body".  Each message may have multiple
   "headers", viz. a message header and MIME-part [N4.RFC2046] headers.

   A message header has a Date header field (i.e., a field with field
   name "Date").  However, there is no "Date header"; use of such non-
   standard terms is likely to lead to confusion, possibly resulting in
   interoperability failures of implementations.

There's only a single place in the RFC where the correct term,
"header field" is used!

There are much too many instances of this primary issue to mention
in detail -- there are roughly 60 instances of this flaw, starting
with the title of Section 5, in the ToC, "AS3-Specific Headers".


(B)

Further textual flaws are presented in RFC textual order.
I use change bars ('|' in column 1) and occasionally
up/down pointing marker lines ('^^^'/'vvv') to emphasize
the location of textual issues and/or proposed corrections.
Modified text has been re-adjusted to match RFC formatting
rules, where appropriate.


(1)  Section 2.3.1  -- indentation

In Section 2.3.1, the second-to-last list item on page 5 says:

                      vv
|  Non-repudiation of NRR is a "legal event" that occurs when the
   receipt (NRR)        original sender of an EDI/EC interchange has
                        verified the signed receipt coming back from the
                        receiver.  NRR IS NOT a functional or a
                        technical message.

It should say:
                      vv
|  Non-repudiation of   NRR is a "legal event" that occurs when the
   receipt (NRR)        original sender of an EDI/EC interchange has
                        verified the signed receipt coming back from the
                        receiver.  NRR IS NOT a functional or a
                        technical message.


(2)  Section 3.7

The RFC says:

   This Internet RFC defines how a Message Disposition Notification
|  (MDN)is requested, as well as the format and syntax of the MDN.  [..]

It should say:

   This Internet RFC defines how a Message Disposition Notification
|  (MDN) is requested, as well as the format and syntax of the MDN.  [..]
        ^

(3)  Section 6.3.2

Beyond issue (A), there are multiple other flaws in the text of
Section 6.3.2; the RFC says (on page 16):

                          [...].  The Content-Transfer-Encoding header
   SHOULD NOT be used; if the header is present, it SHOULD have a value
   of binary or 8-bit.  The absence of this header or the use of
   alternate values such as "base64" or "quoted-printable" MUST NOT
   result in transaction failure.  Content transfer encoding of MIME
   parts within the AS3 message are similarly constrained.

It should say:

                          [...].  The Content-Transfer-Encoding header
|  field SHOULD NOT be used; if this header field is present anyway, it
|  SHOULD have a value of binary or 8-bit.  The absence of this header
|  field or the use of alternate field values such as "base64" or
|  "quoted-printable" MUST NOT result in transaction failure.  The
|  Content-Transfer-Encoding of MIME bodies within the AS3 message is
|  similarly constrained.

Note:
Usually, only the *body* of a MIME entity (a RFC 2822 message or a MIME
body part) is subject to transfer encoding -- cf. RFC 2045, Section 2;
the MIME header (yes, in this case it's the `header`!) is subject to
encoding according to RFC 2047 and RFC 2231.  Thus, it is essential
here to distinguish precisely between these terms.


(4)  Appendix A.2

Near the bottom of page 38, there's a typo in the Note #1.
The RFC says:
                     v
|     1. The lines proceeded with "&" are what the signature is
         calculated over.

It should say:
                     v
|     1. The lines preceeded with "&" are what the signature is
         calculated over.

It should say:

[see above]

Notes:

Source: apps

RFC 4836, "Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)", April 2007

Source of RFC: hubmib (ops)

Errata ID: 965
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-16
Held for Document Update by: Ron Bonica

 

(1)  Section 3 -- 'rational' quotation -- [legacy]

At the end of the first paragraph of Section 3, on page 4 of RFC 4836,

|  "interface MAUs."
                  ^^
should be written as:

|  "interface MAUs".
                  ^^

Rationale: AFAICS, This is the only place left in the RFC violating
  RFC-Ed policy on 'rational' quotation.


(2)  Section 3.1 -- typos -- [new]

The third paragraph of Section 3.1 says:

|  In addition, the new definitions are added to the IANA-maintained MIB
|  module, to support Ethernet in the First Mile (EFM) and 10GBASE-CX4
   interfaces, defined in [...]

It should say:

|  In addition, new definitions are added to the IANA-maintained MIB
|  module to support Ethernet in the First Mile (EFM) and 10GBASE-CX4
   interfaces, defined in [...]

Rationale:
a) '*the* new definitions' seems to be inappropriate because these
   new definitions have not been introduced so far in the text;
b) the comma separates the subject and the verb in the sentence,
   which better should be avoided.


(3)  Section 3.2.1 -- typo / text formatting -- [new]

In the second paragraph of Section 3.2.1, in the 5th line from the
bottom of page 5,  "non- 10GBASE-W type"  should be spelled
"non-10GBASE-W type".

Note to the RFC-Ed:
  Aparently, this is a recurring text-reformatting problem
  which I have observed multiple times in various recent RFCs.
  According to my experience, matches to the regular expression
    /[a-z0-9]- [a-z0-9]/  (in case-ignoring mode)
  will help find similar problems -- unfortunately, there are
  perfectly feasible matches as well, but finding the candidate
  flaws as always is the first step required.  Maybe, something
  like that search can be added to your nits-checking toolkit.

(4)  Section 3.4 -- table formatting -- [new]

In the tables on pages 7 / 8, the structure of the IEEE Managed
Object names has been hidden even more by the added separator
lines.  E.g., in Table 1, on top of page 7, the table formatting
IMHO hides the fact that  "oMAU"  is the prefix to all subsequent
(partial) object names, and neaer the bottom of page 7, the
'group change' to the next prefix "oAutoNegotiation" is not
obvious any more.
Perhaps this is an artifact of new tools used.
The most simple suggestion for improving the visible grouping in
such tables that comes to my mind is to use modified separator lines
for grouping, and omit the column separator in group headlines, e.g.,

- on top of page 7, modify:

   +----------------------------------+--------------------------------+
   | IEEE 802.3 Managed Object        | Corresponding SNMP Object      |
   +----------------------------------+--------------------------------+
   | oMAU                             |                                |
   +----------------------------------+--------------------------------+
   | .aMAUID                          | rpMauIndex or ifMauIndex or    |
   |                                  | broadMauIndex                  |
   +----------------------------------+--------------------------------+
   | ....                             | ...                            |

to:

   +----------------------------------+--------------------------------+
   | IEEE 802.3 Managed Object        | Corresponding SNMP Object      |
   +==================================+================================+
   | oMAU                                                              |
   +----------------------------------+--------------------------------+
   | .aMAUID                          | rpMauIndex or ifMauIndex or    |
   |                                  | broadMauIndex                  |
   +----------------------------------+--------------------------------+
   | ....                             | ...                            |

- and near the bottom of page 7, change:

   | ...                              | ...                            |
   +----------------------------------+--------------------------------+
   | .nJabber                         | rpMauJabberTrap or             |
   |                                  | ifMauJabberTrap                |
   +----------------------------------+--------------------------------+
   | oAutoNegotiation                 |                                |
   +----------------------------------+--------------------------------+
   | .aAutoNegID                      | ifMauIndex                     |
   +----------------------------------+--------------------------------+
   | ...                              | ...                            |

to:

   | ...                              | ...                            |
   +----------------------------------+--------------------------------+
   | .nJabber                         | rpMauJabberTrap or             |
   |                                  | ifMauJabberTrap                |
   +==================================+================================+
   | oAutoNegotiation                                                  |
   +----------------------------------+--------------------------------+
   | .aAutoNegID                      | ifMauIndex                     |
   +----------------------------------+--------------------------------+
   | ...                              | ...                            |


An additional artifact has subtly changed the apparent semantics
in table 2, on page 8.  The 'Reason for exclusion' given for
oAutoNegotiation.aAutoNegLocalSelectorAbility in fact applies
to all three objetcs in the oAutoNegotiation group.  The published
form of the table does not properly represent this fact.  In HTML,
the corresponding cell could be given a vertical span of three rows.
Incorporating the modification for better grouping support proposed
above, the Table 2,

   +------------------------------------+------------------------------+
   | IEEE 802.3 Managed Object          | Reason for exclusion         |
   +------------------------------------+------------------------------+
   | oMAU                               |                              |
   +------------------------------------+------------------------------+
   | .aIdleErrorCount                   | Only useful for 100BaseT2,   |
   |                                    | which is not widely          |
   |                                    | implemented.                 |
   +------------------------------------+------------------------------+
   | oAutoNegotiation                   |                              |
   +------------------------------------+------------------------------+
   | .aAutoNegLocalSelectorAbility      | Only needed for support of   |
   |                                    | isoethernet (802.9a), which  |
   |                                    | is not supported by MAU-MIB. |
   +------------------------------------+------------------------------+
   | .aAutoNegAdvertisedSelectorAbility |                              |
   +------------------------------------+------------------------------+
   | .aAutoNegReceivedSelectorAbility   |                              |
   +------------------------------------+------------------------------+

should perhaps better be presented as:

   +------------------------------------+------------------------------+
   | IEEE 802.3 Managed Object          | Reason for exclusion         |
   +====================================+==============================+
   | oMAU                                                              |
   +------------------------------------+------------------------------+
   | .aIdleErrorCount                   | Only useful for 100BaseT2,   |
   |                                    | which is not widely          |
   |                                    | implemented.                 |
   +====================================+==============================+
   | oAutoNegotiation                                                  |
   +------------------------------------+------------------------------+
   | .aAutoNegLocalSelectorAbility      | Only needed for support of   |
   +------------------------------------+ isoethernet (802.9a), which  |
   | .aAutoNegAdvertisedSelectorAbility | is not supported by the MAU- |
   +------------------------------------+ MIB.                         |
   | .aAutoNegReceivedSelectorAbility   |                              |
   +------------------------------------+------------------------------+

Note: I have also added the missing article in front of "MAU-MIB".


(5)  Section 4 (MAU-MIB Module)

(5a)  rpMauMediaAvailable -- missing article -- [new]

The DESCRIPTION clause in the rpMauMediaAvailable OBJECT-TYPE macro
invocation, at the bottom of page 16, says:
                                             v
|         DESCRIPTION "This object identifies Media Available state of
                      the MAU, complementary to the rpMauStatus.  [...]

It should say:
                                             vvvvv
|         DESCRIPTION "This object identifies the Media Available state
                      of the MAU, complementary to the rpMauStatus.
                      [...]

(5b)  ifMauMediaAvailable -- missing article -- [new]

Similarly to the preceding item, the DESCRIPTION clause in the
ifMauMediaAvailable OBJECT-TYPE declaration, on top of page 23, says:
                                             v
|         DESCRIPTION "This object identifies Media Available state of
                      the MAU, complementary to the ifMauStatus.  [...]

It should say:
                                             vvvvv
|         DESCRIPTION "This object identifies the Media Available state
                      of the MAU, complementary to the ifMauStatus.
                      [...]

(5c)  ifMauTypeListBits              (page 27
(5d)  ifMauAutoNegCapabilityBits     (page 33)
(5e)  ifMauAutoNegCapAdvertisedBits  (page 34)
(5f)  ifMauAutoNegCapReceivedBits    (page 34)

For completeness and uniformity, it would be useful to amend the
textual references to the bOther bit value in the DESCRIPTION clauses
of these OBJECT-TYPE declarations by adding the numerical value in
parentheses, as it has been done in all similar places in the text:

Change   "bOther"   -->   "bOther(0)" .

(5g)  ifMauAutoNegCapability -- tabular formatting -- [legacy]

The latest additions to the table in the DESCRIPTION clause of the
deprecated ifMauAutoNegCapability OBJECT-TYPE declaration have not
been aligned properly.
Near the top of page 32, the RFC says:

                       [...]
                       17       (reserved)
                       18       (reserved)
|                      19      100BASE-T2 half duplex mode
|                      20      100BASE-T2 full duplex mode
                               ^^
It should say:

                       [...]
                       17       (reserved)
                       18       (reserved)
|                      19       100BASE-T2 half duplex mode
|                      20       100BASE-T2 full duplex mode
                               ^^

(5h)  mauIfGrp100Mbs -- spurious blank line -- [legacy/repagination]

Perhaps as an artifact of the text reformatting (new pagination),
there now is a spurious blank line in the mauIfGrp100Mbs OBJECT-GROUP
macro invocation, on top of page 40.
The RFC says:

                      }
|
          STATUS      deprecated

It should say:

                      }
          STATUS      deprecated

Note to the RFC-Ed:
  This is a recurring artifact observed repeatedly in MIB modules,
  but also in other places; where older editions of the text
  (previous RFC or I-D) had a page break and this is removed
  in the RFC, sometimes such spurious blank line(s) remain.

(5i)  mauModRpCompl2 -- spurious blank line -- [legacy/repagination]

Similarly as above, the mauModRpCompl2 MODULE-COMPLIANCE macro
invocation contains a spurious blank line, after the 8th non-blank
text line on page 45.
The RFC says:

              GROUP       rpMauNotifications
|
              DESCRIPTION "Implementation of this group is recommended
                          for MAUs attached to repeater ports."

It should say:

              GROUP       rpMauNotifications
              DESCRIPTION "Implementation of this group is recommended
                          for MAUs attached to repeater ports."

(5j)  mauModIfCompl3 -- lost blank line -- [legacy/repagination]

In contrast to the two preceding items, in the mauModIfCompl3
MODULE-COMPLIANCE macro invocation, a separating blank line
has been lost.
At the top of page 46, the RFC says:

              GROUP       mauIfGrpAutoNeg2
              DESCRIPTION "Implementation of this group is mandatory
                          for MAUs that support managed
                          auto-negotiation."
              GROUP       mauIfGrpAutoNeg1000Mbps
              DESCRIPTION "Implementation of this group is mandatory
                          [...]

It should say:

              GROUP       mauIfGrpAutoNeg2
              DESCRIPTION "Implementation of this group is mandatory
                          for MAUs that support managed
                          auto-negotiation."
|
              GROUP       mauIfGrpAutoNeg1000Mbps
              DESCRIPTION "Implementation of this group is mandatory
                          [...]


(6)  Section 5 (IANA-MAU-MIB Module)

(6a)  IANAifMauTypeListBits TC -- formatting -- [legacy++]

The SYNTAX clause of the IANAifMauTypeListBits TEXTUAL-CONVENTION,
on page 48 of RFC 4836, contains three blank lines.
I suspect that these initially were intended to visually group
the lines according to the speed classes; but this was never
handled correctly; e.g., in :

       SYNTAX       BITS {
              bOther(0),          -- other or unknown
              bAUI(1),            -- AUI
              b10base5(2),        -- 10BASE-5
              bFoirl(3),          -- FOIRL
|
              b10base2(4),        -- 10BASE-2

a break would perhaps have been appropiate below bOther(0), not
below bFoirl(3), thus not disrupting the group of 10 Mbps MAU types,
i.e.:

       SYNTAX       BITS {
              bOther(0),          -- other or unknown
|
              bAUI(1),            -- AUI
              b10base5(2),        -- 10BASE-5
              bFoirl(3),          -- FOIRL
              b10base2(4),        -- 10BASE-2

In RFC 3636, there was a page break between the 10 Mbps MAU types
and the 100 Mbps MAU types; in RFC 4836, there's no separating blank
line there.
The addition of the new MAU types (on page 49) finally has made
this grouping scheme impossible/obsolete.

I therefore recommend to remove these embedded separating blank lines
from the IANA-MAU-MIB module at the next update, under the control of
the designated expert.

(6b)  IANAifMauMediaAvailable -- typo -- [new]

Within the DESCRIPTION clause of the IANAifMauMediaAvailable TC,
in the first line of the last paragraph on page 51, a comma has
been dropped.
For consistency of style and grammar, I recommend to change back
in the IANA-MAU-MIB module (at the next update) the line,

         For 10 Gb/s the enumerations map to value of the link_fault

to say:

         For 10 Gb/s, the enumerations map to value of the link_fault

(6c)  OBJECT IDENTITIES for MAU types -- visual enhancement

For enhanced readability, I also recommend to insert additional blank
lines below the ASN.1 comments, "-----  new since ..." in the section
listing the OBJECT IDENTITIES for MAU types.

This could be done at the next regular update of the IANA-MAU-MIB
module, at the places corresponding to page 56, 57, 59, and 60 in
RFC 4836, respectively; e.g. (on page 56), change

     ------ new since RFC 1515:
     dot3MauType10BaseTHD OBJECT-IDENTITY
        STATUS     current
        [...]
to:

     ------ new since RFC 1515:
|
     dot3MauType10BaseTHD OBJECT-IDENTITY
        STATUS     current
        [...]


(7)  Section 7 -- missing article -- [new]

The first paragraph of Section 7, on page 63, says:

                        v
|  This document defines first version of the IANA-maintained IANA-MAU-
   MIB module.  [...]

It should say:
                        vvvvv
|  This document defines the first version of the IANA-maintained IANA-
   MAU-MIB module.  [...]

It should say:

[see above]

Notes:

After studying the recently published RFC 4836 (revised MAU MIB)
authored/edited by you, I would like to submit a few comments,
pointing out some minor textual flaws I found in the RFC text.

Some of these are legacy flaws (I had decided not to report
previously) or instances of recurring editorial issues, but
some have been newly introduced.

The intent of this note is to make you aware of the issues,
and to possibly address these in future related / derived work.
Although published policy would perhaps admit the publication
of an RFC Errata Note, IMHO that is not necessary in this case.

from pending

RFC 4848, "Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)", April 2007

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 2862
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-07-14
Held for Document Update by: Pete Resnick

Section 4.6 says:

        u-naptr-regexp = "!.*!"<URI>"!"

It should say:

        u-naptr-regexp = "!.*!" URI "!"

Notes:

As this is ABNF, its productions need not be enclosed in <>. They are only allowed when defining "prose values", which "URI" isn't. "URI" is an actual ABNF production from RFC 3986/

RFC 4852, "IPv6 Enterprise Network Analysis - IP Layer 3 Focus", April 2007

Source of RFC: v6ops (ops)

Errata ID: 1043
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-08
Held for Document Update by: Ron Bonica

Section 10.1 says:

  [IPSEC]  Eastlake 3rd, D., "Cryptographic Algorithm Implementation
           Requirements for Encapsulating Security Payload (ESP) and
           Authentication Header (AH)", RFC 4305, December 2005.

It should say:

  [IPSEC]  Kent, S. and K. Seo, "Security Architecture for the
           Internet Protocol", RFC 4301, December 2005.

Notes:

a) RFC 4305 has been obsoleted by RFC 4835, published two weeks
before RFC 4852.

b) The single use of "[IPSEC]" in the text is totally unrelated to
specific cryptographic algorithms and their support in IPsec;
it refers to IPsec in general, as a framework to secure IPv6 ND.

c) The primary reference for IPsec alway should be the latest IPsec
Architecture document, currently RFC 4301, and not a subordinate
document with recommendations for cryptographic algorithm support
like RFC 4305/4835, subject to relatively frequent updates.

RFC 4856, "Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences", February 2007

Source of RFC: avt (rai)

Errata ID: 1042
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-03-07
Held for Document Update by: Robert Sparks

Section 5.1 says:

   [6]  Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
        "RTP:  A Transport Protocol for Real-Time Applications", RFC
        3550, July 2003.

...

   [8]  Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
        "RTP:  A Transport Protocol for Real-Time Applications", RFC
        3550, July 2003.

It should say:

   [6]  Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
        "RTP:  A Transport Protocol for Real-Time Applications", STD
        64, RFC 3550, July 2003.

Notes:

I find two Normative References, [6] and [8],
that *both* point to RFC 3550, the RTP specification.

I first thought there might something have gone wrong,
e.g., another ref. intended. Yet, it doesn't look like
that from the quotations in the text, in Section 2.1.1
and Section 4.

Furthermore, the ref. tag [6] in Section 2.1.1 is embedded
in an IANA registration template, where such ref. tags should
be avoided generally (as has been done in all similar cases
in the text: in Sections 2.1.2 - 2.1.19 and 2.2.1).
Removing that spurious tag orphans ref. [6] in RFC 4856 entirely.

Perhaps, it would have been better to add a formal ref. to RFC 3550
at the very beginning of the RFC, in the first sentence of Section 1:

This document updates the media type registrations initially
specified in RFC 3555 for the Real-time Transport Protocol (RTP)
payload formats defined in the RTP Profile for Audio and Video
Conferences, RFC 3551 [1], as subtypes under the "audio" and "video"
media types. [...]
--- vvvv
This document updates the media type registrations initially
| specified in RFC 3555 for the Real-time Transport Protocol (RTP) [8]
payload formats defined in the RTP Profile for Audio and Video
Conferences, RFC 3551 [1], as subtypes under the "audio" and "video"
media types. [...]

BTW:
The usual RFC references include the 'special series' names
as well; has there been a particular reason to omit "STD64, "
from the ref. to RFC 3550?
In RFC 4855, this observation also holds, for RFC 3550 and
for RFC 3551 (STD 65) as well.

RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", September 2007

Note: This RFC has been updated by RFC 5942, RFC 6980, RFC 7048, RFC 7527, RFC 7559, RFC 8028, RFC 8319, RFC 8425, RFC 9131

Source of RFC: ipv6 (int)

Errata ID: 2797
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alin Năstac
Date Reported: 2011-05-05
Held for Document Update by: Brian Haberman

Section Appendix C says:

!INCOMPLETE     NA, Solicited=1,        -                   REACHABLE
                Override=0
                Same link-layer
                address as cached
                or no link-layer 
                address

It should say:

PROBE           NA, Solicited=1,        -                   REACHABLE
                Override=0
                Same link-layer
                address as cached
                or no link-layer 
                address

Notes:

NA having Solicited=1 are supposed to confirm two-way connectivity. In order to prove that, NA transmission has to be triggered by an NS sent by local host. Since {REACHABLE,STALE,DELAY} states deny that local host has sent a NS (they're sent only in INCOMPLETE or PROBE states), receiving a NA with Solicited=1 cannot verify 2-way connectivity, therefore it should be ignored.

Errata ID: 3440
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Jeff Wheeler
Date Reported: 2012-12-28
Held for Document Update by: Brian Haberman

Section 3.1 says:

Unlike in IPv4 Router Discovery, the Router Advertisement messages
do not contain a preference field.  The preference field is not ...

It should say:

The Router Advertisement preference field is not ...

Notes:

If Errata #3367 is applied to this document, incorporating the Default Router Preference into the base ND specification, then this errata must also be applied to Section 3.1 paragraph 14.
If Errata #3367 is rejected then this errata should also be rejected.

Errata ID: 1317
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Fernando Gont
Date Reported: 2008-02-13
Held for Document Update by: Brian Haberman

In Appendix F, it says:

Removed the on-link assumption in Section 5.2 based on RFC 4942,
"IPv6 Neighbor Discovery On-Link Assumption Considered Harmful".

It should say:

Removed the on-link assumption in Section 5.2 based on RFC 4943,
"IPv6 Neighbor Discovery On-Link Assumption Considered Harmful".

RFC 4862, "IPv6 Stateless Address Autoconfiguration", September 2007

Note: This RFC has been updated by RFC 7527

Source of RFC: ipv6 (int)

Errata ID: 4305
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Erik Nordmark
Date Reported: 2015-03-17
Held for Document Update by: Brian Haberman
Date Held: 2015-09-14

Section Appendix C says:

   o  Clarified that on failure of Duplicate Address Detection, IP
      network operation should be disabled and that the rule should
      apply when the hardware address is supposed to be unique.

It should say:

o  Clarified that on failure of Duplicate Address Detection, IP
   network operation for the interface should be disabled if and 
   only if:
   - the duplicate check is performed on the IP link-local address,
   - the link-local address is based on an EUI-64 or other hardware 
     address, and
   - the hardware address is supposed to be unique on the link.

RFC 4871, "DomainKeys Identified Mail (DKIM) Signatures", May 2007

Note: This RFC has been obsoleted by RFC 6376

Note: This RFC has been updated by RFC 5672

Source of RFC: dkim (sec)

Errata ID: 1380
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Tony Hansen
Date Reported: 2008-03-21
Held for Document Update by: Pasi Eronen

Section 3.5 says:

       INFORMATIVE NOTE: The "x=" tag is not intended as an anti-replay
           defense.

It should say:

       INFORMATIVE NOTE: The "x=" tag is not intended as an anti-replay
           defense.
       INFORMATIVE NOTE: Due to clock drift, the receiver’s notion of 
when to consider the signature expired may not match exactly when the 
sender is expecting. Receiver’s MAY add a 'fudge factor' to allow for 
such possible drift.

Notes:

From the October 2008 interop event:

When does x= take effect?
* §3.5 says the “x=” value is an “absolute date”
* A receiver’s notion of absolute time might not match the sender’s notion of absolute time
* The document may not expire exactly when sender thinks it should
* A receiving implementation has these choices:
- Try to decide how far apart sender’s notion of absolute time is from the receiver’s notion of absolute time, based on header information
- Use local knowledge of what the absolute time is
- Add in a “fudge factor” to acknowledge possible clock drift

Errata ID: 1381
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Tony Hansen
Date Reported: 2008-03-21
Held for Document Update by: Pasi Eronen

Section 3.5/3.6.1 says:

section 3.5:

   q=  A colon-separated list of query methods used to retrieve the
       public key ... Implementations MUST use the recognized query
       mechanisms in the order presented.

section 3.6.1:

   h=  Acceptable hash algorithms ... Signers and Verifiers MUST
       support the "sha256" hash algorithm.  Verifiers MUST also support
       the "sha1" hash algorithm.

   k=  Key type ... (Note: the "p=" tag further encodes the value using the
       base64 algorithm.)

   s=  Service Type ... Verifiers for a given service type MUST ignore this 
       record if the appropriate type is not listed.  Currently defined 
       service types are as follows:

   t=  Flags, represented as a colon-separated list of names (plain-
       text; OPTIONAL, default is no flags set).  The defined flags are
       as follows:

It should say:

section 3.5:

   q=  A colon-separated list of query methods used to retrieve the
       public key ...  Implementations MUST use the recognized query
       mechanisms in the order presented. Unrecognized query mechanisms
       MUST be ignored.

section 3.6.1:

   h=  Acceptable hash algorithms ... Signers and Verifiers MUST
       support the "sha256" hash algorithm.  Verifiers MUST also support
       the "sha1" hash algorithm. Unrecognized hash algorithms MUST be 
       ignored.

   k=  Key type ...(Note: the "p=" tag further encodes the value using the
       base64 algorithm.) Unrecognized key types MUST be ignored.

   s=  Service Type ... Verifiers for a given service type MUST ignore this 
       record if the appropriate type is not listed. Unrecognized service 
       types MUST be ignored. Currently defined service types are as follows:

   t=  Flags, represented as a colon-separated list of names (plain-
       text; OPTIONAL, default is no flags set).  Unrecognized flags MUST be 
       ignored. The defined flags are as follows:

Notes:

From the October 2008 interop event:

Invalid q=, etc. values

* q=foo/bar:dns/txt:exam/ple
* Nothing in text about unknown values
* But ABNF says unknown values are for “future extension”
* Consensus: ignore unknown values
* Errata: Add statement saying unknown values must be ignored in signature “q=” and key “h=”, “k=”, “s=”, “t=”

Errata ID: 1382
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Tony Hansen
Date Reported: 2008-03-21
Held for Document Update by: Pasi Eronen

Section 3.6.1 says:

   s=  Service Type (plain-text; OPTIONAL; default is "*").  A colon-
       separated list of service types to which this record applies.
       Verifiers for a given service type MUST ignore this record if the
       appropriate type is not listed.  Currently defined service types
       are as follows:

       *   matches all service types

       email   electronic mail (not necessarily limited to SMTP)

       This tag is intended to constrain the use of keys for other
       purposes, should use of DKIM be defined by other services in the
       future.

It should say:

   s=  Service Type (plain-text; OPTIONAL; default is "*").  A colon-
       separated list of service types to which this record applies.
       Verifiers for a given service type MUST ignore this record if the
       appropriate type is not listed.  Currently defined service types
       are as follows:

       *   matches all service types

       email   electronic mail (not necessarily limited to SMTP)

       Unrecognized service types MUST be ignored.

       This tag is intended to constrain the use of keys for other
       purposes, should use of DKIM be defined by other services in the
       future.

Notes:

From the October 2008 interop event:

DNS Key Interoperability Issues: “s=” in key records

* §3.6.1 doesn't say what to do if one of the colon-separated words is a word not enumerated in the “currently defined service types”
s=foo:email:bar
* No explicit guidance about what to do with clearly bogus values, e.g.
s=*:email
* Consensus is to ignore any colon-separated value not recognized and only pay attention to “*” and “email” for DKIM e-mail implementations

Errata ID: 1386
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Delany
Date Reported: 2008-03-24
Held for Document Update by: Pasi Eronen

Section 3.5 says:

DKIM-Signature: a=rsa-sha256; d=example.net; s=brisbane;

It should say:

DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane;

Notes:

The example is missing the v= tag which MUST be included.

Errata ID: 1532
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Tony Hansen
Date Reported: 2008-09-30
Held for Document Update by: Sean Turner

Section 3.6.1 says:

N/A (see Notes below)

It should say:

Add text similar to the following:

Compatibility Note for DomainKeys

If a v= value is not found at the beginning of the DKIM key record, 
the key record should be interpreted as for DomainKeys [4870]. The 
definition given here is upwardly compatible with what is used for 
DomainKeys, with the exception of the "g=" value. In a DomainKeys 
key record, an empty "g=" value should be interpreted as being 
equivalent to DKIM's "g=*".

Notes:

There should be a note added somewhere to section 3.6.1 saying
that if a v= is not found at the beginning of the DKIM key
record, the DNS key record should be interpreted as for DomainKeys
and described in RFC 4870. In addition, a note should be added
about the difference in the interpretation of an empty "g=",
which is the only incompatible tag.

Errata ID: 1596
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Tony Hansen
Date Reported: 2008-11-17
Held for Document Update by: Sean Turner

Section 2.4/3.7 says:

Here're the relevant portions of RFC 4871 

   2.4.  Common ABNF Tokens

   The following ABNF tokens are used elsewhere in this document:

     base64string =     1*(ALPHA / DIGIT / "+" / "/" / [FWS])
                        [ "=" [FWS] [ "=" [FWS] ] ]

   3.7.  Computing the Message Hashes
 
   2.  The DKIM-Signature header field that exists (verifying) or will
       be inserted (signing) in the message, with the value of the "b="
       tag deleted (i.e., treated as the empty string), canonicalized
       using the header canonicalization algorithm specified in the "c="
       tag, and without a trailing CRLF.

Sections 3.2 and 3.5 have this to say:

   3.2.  Tag=Value Lists
 
   Formally, the syntax rules are as follows:

        tag-list  =  tag-spec 0*( ";" tag-spec ) [ ";" ]
        tag-spec  =  [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS]
        tag-name  =  ALPHA 0*ALNUMPUNC
        tag-value =  [ tval 0*( 1*(WSP / FWS) tval ) ]
                          ; WSP and FWS prohibited at beginning and end
        tval      =  1*VALCHAR

   Note that WSP is allowed anywhere around tags.  In particular, any
   WSP after the "=" and any WSP before the terminating ";" is not part
   of the value; however, WSP inside the value is significant.

   3.5.  The DKIM-Signature Header Field

   The signature of the email is stored in the DKIM-Signature header
   field.  This header field contains all of the signature and key-
   fetching data.  The DKIM-Signature value is a tag-list as described
   in Section 3.2.

   ...

   b=  The signature data (base64; REQUIRED).  Whitespace is ignored in
       this value and MUST be ignored when reassembling the original
       signature.  In particular, the signing process can safely insert
       FWS in this value in arbitrary places to conform to line-length
       limits.  See Signer Actions (Section 5) for how the signature is
       computed.

   ABNF:

       sig-b-tag       = %x62 [FWS] "=" [FWS] sig-b-tag-data
       sig-b-tag-data  = base64string

It should say:

Add text "(including all surrounding whitespace)" to the description of deleting the b= value.

   3.7.  Computing the Message Hashes

   2.  The DKIM-Signature header field that exists (verifying) or will
       be inserted (signing) in the message, with the value of the "b="
       tag (including all surrounding whitespace) deleted 
       (i.e., treated as the empty string), canonicalized
       using the header canonicalization algorithm specified in the "c="
       tag, and without a trailing CRLF.

Fix the ambiguity in the base64string grammar to remove leading and trailing FWS:

     ALPHADIGITPS =     (ALPHA / DIGIT / "+" / "/")

     base64string =     ALPHADIGITPS *([FWS] ALPHADIGITPS)
                        [ [FWS] "=" [ [FWS] "=" ] ]

Notes:

The issues are, what constitutes the *value* of the b= tag? Is it everything after the "=" through any following ";" and/or the end of the header? Does that include or exclude surrounding white space? Is it specifically the characters that constitute "tag-val" / "sig-b-tag-data"? Does sig-b-tag-data include or exclude white space?

Notice how the section 3.5 "b=" deletion description talks about adding FWS "in" the value, but not "before" or "after".

Notice that the section 3.2 definition of tag-val

tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS]
tag-value = [ tval 0*( 1*(WSP / FWS) tval ) ]
; WSP and FWS prohibited at beginning and end

explicitly does *not* include either the FWS before its value or after.

And the text in section 3.2 explicitly says that the surrounding WSP is not part of the value.

And notice that the section 3.5 grammar around sig-b-tag-data

sig-b-tag = %x62 [FWS] "=" [FWS] sig-b-tag-data
sig-b-tag-data = base64string

explicitly mentions FWS as being separate from the data.

By the above definitions, tag-val and sig-b-tag-data explicitly do *not* include the FWS either before or after it.

However, the definition of base64string

base64string = 1*(ALPHA / DIGIT / "+" / "/" / [FWS])
[ "=" [FWS] [ "=" [FWS] ] ]

tosses FWS in to its production. So it is ambiguous from the grammar whether the leading/trailing FWS is part of sig-b-tag-data or part of base64string. (This grammar ambiguity is in *all* of the uses of base64string in sections 3.5 and 3.6.1.)

In addition, the text in the section 3.5 b= description certainly implies that white space before and after the hash should not affect the verification.

So by these, "with the value of the 'b=' tag deleted" could mean 1) everything after the "=" which includes the leading/trailing white space, 2) the *tag-value* grammar production which excludes leading/trailing white space, or 3) the *sig-b-tag-data* grammar production that may or may not include leading/trailing white space.

**This is an ambiguity (a bug) in the spec.**

Errata ID: 1383
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tony Hansen
Date Reported: 2008-03-21
Held for Document Update by: Pasi Eronen
Date Held: 2009-05-05

Section 3.6.1 says:

   g=  Granularity of the key (plain-text; OPTIONAL, default is "*").
       ....  Wildcarding allows matching for addresses such as
       "user+*" or "*-offer".  An empty "g=" value never matches any
       addresses.

It should say:

   g=  Granularity of the key (plain-text; OPTIONAL, default is "*").
       ....  Wildcarding allows matching for addresses such as
       "user+*", "*-offer", or "foo*bar". An empty "g=" value never 
       matches any addresses.

Notes:

The ABNF allows "*" in the middle (but only one), and this should
be shown in the examples, too.

RFC 4872, "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", May 2007

Note: This RFC has been updated by RFC 4873, RFC 6780, RFC 9270

Source of RFC: ccamp (rtg)

Errata ID: 932
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-07
Held for Document Update by: Adrian Farrel
Date Held: 2010-10-30

Section 16 says:

   The ASSOCIATION object is used to associate LSPs with each other.

It should say:

[not submitted]

Notes:

The second paragraph of Section 16 is a literal restatement of the
first sentence of the same section, on the same page (37).
Therefore, the last text line of Section 16 (above), should be deleted.

RFC 4873, "GMPLS Segment Recovery", May 2007

Note: This RFC has been updated by RFC 9270

Source of RFC: ccamp (rtg)

Errata ID: 935
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-08
Held for Document Update by: Adrian Farrel

 

Section 2

Near the end of the second-to-last paragraph on page 5, RFC 4873 says:

                                                        [...].  The
   branch node of a recovery LSP creates an SRRO by copying the RRO from
|  the Resv message of associated recovery LSP into a new SRRO object.
   Any SRROs present in the recovery LSP's Resv message are also copied.

It should say:
                                                        [...].  The
   branch node of a recovery LSP creates an SRRO by copying the RRO from
|  the Resv message of the associated recovery LSP into a new SRRO
   object.  Any SRROs present in the recovery LSP's Resv message are
   also copied.

Rationale:  missing article.


Section 3.2

On page 7, the last sentence of Section 3.2 says:

|              [...].  This object MUST NOT be used when association is
   made according to the methods defined in [RFC4090].

It should say:

|              [...].  This object MUST NOT be used when an association
   is made according to the methods defined in [RFC4090].

Rationale:  missing article.


Section 4.1

On page 8, Section 4.1 says:

                   [...].  This includes the definition of subobjects
|  defined for EXPLICIT_ROUTE object.  The class of the
   SECONDARY_EXPLICIT_ROUTE object is 200 (of the form 11bbbbbb).

It should say:

                   [...].  This includes the definition of subobjects
|  defined for the EXPLICIT_ROUTE object.  The class of the
   SECONDARY_EXPLICIT_ROUTE object is 200 (of the form 11bbbbbb).

Rationale:  missing article.


Section 4.2

In the second paragraph on page 10, Section 4.2 says:

|  At a branch node, the SERO, together with the Path message of LSP
   being recovered, provides the information to create the recovery LSP.
   [...]

It should say:

|  At a branch node, the SERO, together with the Path message of the LSP
   being recovered, provides the information to create the recovery LSP.
   [...]

Rationale:  missing article.


Section 4.2.1

Near the bottom of page 10, the first paragraph of Section 4.2.1 says:

                                                          [...].  The
|  processing of these events depend on a number of factors.

It should say:
                                                          [...].  The
|  processing of these events depends on a number of factors.
                                    ^
Rationale:  grammar.


Section 4.3.2

The second sentence of Section 4.3.2 says:

|                      [...].  When a branch or merge node receives
   notification of an LSP failure and it is unable to recover from that
   failure, [...]

It should say:
|                      [...].  When a branch or merge node receives a
   notification of an LSP failure and it is unable to recover from that
   failure, [...]

Rationale:  missing article.


Section 6.2

The last sentence of the third paragraph of Section 6.2,
on mid-page 17, says:

                                                             [...].  The
   dynamically identified information, together with the Path message of
|  LSP being recovered, is used to create the recovery LSP.

It should say:
                                                             [...].  The
   dynamically identified information, together with the Path message of
|  the LSP being recovered, is used to create the recovery LSP.

Rationale:  missing article.

It should say:

[see above]

Notes:

editorial nits.

from pending

Errata ID: 941
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-08
Held for Document Update by: Adrian Farrel
Date Held: 2010-10-30

Section 5.1 says:

   The format of a SECONDARY_RECORD_ROUTE object is the same as a
   RECORD_ROUTE object, Class number 21.  This includes the definition
   of subobjects defined for RECORD_ROUTE object.  The class of the
   SECONDARY_RECORD_ROUTE object is 201 (of the form 11bbbbbb).

It should say:

   The format of a SECONDARY_RECORD_ROUTE object is the same as that of
   a RECORD_ROUTE object, Class number 21.  This includes the definition
   of subobjects defined for the RECORD_ROUTE object.  The class of the
   SECONDARY_RECORD_ROUTE object is 201 (of the form 11bbbbbb).

Notes:

The proposed text change (below) is rejected in favor of more correct English.
The format of a SECONDARY_RECORD_ROUTE object is the same as for a
RECORD_ROUTE object, Class number 21. This includes the definition
of subobjects defined for the RECORD_ROUTE object. The class of the
SECONDARY_RECORD_ROUTE object is 201 (of the form 11bbbbbb).

RFC 4875, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", May 2007

Note: This RFC has been updated by RFC 6510

Source of RFC: mpls (rtg)

Errata ID: 2481
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Held for Document Update by: Adrian Farrel
Date Held: 2010-08-21

 

Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.

(1)  Section 4.5 -- syntax / punctuation issue

In the first paragraph of Section 4.5, on page 7, RFC 4875 says:
                                           vv
|           [...].  The < [<EXPLICIT_ROUTE>], <S2L_SUB_LSP> > tuple
   represents the S2L sub-LSP and is referred to as the sub-LSP
   descriptor.  [...]

Obviously, the tagged comma should be *inside* the square brackets:
                                           vv
|           [...].  The < [<EXPLICIT_ROUTE>,] <S2L_SUB_LSP> > tuple
   represents the S2L sub-LSP and is referred to as the sub-LSP
   descriptor.  [...]

The same issue recurs in the third paragraph of Section 4.5, on the
same page.

At similar places in the RFC, e.g. in the first paragraph of
Section 5.2.1, the comma is omitted entirely in the tuple notation.
That is very unusual.

It should say:

[see above]

Errata ID: 2482
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Held for Document Update by: Adrian Farrel
Date Held: 2010-08-21

Section 5.2.1 says:

Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.

(2)  Section 5.2.1 -- typo (text reformatting problem ?)

In the 5th line of the last-paragraph of Section 5.2.1,
    "Sub- Group"   should be spelled   "Sub-Group" .

Errata ID: 2484
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Held for Document Update by: Adrian Farrel
Date Held: 2010-08-21

Section 6.2 says:

Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.

(4)  Section 6.2 -- missing article

The second paragraph of Section 6.2, on mid-page 17, says:

                                 [...].  When the integrity bit is set
|  in the LSP_REQUIRED_ATTRIBUTE object, Resv message MUST NOT be sent
   upstream until all Resv messages have been received from the
   downstream neighbors.

Missing indefinite article.

It should say:

                                 [...].  When the integrity bit is set
|  in the LSP_REQUIRED_ATTRIBUTE object, a Resv message MUST NOT be sent
   upstream until all Resv messages have been received from the
   downstream neighbors.

Errata ID: 2485
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Held for Document Update by: Adrian Farrel
Date Held: 2010-08-21

Section 8.2 says:

Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.

(5)  Section 8.2 -- text duplication and inconsistency

The second paragraph of Section 8.2 (on page 23),

   A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC
   object(s) of a Resv message to the value that was received in the
   corresponding Path message.  If any of the incoming Resv messages
   corresponding to a single Path message carry a RESV_CONFIRM object,
   then the LSR MUST include a RESV_CONFIRM object in the corresponding
   Resv message that it sends upstream.  If the Sub-Group Originator ID
   is its own address, then it MUST set the receiver address in the
   RESV_CONFIRM object to this address, else it MUST propagate the
   object unchanged.

should be deleted entirely !

Rationale:
  The first two sentences in this paragraph are repeated almost
  literally in the subsequent (third) paragraph of the section.
  The third (last) sentence above essentially is superseeded, in
  a more precise manner, by the second and the third bullet at the
  bottom of page 23.
  But, perhaps most importantly, the first bullet there handles a
  subcase not covered by, and hence mis-specified, by that sentence!

  Apparently, the lower half of page 23 is a revised revision of
  the quoted second paragraph, which should have been deleted.

Errata ID: 2486
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Held for Document Update by: Adrian Farrel
Date Held: 2010-08-21

Section 10.2 says:

Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.

(6)  Section 10.2 -- clarification including mismatched angle
                     brackets, word omissions, and punctuation

Within Section 10.2, the third paragraph on page 26 says:

   [...]
|  A newly received Path message that matches SESSION object and Sender
   Tunnel Address, LSP ID, Sub-Group Originator ID> with existing Path
|  state carrying the same or different Sub-Group_ID, referred to Sub-
|  Group_ID(n) is processed as follows:

It should say:

|  A newly received Path message with SESSION object and <Sender Tunnel
|  Address, LSP ID, Sub-Group Originator ID> tuple matching existing
|  Path state carrying the same or a different Sub-Group_ID, referred to
|  as Sub-Group_ID(n), is processed as follows:

Errata ID: 2487
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Held for Document Update by: Adrian Farrel
Date Held: 2010-08-21

Section 11.3 says:

Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.

(7)  Section 11.3

Established language in IETF (and other) publications is "tear down",
not simply "tear", when it comes to the deletion of connections etc.

Therefore, while not really wrong, I would have appreciated the
following changes:

- in the 5th line of the 3rd paragraph of Section 11.3 (on page 28):
       "It does not tear any other branches ..."
  -->  "It does not tear down any other branches ..."

- in the 5th paragraph of Section 11.3, in the last text line on p.28:
       "... that are explicitely torn ..."
  -->  "... that are explicitely torn down ..."

[ I note this minor issue just for consideration in the preparation
  of future / derived work. ]

Errata ID: 2488
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Held for Document Update by: Adrian Farrel
Date Held: 2010-08-21

Section 15.1.2 says:

Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.

(8)  Section 15.1.2 -- another typo

On page 31, in the 6th line of the first paragraph of Section 15.1.2,

  "being backed- up"  should be  "being backed up"

[ The hyphenated form, "backed-up" is only appropriate in adverbial
  context, e.g., "a backed-up LSP". ]

Errata ID: 2489
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Held for Document Update by: Adrian Farrel
Date Held: 2010-08-21

Section 16 says:

Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.

(9)  Section 16 -- typo/grammar

Within Section 16, the third paragraph on page 34 says:

   There maybe overhead for an operator to configure ...

It should say:

   There may be overhead for an operator to configure ...
            ^

Rationale: Otherwise, the sentence lacks of a verb.

Errata ID: 2491
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Held for Document Update by: Adrian Farrel
Date Held: 2010-08-21

Section 18 says:

Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.

(11)  Section 18 -- typo (text reformatting problem ?)

Within Section 18, at the bottom of page 35,
    "re- merge"  should be  "re-merge"

Errata ID: 2493
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Held for Document Update by: Adrian Farrel
Date Held: 2010-08-21

Section 19 says:

Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.

(12)  Section 19

(12b) -- unusual presentation

It is unusual to present the explanations of fields in a diagram
in a sequence that does not correspond to the sequence of the
fields therein.

Therefore, I would have appreciated it to find ...

o  in Section 19.2.1 (on page 41) the explanation for "LSP ID"
   not at the bottom of the list, but at the second position,
   below the explanation for "IPv4 tunnel sender address";

and

o  in Section 19.2.2 (on page 42) the explanation for "LSP ID"
   not at the bottom of the list, but at the second position,
   below the explanation for "IPv6 tunnel sender address";

RFC 4880, "OpenPGP Message Format", November 2007

Note: This RFC has been updated by RFC 5581

Source of RFC: openpgp (sec)

Errata ID: 2199
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner

Section 3.7.2.1. says:

For compatibility, when an S2K specifier is used, the special value
254 or 255 is stored in the position where the hash algorithm octet
would have been in the old data structure.  This is then followed
immediately by a one-octet algorithm identifier, and then by the S2K
specifier as encoded above.

It should say:

For compatibility, when an S2K specifier is used, the special value
254 or 255 is stored in the position where the cipher algorithm octet
would have been in the old data structure.  This is then followed
immediately by a one-octet cipher algorithm identifier, and then by
the S2K specifier as encoded above.

Notes:

The paragraph before says:
Older versions of PGP just stored a cipher algorithm octet preceding
the secret data or a zero to indicate that the secret data was
unencrypted. The MD5 hash function was always used to convert the
passphrase to a key for the specified cipher algorithm.

Errata ID: 2200
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner

Section 3.7.2.1. says:

This last possibility, the cipher algorithm number with an implicit
use of MD5 and IDEA, is provided for backward compatibility;

It should say:

This last possibility, the cipher algorithm number with an implicit
use of MD5, is provided for backward compatibility;

Notes:

The cipher algorithm is determined by the number. There is no implicit
use of IDEA.

Errata ID: 2206
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Date Held: 2010-07-20

Section 5.1. says:

A Public-Key Encrypted Session Key packet holds the session key used 
to encrypt a message.

It should say:

A Public-Key Encrypted Session Key (PKESK) packet holds the session 
key used to encrypt a message.

Notes:

The acronym PKESK is not defined.

Tweaked the suggestion to reword the 1st sentence in 5.1 to define it.

Errata ID: 2208
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Date Held: 2010-07-20

Section 5.2.1. says:

   This signature is a statement by a signing subkey, indicating that
   it is owned by the primary key and subkey.

It should say:

   This signature is a statement by a signing subkey, indicating that
   it is owned by the primary key.

Notes:

The subkey does not own itself.

Errata ID: 2214
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Date Held: 2010-07-20

Section 5.2.3. says:

   The concatenation of the data being signed and the signature data
   from the version number through the hashed subpacket data (inclusive)
   is hashed.  The resulting hash value is what is signed.  The left 16
   bits of the hash are included in the Signature packet to provide a
   quick test to reject some invalid signatures.

   There are two fields consisting of Signature subpackets.  The first
   field is hashed with the rest of the signature data, while the second
   is unhashed.

It should say:

   The concatenation of the data being signed and the signature data from
   the version number through the hashed subpacket data (inclusive), plus
   a six-octet trailer (see section 5.2.4) is hashed.  The resulting hash
   value is converted to the signature.  The left 16 bits of the hash are
   included in the Signature packet to provide a quick test to reject
   some invalid signatures.

   There are two fields consisting of Signature subpackets.  The first
   field (together with the preceding parts of the signature) is
   included in the hash, while the second is not.

Notes:

There are six more octets (see 5.2.4.).
The data being signed is signed. The hash value is not signed, but
converted into the signature.
The first field is not hashed (does not contain a hash), but it is
hashincluded. It is not true that the rest of the signature data is used
in the hash. (This formulation is such strange for accuracy.)
Unhashing is the reverse of hashing, which is hopefully unfeasible.

Modified text.

Errata ID: 2216
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner

Section 5.2.3.3. says:

   Subpackets that appear in a certification self-signature
   apply to the user name, and subpackets that appear in the subkey
   self-signature apply to the subkey.

It should say:

   Subpackets that appear in a certification self-signature
   apply to the User ID, and subpackets that appear in the subkey
   self-signature apply to the subkey.

Notes:

User ID, not user name

Errata ID: 2219
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Date Held: 2010-07-20

Section 5.3. says:

   The message is encrypted with a session key, and the session key is
   itself encrypted and stored in the Encrypted Session Key packet or
   the Symmetric-Key Encrypted Session Key packet.

It should say:

   The message is encrypted with a session key, and the session key is
   itself encrypted and stored in the Public-Key Encrypted Session Key
   packet or the Symmetric-Key Encrypted Session Key packet.

Notes:

The word `Public-Key' is missing.

Changed to editorial

Errata ID: 2222
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Date Held: 2010-07-20

Section 5.5.3. says:

   Implementations MUST use a string-to-key specifier; the simple hash
   is for backward compatibility and is deprecated, though
   implementations MAY continue to use existing private keys in the old
   format.

It should say:

   Implementations MUST generate a string-to-key specifier; the simple
   hash is for backward compatibility and is deprecated, though
   implementations MAY continue to use existing private keys in the old
   format.

Notes:

MUST use and MAY continue to use the opposite is a contradiction.

Changed to editorial.

Errata ID: 2226
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Date Held: 2010-07-20

Section 5.9. says:

       These should be converted to native line endings by the receiving
       software.

It should say:

       These SHOULD be converted to native line endings by the receiving
       software.

Notes:

This is a SHOULD of [RFC2119].

Changed to editorial.

Errata ID: 2234
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Date Held: 2010-07-20

Section 6.5. says:

    Examples of Radix-64

It should say:

    Examples of base64

Notes:

Radix-64 has a checksum, too.

Changed to editorial.

Errata ID: 2235
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Date Held: 2010-07-20

Section 8. says:

   If two characters in the sequence are separated
   by '-', this is shorthand for the full list of ASCII characters
   between them (e.g., '[0-9]' matches any decimal digit).

It should say:

   If two characters in the sequence are separated by '-', this is
   shorthand for the full list of ASCII characters between them (e.g.,
   '[0-9]' matches any decimal digit).  The collation sequence is UTF-8.

Notes:

UTF-8 has the collation sequence of unicode. You probably do not want
to have the system's locale involved.

Maybe a hint on greediness of regex is nessessary, too.

Changed to editorial.

Errata ID: 2236
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner

Section 11. says:

11.  Packet Composition

(the headline)

It should say:

11.  Packet Sequence Composition

Notes:

It is about the composition of a sequence of packets, not about the
composition of a packet.

Errata ID: 2238
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Date Held: 2010-07-20

Section 11.1. says:

   After the User ID packet or Attribute packet, there may be zero or
   more Subkey packets.

It should say:

   After the sequence with the User ID packets and User Attribute
   packets, there may be zero or more Subkey packets.

Notes:

The Subkey packets come after all User ID packets and User Attribute
packets.

Changed to editorial.

Errata ID: 2240
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Date Held: 2010-07-20

Section 12.1. says:

   In the above diagram, if the binding signature of a subkey has been
   revoked, the revoked key may be removed, leaving only one key.

It should say:

   In the above diagram, if the binding signature of a subkey has been
   revoked, the revoked key may be removed.  Note that this bears the
   danger of importing the subkey again without the Binding Signature
   Revocation.

Notes:

If there are more than one subkeys, the removing of one leaves more
than one key. And the warning is missing.

Changed to editorial.

Errata ID: 2243
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Date Held: 2010-07-20

Section 13.9. says:

   OpenPGP CFB mode uses an initialization vector (IV) of all zeros, and
   prefixes the plaintext with BS+2 octets of random data, such that
   octets BS+1 and BS+2 match octets BS-1 and BS.  It does a CFB
   resynchronization after encrypting those BS+2 octets.

   Thus, for an algorithm that has a block size of 8 octets (64 bits),
   the IV is 10 octets long and octets 7 and 8 of the IV are the same as
   octets 9 and 10.  For an algorithm with a block size of 16 octets
   (128 bits), the IV is 18 octets long, and octets 17 and 18 replicate
   octets 15 and 16.  Those extra two octets are an easy check for a
   correct key.

It should say:

   OpenPGP CFB mode uses an initialization vector (IV) of all zeros, and
   prefixes the plaintext with BS+2 octets of random data, such that
   octets BS+1 and BS+2 match octets BS-1 and BS.  It does a CFB
   resynchronization after encrypting those BS+2 octets.

   Thus, for an algorithm that has a block size of 8 octets (64 bits),
   the virtual IV is 10 octets long and octets 7 and 8 of the virtual IV
   are the same as octets 9 and 10.  For an algorithm with a block size
   of 16 octets (128 bits), the virtual IV is 18 octets long, and octets
   17 and 18 replicate octets 15 and 16. Those extra two octets are an
   easy check for a correct key."

Notes:

'IV' is used in a contradicting manner.

Changed to editorial.

From Jon. C.: This is a marvelous re-wording of a confusing process. I really like the “virtual IV” mentioned. However, the suggested change omitted the final sentence, which is the whole reason for the virtual IV. I have restored that sentence.

Errata ID: 5491
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marco Bellaccini
Date Reported: 2018-09-04
Held for Document Update by: Benjamin Kaduk
Date Held: 2019-06-12

Section 6.1 says:

#define CRC24_POLY 0x1864CFBL

It should say:

#define CRC24_POLY 0x864CFBL

Notes:

In the C reference implementation of CRC-24, the generator used does not match the specification in Section 6, though the final masking step avoids a functional difference.

Errata ID: 7545
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Raghu Saxena
Date Reported: 2023-06-16
Held for Document Update by: RFC Editor
Date Held: 2023-06-19

Section 6.2 says:

   The format of an Armor Header is that of a key-value pair.  A colon
   (':' 0x38) and a single space (0x20) separate the key and value.
   OpenPGP should consider improperly formatted Armor Headers to be
   corruption of the ASCII Armor.  Unknown keys should be reported to
   the user, but OpenPGP should continue to process the message.

It should say:

   The format of an Armor Header is that of a key-value pair.  A colon
   (':' 0x3A) and a single space (0x20) separate the key and value.
   OpenPGP should consider improperly formatted Armor Headers to be
   corruption of the ASCII Armor.  Unknown keys should be reported to
   the user, but OpenPGP should continue to process the message.

Notes:

0x3A is a colon -> ':' , whereas 0x38 is the character for the numeral eight -> '8'

RFC 4885, "Network Mobility Support Terminology", July 2007

Source of RFC: nemo (int)

Errata ID: 1041
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Held for Document Update by: Brian Haberman

Section 5.2 says:

                                   _____
                   _           _  |     |
                  |_|-|  _  |-|_|-|     |-|        _
                   _  |-|_|=|  \  |_____| |  _  |-|_|
                  |_|-|     |             |-|_|-|
                                             \  |
                  MNNs   MR   AR  Internet   AR    HA

              Figure 6: Multihoming: MR with multiple E-faces

It should say:

[not supplied]

Notes:

(1) The term 'E-faces' used in the figure caption does not appear
anywhere else in the text. I suspect this is a sluggish
contraction of the defined term, 'egress interfaces', and IMHO,
it should better have been avoided in favor of the latter.

(2) The artwork does *not* visually represent in any way the
essential point pretended (and perhaps intended) to be shown
in the figure: *multiple* egress interfaces of the MR.

RFC 4888, "Network Mobility Route Optimization Problem Statement", July 2007

Source of RFC: nemo (int)

Errata ID: 1039
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-11
Held for Document Update by: Ralph Droms

 

(1)  outdated / inappropriate Reference

The second bullet in Section 2.1 of RFC 4888, on top of page 5, says:

              [...].  For instance, given a voice application using an 8
      kbps algorithm (e.g., G.729) and taking a voice sample every 20 ms
|     (as in RFC 1889 [6]), the packet transmission rate will be 50
      packets per second.  [...]

and Section 6.2, on page 12, contains the details for the ref. [6].

RFC 1889 has long been obsoleted by STD 64, RFC 3550.
Furthermore, I seriously doubt whether the reference to the core
RTP specification is appropriate here; most probably, a reference
to the RTP A/V profile specification, STD 65, RFC 3551, would have
been much more appropriate, because Section 4.5.6 of that RFC
contains the current specification with the relevant details
for the G.729 codec mentioned in the example.


(2)  textual issues in Section 1

The first paragraph of Section 1, on page 3 of RFC 4888, says:

   With current Network Mobility (NEMO) Basic Support [1], all
   communications to and from nodes in a mobile network must go through
   the bi-directional tunnel established between the Mobile Router and
   its Home Agent (also known as the MRHA tunnel) when the mobile
|  network is away.  Although such an arrangement allows Mobile Network
   Nodes to reach and be reached by any node on the Internet,
   limitations associated to the base protocol degrade overall
   performance of the network and, ultimately, can prevent all
   communications to and from the Mobile Network Nodes.

It should perhaps better say, inserting "from home" for clarification:

   With current Network Mobility (NEMO) Basic Support [1], all
   communications to and from nodes in a mobile network must go through
   the bi-directional tunnel established between the Mobile Router and
   its Home Agent (also known as the MRHA tunnel) when the mobile
|  network is away from home.  Although such an arrangement allows
   Mobile Network Nodes to reach and be reached by any node on the
   Internet, limitations associated to the base protocol degrade overall
   performance of the network and, ultimately, can prevent all
   communications to and from the Mobile Network Nodes.

In the subsequent second paragraph of Section 1,

   Some of these concerns already exist with Mobile IPv6 [4] and were
   addressed by the mechanism known as Route Optimization, which is part
   of the base protocol.  With Mobile IPv6, Route Optimization mostly
|  improves the end-to-end path between the Mobile Node and
   Correspondent Node, with an additional benefit of reducing the load
   of the Home Network, thus its name.

perhaps another article "the" should have been inserted:

   Some of these concerns already exist with Mobile IPv6 [4] and were
   addressed by the mechanism known as Route Optimization, which is part
   of the base protocol.  With Mobile IPv6, Route Optimization mostly
|  improves the end-to-end path between the Mobile Node and the
   Correspondent Node, with an additional benefit of reducing the load
   of the Home Network, thus its name.


(3) Appendix A,  Section A.4.3

In the last paragraph of Section A.4.3, at the bottom of page 21,
RFC 4888 says:

              [...].  This is particularly useful for a short-term
   communications that may easily be retried if it fails.  [...]

the phrase
            "a short-term communications"

should have been corrected to say either

            "a short-term communication"
or:
            "short-term communications" .

RFC 4889, "Network Mobility Route Optimization Solution Space Analysis", July 2007

Source of RFC: nemo (int)

Errata ID: 1038
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-12
Held for Document Update by: Brian Haberman

Section 5.1.2 says:

   Traditionally, it has been generally
   avoided having state information in the routers to increase
   proportionally with the number of pairs of communicating peers.

It should say:

[see below]

Notes:

This is not true for the vast majority of IPv4 routers deployed
today, the typical NAT/NAPT 'SOHO' access routers, which all need to
keep *per flow* state -- increasing even more, proportionally with
the number of transport 'sessions' between communicating peers!

Errata ID: 1037
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-12
Held for Document Update by: Brian Haberman

 

(1)  Section titles -- missing articles

The following section titles:

       5.5.1.  Binding to the Location of Parent Mobile Router
and
       5.5.3.  Binding to the Location of Root Mobile Router

apparently lack of tha article after "of", and should therefore
better have been written as:

       5.5.1.  Binding to the Location of the Parent Mobile Router
and
       5.5.3.  Binding to the Location of the Root Mobile Router

or perhaps alternatively, even shorter:

       5.5.1.  Binding to the Parent Mobile Router's Location
and
       5.5.3.  Binding to the Root Mobile Router's Location


(2)  Section 1 -- a typo and sluggish wording

(2a)
The first paragraph of Section 1 says:

   Network Mobility Route Optimization Problem Statement [1] describes
|  operational limitations and overheads incurred in a deployment of
   Network Mobility (NEMO) Basic Support [2], which could be alleviated
   by a set of NEMO Route Optimization techniques to be defined.

It should perhaps better have used the singular, "overhead",
and stated:

   Network Mobility Route Optimization Problem Statement [1] describes
|  operational limitations and overhead incurred in a deployment of
   Network Mobility (NEMO) Basic Support [2], which could be alleviated
   by a set of NEMO Route Optimization techniques to be defined.

(2b)
The last paragraph of Section 1 says:

                      [...].  A point to note is that since this
   document discusses aspects of Route Optimization, the reader may
|  assume that a mobile network or a mobile host is away when they are
   mentioned throughout this document, unless it is explicitly specified
   that they are at home.

The sluggish abbreviated pure "away" should better have been avoided,
stating:
                      [...].  A point to note is that since this
   document discusses aspects of Route Optimization, the reader may
|  assume that a mobile network or a mobile host is away from home when
   they are mentioned throughout this document, unless it is explicitly
   specified that they are at home.


(3)  Section 2

As in item (2a) above, in the 4th bullet of Section 2, near the
bottom of page 4,  "overheads"  should perhaps better b replaced by
the singular form, "overhead".


(4)  Section 3.1 -- missing article

The initial paragraph of Section 3.1, on mid-page 6, says:

|                 [...].  With the use of Correspondent Router, Route
   Optimization session is terminated at the Correspondent Router on
   behalf of the Correspondent Node.  As long as the Correspondent
   Router is located "closer" to the Correspondent Node ...

It should better say:
                                                               vvvv
|                 [...].  With the use of Correspondent Router, the
   Route Optimization session is terminated at the Correspondent Router
   on behalf of the Correspondent Node.  As long as the Correspondent
   Router is located "closer" to the Correspondent Node ...


(5)  Section 3.2.1 -- mis-wording

The last paragraph/sentence of Section 3.1.2, at the bottom of
page 8, does not parse.

The RFC says:

   An example of this approach include Reverse Routing Header (RRH)
   [10].

It should perhaps say either:

   An example of this approach can be found in Reverse Routing Header
   (RRH) [10].

or simply:

   Reverse Routing Header (RRH) [10] is an example of this approach.


(6)  Section 3.3 -- typo

The first paragraph of Section 3.3, on mid-page 9, says:

   An infrastructure-based optimization is an approach where
   optimization is carried out fully in the infrastructure.  One example
   is to make use of Mobility Anchor Points (MAPs) such as defined in
   HMIPv6 [13] to optimize routes between themselves.  Another example
|  is to make use of proxy Home Agent such as defined in the global Home
   Agent to Home Agent (HAHA) protocol [14].  A proxy Home Agent acts as
   a Home Agent for the Mobile Node, and acts as a Mobile Node for the
   Home Agent, Correspondent Node, Correspondent Router, and other
   proxies.  In particular, the proxy Home Agent terminates the MRHA
   tunnel and the associated encryption, extracts the packets, and re-
   encapsulates them to the destination.  In this case, proxy Home
   Agents are distributed in the infrastructure and each Mobile Router
   binds to the closest proxy.  [...]

It should use the plural of "Home Agent" in the 5th line,
and thus say:

   An infrastructure-based optimization is an approach where
   optimization is carried out fully in the infrastructure.  One example
   is to make use of Mobility Anchor Points (MAPs) such as defined in
   HMIPv6 [13] to optimize routes between themselves.  Another example
|  is to make use of proxy Home Agents such as defined in the global
   Home Agent to Home Agent (HAHA) protocol [14].  A proxy Home Agent
   acts as a Home Agent for the Mobile Node, and acts as a Mobile Node
   for the Home Agent, Correspondent Node, Correspondent Router, and
   other proxies.  In particular, the proxy Home Agent terminates the
   MRHA tunnel and the associated encryption, extracts the packets, and
   re-encapsulates them to the destination.  In this case, proxy Home
   Agents are distributed in the infrastructure and each Mobile Router
   binds to the closest proxy.  [...]


(7)  Section 4.1 -- singular/plural mismatches

Within Section 4.1, at the bottom of page 1, ...

(7a)
the 2nd paragraph says:

|        [...].  This effect will be especially significant for wireless
|  environment where bandwidth is relatively limited.

where it should say:
                                                               vv
|        [...].  This effect will be especially significant for a
   wireless environment where bandwidth is relatively limited.

or:

         [...].  This effect will be especially significant for wireless
|  environments where bandwidth is relatively limited.
              ^
and ...

(7b)
the 3rd paragraph says:

|  It is possible to moderate the effect of Signaling Storm by
   incorporating mechanisms such as [...]

where it should say:
                                            vv
|  It is possible to moderate the effect of a Signaling Storm by
   incorporating mechanisms such as [...]

or:
                                                           v
|  It is possible to moderate the effect of Signaling Storms by
   incorporating mechanisms such as [...]

(Please choose!)


(8)  Section 4.2 -- missing article and singular/plural mismatch

The 1st paragraph of Section 4.2, on page 12, says:

                                  v
   It is expected that NEMO Route Optimization will be more complicated
|  than NEMO Basic Support.  Thus, complexity of nodes that are required
   to incorporate new functionalities to support NEMO Route Optimization
|  would be higher than those required to provide NEMO Basic Support.
                        ^^^^^
It should say:
                                  vvvvv
   It is expected that NEMO Route Optimization will be more complicated
|  than NEMO Basic Support.  Thus, the complexity of nodes that are
   required to incorporate new functionalities to support NEMO Route
|  Optimization would be higher than that required to provide NEMO
   Basic Support.
                                     ^^^^

(9)  Section 4.3 -- missing articles

The 1st paragraph of Section 4.3, on mid-page 12, says:
                                                            v
|  Due to the diversity of locations of different nodes that Mobile
                                                     v
|  Network Node may signal with and the complexity of NEMO Route
   Optimization procedure that may cause several rounds of signaling
   messages, a NEMO Route Optimization procedure may take a longer time
   to finish its handoff than that in NEMO Basic Support.  [...]

It should say:
                                                            vvv
|  Due to the diversity of locations of different nodes that a Mobile
                                                     vvv
|  Network Node may signal with and the complexity of a NEMO Route
   Optimization procedure that may cause several rounds of signaling
   messages, a NEMO Route Optimization procedure may take a longer time
   to finish its handoff than that in NEMO Basic Support.  [...]


(10)  Section 4.4 -- missing article

The first paragraph of Section 4.4, on top of page 13, says:

                         v
   In order to support NEMO Route Optimization, some nodes need to be
|  changed or upgraded.  Smaller number of nodes required to be changed
   will allow for easier adoption of the NEMO Route Optimization
   solution in the Internet and create less impact on existing Internet
   infrastructure.  [...]

It should say:
                         vvv
   In order to support NEMO Route Optimization, some nodes need to be
|  changed or upgraded.  A smaller number of nodes required to be
   changed will allow for easier adoption of the NEMO Route Optimization
   solution in the Internet and create less impact on existing Internet
   infrastructure.  [...]


(11)  Section 4.6

In the first paragraph of Section 4.6, in place of:

   ... keep track of the states of all Route Optimization sessions.
                              ^
the RFC should preferably say:

   ... keep track of the state of all Route Optimization sessions.


(12)  Section 5

The list item:

   3.  How is Route Optimization capabilities detected?

should better say:

   3.  How are Route Optimization capabilities detected?
or:
   3.  How is Route Optimization capability detected?

... depending on whether you expect a variety or finer granularity of
Route Optimization capabilities vs. a single 'block' of procedures.
Many parts of the memo make it likely that there might be various
solutions for various senarios, and hence the former expectation
be more appropriate.


(13)  [[posted separately as Technical.]]


(14)  Section 5.1.3

The 3rd paragraph of Section 5.1.3, on top of page 18, says:

   A deployment consideration with respect to the use of Correspondent
|  Router is the location of the Correspondent Router relative to the
   Correspondent Node.  [...]

It should say:
         v
   A deployment consideration with respect to the use of Correspondent
|  Routers is the location of the Correspondent Router relative to the
   Correspondent Node.  [...]


(15)  Section 5.2

The first paragraphh of Section 5.2 (still on page 18) says:

                                                       [...].  However,
   when the mobile node is within a nested mobile network, the detection
   of the mobility of upstream Mobile Routers may need to be conveyed to
|  the nested Mobile Network Node.  This might incur longer signaling
   delay as discussed in Section 4.3.

It should say:
                                                       [...].  However,
   when the mobile node is within a nested mobile network, the detection
   of the mobility of upstream Mobile Routers may need to be conveyed to
|  the nested Mobile Network Node.  This might incur a longer signaling
   delay as discussed in Section 4.3.
                                                     ^^

(16)  Section 5.3 -- grammar

The first paragraphh of Section 5.3, on mid-page 19, says:

   The question here is how the initiator of Route Optimization knows
   whether the Correspondent Entity supports the functionality required
|  to established a Route Optimization session.  [...]
               ^^^

This sentence does not parse.
It should say:

   The question here is how the initiator of Route Optimization knows
   whether the Correspondent Entity supports the functionality required
|  to establish a Route Optimization session.  [...]
               ^

(17)  Section 5.5

The first paragraphh of Section 5.5, near the bottom of page 20, says:
               v
|  In order for route to be optimized, it is generally necessary for the
   Correspondent Entity to create a binding between the address and the
   location of the Mobile Network Node.  This can be done in the
   following ways:

It should say:
               vvv
|  In order for a route to be optimized, it is generally necessary for
   the Correspondent Entity to create a binding between the address and
   the location of the Mobile Network Node.  This can be done in the
   following ways:


(18)  Section 5.5.1

(18a) section headline -- see item (1) above

(18b) headline of second bullet on page 21

The RFC says:

|  o  Sending Information of Parent Mobile Router
                            ^
It should say:

|  o  Sending Information of the Parent Mobile Router
                            ^^^^^
This issue recurs several times in the text;
I omit to mention these details.

(18c)
At the bottom of page 22, the RFC says:

   One advantage shared by all the approaches listed here is that only
   mobility protocol is affected.  [...]

It should say:

   One advantage shared by all the approaches listed here is that only
|  the mobility protocol is affected.  [...]
   ^^^^


(19)  Section 5.5.3

(19a) section headline -- see item (1) above

(19b)
The third paragraph of the first bullet of Section 5.5.3, just below
the page break to page 25, says:

                              [...].  However, it requires the access
<< page break >>
|     router (or some other entity within the access network) and Mobile
|     Router to possess prefix delegation functionality, and also
      maintain information on what prefix is delegated to which node.
|     How to efficiently assign a subset of Mobile Network Prefix to
      child Mobile Routers could be an issue because Mobile Network
      Nodes may dynamically join and leave with an unpredictable
      pattern.  [...]

It should say:
                              [...].  However, it requires the access
<< page break >>                                                 vvvv
|     router (or some other entity within the access network) and the
      Mobile Router to possess prefix delegation functionality, and also
|     to maintain information on what prefix is delegated to which node.
      ^^^                                   vvvv
|     How to efficiently assign a subset of the Mobile Network Prefix to
      child Mobile Routers could be an issue because Mobile Network
      Nodes may dynamically join and leave with an unpredictable
      pattern.  [...]

(Alternatively, use "a" in place of the inserted "the".)


(20)  Section 5.6

The 2nd paragraph of Section 5.6, on topof page 27, says:

          [...].  Off-plane signaling, on the other hand, sends
|  signaling messages independently from the data packet.  [...]
                                                       ^^
It should say:

          [...].  Off-plane signaling, on the other hand, sends
|  signaling messages independently from the data packets.  [...]
                                                       ^^^

(21)  Section 5.8.1

The last paragraph of Section 5.8.1, on page 30, says:

                                                [...].  There is also a
|  proposed mechanism in [23] for Mobile Network Node to delegate some
   rights to their Mobile Routers, which may be used to allow the Mobile
   Routers to prove their authenticities to Correspondent Entities when
   establishing Route Optimization sessions on behalf of the Mobile
   Network Nodes.

It should say:
a                                                    v
                                                [...].  There is also a
|  proposed mechanism in [23] for Mobile Network Nodes to delegate some
   rights to their Mobile Routers, which may be used to allow the Mobile
   Routers to prove their authenticities to Correspondent Entities when
   establishing Route Optimization sessions on behalf of the Mobile
   Network Nodes.

RFC 4895, "Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)", August 2007

Source of RFC: tsvwg (wit)

Errata ID: 995
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Frank Ellermann
Date Reported: 2007-09-27
Held for Document Update by: Lars Eggert

Section 11 says:

   [1]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
        April 1992.

It should say:

[should be omitted]

Notes:

RFC 4895 contains an unused normative reference to RFC 1321

RFC 4906, "Transport of Layer 2 Frames Over MPLS", June 2007

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rtg

Errata ID: 1035
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-08-17
Held for Document Update by: Stewart Bryant

 

(1)  Abstract -- another erroneous acronym expansion

In the Abstract of RFC 4906,

      "Synchronized Optical Network (SONET)"
               ^^^^
should say:

      "Synchronous Optical Network (SONET)"
               ^^^


(2)  Section 5.2.1 -- missing punctuation

Section 5.2.1 (on page 6 of RFC 4906) says:

   ATM AAL5 Common Part Convergence Sublayer - Service Data Units
|  (CPCS-SDUs) are encapsulated according to [RFC4905] ATM AAL5 CPCS-SDU
   mode.  [...]
                                                      ^
It should say:

   ATM AAL5 Common Part Convergence Sublayer - Service Data Units
|  (CPCS-SDUs) are encapsulated according to [RFC4905], ATM AAL5 CPCS-
   SDU mode.  [...]
                                                      ^^

(3)  [[posted separately.]]


(4)  Section 6.1 -- missing punctuation

On mid-page 11, the explanation for 'Payload Bytes' says:

        A 2-octet value indicating the number of TDM payload octets
|       contained in all packets on the CEM stream from 48 to 1,023
        octets.  [...]
                                                  ^
It should says:

        A 2-octet value indicating the number of TDM payload octets
|       contained in all packets on the CEM stream, from 48 to 1,023
        octets.  [...]
                                                  ^^

(5)  Section 9 -- punctuation

On page 18, the [ANSI.T1.105] entry of Section 9 does not use the
'rational quotation' style requested for RFCs in all related
documents (RFC Author guides).
The RFC says:

   [ANSI.T1.105] American National Standards Institute, "Synchronous
|                Optical Network Formats," ANSI T1.105-1995.
                                        ^^
It should say:

   [ANSI.T1.105] American National Standards Institute, "Synchronous
|                Optical Network Formats", ANSI T1.105-1995.
                                        ^^

RFC 4918, "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", June 2007

Note: This RFC has been updated by RFC 5689

Source of RFC: webdav (app)

Errata ID: 1207
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2008-01-03
Held for Document Update by: Peter Saint-Andre

Section 9.10.1 says:

   A LOCK request to an existing resource will create a lock on the
   resource identified by the Request-URI, provided the resource is not
   already locked with a conflicting lock.  The resource identified in
   the Request-URI becomes the root of the lock.  LOCK method requests
   to create a new lock MUST have an XML request body.  The server MUST
   preserve the information provided by the client in the 'owner'
   element in the LOCK request.  The LOCK request MAY have a Timeout
   header.

It should say:

   A LOCK request to an existing resource will create a lock on the
   resource identified by the Request-URI, provided the resource is not
   already locked with a conflicting lock.  The Request-URI becomes the
   root of the lock.  LOCK method requests
   to create a new lock MUST have an XML request body.  The server MUST
   preserve the information provided by the client in the 'owner'
   element in the LOCK request.  The LOCK request MAY have a Timeout
   header.

Notes:

This is incorrect in that it implies that the "lock root" is a resource, not a URL (<http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=251>). However, should a directly locked resource have multiple bindings, only the one used in the Request-URI of the LOCK request will be the protected from changes of clients not supplying the lock token.

Note that this change makes the description consistent with the definition of the DAV:lockroot XML element in Section 14.12 of [RFC4918].

Errata ID: 1371
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2008-03-14
Held for Document Update by: Peter Saint-Andre
Date Held: 2010-07-07

Section 9.2 says:

    Servers MUST process PROPPATCH instructions in document order (an
    exception to the normal rule that ordering is irrelevant).

It should say:

    Servers MUST process the child elements of the propertyupdate XML
    element in the order they appear in the request body (an exception to
    the normal rule that ordering is irrelevant).

Notes:

There are no "PROPPATCH" instructions in the request document (PROPPATCH is a method name, not an XML element name used in WebDAV).

Note this issue was raised during Gen-art review, but not fixed before publication (http://www.ietf.org/mail-archive/web/gen-art/current/msg01823.html)

Errata ID: 1635
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Zdenek Kouba
Date Reported: 2008-12-13
Held for Document Update by: Alexey Melnikov
Date Held: 2010-07-11

Section 7.4 says:

MOVE an internal member into the collection,

It should say:

MOVE inserting a new internal member into the collection,

Notes:

Edited the corrected text as per discussion between Lisa and Julian.

RFC 4919, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", August 2007

Source of RFC: 6lowpan (int)

Errata ID: 1032
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Held for Document Update by: Brian Haberman

 

(1)  Section 1 -- minor textual flaw

The second paragraph of Section 1, on page 2 of RFC 4919, says:

   This document gives an overview of LoWPANs and describes how they
   benefit from IP and, in particular, IPv6 networking.  It describes
|  LoWPAN requirements with regards to the IP layer and the above, and
   spells out the underlying assumptions of IP for LoWPANs.  [...]

Perhaps, it should better say:

   This document gives an overview of LoWPANs and describes how they
   benefit from IP and, in particular, IPv6 networking.  It describes
|  LoWPAN requirements with regards to the IP layer and the layers
   above, and spells out the underlying assumptions of IP for LoWPANs.
   [...]

or shorter:

   This document gives an overview of LoWPANs and describes how they
   benefit from IP and, in particular, IPv6 networking.  It describes
|  LoWPAN requirements with regards to the IP layer and above, and
   spells out the underlying assumptions of IP for LoWPANs.  [...]


(2)  Section 2 -- minor indentation flaw

Near the top of page 3, Section 2 of RFC 4919 contains the numbered
bullet:

       v
|  7.  Large number of devices expected to be deployed during the
        lifetime of the technology.  This number is expected to dwarf
        the number of deployed personal computers, for example.

This should perhaps better have been formatted as:

       vv
|  7.   Large number of devices expected to be deployed during the
        lifetime of the technology.  This number is expected to dwarf
        the number of deployed personal computers, for example.


(3)  Sections 5 and 8.2 -- misleading reference tag

Apparently during a last minute change before publication, an attempt
has been made to update the references to the most current versions
available, and that has resulted in the misfortunate introduction
into the text (Section 5, first line on page 8, and Section 8.2,
second entry), of the improper and misleading reference tag,
'[6LoWPAN]', in place of an appropriate and mnemonic reference tag
like '[RFC2462bis]' for to-be-RFC4862.


(4)  Section 8.2 -- wrong Informative Reference given

The RFC text in Section 5 (bullet 5. on page 8) makes reference to
the SNMPv3 umbrella document, RFC 3410, using the tag '[RFC3410]'.

But in place of the proper citation of RFC 3410, Section 8.2
contains an unexpected quotation to RFC 3411, tagged '[RFC3411]';
the latter tag does not appear anywhere else in the RFC text.

Therefore, the entry [RFC3411] should have been replaced by an
entry [RFC3410] !

RFC 4928, "Avoiding Equal Cost Multipath Treatment in MPLS Networks", June 2007

Note: This RFC has been updated by RFC 7274

Source of RFC: mpls (rtg)

Errata ID: 1031
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-08-17
Held for Document Update by: Adrian Farrel

Section 3 says:

|  It is REQUIRED, however, that applications depend upon in-order
   packet delivery restrict the first nibble values to 0x0 and 0x1.

It should say:

|  It is REQUIRED, however, that applications depending upon in-order
   packet delivery restrict the first nibble values to 0x0 and 0x1.

Notes:

The original sounds like:
It is REQUIRED that applications depend upon in-order packet delivery
Therefore, the sentence should be clarified and corrected as above.

RFC 4935, "Fibre Channel Fabric Configuration Server MIB", August 2007

Source of RFC: imss (ops)

Errata ID: 1030
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-12
Held for Document Update by: Dan Romascanu

 

(1)  Section 4 -- missing articles

On page 5 of RFC 4935, the last paragraph of Section 4 says:

   This MIB imports some common Textual Conventions from T11-TC-MIB
   [RFC4439] and from T11-FC-NAME-SERVER-MIB [RFC4438].  It also imports
   URLString from NETWORK-SERVICES-MIB [RFC2788].

It should perhaps better say:

|  This MIB imports some common Textual Conventions from the T11-TC-MIB
|  [RFC4439] and from the T11-FC-NAME-SERVER-MIB [RFC4438].  It also
|  imports URLString from the NETWORK-SERVICES-MIB [RFC2788].


(2)  Section 5.3 -- typo

The first paragraph of Section 5.3, on page 6, says:
                                                          v
|  With multiple Fabrics, each Fabric has its own instances of the
   Fabric-related management instrumentation.  [...]

It should say:

|  With multiple Fabrics, each Fabric has its own instance of the
   Fabric-related management instrumentation.  [...]


(3)  Section 5.4 -- unspecific text

Section 5.4, on top of page 7, says:

   This section describes the six MIB groups contained in the MIB
|  module.

It should more specifically say, e.g.:

   This section describes the six MIB groups contained in the MIB
|  module defined in Section 6.
         ^^^^^^^^^^^^^^^^^^^^^

(4)  Section 6


(4a) improper use of term

In the DESCRIPTION clause of MODULE-IDENTITY invocation, in the first
line on page 10, the term "MIB" should be replaced by the standards-
conformant term "MIB module".


(4b) missing article

In the DESCRIPTION clause of the t11FcsFabricDiscoveryTable OBJECT-TYPE
declaration, on top of page 15, the RFC says:

            "This table contains control information for discovery
            of Fabric configuration by switches.

It should better say:
                                                         vvvv
|           "This table contains control information for the discovery
            of Fabric configuration by switches.


(4c) word replication

In the DESCRIPTION clause of the t11FcsFabricDiscoveryStart OBJECT-TYPE
declaration, on mid-page 16, the RFC says:
                                                              vvvvv
                                     [...].  It is recommended that
            whenever an instance of this object is set to 'start',
|           that the desired range be specified at the same time by
            ^^^^^
            setting the corresponding instances of
            t11FcsFabricDiscoveryRangeLow and
            t11FcsFabricDiscoveryRangeHigh.

It should better say:

                                     [...].  It is recommended that
            whenever an instance of this object is set to 'start',
|           the desired range be specified at the same time by
            setting the corresponding instances of
            t11FcsFabricDiscoveryRangeLow and
            t11FcsFabricDiscoveryRangeHigh.


(4d) mis-specification

The DESCRIPTION clause of the t11FcsIeMgmtAddrListIndex OBJECT-TYPE
declaration, at the bottom of page 21, says:

            "The management address list for this Interconnect Element.
|           This object points to an entry in the
            t11FcsMgmtAddrListTable."

This is not true.  Cf. the corresponding description of the
T11FcListIndexPointerOrZero TEXTUAL-CONVENTION and the description
clauses for the t11FcsMgmtAddrListTable pointed to by this object.
In fact, this object points to a 'slice' in the
t11FcsMgmtAddrListTable, namely the set of entries with common
third index equal to the value of the row instance of this object.

Therefore, the RFC should say either:

            "The management address list for this Interconnect Element.
|           This object points to a particular list in the
            t11FcsMgmtAddrListTable."

or:

            "The management address list for this Interconnect Element.
|           This object points to a set of entries in the
            t11FcsMgmtAddrListTable."

This issue recurs.
Similar changes need to be applied to the occurrences of "an entry"
in the DESCRIPTION clauses of the following OBJECT-TYPE declarations:

(4e)
  - t11FcsPortAttachPortNameIndex (at the bottom of page 25),

(4f)
  - t11FcsPlatformNodeNameListIndex (on page 30),  and

(4g)
  - t11FcsPlatformMgmtAddrListIndex (on page 30),


(4h) insufficient / inappropriate specification

The DESCRIPTION clause of the t11FcsPlatformSysMgmtAddr OBJECT-TYPE
declaration (on page 32) says:

|           "A list of management addresses for the platform."

This is misleading; taken literally, it would replicate precisely
the semantics specified for the t11FcsPlatformMgmtAddrListIndex
object (on page 30).  This cannot have been intended.

I strongly suspect that the RFC should say instead:

|           "A list of management addresses for the hosting
|            system of the platform."


(4i) incomplete specification

The DESCRIPTION clause of the t11FcsDiscoveryCompleteNotify
NOTIFICATION-TYPE declaration (near the bottom of page 40) says:

            "This notification is generated by the Fabric
            Configuration Server on the completion of the
            discovery of Fabrics in the range that has
|           t11FcsFabricDiscoveryRangeLow at its low end."

This is incomplete and misleading;
the upper limit of the Fabric index needs to be specified as well.

Thus, the RFC should say:

            "This notification is generated by the Fabric
            Configuration Server on the completion of the
            discovery of Fabrics in the range that has
|           t11FcsFabricDiscoveryRangeLow at its low end and
|           t11FcsFabricDiscoveryRangeHigh at its high end."


IMHO, in particular the items (4a) and (4d) ... (4i) above
deserve being addressed by an appropriate RFC Errata Note.

RFC 4939, "Definitions of Managed Objects for iSNS (Internet Storage Name Service)", July 2007

Source of RFC: ips (tsv)

Errata ID: 1639
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-14
Held for Document Update by: Lars Eggert
Date Held: 2008-12-19

 

(1)  Section 3.3

The text of the second sentence in the second paragraph of
Section 3.3, at the bottom of page 5 of RFC 4939, apparently
is garbled by word omissions.

The RFC says:

   The count of objects registered in each iSNS server instance is shown
|  in the table isnsNumObjectsTable.  The provides a summary of the
|  number Discovery Domain Sets, Discovery Domains, Entities, Portals,
   Portal Groups, iSCSI Nodes, and iFCP FC Nodes and Ports.

It should perhaps say:

   The count of objects registered in each iSNS server instance is shown
|  in the table isnsNumObjectsTable.  This table provides a summary of
              vvv                       ^^^^^^^^
|  the number of Discovery Domain Sets, Discovery Domains, Entities,
   Portals, Portal Groups, iSCSI Nodes, and iFCP FC Nodes and Ports.

Errata ID: 1640
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-14
Held for Document Update by: Lars Eggert
Date Held: 2008-12-19

 

(2c)  isnsControlNodeIscsiNodeName  (page 28)

According to the DESCRIPTION clause in the isnsControlNodeIscsiNodeName
OBJECT-TYPE declaration, the SYNTAX clause should have been specified
with a formal SIZE limitation to 223 for this object as well, as has
been done for all other similar objects in this MIB module.

The RFC says:

      isnsControlNodeIscsiNodeName   OBJECT-TYPE
|         SYNTAX                  SnmpAdminString
          [...]

It should say:

      isnsControlNodeIscsiNodeName   OBJECT-TYPE
|         SYNTAX                  SnmpAdminString (SIZE (0..223))
          [...]

Errata ID: 1641
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-14
Held for Document Update by: Lars Eggert
Date Held: 2008-12-19

 

(2f)  isnsRegEntityNumObjectsTable / isnsRegEntityNumObjectsEntry
      (page 44)

Studying the MIB module, it turns out that the
isnsRegEntityNumObjectsTable is a (dense) augmentation
of the isnsRegEntityTable : a conceptual row in the former
must be instantiated if an only if the corresponding row
(with identical index values) is instantiated in the latter.

Therefore, according to the strong recommendation '(1)' given
in Section 7.8.1 of the first part of STD 58, RFC 2578, the
isnsRegEntityNumObjectsTable should be formally represented
as an augmentation of the isnsRegEntityNumObjectsTable.

This means that, in the isnsRegEntityNumObjectsEntry OBJECT-TYPE
declaration, where the RFC says ...

      isnsRegEntityNumObjectsEntry    OBJECT-TYPE
          [...]
|         INDEX   { isnsServerIndex,
|                   isnsRegEntityIndex }
          ::= { isnsRegEntityNumObjectsTable 1 }

... it should have specified:

      isnsRegEntityNumObjectsEntry    OBJECT-TYPE
          [...]
|         AUGMENTS { isnsRegEntityEntry }
          ::= { isnsRegEntityNumObjectsTable 1 }

Note that the similar relationship between the isnsNumObjectsTable
and the isnsServerTable has correctly reflected in the RFC; the
isnsNumObjectsEntry OBJECT-TYPE declaration already contains the
clause:
          AUGMENTS { isnsServerEntry }


(2g)  isnsRegIscsiNodeAuthMethod  (page 55)

The DESCRIPTION clause of the isnsRegIscsiNodeAuthMethod OBJECT-TYPE
declaration says:

|     "This attribute contains a null-terminated string containing
       UTF-8 text listing the iSCSI authentication methods enabled
       for this iSCSI Node, in order of preference.  The text
       values used to identify iSCSI authentication methods are
       embedded in this string attribute and delineated by a
       comma.  The text values are identical to those found in
       RFC 3720 - iSCSI.  Additional vendor-specific text values
       are also possible."

This is very unusual.  'null-terminated' have been introduced
in some very popular programming languages in place of length
counts for string variables.  (Some people believe this has been
one of the most serious errors ever in the history of programming
languages, because it makes transparent strings (with 0x00 allowed)
impossible, and practice sadly has proven it is a pathway to the
hell of very many security flaws.)
ASN.1 OCTET-STRINGs are counted strings, and the SMIv2 *is* a qualified
subset of ASN.1.  SnmpAdminString is a proper subtype of OCTET-STRING.
Hence, there is no need to include a terminating null into an object
of type SnmpAdminString.
Apparently, this has been recognized throughout this MIB module,
with explicit explanations for all OCTET-STRING (SIZE (0..223))
typed objects.

This single deviation from standard practice is a significant
inconsistency in the MIB module and it might well lead to
interoperability problems if it is not recognized by implementors!


(2h)  object names in the isnsNotificationsInfo branch
      (pages 64/65, used later on as well)

It is common practice, and makes life easier, to have object names
built in a manner that reflects the OID tree: most significant
part(s) left, finer granularity right.

The object names introduced in most parts of the MIB module conform
to that rule.  But unfortunately, the object names in the
isnsNotificationsInfo branch are not built this way.

IMHO, it would have been much more preferable to have the
following name changes applied (unfortunately, it's too late
now for such modification):

   isnsAddressNotificationType   -->  isnsNotificationAddressType

   isnsAddressNotification       -->  isnsNotificationAddress

   isnsTcpPortNotification       -->  isnsNotificationTcpPort

   isnsUdpPortNotification       -->  isnsNotificationUdpPort

RFC 4940, "IANA Considerations for OSPF", July 2007

Source of RFC: ospf (rtg)

Errata ID: 1025
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-08-15
Held for Document Update by: Stewart Bryant
Date Held: 2012-10-26

Section 5.7 says:

          vvvvvvv                     v
|  OSPFv2 Options Registry (Section 2.1)

   Value Description Reference
   ----- ----------- ---------
   0x01  B-bit       [RFC2328]
|  0x02  W-bit       [RFC2328]
   0x04  V-bit       [RFC2328]
   0x08  W-bit       [RFC1584]
   0x10  Nt-bit      [RFC3101]

It should say:

          vvvvvvvvvvvvvvvvv                     vvv
|  OSPFv2 Router Properties Registry (Section 2.4.2)

   Value Description Reference
   ----- ----------- ---------
   0x01  B-bit       [RFC2328]
|  0x02  E-bit       [RFC2328]
   0x04  V-bit       [RFC2328]
   0x08  W-bit       [RFC1584]
   0x10  Nt-bit      [RFC3101]

Notes:

Apparently, the headline has been erroneously copied from Section 5.1
without performing the necessary edits.
The duplicate occurrence of "W-Bit" in the table is striking -
Section A.4.2 of RFC 2328 normatively gives the correct name of bit
0x02, and the Appendices of RFC 3101 and RFC 1584 correctly replicate
the field names as stated in RFC 2328 (and its predecessors).

RFC 4941, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", September 2007

Note: This RFC has been obsoleted by RFC 8981

Source of RFC: ipv6 (int)

Errata ID: 3239
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-10-12
Held for Document Update by: Brian Haberman
Date Held: 2012-06-01

Section 3 says:

On page 9, the 2nd numbered bullet in Section 3 says:

   2.  [...]
       Deprecated address can continue to be used for already
       established connections, but are not used to initiate new
       connections.  [...]

It should say:

   2.  [...]
       Deprecated addresses can continue to be used for already
       established connections, but are not used to initiate new
       connections.  [...]

Errata ID: 4404
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Jewgenij Bytschkow
Date Reported: 2015-06-29
Held for Document Update by: Brian Haberman
Date Held: 2015-06-30

Section 2.3 says:

The way PPP is used today, however, PPP servers
typically unilaterally inform the client what address they are to use
(i.e., the client doesn't generate one on its own).  This practice,
if continued in IPv6, would avoid the concerns that are the focus of
this document.

It should say:

In contrast to LAN clients, the way PPP is used today, however, does
not allow the client to freely and unilaterally change its own
interface identifier. PPP servers also do not unilaterally inform the
client what 128-bit address to use. In the same manner as for LAN
connected clients (without PPP), a PPP client generates its
global-scope IPv6 address from the Interface-Identifier part and the
Prefix part. The client obtains a prefix from the PPP server in the
same way as LAN clients do, i.e. via Neighbor Discovery Protocol.
However, an interface identifier of a PPP client MUST be negotiated
with the PPP server via IPv6CP protocol (Interface-Identifier option).
Only then, after IPv6CP was successfully negotiated between the PPP
client and the PPP server, the PPP client can generate and assign its
individual global IPv6 address compounded from the negotiated
interface identifier and the obtained prefix.
In order to change the old negotiated interface identifier later in the
same PPP session, the client MUST initiate a new IPv6CP negotiation
with the PPP server, proposing a new client's interface identifier.

Notes:

Such an extensive additional explanation of PPP specifics regarding changing of interface identifier on PPP clients is very important for both PPP servers manufacturers and PPP slients manufacturers, in order to define a method for legal changing of interface IDs on PPP clients (according to the recommendations of this RFC 4941) and to correctly support of a changed client’s interface ID on the PPP Server (for correct IPv6 routes in the routing table et al.).
Failure to comply with these PPP specifics and requirements can lead to misinterpretation, fault implementations, and then to critical PPP sessions issues in real operation!

Errata ID: 3242
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-10-12
Held for Document Update by: Brian Haberman
Date Held: 2012-06-01

Section 3.5 says:

   The frequency at which temporary addresses changes depends on [...]

It should say:

   The frequency at which temporary addresses change depends on [...]

Errata ID: 3243
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-10-12
Held for Document Update by: Brian Haberman
Date Held: 2012-06-01

Section 3.6 says:

                                       [...].  Note that the pre-prefix
   setting can be applied at any granularity, and not necessarily on a
   per-subnet basis.

It should say:

                                       [...].  Note that the per-prefix
   setting can be applied at any granularity, and not necessarily on a
   per-subnet basis.

RFC 4952, "Overview and Framework for Internationalized Email", July 2007

Note: This RFC has been obsoleted by RFC 6530

Note: This RFC has been updated by RFC 5336

Source of RFC: eai (app)

Errata ID: 1507
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-09-15
Held for Document Update by: Alexey Melnikov

Section 1 (and 1.*) says:

                                                 [...].  However, it
   does not permit the use of email addresses that include non-ASCII
   characters.  Without the extensions defined here, or some equivalent
   set, the only way to incorporate non-ASCII characters in any part of
   email addresses is to use RFC 2047 coding to embed them in what RFC
   2822 [RFC2822] calls the "display name" (known as a "name phrase" or
|  by other terms elsewhere) of the relevant headers.  Information coded
   into the display name is invisible in the message envelope and, for
   many purposes, is not part of the address at all.

It should say:

                                                 [...].  However, it
   does not permit the use of email addresses that include non-ASCII
   characters.  Without the extensions defined here, or some equivalent
   set, the only way to incorporate non-ASCII characters in any part of
   email addresses is to use RFC 2047 coding to embed them in what RFC
   2822 [RFC2822] calls the "display name" (known as a "name phrase" or
|  by other terms elsewhere) of the relevant header fields.
   Information coded into the display name is invisible in the message
   envelope and, for many purposes, is not part of the address at all.

Notes:

Conformance to terminology established in the IETF requires
making the precise distinction between a header and the
header fields it is comprised of.

This same issue recurs in the first paragraph of Section 1.1
and in the 3rd line of the last paragraph of Section 1.2.

RFC 4954, "SMTP Service Extension for Authentication", July 2007

Note: This RFC has been updated by RFC 5248

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 1019
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-08-25
Held for Document Update by: Alexey Melnikov

Section 1 says:

|  When compared to RFC 2554, this document deprecates use of the 538
   response code, adds a new Enhanced Status Code, adds a requirement to
|  support SASLprep profile for preparing authorization identities,
|  recommends use of RFC 3848 transmission types in the Received trace
|  header field, and clarifies interaction with SMTP PIPELINING
   [PIPELINING] extension.

It should say:

|  When compared to RFC 2554, this document deprecates the use of the
   538 response code, adds a new Enhanced Status Code, adds a
|  requirement to support the SASLprep profile for preparing
|  authorization identities, recommends the use of RFC 3848 transmission
|  types in the Received trace header field, and clarifies the
|  interaction with the SMTP PIPELINING [PIPELINING] extension.

Notes:

missing articles

RFC 4957, "Link-Layer Event Notifications for Detecting Network Attachments", August 2007

Source of RFC: dna (int)

Errata ID: 1052
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-08-20
Held for Document Update by: Brian Haberman

 

(1)  Section 3

Within Section 3, the second paragraph on page 6 says:

                               [...].  Therefore, there exist cases
|  where IP-layer configuration may have to change even without the IP
   layer receiving a link up notification.  [...]

It should perhaps better say, adding the article:

                               [...].  Therefore, there exist cases
|  where the IP-layer configuration may have to change even without the
   IP layer receiving a link up notification.  [...]

The last paragraph of Section 3 says:
                                                     vvvvvv
|  The link-layer process leading to a link up event depend on the link
   technology.  [...]

It should better say:
                                                     vvvvvvv
|  The link-layer process leading to a link up event depends on the link
   technology.  [...]


(2)  Section 4

In the first paragraph of Section 4 (on page 13), the RFC says:

                                      [...].  In addition, wireless
   networks such as 802.11 are susceptible to an attack called the "Evil
   Twin" attack where an attacker sets up an Access Point with the same
|  SSID as a legitimate one and gets the use to connect to the fake
   access point instead of the real one.  [...]
                                         ^^^
The tagged word 'use' apparently should be 'user' :

                                      [...].  In addition, wireless
   networks such as 802.11 are susceptible to an attack called the "Evil
   Twin" attack where an attacker sets up an Access Point with the same
|  SSID as a legitimate one and gets the user to connect to the fake
   access point instead of the real one.  [...]
                                         ^^^^

(3)  Section 7.1

- In Section 7.1 (on page 14), the first entry is apparently
  truncated:

                                                          vvvv
|  [CDMA2K]        "cdma2000 Wireless IP Network Standard",  ,
                   December 2000.

RFC 4960, "Stream Control Transmission Protocol", September 2007

Note: This RFC has been obsoleted by RFC 9260

Note: This RFC has been updated by RFC 6096, RFC 6335, RFC 7053, RFC 8899

Source of RFC: tsvwg (wit)

Errata ID: 3291
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eric W. Biederman
Date Reported: 2012-07-21
Held for Document Update by: Martin Stiemerling

Section 3.3.2 says:

          Variable Parameters                  Status     Type Value
          -------------------------------------------------------------
          IPv4 Address (Note 1)               Optional    5 IPv6 Address
          (Note 1)               Optional    6 Cookie Preservative
          Optional    9 Reserved for ECN Capable (Note 2)   Optional
          32768 (0x8000) Host Name Address (Note 3)          Optional
          11 Supported Address Types (Note 4)    Optional    12

It should say:

          Variable Parameters                  Status     Type Value
          -------------------------------------------------------------
          IPv4 Address (Note 1)               Optional    5 
          IPv6 Address (Note 1)               Optional    6
          Cookie Preservative                 Optional    9
          Reserved for ECN Capable (Note 2)   Optional    32768 (0x8000)
          Host Name Address (Note 3)          Optional    11
          Supported Address Types (Note 4)    Optional    12

Notes:

Something placed the line ending in the wrong place making the table nearly
unreadable.

Errata ID: 4071
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Federico Zuccardi Merli
Date Reported: 2014-08-06
Held for Document Update by: Martin Stiemerling
Date Held: 2015-11-02

Section 6.1 says:

      However, regardless of the value of rwnd (including if it is 0),
      the data sender can always have one DATA chunk in flight to the
      receiver if allowed by cwnd (see rule B below).  This rule allows
      the sender to probe for a change in rwnd that the sender missed
      due to the SACK having been lost in transit from the data receiver
      to the data sender.

It should say:

[empty]

Notes:

The whole paragraph is a one-to-one repetition of the final part of first paragraph of Rule A).
The position of the paragraph does not affect meaning, but the repetition hinders readability.

Errata ID: 5958
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Földvári Zoltán
Date Reported: 2020-01-13
Held for Document Update by: Martin Duke
Date Held: 2020-04-27

Section 10.1 says:

Notes:

From A) to I) there are "Mandatory attributes" and "Optional attributes" section for each primitive.
"Optional attributes" section is missing from J) Request HeartBeat.
"Optional attributes" section is missing from K) Get SRTT Report.
"Optional attributes" section is missing from L) Set Failure Threshold.
"Mandatory attributes" label is missing from N) Receive Unsent Message.
"Mandatory attributes" label is missing from o Receive Unacknowledged Message.
"Mandatory attributes" label is missing from P) Destroy SCTP Instance.

RFC 4968, "Analysis of IPv6 Link Models for 802.16 Based Networks", August 2007

Source of RFC: 16ng (int)

Errata ID: 1015
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-08-17
Held for Document Update by: Jari Arkko

 

(1)  Section 1 -- mis-expansion of acronym

At the bottom of page 2, Section 1 of RFC 4968 says:

                   [...].  Another method is to treat the IEEE 802.16
|  MAC (Message Authentication Code) transport connections between an MS
   (Mobile Station) and BS (Base Station) as point-to-point IP links so
   that the IP protocols (e.g., ARP (Address Resolution Protocol), IPv6
   Neighbor Discovery) can be run without any problems.

It should say:

                   [...].  Another method is to treat the IEEE 802.16
|  MAC (Media Access Control) transport connections between an MS
   (Mobile Station) and BS (Base Station) as point-to-point IP links so
   that the IP protocols (e.g., ARP (Address Resolution Protocol), IPv6
   Neighbor Discovery) can be run without any problems.


(2)  Section 3.1 -- typo/grammar

The first paragraph of Section 3.1 says, at the bottom of page 3:
             v
                                  [...].  The following figures
|  illustrates a high-level view of this link model wherein [...]

It should say:

                                  [...].  The following figures
|  illustrate a high-level view of this link model wherein [...]


(3)  missing articles

(3a)
The RFC text regularly uses "to an AR", "via the AR", etc.
It also should not omit the article 'the' in "of the AR"
and in other context.

For instance:

- Section 3.1, 1st paragraph (page 5), 7th line:
    "support of AR"           -->   "support of the AR"

- Section 3.1.4.2 (page 6), 2nd line:
    "backend process in AR"   -->   "backend process in the AR"

- Section 3.1.4.4 (page 6), 3rd line:
    "the MS and AR"           -->   "the MS and the AR"

(3b)
Similar inconsistent use/non-use of the article occurs for "BS".
For instance,

- Section 3.3.4.6 (page 11), 2nd line:
    "implemented in BS"       -->   "implemented in the BS"

- Section 4, first paragraph on page 12, last line:
    "sends a single RA to BS" -->   "sends a single RA to the BS"

- Section 4, last paragraph (page 12), 2nd line:
    "sent by the AR to BS"    -->   "sent by the AR to the BS"

(3c)
Finally, I found inconsistent use of the article for "Ethernet CS"
in the first paragraph of Section 7, on page 13.  The RFC says:

   Ethernet-Like Link models would be used when the deployment requires
|  the use of Ethernet CS, as this is the only model being proposed for
   the Ethernet CS and running IPv6 over Ethernet is well understood.

It should say:

   Ethernet-Like Link models would be used when the deployment requires
|  the use of the Ethernet CS, as this is the only model being proposed
   for the Ethernet CS and running IPv6 over Ethernet is well
   understood.


(4)  grammar / word omission

On page 9, Section 3.2.3.6 contains the bullet:

|  1.  Each MS is assigned a separate VLAN when IEEE 802.1X [12] or each
       MS must have an L2 tunnel to the AR to aggregate all the
|      connections to the MS and present these set of connections as an
       interface to the IPv6 layer.

This sentence does not parse.  Perhaps, it should say:

|  1.  Each MS is assigned a separate VLAN when IEEE 802.1X [12] is used
       or each MS must have an L2 tunnel to the AR to aggregate all the
|      connections to the MS and present this set of connections as an
       interface to the IPv6 layer.


(5)  extraneous word

The last sentence of Section 3.3.4.2 (on page 11) says:

   Nevertheless, in case of bridging, direct inter-MSs communication may
|  not be not allowed due to restrictions from the service providers.
   ^^^^^^^^^^

It should say:

   Nevertheless, in case of bridging, direct inter-MSs communication may
|  not be allowed due to restrictions from the service providers.
   ^^^^^^


(6)  References

In Section 11.2, in the entries [4] and [5], a space character should
have been inserted after "Part 16:" .
Do these two documents really have the same title ?

RFC 4975, "The Message Session Relay Protocol (MSRP)", September 2007

Note: This RFC has been updated by RFC 7977, RFC 8591, RFC 8873, RFC 8996

Source of RFC: simple (rai)

Errata ID: 1281
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-14
Held for Document Update by: Robert Sparks

Throughout the document, when it says:

<headers>

<header>

<ext-header>

It should say:

<hfields>

<hfield>

<ext-hfield>

Notes:

Note on Terminology:
To help avoid the terminological issues observed in the companion
document, RFC 4976, and reduce the likelihood of similar issues in
future derived work, it would perhaps have been useful to subtly
change the ABNF in Section 9 (and all related references in the prose),
replacing three rule names:
<headers> --> <hfields>
<header> --> <hfield>
<ext-header> --> <ext-hfield>

Errata ID: 1282
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-14
Held for Document Update by: Robert Sparks

Section 9, p.38 says:

   hname = ALPHA *token

It should say:

   hname = ALPHA [token]

(or use:
   hname = ALPHA *1token
)

Notes:

This resolves a potential parsing ambiguity,
and should also improve the readability.

Errata ID: 1286
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-14
Held for Document Update by: Robert Sparks

Section 15.5.1,p.57 says:

   Contact:  Ben Campbell (ben@estacado.net).
   Author/Change Controller:  This is a permanent registration request.
      Change control does not apply.

It should say:

   Contact:  Ben Campbell (ben@estacado.net).
|  Author/Change Controller:  IESG.

Notes:

(This only is a proposal.)

Rationale: Congratulations! The registrant seems to have achieved
immortality, and/or his email address guaranteed to be perpetual. :-)

More seriously: cf. Section 3 of RFC 2434.

Errata ID: 4177
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Archie Cobbs
Date Reported: 2014-11-13
Held for Document Update by: Orie Steele
Date Held: 2024-04-01

Section 7.1 says:

   line, and a flag character.  If a body is present, the end-line MUST
   be preceded by a CRLF that is not part of the body.  If the chunk
   represents the data that forms the end of the complete message, the
   flag value MUST be a "$".  If the sender is aborting an incomplete
   message, and intends to send no further chunks in that message, the
   flag MUST be a "#".  Otherwise, the flag MUST be a "+".

   If the request contains a body, the sender MUST ensure that the end-
   line (seven hyphens, the transaction identifier, and a continuation
   flag) is not present in the body.  If the end-line is present in the

It should say:

   line, and a flag character.  If a body is present, the end-line MUST
   be preceded by a CRLF that is not part of the body.  If the chunk
   represents the data that forms the end of the complete message, the
   flag value MUST be a "$".  If the sender is aborting an incomplete
   message, and intends to send no further chunks in that message, the
   flag MUST be a "#".  Otherwise, the flag MUST be a "+".

   If the request contains a body, the sender MUST ensure that the end-
   line (seven hyphens, the transaction identifier, and a continuation
   flag) is not present in the body.  A receiver detecting an end-line
   present in the body preceded by a non-empty sequence other than CRLF
   SHOULD terminate the session. If the end-line is present in the

Notes:

The way the text is written leaves unspecified how a receiver should handle the situation where it encounters an end-line within the body that's preceded by something OTHER than CRLF.

Obviously, this indicates the sender is not complying with this RFC, but what should the receiver do?

Should the receiver terminate the connection? Or just proceed giving no special interpretation to the end-line, which would actually work just fine?

The suggested change reflects the first choice. If the second choice were made, the change could be:

If the request contains a body, the sender MUST ensure that the
end-line (seven hyphens, the transaction identifier, and a continuation
flag) neither appears at the beginning of the body nor is not present
in the body preceded by CRLF. An end-line MAY appear in the body if
preceded in the body by any non-empty sequence other than CRLF.

This would force the interpretation that an end-line not preceded by CRLF has no special significance.

Errata ID: 1280
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-14
Held for Document Update by: Robert Sparks

Section 7.1.1,p.19 says:

<<<  at the end of the (indented) second paragraph  >>
 
        [...]  For example, an endpoint could concatenate an instance
      identifier such as a MAC address, its idea of the number of
      seconds since the epoch, a process ID, and a monotonically
      increasing 16-bit integer, all base-64 encoded.  Alternately, an
      endpoint without an on-board clock could simply use a 64-bit
      random number.

It should say:

 
        [...]  For example, an endpoint could concatenate an instance
      identifier such as a MAC address, its idea of the number of
      seconds since the epoch, a process ID, and a monotonically
      increasing 16-bit integer, all base-64 encoded.  Alternately, an   
      endpoint without an on-board clock could simply use a 64-bit
|     random number and base-64 encode it.

Notes:

Clarification; otherwise, "Alternately" could be grossly misunderstood
to indicate a direct alternative for the header field value.

Errata ID: 1284
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-14
Held for Document Update by: Robert Sparks

Section 13, p.48 says:

           ... "message/ cpim"  ...

It should say:

           ... "message/cpim"  ...

Notes:

Within quoted text literals, white space might be considered
significant; thus, to avoid any potential ambiguity .... :-)

Errata ID: 1285
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-14
Held for Document Update by: Robert Sparks

Section 15.2, p.55 says:

|  This specification establishes the header field-Field sub-registry
   under MSRP Parameters.  New parameters in this sub-registry must be
   published in an RFC (either as an IETF submission or RFC Editor
   submission).  [...]

It should say:

|  This specification establishes the Header Field sub-registry under
   MSRP Parameters.  New parameters in this sub-registry must be
   published in an RFC (either as an IETF submission or RFC Editor
   submission).  [...]

RFC 4976, "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", September 2007

Note: This RFC has been updated by RFC 7977, RFC 8553, RFC 8996

Source of RFC: simple (rai)

Errata ID: 1269
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-14
Held for Document Update by: Robert Sparks

Throughout the document, when it says:

a)    Header

b)    Headers

c)    header

d)    headers

It should say:

a)    Header Field

b)    Header Fields

c)    header field

d)    header fields

Notes:

In some parts of the text, RFC 4976 makes confusing sluggish use of
established IETF standard terminology.

Since RFC 2045 ff., and reinforced by many more RFCs, the distinction
between "header" and the elements of a header, "header fields" should be
clear to all. I once again recommend BCP 90, RFC 3864, and in particular
Section 3.1.1 of RFC 4249 for clarification of this terminological issue.

Hint:
Additionally, the RFC sometimes is not precise enough in distinguishing
the parts of a header field from the whole, e.g. saying "header" where
it should say "header field value" ; this issue will be mentioned below
as case e) and additionally be addressed in specific errata reports.

Note: Remarkably, other parts of RFC 4976, and the whole companion
document, RFC 4975, do not suffer from this deficiency.

The following parts of RFC 4976 suffer from the four variants
of this abuse of language shown in the OLD / NEW boxes above:

a) headlines of Sections 4.2, 4.3, 4.4, and 4.5

b) headline of Sections 4.6 and 10.2

c) - text of section 4.2 (5 instances),
- text of section 4.3 (1 instance),
- text of section 4.4 (1 instance),
- text of section 4.5 (1 instance),
- text of section 4.6 (8 instances),
- text of section 5.1 (18 instances),
- text of section 6.3 (6 instances),
- text of section 6.4.1 (5 instances),
- text of section 6.4.2 -- see extra report,
- text of section 6.4.3 (5 instances),
- text of section 9.1 (6 instances),
- text of section 9.4 (2 instances)

d) - text of section 4.2 (1 instance),
- text of section 9.1 (2 instances)

e) - text of section 6.4.1 (2 instances)

Errata ID: 1273
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-14
Held for Document Update by: Robert Sparks

Section 5.2 - pg.17 says:

<< 3rd message shown >>

    MSRP m4nbvx 200 OK
    To-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
             msrps://alice.example.com:9892/98cjs;tcp
    From-Path: msrps://extra.example.com;tcp
|   Use-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
|             msrps://extra.example.com:9000/mywdEe1233;tcp
    Authentication-Info:  [...]

<<  4th message shown >>
    MSRP m3nbvx 200 OK
    To-Path: msrps://alice.example.com:9892/98cjs;tcp
    From-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
               msrps://extra.example.com;tcp
|   Use-Path: msrps://extra.example.com:9000/mywdEe1233;tcp \
              msrps://extra.example.com:9000/mywdEe1233;tcp
    Authentication-Info: [...]

It should say:

<< 3rd message >>
    MSRP m4nbvx 200 OK
    To-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
             msrps://alice.example.com:9892/98cjs;tcp
    From-Path: msrps://extra.example.com;tcp
|   Use-Path: msrps://extra.example.com:9000/mywdEe1233;tcp
    Authentication-Info: [...]

<<  4th message >>
    MSRP m3nbvx 200 OK
    To-Path: msrps://alice.example.com:9892/98cjs;tcp
    From-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
               msrps://extra.example.com;tcp
|   Use-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
              msrps://extra.example.com:9000/mywdEe1233;tcp
    Authentication-Info: [...]

Notes:

In both messages, the "Use-Path:" header fields are garbled.

This should draw the attention to the lack of specification in the RFC
(cf. extra report) for the Relay behavior w.r.t. Use-Path in repsonses.

From descriptive text in the RFC it becomes clear that the 3rd message
above should contain one URI in the Use-Path header field, and that the
second one shown there in fact needs to be added by the relay into the
4th message (final response to the client).
The simple URI repetition shown in the 4th message doen not make sense
at all.

Errata ID: 1274
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-14
Held for Document Update by: Robert Sparks

Section 6.4.1, pa.2 says:

   If the Failure-Report header is "yes", then the relay MUST run a
   timer to detect if transmission to the next hop fails.  [...]

It should say:

   If the Failure-Report header field value is "yes", then the relay
   MUST run a timer to detect if transmission to the next hop fails.
   [...]

Notes:

Cf. GLOBAL errata report on terminology.

Errata ID: 1275
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-14
Held for Document Update by: Robert Sparks

Section 6.4.1,p.22 says:

                          [...].  In this case, the relay SHOULD discard
|  the message, and if the Failure-Report header is set to "yes", the
   relay SHOULD generate a failure report.

It should say:

                          [...].  In this case, the relay SHOULD discard
|  the message, and if the Failure-Report header field value is set to 
   "yes", the relay SHOULD generate a failure report.

Notes:

The offending text is at the end of the last paragraph of Section 6.4.1.
For rationale, cf. the GLOBAL errata report on terminology.

Errata ID: 1277
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-14
Held for Document Update by: Robert Sparks

Section 7, page 23 says:

   WWW-Authenticate    = "WWW-Authenticate:" SP "Digest" SP digest-param
                         *("," SP digest-param)

   digest-param        = ( realm / nonce / [ opaque ] / [ stale ] / [
                         algorithm ] / qop-options  / [auth-param] )

It should say:

  WWW-Authenticate    = "WWW-Authenticate:" SP "Digest" SP digest-param
                         *("," SP digest-param)
|                       ; realm, nonce, and qop digest-params are required

| digest-param        = ( realm / nonce / opaque / stale / algorithm
|                         / qop-options  / auth-param )

Notes:

a) The prose of the RFC indicates that the restriction stated in the
added ABNF comment indeed should hold. See also note below.

b) The <digest-param> syntax as stated in the RFC makes no sense;
allowing optional productions in the ABNF alternative would allow
empty <digest-param>s , i.e. immediately adjacent commas in the
WWW-Authenticate header field value; I suspect that the square
brackets might have been intended to indicate what I suggest to
express in the ABNF comment a).

To express the full set of requirements for WWW-Authenticate in pure,
formal ABNF would perhaps make it much less readable.

These issues are replicated for <credentials> and <digest-response>
-- this is addressed in a separate report.

Errata ID: 1278
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-14
Held for Document Update by: Robert Sparks

Section 7, p.23/24 says:

   credentials         = "Digest" SP digest-response
                         *( "," SP digest-response)

   digest-response     = ( username / realm / nonce / response / [
                         algorithm ] / cnonce / [opaque] / message-qop /
                         [nonce-count]  / [auth-param] )

It should say:

   credentials         = "Digest" SP digest-response
                         *( "," SP digest-response)
|                        ; mandatory digest-response items are:
|                        ;  username, realm, nonce, response, cnonce,
|                        ;  and message-qop

|  digest-response     = ( username / realm / nonce / response 
|                          / algorithm / cnonce / opaque / message-qop 
|                          / nonce-count / auth-param )

Notes:

For rationale, see the related report on <WWW-Authenticate> and
<digest-param> ABNF.

Errata ID: 1270
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-14
Held for Document Update by: Robert Sparks

Throughout the document, when it says:

 ... in Section 5.1

It should say:

 ... in Section 5.1 and 9.1

Notes:

The text in Sections 4.3 through 4.5 refers to Section 5.1
for the details of HTTP Digest authentication.
Most of these in fact are in Section 9.1; thus the reader
should be directly advised to consult Section 9.1 as well.

It might even be better to only point to 9.1 in these 3 instances.

Note: The pointer to Section 5.1 given in Section 4.2 seems to be
appropriate.

Errata ID: 1271
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-14
Held for Document Update by: Robert Sparks

Section 4.2, 1st par says:

   The Use-Path header is a list of URIs provided by an MSRP relay in
   response to a successful AUTH request.  [...]

It should say:

   The Use-Path header field contains a list of URIs provided by an MSRP
   relay in response to a successful AUTH request.  [...]

Notes:

a) terminology -- cf. GLOBAL errata reoprt
b) misleading verb: "is" --> "contains"

Errata ID: 1279
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-14
Held for Document Update by: Robert Sparks

Section App. A,p.35 says:

                    [...].  When implementing something like this,
|  implementors should be careful not to use a scheme like EBE that
|  would allows portions of encrypted tokens to be cut and pasted into
   other URIs.

It should say:

                    [...].  When implementing something like this,
   implementors should be careful not to use a scheme like EBE (..???..)
   that would allow portions of encrypted tokens to be cut and pasted
   into other URIs.

Notes:

a) Newly introduced abbreviation -- never explained ==> need expansion
Please supply!
b) Grammar: s/allows/allow/

Errata ID: 2695
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rockson Li
Date Reported: 2011-01-30
Held for Document Update by: Robert Sparks

Section 6.4.3 says:

The relay sends the request over
   the best connection that corresponds to the next URI in the To-Path
   header. 

It should say:

The relay sends the response over
   the best connection that corresponds to the next URI in the To-Path
   header. 

Notes:

This is section is talking about handling response.
typo "request" should be "response"

Errata ID: 2993
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Iñaki Baz Castillo
Date Reported: 2011-10-12
Held for Document Update by: Robert Sparks

Section 3 says:

   Alice              a.example.org       b.example.net             Bob
     |                     |                    |                     |
     |--- SEND 1-3 ------->|                    |                     |
     |<-- 200 OK ----------|                    |  (slow link)        |
     |--- SEND 4-7 ------->|--- SEND 1-5 ------>|                     |
     |<-- 200 OK ----------|<-- 200 OK ---------|--- SEND 1-3 ------->|
     |--- SEND 8-10 ------>|--- SEND 6-10 ----->|                ....>|
     |<-- 200 OK ----------|<-- 200 OK ---------|                  ..>|
     |                     |                    |<-- 200 OK ----------|
     |                     |                    |<-- REPORT 1-3 ------|
     |                     |<-- REPORT 1-3 -----|--- SEND 4-7 ------->|
     |<-- REPORT 1-3 ------|                    |                 ...>|
     |                     |                    |<-- REPORT 4-7 ----->|
     |                     |<-- REPORT 4-7 -----|--- SEND 8-10 ------>|
     |<-- REPORT 4-7 ------|                    |                  ..>|
     |                     |                    |<-- 200 OK ----------|
     |                     |<-- REPORT done-----|<-- REPORT done -----|
     |<-- REPORT done -----|                    |                     |
     |                     |                    |                     |

It should say:

   Alice              a.example.org       b.example.net             Bob
     |                     |                    |                     |
     |--- SEND 1-3 ------->|                    |                     |
     |<-- 200 OK ----------|                    |  (slow link)        |
     |--- SEND 4-7 ------->|--- SEND 1-5 ------>|                     |
     |<-- 200 OK ----------|<-- 200 OK ---------|--- SEND 1-3 ------->|
     |--- SEND 8-10 ------>|--- SEND 6-10 ----->|                ....>|
     |<-- 200 OK ----------|<-- 200 OK ---------|                  ..>|
     |                     |                    |<-- 200 OK ----------|
     |                     |                    |<-- REPORT 1-3 ------|
     |                     |<-- REPORT 1-3 -----|--- SEND 4-7 ------->|
     |<-- REPORT 1-3 ------|                    |                 ...>|
     |                     |                    |<-- 200 OK ----------|
     |                     |                    |<-- REPORT 4-7 ----->|
     |                     |<-- REPORT 4-7 -----|--- SEND 8-10 ------>|
     |<-- REPORT 4-7 ------|                    |                  ..>|
     |                     |                    |<-- 200 OK ----------|
     |                     |<-- REPORT done-----|<-- REPORT done -----|
     |<-- REPORT done -----|                    |                     |
     |                     |                    |                     |

Notes:

The flow in page 10 lacks the mandatory 200 OK for the SEND 4-7 received by Bob.

RFC 4978, "The IMAP COMPRESS Extension", August 2007

Source of RFC: lemonade (app)

Errata ID: 1014
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-18
Held for Document Update by: Alexey Melnikov
Date Held: 2009-07-06

 

RFC 4978 vs. RFC 5032 -- mismatch in UPDATES clauses

Within two weeks, two RFCs have been published specifying amendments
to the IMAP protocol:

  o  RFC 4978  -- COMPRESS

  o  RFC 5032  -- WITHIN Search

Both IMAP extensions are similarly structured and arguably RFC 4978
modifies IMAP behaviour specified in RFC 3501 (and other IMAP
extension specifications: IMAP TLS and SASL) to a much greater extent
than RFC 5032 does.

Nevertheless and surprisingly, only RFC 5032 has the line,
  Updates: 3501
in its document header and hence in its RFC index metadata.

This is apparently inconsistent.

An update to the RFC metadata incoporating the relation
     "RFC 4978 updates RFC 3501"
would be welcome as well.

RFC 4982, "Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs)", July 2007

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: int

Errata ID: 1013
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-08-20
Held for Document Update by: Brian Haberman

 

(1)  Section 3 -- typo ??

In the second bullet on mid-page 3, Section 3 twice talks about
"Care-off Adress".  That is potentially misleading.
The RFC should use the proper term from Mobile IP, "Care-of Adress".


(2)  Section 4.1

(2a)  underspecification; needs clarification

In the 3rd paragraph on page 5, Section 4.1 says (on mid-page 5):

                                                [...].  So for instance,
   the Sec value 000 would mean that the hash function used is SHA-1 and
|  the 0 bits of hash2 (as defined in RFC 3972) must be 0.  Sec value of
|  001 could be that the hash function used is SHA-1 and the 16 bits of
   hash2 (as defined in RFC 3972) must be zero.  [...]

It should perhaps better say, to avoid possible misinterpretation:

                                                [...].  So for instance,
   the Sec value 000 would mean that the hash function used is SHA-1 and
|  the 0 bits of hash2 (as defined in RFC 3972) must be 0.  The Sec value
|  001 could indicate that the hash function used is SHA-1 and the 16
|  leftmost bits of hash2 (as defined in RFC 3972) must be zero.  [...]

Note: "leftmost" is the essential clarification; the other changes
      attempt further subordinate improvements of the language.

(2b)  wording/clarification

In the middle of the last paragraph on page 5, Section 4.1 talks
about                     "a last resource option" .
Shouldn't that have been  "a last resort option"   ?

RFC 4985, "Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name", August 2007

Source of RFC: pkix (sec)

Errata ID: 2396
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-29

Section 5 says:

The second paragraph of Section 5 (on page 6 of RFC 4985) says:

   When X.509 certificates enhanced with the name form specified in this
   standard is used to enhance authentication of service discovery based
   on an SRV RR query to a DNS server, all security considerations of
   RFC 2782 applies.

It should say:

   When X.509 certificates enhanced with the name form specified in this
|  standard are used to enhance authentication of service discovery
   based on an SRV RR query to a DNS server, all security considerations
   of RFC 2782 applies.

Errata ID: 2397
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-29

Section 2 says:

Within Section 2, the 3rd-to-last paragraph on page 3 says:

   Even though this name form is based on the service resource record
   (SRV RR) definition in RFC 2782 [N3] and may be used to enhance
   subsequent authentication of DNS-based service discovery, this
   standard does not define any new conditions or requirements regarding
|  use of SRV RR for service discovery or where and when such use is
   appropriate.
              ^^

It should say:

It should say:

   Even though this name form is based on the service resource record
   (SRV RR) definition in RFC 2782 [N3] and may be used to enhance
   subsequent authentication of DNS-based service discovery, this
   standard does not define any new conditions or requirements regarding
|  the use of SRV RRs for service discovery or where and when such use
   ^^^^           ^^^
   is appropriate.

Errata ID: 2399
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-29

Section 1 says:

The last paragraph of Section 1, on page 2 of RFC 4985, says:

   v
|  Current dNSName GeneralName Subject Alternative name form only
   provides for DNS host names to be expressed in "preferred name
   syntax", as specified by RFC 1034 [N4].  [...]

It should say:

It should say:

   vvvvv
|  The current dNSName GeneralName Subject Alternative name form only
   provides for DNS host names to be expressed in "preferred name
   syntax", as specified by RFC 1034 [N4].  [...]

Errata ID: 1012
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-29

Section 1 says:

RFC 4985 repeatedly uses inprecise terms like "domain name",
"DNS domain name", or even merely the pattern "host.example.com"
(in Section 4), in places where preferably the established precise
term "fully qualified domain name" (FQDN) should have been used.

Errata ID: 2395
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-29

Section A.2 says:

  -- In the GeneralName definition using the 1993 ASN.1 syntax

It should say:

  -- The GeneralName definition using the 1993 ASN.1 syntax

RFC 4991, "A Common Schema for Internet Registry Information Service Transfer Protocols", August 2007

Source of RFC: crisp (app)

Errata ID: 1011
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Held for Document Update by: Alexey Melnikov
Date Held: 2010-05-21

Section 10 says:

Section 10 (on page 10) is confusing due to missing appropriate
structuring, misleadingly joining the two distinct registrations.

The RFC says (I have omitted blank lines in the bullets for the
sake of better readability in the context of this message):

------
10.  IANA Considerations

10.1.  XML Namespace URN Registration

   This document makes use of the XML namespace and schema registry
   specified in XML_URN [7].  Accordingly, the following registrations
   have been made by IANA:

   o  XML Namespace URN/URI:
      *  urn:ietf:params:xml:ns:iris-transport

   o  Contact:
      *  Andrew Newton <andy@hxr.us>

   o  XML:
      *  None

   o  XML Schema URN/URI:
      *  urn:ietf:params:xml:schema:iris-transport

   o  Contact:
      *  Andrew Newton <andy@hxr.us>

   o  XML:
      *  The XML Schema specified in Section 3
------

Perhaps, it should better say:

------
10.  IANA Considerations

   This document makes use of the XML namespace and schema registry
   specified in XML_URN [7].  Accordingly, the following registrations
   have been made by IANA:

10.1.  XML Namespace URN Registration

   o  XML Namespace URN/URI:
      *  urn:ietf:params:xml:ns:iris-transport

   o  Contact:
      *  Andrew Newton <andy@hxr.us>

   o  XML:
      *  None

10.2.  XML Schema URN/URI Registration

   o  XML Schema URN/URI:
      *  urn:ietf:params:xml:schema:iris-transport

   o  Contact:
      *  Andrew Newton <andy@hxr.us>

   o  XML:
      *  The XML Schema specified in Section 3
------

Furthermore, all occurrences of "URN/URI" might better have been
shortened to "URN" there, for brevity and clarity.

RFC 4992, "XML Pipelining with Chunks for the Internet Registry Information Service", August 2007

Note: This RFC has been updated by RFC 8996

Source of RFC: crisp (app)

Errata ID: 2832
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Held for Document Update by: Peter Saint-Andre
Date Held: 2011-06-11

Section 6.5 says:

   o  mechanism data length - the length of the SASL data.

It should say:

   o  mechanism data length - the length of the SASL data,
      or the special value 65535 (to indicate the absence of
      an initial SASL response -- see below).

Notes:

The final paragraph of Section 6.5 (i.e., the 2nd paragraph
on page 12) says:

When used as an initial challenge response for SASL mechanisms that
support such a feature, the mechanism data length may be set to a
decimal value of 65,535 to indicate an absent initial response. A
value of 0 indicates an empty initial response.

Apparently, the need to subtly distinguish an absent initial response
from an empty initial response is the only justification left for the
existence of the 'mechanism data length' field.
But this information could be conveyed in a single flag bit.

[Separating into individual errata from 1009]

Errata ID: 2828
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Held for Document Update by: Pete Resnick
Date Held: 2011-06-11

Section 6 says:

        +-----------+------------+--------+
   field | chunk     | chunk data | chunk  |
         | descriptor| length     | data   |
         +-----------+------------+--------+
   octets      1            2      variable

                                  chunk

It should say:

         +-----------+------------+--------+
   field | chunk     | chunk data | chunk  |
         | descriptor| length     | data   |
         +-----------+------------+--------+
   octets      1            2      variable

                                  Chunk

Notes:

The figure caption of the last diagram in Section 6, at the bottom
of page 8, resembles mis-spaced spurious text because it is not
written with headline capitalisation (as all othe similar figure
captions are).

[Separating into individual errata from 1009]

Errata ID: 2831
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Held for Document Update by: Pete Resnick
Date Held: 2011-06-11

Section 6.5 says:

    ... a server can determine authentication status ...

It should say:

    ... a server can determine the authentication status ...

Notes:

[Separating into individual errata from 1009]

Errata ID: 2836
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Held for Document Update by: Pete Resnick
Date Held: 2011-06-11

Section Appendix A says:

   C:           (request block)
   C: 0x00      (block header: V=0,KO=no)

It should say:

   C:           (request block)
   C: 0x20      (block header: V=0,KO=yes)

Notes:

The introductory text, near the top of page 26, says:

[...]. Note that the
client requests that the connection stay open for further requests,
but the server does not honor this request.

This example should better be corrected to show the KO bit as announced, for educational purposes.

[Separating into individual errata from 1009]

Errata ID: 2833
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Held for Document Update by: Pete Resnick
Date Held: 2011-06-11

Section 6.6 says:

		   where as

It should say:

                   whereas

Notes:

[Separating into individual errata from 1009]

Errata ID: 2834
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Held for Document Update by: Pete Resnick
Date Held: 2011-06-11

Section 10 says:

   Section 6.2 of RFC 3981 [1] (IRIS-CORE) states that IRIS-BEEP [2] is
   the default transport for IRIS.  [...]

It should say:

   Section 7.2 of RFC 3981 [1] (IRIS-CORE) states that IRIS-BEEP [2] is
   the default transport for IRIS.  [...]

Notes:

[Separating into individual errata from 1009]

Errata ID: 2835
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Held for Document Update by: Pete Resnick
Date Held: 2011-06-11

Section 14.1 says:

      Anonymous client access SHOULD be considered in one of two
      methods:

It should say:

   Anonymous client access SHOULD be considered in one of two methods:

Notes:

Near the bottom of page 17, the paragraph introducing the list of
numbered items is indented too much.

[Separating into individual errata from 1009]

RFC 4995, "The RObust Header Compression (ROHC) Framework", July 2007

Note: This RFC has been obsoleted by RFC 5795

Source of RFC: rohc (tsv)

Errata ID: 1256
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-11
Held for Document Update by: Magnus Westerlund

Section 5.2.4,1st ln says:

   Feedback carries information from the decompressor to compressor.
   Feedback can be sent over a ROHC channel that operates in the same
   direction as the feedback.

It should say:

|  Feedback carries information from the decompressor to the compressor.
   Feedback can be sent over a ROHC channel that operates in the same
   direction as the feedback.
 

Notes:

Missing article

Errata ID: 1257
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-11
Held for Document Update by: Magnus Westerlund

Section 6,2nd bullet says:

   o  Field encodings

      Bits and groups of bits from the packet format layout, referred to
      as Compressed fields, represents the result of an encoding method
      specific for that compressed field within a specific packet
      format.  The profile defines these encoding methods.

It should say:

   o  Field encodings

      Bits and groups of bits from the packet format layout, referred to
|     as Compressed fields, represent the result of an encoding method
      specific for that compressed field within a specific packet
      format.  The profile defines these encoding methods.

Notes:

singular/plural mismatch, resolved by: s/represents/represent/

RFC 4996, "RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)", July 2007

Note: This RFC has been obsoleted by RFC 6846

Source of RFC: rohc (tsv)

Errata ID: 1290
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-21
Held for Document Update by: Magnus Westerlund

Section 5.2.1.1 says:

   The optimistic approach is the principle by which a compressor sends
   the same type of information for a number of packets (consecutively
   or not) until it is fairly confident that the decompressor has
   received the information.  The optimistic approach is useful to
|  ensure robustness when ROHC-TCP is used to compress packet over lossy
   links.

It should say:

   The optimistic approach is the principle by which a compressor sends
   the same type of information for a number of packets (consecutively
   or not) until it is fairly confident that the decompressor has
   received the information.  The optimistic approach is useful to
|  ensure robustness when ROHC-TCP is used to compress packets over
   lossy links.
                                                             ^

Errata ID: 1296
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-21
Held for Document Update by: Magnus Westerlund

Section 7.1, p.37 says:

      Payload: The payload of the corresponding original packet, if any.
      The payload consists of all data after the last octet of the TCP
|     header to end of the uncompressed packet.  The presence of a
      payload is inferred from the packet length.

It should say:

      Payload: The payload of the corresponding original packet, if any.
      The payload consists of all data after the last octet of the TCP
|     header to the end of the uncompressed packet.  The presence of a
      payload is inferred from the packet length.

Notes:

Location is last paragraph in unnumbered subsection on IR packet type.

Errata ID: 1297
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-21
Held for Document Update by: Magnus Westerlund
Date Held: 2009-09-07

Section 7.2, p.39 says:

|  The ROHC-TCP IR-CR packet follows the general format of the ROHC CR
   packet, as defined in [RFC4164], Section 3.5.2.  [...]
   

It should say:

   The ROHC-TCP IR-CR packet follows the general format of the ROHC
|  IR-CR packet, as defined in [RFC4164], Section 3.5.2.  [...]
 

Notes:

RFC 4996 should use precise terminology established in RFC 4995
and RFC 4164.
"CR" does not appear anywhere in both RFCs (and it does not recur in
RFC 4996 as well); "IR-CR" should be used for clarity and precision.

Chair reply: It should be IR-CR and there is no CR defined in the document, but I think most people will understand the sentence. Still, if/when we update this document we should make this correction. So hold for update.

RFC 5002, "The Session Initiation Protocol (SIP) P-Profile-Key Private Header (P-Header)", August 2007

Note: This RFC has been updated by RFC 8217

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: gen

Errata ID: 4649
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Brett Tate
Date Reported: 2016-03-29
Held for Document Update by: Lars Eggert
Date Held: 2023-08-11

Section 5 says:

The following is an example of a P-Profile-Key header field that
contains a Wildcarded Public Service Identity:

It should say:

If the URI contains a comma, question mark or semicolon, the
URI MUST be enclosed in angle brackets (< and >).

The following is an example of a P-Profile-Key header field that
contains a Wildcarded Public Service Identity:

Notes:

If addr-spec is used when there are parameters, it is ambiguous if the parameters are URI parameters or header parameters. For consistency with RFC 3261 section 20, the same bracket rule is indicated even if comma and question mark do not cause an issue.

RFC 5003, "Attachment Individual Identifier (AII) Types for Aggregation", September 2007

Source of RFC: pwe3 (int)

Errata ID: 3411
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Rajiv Asati
Date Reported: 2012-11-15
Held for Document Update by: Brian Haberman

Section 3.2 says:

     o Prefix = The 32-bit prefix is a value assigned by the provider or
       it can be automatically derived from the PE's /32 IPv4 loopback
       address.  Note that, for IP reachability, it is not required that
       the 32-bit prefix have any association with the IPv4 address
       space used in the provider's IGP or BGP.

It should say:

     o Prefix = The 32-bit prefix is a value assigned by the provider or
       it can be automatically derived from the PE's router-id i.e. LSR Id.
       Note that it is not required that
       the 32-bit prefix is IP routable or have any association with the 
       IPv4 address space used in the provider's IGP or BGP. 

Notes:

The intent of this RFC is to treat the 32bit prefix as a number that provides uniqueness in the network (within the ASN). While it can be derived from the IPv4 /32 Loopback address, it causes confusion when routers are configured with no IPv4. It is better to suggest using router-id used by LDP for calculating the LSR identifier. How is router-id calculated is outside the scope of this document.`

RFC 5012, "Requirements for Emergency Context Resolution with Internet Technologies", January 2008

Source of RFC: ecrit (rai)

Errata ID: 1259
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-13
Held for Document Update by: Robert Sparks

Section 8, pg.19 says:

   Ma14.  Resilience to mapping server failure:  The mapping protocol
      MUST support a mechanism that enables the client to fail over to
      different (replica) mapping server.

It should say:

   Ma14.  Resilience to mapping server failure:  The mapping protocol
|     MUST support a mechanism that enables the client to fail over to a
      different (replica) mapping server.

Notes:

insert missing "a"

Errata ID: 1263
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-13
Held for Document Update by: Robert Sparks

Section 8 (p.19) says:

   Ma15.  Traceable resolution:  The mapping protocol SHOULD support the
|     ability of the mapping client to be able to determine the entity
      or entities that provided the emergency address resolution
      information.

It should say:

   Ma15.  Traceable resolution:  The mapping protocol SHOULD support the
|     ability of the mapping client to determine the entity or entities
      that provided the emergency address resolution information.

Notes:

"double replication": ability to <-> to be able to :-)

Note:
The previous entry of this same Errata Entry has been truncated
inadvertently -- please remove it.

RFC 5024, "ODETTE File Transfer Protocol 2.0", November 2007

Note: This RFC has been updated by RFC 8996

Source of RFC: INDEPENDENT

Errata ID: 3453
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Ieuan Friend
Date Reported: 2013-01-14
Held for Document Update by: Nevil Brownlee
Date Held: 2014-01-20

Section 4.5.1 says:

   The Speaker notifies the Listener that it has finished sending a
   Virtual File by sending an End File (EFID) command.  The Listener
   replies with a positive or negative End File command and has the
   option to request a Change Direction command from the Speaker.
 
   1. Speaker  -- EFID ------------> Listener   End File
               <------------ EFPA --            Answer YES
 
   2. Speaker  -- EFID ------------> Listener   End File
               <------------ EFPA --            Answer YES + CD
               -- CD -------------->            Change Direction
      Listener <------------ EERP -- Speaker    End to End Response
               -------------- RTR ->            Ready to Receive
      Listener <------------ NERP -- Speaker    Negative End Response
               -------------- RTR ->            Ready to Receive
               Go to Start File Phase
 
   3. Speaker  -- EFID ------------> Listener   End File
               <------------ EFNA --            Answer NO

It should say:

   The Speaker notifies the Listener that it has finished sending a
   Virtual File by sending an End File (EFID) command.  The Listener
   replies with a positive or negative End File command and has the
   option to request a Change Direction command from the Speaker.
 
   1. Speaker  -- EFID ------------> Listener   End File
               <------------ EFPA --            Answer YES
 
   2. Speaker  -- EFID ------------> Listener   End File
               <------------ EFPA --            Answer YES   CD
               -- CD -------------->            Change Direction
      Listener <------------ EERP -- Speaker    End to End Response
               -------------- RTR ->            Ready to Receive
      Listener <------------ NERP -- Speaker    Negative End Response
               -------------- RTR ->            Ready to Receive
               Go to Start File Phase
 
   3. Speaker  -- EFID ------------> Listener   End File
               <------------ EFNA --            Answer NO
 
   Following the receipt of a positive End File command which does
   not request a Change Direction command, the Speaker has the option
   to send   a file (SFID), an EERP/NERP, a CD or an ESID with error. 

   If the Speaker wishes to end the session normally, a 
   Change Direction (CD) command MUST be sent to the Listener.
 
   4. Speaker  -- EFID ------------> Listener   End File
               <------------ EFPA --            Answer YES   No CD
               -- CD -------------->            Change Direction
      Listener <------------ ESID -- Speaker    End Session

Notes:

This erratum adds a little more documentation to the ODETTE protocol,
but doesn't seem to be correcting an actual error.

Errata ID: 3454
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Ieuan Friend
Date Reported: 2013-01-14
Held for Document Update by: Nevil Brownlee
Date Held: 2014-01-20

Section 5.3.2 says:

   o-------------------------------------------------------------------o
   |       SSID        Start Session                                   |
   |                                                                   |
   |       Start Session Phase     Initiator <---> Responder           |
   |-------------------------------------------------------------------|
   | Pos | Field     | Description                           | Format  |
   |-----+-----------+---------------------------------------+---------|
   |   0 | SSIDCMD   | SSID Command 'X'                      | F X(1)  |
   |   1 | SSIDLEV   | Protocol Release Level                | F 9(1)  |
   |   2 | SSIDCODE  | Initiator's Identification Code       | V X(25) |
   |  27 | SSIDPSWD  | Initiator's Password                  | V X(8)  |
   |  35 | SSIDSDEB  | Data Exchange Buffer Size             | V 9(5)  |
   |  40 | SSIDSR    | Send / Receive Capabilities (S/R/B)   | F X(1)  |
   |  41 | SSIDCMPR  | Buffer Compression Indicator (Y/N)    | F X(1)  |
   |  42 | SSIDREST  | Restart Indicator (Y/N)               | F X(1)  |
   |  43 | SSIDSPEC  | Special Logic Indicator (Y/N)         | F X(1)  |
   |  44 | SSIDCRED  | Credit                                | V 9(3)  |
   |  47 | SSIDAUTH  | Secure Authentication (Y/N)           | F X(1)  |
   |  48 | SSIDRSV1  | Reserved                              | F X(4)  |
   |  52 | SSIDUSER  | User Data                             | V X(8)  |
   |  60 | SSIDCR    | Carriage Return                       | F X(1)  |
   o-------------------------------------------------------------------o

      SSIDCMD   Command Code
      Character

      Value: 'X'  SSID Command identifier.

   SSIDLEV   Protocol Release Level                           Numeric(1)

             Used to specify the level of the ODETTE-FTP protocol

      Value: '1' for Revision 1.2
             '2' for Revision 1.3
             '4' for Revision 1.4
             '5' for Revision 2.0

             Future release levels will have higher numbers.  The
             protocol release level is negotiable, with the lowest level
             being selected.

             Note: ODETTE File Transfer Protocol 1.3 (RFC 2204)
                   specifies '1' for the release level, despite adhering
                   to revision 1.3.

It should say:

   o-------------------------------------------------------------------o
   |       SSID        Start Session                                   |
   |                                                                   |
   |       Start Session Phase     Initiator <---> Responder           |
   |-------------------------------------------------------------------|
   | Pos | Field     | Description                           | Format  |
   |----- ----------- --------------------------------------- ---------|
   |   0 | SSIDCMD   | SSID Command 'X'                      | F X(1)  |
   |   1 | SSIDLEV   | Protocol Release Level                | F 9(1)  |
   |   2 | SSIDCODE  | Initiator's Identification Code       | V X(25) |
   |  27 | SSIDPSWD  | Initiator's Password                  | V X(8)  |
   |  35 | SSIDSDEB  | Data Exchange Buffer Size             | V 9(5)  |
   |  40 | SSIDSR    | Send / Receive Capabilities (S/R/B)   | F X(1)  |
   |  41 | SSIDCMPR  | Buffer Compression Indicator (Y/N)    | F X(1)  |
   |  42 | SSIDREST  | Restart Indicator (Y/N)               | F X(1)  |
   |  43 | SSIDSPEC  | Special Logic Indicator (Y/N)         | F X(1)  |
   |  44 | SSIDCRED  | Credit                                | V 9(3)  |
   |  47 | SSIDAUTH  | Secure Authentication (Y/N)           | F X(1)  |
   |  48 | SSIDRSV1  | Reserved                              | F X(4)  |
   |  52 | SSIDUSER  | User Data                             | V X(8)  |
   |  60 | SSIDCR    | Carriage Return                       | F X(1)  |
   o-------------------------------------------------------------------o
 
      SSIDCMD   Command Code
      Character
 
      Value: 'X'  SSID Command identifier.
 
   SSIDLEV   Protocol Release Level                           Numeric(1)
 
             Used to specify the level of the ODETTE-FTP protocol
 
      Value: '1' for Revision 1.2
             '2' for Revision 1.3
             '4' for Revision 1.4
             '5' for Revision 2.0
 
             Future release levels will have higher numbers.  The
             protocol release level is negotiable, with the lowest level
             being selected.
 
             Note: ODETTE File Transfer Protocol 1.3 (RFC 2204)
                   specifies '1' for the release level, despite adhering
                   to revision 1.3.
 
       Negotiation of the release level:
 
             Release level m -- SSID ------------>
                             <------------ SSID --  Release level n
                                                    (n less than or
                                                     equal to m)
             
             The negotiated value will be n unless it is rejected
             with an ESID '10' (Mode or capabilities incompatible).
 
                             -- ESID '10' ------->

Notes:

Clarification of the protocol release level negotiation process.

This erratum adds a little more to the ODETTE protocol's documentation, but does not report an error.

RFC 5031, "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", January 2008

Note: This RFC has been updated by RFC 7163

Source of RFC: ecrit (rai)

Errata ID: 1261
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-13
Held for Document Update by: Robert Sparks

Section 7.2 (p.11) says:

   [LOST]     Hardie, T., "LoST: A Location-to-Service Translation
|             Protocol", Work in Progress, March 2007.

It should say:

   [LOST]     Hardie, T., "LoST: A Location-to-Service Translation
|             Protocol", Work in Progress, August 2007.

Notes:

Outdated reference.

The publication of RFC 5012 and this RFC (5031) apparently has been
coordinated. Hence, both RFCs should refer to the same version of
this particular work in progress.

Errata ID: 1262
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-13
Held for Document Update by: Robert Sparks

Section App.A (p.13) says:

   tel:sos  This solution avoids name conflicts, but requires extending
|     the "tel" URI "tel" [RFC3966].  It also only works if every
      outbound proxy knows how to route requests to a proxy that can
      reach emergency services since tel URIs do not identify the
      destination server.

It should say:

   tel:sos  This solution avoids name conflicts, but requires extending
|     the "tel" URI [RFC3966].  It also only works if every outbound
      proxy knows how to route requests to a proxy that can reach
      emergency services since tel URIs do not identify the destination
      server.

Notes:

Spurious word replication of "tel" .

For conformance with the display enhancement style used throughout the
document, it might also have been preferable to use single quotes:
'tel' .

RFC 5035, "Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility", August 2007

Source of RFC: smime (sec)

Errata ID: 1007
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Held for Document Update by: Tim Polk
Date Held: 2010-07-20

Section A says:

At the end of Appendix A, near the bottom of page 15, the last
two ASN.1 definitions are joined on one line.  Apart from a major
decrease in readability, this in fact might be wrong in ASN.1.

The RFC says:

   Hash ::= OCTET STRING  IssuerSerial ::= SEQUENCE {
        issuer                   GeneralNames,
        serialNumber             CertificateSerialNumber
   }

It should say:

   Hash ::= OCTET STRING

   IssuerSerial ::= SEQUENCE {
        issuer                   GeneralNames,
        serialNumber             CertificateSerialNumber
   }

(Note: I have indented the original/replacement RFC text by 3 columns
 to make it better distinguishable in this context.)

It should say:

See above.

Notes:

See above.

Errata ID: 2365
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Held for Document Update by: Tim Polk
Date Held: 2010-07-29

Section 6 says:

The first paragraph of Section 6, on page 8, says:

   (Note: This section does not present new material.  This section
|  contains the original contents of Section 5.4 in [ESS], which are
   retained with minor changes in this specification to achieve
   backwards compatibility.)

The section number given therein is wrong; it should be 5.4.1 :

   (Note: This section does not present new material.  This section
|  contains the original contents of Section 5.4.1 in [ESS], which are
   retained with minor changes in this specification to achieve
   backwards compatibility.)

It should say:

See above.

Notes:

See above.

Errata ID: 2366
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Held for Document Update by: Tim Polk
Date Held: 2010-07-29

Section 6 says:

On top of page 7, Section 6 of RFC 5035 says:

   The fields of ESSCertID are defined as follows:

   certHash
|     is computed over the entire DER-encoded certificate (including the
|     signature).

   [...]

This is the counterpart to the issue explained in errata 2634.
In the original Cert ID (v1) described here, the signature algorithm
is fixed and should be specified explicitely as SHA-1 in the
description of the certHash field :

   certHash
|     is computed over the entire DER-encoded certificate (including the
|     signature), using the SHA-1 algorithm.
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^

It should say:

See above.

Notes:

See above.

RFC 5036, "LDP Specification", October 2007

Note: This RFC has been updated by RFC 6720, RFC 6790, RFC 7358, RFC 7552

Source of RFC: mpls (rtg)

Errata ID: 2133
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2010-04-07
Held for Document Update by: Adrian Farrel

Section 2.5.4 says:

   NON EXISTENT  Session TCP connection established  INITIALIZED
                 established

It should say:

   NON EXISTENT  Session TCP connection established  INITIALIZED

Errata ID: 3155
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2012-03-12
Held for Document Update by: Adrian Farrel

Section 3.5.1.2.1 says:

      -  The LDP protocol version is not supported by the receiver, d or
         it is supported but is not the version negotiated for the
         session during session establishment.  This is a fatal error
         signaled by the Bad Protocol Version Status Code.

It should say:

      -  The LDP protocol version is not supported by the receiver, or
         it is supported but is not the version negotiated for the
         session during session establishment.  This is a fatal error
         signaled by the Bad Protocol Version Status Code.

Errata ID: 3415
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jeff Wheeler
Date Reported: 2012-11-26
Held for Document Update by: Adrian Farrel
Date Held: 2012-11-26

Section 3.1 says:

Prior to completion of the negotiation, the
maximum allowable length is 4096 bytes.

It should say:

Prior to completion of the negotiation, the
maximum allowable length is 4096 octets.

Notes:

"octets" instead of "bytes"
Although "octet" is technically correct, there will be little confusion caused by the use of "byte"

Errata ID: 3425
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jeff Wheeler
Date Reported: 2012-12-08
Held for Document Update by: Adrian Farrel

Section 3.5 says:

The specification assigns type values for related messages, such as
the Label messages, from of a contiguous block in the 16-bit message
type number space.

It should say:

The specification assigns type values for related messages, such as
the Label messages, from a contiguous block in the 16-bit message
type number space.

Notes:

"from of a contiguous block" changed to "from a contiguous block"

Errata ID: 5587
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramakrishna Rao DTV
Date Reported: 2018-12-28
Held for Document Update by: Deborah Brungard
Date Held: 2019-01-08

Section 2.6.2.2 says:

  "In Downstream Unsolicited advertisement mode, label mapping
   advertisements for all routes may be received from all LDP peers.
   When using Liberal Label retention, every label mappings received
   from a peer LSR is retained regardless of whether the LSR is the next
   hop for the advertised mapping..."

It should say:

  "In Downstream Unsolicited advertisement mode, label mapping
   advertisements for all routes may be received from all LDP peers.
   When using Liberal Label retention, every label mapping received
   from a peer LSR is retained regardless of whether the LSR is the next
   hop for the advertised mapping..."

Notes:

s/mappings/mapping/

Errata ID: 5674
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramakrishna Rao DTV
Date Reported: 2019-03-25
Held for Document Update by: Deborah Brungard
Date Held: 2019-05-30

Section A.2.8 says:

-  FEC.  The FEC for which a label request is to be sent.

It should say:

-  FEC.  The FEC for which a label mapping is to be sent.

Notes:

Prepare_Label_Mapping_Attributes is used for sending label mapping message and
NOT label request message.

RFC 5054, "Using the Secure Remote Password (SRP) Protocol for TLS Authentication", November 2007

Note: This RFC has been updated by RFC 8996

Source of RFC: tls (sec)

Errata ID: 3570
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nico Roeser
Date Reported: 2013-03-27
Held for Document Update by: Sean Turner

Section 2.5.1.3 says:

2.5.1.3.  Unknown SRP         User Name

It should say:

2.5.1.3.  Unknown SRP User Name

Notes:

Too many spaces in the heading.

RFC 5059, "Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)", January 2008

Note: This RFC has been updated by RFC 8736, RFC 9436

Source of RFC: pim (rtg)

Errata ID: 1323
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-02-14
Held for Document Update by: Adrian Farrel
Date Held: 2011-08-05

Section 4.1, pg.28 says:

   BSR Address
        The address of the bootstrap router for the domain.  The format
        for this address is given in the Encoded-Unicast address in [1].

It should say:

   BSR Address
        The address of the bootstrap router for the domain.  The format
|       for this address is given in the Encoded-Unicast address format
|       defined in [1] and restated in Section 4.

Notes:

Note: This Erratum was updated by the AD from the original proposal. The original suggested replacing the reference to [1] with a reference to Section 4. The resolution includes both references.

The notes below were updated to be consistent with this change.

======

The above quotation is at the bottom of page 28.
Further instances of the same issue are enumerated at the end of these Notes.

Rationale:

In Section 4, on page 24, the RFC purposely restates the terms
"Encoded-Unicast format" and "Encoded-Group format" from [1] and
continues:

We repeat these here to aid readability.

---- End of Rationale ----

This issue recurs four more times, and similar changes
should be applied:

o on page 29, in the first item, "Group Address 1..n",

o on page 29, in the 4th item, "RP address 1..m"
(subject to preceding Erratum),

as well as in Section 4.2:

o on page 32, in the 3rd item, "RP Address", and

o on page 32, in the 4th item, "Group Address-1..n"
(Note that the hyphen above also should be a blank, for consistency.)

RFC 5060, "Protocol Independent Multicast MIB", January 2008

Source of RFC: pim (rtg)

Errata ID: 1445
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-06-14
Held for Document Update by: Adrian Farrel
Date Held: 2011-09-28

Section 5, pg.12 says:

pimInvalidRegisterAddressType
    ...
    DESCRIPTION
            "The address type stored in pimInvalidRegisterOrigin,
            pimInvalidRegisterGroup, and pimInvalidRegisterRp.
            [...]

It should say:

pimInvalidRegisterAddressType
    ...
    DESCRIPTION
|           "The type of the addresses stored in
            pimInvalidRegisterOrigin,
            pimInvalidRegisterGroup, and pimInvalidRegisterRp.
            [...]

Notes:

The Original Text is misleading. No "address type [is] stored" in
the columnar objects pimInvalidRegisterOrigin,
pimInvalidRegisterGroup, and pimInvalidRegisterRp; addresses are!
The addres type for these addresses is stored in
pimInvalidRegisterAddressType -- as its name says.

Type changed to Editorial

Errata ID: 1446
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-06-14
Held for Document Update by: Adrian Farrel

Section 5, pg.20 says:

pimInterfaceTrigHelloInterval
    ...
    DESCRIPTION
       ...
       the 'Trigered_Hello_Delay' timer ...

It should say:

pimInterfaceTrigHelloInterval
    ...
    DESCRIPTION
       ...
       the 'Triggered_Hello_Delay' timer ...

Notes:

Typo yields invalid variable name / reference to the PIM-SM spec.

RFC 5063, "Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart", October 2007

Source of RFC: ccamp (rtg)

Errata ID: 1000
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-10-23
Held for Document Update by: Adrian Farrel
Date Held: 2009-08-24

Section 4 says:

(1)  Document title and Abstract

Over the years, there have been arising different of flavors of RSVP.
In particular, RSVP-TE, based on the seminal RFC 3209, addresses
quite distinct requirements than the original, QoS oriented, basic
RSVP, and it follows a distinguished service model.
It has been good practice to clearly distinguish between RSVP-TE
and the basic RSVP in the titles of RFCs published in the last
years.  Unfortunately, this has not been done for RFC 5063.

BTW:
  Some of the extensions to RSVP-TE published in RFC 3473, in
  particular those reused and amended per RFC 5063, apparently
  are not only applicable to GMPLS, but also to 'classical' MPLS /
  MPLS Traffic Engineering.  The mentioning of 'GMPLS' in the
  title of RFC 5063 therefore seems to unnecessarily narrow the
  scope of the RFC.  The body of RFC 5063, e.g. the text in the
  Introduction, seems to strongly support this point of view.

Therefore, it might perhaps have been preferable to make the title
of RFC 5063 (omitting the expansion of acronyms, anecdotally anyway
only performed partially in the published title):

             Extensions to RSVP-TE Graceful Restart

Accordingly, the Abstract of the document should better talk about
RSVP-TE than (pure) RSVP, in its first paragraph.


(2)  Section 1 -- word omission

Within Section 1 of RFC 5063, in the 4th paragraph on page 4,
the RFC says:

                                  [...].  The downstream RSVP neighbor
   can indicate its ability to send RecoveryPath messages by including
|  the Capability object with the RecoveryPath Transmit Enabled set in
   its Hello messages to the restarting node.  [...]

It should say:

                                  [...].  The downstream RSVP neighbor
   can indicate its ability to send RecoveryPath messages by including
|  the Capability object with the RecoveryPath Transmit Enabled bit set
   in its Hello messages to the restarting node.  [...]
                                                                ^^^^

Note: This correction is in accordance with the language used
      in other places in the RFC, in particular the immediate
      preceding sentence in the same paragraph.


(3)  Section 4.2 -- incomplete specification

Within Section 4.2, the artwork on page 6 depicting the Capability
object includes the RSVP object header and specifies the constant
values applicable for the Class-Num and C-Type field.
Contrary to that, it does not specify the value of the Length field
(that is equally constant for the new object) -- neither in the
diagram, nor does it supply explanatory text for that field (that
could have pointed to the fundamental specification and/or directly
specified the value).
For simplicity, I propose to correct the diagram.
The RFC says:

   The format of a Capability object is:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     |            Length             | Class-Num(134)|  C-Type  (1)  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Reserved                        |T|R|S|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

For the sake of completeness of the specification, the RFC should say:

   The format of a Capability object is:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     |           Length (8)          | Class-Num(134)|  C-Type  (1)  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Reserved                        |T|R|S|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


(4)   Section 4.4.2 -- potentially misleading omission of article

In the 2nd-to-last paragraph of Section 4.4.2, on top of page 9
RFC 5063 says:

                                              [...].  If the restarting
   node expects to recover RSVP state by the receipt and processing of
|  RecoveryPath messages, it MUST follow procedures defined in Section
   4.5.2, with the downstream RSVP neighbor.

It should say:
                                              [...].  If the restarting
   node expects to recover RSVP state by the receipt and processing of
   RecoveryPath messages, it MUST follow the procedures defined in
   Section 4.5.2, with the downstream RSVP neighbor.

Rationale:
  Without the omitted 'the', the reference is to an unspecified set
  of procedures there, which might be misleading.  For the sake of
  clarity and precision, the article should be supplied.

This issue recurs in subsequent parts of the text.
Similar corrections will be listed below in shorthand notation,
referring to this item.


(5)  Section 4.5.2.1 -- grammar / terminology

On page 11, at the end of the first paragraph of Section 4.5.2.1,
the RFC says:

                                              [...].  If there is
   resynchronized state and there is no MESSAGE_ID object or reliable
   message delivery [RFC2961] is not supported, the node SHOULD send a
|  trigger Path message, and, consider the message as processed.
          ^
It should say:

                                              [...].  If there is
   resynchronized state and there is no MESSAGE_ID object or reliable
   message delivery [RFC2961] is not supported, the node SHOULD send a
|  triggered Path message, and, consider the message as processed.
          ^^^

Rationale: "a trigger Path message" might well be misunderstood
  to be a quite different concept than "a triggered Path message".
  The latter is the proper term.

This issue recurs in subsequent parts of the text.
Similar corrections will be listed below in shorthand notation,
referring to this item.


(6)  Section 4.5.2.2 -- grammar / terminology

As a corollary to item (5) above, in Section 4.5.2.2 the second
line of the last paragraph on page 12 should be corrected:
  "a trigger Path message"  -->  "a triggered Path message"


(7)  Section 5 -- word omission, and spurious word

The second paragraph of Section 5, on mid-page 14, says:

   Selective transmission of RecoveryPath messages is controlled much
|  the same way transmission of Path or Resv messages is controlled with
   standard Summary Refresh, see [RFC2961].  In standard Summary
   Refresh, an Srefresh message is sent by a node to identify to its
|  neighbor about Path and Resv state that is locally installed and
   available.  [...]

It should say:

   Selective transmission of RecoveryPath messages is controlled much
|  the same way as transmission of Path or Resv messages is controlled
   with standard Summary Refresh, see [RFC2961].  In standard Summary
   Refresh, an Srefresh message is sent by a node to identify to its
|  neighbor Path and Resv state that is locally installed and available.
   [...]


(8)   Section 5.2.1 -- potentially misleading omission of article

As a corollary to item (4) above, the text in the 3rd paragraph of
Section 5.2.1, at the bottom of page 16 should be corrected:

   "revert to normal procedures defined in Section 4.5.1"
---
   "revert to the normal procedures defined in Section 4.5.1"


(9)  Section 5.3.2 -- grammar / terminology

As a corollary to item (5) above, in the second paragraph of
Section 5.3.2 (on mid-page 19), apply the corrections:

    "a trigger Path message"      -->  "a triggered Path message"
and
    "such trigger Path message"   -->  "such triggered Path message"


(10)  Section 5.3.3 -- potentially misleading omission of article

As another corollary to item (4) above, the text in the first
paragraph of Section 5.3.3, near the bottom of page 19 should be
corrected:

              [...].  Processing of MESSAGE_ID NACKs with the
|  RecoveryPath Flag set (1) also follows procedures defined in
   [RFC2961] unless explicitly modified in this section.
---
              [...].  Processing of MESSAGE_ID NACKs with the
|  RecoveryPath Flag set (1) also follows the procedures defined in
   [RFC2961] unless explicitly modified in this section.

Notes:

[Adrian Farrel]
(1) No change needed. Inclusion of "GMPLS" in the title indicates that this is the GMPLS extensions to the TE extensions to RSVP.
(5), (6) and (9) "trigger Path message" is correct. The name of the Path message is a trigger Path message.
(7) Insertion of "as" is not required in US English.

RFC 5065, "Autonomous System Confederations for BGP", August 2007

Source of RFC: idr (rtg)

Errata ID: 1005
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-08-17
Held for Document Update by: Stewart Bryant
Date Held: 2013-09-19

 

(1)  obsolete reference tag - #1

Apparently, some reference tags have not been updated when the
'References' Section (10.) has been modified to incorporate
current versions of the relevant documents.

The second paragraph of Section 1, on page 3 of RFC 5065, says:

   This scaling problem has been well documented and a number of
|  proposals have been made to alleviate this, such as [RFC2796] and
   [RFC1863] (made historic by [RFC4223]).  [...]

RFC 2796 has been obsoleted by RFC 4456, and Section 10.2 only
contains an entry for [RFC4456], which is only used in the
second paragraph of Section 2, but no entry for [RFC 2796].

Therefore, the above sentence should better say:

   This scaling problem has been well documented and a number of
|  proposals have been made to alleviate this, such as [RFC4456] and
   [RFC1863] (made historic by [RFC4223]).  [...]

or, if you prefer, for the sake of historical precision:

   This scaling problem has been well documented and a number of
|  proposals have been made to alleviate this, such as [RFC4456]
|  (first version published in [RFC 2796]) and [RFC1863] (made historic
   by [RFC4223]).  [...]

For the latter variant, an entry for [RFC2796] must be restored into
Section 10.2, as well.


(2)  sluggish / imprecise language

The third paragraph of Section 4, at the bottom of page 5, says:

   A BGP speaker receiving an AS_PATH attribute containing an autonomous
|  system matching its own AS Confederation Identifier SHALL treat the
   path in the same fashion as if it had received a path containing its
   own AS number.

Preferably, the text should not mess up the terms 'autonomous system'
and 'autonomous system number'.
Thus, it should say:

   A BGP speaker receiving an AS_PATH attribute containing an autonomous
|  system number matching its own AS Confederation Identifier SHALL
   treat the path in the same fashion as if it had received a path
   containing its own AS number.


(3)  misleading specification, with bad wording

In Section 4.1, the bullets b) 1) (on page 6) and c) 2) (on page 7)
have been amended by instructions for the case of AS_PATH segment
overflow.  Although the details of the action necessary according
to the spirit of BGP differ in a small, but important way, the
same wording is used in both cases.  That might be very misleading.
I propose to explicitely specify the AS number to be inserted in
both cases, using the terms defined in Section 1.2.

Furthermore, the word 'prepend' is abused in the last part of the
amendments and might even be misleading.
I propose to use 'include' in there, as the text already does in
similar context, for instance in the immediately subsequent bullets.

Therefore, the text in bullet b) 1) (on page 6),

                     [...].  If the act of prepending will cause an
         overflow in the AS_PATH segment (i.e., more than 255 ASs), it
         SHOULD prepend a new segment of type AS_CONFED_SEQUENCE and
|        prepend its own AS number to this new segment.
         ^^^^^^^         ^^^^^^^^^ ^^
should say:

                     [...].  If the act of prepending will cause an
         overflow in the AS_PATH segment (i.e., more than 255 ASs), it
         SHOULD prepend a new segment of type AS_CONFED_SEQUENCE and
|        include its own Member-AS number in this new segment.
         ^^^^^^^         ^^^^^^^^^^^^^^^^ ^^

Similarly, the identical text in bullet c) 2) (on page 7),

                     [...].  If the act of prepending will cause an
         overflow in the AS_PATH segment (i.e., more than 255 ASs), it
|        SHOULD prepend a new segment of type AS_SEQUENCE and prepend
|        its own AS number to this new segment.
                 ^^^^^^^^^ ^^                                 ^^^^^^^

should say:

                     [...].  If the act of prepending will cause an
         overflow in the AS_PATH segment (i.e., more than 255 ASs), it
|        SHOULD prepend a new segment of type AS_SEQUENCE and include
|        its own AS Condeferation Identifier in this new segment.
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^               ^^^^^^^

(4)  textual enhancement

Still in Section 4.1, in the lower half of pgae 7, the bullets a) and
b) under headline:

   When a BGP speaker originates a route then:

deal with similar cases using (almost) similar wording.
Bullet b) says:

   b) the originating speaker includes its own Member-AS Number in a
      path segment, of type AS_CONFED_SEQUENCE, in the AS_PATH attribute
      of all UPDATE messages sent to BGP speakers located in neighboring
|     Member Autonomous Systems that are members of the local
      confederation.  [...]

To finalize the similarity, and to remove the unnecessary repetition
of the word 'member', it would perhaps have been better to say:

   b) the originating speaker includes its own Member-AS Number in a
      path segment, of type AS_CONFED_SEQUENCE, in the AS_PATH attribute
      of all UPDATE messages sent to BGP speakers located in neighboring
|     autonomous systems that are members of the local confederation.
      [...]


(5)  typo, and unnecessarily differing case

The last paragraph of the new Section 5 says:

         vv
|  It is a error for a BGP speaker to receive an update message from a
   confederation peer that is not in the same Member-AS that does not
   have AS_CONFED_SEQUENCE as the first segment.  [...]

To correct the grammar, and to harmonize the case of 'UPDATE message'
throughout the whole section, it should say:

         vvv
|  It is an error for a BGP speaker to receive an UPDATE message from a
   confederation peer that is not in the same Member-AS that does not
   have AS_CONFED_SEQUENCE as the first segment.  [...]

Alternatively, perhaps, the obstinate double 'that' could easily be
removed as well:

         vvv
|  It is an error for a BGP speaker to receive an UPDATE message from a
|  confederation peer not located in the same Member-AS that does not
   have AS_CONFED_SEQUENCE as the first segment.  [...]


(6)  grammar

The first paragraph of Section 6, on top of page 10, says:

                                             vv
|  All BGP speakers participating as members of a confederation MUST
   recognize the AS_CONFED_SET and AS_CONFED_SEQUENCE segment type
   extensions to the AS_PATH attribute.

IMHO, it should be  ... participating *in* ...
Thus, the RFC should say:
                                             vv
|  All BGP speakers participating as members in a confederation MUST
   recognize the AS_CONFED_SET and AS_CONFED_SEQUENCE segment type
   extensions to the AS_PATH attribute.


(7)  obsolete reference tag - #2

Section 8 (at the bottom of page 10) says:

   This extension to BGP does not change the underlying security issues
   inherent in the existing BGP protocol, such as those described in
|  [RFC2385] and [BGP-VULN].
                  ^^^^^^^^

There is no such reference tag '[BGP-VULN]' in Section 10.
Apparently, the RFC should say:

   This extension to BGP does not change the underlying security issues
   inherent in the existing BGP protocol, such as those described in
|  [RFC2385] and [RFC4272].
                  ^^^^^^^


(8)  obsolete reference tag - #3

The first paragraph of Section 9, on top of page 11, says:

   The general concept of BGP confederations was taken from IDRP's
   Routing Domain Confederations [ISO10747].  Some of the introductory
|  text in this document was taken from [RFC2796].
                                            ^^^^

As in item (1) above, either the tag '[RFC2796]' is updated:

   The general concept of BGP confederations was taken from IDRP's
   Routing Domain Confederations [ISO10747].  Some of the introductory
|  text in this document was taken from [RFC4456].
                                            ^^^^

or an entry for '[RFC2796]' must be restored into Section 10.2 .


(9)  obsolete RFCs listed as Normative References ?!?

RFC 5065, on page 11, lists its obsolete predecessors as Normative
References, [RFC1965] and [RFC3065], in Section 10.1.

According to common sense, general practice, and the rules for
Normative References, I would have preferred to see these entries
placed into Section 10.2, as Informative References.

Notes:

This proposed no normative changes, and the clarifications do not appear to be urgent.

RFC 5070, "The Incident Object Description Exchange Format", December 2007

Note: This RFC has been obsoleted by RFC 7970

Note: This RFC has been updated by RFC 6685

Source of RFC: inch (sec)

Errata ID: 3333
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Youki Kadobayashi
Date Reported: 2012-09-02
Held for Document Update by: Sean Turner
Date Held: 2012-09-06

 

As this report involves a number of sections, original texts 
are also referred to in the Corrected Text below.

It should say:

#1, IncidentID includes a default value for the restriction attribute of "default" in the schema.  The specification description is updated as follows to correct the discrepancy.
Section 3.3, IncidentID:
Change from:
"  restriction
      Optional.  ENUM.  This attribute has been defined in Section 3.2."
To:
"  restriction
      Optional.  ENUM.  This attribute has been defined in Section 3.2.
      The default value is "public".


#2, In section 3.5, the UML diagram does not match the text description or schema for the minOccurs value.  It should be set to "1".  The diagram should be changed from:
"        +------------------+
         | RelatedActivity  |
         +------------------+
         | ENUM restriction |<>--{0..*}--[ IncidentID ]
         |                  |<>--{0..*}--[ URL        ]
         +------------------+

                      Figure 5: RelatedActivity Class"
To:

"        +------------------+
         | RelatedActivity  |
         +------------------+
         | ENUM restriction |<>--{1..*}--[ IncidentID ]
         |                  |<>--{1..*}--[ URL        ]
         +------------------+

                      Figure 5: RelatedActivity Class"

#3, Section 3.7.1, lists the attribute "registry" as "Required."  The default value is not specified in the schema as local, therefore the description is updated to match.  To match the schema, the definition is changed as follows:
From: 
"   registry
      Required.  ENUM.  The database to which the handle belongs.  The
      default value is 'local'.  The possible values are:"
To:
"   registry
      Optional.  ENUM.  The database to which the handle belongs.
      The possible values are:"

#4, Section 3.7.2, PostalAddress Class leverages the schema definition for MLStringType to include the "lang" attribute.  The MLStringType has this attribute as Optional.  The specification definition is updated as follows to correct the issue.
Change from: 
"   lang
      Required.  ENUM.  A valid language code per RFC 4646 [7]
      constrained by the definition of "xs:language".  The
      interpretation of this code is described in Section 6."
To:
"   lang
      Optional.  ENUM.  A valid language code per RFC 4646 [7]
      constrained by the definition of "xs:language".  The
      interpretation of this code is described in Section 6."

#5, Section 3.11, the "restriction" attribute of the History Class includes a default value of "default" in the schema.  As such, the specification definition is updated as follows.
Change from:
"   restriction
      Optional.  ENUM.  This attribute is defined in Section 3.2."
To:
"   restriction
      Optional.  ENUM.  This attribute is defined in Section 3.2.
      The default value is "default".

#6, Section 3.13, the "restriction" attribute of the Expectation Class includes a default value of "default" in the schema.  As such, the specification definition is updated as follows.
Change from:
"   restriction
      Optional.  ENUM.  This attribute is defined in Section 3.2."
To:
"   restriction
      Optional.  ENUM.  This attribute is defined in Section 3.2.
      The default value is "default".

#7, Section 3.13, the "action" attribute of the Expectation Class includes a default value of "other" in the schema.  As such, the specification definition is updated as follows.
Change from:
"   action
      Optional.  ENUM.  Classifies the type of action requested.  This
      attribute is an enumerated list with no default value."
To:
"   action
      Optional.  ENUM.  Classifies the type of action requested.  This
      attribute is an enumerated list with a default value of "other"."


#8, removed - placeholder to retain original numbering

#9, Section 3.10, a default value is specified for the "occurrence" attribute specification definition, but is not included in the schema.  The text in the specification is removed as follows to correct the discrepancy.
Change from:
"   occurrence
      Optional.  ENUM.  Specifies whether the assessment is describing
      actual or potential outcomes.  The default is "actual" and is
      assumed if not specified."
To:
"   occurrence
      Optional.  ENUM.  Specifies whether the assessment is describing
      actual or potential outcomes."


#10, Section 3.10.1, Impact Class leverages the schema definition for MLStringType to include the "lang" attribute.  The MLStringType has this attribute as Optional.  The specification definition is updated as follows to correct the issue.
Change from: 
"   lang
      Required.  ENUM.  A valid language code per RFC 4646 [7]
      constrained by the definition of "xs:language".  The
      interpretation of this code is described in Section 6."
To:
"   lang
      Optional.  ENUM.  A valid language code per RFC 4646 [7]
      constrained by the definition of "xs:language".  The
      interpretation of this code is described in Section 6."

#11, Section 3.10.1, Impact Class definition for the attribute type requires updating to match the schema listing of this attribute as "Optional".  The attribute includes a default value in the schema that should match the specification text.
Change from:
"   type
      Required.  ENUM.  Classifies the malicious activity into incident
      categories.  The permitted values are shown below.  The default
      value is "other"."
To:
"   type
      Optional.  ENUM.  Classifies the malicious activity into incident
      categories.  The permitted values are shown below.  The default
      value is "unknown"."


#12, Section 3.10.2, TimeImpact Class is inconsistent with the schema definition for the "duration" attribute.  The specification definition is updated as follows to resolve the issue.
Change from:
"   duration
      Required.  ENUM.  Defines a unit of time, that when combined with
      the metric attribute, fully describes a metric of impact that will
      be conveyed in the element content.  The permitted values are
      shown below.  The default value is "hour"."
To:
"   duration
      Optional.  ENUM.  Defines a unit of time, that when combined with
      the metric attribute, fully describes a metric of impact that will
      be conveyed in the element content.  The permitted values are
      shown below.  The default value is "hour"."

#13, Section 3.10.3, MonetaryImpact Class: "currency" attribute is inconsistent with the schema and the definition is updated as follows to correct the issue.
Change from:
"   currency
      Required.  STRING.  Defines the currency in which the monetary
      impact is expressed.  The permitted values are defined in ISO
      4217:2001, Codes for the representation of currencies and funds
      [14].  There is no default value."
To:
"   currency
      Optional.  STRING.  Defines the currency in which the monetary
      impact is expressed.  The permitted values are defined in ISO
      4217:2001, Codes for the representation of currencies and funds
      [14].  There is no default value."



#14, Section 3.10.4 Confidence Class needs a definition for the enumeration value of "unknown" to be consistent with the schema.
Change from:
"   rating
      Required.  ENUM.  A rating of the analytical validity of the
      specified Assessment.  The permitted values are shown below.
      There is no default value.

      1.  low.  Low confidence in the validity.

      2.  medium.  Medium confidence in the validity.

      3.  high.  High confidence in the validity.

      4.  numeric.  The element content contains a number that conveys
          the confidence of the data.  The semantics of this number
          outside the scope of this specification."
To:
"   rating
      Required.  ENUM.  A rating of the analytical validity of the
      specified Assessment.  The permitted values are shown below.
      There is no default value.

      1.  low.  Low confidence in the validity.

      2.  medium.  Medium confidence in the validity.

      3.  high.  High confidence in the validity.

      4.  numeric.  The element content contains a number that conveys
          the confidence of the data.  The semantics of this number
          outside the scope of this specification.

      5. unknown.  The confidence rating value is not known."

#15, Section 3.12, in the EventData Class, the "restriction" attribute includes a default value of "default" in the schema.  As such, the specification definition is updated as follows.
Change from:
"   restriction
      Optional.  ENUM.  This attribute is defined in Section 3.2."
To:
"   restriction
      Optional.  ENUM.  This attribute is defined in Section 3.2.
      The default value is "default".

#16, Section 3.15 System Class requires an update to the specification description to match the UML and schema definition for the Operating System" element as follows.
Change from:
"   OperatingSystem
      Zero or one.  The operating system running on the system."
To:
"   OperatingSystem
      Zero or more.  The operating system running on the system."

#17, Section 3.15, in the System Class, the attribute "category" is listed in the schema as Optional, so the definition in the specification requires updating as follows.
Change from:
"   category
      Required.  ENUM.  Classifies the role the host or network played
      in the incident.  The possible values are:"
To:
"   category
      Optional.  ENUM.  Classifies the role the host or network played
      in the incident.  The possible values are:"

For #18, Section 3.16.2, in the Address Class, the attribute "category" is listed in the schema as Optional, so the definition in the specification requires updating as follows.
Change from:
"   category
      Required.  ENUM.  Classifies the role the host or network played
      in the incident.  The possible values are:"
To:
"   category
      Optional.  ENUM.  Classifies the role the host or network played
      in the incident.  The possible values are:"

For #19, Section 3.16.3, NodeRole Class leverages the schema definition for MLStringType to include the "lang" attribute.  The MLStringType has this attribute as Optional.  The specification definition is updated as follows to correct the issue.
Change from: 
"   lang
      Required.  ENUM.  A valid language code per RFC 4646 [7]
      constrained by the definition of "xs:language".  The
      interpretation of this code is described in Section 6."
To:
"   lang
      Optional.  ENUM.  A valid language code per RFC 4646 [7]
      constrained by the definition of "xs:language".  The
      interpretation of this code is described in Section 6."


#20, Section 3.17 the Service Class attribute of "Application" specification description does not match the UML or schema.  The following update corrects the issue.
Change from:
"   Application
      Zero or more.  The application bound to the specified Port or
      Portlist."
To:
"   Application
      Zero or one.  The application bound to the specified Port or
      Portlist."

#21, Section 3.17 Service Class, the UML diagram and text does not match the schema for the ProtoField element.
Change from:
"   ProtoFlags
      Zero or one.  INTEGER.  A layer-4 protocol specific flag field."
To:
"   ProtoField
      Zero or one.  INTEGER.  A layer-4 protocol specific flag field."
AND update the UML diagram from:
"  +---------------------+
   | Service             |
   +---------------------+
   | INTEGER ip_protocol |<>--{0..1}--[ Port        ]
   |                     |<>--{0..1}--[ Portlist    ]
   |                     |<>--{0..1}--[ ProtoCode   ]
   |                     |<>--{0..1}--[ ProtoType   ]
   |                     |<>--{0..1}--[ ProtoFlags  ]
   |                     |<>--{0..1}--[ Application ]
   +---------------------+

                       Figure 31: The Service Class"
To:
"  +---------------------+
   | Service             |
   +---------------------+
   | INTEGER ip_protocol |<>--{0..1}--[ Port        ]
   |                     |<>--{0..1}--[ Portlist    ]
   |                     |<>--{0..1}--[ ProtoCode   ]
   |                     |<>--{0..1}--[ ProtoType   ]
   |                     |<>--{0..1}--[ ProtoField  ]
   |                     |<>--{0..1}--[ Application ]
   +---------------------+

                       Figure 31: The Service Class"

#22, Section 3.19.1 RecordData Class: the AdditionalData element's specification definition does not match the UML diagram or the schema and is updated as follows to correct the issue.
Change from:
"   AdditionalData
      Zero or one.  An extension mechanism for data not explicitly
      represented in the data model."
To:
"   AdditionalData
      Zero or more.  An extension mechanism for data not explicitly
      represented in the data model."

#23, Section 3.19.2, page 53: the definition of offsetunit should be changed to match the schema from:
"   offsetunit
      Optional.  ENUM.  Describes the units of the offset attribute.
      The default is "line".

      1.  line.  Offset is a count of lines.

      2.  binary.  Offset is a count of bytes.

      3.  ext-value.  An escape value used to extend this attribute.
          See Section 5.1."

To:

"   offsetunit
      Optional.  ENUM.  Describes the units of the offset attribute.
      The default is "line".

      1.  line.  Offset is a count of lines.

      2.  byte.  Offset is a count of bytes.

      3.  ext-value.  An escape value used to extend this attribute.
          See Section 5.1."

#24, Section 3.17.1 Application Class: for the definition for "swid", add "default="0"" to the definition to match the schema.  
Change from:
"    swid
      Optional.  STRING.  An identifier that can be used to reference
      this software."

To:
"   swid
      Optional.  STRING.  An identifier that can be used to reference
      this software, where the default value is "0"."


#25, Section 3.17.1 Application Class: the definition for the attribute "configid" requires updating to include a default value as is included in the schema.  
Change from:
"   configid
      Optional.  STRING.  An identifier that can be used to reference a
      particular configuration of this software."
To:
"   configid
      Optional.  STRING.  An identifier that can be used to reference a
      particular configuration of this software, where the default value is "0"."

Notes:

In each of the listed corrections, the schema is preferred as correct wherever possible for the updates provided. The assumption is that most existing implementations would have preferred the schema definition over the text descriptions or UML diagrams.

SPT: I removed #8 because it's a schema change and edited #17 at the request of the submitters.

RFC 5080, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", December 2007

Source of RFC: radext (sec)

Errata ID: 4623
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alan DeKok
Date Reported: 2016-02-22
Held for Document Update by: Benoit Claise
Date Held: 2016-05-18

Section 2.2.1 says:

   For Accounting-Request packets, the default values for MRC, MRD, and
   MRT SHOULD be zero.  These settings will enable a RADIUS client to
   continue sending accounting requests to a RADIUS server until the
   request is acknowledged.  If any of MRC, MRD, or MRT are non-zero,
   then the accounting information could potentially be discarded
   without being recorded.

It should say:

   For Accounting-Request packets, the default values for MRC, MRD, and
   MRT SHOULD be zero.  These settings will enable a RADIUS client to
   continue sending accounting requests to a RADIUS server until the
   request is acknowledged.  If any of MRC, MRD, or MRT are non-zero,
   then the accounting information could potentially be discarded
   without being recorded.

  This retransmission behavior can be modified for Accounting-Request 
  packets containing Acct-Status-Type of Interim-Update.  A 
  "retransmission" MAY include updated statistics, but will otherwise be
  treated as a retransmission of the original packet, with timers as 
  described above.  Such an updated packet MUST set Acct-Delay-Time 
  (if present) to zero, and Event-Timestamp (if present) to the current
  time.  These changes indicate that the statistics contained in the 
  packet are new, and were not previously sent.

  When the NAS sends periodic Accounting-Request packets containing 
  Acct-Status-Type of Interim-Update, the NAS SHOULD NOT continue to
  retransmit an old Accounting-Request packet when it is time to send a
  new one.  The old packet SHOULD be discarded, and the new one sent
  in its place.

  The alternative is for a NAS to send a new Accounting-Request
  packet while it still is trying to send an old one.  This situation
  could lead to the NAS sending multiple Accounting-Request packets
  simultaneously for the same session, leading to congestive collapse
  of the network.

Notes:

- if we're retransmitting an Accounting-Request packet, it should be acceptable
to update the statistics in it.

- i.e. there should not be a requirement that the content remain the same. The
Acct-Delay-Time attribute is changing, so why not other things, too?

- And MRT of zero for Accounting-Request packet SHOULD NOT mean that the
NAS starts a new retransmission timer every 5 minutes.

- e.g. if the server is down for 20 minutes, the NAS should have *one*
Accounting-Status packet in it's retransmit queue. Not 4.

RFC 5084, "Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)", November 2007

Source of RFC: smime (sec)

Errata ID: 4727
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Peter Dettman
Date Reported: 2016-07-01
Held for Document Update by: Stephen Farrell
Date Held: 2016-07-01

Section 3.2 says:

   The AES-GCM authenticated encryption algorithm is described in [GCM].
   A brief summary of the properties of AES-CCM is provided in Section
   1.5.

It should say:

   The AES-GCM authenticated encryption algorithm is described in [GCM].
   A brief summary of the properties of AES-GCM is provided in Section
   1.5.

Notes:

Section 3.2 discusses AES-GCM, and links to Section 1.5 (titled "AES-GCM"), so the text "AES-CCM" in the second sentence should be "AES-GCM".

RFC 5087, "Time Division Multiplexing over IP (TDMoIP)", December 2007

Source of RFC: pwe3 (int)

Errata ID: 1212
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-03
Held for Document Update by: Stewart Bryant

Section 4.3 says:

   Protocol  (8 bits) is the IP protocol field.  It must be set to 0x73
      (115), the user port number that has been assigned to L2TP by
      IANA.

It should say:

   Protocol  (8 bits) is the IP protocol field.  It must be set to 0x73
|     (115), the protocol number that has been assigned to L2TP by
      IANA.
                 ^^^^^^^^

Notes:

Near the bottom of page 14, the explanations belo Figure 5
confuse the terms "port number" and "protocol". Sigh!

Errata ID: 1214
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-03
Held for Document Update by: Stewart Bryant

Section 4.4 says:

   Rows 1 through 6 are the (DIX) Ethernet header; for 802.3 there may
   be additional fields, depending on the value of the length field, see
   [IEEE802.3].  Fields not previously described will now be explained.

It should say:

|  Rows 1 through 5 are the (DIX) Ethernet header; for 802.3 there may
   be additional fields, depending on the value of the length field, see
   [IEEE802.3].  Fields not previously described will now be explained.

Notes:

On page 16, the explanation immediately below Figure 6 gives the wrong
number of rows (6) -- it should be 5 !

Errata ID: 1210
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-03
Held for Document Update by: Stewart Bryant

Section 1, 2nd para says:

           [...].  In contrast to SAToP, structure-aware methods such as
   TDMoIP ensure the integrity of TDM structure and thus enable the PW
   to better withstand network degradations.  [...]

It should say:

           [...].  In contrast to SAToP, structure-aware methods such as
   TDMoIP ensure the integrity of the TDM structure and thus enable the
   PW to better withstand network degradations.  [...]

Notes:

Missing article.

Errata ID: 1211
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-03
Held for Document Update by: Stewart Bryant

Section 2, 6th para says:

   When structure-aware TDM transport is employed, it is possible to
   explicitly safeguard TDM structure during transport over the PSN,
   thus making possible to effectively conceal packet loss events.

It should say:

   When structure-aware TDM transport is employed, it is possible to
|  explicitly safeguard the TDM structure during transport over the PSN,
   thus making possible to effectively conceal packet loss events.

Notes:

Missing article.

Errata ID: 1213
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-03
Held for Document Update by: Stewart Bryant
Date Held: 2011-08-04

Section 4.4, 3rd p. says:

   Ethernet encapsulation introduces restrictions on both minimum and
   maximum packet size.  Whenever the entire TDMoIP packet is less than
   64 bytes, padding is introduced and the true length indicated by
   using the Length field in the control word.  In order to avoid
   fragmentation, the TDMoIP packet MUST be restricted to the maximum
   payload size.  For example, the length of the Ethernet payload for a
   UDP/IP encapsulation of AAL1 format payload with 30 PDUs per packet
   is 1472 bytes, which falls below the maximal permitted payload size
   of 1500 bytes.

It should say:

   Ethernet encapsulation introduces restrictions on both minimum and
   maximum packet size.  Whenever the entire TDMoIP packet is less than
   64 bytes, padding is introduced and the true length indicated by
   using the Length field in the control word.  In order to avoid
   fragmentation, the TDMoIP packet MUST be restricted to the maximum
   payload size.  For example, the length of the Ethernet payload for a
|  UDP/IP encapsulation of the AAL1 format payload with 30 PDUs per packet
   is 1472 bytes, which falls below the maximal permitted payload size
   of 1500 bytes.

Errata ID: 1216
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-03
Held for Document Update by: Stewart Bryant

Section 6, 10th para says:

a)
     ... trail terminated scenario ...
 

b)

     ... trail extended scenario ...

It should say:

a)
     ... trail-terminated scenario ...
 

b)

     ... trail-extended scenario ...

Notes:

Two missing hyphens.

Errata ID: 1217
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-03
Held for Document Update by: Stewart Bryant

Section 6, 11th para says:

   The final possibility is that of a unidirectional defect in the PSN.
   In such a case, TDMoIP IWF1 sends packets toward IWF2, but these are
   not received.  [...]

It should say:

   The final possibility is that of a unidirectional defect in the PSN.
|  In such a case, the TDMoIP IWF1 sends packets toward IWF2, but these 
   are not received.  [...]

Notes:

Missing article.

Errata ID: 1218
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-03
Held for Document Update by: Stewart Bryant

Section 6, 12th para says:

   [...]
   Since TDM PWs are inherently bidirectional, a persistent defect in 
|  either directional results in a bidirectional service failure.  [...]   
                   ^^

It should say:

   [...]
   Since TDM PWs are inherently bidirectional, a persistent defect in
 | either direction results in a bidirectional service failure.  [...]

Notes:

Typo/grammar.

Errata ID: 1222
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-03
Held for Document Update by: Stewart Bryant

Section App. B says:

   When the TDM circuit is channelized according to [G704], and in
   particular when it is desired to fractional E1 or T1, it is
   advantageous to use one of the structured AAL1 circuit emulation
   services.  [...]

It should say:

   When the TDM circuit is channelized according to [G704], and in
 | particular when it is desired to transport fractional E1 or T1, it is
   advantageous to use one of the structured AAL1 circuit emulation
   services.  [...]

Notes:

In the first paragraph on page 33, the verb "transport" (or similar)
is missing.

Errata ID: 1223
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-03
Held for Document Update by: Stewart Bryant

Section App. C says:

   CID  (8 bits) channel identifier is an identifier that must be unique
      for the PW.  The values 0-7 are reserved for special purposes,
      (and if interworking with VoDSL is required, so are values 8
      through 15 as specified in [LES]), thus leaving 248 (240) CIDs per
      PW.  The mapping of CID values to channels MAY be manually
      configured manually or signaled.

It should say:

   CID  (8 bits) channel identifier is an identifier that must be unique
      for the PW.  The values 0-7 are reserved for special purposes,
      (and if interworking with VoDSL is required, so are values 8
      through 15 as specified in [LES]), thus leaving 248 (240) CIDs per
 |    PW.  The mapping of CID values to channels MAY be configured 
      manually or signaled.

Notes:

Replication of "manually" fixed.

Errata ID: 1224
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-03
Held for Document Update by: Stewart Bryant

Section Norm. Ref's says:

   [RFC2119]     Bradner, S., "Key Words in RFCs to Indicate Requirement
                 Levels", RFC 2119, March 1997.

It should say:

   [RFC2119]     Bradner, S., "Key Words in RFCs to Indicate Requirement
|                Levels", BCP 14, RFC 2119, March 1997.
                          ^^^^^^^^

Notes:

The "BCP14, " tag for RFC 2119 is missing.

RFC 5088, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", January 2008

Note: This RFC has been updated by RFC 9353

Source of RFC: pce (rtg)

Errata ID: 1264
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-13
Held for Document Update by: Adrian Farrel

Section 2 (p.4/bot.) says:

   TLV: Type-Length-Variable data encoding.

It should say:

   TLV: Type-Length-Value data encoding.

Notes:

Wrong expansion of acronym;
cf. RFC 4940 and RFC-Ed. file "abbrev.expansion.txt"

Errata ID: 1267
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-13
Held for Document Update by: Adrian Farrel

Section 9.6, line 1 says:

         ... PCED TLV, may have ...

It should say:

         ... PCED TLV may have ...

Notes:

Spurious comma, distorting the grammar.

>>> This issue is not present in the equivalent text of
RFC 5089, which has been published together with this RFC.

This report is primarily intended as a kind of quality control feedback.

Another typographical flaw of similar 'severity' appears in Section 11.2,
where punctuation has been orphaned into the 3rd line of the '[PCEP]'
entry:

[PCEP] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path
Computation Element (PCE) communication Protocol (PCEP)
| ", Work in Progress, November 2007.
^^

>>> This latter issue also is present in RFC 5089.
and perhaps does not deserve

RFC 5089, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", January 2008

Note: This RFC has been updated by RFC 9353

Source of RFC: pce (rtg)

Errata ID: 1265
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-13
Held for Document Update by: Adrian Farrel

Section 2 (p.4 bot.) says:

   TLV: Type-Length-Variable data encoding.

It should say:

   TLV: Type-Length-Value data encoding.

Notes:

Wrong expansion of acronym;
cf. RFC 3359 and RFC-Ed. file "abbrev.expansion.txt".

Errata ID: 1268
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-13
Held for Document Update by: Adrian Farrel

Section 4.2 mid-p.8 says:

   Pref-Y field: PCE's preference for inter-layer TE LSP computation.
       ^^

It should say:

   PrefY field: PCE's preference for inter-layer TE LSP computation.
       ^

Notes:

May be confusing.

Restore consistency with artwork on the same page as well as subsequent
text (and RFC 5088 as well).


Further minor typographical flaws in this RFC,
noted here for quality control purposes:

a) Section 4.2, 2nd paragraph:
... more than once only ...
should be
... more than once, only ...
(as in RFC 5088);

b) Section 9.1: missing white space after the5 bullets (dash characters),
cf. RFC 5088;

c) Section 11.2: orphaned punctuation in '[PCEP]' entry --
cf. footnote in Editorial Errata Report for RFC 5088.

RFC 5090, "RADIUS Extension for Digest Authentication", February 2008

Source of RFC: radext (sec)

Errata ID: 1326
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-02-17
Held for Document Update by: Dan Romascanu

Throughout the document, when it says:

a)       header

b)       headers

c)       Header

It should say:

a)       header field

b)       header fields

c)       Header Field

Notes:

As a Standards Track document, RFC 5090 should use established
IETF standard terminology, and not fall back to common sluggish
and confusing terminology. Concise Ref.: RFC 4249, Section 3.1.1.

There are 24 instances of case a) throughout the RFC;
only Section 3.20 makes proper use of the IETF standard
terminology; case b) occurs twice in the RFC;
case c) applies to the title of Section 2.1.3.

RFC 5091, "Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems", December 2007

Note: This RFC has been updated by RFC 8996

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 2737
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: David Núñez (University of Málaga)
Date Reported: 2011-02-27
Held for Document Update by: Sean Turner

Section 5.1.2 says:

Method:
...
2. ...
(a) If n = 1024, then let n_p = 512, n_q = 160, hashfcn =
          1.3.14.3.2.26 (SHA-1 [SHA]

It should say:

(a) If n = 1024, then let n_p = 512, n_q = 160, hashfcn =
          1.3.14.3.2.26 (SHA-1 [SHA])

Notes:

There is a missing ')'. The same typo occurs in first line of page 40.

RFC 5092, "IMAP URL Scheme", November 2007

Note: This RFC has been updated by RFC 5593

Source of RFC: lemonade (app)

Errata ID: 2699
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-02-01
Held for Document Update by: Alexey Melnikov

Section 13.2 says:

[URI-REG]    Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
             Registration Procedures for New URI Schemes", BCP 115,
             RFC 4395, February 2006.

It should say:

[URI-REG]    Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
             Registration Procedures for New URI Schemes", BCP 35,
             RFC 4395, February 2006.

Notes:

RFC 4395 is not BCP 115, but BCP 35.

Errata ID: 2802
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-05-08
Held for Document Update by: Pete Resnick

Throughout the document, when it says:

imap: URI scheme

It should say:

'imap' URI Scheme

Notes:

The ":" (colon) character is not a part of URI scheme name. RFC 3986 says:

URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )

i. e. ":" is a delimiter between scheme name and the remainder of URI.

Errata ID: 2846
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-06-28
Held for Document Update by: Peter Saint-Andre

Section 11 says:

   ipath-empty     = 0<pchar>
                    ; Zero characters.
                    ; The same-document reference.

It should say:

   ipath-empty     = ""
                    ; Zero characters.
                    ; The same-document reference.

Notes:

Copying Erratum report #2033 for RFC 3986 by Tanaka Akira. "0<foo>" assumes "foo" is <pros-val> of RFC 5234, which it isn't. Given this should identify null string, "" is appropriate, in my opinion.

RFC 5098, "Signaling MIB for PacketCable and IPCablecom Multimedia Terminal Adapters (MTAs)", February 2008

Note: This RFC has been updated by RFC 9141

Source of RFC: ipcdn (ops)

Errata ID: 1347
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-04
Held for Document Update by: Dan Romascanu

Section 5, pg.12 says:

  pktcSigDevCodecTable OBJECT-TYPE
     ...
     DESCRIPTION
        " ...

          Codec Type     Maximum Number of Simultaneous Codecs
          PCMA                             3

          PCMA                             2
          PCMU                             1

          PCMA                             1
|
          PCMU                             2

          PCMU                             3

          PCMA                             1
          G729                             1

          G729                             2

          PCMU                             1
          G729                             1

It should say:

  pktcSigDevCodecTable OBJECT-TYPE
     ...
     DESCRIPTION
        " ...

          Codec Type     Maximum Number of Simultaneous Codecs
|
          PCMA                             3

          PCMA                             2
          PCMU                             1

          PCMA                             1
          PCMU                             2

          PCMU                             3

          PCMA                             1
          G729                             1

          G729                             2

          PCMU                             1
          G729                             1

Notes:

Issue: Spurious blank line distorts grouping of example
line and turns example ineffective.
Correction: Delete the spurious line, but add a blank line
after the headline, for clarity.

Errata ID: 1348
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-04
Held for Document Update by: Dan Romascanu

Section 5, pg.20 says:

  pktcSigCapabilityVendorExt      OBJECT-TYPE
     ...
     DESCRIPTION
        " The vendor extension allows vendors to provide a list of
          additional capabilities.

          The syntax for this MIB object in ABNF ([RFC5234]) is
          specified to be zero or more occurrences of vendor
          extensions, as follows:

           pktcSigCapabilityVendorExt  = *(vendor-extension)
|          vendor-extension = (ext symbol alphanum) DQUOTE ; DQUOTE
|          ext      = DQUOTE %x58 DQUOTE
|          symbol   = (DQUOTE %x2D DQUOTE)/(DQUOTE %x2D DQUOTE)
           alphanum = 1*6(ALPHA/DIGIT)

         "

It should say:

  pktcSigCapabilityVendorExt      OBJECT-TYPE
     ...
     DESCRIPTION
        " The vendor extension allows vendors to provide a list of
          additional capabilities.

          The syntax for this MIB object in ABNF ([RFC5234]) is
          specified to be zero or more occurrences of vendor
          extensions, as follows:

           pktcSigCapabilityVendorExt  = *(vendor-extension)
|          vendor-extension = ext symbol alphanum ";" 
|          ext      = %x58               ; uppercase only X
|          symbol   = %x2B / %x2D        ; + or -
           alphanum = 1*6(ALPHA/DIGIT)

         "

Notes:

Symptom: ABNF grossly nonsensical:
ABNF comment '; DQUOTE' perhaps intended as non-comment;
all DQUOTEs apparently should be removed;
two identical alternatives for symbol do not make sense.

Correction is based on earlier draft versions, applying the
corrections necessary to obtain valid ABNF, yet specifying
what probably was intended.

Alternatively, the following line might be substituted above:

| symbol = "+" / "-"

Errata ID: 1349
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-04
Held for Document Update by: Dan Romascanu

Section 5,pg.31-33 says:

-

It should say:

         osi                             any value  (not used)

Notes:

Incomplete specification:

The line given as 'corrected text' is missing from the tabular
listings of all (other) cases possible, in the DESCRIPTION clauses
of the following three scalar MIB objects, on pp.31-33 of the RFC:

pktcSigDevVmwiAfterDTAS
pktcSigDevVmwiAfterRPAS
pktcSigDevVmwiDTASAfterLR

RFC 5101, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", January 2008

Note: This RFC has been obsoleted by RFC 7011

Source of RFC: ipfix (ops)

Errata ID: 2761
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-04-01
Held for Document Update by: ron bonica

Section 8 says:

   If the measurement parameters change such that a new Template is
   required, the Template MUST be withdrawn (using a Template Withdraw
   Message

It should say:

   If the measurement parameters change such that a new Template is
   required, the Template MUST be withdrawn (using a Template Withdrawal
   Message

Notes:

correct "Template Withdraw Message" to "Template Withdrawal Message" per figure T and the rest of the document.

Errata ID: 2762
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-04-01
Held for Document Update by: ron bonica

Section 8 says:

   If the Metering Process restarts, the Exporting Process MUST either
   reuse the previously assigned Template ID for each Template, or it
   MUST withdraw the previously issued Template IDs by sending Template
   Withdraw Message(s) before reusing them.

It should say:

   If the Metering Process restarts, the Exporting Process MUST either
   reuse the previously assigned Template ID for each Template, or it
   MUST withdraw the previously issued Template IDs by sending Template
   Withdrawal Message(s) before reusing them.

Notes:

Correct "Template Withdraw Message" to "Template Withdrawal Message" per figure T and the rest of the document.

Errata ID: 2763
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-04-01
Held for Document Update by: ron bonica

Section 9 says:

   If the Collecting Process receives a Template Withdraw message

It should say:

   If the Collecting Process receives a Template Withdrawal message

Notes:

Correct "Template Withdraw Message" to "Template Withdrawal Message" per figure T and the rest of the document.

Errata ID: 2764
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-04-01
Held for Document Update by: ron bonica

Section 10.3.6 says:

   If UDP is selected as the transport protocol, the Template Withdraw
   Messages MUST NOT be used, as this method is inefficient due to the
   unreliable nature of UDP.

It should say:

   If UDP is selected as the transport protocol, the Template Withdrawal
   Messages MUST NOT be used, as this method is inefficient due to the
   unreliable nature of UDP.

Notes:

Correct "Template Withdraw Message" to "Template Withdrawal Message" per figure T and the rest of the document.

Errata ID: 2852
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-07-03
Held for Document Update by: Dan Romascanu

Section Figure O says:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Scope N Field Length      |   Scope N Enterprise Number ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ...  Scope N Enterprise Number   |1| Option 1 Infor. Element Id. |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Option 1 Field Length      |  Option 1 Enterprise Number ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ... Option 1 Enterprise Number   |              ...              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Scope N Field Length      |   Scope N Enterprise Number  ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ...  Scope N Enterprise Number   |1| Option 1 Infor. Element Id. |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Option 1 Field Length      |  Option 1 Enterprise Number  ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ... Option 1 Enterprise Number   |              ...              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

Notice that the rows don't line up properly. I think this is because the ellipsis were supposed to overlap the edges. Compare with the diagram in A.4.3.

Perhaps the ellipsis in the figure in section A.4.2 could also be modified for consistency.

Errata ID: 2857
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-07-11
Held for Document Update by: Dan Romascanu

Section 6.2, 4th par says:

If reduced sizing is used,

It should say:

If reduced size encoding is used,

Notes:

s/reduced sizing/reduced size encoding/

Another instance also in this section: "Reduced sizing can also be used".

RFC 5102, "Information Model for IP Flow Information Export", January 2008

Note: This RFC has been obsoleted by RFC 7012

Note: This RFC has been updated by RFC 6313

Source of RFC: ipfix (ops)

Errata ID: 3101
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2012-01-31
Held for Document Update by: ron bonica

Section 5.9. says:

   Timestamps flowStartSysUpTime and flowEndSysUpTime are relative
   timestamps indicating the time relative to the last (re-
   )initialization of the IPFIX Device.  For reporting the time of the
   last (re-)initialization, systemInitTimeMilliseconds can be reported,
   for example, in Data Records defined by Option Templates.

It should say:

   Timestamps flowStartSysUpTime and flowEndSysUpTime are relative
   timestamps indicating the time relative to the last
   (re-)initialization of the IPFIX Device.  For reporting the time of the
   last (re-)initialization, systemInitTimeMilliseconds can be reported,
   for example, in Data Records defined by Option Templates.

Notes:

Poor formatting of "(re-)initialization" in the 3rd paragraph of section 5.9

RFC 5106, "The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method", February 2008

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 1342
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-03
Held for Document Update by: Sean Turner

Section 8.1 says:

Last paragraph on page 17:

         [...].  The Message Length field is four octets long and
   contains the length of the entire message (i.e., the length of the
   EAP Data field.).  Note that, in contrast, the Length field shown in
   ^^^^^^^^^^^^^^
   Figure 4 contains the length of only the current fragment.  [...]

Second-to-last paragraph on page 18:

   The Integrity Checksum Data field contains a cryptographic checksum
   that covers the entire EAP message, starting with the Code field, and
|  ending at the end of the EAP Data field.  This field, shown in Figure
                        ^^^^^^^^^^^^^^^^^^
   4, is present only if the I bit is set in the Flags field.  The
   Integrity Checksum Data field immediately follows the EAP Data field
   without padding.

Notes:

The above text is ambiguous and confusing, because the
"EAP Data field" is neither shown in Figure 4 nor
introduced in the text of Sections 8 / 8.1.

From the text snippits above, it remains unclear in particular
whether or not the "Integrity Checksum Data" field is considered
part of the "EAP Data field".
According to the EAP base specification, the former should be
expected, but the text contains no provisions for presetting
that field when calculating the ICV; thus it might be concluded
that the latter was intended.

Please clarify!

Errata ID: 1336
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-03
Held for Document Update by: Sean Turner

Section 4.,4th para says:

   ... by other severs ...

It should say:

   ... by other servers ...
                  ^

Errata ID: 1337
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-03
Held for Document Update by: Sean Turner
Date Held: 2010-07-30

Section 6.,2nd para says:

   o  The Session-ID is constructed and exported as the concatenation of
|     the following three elements, in this order: (a) the EAP Code Type
|     for EAP-IKEv2 (to be defined by IANA), (b) the contents of the
      Nonce Data field of the Nonce Payload Ni from message 3, (c) the
      contents of the Nonce Data field of the Nonce Payload Nr from
      message 4.

It should say:

   o  The Session-ID is constructed and exported as the concatenation of
|     the following three elements, in this order: (a) the EAP Method 
|     Type for EAP-IKEv2 (49, as assigned by IANA), (b) the contents of
      the Nonce Data field of the Nonce Payload Ni from message 3, (c)
      the contents of the Nonce Data field of the Nonce Payload Nr from
      message 4.

Notes:

Rationale:
a) "EAP Code Type" is confusing; the correct term is
"EAP Methode Type".
b) The code point indeed had been allocated by IANA on publication
of the RFC; the text should be explicit, for the ease of its readers.

Errata ID: 1340
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-03
Held for Document Update by: Sean Turner

Section 7, pg.15 says:

|  o  The packet contains an Integrity Checksum Data field (see *Figure
      4) that is incorrect.
                                                                ^

It should say:

|  o  The packet contains an Integrity Checksum Data field (see Figure
      4) that is incorrect.

Notes:

Location is third bullet on page 15.

Errata ID: 1341
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-03
Held for Document Update by: Sean Turner

Section 8, last para says:

    ...  processed in way ...

It should say:

    ...  processed in a way ...

Errata ID: 1343
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-03
Held for Document Update by: Sean Turner

Section 8.10,last pa says:

   ... in the context EAP-IKEv2 ...

It should say:

   ... in the context of EAP-IKEv2 ...

Notes:

Location is 3rd-to-last line of last paragraph of the section.

Errata ID: 1344
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-03
Held for Document Update by: Sean Turner

Section A.,last para says:

   The difference in the full successful exchange ...

It should say:

   The difference from the full successful exchange ...

RFC 5109, "RTP Payload Format for Generic Forward Error Correction", December 2007

Source of RFC: avt (rai)

Errata ID: 1225
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Adam Li
Date Reported: 2008-01-03
Held for Document Update by: Robert Sparks

Section 1 says:

In the 2nd Paragraph

... signaled by different MIMEs from those of RFC 3009, ...
             ^^^^^^^^^^^^^^^^^^

It should say:

... signaled as a media type different from those of RFC 3009, ...
             ^^^^^^^^^^^^^^^^^^^^^^^^^

Errata ID: 1227
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Adam Li
Date Reported: 2008-01-03
Held for Document Update by: Robert Sparks

Section 9.2 says:

In Step 7,

      7.  The total length of the recovered media packet is recovered
          from the recovery operation at protection level 0 of the
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
          recovered media packet.  This information can be used to check
          ^^^^^^^^^^^^^^^^^^^^^^
          if the complete recovery operation (of all levels) has
          recovered the packet to its full length.

It should say:

      7.  The total length of the recovered media packet is recovered
          during the reconstruction of the RTP header (Step 13 in 
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
          Section 9.1).  This information can be used to check
          ^^^^^^^^^^^^
          if the complete recovery operation (of all levels) has
          recovered the packet to its full length.

Errata ID: 1228
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Adam Li
Date Reported: 2008-01-03
Held for Document Update by: Robert Sparks

Section 10.3 says:

In Figure 18,

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 RTP Header (RED) - 6 octets                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 RTP Header (RED) - 12 octets                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Errata ID: 1229
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Adam Li
Date Reported: 2008-01-03
Held for Document Update by: Robert Sparks

Section 10.3 says:

In Figure 21,

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 RTP Header (RED) - 6 octets                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 RTP Header (RED) - 12 octets                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Errata ID: 1230
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Adam Li
Date Reported: 2008-01-03
Held for Document Update by: Robert Sparks

Section 10.3 says:

In Figure 21,

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 RTP Header (RED) - 6 octets                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Redundant Encoding Block Header (RED) - 4 octets        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        FEC Packet Data                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Primary Encoding Block Header (RED) - 1 octet          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Media Packet Data                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 RTP Header (RED) - 12 octets                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Redundant Encoding Block Header (RED) - 4 octets        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Primary Encoding Block Header (RED) - 1 octet          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        FEC Packet Data                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Media Packet Data                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

- The RTP Header should be 12 octets instead of 6 octets.
- The Primary Encoding Block Header (RED) should appear before the FEC Packet Data.

Errata ID: 3460
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Adam Li
Date Reported: 2013-01-16
Held for Document Update by: Gonzalo Camarillo

Section 10.2 says:

In Figure 12,

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|0|0|0 0 0 0|0|0 0 1 1 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ....

      P rec.:    0     [0 XOR 0 XOR 0 XOR 0]
      X rec.:    0     [0 XOR 0 XOR 0 XOR 0]
      CC rec.:   0     [0 XOR 0 XOR 0 XOR 0]
      M rec.:    0     [1 XOR 0 XOR 1 XOR 0]

It should say:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|0|0|0 0 0 0|1|0 0 1 1 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ....

      P rec.:    0     [0 XOR 0]
      X rec.:    0     [0 XOR 0]
      CC rec.:   0     [0 XOR 0]
      M rec.:    1     [1 XOR 0]

Notes:

These fields (P rec., X rec., CC rec., and M rec.) should be calculated from the packets that are protected at Level 0 (as specified). The specification text in previous sections are all correct. This change here is only a typo in the examples, but correcting it helps to understand the specification.

Errata ID: 3461
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Adam Li
Date Reported: 2013-01-16
Held for Document Update by: Gonzalo Camarillo

Section 10.2 says:

In Figure 15,

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|0|0|0 0 0 0|0|0 0 1 1 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ....

      P rec.:    0     [0 XOR 0 XOR 0 XOR 0]
      X rec.:    0     [0 XOR 0 XOR 0 XOR 0]
      CC rec.:   0     [0 XOR 0 XOR 0 XOR 0]
      M rec.:    0     [1 XOR 0 XOR 1 XOR 0]

It should say:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|0|0|0 0 0 0|1|0 0 1 1 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ....

      P rec.:    0     [0 XOR 0]
      X rec.:    0     [0 XOR 0]
      CC rec.:   0     [0 XOR 0]
      M rec.:    1     [1 XOR 0]

Notes:

These fields (P rec., X rec., CC rec., and M rec.) should be calculated from the packets that are protected at Level 0 (as specified). The specification text in previous sections are all correct. This change here is only a typo in the examples, but correcting it helps to understand the specification.

RFC 5115, "Telephony Routing over IP (TRIP) Attribute for Resource Priority", January 2008

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rai

Errata ID: 1358
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-11
Held for Document Update by: Robert Sparks

Section 3, 2nd para says:

   The requirements in [rfc3487] produced the corresponding document
|  [rfc4412] in the SIP working group, which defines a new header for
|  SIP called Resource-Priority.  This new header, which is optional, is
   divided into two parts: a NameSpace and a Value.  [...]

It should say:

   The requirements in [rfc3487] produced the corresponding document
|  [rfc4412] in the SIP working group, which defines a new header field
|  for SIP called Resource-Priority.  This new header field, which is
|  optional, has a field value divided into two parts: a NameSpace and
   a Value.  [...]

Notes:

a) Abuse of language / non-use of established precise terminology:
"header" --> "header field.

This issue recurs twice in Section 3.1 (first and last paragraph).

b) Any header field is divided into two parts, the header field name
and the header field value. Hence, the RFC text is misleading.
Apparently, it wants to indicate that the field value is further
subdivided into two parts.
The proposed correction tries to clarify this with minimal rewording.

Errata ID: 1359
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-11
Held for Document Update by: Robert Sparks

Section 3.1, pg. 3 says:

    ... header ...

It should say:

   ... header field  ...

Notes:

Two occurrences: in the first and the last paragraph of Section 3.1.
For Rationale see NOTES for Errata-ID 1358.

RFC 5117, "RTP Topologies", January 2008

Note: This RFC has been obsoleted by RFC 7667

Source of RFC: avt (rai)

Errata ID: 1312
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-02-13
Held for Document Update by: Cullen Jennings

Section 3.3, 5th par says:

   Stand-alone Media Translators are rare.  Most commonly, a combination
|  of Transport and Media Translators are used to translate both the
   media stream and the transport aspects of a stream between two
   transport domains (or clouds).

It should say:

   Stand-alone Media Translators are rare.  Most commonly, a combination
|  of Transport and Media Translators is used to translate both the
   media stream and the transport aspects of a stream between two
   transport domains (or clouds).

Notes:

"A combination ... *is* used ..." !

Errata ID: 1313
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-02-13
Held for Document Update by: Cullen Jennings

Section 3.3,pg.7 says:

                    [...].  Therefore, if the Receiver Reports were
   forwarded without changes, the extended highest sequence number would
   indicate that B were substantially behind in reception, while it most
|  likely it would not be.  [...]
         ^^^^

It should say:

                    [...].  Therefore, if the Receiver Reports were
   forwarded without changes, the extended highest sequence number would
   indicate that B were substantially behind in reception, while it most
|  likely would not be.  [...]
         ^

Notes:

Spurious word replication; location is 4th-to-last line on page 7.

Errata ID: 1314
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-02-13
Held for Document Update by: Cullen Jennings

Section 3.4, pg.9 says:

         [...].  The CSRC Count (CC) and CSRC fields in the RTP header
|  are used to indicate the contributors of to the newly generated
   stream.  The SSRCs of the to-be-mixed streams on the Mixer input
   appear as the CSRCs at the Mixer output.  That output stream uses a
|  unique SSRC that identifies the Mixer's stream.  The CSRC are
   forwarded between the two domains to allow for loop detection and
   identification of sources that are part of the global session.  [...]

It should say:

         [...].  The CSRC Count (CC) and CSRC fields in the RTP header
|  are used to indicate the contributors to the newly generated
   stream.  The SSRCs of the to-be-mixed streams on the Mixer input
   appear as the CSRCs at the Mixer output.  That output stream uses a
|  unique SSRC that identifies the Mixer's stream.  The CSRCs are
   forwarded between the two domains to allow for loop detection and
   identification of sources that are part of the global session.  [...]

Notes:

Near the bottom of page 9:
a) s/of to/to/
^^^
b) s/The CSRC are/The CSRCs are/
^

Errata ID: 1315
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-02-13
Held for Document Update by: Cullen Jennings

Section 3.4, pg.10 says:

   A Mixer is responsible for receiving RTCP feedback messages and
   handling them appropriately.  The definition of "appropriate" depends
   on the message itself and the context.  In some cases, the reception
   of a codec-control message may result in the generation and
   transmission of RTCP feedback messages by the Mixer to the
|  participants in the other domain.  In other cases, a message is
   handled by the Mixer itself and therefore not forwarded to any other
   domain.

It should say:

   A Mixer is responsible for receiving RTCP feedback messages and
   handling them appropriately.  The definition of "appropriate" depends
   on the message itself and the context.  In some cases, the reception
   of a codec-control message may result in the generation and
   transmission of RTCP feedback messages by the Mixer to the
|  participants in the other domain(s).  In other cases, a message is
   handled by the Mixer itself and therefore not forwarded to any other
   domain.

Notes:

Location is 4th paragraph on page 10.
Rationale: There may be more than one "other" domain;
in particular, this *is* the case in the example discussed
in the text (cf. Figure 5 on page 9).

Errata ID: 1316
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-02-13
Held for Document Update by: Cullen Jennings

Section 4.1.5, p.16 says:

  ... handled correctly in domain bridging function.  [...]

It should say:

Either:

  ... handled correctly in domain bridging functions.  [...]

Or (less preferable):

  ... handled correctly in a domain bridging function.  [...]

RFC 5119, "A Uniform Resource Name (URN) Namespace for the Society of Motion Picture and Television Engineers (SMPTE)", February 2008

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 1324
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-02-16
Held for Document Update by: Alexey Melnikov

Section 2, pg. 5 says:

Rules for Lexical Equivalence:

         Lexical equivalence of URNs in the "urn:smpte:ul" subnamespace
         is defined by case-insensitive string match.

         Lexical equivalence of URNs in additional subnamespaces of
         "urn:smpte:" will be specified by SMPTE in the defining
         document; in the absence of such specification, lexical
         equivalence of URNs in the "urn:smpte:" namespace outside of
|        the "urn:smpte:ul" subnamespace is defined by exact string
|        match, according to [RFC2141].

It should say:

      Rules for Lexical Equivalence:

         Lexical equivalence of URNs in the "urn:smpte:ul" subnamespace
         is defined by case-insensitive string match.

         Lexical equivalence of URNs in additional subnamespaces of
         "urn:smpte:" will be specified by SMPTE in the defining
         document; in the absence of such specification, lexical
         equivalence of URNs in the "urn:smpte:" namespace outside of
         the "urn:smpte:ul" subnamespace is defined by exact string
|        match of the namespace-specific subpart of the URN (denoted
|        <other-NSS> above), according to [RFC2141].

Notes:

The RFC text contradicts RFC 2141.
The above correction restores conformance with RFC 2141.

[[ please remove after verification:
apparently this correction has been lost since LC,
during the application of other updates. ]]

RFC 5121, "Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks", February 2008

Note: This RFC has been updated by RFC 8064

Source of RFC: 16ng (int)

Errata ID: 1768
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Daan Pareit
Date Reported: 2009-04-23
Held for Document Update by: Brian Haberman

Section 6.3 says:

The Len parameter has a size of 11 bits.
Hence, the total MAC PDU size is 2048 bytes.

It should say:

The Len parameter has a size of 11 bits.
Hence, the total MAC PDU size is 2047 bytes.

Notes:

There are 11 bits for indicating the size of the MAC PDU, thus according to me this indicates a maximum size of (binary) 111 1111 1111, which equals (decimal) 2047 (2**11 - 1).
The maximum of 2047 is also cited in the book "Fundamentals of WiMAX" by Jeffrey G. Andrews, Arunabha Ghosh and Rias Muhamed on page 48: "The maximum frame length is 2,047 bytes, which is represented by 11 bits in the GMH."

RFC 5128, "State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs)", March 2008

Source of RFC: behave (tsv)

Errata ID: 1403
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-31
Held for Document Update by: Magnus Westerlund

Section 3.2,last par says:

   A variety of current peer-to-peer applications implement this
   technique.  Its main limitation, of course, is that it only works so
   long as only one of the communicating peers is behind a NAT device.
|  If the NAT device is EIM-NAT, the public client can contact external
|  server S to determine the specific public endpoint from which to
|  expect Client-A-originated connection and allow connections from just
|  those endpoints.  If the NAT device is EIM-NAT, the public client can
   contact the external server S to determine the specific public
   endpoint from which to expect connections originated by client A, and
   allow connections from just that endpoint.  If the NAT device is not
   EIM-NAT, the public client cannot know the specific public endpoint
   from which to expect connections originated by client A.  In the
   increasingly common case where both peers can be behind NATs, the
   Connection Reversal method fails.  [...]

It should say:

   A variety of current peer-to-peer applications implement this
   technique.  Its main limitation, of course, is that it only works so
   long as only one of the communicating peers is behind a NAT device.
   If the NAT device is EIM-NAT, the public client can contact the
   external server S to determine the specific public endpoint from
   which to expect connections originated by client A, and allow
   connections from just that endpoint.  If the NAT device is not
   EIM-NAT, the public client cannot know the specific public endpoint
   from which to expect connections originated by client A.  In the
   increasingly common case where both peers can be behind NATs, the
   Connection Reversal method fails.  [...]

Notes:

Location is mid-page 11.

Rationale and background:

The reporter once had suggested replacement text to improve the
readability of the third and fourth sentence in this paragraph.
These LC comments have been accepted, but inadvertently, the
third original sentence has been left in the text, followed
by its intended replacement.

Note that the similar replacement of the next sentence
("If the NAT device is not ...") has been performed properly.

The above correction removes the original, less legible draft
version of the other sentence.

RFC 5135, "IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT)", February 2008

Source of RFC: behave (tsv)

Errata ID: 1319
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-02-14
Held for Document Update by: Magnus Westerlund

Section 4.1, pg.6 says:

   REQ-7:   The NAT MUST NOT forward Local Network Control Block
|           (224.0.0/24) [RFC3171] (also known as "link-local
            multicast") traffic from its 'inside' interface(s) to its
            'outside' interface.

It should say:

   REQ-7:   The NAT MUST NOT forward Local Network Control Block
|           (224.0.0.0/24) [RFC3171] (also known as "link-local
            multicast") traffic from its 'inside' interface(s) to its
            'outside' interface.

Notes:

Location is end of Section 4.1, near the bottom of page 6.
This correction also needs to be applied to the re-statement
of REQ-7 in Section 5 (mid-page 10).

Rationale:
The basic "strategic" document for CIDR notation now is BCP 122,
RFC 4632, and that document clearly states (in section 3.1, at
the bottom of page 5):
vvvvvvv
| [...] In CIDR notation, a prefix is shown as a 4-octet
quantity, just like a traditional IPv4 address or network number,
followed by the "/" (slash) character, followed by a decimal value
between 0 and 32 that describes the number of significant bits.

Also being a BCP, RFC 5135 should follow this rule.

Errata ID: 1318
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-02-14
Held for Document Update by: Magnus Westerlund

In the Abstract, it says:

   This document specifies requirements for a for a Network Address
   Translator (NAT) and ...

It should say:

   This document specifies requirements for a Network Address
   Translator (NAT) and ...

Notes:

word replication (added in AUTH48!)

Errata ID: 1320
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-02-14
Held for Document Update by: Magnus Westerlund
Date Held: 2008-11-16

Section 4.3, pg.8 says:

   Any Source Multicast (ASM) uses the IP addresses in the 224/8 through
   231/8, and 233/8 through 239/8 range [IANA-ALLOC].

It should say:

   Any Source Multicast (ASM) uses the IP addresses in the 224.0.0.0/8
   through 231.0.0.0/8, and 233.0.0.0/8 through 239.0.0.0/8 range
   [IANA-ALLOC].

Notes:

Rationale: see preceding entry

RFC 5140, "A Telephony Gateway REgistration Protocol (TGREP)", March 2008

Source of RFC: iptel (rai)

Errata ID: 1355
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-11
Held for Document Update by: Robert Sparks

Section 3, pg.7 says:

      - Prefix (Hexadecimal Routing Number): This attribute is used to
        represent the list of Hexadecimal prefixes to which the
        respective route can complete calls.

It should say:

      - Prefix (Pentadecimal Routing Number): This attribute is used to
        represent the list of Pentadecimal prefixes to which the
        respective route can complete calls.

Notes:

There are no *Hexa*decimal Routing Numbers in TRIP or TGREP; but there
are *Penta*decimal Routing Numbers (see RFC 3219, Section 5.1.1.3).
The rest of RFC 5140 never uses "Hexadecimal", only "Pentadecimal".

Errata ID: 1356
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-11
Held for Document Update by: Robert Sparks

Section 4.4.5, pg.13 says:

   The LS receiving this attribute should disseminate to other peers,
   both internal and external to the ITAD.

It should say:

                                                     vvvv
   The LS receiving this attribute should disseminate it to other peers,
   both internal and external to the ITAD.

Notes:

cf. similar subsections of RFC 5140 (4.*.5)

Errata ID: 1357
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-11
Held for Document Update by: Robert Sparks

Section 6.7, pg.20 says:

                                    [...].  TGREP should specify its
   choice address family through the route-type capability in the OPEN
   message.  And route-type specification in the OPEN message violating
   the above rule should be rejected with a NOTIFICATION message.

It should say:

                                    [...].  TGREP should specify its
|  choice of address family through the route-type capability in the
|  OPEN message.  Any route-type specification in the OPEN message
   violating the above rule should be rejected with a NOTIFICATION
   message.

Notes:

a) missing "of"
b) "And" --> "Any"

RFC 5144, "A Domain Availability Check (DCHK) Registry Type for the Internet Registry Information Service (IRIS)", February 2008

Source of RFC: crisp (app)

Errata ID: 1334
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-03
Held for Document Update by: Alexey Melnikov

Section 3.1.1, pg.6 says:

      *  <update> - specifies a general modification of the domain
|        information.  This status is usually be further refined by the
         disposition attribute.
                                             ^^^^

It should say:

      *  <update> - specifies a general modification of the domain
|        information.  This status is usually further refined by the
         disposition attribute.
                                             ^

RFC 5158, "6to4 Reverse DNS Delegation Specification", March 2008

Note: This RFC has been updated by RFC 8996

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: int

Errata ID: 1362
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-11
Held for Document Update by: Brian Haberman

Section 4, pg.7 says:

   This service is implemented by web servers that are operated on a
|  dual-stack IPv4 / IPv6 server, accessible via SSL.  [...]
                                                 ^^^

It should say:

   This service is implemented by web servers that are operated on a
|  dual-stack IPv4 / IPv6 server, accessible via TLS.  [...]

Notes:

Location is top of page 7.

The 4th paragraph of the same section (on page 6) clearly refers
to TLS [RFC4346]. SSL is *not* TLS, it's the predecessor, updated
in the IETF to fix serious security issues detected.

Hence the RFC should consistently refer to "TLS" and not mix in "SSL".

Errata ID: 1360
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-11
Held for Document Update by: Brian Haberman

Section 2.1,1st para says:

                                                 [...].  In the case of
|  the 6to4 mapped IPv6 space, the upstream may not be providing any
   IPv6-based services at all, and therefore would not be expected to
   have a 6to4 reverse DNS delegation for its IPv4 address block.  [...]

It should say:

                                                 [...].  In the case of
|  the 6to4 mapped IPv6 space, the upstream provider may not be providing
   any IPv6-based services at all, and therefore would not be expected to
   have a 6to4 reverse DNS delegation for its IPv4 address block.  [...]

Notes:

Missing noun, "provider".

This note and the subsequent ones repeat the more significant
issues pointed out in review comments sent Aug 21, 2007, which
apparently have been missed (after positive acknowledgement).

Errata ID: 1361
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-11
Held for Document Update by: Brian Haberman

Section 3., pg. 5 says:

   The IPv4 address used as part of the generation of 6to4 addresses for
   the local IPv6 network is that of the external IPv4 network interface
   address (labelled '(A)' in the above diagram).  For example, if the
   interface (A) has the IPv4 address 192.0.2.1, then the local IPv6
   clients will use a common IPv6 address prefix of the form 2002:
|  {192.0.2.1}::/48 (or (2002:C000:201::/48 in hex notation).  All the
                        ^
   local IPv6 clients share this common /48 address prefix, irrespective
   of any local IPv4 address that such host may use if they are
   operating in a dual stack mode.

It should say:

   The IPv4 address used as part of the generation of 6to4 addresses for
   the local IPv6 network is that of the external IPv4 network interface
   address (labelled '(A)' in the above diagram).  For example, if the
   interface (A) has the IPv4 address 192.0.2.1, then the local IPv6
   clients will use a common IPv6 address prefix of the form 2002:
|  {192.0.2.1}::/48 (or 2002:C000:201::/48 in hex notation).  All the
   local IPv6 clients share this common /48 address prefix, irrespective
   of any local IPv4 address that such host may use if they are
   operating in a dual stack mode.

Notes:

Issue: mismatched (spurious) opening parentheses.
Location is last paragraph on page 5.

Errata ID: 1363
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-11
Held for Document Update by: Brian Haberman

Section 4, pg.7 says:

                                    vv
|         [...], given the potentially for inheritance of 'stale'
      reverse DNS information in this context, in those cases where [...]

It should say:

|         [...], given the potential for inheritance of 'stale' reverse
      DNS information in this context, in those cases where [...]

Notes:

Location is last paragraph on page 7 (2nd bullet).

Errata ID: 1364
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-11
Held for Document Update by: Brian Haberman

Section 8.2 says:

   [6to4-dns]  Moore, K., "6to4 and DNS", Work in Progress, April 2003.

It should say:

   [6to4-dns]  Moore, K., "6to4 and DNS", Work in Progress, October 2002.

Notes:

The only matching draft that can be found in the archives has an
*expiration* month of April 2003; nevertheless, it has been
published in October 2002, and that month should be listed.

RFC 5162, "IMAP4 Extensions for Quick Mailbox Resynchronization", March 2008

Note: This RFC has been obsoleted by RFC 7162

Source of RFC: lemonade (app)

Errata ID: 1365
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-11
Held for Document Update by: Pete Resnick

Section 1. (ff.) says:

   A client making use of this extension MUST issue "ENABLE QRESYNC"
   once it is authenticated.  A server MUST respond with a tagged BAD
   response if the QRESYNC parameter to the SELECT/EXAMINE command or
   the VANISHED UID FETCH modifier is specified and the client hasn't
   issued "ENABLE QRESYNC" in the current connection.

It should say:

   A client making use of this extension MUST issue "ENABLE QRESYNC"
   once it is authenticated.  A server MUST respond with a tagged BAD
   response if the QRESYNC parameter to the SELECT/EXAMINE command or
   the VANISHED UID FETCH modifier is specified and the client hasn't
|  issued "ENABLE QRESYNC", or the server has not positively responded
|  to that command with "ENABLED QRESYNC", in the current connection.

Notes:

Rationale:
According to RFC 5161, the option enablement handshake is only
complete, and hence the option(s) enabled on the server, if the
server has sent a positive (untagged) "ENABLED <option>" response
to the ENABLE command.
For clarity, RFC 5162 should unambiguously reflect this causality
chain.

This same issue recurs in Section 3.1 (last paragraph on page 4)
and Section 3.6 (4th paragraph on page 13).

RFC 5169, "Handover Key Management and Re-Authentication Problem Statement", March 2008

Source of RFC: hokey (sec)

Errata ID: 1399
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-31
Held for Document Update by: Tim Polk

Section 6.3,pg.10/11 says:

   CAPWAP currently has no means to support roaming between ACs in an
   enterprise network.  The proposed work on EAP efficient re-
|  authentication addresses is an inter-authenticator handover problem
   from an EAP perspective, which applies during handover between ACs.
   [...]

It should say:

   CAPWAP currently has no means to support roaming between ACs in an
   enterprise network.  The proposed work on EAP efficient re-
|  authentication addresses an inter-authenticator handover problem
   from an EAP perspective, which applies during handover between ACs.
   [...]

Notes:

Two verbs back-ro-back.

RFC 5185, "OSPF Multi-Area Adjacency", May 2008

Source of RFC: ospf (rtg)

Errata ID: 1437
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2008-06-12
Held for Document Update by: Stewart Bryant

Section 2.1 says:

  Multi-area adjacencies are configured between two routers having a
   common interface. 

It should say:

  Multi-area adjacencies are configured between two routers having an
   interface to the same network.

Notes:

Unless "interface" is used in an unusual meaning?

RFC 5187, "OSPFv3 Graceful Restart", June 2008

Source of RFC: ospf (rtg)

Errata ID: 1453
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-06-15
Held for Document Update by: Stewart Bryant
Date Held: 2012-10-26

Section 3.2 / 7.2 says:

a)
The last paragraph of Section 3.2 (on top of page 5) says:

|  Many implementations currently use the interface's MIB-II IfIndex
|  [MIB-INTF] for Interface ID.  The persistence of Interface ID across
|  reboots is described in section 3.1.5 of [MIB-PERS].

b)
Section 7.2 (on page 6) says:

|  [MIB-INTF]     McCloghrie, K. and M. Rose, "Management Information
|                 Base for network management of TCP/IP-based internets:
|                 MIB-II", STD 17, RFC 1213, March 1991.

|  [MIB-PERS]     McCloghrie, K. and F. Kastenholz, "The Interfaces
                  Group MIB", RFC 2863, June 2000.

It should say:

a)

|  Many implementations currently use the interface's SNMP MIB IfIndex
|  [MIB-INTF] for Interface ID.  The persistence of Interface ID across
   reboots is described in section 3.1.5 of [MIB-INTF].

b)

|  [MIB-INTF]     McCloghrie, K. and F. Kastenholz, "The Interfaces
                  Group MIB", RFC 2863, June 2000.

Notes:

Unfortunately, the IETF maintains the questionable 'luxury' of
two sets of Network Management Standards, where the second one
actually has obsoleted the former one.

Although all parts of RFC 1213 have either been obsoleted by
newer standards or deliberately been deprecated together with
the legacy protocols they were intended to support, STD 17
(RFC 1213) [as well as STD 16] have been resurrected in
rfcxx00.txt, including its latest RFC edition, RFC 5000.

In particular (omitting all intermediate RFCs now obsoleted as well),
- the basic part of RFC 1213 ("host group") has been replaced
by the SNMP MIB module in part 8 of STD 62, RFC 3418,
- the "interface group" has been obsoleted by RFC 2863,
- the "IP group" has been obsoleted by RFC 4293,
- the IP forwarding table has been obsoleted by RFC 4292,
- the "TCP group" has been obsoleted by RFC 4022,
- the "UDP group" has been obsoleted by RFC 4113.

References to "MIB-II" and RFC 1213 are the source of frequent
confusion.
Therefore, new RFCs, in particular STANDARDS TRACK RFCs, should
not quote RFC 1213 any more.

It is observed current policy of the MIB Doctors to have all new
IETF documents defining MIB modules refer to the newer standards;
but RFC 5187, not defining a MIB module, apparently has not
undergone MIB Doctor review. Nevertheless, the confusing
reference to "MIB-II" and a document outdated since many years
should have been avoided here as well.

RFC 5198, "Unicode Format for Network Interchange", March 2008

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 1401
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-31
Held for Document Update by: Pete Resnick
Date Held: 2014-05-16

Section 2, pg.3 says:

   3.  The control characters in the ASCII range (U+0000 to U+001F and
|      U+007F to U+009F) SHOULD generally be avoided.  Space (SP,
|      U+0020), CR, LF, and Form Feed (FF, U+000C) are exceptions to
|      this principle, but use of all but the first requires care as
       discussed elsewhere in this document.  The so-called "C1
       Controls" (U+0080 through U+009F), which did not appear in ASCII,
       MUST NOT appear.

It should say:

   3.  The control characters in the ASCII range (U+0000 to U+001F and
|      U+007F to U+009F) SHOULD generally be avoided. CR, LF, and Form
|      Feed (FF, U+000C) are exceptions to this principle, but use of
|      these, as well as Space (SP, U+0020, which is often treated as a
|      control character), requires care as discussed elsewhere in this
       document.  The so-called "C1 Controls" (U+0080 through U+009F),
       which did not appear in ASCII, MUST NOT appear.

Notes:

Logical inconsistency:
SPACE is not contained in the enumeration in the first sentence;
thus, it is no *exception* to that rule, and the published text
does not make proper sense.

RFC 5201, "Host Identity Protocol", April 2008

Note: This RFC has been obsoleted by RFC 7401

Note: This RFC has been updated by RFC 6253

Source of RFC: hip (int)

Errata ID: 1799
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Ari Keränen
Date Reported: 2009-06-30
Held for Document Update by: Brian Haberman

Section 5.2. says:

   Parameters numbered between 1024-2047 are reserved.  Parameters
   numbered between 2048-4095 are used for parameters related to HIP
   transform types.  Parameters numbered between 4096 and (2^16 - 2^12)
   61439 are reserved.  Parameters numbered between 61440-62463 are used
   for signatures and signed MACs.  Parameters numbered between 62464-
   63487 are used for parameters that fall outside of the signed area of
   the packet.  Parameters numbered between 63488-64511 are used for
   rendezvous and other relaying services.  Parameters numbered between
   64512-65535 are reserved.

It should say:

(for the correct values, see: http://www.iana.org/assignments/hip-parameters/hip-parameters.xhtml#hip-parameters-3)

Notes:

The parameter number ranges are not in sync with the actual IANA assignments.

Errata ID: 4319
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Hoffman
Date Reported: 2015-03-31
Held for Document Update by: Brian Haberman
Date Held: 2015-04-22

Section 3 says:

   HIP implementations MUST support the Rivest Shamir Adelman (RSA/SHA1)

It should say:

   HIP implementations MUST support the Rivest Shamir Adleman (RSA/SHA1)

Notes:

Misspelling of one of the inventors' names.

RFC 5202, "Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)", April 2008

Note: This RFC has been obsoleted by RFC 7402

Source of RFC: hip (int)

Errata ID: 1798
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ari Keränen
Date Reported: 2009-06-29
Held for Document Update by: Brian Haberman

Section 5.1.2 says:

Conversely, a recipient MUST be prepared to handle received transport
parameters that contain more than six Suite IDs.

It should say:

Conversely, a recipient MUST be prepared to handle received transform
parameters that contain more than six Suite IDs.

Notes:

The section describes the ESP "transform", not "transport", parameter.

RFC 5215, "RTP Payload Format for Vorbis Encoded Audio", August 2008

Source of RFC: avt (rai)

Errata ID: 1659
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-01-26
Held for Document Update by: Cullen Jennings

Section 2.2, pg.6 says:

   This field specifies the kind of Vorbis data stored in this RTP
   packet.  There are currently three different types of Vorbis
   payloads.  Each packet MUST contain only a single type of Vorbis
   packet (e.g., you must not aggregate configuration and comment
   packets in the same RTP payload).

      0 = Raw Vorbis payload

      1 = Vorbis Packed Configuration payload

      2 = Legacy Vorbis Comment payload

      3 = Reserved

It should say:

   This field specifies the kind of Vorbis data stored in this RTP
|  payload.  There are currently three different types of Vorbis
|  packets.  Each RTP payload MUST contain only a single type of Vorbis
   packet (e.g., you must not aggregate configuration and comment
   packets in the same RTP payload).

|     0 = Raw Vorbis packet

|     1 = Vorbis Packed Configuration packet

|     2 = Legacy Vorbis Comment packet

      3 = Reserved

Notes:

Rationale:

The RFC is about an RTP *payload* format, and, according to
section 1 of the RFC, deals with Vorbis *packets* -- to be
encapsulated in the RTP payload.

Section 2.2 explains the RTP Payload Header vor Vorbis. Thus,
the use of "payload" and "packet" in the Original Text does
not match these definitions and hence might well be confusing.
The Corrected Text aims at placing the proper terms there.

Errata ID: 1661
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-01-26
Held for Document Update by: Robert Sparks

Section 3.1.1, pg.11 says:

   The Ident field is set with the value that will be used by the Raw
   Payload Packets to address this Configuration.  The Fragment type is
   set to 0 because the packet bears the full Packed configuration.  The
|  number of the packet is set to 1.
   ^^^^^^^^^^^^^^^^^^^^

It should say:

   The Ident field is set with the value that will be used by the Raw
   Payload Packets to address this Configuration.  The Fragment type is
   set to 0 because the packet bears the full Packed configuration.  The
|  number of packets is set to 1.
   ^^^^^^^^^^^^^^^^^

Notes:

Rationale:

According to Section 2.2 of the RFC, the last field in the
Payload Header is "number of packets", not "number of the packet"
(which might be misunderstood as some kind of sequence number).
It seems to be prudent to use the precise field name.

Errata ID: 1660
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-01-26
Held for Document Update by: Robert Sparks

Section 3.1, pg.9 says:

   The Packed Configuration (Section 3.1.1) Payload is sent in-band with
   the packet type bits set to match the Vorbis Data Type.  Clients MUST
   be capable of dealing with fragmentation and periodic re-transmission
|  of [RFC4588] the configuration headers.  [...]
   ^^^^^^^^^^^^

It should say:

   The Packed Configuration (Section 3.1.1) Payload is sent in-band with
   the packet type bits set to match the Vorbis Data Type.  Clients MUST
   be capable of dealing with fragmentation and periodic re-transmission
|  [RFC4588] of the configuration headers.  [...]
   ^^^^^^^^^^^^

Notes:

Rationale: cunfusing word twister!

Errata ID: 1662
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-01-26
Held for Document Update by: Robert Sparks

Section 5.1,1st para says:

   Here is an example of a fragmented Vorbis packet split over three RTP
|  payloads.  Each of them contains the standard RTP headers as well as
|  the 4-octet Vorbis headers.
                            ^                              ^

It should say:

   Here is an example of a fragmented Vorbis packet split over three RTP
|  payloads.  Each of them contains the standard RTP header as well as
|  the 4-octet Vorbis header.

Notes:

Rationale:

Confusing use of plural: Each RTP packet contains a single
standard RTP header and a single 4-octet Vorbis header.

Errata ID: 1663
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-01-26
Held for Document Update by: Robert Sparks

Section 5.2,2nd para says:

|  Loss of any of the Configuration fragment will result in the loss of
   the full Configuration packet with the result detailed in the Loss of
|  Configuration Headers (Section 3.3) section.

It should say:

|  Loss of any fragment of the Configuration packet will result in the
   loss of the full Configuration packet with the result detailed in the
|  Loss of Configuration Headers section (Section 3.3).

Notes:

Rationale: Clarification / improved language

Errata ID: 1664
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-01-26
Held for Document Update by: Robert Sparks

Section 6/6.* titles says:

Section 6 is structured as follows:

|6.  IANA Considerations
|
   ...
   <IANA registration of media type audio/vorbis>
   ...

|6.1.  Packed Headers IANA Considerations
|
|  The following IANA considerations refers to the split configuration
|  Packed Headers (Section 3.2.1) used within RFC 5215.

   ...
   <IANA registration of media type audio/vorbis-config>
   ...

It should say:

Section 6 is structured as follows:

|6.  IANA Considerations
|
|   The following subsections contain the IANA registrations (in
|   accordance with RFC 4855 using the registration template of
|   RFC 4288) of the media types for the basic Vorbis payload format
|   and the Packed Headers payload format (Section 3.2.1).
|
|6.1.  IANA registration of media type audio/vorbis
|
   ...
   <IANA registration of media type audio/vorbis>
   ...

|6.2.  IANA registration of media type audio/vorbis-config
|
   ...
   <IANA registration of media type audio/vorbis-config>
   ...

Notes:

Rationale:

The section structure and titles do not properly match the contents
of the whole section and should be corrected for clarity.
Because the applicable RFC 4288 and RFC 4855 have no entries in the
References section of this RFC, they are quoted only informally.
In the Correcte Text, the explanatory text has been moved to up to
6. and expanded accordingly to describe the whole section content.

Errata ID: 1665
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-01-26
Held for Document Update by: Robert Sparks

Section 7.1, p.21/21 says:

   The information carried in the Media Type specification has a
   specific mapping to fields in the Session Description Protocol (SDP)
   [RFC4566], which is commonly used to describe RTP sessions.  When SDP
|  is used to specify sessions, the mapping are as follows:

   [...]

|  o  The mandated parameters "configuration" MUST be included in the
      SDP "a=fmtp" attribute.

   [...]

It should say:

   The information carried in the Media Type specification has a
   specific mapping to fields in the Session Description Protocol (SDP)
   [RFC4566], which is commonly used to describe RTP sessions.  When SDP
|  is used to specify sessions, the mapping is as follows:

   [...]

|  o  The mandated parameter "configuration" MUST be included in the
      SDP "a=fmtp" attribute.

   [...]

Notes:

Rationale:

Grammar; there is only a single mapping (first paragraph of the section)
and only a single mandatory parameter (last bullet (of 5)).

Errata ID: 1666
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-01-26
Held for Document Update by: Robert Sparks

Section 7.1.1 says:

7.1.1.  SDP Example

   The following example shows a basic SDP single stream.  The first
|  configuration packet is inside the SDP; other configurations could be
|  fetched at any time from the URIs provided.  The following base64
|  [RFC4648] configuration string is folded in this example due to RFC
   line length limitations.

|     c=IN IP4 192.0.2.1
|
|     m=audio RTP/AVP 98
|
|     a=rtpmap:98 vorbis/44100/2
|
|     a=fmtp:98 configuration=AAAAAZ2f4g9NAh4aAXZvcmJpcwA...;

   Note that the payload format (encoding) names are commonly shown in
|  uppercase.  Media Type subtypes are commonly shown in lowercase.
   These names are case-insensitive in both places.  Similarly,
|  parameter names are case-insensitive both in Media Type types and in
   the default mapping to the SDP a=fmtp attribute.  The a=fmtp line is
|  a single line, even if it is shown as multiple lines in this document
|  for clarity.

It should say:

7.1.1.  SDP Example

   The following example shows a basic SDP single stream.  The first
|  configuration packet is inside the SDP. The following base64
|  [RFC4648] configuration string is truncated in this example due to
   RFC line length limitations.

|     c=IN IP4 192.0.2.1
|     m=audio RTP/AVP 98
|     a=rtpmap:98 vorbis/44100/2
|     a=fmtp:98 configuration=AAAAAZ2f4g9NAh4aAXZvcmJpcwA...;

   Note that the payload format (encoding) names are commonly shown in
|  uppercase.  Media Types and Subtypes are commonly shown in lowercase.
   These names are case-insensitive in both places.  Similarly,
|  parameter names are case-insensitive both in Media Types and in the
   default mapping to the SDP a=fmtp attribute.  The a=fmtp line is
|  shown incompletely in this document for clarity.

Notes:

Rationale:

a) There is no URI provided; the corresponding remark is misleading
and therefore has been deleted in the Corrected Text.

b) The example does not contain folded lines; one line is shown only
partially -- for brevity this is denoted as truncation, and the
confusing remarks regarding line folding have been deleted in the
Corrected Text.

c) Spurious blank lines within SDP example deleted.

d) Language regarding media types/subtypes corrected.

Errata ID: 1667
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-01-26
Held for Document Update by: Robert Sparks

Section 10, pg.23 says:

   RTP packets using this payload format are subject to the security
|  considerations discussed in the RTP specification [RFC3550], the
|  base64 specification [RFC4648], and the URI Generic syntax
|  specification [RFC3986].  [...]

It should say:

   RTP packets using this payload format are subject to the security
|  considerations discussed in the RTP specification [RFC3550] and the
|  base64 specification [RFC4648].  [...]

Notes:

Rationale:

The published RFC does not make use of embedded or explicit URIs.
Consequently the Security Considerations from RFC 3986 seem to be
irrelevant.

Arguably, the ref. to [RFC4648] only applies to the SDP, not the
RTP packets themselves; further text changes in support of this
observation have been set aside for brevity.

Note:
The entry [RFC3986] in Section 13.1 can be deleted after the
above change.

RFC 5216, "The EAP-TLS Authentication Protocol", March 2008

Note: This RFC has been updated by RFC 8996, RFC 9190

Source of RFC: emu (sec)

Errata ID: 1388
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-26
Held for Document Update by: Pasi Eronen

Section 2.1.1,pg.5 says:

   The certificate message contains a public key certificate chain for
   either a key exchange public key (such as an RSA or Diffie-Hellman
   key exchange public key) or a signature public key (such as an RSA or
|  Digital Signature Standard (DSS) signature public key).  In the
   latter case, a TLS server_key_exchange handshake message MUST also be
   included to allow the key exchange to take place.

It should say:

   The certificate message contains a public key certificate chain for
   either a key exchange public key (such as an RSA or Diffie-Hellman
   key exchange public key) or a signature public key (such as an RSA or
|  Digital Signature Algorithm (DSA) signature public key).  In the
                     ^^^^^^^^^    ^
   latter case, a TLS server_key_exchange handshake message MUST also be
   included to allow the key exchange to take place.

Notes:

Location is the 6th paragraph of Section 2.1.1.
(Please note that the first paragraph of that section is
inadvertently split into two parts by a spurious blank line
that has been ignored for the purpose of paragraph numbering.)

Rationale:
There's no such thing like a DSS signature public key.
Keys have to match the mathematical algorithms, and only
indirectly the standrds documents.
The Digital Signature Standard (DSS) supports three different
kinds of signature algorithms: (classical) DSA, ECDSA (the DSA
variant based on Elliptic Curve Cryptography), and RSA.
All three algorithms require different keys, based on the
mathematical properties and the related presentation forms.

Other parts of the document, in particular Section 5.1 already
use the proper terminology to distinguish between algorithm and
standards document.

Errata ID: 1393
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-26
Held for Document Update by: Pasi Eronen

Section 3.1,pg.20 says:

|  0                   1                   2                   3
|  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |   Identifier  |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |     Type      |     Flags     |      TLS Message Length
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |     TLS Message Length        |       TLS Data...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

|   0                   1                   2                   3
|   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |   Identifier  |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |     Type      |     Flags     |      TLS Message Length       :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  :     TLS Message Length        |       TLS Data...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

There are two issues:
- misalignment of ruler lines above the diagram;
- misleading representation of the TLS Message Length field
that is continued from the 2nd to the 3rd data line;
the above proposal makes use of ':' to denote continuation
of a folded field -- this notational detail has been widely
adopted in many contemporary RFCs.

This very same issue recurs in Section 3.2, on page 22, and
identical changes should be applied there.


Note:
Unfortunately, the affiliation of the authors apparently
maintains packet filters (since almost 9 months) that preclude
DNS lookups for the MX records, and hence sending email to the
authors, for any site operating a DNS resolver behind a NAT/NAPT,
by blackholing DNS queries from sorce ports other than 53 --
contrary to all applicable RFCs.
This effective denial of service has prohibited me from direct
communication with the authors, to make them aware of the issues
now reported in this series of Errata Reports.

Errata ID: 1390
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-26
Held for Document Update by: Pasi Eronen

Section 2.1.3,pg.10 says:

                           <- EAP-Request/
                           EAP-Type=EAP-TLS
                           (TLS server_hello,
                             TLS certificate,
                    [TLS server_key_exchange,]
               TLS certificate_request,
                 TLS server_hello_done)

   EAP-Response/
   EAP-Type=EAP-TLS
   (TLS certificate,
    TLS client_key_exchange,
    TLS certificate_verify,
    TLS change_cipher_spec,
    TLS finished) ->

It should say:

                           <- EAP-Request/
                           EAP-Type=EAP-TLS
                           (TLS server_hello,
|                           TLS certificate,
|                           [TLS server_key_exchange,]
|                           TLS certificate_request,
|                           TLS server_hello_done)

   EAP-Response/
   EAP-Type=EAP-TLS
   (TLS certificate,
    TLS client_key_exchange,
    TLS certificate_verify,
    TLS change_cipher_spec,
    TLS finished) ->

Notes:

Rationale:

The columnar alignment of many parts of the examples
presented in Section 2.1.3 - 2.1.5 is distorted, for
multiple messages sent by the Authenticator
(denoted A-msg below, for brevity).

The example above is the 3rd A-msg on page 10.

Additional occurrences of this issue are:

- Section 2.1.3, last part, mid-page 11, third A-msg,
- Section 2.1.4, first, second and third A-msg on page 13,
- Section 2.1.5, second and third A-msg on page 15,
and second A-msg on page 16.

Errata ID: 1391
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-26
Held for Document Update by: Pasi Eronen

Section 2.3,pg.17 says:

   master_secret = TLS-PRF-48(pre_master_secret, "master secret",
|                   client.random || server.random) key_block     =
|  TLS-PRF-X(master_secret, "key expansion",
                    server.random || client.random)

It should say:

   master_secret = TLS-PRF-48(pre_master_secret, "master secret",
|                   client.random || server.random)
|  key_block     = TLS-PRF-X(master_secret, "key expansion",
                    server.random || client.random)

Notes:

Wrong line break makes formula presentation confusing.

(This flaw has been introduced in a last-minute change
before publication!)

Errata ID: 1394
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-26
Held for Document Update by: Pasi Eronen
Date Held: 2008-12-04

Section 5.3,pg.26 says:

   In contrast to the EAP-TLS server, the EAP-TLS peer may not have
|  Internet connectivity.  Therefore, the EAP-TLS server SHOULD provide
   its entire certificate chain minus the root to facilitate certificate
   validation by the peer.  The EAP-TLS peer SHOULD support validating
   the server certificate using RFC 3280 [RFC3280] compliant path
   validation.

It should say:

   In contrast to the EAP-TLS server, the EAP-TLS peer may not have
|  Internet connectivity (at the time of the EAP-TLS exchange).
   Therefore, the EAP-TLS server SHOULD provide its entire certificate
   chain minus the root to facilitate certificate validation by the
   peer.  The EAP-TLS peer SHOULD support validating the server
   certificate using RFC 3280 [RFC3280] compliant path validation.

Notes:

Rationale: Clarification

Errata ID: 2510
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Min Pae
Date Reported: 2010-09-03
Held for Document Update by: Sean Turner

Section 3.1 says:

The L bit (length included) is set to indicate the presence of the
four-octet TLS Message Length field, and MUST be set for the first
fragment of a fragmented TLS message or set of messages.

It should say:

The L bit (length included) is set to indicate the presence of the
four-octet TLS Message Length field, and MUST be set for the first
fragment of a fragmented TLS message.  The L bit MAY be included
in all fragments of a fragmented TLS message, but if included the
TLS Length MUST represent the entire length of the TLS message.

Notes:

The lack of definition for what to do with the L bit and the TLS length field for TLS fragments other than the first fragment is leaving the door open to divergent behavior for whether the L bit and length field are included, what the length contains if they're included, and how to interpret it.

RFC 5222, "LoST: A Location-to-Service Translation Protocol", August 2008

Note: This RFC has been updated by RFC 6848, RFC 8917, RFC 9036

Source of RFC: ecrit (rai)

Errata ID: 2511
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin Thomson
Date Reported: 2010-09-07
Held for Document Update by: Robert Sparks
Date Held: 2011-09-14

Section 8.3.5, 8.4.2 says:

In 8.3.5:
     <locationValidation>
       <valid>country A1 A3 A6</valid>
       <invalid>PC</invalid>
       <unchecked>HNO</unchecked>
     </locationValidation>

In 8.4.2:
   ... Each element contains a list of tokens separated by
   whitespace, enumerating the civic location labels used in child
   elements of the <civicAddress> element.  ...
and:
   The example shown in Figure 5 and in Figure 6 indicates that the
   tokens 'country', 'A1', 'A3', and 'A6' have been validated by the
   LoST server.  ...

It should say:

In 8.3.5:
     <locationValidation
        xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
       <valid>ca:country ca:A1 ca:A3 ca:A6</valid>
       <invalid>ca:PC</invalid>
       <unchecked>ca:HNO</unchecked>
     </locationValidation>

In 8.4.2:
   ... Each element contains a list of qualified element names separated by
   whitespace, enumerating child elements of the <civicAddress> element.  ...
and:
   The examples shown in Figure 5 and in Figure 6 indicates that the
   tokens 'country', 'A1', 'A3', and 'A6' from [RFC5139] have been validated
   by the LoST server.  ...

Notes:

It's not clear from the description how the location validation response elements are to be interpreted. The example seems to indicate that the local name (only) for the civic address elements is used. On the other hand, the schema seems to imply that, because this is a list of xs:QName, a qualified name is used for each. The text itself is ambiguous.

----
This errata is being held for document update. The essence of its issue is being addressed in draft-ietf-geopriv-local-civic. There are two related threads in the ecrit archive. One beginning at
http://www.ietf.org/mail-archive/web/ecrit/current/msg07380.html
and one ending at
http://www.ietf.org/mail-archive/web/ecrit/current/msg07750.html


Using the local name only could result in errors - it would be possible (albeit inadvisable) to extend RFC 5139 with an element that had the same local name as an existing element or an element in another extension. As long as the namespace is distinct, this is perfectly legal, but it could lead to a naming conflict here.

With this interpretation, the elements in the example in 8.3.5 indicate elements from the LoST namespace (urn:ietf:params:xml:ns:lost1), rather than the civic address namespace (urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr).

Updating the description in 8.4.2 and the example in 8.3.5 would ensure that this doesn't result in interoperability problems.

Errata ID: 4175
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dan Banks
Date Reported: 2014-11-12
Held for Document Update by: Alissa Cooper
Date Held: 2015-11-01

Section 12.1 says:

     <location id="DEF 345" profile="geodetic-2d">
       <gml:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
         <gml:pos>42.656844 -73.348157</gml:pos>
       </gml:Point>
     </location>

It should say:

     <location id="DEF 345" profile="geodetic-2d">
       <gml:Point id="point1"
       srsName="urn:ogc:def:crs:EPSG::4326">
         <gml:pos>42.656844 -73.348157</gml:pos>
       </gml:Point>
     </location>

Notes:

The 'srsName' in the location provided as part of example in Figure 15 is missing a required ':' between 'EPSG' and '4326'.

RFC 5226, "Guidelines for Writing an IANA Considerations Section in RFCs", May 2008

Note: This RFC has been obsoleted by RFC 8126

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: gen

Errata ID: 2701
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-02-01
Held for Document Update by: RFC Editor
Date Held: 2011-12-08

Section 12.2 says:

 [RFC4395]             Hansen, T., Hardie, T., and L. Masinter,
                       "Guidelines and Registration Procedures for New
                       URI Schemes", BCP 115, RFC 4395, February 2006.

It should say:

 [RFC4395]             Hansen, T., Hardie, T., and L. Masinter,
                       "Guidelines and Registration Procedures for New
                       URI Schemes", BCP 35, RFC 4395, February 2006.

Notes:

RFC 4395 is not BCP 115. It is BCP 35.

--VERIFIER NOTES--
Correct - RFC 4395 is BCP 35, not BCP 115. However, at the time RFC 5226 was published (May 2008), this error had not yet been reported (it was reported in Jan. 2009, and the relevant data was updated accordingly at that time).

RFC 5234, "Augmented BNF for Syntax Specifications: ABNF", January 2008

Note: This RFC has been updated by RFC 7405

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 2820
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Spiros Bousbouras
Date Reported: 2011-06-03
Held for Document Update by: Pete Resnick
Date Held: 2011-06-11

Section 4 says:

         prose-val      =  "<" *(%x20-3D / %x3F-7E) ">"
                                ; bracketed string of SP and VCHAR
                                ;  without angles

It should say:

         prose-val      =  "<" *(%x20-3D / %x3F-7E) ">"
                                ; bracketed string of SP and VCHAR
                                ;  without ">"

Notes:

"without angles" suggests that ">" and "<"
must not appear but the range of codes given
suggests that only ">" must not appear.

Errata ID: 2914
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rudolf Dovicin
Date Reported: 2011-08-03
Held for Document Update by: Pete Resnick
Date Held: 2011-08-04

Throughout the document, when it says:

         alternation    =  concatenation
                           *(*c-wsp "/" *c-wsp concatenation)

         concatenation  =  repetition *(1*c-wsp repetition)

         repetition     =  [repeat] element

         repeat         =  1*DIGIT / (*DIGIT "*" *DIGIT)

         element        =  rulename / group / option /
                           char-val / num-val / prose-val

         group          =  "(" *c-wsp alternation *c-wsp ")"

         option         =  "[" *c-wsp alternation *c-wsp "]"

Notes:

Section 4. (ABNF Definition of ABNF) contains at least 2 recursions.
Recursions are not explicitly mentioned in the document, which may be confusing.

Errata ID: 6172
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Glyn Normington
Date Reported: 2020-05-14
Held for Document Update by: Barry Leiba
Date Held: 2020-05-14

Section Appendix B says:

Note that these rules are only valid for ABNF encoded in 7-bit ASCII or in characters sets that are a superset of 7-bit ASCII.

It should say:

Note that these rules are only valid for ABNF encoded in 7-bit ASCII or in character sets that are a superset of 7-bit ASCII.

Notes:

Typo.

Errata ID: 6173
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Glyn Normington
Date Reported: 2020-05-14
Held for Document Update by: Barry Leiba
Date Held: 2020-05-14

Section 3.6 says:

The operator "*" preceding an element indicates repetition. The full form is:

 <a>*<b>element

where <a> and <b> are optional decimal values, indicating at least <a> and at most <b> occurrences of the element.

Default values are 0 and infinity so that *<element> allows any number, including zero; 1*<element> requires at least one; 3*3<element> allows exactly 3; and 1*2<element> allows one or two.

It should say:

The operator "*" preceding an element indicates repetition. The full form is:

 <a>*<b>element

where <a> and <b> are optional decimal values, indicating at least <a> and at most <b> occurrences of the element.

The default value of <a> is 0. If <b> is omitted, there is no upper limit to the number of occurrences of the element. Consequently *<element> allows any number, including zero; 1*<element> requires at least one; 3*3<element> allows exactly 3; and 1*2<element> allows one or two.

Notes:

infinity is not a decimal value

RFC 5237, "IANA Allocation Guidelines for the Protocol Field", February 2008

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: gen

Errata ID: 2732
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-02-23
Held for Document Update by: Russ Housley

Section 2 says:

   This document replaces the RFC 2780 Section 4.3 rule [RFC2780] with
   the following:

      IANA allocates values from the IPv4 Protocol name space following
      an IESG Approval or Standards Action process.

   This document also makes an implicit change to the rule for the IPv6
   Next Header field in Section 5.3 of RFC 2780.  That rule refers to
   the rule in Section 4.3 of the same RFC.  From now on, this reference
   should be understood to refer to the rule revised here, i.e., without
   the Expert Review option.

It should say:

   This document replaces the RFC 2780 Section 4.3 rule [RFC2780] with
   the following:

      IANA allocates values from the IPv4 Protocol name space following
      an IESG Approval or Standards Action process [RFC5226].

   This document also makes an implicit change to the rule for the IPv6
   Next Header field in Section 5.3 of RFC 2780.  That rule refers to
   the rule in Section 4.3 of the same RFC.  From now on, this reference
   should be understood to refer to the rule revised here, i.e., without
   the Expert Review option.

Notes:

The reference to RFC 5226 is probably missing here.

RFC 5239, "A Framework for Centralized Conferencing", June 2008

Source of RFC: xcon (rai)

Errata ID: 1450
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-06-15
Held for Document Update by: Robert Sparks

Section 8.4, pg.27 says:

The 5th and the 6th paragraph on pg.27 both contain the clause:

   ...
   When using SDP offer/answer exchange to negotiate ...

It should say:

Both instances should say
either:

   ...
   When using SDP offer/answer exchanges to negotiate ...
                                       ^
or (less preferable):

   ...
   When using SDP an offer/answer exchange to negotiate ...
                  ^^^

Notes:

Grammar

Errata ID: 1451
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-06-15
Held for Document Update by: Robert Sparks

Section 9.3,1st para says:

                                           [...].  This kind of
|  operation is called "1st party signaling" and they do not affect the
   state of other participants in the conference.

It should say:

                                           [...].  This kind of
|  operation is called "1st party signaling" and it does not affect the
   state of other participants in the conference.
                                                 ^^^^^^^

Notes:

Grammar: "they do" does not match "This kind of operation".

Errata ID: 1452
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-06-15
Held for Document Update by: Robert Sparks

Section 9.6,2nd para says:

   Figure 15 provides an example of one user "Alice" who's chairing a
   fixed length conference with "Bob" and "Carol".  The configuration is
|  such that only the chair is providing a warning when there are only
                                     ^^^
   10 minutes left in the conference.  At that time, "Alice" is moved
   into a sidebar created by the conferencing system and only "Alice"
   receives the announcement.

It should say:

   Figure 15 provides an example of one user "Alice" who's chairing a
   fixed length conference with "Bob" and "Carol".  The configuration is
|  such that only the chair is provided a warning when there are only
                                     ^^
   10 minutes left in the conference.  At that time, "Alice" is moved
   into a sidebar created by the conferencing system and only "Alice"
   receives the announcement.

Notes:

Typo distorting the proper sense of the text.
See also Figure 15 -- the warning is sent *to* "Alice".

RFC 5240, "Protocol Independent Multicast (PIM) Bootstrap Router MIB", June 2008

Source of RFC: pim (rtg)

Errata ID: 1438
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-06-12
Held for Document Update by: Adrian Farrel

Section 5, pg.5 says:

   pimBsrCandidateRPGroupPrefixLength OBJECT-TYPE
       ...
       DESCRIPTION
|              "The multicast group address mask that, when combined
               with the corresponding value of
               pimBsrCandidateRPGroupAddress, identifies a group prefix
               for which the local router will advertise itself as a
               Candidate-RP.  [...]

It should say:

   pimBsrCandidateRPGroupPrefixLength OBJECT-TYPE
       ...
       DESCRIPTION
|              "The multicast group prefix length that, when combined
               with the corresponding value of
               pimBsrCandidateRPGroupAddress, identifies a group prefix
               for which the local router will advertise itself as a
               Candidate-RP.  [...]

Notes:

Missed update from legacy text!
On page 9, the DESCRIPTION for pimBsrElectedBSRGrpMappingGrpPrefixLen
contains the proper wording, copied to Corrected Text above.

Errata ID: 1441
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-06-12
Held for Document Update by: Adrian Farrel

Throughout the document, when it says:

a) In section 1 (2nd paragraph on pg. 2) :

   This document was created by moving some of the PIM BSR-specific MIB
|  tables from one of the earlier versions of PIM MIB [RFC5060].
                                                          ^^^^

b) 1st paragraph of Section 8  (on page 19) :

   This MIB module is based on the original work in [RFC5060] by R.
   Sivaramu, J. Lingard, and B. Joshi.

It should say:

a) In section 1 (2nd paragraph on pg. 2) :

   This document was created by moving some of the PIM BSR-specific MIB
|  tables from one of the earlier versions of the PIM MIB [RFC2934].
|  Together with RFC 5060 [RFC5060], this document obsoletes RFC 2934.

b) 1st paragraph of Section 8

   This MIB module is based on the original work in [RFC2934] by K.
   McCloghrie, D. Farinacci, D. Thaler, and B. Fenner.

Notes:

As explained in the body of RFC 5060, the material from RFC 2934
has been upgraded and split into two documents, RFC 5060, and now
RFC 5240 for the PIM-BSR functionality, in the same way as the
PIM-BSR protocol description has been separated from the basic
PIM protocol desciption.

Unfortunately, RFC 5240 does not restate these circumstances,
and this omission apparently has lead to an improper reference
update during the final publication process for RFC 5240,
erroneously replacing the references to RFC 2934 by RFC 5060.

The front matter of RFC 5060 and RFC 5240 should better say:
Obsoletes: 2934
and the text in the Introduction of RFC 5240 should contain
the details as proposed in the Corrected Text.

Accordingly, the *Normative* Reference [RFC5060] ought to be demoted
to Informative, and an additional Informative Reference to RFC 2934,
with tag [RFC2934], should have been added to Section 9.2.

I suggest that, to clarify the circumstances, the RFC index metadata
should be updated by adding the relations
2934 Obsoleted by 5060
and 2924 Obsoleted by 5240
and the 'inverse' (Obsoletes) relations.

Errata ID: 1439
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-06-12
Held for Document Update by: Adrian Farrel

Section 5, pg.8 says:

-- The BSR Elected BSR RP-Set Table
      ^^^^^

It should say:

-- The Elected BSR RP-Set Table

Notes:

Wrong/misleading SMI comment on top of page 8.
The table name should be used consistently; cf. Section 4, item 2.

Errata ID: 1442
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-06-12
Held for Document Update by: Adrian Farrel

Section 5, pg.10 says:

a)  pimBsrElectedBSRRPSetPriority

       DESCRIPTION
               "The priority for RP.  [...]

b)  pimBsrElectedBSRRPSetHoldtime

       DESCRIPTION
               "The holdtime for RP"

It should say:

a)  pimBsrElectedBSRRPSetPriority

       DESCRIPTION
|              "The priority for this RP.  [...]
                                 ^^^^^

b)  pimBsrElectedBSRRPSetHoldtime

       DESCRIPTION
|              "The holdtime for this RP."
                                 ^^^^^  ^

Notes:

Clarification of context.

Errata ID: 1443
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-06-12
Held for Document Update by: Adrian Farrel

Section 5., pg.13 says:

pimBsrCandidateBSRBootstrapTimer :

       DESCRIPTION
               "The time remaining before the local router next
               originates a Bootstrap message for this zone.
               Value of this object is zero if
               pimBsrCandidateBSRElectedBSR is 'FALSE'."

It should say:

       DESCRIPTION
               "The time remaining before the local router next
               originates a Bootstrap message for this zone.
|              The value of this object is zero if
               pimBsrCandidateBSRElectedBSR is 'FALSE'."

Notes:

grammar/language improvement, uniform style.


Furthermore, RFC 5240 unnecessarily and inadvertantly contains
an almost blank page, pg. 20 ( Help save a tree! :-) ).

RFC 5245, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", April 2010

Note: This RFC has been obsoleted by RFC 8445, RFC 8839

Note: This RFC has been updated by RFC 6336

Source of RFC: mmusic (rai)

Errata ID: 3107
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: N V S Kaushik
Date Reported: 2012-02-05
Held for Document Update by: Robert Sparks

Section Appendix B.6 says:

However, the check from agent R has not yet 
generated a response, and agent R receives the updated offer 
(message 7) before getting the response (message 9).  

It should say:

However, the check from agent R has not yet 
received a response, and agent R receives the updated offer 
(message 7) before getting the response (message 9).  

Notes:

Here, Agent R (ideally Agent B as per the figure 11) has generated the request, so it must receive the response. The original text may give a meaning that Agent R has to generate a response.

RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2", August 2008

Note: This RFC has been obsoleted by RFC 8446

Note: This RFC has been updated by RFC 5746, RFC 5878, RFC 6176, RFC 7465, RFC 7507, RFC 7568, RFC 7627, RFC 7685, RFC 7905, RFC 7919, RFC 8447, RFC 9155

Source of RFC: tls (sec)

Errata ID: 4007
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: KIKUCHI Masashi
Date Reported: 2014-06-06
Held for Document Update by: Stephen Farrell
Date Held: 2015-03-24

Section 7.3. says:

Note: To help avoid pipeline stalls, ChangeCipherSpec is an
   independent TLS protocol content type, and is not actually a TLS
   handshake message.

It should say:

Note: To avoid ChangeCipherSpec being transmitted in mix with
   other handshake fragments in one record, ChangeCipherSpec is
   an independent TLS protocol content type, and is not actually
   a TLS handshake message.  To help avoid pipeline stalls, 
   ChangeCipherSpec is sent from both the server and the client.

Notes:

The original text can be read like we can handle ChangeCipherSpec asynchronously.
This is harmful and may be a cause of CCS Injection vulnerability.

Errata ID: 2390
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Juho Vähä-Herttua
Date Reported: 2010-07-23
Held for Document Update by: Sean Turner

Section 6.2.3.3 says:

   The additional authenticated data, which we denote as
   additional_data, is defined as follows:

      additional_data = seq_num + TLSCompressed.type +
                        TLSCompressed.version + TLSCompressed.length;

   where "+" denotes concatenation.

   The aead_output consists of the ciphertext output by the AEAD
   encryption operation.  The length will generally be larger than
   TLSCompressed.length, but by an amount that varies with the AEAD
   cipher.  Since the ciphers might incorporate padding, the amount of
   overhead could vary with different TLSCompressed.length values.  Each
   AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes.
   Symbolically,

It should say:

   The additional authenticated data, which we denote as
   additional_data, is defined as follows:

      additional_data = seq_num + TLSCompressed.type +
                        TLSCompressed.version + TLSCompressed.length;

   where "+" denotes concatenation.

   The aead_output consists of the ciphertext output by the AEAD
   encryption operation.  The length will generally be larger than
   TLSCompressed.length, but by an amount that varies with the AEAD
   cipher.  Each AEAD cipher MUST NOT produce an expansion of greater
   than 1024 bytes.  Symbolically,

Notes:

I suggest leaving the sentence about padding out. The value for TLSCompressed.length is required by additional_data for both encryption and decryption. Therefore, it must be possible to determine the TLSCompressed.length from the ciphertext before decryption.

In practice this is done by subtracting the integrity check value length from the ciphertext length, where the integrity check value length is defined by each AEAD cipher separately. If the cipher incorporates variable padding, it is impossible to calculate the TLSCompressed.length without an explicit value sent for each ciphertext separately. Therefore to avoid confusion, it would be better not to mention anything about padding at all.

(issue discussed on tls@ietf.org and with Eric Rescorla, result of both discussions was that padding in AEAD ciphers doesn't seem to be possible with the current specification)

Errata ID: 2165
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2010-04-19
Held for Document Update by: Sean Turner

Section 6.2.3.2 says:

   Example: If the block length is 8 bytes, the content length
   (TLSCompressed.length) is 61 bytes, and the MAC length is 20 bytes,
   then the length before padding is 82 bytes (this does not include the



Dierks & Rescorla           Standards Track                    [Page 23]

RFC 5246                          TLS                        August 2008


   IV.  Thus, the padding length modulo 8 must be equal to 6 in order to
   make the total length an even multiple of 8 bytes (the block length).
   The padding length can be 6, 14, 22, and so on, through 254.  If the
   padding length were the minimum necessary, 6, the padding would be 6
   bytes, each containing the value 6.  Thus, the last 8 octets of the
   GenericBlockCipher before block encryption would be xx 06 06 06 06 06
   06 06, where xx is the last octet of the MAC.

It should say:

   Example: If the block length is 8 bytes, the content length
   (TLSCompressed.length) is 61 bytes, and the MAC length is 20 bytes,
   then the length before padding is 82 bytes (this does not include the



Dierks & Rescorla           Standards Track                    [Page 23]

RFC 5246                          TLS                        August 2008


   IV).  Thus, the padding length modulo 8 must be equal to 6 in order to
   make the total length an even multiple of 8 bytes (the block length).
   The padding length can be 6, 14, 22, and so on, through 254.  If the
   padding length were the minimum necessary, 6, the padding would be 6
   bytes, each containing the value 6.  Thus, the last 8 octets of the
   GenericBlockCipher before block encryption would be xx 06 06 06 06 06
   06 06, where xx is the last octet of the MAC.

Errata ID: 4885
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Wail Yahyaoui
Date Reported: 2016-12-13
Held for Document Update by: Stephen Farrell
Date Held: 2016-12-14

Section 6.1. says:

   server random
      A 32-byte value provided by the server.

      These parameters are defined in the presentation language as:

      enum { server, client } ConnectionEnd;

It should say:

   server random
      A 32-byte value provided by the server.

   These parameters are defined in the presentation language as:

      enum { server, client } ConnectionEnd;

Notes:

The line "These parameters are ..." after the list of parameters is at the same indentation level as the list of parameters, instead of coming back left by one level.

Errata ID: 6244
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Victor S. Osipov
Date Reported: 2020-07-29
Held for Document Update by: Paul Wouters
Date Held: 2024-03-21

Section 6.2.3.2 says:

IV
The Initialization Vector (IV) SHOULD be chosen at random, and
MUST be unpredictable. Note that in versions of TLS prior to 1.1,
there was no IV field, and the last ciphertext block of the
previous record (the "CBC residue") was used as the IV. This was
changed to prevent the attacks described in [CBCATT]. For block
ciphers, the IV length is of length
SecurityParameters.record_iv_length, which is equal to the
SecurityParameters.block_size.

It should say:

IV
The Initialization Vector (IV) SHOULD be chosen at random, and
MUST be unpredictable. Note that in versions of TLS prior to 1.1,
there was no IV field, and the last ciphertext block of the
previous record (the "CBC residue") was used as the IV. This was
changed to prevent the attacks described in [CBCATT]. For block
ciphers, the IV length is of length
SecurityParameters.record_iv_length, which is equal to the
SecurityParameters.block_length.

Notes:

This is an error here. The structure SecurityParameters hasn't the element block_size.
It has the element block_length.
See in section 6.1:
struct {
ConnectionEnd entity;
PRFAlgorithm prf_algorithm;
BulkCipherAlgorithm bulk_cipher_algorithm;
CipherType cipher_type;
uint8 enc_key_length;
uint8 block_length;
uint8 fixed_iv_length;
uint8 record_iv_length;
MACAlgorithm mac_algorithm;
uint8 mac_length;
uint8 mac_key_length;
CompressionMethod compression_algorithm;
opaque master_secret[48];
opaque client_random[32];
opaque server_random[32];
} SecurityParameters;


Paul Wouters (AD): Note this RFC is obsoleted and all of this text already got removed

RFC 5247, "Extensible Authentication Protocol (EAP) Key Management Framework", August 2008

Note: This RFC has been updated by RFC 8940

Source of RFC: eap (int)

Errata ID: 5011
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Jouni Malinen
Date Reported: 2017-05-07
Held for Document Update by: Roman Danyliw
Date Held: 2020-07-27

Section Appendix A says:

   EAP-AKA

      EAP-AKA is defined in [RFC4187].  The EAP-AKA Session-Id is the
      concatenation of the EAP Type Code (0x17) with the contents of the
      RAND field from the AT_RAND attribute, followed by the contents of
      the AUTN field in the AT_AUTN attribute:

      Session-Id = 0x17 || RAND || AUTN

It should say:

   EAP-AKA

      EAP-AKA is defined in [RFC4187].  When using full authentication,
      the EAP-AKA Session-Id is the
      concatenation of the EAP Type Code (0x17) with the contents of the
      RAND field from the AT_RAND attribute, followed by the contents of
      the AUTN field in the AT_AUTN attribute:

      Session-Id = 0x17 || RAND || AUTN

      When using fast re-authentication, the EAP-AKA Session-Id is the
      concatenation of the EAP Type Code (0x17) with the contents of the
      NONCE_S field from the AT_NONCE_S attribute, followed by the
      contents of the MAC field from the AT_MAC attribute from
      EAP-Request/AKA-Reauthentication:

      Session-Id = 0x17 || NONCE_S || MAC

Notes:

RFC 5247 was supposed to define exported parameters for existing EAP methods in Appendix A. The way Session-Id was defined for EAP-AKA and EAP-SIM works only for the full authentication case, i.e., it cannot be used when the optional fast re-authentication case is used since the used parameters (RAND, AUTN, NONCE_MT) are not used in the fast re-authentication case. Based on RFC 4187 chapter 5.2 (and similar chapter in RFC 4186), NONCE_S corresponds to RAND and MAC in EAP-Request/AKA-Reauthentication corresponds to AUTN. That would seem to imply that the Session-Id could be defined using NONCE_S and MAC instead of RAND and AUTN/NONCE_MT.

The corrected text in this errata shows the changes for EAP-AKA. Similar changes should be done for EAP-SIM (replace RAND || NONCE_MT with NONCE_S || MAC for fast re-authentication).

It should be noted that EAP-AKA' (RFC 5448) specification did not follow the MUST requirement in RFC 5247, i.e., it did not define Session-Id derivation. That could be done in an update of RFC 5247 with a clone of EAP-AKA design.

In addition, RFC 5247 did not define Session-Id definition for PEAP and there does not seem to exist any IETF RFC which such definition. That could also be included in RFC 5247 update and done similarly to EAP-TLS (Session-Id = EAP type || client.random || server.random).

It would be good to have a clear IETF reference for these details since EAP Session-Id is needed for ERP (RFC 6696) and that is now seeing additional implementation and deployment interest as a component of FILS authentication (IEEE 802.11ai). Same definition of EAP Session-Id is needed to make FILS shared key authentication implementation interoperable.

Errata ID: 1711
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yoshihiro Ohba
Date Reported: 2008-12-20
Held for Document Update by: Brian Haberman
Date Held: 2009-03-11

Section 4 says:

   EAP pre-authentication
      In EAP pre-authentication, an EAP peer pre-establishes EAP keying
      material with an authenticator prior to arrival.  EAP
      pre-authentication only affects the timing of EAP authentication,
      but does not shorten or eliminate EAP (phase 1a) or AAA (phase 1b)
      exchanges;  Discovery (phase 0) and Secure Association Protocol
      (phase 2) exchanges occur as described in Section 1.3.  As a
      result, the primary benefit is to enable EAP authentication to be
      removed from the handoff critical path, thereby reducing latency.
      Use of EAP pre-authentication within IEEE 802.11 is described in
      [IEEE-802.11] and [8021XPreAuth].

   Proactive key distribution
      In proactive key distribution, keying material and authorizations
      are transported from the backend authentication server to a
      candidate authenticator in advance of a handoff.  As a result, EAP
      (phase 1a) is not needed, but the Discovery (phase 0), and Secure
      Association Protocol exchanges (phase 2) are still necessary.
      Within the AAA exchange (phase 1b), authorization and key
      distribution functions are typically supported, but not
      authentication.  Proactive key distribution is described in
      [MishraPro], [IEEE-03-084], and [HANDOFF].

It should say:

Move the reference 8021XPreAuth to the second paragraph.

Notes:

The reference [8021XPreAuth] describes a mechanism in which EAP
authentication happens only once with the serving authenticator, i.e.,
one EAP authentication with the serving authenticator generates
multiple MSKs and distributed to serving authenticator and target
authenticator, and there is no additional EAP authentication
performed between peer and target authenticator. This does not match
the definition of pre-authentication as described by the first paragraph;
hence the reference should be moved to the second paragraph.

RFC 5250, "The OSPF Opaque LSA Option", July 2008

Source of RFC: ospf (rtg)

Errata ID: 2981
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Gary Cote
Date Reported: 2011-09-28
Held for Document Update by: Stewart Bryant
Date Held: 2012-02-21

Section 3 says:

Section 7 describes Opaque type allocation and assignment.

It should say:

Section 9 describes Opaque type allocation and assignment.

Notes:

Section 7 was the "IANA Considerations" section in the previous RFC, 2370.
IANA Considerations are included in Section 9 of this document.

===

The reporter is correct in his report of the error and its root cause. However this error is unlikely to cause implementation or interoperability issues and can thus wait to be fixed when the RFC is revised.

Errata ID: 2982
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Gary Cote
Date Reported: 2011-09-28
Held for Document Update by: Stewart Bryant
Date Held: 2012-02-21

Section A.2 says:

See section 7 of this document for a description of Opaque type allocation and assignment.

It should say:

See section 9 of this document for a description of Opaque type allocation and assignment.

Notes:

Section 7 was the "IANA Considerations" section in the previous RFC, 2370.

IANA Considerations are included in Section 9 of this document.

===

The reporter is correct in his report of the error and its root cause. However this error is unlikely to cause implementation or interoperability issues and can thus wait to be fixed when the RFC is revised.

Errata ID: 5287
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Angelos Vassiliou
Date Reported: 2018-03-14
Held for Document Update by: Alvaro Retana
Date Held: 2018-03-14

Section 7 says:

inter-area procedures described in Section 6 of this document.

It should say:

inter-area procedures described in Section 5 of this document.

Notes:

Inter-Area Considerations are discussed in Section 5, not Section 6.

RFC 5251, "Layer 1 VPN Basic Mode", July 2008

Source of RFC: l1vpn (rtg)

Errata ID: 1558
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-10-09
Held for Document Update by: Adrian Farrel

Section 4.4, pg.19 says:

   Signaling:

   A CE requests a network-protected LSP (i.e., an LSP that is protected
|  from PE-to-PE) by using the technique described in [RFC4873].
   [...]

It should say:

   Signaling:

   A CE requests a network-protected LSP (i.e., an LSP that is protected
|  from PE to PE) by using the technique described in [RFC4873].
   [...]

Notes:

Rationale: distorting hyphens

RFC 5252, "OSPF-Based Layer 1 VPN Auto-Discovery", July 2008

Source of RFC: l1vpn (rtg)

Errata ID: 3310
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kris Michielsen
Date Reported: 2012-08-07
Held for Document Update by: Adrian Farrel

Section 2.1 says:

   L1VPN Info TLV
      A single TLV, as defined in Section 3.2, MUST be present.  If more
      than one L1VPN Info TLV is present, only the first TLV is
      processed and the others MUST be ignored on receipt.

It should say:

   L1VPN Info TLV
      A single TLV, as defined in Section 2.2, MUST be present.  If more
      than one L1VPN Info TLV is present, only the first TLV is
      processed and the others MUST be ignored on receipt.

RFC 5254, "Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)", October 2008

Source of RFC: pwe3 (int)

Errata ID: 1578
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-10-24
Held for Document Update by: Stewart Bryant
Date Held: 2012-02-14

Section 1.2, pg. 4 says:

         Native  |<--------Multi-Segment Pseudowire----->|  Native
         Service |         PSN              PSN          |  Service
          (AC)   |     |<-Tunnel->|     |<-Tunnel->|     |  (AC)
           |     V     V     1    V     V     2    V     V   |
           |     +-----+          +-----+          +---- +   |
   +---+   |     |T-PE1|==========|S-PE1|==========|T-PE2|   |    +---+
   |   |---------|........PW1.......... |...PW3..........|---|----|   |
   |CE1|   |     |     |          |     |          |     |   |    |CE2|
   |   |---------|........PW2...........|...PW4..........|--------|   |
   +---+   |     |     |==========|     |==========|     |   |    +---+
       ^         +-----+          +-----+          +-----+        ^
       |     Provider Edge 1         ^        Provider Edge 3     |
       |                             |                            |
       |                             |                            |
       |                     PW switching point                   |
       |                                                          |
       |                                                          |
       |<------------------- Emulated Service ------------------->|

                Figure 2: PW Switching Reference Model

   Figure 2 extends this architecture to show a multi-segment case.
   Terminating PE1 (T-PE1) and Terminating PE3 (T-PE3) provide PWE3
   service to CE1 and CE2.  These PEs terminate different PSN tunnels,
   PSN Tunnel 1 and PSN Tunnel 2, and may reside in different PSN or
   pseudowire domains.  One PSN tunnel extends from T-PE1 to S-PE1
   across PSN1, and a second PSN tunnel extends from S-PE1 to T-PE2
   across PSN2.

It should say:

         Native  |<--------Multi-Segment Pseudowire----->|  Native
         Service |         PSN              PSN          |  Service
          (AC)   |     |<-Tunnel->|     |<-Tunnel->|     |  (AC)
           |     V     V     1    V     V     2    V     V   |
           |     +-----+          +-----+          +---- +   |
   +---+   |     |T-PE1|==========|S-PE2|==========|T-PE3|   |    +---+
   |   |---------|........PW1.......... |...PW3..........|---|----|   |
   |CE1|   |     |     |          |     |          |     |   |    |CE2|
   |   |---------|........PW2...........|...PW4..........|--------|   |
   +---+   |     |     |==========|     |==========|     |   |    +---+
       ^         +-----+          +-----+          +-----+        ^
       |     Provider Edge 1         ^        Provider Edge 3     |
       |                             |                            |
       |                             |                            |
       |                     PW switching point                   |
       |                                                          |
       |                                                          |
       |<------------------- Emulated Service ------------------->|

                Figure 2: PW Switching Reference Model

   Figure 2 extends this architecture to show a multi-segment case.
   Terminating PE1 (T-PE1) and Terminating PE3 (T-PE3) provide PWE3
   service to CE1 and CE2.  These PEs terminate different PSN tunnels,
   PSN Tunnel 1 and PSN Tunnel 2, and may reside in different PSN or
   pseudowire domains.  One PSN tunnel extends from T-PE1 to S-PE2
   across PSN1, and a second PSN tunnel extends from S-PE2 to T-PE2
   across PSN2.

Notes:

Rationale:

The original diagram was inconsistent. The proposed edits correct this inconsistency. Specifically the PEs are now labels xPE1, xPE2, xPE3 across
the page and the text is modified accordingly.


The erratum is technically correct, but since the purpose of this RFC was to establish the requirements in RFC5659 and the error does not occur in RFC5659 the problem may be classified as fixed in update.

RFC 5257, "Internet Message Access Protocol - ANNOTATE Extension", June 2008

Source of RFC: imapext (app)

Errata ID: 3069
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Chris Newman
Date Reported: 2011-12-28
Held for Document Update by: Pete Resnick

Section 1 says:

   In order to provide optimum support for a disconnected client (one
   that needs to synchronize annotations for use when offline), servers
   SHOULD also support the Conditional STORE [RFC4551] extension.

It should say:

   In order to provide optimum support for a disconnected client (one
   that needs to synchronize annotations for use when offline), servers
   SHOULD also support the Conditional STORE [RFC4551] extension.

   If the server advertises ANNOTATE and either CONDSTORE [RFC4551]
   or QRESYNC [RFC5162], then the server MUST update the MODSEQ when
   an annotation is modified.

Notes:

This probably should go to "hold for document update" state. It's debatable whether this is a clarification of existing text here and in section 4.5 or a technical change.

RFC 5261, "An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors", September 2008

Source of RFC: simple (rai)

Errata ID: 3458
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Erik Wilde
Date Reported: 2013-01-16
Held for Document Update by: Gonzalo Camarillo

Section 8 says:

<!ENTITY id     "id\(('&ncname;')?\)|id\((&quot;&ncname;&quot;)?\)">

It should say:

<!ENTITY id     "id\('&ncname;'\)|id\(&quot;&ncname;&quot;\)">

Notes:

The regex in the XSD suggests that "id()" would be a valid selector for a patch, but it would not make sense to specify such a selector since it never would select a node (there's no identifier to locate in the document). This means that while "id()" is a valid XPath expression, it should not be allowed as a selector expression within an XML patch document.

Errata ID: 3465
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Erik Wilde
Date Reported: 2013-01-18
Held for Document Update by: Gonzalo Camarillo

Section 4.2.3 says:

- Lastly, if the above two rules still don't apply, first all
  in-scope namespace prefixes of the evaluation context node are
  arranged alphabetically in an ascending order. 

It should say:

n/a

Notes:

It is not entirely clear what "arranged alphabetically" refers to in this section. Sorting can be done in a variety of ways, and while many environment may have standard sort orders, not all are the same and for this standard to be implement consistently it's important to clearly state what sort order the above sentence is referring to. The suggested fix for this erratum is to add text that clearly states which sorting method should be used.

Errata ID: 3477
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Erik Wilde
Date Reported: 2013-02-05
Held for Document Update by: Gonzalo Camarillo

Section 4.2.2 says:

In XPath 2.0, a "bar" selector
not only matches an unqualified <bar> element, but also matches a
qualified <bar> element that is in scope of a default namespace
declaration.  In contrast, in this specification, a selector without
a prefix only matches one element, and it may match an element with
or without a prefix but only if the namespace it's qualified with (or
none) is an exact match.

It should say:

In XPath 2.0, a "bar" selector matches elements that have the URI of 
the "default element/type namespace", which is part of an XPath's 
static context. By setting this URI to the default namespace of the 
diff document (or leave it empty, if there is none), XPath 2.0's 
behavior matches the requirements of the previous section.

Notes:

The original text is not easy to understand, but seems to assume that an unprefixed name in XPath 2.0 matches both unprefixed names, and prefixed ones that have the same namespace than the default namespace of the XPath static context. This is not the case: Matching depends on how the "default element/type namespace" of the XPath static context is defined, and then matches either namespace-less elements, or those in the "default element/type namespace", but never both. This context, however, is defined by the XPath itself, not by the document. Thus, it can be set externally and could be set to the diff document's default namespace (if there is one). In that case, XPath 2.0 can be used to evaluate XML Patch selectors.

Errata ID: 3478
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Erik Wilde
Date Reported: 2013-02-07
Held for Document Update by: Gonzalo Camarillo

Section 4.4.3 says:

4.4.3. Replacing a Namespace Declaration URI


   An example for a replacement of a namespace URI:

   <replace sel="doc/namespace::pref">urn:new:xxx</replace>

   This will replace the URI value of 'pref' prefixed namespace node
   with "urn:new:xxx".  The parent node of the namespace declaration
   MUST be the <doc> element, otherwise an error occurs.

It should say:

4.4.3. Replacing a Namespace URI


   An example for a replacement of a namespace URI:

   <replace sel="doc/namespace::pref">urn:new:xxx</replace>

   This will replace the URI of the namespace associated with the
   'pref' prefix with "urn:new:xxx". The parent node of the namespace
   declaration MUST be the <doc> element, otherwise an error occurs.
   Replacing the namespace at the element where it is declared MUST
   also change all namespace nodes derived from this declaration in
   descendant elements. 

Notes:

The spec uses the terms "namespace declaration" and "namespace" almost interchangeably, which is incorrect. It is impossible to select (and thus patch) *namespace declarations* using XPath. When selecting and replacing a *namespace*, then it should be taken into account that the *namespace declaration* very likely has resulted in numerous namespace nodes, attached to child elements of the element where the namespace was declared. It is likely that the spec intended to specify a "recursive replace" of the resulting namespace nodes of a namespace declaration, and this is what the corrected text suggests. The original text is mixing terminology, hard to read, and ambiguous in its meaning.

If the spec text instead tried to specify that really only this one namespace node should be changed, then this can lead to rather strange effects in the resulting document, since the XPath tree now has "orphan" namespace nodes, which then need to be serialized and namespace declarations in locations where previously no namespace declarations occurred.

One way or the other, this ambiguity needs to be clarified to make the spec easier to read and implement.

RFC 5272, "Certificate Management over CMS (CMC)", June 2008

Note: This RFC has been updated by RFC 6402

Source of RFC: pkix (sec)

Errata ID: 2731
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sean Turner
Date Reported: 2011-02-23
Held for Document Update by: Tim Polk

Section 2.2 says:

Full PKI Response
------------------------
+----------------+
| CMS ContentInfo|
| CMS SignedData |
|   or Auth Data |
|     object     |
+----------------+--------+
|                         |
| PKIResponseBody         |

It should say:

Full PKI Response
------------------------
+----------------+
| CMS ContentInfo|
| CMS SignedData |
|   or Auth Data |
|     object     |
+----------------+--------+
|                         |
| PKIResponse             |

Notes:

PKIResponse should be PKIResponse. It's the name of the content type. PKIResponseBody only appears once in this RFC and it's in Figure 2.

RFC 5273, "Certificate Management over CMS (CMC): Transport Protocols", June 2008

Note: This RFC has been updated by RFC 6402

Source of RFC: pkix (sec)

Errata ID: 3593
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sean Turner
Date Reported: 2013-04-16
Held for Document Update by: Stephen Farrell

Section s3 says:

"CMC-Request"

It should say:

"CMC-request"

Notes:

The text before Table 1 indicate the SMIME type parameters is "CMC-Request" but the table uses "CMC-request". I marked this as editorial because I think implementers can figure this out, but I thought I'd submit it anyway

RFC 5279, "A Uniform Resource Name (URN) Namespace for the 3rd Generation Partnership Project (3GPP)", July 2008

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 2626
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-09-15
Held for Document Update by: Peter Saint-Andre
Date Held: 2010-11-12

Section 3 says:

Notes:

Furthermore, the second example presented in Section 3 of RFC 5279
does not precisely match the pattern indicated in the above clause;
instead, it tries to suggest that

urn:3gpp:acme.foo-serv

defines a '3gpp' URN

... identified by the "3gpp-urn" value "acme".

This contradiction seems to be a hint that the authors indeed
want to define a structured NSS with <3gpp-urn> being the most
significant part, and the period character used to separate it
from a potentially following more specific part of the '3gpp' URN.
Yet, there's no syntax definition in the RFC that would support
this precisely.

RFC 5280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", May 2008

Note: This RFC has been updated by RFC 6818, RFC 8398, RFC 8399, RFC 9549

Source of RFC: pkix (sec)

Errata ID: 3200
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: David Mandelberg
Date Reported: 2012-04-24
Held for Document Update by: Sean Turner

Section 4.1.2.2 says:

   The serial number MUST be a positive integer assigned by the CA to
   each certificate.  It MUST be unique for each certificate issued by a
   given CA (i.e., the issuer name and serial number identify a unique
   certificate).  CAs MUST force the serialNumber to be a non-negative
   integer.

It should say:

   The serial number MUST be a positive non-zero integer assigned by the
   CA to each certificate.  It MUST be unique for each certificate issued
   by a given CA (i.e., the issuer name and serial number identify a
   unique certificate).  CAs MUST force the serialNumber to be a positive
   integer.

Notes:

"positive" and "non-negative" do not mean the same thing. I used the third paragraph of the section as a tie-breaker to decide which of the two terms was intended:

Note: Non-conforming CAs may issue certificates with serial numbers
that are negative or zero. Certificate users SHOULD be prepared to
gracefully handle such certificates.

Errata ID: 5876
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: David Woodhouse
Date Reported: 2019-10-16
Held for Document Update by: Benjamin Kaduk
Date Held: 2019-10-20

Section 4.2.1.6 says:

   When the subjectAltName extension contains an iPAddress, the address
   MUST be stored in the octet string in "network byte order", as
   specified in [RFC791]. 

It should say:

   When the subjectAltName extension contains an IP address, the address
   MUST be stored in the iPAddress (an octet string). The address 
   MUST be stored in the octet string in "network byte order", as
   specified in [RFC791]. 

Notes:

For email addresses and domain names, this section is very prescriptive:

When the subjectAltName extension contains an Internet mail address,
the address MUST be stored in the rfc822Name.
...
When the subjectAltName extension contains a domain name system
label, the domain name MUST be stored in the dNSName…

However, for IP addresses, it's possible to interpret the current wording as saying that *if* you happen to choose the iPAddress form for an IP address, then you must represent that as big-endian. I suspect this was a poor choice of wording and the intent was to say that you MUST use the iPAddress form for an IP address.

Errata ID: 5997
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Ryan Sleevi
Date Reported: 2020-02-27
Held for Document Update by: Benjamin Kaduk
Date Held: 2020-03-17

Section 4.2.1.10 says:

   DNS name restrictions are expressed as host.example.com.  Any DNS
   name that can be constructed by simply adding zero or more labels to
   the left-hand side of the name satisfies the name constraint.  For
   example, www.host.example.com would satisfy the constraint but
   host1.example.com would not.

It should say:

   For DNS names, restrictions MUST use the dNSName syntax in
   Section 4.2.1.6.  Any DNS name that can be constructed by simply
   adding zero or more labels to the left-hand side of the name satisfies
   the name constraint.  For example, if the constraint contains
   host.example.com, then www.host.example.com would satisfy the
   constraint but host1.example.com would not.

Notes:

Currently, the syntax for a dNSName nameConstraint is left implicit, and thus has resulted in ambiguities in encoding and processing that have resulted in ineroperability issues.

One interpretation is that the dNSName nameConstraint must be a valid "host name" (as discussed in RFC 8499), which is to say must be a Fully-Qualified Domain Name in the preferred name syntax. This interpretation is supported by Section 4.2.1.6, which explicitly states that for the subjectAltName. As 4.2.1.10 does not define an exception to this (as discussed in Appendix B), the interpretation, along with the existing example, would conclude that this field uses preferred name syntax, and that "DNS name" here matches the "host name" interpretation from RFC 8499

A different interpretation is that the dNSName nameConstraint uses the modified syntax similar to the URI nameConstraint. That is, it explicitly permits a leading period to indicate that one or more labels preceding is required in order to satisfy the constraint. This allows subdomains, but does not allow the base domain to match. While the language for the DNS name constraint makes it clear that a host name with no preceding period matches both that host and sub-domains, the existence of a preceding period would constraint it to only subdomains.

Aligning with Section 4.2.1.6 would prohibit the latter interpretation, as the preferred name syntax does not permit leading periods. Alternatively, if the latter interpretation is intended, this section would benefit from making that explicit.

This has been a source of interoperability issues, with additional information and discussion captured at:
- https://github.com/golang/go/issues/16347
- https://rt.openssl.org/Ticket/Display.html?id=3562

While "running code" has aligned in being permissive with a leading period, implementations have gone and seemingly aligned on a third interpretation:

The syntax of a dNSName MUST be as described in Section 4.2.1.6, with the exception that it MAY contain a leading period. Any DNS name that can be constructed by simply adding zero or more labels to the left-hand side of the name, ignoring any leading period, satisfies the name constraint.

This seems to support implementations expecting the first interpretation in the certificates they receive, and seeing leading period as an encoding mistake, not an explicit desire for the second interpretation.

Errata ID: 3466
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Annie Yousar
Date Reported: 2013-01-18
Held for Document Update by: Sean Turner

Section 4.2.1.6 says:

   If the subjectAltName extension is present, the sequence MUST contain
   at least one entry.  Unlike the subject field, conforming CAs MUST
|  NOT issue certificates with subjectAltNames containing empty
   GeneralName fields.  For example, an rfc822Name is represented as an
   IA5String.  While an empty string is a valid IA5String, such an
   rfc822Name is not permitted by this profile. 

It should say:

   If the subjectAltName extension is present, the sequence MUST contain
   at least one entry.  Unlike the subject field, conforming CAs MUST
|  NOT issue certificates with subjectAltName extensions containing empty
   GeneralName fields.  For example, an rfc822Name is represented as an
   IA5String.  While an empty string is a valid IA5String, such an
   rfc822Name is not permitted by this profile. 

Notes:

Certificates do not have "subjectAltNames" but only "subjectAltName extensions", which is the correct wording that is thoroughly used in the document.

Errata ID: 3674
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Piyush Jain
Date Reported: 2013-06-28
Held for Document Update by: Sean Turner

Section 6.3.3 says:

If the distribution point name is present in the IDP CRL 
extension and the distribution field is present in the DP, 
then verify that one of the names in the IDP matches one 
of the names in the DP.

It should say:

If the distribution point name is present in the IDP CRL 
extension and the distributionPoint field is present in 
the DP, then verify that one of the names in the IDP 
matches one of the names in the DP.

Notes:

Original text refers to the non existent field "distribution" in DP.

Errata ID: 3754
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michal Bozon
Date Reported: 2013-10-16
Held for Document Update by: Sean Turner
Date Held: 2013-10-16

Section A.1 says:

-- Naming attributes of type X520countryName (digraph from IS 3166)

It should say:

-- Naming attributes of type X520countryName (digraph from ISO 3166)

Notes:

typo in ASN.1 comment ("IS", should be "ISO")

Errata ID: 4274
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ilya V. Matveychikov
Date Reported: 2015-02-19
Held for Document Update by: Kathleen Moriarty
Date Held: 2015-03-25

Section A.1 says:

-- Naming attributes of type X520CommonName:
--   X520CommonName ::= DirectoryName (SIZE (1..ub-common-name))

...

-- Naming attributes of type X520LocalityName:
--   X520LocalityName ::= DirectoryName (SIZE (1..ub-locality-name))

...

-- Naming attributes of type X520StateOrProvinceName:
--   X520StateOrProvinceName ::= DirectoryName (SIZE (1..ub-state-name))

...

-- Naming attributes of type X520OrganizationName:
--   X520OrganizationName ::=
--          DirectoryName (SIZE (1..ub-organization-name))

...

-- Naming attributes of type X520OrganizationalUnitName:
--   X520OrganizationalUnitName ::=
--          DirectoryName (SIZE (1..ub-organizational-unit-name))

...

-- Naming attributes of type X520Title:
--   X520Title ::= DirectoryName (SIZE (1..ub-title))

...

-- Naming attributes of type X520Pseudonym:
--   X520Pseudonym ::= DirectoryName (SIZE (1..ub-pseudonym))

It should say:

-- Naming attributes of type X520CommonName:
--   X520CommonName ::= DirectoryString (SIZE (1..ub-common-name))

...

-- Naming attributes of type X520LocalityName:
--   X520LocalityName ::= DirectoryString (SIZE (1..ub-locality-name))

...

-- Naming attributes of type X520StateOrProvinceName:
--   X520StateOrProvinceName ::=
--          DirectoryString (SIZE (1..ub-state-name))

...

-- Naming attributes of type X520OrganizationName:
--   X520OrganizationName ::=
--          DirectoryString (SIZE (1..ub-organization-name))

...

-- Naming attributes of type X520OrganizationalUnitName:
--   X520OrganizationalUnitName ::=
--          DirectoryString (SIZE (1..ub-organizational-unit-name))

...

-- Naming attributes of type X520Title:
--   X520Title ::= DirectoryString (SIZE (1..ub-title))

...

-- Naming attributes of type X520Pseudonym:
--   X520Pseudonym ::= DirectoryString (SIZE (1..ub-pseudonym))

Notes:

Appendix B. ASN.1 Notes says that:

For many of the attribute types defined in [X.520], the
AttributeValue uses the DirectoryString type. Of the attributes
specified in Appendix A, the name, surname, givenName, initials,
generationQualifier, commonName, localityName, stateOrProvinceName,
organizationName, organizationalUnitName, title, and pseudonym
attributes all use the DirectoryString type. X.520 uses a
parameterized type definition [X.683] of DirectoryString to specify
the syntax for each of these attributes. The parameter is used to
indicate the maximum string length allowed for the attribute. In
Appendix A, in order to avoid the use of parameterized type
definitions, the DirectoryString type is written in its expanded form
for the definition of each of these attribute types. So, the ASN.1
in Appendix A describes the syntax for each of these attributes as
being a CHOICE of TeletexString, PrintableString, UniversalString,
UTF8String, and BMPString, with the appropriate constraints on the
string length applied to each of the types in the CHOICE, rather than
using the ASN.1 type DirectoryString to describe the syntax.

There is nothing about DirectoryName type here. So comments in ASN.1 in
A.1 are wrong and DirectoryName should be fixed to DirectoryString.

From Expert PKIX reviewers:
The errata calls for changing "DirectoryName" to "DirectoryString" in the comments
of the ASN.1. Nobody seems to disagree with this correction.

This message triggered a lot of discussion about whether to remove the string size limits.
That discussion ended with consensus to retain the size limits.

Errata ID: 4847
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Annie Yousar
Date Reported: 2016-10-30
Held for Document Update by: Stephen Farrell
Date Held: 2016-10-31

Section A.1 says:

    id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
            -- arc for policy qualifier types
    id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
|           -- arc for extended key purpose OIDS
    id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
            -- arc for access descriptors

It should say:

    id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
            -- arc for policy qualifier types
    id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
|           -- arc for extended key purpose OIDs
    id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
            -- arc for access descriptors

Notes:

"Object Identifiers" are abbreviated as "OIDs" and not as "OIDS".

RFC 5283, "LDP Extension for Inter-Area Label Switched Paths (LSPs)", July 2008

Source of RFC: mpls (rtg)

Errata ID: 1731
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-03-17
Held for Document Update by: Adrian Farrel

Section 6.1, Fig.1 says:

[[ Top part of Figure 1 (page 6): ]]

                        Area "B"

                 Level 2 / Backbone area
              +--------------------------+
     Area "A" |                          |  Area "C"
              |                          |
|    Level 1  |                          |  Level 1 / area
              |        P1                |
   +----------+                          +-------------+

It should say:

                        Area "B"

                 Level 2 / Backbone area
              +--------------------------+
     Area "A" |                          |  Area "C"
              |                          |
|    Level 1  |                          |  Level 1
              |        P1                |
   +----------+                          +-------------+

Notes:

Rationale: balance the annotation, avoid replicated "area"
-- keep for update! --

Errata ID: 1732
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-03-17
Held for Document Update by: Adrian Farrel

Section 7.2, pg.8 says:

|         [...]  Currently, with most routers implementations, ...
                                            ^

It should say:

|         [...]  Currently, with most router implementations, ...

Notes:

Typo/grammar; keep for update!

RFC 5295, "Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)", August 2008

Source of RFC: hokey (sec)

Errata ID: 1498
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-09-02
Held for Document Update by: Tim Polk

Section 7.5 says:

                           v 
                                                    [...].  Setting a
|  key lifetime shorter that a system lifetime may result in keys
   becoming invalid with no convenient way to refresh them.  [...]

It should say:

                           v
                                                     [...].  Setting a
|  key lifetime shorter than a system lifetime may result in keys
   becoming invalid with no convenient way to refresh them.  [...]

Errata ID: 1499
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-09-02
Held for Document Update by: Tim Polk
Date Held: 2010-03-22

Section 8, pg.16 says:

   The keywords "Private Use", "Specification Required", and "IETF
|  Consensus" that appear in this document when used to describe
   ^^^^^^^^^
   namespace allocation are to be interpreted as described in [RFC5226].

It should say:

   The keywords "Private Use", "Specification Required", and "IETF
|  Review" that appear in this document when used to describe namespace
   ^^^^^^
   allocation are to be interpreted as described in [RFC5226].

Notes:

RFC 5226 has purposely changed the terminology.
Updating the Ref. to RFC 5226 hence should have been accompanied by
upgrading the terminology.

This same issue recurs in the third line of Section 8.2 of RFC 5295.

RFC 5296, "EAP Extensions for EAP Re-authentication Protocol (ERP)", August 2008

Note: This RFC has been obsoleted by RFC 6696

Source of RFC: hokey (sec)

Errata ID: 1844
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Glen Zorn
Date Reported: 2009-08-31
Held for Document Update by: Tim Polk

Section 1 says:

The protocol that uses these extensions itself is referred to as 
the EAP Re-authentication Protocol (ERP).  

It should say:

The protocol that uses these extensions is itself referred to as 
the EAP Re-authentication Protocol (ERP).  

Notes:

Original text is awkward.

RFC 5298, "Analysis of Inter-Domain Label Switched Path (LSP) Recovery", August 2008

Source of RFC: ccamp (rtg)

Errata ID: 1730
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-03-17
Held for Document Update by: Adrian Farrel

Section 4.4.2, pg.15 says:

   Since both LSPs are computed in a single pass, the LSPs can be
|  signaled simultaneously of sequentially according to the preference
   of the head-end LSR.
                           ^^

It should say:

   Since both LSPs are computed in a single pass, the LSPs can be
|  signaled simultaneously or sequentially according to the preference
   of the head-end LSR.
                           ^^

Notes:

Distorting typo; keep for Update!

RFC 5301, "Dynamic Hostname Exchange Mechanism for IS-IS", October 2008

Note: This RFC has been updated by RFC 6232

Source of RFC: isis (rtg)

Errata ID: 1539
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-10-08
Held for Document Update by: Stewart Bryant
Date Held: 2011-01-28

Section 2, pg.3 says:

                         [...].  Another possible drawback might be the
   added complexity of DNS.  Also, some DNS implementations might not
|  support A and PTR records for Connection Network Service (CLNS)
   Network Service Access Points (NSAPs).

It should say:

                         [...].  Another possible drawback might be the
   added complexity of DNS.  Also, some DNS implementations might not
|  support A and PTR records for Connectionless-mode Network Service (CLNS)
   Network Service Access Points (NSAPs).

Notes:

Location is 2nd paragraph of Section 2, on top of page 3.

Rationale: Align with correct term in ISO/IEC 8348 clause 7

RFC 5302, "Domain-Wide Prefix Distribution with Two-Level IS-IS", October 2008

Source of RFC: isis (rtg)

Errata ID: 1541
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-10-08
Held for Document Update by: Adrian Farrel
Date Held: 2012-08-09

Section 3.1,1st para says:

   The combination IP Internal Reachability Information and external
   metric-type is not allowed.  Also, the up/down bit MUST NOT be set in
|  L2 LSPs.  This leaves us with 8 different types of IP advertisements
|  in IS-IS.  However, there are more than 8 reasons for IP prefixes to
   be advertised in IS-IS.  The following list describes the types of IP
   prefixes and how they are encoded.

It should say:

   The combination IP Internal Reachability Information and external
   metric-type is not allowed.  Also, the up/down bit MUST NOT be set in
|  L2 LSPs.  This leaves us with 9 different types of IP advertisements
|  in IS-IS.  However, there are more than 9 reasons for IP prefixes to
   be advertised in IS-IS.  The following list describes the types of IP
   prefixes and how they are encoded.

Notes:

Rationale:
Each of the two restrictions mentioned in the initial part
of the quoted paragraph indeed excludes 4 possibilities
of the original set of 16 combinations. However, these
restrictions are not exclusive; they overlap in one case,
thus reducing the number of forbidden combinations to 7.

Therefore, we are left with *9* different types of combinations.

This can also be seen from the subsequent list of 12 items
(unfortunately, the numbering of these has been lost on the way
from RFC 2966 to its successor). That list contains 3 pairs of
entries, i.e. 6 entries that contain the wording
"These prefixes cannot be distinguished from ... routes." ,
thus reducing the number of distinguishable cases from 12 to 9.

Virtually restoring the list item numbering as (1) ... (12),
the following table shows a decision matrix:

+----------------------+---------------+-------------------+
| Metric U/D \ Level | L1 | L2 |
| Type Bit \ TLV# | 128 | 130 | 128 | 130 |
+----------------------+-------+-------+---------+---------+
| 0 | (1) | (2) | (3),(5) | (4),(6) |
| Int --------------+-------+-------+---------+---------+
| 1 | (7) | (8) | N/A | N/A |
+----------------------+-------+-------+---------+---------+
| 0 | N/A | (9) | N/A |(10),(11)|
| Ext --------------+-------+-------+---------+---------+
| 1 | N/A | (12) | N/A | N/A |
+----------------------+-------+-------+---------+---------+

Errata ID: 1542
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-10-08
Held for Document Update by: Stewart Bryant

Section 5, 2nd para says:

                                              [...].  In this case, the
   solution defined in this document, which requires only an upgrade of
   L1L2 routers in selected areas, might be a good alternative to the
|  solution defined in 5305.

It should say:

                                              [...].  In this case, the
   solution defined in this document, which requires only an upgrade of
   L1L2 routers in selected areas, might be a good alternative to the
|  solution defined in RFC 5305.
                       ^^^^

Notes:

Rationale: inconsistent, too colloquial verbiage.

RFC 5303, "Three-Way Handshake for IS-IS Point-to-Point Adjacencies", October 2008

Source of RFC: isis (rtg)

Errata ID: 2589
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mohammad Fahad Imteyaz
Date Reported: 2010-10-29
Held for Document Update by: Adrian Farrel
Date Held: 2012-08-09

Section 3.2 says:

Add a section 8.2.4.1.1, "Three-Way Handshake", immediately prior to "IIH PDU Processing" (section 8.2.4.2 of [ISIS]):

It should say:

Add a section 8.2.5.1.1, "Three-Way Handshake", immediately prior to "IIH PDU Processing" (section 8.2.5.2 of [ISIS]):

Notes:

Though the ISIS reference name in "Normative References" have been updated to "International Standard 10589:2002, Second Edition, 2002" , the section reference was still to first edition of ISO 10589.

Errata ID: 2590
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mohammad Fahad Imteyaz
Date Reported: 2010-10-29
Held for Document Update by: Adrian Farrel
Date Held: 2012-08-09

Section 3.2 says:

      A received Point-to-Point IIH PDU may or may not contain the
      Point-to-Point Three-Way Adjacency option.  If it does not, the
      link is assumed to be functional in both directions, and the
      procedures described in section 8.2.4.2 are followed.

It should say:

      A received Point-to-Point IIH PDU may or may not contain the
      Point-to-Point Three-Way Adjacency option.  If it does not, the
      link is assumed to be functional in both directions, and the
      procedures described in section 8.2.5.2 are followed.

Notes:

Though the ISIS reference name in "Normative References" have been updated to "International Standard 10589:2002, Second Edition, 2002" , the section reference was still to first edition of ISO 10589.

Errata ID: 2591
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mohammad Fahad Imteyaz
Date Reported: 2010-10-29
Held for Document Update by: Adrian Farrel
Date Held: 2012-08-09

Section 3.2 says:

      If the Neighbor System ID and Neighbor Extended Local Circuit ID
      fields match those of the local system, or are not present, the
      procedures described in section 8.2.4.2 are followed with the
      following changes:

It should say:

      If the Neighbor System ID and Neighbor Extended Local Circuit ID
      fields match those of the local system, or are not present, the
      procedures described in section 8.2.5.2 are followed with the
      following changes:

Notes:

Though the ISIS reference name in "Normative References" have been updated to "International Standard 10589:2002, Second Edition, 2002" , the section reference was still to first edition of ISO 10589.

Errata ID: 2593
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mohammad Fahad Imteyaz
Date Reported: 2010-10-29
Held for Document Update by: Adrian Farrel
Date Held: 2012-08-09

Section 3.2 says:

      a) In section 8.2.4.2 a and b, the action "Up" from state tables
         5, 6, 7, and 8 may create a new adjacency but the three-way
         state of the adjacency SHALL be Down.

      b) If the action taken from section 8.2.4.2 a or b is "Up" or
         "Accept", the IS SHALL perform the action indicated by the new
         adjacency three-way state table below, based on the current
         adjacency three-way state and the received Adjacency Three-Way
         State value from the option.  (Note that the procedure works
         properly if neither field is ever included.  This provides
         backward compatibility to an earlier version of this option.)

                                 Received Adjacency Three-Way State
                                    Down       Initializing    Up
                              --------------------------------------
                 Down         |  Initialize        Up         Down
                              |
         Adj.    Initializing |  Initialize        Up         Up
         Three-               |
         Way     Up           |  Initialize        Accept     Accept
         State                |
                              |

                         Adjacency Three-Way State Table

         If the new action is "Down", an adjacencyStateChange(Down)
         event is generated with the reason "Neighbor restarted" and the
         adjacency SHALL be deleted.

         If the new action is "Initialize", no event is generated and
         the adjacency three-way state SHALL be set to "Initializing".

         If the new action is "Up", an adjacencyStateChange(Up) event is
         generated.

      c) Skip section 8.2.4.2 c and d.

      d) If the new action is "Initialize", "Up", or "Accept", follow
         section 8.2.4.2 e.

It should say:

      a) In section 8.2.5.2 a and b, the action "Up" from state tables
         5, 6, 7, and 8 may create a new adjacency but the three-way
         state of the adjacency SHALL be Down.

      b) If the action taken from section 8.2.5.2 a or b is "Up" or
         "Accept", the IS SHALL perform the action indicated by the new
         adjacency three-way state table below, based on the current
         adjacency three-way state and the received Adjacency Three-Way
         State value from the option.  (Note that the procedure works
         properly if neither field is ever included.  This provides
         backward compatibility to an earlier version of this option.)

                                 Received Adjacency Three-Way State
                                    Down       Initializing    Up
                              --------------------------------------
                 Down         |  Initialize        Up         Down
                              |
         Adj.    Initializing |  Initialize        Up         Up
         Three-               |
         Way     Up           |  Initialize        Accept     Accept
         State                |
                              |

                         Adjacency Three-Way State Table

         If the new action is "Down", an adjacencyStateChange(Down)
         event is generated with the reason "Neighbor restarted" and the
         adjacency SHALL be deleted.

         If the new action is "Initialize", no event is generated and
         the adjacency three-way state SHALL be set to "Initializing".

         If the new action is "Up", an adjacencyStateChange(Up) event is
         generated.

      c) Skip section 8.2.5.2 c and d.

      d) If the new action is "Initialize", "Up", or "Accept", follow
         section 8.2.5.2 e.

Notes:

Though the ISIS reference name in "Normative References" have been updated to "International Standard 10589:2002, Second Edition, 2002" , the section reference was still to first edition of ISO 10589. (replace 8.2.4.2 with 8.2.5.2 in the orignal text.

Errata ID: 2594
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mohammad Fahad Imteyaz
Date Reported: 2010-10-29
Held for Document Update by: Stewart Bryant
Date Held: 2011-01-28

Section 6 says:

   This document is a minor edit of [RFC3373] with the intent of
   advancing it from Informational to Standards Track.  It also updates
   the ISP 10589 reference to refer to the current "2002" version.

It should say:

   This document is a minor edit of [RFC3373] with the intent of
   advancing it from Informational to Standards Track.  It also updates
   the ISO/IEC 10589 reference to refer to the current "2002" version.

RFC 5307, "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", October 2008

Note: This RFC has been updated by RFC 6001, RFC 6002, RFC 7074

Source of RFC: isis (rtg)

Errata ID: 1552
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-10-09
Held for Document Update by: Adrian Farrel
Date Held: 2012-08-09

Section 1.1, pg.2 says:

1.1.  Link Local/Remote Identifiers

|  A Link Local Interface Identifier is a sub-TLV of the extended IS
   reachability TLV.  [...]

It should say:

1.1.  Link Local/Remote Identifiers

|  The Link Local/Remote Identifiers TLV is a sub-TLV of the extended IS
   reachability TLV.  [...]

Notes:

Rationale: Confusion in Terminology:
The term "Link Local Interface Identifier" does not
appear anywhere else in the document; the shorter form,
"Link Local Identifier" is used to denote a specific
component of the sub-TLV under consideration.
Hence, the precise name of the sub-TLV should be used.

Errata ID: 1553
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-10-09
Held for Document Update by: Stewart Bryant

Section 1.3, pg.5 says:

   The Minimum LSP Bandwidth is encoded in a 4-octet field in the IEEE
   floating point format.  The units are bytes (not bits!) per second.
   The Interface MTU is encoded as a 2-octet integer, and carries the
|  MTU value in the units of bytes.

It should say:

   The Minimum LSP Bandwidth is encoded in a 4-octet field in the IEEE
   floating point format.  The units are bytes (not bits!) per second.
   The Interface MTU is encoded as a 2-octet integer, and carries the
|  MTU value in units of bytes.

Notes:

Location is first paragraph below the diagram on page 5.

Rationale: Surprising use of article.

On the other hand, there are other places in the document
where an expected article is missing, for instance, the
same clause recurring four times in Sections 1.1 - 1.4,

The following illustrates encoding of ...

should better say:

The following illustrates the encoding of ...

RFC 5318, "The Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header)", December 2008

Note: This RFC has been updated by RFC 8217

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: gen

Errata ID: 4651
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Brett Tate
Date Reported: 2016-03-29
Held for Document Update by: Lars Eggert
Date Held: 2023-08-11

Section 5 says:

The members P-Header parameter MUST contain a cid-url, which is
defined in RFC 2392 [2].

It should say:

The members P-Header parameter MUST contain a cid-url, which is
defined in RFC 2392 [2].

If the URI contains a comma, question mark or semicolon, the URI
MUST be enclosed in angle brackets (< and >).

Notes:

Comma and semicolon can cause decode ambiguities when the header contains addr-spec values instead of name-addr values. For consistency with RFC 3261 section 20, the same bracket rule is indicated to resolve the ambiguity.

RFC 5321, "Simple Mail Transfer Protocol", October 2008

Note: This RFC has been updated by RFC 7504

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: art

Errata ID: 1543
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Brett Watson
Date Reported: 2008-10-08
Held for Document Update by: Pete Resnick

Section 3.8 says:

   SMTP clients that experience a connection close, reset, or other
   communications failure due to circumstances not under their control
   (in violation of the intent of this specification but sometimes
   unavoidable) SHOULD, to maintain the robustness of the mail system,
   treat the mail transaction as if a 451 response had been received and
   act accordingly.

It should say:

   SMTP clients that experience a connection close, reset, or other
   communications failure due to circumstances not under their control
   (in violation of the intent of this specification but sometimes
   unavoidable) SHOULD, to maintain the robustness of the mail system,
   treat the mail transaction as if a 421 response had been received and
   act accordingly.

Notes:

SMTP clients are told to act as though a 451 response ("Requested action aborted: local error in processing") had been received when context clearly indicates that a 421 response ("Service not available, closing transmission channel") was intended.

Errata ID: 4315
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Rodrigo Speller
Date Reported: 2015-03-27
Held for Document Update by: Barry Leiba
Date Held: 2015-03-28

Section 4.1.3 says:

   IPv6-full      = IPv6-hex 7(":" IPv6-hex)

   IPv6-comp      = [IPv6-hex *5(":" IPv6-hex)] "::"
                  [IPv6-hex *5(":" IPv6-hex)]
                  ; The "::" represents at least 2 16-bit groups of
                  ; zeros.  No more than 6 groups in addition to the
                  ; "::" may be present.

   IPv6v4-full    = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal

   IPv6v4-comp    = [IPv6-hex *3(":" IPv6-hex)] "::"
                  [IPv6-hex *3(":" IPv6-hex) ":"]
                  IPv4-address-literal
                  ; The "::" represents at least 2 16-bit groups of
                  ; zeros.  No more than 4 groups in addition to the
                  ; "::" and IPv4-address-literal may be present.

It should say:

   IPv6-full      = IPv6-hex 7(":" IPv6-hex)

   IPv6-comp      = "::" [IPv6-hex *6(":" IPv6-hex)]
                  | IPv6-hex "::" [IPv6-hex *5(":" IPv6-hex)]
                  | IPv6-hex 1(":" IPv6-hex) "::"
                  [IPv6-hex *4(":" IPv6-hex)]
                  | IPv6-hex 2(":" IPv6-hex) "::"
                  [IPv6-hex *3(":" IPv6-hex)]
                  | IPv6-hex 3(":" IPv6-hex) "::"
                  [IPv6-hex *2(":" IPv6-hex)]
                  | IPv6-hex 4(":" IPv6-hex) "::"
                  [IPv6-hex *1(":" IPv6-hex)]
                  | IPv6-hex 5(":" IPv6-hex) "::" [IPv6-hex]
                  | IPv6-hex 6(":" IPv6-hex) "::"
                  ; The "::" represents at least one 16-bit groups of
                  ; zeros.  No more than 7 groups in addition to the
                  ; "::" may be present.

   IPv6v4-full    = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal

   IPv6v4-comp    = ("::" [IPv6-hex *4(":" IPv6-hex) ":"] 
                  | IPv6-hex "::" [IPv6-hex *3(":" IPv6-hex) ":"]
                  | IPv6-hex 1(":" IPv6-hex) "::"
                  [IPv6-hex *2(":" IPv6-hex) ":"]
                  | IPv6-hex 2(":" IPv6-hex) "::"
                  [IPv6-hex *1(":" IPv6-hex) ":"]
                  | IPv6-hex 3(":" IPv6-hex) "::" [IPv6-hex ":"]
                  | IPv6-hex 4(":" IPv6-hex) "::")
                  IPv4-address-literal
                  ; The "::" represents at least one 16-bit groups of
                  ; zeros.  No more than 5 groups in addition to the
                  ; "::" and IPv4-address-literal may be present.

Notes:

I had the same impression that Michael Rushton (Errata 2467).

Searching about what says the others RFCs ([RFC 3986] , [RFC 4291] , [RFC 5952]), I believe that Michael Rushton's affirmative may be right.


Case 1 - Section 3.2.2 of [RFC 3986] says:

"(...) A sequence of one or more consecutive zero-valued 16-bit pieces within the address may be elided, omitting all their digits and leaving exactly two consecutive colons in their place to mark the elision." (sic).


Transcription of Section 3.2.2 of [RFC 3986]

"(...)

A 128-bit IPv6 address is divided into eight 16-bit pieces. Each piece is represented numerically in case-insensitive hexadecimal, using one to four hexadecimal digits (leading zeroes are permitted). The eight encoded pieces are given most-significant first, separated by colon characters. Optionally, the least-significant two pieces may instead be represented in IPv4 address textual format. A sequence of one or more consecutive zero-valued 16-bit pieces within the address may be elided, omitting all their digits and leaving exactly two consecutive colons in their place to mark the elision.

(...)"



Case 2 - Section 2.2 of [RFC 4291] says:

"(...) The use of "::" indicates one or more groups of 16 bits of zeros. (...)" (sic).


Transcription of Item 2, Section 2.2 of [RFC 4291]

"2. Due to some methods of allocating certain styles of IPv6 addresses, it will be common for addresses to contain long strings of zero bits. In order to make writing addresses containing zero bits easier, a special syntax is available to compress the zeros. The use of "::" indicates one or more groups of 16 bits of zeros. The "::" can only appear once in an address. The "::" can also be used to compress leading or trailing zeros in an address.

(...)"



Case 3 - Recommendations of [RFC 5952]

In reply to the question of Errata 2467, was quoted the words of Section 4.2.2 of [RFC 5952], that recommends:

"The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field. For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but 2001:db8::1:1:1:1:1 is not correct." (sic).


But the Section 4 of the same RFC, says:

"(...) The recommendation in this section SHOULD be followed by systems when generating an address to be represented as text, but all implementations MUST accept and be able to handle any legitimate [RFC4291] format."


Transcription of Section 4 and 4.2.2 of [RFC 5952]

"4. A Recommendation for IPv6 Text Representation

A recommendation for a canonical text representation format of IPv6 addresses is presented in this section. The recommendation in this document is one that complies fully with [RFC4291], is implemented by various operating systems, and is human friendly. The recommendation in this section SHOULD be followed by systems when generating an address to be represented as text, but all implementations MUST accept and be able to handle any legitimate [RFC4291] format. It is advised that humans also follow these recommendations when spelling an address.

(...)

4.2.2. Handling One 16-Bit 0 Field

The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field. For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but 2001:db8::1:1:1:1:1 is not correct.

(...)"



Therefore, it is clear that the intent of what was said in Section 4.2.2 only serves to standardize the generation and not to interpretation of a IPv6 representation.



For more explanations see:

RFC 4291 - Errata 2702, 2735 and 2466
http://www.rfc-editor.org/errata_search.php?rfc=4291

RFC 4291 - Errata 2735 discussion
http://www.ietf.org/mail-archive/web/v6ops/current/msg07722.html



[RFC 3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.

[RFC 4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.

[RFC 5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010.

===== Verifier notes =====
The text in 5321 was correct at the time of publication, according to advice from the IPv6 folks. This was, of course, well before 5952 came out. This report has been noted in the notes for a future 5321bis document.

Errata ID: 5414
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: David Romerstein
Date Reported: 2018-06-29
Held for Document Update by: Barry Leiba
Date Held: 2019-11-13

Section 4.1.2 says:

Quoted-string  = DQUOTE *QcontentSMTP DQUOTE

It should say:

Quoted-string  = DQUOTE 1*QcontentSMTP DQUOTE

Notes:

As written, this allows for an email envelope recipient (Forward-path) with a NULL value for the local part of their address. This is a functional departure from similar wording in the preceding RFC 821, which defines quoted-string in such a way as to require at least one character that is not one of the surrounding quotation marks.

Errata ID: 1851
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alessandro Vesely
Date Reported: 2009-09-08
Held for Document Update by: Pete Resnick

Section 4.1.1.5. says:

There are circumstances, contrary to the intent of this
specification, in which an SMTP server may receive an indication that
the underlying TCP connection has been closed or reset.  To preserve
the robustness of the mail system, SMTP servers SHOULD be prepared
for this condition and SHOULD treat it as if a QUIT had been received
before the connection disappeared.

Notes:

That text seems inappropriate in the RESET (RSET) section. It should presumably be moved to section 4.1.1.10. QUIT (QUIT), or, better yet, to section 3.8. Terminating Sessions and Connections.

Errata ID: 3447
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Adrien de Croy
Date Reported: 2013-01-07
Held for Document Update by: Barry Leiba
Date Held: 2013-01-09

Section 4.4 says:

When the delivery SMTP server makes the "final delivery" of a
   message, it inserts a return-path line at the beginning of the mail
   data.  This use of return-path is required; mail systems MUST support
   it.

...

SMTP servers performing
   a relay function MUST NOT inspect the message data

...

For this to be unambiguous, exactly one return path
   SHOULD be present when the message is delivered.

It should say:

When the delivery SMTP server makes the "final delivery" of a
   message, it MUST insert a return-path line at the beginning of the mail
   data. 


For this to be unambiguous, exactly one return path
   MUST be present when the message is delivered. 

Notes:

There are contradictory and ambiguous statements in this section. Return-path is classified in 5322 as optional. It's not 100% clear in the original text whether the server MUST prepend the return-path header or not.

Do we really want to prohibit inspection by relays in this section? I would imagine this MUST level requirement is routinely ignored anyway.

Alternatively, we decide that Return-path is truly optional and change the first sentence to make that clear instead of the strongly implied MUST.

--- VERIFIER NOTES ---
This erratum would normally meet the criteria for "Rejected", but
it points out that as it currently stands, RFC 5321 is in need of
some work, perhaps in the process of advancing it on the Standards
Track to Internet Standard. The erratum raises some issues, which
I'll note here:

1. RFC 5321 uses the capitalized key words from RFC 2119 only sparingly,
and much of the normative language in the document is written in plain
English ("the server does this", rather than "the server MUST do this").
This is by intent, and is certainly not an error in the document, but
some people find it less clear.

2. While RFC 5321 and RFC 5322 go hand in hand for most of us most of
the time, they are quite separable. RFC 5321 can be used to transfer
data that does not conform to the format in RFC 5322, and message stores
can contain messages in RFC 5322 format that were not put there via
SMTP (RFC 5321). As a result, there are sometimes things that seem
contradictory between the two documents, if one is not aware of this
situation.

3. RFC 5321 specifies a protocol that we know is not fully followed
everywhere. That there are known variants does not mean that we should
define the protocol any less rigorously, and the claim that a requirement
of the protocol is "routinely ignored" may well be true, but is not
relevant to how the protocol is defined.

All that said, the points need to be considered when a revision of
RFC 5321 is taken on, and I'm marking this as "Held for Document Update"
so that it will be staring us in the face is and when that happens.

Errata ID: 5711
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Guillaume Fortin-Debigaré
Date Reported: 2019-04-29
Held for Document Update by: Barry Leiba
Date Held: 2019-11-13

Section D.3 says:

      C: Bill:
      C: The next meeting of the board of directors will be
      C: on Tuesday.
      C: John.

It should say:

      C: Bill:
      C: The next meeting of the board of directors will be
      C: on Tuesday.
      C:                         John.

Notes:

Since step 1 and step 2 are transmitting the same message, the relay host should not change its body.

The previous version of this document, RFC 2821, had the "John." signature centered by padding spaces before it on both steps, not just step 2.

RFC 5322, "Internet Message Format", October 2008

Note: This RFC has been updated by RFC 6854

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 1906
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Wolf Lammen
Date Reported: 2009-10-10
Held for Document Update by: Pete Resnick
Date Held: 2010-04-02

Section 4.1 says:

   obs-body        =   *((*LF *CR *((%d0 / text) *LF *CR)) / CRLF)

It should say:

   obs-body        =   *(%d0-127)

Notes:

The regular expression for obs-body is overly complex and can be simplified as suggested. Alternatively, one could use
*(d0 /text / LF / CR)
should the difference to 'text' be emphazised.

[Alexey: I've edited this to only show 1 issue per erratum.]

Errata ID: 2950
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Antonio Regidor García
Date Reported: 2011-08-30
Held for Document Update by: Barry Leiba
Date Held: 2019-11-13

Section 3.6 says:

   fields          =   *(trace
                         *optional-field /
                         *(resent-date /
                          resent-from /
                          resent-sender /
                          resent-to /
                          resent-cc /
                          resent-bcc /
                          resent-msg-id))
                       *(orig-date /
                       from /
                       sender /
                       reply-to /
                       to /
                       cc /
                       bcc /
                       message-id /
                       in-reply-to /
                       references /
                       subject /
                       comments /
                       keywords /
                       optional-field)

It should say:

   fields          =   *(trace
                         *optional-field /
                         1*(resent-date /
                           resent-from /
                           resent-sender /
                           resent-to /
                           resent-cc /
                           resent-bcc /
                           resent-msg-id))
                       *(orig-date /
                       from /
                       sender /
                       reply-to /
                       to /
                       cc /
                       bcc /
                       message-id /
                       in-reply-to /
                       references /
                       subject /
                       comments /
                       keywords /
                       optional-field)

Notes:

The original version causes an infinite loop (matching an infinite list of empty strings).

Errata ID: 3135
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Ashley Willis
Date Reported: 2012-02-25
Held for Document Update by: Barry Leiba
Date Held: 2019-11-13

Section 3.2.4 says:

   quoted-string   =   [CFWS]
                       DQUOTE *([FWS] qcontent) [FWS] DQUOTE
                       [CFWS]

It should say:

   quoted-string   =   [CFWS]
                       DQUOTE ((1*([FWS] qcontent) [FWS]) / FWS) DQUOTE
                       [CFWS]

Notes:

The text following this definition states that a "quoted-string is identical to atom, semantically." "Semantically, neither the optional CFWS outside of the quote characters nor the quote characters themselves are part of the quoted-string; the quoted-string is what is contained between the two quote characters."

The published definition allows, for example, an angle-addr of <""@ietf.org> which is equivalent to <@ietf.org>, hence invalid. The corrected definition ensures that at a minimum there is one FWS or qcontent between each DQUOTE.

Currently allowed yet invalid: <""@ietf.org>, <foo.""@ietf.org>, <"".bar@ietf.org>, and <foo."".bar@ietf.org>.

As a quoted-string must be bound by the ends of the local-part or by a dot, there is no change in regard to the currently invalid addresses such as <foo""@ietf.org>, <""bar@ietf.org>, and <foo""bar@ietf.org>.

Errata ID: 4692
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Oleg Andriyanov
Date Reported: 2016-05-13
Held for Document Update by: Barry Leiba
Date Held: 2019-04-30

Section 3.2.4 says:

   qtext           =   %d33 /             ; Printable US-ASCII
                       %d35-91 /          ;  characters not including
                       %d93-126 /         ;  "\" or the quote character
                       obs-qtext

It should say:

   qtext           =   %d32 /             ; Printable US-ASCII
                       %d33 /             ;  characters not including
                       %d35-91 /          ;  "\" or the quote character
                       %d93-126 /
                       obs-qtext

Notes:

According to the Open Group's definition of the "print" class of characters in a locale [1], the SPACE character (%d32) is printable as well. So either it should be included in the "qtext" definition or the comment should state explicitly that it is excluded from "qtext" along with backslash and double quote.

[1]: pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html

----- Verifier notes -----
There are many places in the document that refer to "printable US-ASCII characters", and it's clear from the context of them that SPACE was not included there. This issue does need to be looked at when we revise this document to advance it to Internet Standard.

Errata ID: 5867
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Pete Resnick
Date Reported: 2019-10-01
Held for Document Update by: Barry Leiba
Date Held: 2019-11-13

Section 4.5.7 says:

   obs-received    =   "Received" *WSP ":" *received-token CRLF

It should say:

   obs-received    =   "Received" *WSP ":"
                       [1*received-token / CFWS] [ ";" date-time CRLF ]
                    

Notes:

Erratum 3979 already describes that CFWS should be allowed in an otherwise empty list of received-tokens. This adds an optional date-time after that.

Errata ID: 5905
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Edward Welbourne
Date Reported: 2019-11-13
Held for Document Update by: Barry Leiba
Date Held: 2019-11-13

Section 3.3 says:

   The time-of-day specifies the number of hours, minutes, and
   optionally seconds since midnight of the date indicated.

   The date and time-of-day SHOULD express local time.

It should say:

   The time-of-day specifies the number of hours, minutes, and
   optionally seconds since midnight of the date indicated or, when
   a time-zone transition has intervened in the interval, since the
   nominal midnight of the zone now in effect.

   The date and time-of-day SHOULD express local time.

Notes:

The problem with the original text is its reading on the day of a time-zone transition.

For example, if the hour from 02:00 to 03:00 was repeated (a fall-back, as at the end of DST), then what local time refers to as 04:00 is 5 hours after midnight "of the date indicated" and what local time refers to as 23:59 is almost 25 hours after midnight. Likewise, if an hour early in the day has been skipped (a spring-forward, as at the start of DST), the time since midnight is one hour short of the local time, as normally understood; for example, 23:00 is only 22 hours after midnight.

There are zones in which transitions happen at midnight, for which 01:00 is midnight on a relevant day: at the other end of the year, there may then be a day that repeats 00:00, so may be argued to have two midnights (with a rather literal "midnight hour" in between).

I cannot think of a good replacement text, sad to say, but I have tried my (painfully verbose) best. I assume everyone has always just used the conventional meaning of local time (as per the SHOULD in the paragraph I haven't changed), without worrying about the inaccurate "since midnight" phrasing.

Errata ID: 2726
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tony Finch
Date Reported: 2011-02-21
Held for Document Update by: Pete Resnick

Section 3.3 says:

   The zone specifies the offset from Coordinated Universal Time (UTC,
   formerly referred to as "Greenwich Mean Time") that the date and
   time-of-day represent.  The "+" or "-" indicates whether the time-of-
   day is ahead of (i.e., east of) or behind (i.e., west of) Universal
   Time.  The first two digits indicate the number of hours difference
   from Universal Time, and the last two digits indicate the number of
   additional minutes difference from Universal Time.  (Hence, +hhmm
   means +(hh * 60 + mm) minutes, and -hhmm means -(hh * 60 + mm)
   minutes).  The form "+0000" SHOULD be used to indicate a time zone at
   Universal Time.  Though "-0000" also indicates Universal Time, it is
   used to indicate that the time was generated on a system that may be
   in a local time zone other than Universal Time and that the date-time
   contains no information about the local time zone.

It should say:

   The zone specifies the offset from Coordinated Universal Time (UTC) 
   that the date and time-of-day represent.
   The "+" or "-" indicates whether the time-of-
   day is ahead of (i.e., east of) or behind (i.e., west of) UTC.
   The first two digits indicate the number of hours difference
   from UTC, and the last two digits indicate the number of
   additional minutes difference from UTC.  (Hence, +hhmm
   means +(hh * 60 + mm) minutes, and -hhmm means -(hh * 60 + mm)
   minutes).  The form "+0000" SHOULD be used to indicate a time zone at
   UTC.  Though "-0000" also indicates UTC, it is
   used to indicate that the time was generated on a system that may be
   in a local time zone other than UTC and that the date-time
   contains no information about the local time zone.

Notes:

It is not correct to say that UTC was formerly referred to as GMT. I think this was an editorial mistake: RFC 822 did not use the term UTC and said "Universal Time (formerly called Greenwich Mean Time)" which is reasonably correct for UT without a suffix.

For the purposes of RFC 5322 and for consistency with RFC 3339 and ISO 8601 I think it is best to refer to UTC throughout - though see the next erratum for notes on the obsolete syntax.

Errata ID: 3048
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Pan GaoYong
Date Reported: 2011-12-08
Held for Document Update by: Pete Resnick
Date Held: 2011-12-29

Section 3.6.6. Rese says:

   When resent fields are used, the "Resent-From:" and "Resent-Date:"
   fields MUST be sent.  The "Resent-Message-ID:" field SHOULD be sent.

It should say:

   When resent fields are used, the "Resent-From:" and "Resent-Date:"
   fields MUST be set.  The "Resent-Message-ID:" field SHOULD be set.

Notes:

[Verifier note: The original report only noted the second use of the word "sent". I have updated to include both. I have marked as "Hold" because (a) I believe the meaning is clear in the current and (b) it is not obvious that "set" is the correct word here; perhaps "used" is better. Left for an editing pass when this moves to Standard.]

RFC 5331, "MPLS Upstream Label Assignment and Context-Specific Label Space", August 2008

Note: This RFC has been updated by RFC 7274

Source of RFC: mpls (rtg)

Errata ID: 1698
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-03-02
Held for Document Update by: Adrian Farrel

Section 4., 1st para says:

   [...]
   Then, with respect to this binding, Ru is the "upstream LSR", and Rd
|  is the "downstream LSR"."
                          ^^

It should say:

   Then, with respect to this binding, Ru is the "upstream LSR", and Rd
|  is the "downstream LSR".
                          ^

Notes:

Typo; keep for update!

Errata ID: 1699
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-03-02
Held for Document Update by: Adrian Farrel

Section 7, pg.8 says:

   The precise set of procedures for identifying the IP address of the
|  root of the tunnel depend, of course, on the protocol used to set up
   the tunnel.  [...]
                           ^^

It should say:

   The precise set of procedures for identifying the IP address of the
|  root of the tunnel depends, of course, on the protocol used to set up
   the tunnel.  [...]
                           ^^^

Notes:

Location is the 2nd paragraph on page 8.

Rationale: singular/plural mismatch: "The ... set ... depend".
Keep for update!

Errata ID: 1701
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-03-02
Held for Document Update by: Adrian Farrel

Section 8., 6th para says:

          [...].  Values of the host part of the IPv4 address greater
|  than 0xFFFEF are not allowed to be used as context labels.
                                           ^^

It should say:

          [...].  Values of the host part of the IPv4 address greater
|  than 0xFFFEF are not allowed to be used to generate context labels.
                                           ^^^^^^^^^^^

Notes:

Rationale: The 'host part' only becomes a part of the label
(The full, 32-bit label format is specified in RFC 3032 with
significant updates by RFC 5462, RFC 3270, and RFC 5129.)
Thus, the host part cannot be used "as" as label; the Corrected
Text suggests an appropriate wording.

Errata ID: 1702
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-03-02
Held for Document Update by: Adrian Farrel

Section 9 says:

   A typical use case of upstream-assigned labels is for MPLS multicast
   and is described here for illustration.  This use case arises when an
   upstream LSR Ru is adjacent to several downstream LSRs <Rd1...Rdn> in
|  an LSP, LSP1 AND Ru is connected to <Rd1...Rdn> via a multi-access
   media or tunnel, AND Ru wants to transmit a single copy of an MPLS
   packet on the LSP to <Rd1...Rdn>.  [...]

It should say:

   A typical use case of upstream-assigned labels is for MPLS multicast
   and is described here for illustration.  This use case arises when an
   upstream LSR Ru is adjacent to several downstream LSRs <Rd1...Rdn> in
|  an LSP, LSP1, AND Ru is connected to <Rd1...Rdn> via a multi-access
               ^
   media or tunnel, AND Ru wants to transmit a single copy of an MPLS
   packet on the LSP to <Rd1...Rdn>.  [...]

Notes:

Rationale:
The missing comma distorts the sense (giving the subject LSP a name,
"LSP1") and visually binds "LSP1" too much to the "AND".
Maybe it would have been preferable to also insert "say" for clarity:
"... and LSP, say LSP1, AND ..."

Errata ID: 3728
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Liu Lin
Date Reported: 2013-09-16
Held for Document Update by: Adrian Farrel
Date Held: 2013-09-17

Section 8 says:

If the IPv4 network mask is greater than 12 bits, 
it is possible to map the remaining 20 bits into 
a unique context label value.  

It should say:

If the IPv4 network mask is equal or greater than 12 bits, 
it is possible to map the remaining bits into 
a unique context label value.

RFC 5337, "Internationalized Delivery Status and Disposition Notifications", September 2008

Note: This RFC has been obsoleted by RFC 6533

Source of RFC: eai (app)

Errata ID: 1514
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-09-15
Held for Document Update by: Alexey Melnikov

Section 4, pg. 8 says:

a)
    MIME type                 [[one instance]], and

b)
    MIME types                [[two instances]]

It should say:

a)
    media type  

b)
    media types   

Notes:

Correct usage of established IETF terminology;
see RFC 4288 (et al.) for rationale.

RFC 5339, "Evaluation of Existing GMPLS Protocols against Multi-Layer and Multi-Region Networks (MLN/MRN)", September 2008

Source of RFC: ccamp (rtg)

Errata ID: 1555
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-10-09
Held for Document Update by: Adrian Farrel

Section 3.1.3, pg.9 says:

   FA-LSP connectivity verification relies on technology-specific
   mechanisms (e.g., for SDH using G.707 and G.783; for MPLS using
|  Bidrectional Forwarding Detection (BFD); etc.) as for any other LSP.
   Hence, this requirement is out of the scope of GMPLS protocols.

It should say:

   FA-LSP connectivity verification relies on technology-specific
   mechanisms (e.g., for SDH using G.707 and G.783; for MPLS using
|  Bidirectional Forwarding Detection (BFD); etc.) as for any other LSP.
   Hence, this requirement is out of the scope of GMPLS protocols.

Notes:

Typo, missing 'i'.

RFC 5340, "OSPF for IPv6", July 2008

Note: This RFC has been updated by RFC 6845, RFC 6860, RFC 7503, RFC 8362, RFC 9454

Source of RFC: ospf (rtg)

Errata ID: 1582
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Faraz Shamim
Date Reported: 2008-11-01
Held for Document Update by: Stewart Bryant

Section 8 says:

Faraz Shamin reviewed a late version of the document and provided editorial comments.

It should say:

Faraz Shamim reviewed a late version of the document and provided editorial comments.

Notes:

Last name is mis-spelled with "n" at the end instead of "m"

Errata ID: 1583
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Faraz Shamim
Date Reported: 2008-11-01
Held for Document Update by: Stewart Bryant

Section 8 says:

Faraz Shamin reviewed a late version of the document and provided
      editorial comments.

It should say:

Faraz Shamim reviewed a late version of the document and provided
      editorial comments.

Notes:

Last name is mis-spelled. Instead of "m" at the end it says "n"

RFC 5346, "Operational Requirements for ENUM-Based Softswitch Use", October 2008

Source of RFC: enum (rai)

Errata ID: 1537
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-10-07
Held for Document Update by: Robert Sparks

Section 4.1.1,pg.5 says:

   The case where a valid URI was present is covered in Section 4.1.2
   (rule 2 A, second point).  The case where an ENUM entry was not
   provisioned for a number that had an active PSTN Point of
|  Interconnect is covered in Section 4.1.2 (rule 2 B).

   For "ENUM only" ranges, where a given number in that range was in
   service (i.e., there was an IP-based Point of Interconnect to a
   carrier), a valid SIP or H.323 URI was always provisioned into the
|  associated ENUM domain.  This is covered in Section 4.1.2 (rule 2 A,
   second point).

   In such an "ENUM only" range, if the number was not in service, a TXT
   record was provisioned but no valid NAPTRs would be present.  This
   ensured that a query for NAPTRs in a given (out of service, "ENUM
   only" range) domain would succeed (i.e., return a RCODE of 0), but
   that the number of answers would also be zero.  This is covered in
|  Section 4.1.2 (rule 2 A, first point).  Note that this point also
   covers the case where only NAPTRs that cannot be used to initiate a
   call exist in such a zone.

It should say:

   The case where a valid URI was present is covered in Section 4.1.2
|  (rule 3 A, second point).  The case where an ENUM entry was not
   provisioned for a number that had an active PSTN Point of
|  Interconnect is covered in Section 4.1.2 (rule 3 B).

   For "ENUM only" ranges, where a given number in that range was in
   service (i.e., there was an IP-based Point of Interconnect to a
   carrier), a valid SIP or H.323 URI was always provisioned into the
|  associated ENUM domain.  This is covered in Section 4.1.2 (rule 3 A,
   second point).

   In such an "ENUM only" range, if the number was not in service, a TXT
   record was provisioned but no valid NAPTRs would be present.  This
   ensured that a query for NAPTRs in a given (out of service, "ENUM
   only" range) domain would succeed (i.e., return a RCODE of 0), but
   that the number of answers would also be zero.  This is covered in
|  Section 4.1.2 (rule 3 A, first point).  Note that this point also
   covers the case where only NAPTRs that cannot be used to initiate a
   call exist in such a zone.

Notes:

All (4) instances of "rule 2" should say "rule 3".

Errata ID: 1538
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-10-07
Held for Document Update by: Robert Sparks

Section 4.1.2,pg.7 says:

           [...]
|          Configuring it in a non-complaint manner was considered
           unacceptable, due to the need to analyze the impact of that
           choice on other DNS operations thoroughly before it could be
           implemented safely.

It should say:

           [...]    
|          Configuring it in a non-compliant manner was considered
           unacceptable, due to the need to analyze the impact of that
           choice on other DNS operations thoroughly before it could be
           implemented safely.

Notes:

Distorting typo in the last paragraph of 4.1.2. !

RFC 5347, "Media Gateway Control Protocol Fax Package", October 2008

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rai

Errata ID: 1600
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-11-17
Held for Document Update by: Robert Sparks

Section 2.1.1,pg.6/7 says:

a)  last paragraph on page 6:

   The Call Agent instructs the gateway to perform the media change by
   sending it a ModifyConnection command with "image/t38" listed as the
   encoding method in the LocalConnectionOptions (receipt of a
   ModifyConnection command without LocalConnectionOptions but with a
|  RemoteConnectionDescriptor containing an "m=" line with the MIME type
   "image/t38" would achieve the same).  [...]

b)  second paragraph on page 7:

                     [...].  The T.38 fax procedure continues when an
   acceptable RemoteConnectionDescriptor is received.  An acceptable
   RemoteConnectionDescriptor contains an "m=" line with the "image/t38"
|  MIME type (using the normal SDP syntax) and a supported transport
   protcol (UDPTL or TCP).  [...]

It should say:

a)
   The Call Agent instructs the gateway to perform the media change by
   sending it a ModifyConnection command with "image/t38" listed as the
   encoding method in the LocalConnectionOptions (receipt of a
   ModifyConnection command without LocalConnectionOptions but with a
|  RemoteConnectionDescriptor containing an "m=" line with the media
   type "image/t38" would achieve the same).  [...]

b)

                     [...].  The T.38 fax procedure continues when an
   acceptable RemoteConnectionDescriptor is received.  An acceptable
   RemoteConnectionDescriptor contains an "m=" line with the "image/t38"
|  media type (using the normal SDP syntax) and a supported transport
   protcol (UDPTL or TCP).  [...]

Notes:

Rationale:

BCP 13, RFC 4288, has re-enforced the terminology from
RFC 2045 ff. The 'IM' in "MIME" stands for 'Internet Mail'.
As pointed out in RFC 4288, it makes no sense to remain stuck
with the colloquial abuse of language, talking about "MIME types",
in particular when Media Types are used outside the scope of
Internet Mail; the MGCP context is one specific example of
such a scenario. Hence, the RFC should use the terminology
established in the IETF, as explained in RFC 4288.

Errata ID: 1601
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-11-17
Held for Document Update by: Robert Sparks

Section 2.1.4, pg.9 says:

<< near the top of page 9 >>:

|     * the relevant MIME media type, e.g., "image/t38", is included in
        the "m=" line in the RemoteConnectionDescriptor, or

|     * the relevant MIME media type is included as a capability (see
        [RFC3407]) in the RemoteConnectionDescriptor.

It should say:

|     * the relevant media type, e.g., "image/t38", is included in the
        "m=" line in the RemoteConnectionDescriptor, or

|     * the relevant media type is included as a capability (see
        [RFC3407]) in the RemoteConnectionDescriptor.

Notes:

Rationale: See Errata for Section 2.1.1, Eid=1600.

Errata ID: 1603
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-11-17
Held for Document Update by: Robert Sparks

Section 3.2, pg.33 says:

<< in step 14 >>:

   The Call Agent then instructs the terminating gateway to use the
|  "image/t38" MIME type instead:
|

It should say:

   The Call Agent then instructs the terminating gateway to use the
|  "image/t38" media type instead:

Notes:

Rationale:
See Errata Note for same issue for Section 2.1.1, Eid=1600.

Errata ID: 1605
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-11-17
Held for Document Update by: Robert Sparks

Section 3.3, pg.43 says:

a)   << Steps 15, 16 >>

|  The originating endpoint detects V.21 fax preamble.  Even though the
   endpoint is already using "image/t38" for media, it generates a
   "t38(start)" event and notifies the Call Agent.

b)   << Step 23 >>

   The originating endpoint also generates a "t38(stop)" event, which is
   notified to the Call Agent:

|     NTFY 3502 ds/ds1-1/1@gw-o.example.net MGCP 1.0 O: t38(stop) X: 2

It should say:

a)

|  The originating endpoint detects the V.21 fax preamble.  Even though
   the endpoint is already using "image/t38" for media, it generates a
   "t38(start)" event and notifies the Call Agent.

b)

   The originating endpoint also generates a "t38(stop)" event, which is
   notified to the Call Agent:

|     NTFY 3502 ds/ds1-1/1@gw-o.example.net MGCP 1.0
|     O: t38(stop)
|     X: 2

Notes:

Rationale:

a) Missing definite article.

b) Confusing formating, inconsistent with all other message examples.

Errata ID: 1602
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-11-17
Held for Document Update by: Robert Sparks

Section 3.2, pg.29 says:

<< last line of first paragraph >>:

   Furthermore, the originating fax machine is generating CNG tone.

It should say:

   Furthermore, the originating fax machine is generating a CNG tone.
                                                         ^^^

Notes:

Rationale: Missing indefinite article.

Errata ID: 1604
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-11-17
Held for Document Update by: Robert Sparks
Date Held: 2010-12-17

Section 3.3, pg.37 says:

<<  last line of first paragraph >>:

   Once again, the originating fax does not generate CNG tone.

It should say:

   Once again, the originating fax does not generate a CNG tone.
                                                    ^^^

Notes:

Rationale: Missing indefiniet article; it should be used
consistently.

--- From the RAI reviewer
Recommended status: (incorrect) Rejected

Thinking about this some more (and in contradiction to my report on
erratum 1602 on this RFC), the intention of the text is to use "CNG
tone" as a mass noun, and so it does not take an indefinite article.

I believe that use of such phrases as "CNG tone" as a mass noun is
more common in British English than American English. This RFC
appears to follow the British convention, with the sole exception of
the first line of "Steps 9-12" on page 33 of section 3.2, which I now
consider to be an error.
======================================================================

RFC 5348, "TCP Friendly Rate Control (TFRC): Protocol Specification", September 2008

Source of RFC: dccp (tsv)

Errata ID: 1612
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-11-24
Held for Document Update by: Magnus Westerlund

Section 4, pg.9 says:

<< 5th bullet >>

   o   Oscillation prevention (optional).

It should say:

   o   Oscillation reduction (optional).
                   ^^^^^^^^^

Notes:

Rationale:
Consistency in change of emphasis (since RFC 3448),
cf. new title of Section 4.5 !

Errata ID: 1613
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-11-24
Held for Document Update by: Lars Eggert

Section 4.4, pg.15 says:

<< 1st paragraph in Section 4.4 >>

|  This section specifies the sender's response to a nofeedback timer.
   The nofeedback timer could expire because of an idle period or
   because of data or feedback packets dropped in the network.

It should say:

                                                                vvvvvvv
|  This section specifies the sender's response to a nofeedback timeout.
   The nofeedback timer could expire because of an idle period or
   because of data or feedback packets dropped in the network.

Errata ID: 1616
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-11-24
Held for Document Update by: Lars Eggert

Section 7, pg.30 says:

<<  second paragraph of section, at the bottom of pg. 30 >>

   The main advantage of a sender-based variant of TFRC is that the
   sender does not have to trust the receiver's calculation of the
   packet loss rate.  However, with the requirement of reliable delivery
   of loss information from the receiver to the sender, a sender-based
|  TFRC would have much tighter constraints on the transport protocol in
   which it is embedded.

It should say:

   The main advantage of a sender-based variant of TFRC is that the
   sender does not have to trust the receiver's calculation of the
   packet loss rate.  However, with the requirement of reliable delivery
   of loss information from the receiver to the sender, a sender-based
|  TFRC has much tighter constraints on the transport protocol in which
   it is embedded.

Notes:

Rationale:
Consistency in style broken by incomplete change since
RFC 3448; present tense is now used in the first sentence;
so it should be used in the second one as well, for clarity.

Errata ID: 1617
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-11-24
Held for Document Update by: Lars Eggert

Section C.1, pg.48 says:

<<  second paragraph on page 48 >>

   Recovery after idle or data-limited periods: When TCP reduces the
|  congestion window after an idle or data-utilized period, TCP can set
   the slow-start threshold, ssthresh, to allow the TCP sender to slow-
   start back up towards its old sending rate when the idle or data-
   limited period is over.  [...]

It should say:

   Recovery after idle or data-limited periods: When TCP reduces the
|  congestion window after an idle or data-limited period, TCP can set
   the slow-start threshold, ssthresh, to allow the TCP sender to slow-
   start back up towards its old sending rate when the idle or data-
   limited period is over.  [...]

Notes:

Rationale:
The term "data-utilized period" does not appear anywhere else in
the RFC; apparently, "data-limited period" is meant here as well.

RFC 5357, "A Two-Way Active Measurement Protocol (TWAMP)", October 2008

Note: This RFC has been updated by RFC 5618, RFC 5938, RFC 6038, RFC 7717, RFC 7750, RFC 8545

Source of RFC: ippm (ops)

Errata ID: 1591
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-11-05
Held for Document Update by: Lars Eggert

Section 6, pg.20 says:

<<  second paragraph of the section  >>

                                                             [...].  The
   Count field provides an opportunity for a denial-of-service (DOS)
   attack because it is 32 bits long.  If an attacking system set the
|  maximum value in Count (2**32), [...]

It should say:

                                                             [...].  The
   Count field provides an opportunity for a denial-of-service (DOS)
   attack because it is 32 bits long.  If an attacking system set the
|  maximum value in Count (2**32-1), [...]

Notes:

In the second paragraph of Section 6, near the bottom of page 20,
the maximum value given is too large. In the OWAMP specification,
I could not find any indication of a bias added to the Count value,
and thus the (hypothetical) range for Count is 0 .. 2**32-1 .

Thus, the RFC text needs to be corrected.

Errata ID: 1594
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-11-05
Held for Document Update by: Lars Eggert

Section 3.8,1st para says:

                                vvvvvvvvvvvvvvvvv
                                                        [...].  The
|  message is terminated with a single block HMAC to complete the Stop-
   Sessions command.  [...]

It should say:

<<  either:  >>

                                                        [...].  The
|  message is terminated with a single-block HMAC to complete the Stop-
   Sessions command.  [...]

<<  or:  >>

                                       vvvvvvvvvv
                                                        [...].  The
|  message is terminated with a single HMAC block to complete the Stop-
   Sessions command.  [...]

Notes:

In any way this is problematic because the term "block" has not been
introduced into the RFC text. (That's also a problem for 4.2.1!)

Even in the restricted context of SHA (FIPS PUB 180-2/3) and HMAC
(FIPS PUB 197), the term "block" does not uniquely identify a
specific number of octets.
For SHA-1, SHA-224, and SHA-256, the block size is 512 bits,
for SHA-384 and SHA-512 it is 1024 bits.

But OWAMP uses a truncated version of HMAC-SHA-1 with a 128-bit MAC,
(officially denoted as HMAC-SHA-1-128), and apparently that is carried
over to TWAMP without mention in the RFCs.

It remains unclear from the text what precisely was intended to say.


Hint: Errata Note entered on request of the responsible AD before
resolution with the authors.

Errata ID: 4429
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Steve Baillargeon
Date Reported: 2015-07-27
Held for Document Update by: Spencer Dawkins
Date Held: 2016-07-04

Section Appendix 1 says:

Section Appendix says: 
              controller                              responder
          +-----------------+                   +-------------------+
          |     Server      |<----------------->|                   |
          | Control-Client  |                   | Session-Reflector |
          | Session-Sender  |<--TWAMP-Test----->|                   |
          +-----------------+                   +-------------------+

It should say:

             controller                              responder
          +-----------------+                   +-------------------+
          |     Server      |                   |                   |
          | Control-Client  |                   | Session-Reflector |
          | Session-Sender  |<--TWAMP-Test----->|                   |
          +-----------------+                   +-------------------+

Notes:

The top arrow is not identified and misleading. It should be removed.

2015-07-29: RFC Editor changed the Type to Technical.

2016-07-04 Spencer chatted about this with Al Morton.

Al said -

> As I'm likely the last reachable author of TWAMP:
>
> In http://tools.ietf.org/html/rfc5357#section-1.2
> the Logical Model of TWAMP, the communications link
> between the Server and the Session-Reflector is indicated,
> but also undescribed. This communication is necessary for
> controlling state in the Session-Reflector, to start and
> stop sessions (which resets sequence renumbering in the
> Session-Reflector), for example.
>
> Also, section 1.2 says:
> "Unlabeled links in the figure are unspecified by
> this document and may be proprietary protocols."
>
> Like the Figure at the bottom of Page 4 in sec 1.2,
> the TWAMP-Light Figure is a re-formulation of the roles
> in the Logical Model, moving the Server alongside the
> Control-Client. The need for Server <-> Session-Reflector
> communications still exists for the case of TWAMP-Light
> operating *with* session state.

In previous discussions, Brian Trammell had suggested that unlabeled arrows should be marked "protocol unspecified" or "see section 1.2" here to clear up the confusion.

Spencer will leave this for the working group to consider if the document is updated.

Errata ID: 1586
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-11-05
Held for Document Update by: Lars Eggert

Section 2, pg.5 says:

<< first bullet >>

                                                    vv
|  -  The Control-Client initiates a TCP connection on TWAMP's well-
      known port, and the Server (its role now established) responds
      with its Greeting message, indicating the security/integrity
      mode(s) it is willing to support.

It should say:

                                                    vv
|  -  The Control-Client initiates a TCP connection to TWAMP's well-
      known port, and the Server (its role now established) responds
      with its Greeting message, indicating the security/integrity
      mode(s) it is willing to support.

Notes:

The "on" is misleading or ambiguous; such verbiage commonly is used
to denote the *source* port used to send a packet, but from the
context (and in particular the first paragraph of Section 3.1)
it seems likely that you mean the *destination* port number here.

The corrected text aims to disambiguate/clarify/correct this.

Errata ID: 1588
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-11-05
Held for Document Update by: Lars Eggert

Section 4 says:

|                                 [...].  As with OWAMP-test protocol
   [RFC4656], there are three modes: unauthenticated, authenticated, and
   encrypted.

It should say:

|                                 [...].  As with the OWAMP-test
   protocol [RFC4656], there are three modes: unauthenticated,
   authenticated, and encrypted.

Notes:

Missing article.

Errata ID: 1592
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-11-05
Held for Document Update by: Lars Eggert

Section 8, pg. 21 says:

<<  near the bottom of page 21 >>

   #               863-872    Unassigned

Notes:

The indicated line should be deleted; it is confusing, as it
contains information on the state of the IANA registry at the
time of publication of the RFC, which is totally uncorrelated
to the matter of the RFC.

RFC 5384, "The Protocol Independent Multicast (PIM) Join Attribute Format", November 2008

Note: This RFC has been updated by RFC 7887

Source of RFC: pim (rtg)

Errata ID: 1598
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-11-17
Held for Document Update by: Adrian Farrel
Date Held: 2013-01-16

Section 3.4.2 says:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |      OptionType = 26           |      OptionLength = 0        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |      OptionType = 26          |       OptionLength = 0        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

The notes when raised read:

> Misplaced field separator (vertical bar).
>
> Erratum is considered 'Technical' because the text of the RFC
> does not contain text that could guide the reader in
> disambiguating the figure.

Moving this to editorial with the note that PIM Option formats are well known.

Errata ID: 1599
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-11-17
Held for Document Update by: Adrian Farrel

Section 3.2,1st para says:

   To ensure that a type 1 Encoded-Source Address is not sent to a PIM
   neighbor that does not understand this encoding, a new PIM Hello
   option, the "Join Attribute" option, is defined.  This option MUST be
   included in the PIM Hellos of any PIM router that is willing to
|  receive type 1 Encoded-Source Address.  A PIM router MUST NOT send a
                                        ^
   type 1 Encoded-Source Address out any interface on which there is a
   PIM neighbor that has not included this option in its Hellos.  (Even
|  a router that is not the upstream neighbor must be able parse the
                                                          ^
   packet in order to do Join suppression or overriding.)

It should say:

   To ensure that a type 1 Encoded-Source Address is not sent to a PIM
   neighbor that does not understand this encoding, a new PIM Hello
   option, the "Join Attribute" option, is defined.  This option MUST be
   included in the PIM Hellos of any PIM router that is willing to
|  receive type 1 Encoded-Source Addresses.  A PIM router MUST NOT send
                                        ^^^
   a type 1 Encoded-Source Address out any interface on which there is a
   PIM neighbor that has not included this option in its Hellos.  (Even
|  a router that is not the upstream neighbor must be able to parse the
                                                          ^^^^
   packet in order to do Join suppression or overriding.)

Notes:

Rationale: Grammar flawed.

RFC 5385, "Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs", February 2010

Source of RFC: INDEPENDENT

Errata ID: 5778
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lloyd Wood
Date Reported: 2019-07-11
Held for Document Update by: Adrian Farrel
Date Held: 2019-07-13

Section Abstract says:

http://www.isi.edu/touch/tools/

It should say:

https://www.strayalpha.com/tools/

Notes:

Although we cannot use Errata Reports to update referenced URLs, I am leaving this report as "Held for Document Update" so that the information remains available for any future revision and also so that it is linked to the RFC and can be found by resourceful readers.

=====

This RFC describes Word templates which were at Joe Touch's ISI webpages. Those webpages are no more. There is a redirect to Joe's personal website at www.strayalpha.com as a hint and the current correct reference for the tools being maintained is presumably
https://www.strayalpha.com/tools/ but who knows how long that redirect will exist and how long those personal webpages will be there? An expired credit card could kill the domain and the resource.

https://web.archive.org/web/20171121144145/https://www.isi.edu/touch/tools/
has a copy of the original page referenced.

A copy of the template and tools probably needs to be hosted on an IETF-controlled server, with this erratum pointing at that IETF copy as canonical.

(Also, don' t add periods after urls to preserve grammar -just confuses everyone.)

RFC 5386, "Better-Than-Nothing Security: An Unauthenticated Mode of IPsec", November 2008

Source of RFC: btns (sec)

Errata ID: 1609
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-11-18
Held for Document Update by: Sean Turner

Section 3.1, pg.6 says:

<< immediately below Figure 2 >>

|  Note that [SG-A]'s PAD entry has one and only one wildcard PAD entry:
   the BTNS catch-all PAD entry as the last entry, as described in
   Section 2.

It should say:

|  Note that [SG-A]'s PAD has one and only one wildcard PAD entry:
   the BTNS catch-all PAD entry as the last entry, as described in
   Section 2.

Notes:

Rationale:

Designating the PAD (Peer Authentication Database) an an "entry"
is misleading, and particularly confusing when in the same line
a table row in that database is also designated as an "entry".

RFC 5387, "Problem and Applicability Statement for Better-Than-Nothing Security (BTNS)", November 2008

Source of RFC: btns (sec)

Errata ID: 1618
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-11-24
Held for Document Update by: Tim Polk

Section 4, pg.15 says:

   BTNS is intended for services open to the public but for which
   protected associations are desired, and for services that can be
   authenticated at higher layers in the protocol stack.  BTNS can also
   provide some level of protection for private services when the
|  alternative BTNS is no protection at all.

It should say:

   BTNS is intended for services open to the public but for which
   protected associations are desired, and for services that can be
   authenticated at higher layers in the protocol stack.  BTNS can also
   provide some level of protection for private services when the
|  alternative to BTNS is no protection at all.
              ^^^^

Notes:

Rationale: Distorting word omission.

RFC 5389, "Session Traversal Utilities for NAT (STUN)", October 2008

Note: This RFC has been obsoleted by RFC 8489

Note: This RFC has been updated by RFC 7350, RFC 8553

Source of RFC: behave (tsv)

Errata ID: 2010
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Pasi Eronen
Date Reported: 2010-01-21
Held for Document Update by: Lars Eggert

Section 7.2.2 says:

For purposes of usage with this specification, the client treats the
domain name or IP address used in Section 8.1 as the host portion of
the URI that has been dereferenced.

Notes:

The reference should be to Section 9, not 8.1.

Unfortunately, even with this purely editorial fix, the text is
ambiguous: the procedure described in Section 9 would typically use at
least three different domain names: (1) the configured domain name,
like "example.com"; (2) the domain name used in the SRV query, like
"_stuns._tcp.example.com"; and (3) the domain name found in the SRV
record and used for A/AAAA query, like "stunserver3.foobar.example".
And they have *very* different security implications...

Errata ID: 2972
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jack Bates
Date Reported: 2011-09-16
Held for Document Update by: Wes Eddy

Section 15.9 says:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Attribute 1 Type           |     Attribute 2 Type        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Attribute 3 Type           |     Attribute 4 Type    ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Attribute 1 Type        |       Attribute 2 Type        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Attribute 3 Type        |       Attribute 4 Type    ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

Attribute 1 Type and Attribute 3 Type are 17-bits in original figure, Attribute 2 Type and Attribute 4 Type are 15-bits

This is a very cosmetic nit, since the meaning is perfectly clear (a list of 16-bit values)

In general however I find the decimal indices make all figures like this harder to read. I find hex indices an improvement:

<pre>
0 1 2 3 4 5 6 7 8 9 A B C D E F 0 1 2 3 4 5 6 7 8 9 A B C D E F
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute 1 Type | Attribute 2 Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute 3 Type | Attribute 4 Type ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>

Errata ID: 3737
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Spencer Dawkins
Date Reported: 2013-09-25
Held for Document Update by: Martin Stiemerling
Date Held: 2015-04-17

Section 17 says:

The IAB has mandated that protocols developed for this purpose
document a specific set of considerations. 

It should say:

The IAB has suggested that protocols developed for this purpose
document a specific set of considerations. 

Notes:

The IAB UNSAF RFC (http://tools.ietf.org/html/rfc3424) is Informational, and the IAB hasn't "mandated" what IETF protocol documents contain for something like 20 years, if I understand correctly.

Errata ID: 4233
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Anatoliy Sivov
Date Reported: 2015-01-15
Held for Document Update by: Martin Stiemerling
Date Held: 2015-12-16

Section 18.2 says:

Comprehension-required range (0x0000-0x7FFF):
     0x0000: (Reserved)
     0x0001: MAPPED-ADDRESS
     0x0002: (Reserved; was RESPONSE-ADDRESS)
     0x0003: (Reserved; was CHANGE-ADDRESS)
     0x0004: (Reserved; was SOURCE-ADDRESS)
     0x0005: (Reserved; was CHANGED-ADDRESS)

It should say:

Comprehension-required range (0x0000-0x7FFF):
     0x0000: (Reserved)
     0x0001: MAPPED-ADDRESS
     0x0002: (Reserved; was RESPONSE-ADDRESS)
     0x0003: (Reserved; was CHANGE-REQUEST)
     0x0004: (Reserved; was SOURCE-ADDRESS)
     0x0005: (Reserved; was CHANGED-ADDRESS)

Notes:

Text says that attribute 0x0003 was known as CHANGE-ADDRESS, but it was named CHANGE-REQUEST in RFC 3489. It is the only place in RFC 5389, where CHANGE-ADDRESS is used instead of CHANGE-REQUEST, as I can see.

RFC 5404, "RTP Payload Format for G.719", January 2009

Source of RFC: avt (rai)

Errata ID: 1668
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-01-26
Held for Document Update by: Cullen Jennings

Section 5.6.2, pg.13 says:

                                                      [...].  Although
|  the G.719 is robust and thus tolerant to a high random frame erasure
   rate, it would have difficulties handling consecutive frame losses at
   startup.  Thus, some special implementation considerations are
   described.

It should say:

                                                      [...].  Although
|  the G.719 decoder is robust and thus tolerant to a high random frame
   erasure rate, it would have difficulties handling consecutive frame
   losses at startup.  Thus, some special implementation considerations
   are described.

Notes:

Rationale: Word omission; "decoder" inserted after "the G.719".

Errata ID: 1669
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-01-26
Held for Document Update by: Cullen Jennings
Date Held: 2009-01-28

Section 7.1, pg.18 says:

   CBR:  Constant Bitrate (CBR) indicates the exact codec bitrate in
      bits per second (not including the overhead from packetization,
      RTP header, or lower layers) that the codec MUST use.  "CBR" is to
      be used when the dynamic rate cannot be supported (one case is,
      e.g., gateway to H.320).  "CBR" is mostly used for gateways to
|     circuit switch networks.  Therefore, the "CBR" is the rate not
      including any FEC as specified in Section 4.3.1.  If FEC is to be
|     used, the "b=" parameter MUST be used to allow the extra bitrate
      needed to send the redundant information.  [...]

It should say:

   CBR:  Constant Bitrate (CBR) indicates the exact codec bitrate in
      bits per second (not including the overhead from packetization,
      RTP header, or lower layers) that the codec MUST use.  "CBR" is to
      be used when the dynamic rate cannot be supported (one case is,
      e.g., gateway to H.320).  "CBR" is mostly used for gateways to
|     circuit switched networks.  Therefore, the "CBR" is the rate not
      including any FEC as specified in Section 4.3.1.  If FEC is to be
|     used, the "b=" SDP parameter MUST be used to allow the extra
      bitrate needed to send the redundant information.  [...]

Notes:

Rationale:

a) Typo; s/circuit switch/circuit switched/

b) In the context of the discussion of media type parameters,
also using the unqualified term "parameter" for an SDP parameter
is rather confusing; for clarity, "SDP" needs to be inserted.

Additional note from authors of RFC ...

This text should probably not talk about SDP
parameters at all, but rather the need for external functionality that
indicates the actual bitrate of the RTP session as due to the
FEC/Redundancy the CBR value is not a good indicator of the total bitrate.

Errata ID: 1670
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-01-26
Held for Document Update by: Cullen Jennings

Section 7.2.1, pg.21 says:

<< on top of page 21 >>

                                            [...].  The answerer is
         recommended to include in its answer an "int-delay" parameter
         to declare what the property is for the stream it is going to
|        send.  The answer is expected to be capable of selecting a
         valid parameter value that is between zero and the declared
         maximum number of slots in the de-interleaving buffer.

It should say:

                                            [...].  The answerer is
         recommended to include in its answer an "int-delay" parameter
         to declare what the property is for the stream it is going to
|        send.  The answerer is expected to be capable of selecting a
         valid parameter value that is between zero and the declared
         maximum number of slots in the de-interleaving buffer.

Notes:

Rationale: Confusing typo; s/answer/answerer/

Errata ID: 1754
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Magnus Westerlund
Date Reported: 2009-04-03
Held for Document Update by: Cullen Jennings

Section 12.1 says:

   [ITU-T-G719]  ITU-T, "Specification : ITU-T G.719 extension for 20
                 kHz fullband audio", April 2008.

It should say:

[ITU-T-G719]  ITU-T, "Specification: ITU-T G.719 Low-complexity, full-band audio coding for high-quality, conversational applications", June 2008.

Notes:

Steven Botzko informed me that the Reference title is not correct, nor is the publication date for the G.719 reference. However, there should be little issues with finding the correct reference based on Recommendation number.

RFC 5412, "Lightweight Access Point Protocol", February 2010

Source of RFC: INDEPENDENT

Errata ID: 4536
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Tony Deng
Date Reported: 2015-11-18
Held for Document Update by: Nevil Brownlee
Date Held: 2017-07-20

Section 7.2.3 says:

The AC Name with Index message element is sent by the AC to the WTP
   to configure preferred ACs.  The number of instances where this
   message element would be present is equal to the number of ACs
   configured on the WTP.

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Index     |   AC Name...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   90 for AC Name with Index

   Length:   5

   Index:   The index of the preferred server (e.g., 1=primary,
      2=secondary).

   AC Name:   A variable-length ASCII string containing the AC's name.

Notes:

This entire section is in the wrong location or needs to be revised. Section 7.2 is the definition for Configure Request, which is suppose to be a message sent from the WTP to the AC. But here at 7.2.3, this message element clearly states it is an element to be sent from the AC to the WTP. Does this section belong in the Configure Response section instead?

[This section does seem to be in the wrong place. However, moving it will need to wait fo a new (revised) RFC. ISE, July 2017]

RFC 5420, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", February 2009

Note: This RFC has been updated by RFC 6510

Source of RFC: ccamp (rtg)

Errata ID: 1689
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-02-20
Held for Document Update by: Adrian Farrel

Section 11.3, pg.19 says:

a)
   The IANA has created a new registry and will manage the space of
|  attributes bit flags, numbering them in the usual IETF notation:
            ^
   starting at zero and continuing at least through 31.

b)
   Each bit should be tracked with the following qualities:

   - Bit number
   - Defining RFC
   - Name of bit
|  - Whether there is meaning in the Attribute Flags TLV on a Path
|  - Whether there is meaning in the Attribute Flags TLV on a Resv
   - Whether there is meaning in the RRO Attributes subobject

It should say:

a)
   The IANA has created a new registry and will manage the space of
   attribute bit flags, numbering them in the usual IETF notation:
   starting at zero and continuing at least through 31.

b)
   Each bit should be tracked with the following qualities:

   - Bit number
   - Defining RFC
   - Name of bit
|  - Whether there is meaning in the Attribute Flags TLV on a Path message
|  - Whether there is meaning in the Attribute Flags TLV on a Resv message
   - Whether there is meaning in the RRO Attributes subobject

Notes:

Rationale:

a) grammar fix in the body of RFC 5420 vs. RFC 4420
should also be reflected in the IANA Considerations
(and in the IANA registry -- subject to independent report to IANA);

b) language improvement applied in the body of the RFC
should also be reflected in the IANA Considerations.

RFC 5424, "The Syslog Protocol", March 2009

Source of RFC: syslog (sec)

Errata ID: 2682
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: VicTor Smirnoff
Date Reported: 2011-01-07
Held for Document Update by: Sean Turner

Section 6.2.1. says:

 15             clock daemon (note 2)
(...)
 Table 1.  Syslog Message Facilities

It should say:

 15             clock daemon
(...)
 Table 1.  Syslog Message Facilities

Notes:

Note 2 isn't present in this document. It's an artefact from RFC 3164.

RFC 5425, "Transport Layer Security (TLS) Transport Mapping for Syslog", March 2009

Source of RFC: syslog (sec)

Errata ID: 1733
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-03-19
Held for Document Update by: Pasi Eronen

Section 4.2.1, pg.6 says:

   o  End-entity certificate matching: The transport sender or receiver
      is configured with information necessary to identify the valid
      end-entity certificates of its authorized peers.  The end-entity
      certificates can be self-signed, and no certification path
      validation is needed.  Implementations MUST support certificate
|     fingerprints in Section 4.2.2 and MAY allow other formats for
      end-entity certificates such as a DER-encoded certificate.  This
      method provides an alternative to a PKI that is simple to deploy
      and still maintains a reasonable level of security.

It should say:

   o  End-entity certificate matching: The transport sender or receiver
      is configured with information necessary to identify the valid
      end-entity certificates of its authorized peers.  The end-entity
      certificates can be self-signed, and no certification path
      validation is needed.  Implementations MUST support certificate
|     fingerprints as specified in Section 4.2.2 and MAY allow other
                   ^^^^^^^^^^^^^ 
      formats for end-entity certificates such as a DER-encoded
      certificate.  This method provides an alternative to a PKI that is
      simple to deploy and still maintains a reasonable level of
      security.

Notes:

Clarification; keep for update!

Errata ID: 1734
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-03-19
Held for Document Update by: Pasi Eronen

Section 5.1, pg.8 says:

   In the simplest case, the transport sender and receiver are
|  configured with information necessary to identity the valid
   end-entity certificates of its authorized peers.

It should say:

   In the simplest case, the transport sender and receiver are
|  configured with information necessary to identify the valid
   end-entity certificates of its authorized peers.

Notes:

Typo: s/identity/identify/
^ ^
(keep for update!)

RFC 5429, "Sieve Email Filtering: Reject and Extended Reject Extensions", March 2009

Source of RFC: sieve (app)

Errata ID: 5159
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stan Kalisch
Date Reported: 2017-10-17
Held for Document Update by: Alexey Melnikov
Date Held: 2017-10-18

Section 2.1.1, 2.2 says:

non-US-ACSII

It should say:

non-US-ASCII

Notes:

Typo in "ASCII". The original text occurs five times in Section 2.1.1, once in Section 2.2.

RFC 5438, "Instant Message Disposition Notification (IMDN)", February 2009

Source of RFC: simple (rai)

Errata ID: 3013
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Dan Price
Date Reported: 2011-11-04
Held for Document Update by: Robert Sparks

Section 7.2.1.1 says:

   From: Bob <im:bob@example.com>
   To: Alice <im:alice@example.com>
   NS: imdn <urn:ietf:params:imdn>
   imdn.Message-ID: d834jied93rf
   Content-type: message/imdn+xml
   Content-Disposition: notification
   Content-length: ...

It should say:

   From: Bob <im:bob@example.com>
   To: Alice <im:alice@example.com>
   NS: imdn <urn:ietf:params:imdn>
   imdn.Message-ID: d834jied93rf

   Content-type: message/imdn+xml
   Content-Disposition: notification
   Content-length: ...

Notes:

None of the examples in this RFC comply with the format of CPIM defined in RFC 3862, in which the message metadata headers are separated from the headers of the encapsulated MIME object by a blank line.

RFC 5440, "Path Computation Element (PCE) Communication Protocol (PCEP)", March 2009

Note: This RFC has been updated by RFC 7896, RFC 8253, RFC 8356, RFC 9488

Source of RFC: pce (rtg)

Errata ID: 4427
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Phaneendra Manda
Date Reported: 2015-07-23
Held for Document Update by: Deborah Brungard
Date Held: 2015-11-18

Section 6.9 says:

A PCEP implementation that receives an unrecognized PCEP message MUST
   send a PCErr message with Error-value=2 (capability not supported).

It should say:

A PCEP implementation that receives an unrecognized PCEP message MUST
   send a PCErr message with Error-Type=2 (capability not supported).

Notes:

Error-value=2 is not defined, it should be Error-Type=2

Errata ID: 5382
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: VENUGOPAL REDDY KONDREDDY
Date Reported: 2018-06-06
Held for Document Update by: Deborah Brungard
Date Held: 2018-06-07

Section 6.8 says:

The Close message MUST contain exactly one CLOSE object (see
   Section 6.8). 

It should say:

The Close message MUST contain exactly one CLOSE object (see
   Section 7.17). 

Notes:

Section pointed in the text is incorrect.

RFC 5447, "Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction", February 2009

Source of RFC: dime (ops)

Errata ID: 1695
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-02-23
Held for Document Update by: Dan Romascanu

Section 7.1, pg.13 says:

|  The following new AVPs are to be allocated from RADIUS Attribute Type
   space [RFC2865] so that they are RADIUS backward-compatible (AVP Code
   values between 0-255):

It should say:

                          vvvvvvvvv                vvvv
|  The following new AVPs have been allocated from the RADIUS Attribute
   Type space [RFC2865] so that they are RADIUS backward-compatible (AVP
   Code values between 0-255):

Notes:

Location: second text paragraph in Section 7.1.

Rationale:
Wrong temporal relationship (plus missing article);
as in the first paragraph of the section, the action IANA
_has performed_ in conjunction with the publication of the RFC
should have been recorded in the RFC text.

Errata ID: 1934
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Glen Zorn
Date Reported: 2009-10-26
Held for Document Update by: Dan Romascanu

Section 4.2.4 says:

   The MIP6-Home-Link-Prefix AVP (AVP Code 125) is of type OctetString
   and contains the Mobile IPv6 home network prefix information in a
   network byte order. 

It should say:

   The MIP6-Home-Link-Prefix AVP (AVP Code 125) is of type OctetString
   and contains the Mobile IPv6 home network prefix information in
   network byte order. 

Notes:

AFAIK there's only one network byte order.

RFC 5449, "OSPF Multipoint Relay (MPR) Extension for Ad Hoc Networks", February 2009

Source of RFC: ospf (rtg)

Errata ID: 1697
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-03-01
Held for Document Update by: Stewart Bryant

Section A., 2nd para says:

   The following terminology will be used in describing the heuristics:
   D(Y) is the degree of a 1-hop neighbor, router Y (where Y is a member
|  of N(i), defined as the number of neighbors of router Y, EXCLUDING
   all the members of N(i) and EXCLUDING the router performing the
   computation.  The proposed heuristic can then be described as
   follows.  Begin with an empty Flooding-MPR set.  Then:

It should say:

   The following terminology will be used in describing the heuristics:
   D(Y) is the degree of a 1-hop neighbor, router Y (where Y is a member
|  of N(i)), defined as the number of neighbors of router Y, EXCLUDING
   all the members of N(i) and EXCLUDING the router performing the
   computation.  The proposed heuristic can then be described as
   follows.  Begin with an empty Flooding-MPR set.  Then:

Notes:

A missing matching ')' makes the text very ambiguous and confusing.

RFC 5451, "Message Header Field for Indicating Message Authentication Status", April 2009

Note: This RFC has been obsoleted by RFC 7001

Note: This RFC has been updated by RFC 6577

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 2617
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: D. Stussy
Date Reported: 2010-11-09
Held for Document Update by: Sean Turner

Section 2.4.2 says:

   hardfail:  This client is explicitly not authorized to inject or
      relay mail using the sender's DNS domain.

It should say:

   fail:  This client is explicitly not authorized to inject or
      relay mail using the sender's DNS domain.

Notes:

Change [sixth paragraph] for consistency:
1) RFC 4408 (SPF) defines this state as "fail", not "hardfail".
2) The other subsections of 2.4 of this RFC define "fail".
The change makes the result state consistent and parallel to those as noted in other RFCs and for the alternative methods defined in this RFC.

Errata ID: 3195
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Dirk Geschke
Date Reported: 2012-04-17
Held for Document Update by: Barry Leiba
Date Held: 2012-04-18

Section 2.3 says:

     reasonspec = "reason" [CFWS] "=" [CFWS] value
                ; a free-form comment on the reason the given result
                ; was returned

It should say:

     reasonspec = [CFWS] "(" value ")"
                ; a free-form comment on the reason the given result
                ; was returned

Notes:

I am not sure if it is a mistake, but the examples look this way:

Authentication-Results: example.com;
dkim=pass (good signature) header.i=@mail-router.example.net;
dkim=fail (bad signature) header.i=@newyork.example.com

So I think the "reasonspec" is here "(good signature)" and "(bad signature)". All other examples show similar entries for "reasonspec".

[Verifier's note:
This change is INCORRECT. The free-form parenthesized comments are actually part of the "CFWS" production. The confusion is caused by having no examples that use the "reasonspec" production, and that should be fixed if the document is updated.]

Errata ID: 2818
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alessandro Vesely
Date Reported: 2011-05-31
Held for Document Update by: Sean Turner

Section B.5 says:

        Authentication-Results: example.com;
                  sender-id=hardfail header.from=example.com;
                  dkim=pass (good signature) header.i=sender@example.com
        Received: from mail-router.example.com
                      (mail-router.example.com [192.0.2.1])
                  by auth-checker.example.com (8.11.6/8.11.6)
                      with ESMTP id i7PK0sH7021929;
                  Fri, Feb 15 2002 17:19:22 -0800
        Authentication-Results: example.com;
                  auth=pass (cram-md5) smtp.auth=sender@example.com;
                  spf=hardfail smtp.mailfrom=example.com
        Received: from dialup-1-2-3-4.example.net
                      (dialup-1-2-3-4.example.net [192.0.2.200])
                  by mail-router.example.com (8.11.6/8.11.6)
                      with ESMTP id g1G0r1kA003489;
                  Fri, Feb 15 2002 17:19:07 -0800
        DKIM-Signature:  v=1; a=rsa-sha256; s=gatsby; d=example.com;
                  i=sender@example.com; t=1188964191; c=simple/simple;
                  h=From:Date:To:Message-Id:Subject;
                  bh=sEuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m70;
                  b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM=
        From: sender@example.com
        Date: Fri, Feb 15 2002 16:54:30 -0800
        To: receiver@example.com
        Message-Id: <12345.abc@example.com>
        Subject: here's a sample

        Hello!  Goodbye!

It should say:

        Authentication-Results: example.com;
                  spf=pass smtp.mailfrom=example.com
                  dkim=pass (good signature) header.i=@example.com
        Received: from msa.example.com (msa.example.com [192.0.2.1])
                  by mx.example.com (8.11.6/8.11.6)
                      with ESMTP id i7PK0sH7021929;
                  Fri, Feb 15 2002 17:19:22 -0800
        DKIM-Signature:  v=1; a=rsa-sha256; s=gatsby; d=example.com;
                  t=1188964191; c=simple/simple; h=From:Date:To:Subject:
                  Message-Id:Authentication-Results;
                  bh=sEuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m70;
                  b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM=
        Authentication-Results: example.com;
                  auth=pass (details omitted as precautionary measure)
        Received: from [192.0.2.200]
                      (dialup-1-2-3-4.example.net [192.0.2.200])
                  by msa.example.com (8.11.6/8.11.6)
                      with ESMTP id g1G0r1kA003489;
                  Fri, Feb 15 2002 17:19:07 -0800
        From: sender@example.com
        Date: Fri, Feb 15 2002 16:54:30 -0800
        To: receiver@example.com
        Message-Id: <12345.abc@example.com>
        Subject: here's a sample

        Hello!  Goodbye!

Notes:

The corrected example shows how an MSA may prove that it handled submission by signing an A-R field. (I reordered the header, changed host names, changed A-R fields, removed i=, and added A-R in h=)

Some text in the same section may need minor revision. In particular, SPF pass, host name, senderid, and the origin of the DKIM key (in the corrected example, example.net may well be a MUA, while example.com has separate MSA and MX hosts.)

RFC 5454, "Dual-Stack Mobile IPv4", March 2009

Source of RFC: mip4 (int)

Errata ID: 1720
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-03-15
Held for Document Update by: Brian Haberman

Section 3.6,pp.13/14 says:

   When IPv6 runs over an IPv4 tunnel, the IPv6 tunnel endpoints can
   treat the IPv4 tunnel as a single hop link as defined in [RFC4213].
   The two tunnel endpoints, e.g., mobile node and home agent, MUST
   configure link-local IPv6 addresses as defined in Section 3.7 of
   [RFC4213], while they MUST also adhere to the neighbor discovery
   requirements of the same specification, Section 3.8, and the hop
|  limit requirements of Section 3.3.

It should say:

   When IPv6 runs over an IPv4 tunnel, the IPv6 tunnel endpoints can
   treat the IPv4 tunnel as a single hop link as defined in [RFC4213].
   The two tunnel endpoints, e.g., mobile node and home agent, MUST
   configure link-local IPv6 addresses as defined in Section 3.7 of
   [RFC4213], while they MUST also adhere to the neighbor discovery
   requirements of the same specification, Section 3.8, and the hop
|  limit requirements of Section 3.3 in [RFC4213].

Notes:

Rationale: The text should also make clear to which document
(this RFC or RFC 4213) the last section number given refers.
Pointing to RFC 4213 twice (but not in the final case) could be
misunderstood, in particular due to the presence of the comma in
front of the "and" in a two-item list.

RFC 5458, "Security Requirements for the Unidirectional Lightweight Encapsulation (ULE) Protocol", March 2009

Source of RFC: ipdvb (int)

Errata ID: 1747
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-03-30
Held for Document Update by: Brian Haberman

Section 10.2, pg.17 says:

   [GSE]       TS 102 606, "Digital Video Broadcasting (DVB); Generic
               Stream Encapsulation (GSE) Protocol, "European
|              Telecommunication Standards, Institute (ETSI), 2007.
                                          ^^

It should say:

   [GSE]       TS 102 606, "Digital Video Broadcasting (DVB); Generic
               Stream Encapsulation (GSE) Protocol, "European
|              Telecommunication Standards Institute (ETSI), 2007.
                                          ^

Notes:

Rationale: distorting spurious comma.

The immediately preceding entry ('[ETSI-DAT]') is correct
in this respect, but it lacks the publication year.

RFC 5467, "GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)", March 2009

Note: This RFC has been obsoleted by RFC 6387

Source of RFC: ccamp (rtg)

Errata ID: 1715
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-03-13
Held for Document Update by: Adrian Farrel

Section 6, 1st para says:

   This document introduces new message objects for use in GMPLS
   signaling [RFC3473] -- specifically the UPSTREAM_TSPEC,
   UPSTREAM_ADSPEC, and UPSTREAM_FLOWSPEC objects.  These objects
|  parallel the exiting SENDER_TSPEC, ADSPEC, and FLOWSPEC objects but
   are used in the opposite direction.  As such, any vulnerabilities
   that are due to the use of the old objects now apply to messages
   flowing in the reverse direction.

It should say:

   This document introduces new message objects for use in GMPLS
   signaling [RFC3473] -- specifically the UPSTREAM_TSPEC,
   UPSTREAM_ADSPEC, and UPSTREAM_FLOWSPEC objects.  These objects
|  parallel the existing SENDER_TSPEC, ADSPEC, and FLOWSPEC objects but
   are used in the opposite direction.  As such, any vulnerabilities
   that are due to the use of the old objects now apply to messages
   flowing in the reverse direction.

Notes:

Rationale: typo changing the sense !
==> s/exiting/existing/

RFC 5472, "IP Flow Information Export (IPFIX) Applicability", March 2009

Source of RFC: ipfix (ops)

Errata ID: 2875
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Held for Document Update by: Dan Romascanu

Section 5 says:

The threat level to IPIFX itself

It should say:

The threat level to IPFIX itself

Notes:

s/IPIFX/IPFIX/

Errata ID: 2876
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Held for Document Update by: Dan Romascanu

Section 5 says:

even if
IPIFX is not the target of the attack

It should say:

even if
IPFIX is not the target of the attack

Notes:

s/IPIFX/IPFIX/

RFC 5473, "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports", March 2009

Source of RFC: ipfix (ops)

Errata ID: 2911
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Gerhard Muenz
Date Reported: 2011-08-02
Held for Document Update by: Dan Romascanu

Section 10 says:

   The authors would like to thank Guido Pohl for initiating this work
   and for his contribution to early versions of this document.  Thanks
   also to Andrew Johnson, Gehrard Muenz, Brian Trammell, and Paul
   Aitken for their comments and feedback.

It should say:

   The authors would like to thank Guido Pohl for initiating this work
   and for his contribution to early versions of this document.  Thanks
   also to Andrew Johnson, Gerhard Muenz, Brian Trammell, and Paul
   Aitken for their comments and feedback.

Notes:

s/Gehrard/Gerhard/

Typo

RFC 5479, "Requirements and Analysis of Media Security Management Protocols", April 2009

Source of RFC: sip (rai)

Errata ID: 2120
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-04-05
Held for Document Update by: Robert Sparks

Section 4.4,3rd para says:

|  A typical case of using media security where two entities are having
   a Voice over IP (VoIP) conversation over IP-capable networks.
   [...]

It should say:

|  A typical case of using media security is where two entities are
   having a Voice over IP (VoIP) conversation over IP-capable networks.
   [...]

Notes:

Rationale: missing verb.

Errata ID: 2121
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-04-05
Held for Document Update by: Robert Sparks

Section 5.1 - 5.3 says:

Notes:

Sections 5.1 through 5.3 use unexpected irregular, non-uniform
indentation in hanging lists; this is accompanied by dangling
hyphens in 5.2 ( s/third- party/third-party/ and
s/crypto- agility/crypto-agility/ !).

(Keep for update!)
third- party

Errata ID: 2122
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-04-05
Held for Document Update by: Robert Sparks

Section App. A says:

[[ second-to-last paragraph, on mid-page 24: ]]

   Related to SRTP's characteristics is a goal that any SRTP keying
|  mechanism to also be efficient and not cause additional call setup
   delay.

It should say:

   Related to SRTP's characteristics is a goal that any SRTP keying
|  mechanism also be efficient and not cause additional call setup
   delay.

Notes:

Rationale: language/grammar improvement -- keep for update!

Errata ID: 2123
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-04-05
Held for Document Update by: Robert Sparks

Section A.1.7 says:

[[ second paragraph: ]]

   With this proposal, the ECDSA signature, MIKEY-ECIES, and MIKEY-ECMQV
|  function exactly like MIKEY-RSA, and the new DH-Group code function
   exactly like MIKEY-DHSIGN.  Therefore, these ECC mechanisms are not
   discussed separately in this document.

It should say:

   With this proposal, the ECDSA signature, MIKEY-ECIES, and MIKEY-ECMQV
|  function exactly like MIKEY-RSA, and the new DH-Group code functions
   exactly like MIKEY-DHSIGN.  Therefore, these ECC mechanisms are not
   discussed separately in this document.

Notes:

Rationale: singular/plural mismatch -- keep for update!

Errata ID: 2124
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-04-05
Held for Document Update by: Robert Sparks

Section A.1.11 says:

   MIKEYv2 [MIKEYv2] adds mode negotiation to MIKEYv1 and removes the
   time synchronization requirement.  It therefore now takes 2 round
   trips to complete.  In the first round trip, the communicating
   parties learn each other's identities, agree on a MIKEY mode, crypto
|  algorithm, SRTP policy, and exchanges nonces for replay protection.
   In the second round trip, they negotiate unicast and/or group SRTP
   context for SRTP and/or SRTCP.

It should say:

   MIKEYv2 [MIKEYv2] adds mode negotiation to MIKEYv1 and removes the
   time synchronization requirement.  It therefore now takes 2 round
   trips to complete.  In the first round trip, the communicating
   parties learn each other's identities, agree on a MIKEY mode, crypto
|  algorithm, SRTP policy, and exchange nonces for replay protection.
   In the second round trip, they negotiate unicast and/or group SRTP
   context for SRTP and/or SRTCP.

Notes:

Rationale: singular/plural mismatch -- keep for update!

Errata ID: 2125
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-04-05
Held for Document Update by: Robert Sparks

Section A.4.3 says:

|  In SRTP, a cryptographic context is defined as the SSRC, destination
|  network address, and destination transport port number.  Whereas RTP,
|  a flow is defined as the destination network address and destination
   transport port number.  This results in a problem -- how to
   communicate the SSRC so that the SSRC can be used for the
   cryptographic context.

It should say:

|  In SRTP, a cryptographic context is defined by the SSRC, destination
|  network address, and destination transport port number, whereas in RTP,
|  a flow is defined by the destination network address and destination
   transport port number.  This results in a problem -- how to
   communicate the SSRC so that the SSRC can be used for the
   cryptographic context.

Notes:

Rationale: clarification/language improvement -- keep for update!

Errata ID: 2126
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-04-05
Held for Document Update by: Robert Sparks

Section A.5.3 says:

[[ 4th paragraph: ]]

   Currently, several techniques are commonly considered as candidates
|  to provide opportunistic encryption:

It should say:

   Currently, several techniques are commonly considered as candidates
|  to provide best effort encryption:

Notes:

Rationales: consistency with section headline.

RFC 5480, "Elliptic Curve Cryptography Subject Public Key Information", March 2009

Note: This RFC has been updated by RFC 8813

Source of RFC: pkix (sec)

Errata ID: 1727
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-03-16
Held for Document Update by: Pasi Eronen

Section 2.1.1, pg.5 says:

|     o specifiedCurve, which is of type SpecifiedECDomain type (defined
        in [X9.62]), allows all of the elliptic curve domain parameters
        to be explicitly specified.  [...]

It should say:

|     o specifiedCurve, which is of type SpecifiedECDomain (defined
        in [X9.62]), allows all of the elliptic curve domain parameters
        to be explicitly specified.  [...]

Notes:

Location: last bullet in Section 2.1.1.
Rationale: inadvertant replication of "type"

Errata ID: 1728
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-03-16
Held for Document Update by: Pasi Eronen

Section 2.1.1.1 says:

   The namedCurve field in ECParameters uses object identifiers to name
   well-known curves.  This document publishes curve identifiers for the
   fifteen NIST-recommended curves [FIPS186-3].  Other documents can
|  publish other name curve identifiers.  The NIST-named curves are:

It should say:

   The namedCurve field in ECParameters uses object identifiers to name
   well-known curves.  This document publishes curve identifiers for the
   fifteen NIST-recommended curves [FIPS186-3].  Other documents can
|  publish other named curve identifiers.  The NIST named curves are:
                     ^                             ^

Notes:

Location: first paragraph of 2.1.1.1
Rationale:
a) typo: s/name curve/named curve/
b) extraneous hyphen (inserted in final publication processing)
changes semantics in an unfortunate manner; "NIST-named curves"
could be misunderstood as indicating that NIST had named these
'Named Curves'; "NIST-recommended named curves" might have been a
valid alternative but would have incurred too much word repetition.

RFC 5491, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", March 2009

Note: This RFC has been updated by RFC 7459

Source of RFC: geopriv (rai)

Errata ID: 1749
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-03-30
Held for Document Update by: Cullen Jennings

Section 5.2.5,pg.20 says:

     <presence xmlns="urn:ietf:params:xml:ns:pidf"
               xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
               xmlns:gml="http://www.opengis.net/gml"
               xmlns:gs="http://www.opengis.net/pidflo/1.0"
               entity="pres:paul@somecell.example.com">
       <tuple id="arcband">
         <status>
           <gp:geopriv>
             <gp:location-info>
               <gs:ArcBand srsName="urn:ogc:def:crs:EPSG::4326">
                 <gml:pos>-43.5723 153.21760</gml:pos>
                 <gs:innerRadius uom="urn:ogc:def:uom:EPSG::9001">
                   3594
                 </gs:innerRadius>
                 <gs:outerRadius uom="urn:ogc:def:uom:EPSG::9001">
                   4148
                 </gs:outerRadius>
                 <gs:startAngle uom="urn:ogc:def:uom:EPSG::9102">
                   20
                 </gs:startAngle>
                 <gs:openingAngle uom="urn:ogc:def:uom:EPSG::9102">
|                  20
                 </gs:openingAngle>
               </gs:ArcBand>
             </gp:location-info>
             <gp:usage-rules/>
             <gp:method>TA-NMR</gp:method>
           </gp:geopriv>
         </status>
         <timestamp>2007-06-22T20:57:29Z</timestamp>
       </tuple>
     </presence>

                 Figure 12: PIDF-LO Containing an Arc Band

   An important note to make on the arc band is that the center point
|  used in the definition of the shape is not included in resulting
   enclosed area, and that Target may be anywhere in the defined area of
   the arc band.

It should say:

     <presence xmlns="urn:ietf:params:xml:ns:pidf"
               xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
               xmlns:gml="http://www.opengis.net/gml"
               xmlns:gs="http://www.opengis.net/pidflo/1.0"
               entity="pres:paul@somecell.example.com">
       <tuple id="arcband">
         <status>
           <gp:geopriv>
             <gp:location-info>
               <gs:ArcBand srsName="urn:ogc:def:crs:EPSG::4326">
                 <gml:pos>-43.5723 153.21760</gml:pos>
                 <gs:innerRadius uom="urn:ogc:def:uom:EPSG::9001">
                   3594
                 </gs:innerRadius>
                 <gs:outerRadius uom="urn:ogc:def:uom:EPSG::9001">
                   4148
                 </gs:outerRadius>
                 <gs:startAngle uom="urn:ogc:def:uom:EPSG::9102">
                   20
                 </gs:startAngle>
                 <gs:openingAngle uom="urn:ogc:def:uom:EPSG::9102">
|                  120
                 </gs:openingAngle>
               </gs:ArcBand>
             </gp:location-info>
             <gp:usage-rules/>
             <gp:method>TA-NMR</gp:method>
           </gp:geopriv>
         </status>
         <timestamp>2007-06-22T20:57:29Z</timestamp>
       </tuple>
     </presence>

                 Figure 12: PIDF-LO Containing an Arc Band

   An important note to make on the arc band is that the center point
|  used in the definition of the shape is not included in the resulting
   enclosed area, and that Target may be anywhere in the defined area of
   the arc band.

Notes:

a) The openingAngle in Figure 12 does not match the scenario
depicted in Figure 11 and described in the text on page 19.
==> s/20/120/

b) Missing article.

Hint (saving an additional Errata Note):
In Section 5.2.8 (2nd line on pg.24), another article is missing:
s/floors of building/floors of a building/

RFC 5496, "The Reverse Path Forwarding (RPF) Vector TLV", March 2009

Source of RFC: pim (rtg)

Errata ID: 3664
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bharat Joshi
Date Reported: 2013-06-17
Held for Document Update by: Adrian Farrel
Date Held: 2013-09-17

Section 3 says:

Without the PIM extensions specified in this document,
the core router cannot determine where the send the Join,
to the tree cannot be constructed.

It should say:

Without the PIM extensions specified in this document,
the core router cannot determine where to send the Join,
so the tree cannot be constructed.

Notes:

A small typo in "where the send the join".

Errata ID: 3666
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bharat Joshi
Date Reported: 2013-06-17
Held for Document Update by: Adrian Farrel
Date Held: 2013-09-17

Section 3.2 says:

The procedures in this document do not define a way for
BSR messages to be forwarded across a core in which the
BSP IP address is not routable.

It should say:

The procedures in this document do not define a way for
BSR messages to be forwarded across a core in which the
BSR IP address is not routable.

Notes:

BSP IP address is not a term used in PIM BSR. It should be BSR IP address.

Errata ID: 3667
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bharat Joshi
Date Reported: 2013-06-17
Held for Document Update by: Adrian Farrel
Date Held: 2013-09-17

Section 3.3.1 says:

Core 2, and subsequent core routers, will forwarding
the Join along the Vector (i.e., towards Edge 1) 
instead of trying to forward it towards S.

It should say:

Core 2, and subsequent core routers, will forward the
Join along the Vector (i.e., towards Edge 1) instead 
of trying to forward it towards S.

Notes:

A typo in "will forwarding the Join'.
(Modified resolution from original report.)

RFC 5497, "Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs)", March 2009

Source of RFC: manet (rtg)

Errata ID: 1721
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-03-16
Held for Document Update by: Adrian Farrel

Section 6, pg.7 says:

   The following data structure allows the representation of a single
|  time-value, or of a default time-value plus pairs of (time-values,
|  hop counts) for when hop-count-dependent time-values are required.
   [...]

It should say:

   The following data structure allows the representation of a single
|  time-value, or of a default time-value plus pairs of (time-value,
|  hop count) for when hop-count-dependent time-values are required.
   [...]

Notes:

Rationale:
Each pair contains a single 'time-value' and a single 'hop-count'.
See text on pp. 8/9: multiple instances of "(time-value, hop count)".

RFC 5498, "IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols", March 2009

Source of RFC: manet (rtg)

Errata ID: 1741
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Thomas Clausen
Date Reported: 2009-03-24
Held for Document Update by: Adrian Farrel

Section 6 says:

   Action 2:

      IANA has made the following assignments in the "PROTOCOL NUMBERS"
      registry:

      sub-registry "WELL KNOWN PORT NUMBERS"

      Keyword Decimal Description     References
      ------- ------- -----------     ----------
      manet   138     MANET Protocols [RFC5498]

It should say:

   Action 2:

      IANA has made the following assignments in the "PROTOCOL NUMBERS"
      registry:

      Keyword Decimal Description     References
      ------- ------- -----------     ----------
      manet   138     MANET Protocols [RFC5498]

Notes:

The original text reads, for "protocol numbers" that an assignment should be made in the "well known port numbers" sub-registry. There appears to be no such sub-registry in the PROTOCOL NUMBERS registry managed by IANA.

RFC 5506, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", April 2009

Source of RFC: avt (rai)

Errata ID: 2118
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-04-05
Held for Document Update by: Robert Sparks

Section Abstract says:

   This memo discusses benefits and issues that arise when allowing
|  Real-time Transport Protocol (RTCP) packets to be transmitted with
   reduced size.  [...]

It should say:

   This memo discusses benefits and issues that arise when allowing
|  Real-time Transport Control Protocol (RTCP) packets to be transmitted
   with reduced size.  [...]

Notes:

Rationale: Consistency with document title (and RFC 3550).

Errata ID: 2119
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-04-05
Held for Document Update by: Robert Sparks

Section 3.4.5 says:

|  o  Compression of RTCP: No IETF-defined header compression method
      compress RTCP; however, if such methods are developed in the
|     future, these methods must take Reduced-Size RTCP in account.

It should say:

|  o  Compression of RTCP: No IETF-defined header compression methods
      compress RTCP; however, if such methods are developed in the
|     future, these methods must take Reduced-Size RTCP into account.

Notes:

Rationale: singular/plural mismatch; language improvement.

RFC 5519, "Multicast Group Membership Discovery MIB", April 2009

Source of RFC: magma (int)

Errata ID: 3406
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Stig Venaas
Date Reported: 2012-11-13
Held for Document Update by: Brian Haberman

Section 5 says:

mgmdHostCacheLastReporter OBJECT-TYPE
    SYNTAX     InetAddress (SIZE(4|16))
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION
            "The IP address of the source of the last membership report
            received for this IP multicast group address on this
            interface.  If no membership report has been received, this
            object has a value of 0.  The InetAddressType, e.g., IPv4 or
            IPv6, is identified by the mgmdHostCacheAddressType variable
            in the mgmdHostCache table."

It should say:

I don't think it makes sense for a host to keep track of last received report.
Should it be last sent report?

RFC 5520, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", April 2009

Source of RFC: pce (rtg)

Errata ID: 1776
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-05-05
Held for Document Update by: Adrian Farrel

Section 8.2, pg. 18 says:

|  [RBNF]     Farrel, A., "Reduced Backus-Naur Form (RBNF) A Syntax Used
|             in Various Protocol Specifications", Work in Progress,
|             November 2008.

It should say:

|  [RBNF]     Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used
|             in Various Protocol Specifications", RFC 5511, April 2009.

Notes:

Rationale: [[ may be deleted on approval of this erratum ]]

a) The referenced document has been published as RFC 5511 shortly
*before* this RFC.

b) The expansion of "RBNF" in general, and in particular the title
of that document, have been changed before IESG approval, with
the -09 draft version submitted to the RFC Editor.
"RBNF" officially stands for "Routing BNF".
Also, the clarifying colon is missing in the citation.

It could have been expected that the RFC Editor better coordinate
between the documents in his Queue.

Hint: b) also affects other RFCs published since the draft of RFC 5511
has entered the RFC Editor Queue, e.g. RFC 5440 ff. and RFC 5455.

Errata ID: 3583
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Abdussalam Baryun
Date Reported: 2013-04-07
Held for Document Update by: Adrian Farrel

Section 3.2.3 says:

The format of a PCReq message is as follows:

   <PCReq Message>::= <Common Header>
                      [<SVEC-list>]
                      <request-list>

   where:

      <svec-list>::=<SVEC>[<svec-list>]
      <request-list>::=<request>[<request-list>]

It should say:

The format of a PCReq message is as follows:

   <PCReq Message>::= <Common Header>
                      [<svec-list>]
                      <request-list>

   where:

      <svec-list>::=<SVEC>[<svec-list>]
      <request-list>::=<request>[<request-list>]

Notes:

The corrected text is as RFC5440 section 6.4, the editorial difference is <SVEC-list> in RFC5520 and in RFC5440 is <svec-list>.

RFC 5536, "Netnews Article Format", November 2009

Source of RFC: usefor (app)

Errata ID: 1979
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-28
Held for Document Update by: Lisa Dusseault

Section 3.2.7 says:

... in the 2nd paragraph:

   However, software that predates this standard does not use this
|  header, and therefore agents MUST accept articles without the
   Injection-Date header field.

It should say:

   However, software that predates this standard does not use this
|  header field, and therefore agents MUST accept articles without the
   Injection-Date header field.

Notes:

Rationale:
The whole RFC is precise in its use of the IETF standard terminology
as explained in Section 2.1. This phrase is an exception; here as
well "header" should be "header field".

RFC 5537, "Netnews Architecture and Protocols", November 2009

Note: This RFC has been updated by RFC 8315

Source of RFC: usefor (app)

Errata ID: 1983
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-28
Held for Document Update by: Lisa Dusseault

Throughout the document, when it says:

(a)  Section 3.10, first paragraph:

   A gateway transforms an article into the native message format of
   another medium, or translates the messages of another medium into
   news articles, or transforms articles into proto-articles for
   injection into a separate Netnews network.  Encapsulation of a news
|  article into a message of MIME type application/news-transmission, or
   the subsequent undoing of that encapsulation, is not gatewaying since
   it involves no transformation of the article.


(b)  Section 4 (page 29):

|  The updated MIME media type definition of message/news is:

|    MIME type name:           message

|    MIME subtype name:        news
 
     Required parameters:      ...


(c)  Section 4.1 (bottom of page 30):

|  The MIME media type definition of application/news-transmission is:

|    MIME type name:           application

|    MIME subtype name:        news-transmission

     Required parameters:      ...


(d)  Section 4.2 (bottom of page 31 plus top of page 32):

|  The MIME media type definition of application/news-groupinfo is:

|     MIME type name:           application

|     MIME subtype name:        news-groupinfo

      Required parameters:      none

      Optional parameters:      charset, which MUST be a charset
|                               registered for use with MIME text types.
                                It has the same syntax as the parameter
                                defined for text/plain [RFC2046].  [...]


(e)   Section 4.3 (page 33):

|  The MIME media type definition of application/news-checkgroups is:

|     MIME type name:           application

|     MIME subtype name:        news-checkgroups

      Required parameters:      none

      Optional parameters:      charset, which MUST be a charset
|                               registered for use with MIME text types.
                                It has the same syntax as the parameter
                                defined for text/plain [RFC2046].

It should say:

(a)  Section 3.10, first paragraph:

   A gateway transforms an article into the native message format of
   another medium, or translates the messages of another medium into
   news articles, or transforms articles into proto-articles for
   injection into a separate Netnews network.  Encapsulation of a news
|  article into a message of media type application/news-transmission,
   or the subsequent undoing of that encapsulation, is not gatewaying
   since it involves no transformation of the article.


(b)  Section 4 (page 29):

|  The updated media type definition of message/news is:

|     Type name:                message

|     Subtype name:             news
 
      Required parameters:      ...


(c)  Section 4.1 (bottom of page 30):

|  The media type definition of application/news-transmission is:

|     Type name:                application

|     Subtype name:             news-transmission

      Required parameters:      ...


(d)  Section 4.2 (bottom of page 31 plus top of page 32):

|  The media type definition of application/news-groupinfo is:

|     Type name:                application

|     Subtype name:             news-groupinfo

      Required parameters:      none

      Optional parameters:      charset, which MUST be a charset
|                               registered for use with 'text' media
                                types.
                                It has the same syntax as the parameter
                                defined for text/plain [RFC2046].  [...]


(e)   Section 4.3 (page 33):

|  The media type definition of application/news-checkgroups is:

|     Type name:                application

|     Subtype name:             news-checkgroups

      Required parameters:      none

      Optional parameters:      charset, which MUST be a charset
|                               registered for use with 'text' media
                                types.
                                It has the same syntax as the parameter
                                defined for text/plain [RFC2046].

Notes:

Rationale:
RFC 5537 does not follow the IETF standard terminology reinforced
by RFC 4288 and does not properly use the media type registration
template from Section 10 of RFC 4288.
RFC 4288 clarifies that IETF media types (and subtypes) have
outgrown the Internet Email MIME environment and now are used
in non-email environments as well; for instance in the context
of Netnews (this RFC!). Therefore, all mention of "MIME" in the
context of Internet media types must be avoided. See Sections 1
through 3 of RFC 4288 for more rationale and Section 10 there for
the registration template to be used since RFC 4288, in 2005.

Editorial Note (keep for update):
The structure of Section 4 would perhaps more reasonably have been
split into a single-paragraph Section 4 and packing the remainder
of 4. into a new subsection 4.1, "Obsolescence of message/news",
with the remaining subsection numbers 4.* bumped accordingly.

Errata ID: 1980
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-28
Held for Document Update by: Lisa Dusseault
Date Held: 2010-01-19

Throughout the document, when it says:

(a)  Section 3.1, last paragraph:

|        ... trace headers ...

(b)  Section 3.4.4, second paragraph:

|        ... a References header, ...

(c)  Section 3.5, numbered processing steps:
   
    4.  [...]
                                           ... in the Newsgroups
|       header is valid.

    [...]

    6.  [...]
                                                               [...]  It
        MAY add other header fields not already provided by the poster,
        but injecting agents are encouraged to use the Injection-Info
|       header for such information and to minimize the addition of
|       other headers.  [...]
   
|   7.  If the Newsgroups header contains one or more moderated groups
        and the proto-article does not contain an Approved header field,
        the injecting agent MUST either forward it to a moderator as
        specified in Section 3.5.1 or, if that is not possible, reject
        it.  This forwarding MUST be done after adding the Message-ID
|       and Date headers if required, and before adding the Injection-
|       Info and Injection-Date headers.
         
(d)  Section 3.6, first paragraph

|          ... forgery of Path and Injection-Info headers, ...
 
(e)  Section 5.2.1, first paragraph:

   The newgroup control message requests that the specified group be
   created or, if already existing, that its moderation status or
|  description be changed.  The syntax of its Control header field is:
         
         control-command     =/ Newgroup-command
         Newgroup-command    = "newgroup" Newgroup-arguments
         [...]

(f)  Section 5.2.2, first paragraph:

   The rmgroup control message requests that the specified group be
   removed from a news server's list of valid groups.  The syntax of its
|  Control header field is:

g)  Section 5.2.3, first paragraph:
(
                                                 [...]  The syntax of
|  its Control header field is:

(h)  Section 5.2.3, last paragraph:

   The body of the message is an entity of type application/
   news-checkgroups.  It SHOULD be declared as such with appropriate
|  MIME headers, but news servers SHOULD interpret checkgroups messages
|  that lack the appropriate MIME headers as if the body were of type
   application/news-checkgroups for backward compatibility.

(i)  Section 5.3, first paragraph:

   The cancel control message requests that a target article be
   withdrawn from circulation and access.  The syntax of its Control
|  header field is:

(j)  Section 5.5, second paragraph:

   ihave and sendme control messages share similar syntax for their
|  Control header fields and bodies:

(k)  Appendix A, first bullet:

                                              [...]  Folding of the
|     Path header is permitted.

It should say:

(a)  Section 3.1, last paragraph:

|       ... trace header fields ...

(b)  Section 3.4.4, second paragraph:

|        ... a References header field, ...

(c)  Section 3.5, numbered processing steps:

    4.  [...]
                                           ... in the Newsgroups
|       header field is valid.

    [...]

    6.  [...]
                                                               [...]  It
        MAY add other header fields not already provided by the poster,
        but injecting agents are encouraged to use the Injection-Info
|       header field for such information and to minimize the addition 
|       of other header fields.  [...]
   
|  7.   If the Newsgroups header field contains one or more moderated
        groups and the proto-article does not contain an Approved header
        field, the injecting agent MUST either forward it to a moderator
        as specified in Section 3.5.1 or, if that is not possible,
        reject it.  This forwarding MUST be done after adding the
|       Message-ID and Date header fields if required, and before adding
|       the Injection-Info and Injection-Date header fields.

(d)  Section 3.6, first paragraph

|          ... forgery of Path and Injection-Info header fields, ...

(e)  Section 5.2.1, first paragraph:

   The newgroup control message requests that the specified group be
   created or, if already existing, that its moderation status or
|  description be changed.  The syntax of its Control header field
|  value is:
         
         control-command     =/ Newgroup-command
         Newgroup-command    = "newgroup" Newgroup-arguments
         [...]

(f)  Section 5.2.2, first paragraph:

   The rmgroup control message requests that the specified group be
   removed from a news server's list of valid groups.  The syntax of its
|  Control header field value is:

(g)  Section 5.2.3, first paragraph:

                                                 [...]  The syntax of
|  its Control header field value is:

(h)  Section 5.2.3, last paragraph:

   The body of the message is an entity of type application/
   news-checkgroups.  It SHOULD be declared as such with appropriate
|  MIME header fields, but news servers SHOULD interpret checkgroups
|  messages that lack the appropriate MIME header fields as if the body
   were of type application/news-checkgroups for backward compatibility.

(i)  Section 5.3, first paragraph:

   The cancel control message requests that a target article be
   withdrawn from circulation and access.  The syntax of its Control
|  header field value is:

(j)  Section 5.5, second paragraph:

   ihave and sendme control messages share similar syntax for their
|  Control header field values and message bodies:


(k)  Appendix A, first bullet:

                                              [...]  Folding of the
|     Path header field is permitted.


Julian Elie suggests the corrected text: 

Corrected Text
--------------
(a)  Section 3.1, last paragraph:

|       ... trace header fields ...

(b)  Section 3.4, fourth paragraph:

|       ... an Injection-Date header field.

(c)  Section 3.4.4, second paragraph:

|       ... a References header field, ...

(d)  Section 3.5, numbered processing steps:

  4.  [...]
                                         ... in the Newsgroups
|       header field is valid.

  [...]

  6.  [...]
                                                             [...]  It
      MAY add other header fields not already provided by the poster,
      but injecting agents are encouraged to use the Injection-Info
|       header field for such information and to minimize the addition |       of other header fields.  [...]
 |  7.   If the Newsgroups header field contains one or more moderated
      groups and the proto-article does not contain an Approved header
      field, the injecting agent MUST either forward it to a moderator
      as specified in Section 3.5.1 or, if that is not possible,
      reject it.  This forwarding MUST be done after adding the
|       Message-ID and Date header fields if required, and before adding
|       the Injection-Info and Injection-Date header fields.

(e)  Section 3.6, first paragraph

|       ... forgery of Path and Injection-Info header fields, ...

(f)  Section 5.2.1, first paragraph:

 The newgroup control message requests that the specified group be
 created or, if already existing, that its moderation status or
|  description be changed.  The syntax of its Control header field
|  body is:
               control-command     =/ Newgroup-command
       Newgroup-command    = "newgroup" Newgroup-arguments
       [...]

(g)  Section 5.2.2, first paragraph:

 The rmgroup control message requests that the specified group be
 removed from a news server's list of valid groups.  The syntax of its
|  Control header field body is:

(h)  Section 5.2.3, first paragraph:

                                               [...]  The syntax of
|  its Control header field value is:

(i)  Section 5.2.3, last paragraph:

 The body of the message is an entity of type application/
 news-checkgroups.  It SHOULD be declared as such with appropriate
|  MIME header fields, but news servers SHOULD interpret checkgroups
|  messages that lack the appropriate MIME header fields as if the body
 were of type application/news-checkgroups for backward compatibility.

(j)  Section 5.3, first paragraph:

 The cancel control message requests that a target article be
 withdrawn from circulation and access.  The syntax of its Control
|  header field body is:

(k)  Section 5.5, second paragraph:

 ihave and sendme control messages share similar syntax for their
|  Control header field bodies and message bodies:

(l)  Appendix A, first bullet:

                                            [...]  Folding of the
|     Path header field is permitted.

Notes:

Rationale:
Contrary to its companion document, RFC 5536, this RFC mixes precise
IETF terminology for protocol elements and colloquial abuse of it in
various places. For clarity and consistency, it should also
inequivocally make use of the standard terminology; the fields
of the "header" that a protocol layer or sub-layer adds to its
payload are "header fields", not "headers" in itself.
Similarly, denoting as "header field" a "header field value" is
confusing -- items (e), (f), (g), (i), and (j) above.

Errata ID: 1982
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-28
Held for Document Update by: Lisa Dusseault

Section 3.4.2, NOTE says:

       ... unintended repeat injection into the same network, ...
                           ^

It should say:

       ... unintended repeated injection into the same network, ...
                           ^^^

RFC 5545, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", September 2009

Note: This RFC has been updated by RFC 5546, RFC 6868, RFC 7529, RFC 7953, RFC 7986, RFC 9073, RFC 9074, RFC 9253

Source of RFC: calsify (app)

Errata ID: 3038
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Brent Bloxam
Date Reported: 2011-11-30
Held for Document Update by: Peter Saint-Andre
Date Held: 2011-12-06

Section 3.8.7.2 says:

Value Type:  DATE-TIME

   Property Parameters:  IANA and non-standard property parameters can
      be specified on this property.

   Conformance:  This property MUST be included in the "VEVENT",
      "VTODO", "VJOURNAL", or "VFREEBUSY" calendar components.

   Description:  The value MUST be specified in the UTC time format.

      This property is also useful to protocols such as [2447bis] that
      have inherent latency issues with the delivery of content.  This
      property will assist in the proper sequencing of messages
      containing iCalendar objects.

It should say:

Value Type:  DATE-TIME. The time value MUST be in the DATE WITH UTC
      TIME form defined for the DATE-TIME value type.

   Property Parameters:  IANA and non-standard property parameters can
      be specified on this property.

   Conformance:  This property MUST be included in the "VEVENT",
      "VTODO", "VJOURNAL", or "VFREEBUSY" calendar components.

   Description:  This property is also useful to protocols such as
      [2447bis] that have inherent latency issues with the delivery of
      content.  This property will assist in the proper sequencing of
      messages containing iCalendar objects.

Notes:

Application of the DATE-TIME value type is inconsistent in the RFC, and can lead to ambiguity since DATE-TIME can take on three different forms. The wording for the corrected Value Type for DTSTAMP is similar to the DTSTART property's Value Type. This is to make it clear that the only acceptable form is DATE WITH UTC TIME. You can also see evidence of defining specificity inline with the Value Type in the GEO property.

The spec author comments: "To improve consistency, we should modify Section 3.8.7.2. Date-Time Stamp and Section 3.8.7.3. Last Modified to use the same phrasing as Section 3.8.7.1. Date-Time Created and Section 3.8.2.1. Date-Time Completed."

Errata ID: 5505
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Ken Murchison
Date Reported: 2018-09-26
Held for Document Update by: Francesca Palombini
Date Held: 2024-01-16

Section 3.2.19 says:

       tzidparam  = "TZID" "=" [tzidprefix] paramtext

It should say:

       tzidparam  = "TZID" "=" [tzidprefix] param-value

Notes:

TZID appears to be the only parameter defined 5545 whose value can not be a quoted string. This is problematic in that time zone IDs such as "GMT-03:00" are beginning to appear (note the embedded colon). RFC 6868 has no mechanism to quote a colon character, as it relies on such characters appearing within a quoted string. I see no technical reason why a TZID parameter can not be quoted, and existing implementations already accept quoted TZIDs.

Errata ID: 2495
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Scott Furry
Date Reported: 2010-08-21
Held for Document Update by: Peter Saint-Andre

Section 3.2.7 says:

Description: This property parameter identifies the inline encoding
    used in a property value.  The default encoding is "8BIT",
    corresponding to a property value consisting of text.  The
    "BASE64" encoding type corresponds to a property value encoded
    using the "BASE64" encoding defined in [RFC2045].

It should say:

Description: This property parameter identifies the inline encoding
    used in a property value.  The default encoding is "8BIT",
    corresponding to a property value consisting of text.  The
    "BASE64" encoding type corresponds to a property value encoded
    using the "BASE64" encoding defined in [RFC4648].
                                            ^^^^^^^

Notes:

Section "Format Definition" above the "Description" paragraph cites [RFC2045] as defining value "8BIT" and [RFC4648] covering value "BASE64".

Errata ID: 4626
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tim Ruffing
Date Reported: 2016-02-25
Held for Document Update by: Barry Leiba
Date Held: 2016-02-25

Section A.1 says:

[Missing item]

It should say:

6.  The value of the "DUE" property MUST be strictly later in time than
    the value of the "DTSTART" property (as opposed to only "equal or
    later in time").

Notes:

See http://www.ietf.org/mail-archive/web/calsify/current/msg02217.html

RFC 5549, "Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop", May 2009

Note: This RFC has been obsoleted by RFC 8950

Source of RFC: softwire (int)

Errata ID: 5253
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Shyam Sethuram
Date Reported: 2018-02-02
Held for Document Update by: Alvaro Retana
Date Held: 2020-08-24

Section 6.2 says:

Length of Next Hop Network Address = 16 (or 32)

It should say:

Length of Next Hop Network Address = 24 (or 48)

Notes:

The lengths should include the RD length also, right ?

===
This report is being addressed in draft-ietf-bess-rfc5549revision.

RFC 5555, "Mobile IPv6 Support for Dual Stack Hosts and Routers", June 2009

Note: This RFC has been updated by RFC 8553

Source of RFC: mext (int)

Errata ID: 1805
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Laganier
Date Reported: 2009-07-08
Held for Document Update by: Brian Haberman

Section 8 says:

      The IPv4 home address option described in Section 3.1.1 has been
      assigned value 29.  This option is included in the mobility header
      described in [RFC3775].

      The IPv4 address acknowledgement option described in Section 3.2.1
      has been assigned value 29.  This option is included in the
      mobility header described in [RFC3775].

It should say:

      The IPv4 home address option described in Section 3.1.1 has been
      assigned value 29.  This option is included in the mobility header
      described in [RFC3775].

      The IPv4 address acknowledgement option described in Section 3.2.1
      has been assigned value 30.  This option is included in the
      mobility header described in [RFC3775].

Notes:

There's an error in the IANA section of the RFC: while both the IANA registry <http://www.iana.org/assignments/mobility-parameters/> and the section of the RFC describing the option <http://tools.ietf.org/html/rfc5555#section-3.2.1> have the correct type value for the IPv4 address acknowledgement option, i.e., 30, the IANA section <http://tools.ietf.org/html/rfc5555#section-8> assigns type value 29 to both the IPv4 home address option and IPv4 address acknowledgement option.

RFC 5556, "Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement", May 2009

Source of RFC: trill (int)

Errata ID: 2532
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vishwas Manral
Date Reported: 2010-09-28
Held for Document Update by: Brian Haberman

Section 2.4 says:

   When such snooping and optimization is performed by spanning-tree-
   based bridges, it done at each bridge based on the traffic observed
   on that bridge's ports.

It should say:

   When such snooping and optimization is performed by spanning-tree-
   based bridges, it is done at each bridge based on the traffic observed
   on that bridge's ports.

RFC 5559, "Pre-Congestion Notification (PCN) Architecture", June 2009

Source of RFC: pcn (tsv)

Errata ID: 1973
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-21
Held for Document Update by: Lars Eggert

Section 4.1, Fig. 4 says:

|                                      +---------+   Result
|                                   +->|Threshold|-------+
|                                   |  |  Meter  |       |
|                                   |  +---------+       V
         +----------+   +- - - - -+  |                +------+
         |   BA     |   |         |  |                |      |    Marked
Packet =>|Classifier|==>| Dropper |==?===============>|Marker|==> Packet
Stream   |          |   |         |  |                |      |    Stream
         +----------+   +- - - - -+  |                +------+
|                                   |  +---------+       ^
|                                   |  | Excess  |       |
|                                   +->| Traffic |-------+
|                                      |  Meter  |   Result
|                                      +---------+

It should say:

|                                       +---------+   Result
|                                    +->|Threshold|-------+
|                                    |  |  Meter  |       |
|                                    |  +---------+       V
         +----------+   +- - - - -+  |                +------+
         |   BA     |   |         |  |                |      |    Marked
Packet =>|Classifier|==>| Dropper |==?===============>|Marker|==> Packet
Stream   |          |   |         |  |                |      |    Stream
         +----------+   +- - - - -+  |                +------+
|                                    |  +---------+       ^
|                                    |  | Excess  |       |
|                                    +->| Traffic |-------+
|                                       |  Meter  |   Result
|                                       +---------+

Notes:

Rationale: Misalignment in Figure, breaking arrow lines.
(Keep for update!)

Errata ID: 1974
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-21
Held for Document Update by: Lars Eggert

Section 6.3, pg.36 says:

   4.  PCN-flows may have different precedence, but the applicability of
|      the PCN mechanisms for emergency use (911, GETS (Government
|      Telecommunications Service), WPS (Wireless Priority Service),
       MLPP (Multilevel Precedence and Premption), etc.) is out of
       scope.

It should say:

   4.  PCN-flows may have different precedence, but the applicability of
       the PCN mechanisms for emergency use (911, GETS (Government
|      Emergency Telecommunications Service), WPS (Wireless Priority
       Service), MLPP (Multilevel Precedence and Premption), etc.) is
       out of scope.

Notes:

Rationale:
Incomplete expansion of acronym "GETS":
important word "Emergency" missing.

Errata ID: 1975
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-21
Held for Document Update by: Lars Eggert

Section 10.2, pg.45 says:

   [Hancock02]      Hancock, R. and E. Hepworth, "Slide 14 of 'NSIS: An
|                   Outline Framework for QoS Signalling'", May 2002, <h
|                   ttp://www-nrc.nokia.com/sua/nsis/interim/
                    nsis-framework-outline.ppt>.

It should say:

   [Hancock02]      Hancock, R. and E. Hepworth, "Slide 14 of 'NSIS: An
|                   Outline Framework for QoS Signalling'", May 2002,
|                   <http://www-nrc.nokia.com/sua/nsis/interim/
                    nsis-framework-outline.ppt>.

Notes:

Rationale:
Unpleasant and unexpected line folding -- tool (xml2rfc) issue?

Errata ID: 1976
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-21
Held for Document Update by: Lars Eggert

Section 10.2, pg.46 says:

   [Kumar01]        Kumar, A., Rastogi, R., Silberschatz, A., and B.
                    Yener, "Algorithms for Provisioning Virtual Private
                    Networks in the Hose Model", Proceedings ACM SIGCOMM
|                   (ITC16), , 2001.

It should say:

   [Kumar01]        Kumar, A., Rastogi, R., Silberschatz, A., and B.
                    Yener, "Algorithms for Provisioning Virtual Private
                    Networks in the Hose Model", Proceedings ACM SIGCOMM
|                   (ITC16), August 2001.

RFC 5575, "Dissemination of Flow Specification Rules", August 2009

Note: This RFC has been obsoleted by RFC 8955

Note: This RFC has been updated by RFC 7674

Source of RFC: idr (rtg)

Errata ID: 4482
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Wesley Eddy
Date Reported: 2015-09-25
Held for Document Update by: Alvaro Retana
Date Held: 2016-02-16

Section 4 (page 11) says:

   An example of a flow specification encoding for: "all packets to
   10.0.1/24 from 192/8 and port {range [137, 139] or 8080}".

   +------------------+----------+-------------------------+
   | destination      | source   | port                    |
   +------------------+----------+-------------------------+
   | 0x01 18 0a 01 01 | 02 08 c0 | 04 03 89 45 8b 91 1f 90 |
   +------------------+----------+-------------------------+

It should say:

   An example of a flow specification encoding for: "all packets to
   10.1.1/24 from 192/8 and port {range [137, 139] or 8080}".

   +------------------+----------+-------------------------+
   | destination      | source   | port                    |
   +------------------+----------+-------------------------+
   | 0x01 18 0a 01 01 | 02 08 c0 | 04 03 89 45 8b 91 1f 90 |
   +------------------+----------+-------------------------+

OR:

   An example of a flow specification encoding for: "all packets to
   10.0.1/24 from 192/8 and port {range [137, 139] or 8080}".

   +------------------+----------+-------------------------+
   | destination      | source   | port                    |
   +------------------+----------+-------------------------+
   | 0x01 18 0a 00 01 | 02 08 c0 | 04 03 89 45 8b 91 1f 90 |
   +------------------+----------+-------------------------+

Notes:

The prefix stated in the text, does not match the one encoded in the example.

10.0.1/24 should be 10.1.1/24 to match the example, or alternatively the example should change from:
0x01 18 0a 01 01
to:
0x01 18 0a 00 01

Errata ID: 3610
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sergey Antipov
Date Reported: 2013-04-30
Held for Document Update by: Stewart Bryant
Date Held: 2013-09-17

Section 4 says:

   If a given component type within a prefix in unknown, the prefix in
   question cannot be used for traffic filtering purposes by the
   receiver.  Since a flow specification has the semantics of a logical
   AND of all components, if a component is FALSE, by definition it
   cannot be applied.  However, for the purposes of BGP route
   propagation, this prefix should still be transmitted since BGP route
   distribution is independent on NLRI semantics.

It should say:

   If a given component type within a prefix is unknown, the prefix in
   question cannot be used for traffic filtering purposes by the
   receiver.  Since a flow specification has the semantics of a logical
   AND of all components, if a component is FALSE, by definition it
   cannot be applied.  However, for the purposes of BGP route
   propagation, this prefix should still be transmitted since BGP route
   distribution is independent of NLRI semantics.

Notes:

Two minor typos:
- If a given component type within a prefix _in_ unknown
- independent _on_

RFC 5577, "RTP Payload Format for ITU-T Recommendation G.722.1", July 2009

Source of RFC: avt (rai)

Errata ID: 1826
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-08-11
Held for Document Update by: Robert Sparks

Throughout the document, when it says:

Khz

It should say:

kHz

Notes:

Rationale:
Proper Names when used in unit symbols keep their capitalization,
e.g., Hertz (Hz), Coulomb (C), Tesla (T), Henry (H), Farad (F);
however, the unit factor 1000 is always indicated by a
*lowercase* prefix 'k' !

Instances of improper case:
o last paragraph of Section 1 (top of page 3) - 2 instances,
o last paragraph of Section 3.1 (mid-page 3) - 4 instances,
o Section 4.1.1, 'Required Parameters' clause
(last paragraph on page 6) - 2 instances,
o Section 4.1.1, 'Optional Parameters' clause
(first paragraph on page 7) - 1 instance,
o Section 4.1.1, 'Interoperability considerations' clause
(mid-page 7) - 2 instances,
o Section 5.1, 3rd paragraph (mid-page 8) - 1 instance,
o Section 7, first paragraph (mid-page 9) - 1 instance

Note that the initial part of Section 1 on page 2 and the final
part of the last paragraph of Section 1 (on page 3) are correct!

Errata ID: 1827
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-08-11
Held for Document Update by: Robert Sparks

Section 6, pg.9 says:

[[ second paragraph on page 9: ]]

|                  [...].  Another mechanism that may be used is IPsec
|  [RFC4301] Transport Layer Security (TLS) [RFC5246] (RTP over TCP);
   other alternatives may exist.

It should say:

|                  [...].  Other mechanisms that may be used are IPsec
|  [RFC4301] or Transport Layer Security (TLS) [RFC5246] (RTP over TCP);
   other alternatives may exist.

Notes:

Rationale: IPsec and TLS are two distinct and very different protocols!

RFC 5582, "Location-to-URL Mapping Architecture and Framework", September 2009

Source of RFC: ecrit (rai)

Errata ID: 2041
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Karl Heinz Wolf
Date Reported: 2010-02-12
Held for Document Update by: Robert Sparks

Section 7.1 says:

Each tree can map a location described by either civic or geographic
coordinates, but not both, for one type of service (such as
'sos.police', 'sos.fire' or 'counseling') and one location profile,
although nothing prevents re-using the same servers for multiple,
different services or both types of coordinates.  The collection of
all trees for one service and location profile is known as a forest.

It should say:

Each tree can map a location described by civic and/or geographic
coordinates, for one type of service (such as 'sos.police', 'sos.fire' or
'counseling'), although nothing prevents re-using the same servers for
multiple, different services.  The collection of all trees for one service 
is known as a forest.

Notes:

Trees may have mapping data in multiple location profiles, not only in a single profile. In particular, according to RFC 5222, a LoST server must understand civic and geographic coordinates. Furthermore, there is no mechanism to discover LoST servers based on the location profile.

Errata ID: 2042
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Karl Heinz Wolf
Date Reported: 2010-02-12
Held for Document Update by: Robert Sparks

Section 8 says:

   To facilitate orientation among the trees, we introduce a forest
   guide (FG), which keeps track of the coverage regions of all the
   trees for one service and location profile.  

It should say:

   To facilitate orientation among the trees, we introduce a forest
   guide (FG), which keeps track of the coverage regions of all the
   trees for one service.  

Notes:

Trees may have mapping data in multiple location profiles, not only in a single profile. In particular, according to RFC 5222, a LoST server must understand civic and geographic coordinates. Furthermore, there is no mechanism to discover LoST servers based on the location profile.

Errata ID: 2043
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Karl Heinz Wolf
Date Reported: 2010-02-12
Held for Document Update by: Robert Sparks

Section 3 says:

   resolver:  A resolver is contacted by a seeker, consults a forest
      mapping server, and then resolves the query using an appropriate
      tree.  Resolvers may cache query results.


   tree:  A tree consists of a self-contained hierarchy of authoritative
      mapping servers for a particular service.  Each tree exports its
      coverage region to the forest mapping servers.

It should say:

   resolver:  A resolver is contacted by a seeker, consults a forest
      guide, and then resolves the query using an appropriate
      tree.  Resolvers may cache query results.


   tree:  A tree consists of a self-contained hierarchy of authoritative
      mapping servers for a particular service.  Each tree exports its
      coverage region to the forest guide.

Notes:

The server should be correctly referred to as "forest guide", there is no "forest mapping server" in the architecture.

RFC 5583, "Signaling Media Decoding Dependency in the Session Description Protocol (SDP)", July 2009

Source of RFC: mmusic (rai)

Errata ID: 1828
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-08-11
Held for Document Update by: Robert Sparks

Section 5.2.2, pg.10 says:

[[ last paragraph of Section 5.2.2: ]]

          v
|  Further, dependency types MUST be defined in a Standards-Track
   document.

It should say:

|  Further dependency types MUST be defined in a Standards-Track
   document.

Notes:

Rationale:
In this case, "Further" is an attribute; the spurious comma
separates this attribute from its noun "[dependency] types",
and thus changes the sense of the sentence in an inappropriate
manner.

Errata ID: 1829
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-08-11
Held for Document Update by: Robert Sparks

Section 6.3, pg.12 says:

   The signaling mechanisms defined in this document MUST NOT be used to
|  negotiate between using the attribute-value pair (AVP) [RFC3551] and
                               ^^^^^^^^^^^^^^^^^^^^ 
   SAVP [RFC3711] profile for RTP.  However, both profiles MAY be used
   separately or jointly with the signaling mechanism defined in this
   document.

It should say:

   The signaling mechanisms defined in this document MUST NOT be used to
|  negotiate between using the Audio/Video Profile (AVP) [RFC3551] and
|  Secure Audio/Video Profile (SAVP) [RFC3711] for RTP.  However, both
   profiles MAY be used separately or jointly with the signaling
   mechanism defined in this document.

Notes:

Rationale:
Nonsensical acronym expansion (introduced late in the process).
The correct expansion could have been found by inspection of
the References in Section 10.1, in the entry for [RFC3551] !

Only changing the bad expansion turns the sentence weird;
therefore, the above change proposal tries to balance the
language by also expanding "SAVP" and saving the trailing
instance of "profile" (being part of both acronym expansions).

RFC 5584, "RTP Payload Format for the Adaptive TRansform Acoustic Coding (ATRAC) Family", July 2009

Source of RFC: avt (rai)

Errata ID: 1830
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-08-11
Held for Document Update by: Robert Sparks

Section 10.2, pg.29 says:

   Also, validity checking of the received audio packets MUST be
   performed.  It can be carried out by the decoding process, as the
   ATRAC format is designed so that the validity of data frames can be
|  determined by decoding the algorithm.  [...]
                 ^^^^^^^^^^^^

It should say:

   Also, validity checking of the received audio packets MUST be
   performed.  It can be carried out by the decoding process, as the
   ATRAC format is designed so that the validity of data frames can be
|  determined by the decoding algorithm.  [...]
                 ^^^^^^^^^^^^

Notes:

Rationale: Confusing word twister.

RFC 5589, "Session Initiation Protocol (SIP) Call Control - Transfer", June 2009

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rai

Errata ID: 3273
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Victor S. Osipov
Date Reported: 2012-06-29
Held for Document Update by: Robert Sparks

Section 5 says:

3. There were concerns with authorizing out-of-dialog REFERs. The
authorization policy for REFER in most implementations piggybacks
on the authorization policy for INVITE (which is, in most cases,
based simply on "I placed or answered this call").

Globally Routable UA URIs (GRUUs) [SIP-GRUU] can be used to address
problem 1. Problem 2 can be addressed using the Target-Dialog header
field defined in [RFC4538]. In the immediate term, this solution to
problem 2 allows the existing REFER authorization policy to be
reused.

It should say:

3. There were concerns with authorizing out-of-dialog REFERs. The
authorization policy for REFER in most implementations piggybacks
on the authorization policy for INVITE (which is, in most cases,
based simply on "I placed or answered this call").

Globally Routable UA URIs (GRUUs) [SIP-GRUU] can be used to address
problem 1. Problem 2 can be addressed using the Target-Dialog header
field defined in [RFC4538]. In the immediate term, this solution to
problem 2 allows the existing INVITE authorization policy to be
reused by REFER (thus solving problem 3).

Notes:

The phrase 'allows the existing REFER authorization policy to be reused' leads to a misunderstanding and confusion, because in actual fact INVITE authorization policy may be reused by REFER, not inversely.
The correction is proposed in order to clear up confusion.

Errata ID: 1892
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dale Worley
Date Reported: 2009-09-23
Held for Document Update by: Robert Sparks

Section 6 says:

page 10:

   F5 INVITE Transferee -> Transfer Target
...
   CSeq: 521 REFER

page 14:

   F5 INVITE Transferee -> Transfer Target
...
   CSeq: 521 REFER

page 15:

   F6 NOTIFY Transferee -> Transferor
...
   CSeq: 29889 INVITE

It should say:

page 10:

   F5 INVITE Transferee -> Transfer Target
...
   CSeq: 521 INVITE

page 14:

   F5 INVITE Transferee -> Transfer Target
...
   CSeq: 521 INVITE

page 15:

   F6 NOTIFY Transferee -> Transferor
...
   CSeq: 29889 NOTIFY

RFC 5595, "The Datagram Congestion Control Protocol (DCCP) Service Codes", September 2009

Note: This RFC has been updated by RFC 6335

Source of RFC: dccp (tsv)

Errata ID: 1891
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-22
Held for Document Update by: Lars Eggert
Date Held: 2011-03-01

Section 2.7, pg.10 says:

OLD:
 o  It preserves the 4 lowest bits of the final bytes of the Service
    Code, which allows many common series of Service Codes to be
    mapped to a set of adjacent port numbers, e.g., Foo1, and Foo2;
    Fooa and Foob would be assigned adjacent ports.

It should say:

NEW:
 o  It preserves the 3 lowest bits of the final bytes of the Service
                     ^^
    Code, which allows many common series of Service Codes to be
    mapped to a set of adjacent port numbers, e.g., Foo1, and Foo2;
    Fooa and Foob would be assigned adjacent ports.

Notes:

Simply trying the full example shows that the statement is not
entirely correct. The quoted formula reveals that only the least
significant *3* bits are left unchanged (due to the '<<3'
operation on sc[2]). It turns out that ranges of *8* contiguous
SC values are mapped to contiguous 8 port numbers but, depending
on the two least significant bits of sc[2], groups of 4 adjacent
ranges are shuffled around. More complicated patterns arise for
the next higher level of 4-clusters of range-groups, etc.
Thus, the situation is not hopeless for the indicated purpose,
but much more complicated than indicated in the RFC text.

I leave it as an exercise to the interested reader to figure
out the details for the size of range she is interested in.

A future revision of the RFC however should fix the text.

RFC 5598, "Internet Mail Architecture", July 2009

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 2956
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Dave Crocker
Date Reported: 2011-09-03
Held for Document Update by: Peter Saint-Andre

Section 4 says:

Figure 5: Protocols and Services, MTA-hMDA list of protocols

It should say:

{{ The text in Section 4.4 cites the two, standards-track 'turn' mechanisms, but these are not listed in the MTA-hMDA link of Figure 5. }}

Notes:

Clearly this is a non-critical enhancement. Still, it would be good to add whenever the document is updated.

Errata ID: 3282
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alessandro Vesely
Date Reported: 2012-07-11
Held for Document Update by: Barry Leiba

Section 2.3 says:

Mail Service Providers (MSPs)

It should say:

either:
   Mailbox Providers (MPs)
or:
   Email Service Providers (ESPs)

Notes:

The ambiguity between the two concepts possibly indicated with similar terms is frequent. The distinction reported here is due to JD Falk, and it seems to be taking roots.

RFC 5601, "Pseudowire (PW) Management Information Base (MIB)", July 2009

Source of RFC: pwe3 (int)

Errata ID: 1856
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-08
Held for Document Update by: Stewart Bryant
Date Held: 2011-11-12

Section 12, pg.18 says:

  pwPeerAddrType OBJECT-TYPE
     SYNTAX        InetAddressType
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
          "Denotes the address type of the peer node.  It should be
           set to 'unknown' if PE/PW maintenance protocol is not used
           and the address is unknown."
     DEFVAL { ipv4 }
     ::= { pwEntry 8 }

  pwPeerAddr OBJECT-TYPE
     SYNTAX        InetAddress
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
          "This object contains the value of the peer node address
           of the PW/PE maintenance protocol entity.  This object
           SHOULD contain a value of all zeroes if not applicable
           (pwPeerAddrType is 'unknown')."
     ::= { pwEntry 9 }

It should say:

  pwPeerAddrType OBJECT-TYPE
     SYNTAX        InetAddressType
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
|         "Denotes the address type of the peer node stored in
|          pwPeerAddr.  It should be set to 'unknown' if PE/PW
           maintenance protocol is not used and the address is
           unknown."
     DEFVAL { ipv4 }
     ::= { pwEntry 8 }

  pwPeerAddr OBJECT-TYPE
     SYNTAX        InetAddress
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
          "This object contains the value of the peer node address
|          of the PW/PE maintenance protocol entity. The type of this
|          object is determined by the corresponding pwPeerAddr object.
|          This object MUST contain a zero-length octet string if not
           applicable (pwPeerAddrType is 'unknown')."
     ::= { pwEntry 9 }

Notes:

Rationale:

a) RFC 4001 requests that every use of InetAddressType and
InetAddress makes explicit the coupling between the objects.
Hence, the DESCRIPTION clause(s) need to be amended.
For clarity, the Corrected text does so for both objects.

b) RFC 4001 (pg. 6) specifies that an InetAddressType object of
value unknown(0) correspond to an InetAddress object
that is a zero-length string, unless unknown(0) is used to
indicate an internet address type not (yet) known (at the time
of publication of RFC 4001). All Standards Track MIB modules
making use of InetAddressType so far couple the value unknown(0)
with an InetAddress of size 0, because an unknown IP address
of a (known) specific type can be represented by the
"unspecified address" of that address format.
Hence, the original text should be changed.
This has been done in the perceived spirit of the conformance
specification for pwPeerAddr on mid-page 51 and page 54.

This is a correct, however, it is unlikely that "unknown" is ever used in an implementation. Therefore it is not critical to fix this, hence classifying as hold for document update.

Errata ID: 1852
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-08
Held for Document Update by: Stewart Bryant
Date Held: 2011-11-12

Section 12, pg.27 says:

  pwLastChange OBJECT-TYPE
|    SYNTAX        TimeTicks
     MAX-ACCESS    read-only
     STATUS        current
     DESCRIPTION
        "The value of sysUpTime at the time the PW entered
         its current operational state.  If the current state was
         entered prior to the last re-initialization of the local
         network management subsystem, then this object contains a
         zero value."
     ::= { pwEntry 36 }

It should say:

  pwLastChange OBJECT-TYPE
|    SYNTAX        TimeStamp
     MAX-ACCESS    read-only
     STATUS        current
     DESCRIPTION
        "The value of sysUpTime at the time the PW entered
         its current operational state.  If the current state was
         entered prior to the last re-initialization of the local
         network management subsystem, then this object contains a
         zero value."
     ::= { pwEntry 36 }

Notes:

[[ Location is bottom of page 27 ]]

Like any other object intended to keep a snapshot of sysUpTime,
this object must have the corrresponding SYNTAX of TimeStamp
(cf. pwCreateTime, on mid-page 27); a SYNTAX of TimeTicks is
appropriate on;y for 'running clocks' started at a particular
event (like pwUpTime, also on pg. 27, just above pwLastChange).


Although technically correct that the SYNTAX should be TimeStamp, this
is safe because the SYNTAX of TimeStamp is TimeTicks.

Errata ID: 1853
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-08
Held for Document Update by: Stewart Bryant
Date Held: 2011-11-12

Section 11, 1st para says:

   This section contains the initial version of the IANA-PWE3-MIB.  IANA
|  has updated this MIB module based on expert review as defined in
   [RFC5226].  Each new assignment of PW type or PW PSN type made by
   IANA based on the procedures described in [RFC4446] should be
   documented in the online version of IANA-PWE3-MIB.  The current
   IANA-PWE3-MIB contains PW types as requested in [RFC4446] and
   [RFC4863].

It should say:

   This section contains the initial version of the IANA-PWE3-MIB.  IANA
|  will update this MIB module based on expert review as defined in
   [RFC5226].  Each new assignment of PW type or PW PSN type made by
   IANA based on the procedures described in [RFC4446] should be
   documented in the online version of IANA-PWE3-MIB.  The current
   IANA-PWE3-MIB contains PW types as requested in [RFC4446] and
   [RFC4863].

Notes:

Wrong temporal relationship!

Errata ID: 1854
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-08
Held for Document Update by: Stewart Bryant

Section 11, pg. 8 says:

[[ 2nd para of DESCRIPTION clause for ianaPwe3MIB MODULE-IDENTITY ]]

                                                         ... The
           Designated Expert will be selected by the IESG Area
|          Director(s) of the internet Area.
                              ^

It should say:

                                                         ... The
           Designated Expert will be selected by the IESG Area
|          Director(s) of the Internet Area.
                              ^

Errata ID: 1855
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-08
Held for Document Update by: Stewart Bryant
Date Held: 2011-11-12

Section 12, pg.17 says:

[[ 3rd para of DESCRIPTION clause of pw Owner OBJECT-TYPE ]]

           'genFecSignaling' is used in case of LDP signaling with
|          the generalized FEC.

It should say:

           'genFecSignaling' is used in case of LDP signaling with
|          the generalized FEC element.

Notes:

This is correct, but is thought unlikely to cause any problems

Errata ID: 1857
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-09
Held for Document Update by: Stewart Bryant

Section 12, pg.19 says:

[[ DESCRIPTION clause of pwAttachedPwIndex OBJECT-TYPE ]]

     DESCRIPTION
         "If the PW is attached to another PW instead of a local
          native service, this item indicates the pwIndex of the
          attached PW.  Otherwise, this object MUST
|         be set to zero.  Attachment to another PW will have no
          PW specific entry in any of the service MIB modules."

It should say:

     DESCRIPTION
         "If the PW is attached to another PW instead of a local
          native service, this item indicates the pwIndex of the
          attached PW.  Otherwise, this object MUST
|         be set to zero.  A PW attached to another PW will have no
          PW specific entry in any of the service MIB modules."

Notes:

Rationale: Clarity of language.

Errata ID: 1863
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-09
Held for Document Update by: Stewart Bryant
Date Held: 2011-11-12

Section 12, pg. 40 says:

[[ DESCRIPTION clause for pwIndexMappingTable OBJECT-TYPE: ]]

          "This table enables the reverse mapping of the unique
           PWid parameters [peer IP, PW type, and PW ID] and the
           pwIndex.  The table is not applicable for PWs created
|          manually or by using the generalized FEC."

It should say:

          "This table enables the reverse mapping of the unique
           PWid parameters [peer IP, PW type, and PW ID] and the
           pwIndex.  The table is not applicable for PWs created
|          manually or by using the generalized FEC element."

Notes:

Rationale: Added precision (cf. EID=1855).

Errata ID: 1865
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-09
Held for Document Update by: Stewart Bryant
Date Held: 2011-11-12

Section 12, pg.41 says:

  pwIndexMappingPeerAddr OBJECT-TYPE
     SYNTAX        InetAddress
     MAX-ACCESS    not-accessible
     STATUS        current
     DESCRIPTION
|         "IP address of the peer node."
     ::= { pwIndexMappingEntry 4 }

It should say:

  pwIndexMappingPeerAddr OBJECT-TYPE
     SYNTAX        InetAddress
     MAX-ACCESS    not-accessible
     STATUS        current
     DESCRIPTION
|         "IP address of the peer node. The type of this object
           is determined by the value of the corresponding
           pwIndexMappingPeerAddrType object." 
     ::= { pwIndexMappingEntry 4 } 

Notes:

Rationale: cf. EID=1856

Errata ID: 1867
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-09
Held for Document Update by: Stewart Bryant
Date Held: 2011-11-12

Section 12, pg.43 says:

[[ DESCRIPTION clause for pwPeerMappingPeerAddr OBJECT-TYPE: ]]

|         "IP address of the peer node."

It should say:

|         "IP address of the peer node. The type of this object
           is determined by the value of the corresponding
           pwPeerMappingPeerAddrType object."

Notes:

Rationale: cf. EID=1856 and EID=1865.

Errata ID: 1868
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-09
Held for Document Update by: Stewart Bryant

Section 12, pg.43 says:

[[ REFERENCE clause of pwUpDownNotifEnable OBJECT-TYPE: ]]

        "See also [RFC3413] for explanation that
         notifications are under the ultimate control of the
|        MIB module in this document."

It should say:

        "See also [RFC3413] for explanation that
         notifications are under the ultimate control of the
|        MIB module in that document."

Notes:

Rationale: "this" in the given context is likely to be understood
as pointing to "this" RFC, RFC 5601!

Errata ID: 1869
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-09
Held for Document Update by: Stewart Bryant

Section 12, pg.44 says:

  pwDeletedNotifEnable  OBJECT-TYPE
     SYNTAX      TruthValue
     MAX-ACCESS  read-write
     STATUS      current
     DESCRIPTION
        "If this object is set to true(1), then it enables the
|        emission of pwDeleted notification; otherwise, this
         notification is not emitted."
     REFERENCE
        "See also [RFC3413] for explanation that
         notifications are under the ultimate control of the
|        MIB module in this document."

It should say:

  pwDeletedNotifEnable  OBJECT-TYPE
     SYNTAX      TruthValue
     MAX-ACCESS  read-write
     STATUS      current
     DESCRIPTION
        "If this object is set to true(1), then it enables the
|        emission of pwDeleted notifications; otherwise, this
         notification is not emitted."
     REFERENCE
        "See also [RFC3413] for explanation that
         notifications are under the ultimate control of the
|        MIB module in that document."

Notes:

Rationale:
a) plural is needed;
b) as for EID=1868

Errata ID: 1870
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-09
Held for Document Update by: Stewart Bryant

Section 12, pg.44 says:

[[ DESCRIPTION clause for pwGenFecIndexMappingTable OBJECT-TYPE: ]]

          "This table enables the reverse mapping of the unique
           PWid parameters [GroupAttachmentID, LocalAttachmentID,
           and PeerAttachmentID] and the pwIndex.  The table is
|          only applicable for PW using the generalized FEC."

It should say:

          "This table enables the reverse mapping of the unique
           PWid parameters [GroupAttachmentID, LocalAttachmentID,
           and PeerAttachmentID] and the pwIndex.  The table is
|          only applicable for PWs using the generalized FEC."

Notes:

Rationale: plural is needed!

Note:

Surprisingly, the whole definition of the Gen Fec PW ID mapping table
(starting with this entry and extending down to the top of page 47)
is not contained in the part of the MIB module enclosed in comments
'Reverse mapping tables' / 'End of reverse mapping tables'
(extending from top of page 40 to mid-page 43).
It would have been better to move the specification of this table
into that part as well, i.e. to its end -- irrespective of the OID
value assigned to the pwGenFecIndexMappingTable object.

Errata ID: 1873
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-09
Held for Document Update by: Stewart Bryant

Section 12, pg.51 says:

[[ on mid-pg. 51: ]]

     OBJECT       pwPeerAddr
     SYNTAX       InetAddress (SIZE(0|4))
     DESCRIPTION "An implementation is only required to support
|                 0, 4 address sizes."

It should say:

     OBJECT       pwPeerAddr
     SYNTAX       InetAddress (SIZE(0|4))
     DESCRIPTION "An implementation is only required to support
|                 address sizes 0 and 4."

Notes:

Rationale:
Grammar: "4 address sizes" has quite different semantics than
"address size 4" !

Note:

This issue recurs on page 54, and a similar correction applies there.

RFC 5616, "Streaming Internet Messaging Attachments", August 2009

Source of RFC: lemonade (app)

Errata ID: 2095
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-03-17
Held for Document Update by: Alexey Melnikov
Date Held: 2010-03-23

Section Title says:

Streaming Internet Messaging Attachments

It should say:

Internet Message Access Protocol (IMAP): Streaming Message Attachments

Notes:

In order to more easily locate the document, it would
have been very useful for prospective readers to find the primary
protocol to which this RFC relates mentioned already in the
document title.

RFC 5617, "DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)", August 2009

Note: This RFC has been updated by RFC 8553

Source of RFC: dkim (sec)

Errata ID: 2849
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Murray Kucherawy
Date Reported: 2011-06-29
Held for Document Update by: Sean Turner

Section 6 says:

<section 6.5 missing>

It should say:

6.5.  Non-Compliant Messages

Both DKIM and ADSP are predicated on receiving valid RFC5322 messages as input.
Where, for example, a message under evaluation has multiple From fields, it is
unspecified from which From field the Author Domain is to be extracted.
Implementers are advised to return a result that indicates the Author Domain
could not be determined when the input message has multiple From header fields,
or even more generally if the message does not comply with RFC5322.

Notes:

This is an issue brought up during the RFC4871bis effort.

An alternative to the above would be to make this a normative requirement rather than a Security Consideration.

RFC 5623, "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering", September 2009

Source of RFC: pce (rtg)

Errata ID: 1898
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-30
Held for Document Update by: Adrian Farrel

Section 4.2.2,pg.14 says:

     Step 4:  H1 initiates higher-layer signaling using the computed
|             explicit router of H2-L1-L2-H3-H4.
                            ^

It should say:

     Step 4:  H1 initiates higher-layer signaling using the computed
|             explicit route of H2-L1-L2-H3-H4.

Notes:

Rationale: confusing typo.

RFC 5632, "Comcast's ISP Experiences in a Proactive Network Provider Participation for P2P (P4P) Technical Trial", September 2009

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 1948
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-11-26
Held for Document Update by: Lisa Dusseault

Section 7, 2nd para says:

   The experiment did show that an ISP can improve performance without
   exposing fine-grained details about network structure, which might
   otherwise be a security concern (see Section 3.1 (P4P Fine Grain) and
|  Section 3.2 (P4P Coarse Grain).  [...]
                                 ^

It should say:

   The experiment did show that an ISP can improve performance without
   exposing fine-grained details about network structure, which might
   otherwise be a security concern (see Section 3.1 (P4P Fine Grain) and
|  Section 3.2 (P4P Coarse Grain)).  [...]
                                 ^

Notes:

Rationale: Mismatch of parentheses.

RFC 5644, "IP Performance Metrics (IPPM): Spatial and Multicast", October 2009

Note: This RFC has been updated by RFC 6248

Source of RFC: ippm (ops)

Errata ID: 2321
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Cypryan T. Klish II
Date Reported: 2010-07-09
Held for Document Update by: Lars Eggert

Section 2.7 says:

Figure 2 is ambiguous for two reasons:

Use "X" for both types of nodes: 1) the graphic only labels intermediate nodes with "X" and 2) both "nodes that are points of interest" and "nodes that are not points of interest" are label "X" in the note following the graphic. Thus there is no difference between nodes that are points of interest and those that are not, and the distinction between the two types is not apparent

The destination node "Dst" has no representation in the "Hosts" identifier column.  the "Dst" label is in the same vertical column as the Hosts

It should say:

Change a subset of intermediate nodes (all currently labeled X) to "Y". Change the second line of the note to read "'Y' are nodes thatare not points of interest.

Shift the "Hosts column to the left to provide vertical separation for "Dst". Label "Dst" as "K" in the hosts column.

Notes:

It would be useful to clarify if the nodes that are points of interest must be contiguous or if the subset can truly be selected in an arbitrary fashion. For a contiguous subset of point of interest nodes it is suggested that it would be useful to associate this with a higher abstract architectural construct (container) since the group might well align with a physical or administrative segment, or provider specific segment of the network. This would aid in modeling the system for performance management applications since a one to one relationship can be created between the higher level container object and the segment object

RFC 5648, "Multiple Care-of Addresses Registration", October 2009

Note: This RFC has been updated by RFC 6089

Source of RFC: mext (int)

Errata ID: 1904
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-10-08
Held for Document Update by: Brian Haberman

Section 6.2, pg.25 says:

a)
In Section 4.3, the description of the 'Care-of Address' field
in the Binding Identifier Mobility Option specifies:

   Care-of Address

      If a Binding Identifier mobility option is included in a Binding
      Update for the home registration, either IPv4 or IPv6 care-of
      addresses for the corresponding BID can be stored in this field.
      For the binding registration to correspondent nodes (i.e., route
      optimization), only IPv6 care-of addresses can be stored in this
      field.  If no address is specified in this field, the length of
!     this field MUST be zero (i.e., not appear in the option).  If the
!     option is included in any messages other than a Binding Update,
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
!     the length of this field MUST also be zero.
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
b)
Contrary to the "MUST" in the last line, Section 6.2 of the RFC says,
on mid-page 25, where it elaborates on Binding Acknowledgement messages:

   If all the above operations are successfully completed and the 'A'
   flag is set in the Binding Update, a Binding Acknowledgement
   containing the Binding Identifier mobility options MUST be sent to
!  the mobile node.  Whenever a Binding Acknowledgement is sent, all the
                                ^^^^^^^^^^^^^^^^^^^^^^^
!  Binding Identifier mobility options stored in the Binding Update MUST
!  be copied to the Binding Acknowledgement except the Status field.
!  The Care-of Address field in each Binding Identifier mobility option,
|  however, MAY be omitted, because the mobile node can match a
            ^^^
!  corresponding Binding Update List entry using the BID.

It should say:

a)
<< no change >>

b)
   If all the above operations are successfully completed and the 'A'
   flag is set in the Binding Update, a Binding Acknowledgement
   containing the Binding Identifier mobility options MUST be sent to
   the mobile node.  Whenever a Binding Acknowledgement is sent, all the
   Binding Identifier mobility options stored in the Binding Update MUST
   be copied to the Binding Acknowledgement except the Status field.
   The Care-of Address field in each Binding Identifier mobility option,
|  however, MUST be omitted, because the mobile node can match a
   corresponding Binding Update List entry using the BID.

Notes:

Rationale:
The inconsistency is described with the Original Text.
The Corrected Text proposed gives preference to the requirement
from Section 4.3, which seems to be reasonable for efficiency
and consistent with other parts of the specification.

RFC 5651, "Layered Coding Transport (LCT) Building Block", October 2009

Source of RFC: rmt (tsv)

Errata ID: 2000
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-01-10
Held for Document Update by: Magnus Westerlund

Section 6.1, pg. 25 says:

[ second-to-last paragraph, mid-page 25 : ]

   For the reasons mentioned above, this document does not pose any
   restriction on packet sizes.  However, network efficiency
   considerations recommend that the sender uses an as large as possible
   packet payload size, but in such a way that packets do not exceed the
|  network's maximum transmission unit size (MTU), or when fragmentation
   coupled with packet loss might introduce severe inefficiency in the
   transmission.

It should say:

   For the reasons mentioned above, this document does not pose any
   restriction on packet sizes.  However, network efficiency
   considerations recommend that the sender uses an as large as possible
   packet payload size, but in such a way that packets do not exceed the
|  network's maximum transmission unit size (MTU), because fragmentation
   coupled with packet loss might introduce severe inefficiency in the
   transmission.

Notes:

Rationale: "or when" does not make proper sense here; "because" does.

Errata ID: 2001
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-01-10
Held for Document Update by: Magnus Westerlund

Section 5.2.1, pg.20 says:

   EXT_AUTH, HET=1 Packet authentication extension.  Information used to
                   authenticate the sender of the packet.  The format of
                   this Header Extension and its processing is outside
                   the scope of this document and is to be communicated
                   out-of-band as part of the session description.

|  It is RECOMMENDED that senders provide some form of packet
                   authentication.  If EXT_AUTH is present, whatever
                   packet authentication checks that can be performed
                   immediately upon reception of the packet SHOULD be
                   performed before accepting the packet and performing
                   any congestion-control-related action on it.

|  Some packet authentication schemes impose a delay of several seconds
                   between when a packet is received and when the packet
                   is fully authenticated.  Any congestion control
                   related action that is appropriate SHOULD NOT be
                   postponed by any such full packet authentication.

It should say:

   EXT_AUTH, HET=1 Packet authentication extension.  Information used to
                   authenticate the sender of the packet.  The format of
                   this Header Extension and its processing is outside
                   the scope of this document and is to be communicated
                   out-of-band as part of the session description.

|                  It is RECOMMENDED that senders provide some form of
                   packet authentication.  If EXT_AUTH is present,
                   whatever packet authentication checks that can be
                   performed immediately upon reception of the packet
                   SHOULD be performed before accepting the packet and
                   performing any congestion-control-related action on
                   it.

|                  Some packet authentication schemes impose a delay of
                   several seconds between when a packet is received and
                   when the packet is fully authenticated.  Any
                   congestion control related action that is appropriate
                   SHOULD NOT be postponed by any such full packet
                   authentication.

Notes:

Rationale:
Improper formatting of hanging list item consisting of three
paragraphs, visually pretending two more list items;
flaw apparently introduced in final pre-publication stages --
drafts were formatted properly.

RFC 5652, "Cryptographic Message Syntax (CMS)", September 2009

Note: This RFC has been updated by RFC 8933

Source of RFC: smime (sec)

Errata ID: 7863
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: heasley
Date Reported: 2024-03-21
Held for Document Update by: Deb Cooley
Date Held: 2024-03-22

Section 5.2 says:

"... and the content
   field of the EncapsulatedContentInfo value MUST be omitted."

It should say:

"... and the eContent
   field of the EncapsulatedContentInfo value MUST be omitted."

Notes:

No 'content' field exists and I do not think this is referring to another structure.

Errata ID: 2026
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-01-28
Held for Document Update by: Tim Polk

Section 5.3, pg. 15 says:

[[  around the page break from page 14 to page 15: ]]

      digestAlgorithm identifies the message digest algorithm, and any
      associated parameters, used by the signer.  The message digest is
      computed on either the content being signed or the content
<< page break >>
      together with the signed attributes using the process described in
      Section 5.4.  The message digest algorithm SHOULD be among those
|     listed in the digestAlgorithms field of the associated SignerData.
                                                             ^^^^^^^^^^
      Implementations MAY fail to validate signatures that use a digest
      algorithm that is not included in the SignedData digestAlgorithms
      set.

It should say:

      digestAlgorithm identifies the message digest algorithm, and any
      associated parameters, used by the signer.  The message digest is
      computed on either the content being signed or the content
      together with the signed attributes using the process described in
      Section 5.4.  The message digest algorithm SHOULD be among those
|     listed in the digestAlgorithms field of the associated SignedData.
      Implementations MAY fail to validate signatures that use a digest
      algorithm that is not included in the SignedData digestAlgorithms
      set.

Notes:

Rationale:
There's no such ASN.1 type/object named "SignerData" in relevant
specifications. Text should refer to "SignedData" instead.
This is an undetected legacy flaw inherited literally from RFC 2630,
RFC 3369, and RFC 3852.

Errata ID: 3867
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jos Breek
Date Reported: 2014-01-16
Held for Document Update by: Kathleen Moriarty
Date Held: 2015-03-24

Section 5.3 says:

digestAlgorithm identifies the message digest algorithm, and any
associated parameters, used by the signer.

It should say:

digestAlgorithm identifies the message digest algorithm, and any
associated parameters, used by the signer in the signature Generation 
Process. 

Notes:

The text stated that the message digest algorithm is "used by the signer". It is unclear for what purpose the message digest algorithm is used. This recommendation is editorial and was accepted.


Additional text provided was not accepted as there is no requirement that digest used on the body is the same as the digest used in the signature operation.

The following sentence was suggested (and rejected):
"The message digest algorithm shall be equal to the message
digest algorithm used in the signatureAlgorithm field."

With the explanation in the original errata report for this additional sentence as:
There are implementations that use the message digest algorithm specified in the messageDigest field instead of the message digest algorithm specified in the signatureAlgorithm.

Is the purpose of the messageDigest field to nest the hashing algorithm used in the signing process? If so, please use the corrected text to clarify the goal of the field.

RFC 5654, "Requirements of an MPLS Transport Profile", September 2009

Source of RFC: mpls (rtg)

Errata ID: 2073
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eric Gray
Date Reported: 2010-03-12
Held for Document Update by: Adrian Farrel

Section 2.5.4 says:

83  The external controls as defined in [RFC4427] MUST be supported.

       A.  External controls overruled by higher priority requests
           (e.g., administrative requests and requests due to link/node
           failures) or unable to be signaled to the remote end (e.g.,
           due to a coordination failure of the protection state) MUST
           be dropped.

It should say:

83  The external controls as defined in [RFC4427] MUST be supported.

       A.  External controls overruled by higher priority requests
           (e.g., administrative requests and requests due to link/node
           failures) or unable to be signaled to the remote end (e.g.,
           due to a coordination failure of the protection state) MUST
           be ignored.

Notes:

Dropping a control is meaningless. The original intent may have been to say "control messages", but this requirement is stated in the section "Management-Plane Operation of Protection and Restoration"

In any case, using "ignored" instead of "dropped" fixes the problem regardless of the original intention.

Errata ID: 6434
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Peter Goorts
Date Reported: 2021-02-20
Held for Document Update by: Deborah Brungard
Date Held: 2021-02-26

Section 2.4 says:

52  An MPLS-TP control plane MUST support operation of the recovery	
	       functions described in Section 2.8.	 	

It should say:

52  An MPLS-TP control plane MUST support operation of the recovery	
	       functions described in Section 2.5.

Notes:

There is no section 2.8 in this document. During revision, section changed to 2.5.

RFC 5655, "Specification of the IP Flow Information Export (IPFIX) File Format", October 2009

Source of RFC: ipfix (ops)

Errata ID: 2030
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Andrei Rohau
Date Reported: 2010-02-01
Held for Document Update by: Dan Romascanu

Section A.5, pg.56 says:

 Bringing together the examples above and adding message headers as
 appropriate, a hex dump of the first 317 bytes of the example File
 constructed above would appear as in the annotated Figure 10 below.

...


   144: D6 C7 58 BE 44 E6 60 06 4E 78 74 AE 7D 00 00 00

   176:|00 0A 00 50 47 0A B6 E5 00 00 00 01 00 00 00 01
      [^ second message header (length 80 bytes) -->
   192:|01 01 00 0E 00 47 0A B6 B9 47 0C 07 1B 00|01 02
      [^ time window rec -> [ session detail rec ^ -->
   208: 00 1C 00 C0 00 02 1E 0C 00 02 1F 80 01 12 83 84

   224: 0A 47 0A B6 E5 47 0C 07 48 00|01 03 00 18 00 3E
           [ message checksum record ^ -->
   240: 2B 37 08 CE B2 0E 30 11 32 12 4A 5F E3 AD DB 00

   256:|00 0A 05 10 47 0A B6 E5 00 00 00 06 00 00 00 01
      [^ third message header (length 1296 bytes) -->
   272:|01 00 04 E6|47 0A B6 B9 C0 00 02 02 C0 00 02 03
      [^ set hdr ][^ first data rec -->
   288: 80 02 00 50 06 00 00 46 50 00 00 00 41

It should say:

 Bringing together the examples above and adding message headers as
 appropriate, a hex dump of the first 285 bytes of the example File
 constructed above would appear as in the annotated Figure 10 below.

...

   144: D6 C7 58 BE 44 E6 60 06 4E 78 74 AE 7D 00 00 00

   160:|00 0A 00 50 47 0A B6 E5 00 00 00 01 00 00 00 01
      [^ second message header (length 80 bytes) -->
   176:|01 01 00 0E 00 47 0A B6 B9 47 0C 07 1B 00|01 02
      [^ time window rec -> [ session detail rec ^ -->
   192: 00 1C 00 C0 00 02 1E 0C 00 02 1F 80 01 12 83 84

   208: 0A 47 0A B6 E5 47 0C 07 48 00|01 03 00 18 00 3E
           [ message checksum record ^ -->
   224: 2B 37 08 CE B2 0E 30 11 32 12 4A 5F E3 AD DB 00

   240:|00 0A 05 10 47 0A B6 E5 00 00 00 06 00 00 00 01
      [^ third message header (length 1296 bytes) -->
   256:|01 00 04 E6|47 0A B6 B9 C0 00 02 02 C0 00 02 03
      [^ set hdr ][^ first data rec -->
   272: 80 02 00 50 06 00 00 46 50 00 00 00 41

Notes:

Should be pretty obvious as total size of the hex dump is only 285 bytes.

Please note that the whole Figure 10 is supposed to contain 317 bytes!

Errata ID: 1984
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-28
Held for Document Update by: Dan Romascanu

Section 5.8, pg.13 says:

   Certain use cases for archival flow storage require the storage of
   collection infrastructure details alongside the data itself.  These
   details include information about how and when data was received, and
   where it was received from.  They are useful for auditing as well as
|  for the replaying received data for testing purposes.

It should say:

   Certain use cases for archival flow storage require the storage of
   collection infrastructure details alongside the data itself.  These
   details include information about how and when data was received, and
   where it was received from.  They are useful for auditing as well as
|  for replaying received data for testing purposes.

Notes:

Alternative for last line:

| for the replay of received data for testing purposes.


Additional editorial remark (keep for update!):
In Section 1.1, there's an unexpected blank line inserted into
the first paragraph on page 5.

Errata ID: 1985
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-28
Held for Document Update by: Dan Romascanu

Section 7.1, pg.16 says:

... third bullet, at the bottom of page 16:

   o  resolve any conflict between a resent definition and a previous
      definition by assuming that the new Template replaces the old, as
|     consistent with Template expiration and ID reuse when using UDP at
      the IPFIX transport protocol; and

It should say:

   o  resolve any conflict between a resent definition and a previous
      definition by assuming that the new Template replaces the old, as
|     consistent with Template expiration and ID reuse when using UDP as
      the IPFIX transport protocol; and

Notes:

Rationale: typo; s/at/as/ .

Errata ID: 1986
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-28
Held for Document Update by: Dan Romascanu

Section 8.1.4, pg.26 says:

... first paragraph:

                                          [...].  This Options Template
|  also allows the storage of the export session metadata provided the
   Export Session Details Options Template, for storing information from
   multiple Transport Sessions in the same IPFIX File.

It should say:

                                          [...].  This Options Template
|  also allows the storage of the export session metadata provided by
   the Export Session Details Options Template, for storing information
   from multiple Transport Sessions in the same IPFIX File.

Notes:

Rationale: missing word, "by".

Errata ID: 1987
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-28
Held for Document Update by: Dan Romascanu

Section 9, 1st para says:

   In order to ensure the integrity of IPFIX Files and the identity of
   IPFIX File Writers, File Writers and File Readers SHOULD provide for
   an interoperable and easily implemented method for signing IPFIX
|  Files, and verifying those signatures.  This section specifies method
|  via CMS detached signatures.

It should say:

   In order to ensure the integrity of IPFIX Files and the identity of
   IPFIX File Writers, File Writers and File Readers SHOULD provide for
   an interoperable and easily implemented method for signing IPFIX
|  Files, and verifying those signatures.  This section specifies one
|  such method via CMS detached signatures.

Notes:

Rationale: missing word(s); suggest inserting "one such".

Errata ID: 1990
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-28
Held for Document Update by: Dan Romascanu

Section 12, pg.42 says:

                                                 [...].  However, aside
   from merely applying CMS for signatures, there are several security
|  issues which much be considered in certain circumstances; these are
   covered in the subsections below.

It should say:

                                                 [...].  However, aside
   from merely applying CMS for signatures, there are several security
|  issues that must be considered in certain circumstances; these are
   covered in the subsections below.

Notes:

Rationale: broken grammar; s/which much/that must/ .

Errata ID: 1991
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-28
Held for Document Update by: Dan Romascanu

Section 12.2, pg.43 says:

...  first paragraph:

                                                 [...].  The channel
|  between the Exporting Process to Collecting Process using IPFIX is
   signed by the Exporting Process key and protected via TLS and DTLS,
   while the File is signed by the File Writer key and protected via
   CMS.  [...]

It should say:

                                                 [...].  The channel
|  from the Exporting Process to the Collecting Process using IPFIX is
   signed by the Exporting Process key and protected via TLS and DTLS,
   while the File is signed by the File Writer key and protected via
   CMS.  [...]

Notes:

Rationale:
"channel between xxx to yyy" does not make sense. Either
"channel _from_ xxx to yyy" or "channel between xxx _and_ yyy"
should be written.
The Corrected Text above suggests the first alternative (based
on the essential unidirectionality of the information flow) and
balances the use of articles.

Errata ID: 1992
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-28
Held for Document Update by: Ron Bonica

Throughout the document, when it says:

Section 15.1 contains the outdated Normative Reference:

|  [RFC3852]    Housley, R., "Cryptographic Message Syntax (CMS)",
|               RFC 3852, July 2004.

"[RFC3852]" is used in Sections 5.6, 9.1, 9.1.1, and 12.

It should say:

At the time of publication of RFC 5655, the replacement RFC already
had been published six weeks ago and should have been referred to,
due to the essential corrections it incorporates:

|  [RFC5652]    Housley, R., "Cryptographic Message Syntax (CMS)",
|               RFC 5652, September 2009.

Errata ID: 2881
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Held for Document Update by: Dan Romascanu

Section B.2 says:

   6.  Copy each FlowSet from the Netflow V9 packet to the IPFIX Message
       after the header.  Replace Set ID 0 with Set ID 2 for Template
       Sets, and Set ID 1 with Set ID 3 for Options Template Sets.

It should say:

   6.  Copy each FlowSet from the NetFlow V9 packet to the IPFIX Message
       after the header.  Replace Set ID 0 with Set ID 2 for Template
       Sets, and Set ID 1 with Set ID 3 for Options Template Sets.

Notes:

s/Netflow/NetFlow/

Per RFC 3954 and searches of cisco.com and google, the correct term is "NetFlow".

Errata ID: 3687
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2013-07-26
Held for Document Update by: Benoit Claise
Date Held: 2013-07-26

Section 8.1.4 says:

   | messageScope [scope]       | A marker denoting this Option        |
   |                            | applies to the whole IPFIX message;  |
   |                            | content is ignored.

It should say:

   | messageScope [scope]       | A marker denoting this Option        |
   |                            | applies to the whole IPFIX Message;  |
   |                            | content is ignored.

Notes:

s/IPFIX message/IPFIX Message/

- because that's the technical term defined in RFC5101 to which this draft refers

Errata ID: 3688
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2013-07-26
Held for Document Update by: Benoit Claise
Date Held: 2013-07-26

Section B.1.1 says:

   Export Time:   Aside from being called UNIX Secs in the NetFlow V9
      packet header specification, the export time in seconds since 1
      January 1970 at 0000 UTC appears in both NetFlow V9 and IPFIX
      message headers.

It should say:

   Export Time:   Aside from being called UNIX Secs in the NetFlow V9
      packet header specification, the export time in seconds since 1
      January 1970 at 0000 UTC appears in both NetFlow V9 and IPFIX
      Message headers.

Notes:

s/IPFIX message/IPFIX Message/

- because that's the technical term defined in RFC5101 to which this draft refers

RFC 5656, "Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer", December 2009

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 2710
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mattias Wadenstein
Date Reported: 2011-02-10
Held for Document Update by: Tim Polk
Date Held: 2011-03-09

Section 9 says:

The SHA2 family 
consists of four variants -- SHA-224, SHA-256, SHA-384, and SHA-521 
-- named after their digest lengths.

It should say:

The SHA2 family 
consists of four variants -- SHA-224, SHA-256, SHA-384, and SHA-512 
-- named after their digest lengths.

Notes:

The SHA2 family has a SHA-512 variant, not SHA-521.

RFC 5659, "An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge", October 2009

Source of RFC: pwe3 (int)

Errata ID: 2127
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-04-05
Held for Document Update by: Stewart Bryant

Section 5.* says:

a)
5.1.1.  Forwarding

b)
5.1.2.  Native Service Processing

It should say:

a)
5.2.  Forwarding

b)

5.3.  Native Service Processing

Notes:

Rationale:
Obviously, the sections numbered 5.1.1 and 5.1.2 are _not_
subordinate to section 5.1. Pseudowire Pre-Processing,
but of a sibling level.

Errata ID: 2128
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-04-05
Held for Document Update by: Stewart Bryant

Section 6., pg.15 says:

                       [...]  The receiving S-PE swaps the existing PW
   demultiplexer for the demultiplexer of the next segment and then
|  sends the PDU over transport tunnel in PSN2.  [...]

It should say:

                       [...]  The receiving S-PE swaps the existing PW
   demultiplexer for the demultiplexer of the next segment and then
|  sends the PDU over the transport tunnel in PSN2.  [...]

Notes:

Rationale: missing article.

RFC 5661, "Network File System (NFS) Version 4 Minor Version 1 Protocol", January 2010

Note: This RFC has been obsoleted by RFC 8881

Note: This RFC has been updated by RFC 8178, RFC 8434

Source of RFC: nfsv4 (wit)

Errata ID: 2505
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Eisler
Date Reported: 2010-08-31
Held for Document Update by: Magnus Westerlund
Date Held: 2019-10-25

Section 12.5.4. says:

   Because of this inconsistency, it is necessary to resynchronize the
   client with the metadata server and its storage devices and make any
   potential changes available to other clients. 

AND

   For file-based layouts, synchronization of
   attributes between the metadata and storage devices, primarily the
   size attribute, is required.

It should say:

   Because of this inconsistency, in general, it is necessary to resynchronize the
   client with the metadata server and its storage devices and make any
   potential changes available to other clients. 

AND

   For file-based layouts, synchronization of
   attributes between the metadata and storage devices, primarily the
   size attribute, is not required, but the use of LAYOUTCOMMIT provides 
   a way to optimize the synchronization. Indeed, if a LAYOUT4_NFSV4_1_FILES
   layout is ever revoked, the metadata server MUST direct all data servers to
   commit any modified data of the file to stable storage, and synchronize 
   the file's size and time_modify attributes on the metadata server
   with the those on the data server.

Notes:

Without this correction, the implication is that a file could be truncated if a LAYOUT4_NFSV4_1_FILES layout was revoked before LAYOUTCOMMIT, which would then mean that every append operation to a data server would require a LAYOUTCOMMIT, which is an absurd consequence.

Errata ID: 3065
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: David Black
Date Reported: 2011-12-27
Held for Document Update by: Martin Stiemerling

Section 12.7.4 says:

      If the metadata server's
      consistency checks on loca_layoutupdate succeed, then the metadata
      server MUST commit the data (as described by the loca_offset,
      loca_length, and loca_layoutupdate fields of the arguments) that
      was written to the storage device. If the metadata server's
      consistency checks on loca_layoutupdate fail, the metadata server
      rejects the LAYOUTCOMMIT operation and makes no changes to the
      file system.  However, any time LAYOUTCOMMIT with loca_reclaim
      TRUE fails, the pNFS client has lost all the data in the range
      defined by <loca_offset, loca_length>.  

It should say:

      If the metadata server's
      consistency checks on loca_layoutupdate succeed, then the metadata
      server MUST commit the changed data that was written to the storage
      device within the scope of the LAYOUTCOMMIT operation.
      If the metadata server's
      consistency checks on loca_layoutupdate fail, the metadata server
      rejects the LAYOUTCOMMIT operation and makes no changes to the
      file system.  However, any time LAYOUTCOMMIT with loca_reclaim
      TRUE fails, the pNFS client may have lost all uncommitted
	data within the scope of the failed LAYOUTCOMMIT operation.  

Notes:

Errata 2 of 5 to deprecate loca_offset and loca_length arguments to LAYOUTCOMMIT.

Errata ID: 3066
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: David Black
Date Reported: 2011-12-27
Held for Document Update by: Martin Stiemerling

Section 12.7.4 says:

   o  The client does not have a copy of the data in its memory and the
      metadata server is no longer in its grace period; i.e., the
      metadata server returns NFS4ERR_NO_GRACE.  As with the scenario in
      the above bullet point, the failure of LAYOUTCOMMIT means the data
      in the range <loca_offset, loca_length> lost.  The defense against
      the risk is the same -- cache all written data on the client until
      a successful LAYOUTCOMMIT.

It should say:

   o  The client does not have a copy of the data in its memory and the
      metadata server is no longer in its grace period; i.e., the
      metadata server returns NFS4ERR_NO_GRACE.  As with the scenario in
      the above bullet point, the failure of LAYOUTCOMMIT means the data
      in the scope of that LAYOUTCOMMIT may have been lost.  The defense
      against the risk is the same -- cache all written data on the client
      until a successful LAYOUTCOMMIT.

Notes:

Errata 3 of 5 to deprecate loca_offset and loca_length arguments to LAYOUTCOMMIT.

Errata ID: 3067
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: David Black
Date Reported: 2011-12-27
Held for Document Update by: Martin Stiemerling

Section 18.42.3 says:

   The LAYOUTCOMMIT operation commits changes in the layout represented
   by the current filehandle, client ID (derived from the session ID in
   the preceding SEQUENCE operation), byte-range, and stateid.  Since
   layouts are sub-dividable, a smaller portion of a layout, retrieved
   via LAYOUTGET, can be committed.  The byte-range being committed is
   specified through the byte-range (loca_offset and loca_length).  This
   byte-range MUST overlap with one or more existing layouts previously
   granted via LAYOUTGET (Section 18.43), each with an iomode of
   LAYOUTIOMODE4_RW.  In the case where the iomode of any held layout
   segment is not LAYOUTIOMODE4_RW, the server should return the error
   NFS4ERR_BAD_IOMODE.  For the case where the client does not hold
   matching layout segment(s) for the defined byte-range, the server
   should return the error NFS4ERR_BAD_LAYOUT.

It should say:

   The LAYOUTCOMMIT operation commits changes in the layout represented
   by the current filehandle, client ID (derived from the session ID in
   the preceding SEQUENCE operation), and stateid.  As a layout-independent
   operation, LAYOUTCOMMIT commits the entire layout; layout type-specific
   data (loca_layoutupdate) may specify a smaller scope of data that is to
   be committed (e.g., for the block layout, see RFC 5663 [41]).

   The loca_offset and loca_length arguments have been deprecated.  The
   client SHOULD set both loca_offset and loca_length to 0.
   The server MUST ignore the loca_offset and loca_length arguments.
   The client MUST hold one or more existing layouts
   previously granted via LAYOUTGET (Section 18.43), with an iomode of
   LAYOUTIOMODE4_RW.  If layout type-specific data (loca_layoutupdate)
   restricts the scope of the LAYOUTCOMMIT to less than the entire layout,
   the client MUST hold one or more existing layouts with an iomode
   of LAYOUTIOMODE4_RW fully covering the committed byte ranges.
   In the case where no previously granted layout
   has an iomode of LAYOUTIOMODE4_RW, the server should return the error
   NFS4ERR_BAD_IOMODE.  For the case where the client does not hold
   any previously granted layout, the server should return the error
   NFS4ERR_BAD_LAYOUT.

Notes:

Errata 4 of 5 to deprecate loca_offset and loca_length arguments to LAYOUTCOMMIT.

Errata ID: 3068
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: David Black
Date Reported: 2011-12-27
Held for Document Update by: Martin Stiemerling

Section 18.42.3 says:

   The loca_last_write_offset field specifies the offset of the last
   byte written by the client previous to the LAYOUTCOMMIT.  Note that
   this value is never equal to the file's size (at most it is one byte
   less than the file's size) and MUST be less than or equal to
   NFS4_MAXFILEOFF.  Also, loca_last_write_offset MUST overlap the range
   described by loca_offset and loca_length. 

It should say:

   The loca_last_write_offset field specifies the offset of the last
   byte written by the client previous to the LAYOUTCOMMIT.  Note that
   this value is never equal to the file's size (at most it is one byte
   less than the file's size) and MUST be less than or equal to
   NFS4_MAXFILEOFF.

Notes:

Errata 5 of 5 to deprecate loca_offset and loca_length arguments to LAYOUTCOMMIT.

Errata ID: 3714
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Yuri Radchenko
Date Reported: 2013-08-31
Held for Document Update by: Magnus Westerlund
Date Held: 2019-10-25

Section 13.4.4. says:

The flag NFL4_UFLG_DENSE of the nfl_util4 data type (field nflh_util
of the data type nfsv4_1_file_layouthint4 and field nfl_util of data
type nfsv4_1_file_layout_ds_addr4)

It should say:

The flag NFL4_UFLG_DENSE of the nfl_util4 data type (field nflh_util
of the data type nfsv4_1_file_layouthint4 and field nfl_util of data
type  nfsv4_1_file_layout4)

Notes:

nfsv4_1_file_layout_ds_addr4 data type does not have field nflh_util

Errata ID: 3901
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Trond Myklebust
Date Reported: 2014-02-25
Held for Document Update by: Magnus Westerlund
Date Held: 2019-10-25

Section 18.43.3 says:

The logr_return_on_close result field is a directive to return the
layout before closing the file.  When the metadata server sets this
return value to TRUE, it MUST be prepared to recall the layout in the
case in which the client fails to return the layout before close.
For the metadata server that knows a layout must be returned before a
close of the file, this return value can be used to communicate the
desired behavior to the client and thus remove one extra step from
the client's and metadata server's interaction.

It should say:

The logr_return_on_close result field is a directive to return
or forget the layout when the client returns all open/delegation
state for that file.

Once a LAYOUTGET operation returns with logr_return_on_close
set to TRUE for a given file, then all subsequent LAYOUTGET
requests by that client for the same file and layout type, MUST
reply with logr_return_on_close set to TRUE until the client returns
all its open state for that file using CLOSE and DELEGRETURN.
Note that return_on_close also applies retroactively to all layout
segments retrieved by the client for that file and layout type.

After the client has closed all open stateids and returned the
delegation stateids for a file for which logr_return_on_close
was set to TRUE, the server MUST  invalidate all layout segments
that were  issued to the client for that file. The client MUST NOT
attempt to use that layout or the layout stateid.

If the server needs to revoke all open stateids and delegation
stateids owned by the client for a file for which logr_return_on_close
was set to TRUE, then it MUST also revoke all layout segments of 
type loga_layout_type that were issued for that file to that client, 
and take action to fence the access to the DSes.

Notes:

This is intended as a replacement for the errata with id 3226, which is incomplete in that it does not discuss how return-on-close is supposed to work with delegations or with layout revoking.
--VERIFIER NOTES--
Please get an agreement in the WG and submit an up to date errata, as this text part seems to be under discussion.

2016-06-17: RFC Editor moved from Rejected to Reported per request from AD (Spencer Dawkins).

2019-10-25: TSV AD Magnus Westerlund put this into the Held for document update so that the WG can deal with the consensus deision issues related to this clarification when updating the document.

Errata ID: 4118
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Christoph Hellwig
Date Reported: 2014-09-17
Held for Document Update by: Martin Stiemerling
Date Held: 2016-02-02

Section 20.12.3 says:

NOTIFY_DEVICEID4_CHANGE
  A previously provided device-ID-to-device-address mapping has
  changed and the client uses GETDEVICEINFO to obtain the updated
  mapping.  The notification is encoded in a value of data type
  notify_deviceid_change4.  This data type also contains a boolean
  field, ndc_immediate, which if TRUE indicates that the change will
  be enforced immediately, and so the client might not be able to
  complete any pending I/O to the device ID.  If ndc_immediate is
  FALSE, then for an indefinite time, the client can complete
  pending I/O.  After pending I/O is complete, the client SHOULD get
  the new device-ID-to-device-address mappings before sending new
  I/O requests to the storage devices addressed by the device ID.

It should say:

NOTIFY_DEVICEID4_CHANGE
  A previously provided device-ID-to-device-address mapping has
  changed and the client uses GETDEVICEINFO to obtain the updated
  mapping.  The notification is encoded in a value of data type
  notify_deviceid_change4.  This data type also contains a boolean
  field, ndc_immediate, which SHOULD be ignored by the client.
  The client may finish any outstanding I/Os that reference the
  previously provided device-ID-to-device-address mapping and SHOULD
  use GETDEVICEINFO to obtain the updated mapping for the previously
  provided device-ID-to-device-address mapping before requesting new
  layouts.  All outstanding layouts remain valid after a notification
  of type NOTIFY_DEVICEID4_CHANGE.  If the device-ID-to-device-address
  mapping changed in an incompatible way that would invalidate
  outstanding layouts, the server MUST recall all outstanding layouts
  and send a NOTIFY_DEVICEID4_DELETE notification instead.

Notes:

Clarify what DEVICEID4_CHANGE means vs layouts instead of I/Os. Drop the under specified ndc_immediate flag, which can't be enforced.

Errata ID: 4119
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Christoph Hellwig
Date Reported: 2014-09-17
Held for Document Update by: Magnus Westerlund
Date Held: 2019-10-25

Section 12.2.10 says:

A device ID lives as long as there is a layout referring to the
device ID.  If there are no layouts referring to the device ID, the
server is free to delete the device ID any time.

It should say:

A device ID is established by referencing it in the result of a
GETDEVICELIST or LAYOUTGET operation and can be deleted by the server
as soon as there are no layouts referring to the device ID.

If the client requested notifications for device ID mappings, the
server SHOULD send CB_NOTIFY_DEVICEID notifications for device ID
deletions or changes to the device-ID-to-device-address mappings to any
client which has used the device-ID in question at least once,
irrespective of whether the client has any layouts currently referring
to it. If the server does not support or the client does not request
notifications for device ID mappings, the client SHOULD periodically
retired unused device IDs.


Given that GETDEVICELIST does not support requesting notifications a
server that implements GETDEVICELIST MUST not not advertise support
for NOTIFY_DEVICEID4_CHANGE notification in GETDEVICEINFO, and client
using GETDEVICELIST must not rely on NOTIFY_DEVICEID4_CHANGE or
NOTIFY_DEVICEID4_DELETE notifications to work reliably.

Notes:

The lifetime rules in RFC5661 are contradictory - both GETDEVICELIST and CB_NOTIFY_DEVICEID (NOTIFY4_DEVICEID_DELETE) operations imply that device IDs are valid even without layouts referring to them. Implementations rely on this fact by caching not referenced device IDs to avoid the huge setup costs, and thus require notifications to be sent for that case.

Errata ID: 4492
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: David Noveck
Date Reported: 2015-10-05
Held for Document Update by: Magnus Westerlund
Date Held: 2019-10-25

Section 18.17.4 says:

If the server does not support named attributes for the current 
filehandle, an error of NFS4ERR_NOTSUPP will be returned to the 
client.

It should say:

If the server does not support named attributes for file system 
objects on the file system associated with the current filehandle, 
an error of NFS4ERR_NOTSUPP will be returned to the client.

Notes:

There are a number of situations in which, a server might not support named attributes on particular file system objects. A number of cases concern doing an OPENATTR on a named attribute directory or named attribute and are mentioned in the immediately preceeding section.
Aside from that contradiction, many implementations might allow named attributes on
symbolic likes or special files. The existing text would require NFS4ERR_NOTSUPP rather
than NFS4ERR_WRONG_TYPE to be returned in such cases, causing the client to conclude
incorrectly that named attribute support is not present for the file system in question, or at
least be uncertain about the presence/absence of such support.

Errata ID: 4712
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Trond Myklebust
Date Reported: 2016-06-16
Held for Document Update by: Magnus Westerlund
Date Held: 2020-09-03

Section 6.2.1.3.1. says:

   ACE4_DELETE

      Operation(s) affected:

         REMOVE

It should say:

   ACE4_DELETE

      Operation(s) affected:

         REMOVE

         RENAME

Notes:

ACE4_DELETE on the source file may allow a rename to proceed in cases where the user does not have ACE4_DELETE_CHILD on the source directory. It may also affect the ability of the user to be able to RENAME if there is an existing file in the target directory with the target name.

AD notes based on Chuck Lever's input.
o The text in RFC 5661 Section 6.2.1.3.1 matches the text in RFC 7530 Section 6.2.1.3.1. Are updaed of RFC 7530 also needed for this reason?
o Should the Notes section of the errata be added to Section 6.2.1.3.2?
o A consideration is if there are already server implementations that reject RENAME operations in these cases, or do all server implementations permit RENAME?
o This is held so that the issues can be addressed in rfc5661bis after further discussion.
o Additional Editorial correction: The Discussion subsections of ACE4_DELETE and ACE4_DELETE are missing the word "how".

Errata ID: 5212
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: NFS4ERR_ROFS is not a valid error code for LAYOUTGET
Date Reported: 2017-12-19
Held for Document Update by: Magnus Westerlund
Date Held: 2020-09-04

Section 15.2 says:

   | LAYOUTGET            | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED,     |
   |                      | NFS4ERR_BADIOMODE, NFS4ERR_BADLAYOUT,      |
   |                      | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID,       |
   |                      | NFS4ERR_DEADSESSION, NFS4ERR_DELAY,        |
   |                      | NFS4ERR_DELEG_REVOKED, NFS4ERR_DQUOT,      |
   |                      | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE,          |
   |                      | NFS4ERR_INVAL, NFS4ERR_IO,                 |
   |                      | NFS4ERR_LAYOUTTRYLATER,                    |
   |                      | NFS4ERR_LAYOUTUNAVAILABLE, NFS4ERR_LOCKED, |
   |                      | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE,       |
   |                      | NFS4ERR_NOSPC, NFS4ERR_NOTSUPP,            |
   |                      | NFS4ERR_OLD_STATEID, NFS4ERR_OPENMODE,     |
   |                      | NFS4ERR_OP_NOT_IN_SESSION,                 |
   |                      | NFS4ERR_RECALLCONFLICT,                    |
   |                      | NFS4ERR_REP_TOO_BIG,                       |
   |                      | NFS4ERR_REP_TOO_BIG_TO_CACHE,              |
   |                      | NFS4ERR_REQ_TOO_BIG,                       |
   |                      | NFS4ERR_RETRY_UNCACHED_REP,                |
   |                      | NFS4ERR_SERVERFAULT, NFS4ERR_STALE,        |
   |                      | NFS4ERR_TOOSMALL, NFS4ERR_TOO_MANY_OPS,    |
   |                      | NFS4ERR_UNKNOWN_LAYOUTTYPE,                |
   |                      | NFS4ERR_WRONG_TYPE                         |

It should say:

   | LAYOUTGET            | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED,     |
   |                      | NFS4ERR_BADIOMODE, NFS4ERR_BADLAYOUT,      |
   |                      | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID,       |
   |                      | NFS4ERR_DEADSESSION, NFS4ERR_DELAY,        |
   |                      | NFS4ERR_DELEG_REVOKED, NFS4ERR_DQUOT,      |
   |                      | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE,          |
   |                      | NFS4ERR_INVAL, NFS4ERR_IO,                 |
   |                      | NFS4ERR_LAYOUTTRYLATER,                    |
   |                      | NFS4ERR_LAYOUTUNAVAILABLE, NFS4ERR_LOCKED, |
   |                      | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE,       |
   |                      | NFS4ERR_NOSPC, NFS4ERR_NOTSUPP,            |
   |                      | NFS4ERR_OLD_STATEID, NFS4ERR_OPENMODE,     |
   |                      | NFS4ERR_OP_NOT_IN_SESSION,                 |
   |                      | NFS4ERR_RECALLCONFLICT,                    |
   |                      | NFS4ERR_REP_TOO_BIG,                       |
   |                      | NFS4ERR_REP_TOO_BIG_TO_CACHE,              |
   |                      | NFS4ERR_REQ_TOO_BIG,                       |
   |                      | NFS4ERR_RETRY_UNCACHED_REP, NFS4ERR_ROFS,  |
   |                      | NFS4ERR_SERVERFAULT, NFS4ERR_STALE,        |
   |                      | NFS4ERR_TOOSMALL, NFS4ERR_TOO_MANY_OPS,    |
   |                      | NFS4ERR_UNKNOWN_LAYOUTTYPE,                |
   |                      | NFS4ERR_WRONG_TYPE                         |

Notes:

It could be argued that the OPEN takes care of a NFS4ERR_ROFS for a LAYOUTGET of a LAYOUTIOMODE4_RW, but that does not explain why WRITE is allowed to return a NFS4ERR_ROFS.

With the Flex File Layout Type, the storage device depends on the metadata server enforcing the read-only filesystem semantics. An NFSv3 WRITE to the storage device might be accepted even though the filesystem might be RO. Further, if a snapshot is taken, the storage device might not be aware of the fact that a data file is in a snapshot.

Currently, if the underlying filesystem determines that the LAYOUTGET for a LAYOUTIOMODE4_RW is going to return NFS4ERR_ROFS, to be spec compliant, it MUST convert the error code to NFS4ERR_SERVERFAULT. The client may then decide to perform IO through the metadata server with NFSv4 WRITE calls, which will in turn get a NFS4ERR_ROFS error. This change pushes the responsibility to be on the LAYOUTGET and allows the client to inform the application of an error earlier.

AD Comments:
This topic requires WG discussion and establishment of consensus. Thus for future document update.

--VERIFIER NOTES--
This topic requires WG discussion and establishment of consensus. Thus for future document update.

Errata ID: 3064
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: David Black
Date Reported: 2011-12-27
Held for Document Update by: Martin Stiemerling

Section 12.5.4 says:

   The LAYOUTCOMMIT operation is responsible for committing a modified
   layout to the metadata server.  The data should be written and
   committed to the appropriate storage devices before the LAYOUTCOMMIT
   occurs.  The scope of the LAYOUTCOMMIT operation depends on the
   storage protocol in use.

It should say:

   The LAYOUTCOMMIT operation is responsible for committing a modified
   layout to the metadata server.  The data should be written and
   committed to the appropriate storage devices before the LAYOUTCOMMIT
   occurs.  The scope of data committed by a LAYOUTCOMMIT operation is
   specific to the type of layout because that scope depends on the
   storage protocol in use.

Notes:

Errata 1 of 5 to deprecate loca_offset and loca_length arguments to LAYOUTCOMMIT.

Errata ID: 3653
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kanda Motohiro
Date Reported: 2013-06-15
Held for Document Update by: Martin Stiemerling
Date Held: 2016-02-02

Section 13.4.2 says:

The destinations of the first 13 storage units are:

It should say:

The destinations of the first 13 stripe units are:

Notes:

Same errata on Section 13.4.3

Errata ID: 4572
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sai Chakravarthy Tangudu
Date Reported: 2015-12-30
Held for Document Update by: Magnus Westerlund
Date Held: 2019-10-25

Section 18.35.3 says:

A server MUST NOT use the same client ID for two different
incarnations of an eir_clientowner.

It should say:

A server MUST NOT use the same client ID for two different
incarnations of an eia_clientowner.

Errata ID: 4914
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dylan Simon
Date Reported: 2017-01-22
Held for Document Update by: Magnus Westerlund
Date Held: 2019-10-25

Section 14.3.3 says:

Mapping Used by nfs4_cis_prep

It should say:

Mapping Used by nfs4_mixed_prep

Notes:

Section header is incorrect, possibly copied from previous section 14.2.3

Errata ID: 5476
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tigran Mkrtchyan
Date Reported: 2018-08-23
Held for Document Update by: Magnus Westerlund
Date Held: 2019-10-25

Section 18.42.3 says:

   matching layout segment(s) for the defined byte-range, the server
   should return the error NFS4ERR_BAD_LAYOUT.

It should say:

   matching layout segment(s) for the defined byte-range, the server
   should return the error NFS4ERR_BADLAYOUT.

Notes:

The error code is NFS4ERR_BADLAYOUT.

RFC 5663, "Parallel NFS (pNFS) Block/Volume Layout", January 2010

Note: This RFC has been updated by RFC 6688

Source of RFC: nfsv4 (wit)

Errata ID: 4141
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Christoph Hellwig
Date Reported: 2014-10-23
Held for Document Update by: Martin Stiemerling
Date Held: 2016-02-02

Section 2.2.2 says:

It should say:

   The volume size of a PNFS_BLOCK_VOLUME_SIMPLE volume must be obtained
   by the client from the storage subsystem as no size is provided in
   the XDR. All volumes listed in bsv_volumes of a
   struct pnfs_block_stripe_volume_info4 must be the same size.  If
   the size of the volumes listed in a stripe set does not align
   to the bsv_stripe_unit, the last stripe should be treated as
   having a size of volume size modulo the stripe size.
   The volume size of a PNFS_BLOCK_VOLUME_SLICE volume is the sum
   of the volume sizes of each component listed in bsv_volumes.
   The volume size of a PNFS_BLOCK_VOLUME_CONCAT volume is the sum
   of the volume sizes of each component listed in bcv_volumes.

Notes:

RFC5663 provides no explanation of the volume types except for a few sparse comments in the XDR. Explain at least basic size related rules.

Errata ID: 4142
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Christoph Hellwig
Date Reported: 2014-10-23
Held for Document Update by: Martin Stiemerling
Date Held: 2016-02-02

Section 2.8 says:

<section does not exist yet>

It should say:

2.8.  Device-ID-to-device-address

   A pNFS block volume layout server MAY signal
   device-ID-to-device-address changes to the client using the
   CB_NOTIFY_DEVICEID callback operation.

   If the change is compatible and does not require outstanding layouts
   to be recalled the server can issue a notification of type
   NOTIFY_DEVICEID4_CHANGE.

   A device-ID-to-device-address mapping change signaled by
   NOTIFY_DEVICEID4_CHANGE must not change the storage system specific
   addressing of the volume, and can only add new storage to the
   existing device.  In particular the following changes are allowed:

     o increasing the size of the underlying block device of a
       PNFS_BLOCK_VOLUME_SIMPLE volume.
     o increasing the size of a PNFS_BLOCK_VOLUME_SLICE volume if the
       underlying block device of the PNFS_BLOCK_VOLUME_SIMPLE volume
       it refers to is big enough to fit the new size.
     o increasing the size of each volume in a bsv_volumes of a
       PNFS_BLOCK_VOLUME_SLICE volume by the same amount.
     o increasing the size of the last volume in bcv_volumes of a
       PNFS_BLOCK_VOLUME_CONCAT volume.
     o adding new members to the end of bcv_volumes of a
       PNFS_BLOCK_VOLUME_CONCAT volume.

Notes:

Specify what device configuration changes can be supported without recalling layouts.

RFC 5665, "IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats", January 2010

Source of RFC: nfsv4 (wit)

Errata ID: 2015
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-01-26
Held for Document Update by: Wes Eddy

Section 5.1, pg.6 says:

[[ Item 4., last paragraph ]]

       For assignments made on a Standards Action basis, the point of
|      contact is always determined by IESG.
                                      ^

It should say:

       For assignments made on a Standards Action basis, the point of
|      contact is always determined by the IESG.

Notes:

Rationale: missing article; consistency of style.

RFC 5670, "Metering and Marking Behaviour of PCN-Nodes", November 2009

Source of RFC: pcn (tsv)

Errata ID: 1968
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-21
Held for Document Update by: Lars Eggert

Section A.2 says:

   A token bucket with the following parameters:

      *  PCN-excess-rate: token rate of token bucket (bits/second)

|     *  BS_etm: depth of TB in token bucket (bits)

      *  lastUpdate: time the token bucket was last updated (seconds)

      *  F_etm: amount of tokens in token bucket (bits)

It should say:

   A token bucket with the following parameters:

      *  PCN-excess-rate: token rate of token bucket (bits/second)

|     *  BS_etm: depth of token bucket (bits)

      *  lastUpdate: time the token bucket was last updated (seconds)

      *  F_etm: amount of tokens in token bucket (bits)

Notes:

Rationale: "TB" does not appear anywhere else in the document.
The RFC text looks like a shift in terminology has not been
performed consistently. Dropping "TB in" seems appropriate
and consistent in style with the surrounding text.

RFC 5676, "Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications", October 2009

Source of RFC: opsawg (ops)

Errata ID: 1928
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-10-23
Held for Document Update by: Dan Romascanu

Section 7, pg. 7 says:

 SyslogTimeStamp ::= TEXTUAL-CONVENTION
!    DISPLAY-HINT "2d-1d-1d,1d:1d:1d.3d,1a1d:1d"
     STATUS       current
     DESCRIPTION
        "A date-time specification.  This type is similar to the
         DateAndTime type defined in the SNMPv2-TC, except the
         subsecond granulation is microseconds instead of
         deciseconds and a zero-length string can be used
         to indicate a missing value.

         field  octets  contents                  range
         -----  ------  --------                  -----
|          1      1-2   year*                     0..65536
           2       3    month                     1..12
           3       4    day                       1..31
           4       5    hour                      0..23
           5       6    minutes                   0..59
           6       7    seconds                   0..60
                        (use 60 for leap-second)
!          7     8-10   microseconds*             0..999999
           8      11    direction from UTC        '+' / '-'
           9      12    hours from UTC*           0..13
          10      13    minutes from UTC          0..59

         * Notes:
         - the value of year is in network-byte order
|        - the value of microseconds is in network-byte order
         - daylight saving time in New Zealand is +13

         For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be
         displayed as:

                         1992-5-26,13:30:15.0,-4:0

         Note that if only local time is known, then timezone
         information (fields 11-13) is not present."
     SYNTAX      OCTET STRING (SIZE (0 | 10 | 13))

It should say:

(a)  upper part of the table:

         field  octets  contents                  range
         -----  ------  --------                  -----
|          1      1-2   year*                     0..32767
           ...

(b)  "*Notes:" part:

<< see Notes below -- one possibility to address the issue is
   amending the text as follows; verifiers might do better >> 

         * Notes:
         - the value of year is in network-byte order
|        - the value of microseconds is in network-byte order;
|          users of network management applications following
|          the DISPLAY-HINT specified above should be aware of
|          the unusual appearance of the apparent 'fractional part'
|          displayed: RFC 2579 requires the leading zeros to be
|          omitted; thus a time component diaplayed as '13:30:15.50'
|          does not indicate 50 centiseconds, but 50 microseconds
|          past the full second!
         - daylight saving time in New Zealand is +13

Notes:

(a)

Section 3.1 of RFC 2579 (on page 21) states, regarding numerical
conversion descriptor components in DISPLAY-HINTS:

[...] For all types, when rendering a value, leading
zeros are omitted, and for negative values, a minus sign is rendered
immediately before the digits. [...]

Arguably, this means that substrings of OCTET STRING type are
interpreted as *signed* values (in network byte order).
Therefore, the range restriction for the 'year' part specified
informally in the DESCRIPTION clause does not make proper sense;
an upper bound of 65536 is nonsensical anyway since a 2-octet
substring cannot assme 65537 different values; to avoid issues
with different interpretation of RFC 2579, the 'safe' range
0..32767 is recommended -- this should not be a serious restriction
in practice.

(b)

WARNING:

According to Section 3.1 of RFC 2579, the components of the
DISPLAY-HINTS string describe the *independent* formatting of
substrings of the OCTET STRING (in this case).
Thus, the display instructions for the conceptional 'seconds'
part of the OCTET STRING, "1d.3d", actually describes the
independent formatting of a 1-octet and a 3-octet substring
(in network byte order) as decimal integers without leading
zeros, separated by a literal period ('.') -- a "display
separator character" in RFC 2579 terms --, and not the
human-friendly formatting of a single fixed-point fractional
number; there is no concept of a decimal fraction representation
in this notation.
So the presentation format will be very different from common
practice for human beings. See the example below.
The "fixed-point with decimal sign" representation from
RFC 2579 is only available for INTEGER values, for cases with
scaled values, where the conceptual integer and fractional part
are stored as a single integer in units of the specified
fractional part; it is not applicable to display formats for
OCTET STRING objects.

Elaborating on a slight variant of the example from the RFC, ...
Tuesday May 26, 1992 at 1:30:15.008 PM EDT
(8 milliseconds past the full 15 seconds), the 'seconds' part
would be represented as 15 seconds 8000 microseconds in four
octets containing 0x0F, 0x00, 0x1F, 0x40, which, together with
the other components, would be rendered as:
1992-5-26,13:30:15.8000,-4:0

RFC 5677, "IEEE 802.21 Mobility Services Framework Design (MSFD)", December 2009

Source of RFC: mipshop (int)

Errata ID: 1962
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-21
Held for Document Update by: Brian Haberman

Section 11.2 says:

   [IEEE80221] "IEEE Standard for Local and Metropolitan Area Networks -
               Part 21: Media Independent Handover Services", IEEE
               LAN/MAN Std 802.21-2008, January 2009,
|              http://www.ieee802.org/21/private/Published%20Spec/
|              802.21-2008.pdf (access to the document requires
|              membership).

It should say:

   [IEEE80221] "IEEE Standard for Local and Metropolitan Area Networks -
               Part 21: Media Independent Handover Services", IEEE
               LAN/MAN Std 802.21-2008, January 2009,
|              http://standards.ieee.org/getieee802/802.21.html.

Notes:

Rationale: By the time of publication of the RFC, the 6-month
IEEE 802 grace period had passed for more than 5 months, and
the specification is now available freely as usual.

Errata ID: 1963
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-21
Held for Document Update by: Brian Haberman

Section 5.3,1st para says:

|  To discover a Mobility Server in a remote network other than home
   network, the MN MUST use the DNS-based MoS discovery method described
   in [RFC5679].  [...]

It should say:

|  To discover a Mobility Server in a remote network other than the home
   network, the MN MUST use the DNS-based MoS discovery method described
   in [RFC5679].  [...]

Notes:

Rationale: Missing article.

Other editorial flaw (keep for update!):
The text of Section 2.1 (page 7) is indented too much;
should be same indentation as for the body of Section 3.

Errata ID: 1965
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-21
Held for Document Update by: Brian Haberman

Section 6.3,2nd para says:

                             [...]  The default maximum number of
   retransmissions is set to 2 and the initial retransmission timer
|  (TMO) is set to 3s when RTT is not known.  The maximum TMO is set to
   30s.

It should say:

                             [...]  The default maximum number of
   retransmissions is set to 2 and the initial retransmission timer
|  (TMO) is set to 3s when the RTT is not known.  The maximum TMO is set
   to 30s.

Notes:

Rationale:
Missing article; adjustment to use of language in preceding text.

Errata ID: 1966
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-21
Held for Document Update by: Brian Haberman

Section 8 says:

|             [...]  Since IEEE 802.21 base specification does not
   provide MIH protocol level security, it is assumed that either lower
   layer security (e.g., link layer) or overall system-specific (e.g.,
   proprietary) security solutions are available.  [...]

It should say:

|             [...]  Since the IEEE 802.21 base specification does not
   provide MIH protocol level security, it is assumed that either lower
   layer security (e.g., link layer) or overall system-specific (e.g.,
   proprietary) security solutions are available.  [...]

Notes:

Rationale: Missing article. (Keep for update!)

Errata ID: 1967
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-21
Held for Document Update by: Brian Haberman

Section 8.1 says:

a)  1st para:
  
       [...]  In such cases, the link between the DHCP client and Layer
   2 termination point may be protected, but the DHCP message source and
   its messages cannot be authenticated or the integrity of the latter
|  checked unless there exits a security binding between link layer and
   DHCP layer.

b) 2nd para:
                    v
|  In the case where DNS is used for discovering MoS, fake DNS requests
   and responses may cause denial of service (DoS) and the inability of
   the MN to perform a proper handover, respectively.  Where networks
   are exposed to such DoS, it is RECOMMENDED that DNS service providers
   use the Domain Name System Security Extensions (DNSSEC) as described
   in [RFC4033].  Readers may also refer to [RFC4641] to consider the
   aspects of DNSSEC operational practices.

It should say:

a)  1st para:
  
       [...]  In such cases, the link between the DHCP client and Layer
   2 termination point may be protected, but the DHCP message source and
   its messages cannot be authenticated or the integrity of the latter
|  checked unless there exists a security binding between link layer and
   DHCP layer.

b) 2nd para:
                    vvvvv
|  In the case where the DNS is used for discovering MoS, fake DNS
   requests and responses may cause denial of service (DoS) and the
   inability of the MN to perform a proper handover, respectively.
   Where networks are exposed to such DoS, it is RECOMMENDED that DNS
   service providers use the Domain Name System Security Extensions
   (DNSSEC) as described in [RFC4033].  Readers may also refer to
   [RFC4641] to consider the aspects of DNSSEC operational practices.

Notes:

Rationale:
a) typo
b) missing article

RFC 5681, "TCP Congestion Control", September 2009

Note: This RFC has been updated by RFC 9438

Source of RFC: tcpm (wit)

Errata ID: 2074
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Herbie Robinson
Date Reported: 2010-03-15
Held for Document Update by: Lars Eggert

Section 3.1 says:

   A detailed rationale and discussion of the IW setting is provided in
   [RFC3390].

It should say:

   A detailed rationale and discussion of the IW setting is provided in
   [RFC3390].  The IW value for the case when (SMSS > 1095 bytes) and (SMSS <= 
   2190 bytes) is changed from RFC3390.  The new definition will keep early 
   values of cwnd at a multiple of SMSS and avoid transmitting partial segments.

Notes:

Hopefully, I surmised the reason for the change correctly.

Errata ID: 4068
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Taylor
Date Reported: 2014-08-04
Held for Document Update by: Martin Stiemerling
Date Held: 2014-11-10

Throughout the document, when it says:

Notes:

The problem is the use of the phrase "new data" in an imprecise manner to sometimes mean "previously unacknowledged data" and other times mean "never before sent data".

For example, in Section 3.1

During slow start, a TCP increments cwnd by at most SMSS bytes for
each ACK received that cumulatively acknowledges new data.

This should read

During slow start, a TCP increments cwnd by at most SMSS bytes for
each ACK received that cumulatively acknowledges previously
unacknowledged data.

I believe that throughout Section 3.1 "new data" refers to "previously unacknowledged data".

However, in Section 3.2 we have

After the fast retransmit algorithm sends what appears to be the
missing segment, the "fast recovery" algorithm governs the
transmission of new data until a non-duplicate ACK arrives.

I believe that here "new data" refers to "previously unsent data".

This is clearer in the following paragraph from Section 3.2

1. On the first and second duplicate ACKs received at a sender, a
TCP SHOULD send a segment of previously unsent data per [RFC3042]
provided that the receiver's advertised window allows, the total
FlightSize would remain less than or equal to cwnd plus 2*SMSS,
and that new data is available for transmission.

Here we can see the use of "previously unsent data" followed by "new data"
which refers to the aforementioned "previously unsent data".

While the meaning of "new data" might be clear to those with extensive experience
in TCP it is imprecise and therefore may be quite confusing to those who are learning about the protocol.

RFC 5688, "A Session Initiation Protocol (SIP) Media Feature Tag for MIME Application Subtypes", January 2010

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rai

Errata ID: 1999
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-01-10
Held for Document Update by: Robert Sparks

Section 3, 1st para says:

   The 'sip.app-subtype' media feature tag is of type token with a case-
   insensitive equality relationship.  Its value can be any registered
|  or private MIME application subtype compliant to the subtype-name
   grammar defined in [RFC4288].  When included in the Contact header
   field of a REGISTER request, an agent SHOULD include all application
   subtypes that it can support as streaming formats.  An application
|  subtype is supported if the user agent would be capable of processing
   a Session Description Protocol (SDP) [RFC4566] offer [RFC3264] that
   contained that subtype as a format in the m-line of the SDP.

It should say:

   The 'sip.app-subtype' media feature tag is of type token with a case-
   insensitive equality relationship.  Its value can be any registered
|  or private 'application' media subtype compliant to the subtype-name
   grammar defined in [RFC4288].  When included in the Contact header
   field of a REGISTER request, an agent SHOULD include all application
   subtypes that it can support as streaming formats.  An application
|  subtype is supported if the user agent would be capable of accepting
   a Session Description Protocol (SDP) [RFC4566] offer [RFC3264] that
   contained that subtype as a format in the m-line of the SDP.

Notes:

Rationale:

For clarity, the whole paragraph is shown here, including both changes.

a) editorial; see GLOBAL Errata note, EID=1997.

b) technical: the ability of "processing" an SDP offer does not
mean the ability to _accept_ it. The latter reasonably seems
to be synonymous to "supporting" the feature contained therein,
but the former isn't. Therefore, s/processing/accepting/ .

Errata ID: 1997
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-01-10
Held for Document Update by: Robert Sparks

Throughout the document, when it says:

a)   document title:

     A Session Initiation Protocol (SIP) Media Feature Tag for MIME
                          Application Subtypes

b)   Abstract

   The caller preferences specification for the Session Initiation
   Protocol (SIP) allows a caller to express preferences that the call
   be routed to a User Agent (UA) with particular capabilities.
   Similarly, a specification exists to allow a UA to indicate its
   capabilities in a registration.  Amongst those capabilities are the
|  type of media streams the agent supports, described as top-level MIME
|  types.  The 'application' MIME type is used to describe a broad range
   of stream types, and it provides insufficient granularity as a
   capability.  This specification allows a UA to indicate which
   application subtypes the agent supports.

c)  Section 3, 1st para

   The 'sip.app-subtype' media feature tag is of type token with a case-
   insensitive equality relationship.  Its value can be any registered
|  or private MIME application subtype compliant to the subtype-name
   grammar defined in [RFC4288].  [...]

[[ see also subsequent errata note covering another issue as well ! ]]

d)  Section 3, 3rd para

   It is important to note that this media feature tag is only
   indicating the streaming media types that a user agent is capable of
   supporting.  It says nothing about the functionality provided by the
|  user agent itself or the MIME types that the agent can send or
   receive in SIP messages or emails.  For example, let us assume that a
   SIP user agent is capable of supporting a chess game.  The game is
   played by each user sending chess moves as binary objects over UDP
|  between a pair of user agents.  Those objects have a MIME type of
   "application/example".  [...]

e)  Section 3, 4th para

   A consequence of this is that, as new streaming media type formats
   are defined (such as game stream formats, whiteboard session formats,
   and so on), they SHOULD be defined using the SDP application stream
|  and utilize a MIME application subtype.

f)  Section 6, 4th para

   Summary of the media feature indicated by this tag:  This feature tag
|     indicates the MIME application subtypes supported by the agent for
      purposes of streaming media.

It should say:

a)
        A Session Initiation Protocol (SIP) Media Feature Tag for
                      'Application' Media Subtypes

b)

   The caller preferences specification for the Session Initiation
   Protocol (SIP) allows a caller to express preferences that the call
   be routed to a User Agent (UA) with particular capabilities.
   Similarly, a specification exists to allow a UA to indicate its
   capabilities in a registration.  Amongst those capabilities are the
|  type of media streams the agent supports, described as top-level media
|  types.  The 'application' media type is used to describe a broad range
   of stream types, and it provides insufficient granularity as a
   capability.  This specification allows a UA to indicate which
   application subtypes the agent supports.

c)

   The 'sip.app-subtype' media feature tag is of type token with a case-
   insensitive equality relationship.  Its value can be any registered
|  or private 'application' media subtype compliant to the subtype-name
   grammar defined in [RFC4288].  [...]

d)
   It is important to note that this media feature tag is only
   indicating the streaming media types that a user agent is capable of
   supporting.  It says nothing about the functionality provided by the
|  user agent itself or the media types that the agent can send or
   receive in SIP messages or emails.  For example, let us assume that a
   SIP user agent is capable of supporting a chess game.  The game is
   played by each user sending chess moves as binary objects over UDP
|  between a pair of user agents.  Those objects have a media type of
   "application/example".  [...]

e)

   A consequence of this is that, as new streaming media type formats
   are defined (such as game stream formats, whiteboard session formats,
   and so on), they SHOULD be defined using the SDP application stream
|  and utilize an 'application' media subtype.

f)

   Summary of the media feature indicated by this tag:  This feature tag
|     indicates the 'application' media subtypes supported by the agent
      for purposes of streaming media.

Notes:

Rationale:
The subject of the RFC is SIP, not e-Mail, the 3rd letter in "MIME".
Therefore, the RFC should better follow the explanations given in
RFC 4288, which places the original concepts from MIME that have
proven generally useful into a more general context and strongly
recommends talking about "media types" and "media subtypes".
That reasoning similarly holds for Media Features, which for
obvious reasons not have been denoted "MIME Features".

Errata ID: 1998
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-01-10
Held for Document Update by: Robert Sparks

Section 1, 4th para says:

   RFC 3840 defines media feature tags for each and every top-level
   media type, including 'application'.  This media type covers an
   extremely broad range of subtypes -- multiplayer games of all sorts,
   shared whiteboards and application sharing, and so on.  With audio
|  and video, where there is often a common codec supported by agents
   (i.e., a common subtype).  [...]

It should say:

   RFC 3840 defines media feature tags for each and every top-level
   media type, including 'application'.  This media type covers an
   extremely broad range of subtypes -- multiplayer games of all sorts,
   shared whiteboards and application sharing, and so on.  With audio
|  and video, there is often a common codec supported by agents (i.e.,
   a common subtype).  [...]

Notes:

Rationale: grammar; the original sentence sounds incomplete.
Therefore, strike "where".

RFC 5695, "MPLS Forwarding Benchmarking Methodology for IP Flows", November 2009

Source of RFC: bmwg (ops)

Errata ID: 1972
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-21
Held for Document Update by: Dan Romascanu

Section 5 (Table) says:

      [...]

      Port Media                       GigE (Gigabit Ethernet),
                                       POS, ATM, etc.

|     Port Speed                       1 gbps, 100 Mbps, etc.
                                         ^
      Interface Encapsulation          Ethernet, Ethernet
                                       VLAN, PPP, HDLC, etc.

      [...]

It should say:

      [...]

      Port Media                       GigE (Gigabit Ethernet),
                                       POS, ATM, etc.

|     Port Speed                       1 Gbps, 100 Mbps, etc.
                                         ^
      Interface Encapsulation          Ethernet, Ethernet
                                       VLAN, PPP, HDLC, etc.

      [...]

Notes:

Rationale:
Case matters for powers-of-ten indicating prefix characters in
SI unit designators; "G" = Giga (= 10^9); "g" is still undefined.

Errata ID: 1970
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-21
Held for Document Update by: Dan Romascanu

Section 4.1.2 says:

                                                              vv
|  It is RECOMMENDED that all of the ports (A1, DA1, DB1, and A2) on the
   DUT and test tool support a dynamic Interior Gateway Protocol (IGP)
   for routing such as IS-IS, OSPF, RIP, etc.  [...]

It should say:

                                                              vvvvvvvv
|  It is RECOMMENDED that all of the ports (A1, DA1, DB1, and B1, etc.)
   on the DUT and test tool support a dynamic Interior Gateway Protocol
   (IGP) for routing such as IS-IS, OSPF, RIP, etc.  [...]

Notes:

Rationale:
The text (on top of page 6 of the RFC) should refer to all four
columns in Figure 1 (on page 4); "A2" as the name of a second entity
in the first coulumn seems to be redundant; therefore, s/A2/B1/ ;
additionally, ", etc." suggested as an indication of the other rows.

Errata ID: 1971
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-21
Held for Document Update by: Dan Romascanu

Section 4.1.4.1 says:

(last paragraph:)

   MPLS label values used in any test case MUST be outside the reserved
|  label value (0-15) unless stated otherwise.

It should say:

   MPLS label values used in any test case MUST be outside the reserved
|  label value range (0-15) unless stated otherwise.
              ^^^^^^^

Notes:

Rationale:
"(0-15)" is not "the reserved label value".
To avoid confusion, more precise language should be used.
Inserting "range" seems to be the smallest sensical change.

RFC 5696, "Baseline Encoding and Transport of Pre-Congestion Information", November 2009

Note: This RFC has been obsoleted by RFC 6660

Source of RFC: pcn (tsv)

Errata ID: 1969
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-21
Held for Document Update by: Lars Eggert

Section A.2 says:

(see Notes)

Notes:

Keep for Update: There's an unexpected/misplaced page break
after the second bullet in Appendix A.2, on page 13.

RFC 5707, "Media Server Markup Language (MSML)", February 2010

Source of RFC: INDEPENDENT

Errata ID: 4961
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Rajmund Takács
Date Reported: 2017-03-09
Held for Document Update by: Nevil Brownlee
Date Held: 2017-07-20

Throughout the document, when it says:

Notes:

There are some inconsistencies between the examples and the published XSD.

#1: In all of the examples, <dialogid> is the child of <msml>, but the XSD only accepts it if it's the child of <result>.

For example, this is wrong:
<msml version="1.1">
<result response="200"/>
<dialogid>conn:jd87dfg4h/dialog:12345</dialogid>
</msml>

This would be the correct one, according to the XSD:
<msml version="1.1">
<result response="200">
<dialogid>conn:jd87dfg4h/dialog:12345</dialogid>
</result>
</msml>

#2: The XSD say the <event> tag must have children, but there are examples where it doesn't have. The 'minOccurs' attribute in the regarding <xs:choice> is not explicitly specified in msml-core.xsd, but the default value is '1', so there must be at least one <name> and one <value> element, in sequence.

Ref: https://www.w3schools.com/xml/el_choice.asp

For example, this is invalid:
<event name="msml.dialog.exit" id="conn:jd87dfg4h/dialog:12345" />

#3: This is also related to <event>. In the XSD, there is a regular expression specified for the contents of <value>. This regexp does not accept the colon ':' character, but the examples contain this character.

For example, this is not accepted because of the colon character:
<event name="msml.conf.asn" id="conf:example">
<name>speaker</name>
<value>conn:hd93tg5hdf</value>
</event>

-------------------
msml-core.xsd

<xs:element name="event">
<xs:complexType>
<xs:choice maxOccurs="unbounded">
<xs:sequence>
<xs:element name="name" type="msmlEventNameValue.datatype"/>
<xs:element name="value">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="[a-zA-Z0-9.]+"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:choice>
<xs:attribute name="name" type="msmlEventName.datatype" use="required"/>
<xs:attribute name="id" type="msmlEventSource.datatype" use="required"/>
</xs:complexType>
</xs:element>

RFC 5709, "OSPFv2 HMAC-SHA Cryptographic Authentication", October 2009

Note: This RFC has been updated by RFC 7474

Source of RFC: ospf (rtg)

Errata ID: 3585
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Mike Dubrovsky
Date Reported: 2013-04-09
Held for Document Update by: Stewart Bryant
Date Held: 2013-09-19

Section 3.3 says:

(1) PREPARATION OF KEY
       In this application, Ko is always L octets long.

       If the Authentication Key (K) is L octets long, then Ko is equal
       to K.  If the Authentication Key (K) is more than L octets long,
       then Ko is set to H(K).  If the Authentication Key (K) is less
       than L octets long, then Ko is set to the Authentication Key (K)
       with zeros appended to the end of the Authentication Key (K),
       such that Ko is L octets long.

It should say:

(1) PREPARATION OF KEY
       In this application, Ko is always B octets long and is computed 
       as follows:

       If the Authentication Key (K) is B octets long, then Ko is equal
       to K.  If the Authentication Key (K) is more than B octets long,
       then Ko is set to H(K) and then appended with (B-L) zeroes to 
       create a B octets long string Ko.  If the Authentication Key (K) 
       is less than B octets long, then Ko is set to the Authentication 
       Key (K) with zeros appended to the end of the Authentication Key 
       (K), such that Ko is B octets long.

Notes:

This is in accordance with RFC2104(HMAC: Keyed-Hashing for Message Authentication). Reproducing the relevant text below:

2. Definition of HMAC

The definition of HMAC requires a cryptographic hash function, which
we denote by H, and a secret key K. We assume H to be a cryptographic
hash function where data is hashed by iterating a basic compression
function on blocks of data. We denote by B the byte-length of such
blocks (B=64 for all the above mentioned examples of hash functions),
and by L the byte-length of hash outputs (L=16 for MD5, L=20 for
SHA-1). The authentication key K can be of any length up to B, the
block length of the hash function. Applications that use keys longer
than B bytes will first hash the key using H and then use the
resultant L byte string as the actual key to HMAC. In any case the
minimal recommended length for K is L bytes (as the hash output
length). See section 3 for more information on keys.


Also, according to FIPS PUB 198, section 5(HMAC SPECIFICATION) :

STEPS
STEP-BY-STEP DESCRIPTION
Step 1
If the length of K = B: set K0 = K. Go to step 4.
Step 2
If the length of K > B: hash K to obtain an L byte string,
then append (B-L) zeros to create a B-byte string K0
(i.e., K0 = H(K) || 00...00). Go to step 4.
Step 3
If the length of K < B: append zeros to the end of K to
create a B-byte string K0 (e.g., if K is 20 bytes in
length and B = 64, then K will be appended with 44 zero
bytes 0x00).
Step 4
Exclusive-Or K0 with ipad to produce a B-byte string:
K0 ¯ ipad.
Step 5
Append the stream of data 'text' to the string resulting
from step 4: (K0 ¯ ipad) || text.
Step 6
Apply H to the stream generated in step 5:
H((K0 ¯ ipad) || text).
Step 7
Exclusive-Or K0 with opad: K0 ¯ opad.
Step 8
Append the result from step 6 to step 7:
(K0 ¯ opad) || H((K0 ¯ ipad) || text).
Step 9
Apply H to the result from step 8:
H((K0 ¯ opad )|| H((K0 &#65455; ipad) || text)).
Step 10
Select the leftmost t bytes of the result of step 9 as the MAC.

Verifier's note:
This issue is being addressed by draft-ietf-ospf-rfc6506bis.

RFC 5724, "URI Scheme for Global System for Mobile Communications (GSM) Short Message Service (SMS)", January 2010

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 2784
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-04-18
Held for Document Update by: Pete Resnick

Section 2.2 says:

2.2. Formal Definition

   The URI scheme's keywords specified in the following syntax
   description are case-insensitive.  The syntax of an "sms" URI is
   formally described as follows, where the URI base syntax is taken
   from [RFC3986]:

  sms-uri        = scheme ":" sms-hier-part [ "?" sms-fields ]
  scheme         = "sms"
  sms-hier-part  = sms-recipient *( "," sms-recipient )
  sms-recipient  = telephone-subscriber ; defined in RFC 3966
  sms-fields     = sms-field *( "&" sms-field )
  sms-field      = sms-field-name "=" escaped-value
  sms-field-name = "body" / sms-field-ext ; "body" MUST only appear once
  sms-field-ext  = 1*( unreserved )
  escaped-value  = *( unreserved / pct-encoded ) ; defined in RFC 3986

It should say:

2.2. Formal Definition

   The URI scheme's keywords specified in the following syntax
   description are case-insensitive.  The syntax of an "sms" URI is
   formally described as follows, where the URI base syntax is taken
   from [RFC3986]:

  sms-uri        = scheme ":" sms-hier-part [ "?" sms-fields ]
  scheme         = "sms"
  sms-hier-part  = sms-recipient *( "," sms-recipient )
  sms-recipient  = telephone-subscriber  ; defined in RFC 3966
  sms-fields     = no-body / body-first / body-middle-last
  no-body        = sms-field *( "&" sms-field )  
                   ; <sms-fields> part without the "body" field
  body-first     = body-field *( "&" sms-field )
                   ; <sms-fields> part with the "body" field  
                   ; at the first place
  body-middle-last = sms-field *( "&" sms-field ) "&" body-field
                   *( "&" sms-field )
                   ; <sms-fields> part with the "body" field  
                   ; in the middle or at the end
  sms-field      = sms-field-name "=" escaped-value
  body-field     = "body=" escaped-value
  sms-field-name = 1*( unreserved )
  escaped-value  = *( unreserved / pct-encoded )  ; defined in RFC 3986

Notes:

The syntax I propose represents that "body" field can occur in the URI only once while the current one does not reveal this.

Errata ID: 1996
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-01-10
Held for Document Update by: Lisa Dusseault

Section 2.4 says:

a)  first bullet (near bottom of page 9):
                                                              v
|  o  Both must be either a <local-number> or a <global-number<, i.e.,
      start with a "+".

b)  last paragraph (page 10):

   Since "sms" URIs can contain multiple <telephone-subscriber>s as well
|  as <sms-fields>, in addition to adopting the rules defined for
   comparing <telephone-subscriber>s as defined by [RFC3966], two "sms"
   URIs are only equivalent if their <sms-fields> are identical, and if
   all <telephone-subscriber>s, compared pairwise as a set (i.e.,
   without taking sequence into consideration), are equivalent.

It should say:

a)
                                                              v
|  o  Both must be either a <local-number> or a <global-number>, i.e.,
      start with a "+".

b)

   Since "sms" URIs can contain multiple <telephone-subscriber>s as well
|  as <sms-field>s, in addition to adopting the rules defined for
   comparing <telephone-subscriber>s as defined by [RFC3966], two "sms"
   URIs are only equivalent if their <sms-fields> are identical, and if
   all <telephone-subscriber>s, compared pairwise as a set (i.e.,
   without taking sequence into consideration), are equivalent.

Notes:

Rationale:
a) Distorting typo.
b) Although there is a rule '<sms-fields>', the components of it
are meant here, in plural: <sms-field>s .

Errata ID: 2672
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Charles Curran
Date Reported: 2010-12-16
Held for Document Update by: Pete Resnick

Section Document says:

<
This is really pre-erratum.

RFC5724 narrows / focuses the applicability of the SMS URI to GSM.
GSM isn't (that) relevant: SMS has moved on in the last 25 years!

Some countries, eg S.Korea, do not use/have GMS, but *CDMA* instead.
>

It should say:

<n/a — RFC ¿rewrite?>

Notes:

Current SMS availability…
http://en.wikipedia.org/wiki/SMS:
1985… Since then, support for the service has expanded to include other mobile technologies such as ANSI CDMA networks and Digital AMPS, as well as satellite and landline networks.

Errata ID: 2690
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-01-21
Held for Document Update by: Pete Resnick

Throughout the document, when it says:

RFC 5724                    sms" URI Scheme                 January 2010

It should say:

RFC 5724                   "sms" URI Scheme                 January 2010

Notes:

That is a typographical error.

RFC 5725, "Post-Repair Loss RLE Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)", February 2010

Source of RFC: avt (rai)

Errata ID: 3293
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Glen Zorn
Date Reported: 2012-07-25
Held for Document Update by: Robert Sparks

Section 3 says:

   o  thinning (T): 4 bits
      The amount of thinning performed on the sequence-number space.
      Only those packets with sequence numbers 0 mod 2^T are reported by
      this block.  A value of 0 indicates that there is no thinning and
      all packets are reported.  The maximum thinning is one packet in
      every 32,768 (amounting to two packets within each 16-bit sequence
      space).

It should say:

   o  thinning (T): 4 bits
      The amount of thinning performed on the sequence-number space.
      Only those packets with sequence numbers s satisfying the relation 
      s mod 2^T = 0 are reported by this block.  A value of 0 indicates 
      that there is no thinning and all packets are reported.  The maximum
      thinning is one packet in every 32,768 (amounting to two packets 
      within each 16-bit sequence space).

Notes:

The original is cryptic at best.

RFC 5727, "Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area", March 2010

Note: This RFC has been updated by RFC 7957

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rai

Errata ID: 2091
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-03-21
Held for Document Update by: Robert Sparks

Section 7. says:

[ 4th para of section, at the bottom of page 11: ]
  
|                                   [...], at the discretion the
   Designated Expert).  Short forms of header fields MUST only be
   assigned to Standards Track header fields.

It should say:

|                                   [...], at the discretion of the
   Designated Expert).  Short forms of header fields MUST only be
   assigned to Standards Track header fields.

Notes:

Rationale: missing word "of".

Remark -- another nit (keep for update):
The trailing period is missing from the first paragraph of Section 1.

RFC 5728, "The SatLabs Group DVB-RCS MIB", March 2010

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: int

Errata ID: 2286
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Stephane Combes
Date Reported: 2010-05-21
Held for Document Update by: Brian Haberman

Section 4 says:

REVISION "200907201200Z"
DESCRIPTION
"Revision of this MIB module, following MIB doctor review
and adjustments based on the MIB authoring guidelines
from the IETF."
::= { transmission 239 }

It should say:

REVISION "201002161200Z"
DESCRIPTION 
    "Revision of the SatLabs DVB-RCS MIB module.
    This version is published as RFC 5728."
REVISION "200907201200Z"
DESCRIPTION
    "Revision of this MIB module, following MIB doctor review
    and adjustments based on the MIB authoring guidelines
    from the IETF."
::= { transmission 239 }

Notes:

DESCRIPTION clause for the LAST-UPDATED version of the MIB is missing.

RFC 5730, "Extensible Provisioning Protocol (EPP)", August 2009

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 1876
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-11
Held for Document Update by: Alexey Melnikov
Date Held: 2009-09-11

Throughout the document, when it says:

a)  Section 1, 2nd paragraph:

|  EPP content is identified by MIME media type application/epp+xml.
   Registration information for this media type is included in an
   appendix to this document.

b)  Section 6, last paragraph:

   A MIME media type registration template is included in Appendix B.

c)  Appendix B, first two items

   MIME media type name: application

   MIME subtype name: epp+xml

It should say:

a)

|  EPP content is identified by the media type application/epp+xml.
   Registration information for this media type is included in an
   appendix to this document.

b) 

   A media type registration template is included in Appendix B.

c)

   Media type name: application

   Subtype name: epp+xm

Notes:

Rationale:

As explained in Section 1 od BCP 13, RFC 4288, the concept of a
"Media Type" formalized for the first time in the MIME RFCs has gained
significance far beyond the narrow area of Internet Mail. Therefore,
the related terms should not be used in the colloquial form including
"MIME" that did not even appear in RFC 2045; in particular, the
colloquial term "MIME Type" (or "MIME Media Type") should generally
be avoided in favor of the (original and) more appropriate bare
"Media Type".

I'd expect that a Full Standard RFC follows the established
terminology of the IETF, and that it uses the revised Media Type
registration boilerplate published in RFC 4288 (December 2005),
even when it merely updates/re-parents an existing registration.

EPP has not even a standardized transport binding to Internet Email.
Hence, tying the terminology to MIME seems even more inappropriate
here.

Alexey Melnikov: I can't see anybody be confused by use of MIME type where use of "media type" would be slightly more appropriate.

RFC 5731, "Extensible Provisioning Protocol (EPP) Domain Name Mapping", August 2009

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: art

Errata ID: 4780
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Romuald Brunet
Date Reported: 2016-08-18
Held for Document Update by: Orie Steele
Date Held: 2024-04-01

Section 3.2.5 says:

   -  A <domain:registrant> element that contains the identifier for the
      human or organizational social information (contact) object to be
      associated with the domain object as the object registrant.  This
      object identifier MUST be known to the server before the contact
      object can be associated with the domain object.  An empty element
      can be used to remove registrant information.

   -  A <domain:authInfo> element that contains authorization
      information associated with the domain object.  This mapping
      includes a password-based authentication mechanism, but the schema
      allows new mechanisms to be defined in new schemas.  A <domain:
      null> element can be used within the <domain:authInfo> element to
      remove authorization information.

It should say:

   -  An OPTIONAL <domain:registrant> element that contains the
      identifier for the human or organizational social information
      (contact) object to be associated with the domain object as the
      object registrant.  This object identifier MUST be known to the
      server before the contact object can be associated with the domain
      object.  An empty element can be used to remove registrant
      information.

   -  An OPTIONAL <domain:authInfo> element that contains authorization
      information associated with the domain object.  This mapping
      includes a password-based authentication mechanism, but the schema
      allows new mechanisms to be defined in new schemas.  A <domain:
      null> element can be used within the <domain:authInfo> element to
      remove authorization information.

Notes:

The registrant and authinfo parameters are both optional according to the XML Schema specification.
But the text of the 3.2.5 is currently ambiguous (IMHO), and may lead to think both parameters are mandatory.

RFC 5734, "Extensible Provisioning Protocol (EPP) Transport over TCP", August 2009

Note: This RFC has been updated by RFC 8996

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 1875
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-11
Held for Document Update by: Alexey Melnikov

Section 1 says:

   This document describes how the Extensible Provisioning Protocol
   (EPP) is mapped onto a single client-server TCP connection.  Security
   services beyond those defined in EPP are provided by the Transport
|  Layer Security (TLS) Protocol [RFC2246].  EPP is described in
   [RFC5730].  TCP is described in [RFC0793].  This document obsoletes
   RFC 4934 [RFC4934].

It should say:

   This document describes how the Extensible Provisioning Protocol
   (EPP) is mapped onto a single client-server TCP connection.  Security
   services beyond those defined in EPP are provided by the Transport
|  Layer Security (TLS) Protocol ([RFC2246], [RFC4346], and [RFC5246]).
   EPP is described in [RFC5730].  TCP is described in [RFC0793].
   This document obsoletes RFC 4934 [RFC4934].

Notes:

Rationale:

The RFC text potentially misguides the reader to conclude that
EPP over TCP is normatively bound to the outdated and slightly
flawed version TLS v1.0 specified in [RFC2246], which in the
meantime has been superseded twice, first by TLS v1.1 ([RFC4346]),
and then by TLS v1.2 ([RFC5246]).

However, later on in the RFC, Sections 8 and 9 make it clear that
this is not the intent of the standard -- implementations MUST
use the most recent version of TLS available to the peers.
Sections 8 and 9 refer to all three versions of TLS specified
so far, and thus, for consistency, the Introduction should not
indicate otherwise. The addition of the additional references
seems sufficient to align the expectations of readers of the
Introduction with what is detailed later in the Standard.

Releated Note for Section 11:

Arguably it would have been preferable to have not only the
obsoleted RFC 2246, but also RFC 4346 and RFC 5246 listed as
*Normative* References.
BTW, the Normative Reference to RFC 2246 arguably is a downref
and hence surprising anyway in a Full Standard.

RFC 5735, "Special Use IPv4 Addresses", January 2010

Note: This RFC has been obsoleted by RFC 6890

Note: This RFC has been updated by RFC 6598

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: int

Errata ID: 2092
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-03-21
Held for Document Update by: Brian Haberman

Section 7., 2nd para says:

|  It should also be noted that some of these address spaces may be used
   legitimately outside a single administrative domain, and may appear
   on the global Internet.  [...]

It should say:

|  It should also be noted that some of these address blocks may be used
   legitimately outside a single administrative domain, and may appear
   on the global Internet.  [...]

Notes:

Rationale: Consistent use of terminology
(cf. Abstract, Sections 3 through 5, 1st para of same section).

Errata ID: 2093
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-03-21
Held for Document Update by: Brian Haberman

Section Appendix A says:

   Address blocks that were reserved for a special purpose in RFC 3330
   but are no longer reserved for any special purpose and are available
|  for allocation are no longer listed in Sections 4 or 5.  The
   following blocks have become available:

It should say:

   Address blocks that were reserved for a special purpose in RFC 3330
   but are no longer reserved for any special purpose and are available
|  for allocation are no longer listed in Sections 3 and 4.  The
   following blocks have become available:

Notes:

Rationale: Adjust internal references.

Further:
Under the above introduction, the 6th and 7th bullet are misplaced;
they do not refer to address blocks that "bave become available" and
are no longer listed, they mention _newly assigned_ address blocks.

Thus, to avoid confusion, the final part of the Appendix,

- 191.255.0.0/16 is not reserved and is subject to future allocation
by a RIR for assignment in the normal manner.

- 198.51.100.0/24 is assigned as "TEST-NET-2" for use in
documentation and example code.

- 203.0.113.0/24 is assigned as "TEST-NET-3" for use in
documentation and example code.

- 223.255.255.0/24 is not reserved and is subject to future
allocation by an RIR for assignment in the normal manner.

should better say:

- 191.255.0.0/16 is not reserved and is subject to future allocation
by a RIR for assignment in the normal manner.

- 223.255.255.0/24 is not reserved and is subject to future
allocation by an RIR for assignment in the normal manner.

Two address blocks were reserved for special purpose since RFC 3330
and have been added to Sections 3 and 4:

- 198.51.100.0/24 is assigned as "TEST-NET-2" for use in
documentation and example code.

- 203.0.113.0/24 is assigned as "TEST-NET-3" for use in
documentation and example code.

RFC 5738, "IMAP Support for UTF-8", March 2010

Note: This RFC has been obsoleted by RFC 6855

Source of RFC: eai (app)

Errata ID: 2075
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-03-17
Held for Document Update by: Alexey Melnikov

Section 4, 3rd para says:

   IMAP servers that do not advertise the "UTF8=APPEND" or "UTF8=ONLY"
|  capability SHOULD reject an APPEND command that includes any 8-bit in
|  the message headers with a "NO" response.

It should say:

   IMAP servers that do not advertise the "UTF8=APPEND" or "UTF8=ONLY"
|  capability SHOULD reject an APPEND command that includes any 8-bit
|  character in message header fields with a "NO" response.

or:

   IMAP servers that do not advertise the "UTF8=APPEND" or "UTF8=ONLY"
|  capability SHOULD reject an APPEND command that includes any 8-bit
|  character in a message header with a "NO" response.

Notes:

Rationale: improved language and precise terminology

Errata ID: 2076
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-03-17
Held for Document Update by: Alexey Melnikov

Section 8, 4th para says:

|  Up-conversion of MIME header encoding of the following headers MUST
   also be implemented: Subject, Date ([RFC5322] comments only),
   Comments, Keywords, and Content-Description.

It should say:

|  Up-conversion of MIME header encoding of the following header fields
   MUST also be implemented: Subject, Date ([RFC5322] comments only),
   Comments, Keywords, and Content-Description.

Notes:

Rationale: precise use of IETF standard terminology.

Note: Further nits in this RFC (keep for update):

- Section 5, last line

... Section 2.3 of SASLprep RFC 4013 [RFC4013].

should better say:

... Section 2.3 of SASLprep (RFC 4013 [RFC4013]).

- Section 10 (2 instances):

This adds ...

should better say:

This RFC adds ...

- Section 12.1 -- unexpected line break in Ref. [RFC2231] :

[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
Word Extensions:
Character Sets, Languages, and Continuations", RFC 2231,
November 1997.

should say:

[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
Word Extensions: Character Sets, Languages, and
Continuations", RFC 2231, November 1997.

RFC 5739, "IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2)", February 2010

Source of RFC: ipsecme (sec)

Errata ID: 2089
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-03-21
Held for Document Update by: Sean Turner
Date Held: 2010-03-21

Section 4.5,2nd para says:

   All other attributes except INTERNAL_IP6_ADDRESS (and
|  INTENAL_ADDRESS_EXPIRY) from [IKEv2] remain valid, including the
   somewhat confusingly named INTERNAL_IP6_SUBNET (see Section 6.3 of
   [RFC4718] for discussion).

It should say:

   All other attributes except INTERNAL_IP6_ADDRESS (and
|  INTERNAL_ADDRESS_EXPIRY) from [IKEv2] remain valid, including the
   somewhat confusingly named INTERNAL_IP6_SUBNET (see Section 6.3 of
   [RFC4718] for discussion).

Notes:

Rationale: Technically significant spelling error.

Errata ID: 2090
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-03-21
Held for Document Update by: Sean Turner

Section 4.3,1st para says:

             [...].  However, if the same peers are also using IPsec/
   IKEv2 for other uses (with addresses not assigned inside IKEv2), they
   would also have SPD entries and PAD Child SA Authorization Data that
|  is not related to the virtual link.

It should say:

             [...].  However, if the same peers are also using IPsec/
   IKEv2 for other uses (with addresses not assigned inside IKEv2), they
   would also have SPD entries and PAD Child SA Authorization Data that
|  are not related to the virtual link.

Notes:

Rationale: Grammar: "SPD entries and ... Data ... are ..."

RFC 5741, "RFC Streams, Headers, and Boilerplates", December 2009

Note: This RFC has been obsoleted by RFC 7841

Source of RFC: IAB

Errata ID: 3331
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: RJ Atkinson
Date Reported: 2012-08-30
Held for Document Update by: IAB-Chair

Section 3.2.2 says:

In one place:

   "Suggested initial text, for current streams, is provided below."

In another place:

   "The text that follows is stream dependent -- these are suggested
   initial values and may be updated by stream definition document
   updates."

It should say:

In the first instance:
   "Initial mandatory text, for current streams, is provided below."

In the second instance:
   "The text that follows is stream dependent -- these are the initial
   mandatory text values.  These stream-dependent mandatory text values 
   MAY be updated by stream definition document updates.  This text 
   MUST NOT be revised or expanded on a document-by-document basis."

Notes:

Although parts of RFC-5741 use RFC-2119 language ("must", "should", "may") in a very clear way, Section 3.2.2 uses ambiguous phrasing ("suggested") and recently has been interpreted in different ways by different people (all of whom are experienced IETF/IRTF/RFC-Editor people).

Leslie Daigle sent a note to the relevant folks that clarified the intent of this sub-section of this RFC. Her note read, in part:
%
% The expectation, when writing RFC5741, was that the boilerplate was fixed.
% The "suggested text" connotations in the document were meant to indicate
% that the boilerplate might be updated in the stream definition itself,
% not on a document-by-document basis.

The primary confusing/problematic sentences from RFC-5741 are copied and pasted separately into "Original Text" in this errata submission. Candidate edited sentences, intended to be consistent with Leslie's clarification of the authors' intended meaning, are provided in "Corrected Text", but some other editorial correction might well be better/clearer.

The primary goal of this erratum is to help ensure that any future revisions of RFC-5741, and also any future revisions of the closely related stream-dependent publication documents, are more clear about the fixed nature of "Status of this Memo" text.

RFC 5749, "Distribution of EAP-Based Keys for Handover and Re-Authentication", March 2010

Source of RFC: hokey (sec)

Errata ID: 2087
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-03-21
Held for Document Update by: Sean Turner

Section 2., pg. 4 says:

   DSUSRK
      Domain-Specific Usage-Specific Root Key.  A root key that is
|     derived from the DSRK; see [RFC5295].

It should say:

   DSUSRK
      Domain-Specific Usage-Specific Root Key.  A root key that is
|     derived from a DSRK; see [RFC5295].

Notes:

Rationale: There can be different DSRKs (cf. Figure 1 on page 6);
hence use of the definite article here could be confusing.

Errata ID: 2088
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-03-21
Held for Document Update by: Sean Turner

Section 6.2,2nd para says:

                              [...].  EAP-Initiate/Re-auth-Start
|  messages send to the peer will be silently dropped by the peer
   causing further waste of resources.

It should say:

                              [...].  EAP-Initiate/Re-auth-Start
|  messages sent to the peer will be silently dropped by the peer
   causing further waste of resources.

RFC 5752, "Multiple Signatures in Cryptographic Message Syntax (CMS)", January 2010

Source of RFC: smime (sec)

Errata ID: 2027
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-01-29
Held for Document Update by: Tim Polk
Date Held: 2010-03-21

Section 5, pg. 8 says:

   This section describes recommended processing of signatures when
|  there are more than one SignerInfo present in a message.  This may be
   due to either multiple SignerInfo objects being present in a single
|  SignedData object or multiple SignerData objects embedded in each
   other.

   [...]

   Order of operations:

   1) Evaluate each SignerInfo object independently.

   2) Combine the results of all SignerInfo objects at the same level
|     (i.e., attached to the same SignerData object).

|  3) Combine the results of the nested SignerData objects.  Note that
      this should ignore the presence of other CMS objects between the
      SignedData objects.

It should say:

   This section describes recommended processing of signatures when
|  there is more than one SignerInfo object present in a message.  This
   may be due to either multiple SignerInfo objects being present in a
|  single SignedData object or multiple SignedData objects embedded in
   each other.

   [...]

   Order of operations:

   1) Evaluate each SignerInfo object independently.

   2) Combine the results of all SignerInfo objects at the same level
|     (i.e., attached to the same SignedData object).

|  3) Combine the results of the nested SignedData objects.  Note that
      this should ignore the presence of other CMS objects between the
      SignedData objects.

Notes:

Rationale:
There's no such ASN.1 type/object "SignerData".
Based on the importance of referencing the correct type/object,
the correction to "SignedData" is classified as 'Technical'.
Also a clarification and fix is applied in the first sentence.

Errata ID: 2028
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-01-29
Held for Document Update by: Tim Polk

Section 2.1, pg. 6 says:

   The following is an example:

      SignedData
        DigestAlg=sha1,sha256
        SignerInfo1                SignerInfo2
          digestAlg=sha1             digestAlg=sha256
          signatureAlg=dsawithsha1   signatureAlg=ecdsawithsha256
          signedAttrs=               signedAttrs=
            signingTime1               signingTime1
            messageDigest1             messageDigest2
            multiSig1=                 multiSig2=
              bodyHash=sha256           bodyHash=sha1
              signAlg=ecdsawithsha256   signAlg=dsawithsha1
 |              signAttrsHash=          signAttrsHash=
 |              algID=sha1              algID=sha256
 |              hash=value1             hash=value2

It should say:

   The following is an example:

      SignedData
        DigestAlg=sha1,sha256
        SignerInfo1                SignerInfo2
          digestAlg=sha1             digestAlg=sha256
          signatureAlg=dsawithsha1   signatureAlg=ecdsawithsha256
          signedAttrs=               signedAttrs=
            signingTime1               signingTime1
            messageDigest1             messageDigest2
            multiSig1=                 multiSig2=
              bodyHash=sha256           bodyHash=sha1
              signAlg=ecdsawithsha256   signAlg=dsawithsha1
 |            signAttrsHash=            signAttrsHash=
 |              algID=sha1                algID=sha256
 |              hash=value1               hash=value2

Notes:

Rationale:
Fixed indentation for consistency and clarity
(visual indication of subordinate elements).

Errata ID: 2029
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-01-29
Held for Document Update by: Tim Polk

Section 4.1, pg. 7 says:

   - The signer MUST:

     -- Retain the existing signerInfo objects.

|    -- Include their signerInfo object(s).

It should say:

   - The signer MUST:

     -- Retain the existing signerInfo objects.

|    -- Include their own signerInfo object(s).

Notes:

Rationale: Remove possible ambiguity of language.
(Keep for update!)

RFC 5754, "Using SHA2 Algorithms with Cryptographic Message Syntax", January 2010

Source of RFC: smime (sec)

Errata ID: 2025
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-01-27
Held for Document Update by: Tim Polk
Date Held: 2010-03-21

Section 2.4, pg. 6 says:

2.4.  SHA-512

   [...]

|  The SMIMECapabilities attribute value indicates support for SHA-384
   in a SEQUENCE with the capabilityID field containing the object
|  identifier id-sha384 with absent parameters.  The DER encoding for
   this SMIMECapability value is:

      id-sha512: 30 0b 06 09 60 86 48 01 65 03 04 02 03

It should say:

2.4.  SHA-512

   [...]

|  The SMIMECapabilities attribute value indicates support for SHA-512
   in a SEQUENCE with the capabilityID field containing the object
|  identifier id-sha512 with absent parameters.  The DER encoding for
   this SMIMECapability value is:

      id-sha512: 30 0b 06 09 60 86 48 01 65 03 04 02 03

Notes:

Rationale: Undetected copy&paste error, but significant
(therefore classified as Technical)

RFC 5756, "Updates for RSAES-OAEP and RSASSA-PSS Algorithm Parameters", January 2010

Source of RFC: pkix (sec)

Errata ID: 2021
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-01-26
Held for Document Update by: Pasi Eronen

Section 1, last para says:

   This document also replaces incorrect references to the
   publicKeyAlgorithms field in Section 3 with references to the
   parameters field in the subjectPublicKeyInfo algorithm field.
|  Section 3 also rewords the second and third paragraphs for clarity.
          ^^^

It should say:

   This document also replaces incorrect references to the
|  publicKeyAlgorithms field in Section 3 of [RFC4055] with references
   to the parameters field in the subjectPublicKeyInfo algorithm field.
|  Section 2 also rewords the second and third paragraph in Section 3
|  of [RFC4055] for clarity.

Notes:

Rationale: Clarification
Confusion between section numbers in 2 different documents
(per late text change).
Resolution:
More details added for clarification, wrong section number corrected.

RFC 5758, "Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA", January 2010

Source of RFC: pkix (sec)

Errata ID: 2013
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-01-26
Held for Document Update by: Pasi Eronen

Section 3, last para says:

|  Conforming CA implementations that ECDSA signatures in certificates
   or CRLs MAY generate such ECDSA signatures in accordance with all the
   requirements and recommendations in [X9.62] or [SEC1] if they have a
   stated policy that requires conformance to [X9.62] or [SEC1].

It should say:

|  Conforming CA implementations that generate ECDSA signatures in
   certificates or CRLs MAY generate such ECDSA signatures in accordance
   with all the requirements and recommendations in [X9.62] or [SEC1] if
   they have a stated policy that requires conformance to [X9.62] or
   [SEC1].

Notes:

Rationale: missing verb, "generate";
cf. similar text immediately above in the same Section
and the last two paragraphs of Section 2.

RFC 5760, "RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback", February 2010

Note: This RFC has been updated by RFC 6128

Source of RFC: avt (rai)

Errata ID: 2111
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: ALfred Hoenes
Date Reported: 2010-04-05
Held for Document Update by: Robert Sparks

Section 7.4, pg.34 says:

[[  first paragraph on page 34: ]]

|  The RTP receiver MUST process the report blocks contained in any RTP
   SR and RR packets to complete its view of the RTP session.

It should say:

|  The RTP receiver MUST process the report blocks contained in any RTCP
   SR and RR packets to complete its view of the RTP session.

Notes:

Rationale; distinction between RTP and RTCP is significant;
therefore classified as 'Technical'.

Errata ID: 2113
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: ALfred Hoenes
Date Reported: 2010-04-05
Held for Document Update by: Robert Sparks

Section 9.4, pg.39 says:

[[  in the second paragraph of Section 9.4: ]]
 
|       [...] are in use, the Distribution MAY combine several incoming
   RTCP feedback packets and forward the aggregate along with its next
   RTCP RR/RSI packet.  [...]

It should say:

|       [...] are in use, the Distribution Source MAY combine several
   incoming RTCP feedback packets and forward the aggregate along with
   its next RTCP RR/RSI packet.  [...]

Notes:

Rationale: Use of full defined term, "Distribution Source".

Errata ID: 2115
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-04-05
Held for Document Update by: Robert Sparks

Section B.4, pg.63 says:

   Constant value
   Due to the size of the multiplicative factor field being 4 bits, the
|  maximum multiplicative value is 15.

|  The distribution type field of this packet would be value 1 since it
   represents loss data.

It should say:

   Constant value
   Due to the size of the multiplicative factor field being 4 bits, the
|  maximum multiplicative value is 2^15.

|  The sub-report block type field of this packet would be value 4
|  since it represents a loss data histogram.

Notes:

Rationale:
Apparently evolution of SRBT design for the body of the RFC
have been missed in the Appendix.
Changes above serve to obtain consistent use of terms and
appropriate values.

For improved readability, related changes for pp. 64/65 are being
reported in distinct Errata notes.

Errata ID: 2116
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-04-05
Held for Document Update by: Robert Sparks

Section B.4, pg.64 says:

      The packet fields will contain the values:

|     Header distribution Block
|     Distribution Type:                       1
      Number of Data Buckets:                  16
      Multiplicative Factor:                   9
      Packet Length field:                     5 (5 * 4 => 20 bytes)
|     Minimum Data Value:                      0
|     Maximum Data Value:                      39
|     Data Bucket values:                      (each value is 16-bits)

It should say:

      The packet fields will contain the values:

|     RSI reoprt fixed header;
|     -- Sub-report Block --
|     Sub-Report Block Type:                   4 (Loss distribution)
      Number of Data Buckets:                  16
      Multiplicative Factor:                   9
      Packet Length field:                     5 (5 * 4 => 20 bytes)
|     Minimum Distribution Value:              0
|     Maximum Distribution Value:              39
|     Data Bucket values:                      (each value is 4 bits)

Notes:

Rationale: See preceding reort, eid=2115 !

Errata ID: 2117
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-04-05
Held for Document Update by: Robert Sparks

Section B.4, pg.65 says:

      The packet fields will contain the values:

|     Header Distribution Block
|     Distribution Type:                        1
      Number of Data Buckets:                   40
      Multiplicative Factor:                    0
      Packet Length field:                      18 (18 * 4 => 72 bytes)
|     Minimum Loss Value:                       0
|     Maximum Loss Value:                       39

|     Bucket values are the same as the initial data set.

|     Result
|     Selecting one of the three methods outlined above might be done by
      a congestion parameter or by user preference.  The overhead
      associated with processing the packets is likely to differ very
      little between the techniques.  The savings in bandwidth are
|     apparent, however, using 20, 52, and 72 octets respectively.
      These values would vary more widely for a larger data set with
      less correlation between results.

It should say:

      The packet fields will contain the values:

|     RSI report fixed header;
|     -- Sub-report Block --
|     Sub-Report Block Type:                    4 (Loss distribution)
      Number of Data Buckets:                   40
      Multiplicative Factor:                    0
      Packet Length field:                      18 (18 * 4 => 72 bytes)
|     Minimum Distribution Value:               0
|     Maximum Distribution Value:               39

|     Bucket values are the same as the initial data set, represented
|     in 12 bits each.

|  Result
|     Selecting one of the two methods outlined above might be done by
      a congestion parameter or by user preference.  The overhead
      associated with processing the packets is likely to differ very
      little between the techniques.  The savings in bandwidth are
|     apparent, however, using 20 and 72 octets respectively.
      These values would vary more widely for a larger data set with
      less correlation between results.

Notes:

Rationale: See preceding reort, eid=2115 !
Also, there are only two examples le ft in the published appendix.

Errata ID: 2112
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: ALfred Hoenes
Date Reported: 2010-04-05
Held for Document Update by: Robert Sparks

Section 9.1 - 9.3 says:

[[ In Section 9.1: ]]

|  If the Distribution Source is operating in Simple Feedback Model
   (which may be indicated [...]

|  If the Distribution Source is operating in Distribution Source
   Feedback Summary Model, the receiver MUST use [...]

It should say:

|  If the Distribution Source is operating in the Simple Feedback Model
   (which may be indicated [...]

|  If the Distribution Source is operating in the Distribution Source
   Feedback Summary Model, the receiver MUST use [...]

Notes:

Rationale: missing articles.
Similar instances recur in Sections 9.2 and 9.3.

Further, the section headline of 9.3,

9.3. Media Senders RTCP Transmission

should perhaps better say:

9.3. Media Sender RTCP Transmission

or:

9.3. RTCP Transmission by Media Senders

[keep for update!]

RFC 5763, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", May 2010

Note: This RFC has been updated by RFC 8842

Source of RFC: sip (rai)

Errata ID: 2723
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Wu Yongming
Date Reported: 2011-02-15
Held for Document Update by: Robert Sparks

Section 5 says:

The endpoint SHOULD
send the SIP message containing the offer to the offerer's SIP proxy
over an integrity protected channel.  The proxy SHOULD add an
Identity header field according to the procedures outlined in
[RFC4474].  The SIP message containing the offer SHOULD be sent to
the offerer's SIP proxy over an integrity protected channel.

It should say:

The endpoint SHOULD
send the SIP message containing the offer to the offerer's SIP proxy
over an integrity protected channel.  The proxy SHOULD add an
Identity header field according to the procedures outlined in
[RFC4474].  The SIP message containing the offer SHOULD be sent to
the answer's SIP proxy over an integrity protected channel.

Notes:

the original text seems to be repetitive.

RFC 5764, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", May 2010

Note: This RFC has been updated by RFC 7983, RFC 9443

Source of RFC: avt (rai)

Errata ID: 3913
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin Thomson
Date Reported: 2014-03-06
Held for Document Update by: Ben Campbell
Date Held: 2015-07-22

Section 5.1.2 says:

Arriving packets may be of types RTP, DTLS, or STUN [RFC5389].
...
                   |       B < 2   -+--> forward to STUN
...
If the value of this byte is 0 or 1, then the packet is STUN.

It should say:

Arriving packets may be of types RTP, DTLS, or STUN [RFC5389].  
STUN messages with methods identifiers of 1280 or higher cannot 
be demultiplexed.
...
                   |       B < 20  -+--> forward to STUN
...
If the value of this byte is less than 20, then the packet is STUN.

Notes:

This is a tricky one. We can't distinguish all STUN message types,
because - at least in theory - new message types >= 1280 can be added
to STUN, which could collide with DTLS.

Please see Section 7 of RFC 7983 for the change that addresses this problem more
holistically and *differently* than above.

RFC 5766, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", April 2010

Note: This RFC has been obsoleted by RFC 8656

Note: This RFC has been updated by RFC 8155, RFC 8553

Source of RFC: behave (tsv)

Errata ID: 4143
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Florian Waltersdorfer
Date Reported: 2014-10-23
Held for Document Update by: Spencer Dawkins
Date Held: 2016-01-13

Section 1.Intro... says:

attempt discover a direct communication path; that is, a

It should say:

attempt to discover a direct communication path; that is, a

Notes:

line 177 in the txt version, attempt *to* do something

RFC 5769, "Test Vectors for Session Traversal Utilities for NAT (STUN)", April 2010

Source of RFC: behave (tsv)

Errata ID: 4776
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: software should include manufacturer and version number
Date Reported: 2016-08-12
Held for Document Update by: Magnus Westerlund
Date Held: 2020-06-02

Section 2 says:

2.1.  Sample Request

   This request uses the following parameters:

   Software name:  "STUN test client" (without quotes)

It should say:

2.1.  Sample Request

   This request uses the following parameters:

   Software name:  "STUN-test-client@v0.0.0" (without quotes)

Notes:

https://tools.ietf.org/html/rfc5389#section-15.10 says that
Its value SHOULD include manufacturer and version number.
so test vector of SOFTWARE at 2.1, 2.2, 2.3 should include this.

RFC 5771, "IANA Guidelines for IPv4 Multicast Address Assignments", March 2010

Source of RFC: mboned (ops)

Errata ID: 2733
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-02-24
Held for Document Update by: ron bonica

Throughout the document, when it says:

[IANA]

It should say:

[IANA-protocols]

Notes:

All references named [IANA] should be replaced by [IANA-protocols] because such references refer to the list of current assignments, that are placed at the location, mentioned as [IANA-protocols].

Errata ID: 2734
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-02-24
Held for Document Update by: ron bonica

Section 17.2 says:

 [IANA]    IANA, "IANA Protocol Registries", <http://www.iana.org/>.

It should say:

<none - should be removed>

Notes:

This errata report is to remove confusion made by Errata ID 2733. That errata proposes that [IANA] shall be replaced by [IANA-protocols] and no references to [IANA] are therefore needed.

RFC 5774, "Considerations for Civic Addresses in the Presence Information Data Format Location Object (PIDF-LO): Guidelines and IANA Registry Definition", March 2010

Source of RFC: geopriv (rai)

Errata ID: 2066
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-03-05
Held for Document Update by: Robert Sparks

Section 1, 6th para says:

   Section 3.4 of [RFC4776] also contains instructions on the creation
|  of civic address considerations documents on page 8.  This document
   updates that section and replaces said instructions with Sections 4
   and 5 of this memo.

It should say:

   Section 3.4 of [RFC4776] also contains instructions on the creation
|  of civic address considerations documents on page 9.  This document
   updates that section and replaces said instructions with Sections 4
   and 5 of this memo.

Notes:

Rationale:
This indeed refers to the second paragraph on page _9_ of RFC 4776.

RFC 5777, "Traffic Classification and Quality of Service (QoS) Attributes for Diameter", February 2010

Source of RFC: dime (ops)

Errata ID: 2337
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Francois Bard
Date Reported: 2010-07-19
Held for Document Update by: Dan Romascanu

Section 4.2.10 says:

The Absolute-End-Fractional-Seconds AVP (AVP Code 569) is of type
Unsigned32.  The value specifies the fractional seconds that are
added to Absolute-End-Time value in order to determine when the time
window ends.  If this AVP is absent from the Time-Of-Day-Condition
AVP, then the fractional seconds are assumed to be zero.

It should say:

The Absolute-Start-Fractional-Seconds AVP (AVP Code 569) is of type
Unsigned32.  The value specifies the fractional seconds that are
added to Absolute-End-Time value in order to determine when the time
window ends.  The Absolute-End-Fractional-Seconds represent 
a 32-bit fraction field giving a precision of about 232 picoseconds 
( 1/((2^32)-1)) seconds ).  If this AVP is absent from the Time-Of-Day-
Condition AVP, then the fractional seconds are assumed to be zero.
See the Network Time Protocol [RFC 1305] for more precision.

Notes:

The AVP description lacked a explanation about what a fractional second is.

RFC 5780, "NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)", May 2010

Note: This RFC has been updated by RFC 8553

Source of RFC: behave (tsv)

Errata ID: 2939
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: John Selbie
Date Reported: 2011-08-17
Held for Document Update by: Wes Eddy
Date Held: 2012-04-27

Section 9.1 says:

Section 9.1
   ...
   0x802c: OTHER-ADDRESS
   

Notes:

The document contradicts itself, one place (section 7.4) saying that OTHER-ADDRESS has the same value as CHANGED-ADDRESS did, and the other place (section 9.1) giving a new value, which matches the IANA registry. The statement explaining why it has the same value (which it doesn't) should be removed.

Errata ID: 4327
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Xinbang Hu
Date Reported: 2015-04-03
Held for Document Update by: Spencer Dawkins
Date Held: 2016-01-13

Section 3.6 says:

This test apples to UDP and TCP, but not TLS over TCP connections.

It should say:

This test applies to UDP and TCP, but not TLS over TCP connections.

Notes:

"apples" should be "applies".

RFC 5783, "Congestion Control in the RFC Series", February 2010

Source of RFC: IRTF

Errata ID: 2513
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-09-07
Held for Document Update by: Lars Eggert

Section 7, pg.19 says:

      [RFC3450] specifies ALC, a rough header format using the RMT
      building blocks, that can be used by multicast content
      dissemination protocols.  ALC is intended to use a multi-rate
      congestion control building block, where the sender does not
      require any feedback, but where multiple multicast groups with
|     different transmission rates are available within and ALC session,
      and receivers control their rates by joining or leaving groups.

It should say:

      [RFC3450] specifies ALC, a rough header format using the RMT
      building blocks, that can be used by multicast content
      dissemination protocols.  ALC is intended to use a multi-rate
      congestion control building block, where the sender does not
      require any feedback, but where multiple multicast groups with
|     different transmission rates are available within an ALC session,
      and receivers control their rates by joining or leaving groups.

Notes:

Rationale: confusing typo -- s/and/an/

RFC 5785, "Defining Well-Known Uniform Resource Identifiers (URIs)", April 2010

Note: This RFC has been obsoleted by RFC 8615

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 3027
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Frank Ellermann
Date Reported: 2011-11-11
Held for Document Update by: Peter Saint-Andre

Section header says:

Updates: 2616, 2818        

It should say:

Notes:

The document has no RFC 2818 reference, let alone any update. The RFC 2616 reference is informative, RFC 2616 was not updated by RFC 5785.

RFC 5786, "Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) Extensions", March 2010

Note: This RFC has been updated by RFC 6827, RFC 8687

Source of RFC: ospf (rtg)

Errata ID: 2085
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-03-21
Held for Document Update by: Stewart Bryant

Section 6. says:

   IANA has assigned the Node Attribute TLV (value 5) type from the
   range 3-32767 as specified in [RFC3630], from the top level types in
|  TE LSAs registry maintained by IANA at http://www.iana.org.

   IANA has created and now maintains the registry for the sub-TLVs of
|   the Node Attribute TLV.  Value 1 is reserved for Node IPv4 Local
|  Address sub-TLV and value 2 for Node IPv6 Local Address sub-TLV.

   [...]

      o  Types in the range 32778-65535 are not to be assigned at this
         time.  Before any assignments can be made in this range, there
         MUST be a Standards Track RFC that specifies IANA
|        Considerations that covers the range being assigned.

It should say:

   IANA has assigned the Node Attribute TLV (value 5) type from the
   range 3-32767 as specified in [RFC3630], from the top level types in
|  the TE LSAs registry maintained by IANA at http://www.iana.org.

   IANA has created and now maintains the registry for the sub-TLVs of
|  the Node Attribute TLV.  Value 1 is assigned to the Node IPv4 Local
|  Address sub-TLV and value 2 to the Node IPv6 Local Address sub-TLV.

   [...]

      o  Types in the range 32778-65535 are not to be assigned at this
         time.  Before any assignments can be made in this range, there
         MUST be a Standards Track RFC that specifies IANA
|        Considerations that cover the range being assigned.

Notes:

Rationale:
a) missing article
b) confusing use of "reserved"; IANA has _assigned_ these 2 values
c) singular/plural mismatch

RFC 5795, "The RObust Header Compression (ROHC) Framework", March 2010

Source of RFC: rohc (tsv)

Errata ID: 2107
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-04-05
Held for Document Update by: Lars Eggert

Section 1, pg. 5 says:

[[  1st paragraph on page 5: ]]

|  RFC 3095 [RFC3095] defines the ROHC framework along with an initial
   set of compression profiles.  [...]

It should say:

|  RFC 3095 [RFC3095] defined the ROHC framework along with an initial
   set of compression profiles.  [...]

Notes:

Rationale: This is already the 2nd revision of RFC 3095;
therefore, the adjusted temporal form better reflects
the current state of the art.

Errata ID: 2110
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-04-05
Held for Document Update by: Lars Eggert

Section 5.2.5.2 says:

[[  at the bottom of page 27: ]]

|  Header: See Section 5.2.1

|  Payload: See Section 5.2.1

|  CRC: 32-bit CRC computed using the polynomial of Section 5.3.1.4

It should say:

|  Header: See Section 5.2.1.

|  Payload: See Section 5.2.1.

|  CRC: 32-bit CRC computed using the polynomial of Section 5.3.1.4.

Notes:

Rationale: consistent use of punctuation within the RFC.

RFC 5798, "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6", March 2010

Source of RFC: vrrp (rtg)

Errata ID: 4698
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Quentin Armitage
Date Reported: 2016-05-19
Held for Document Update by: Alvaro Retana
Date Held: 2016-07-14

Section 6.4.2 says:

(465) * else // preempt was true or priority was less

It should say:

(465) * else // preempt was true and priority was less

Notes:

This is the complement of (445) - If Preempt_Mode is False, or if the Priority ... is greater than or equal to the local priority, and so should be Preempt_Mode is True and the Priority is less than the local priority

Errata ID: 4699
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Quentin Armitage
Date Reported: 2016-05-19
Held for Document Update by: Alvaro Retana
Date Held: 2016-07-14

Section 6.4.3 says:

         (630) ++ MUST send ND Router Advertisements for the virtual
         router.

         (635) ++ If Accept_Mode is False:  MUST NOT drop IPv6 Neighbor
         Solicitations and Neighbor Advertisements.

      (640) +-endif // ipv4?

and

         (705) -+ If the Priority in the ADVERTISEMENT is zero, then:

            (710) -* Send an ADVERTISEMENT

            (715) -* Reset the Adver_Timer to Advertisement_Interval

         (720) -+ else // priority was non-zero

            (725) -* If the Priority in the ADVERTISEMENT is greater
            than the local Priority,

            (730) -* or

            (735) -* If the Priority in the ADVERTISEMENT is equal to
            the local Priority and the primary IPvX Address of the
            sender is greater than the local primary IPvX Address, then:

               (740) -@ Cancel Adver_Timer

               (745) -@ Set Master_Adver_Interval to Adver Interval
               contained in the ADVERTISEMENT

               (750) -@ Recompute the Skew_Time

It should say:

         (630) + MUST send ND Router Advertisements for the virtual
         router.

         (635) + If Accept_Mode is False:  MUST NOT drop IPv6 Neighbor
         Solicitations and Neighbor Advertisements.

      (640) -endif // ipv4?

and

         (705) + If the Priority in the ADVERTISEMENT is zero, then:

            (710) * Send an ADVERTISEMENT

            (715) * Reset the Adver_Timer to Advertisement_Interval

         (720) + else // priority was non-zero

            (725) * If the Priority in the ADVERTISEMENT is greater
            than the local Priority,

            (730) * or

            (735) * If the Priority in the ADVERTISEMENT is equal to
            the local Priority and the primary IPvX Address of the
            sender is greater than the local primary IPvX Address, then:

               (740) @ Cancel Adver_Timer

               (745) @ Set Master_Adver_Interval to Adver Interval
               contained in the ADVERTISEMENT

               (750) @ Recompute the Skew_Time

Notes:

Between
(750) -@ Recompute the Skew_Time
and
(755) @ Recompute the Master_Down_Interval

the indentation level marking changes from '-@' to '@'. The corrected text removes the extra '+' from (630) to (640) and '-' from (705) to (750).

Errata ID: 5327
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ariel Otilibili Anieli
Date Reported: 2018-04-14
Held for Document Update by: Alvaro Retana
Date Held: 2018-11-04

Section 1.1 says:

This document discusses both IPv4 and IPv6 operation,

It should say:

This document discusses both IPv4 and IPv6 operations,

Notes:

Spelling mistake.

RFC 5802, "Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms", July 2010

Note: This RFC has been updated by RFC 7677, RFC 9266

Source of RFC: sasl (sec)

Errata ID: 2689
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Steffen Lehmann
Date Reported: 2011-01-21
Held for Document Update by: Tim Polk

Section 5.2 says:

2b) SCRAM sends additional data with success.

It should say:

2b) SCRAM sends additional data with success. If the server sends the additional data as a challenge, the response to this challenge is a empty response.

Notes:

The added information MUST be supplied according to RFC 4422, Section 5, Paragraph 2b.

RFC 5803, "Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted Challenge Response Authentication Mechanism (SCRAM) Secrets", July 2010

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 2500
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-08-23
Held for Document Update by: Stephen Farrell

Section Abstract says:

   This memo describes how the "authPassword" Lightweight Directory
   Access Protocol (LDAP) attribute can be used for storing secrets used
|  by the Salted Challenge Response Authentication Message (SCRAM)
   mechanism in the Simple Authentication and Security Layer (SASL)
   framework.

It should say:

   This memo describes how the "authPassword" Lightweight Directory
   Access Protocol (LDAP) attribute can be used for storing secrets used
|  by the Salted Challenge Response Authentication Mechanism (SCRAM)
   mechanism in the Simple Authentication and Security Layer (SASL)
   framework.

Notes:

Rationale: Adjust expansion of acronym "SCRAM" with what is used
in the defining document (RFC 5802).

Errata ID: 2501
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-08-23
Held for Document Update by: Stephen Farrell

Section 5 says:

   [SCRAM]     Menon-Sen, A., Newman, C., Melnikov, A., and N. Williams,
|              "Salted Challenge Response Authentication Message (SCRAM)
|              SASL Mechanisms", RFC 5802, July 2010.

It should say:

   [SCRAM]     Menon-Sen, A., Newman, C., Melnikov, A., and N. Williams,
|              "Salted Challenge Response Authentication Mechanism
|              (SCRAM) SASL and GSS-API Mechanisms", RFC 5802,
|              July 2010.

Notes:

Rationale: Align quoted title of RFC 5802 with published version.

RFC 5804, "A Protocol for Remotely Managing Sieve Scripts", July 2010

Note: This RFC has been updated by RFC 7817, RFC 8553

Source of RFC: sieve (app)

Errata ID: 2635
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexey Melnikov
Date Reported: 2010-11-17
Held for Document Update by: Peter Saint-Andre

Section 4 says:

    single-capability     = capability-name [SP string] CRLF

    capability-name       = string
                            ;; Note that literal-s2c is allowed.

    initial-capabilities  = DQUOTE "IMPLEMENTATION" DQUOTE SP string /
                            DQUOTE "SASL" DQUOTE SP sasl-mechs /
                            DQUOTE "SIEVE" DQUOTE SP sieve-extensions /
                            DQUOTE "MAXREDIRECTS" DQUOTE SP number-str /
                            DQUOTE "NOTIFY" DQUOTE SP notify-mechs /
                            DQUOTE "STARTTLS" DQUOTE /
                            DQUOTE "LANGUAGE" DQUOTE SP language /
                            DQUOTE "VERSION" DQUOTE SP version /
                            DQUOTE "OWNER" DQUOTE SP string
|                           ;; Each capability conforms to
|                           ;; the syntax for single-capability.
                            ;; Also note that the capability name
                            ;; can be returned as either literal-s2c
                            ;; or quoted, even though only "quoted"
                            ;; string is shown above.

Notes:

single-capability definition includes CRLF, while each initial-capabilities alternative doesn't. Either the ABNF comment for initial-capabilities needs to be updated to reflect that, or one of single-capability/initial-capabilities needs to be updated to make the comment true.

RFC 5810, "Forwarding and Control Element Separation (ForCES) Protocol Specification", March 2010

Note: This RFC has been updated by RFC 7121, RFC 7391

Source of RFC: forces (rtg)

Errata ID: 2567
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jamal Hadi Salim
Date Reported: 2010-10-16
Held for Document Update by: Adrian Farrel

Section Appendix A.5 says:

The RESULT-TLV RTesult Value is an 8-bit value

It should say:

The RESULT-TLV Result Value is an 8-bit value.

Errata ID: 2569
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jamal Hadi Salim
Date Reported: 2010-10-16
Held for Document Update by: Adrian Farrel

Section A.1 says:

Section A.1. Message Type Namespace, a typo 

  0x0F               Hearbeat

It should say:

should be:
  0x0F               Heartbeat

Errata ID: 2571
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jamal Hadi Salim
Date Reported: 2010-10-16
Held for Document Update by: Adrian Farrel

Section 7.1.6 says:

multiple errors in a single leaf PATH-DATA/FULLDATA-TLB, the FE can

It should say:

multiple errors in a single leaf PATH-DATA/FULLDATA-TLV, the FE can

Errata ID: 2572
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jamal Hadi Salim
Date Reported: 2010-10-16
Held for Document Update by: Adrian Farrel

Section global says:

The text on KEYINFO-TLV examples could be a little confusing.

The grammar is:
KEYINFO-TLV := KeyID FULLDATA-TLV
where the FULLDATA-TLV carries the KEYDATA. 
However, the examples dont show the text as being carried in the
FULLDATA-TLV instead they would show something along the lines of:
KEYINFO-TLV = KeyID=1, KEY_DATA=100

It should say:

The best way to represent this is:
KEYINFO-TLV, V= {1, FULLDATA-TLV V={100}}

Errata ID: 2573
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jamal Hadi Salim
Date Reported: 2010-10-16
Held for Document Update by: Adrian Farrel
Date Held: 2010-10-17

Section 7.2 and App D. says:

Section 7.2
KEY_ID  (in two places)


Appendix D
KEYDATA

It should say:

Section 7.2
KeyID   (both times)


Appendix D
KEY_DATA

Notes:

There is some small inconsistency in spelling the terms
KeyID and KeyData. Sometimes the text refers to KEY_ID and
KEY_DATA and sometimes KeyID and KEYDATA.

Errata ID: 5348
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2018-05-06
Held for Document Update by: Alvaro Retana
Date Held: 2018-05-07

Section 7.6.1 says:

   Type:

   The operation type for Config message.  Two types of operations for
   the Config message are defined:

       Type = "SET" - This operation is to set LFB components

       Type = "SET-PROP" - This operation is to set LFB component
              properties.

       Type = "DEL" - This operation is to delete some LFB components.

       Type = "COMMIT" - This operation is sent to the FE to commit in a
              2pc transaction.  A COMMIT TLV is an empty TLV, i.e., it
              has no "V"alue.  In other words, there is a length of 4
              (which is for the header only).

       Type = "TRCOMP" - This operation is sent to the FE to mark the
              success from an NE perspective of a 2pc transaction.  A
              TRCOMP TLV is an empty TLV, i.e., it has no "V"alue.  In
              other words, there is a length of 4 (which is for the
              header only).

It should say:

   Type:

   The operation type for Config message.  Five types of operations for
   the Config message are defined:

       Type = "SET" - This operation is to set LFB components

       Type = "SET-PROP" - This operation is to set LFB component
              properties.

       Type = "DEL" - This operation is to delete some LFB components.

       Type = "COMMIT" - This operation is sent to the FE to commit in a
              2pc transaction.  A COMMIT TLV is an empty TLV, i.e., it
              has no "V"alue.  In other words, there is a length of 4
              (which is for the header only).

       Type = "TRCOMP" - This operation is sent to the FE to mark the
              success from an NE perspective of a 2pc transaction.  A
              TRCOMP TLV is an empty TLV, i.e., it has no "V"alue.  In
              other words, there is a length of 4 (which is for the
              header only).

Notes:

The number of types is incorrect (two instead of five).

Errata ID: 5349
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2018-05-06
Held for Document Update by: Alvaro Retana
Date Held: 2018-05-07

Section 7.6.2 says:

   Type:
          The operation type for Config Response message.  Two types of
          operations for the Config Response message are defined:

       Type = "SET-RESPONSE" - This operation is for the response of the
              SET operation of LFB components.

       Type = "SET-PROP-RESPONSE" - This operation is for the response
              of the SET-PROP operation of LFB component properties.

       Type = "DEL-RESPONSE" - This operation is for the response of the
              DELETE operation of LFB components.

       Type = "COMMIT-RESPONSE" - This operation is sent to the CE to
              confirm a commit success in a 2pc transaction.  A
              COMMIT-RESPONSE TLV MUST contain a RESULT-TLV indicating
              success or failure.

It should say:

   Type:
          The operation type for Config Response message.  Four types of
          operations for the Config Response message are defined:

       Type = "SET-RESPONSE" - This operation is for the response of the
              SET operation of LFB components.

       Type = "SET-PROP-RESPONSE" - This operation is for the response
              of the SET-PROP operation of LFB component properties.

       Type = "DEL-RESPONSE" - This operation is for the response of the
              DELETE operation of LFB components.

       Type = "COMMIT-RESPONSE" - This operation is sent to the CE to
              confirm a commit success in a 2pc transaction.  A
              COMMIT-RESPONSE TLV MUST contain a RESULT-TLV indicating
              success or failure.

Notes:

The number of types is incorrect (two instead of four).

Errata ID: 5350
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2018-05-07
Held for Document Update by: Alvaro Retana
Date Held: 2018-05-07

Section Appendix B says:

         <events baseID="61">
           <event eventID="1">
             <name>PrimaryCEDown</name>
             <synopsis>
                 The pimary CE has changed
             </synopsis>
             <eventTarget>
                 <eventField>LastCEID</eventField>
             </eventTarget>
             <eventChanged/>
             <eventReports>
                <eventReport>
                  <eventField>LastCEID</eventField>
                </eventReport>
             </eventReports>
           </event>
         </events>

       </LFBClassDef>
     </LFBClassDefs>
   </LFBLibrary>

It should say:

         <events baseID="61">
           <event eventID="1">
             <name>PrimaryCEDown</name>
             <synopsis>
                 The primary CE has changed
             </synopsis>
             <eventTarget>
                 <eventField>LastCEID</eventField>
             </eventTarget>
             <eventChanged/>
             <eventReports>
                <eventReport>
                  <eventField>LastCEID</eventField>
                </eventReport>
             </eventReports>
           </event>
         </events>

       </LFBClassDef>
     </LFBClassDefs>
   </LFBLibrary>

Notes:

A typo in the word ¨primary¨.

RFC 5812, "Forwarding and Control Element Separation (ForCES) Forwarding Element Model", March 2010

Note: This RFC has been updated by RFC 7408

Source of RFC: forces (rtg)

Errata ID: 5363
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2018-05-18
Held for Document Update by: Alvaro Retana
Date Held: 2019-09-10

Section 3.2.8 says:

   An interesting issue related to class inheritance is backward
   compatibility between a descendant and an ancestor class.  Consider
   the following hypothetical scenario where a standardized LFB class
   "L1" exists.  Vendor A builds an FE that implements LFB "L1", and
   vendor B builds a CE that can recognize and operate on LFB "L1".
   Suppose that a new LFB class, "L2", is defined based on the existing
   "L1" class by extending its capabilities incrementally.  Let us
   examine the FE backward-compatibility issue by considering what would
   happen if vendor B upgrades its FE from "L1" to "L2" and vendor C's





Halpern & Hadi Salim         Standards Track                   [Page 29]

RFC 5812                     ForCES FE Model                  March 2010


   CE is not changed.  The old L1-based CE can interoperate with the new
   L2-based FE if the derived LFB class "L2" is indeed backward
   compatible with the base class "L1".

It should say:

   An interesting issue related to class inheritance is backward
   compatibility between a descendant and an ancestor class.  Consider
   the following hypothetical scenario where a standardized LFB class
   "L1" exists.  Vendor A builds an FE that implements LFB "L1", and
   vendor B builds a CE that can recognize and operate on LFB "L1".
   Suppose that a new LFB class, "L2", is defined based on the existing
   "L1" class by extending its capabilities incrementally.  Let us
   examine the FE backward-compatibility issue by considering what would
   happen if vendor A upgrades its FE from "L1" to "L2" and vendor B's





Halpern & Hadi Salim         Standards Track                   [Page 29]

RFC 5812                     ForCES FE Model                  March 2010


   CE is not changed.  The old L1-based CE can interoperate with the new
   L2-based FE if the derived LFB class "L2" is indeed backward
   compatible with the base class "L1".

Notes:

Confusion in the notation of vendors.

Errata ID: 5364
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2018-05-18
Held for Document Update by: Alvaro Retana
Date Held: 2019-09-10

Section 3.4.1 says:

   (b) Using pure encoded state approach to represent the LFB
   topology in 5(a), if LFB#1, LFB#2, ..., and LFB#N are of the
   same type (e.g., meter).

It should say:

   (b) Using pure encoded state approach to represent the LFB
   topology in 7(a), if LFB#1, LFB#2, ..., and LFB#N are of the
   same type (e.g., meter).

Notes:

Invalid reference to figure 5(a) instead of figure 7(a).

Errata ID: 5656
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2019-03-13
Held for Document Update by: Deborah Brungard
Date Held: 2019-05-30

Section 4.8.6 says:

                <synopsis>
                  the path to the component target
                  each 4 octets is read as one path element,
                  using the path construction in the ForCES protocol,
                  [2].
                </synopsis>

It should say:

                <synopsis>
                  the path to the component target
                  each 4 octets is read as one path element,
                  using the path construction in the ForCES protocol,
                  [RFC5810].
                </synopsis>

Notes:

Incorrect reference

RFC 5815, "Definitions of Managed Objects for IP Flow Information Export", April 2010

Note: This RFC has been obsoleted by RFC 6615

Source of RFC: ipfix (ops)

Errata ID: 2882
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Held for Document Update by: Dan Romascanu

Section multiple says:

   Benoit Claise
   Cisco Systems, Inc.
   De Kleetlaan 6a b1
   Degem  1831
   BE

It should say:

   Benoit Claise
   Cisco Systems, Inc.
   De Kleetlaan 6a b1
   Diegem  1831
   BE

Notes:

s/Degem/Diegem/

- three times:
in the MIB in section 8.1,
in the MIB in section 8.2,
and in the Author's Addresses.

Errata ID: 2896
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Held for Document Update by: Dan Romascanu

Section multiple says:

ipfixFunFn...

It should say:

ipfixFuncFn...

Notes:

Typo in section 6.1 and in the MIB in section 8.1.
Inconsistent with use of "ipfixFuncF*" elsewhere in the document.

Errata ID: 2897
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Held for Document Update by: Dan Romascanu

Section 8.1 says:

   ipfixMeteringProcessCacheId OBJECT-TYPE
       SYNTAX      Unsigned32 (1..4294967295)
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "Locally arbitrary, but unique identifier of an entry in the
           ipfixMeterinProcessTable.  The value is expected to remain
           constant from a re-initialization of the entity's network
           management agent to the next re-initialization."
       ::= { ipfixMeteringProcessEntry 1 }

It should say:

   ipfixMeteringProcessCacheId OBJECT-TYPE
       SYNTAX      Unsigned32 (1..4294967295)
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "Locally arbitrary, but unique identifier of an entry in the
           ipfixMeterinProcessTable.  The value is expected to remain
           constant from a re-initialization of the entity's network
           management agent to the next re-initialization."
       ::= { ipfixMeteringProcessEntry 1 }

Notes:

s/ipfixMeterinProcessTable/ipfixMeteringProcessTable/

Typo: section 1.1.5: Metering Process Table defines "ipfixMeteringProcessTable".

Errata ID: 2898
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Held for Document Update by: Dan Romascanu

Section 1.1.7 says:

   ipfixSelectionProcessSelectorIndex OBJECT-TYPE
       SYNTAX      Unsigned32 (1..4294967295)
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "Index specifying the order in which the referenced
           ipfixSelctionProcessSelectorFunctions are applied to the
           observed packet stream within the given Selection Process
           (identified by the ipfixSelectionProcessIndex).  The
           Selector Functions are applied in increasing order, i.e.,
           Selector Functions with lower index are applied first."
       ::= { ipfixSelectionProcessEntry 2 }

It should say:

   ipfixSelectionProcessSelectorIndex OBJECT-TYPE
       SYNTAX      Unsigned32 (1..4294967295)
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "Index specifying the order in which the referenced
           ipfixSelectionProcessSelectorFunctions are applied to the
           observed packet stream within the given Selection Process
           (identified by the ipfixSelectionProcessIndex).  The
           Selector Functions are applied in increasing order, i.e.,
           Selector Functions with lower index are applied first."
       ::= { ipfixSelectionProcessEntry 2 }

Notes:

s/ipfixSelctionProcessSelectorFunctions/ipfixSelectionProcessSelectorFunctions/

Typo: section 1.1.7 Selection Process Table defines "ipfixSelectionProcessSelectorFunction".

RFC 5826, "Home Automation Routing Requirements in Low-Power and Lossy Networks", April 2010

Source of RFC: roll (rtg)

Errata ID: 2132
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-04-07
Held for Document Update by: Adrian Farrel

Section 5, pg.15 says:

[[ bottom lines of page 15: ]]

                     [...].  The routing protocol(s) MUST deny service
|  to any node that has not clearly established trust with the HC-LLN.

It should say:

                     [...].  The routing protocol(s) MUST deny service
|  to any node that has not clearly established trust with the LLN.

Notes:

Rationale: The abbreviation "HC-LLN" is not defined in the document.
(Editorial oversight; keep for update!)

RFC 5847, "Heartbeat Mechanism for Proxy Mobile IPv6", June 2010

Source of RFC: netlmm (int)

Errata ID: 2302
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-06-15
Held for Document Update by: Brian Haberman

Section 3.1, pg. 5 says:

   A PMIPv6 node (MAG or LMA) matches every received Heartbeat Response
   to the Heartbeat Request sent using the sequence number.  Before
   sending the next Heartbeat Request, it increments a local variable
<< page break >>
|  MISSING_HEARTBEAT if it has not received a Heartbeat Response for the
|  previous request.  When this local variable MISSING_HEARTBEAT exceeds
   a configurable parameter MISSING_HEARTBEATS_ALLOWED, the PMIPv6 node
   concludes that the peer PMIPv6 node is not reachable.  If a Heartbeat
!  Response message is received, the MISSING_HEARTBEATS counter is
   reset.

It should say:

   A PMIPv6 node (MAG or LMA) matches every received Heartbeat Response
   to the Heartbeat Request sent using the sequence number.  Before
   sending the next Heartbeat Request, it increments a local variable
|  MISSING_HEARTBEATS if it has not received a Heartbeat Response for 
|  the previous request.  When this local variable MISSING_HEARTBEATS 
   exceeds a configurable parameter MISSING_HEARTBEATS_ALLOWED, the
   PMIPv6 node concludes that the peer PMIPv6 node is not reachable.
   If a Heartbeat Response message is received, the MISSING_HEARTBEATS
   counter is reset.

Notes:

Rationale:
The RFC text varies between singular and plural form of the name
of the local variable. A single name is necessary for consistency.
Paraphrasing from MIB doctor guidelines, counter variables should
always be in plural form. Additionally, the related configurable
parameter is called "MISSING_HEARTBEATS_ALLOWED " in the RFC.
Therefore, "MISSING_HEARTBEATS" is chosen above as the appropriate
form and the instances of "MISSING_HEARTBEAT" are changed to the
plural form.

RFC 5849, "The OAuth 1.0 Protocol", April 2010

Note: This RFC has been obsoleted by RFC 6749

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 2718
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Florian Sey
Date Reported: 2011-02-14
Held for Document Update by: Peter Saint-Andre

Section 3.4.1.3.1 says:

contains the following (fully decoded) parameters used in the 
signature base sting:

It should say:

contains the following (fully decoded) parameters used in the 
signature base string:

Notes:

typographical error

Errata ID: 2860
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: houtsnip
Date Reported: 2011-07-13
Held for Document Update by: Peter Saint-Andre

Section 3.4.1.1. says:

   5.  The request parameters as normalized in Section 3.4.1.3.2, after
       being encoded (Section 3.6).

It should say:

   5.  The request parameters as normalized in Section 3.4.1.3.2, and then encoded (Section 3.6).

[or ...]

   5.  The normalized request parameter string (see Section 3.4.1.3.2), after being encoded.

Notes:

It is not clear, from the way you write, whether you mean that the request parameters are first encoded, and then normalized, or the other way round.

When the sentence is read out of context, the meaning seems to be that the request parameters are first encoded, and then normalized, which is not what is actually meant. The real meaning can only be understood by looking at the sentence preceding the list: 'The signature base string is constructed by concatenating together, in order, the following HTTP request elements'. Then you understand that the request parameters are not *normalized* 'after being encoded', but are *concatenated* 'after being encoded'.

It was confusing enough for me, and my first language is English. Until I started filling in this erratum (and until I really looked at it closely), I really thought it was a technical error, and you'd just got it wrong.

Errata ID: 3328
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Peter Day
Date Reported: 2012-08-21
Held for Document Update by: Sean Turner

Section 4.12. says:

Those designing additional signature methods, should evaluated 
the compatibility of the signature base string with their 
security requirements.

It should say:

Those designing additional signature methods should evaluate 
the compatibility of the signature base string with their 
security requirements.

Notes:

Remove comma after "methods" and change "evaluated" to "evaluate".

RFC 5850, "A Call Control and Multi-Party Usage Framework for the Session Initiation Protocol (SIP)", May 2010

Source of RFC: sipping (rai)

Errata ID: 3662
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Joël Repiquet
Date Reported: 2013-06-17
Held for Document Update by: Gonzalo Camarillo

Section 2.5 says:

   The multi-party architecture may also need to provide a mechanism to
   get information about the status/handling of a dialog (for example,
   information about the history of other contacts attempted prior to
   the current contact).  Finally, the architecture should provide ample
   opportunities to present informational URIs that relate to calls,
   conversations, or dialogs in some way.  For example, consider the SIP
   Call-Info header or Contact header fields returned in a 300-class
   response.  Frequently, additional information about a call or dialog
   can be fetched via non-SIP URIs.  For example, consider a web page
   for package tracking when calling a delivery company or a web page
   with related documentation when joining a dial-in conference.  The
   use of URIs in the multi-party framework is discussed in more detail
   in Section 3.7.

It should say:

   The multi-party architecture may also need to provide a mechanism to
   get information about the status/handling of a dialog (for example,
   information about the history of other contacts attempted prior to
   the current contact).  Finally, the architecture should provide ample
   opportunities to present informational URIs that relate to calls,
   conversations, or dialogs in some way.  For example, consider the SIP
   Call-Info header or Contact header fields returned in a 300-class
   response.  Frequently, additional information about a call or dialog
   can be fetched via non-SIP URIs.  For example, consider a web page
   for package tracking when calling a delivery company or a web page
   with related documentation when joining a dial-in conference.  The
   use of URIs in the multi-party framework is discussed in more detail
   in Section 2.7.

RFC 5857, "IKEv2 Extensions to Support Robust Header Compression over IPsec", May 2010

Source of RFC: rohc (tsv)

Errata ID: 2274
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-05-19
Held for Document Update by: Lars Eggert

Section 3.1, pg.4 says:

[[ first paragraph on page 4: ]]
 
  A new Notify Message Type value, denoted ROHC_SUPPORTED, indicates
   that the Notify payload is conveying ROHC channel parameters (Section
|  4).

It should say:

   A new Notify Message Type value, denoted ROHC_SUPPORTED, indicates
   that the Notify payload is conveying ROHC channel parameters (Section
|  3.1.2).

Notes:

Rationale:
Section 4 of RFC 5857 is "Security Considerations"; the various ROHC
parameters that can/must be signaled via this Notify payload are
described in Section 3.1.2 of RFC 5857.

Errata ID: 2275
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-05-19
Held for Document Update by: Lars Eggert

Section 3.1.2, pg.8 says:

[[ first paragraph of description for ROHC_ICV_LEN, on mid-page 8: ]]

      [...]
      If no ROHC_ICV_LEN attribute is sent at all or if the ROHC_ICV_LEN
|     is larger than the length of the ICV of selected algorithm, then
      the full ICV length as specified by the ROHC_INTEG algorithm MUST
      be sent.

It should say:

      [...]
      If no ROHC_ICV_LEN attribute is sent at all or if the ROHC_ICV_LEN
|     is larger than the length of the ICV of the selected algorithm,
      then the full ICV length as specified by the ROHC_INTEG algorithm
      MUST be sent.

Notes:

Rationale: missing definite article

Errata ID: 3320
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2012-08-16
Held for Document Update by: Wes Eddy

Section 3.1.2 says:

   This section describes five ROHC Attribute Types: MAX_CID,
   ROHC_PROFILE, ROHC_INTEG, ROHC_ICV_LEN, and MRRU.  The value
   allocated for each ROHC Attribute Type is specified in Section 4.

It should say:

   This section describes five ROHC Attribute Types: MAX_CID,
   ROHC_PROFILE, ROHC_INTEG, ROHC_ICV_LEN, and MRRU.  The value
   allocated for each ROHC Attribute Type is specified in Section 5.

Notes:

Section 4 of RFC 5857 is "Security Considerations". Values of ROHC Attribute Types listed in Section 5.

RFC 5858, "IPsec Extensions to Support Robust Header Compression over IPsec", May 2010

Source of RFC: rohc (tsv)

Errata ID: 2277
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-05-19
Held for Document Update by: Lars Eggert

Section 4.2, pg. 7 says:

                BEFORE COMPRESSION AND APPLICATION OF ESP
                ----------------------------
          IPv4  |orig IP hdr  |     |      |
                |(any options)| TCP | Data |
                ----------------------------

                 AFTER ROHCOIPSEC COMPRESSION AND APPLICATION OF ESP
               ------------------------------------------------------
         IPv4  | new IP hdr  |     | Cmpr. |    | ROHC | ESP   | ESP|
               |(any options)| ESP | Hdr.  |Data| ICV  |Trailer| ICV|
               ------------------------------------------------------

   Figure 1.  Example of a ROHCoIPsec-Processed Packet

It should say:

                BEFORE COMPRESSION AND APPLICATION OF ESP
                ----------------------------
          IPv4  |orig IP hdr  |     |      |
                |(any options)| TCP | Data |
                ----------------------------

                 AFTER ROHCOIPSEC COMPRESSION AND APPLICATION OF ESP
               ------------------------------------------------------
         IPv4  | new IP hdr  |     | Cmpr. |    | ROHC | ESP   | ESP|
               |(any options)| ESP | Hdr.  |Data| ICV  |Trailer| ICV|
|              --------------------+===================+-------------

|  Figure 1.  Example of a ROHCoIPsec-Processed Packet ( +=====+ in
|             the diagram indicates the plaintext that undergoes ESP
|             protection; the packet actually contains the ciphertext)

Notes:

Rationale:
The lower part of Figure 1 misrepresents the packet format;
in the general case (not ESP NULL encryption), the structure
of the inner part of the ESP tunnel mode packet is hidden by
encryption.
The graphical presentation therefore might mislead the reader.
The suggested Corrected Text tries to avoid this by graphically
marking this part of the packet and adding a short note that the
diagram represents the plaintext structure only.

Errata ID: 2276
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-05-19
Held for Document Update by: Lars Eggert

Section 3.2, pg. 5 says:

   The data items contained within the SAD are defined in RFC 4301
   [IPSEC], Section 4.4.2.1.  To support ROHC, the SAD must include a
|  "ROHC Data Item"; this data item contains parameters used by ROHC
   instance.  The ROHC Data Item exists for both inbound and outbound
   SAs.

   The ROHC Data Item includes the ROHC channel parameters for the SA.
   These channel parameters (i.e., MAX_CID, PROFILES, MRRU) are
   enumerated above in Section 3.1.  For inbound SAs, the ROHC Data Item
   MUST specify the ROHC channel parameters that are used by the local
   decompressor instance; conversely, for outbound SAs, the ROHC Data
|  Item MUST specify the ROHC channel parameters that are used by local
   compressor instance.

It should say:

   The data items contained within the SAD are defined in RFC 4301
   [IPSEC], Section 4.4.2.1.  To support ROHC, the SAD must include a
|  "ROHC Data Item"; this data item contains parameters used by the ROHC
   instance.  The ROHC Data Item exists for both inbound and outbound
   SAs.

   The ROHC Data Item includes the ROHC channel parameters for the SA.
   These channel parameters (i.e., MAX_CID, PROFILES, MRRU) are
   enumerated above in Section 3.1.  For inbound SAs, the ROHC Data Item
   MUST specify the ROHC channel parameters that are used by the local
   decompressor instance; conversely, for outbound SAs, the ROHC Data
|  Item MUST specify the ROHC channel parameters that are used by the
   local compressor instance.

Notes:

Rationale: missing definite article (2 instances)

RFC 5864, "DNS SRV Resource Records for AFS", April 2010

Note: This RFC has been updated by RFC 8553

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 2767
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Iñaki Baz Castillo
Date Reported: 2011-04-05
Held for Document Update by: Peter Saint-Andre

Section 6 says:

   afsdb1, afsdb2, and afsdb3 all provide VLDB service via UDP.  The
   first two have the same priority but have weights indicating that
   afsdb1 should get about twice as many clients as afsdb2.

It should say:

   afsdb1, afsdb2, and afsdb3 all provide VLDB service via UDP.  The
   first two have the same priority but have weights indicating that
   afsdb2 should get about twice as many clients as afsdb1.

Notes:

The given DNS zone file shows:

_afs3-vlserver._udp SRV 0 2 7003 afsdb1.example.com.
_afs3-vlserver._udp SRV 0 4 7003 afsdb2.example.com.

This means that afsdb2.example.com. as weight 4 (double of weight for afsdb1.example.com.).

According to RFC 2782:

Weight
A server selection mechanism. The weight field specifies a
relative weight for entries with the same priority. Larger
weights SHOULD be given a proportionately higher probability of
being selected.

RFC 5865, "A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic", May 2010

Source of RFC: tsvwg (wit)

Errata ID: 3194
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sergey Antipov
Date Reported: 2012-04-17
Held for Document Update by: Wesley Eddy

Section 2.2 says:

   There are at least six major ways that capacity admission is done or
   has been proposed to be done for real-time applications.  Each will
   be described below, and Section 3 will judge which ones are likely to
   meet the requirements of the Admitted Telephony service class.  These
   include:

It should say:

   There are at least six major ways that capacity admission is done or
   has been proposed to be done for real-time applications.  Each will
   be described below, and Section 2.3 will judge which ones are likely to
   meet the requirements of the Admitted Telephony service class.  These
   include:

Notes:

Section 2.3 is the one, which recommends capacity admission procedures, while Section 3 summarizes proposed changes.

RFC 5877, "The application/pkix-attr-cert Media Type for Attribute Certificates", May 2010

Source of RFC: pkix (sec)

Errata ID: 2254
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-05-13
Held for Document Update by: Tim Polk

Throughout the document, when it says:

   ... MIME media type ...

It should say:

   ... media type ...

Notes:

The adaptation to RFC 4288 has been performed in an incomplete manner.
"MIME" should better have been removed from the Abstract (1 instance)
and the first paragraph of Section 1 (2 instances) as well.

RFC 5878, "Transport Layer Security (TLS) Authorization Extensions", May 2010

Note: This RFC has been updated by RFC 8447, RFC 8996

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 3514
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Ben Laurie
Date Reported: 2013-03-08
Held for Document Update by: Kathleen Moriarty
Date Held: 2015-06-05

Section 3.3 says:

17 # Handshake.msg_type == supplemental_data(23)
00 00 11 # Handshake.length = 17
00 00 0e # length of SupplementalData.supp_data = 14
40 02 # SupplementalDataEntry.supp_data_type = 16386
00 0a # SupplementalDataEntry.supp_data_length = 10
00 08 # length of AuthorizationData.authz_data_list = 8
01 # authz_format = saml_assertion(1)
00 05 # length of SAMLAssertion
aa aa aa aa aa # SAML assertion (fictitious: "aa aa aa aa aa")

It should say:

17 # Handshake.msg_type == supplemental_data(23)
00 00 0f # Handshake.length = 15
00 00 0d # length of SupplementalData.supp_data = 13
40 02 # SupplementalDataEntry.supp_data_type = 16386
00 0a # SupplementalDataEntry.supp_data_length = 8
01 # authz_format = saml_assertion(1)
00 05 # length of SAMLAssertion
aa aa aa aa aa # SAML assertion (fictitious: "aa aa aa aa aa")

Notes:

Per Russ Housley: We do not have an implementation that can be used to check the hex values, but they appear to be correct.

RFC 5880, "Bidirectional Forwarding Detection (BFD)", June 2010

Note: This RFC has been updated by RFC 7419, RFC 7880, RFC 8562

Source of RFC: bfd (rtg)

Errata ID: 5205
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Dave Katz
Date Reported: 2017-12-14
Held for Document Update by: Alvaro Retana
Date Held: 2018-03-14

Section 6.8.4 says:

If Demand mode is not active, and a period of time equal to the
Detection Time passes without receiving a BFD Control packet from the
remote system, and bfd.SessionState is Init or Up, the session has
gone down -- the local system MUST set bfd.SessionState to Down and
bfd.LocalDiag to 1 (Control Detection Time Expired).

It should say:

If Demand mode is not active, and a period of time equal to the
Detection Time passes without receiving a BFD Control packet from the
remote system, the session has
gone down -- the local system MUST set bfd.SessionState to Down and
bfd.LocalDiag to 1 (Control Detection Time Expired).

Notes:

This is based on an email I received from Anil Kumar of Nokia (anil.kumar_t_v@nokia.com).

The language as originally written made a session timeout a no-op when in Down state. This was a gratuitous attempt to avoid a null state transition, but had the side effect of not setting the diag code (and otherwise is no different).

This turns out to be problematic in the case where system "A" signals AdminDown, causing system "B" to respond with Down state. If the link then fails, the existing verbiage implies that "B" will not report the detection timeout, even locally.

If the link fails in a unidirectional manner (such that "B" is deaf), B will give no indication of a timeout in its outgoing Control packets back to A (which can in fact hear them).

Making the suggested change should ensure that the diagnostic code is always set to Detection Time Expired when Control packets stop arriving, even if the far end system was previously reporting AdminDown.

Errata ID: 7240
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Jeffrey Haas
Date Reported: 2022-11-06
Held for Document Update by: John Scudder
Date Held: 2023-03-10

Section 6.8.1 says:

   bfd.LocalDiag

      The diagnostic code specifying the reason for the most recent
      change in the local session state.  This MUST be initialized to
      zero (No Diagnostic).

It should say:

No proposed changes are offered here. See the notes for further discussion.

Notes:

RFC 5880 at various points calls out setting the value of bfd.LocalDiag as part of state transitions. The text defining the feature calls for it to be initialized to zero. Discussion on the WG mailing list following the filing of the initial version of this erratum revealed two things:

First, the text of the RFC is correct, complete, and reflects the authors’ intention at the time of writing, which really WAS that the value should only be initialized to zero but not reset to zero at any other time.

Second, by not emphasizing this point, the spec although formally speaking unambiguous, left space for implementors to exercise their intuitions and creativity. As a result, several implementations are reported to reset this value to zero when the session transitions back to Up.

The discussion is archived at https://mailarchive.ietf.org/arch/msg/rtg-bfd/yEOx2LTO51zq1he6vChUOVJySqM/ . If a new version of RFC 5880 is prepared in the future, this question should be reopened as part of that process. It would also be possible to offer a standards track document to update RFC 5880 in this respect if WG consensus can be found for a new approach.

Errata ID: 4410
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Liu Lin
Date Reported: 2015-07-07
Held for Document Update by: Alvaro Retana
Date Held: 2016-02-16

Section 6.8.4 says:

If Demand mode is active, and a period of time equal to the Detection
Time passes after the initiation of a Poll Sequence (the transmission
of the first BFD Control packet with the Poll bit set), the session
has gone down

It should say:

If Demand mode is active, and a period of time equal to the Detection
Time passes after the initiation of a Poll Sequence (the transmission
of the first BFD Control packet with the Poll bit set),and without 
receiving a BFD Control packet with the Final (F) bit set from the
remote system, the session has gone down

Notes:

If has received BFD Control packet with the Final (F) bit set from the
remote system, the session will not gone down

RFC 5882, "Generic Application of Bidirectional Forwarding Detection (BFD)", June 2010

Source of RFC: bfd (rtg)

Errata ID: 4812
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alexander ("Sasha") Vainshtein
Date Reported: 2016-09-27
Held for Document Update by: Alvaro Retana
Date Held: 2016-09-27

Section 10.1.2 says:

   IS-IS may be used to support only one data protocol, or multiple data
   protocols.  [ISIS] specifies a common topology for multiple data
   protocols, but work is under way to support multiple topologies.  If
   multiple topologies are used to support multiple data protocols (or
   multiple classes of service of the same data protocol), the topology-
   specific path associated with a failing BFD session should no longer
   be advertised in IS-IS Label Switched Paths (LSPs) in order to signal
   a lack of connectivity.

It should say:

   IS-IS may be used to support only one data protocol, or multiple data
   protocols.  [ISIS] specifies a common topology for multiple data
   protocols, but work is under way to support multiple topologies.  If
   multiple topologies are used to support multiple data protocols (or
   multiple classes of service of the same data protocol), the topology-
   specific path associated with a failing BFD session should no longer
   be advertised in IS-IS Link State Packets (LSPs) in order to signal
   a lack of connectivity.

Notes:

In the context of this section (that discusses usage of BFD sessions for detection of failure of an IS-IS adjacency) the abbreviation "LSP" should be expanded as "Link State Packet" and not as "Label Switched Path".

From my POV this is an editorial erratum since I believe the readers of the RFC understand what the authors wanted to say.

RFC 5884, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", June 2010

Note: This RFC has been updated by RFC 7726

Source of RFC: bfd (rtg)

Errata ID: 5087
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Carlos Pignataro
Date Reported: 2017-08-16
Held for Document Update by: Alvaro Retana
Date Held: 2017-11-06

Section 7 says:

7.  Encapsulation

[...]

   The BFD Control packet sent by the ingress LSR MUST be a UDP packet
   with a well-known destination port 3784 [BFD-IP] and a source port
   assigned by the sender as per the procedures in [BFD-IP].  The source
   IP address is a routable address of the sender.  The destination IP
   address MUST be randomly chosen from the 127/8 range for IPv4 and
   from the 0:0:0:0:0:FFFF:7F00/104 range for IPv6 with the following
   exception.  If the FEC is an LDP IP FEC, the ingress LSR may discover
   multiple alternate paths to the egress LSR for this FEC using LSP
   Ping traceroute.  In this case, the destination IP address, used in a
   BFD session established for one such alternate path, is the address
   in the 127/8 range for IPv4 or 0:0:0:0:0:FFFF:7F00/104 range for IPv6
   discovered by LSP Ping traceroute [RFC4379] to exercise that
   particular alternate path.

[...]

   Or the BFD Control packet sent by the egress LSR to the ingress LSR
   MAY be encapsulated in an MPLS label stack.  In this case, the
   presence of the fault detection message is indicated as described
   above.  This may be the case if the FEC for which the fault detection
   is being performed corresponds to a bidirectional LSP or an MPLS PW.
   This may also be the case when there is a return LSP from the egress
   LSR to the ingress LSR.  In this case, the destination IP address
   MUST be randomly chosen from the 127/8 range for IPv4 and from the
   0:0:0:0:0:FFFF:7F00/104 range for IPv6.

It should say:

7.  Encapsulation

[...]

   The BFD Control packet sent by the ingress LSR MUST be a UDP packet
   with a well-known destination port 3784 [BFD-IP] and a source port
   assigned by the sender as per the procedures in [BFD-IP].  The source
   IP address is a routable address of the sender.  The destination IP
   address MUST be randomly chosen from the 127/8 range for IPv4 and
   from the 0:0:0:0:0:FFFF:7F00:0/104 range for IPv6 with the following
   exception.  If the FEC is an LDP IP FEC, the ingress LSR may discover
   multiple alternate paths to the egress LSR for this FEC using LSP
   Ping traceroute.  In this case, the destination IP address, used in a
   BFD session established for one such alternate path, is the address
   in the 127/8 range for IPv4 or 0:0:0:0:0:FFFF:7F00:0/104 range for 
   IPv6 discovered by LSP Ping traceroute [RFC4379] to exercise that
   particular alternate path.

[...]

   Or the BFD Control packet sent by the egress LSR to the ingress LSR
   MAY be encapsulated in an MPLS label stack.  In this case, the
   presence of the fault detection message is indicated as described
   above.  This may be the case if the FEC for which the fault detection
   is being performed corresponds to a bidirectional LSP or an MPLS PW.
   This may also be the case when there is a return LSP from the egress
   LSR to the ingress LSR.  In this case, the destination IP address
   MUST be randomly chosen from the 127/8 range for IPv4 and from the
   0:0:0:0:0:FFFF:7F00:0/104 range for IPv6.

Notes:

There are three instances of the IPv4-mapped IPv6 prefix for the IPv4 loopback range 127.0.0.0/8 written as 0:0:0:0:0:FFFF:7F00/104, and it should instead be written as 0:0:0:0:0:FFFF:7F00:0/104.

s/0:0:0:0:0:FFFF:7F00/0:0:0:0:0:FFFF:7F00:0/g (3 replacements)

Same rationale as https://mailarchive.ietf.org/arch/msg/rtg-bfd/DqH_LFCEyUqCLQhffEb7_jU24uQ

Errata ID: 5088
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Carlos Pignataro
Date Reported: 2017-08-17
Held for Document Update by: Alvaro Retana
Date Held: 2017-11-06

Section 3.1,4,7,11.2 says:

[5085]

It should say:

[5885]

Notes:

RFC 5884 refers to RFC 5085, when in fact it should refer to RFC 5885 (or at the very least to both RFCs 5085 and 5885 consecutively).

Historically, RFC 5085 and RFC 5885 come from the same Internet-Draft, which was Referenced from RFC 5884. It included general VCCV as well as BFD for VCCV. Subsequently, that document was split into two I-Ds that resulted in RFCs 5085 and 5885. BFD for Pseudowires is actually covered by RFC 5885 (not 5085).

In Section 3.1. BFD for MPLS LSPs: Motivation

e) Pseudowires based on PWid FEC and Generalized PWid FEC
[RFC4447]

e) is covered by RFC 5885 as BFD single-hop for PWs. And not as per the more complex RFC 5884.

A better technical normalization of BFD for PWs versus BFD for other MPLS LSPs is needed to adequately cover the subject matter of RFC 5884.

Note, RFC 5884 and 5885 were part of the same RFC-Editor cluster.

RFC 5888, "The Session Description Protocol (SDP) Grouping Framework", June 2010

Note: This RFC has been updated by RFC 8843, RFC 9143

Source of RFC: mmusic (rai)

Errata ID: 2314
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-06-24
Held for Document Update by: Gonzalo Camarillo

Section 9.3 says:

   A client that understands "group" and "mid", but does not want to use
   these SDP features in a particular session, may still want to
   indicate that it supports these features.  To indicate this support,
|  a client can add an "a=3Dgroup" line with no identification-tags for
   every semantics value it understands.

It should say:

   A client that understands "group" and "mid", but does not want to use
   these SDP features in a particular session, may still want to
   indicate that it supports these features.  To indicate this support,
|  a client can add an "a=group" line with no identification-tags for
   every semantics value it understands.

Notes:

Rationale:
There's no need for quoted-printable encoding of the
"=" character in the running RFC text!
(Cf. other parts of the RFC.)

Errata ID: 4357
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jeff Poole
Date Reported: 2015-05-06
Held for Document Update by: Alissa Cooper
Date Held: 2015-11-01

Section 8.4.1 says:

          v=0
          o=Laura 289083124 289083124 IN IP4 seven.example.com
          c=IN IP4 192.0.2.1
          t=0 0
          a=group:FID 1 2
          m=audio 30000 RTP/AVP 0
          a=mid:1
          m=audio 20000 RTP/AVP 97
          c=IN IP4 192.0.2.2
          a=rtpmap:97 telephone-events
          a=mid:2

It should say:

          v=0
          o=Laura 289083124 289083124 IN IP4 seven.example.com
          c=IN IP4 192.0.2.1
          t=0 0
          a=group:FID 1 2
          m=audio 30000 RTP/AVP 0
          a=mid:1
          m=audio 20000 RTP/AVP 97
          c=IN IP4 192.0.2.2
          a=rtpmap:97 telephone-event
          a=mid:2

Notes:

Minor typo on page 10. Per RFC 4733, the rtpmap entry should use the media type "telephone-event" not "telephone-events".

RFC 5890, "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", August 2010

Source of RFC: idnabis (app)

Errata ID: 4824
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Juan Altmayer Pizzorno
Date Reported: 2016-05-17
Held for Document Update by: Alexey Melnikov
Date Held: 2016-10-07

Section 4.2 says:

Because A-labels (the form actually used in the
DNS) are potentially much more compressed than UTF-8 (and UTF-8 is,
in general, more compressed that UTF-16 or UTF-32), U-labels that
obey all of the relevant symmetry (and other) constraints of these
documents may be quite a bit longer, potentially up to 252 characters
(Unicode code points).

It should say:

Because A-labels (the form actually used in the
DNS) are potentially much more compressed than UTF-8 (and UTF-8 is,
in general, more compressed that UTF-16 or UTF-32), U-labels that
obey all of the relevant symmetry (and other) constraints of these
documents may be quite a bit longer, potentially up to 59 Unicode
code points, or up to 236 octets.

Notes:

(The same rationale as my report for 2.3.2.1 applies:)

The contents of U-labels are encoded in the up to 59 ASCII characters (see 2.3.2.1)
output by the Punycode algorithm in their corresponding A-labels. The Punycode
decoder (https://tools.ietf.org/html/rfc3492#section-6.2) consumes at least one
of those ASCII characters for each code point inserted into the U-label. An U-label,
thus, can contain at the most 59 Unicode code points.

Since U-labels are defined (in 2.3.2.1) to be expressed in a standard Unicode Encoding
Form, and UTF-32, UTF-16 and UTF-8 (as revised by RFC3629) all can encode a code
point in at most 4 octets, 236 octets is an upper bound for an U-label's length.

I think it should be possible to derive a tighter bound, but its rationale would likely be
less straighforward.

I imagine the number 252 was originally derived by multiplying 63, the maximum
length of an A-label (including the "xn--" prefix), by 4, the maximum number of
octets needed to represent a code point.

Errata ID: 4823
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Juan Altmayer Pizzorno
Date Reported: 2016-05-17
Held for Document Update by: Alexey Melnikov
Date Held: 2016-10-07

Section 2.3.2.1 says:

expansion of the A-label form to a U-label may produce strings that are
much longer than the normal 63 octet DNS limit (potentially up to 252
characters)

It should say:

expansion of the A-label form to a U-label may produce strings that are
much longer than the normal 63 octet DNS limit (potentially up to 59
Unicode code points or 236 octets)

Notes:

The contents of U-labels are encoded in the up to 59 ASCII characters (see 2.3.2.1 itself)
output by the Punycode algorithm in their corresponding A-labels. The Punycode
decoder (https://tools.ietf.org/html/rfc3492#section-6.2) consumes at least one
of those ASCII characters for each code point inserted into the U-label. An U-label,
thus, can contain at the most 59 Unicode code points.

Since U-labels are defined (in 2.3.2.1) to be expressed in a standard Unicode Encoding
Form, and UTF-32, UTF-16 and UTF-8 (as revised by RFC3629) all can encode a code
point in at most 4 octets, 236 octets is an upper bound for an U-label's length.

I think it should be possible to derive a tighter bound, but its rationale would likely be
less straighforward.

I imagine the number 252 was originally derived by multiplying 63, the maximum
length of an A-label (including the "xn--" prefix), by 4, the maximum number of
octets needed to represent a code point.

Errata ID: 5484
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Peter Occil
Date Reported: 2018-08-28
Held for Document Update by: Murray Kucherawy
Date Held: 2023-01-04

Section 2.3.2.1 says:

   For IDNA-aware applications, the three types of valid labels are
   "A-labels", "U-labels", and "NR-LDH labels", each of which is defined
   below.

It should say:

   For IDNA-aware applications, the three types of valid labels are
   "A-labels", "U-labels", and "NR-LDH labels", each of which is defined
   below and in section 2.3.1.

Notes:

The term NR-LDH label is actually defined in section 2.3.1, not later in this section.

[Note from the document author: In reality, at least from the author's perspective, "NR-LDH label" is defined in the section of that name, i.e., 2.3.2.2, which is "below" 2.3.2.1. Whether 2.3.1 also "defines" it or supplements that definition (or if 2.3.2.1 supplements what 2.3.1 has to say) is a matter for debate, but it is clear that the text cited would benefit from a reference to 2.3.1.]

RFC 5891, "Internationalized Domain Names in Applications (IDNA): Protocol", August 2010

Source of RFC: idnabis (app)

Errata ID: 3969
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Peter Occil
Date Reported: 2014-04-19
Held for Document Update by: Barry Leiba
Date Held: 2014-04-21

Section 4.2.3.2 says:

The Unicode string MUST NOT begin with a combining mark or combining
character (see The Unicode Standard, Section 2.11 [Unicode] for an
exact definition).

It should say:

The Unicode string MUST NOT begin with a combining mark or combining 
character (as defined in The Unicode Standard, Section 3.6 [Unicode], 
definition D52).

Notes:

Section 2.11 of the Unicode Standard explains what combining characters are only in general terms. Section 3.6 contains the actual definition.

----- Verifier Notes -----
The actual fix is probably closer to changing "exact definition" to "explanation of combining characters," and leaving the reference alone. But discussion indicates that more clarification is probably good, and that clarification needs to be in the broader context of a document update.

RFC 5905, "Network Time Protocol Version 4: Protocol and Algorithms Specification", June 2010

Note: This RFC has been updated by RFC 7822, RFC 8573, RFC 9109

Source of RFC: ntp (int)

Errata ID: 3125
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Richard Walters
Date Reported: 2012-02-16
Held for Document Update by: Brian Haberman

Section A.5.1.1 says:

        /*
         * Calculate offset, delay and dispersion, then pass to the
         * clock filter.  Note carefully the implied processing.  The
         * first-order difference is done directly in 64-bit arithmetic,
         * then the result is converted to floating double.  All further
         * processing is in floating-double arithmetic with rounding
         * done by the hardware.  This is necessary in order to avoid
         * overflow and preserve precision.
         *
         * The delay calculation is a special case.  In cases where the
         * server and client clocks are running at different rates and
         * with very fast networks, the delay can appear negative.  In
         * order to avoid violating the Principle of Least Astonishment,
         * the delay is clamped not less than the system precision.
         */
        if (p->pmode == M_BCST) {
                offset = LFP2D(r->xmt - r->dst);
                delay = BDELAY;
                disp = LOG2D(r->precision) + LOG2D(s.precision) + PHI *
                    2 * BDELAY;
        } else {
                offset = (LFP2D(r->rec - r->org) + LFP2D(r->dst -
                    r->xmt)) / 2;
                delay = max(LFP2D(r->dst - r->org) - LFP2D(r->rec -
                    r->xmt), LOG2D(s.precision));
                disp = LOG2D(r->precision) + LOG2D(s.precision) + PHI *
                    LFP2D(r->dst - r->org);
        }
        clock_filter(p, offset, delay, disp);

It should say:

        /*
         * Calculate offset, delay and dispersion, then pass to the
         * clock filter.  Note carefully the implied processing.  The
         * first-order difference is done directly in 64-bit arithmetic,
         * then the result is converted to floating double.  All further
         * processing is in floating-double arithmetic with rounding
         * done by the hardware.  This is necessary in order to avoid
         * overflow and preserve precision.
         *
         * The delay calculation is a special case.  In cases where the
         * server and client clocks are running at different rates and
         * with very fast networks, the delay can appear negative.  In
         * order to avoid violating the Principle of Least Astonishment,
         * the delay is clamped not less than the system precision.
         */
        if (p->pmode == M_BCST) {
                offset = LFP2D(r->xmt - r->dst);
                delay = BDELAY;
                disp = LOG2D(r->precision) + LOG2D(s.precision) + PHI *
                    2 * BDELAY;
        } else {
                offset = (LFP2D(r->rec - r->org) + LFP2D(r->xmt -
                    r->dst)) / 2;
                delay = max(LFP2D(r->dst - r->org) - LFP2D(r->xmt -
                    r->rec), LOG2D(s.precision));
                disp = LOG2D(r->precision) + LOG2D(s.precision) + PHI *
                    LFP2D(r->dst - r->org);
        }
        clock_filter(p, offset, delay, disp);

Notes:

Calculations of 'offset' and 'delay' have terms that are incorrectly swapped. In the calculation of 'offset', term 'r->dst' should be 'r->xmt', and term 'r->xmt' should be 'r->dst'. In the calculation of 'delay', term 'r->rec' should be 'r->xmt', and term 'r->xmt' should be 'r->rec'.

See the text from section 8:

"In the figure, the first packet transmitted by A contains only the
origin timestamp t1, which is then copied to T1. B receives the
packet at t2 and copies t1 to T1 and the receive timestamp t2 to T2.
At this time or some time later at t3, B sends a packet to A
containing t1 and t2 and the transmit timestamp t3. All three
timestamps are copied to the corresponding state variables. A
receives the packet at t4 containing the three timestamps t1, t2, and
t3 and the destination timestamp t4. These four timestamps are used
to compute the offset and delay of B relative to A, as described
below.

...

"The four most recent timestamps, T1 through T4, are used to compute
the offset of B relative to A

theta = T(B) - T(A) = 1/2 * [(T2-T1) + (T3-T4)]

and the round-trip delay

delta = T(ABA) = (T4-T1) - (T3-T2)."

Noting that, from the perspective of A at time t4:

T1 = t1 = origin timestamp (r->org)
T2 = t2 = receive timestamp (r->rec)
T3 = t3 = transmit timestamp (r->xmt)
T4 = t4 = destination timestamp (r->dst)

An alternative correction would be to change the '+' to a '-' in the calculation of 'offset', and change the '-' to a '+' in the calculation of 'delay'. However, this would deviate from the operators used in the formulas from section 8.

Errata ID: 2476
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Joerg Weilbier
Date Reported: 2010-08-19
Held for Document Update by: Brian Haberman

Section 7.3. says:

For instance, a value of -18 
corresponds to a precision of about one microsecond.

It should say:

For instance, a value of -20 
corresponds to a precision of about one microsecond.

Notes:

2**-20 = 0.954 usec
2**-18 = 3.815 usec

Errata ID: 3404
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Philippe Verdy
Date Reported: 2012-11-08
Held for Document Update by: Brian Haberman

Section A.1.1. says:

#define SQUARE(x)       (x * x)

It should say:

#define SQUARE(x)       ((x) * (x))

Notes:

This macro is used in the example code to square differences:

//- in clock_filter() {...} (page 85) :

p->jitter += SQUARE(f[i].offset - f[0].offset);

//- in clock_select() { ... } (page 92) :

dtemp += SQUARE(p->offset - q->offset);

//- in clock_combine() { ... } (page 96) :

w += SQUARE(p->offset - s.v[0].p->offset) / x;

//- in local_clock() { ... } (page 99) :

dtemp = SQUARE(max(fabs(offset - c.last),
LOG2D(s.precision)));


These expressions are using differences of double values: the .offset member in a Filter stage structure (f), and the .jitter member in an Association structure (p), or in a Local clock structure (c), or in a System structure (s).

All these occurences of macro substitions of SQUARE() will be wrong if the C macro does not surrounds its parameter expression by adding parentheses around them !

This is a very classic error made by beginners in C programming using "utility" macros with side effects... At least newer programmers avoid these kind of macros and prefer defining inline functions

Errata ID: 3127
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Richard Walters
Date Reported: 2012-02-17
Held for Document Update by: Brian Haberman

Section A.5.5.1 says:

                /*
                 * Scan the chime list from lowest to highest to find
                 * the lower endpoint.
                 */
                found = 0;
                chime = 0;
                for (i = 0; i < n; i++) {
                        chime -= s.m[i].type;
                        if (chime >= n - found) {
                                low = s.m[i].edge;
                                break;
                        }
                        if (s.m[i].type == 0)
                                found++;
                }

                /*
                 * Scan the chime list from highest to lowest to find
                 * the upper endpoint.
                 */
                chime = 0;
                for (i = n - 1; i >= 0; i--) {
                        chime += s.m[i].type;
                        if (chime >= n - found) {
                                high = s.m[i].edge;
                                break;
                        }
                        if (s.m[i].type == 0)
                                found++;
                }

It should say:

                /*
                 * Scan the chime list from lowest to highest to find
                 * the lower endpoint.
                 */
                found = 0;
                chime = 0;
                for (i = 0; i < n; i++) {
                        chime -= s.m[i].type;
                        if (chime >= n - allow) {
                                low = s.m[i].edge;
                                break;
                        }
                        if (s.m[i].type == 0)
                                found++;
                }

                /*
                 * Scan the chime list from highest to lowest to find
                 * the upper endpoint.
                 */
                chime = 0;
                for (i = n - 1; i >= 0; i--) {
                        chime += s.m[i].type;
                        if (chime >= n - allow) {
                                high = s.m[i].edge;
                                break;
                        }
                        if (s.m[i].type == 0)
                                found++;
                }

Notes:

In both scans (lowest to highest, and highest to lowest)

chime >= n - found

needs to be:

chime >= n - allow

Errata ID: 3608
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Cristian Rodríguez
Date Reported: 2013-04-29
Held for Document Update by: Brian Haberman

Section A.2. says:

/*
         * Read command line options and initialize system variables.
         * The reference implementation measures the precision specific
         * to each machine by measuring the clock increments to read the
         * system clock.
         */
        memset(&s, sizeof(s), 0);

.....
/*
         * Initialize local clock variables
         */
        memset(&c, sizeof(c), 0);

It should say:

/*
         * Read command line options and initialize system variables.
         * The reference implementation measures the precision specific
         * to each machine by measuring the clock increments to read the
         * system clock.
         */
        memset(&s, 0. sizeof(s));
...

/*
         * Initialize local clock variables
         */
        memset(&c, 0, sizeof(c));

Notes:

Paramters 2 and 3 of the memset functions are inverted everywhere in the example code, not just in section A2

Errata ID: 4366
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Vyacheslav
Date Reported: 2015-05-13
Held for Document Update by: Brian Haberman
Date Held: 2015-09-14

Section 11.2.1 says:

5.  Is d = f and l < u?  If yes, then follow step 5A; else, follow
   step 5B.

It should say:

5.  Is d <= f and l < u?  If yes, then follow step 5A; else, follow
   step 5B.

Notes:

Original text doesn't correspond to sample implementation at A.5.5.1. And, I suppose, described algorithm may throw out reasonable set of measures.

Errata ID: 5604
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Takashi Nakamoto
Date Reported: 2019-01-15
Held for Document Update by: Erik Kline
Date Held: 2022-09-26

Section 11.2.3. says:

                  | s.rootdisp  <-- p.epsilon_r + p.epsilon + |
                  |                 p.psi + PHI * (s.t - p.t) |
                  |                 + |THETA|                 |

It should say:

                  | s.rootdisp  <-- p.epsilon_r + p.epsilon   |
                  |                 + 5 * p.psi +             |
                  |                 + PHI * (s.t - p.t)       |
                  |                 + |THETA|                 |

Notes:

In addition to the correction proposed in Errata ID 5601, I think that the formula to calculate the dispersion should be revised. The term "p.psi" should be multiplied by not one, but a larger value.

This is because the dispersion is defined as the statistics that represent the maximum error, so when it is calculated, it should take into account the maximum errors in the offset estimation. However, the jitter p.psi is defined as the RMS average of the offset values theta_j relative to theta_0, so the term "p.psi" does not represent the maximum error caused by the distribution of the offset values.

If we assume that the offset value follows the uniform distribution, the error bound is represented as sqrt(3) * p.psi. So, at least, the term "p.psi" should be multiplied by sqrt(3). There is arbitrarity in choice of the distribution type, so depending on the distribution type the factor may change. For example, if the normal distribution is assumed, 5 * p.psi gives us 99.99994% confidence. Assuming that the system variable is updated every 16 seconds, the actual offset may be outside the range [theta_0 - 5 * p.psi, theta_0 + 5 * p.psi] approximately once a year. It should be sufficient for usual Internet applications, though someone may think that the factor "5" may not be sufficient depending on the application.

---

[INT AD notes]

See also https://mailarchive.ietf.org/arch/msg/ntp/Cbg3sOhChyfenYoj7UG5wCymFMU/ :

"""
...That makes some sense to me, but I'd say it really depends on the model of the clock and that's arbitrary...
"""

Errata ID: 6280
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Jingguo Yao
Date Reported: 2020-09-05
Held for Document Update by: Erik Kline
Date Held: 2022-09-26

Section A.5.5.1. says:

There is the following comment:

* First, construct the chime list of tuples (p, type, edge) as
* shown below, then sort the list by edge from lowest to
* highest.

It should say:

There should be some statements to do the sorting since the comment mentions it. But there are no statements related to sorting in the following code. 

And I checked the NTP reference implementation. There is code to do the sorting at https://github.com/ntp-project/ntp/blob/71a962710bfe066f76da9679cf4cfdeffe34e95e/ntpd/ntp_proto.c#L2837

Notes:

From https://mailarchive.ietf.org/arch/msg/ntp/zJNoHvZ08SPX-3kwflMK7PIReFo/ :

"""
... correctly identifies the problem, but it doesn't provide the new
text. I'd suggest to add "sort(s.m, n);" right after the first while
loop in A.5.5.1.
"""

Errata ID: 2514
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jerzy Miernik
Date Reported: 2010-09-08
Held for Document Update by: Brian Haberman

Section A.5.1 says:

if (0) { ...

It should say:

if (unicast ...) { ...

Notes:

expression under if is needed, even using pseudo-code

Errata ID: 2826
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christian Aistleitner
Date Reported: 2011-06-10
Held for Document Update by: Brian Haberman

Section 6 says:

[...]
and a 64-bit fraction field resolving .05 attosecond (i.e., 0.5e-18).

It should say:

[...]
and a 64-bit fraction field resolving .05 attosecond (i.e., 0.05e-18).

Notes:

"atto" is the prefix for 1e-18.

Errata ID: 3126
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Richard Walters
Date Reported: 2012-02-16
Held for Document Update by: Brian Haberman

Section 3 says:

          +-------------------+-------------------+------------------+
          |  Association Mode | Assoc. Mode Value | Packet Mode Value|
          +-------------------+-------------------+------------------+
          | Symmetric Active  |         1         | 1 or 2           |
          | Symmetric Passive |         2         | 1                |
          | Client            |         3         | 4                |
          | Server            |         4         | 3                |
          | Broadcast Server  |         5         | 5                |
          | Broadcast Client  |         6         | N/A              |
          +-------------------+-------------------+------------------+

                  Figure 1: Association and Packet Modes

   In the client/server variant, a persistent client sends packet mode 4
   packets to a server, which returns packet mode 3 packets.

It should say:

          +-------------------+-------------------+------------------+
          |  Association Mode | Assoc. Mode Value | Packet Mode Value|
          +-------------------+-------------------+------------------+
          | Symmetric Active  |         1         | 1 or 2           |
          | Symmetric Passive |         2         | 1                |
          | Client            |         3         | 4                |
          | Server            |         4         | 3                |
          | Broadcast Server  |         5         | N/A              |
          | Broadcast Client  |         6         | 5                |
          +-------------------+-------------------+------------------+

                  Figure 1: Association and Packet Modes

   In the client/server variant, a persistent client sends packet mode 3
   packets to a server, which returns packet mode 4 packets.

Notes:

The majority of the rows in Figure 1 are correct if the 'Packet Mode Value' refers to the mode of packets which are expected to be received by an NTP speaker which has mobilized an association with the corresponding 'Association Mode'. Assuming this is the case, the last two rows are incorrect:

* A peer with a mobilized 'Broadcast Server' mode association is not expected to receive any packets at all for this association -- a broadcast server does not receive anything back (see 'Broadcast' mode row in Section 9.2, Figure 20, where each column in that row is 'DSCRD'.) Therefore, the value of 'Packet Mode Value' for 'Broadcast Server' should be 'N/A', not '5'.

* A peer with a mobilized 'Broadcast Client' mode association is expected to receive packets with a 'Packet Mode Value' of 5 for this association (see 'Bcast Client' mode row in Section 9.2, Figure 20, where each column in that row is 'DSCRD' except for the '5' column, which is 'PROC'.) Therefore, the value of 'Packet Mode Value' for 'Broadcast Client' should be '5', not 'N/A'.

It might help the clarity of Figure 1 if the row labeled 'Packet Mode Value' were to be changed to 'Receive Packet Mode Value(s)'.

The text immediately following Figure 1 also has the packet mode values swapped. As made clear throughout the RFC (for example, see Section 9.2 where is says, "FXMIT. This indicates a client (mode 3) packet matching no association (mode 0). If the destination address is not a broadcast address, the server constructs a server (mode 4) packet and returns it to the client without retaining state."), clients send servers packet mode 3 packets, not packet mode 4 packets; it is servers which send clients packet mode 4 packets, not packet mode 3 packets.

Just to make it perfectly clear, here are the modes of packets sent:

* Time t0: client mobilizes 'Client' mode association for server (via configuration, or due to reception of manycast server packet)
* Time t1: client transmits mode 3 packet to server (e.g. via poll(p) => peer_xmit(p) when c.t >= p->nextdate)
* Time t2: server receives mode 3 packet from client (dispatch: FXMIT; no association found or mobilized)
* Time t3: server transmits mode 4 packet to client
* Time t4: client receives mode 4 packet from server (matches previously mobilized association -- dispatch: PROC)

Errata ID: 3132
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Richard Walters
Date Reported: 2012-02-21
Held for Document Update by: Brian Haberman

Section 11.2.1 says:

   First, those servers that are unusable according to the rules of the
   protocol are detected and discarded as shown by the accept() routine
   in Appendix A.5.5.3.

It should say:

   First, those servers that are unusable according to the rules of the
   protocol are detected and discarded as shown by the fit() routine
   in Appendix A.5.2.

Notes:

The fit() and accept() routines are identical. Since accept() is not called from, nor mentioned anywhere else, whereas fit() is called from two places and listed in the function prototypes, just drop accept() and use fit() instead in section 11.2.1.

Errata ID: 4025
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julien Cretin
Date Reported: 2014-06-25
Held for Document Update by: Brian Haberman
Date Held: 2014-06-25

Section 6 says:

-678,491

It should say:

-678,941

Notes:

In Figure 4, the MJD of 1 Jan 0 has a typo.

There are 365 (not 815) days from 1 Jan -1 to 1 Jan 0, and 366 (not -84) from 1 Jan 0 to 1 Jan 1. I took NTP Timestamp Era Offset as a reference for the number of days in these years.

Errata ID: 4263
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Priyesh Patel
Date Reported: 2015-02-05
Held for Document Update by: Brian Haberman
Date Held: 2015-02-06

Section 7.3, Fig 8 says:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |LI | VN  |Mode |    Stratum     |     Poll      |  Precision   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |LI | VN  |Mode |    Stratum    |     Poll      |  Precision    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

The field boundaries are not aligned with the bit boundaries in "Figure 8: Packet Header Format".

Errata ID: 6423
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stijn van Drongelen
Date Reported: 2021-02-07
Held for Document Update by: Erik Kline
Date Held: 2022-07-27

Section 6 says:

| 1 Jan 1972  | 41,317     | 0   | 2,272,060,800 | First day UTC    |

It should say:

| 1 Jan 1972  | 41,317     | 0   | 2,272,060,800 | First day "modern" UTC |

Notes:

The initial definition of UTC was introduced in 1963 with CCIR Recommendation 374. The time standard specified that seconds had a varying duration. In 1970, CCIR Recommendation 460 introduced the current definition of UTC, using leap seconds, which was implemented on the first second of 1972. Consult D. McCarthy's "Note on Coordinated Universal Time" (numbered CCTF/09-32 by the Consultative Committee for Time and Frequency of the BIPM) for more information.

---

There may perhaps be more precise terminology than "modern", but this point should be addressed by a document that updates or replaces this one.

Errata ID: 6524
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kenneth Duffill
Date Reported: 2021-04-09
Held for Document Update by: Erik Kline
Date Held: 2022-09-26

Section 6 says:

202,939,144

It should say:

202,934,144

Notes:

In Figure 4 The Era Offset of 1 Jan 1 has a typo.

The value of 202,939,144 for the Era Offset of 1 Jan 1 should be 202,934,144 because 1 Jan 0 has an Era Offset of 171,311,744 and there are 366 days in year 0, therefore the Era Offset for 1 Jan 1 should be 86400 * 366 (= 31,622,400) greater than that for 1 JAN 0.

---

[INT AD notes]

From https://mailarchive.ietf.org/arch/msg/ntp/Cbg3sOhChyfenYoj7UG5wCymFMU/ :

"""
... might be correct too, but I find that table confusing with those
dates when the modern definition of the second and UTC didn't exist
yet...
"""

RFC 5906, "Network Time Protocol Version 4: Autokey Specification", June 2010

Source of RFC: ntp (int)

Errata ID: 3348
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: liyh
Date Reported: 2012-09-12
Held for Document Update by: Brian Haberman

Section 5 says:

Autokey exchange.[...]Completion of this exchange lights the AUT bit as described below.

It should say:

Autokey exchange.[...]Completion of this exchange lights the AUTO bit as described below.

RFC 5907, "Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4)", June 2010

Source of RFC: ntp (int)

Errata ID: 2542
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dave Hart
Date Reported: 2010-10-04
Held for Document Update by: Brian Haberman

Section 5 says:

-- MIB contains 6 groups

It should say:

-- MIB contains 5 groups

Notes:

Late in NTPv4 MIB development the proposed 6th section in the MIB, NtpEntNotifPrefix, was removed, the comment preceding the section definitions was overlooked, still referencing 6 MIB sections.

Errata ID: 2543
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dave Hart
Date Reported: 2010-10-04
Held for Document Update by: Brian Haberman

Section 5 says:

Discountinuities in the value of this counter can occur

It should say:

Discontinuities in the value of this counter can occur

Notes:

"Discontinuities" is misspelled in several counter descriptions.

RFC 5918, "Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)", August 2010

Note: This RFC has been updated by RFC 7358

Source of RFC: mpls (rtg)

Errata ID: 2473
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-08-18
Held for Document Update by: Adrian Farrel

Section 3, last para says:

   This document specifies one FEC Element Type instance (e.g., Prefix
   FEC) for the 'Typed Wildcard FEC Element' in Section 6.

It should say:

   This document specifies one FEC Element Type instance (i.e., Prefix
   FEC) for the 'Typed Wildcard FEC Element' in Section 6.

Notes:

Adjust the semantics: s!e.g.!i.e.!

RFC 5919, "Signaling LDP Label Advertisement Completion", August 2010

Source of RFC: mpls (rtg)

Errata ID: 2475
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-08-19
Held for Document Update by: Adrian Farrel

Section 5.3,1st para says:

   When an LDP speaker receives a Label Request message for a Typed
|  Wildcard FEC (e.g., a particular FEC Element Type) from a peer, the
   LDP speaker determines the set of bindings (as per any local
   filtering policy) to advertise to the peer for the FEC type specified
   by the request.  [...]

It should say:

   When an LDP speaker receives a Label Request message for a Typed
|  Wildcard FEC (i.e., a particular FEC Element Type) from a peer, the
   LDP speaker determines the set of bindings (as per any local
   filtering policy) to advertise to the peer for the FEC type specified
   by the request.  [...]

Notes:

The parenthetical clause does not give an example, it gives
an explanation; therefore, to avoid confusion, s!e.g.!i.e.!

Note: Same issue as addressed by EID=2473 for RFC 5918.

RFC 5923, "Connection Reuse in the Session Initiation Protocol (SIP)", June 2010

Source of RFC: sip (rai)

Errata ID: 2310
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-06-24
Held for Document Update by: Robert Sparks

Section 8.2 says:

[[ in the last paragraph at the bottom of page 13: ]]

   The server, if it decides to reuse the connection, MUST cache in the
   alias table the identity (or identities) of the client as they appear
|  in the X.509 certificate subjectAlternativeName extension field.  [...]
                                   ^^^^^^^^^^^

It should say:

   The server, if it decides to reuse the connection, MUST cache in the
   alias table the identity (or identities) of the client as they appear
|  in the X.509 certificate subjectAltName extension field.  [...]
                                   ^^^

Notes:

Rationale:
Mis-spelling of the defined certificate extension name --
see (for example) RFC 5280.

RFC 5925, "The TCP Authentication Option", June 2010

Source of RFC: tcpm (wit)

Errata ID: 6406
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ananth Rajadurai
Date Reported: 2021-01-22
Held for Document Update by: Martin Duke
Date Held: 2021-01-25

Section Section 5.1 says:

In Section 5.1, Figure 6 - TCP IPv6 Pseudoheader

+--------+--------+--------+--------+
|                                   |
+                                   +
|                                   |
+          Source Address           +
|                                   |
+                                   +
|                                   |
+                                   +
+--------+--------+--------+--------+
|                                   |
+                                   +
|                                   |
+        Destination Address        +
|                                   |
+                                   +
|                                   |
+--------+--------+--------+--------+
|      Upper-Layer Payload Length   |
+--------+--------+--------+--------+
|      Zero       |    Next Header  |
+--------+--------+--------+--------+

It should say:

+--------+--------+--------+--------+
|                                   |
+                                   +
|                                   |
+          Source Address           +
|                                   |
+                                   +
|                                   |
+                                   +
+--------+--------+--------+--------+
|                                   |
+                                   +
|                                   |
+        Destination Address        +
|                                   |
+                                   +
|                                   |
+--------+--------+--------+--------+
|      Upper-Layer Payload Length   |
+--------+--------+--------+--------+
|            Zero          |Next Hdr|
+--------+--------+--------+--------+

Notes:

In IPv6 pseudoheader, Zero field should be 3 bytes and Next header should be 1 byte.
But in RFC 5925, figure 6, it misleads into Zero field 2 bytes and Next header 2 bytes.

RFC 5926, "Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)", June 2010

Source of RFC: tcpm (wit)

Errata ID: 6413
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ananth Rajadurai
Date Reported: 2021-01-28
Held for Document Update by: Martin Duke
Date Held: 2021-02-02

Section 3.1.1.2 says:

In section 3.1.1.2 Page 8, figure 1,

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+                        KDF-AES-128-CMAC                           +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+                                                                   +
+ Input  : MK (Master_Key, the variable-length shared secret)       +
+        : I (Input, i.e., the input data of the PRF)               +
+        : MKlen (length of MK in octets)                           +
+        : len (length of M in octets)                              +
+ Output : TK (Traffic_Key, 128-bit Pseudo-Random Variable)         +
+                                                                   +
+-------------------------------------------------------------------+

It should say:

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+                        KDF-AES-128-CMAC                           +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+                                                                   +
+ Input  : MK (Master_Key, the variable-length shared secret)       +
+        : I (Input, i.e., the input data of the PRF)               +
+        : MKlen (length of MK in octets)                           +
+        : len (length of I in octets)                              +
+ Output : TK (Traffic_Key, 128-bit Pseudo-Random Variable)         +
+                                                                   +
+-------------------------------------------------------------------+

Notes:

In Input, "len" is described as (length of "M' in octets), but there is no "M" in the input, but it is supposed to mention the length of the Input Data "I", so it should be (length of "I" in octets)

RFC 5940, "Additional Cryptographic Message Syntax (CMS) Revocation Information Choices", August 2010

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 2531
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ruediger Volk
Date Reported: 2010-09-26
Held for Document Update by: Stephen Farrell

Section 4. says:

  Unlike OSCP, SCVP permits unprotected and protected responses, where
   protected responses can be digitally signed or include message
   authentication codes.

It should say:

  Unlike OCSP, SCVP permits unprotected and protected responses, where
   protected responses can be digitally signed or include message
   authentication codes.

Notes:

simple typo in acronym OCSP

RFC 5951, "Network Management Requirements for MPLS-based Transport Networks", September 2010

Source of RFC: mpls (rtg)

Errata ID: 3254
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Adrian Farrel
Date Reported: 2012-06-11
Held for Document Update by: Adrian Farrel

Section 6.3 says:

   1) In addition to the requirement to support static provisioning of
      transport paths (defined in RFC 5645 [7], Section 2.1

It should say:

   1) In addition to the requirement to support static provisioning of
      transport paths (defined in RFC 5654 [7], Section 2.1

Notes:

Digits in RFC number transposed

RFC 5952, "A Recommendation for IPv6 Address Text Representation", August 2010

Source of RFC: 6man (int)

Errata ID: 3218
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rodrigo Curado
Date Reported: 2012-05-09
Held for Document Update by: Brian Haberman

Section 3.1.4 says:

Network diagrams and blueprints often show what IP addresses are 
assigned to a system devices.

It should say:

Network diagrams and blueprints often show which IP addresses are 
assigned to which systems devices.

Notes:

Improved grammar and correction to mismatch between singular and plural usage.

Errata ID: 3219
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rodrigo Curado
Date Reported: 2012-05-09
Held for Document Update by: Brian Haberman

Section 3.1.4 says:

In times of trouble shooting there may be a need to search

It should say:

In times of troubleshooting there may be a need to search

Notes:

"troubleshooting" should be written as one word

RFC 5953, "Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)", August 2010

Note: This RFC has been obsoleted by RFC 6353

Note: This RFC has been updated by RFC 8996

Source of RFC: isms (sec)

Errata ID: 2670
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Juergen Schoenwaelder
Date Reported: 2010-12-14
Held for Document Update by: Sean Turner

Section A.1 says:

snmpTargetParamsRowStatus       = 4          (createAndGo0

It should say:

snmpTargetParamsRowStatus       = 4          (createAndGo)

Notes:

This is a typo - the shift key was not hit hard enough and hence the closing parenthesis became a 0.

Errata ID: 2671
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Robert Story
Date Reported: 2010-12-15
Held for Document Update by: Sean Turner

Section A.1 says:

       snmpTargetAddrColumnStatus      = 4          (createAndGo)

It should say:

       snmpTargetAddrRowStatus         = 4          (createAndGo)

Notes:

There is not such object as snmpTargetAddrColumnStatus. The correct object for row creation is snmpTargetAddrRowStatus.

RFC 5954, "Essential Correction for IPv6 ABNF and URI Comparison in RFC 3261", August 2010

Source of RFC: sip (rai)

Errata ID: 2502
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-08-23
Held for Document Update by: Robert Sparks

Section 4.2, page 5 says:

   NEW:

   o  For two URIs to be equal, the user, password, host, and port
|     components must match.  If the host component contains a textual
|     representation of IP addresses, then the representation of those
      IP addresses may vary.  If so, the host components are considered
      to match if the different textual representations yield the same
      binary IP address.

It should say:

   NEW:

   o  For two URIs to be equal, the user, password, host, and port
|     components must match.  If both host components contain the textual
|     representation of an IP address, then the representation of those
      IP addresses may vary.  If so, the host components are considered
      to match if the different textual representations yield the same
      binary IP address.

Notes:

Rationale: Essential clarification of potentially misleading grammar
and semantics including singular/plural mismatches. Because of the
perceived significance, this erratum is designated as Technical.

RFC 5961, "Improving TCP's Robustness to Blind In-Window Attacks", August 2010

Note: This RFC has been updated by RFC 9293

Source of RFC: tcpm (wit)

Errata ID: 4772
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2016-08-10
Held for Document Update by: Mirja Kühlewind
Date Held: 2016-09-12

Section 7 says:

[The entire section]

It should say:

No suggested text because it requires a much more serious analysis. 
May be adding that the rate-limit counter SHOULD be per-connection, 
in the spirit of RFC 6528?

Notes:

It appears the section does not specify that the counter for ACK throttling SHOULD be per-connection. In Linux, it is apparently global, which allowed its use as a side channel enabling nasty attacks (CVE-2016-5696 and the paper "Off-Path TCP Exploits: Global Rate Limit Considered Dangerous" <http://www.cs.ucr.edu/~zhiyunq/pub/sec16_TCP_pure_offpath.pdf>).
Also see discussion on tcpm list about this reported errata!

Errata ID: 5068
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Wesley Eddy
Date Reported: 2017-07-12
Held for Document Update by: Martin Duke
Date Held: 2020-04-20

Section 3.2 says:

   [RFC0793] currently requires handling of a segment with the RST bit
   when in a synchronized state to be processed as follows:

It should say:

   [RFC0793] currently requires handling of a segment with the RST bit
   when not in SYN-SENT to be processed as follows:

Notes:

The text in section 3.2 begins by stating a change from RFC 793 for RST bit handling "when in a synchronized state" (which means all states except for LISTEN, SYN-SENT, and SYN-RECEIVED).

Section 3.4 of RFC 793 refers to "all states but SYN-SENT", so the description of RFC 793 is inaccurate.

RFC 5965, "An Extensible Format for Email Feedback Reports", August 2010

Note: This RFC has been updated by RFC 6650

Source of RFC: marf (app)

Errata ID: 3120
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: John Levine
Date Reported: 2012-02-14
Held for Document Update by: Pete Resnick

Section 2.d. says:

This part MUST be included (contrary to [REPORT])

It should say:

This part MUST be included if the entity creating the report has 
received the message.

Notes:

Reports can be created from info collected in SMTP transactions that don't accept a message, a scenario we didn't consider when we wrote this section.

RFC 5984, "Increasing Throughput in IP Networks with ESP-Based Forwarding: ESPBasedForwarding", April 2011

Source of RFC: INDEPENDENT

Errata ID: 5408
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: micheal65536
Date Reported: 2018-06-25
Held for Document Update by: Adrian Farrel
Date Held: 2019-08-18

Section 3.1 says:

The DPAUI sends a signal to the PPG (Deep Packet And User Inspection)

It should say:

The DPAUI sends a signal to the PPG (Precognitive Packet Generator)

Notes:

Incorrect expansion of acronym is given.

RFC 5986, "Discovering the Local Location Information Server (LIS)", September 2010

Source of RFC: geopriv (rai)

Errata ID: 2521
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-09-15
Held for Document Update by: Robert Sparks

Section 3.4,3rd para says:

   DHCPv4 option 15 [RFC2132] provides an indication of the domain name
|  that a host uses when resolving hostnames in DNS.  This option is
   used when the DHCPv4 access domain name is not available.

It should say:

   DHCPv4 option 15 [RFC2132] provides an indication of the domain name
|  that a host uses when resolving hostnames in the DNS.  This option is
   used when the DHCPv4 access domain name is not available.

Notes:

Rationale: missing article

Errata ID: 2522
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-09-15
Held for Document Update by: Robert Sparks

Section 5, pg.12 says:

|  The domain name that used to authenticate the LIS is the domain name
   input to the U-NAPTR process, not the output of that process
   [RFC3958], [RFC4848].  As a result, the results of DNS queries do not
   need integrity protection.

It should say:

|  The domain name that is used to authenticate the LIS is the domain
   name input to the U-NAPTR process, not the output of that process
   [RFC3958], [RFC4848].  As a result, the results of DNS queries do not
   need integrity protection.

Notes:

Rationale: missing verb: "is"

RFC 5988, "Web Linking", October 2010

Note: This RFC has been obsoleted by RFC 8288

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 3158
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2012-03-19
Held for Document Update by: Peter Saint-Andre

Section 5. says:

  Link           = "Link" ":" #link-value
  link-value     = "<" URI-Reference ">" *( ";" link-param )
  link-param     = ( ( "rel" "=" relation-types )
                 | ( "anchor" "=" <"> URI-Reference <"> )
                 | ( "rev" "=" relation-types )
                 | ( "hreflang" "=" Language-Tag )
                 | ( "media" "=" ( MediaDesc | ( <"> MediaDesc <"> ) ) )
                 | ( "title" "=" quoted-string )
                 | ( "title*" "=" ext-value )
                 | ( "type" "=" ( media-type | quoted-mt ) )
                 | ( link-extension ) )
  link-extension = ( parmname [ "=" ( ptoken | quoted-string ) ] )
                 | ( ext-name-star "=" ext-value )
  ext-name-star  = parmname "*" ; reserved for RFC2231-profiled
                                ; extensions.  Whitespace NOT
                                ; allowed in between.
  ptoken         = 1*ptokenchar
  ptokenchar     = "!" | "#" | "$" | "%" | "&" | "'" | "("
                 | ")" | "*" | "+" | "-" | "." | "/" | DIGIT
                 | ":" | "<" | "=" | ">" | "?" | "@" | ALPHA
                 | "[" | "]" | "^" | "_" | "`" | "{" | "|"
                 | "}" | "~"
  media-type     = type-name "/" subtype-name
  quoted-mt      = <"> media-type <">
  relation-types = relation-type
                 | <"> relation-type *( 1*SP relation-type ) <">
  relation-type  = reg-rel-type | ext-rel-type
  reg-rel-type   = LOALPHA *( LOALPHA | DIGIT | "." | "-" )
  ext-rel-type   = URI

Notes:

The ABNF special cases the value syntax for each predefined parameter name, and furthermore, introduces a quoted-string-like notation without using the RFC2616/httpbis quoted-string syntax.

This is confusing in that

- parsing of parameter values depends on the parameter names
- some of the time double quotes indicate quoted-string syntax, sometimes not
- sometimes only one variant (token vs quoted-string) is allowed, although a generic parser will accept both

This is in conflict with a recommendation in HTTPbis Part 2 (<http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-19#section-3.1>), and also does not reflect reality (see, for instance, <http://greenbytes.de/tech/tc/httplink/#simplecsstitletok>).

The ABNF should be simplified so that all parameters take both token and quoted-string, and that any additional syntactical constraints apply to quoted-string after undoing q-s escaping.

Errata ID: 2630
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2010-11-13
Held for Document Update by: Peter Saint-Andre

Section 5 says:

  ext-name-star  = parmname "*" ; reserved for RFC2231-profiled
                                ; extensions.  Whitespace NOT
                                ; allowed in between.

It should say:

  ext-name-star  = parmname "*" ; reserved for RFC5987-profiled
                                ; extensions.  Whitespace NOT
                                ; allowed in between.

Notes:

RFC5987 clarifies RFC2231 for use in HTTP. The update in RFC5988 left two mentions of RFC2231 which should be updated.

Errata ID: 2631
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2010-11-13
Held for Document Update by: Peter Saint-Andre

Section 5 says:

   The example below shows an instance of the Link header encoding
   multiple links, and also the use of RFC 2231 encoding to encode both
   non-ASCII characters and language information.

It should say:

   The example below shows an instance of the Link header encoding
   multiple links, and also the use of RFC 5987 encoding to encode both
   non-ASCII characters and language information.

Notes:

RFC5987 clarifies RFC2231 for use in HTTP. The update in RFC5988 left two mentions of RFC2231 which should be updated.

Errata ID: 3075
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Klensin
Date Reported: 2012-01-04
Held for Document Update by: Peter Saint-Andre

Section 8 says:

none - suggestion below is an addition 

It should say:

Add a new paragraph:

Note that registered Relation Names are required to be lower-case ASCII letters.

Notes:

This is not important, but a useful placeholder for any future revision.

One can determine the above by tracing back through the ABNF to RFC 2616 and examine the LOALPHA production there. But, to prevent confusion, an "Internationalization Considerations" section should probably call out ASCII restrictions explicitly. One could, as an alternative, include that information under "IANA Considerations" for new registrations (Section 6.2.1 of the present version), but I believe it should be explicitly noted somewhere in this document.

RFC 5990, "Use of the RSA-KEM Key Transport Algorithm in the Cryptographic Message Syntax (CMS)", September 2010

Source of RFC: smime (sec)

Errata ID: 2529
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-09-23
Held for Document Update by: Tim Polk

Section 4, pg.9 says:

   Within the CMS, algorithms are identified by object identifiers
|  (OIDs).  With one exception, all of the OIDs used in this document
   were assigned in other IETF documents, in ISO/IEC standards
   documents, by the National Institute of Standards and Technology
   (NIST), and in Public-Key Cryptography Standards (PKCS) documents.
   The two exceptions are the ASN.1 module's identifier (see Appendix
|  B.3) and id-rsa-kem that are both assigned in this document.  The
|  module object identifiers are defined in an arc delegated by the
   former company RSA Data Security Inc. to the S/MIME Working Group.
   When the S/MIME Working Group closes, this arc and its registration
   procedures will be transferred to IANA.

It should say:

   Within the CMS, algorithms are identified by object identifiers
|  (OIDs).  With two exceptions, all of the OIDs used in this document
   were assigned in other IETF documents, in ISO/IEC standards
   documents, by the National Institute of Standards and Technology
   (NIST), and in Public-Key Cryptography Standards (PKCS) documents.
   The two exceptions are the ASN.1 module's identifier (see Appendix
|  B.3) and id-rsa-kem that are both assigned in this document.  Both
|  object identifiers are defined in an arc delegated by the
   former company RSA Data Security Inc. to the S/MIME Working Group.
   When the S/MIME Working Group closes, this arc and its registration
   procedures will be transferred to IANA.

Notes:

Rationale:
Alignment with Appendix B: _two_ exceptions, both from same arc.

RFC 5997, "Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol", August 2010

Source of RFC: radext (sec)

Errata ID: 2507
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-09-01
Held for Document Update by: Dan Romascanu

Section 3, pg.9 says:

[[  last paragraph on page 9 (extending to page 10): ]]

|  The Access-Accept MAY contain a Reply-Message or Message-
   Authenticator attribute.  It SHOULD NOT contain other attributes.
   The Accounting-Response packets sent in response to a Status-Server
   query SHOULD NOT contain any attributes.  [...]

It should say:

|  The Access-Accept sent in response to a Status-Server query MAY
   contain a Reply-Message or Message-Authenticator attribute.  It
   SHOULD NOT contain other attributes.
   The Accounting-Response packets sent in response to a Status-Server
   query SHOULD NOT contain any attributes.  [...]

Notes:

Rationale: Bare "Access-Accept" is potentially misleading.
The clause needed to properly restrict the scope of the sentence
has been added in most similar instances of specification text
in the RFC, but that has been missed here. So for consistency and
clarity, the New text once more provides this additional clause --
as it already appears in the 3rd sentence of this paragraph.

Errata ID: 2508
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-09-01
Held for Document Update by: Dan Romascanu

Section 4.6.2, pg.17 says:

4.6.2.  Interaction with RADIUS Client MIB Modules

   Clients implementing Status-Server MUST NOT increment [RFC4668] or
   [RFC4670] counters upon reception of Response packets to Status-
|  Server queries.  That is, when a server fully implements Status-
   Server, the counters defined in [RFC4668] and [RFC4670] MUST be
   unaffected by the transmission or reception of packets relating to
   Status-Server.

It should say:

4.6.2.  Interaction with RADIUS Client MIB Modules

   Clients implementing Status-Server MUST NOT increment [RFC4668] or
   [RFC4670] counters upon reception of Response packets to Status-
|  Server queries.  That is, when a client fully implements Status-
   Server, the counters defined in [RFC4668] and [RFC4670] MUST be
   unaffected by the transmission or reception of packets relating to
   Status-Server.

Notes:

Rationale: Confusion between "server" and "client".
This section deals with client implementations only;
the reference to a server apparently is the result of an
oversight in copy-editing text from Section 4.6.1, 2nd para.

RFC 6006, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths", September 2010

Note: This RFC has been obsoleted by RFC 8306

Source of RFC: pce (rtg)

Errata ID: 3836
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Udayasree
Date Reported: 2013-12-13
Held for Document Update by: Adrian Farrel
Date Held: 2013-12-13

Section 3.13 says:

The F-bit is used in the RP object header 
to signal that the initial request or response was too large
to fit into a single message and will be fragmented into multiple
messages. 

It should say:

The F-bit is used in the RP object
to signal that the initial request or response was too large
to fit into a single message and will be fragmented into multiple
messages.  

Notes:

F-bit is used in the RP object body but not the object header

RFC 6016, "Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs", October 2010

Source of RFC: tsvwg (wit)

Errata ID: 2557
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-10-12
Held for Document Update by: Lars Eggert

Section 4, pg. 15 says:

[[ last paragraph of Section 4 ]]

   To achieve effective admission control in the backbone, there needs
   to be some way to separate the data-plane traffic that has a
   reservation from that which does not.  We assume that packets that
   are subject to admission control on the core will be given a
|  particular MPLS EXP value, and that no other packets will be allowed
   to enter the core with this value unless they have passed admission
   control.  Some fraction of link resources will be allocated to queues
|  on core links for packets bearing that EXP value, and the MPLS-TE
   tunnels will use that resource pool to make their constraint-based
   routing and admission control decisions.  This is all consistent with
   the principles of aggregate RSVP reservations described in [RFC3175].

It should say:

   To achieve effective admission control in the backbone, there needs
   to be some way to separate the data-plane traffic that has a
   reservation from that which does not.  We assume that packets that
   are subject to admission control on the core will be given a
|  particular MPLS Traffic Class value, and that no other packets will
   be allowed to enter the core with this value unless they have passed
   admission control.  Some fraction of link resources will be allocated
|  to queues on core links for packets bearing that Traffic Class value,
   and the MPLS-TE tunnels will use that resource pool to make their
   constraint-based routing and admission control decisions.  This is
   all consistent with the principles of aggregate RSVP reservations
   described in [RFC3175].

5

Notes:

Rationale: s/EXP/Traffic Class/ !
RFC 5462 has carefully changed the terminology and updated numerous
RFCs; it has given a detailed explantion why this needs to be done
consistently and confirmed that all future RFCs should unconditionally
use the updated terms.
(See also EID 2547 for RFC 5994.)

Errata ID: 2559
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-10-12
Held for Document Update by: Lars Eggert

Section 8.5, pg.25/2 says:

a) [[ on mid-page 25: ]]

|  The Reserved field MUST be set to zero on transmit and ignored on
   receipt.

b) [[ last paragraph of the section, on page 26: ]]

|  The Reserved field MUST be set to zero on transmit and ignored on
   receipt.

It should say:

a) and b)

|  The Reserved fields MUST be set to zero on transmit and ignored on
   receipt.

Notes:

Rationale:
a) There are _two_ Reserved fields in the AGGREGATE-VPN-IPv{4|6}
SESSION objects, as shown in the preceding artwork in the RFC;
the said treatment applies to both.
b) dto. for the GENERIC-AGGREGATE-VPN-IPv{4|6} SESSION objects.

Errata ID: 2561
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-10-12
Held for Document Update by: Lars Eggert

Section 8.7,pg.27/28 says:

|  The usage of Aggregated VPN-IPv4 FILTER_SPEC object is described in
|  Section 7.3.  The AGGREGATE-VPN-IPv4 FILTER_SPEC object appears in
|  RSVP messages that ordinarily contain a AGGREGATE-IPv4 FILTER_SPEC
   object as defined in [RFC3175] and [RFC4860], and are sent between
   ingress PE and egress PE in either direction.  These objects MUST NOT
   be included in any RSVP messages that are sent outside of the
   provider's backbone (except in the inter-AS Option-B and Option-C
|  cases, as described above, when it may appear on inter-AS links).

   The processing rules for these objects are otherwise identical to
|  those of the VPN-IPv4 FILTER_SPEC object defined in Section 8.3.  The
   format of the object is as follows:

It should say:

|  The usage of the Aggregated VPN-IPv4 FILTER_SPEC object is described
|  in Section 7.3.  The AGGREGATE-VPN-IPv4 (or AGGREGATE-VPN-IPv6)
   FILTER_SPEC object appears in RSVP messages that ordinarily contain
|  an AGGREGATE-IPv4 (respectively, AGGREGATE-IPv6) FILTER_SPEC object
   as defined in [RFC3175] and [RFC4860], and are sent between ingress
   PE and egress PE in either direction.  These objects MUST NOT be
   included in any RSVP messages that are sent outside of the provider's
   backbone (except in the inter-AS Option-B and Option-C cases, as
|  described above, when they may appear on inter-AS links).

   The processing rules for these objects are otherwise identical to
|  those of the VPN-IPv4 and VPN-IPv6 FILTER_SPEC objects defined in
   Section 8.3.  The format of the object is as follows:

Notes:

Rationale:
a) missing article
b) incomplete specification; the use of "These objects" as well as the
references to two different RFCs (one for the IPv4 case, one for the
IPv6 case) are strong indications that this text should be phrased
in a similar manner as in preceding subsections of Section 8, i.e.
it should include mention of the equivalent object for the IPv6 case
as well (this qualifies the Errata Note as Technical);
c) s/a AGGREGATE/an AGGREGATE/
d) singular/plural mismatch: s/it/they/ .

Errata ID: 2554
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-10-12
Held for Document Update by: Lars Eggert

Section Abstract says:

   RFC 4364 and RFC 4659 define an approach to building provider-
   provisioned Layer 3 VPNs (L3VPNs) for IPv4 and IPv6.  It may be
|  desirable to use Resource Reservation Protocol (RSVP) to perform
   admission control on the links between Customer Edge (CE) routers and
   Provider Edge (PE) routers.  [...]

It should say:

   RFC 4364 and RFC 4659 define an approach to building provider-
   provisioned Layer 3 VPNs (L3VPNs) for IPv4 and IPv6.  It may be
|  desirable to use the Resource Reservation Protocol (RSVP) to perform
   admission control on the links between Customer Edge (CE) routers and
   Provider Edge (PE) routers.  [...]

Notes:

Rationale: Missing article

Errata ID: 2555
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-10-12
Held for Document Update by: Lars Eggert

Section 3.2,1st para says:

   When a Path message arrives at the ingress PE (step 3 of Section 2.1)
   the PE needs to establish suitable Path state and forward the Path
   message on to the egress PE.  In the following paragraphs, we
|  described the steps taken by the ingress PE.

It should say:

   When a Path message arrives at the ingress PE (step 3 of Section 2.1)
   the PE needs to establish suitable Path state and forward the Path
   message on to the egress PE.  In the following paragraphs, we
|  describe the steps taken by the ingress PE.

Notes:

Rationale: inappropriate past tense; should be present tense.

Errata ID: 2556
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-10-12
Held for Document Update by: Lars Eggert

Section 3.5, pg.13 says:

   Upon receiving a Resv message at the ingress PE (step 8 of
|  Section 2.1) with respect to data flow (i.e., PE1 in Figure 1), the
   PE determines the local VRF context and associated Path state for
   this Resv by decoding the received SESSION and FILTER_SPEC objects.
   [...]

It should say:

   Upon receiving a Resv message at the ingress PE (step 8 of
|  Section 2.1) with respect to the data flow (i.e., PE1 in Figure 1),
   the PE determines the local VRF context and associated Path state for
   this Resv by decoding the received SESSION and FILTER_SPEC objects.
   [...]

Notes:

Rationale: missing article; cf. other parts of the document.

Errata ID: 2560
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-10-12
Held for Document Update by: Lars Eggert

Section 8.6, pg.26 says:

|  The usage of Aggregated VPN-IPv4 (or VPN-IPv6) SENDER_TEMPLATE object
   is described in Section 7.3.  [...]

It should say:

|  The usage of the Aggregated VPN-IPv4 (or VPN-IPv6) SENDER_TEMPLATE
   object is described in Section 7.3.  [...]

Notes:

Rationale: missing article (as in EID=2558)

RFC 6020, "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", October 2010

Source of RFC: netmod (ops)

Errata ID: 3834
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Chris LaBauve
Date Reported: 2013-12-12
Held for Document Update by: Benoit Claise
Date Held: 2013-12-13

Section 9.7.5 says:

    Given the following leaf:

     leaf mybits {
         type bits {
             bit disable-nagle {
                 position 0;
             }
             bit auto-sense-speed {
                 position 1;
             }
             bit 10-Mb-only {
                 position 2;
             }
         }
         default "auto-sense-speed";
     }

   The lexical representation of this leaf with bit values disable-nagle
   and 10-Mb-only set would be:

     <mybits>disable-nagle 10-Mb-only</mybits>

It should say:

    Given the following leaf:

     leaf mybits {
         type bits {
             bit disable-nagle {
                 position 0;
             }
             bit auto-sense-speed {
                 position 1;
             }
             bit ten-Mb-only {
                 position 2;
             }
         }
         default "auto-sense-speed";
     }

   The lexical representation of this leaf with bit values disable-nagle
   and ten-Mb-only set would be:

     <mybits>disable-nagle ten-Mb-only</mybits>

Notes:

9.7.5. Shows a usage example of the bit statement wherein the identifier '10-Mb-only' begins with a digit, which contradicts the ABNF rule 'identifier' (identifier must begin with [_A-Za-z])

RFC 6026, "Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE Requests", September 2010

Source of RFC: sipcore (rai)

Errata ID: 2536
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Takao Collier
Date Reported: 2010-09-30
Held for Document Update by: Robert Sparks

Section 7.2 says:

   +-----------+                        +-----------+
   |           |                        |           |
   |  Calling  |                        |  Calling  |
   |           |----------->+           |           |-----------+
   +-----------+ 2xx        |           +-----------+ 2xx       |
                 2xx to TU  |                         2xx to TU |
                            |                                   |
                            |                                   |

It should say:

   BEFORE                               AFTER

   +-----------+                        +-----------+
   |           |                        |           |
   |  Calling  |                        |  Calling  |
   |           |----------->+           |           |-----------+
   +-----------+ 2xx        |           +-----------+ 2xx       |
                 2xx to TU  |                         2xx to TU |
                            |                                   |
                            |                                   |

Notes:

Figures 1 and 2 contain "BEFORE" and "AFTER" labels for their respective state machines. Figure 3 does not contain a "BEFORE" and "AFTER" label. Although it's pretty obvious from the context that the left-side is the "BEFORE" case and the right-side is the "AFTER" case, I believe for consistency (and to make it explicit), Figure 3 should contain "BEFORE" and "AFTER" labels.

RFC 6035, "Session Initiation Protocol Event Package for Voice Quality Reporting", November 2010

Source of RFC: sipping (rai)

Errata ID: 3375
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Henning Christiansen
Date Reported: 2012-10-09
Held for Document Update by: Robert Sparks

Section 4.7.2 says:

CSeq: 4331 PUBLISH

It should say:

CSeq: 4331 NOTIFY

Notes:

The message format for the NOTIFY message (F13) seems to contain an invalid CSeq header.

RFC 6036, "Emerging Service Provider Scenarios for IPv6 Deployment", October 2010

Note: This RFC has been obsoleted by RFC 9386

Source of RFC: v6ops (ops)

Errata ID: 2585
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Brian Carpenter
Date Reported: 2010-10-27
Held for Document Update by: ron bonica

Section 2.5 says:

   84% support or plan DNS Authentication, Authorization, Accounting,
   and Auditing (AAAA) queries over IPv6, and all but one of these
   include reverse DNS lookup for IPv6.

It should say:

   84% support or plan DNS AAAA queries over IPv6, and all but one of
   these include reverse DNS lookup for IPv6.

Notes:

AAAA is not an acronym in this context; it is an RR type.

RFC 6038, "Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features", October 2010

Source of RFC: ippm (ops)

Errata ID: 4258
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Huck Zhao
Date Reported: 2015-02-04
Held for Document Update by: Spencer Dawkins
Date Held: 2016-01-13

Section 4.3 says:

Last bullet on Page 8:
Section 4.1.2 defines...

It should say:

Section 5.1.2 defines...

Notes:

(There's actually not a section 4.1.2 in this RFC)

Errata ID: 4259
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Huck Zhao
Date Reported: 2015-02-04
Held for Document Update by: Spencer Dawkins
Date Held: 2016-01-13

Section 5.2 says:

o  Symmetrical Size mode: The Session-Reflector MUST operate using
      the Session_Reflector Packet Format defined in Section 5.1.4,
      where the Padding Octets are separated from the information
      fields.

Section 5.1.4 defines Session_Sender Packet Format.

It should say:

o  Symmetrical Size mode: The Session-Reflector MUST operate using
      the Session_Sender Packet Format defined in Section 5.1.4,
      where the Padding Octets are separated from the information
      fields.

Notes:

This is just dropping a sentence that repeats what was just said previously.

RFC 6055, "IAB Thoughts on Encodings for Internationalized Domain Names", February 2011

Source of RFC: IAB

Errata ID: 3296
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Martin Dürst
Date Reported: 2012-07-26
Held for Document Update by: IAB-Chair

Section 8.2. says:

   [MJD]            Duerst, M., "The Properties and Promizes of UTF-8",
                    11th International Unicode Conference, San Jose ,
                    September 1997, <http://www.ifi.unizh.ch/mml/
                    mduerst/papers/PDF/IUC11-UTF-8.pdf>.

It should say:

   [MJD]            Duerst, M., "The Properties and Promizes of UTF-8",
                    11th International Unicode Conference, San Jose ,
                    September 1997, <http://www.sw.it.aoyama.ac.jp/2012/
                    pub/IUC11-UTF-8.pdf>.

Notes:

The Web site of the University of Zurich (my employer at the time of writing this paper) has been reorganized last year. I finally managed to retreive a copy of the paper and make it available again, at http://www.sw.it.aoyama.ac.jp/2012/pub/IUC11-UTF-8.pdf. It should be available there for the next 15-20 years.

RFC 6062, "Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations", November 2010

Source of RFC: behave (tsv)

Errata ID: 3469
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nazmus Shakeeb
Date Reported: 2013-01-23
Held for Document Update by: Martin Stiemerling
Date Held: 2013-09-30

Section 5.2. says:

The server MUST buffer any data received from the client.

It should say:

The server MUST buffer any data received from the peer.

Notes:

It is solely a typo, i.e., client is replaced by peer.

RFC 6063, "Dynamic Symmetric Key Provisioning Protocol (DSKPP)", December 2010

Source of RFC: keyprov (sec)

Errata ID: 2697
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2011-01-31
Held for Document Update by: Tim Polk

Section 3.4.1.1 says:

   Assume that the raw Client ID value or the value entered by the use
   is: myclient!ID

It should say:

   Assume that the raw Client ID value or the value entered by the use
   is: myclient!D

Notes:

Erroneously entered an extra character "I" into Client ID value.

Errata ID: 2725
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2011-02-18
Held for Document Update by: Tim Polk

Section 7.2.2 says:

   To handle content negotiation, HTTP requests MAY include an HTTP
   Accept header field.  This header field SHOULD should be identified
   using the MIME type specified in Section 7.2.1.  The Accept header
   MAY include additional content types defined by future versions of
   this protocol.

It should say:

   To handle content negotiation, HTTP requests MAY include an HTTP
   Accept header field.  This header field SHOULD be identified
   using the MIME type specified in Section 7.2.1.  The Accept header
   MAY include additional content types defined by future versions of
   this protocol.

Notes:

Double "should"

RFC 6068, "The 'mailto' URI Scheme", October 2010

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 3265
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Levine
Date Reported: 2012-06-23
Held for Document Update by: Barry Leiba

Section 11.1 says:

  [RFC5322]  Resnik, P.,

It should say:

  [RFC5322]  Resnick, P.,

Notes:

Pete Resnick's name spelled wrong. Oops.

RFC 6083, "Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)", January 2011

Note: This RFC has been updated by RFC 8996

Source of RFC: tsvwg (wit)

Errata ID: 5744
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Sidhartha Pant
Date Reported: 2019-05-30
Held for Document Update by: Martin Duke
Date Held: 2020-04-21

Section 4.8 says:

4.8.  Handling of Endpoint-Pair Shared Secrets

   The endpoint-pair shared secret for Shared Key Identifier 0 is empty
   and MUST be used when establishing a DTLS connection.  Whenever the
   master key changes, a 64-byte shared secret is derived from every
   master secret and provided as a new endpoint-pair shared secret by
   using the exporter described in [RFC5705].  The exporter MUST use the
   label given in Section 5 and no context.  The new Shared Key
   Identifier MUST be the old Shared Key Identifier incremented by 1.
   If the old one is 65535, the new one MUST be 1.

   Before sending the Finished message, the active SCTP-AUTH key MUST be
   switched to the new one.

   Once the corresponding Finished message from the peer has been
   received, the old SCTP-AUTH key SHOULD be removed.

It should say:

4.8.  Handling of Endpoint-Pair Shared Secrets

   The endpoint-pair shared secret for Shared Key Identifier 0 is empty
   and MUST be used when establishing a DTLS connection.  Whenever the
   master key changes, a 64-byte shared secret is derived from every
   master secret and provided as a new endpoint-pair shared secret by
   using the exporter described in [RFC5705].  The exporter MUST use the
   label given in Section 5 and no context.  The new Shared Key
   Identifier MUST be the old Shared Key Identifier incremented by 1.
   If the old one is 65535, the new one MUST be 1.

   Before sending the Finished message, the active SCTP-AUTH key 
   SHOULD be switched to the new one.
   However if the ChangeCipherSpec and Finished messages are sent 
   back to back, there may be a case if Finished message is sent with
   the new key might get dropped by peer, if the new key is not 
   configured yet.
   Hence the sender MAY send the Finished message with Old Key which
   SHOULD be accepted by the peer. 

   Once the corresponding Finished message from the peer has been
   received, the old SCTP-AUTH key SHOULD be removed.

Notes:

If the time gap between the ChangeCipherSpec and Finished messages is very less than either the peer may wait to configure the new key received in ChangeCipherSpec and then validate the Finished messges with new key. Alternatively the Sender may choose to send the Finished message with Old key to peer which should still be configured at the peer. Once the peer recevies the Finished message it should accept with Old key. Subsequently the Old key Should be removed.
Hence during this switchover of Key , two keys can be used by both peer nodes.

RFC 6086, "Session Initiation Protocol (SIP) INFO Method and Package Framework", January 2011

Source of RFC: sipcore (rai)

Errata ID: 3167
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Dale Worley
Date Reported: 2012-03-26
Held for Document Update by: Robert Sparks

Section 12.2.2 says:

12.2.2.1.  Non-Info Package Body Part

   INFO sip:alice@pc33.example.com SIP/2.0
   Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef
   To: Alice <sip:alice@example.net>;tag=1234567
   From: Bob <sip:bob@example.com>;tag=abcdefg
   Call-Id: a84b4c76e66710@pc33.example.com
   CSeq: 314400 INFO
   Info-Package: foo
   Content-Type: multipart/mixed;boundary="theboundary"
   Content-Length: ...

   --theboundary
   Content-Type: application/mumble
   ...

   <mumble stuff>

   --theboundary
   Content-Type: application/foo-x
   Content-Disposition: Info-Package
>>>Content-length: 59

   I am a foo-x message type, and I belong to Info Package foo
   --theboundary--

12.2.2.2.  Info Package with Multiple Body Parts inside Multipart Body
           Part

   INFO sip:alice@pc33.example.com SIP/2.0
   Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef
   To: Alice <sip:alice@example.net>;tag=1234567
   From: Bob <sip:bob@example.com>;tag=abcdefg
   Call-Id: a84b4c76e66710@pc33.example.com
   CSeq: 314423 INFO
   Info-Package: foo
   Content-Type: multipart/mixed;boundary="theboundary"
   Content-Disposition: Info-Package
   Content-Length: ...

   --theboundary
   Content-Type: application/foo-x
>>>Content-length: 59

   I am a foo-x message type, and I belong to Info Package foo

   <mumble stuff>

   --theboundary
   Content-Type: application/foo-y
>>>Content-length: 59

   I am a foo-y message type, and I belong to Info Package foo
   --theboundary--

12.2.2.3.  Info Package with Single Body Part inside Multipart Body Part

   INFO sip:alice@pc33.example.com SIP/2.0
   Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef
   To: Alice <sip:alice@example.net>;tag=1234567
   From: Bob <sip:bob@example.com>;tag=abcdefg
   Call-Id: a84b4c76e66710@pc33.example.com
   CSeq: 314423 INFO
   Info-Package: foo
   Content-Type: multipart/mixed;boundary="theboundary"
   Content-Disposition: Info-Package
   Content-Length: ...

   --theboundary
   Content-Type: application/foo-x
   Content-Disposition: icon
>>>Content-length: 59

   I am a foo-x message type, and I belong to Info Package foo
   --theboundary--

It should say:

12.2.2.1.  Non-Info Package Body Part

   INFO sip:alice@pc33.example.com SIP/2.0
   Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef
   To: Alice <sip:alice@example.net>;tag=1234567
   From: Bob <sip:bob@example.com>;tag=abcdefg
   Call-Id: a84b4c76e66710@pc33.example.com
   CSeq: 314400 INFO
   Info-Package: foo
   Content-Type: multipart/mixed;boundary="theboundary"
   Content-Length: ...

   --theboundary
   Content-Type: application/mumble
   ...

   <mumble stuff>

   --theboundary
   Content-Type: application/foo-x
   Content-Disposition: Info-Package

   I am a foo-x message type, and I belong to Info Package foo
   --theboundary--

12.2.2.2.  Info Package with Multiple Body Parts inside Multipart Body
           Part

   INFO sip:alice@pc33.example.com SIP/2.0
   Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef
   To: Alice <sip:alice@example.net>;tag=1234567
   From: Bob <sip:bob@example.com>;tag=abcdefg
   Call-Id: a84b4c76e66710@pc33.example.com
   CSeq: 314423 INFO
   Info-Package: foo
   Content-Type: multipart/mixed;boundary="theboundary"
   Content-Disposition: Info-Package
   Content-Length: ...

   --theboundary
   Content-Type: application/foo-x

   I am a foo-x message type, and I belong to Info Package foo

   <mumble stuff>

   --theboundary
   Content-Type: application/foo-y

   I am a foo-y message type, and I belong to Info Package foo
   --theboundary--

12.2.2.3.  Info Package with Single Body Part inside Multipart Body Part

   INFO sip:alice@pc33.example.com SIP/2.0
   Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef
   To: Alice <sip:alice@example.net>;tag=1234567
   From: Bob <sip:bob@example.com>;tag=abcdefg
   Call-Id: a84b4c76e66710@pc33.example.com
   CSeq: 314423 INFO
   Info-Package: foo
   Content-Type: multipart/mixed;boundary="theboundary"
   Content-Disposition: Info-Package
   Content-Length: ...

   --theboundary
   Content-Type: application/foo-x
   Content-Disposition: icon

   I am a foo-x message type, and I belong to Info Package foo
   --theboundary--

Notes:

In four locations (in three examples), a Content-Length header is shown for a multipart body-part. But comparing with RFC 1521 section 7.2, Content-Length has no defined meaning within MIME, and it appears that any appearance in a body-part header must be ignored. Thus, these headers are meaningless, and the authors would probably not have included them if they had researched the subject.

(Bruno Chatras discovered this discrepancy.)

RFC 6090, "Fundamental Elliptic Curve Cryptography Algorithms", February 2011

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 2777
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Annie Yousar
Date Reported: 2011-04-11
Held for Document Update by: Sean Turner

Section 7.2 says:

KT-I is mathematically and functionally equivalent to ECDSA, and can interoperate
with the IEEE [P1363] and ANSI [X9.62] standards for Elliptic Curve DSA (ECDSA)
based on fields of characteristic greater than three.  KT-I signatures can be
verified using the ECDSA verification algorithm, and ECDSA signatures can be
verified using the KT-I verification algorithm.

It should say:

For many hash functions KT-I is mathematically and functionally equivalent to
ECDSA, and can interoperate with the IEEE [P1363] and ANSI [X9.62] standards for
Elliptic Curve DSA (ECDSA) based on fields of characteristic greater than three.
KT-I signatures can be verified using the ECDSA verification algorithm, and ECDSA
signatures can be verified using the KT-I verification algorithm (refer to
Section 10.4).

Notes:

If the hash function h generates a bit string that has a bit length greater than the bit length of the elliptic curve group order, ECDSA as specified in P1363 uses a truncation of the hash value to the left-most bits. The KT-I algorithm does not use this truncation but reduces modulo q. Therefore ECDSA and KT-I with SHA-384 on the P-256 curve result in different signature values. Add a corresponding note in 10.4: The output of the hash used in KT signatures should truncated to the left-most bits if its bit-length is longer than the bit-length of the group order.

Errata ID: 2773
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Annie Yousar
Date Reported: 2011-04-11
Held for Document Update by: Sean Turner

Section 2.2 says:

Sometimes an alternative called additive notation is used, 
in which a * b is denoted as a + b, and a^N is denoted as N * a. 

It should say:

Sometimes an alternative called additive notation is used, 
in which a * b is denoted as a + b, and a^N is denoted as Na. 

Notes:

The original text refers to Appendix E some sentences later:
"Appendix E elucidates the correspondence between the two notations."

In the Appendix E the notation "Na" is used, whereas the original text uses the notation "N*a".

Errata ID: 2774
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Annie Yousar
Date Reported: 2011-04-11
Held for Document Update by: Sean Turner

Section 2.2 says:

By convention, a^0 is equal to the identity element for any a in G.

It should say:

By convention, a^0 is equal to the identity element and a^1 is equal to a itself for any a in G.

Notes:

Without this convention the explanation on the next page: "... for any integers X and Y: a^(X+Y) = (a^X)*(a^Y) ..." would be incomplete, as being undefined for the integers X=1 and/or Y=1.

Errata ID: 2775
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Annie Yousar
Date Reported: 2011-04-11
Held for Document Update by: Sean Turner

Section 2.2 says:

Note that a^M is equal to g^(M modulo R) for any non-negative integer M.

It should say:

Note that a^M is equal to a^(M mod R) for any non-negative integer M.

Notes:

g is a typo. The result of the modulo operation is always denoted in the text by "mod". The notation "modulo" identifies the operation and not the result.

Errata ID: 2776
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Annie Yousar
Date Reported: 2011-04-11
Held for Document Update by: Sean Turner

Section 6.2 says:

The integer x shall be converted to an octet string S of length k as follows.  The string S shall satisfy
                      k
                y =  SUM  2^(8(k-i)) Si .
                    i = 1

It should say:

The integer y shall be converted to an octet string S of length k as follows.  The string S shall satisfy
                      k
                y =  SUM  2^(8(k-i)) Si .
                    i = 1

Note that the conversion fails if y >= 2^(8*k).

Notes:

Typo corrected. The integer y can not be converted, if the octet string is to short.

RFC 6092, "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", January 2011

Source of RFC: v6ops (ops)

Errata ID: 6979
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Tomoyuki Sahara
Date Reported: 2022-05-23
Held for Document Update by: Warren Kumari (Ops AD)
Date Held: 2023-08-31

Section 3.1 says:

   REC-9: Inbound DHCPv6 discovery packets [RFC3315] received on
   exterior interfaces MUST NOT be processed by any integrated DHCPv6
   server or relay agent.

It should say:

   REC-9: Inbound DHCPv6 Solicit messages [RFC3315] received on
   exterior interfaces MUST NOT be processed by any integrated DHCPv6
   server or relay agent.

Notes:

"discovery" packet, more precisely DHCPDISCOVER message, is defined in DHCPv4 but it is not defined in DHCPv6.
DHCPv6 clients send "Solicit" messages to discover DHCPv6 servers or relay agents.

[WK]: RFC3315 seems to use "discover" and "discovery" in the general sense, but as this recommendation uses RFC2119 MUST NOT language, it seems that being more explicit (Solicit) is more appropriate.

RFC 6107, "Procedures for Dynamically Signaled Hierarchical Label Switched Paths", February 2011

Source of RFC: ccamp (rtg)

Errata ID: 3412
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kris Michielsen
Date Reported: 2012-11-16
Held for Document Update by: Adrian Farrel

Section 3.1.2 says:

           Type (16 bits)

             The identifier of the TLV.  Two type values are defined in
             this document:

             1  IGP Instance Identifier TLV
             2  Unnumbered Component Link Identifier TLV
             3  IPv4 Numbered Component Link Identifier TLV
             4  IPv6 Numbered Component Link Identifier TLV

It should say:

           Type (16 bits)

             The identifier of the TLV.  Four type values are defined in
             this document:

             1  IGP Instance Identifier TLV
             2  Unnumbered Component Link Identifier TLV
             3  IPv4 Numbered Component Link Identifier TLV
             4  IPv6 Numbered Component Link Identifier TLV

Notes:

s/Two/Four/

RFC 6109, "La Posta Elettronica Certificata - Italian Certified Electronic Mail", April 2011

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 4131
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Luigi De Rosa
Date Reported: 2014-10-14
Held for Document Update by: Barry Leiba
Date Held: 2014-10-14

Section 3.22 says:

X-Trasplorto: errore

It should say:

X-Trasporto: errore

Notes:

typo error

RFC 6120, "Extensible Messaging and Presence Protocol (XMPP): Core", March 2011

Note: This RFC has been updated by RFC 7590, RFC 8553

Source of RFC: xmpp (rai)

Errata ID: 4741
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Sam Whited
Date Reported: 2016-07-13
Held for Document Update by: Ben Campbell
Date Held: 2016-07-13

Section 8.2.3 says:

1.  The 'id' attribute is REQUIRED for IQ stanzas.

…

3.  An entity that receives a stanza of type "get" or "set" MUST
    reply with an IQ respones of type "result" or "error".  The
    response MUST preserve the 'id' attribute of the request (or be
    empty if the generated stanza did not include an 'id' attribute).

It should say:

1.  The 'id' attribute is REQUIRED for IQ stanzas.

…

3.  An entity that receives a stanza of type "get" or "set" MUST
    reply with an IQ respones of type "result" or "error".  The
    response MUST preserve the 'id' attribute of the request, or
    send an appropriate error if the generated stanza did not
    include an 'id' attribute.

Notes:

If the received IQ had an empty ID then it was not valid per point 1 and clients and servers cannot key on the ID (eg. for key mapped lists of IQs pending receipt or dispatch of a reply). An appropriate error or other behavior should be defined if the 'id' is meant to be REQUIRED, otherwise, if point 3 is correct, then 'id' should not be REQUIRED.

Errata ID: 2855
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Toby Moncaster
Date Reported: 2011-07-06
Held for Document Update by: Robert Sparks

Section 3.2.1 says:

3. If a response is received, it will contain one or more
combinations of a port and FDQN,

It should say:

3. If a response is received, it will contain one or more
combinations of a port and FQDN,

Notes:

There are multiple occurrences (1 each in list items 3, 4, 5, 6 & 7). All read FDQN and should read FQDN

Errata ID: 3486
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marco Cirillo
Date Reported: 2013-02-18
Held for Document Update by: Gonzalo Camarillo

Section 5.4.1 says:

The receiving entity then MUST send stream features to the initiating
entity.  If the receiving entity supports TLS, the stream features
MUST include an advertisement for support of STARTTLS negotiation,
i.e., a <starttls/> element qualified by the
'urn:ietf:params:xml:ns:xmpp-tls' namespace.

It should say:

The receiving entity then MUST send stream features to the initiating 
entity.  If the receiving entity offers TLS capability, the stream 
features MUST include an advertisement for support of STARTTLS 
negotiation, i.e., a <starttls/> element qualified by the
'urn:ietf:params:xml:ns:xmpp-tls' namespace.

Notes:

Current text mixes up actual support of STARTTLS/TLS (which is mandated by section 5.2) with deployment/availableness of the said.

Errata ID: 3650
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Peter Saint-Andre
Date Reported: 2013-06-12
Held for Document Update by: Richard Barnes
Date Held: 2013-06-13

Section Appendix A.2 says:

  <xs:element name='bad-format' type='empty'/>
  <xs:element name='bad-namespace-prefix' type='empty'/>
  <xs:element name='conflict' type='empty'/>
  <xs:element name='connection-timeout' type='empty'/>
  <xs:element name='host-gone' type='empty'/>
  <xs:element name='host-unknown' type='empty'/>
  <xs:element name='improper-addressing' type='empty'/>
  <xs:element name='internal-server-error' type='empty'/>
  <xs:element name='invalid-from' type='empty'/>
  <xs:element name='invalid-id' type='empty'/>
  <xs:element name='invalid-namespace' type='empty'/>
  <xs:element name='invalid-xml' type='empty'/>
  <xs:element name='not-authorized' type='empty'/>
  <xs:element name='not-well-formed' type='empty'/>
  <xs:element name='policy-violation' type='empty'/>
  <xs:element name='remote-connection-failed' type='empty'/>
  <xs:element name='reset' type='empty'/>
  <xs:element name='resource-constraint' type='empty'/>
  <xs:element name='restricted-xml' type='empty'/>
  <xs:element name='see-other-host' type='xs:string'/>
  <xs:element name='system-shutdown' type='empty'/>
  <xs:element name='undefined-condition' type='empty'/>
  <xs:element name='unsupported-encoding' type='empty'/>
  <xs:element name='unsupported-stanza-type' type='empty'/>
  <xs:element name='unsupported-version' type='empty'/>

  <xs:group name='streamErrorGroup'>
    <xs:choice>
      <xs:element ref='bad-format'/>
      <xs:element ref='bad-namespace-prefix'/>
      <xs:element ref='conflict'/>
      <xs:element ref='connection-timeout'/>
      <xs:element ref='host-gone'/>
      <xs:element ref='host-unknown'/>
      <xs:element ref='improper-addressing'/>
      <xs:element ref='internal-server-error'/>
      <xs:element ref='invalid-from'/>
      <xs:element ref='invalid-id'/>
      <xs:element ref='invalid-namespace'/>
      <xs:element ref='invalid-xml'/>
      <xs:element ref='not-authorized'/>
      <xs:element ref='not-well-formed'/>
      <xs:element ref='policy-violation'/>
      <xs:element ref='remote-connection-failed'/>
      <xs:element ref='reset'/>
      <xs:element ref='resource-constraint'/>
      <xs:element ref='restricted-xml'/>
      <xs:element ref='see-other-host'/>
      <xs:element ref='system-shutdown'/>
      <xs:element ref='undefined-condition'/>
      <xs:element ref='unsupported-encoding'/>
      <xs:element ref='unsupported-stanza-type'/>
      <xs:element ref='unsupported-version'/>
    </xs:choice>
  </xs:group>

It should say:

  <xs:element name='bad-format' type='empty'/>
  <xs:element name='bad-namespace-prefix' type='empty'/>
  <xs:element name='conflict' type='empty'/>
  <xs:element name='connection-timeout' type='empty'/>
  <xs:element name='host-gone' type='empty'/>
  <xs:element name='host-unknown' type='empty'/>
  <xs:element name='improper-addressing' type='empty'/>
  <xs:element name='internal-server-error' type='empty'/>
  <xs:element name='invalid-from' type='empty'/>
  <xs:element name='invalid-namespace' type='empty'/>
  <xs:element name='invalid-xml' type='empty'/>
  <xs:element name='not-authorized' type='empty'/>
  <xs:element name='not-well-formed' type='empty'/>
  <xs:element name='policy-violation' type='empty'/>
  <xs:element name='remote-connection-failed' type='empty'/>
  <xs:element name='reset' type='empty'/>
  <xs:element name='resource-constraint' type='empty'/>
  <xs:element name='restricted-xml' type='empty'/>
  <xs:element name='see-other-host' type='xs:string'/>
  <xs:element name='system-shutdown' type='empty'/>
  <xs:element name='undefined-condition' type='empty'/>
  <xs:element name='unsupported-encoding' type='empty'/>
  <xs:element name='unsupported-feature' type='empty'/>
  <xs:element name='unsupported-stanza-type' type='empty'/>
  <xs:element name='unsupported-version' type='empty'/>

  <xs:group name='streamErrorGroup'>
    <xs:choice>
      <xs:element ref='bad-format'/>
      <xs:element ref='bad-namespace-prefix'/>
      <xs:element ref='conflict'/>
      <xs:element ref='connection-timeout'/>
      <xs:element ref='host-gone'/>
      <xs:element ref='host-unknown'/>
      <xs:element ref='improper-addressing'/>
      <xs:element ref='internal-server-error'/>
      <xs:element ref='invalid-from'/>
      <xs:element ref='invalid-namespace'/>
      <xs:element ref='invalid-xml'/>
      <xs:element ref='not-authorized'/>
      <xs:element ref='not-well-formed'/>
      <xs:element ref='policy-violation'/>
      <xs:element ref='remote-connection-failed'/>
      <xs:element ref='reset'/>
      <xs:element ref='resource-constraint'/>
      <xs:element ref='restricted-xml'/>
      <xs:element ref='see-other-host'/>
      <xs:element ref='system-shutdown'/>
      <xs:element ref='undefined-condition'/>
      <xs:element ref='unsupported-encoding'/>
      <xs:element ref='unsupported-feature'/>
      <xs:element ref='unsupported-stanza-type'/>
      <xs:element ref='unsupported-version'/>
    </xs:choice>
  </xs:group>

Notes:

The "invalid-id" error condition was removed in the changes between RFC 3920 and RFC 6120, but mistakenly not removed from the schema. The "unsupported-feature" error condition was added in the changes between RFC 3920 and RFC 6120, but mistakenly not added to the schema.

This bug was found by Anastasia Gornostaeva.

Implementors using the schema as updated by this erratum should note that if they produce XML that includes the "unsupported-feature" element, then it might be rejected as invalid by implementations using the original schema. Likewise, if they produce XML that includes the "invalid-id" element, then it might be rejected as invalid by implementations following the revised schema.

Errata ID: 3651
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Peter Saint-Andre
Date Reported: 2013-06-12
Held for Document Update by: Richard Barnes

Section 4.9.3.19 says:

"(b) the receiving entity MAY have a policy of following redirects only
if it has authenticated the receiving entity"

It should say:

"(b) the initiating entity MAY have a policy of following redirects only 
if it has authenticated the receiving entity"

Notes:

This bug was found by Yann Leboulanger.

RFC 6121, "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", March 2011

Source of RFC: xmpp (rai)

Errata ID: 5058
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Florian Schmaus
Date Reported: 2017-07-02
Held for Document Update by: Ben Campbell
Date Held: 2017-07-10

Section 2.1.6 says:

   2.  A receiving client MUST ignore the stanza unless it has no 'from'
       attribute (i.e., implicitly from the bare JID of the user's
       account) or it has a 'from' attribute whose value matches the
       user's bare JID <user@domainpart>.

It should say:

   2.  A receiving client MUST ignore the stanza unless it has no 'from'
       attribute (i.e., implicitly from the bare JID of the user's
       account) or it has a 'from' attribute whose value matches either
       the user's bare JID <user@domainpart> or the address of an entity
       authorized performing roster pushes.

Notes:

RFC 6121 § 2.1.6 2. specifies that roster pushes have to origin from the "user's account", i.e., no 'from' attribute or 'from' attribute matching the user's bare JID. However the Security Warning in the same section states that

... this specification allows entities other than the user's server to
maintain roster information, which means that a roster push might
include a 'from' address other than the bare JID of the user's
account. Therefore, the client MUST check the 'from' address to
verify that the sender of the roster push is authorized to update
the roster.

which contradicts what is specified in § 2.1.6 2.

Verifier note: This seems more than editorial, and probably needs some discussion about third party authorizations. I will set the status to "Held for Document Update"

Errata ID: 3391
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Todd Lucas
Date Reported: 2012-10-21
Held for Document Update by: Robert Sparks

Section 4.3.2.1. says:

   Juliet's server replies with an unavailable notification, mirroring
   the 'id' of Rome's presence probe because there is no 'id' to
   preserve from an available notification that her client has sent.

It should say:

   Juliet's server replies with an unavailable notification, mirroring
   the 'id' of Romeo's presence probe because there is no 'id' to
   preserve from an available notification that her client has sent.

Notes:

Minor typo: "Rome's" should be "Romeo's"

RFC 6122, "Extensible Messaging and Presence Protocol (XMPP): Address Format", March 2011

Note: This RFC has been obsoleted by RFC 7622

Source of RFC: xmpp (rai)

Errata ID: 2801
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Florian Zeitz
Date Reported: 2011-05-07
Held for Document Update by: Robert Sparks

Section 2.2 says:

When preparing a text label (consisting of a sequence of UTF-8 encoded
Unicode code points) for representation as an internationalized label
in the process of constructing an XMPP domainpart or comparing two
XMPP domainparts, an application MUST ensure that for each text label
it is possible to apply without failing the ToASCII operation
specified in [IDNA2003] with the UseSTD3ASCIIRules flag set (thus
forbidding ASCII code points other than letters, digits, and
hyphens).

It should say:

When preparing a text label (consisting of a sequence of UTF-8 encoded
Unicode code points) for representation as an internationalized label
in the process of constructing an XMPP domainpart, an application MUST
ensure that for each text label it is possible to apply without failing the
ToASCII operation specified in [IDNA2003] with the UseSTD3ASCIIRules flag set
(thus forbidding ASCII code points other than letters, digits, and hyphens).
When comparing two XMPP domainparts, an application MUST first apply the
[NAMEPREP] profile of [STRINGPREP] to both domainparts and perform a byte-wise
comparison afterwards.

Notes:

As is the RFC does not specify how to compare XMPP domainparts. It should have been pointed out that normalization is required and how to do that normalization.

RFC 6125, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", March 2011

Note: This RFC has been obsoleted by RFC 9525

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 3090
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Jeff Hodges
Date Reported: 2012-01-13
Held for Document Update by: Peter Saint-Andre
Date Held: 2012-02-27

Section 6.4.3 says:

6.4.3. Checking of Wildcard Certificates

   A client employing this specification's rules MAY match the reference
   identifier against a presented identifier whose DNS domain name
   portion contains the wildcard character '*' as part or all of a label
   (following the description of labels and domain names in
   [DNS-CONCEPTS]).

   For information regarding the security characteristics of wildcard
   certificates, see Section 7.2.

   If a client matches the reference identifier against a presented
   identifier whose DNS domain name portion contains the wildcard
   character '*', the following rules apply:

   1.  The client SHOULD NOT attempt to match a presented identifier in
       which the wildcard character comprises a label other than the
       left-most label (e.g., do not match bar.*.example.net).

   2.  If the wildcard character is the only character of the left-most
       label in the presented identifier, the client SHOULD NOT compare
       against anything but the left-most label of the reference
       identifier (e.g., *.example.com would match foo.example.com but
       not bar.foo.example.com or example.com).

   3.  The client MAY match a presented identifier in which the wildcard
       character is not the only character of the label (e.g.,
       baz*.example.net and *baz.example.net and b*z.example.net would
       be taken to match baz1.example.net and foobaz.example.net and
       buzz.example.net, respectively).  However, the client SHOULD NOT
       attempt to match a presented identifier where the wildcard
       character is embedded within an A-label or U-label [IDNA-DEFS] of
       an internationalized domain name [IDNA-PROTO].

It should say:

[ no firm test suggestions just as yet, please see below ]

Notes:

RFC6125 bug: Checking of Wildcard Certs lacks spec of how many labels in presented identifier

section 6.4.3 does not specify how many labels must be in a wildcarded presented identifier. I.e., it leaves open the possibility that the following presented identifiers could be matched against actual domain names..

*
*.
*.com i.e. *.<fill in TLD here> e.g.: *.uk or *.co.uk
*U i.e. *<fill in portion of TLD here> e.g.: will match AU, EDU, CU

etc. etc.


If actual TLS/SSL implementations (e.g. web browsers) were to make valid matches as shown above, then someone could ostensibly obtain a cert (c.f. diginotar) for one of them and then go and MITM large swaths of domain name space.

Note that the discussion of wildcards in Section 7.2 of security considerations identifies the public suffix issue in passing, but only as one of a set of issues why the spec discourages use of wildcard certs.

Note also that this issue begs the question of being able to determine what constitutes a so-called domain name "public suffix" (e.g. ".com", ".co.uk") -- we can't simply write into the spec "the wildcard must be in the left-most label position and there must be at least one? two? three? labels to the right of the wildcard's position".

Likely the approach will need to consist of a "SHOULD" declaration and some hand-waving about how "matching wildcards on presented identifiers with less than N (?) labels to the right of the wildcard has various increasing risks as N approaches zero, and that implementors should perhaps consider leveraging some of the available public suffix identification mechanisms, but that those are out of scope and have their own operational and security considerations."

PSA: This issue needs to be addressed, but doing so by means of an erratum is not the best way to go about having this conversation. Marking as "Hold For Document Update" to make sure we don't lose track of the issue. -- Peter Saint-Andre

RFC 6130, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", April 2011

Note: This RFC has been updated by RFC 7183, RFC 7188, RFC 7466

Source of RFC: manet (rtg)

Errata ID: 4866
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2016-11-15
Held for Document Update by: Alvaro Retana
Date Held: 2017-01-25

Section 4.3.2 says:

   o  For each MANET interface, within every time interval equal to the
      corresponding REFRESH_INTERVAL, sent HELLO messages MUST
      collectively include all of the relevant information in the
      corresponding Link Set and the Neighbor Information Base.  Note
      that when determining whether to include information in a HELLO
      message, the sender MUST consider all times up to the latest time
      when it may send its next HELLO message on this MANET interface.

   o  For each MANET interface, within every time interval equal to the
      corresponding REFRESH_INTERVAL, sent HELLO messages MUST
      collectively include all of the relevant information in the
      corresponding Link Set and the Neighbor Information Base.

It should say:

   o  For each MANET interface, within every time interval equal to the
      corresponding REFRESH_INTERVAL, sent HELLO messages MUST
      collectively include all of the relevant information in the
      corresponding Link Set and the Neighbor Information Base.  Note
      that when determining whether to include information in a HELLO
      message, the sender MUST consider all times up to the latest time
      when it may send its next HELLO message on this MANET interface.

Notes:

The second statement is already contained in the first one.

=====
From Christopher Dearlove (author):

it is the other paragraph that should be deleted. Because the paragraph following the two quoted paragraphs, which I copy here:

o When determining whether to include a given piece of neighbor
information in a HELLO message, it is not sufficient to consider
whether that information has been sent in the interval of length
REFRESH_INTERVAL up to the current time. Instead, the router MUST
consider the interval of length REFRESH_INTERVAL that will end at
the latest possible time at which the next HELLO message will be
sent on this MANET interface. (Normally, this will be
HELLO_INTERVAL past the current time, but MAY be earlier if this
router elects to divide its neighbor information among more than
one HELLO message in order to reduce the size of its HELLO
messages.) All neighbor information MUST be sent in this
interval, i.e., the router MUST ensure that this HELLO message
includes all neighbor information that has not already been
included in any HELLO messages sent since the start of this
interval (normally, the current time - (REFRESH_INTERVAL -
HELLO_INTERVAL)).

contains the additional information in the longer paragraph, expanded to explain what it means.

Thus the resolution is to delete the first paragraph:

OLD:

o For each MANET interface, within every time interval equal to the
corresponding REFRESH_INTERVAL, sent HELLO messages MUST
collectively include all of the relevant information in the
corresponding Link Set and the Neighbor Information Base. Note
that when determining whether to include information in a HELLO
message, the sender MUST consider all times up to the latest time
when it may send its next HELLO message on this MANET interface.

NEW:

Errata ID: 5780
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2019-07-14
Held for Document Update by: Alvaro Retana
Date Held: 2019-07-17

Section F.3 says:

   The content of the Interface Information Base is in this case
   identical to than in Example 1, except that the 2-Hop Set contains an
   extra 2-Hop Tuple with N2_neighbor_iface_addr_list being {2} and
   N2_2hop_addr being {4}.  These two 2-Hop Tuples are illustrated by
   the two lines from {2} to {3} and (2) to {4}, respectively.

It should say:

   The content of the Interface Information Base is in this case
   identical to than in Example 1, except that the 2-Hop Set contains an
   extra 2-Hop Tuple with N2_neighbor_iface_addr_list being {2} and
   N2_2hop_addr being {4}.  These two 2-Hop Tuples are illustrated by
   the two lines from {2} to {3} and {2} to {4}, respectively.

Notes:

Parentheses are mistakenly typed. s/(2)/{2}

Errata ID: 5785
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Steve Matty
Date Reported: 2019-07-18
Held for Document Update by: Alvaro Retana
Date Held: 2019-07-18

Section F.3 says:

The content of the Interface Information Base is in this case
identical to than in Example 1, except that the 2-Hop Set contains an
extra 2-Hop Tuple with N2_neighbor_iface_addr_list being {2} and
N2_2hop_addr being {4}.  These two 2-Hop Tuples are illustrated by
the two lines from {2} to {3} and (2) to {4}, respectively.

It should say:

The content of the Interface Information Base is in this case
identical to that in Example 1, except that the 2-Hop Set contains an
extra 2-Hop Tuple with N2_neighbor_iface_addr_list being {2} and
N2_2hop_addr being {4}.  These two 2-Hop Tuples are illustrated by
the two lines from {2} to {3} and (2) to {4}, respectively.

Notes:

Typo in first sentence. "than" should read "that"

RFC 6145, "IP/ICMP Translation Algorithm", April 2011

Note: This RFC has been obsoleted by RFC 7915

Note: This RFC has been updated by RFC 6791, RFC 7757

Source of RFC: behave (tsv)

Errata ID: 3061
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Gandhar Gokhale
Date Reported: 2011-12-23
Held for Document Update by: Wesley Eddy

Section 5.1.1 says:

   Fragment Offset:  Copied from the Fragment Offset field of the IPv6
      Fragment Header.

It should say:

   Fragment Offset:  If the Next Header field of the Fragment Header is 
      not an extension header (except ESP) then Fragment Offset MUST be 
      copied from the Fragment Offset field of the IPv6 Fragment Header. 
      If the Next Header field of the Fragment Header is an extension 
      header (except ESP) then the packet SHOULD be dropped and logged.

Notes:

If the fragmentable part (as described in RFC 2460) of the original unfragmented IPv6 packet had extension headers then the translator can not calculate the offset of the IPv4 fragment for non-initial fragments. If extension headers are present in the fragmentable part then the fragment offset value of the IPv6 header includes length of the extension headers also. Since translator strips of the IPv6 extension headers the fragment offset value set by the sender of IPv6 fragments can not match that received by the IPv4 receiver and the reassembly will fail. For non-initial fragments the translator does not have the knowledge of this delta when there is no state maintained.

The legth issue stated in erratum 2 is not in itself sufficient to advocate packet drop. However, the offset issue is sufficient to advocate packet drop as the reassembly is bound to fail. Therefore I'm putting a SHOULD in both cases.

Errata ID: 4090
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Fernando Gont
Date Reported: 2014-08-20
Held for Document Update by: Magnus Westerlund
Date Held: 2020-06-02

Section 6 says:

   1.  In the IPv4-to-IPv6 direction: if the MTU value of ICMPv4 Packet
       Too Big (PTB) messages is less than 1280, change it to 1280.
       This is intended to cause the IPv6 host and IPv6 firewall to
       process the ICMP PTB message and generate subsequent packets to
       this destination with an IPv6 Fragment Header.

It should say:

   1.  In the IPv4-to-IPv6 direction: if the MTU value of ICMPv4 Packet
       Too Big (PTB) messages is less than 1280, change it to 1280.
       This is intended to cause the IPv6 host and IPv6 firewall to
       process the ICMP PTB message.

Notes:

An ICMPv6 PTB message reporting an MTU equal to 1280 does not trigger IPv6 atomic fragments. Only ICMPv6 PTB < 1280 do.

AD Comment (Magnus Westerlund): As RFC 6145 has been superseeded by RFC 7915. In that document the above text is gone. So I consider this issue handled and not necessary to determine if it is verified or not.

RFC 6146, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", April 2011

Source of RFC: behave (tsv)

Errata ID: 4756
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alberto Leiva Popper
Date Reported: 2016-08-02
Held for Document Update by: Magnus Westerlund
Date Held: 2021-01-13

Section 3.5.3 says:

If the NAT64 filters on its IPv4 interface, then the NAT64 checks
to see if the incoming packet is allowed according to the Address-
Dependent Filtering rule.  To do this, it searches for a Session
Table Entry with an STE source IPv4 address equal to X, an STE
ICMPv4 Identifier equal to i2, and a STE destination IPv4 address
equal to Y.  If such an entry is found (there may be more than
one), packet processing continues.  Otherwise, the packet is
discarded.  If the packet is discarded, then an ICMP error message
MAY be sent to the original sender of the packet.  The ICMP error
message, if sent, has Type 3 (Destination Unreachable) and Code 13
(Communication Administratively Prohibited).

In case the packet is not discarded in the previous processing
steps (either because the NAT64 is not filtering or because the
packet is compliant with the Address-Dependent Filtering rule),
then the NAT64 searches for a Session Table Entry (...)

It should say:

The NAT64 then searches for a Session Table Entry (...)

Notes:

The statement "there may be more than one" is incorrect; the triplet (X,i2,Y) constitutes the whole ICMP session's v4 identifier. Considering that, the whole paragraph tends to fall apart.

The point of Address-Dependent Filtering (ADF) is to provide a means to allow or disallow IPv4-started "sibling" connections. If there is an ongoing connection whose binding state is

BIB entry: (*,*) <--> (T,t)
Session: (*,*),(*,*) <--> (T,t),(Z,z)

(Left side is v6, right side is v4. This is the same notation as the RFC; see for example https://tools.ietf.org/html/rfc6146#section-3.5.1; '*' is anything/irrelevant)

Then ADF dictates whether the v4 endpoint is allowed to create the following new session (using the same BIB entry):

Session: (*,*),(*,*) <--> (T,t),(Z,m)

(where 'z' is not equal to 'm')

ADF works in UDP/TCP because t and z/m are separate variables. This is not the case in ICMP:

BIB entry: (*,*) <--> (T,t)
Session: (*,*,*) <--> (T,t,Z)

If only one ICMP triplet can match, there is no room for "sibling" ICMP "connections" that share a "source" IPv4 identifier but not a "destination" IPv4 identifier like TCP and UDP do. The two pings will share both BIB entry and v4 endpoint address and therefore also share the session. The NAT64 is incapable of telling the two pings apart, and therefore cannot filter one of them.

There is no such thing as "Address-Dependent Filtering" on ICMP.

RFC 6147, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", April 2011

Source of RFC: behave (tsv)

Errata ID: 2975
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Libor Polcak
Date Reported: 2011-09-18
Held for Document Update by: Wes Eddy

Section 5.1.4 says:

An implementation SHOULD include the ::ffff/96 network in that range 
by default.

It should say:

An implementation SHOULD include the ::ffff:0:0/96 network in that range 
by default.

RFC 6154, "IMAP LIST Extension for Special-Use Mailboxes", March 2011

Source of RFC: morg (app)

Errata ID: 4422
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Chris Newman
Date Reported: 2015-07-20
Held for Document Update by: Barry Leiba
Date Held: 2015-07-20

Throughout the document, when it says:

N/A

It should say:

N/A

Notes:

There is missing information in this RFC that resulted in interoperability problems when we performed an informal interop test of multiple implementations on 2015-07-19. This is assumed to be a "hold for document update" errata.

There is no guidance in the document related to how special-use attributes are bootstrapped. Servers may pre-create them but there's no requirement to do so and clients may use the CREATE-SPECIAL-USE or METADATA extensions to bootstrap but there is no requirement to use those mechanisms if the server offers them. This resulted in a server implementation assuming the client would bootstrap these attributes and a client assuming the server would do so, thus interoperability failed.

Given this experience, the fastest way to resolve this interop problem over time is for both client and server to take responsibility for bootstrapping special use mailboxes. This means if clients create a mailbox intended for special use (e.g., drafts, sent, junk, trash, etc), and the CREATE-SPECIAL-USE extension is offered, then clients need to provide the USE extension to improve interoperability. Servers that are provisioned with an end-user's locale or language need to pre-create appropriate special-use mailboxes to improve interoperability of this extension. For existing accounts where the server is upgraded to support this feature, the server can look for mailboxes with names that imply special use and add the attribute to those mailboxes (especially if the server has locale/language awareness provisioned for users). Clients that implement a name-based search if special use attributes are not present and decide to use a mailbox for a special use based on its name can use the METADATA extension, if offered, to label that mailbox appropriately.

RFC 6167, "URI Scheme for Java(tm) Message Service 1.0", April 2011

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 2809
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-05-14
Held for Document Update by: Pete Resnick

Throughout the document, when it says:

Phillips, et al.              Informational                     [Page 1]

RFC 6167                     jms" URI Scheme                  April 2011

It should say:

Phillips, et al.              Informational                     [Page 1]

RFC 6167                     "jms" URI Scheme                 April 2011

Notes:

This is a typing error, I believe - one inverted comma is missing here.

RFC 6196, "Moving mailserver: URI Scheme to Historic", March 2011

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 2756
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-03-25
Held for Document Update by: Pete Resnick

Throughout the document, when it says:

mailserver: URI Scheme

It should say:

'mailserver' URI Scheme

Notes:

The ":" (colon) character is not a part of URI scheme name. RFC 3986 says:

URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )

i. e. ":" is a delimiter between scheme name and the remainder of URI.

Errata ID: 2916
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-08-04
Held for Document Update by: Pete Resnick

Section 1 says:

   There were some previous attempts to provide detailed documentation
   of the mailserver: URI scheme, but those efforts were not successful.
   Implementors interested in providing instructions for generating an
   email [RFC5322] message can instead use the mailto: URI scheme
   [RFC6068].  Implementors interested in referencing a message or a set
   of messages available from a mailstore over IMAP [RFC3501], POP
   [RFC1939], or web [RFC2616] can instead use the imap: [RFC5092], pop:
   [RFC2384] or http: [RFC2616] URIs, respectively.

It should say:

   There were some previous attempts to provide detailed documentation
   of the 'mailserver' URI scheme, but those efforts were not successful.
   Implementors interested in providing instructions for generating an
   email [RFC5322] message can instead use the 'mailto' URI scheme
   [RFC6068].  Implementors interested in referencing a message or a set
   of messages available from a mailstore over IMAP [RFC3501], POP
   [RFC1939], or web [RFC2616] can instead use the 'imap' [RFC5092], 'pop'
   [RFC2384] or 'http' [RFC2616] URIs, respectively.

Notes:

This is a complement to Erratum 2756 (http://www.rfc-editor.org/errata_search.php?eid=2756); see justification there.

RFC 6214, "Adaptation of RFC 1149 for IPv6", April 2011

Source of RFC: INDEPENDENT

Errata ID: 4668
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: YC Lee
Date Reported: 2016-04-14
Held for Document Update by: Nevil Brownlee
Date Held: 2016-04-28

Section 8 says:

Notes:

In some countries you are be required to obtain a proper license from authorities to keep some kind of birds. It should be addressed in RFC.

Example: http://www.afcd.gov.hk/english/publications/publications_press/pr1037.html
"Unauthorised keeping of five kinds of poultry -chickens, ducks, geese, pigeons and quails – is an offence..."

RFC 6221, "Lightweight DHCPv6 Relay Agent", May 2011

Source of RFC: dhc (int)

Errata ID: 2957
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Gaurav Halwasia
Date Reported: 2011-09-05
Held for Document Update by: Brian Haberman

Section 6.2 says:

-  the Interface-ID option is present, and the value corresponds to a
   valid interface in the access node;

It should say:

-  the Interface-ID option is present, and the value corresponds to a
   valid client-facing interface in the access node;

RFC 6225, "Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information", July 2011

Source of RFC: geopriv (rai)

Errata ID: 3202
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2012-04-26
Held for Document Update by: Robert Sparks

Section 4.3, pg. 19 says:

   Description: The description of the altitude described by this code.

It should say:

   Description: The description of the datum (coordinate system)
      described by this code.

Notes:

Rationale: copyedit artifact; text obviously copied from
Section 4.2. (Altitude Type Registry) without performing
the needed adaptation for Section 4.3. (Datum Registry).

RFC 6234, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", May 2011

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 5238
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yeong-u Kim (K.)
Date Reported: 2018-01-19
Held for Document Update by: Warren Kumari (Ops AD)
Date Held: 2018-01-22

Section 3 says:

   e. The rotate left (circular left shift) operation ROTL^n(x), where x
      is a w-bit word and n is an integer with 0 <= n < w, is defined by

         ROTL^n(X) = (x<<n) OR (x>>(w-n))

It should say:

   e. The rotate left (circular left shift) operation ROTL^n(x), where x
      is a w-bit word and n is an integer with 0 <= n < w, is defined by

         ROTL^n(x) = (x<<n) OR (x>>(w-n))

Notes:

A typo. The function argument has to be x, not X.

RFC 6236, "Negotiation of Generic Image Attributes in the Session Description Protocol (SDP)", May 2011

Source of RFC: mmusic (rai)

Errata ID: 3620
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Liangxing Wang
Date Reported: 2013-05-14
Held for Document Update by: Gonzalo Camarillo

Section 4.2.4 says:

send [x=400:16:800],y=[320:16:640],sar=[1.0-1.3],par=[1.2-1.3]] 

It should say:

send [x=[400:16:800],y=[320:16:640],sar=[1.0-1.3],par=[1.2-1.3]] 

Notes:

Mismatching [] in original text.

RFC 6238, "TOTP: Time-Based One-Time Password Algorithm", May 2011

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 3338
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Samuel Whited
Date Reported: 2012-09-06
Held for Document Update by: Sean Turner

Section 1.2 says:

Basically, the output of the HMAC-SHA-1 calculation is truncated to
obtain user-friendly values:

It should say:

The output of the HMAC-SHA-1 calculation is truncated to
obtain user-friendly values:

Notes:

Starting a sentence with `Basically' is often considered bad form.
Qualifiers such as basically add nothing to the sentence and should
generally be avoided.

Errata ID: 3339
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Samuel Whited
Date Reported: 2012-09-06
Held for Document Update by: Sean Turner

Section 4.2 says:

Basically, we define TOTP as TOTP = HOTP(K, T), where T is an integer
and represents the number of time steps between the initial counter
time T0 and the current Unix time.

It should say:

We define TOTP as TOTP = HOTP(K, T), where T is an integer
and represents the number of time steps between the initial counter
time T0 and the current Unix time.

Notes:

As mentioned in a previous errata, starting a sentence with
`Basically' is often considered bad form. Qualifiers such as
basically add nothing to the sentence and should generally be
avoided.

RFC 6239, "Suite B Cryptographic Suites for Secure Shell (SSH)", May 2011

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 7859
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Thomas Bailleux
Date Reported: 2024-03-20
Held for Document Update by: Deb Cooley
Date Held: 2024-03-29

Section 4.2 says:

The format of the SSH_MSG_KEXECDH_REPLY is:

      byte      SSH_MSG_KEXECDH_REPLY

It should say:

The format of the SSH_MSG_KEXECDH_REPLY is:

      byte      SSH_MSG_KEXDH_REPLY

Notes:

SSH_MSG_KEXECDH_REPLY is defined nowhere. Similar to SSH_MSG_KEXECDH_INIT with SSH_MSG_KEXDH_INIT, I think SSH_MSG_KEXECDH_REPLY is supposed to reuse SSH_MSG_KEXDH_REPLY.

RFC 6241, "Network Configuration Protocol (NETCONF)", June 2011

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

Source of RFC: netconf (ops)

Errata ID: 5401
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Rohit R Ranade
Date Reported: 2018-06-21
Held for Document Update by: Ignas Bagdonas
Date Held: 2019-10-18

Section 8.9.1 says:

   The XPath expression MUST return a node set.  If it does not return a
   node set, the operation fails with an "invalid-value" error.

It should say:

   The XPath expression MUST return a node set.  If it does not return a
   node set, the operation fails with an <error-tag> value of 
   "invalid-value".

Notes:

It is unclear what is the meaning of "invalid-value" "error". Since the xpath will be part of "select" attribute, we can assume that a server can return a "bad-attribute" error-tag and having error-message indicating invalid-value for the attribute. This clarifies the <error-tag> to be used in such cases.
In other places, where error-tag has been mentioned, it is clear that "invalid-value" <error-tag> must be used.

Errata ID: 3569
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Xiang Li
Date Reported: 2013-03-27
Held for Document Update by: Benoit Claise

Section 1.2 says:

   (2)  The Messages layer provides a simple, transport-independent
        framing mechanism for encoding RPCs and notifications.
        Section 4 documents the RPC messages, and [RFC5717] documents
        notifications

It should say:

   (2)  The Messages layer provides a simple, transport-independent
        framing mechanism for encoding RPCs and notifications.
        Section 4 documents the RPC messages, and [RFC5277] documents
        notifications

Notes:

RFC5717 Partial Lock Remote Procedure Call (RPC) for NETCONF
RFC5277 NETCONF Event Notifications

Errata ID: 3821
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jonathan Hansford
Date Reported: 2013-12-06
Held for Document Update by: Benoit Claise
Date Held: 2014-01-13

Section 8.4.1 says:

8.4.1.  Description

The :confirmed-commit:1.1 capability indicates that the server will
support the <cancel-commit> operation and the <confirmed>,
<confirm-timeout>, <persist>, and <persist-id> parameters for the
<commit> operation.  See Section 8.3 for further details on the
<commit> operation.

A confirmed <commit> operation MUST be reverted if a confirming
commit is not issued within the timeout period (by default 600
seconds = 10 minutes).  The confirming commit is a <commit> operation
without the <confirmed> parameter.  The timeout period can be
adjusted with the <confirm-timeout> parameter.  If a follow-up
confirmed <commit> operation is issued before the timer expires, the
timer is reset to the new value (600 seconds by default).  Both the
confirming commit and a follow-up confirmed <commit> operation MAY
introduce additional changes to the configuration.

If the <persist> element is not given in the confirmed commit
operation, any follow-up commit and the confirming commit MUST be
issued on the same session that issued the confirmed commit.  If the
<persist> element is given in the confirmed <commit> operation, a
follow-up commit and the confirming commit can be given on any
session, and they MUST include a <persist-id> element with a value
equal to the given value of the <persist> element.

If the server also advertises the :startup capability, a
<copy-config> from running to startup is also necessary to save the
changes to startup.

If the session issuing the confirmed commit is terminated for any
reason before the confirm timeout expires, the server MUST restore
the configuration to its state before the confirmed commit was
issued, unless the confirmed commit also included a <persist>
element.

If the device reboots for any reason before the confirm timeout
expires, the server MUST restore the configuration to its state
before the confirmed commit was issued.

If a confirming commit is not issued, the device will revert its
configuration to the state prior to the issuance of the confirmed
commit.  To cancel a confirmed commit and revert changes without
waiting for the confirm timeout to expire, the client can explicitly
restore the configuration to its state before the confirmed commit
was issued, by using the <cancel-commit> operation.

It should say:

8.4.1.  Description
 
The :confirmed-commit:1.1 capability indicates that the server will
support the <cancel-commit> operation, the <confirmed>, <confirm-
timeout>, <persist>, and <persist-id> parameters for the <commit>
operation, and differentiate between a “to be confirmed” <commit>
operation (a “confirmed commit”) and a confirming <commit>
operation. See Section 8.3 for further details on the <commit>
operation.
 
A confirmed <commit> operation MUST be reverted if a confirming
commit is not issued within the timeout period (by default 600
seconds = 10 minutes). The confirming commit is a <commit> operation
without the <confirmed> parameter and, if successful, cannot be
reverted. The timeout period can be adjusted with the <confirm-
timeout> parameter. If a follow-up confirmed <commit> operation is
issued before the timer expires, the timer is reset to the new value
(600 seconds by default). Both the confirming commit and a follow-up
confirmed <commit> operation MAY introduce additional changes to the
configuration.
 
If the <persist> element is not given in the confirmed commit
operation, any follow-up commit and the confirming commit MUST be
issued on the same session that issued the confirmed commit. If the
<persist> element is given in the confirmed <commit> operation, a
follow-up commit and the confirming commit can be given on any
session, and they MUST include a <persist-id> element with a value
equal to the given value of the <persist> element.
 
If the server also advertises the :startup capability, a <copy-
config> from running to startup is also necessary to save the
changes to startup. If the session issuing a sequence of one or more
confirmed commits is terminated for any reason before the confirm
timeout expires, the server MUST restore the configuration to its
state before the sequence of confirmed commits was issued, unless
the last confirmed commit also included a <persist> or <persist-id>
element.
 
If the device reboots for any reason before the confirm timeout
expires, the server MUST restore the configuration to its state
before the sequence of confirmed commits was issued, unless the last
confirmed commit also included a <persist> or <persist-id> element.
 
If a confirming commit is not issued, the device will revert its
configuration to the state prior to the issuance of the first in the
current sequence of confirmed commits. To cancel the current
sequence of confirmed commits and revert changes without waiting for
the confirm timeout to expire, the client can explicitly restore the
configuration to its state before the sequence of confirmed commits
was issued, by using the <cancel-commit> operation.
 

Notes:

This erratum seeks to clarify the meaning of the term "confirmed commit" for those not familiar with the use of the term within JUNOS. In particular, that the use of "confirmed" is not in the sense of the adjective (meaning "firmly established") but rather that the commit needs to be confirmed. It also emphasises that a "confirming commit" cannot be reverted. Finally it identifies that it is possible to have a sequence of "confirmed commits" prior to a "confirming commit" and that, should no "confirming commit" be received, the configuration will revert to the state prior to the first "confirmed commit" in the sequence.

Errata ID: 3822
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jonathan Hansford
Date Reported: 2013-12-06
Held for Document Update by: Benoit Claise
Date Held: 2014-01-13

Section 8.4.4.1 says:

Description:

      Cancels an ongoing confirmed commit.  If the <persist-id>
      parameter is not given, the <cancel-commit> operation MUST be
      issued on the same session that issued the confirmed commit.

Parameters:

   persist-id:

         Cancels a persistent confirmed commit.  The value MUST be
         equal to the value given in the <persist> parameter to the
         <commit> operation.  If the value does not match, the
         operation fails with an "invalid-value" error.

It should say:

Description:

      Cancels an ongoing sequence of confirmed commits. If the
      <persist-id> parameter is not given, the <cancel-commit>
      operation MUST be issued on the same session that issued the
      sequence of confirmed commits.

Parameters:

   persist-id:

         Cancels a persistent sequence of confirmed commits. The
         value MUST be equal to the value given in the <persist>
         parameter to the <commit> operation. If the value does not
         match, the operation fails with an "invalid-value" error.

Notes:

This erratum seeks to clarify that <cancel-commit> will cancel all configuration changes arising from a sequence of "confirmed commits".

Errata ID: 3823
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jonathan Hansford
Date Reported: 2013-12-06
Held for Document Update by: Benoit Claise
Date Held: 2014-01-13

Section 8.4.5.1 says:

   persist:

         Make the confirmed commit survive a session termination, and
         set a token on the ongoing confirmed commit.

It should say:

   persist:

         Make the confirmed commit survive a session termination,
         and set a token on the ongoing sequence of confirmed
         commits.

Notes:

This erratum seeks to clarify that the use of the "persist" parameter will persist all configuration changes arising from a sequence of "confirmed commits".

RFC 6244, "An Architecture for Network Management Using NETCONF and YANG", June 2011

Source of RFC: netmod (ops)

Errata ID: 3356
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Benoit Claise
Date Reported: 2012-09-17
Held for Document Update by: Benoit Claise

Section 2.2.3 says:

          augment /ospf:ospf/ospf:area/ospf:interfaces  {
               leaf no-neighbor-down-notification {
                   type empty;
                   description "Don't inform other protocols about"
                             + " neighbor down events";

It should say:

          augment /ospf:ospf/ospf:area/ospf:interface {
               leaf no-neighbor-down-notification {
                   type empty;
                   description "Don't inform other protocols about"
                             + " neighbor down events";

Notes:

Section 2.2.3
For example, if the above OSPF configuration were the standard, a
vendor module may augment this with vendor-specific extensions.

module vendorx-ospf {
namespace "http://vendorx.example.com/ospf";
prefix vendorx;

import example-ospf {
prefix ospf;
}

augment /ospf:ospf/ospf:area/ospf:interfaces {
leaf no-neighbor-down-notification {
type empty;
description "Don't inform other protocols about"
+ " neighbor down events";
}
}
}

While the "above OSPF configuration" refers to interface and not interfaces

module example-ospf {
namespace "http://example.org/netconf/ospf";
prefix ospf;

import network-types { // Access another module's def'ns
prefix nett;
}

container ospf { // Declare the top-level tag
list area { // Declare a list of "area" nodes
key name; // The key "name" identifies list members
leaf name {
type nett:area-id;
}
list interface {
key name;
leaf name {
type nett:interface-name;
}
leaf priority {
description "Designated router priority";
type uint8; // The type is a constraint on
// valid values for "priority".
}
leaf metric {
type uint16 {
range 1..65535;
}
}
leaf dead-interval {
units seconds;
type uint16 {
range 1..65535;
}
}
}
}
}
}

RFC 6257, "Bundle Security Protocol Specification", May 2011

Source of RFC: IRTF

Errata ID: 3184
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jim Wright
Date Reported: 2012-04-10
Held for Document Update by: Stephen Farrell

Section 4.2 says:

   "Commensurate strength" cryptography is generally held to be a good
   idea.  A combination of RSA with SHA-256 is reckoned to require a
   3076-bit RSA key according to this logic.

It should say:

   "Commensurate strength" cryptography is generally held to be a good
   idea.  A combination of RSA with SHA-256 is reckoned to require a
   3072-bit RSA key according to this logic.

Notes:

After consulting the authors, it appears that 3076 is a typo and should be 3072.

RFC 6265, "HTTP State Management Mechanism", April 2011

Source of RFC: httpstate (app)

Errata ID: 3663
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Dave Thaler
Date Reported: 2013-06-17
Held for Document Update by: Barry Leiba
Date Held: 2013-08-07

Section 5.1.4 says:

A request-path path-matches a given cookie-path if at least one of
the following conditions holds:

o  The cookie-path and the request-path are identical.

It should say:

A request-path path-matches a given cookie-path if at least one of
the following conditions holds:

o  The cookie-path and the request-path are identical.  Note that this
   differs from the rules in RFC 3986 for equivalence of the path
   component, and hence two equivalent paths can have different
   cookies.

Notes:

The "identical" rule differs from the URI equivalence rule(s) in RFC 3986
sections 6.2 and 2.1 (e.g., "If two URIs differ only in the case of hexadecimal
digits used in percent-encoded octets, they are equivalent.") The fact that
equivalent URIs have different cookies arguably violates the principle of
least astonishment. To avoid significant confusion and prevent such surprise,
this fact should be noted so that it is at least not unexpected.

RFC 6276, "DHCPv6 Prefix Delegation for Network Mobility (NEMO)", July 2011

Source of RFC: mext (int)

Errata ID: 3078
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sofiane IMADALI
Date Reported: 2012-01-05
Held for Document Update by: Brian Haberman

Section 3.2 says:

Figure 3: Signaling sequence for the case the home agent is at home

It should say:

Figure 3: Signaling sequence for the case the Mobile Router is at home

Notes:

The figure name is not corresponding to the section's name. In addition, the home agent is always at home.

RFC 6286, "Autonomous-System-Wide Unique BGP Identifier for BGP-4", June 2011

Source of RFC: idr (rtg)

Errata ID: 2990
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2011-10-11
Held for Document Update by: Stewart Bryant

Section 3 says:

In the AGGREAGTOR attribute of a route

It should say:

In the AGGREGATOR attribute of a route

RFC 6287, "OCRA: OATH Challenge-Response Algorithm", June 2011

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 3900
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marcus Bring
Date Reported: 2014-02-24
Held for Document Update by: Stephen Farrell
Date Held: 2014-07-03

Section Appendix A. says:

* @param password     a password that can be used, HEX encoded
.
.
.
// Put the bytes of "password" to the message
// Input is HEX encoded

It should say:

* @param password     a password that can be used, hashed with the 
* SHA-version declared in OCRA-suite and HEX encoded.
.
.
.
// Put the bytes of "password" to the message
// Input is SHA hashed and HEX encoded

Notes:

The password should be hashed as stated in the RFC and as it is done in the testOCRA class.

This should also eliminate the need to padd the password with zeros since the hash is always of the correct length.

// Password - sha1
if(DataInput.toLowerCase().indexOf("psha1") > 1){
passwordLength=20;
}

// Password - sha256
if(DataInput.toLowerCase().indexOf("psha256") > 1){
passwordLength=32;
}

// Password - sha512
if(DataInput.toLowerCase().indexOf("psha512") > 1){
passwordLength=64;
}

RFC 6295, "RTP Payload Format for MIDI", June 2011

Source of RFC: payload (rai)

Errata ID: 6540
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Juli Mallett
Date Reported: 2021-04-13
Held for Document Update by: RFC Editor
Date Held: 2024-02-16

The Table of Contents says:

   Appendix C. Session Configuration Tools ....... ..................100

It should say:

   Appendix C. Session Configuration Tools ..........................100

Notes:

Space to full stop.

RFC 6310, "Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping", July 2011

Source of RFC: pwe3 (rtg)

Errata ID: 3281
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Muly Ilan
Date Reported: 2012-07-05
Held for Document Update by: Stewart Bryant
Date Held: 2012-07-11

Section 6.1.3 says:

This is achieved by including a capability TLV in the PW Forward 
Error Correction (FEC) interface parameters TLV.

It should say:

This is achieved by including a capability TLV in the PW Forwarding 
Equivalence Class (FEC) interface parameters TLV.

Notes:

"FEC" should also be added to the list of abbreviations in section 2.1.

This erratum is correct, but is unlikely to cause an incorrect implementation of the protocol, thus it can be held over to the next revision of the RFC.

RFC 6313, "Export of Structured Data in IP Flow Information Export (IPFIX)", July 2011

Source of RFC: ipfix (ops)

Errata ID: 2885
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Held for Document Update by: Dan Romascanu

Section multiple says:

commonPropertiesID

It should say:

commonPropertiesId

Notes:

s/commonPropertiesID/commonPropertiesId/ (thrice)

- in sections 10.1, 10.1.1, and 10.1.2.

Per the definition in RFC 5101 and in IANA's IPFIX registry.

Errata ID: 2925
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-08
Held for Document Update by: ron bonica

Section Appendix A says:

     <enumeration value="basicList">
       <annotation>
         <documentation>
           Represents a list of zero or more instances of
           any Information Element, primarily used for
           single-valued data types.  Examples include a list of port
           numbers, a list of interface indexes, and a list of AS in a
           BGP AS-PATH.
         </documentation>
       </annotation>
     </enumeration>

...

     <enumeration value="subTemplateList">
       <annotation>
         <documentation>
           Represents a list of zero or more instances of a
           structured data type, where the data type of each list
           element is the same and corresponds with a single
           Template Record.  Examples include a structured data type
           composed of multiple pairs of ("MPLS label stack entry
           position", "MPLS label stack value"), a structured
           data type composed of performance metrics, and a
           structured data type composed of multiple pairs of IP
           address.
         </documentation>
       </annotation>
     </enumeration>

...

     <enumeration value="subTemplateMultiList">
       <annotation>
         <documentation>
           Represents a list of zero or more instances of
           structured data types, where the data type of each
           list element can be different and corresponds with
           different Template definitions.  An example is a
           structured data type composed of multiple
           access-list entries, where entries can be
           composed of different criteria types.
         </documentation>
       </annotation>
     </enumeration>

It should say:

         <enumeration value="basicList">
           <annotation>
             <documentation>The type "basicList" represents a list
               of zero or more instances of any Information Element,
               primarily used for single-valued data types.
               Examples include a list of port numbers,
               a list of interface indexes,
               and a list of AS in a BGP AS-PATH.
             </documentation>
           </annotation>
         </enumeration>

...

         <enumeration value="subTemplateList">
           <annotation>
             <documentation>The type "subTemplateList" represents a list
               of zero or more instances of a structured data type,
               where the data type of each list element is the same
               and corresponds with a single Template Record.  Examples include
               a structured data type composed of multiple pairs of
               ("MPLS label stack entry position", "MPLS label stack value"),
               a structured data type composed of performance metrics, and
               a structured data type composed of multiple pairs of IP address.
             </documentation>
           </annotation>
         </enumeration>

...

         <enumeration value="subTemplateMultiList">
           <annotation>
             <documentation>The type "subTemplateMultiList" represents a list
               of zero or more instances of structured data types,
               where the data type of each list element can be different
               and corresponds with different Template definitions.
               An example is a structured data type composed of multiple
               access-list entries, where entries can be composed of
               different criteria types.
             </documentation>
           </annotation>
         </enumeration>

Notes:

Addition of 'The type "basicList"', 'The type "subTemplateList"' and 'The type "subTemplateMultiList"', for consistency with the existing descriptions which all begin 'The type xxx ...'.

Note that this refers to text on page 63, for modifications to the IPFIX schema. The schema has been updated with the corrected text above.

Errata ID: 2926
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-08
Held for Document Update by: ron bonica

Section Appendix A says:

 <simpleType name="dataTypeSemantics">
   <restriction base="string">
     <enumeration value="List">
       <annotation>
         <documentation>
           Represents an arbitrary-length sequence of structured
           data elements, either composed of regular Information
           Elements or composed of data conforming to a Template
           Record.
         </documentation>
       </annotation>
     </enumeration>

It should say:

         <enumeration value="list">
           <annotation>
             <documentation>
               Represents an arbitrary-length sequence
               of zero or more structured data Information Elements,
               either composed of regular Information Elements
               or composed of data conforming to a Template Record.
             </documentation>
           </annotation>
         </enumeration>

Notes:

Insertion of missing "zero or more" per the definition in section 4.2.1:

4.2. New Data Type Semantic
4.2.1. List

A list represents an arbitrary-length sequence of zero or more
structured data Information Elements, either composed of regular
Information Elements or composed of data conforming to a Template
Record.

Note that this refers to the dataTypeSemantics on page 64, for modifications to the IPFIX schema. The schema has been updated with the corrected text above.

RFC 6321, "xCal: The XML Format for iCalendar", August 2011

Note: This RFC has been updated by RFC 6868, RFC 7529

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 3315
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Norman Walsh
Date Reported: 2012-08-12
Held for Document Update by: Barry Leiba

Section Appendix A says:

   type-until = element until {
       type-date |
       type-date-time
   }

It should say:

???

Notes:

The type-date and type-date-time patterns are undefined in the schema.

Errata ID: 3316
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Norman Walsh
Date Reported: 2012-08-12
Held for Document Update by: Barry Leiba

Section Appendix A says:

   type-byday = element byday {
       xsd:integer?,
       type-weekday
   }

It should say:

???

Notes:

That's not a valid RELAX NG pattern. It's an attempt to group "string" and "data" patterns.

Errata ID: 2938
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hamish Lawson
Date Reported: 2011-08-15
Held for Document Update by: Peter Saint-Andre

Section 3.4.1.2 says:

These are an IC:latitude element and an IC:longitude
element, each of which contains float values.

It should say:

 These are an IC:latitude element and an IC:longitude
 element, each of which contains a float value.

Notes:

The existing text erroneously suggests that multiple values could be contained by each element.

Errata ID: 3314
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Norman Walsh
Date Reported: 2012-08-12
Held for Document Update by: Barry Leiba

Section Appendix A says:

   # 3.6.5 Time Zone Component

   component-vtimezone = element vtimezone {
       element properties {
           property-tzid &

           property-last-mod? &
           property-tzuurl?
       },

It should say:

   # 3.6.5 Time Zone Component

   component-vtimezone = element vtimezone {
       element properties {
           property-tzid &

           property-last-mod? &
           property-tzurl?
       },

Notes:

The property-tzurl pattern name is misspelled.

RFC 6335, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", August 2011

Source of RFC: tsvwg (wit)

Errata ID: 4999
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Nottingham
Date Reported: 2017-04-19
Held for Document Update by: Mirja Kühlewind
Date Held: 2020-03-04

Throughout the document, when it says:

Notes:

Many port number assignments are to individuals, but the document does not
contemplate how they should be handled when the assignee is dead or
otherwise can't be contacted.

The most obvious procedure to follow is a transfer (8.5), but that requires
de-assignment (8.2), and that doesn't cover the case above.

RFC 6350, "vCard Format Specification", August 2011

Note: This RFC has been updated by RFC 6868

Source of RFC: vcarddav (app)

Errata ID: 3100
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Roberto Javier Godoy
Date Reported: 2012-01-30
Held for Document Update by: Peter Saint-Andre

Section 5.6 says:

type-param = "TYPE=" type-value *("," type-value)

It should say:

type-param =  "TYPE=" type-value *("," type-value)
type-param =/ "TYPE=" DQUOTE type-value *("," type-value) DQUOTE

Notes:

Section 6.4.1 states that TYPE parameter values can be specified
as a parameter list (e.g., TYPE=text;TYPE=voice) or as a value list (e.g.,
TYPE="text,voice").

Either the description is right (and the ABNF should be corrected), or the ABNF is right, and the description and examples in Sections 6.4.1 and 8 should be fixed.

Value lists in vCard 3.0 did not use quotes (e.g "TYPE=dom,postal" in Section 3.3.1 of RFC 2426). If the ABNF is fixed this would be a significant change from RFC 2426 syntax.

Errata ID: 3138
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Kai Giebeler
Date Reported: 2012-02-25
Held for Document Update by: Peter Saint-Andre

Section 3.3. says:

   param-value = *SAFE-CHAR / DQUOTE *QSAFE-CHAR DQUOTE

   SAFE-CHAR = WSP / "!" / %x23-39 / %x3C-7E / NON-ASCII
     ; Any character except CTLs, DQUOTE, ";", ":"

It should say:

   param-value = *SAFE-CHAR / DQUOTE *QSAFE-CHAR DQUOTE

   SAFE-CHAR = WSP / "!" / %x23-2B / %x2D-39 / %x3C-7E / NON-ASCII
     ; Any character except CTLs, DQUOTE, ",", ";", ":"

Notes:

"5. Property Parameters" states: "Property parameter value elements that contain the COLON (U+003A), SEMICOLON (U+003B), or COMMA (U+002C) character separators MUST be specified as quoted-string text values."

So COMMA cannot be part of a non-quoted parameter value which should be reflected by the SAFE-CHAR declaration.

Otherwise a value of
X-PARAM=tel,fax
could be ambiguously interpreted as
"tel","fax" (separated values)
and "tel,fax" (combined value containing a COMMA)

Errata ID: 3139
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Kai Giebeler
Date Reported: 2012-02-25
Held for Document Update by: Peter Saint-Andre

Section 3.3. et. al. says:

3.3. ABNF Format Definition
   param-value = *SAFE-CHAR / DQUOTE *QSAFE-CHAR DQUOTE
   any-param  = (iana-token / x-name) "=" param-value *("," param-value)

5.6. TYPE
   type-param = "TYPE=" type-value *("," type-value)

5.9. SORT-AS
   sort-as-value = param-value *("," param-value)
   SORT-AS="Harten,Rene"

6.4.1. TEL
   TYPE=text;TYPE=voice
   TYPE="voice,fax"

It should say:

The semantics of of lists passed to/by parameters should be consistent
or clearly stated.

Notes:

(I'm unsure if this is a technical problem or simply needs to be clarified)

All of the following parameters seem to be allowed and seem to be (more or less) equivalent:
X-PARAM="tel,fax,mail"
X-PARAM="tel","fax","mail"
X-PARAM="tel",fax,"mail,pager"
X-PARAM="tel,fax";X-PARAM="mail",pager

The main advantage of quoting strings gets lost, if contained characters get a special meaning (like a comma for separation).

In my opinion quoted values should be considered to be some kind of atomic. Without that rule there's no generic approach to interpret unknown parameter values. e.g.
X-PARAM="doc1.txt?row=10,col=6","doc2.txt?row=3,col=5"

If "voice,fax" may be decomposed to "voice", "fax" the example could be decomposed to:
- "doc1.txt?row=10"
- "col=6"
- "doc2.txt?row=3"
- "col=5"
... which is clearly not the authors intention. By recomposing it could end up as
"doc1.txt?row=10,col=6,doc2.txt?row=3,col=5"

Preserving unknown parameters in a read-modify-write-process is nearly impossible to implement.

Errata ID: 3488
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Angstadt
Date Reported: 2013-02-18
Held for Document Update by: Barry Leiba
Date Held: 2013-02-19

Throughout the document, when it says:

See notes

It should say:

See notes

Notes:

============================================
Verifier notes:
The report below is correct, and it's important that implementors understand that RFC 6350 has a number of errors here. The problem is that properly correcting the errors goes beyond the scope of the RFC errata system, and requires an updated document.

This errata report is, therefore, going to be marked "held for document update", but that designation should not be taken as downplaying the importance of this report and the errors it talks about. The verifier strongly encourages an effort to produce such an updated document soon. There will be significant interoperability problems if different implementations handle multi-valued parameters differently.
============================================

Multiple errata have been submitted that draw attention to an inconsistency in how multi-valued parameters are represented in the ABNF and how they are represented in various examples throughout the specification (errata IDs 3100, 3138, 3139).

It is the opinion of this author that it is the ABNF, not the examples, which should be declared correct, since the ABNF allows for comma characters to be included in parameter values.

To briefly review the issue, in the example below, the TYPE parameter only has one value according to the ABNF, since all of the parameter values are surrounded in double quotes. This is the way that many multi-valued parameters are represented in the specification.

ADR;TYPE="home,dom,work":

According to the ABNF, the correct way to encode this list of values would be to either remove the double quotes, since none of the values contain special characters, or to enclose selected, individual values in double quotes. The properties below are all ABNF-valid:

ADR;TYPE="home","dom","work":
ADR;TYPE=home,dom,work:
ADR;TYPE=home,"dom",work:

The example in section 6.3.1 on page 34 is a good example of why the ABNF should be followed:

ADR;GEO="geo:12.3457,78.910";LABEL="Mr. John Q. Public, Esq.\n
Mail Drop: TNE QB\n123 Main Street\nAny Town, CA 91921-1234\n
U.S.A.":;;123 Main Street;Any Town;CA;91921-1234;U.S.A.

The GEO and LABEL parameters are enclosed in double quotes because their values contain special characters (colons and commas). If the ABNF is followed, then the parameters are correctly parsed as follows:

GEO
(1) geo:12.3457,78.910
LABEL
(1) Mr. John Q. Public, Esq.\nMail Drop: TNE QB\n123 Main Street\nAny Town, CA 91921-1234\nU.S.A.

However, if these parameters were to be parsed according to the other method, then their values would be incorrectly split up, since they each contain a comma character.

GEO
(1) geo:12.345778.910
(2) 78.910
LABEL
(1) Mr. John Q. Public, Esq.\nMail Drop: TNE QB\n123 Main Street\nAny Town
(2) CA 91921-1234\nU.S.A.

It is suggested that the following corrections be made to the specification:

===========

1. Section 5.9, pages 21-22

FN:Rene van der Harten
N;SORT-AS="Harten,Rene":van der Harten;Rene,J.;Sir;R.D.O.N.
FN:Robert Pau Shou Chang
N;SORT-AS="Pau Shou Chang,Robert":Shou Chang;Robert,Pau;;
FN:Osamu Koura
N;SORT-AS="Koura,Osamu":Koura;Osamu;;
FN:Oscar del Pozo
N;SORT-AS="Pozo,Oscar":del Pozo Triscon;Oscar;;
FN:Chistine d’Aboville
N;SORT-AS="Aboville,Christine":d’Aboville;Christine;;
FN:H. James de Mann
N;SORT-AS="Mann,James":de Mann;Henry,James;;

should be

FN:Rene van der Harten
N;SORT-AS=Harten,Rene:van der Harten;Rene,J.;Sir;R.D.O.N.
FN:Robert Pau Shou Chang
N;SORT-AS=Pau Shou Chang,Robert:Shou Chang;Robert,Pau;;
FN:Osamu Koura
N;SORT-AS=Koura,Osamu:Koura;Osamu;;
FN:Oscar del Pozo
N;SORT-AS=Pozo,Oscar:del Pozo Triscon;Oscar;;
FN:Chistine d’Aboville
N;SORT-AS=Aboville,Christine:d’Aboville;Christine;;
FN:H. James de Mann
N;SORT-AS=Mann,James:de Mann;Henry,James;;

===========

2. Section 6.4.1, page 35

The default type is "voice". These type parameter values can be
specified as a parameter list (e.g., TYPE=text;TYPE=voice) or as a
value list (e.g., TYPE="text,voice"). The default can be
overridden to another set of values by specifying one or more
alternate values. For example, the default TYPE of "voice" can be
reset to a VOICE and FAX telephone number by the value list
TYPE="voice,fax".

should be

The default type is "voice". These type parameter values can be
specified as a parameter list (e.g., TYPE=text;TYPE=voice) or as a
value list (e.g., TYPE=text,voice). The default can be
overridden to another set of values by specifying one or more
alternate values. For example, the default TYPE of "voice" can be
reset to a VOICE and FAX telephone number by the value list
TYPE=voice,fax.

===========

3. Section 6.4.1, page 36

Example:
TEL;VALUE=uri;PREF=1;TYPE="voice,home":tel:+1-555-555-5555;ext=5555
TEL;VALUE=uri;TYPE=home:tel:+33-01-23-45-67

should be

Example:
TEL;VALUE=uri;PREF=1;TYPE=voice,home:tel:+1-555-555-5555;ext=5555
TEL;VALUE=uri;TYPE=home:tel:+33-01-23-45-67

===========

4. Section 8, page 57

TEL;VALUE=uri;TYPE="work,voice";PREF=1:tel:+1-418-656-9254;ext=102
TEL;VALUE=uri;TYPE="work,cell,voice,video,text":tel:+1-418-262-6501

should be

TEL;VALUE=uri;TYPE=work,voice;PREF=1:tel:+1-418-656-9254;ext=102
TEL;VALUE=uri;TYPE=work,cell,voice,video,text:tel:+1-418-262-6501

Errata ID: 4261
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Ivan Enderlin
Date Reported: 2015-02-05
Held for Document Update by: Barry Leiba
Date Held: 2015-03-02

Section 4.3 says:

In RFC6351 (Appendice A), we have a Relax NG Schema defining date and
time format:

# 4.3.1
value-date = element date {
    xsd:string { pattern = "\d{8}|\d{4}-\d\d|--\d\d(\d\d)?|---\d\d" }
  }

# 4.3.2
value-time = element time {
    xsd:string { pattern = "(\d\d(\d\d(\d\d)?)?|-\d\d(\d\d?)|--\d\d)"
                         ~ "(Z|[+\-]\d\d(\d\d)?)?" }
  }

# 4.3.3
value-date-time = element date-time {
    xsd:string { pattern = "(\d{8}|--\d{4}|---\d\d)T\d\d(\d\d(\d\d)?)?"
                         ~ "(Z|[+\-]\d\d(\d\d)?)?" }
  }

# 4.3.4
value-date-and-or-time = value-date | value-date-time | value-time

We assume this is the format from ISO.8601.2004 mentioned in RFC6350.
There is no link on ISO.8601.2004 because ISO documents are not free.
So this is our guess: These formats are very close based on different
examples in RFC6350 and RFC6351.

It should say:

See notes.

Notes:

Question: --10 is October or 10 seconds?

--10 can fit into value-date and value-time:

* From value-date, the 3rd element in the disjunction is --\d\d(\d\d)?, so it matches --10,
* From value-time, the last element in the first disjunction is --\d\d, so it matches --10.

value-date-and-or-time matches value-date before value-time. Conclusion: --10 is always October and never 10 seconds. Is it a technical error in the RFC.


PS: This erratum can be applied on RFC6350 and RFC6351.
PPS: Consider the following erratum http://www.rfc-editor.org/errata_search.php?rfc=6351&eid=4247 on value-time also.

----- Verifier Notes -----
This errata report highlights a real problem that was not foreseen by the working group at the time when the RFC was published. Interoperability issues could result, so it's important to take note of this.

Fixing the problem will require revising the RFC, possibly in a non-backward-compatible manner. The fix is not trivial and discussion and a document update will be necessary.

Errata ID: 4213
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Eric Vought
Date Reported: 2014-12-28
Held for Document Update by: Barry Leiba
Date Held: 2015-01-02

Section 5.4 says:

"Two property instances are considered alternative representations of
the same logical property if and only if their names as well as the
value of their ALTID parameters are identical.  Property instances
without the ALTID parameter MUST NOT be considered an alternative
representation of any other property instance.  Values for the ALTID
parameter are not globally unique: they MAY be reused for different
property names."

It should say:

"Two property instances are considered alternative representations of
the same logical property if and only if their names as well as the
value of their ALTID parameters are identical.  Property instances
without the ALTID parameter MUST NOT be considered an alternative
representation of any other property instance.  Values for the ALTID
parameter are not globally unique: they MAY be reused for different
property names.

"Values for group and for the PREF parameter SHOULD be the same for all
alternative representations of the same property. The values of group
and PREF are not defined for a property if they differ among alternative
representations of the same logical property."

Notes:

The corrected text "not defined" is intended as a literal statement of the consequences of the current specification and not a change to the meaning of the current specification. The submitter recommends that the text "Values for the group and for the PREF parameter MUST be the same..." be considered for future versions of this document.

It is also requested that the example below be added to the "legal but questionable" list in section 5.4.

Section 3.3 contains the text:

"The group construct is used to group related properties together.
The group name is a syntactic convention used to indicate that all
property names prefaced with the same group name SHOULD be grouped
together when displayed by an application."

There is no valid interpretation available for an application if a logical property has more than one group (see example below) and clearly no way to display such properties together, therefore the group construct has no defined meaning for such a case. This is particularly troublesome when converting to formats such as the VCard XML Schema where the group is represented as an XML schema in which properties are contained.

Also, Section 5.3 states in reference to the PREF parameter:

"Note that the value of this parameter is to be interpreted only in
relation to values assigned to other instances of the same property
in the same vCard. A given value, or the absence of a value, MUST
NOT be interpreted on its own."

The meaning of "instances of the same property" is not decipherable with respect to logical properties which differ in their PREF parameter value, therefore application behavior is also not defined for this case.

Example:

volunteer.ORG;ALTID=1;PREF=1;LANGUAGE=en:Doctors Without Borders
causes.ORG;ALTID=1;LANGUAGE=fr:Médecins Sans Frontières
volunteer.ORG:Community Emergency Response Team;Some County\, Some State
volunteer.ROLE:CERT Instructor
ORG;TYPE=WORK:Sometown Medical Center

The alternative representation of "Doctors Without Borders" is legal according to the current text but breaks the 'volunteer' grouping: the same logical property is requested by the VCard to appear in two places. Similarly, the PREF tag on "Doctors Without Borders" is legal but nonsensical. The logical application representation of the ORG properties with ALTID=1 as the same logical property breaks sort ordering or selection by PREF. Similarly, application representation of PREF as a priority queue of properties breaks for this case. The application is forced to drop consideration of PREF and group in these cases and should be explicitly allowed to do so (even though it may support PREF and grouping in the general case).

======================================
======================================

Verifier notes:

This is a complicated issue that needs discussion and that goes well beyond what errata can cover. I'm marking this as "held for document update" to leave the introduction to the issue here, because the confusion about how to interoperate here is real. But readers need to follow any subsequent discussion on the vcarddav mailing list.
======================================

Errata ID: 4245
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Ivan Enderlin
Date Reported: 2015-01-27
Held for Document Update by: Barry Leiba
Date Held: 2015-03-02

Section 6.7.7 says:

   Value type:  A semicolon-separated pair of values.  The first field
      is a small integer corresponding to the second field of a PID
      parameter instance.  The second field is a URI.  The "uuid" URN
      namespace defined in [RFC4122] is particularly well suited to this
      task, but other URI schemes MAY be used.

It should say:

   Value type:  A single structured text value consisting of components
      separated by the SEMICOLON character (U+003B). The first
      component is a small integer corresponding to the second
      component of a PID parameter instance.  The second component is a
      URI. The "uuid" URN namespace defined in [RFC4122] is particularly
      well suited to this task, but other URI schemes MAY be used.

Notes:

A “semicolon-separated pair of values” is a structured text value. Moreover, the RFC6351 considers the CLIENTPIDMAP property with a structured text value (see the Relax NG Schema definition of property-clientpidmap).

----- Verifier Notes -----
The original text would not cause any real confusion or interoperability issues, so this is held for document update. That said, the corrected text is more accurate and better represents the working group's consensus at the time the RFC was published.

Errata ID: 3005
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: David Keegel
Date Reported: 2011-10-25
Held for Document Update by: Peter Saint-Andre

Section 6.5.1 says:

          Examples:

            TZ:Raleigh/North America

It should say:

          Examples:

            TZ:America/New_York

Notes:

The example given is not valid for the Olson/TZ database; it includes a space, it has the specific location (city) before the continent, neither city nor continent names are present for the current TZ database, and there isnt a separate time zone for Raleigh, NC (since Raleigh's clocks have always matched New York's since 1970, Raleigh uses America/New_York as its time zone name in the Olson database).

Errata ID: 3062
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Peter K. Sheerin
Date Reported: 2011-12-25
Held for Document Update by: Pete Resnick
Date Held: 2011-12-29

Section 6.4.2 says:

   Special notes:  The property can include tye "PREF" parameter to
      indicate a preferred-use email address when more than one is
      specified.

It should say:

   Special notes:  The property can include the "PREF" parameter to
      indicate a preferred-use email address when more than one is
      specified.

Notes:

Simple misspelling of "the"

RFC 6351, "xCard: vCard XML Representation", August 2011

Note: This RFC has been updated by RFC 6868

Source of RFC: vcarddav (app)

Errata ID: 3008
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Torsten Fusswinkel
Date Reported: 2011-10-31
Held for Document Update by: Peter Saint-Andre

Section Appendix A says:

### Section 3.3: vCard Format Specification
#
# 3.3
iana-token = xsd:string { pattern = "[a-zA-Z0-9-]+" }
x-name = xsd:string { pattern = "x-[a-zA-Z0-9-]+" }

It should say:

### Section 3.3: vCard Format Specification
#
# 3.3
iana-token = xsd:string { pattern = "[a-zA-Z0-9\-]+" }
x-name = xsd:string { pattern = "x-[a-zA-Z0-9\-]+" }

Notes:

The minus sign has to be escaped with a backslash.

RFC 6371, "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", September 2011

Note: This RFC has been updated by RFC 6435

Source of RFC: mpls (rtg)

Errata ID: 3958
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Liu Lin
Date Reported: 2014-04-11
Held for Document Update by: Adrian Farrel
Date Held: 2014-04-11

Section 3.3 says:

Figure 3 describes four examples of per-interface Up MEPs: an Up
   Source MEP in a source node (case 1), an Up Sink MEP in a destination
   node (case 2), a Down Source MEP in a source node (case 3), and a
   Down Sink MEP in a destination node (case 4).

It should say:

Figure 3 describes four examples of per-interface MEPs: an Up
   Source MEP in a source node (case 1), an Up Sink MEP in a destination
   node (case 2), a Down Source MEP in a source node (case 3), and a
   Down Sink MEP in a destination node (case 4).

Notes:

per-interface Up MEPs ----> per-interface MEPs

The four instances listed include Up and Down MEPs, so the text should be more general.

Errata ID: 3961
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Liu Lin
Date Reported: 2014-04-11
Held for Document Update by: Adrian Farrel
Date Held: 2014-04-12

Section 3.7 says:

      This packet
      will be delivered by the forwarding plane to all intermediate
      nodes at the same TTL distance of the target MIP and to any leaf
      that is located at a shorter distance.

It should say:

      This packet
      will be delivered by the forwarding plane to all
      nodes at the same TTL distance as the target MIP and to any leaf
      that is located at a shorter distance.

Notes:

The packet will also be deliverd to any leaf that has the same TTL distance of the target MIP.

Errata ID: 3963
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Liu Lin
Date Reported: 2014-04-15
Held for Document Update by: Adrian Farrel
Date Held: 2014-04-15

Section 7.1.2 says:

The peer MEP, upon receiving an LKI removal request, can either
   accept or reject the removal instruction and replies with an LK
   removal reply OAM packet indicating whether or not it has accepted
   the instruction.

It should say:

The peer MEP, upon receiving an LKI removal request, can either
   accept or reject the removal instruction and replies with an LKI
   removal reply OAM packet indicating whether or not it has accepted
   the instruction.

Notes:

LK ---> LKI

RFC 6376, "DomainKeys Identified Mail (DKIM) Signatures", September 2011

Note: This RFC has been updated by RFC 8301, RFC 8463, RFC 8553, RFC 8616

Source of RFC: dkim (sec)

Errata ID: 6254
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Dave Crocker
Date Reported: 2020-08-08
Held for Document Update by: Murray Kucherawy
Date Held: 2021-12-02

Section 5.4 says:

Notes:

The "INFORMATIVE OPERATIONS NOTE" early in Section 5.4 appears to be in conflict with Section 5.4.1. They appear to cover the same issue, namely what header fields to use for the signature, but they seem to give different advice. (Though not formally an erratum, there is also the matter of thinking that what is shown the the recipient is relevant...) /d

Errata ID: 6769
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Ale Vesely
Date Reported: 2021-12-01
Held for Document Update by: Murray Kucherawy
Date Held: 2021-12-02

Section 8.2 says:

An example of such an attack includes altering the MIME structure,
exploiting lax HTML parsing in the MUA, and defeating duplicate
message detection algorithms.

It should say:

In case of MIME structures, the value of l= should cover all of the
body, including the terminating boundary and the epilogue, so that
altering the structure is not feasible.  In any case, if l= is set and
Content-Type is not signed, an attacker can replace it with a multipart
type and thus relegate the original body to the role of a MIME preamble.

Notes:

Duplicate message detection algorithms should consider Message-ID. When they compare the body, they should be sophisticated enough to recognize specific key fields, for example to avoid accumulating duplicate values of financial transactions.

Errata ID: 3017
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vernon Tang
Date Reported: 2011-11-05
Held for Document Update by: Barry Leiba
Date Held: 2019-04-30

Section 3.6.1 says:

   k= Key type (plain-text; OPTIONAL, default is "rsa").  Signers and
      Verifiers MUST support the "rsa" key type.  The "rsa" key type
      indicates that an ASN.1 DER-encoded [ITU-X660-1997] RSAPublicKey
      (see [RFC3447], Sections 3.1 and A.1.1) is being used in the "p="
      tag.  (Note: the "p=" tag further encodes the value using the
      base64 algorithm.)  Unrecognized key types MUST be ignored.

It should say:

   k= Key type (plain-text; OPTIONAL, default is "rsa").  Signers and
      Verifiers MUST support the "rsa" key type.  The "rsa" key type
      indicates that an ASN.1 DER-encoded [ITU-X660-1997] RSAPublicKey
      (see [RFC3447], Sections 3.1 and A.1.1), which MAY be contained in
      a SubjectPublicKeyInfo (see [RFC5280], Section A.1), is being used
      in the "p=" tag.  (Note: the "p=" tag further encodes the value
      using the base64 algorithm.)  Unrecognized key types MUST be
      ignored.

Notes:

The procedure in Appendix C results in a public key in SubjectPublicKeyInfo format. Accordingly, most current implementations will accept such keys. Furthermore, it is trivial to distinguish whether a key is encapsulated in a SubjectPublicKeyInfo.

Errata ID: 4875
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Emiel Bruijntjes
Date Reported: 2016-12-01

Section 3.5 says:

The header field text itself must encode the vertical bar
("|", %x7C) character (i.e., vertical bars in the "z=" text are
meta-characters, and any actual vertical bar characters in a
copied header field must be encoded).  Note that all whitespace
must be encoded, including whitespace between the colon and the
header field value.  After encoding, FWS MAY be added at arbitrary
locations in order to avoid excessively long lines; such
whitespace is NOT part of the value of the header field and MUST
be removed before decoding.

It should say:

The header field value itself must encode the vertical bar
("|", %x7C) character (i.e., vertical bars in the "z=" text are
meta-characters, and any actual vertical bar characters in a
copied header field must be encoded).  Note that all whitespace
must be encoded, including whitespace between the colon and the
header field value.  After encoding, FWS MAY be added at arbitrary
locations inside the header field value in order to avoid 
excessively long lines; such whitespace is NOT part of the value 
of the header field and MUST be removed before decoding. FWS MAY NOT
be added to the header field name.

Notes:

The original text is confusing on whether FWS may be added to just the header field values or to both the header field names and header field values. The ABNF suggests that it is just allowed inside the values, but we've seen in practice that this whitespace is also added to the field names.

Further more, the use of the three terms "header field name", "header field value" and "header field text" is confusing. It is better to stick with just "header field name" and "header field value".

RFC 6392, "A Survey of In-Network Storage Systems", October 2011

Source of RFC: decade (tsv)

Errata ID: 3006
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2011-10-26
Held for Document Update by: Wes Eddy

Section 5.1.2 says:

Not provided.

It should say:

Basic deletion of resources is provided with the DELETE method.

Notes:

The typical "data management operation" mentioned for other protocols is the deletion of data. HTTP has it from the beginning (Section 9.7 of RFC 2616).

Apache does not support it directly, you apparently have to provide a module which does it (mod_dav does it, even if DELETE is not a WebDAV method). Anyway, this section is about the abilities of the protocol, not of implementations.

RFC 6396, "Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format", October 2011

Source of RFC: grow (ops)

Errata ID: 3817
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramakrishna DTV
Date Reported: 2013-12-01
Held for Document Update by: Benoit Claise
Date Held: 2014-04-16

Section 5.7 says:

            BGP4MP_ENTRY             2           See Section 4.4
            BGP4MP_SNAPSHOT          3           See Section 4.4

It should say:

            BGP4MP_ENTRY             2           See Section B.2.6
            BGP4MP_SNAPSHOT          3           See Section B.2.6

Notes:

These subtypes are deprecated and are defined only in Appendix B.

RFC 6402, "Certificate Management over CMS (CMC) Updates", November 2011

Source of RFC: pkix (sec)

Errata ID: 3943
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Jim Schaad
Date Reported: 2014-04-02
Held for Document Update by: Benjamin Kaduk
Date Held: 2019-12-16

Section 2.8, says:

      ChangeSubjectName ::= SEQUENCE {
          subject             Name OPTIONAL,
          subjectAlt          SubjectAltName OPTIONAL
      }
      (WITH COMPONENTS {..., subject PRESENT} |
            COMPONENTS {..., subjectAlt PRESENT} )

It should say:

      ChangeSubjectName ::= SEQUENCE {
          subject             Name OPTIONAL,
          subjectAlt          [1] SubjectAltName OPTIONAL
      }
      (WITH COMPONENTS {..., subject PRESENT} |
            COMPONENTS {..., subjectAlt PRESENT} )

Notes:

Both Name and SubjectAltName use the same tag (SEQUENCE) so it is not possible to distinguish between the two fields without having a tag on one of them. This fix adds an (arbitrarily chosen) tag so that it is possible to differentiate the two fields.

RFC 6407, "The Group Domain of Interpretation", October 2011

Source of RFC: msec (sec)

Errata ID: 3600
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Claude Briere de L'Isle
Date Reported: 2013-04-20
Held for Document Update by: Sean Turner

Section 7.4 says:

The concepts "forward access
control" and "backward access control" have also been described as
"perfect forward security" and "perfect backward security",
respectively, in the literature [RFC2627].

It should say:

The concepts "forward access 
control" and "backward access control" have also been described as 
"perfect forward security" and "perfect backward security",
respectively, in the literature
(<http://tools.ietf.org/id/draft-balenson-groupkeymgmt-oft-00.txt>).

Notes:

There is no occurrence of these terms in RFC 2627. Brian Weiss wrote : "You are correct. I see that this wording was carried from early versions of an Internet-draft that became RFC 3547, the predecessor of RFC6407. A more accurate reference for these terms would be <http://tools.ietf.org/id/draft-balenson-groupkeymgmt-oft-00.txt>

Errata ID: 3861
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Prashant Gupta
Date Reported: 2014-01-07
Held for Document Update by: Sean Turner
Date Held: 2014-01-20

Section 1 says:

Secure group and multicast applications require a method by which
   each group member shares common security policy and keying material.
   This document describes the Group Domain of Interpretation (GDOI),
   which is an Internet Security Association and Key Management Protocol
   (ISAMKP) [RFC2408] Domain of Interpretation (DOI), a group key
   management system. 

It should say:

Secure group and multicast applications require a method by which
   each group member shares common security policy and keying material.
   This document describes the Group Domain of Interpretation (GDOI),
   which is an Internet Security Association and Key Management Protocol
   (ISAKMP) [RFC2408] Domain of Interpretation (DOI), a group key
   management system. 

Notes:

ISAMKP -> ISAKMP

RFC 6415, "Web Host Metadata", October 2011

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 3118
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Christian Weiske
Date Reported: 2012-02-09
Held for Document Update by: Peter Saint-Andre
Date Held: 2012-02-27

Section Appendix A. says:

      <Subject>http://blog.example.com/article/id/314</Subject>
      <Expires>2010-01-30T09:30:00Z</Expires>

It should say:

      <Expires>2010-01-30T09:30:00Z</Expires>
      <Subject>http://blog.example.com/article/id/314</Subject>

Notes:

The XML example in Appendix A. has the Subject before the Expires tag, which is wrong.

XRD 1.0 defines[1] the <XRD> element as a "sequence" with <Expires> first, <Subject> second. A sequence is defined[2] as "Sequence (the element information items match the particles in sequential order);".

PSA: Because this is a minor problem with a non-normative example, processing as "Hold For Document Update". -- Peter Saint-Andre

[1] http://docs.oasis-open.org/xri/xrd/v1.0/xrd-1.0.html#element.xrd
[2] http://www.w3.org/TR/xmlschema-1/#Model_Group

RFC 6418, "Multiple Interfaces and Provisioning Domains Problem Statement", November 2011

Source of RFC: mif (int)

Errata ID: 3057
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Zhou Sujing
Date Reported: 2011-12-21
Held for Document Update by: Brian Haberman

Section 4.4 says:

For instance, the network may perform HTTP redirection or modify DNS behavior (Section 4.1) until the user has not authenticated.

It should say:

For instance, the network may perform HTTP redirection or modify DNS behavior (Section 4.1) until the user has been authenticated.

Errata ID: 3058
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Zhou Sujing
Date Reported: 2011-12-21
Held for Document Update by: Brian Haberman

Section 4. 1 says:

Until the user has not authenticated
When the user has not authenticated

It should say:

Until the user has been authenticated
When the user has been authenticated

RFC 6434, "IPv6 Node Requirements", December 2011

Note: This RFC has been obsoleted by RFC 8504

Source of RFC: 6man (int)

Errata ID: 3073
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Loughney
Date Reported: 2012-01-04
Held for Document Update by: Brian Haberman

Section 15.2 says:

15.2.  Authors and Acknowledgments from RFC 4279

   The original version of this document (RFC 4279) was written by the
   IPv6 Node Requirements design team:

It should say:

15.2.  Authors and Acknowledgments from RFC 4294  

   The original version of this document (RFC 4294 ) was written by the
   IPv6 Node Requirements design team:

Notes:

RFC 4279 is the TLS RFC.

Errata ID: 3091
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sam Silvester
Date Reported: 2012-01-16
Held for Document Update by: Brian Haberman

Section 5.10 says:

   Nodes supporting applications that expect
   to only take advantage of MLDv2's INCLUDE functionality as well as
   Any-Source Multicast will find it sufficient to support MLDv2 as
   defined in [RFC5790].

It should say:

   Nodes supporting applications that expect 
   to only take advantage of MLDv2's INCLUDE functionality as well as 
   Any-Source Multicast will find it sufficient to support Lightweight 
   MLDv2 as defined in [RFC5790].

Notes:

MLDv2 is RFC3810, and has both INCLUDE and EXCLUDE filter modes (as per previous paragraph.

RFC5790 (Lightweight MLDv2) is sufficient for nodes supporting application using only INCLUDE and Any-Source Multicast.

RFC 6455, "The WebSocket Protocol", December 2011

Note: This RFC has been updated by RFC 7936, RFC 8307, RFC 8441

Source of RFC: hybi (app)

Errata ID: 3227
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexey Melnikov
Date Reported: 2012-05-16
Held for Document Update by: Barry Leiba

Section 7.4.1 says:

   1011

      1011 indicates that a server is terminating the connection because
      it encountered an unexpected condition that prevented it from
      fulfilling the request.

It should say:

   1011

      1011 indicates that a remote endpoint is terminating the connection
      because it encountered an unexpected condition that prevented it from
      fulfilling the request.

Notes:

As per the discussion in the WG (See <http://www.ietf.org/mail-archive/web/hybi/current/msg09628.html>) the meaning of this error close code should be extended to cover clients as well. As the Designated Expert for the WebSocket close code registry I've approved the corresponding change to the IANA registry.

This should be "hold for update" for rfc6455bis.

Errata ID: 3432
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Eric Lawrence
Date Reported: 2012-12-18
Held for Document Update by: Barry Leiba
Date Held: 2012-12-18

Section 5.7 says:

   o  Unmasked Ping request and masked Ping response

      *  0x89 0x05 0x48 0x65 0x6c 0x6c 0x6f (contains a body of "Hello",
         but the contents of the body are arbitrary)

      *  0x8a 0x85 0x37 0xfa 0x21 0x3d 0x7f 0x9f 0x4d 0x51 0x58
         (contains a body of "Hello", matching the body of the ping)

It should say:

   o  Unmasked Ping request and masked Pong response

      *  0x89 0x05 0x48 0x65 0x6c 0x6c 0x6f (contains a body of "Hello",
         but the contents of the body are arbitrary)

      *  0x8a 0x85 0x37 0xfa 0x21 0x3d 0x7f 0x9f 0x4d 0x51 0x58
         (contains a body of "Hello", matching the body of the ping)

Notes:

The response isn't a Ping, it's a Pong.
--VERIFIER NOTES--
The errata system is meant for documentation errors that could cause implementation confusion. I don't think this will confuse anyone.

Errata ID: 4398
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Mike West
Date Reported: 2015-06-24
Held for Document Update by: Barry Leiba
Date Held: 2015-06-24

Section 4.1 says:

1. The components of the WebSocket URI passed into this algorithm
   (/host/, /port/, /resource name/, and /secure/ flag) MUST be
   valid according to the specification of WebSocket URIs specified
   in Section 3.  If any of the components are invalid, the client
   MUST _Fail the WebSocket Connection_ and abort these steps.

It should say:

1. The components of the WebSocket URI passed into this algorithm
   (/host/, /port/, /resource name/, and /secure/ flag) MUST be
   valid according to the specification of WebSocket URIs specified
   in Section 3.  If any of the components are invalid, the client
   MUST _Fail the WebSocket Connection_ and abort these steps.

2. If secure is false, and the algorithm in Mixed Content's "§5.1
   Does settings object restrict mixed content?" returns Restricts
   Mixed Content when applied to client's entry script's relevant
   settings object's, then the client MUST fail the WebSocket
   connection and abort the connection.

Notes:

This change is suggested by the W3C's "Mixed Content" document (https://w3c.github.io/webappsec/specs/mixedcontent/#websockets-integration), and will bring WebSockets' behaviors into line with XMLHttpRequest, EventSource, and Fetch, all of which act as though there was a network error when blocking a mixed content request, rather than throwing a SecurityError exception.

Errata ID: 5498
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Patrick McManus
Date Reported: 2018-09-14
Held for Document Update by: Alexey Melnikov
Date Held: 2018-09-20

Section 11.2 says:

   Name of token
      WebSocket

It should say:

   Name of token
      websocket

Notes:

The HTTP bootstrap request is required to use an upgrade token of all lowercase "websocket" -

5. The request MUST contain an |Upgrade| header field whose value
MUST include the "websocket" keyword.

The registration is for "WebSocket" (capital W and capital S). In practice "websocket" is used.

Although the interpretation of that is defined case-insensitively for this RFC (which conflicts with general HTTP semantics where this is case sensitive). As part of RFC 8441, the IANA registry has been updated to also include "websocket" with a reference to both RFC 6455 and RFC 8441.

imo this errata should be held for update and the reference to "WebSocket" removed at that time.

See also https://www.rfc-editor.org/errata/eid5453

RFC 6458, "Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)", December 2011

Source of RFC: tsvwg (wit)

Errata ID: 4921
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Jonathan Leighton
Date Reported: 2017-02-02
Held for Document Update by: Martin Duke
Date Held: 2020-04-27

Section 9.1 says:

If sd is an IPv4 socket, the addresses passed must be IPv4 addresses.
If the sd is an IPv6 socket, the addresses passed can either be IPv4
or IPv6 addresses.

It should say:

If sd is an IPv4 socket, the passed addresses must be IPv4 addresses.
If sd is an IPv6 socket, the passed addresses must be IPv6 addresses.
Use IPv4-mapped IPv6 addresses to bind an IPv6 socket to an IPv4
address. Note that some implementations optionally allow IPv4 addresses
to be passed in directly.

Notes:

The erratum is a subtle change in meaning that would be a useful clarification.

Errata ID: 6116
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Tuexen
Date Reported: 2020-04-20
Held for Document Update by: Martin Duke
Date Held: 2020-04-27

Section 6.1.2 says:

   spc_state:  This field holds one of a number of values that
      communicate the event that happened to the address.  They include

      SCTP_ADDR_AVAILABLE:  This address is now reachable.  This
         notification is provided whenever an address becomes reachable.

      SCTP_ADDR_UNREACHABLE:  The address specified can no longer be
         reached.  Any data sent to this address is rerouted to an
         alternate until this address becomes reachable.  This
         notification is provided whenever an address becomes
         unreachable.

      SCTP_ADDR_REMOVED:  The address is no longer part of the
         association.

      SCTP_ADDR_ADDED:  The address is now part of the association.

      SCTP_ADDR_MADE_PRIM:  This address has now been made the primary
         destination address.  This notification is provided whenever an
         address is made primary.

It should say:

   spc_state:  This field holds one of a number of values that
      communicate the event that happened to the address.  They include

      SCTP_ADDR_CONFIRMED:  This address is now confirmed.  This
         notification is provided once an address transitions from
         the UNCONFIRMED state to the CONFIRMED state (see
         Section 5.4 of [RFC 4960]).

      SCTP_ADDR_AVAILABLE:  This address is now reachable.  This
         notification is provided whenever an address becomes reachable.

      SCTP_ADDR_UNREACHABLE:  The address specified can no longer be
         reached.  Any data sent to this address is rerouted to an
         alternate until this address becomes reachable.  This
         notification is provided whenever an address becomes
         unreachable.

      SCTP_ADDR_REMOVED:  The address is no longer part of the
         association.

      SCTP_ADDR_ADDED:  The address is now part of the association.

      SCTP_ADDR_MADE_PRIM:  This address has now been made the primary
         destination address.  This notification is provided whenever an
         address is made primary.

Notes:

A description of the handling of the path verification as specified in Section 5.4 of RFC 4960 was missing.

Errata ID: 6113
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Tuexen
Date Reported: 2020-04-20
Held for Document Update by: Martin Duke
Date Held: 2020-04-27

Section 6.1.1 says:

sac_info:  If sac_state is SCTP_COMM_LOST and an ABORT chunk was
      received for this association, sac_info[] contains the complete
      ABORT chunk as defined in Section 3.3.7 of the SCTP specification
      [RFC4960].

It should say:

sac_info:  If sac_state is SCTP_COMM_LOST or SCTP_CANT_STR_ASSOC and
      an ABORT chunk was received for this association, sac_info[]
      contains the complete ABORT chunk as defined in Section 3.3.7
      of the SCTP specification [RFC4960].

Notes:

During association setup, SCTP_CANT_STR_ASSOC is signalled when an ABORT chunk is received. SCTP_COMM_LOST is used after the association has been established.

Errata ID: 6114
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Tuexen
Date Reported: 2020-04-20
Held for Document Update by: Martin Duke
Date Held: 2020-04-27

Section 9.5 says:

If the id field is set to the value '0', then the locally bound
addresses are returned without regard to any particular association.

It should say:

If the id field is set to the value SCTP_FUTURE_ASSOC, then the locally bound
addresses are returned without regard to any particular association.

Notes:

Don't use a numeric constant, but the symbolic constant. Its numeric value is implementation specific.

RFC 6470, "Network Configuration Protocol (NETCONF) Base Notifications", February 2012

Source of RFC: netconf (ops)

Errata ID: 4073
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Andy Bierman
Date Reported: 2014-08-07
Held for Document Update by: Benoit Claise
Date Held: 2014-09-17

Section 2.2 says:

   <CODE BEGINS> file="ietf-netconf-notifications@2011-12-09.yang"

It should say:

   <CODE BEGINS> file="ietf-netconf-notifications@2012-02-06.yang"

Notes:

Reported to me by Martin Bjorklund

RFC 6476, "Using Message Authentication Code (MAC) Encryption in the Cryptographic Message Syntax (CMS)", January 2012

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 4060
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Gutmann
Date Reported: 2014-07-23
Held for Document Update by: Kathleen Moriarty
Date Held: 2015-03-24

Section 4 says:

parameters have the value 08 00 02 01 01.

It should say:

parameters have the value 04 00 02 01 01.

Notes:

The text with the encoded form was added at the request of a reviewer who felt that providing only the ASN.1 might lead to developers getting the encoding wrong. Ironically, this had the opposite effect to what was intended for anyone who used the encoded form rather than just going with the ASN.1.

Errata report was verified by the editor of this RFC.

RFC 6480, "An Infrastructure to Support Secure Internet Routing", February 2012

Source of RFC: sidr (rtg)

Errata ID: 5196
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2017-12-05
Held for Document Update by: Alvaro Retana
Date Held: 2017-12-08

Section 6 says:

      3. For each manifest, verify that certificates and CRLs issued
         under the corresponding CA certificate match the hash values
         contained in the manifest.  Additionally, verify that no
         certificate or manifest listed on the manifest is missing from
         the repository.  If the hash values do not match, or if any
         certificate or CRL is missing, notify the appropriate
         repository administrator that the repository data has been
         corrupted.

It should say:

      3. For each manifest, verify that certificates and CRLs issued
         under the corresponding CA certificate match the hash values
         contained in the manifest.  Additionally, verify that no
         certificate or CRL listed on the manifest is missing from
         the repository.  If the hash values do not match, or if any
         certificate or CRL is missing, notify the appropriate
         repository administrator that the repository data has been
         corrupted.

Notes:

On the fourth line: it should read "certificate or CRL" instead of "certificate or manifest".

RFC 6485, "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI)", February 2012

Note: This RFC has been obsoleted by RFC 7935

Source of RFC: sidr (rtg)

Errata ID: 3162
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Danny Rios
Date Reported: 2012-03-23
Held for Document Update by: Stewart Bryant

Section 9 says:

9.  Normative References

It should say:

8.  Normative References

Notes:

Section 8 was incorrectly numbered as section 9 in final RFC. This was due to the draft including a section 7 for "IANA Considerations," which was later removed.

Errata ID: 4340
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Richard Hansen
Date Reported: 2015-04-20
Held for Document Update by: Alvaro Retana
Date Held: 2015-05-21

Section 1 says:

                                           the SIDR Architecture
   [RFC6480],

It should say:

                                           the RPKI Architecture
   [RFC6480],

Notes:

Neither "SIDR" nor "Secure Inter-Domain Routing" is mentioned in RFC6480. RFC6480 is about the design of the RPKI, so "RPKI Architecture" seems like a more appropriate fit.

RFC 6487, "A Profile for X.509 PKIX Resource Certificates", February 2012

Note: This RFC has been updated by RFC 7318, RFC 8209

Source of RFC: sidr (rtg)

Errata ID: 6854
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Corey Bonnell
Date Reported: 2022-02-16
Held for Document Update by: John Scudder
Date Held: 2022-05-24

Section 4.8.1 says:

   The Basic Constraints extension field is a critical extension in the
   resource certificate profile, and MUST be present when the subject is
   a CA, and MUST NOT be present otherwise.

   The issuer determines whether the "cA" boolean is set.

It should say:

   The Basic Constraints extension field is critical and MUST be present 
   when the "cA" field is TRUE, otherwise it MUST NOT be present.

Notes:

See discussion at https://mailarchive.ietf.org/arch/msg/sidrops/dPCiDz_pDR68G4cTC8W7X5LTE5o/

The original text is tautological -- Since according to RFC 5280 §4.2.1.9 the "cA" boolean MUST be set when the subject is a CA, and MUST NOT be set when the subject is not a CA, then it's axiomatic that

cA boolean set <=> Basic Constraints field present <=> subject is a CA

Although the original text is not strictly speaking wrong, it's potentially misleading since it could be read as implying that it's possible to have the cA boolean FALSE in a CA certificate, which is not so.

Errata ID: 5187
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2017-11-28
Held for Document Update by: Alvaro Retana
Date Held: 2017-12-01

Section 7.1 says:

      encompass
         Given two IP address and AS number sets, X and Y, X
         "encompasses" Y if, for every contiguous range of IP addresses
         or AS numbers elements in set Y, the range element is either
         "more specific" than or "equal" to a contiguous range element
         within the set X.

It should say:

      encompass
         Given two IP address or two AS number sets, X and Y, X
         "encompasses" Y if, for every contiguous range of IP addresses
         or AS numbers elements in set Y, the range element is either
         "more specific" than or "equal" to a contiguous range element
         within the set X.

Errata ID: 5188
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2017-11-28
Held for Document Update by: Alvaro Retana
Date Held: 2017-11-28

Section 7.1 says:

   Validation of a certificate's resource extension in the context of a
   certification path (see Section 7.2 entails that for every adjacent

It should say:

   Validation of a certificate's resource extension in the context of a
   certification path (see Section 7.2) entails that for every adjacent

Notes:

The closing parenthesis is missing.

Errata ID: 5190
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2017-11-28
Held for Document Update by: Alvaro Retana
Date Held: 2017-12-01

Section 8 says:

         3) A randomly generated ASCII HEX encoded string of length 20
            or greater:
            example: cn="0f8fcc28e3be4869bc5f8fa114db05e1">
            (A string of 20 ASCII HEX digits would have 80-bits of
            entropy)

It should say:

         3) A randomly generated ASCII HEX encoded string of length 20
            or greater:
            example: cn="0f8fcc28e3be4869bc5f8fa114db05e1"
            (A string of 20 ASCII HEX digits would have 80-bits of
            entropy)

Notes:

Typo

Errata ID: 5191
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2017-11-28
Held for Document Update by: Alvaro Retana
Date Held: 2017-12-01

Section 8 says:

            (The issuing CA may wish to be able to extract the database
            key or subscriber ID from the commonName.  Since only the
            issuing CA would need to be able to parse the commonName,
            the database key and the source of entropy (e.g., a UUID)
            could be separated in any way that the CA wants, as long as
            it conforms to the rules for PrintableString.  The separator




Huston, et al.               Standards Track                   [Page 21]

RFC 6487              Resource Certificate Profile         February 2012


            could be a space character, parenthesis, hyphen, slash,
            question mark, etc.

It should say:

            (The issuing CA may wish to be able to extract the database
            key or subscriber ID from the commonName.  Since only the
            issuing CA would need to be able to parse the commonName,
            the database key and the source of entropy (e.g., a UUID)
            could be separated in any way that the CA wants, as long as
            it conforms to the rules for PrintableString.  The separator




Huston, et al.               Standards Track                   [Page 21]

RFC 6487              Resource Certificate Profile         February 2012


            could be a space character, parenthesis, hyphen, slash,
            question mark, etc).

Notes:

The closing parenthesis is missing.

RFC 6488, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", February 2012

Source of RFC: sidr (rtg)

Errata ID: 3203
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: David Mandelberg
Date Reported: 2012-04-26
Held for Document Update by: Stewart Bryant

Section Table of Con says:

                  2.1.6.7. unsigneAttrs ...............................8

It should say:

                  2.1.6.7. unsignedAttrs ..............................8

RFC 6493, "The Resource Public Key Infrastructure (RPKI) Ghostbusters Record", February 2012

Source of RFC: sidr (rtg)

Errata ID: 3654
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Joël Repiquet
Date Reported: 2013-06-15
Held for Document Update by: Stewart Bryant

Section 5 says:

   VERSION -  pro forma packaging that MUST be the second line in the
      vCard and MUST have the value "VERSION:4.0" as described in
      Section 3.7.9 of [RFC6350].

It should say:

   VERSION -  pro forma packaging that MUST be the second line in the
      vCard and MUST have the value "VERSION:4.0" as described in
      Section 6.7.9 of [RFC6350].

RFC 6503, "Centralized Conferencing Manipulation Protocol", March 2012

Source of RFC: xcon (rai)

Errata ID: 3698
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Amanda Baber
Date Reported: 2013-08-20
Held for Document Update by: Richard Barnes

Section 12.5.1 says:

This specification establishes the Message sub-registry under
http://www.iana.org/assignments/ccmp-messages.

It should say:

This specification establishes the Message sub-registry under
http://www.iana.org/assignments/ccmp-parameters.

RFC 6505, "A Mixer Control Package for the Media Control Channel Framework", March 2012

Source of RFC: mediactrl (rai)

Errata ID: 3659
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Joël Repiquet
Date Reported: 2013-06-17
Held for Document Update by: Gonzalo Camarillo

Section 4.2.2.4 says:

   id2:  an identifier for either a connection or a conference.  The
      identifier MUST conform to the syntax defined in Section 15.1 of
      [RFC6230].  The attribute is mandatory.

It should say:

   id2:  an identifier for either a connection or a conference.  The
      identifier MUST conform to the syntax defined in Appendix A.1 of
      [RFC6230].  The attribute is mandatory.

RFC 6506, "Supporting Authentication Trailer for OSPFv3", February 2012

Note: This RFC has been obsoleted by RFC 7166

Source of RFC: ospf (rtg)

Errata ID: 3394
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Srinivasan K L
Date Reported: 2012-10-25
Held for Document Update by: Stewart Bryant
Date Held: 2013-09-17

Section 4.5 says:

The OSPFv3 Cryptographic Protocol ID is appended to the
Authentication Key (K) yielding a Protocol-Specific
Authentication Key (Ks). In this application, Ko is always L
octets long and is computed as follows:

If the Protocol-Specific Authentication Key (Ks) is L octets
long, then Ko is equal to K. If the Protocol-Specific
Authentication Key (Ks) is more than L octets long, then Ko is
set to H(Ks). If the Protocol-Specific Authentication Key
(Ks) is less than L octets long, then Ko is set to the
Protocol-Specific Authentication Key (Ks) with zeros appended
to the end of the Protocol-Specific Authentication Key (Ks)
such that Ko is L octets long.

It should say:

Please see - notes

====

The OSPFv3 Cryptographic Protocol ID is appended to the
Authentication Key (K) yielding a Protocol-Specific
Authentication Key (Ks). In this application, Ko is always B
octets long and is computed as follows:

If the Protocol-Specific Authentication Key (Ks) is B octets
long, then Ko is equal to Ks. If the Protocol-Specific
Authentication Key (Ks) is more than B octets long, then Ko is
set to H(Ks) and then appended with (B-L) zeroes to create a 
B octets long string Ko. If the Protocol-Specific Authentication
Key (Ks) is less than B octets long, then Ko is set to the
Protocol-Specific Authentication Key (Ks) with zeros appended
to the end of the Protocol-Specific Authentication Key (Ks)
such that Ko is B octets long.

Notes:

Readers should consult: draft-ietf-ospf-rfc6506bis for the resolution of this Erratum

=====

This is in accordance with RFC2104(HMAC: Keyed-Hashing for Message Authentication). Reproducing the relevant text below:

2. Definition of HMAC

The definition of HMAC requires a cryptographic hash function, which
we denote by H, and a secret key K. We assume H to be a cryptographic
hash function where data is hashed by iterating a basic compression
function on blocks of data. We denote by B the byte-length of such
blocks (B=64 for all the above mentioned examples of hash functions),
and by L the byte-length of hash outputs (L=16 for MD5, L=20 for
SHA-1). The authentication key K can be of any length up to B, the
block length of the hash function. Applications that use keys longer
than B bytes will first hash the key using H and then use the
resultant L byte string as the actual key to HMAC. In any case the
minimal recommended length for K is L bytes (as the hash output
length). See section 3 for more information on keys.


Also, according to FIPS PUB 198, section 5(HMAC SPECIFICATION) :

STEPS
STEP-BY-STEP DESCRIPTION
Step 1
If the length of K = B: set K0 = K. Go to step 4.
Step 2
If the length of K > B: hash K to obtain an L byte string, then append (B-L) zeros to create a B-byte string K0 (i.e., K0 = H(K) || 00...00). Go to step 4.
Step 3
If the length of K < B: append zeros to the end of K to create a B-byte string K0 (e.g., if K is 20 bytes in length and B = 64, then K will be appended with 44 zero bytes 0x00).
Step 4
Exclusive-Or K0 with ipad to produce a B-byte string: K0 ¯ ipad.
Step 5
Append the stream of data 'text' to the string resulting from step 4: (K0 ¯ ipad) || text.
Step 6
Apply H to the stream generated in step 5: H((K0 ¯ ipad) || text).
Step 7
Exclusive-Or K0 with opad: K0 ¯ opad.
Step 8
Append the result from step 6 to step 7: (K0 ¯ opad) || H((K0 ¯ ipad) || text).
Step 9
Apply H to the result from step 8: H((K0 ¯ opad )|| H((K0 &#65455; ipad) || text)).
Step 10
Select the leftmost t bytes of the result of step 9 as the MAC.

Errata ID: 3567
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Marek Karasek
Date Reported: 2013-03-27
Held for Document Update by: Stewart Bryant
Date Held: 2013-09-17

Section 2.2 says:

   Consistent with OSPFv2 Cryptographic Authentication [RFC2328], both
   OSPFv3 header checksum calculation and verification are omitted when
   the OSPFv3 authentication mechanism described in this specification
   is used.

It should say:

Please see notes

=====

OSPFv3 authentication mechanism provides capability to detect 
corruption of OSPFv3 packet, which is under non authenticated 
operation achieved using OSPFv3 header checksum [RFC 5340] 
and LLS data block checksum [RFC 5613]. In spirit of OSPFv2 
Cryptographic Authentication [RFC2328], OSPFv3 header checksum 
and LLS Data Block Checksum calculation and verification 
are omitted when the OSPFv3 authentication mechanism 
described in this specification is used.

Notes:

Readers should consult: draft-ietf-ospf-rfc6506bis for the
resolution of this Erratum

======

RFC does not specify how to work with LLS Data Block Checksum.
Errata suggests omit checksum calculation/verification in the
same way like for OSPFv3 header checksum.

Errata ID: 3568
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Marek Karasek
Date Reported: 2013-03-27
Held for Document Update by: Stewart Bryant
Date Held: 2013-09-17

Section 4.2 says:

OSPFv3 Header Checksum

   Both OSPFv3 header checksum calculation and verification are omitted
   when the OSPFv3 authentication mechanism described in this
   specification is used.  This implies:

   o  For OSPFv3 packets to be transmitted, the OSPFv3 header checksum
      computation is omitted, and the OSPFv3 header checksum SHOULD be
      set to 0 prior to computation of the OSPFv3 Authentication Trailer
      message digest.

   o  For received OSPFv3 packets including an OSPFv3 Authentication
      Trailer, OSPFv3 header checksum verification MUST be omitted.
      However, if the OSPFv3 packet does include a non-zero OSPFv3
      header checksum, it will not be modified by the receiver and will
      simply be included in the OSPFv3 Authentication Trailer message
      digest verification.

It should say:

Please see notes

======

OSPFv3 Header Checksum and LLS Data Block Checksum

OSPFv3 Header Checksum and LLS Data Block Checksum calculation
and verification are omitted when the OSPFv3 authentication 
mechanism described in this specification is used.  This 
implies:

o  For OSPFv3 packets to be transmitted, the OSPFv3 header 
checksum and LLS Data Block checksum computation is omitted, 
and the checksums SHOULD be set to 0 prior to computation 
of the OSPFv3 Authentication Trailer message digest.

o  For received OSPFv3 packets including an OSPFv3 
Authentication Trailer, OSPFv3 header checksum and LLS Data 
Block checksum verification MUST be omitted.  However, 
if the OSPFv3 packet does include a non-zero OSPFv3 header 
or LLS Data Block checksum, it will not be modified by 
the receiver and will simply be included in the OSPFv3 
Authentication Trailer message digest verification.

Notes:

The reader should consult draft-ietf-ospf-rfc6506bis for
the resolution of this erratum

======

RFC does not specify how to work with LLS Data Block
Checksum. Errata suggests omit checksum calculation/
verification in the same way like for OSPFv3 header
checksum.

RFC 6513, "Multicast in MPLS/BGP IP VPNs", February 2012

Note: This RFC has been updated by RFC 7582, RFC 7900, RFC 7988

Source of RFC: l3vpn (rtg)

Errata ID: 3658
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Joël Repiquet
Date Reported: 2013-06-17
Held for Document Update by: Stewart Bryant
Date Held: 2013-09-17

Section 5.3.1 says:

   Whenever a C-multicast route is sent, it must also carry the Selected
   Upstream Multicast Hop corresponding to the C-root address
   (determined by the procedures of Section 5.1).  The Selected Upstream
   Multicast Hop must be encoded as part of a Route Target Extended
   Community to facilitate the optional use of filters that can prevent
   the distribution of the update to BGP speakers other than the
   Upstream Multicast Hop.  See Section 10.1.3 of [MVPN-BGP] for the
   details.

It should say:

   Whenever a C-multicast route is sent, it must also carry the Selected
   Upstream Multicast Hop corresponding to the C-root address
   (determined by the procedures of Section 5.1).  The Selected Upstream
   Multicast Hop must be encoded as part of a Route Target Extended
   Community to facilitate the optional use of filters that can prevent
   the distribution of the update to BGP speakers other than the
   Upstream Multicast Hop.  See Section 11.1.3 of [MVPN-BGP] for the
   details.

RFC 6514, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", February 2012

Note: This RFC has been updated by RFC 6515, RFC 6625, RFC 7385, RFC 7441, RFC 7582, RFC 7899, RFC 7900, RFC 7902, RFC 7988, RFC 8534, RFC 9081

Source of RFC: l3vpn (rtg)

Errata ID: 5724
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Jingrong Xie
Date Reported: 2019-05-20
Held for Document Update by: Alvaro Retana
Date Held: 2022-06-22

Section 11.1.3 says:

The Source AS field in the C-multicast
route is set to value of the Originating Router's IP Address field of
the found Intra-AS I-PMSI A-D route.

It should say:

The Source AS field in the C-multicast
route is set to value of the Originating Router's IP Address field of
the found Intra-AS I-PMSI A-D route when the Originating Router's IP 
Address is an IPv4 address.

Notes:

Source AS field in C-multicast route is a 4-octet field, and only an IPv4 address is possible to be filled in it. The Originating Router's IP Address can be an IPv6 address according to RFC6515.

Errata ID: 3801
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nagendra Kumar
Date Reported: 2013-11-13
Held for Document Update by: Stewart Bryant
Date Held: 2013-11-22

Section 4.1 says:

Usage of Intra-AS I-PMSI A-D routes is described in Section 9.2.

It should say:

Usage of Intra-AS I-PMSI A-D routes is described in Section 9.1.

Notes:

Section 9.2 defines Inter-AS I-PMSI A-D operation and is not the right reference to be called in Section 4.1

Errata ID: 3802
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nagendra Kumar
Date Reported: 2013-11-13
Held for Document Update by: Stewart Bryant
Date Held: 2013-11-22

Section 4.2 says:

Usage of Inter-AS I-PMSI A-D routes is described in Section 9.1

It should say:

Usage of Inter-AS I-PMSI A-D routes is described in Section 9.2

Notes:

Section 9.1 defines Intra-AS I-PMSI A-D operation and is not the right reference to be called in Section 4.2

RFC 6531, "SMTP Extension for Internationalized Email", February 2012

Source of RFC: eai (app)

Errata ID: 4996
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Vitaliy V. Tokarev
Date Reported: 2017-04-16
Held for Document Update by: Alexey Melnikov
Date Held: 2017-09-07

Section 3.3 says:

The definition of <atext> is extended to permit both the RFC 5321
definition and a UTF-8 string. That string MUST NOT contain any
of the ASCII graphics or control characters.

It should say:

The definition of <atext> is extended to permit both the RFC 5321
definition and a UTF-8 string. That string MUST NOT contain any
of the Extended ASCII graphics (%d128-255) or control characters.

Notes:

The question is: what is "ASCII graphics characters"? Either meant that is possible to transmit 8bit characters, but they should not be in range %d128-255. Or something else. A better clarification is appreciated.

Alexey Melnikov: see Ned Freed' reply and the thread that follows <https://www.ietf.org/mail-archive/web/ima/current/msg05506.html>

RFC 6535, "Dual-Stack Hosts Using "Bump-in-the-Host" (BIH)", February 2012

Source of RFC: behave (tsv)

Errata ID: 3221
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Etienne Dublé
Date Reported: 2012-05-10
Held for Document Update by: Wesley Eddy

Section 7 says:

This document recommends the socket API-layer implementation
option over network layer translation, i.e., it recommends the
approach introduced in RFC 2767 over the approach of RFC 3338.

It should say:

This document recommends the socket API-layer implementation 
option over network layer translation, i.e., it recommends the 
approach introduced in RFC 3338 over the approach of RFC 2767.

Notes:

RFC numbers are swapped in this sentence. RFC 3338 describes the socket-API layer implementation, RFC 2767 describes the alternative (network-based) implementation.

RFC 6545, "Real-time Inter-network Defense (RID)", April 2012

Source of RFC: mile (sec)

Errata ID: 3302
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: S Terry Brugger
Date Reported: 2012-07-31
Held for Document Update by: Sean Turner
Date Held: 2012-07-31

Section 7.2.1 says:

   SP-1 is represented by CERT-FOR-OUR-DOMAIN and 192.0.2.67.  SP-2 is
   identified by 192, 0.2.98.  In this example, SP-2 is the service
   provider for systems on the 192.0.2.32/27 subnet.  The contact for
   the host 192.0.2.35 is known at the start of the request as
   'Constituency-contact@10.1.1.2'.

It should say:

   SP-1 is represented by CERT-FOR-OUR-DOMAIN and 192.0.2.67.  SP-2 is
   identified by 192.0.2.98.  In this example, SP-2 is the service
   provider for systems on the 192.0.2.32/27 subnet.  The contact for
   the host 192.0.2.35 is known at the start of the request as
   'Constituency-contact@10.1.1.2'.

Notes:

This could also be considered an Editorial erratum; however, since it is a technically invalid address, I selected Technical.

AD: I marked it as editorial because the correct value is used in the example.

Errata ID: 3303
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: S Terry Brugger
Date Reported: 2012-07-31
Held for Document Update by: Sean Turner

Section 9.5 says:

   o  Protection of data from being viewed by intermediate parties in
      the path of an Request request  should be considered.

It should say:

   o  Protection of data from being viewed by intermediate parties in
      the path of a Request request should be considered.

Errata ID: 5588
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Logan Widick
Date Reported: 2018-12-28
Held for Document Update by: Benjamin Kaduk
Date Held: 2019-01-28

Section 5.1 says:

Page 18 says:

PolicyRegion

      One or many.  REQUIRED.  The values for the attribute "region" are
      used to determine what policy area may require consideration
      before a trace can be approved.  The PolicyRegion may include
      multiple selections from the attribute list in order to fit all
      possible policy considerations when crossing regions, consortiums,
      or networks.

   region

      One or many.  REQUIRED.  ENUM.  The attribute region is used to
      identify the expected sharing range of the incident information.
      The region may be within a region or defined by existing
      relationships such as those of a consortium or a client to a
      service provider.

It should say:

Page 18 should say:

PolicyRegion

      One or many.  REQUIRED.  The values for the attribute "region" are
      used to determine what policy area may require consideration
      before a trace can be approved.  The PolicyRegion may include
      multiple selections from the attribute list in order to fit all
      possible policy considerations when crossing regions, consortiums,
      or networks.

   region

      One.  REQUIRED.  ENUM.  The attribute region is used to
      identify the expected sharing range of the incident information.
      The region may be within a region or defined by existing
      relationships such as those of a consortium or a client to a
      service provider.

Notes:

The text as written (with "One or many" instances of the "region" attribute) suggests that
<PolicyRegion region="ClientToSP" region="SPToClient"/>
would be legal.

However, the schema (Section 8) and the fact that a single XML tag can't contain more than one instance of a given attribute (see https://www.w3.org/TR/xml/#uniqattspec, "An attribute name MUST NOT appear more than once in the same start-tag or empty-element tag") indicate that the above example of a PolicyRegion is not legal, and would need to be replaced with:
<PolicyRegion region="ClientToSP"/>
<PolicyRegion region="SPToClient"/>

RFC 6546, "Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS", April 2012

Source of RFC: mile (sec)

Errata ID: 3277
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Field
Date Reported: 2012-07-03
Held for Document Update by: Sean Turner

Section 3 says:

Table 1 lists the allowable RID message types in an HTTP Response for a given RID message type in the Request.  A RID system MUST be prepared to handle an HTTP Response of the given type(s) when sending the corresponding HTTP Request.  A RID system MUST NOT send an HTTP Response containing any RID message other than the one corresponding to the one sent in the HTTP Request.

(table 1 appears here)

The use of stable DNS names to address RID systems is RECOMMENDED; in addition to facilitating connection to RID systems within a consortium, these are to be used as reference identifiers for a RID system's peers.  For security purposes, RID systems SHOULD NOT return 3xx Redirection response codes, and SHOULD NOT follow any 3xx Redirection.  The protocol provides no in-band method for handling a change of address of a RID system.

It should say:

Insert new text just before table 1:

"An X appearing in the Callback column of Table 1 means that the exchange itself IS a callback.  In these cases the HTTP request contains a RID message that is intended to conclude an earlier RID exchange which initially returned 202.   Note that RID Acknowledgment and RID Result messages can only ever appear in an HTTP request when the message is being generated as a Callback.  However, a RID Report message that appears in an HTTP request may represent either a unsolicited Report, or a delayed Callback.  It is important to note that any RID message that is sent as a Callback must be answered with a 200, and so cannot itself generate yet another Callback."

Notes:

This is a request to insert some additional text to help clarify the meaning of the "X" that appears in the Callback column of table 1. I believe this will be of benefit to implementers who must understand the message exchange patterns described in table 1 in order to properly implement the RID protocol.

RFC 6550, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", March 2012

Note: This RFC has been updated by RFC 9008, RFC 9010

Source of RFC: roll (rtg)

Errata ID: 5160
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Remous-Aris Koutsiamanis
Date Reported: 2017-10-18
Held for Document Update by: Alvaro Retana
Date Held: 2017-11-06

Section 6.7.4 says:

The DAG Metric Container option MAY be present in DIO or DAO
messages, and its format is as follows:

It should say:

The DAG Metric Container option MAY be present in the DIO
message, and its format is as follows:

Notes:

The DAG Metric Container is not defined as one of the valid options in Section 6.4.3.

Errata ID: 3311
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Duong Nguyen
Date Reported: 2012-08-08
Held for Document Update by: Adrian Farrel

Section 6.7.10 says:

   R:    1-bit router address flag.  When set, it indicates that the
         Prefix field contains a complete IPv6 address assigned to the
         sending router that can be used as parent in a target option.

It should say:

   R:    1-bit router address flag.  When set, it indicates that the
         Prefix field contains a complete IPv6 address assigned to the
         sending router that can be used as parent in a transit option.

Notes:

parent address is carried in transit option, not target option.

Errata ID: 3581
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tony Cheneau
Date Reported: 2013-04-04
Held for Document Update by: Adrian Farrel

Section 6.4.3 says:

   A special case of the DAO message, termed a No-Path, is used in
   Storing mode to clear Downward routing state that has been
   provisioned through DAO operation.  The No-Path carries a Target
   option and an associated Transit Information option with a lifetime
   of 0x00000000 to indicate a loss of reachability to that Target.

It should say:

   A special case of the DAO message, termed a No-Path, is used in
   Storing mode to clear Downward routing state that has been
   provisioned through DAO operation.  The No-Path carries a Target
   option and an associated Transit Information option with a lifetime
   of 0x00 to indicate a loss of reachability to that Target.

Notes:

The Path Lifetime field of the Transit Information option is a 8-bit field. Using 0x00000000 here would indicate a 32 bits encoding and is misleading.

Errata ID: 4219
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Richardson
Date Reported: 2015-01-05
Held for Document Update by: Adrian Farrel
Date Held: 2015-01-06

Section 1.0 says:

This document specifies the IPv6 Routing Protocol for LLNs (RPL).
Note that although RPL was specified according to the requirements
set forth in the aforementioned requirement documents, its use is in
no way limited to these applications.

It should say:

This document specifies the IPv6 Routing Protocol for LLNs (RPL).  
The acronym RPL is used extensively in other documents and in 
other acronyms,and it is pronounced "ripple". As such, it is 
appropriate to write "a RPL root" as if the acronym was pronounced, 
rather than "an RPL root" if the letters were spelt out "arr peee ell".

Note that although RPL was specified according to the requirements
set forth in the aforementioned requirement documents, its use is in
no way limited to these applications.

Notes:

Pronunciation of RPL
Newcomers to the IoT space do not know what "ripple" is.
This is recorded as errata so that it does not get lost on 6550bis.

Errata ID: 4457
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dominique Barthel
Date Reported: 2015-08-27
Held for Document Update by: Alvaro Retana
Date Held: 2016-02-15

Section 20.9 says:

in title of section (one instance) and text (two instances)
"DODAG Informational Solicitation"

It should say:

"DODAG Information Solicitation"

Notes:

DIS is defined in Section 2 (Terminology) as "DODAG Information Solicitation".
This acronym is expanded consistently throughout the RFC but in this section.

=== Alvaro Retana ===
Note that this error affects the name of the IANA registry as well. A future revision of this document should request an update to that name as well.

Errata ID: 4458
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dominique Barthel
Date Reported: 2015-08-27
Held for Document Update by: Alvaro Retana
Date Held: 2016-02-15

Section 20.10 says:

No bit is currently defined for the DIS (DODAG Informational
Solicitation) Flags.

It should say:

No bit is currently defined for the DIO (DODAG Information
Object) Flags.

Notes:

This is obviously an erroneous copy-paste from section 20.9

Errata ID: 4618
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yasuyuki Tanaka
Date Reported: 2016-02-13
Held for Document Update by: Alvaro Retana
Date Held: 2016-02-15

Section 6.7.6 says:

Reserved: 7-bit unused field.  The field MUST be initialized to zero
         by the sender and MUST be ignored by the receiver.

It should say:

Reserved: 8-bit unused field.  The field MUST be initialized to zero
         by the sender and MUST be ignored by the receiver.

Notes:

The error is clear, but it should not affect implementations.

Figure 24 clearly shows that the Reserved field of DODAG Configuration options is 8 bits long.

Errata ID: 4654
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Richardson
Date Reported: 2016-04-04
Held for Document Update by: Alvaro Retana
Date Held: 2016-07-14

Section 2, 5.1, 6.3 says:

Section 2 defines DODAGID:

   DODAGID: A DODAGID is the identifier of a DODAG root.  The DODAGID is
         unique within the scope of a RPL Instance in the LLN.  The
         tuple (RPLInstanceID, DODAGID) uniquely identifies a DODAG.

It should say:

DODAGID: A DODAGID is the identifier of a DODAG root.  
  The DODAGID MUST be a reachable IPv6 address of the root node.
  The DODAG MUST be unique within the scope of a RPL Instance 
  in the LLN. The tuple (RPLInstanceID, DODAGID) uniquely 
  identifies a DODAG.

Notes:

section 5.1, and 6.3 also offered definitions of DODAGID, the above text summarizes those sections.

RFC 6551, "Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks", March 2012

Source of RFC: roll (rtg)

Errata ID: 4531
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jeremy Dubrulle
Date Reported: 2015-11-13
Held for Document Update by: Alvaro Retana
Date Held: 2016-02-17

Section 3.2 says:

Figure 3: NE Sub-Object Format

It should say:

Figure 3: NE Object Body Format

Notes:

Figure 3 describes the format of the NE object body while Figure 4 describes the format of the NE Sub-Object.

RFC 6564, "A Uniform Format for IPv6 Extension Headers", April 2012

Source of RFC: 6man (int)

Errata ID: 4807
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Tim Chown
Date Reported: 2016-09-20
Held for Document Update by: Suresh Krishnan
Date Held: 2017-01-29

Section 4 and 9 says:

In Section 4:

Next Header          8-bit selector.  Identifies the type of header
                        immediately following the extension header.
                        Uses the same values as the IPv4 Protocol field
                        [IANA_IP_PARAM].

In Section 9:

[IANA_IP_PARAM] IANA, "IP Parameters",
                   <http://www.iana.org/assignments/ip-parameters>.

It should say:

In Section 4:

Next Header          8-bit selector.  Identifies the type of header
                        immediately following the extension header.
                        Uses the same values as the IPv4 Protocol field
                        [IANA-PN].

In Section 9:

[IANA-PN]  "Assigned Internet Protocol Numbers",
              <https://www.iana.org/assignments/protocol-numbers/
              protocol-numbers.xhtml>.

Notes:

This is being handled in the 2460bis work.

RFC 6580, "IANA Registries for the Remote Direct Data Placement (RDDP) Protocols", April 2012

Source of RFC: storm (tsv)

Errata ID: 3181
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: David L. Black
Date Reported: 2012-04-09
Held for Document Update by: Martin Stiemerling

Section 3.5 says:

   Name of the registry: "SCTP Function Codes for DDP Session Control"

   Namespace details: SCTP (Stream Control Transmission Protocol)
   function codes for DDP session control are 16-bit values [RFC5043].

It should say:

   Name of the registry: "SCTP Function Codes for DDP Stream Session Control"

   Namespace details: SCTP (Stream Control Transmission Protocol)
   function codes for DDP stream session control are 16-bit values [RFC5043].

Notes:

IANA found this minor naming discrepancy with RFC 5043 in performing registry updates. The word "stream" needs to be inserted in two places.

RFC 6594, "Use of the SHA-256 Algorithm with RSA, Digital Signature Algorithm (DSA), and Elliptic Curve DSA (ECDSA) in SSHFP Resource Records", April 2012

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 6174
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: HARUYAMA Seigo
Date Reported: 2020-05-15
Held for Document Update by: Warren Kumari (Ops AD)
Date Held: 2020-05-15

Section Status says:

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   fInternet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

It should say:

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

Notes:

s/fInternet/Internet/

RFC 6603, "Prefix Exclude Option for DHCPv6-based Prefix Delegation", May 2012

Source of RFC: dhc (int)

Errata ID: 3332
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Gaurav Halwasia
Date Reported: 2012-09-01
Held for Document Update by: Brian Haberman

Section 4.2 says:

   Any prefix excluded from the delegated prefix MUST be contained in
   OPTION_PD_EXCLUDE options within the corresponding OPTION_IAPREFIX.

It should say:

   Any prefix excluded from the delegated prefix MUST be contained in
   OPTION_PD_EXCLUDE option within the corresponding OPTION_IAPREFIX.

Notes:

As per this specification OPTION_PD_EXCLUDE option is used to exclude exactly one prefix from a delegated prefix. So as per this specification only one instance of OPTION_PD_EXCLUDE option can be present within OPTION_IAPREFIX.

RFC 6625, "Wildcards in Multicast VPN Auto-Discovery Routes", May 2012

Note: This RFC has been updated by RFC 7582, RFC 7900, RFC 8534

Source of RFC: l3vpn (rtg)

Errata ID: 5605
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Jingrong Xie
Date Reported: 2019-01-16
Held for Document Update by: Alvaro Retana
Date Held: 2022-06-22

Section 3.2.1 says:

      - If there is an installed S-PMSI A-D route originated by PE2,
        whose NLRI contains (C-S,C-G), then (C-S,C-G) matches that
        route.

      - Otherwise, if there is an installed S-PMSI A-D route originated
        by PE2, whose NLRI contains (C-S,C-*), AND if C-G is an SSM
        multicast group address, then (C-S,C-G) matches that route.

      - Otherwise, if there is an installed S-PMSI A-D route originated
        by PE2, whose NLRI contains (C-*,C-G), AND if C-G is an ASM
        multicast group address, then (C-S,C-G) matches that route.

      - Otherwise, if there is an installed S-PMSI A-D route originated
        by PE2, whose NLRI contains (C-*,C-*), then (C-S,C-G) matches
        that route.

It should say:

      - If there is an installed S-PMSI A-D route originated by PE2,
        whose NLRI contains (C-S,C-G), then (C-S,C-G) matches that
        route.

      - If there is an installed S-PMSI A-D route originated
        by PE2, whose NLRI contains (C-S,C-*), AND if C-G is an SSM
        multicast group address, then (C-S,C-G) matches that route too.

      - If there is an installed S-PMSI A-D route originated
        by PE2, whose NLRI contains (C-*,C-G), AND if C-G is an ASM
        multicast group address, then (C-S,C-G) matches that route too.

      - If there is an installed S-PMSI A-D route originated
        by PE2, whose NLRI contains (C-*,C-*), then (C-S,C-G) matches
        that route too.

Notes:

The 'Match for data reception' is an behavior on the MVPN receiver-site PE. If an SPMSI A-D route is matched for data reception, it means that the receiver-site PE will respond to this SPMSI A-D route, either send a responded Leaf A-D route in case there is an explicit-tracking flag (LIR or LIRpF), or join the PMSI tunnel in the SPMSI A-D route in case the tunnel type is mLDP/PIM etc. This usage of 'match for data reception' is not explicitly explained in this RFC but it is used in <draft-ietf-bess-mvpn-expl-track-13>.
There is clear inclusive-selective relationship between S-PMSI A-D (*,*) and S-PMSI A-D(S,G).
Thinking the S-PMSI A-D (*,*) as an Inclusive one, the receiver site PE with a (C-S,C-G) state should keep its join state on both the S-PMSI A-D (*,*) and S-PMSI A-D(S,G), and setup the 'reception state' on both the (*,*) PMSI-tunnel and (S,G) PMSI-tunnel. So the 'match for reception' should be one or more SPMSI A-D routes. The 'if/othersize/othersize' sentences make the wrong meaning.


=== AD Note ====
This section of rfc6625 has been Updated by rfc7582, rfc7900, and rfc8534 for various scenarios. Any general change to the overall procedure must take those updates into consideration. I am then marking this report as "Held for Document Update" so these modifications can be taken into account.

RFC 6639, "Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-Based Management Overview", June 2012

Source of RFC: mpls (rtg)

Errata ID: 3450
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: tom petch
Date Reported: 2013-01-10
Held for Document Update by: Adrian Farrel

Section 4.2.9 says:

   The mplsOutSegmentPerfTable [RFC3813] contains statistical
   information (total packets received, total errored packets received,
   total packets discarded, discontinuity time) for outgoing MPLS
   segments from an LSR.

It should say:

   The mplsOutSegmentPerfTable [RFC3813] contains statistical
   information (total packets sent, 
   total packets that could not be sent due to errors, 
   total packets discarded, discontinuity time) for outgoing MPLS
   segments from an LSR.

Notes:

mplsOutSegmentPerfTable is for segments sent, current text relates to segments received.

Errata ID: 3923
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Liu Lin
Date Reported: 2014-03-20
Held for Document Update by: Adrian Farrel
Date Held: 2014-03-20

Section 4.2.6 says:

This MIB architecture is modeled based on PW3 architecture [RFC3985]

It should say:

This MIB architecture is modeled based on PWE3 architecture [RFC3985]

Notes:

PW3 -> PWE3

RFC 6655, "AES-CCM Cipher Suites for Transport Layer Security (TLS)", July 2012

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 3760
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sandeep S. Kumar
Date Reported: 2013-10-22
Held for Document Update by: Sean Turner
Date Held: 2014-01-14

Section 3 says:

....is 8 octets.  Each value of the
   nonce_explicit MUST be distinct for each distinct invocation of the
   GCM encrypt function for any fixed key.  Failure to meet...

It should say:

....is 8 octets.  Each value of the
   nonce_explicit MUST be distinct for each distinct invocation of the
   CCM encrypt function for any fixed key.  Failure to meet...

Notes:

GCM should be corrected to CCM. The draft discusses the AES-CCM mode of operation.

spt: Don't think implementers will be confused by this so HFDU.

RFC 6656, "Description of Cisco Systems' Subnet Allocation Option for DHCPv4", July 2012

Source of RFC: dhc (int)

Errata ID: 3617
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Dushyant Raghuvanshi
Date Reported: 2013-05-08
Held for Document Update by: Ted Lemon

Section 3.2 says:

Len = Length of the suboption (min. length of 8) (1 octet)

It should say:

Len = Length of the suboption (min. length of 1) (1 octet)

Notes:

RFC 6656 suggests that a DHCP Client MAY request list of previously allocated subnets from the DHCP Server in case of recovering from a restart if the Client does not have local storage in order to retain the information itself. But there will be cases when Server does not have any information to send back (this could be a new Client or this Client never spoke to this Server before). In this case, DHCP Server may decide to remain silent and discard the request. This approach will make it difficult for DHCP Client to decide if request could not reach to Server or Server did not have any information to send back. A possible approach could be to send the OFFER back to Client with Subnet-Information Suboption (without Subnet Prefix Information Block) in it. So that Client can proceed by making a request to allocate new subnets. This would require to reduce the minimum length of Subnet-Information Suboption to 1 (just include flags). Section 6 would require to be updated as well to reflect the new behavior (to respond).

RFC 6686, "Resolution of the Sender Policy Framework (SPF) and Sender ID Experiments", July 2012

Source of RFC: spfbis (app)

Errata ID: 4049
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nico Roeser
Date Reported: 2014-07-11
Held for Document Update by: Barry Leiba
Date Held: 2014-07-11

Section 2 says:

   Resource Record (RR) type.  These are always expressed internally in
   software as numbers, assigned according to the procedures in
   [DNS-IANA] Assigned RRTYPEs also have names.  The two of interest in

It should say:

   Resource Record (RR) type.  These are always expressed internally in
   software as numbers, assigned according to the procedures in
   [DNS-IANA].  Assigned RRTYPEs also have names.  The two of interest
   in

Notes:

Wrong punctuation: missing period and space.

----- Verifier Notes -----
We don't use errata reports for insignificant typos.

RFC 6690, "Constrained RESTful Environments (CoRE) Link Format", August 2012

Source of RFC: core (wit)

Errata ID: 3751
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Peter A. Bigot
Date Reported: 2013-10-15
Held for Document Update by: Barry Leiba
Date Held: 2013-10-15

Section 2 says:

   URI-Reference  = <defined in [RFC3986]>
 

It should say:

   URI-reference  = <defined in [RFC3986]>
 

Notes:

Although RFC5234 does specify that rule names are case-insensitive, URI-reference is "misspelled" URI-Reference throughout ABNF rules in section 2. It is correct in the remainder of the text.

----- Verifier notes -----
An unimportant typo that will not cause confusion for anyone.
We can change it if/when the document is updated.

RFC 6704, "Forcerenew Nonce Authentication", August 2012

Source of RFC: dhc (int)

Errata ID: 3353
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Gaurav Halwasia
Date Reported: 2012-09-14
Held for Document Update by: Brian Haberman

Section 5.1 says:

   The mechanism described in this document is vulnerable to a denial-
   of-service (DoS) attack through flooding a client with bogus
   FORCERENEW messages.  The calculations involved in authenticating the
   bogus FORECERENEW messages may overwhelm the device on which the
   client is running.

It should say:

   The mechanism described in this document is vulnerable to a denial-
   of-service (DoS) attack through flooding a client with bogus
   FORCERENEW messages.  The calculations involved in authenticating the
   bogus FORCERENEW messages may overwhelm the device on which the
   client is running.

Notes:

Spelling of "FORECERENEW" is incorrect. It should be "FORCERENEW"

RFC 6710, "Simple Mail Transfer Protocol Extension for Message Transfer Priorities", August 2012

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 3336
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: D. Stussy
Date Reported: 2012-09-06
Held for Document Update by: Barry Leiba
Date Held: 2012-09-06

Section 7 says:

   ; New "clause" that can be used in the Received header field
   Pri  = CFWS "PRIORITY" FWS priority-value
             ; Complies with the <Additional-Registered-Clauses>
             ; non-terminal syntax from RFC 5321.

It should say:

   ; New "clause" that can be used in the Received header field
   Pri  = CFWS "priority" FWS priority-value
             ; Complies with the <Additional-Registered-Clauses>
             ; non-terminal syntax from RFC 5321.

Notes:

All the subclauses of the "Received:" header in RFC 5321 are lowercase ("from", "by", "via", "with", "id", and "for" - in that order). I suggest that "PRIORITY" also be lower cased ("priority") for consistency.

Additional note: As this is the first additional clause, it obviously trails the others defined in RFC 5321 per the ABNF syntax found there. However, all future additional clauses should indicate their placement relative to additional clauses added to the list before them (i.e. RFC 5321 does not specify an order for the additional clauses, but each individual future RFC that proposes them should).

---------------------
Reviewer note:
Minor editorial issues that won't cause confusion go into "Hold for Document Update." So let it be written; so let it be done.

RFC 6716, "Definition of the Opus Audio Codec", September 2012

Note: This RFC has been updated by RFC 8251

Source of RFC: codec (rai)

Errata ID: 4392
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Budny
Date Reported: 2015-06-15
Held for Document Update by: Ben Campbell
Date Held: 2015-06-15

Section 2 says:

The Opus codec scales from 6 kbit/s narrowband mono speech to
510 kbit/s fullband stereo music, with algorithmic delays ranging
from 5 ms to 65.2 ms.

(further in the same section)

To
compensate for the different look-ahead required by each layer, the
CELT encoder input is delayed by an additional 2.7 ms.

It should say:

The Opus codec scales from 6 kbit/s narrowband mono speech to
510 kbit/s fullband stereo music, with algorithmic delays ranging
from 5 ms to 66.5 ms.

(further in the same section)

To
compensate for the different look-ahead required by each layer, the
CELT encoder input is delayed by an additional 4 ms.

Notes:

For the latter text, the delays for the CELT and SILK layers must match. SILK has a "5 ms look-ahead for noise shaping estimation", and "1.5 ms delay for sampling rate conversion", totaling 6.5 ms. CELT has a "2.5 ms look-ahead due to the overlapping MDCT windows". Thus, the amount of delay needed to align CELT with SILK is 6.5ms - 2.5ms = 4ms.

The text at the beginning of the section must reflect this as well. The "algorithmic delays" reported apparently include framing (minimum frame size 2.5ms + look-ahead delay in CELT-only mode 2.5ms = 5ms). In that case, the maximum delay is the maximum frame size (60ms) + the maximum delay for look-ahead and resampling (6.5ms) = 66.5ms.

Confirmed by author ("Jmvalin") at https://en.wikipedia.org/wiki/Talk:Opus_(audio_format)/Archive_1#Codec_delay_values

Errata ID: 4829
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: flacs
Date Reported: 2016-10-12
Held for Document Update by: Ben Campbell
Date Held: 2016-11-02

Throughout the document, when it says:

Coeffieients

It should say:

Coefficients

Notes:

Just a small typo in the Table of Contents.

RFC 6719, "The Minimum Rank with Hysteresis Objective Function", September 2012

Source of RFC: roll (rtg)

Errata ID: 4878
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Cenk Gündogan
Date Reported: 2016-12-06
Held for Document Update by: Alvaro Retana
Date Held: 2017-01-25

Section Abstract says:

MRHOF works with additive metrics along a route, and
the metrics it uses are determined by the metrics that the RPL
Destination Information Object (DIO) messages advertise.

It should say:

MRHOF works with additive metrics along a route, and
the metrics it uses are determined by the metrics that the RPL
DODAG Information Object (DIO) messages advertise.

Notes:

DIO stands for DODAG Information Object

Errata ID: 4879
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Cenk Gündogan
Date Reported: 2016-12-06
Held for Document Update by: Alvaro Retana
Date Held: 2017-01-25

Section 1 says:

RPL advertises metrics in RPL Destination Information
Object (DIO) messages with a Metric Container suboption.

It should say:

RPL advertises metrics in RPL DODAG Information
Object (DIO) messages with a Metric Container suboption.

Notes:

DIO stands for DODAG Information Object

Errata ID: 5283
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dario Tedeschi
Date Reported: 2018-03-07
Held for Document Update by: Alvaro Retana
Date Held: 2018-03-14

Section 3.3 says:

whose paths have a large range of Ranks will likely result in
subptimal routing: nodes might not choose good paths because they are

It should say:

whose paths have a large range of Ranks will likely result in
suboptimal routing: nodes might not choose good paths because they are

Notes:

Incorrect spelling of suboptimal.

RFC 6733, "Diameter Base Protocol", October 2012

Note: This RFC has been updated by RFC 7075, RFC 8553

Source of RFC: dime (ops)

Errata ID: 5084
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Priyatosh Mandal
Date Reported: 2017-08-11
Held for Document Update by: Benoit Claise
Date Held: 2017-09-17

Section 8.16 says:

By including Origin-State-Id in a message, it allows other Diameter
entities to infer that sessions associated with a lower Origin-State-Id 
are no longer active.
If an access device does not intend for such inferences to be made, it 
MUST either not include Origin-State-Id in any message or set its value 
to 0.

It should say:

By including Origin-State-Id in a message, it allows other Diameter
entities to infer that sessions associated with a lower Origin-State-Id 
are no longer active.
If an access device does not intend for such inferences to be made, it 
MUST either not include Origin-State-Id in any message or set its value 
to 0. 
As a special case when the value of Origin-State-Id changes from 
4294967295 to 0, then also the access device  clear all the sessions.

Notes:

Origin-State-Id is defined as Unsigned32 in RFC 6733, Section 8.16. So the maximum
value it can have is 4294967295. If the system restarts many times and the value of
Origin-State-Id reaches the value which is same as its maximum value 4294967295.
Then what will happen for the next restart. At the next restart the value of Origin-State-Id
will be 0 if we try to increase the value of Origin-State-Id.
It is not defined in the RFC 6733, that how the system should behave after 4294967295-th
restart with respect to Origin-State-Id.

Generally when the peer receives an increased value of Origin-State-Id, then it clear all sessions.
If the value of Origin-State-Id reaches its maximum i.e., 4294967295, then after another restart
its value will be 0. For a special case for transition of value of Origin-State-Id from
4294967295 to 0, the peer should clear its session.

Errata ID: 4210
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hans Liu
Date Reported: 2014-12-25
Held for Document Update by: Benoit Claise
Date Held: 2015-01-07

Section 5.4.3 says:

   The Disconnect-Cause AVP (AVP Code 273) is of type Enumerated.  A
   Diameter node MUST include this AVP in the Disconnect-Peer-Request
   message to inform the peer of the reason for its intention to shut
   down the transport connection.  The following values are supported:
      REBOOTING                         0
         A scheduled reboot is imminent.  A receiver of a DPR with
         above result code MAY attempt reconnection.
      BUSY                              1
         The peer’s internal resources are constrained, and it has
         determined that the transport connection needs to be closed.
         A receiver of a DPR with above result code SHOULD NOT attempt
         reconnection.
      DO_NOT_WANT_TO_TALK_TO_YOU        2
         The peer has determined that it does not see a need for the
         transport connection to exist, since it does not expect any
         messages to be exchanged in the near future.  A receiver of a
         DPR with above result code SHOULD NOT attempt reconnection.

It should say:

   The Disconnect-Cause AVP (AVP Code 273) is of type Enumerated.  A
   Diameter node MUST include this AVP in the Disconnect-Peer-Request
   message to inform the peer of the reason for its intention to shut
   down the transport connection.  The following values are supported:
      REBOOTING                         0
         A scheduled reboot is imminent.  A receiver of a DPR with
         above result code MAY attempt reconnection.
      BUSY                              1
         The internal resources are constrained, and it has
         determined that the transport connection needs to be closed.
         A receiver of a DPR with above result code SHOULD NOT attempt
         reconnection.
      DO_NOT_WANT_TO_TALK_TO_YOU        2
         The node has determined that it does not see a need for the
         transport connection to exist, since it does not expect any
         messages to be exchanged in the near future.  A receiver of a
         DPR with above result code SHOULD NOT attempt reconnection.

Notes:

A peer can either be a sender or receiver, depending on the contexst.

However in same section describing usage for the same AVP (description for cause), the 1st appearance represents the role of receiver, the 2nd and 3rd appearances has changed to the role of senders, it's confusing literally.

Errata ID: 4234
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lionel Morand
Date Reported: 2015-01-16
Held for Document Update by: Kathleen Moriarty
Date Held: 2015-01-16

Section 5.4 says:

In the last sentence of first paragraph odf the section 5.4, it is said:

   When a Diameter node disconnects one of its transport connections,
   its peer cannot know the reason for the disconnect and will most
   likely assume that a connectivity problem occurred or that the peer
   has rebooted.  In these cases, the peer may periodically attempt to
   reconnect, as stated in Section 2.1.  In the event that the
   disconnect was a result of either a shortage of internal resources or
   simply that the node in question has no intentions of forwarding any
   Diameter messages to the peer in the foreseeable future, a periodic
   connection request would not be welcomed.  The Disconnection-Reason
   AVP contains the reason the Diameter node issued the Disconnect-Peer-
   Request message.

It should say:

the sentence should be:


   When a Diameter node disconnects one of its transport connections,
   its peer cannot know the reason for the disconnect and will most
   likely assume that a connectivity problem occurred or that the peer
   has rebooted.  In these cases, the peer may periodically attempt to
   reconnect, as stated in Section 2.1.  In the event that the
   disconnect was a result of either a shortage of internal resources or
   simply that the node in question has no intentions of forwarding any
   Diameter messages to the peer in the foreseeable future, a periodic
   connection request would not be welcomed.  The Disconnect-Cause AVP
   contains the reason the Diameter node issued the Disconnect-Peer-
   Request message.

Notes:

The correct name of the AVP is "Disconnect-Cause AVP" and not "Disconnection-Reason AVP" that does not exist.

RFC 6749, "The OAuth 2.0 Authorization Framework", October 2012

Note: This RFC has been updated by RFC 8252, RFC 8996

Source of RFC: oauth (sec)

Errata ID: 3780
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Torsten Lodderstedt
Date Reported: 2013-11-04
Held for Document Update by: Kathleen Moriarty
Date Held: 2015-12-08

Section 3.2.1 says:

A client MAY use the "client_id" request parameter to identify itself
   when sending requests to the token endpoint.

It should say:

A public client MAY use the "client_id" request parameter to identify 
itself when sending requests to the token endpoint.

Notes:

Note from AD: The provided link doesn't exactly demonstrate consensus, but the change makes sense, hence this is marked "Held for Document Update".

From Submitter: The current text may mislead confidential clients to sent their client_id in the request body in addition to their client_id and client_secret in the BASIC authz header. This leads to unnecessary duplication and ambiguities.

There has been consensus on the list that the intention of this sentence was to advise _public_ clients to identity themselves towards the token endpoint in order to mitigate substitution attacks and allow for logging. Confidential clients need to authenticate anyway, this sentence should be narrowed down to public clients only.

see http://www.ietf.org/mail-archive/web/oauth/current/msg12005.html

This issue was discovered in the course of the OpenID Connect Interop testings.

Errata ID: 4206
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alexander Kempgen
Date Reported: 2014-12-23
Held for Document Update by: Kathleen Moriarty
Date Held: 2015-12-08

Section 4.1 says:

   (E)  The authorization server authenticates the client, validates the
        authorization code, and ensures that the redirection URI
        received matches the URI used to redirect the client in
        step (C).  If valid, the authorization server responds back with
        an access token and, optionally, a refresh token.

It should say:

   (E)  The authorization server authenticates the client, validates the
        authorization code, and ensures that the redirection URI
        received matches the redirection URI provided by the client in
        step (A).  If valid, the authorization server responds back with
        an access token and, optionally, a refresh token.

Notes:

AD & WG notes: The wording is better, so this is accepted, but it does mean the same thing. The URI in A and C are the same.

See https://www.ietf.org/mail-archive/web/oauth/current/msg15277.html and responses.

Submitter notes: As written in section 4.1.3, the redirection URI in the access token request must match the redirection URI provided by the client in the authorization request (4.1.1). The URI used to redirect the user agent to the client in step (C) is actually different from this URI, as it contains the additional query parameters "code" and "state".

Affects the same sentence as Errata ID: 3500.

RFC 6751, "Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises Equipment (6a44)", October 2012

Source of RFC: INDEPENDENT

Errata ID: 3390
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Andreas Cudok
Date Reported: 2012-10-19
Held for Document Update by: Nevil Brownlee
Date Held: 2014-01-20

Section 6.6.2 says:

RR4-2 IPv6 PACKET FROM A 6a44 CLIENT TO ANOTHER 6a44 CLIENT

  (IPv4, N1, B, UDP(Z1, W, [IPv6, <C.N1.Z1...>, <C.N2.Z2...>, ...]))
  <figure omitted>

If ALL the following conditions are satisfied, the 6a44 relay MUST
return back via its downstream IPv4 interface an IPv6/ UDP/IPv4
packet containing the same encapsulated packet, having its UDP/IPv4
destination set to the UDP/IPv4 address found in the 6a44 destination
address, and having its UDP/IPv4 source set to the 6a44-relay
UDP/IPv4 address: (1) the IPv4 packet contains a complete UDP
datagram (protocol = 17, offset = 0, more-fragment bit = 0); (2) the
UDP payload is an IPv6 packet (length of at least 40 octets, version
= 6); (3) the IPv6 source address starts with the 6a44-network IPv6
prefix followed by the UDP/IPv4 source address of the received
packet; (4) the IPv6 destination address starts with the 6a44-network
IPv6 prefix.

It should say:

RR4-2 IPv6 PACKET FROM A 6a44 CLIENT TO ANOTHER 6a44 CLIENT

  (IPv4, N1, B, UDP(Z1, W, [IPv6, <C.N1.Z1...>, <C.N2 != B .Z2...>,
   ...]))
  <figure omitted>

If ALL the following conditions are satisfied, the 6a44 relay MUST
return back via its downstream IPv4 interface an IPv6/UDP/IPv4
packet containing the same encapsulated packet, having its UDP/IPv4
destination set to the UDP/IPv4 address found in the 6a44 destination
address, and having its UDP/IPv4 source set to the 6a44-relay
UDP/IPv4 address: (1) the IPv4 packet contains a complete UDP
datagram (protocol = 17, offset = 0, more-fragment bit = 0); (2) the
UDP payload is an IPv6 packet (length of at least 40 octets, version
= 6); (3) the IPv6 source address starts with the 6a44-network IPv6
prefix followed by the UDP/IPv4 source address of the received
packet; (4) the IPv6 destination address starts with the 6a44-network
IPv6 prefix and the embedded IPv4 address (bits 48-79) MUST be
different from the 6a44-relay anycast address.

Notes:

Requesting N2 != B prevents unwanted packets sent from the 6a44 relay to itself and makes the system more robust against DOS attacks.

This is really an enhancement, not an error, so it's Held (rather than Verified)

RFC 6761, "Special-Use Domain Names", February 2013

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 5039
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Walter H.
Date Reported: 2017-06-12
Held for Document Update by: Warren Kumari
Date Held: 2017-06-12

Section 6.1 says:

   The private-address [RFC1918] reverse-mapping domains listed below,
   and any names falling within those domains, are Special-Use Domain
   Names:

     10.in-addr.arpa.      21.172.in-addr.arpa.  26.172.in-addr.arpa.
     16.172.in-addr.arpa.  22.172.in-addr.arpa.  27.172.in-addr.arpa.
     17.172.in-addr.arpa.  30.172.in-addr.arpa.  28.172.in-addr.arpa.
     18.172.in-addr.arpa.  23.172.in-addr.arpa.  29.172.in-addr.arpa.
     19.172.in-addr.arpa.  24.172.in-addr.arpa.  31.172.in-addr.arpa.
     20.172.in-addr.arpa.  25.172.in-addr.arpa.  168.192.in-addr.arpa.

It should say:

   The private-address [RFC1918] reverse-mapping domains listed below,
   and any names falling within those domains, are Special-Use Domain
   Names:

     10.in-addr.arpa.      21.172.in-addr.arpa.  27.172.in-addr.arpa.
     16.172.in-addr.arpa.  22.172.in-addr.arpa.  28.172.in-addr.arpa.
     17.172.in-addr.arpa.  23.172.in-addr.arpa.  29.172.in-addr.arpa.
     18.172.in-addr.arpa.  24.172.in-addr.arpa.  30.172.in-addr.arpa.
     19.172.in-addr.arpa.  25.172.in-addr.arpa.  31.172.in-addr.arpa.
     20.172.in-addr.arpa.  26.172.in-addr.arpa.  168.192.in-addr.arpa.

Notes:

the original list is not correctly ordered, therefore is Errata-ID 5025 obsolete: this said that 30.172.in-addr.arpa. were missing in the original list.

RFC 6762, "Multicast DNS", February 2013

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: int

Errata ID: 4977
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Nathan Osman
Date Reported: 2017-03-23
Held for Document Update by: Éric Vyncke
Date Held: 2024-01-12

Section 6.1 says:

The 'Next Domain Name' field contains the record's own name. When
used with name compression, this means that the 'Next Domain Name'
field always takes exactly two bytes in the message.

It should say:

The 'Next Domain Name' field contains the record's own name.

Notes:

Section 4.1.1 of RFC 4034 states:

"A sender MUST NOT use DNS name compression on the Next Domain Name
field when transmitting an NSEC RR."

--- Verifier note ---
While errata submitter's concern is valid, this is not a stricto sensu "errata" as the existing RFC reflects the WG consensus at the publication time.


In order to comply with the existing RFC, name compression should not
be suggested.

RFC 6763, "DNS-Based Service Discovery", February 2013

Note: This RFC has been updated by RFC 8553

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 6312
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Makarand Damle
Date Reported: 2020-10-20
Held for Document Update by: Eric Vyncke
Date Held: 2020-10-20

Section 7.1 says:

On the other hand, there are cases where users wish to manage printers specifically, not to discover web pages in general, and it is good accommodate this.

It should say:

On the other hand, there are cases where users wish to manage printers specifically, not to discover web pages in general, and it is good to accommodate this.

Notes:

Per "IESG Processing of RFC Errata for the IETF Stream", trivial grammar error should be tagged as "held for document update".
Thank you for reporting.

RFC 6773, "DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal", November 2012

Source of RFC: dccp (tsv)

Errata ID: 4655
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Timothy Pederick
Date Reported: 2016-04-05
Held for Document Update by: Magnus Westerlund
Date Held: 2019-12-19

Section 1 says:

Network optimisations for DCCP-STP and UDP may need to be updated to 
allow these optimisations to take advantage of DCCP-UDP.

It should say:

Network optimisations for DCCP-STD and UDP may need to be updated to 
allow these optimisations to take advantage of DCCP-UDP.

Notes:

"DCCP-STP" is nowhere defined, and so is presumably a typo for "DCCP-STD".

RFC 6781, "DNSSEC Operational Practices, Version 2", December 2012

Source of RFC: dnsop (ops)

Errata ID: 5276
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Matthijs Mekking
Date Reported: 2018-03-06
Held for Document Update by: Warren Kumari (Ops AD)
Date Held: 2018-10-02

Section 4.1.4 says:

   ----------------------------------------------------------------
    new DS               DNSKEY removal       RRSIGs removal
   ----------------------------------------------------------------
   Parent:
    SOA_1 ------------------------------------------------------->
    RRSIG_par(SOA) ---------------------------------------------->
    DS_K_2 ------------------------------------------------------>
    RRSIG_par(DS_K_2) ------------------------------------------->

   Child:
    -------------------> SOA_3                SOA_4
    -------------------> RRSIG_Z_10(SOA)
    -------------------> RRSIG_Z_11(SOA)      RRSIG_Z_11(SOA)

    ------------------->
    -------------------> DNSKEY_K_2           DNSKEY_K_2
    ------------------->
    -------------------> DNSKEY_Z_11          DNSKEY_Z_11
    ------------------->
    -------------------> RRSIG_K_2(DNSKEY)    RRSIG_K_2(DNSKEY)
   ----------------------------------------------------------------

        Figure 8: Stages of Deployment during an Algorithm Rollover

It should say:

   ----------------------------------------------------------------
    new DS               DNSKEY removal       RRSIGs removal
   ----------------------------------------------------------------
   Parent:
    SOA_1 ------------------------------------------------------->
    RRSIG_par(SOA) ---------------------------------------------->
    DS_K_2 ------------------------------------------------------>
    RRSIG_par(DS_K_2) ------------------------------------------->

   Child:
    -------------------> SOA_3                SOA_4
    -------------------> RRSIG_Z_10(SOA)
    -------------------> RRSIG_Z_11(SOA)      RRSIG_Z_11(SOA)

    ------------------->
    -------------------> DNSKEY_K_2           DNSKEY_K_2
    ------------------->
    -------------------> DNSKEY_Z_11          DNSKEY_Z_11
    -------------------> RRSIG_K_1(DNSKEY)
    -------------------> RRSIG_K_2(DNSKEY)    RRSIG_K_2(DNSKEY)
   ----------------------------------------------------------------

        Figure 8: Stages of Deployment during an Algorithm Rollover

Notes:

This is about Figure 8 on page 30.

The figure should have the signature of the old KSK, called RRSIG_K_1(DNSKEY) in the "DNSKEY removal" step.

Because a conservative validator may have the DNSKEY RRset cached that includes DNSKEY_K_1, DNSKEY_K_2, DNSKEY_Z_1, and DNSKEY_Z_2.

RFC 6787, "Media Resource Control Protocol Version 2 (MRCPv2)", November 2012

Source of RFC: speechsc (rai)

Errata ID: 3657
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Joël Repiquet
Date Reported: 2013-06-17
Held for Document Update by: Richard Barnes

Section 13.7 says:

   IANA has registered the following SDP parameter values.  The
   information for each follows the template given in RFC 4566
   [RFC4566], Appendix B.

It should say:

   IANA has registered the following SDP parameter values.  The
   information for each follows the template given in RFC 4566
   [RFC4566], Section 8.2.

RFC 6790, "The Use of Entropy Labels in MPLS Forwarding", November 2012

Note: This RFC has been updated by RFC 7274, RFC 7447, RFC 8012

Source of RFC: mpls (rtg)

Errata ID: 3431
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Jeff Wheeler
Date Reported: 2012-12-16
Held for Document Update by: Adrian Farrel

Section 5.2 says:

This is an optional, transitive BGP attribute of value 28.

It should say:

This is an optional, transitive BGP Attribute having Attribute Type Code 28, length 0, and no data.

Notes:

"Value" is (slightly) confusing in this context. The text should also explicitly specify that there isn't Attribute Data and thus the length will be 0.

Ambiguity on this matter may lead implementations to utilize the data field in some unforeseen way. Other implementations may then reject the attribute, applying general attribute processing rules, with an Attribute Length Error (RFC 4271 S6.3 paragraph 4.)

RFC 6793, "BGP Support for Four-Octet Autonomous System (AS) Number Space", December 2012

Source of RFC: idr (rtg)

Errata ID: 4538
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Warren Kumari
Date Reported: 2015-11-19
Held for Document Update by: Alvaro Retana
Date Held: 2015-11-23

Section 8 says:

If the BGP4-MIB [RFC4273] is supported, there are no additional
manageability concerns that arise from the use of four-octet AS
numbers, since the InetAutonomousSystemNumber textual convention
[RFC4001] is defined as Unsigned32.

It should say:

If the BGP4-MIBv2 [draft-ietf-idr-bgp4-mibv2] is supported, there are 
no additional manageability concerns that arise from the use of 
four-octet AS numbers, since the InetAutonomousSystemNumber 
textual convention [RFC4001] is defined as Unsigned32.

Notes:

I do not have corrected text. RFC4273 does not use InetAutonomousSystemNumber for AS numbers:
bgpPeerRemoteAs OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The remote autonomous system number received in
the BGP OPEN message."
REFERENCE
"RFC 4271, Section 4.2."
::= { bgpPeerEntry 9 }

This uses "Integer32 (0...65535)" (note, Integer, not Unsigned Int).
It is unclear to me how to fix this, I know some folk are simply treating it as a UInt32.

=====
The report is correct, rfc4273 can't support 4-byte ASNs.

After consulting with the authors and the WG, it seems like the correct reference should have been
draft-ietf-idr-bgp4-mibv2 (BGP4 MIBv2). Besides the corrected text above, an Informative Reference should be added to draft-ietf-idr-bgp4-mibv2.

RFC 6819, "OAuth 2.0 Threat Model and Security Considerations", January 2013

Source of RFC: oauth (sec)

Errata ID: 4267
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: David Gladstone
Date Reported: 2015-02-09
Held for Document Update by: Kathleen Moriarty
Date Held: 2015-12-08

Section 4.4.1.11 says:

If an authorization server includes a nontrivial amount of entropy

It should say:

If an authorization server includes a trivial amount of entropy

Notes:

The threat being described outlines a scenario where too little entropy is involved; countermeasures include using non-trivial amounts of entropy.

RFC 6822, "IS-IS Multi-Instance", December 2012

Note: This RFC has been obsoleted by RFC 8202

Source of RFC: isis (rtg)

Errata ID: 4521
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexander Okonnikov
Date Reported: 2015-11-02
Held for Document Update by: Alia Atlas
Date Held: 2015-11-11

Section 2.6.2 says:

   In order for an MI-RTR to interoperate over a point-to-point 
   circuit with a router that does NOT support this extension, the 
   MI-RTR MUST NOT send IS-IS PDUs for instances other than IID #0 
   over the point-to-point circuit as these PDUs may affect the state 
   of IID #0 in the neighbor.

It should say:

   Note: The procedure below should not be used when MI-RTR is 
   operating in point-to-point mode over broadcast circuit 
   [RFC 5309].

   In order for an MI-RTR to interoperate over a point-to-point 
   circuit with a router that does NOT support this extension, the 
   MI-RTR MUST NOT send IS-IS PDUs for instances other than IID #0 
   over the point-to-point circuit as these PDUs may affect the state 
   of IID #0 in the neighbor.

Notes:

In Section 2.6.1, it clearly says "If operating in point-to-point mode on a broadcast circuit [RFC5309]" which reinforces that Section 2.6.2 is about point-to-point circuits and not broadcast circuits.

However, there isn't any harm in adding a bit of clarity going forward. This can be looked at if and when RFC 6822 is updated.

RFC 6844, "DNS Certification Authority Authorization (CAA) Resource Record", January 2013

Note: This RFC has been obsoleted by RFC 8659

Source of RFC: pkix (sec)

Errata ID: 4062
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Evan Hunt
Date Reported: 2014-07-24
Held for Document Update by: Kathleen Moriarty
Date Held: 2014-09-03

Section 5.1.1 says:

Value:  Is the <character-string> encoding of the value field as
specified in [RFC1035], Section 5.1.

It should say:

Value:  The value field, expressed as a contiguous set of characters
without interior spaces, or as a quoted string.  See the the
<character-string> format specified in [RFC1035], Section 5.1,
but note that the value field contains no length byte and is not
limited to 255 characters.

Notes:

<character-string> is defined in RFC 1035 as being limited to 255 characters
preceded by a length byte. Saying the field is encoded as a <character-string>
creates ambiguity as to whether the value field is intended to be size-limited.

RFC author agreed that it was okay to make this more explicit with the proposed text.

Errata ID: 5065
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Phillip Hallam-Baker
Date Reported: 2017-07-10
Held for Document Update by: EKR
Date Held: 2017-08-22

Section 4 says:

   Let CAA(X) be the record set returned in response to performing a CAA
   record query on the label X, P(X) be the DNS label immediately above
   X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME
   alias record specified at the label X.

   o  If CAA(X) is not empty, R(X) = CAA (X), otherwise

   o  If A(X) is not null, and R(A(X)) is not empty, then R(X) =
      R(A(X)), otherwise

   o  If X is not a top-level domain, then R(X) = R(P(X)), otherwise

   o  R(X) is empty.

It should say:

   Let CAA(X) be the record set returned in response to performing a CAA
   record query on the label X, P(X) be the DNS label immediately above
   X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME
   alias record chain specified at the label X.
 
   o  If CAA(X) is not empty, R(X) = CAA (X), otherwise
 
   o  If A(X) is not null, and CAA(A(X)) is not empty, then R(X) =
      CAA(A(X)), otherwise
 
   o  If X is not a top-level domain, then R(X) = R(P(X)), otherwise
 
   o  R(X) is empty.
 
  Thus, when a search at node X returns a CNAME record, the CA will
  follow the CNAME record chain to its target. If the target label 
  contains a CAA record, it is returned.

  ?O?therwise, the CA continues the search at
  the parent of node X.
 
  Note that the search does not include the parent of a target of a
  CNAME record (except when the CNAME points back to its own path).
 
  To prevent resource exhaustion attacks, CAs SHOULD limit the length of
  CNAME chains that are accepted. However CAs MUST process CNAME
  chains that contain 8 or fewer CNAME records.

Notes:

This is the updated errata to replace the ones previously deleted. It has been reviewed by all the parties concerned. Since this is a breaking change, this will have to go to hold for document update. The LAMPS working group is currently considering a more radical re-working of the CAA discovery scheme as a work item for its new charter.

I will be in Prague to discuss...

Errata ID: 5097
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Andrew Ayer
Date Reported: 2017-08-25
Held for Document Update by: EKR
Date Held: 2018-11-30

Section 4 says:

Let CAA(X) be the record set returned in response to performing a CAA
record query on the label X, P(X) be the DNS label immediately above
X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME
alias record specified at the label X.

It should say:

Let CAA(X) be the record set returned in response to performing a CAA
record query on the label X, P(X) be the DNS label immediately above
X in the DNS hierarchy, and A(X) be the target of a CNAME
alias record specified at the label X.

Notes:

As currently worded, section 4 tells the CA to look up a DNAME record specified *at* the label X, and if one is found, look up a CAA record at the DNAME's target. This is contrary to the behavior of DNAME as specified in RFC 6672, which is to redirect names subordinate of the DNAME but not the DNAME itself.

Since DNAMEs cause CNAMEs to be synthesized for subordinate names, there is no need for implementers of CAA to care about the presence of DNAMEs at all, so this erratum simply removes any mention of DNAME.

Errata ID: 5200
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Richard Gibson
Date Reported: 2017-12-08
Held for Document Update by: EKR
Date Held: 2018-11-30

Section 3 says:

<Issuer Domain Name> [; <name>=<value> ]*

It should say:

<Issuer Domain Name> [; [ <name>=<value> ]* ]

Notes:

For values of the "issue" and "issuewild" property tags, section 3 specifies [; <name>=<value> ]* (which seems to indicate that every parameter is preceded by a semicolon) but the grammar in section 5.2 specifies [";" *(space parameter) space] (in which parameters are separated by whitespace and the entire list is preceded by a single semicolon). Presumably, the formal grammar is definitive and the preceding shorthand should be updated to better express it.

Errata ID: 5244
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Corey Bonnell
Date Reported: 2018-01-26
Held for Document Update by: EKR
Date Held: 2018-11-30

Section 5.2 says:

CAA authorizations are additive; thus, the result of specifying both
the empty issuer and a specified issuer is the same as specifying
just the specified issuer alone.

It should say:

CAA authorizations are additive; thus, the result of specifying both
the empty issuer and a specified issuer is the same as specifying
just the specified issuer alone.  A non-empty CAA record set that does
not contain an issue property tag is authorization to any certificate
issuer to issue for the corresponding domain, provided that no
records in the CAA record set otherwise prohibit issuance.

Notes:

The current wording in the RFC does not clearly state how non-empty CAA record sets which do not contain any "issue" property tags should be handled in terms of whether or not such record sets authorize issuance. The additional wording clarifies the correct handling of this case.

Errata ID: 5452
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Rich Salz
Date Reported: 2018-08-06
Held for Document Update by: EKR
Date Held: 2018-11-30

Throughout the document, when it says:

The EBNF (scattered throughout the document) does not match the examples
nor the prose. It is also ambiguous in places (allowing two different
interpretations of a parameter list), and nonsensical in others (such
as the handling of whitespace).

It should say:

The EBNF should be corrected as follows:

issuevalue = *WSP [domain *WSP] [";" *WSP [parameters *WSP]]

domain = label *("." label)
label = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT))

parameters = (parameter *WSP ";" *WSP parameters) / parameter
parameter = tag *WSP "=" *WSP value
tag = (ALPHA / DIGIT) *(ALPHA / DIGIT)
value = *(%x21-3A / %x3C-7E)

Notes:

[EBNF, text, examples do not match.]

I am proposing this on behalf of the IETF ACME WG. We want to submit a standards-track document, but the current CAA specification is broken. We know it is being revised, but we do not want to wait. Our AD has said to submit the errata and he will accept it.

Errata ID: 4070
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: JINMEI Tatuya
Date Reported: 2014-08-05
Held for Document Update by: Kathleen Moriarty
Date Held: 2014-09-04

Section 3 says:

   $ORIGIN example.com
   .       CAA 0 issue "ca.example.net"

It should say:

   $ORIGIN example.com.
           CAA 0 issue "ca.example.net"

Notes:

The original text is obviously incorrect (or at least something not really intended) in that the owner name is absolute. It just doesn't make sense to use $ORIGIN if we use an absolute owner name for the actual RR. The "corrected text" is one representation of what I guess the author really intended.

There are other instances of the same kind of this error in this section, but I don't bother to list all of them as it should be obvious and the sense of the "fix" should be the same.

From the verification of the errata:
The errata is correct as reported with the following caveat, some implementations of DNS presentation format assume all $ORIGIN statements are Fully Qualified Domain Names,
but others do not and those will take the domain name and append to it current origin.
Thus the trailing dot removes any ambiguity that the name specified is FQDN.

Errata ID: 5090
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mak Kolybabi
Date Reported: 2017-08-18
Held for Document Update by: Kathleen Moriarty
Date Held: 2017-08-22

Section 2.2 says:

   Resource Record Set (RRSet):  A set of Resource Records or a
      particular owner name, class, and type.  The time to live on all
      RRs with an RRSet is always the same, but the data may be
      different among RRs in the RRSet.

It should say:

   Resource Record Set (RRSet):  A set of Resource Records for a
      particular owner name, class, and type.  The time to live on all
      RRs with an RRSet is always the same, but the data may be
      different among RRs in the RRSet.

Notes:

Changed 'or' to 'for', the former not making sense in this context and being a likely typo.

Errata ID: 5091
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mak Kolybabi
Date Reported: 2017-08-18
Held for Document Update by: Kathleen Moriarty
Date Held: 2017-08-22

Section 4 says:

   o  If CAA(X) is not empty, R(X) = CAA (X), otherwise

It should say:

   o  If CAA(X) is not empty, R(X) = CAA(X), otherwise

Notes:

Remove unnecessary space after second CAA, making appearances of CAA(X) consistent throughout the section.
This builds on errata 5065, where this error wasn't fixed.

RFC 6857, "Post-Delivery Message Downgrading for Internationalized Email Messages", March 2013

Source of RFC: eai (app)

Errata ID: 5419
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Occil
Date Reported: 2018-07-13
Held for Document Update by: Alexey Melnikov
Date Held: 2018-07-26

Section 3.2.1 says:

From:
   Sender:
   To:
   Cc:
   Bcc:
   Reply-To:
   Resent-From:
   Resent-Sender:
   Resent-To:
   Resent-Cc:
   Resent-Bcc:
   Resent-Reply-To:
   Return-Path:
   ^^^^^^^^^^^
   Disposition-Notification-To:

It should say:

From:
   Sender:
   To:
   Cc:
   Bcc:
   Reply-To:
   Resent-From:
   Resent-Sender:
   Resent-To:
   Resent-Cc:
   Resent-Bcc:
   Resent-Reply-To:
   Disposition-Notification-To:

Notes:

Under RFC 5322 sec. 3.6.7, the Return-Path header field contains no production named "address", but at most a production named "angle-addr", which does not accept display names, for one. An update to this RFC could discuss this header field in its own section.

I agree with John Levine's comment on this:
This erratum is correct. I would suggest hold for update, since it is not
my impression that this flavor of downgrade is used very much if at all.

RFC 6870, "Pseudowire Preferential Forwarding Status Bit", February 2013

Note: This RFC has been updated by RFC 7771

Source of RFC: pwe3 (rtg)

Errata ID: 3656
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Joël Repiquet
Date Reported: 2013-06-17
Held for Document Update by: Stewart Bryant

Throughout the document, when it says:

Section 15

It should say:

Appendix A

Notes:

8 occurences: Section 15, 15.2, 15.5, Section 15.2, Section 15.1, Section 15.1, Section 15.3, Section 15.3

RFC 6878, "IANA Registry for the Session Initiation Protocol (SIP) "Priority" Header Field", March 2013

Source of RFC: sipcore (rai)

Errata ID: 3628
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lawrence Jovellanos
Date Reported: 2013-05-17
Held for Document Update by: Gonzalo Camarillo

Section 2 says:

This policy was chosen over lighter-weight policies due the potential
architectural impact of the semantics associated with new values.

It should say:

This policy was chosen over lighter-weight policies due to the potential 
architectural impact of the semantics associated with new values.

RFC 6887, "Port Control Protocol (PCP)", April 2013

Note: This RFC has been updated by RFC 7488, RFC 7652, RFC 7843

Source of RFC: pcp (int)

Errata ID: 3891
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Matt Dainty
Date Reported: 2014-02-14
Held for Document Update by: Ted Lemon
Date Held: 2014-02-17

Section 13.3 says:

The Prefix Length indicates how many bits of the address are used for
the filter.  For IPv4 addresses (which are encoded using the
IPv4-mapped address format (::FFFF:0:0/96)), this means valid prefix
lengths are between 96 and 128 bits, inclusive.  That is, add 96 to
the IPv4 prefix length.  For IPv6 addresses, valid prefix lengths are
between 0 and 128 bits, inclusive.  Values outside those ranges cause
the PCP server to return the MALFORMED_OPTION result code.

To remove all existing filters, the Prefix Length 0 is used.  There
is no mechanism to remove a specific filter.

It should say:

The Prefix Length indicates how many bits of the address are used for
the filter.  For IPv4 addresses (which are encoded using the
IPv4-mapped address format (::FFFF:0:0/96)), this means valid prefix
lengths are between 97 and 128 bits, inclusive.  That is, add 96 to
the IPv4 prefix length.  For IPv6 addresses, valid prefix lengths are
between 1 and 128 bits, inclusive.  Values outside those ranges cause
the PCP server to return the MALFORMED_OPTION result code.

To remove all existing filters, the Prefix Length 0 is used.  The
Remote Peer Port and Remote Peer IP Address fields MUST be set to zero
on transmission and MUST be ignored on reception.  There is no
mechanism to remove a specific filter. 

Notes:

A mapping with a filter containing an address-specific prefix length of 0 doesn't provide any value as it's no different to a mapping with no filters at all.

Since a prefix length of 0 is not even possible for IPv6 addresses, it should not be possible for IPv4 addresses either. Therefore the valid prefix length range for IPv4 addresses should be 97 to 128 bits inclusive and the valid range for IPv6 addresses should be documented as 1 to 128 bits inclusive in addition to a prefix length of 0 being documented as the special case.

Also clarify in that special case that it doesn't matter what the remote peer port and IP address fields are and therefore follow the convention throughout the RFC of setting to zero on transmission and ignoring on reception.

RFC 6902, "JavaScript Object Notation (JSON) Patch", April 2013

Source of RFC: appsawg (app)

Errata ID: 4787
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Daniel Frey
Date Reported: 2016-08-25
Held for Document Update by: Alexey Melnikov
Date Held: 2017-02-23

Section 4.2 says:

The "remove" operation removes the value at the target location.

The target location MUST exist for the operation to be successful.

For example:

{ "op": "remove", "path": "/a/b/c" }

If removing an element from an array, any elements above the
specified index are shifted one position to the left.

It should say:

The "remove" operation removes the value at the target location.

The target location MUST exist for the operation to be successful.

For example:

{ "op": "remove", "path": "/a/b/c" }

If removing an element from an array, any elements above the
specified index are shifted one position to the left.

The target location MUST NOT be a reference to the root. It is an
error in this document:

{ "op": "remove", "path": "" }

Notes:

The semantics of { "op": "remove", "path": "" } are never specified. If we allow to remove the root element, what would the result be? It would no longer be a valid JSON document, hence I propose to explicitly require the path of the "remove" operation to not reference the root.

Mark Nottingham: This isn't an errata; it would require gaining consensus and updating the document. See also: https://github.com/json-patch/json-patch2

RFC 6920, "Naming Things with Hashes", April 2013

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 7129
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Venkatesh
Date Reported: 2022-09-13
Held for Document Update by: RFC Editor
Date Held: 2022-09-19

Section 8.1 says:

   The following ni URI is generated from the text "Hello World!" (12
   characters without the quotes), using the sha-256 algorithm shown
   with and without an authority field:

   ni:///sha-256;f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk

   ni://example.com/sha-256;f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk

It should say:

   The following ni URI is generated from the text "Hello World!" (12
   characters without the quotes), using the sha-256 algorithm shown
   with and without an authority field:

   ni://example.com/sha-256;f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk

   ni:///sha-256;f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk

Notes:

Make example consistent with the "with and without" language.

--VERIFIER NOTES--
This has been marked as held for document update per author input: co-authors […] concluded that indeed it would be more clear if the order of the examples was changed as suggested by the report.

RFC 6931, "Additional XML Security Uniform Resource Identifiers (URIs)", April 2013

Note: This RFC has been obsoleted by RFC 9231

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 3965
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Axel Puhlmann
Date Reported: 2014-04-15
Held for Document Update by: Roman Danyliw
Date Held: 2022-01-19

Section 4.2 and 4.1 says:

   2006/12/xmlc12n11#                  [CANON11]  Canonicalization
   2006/12/xmlc14n11#WithComments      [CANON11]  Canonicalization

It should say:

   2006/12/xmlc12n11#   {Bad}          [CANON11]
   2006/12/xmlc14n11#                  [CANON11]

Notes:

As explained in Appendix B of draft-eastlake-rfc6931bis-xmlsec-uris:

[RFC6931] included two bad URIs as shown below. "{Bad}" in the
indexes (Sections 4.1 and 4.2) indicates such a bad value.
Implementations SHOULD only generate the correct URI but SHOULD
understand both the correct and erroneous URI.

2006/12/xmlc12n11#
Appears in the indices (Section 4.1 and 4.2] of [RFC6931] when it
should be "2006/12/xmlc14n11#" (i.e., the "12" inside "xmlc12n11"
should have been "14"). This is [Err3965] and is corrected in
this document.

==[ Original Text
--[ corrected text
2006/12/xmlc14n11# [CANON11] Canonicalization
2006/12/xmlc14n11#WithComments [CANON11] Canonicalization

-- [notes
[CANON11] referencing to <http://www.w3.org/TR/2008/REC-xml-c14n11-20080502/>
only talks about c14n and not c12n.

If this is not a flaw but done purposely, there should be a not about it.

I could not find the original definitions for xmlc12n11 and xmlc14n11.
They are not in the referenced document.
(And google only shows copies of this rfc.)

For stability reasons it may be better to not change/correct this, as it may be already in use.
So a note about this discrepance may be appropriate. Or a reference to the document defining those uris.

Errata ID: 4004
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Frederick Hirsch
Date Reported: 2014-05-29
Held for Document Update by: Roman Danyliw
Date Held: 2022-01-18

Section 2.3.11 says:

2.3.11.  RSA-SHA224

Identifier:
     http://www.w3.org/2007/05/xmldsig-more#rsa-sha224

  This implies the PKCS#1 v1.5 padding algorithm [RFC3447] as described
  in Section 2.3.1, but with the ASN.1 BER SHA-224 algorithm designator
  prefix.  An example of use is

  <SignatureMethod
     Algorithm="http://www.w3.org/2007/05/xmldsig-more#rsa-sha224" />

  Because it takes about the same effort to calculate a SHA-224 message
  digest as it does a SHA-256 message digest, it is suggested that
  RSA-SHA256 be used in preference to RSA-SHA224 where possible.

It should say:

2.3.11.  RSA-SHA224

Identifier:
     http://www.w3.org/2001/04/xmldsig-more#rsa-sha224

  This implies the PKCS#1 v1.5 padding algorithm [RFC3447] as described
  in Section 2.3.1, but with the ASN.1 BER SHA-224 algorithm designator
  prefix.  An example of use is

  <SignatureMethod
     Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha224" />

  Because it takes about the same effort to calculate a SHA-224 message
  digest as it does a SHA-256 message digest, it is suggested that
  RSA-SHA256 be used in preference to RSA-SHA224 where possible.

Notes:

RFC 6931 should be corrected to use the same identifier for RSA-SHA224 as is used in the W3C Recommendation "XML Signature Syntax and Processing Version 1.1? normative section 6.4.2 ( http://www.w3.org/TR/2013/REC-xmldsig-core1-20130411/#sec-PKCS1 ).

This same identifier is also specified in the W3C Note "XML Security Algorithm Cross-Reference? section 3.2 ( http://www.w3.org/TR/2013/NOTE-xmlsec-algorithms-20130411/#RSA )

At least two shipping code implementations use this value from the W3C Recommendation ; to enable interoperability, avoid confusion and be consistent with the published Recommendation RFC 6931 should be updated to be consistent.

Please note that the revision affects both the identifier URL and the Algorithm attribute value in the 2.3.11 section which is why the entire section is given in the Original and Corrected text above.

Errata ID: 3597
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Annie Yousar
Date Reported: 2013-04-18
Held for Document Update by: Sean Turner

Section References says:

[XMLDSIG11]   Eastlake, D., Reagle, J., Solo, D., Hirsch, F.,
              Nystrom, M., Roessler, T., and K. Yiu, "XML Signature
              Syntax and Processing Version 1.1", W3C Proposed
              Recommendation, 24 January 2013,
              <http://www.w3.org/TR/2013/PR-xmldsig-core1-20130124/>.

It should say:

[XMLDSIG11]   Eastlake, D., Reagle, J., Solo, D., Hirsch, F.,
              Nystrom, M., Roessler, T., and K. Yiu, "XML Signature
              Syntax and Processing Version 1.1", W3C Recommendation,
              11 April 2013, <http://www.w3.org/TR/xmldsig-core1/>.

Notes:

A normative reference should point to the final and not to the pre version even if there are differences.

RFC 6933, "Entity MIB (Version 4)", May 2013

Source of RFC: eman (ops)

Errata ID: 4122
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Robert Fox
Date Reported: 2014-09-24
Held for Document Update by: Benoit Claise
Date Held: 2014-10-07

Section 2.12.1 says:

The URN namespace for CLEIs is defined in [RFC4152], and the CLEI format
is defined in [T1.213] and [T1.213a]. For example, an entPhysicalUris 
instance may have the value of:

URN:CLEI:D4CE18B7AA

[RFC3986] and [RFC4152] identify this as a URI in the CLEI URN 
namespace. The specific CLEI code, D4CE18B7AA, is based on the 
example provided in [T1.213a].

It should say:

The URN namespace for CLEIs is defined in [RFC4152], and the CLEI format
is defined in [ATIS-0300213]. For example, an entPhysicalUris instance
may have the value of:

URN:CLEI:IPUIADEUAA

[RFC3986] and [RFC4152] identify this as a URI in the CLEI URN 
namespace. The specific CLEI code, IPUIADEUAA, is based on the 
example provided in [ATIS-0300213].

Notes:

The ATIS standards T1.213 and T1.213a are obsolete and have
been replaced by ATIS-0300213. The example in ATIS-0300213 uses a
different CLEI Code, IPUIADEUAA

Errata ID: 4123
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Robert Fox
Date Reported: 2014-09-24
Held for Document Update by: Benoit Claise
Date Held: 2014-10-07

Section 8.2 says:

[T1.213] ATIS T1.213-2001, "Coded Identification of Equipment
Entities in the North American Telecommunications
System for Information Exchange", 2001, <www.ansi.org>.

[T1.213a] ATIS T1.213a, "Supplement to T1.213-2001, Coded
Identification of Equipment Entities in the North
American Telecommunications System for Information
Exchange, to Correct the Representation of the Basic
Code in Figure B.1", 2001, <www.ansi.org>.

It should say:

[ATIS-0300213] ATIS-0300213, "Structure for the 
Identification of Equipment Entities for Information 
Exchange", 2006, <www.ansi.org>.

Notes:

The ATIS standards T1.213 and T1.213a are obsolete and have
been replaced by ATIS-0300213.

RFC 6936, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", April 2013

Source of RFC: 6man (int)

Errata ID: 4341
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Brian Carpenter
Date Reported: 2015-04-20
Held for Document Update by: Brian Haberman
Date Held: 2015-04-22

Section 1.3.5 says:

The ingress of a tunnel seeking to provide good
entropy in the flow label field would therefore need to create a
random flow label value and keep corresponding state so that all
packets that were associated with a flow would be consistently given
the same flow label.  Although possible, this complexity may not be
desirable in a tunnel ingress.

It should say:

The ingress of a tunnel seeking to provide good
entropy in the flow label field would therefore need to create a
pseudo-random flow label value using a stateless method
as described in [RFC6438] so that all
packets that were associated with a flow would be consistently given
the same flow label.

Notes:

It is incorrect that a stateful method is needed, and presumably that
was the complexity judged undesirable. Also, we shouldn't say "random"
when we mean "pseudo-random."

RFC 6940, "REsource LOcation And Discovery (RELOAD) Base Protocol", January 2014

Source of RFC: p2psip (rai)

Errata ID: 4486
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Roland Bless
Date Reported: 2015-09-28
Held for Document Update by: Ben Campbell
Date Held: 2015-09-28

Section 10.8 says:

10.8.  Route Query f.in 3

It should say:

10.8.  Route Query

Notes:

This is a formatting nit, probably caused by an nroff remnant. However, a bit confusing nevertheless...

RFC 6958, "RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Loss Metric Reporting", May 2013

Source of RFC: xrblock (rai)

Errata ID: 4524
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Varun Singh
Date Reported: 2015-11-06
Held for Document Update by: Alissa Cooper
Date Held: 2015-12-07

Section 3.2 says:

  Number of Bursts: 16 bits

    The number of bursts in the period of the report (Interval or
    Cumulative).

    The measured value is an unsigned value.  If the measured value
    exceeds 0xFFFD, the value 0xFFFE MUST be reported to indicate
    an over-range measurement.  If the measurement is unavailable,
    the value 0xFFFF MUST be reported.

It should say:

  Number of Bursts: 12 bits

    The number of bursts in the reporting period (Interval or
    Cumulative).

    The measured value is an unsigned value.  If the measured value
    exceeds 0xFFD, the value 0xFFE MUST be reported to indicate
    an over-range measurement.  If the measurement is unavailable,
    the value 0xFFF MUST be reported.

Notes:

This was discussed on the mailing list after the Prague meeting and agreed at the Yokohama meeting.

Errata ID: 4525
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Varun Singh
Date Reported: 2015-11-06
Held for Document Update by: Alissa Cooper
Date Held: 2015-12-07

Section 3.1 says:

      0               1               2               3               4
      0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     BT=33     |   Reserved    |      Block length = 4         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       SSRC of Source                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       begin_seq               |          end_seq              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Post-repair loss count       |     Repaired loss count       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Block length: 16 bits

      This field is in accordance with the definition in [RFC3611].  In
      this report block, it MUST be set to 4.  The block MUST be
      discarded if the block length is set to a different value.

It should say:

      0               1               2               3               4
      0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     BT=33     |   Reserved    |      Block length = 3         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       SSRC of Source                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       begin_seq               |          end_seq              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Post-repair loss count       |     Repaired loss count       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Block length: 16 bits

      This field is in accordance with the definition in [RFC3611].  In
      this report block, it MUST be set to 3.  The block MUST be
      discarded if the block length is set to a different value.

Notes:

The block length is calculated and indicated incorrectly in two places: the packet format and the definition of the block length.

RFC 6960, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", June 2013

Note: This RFC has been updated by RFC 8954

Source of RFC: pkix (sec)

Errata ID: 5730
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Jaime Hablutzel
Date Reported: 2019-05-22
Held for Document Update by: Paul Wouters
Date Held: 2024-02-23

Section 4.1.1 says:

optionalSignature contains the algorithm identifier and any
associated algorithm parameters in signatureAlgorithm; the
signature value in signature; and, optionally, certificates the
server needs to verify the signed response (normally up to but not
including the client’s root certificate).

It should say:

optionalSignature contains the algorithm identifier and any
associated algorithm parameters in signatureAlgorithm; the
signature value in signature; and, optionally, certificates the
server needs to verify the signed request (normally up to but not
including the client’s root certificate).

Notes:

The paragraph refers to the signed "response" where it should refer to the signed "request".

RFC 6979, "Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)", August 2013

Source of RFC: INDEPENDENT

Errata ID: 5963
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Annie Yousar
Date Reported: 2020-01-23
Held for Document Update by: Adrian Farrel
Date Held: 2020-01-26

Section 3.2 says:

   b.  Set:

          V = 0x01 0x01 0x01 ... 0x01

       such that the length of V, in bits, is equal to 8*ceil(hlen/8).
:
:
   c.  Set:

          K = 0x00 0x00 0x00 ... 0x00

       such that the length of K, in bits, is equal to 8*ceil(hlen/8).

It should say:

   b.  Set:

          V = 0x010101...01

       such that the length of V, in bits, is equal to 8*ceil(hlen/8).
:
:
   c.  Set:

          K = 0x000000...00

       such that the length of K, in bits, is equal to 8*ceil(hlen/8).

Notes:

Hrmonize the notations in 3.2 and A.1.1, where the hex string q is denoted as
0x4000000000000000000020108A2E0CC0D99F8A5EF
and not as
0x40 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x20 0x10 0x8A 0x2E 0x0C 0xC0 0x0D 0x99 0xF8 0xA5 0xEF.

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.

RFC 7001, "Message Header Field for Indicating Message Authentication Status", September 2013

Note: This RFC has been obsoleted by RFC 7601

Note: This RFC has been updated by RFC 7410

Source of RFC: appsawg (app)

Errata ID: 4201
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2014-12-15
Held for Document Update by: Barry Leiba
Date Held: 2015-02-17

Section C.5 says:

        Authentication-Results: example.com;
                  sender-id=fail header.from=example.com;
                  dkim=pass (good signature) header.d=example.com

It should say:

No idea

Notes:

The Sender-ID test is OK (header From:) but the DKIM one names a field
in the DKIM-Signature: header (d=). Isn't it a violation of section
2.2, which says 'if "ptype" is "header", this indicates from which header field the value being evaluated was extracted' Or is section 2.2 an insufficient description?

----- Verifier Notes -----
The resolution of this isn't straightforward, and will require discussion and a proper update. That is now ongoing.

RFC 7006, "Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP)", September 2013

Source of RFC: mmusic (rai)

Errata ID: 3738
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: pearl liang
Date Reported: 2013-09-25
Held for Document Update by: Gonzalo Camarillo
Date Held: 2013-11-14

Section 6.1 says:

6.1.  New SDP Attributes

   IANA has registered new attributes in the "att-field (both session
   and media level)" subregistry of the "Session Description Protocol
   (SDP) Parameters" registry, according to the following registration
   form:

Attribute name: bcap
Long form name: Bandwidth Capability
Type of attribute: Both media and session level
Subject to charset: No
Purpose: Negotiate session or media-level bandwidths
Appropriate values: See RFC 7066, Section 3.1.1
Contact name: Miguel A. Garcia
Miguel.A.Garcia@ericsson.com

Attribute name: ccap
Long form name: Connection Data Capability
Type of attribute: Both media and session level
Subject to charset: No
Purpose: Negotiate media-level connection data
Appropriate values: See RFC 7066, Section 3.1.2
Contact name: Miguel A. Garcia
Miguel.A.Garcia@ericsson.com


Attribute name: icap
Long form name: Title Capability
Type of attribute: Both media and session level
Subject to charset: Yes
Purpose: Negotiate human-readable information
describing the session or media
Appropriate values: See RFC 7066, Section 3.1.3
Contact name: Miguel A. Garcia
Miguel.A.Garcia@ericsson.com

It should say:

6.1.  New SDP Attributes

   IANA has registered new attributes in the "att-field (both session
   and media level)" subregistry of the "Session Description Protocol
   (SDP) Parameters" registry, according to the following registration
   form:

Attribute name: bcap
Long form name: Bandwidth Capability
Type of attribute: Both media and session level
Subject to charset: No
Purpose: Negotiate session or media-level bandwidths
Appropriate values: See RFC 7006, Section 3.1.1
Contact name: Miguel A. Garcia
Miguel.A.Garcia@ericsson.com

Attribute name: ccap
Long form name: Connection Data Capability
Type of attribute: Both media and session level
Subject to charset: No
Purpose: Negotiate media-level connection data
Appropriate values: See RFC 7006, Section 3.1.2
Contact name: Miguel A. Garcia
Miguel.A.Garcia@ericsson.com


Attribute name: icap
Long form name: Title Capability
Type of attribute: Both media and session level
Subject to charset: Yes
Purpose: Negotiate human-readable information
describing the session or media
Appropriate values: See RFC 7006, Section 3.1.3
Contact name: Miguel A. Garcia
Miguel.A.Garcia@ericsson.com

Notes:

The Appropriate values for the three New SDP Attributes have cited an incorrect RFC.
It should be RFC 7006, rather than RFC 7066.

RFC 7011, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", September 2013

Source of RFC: ipfix (ops)

Errata ID: 7413
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Duggan
Date Reported: 2023-04-02
Held for Document Update by: Wa
Date Held: 2023-04-26

Section 3.4.1 says:

Field Count

      Number of fields in this Template Record.

It should say:

Field Count

Number of fields in this Template Record. The Field Count MUST NOT be zero, unless used in a Template Withdrawal.

Notes:

If the size of data record corresponding to a template can ever be zero, then the only valid size for such a data set is the size of the set header. For normal cases any size greater than that of the set header is a valid size, since records are read from a set until the number of octets remaining is less than the smallest possible record size for that set. If a record size can be zero, then any number of bytes past the header cannot be padding (is not smaller than the smallest record), and a conforming implementation might return an infinite number of zero-sized records. As this could cause a denial of service situation, rejecting templates that define zero-sized records seems to be the simplest solution.

Similar text may be necessary for Option Template records, though the fact that the scope count MUST be non-zero may negate the necessity.

---
WK: See thread https://mailarchive.ietf.org/arch/msg/ipfix/AkCZr1jObLt_x9cyQ73qXBlKC2w/ for more info.
WK - 2023-04-26: Update from the original reporter (Michael) and confirmations from authors (Brian and Benoit) that Field Count can be zero in the case of Template Withdrawal. Changing the state from Verified to HFDU, so that this can be better clarified in any future updates.

Errata ID: 3732
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2013-09-21
Held for Document Update by: Benoit Claise
Date Held: 2013-10-26

Section 1.1 says:

A new Section 5.2 has been added to address wraparound of these
     timestamp data types after they overflow in the years 2032-2038.

It should say:

A new Section 5.2 has been added to address wraparound of these
    timestamp data types after they overflow.

Notes:

Since dateTimeSeconds is encoded in an _unsigned_ integer, it will wraparound in 2106 (as written correctly in section 5.2), not 2038.

Errata ID: 4216
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2014-12-31
Held for Document Update by: Benoit Claise
Date Held: 2015-01-04

Section 3.4.2.2 says:

   Scope Field Count

      Number of scope fields in this Options Template Record.  The Scope
      Fields are normal Fields, except that they are interpreted as
      scope at the Collector.  A scope field count of N specifies that
      the first N Field Specifiers in the Template Record are Scope
      Fields.  The Scope Field Count MUST NOT be zero.

It should say:

   Scope Field

      Scope Fields are normal Fields, except that they are interpreted
      as scope at the Collector.

   Scope Field Count

      Number of scope fields in this Options Template Record.
      A scope field count of N specifies that
      the first N Field Specifiers in the Template Record are Scope
      Fields.  The Scope Field Count MUST NOT be zero.

Notes:

Separate out the "Scope Field" definition from "Scope Field Count", since "Scope Field" is used as a defined term throughout the document without a formal definition.

RFC 7012, "Information Model for IP Flow Information Export (IPFIX)", September 2013

Source of RFC: ipfix (ops)

Errata ID: 6564
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2021-04-28
Held for Document Update by: Rob Wilton
Date Held: 2024-01-15

Section 7.2 says:

   The specification
   of new MPLS label types MUST be published using a well-established
   and persistent publication medium.

It should say:

(Deleted)

Notes:

This paragraph envisaged that a new RFC be written to specify new label types in the mplsTopLabelType sub-registry.

Since the publication of RFC7012, IANA has added 16 other IPFIX IE sub-registries, none of which have the same requirement. See https://www.iana.org/assignments/ipfix/ipfix.xhtml

Publication in IANA's IPFIX registry should provide a clear and persistent definition. New IPFIX MPLS label type specifications should not be singled out to require persistent publication of an additional document.

RFC 7030, "Enrollment over Secure Transport", October 2013

Note: This RFC has been updated by RFC 8951, RFC 8996

Source of RFC: pkix (sec)

Errata ID: 4384
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Pierce Leonberger
Date Reported: 2015-06-02
Held for Document Update by: Roman Danyliw
Date Held: 2020-08-19

Section 4.5.2 says:

CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID

AttrOrOID ::= CHOICE (oid OBJECT IDENTIFIER, attribute Attribute }

Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE {
     type   ATTRIBUTE.&id({IOSet}),
     values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type}) }

It should say:

AttrOrOID ::= CHOICE {
      oid OBJECT IDENTIFIER, 
      attribute Attribute{YouNeedToDefineOrReferenceAnObjectSet}
}

Notes:

1. The AttrOrOID CHOICE was started with a '(' versus a '{'.

2. Attribute{} is a parameterized type and you are missing the parameter reference within the AttrOrOID CHOICE for "attribute".

3. You need to define or reference the object set to be used in #2.

Highly recommend you create an ASN.1 Module as part of this specification. This will make it clear which specifications (and the versions there of) you are importing types from (i.e. Attribute{}) and the tagging that should be used (module level). If you need to define a new object set for #3 then this new module would be the perfect home for it.

Errata ID: 5107
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Sean Turner
Date Reported: 2017-09-07
Held for Document Update by: Roman Danyliw
Date Held: 2020-08-19

Section 3.2.1 says:

It should say:

Add the following is as the last paragraph of Section 3.2.1:

  [RFC2616] indicates "HTTP does not use the
  Content-Transfer-Encoding (CTE) field of RFC 2045”; nevertheless, this
  document was published specifying the use of the
  Content-Transfer-Encoding header with a value of ‘base64' in Sections
  4.1.3, 4.3.1, 4.3.2, 4.4.2, 4.5.2, as well as in the examples in
  Appendices A.1-A.4.   As HTTP is binary-clean transport, there is no
  need to indicate this for HTTP-based protocols like EST.  EST server
  implementations SHOULD omit the Content-Transfer-Encoding header if
  they know a priori that EST clients do not rely this field.  EST
  Clients SHOULD expect that the Content-Transfer-Encoding header will
  be absent unless they have an a priori agreement with the EST server.
  The mechanism to establish this client dependency is out-of-scope.

Notes:

EST, which is an HTTP-based protocol, erroneous used CTE. This errata addresses this error.

Note that the text was reviewed by a RAI AD as well as multiple EST implementors.

Errata ID: 5108
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Sean Turner
Date Reported: 2017-09-07
Held for Document Update by: Roman Danyliw
Date Held: 2020-08-19

Section 4.2.3, 4.4.2 says:

OLD from s.4.2.3:

  If the content-type is not set, the response data MUST be a plaintext
  human-readable error message containing explanatory information
  describing why the request was rejected (for example, indicating that
  CSR attributes are incomplete).

OLD from s4.4.2:

  If the content-type is not set, the response data MUST be a plaintext
  human-readable error message.

It should say:

NEW for s4.2.3:

  If the content-type is not set, the response data must be a plaintext
  human-readable error message containing explanatory information
  describing why the request was rejected (for example, indicating that
  CSR attributes are incomplete).  Servers MAY use the "text/plain”
  content-type [RFC2046] for human-readable errors.

NEW for s4.4.2:

  If the content-type is not set, the response data must be a plaintext
  human-readable error message. Servers MAY use the "text/plain”
  content-type [RFC2046] for human-readable errors.

Notes:

The current text is somewhat unclear as to what content-type needs to be used for the human-readable error. There are many human-readable content-types, but "text/plain" seems to be the most sensible.

Note that the MUST was reduced to a must because no content-type is specified.

RFC 7049, "Concise Binary Object Representation (CBOR)", October 2013

Note: This RFC has been obsoleted by RFC 8949

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 5434
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: LAMBERT David
Date Reported: 2018-07-22
Held for Document Update by: Barry Leiba
Date Held: 2020-07-17

Section E.6 says:

   |               |                         |                         |
   | UBJSON        | 61 02 42 01 61 02 42 02 | 61 ff 42 01 61 02 42 02 |
   |               | 42 03                   | 42 03 45                |
   |               |                         |                         |

It should say:

   |               |                         |                         |
   | UBJSON        | 5B 23 55 02 55 01 5B 23 | 5B 55 01 5B 55 02 55 03 |
   |               | 55 02 55 02 55 03       | 5D 5D                   |
   |               |                         |                         |

Notes:

According to UBJSON type specification available at
http://ubjson.org/type-reference/ arrays are encoded with square-brackets '[' and ']', or with '[' followed by '#' to specify the element count.

Errata ID: 5763
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: John Visosky
Date Reported: 2019-06-26
Held for Document Update by: Barry Leiba
Date Held: 2020-07-17

Section 2.4 says:

A tag always applies to the item that is directly followed by it.

It should say:

A tag always applies to the item that directly follows it.

Notes:

The 'it' in the original text refers to the tag, so the sentence reads that the tag follows the item. In fact, the item follows the tag.

Errata ID: 5917
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Faye Amacker
Date Reported: 2019-11-24
Held for Document Update by: Barry Leiba
Date Held: 2019-11-24

Section Appendix A says:

simple(24)                   | 0xf818  

Notes:

This example violates RFC 7049 section 2.3 Floating-Point Numbers and Values with No Content.

The incorrect example in Appendix A clearly uses a value <32 which is not allowed.

First, RFC 7049 section 2.3 has a table that shows:
| 24 | Simple value (value 32..255 in following byte) |

Next, RFC 7049 section 2.3 says:
As with all other major types, the 5-bit value 24 signifies a single-
byte extension: it is followed by an additional byte to represent the
simple value. (To minimize confusion, only the values 32 to 255 are
used.)

Wikipedia is also currently incorrect by having an interpretation based on the incorrect example from RFC 7049 Appendix A instead of the text from RFC 7049 Section 2.3.

Credits: This problem was first reported at https://github.com/fxamacker/cbor/issues/46

Errata ID: 4294
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eric Myhre
Date Reported: 2015-03-07
Held for Document Update by: Barry Leiba
Date Held: 2015-03-07

Section 2.2.1 says:

   BF           -- Start indefinite-length map
      63        -- First key, UTF-8 string length 3
         46756e --   "Fun"
      F5        -- First value, true
      63        -- Second key, UTF-8 string length 3
         416d74 --   "Amt"
      21        -- -2
      FF        -- "break"

It should say:

   BF           -- Start indefinite-length map
      63        -- First key, UTF-8 string length 3
         46756e --   "Fun"
      F5        -- First value, true
      63        -- Second key, UTF-8 string length 3
         416d74 --   "Amt"
      21        -- Second value, -2
      FF        -- "break"

Notes:

This is only a break in phrasing consistency. There is no technical error.

RFC 7111, "URI Fragment Identifiers for the text/csv Media Type", January 2014

Source of RFC: INDEPENDENT

Errata ID: 5591
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Greg Skinner
Date Reported: 2019-01-05
Held for Document Update by: Adrian Farrel
Date Held: 2019-08-18

Section 1.3 says:

This is a reasonable fallback behavior and, in general users, should
take into account the possibility that a program interpreting a given
URI will fail to interpret the fragment identifier part.

It should say:

This is reasonable fallback behavior, and in general, users should
take into account the possibility that a program interpreting a given
URI will fail to interpret the fragment identifier part.

Notes:

fixed grammatical errors

RFC 7115, "Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)", January 2014

Source of RFC: sidr (rtg)

Errata ID: 4973
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tassos Chatzithomaoglou
Date Reported: 2017-03-18
Held for Document Update by: Alvaro Retana
Date Held: 2017-03-25

Section 3 & 5 says:

section 3
---------
For example, if, instead of 10.0.0.0/16-24, one issues
   10.0.0.0/16 and 10.0.42.0/24, a forged origin attack cannot succeed
   against 10.0.666.0/24. 

section 5
---------
Consider having a ROA for AS 42 for prefix
   10.0.0.0/16-24.  A BGP announcement for 10.0.666.0/24 from AS 666
   would be Invalid

It should say:

section 3
---------
For example, if, instead of 10.0.0.0/16-24, one issues
   10.0.0.0/16 and 10.0.42.0/24, a forged origin attack cannot succeed
   against 10.0.66.0/24. 

section 5
---------
Consider having a ROA for AS 42 for prefix
   10.0.0.0/16-24.  A BGP announcement for 10.0.66.0/24 from AS 666
   would be Invalid

Notes:

666 is not a valid octet for an ipv4 address

===
I am marking this report as "Held for Document Update" [1], which means that the author might consider its merits for a future update. If the use of the "666" octet was intentional, then a short note explaining might be appropriate to avoid further confusion.

- Alvaro.

[1] https://www.ietf.org/iesg/statement/errata-processing.html

RFC 7121, "High Availability within a Forwarding and Control Element Separation (ForCES) Network Element", February 2014

Note: This RFC has been updated by RFC 7391

Source of RFC: forces (rtg)

Errata ID: 5677
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2019-03-28
Held for Document Update by: Alvaro Retana
Date Held: 2019-09-10

Section 3.2 says:

   If the FE is unable to find an associated FE in its list of CEs, then
   it MUST attempt to connect and associate with the first from the list
   of all CEs and continue in a round-robin fashion until it connects
   and associates with a CE or the CEFTI timer expires.

It should say:

   If the FE is unable to find an associated CE in its list of CEs, then
   it MUST attempt to connect and associate with the first from the list
   of all CEs and continue in a round-robin fashion until it connects
   and associates with a CE or the CEFTI timer expires.

Notes:

First line at p. 17
FE is mistakenly specified instead of CE.

RFC 7126, "Recommendations on Filtering of IPv4 Packets Containing IPv4 Options", February 2014

Source of RFC: opsec (ops)

Errata ID: 5798
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mohamed Boucadair
Date Reported: 2019-07-30
Held for Document Update by: Warren Kumari (Ops AD)
Date Held: 2019-07-30

Section 1.1 says:

   The terms "fast path", "slow path", and associated relative terms
   ("faster path" and "slower path") are loosely defined as in Section 2
   of [RFC6398].

Notes:

These terms are not used in the document. The quoted text should be removed.

RFC 7130, "Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces", February 2014

Source of RFC: bfd (rtg)

Errata ID: 5741
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Anoop Ghanwani
Date Reported: 2019-05-30
Held for Document Update by: Martin Vigoureux
Date Held: 2019-06-17

Section 1 says:

While there are native Ethernet mechanisms to detect failures 
(802.1ax, .3ah)

It should say:

While there are native Ethernet mechanisms to detect failures 
(802.1AX, 802.3ah)

Notes:

ax should be capitalized.

Errata ID: 5742
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Anoop Ghanwani
Date Reported: 2019-05-30
Held for Document Update by: Martin Vigoureux
Date Held: 2019-06-17

Section 2.3 says:

Micro-BFD packets SHOULD always be sent untagged.  However, when the
LAG is operating in the context of IEEE 802.1q or IEEE 802.qinq, 

It should say:

Micro-BFD packets SHOULD always be sent untagged.  However, when the
LAG is operating in the context of IEEE 802.1Q or IEEE 802.1ad, 

Notes:

q should be capitalized. The IEEE standard for QinQ is IEEE 802.1ad.

RFC 7132, "Threat Model for BGP Path Security", February 2014

Source of RFC: sidr (rtg)

Errata ID: 4454
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: David Mandelberg
Date Reported: 2015-08-25
Held for Document Update by: Alvaro Retana
Date Held: 2016-02-16

Section 1 says:

   PATHSEC is intended to address the concerns cited above, to provide
   significantly improved path security, which builds upon the route
   origination validation capability offered by use of the RPKI
   [RFC6810].

It should say:

   PATHSEC is intended to address the concerns cited above, to provide
   significantly improved path security, which builds upon the route
   origination validation capability offered by use of the RPKI
   [RFC6811].

Notes:

I think this text should reference RFC6811 (origin validation), not RFC6810 (the rpki-rtr protocol).

RFC 7139, "GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks", March 2014

Note: This RFC has been updated by RFC 7892

Source of RFC: ccamp (rtg)

Errata ID: 3930
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Adrian Farrel
Date Reported: 2014-03-23
Held for Document Update by: Adrian Farrel
Date Held: 2014-03-24

Section 3 says:

   [RFC4328] describes GMPLS signaling extensions to support the control
   for the 2001 revision of the G.709 specification.  However, [RFC7096]
   does not provide the means to signal all the new Signal Types and
   related mapping and multiplexing functionalities.  Moreover, it
   supports only the deprecated auto-MSI (Multiframe Structure
   Identifier) mode, which assumes that the Tributary Port Number (TPN)
   is automatically assigned in the transmit direction and not checked
   in the receive direction.

It should say:

   [RFC4328] describes GMPLS signaling extensions to support the control
   for the 2001 revision of the G.709 specification.  However, as 
   described in[RFC7096], that document does not provide the means to
   signal all the new Signal Types and related mapping and multiplexing
   functionalities.  Moreover, it supports only the deprecated auto-MSI
   (Multiframe Structure Identifier) mode, which assumes that the 
   Tributary Port Number (TPN) is automatically assigned in the transmit
   direction and not checked in the receive direction.

Notes:

RFC 7096 is the analysis of pre-existing GMPLS signalling. It does not contain any protocol extensions itself, but looks at the mechanisms provided in RFC 4328.

RFC 7159, "The JavaScript Object Notation (JSON) Data Interchange Format", March 2014

Note: This RFC has been obsoleted by RFC 8259

Source of RFC: json (app)

Errata ID: 4388
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kerry Lynn
Date Reported: 2015-06-09
Held for Document Update by: Barry Leiba
Date Held: 2015-06-09

Section 1.2 says:

   This document updates [RFC4627], which describes JSON and registers
   the media type "application/json".

It should say:

   This document replaces [RFC4627], which previously described JSON and
   registered the media type "application/json".

Notes:

The link at https://tools.ietf.org/html/rfc7159 says it obsoletes RFC 4627. I believe this is the intent and result of RFC 7159, and that RFC 4627 need not be consulted except for historical reasons going forward.

RFC 7170, "Tunnel Extensible Authentication Protocol (TEAP) Version 1", May 2014

Note: This RFC has been updated by RFC 9427

Source of RFC: emu (sec)

Errata ID: 5767
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Jouni Malinen
Date Reported: 2019-06-28
Held for Document Update by: Paul Wouters
Date Held: 2024-04-01

Section 3.3.1 says:

   EAP method messages are carried within EAP-Payload TLVs defined in
   Section 4.2.10.  If more than one method is going to be executed in
   the tunnel, then upon method completion, the server MUST send an
   Intermediate-Result TLV indicating the result.

It should say:

   EAP method messages are carried within EAP-Payload TLVs defined in
   Section 4.2.10.  Upon completion of each EAP authentication method in
   the tunnel, the server MUST send an Intermediate-Result TLV
   indicating the result.

Notes:

TEAP description is somewhat vague in discussion about "EAP methods" vs. "EAP authentication methods" as it comes to the EAP methods performed in Phase 2 within the TLS tunnel. RFC 3748 defines Identity request/response as an EAP method. However, this method is not an "authentication method" which is a special case of an method where the Type is 4 or greater.

RFC 7170 uses correct terminology in the first paragraph of Section 3.3.1 when talking about multiple authentication methods not being allowed by RFC 3748 in a single EAP conversation. However, many, but not all, of the following "[EAP] method" instances are actually referring to "[EAP] authentication method". This results in incorrect claims on when the Intermediate-Result TLV and Crypto-Binding TLV are used. They are not used after an EAP non-authentication method like Identity (e.g., see the example in C.3); they are used after each EAP authentication method like EAP-pwd.

Furthermore, the comment about "more than one method is going to be executed in the tunnel" does not sound accurate. This applies even if only a single EAP authentication method is executed in the tunnel (Identity method is not required to be executed). The proposed text in this errata entry addresses these two issues in Section 3.3.1. The following additional changes would be needed to make rest of the specification use the terms more accurately:

3.3.3: "after each successful EAP method" --> "after each successful EAP authentication method"
3.8.3: "completion of the EAP method" --> "completion of the EAP authentication method"
4.2.11: "between multiple inner EAP methods within EAP" --> "after each inner EAP authentication method"
4.2.13: "after each successful EAP method" --> "after each successful EAP authentication method"

Errata ID: 5770
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Jouni Malinen
Date Reported: 2019-07-01
Held for Document Update by: Paul Wouters
Date Held: 2024-04-02

Section 5.4 says:

   TEAP authentication assures the Master Session Key (MSK) and Extended
   Master Session Key (EMSK) output from the EAP method are the result
   of all authentication conversations by generating an Intermediate
   Compound Key (IMCK).  The IMCK is mutually derived by the peer and
   the server as described in Section 5.2 by combining the MSKs from
   inner EAP methods with key material from TEAP Phase 1.  The resulting
   MSK and EMSK are generated as part of the IMCKn key hierarchy as
   follows:

      MSK  = TLS-PRF(S-IMCK[j], "Session Key Generating Function", 64)
      EMSK = TLS-PRF(S-IMCK[j],
           "Extended Session Key Generating Function", 64)

   where j is the number of the last successfully executed inner EAP
   method.

Notes:

Section 5.4 claims that IMCK (and as such, also) S-IMCK[j] is derived by combining the MSKs from inner EAP methods while Section 5.2 talks about two different derivations: one based on MSK and the other one based on EMSK. Section 5.2 seems clear on both MSK and EMSK based values being used in Compound MAC (since both are actually included in the Crypto-Binding TLV). However, Section 5.2 does not clarify how a unique S-IMCK[j] should be derived since there can be two different IMSK[j] values based on whether the inner EAP method generates MSK and EMSK. This gets even more confusing if there is a series of inner EAP methods of which at least one generates both MSK and EMSK, at least one generates only MSK, and at least one does not generate either MSK or EMSK. How exactly would MSK/EMSK from TEAP be derived in those cases? Based on Section 5.4, these are based on S-IMCK[j], but it is not clear how that is derived due to Section 5.2 having three different ways of deriving the IMSK[j] and two different Compound MAC values (and consequently, two different ways of deriving S-IMCK[j] after each successfully completed EAP authentication method).

It does not look like this could work in practice. There needs to be a clear definition of how to derive a single S-IMCK[j] value for TEAP MSK/EMSK derivation. It would also be helpful to clarify how CMK[j] is derived for each inner EAP method in case of different MSK/EMSK derivation support between the EAP methods used in the sequence.

Paul Wouters(AD): This is curently all addressed in the 7170bis draft

RFC 7182, "Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)", April 2014

Source of RFC: manet (rtg)

Errata ID: 5346
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Denis Ovsienko
Date Reported: 2018-05-03
Held for Document Update by: Alvaro Retana
Date Held: 2018-05-24

Section 12.1 says:

      then L > log2(NRT/P).  For example, if N is 32, R is 1000, T is
      86400 (I day) and P is 10^-6, then L must be at least 52 bits.

It should say:

      then L > log2(NRT/P).  For example, if N is 32, R is 1000, T is
      86400 (1 day) and P is 10^-6, then L must be at least 52 bits.

Notes:

A Roman numeral in this context makes it more difficult to follow.

RFC 7183, "Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)", April 2014

Source of RFC: manet (rtg)

Errata ID: 4397
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jiazi
Date Reported: 2015-06-22
Held for Document Update by: Alvaro Retana
Date Held: 2015-06-22

Section 4 says:

Generation of TIMESTAMP Message TLVs (as defined in [RFC7182]) for
      inclusion in an outgoing message.  An implementation of [RFC6130]
      and [RFC7181] MAY use more than one ICV TLV in a message, but it
      MUST NOT use the same type extensio

It should say:

Generation of TIMESTAMP Message TLVs (as defined in [RFC7182]) for
      inclusion in an outgoing message.  An implementation of [RFC6130]
      and [RFC7181] MAY use more than one TIMESTAMP TLV in a message
      , but it MUST NOT use the same type extensio

Notes:

We are only talking about TIMESTAMP TLV in this paragraph.
I think it's an error when copying the text from the previous paragraph.

Errata ID: 5144
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Denis Ovsienko
Date Reported: 2017-10-04
Held for Document Update by: Alvaro Retana
Date Held: 2017-11-06

Section 8.1.3 says:

   is contained in message.  As an attacker cannot modify the content of
   this timestamp (as it is protected by the identity check value), an
   attacker cannot replay messages after this time.  Within this time

It should say:

   is contained in message.  As an attacker cannot modify the content of
   this timestamp (as it is protected by the integrity check value), an
   attacker cannot replay messages after this time.  Within this time

Notes:

Integrity check value (ICV) is the means of protection in this document.

RFC 7193, "The application/cms Media Type", April 2014

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 4033
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sean Leonard
Date Reported: 2014-07-02
Held for Document Update by: Kathleen Moriarty
Date Held: 2014-09-03

Section 1 says:

[RFC5751] registered the application/pkc7-mime media type.

It should say:

[RFC5751] registered the application/pkcs7-mime media type.

Notes:

The correct media type is application/pkcs7-mime.
The references are correct to PKCS#7 and the RFC that establishes the media type. This is clearly a typo, hence accepting the errata, but a change to editorial.

RFC 7208, "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", April 2014

Note: This RFC has been updated by RFC 7372, RFC 8553, RFC 8616

Source of RFC: spfbis (app)

Errata ID: 4001
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Jimmy Xu
Date Reported: 2014-05-27
Held for Document Update by: Pete Resnick
Date Held: 2014-06-04

Section A.4 says:

   example.com.           SPF  ( "v=spf1 "
                                 "-include:ip4._spf.%{d} "
                                 "-include:ptr._spf.%{d} "
                                 "+all" )
   ip4._spf.example.com.  SPF  "v=spf1 -ip4:192.0.2.0/24 +all"
   ptr._spf.example.com.  SPF  "v=spf1 -ptr +all"

It should say:

   example.com.           TXT  ( "v=spf1 "
                                 "-include:ip4._spf.%{d} "
                                 "-include:ptr._spf.%{d} "
                                 "+all" )
   ip4._spf.example.com.  TXT  "v=spf1 -ip4:192.0.2.0/24 +all"
   ptr._spf.example.com.  TXT  "v=spf1 -ptr +all"

Notes:

According to Section 14.1 and Appendix B, the use of DNS RR type SPF (99) has been removed from the protocol.

Errata ID: 4453
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Seymour J. Metz
Date Reported: 2015-08-24
Held for Document Update by: Barry Leiba
Date Held: 2015-08-24

Section 5.6. "ip4" says:

  ip4-cidr-length  = "/" ("0" / %x31-39 0*1DIGIT) ; value range 0-32
  ip6-cidr-length  = "/" ("0" / %x31-39 0*2DIGIT) ; value range 0-128

It should say:

  ip4-cidr-length  = "/" (DIGIT / 
                          %x31-%x32 DIGIT /
                          %x33 %x30-%x32) ; value range 0-32

  ip6-cidr-length  = "/" ("0" /
                          %31-%39 0*1DIGIT /
                          "1" %30-%31 DIGIT /
                          "12" %30-%38) ; value range 0-128

Notes:

As written the ABNF matches ranges 0-99 and 0-999, not the ranges in the comments.
Note: I coded the ABNF the way that I did to avoid leading zeros.

----- Verifier Notes -----
This isn't documenting an error: the ABNF was specified as it was intentionally, using the comments to restrict the range. I'm marking this "Held for Document Update" in case we ever revise this and want to consider making the ABNF pickier.

RFC 7230, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", June 2014

Note: This RFC has been obsoleted by RFC 9110, RFC 9112

Note: This RFC has been updated by RFC 8615

Source of RFC: httpbis (wit)

Errata ID: 4189
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Simon Schueppel
Date Reported: 2014-11-26
Held for Document Update by: Barry Leiba
Date Held: 2015-04-22

Section 3.2 says:

     field-name     = token
     field-value    = *( field-content / obs-fold )
     field-content  = field-vchar [ 1*( SP / HTAB ) field-vchar ]
     field-vchar    = VCHAR / obs-text

     obs-fold       = CRLF 1*( SP / HTAB )
                    ; obsolete line folding
                    ; see Section 3.2.4

It should say:

     field-name     = token
     field-value    = *( field-content / obs-fold )
     field-content  = field-vchar [ 1*( SP / HTAB / field-vchar )
                      field-vchar ]
     field-vchar    = VCHAR / obs-text

     obs-fold       = OWS CRLF 1*( SP / HTAB )
                    ; obsolete line folding
                    ; see Section 3.2.4

Notes:

the field-value rule given in Section 3.2 will not recognize several strings recognized by specific header rules.

Examples:
- ", , ," recognized by legacy list rule
- "abrowser/0.001 (C O M M E N T)" recognized by User-Agent rule
- "gzip , chunked" recognized by Transfer-Encoding rule
- etc.

General Problem:
the specified field-value rule does not allow single field-vchar surrounded by whitespace anywhere

Further Notes:
-what the authors propably wanted to say:
a string of octets is a field-value if, and only if:
-it is *( field-vchar / SP / HTAB / obs-fold )
-if it is not empty, it starts and ends with field-vchar

-the suggested correction was designed according to these criteria

--------------------- Notes from verifier ---------------------
This has been edited from the original report after discussion, but even this is not right. There's more here than can be reasonably fixed in an errata report, and the proper fix needs to be done in a revision of the document -- hence, "Held for Document Update". Note that this *is* a valid report, and that a fix is needed. The one above is the best approach for now, and a better fix will be developed in 7230bis.

Errata ID: 4683
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Daurnimator
Date Reported: 2016-05-04
Held for Document Update by: Alexey Melnikov
Date Held: 2016-05-05

Section 4 says:

It should say:

The name part of a transfer-parameter is case insensitive and MUST not
be "q" (as this would be ambiguous when used as part of the TE header).

Notes:

Nothing is said about how to handle transfer-parameters.
Notably, nothing is said about the case sensitivity of the parameter key.

This results in a conflict with the TE header: if you see a "q" token,
you cannot know if it is a transfer-parameter vs a t-ranking.

It *is* noted that the "q" token is case insensitive in section 4.3.
> When multiple transfer codings are acceptable, the client MAY rank
> the codings by preference using a case-insensitive "q" parameter


Alexey: as per Mark, this should be discussed in the HTTPBis WG.

Errata ID: 5163
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: David Matson
Date Reported: 2017-10-20
Held for Document Update by: Francesca Palombini
Date Held: 2021-08-23

Section 3.2.4 says:

A field value might be preceded and/or followed by optional
whitespace (OWS); a single SP preceding the field-value is preferred
for consistent readability by humans.  The field value does not
include any leading or trailing whitespace: OWS occurring before the
first non-whitespace octet of the field value or after the last
non-whitespace octet of the field value ought to be excluded by
parsers when extracting the field value from a header field.

It should say:

A field value might be preceded and/or followed by optional
whitespace (OWS); a single SP preceding the field-value is preferred
for consistent readability by humans.  The field value does not
include any leading or trailing whitespace: OWS occurring before the
first non-whitespace octet of the field value or after the last
non-whitespace octet of the field value ought to be excluded by
parsers when extracting the field value from a header field.

All optional whitespace between tokens in field-content has the same
semantics as SP. Any sequence of SP / HTAB that occurs between tokens
in field-content MAY be replaced with a single SP before interpreting
the field value or forwarding the message downstream.

Notes:

RFC 2616, section 2.2, contained the following text:

All linear white space, including folding, has the same semantics as SP. A recipient MAY replace any linear white space with a single SP before interpreting the field value or forwarding the message downstream.

Similarly, RFC 2616 section 4.2 contained the following text:
Any LWS that occurs between field-content MAY be replaced with a single SP before interpreting the field value or forwarding the message downstream.

In section A.2. Changes from RFC 2616, the document does not list any intended change for how space and tab are handled, but the current text does appear to constitute a change. I suspect the change is accidental due to rewording the document when line folding was made deprecated.

Note that in RFC 2616, LWS is defined as follows:
LWS = [CRLF] 1*( SP | HT )

In particular, the leading CRLF was optional.

Thus, the wording in RFC 2616 covered two cases:
1. LWS that includes line folding.
2. LWS that does not include line folding.

The current text does cover how to handle case #1 - former LWS that began with a CRLF; later in section 3.2.4 it requires rejecting or replacing with SP. (The old "MAY" language has effectively become a "MUST" for the leading CRLF case.)

However, the current text does not appear to address case #2 - former LWS that does not begin with a CRLF - in other words, SP and HTAB occurring between field-content. I suspect the intention is still that a recipient should treat such whitespace as insignificant, and may replace any sequence of SP and HTAB with a single SP before interpreting the field content, but I believe the text of the current RFC no longer provides this behavior.

(I have not read all of the specifications in full, so please accept my apologies if I have misread or missed a relevant portion elsewhere.)

Errata ID: 5257
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Erwin Pe
Date Reported: 2018-02-07
Held for Document Update by: Francesca Palombini
Date Held: 2021-08-23

Section 7 says:

For compatibility with legacy list rules, a recipient MUST parse and
ignore a reasonable number of empty list elements: enough to handle
common mistakes by senders that merge values, but not so much that
they could be used as a denial-of-service mechanism.  In other words,
a recipient MUST accept lists that satisfy the following syntax:

  #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]

  1#element => *( "," OWS ) element *( OWS "," [ OWS element ] )

It should say:

For compatibility with legacy list rules, a recipient MUST parse and
ignore a reasonable number of empty list elements: enough to handle
common mistakes by senders that merge values, but not so much that
they could be used as a denial-of-service mechanism.  In other words,
a recipient MUST accept lists that satisfy the following syntax:

  #element => [ ( ("," OWS element) / element ) *( OWS "," [ OWS 
    element ] ) ]

  1#element => *( "," OWS ) element *( OWS "," [ OWS element ] )

Notes:

With the current ABNF rule for #element, and using token as an element, the construction:

", foobar"

cannot be derived from #element, but can be derived from 1#element. (legacy list rule)
Since #element is meant to be a superset of 1#element, lists derived from 1#element should satisfy the #element rule as well.

Errata ID: 5964
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Rick van Rein
Date Reported: 2020-01-23
Held for Document Update by: Barry Leiba
Date Held: 2020-02-05

Section 2.7.1 says:

   The URI generic syntax for authority also includes a deprecated
   userinfo subcomponent ([RFC3986], Section 3.2.1) for including user
   authentication information in the URI.  Some implementations make use
   of the userinfo component for internal configuration of
   authentication information, such as within command invocation
   options, configuration files, or bookmark lists, even though such
   usage might expose a user identifier or password.  A sender MUST NOT
   generate the userinfo subcomponent (and its "@" delimiter) when an
   "http" URI reference is generated within a message as a request
   target or header field value.  Before making use of an "http" URI
   reference received from an untrusted source, a recipient SHOULD parse
   for userinfo and treat its presence as an error; it is likely being
   used to obscure the authority for the sake of phishing attacks.

It should say:

   The URI generic syntax for authority also includes a
   userinfo subcomponent in which the format "user:password" is deprecated
   ([RFC3986], Section 3.2.1).  The user is permitted, but the password
   is not.  Some implementations make use
   of the userinfo component for internal configuration of
   authentication information, such as within command invocation
   options, configuration files, or bookmark lists, even though such
   usage might expose a user identifier or password.  A sender MUST NOT
   generate a colon in a userinfo subcomponent when an
   "http" URI reference is generated within a message as a request
   target or header field value, but it may prefix a user and an "@" delimiter
   before the host name in an "http" URI.  Before making use of an "http" URI
   reference received from an untrusted source, a recipient SHOULD parse
   for userinfo and treat the presence of a colon in it as an error.

Notes:

RFC3986 does not forbid or even discourage the "user" in the userinfo subcomponent. It only says

Use of the format "user:password" in the userinfo field is
deprecated.

and continues to describe ":password" handling.

Obscuring the authority for the purposes of phishing is not mitigated by parsing the userinfo; subdomains in DNS offer similar notational flexibility. Parsing does help against misleading password popups.

The user is part of the authority section of the URI and its purpose is to zoom in on a scope for authoritative resource addressing. This syntax has in the past been (ab)used for Basic/Digest authentication details, which only works if visitor and visited resource happen to be the same user; it is this (ab)use that is now deprecated.

===========================
Verifier notes:
This is not really an erratum, as the document says exactly what it was intended to say when it was written. That said, the issue does need to be discussed as the document is updated, and an update is planned... so I'm marking it "Held for Document Update", rather than "Rejected".

Errata ID: 4779
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: William A. Rowe Jr.
Date Reported: 2016-08-18
Held for Document Update by: Alexey Melnikov
Date Held: 2016-10-07

Section A.2. says:

   [...] Non-US-ASCII content in header fields and the reason
   phrase has been obsoleted and made opaque (the TEXT rule was
   removed).  (Section 3.2.6)

It should say:

   [...] Non-US-ASCII content in header field values and the reason
   phrase has been obsoleted and made opaque (the TEXT rule was
   removed).  (Section 3.2.6)

Notes:

Section 3.2 plainly states header field names are token
(VCHARs less separators) as defined in 3.2.6.

The "header fields" identified in this footnote are neither
clear nor correct.

Alexey: While this is a clarification, the whole section is likely to be deleted when the document is revised.

Errata ID: 4891
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mike Bishop
Date Reported: 2016-12-16
Held for Document Update by: Alexey Melnikov
Date Held: 2017-02-23

Section 3.2.6 says:

qdtext         = HTAB / SP /%x21 / %x23-5B / %x5D-7E / obs-text

It should say:

qdtext         = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text

Notes:

Lack of space between the slash and the alternative makes it unclear that the slash isn't part of the next alternative.

Mark Nottingham: Not a bug, but certainly an improvement.

RFC 7231, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", June 2014

Note: This RFC has been obsoleted by RFC 9110

Source of RFC: httpbis (wit)

Errata ID: 4689
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Daurnimator
Date Reported: 2016-05-10
Held for Document Update by: Alexey Melnikov
Date Held: 2017-02-23

Section 3.1.1.2 says:

3.1.1.2.  Charset

   HTTP uses charset names to indicate or negotiate the character
   encoding scheme of a textual representation [RFC6365].  A charset is
   identified by a case-insensitive token.

     charset = token

   Charset names ought to be registered in the IANA "Character Sets"
   registry (<http://www.iana.org/assignments/character-sets>) according
   to the procedures defined in [RFC2978].

It should say:

3.1.1.2.  Charset

   HTTP uses charset names to indicate or negotiate the character
   encoding scheme of a textual representation [RFC6365].


     charset       = <mime-charset, see [RFC5987], Section 3.2.1>


   Charset names ought to be registered in the IANA "Character Sets"
   registry (<http://www.iana.org/assignments/character-sets>) according
   to the procedures defined in [RFC2978].

Notes:

The definition of charset from RFC 5987 is more strict and more correct.

Mark Nottingham: This is not an errata; it is a suggestion for a technical change in the document, and needs to be discussed by the working group.

Errata ID: 5541
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Danil Suits
Date Reported: 2018-11-02
Held for Document Update by: Alexey Melnikov
Date Held: 2019-03-20

Section 4.3.5 says:

If a DELETE
   request passes through a cache that has one or more stored responses
   for the effective request URI, those stored responses will be
   invalidated

It should say:

If a successful DELETE
   request passes through a cache that has one or more stored responses
   for the effective request URI, those stored responses will be
   invalidated

Notes:

RFC 7234 4.4 describes the semantics of cache invalidation for successful requests (non-error status code), but does not describe semantics for unsuccessful requests. The corrected text parallels the construction in section 4.3.4 ("If a successful PUT request...").

Mark Nottingham wrote:

I think HOLD FOR UPDATE; we can address this in the current http-core work.

Errata ID: 5806
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Anders Kaseorg
Date Reported: 2019-08-12
Held for Document Update by: Francesca Palombini
Date Held: 2021-08-23

Section 4.3.7 says:

A server MUST generate a Content-Length field with a value of "0" if no
payload body is to be sent in the response.

It should say:

If no payload body is to be sent in the response, a server MUST
generate a status code of 204 (No Content) or a Content-Length field
with a value of "0" (but not both).

Notes:

The original text contradicts RFC 7230 §3.3.2: “A server MUST NOT send a Content-Length header field in any response with a status code of 1xx (Informational) or 204 (No Content)”, unless the intention was to disallow all 204 responses to OPTIONS requests, which I assume it was not.

Errata ID: 4072
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Martin Thomson
Date Reported: 2014-08-06
Held for Document Update by: Barry Leiba
Date Held: 2014-08-06

Section TOC says:

ed 

Notes:

Three extraneous characters "ed " appear before the table of contents entry for 7.1.1.

Errata ID: 4436
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Aron Duby
Date Reported: 2015-08-06
Held for Document Update by: Barry Leiba
Date Held: 2015-08-07

Section 4.3.5 says:

If a DELETE method is successfully applied, the origin server SHOULD
send a 202 (Accepted) status code if the action will likely succeed
but has not yet been enacted, a 204 (No Content) status code if the
action has been enacted and no further information is to be supplied,
or a 200 (OK) status code if the action has been enacted and the
response message includes a representation describing the status.

It should say:

If a DELETE method is successfully applied, the origin server SHOULD
send a 202 (Accepted) status code if the action will likely succeed
but has not yet been enacted; a 204 (No Content) status code if the
action has been enacted and no further information is to be supplied;
or a 200 (OK) status code if the action has been enacted and the
response message includes a representation describing the status.

Notes:

Using a semicolon creates a stronger delineation of the different options. If you are just quickly trying to parse what status to return if the delete hasn't happened yet and you quickly read "has not yet been enacted, a 204 (No Content)" you could incorrectly read that as return a 204. The semicolon makes it more obvious that "enacted" is the end of that thought and to scan backwards where as the comma in this instance requires knowing the structure of the rest of the paragraph.

----- Verifier Notes -----
There's no reason to use semicolons to delimit this list, because the list items themselves don't contain commas. Still, the reporter's confusion is noted. Perhaps a bullet list would be better in this case:

-------
If a DELETE method is successfully applied, the origin server SHOULD
send

- a 202 (Accepted) status code if the action will likely succeed
but has not yet been enacted,

- a 204 (No Content) status code if the action has been enacted and
no further information is to be supplied, or

- a 200 (OK) status code if the action has been enacted and the
response message includes a representation describing the status.
-------

Errata ID: 4452
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Attila Gulyas
Date Reported: 2015-08-22
Held for Document Update by: Barry Leiba
Date Held: 2015-08-22

Section 6.4 says:

Automatic redirection needs to done with
   care for methods not known to be safe, as defined in Section 4.2.1,
   since the user might not wish to redirect an unsafe request.

It should say:

Automatic redirection needs to be done with
   care for methods not known to be safe, as defined in Section 4.2.1,
   since the user might not wish to redirect an unsafe request.

Notes:

A simple typo ("needs to _be_ done")

RFC 7233, "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", June 2014

Note: This RFC has been obsoleted by RFC 9110

Source of RFC: httpbis (wit)

Errata ID: 5620
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Armin Abfalterer
Date Reported: 2019-02-01
Held for Document Update by: Barry Leiba
Date Held: 2020-11-13

Section 4.2 says:

Content-Range       = byte-content-range
                    / other-content-range

other-content-range = other-range-unit SP other-range-resp
other-range-resp    = *CHAR

Notes:

Due to the loose definition of "other-content-range" invalid "byte content range" values are possible.

For example, following invalid header value is not valid according to "byte-content-range" (as "complete-length" or "*" is missing) but is yet allowed by "other-content-range".

Content-Range: bytes 42-1233/

The problem might be solved by excluding "bytes-unit" in "other-range-unit".

Errata ID: 4358
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tim
Date Reported: 2015-05-07
Held for Document Update by: Barry Leiba
Date Held: 2015-05-12

Section 4 says:

The 206 (Partial Content) status code indicates that the server is
successfully fulfilling a range request for the target resource by
transferring one or more parts of the selected representation that
correspond to the satisfiable ranges found in the request's Range
header field (Section 3.1).

It should say:

The 206 (Partial Content) status code indicates that the server is
successfully fulfilling a range request for the target resource by
transferring one or more parts of the selected representation that
correspond to the satisfiable ranges found in the request's Range
header field (Section 3.1). A response may chose to satisfy only
part of a requested range.

Notes:

Firefox and Chrome already behave as if the "Corrected Text"
statement is true.

It may be desirable if for example a user returns to a
html5 video with auto play, pauses the video and is only
interested in responding to a comment on the page. In this example
it would be unnecessarily costly to transfer the whole 128GB when
the user only consumes a few MB.

Alternative: maybe it should only be true if last-byte-pos is
absent.

----- Verifier Notes -----
The reporter is uncertain of the meaning and asks that it be clarified, one way or the other. A future update of the document might consider clarifying wording.

RFC 7234, "Hypertext Transfer Protocol (HTTP/1.1): Caching", June 2014

Note: This RFC has been obsoleted by RFC 9111

Source of RFC: httpbis (wit)

Errata ID: 6279
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Todd Greer
Date Reported: 2020-09-04
Held for Document Update by: Francesca Palombini
Date Held: 2021-04-29

Section 4.2.4 says:

A cache MUST NOT generate a stale response if it is prohibited by an
explicit in-protocol directive (e.g., by a "no-store" or "no-cache"
cache directive, a "must-revalidate" cache-response-directive, or an
applicable "s-maxage" or "proxy-revalidate" cache-response-directive;
see Section 5.2.2).

It should say:

A cache MUST NOT generate a stale response if it is prohibited by an
explicit in-protocol directive (e.g., by a "no-cache"
cache directive, a "must-revalidate" cache-response-directive, or an
applicable "s-maxage" or "proxy-revalidate" cache-response-directive;
see Section 5.2.2).

Notes:

The examples of directives that prohibit stale responses includes "no-store", but the definitions of "no-store" in 5.2.1.5 and 5.2.2.3 don't prohibit serving stale responses, and there is no other mention in RFC 7234 (or elsewhere) of "no-store" prohibiting serving stale responses.

If a "no-store" request directive is intended to prohibit serving stale responses, 5.2.1.5 should say so. (The question is meaningless for "no-store" response directives, since those should never be found in a cache.)

RFC 7252, "The Constrained Application Protocol (CoAP)", June 2014

Note: This RFC has been updated by RFC 7959, RFC 8613, RFC 8974, RFC 9175

Source of RFC: core (wit)

Errata ID: 4895
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Esko Dijk
Date Reported: 2016-12-23
Held for Document Update by: Francesca Palombini
Date Held: 2023-01-18

Section 6.4 says:

Note that these rules completely resolve any percent-encoding.

It should say:

Note that these rules completely resolve any percent-encoding. Also 
note that a trailing slash character in the <path> component represents
a separate, zero-character path segment (see [RFC3986] Section 3.3 
ABNF) and therefore it is encoded using a Uri-Path Option of zero
length.

Notes:

The current specification for decomposing a URI into CoAP Options (Section 6.4) is correct; however the text may still be unclear to implementers who may think that the phrase "not including the delimiting slash characters" means simply omitting a trailing slash character in the URI path. This is incorrect. See the discussion outcome in email thread https://www.ietf.org/mail-archive/web/core/current/msg08223.html . Therefore, a minor clarification is proposed in the notes after the parsing steps.

RFC 7282, "On Consensus and Humming in the IETF", June 2014

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 5321
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dave Thaler
Date Reported: 2018-04-10
Held for Document Update by: Benjamin Kaduk
Date Held: 2018-04-10

Section 3 says:

A valid justification needs to me made.

It should say:

A valid justification needs to be made.

Notes:

Typo: "me" should be "be"

RFC 7296, "Internet Key Exchange Protocol Version 2 (IKEv2)", October 2014

Note: This RFC has been updated by RFC 7427, RFC 7670, RFC 8247, RFC 8983, RFC 9370

Source of RFC: ipsecme (sec)

Errata ID: 5056
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Taylor
Date Reported: 2017-06-29
Held for Document Update by: Paul Wouters
Date Held: 2022-04-11

Section 1.7 says:

   This document removes discussion of the INTERNAL_ADDRESS_EXPIRY
   configuration attribute because its implementation was very
   problematic.  Implementations that conform to this document MUST
   ignore proposals that have configuration attribute type 5, the old
   value for INTERNAL_ADDRESS_EXPIRY 

It should say:

Unclear what it should be

Notes:

Configuration attribute 5, INTERNAL_ADDRESS_EXPIRY, is a type of attribute in a configuration payload. It is not an attribute in a proposal. As documented in Section 2.7 proposals are part of an SA payload.

An SA payload consists of one or more proposals. Each proposal
includes one protocol. Each protocol contains one or more transforms
-- each specifying a cryptographic algorithm. Each transform
contains zero or more attributes (attributes are needed only if the
Transform ID does not completely specify the cryptographic
algorithm).

So the correct behavior when one receives a *configuration* payload with INTERNAL_ADDRESS_EXPIRY cannot be to ignore a proposal. Was the intent to say that the configuration payload should be ignored? Was the intent to say that the configuration payload should be processed but the INTERNAL_ADDRESS_EXPIRY attribute ignored? Clearly these choices would result in radically different outcomes for the negotiation.

Paul Wouters:

This comment is about the use of the word "proposal" which I agree is open to wrong interpretation. My suggestion would be:

Current:

Implementations that conform to this document MUST
ignore proposals that have configuration attribute type 5, the old
value for INTERNAL_ADDRESS_EXPIRY

Proposed:

Implementations that conform to this document MUST
process configuration attribute value 5 similar to
any other unknown Attribute Type.

It is mostly obvious that only the attribute type should be ignored, not the entire proposal. Therefor Held for Document update as it does not affect implementations but the wording should be improved in future versions of the document

Errata ID: 4387
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yoav Nir
Date Reported: 2015-06-04
Held for Document Update by: Stephen Farrell
Date Held: 2015-06-04

Section 3.7 says:

   The Certificate Request payload, denoted CERTREQ in this document,
   provides a means to request preferred certificates via IKE and can
   appear in the IKE_INIT_SA response and/or the IKE_AUTH request.
   Certificate Request payloads MAY be included in an exchange when the
   sender needs to get the certificate of the receiver.

It should say:

   The Certificate Request payload, denoted CERTREQ in this document,
   provides a means to request preferred certificates via IKE and can
   appear in the IKE_SA_INIT response and/or the IKE_AUTH request.
   Certificate Request payloads MAY be included in an exchange when the
   sender needs to get the certificate of the receiver.

Notes:

IKE_SA_INIT is mis-spelled as IKE_INIT_SA this one time.

Errata ID: 5247
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Andrew Cagney
Date Reported: 2018-01-30
Held for Document Update by: Paul Wouters
Date Held: 2022-04-11

Section 3.10. says:

   o  Protocol ID (1 octet) - If this notification concerns an existing
      SA whose SPI is given in the SPI field, this field indicates the
      type of that SA.  For notifications concerning Child SAs, this
      field MUST contain either (2) to indicate AH or (3) to indicate
      ESP.  Of the notifications defined in this document, the SPI is
      included only with INVALID_SELECTORS, REKEY_SA, and
      CHILD_SA_NOT_FOUND.  If the SPI field is empty, this field MUST be
      sent as zero and MUST be ignored on receipt.

It should say:

   o  Protocol ID (1 octet) - If this notification concerns an existing
      SA whose SPI is given in the SPI field, this field indicates the
      type of that SA.  For notifications concerning Child SAs, this
      field MUST contain either (2) to indicate AH or (3) to indicate
      ESP.  Of the notifications defined in this document, the SPI is
      included only with INVALID_SELECTORS, REKEY_SA, and
      CHILD_SA_NOT_FOUND.  If the SPI field is empty, this field MUST be
      sent as zero to indicate NONE and MUST be ignored on receipt.

Notes:

If I assume that the 'Protocol ID' field in the notification payload is specified by:

Internet Key Exchange Version 2 (IKEv2) Parameters
IKEv2 Security Protocol Identifiers

then a notification is using the 'Reserved' value 0. Since the value is being used,
I think it would be better to give it a name. Other uses of 'Protocol ID' don't need
updating as they all explicitly list allowed values, and in no case is 0 allowed.

Paul Wouters:

This is about name for Protocol ID 0 to be seen as "NONE", versus giving it a better name. While I agree with the poster the writing could be improved, this change is not required for implementing the RFC. Thus moved to Held for Document Update where this text can then be improved upon.

Errata ID: 6779
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: warren.wang
Date Reported: 2021-12-08
Held for Document Update by: Benjamin Kaduk
Date Held: 2021-12-11

Section 1.1.1 says:

   In this scenario, neither endpoint of the IP connection implements
   IPsec, but network nodes between them protect traffic for part of the
   way.  Protection is transparent to the endpoints, and depends on
   ordinary routing to send packets through the tunnel endpoints for
   processing.  Each endpoint would announce the set of addresses
   "behind" it, and packets would be sent in tunnel mode where the inner
   IP header would contain the IP addresses of the actual endpoints.

It should say:

   In this scenario, neither endpoint of the IP connection implements
   IPsec, but network nodes between them protect traffic for part of the
   way.  Protection is transparent to the endpoints, and depends on
   ordinary routing to send packets through the tunnel endpoints for
   processing.  Each tunnel endpoint would announce the set of addresses
   "behind" it, and packets would be sent in tunnel mode where the inner
   IP header would contain the IP addresses of the actual endpoints.

Notes:

"Each tunnel endpoint" will make it easy to understand which entity is announcing the set of addresses.

RFC 7307, "LDP Extensions for Multi-Topology", July 2014

Source of RFC: mpls (rtg)

Errata ID: 5145
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sandra Murphy
Date Reported: 2017-10-05
Held for Document Update by: Deborah Brungard
Date Held: 2021-02-26

Section 4.3.2 says:

   The format of this sub-TLV is similar to the LDP IPv4 FEC sub-TLV as
   defined in [RFC4379].  In addition to "IPv4 prefix" and "Prefix
   Length" fields, this new sub-TLV also specifies the MT-ID (Multi-
   Topology ID).  The Length for this sub-TLV is 5.

It should say:

   The format of the MT LDP IPv4 prefix sub-TLV (type 31) is similar to
   the LDP IPv4 prefix sub-TLV (type 1) as defined in [RFC4379].  In
   addition to the "IPv4 prefix" and "Prefix Length" fields already
   defined in the LDP IPv4 prefix sub-TLV, the new MT LDP IPv4 prefix
   sub-TLV also specifies the MT-ID (Multi-Topology ID) field.  While
   the length of the LDP IPv4 prefix sub-TLV is 5 (and does not include
   the trailing MBZ bytes), the length of this new MT LDP IPv6 prefix 
   sub-TLV is 8 (and does include the internal MBZ byte).

Notes:

The original text uses "this sub-TLV" in ways that can be ambiguous. In particular, the final sentence "The Length for this sub-TLV is 5." is incorrect if "this sub-TLV" refers to the topic of the section, i.e., "MT LDP IPv4 FEC Sub-TLV", but is correct if "this sub-TLV" refers to the LDP IPv4 prefix sub-TLV defined in RFC4379/RFC8029. The revised text is suggested to remove the ambiguities. Adrian Farrell provided the bulk of the suggested revisions.

In addition, the sub-TLV names are changed to match the names that were registered in the IANA registry, to aid those trying to find the registry entries.

Errata ID: 5146
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sandra Murphy
Date Reported: 2017-10-05
Held for Document Update by: Deborah Brungard
Date Held: 2021-02-26

Section 4.3.3 says:

   The format of this sub-TLV is similar to the LDP IPv6 FEC sub-TLV as
   defined in [RFC4379].  In addition to the "IPv6 prefix" and "Prefix
   Length" fields, this new sub-TLV also specifies the MT-ID (Multi-
   Topology ID).  The Length for this sub-TLV is 17.

It should say:

   The format of the MT LDP IPv6 prefix sub-TLV (type 32) is similar to
   the LDP IPv6 prefix sub-TLV (type 2) as defined in [RFC4379].  In
   addition to the "IPv6 prefix" and "Prefix Length" fields already
   defined in the LDP IPv6 prefix sub-TLV, the new MT LDP IPv6 prefix 
   sub-TLV also specifies the MT-ID (Multi-Topology ID) field.  While
   the length of the LDP IPv6 prefix sub-TLV is 17 (and does not include
   the trailing MBZ bytes), the length of this new MT LDP IPv6 prefix
   sub-TLV is 20 (and does include the internal MBZ byte).

Notes:

The original text uses "this sub-TLV" in ways that can be ambiguous. In particular, the final sentence "The Length for this sub-TLV is 17.” is incorrect if "this sub-TLV" refers to the topic of the section, i.e., "MT LDP IPv6 FEC Sub-TLV", but is correct if "this sub-TLV" refers to the LDP IPv6 prefix sub-TLV defined in RFC4379/RFC8029. The revised text is suggested to remove the ambiguities. Adrian Farrell provided the bulk of the suggested revisions.

In addition, the sub-TLV names are changed to match the names that were registered in the IANA registry, to aid those trying to find the registry entries.

RFC 7317, "A YANG Data Model for System Management", August 2014

Source of RFC: netmod (ops)

Errata ID: 6245
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maurizio Brigandi'
Date Reported: 2020-07-29
Held for Document Update by: Rob Wilton
Date Held: 2023-10-02

Section 6 says:

         leaf-list user-authentication-order {
           type identityref {
             base authentication-method;
           }
           must '(. != "sys:radius" or ../../radius/server)' 

It should say:

         leaf-list user-authentication-order {
           type identityref {
             base authentication-method;
           }
           must '(not(. = "sys:radius") or ../../radius/server)'
 

Notes:

As indicated in https://www.w3.org/TR/1999/REC-xpath-19991116/#booleans

the following expression comparing a node-set with a string

. != "sys:radius"

is true if at least one node in the node-set satisfies the boolean expression.

This is not the intention of the "must" condition.

It is necessary to use not(. = "sys:radius") to achieve the right intention of the check.

This errata has been marked as "Held for Document Update" because it requires a new revision of the YANG module to be published, and hence a new RFC.

RFC 7322, "RFC Style Guide", September 2014

Note: This RFC has been updated by RFC 7997

Source of RFC: IAB

Errata ID: 5076
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: John Klensin
Date Reported: 2017-08-02
Held for Document Update by: Robert Sparks
Date Held: 2017-08-09

Section 4.3 says:

Every RFC must have an Abstract that provides a concise and 
comprehensive overview ...
[...]
Similarly, the Abstract should be complete in itself.  It will appear
in isolation in publication announcements and in the online index 
of RFCs. Therefore, the Abstract must not contain citations.

It should say:

   (Because this document is already being revised and there are 
   more fundamental issues involved than simple textual changes,
   the optimal fix for these issues should be left to the 
   discretion of the RFC Editor.)

Notes:

While the intent seems to me to be clear, this subsection can be read to contradict both other "preferences" and that intent. For example, "comprehensive", when taken out of the context of the text that follows (as it appears to have recently been taken by an AD acting in official capacity [1] [2]) can be used to insist that the abstract contain copies of extracts of almost any part of a well-written document, thereby defeating the purpose of an abstract and violating the RFC Editor's historical "no more than 13 lines" guidance (which does not appear in this RFC).

In addition, the prohibition on citations has often been taken as a prohibition on explicit citation anchors. But, if the intent is to be sure that abstracts are self-contained, any mention of another document by reference, without context appropriate to abstracts explaining what they document is about, is a citation. For example, the statement (from the abstract of this document) 'This document obsoletes RFC 2223, "Instructions to RFC Authors"' is plausible in an abstract because it is clear to the reader what RFC 2223 is about although one could reasonably argue for different presentation. By contract, a statement such as "This document obsoletes RFC 4637" should not be acceptable because it not only contains a citation (even if the explicit anchor is absent) but has no actual meaning unless the number is very well-known (i.e., meets criteria roughly equivalent to those for common abbreviations in section 3.6) or the reader tracks the citation down, violating the "complete in itself" principle. If readers of this submission do not immediately recognize "4637" and associate it with important other issues, Q.E.D.

I note that prohibitions of statements like "This document obsoletes RFC 4637" or "This document makes RFC 7 Historic" appear to contradict popular interpretations of an IESG statement [3]. That further suggests that either this subsection is in need of further clarification or that the RFC Editor and IESG have some sorting out to do.

-----
[1] https://www.ietf.org/mail-archive/web/urn/current/msg03783.html
[2] https://www.ietf.org/mail-archive/web/urn/current/msg03784.html
[3] https://www.ietf.org/iesg/statement/designating-rfcs-as-historic-2011-06-27.html

Errata ID: 6347
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Carsten Bormann
Date Reported: 2020-12-01
Held for Document Update by: Mirja Kühlewind (IAB chair)
Date Held: 2020-12-14

Section 4.8.6.5 says:

   The following format is required when a reference to an erratum
   report is necessary:

      [ErrNumber]  RFC Errata, Erratum ID number, RFC number.

      [Err1912]  RFC Errata, Erratum ID 1912, RFC 2978.

It should say:

   The following format is required when a reference to an errata
   report is necessary:

      [ErrNumber]  RFC Errata Report, EID number, RFC number.

      [Err1912]  RFC Errata Report, EID 1912, RFC 2978.

Notes:

Errata reports are not errata. Errata are in the original text. Errata reports are reports that indicate the reporter believes to have detected errata; there may be no actual errata, or there may actually be multiple errata touched in one report. As is, the reference is misleading.

However, this hasn't lead to confusion so far and many published RFCs use the current format. As such this is noted as held for document update

RFC 7323, "TCP Extensions for High Performance", September 2014

Source of RFC: tcpm (wit)

Errata ID: 5585
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marco Caspers
Date Reported: 2018-12-27
Held for Document Update by: Mirja Kühlewind
Date Held: 2019-03-18

Section 2.2 says:

2.2.  Window Scale Option

   The three-byte Window Scale option MAY be sent in a <SYN> segment by
   a TCP.  It has two purposes: (1) indicate that the TCP is prepared to
   both send and receive window scaling, and (2) communicate the
   exponent of a scale factor to be applied to its receive window.
   Thus, a TCP that is prepared to scale windows SHOULD send the option,
   even if its own scale factor is 1 and the exponent 0.  The scale
   factor is limited to a power of two and encoded logarithmically, so
   it may be implemented by binary shift operations.  The maximum scale
   exponent is limited to 14 for a maximum permissible receive window
   size of 1 GiB (2^(14+16)).

It should say:

2.2.  Window Scale Option

   The three-byte Window Scale option MAY be sent in a <SYN> segment by
   a TCP.  It has two purposes: (1) indicate that the TCP is prepared to
   both send and receive window scaling, and (2) communicate the
   exponent of a scale factor to be applied to its receive window.
   Thus, a TCP that is prepared to scale windows SHOULD send the option,
   even if its own scale factor is 1 and the exponent 0.  The scale
   factor is limited to a power of two and encoded logarithmically, so
   it may be implemented by binary shift operations.  The maximum scale
   exponent is limited to 14 for a maximum permissible receive window
   size of approximately 1 GiB ((2^30-1) - (2^14-1)).

Notes:

Left shift inserts zero's on the right hand side so the maximum window size is actually 16KiB shy of 1 GiB. The exact calculation would be ((2^30-1) - (2^14-1)). As it is stated as "approximately 1 GiB" the text is not incorrect but it would be good to provide the complete calculation in a document update to avoid invalid implementations.

RFC 7331, "Bidirectional Forwarding Detection (BFD) Management Information Base", August 2014

Source of RFC: bfd (rtg)

Errata ID: 4441
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Rui Lin
Date Reported: 2015-08-09
Held for Document Update by: Alvaro Retana
Date Held: 2015-08-11

Section 4.5 says:

Given bfdSessInterface, bfdSessSrcAddrType, bfdSessSrcAddr,
bfdSessDstAddrType, and bfdSessSrcAddrType, the BFD Session IP
Mapping Table maps to an associated BFD session found in the
bfdSessionTable.

It should say:

Given bfdSessInterface, bfdSessSrcAddrType, bfdSessSrcAddr,
bfdSessDstAddrType, and bfdSessDstAddr, the BFD Session IP
Mapping Table maps to an associated BFD session found in the
bfdSessionTable.

Notes:

Duplicate bfdSessSrcAddrType but missing bfdSessDstAddr

(Alvaro Retana): the MIB Module itself has the correct description.

RFC 7401, "Host Identity Protocol Version 2 (HIPv2)", April 2015

Note: This RFC has been updated by RFC 8002, RFC 9374

Source of RFC: hip (int)

Errata ID: 6653
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2021-08-03
Held for Document Update by: Eric Vyncke
Date Held: 2021-08-05

Section 5.2 says:

   | TRANSPORT_FORMAT_LIST  | 2049  | Ordered   | variable             |
   |                        |       | list of   |                      |
   |                        |       | preferred |                      |
   |                        |       | HIP       |                      |
   |                        |       | transport |                      |
   |                        |       | type      |                      |
   |                        |       | numbers   |                      |
   |                        |       |           |                      |

It should say:

   | TRANSPORT_FORMAT_LIST  | 2049  |  variable | Ordered              |
   |                        |       |           | list of              |
   |                        |       |           | preferred            |
   |                        |       |           | HIP                  |
   |                        |       |           | transport            |
   |                        |       |           | type                 |
   |                        |       |           | numbers              |
   |                        |       |           |                      |

Notes:

The values in the columns are swapped.

--- Verifier note ---
The erratum has been verified by Tom Henderson (co-author) https://mailarchive.ietf.org/arch/msg/hipsec/aJSEhRNShc3vXcbtlbd8V39Bfow/

As it does not prevent implementation, the erratum status is "help for document update"

RFC 7407, "A YANG Data Model for SNMP Configuration", December 2014

Source of RFC: netmod (ops)

Errata ID: 5886
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin Björklund
Date Reported: 2019-10-29
Held for Document Update by: Ignas Bagdonas
Date Held: 2019-11-18

Section 4.1 says:

        leaf fingerprint {
           type x509c2n:tls-fingerprint;
           mandatory true;
           description
             "Specifies a value with which the fingerprint of the
              full certificate presented by the peer is compared.  If
              the fingerprint of the full certificate presented by the
              peer does not match the fingerprint configured, then the
              entry is skipped, and the search for a match continues.";

It should say:

        leaf fingerprint {
           type x509c2n:tls-fingerprint;
           mandatory true;
           description
             "Specifies a value with which the certificate presented by
              the peer is compared, according to the algorithm defined 
	      in the description of the list node 'cert-to-name'.";

Notes:

The quoted text is not consistent with the algorithm described in the list 'cert-to-name'. Better to simply refer to the cert-to-name description. The algorithm described in 'cert-to-name' works in the same way as described in the referenced RFC 6353, which makes it clear that this is the intended behaviour.

RFC 7408, "Forwarding and Control Element Separation (ForCES) Model Extension", November 2014

Source of RFC: forces (rtg)

Errata ID: 5662
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2019-03-17
Held for Document Update by: Alvaro Retana
Date Held: 2020-07-21

Section 3 (page 20) says:

               <!-- Extension RFC 7408 -->
               <xsd:attribute name="access" use="optional"
                  default="read-write">
                  <xsd:simpleType>
                     <xsd:list itemType="accessModeType"/>
                  </xsd:simpleType>
               </xsd:attribute>
               <!-- Extension RFC 7408 -->

It should say:

               <!-- Extension RFC 7408 -->
               <xsd:attribute name="access" use="optional"
                  default="read-write">
                  <xsd:simpleType>
                     <xsd:list itemType="accessModeType"/>
                  </xsd:simpleType>
               </xsd:attribute>
               <!-- /Extension RFC 7408 -->

Notes:

¨/¨ missing.

RFC 7426, "Software-Defined Networking (SDN): Layers and Architecture Terminology", January 2015

Source of RFC: IRTF

Errata ID: 5302
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2018-03-25
Held for Document Update by: Colin Perkins
Date Held: 2019-04-04

Section 7 says:

   [REST]        Fielding, Roy, "Chapter 5: Representational State
                 Transfer (REST)", in Disseration "Architectural Styles
                 and the Design of Network-based Software
                 Architectures", 2000.

It should say:

   [REST]        Fielding, Roy, "Chapter 5: Representational State
                 Transfer (REST)", in Dissertation "Architectural Styles
                 and the Design of Network-based Software
                 Architectures", 2000.

Notes:

Typo (t letter missing).

RFC 7432, "BGP MPLS-Based Ethernet VPN", February 2015

Note: This RFC has been updated by RFC 8584, RFC 9161

Source of RFC: l2vpn (rtg)

Errata ID: 4428
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Wenhu Lu
Date Reported: 2015-07-27
Held for Document Update by: Alvaro Retana
Date Held: 2015-07-27

Section TOC says:

Route Distinguisher Assignment per EVI

It should say:

Route Distinguisher Assignment per MAC-VRF

Notes:

In the Table of Contents, the line for section 7.9. is incorrect and does not reflect the actual section title on page 18.

Errata ID: 5718
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kazuhiko Mino
Date Reported: 2019-05-03
Held for Document Update by: Martin Vigoureux
Date Held: 2019-06-17

Section 5 says:

5.  Ethernet Segment
   - Type 4 (T=0x04)
     + Local Discriminator value (4 octets).  The Local Discriminator
       value MUST be encoded in the 4 octets next to the IP address.

It should say:

     + Local Discriminator value (4 octets).  The Local Discriminator
       value MUST be encoded in the 4 octets next to the Router ID.

Notes:

Since the field before that is defined as "Router ID", the notation of "IP address" is not correct.

Errata ID: 6286
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Luc Andre Burdet
Date Reported: 2020-09-11
Held for Document Update by: Alvaro Retana
Date Held: 2020-09-11

Section 8.3 says:

   route.  As described in Section 8.1.1, the route MUST carry an ESI
   Label extended community with a valid ESI label.  The disposition PE

It should say:

   route.  As described in Section 8.2.1, the route MUST carry an ESI
   Label extended community with a valid ESI label.  The disposition PE

Notes:

8.1.1 is ES route construction, 8.2.1 is the correct cross-ref for ES/EAD route construction.

RFC 7463, "Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR)", March 2015

Source of RFC: bliss (rai)

Errata ID: 4915
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Brett Tate
Date Reported: 2017-01-23
Held for Document Update by: Ben Campbell
Date Held: 2017-01-24

Throughout the document, when it says:

   To: <sips:alice@example.com>;tag=428765950880801

It should say:

   To: <sips:alice@example.com>

Notes:

PUBLISH must not contain To tag unless sending within dialog. The To tag (428765950880801) appears to be extraneous within the following SIP messages since there is no explanation about which dialog is being shared: section 11.7 F32, section 11.9 F32, section 11.10 F22, and section 11.14 F48. The To/From URI values within section 11.7 F32 also should be swapped since it does not appear to be intentional and is different than the other examples indicating To tag value 428765950880801.

Section 11.4 F2 also has To tag issues since a To tag must be present to comply with RFC 3261. Section 11.6 F28 also should not be missing a To tag.

RFC 7489, "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", March 2015

Note: This RFC has been updated by RFC 8553, RFC 8616

Source of RFC: INDEPENDENT

Errata ID: 6485
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Kaspar Etter
Date Reported: 2021-03-15
Held for Document Update by: Eliot Lear (ISE)
Date Held: 2022-10-01

Section 7.2.1.1. says:

     dmarc-subject = %x52.65.70.6f.72.74 1*FWS       ; "Report"
                     %x44.6f.6d.61.69.6e.3a 1*FWS    ; "Domain:"
                     domain-name 1*FWS               ; from RFC 6376
                     %x53.75.62.6d.69.74.74.65.72.3a ; "Submitter:"
                     1*FWS domain-name 1*FWS
                     %x52.65.70.6f.72.74.2d.49.44.3a ; "Report-ID:"
                     msg-id                          ; from RFC 5322

It should say:

     dmarc-subject = %x52.65.70.6f.72.74 1*FWS       ; "Report"
                     %x44.6f.6d.61.69.6e.3a 1*FWS    ; "Domain:"
                     domain-name 1*FWS               ; from RFC 6376
                     %x53.75.62.6d.69.74.74.65.72.3a ; "Submitter:"
                     1*FWS domain-name 1*FWS
                     %x52.65.70.6f.72.74.2d.49.44.3a ; "Report-ID:"
                     1*FWS %x3c dot-atom-text %x3e   ; from RFC 5322

Notes:

According to RFC 5322, msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS]. The example given in Section 7.2.1.1. (<2002.02.15.1>) does not adhere to this and neither do reports in the wild. Instead of referring to the msg-id ABNF, I suggest that we refer to the dot-atom-text ABNF and include "<" and ">" as ASCII characters. This also has the advantage of getting rid of CFWS. According to RFC 5322, "comments may be included in structured field bodies" but "Subject" is not a structured header field.

Errata ID: 7835
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Giuseppe Trotta
Date Reported: 2024-03-04
Held for Document Update by: Eliot Lear
Date Held: 2024-03-11

Section 6.6.3 says:

   2.  Records that do not start with a "v=" tag that identifies the
       current version of DMARC are discarded.

   3.  If the set is now empty, the Mail Receiver MUST query the DNS for
       a DMARC TXT record at the DNS domain matching the Organizational
       Domain in place of the RFC5322.From domain in the message (if
       different).  This record can contain policy to be asserted for
       subdomains of the Organizational Domain.  A possibly empty set of
       records is returned.

   4.  Records that do not start with a "v=" tag that identifies the
       current version of DMARC are discarded.

It should say:

   2.  Records that do not start with a "v=" tag that identifies the
       current version of DMARC are discarded.

   3.  If the set is now empty, the Mail Receiver MUST query the DNS for
       a DMARC TXT record at the DNS domain matching the Organizational
       Domain in place of the RFC5322.From domain in the message (if
       different).  This record can contain policy to be asserted for
       subdomains of the Organizational Domain.  A possibly empty set of
       records is returned.

Notes:

The intent of the original text is that indeed step 2 should be repeated as follows:
(1) Go get a set of things.
(2) Filter them.
(3) If the set is now empty, go get a set of things from a different location.
(4) Filter them.

At the time of this writing, draft-ietf-dmarc-dmarcbis is being developed, and so that text may clarify this point. As such we will hold this erratum for update.

Errata ID: 5151
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Clara Nees
Date Reported: 2017-10-10
Held for Document Update by: Adrian Farrel
Date Held: 2018-04-08

Section 1 says:

However, there has been no single widely
accepted or publicly available mechanism to communication of
domain-specific message-handling policies for receivers, or to
request reporting of authentication and disposition of received mail.

It should say:

However, there has been no single widely
accepted or publicly available mechanism to communicate
domain-specific message-handling policies to receivers, or to
request reporting of authentication and disposition of received mail.

Notes:

"Mechanism to communication of [...] policies for receivers" should instead read,
"Mechanism to COMMUNICATE [...] policies TO receivers.

Errata ID: 5774
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Freddie Leeman
Date Reported: 2019-07-03
Held for Document Update by: Adrian Farrel
Date Held: 2021-06-01

Section Appendix C says:

       <!-- The DMARC disposition applying to matching
            messages. -->
       <xs:element name="policy_evaluated"
                   type="PolicyEvaluatedType"
                   minOccurs="1"/>

       <!-- The RFC5321.MailFrom domain. -->
       <xs:element name="envelope_from" type="xs:string"
                   minOccurs="1"/>

       <!-- The RFC5322.From domain. -->
       <xs:element name="header_from" type="xs:string"
                   minOccurs="1"/>

       <!-- The "d=" parameter in the signature. -->
       <xs:element name="domain" type="xs:string"
                   minOccurs="1"/>

       <!-- The DKIM verification result. -->
       <xs:element name="result" type="DKIMResultType"
                   minOccurs="1"/>

       <!-- The checked domain. -->
       <xs:element name="domain" type="xs:string" minOccurs="1"/>

       <!-- The scope of the checked domain. -->
       <xs:element name="scope" type="SPFDomainScope" minOccurs="1"/>

       <!-- The SPF verification result. -->
       <xs:element name="result" type="SPFResultType"
                   minOccurs="1"/>

       <!-- There will always be at least one SPF result. -->
       <xs:element name="spf" type="SPFAuthResultType" minOccurs="1"
                   maxOccurs="unbounded"/>

It should say:

       <!-- The DMARC disposition applying to matching
            messages. -->
       <xs:element name="policy_evaluated"
                   type="PolicyEvaluatedType"/>

       <!-- The RFC5321.MailFrom domain. -->
       <xs:element name="envelope_from" type="xs:string"/>

       <!-- The RFC5322.From domain. -->
       <xs:element name="header_from" type="xs:string"/>

       <!-- The "d=" parameter in the signature. -->
       <xs:element name="domain" type="xs:string"/>

       <!-- The DKIM verification result. -->
       <xs:element name="result" type="DKIMResultType"/>

       <!-- The checked domain. -->
       <xs:element name="domain" type="xs:string"/>

       <!-- The scope of the checked domain. -->
       <xs:element name="scope" type="SPFDomainScope"/>

       <!-- The SPF verification result. -->
       <xs:element name="result" type="SPFResultType"/>

       <!-- There will always be at least one SPF result. -->
       <xs:element name="spf" type="SPFAuthResultType"
                   maxOccurs="unbounded"/>

Notes:

Removed all minOccurs="1" from the DMARC XML Schema since the NOTE at the beginning of the appendix already states that 'unless otherwise specified, the minOccurs and maxOccurs values for each element are set to 1'. These (9) unnecessary specifications of minOccurs can cause confusion and lead to incorrect implementations.

While this report is technically correct, it is hard to see that the text as currently present is harmful or confusing. This is left for an update if/when the document is revised.

RFC 7498, "Problem Statement for Service Function Chaining", April 2015

Source of RFC: sfc (rtg)

Errata ID: 4527
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Igor Duarte Cardoso
Date Reported: 2015-11-09
Held for Document Update by: Alia Atlas
Date Held: 2015-11-11

Section 4 says:

Although this problem statement does not introduce any protocols,
   when considering service function chaining, the three main areas
   begin investigated (see Section 3) by the WG have security aspects
   that warrant consideration.

It should say:

Although this problem statement does not introduce any protocols,
   when considering service function chaining, the three main areas
   being investigated (see Section 3) by the WG have security aspects
   that warrant consideration.

Notes:

"begin" replaced by "being", it seems to have been a missed typo.

RFC 7539, "ChaCha20 and Poly1305 for IETF Protocols", May 2015

Note: This RFC has been obsoleted by RFC 8439

Source of RFC: IRTF

Errata ID: 4372
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Adam Eijdenberg
Date Reported: 2015-05-21
Held for Document Update by: Lars Eggert
Date Held: 2015-06-03

Section 2.5.1 says:

accumulator = 0

It should say:

a = 0

Notes:

This variable goes by both "accumulator" and "a" in the pseudo-code. Renaming this line allows the pseudo-code to pseudo-compile.

Errata ID: 4373
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Adam Eijdenberg
Date Reported: 2015-05-21
Held for Document Update by: Lars Eggert
Date Held: 2015-06-03

Section 2.5.1 says:

s = le_num(key[16..31])

It should say:

s = le_bytes_to_num(key[16..31])

Notes:

Other usages in the same pseudo-code example call the function le_bytes_to_num to perform what appears to be the same task.

Errata ID: 4434
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lukasz Stelmach
Date Reported: 2015-08-05
Held for Document Update by: Lars Eggert
Date Held: 2015-08-06

Section 2.6 says:

We take
the first 256 bits or the serialized state, and use those as the one-
time Poly1305 key: the first 128 bits are clamped and form "r", while
the next 128 bits become "s".

It should say:

We take
the first 256 bits of the serialized state, and use those as the one-
time Poly1305 key: the first 128 bits are clamped and form "r", while
the next 128 bits become "s".

Notes:

“We take the first 256 **or** the serialized state”. Should be **of**.

RFC 7540, "Hypertext Transfer Protocol Version 2 (HTTP/2)", May 2015

Note: This RFC has been obsoleted by RFC 9113

Note: This RFC has been updated by RFC 8740

Source of RFC: httpbis (wit)

Errata ID: 4535
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Erik Schnell
Date Reported: 2015-11-17
Held for Document Update by: Barry Leiba
Date Held: 2015-11-19

Section 5.1 says:

(content of Figure 2)

It should say:

(see notes, below)

Notes:

Section 5.1 Figure 2 is unclear about what stream is being depicted when PUSH_PROMISE is used. The figure shows a transition from /idle/ to /reserved (local)/ on a PUSH_PROMISE receive, but Section 6.6 only allows PUSH_PROMISE to be sent on a stream that is in /open/ or /half-closed (remote)/ state. But these are talking about different streams.

A note should be added to figure 2 in section 5.1 clarifying that where a PUSH_PROMISE is sent or received, the state diagram is for the promised stream, not the original stream.

Errata ID: 4666
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Vasiliy Faronov
Date Reported: 2016-04-13
Held for Document Update by: Alexey Melnikov
Date Held: 2017-02-23

Section 9.1.2 says:

   A 421 response is cacheable by default, i.e., unless otherwise
   indicated by the method definition or explicit cache controls (see
   Section 4.2.2 of [RFC7234]).

It should say:

   [paragraph removed]

Notes:

The HTTP cache key (RFC 7234 Section 2) is based on the request URI, not on properties of the connection. Therefore, if a client were to cache a 421 response, it would then use this cached 421 to satisfy further requests to the same URI, before it has a chance to connect to an authoritative server.

Mark Nottingham: As discussed on list, I think the best we can do here is to note that in many cases, it'd be desireable to mark this as explicitly uncacheable.

With this paragraph removed, a 421 response is not cacheable by default, per RFC 7231 Section 6.1.

Errata ID: 6309
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Mike Bishop
Date Reported: 2020-10-19
Held for Document Update by: Barry Leiba
Date Held: 2020-10-27

Section 5.1 says:

      Receiving any frame other than HEADERS or PRIORITY on a stream in
      this state MUST be treated as a connection error (Section 5.4.1)
      of type PROTOCOL_ERROR.

...and similar throughout the section

It should say:

      Receiving any frame defined in this document other than HEADERS
      or PRIORITY on a stream in
      this state MUST be treated as a connection error (Section 5.4.1)
      of type PROTOCOL_ERROR.  Frames of unknown types are ignored.

Notes:

Discovered via Chrome's GREASE experiment and discussed on-list, but never filed that I can find. The HTTP/2 RFC mandates tolerance of any unknown frame type, but also mandates rejection of frames which are not the few listed. The conservative solution in current deployments is, of course, to restrict sending extension frame types to open (and half-closed (remote)) streams. The text which should have been in the document to begin with, however, is that only frame types defined in the HTTP/2 specification were to be impacted by that restriction.

This is already stated in section 5.1:

In the absence of more specific guidance elsewhere in this document,
implementations SHOULD treat the receipt of a frame that is not
expressly permitted in the description of a state as a connection
error (Section 5.4.1) of type PROTOCOL_ERROR. Note that PRIORITY can
be sent and received in any stream state. Frames of unknown types
are ignored.

However, it's unclear whether the "any frame other than" language is to be construed as "more specific guidance."

Errata ID: 4720
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kazu Yamamoto
Date Reported: 2016-06-27
Held for Document Update by: Alexey Melnikov
Date Held: 2016-08-11

Section 8.2.1 says:

Pushed responses are always associated with an explicit request from
the client.  The PUSH_PROMISE frames sent by the server are sent on
that explicit request's stream. 

It should say:

Promised requests are always associated with an explicit request from
the client.  The PUSH_PROMISE frames sent by the server are sent on
that explicit request's stream. 

Notes:

This section talks about promised requests, not pushed responses.

Alexey:
As per HTTPBIS WG discussion, this is correct in the original, but clearer in the proposed text.

Errata ID: 4925
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Martin Thomson
Date Reported: 2017-02-07
Held for Document Update by: Alexey Melnikov
Date Held: 2017-02-23

Throughout the document, when it says:

Notes:

It's unclear from the text whether PRIORITY frames affect stream states (as shown in the state machine in Section 5.1). The original intent was that prioritization of streams was independent of the mechanics of opening and closing streams, but this was not consistently captured.

Two small additions to the document would help considerably.

In Section 5.3 (Stream Priority) add a new paragraph:

> The information that an endpoint maintains for stream priority is separate from other state. Importantly, this includes stream states (Section 5.1). A stream in any state can have its priority changed with a PRIORITY frame. The state of a stream is not changed as a result of changing its priority. The number of streams for which state is remembered is at the discretion of an endpoint, see Section 5.3.4 for details.

In Section 6.4 (PRIORITY) a new sentence at the end of the first paragraph:

> Sending or receiving a PRIORITY frame does not affect the state of any stream (Section 5.1), only the priority of streams is altered.

RFC 7541, "HPACK: Header Compression for HTTP/2", May 2015

Source of RFC: httpbis (wit)

Errata ID: 4574
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christian Parpart
Date Reported: 2015-12-31
Held for Document Update by: Barry Leiba
Date Held: 2015-12-31

Section Appendix A. says:

   Table 1 lists the predefined header fields that make up the static
   table and gives the index of each entry.

It should say:

   Table 1 lists the predefined header fields that make up the static
   table and gives the index of each entry.

   This list of predefined header fields is NOT sorted.

Notes:

The list of header fields actually is sorted except for one field. The field with index 19 should be between the fields with index 14 and 15).

That is why it gives the false impression that an implementer may use binary search algorithm to look up for header fields (while encoding) in order to retrieve their index numbers.

I highly encourage to at either move that field up or at least clarify that this list (even though it looks sorted), it is not.

Errata ID: 5094
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Xue Fei
Date Reported: 2017-08-24
Held for Document Update by: Alexey Melnikov
Date Held: 2017-09-21

Section 5.1 says:

Integers are used to represent name indexes, header field indexes,
or string lengths.

It should say:

Integers are used to represent name indexes, header field indexes,
string lengths, or dynamic table size.

Notes:

Section 5.1 says, Integer encodings that exceed implementation limits — in value or octet length — MUST be treated as decoding errors.

Section 6.3 is using HPACK integer to represent value of dynamic table size. This size can be more larger than index or string length.

This change make user who implement integer encoding/decoding can figure out a proper integer value limit for each condition.

RFC 7543, "Covering Prefixes Outbound Route Filter for BGP-4", May 2015

Source of RFC: bess (rtg)

Errata ID: 4669
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ron Bonica
Date Reported: 2016-04-15
Held for Document Update by: Alvaro Retana
Date Held: 2016-04-15

Section 4 and 5 says:

   V-spoke1 establishes a BGP session with the RR, negotiating the
   CP-ORF capability as well as the Multiprotocol Extensions capability

It should say:

   V-spoke1 establishes a BGP session with the RR, advertising the
   ORF capability (including the CP ORF Type in its ORF Type list)
   as well as the Multiprotocol Extensions capability

Notes:

This text occurs twice, once in Section 4 and again in Section 5

Errata ID: 5258
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alexander ("Sasha") Vainshtein
Date Reported: 2018-02-08
Held for Document Update by: Alvaro Retana
Date Held: 2018-03-14

Section Section 5 says:

The UMR is characterized as follows:

   o  EVPN Route Type is equal to MAC/IP Advertisement Route

   o  MAC address length is equal to 0

   o  IP address length is equal to 0

It should say:

In Section 5:

The UMR is characterized as follows:

   o  EVPN Route Type is equal to MAC/IP Advertisement Route

   o  MAC address length is equal to 48

   o  IP address length is equal to 0

Notes:

The original text provides conflicting definitions of the MAC Address Length in the Unknown MAC Route (UMR).

Since the UMR is a MAC/IP Advertisement Route defined in RFC 7432, and since this RFC states that the MAC Address Length in these routes is 48, the text in Section 5 should be corrected to match RFC 7432 as well as the text in Section 1 of this RFC (where MAC Address Length in the UMR is correctly defined as 48).

RFC 7554, "Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement", May 2015

Source of RFC: 6tisch (int)

Errata ID: 4426
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yusuke DOI
Date Reported: 2015-07-23
Held for Document Update by: Brian Haberman
Date Held: 2015-07-23

Section Abstract says:

   This document describes the environment, problem statement, and goals
   for using the Time-Slotted Channel Hopping (TSCH) Medium Access
   Control (MAC) protocol of IEEE 802.14.4e in the context of Low-Power
   and Lossy Networks (LLNs).  The set of goals enumerated in this
   document form an initial set only

It should say:

   This document describes the environment, problem statement, and goals
   for using the Time-Slotted Channel Hopping (TSCH) Medium Access
   Control (MAC) protocol of IEEE 802.15.4e in the context of Low-Power
   and Lossy Networks (LLNs).  The set of goals enumerated in this
   document form an initial set only

Notes:

s/802.14.4e/802.15.4e/

RFC 7556, "Multiple Provisioning Domain Architecture", June 2015

Source of RFC: mif (int)

Errata ID: 4389
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ian Farrer
Date Reported: 2015-06-10
Held for Document Update by: Brian Haberman
Date Held: 2015-09-14

Section 4.3 says:

Figure 3: An Example of PvD Use with Wi-Fi and Mobile Interfaces

It should say:

Figure 3: An Example of PvD Use within a Home Network

Notes:

The title for Figure 3 is erroneously the same as the title for Figure 1 in section 4.1.

RFC 7568, "Deprecating Secure Sockets Layer Version 3.0", June 2015

Note: This RFC has been updated by RFC 8996

Source of RFC: tls (sec)

Errata ID: 4561
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Richard Petrie
Date Reported: 2015-12-08
Held for Document Update by: Stephen Farrell
Date Held: 2015-12-08

Section 1. says:

Since it was released in 1996, the SSLv3 protocol [RFC6101] has been
   subject to a long series of attacks, both on its key exchange
   mechanism and on the encryption schemes it supports.  Despite being
   replaced by TLS 1.0 [RFC2246] in 1999, and subsequently TLS 1.1 in
   2002 [RFC4346] and 1.2 in 2006 [RFC5246], availability of these
   replacement versions has not been universal.  As a result, many
   implementations of TLS have permitted the negotiation of SSLv3.

   The predecessor of SSLv3, SSL version 2, is no longer considered
   sufficiently secure [RFC6176].  SSLv3 now follows.

It should say:

Since it was released in 1996, the SSLv3 protocol [RFC6101] has been
   subject to a long series of attacks, both on its key exchange
   mechanism and on the encryption schemes it supports.  Despite being
   replaced by TLS 1.0 [RFC2246] in 1999, and subsequently TLS 1.1 in
   2006 [RFC4346] and 1.2 in 2008 [RFC5246], availability of these
   replacement versions has not been universal.  As a result, many
   implementations of TLS have permitted the negotiation of SSLv3.

   The predecessor of SSLv3, SSL version 2, is no longer considered
   sufficiently secure [RFC6176].  SSLv3 now follows.

Notes:

TLS 1.1 was first drafted in 2002, but not published until 2006. Similarly, TLS 1.2 was drafted in 2006, but not published until 2008.

RFC 7585, "Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI)", October 2015

Source of RFC: radext (sec)

Errata ID: 4991
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alan DeKok
Date Reported: 2017-04-07
Held for Document Update by: Benoit Claise
Date Held: 2017-07-27

Throughout the document, when it says:

Notes:

The document describes how to look up realms, but doesn't describe what to do after that. i.e. are the lookups cached? Are the lookups done for every request that comes in?

This gives little guidance for an implementor.

I suggest leveraging the "logical AAA routing table" described in RFC 7542 Section 3. In short form:

* a client MUST maintain a table of known dynamic realms.

* the table MUST be keyed by the realm name, and the contents MUST be server-specific information as described in RFC 7542 Section 3

* when a realm is being looked up, the realm SHOULD be inserted into the table with a "pending" flag, so subsequent requests during the lookup process do not cause additional lookups to be made

* if server validation fails, the realm SHOULD be updated with a "failed" state and a TTL, so that subsequent requests do not cause additional lookups for a period of time. No server information should be stored for this entry. i.e. the realm is marked as "failed", the corresponding server MUST NOT be marked as "failed". This prevents attacks where a malicious actor could point their realm to an unknowing third-party server, and cause poorly implemented proxies to mark it "failed".

* if server validation succeeds, the realm MUST be updated with a "live" state (and a TTL), so that subsequent requests go to the same server without additional lookups

* if server validation succeeds, all realms in the TLS "subject alternative names" presented by the server SHOULD be inserted into the realm table, all pointing to the same server definition, so that subsequent requests for those other realms do not cause additional lookups to be made.

* servers which have been dynamically looked up MUST NOT be added to any global pool of servers. i.e. the lookup is always "realm -> server", and not "There's a known server at this IP address"

I thought we had a short discussion of some of these topics on RADEXT, but I can't find it in the archives.

I think these comments are substantial enough to warrant "wait for document update". I just wanted to ensure they weren't lost.

RFC 7595, "Guidelines and Registration Procedures for URI Schemes", June 2015

Note: This RFC has been updated by RFC 8615

Source of RFC: appsawg (art)

Errata ID: 7011
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Timothy McSweeney
Date Reported: 2022-07-01
Held for Document Update by: Murray Kucherawy
Date Held: 2022-08-10

Section 3 says:

[RFC3986] defines the overall syntax for URIs as:

               URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

   A scheme definition cannot override the overall syntax for URIs. 

It should say:

[RFC3986] defines the generic syntax for URIs as:

               URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

   A scheme definition cannot override the generic syntax for URIs. 

Notes:

There are two instances here where [RFC3986] is incorrectly referenced by using the word 'overall' and should instead be replaced with the term 'generic' as it is uses the identical example from https://datatracker.ietf.org/doc/html/rfc3986#section-3

RFC 7599, "Mapping of Address and Port using Translation (MAP-T)", July 2015

Source of RFC: softwire (int)

Errata ID: 5323
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Shachar Rosenberg
Date Reported: 2018-04-11
Held for Document Update by: Eric Vyncke
Date Held: 2020-01-08

Section Appendix A says:

Example 4:

IPv4 address:            192.0.2.18 (0xc0000212)

It should say:

Example 4:

IPv4 address:            192.0.2.1 (0xc0000201)

Notes:

BMR defines 0 EA bits and IPv4 prefix 192.0.2.1/32, shouldn't the IPv4 address be 192.0.2.1?

Another possible option perhaps would be to change the BMR IPv4 prefix to 192.0.2.18/32 and the IPv6 address of MAP CE to: 2001:db8:0012:3400:0000:c000:0212:0000

Errata ID: 5322
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Shachar Rosenberg
Date Reported: 2018-04-11
Held for Document Update by: Eric Vyncke
Date Held: 2019-12-25

Section Appendix A says:

Example 2 - BR:
PSID:  0                  x34 (1232)

Example 4:

It should say:

Example 2 - BR:

PSID:                     0x34 (1232)

Notes:

There is a long space between 0 and x34

RFC 7605, "Recommendations on Using Assigned Transport Port Numbers", August 2015

Source of RFC: tsvwg (wit)

Errata ID: 5592
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: C. M. Heard
Date Reported: 2019-01-05
Held for Document Update by: Mirja Kühlewind
Date Held: 2019-03-22

Section 3 says:

                                      [RFC1340] also establishes the
   Registered range of 1024-59151, though it notes that it is not
   controlled by the IANA (at that point). 

It should say:

                                      [RFC1340] first indicated the
   Registered range of 1024-65535. This noted that the range was only
   recorded (rather than controlled) by IANA. The list provided by
   [RFC1700] in 1994 remained the standard, until replaced by an
   online version in 2002 [RFC3232].  At some time after 1994, but
   before 2000, the Registered range was changed to 1024-49151 and the
   Dynamic/Private range of 49152-65535 was established, although this
   change was not recorded in the RFC series until 2011 [RFC6335].

Notes:

There is an editorial issue as the original text indicated the wrong range with respect to RFC1340. However, the range should not just be updated in the text as there is more history that needs clarification.

RFC 7606, "Revised Error Handling for BGP UPDATE Messages", August 2015

Source of RFC: idr (rtg)

Errata ID: 5941
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Benjamin Kaduk
Date Reported: 2019-12-18
Held for Document Update by: Alvaro Retana
Date Held: 2019-12-18

Section 7.16 says:

         An UPDATE message with a malformed ATTR_SET attribute SHALL be
         handled using the approach of "treat as withdraw".

It should say:

         An UPDATE message with a malformed ATTR_SET attribute SHALL be
         handled using the approach of "treat-as-withdraw".

Notes:

All 20 other instances of "treat-as-withdraw" in the document use the hyphenated form.

RFC 7616, "HTTP Digest Access Authentication", September 2015

Source of RFC: httpauth (sec)

Errata ID: 5801
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Franck MOURRE
Date Reported: 2019-08-06
Held for Document Update by: Benjamin Kaduk
Date Held: 2019-08-08

Section 3.7 says:

   This specification defines the following algorithms:

   o  SHA2-256 (mandatory to implement)

   o  SHA2-512/256 (as a backup algorithm)

   o  MD5 (for backward compatibility).

It should say:

   This specification defines the following algorithms:

   o  SHA-256 (mandatory to implement)

   o  SHA-512/256 (as a backup algorithm)

   o  MD5 (for backward compatibility).

Notes:

The SHA-2 family of algorithms are conventionally referred to using just "SHA-" and the bit strength, not "SHA2-" and the bit strength.

Errata ID: 5803
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Franck MOURRE
Date Reported: 2019-08-06
Held for Document Update by: Benjamin Kaduk
Date Held: 2019-08-08

Section A says:

   o  Adds support for two new algorithms, SHA2-256 as mandatory and
      SHA2-512/256 as a backup, and defines the proper algorithm
      negotiation.  The document keeps the MD5 algorithm support but
      only for backward compatibility.

It should say:

   o  Adds support for two new algorithms, SHA-256 as mandatory and
      SHA-512/256 as a backup, and defines the proper algorithm
      negotiation.  The document keeps the MD5 algorithm support but
      only for backward compatibility.

Notes:

The SHA-2 family of algorithms are conventionally referred to using just "SHA-" and the bit strength, not "SHA2-" and the bit strength.

RFC 7622, "Extensible Messaging and Presence Protocol (XMPP): Address Format", September 2015

Source of RFC: xmpp (art)

Errata ID: 5769
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Florian Schmaus
Date Reported: 2019-06-30
Held for Document Update by: Barry Leiba
Date Held: 2019-07-02

Section 3.2.1 says:

An entity that prepares a string for inclusion in an XMPP domainpart
slot MUST ensure that the string consists only of Unicode code points
that are allowed in NR-LDH labels or U-labels as defined in
[RFC5890].

It should say:

An entity that prepares a string for inclusion in an XMPP domainpart
slot MUST ensure that the string consists only of Unicode code points
that are allowed in NR-LDH labels or U-labels as defined in
[RFC5890], or the DNS label separator "dot" (U+002E, FULL STOP).

Notes:

The current specification forbids the inclusion of dots (".") in the domainpart, since they are not allowed in NR-LDH nor U-labels. But they should be allowed, as otherwise a DNS name could never be put into an XMPP domainpart (which is commonly done).

----- Verifier notes -----
This is correct as far as it goes, but there's more to the fix than this, so proper discussion, consensus, and document update are needed. There are, for example, other dot characters that need to be allowed as well as U+002E. The bottom line is that Florian is correct that DNS label separators need to be allowed, and the proper fix to the text is deferred to any future document update.

Errata ID: 5789
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Florian Schmaus
Date Reported: 2019-07-22
Held for Document Update by: Barry Leiba
Date Held: 2019-07-22

Section 3.2.1 says:

An entity that prepares a string for inclusion in an XMPP domainpart
slot MUST ensure that the string consists only of Unicode code points
that are allowed in NR-LDH labels or U-labels as defined in
[RFC5890].

It should say:

An entity that prepares a string for inclusion in an XMPP
domainpart slot MUST ensure that the string consists only of
- code points allowed in U-labels as defined in [RFC5890]
- % U+0025 PERCENT SIGN
- . U+002E (FULL STOP, DNS label separator "dot")
- : U+003A (COLON)
- ] U+005B (LEFT SQUARE BRACKET)
- [ U+005D (RIGHT SQUARE BRACKET)

Notes:

This is a follow up and update on Errata ID #5769. Besides allowing DNS label separators in the domainpart, this further allows codepoints not allowed in U-labels but required by the IP-literal rule of RFC6874, which is used by RFC7622 to allow IPv6 addresses in XMPP domainparts. As in the previous errata, this also drops the reference to NR-LDH labels, which I believe to be unnecessary.

===== Verifier Notes =====
As with the related errata report, this is held for document update because more discussion and consensus is needed. So this is on record for that discussion.

Errata ID: 4470
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2015-09-10
Held for Document Update by: Ben Campbell
Date Held: 2015-09-12

Section 3.5 says:

<king@example.com/&#x265A>;

It should say:

<king@example.com/&#x265A;>

Notes:

Right angle bracket arrived too soon.

RFC 7634, "ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec", August 2015

Source of RFC: ipsecme (sec)

Errata ID: 5441
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Andrew Cagney
Date Reported: 2018-07-26
Held for Document Update by: Paul Wouters
Date Held: 2022-04-11

Section 4 says:

   When negotiating the ChaCha20-Poly1305 algorithm for use in IKE or
   IPsec, the value ENCR_CHACHA20_POLY1305 (28) should be used in the
   transform substructure of the SA payload as the ENCR (type 1)
   transform ID.  As with other AEAD algorithms, INTEG (type 3)
   transform substructures MUST NOT be specified, or just one INTEG
   transform MAY be included with value NONE (0).

It should say:

   When negotiating the ChaCha20-Poly1305 algorithm for use in IKE or
   IPsec, the value ENCR_CHACHA20_POLY1305 (28) should be used in the
   transform substructure of the SA payload as the ENCR (type 1)
   transform ID.
   As with other transforms that use a fixed-length key, the Key Length
   attribute MUST NOT be specified.
   As with other AEAD algorithms, INTEG (type 3)
   transform substructures MUST NOT be specified, or just one INTEG
   transform MAY be included with value NONE (0).

Notes:

Reading both RFC7634 and RFC7539 there seems to be a single fixed-length key of 256-bits.
Hence, I think https://tools.ietf.org/html/rfc7296#section-3.3.5:
o The Key Length attribute MUST NOT be used with transforms that use
a fixed-length key. For example, this includes ENCR_DES,
ENCR_IDEA,...
applies (my intent is to clarify this).

Paul Wouters:

I agree this should be added in future versions of this document to prevent implementation mistakes. However, not mentioning it here is not an error, so resolving this as Held for Document Update.

RFC 7635, "Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization", August 2015

Source of RFC: tram (tsv)

Errata ID: 4826
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Mihály Mészáros
Date Reported: 2016-10-10
Held for Document Update by: Magnus Westerlund
Date Held: 2021-01-14

Section 8. says:

8.  STUN Client Behavior

   o  The client looks for the MESSAGE-INTEGRITY attribute in the
      response.  If MESSAGE-INTEGRITY is absent or the value computed
      for message integrity using mac_key does not match the contents of
      the MESSAGE-INTEGRITY attribute, then the response MUST be
      discarded.

   o  If the access token expires, then the client MUST obtain a new
      token from the authorization server and use it for new STUN
      requests.

It should say:

8.  STUN Client Behavior

   o  The client looks for the MESSAGE-INTEGRITY attribute in the
      response.  If MESSAGE-INTEGRITY is absent or the value computed
      for message integrity using mac_key does not match the contents of
      the MESSAGE-INTEGRITY attribute, then the response MUST be
      discarded.

9.  Application (OAuth Client) Behavior

   o  If the access token expires, then the Application (OAuth client) 
      MUST obtain a new token from the authorization server, and update
      STUN client to use it for new STUN requests.

   o  Application SHOULD pass only a subset of the received OAuth 
      parameters to the STUN client. Only parameters SHOULD be passed 
      that will be really needed and used by the STUN Client. 
      In this way, only the kid, the mac_key, and the access_token
      parameters SHOULD be passed to the STUN client.
      

...
Renumber the sections
...

Notes:

1. Remove from STUN client behaviour the access_token renewal function,
and move this function up to application level.
2. Pass to STUN only that subset of the OAuth parameters, that will be really used by STUN Client.

Errata ID: 4923
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Mészáros Mihály
Date Reported: 2017-02-03
Held for Document Update by: Magnus Westerlund
Date Held: 2021-01-14

Section Appendix B. says:

          "key":"v51N62OM65kyMvfTI08O"

It should say:

        "key": "ew0KICAgICJrdHkiOiJvY3QiLA0KICAgICJ
raWQiOiJpZDEyMyIsDQogICAgImFsZyI6IkhTMjU2IiwNCiAgIC
AiayI6IlpvUlNPckZ6Tl9GelVBNVhLTVlvVkh5emZmNW9SSnhsL
UlYUnR6dEo2dUUiDQp9"

Notes:

"key" according https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02#section-4.2
"The 'key' parameter either contains a plain JWK structure or a JWK encrypted with a JWE."

According Example Figure 2. "key" in draft-ietf-oauth-pop-key-distribution-02#section-4.2
It seems they missed to write plain JWK MUST be base64 format.
So according the example coorected the above sentence:

"The 'key' parameter either contains a plain BASE64 ENCODED JWK structure or a JWK encrypted with a JWE."

Anyhow in RFC7635 Appendix B. the
"key" seems to be not in base64 (JWK) or JWE encrypted JWK format.
(Base64 decoded key value string is "Salted__"....)

RFC 7644, "System for Cross-domain Identity Management: Protocol", September 2015

Source of RFC: scim (sec)

Errata ID: 7122
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Egil Hansen
Date Reported: 2022-09-08
Held for Document Update by: Murray Kucherawy
Date Held: 2022-09-12

Section 3.5.2 says:

   The "path" attribute is described by the following ABNF syntax rule:

                   PATH = attrPath / valuePath [subAttr]

                      Figure 7: SCIM PATCH PATH Rule

   The ABNF rules "attrPath", "valuePath", and "subAttr" are defined in
   Section 3.4.2.2.  The "valuePath" rule allows specific values of a
   complex multi-valued attribute to be selected.

It should say:

   The "path" attribute is described by the following ABNF syntax rule:

                   PATH = attrPath / valuePath [subAttr] / attrExp

                      Figure 7: SCIM PATCH PATH Rule

   The ABNF rules "attrPath", "valuePath", "subAttr", and "attrExp" are 
   defined in Section 3.4.2.2. The "valuePath" rule allows specific 
   values of a complex multi-valued attribute to be selected.

Notes:

In section 3.5.2.2. (Remove Operation), states:

"If the target location is a multi-valued attribute and a complex
filter is specified comparing a "value", the values matched by the
filter are removed. If no other values remain after removal of
the selected values, the multi-valued attribute SHALL be
considered unassigned."

This means it should be possible to create a filter that selects a value from a multi-valued attribute that is not complex. Writing such a filter seems impossible without having "attrExp" as a possible legal PATH.

In section 3.4.2.2. (Filtering) there is an example that shows how such a filter could look for a multi-valued attribute, i.e.:

filter=
schemas eq "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"

This would also work for a path filter, e.g.:

{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations":[{
"op":"remove",
"path":"schemas eq \"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User\""
}]
}

[AD Note: The document reflects consensus of the working group at the time of publication, but on review it is believed that any future update work in this space should consider this erratum.]

RFC 7652, "Port Control Protocol (PCP) Authentication Mechanism", September 2015

Source of RFC: pcp (int)

Errata ID: 4513
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2015-10-28
Held for Document Update by: Brian Haberman
Date Held: 2015-10-28

Section 5.5 says:

      Option-Length: The length of the PA_AUTHENTICATION option for the
      PCP Auth message (in octets), including the 4-octet fixed-length
      header and the variable-length authentication data.

It should say:

      Option-Length: The length of the PA_AUTHENTICATION_TAG option
      for the PCP Auth message (in octets), including the 4-octet
      fixed-length header and the variable-length authentication data.

Notes:

Incorrect option name in the field description.

RFC 7672, "SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)", October 2015

Source of RFC: dane (sec)

Errata ID: 6283
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Viktor Dukhovni
Date Reported: 2020-09-08
Held for Document Update by: Paul Wouters
Date Held: 2024-01-16

Section 3.2.2 says:

3.2.2.  DANE-TA(2) Name Checks

   To match a server via a TLSA record with certificate usage
   DANE-TA(2), the client MUST perform name checks to ensure that it has
   reached the correct server.  In all DANE-TA(2) cases, the SMTP client
   MUST employ the TLSA base domain as the primary reference identifier
   for matching the server certificate.

   TLSA records for MX hostnames:  If the TLSA base domain was obtained
      indirectly via a "secure" MX lookup (including any CNAME-expanded
      name of an MX hostname), then the original next-hop domain used in
      the MX lookup MUST be included as a second reference identifier.
      The CNAME-expanded original next-hop domain MUST be included as a
      third reference identifier if different from the original next-hop
      domain.  When the client MTA is employing DANE TLS security
      despite "insecure" MX redirection, the MX hostname is the only
      reference identifier.

It should say:

3.2.2.  DANE-TA(2) Name Checks

   To match a server via a TLSA record with certificate usage
   DANE-TA(2), the client MUST perform name checks to ensure that it has
   reached the correct server.  In all DANE-TA(2) cases, the SMTP client
   MUST employ the TLSA base domain as the primary reference identifier
   for matching the server certificate.

   TLSA records for MX hostnames:  If the TLSA base domain was obtained
      indirectly via a "secure" MX lookup (including any CNAME-expanded
      name of an MX hostname), then the original next-hop domain used in
      the MX lookup MUST be included as a second reference identifier.
      The CNAME-expanded original next-hop domain MUST be included as a
      third reference identifier if different from the original next-hop
      domain.  When the client MTA is employing DANE TLS security
      despite "insecure" MX redirection, the TLSA base domain is the only
      reference identifier.

Notes:

The first paragraph of 3.2.2 makes it clear that the TLSA base domain is the primary reference identifier in all cases. The last sentence of the second paragraph inadvertently contradicts this in the case the the TLSA base domain is a CNAME expansion of the input MX hostname.

The corrected text replaces "... the MX hostname is the only reference identifier" with "... the TLSA base domain is the only reference identifier".

RFC 7697, "MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) Identifiers Management Information Base (MIB)", January 2016

Source of RFC: mpls (rtg)

Errata ID: 4586
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Venkatesan Mahalingam
Date Reported: 2016-01-09
Held for Document Update by: Deborah Brungard
Date Held: 2016-02-08

Section 9.1 says:

9.1.  IANA Considerations for MPLS-OAM-ID-STD-MIB

   IANA has to assign the OID { mplsStdMIB 21 } to the
   MPLS-OAM-ID-STD-MIB module specified in this document.

It should say:

9.1.  IANA Considerations for MPLS-OAM-ID-STD-MIB

   IANA has assigned the OID { mplsStdMIB 21 } to the
   MPLS-OAM-ID-STD-MIB module specified in this document.

Notes:

Missed by RFC Editor to change from future tense "has to assign" to past tense "has assigned".

RFC 7725, "An HTTP Status Code to Report Legal Obstacles", February 2016

Source of RFC: httpbis (wit)

Errata ID: 5181
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2017-11-11
Held for Document Update by: Francesca Palombini
Date Held: 2022-11-09

Section 3 says:

   Link: <https://spqr.example.org/legislatione>; rel="blocked-by"

It should say:

   Link: <https://search.example.net/legal>; rel="blocked-by"

Notes:

Of course, it is hard to say from just an URL but it seems that the original "blocked-by" mentioned the authority requesting the blocking (spqr = Roman Senate and People) while the text in section 4 says "The intent is that the header be used to identify the entity actually implementing blockage, not any other entity mandating it."

Experience with the 451 crawler during the IETF 99 hackathon showed that several implementors got this wrong and used a "blocked-by" indicating the authority.

[It could be a good idea to have two links, one for the authority and one for the implementor, but this is outside the scope of this errata.]

RFC 7761, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", March 2016

Note: This RFC has been updated by RFC 8736, RFC 9436

Source of RFC: pim (rtg)

Errata ID: 5367
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Frank Hua Li
Date Reported: 2018-05-24
Held for Document Update by: Alvaro Retana
Date Held: 2018-10-29

Section 4.4.2 says:

4.4.2 Page 44
   Thus, at the RP, KeepaliveTimer(S,G) should be restarted to ( 3 *
   Register_Suppression_Time + Register_Probe_Time ).

It should say:

4.4.2 Page 44
   Thus, at the RP, KeepaliveTimer(S,G) should be restarted to the 
   maximum of ( 3 * Register_Suppression_Time + Register_Probe_Time ) 
   and Keepalive_Period.

Notes:

The normal keepalive period for the KAT(S,G) defaults to 210 seconds. However, at the RP, the keepalive period must be at least the Register_Suppression_Time, or the RP may time out the (S,G) state before the next Null-Register arrives. Thus, the KAT(S,G) is set to max(Keepalive_Period, RP_Keepalive_Period) when a Register-Stop is sent.

====
Note that the text above comes from §4.11.

===
Please also refer to Errata ID 5342.

RFC 7774, "Multicast Protocol for Low-Power and Lossy Networks (MPL) Parameter Configuration Option for DHCPv6", March 2016

Source of RFC: roll (rtg)

Errata ID: 5057
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: James K.
Date Reported: 2017-06-29
Held for Document Update by: Alvaro Retana
Date Held: 2017-11-06

Section 2.1 says:

DM_IMAX (unsigned 8-bit integer):  DATA_MESSAGE_IMAX.  The actual
      maximum timeout is described as a number of doublings of
      DATA_MESSAGE_IMIN, as described in [RFC6206], Section 4.1.
      0 and 0xff are reserved and MUST NOT be used.

It should say:

DM_IMAX (unsigned 8-bit integer):  DATA_MESSAGE_IMAX.  The actual
      maximum timeout is described as a number of doublings of
      DATA_MESSAGE_IMIN, as described in [RFC6206], Section 4.1.
      0xff is reserved and MUST NOT be used.

Notes:

RFC6206
The maximum interval size, Imax, is described as a number of
doublings of the minimum interval size.

RFC7731
DATA_MESSAGE_IMAX - The maximum Trickle timer interval, as defined
in [RFC6206], for MPL Data Message transmissions.
DATA_MESSAGE_IMAX has a default value equal to DATA_MESSAGE_IMIN.
also
The default MPL parameters specify a forwarding strategy that
utilizes both proactive and reactive techniques. Using these default
values, an MPL Forwarder proactively transmits any new MPL Data
Messages it receives and then uses MPL Control Messages to trigger
additional MPL Data Message retransmissions where message drops are
detected. Setting DATA_MESSAGE_IMAX to the same value as
DATA_MESSAGE_IMIN in this case is acceptable, since subsequent MPL
Data Message retransmissions are triggered by MPL Control Messages,
where CONTROL_MESSAGE_IMAX is greater than CONTROL_MESSAGE_IMIN.

For DATA_MESSAGE_IMAX == DATA_MESSAGE_IMIN implies DM_IMAX=0. 0 is a valid value for DM_IMAX.

=====
[Alvaro Retana]

The pointer to rfc7731 seems to indicate that the description for is incorrect. However, this document uses Normative language to define the DM_IMAX parameter.

I am then not marking this report as Verified, but as "Hold for Document Update", which means that when this document is updated, the validity should be considered then. [1]

[1] https://www.ietf.org/iesg/statement/errata-processing.html

Errata ID: 5063
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: James K.
Date Reported: 2017-07-06
Held for Document Update by: Alvaro Retana
Date Held: 2017-11-06

Section 2.1 says:

   C_T_EXP (unsigned 16-bit integer):
      CONTROL_MESSAGE_TIMER_EXPIRATIONS.  0 and 0xffff are reserved and
      MUST NOT be used.

It should say:

   C_T_EXP (unsigned 16-bit integer):
      CONTROL_MESSAGE_TIMER_EXPIRATIONS.  0xffff is reserved and
      MUST NOT be used.

Notes:

[RFC 7731] states:

9.3. MPL Data Message Processing

o If the MPL Control Message Trickle timer is not running and
CONTROL_MESSAGE_TIMER_EXPIRATIONS is non-zero, the MPL Forwarder
MUST initialize and start the MPL Control Message Trickle timer.

10.2. MPL Control Message Transmission

An MPL Forwarder transmits MPL Control Messages using the Trickle
algorithm. An MPL Forwarder maintains a single Trickle timer for
each MPL Domain. When CONTROL_MESSAGE_TIMER_EXPIRATIONS is 0, the
MPL Forwarder does not execute the Trickle algorithm and does not
transmit MPL Control Messages.

Thus, 0 is a valid configuration for C_T_EXP to disable Reactive Forwarding.

=====
[Alvaro Retana]

The pointer to rfc7731 seems to indicate that the description for CONTROL_MESSAGE_TIMER_EXPIRATIONS is incorrect. However, this document uses Normative language to define the C_T_EXP parameter.

I am then not marking this report as Verified, but as "Hold for Document Update", which means that when this document is updated, the validity should be considered then. [1]

[1] https://www.ietf.org/iesg/statement/errata-processing.html

RFC 7788, "Home Networking Control Protocol", April 2016

Note: This RFC has been updated by RFC 8375

Source of RFC: homenet (int)

Errata ID: 4718
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Ralph Droms
Date Reported: 2016-06-23
Held for Document Update by: Terry Manderson
Date Held: 2017-01-31

Throughout the document, when it says:

7.4.  Multicast DNS Proxy

   The designated Multicast DNS (mDNS) [RFC6762] proxy on a Common Link
   is elected based on the capabilities described in Section 4.

[...]

   The elected router MUST provide an mDNS proxy on the given link and
   announce it as described in Section 8.

[...]

8.  Naming and Service Discovery

   [...]

   Each HNCP router SHOULD provide and announce an auto-generated or
   user-configured name for each internal Common Link (Section 6.1) for
   which it is the designated DHCPv4, stateful DHCPv6 server, mDNS
   proxy, or for which it provides forward or reverse DNS services on
   behalf of connected devices.

[...]

10.1.  HNCP-Version TLV

   [...]

   M-capability:  Priority value used for electing the on-link mDNS
      [RFC6762] proxy.  It MUST be set to 0 if the router is not capable
      of proxying mDNS, otherwise it SHOULD be set to 4 but MAY be set
      to any value from 1 to 7 to indicate a non-default priority

It should say:

7.4.  Multicast DNS Hybrid Proxy

   The designated Multicast DNS (mDNS) [RFC6762] Hybrid Proxy
   [draft-ietf-dnssd-hybrid-03] on a Common Link is elected based
   on the capabilities described in Section 4.

[...]

   The elected router MUST provide an mDNS Hybrid Proxy on the
   given link and announce it as described in Section 8.

[...]

8.  Naming and Service Discovery

   [...]

   Each HNCP router SHOULD provide and announce an auto-generated or
   user-configured name for each internal Common Link (Section 6.1) for
   which it is the designated DHCPv4, stateful DHCPv6 server, mDNS
   Hybrid Proxy, or for which it provides forward or reverse DNS
   services on behalf of connected devices.

[...]

10.1.  HNCP-Version TLV

   [...]

   M-capability:  Priority value used for electing the on-link mDNS
      Hybrid Proxy.  It MUST be set to 0 if the router is not capable
      of providing an mDNS Hybrid Proxy service, otherwise it SHOULD
      be set to 4 but MAY be set to any value from 1 to 7 to indicate
      a non-default priority

Notes:

RFC 7788 refers to "Multicast DNS (mDNS) proxy" and gives a citation for RFC 6762.

RFC 6762, "Multicast DNS," defines multicast DNS and mentions (without an explicit definition) a "Multicast DNS Proxy" service. This proxy service is also known as "Bonjour Sleep Proxy" [https://en.wikipedia.org/wiki/Bonjour_Sleep_Proxy]

However, the intent of RFC 7788 is to specify the operation and advertisement of the multicast DNS Hybrid Proxy Service, as defined in draft-ietf-dnssd-hybrid-03, "Hybrid Unicast/Multicast DNS-Based Service Discovery." This errata corrects the mentions of "mDNS proxy" in RFC 7788 to "Hybrid Proxy."

draft-ietf-dnssd-hybrid-03 should also be added to the Normative References.

RFC 7810, "IS-IS Traffic Engineering (TE) Metric Extensions", May 2016

Note: This RFC has been obsoleted by RFC 8570

Source of RFC: isis (rtg)

Errata ID: 5293
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jeffrey Haas
Date Reported: 2018-03-22
Held for Document Update by: Alvaro Retana
Date Held: 2018-05-24

Section 4.5-4.7 says:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type        |     Length    |  RESERVED     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Residual Bandwidth                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where:

   Type: 37

   Length: 4

   RESERVED: This field is reserved for future use

It should say:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type        |     Length    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Residual Bandwidth                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where:

   Type: 37

   Length: 4

Notes:

In sections 4.5, 4.6 and 4.7, a RESERVED field is in the diagram and the text. However, the length field of each of these TLVs is 4. The RESERVED field is thus not present and should be removed in future editions of this document.
===
The discussion in the WG is here: https://mailarchive.ietf.org/arch/msg/lsr/x5DlcGmwMPf9hvgL6mofNqGpbQA/

Errata ID: 5486
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Teresa
Date Reported: 2018-08-31
Held for Document Update by: Alvaro Retana
Date Held: 2018-11-04

Section 4.6 says:

Available Bandwidth: This field carries the available bandwidth on a
   link, forwarding adjacency, or bundled link in IEEE floating-point
   format with units of bytes per second.  For a link or forwarding
   adjacency, available bandwidth is defined to be residual bandwidth
   (see Section 4.5) minus the measured bandwidth used for the actual
   forwarding of non-RSVP-TE label switched path packets.  For a bundled
   link, available bandwidth is defined to be the sum of the component
   link available bandwidths minus the measured bandwidth used for the
   actual forwarding of non-RSVP-TE label switched path packets.  For a
   bundled link, available bandwidth is defined to be the sum of the
   component link available bandwidths.

It should say:

Available Bandwidth: This field carries the available bandwidth on a
   link, forwarding adjacency, or bundled link in IEEE floating-point
   format with units of bytes per second.  For a link or forwarding
   adjacency, available bandwidth is defined to be residual bandwidth
   (see Section 4.5) minus the measured bandwidth used for the actual
   forwarding of non-RSVP-TE label switched path packets.  For a bundled
   link, available bandwidth is defined to be the sum of the component
   link (residual) bandwidths minus the measured bandwidth used for the
   actual forwarding of non-RSVP-TE label switched path packets.For a
   bundled link, available bandwidth is defined to be the sum of the
   component link available bandwidths.

Notes:

Two sentences to explain 'available bandwidth' on a bundled link, but one says "sum of component available bandwidth minus xxx", the other says "sum of component available bandwidth", is conflicting. need to change the first sentence to 'sum of component residual bandwidth minus xxx'

RFC 7838, "HTTP Alternative Services", April 2016

Source of RFC: httpbis (wit)

Errata ID: 6480
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lucas Pardue
Date Reported: 2021-03-12
Held for Document Update by: Francesca Palombini
Date Held: 2021-03-15

Section 2 says:

Formally, an alternative service is identified by the combination of:

   o  An Application Layer Protocol Negotiation (ALPN) protocol name, as
      per [RFC7301]

It should say:

Formally, an alternative service is identified by the combination of:

   o  An Application-Layer Protocol Negotiation (ALPN) protocol name, as
      per [RFC7301]

Notes:

RFC 7301 seems to formally use the hyphenated version. Most relevant to RFC 7838 is the ALPN ID registry, which RFC 7301 states:

This document establishes a registry for protocol identifiers
entitled "Application-Layer Protocol Negotiation (ALPN) Protocol IDs"

RFC 7841, "RFC Streams, Headers, and Boilerplates", May 2016

Note: This RFC has been updated by RFC 9280

Source of RFC: IAB

Errata ID: 4703
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2016-05-30
Held for Document Update by: Robert Sparks
Date Held: 2018-02-09

Section 3.2 says:

Notes:

Sections 3.3 through 3.6 should have been subsections of 3.2, as they describe parts of "status of this memo". See also RFC 5741 which has this right.

RFC 7854, "BGP Monitoring Protocol (BMP)", June 2016

Note: This RFC has been updated by RFC 8671, RFC 9069, RFC 9515

Source of RFC: grow (ops)

Errata ID: 4830
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Suhas Anand
Date Reported: 2016-10-12
Held for Document Update by: Joel Jaeggli
Date Held: 2017-03-29

Section 4.9 says:

Peer Down Notification

   This message is used to indicate that a peering session was
   terminated.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+
     |    Reason     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Data (present if Reason = 1, 2 or 3)               |
     ~                                                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

Peer Down Notification

   This message is used to indicate that a peering session was
   terminated. Following the common BMP header and per-peer header is 
   the following:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+
     |    Reason     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Data (present if Reason = 1, 2 or 3)               |
     ~                                                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

What:

For Peer Down Notification: To the programmer implementing the RFC, it is not clear if the Peer Down message consists of per peer header

Errata ID: 5736
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mohamed Boucadair
Date Reported: 2019-05-23
Held for Document Update by: Warren Kumari (Ops AD)
Date Held: 2019-07-01

Section 4.2 says:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Peer Type   |  Peer Flags   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Peer Distinguisher (present based on peer type)       |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 Peer Address (16 bytes)                       |
     ~                                                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Peer AS                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Peer BGP ID                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Timestamp (seconds)                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  Timestamp (microseconds)                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Peer Type   |  Peer Flags   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Peer Distinguisher (present based on peer type)       |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 Peer Address (16 bytes)                       |
     ~                                                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Peer AS                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Peer BGP ID                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Timestamp (seconds)                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  Timestamp (microseconds)                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

The OLD figure may be misinterpreted as if there are unused bits between the "Peer Flags" and "Peer Distinguisher".
WK: This also makes is consistent with other diagrams in this RFC.

RFC 7858, "Specification for DNS over Transport Layer Security (TLS)", May 2016

Note: This RFC has been updated by RFC 8310

Source of RFC: dprive (int)

Errata ID: 5375
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jelte Jansen
Date Reported: 2018-06-01
Held for Document Update by: Éric Vyncke
Date Held: 2019-12-19

Section 9.2 says:

   [DNSCRYPT-WEBSITE]
              Denis, F., "DNSCrypt", December 2015,
              <https://www.dnscrypt.org/>.

It should say:

   [DNSCRYPT-WEBSITE]
              Denis, F., "DNSCrypt", December 2015,
              <https://www.dnscrypt.info/>.

Notes:

www.dnscrypt.org leads to a parking page. The official website is now at www.dnscrypt.info.

RFC 7868, "Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP)", May 2016

Source of RFC: INDEPENDENT

Errata ID: 5185
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Varadhan Venkataseshan
Date Reported: 2017-11-21
Held for Document Update by: Adrian Farrel
Date Held: 2018-04-08

Section 6.9.3.5 says:

across a network measured in measured in microseconds.    

It should say:

across a network measured in microseconds.

Notes:

Words "measured in" is repeated twice at line number 3965 in section 6.9.3.5

Errata ID: 6089
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rafał Cygnarowski
Date Reported: 2020-04-12
Held for Document Update by: Adrian Farrel
Date Held: 2020-04-22

Section 5.5.2 says:

    EIGRP uses one-way-
   based values either provided by the interface or computed as a factor
   of the link s bandwidth.

It should say:

    EIGRP uses one-way-
   based values either provided by the interface or computed as a factor
   of the link's bandwidth.

Notes:

Missing apostrophe (') in "link's".

Errata ID: 6091
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rafał Cygnarowski
Date Reported: 2020-04-12
Held for Document Update by: Adrian Farrel
Date Held: 2020-04-22

Section 6.7.4. says:

           Vender OS major version        1
           Vender OS minor version        1

It should say:

           Vendor OS major version        1
           Vendor OS minor version        1

Notes:

Typo in 'Vendor' word.

RFC 7905, "ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS)", June 2016

Source of RFC: tls (sec)

Errata ID: 5251
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Xavier Bonnetain
Date Reported: 2018-02-01
Held for Document Update by: Paul Wouters
Date Held: 2024-03-18

Section 4. Security says:

   Poly1305 is designed to ensure that forged messages are rejected with
   a probability of 1-(n/2^107), where n is the maximum length of the
   input to Poly1305.  In the case of (D)TLS, this means a maximum
   forgery probability of about 1 in 2^93.

It should say:

   Poly1305 is designed to ensure that forged messages are rejected with
   a probability of 1-(n/2^106), where n is the maximum length of the
   input to Poly1305.  In the case of (D)TLS, this means a maximum
   forgery probability of about 1 in 2^92.

Notes:

The security claimed on poly1305 is slightly beyond what was proven by the designer (see https://cr.yp.to/mac/poly1305-20050329.pdf), and the trivial forgery attempt with a message of length 1 succeeds with probability 2^{-106}.

Paul Wouters(AD): See https://mailarchive.ietf.org/arch/msg/tls/dBMIsLsaA7XevXpd9hzJ6skMqE4/

RFC 7919, "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)", August 2016

Source of RFC: tls (sec)

Errata ID: 4908
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin Thomson
Date Reported: 2017-01-16
Held for Document Update by: Paul Wouters
Date Held: 2024-01-17

Section 4 says:

   If a compatible TLS server receives a Supported Groups extension from
   a client that includes any FFDHE group (i.e., any codepoint between
   256 and 511, inclusive, even if unknown to the server), and if none
   of the client-proposed FFDHE groups are known and acceptable to the
   server, then the server MUST NOT select an FFDHE cipher suite.  In
   this case, the server SHOULD select an acceptable non-FFDHE cipher
   suite from the client's offered list.  If the extension is present
   with FFDHE groups, none of the client's offered groups are acceptable
   by the server, and none of the client's proposed non-FFDHE cipher
   suites are acceptable to the server, the server MUST end the
   connection with a fatal TLS alert of type insufficient_security(71).

It should say:

   If a compatible TLS server receives a Supported Groups extension from
   a client that includes any FFDHE group (i.e., any codepoint between
   256 and 511, inclusive, even if unknown to the server), and if none
   of the client-proposed FFDHE groups are known and acceptable to the
   server, then the server MUST NOT select an FFDHE cipher suite.  In
   this case, the server SHOULD select an acceptable non-FFDHE cipher
   suite from the client's offered list.

Notes:

The text is overly prescriptive about the alert code that needs to used if there are no acceptable cipher suites available. If the server is unable to pick a cipher suite, it can send a handshake_failure(40) alert, which this text would prohibit. handshake_failure is at least equally valid in practice.

This eliminates the prescriptive text about the alert type.

Servers eliminate cipher suites from considerations in numerous ways. Being able to definitively identify the reason as a (perceived) shortcoming in the strength of the offered security is actually quite challenging in practice.

It's true that insufficient_security is perhaps a more desirable code to use in this case, but it's not generically possible to determine that the server configuration is "more secure" than the combinations on offer by the client. Consider also the possibility that it's the server that is insecure because it doesn't some of the options offered by the client. That's a general criticism of the value of insufficient_security, but it should at least motivate why insufficient_security should never be mandated in this way.

Paul Wouters(AD): After discussion with Martin, we propose that the correction required is only the removal of "of type insufficient_security(71).".

As Martin explains:

Having a MUST on this is not appropriate in that sense. What would be acceptable is:

[...] the server terminates the connection according to Section 4.1.1 of [RFC8446].

Of course, that would depend on time travel in the sense that RFC 7919 pre-dates TLS 1.3 by a fair bit and so it can't really refer to it like that.

RFC 7934, "Host Address Availability Recommendations", July 2016

Source of RFC: v6ops (ops)

Errata ID: 4806
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Smith
Date Reported: 2016-09-20
Held for Document Update by: Joel Jaeggli
Date Held: 2017-03-29

Section 3 says:

3.  Benefits of Providing Multiple Addresses

   Today, there are many host functions that require more than one IP
   address to be available to the host, including:

   o  Privacy addressing to prevent tracking by off-network hosts
      [RFC4941].

 ...

It should say:

3.  Benefits of Providing Multiple Addresses

   Today, there are many host functions that require more than one IP
   address to be available to the host, including:

   o  Privacy addressing to prevent tracking by off-network hosts
      [RFC4941].

...

   o  Other potential use cases such as those described in [RFC1681].

Notes:

Somewhat trivial errata, a reference to RFC1681, " On Many Addresses per Host", would be good to credit Steve's early thoughts, and those which probably in part lead to [TARP]. No urgency to update, a note to include it if this RFC is ever updated.

RFC 7938, "Use of BGP for Routing in Large-Scale Data Centers", August 2016

Source of RFC: rtgwg (rtg)

Errata ID: 5477
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Klemens Schragel
Date Reported: 2018-08-24
Held for Document Update by: Martin Vigoureux
Date Held: 2018-11-04

Section 3.2.3 says:

   The small example of topology in Figure 3 is built from devices with
   a port count of 4.  In this document, one set of directly connected
   Tier 2 and Tier 3 devices along with their attached servers will be
   referred to as a "cluster".  For example, DEV A, B, C, D, and the
   servers that connect to DEV A and B, on Figure 3 form a cluster.  The
   concept of a cluster may also be a useful concept as a single
   deployment or maintenance unit that can be operated on at a different
   frequency than the entire topology.

It should say:

   The small example of topology in Figure 3 is built from devices with
   a port count of 4. By introducing an additional Tier the 4-port
   Tier 1 device has still two unused ports to connect further devices,
   therefore scaling from a maximum of 8 servers in a 3-stage Clos to a
   maximum of 16 servers in this 5-stage Clos.
   In this document, one set of directly connected Tier 2 and Tier 3
   devices along with their attached servers will be referred to as a
   "cluster".  For example, DEV A, B, C, D, and the servers that
   connect to DEV A and B, on Figure 3 form a cluster.  The concept of
   a cluster may also be a useful concept as a single deployment or
   maintenance unit that can be operated on at a different frequency
   than the entire topology.

Notes:

Section does not properly describe where the scaling happens, also the depicted topology still connects only 8 servers (the same amount as with a 3-stage Clos). The reader can grasp the scaling only when looking very carefully at the figure.

RFC 7948, "Internet Exchange BGP Route Server Operations", September 2016

Source of RFC: grow (ops)

Errata ID: 5366
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Greg Skinner
Date Reported: 2018-05-23
Held for Document Update by: Warren Kumari (Ops AD)
Date Held: 2018-05-23

Section 6.2 says:

[RS-ARCH]  Govindan, R., Alaettinoglu, C., Varadhan, K., and D.
           Estrin, "A Route Server Architecture for Inter-Domain
           Routing", 1995,
           <http://www.cs.usc.edu/assets/003/83191.pdf>.

It should say:

[RS-ARCH]  Govindan, R., Alaettinoglu, C., Varadhan, K., and D.
           Estrin, "A Route Server Architecture for Inter-Domain
           Routing", 1995,
<https://www.researchgate.net/
publication/
2297181_A_Route_Server_Architecture_for_Inter-Domain_Routing>

Notes:

The paper is no longer accessible from the www.cs.usc.edu site. A related paper can be accessed at https://doi.org/10.1016/S0169-7552(98)00008-7 by those who are registered members or will pay for the paper. It would be cited as:
[RS-ARCH] Govindan, R., Alaettinoglu, C., Varadhan, K., and D.
Estrin, "A Route Server Architecture for Inter-Domain
Routing", Computer Networks and ISDN Systems, Volume 30,
Issue 12, 13 July 1998, Pages 1157-1174,
<https://doi.org/10.1016/S0169-7552(98)00008-7>.

Sorry, I had to split the link in the corrected text to satisfy the 72-character line length requirement in the corrected text.

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.

RFC 7959, "Block-Wise Transfers in the Constrained Application Protocol (CoAP)", August 2016

Note: This RFC has been updated by RFC 8323

Source of RFC: core (wit)

Errata ID: 6083
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mohamed Boucadair
Date Reported: 2020-04-09
Held for Document Update by: Barry Leiba
Date Held: 2020-04-10

Section 2.1 says:

       +-----+---+---+---+---+--------+--------+--------+---------+
       | No. | C | U | N | R | Name   | Format | Length | Default |
       +-----+---+---+---+---+--------+--------+--------+---------+
       |  23 | C | U | - | - | Block2 | uint   |    0-3 | (none)  |
       |     |   |   |   |   |        |        |        |         |
       |  27 | C | U | - | - | Block1 | uint   |    0-3 | (none)  |
       +-----+---+---+---+---+--------+--------+--------+---------+

                       Table 1: Block Option Numbers

It should say:

       +-----+---+---+---+---+--------+--------+--------+---------+
       | No. | C | U | N | R | Name   | Format | Length | Default |
       +-----+---+---+---+---+--------+--------+--------+---------+
       |  23 | x | x | - |   | Block2 | uint   |    0-3 | (none)  |
       |     |   |   |   |   |        |        |        |         |
       |  27 | x | x | - |   | Block1 | uint   |    0-3 | (none)  |
       +-----+---+---+---+---+--------+--------+--------+---------+

                       Table 1: Block Option Numbers

Notes:

* This is to align with the conventions in Section 5.10 of RFC7252
* These options are not repeatable as per:

"Either Block option MUST NOT occur more than once in a
single message."

RFC 7991, "The "xml2rfc" Version 3 Vocabulary", December 2016

Source of RFC: IAB

Errata ID: 4906
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2017-01-15
Held for Document Update by: Robert Sparks
Date Held: 2018-02-09

Section Appendix C says:

   artwork =
     element artwork {
       attribute xml:base { text }?,
       attribute xml:lang { text }?,
       attribute anchor { xsd:ID }?,
       attribute pn { text }?,
       attribute xml:space { text }?,
       [ a:defaultValue = "" ] attribute name { text }?,
       [ a:defaultValue = "" ] attribute type { text }?,
       attribute src { text }?,
       [ a:defaultValue = "left" ]
       attribute align { "left" | "center" | "right" }?,
       [ a:defaultValue = "" ] attribute alt { text }?,
       [ a:defaultValue = "" ] attribute width { text }?,
       [ a:defaultValue = "" ] attribute height { text }?,
       attribute originalSrc { text }?,
       (text* | svg)
     }
   # https://www.rfc-editor.org/materials/format/SVG-1.2-RFC.rnc

It should say:

   artwork =
     element artwork {
       attribute xml:base { text }?,
       attribute xml:lang { text }?,
       attribute anchor { xsd:ID }?,
       attribute pn { text }?,
       attribute xml:space { text }?,
       [ a:defaultValue = "" ] attribute name { text }?,
       [ a:defaultValue = "" ] attribute type { text }?,
       attribute src { text }?,
       [ a:defaultValue = "left" ]
       attribute align { "left" | "center" | "right" }?,
       [ a:defaultValue = "" ] attribute alt { text }?,
       [ a:defaultValue = "" ] attribute width { text }?,
       [ a:defaultValue = "" ] attribute height { text }?,
       attribute originalSrc { text }?,
       (text* | svg)
     }

   include "https://www.rfc-editor.org/materials/format/SVG-1.2-RFC.rnc"

Notes:

Without actually including the SVG RNC grammar, *this* grammar is incomplete.

(Note that when this is applied, Appendix D, if still present, would need to be adjusted as well)

Errata ID: 4904
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2017-01-15
Held for Document Update by: Robert Sparks
Date Held: 2018-02-09

Section 2.25.2 says:

   Deprecated.  If the goal is to provide a single URI for a reference,
   use the "target" attribute in <reference> instead.

Notes:

This text doesn't make any sense, as the purpose for "alt" is something entirely different. The reason why it really was deprecated will have to be included here.

Errata ID: 4905
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2017-01-15
Held for Document Update by: Robert Sparks
Date Held: 2018-02-09

Section 9.1 says:

   [BCP14]    Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/bcp14>.

It should say:

   [BCP14]    Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              March 1997,
              <http://www.rfc-editor.org/info/bcp14>.

Notes:

BCP14 (as opposed to RFC 2119) doesn't have a DOI, thus it shouldn't be listed here.

RFC 7997, "The Use of Non-ASCII Characters in RFCs", December 2016

Source of RFC: IAB

Errata ID: 6032
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2020-03-29
Held for Document Update by: John Levine
Date Held: 2020-12-08

Section 3.4 says:

1.  Temperature changes in the Temperature Control Protocol are
    indicated by the U+2206 character ("Δ").

It should say:

1.  Temperature changes in the Temperature Control Protocol are
    indicated by the U+2206 character ("∆").

Notes:

This applies to the PDF version only (https://www.rfc-editor.org/rfc/rfc7997.pdf); the issue is repeated in the following lines.

The character on display is 'GREEK CAPITAL LETTER DELTA' (U+0394), not 'INCREMENT' (U+2206).

(found by Henrik Levkowetz, see https://github.com/rfc-format/draft-iab-rfc-nonascii-bis/issues/4#issuecomment-605623783)

This was marked "Held For Document Update" per discussion with the Temporary RFC Series Project Manager (John Levine).

RFC 8013, "Forwarding and Control Element Separation (ForCES) Inter-FE Logical Functional Block (LFB)", February 2017

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rtg

Errata ID: 5358
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2018-05-13
Held for Document Update by: Alvaro Retana
Date Held: 2020-07-21

Section 6.1 says:

   The inter-FE LFB (instance) can be positioned at the ingress of a
   receiving FE.  Figure 5 illustrates an example destination FE in the
   form of FE1.  In such a case, an inter-FE LFB receives, via an LFB
   port in the IngressInGroup, an encapsulated Ethernet frame.
   Successful processing of the packet will result in a raw packet with
   associated metadata IDs going downstream to an LFB connected on OUT2.
   On failure, the data is sent out EXCEPTIONOUT.

It should say:

   The inter-FE LFB (instance) can be positioned at the ingress of a
   receiving FE.  Figure 5 illustrates an example destination FE in the
   form of FE2.  In such a case, an inter-FE LFB receives, via an LFB
   port in the IngressInGroup, an encapsulated Ethernet frame.
   Successful processing of the packet will result in a raw packet with
   associated metadata IDs going downstream to an LFB connected on OUT2.
   On failure, the data is sent out EXCEPTIONOUT.

Notes:

Destination FE is FE2 not FE1.

RFC 8017, "PKCS #1: RSA Cryptography Specifications Version 2.2", November 2016

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 5576
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dave Thompson
Date Reported: 2018-12-16
Held for Document Update by: Benjamin Kaduk
Date Held: 2019-01-05

Section B.1 says:

   The object identifiers id-md2, id-md5, id-sha1, id-sha224, id-sha256,
   id-sha384, id-sha512, id-sha512/224, and id-sha512/256 identify the
   respective hash functions:
...
   The parameters field associated with id-sha1, id-sha224, id-sha256,
   id-sha384, id-sha512, id-sha512/224, and id-sha512/256 should
...
   Exception: When formatting the DigestInfoValue in EMSA-PKCS1-v1_5
   (see Section 9.2), the parameters field associated with id-sha1,
   id-sha224, id-sha256, id-sha384, id-sha512, id-sha512/224, and
   id-sha512/256 shall have a value of type NULL.  This is to maintain

It should say:

   The object identifiers id-md2, id-md5, id-sha1, id-sha224, id-sha256,
   id-sha384, id-sha512, id-sha512-224, and id-sha512-256 identify the
   respective hash functions:
...
   The parameters field associated with id-sha1, id-sha224, id-sha256,
   id-sha384, id-sha512, id-sha512-224, and id-sha512-256 should
...
   Exception: When formatting the DigestInfoValue in EMSA-PKCS1-v1_5
   (see Section 9.2), the parameters field associated with id-sha1,
   id-sha224, id-sha256, id-sha384, id-sha512, id-sha512-224, and
   id-sha512-256 shall have a value of type NULL.  This is to maintain

Notes:

ASN.1 identifiers don't allow slash. The actual ASN.1 code in the middle of B.1, and the ASN.1 module in C, correctly use hyphens for id-sha512-224 and id-sha512-256.

RFC 8020, "NXDOMAIN: There Really Is Nothing Underneath", November 2016

Source of RFC: dnsop (ops)

Errata ID: 6079
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ángel
Date Reported: 2020-04-07
Held for Document Update by: Warren Kumari (Ops AD)
Date Held: 2020-04-07

Section 8.2 says:

   [balakrichenan-dafa888]
              Balakrichenan, S., "Disturbance in the DNS - "Random
              qnames", the dafa888 DoS attack"", October 2014,
              <https://indico.dns-oarc.net/event/20/session/3/contribution/3>.

It should say:

   [balakrichenan-dafa888]
              Balakrichenan, S., "Disturbance in the DNS - "Random
              qnames", the dafa888 DoS attack"", October 2014,
              <https://indico.dns-oarc.net/event/20/contributions/278/>.

Notes:

The url for [balakrichenan-dafa888] returns «Not Found The page you are looking for doesn't exist.», and seems to have done so for some time: https://web.archive.org/web/20180615000000*/https://indico.dns-oarc.net/event/20/session/3/contribution/3/

The referenced content was found at https://indico.dns-oarc.net/event/20/contributions/278/

RFC 8029, "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures", March 2017

Note: This RFC has been updated by RFC 8611, RFC 9041

Source of RFC: mpls (rtg)

Errata ID: 5102
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alexander Okonnikov
Date Reported: 2017-08-30
Held for Document Update by: Deborah Brungard
Date Held: 2017-12-12

Section 3.2.5 says:

   VPN-IPv4 Network Layer Routing Information (NLRI) is defined in
   [RFC4365].

It should say:

   VPN-IPv4 Network Layer Routing Information (NLRI) is defined in
   [RFC4364].

Notes:

Incorrect reference.

Errata ID: 5103
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alexander Okonnikov
Date Reported: 2017-08-30
Held for Document Update by: Deborah Brungard
Date Held: 2017-12-12

Section 3.2.6 says:

   VPN-IPv6 NLRI is defined in [RFC4365].

It should say:

   VPN-IPv6 NLRI is defined in [RFC4659].

Notes:

Incorrect reference.

RFC 8031, "Curve25519 and Curve448 for the Internet Key Exchange Protocol Version 2 (IKEv2) Key Agreement", December 2016

Source of RFC: ipsecme (sec)

Errata ID: 6931
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Christian Tschudin
Date Reported: 2020-11-17
Held for Document Update by: Paul Wouters
Date Held: 2023-07-28

Section Global says:

Notes:

A discrepancy came to my attention when testing the Yubikey 5 hardware and comparing it with the NaCl library and RFC8031. While the NaCl library works as expected, it is disturbing to see that the Yubikey can only be made to produce the desired (above and corrected) shared secret if you let it compute X25519(fixed_i,pub_r). That is, the secret must be presented to the Yubikey in big-endian format which could be "inspired" by the (not very detailed) Smartcard spec 3.4.1 that refers to ANSI X9.62 where curve parameters, prefixed with 0x04, are encoded in big-endian order - clearly the ANSI encoding is not useful here as we only need one parameter u. I wonder whether RFC8031 should spell out that input parameters (d_X and pub_X) SHOULD be presented in encoded form (and thus little-endian), hence putting manufacturers in charge of documenting any deviation.

RFC 8032, "Edwards-Curve Digital Signature Algorithm (EdDSA)", January 2017

Source of RFC: IRTF

Errata ID: 5758
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Franck Rondepierre
Date Reported: 2019-06-21
Held for Document Update by: Stanislav Smyshlyaev
Date Held: 2022-02-15

Section 5.1. says:

                          (p+3)/8      3        (p-5)/8
                 x = (u/v)        = u v  (u v^7)         (mod p)

It should say:

                          (p+3)/8          (p-5)/8
                 x = (u/v)        = u (u v)         (mod p)

Notes:

--VERIFIER NOTES--
The original text was correct (verified by Nick Sullivan).
01/28/2022: RFC Editor changed status to Reported per discussion with Stanislav V. Smyshlyaev.
02/15/2022: The status is changed to "Held for Document Update" by Stanislav Smyshlyaev. The proposed formulas are correct as well (for the specific case of the EdDSA parameters) and provide a slight efficiency gain.

Errata ID: 5759
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Franck Rondepierre
Date Reported: 2019-06-21
Held for Document Update by: Stanislav Smyshlyaev
Date Held: 2022-02-15

Section 5.2. says:

                          (p+1)/4    3            (p-3)/4
                 x = (u/v)        = u  v (u^5 v^3)         (mod p)

It should say:

                          (p+1)/4            (p-3)/4
                 x = (u/v)        =  u (u v)         (mod p)

Notes:

--VERIFIER NOTES--
The original text was correct (verified by Nick Sullivan).
01/28/2022: RFC Editor changed status to Reported per discussion with Stanislav V. Smyshlyaev.
02/15/2022: The status is changed to "Held for Document Update" by Stanislav Smyshlyaev. The proposed formulas are correct as well (for the specific case of the EdDSA parameters) and provide a slight efficiency gain.

RFC 8033, "Proportional Integral Controller Enhanced (PIE): A Lightweight Control Scheme to Address the Bufferbloat Problem", February 2017

Source of RFC: aqm (tsv)

Errata ID: 7108
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Greg White
Date Reported: 2022-08-31
Held for Document Update by: Martin Duke
Date Held: 2024-01-18

Section 5.1 & 10.2 says:

5.1.  ECN Support

   PIE MAY support ECN by marking (rather than dropping) ECN-capable
   packets [ECN].  ...

...



10.2.  Informative References
...

   [ECN]      Briscoe, B., Kaippallimalil, J., and P. Thaler,
              "Guidelines for Adding Congestion Notification to
              Protocols that Encapsulate IP", Work in Progress,
              draft-ietf-tsvwg-ecn-encap-guidelines-07, July 2016.
...

It should say:

5.1.  ECN Support

   PIE MAY support ECN by marking (rather than dropping) ECN-capable
   packets [RFC3168].  ...

...



10.2.  Informative References
...

   [RFC3168]      Ramakrishnan, K., Floyd, S., and D. Black, 
                  "The Addition of Explicit Congestion Notification 
                  (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, 
                  September 2001, <https://www.rfc-editor.org/info/rfc3168>.
...

Notes:

The reference provided for ECN points to the incorrect IETF document.

RFC 8040, "RESTCONF Protocol", January 2017

Note: This RFC has been updated by RFC 8527

Source of RFC: netconf (ops)

Errata ID: 5493
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Qin Wu
Date Reported: 2018-09-06
Held for Document Update by: Ignas Bagdonas
Date Held: 2019-10-22

Section 6 says:

Note that the YANG definitions within this module do not
represent configuration data of any kind.
The 'restconf-media-type' YANG extension statement
provides a normative syntax for XML and JSON
message-encoding purposes.

It should say:

Note that the YANG definitions within this module do not
represent configuration data of any kind.
The yang-data extension statement
provides a normative syntax for XML and JSON
message-encoding purposes.

Notes:

The 'restconf-media-type' YANG extension has been replaced by more generic yang-data extension.

Errata ID: 5633
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Qin WU
Date Reported: 2019-02-11
Held for Document Update by: Ignas Bagdonas
Date Held: 2019-10-22

Section B.2.2. says:

      PATCH /restconf/data/example-jukebox:jukebox/\
          library/artist=Foo%20Fighters/album=Wasting%20Light/\
          genre HTTP/1.1
      Host: example.com
      If-Unmodified-Since: Thu, 26 Jan 2017 20:56:30 GMT
      Content-Type: application/yang-data+json

      { "example-jukebox:genre" : "example-jukebox:alternative" }

   In this example, the datastore resource has changed since the time
   specified in the "If-Unmodified-Since" header.  The server might
   respond as follows:

      HTTP/1.1 412 Precondition Failed
      Date: Thu, 26 Jan 2017 20:56:30 GMT
      Server: example-server
      Last-Modified: Thu, 26 Jan 2017 19:41:00 GMT
      ETag: "b34aed893a4c"

It should say:

      PATCH /restconf/data/example-jukebox:jukebox/\
          library/artist=Foo%20Fighters/album=Wasting%20Light/\
          genre HTTP/1.1
      Host: example.com
      If-Unmodified-Since: Thu, 26 Jan 2017 20:56:30 GMT
      Content-Type: application/yang-data+json

      { "example-jukebox:genre" : "example-jukebox:alternative" }

   In this example, the datastore resource has changed since the time
   specified in the "If-Unmodified-Since" header.  The server might
   respond as follows:

      HTTP/1.1 412 Precondition Failed
      Date: Thu, 26 Jan 2017 20:56:30 GMT
      Server: example-server
      Last-Modified: Thu, 26 Jan 2017 20:57:10 GMT
      ETag: "b34aed893a4c"

Notes:

The date in the Last-Modified field of the response HTTP header should be greater than the date in the If-Unmodified-Since field of the request HTTP header.

RFC 8092, "BGP Large Communities Attribute", February 2017

Source of RFC: idr (rtg)

Errata ID: 4962
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2017-03-09
Held for Document Update by: Alvaro Retana
Date Held: 2017-03-25

Section 3 says:

   Duplicate BGP Large Community values MUST NOT be transmitted.  A
   receiving speaker MUST silently remove redundant BGP Large Community
   values from a BGP Large Community attribute.

It should say:

   Duplicate BGP Large Community values MUST NOT be transmitted.  A
   receiving speaker MUST silently remove redundant BGP Large Community
   values from a BGP Large Communities attribute.

Notes:

Typo
====
There are two mote instances where the name of the attribute is also mentioned as "BGP Large Community attribute", and not "BGP Large Communities Attribute” as defined in Section 3.

I am changing the status to "Held for Document Update", which means that "The erratum is not a necessary update to the RFC. However, any future update of the document might consider this erratum, and determine whether it is correct and merits including in the update." [1]

- Alvaro.
[1] https://www.ietf.org/iesg/statement/errata-processing.html

RFC 8126, "Guidelines for Writing an IANA Considerations Section in RFCs", June 2017

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 5772
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2019-07-03
Held for Document Update by: Barry Leiba
Date Held: 2019-07-03

Throughout the document, when it says:

   Jon Postel and Joyce Reynolds provided a detailed explanation on what
   IANA needs in order to manage assignments efficiently, and patiently
   provided comments on multiple versions of this document.  Brian
   Carpenter provided helpful comments on earlier versions of the
   document.  One paragraph in the Security Considerations section was
   borrowed from RFC 4288.

It should say:

   Jon Postel and Joyce Reynolds provided a detailed explanation on what
   IANA needs in order to manage assignments efficiently, and patiently
   provided comments on multiple versions of this document.  Brian
   Carpenter provided helpful comments on earlier versions of the
   document.  One paragraph in the Security Considerations section was
   borrowed from RFC 2048.

Notes:

Incorrect reference in ¨Acknowledgments from the First Edition (1998)¨, p. 46

RFC 8138, "IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header", April 2017

Note: This RFC has been updated by RFC 9008, RFC 9035

Source of RFC: roll (rtg)

Errata ID: 5403
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yasuyuki Tanaka
Date Reported: 2018-06-21
Held for Document Update by: Alvaro Retana
Date Held: 2018-11-04

Section 5.2.3. says:

This is encoded as S/DAC = 1 and S/AM=11.

It should say:

This is encoded as S/DAC = 1 and S/DAM=11.

Notes:

The corrected part refers to SAM and DAM defined in Section 3.1.1 of RFC 6282 (https://tools.ietf.org/html/rfc6282#section-3.1.1)

RFC 8140, "The Arte of ASCII: Or, An True and Accurate Representation of an Menagerie of Thynges Fabulous and Wonderful in Ye Forme of Character", April 2017

Source of RFC: INDEPENDENT

Errata ID: 5317
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Martin Thomson
Date Reported: 2018-04-02
Held for Document Update by: Adrian Farrel
Date Held: 2018-04-08

Section 2.2 says:

as they are sometimes know).

It should say:

as they are sometimes known).

RFC 8152, "CBOR Object Signing and Encryption (COSE)", July 2017

Note: This RFC has been obsoleted by RFC 9052, RFC 9053

Source of RFC: cose (sec)

Errata ID: 5533
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jian Huang
Date Reported: 2018-10-18
Held for Document Update by: Benjamin Kaduk
Date Held: 2018-10-19

Section 3.1 says:

   alg:  This parameter is used to indicate the algorithm used for the
      security processing.  This parameter MUST be authenticated where
      the ability to do so exists.  This support is provided by AEAD
      algorithms or construction (COSE_Sign, COSE_Sign0, COSE_Mac, and
      COSE_Mac0).

It should say:

   alg:  This parameter is used to indicate the algorithm used for the
      security processing.  This parameter MUST be authenticated where
      the ability to do so exists.  This support is provided by AEAD
      algorithms or construction (COSE_Sign, COSE_Sign1, COSE_Mac, and
      COSE_Mac0).

Notes:

COSE_Sign0 is only mentioned once in the document, but COSE_Sign1 appears many times.

RFC 8164, "Opportunistic Security for HTTP/2", May 2017

Source of RFC: httpbis (wit)

Errata ID: 5023
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Xiaoyin Liu
Date Reported: 2017-05-19
Held for Document Update by: Alexey Melnikov
Date Held: 2017-10-18

Section Abstract says:

This mechanism not a replacement for "https"
URIs; it is vulnerable to active attacks.

It should say:

This mechanism is not a replacement for "https"
URIs; it is vulnerable to active attacks.

Notes:

This sentence is in the Abstract. It misses the verb "is".

Alexey: This is correct, but it is unlikely to confuse readers.

Errata ID: 5490
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Steven Meixner
Date Reported: 2018-09-04
Held for Document Update by: Francesca Palombini
Date Held: 2022-11-09

Section 2 says:

in order minimize the delays that might be incurred.

It should say:

in order to minimize the delays that might be incurred.

Notes:

Grammar only.

RFC 8174, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", May 2017

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 5022
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Xiaoyin Liu
Date Reported: 2017-05-19
Held for Document Update by: Ben Campbell
Date Held: 2017-05-22

Throughout the document, when it says:

by clarifying that only UPPERCASE usage of the key words have the
defined special meanings.

It should say:

by clarifying that only UPPERCASE usage of the key words has the
defined special meanings.

Notes:

The text appears in both "Abstract" and Section 1. The verb should be "has" because "usage" is a singular noun.

RFC 8180, "Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration", May 2017

Source of RFC: 6tisch (int)

Errata ID: 5539
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yasuyuki Tanaka
Date Reported: 2018-10-29
Held for Document Update by: Erik Kline
Date Held: 2022-01-13

Section 5 says:

(...)

   The Rank computation is described in Section 4.1 of [RFC6552].  A
   node's Rank (see Figure 4 for an example) is computed by the
   following equations:

      R(N) = R(P) + rank_increment

      rank_increment = (Rf*Sp + Sr) * MinHopRankIncrease

(...)

   This section illustrates the use of OF0 (see Figure 4).  We have:

      rank_increment = ((3*numTx/numTxAck)-2)*minHopRankIncrease = 512

It should say:

(...)

   The Rank computation is described in Section 4.1 of [RFC6552].  A
   node's Rank (see Figure 4 for an example) is computed by the
   following equations:

      R(N) = R(P) + rank_increase

      rank_increase = (Rf*Sp + Sr) * MinHopRankIncrease

(...)

   This section illustrates the use of OF0 (see Figure 4).  We have:

      rank_increase = ((3*numTx/numTxAck)-2)*minHopRankIncrease = 512

Notes:

s/rank_increment/rank_increase/

It'd be better to use "rank_increase" as the variable name for consistency, which is used in Section 4.1 of RFC 6552 (https://tools.ietf.org/html/rfc6552#section-4.1):

[excerpt from RFC 6552]

The step_of_rank Sp that is computed for that link is multiplied by
the rank_factor Rf and then possibly stretched by a term Sr that is
less than or equal to the configured stretch_of_rank. The resulting
rank_increase is added to the Rank of preferred parent R(P) to obtain
that of this node R(N):

R(N) = R(P) + rank_increase where:

rank_increase = (Rf*Sp + Sr) * MinHopRankIncrease

RFC 8182, "The RPKI Repository Delta Protocol (RRDP)", July 2017

Source of RFC: sidr (rtg)

Errata ID: 6919
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Ties de Kock
Date Reported: 2022-04-04
Held for Document Update by: Alvaro Retana
Date Held: 2022-04-18

Section 3.4.2 says:

   o  When a Relying Party encounters a "withdraw" element, or a
      "publish" element where an object is replaced, in a delta that it
      retrieves from a Repository Server, it MUST verify that the object
      to be withdrawn or replaced was retrieved from this same
      Repository Server before applying the appropriate action.  Failing
      to do so will leave the Relying Party vulnerable to malicious
      Repository Servers instructing it to delete or change arbitrary
      objects.

It should say:

   o  When a Relying Party encounters a "withdraw" element, or a
      "publish" element where an object is replaced, in a delta that it
      retrieves from a Repository Server, it MUST verify that the object
      to be withdrawn or replaced was retrieved from this same
      Repository Server before applying the appropriate action.  Failing
      to do so will leave the Relying Party vulnerable to malicious
      Repository Servers instructing it to delete or change arbitrary
      objects.

   o  For a "publish" or "withdraw" element, the hash MUST be present
      if the publication operation is overwriting an existing object,
      and it MUST NOT be present if this publication operation is writing
      to a new URI where no prior object exists.  Presence of an object
      when no "hash" attribute has been specified is an error, as is
      absence of an object or an incorrect hash value when a "hash"
      attribute has been specified. In this situation this file MUST be
      rejected.

Notes:

Text taken from RFC8181. For <publish> elements in RRDP deltas, the same process described in RFC8181 applies; "the hash of a publish MUST match to overwrite the existing file"

(This gap in the specification was independently spotted by C.J. around the same time)

RFC 8188, "Encrypted Content-Encoding for HTTP", June 2017

Source of RFC: httpbis (wit)

Errata ID: 5516
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Dolan Murvihill
Date Reported: 2018-10-05
Held for Document Update by: Francesca Palombini
Date Held: 2022-11-09

Section 3.1 says:

HTTP/1.1 200 OK
Content-Type: application/octet-stream
Content-Length: 54
Content-Encoding: aes128gcm

I1BsxtFttlv3u_Oo94xnmwAAEAAA-NAVub2qFgBEuQKRapoZu-IxkIva3MEB1PD-
ly8Thjg

It should say:

HTTP/1.1 200 OK
Content-Type: application/octet-stream
Content-Length: 53
Content-Encoding: aes128gcm

I1BsxtFttlv3u_Oo94xnmwAAEAAA-NAVub2qFgBEuQKRapoZu-IxkIva3MEB1PD-
ly8Thjg

Notes:

16-bit encrypted payload
16-bit authentication tag
21-bit header

The other example, in Section 3.2, reports the correct content length of 53

RFC 8199, "YANG Module Classification", July 2017

Source of RFC: netmod (ops)

Errata ID: 5924
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mohamed Boucadair
Date Reported: 2019-12-02
Held for Document Update by: Warren Kumari (Ops AD)
Date Held: 2020-01-05

Section Section 6.1 says:

6.1.  Normative References

...

   [RFC8049]  Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data
              Model for L3VPN Service Delivery", RFC 8049,
              DOI 10.17487/RFC8049, February 2017,
              <http://www.rfc-editor.org/info/rfc8049>.

It should say:

6.1.  Informative References

...

   [RFC8049]  Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data
              Model for L3VPN Service Delivery", RFC 8049,
              DOI 10.17487/RFC8049, February 2017,
              <http://www.rfc-editor.org/info/rfc8049>.

Notes:

RFC8049 is cited only as an example (Section 2.1):

"An example of a Network Service YANG Module is in [RFC8049]..."

Not sure why it was listed as normative.

[Warren Kumari: Thanks to Benoit and Joel for review. ]

RFC 8200, "Internet Protocol, Version 6 (IPv6) Specification", July 2017

Source of RFC: 6man (int)

Errata ID: 5933
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Fernando Gont
Date Reported: 2019-12-11
Held for Document Update by: Suresh Krishnan
Date Held: 2020-03-02

Section 4 says:

   Extension headers (except for the Hop-by-Hop Options header) are not
   processed, inserted, or deleted by any node along a packet's delivery
   path, until the packet reaches the node (or each of the set of nodes,
   in the case of multicast) identified in the Destination Address field
   of the IPv6 header.

   The Hop-by-Hop Options header is not inserted or deleted, but may be
   examined or processed by any node along a packet's delivery path,
   until the packet reaches the node (or each of the set of nodes, in
   the case of multicast) identified in the Destination Address field of
   the IPv6 header.  The Hop-by-Hop Options header, when present, must
   immediately follow the IPv6 header.  Its presence is indicated by the
   value zero in the Next Header field of the IPv6 header.

It should say:

   Extension headers (except for the Hop-by-Hop Options header, or a 
   Destination Options header preceding a Routing header) are not processed,
   inserted, or deleted by any node along a packet's delivery path, until the
   packet reaches the final destination node (or each of the set of final
   destination nodes, in the case of multicast). 

   For packets that do not include a Routing Header, the final destination
   node is identified by the Destination Address field of the IPv6 header. 
   For packets that include a Routing Header, the final destination node is 
   identified by the Destination Address field of the IPv6 header only when
   the Segments Left field of the Routing Header is 0. 

   The Hop-by-Hop Options header is not inserted or deleted, but may be
   examined or processed by any node along a packet's delivery path,
   until the packet reaches the final destination node (or each of the set of
   final destination nodes, in the case of multicast). The Hop-by-Hop Options 
   header, when present, must immediately follow the IPv6 header.  Its 
   presence is indicated by the value zero in the Next Header field of the 
   IPv6 header.

   A Destination Options header preceding a Routing Header is not
   processed, inserted, or deleted by any node along a packet's delivery
   path, until the packet reaches the destination node (or each of the set 
   of destination nodes, in the case of multicast) identified by the 
   Destination Address field of the IPv6 header. This means that  a 
   Destination Options header preceding a Routing Header will be
   processed by the first destination of the packet (specified by the
   Destination Address field of the IPv6 header at the origin node) and by 
   each node listed in the Routing Header.

Notes:

This errata clarifies two different issues:

* It clarifies that nodes other than the final destination do not insert o remove extension headers.

* It clarifies that the Destination Options header preceding a routing header *is* processed along the
packet delivery's path, but the node(s) identified by the Destination Address of the IPv6 header.

Area Director's Note (Suresh Krishnan):

I am handling this based on the IESG Statement about processing of RFC Errata for the IETF Stream (https://ietf.org/about/groups/iesg/statements/processing-rfc-errata/)

"Changes that modify the working of a protocol to something that might be different from the intended consensus when the document was approved should be either Hold for Document Update or Rejected. Deciding between these two depends on judgment. Changes that are clearly modifications to the intended consensus, or involve large textual changes, should be Rejected."

Some people might interpret the text in RFC8200 to mean the replacement text provided above in the erratum but others might read the text exactly as written ("until the packet reaches the node identified in the Destination Address field of the IPv6 header”). Given that the text in RFC8200 had consensus and it is impossible to tell after the fact if the proposed replacement text would have achieved consensus, I believe this erratum falls under the above category.

The change proposed by this erratum has to be evaluated for correctness and consensus if and when there is an update of RFC8200.

Errata ID: 5259
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2018-02-08
Held for Document Update by: Suresh Krishnan
Date Held: 2020-02-03

Section Appendix B says:

      -  Updated the Fragmentation header text to correct the inclusion
         of an Authentication Header (AH) and noted No Next Header case.

It should say:

      -  Updated the Fragment header text to correct the inclusion
         of an Authentication Header (AH) and noted No Next Header case.

Notes:

Typo

Errata ID: 5506
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: jiangmaoyong
Date Reported: 2018-09-27
Held for Document Update by: Suresh Krishnan
Date Held: 2020-02-03

Section Appendix B. says:

      -  Updated the Fragmentation header text to correct the inclusion
         of an Authentication Header (AH) and noted No Next Header case.

It should say:

      -  Updated the Fragmentation header text to correct the inclusion
         the Encapsulating Security Payload (ESP)  and noted No Next 
         Header case.

Notes:

The Extension headers are all other extension headers that are not
included in the Per-Fragment headers part of the packet. For this
purpose, the Encapsulating Security Payload (ESP) is not
considered an extension header. The Upper-Layer header is the
first upper-layer header that is not an IPv6 extension header.
Examples of upper-layer headers include TCP, UDP, IPv4, IPv6,
ICMPv6, and as noted ESP.

The Fragmentable Part consists of the rest of the packet after the
upper-layer header or after any header (i.e., initial IPv6 header
or extension header) that contains a Next Header value of No Next
Header.

RFC 8214, "Virtual Private Wire Service Support in Ethernet VPN", August 2017

Source of RFC: bess (rtg)

Errata ID: 7837
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexander ("Sasha") Vainshtein
Date Reported: 2024-03-05
Held for Document Update by: John Scudder
Date Held: 2024-03-07

Section 3.1 says:

This document defines a new extended community [RFC4360], to be included with per-EVI Ethernet A-D routes.  This attribute is mandatory if multihoming is enabled.

It should say:

This document defines a new extended community [RFC4360], to be included with per-EVI Ethernet A-D routes.  

If multihoming is enabled, this attribute is MANDATORY regardless of whether the per-EVI Ethernet A-D route is advertised by an EVPN-VPWS instance or by a "bridging" EVPN instance.

Notes:

The lower-case "mandatory" used in the original text does not represent any form of requirement in IETF documents, therefore replacing with upper-case "MANDATORY" is needed.

The reference to per-EVI Ethernet A-D routes advertised by both "bridging" EVPN and EVPN-VPWS is needed to remove possible doubts about the scope of this requirement since the standard is about EVPN-VPWS.

--
Verifier note: see also https://mailarchive.ietf.org/arch/msg/bess/vBYU98CJkLvHfvnX_6wIsV2cCFM/

RFC 8224, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", February 2018

Note: This RFC has been updated by RFC 8946

Source of RFC: stir (art)

Errata ID: 6519
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Roman Shpount
Date Reported: 2021-04-06
Held for Document Update by: Murray Kucherawy
Date Held: 2023-03-29

Section 4 says:

ident-type = "ppt" EQUAL token

It should say:

ident-type = "ppt" EQUAL DQUOTE token DQUOTE

Notes:

Based on IETF 101 STIR notes ptr= values should always be quoted. Also, ATIS-1000074 is using double quotes around ppt value.

[AD note] See the minutes of the STIR WG at IETF 116, and https://datatracker.ietf.org/doc/minutes-interim-2021-stir-01-202104141600/.

RFC 8229, "TCP Encapsulation of IKE and IPsec Packets", August 2017

Note: This RFC has been obsoleted by RFC 9329

Source of RFC: ipsecme (sec)

Errata ID: 5320
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Valery Smyslov
Date Reported: 2018-04-09
Held for Document Update by: Paul Wouters
Date Held: 2022-04-11

Throughout the document, when it says:

It should say:

TCP provides reliable transport, so there is no need for applications 
to deal with retransmissions. Moreover, sending retransmissions by IKE 
in case of TCP on congested networks could further increase congestion 
and degrade performance. For this reason IKE initiators SHOULD NOT 
retransmit requests if they are sent over TCP. However, both IKE 
initiators and responders MUST correctly handle retransmitted messages 
received over TCP, but responders SHOULD NOT resend response messages 
in this case. If IKE initiators still choose to retransmit requests 
over TCP, then the retransmission policy SHOULD be less aggressive than 
it would have been in case of UDP.

Notes:

While Section 12.2 discusses some implications that TCP transport could have on ESP protocol, the IKE retransmission behavior, described in Section 2.1 of RFC7296, is not redefined by this RFC. This is an oversight and some recommendations for implementers should have been given. The suggested text should be placed in a new section, presumably between sections 8 and 9.

Paul Wouters:

The reported of this errata is writing a bis draft for this document where this is indeed already clarified.
See https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-rfc8229bis-05#section-7.2

Resolving as Held for Document Update

RFC 8231, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", September 2017

Note: This RFC has been updated by RFC 8786, RFC 9353

Source of RFC: pce (rtg)

Errata ID: 5796
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Hillol
Date Reported: 2019-07-29
Held for Document Update by: Deborah Brungard
Date Held: 2020-07-13

Section 7.3.3 says:

               Value      Description
               -----      -------------------------------------
                 1        Unknown reason
                 2        Limit reached for PCE-controlled LSPs
                 3        Too many pending LSP Update Requests
                 4        Unacceptable parameters
                 5        Internal error
                 6        LSP administratively brought down
                 7        LSP preempted
                 8        RSVP signaling error

It should say:

Remove Value 2
 2        Limit reached for PCE-controlled LSPs

Notes:

Value 2 "Limit reached for PCE-controlled LSPs" can occur when an PC update message comes for either PCInitiated or PCDelegated LSP. But since the lsp is already created or delegated, it means the resource is available and allocated. Also RFC 8281 (section 5.3) states that if LSP provisioned exceeds the limit, an LSP error message should be sent with Error-type=19 (Invalid Operation) and
Error-value=6 (PCE-initiated LSP limit reached). So, I believe there is no scenario where LSP Error code TLV "Limit reached for PCE-controlled LSPs" would be used.
Please let me know if there is some scenario which can trigger the same.

RFC 8233, "Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs)", September 2017

Source of RFC: pce (rtg)

Errata ID: 5389
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: DHRUV DHODY
Date Reported: 2018-06-13
Held for Document Update by: Deborah Brungard
Date Held: 2018-06-13

Section 3.1 says:

The METRIC object is defined in Section 7.8 of [RFC5440], comprising
metric-value and metric-type (T field), and a flags field, comprising
a number of bit flags (B bit and P bit).  This document defines the
following types for the METRIC object.

It should say:

The METRIC object is defined in Section 7.8 of [RFC5440], comprising
metric-value and metric-type (T field), and a flags field, comprising
a number of bit flags (B bit and C bit).  This document defines the
following types for the METRIC object.

Notes:

The METRIC object (https://tools.ietf.org/html/rfc5440#section-7.8) has 2 flags defined - B (Bound) and C (Computed Metric). The P bit is incorrect in the original text, it should be C bit.

RFC 8250, "IPv6 Performance and Diagnostic Metrics (PDM) Destination Option", September 2017

Source of RFC: ippm (ops)

Errata ID: 7601
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Chris Lonvick
Date Reported: 2023-08-12
Held for Document Update by: Martin Duke
Date Held: 2023-08-29

Section 3.2.1 says:

This field is initialized at a random number and incremented
monotonically for each packet of the session flow of the
5-tuple.  The random-number initialization is intended to make
it harder to spoof and insert such packets.

It should say:

This field is initialized at a random number and incremented
sequentially for each packet of the session flow of the
5-tuple.  The random-number initialization is intended to make
it harder to spoof and insert such packets.

Notes:

The term monotonically increasing just means that the value must not decrease; it does not mean that it must increase. For example a monotonically increasing sequence may be: 1,2,2,2,2,2,2,2. On the other hand, a sequentially increasing example would be 1,2,3,4,5,6,7,8. I believe that the authors intended for the value to increase sequentially for each packet.

RFC 8253, "PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", October 2017

Source of RFC: pce (rtg)

Errata ID: 5180
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2017-11-06
Held for Document Update by: Deborah Brungard
Date Held: 2017-12-12

Section 3.4 says:

       *  PCEPS implementations MUST, at a minimum, support negotiation
          of the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 [RFC6460] and
          SHOULD support TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as
          well.  ...

It should say:

       *  PCEPS implementations MUST, at a minimum, support negotiation
          of the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 [RFC5289] and
          SHOULD support TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as
          well.  ...

Notes:

RFC 6460 makes reference to the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ciphersuites, but it does not define them. These ciphersuites are defined in RFC 5289.

RFC 8257, "Data Center TCP (DCTCP): TCP Congestion Control for Data Centers", October 2017

Source of RFC: tcpm (wit)

Errata ID: 6697
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Vidhi Goel
Date Reported: 2021-09-28
Held for Document Update by: Martin Duke
Date Held: 2022-05-13

Section 3.3 says:

The below pseudocode follows after DCTCP.Alpha is updated on ACK processing. This is wrong as cwnd should only be reduced using DCTCP.Alpha when ECE is received. 

9. Rather than always halving the congestion window as described in
       [RFC3168], the sender SHOULD update cwnd as follows:

          cwnd = cwnd * (1 - DCTCP.Alpha / 2)

It should say:

Instead, a new paragraph for Congestion Response to ECN feedback would be much clearer. First start with RFC 3168's response to ECE and then provide DCTCP's response to ECE.

I am thinking splitting section 3.3 into two sub-sections - 
3.3.1 Computation of DCTCP.Alpha
3.3.2 Congestion Response to ECE at sender

Notes:

Although RFC 8257 refers to RFC 3168 congestion window halving at step 9, but it is confusing to put it right after step 8.

Literally interpreted, a window with no congestion marks would reduce the cwnd, which is wrong.

RFC 8270, "Increase the Secure Shell Minimum Recommended Diffie-Hellman Modulus Size to 2048 Bits", December 2017

Source of RFC: curdle (sec)

Errata ID: 5501
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eugene Adell
Date Reported: 2018-09-21
Held for Document Update by: Benjamin Kaduk
Date Held: 2018-09-23

Section 3 says:

[RFC4419] specifies a recommended minimum size of 1024 bits for k,
   which is the modulus length of the DH group.  It also suggests that,
   in all cases, the size of the group needs be at least 1024 bits.

It should say:

[RFC4419] specifies a recommended minimum size of 1024 bits for k,
   which is the modulus length of the DH group.  It also suggests that,
   in all cases, the size of the group needs to be at least 1024 bits.

Notes:

Fix a typo (missing "to").

RFC 8287, "Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes", December 2017

Note: This RFC has been updated by RFC 8690, RFC 9214

Source of RFC: mpls (rtg)

Errata ID: 6101
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alexander ("Sasha") Vainshtein
Date Reported: 2020-04-13
Held for Document Update by: Deborah Brungard
Date Held: 2020-04-30

Section 7.2 says:

   The network node that advertised the Node Segment ID is responsible
   for generating a FEC Stack Change sub-TLV with the Post Office
   Protocol (POP) operation type for the Node Segment ID, regardless of
   whether or not Penultimate Hop Popping (PHP) is enabled.

   The network node that is immediately downstream of the node that
   advertised the Adjacency Segment ID is responsible for generating the
   FEC Stack Change sub-TLV for POP operation for the Adjacency Segment
   ID.

It should say:

   The network node that advertised the Node Segment ID is responsible
   for generating a FEC Stack Change sub-TLV with the pop operation type for 
   the Node Segment ID, regardless of whether or not penultimate hop popping 
   (PHP) is enabled.

   The network node that is immediately downstream of the node that
   advertised the Adjacency Segment ID is responsible for generating the
   FEC Stack Change sub-TLV for pop operation for the Adjacency Segment
   ID.

Notes:

Expansion of POP to "Post Office Protocol" in the context of this document is wrong. It should not be capitalized, it is not an abbreviation, simply the verb, pop. In addition, expansion for PHP should not be with caps.

RFC 8294, "Common YANG Data Types for the Routing Area", December 2017

Source of RFC: rtgwg (rtg)

Errata ID: 7255
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Jeffrey Haas
Date Reported: 2022-11-18
Held for Document Update by: Alvaro Retana
Date Held: 2023-02-13

Section 3 says:

     typedef route-distinguisher {
       type string {
         pattern
           '(0:(6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|'
         +     '6[0-4][0-9]{3}|'
         +     '[1-5][0-9]{4}|[1-9][0-9]{0,3}|0):(429496729[0-5]|'
         +     '42949672[0-8][0-9]|'
         +     '4294967[01][0-9]{2}|429496[0-6][0-9]{3}|'
         +     '42949[0-5][0-9]{4}|'
         +     '4294[0-8][0-9]{5}|429[0-3][0-9]{6}|'
         +     '42[0-8][0-9]{7}|4[01][0-9]{8}|'
         +     '[1-3][0-9]{9}|[1-9][0-9]{0,8}|0))|'
         + '(1:((([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|'
         +     '25[0-5])\.){3}([0-9]|[1-9][0-9]|'
         +     '1[0-9]{2}|2[0-4][0-9]|25[0-5])):(6553[0-5]|'
         +     '655[0-2][0-9]|'
         +     '65[0-4][0-9]{2}|6[0-4][0-9]{3}|'
         +     '[1-5][0-9]{4}|[1-9][0-9]{0,3}|0))|'
         + '(2:(429496729[0-5]|42949672[0-8][0-9]|'
         +     '4294967[01][0-9]{2}|'
         +     '429496[0-6][0-9]{3}|42949[0-5][0-9]{4}|'
         +     '4294[0-8][0-9]{5}|'
         +     '429[0-3][0-9]{6}|42[0-8][0-9]{7}|4[01][0-9]{8}|'
         +     '[1-3][0-9]{9}|[1-9][0-9]{0,8}|0):'
         +     '(6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|'
         +     '6[0-4][0-9]{3}|'
         +     '[1-5][0-9]{4}|[1-9][0-9]{0,3}|0))|'
         + '(6(:[a-fA-F0-9]{2}){6})|'
         + '(([3-57-9a-fA-F]|[1-9a-fA-F][0-9a-fA-F]{1,3}):'
         +     '[0-9a-fA-F]{1,12})';
       }

It should say:

     typedef route-distinguisher {
       type string {
         pattern
           '(0:(6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|'
         +     '6[0-4][0-9]{3}|'
         +     '[1-5][0-9]{4}|[1-9][0-9]{0,3}|0):(429496729[0-5]|'
         +     '42949672[0-8][0-9]|'
         +     '4294967[01][0-9]{2}|429496[0-6][0-9]{3}|'
         +     '42949[0-5][0-9]{4}|'
         +     '4294[0-8][0-9]{5}|429[0-3][0-9]{6}|'
         +     '42[0-8][0-9]{7}|4[01][0-9]{8}|'
         +     '[1-3][0-9]{9}|[1-9][0-9]{0,8}|0))|'
         + '(1:((([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|'
         +     '25[0-5])\.){3}([0-9]|[1-9][0-9]|'
         +     '1[0-9]{2}|2[0-4][0-9]|25[0-5])):(6553[0-5]|'
         +     '655[0-2][0-9]|'
         +     '65[0-4][0-9]{2}|6[0-4][0-9]{3}|'
         +     '[1-5][0-9]{4}|[1-9][0-9]{0,3}|0))|'
         + '(2:(429496729[0-5]|42949672[0-8][0-9]|'
         +     '4294967[01][0-9]{2}|'
         +     '429496[0-6][0-9]{3}|42949[0-5][0-9]{4}|'
         +     '4294[0-8][0-9]{5}|'
         +     '429[0-3][0-9]{6}|42[0-8][0-9]{7}|4[01][0-9]{8}|'
         +     '[1-3][0-9]{9}|[1-9][0-9]{0,8}|0):'
         +     '(6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|'
         +     '6[0-4][0-9]{3}|'
         +     '[1-5][0-9]{4}|[1-9][0-9]{0,3}|0))';
       }

Notes:

Type 6 route-distinguishers are not defined. See the registry at IANA:
https://www.iana.org/assignments/route-distinguisher-types/route-distinguisher-types.xhtml

=== AD Notes (Alvaro Retana) ===
The WG discussed this report: https://mailarchive.ietf.org/arch/msg/rtgwg/o536w2kGqGO-PULTSNTfxyO96ZQ/

There is agreement that the report is correct, but the document needs to be updated.

Also, a similar error in the string related to the route-origin needs to also be corrected.

RFC 8296, "Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks", January 2018

Source of RFC: bier (rtg)

Errata ID: 5641
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jingrong Xie
Date Reported: 2019-02-21
Held for Document Update by: Alvaro Retana
Date Held: 2019-09-10

Section 2.2.3 says:

   By requiring the use of a distinct codepoint for "non-MPLS BIER", we
   allow for deployment scenarios where non-MPLS BIER can coexist with
   non-BIER MPLS.  The BIFT-id values used by the former will not
   conflict with MPLS label values used by the latter.

It should say:

   By requiring the use of a distinct codepoint for "non-MPLS BIER", we
   allow for deployment scenarios where non-MPLS BIER can coexist with
   MPLS BIER.  The BIFT-id values used by the former will not
   conflict with MPLS label values used by the latter.

Notes:

There are "MPLS BIER" and "BIER-MPLS" in this RFC.
The "MPLS BIER" is the right text here for comparison.

RFC 8299, "YANG Data Model for L3VPN Service Delivery", January 2018

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rtg

Errata ID: 5721
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Ivan Frolov
Date Reported: 2019-05-01
Held for Document Update by: John Scudder
Date Held: 2022-05-14

Section 6.2.1. says:

Hub_Site ------- (VRF_Hub)  PE1
                               (VRF_Spoke)
                                  /  |
  Spoke_Site1 -------------------+   |
                                     |
  Spoke_Site2 -----------------------+

It should say:

Hub_Site ------- (VRF_Hub)  PE1
                             (VRF_Spoke1) (VRF_Spoke2)
                                  /            |
  Spoke_Site1 -------------------+             |
                                               |
  Spoke_Site2 ---------------------------------+

Notes:

Submitter's comment:

On the picture, two spoke sites (“Spoke_Site1”, “Spoke_Site2”) are using the same VRF (“VRF_Spoke”) in PE1 router. For Hub and Spoke topology, it seems confusing. The spoke sites must not have a common routing table in the device and each spoke site must have its own VRF if there are more than one site using the same physical router.

Verifier's comment:

Subsequent discussion with the authors came to the conclusion that while the diagram is not technically wrong (for example, a single VRF could be used with policies to control inter-site communication), it would represent a very unusual configuration and therefore isn't a great choice as an example. The proposed replacement text represents the common deployment model and would be a better example.

RFC 8303, "On the Usage of Transport Features Provided by IETF Transport Protocols", February 2018

Source of RFC: taps (wit)

Errata ID: 6373
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2020-12-29
Held for Document Update by: Martin Duke
Date Held: 2021-01-19

Section 4.1 says:

   o  SET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS):

      Pass 1 primitive/event: 'Set_TTL' and 'Set_IPV6_Unicast_Hops'

      Parameters: IPv4 TTL value or IPv6 Hop Count value

      Comments: this allows an application to change the IPv4 TTL of
      IPv6 Hop Count value for outgoing UDP(-Lite) datagrams.

It should say:

   o  SET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS):

      Pass 1 primitive/event: 'Set_TTL' and 'Set_IPV6_Unicast_Hops'

      Parameters: IPv4 TTL value or IPv6 Hop Count value

      Comments: this allows an application to change the IPv4 TTL or
      IPv6 Hop Count value for outgoing UDP(-Lite) datagrams.

Notes:

typo: of instead or

RFC 8304, "Transport Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP-Lite)", February 2018

Source of RFC: taps (wit)

Errata ID: 6370
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2020-12-26
Held for Document Update by: Martin Duke
Date Held: 2021-01-19

Section 3.1 says:

   GET_ECN:  The GET_ECN primitive is a network-layer function that
      returns the value of the ECN field in the IP header of a received
      UDP datagram.  Section 3.1.5 of [RFC8085] states that a UDP
      receiver "MUST check the ECN field at the receiver for each UDP
      datagram that it receives on this port", requiring the UDP
      receiver API to pass the received ECN field up to the application
      layer to enable appropriate congestion feedback.

It should say:

   GET_ECN:  The GET_ECN primitive is a network-layer function that
      returns the value of the ECN field in the IP header of a received
      UDP datagram.  Section 3.1.7 of [RFC8085] states that a UDP
      receiver "MUST check the ECN field at the receiver for each UDP
      datagram that it receives on this port", requiring the UDP
      receiver API to pass the received ECN field up to the application
      layer to enable appropriate congestion feedback.

Notes:

Incorrect reference to RFC 8085

Errata ID: 6371
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2020-12-26
Held for Document Update by: Martin Duke
Date Held: 2021-01-19

Section 3.1 says:

   ERROR_REPORT:  The ERROR_REPORT event informs an application of "soft
      errors", including the arrival of an ICMP or ICMPv6 error message.
      Section 4.1.4 of the requirements for Internet hosts [RFC1122]
      states that "UDP MUST pass to the application layer all ICMP error
      messages that it receives from the IP layer."  For example, this
      event is required to implement ICMP-based Path MTU Discovery
      [RFC1191] [RFC8201].  UDP applications must perform a CONNECT to
      receive ICMP errors.

It should say:

   ERROR_REPORT:  The ERROR_REPORT event informs an application of "soft
      errors", including the arrival of an ICMP or ICMPv6 error message.
      Section 4.1.3.3 of the requirements for Internet hosts [RFC1122]
      states that "UDP MUST pass to the application layer all ICMP error
      messages that it receives from the IP layer."  For example, this
      event is required to implement ICMP-based Path MTU Discovery
      [RFC1191] [RFC8201].  UDP applications must perform a CONNECT to
      receive ICMP errors.

Notes:

Incorrect reference to RFC 1122

RFC 8325, "Mapping Diffserv to IEEE 802.11", February 2018

Note: This RFC has been updated by RFC 8622

Source of RFC: tsvwg (wit)

Errata ID: 7520
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jason Livingood
Date Reported: 2023-05-22
Held for Document Update by: RFC Editor
Date Held: 2023-05-24

Section 9 says:

[IEEE.802.11-2016]
              IEEE, "IEEE Standard for Information technology -
              Telecommunications and information exchange between
              systems - Local and metropolitan area networks - Specific
              requirements - Part 11: Wireless LAN Medium Access Control
              (MAC) and Physical Layer (PHY) Specifications",
              IEEE 802.11, DOI 10.1109/IEEESTD.2016.7786995, December
              2016, <https://standards.ieee.org/findstds/
              standard/802.11-2016.html>.

It should say:

[IEEE.802.11-2016]
              IEEE, "IEEE Standard for Information technology -
              Telecommunications and information exchange between
              systems - Local and metropolitan area networks - Specific
              requirements - Part 11: Wireless LAN Medium Access Control
              (MAC) and Physical Layer (PHY) Specifications",
              IEEE 802.11, DOI 10.1109/IEEESTD.2016.7786995, December
              2016, <https://standards.ieee.org/ieee/8802-11/10034/802.11/5536/>.

Notes:

The format links of IEEE standards has changed on the IEEE website.
The old URL now gives a 404 error.

The new one appears to be https://standards.ieee.org/ieee/8802-11/10034/802.11/5536/.

--VERIFIER NOTES--
The URL worked at the time of publication. This should be reviewed if/when the RFC is updated.

RFC 8357, "Generalized UDP Source Port for DHCP Relay", March 2018

Source of RFC: dhc (int)

Errata ID: 6008
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2020-03-05
Held for Document Update by: Eric Vyncke
Date Held: 2021-01-28

Section 4.2 says:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    OPTION_RELAY_PORT    |         Option-Len                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Downstream Source Port     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 

It should say:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       OPTION_RELAY_PORT       |         Option-Len            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Downstream Source Port     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

Discrepancy between the diagram and the text noted by draft-mcquistin-augmented-ascii-diagrams-02.

-- Verifier note --
There is clearly an error in the diagram that does not reflect the text. As the text is sensible and used as a reference, implementors will follow the text. Hence, the status of 'hold for document update' as it does not cause significant implementation error.

RFC 8358, "Update to Digital Signatures on Internet-Draft Documents", March 2018

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: gen

Errata ID: 5286
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2018-03-13
Held for Document Update by: Lars Eggert
Date Held: 2021-03-11

Throughout the document, when it says:

   The RFC Editor recently published the first RFC that includes non-
   ASCII characters in a text file.  The conventions specified in RFC
   7997 were followed.  We assume that non-ASCII characters will soon
   start appearing in Internet-Drafts as well. (...)

Notes:

This statement is misleading as the drafts for RFC 8187 (which has the non-ASCII characters) were indeed submitted and published as regular internet drafts.

RFC 8365, "A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)", March 2018

Source of RFC: bess (rtg)

Errata ID: 5497
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Klemens Schragel
Date Reported: 2018-09-12
Held for Document Update by: Martin Vigoureux
Date Held: 2018-11-03

Section 5.1.3 says:

   list of encapsulation types defined in [RFC5512]; they are listed in
   Section 11.

   The MPLS encapsulation tunnel type, listed in Section 11, is needed

It should say:

   list of encapsulation types defined in [RFC5512]; they are listed in
   Section 12.

   The MPLS encapsulation tunnel type, listed in Section 12, is needed

Notes:

Typo in the reference, Section 11 is "11. Security Considerations", but text refers to "12. IANA Considerations"

Errata ID: 6336
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Luc Andre Burdet
Date Reported: 2020-11-16
Held for Document Update by: Alvaro Retana
Date Held: 2020-11-17

Section 8.1.5 says:

8.1.5.  DF Election
...
   EVI, normalized VIDs, and etc., as along the IDs are configured

It should say:

8.1.5.  DF Election
...
   EVI, normalized VIDs, and etc., as long as the IDs are configured

Notes:

Nit.
=> as long as

RFC 8366, "A Voucher Artifact for Bootstrapping Protocols", May 2018

Source of RFC: anima (ops)

Errata ID: 7301
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Richardson
Date Reported: 2023-01-08
Held for Document Update by: Rob Wilton
Date Held: 2024-01-15

Section 5.3 says:

          "The Authority Key Identifier OCTET STRING (as defined in
           Section 4.2.1.1 of RFC 5280) from the pledge's IDevID

It should say:

          "The Authority Key Identifier OCTET STRING (as defined in
           Section 4.2.1.1 of [RFC5280]) from the pledge's IDevID

Notes:

The YANG module references RFC 5280 normatively, but the document does not include it as a normative reference.

This errata requires a new revision of the YANG module that cannot be done by an errata, hence moved to "Held for Document Update". In the update, I would suggesting adding a reference statement to the YANG leaf and also a normative document reference to RFC 5280.

RFC 8369, "Internationalizing IPv6 Using 128-Bit Unicode", April 2018

Source of RFC: INDEPENDENT

Errata ID: 5344
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Roland Illig
Date Reported: 2018-04-29
Held for Document Update by: Adrian Farrel
Date Held: 2018-04-30

Section 7 says:

unobfsucated

It should say:

unobfuscated

RFC 8392, "CBOR Web Token (CWT)", May 2018

Source of RFC: ace (sec)

Errata ID: 5710
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Felipe Gasper
Date Reported: 2019-04-29
Held for Document Update by: Paul Wouters
Date Held: 2024-01-17

Section 1.1 says:

In JSON, maps are called objects and only have one kind of map key: a
   string.  CBOR uses strings, negative integers, and unsigned integers
   as map keys.

It should say:

In JSON, maps are called objects and only have one kind of map key:
a string.  CBOR allows other data types, such as strings, negative
integers, and unsigned integers, as map keys.

Notes:

The text as it stands risks an interpretation that CBOR limits map keys to integers and strings; per discussion on the CBOR mailing list, this is not the case.

Errata ID: 5852
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Laurence Lundblade
Date Reported: 2019-09-03
Held for Document Update by: Benjamin Kaduk
Date Held: 2019-09-05

Section A.3 says:

   d28443a10126a104524173796d6d657472696345434453413235365850a701756
   36f61703a2f2f61732e6578616d706c652e636f6d02656572696b77037818636f
   61703a2f2f6c696768742e6578616d706c652e636f6d041a5612aeb0051a5610d
   9f0061a5610d9f007420b7158405427c1ff28d23fbad1f29c4c7c6a555e601d6f
   a29f9179bc3d7438bacaca5acd08c8d4d4f96131680c429a01f85951ecee743a5
   2b9b63632c57209120e1c9e30

It should say:

   d28443a10126a104524173796d6d657472696345434453413235365850a70175
   636f61703a2f2f61732e6578616d706c652e636f6d02656572696b7703781863
   6f61703a2f2f6c696768742e6578616d706c652e636f6d041a5612aeb0051a56
   10d9f0061a5610d9f007420b7158405427c1ff28d23fbad1f29c4c7c6a555e60
   1d6fa29f9179bc3d7438bacaca5acd08c8d4d4f96131680c429a01f85951ecee
   743a52b9b63632c57209120e1c9e30

Notes:

The ASCII representation of binary bytes in Figure 10 is wrapped
on an odd number of ASCII characters. Since there are two ASCII
characters per binary bytes this splits the last byte over two
lines.

The CBOR playground (http://cbor.me) cannot handle this and
errors out.

This is slightly confusing for readers.

The actual bytes values are correct by all the checks I did.

RFC 8398, "Internationalized Email Addresses in X.509 Certificates", May 2018

Source of RFC: lamps (sec)

Errata ID: 5418
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Belyavskiy Dmitry
Date Reported: 2018-07-11
Held for Document Update by: Paul Wouters
Date Held: 2024-01-17

Section Appendix B says:

   This non-normative example demonstrates using SmtpUTF8Mailbox as an
   otherName in GeneralName to encode the email address
   "u+8001u+5E2B@example.com".

      The hexadecimal DER encoding of the email address is:
      A022060A 2B060105 05070012 0809A014 0C12E880 81E5B8AB 40657861
      6D706C65 2E636F6D

      The text decoding is:
        0  34: [0] {
        2  10:   OBJECT IDENTIFIER '1 3 6 1 5 5 7 0 18 8 9'
       14  20:   [0] {
       16  18:     UTF8String '..@example.com'
             :     }
             :   }

                                 Figure 2

   The example was encoded on the OSS Nokalva ASN.1 Playground and the
   above text decoding is an output of Peter Gutmann's "dumpasn1"
   program.

It should say:

   This non-normative example demonstrates using SmtpUTF8Mailbox as an
   otherName in GeneralName to encode the email address
   "u+533Bu+751F@u+5927u+5B66.example.com".

   The hexadecimal DER encoding of the block is:
   a0330608 2b060105 05070809 a0270c25 c3a5c28c c2bbc3a7 c294c29f 
   40c3a5c2 a4c2a7c3 a5c2adc2 a62e6578 616d706c 652e636f 6d


   The text decoding is:
     2  51: [0] {
     4   8:   OBJECT IDENTIFIER '1 3 6 1 5 5 7 8 9'
    14  39:   [0] {
    16  37:     UTF8String '..@...example.com'
          :     }
          :   }

                                 Figure 2

   The example was encoded on the OSS Nokalva ASN.1 Playground and the
   above text decoding is an output of Peter Gutmann's "dumpasn1"
   program.

Notes:

The OID used in Appendix B does not match the OID for id-on-SmtpUTF8Mailbox defined in "Appendix A. ASN.1 Module" and is not mentioned anywhere in the RFC.

Paul Wouters (AD): Note that it seems different versions of the dumpasn1 tool seem to handle non-ASCII characters in the output differently, so the tool output can slightly vary from the Reporter's corrected output. The OID correction has been verified by my and Russ Housley

RFC 8401, "Bit Index Explicit Replication (BIER) Support via IS-IS", June 2018

Note: This RFC has been updated by RFC 9272

Source of RFC: bier (rtg)

Errata ID: 6418
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Les Ginsberg
Date Reported: 2021-01-31
Held for Document Update by: Alvaro Retana
Date Held: 2021-02-02

Section 4.2 says:

 o  When the Prefix Attributes Flags sub-TLV [RFC7794] is present, the
      N flag MUST be set and the R flag MUST NOT be set.

It should say:

  o  When the Prefix Attributes Flags sub-TLV [RFC7794] is present, the
      N flag MUST be set.

Notes:

Early versions of the draft did not support leaking of BIER advertisements. At that time the requirement that R-flag be clear made sense. Once leaking was allowed the prohibition against R-bit being set no longer makes sense and should be removed.

RFC 8410, "Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure", August 2018

Note: This RFC has been updated by RFC 9295

Source of RFC: curdle (sec)

Errata ID: 5696
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Lijun Liao
Date Reported: 2019-04-17
Held for Document Update by: Roman Danyliw
Date Held: 2022-04-25

Section 5 says:

   If the keyUsage extension is present in a certification authority
   certificate that indicates id-Ed25519 or id-Ed448, then the keyUsage
   extension MUST contain one or more of the following values:

          nonRepudiation;
          digitalSignature;
          keyCertSign; and
          cRLSign.

It should say:

   If the keyUsage extension is present in a certification authority
   certificate that indicates id-Ed25519 or id-Ed448, then the keyUsage
   extension MUST contain keyCertSign, and zero, one or more of the
   following values:

          nonRepudiation;
          digitalSignature; and
          cRLSign.

Notes:

The usage keyCertSign must be set in a CA certificate.

Errata ID: 7848
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Corey Bonnell
Date Reported: 2024-03-12
Held for Document Update by: Deb Cooley
Date Held: 2024-04-11

Section 6 says:

Certificate  ::=  SEQUENCE  {
           tbsCertificate       TBSCertificate,
           signatureAlgorithm   AlgorithmIdentifier,
           signatureValue       BIT STRING  }

...


For the Certificate structure, the signature value is
   wrapped in the "signatureValue" BIT STRING field.

It should say:

Certificate  ::=  SEQUENCE  {
           tbsCertificate       TBSCertificate,
           signatureAlgorithm   AlgorithmIdentifier,
           signature            BIT STRING  }

...

For the Certificate structure, the signature value is
   wrapped in the "signature" BIT STRING field.

Notes:

There is no field with the name "signatureValue" in the Certificate SEQUENCE. It is instead named "signature" according to the ASN.1 module in RFC 5280 A.1 as well as the ASN.1 module in section 14 of RFC 5912.

Errata ID: 5459
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Conrado Gouvea
Date Reported: 2018-08-13
Held for Document Update by: Benjamin Kaduk
Date Held: 2018-08-13

Section 7 says:

   -----BEGIN PRIVATE KEY-----
   MHICAQEwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC
   oB8wHQYKKoZIhvcNAQkJFDEPDA1DdXJkbGUgQ2hhaXJzgSEAGb9ECWmEzf6FQbrB
   Z9w7lshQhqowtrbLDFw4rXAxZuE=
   -----END PRIVATE KEY------

It should say:

   -----BEGIN PRIVATE KEY-----
   MHICAQEwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC
   oB8wHQYKKoZIhvcNAQkJFDEPDA1DdXJkbGUgQ2hhaXJzgSEAGb9ECWmEzf6FQbrB
   Z9w7lshQhqowtrbLDFw4rXAxZuE=
   -----END PRIVATE KEY-----

Notes:

Should be five dashes instead of six, at the end

Errata ID: 5707
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lijun Liao
Date Reported: 2019-04-29
Held for Document Update by: Benjamin Kaduk
Date Held: 2019-05-25

Section 10.2 says:

Notes:

In the example certificate, the critical-field of extensions keyUsage and subjectKeyIdentifier are of default value 'false'. They should not be included according to DER encoding rule.

RFC 8415, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", November 2018

Source of RFC: dhc (int)

Errata ID: 6269
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Felix Hamme
Date Reported: 2020-08-30
Held for Document Update by: Eric Vyncke
Date Held: 2021-01-28

Throughout the document, when it says:

section 16:
"A server MUST discard any Solicit, Confirm, Rebind, or Information-request messages it receives with a Layer 3 unicast destination address."

section 18.2:
"If the client has a source address of sufficient scope that can be used by the server as a return address and the client has received a Server Unicast option (see Section 21.12) from the server, the client SHOULD unicast any Request, Renew, Release, and Decline messages to the server."


Appendix B does not permit a Server Unicast option in a Reconfigure message.

It should say:

section 16:
"A server MUST discard any Solicit, Confirm, or Rebind messages it receives with a Layer 3 unicast destination address."

section 18.2:
"If the client has a source address of sufficient scope that can be used by the server as a return address and the client has received a Server Unicast option (see Section 21.12) from the server, the client SHOULD unicast any Request, Renew, Release, Decline, and Information-request messages to the server."

Appendix B permits a Server Unicast option in a Reconfigure message.

Notes:

Section 18.4 allows transmission of Information-request messages with a unicast destination address, if the client received a message with Server Unicast option. (See also https://mailarchive.ietf.org/arch/msg/dhcwg/x80cmfTN8fpRViiN_RHNXes-zVg/)

-- Verifier note --
After discussions inside the DHC WG (https://mailarchive.ietf.org/arch/msg/dhcwg/oNqBzT7CSOtoV7kQNLkJfSY_73E/), it appears that there is indeed an issue but as a RFC 8415-bis is probably coming and as the errata does not seem to be a couple of sentences to add/modify, I am selecting 'hold for document update'

Errata ID: 6159
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Fernando Gont
Date Reported: 2020-05-07
Held for Document Update by: Eric Vyncke
Date Held: 2020-05-07

Section 6.5 says:

   Temporary addresses were originally introduced to avoid privacy
   concerns with stateless address autoconfiguration, which based
   64 bits of the address on the EUI-64 (see [RFC4941].

It should say:

   Temporary addresses were originally introduced to avoid privacy
   concerns with stateless address autoconfiguration, which based
   64 bits of the address on the EUI-64 (see [RFC4941]).

Notes:

Missing close parenthesis

AD note: good catch but as it is a typo, it is for "Held for Document Update". Thank you.

RFC 8416, "Simplified Local Internet Number Resource Management with the RPKI (SLURM)", August 2018

Source of RFC: sidr (rtg)

Errata ID: 7080
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Ben Maddison
Date Reported: 2022-08-10
Held for Document Update by: Warren Kumari (Ops AD)
Date Held: 2022-10-07

Section 3.4.2 says:

   The above is expressed as a value of the "bgpsecAssertions" member,
   as an array of zero or more objects.  Each object MUST contain one
   each of all of the following members:

   o  An "asn" member, whose value is a number.

   o  An "SKI" member, whose value is the Base64 encoding without
      trailing '=' (Section 5 of [RFC4648]) of the certificate's Subject
      Key Identifier as described in Section 4.8.2 of [RFC6487] (This is
      the value of the ASN.1 OCTET STRING without the ASN.1 tag or
      length fields.)

   o  A "routerPublicKey" member, whose value is the Base64 encoding
      without trailing '=' (Section 5 of [RFC4648]) of the equivalent to
      the subjectPublicKeyInfo value of the router certificate's public
      key, as described in [RFC8208].  This is the full ASN.1 DER
      encoding of the subjectPublicKeyInfo, including the ASN.1 tag and
      length values of the subjectPublicKeyInfo SEQUENCE.

It should say:

   The above is expressed as a value of the "bgpsecAssertions" member,
   as an array of zero or more objects.  Each object MUST contain one
   each of all of the following members:

   o  An "asn" member, whose value is a number.

   o  An "SKI" member, whose value is the Base64 encoding without
      trailing '=' (Section 5 of [RFC4648]) of the certificate's Subject
      Key Identifier as described in Section 4.8.2 of [RFC6487] (This is
      the value of the ASN.1 OCTET STRING without the ASN.1 tag or
      length fields.)

   o  A "routerPublicKey" member, whose value is the Base64 encoding
      without trailing '=' (Section 5 of [RFC4648]) of the equivalent to
      the subjectPublicKeyInfo value of the router certificate's public
      key, as described in [RFC8208].  This is the full ASN.1 DER
      encoding of the subjectPublicKeyInfo, including the ASN.1 tag and
      length values of the subjectPublicKeyInfo SEQUENCE.

   In addition, each object MAY contain one optional "comment" member,
   whose value is a string.

Notes:

The "comment" member is allowed to appear in every other structure defined by the document, and was clearly intended to be allowed here too, since it appears in the examples presented in sections 3.4.2 and 3.5

[Warren Kumari: See thread https://mailarchive.ietf.org/arch/msg/sidrops/uEc7K01ex0GJ6tE_FqfDwDTZTws/

We are not aware of any implementations which will choke on comments]

RFC 8422, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier", August 2018

Note: This RFC has been updated by RFC 8996

Source of RFC: tls (sec)

Errata ID: 5466
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Masato Gosui
Date Reported: 2018-08-17
Held for Document Update by: Benjamin Kaduk
Date Held: 2018-08-17

Section 5.3 says:

   Actions of the sender:

   The server constructs an appropriate certificate chain and conveys it
   to the client in the Certificate message.  If the client has used a
   Supported Elliptic Curves Extension, the public key in the server's
   certificate MUST respect the client's choice of elliptic curves.  A
   server that cannot satisfy this requirement MUST NOT choose an ECC
   cipher suite in its ServerHello message.)

It should say:

   Actions of the sender:

   The server constructs an appropriate certificate chain and conveys it
   to the client in the Certificate message.  If the client has used a
   Supported Elliptic Curves Extension, the public key in the server's
   certificate MUST respect the client's choice of elliptic curves.  A
   server that cannot satisfy this requirement MUST NOT choose an ECC
   cipher suite in its ServerHello message.

Notes:

This removes the spurious closing parenthesis of the last sentence of the "Actions of the sender" paragraph.

Errata ID: 5468
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Masato Gosui
Date Reported: 2018-08-17
Held for Document Update by: Paul Wouters
Date Held: 2024-01-17

Section 5.4 says:

   namedCurve: Specifies a recommended set of elliptic curve domain

It should say:

   namedcurve: Specifies a recommended set of elliptic curve domain

Notes:

This fixes mismatched names of the variable "namedcurve" in the "Structure of this message" paragraph.

RFC 8423, "Reclassification of Suite B Documents to Historic Status", July 2018

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 5686
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Adam Crosby
Date Reported: 2019-04-09
Held for Document Update by: Benjamin Kaduk
Date Held: 2019-04-20

Section 8.2 says:

   [CNSA]     National Security Agency, "Commercial National Security
              Algorithm Suite", August 2015,
              <https://www.iad.gov/iad/programs/iad-initiatives/
              cnsa-suite.cfm>.

It should say:

   [CNSA]     National Security Agency, "Commercial National Security
              Algorithm Suite", August 2015,
              <https://apps.nsa.gov/iaarchive/programs/iad-initiatives/
              cnsa-suite.cfm>.

Notes:

The NSA re-worked their website, and the URL for reference [CNSA] is no longer valid.

RFC 8427, "Representing DNS Messages in JSON", July 2018

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: art

Errata ID: 5437
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Richard Gibson
Date Reported: 2018-07-24
Held for Document Update by: Barry Leiba
Date Held: 2020-11-25

Section 2 says:

2.1.  Message Object Members
   o  compressedQNAME - Object that describes the name with two optional
      values: "isCompressed" (with a value of 0 for no and 1 for yes)
      and "length" (with an integer giving the length in the message)

2.2.  Resource Record Object Members
   o  compressedNAME - Object that describes the name with two optional
      values: "isCompressed" (with a value of 0 for no and 1 for yes)
      and "length" (with an integer giving the length in the message)

It should say:

2.1.  Message Object Members
   o  compressedQNAME - Object that describes the name with two optional
      values: "isCompressed" (with a value of 0 for no and 1 for yes)
      and "length" (an integer giving the count of octets of the name in
      the message, including but not following compression pointers)

2.2.  Resource Record Object Members
   o  compressedNAME - Object that describes the name with two optional
      values: "isCompressed" (with a value of 0 for no and 1 for yes)
      and "length" (an integer giving the count of octets of the name in
      the message, including but not following compression pointers)

Notes:

"length in the message" is ambiguous for compressed names... taking for example a compressed domain name that represents "a.b.example.com." as 0x0161 0x0162 0xC00C (i.e., label "a", then label "b", then a pointer to "example.com." at offset 12), it could mean 1) the count of octets constituting the absolute name, including both compression pointers and labels referenced by them (6+13=19), or 2) the count of octets of the compression pointer plus immediately preceding labels (6), or 3) the count of octets of labels _preceding_ the compression pointer (4), or even 4) the offset in the compression pointer (12).

The above Corrected Text specifies option 3, because that interpretation allows for the most uniform treatment of compressed vs. uncompressed names.

Errata ID: 5570
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2018-12-07
Held for Document Update by: Benjamin Kaduk
Date Held: 2019-01-25

Section 5.2 says:

"responseMessage": { "ID": 32784, "QR": 1, "AA": 1, "RCODE": 0,
                         "QDCOUNT": 1, "ANCOUNT": 1, "NSCOUNT": 1,

It should say:

"responseMessage": { "ID": 32784, "QR": 1, "AA": 1, "RCODE": 0,
                         "QDCOUNT": 1, "ANCOUNT": 2, "NSCOUNT": 1,

Notes:

ANCOUNT should, IMHO, be 2 and not 1. There are two resource records in the answer section.

True, the RFC explicitely says (section 8, 1st paragraph) that there can be a discrepancy between ANCOUNT and the actual number of records but I doubt this example was meant to illustrate this point.

RFC 8428, "Sensor Measurement Lists (SenML)", August 2018

Note: This RFC has been updated by RFC 9100

Source of RFC: core (wit)

Errata ID: 6728
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Veijo Pesonen
Date Reported: 2021-11-01
Held for Document Update by: Francesca Palombini
Date Held: 2021-11-01

Section 11 says:

SenML-Pack = [1* record]

   record = {
     ? bn => tstr,        ; Base Name
     ? bt => numeric,     ; Base Time
     ? bu => tstr,        ; Base Units
     ? bv => numeric,     ; Base Value
     ? bs => numeric,     ; Base Sum
     ? bver => uint,      ; Base Version
     ? n => tstr,        ; Name
     ? u => tstr,        ; Units
     ? s => numeric,     ; Sum
     ? t => numeric,     ; Time
     ? ut => numeric,    ; Update Time
     ? ( v => numeric // ; Numeric Value
         vs => tstr //   ; String Value
         vb => bool //   ; Boolean Value
         vd => binary-value ) ; Data Value
     * key-value-pair
   }

It should say:

SenML-Pack = [1* record]

   record = {
     ? bn => tstr,        ; Base Name
     ? bt => numeric,     ; Base Time
     ? bu => tstr,        ; Base Units
     ? bv => numeric,     ; Base Value
     ? bs => numeric,     ; Base Sum
     ? bver => uint,      ; Base Version
     ? n => tstr,        ; Name
     ? u => tstr,        ; Units
     ? s => numeric,     ; Sum
     ? t => numeric,     ; Time
     ? ut => numeric,    ; Update Time
     ? ( v => numeric // ; Numeric Value
         vs => tstr //   ; String Value
         vb => bool //   ; Boolean Value
         vd => binary-value ), ; Data Value
     * key-value-pair
   }

Notes:

It would show good style to set the comma even though it's not required.

RFC 8431, "A YANG Data Model for the Routing Information Base (RIB)", September 2018

Source of RFC: i2rs (rtg)

Errata ID: 7359
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2023-02-17
Held for Document Update by: Alvaro Retana
Date Held: 2023-02-17

Section 3 says:

     grouping vxlan-header {
       description
         "The VXLAN encapsulation header information.";
       choice vxlan-type {
         description
           "NVGRE can use either an IPv4
            or an IPv6 header for encapsulation.";
         case ipv4 {
           uses ipv4-header;
         }
         case ipv6 {
           uses ipv6-header;
         }
       }
       leaf vxlan-identifier {
         type uint32;
         mandatory true;
         description
           "The VXLAN identifier of the VXLAN header.";
       }
     }

It should say:

     grouping vxlan-header {
       description
         "The VXLAN encapsulation header information.";
       choice vxlan-type {
         description
           "VXLAN can use either an IPv4
            or an IPv6 header for encapsulation.";
         case ipv4 {
           uses ipv4-header;
         }
         case ipv6 {
           uses ipv6-header;
         }
       }
       leaf vxlan-identifier {
         type uint32;
         mandatory true;
         description
           "The VXLAN identifier of the VXLAN header.";
       }
     }

Notes:

In the description, instead of VXLAN, NVGRE is indicated (page 49)

Errata ID: 7360
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2023-02-17
Held for Document Update by: Alvaro Retana
Date Held: 2023-02-17

Section 3 says:

    rpc route-delete {
       description
         "To delete a route or a list of routes from a RIB";
       input {
         leaf return-failure-detail {
           type boolean;
           default "false";
           description
             "Whether to return the failure detail.
              true  - return the failure detail
              false - do not return the failure detail
              The default is false.";
         }
         leaf rib-name {
           type string;
           mandatory true;
           description
             "A reference to the name of a RIB.";
         }
         container routes {
           description
             "The routes to be added to the RIB.";
           list route-list {
             key "route-index";
             description
               "The list of routes to be deleted.";
             uses route-prefix;
           }
         }
       }
       output {
         uses route-operation-state;
       }
     }

It should say:

    rpc route-delete {
       description
         "To delete a route or a list of routes from a RIB";
       input {
         leaf return-failure-detail {
           type boolean;
           default "false";
           description
             "Whether to return the failure detail.
              true  - return the failure detail
              false - do not return the failure detail
              The default is false.";
         }
         leaf rib-name {
           type string;
           mandatory true;
           description
             "A reference to the name of a RIB.";
         }
         container routes {
           description
             "The routes to be deleted from the RIB.";
           list route-list {
             key "route-index";
             description
               "The list of routes to be deleted.";
             uses route-prefix;
           }
         }
       }
       output {
         uses route-operation-state;
       }
     }

Notes:

Copy-paste error at page 60.

Errata ID: 7361
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2023-02-17
Held for Document Update by: Alvaro Retana
Date Held: 2023-02-17

Section 3 says:

     rpc route-update {
       description
         "To update a route or a list of routes of a RIB.
          The inputs:
            1. The match conditions, which could be:
              a. route prefix,
              b. route attributes, or
              c. nexthop.
            2. The update parameters to be used:
              a. new nexthop,
              b. new route attributes, or
              c. nexthop.

It should say:

     rpc route-update {
       description
         "To update a route or a list of routes of a RIB.
          The inputs:
            1. The match conditions, which could be:
              a. route prefix,
              b. route attributes, or
              c. nexthop.
            2. The update parameters to be used:
              a. new nexthop, or
              b. new route attributes

Notes:

Excess item 2.c (page 61)

Errata ID: 7362
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2023-02-17
Held for Document Update by: Alvaro Retana
Date Held: 2023-02-17

Section 3 says:

       output {
         leaf result {
           type boolean;
           mandatory true;
           description
             "Return the result of the rib-add operation:
              true  - success
              false - failed";
         }
         leaf reason {
           type string;
           description
             "The specific reason that caused the failure.";
         }
         leaf nexthop-id {
           type uint32;
           description
             "A nexthop identifier that is allocated to the nexthop.";
         }

It should say:

       output {
         leaf result {
           type boolean;
           mandatory true;
           description
             "Return the result of the nh-add operation:
              true  - success
              false - failed";
         }
         leaf reason {
           type string;
           description
             "The specific reason that caused the failure.";
         }
         leaf nexthop-id {
           type uint32;
           description
             "A nexthop identifier that is allocated to the nexthop.";
         }

Notes:

Erroneously specified operation rib-add instead of nh-add on page 64

Errata ID: 7363
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2023-02-17
Held for Document Update by: Alvaro Retana
Date Held: 2023-02-17

Section 3 says:

       output {
         leaf result {
           type boolean;
           mandatory true;
           description
             "Return the result of the rib-add operation:
              true  - success;
              false - failed";
         }

It should say:

       output {
         leaf result {
           type boolean;
           mandatory true;
           description
             "Return the result of the nh-delete operation:
              true  - success;
              false - failed";
         }

Notes:

Erroneously specified operation rib-add instead of nh-delete on page 65

RFC 8441, "Bootstrapping WebSockets with HTTP/2", September 2018

Source of RFC: httpbis (wit)

Errata ID: 5500
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Loïc Hoguin
Date Reported: 2018-09-21
Held for Document Update by: Barry Leiba
Date Held: 2020-04-01

Section 3 says:

Using a SETTINGS parameter to opt into an otherwise incompatible
protocol change is a use of "Extending HTTP/2" defined by Section 5.5
of [RFC7540].  Specifically, the addition a new pseudo-header field,

It should say:

Using a SETTINGS parameter to opt into an otherwise incompatible
protocol change is a use of "Extending HTTP/2" defined by Section 5.5
of [RFC7540].  Specifically, the addition of a new pseudo-header field,

Notes:

I think it's missing a word.

RFC 8446, "The Transport Layer Security (TLS) Protocol Version 1.3", August 2018

Source of RFC: tls (sec)

Errata ID: 5682
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Richard Barnes
Date Reported: 2019-04-01
Held for Document Update by: Paul Wouters
Date Held: 2024-01-17

Section 4.3.2, B.3.2 says:

     struct {
         opaque certificate_request_context<0..2^8-1>;
         Extension extensions<2..2^16-1>;
     } CertificateRequest;

It should say:

     struct {
         opaque certificate_request_context<0..2^8-1>;
         Extension extensions<0..2^16-1>;
     } CertificateRequest;

Notes:

The length of this vector can never 2. It is either 0, if the vector is empty, or >=4, if the vector has at least one extension. Nothing elsewhere in the spec requires a non-zero number of extensions here, so this syntax should allow a zero-length vector.

Paul Wouters (AD): There are two places in the mentioned sections that need this one liner fix.

Errata ID: 5874
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Mr Laurie Perrin
Date Reported: 2019-10-12
Held for Document Update by: Paul Wouters
Date Held: 2024-04-05

Section 5.1 says:

...

   Application Data messages contain data that is opaque to TLS.
   Application Data messages are always protected.  Zero-length
   fragments of Application Data MAY be sent, as they are potentially
   useful as a traffic analysis countermeasure.  Application Data
   fragments MAY be split across multiple records or coalesced into a
   single record.

It should say:

...

   Application Data messages contain data that is opaque to TLS.
   Application Data messages are always protected.  Zero-length
   fragments of Application Data (i.e. those encapsulating an
   TLSInnerPlaintext record having a content field of length zero)
   MAY be sent, as they are potentially useful as a traffic analysis
   countermeasure. Application Data fragments MAY be split across
   multiple records or coalesced into a single record.

Notes:

In the interest of clarity, it may be prudent to specify the type of record for
which a fragment of length zero is being considered - it cannot be that of the
TLSCiphertext itself, for "Application Data messages are always protected,"
therefore I infer this relates to the TLSInnerPlaintext content field (of
length "TLSPlaintext.length") - i.e. to the TLSPlaintext fragment.

Note: This comment also applies to previous versions of the TLS specification,
in particular with the introduction of the respective text concerning zero-length
fragments in RFC 5246. In TLS 1.2, this would be the GenericXXCipher content
field of length "TLSCompressed.length" - i.e. to the TLSCompressed fragment.

Note: The implications of zero-length records must be considered with respect to
potential vectors for denial of service.

Paul Wouters(AD): Currently discussed at:

https://github.com/tlswg/tls13-spec/issues/1346
https://github.com/tlswg/tls13-spec/pull/1347

Errata ID: 6401
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Eric Covener
Date Reported: 2021-01-20
Held for Document Update by: Paul Wouters
Date Held: 2024-03-29

Section 4.6.2 says:

When the client has sent the "post_handshake_auth" extension (see
Section 4.2.6), a server MAY request client authentication at any
time after the handshake has completed by sending a
CertificateRequest message.  

It should say:

When the client has sent the "post_handshake_auth" extension (see
Section 4.2.6), a server MAY request client authentication during the 
main handshake and/or at any time after the handshake has completed by 
sending a CertificateRequest message.  

Notes:

4.6.2 is ambiguous as to whether it forbids "main handshake" (mid-handshake) client
authentication when the client has sent the "post_handshake_auth" extension. I think
the language would be stronger if it were really forbidden, and openssl s_server permits
this behavior and rfc8740 implies it as well.

The "main handshake" language is adopted from 4.3.2 but "main" could be dropped as
"handshake" is not ambiguous in 1.3 due to no renegotiation.

Errata ID: 6820
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Leander Schwarz
Date Reported: 2022-01-21
Held for Document Update by: Paul Wouters
Date Held: 2024-04-05

Section 6.2 says:

unsupported_extension:  Sent by endpoints receiving any handshake
      message containing an extension known to be prohibited for
      inclusion in the given handshake message, or including any
      extensions in a ServerHello or Certificate not first offered in
      the corresponding ClientHello or CertificateRequest. 

It should say:

unsupported_extension:  Sent by endpoints receiving any handshake
      message containing an extension in a ServerHello or Certificate
      not first offered in the corresponding ClientHello or 
      CertificateRequest.

Notes:

The definition of the unsupported_extension alert in section 6.2 contradicts the statements in section 4.2:

If an implementation receives an extension
which it recognizes and which is not specified for the message in
which it appears, it MUST abort the handshake with an
"illegal_parameter" alert.

While this might not be inconsistent due to the "abort the handshake with an X alert" specification at the beginning of section 6.2, it might lead to confusion. (see https://mailarchive.ietf.org/arch/msg/tls/hGOGWZRMg718mWqOZ06LwjV9360/).

Paul Wouters(AD): Currently discussed at:

https://github.com/tlswg/tls13-spec/issues/1352
https://github.com/tlswg/tls13-spec/pull/1353

Errata ID: 5627
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Daniel Kahn Gillmor
Date Reported: 2019-02-08
Held for Document Update by: Benjamin Kaduk
Date Held: 2019-02-08

Section 4.2.11 says:

In TLS versions prior to TLS 1.3, the Server Name Identification
(SNI) value 

It should say:

In TLS versions prior to TLS 1.3, the Server Name Indication
(SNI) value 

Notes:

RFC 6066 and many other places indicate that the correct expansion for "SNI" is "Server Name Indication", not "Server Name Identification".

Errata ID: 5717
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Daniel Migault
Date Reported: 2019-05-03
Held for Document Update by: Paul Wouters
Date Held: 2024-03-29

Section 2.2. says:

 Figure 3 shows a pair of handshakes in which the first handshake
   establishes a PSK and the second handshake uses it:
 
          Client                                               Server
 
   Initial Handshake:
          ClientHello
          + key_share               -------->
                                                          ServerHello
                                                          + key_share
                                                {EncryptedExtensions}
                                                {CertificateRequest*}
                                                       {Certificate*}
                                                 {CertificateVerify*}
                                                           {Finished}
                                    <--------     [Application Data*]
          {Certificate*}
          {CertificateVerify*}
          {Finished}                -------->
                                    <--------      [NewSessionTicket]
          [Application Data]        <------->      [Application Data]
 
 
   Subsequent Handshake:
          ClientHello
          + key_share*
          + pre_shared_key          -------->
                                                          ServerHello
                                                     + pre_shared_key
                                                         + key_share*
                                                {EncryptedExtensions}
                                                           {Finished}
                                    <--------     [Application Data*]
          {Finished}                -------->
          [Application Data]        <------->      [Application Data]
 
               Figure 3: Message Flow for Resumption and PSK

It should say:

 Figure 3 shows a pair of handshakes in which the first handshake
   establishes a PSK and the second handshake uses it:
 
          Client                                               Server
 
   Initial Handshake:
          ClientHello
          + key_share               -------->
                                                          ServerHello
                                                          + key_share
                                                {EncryptedExtensions}
                                                {CertificateRequest*}
                                                       {Certificate*}
                                                 {CertificateVerify*}
                                                           {Finished}
                                    <--------     [Application Data*]
          {Certificate*}
          {CertificateVerify*}
          {Finished}                -------->
                                    <--------      [NewSessionTicket]
          [Application Data]        <------->      [Application Data]
 
 
   Subsequent Handshake:
          ClientHello
          + key_share*
          + psk_key_exchange_modes        
          + pre_shared_key          -------->

                                                          ServerHello
                                                     + pre_shared_key
                                                         + key_share*
                                                {EncryptedExtensions}
                                                           {Finished}
                                    <--------     [Application Data*]
          {Finished}                -------->
          [Application Data]        <------->      [Application Data]
 
               Figure 3: Message Flow for Resumption and PSK

Notes:

The pre_shared_key requires the pre_share_key extension.

This Issue and PR should address this erratum:
https://github.com/tlswg/tls13-spec/issues/1344
https://github.com/tlswg/tls13-spec/pull/1345

Errata ID: 6125
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-24
Held for Document Update by: Paul Wouters
Date Held: 2024-03-21

Throughout the document, when it says:

PSKs are referred to as out-of-band and external

It should say:

Referring to PSKs as either out-of-band xor external would help at least one reader

Notes:

This got incorporated into the bis document, but not exactly as suggested.

Errata ID: 6128
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-24
Held for Document Update by: Paul Wouters
Date Held: 2024-03-21

Throughout the document, when it says:

terminate and abort are used interchangeable, but this isn't explained until after such use.

In Section 6.2, we have: In the rest of this specification, when the phrases "terminate the connection" and "abort the handshake" are used without a specific alert it means that the implementation SHOULD send the alert indicated by the
descriptions below.  

It should say:

Perhaps explain terminology earlier. At the very least, in Section 6.2, open the above sentence with "Throughout this specification"

Notes:

This got incorporated into the bis document, but not exactly as suggested.

Errata ID: 6135
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-28
Held for Document Update by: Paul Wouters
Date Held: 2024-03-21

Section Global says:

list, series, set, and vector are seemingly used as synonyms. 

It should say:

Using list, series, set, xor vector would help at least one reader. 

Notes:

Additionally, consistent usage is desirable, e.g., page 31 uses "A list of extensions" whereas "A set of
extensions" is used on page 60. Elsewhere inconsistently usage causes confusion, e.g.,
Page 48:

client_shares: A list of offered KeyShareEntry values in descending
order of client preference.

This vector MAY be empty if the client is requesting a

(Replace "vector" with "list", or vice versa.)

Paul Wouters (AD): This got incorporated into the bis document, but not exactly as suggested.

Errata ID: 6138
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-28
Held for Document Update by: Paul Wouters
Date Held: 2024-03-21

Section 4.2.10 says:

   For externally              
   provisioned PSKs, the associated values are those provisioned along 
   with the key.  For PSKs established via a NewSessionTicket message, 
   the associated values are those which were negotiated in the        
   connection which established the PSK.  

   ...

   For externally established             
   PSKs, the associated values are those provisioned along with the key.
   For PSKs established via a NewSessionTicket message, the associated  
   values are those negotiated in the connection during which the ticket
   was established.                                                     

It should say:

   For externally              
   provisioned PSKs, the associated values are those provisioned along 
   with the key.  For PSKs established via a NewSessionTicket message, 
   the associated values are those which were negotiated in the        
   connection which established the PSK.  

Notes:

Drop largely verbatim duplicated text

Paul Wouters (AD): This got incorporated into the bis document, but not exactly as suggested.

Errata ID: 6204
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Chris Wood
Date Reported: 2020-06-03
Held for Document Update by: Paul Wouters
Date Held: 2024-03-29

Section E.1 says:

Implementations MUST NOT combine external PSKs with certificate-based authentication of either the client or the server unless negotiated by some extension.

It should say:

Implementations MUST NOT combine external PSKs with certificate-based authentication of either client or the server. Future specifications MAY provide an extension to permit this. 

Notes:

The existing text can be misread as permitting this combination upon negotiation of the "post_handshake_auth" extension, which would be incorrect. [1] describes an attack that can occur based on this misinterpretation. The proposed text aims to make clear that a *new* extension is required for this combination.

Paul Wouters(AD): See https://mailarchive.ietf.org/arch/msg/tls/uDjERicvcTimiecyhiSrYA0H1Sc/
[1] https://link.springer.com/article/10.1007%2Fs11416-020-00352-0

Errata ID: 6205
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Martin Thomson
Date Reported: 2020-06-04
Held for Document Update by: Paul Wouters
Date Held: 2024-01-17

Section 4.3.2 says:

   Servers which are authenticating with a PSK MUST NOT send the
   CertificateRequest message in the main handshake, though they MAY
   send it in post-handshake authentication (see Section 4.6.2) provided
   that the client has sent the "post_handshake_auth" extension (see
   Section 4.2.6).

It should say:

   Servers which are authenticating with a resumption PSK MUST NOT send the
   CertificateRequest message in the main handshake, though they MAY
   send it in post-handshake authentication (see Section 4.6.2) provided
   that the client has sent the "post_handshake_auth" extension (see
   Section 4.2.6).  Servers which are authenticating with an external PSK
   MUST NOT send the CertificateRequest message either in the main handshake
   or request post-handshake authentication. Future specifications MAY
   provide an extension to permit this. 

Notes:

The lack of qualification on "authenticating with a PSK" implies that the statement applies equally to both external and resumption PSKs. However, there are two conditions being governed: whether a certificate can be requested during the handshake, and whether a certificate can be requested post-handshake. The latter of these requires different rules depending on the type of PSK.

We know from the analysis of resumption (see https://mailarchive.ietf.org/arch/msg/tls/TugB5ddJu3nYg7chcyeIyUqWSbA/) that combining a PSK handshake of either type with a client certificate is not safe. Thus, the prohibition on CertificateRequest during the handshake applies equally to both resumption and external PSKs.

For post-handshake, Appendix E.1 already discusses the risks of combining PSKs with certificates, citing the same analysis as above.

[...] It is unsafe to use certificate-based client
authentication when the client might potentially share the same
PSK/key-id pair with two different endpoints.

For this reason an external PSK is not safe to use with post-handshake authentication. A resumption PSK does not have this property, so the same prohibition doesn't apply.

Splitting the requirements as proposed makes this split clearer.

RFC 8448, "Example Handshake Traces for TLS 1.3", January 2019

Source of RFC: tls (sec)

Errata ID: 5720
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin Thomson
Date Reported: 2019-05-05
Held for Document Update by: Benjamin Kaduk
Date Held: 2019-05-06

Throughout the document, when it says:

00 0d 00 20 00 1e 04 03 05 03 06 03 02 03 08 04 08 05
08 06 04 01 05 01 06 01 02 01 04 02 05 02 06 02 02 02 

It should say:

00 0d 00 18 00 16 04 03 05 03 06 03 02 03 08 04 08 05
08 06 04 01 05 01 06 01 02 01

Notes:

The traces all show DSA signature schemes in ClientHello messages. The use of these is prohibited by RFC 8446. To be compliant, these would be removed.

Note that this isn't a simple substitution as implied above. The length fields on all of the messages would also need to be reduced by 8 in addition to making the substitution. The value of the PSK binders used in the resumption case in Section 4 would need to be recalculated also.

RFC 8460, "SMTP TLS Reporting", September 2018

Source of RFC: uta (sec)

Errata ID: 5889
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Scott Kitterman
Date Reported: 2019-10-31
Held for Document Update by: Alexey Melnikov
Date Held: 2020-03-25

Section 6.7 says:

Item is missing entirely

It should say:

6.7 DKIM Service Type

This document registers a new DKIM Service Type in the DomainKeys Identified Mail (DKIM) Parameters registry:

Service Type name: tlsrpt

Reference: RFC 8460

Status Active

Notes:

The new service type is discussed in Section 3, so it should have been added to the registry. It's an IETF Review required registry, not Specification Required, so this can (and should) be addressed in terms at least of the registry now.

Alexey: Murray wrote:

I would guess we can't rectify this oversight via the errata system. What got IETF Review was the need for the registration, but not the registration itself.

I imagine this should either be done through DISPATCH (which is chartered to do minor housekeeping things like this) or through an AD-sponsored document that contains only the registration.

Errata ID: 6241
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Kristian Klausen
Date Reported: 2020-07-27
Held for Document Update by: Barry Leiba
Date Held: 2020-07-29

Section Appendix B. says:

Appendix B.  Example JSON Report
...
     "policies": [{
       "policy": {
...
         "mx-host": "*.mail.company-y.example"
       },
...

It should say:

Appendix B.  Example JSON Report
...
     "policies": [{
       "policy": {
...
         "mx-host": ["*.mail.company-y.example"]
       },
...

Notes:

"mx-host-pattern" is defined as a JSON array

========== Verifier notes ==========
This is right on the edge of "Verified": the reporter is correct about the error, but the existing implementations don't comply with the proposed fix. So this really needs to be dealt with in a document update, rather than through an errata report.

RFC 8466, "A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery", October 2018

Source of RFC: l2sm (ops)

Errata ID: 5921
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexander ("Sasha") Vainshtein
Date Reported: 2019-11-27
Held for Document Update by: Robert Wilton
Date Held: 2024-01-12

Section 8 says:

identity vpws-evpn {
    base service-type;
    description
      "VPWS service type using Ethernet VPNs (EVPNs)
       as specified in RFC 7432.";
  

  identity pbb-evpn {
   base service-type;
    description
      "Provider Backbone Bridge (PBB) service type using
       EVPNs as specified in RFC 7432.";
}

It should say:

identity vpws-evpn {
    base service-type;
    description
      "VPWS service type using Ethernet VPNs (EVPNs)
       as specified in RFC 8214.";
  

  identity pbb-evpn {
   base service-type;
    description
      "Provider Backbone Bridge (PBB) service type using
       EVPNs as specified in RFC 7623.";
}

Notes:

Neither VPWS-EVPN nor PBB-EVPN are mentioned in RFC 7432.
The former is defined in RFC 8214, and the latter - in RFC 7623.

Please note also that RFC 7623 is not mentioned as one of the references.

AD Note: I agree with this errata, but given the change is within a YANG module, it needs a new revision of that YANG module to be published. Hence, I've moved this errata to "Held for Document Update".

Errata ID: 5922
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexander ("Sasha") Vainshtein
Date Reported: 2019-11-27
Held for Document Update by: Robert Wilton
Date Held: 2024-01-12

Section 8 says:

  identity bgp-vpls {
    base service-type;
    description
      "BGP-based multipoint VPLS service type.  This VPLS uses a
       BGP control plane as described in RFCs 4761 and 6624.";
  }

  identity vpws-evpn {
    base service-type;
    description
      "VPWS service type using Ethernet VPNs (EVPNs)
       as specified in RFC 7432.";
  }

It should say:

  identity bgp-vpls {
    base service-type;
    description
      "BGP-based multipoint VPLS service type.  This VPLS uses a
       BGP control plane as described in RFCs 4761 and 6624.";
  }
 identity evpn {
    base service-type;
    description
      " EVPN service type as specified in RFC 7432"
}
  identity vpws-evpn {
    base service-type;
    description
      "VPWS service type using Ethernet VPNs (EVPNs)
       as specified in RFC 7432.";
  }

Notes:

The service type for an EVPN service as defined in RFC 7432 is missing.

It seems likely that a standalone EVPN identity should have been defined, but that cannot be fixed using the errata process. It requires a new version of the YANG module to be published, hence I've moved this to errata report to "Held for Document Update".

Errata ID: 6383
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Julian Lucek
Date Reported: 2021-01-08
Held for Document Update by: Rob Wilton
Date Held: 2023-10-02

Section 8 says:

container service {
              container svc-bandwidth {
                if-feature "input-bw";
                list bandwidth {
                  key "direction type";
                  leaf direction {
                    type identityref {
                      base bw-direction;
                    }
                    description
                      "Indicates the bandwidth direction.  It can be
                       the bandwidth download direction from the SP to
                       the site or the bandwidth upload direction from
                       the site to the SP.";
                  }

Notes:

The svc-bandwidth container is triggered by if-feature "input-bw". However, that container can contain input-bw only, output-bw only or both. It might be better to have two separate containers, one for input-bw and the other for output-bw, triggered by if-feature "input-bw" and if-feature "output-bw" respectively.

The bug looks to be valid, but this erratum has been marked as "Hold For Document Update" because further discussion is required as to the solution, and it will require a new revision of the YANG module which will require a new RFC to be published.

Errata ID: 6699
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Mohamed Boucadair
Date Reported: 2021-10-01
Held for Document Update by: Rob Wilton
Date Held: 2023-10-02

Section 8 says:

                  container lacp {
                    if-feature "lacp";
                    leaf enabled {
                      type boolean;
                      default "false";
                      description
                        "LACP on/off.  By default, LACP is disabled.";
                    }
                    leaf mode {
                      type neg-mode;
                      description
                        "LACP mode.  LACP modes have active mode and
                         passive mode ('false').  'Active mode' means
                         initiating the auto-speed negotiation and
                         trying to form an Ethernet channel with the
                         other end.  'Passive mode' means not initiating
                         the negotiation but responding to LACP packets
                         initiated by the other end (e.g., full duplex
                         or half duplex).";
                    }

It should say:

                  container lacp {
                    if-feature "lacp";
                    leaf enabled {
                      type boolean;
                      default "false";
                      description
                        "LACP on/off.  By default, LACP is disabled.";
                    }
                    leaf mode {
                      type identityref {
                        base lacp-mode;
                      }
                      description
                        "LACP mode. LACP modes have active mode and
                         passive mode ('false').  'Active mode' means
                         initiating the auto-speed negotiation and
                         trying to form an Ethernet channel with the
                         other end.  'Passive mode' means not initiating
                         the negotiation but responding to LACP packets
                         initiated by the other end (e.g., full duplex
                         or half duplex).";
                    }


Also, make this change: 

OLD:

           |  +--rw lag-interfaces {lag-interface}?
           |  |  +--rw lag-interface* [index]
           |  |     +--rw index    string
           |  |     +--rw lacp {lacp}?
           |  |        +--rw enabled?           boolean
           |  |        +--rw mode?              neg-mode

NEW:

           |  +--rw lag-interfaces {lag-interface}?
           |  |  +--rw lag-interface* [index]
           |  |     +--rw index    string
           |  |     +--rw lacp {lacp}?
           |  |        +--rw enabled?           boolean
           |  |        +--rw mode?              identityref

Notes:

The LACP mode can be set to active or passive, which is not what neg-mode is supposed to cover. lacp-mode identity should be used, instead.

The errata looks valid, but given this requires a new revision of the YANG module a new RFC needs to be published.

Errata ID: 6555
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mohamed Boucadair
Date Reported: 2021-04-23
Held for Document Update by: Robert Wilton
Date Held: 2024-01-12

Section 8 says:

                container vxlan {
                  when "derived-from-or-self(../type, "
                     + "'l2vpn-svc:vxlan')" {
                    description
                      "Only applies when the type of the tagged
                       interface is 'vxlan'.";
                  }
                  if-feature "vxlan";
                  leaf vni-id {
                    type uint32;
                    mandatory true;
                    description
                      "VXLAN Network Identifier (VNI).";
                  }
                  leaf peer-mode {
                    type identityref {
                      base vxlan-peer-mode;
                    }
                    default "static-mode";
                    description
                      "Specifies the VXLAN access mode.  By default,
                       the peer mode is set to 'static-mode'.";
                  }
                  list peer-list {
                    key "peer-ip";
                    leaf peer-ip {
                      type inet:ip-address;
                      description
                        "Peer IP.";
                    }
                    description
                      "List of peer IP addresses.";
                  }
                  description
                    "QinQ.";
                }

It should say:

                container vxlan {
                  when "derived-from-or-self(../type, "
                     + "'l2vpn-svc:vxlan')" {
                    description
                      "Only applies when the type of the tagged
                       interface is 'vxlan'.";
                  }
                  if-feature "vxlan";
                  leaf vni-id {
                    type uint32;
                    mandatory true;
                    description
                      "VXLAN Network Identifier (VNI).";
                  }
                  leaf peer-mode {
                    type identityref {
                      base vxlan-peer-mode;
                    }
                    default "static-mode";
                    description
                      "Specifies the VXLAN access mode.  By default,
                       the peer mode is set to 'static-mode'.";
                  }
                  list peer-list {
                    key "peer-ip";
                    leaf peer-ip {
                      type inet:ip-address;
                      description
                        "Peer IP.";
                    }
                    description
                      "List of peer IP addresses.";
                  }
                  description
                    "Container for VXLAN.";
                }

Notes:

The description should refer to VXLAN not QinQ.

AD Note: This errata is correct, but YANG modules cannot be fixed as part of the errata process. A new YANG module revision needs to be published so I have put this errata into "Held for Document Update" state.

Errata ID: 6703
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mohamed Boucadair
Date Reported: 2021-10-05
Held for Document Update by: Rob Wilton
Date Held: 2022-05-19

Section 8 says:

                  leaf pbs {
                    type uint64;
                    units "bps";
                    description
                      "Peak Burst Size.  It is measured in bytes per
                       second.";
                  }

It should say:

                  leaf pbs {
                    type uint64;
                    units "Bytes per Second";
                    description
                      "Peak Burst Size.";
                  }

Notes:

There is a mismatch between the units statement and the description text.

The corrected text assumes that the description reflects the intent. This is the meaning assumed in draft-ietf-opsawg-l2nm

RFC 8469, "Recommendation to Use the Ethernet Control Word", November 2018

Source of RFC: pals (rtg)

Errata ID: 6082
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Michal Dolegowski
Date Reported: 2020-04-09
Held for Document Update by: Deborah Brungard
Date Held: 2020-04-10

Section 3 says:

Thus, if the source MAC address of an Ethernet frame carried over
the PW without a control word present begins with 0x4 or 0x6, it
could be mistaken for an IPv4 or IPv6 packet.  This could,
depending on the configuration and topology of the MPLS network,
lead to a situation where all packets for a given PW do not follow
the same path.

It should say:

Thus, if the destination MAC address of an Ethernet frame carried over
the PW without a control word present begins with 0x4 or 0x6, it
could be mistaken for an IPv4 or IPv6 packet.  This could,
depending on the configuration and topology of the MPLS network,
lead to a situation where all packets for a given PW do not follow
the same path.

Notes:

The first nibble of an Ethernet frame is the first nibble of the destination MAC address, not the source MAC address. The erroneous packet reordering occurs for traffic traveling toward the device with the 0x4... or 0x6... MAC address

RFC 8478, "Zstandard Compression and the application/zstd Media Type", October 2018

Note: This RFC has been obsoleted by RFC 8878

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 5786
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Felix Handte
Date Reported: 2019-07-17
Held for Document Update by: Barry Leiba
Date Held: 2019-07-18

Section 3.1.1.2.3 says:

   A Compressed_Block has the extra restriction that Block_Size is
   always strictly less than the decompressed size.  If this condition
   cannot be respected, the block must be sent uncompressed instead
   (i.e., treated as a Raw_Block).

It should say:

   If this condition cannot be respected when generating a
   Compressed_Block, the block must be sent uncompressed instead
   (i.e., treated as a Raw_Block).

Notes:

The RFC as originally written places a limit on the size of compressed
blocks (that they can be no larger than the compressed content they
represent) above and beyond the restrictions placed on the other block
types.

This restriction does not belong in the spec, and it should be
removed. Here's why:

Under only cursory examination, a rule like this makes sense. A
compressed representation that is larger than the uncompressed content
it represents seems useless, since Zstandard supports raw blocks.
However, even if this were true (which, see below), that reasoning
motivates implementing such a fallback in the compressor, it doesn't
explain why compressors should be required to implement such behavior.

However, this restriction is not actually useful for decoders, and its
removal will not negatively affect decompressors or their
interoperability. All conforming decompressor implementations must
already be prepared to accept blocks, including compressed blocks, up
to the Block_Maximum_Decompressed_Size, so loosening this restriction
will not require them to allocate any more memory than required at
present. And in fact, to the best of my knowledge, no decompressor
implementation currently enforces the restriction in question or has
ever done so in the past.

Finally, this restriction does in fact over-constrain compressors.
Compressed blocks that are larger than the content they represent can
nonetheless have value, when they contain entropy tables (e.g., a
Huffman_Tree_Description), the cost of which is amortized over
subsequent blocks that reuse the same table description.

In short, this change is a safe, strict improvement over the existing
language, which better reflects the reality of implementations, and
which removes a restriction which should never have been in the spec
in the first place.

We've already made this change to the Zstandard format document
maintained in the reference implementation repo[0].

[0] https://github.com/facebook/zstd/blob/dev/doc/zstd_compression_format.md#blocks

===== Verifier Notes =====
All this is fine, but the document says exactly what it was meant to say when it was written; this is not an erratum. This is now on record for discussion if the document is updated.

Errata ID: 6303
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Sean Bartell
Date Reported: 2020-10-07
Held for Document Update by: Barry Leiba
Date Held: 2020-10-08

Section 3.1.1.5 says:

The newest offset takes the lead in offset history, shifting others
back (up to its previous place if it was already present).  This
means that when Repeated_Offset1 (most recent) is used, history is
unmodified.  When Repeated_Offset2 is used, it is swapped with
Repeated_Offset1.  If any other offset is used, it becomes
Repeated_Offset1, and the rest are shifted back by 1.

It should say:

The newest offset takes the lead in offset history, shifting others
back (up to its previous place if the new offset is a repeat offset).
This means that when the new offset is a repeat offset referring to
Repeated_Offset1 (most recent), history is unmodified.
When the new offset is a repeat offset referring to Repeated_Offset2,
it is swapped with Repeated_Offset1.  In any other situation, the new
offset becomes Repeated_Offset1 and the rest are shifted back by 1.

Note that if a non-repeat offset happens to match one of the
Repeated_Offset values, it is treated just like any other non-repeat
offset; all the Repeated_Offset values are shifted back by 1.

The following code demonstrates how an offset_value is decoded into
a NewOffset and the Repeated_Offset values are updated.

if offset_value <= 3:
    if literal_length == 0:
        offset_value = offset_value + 1
    if offset_value == 1:
        NewOffset = Repeated_Offset1
    elif offset_value == 2:
        NewOffset = Repeated_Offset2
        Repeated_Offset2 = Repeated_Offset1
        Repeated_Offset1 = NewOffset
    elif offset_value == 3:
        NewOffset = Repeated_Offset3
        Repeated_Offset3 = Repeated_Offset2
        Repeated_Offset2 = Repeated_Offset1
        Repeated_Offset1 = NewOffset
    elif offset_value == 4:
        NewOffset = Repeated_Offset1 - 1
        if NewOffset == 0:
            # corrupted input
            NewOffset = 1
        Repeated_Offset3 = Repeated_Offset2
        Repeated_Offset2 = Repeated_Offset1
        Repeated_Offset1 = NewOffset
elif offset_value > 3:
    NewOffset = offset_value - 3
    Repeated_Offset3 = Repeated_Offset2
    Repeated_Offset2 = Repeated_Offset1
    Repeated_Offset1 = NewOffset

Notes:

Change the explanation of how Repeated_Offset values are updated in order to match the reference implementation. See https://github.com/facebook/zstd/issues/2346

RFC 8505, "Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery", November 2018

Note: This RFC has been updated by RFC 8928, RFC 8929, RFC 9010

Source of RFC: 6lo (int)

Errata ID: 5557
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Devin Edmison
Date Reported: 2018-11-20
Held for Document Update by: Erik Kline
Date Held: 2021-04-29

Section Abstract says:

This specification updates RFC 6775 -- the Low-Power Wireless
   Personal Area Network (6LoWPAN) Neighbor Discovery specification --
   to clarify the role of the protocol as a registration technique and
   simplify the registration operation in 6LoWPAN routers, as well as to
   provide enhancements to the registration capabilities and mobility
   detection for different network topologies, including the Routing
   Registrars performing routing for host routes and/or proxy Neighbor
   Discovery in a low-power network.

It should say:

This specification updates RFC 6775 -- the Low-Power Wireless
   Personal Area Network (6LoWPAN) Neighbor Discovery specification --
   to clarify the role of the protocol as a registration technique,
   to simplify the registration operation in 6LoWPAN routers, and to
   provide enhancements to the registration capabilities and mobility
   detection for different network topologies, including the Routing
   Registrars performing routing for host routes and/or proxy Neighbor
   Discovery in a low-power network.

Notes:

Change wording to flow in a smooth way.

-----

From https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/

"Changes which are simply stylistic issues or simply make things read better should be Hold for Document Update. "

RFC 8519, "YANG Data Model for Network Access Control Lists (ACLs)", March 2019

Source of RFC: netmod (ops)

Errata ID: 5908
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Fanqiang Kong
Date Reported: 2019-11-14
Held for Document Update by: Robert Wilton
Date Held: 2024-01-12

Section section-4.1 says:

choice l2 {
              container eth {
                when "derived-from-or-self(/acls/acl/type, "
                   + "'acl:eth-acl-type')";
                if-feature "match-on-eth";
                uses pf:acl-eth-header-fields;
                description
                  "Rule set that matches Ethernet headers.";
              }
              description
                "Match Layer 2 headers, for example, Ethernet
                 header fields.";
            }

            choice l3 {
              container ipv4 {
                when "derived-from-or-self(/acls/acl/type, "
                   + "'acl:ipv4-acl-type')";
                if-feature "match-on-ipv4";
                uses pf:acl-ip-header-fields;
                uses pf:acl-ipv4-header-fields;
                description
                  "Rule set that matches IPv4 headers.";
              }

              container ipv6 {
                when "derived-from-or-self(/acls/acl/type, "
                   + "'acl:ipv6-acl-type')";
                if-feature "match-on-ipv6";
                uses pf:acl-ip-header-fields;
                uses pf:acl-ipv6-header-fields;
                description
                  "Rule set that matches IPv6 headers.";
              }
              description
                "Choice of either IPv4 or IPv6 headers";
            }

It should say:

choice l2 {
              container eth {
                when "derived-from-or-self(../../../../type, "
                   + "'acl:eth-acl-type')";
                if-feature "match-on-eth";
                uses pf:acl-eth-header-fields;
                description
                  "Rule set that matches Ethernet headers.";
              }
              description
                "Match Layer 2 headers, for example, Ethernet
                 header fields.";
            }

            choice l3 {
              container ipv4 {
                when "derived-from-or-self(../../../../type, "
                   + "'acl:ipv4-acl-type')";
                if-feature "match-on-ipv4";
                uses pf:acl-ip-header-fields;
                uses pf:acl-ipv4-header-fields;
                description
                  "Rule set that matches IPv4 headers.";
              }

              container ipv6 {
                when "derived-from-or-self(../../../../type, "
                   + "'acl:ipv6-acl-type')";
                if-feature "match-on-ipv6";
                uses pf:acl-ip-header-fields;
                uses pf:acl-ipv6-header-fields;
                description
                  "Rule set that matches IPv6 headers.";
              }
              description
                "Choice of either IPv4 or IPv6 headers";
            }

Notes:

In access-list-control yang definition, the absolute path was used in when derived-from-or-self. This mean it will check all the type in configured acl lists one by one the return the first matched result (If there is any). For examples, I have acls acl acl_test1 configured, and type is set to ipv4-acl-type. Then if I create acl_test2 with ipv6-acl-type, when choice happened in acl_test2, it starts from acl_test1 because it's the first entry for acl list. Choice found there is ipv4-acl-type, then it chooses containter ipv4 rather than ipv6. This is not the correct behivour, it should choose ipv6 container because current acl type is ipv6-acl-type.
I think it should only check the current acl type not the whole acl list. So I changed it to relevant path only match the type field in current acl.
Please review my change and corret me if my understanding is not match your design.
If you need more information, please contact me directly.

AD Note: I agree that the errata is valid, but we cannot update a YANG module revision through the errata process, hence I've moved this errata to "Held for Document Update" so that it can be fixed by publishing a new revision of the YANG module.

RFC 8525, "YANG Library", March 2019

Source of RFC: netconf (ops)

Errata ID: 6484
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Jernej Tuljak
Date Reported: 2021-03-15
Held for Document Update by: Robert Wilton
Date Held: 2024-01-12

Section 4 says:

     revision 2016-04-09 {
       description
         "Initial revision.";
       reference
         "RFC 7895: YANG Module Library";
     }

It should say:

     revision 2016-06-21 {
       description
         "Initial revision.";
       reference
         "RFC 7895: YANG Module Library";
     }

Notes:

Initial revision of ietf-yang-library YANG module was 2016-06-21, not 2016-04-09.

This is a valid issue but fixing it requires a new version of the YANG module to be published, which cannot be done via the errata process, hence resolved as "Held for Document Update".

RFC 8536, "The Time Zone Information Format (TZif)", February 2019

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 6426
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Thomas Conner
Date Reported: 2021-02-12
Held for Document Update by: Barry Leiba
Date Held: 2021-02-21

Section B.3 says:

   | 000    | 54 5a 69 66  | magic            | "TZif"                 |
   | 004    | 33           | version          | '3' (3)                |
   | 005    | 00 00 00 00  |                  |                        |
   |        | 00 00 00 00  |                  |                        |
   |        | 00 00 00 00  |                  |                        |
   |        | 00 00 00     |                  |                        |
   | 020    | 00 00 00 00  | isutccnt         | 0                      |
   | 024    | 00 00 00 00  | isstdcnt         | 0                      |
   | 028    | 00 00 00 00  | isleapcnt        | 0                      |
   | 032    | 00 00 00 00  | timecnt          | 0                      |
   | 036    | 00 00 00 00  | typecnt          | 0                      |
   | 040    | 00 00 00 00  | charcnt          | 0                      |

It should say:

Delete this header.

Notes:

According to section 3.1 p. 6, the typecnt and charcnt fields of the header MUST NOT be zero.

===== Verifier notes =====
There are errors in these tables, but the suggested fix is not correct. There really needs to be a proper update to the document instead.

RFC 8542, "A YANG Data Model for Fabric Topology in Data-Center Networks", March 2019

Source of RFC: i2rs (rtg)

Errata ID: 7055
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Jan Lindblad
Date Reported: 2022-07-29
Held for Document Update by: Alvaro Retana
Date Held: 2022-09-07

Section 4 says:

augment "/nw:networks/nw:network/nw:node" {
  when '/nw:networks/nw:network/nw:network-types/'
     + 'fabric:fabric-network' {
    description
      "Augmentation parameters apply only for networks
       with fabric topology";
  }

It should say:

augment "/nw:networks/nw:network/nw:node" {
  when '../nw:network-types/fabric:fabric-network' {
    description
      "Augmentation parameters apply only for networks
       with fabric topology";
  }

Notes:

The original YANG statements make the augmentation apply to all nw:networks as soon as there is at least one nw:network that is of fabric:fabric-network topo. This is clearly not the author's intent, as proven by the text in the description statement.

The corrected YANG statements make the augmentation only apply to the specific nw:networks that are of fabric topology. There are also other ways to fix this issue.

===
[AD Note] I believe that the original intent was as shown in the corrected text. However, the resolution is not straightforward, and an update may require further consideration in light of the current rules (rfc7950). Therefore, I am marking this report as "Hold for Document Update" [1].

[1] https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/

Errata ID: 7056
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Jan Lindblad
Date Reported: 2022-07-29
Held for Document Update by: Alvaro Retana
Date Held: 2022-09-07

Section 4 says:

augment "/nw:networks/nw:network/nw:node/nt:termination-point" {
  when '/nw:networks/nw:network/nw:network-types/'
     + 'fabric:fabric-network' {
    description
      "Augmentation parameters apply only for networks
       with fabric topology";
  }

It should say:

augment "/nw:networks/nw:network/nw:node/nt:termination-point" {
  when '../../nw:network-types/fabric:fabric-network' {
    description
      "Augmentation parameters apply only for networks
       with fabric topology";
  }

Notes:

The original YANG statements make the augmentation apply to all nw:networks as soon as there is at least one nw:network that is of fabric:fabric-network topo. This is clearly not the author's intent, as proven by the text in the description statement.

The corrected YANG statements make the augmentation only apply to the specific nw:networks that are of fabric topology. There are also other ways to fix this issue.

===
[AD Note] I believe that the original intent was as shown in the corrected text. However, the resolution is not straightforward, and an update may require further consideration in light of the current rules (rfc7950). Therefore, I am marking this report as "Hold for Document Update" [1].

[1] https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/

Errata ID: 7057
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Jan Lindblad
Date Reported: 2022-07-29
Held for Document Update by: Alvaro Retana
Date Held: 2022-09-07

Section Appendix A says:

augment "/nws:networks/nws:network/nws:node" {
  when '/nws:networks/nws:network/nws:network-types'
     + '/sfabric:fabric-network' {
    description
      "Augmentation parameters apply only for
       networks with fabric topology.";
  }

It should say:

augment "/nws:networks/nws:network/nws:node" {
  when '../nws:network-types/sfabric:fabric-network' {
    description
      "Augmentation parameters apply only for
       networks with fabric topology.";
  }

Notes:

The original YANG statements make the augmentation apply to all nws:networks as soon as there is at least one nws:network that is of sfabric:fabric-network topo. This is clearly not the author's intent, as proven by the text in the description statement.

The corrected YANG statements make the augmentation only apply to the specific nws:networks that are of fabric topology. There are also other ways to fix this issue.

===
[AD Note] I believe that the original intent was as shown in the corrected text. However, the resolution is not straightforward, and an update may require further consideration in light of the current rules (rfc7950). Therefore, I am marking this report as "Hold for Document Update" [1].

[1] https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/

RFC 8552, "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", March 2019

Source of RFC: dnsop (ops)

Errata ID: 5665
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ronan Flood
Date Reported: 2019-03-21
Held for Document Update by: Warren Kumari (Ops AD)
Date Held: 2019-04-11

Section 4.1.3 says:

4.1.3.  _ta

   Under the NULL RR Type, the entry "_ta-*" denotes all node names
   beginning with the string "_ta-*".  It does NOT refer to a DNS
   wildcard specification.

It should say:

4.1.3.  _ta

   Under the NULL RR Type, the entry "_ta-*" denotes all node names
   beginning with the string "_ta-".  It does NOT refer to a DNS
   wildcard specification.

Notes:

The second '*' should not be present, as a literal asterisk does not appear in all node names beginning with "_ta-".

RFC 8555, "Automatic Certificate Management Environment (ACME)", March 2019

Source of RFC: acme (sec)

Errata ID: 5979
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: jonathan vanasco
Date Reported: 2020-02-11
Held for Document Update by: Benjamin Kaduk
Date Held: 2020-02-24

Section 7.4 says:

 If the server is willing to issue the requested certificate, it
   responds with a 201 (Created) response.  The body of this response is
   an order object reflecting the client's request and any
   authorizations the client must complete before the certificate will
   be issued.

It should say:

 If the server is willing to issue the requested certificate, it
   responds with a 201 (Created) response.  The body of this response is
   an order object reflecting the client's request and any
   authorizations the client must complete before the certificate will
   be issued. The server returns an order URL in a Location header field.

Notes:

The RFC does not specify/require where the "order URL" is presented. The RFC is very explicit about where other URLs are obtained, and the common understanding is that the URL appears in a Location header after a new-order.

For example:

In 7.3; 7.3.1; 7.3.5, the RFC explicitly declares the account URL is in the Location header field.

In 7.4.1 the RFC is explicit that authorization URLs in pre-authorization appear in the Location header field.

But the order URL is only mentioned by example:

In 7.4, the RFC illustrates the order URL appearing in the Location header field (All clients seem to implement this). In 7.1, the RFC shows a table with "a typical sequence of requests" that note the "account" and "order" URLs appear in the location header field.

The specification should state something to the effect of "The server returns an order URL in a Location header field." making this functionality explicit.

Errata ID: 6030
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Matt Palmer
Date Reported: 2020-03-25
Held for Document Update by: Deb Cooley
Date Held: 2024-03-22

Section 7.2 says:

To get a fresh nonce, the client sends a HEAD request to the newNonce
resource on the server.  The server's response MUST include a Replay-
Nonce header field containing a fresh nonce and SHOULD have status
code 200 (OK).  The server MUST also respond to GET requests for this
resource, returning an empty body (while still providing a Replay-
Nonce header) with a status code of 204 (No Content).

It should say:

To get a fresh nonce, the client sends a HEAD request to the newNonce
resource on the server.  The server's response MUST include a Replay-
Nonce header field containing a fresh nonce and SHOULD have status
code 204 (No Content).  The server MUST also respond to GET requests for this
resource, returning an empty body (while still providing a Replay-
Nonce header) with a status code of 204 (No Content).

Notes:

RFC7321 s4.3.2, says "The server SHOULD send the same header fields in response to a HEAD request as it would have sent if the request had been a GET". I can't see any rationale for violating this SHOULD in the discussion in the GH issue which introduced the discrepancy in response code between GET and HEAD (https://github.com/ietf-wg-acme/acme/pull/371), thus (IMHO) it violates the tenets of a SHOULD, as "the full implications" do not appear to have "be[en] understood and carefully weighed before choosing a different course" (RFC2119, of course).

Errata ID: 6317
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Matthew Holt
Date Reported: 2020-10-23
Held for Document Update by: Roman Danyliw
Date Held: 2024-01-11

Section 7.5.1 says:

The server is said to "finalize" the authorization when it has
completed one of the validations.

It should say:

The server is said to "finalize" the authorization when it has
successfully completed one of the validations or failed all of
them.

Notes:

The current handling of failed challenges is ambiguous, or at least inefficient.

To get a certificate, a client creates an Order. The client then has to validate all Authorizations ("authzs"). For each Authorization, the client needs to successfully complete one of the offered Challenges. One successful Challenge is sufficient to validate the authz. However, currently in practice, one failed Challenge is sufficient to invalidate the authz, and thus the entire Order. To try another Challenge, the client then has to first deactivate the other Authorizations (expensive) and create a new Order (also expensive), then repeat the whole process, remembering what was already tried.

It is proposed that an Authorization MUST NOT be finalized until all possible challenges have failed. The client could then simply try the next Challenge. In other words, a single failed Challenge should not invalidate an authz; an authz should be "pending" until all offered challenges have failed or one has succeeded.

The spec should be clear that a single failed challenge is not sufficient to finalize an authz which has multiple possible challenges.

ACME servers see many, many failed validations. ACME clients need to keep more state. This change will speed up ACME transactions, lower costs for CAs, reduce code complexity, and make ACME more reliable on the whole.

Real-world experience: https://github.com/mholt/acmez/commit/80adb6d5e64a3d36a56c58c66965b131ea366b8c
Mailing list discussion: https://mailarchive.ietf.org/arch/msg/acme/wIHaqikTCZ59zrWsUUus8lZ4VSg/

Errata ID: 6843
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: James Kasten
Date Reported: 2022-02-08
Held for Document Update by: Roman Danyliw
Date Held: 2024-01-11

Section 8.3 says:

Because many web servers
allocate a default HTTPS virtual host to a particular low-privilege
tenant user in a subtle and non-intuitive manner, the challenge must
be completed over HTTP, not HTTPS.

It should say:

Because many web servers
allocate a default HTTPS virtual host to a particular low-privilege
tenant user in a subtle and non-intuitive manner, the challenge must
be initiated over HTTP, not HTTPS.

Notes:

Completing the entire http-01 challenge over HTTP is unnecessary. The threat of default HTTPS virtual hosts is remediated by "initiating" the http-01 challenge over HTTP. Validation servers which redirect from HTTP to HTTPS should be permitted following the rest of the guidance within Section 10, Security Considerations.

Errata ID: 6950
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Lloyd Wood
Date Reported: 2022-05-02
Held for Document Update by: Deb Cooley
Date Held: 2024-03-22

Throughout the document, when it says:

token (required, string):  A random value that uniquely identifies
      the challenge.  This value MUST have at least 128 bits of entropy.

It should say:

token (required, string):  A random value that uniquely identifies
      the challenge.  This value MUST have at least 128 bits of entropy, which in the 
      base64url alphabet means a minimum string length of 22 characters if the full
      scope of the base64url alphabet is in use in the token, by:
                        log2(64^22) = 132 bits of entropy

Notes:

This standards-track document doesn't specify the string ramifications for entropy; I'd expect it to be called out to implementers, just the once, and then referred to later at other tokens.

If entropy is log2 the number of possible characters (64 if full base64url set of chars is in use) then
log2 (64^21) = 126
log2 (64^22) = 132

so a minimum of 22 characters are needed to get a minimum of 128 bits of entropy in the token.

But, if the random value is specified using a subset of the base64url, say because the implementer doesn't like or use CAPITALS or (most likely) the punctuation symbols, then the token must necessarily be longer to meet the local implementer entropy requirement (though just losing only the punctuation marks means you're still good and meet the requirement with 22 characters). Not sure that matters so much on the wire.

I also have editing nits about base64url being defined clearly in ABNF just for Replay-Nonce:, but then both 'base64 alphabet' and 'base64url alphabet' are in use in the document, and base64url references are to RFC4648 via RFC7515, but those are to Base64url, not to base64url... it all seems a bit inconsistent editingwise. So all the references to 'base64 alphabet' should be to 'base64url alphabet' as defined in the doc, but it should really be 'Base64url alphabet' to be consistent with references?

(I really think that it should have been called 'Base-64_url alphabet' way back when to enphasise the punctuation use, but that ship has sailed.)

To me, 'base64 alphabet' is the a-zA-Z subset of base64... I think the document could be much clearer in this regard, and I hope any doc revisions taking into account all the other errata raised consider this too.

My thanks to Lee Maguire for pointing much of this out.

Errata ID: 6276
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: James Manger
Date Reported: 2020-09-03
Held for Document Update by: Benjamin Kaduk
Date Held: 2020-09-04

Section 2 says:

   o  The CA verifies that the client controls the requested domain
      name(s) by having the ACME client perform some action(s) that can
      only be done with control of the domain name(s).  For example, the
      CA might require a client requesting example.com to provision a
      DNS record under example.com or an HTTP resource under
      http://example.com.

It should say:

   o  The CA verifies that the client controls the requested domain
      name(s) by having the ACME client perform some action(s) that can
      only be done with control of the domain name(s).  For example, the
      CA might require a client requesting example.org to provision a
      DNS record under example.org or an HTTP resource under
      http://example.org.

Notes:

The spec consistently uses example.com for an ACME CA server, and example.org for a site requesting a certificate -- except in this sentence.

RFC 8572, "Secure Zero Touch Provisioning (SZTP)", April 2019

Source of RFC: netconf (ops)

Errata ID: 5950
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tetsuya Hasegawa
Date Reported: 2019-12-30
Held for Document Update by: Warren Kumari (Ops AD)
Date Held: 2020-01-05

Section 5.1. Initia says:

   7.  Devices that support decrypting SZTP artifacts MUST posses the

It should say:

   7.  Devices that support decrypting SZTP artifacts MUST possess the

RFC 8610, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", June 2019

Source of RFC: cbor (art)

Errata ID: 6278
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Eric Seppanen
Date Reported: 2020-09-04
Held for Document Update by: Barry Leiba
Date Held: 2020-09-04

Section Appendix B says:

BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / CRLF

It should say:

BCHAR = %x20-26 / %x28-5B / %x5D-7E / %x80-10FFFD / SESC / CRLF

Notes:

Between draft 6 and 7 of the RFC, the ASCII DELETE character 0x7F was excluded from the character set allowed in text literals. I believe it should also be excluded from the character set of bytestring literals.

A 0x7F byte could not be decoded if included in a hex or base64 bytestring, leaving only UTF-8 bytestrings. Since there is no discussion in the text of any reason to allow this character in a UTF-8 bytestring when it was not allowed in a UTF-8 text string, I suspect this was an oversight.

===== Verifier notes =====
It was, indeed, an oversight, but discussion on the CBOR working group list shows that the proper fix is not straightforward, and that it should be handled in the next version of the spec.

Errata ID: 6527
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Sean Bartell
Date Reported: 2021-04-11
Held for Document Update by: Francesca Palombini
Date Held: 2021-04-23

Section B says:

text = %x22 *SCHAR %x22
SCHAR = %x20-21 / %x23-5B / %x5D-7E / %x80-10FFFD / SESC
SESC = "\" (%x20-7E / %x80-10FFFD)

It should say:

SESC = "\" ( %x22 / "/" / "\" /                 ; \" \/ \\
             %x62 / %x66 / %x6E / %x72 / %x74 / ; \b \f \n \r \t
             (%x75 hexchar) )                   ; \u
hexchar = non-surrogate / (high-surrogate "\" %x75 low-surrogate)
non-surrogate = ((DIGIT / "A"/"B"/"C" / "E"/"F") 3HEXDIG) /
               ("D" %x30-37 2HEXDIG )
high-surrogate = "D" ("8"/"9"/"A"/"B") 2HEXDIG
low-surrogate = "D" ("C"/"D"/"E"/"F") 2HEXDIG

Notes:

As discussed during the CBOR interim 2021-04-21 and in the mailing list: https://mailarchive.ietf.org/arch/msg/cbor/ljHAiw-WhNqoIKAzkjZa4WIf56Q/
--
The ABNF used in [RFC8610] for the content of text string literals is rather permissive:

text = %x22 *SCHAR %x22
SCHAR = %x20-21 / %x23-5B / %x5D-7E / %x80-10FFFD / SESC
SESC = "\" (%x20-7E / %x80-10FFFD)

This allows almost any non-C0 character to be escaped by a backslash, but critically misses out on the \uXXXX and \uHHHH\uLLLL forms that JSON allows to specify characters in hex. Both can be solved by updating the SESC production to:

SESC = "\" ( %x22 / "/" / "\" / ; \" \/ \\
%x62 / %x66 / %x6E / %x72 / %x74 / ; \b \f \n \r \t
(%x75 hexchar) ) ; \u
hexchar = non-surrogate / (high-surrogate "\" %x75 low-surrogate)
non-surrogate = ((DIGIT / "A"/"B"/"C" / "E"/"F") 3HEXDIG) /
("D" %x30-37 2HEXDIG )
high-surrogate = "D" ("8"/"9"/"A"/"B") 2HEXDIG
low-surrogate = "D" ("C"/"D"/"E"/"F") 2HEXDIG

Now that SESC is more restrictively formulated, this also requires an update to the BCHAR production used in the ABNF syntax for byte string literals:

bytes = [bsqual] %x27 *BCHAR %x27
BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / CRLF
bsqual = "h" / "b64"
The updated version explicit allows \', which is no longer allowed in the updated SESC:

BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / "\'" / CRLF

Errata ID: 6543
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Sean Bartell
Date Reported: 2021-04-13
Held for Document Update by: Francesca Palombini
Date Held: 2021-04-23

Section B says:

     bytes = [bsqual] %x27 *BCHAR %x27
     BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / CRLF

It should say:

     bytes = %x27 *BCHAR %x27
           / bsqual %x27 *QCHAR %x27
     BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / CRLF
     QCHAR = DIGIT / ALPHA / "+" / "/" / "-" / "_" / "=" / WS

Notes:

As discussed during the CBOR interim 2021-04-21 and in the mailing list: https://mailarchive.ietf.org/arch/msg/cbor/ekFn8a4GbUQAk4nyhc-Il-ZRLZc/
--

The ABNF used in [RFC8610] for the content of byte string literals lumps together byte strings notated as text with byte strings notated in base16 (hex) or base64 (but see also updated BCHAR production above):

bytes = [bsqual] %x27 *BCHAR %x27
BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / CRLF

Errata report 6543 proposes to handle the two cases in separate productions (where, with an updated SESC, BCHAR obviously needs to be updated as above):

bytes = %x27 *BCHAR %x27
/ bsqual %x27 *QCHAR %x27
BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / CRLF
QCHAR = DIGIT / ALPHA / "+" / "/" / "-" / "_" / "=" / WS

This potentially causes a subtle change, which is hidden in the WS production:

WS = SP / NL
SP = %x20
NL = COMMENT / CRLF
COMMENT = ";" *PCHAR CRLF
PCHAR = %x20-7E / %x80-10FFFD
CRLF = %x0A / %x0D.0A

This allows any non-C0 character in a comment, so this fragment becomes possible:

foo = h'
43424F52 ; 'CBOR'
0A ; LF, but don't use CR!
'

The current text is not unambiguously saying whether the three apostrophes need to be escaped with a \ or not, as in:

foo = h'
43424F52 ; \'CBOR\'
0A ; LF, but don\'t use CR!
'
... which would be supported by the existing ABNF in [RFC8610].

Errata ID: 6575
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Laurence Lundblade
Date Reported: 2021-05-06
Held for Document Update by: Francesca Palombini
Date Held: 2022-06-01

Section 2.2.3 says:

   Where a major type of 6 (Tag) is used, the type
   of the tagged item can be specified by appending it in parentheses.

It should say:

   Where a major type of 6 (Tag) is used, the type 
   of the tagged item can be specified by appending it in parentheses.
   Additionally, for major type 6 the value of the argument, not the 
   additional info is what follows the dot.

Notes:

The text at the top of page 50 is correct. The examples in 2.2.3 are also correct.

See https://mailarchive.ietf.org/arch/msg/cbor/0fhPGMaG1-TPmKlgKnP7iA2lb9M/ for discussion in the working group.

RFC 8639, "Subscription to YANG Notifications", September 2019

Source of RFC: netconf (ops)

Errata ID: 6211
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: kent watsen
Date Reported: 2020-06-22
Held for Document Update by: Robert Wilton
Date Held: 2024-01-12

Section 7 says:

   A specification for a transport MUST identify any encodings that are
   supported.  If a configured subscription's transport allows different
   encodings, the specification MUST identify the default encoding.

It should say:

   A specification for a transport MUST identify any encodings that are
   supported.  If a configured subscription's transport allows different
   encodings, the specification MUST identify the default encoding, or
   provide a mechanism whereby supported encodings can be discovered.

Notes:

https://mailarchive.ietf.org/arch/msg/netconf/XBpoFqtRynfc0zaRggMEiEMBW2M/

RFC 8713, "IAB, IESG, IETF Trust, and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees", February 2020

Note: This RFC has been updated by RFC 9389

Source of RFC: iasa2 (gen)

Errata ID: 7092
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Rich Salz
Date Reported: 2022-08-16
Held for Document Update by: Lars Eggert
Date Held: 2023-08-11

Section 4.17 says:

If the Chair is unable to contact a voting volunteer, the Chair must
repeat the random selection process in order to replace the unavailable
volunteer.  There should be at least one day between the announcement of
the iteration and the selection process.

It should say:

TBD

Notes:

Historically, it appears that NomCom chairs treat "can't contact" as "ineligible" and just move down the list. This also appears to be IETF consensus.

Was the intent to really announce seed source, wait, pick them, re-run the process? If so, how long to wait for objections? This needs much more clarification. For example, a timeline of how long to take if following RFC 3797.

Errata ID: 7274
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Rich Salz
Date Reported: 2022-12-14
Held for Document Update by: Lars Eggert
Date Held: 2023-08-11

Section 5.10 says:

The call for nominees must include a request for comments regarding the
past performance of incumbents, which will be considered during the
deliberations of the NomCom.

The call must request that a nomination include a valid, working email
address, a telephone number, or both for the nominee. The nomination
must include the set of skills or expertise the nominator believes the
nominee has that would be desirable.

It should say:

Delete them.

Notes:

The last two paragraphs in the section have not been followed by any recent committees. A possible reason for this is use of questionnaires, required by all, to contain contact information; and interviews. In other words, "overtaken by events."

Errata ID: 7300
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Rich Salz
Date Reported: 2023-01-05
Held for Document Update by: Lars Eggert
Date Held: 2023-08-11

Section 5.15 says:

A nominee may not know they were a candidate. This permits a candidate
to be rejected by a confirming body without the nominee knowing about
the rejection.

It should say:

Delete.

Notes:

We do not have "private" nominees any more. All candidates are posted on the website, comments from the IETF community are solicited multiple times, each cnadidate must have an interview with NomCom and respond to a questionnaire. While there is some interest, scattered, in getting rid of the questionnaire, the concept of "nominee didn't know they were nominated" is clearly outdated.

Errata ID: 7174
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Rich Salz
Date Reported: 2022-10-20
Held for Document Update by: Lars Eggert
Date Held: 2023-08-11

Section 3.7.3 says:

The sitting IAB members review the IESG candidates.

It should say:

The sitting IAB members review the IESG candidates
(including IETF Chair).

Notes:

Sometimes IETF Chair is mentioned and sometimes Gen AD is mentioned;
the clarification avoids confusion.

Errata ID: 7270
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Rich Salz
Date Reported: 2022-12-13
Held for Document Update by: Lars Eggert
Date Held: 2023-08-11

Section 3.7.3 says:

The IETF LLC Director candidate is reviewed as specified in [RFC8711].

It should say:

The IETF LLC Director candidate is reviewed as specified in Section 6.1
of [RFC8711].

Notes:

This document uses "LLC Director" which seems to be outdated; LLC Board Member is more common.

However, in the original text, adding a reference to the specific section is very useful.

Errata ID: 7273
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Rich Salz
Date Reported: 2022-12-14
Held for Document Update by: Lars Eggert
Date Held: 2023-08-11

Section 3.7.3 says:

The IETF LLC Director candidate is reviewed as specified in [RFC8711].

It should say:

The IETF LLC Director candidate is reviewed as specified in
Section 6.1 of [RFC8711].

Notes:

The two documents often use different terms for the same thing. Having an explicit section reference will save the reader time.

Errata ID: 7275
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Rich Salz
Date Reported: 2022-12-14
Held for Document Update by: Lars Eggert
Date Held: 2023-08-11

Section 5.13 says:

A nominee's consent must be written (email is acceptable) and must
include a commitment to provide the resources necessary to fill the open
position and an assurance that the nominee will perform the duties of
the position for which they are being considered in the best interests
of the IETF community.

It should say:

Delete

Notes:

This third paragraph from 5.13 is not appropriate. Recent nomcom's solicit that information during the interview and questionnaire responses.

RFC 8714, "Update to the Process for Selection of Trustees for the IETF Trust", February 2020

Source of RFC: iasa2 (gen)

Errata ID: 7137
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Lars Eggert
Date Reported: 2022-09-21
Held for Document Update by: RFC Editor
Date Held: 2022-09-26

Section 3 says:

Trustees appointed by the IESG or by the ISOC Board of
Directors may be recalled by the appointing body. 

It should say:

Trustees appointed by the IESG or by the ISOC Board of
Trustees may be recalled by the appointing body. 

Notes:

ISOC has a Board of Trustees, not a Board of Directors.

--VERIFIER NOTES--
Status changed to HFDU per input from Ted Hardie

RFC 8774, "The Quantum Bug", April 2020

Source of RFC: INDEPENDENT

Errata ID: 6075
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Pickle Surprise
Date Reported: 2020-04-01
Held for Document Update by: Adrian Farrel
Date Held: 2020-04-01

Section Abstract says:

   This
   will lead to a perceived round-trip time of zero seconds on some
   Internet paths, a capability which was not predicted and so not
   included as a possibility in many protocol specifications.

It should say:

Suggested text...
   The
   no communication theorem holds, and there will be no perceived
   round-trip time of zero seconds on some Internet paths, a
   capability which was not predicted and so not included as a
   possibility in many protocol specifications.

Notes:

This report has been marked as "held for document update" so that the authors can consider it when a revision to the RFC is made.
At that time, the authors may want to think about the following points:
- The original text says "perceived round-trip time of zero seconds". Of course, the
perception of a zero round-trip time says nothing about the actual time: none of
the laws of physics apply to perception.
- The well-known "no-communication theorem" is predicated on the assumption
that the laws of quantum mechanics hold, but that it is clearly not the case on
March 32nd.
- The proof of the no-communication theorem depends on an understanding of
Hilbert Space. Mr Space is notably hard to comprehend.
- The no-communication theorem is classically described in relation to
communications between Alice and Bob, but we know that the Internet is For All,
and so our concerns should extend wider than just Alice and Bob to include
Charlie, Daphne, Eustace, and Felicity.
- The proof of the no-communication theorem depends on the Born rule, but while
there is one Born every minute, it is generally accepted that there is no change
through the Born identity.

RFC 8794, "Extensible Binary Meta Language", July 2020

Source of RFC: cellar (art)

Errata ID: 7191
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Steve Lhomme
Date Reported: 2022-10-30
Held for Document Update by: Murray Kucherawy
Date Held: 2024-02-29

Section 5. says:

      +=========================+================+=================+
      | Element ID Octet Length | Range of Valid | Number of Valid |
      |                         |  Element IDs   |     Element IDs |
      +=========================+================+=================+
      |            1            |  0x81 - 0xFE   |             126 |
      +-------------------------+----------------+-----------------+

It should say:

      +=========================+================+=================+
      | Element ID Octet Length | Range of Valid | Number of Valid |
      |                         |  Element IDs   |     Element IDs |
      +=========================+================+=================+
      |            1            |  0x80 - 0xFE   |             127 |
      +-------------------------+----------------+-----------------+

Notes:

0x80 is allowed in Matroska so in EBML as well.

See https://github.com/ietf-wg-cellar/ebml-specification/pull/414

RFC 8824, "Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)", June 2021

Source of RFC: lpwan (int)

Errata ID: 7623
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Ana Minaburo
Date Reported: 2023-08-31
Held for Document Update by: Éric Vyncke
Date Held: 2024-01-12

Section Section 7.1 says:

Table 3 

Field	        FL	FP	DI	TV	MO	CDA	Sent [bits]
CoAP Uri-Path	var	1	Dw	path	equal 1	not-sent	

It should say:

Table 3 

Field	        FL	FP	DI	TV	    MO	  CDA	Sent [bits]
CoAP 
Uri-Path	var	1	Dw    1st. element  equal not-sent
                                      of the path		

Notes:

A MO 'equal 1' has not been defined in the possibilities of SCHC. However, when this table was written and never updated, it was one option to say that we wanted to check only the first element. To comply with the RFC8724, the idea of only matching the first element of the path needs to be expressed in the corrected text way.

---- verifier note ---
Let's indeed fix this in draft-ietf-schc-8824-update

Errata ID: 7390
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT, PDF
Reported By: Marco Tiloca
Date Reported: 2023-03-19
Held for Document Update by: Éric Vyncke
Date Held: 2023-08-02

Section 5.1 says:

CoAP Content and Accept Options

It should say:

CoAP Option Content-Format and Accept Fields

Notes:

The new title of Section 5.1 uses the correct CoAP option name "Content-Format", and is consistent with the title of other sections.

Errata ID: 7393
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT, PDF
Reported By: Marco Tiloca
Date Reported: 2023-03-19
Held for Document Update by: Éric Vyncke
Date Held: 2023-08-02

Section 6.4 says:

Figure 4 shows the OSCORE option value encoding defined in
Section 6.1 of [RFC8613], where the first byte specifies the content
of the OSCORE options using flags.

It should say:

Figure 4 shows the OSCORE option value encoding defined in
Section 6.1 of [RFC8613], where the first byte specifies the content
of the OSCORE option using flags.

Notes:

The end of the sentence should still refer to a single OSCORE option, i.e., in the singular.

RFC 8832, "WebRTC Data Channel Establishment Protocol", January 2021

Source of RFC: rtcweb (wit)

Errata ID: 6411
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Victor Boivie
Date Reported: 2021-01-25
Held for Document Update by: Francesca Palombini
Date Held: 2023-11-07

Section 5 says:

5.  Message Formats

   Every Data Channel Establishment Protocol message starts with a one
   byte field called "Message Type" which indicates the type of the
   message.  The corresponding values are managed by IANA (see
   Section 8.2.1).

It should say:

5.  Message Formats

   Every Data Channel Establishment Protocol message starts with a one
   byte field called "Message Type" which indicates the type of the
   message.  The corresponding values are managed by IANA (see
   Section 8.2.1).

   All integer fields in an Data Channel Establishment Protocol message
   MUST be transmitted in network byte order, unless otherwise stated.

Notes:

Submitter's note: The byte order of integer fields in the protocol messages is not defined.
---
Verifier's note: the byte order in the protocol messages is defined, since Data Channel Establishment Protocol depends on SCTP, which requires Network Byte Order (RFC 4960, Section 3). However, since this could be considered an omission that might have been corrected if it had been caught at the time of publication, I am marking it "Hold for document update".

RFC 8894, "Simple Certificate Enrolment Protocol", September 2020

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 7550
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Simone Guidi
Date Reported: 2023-06-23
Held for Document Update by: Paul Wouters
Date Held: 2024-01-17

Section 3.1 says:

Once the messageData has been encrypted, it is signed with the
sender's public key.

It should say:

Once the messageData has been encrypted, it is signed with the
sender's private key.

Notes:

The sender should use their private key, rather than their public key, to sign the data.

RFC 8895, "Application-Layer Traffic Optimization (ALTO) Incremental Updates Using Server-Sent Events (SSE)", November 2020

Source of RFC: alto (ops)

Errata ID: 7398
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Mohamed Boucadair
Date Reported: 2023-03-20
Held for Document Update by: Martin Duke
Date Held: 2024-01-18

Section 8.1 says:

     "my-network-map": {
       "uri": "https://alto.example.com/networkmap",
       "media-type": "application/alto-networkmap+json",
     },
     ...

It should say:

     "my-network-map": {
       "uri": "https://alto.example.com/networkmap",
       "media-type": "application/alto-networkmap+json"
     },
     ...

Notes:

The OLD text includes a trailing ","

RFC 8906, "A Common Operational Problem in DNS Servers: Failure to Communicate", September 2020

Source of RFC: dnsop (ops)

Errata ID: 7689
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Josh Soref
Date Reported: 2023-10-26
Held for Document Update by: Warren Kumari (Ops AD)
Date Held: 2024-01-29

Section 8.2.8 says:

expect: DO=1 to be present if an RRSIG is in the response

It should say:

expect: flag: do to be present if an RRSIG is in the response

Notes:

The same section has `expect: flag: aa to be present`, and when running the suggested command, no `DO=1` is shown, which makes the advice unhelpful.

Sample command:
```
$ dig +nocookie +edns=0 +noad +norec +dnssec soa $zone @$server

; <<>> DiG 9.16.44-Debian <<>> +nocookie +edns +noad +norec +dnssec soa powerdns.com @2600:3c03::f03c:91ff:fe55:e54d
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 45268
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;powerdns.com. IN SOA

;; Query time: 0 msec
;; SERVER: 2600:3c03::f03c:91ff:fe55:e54d#53(2600:3c03::f03c:91ff:fe55:e54d)
;; WHEN: Thu Oct 26 22:26:44 UTC 2023
;; MSG SIZE rcvd: 41
```

[ WK: For more info, see thread: https://mailarchive.ietf.org/arch/msg/dnsop/gA71yLWLZ8-eylYgKjNy9emP9hU/

It was also suggested that reminding readers that "@$server" in this case refers to an
authoritative server, and not a recursive server - See Sec 8 ]

RFC 8912, "Initial Performance Metrics Registry Entries", November 2021

Source of RFC: ippm (ops)

Errata ID: 6755
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Nikolai Malykh
Date Reported: 2021-11-27
Held for Document Update by: Martin Duke
Date Held: 2022-05-13

Section 5.3.5 says:

5.3.5.  Runtime Parameters and Data Format

   Src:  The IP address of the host in the Src Role (format
      ipv4-address-no-zone value for IPv4 or ipv6-address-no-zone value
      for IPv6; see Section 4 of [RFC6991]).

It should say:

5.3.5.  Runtime Parameters and Data Format

   Runtime Parameters are input factors that must be determined,
   configured into the measurement system, and reported with the results
   for the context to be complete.

   Src:  The IP address of the host in the Src Role (format
      ipv4-address-no-zone value for IPv4 or ipv6-address-no-zone value
      for IPv6; see Section 4 of [RFC6991]).

Notes:

Skipped paragraph.

=======
01/24/22: RFC Editor changed type to technical and asked the TSV ADs to review - nope this is editorial; this explanatory paragraph is in all the counterpart sections, but just missed here.

RFC 8932, "Recommendations for DNS Privacy Service Operators", October 2020

Source of RFC: dprive (int)

Errata ID: 6629
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Joeri de Ruiter
Date Reported: 2021-07-05
Held for Document Update by: Eric Vyncke
Date Held: 2021-07-05

Section B.1. says:

One example would be to replace all TCP/UDP port
numbers with one of two fixed values indicating whether the
original port was ephemeral (>=1024) or nonephemeral (>1024).

It should say:

One example would be to replace all TCP/UDP port
numbers with one of two fixed values indicating whether the
original port was ephemeral (>=1024) or nonephemeral (<1024).

Notes:

Nonephemeral port numbers are <1024

--- Verifier note ---
The errata is indeed a real typo. As it is in appendix, "held for document update" was selected.

RFC 8944, "A YANG Data Model for Layer 2 Network Topologies", November 2020

Source of RFC: i2rs (rtg)

Errata ID: 6951
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Mohammed Riyas Valiyapalathingal
Date Reported: 2022-05-03
Held for Document Update by: Alvaro Retana
Date Held: 2022-06-22

Section 4 says:

augment "/nw:networks/nw:network" {
 when '/nw:networks/nw:network/nw:network-types/l2t:l2-topology' {
   description
     "Augmentation parameters apply only for networks
      with L2 topology.";
 }
 description
   "Configuration parameters for the L2 network
    as a whole.";
 uses l2-topology-attributes;
}
augment "/nw:networks/nw:network/nw:node" {
 when '/nw:networks/nw:network/nw:network-types/l2t:l2-topology' {
   description
     "Augmentation parameters apply only for networks
      with L2 topology.";
 }
 description
   "Configuration parameters for L2 at the node
    level.";
 uses l2-node-attributes;
}
augment "/nw:networks/nw:network/nt:link" {
 when '/nw:networks/nw:network/nw:network-types/l2t:l2-topology' {
   description
     "Augmentation parameters apply only for networks
      with L2 topology.";
 }
 description
   "Augments L2 topology link information.";
 uses l2-link-attributes;
}
augment "/nw:networks/nw:network/nw:node/nt:termination-point" {
 when '/nw:networks/nw:network/nw:network-types/l2t:l2-topology' {
   description
     "Augmentation parameters apply only for networks
      with L2 topology.";
 }
 description
   "Augments L2 topology termination point information.";
 uses l2-termination-point-attributes;
}

It should say:

augment "/nw:networks/nw:network" {
  when 'nw:network-types/l2t:l2-topology' {
    description
      "Augmentation parameters apply only for networks
       with L2 topology.";
  }
  description
    "Configuration parameters for the L2 network
     as a whole.";
  uses l2-topology-attributes;
}
augment "/nw:networks/nw:network/nw:node" {
  when '../nw:network-types/l2t:l2-topology' {
    description
      "Augmentation parameters apply only for networks
       with L2 topology.";
  }
  description
    "Configuration parameters for L2 at the node
     level.";
  uses l2-node-attributes;
}
augment "/nw:networks/nw:network/nt:link" {
  when '../nw:network-types/l2t:l2-topology' {
    description
      "Augmentation parameters apply only for networks
       with L2 topology.";
  }
  description
    "Augments L2 topology link information.";
  uses l2-link-attributes;
}
augment "/nw:networks/nw:network/nw:node/nt:termination-point" {
  when '../../nw:network-types/l2t:l2-topology' {
    description
      "Augmentation parameters apply only for networks
       with L2 topology.";
  }
  description
    "Augments L2 topology termination point information.";
  uses l2-termination-point-attributes;
}

Notes:

With absolute XPaths on the augmentations, the meaning becomes “augment nw:network with l2-topology-attributes if ANY network in the list of networks has l2t:l2-topology”.
With that meaning, the following json snippet passes validation when it should not.
It has 2 instances of ietf-network, one at L2 and one at L3. L2 attributes are WRONGLY added to the L3 network and L3 node.

{
"ietf-network:networks": {
"network": [
{
"network-id": "l2-network",
"network-types": {
"ietf-l2-topology:l2-topology": {}
},
"node": [
{
"node-id": "l2-node"
}
]
},
{
"network-id": "l3-network",
"network-types": {
"ietf-l3-unicast-topology:l3-unicast-topology": {}
},
"ietf-l2-topology:l2-topology-attributes": {
"name": "L2Topology"
},
"node": [
{
"node-id": "l3-node",
"ietf-l2-topology:l2-node-attributes" : {
"name": "l2-node-name",
"management-address": [
"1.1.1.1"
],
"management-mac": "11:22:33:aa:bb:cc"
}
}
]
}
]
}
}

With relative XPaths as suggested, the meaning becomes “augment only if THIS network has l2t:l2-topology” and the json snippet above fails validation, as it should.

RFC 8960, "A YANG Data Model for MPLS Base", December 2020

Source of RFC: mpls (rtg)

Errata ID: 7059
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Jan Lindblad
Date Reported: 2022-07-29
Held for Document Update by: James N Guichard
Date Held: 2023-05-31

Section 2.5 says:

        augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/"
              + "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" {
          description
            "Augments the 'simple-next-hop' case in IP unicast routes.";
          uses nhlfe-single-contents {
            when "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route"
               + "/mpls:mpls-enabled = 'true'";
          }
        }

It should say:

        augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/"
              + "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" {
          description
            "Augments the 'simple-next-hop' case in IP unicast routes.";
          uses nhlfe-single-contents {
            when "../../../mpls:mpls-enabled = 'true'";
          }
        }

Notes:

The original YANG statements make the "uses" statement apply to all rt:rib and all rt:route instances as soon as there is at least one instance that has mpls:mpls-enabled set to true. I suspect this is not the author's intent.

The corrected YANG statements make the "uses" statement only apply to the specific route instances that have mpls:mpls-enabled set to true. There are also other ways to fix this issue.

Errata ID: 7060
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Jan Lindblad
Date Reported: 2022-07-29
Held for Document Update by: James N Guichard
Date Held: 2023-05-31

Section 2.5 says:

  augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/"
        + "rt:next-hop/rt:next-hop-options/rt:next-hop-list/"
        + "rt:next-hop-list/rt:next-hop" {
    description
      "This leaf augments the 'next-hop-list' case of IP unicast
       routes.";
    uses nhlfe-multiple-contents {
      when "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route"
         + "/mpls:mpls-enabled = 'true'";
    }
  }

It should say:

  augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/"
        + "rt:next-hop/rt:next-hop-options/rt:next-hop-list/"
        + "rt:next-hop-list/rt:next-hop" {
    description
      "This leaf augments the 'next-hop-list' case of IP unicast
       routes.";
    uses nhlfe-multiple-contents {
      when "../../../../../mpls:mpls-enabled = 'true'";
    }
  }

Notes:

The original YANG statements make the "uses" statement apply to all rt:rib and all rt:route instances as soon as there is at least one instance that has mpls:mpls-enabled set to true. I suspect this is not the author's intent.

The corrected YANG statements make the "uses" statement only apply to the specific route instances that have mpls:mpls-enabled set to true. There are also other ways to fix this issue.

RFC 8962, "Establishing the Protocol Police", April 2021

Source of RFC: INDEPENDENT

Errata ID: 6516
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Ap Ril Fools
Date Reported: 2021-04-05
Held for Document Update by: Adrian Farrel
Date Held: 2021-04-18

Section 10 says:

All your networks are belong to us.

It should say:

All your network are belong to us.

Notes:

=~ "all your base are belong to us"

The Protocol Police have launched an investigation and will act when the time is right.

RFC 8994, "An Autonomic Control Plane (ACP)", May 2021

Source of RFC: anima (ops)

Errata ID: 7558
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: J. William Atwood
Date Reported: 2023-07-02
Held for Document Update by: Rob Wilton
Date Held: 2024-01-15

Section 6.2.1 says:

   ACP nodes MUST NOT support certificates with RSA public keys of less
   than a 2048-bit modulus or curves with group order of less than 256
   bits.  They MUST support certificates with RSA public keys with
   2048-bit modulus and MAY support longer RSA keys.  They MUST support
   certificates with ECC public keys using NIST P-256 curves and SHOULD
   support P-384 and P-521 curves.

   ACP nodes MUST NOT support certificates with RSA public keys whose
   modulus is less than 2048 bits, or certificates whose ECC public keys
   are in groups whose order is less than 256 bits.  RSA signing
   certificates with 2048-bit public keys MUST be supported, and such
   certificates with longer public keys MAY be supported.  ECDSA
   certificates using the NIST P-256 curve MUST be supported, and such
   certificates using the P-384 and P-521 curves SHOULD be supported.

It should say:

   ACP nodes MUST NOT support certificates with RSA public keys whose
   modulus is less than 2048 bits, or certificates whose ECC public keys
   are in groups whose order is less than 256 bits.  RSA signing
   certificates with 2048-bit public keys MUST be supported, and such
   certificates with longer public keys MAY be supported.  ECDSA
   certificates using the NIST P-256 curve MUST be supported, and such
   certificates using the P-384 and P-521 curves SHOULD be supported.

Notes:

The second paragraph in the original text appears to be a more carefully-written version of the first paragraph. Therefore the first paragraph should be deleted and the second paragraph retained.

RFC 8995, "Bootstrapping Remote Secure Key Infrastructure (BRSKI)", May 2021

Source of RFC: anima (ops)

Errata ID: 6642
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT, HTML
Reported By: Michael Richardson
Date Reported: 2021-07-14
Held for Document Update by: Rob Wilton
Date Held: 2024-01-15

Section 5.4 says:

Use of TLS 1.3 (or newer) is encouraged.  TLS 1.2 or newer is 
REQUIRED.  TLS 1.3 (or newer) SHOULD be available.

It should say:

TLS 1.2 [RFC5246] with SNI support [RFC6066] is REQUIRED if 
TLS 1.3 is not available.
The Server Name Indicator (SNI) is required when the Registrar 
communicates with the MASA in order for the MASA to be hosted in 
a modern multi-tenant TLS infrastructure.

Notes:

https://mailarchive.ietf.org/arch/msg/anima/bqrZXAk7vstWQ3V1-irIATnBKpY/
This adds new references to the text.

Errata ID: 6649
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Michael Richardson
Date Reported: 2021-07-27
Held for Document Update by: Rob Wilton
Date Held: 2024-01-15

Section 5.5.4. says:

Even when a domain CA is authenticated to the MASA, and there is
strong sales channel integration to understand who the legitimate
owner is, the above id-kp-cmcRA check prevents arbitrary end-entity
certificates (such as an LDevID certificate) from having vouchers
issued against them.

It should say:

Even when a domain CA is authenticated to the MASA, and there is
strong sales channel integration to understand who the legitimate
owner is, the above id-kp-cmcRA check prevents arbitrary end-entity
certificates (such as an LDevID certificate) from having vouchers
issued against them.

add:
The id-kp-cmcRA is an Extended Key Usage (EKU) attribute.
When any EKU attribute it set, then the certificate MUST have all 
related attributes set.  
This means that the Registrar certificate MUST also have the 
id-kp-clientAuth (for use with the MASA) and the id-kp-serverAuth 
(for use with the Pledge) set.

Notes:

https://mailarchive.ietf.org/arch/msg/anima/H6Xs_f3rQAh9acOEFXEYuoZZGls/

RFC 8996, "Deprecating TLS 1.0 and TLS 1.1", March 2021

Source of RFC: tls (sec)

Errata ID: 7769
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Martin Thomson
Date Reported: 2021-03-23
Held for Document Update by: Paul Wouters
Date Held: 2024-01-17

Section 1.1 says:

ServerHello.Random

It should say:

ServerHello.random 

Notes:

Very pedantic, but RFC 8446 uses all lowercase for "random" to match the grammar.

Paul Wouters (AD): RFC 8446 itself actually also has this problem once in Section 4.1.3

RFC 9000, "QUIC: A UDP-Based Multiplexed and Secure Transport", May 2021

Source of RFC: quic (wit)

Errata ID: 7578
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Marten Seemann
Date Reported: 2023-07-30
Held for Document Update by: Zaheduzzaman Sarker
Date Held: 2024-01-29

Section 17.2.1 says:

                                                       Where QUIC
   might be multiplexed with other protocols (see [RFC7983]), servers
   SHOULD set the most significant bit of this field (0x40) to 1 so that
   Version Negotiation packets appear to have the Fixed Bit field.

It should say:

                                                       Unless the
   server has out-of-band knowledge that clients are not
   demultiplexing QUIC with other protocols (see [RFC7983]), it
   SHOULD set the most significant bit of this field (0x40) to 1 so that
   Version Negotiation packets appear to have the Fixed Bit field.

Notes:

Unless operating in a tightly controlled environment, the server has no way of knowing what other protocols the client might be demultiplexing on the same UDP socket. According to the demultiplexing logic defined in RFC 9443, Version Negotiation packets with 0x40 set to 0 would be misclassified as RTP/RTCP.

Looking at the discussion in https://mailarchive.ietf.org/arch/msg/quic/oR4kxGKY6mjtPC1CZegY1ED4beg/ and IETF118 QUIC working group meeting minutes. This needs more discussion to reach a conclusion on the potential solution.

Errata ID: 7374
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Bob Briscoe
Date Reported: 2023-02-27
Held for Document Update by: Zaheduzzaman Sarker
Date Held: 2023-05-29

Section 13.4.1 says:

                                                               If an
   endpoint does not implement ECN support or does not have access to
   received ECN fields, it does not report ECN counts for packets it
   receives.

   Even if an endpoint does not set an ECT field in packets it sends,
   the endpoint MUST provide feedback about ECN markings it receives, if
   these are accessible.  

It should say:

                                                               If an
   endpoint does not have access to
   received ECN fields, it does not report ECN counts for packets it
   receives.

   Even if an endpoint does not set an ECT field in packets it sends,
   the endpoint MUST provide feedback about ECN markings it receives, if
   these are accessible.  

Notes:

In the second sentence, the only allowed exception to "MUST provide feedback about received ECN markings" is inaccessibility. The first sentence contradicts this by allowing two exceptions: inaccessibility and just "not implementing ECN support".

If "not implementing ECN support" was really intended to be an allowed exception, the capitalized "MUST" would have been pointless.

Therefore it is proposed that the words "does not implement ECN support or " are deleted from the first paragraph.

NOTE : Based on discussion in https://mailarchive.ietf.org/arch/msg/quic/lsz4X-cZql71Ba56uQhNQz4NzGc/ , the error type is changed from technical to editorial.

RFC 9051, "Internet Message Access Protocol (IMAP) - Version 4rev2", August 2021

Source of RFC: extra (art)

Errata ID: 6826
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Hontvári Levente
Date Reported: 2022-02-02
Held for Document Update by: Murray Kucherawy
Date Held: 2023-07-28

Throughout the document, when it says:

   18.  RFC822, RFC822.HEADER, and RFC822.TEXT FETCH data items were
        deprecated.  Clients should use the corresponding BODY[]
        variants instead.

It should say:

   18.  RFC822, RFC822.HEADER, and RFC822.TEXT FETCH data items were
        removed. Clients should use the corresponding BODY[]
        variants instead.

Notes:

Contrary to the original text, these data items are not deprecated but they were completely removed from the text of the RFC. As far as I see other deprecated items are not removed completely but moved to a '...obsolete...' token in the formal syntax.

RFC 9067, "A YANG Data Model for Routing Policy", October 2021

Source of RFC: rtgwg (rtg)

Errata ID: 6844
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Kris Lambrechts
Date Reported: 2022-02-10
Held for Document Update by: Alvaro Retana
Date Held: 2022-02-11

Section 7.2. grouping prefix says:

       leaf mask-length-upper {
         type uint8 {
           range "1..128";
         }

It should say:

       leaf mask-length-upper {
         type uint8 {
           range "0..128";
         }

Notes:

With the original definition, it is not possible to specify an exact match for the default routes (0.0.0.0/0 and ::/0) which is a valid use case.

===== AD Note ====
This report is valid, but the resolution requires an update to the YANG model and not just a text correction.

RFC 9094, "A YANG Data Model for Wavelength Switched Optical Networks (WSONs)", August 2021

Source of RFC: ccamp (rtg)

Errata ID: 7054
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Jan Lindblad
Date Reported: 2022-07-29
Held for Document Update by: John Scudder
Date Held: 2022-09-06

Section 3 says:

  augment "/nw:networks/nw:network/nw:node/tet:te"
        + "/tet:te-node-attributes" {
    when '/nw:networks/nw:network/nw:network-types'
       + '/tet:te-topology/wsont:wson-topology' {
      description
        "Augmentation parameters apply only for networks with
         WSON topology type.";
    }

It should say:

  augment "/nw:networks/nw:network/nw:node/tet:te"
        + "/tet:te-node-attributes" {
    when '../../../nw:network-types/tet:te-topology/'
       + 'wsont:wson-topology' {
      description
        "Augmentation parameters apply only for networks with
         WSON topology type.";
    }

Notes:

The original YANG statements make the augmentation apply to all nw:networks as soon as there is at least one nw:network that is of wsont:wson-topology. This is clearly not the author's intent, as proven by the text in the description statement.

The corrected YANG statements make the augmentation only apply to the specific nw:networks that are of wsont:wson-topology type. There are also other ways to fix this issue.

(See also discussion at https://mailarchive.ietf.org/arch/msg/ccamp/9-8jHMSqp_Lqdu0XMuVkh8HaJN8/)

RFC 9098, "Operational Implications of IPv6 Packets with Extension Headers", September 2021

Source of RFC: v6ops (ops)

Errata ID: 6689
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Stéphane Bortzmeyer
Date Reported: 2021-09-20
Held for Document Update by: Warren Kumari (Ops AD)
Date Held: 2024-01-15

Section 7.2 says:

  If a forwarding router cannot determine consistent n-tuples for
   calculating flow hashes, data streams are more likely to end up being
   distributed unequally across ECMP and load-shared links.  This may
   lead to packet drops or reduced performance.

It should say:

[None]

Notes:

The paragraph seems to belong to 7.1 (ECMP and load blanacing) since it is not related to the subject in 7.2 (ACL and filtering). But there is a very similar paragraph in 7.1 so the best solution is probably to delete the whole paragraph.

RFC 9171, "Bundle Protocol Version 7", January 2022

Source of RFC: dtn (int)

Errata ID: 7881
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: John Huff
Date Reported: 2024-04-03
Held for Document Update by: Erik Kline
Date Held: 2024-04-07

Section 6.1.1 says:

   The first element of each bundle status item SHALL be a status
   indicator, a Boolean value indicating whether or not the
   corresponding bundle status is asserted, encoded as a CBOR Boolean
   value.

It should say:

   The first element of each bundle status item SHALL be a status
   indicator, a Boolean value indicating whether or not the
   corresponding bundle status is asserted, encoded as a CBOR simple
   value.  A value of 'true' SHALL be encoded as a CBOR simple value
   with additional information 21.  A value of 'false' SHALL be encoded
   as a CBOR simple value with additional information 20.

Notes:

The CBOR spec does not define a 'Boolean' type (RFC8949). It's become common practice to encode boolean values as simple values (major type 7), with additional information 21 indicating 'true' and additional information 20 indicating 'false' (RFC9254, RFC8152). However, this should be explicitly stated for clarity.

--- comments ---

The original text refers to "Boolean values" and not to any "Boolean type"; it is technically correct as is.

As noted, CBOR doesn't have a specific "type" per se for a Boolean, but RFC 8948 S3.3 clearly specifies an encoding for `true` and `false`.

That said, there might be room here for additional clarity for implementers if there is ever to be a 9171bis.

RFC 9204, "QPACK: Field Compression for HTTP/3", June 2022

Source of RFC: quic (wit)

Errata ID: 7277
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Rory Hewitt
Date Reported: 2022-12-15
Held for Document Update by: Francesca Palombini
Date Held: 2024-01-30

Section Appendix A says:

In the static table, entry 73 has a value of:

access-control-allow-credentials: TRUE

and entry 74 has a value of:

access-control-allow-credentials: FALSE

It should say:

Entry 73 should have a value of:

access-control-allow-credentials: true

(note the lower-case value of "true")

and entry 74 should NOT EXIST since "FALSE" (in upper-case
or lower-case) is not a valid value for this header.

Notes:

The "access-control-allow-credentials" header is a CORS header. It only has one allowed value - "true" (without quotes, MUST be in lower-case). Values of "TRUE", "FALSE" and "false" are all invalid values, as is any mixed-case version of "true".

See the latest WHATWG spec at https://fetch.spec.whatwg.org/#cors-protocol-and-credentials which notes the required case-sensitivity of the "true" value and that it is the only valid value.

Also see the prior W3C spec at https://www.w3.org/TR/2020/SPSD-cors-20200602/#access-control-allow-credentials-response-header which says the same thing. Note that the W3C spec was superseded by the WHATWG spec.

Note that there are many instances of "access-control-allow-credentials: false" being returned from server responses (which is presumably why these values were added to the table), but they are invalid and the servers that send them are not following the CORS specification.

There may be case to be made that the static table is defined to make the QPACK algorithm as performant as possible and therefore it should include not only commonly-used valid values, but also commonly-used invalid values. However, the static table should ideally contain only valid header values.

-- Verifier notes
See https://mailarchive.ietf.org/arch/msg/quic/tgmjRvHDPev-mjPQWEM_zqRn5LE/

RFC 9249, "A YANG Data Model for NTP", July 2022

Source of RFC: ntp (int)

Errata ID: 7401
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Maurice Angermann
Date Reported: 2023-03-21
Held for Document Update by: Erik Kline
Date Held: 2023-03-21

Section 8 says:

  identity hmac-sha-256 {
    description
      "HMAC-SHA-256 authentication algorithm";
    reference
      "SHS: Secure Hash Standard (SHS) (FIPS PUB 180-4)";
  }

  identity hmac-sha-384 {
    description
      "HMAC-SHA-384 authentication algorithm";
    reference
      "SHS: Secure Hash Standard (SHS) (FIPS PUB 180-4)";
  }

  identity hmac-sha-512 {
    description
      "HMAC-SHA-512 authentication algorithm";
    reference
      "SHS: Secure Hash Standard (SHS) (FIPS PUB 180-4)";
  }

It should say:

  identity hmac-sha-256 {
    base crypto-algorithm;
    description
      "HMAC-SHA-256 authentication algorithm";
    reference
      "SHS: Secure Hash Standard (SHS) (FIPS PUB 180-4)";
  }

  identity hmac-sha-384 {
    base crypto-algorithm;
    description
      "HMAC-SHA-384 authentication algorithm";
    reference
      "SHS: Secure Hash Standard (SHS) (FIPS PUB 180-4)";
  }

  identity hmac-sha-512 {
    base crypto-algorithm;
    description
      "HMAC-SHA-512 authentication algorithm";
    reference
      "SHS: Secure Hash Standard (SHS) (FIPS PUB 180-4)";
  }

Notes:

The identity definitions of "hmac-sha-256", "hmac-sha-384" and "hmac-sha-512" lack the "base crypto-algorithm;" statement and therefore basically cannot be used in the scope of ietf-ntp@2022-07-05.yang.

RFC 9277, "On Stable Storage for Items in Concise Binary Object Representation (CBOR)", August 2022

Source of RFC: cbor (art)

Errata ID: 7144
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Thomas Fossati
Date Reported: 2022-10-04
Held for Document Update by: Francesca Palombini
Date Held: 2023-03-15

Section Appendix D says:

As with the Labeled CBOR Sequence {#sequences}, this choice of the
tag content places the ASCII characters "CBOR" prominently into the
header.

It should say:

As with the Labeled CBOR Sequence (Section 2.3), this choice of the
tag content places the ASCII characters "CBOR" prominently into the
header.

Notes:

It looks like a typo in the markdown (a missing pair of curly brackets) managed to trickle through the publication process.

RFC 9280, "RFC Editor Model (Version 3)", June 2022

Source of RFC: IAB

Errata ID: 7795
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Eliot Lear
Date Reported: 2024-02-03
Held for Document Update by: Mirja Kühlewind (IAB and RSAB chair)
Date Held: 2024-03-11

Section 8 says:

   Updates, amendments, and refinements to this document can be produced
   using the process documented herein but shall be published and
   operative only after (a) obtaining the agreement of the IAB and the
   IESG and (b) ensuring that the IETF LLC has no objections regarding
   its ability to implement any proposed changes.

It should say:

   Updates, amendments, and refinements to this document can be
   produced using the process documented herein but, unless otherwise
   specified in this document, shall be published and operative only
   after (a) obtaining the agreement of the IAB and the IESG and (b)
   ensuring that the IETF LLC has no objections regarding its ability
   to implement any proposed changes.

Notes:

Section 7 explicitly states:

"Proposals that affect these properties are possible within the processes defined in this document."

And it goes on from there to discuss RSWG/RSAB review.

Therefore, it should not be necessary for the IAB, IESG, and LLC to approve changes in Section 7. That is just a for-instance. There may be other examples.

Verifier Note: Given the text in section 7, the process is clear and this is therefore not an errata. However, this could be further clarified in a document update.

RFC 9350, "IGP Flexible Algorithm", February 2023

Source of RFC: lsr (rtg)

Errata ID: 7376
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Nikolai Malykh
Date Reported: 2023-03-04
Held for Document Update by: John Scudder
Date Held: 2023-03-06

Section 6 says:

   One of the limitations of IS-IS [ISO10589] is that the length of a
   TLV/sub-TLV is limited to a maximum of 255 octets.  For the FAD sub-
   TLV, there are a number of sub-sub-TLVs (defined below) that are
   supported.  For a given Flex-Algorithm, it is possible that the total
   number of octets required to completely define a FAD exceeds the
   maximum length supported by a single FAD sub-TLV.  In such cases, the
   FAD MAY be split into multiple such sub-TLVs, and the content of the
   multiple FAD sub-TLVs are combined to provide a complete FAD for the
   Flex-Algorithm.  In such a case, the fixed portion of the FAD (see
   Section 5.1) MUST be identical in all FAD sub-TLVs for a given Flex-
   Algorithm from a given IS.  

It should say:

   One of the limitations of IS-IS [ISO10589] is that the length of a
   TLV/sub-TLV is limited to a maximum of 255 octets.  For the FAD sub-
   TLV, there are a number of sub-sub-TLVs (defined below) that are
   supported.  For a given Flex-Algorithm, it is possible that the total
   number of octets required to completely define a FAD exceeds the
   maximum length supported by a single FAD sub-TLV.  In such cases, the
   FAD MAY be split into multiple such sub-TLVs, and the content of the
   multiple FAD sub-TLVs are combined to provide a complete FAD for the
   Flex-Algorithm.  In such a case, the fixed portion of the FAD (see
   Section 5.1) MUST be identical in all FAD sub-TLVs for a given Flex-
   Algorithm from a given IS (Intermediate System).

Notes:

Although "IS" is listed in https://www.rfc-editor.org/materials/abbrev.expansion.txt as well-known, this evidently confused at least one reader, so it seems worth expanding on first use. See also https://mailarchive.ietf.org/arch/msg/lsr/LICQJ8U3cBAY9Z1LHMfAI4v7xRg/

RFC 9457, "Problem Details for HTTP APIs", July 2023

Source of RFC: httpapi (wit)

Errata ID: 7731
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Roman Kovařík
Date Reported: 2023-12-14
Held for Document Update by: Francesca Palombini
Date Held: 2023-12-18

Appendix A says:

# NOTE: '\' line wrapping per RFC 8792
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "An RFC 7807 problem object",
  "type": "object",
  "properties": {
    "type": {
      "type": "string",
      "format": "uri-reference",
      "description": "A URI reference that identifies the \
problem type."
    },
    "title": {
      "type": "string",
      "description": "A short, human-readable summary of the \
problem type."
    },
    "status": {
      "type": "integer",
      "description": "The HTTP status code \
generated by the origin server for this occurrence of the problem.",
      "minimum": 100,
      "maximum": 599
    },
    "detail": {
      "type": "string",
      "description": "A human-readable explanation specific to \
this occurrence of the problem."
    },
    "instance": {
      "type": "string",
      "format": "uri-reference",
      "description": "A URI reference that identifies the \
specific occurrence of the problem. It may or may not yield \
further information if dereferenced."
    }
  }
}

It should say:

# NOTE: '\' line wrapping per RFC 8792
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "An RFC 7807 problem object",
  "type": "object",
  "properties": {
    "type": {
      "type": "string",
      "format": "uri-reference",
      "description": "A URI reference that identifies the \
problem type."
    },
    "title": {
      "type": "string",
      "description": "A short, human-readable summary of the \
problem type."
    },
    "status": {
      "type": "integer",
      "description": "The HTTP status code \
generated by the origin server for this occurrence of the problem.",
      "minimum": 100,
      "maximum": 599
    },
    "detail": {
      "type": "string",
      "description": "A human-readable explanation specific to \
this occurrence of the problem."
    },
    "instance": {
      "type": "string",
      "format": "uri-reference",
      "description": "A URI reference that identifies the \
specific occurrence of the problem. It may or may not yield \
further information if dereferenced."
    }
  },
  "additionalProperties": true
}

Notes:

The document is correct, however in the example it would have been nice to have "additionalProperties": true explicitly stated.

See: https://mailarchive.ietf.org/arch/msg/httpapi/fj9TAH6my-kmw7wA_KOlVKCF_V8/

RFC 9493, "Subject Identifiers for Security Event Tokens", December 2023

Source of RFC: secevent (sec)

Errata ID: 7727
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Atul Tulshibagwale
Date Reported: 2023-12-11
Held for Document Update by: Paul Wouters
Date Held: 2024-04-05

Throughout the document, when it says:

Security Event Identifier Formats

It should say:

Subject Identifier Formats

Notes:

The identifiers described in the RFC are relating to subject fields in Security Event Tokens, and not to the Security Event Tokens as a whole. This is clearly stated in the first sentence of Section 1 (Introduction) and the first sentence of the second paragraph of Section 1 (Introduction).

Therefore, the registry defined in Section 8.1 should be named "Subject Identifier Formats", and not "Security Event Identifier Formats".

Paul Wouters(AD): See https://mailarchive.ietf.org/arch/msg/id-event/-S-MsO2W6PeFF_O5kjP8om-7QNM/

Status: Rejected (964)

RFC 88, "NETRJS: A third level protocol for Remote Job Entry", January 1971

Note: This RFC has been obsoleted by RFC 189

Source of RFC: Legacy

Errata ID: 4612
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Wang Haojian
Date Reported: 2016-02-05
Rejected by: John Scudder
Date Rejected: 2024-01-12

Section F says:

Record Format

It should say:

F. Record Format

Notes:

There should be "F"
--VERIFIER NOTES--
Looks correct, but rejected per https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/ guideline 7.

RFC 586, "Traffic statistics (October 1973)", November 1973

Source of RFC: Legacy

Errata ID: 7171
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: bossbitxh52
Date Reported: 2022-10-17
Rejected by: John Scudder
Date Rejected: 2024-01-12

Section 10.3.1 says:

Section 10.3.1 says:

    4. The contributor represents that contribution properly
       acknowledge major contributors.

    5. The contribuitor, the organization (if any) he represents and
       the owners of any proprietary rights in the contribution, agree
       that no information in the contribution is confidential and
       that the ISOC and its affiliated organizations may freely
       disclose any information in the contribution.

It should say:

It should say:

    4. The contributor represents that the contribution properly
       acknowledges major contributors.

    5. The contributor, the organization (if any) he represents and
       the owners of any proprietary rights in the contribution, agree
       that no information in the contribution is confidential and
       that the ISOC and its affiliated organizations may freely
       disclose any information in the contribution

Notes:

Notes:

verb agreement ("acknowledges") and spelling correction ("contributor")
--VERIFIER NOTES--
This erratum appears to be a mistake, RFC 586 doesn't contain the quoted text.

RFC 791, "Internet Protocol", September 1981

Note: This RFC has been updated by RFC 1349, RFC 2474, RFC 6864

Source of RFC: Legacy
Area Assignment: int

Errata ID: 3874
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Bo-Jhang Ho
Date Reported: 2014-01-23
Rejected by: Ted Lemon
Date Rejected: 2014-05-01

Section 3 says:

    The number 576 is selected to allow a reasonable sized data block to
    be transmitted in addition to the required header information.  For
    example, this size allows a data block of 512 octets plus 64 header
    octets to fit in a datagram.  The maximal internet header is 60
    octets, and a typical internet header is 20 octets, allowing a
    margin for headers of higher level protocols.

It should say:

    The number 576 is selected to allow a reasonable sized data block to
    be transmitted in addition to the required header information.  For
    example, this size allows a data block of 516 octets plus 60 header
    octets to fit in a datagram.  The maximal internet header is 60
    octets, and a typical internet header is 20 octets, allowing a
    margin for headers of higher level protocols.

Notes:

It is not consistent that it first give an example which illustrates the header is 64 octets, but then explains the maximum header size is 60 octets.
--VERIFIER NOTES--
I believe that the discrepancy you are seeing is because in the one case the text is referring to the set of all headers, and in the other case it's referring to the IP header alone. The IP header does have a maximum size of 60 octets, but for example an IP header plus a UDP header would be 28 octets, and IP+TCP would be 40 octets, plus a timestamp header in current practice. Notice the "for example" at the beginning of the sentence that mentions 64 header octets.

Errata ID: 5038
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Prabhu K Lokesh
Date Reported: 2017-06-10
Rejected by: Suresh Krishnan
Date Rejected: 2020-03-25

Section 3.1 says:

The option begins with the option type code.  The second octet
        is the option length which includes the option type code and the
        length octet, the pointer octet, and length-3 octets of route
        data.

It should say:

The option begins with the option type code.  The second octet
        is the option length, measured in octets, including the option 
        type code octet, the length octet, the pointer octet, and the
        octets of route data.

Notes:

The way the second octet is defined, although readable to majority of the audience with no concern, will incorrectly equate to:
length = 'option type code octet' + 'length octet + 'pointer octet' + length - 3 octet of route data

So, what is the value of 'length' in 'length - 3'; when reader encounters 'length - 3', the term 'length' itself is not completely defined. Using the term 'length - 3' to define the term 'length' may not be very appropriate.

For better readability, we can simply write -
The second octet is the option length, measured in octets, including the option type code octet, the length octet, the pointer octet, and the octets of route data.

The same correction applies to the following sections -
3.1. Internet Header Format > Loose Source and Record Route
3.1. Internet Header Format > Strict Source and Record Route
3.1. Internet Header Format > Record Route
--VERIFIER NOTES--
While the text can be simplified as the submitter of the Erratum implies, the current text has been in use for close to 4 decades without any interoperability issues rising out of it. Hence this

Errata ID: 6677
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Øyvind Bolme Fredriksen
Date Reported: 2021-09-06
Rejected by: Erik Kline
Date Rejected: 2023-06-10

Section 3.1 says:

Protocol:  8 bits

    This field indicates the next level protocol used in the data
    portion of the internet datagram.  The values for various protocols
    are specified in "Assigned Numbers" [9].

It should say:

Protocol:  8 bits

    This field indicates the next upper level protocol used in the data
    portion of the internet datagram.  The values for various protocols
    are specified in "Assigned Numbers" [9], section ASSIGNED INTERNET PROTOCOL NUMBERS.

Notes:

The word 'next' is ambiguous in the sense that it does not indicate whether the 'next' protocol is at the next LOWER or UPPER level (referring to Fig. 1). Although it may be obvious to people well versed in this domain that the next UPPER level protocol is meant, as a newcomer I had to think twice to reach at this conclusion.

Also, the reference to [9] could be more specific.
--VERIFIER NOTES--
The description of the Protocol field states that it refers to the protocol "used in the data portion of the internet datagram". In the context of Figure 1, this cannot refer to a lower layer protocol.

RFC 793, "Transmission Control Protocol", September 1981

Note: This RFC has been obsoleted by RFC 9293

Note: This RFC has been updated by RFC 1122, RFC 3168, RFC 6093, RFC 6528

Source of RFC: Legacy
Area Assignment: tsv

Errata ID: 784
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Ian D. Allen
Date Reported: 2006-09-22
Rejected by: Lars Eggert
Date Rejected: 2008-12-06

Section 3.2 says:

                              +---------+ ---------\      active OPEN  
                              |  CLOSED |            \    -----------  
                              +---------+<---------\   \   create TCB  
                                |     ^              \   \  snd SYN    
                   passive OPEN |     |   CLOSE        \   \           
                   ------------ |     | ----------       \   \         
                    create TCB  |     | delete TCB         \   \       
                                V     |                      \   \     
                              +---------+            CLOSE    |    \   
                              |  LISTEN |          ---------- |     |  
                              +---------+          delete TCB |     |  
                   rcv SYN      |     |     SEND              |     |  
                  -----------   |     |    -------            |     V  
 +---------+      snd SYN,ACK  /       \   snd SYN          +---------+
 |         |<-----------------           ------------------>|         |
 |   SYN   |                    rcv SYN                     |   SYN   |
 |   RCVD  |<-----------------------------------------------|   SENT  |
 |         |                    snd ACK                     |         |
 |         |------------------           -------------------|         |
 +---------+   rcv ACK of SYN  \       /  rcv SYN,ACK       +---------+
   |           --------------   |     |   -----------                  
   |                  x         |     |     snd ACK                    
   |                            V     V                                
   |  CLOSE                   +---------+                              
   | -------                  |  ESTAB  |                              
   | snd FIN                  +---------+                              
   |                   CLOSE    |     |    rcv FIN                     
   V                  -------   |     |    -------                     
 +---------+          snd FIN  /       \   snd ACK          +---------+
 |  FIN    |<-----------------           ------------------>|  CLOSE  |
 | WAIT-1  |------------------                              |   WAIT  |
 +---------+          rcv FIN  \                            +---------+
   | rcv ACK of FIN   -------   |                            CLOSE  |  
   | --------------   snd ACK   |                           ------- |  
   V        x                   V                           snd FIN V  
 +---------+                  +---------+                   +---------+
 |FINWAIT-2|                  | CLOSING |                   | LAST-ACK|
 +---------+                  +---------+                   +---------+
   |                rcv ACK of FIN |                 rcv ACK of FIN |  
   |  rcv FIN       -------------- |    Timeout=2MSL -------------- |  
   |  -------              x       V    ------------        x       V  
    \ snd ACK                 +---------+delete TCB         +---------+
     ------------------------>|TIME WAIT|------------------>| CLOSED  |
                              +---------+                   +---------+

                      TCP Connection State Diagram
                               Figure 6.

It should say:

[not supplied]

Notes:

Compare with RFC 1122:

" 4.2.2.8 TCP Connection State Diagram: RFC-793 Section 3.2,
page 23

There are several problems with this diagram:

(a) The arrow from SYN-SENT to SYN-RCVD should be labeled
with "snd SYN,ACK", to agree with the text on page 68
and with Figure 8."

Either RFC1122 is wrong (in which case *it* needs an Errata entry), or
RFC793 is wrong, in which case *it* needs an Errata entry. They can't
both be right!

Because of the above protocol diagram change given in RFC1122 (and others
in the same section), RFC1122 should also be mentioned as "updating"
RFC793, and RFC793 should be documented as being "updated by" RFC1122.

from pending
--VERIFIER NOTES--
The RFC Editor has been instructed to indicate in their database and web pages that RFC1122 updates RFC0793. This errata has hence been addressed.

Errata ID: 1496
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Yin Shuming
Date Reported: 2008-08-27
Rejected by: Wes Eddy
Date Rejected: 2011-08-13

Section 3.9 says:

CLOSE CALL


  CLOSE-WAIT STATE
    Queue this request until all preceding SENDs have been segmentized;then send a FIN segment,enter CLOSING state.

  CLOSING STATE
  LAST-ACK STATE
  TIME-WAIT STATE
  
    Respond with "error: connection closing".

It should say:

CLOSE CALL


  CLOSE-WAIT STATE
    Queue this request until all preceding SENDs have been segmentized;then send a FIN segment,enter LAST-ACK  state.

  CLOSING STATE
  LAST-ACK STATE
  TIME-WAIT STATE
  
    Respond with "error: connection closing".

Notes:

In Page 23,Figure 6."TCP Connection State Diagram",illustrates the state change from "CLOSE-WAIT" TO "LAST-ACK",together with the causing event "CLOSE".
--VERIFIER NOTES--
RFC 1122 updates RFC 793 and includes the changes noted in this errata already in section 4.2.2.20.

Errata ID: 1563
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Rejected by: Wes Eddy
Date Rejected: 2011-08-13

Section 3.4 says:

Reset Generation
    3.  If the connection is in a synchronized state (ESTABLISHED,
    FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT),
    any unacceptable segment (out of window sequence number or
    unacceptible acknowledgment number) must elicit only an empty
    acknowledgment segment containing the current send-sequence number
    and an acknowledgment indicating the next sequence number expected
    to be received, and the connection remains in the same state.

    If an incoming segment has a security level, or compartment, or
    precedence which does not exactly match the level, and compartment,
    and precedence requested for the connection,a reset is sent and
    connection goes to the CLOSED state. The reset takes its sequence
    number from the ACK field of the incoming segment.

It should say:

Reset Generation
    3.  If the connection is in a synchronized state (ESTABLISHED,
    FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT),
    any unacceptable segment (out of window sequence number or
    unacceptable acknowledgment number) must elicit only an empty
    acknowledgment segment containing the current send-sequence number
    and an acknowledgment indicating the next sequence number expected
    to be received, and the connection remains in the same state.

    If an incoming segment has a security level, or compartment, or
    precedence which does not exactly match the level, and compartment,
    and precedence requested for the connection, a reset is sent and
    the connection goes to the CLOSED state.
    If the incoming segment has the ACK bit set, the reset takes its
    sequence number from the ACK field of the segment, otherwise the
    reset has sequence number zero and the ACK field is set to the sum
    of the sequence number and segment length of the incoming segment.
    A SYN with a sequence number inside the receive window yields a
    reset, too.

Notes:

Four errors, two editorial and two technical
1. Typo unacceptible -> unacceptable
2. wrong spacing and missing 'the'
3. The ACK bit should be set. But this check comes later. See page 71.
4. According to page 71 a SYN can cause a reset, too.
--VERIFIER NOTES--
I split the editorial corrections into another errata report and accepted them as "hold for document update". The technical corrections are being rejected due to RFC 1122 updating 793 and already including clarification on setting SEQ=0 and ACK=SEG.SEQ+SEG.LEN, as suggested by this errata submission.

Errata ID: 1566
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Rejected by: Wes Eddy
Date Rejected: 2011-08-13

Section 3.9 says:

OPEN Call
LISTEN STATE
      Data associated with SEND may be sent with SYN segment or
      queued for transmission after entering ESTABLISHED state.  The
      urgent bit if requested in the command must be sent with the data
      segments sent as a result of this command.

It should say:

OPEN Call
LISTEN STATE
      --delete this--

Notes:

This is an OPEN call. There is no data associated with a SEND.
BTW, What WND to set in the SYN segment? Set RCV.WND=1?
--VERIFIER NOTES--
This is "may" and does not produce incorrect protocol behavior, so there is no reason to remove it. This rejection was validated through consulting with the TCPM list.

Errata ID: 1567
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Rejected by: Wesley Eddy
Date Rejected: 2012-05-29

Section 3.9 says:

SEND Call
LISTEN STATE
      If the foreign socket is specified, then change the connection
      from passive to active, select an ISS.  Send a SYN segment, set
      SND.UNA to ISS, SND.NXT to ISS+1.  Enter SYN-SENT state.  Data
      associated with SEND may be sent with SYN segment or queued for
      transmission after entering ESTABLISHED state.  The urgent bit if
      requested in the command must be sent with the data segments sent
      as a result of this command.  If there is no room to queue the
      request, respond with "error:  insufficient resources".  If
      Foreign socket was not specified, then return "error:  foreign
      socket unspecified".

It should say:

SEND Call
LISTEN STATE
      If the foreign socket is specified, then change the connection
      from passive to active, select an ISS.  Send a SYN segment, set
      SND.UNA to ISS, SND.NXT to ISS+1.  Enter SYN-SENT state.  Data
      associated with SEND may be sent with SYN segment or queued for
      transmission after entering ESTABLISHED state. If data is sent with
      the SYN segment, SND.NXT is advanced.    The urgent bit if
      requested in the command must be sent with the data segments sent
      as a result of this command.  If there is no room to queue the
      request, respond with "error:  insufficient resources".  If
      Foreign socket was not specified, then return "error:  foreign
      socket unspecified".

Notes:

If data is sent, SND.NXT has to be advanced.

But there are more problems.
What WND to set in the SYN segment? Set RCV.WND=1?
How much data may be put into the segment? There is no SND.WND yet.
What about PUSH? May the data be queued if a PUSH is given?
--VERIFIER NOTES--
As discussed on the TCPM Working Group mailing list in 2012:

According to the errata, there is some ambiguity in RFC 793 regarding data in SYNs.
This requires changes beyond the suggested errata text, and thus we believe
this issue should be done in a separate RFC.

Errata ID: 1568
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Rejected by: Wesley Eddy
Date Rejected: 2012-05-29

Section 3.9 says:

SEGMENT ARRIVES
 If the state is LISTEN then
  third check for a SYN
        The connection
        state should be changed to SYN-RECEIVED.  Note that any other
        incoming control or data (combined with SYN) will be processed
        in the SYN-RECEIVED state, but processing of SYN and ACK should
        not be repeated.
  fourth other text or control
        Any other control or text-bearing segment (not containing SYN)
        must have an ACK and thus would be discarded by the ACK
        processing.  An incoming RST segment could not be valid, since
        it could not have been sent in response to anything sent by this
        incarnation of the connection.  So you are unlikely to get here,
 If the state is SYN-SENT then
  first check the ACK bit
        If SND.UNA =< SEG.ACK =< SND.NXT then the ACK is acceptable.
  fourth check the SYN bit
        This step should be reached only if the ACK is ok, or there is
        no ACK, and it the segment did not contain a RST.

        If the SYN bit is on and the security/compartment and precedence
        are acceptable then, RCV.NXT is set to SEG.SEQ+1, IRS is set to
        SEG.SEQ.
        ...
        Data or controls which were queued for
        transmission may be included.
  fifth, if neither of the SYN or RST bits is set then drop the
        segment and return.
 Otherwise,
  third check security and precedence
  fifth check the ACK field,
   SYN-RECEIVED STATE
    If SND.UNA =< SEG.ACK =< SND.NXT then enter ESTABLISHED state
    and continue processing.
    If the segment acknowledgment is not acceptable, form a
    reset segment,

      <SEQ=SEG.ACK><CTL=RST>

    and send it.
   ESTABLISHED STATE
    If SND.UNA < SEG.ACK =< SND.NXT then, set SND.UNA <- SEG.ACK.
    Any segments on the retransmission queue which are thereby
    entirely acknowledged are removed.  Users should receive
    positive acknowledgments for buffers which have been SENT and
    fully acknowledged (i.e., SEND buffer should be returned with
    "ok" response).  If the ACK is a duplicate
    (SEG.ACK < SND.UNA), it can be ignored.  If the ACK acks
    something not yet sent (SEG.ACK > SND.NXT) then send an ACK,
    drop the segment, and return.

    If SND.UNA < SEG.ACK =< SND.NXT, the send window should be
    updated.  If (SND.WL1 < SEG.SEQ or (SND.WL1 = SEG.SEQ and
    SND.WL2 =< SEG.ACK)), set SND.WND <- SEG.WND, set
    SND.WL1 <- SEG.SEQ, and set SND.WL2 <- SEG.ACK.
  eighth, check the FIN bit,
   Do not process the FIN if the state is CLOSED, LISTEN or SYN-SENT
   since the SEG.SEQ cannot be validated; drop the segment and
   return.

It should say:

SEGMENT ARRIVES
 If the state is LISTEN then
  third check for a SYN
        ??? No idea. But the original does not work.
        If there is data in the SYN, we have a problem. We have to be
        ESTABLISHED to get a buffer. And in ESTABLISHED the segment will be
        dropped, because it has the ACK bit off.
        We need to allocate a buffer. It's just for one segment. And we have
        to adapt the event handling for the user's RECEIVE call. ???
  fourth other text or control
        Any other control or text-bearing segment (not containing SYN)
        must have an ACK and thus would be discarded by the ACK
        processing. So you are unlikely to get here,
 If the state is SYN-SENT then
  first check the ACK bit
        If SND.UNA < SEG.ACK =< SND.NXT then the ACK is acceptable.
  fourth check the SYN bit
        This step should be reached only if the ACK is ok, or there is
        no ACK, and if the segment did not contain a RST.

        If the SYN bit is on, RCV.NXT is set to SEG.SEQ+1, IRS is set to
        SEG.SEQ.
        ...
        Data or controls which were queued for
        transmission may be included and SND.NXT advanced accordingly.
  fifth, because neither of the SYN or RST bits is set, drop the
        segment and return.
 Otherwise,
  third check security and precedence
       Construct the RST in this way:
          If there is an ACK

            <SEQ=SEG.ACK><CTL=RST>

          Otherwise

            <SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>
  fifth check the ACK field,
   SYN-RECEIVED STATE
    If SND.UNA < SEG.ACK =< SND.NXT then enter ESTABLISHED state, set
    SND.WND <- SEG.WND, SND.WL1 <- SEG.SEQ, SND.WL2 <- SEG.ACK,
    and continue processing.
    If the segment acknowledgment is not acceptable
    (SEG.ACK =< ISS or SEG.ACK > SND.NXT), form a
    reset segment,

      <SEQ=SEG.ACK><CTL=RST>

    and send it.
    Drop the segment. Return.
   ESTABLISHED STATE
    If the ACK is a duplicate (SEG.ACK =< SND.UNA), it can be
    ignored.  If the ACK acks something not yet sent
    (SEG.ACK > SND.NXT) then send an ACK, drop the segment, and
    return.
    If SND.UNA =< SEG.ACK =< SND.NXT, the send window should be
    updated.  If (SND.WL1 < SEG.SEQ or (SND.WL1 = SEG.SEQ and
    SND.WL2 =< SEG.ACK)), set SND.WND <- SEG.WND, set
    SND.WL1 <- SEG.SEQ, and set SND.WL2 <- SEG.ACK.
    If SND.UNA < SEG.ACK =< SND.NXT, then set SND.UNA <- SEG.ACK.
    Any segments on the retransmission queue which are thereby
    entirely acknowledged are removed.  Users should receive
    positive acknowledgments for buffers which have been SENT and
    fully acknowledged (i.e., SEND buffer should be returned with
    "ok" response).
  eighth, check the FIN bit,
   --delete this--

Notes:

If the state is LISTEN then
fourth other text or control
Incoming RST are already thrown out. Don't diskuss about it here.
If the state is SYN-SENT then
first check the ACK bit
nearly the same as the correction in RFC-1122 4.2.2.20(g)
fourth check the SYN bit
typo it -> if
security/compartment and precedence are already checked. It is no mistake,
but it is superfluous and confusing.
don't forget to advance SND.NXT
fifth
No more testing is necessary. Superfluous testing is confusing.
Otherwise,
third check security and precedence
The ACK bit is not yet checked.
fifth check the ACK field
SYN-RECEIVED STATE
SND.UNA == ISS. SEG.ACK == ISS does not ack our SYN.
SND.WND <- SEG.WND etc is corrected by RFC-1122.
explanation of not acceptable acknowledgment is helpful
'Drop the segment. Return.' is missing, too.
ESTABLISHED STATE
Corrections of RFC-1122 are included.
What about SEG.ACK =< ISS? I reccomend to send an ACK, drop the segment
and return. When SND.NXT overpaces ISS, ISS has to be adjusted somehow,
e.g. ISS <- ISS xor 0x80000000.
The updating of SND.UNA must be in the end, because the comparisations
need the old value of SND.UNA.
eighth, check the FIN bit,
If you are here, you are not in those states.
--VERIFIER NOTES--
As discussed on the TCPM Working Group mailing list in 2012:

This errata combines several different suggestions. Some of them repeat updates of RFC 1122,
some are subtle minor hints, and in some cases the errata does not propose better phrasing.
The errata cannot be accepted in this form. It might be worth to consider individual aspects
separately.

Errata ID: 1570
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Rejected by: Wesley Eddy
Date Rejected: 2012-05-29

Section 2.7 says:

There are two principal cases for matching the sockets in the local
passive OPENs and an foreign active OPENs.  In the first case, the
local passive OPENs has fully specified the foreign socket.  In this
case, the match must be exact.  In the second case, the local passive
OPENs has left the foreign socket unspecified.  In this case, any
foreign socket is acceptable as long as the local sockets match.

It should say:

There are two principal cases for matching the sockets in the local
passive OPENs and a foreign active OPEN.  In the first case, there
is exactly one local passive OPEN with matching local socket that
has fully specified the foreign socket.  In this case, the match must
be exact.  In the second case, there is exactly one local passive
OPEN with matching local socket that has left the foreign socket
unspecified.  In this case, any foreign socket is acceptable.

Notes:

In this passage singular or plural make a big difference.
--VERIFIER NOTES--
As discussed on the TCPM Working Group mailing list in 2012:

We believe that the original text is not confusing and a change of the meaning is not required.

Errata ID: 2771
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-04-08
Rejected by: Wes Eddy
Date Rejected: 2011-08-13

Throughout the document, when it says:

Notes:

RFC 793 has no regulations whether it should obsolete RFC 761, which, however, is logically obvious. RFC 761 (http://tools.ietf.org/html/rfc761) is the previous version of RFC 793 and, if this errata report is verified, should be marked as obsoleted by RFC 793.
--VERIFIER NOTES--
This is not a technical matter, and should refer to the RFC metadata rather than the document.

Errata ID: 3602
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Dahai Jiang
Date Reported: 2013-04-21
Rejected by: Martin Stiemerling
Date Rejected: 2014-04-16

Section 3.4 says:

5. SYN-RECEIVED --> <SEQ=100><ACK=301><CTL=SYN,ACK> ...

6. ESTABLISHED  <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED

7.              ... <SEQ=101><ACK=301><CTL=ACK>     --> ESTABLISHED

              Simultaneous Connection Synchronization

                             Figure 8.

It should say:

5. SYN-RECEIVED --> <SEQ=100><ACK=301><CTL=SYN,ACK> ...

6. ESTABLISHED  <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED

7.              ... <SEQ=100><ACK=301><CTL=SYN,ACK> --> ESTABLISHED

              Simultaneous Connection Synchronization

                             Figure 8.

Notes:

--VERIFIER NOTES--
See errata 573. Already done, thanks.

Errata ID: 3972
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Richard Scheffenegger
Date Reported: 2014-04-23
Rejected by: Martin Stiemerling
Date Rejected: 2014-04-24

Section 3.1 says:

 Reserved:  6 bits

    Reserved for future use.  Must be zero.

It should say:

 Reserved:  6 bits

    Reserved for future use.  SHOULD be zero.

Notes:

RFC3168 specifies 2 additional bits (ECE and CWR), RFC3540 specifies one additional bit (NS). Even though RFC793 predates RFC2119, and section 2.10 states
" be conservative in what you do, be liberal in what you accept from others.", any
update to this RFC should adjust the wording apropriately.
--VERIFIER NOTES--
The text is correct, as is. For implementations implementing RFC 793 purely the have to set this to zero.

Errata ID: 4753
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Sanjeev Ranot
Date Reported: 2016-07-30
Rejected by: Mirja Kühlewind
Date Rejected: 2016-09-14

Section 1.5 says:

A pair of sockets uniquely identifies each connection.
That is, a socket may be simultaneously used in multiple
connections

It should say:

A pair of sockets uniquely identifies each connection. Sockets can be
classified into client and server sockets. Typically a server socket 
may be simultaneously used in multiple connections.

Notes:

TCP is connection oriented therefore when we say "sockets used in multiple connections" it implies that the context is TCP. Considering their use in TCP, though a single client socket can be implemented in a way to multiplex it for connection with multiple server sockets and exchange different SYN segments but then its same what a server process listening for connections on server port does typically.

I feel classification of sockets here is vital to facilitate understand implicitly that in what use-case can a socket be typically multiplexed while still keeping generality of the statement.
--VERIFIER NOTES--
TCP sockets don't have a client/server concept therefore this clarification is inappropriate.

Errata ID: 7051
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Merlin Büge
Date Reported: 2022-07-28
Rejected by: Martin Duke
Date Rejected: 2022-09-22

Section 3.9 says:

        This step should be reached only if the ACK is ok, or there is
        no ACK, and it the segment did not contain a RST.

It should say:

        This step should be reached only if the ACK is ok, or there is
        no ACK, and if the segment did not contain a RST.

Notes:

Page 67: it -> if.

this document has been obsoleted.
--VERIFIER NOTES--

RFC 826, "An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", November 1982

Note: This RFC has been updated by RFC 5227, RFC 5494

Source of RFC: Legacy

Errata ID: 7630
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: enea eugen
Date Reported: 2023-09-05
Rejected by: John Scudder
Date Rejected: 2024-01-12

Section The Problem: says:

The world is a jungle in general, and the networking game
contributes many animals.  

It should say:

The world is a jungle in general, and in the networking game
contribute many animals.  

Notes:

The original text makes no sense.
--VERIFIER NOTES--
While the original text is somewhat idiomatic, it makes perfect sense. The proposed rewrite, on the other hand, doesn't.

RFC 959, "File Transfer Protocol", October 1985

Note: This RFC has been updated by RFC 2228, RFC 2640, RFC 2773, RFC 3659, RFC 5797, RFC 7151

Source of RFC: Legacy
Area Assignment: app

Errata ID: 3040
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: mark hays
Date Reported: 2011-12-01
Rejected by: Pete Resnick
Date Rejected: 2011-12-29

Section 5.3.2 says:

<number> ::= any decimal integer 1 through 255

It should say:

<byte-size> ::= any decimal integer 1 through 255
[...]
<number> ::= any decimal integer 0 through 255

Notes:

I agree with the author of errata ID 3039 that excluding 0 from <number> is problematic. However, <number> is also used in the definition of <byte-size>. The text in 3.1.1.4 says that"The value of Byte size must be a decimal integer; there is no default value." Strictly speaking, then, 0 is a valid value but I don't see how zero could lead to a sensible result. Indeed the term "decimal integer" is undefined so perhaps negative values are permissible?
--VERIFIER NOTES--
See Erratum 3039. Though the change there does allow for nonsense values for <byte-size>, so does the current syntax in 959. I have accepted 3039 and rejected this as duplicate.

Errata ID: 4575
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dave Mackay
Date Reported: 2016-01-01
Rejected by: Barry Leiba
Date Rejected: 2016-01-21

Section 5.2. says:

         User-PI - Server A                User-PI - Server B
         ------------------                ------------------

         C->A : Connect                    C->B : Connect
         C->A : PASV
         A->C : 227 Entering Passive Mode. A1,A2,A3,A4,a1,a2
                                           C->B : PORT A1,A2,A3,A4,a1,a2
                                           B->C : 200 Okay
         C->A : STOR                       C->B : RETR
                   B->A : Connect to HOST-A, PORT-a

It should say:

         User-PI - Server A                User-PI - Server B
         ------------------                ------------------

         C->A : Connect                    C->B : Connect
         C->A : PASV
         A->C : 227 Entering Passive Mode. (A1,A2,A3,A4,a1,a2).
                                           C->B : PORT A1,A2,A3,A4,a1,a2
                                           B->C : 200 Okay
         C->A : STOR                       C->B : RETR
                   B->A : Connect to HOST-A, PORT-a

Notes:

The reply code for 227 in sections 4.2.1 and 4.2.2. shows <host-port> surrounded by parenthesis with a period at the end, whereas the example in section 5.2 does not.
--VERIFIER NOTES--
As Section 4.2 states, only the numeric value of the reply code is significant to the protocol; the text is intended for human readers. The parentheses and period are not significant.

RFC 1027, "Using ARP to implement transparent subnet gateways", October 1987

Source of RFC: Legacy
Area Assignment: int

Errata ID: 4088
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sergey Yarin
Date Reported: 2014-08-19
Rejected by: Brian Haberman
Date Rejected: 2015-03-09

Section 2.1 says:

The gateway can then respond for host B,
    saying that the network address for host B is that of the gateway
    itself.

It should say:

The gateway can then respond for host A,
    saying that the network address for host B is that of the gateway
    itself.

Notes:

I'm a bit confused about the sentence :) I think there should be "A" instead of "B". Next phrase says that host A sees a reply message from gateway, therefore gateway have to send that reply message to A in the previous sentence.
--VERIFIER NOTES--
Since A and B are on separate networks, the gateway responds *on behalf of host B*.

RFC 1033, "Domain Administrators Operations Guide", November 1987

Source of RFC: Legacy
Area Assignment: ops

Errata ID: 566
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: "CFeng"
Date Reported: 2002-05-05
Rejected by: ron bonica
Date Rejected: 2010-11-01

Section 7 says:

           SRI.COM.  NS
*Here-->>  KL.SRI.COM.  KL.SRI.COM.  A 10.1.0.2.

It should say:

            SRI.COM.     NS  KL.SRI.COM.  
*Here-->>   KL.SRI.COM.  A   10.1.0.2.

Notes:

You can refer to RR "NS (Name Server)" on Page 6 in the same RFC for the reason.
--VERIFIER NOTES--
The status of this document is UNKNOWN. This means that it is so old, that it should not be used as a reference. There is really no way to know if the syntax that you point out was valid in 1987, when the document was published.

Maybe we should transition the document to HISTORIC?

RFC 1035, "Domain names - implementation and specification", November 1987

Note: This RFC has been updated by RFC 1101, RFC 1183, RFC 1348, RFC 1876, RFC 1982, RFC 1995, RFC 1996, RFC 2065, RFC 2136, RFC 2181, RFC 2137, RFC 2308, RFC 2535, RFC 2673, RFC 2845, RFC 3425, RFC 3658, RFC 4033, RFC 4034, RFC 4035, RFC 4343, RFC 5936, RFC 5966, RFC 6604, RFC 7766, RFC 8482, RFC 8490, RFC 8767

Source of RFC: Legacy
Area Assignment: int

Errata ID: 4226
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sun Congyou
Date Reported: 2015-01-09
Rejected by: Ted Lemon
Date Rejected: 2015-01-10

Section 4.2.1 says:

Messages sent using UDP user server port 53 (decimal).

It should say:

Messages sent using UDP uses server port 53 (decimal).

Notes:

--VERIFIER NOTES--
Duplicate of errata #4227.

RFC 1122, "Requirements for Internet Hosts - Communication Layers", October 1989

Note: This RFC has been updated by RFC 1349, RFC 4379, RFC 5884, RFC 6093, RFC 6298, RFC 6633, RFC 6864, RFC 8029, RFC 9293

Source of RFC: Legacy
Area Assignment: int

Errata ID: 6381
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Patrick Ni
Date Reported: 2021-01-07
Rejected by: Martin Duke
Date Rejected: 2021-01-08

Section 4.2.2.6 says:

Eff.snd.MSS = min(SendMSS+20, MMS_S) - TCPhdrsize - IPoptionsize

It should say:

Eff.snd.MSS = min(SendMSS+20, MMS_S) - TCPhdrsize 

Notes:

In Section 3.3.3 Fragmentation: MMS_S = EMTU_S - <IP header size> .... Note that <IP header size> in this equation will be 20, unless the IP reserves space to insert IP options for its own purposes in addition to any options inserted by the transport layer

IPoptionsize was already subtracted once when calculating MMS_S. It is being subtracted again upon calculating Eff.snd.MSS when MMS_S is smaller than sendMSS+20. In other words, if IP options are in use, its size is subtracted twice.
--VERIFIER NOTES--
In Section 3.3.3, it says "Note that <IP header size> in this equation will be 20, unless
the IP reserves space to insert IP options for its own purposes
in addition to any options inserted by the transport layer."

4.2.2.6 defines IPoptionsize as "IPoptionsize is the size of any IP options that TCP
will pass to the IP layer with the current message."

So MMS_S incorporates IP options from the IP layer, but IPoptionsize counts options coming from TCP. The terminology is a little confusing but careful reading of the definitions indicates that the math is correct.

RFC 1123, "Requirements for Internet Hosts - Application and Support", October 1989

Note: This RFC has been updated by RFC 1349, RFC 2181, RFC 5321, RFC 5966, RFC 7766, RFC 9210

Source of RFC: Legacy

Errata ID: 1081
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Frank Ellermann
Date Reported: 2007-11-20
Rejected by: Lisa Dusseault
Date Rejected: 2008-07-14

Section 2.1 says:

                        However, a valid host name can never
have the dotted-decimal form #.#.#.#, since at least the
highest-level component label will be alphabetic.

It should say:

                        However, a valid host name can never
have the dotted-decimal form #.#.#.#, since at least the
highest-level component label will be not all-numeric.

Notes:

RFC 3696 section 2 states: "There is an additional rule that essentially requires that top-level domain names not be all-numeric." The eleven IDN test TLDs created in September 2007 contain hyphen-minus as specified in the IDNA RFCs.
--VERIFIER NOTES--
This errata is in conflict with errata 1353. A new I-D and community consensus are probably needed.

Errata ID: 1353
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: John Klensin
Date Reported: 2008-03-08
Rejected by: Lisa Dusseault
Date Rejected: 2008-07-14

Section 2.1, ID 1081 says:

Errata ID 1081, reported 2007-11-20, identifies a problem with the
evolution of naming of top-level domains and the text of RFC 1123.
It reads:

Section 2.1 says:

                        However, a valid host name can never
have the dotted-decimal form #.#.#.#, since at least the
highest-level component label will be alphabetic.

It should say:

                        However, a valid host name can never
have the dotted-decimal form #.#.#.#, since at least the
highest-level component label will be not all-numeric.

Notes:

RFC 3696 section 2 states: "There is an additional rule that 
essentially requires that top-level domain names not be 
all-numeric." The eleven IDN test TLDs created in 
September 2007 contain hyphen-minus as specified in the 
IDNA RFCs. 

It should say:

However, a valid host name can never have the dotted-decimal 
form #.#.#.#, since this change does not permit the highest-level 
component label to start with a digit even if it is not all-numeric.

Notes:

This is a correct identification of the problem, but the wrong fix. RFC 3696, which ID 1081 cites, is an informational document that is deliberately relaxed about the fine details and says so. It is not relevant to determination of the text that should have been (with perfect knowledge of the future) in 1123.

Based on discussions when we were doing RFC 1591 and subsequently, the expectation then (and presumably when 1123 was written) was that the name of any new TLD would follow the rules for the existing ones, i.e., that they would be exactly two or three characters long and be all-alphabetic (which is exactly what 1123 says). The slightly-odd "will be" language in 1123 was, I believe, because that restriction was expected to be enforced by IANA, rather than being a protocol issue. ICANN, with a different set of assignment policies, effectively eliminated the length rule with the TLDs allocated in 2000. IDNA (RFC 3490) uses a syntax for IDNs that requires embedded hyphens in TLDs if there were ever to be an actual IDN TLD (hence the comment in ID 1081 about the IANA IDN testbed).

While the proposed correction in Errata ID 1081 would fix the problem by imposing the narrowest possible restriction ("not all-numeric"), the original host name rule and the original statement in 1123 both assume the possibility of a minimal check to differentiate between domain names and IP addresses, i.e., checking the first digit only. Because I believe that there are probably implementations that depend on such minimal parsing --some probably ancient and embedded-- it would appear to be wise to relax the rule as little as possible and, in particular, to restrict the "leading digit" exception to domains below the top-level, as 1123 effectively does.

The suggested text above reflects that reasoning. Because of the possible consequences of this issue, I would hope that it would be discussed with the relevant DNS-related WGs, the Root Server Advisory Committee (RSAC), and with IANA for comment and as a heads-up. This issue is substantive enough that it should probably be dealt with by a document that explicitly updates 1123 and that is processed on the Standards Track, but an accurate statement in the errata is the next-best option until that can be done. In the interim and while this suggestion is being discussed, Errata ID 1081 should probably be taken out of "validated" status.
--VERIFIER NOTES--
This errata is in conflict with errata 1081. A new I-D and community consensus are probably needed.

Errata ID: 6134
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Abel
Date Reported: 2020-04-28
Rejected by: Barry Leiba
Date Rejected: 2020-04-28

Section 5.2.2 says:

5.2.2  Canonicalization: RFC-821 Section 3.1

         The domain names that a Sender-SMTP sends in MAIL and RCPT
         commands MUST have been  "canonicalized," i.e., they must be
         fully-qualified principal names or domain literals, not
         nicknames or domain abbreviations.  A canonicalized name either
         identifies a host directly or is an MX name; it cannot be a
         CNAME.

It should say:

RFC5321 Section 2.3.5.  Domain Names

Only resolvable, fully-qualified domain names (FQDNs) are permitted
   when domain names are used in SMTP.  In other words, names that can
   be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed
   in Section 5) are permitted, as are CNAME RRs whose targets can be
   resolved, in turn, to MX or address RRs.

Notes:

Section 2.3.5 from RFC 5321 seems to contradict the section 5.2.2 from 1123.

In RFC5321 it is implied that you can have a domain CNAME pointing to another that has an MX record that is not a CNAME and it should work. However 1123 states that it's not possible.
--VERIFIER NOTES--
Errata reports are for mistakes in the published document -- errata at the time of publication. Anything that might have changed since then is appropriate for a new document, but isn't errata in the old one.

Errata ID: 2464
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Anthony Bryan
Date Reported: 2010-08-15
Rejected by: ron bonica
Date Rejected: 2011-10-12

Section 4.1.2.6 says:

            IMPLEMENTATION:
                 The format of the 227 reply to a PASV command is not
                 well standardized.  In particular, an FTP client cannot
                 assume that the parentheses shown on page 40 of RFC-959
                 will be present (and in fact, Figure 3 on page 43 omits
                 them).

It should say:

            IMPLEMENTATION:
                 The format of the 227 reply to a PASV command is not
                 well standardized.  In particular, an FTP client cannot
                 assume that the parentheses shown on page 40 of RFC-959
                 will be present (and in fact, Figure 3 on page 45 omits
                 them).

Notes:

In RFC 959, Figure 3 is actually on page 45, not page 43.
--VERIFIER NOTES--
I see figure 3 at the top of page 45.

RFC 1149, "Standard for the transmission of IP datagrams on avian carriers", April 1990

Note: This RFC has been updated by RFC 2549, RFC 6214

Source of RFC: INDEPENDENT

Errata ID: 2796
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Bryan Irvine
Date Reported: 2011-05-04
Rejected by: ron bonica
Date Rejected: 2011-05-05

Throughout the document, when it says:

Notes:

Special Considerations:
A port mirror should not be used with avian carriers as a single collision with a mirror will result in 100% loss of that carrier.
--VERIFIER NOTES--
As will a single collision with windows.

RFC 1172, "Point-to-Point Protocol (PPP) initial configuration options", July 1990

Note: This RFC has been obsoleted by RFC 1331, RFC 1332

Source of RFC: ppp (int)

Errata ID: 6467
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: bacquet guillaume
Date Reported: 2021-03-09
Rejected by: Erik Kline
Date Rejected: 2022-02-13

Section Link Quality says:

In-Rx-Packets   =  10 -   3 =  16

It should say:

In-Rx-Packets   =  10 -   3 =  7

Notes:

it is in Example part of link quality page 25

i am pretty sure that 10 minus 3 is not equal to 16.
Hopping that i understood well things here(i'm french :) )
--VERIFIER NOTES--
Actually the real error is that in the example the In-Rx-Packets maths should be "19 - 3 = 16", since the second report from A to B has In-Rx-Packets = 19 (not 10 as mistakenly entered on the computation line).

This RFC has been obsoleted by two others (RFCs 1331, 1332) which do not appear to contain this text.

RFC 1180, "TCP/IP tutorial", January 1991

Source of RFC: Legacy
Area Assignment: int

Errata ID: 4593
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Masoud Valizadeh
Date Reported: 2016-01-11
Rejected by: Brian Haberman
Date Rejected: 2016-01-15

Section 5.4 says:

The IP address space is administered by the NIC (Network Information
Center).  All internets that are connected to the single world-wide
Internet must use network numbers assigned by the NIC.  If you are
setting up your own internet and you are not intending to connect it
to the Internet, you should still obtain your network numbers from
the NIC.

It should say:

The IP address space is administered by the IANA (Internet Assigned 
Numbers Authority).  All internets that are connected to the single 
world-wide Internet must use network numbers assigned by the IANA.  
If you are setting up your own internet and you are not intending to 
connect it to the Internet (private network), you can choose any 
IP address for your network but it is recommended to use private 
ranges which are:
class A   10.0.0.0 - 10.255.255.255 (16,777,216 IP addresses),
class B   172.16.0.0 - 172.31.255.255 (1,048,576 IP addresses) and
class C   192.168.0.0 - 192.168.255.255 (65,536 IP addresses).

Notes:

--VERIFIER NOTES--
The current text in RFC 1180 accurately reflects the administration of IP address at the time.

Errata ID: 4589
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Masoud Valizadeh
Date Reported: 2016-01-10
Rejected by: Brian Haberman
Date Rejected: 2016-01-15

Section 2.2 says:

A driver is software that communicates directly with the network
interface hardware.  A module is software that communicates with a
driver, with network applications, or with another module.

It should say:

A driver is a software that communicates directly with the network
interface hardware.  A module is a software that communicates with a
driver, with network applications or with another module.

Notes:

--VERIFIER NOTES--
The current text is grammatically correct.

RFC 1227, "SNMP MUX protocol and MIB", May 1991

Source of RFC: Legacy
Area Assignment: ops

Errata ID: 1843
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Magnus Fromreide
Date Reported: 2009-08-29
Rejected by: Dan Romascanu
Date Rejected: 2010-11-02

Section 4 says:

          IMPORTS
                  enterprises
                          FROM RFC1155-SMI
                  OBJECT-TYPE
                          FROM RFC1212;

It should say:

          IMPORTS
                  enterprises
                          FROM RFC1155-SMI
                  OBJECT-TYPE
                          FROM RFC1212
                  DisplayString
                          FROM RFC1213-MIB;

Notes:

The object smuxPdescription is declared as a DisplayString but that name isn't imported.

I choose to take DisplayString from RFC1213-MIB since that is where it existed at the time.
--VERIFIER NOTES--
Such a change in a MIB module cannot be done by an erratum, but rather by issuing a new version of the MIB module. As this document is Historic and the MIB module is written in SMIv1, I see no need for such a change in the future.

RFC 1323, "TCP Extensions for High Performance", May 1992

Note: This RFC has been obsoleted by RFC 7323

Source of RFC: tcplw (tsv)

Errata ID: 3685
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Arul Kumar Chellappan
Date Reported: 2013-07-16
Rejected by: Martin Stiemerling
Date Rejected: 2014-01-22

Section 2 says:

         This option is an offer, not a promise; both sides must send
         Window Scale options in their SYN segments to enable window
         scaling in either direction.  If window scaling is enabled,
         then the TCP that sent this option will right-shift its true
         receive-window values by 'shift.cnt' bits for transmission in
         SEG.WND.  The value 'shift.cnt' may be zero (offering to scale,
         while applying a scale factor of 1 to the receive window).

It should say:

         This option is an offer, not a promise; both sides must send
         Window Scale options in their SYN segments to enable window
         scaling in either direction.  If window scaling is enabled,
         then the TCP that sent this option will left-shift its true
         receive-window values by 'shift.cnt' bits for transmission in
         SEG.WND.  The value 'shift.cnt' may be zero (offering to scale,
         while applying a scale factor of 1 to the receive window).

Notes:

This need to be left shift
--VERIFIER NOTES--
The text in RFC 1323 is correct.

RFC 1510, "The Kerberos Network Authentication Service (V5)", September 1993

Note: This RFC has been obsoleted by RFC 4120, RFC 6649

Source of RFC: cat (sec)

Errata ID: 3084
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jennifer Black
Date Reported: 2012-01-05
Rejected by: Stephen Farrell
Date Rejected: 2012-01-05

Section 1.2 says:

   +    "Denial of service" attacks are not solved with Kerberos.  There
        are places in these protocols where an intruder intruder can
        prevent an application from participating in the proper
        authentication steps.  Detection and solution of such attacks
        (some of which can appear to be not-uncommon "normal" failure
        modes for the system) is usually best left to the human
        administrators and users.

It should say:

   +    "Denial of service" attacks are not solved with Kerberos.  There
        are places in these protocols where an intruder can
        prevent an application from participating in the proper
        authentication steps.  Detection and solution of such attacks
        (some of which can appear to be not-uncommon "normal" failure
        modes for the system) is usually best left to the human
        administrators and users.

Notes:

Intruder appeared twice.

While that certainly can happen in practice, I don't think the author meant to allude to that possibility. :)
--VERIFIER NOTES--
Already fixed in 4120 which obsoletes this.

RFC 1533, "DHCP Options and BOOTP Vendor Extensions", October 1993

Note: This RFC has been obsoleted by RFC 2132

Source of RFC: dhc (int)

Errata ID: 4045
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Susumu Endoh
Date Reported: 2014-07-07
Rejected by: Ted Lemon
Date Rejected: 2014-07-11

Section 3.10 says:

The code for the log server option is 8.

It should say:

The code for the cookie server option is 8.

Notes:

--VERIFIER NOTES--
RFC 1533 was obsoleted by RFC 2132.

RFC 1609, "Charting Networks in the X.500 Directory", March 1994

Source of RFC: osids (app)

Errata ID: 2696
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Deckers
Date Reported: 2011-01-30
Rejected by: Peter Saint-Andre
Date Rejected: 2011-06-27

Section 2 says:

The integer value is the number of seconds, excluding leap seconds,
after midnight UTC, January 1, 1970. 

It should say:

The integer value is 63 072 000 when UTC was 1972-01-01; it increases by 1 for
every second of UTC, excluding positive leap seconds. 

Notes:

At the time when UTC was 1970-01-01, TAI was 1970-01-01 + 8.000 082 s,
according to [ftp://maia.usno.navy.mil/ser7/tai-utc.dat]. (The rate of
UTC was slower than the rate of TAI at the time but there have not been any
leap seconds in UTC between 1970 and 1972-01-01.) The original wording could be
taken to imply that the "integer value" was 63 072 001 when UTC was 1972-01-01
and TAI was 1972-01-01 + 10 s, and reached the value 63 072 002 just 82 µs
later. However, UNIX practice is to assign the value 63 072 000 to
the instant when UTC was 1972-01-01. The proposed wording makes it clear
that seconds of UTC are counted, not any seconds.
-- Regarding negative leap seconds (which have not occurred and probably
never will): "excluding" them would be wrong because, when they occur,
the phase of UTC increases by 2 s (and so must the time_t value) while the
phase of TAI only increases by 1 s. The proposed wording simply does not deal with the case, while the original would do it incorrectly.
--VERIFIER NOTES--
The quoted text does not appear in RFC 1609. However, it does appear in
RFC 4049 (!). If the reporter wishes to file an erratum against RFC 4049,
he will need to file a new report with the correct RFC number.

RFC 1738, "Uniform Resource Locators (URL)", December 1994

Note: This RFC has been obsoleted by RFC 4248, RFC 4266

Note: This RFC has been updated by RFC 1808, RFC 2368, RFC 2396, RFC 3986, RFC 6196, RFC 6270, RFC 8089

Source of RFC: Legacy

Errata ID: 2845
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-06-26
Rejected by: Peter Saint-Andre
Date Rejected: 2011-06-27

Section 5 says:

scheme         = 1*[ lowalpha | digit | "+" | "-" | "." ]

[ . . . ]

hostname       = *[ domainlabel "." ] toplabel
domainlabel    = alphadigit | alphadigit *[ alphadigit | "-" ] alphadigit
toplabel       = alpha | alpha *[ alphadigit | "-" ] alphadigit

[ . . . ]

user           = *[ uchar | ";" | "?" | "&" | "=" ]
password       = *[ uchar | ";" | "?" | "&" | "=" ]

[ . . . ]

fpath          = fsegment *[ "/" fsegment ]
fsegment       = *[ uchar | "?" | ":" | "@" | "&" | "=" ]

[ . . . ]

hpath          = hsegment *[ "/" hsegment ]
hsegment       = *[ uchar | ";" | ":" | "@" | "&" | "=" ]
search         = *[ uchar | ";" | ":" | "@" | "&" | "=" ]

[ . . . ]

group          = alpha *[ alpha | digit | "-" | "." | "+" | "_" ]
article        = 1*[ uchar | ";" | "/" | "?" | ":" | "&" | "=" ] "@" host

[ . . . ]

ppath          = psegment *[ "/" psegment ]
psegment       = *[ uchar | "?" | ":" | "@" | "&" | "=" ]
fieldspec      = ";" fieldname "=" fieldvalue
fieldname      = *[ uchar | "?" | ":" | "@" | "&" ]
fieldvalue     = *[ uchar | "?" | ":" | "@" | "&" ]

It should say:

scheme         = 1*( lowalpha | digit | "+" | "-" | "." )

[ . . . ]

hostname       = *( domainlabel "." ) toplabel
domainlabel    = alphadigit | alphadigit *( alphadigit | "-" ) alphadigit
toplabel       = alpha | alpha *( alphadigit | "-" ) alphadigit

[ . . . ]

user           = *( uchar | ";" | "?" | "&" | "=" )
password       = *( uchar | ";" | "?" | "&" | "=" )

[ . . . ]

fpath          = fsegment *( "/" fsegment )
fsegment       = *( uchar | "?" | ":" | "@" | "&" | "=" )

[ . . . ]

hpath          = hsegment *( "/" hsegment )
hsegment       = *( uchar | ";" | ":" | "@" | "&" | "=" )
search         = *( uchar | ";" | ":" | "@" | "&" | "=" )

[ . . . ]

group          = alpha *( alpha | digit | "-" | "." | "+" | "_" )
article        = 1*( uchar | ";" | "/" | "?" | ":" | "&" | "=" ) "@" host

[ . . . ]

ppath          = psegment *( "/" psegment )
psegment       = *( uchar | "?" | ":" | "@" | "&" | "=" )
fieldspec      = ";" fieldname "=" fieldvalue
fieldname      = *( uchar | "?" | ":" | "@" | "&" )
fieldvalue     = *( uchar | "?" | ":" | "@" | "&" )

Notes:

Given this is BNF of RFC 822 construction <n>*<m>[element] is incorrect, as RFC 822 defines:

> 2.5. [RULE]: OPTIONAL
>
> Square brackets enclose optional elements; "[foo bar]" is
> equivalent to "*1(foo bar)".

and therefore [] construction is illegal in the aforementioned one. My proposal is to replace all occurrences of [] construction where they are used in the meaning of () with the legal-as-per-822 one.
--VERIFIER NOTES--
This specification does not use the BNF syntax from RFC 822. Please refer
to the first paragraph of Section 5:

###

This is a BNF-like description of the Uniform Resource Locator
syntax, using the conventions of RFC822, except that "|" is used to
designate alternatives, and brackets [] are used around optional or
repeated elements. Briefly, literals are quoted with "", optional
elements are enclosed in [brackets], and elements may be preceded
with <n>* to designate n or more repetitions of the following
element; n defaults to 0.

###

The definitions follow the syntax used in this document. Thus
the report is incorrect.

RFC 1925, "The Twelve Networking Truths", April 1996

Source of RFC: INDEPENDENT

Errata ID: 4939
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: T Rogers
Date Reported: 2017-02-17
Rejected by: John Scudder
Date Rejected: 2024-02-11

Section 2 says:

No matter how hard you push and no matter what the priority,
        you can't increase the speed of light.

It should say:

No matter how hard you push and no matter what the priority, 
you can't increase the speed of light. You can, however, 
slow it down.

Notes:

Light travels more slowly through media such as glass, and the speed depends on frequency - this is how refraction works.
--VERIFIER NOTES--
The erratum would have been correct if the original text had said “speed of light in vacuum“, or its synonym, “c”. But it didn’t, so as far as I can see it’s correct, and consistent with the observations made in the notes that were submitted.

RFC 1939, "Post Office Protocol - Version 3", May 1996

Note: This RFC has been updated by RFC 1957, RFC 2449, RFC 6186, RFC 8314

Source of RFC: Legacy
Area Assignment: app

Errata ID: 4852
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Claude SIMON
Date Reported: 2016-11-02
Rejected by: Barry Leiba
Date Rejected: 2019-04-30

Section 3 and app. A says:

Section 3 :

Responses may be up to 512 characters
long, including the terminating CRLF.

Appendix A :

- specifies a status indicator length limitation
  of 512 octets, including the CRLF.

It should say:

(See 'Notes')

Notes:

What is written in appendix A does not match with what is written in section 3.
I guess both are wrong. The length of 512 may not concern the length of an entire response, and also not the length of only the status indicator, but the length of the first line returned as an answer by the server, which contains the status indicator, but sometimes some other text too (and, of course, is terminated by CRLF).
As I'm not sure that my guess is correct, and also because I'm not very comfortable with the English language, I am not able to propose a corrected text.
--VERIFIER NOTES--

The text is correct as written, in that a single-line response is limited to 512 octets (which is also 512 characters in US-ASCII). The subsequent paragraph in Section 3 explains multi-line responses.

RFC 1964, "The Kerberos Version 5 GSS-API Mechanism", June 1996

Note: This RFC has been updated by RFC 4121, RFC 6649

Source of RFC: cat (sec)

Errata ID: 7388
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Hisham kurdi
Date Reported: 2023-03-17
Rejected by: Roman Danyliw
Date Rejected: 2023-03-29

2207990

Hisham kurdi

It should say:

Hisham kurdi

Notes:

Hisham kurdi
--VERIFIER NOTES--
The submitted report references text which does not appear in the document

RFC 1981, "Path MTU Discovery for IP version 6", August 1996

Note: This RFC has been obsoleted by RFC 8201

Source of RFC: ipngwg (int)

Errata ID: 2174
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Brian Haberman
Date Rejected: 2015-03-27

Section 5.4. says:

If Path MTU Discovery is used, however, the segment size may not be a
submultiple of the send space,

It should say:

If Path MTU Discovery is used, however, the segment size may not be a
factor of the send space,

Notes:

What is a submultiple?
--VERIFIER NOTES--
submultiple is defined as an exact devisor of a number. The noted usage is perfectly fine.

RFC 1997, "BGP Communities Attribute", August 1996

Note: This RFC has been updated by RFC 7606, RFC 8642

Source of RFC: idr (rtg)

Errata ID: 4576
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Gjoko Stamenkov
Date Reported: 2016-01-02
Rejected by: Alvaro Retana
Date Rejected: 2016-04-03

Throughout the document, when it says:

Well-known Communities

   The following communities have global significance and their
   operations shall be implemented in any community-attribute-aware BGP
   speaker.

NO_EXPORT (0xFFFFFF01)
         All routes received carrying a communities attribute
         containing this value MUST NOT be advertised outside a BGP
         confederation boundary (a stand-alone autonomous system that
         is not part of a confederation should be considered a
         confederation itself).
NO_ADVERTISE (0xFFFFFF02)
         All routes received carrying a communities attribute
         containing this value MUST NOT be advertised to other BGP
         peers.
NO_EXPORT_SUBCONFED (0xFFFFFF03)
         All routes received carrying a communities attribute
         containing this value MUST NOT be advertised to external BGP
         peers (this includes peers in other members autonomous
         systems inside a BGP confederation).

It should say:

Well-known Communities

   The following communities have global significance and their
   operations shall be implemented in any community-attribute-aware BGP
   speaker.

NO_EXPORT (0xFFFFFF01)
         All routes received carrying a communities attribute
         containing this value MUST NOT be advertised to external BGP
         peers (this includes peers in other members autonomous
         systems inside a BGP confederation).  
NO_ADVERTISE (0xFFFFFF02)
         All routes received carrying a communities attribute
         containing this value MUST NOT be advertised to other BGP
         peers.
NO_EXPORT_SUBCONFED (0xFFFFFF03)
         All routes received carrying a communities attribute
         containing this value MUST NOT be advertised outside a BGP
         confederation boundary (a stand-alone autonomous system that
         is not part of a confederation should be considered a
         confederation itself).

Notes:

Definitions of NO_EXPORT and NO_EXPORT_SUBCONFED are interchanged in the original text.

=== (Alvaro Retana) ===

After some research and discussion with the WG [1], I'm rejecting this report.

[1] https://www.ietf.org/mail-archive/web/idr/current/msg15364.html
--VERIFIER NOTES--
After some research and discussion with the WG [1], I'm rejecting this report.

[1] https://www.ietf.org/mail-archive/web/idr/current/msg15364.html

RFC 2004, "Minimal Encapsulation within IP", October 1996

Source of RFC: mobileip (int)

Errata ID: 2840
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Francesco Balzarini
Date Reported: 2011-06-17
Rejected by: Brian Haberman
Date Rejected: 2012-05-04

Throughout the document, when it says:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Protocol    |S|  reserved   |        Header Checksum        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Original Destination Address                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :            (if present) Original Source Address               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

It should say:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Original Destination Address                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :            (if present) Original Source Address               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Protocol    |S|  reserved   |        Header Checksum        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

Notes:

given that:
- The ip4 header has variable size ( >20 octets )
- The suggested extra header has variable size ( 8 or 12 octets )
- The S bit to distinguish the suggested header size is located
inside the second octet of the suggested header
- The only size information is about the sum of both headers

The implication is that the S bit cannot be located.

My opinion to correct this problem is just to change
the order of elements inside the suggested header.
--VERIFIER NOTES--
The proposed change is a protocol modification and must go through the standardization process.

RFC 2018, "TCP Selective Acknowledgment Options", October 1996

Source of RFC: tcplw (tsv)

Errata ID: 6602
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Christian Reusch
Date Reported: 2021-06-07
Rejected by: Martin Duke
Date Rejected: 2022-05-13

Section 5.1 says:

   This document does not attempt to specify in detail the congestion
   control algorithms for implementations of TCP with SACK.  However,
   the congestion control algorithms present in the de facto standard
   TCP implementations MUST be preserved [Stevens94].  In particular, to
   preserve robustness in the presence of packets reordered by the
   network, recovery is not triggered by a single ACK reporting out-of-
   order packets at the receiver.  Further, during recovery the data
   sender limits the number of segments sent in response to each ACK.
   Existing implementations limit the data sender to sending one segment
   during Reno-style fast recovery, or to two segments during slow-start
   [Jacobson88].  Other aspects of congestion control, such as reducing
   the congestion window in response to congestion, must similarly be
   preserved.

It should say:

   This document does not attempt to specify in detail the congestion
   control algorithms for implementations of TCP with SACK.  However,
   the congestion control algorithms present in the de facto standard
   TCP implementations MUST be preserved [Stevens94].  In particular, to
   preserve robustness in the presence of packets reordered by the
   network, recovery is not triggered by a single ACK reporting out-of-
   order packets at the receiver.  Further, during recovery the data
   sender limits the number of segments sent in response to each ACK.
   Existing implementations limit the data sender to sending one segment
   during Reno-style recovery upon a timeout , or to two segments during slow-start
   [Jacobson88].  Other aspects of congestion control, such as reducing
   the congestion window in response to congestion, must similarly be
   preserved.

Notes:

RFC 2581, Section 3.1 sets the cndw to a value of 1:
...
Furthermore, upon a timeout cwnd MUST be set to no more than the loss
window, LW, which equals 1 full-sized segment (regardless of the
value of IW). Therefore, after retransmitting the dropped segment
the TCP sender uses the slow start algorithm to increase the window
from 1 full-sized segment to the new value of ssthresh, at which
point congestion avoidance again takes over.

Whereas in the Fast Recovery section(3.2) the cwnd is set by the following formula:
...
The fast retransmit and fast recovery algorithms are usually
implemented together as follows.

1. When the third duplicate ACK is received, set ssthresh to no more
than the value given in equation 3.
2. Retransmit the lost segment and set cwnd to ssthresh plus 3*SMSS.
This artificially "inflates" the congestion window by the number
of segments (three) that have left the network and which the
receiver has buffered.

3. For each additional duplicate ACK received, increment cwnd by
SMSS. This artificially inflates the congestion window in order
to reflect the additional segment that has left the network.

4. Transmit a segment, if allowed by the new value of cwnd and the
receiver's advertised window.

5. When the next ACK arrives that acknowledges new data, set cwnd to
ssthresh (the value set in step 1). This is termed "deflating"
the window.

This ACK should be the acknowledgment elicited by the
retransmission from step 1, one RTT after the retransmission
(though it may arrive sooner in the presence of significant out-
of-order delivery of data segments at the receiver).
Additionally, this ACK should acknowledge all the intermediate
segments sent between the lost segment and the receipt of the
third duplicate ACK, if none of these were lost.
--VERIFIER NOTES--
The sentence in question is not describing cwnd adjustment. When in Fast Recovery, a duplicate ack indeed allows the transmission of one packet to replace the one that left the network. In Slow Start, an ack allows for two packets: one to replace the old one, and one to fill the newly expanded cwnd.

RFC 2026, "The Internet Standards Process -- Revision 3", October 1996

Note: This RFC has been updated by RFC 3667, RFC 3668, RFC 3932, RFC 3978, RFC 3979, RFC 5378, RFC 5657, RFC 5742, RFC 6410, RFC 7100, RFC 7127, RFC 7475, RFC 8179, RFC 8789, RFC 9282

Source of RFC: poised95 (gen)

Errata ID: 6420
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jason Yundt
Date Reported: 2021-02-03
Rejected by: Lars Eggert
Date Rejected: 2021-03-11

Throughout the document, when it says:

"10.1.  General Policy",
"10.3.  Rights and Permissions",
"10.3.1.  All Contributions",
"10.3.2. Standards Track Documents", or
"10.4.  Notices"

It should say:

"10.1   General Policy",
"10.3   Rights and Permissions",
"10.3.1   All Contributions",
"10.3.2  Standards Track Documents", or
"10.4   Notices"

Notes:

When a top-level section is introduced, its number is followed by a period. For example, section 1 begins with "1. INTRODUCTION", and section 14 begins with "14. DEFINITIONS OF TERMS". This is consistent.

When a subsection is introduced, its number usually not followed by a period, but it sometimes is. For example, section 3.3 begins with "3.3 Requirement Levels", but section 10.1 begins with "10.1. General Policy". This is inconsistent. These inconsistencies are also in the Table of Contents.

--- VERIFIER NOTES ---
These slight formatting inconsistencies do not cause any confusion for a reader. If this document is updated, they will be automatically corrected through the use of the xml2rfc toolchain, so this erratum does not need to be held for document update.

--VERIFIER NOTES--

Errata ID: 7688
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Crystal Ball
Date Reported: 2023-10-26
Rejected by: Warren Kumari (Ops AD)
Date Rejected: 2024-01-12

Section Idkf says:

Jejf

It should say:

Ndjfk

Notes:

Rejecting as junk.
--VERIFIER NOTES--
Ndjfk Jejf Idkf... and also asdfasdfasdfasdf!

RFC 2028, "The Organizations Involved in the IETF Standards Process", October 1996

Note: This RFC has been obsoleted by RFC 9281

Note: This RFC has been updated by RFC 3668, RFC 3979, RFC 8717

Source of RFC: poised95 (gen)

Errata ID: 2742
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-03-05
Rejected by: Russ Housley
Date Rejected: 2011-06-07

Section 5 says:

  [F] IANA Charter, Work in Progress.

  [G] RFC Editor Charter, Work in Progress.

It should say:

  [F] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of Understanding 
      Concerning the Technical Work of the Internet Assigned Numbers Authority", 
      RFC 2860, June 2000.

  [G] Daigle, L., Ed., and Internet Architecture Board, "The RFC Series and
      RFC Editor", RFC 4844, July 2007.

Notes:

--VERIFIER NOTES--
These documents were not yet complete at the time RFC 2028 was written.

RFC 2045, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", November 1996

Note: This RFC has been updated by RFC 2184, RFC 2231, RFC 5335, RFC 6532

Source of RFC: 822ext (app)

Errata ID: 3950
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Occil
Date Reported: 2014-04-03
Rejected by: Barry Leiba
Date Rejected: 2014-04-03

Section 4 says:

   NOTE TO IMPLEMENTORS:  When checking MIME-Version values any RFC 822
   comment strings that are present must be ignored.  In particular, the
   following four MIME-Version fields are equivalent:

     MIME-Version: 1.0

     MIME-Version: 1.0 (produced by MetaSend Vx.x)

     MIME-Version: (produced by MetaSend Vx.x) 1.0

     MIME-Version: 1.(produced by MetaSend Vx.x)0

It should say:

   NOTE TO IMPLEMENTORS:  When checking MIME-Version values any RFC 822
   comment strings that are present must be ignored.  In particular, the
   following three MIME-Version fields are equivalent:

     MIME-Version: 1.0

     MIME-Version: 1.0 (produced by MetaSend Vx.x)

     MIME-Version: (produced by MetaSend Vx.x) 1.0

Notes:

Under RFC 822, a comment placed between two lexical symbols, in the case of the fourth example given, between the dot and the zero, is equivalent to a single space. Accordingly, the fourth example would result in the field "MIME-Version: 1. 0", which is not exactly equivalent to the previous three examples.
--VERIFIER NOTES--
It is exactly equivalent, because, while the lexical parsing puts a blank in, the parsing of the MIME-Version value then ignores the blank.

RFC 2046, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", November 1996

Note: This RFC has been updated by RFC 2646, RFC 3798, RFC 5147, RFC 6657, RFC 8098

Source of RFC: 822ext (app)

Errata ID: 6583
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: ojab
Date Reported: 2021-05-15
Rejected by: RFC Editor
Date Rejected: 2024-02-15

Section 5.1.2 says:

It is essential that such entities be handled correctly when they are
themselves imbedded inside of another "multipart" structure.

It should say:

It is essential that such entities be handled correctly when they are 
themselves embedded inside of another "multipart" structure.

Notes:

`imbedded` is a typo
--VERIFIER NOTES--
“Imbed” is a less common spelling of “embed” (see https://www.merriam-webster.com/dictionary/imbed). It is used in a number of early RFCs (e.g., RFCs 549, 1035, 1258, 1580, 1689, 2567, 3423, and more). It was last used in RFC 5045. Since then, “embed” has been used in the RFC Series.

RFC 2047, "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", November 1996

Note: This RFC has been updated by RFC 2184, RFC 2231

Source of RFC: 822ext (app)

Errata ID: 3749
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alec H. Peterson
Date Reported: 2013-10-11
Rejected by: Barry Leiba
Date Rejected: 2013-10-26

Section 2 says:

   An 'encoded-word' may not be more than 75 characters long, including
   'charset', 'encoding', 'encoded-text', and delimiters.  If it is
   desirable to encode more text than will fit in an 'encoded-word' of
   75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may
   be used.

It should say:

   An 'encoded-word' may not be more than 75 characters long, including
   'charset', 'encoding', 'encoded-text', and delimiters.  If it is
   desirable to encode more text than will fit in an 'encoded-word' of
   75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may
   be used.

   Multiple encoded words MAY exist on a single line, in that event a 
   SPACE MUST separate the encoded words, and after decoding the SPACE 
   is not rendered.

Notes:

Section 2 makes no mention of multiple encoded words per line, or how to handle it. However, the example at the end specifically illustrates what should happen (section 8)

(=?ISO-8859-1?Q?a?= =?ISO-8859-2?Q?_b?=) (a b)

In order to cause a SPACE to be displayed between two strings
of encoded text, the SPACE MAY be encoded as part of one of
the 'encoded-word's.
--VERIFIER NOTES--

<<
I think I just hadn't fully digested the whole RFC. I was just re-reading the RFC in working to come up with the proposed change, and then I saw this in section 6.2:

When displaying a particular header field that contains multiple
'encoded-word's, any 'linear-white-space' that separates a pair of
adjacent 'encoded-word's is ignored. (This is to allow the use of
multiple 'encoded-word's to represent long strings of unencoded text,
without having to separate 'encoded-word's where spaces occur in the
unencoded text.)
>>

So the RFC is correct as it stands. The text in section 2 is specifically talking about multiple encoded-words on multiple lines. Section 6.2 covers the other case.

RFC 2076, "Common Internet Message Headers", February 1997

Source of RFC: mailext (app)

Errata ID: 4607
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Vladimir Dubrovin
Date Reported: 2016-01-29
Rejected by: Barry Leiba
Date Rejected: 2016-01-29

Section 3.5 says:

   Address to which notifications       Errors-To:,    Non-standard,
   are to be sent and a request to      Return-        discouraged.
   get delivery notifications.          Receipt-To:
   Internet standards recommend,
   however, the use of RCPT TO and
   Return-Path, not Errors-To, for
   where delivery notifications are
   to be sent.

It should say:

   Address to which notifications       Errors-To:,    Non-standard,
   are to be sent and a request to      Return-        discouraged.
   get delivery notifications.          Receipt-To:
   Internet standards recommend,
   however, the use of MAIL FROM
   and  Return-Path, not Errors-To,
   for where delivery notifications
   are to be sent.

Notes:

Notifications and bounces are delivered to "MAIL FROM" envelope address of original message.
--VERIFIER NOTES--
Return-Path *is* where the MAIL FROM address is put into a message header.

RFC 2104, "HMAC: Keyed-Hashing for Message Authentication", February 1997

Note: This RFC has been updated by RFC 6151

Source of RFC: ipsec (sec)

Errata ID: 4459
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Bozhi ZHENG
Date Reported: 2015-08-27
Rejected by: Stephen Farrell
Date Rejected: 2015-08-27

Section Appendix says:

        /* start out by storing key in pads */
        bzero( k_ipad, sizeof k_ipad);
        bzero( k_opad, sizeof k_opad);
        bcopy( key, k_ipad, key_len);
        bcopy( key, k_opad, key_len);

        /* XOR key with ipad and opad values */
        for (i=0; i<64; i++) {
                k_ipad[i] ^= 0x36;
                k_opad[i] ^= 0x5c;
        }

It should say:

        /* start out by storing key in pads */
        bzero( k_ipad, sizeof k_ipad);
        bzero( k_opad, sizeof k_opad);
        bcopy( k_ipad, key, key_len);
        bcopy( k_opad, key, key_len);

        /* XOR key with ipad and opad values */
        for (i=0; i<64; i++) {
                k_ipad[i] ^= 0x36;
                k_opad[i] ^= 0x5c;
        }

Notes:

The ipad = the byte 0x36 repeated 64 times, opad = the type 0x5C repeated B times and then ipad and opad XOR K after it appended to 64 byptes.
--VERIFIER NOTES--

The net effect of the suggested change would be to zero the key
and make HMAC useless.

RFC 2119, "Key words for use in RFCs to Indicate Requirement Levels", March 1997

Note: This RFC has been updated by RFC 8174

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: gen

Errata ID: 497
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kiyoshi Ogawa
Date Reported: 2006-07-10
Rejected by: Russ Housley
Date Rejected: 2010-08-19

 

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

It should say:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications should be understood and
   carefully weighed before choosing a different course.

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

Notes:

OR should say:
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications is understood and
carefully weighed before choosing a different course.

4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label.


The change request is "must" to "should".
It may be self definition.
For the balance of SHOULD and SHOULD NOT , it should use "should", not
"must".
--VERIFIER NOTES--
The full implications MUST be understood in order to ignore a "SHOULD" or "SHOULD NOT" statement in a specification.

Errata ID: 6773
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michał Bieńkowski
Date Reported: 2021-12-03
Rejected by: RFC Editor
Date Rejected: 2022-01-27

Section 5 says:

MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.

It should say:

MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional. One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.

Notes:

There is a double space before "One vendor may choose to include".
--VERIFIER NOTES--
This report doesn't add clarity or improve readabilty. We don't recommend errata be used to "correct" the number of spaces between sentences.

Errata ID: 6954
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: aaron wuescher
Date Reported: 2022-05-05
Rejected by: Lars Eggert
Date Rejected: 2023-08-11

Section 6. of all scripts says:

6. Guidance in the use of these Imperatives

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.

{This part: (e.g., limiting retransmisssions); is the focus.}

It should say:

In-line html has an errata by Davidson, Malcolm about the extra S in retransmission. (Good Job to Malcom! (I would also like to make editors aware that is in only corrected in the, in-line html.  The error of the extra -s in the word retransmissions is still present in all of the other documents.)  

The problem I would like to bring to the attention of the minds of the world, is 
still that same word, retransmissions and I'm concerned that it has been looked at and still over looked.   It should be simply "transmissions" or, but NOT RECOMENDED; "re-transmissions".  (I will explain.) 

Notes:

The base word "transmission" (which is already a compound word.) in the plural form, shows more than one, present tense, and also future tense. Therefore the re- prefix is redundant in the word. It actually retards the word making it null. Without the hyphen it is an entirely different compound word that may not even exist yet. The -s making it plural is plenty to make this sentence complete and accurate. There is no need for the re- prefix but if you must it should be hyphenated. Thank you!
--VERIFIER NOTES--
The word in question (retransmissions) is used as an example, and is a term of art in congestion control.

RFC 2126, "ISO Transport Service on top of TCP (ITOT)", March 1997

Source of RFC: Legacy

Errata ID: 492
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Larry Masinter
Date Reported: 2002-03-21
Rejected by: RFC Editor
Date Rejected: 2009-12-01

 

Notes:

All errata for these documents can be found at: http://purl.org/net/http-errata

----------------------
This report was mistakenly posted based on a typo (2126 vs. 2616)
in a message from 2002, and thus has been rejected.

RFC 2127, "ISDN Management Information Base using SMIv2", March 1997

Source of RFC: isdnmib (int)

Errata ID: 491
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Larry Masinter
Date Reported: 2002-03-21
Rejected by: RFC Editor
Date Rejected: 2009-12-01

 

Notes:

All errata for these documents can be found at: http://purl.org/net/http-errata

----------------------
This report was mistakenly posted based on a typo (2127 vs. 2617)
in a message from 2002, and thus has been rejected.

RFC 2131, "Dynamic Host Configuration Protocol", March 1997

Note: This RFC has been updated by RFC 3396, RFC 4361, RFC 5494, RFC 6842

Source of RFC: dhc (int)

Errata ID: 6447
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Adrien de Croy
Date Reported: 2021-03-01
Rejected by: Eric Vyncke
Date Rejected: 2023-08-03

Section 2.2 says:

a client requests the use of an address for some period of time.  The 
allocation mechanism (the collection of DHCP servers) guarantees not 
to reallocate that address within the requested time

It should say:

a client requests the use of an address for some period of time.  The 
allocation mechanism (the collection of DHCP servers) may or may not be able or willing to grant a lease for the requested duration.  Any lease duration it offers it then guarantees not to reallocate within the offered time

Notes:

It is simply ludicrous to imagine that clients are in control of the lease duration, and that servers will simply comply, regardless of resource availability.
--VERIFIER NOTES--
The text does not say that the DHCP servers must grant the requested leased time. I.e., the current text is OK.

RFC 2152, "UTF-7 A Mail-Safe Transformation Format of Unicode", May 1997

Source of RFC: Legacy
Area Assignment: app

Errata ID: 5475
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Peter Occil
Date Reported: 2018-08-22
Rejected by: Barry Leiba
Date Rejected: 2019-04-30

Section Discussion says:

      Content-type: multipart/mixed; boundary=foo
      Content-Disposition: inline

      --foo
      Content-type: text/plain; charset=us-ascii

      Hi Mom
      --foo
      Content-type: text/plain; charset=UNICODE-2-0
      Content-transfer-encoding: base64

      Jjo=
      --foo
      Content-type: text/plain; charset=us-ascii

      !
      --foo--

It should say:

      Content-type: multipart/mixed; boundary=foo
      Content-Disposition: inline

      --foo
      Content-type: text/plain; charset=us-ascii

      Hi Mom
      --foo
      Content-type: text/plain; charset=UTF-7
      Content-transfer-encoding: base64

      Jjo=
      --foo
      Content-type: text/plain; charset=us-ascii

      !
      --foo--

Notes:

The charset name for this RFC is UTF-7, not UNICODE-2-0.
--VERIFIER NOTES--

This is an example that's specifically introduced with, "As an alternative to use of UTF-7," and quite intentionally uses a charset other than UTF-7.

RFC 2181, "Clarifications to the DNS Specification", July 1997

Note: This RFC has been updated by RFC 4035, RFC 2535, RFC 4343, RFC 4033, RFC 4034, RFC 5452, RFC 8767

Source of RFC: dnsind (int)

Errata ID: 6446
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Robert Edmonds
Date Reported: 2021-02-27
Rejected by: Éric Vyncke
Date Rejected: 2024-01-12

Section 1, 5, 6, 10 says:

label

It should say:

owner

Notes:

Sections 1, 5, 6, and 10 consistently use the term "label" to incorrectly refer to what STD 13 calls an "owner". There may also be additional instances of "label" being used incorrectly in Section 11.

-- verifier note --

It seems to me that the term "label" using in RFC 2181 is consistent with RFC 8499 & STD 13.
--VERIFIER NOTES--
It seems to me that the term "label" using in RFC 2181 is consistent with RFC 8499 & STD 13.

RFC 2222, "Simple Authentication and Security Layer (SASL)", October 1997

Note: This RFC has been obsoleted by RFC 4422, RFC 4752

Note: This RFC has been updated by RFC 2444

Source of RFC: Legacy

Errata ID: 2847
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alex Allain
Date Reported: 2011-06-28
Rejected by: Peter Saint-Andre
Date Rejected: 2011-08-02

Section 6 says:

will perform no review of clams made

It should say:

will perform no review of claims made

Notes:

Minor typo
--VERIFIER NOTES--
This minor typo was fixed in RFC 4422, which obsoleted RFC 2222.

RFC 2236, "Internet Group Management Protocol, Version 2", November 1997

Note: This RFC has been updated by RFC 3376

Source of RFC: idmr (rtg)

Errata ID: 3063
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jon Hak Song
Date Reported: 2011-12-26
Rejected by: Adrian Farrel
Date Rejected: 2012-05-08

Section 6 says:

   - "set timer", setting the timer to its maximum value [Version 1
     Router Present Timeout] and (re)starting it.

                              ________________
                             |                |
                             |                |
                             |   No IGMPv1    |
                             |     Router     |
                             |    Present     |
                             |                |
                        ---->|                |----
                       |     |                |    |
                       |     |________________|    |
         timer expires |                           | IGMPv1 query
                       |      ________________     | received
                       |     |                |    | (set timer)
                       |     |                |    |
                       |     |                |    |
                        -----|     IGMPv1     |<---
                             |     Router     |
                             |    Present     |
                             |                |
                        ---->|                |----
                       |     |________________|    |
                       |                           |
                       | IGMPv1 query received     |
                       | (set timer)               |
                        ---------------------------

It should say:

   - "set timer", setting the timer to its maximum value [Version 1
     Router Present Timeout] and starting it.
   - "reset timer", resetting the timer to its maximum value [Version 1
     Router Present Timeout] and restarting it.

                              ________________
                             |                |
                             |                |
                             |   No IGMPv1    |
                             |     Router     |
                             |    Present     |
                             |                |
                        ---->|                |----
                       |     |                |    |
                       |     |________________|    |
         timer expires |                           | IGMPv1 query
                       |      ________________     | received
                       |     |                |    | (set timer)
                       |     |                |    |
                       |     |                |    |
                        -----|     IGMPv1     |<---
                             |     Router     |
                             |    Present     |
                             |                |
                        ---->|                |----
                       |     |________________|    |
                       |                           |
                       | IGMPv1 query received     |
                       | (reset timer)             |
                        ---------------------------

Notes:

Resetting timer is obviously different than setting timer.
--VERIFIER NOTES--
I am rejecting this Erratum mainly because RFC 2236 has been obsoleted by RFC 3376, but also because I don't agree that the change is needed. The original text covers the two operations adequately.

RFC 2246, "The TLS Protocol Version 1.0", January 1999

Note: This RFC has been obsoleted by RFC 4346

Note: This RFC has been updated by RFC 3546, RFC 5746, RFC 6176, RFC 7465, RFC 7507, RFC 7919

Source of RFC: tls (sec)

Errata ID: 3481
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin Rex
Date Reported: 2013-02-08
Rejected by: Stephen Farrell
Date Rejected: 2014-05-08

Section 8.1.2 says:

8.1.2. Diffie-Hellman

   A conventional Diffie-Hellman computation is performed. The
   negotiated key (Z) is used as the pre_master_secret, and is converted
   into the master_secret, as specified above.

It should say:

8.1.2. Diffie-Hellman

   A conventional Diffie-Hellman computation is performed.  The
   negotiated key (Z) is used as the pre_master_secret, and is converted
   into the master_secret, as specified above.  Leading bytes of Z that
   contain all zero bits are stripped before it is used as the
   pre_master_secret.

Notes:

Adopting the clarification from rfc4346 Section 8.1.2. Not stripping the leading zero bits of Z will cause interop problems (handshake failures) with the installed base. Rfc2246 is still the authoritative spec for TLSv1.0. One can not implement TLSv1.0 from rfc4346.
--VERIFIER NOTES--
We don't post errata for things fixed when an RFC is obsoleted.

RFC 2317, "Classless IN-ADDR.ARPA delegation", March 1998

Source of RFC: dnsind (int)

Errata ID: 5688
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Dominik
Date Reported: 2019-04-11
Rejected by: Eric Vyncke
Date Rejected: 2023-08-03

Section [Page 2] says:

 Let us assume we have assigned the address spaces to three different
   parties as follows:

           192.0.2.0/25   to organization A
           192.0.2.128/26 to organization B
           192.0.2.192/26 to organization C

It should say:

 Let us assume we have assigned the address spaces to three different
   parties as follows:

           192.0.2.0/25   to organization A
           192.0.2.128/26 to organization B
           192.0.2.192/27 to organization C

 

Notes:

Ip mask 27 ?
--VERIFIER NOTES--
Actually, the last octet of 192.0.2.128 is b'1000 0000 and 192.0.2.192 is n'1100 0000 and the latter is *not* a subnet of the former in this RFC. I.e., both are /26

RFC 2325, "Definitions of Managed Objects for Drip-Type Heated Beverage Hardware Devices using SMIv2", April 1998

Source of RFC: INDEPENDENT

Errata ID: 4301
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Anthony Yu
Date Reported: 2015-03-12
Rejected by: Barry Leiba
Date Rejected: 2015-03-13

Section 3 says:

The MIB contains objects that
relate to physical connections,
configuration, storage levels,
availability, quality of service, and
availability.

It should say:

The MIB contains objects that
relate to physical connections,
configuration, storage levels,
quality of service, and availability.

Notes:

Availability is stated twice.
--VERIFIER NOTES--
Any coffee drinker will tell you that availability is absolutely critical. Its appearance twice
in the list reflects that importance, and I am rejecting this errata report on those...grounds.

RFC 2326, "Real Time Streaming Protocol (RTSP)", April 1998

Note: This RFC has been obsoleted by RFC 7826

Source of RFC: mmusic (rai)

Errata ID: 4199
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Julius Friedman
Date Reported: 2014-12-11
Rejected by: Ben Campbell
Date Rejected: 2015-06-05

Section 4 says:

4 RTSP Message

   RTSP is a text-based protocol and uses the ISO 10646 character set in
   UTF-8 encoding (RFC 2279 [21]). Lines are terminated by CRLF, but
   receivers should be prepared to also interpret CR and LF by
   themselves as line terminators.

     Text-based protocols make it easier to add optional parameters in a
     self-describing manner. Since the number of parameters and the
     frequency of commands is low, processing efficiency is not a
     concern. Text-based protocols, if done carefully, also allow easy
     implementation of research prototypes in scripting languages such
     as Tcl, Visual Basic and Perl.

     The 10646 character set avoids tricky character set switching, but
     is invisible to the application as long as US-ASCII is being used.
     This is also the encoding used for RTCP. ISO 8859-1 translates
     directly into Unicode with a high-order octet of zero. ISO 8859-1
     characters with the most-significant bit set are represented as
     1100001x 10xxxxxx. (See RFC 2279 [21])

   RTSP messages can be carried over any lower-layer transport protocol
   that is 8-bit clean.

   Requests contain methods, the object the method is operating upon and
   parameters to further describe the method. Methods are idempotent,
   unless otherwise noted. Methods are also designed to require little
   or no state maintenance at the media server.

It should say:

4 RTSP Message

   RTSP is a text-based protocol and uses the ISO 10646 character set in
   UTF-8 encoding (RFC 2279 [21]). Lines are terminated by CRLF, but
   receivers should be prepared to also interpret CR and LF by
   themselves as line terminators.

     Text-based protocols make it easier to add optional parameters in a
     self-describing manner. Since the number of parameters and the
     frequency of commands is low, processing efficiency is not a
     concern. Text-based protocols, if done carefully, also allow easy
     implementation of research prototypes in scripting languages such
     as Tcl, Visual Basic and Perl.

     The 10646 character set avoids tricky character set switching, but
     is invisible to the application as long as US-ASCII is being used.
     This is also the encoding used for RTCP. ISO 8859-1 translates
     directly into Unicode with a high-order octet of zero. ISO 8859-1
     characters with the most-significant bit set are represented as
     1100001x 10xxxxxx. (See RFC 2279 [21])

   RTSP messages can be carried over any lower-layer transport protocol
   that is 8-bit clean.

   Requests contain methods, the object the method is operating upon and
   parameters to further describe the method. Methods are idempotent,
   unless otherwise noted. Methods are also designed to require little
   or no state maintenance at the media server.

*Please note the hexadecimal octet 0x36 should not be included in any 
part of a RTSP message, if present it should be replaced with binary 
escaped sequence as defined in: <consensus>*.

Notes:

Section [15.1 Base Syntax] makes the following definitions:
..
safe = "\$" | "-" | "_" | "." | "+"
..
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "="
extra = "!" | "*" | "$'$" | "(" | ")" | ","
unreserved = alpha | digit | safe | extra
xchar = unreserved | reserved | escape

However it doesn't explicitly state the association of "$" [hexadecimal 0x24]

Section [10.12 Embedded (Interleaved) Binary Data] specified a mechanism of transferring RTSP messages over a TCP connection with a application layer header consisting of the hexadecimal octet 0x24; followed by a single octet channel identifier and the RFC4571 length specifier of the frame.

Due to the fact 0x24 violates section 4's requirements based on the fact it cannot be masked with the octet (AND 0xc3) to ensure it is a valid character I am filing this errata.

The chosen octet may also be present, specifically in the types of RTSP messages which are interleaved during playback such as ANNOUNCE. E.g. 0x24 could be a part of the configuration specifying the bits per pixel or audio bit depth as part of the SDP inter alia.

In such cases the underlying parser would interpret this octet as the start of the defined application header and cause framing errors which could cause data loss as allow for buffer overflow attacks of carefully crafted binary data.

There are also definitions which need to be made in the stadard for what to do when less then the amount of bytes indicated by the application layer frame header are or are not present. (e.g. more or less bytes are required then are present during reception of the given the [$CXX] application header sequence).

It is based on these considerations among others that I recommend that "$" [hexadecimal octet 0x24] be added to the reserved list and if necessary an escaping mechanism be defined where it is replaced with an escaped sequence which is agreed upon after consensus.

Due to the fact that drafts also specify that RTSP can be extended with any type of message so long as the data is not "$" the first character it is ambiguous may also appear elsewhere in the status line.

There are also issues with the ambiguous definition of pdu fragmentation defined in the latest draft, e.g. the mechanism defined as possibly required when pdu's larger then 65535 bytes are used however it specified no way to convey how this occurs or why.

The same can also be said for "sink" and "source" however I will address those definitions et al when appropriate.

Thank you for your time!

The review noted the following:

"The reason is that is is technical change that can cause compatibility issues, and
further does not resolve the issue as it is missing the required
escaping definitions (another technical change). In addition we know
that RFC 2326 is quite buggy and attempting to fix it with Errata does
not work."

MMUSIC is considering whether this should be fixed in RTSP 2.0.
--VERIFIER NOTES--
The reviewer noted the following:

"The reason is that is is technical change that can cause compatibility issues, and
further does not resolve the issue as it is missing the required
escaping definitions (another technical change). In addition we know
that RFC 2326 is quite buggy and attempting to fix it with Errata does
not work."

MMUSIC is considering whether this should be fixed in RTSP 2.0.

Errata ID: 5079
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Vadim Zhukov
Date Reported: 2017-08-08
Rejected by: Ben Campbell
Date Rejected: 2017-09-13

Section 10.8 says:

     S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
           CSeq: 431
           Content-Type: text/parameters
           Session: 12345678
           Content-Length: 15

           packets_received
           jitter

It should say:

     S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
           CSeq: 431
           Content-Type: text/parameters
           Session: 12345678
           Content-Length: 24

           packets_received
           jitter

Notes:

The Content-Length value is wrong, it should be either 24 (as proposed) or 26, depending on end-of-line marker used for message content.
--VERIFIER NOTES--
RFC 2326 has been obsoleted by RFC 7826. The similar examples in RFC 7826 appear to have correct content-length field values.

Errata ID: 6862
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Chris Morgan
Date Reported: 2022-02-25
Rejected by: RFC Editor
Date Rejected: 2022-04-06

Section 3.6 says:

     The syntax conforms to ISO 8601. The npt-sec notation is optimized
     for automatic generation, the ntp-hhmmss notation for consumption
     by human readers.

It should say:

     The syntax conforms to ISO 8601. The npt-sec notation is optimized
     for automatic generation, the npt-hhmmss notation for consumption
     by human readers.

Notes:

A typo, ntp-hhmmss → npt-hhmmss.
--VERIFIER NOTES--
Already addressed in rfc7826

RFC 2327, "SDP: Session Description Protocol", April 1998

Note: This RFC has been obsoleted by RFC 4566

Note: This RFC has been updated by RFC 3266

Source of RFC: mmusic (rai)

Errata ID: 4804
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sean Leonard
Date Reported: 2016-09-18
Rejected by: Ben Campbell
Date Rejected: 2016-09-18

Section Appendix A says:

   This appendix provides an Augmented BNF grammar for SDP. ABNF is
   defined in RFC 2234.

It should say:

   This appendix provides an Augmented BNF grammar for SDP. ABNF is
   defined in RFC 2234 [13].

In References:

   [13] Crocker, D. and P. Overell, "Augmented BNF for syntax
   specifications: ABNF", RFC 2234, November 1997.

Notes:

A reference for RFC 2234 is not provided in the original text. The intent is clear, but as an editorial matter (at least) the text needs to be corrected.
--VERIFIER NOTES--
RFC 2327 was obsoleted by 4566, which will in turn be obsoleted by draft-ietf-mmusic-rfc4566bis. If the concern still exists in the draft, please address it there.

RFC 2328, "OSPF Version 2", April 1998

Note: This RFC has been updated by RFC 5709, RFC 6549, RFC 6845, RFC 6860, RFC 7474, RFC 8042, RFC 9355, RFC 9454

Source of RFC: ospf (rtg)

Errata ID: 1745
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Wenhu Lu
Date Reported: 2009-03-27
Rejected by: Stewart Bryant
Date Rejected: 2012-10-26

Section Appendix E says:

In the paragraph that starts with: "The above algorithm assumes that all"

                                 The algorithm also assumes that no
    network exists having an address equal to another network's
    broadcast address.

It should say:

                                 The algorithm also assumes that if
    one of the conflicting networks is of IP host mask, its LSA
    origination is suppressed. The choice of the suppressing algorithm
    again is a local decision. However, the suppressed LSA MUST be
    originated if the conflicting network becomes withdrawn.

Notes:

The current algorithm will derive an unchanged ID
if one of the conflicting networks is of IP host mask.
This will cause problems that the algorithm try to solve.

On the other hand, the perfect algorithm for
LSID collision resolution does not exist in
that a flat address space cannot accommodate
all of the overlaid supernet/subnet IDs.
For example,
route1 - 10.0.0.0/32
route2 - 10.0.0.1/32
route3 - 10.0.0.0/31
There is no way to originate 3 LSAs with distinct LSIDs.

Thus though in majority cases, LSID collision even
with host route is resolvable, the suppressing
mechanism is still inevitable.
--VERIFIER NOTES--
This text is a change that should be taken through the working group process, as it seems to modify functionality.

Errata ID: 2951
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Joel Gannett
Date Reported: 2011-08-31
Rejected by: Stewart Bryant
Date Rejected: 2011-09-02

Section 3.4 says:

                   Destination   RT3 adv.   RT4 adv.
                   _________________________________
                   Ia,Ib         20         27
                   N6            16         15
                   N7            20         19
                   N8            18         18
                   N9-N11,H1     29         36
                   _________________________________
                   RT5           14         8
                   RT7           20         14

              Table 6: Destinations advertised into Area 1
                        by Routers RT3 and RT4.

It should say:

                   Destination   RT3 adv.   RT4 adv.
                   _________________________________
                   Ia,Ib         20         27
                   N6            16         15
                   N7            20         19
                   N8            18         18
                   N9-N11,H1     29         29
                   _________________________________
                   RT5           14         8
                   RT7           20         14

              Table 6: Destinations advertised into Area 1
                        by Routers RT3 and RT4.

Notes:

The distance from RT4 to N9-N11,H1 should be changed from 36 to 29 to be consistent with the row above that, which shows the distance from RT3 to N8 and RT4 to N8 as the same value, 18. The length 18 path from RT3 to N8 is RT3-RT6-RT10-N8, while the length 18 path from RT4 to N8 is RT4-RT5-RT7-RT10-N8. The summarized N9-N11,H1 network is a distance 11 beyond that, or 29 in both cases. The length 29 path from RT3 to N9-N11,H1 is RT3-RT6-RT10-RT11-(N9-N11,H1), and the length 29 path from RT4 to N9-N11,H1 is RT4-RT5-RT7-RT10-RT11-(N9-N11,H1).
--VERIFIER NOTES--
Joel made an error in posting this erratum. He posted a corrected erratum (2953) to which the reader is referred.

Errata ID: 3644
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Preet D'Souza
Date Reported: 2013-06-07
Rejected by: Stewart Bryant
Date Rejected: 2013-09-19

Section 2.1.2 says:

                                       **FROM**

                 |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|
                 |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9|
              ----- ---------------------------------------------
              RT1|  |  |  |  |  |  |  |  |  |  |  |  |0 |  |  |  |
              RT2|  |  |  |  |  |  |  |  |  |  |  |  |0 |  |  |  |
              RT3|  |  |  |  |  |6 |  |  |  |  |  |  |0 |  |  |  |
              RT4|  |  |  |  |8 |  |  |  |  |  |  |  |0 |  |  |  |
              RT5|  |  |  |8 |  |6 |6 |  |  |  |  |  |  |  |  |  |
              RT6|  |  |8 |  |7 |  |  |  |  |5 |  |  |  |  |  |  |
              RT7|  |  |  |  |6 |  |  |  |  |  |  |  |  |0 |  |  |
          *   RT8|  |  |  |  |  |  |  |  |  |  |  |  |  |0 |  |  |
          *   RT9|  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |0 |
          T  RT10|  |  |  |  |  |7 |  |  |  |  |  |  |  |0 |0 |  |
          O  RT11|  |  |  |  |  |  |  |  |  |  |  |  |  |  |0 |0 |
          *  RT12|  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |0 |
          *    N1|3 |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
               N2|  |3 |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
               N3|1 |1 |1 |1 |  |  |  |  |  |  |  |  |  |  |  |  |
               N4|  |  |2 |  |  |  |  |  |  |  |  |  |  |  |  |  |
               N6|  |  |  |  |  |  |1 |1 |  |1 |  |  |  |  |  |  |
               N7|  |  |  |  |  |  |  |4 |  |  |  |  |  |  |  |  |
               N8|  |  |  |  |  |  |  |  |  |3 |2 |  |  |  |  |  |
               N9|  |  |  |  |  |  |  |  |1 |  |1 |1 |  |  |  |  |
              N10|  |  |  |  |  |  |  |  |  |  |  |2 |  |  |  |  |
              N11|  |  |  |  |  |  |  |  |3 |  |  |  |  |  |  |  |
              N12|  |  |  |  |8 |  |2 |  |  |  |  |  |  |  |  |  |
              N13|  |  |  |  |8 |  |  |  |  |  |  |  |  |  |  |  |
              N14|  |  |  |  |8 |  |  |  |  |  |  |  |  |  |  |  |
              N15|  |  |  |  |  |  |9 |  |  |  |  |  |  |  |  |  |
               H1|  |  |  |  |  |  |  |  |  |  |  |10|  |  |  |  |
               

It should say:

                                    **FROM**

                 |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|
                 |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9|
              ----- ---------------------------------------------
              RT1|  |  |  |  |  |  |  |  |  |  |  |  |0 |  |  |  |
              RT2|  |  |  |  |  |  |  |  |  |  |  |  |0 |  |  |  |
              RT3|  |  |  |  |  |6 |  |  |  |  |  |  |0 |  |  |  |
              RT4|  |  |  |  |8 |  |  |  |  |  |  |  |0 |  |  |  |
              RT5|  |  |  |8 |  |6 |6 |  |  |  |  |  |  |  |  |  |
              RT6|  |  |8 |  |7 |  |  |  |  |5 |  |  |  |  |  |  |
              RT7|  |  |  |  |6 |  |  |  |  |  |  |  |  |0 |  |  |
          *   RT8|  |  |  |  |  |  |  |  |  |  |  |  |  |0 |  |  |
          *   RT9|  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |0 |
          T  RT10|  |  |  |  |  |7 |  |  |  |  |  |  |  |0 |0 |  |
          O  RT11|  |  |  |  |  |  |  |  |  |  |  |  |  |  |0 |0 |
          *  RT12|  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |0 |
          *    N1|3 |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
               N2|  |3 |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
               N3|1 |1 |1 |1 |  |  |  |  |  |  |  |  |  |  |  |  |
               N4|  |  |2 |  |  |  |  |  |  |  |  |  |  |  |  |  |
               N6|  |  |  |  |  |  |1 |1 |  |1 |  |  |  |  |  |  |
               N7|  |  |  |  |  |  |  |4 |  |  |  |  |  |  |  |  |
               N8|  |  |  |  |  |  |  |  |  |3 |2 |  |  |  |  |  |
               N9|  |  |  |  |  |  |  |  |1 |  |1 |1 |  |  |  |  |
              N10|  |  |  |  |  |  |  |  |  |  |  |2 |  |  |  |  |
              N11|  |  |  |  |  |  |  |  |3 |  |  |  |  |  |  |  |
              N12|  |  |  |  |8 |  |2 |  |  |  |  |  |  |  |  |  |
              N13|  |  |  |  |8 |  |  |  |  |  |  |  |  |  |  |  |
              N14|  |  |  |  |8 |  |  |  |  |  |  |  |  |  |  |  |
              N15|  |  |  |  |  |  |9 |  |  |  |  |  |  |  |  |  |
               H1|  |  |  |  |  |  |  |  |  |  |  |10|  |  |  |  |
               Ia|  |  |  |  |  |  |  |  |  |5 |  |  |  |  |  |  |
               Ib|  |  |  |  |  |7 |  |  |  |  |  |  |  |  |  |  |

Notes:

section 2.1.2

Page 20, Figure 2 : A sample Autonomous System.

The interfaces Ia and Ib have not been added to the directed graph.
By definition of point-to-point links under OSPF, for serial interfaces defined by IP addresses,
router RT6 should advertise a stub network to Ib whereas router RT6 should advertise a stub network to Ia .
--VERIFIER NOTES--
The reported made an error in this submission which was
corrected in Erratum 3645

Errata ID: 5611
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Anil Chaitanya Mandru
Date Reported: 2019-01-22
Rejected by: Alvaro Retana
Date Rejected: 2019-01-28

Section 16.1 (4) says:

In this case, the current routing table entry
            should be overwritten if and only if the newly found path is
            just as short and the current routing table entry's Link
            State Origin has a smaller Link State ID than the newly
            added vertex' LSA.

It should say:

In this case, if the newly found path is just as short, 
then both the paths should be added to the routing table. 

Notes:

If the newly found path is just as short then both the paths should be considered for ECMP. Why should the smaller Link State ID path overwrite the current one even if the paths are equi distant?
--VERIFIER NOTES--
See WG discussion here: https://mailarchive.ietf.org/arch/msg/lsr/ACVzdktoiFbIcMyQck1RCGn50es

From Acee Lindem: "This is the case where the transit network vertex corresponding to a network-LSA is newly added to the current intra-area graph and an intra-area route corresponding to the SPF in progress already exists. This implies that there was another network-LSA. So, either the network corresponding to the subnet is partitioned or there is a network configuration error with the same subnet configured for multiple multi-access networks. In either case, I don't really see the benefit of an ECMP route. In fact, it could make trouble-shooting the problem more difficult. "

Note also that the proposed text would result in a modification of the process to calculate the routing table, not just a correction. A change like that should be discussed in the WG/mailing list instead.

Errata ID: 5956
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Marcelo Bustani
Date Reported: 2020-01-08
Rejected by: Alvaro Retana
Date Rejected: 2020-03-18

Section 12.4.1 says:

Router-LSAs

If the state of the interface is Loopback, add a Type 3
link (stub network) as long as this is not an interface
to an unnumbered point-to-point network.  The Link ID
should be set to the IP interface address, the Link Data
set to the mask 0xffffffff (indicating a host route),
and the cost set to 0.

===================================
12.4.1.4.  Describing Point-to-MultiPoint interfaces

                For operational Point-to-MultiPoint interfaces, one or
                more link descriptions are added to the router-LSA as
                follows:

                o   A single Type 3 link (stub network) is added with
                    Link ID set to the router's own IP interface
                    address, Link Data set to the mask 0xffffffff
                    (indicating a host route), and cost set to 0.
=============================================================================
C.3 Router interface parameters
 
 Interface output cost
            The cost of sending a packet on the interface, expressed in
            the link state metric.  This is advertised as the link cost
            for this interface in the router's router-LSA. The interface
            output cost must always be greater than 0.

It should say:

"cost set to 0" to at least "greater than 0"

Notes:

The section 12.4.1 and 12.4.1.4 are inconsistent with the appendix c.3.

These both section we find the cost to stub networks have to be set to 0, but in appendix c.3 we see that the interfaces must have greater than 0.
--VERIFIER NOTES--
A discussion on the WG list (lsr) resulted a consensus of no change needed.
https://mailarchive.ietf.org/arch/msg/lsr/FFiqi15XPunSwOV5BO1pl4o5xYY/

Errata ID: 7757
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Lokesh Venkata Kumar Chakka
Date Reported: 2024-01-11
Rejected by: John Scudder
Date Rejected: 2024-01-11

Section A.4.5 says:

Forwarding address
Data traffic for the advertised destination will be forwarded to this address. If the Forwarding address is set to 0.0.0.0, data traffic will be forwarded instead to the LSA's originator (i.e., the responsible AS boundary router).

It should say:

Forwarding address
Data traffic for the advertised destination will be forwarded to this address. If the Forwarding address is set to a Router ID address value other than 0.0.0.0, data traffic will be forwarded to that Router instead to the LSA's originator (i.e., the responsible AS boundary router).

Notes:

Data traffic destined to the network indicated by Link State ID will be routed to that Router ID mentioned in forwarding address. If forwarding address is set to 0.0.0.0, it will be forwarded to LSA Originator itself.
--VERIFIER NOTES--
See https://mailarchive.ietf.org/arch/msg/lsr/_Xa4tym_roMmxFioFbrF3WRkKcM/

Errata ID: 2632
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dave Cowley
Date Reported: 2010-11-13
Rejected by: Stewart Bryant
Date Rejected: 2013-01-07

Section 11. says:

    Cost
        The link state cost of the path to the destination.  For all
        paths except type 2 external paths this describes the entire
        path's cost.  For Type 2 external paths, this field describes
        the cost of the portion of the path internal to the AS. 

It should say:

    Cost
        The link state cost of the path to the destination.  For all
        paths except type 2 external paths this describes the entire
        path's cost.  For Type 1 external paths, this field describes
        the cost of the portion of the path both internal and external
        to the AS.  

Notes:

'Type 2 cost' is listed in the subsequent 'field' description for section 11 (The Routing Table Structure).
--VERIFIER NOTES--
The text is correct as written in the RFC.

Errata ID: 2952
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Joel Gannett
Date Reported: 2011-08-31
Rejected by: Stewart Bryant
Date Rejected: 2013-01-07

Section 14.1 says:

Premature aging is also be used when unexpectedly receiving self-originated
LSAs during the flooding procedure (see Section 13.4).

It should say:

Premature aging might also be used when unexpectedly receiving self-originated
LSAs during the flooding procedure (see Section 13.4).

Notes:

Change "is also be used" to "might also be used."
--VERIFIER NOTES--
The text in section 13.4 that is referenced is a case where premature aging is used.

Errata ID: 3452
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: David Jet
Date Reported: 2013-01-12
Rejected by: Stewart Bryant
Date Rejected: 2013-01-28

Section 11 says:

Multiple LSAs may
reference the destination, however a tie-breaking scheme always
reduces the choice to a single LSA.

It should say:

Multiple LSAs may
reference the same destination, however a tie-breaking scheme always
reduces the choice to a single LSA. 

Notes:

I think should add the "same" to describe it more clearly.
--VERIFIER NOTES--
Section 11 is written in terms of "the destination", and this is clearly a single destination, thus there should be no confusion with the original text.

Errata ID: 5269
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Angelos Vassiliou
Date Reported: 2018-03-01
Rejected by: Alia Atlas
Date Rejected: 2018-03-01

Section 9.1 says:

The interface is to a broadcast or NBMA network on
 which another router has been selected to be the 
Designated Router.

It should say:

The interface is connected to a broadcast or NBMA 
network on which another router has been selected 
to be the Designated Router.

Notes:

--VERIFIER NOTES--
An interface is the connection point. This minor editorial suggestion does not add significant clarity.

Errata ID: 5684
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: jonathan natale
Date Reported: 2019-04-04
Rejected by: Alvaro Retana
Date Rejected: 2019-06-28

Section 9.4 says:

These two alternatives (~=">=1 BDRs" vs. ~="no BDRs") seem (to me at
least, maybe I missed the point) to have the same outcome (~="highest
becomes BDR")--please clarify it:
If one or more of these
            routers have declared themselves Backup Designated
Router[alternative1]
            (i.e., they are currently listing themselves as Backup
            Designated Router, but not as Designated Router, in their
            Hello Packets) the one having highest Router Priority is
            declared to be Backup Designated Router.  In case of a tie,
            the one having the highest Router ID is chosen.  If no
            routers have declared themselves Backup Designated
Router[alternative2],



Moy                         Standards Track                    [Page 75]
 
RFC 2328                     OSPF Version 2                   April 1998


            choose the router having highest Router Priority, (again
            excluding those routers who have declared themselves
            Designated Router), and again use the Router ID to break
            ties.

It should say:

TBD

Notes:

It is unclear to me if a BDR should get preempted (I know the BDR should not).
--VERIFIER NOTES--
The confusion was cleared on the WG list.

RFC 2373, "IP Version 6 Addressing Architecture", July 1998

Note: This RFC has been obsoleted by RFC 3513

Source of RFC: ipngwg (int)

Errata ID: 456
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mark Meiss
Date Reported: 2001-07-26
Rejected by: Brian Haberman
Date Rejected: 2012-04-25

It appears that the ABNF grammar for textual representations of IPv6 addresses as detailed in Appendix B of RFC 2373 is not correct in its treatment of IPv6 addresses with a trailing IPv4 address. Specifically, section 2.2.3 of the RFC states that:

 "::13.1.83.3" 

It should say:

      IPv6address = dcolon | hexpart

      IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
      IPv6prefix  = hexpart "/" 1*2DIGIT

      dcolon  = "::" | "::" hexseq [ ":" IPv4address ] | "::" [ IPv4address ]
      hexpart = hexseq | hexseq ":" IPv4address | hexseq dcolon
      hexseq  = hex4 *( ":" hex4)
      hex4    = 1*4HEXDIG

Notes:

According to the grammar in Appendix B, this is not a valid IPv6
address; there is no provision for a double colon followed by an IPv4
address. However, the grammar does allow for a double colon, followed by
a colon, followed by an IPv4 address. In other words, ":::13.1.83.3" is a
valid address according to the grammar and "::13.1.83.3" is not.

I blame the discrepancy on the grammar simply because I feel that the
intent of the RFC was clearly to prefer two colons over three colons
before a trailing IPv4 address. This seems to match the behavior of
existing applications.
--VERIFIER NOTES--
This RFC has been replaced by RFC 3513

RFC 2397, "The "data" URL scheme", August 1998

Source of RFC: Legacy

Errata ID: 3360
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Lance E Sloan
Date Reported: 2012-09-20
Rejected by: Barry Leiba
Date Rejected: 2012-09-20

Throughout the document, when it says:

The "data" URL scheme

It should say:

The "data" URI scheme

Notes:

The text refers to "URL" throughout, but to be correct, these are actually URIs.
--VERIFIER NOTES--
"URI"s are first documented in RFC 2396, which was developed at the same time as RFC 2397. At the time the document that became 2397 was approved, "URL" was the correct term. While it's correct that "URI" is the preferred term now, "URL" is also correct, and is the term that was in use when this document was written. This is not an error in the document.

RFC 2428, "FTP Extensions for IPv6 and NATs", September 1998

Source of RFC: ftpext (app)

Errata ID: 5412
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Igor Mozolevsky
Date Reported: 2018-06-27
Rejected by: RFC Editor
Date Rejected: 2018-07-09

Section References says:

[AO98]   Allman, M., and S. Ostermann, "FTP Security
         Considerations", Work in Progress.

It should say:

[AO98]   Allman, M., and S. Ostermann, "FTP Security
         Considerations", adopted as RFC 2577.

Notes:

Time has moved on, and a WIP became an RFC; this change makes it easer for the reader to cross reference.



--VERIFIER NOTES--
Errata reports are intended only for errors at the time of publication (RFC 2577 was not published until May 1999).

A future update of RFC 2428 can resolve this by pointing to the following as a reference entry:

[RFC2577] Allman, M. and S. Ostermann, "FTP Security Considerations", RFC 2577, DOI 10.17487/RFC2577, May 1999, <https://www.rfc-editor.org/info/rfc2577>.

RFC 2435, "RTP Payload Format for JPEG-compressed Video", October 1998

Source of RFC: avt (rai)

Errata ID: 4094
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Julius Richard Friedman
Date Reported: 2014-09-04
Rejected by: Ben Campbell
Date Rejected: 2015-07-22

Section Appendix A says:

/*
 * Table K.1 from JPEG spec.
 */
static const int jpeg_luma_quantizer[64] = {
        16, 11, 10, 16, 24, 40, 51, 61,
        12, 12, 14, 19, 26, 58, 60, 55,
        14, 13, 16, 24, 40, 57, 69, 56,
        14, 17, 22, 29, 51, 87, 80, 62,
        18, 22, 37, 56, 68, 109, 103, 77,
        24, 35, 55, 64, 81, 104, 113, 92,
        49, 64, 78, 87, 103, 121, 120, 101,
        72, 92, 95, 98, 112, 100, 103, 99
};

/*
 * Table K.2 from JPEG spec.
 */
static const int jpeg_chroma_quantizer[64] = {
        17, 18, 24, 47, 99, 99, 99, 99,
        18, 21, 26, 66, 99, 99, 99, 99,
        24, 26, 56, 99, 99, 99, 99, 99,
        47, 66, 99, 99, 99, 99, 99, 99,
        99, 99, 99, 99, 99, 99, 99, 99,
        99, 99, 99, 99, 99, 99, 99, 99,
        99, 99, 99, 99, 99, 99, 99, 99,
        99, 99, 99, 99, 99, 99, 99, 99
};

It should say:

/*
 * Table K.1 from JPEG spec.
 */
static const int jpeg_luma_quantizer[64] = {
           16, 11, 12, 14, 12, 10, 16, 14,
           13, 14, 18, 17, 16, 19, 24, 40,
           26, 24, 22, 22, 24, 49, 35, 37,
           29, 40, 58, 51, 61, 60, 57, 51,
           56, 55, 64, 72, 92, 78, 64, 68,
           87, 69, 55, 56, 80, 109, 81, 87,
           95, 98, 103, 104, 103, 62, 77, 113,
           121, 112, 100, 120, 92, 101, 103, 99,
};

/*
 * Table K.2 from JPEG spec.
 */
static const int jpeg_chroma_quantizer[64] = {
           17, 18, 18, 24, 21, 24, 47, 26,
           26, 47, 99, 66, 56, 66, 99, 99,
           99, 99, 99, 99, 99, 99, 99, 99,
           99, 99, 99, 99, 99, 99, 99, 99,
           99, 99, 99, 99, 99, 99, 99, 99,
           99, 99, 99, 99, 99, 99, 99, 99,
           99, 99, 99, 99, 99, 99, 99, 99,
           99, 99, 99, 99, 99, 99, 99, 99
};

Notes:

Luma and Chroma was not in Zig Zag order and Luma energy has been de-saturated.
--VERIFIER NOTES--
Rejected per discussion in avtcore

Errata ID: 4095
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Julius Richard Friedman
Date Reported: 2014-09-04
Rejected by: Ben Campbell
Date Rejected: 2015-07-22

Section Appendix B says:

int MakeHeaders(u_char *p, int type, int w, int h, u_char *lqt,
                u_char *cqt, u_short dri)
{
        u_char *start = p;

        /* convert from blocks to pixels */
        w <<= 3;
        h <<= 3;



Berc, et. al.               Standards Track                    [Page 19]
 
RFC 2435              RTP Payload Format for JPEG           October 1998


        *p++ = 0xff;
        *p++ = 0xd8;            /* SOI */

        p = MakeQuantHeader(p, lqt, 0);
        p = MakeQuantHeader(p, cqt, 1);

        if (dri != 0)
                p = MakeDRIHeader(p, dri);

        *p++ = 0xff;
        *p++ = 0xc0;            /* SOF */
        *p++ = 0;               /* length msb */
        *p++ = 17;              /* length lsb */
        *p++ = 8;               /* 8-bit precision */
        *p++ = h >> 8;          /* height msb */
        *p++ = h;               /* height lsb */
        *p++ = w >> 8;          /* width msb */
        *p++ = w;               /* wudth lsb */
        *p++ = 3;               /* number of components */
        *p++ = 0;               /* comp 0 */
        if (type == 0)
                *p++ = 0x21;    /* hsamp = 2, vsamp = 1 */
        else
                *p++ = 0x22;    /* hsamp = 2, vsamp = 2 */
        *p++ = 0;               /* quant table 0 */
        *p++ = 1;               /* comp 1 */
        *p++ = 0x11;            /* hsamp = 1, vsamp = 1 */
        *p++ = 1;               /* quant table 1 */
        *p++ = 2;               /* comp 2 */
        *p++ = 0x11;            /* hsamp = 1, vsamp = 1 */
        *p++ = 1;               /* quant table 1 */
        p = MakeHuffmanHeader(p, lum_dc_codelens,
                              sizeof(lum_dc_codelens),
                              lum_dc_symbols,
                              sizeof(lum_dc_symbols), 0, 0);
        p = MakeHuffmanHeader(p, lum_ac_codelens,
                              sizeof(lum_ac_codelens),
                              lum_ac_symbols,
                              sizeof(lum_ac_symbols), 0, 1);
        p = MakeHuffmanHeader(p, chm_dc_codelens,
                              sizeof(chm_dc_codelens),
                              chm_dc_symbols,
                              sizeof(chm_dc_symbols), 1, 0);
        p = MakeHuffmanHeader(p, chm_ac_codelens,
                              sizeof(chm_ac_codelens),
                              chm_ac_symbols,
                              sizeof(chm_ac_symbols), 1, 1);




Berc, et. al.               Standards Track                    [Page 20]
 
RFC 2435              RTP Payload Format for JPEG           October 1998


        *p++ = 0xff;
        *p++ = 0xda;            /* SOS */
        *p++ = 0;               /* length msb */
        *p++ = 12;              /* length lsb */
        *p++ = 3;               /* 3 components */
        *p++ = 0;               /* comp 0 */
        *p++ = 0;               /* huffman table 0 */
        *p++ = 1;               /* comp 1 */
        *p++ = 0x11;            /* huffman table 1 */
        *p++ = 2;               /* comp 2 */
        *p++ = 0x11;            /* huffman table 1 */
        *p++ = 0;               /* first DCT coeff */
        *p++ = 63;              /* last DCT coeff */
        *p++ = 0;               /* sucessive approx. */

        return (p - start);
};

It should say:

int MakeHeaders(u_char *p, int type, int w, int h, u_char *lqt,
                u_char *cqt, u_short dri)
{
        u_char *start = p;

        /* convert from blocks to pixels */
        w <<= 3;
        h <<= 3;
        *p++ = 0xff;
        *p++ = 0xd8;            /* SOI */

        p = MakeQuantHeader(p, lqt, 0);
        if(cqt != NULL) p = MakeQuantHeader(p, cqt, 1);

        if (dri != 0)
                p = MakeDRIHeader(p, dri);

        *p++ = 0xff;
        *p++ = 0xc0;            /* SOF */
        *p++ = 0;               /* length msb */
        *p++ = 17;              /* length lsb */
        *p++ = 8;               /* 8-bit precision */
        *p++ = h >> 8;          /* height msb */
        *p++ = h;               /* height lsb */
        *p++ = w >> 8;          /* width msb */
        *p++ = w;               /* wudth lsb */
        *p++ = 3;               /* number of components */
        *p++ = 1;               /* comp 1 */
        if (type == 0)
                *p++ = 0x21;    /* hsamp = 2, vsamp = 1 */
        else
                *p++ = 0x22;    /* hsamp = 2, vsamp = 2 */
        *p++ = 0;               /* quant table 0 */
        *p++ = 1;               /* comp 1 */
        *p++ = 0x11;            /* hsamp = 1, vsamp = 1 */
        *p++ = 1;               /* quant table 1 */
        *p++ = 2;               /* comp 2 */
        *p++ = 0x11;            /* hsamp = 1, vsamp = 1 */
        *p++ = 1;               /* quant table 1 */
        p = MakeHuffmanHeader(p, lum_dc_codelens,
                              sizeof(lum_dc_codelens),
                              lum_dc_symbols,
                              sizeof(lum_dc_symbols), 0, 0);
        p = MakeHuffmanHeader(p, lum_ac_codelens,
                              sizeof(lum_ac_codelens),
                              lum_ac_symbols,
                              sizeof(lum_ac_symbols), 0, 1);
        if(cqt != NULL)
        {
        p = MakeHuffmanHeader(p, chm_dc_codelens,
                              sizeof(chm_dc_codelens),
                              chm_dc_symbols,
                              sizeof(chm_dc_symbols), 1, 0);
        p = MakeHuffmanHeader(p, chm_ac_codelens,
                              sizeof(chm_ac_codelens),
                              chm_ac_symbols,
                              sizeof(chm_ac_symbols), 1, 1);
       }




Berc, et. al.               Standards Track                    [Page 20]
 
RFC 2435              RTP Payload Format for JPEG           October 1998


        *p++ = 0xff;
        *p++ = 0xda;            /* SOS */
        *p++ = 0;               /* length msb */
        *p++ = cqt != NULL ? 0x12 : 0x0b;/* length lsb */
        *p++ = cqt != NULL ? 0x03 : 0x01;/* 3 components */
        *p++ = 0;               /* comp 0 */
        *p++ = 0;               /* huffman table 0 */
        *p++ = 0x01;               /* comp 1 */
        *p++ = cqt != NULL ? 0x11 : 0x00;/* huffman table 1 */
        if(cqt != NULL) *p++ = 2;/* comp 2 */
        *p++ = cqt != NULL ? 0x11 : 0x00;/* huffman table 1 */
        *p++ = 0;               /* first DCT coeff */
        *p++ = 63;              /* last DCT coeff */
        *p++ = 0;               /* sucessive approx. */

        return (p - start);
};

Notes:

Did not take into account cases with only 1 component was used.
--VERIFIER NOTES--
Rejected due to discussion in avtcore

Errata ID: 4096
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Julius Richard Friedman
Date Reported: 2014-09-04
Rejected by: Ben Campbell
Date Rejected: 2015-07-22

Section Discussion says:

 types  component samp. fact. samp. fact. table number
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |       |  1 (Y)  |     2     |     1     |     0     |
         | 0, 64 |  2 (U)  |     1     |     1     |     1     |
         |       |  3 (V)  |     1     |     1     |     1     |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |       |  1 (Y)  |     2     |     2     |     0     |
         | 1, 65 |  2 (U)  |     1     |     1     |     1     |
         |       |  3 (V)  |     1     |     1     |     1     |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

TO BE DETERMINED

Notes:

types component samp. fact. samp. fact. table number
FROM StartOf Frame (0xFFC0)

Read Nf - Number of image components in frame

if(Nf > 1)

Read Each Component

0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| H | V |
+-+-+-+-+-+-+-+-+

H: Horizontal sampling factor – Specifies the relationship between the component horizontal dimension
and maximum image dimension X (see Jpeg Spec A.1.1); also specifies the number of horizontal data units of component
Ci in each MCU, when more than one component is encoded in a scan.
Vi: Vertical sampling factor – Specifies the relationship between the component vertical dimension and
maximum image dimension Y (see Jpeg Spec A.1.1); also specifies the number of vertical data units of component Ci in
each MCU, when more than one component is encoded in a scan.
Tqi: Implied from the position in parsing
--VERIFIER NOTES--
Rejected based on discussion in avtcore. (And also because the errata does not contain a proposed change to the text).

Errata ID: 4097
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Julius Richard Friedman
Date Reported: 2014-09-04
Rejected by: Ben Campbell
Date Rejected: 2015-07-22

Section 3.1.5 says:

3.1.5.  Width: 8 bits

   This field encodes the width of the image in 8-pixel multiples (e.g.,
   a width of 40 denotes an image 320 pixels wide).  The maximum width
   is 2040 pixels.

3.1.6.  Height: 8 bits

   This field encodes the height of the image in 8-pixel multiples
   (e.g., a height of 30 denotes an image 240 pixels tall). When
   encoding interlaced video, this is the height of a video field, since
   fields are individually JPEG encoded. The maximum height is 65535
   pixels.

It should say:

3.1.5.  Width: 8 bits

   This field encodes the width of the image in 8-pixel multiples (e.g.,
   a width of 40 denotes an image 320 pixels wide).  The maximum width
   is 2040 pixels.

3.1.6.  Height: 8 bits

   This field encodes the height of the image in 8-pixel multiples
   (e.g., a height of 30 denotes an image 240 pixels tall). When
   encoding interlaced video, this is the height of a video field, since
   fields are individually JPEG encoded. The maximum height is 65535
   pixels.

Notes:

Use a divisor of 256 to determine the height, where 8 / 256 = 32.

Ensure FragmentOffset does not exceed 2^24, if it does then use 2^24 - value)
--VERIFIER NOTES--
Rejected based on discussion in avtcore

RFC 2439, "BGP Route Flap Damping", November 1998

Source of RFC: idr (rtg)

Errata ID: 3964
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Gunjan Bansal
Date Reported: 2014-04-15
Rejected by: Alia Atlas
Date Rejected: 2014-05-07

Section 4.8.2 says:

 In either case then:

     1.  set t-updated = t-now

     2.  insert into a reuse list (see Section 4.8.6)

It should say:

 In either case then:

     1.  set t-updated = t-now

Notes:

The route which is unreachable should NOT be inserted into the reuse-list. reuse-list (as per explanation in Section 4.8.7) is used for fast evaluation of routes which have been suppressed long enough and can be potentially used again. The "unreachability/withdrawal" of route is never suppressed and never needs to be re-evaluated in future.
--VERIFIER NOTES--
RFC 2439 isn't the easiest to read, but this erratum is not correct. Despite its name, the "reuse list" as described in S. 4.8.7 is used for processing timer-driven events in general, including freeing up damping structures ("histories"). Quoting from S. 4.8.7, "Handling Reuse Timer Events":

all of the routes in the first queue will be
available for immediate reuse if reachable or the history entry could
^^^^^^^^^^^^^^^^^^^^^^^^^^
be disposed of if unreachable.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

If you have any doubt that "history" means "damping structure", take a look at S. 4.8.2:

If there is no previous stability history (the damping structure
pointer is zero), then:

Presumably, you're clear on why histories for unreachable routes need to be maintained to begin with.

RFC 2460, "Internet Protocol, Version 6 (IPv6) Specification", December 1998

Note: This RFC has been obsoleted by RFC 8200

Note: This RFC has been updated by RFC 5095, RFC 5722, RFC 5871, RFC 6437, RFC 6564, RFC 6935, RFC 6946, RFC 7045, RFC 7112

Source of RFC: ipngwg (int)

Errata ID: 2843
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Florian Weimer
Date Reported: 2011-06-24
Rejected by: Brian Haberman
Date Rejected: 2012-06-01

Section 5 says:

In response to an IPv6 packet that is sent to an IPv4 destination
(i.e., a packet that undergoes translation from IPv6 to IPv4), the
originating IPv6 node may receive an ICMP Packet Too Big message
reporting a Next-Hop MTU less than 1280.  In that case, the IPv6 node
is not required to reduce the size of subsequent packets to less than
1280, but must include a Fragment header in those packets so that the
IPv6-to-IPv4 translating router can obtain a suitable Identification
value to use in resulting IPv4 fragments.  Note that this means the
payload may have to be reduced to 1232 octets (1280 minus 40 for the
IPv6 header and 8 for the Fragment header), and smaller still if
additional extension headers are used.

It should say:

(delete paragraph)

Notes:

This requirement makes it impossible to offer services over IPv6 without keeping per-flow state in the server node. There is no reason why IPv4 fragmentation cannot be used after translation to IPv4.
--VERIFIER NOTES--
This would be a fundamental change to the IPv6 protocol specification. Such a proposal would need to be formally proposed as an internet draft.

RFC 2464, "Transmission of IPv6 Packets over Ethernet Networks", December 1998

Note: This RFC has been updated by RFC 6085, RFC 8064

Source of RFC: ipngwg (int)

Errata ID: 4855
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Gigon Olivier
Date Reported: 2016-11-06
Rejected by: Eric Vyncke
Date Rejected: 2021-01-28

Section 4 says:

For example, the Interface Identifier for an Ethernet interface whose
   built-in address is, in hexadecimal,

                             34-56-78-9A-BC-DE

   would be

                         36-56-78-FF-FE-9A-BC-DE.

It should say:

For example, the Interface Identifier for an Ethernet interface whose
   built-in address is, in hexadecimal,

                             34-56-78-9A-BC-DE

   would be

                         32-56-78-FF-FE-9A-BC-DE.

Notes:

U/L bit inversion of 34 should be 32 instead of 36

--- Verifier note --
The example is correct: 0x34 = 0x0011 0100
The U/L bit is " the next-to-lowest order bit of the first octet of the EUI-64" 0b00000010
So flipping this bit in 0x34 gives 0x0011 0110 = 0x36 as in RFC 2464
--VERIFIER NOTES--
The example is correct: 0x34 = 0x0011 0100

The U/L bit is " the next-to-lowest order bit of the first octet of the EUI-64" 0b00000010

So flipping this bit in 0x34 gives 0x0011 0110 = 0x36 as in RFC 2464

RFC 2548, "Microsoft Vendor-specific RADIUS Attributes", March 1999

Source of RFC: radius (ops)

Errata ID: 4369
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alan DeKok
Date Reported: 2015-05-19
Rejected by: Benoit Claise
Date Rejected: 2015-09-14

Section 2.4.1 says:

The Keys field MUST be encrypted by the RADIUS server using the
same method defined for the User-Password Attribute [3].  Padding
is required because the method referenced above requires the field
to be encrypted to be a multiple of sixteen octets in length.

It should say:

The Keys field MUST be encrypted by the RADIUS server using the
same method defined for the User-Password Attribute [3].  Padding
is required because the method referenced above requires the field
to be encrypted to be a multiple of sixteen octets in length.

We note that the encryption method for the User-Password attribute
does not contain a field describing the length of the decrypted data.
  Despite this, the User-Password attribute contains data which is
variable length.  The length of that data is commonly determined by
looking for either the end of the data, or the first zero octet in the
data, whichever comes first.

That practice cannot be used here, as the Keys field can contain
embedded zero octets.  This means that the length of the decrypted
data MUST be set explicitly to 32 octets for this attribute.

Notes:

re: MS-CHAP-MPPE-Keys "obfuscation"
--VERIFIER NOTES--
Section 2.4.1 describes 32 octets of content, which *include* padding.

The decrypted data is thus less than 32 octets. The ASCII art in that sections shows 64 bit of padding in the end, meaning it's only 24 octets of decrypted keys.

RFC 2549, "IP over Avian Carriers with Quality of Service", April 1999

Source of RFC: INDEPENDENT

Errata ID: 3793
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Anne van Kesteren
Date Reported: 2013-11-10
Rejected by: Nevil Brownlee (ISE)
Date Rejected: 2014-01-17

In the Security Considerations

It should say:

Hawks.

Notes:

Per mnot.

--- Verifier Notes ---
1. This erratum doesn't say which phrase in the original
text needs changing.
2. Errata are intended to note Editorial or Technical changes;
as far as I can see this one is neither.

RFC 2560, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", June 1999

Note: This RFC has been obsoleted by RFC 6960

Note: This RFC has been updated by RFC 6277

Source of RFC: pkix (sec)

Errata ID: 3272
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Matthew Moore
Date Reported: 2012-06-29
Rejected by: Sean Turner
Date Rejected: 2012-07-02

Section 4.1.1 says:

   OCSPRequest     ::=     SEQUENCE {
       tbsRequest                  TBSRequest,
       optionalSignature   [0]     EXPLICIT Signature OPTIONAL }

   TBSRequest      ::=     SEQUENCE {
       version             [0]     EXPLICIT Version DEFAULT v1,
       requestorName       [1]     EXPLICIT GeneralName OPTIONAL,
       requestList                 SEQUENCE OF Request,
       requestExtensions   [2]     EXPLICIT Extensions OPTIONAL }

   Signature       ::=     SEQUENCE {
       signatureAlgorithm      AlgorithmIdentifier,
       signature               BIT STRING,
       certs               [0] EXPLICIT SEQUENCE OF Certificate 
   OPTIONAL}

   Version         ::=             INTEGER  {  v1(0) }

   Request         ::=     SEQUENCE {
       reqCert                     CertID,
       singleRequestExtensions     [0] EXPLICIT Extensions OPTIONAL }

   CertID          ::=     SEQUENCE {
       hashAlgorithm       AlgorithmIdentifier,
       issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
       issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
       serialNumber        CertificateSerialNumber }

It should say:

...
   Version         ::=             INTEGER  {  v1(0) }

   GeneralName     ::=      ????
...

Notes:

The format of the GeneralName in the request syntax is never detailed.
--VERIFIER NOTES--
GeneralName is imported in the ASN.1 module from the PKIX1Explicit88 module.

RFC 2576, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", March 2000

Note: This RFC has been obsoleted by RFC 3584

Source of RFC: snmpv3 (ops)

Errata ID: 1435
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: grant mills
Date Reported: 2008-06-11
Rejected by: Dan Romascanu
Date Rejected: 2010-05-10

Section Status says:

Notes:

RFC3584 indicates that it obsoletes 2576 but there is no forward reference of this within the rfc2576. This differs from convention that I have observed.
--VERIFIER NOTES--
This comment needs to be made to the RFC Editor as it concerns the RFC Editor Web pages.

RFC 2606, "Reserved Top Level DNS Names", June 1999

Note: This RFC has been updated by RFC 6761

Source of RFC: dnsind (int)

Errata ID: 7304
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Rich Salz
Date Reported: 2023-01-13
Rejected by: Eric Vyncke
Date Rejected: 2023-08-03

Throughout the document, when it says:

example.org, ...

It should say:

example.org, example.edu, ...

Notes:

Should mention `example.edu` as one of the reserved names as well, since IANA is doing that according to Kim Davies. The 6125bis draft uses it in some examples.
--VERIFIER NOTES--
While 'example.edu' is indeed operated by IANA, it does appear neither in the "special-use domain names" registry of IANA nor in RFC 6761.

RFC 2616, "Hypertext Transfer Protocol -- HTTP/1.1", June 1999

Note: This RFC has been obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235

Note: This RFC has been updated by RFC 2817, RFC 5785, RFC 6266, RFC 6585

Source of RFC: http (app)

Errata ID: 2301
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Conrad Roche
Date Reported: 2010-06-14
Rejected by: Alexey Melnikov
Date Rejected: 2010-07-07

Section 14.36 says:

   The Referer[sic] request-header field allows the client to specify,
   for the server's benefit, the address (URI) of the resource from
   which the Request-URI was obtained (the "referrer", although the
   header field is misspelled.) The Referer request-header allows a
   server to generate lists of back-links to resources for interest,
   logging, optimized caching, etc. It also allows obsolete or mistyped
   links to be traced for maintenance. The Referer field MUST NOT be
   sent if the Request-URI was obtained from a source that does not have
   its own URI, such as input from the user keyboard.

It should say:

   The Referer[sic] request-header field allows the client to specify,
   for the server's benefit, the address (URI) of the resource from

   whose message-body the Request-URI was obtained (the "referrer", although the
   header field is misspelled.) The Referer request-header allows a
   server to generate lists of back-links to resources for interest,
   logging, optimized caching, etc. It also allows obsolete or mistyped
   links to be traced for maintenance. The Referer field MUST NOT be
   sent if the Request-URI was obtained from a source that does not have
   its own URI, such as input from the user keyboard.

Notes:

The text should mention that the referrer is specified when the URI was obtained from the message-body of the Request-URI.

For instance, when the user agent receives a 302 response for a Request-URI, it does not specify the original Request-URI in the referrer header for the subsequent request - even though the (redirect) URI "was obtained" from the (header of the) 302 response for the original Request-URI.

Roy T. Fielding replied:
I think this should be rejected. The referrer is the redirect.
User agents should be sending the redirecting URI in Referer,
or sending nothing in Referer.

In any case, see the Link header field. It is certainly possible
to be referred by something in the header fields, so saying that it
is in the message-body would be incorrect.
--VERIFIER NOTES--
As per the reply from Roy T. Fielding.

Errata ID: 2998
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Moutinho
Date Reported: 2011-10-15
Rejected by: Peter Saint-Andre
Date Rejected: 2011-10-17

Section 3.2.1 says:

   For definitive information on
   URL syntax and semantics, see "Uniform Resource Identifiers (URI):
   Generic Syntax and Semantics," RFC 2396 [42] (which replaces RFCs
   1738 [4] and RFC 1808 [11]).

It should say:

   For definitive information on
   URL syntax and semantics, see "Uniform Resource Identifiers (URI):
   Generic Syntax and Semantics," RFC 3986 [<ref>] (which updates RFCs
   1738 [4] and replaces RFC 1808 [11] and RFC 2396 [42]).

Notes:

<ref> should be added
--VERIFIER NOTES--
The reader can follow the chain of document updates from RFC 2396 to RFC 3986, which is why we do not modify published RFCs to track document updates for referenced specifications. In any case, the updated HTTP RFCs (being produced by the HTTPBIS WG) will contain the appropriate references.

Errata ID: 3056
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Moutinho
Date Reported: 2011-12-20
Rejected by: Peter Saint-Andre
Date Rejected: 2011-12-21

Section 5.1.2 says:

Request-URI    = "*" | absoluteURI | abs_path | authority

It should say:

Request-URI    = "*" | absoluteURI | abs_path [ "?" query ] | authority

Notes:

so that "/path?query" is a valid Request-URI as it should.

because it is not the case with RFC 3986
(obsoleting RFC 2396 which has the same problem actually):

absoluteURI = absolute-URI
abs_path = path-absolute

absolute-URI = scheme ":" hier-part [ "?" query ]
path-absolute = "/" [ segment-nz *( "/" segment ) ]
segment-nz = 1*pchar
segment = *pchar
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
pct-encoded = "%" HEXDIG HEXDIG
sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="
--VERIFIER NOTES--
This issue has been fixed in the revisions to RFC 2616, see http://trac.tools.ietf.org/wg/httpbis/trac/changeset/76

Errata ID: 2645
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Winfred Qin
Date Reported: 2010-11-27
Rejected by: Peter Saint-Andre
Date Rejected: 2011-05-03

Section 3.5 says:

Use of program names for the identification of encoding formats 
is not desirable and is discouraged for future encodings. Their 
use here is representative of historical practice, not good 
design. For compatibility with previous implementations of HTTP, 
applications SHOULD consider "x-gzip" and "x-compress" to be 
equivalent to "gzip" and "compress" respectively.

It should say:

Use of program names for the identification of encoding formats 
is not desirable and is discouraged for future encodings. Their 
use here is representative of historical practice, not good 
design. For compatibility with future implementations of HTTP, 
applications SHOULD consider "x-gzip" and "x-compress" to be 
equivalent to "gzip" and "compress" respectively.

Notes:

"For compatibility with previous implementations of HTTP",
here, 'previous' should be replaced by 'future'.
--VERIFIER NOTES--
Comment by Peter Saint-Andre:

This erratum is incorrect -- the text is clearly about
backward compatibility, not forward compatibility. The
original poster can comment in the HTTPBIS WG about this
matter since draft-ietf-httpbis-p1-messaging has very
similar text.

Errata ID: 2806
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Carlos McEvilly
Date Reported: 2011-05-12
Rejected by: RFC Editor
Date Rejected: 2011-05-16

Section 14.13 says:

Applications SHOULD use this field to indicate the transfer-length of
   the message-body, unless this is prohibited by the rules in <a href="#section-   ">section</a>
   <a href="#section-   ">4.4</a>.

It should say:

Applications SHOULD use this field to indicate the transfer-length of
   the message-body, unless this is prohibited by the rules in 
<a href="#section-4.4">section 4.4</a>.

Notes:

This errata refers to the linkified version of the RFC at:

http://tools.ietf.org/html/rfc2616

Note that the original and corrected text above both contain HTML tags. In case the text doesn't survive the form submission, just to describe the problem, the link in the text shown, an internal anchor link that should point to #section-4.4, is broken because the number 4.4 is missing at the end of the anchor inside the href quotes.

--- VERIFIER NOTES ---
This report has been rejected because it is regarding a link in the HTML version of the RFC on tools.ietf.org. The report has been directed to webmaster@tools.ietf.org.

Errata are for the RFCs as available from rfc-editor.org.

RFC 2617, "HTTP Authentication: Basic and Digest Access Authentication", June 1999

Note: This RFC has been obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617

Source of RFC: http (app)

Errata ID: 1914
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Larry Westrick
Date Reported: 2009-10-14
Rejected by: Peter Saint-Andre
Date Rejected: 2011-06-27

Section 3.2.2.1 says:

3.2.2.1 Request-Digest

   If the "qop" value is "auth" or "auth-int":

      request-digest  = <"> < KD ( H(A1),     unq(nonce-value)
                                          ":" nc-value
                                          ":" unq(cnonce-value)
                                          ":" unq(qop-value)
                                          ":" H(A2)
                                  ) <">

   If the "qop" directive is not present (this construction is for
   compatibility with RFC 2069):

      request-digest  =
                 <"> < KD ( H(A1), unq(nonce-value) ":" H(A2) ) >
   <">

It should say:

3.2.2.1 Request-Digest

   If the "qop" value is "auth" or "auth-int":

      request-digest  = <"> < KD ( H(A1)  ":" unq(nonce-value)
                                          ":" nc-value
                                          ":" unq(cnonce-value)
                                          ":" unq(qop-value)
                                          ":" H(A2)
                                  ) <">

   If the "qop" directive is not present (this construction is for
   compatibility with RFC 2069):

      request-digest  =
                 <"> < KD ( H(A1) ":" unq(nonce-value) ":" H(A2) ) >
   <">

Notes:

Errata 1796 addressing this issue and was rejected, perhaps for editorial or syntax reasons, when the section as it exists does not indicate the need for a ":" between A1 and unq(nonce-value). The ":" is most certainly required between these variables if the result of the hash is to be correct.
--VERIFIER NOTES--
The verifier notes on the rejected Erratum 1796 were as follows:

###

KD is defined in the document as:

KD(secret, data) = H(concat(secret, ":", data))

So KD takes 2 parameters and the text in the RFC is correct in this respect.

###

If there is good reason to pursue this issue further, please do so outside
the errata process.

Errata ID: 1796
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jerry Conrad
Date Reported: 2009-06-19
Rejected by: Alexey Melnikov
Date Rejected: 2009-06-19

Section 3.2.2.1 says:

3.2.2.1 Request-Digest

   If the "qop" value is "auth" or "auth-int":

      request-digest  = <"> < KD ( H(A1),     unq(nonce-value)
                                          ":" nc-value
                                          ":" unq(cnonce-value)
                                          ":" unq(qop-value)
                                          ":" H(A2)
                                  ) <">

   If the "qop" directive is not present (this construction is for
   compatibility with RFC 2069):

      request-digest  =
                 <"> < KD ( H(A1), unq(nonce-value) ":" H(A2) ) >
   <">

It should say:

3.2.2.1 Request-Digest

   If the "qop" value is "auth" or "auth-int":

      request-digest  = <"> < KD ( H(A1)  ":" unq(nonce-value)
                                          ":" nc-value
                                          ":" unq(cnonce-value)
                                          ":" unq(qop-value)
                                          ":" H(A2)
                                  ) <">

   If the "qop" directive is not present (this construction is for
   compatibility with RFC 2069):

      request-digest  =
                 <"> < KD ( H(A1) ":" unq(nonce-value) ":" H(A2) ) >
   <">

Notes:

The "," after H(A1) should be ":" in two places.
--VERIFIER NOTES--
KD is defined in the document as:

KD(secret, data) = H(concat(secret, ":", data))

So KD takes 2 parameters and the text in the RFC is correct in this respect.

RFC 2640, "Internationalization of the File Transfer Protocol", July 1999

Source of RFC: ftpext (app)

Errata ID: 5445
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: David LAMBERT
Date Reported: 2018-07-28
Rejected by: Barry Leiba
Date Rejected: 2019-04-30

Throughout the document, when it says:

Notes:

The RFC talks about UTF-8 for paths, but not about response messages.
The LANG command specified in the RFC can lead servers to send reply messages containing character outside of the ASCII character set.
It should specify that UTF-8 should also be used for reply messages.
--VERIFIER NOTES--

Section 4.1 says:

This specification RECOMMENDS that the server
default language be English encoded using ASCII. This text may be
augmented by text from other languages. Once negotiated, server-PI
MUST return server messages and textual part of command responses in
the negotiated language and encoded in UTF-8.

RFC 2663, "IP Network Address Translator (NAT) Terminology and Considerations", August 1999

Source of RFC: nat (tsv)

Errata ID: 5555
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Majid Motallebikashani
Date Reported: 2018-11-17
Rejected by: Mirja Kühlewind
Date Rejected: 2018-11-26

Section 3.3 says:

   Changes to ICMP error message will include changes to the original IP
   packet (or portions thereof) embedded in the payload of the ICMP
   error message.

It should say:

   Changes to ICMP error message will include changes to the original IP
   packet and portions of data embedded in the payload of the ICMP
   error message.

Notes:

IP packet is not embedded in ICMP payload, but the other way around.
--VERIFIER NOTES--
The orginal IP packet IS included in the ICMP payload.

RFC 2759, "Microsoft PPP CHAP Extensions, Version 2", January 2000

Source of RFC: pppext (int)

Errata ID: 6429
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Valentin Atanasov
Date Reported: 2021-02-14
Rejected by: Eric Vyncke
Date Rejected: 2023-08-03

Section 9.1.2. says:

Authenticator authentication failure

                         <- Authenticator Challenge
       Peer Response/Challenge ->
                         <- Success/Authenticator Response

   (Authenticator Response verification fails, peer disconnects)

It should say:

Authenticator authentication failure

                         <- Authenticator Challenge
       Peer Response/Challenge ->
                         <- Failure/Authenticator Response

   (Authenticator Response verification fails, peer disconnects)

Notes:

According to section 6. Failure Packet is identical in format to the standard CHAP Failure packet, but there are different codes for success and for failure so in case of failure the returned code must be 4 thus in section 9.1.2. the line "<- Success/Authenticator Response" the response logic should be Failure, not Succsess.
--VERIFIER NOTES--
The example is when the authenticator fails authenticate itself to the peer (i.e., it is a rogue authenticator). MS-CHAPv2 is doing piggy-backed mutual authentication.

RFC 2782, "A DNS RR for specifying the location of services (DNS SRV)", February 2000

Note: This RFC has been updated by RFC 6335, RFC 8553

Source of RFC: dnsext (int)

Errata ID: 2984
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Jordan Brown
Date Reported: 2011-10-04
Rejected by: Brian Haberman
Date Rejected: 2012-05-01

Section Weight says:

        To select a target to be contacted next, arrange all SRV RRs
        (that have not been ordered yet) in any order, except that all
        those with weight 0 are placed at the beginning of the list.

        Compute the sum of the weights of those RRs, and with each RR
        associate the running sum in the selected order. Then choose a
        uniform random number between 0 and the sum computed
        (inclusive), and select the RR whose running sum value is the
        first in the selected order which is greater than or equal to
        the random number selected. The target host specified in the
        selected SRV RR is the next one to be contacted by the client.
        Remove this SRV RR from the set of the unordered SRV RRs and
        apply the described algorithm to the unordered SRV RRs to select
        the next target host.  Continue the ordering process until there
        are no unordered SRV RRs.  This process is repeated for each
        Priority.

It should say:

Correcting the text requires agreement on what to do with entries with
weight=0, so I don't want to try to craft text until we have agreement there.

Notes:

The problem with this algorithm is that for a total weight T, it generates a random number 0..T and so allocates T+1 shares and gives the extra share to the first entry. Thus with weights {1, 1}, the first entry is selected 2/3 of the time while the second entry is selected 1/3 of the time.

I suspect that this is an attempt to do *something* with entries with weight=0, but yields unobvious results there: for {0, 1, 1}, the three entries are each selected 1/3 of the time.

I suggest:

- Ordering weight=0 entries to the end.
- Generating random numbers 0..(T-1).
- Using a "greater" test rather than "greater or equal".
- Selecting weight=0 entries in any order when all of the weight!=0 entries have been selected.
--VERIFIER NOTES--
The errata is not actionable. Issue should be raised with the DNSEXT WG.

RFC 2812, "Internet Relay Chat: Client Protocol", April 2000

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 3784
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Diman Todorov
Date Reported: 2013-11-05
Rejected by: Barry Leiba
Date Rejected: 2013-11-05

Section 2.5 says:

mask = *( nowild / noesc wildone / noesc wildmany )

It should say:

mask = *( nowild / (noesc wildone) / (noesc wildmany) )

Notes:

--VERIFIER NOTES--
The suggested change is not wrong, but neither is the existing text. In ABNF, concatenation
takes precedence over alternatives.

Errata ID: 3785
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Diman Todorov
Date Reported: 2013-11-05
Rejected by: Barry Leiba
Date Rejected: 2013-11-05

Section 2.3.1 says:

params = *14( SPACE middle ) [ SPACE ":" trailing ]
=/ 14( SPACE middle ) [ SPACE [ ":" ] trailing ]

It should say:

params = *13( SPACE middle ) [ SPACE ":" trailing ]
=/ 14( SPACE middle ) [ SPACE [ ":" ] trailing ]

Notes:

--VERIFIER NOTES--
The correction is not wrong, but the original text is not wrong either. They're functionally equivalent.

RFC 2817, "Upgrading to TLS Within HTTP/1.1", May 2000

Note: This RFC has been updated by RFC 7230, RFC 7231

Source of RFC: tls (sec)

Errata ID: 3941
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Florian Borchert
Date Reported: 2014-03-31
Rejected by: Stephen Farrell
Date Rejected: 2014-05-08

Section 3.1 says:

Note that HTTP/1.1 [1] specifies "the upgrade keyword MUST be
supplied within a Connection header field (section 14.10)

It should say:

The hyperlink (http://tools.ietf.org/html/rfc2817#section-14.10) 
to section 14.10 does not work, it should refer to RFC2616: 
http://tools.ietf.org/html/rfc2616#section-14.42

Notes:

The hyperlink is an IETF tooling artefact and not part of the RFC, which is clear.
--VERIFIER NOTES--
The hyperlink is an IETF tooling artefact and not part of the RFC, which is clear.

RFC 2819, "Remote Network Monitoring Management Information Base", May 2000

Source of RFC: rmonmib (ops)

Errata ID: 1400
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Mehala
Date Reported: 2008-03-31
Rejected by: Dan Romascanu
Date Rejected: 2010-05-10

Section 1 2 &3 says:

1. matrixDSSourceAddress
2. matrixDSDestAddress
3. hostAddress

It should say:

Definition of OBJECT-TYPE 1, 2 & 3

Notes:

Got error while compiling the MIB. Error says the above objects "must have size restriction".
--VERIFIER NOTES--
MIB documents before RFC 4001 may present this problem. It's a warning not a compilation error that should be ignored.

RFC 2827, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", May 2000

Note: This RFC has been updated by RFC 3704

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 372
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Craig A. Huegen
Date Reported: 2002-11-20
Rejected by: Sean Turner
Date Rejected: 2011-02-23

Section 9 says:

   [9]  Thanks to: Craig Huegen; See:
        http://www.quadrunner.com/~chuegen/smurf.txt.

It should say:

   [9]  Thanks to: Craig Huegen; See:
        http://www.pentics.net/denial-of-service/white-papers/smurf.html.

Notes:

Tried to preserve the old URL, but could not.
--VERIFIER NOTES--
According to the RFC editor:

The URL was correct at the time of publication, so we don't consider
this an erratum. That is, we don't believe errata should be used
to update things that were true at the time of publication. I think
using the errata in this way muddies the system.

Additionally, using Google search
on "Craig Huegen" returns a link to "Index of Craig Huegen's
Denial-of-Service papers and presentations", which seems sufficient.

RFC 2849, "The LDAP Data Interchange Format (LDIF) - Technical Specification", June 2000

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 4355
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Andrey Repin
Date Reported: 2015-05-05
Rejected by: Barry Leiba
Date Rejected: 2015-05-05

Throughout the document, when it says:

In the section "Formal Syntax Definition of LDIF", Notes 2 and 8 
indirectly imply, that folded lines may contain leading whitespaces(1) 
and not allowed trailing whitespaces(2).
Or, in other words, a fold must occur before a whitespace, or entire 
value must be base64-encoded before folding.
However, the understanding is implied, rather than clearly stated.

It should say:

I suggest to clarify the folding rules to include a reference to 
trailing whitespaces in this specific case.
Something as simple as "in case of folding a line containing 
whitespaces, the fold MUST NOT occur after a whitespace character" will 
go a long way towards clearing the confusion.
Or, in ABNF syntax,
folding-sequence = (SAFE-INIT-CHAR / ":" / "<") FILL SEP SPACE SAFE-CHAR
(That is, symbols ":" and "<" may safely appear at the end of a value 
string, given it is not the first character of attribute value...)

Notes:

The implication is drawn from the
(1): Note 2, "When joining folded lines, exactly one space character at the beginning of each continued line must be discarded." (Emphasis on "exactly one".)
(2): Note 8, "Values … that end with SPACE SHOULD be base-64 encoded.", implied premise of the format that each single line read from the file must be "basically correct", means, follow generic rule of (<empty line> / <comment> / <name:value pair> / <continuation line>) and the generic experience that trailing whitespaces are not apparently visible in text files without the use of special tools.
--VERIFIER NOTES--

Except that it's an incorrect implication. The space at the beginning of the continued line is discarded simply because it's the space that was added to fold the line, so it has to be removed when you unfold. There is no restriction on where the folding is done other than what Note 2 says (MUST NOT fold before the first character of the line, and SHOULD NOT fold in the middle of a multi-byte UTF-8 character).

In particular, a line can be folded in the middle of a FILL sequence, in the middle of a sequence of SPACE characters in a string, or in the middle of a sequence of SPACE characters in a comment line. It is perfectly valid to have SPACE characters both before and after the <SEP SPACE> sequence that folding adds.

RFC 2865, "Remote Authentication Dial In User Service (RADIUS)", June 2000

Note: This RFC has been updated by RFC 2868, RFC 3575, RFC 5080, RFC 6929, RFC 8044

Source of RFC: radius (ops)

Errata ID: 4077
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Axel Luttgens
Date Reported: 2014-08-10
Rejected by: Benoit Claise
Date Rejected: 2014-10-07

Section 3 says:

      Response Authenticator

         The value of the Authenticator field in Access-Accept, Access-
         Reject, and Access-Challenge packets is called the Response
         Authenticator, and contains a one-way MD5 hash calculated over
         a stream of octets consisting of: the RADIUS packet, beginning
         with the Code field, including the Identifier, the Length, the
         Request Authenticator field from the Access-Request packet, and
         the response Attributes, followed by the shared secret.  That
         is, ResponseAuth =
         MD5(Code+ID+Length+RequestAuth+Attributes+Secret) where +
         denotes concatenation.

It should say:

      Response Authenticator

         The value of the Authenticator field in Access-Accept, Access-
         Reject, and Access-Challenge packets is called the Response
         Authenticator, and contains a one-way MD5 hash calculated over
         a stream of octets consisting of: the response Code field, the
         Identifier, the response Length, the Request Authenticator, the
         response Attributes, and finally the shared secret. 
         That is, ResponseAuth =
         MD5(Code+ID+Length+RequestAuth+Attributes+Secret) where +
         denotes concatenation.

Notes:

This sentence fragment "[...] consisting of: the RADIUS packet, [...]" tends to imply one is considering either the Access-Request packet, or the reply packet being under construction.

But this is inconsistent with the idea of having the the MD5 hash calculated over both the Request Authenticator and the response Attributes...
--VERIFIER NOTES--
As discussed with the AAA doctors

RFC 2866, "RADIUS Accounting", June 2000

Note: This RFC has been updated by RFC 2867, RFC 5080, RFC 5997

Source of RFC: radius (ops)

Errata ID: 4487
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Nick Lowe
Date Reported: 2015-09-29
Rejected by: Benoit Claise
Date Rejected: 2015-10-05

Section 5.5 says:

Acct-Session-Id

   Description

      This attribute is a unique Accounting ID to make it easy to match
      start and stop records in a log file.  The start and stop records
      for a given session MUST have the same Acct-Session-Id.  An
      Accounting-Request packet MUST have an Acct-Session-Id.  An
      Access-Request packet MAY have an Acct-Session-Id; if it does,
      then the NAS MUST use the same Acct-Session-Id in the Accounting-
      Request packets for that session.

      The Acct-Session-Id SHOULD contain UTF-8 encoded 10646 [7]
      characters.

It should say:

Acct-Session-Id

   Description

      This attribute is a globally unique Accounting ID to make it easy
      to match start and stop records in a log file.  The start and stop
      records for a given session MUST have the same Acct-Session-Id.
      An Accounting-Request packet MUST have an Acct-Session-Id.
      An Access-Request packet MAY have an Acct-Session-Id; if it does,
      then the NAS MUST use the same Acct-Session-Id in the Accounting-
      Request packets for that session.

      The Acct-Session-Id SHOULD contain UTF-8 encoded 10646 [7]
      characters.

Notes:

A very common implementation fault in RADIUS clients that perform accounting is that Acct-Session-Ids are observed to be reused after a NAS is rebooted or are only unique only in the scope/context of a NAS.

The RFC does not explicitly state the scope of uniqueness and it must be clarified to state that Acct-Session-Ids are expected to be globally unique. I believe this to be the original, implicit intent of the author.

This is necessary because the ambiguity causes substantial implementation issues today.

See: http://freeradius.org/radiusd/man/rlm_acct_unique.txt

An ideal Acct-Session-Id would have the properties of a GUID/UUID.
--VERIFIER NOTES--
As summarized by Nick:


It looks like the Acct-Session-Id and Acct-Multi-Session-Id errata
both will and should be rejected on the grounds that they would
constitute technical changes based on the original intent of the RFC,
which we now know. That does make sense and would be a reasonable
course of action now that that's known.

I am pleased that I have engendered a discussion on what I believe to
be a pertinent issue here. Alan has commented that he feels another
RADIUS fixes RFC would be sensible. I agree with that course of
action.

Thanks for all your time here!

Regards,

Nick

Errata ID: 4488
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Nick Lowe
Date Reported: 2015-09-29
Rejected by: Benoit Claise
Date Rejected: 2015-10-05

Section 5.11 says:

Acct-Multi-Session-Id

   Description

      This attribute is a unique Accounting ID to make it easy to link
      together multiple related sessions in a log file.  Each session
      linked together would have a unique Acct-Session-Id but the same
      Acct-Multi-Session-Id.  It is strongly recommended that the Acct-
      Multi-Session-Id contain UTF-8 encoded 10646 [7] characters.

It should say:

Acct-Multi-Session-Id

   Description

      This attribute is a globally unique Accounting ID to make it easy
      to link together multiple related sessions in a log file.  Each
      session linked together would have a globally unique
      Acct-Session-Id but the same Acct-Multi-Session-Id.  It is
      strongly recommended that the Acct-Multi-Session-Id contain
      UTF-8 encoded 10646 [7] characters.

Notes:

The RFC does not explicitly state the scope of uniqueness and it must be clarified to state that Acct-Multi-Session-Ids are expected to be globally unique. I believe this to be the original, implicit intent of the author.

An ideal Acct-Multi-Session-Id would have the properties of a GUID/UUID.

See Errata 4487 for the same clarification on the Acct-Session-Id.
--VERIFIER NOTES--
As summarized with Nick:


It looks like the Acct-Session-Id and Acct-Multi-Session-Id errata
both will and should be rejected on the grounds that they would
constitute technical changes based on the original intent of the RFC,
which we now know. That does make sense and would be a reasonable
course of action now that that's known.

I am pleased that I have engendered a discussion on what I believe to
be a pertinent issue here. Alan has commented that he feels another
RADIUS fixes RFC would be sensible. I agree with that course of
action.

Thanks for all your time here!

Regards,

Nick

RFC 2910, "Internet Printing Protocol/1.1: Encoding and Transport", September 2000

Note: This RFC has been obsoleted by RFC 8010

Note: This RFC has been updated by RFC 3380, RFC 3381, RFC 3382, RFC 3510, RFC 3995, RFC 7472

Source of RFC: ipp (app)

Errata ID: 4101
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Sweet
Date Reported: 2014-09-05
Rejected by: Barry Leiba
Date Rejected: 2014-09-17

Section 5 says:

   The IPP/1.1 document defines a new scheme 'ipp' as the value of a URL
   that identifies either an IPP printer object or an IPP job object.
   The IPP attributes using the 'ipp' scheme are specified below.
   Because the HTTP layer does not support the 'ipp' scheme, a client
   MUST map 'ipp' URLs to 'http' URLs, and then follows the HTTP
   [RFC2616][RFC2617] rules for constructing a Request-Line and HTTP
   headers.  The mapping is simple because the 'ipp' scheme implies all
   of the same protocol semantics as that of the 'http' scheme
   [RFC2616], except that it represents a print service and the implicit
   (default) port number that clients use to connect to a server is port
   631.

   In the remainder of this section the term 'ipp-URL' means a URL whose
   scheme is 'ipp' and whose implicit (default) port is 631. The term
   'http-URL' means a URL whose scheme is 'http', and the term 'https-
   URL' means a URL whose scheme is 'https',

   A client and an IPP object (i.e. the server) MUST support the ipp-URL
   value in the following IPP attributes.
       job attributes:
           job-uri
           job-printer-uri
       printer attributes:
           printer-uri-supported
       operation attributes:
           job-uri
           printer-uri
   Each of the above attributes identifies a printer or job object. The
   ipp-URL is intended as the value of the attributes in this list, and
   for no other attributes. All of these attributes have a syntax type
   of 'uri', but there are attributes with a syntax type of 'uri' that
   do not use the 'ipp' scheme, e.g. 'job-more-info'.

   If a printer registers its URL with a directory service, the printer
   MUST register an ipp-URL.

   User interfaces are beyond the scope of this document. But if
   software exposes the ipp-URL values of any of the above five
   attributes to a human user, it is REQUIRED that the human see the
   ipp-URL as is.

   When a client sends a request, it MUST convert a target ipp-URL to a
   target http-URL for the HTTP layer according to the following rules:

      1. change the 'ipp' scheme to 'http'
      2. add an explicit port 631 if the URL does not contain an
         explicit port. Note: port 631 is the IANA assigned Well Known
         Port for the 'ipp' scheme.

   The client  MUST use the target http-URL in both the HTTP Request-
   Line and HTTP headers, as specified by HTTP [RFC2616] [RFC2617] .
   However, the client MUST use the target ipp-URL for the value of the
   "printer-uri" or "job-uri" operation attribute within the
   application/ipp body of the request. The server MUST use the ipp-URL
   for the value of the "printer-uri", "job-uri" or "printer-uri-
   supported" attributes within the application/ipp body of the
   response.

   For example, when an IPP client sends a request directly (i.e. no
   proxy) to an ipp-URL "ipp://myhost.com/myprinter/myqueue", it opens a
   TCP connection to port 631 (the ipp implicit port) on the host
   "myhost.com" and sends the following data:

    POST /myprinter/myqueue HTTP/1.1
    Host: myhost.com:631
    Content-type: application/ipp
    Transfer-Encoding: chunked
    ...
    "printer-uri" "ipp://myhost.com/myprinter/myqueue"
              (encoded in application/ipp message body)
    ...

   As another example, when an IPP client sends the same request as
   above via a proxy "myproxy.com", it opens a TCP connection to the
   proxy port 8080 on the proxy host "myproxy.com" and sends the
   following data:

    POST http://myhost.com:631/myprinter/myqueue   HTTP/1.1
    Host: myhost.com:631
    Content-type: application/ipp
    Transfer-Encoding: chunked
    ...
    "printer-uri" "ipp://myhost.com/myprinter/myqueue"
              (encoded in application/ipp message body)
    ...

   The proxy then connects to the IPP origin server with headers that
   are the same as the "no-proxy" example above.

It should say:

    The IPP URL scheme is defined in [RFC3510].

   A client and an IPP object (i.e. the server) MUST support the ipp-URL
   value in the following IPP attributes.
       job attributes:
           job-uri
           job-printer-uri
       printer attributes:
           printer-uri-supported
       operation attributes:
           job-uri
           printer-uri
   Each of the above attributes identifies a printer or job object. The
   ipp-URL is intended as the value of the attributes in this list, and
   for no other attributes. All of these attributes have a syntax type
   of 'uri', but there are attributes with a syntax type of 'uri' that
   do not use the 'ipp' scheme, e.g. 'job-more-info'.

   If a printer registers its URL with a directory service, the printer
   MUST register an ipp-URL.

   User interfaces are beyond the scope of this document. But if
   software exposes the ipp-URL values of any of the above five
   attributes to a human user, it is REQUIRED that the human see the
   ipp-URL as is.

Notes:

Change inline text to a reference to the document that actually defines and registers it.
--VERIFIER NOTES--
While this consolidation and reference to RFC 3510 makes sense, RFC 3510 was published two and a half years *after* RFC 2910... so this dos not represent an error in RFC 2910. Any update to RFC 2910 will clearly refer to RFC 3510 for this information.

RFC 2919, "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists", March 2001

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 361
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Trish Lynch
Date Reported: 2002-08-08
Rejected by: Alexey Melnikov
Date Rejected: 2010-05-11

Section 3 says:

The syntax of the List-Id header follows:

   list-id-header = "List-ID:" [phrase] "<" list-id ">" CRLF

It should say:

The syntax of the List-Id header follows:

   list-id-header = "List-Id:" [phrase] "<" list-id ">" CRLF

Notes:

In order to bring it in line with the examples, and with common usage (by
the RFC, the List-ID is correct) most mail readers use the example and
do not consider the LHS case insensitive, since the RFC says:

The list header fields are subject to the encoding and character restrictions for mail headers as described in [RFC822].

RFC822, while it says that most headers are character insensitive, does
not mandate that, and RFC 2919 only mandates that the List-Id: header is
subject to *encoding* and *character restrictions*, and does not say it
needs to adhere to case insensitivity.

Therefore, the proposed change above will bring things more in line with common
usage.
--VERIFIER NOTES--
Header field names are case insensitive per use of string literals from RFC 2234.

RFC 2960, "Stream Control Transmission Protocol", October 2000

Note: This RFC has been obsoleted by RFC 4960

Note: This RFC has been updated by RFC 3309

Source of RFC: sigtran (rai)

Errata ID: 3317
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sergey Antipov
Date Reported: 2012-08-14
Rejected by: Brian Haberman
Date Rejected: 2012-08-14

Section 6.3.1 says:

       RTTVAR <- (1 - RTO.Beta) * RTTVAR + RTO.Beta * |SRTT - R'| SRTT
       <- (1 - RTO.Alpha) * SRTT + RTO.Alpha * R'

It should say:

       RTTVAR <- (1 - RTO.Beta) * RTTVAR + RTO.Beta * |SRTT - R'|, and
       SRTT <- (1 - RTO.Alpha) * SRTT + RTO.Alpha * R'

Notes:

Currently, it looks like the second equation is part of the first one.
--VERIFIER NOTES--
RFC 2960 is obsolete. It has been replaced by RFC 4960.

RFC 2981, "Event MIB", October 2000

Source of RFC: disman (ops)

Errata ID: 3798
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: shuaixiaojuan
Date Reported: 2013-11-13
Rejected by: Benoit Claise
Date Rejected: 2013-12-09

Section 7 says:

mteTriggerSampleType's description:
If only 'existence' is set in mteTriggerTest this object has
no meaning."

It should say:

If no 'boolean' is set in mteTriggerTest this object has
no meaning."

Notes:

mteTriggerThresholdDeltaRising was added to mteTriggerThresholdTable from the version draft-ietf-disman-event-mib-09.txt and mteTriggerThresholdTable can both deal 'absoluteValue' and 'deltaValue', so mteTriggerSampleType has mean for 'boolean' only. (mteTriggerSampleType has no changed from draft-ietf-disman-event-mib-06.txt)

was added to
--VERIFIER NOTES--
As justified by the DISMAN WG co-chair on the DISMAN mailing list (note: WG now closed), the RFC text is correct.

RFC 2985, "PKCS #9: Selected Object Classes and Attribute Types Version 2.0", November 2000

Source of RFC: Legacy
Area Assignment: sec

Errata ID: 7813
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Florian Weber
Date Reported: 2024-02-18
Rejected by: Paul Wouters
Date Rejected: 2024-02-22

Section 5.2.6 says:

  5.2.6 Gender

   The gender attribute specifies the gender of the subject it is
   associated with.

   gender ATTRIBUTE ::= {
           WITH SYNTAX PrintableString (SIZE(1) ^
                       FROM ("M" | "F" | "m" | "f"))
           EQUALITY MATCHING RULE caseIgnoreMatch
           SINGLE VALUE TRUE
           ID pkcs-9-at-gender
   }

   The letter "M" (or "m") represents "male" and the letter "F" (or "f")
   represents "female".  gender attributes must be single-valued.

It should say:

  5.2.6 Gender

   The gender attribute specifies the gender of the subject it is
   associated with.

   gender ATTRIBUTE ::= {
           WITH SYNTAX IA5String (SIZE(1..pkcs-9-ub-gender))
           EQUALITY MATCHING RULE caseIgnoreMatch
           ID pkcs-9-at-gender
   }

   Attributes of this type need not be single-valued.

Notes:

The original specification restricts the gender attribute to be single-valued. The suggested correction removes the requirement for the attribute to be single-valued, allowing for greater flexibility in representing gender attributes. The suggested correction aligns with the evolving understanding and recognition of gender diversity. By updating the syntax and removing the single value requirement, the revised attribute definition can better accommodate a broader range of gender identities, ensuring inclusivity and accuracy in representing the gender of a subject. This change would introduce a new upper bound pkcs-9-ub-gender with a bound of type INTEGER ::= pkcs-9-ub-pkcs9String. If this correction is to be applied, the RFC should change or remove existing references to the incorrect gender attribute specification throughout the RFC.
--VERIFIER NOTES--
Paul Wouters(AD): While we applaud your intent for improved inclusivity, this modification cannot be done via an errata. We don't have versions of RFCs, so if we were to make a functional change than someone stating they comply to this RFC, you would not know if that includes this new feature or not. The proper way to make this change is to suggest a bis version of this RFC that would obsolete this RFC with the proposed changes. Feel free to reach out to one of the Security Area Directors if you need help on how to start this process.

RFC 3031, "Multiprotocol Label Switching Architecture", January 2001

Note: This RFC has been updated by RFC 6178, RFC 6790

Source of RFC: mpls (rtg)

Errata ID: 3689
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Renato Westphal
Date Reported: 2013-07-28
Rejected by: Adrian Farrel
Date Rejected: 2013-09-27

Section 5.2.1 says:

      6. <PulledUnconditional, RequestWhenNeeded, N/A, ReleaseOnChange,
         UseImmediate>

         This is downstream-on-demand label distribution with
         independent control and conservative label retention mode,
         without loop detection.

      7. <PulledUnconditional, RequestWhenNeeded, N/A, ReleaseOnChange,
         UseIfLoopNotDetected>

It should say:

      6. <PulledUnconditional, RequestWhenNeeded, RequestRetry,
         ReleaseOnChange, UseImmediate>

         This is downstream-on-demand label distribution with
         independent control and conservative label retention mode,
         without loop detection.

      7. <PulledUnconditional, RequestWhenNeeded, RequestRetry,
         ReleaseOnChange, UseIfLoopNotDetected>

Notes:

If the "Request Procedure" is different than "Request Never", then a "NotAvailable Procedure" should be specified. In this case, the "Request Retry" procedure is the right option for Downstream on Demand.

[Note that the reported original text has been updated to reflect the actual text in the RFC]
--VERIFIER NOTES--
This report is rejected for a number of reasons.

The first point to note is that the text in section 5.2 is intended to show how the different label distribution schemes will interoperate. It is not intended to cover every wrinkle or be a normative. In that light, the downstream-on-demand operations can be considered to be consistent with a converged IGP in which case the failure to return a LabelMapping would simply not arise or would represent a marginal error that should not be blindly retried.

Consider for example that the routing tables on the two routers are not in agreement. Can the upstream router know which one is out of synch?

Consider that the downstream router has run out of labels (maybe not realistic these days, but it was a concern once upon a time). Would retrying the request help?

The second point to note is that if this text *is* considered to be normative (i.e., an absolute definition of how downstream-on-demand operates) then any change is also normative. Since the current text is what the authors and WG intended to write, a change to this text would be a change of substance and needs more than just an errata report (for example, an Internet-Draft).

Errata ID: 4331
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Robert Shearman
Date Reported: 2015-04-09
Rejected by: Alia Atlas
Date Rejected: 2015-04-09

Section 3.22 says:

When a labeled packet is traveling along an LSP, it may occasionally
happen that it reaches an LSR at which the ILM does not map the
packet's incoming label into an NHLFE, even though the incoming label
is itself valid.  This can happen due to transient conditions, or due
to an error at the LSR which should be the packet's next hop.

It should say:

When a labeled packet is traveling along an LSP, it may occasionally
happen that it reaches an LSR at which the ILM does not map the
packet's incoming label into an NHLFE, even though the incoming label
is itself valid and it has a usable L3 next hop.  This can happen due
to transient conditions, or due to an error at the LSR which should
be the packet's next hop.

Notes:

Although the reporter is concerned about ambiguity in terms of why the ILM doesn't map a valid label into an NHLFE, the reason that might happen is really irrelevant. The original statement clearly specifies that it could be an error or transient condition.

The correct action of discarding a packet where the label doesn't map into a n NHLFE applies regardless of whether or not there is a usable L3 next hop.
This proposed errata would thus add incorrect ambiguity for no purpose.

================================================

There is ambiguity as to the cause of the "ILM [not mapping] the packet's incoming label into an NHLFE". It could be read in a number of ways, of which only one can be correct:

1. The label is valid in terms of syntax (e.g. not Implicit NULL), but no binding has been installed because the label hasn't been advertised. Clearly, 3.18 covers this case already, and is inconsistent with the section title of "Lack of Outgoing Label" so this interpretation is unlikely to have been intended.

2. The label is valid and is expected to be used for forwarding, but an NHLFE entry is missing or not usable because the interface the next hop is reachable over has gone down, or for some other reason isn't usable. This interpretation is ruled out by the statement that "it is tempting in such cases to strip off the label stack and attempt to forward the packet further via conventional forwarding", which wouldn't be possible if the interface was down.

3. A resource allocation error occurred meaning that the ILM binding was allocated, but the NHLFE entry couldn't be allocated. There is no mention of resource issues in this or related sections so again this interpretation seems unlikely.

4. The label is valid and is expected to be used for forwarding, but the LSR has received no label binding from the LSP's next hop even though it has a usable L3 next hop (i.e. it lacks an outgoing label). It cannot map to an NHLFE entry because the actions in section 3.10 don't include popping and forwarding as unlabeled. This is therefore the interpretation that best fits.

To clarify that interpretation 4 is the one intended, the phrase "and it has a usable L3 next hop" is inserted into the text, using the definition of L3 next hop from section 3.17.
--VERIFIER NOTES--
Although the reporter is concerned about ambiguity in terms of why the ILM doesn't map a valid label into an NHLFE, the reason that might happen is really irrelevant. The original statement clearly specifies that it could be an error or transient condition.

The correct action of discarding a packet where the label doesn't map into a n NHLFE applies regardless of whether or not there is a usable L3 next hop.
This proposed errata would thus add incorrect ambiguity for no purpose.

Errata ID: 5643
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Smith
Date Reported: 2019-02-25
Rejected by: Deborah Brungard
Date Rejected: 2019-05-30

Section Terminology says:

<missing>

It should say:

label edge router - a router capable of accepting an unlabelled packet,
and through MPLS processing, may MPLS encapsulate the packet by adding
 a label stack. 

Notes:

I am doing some MPLS review.

The book I'm using said an LER was an (RFC3031) MPLS edge node. I believed it was any router that could take unlabelled packets and label them, regardless of where the router was within the MPLS domain. (In other words, an MPLS router was not an LER if it would not MPLS label unlabelled packets and forward them.)

I decided to check RFC3031 for a definition, and discovered there isn't a definition at all for "label edge router", or a match on any text that matches "label edge" or "LER".

RFC6178 clarifies LER processing of IPv4 packets, and the general description of processing matches my understanding of what an LER is.

However, it doesn't formally define an "label edge router" either, and I think an update to RFC3031 should be where "label edge router" is formally defined.
--VERIFIER NOTES--
This is not an error with RFC3031. It is inappropriate to use an Errata Report to add a new term to an RFC.

Errata ID: 3171
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2012-04-01
Rejected by: Adrian Farrel
Date Rejected: 2012-04-03

Section 3.20 says:

   Given a set of FECs which are "aggregatable" into a single FEC, it is
   possible to (a) aggregate them into a single FEC, (b) aggregate them
   into a set of FECs, or (c) not aggregate them at all.  Thus we can
   speak of the "granularity" of aggregation, with (a) being the
   "coarsest granularity", and (c) being the "finest granularity".

It should say:

   Given a set of FECs which are "aggregatable" into a single FEC, it is
   possible to (a) aggregate them into a single FEC, (b) aggregate them
   into a set of FECs, or (c) not aggregate them at all.  Thus we can
   speak of the "granularity" of aggregation, with (a) being the
   "coarsest granularity", and (b) being the "finest granularity".

Notes:

In the case of (c) the aggregation is not used, so there is no granularity.
--VERIFIER NOTES--
Not aggregating is a degenerate case of aggregation where a one-to-one aggregation mapping is used. Thus, the result is the "finest granularity".

RFC 3036, "LDP Specification", January 2001

Note: This RFC has been obsoleted by RFC 5036

Source of RFC: mpls (rtg)

Errata ID: 345

Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Barbara Denny
Date Reported: 2006-04-13
Rejected by: Adrian Farrel
Date Rejected: 2009-08-24
Report Text:

A reference for [Dobb] is missing.

Rationale:
In section 2.9.1, there is a mention of a problem
with MD5. The text refers to [Dobb] but the
reference section contains no citation.

 --VERIFIER NOTES-- 
RFC3036 has been obsoleted by RFC5036.
The text that gives rise to this issue is a direct quote from RFC 2385. That reference should be explored to determine the full implications of the text.

---

Errata ID: 1837

Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Barbara Denny
Date Reported: 2006-04-13
Rejected by: Adrian Farrel
Date Rejected: 2009-08-24
Report Text:

A reference for [Dobb] is missing.

Rationale:
In section 2.9.1, there is a mention of a problem
with MD5. The text refers to [Dobb] but the
reference section contains no citation.

 --VERIFIER NOTES-- 
RFC 3036 has been obsoleted by RFC 5036.

The text at issue is a quote from another RFC. That RFC can be inspected to find the full context.

---

RFC 3041, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", January 2001

Note: This RFC has been obsoleted by RFC 4941

Source of RFC: ipngwg (int)

Errata ID: 2747
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Johannes Endres
Date Reported: 2011-03-11
Rejected by: RFC Editor
Date Rejected: 2011-03-27

Section header says:

It should say:

Obsoleted by: 4941

Notes:

The "Obsoleted by" note is missing from the header, so by itself the RFC seems not to be obsolete.

--RATIONALE--
Generally, the text versions of RFCs do not include post-publication metadata (such as "Obsoleted by" or "Updated by") because this data was not available upon publication, and RFCs do not change after publication.

Post-publication metadata is available in these primary locations:
- RFC search results (http://www.rfc-editor.org/rfcsearch.html)
- RFC info pages
- RFC index (http://www.rfc-editor.org/rfc-index.html)

For this specific RFC, this information is available on all of them:
- RFC search result
- RFC info page (http://www.rfc-editor.org/info/rfc3041)
- RFC index

In addition there are HTML versions of RFCs available via tools.ietf.org; they are not maintained by the RFC Editor. They include an added header in a gray box, which shows post-publication metadata. In this case, the HTML version of RFC 3041 includes the data.

RFC 3065, "Autonomous System Confederations for BGP", February 2001

Note: This RFC has been obsoleted by RFC 5065

Source of RFC: idr (rtg)

Errata ID: 338
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2006-01-25
Rejected by: Stewart Bryant
Date Rejected: 2012-02-14

Appendix A says:

   The most notable change from [1] is that of reversing the values
   AS_CONFED_SEQUENCE(4) and AS_CONFED_SET(3) to those defined in
   section "AS_CONFED Segment Type Extension".  The reasoning for this
   is that in the initial implementation, which was already widely
   deployed, they were implemented backwards from [4], and as such,
   subsequent implementations implemented them backwards as well.  In
   order to foster interoperability and compliance with deployed
   implementations, they've therefore been changed here as well. 

It should say:

    The most notable change from [5] is that of reversing the values
    AS_CONFED_SEQUENCE(4) and AS_CONFED_SET(3) to those defined in
    section "AS_CONFED Segment Type Extension".  The reasoning foridely
    deployed, they were implemented backwards from [4], and as such,
    subsequent implementations implemented them backwards as well.  In
    order to foster interoperability and compliance with deployed
    implementations, they've therefore been changed here as well.

Notes:

There is an error in line 1 of Appendix A (RFC 3065). reference
to document [1] is wrong and must be changed to [5].

--VERIFIER NOTES--
Nikolai Malykh made an error in the submission of this erratum which was corrected in erratum 339.

RFC 3101, "The OSPF Not-So-Stubby Area (NSSA) Option", January 2003

Source of RFC: ospf (rtg)

Errata ID: 4767
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Chao Fu
Date Reported: 2016-08-08
Rejected by: Alia Atlas
Date Rejected: 2016-08-08

Section 2.5.(6).(e) says:

          (e) If the current LSA is functionally the same as an
              installed LSA (i.e., same destination, cost and non-zero
              forwarding address) then apply the following priorities in
              deciding which LSA is preferred:

                 1. A Type-7 LSA with the P-bit set.

                 2. A Type-5 LSA.

                 3. The LSA with the higher router ID.

              [NSSA]

It should say:

NULL (it should be deleted because no LSAs would be compared here.)

Notes:

If one LSA is Type-5 and the other is Type-7, one of them would be rejected at step (2.5.(3) ( please refer to OSPF mail list: https://mailarchive.ietf.org/arch/msg/ospf/KBoh5T75o-s7n_bL1knrc6uVlTs ). If both of them are Type-7 LSAs, one of them would be flushed according 2.4:
If two NSSA routers, both
reachable from one another over the NSSA, originate functionally
equivalent Type-7 LSAs (i.e., same destination, cost and non-zero
forwarding address), then the router having the least preferred LSA
should flush its LSA.

As a result, rule (e) would never be applied and should be removed.

--VERIFIER NOTES--
It is easy to envision a topology where an ABR for an NSSA receives an NSSA-LSA from an NSSA internal router and an AS-Exernal-LSA from originating routers that do not receive each others equivalent LSAs. Furthermore, even if this were not the case, the referenced text refers to LSAs that are both NSSA-LSAs as opposed to a
mixture of an NSSA-LSA and an AS-External-LSA.

RFC 3107, "Carrying Label Information in BGP-4", May 2001

Note: This RFC has been obsoleted by RFC 8277

Note: This RFC has been updated by RFC 6790

Source of RFC: mpls (rtg)

Errata ID: 2319
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruno Decraene
Date Reported: 2010-07-07
Rejected by: Adrian Farrel
Date Rejected: 2010-08-20

Section 5 says:

"A BGP speaker should not advertise this capability to another BGP speaker unless there is a Label Switched Path (LSP) between the two speakers."

It should say:

"An eBGP speaker should not advertise this capability to another eBGP speaker unless there is a Label Switched Path (LSP) or layer two interface between the two speakers."

Or just remove completely that sentence.

Notes:

1) :s/BGP/eBGP
An iBGP router should be able to set up an internal BGP session for AFI 1 / SAFI 4 toward a Route Reflector even if the Route Reflector is not capabble of forwarding MPLS packets (This case is even described in the section 2 of the RFC)

2) + layer two interface
If both router are connected by a direct (sub)interface, they should be able to exchange MPLS packets even if there is no LSP between them.

3) Remove the sentence
AFAIK, the point is now better addressed by draft-ietf-idr-bgp-bestpath-selection-criteria-01.txt
--VERIFIER NOTES--
After discussions with the document author on the MPLS mailing list:

- The EBGP/IBGP distinction is not relevant here, as this does not properly
capture the notion of whether a BGP speaker is in the data path.

- The ability to send an MPLS packet from one router to another does not
necessarily depend on there being either a sequence of MPLS routers
between them or on there being an L2 connection between them. There might
be an L3 tunnel, for example.

Furthermore, we feel that no confusion has arisen as the result of the current text so that there is no harm in leaving it as it stands.

Errata ID: 4499
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexander Okonnikov
Date Reported: 2015-10-13
Rejected by: Deborah Brungard
Date Rejected: 2016-02-11

Section 3 says:

   A BGP speaker can withdraw a previously advertised route (as well as
   the binding between this route and a label) by either (a) advertising
   a new route (and a label) with the same NLRI as the previously
   advertised route, or (b) listing the NLRI of the previously
   advertised route in the Withdrawn Routes field of an Update message.
   The label information carried (as part of NLRI) in the Withdrawn
   Routes field should be set to 0x800000.  (Of course, terminating the
   BGP session also withdraws all the previously advertised routes.)

It should say:

   A BGP speaker can withdraw a previously advertised route (as well as
   the binding between this route and a label) by either (a) advertising
   a new route (and a label) with the same NLRI as the previously
   advertised route, or (b) listing the NLRI of the previously
   advertised route in the Withdrawn Routes field of
   an MR_UNREACH_NLRI attribute of an Update message.
   The label information carried (as part of NLRI) in the Withdrawn
   Routes field should be set to 0x000001.  (Of course, terminating the
   BGP session also withdraws all the previously advertised routes.)

Notes:

1. Labeled routes are withdrawn by virtue of MR_UNREACH_NLRI attribute.
2. Label value should be set to 0x00000 with BoS=1. Value 0x800000 was carried from draft, where BoS was high-order bit.
--VERIFIER NOTES--
Rejected as potential to cause interoperability issues.

Errata ID: 4500
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexander Okonnikov
Date Reported: 2015-10-13
Rejected by: Deborah Brungard
Date Rejected: 2016-02-11

Section 5 says:

   A BGP speaker that is capable of handling multiple routes to a
   destination (as described above) should use the Capabilities Optional
   Parameter, as defined in [BGP-CAP], to inform its peers about this
   capability.  The value of this capability is 4.

It should say:

   A BGP speaker that is capable of handling multiple routes to a
   destination (as described above) should use the Capabilities Optional
   Parameter, as defined in [BGP-CAP], to inform its peers about this
   capability.  This capability is advertised using the Capability Code
   4 and Capability Length 0.

Notes:

To remove confusion what word value means - Capability Value or value of Capability Code.
Also, format of multiple routes capability is not described, so length = 0 is assumed.
--VERIFIER NOTES--

RFC 3156, "MIME Security with OpenPGP", August 2001

Source of RFC: openpgp (sec)

Errata ID: 3443
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kwadronaut
Date Reported: 2013-01-03
Rejected by: Sean Turner
Date Rejected: 2013-01-04

Section 4. says:

   Example message:

      From: Michael Elkins <elkins@aero.org>
      To: Michael Elkins <elkins@aero.org>
      Mime-Version: 1.0

It should say:

   Example message:

      From: Michael Elkins <elkins@aero.org>
      To: Michael Elkins <elkins@aero.org>
      MIME-Version: 1.0

Notes:

According to RFC2045 (on which this RFC builds upon) specifies that:
Messages composed in accordance with this document MUST include such a header field, with the following verbatim text:

MIME-Version: 1.0
--VERIFIER NOTES--
Despite the quote from 2045 above, the grammar that's in effect is such that header field names are case-insensitive, so "MIME-Version", "Mime-Version", and "mime-version" are all the same.

RFC 3161, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", August 2001

Note: This RFC has been updated by RFC 5816

Source of RFC: pkix (sec)

Errata ID: 4042
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Kyle Hamilton
Date Reported: 2014-07-05
Rejected by: Stephen Farrell
Date Rejected: 2015-05-12

Section 2.1 says:

   8.    not to examine the imprint being time-stamped in any way (other
         than to check its length, as specified in the previous bullet).

   9.    not to include any identification of the requesting entity in
         the time-stamp tokens.

   10.   to sign each time-stamp token using a key generated exclusively
         for this purpose and have this property of the key indicated on
         the corresponding certificate.

   11.   to include additional information in the time-stamp token, if
         asked by the requester using the extensions field, only for the
         extensions that are supported by the TSA.  If this is not
         possible, the TSA SHALL respond with an error message.

It should say:

   8.    not to examine the imprint being time-stamped in any way (other
         than to check its length, as specified in the previous bullet).

   9.    to sign each time-stamp token using a key generated exclusively
         for this purpose and have this property of the key indicated on
         the corresponding certificate.

   10.   to include additional information in the time-stamp token, if
         asked by the requester using the extensions field, only for the
         extensions that are supported by the TSA.  If this is not
         possible, the TSA SHALL respond with an error message.

Notes:

There exists at least one legal mandate in at least one jurisdiction that contravenes strict compliance with RFC3161. It is easier to work to change IETF non-binding standards than it is to change legal mandates.

The State of Nevada regulates Time Stamps, under Nevada Administrative Code chapter 720 section 160. It requires that Time Stamps, to be recognized by its courts, must contain the identification of the requesting entity (the "identity of the person appending or attaching the notation") in the time-stamp tokens.

The Administrative Code may be found at this URL: http://www.leg.state.nv.us/NAC/NAC-720.html#NAC720Sec160 I have also quoted the relevant section below. (The parenthetical reference to NRS 720.150 is a reference to Nevada Revised Statutes, the statutory authority for the administrative code section.)

NAC 720.160 "Time stamp" defined. (NRS 720.150) "Time stamp" means:
1. A notation that:
(a) Is digitally signed by a certification authority;
(b) Is appended or attached to a message, digital signature or certificate; and
(c) Indicates at least:
(1) The date and time the notation was appended or attached; and
(2) The identity of the person appending or attaching the notation; or
2. To append or attach such a notation to a message, digital signature or certificate.
(Added to NAC by Sec'y of State by R155-98, eff. 12-2-99)

Please note that the requirement of NAC 720.160.1(c)(2) went into effect in December 1999, more than 18 months before RFC3161 was published in August 2001. The attempt by a non-legislative body (IETF pkix-wg) to contravene the will of a legislative body was either abject ignorance or utter hubris.

A TimeStampToken extension would be able to contain the mandatory data. However, such an extension would necessarily violate current RFC3161 section 2.1.9.

The reason for this change is actually technical (from a legal sense), though it may appear to be editorial in nature. As digests grow older, they necessarily have a much longer time that they have subject to the Birthday Attack. As of the date of this errata submission, SHA-1 is disallowed by the Computer Security Resource Center of US National Institute of Science and Technology (NIST) for new digital signature generation, due to potential weakening due to increased temporal attack surface.

This means that sooner or later, an older timestamp is going to be found that matches the digest of a newer document. The goal is to ensure that the document in question was actually in the possession of the particularly-named person identified as having attached the timestamp, by making that person available for testimony in the event of a dispute. If there are multiple timestamps available using different digest algorithms that all have the same time (within a few seconds of each other), that raises the probability that the document did in fact exist at that time. However, because new digest algorithms are introduced over time, it is not feasible to expect that all provided timestamps for a given document will necessarily be at the same time -- as long as all the digests that existed at the time the timestamps were generated have their times match, and the timestamps with new digests were not created before the new digests were implemented, it's the best evidence available that the timestamped data existed at the latest of the times of the timestamps from digests that existed simultaneously. (Be VERY careful about accepting timestamps that are more than thirty seconds apart from algorithms that existed simultaneously, and only in the murkiest situations should any set of timestamps using algorithms that existed simultaneously ever be accepted that are stamped as being more than two minutes apart.)

RFC3161 Section 2.4.1 defines a TimeStampReq format which does not provide the actual datum to be timestamped. Any attempt at a protocol which does make the Certification Authority be the one attaching the timestamp to the datum would have to provide the datum to the custody of the Certification Authority, which would exceed the scope of the protocol defined by RFC3161. Thus, a true RFC3161-compliant implementation would have to use nonstandard extensions to either the submission protocol (leaving the datum in the care of the Time Stamp Server) or the TimeStampReq and TimeStampToken contents (containing the datum in, presumably, an extension containing an ASN.1 OCTET STRING), in order to comply with this legal mandate in such a way that the identity of the person requesting the imprint (and thus presumed to hold the datum in the first place) does not need to be included within the TimeStampToken. Unfortunately, this would also necessitate a violation of RFC3161 section 2.1.8, to prevent false statements from being signed in a jurisdiction where digital signatures have the force of acknowledgments before notaries public.

The erratum submitter respectfully requests that a Time Stamp working group be reconvened for an update to the protocol to address this and other errata which are currently held for update.
--VERIFIER NOTES--

This is not an erratum but a change request. Please send to the pkix list if
it's still useful.

RFC 3162, "RADIUS and IPv6", August 2001

Note: This RFC has been updated by RFC 8044

Source of RFC: Legacy
Area Assignment: ops

Errata ID: 1923
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alan DeKok
Date Reported: 2009-10-22
Rejected by: Dan Romascanu
Date Rejected: 2010-11-02

Section 2.1 says:

   Address

      The Address field is 16 octets.

It should say:

String

  The field is 16 octets

Notes:

As Glen notes in:

http://ops.ietf.org/lists/radiusext/2009/msg00540.html

Using "ipv6 address" for a data type in RADIUS is wrong.

RFC 3162 (among others Glen wrote) contradict his current position. Those documents use data types for the "value" field of RADIUS attributes that have not been defined in RFC 2865. As such, they should either:

a) make it clear that they define a new data type, and be marked as "Updates: 2865"

or

b) use the data types in RFC 2865.

Or even better, maintain an internally consistent set of beliefs, and leave RFC 3162 alone.
--VERIFIER NOTES--
The common terminology is known by RADIUS implementers. Every RADIUS implementor "knows what this means". i.e. "Address" in RFC 2865 means "ipaddr", and "Address" in RFC 3162 means "ipv6addr". A change now would create further confusion.

RFC 3168, "The Addition of Explicit Congestion Notification (ECN) to IP", September 2001

Note: This RFC has been updated by RFC 4301, RFC 6040, RFC 8311

Source of RFC: tsvwg (wit)

Errata ID: 3680
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Mirja Kühlewind
Date Reported: 2013-07-12
Rejected by: Martin Stiemerling
Date Rejected: 2015-04-17

Section 6.1.1. says:

If the TCP connection does not
wish to use ECN notification for a particular packet, the sending TCP
sets the ECN codepoint to not-ECT, and the TCP receiver ignores the
CE codepoint in the received packet.

It should say:

If the TCP connection does not
wish to use ECN notification for a particular packet, the sending TCP
sets the ECN codepoint to not-ECT.

Notes:

The receiver should not ignore any CE codepoint.
--VERIFIER NOTES--
This is not an editorial fix or technical clarification, but proposes to change the processing of ECN. Please go ahead and write a draft that works towards updating RFC 3168.

Errata ID: 6494
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Joe Touch
Date Reported: 2021-03-24
Rejected by: Martin Duke
Date Rejected: 2021-03-24

Section Header says:

Updates: 2474, 2401, 793 

It should say:

Updates: 2474, 2401, 793, 791

Notes:

This is the first standards-track RFC to assign the two unused bits of the IP TOS byte to ECN. Granted it was suggested in RFC2481, but that was experimental and unable to update RFC791 because it would create a downref.
--VERIFIER NOTES--
As several have pointed out on the list, 2474 itself updates 791, so someone following 791 through the tree of its updates will consider 3168.

Errata ID: 3636
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mirja Kühlewind
Date Reported: 2013-06-04
Rejected by: Martin Stiemerling
Date Rejected: 2013-07-11

Section 6.1.1. says:

If the TCP connection does not
   wish to use ECN notification for a particular packet, the sending TCP
   sets the ECN codepoint to not-ECT, and the TCP receiver ignores the
   CE codepoint in the received packet.

It should say:

If the TCP connection does not
   wish to use ECN notification for a particular packet, the sending TCP
   sets the ECN codepoint to not-ECT.

Notes:

CE should not be set on not-ECT capable packets. If this happens anyway, the CE codepoint would overwrite the ECT codepoint. Thus there is no way for the receiver to know it should ignore the CE codepoint; the sentence is therefore nonsensical.
--VERIFIER NOTES--
See discussions in the tsvwg (http://www.ietf.org/mail-archive/web/tsvwg/current/msg11989.html)

Errata ID: 4997
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: C. M. Heard
Date Reported: 2017-04-17
Rejected by: Martin Duke
Date Rejected: 2020-04-20

Section Header says:

Updates: 2474, 2401, 793

It should say:

Updates: 2474, 2460, 2401, 793

Notes:

RFC 3168 updates RFC 2460 but does not indicate this in its header block.

Specifically, Section 5.3 of RFC 3168 requires that the ECN field of a reassembled IPv6 datagram be calculated from the ECN fields of all of the fragments, rather than simply copying it from the initial fragment as specified in RFC 2460.

There are other missing Updates: fields; see e.g. Erratum 2660.
--VERIFIER NOTES--
This is a borderline case, as RFC 2474 already changes the semantics of this field and is correctly listed in the Updates field. Anyway, this would be "Hold for Document Update", but RFC 2460 has already been updated with RFC 8200.

RFC 3205, "On the use of HTTP as a Substrate", February 2002

Note: This RFC has been obsoleted by RFC 9205

Source of RFC: Legacy

Errata ID: 4299
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Anthony Yu
Date Reported: 2015-03-12
Rejected by: Barry Leiba
Date Rejected: 2015-03-12

Section 2.3 says:

This further requires that each
client know the secret to be used with each server, but it does not
provide any means of securely transmitting such secrets between the
parties.

It should say:

This further requires that each
client knows the secret to be used with each server, but it does not
provide any means of securely transmitting such secrets between the
parties.

Notes:

Grammatical mistake: each client knowS
--VERIFIER NOTES--
Actually, it is not a grammatical error, but is grammatically correct. It's using the subjunctive mood, which is appropriate with "requires" (and other verbs, such as "insists", "hopes", and so on). Subjunctive mood is fading in English, with a few notable exceptions ("So be it," "If I were king," and the like), but it's still around here and there. In most cases, as here, the subjunctive form is only distinctive in the third person: "This requires that he know the secret."

RFC 3207, "SMTP Service Extension for Secure SMTP over Transport Layer Security", February 2002

Note: This RFC has been updated by RFC 7817

Source of RFC: Legacy

Errata ID: 4442
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Daniel Kahn Gillmor
Date Reported: 2015-08-10
Rejected by: Barry Leiba
Date Rejected: 2015-08-10

Section Appendix says:

   -  Section 5 and 7: More discussion of the man-in-the-middle attacks
   -  Section 5: Additional discussion of when a server should and
      should not advertise the STARTTLS extension
   -  Section 5: Changed the requirements on SMTP clients after
      receiving a 220 response.
   -  Section 5.1: Clarified description of verifying certificates.
   -  Section 5.3: Added the section on "STARTTLS on the Submission
      Port"
   -  Section 6: Bug fix in the example to indicate that the client
      needs to issue a new EHLO command, as already is described in
      section 5.2.
   -  Section 7: Clarification of the paragraph on acceptable degree of
      privacy. Significant change to the discussion of how to avoid a
      man-in-the-middle attack.
   -  Section A: Update reference from RFC 821 to RFC 2821.

It should say:

   -  Section 4 and 6: More discussion of the man-in-the-middle attacks
   -  Section 4: Additional discussion of when a server should and
      should not advertise the STARTTLS extension
   -  Section 4: Changed the requirements on SMTP clients after
      receiving a 220 response.
   -  Section 4.1: Clarified description of verifying certificates.
   -  Section 4.3: Added the section on "STARTTLS on the Submission
      Port"
   -  Section 5: Bug fix in the example to indicate that the client
      needs to issue a new EHLO command, as already is described in
      section 4.2.
   -  Section 5: Clarification of the paragraph on acceptable degree of
      privacy. Significant change to the discussion of how to avoid a
      man-in-the-middle attack.
   -  Section 7: Update reference from RFC 821 to RFC 2821.

Notes:

The appendix lists the changes as they apply to the sections of rfc 2487, but the links in https://tools.ietf.org/html/rfc3207#page-8 point back to the section numbers in RFC 3207. Either the section numbers referred to should be RFC 3207 numbers (the correction i'm proposing here), or the links within the HTML version should point back to RFC 2487 instead.
--VERIFIER NOTES--
The tools-based HTML rendering is not the definitive version, and the errata system is not for recording problems with that version. There's no error in http://www.rfc-editor.org/rfc/rfc3207.txt

RFC 3220, "IP Mobility Support for IPv4", January 2002

Note: This RFC has been obsoleted by RFC 3344

Source of RFC: mobileip (int)

Errata ID: 320
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: "Charles E. Perkins"
Date Reported: 2002-04-23
Rejected by: Brian Haberman
Date Rejected: 2012-06-06

In Section 3.6.1.2 (after current page 41), insert the following text:

   The Lifetime field is chosen as follows:

    -  If the mobile node is registering with a foreign agent, the
       Lifetime SHOULD NOT exceed the value in the Registration Lifetime
       field of the Agent Advertisement message received from the
       foreign agent.  When the method by which the care-of address is
       learned does not include a Lifetime, the default ICMP Router
       Advertisement Lifetime (1800 seconds) MAY be used.

    -  The mobile node MAY ask a home agent to delete a particular
       mobility binding, by sending a Registration Request with the
       care-of address for this binding, with the Lifetime field set to
       zero (Section 3.8.2).

    -  Similarly, a Lifetime of zero is used when the mobile node
       deregisters all care-of addresses, such as upon returning home.

   The Home Address field MUST be set to the mobile node's home address,
   if this information is known.  Otherwise, the Home Address MUST be
   set to zeroes.

   The Home Agent field MUST be set to the address of the mobile node's
   home agent, if the mobile node knows this address.  Otherwise, the
   mobile node MAY use dynamic home agent address resolution to learn
   the address of its home agent.  In this case, the mobile node MUST
   set the Home Agent field to the subnet-directed broadcast address
   of the mobile node's home network.  Each home agent receiving such
   a Registration Request with a broadcast destination address MUST
   reject the mobile node's registration and SHOULD return a rejection
   Registration Reply indicating its unicast IP address for use by the
   mobile node in a future registration attempt.

   The Care-of Address field MUST be set to the value of the particular
   care-of address that the mobile node wishes to (de)register.  In the
   special case in which a mobile node wishes to deregister all care-of
   addresses, it MUST set this field to its home address.

   The mobile node chooses the Identification field in accordance with
   the style of replay protection it uses with its home agent.  This is
   part of the mobility security association the mobile node shares with
   its home agent.  See Section 5.7 for the method by which the mobile
   node computes the Identification field.


3.6.1.3. Extensions

   This section describes the ordering of any mandatory and any optional
   Extensions that a mobile node appends to a Registration Request.
   This following ordering MUST be followed:

Notes:

--VERIFIER NOTES--
RFC 3220 has been obsoleted by RFC 3344.

Errata ID: 321
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: "Charles E. Perkins"
Date Reported: 2002-04-23
Rejected by: Brian Haberman
Date Rejected: 2012-06-06

Section 5.7 says:

   Whatever method is used, the low-order 32 bits of the Identification
   MUST be copied unchanged from the Registration Request to the Reply.
   The foreign agent uses those bits (and the mobile node's home
   address) to match Registration Requests with corresponding replies.
   of any Registration Reply are identical to the bits it sent in the
   Registration Request.

It should say:

   Whatever method is used, the low-order 32 bits of the Identification
   MUST be copied unchanged from the Registration Request to the Reply.
   The foreign agent uses those bits (and the mobile node's home
   address) to match Registration Requests with corresponding replies.
   The mobile node MUST verify that the low-order 32 bits of any Registration 
   Reply are identical to the bits it sent in the Registration Request.

Notes:

--VERIFIER NOTES--
RFC 3220 has been obsoleted by RFC 3344.

Errata ID: 842
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: "Charles E. Perkins"
Date Reported: 2002-04-23
Rejected by: Brian Haberman
Date Rejected: 2012-06-06

 

Correction 2: to be inserted before the line on page 74
	starting "of any Registration..."

========================================================================
      The mobile node MUST verify that the low-order 32 bits
========================================================================

It should say:

[see above]

Notes:

from pending
--VERIFIER NOTES--
RFC 3220 has been obsoleted by RFC 3344.

RFC 3261, "SIP: Session Initiation Protocol", June 2002

Note: This RFC has been updated by RFC 3265, RFC 3853, RFC 4320, RFC 4916, RFC 5393, RFC 5621, RFC 5626, RFC 5630, RFC 5922, RFC 5954, RFC 6026, RFC 6141, RFC 6665, RFC 6878, RFC 7462, RFC 7463, RFC 8217, RFC 8591, RFC 8760, RFC 8898, RFC 8996

Source of RFC: sip (rai)

Errata ID: 1742
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Pankaj Jain
Date Reported: 2009-03-25
Rejected by: Robert Sparks
Date Rejected: 2010-05-23

Section 17.1.1.2 says:

Timer D reflects the amount of time that the server transaction can
   remain in the "Completed" state when unreliable transports are used.

It should say:

Timer D reflects the amount of time that the client transaction can
   remain in the "Completed" state when unreliable transports are used.

Notes:

server transaction => client transaction
--VERIFIER NOTES--
The original text is correct. The value (and reason) for timer D is to reflect what's happening in the server transaction. See the discussion of Timer H that immediately follows the text quoted above.

Errata ID: 2910
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Iñaki Baz Castillo
Date Reported: 2011-08-02
Rejected by: Robert Sparks
Date Rejected: 2011-11-04

Section Table 2 says:

      Header field          where   proxy ACK BYE CAN INV OPT REG
      ___________________________________________________________
      Contact                1xx           -   -   -   o   -   -

It should say:

      Header field          where   proxy ACK BYE CAN INV OPT REG
      ___________________________________________________________
      Contact                1xx           -   -   -   m   -   -

Notes:

RFC 3261 says:

Section 12.1: "Dialogs are created through the generation of non-failure responses to requests with specific methods. Within this specification, only 2xx and 101-199 responses with a To tag, where the request was INVITE, will establish a dialog."

Section 12.1.1: "When a UAS responds to a request with a response that establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route header field values from the request into the response [...]. The UAS MUST add a Contact header field to the response."

So it's clear that a 1xx response to an INVITE creates a dialog and then it MUST contain a Contact header and mirrored Record-Route headers.

However Table 2 (page 162) says:

Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Contact 1xx - - - o - -
Record-Route 2xx,18x mr - o o o o -

Obviously Record-Route is optional since in the absence of a proxy doing record-routing, such header will not be present. However Contact header should appear as mandatory (m) for 1xx responses for INVITE rather than optional (o).
--VERIFIER NOTES--
1xx also includes 100 Trying, which cannot establish a Dialog. Contact is not mandatory in 100 Trying responses.

Errata ID: 5619
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Isabella Damböck
Date Reported: 2019-01-31
Rejected by: Ben Campbell
Date Rejected: 2019-02-27

Section 4 says:

The address 
of the atlanta.com SIP server could have been configured in Alice's
softphone, or it could have been discovered by DHCP, for example.

It should say:

The address 
of the atlanta.com SIP server could have been configured in Alice's 
softphone, or it could have been discovered by DNS, for example.

Notes:

DHCP Server gives away the DNS-Server to use (or sets it with DHCP option) but usually does no address translation itself. It would also be possible to omit the whole sentence.
--VERIFIER NOTES--
DHCP was the intent of the example.

Errata ID: 4379
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: OKUMURA Shinji
Date Reported: 2015-05-28
Rejected by: Orie Steele
Date Rejected: 2024-03-29

Section 25.1 says:

Errata ID: 316
digest-uri-value  =  request-uri ; Equal to request-uri
                                   as specified by HTTP/1.1

It should say:

digest-uri-value  =  rquest-uri ; Equal to request-uri
                                  as specified by HTTP/1.1

Notes:

Rule names are case-insensitive.
Request-URI has been defined already.
An original definition is correct.
Alternatively, it may refer to request-target as specified by RFC 7230.
--VERIFIER NOTES--
The original text includes: Errata ID: 316

But the current text matches the suggestion:

https://datatracker.ietf.org/doc/html/rfc3261#section-25.1

RFC 3262, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", June 2002

Source of RFC: sip (rai)

Errata ID: 4288
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Jörgen Axell
Date Reported: 2015-03-04
Rejected by: Ben Campbell
Date Rejected: 2015-07-13

Section 4 says:

   Handling of subsequent reliable provisional responses for the same
   initial request follows the same rules as above, with the following
   difference: reliable provisional responses are guaranteed to be in
   order.  As a result, if the UAC receives another reliable provisional
   response to the same request, and its RSeq value is not one higher
   than the value of the sequence number, that response MUST NOT be
   acknowledged with a PRACK, and MUST NOT be processed further by the
   UAC.  An implementation MAY discard the response, or MAY cache the
   response in the hopes of receiving the missing responses.

It should say:

   Handling of subsequent reliable provisional responses for the same
   initial request follows the same rules as above, with the following
   difference: reliable provisional responses are guaranteed to be in
   order.  As a result, if the UAC receives another reliable provisional
   response to the same request on a given dialog, and its RSeq value is
   not one higher than the value of the sequence number, that response
   MUST NOT be acknowledged with a PRACK, and MUST NOT be processed
   further by the  UAC.  An implementation MAY discard the response, or
   MAY cache the response in the hopes of receiving the missing
   responses. If forking occurs, RSeq values are processed on each early
   dialog independently. 

Notes:

Each UAS receiving a forked request selects the RSeq values independently. Without this addition of the text the forking proxy would need to change the RSeq values on the received responses to keep them in order.
--VERIFIER NOTES--
The proposed wording is not correct, since RSeq values are managed per transaction, not per dialog. The "on each dialog" language may mislead users. However, I agree that there is a problem with the original language here, and have asked sipcore to decide how to correct it. Therefore I am rejecting this errata, but we may replace it with a new one if that's what sipcore decides

RFC 3270, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", May 2002

Note: This RFC has been updated by RFC 5462

Source of RFC: mpls (rtg)

Errata ID: 1910
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Francois Le Faucheur
Date Reported: 2009-10-13
Rejected by: Adrian Farrel
Date Rejected: 2014-03-02

Section 5.2.1 says:

MAPnb : 4 bits
         Indicates the number of MAP entries included in the DIFFSERV
         Object.  This can be set to any value from 0 to 8.

It should say:

MAPnb : 4 bits
         Indicates the number of MAP entries included in the DIFFSERV
         Object.  This can be set to any value from 0 to 7.

Notes:

This errata was reported by Colors Springfield <springfieldcolors@gmail.com> on 13 October 2009.
--VERIFIER NOTES--
After many cycles of discussion, we have concluded that this issue is not as simple as it appears. There are many consequences of a change to this text with the conclusion that this would be a technical change that is best addressed through full WG discussion and the RFC process. Thus, anyone concerned about this issue should write an Internet-Draft and bring it to the MPLS working group.

RFC 3314, "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", September 2002

Source of RFC: ipv6 (int)

Errata ID: 296
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Shiang-Ming Huang
Date Reported: 2005-03-28
Rejected by: Brian Haberman
Date Rejected: 2012-05-09

Section 1 says:

     At that meeting, a decision was made to
     form a design team to write a document offering advice
     from the IPv6 WG to the 3GPP community, regarding
     their use of IPv6.

It should say:

     At that meeting, a decision was made
     form a design team to write a document offering advice
     from the IPv6 WG to the 3GPP community, regarding
     their use of IPv6.

Notes:

--VERIFIER NOTES--
The original text is grammatically correct.

RFC 3329, "Security Mechanism Agreement for the Session Initiation Protocol (SIP)", January 2003

Note: This RFC has been updated by RFC 8996

Source of RFC: sip (rai)

Errata ID: 3800
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Hadriel Kaplan
Date Reported: 2013-11-13
Rejected by: Richard Barnes
Date Rejected: 2014-02-15

Section Appendix A says:

mech-parameters    = ( algorithm / protocol /mode /
                             encrypt-algorithm / spi /
                             port1 / port2 )
encrypt-algorithm  = "ealg" EQUAL ( "des-ede3-cbc" / "null" )
spi                = "spi" EQUAL spivalue
port1              = "port1" EQUAL port
port2              = "port2" EQUAL port

It should say:

mech-parameters    = ( algorithm / protocol /mode /
                             encrypt-algorithm / spi-c / spi-s /
                             port-c / port-s )
encrypt-algorithm  = "ealg" EQUAL ( "des-ede3-cbc" / 
                             "aes-cbc" / "null" )
spi-c              = "spi-c" EQUAL spivalue
spi-s              = "spi-s" EQUAL spivalue
port-c             = "port-c" EQUAL port
port-s             = "port-s" EQUAL port

Notes:

3GPP 33.203 has different ABNF than the Appendix in this RFC. Note the "spi-c", "spi-s", "port-c", "port-s" parameter names instead of "spi", "port1", or "port2". And a new algorithm token of "aes-cbc" as well.
--VERIFIER NOTES--
The ABNF changes described here would have required substantial changes to the remainder of Appendix A. If the reporter wishes to make this update, he should submit an Internet-draft that updates this RFC.

RFC 3344, "IP Mobility Support for IPv4", August 2002

Note: This RFC has been obsoleted by RFC 5944

Note: This RFC has been updated by RFC 4636, RFC 4721

Source of RFC: mobileip (int)

Errata ID: 1482
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Keshav Chawla
Date Reported: 2008-08-06
Rejected by: Jari Arkko
Date Rejected: 2010-04-15

Section 1.10 says:

1.10.  Long Extension Format

   This format is applicable for non-skippable extensions which carry
   information more than 256 bytes.

It should say:

1.10.  Long Extension Format

   This format is applicable for any extension (skippable or non-skippable) which carry information more than 256 bytes.

Notes:

As per description in 1.11
" This format is compatible with the skippable extensions defined in
section 1.9. It is not applicable for extensions which require more
than 256 bytes of data; for such extensions, use the format described
in section 1.10."

However 1.10 specifies that it is applicable to only non-skippable extensions, so what would be the format for skippable extensions of size more than 256 bytes?

The correction will specify that any extension (skippable or non-skippable) shall use long format if its length is more than 256 bytes.
--VERIFIER NOTES--
Pete McCann, chair of MIP4 held a discussion about this in the WG and the conclusion was that the errata should be rejected.

RFC 3363, "Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)", August 2002

Note: This RFC has been updated by RFC 6672

Source of RFC: dnsext (int)

Errata ID: 3220
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Andrews
Date Reported: 2012-05-09
Rejected by: Ralph Droms
Date Rejected: 2013-03-10

Section 4 says:

4.  DNAME in IPv6 Reverse Tree

   The issues for DNAME in the reverse mapping tree appears to be
   closely tied to the need to use fragmented A6 in the main tree: if
   one is necessary, so is the other, and if one isn't necessary, the
   other isn't either.  Therefore, in moving RFC 2874 to experimental,
   the intent of this document is that use of DNAME RRs in the reverse
   tree be deprecated.

It should say:

4. DNAME in IPv6 Reverse Tree

[Deleted due to faulty premise.]

Notes:

The opening premise of this section is demonstrably wrong, and so the conclusion based on that premise is wrong. The use of DNAME in the reverse tree is and always has been independent of A6.
--VERIFIER NOTES--
The scope of the requested change is outside what can be specified through an errata.

RFC 3376, "Internet Group Management Protocol, Version 3", October 2002

Note: This RFC has been updated by RFC 4604

Source of RFC: idmr (rtg)

Errata ID: 770
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Rajesh Garg
Date Reported: 2006-03-21
Rejected by: Adrian Farrel
Date Rejected: 2011-07-24

Section 5.2 says:

If new query is Group and Source Specific query and there is pending 
response for this group and recorded source list for the group is empty 
(i.e. previous query was Group Specific query)

It should say:

[see note]

Notes:

In section 5.2 of RFC 3376, 5 sequential steps are given to handle the
received query from the multicast router.
I feel the following case is not handled properly in these steps (see above)

In this case, source list will be cleared as per step 4 of section 5.2.
But I feel the source list should be recorded to generate the report
accordingly.

from pending
--VERIFIER NOTES--
The RFC is correct in saying that recorded source-list should be cleared if the newly received query is group-specific query.

Errata ID: 7575
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Aymen Lahouel
Date Reported: 2023-07-26
Rejected by: John Scudder
Date Rejected: 2024-02-14

Section 5.1 says:

If more changes to the same interface state entry occur before all
the retransmissions of the State-Change Report for the first change
have been completed, each such additional change triggers the
immediate transmission of a new State-Change Report.

It should say:

If more changes to the same interface state entry occur before all
the retransmissions of the State-Change Report for the first change
have been completed, each such additional change triggers the
immediate transmission of a new State-Change Report only if the 
new change is of the same type as the current change.

Notes:

Section 5.1 says: "If the interface reception-state change that triggers the new report is a filter-mode change, then the next [Robustness Variable] State-Change Reports will include a Filter-Mode-Change record. This applies even if any number of source-list changes occur in that period. The host has to maintain retransmission state for the group until the [Robustness Variable] State-Change reports have been sent.".

It is clearly stated that if a source-list changes occur before all the retransmissions of the State-Change Report for the filter-mode change have been completed, The host has to maintain retransmission state for the group until the [Robustness Variable] State-Change reports have been sent. Therefore, in this case it must not immediately send a new State-Change Report.
--VERIFIER NOTES--
RFC 3376 author Bill Fenner said (private email, Feb 9 2024, shared with permission):

Hi Aymen,

Thanks for your interest in IGMPv3. I don't think your proposed change is correct, because one of the fundamental goals of IGMP is to communicate about changes immediately, so a change to say that you don't notify about a change immediately is against that goal.

One thing that makes IGMPv3 a little hard to understand is the complete separation between the interface (see section 2 - the IPMulticastListen() primitives) and the protocol. When nothing complicated is happening, a call to IPMulticastListen() will be tightly tied with a similar message, which makes it even harder to understand the behavior when something complicated happens.

Let's start with the API calls that invoke a set of messages: I think a sequence that is covered by the paragraph in question is:

1. at time T: IPMulticastListen( socket, interface, multicast-address, INCLUDE, { A } );
2. at time T1, where T1-T is less than the robustness interval: IPMulticastListen( socket, interface, multicast-address, INCLUDE, { A, B } )
(Alternatively, this could be a different socket, IPMulticastListen( socket2, interface, multicast-address, INCLUDE, { B } ) since the socket interface has to create a union of all includes to communicate to the router)

I think this is the case that you propose not to send - the first one is a filter mode change, and the second one is a source list change, and those changes are of different types.

However, the intent of section 5.1 is that you *do* send a message at time T1; it's just still TO_IN because you're not done with the robustness count of sending the filter mode change.

A high level view of the processing, assuming a robustness variable of 3, is:
Time T: 3 tramsissions total of IS_IN state scheduled, first one sent as TO_IN(A)
Time T1: 3 transmissions total of "add B" scheduled, first one sent as TO_IN(A,B)
Time T2: TO_IN(A,B)
Time T3: ALLOW(B)

This results in 3 transmissions of the filter mode change, and also 3 transmissions of the source list change. They're bundled together in the transmissions at time T1 and T2; that's the goal of section 5.1.

Please let us know if you have any more questions.

Thanks,
Bill

Errata ID: 3092
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jon Hak Song
Date Reported: 2012-01-18
Rejected by: Adrian Farrel
Date Rejected: 2012-05-08

Section 6.6.3.1 says:

6.6.3.1. Building and Sending Group Specific Queries

   When a table action "Send Q(G)" is encountered, then the group timer
   must be lowered to LMQT.  The router must then immediately send a
   group specific query as well as schedule [Last Member Query Count -
   1] query retransmissions to be sent every [Last Member Query
   Interval] over [Last Member Query Time].

   When transmitting a group specific query, if the group timer is
   larger than LMQT, the "Suppress Router-Side Processing" bit is set in
   the query message.

It should say:

6.6.3.1. Building and Sending Group Specific Queries

   When a table action "Send Q(G)" is encountered, then the group timer
   must be lowered to LMQT.  The router must then immediately send a
   group specific query as well as schedule [Last Member Query Count -
   1] query retransmissions to be sent every [Last Member Query
   Interval] over [Last Member Query Time].

   When a group specific query is being transmitted, if the group timer is
   larger than LMQT, the "Suppress Router-Side Processing" bit is set in
   the query message.

Notes:

--VERIFIER NOTES--
I am rejecting this editorial erratum because the original English is perfectly comprehensible. (It is true that it is not very elegant, but the proposed replacement isn't too good either:-)

RFC 3394, "Advanced Encryption Standard (AES) Key Wrap Algorithm", September 2002

Source of RFC: smime (sec)

Errata ID: 3358
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dwayne Litzenberger
Date Reported: 2012-09-17
Rejected by: Sean Turner
Date Rejected: 2012-09-20

Section 2.2.1 says:

   3) Output the results.

       Set C[0] = A[t]
       For i = 1 to n
           C[i] = R[t][i]

It should say:

   3) Output the results.

       Set C[0] = A[t]
       For i = 1 to n
           C[i] = R[s][i], where s = 6n

Notes:

--VERIFIER NOTES--
Authors and reporter have agreed this is incorrect and another errata will be submitted.

Errata ID: 3361
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dwayne Litzenberger
Date Reported: 2012-09-20
Rejected by: Sean Turner
Date Rejected: 2013-01-04

Section 2.2.1 says:

   3) Output the results.

       Set C[0] = A[t]
       For i = 1 to n
           C[i] = R[t][i]

It should say:

   3) Output the results.

       Set C[0] = A[s]
       For i = 1 to n
           C[i] = R[s][i]

Notes:

--VERIFIER NOTES--
The two are the same.

RFC 3405, "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", October 2002

Note: This RFC has been updated by RFC 8958

Source of RFC: urn (app)

Errata ID: 2842
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-06-23
Rejected by: Peter Saint-Andre
Date Rejected: 2011-06-23

Section 3; 12 says:

3. Registration Policies

   The creation of a given URI scheme or URN namespace id (NID) follows
   the appropriate registration documents for those spaces.  URI schemes
   follow "Registration Procedures for URL Scheme Names" (RFC 2717)
   [10].  URN namespace ids follow "URN Namespace Definition Mechanisms"
   (RFC 2611) (or updates thereto) [9].

3.1 URI.ARPA Registration

3.1.1 Only Schemes in the IETF Tree Allowed

   In order to be inserted into the URI.ARPA zone, the subsequent URI
   scheme MUST be registered under the IETF URI tree.  The requirements
   for this tree are specified in [10].

[ . . . ]

   [9]   Faltstrom, P., Iannella, R., Daigle, L. and D. van Gulik, "URN
         Namespace Definition Mechanisms", BCP 33, RFC 2611, October
         1998.

   [10]  Petke, R. and I. King, "Registration Procedures for URL Scheme
         Names", BCP 35, RFC 2717, January 1999.

It should say:

3. Registration Policies

   The creation of a given URI scheme or URN namespace id (NID) follows
   the appropriate registration documents for those spaces.  URI schemes
   follow "Guidelines and Registration Procedures for New URI Schemes" 
   (RFC 4395) [10].  URN namespace ids follow "Uniform Resource Names (URN)
   Namespace Definition Mechanisms" (RFC 3406) (or updates thereto) [9].

3.1 URI.ARPA Registration

3.1.1 Only Schemes in the IETF Tree Allowed

   In order to be inserted into the URI.ARPA zone, the subsequent URI
   scheme's specification MUST be first approved by IESG (formerly known
   as IETF Tree URI schemes, per [11]).


[ . . . ]

   [9]   Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
         "Uniform Resource Names (URN) Namespace Definition Mechanisms",
         BCP 66, RFC 3406, October 2002.

   [10]  Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
         Registration Procedures for New URI Schemes", BCP 35, RFC 4395,
         February 2006.

   [11]  Petke, R. and I. King, "Registration Procedures for URL Scheme
         Names", BCP 35, RFC 2717, January 1999.

Notes:

RFC 4395 eliminated URI schemes trees; this erratum is to incorporate this change. Moreover, references are updated.
--VERIFIER NOTES--
This erratum is rejected in accordance with <http://www.ietf.org/iesg/statement/errata-processing.html>. In particular, this erratum "proposes a change to the RFC that should be done by publishing a new RFC that replaces the current RFC". Therefore, "if the change is to be considered for future updates of the document, it should be proposed using channels other than the errata process, such as a WG mailing list".

Errata ID: 2971
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-09-15
Rejected by: Peter Saint-Andre
Date Rejected: 2011-09-15

Section n/a says:

N/A

It should say:

N/A

Notes:

This erratum report is to let the readers of RFC 3405 know that after register-uri and register-urn lists were restored in September 2011, new list archives may be found at <http://mm.icann.org/pipermail/register-uri/> and <http://mm.icann.org/pipermail/register-urn/> rather than IANA site.

--VERIFIER NOTES--
This report does not consist of an erratum against the specification.

RFC 3406, "Uniform Resource Names (URN) Namespace Definition Mechanisms", October 2002

Note: This RFC has been obsoleted by RFC 8141

Source of RFC: urn (app)

Errata ID: 2915
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-08-04
Rejected by: Pete Resnick
Date Rejected: 2011-08-04

Section Header says:

BCP: 66

It should say:

BCP: 33

Notes:

RFC 3406 obsoletes RFC 2611, which was BCP 33. Correspondingly, RFC 3406 should be BCP 33 as well. (See also http://www.rfc-editor.org/errata_search.php?rfc=4395; this is the same situation.)

If this erratum report is approved, BCP number 66 should be retired, as BCP 115 (see link above).
--VERIFIER NOTES--
This is likely correct. However, this is because the "RFC has not been processed in accordance with the rules governing the proposed change to the RFC metadata." (See IESG statement on changes to metadata in errata.) Making the suggested change would potentially invalidate references to BCP 66. The IESG and RFC Editor should decide best course of action.

RFC 3413, "Simple Network Management Protocol (SNMP) Applications", December 2002

Source of RFC: snmpv3 (ops)

Errata ID: 7694
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Blake Nemura
Date Reported: 2023-11-02
Rejected by: Rob Wilton
Date Rejected: 2024-01-15

Section 3.2 says:

       - If the isAccessAllowed ASI returns a noSuchView, noAccessEntry,
         or noGroupName error, processing of the management operation is
         halted, a PDU value is constructed using the values from the
         originally received PDU, but replacing the error-status with an
         authorizationError code, and error-index value of 0, and
         control is passed to step (6) below.

       - If the isAccessAllowed ASI returns an otherError, processing of
         the management operation is halted, a different PDU value is
         constructed using the values from the originally received PDU,
         but replacing the error-status with a genError code and the
         error-index with the index of the failed variable binding, and
         control is passed to step (6) below.

It should say:

       - If the isAccessAllowed ASI returns a notInView error for a
         Write-Class viewType (e.g. for a SetRequest-PDU), processing
         of the management operation is halted, a different PDU value is
         constructed using the values from the originally received PDU,
         but replacing the error-status with a noAccess code and the
         error-index with the index of the failed variable binding, and
         control is passed to step (6) below.

       - If the isAccessAllowed ASI returns a noSuchView, noAccessEntry,
         or noGroupName error, processing of the management operation is
         halted, a PDU value is constructed using the values from the
         originally received PDU, but replacing the error-status with an
         authorizationError code, and error-index value of 0, and
         control is passed to step (6) below.

       - If the isAccessAllowed ASI returns an otherError, processing of
         the management operation is halted, a different PDU value is
         constructed using the values from the originally received PDU,
         but replacing the error-status with a genError code and the
         error-index with the index of the failed variable binding, and
         control is passed to step (6) below.

Notes:

RFC3415, Section 3, defines 6 distinct errorIndication types for the isAccessAllowed ASI: notInView, noSuchView, noSuchContext, noGroupName, noAccessEntry, and otherError.

Whereas RFC3413 does not define handling of the notInView error. Whereby one might, presumably mistakenly, assume that notInView should be handled as "an otherError". However otherError is a distinct errorIndication for "undefined error" (presumably as a catch-all for possible implementation-level errors), whereas notInView is a defined error.

Additionally, RFC3416, Section 4.2.5, and only for SetRequest-PDU, clearly defines noAccess error-status as the first-priority validation check for "not...in the appropriate MIB view" case:
(1) If the variable binding's name specifies an existing or non-
existent variable to which this request is/would be denied
access because it is/would not be in the appropriate MIB view,
then the value of the Response-PDU's error-status field is set
to "noAccess", and the value of its error-index field is set to
the index of the failed variable binding.
--VERIFIER NOTES--
This change is too significant to do as part of an errata update to a 20 year old RFC, and there is not clear consensus as to whether any changes are required here at all (hence rejected rather than marked as "held for document update").

There has been some further discussion of this errata here:
https://mailarchive.ietf.org/arch/msg/opsawg/TDMmdSZpDYIqGYHa5SvW1cfnW4c/`
https://mailarchive.ietf.org/arch/msg/opsawg/xnXWL9fTjOhVaiAFD6kmqa-ZeNc/

RFC 3414, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", December 2002

Note: This RFC has been updated by RFC 5590

Source of RFC: snmpv3 (ops)

Errata ID: 5073
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Fabio Costantini
Date Reported: 2017-07-26
Rejected by: Benoit Claise
Date Rejected: 2017-07-27

Section 1.5.1 says:

When an SNMP message contains a
   payload which expects a response (those messages that contain a
   Confirmed Class PDU [RFC3411]), then the receiver of such messages is
   authoritative.  When an SNMP message contains a payload which does
   not expect a response (those messages that contain an Unconfirmed
   Class PDU [RFC3411]), then the sender of such a message is
   authoritative.

It should say:

When an SNMP message contains a
   payload which expects a response (those messages that contain a
   Confirmed Class PDU [RFC3411]), then the receiver of such messages is
   authoritative.  When an SNMP message contains a payload which does
   not expect a response (those messages that contain an Unconfirmed
   Class PDU [RFC3411]), then the sender of such a message is
   non-authoritative.

Notes:

In both cases the receiver was classified as "authoritative".
--VERIFIER NOTES--
The initial text says it correctly: the sender of such a message is authoritative

RFC 3416, "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", December 2002

Source of RFC: snmpv3 (ops)

Errata ID: 3402
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Mike Sauve
Date Reported: 2012-11-08
Rejected by: Benoit Claise
Date Rejected: 2012-11-09

Section 3 says:

max-bindings INTEGER ::= 2147483647

It should say:

max-bindings ::= INTEGER (2147483647)

Notes:

--VERIFIER NOTES--
According to section 4.2 of the ASN.1 spec, the grammar for the value notation is
ValueDefinition ::= identifier Type "::=" Value

The current text conforms to this grammar, and the usage in this particular case
is closely analogous to the example the ASN.1 standard gives in that same
section.

It looks like the submitter wants to change the value definition into a
type definition, which to me would be inconsistent with how the the SNMP
specification employs max-bindings.

Errata ID: 3403
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Mike Sauve
Date Reported: 2012-11-08
Rejected by: Benoit Claise
Date Rejected: 2012-11-26

Section 3 says:

VarBindList ::= SEQUENCE (SIZE (0..max-bindings)) OF VarBind

It should say:

VarBindList ::= SEQUENCE {SIZE (0..max-bindings)} OF VarBind

Notes:

--VERIFIER NOTES--
As reviewed by Juergen Schoenwaelder and Randy Presuhn:

It definitely conforms to the
grammar of the ASN.1 version cited in the references. However,
the "new" ASN.1's changes should not have caused any problems
for the construct in question, though other parts of the grammar
might cause some heartburn.

For the old ASN.1 / new ASN.1 issues (seen through rose-colored
glasses) see http://www.itu.int/ITU-T/studygroups/com17/changing-ASN/

To be really really sure, I tried compiling the module with the
commercial OSS Nokalva ASN.1 syntax checker, configured to
be strict in requiring ASN.1 2002, rather than auto-detecting the
ASN.1 version. It issues one warning (about the anonymous CHOICE
inside the VarBind construct - no surprise) but has no problem
whatsoever with the constructs referred to in the proposed erratum.

The bottom line is that the grammar is correct as-is, and that the
problem is with the submitter's toolset.

As Juergen indicates, this is really a symptom of a subtler issue:
SMI notation is *not* ASN.1, but modules written in the SMI language
have used the IMPORTS construct to reference stuff from ASN.1
modules. Back when I was implementing this stuff, our solution to
this problem was to make sure our tools understood both grammars
(as well as the GDMO and some other notations), but this is going
deep into the guts of how vendors' products handle IMPORTS
constructs, and trying to standardize it would probably
not be a good use of time at this juncture.

RFC 3418, "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", December 2002

Source of RFC: snmpv3 (ops)

Errata ID: 6219
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kevin Seymour
Date Reported: 2020-07-02
Rejected by: Robert Wilton
Date Rejected: 2020-07-03

Section sysServices says:

For example, a node which performs only routing functions would have a value of 4 (2^(3-1)).

It should say:

For example, a node which performs only routing functions would have a value of 4 (2^(4-1)).

Notes:

Typo in the example formula.
--VERIFIER NOTES--
The formula in the original document is correct. The "3" in the calculation refers to the OSI layer that routing functions occur at.

RFC 3447, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", February 2003

Note: This RFC has been obsoleted by RFC 8017

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 3716
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Jim Wigginton
Date Reported: 2013-09-02
Rejected by: Kathleen Moriarty
Date Rejected: 2015-03-31

Section 7.1.2 says:

   3. EME-OAEP decoding:

      a. If the label L is not provided, let L be the empty string. Let
         lHash = Hash(L), an octet string of length hLen (see the note
         in Section 7.1.1).

      b. Separate the encoded message EM into a single octet Y, an octet
         string maskedSeed of length hLen, and an octet string maskedDB
         of length k - hLen - 1 as

            EM = Y || maskedSeed || maskedDB.

      c. Let seedMask = MGF(maskedDB, hLen).

It should say:

   3. EME-OAEP decoding:

      a. If the label L is not provided, let L be the empty string. Let
         lHash = Hash(L), an octet string of length hLen (see the note
         in Section 7.1.1).

      b. Separate the encoded message EM into a single octet Y, an octet
         string maskedSeed of length hLen, and an octet string maskedDB
         of length k - hLen - 1 as

            EM = Y || maskedSeed || maskedDB.

      c. Check to see if Y is 00.

Notes:

Per <https://tools.ietf.org/html/rfc3447#page-21> the first byte of EM should be 00 so shouldn't RSAES-OAEP-DECRYPT / EME-OAEP decoding check that?
--VERIFIER NOTES--
Step g includes the check for Y = 0

If there is no octet with hexadecimal value 0x01 to separate PS
from M, if lHash does not equal lHash', or if Y is nonzero,
output "decryption error" and stop. (See the note below.)

Errata ID: 2177
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2011-06-02

Section 8.1.2 says:

   4. If Result = "consistent," output "valid signature." Otherwise,
      output "invalid signature."

It should say:

   4. If Result = "consistent", output "valid signature", Otherwise,
      output "invalid signature."

Notes:

obvious
--VERIFIER NOTES--
This is addressed in errata #2582.

RFC 3455, "Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)", January 2003

Note: This RFC has been obsoleted by RFC 7315

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rai

Errata ID: 3973
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Zoltan Toth
Date Reported: 2014-04-24
Rejected by: Orie Steele
Date Rejected: 2024-03-29

Section 4.2 says:

      F6 Invite P1 -> UA
           INVITE sip:user1@192.0.2.4 SIP/2.0
           Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bKg48sh128
           Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1
           To: sip:other-user@othernetwork.com
           From: sip:another-user@anothernetwork.com;tag=938s0
           Call-ID: 843817637684230998sdasdh09
           P-Called-Party-ID: sip:user1-business@example.com
           CSeq: 101 INVITE

It should say:

      F6 Invite P1 -> UA
           INVITE sip:user1@192.0.2.4 SIP/2.0
           Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bKg48sh128
           Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1
           To: sip:other-user@othernetwork.com
           From: sip:another-user@anothernetwork.com;tag=938s0
           Call-ID: 843817637684230998sdasdh09
*          P-Called-Party-ID: <sip:user1-business@example.com>
           CSeq: 101 INVITE

Notes:

5.2 P-Called-Party-ID header syntax

The syntax of the P-Called-Party-ID header is described as follows:

P-Called-Party-ID = "P-Called-Party-ID" HCOLON
called-pty-id-spec
called-pty-id-spec = name-addr *(SEMI cpid-param)

RFC3261:
name-addr = [ display-name ] LAQUOT addr-spec RAQUOT

-> the SIP URI of the PCPI header in the example should be enclosed in angle quotes.
--VERIFIER NOTES--
This errata was corrected in https://datatracker.ietf.org/doc/html/rfc7315 which obsoleted https://datatracker.ietf.org/doc/html/rfc3455

RFC 3461, "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", January 2003

Note: This RFC has been updated by RFC 3798, RFC 3885, RFC 5337, RFC 6533, RFC 8098

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 4218
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jaime Hablutzel
Date Reported: 2015-01-03
Rejected by: Barry Leiba
Date Rejected: 2015-03-10

Section 10.5 says:

Note that RET, ENVID, and ORCPT all retain their original values.

...

>>> RCPT TO:<Sam@Boondoggle.GOV> NOTIFY=SUCCESS \
ORCPT=rfc822;George@Tax-ME.GOV
<<< 250 recipient okay

It should say:

Note that RET, ENVID, NOTIFY, and ORCPT all retain their original
values.

...

>>> RCPT TO:<Sam@Boondoggle.GOV> NOTIFY=FAILURE \
ORCPT=rfc822;George@Tax-ME.GOV
<<< 250 recipient okay

Notes:

See the original conversation during the submission (section 10.1) where the NOTIFY parameter has a "FAILURE" value for "George@Tax-ME.GOV" recipient.

>>> RCPT TO:<George@Tax-ME.GOV> NOTIFY=FAILURE \
ORCPT=rfc822;George@Tax-ME.GOV
<<< 250 <George@Tax-ME.GOV> recipient ok

See section 5.2.7.2, "single-recipient aliases".

Under normal circumstances, when a message arrives for an "alias"
which has a single forwarding address, a DSN SHOULD NOT be issued.
Any ENVID, NOTIFY, RET, or ORCPT parameters SHOULD be propagated with
the message as it is redistributed to the forwarding address.

Where it saids that all ENVID, NOTIFY, RET, and ORCPT should be propagated.
--VERIFIER NOTES--
There are specific cases in which NOTIFY doesn't retain its value when a message is relayed (such as if the next hop doesn't support the extension) and the omission of NOTIFY from that list is deliberate.

RFC 3470, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", January 2003

Note: This RFC has been updated by RFC 8996

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 3790
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Erik Wilde
Date Reported: 2013-11-07
Rejected by: Barry Leiba
Date Rejected: 2013-11-07

Section 4.2 says:

n/a

It should say:

n/a

Notes:

While at the time of writing the Infoset was the most relevant spec, now there's XDM, which is more relevant now.

It also might make sense to describe the differences between XML syntax and the more abstract view of Infoset/XML in detail, in particular when it comes to nasty edge cases such as unserializable Infosets, and the fact that some information present in the XML syntax gets lost in the more abstract view.
--VERIFIER NOTES--
As the report says,"at the time of writing the Infoset was the most relevant spec" -- and errata are here to report things that would have been considered errors at the time of writing, but they got missed. This isn't that.

RFC 3501, "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", March 2003

Note: This RFC has been obsoleted by RFC 9051

Note: This RFC has been updated by RFC 4466, RFC 4469, RFC 4551, RFC 5032, RFC 5182, RFC 5738, RFC 6186, RFC 6858, RFC 7817, RFC 8314, RFC 8437, RFC 8474, RFC 8996

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 3445
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Slusarz
Date Reported: 2013-01-06
Rejected by: Barry Leiba
Date Rejected: 2013-01-08

Section 6.3.1 says:

         OK [UIDNEXT <n>]
                     The next unique identifier value.  Refer to section
                     2.3.1.1 for more information.  If this is missing,
                     the client can not make any assumptions about the
                     next unique identifier value.

It should say:

         OK [UIDNEXT <n>]
                     The next unique identifier value.  Refer to section
                     2.3.1.1 for more information.

Notes:

The UIDNEXT response to a SELECT/EXAMINE command is a "REQUIRED OK untagged response" (see Sections 6.3.1 & 6.3.2; see also Appendix B #34). The UIDNEXT response code requires a nz-number per the ABNF (Section 9). Therefore the UIDNEXT value can never be "missing" from a SELECT/EXAMINE, and no assumptions about client behavior should be mentioned.

As currently phrased, the UIDNEXT text implies that the response MAY be missing, which is in direct conflict with the requirements in Sections 6.3.1/6.3.2 that UIDNEXT MUST always be present. REQUIRED appears to be the proper requirement based on the previously mentioned change entry.

See discussion on the IMAP protocol discussion list (http://thread.gmane.org/gmane.mail.imap.general/3163).
--VERIFIER NOTES--
Look at the paragraph above the responses in Section 6.3.1. It says this:

The SELECT command selects a mailbox so that messages in the
mailbox can be accessed. Before returning an OK to the client,
the server MUST send the following untagged data to the client.
Note that earlier versions of this protocol only required the
FLAGS, EXISTS, and RECENT untagged data; consequently, client
implementations SHOULD implement default behavior for missing data
as discussed with the individual item.

The text that you're suggesting removing is there very purposefully,
and should NOT be removed. That said, I think this is not very clear,
and I would like to see a future document update re-word things to
make it clearer.

The point is that these are REQUIRED in the current version of the protocol,
but that because they were optional in an earlier version, and that version is
not distinguishable from this one in operation, clients SHOULD support the
earlier version by taking the actions specified in the even that some or all of
these untagged OK responses are missing.

Errata ID: 6636
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: TornaxO7
Date Reported: 2021-07-10
Rejected by: Benjamin Kaduk
Date Rejected: 2021-07-21

Throughout the document, when it says:

   IMAP4rev1 includes operations for creating, deleting, and renaming
   mailboxes, checking for new messages, permanently removing messages,
   setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching,
   and selective fetching of message attributes, texts, and portions
   thereof.

It should say:

   IMAP4rev1 includes operations for creating, deleting, and renaming
   mailboxes, checking for new messages, permanently removing messages,
   setting and clearing flags, RFC 5322 and RFC 2045 parsing, searching,
   and selective fetching of message attributes, texts, and portions
   thereof.

Notes:

RFC-3501 still refers to RFC-2822 which is obsoleted by RFC-5322. **One** example can be seen in the "Original text" section.
--VERIFIER NOTES--
Errata reports are for issues that were errors at the time of publication. RFC 5322 was published after RFC 3501, so RFC 2822 was the correct reference when RFC 3501 was published.

RFC 3519, "Mobile IP Traversal of Network Address Translation (NAT) Devices", April 2003

Source of RFC: mobileip (int)

Errata ID: 1481
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Manish Yadav
Date Reported: 2008-08-06
Rejected by: Brian Haberman
Date Rejected: 2012-10-04

Section 3.2 says:

3.2 UDP Tunnel Reply Extension

   This extension is a non-skippable extension.  It is sent in reply to
   a UDP Tunnel Request extension, and indicates whether or not the HA
   will use MIP UDP tunnelling for the current mobility binding.  The
   format of this extension is as shown below.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |    Sub-Type   |  Reply Code   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |F|        Reserved             |     Keepalive Interval        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type                44

   Length              6.  Length in bytes of this extension, not
                       including the Type and Length bytes.

   Sub-Type            0

   Reply Code          Indicates whether the HA assents or declines
                       to use UDP tunnelling for the current mobility
                       binding.  See Section 3.2.1 below.

Notes:

In RFC 3519 paragraph 3.2, the UDP Tunnel Reply Extension is specified as a non-skippable with type = 44. However the extension is specified in the "Short Extension Format", which should be used for skippable extensions according to RFC 3344 paragraph 1.11.
--VERIFIER NOTES--
RFC 3344 paragraph 1.11 specifies that the short extension format
must be used by skippable extensions. It doesn't say mean that the format is only used by skippable extensions (i.e., the short extension format can be used by non-skippable extensions).

RFC 3526, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", May 2003

Source of RFC: ipsec (sec)

Errata ID: 7244
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Igor Krisyuk
Date Reported: 2022-11-09
Date Rejected: 2023-08-02

Section 4 says:

3072-bit MODP Group

   This group is assigned id 15.

   This prime is: 2^3072 - 2^3008 - 1 + 2^64 * { [2^2942 pi] + 1690314 }

   Its hexadecimal value is:

      FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
      29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
      EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
      E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
      EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
      C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
      83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
      670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
      E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
      DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
      15728E5A 8AAAC42D AD33170D 04507A33 A85521AB DF1CBA64
      ECFB8504 58DBEF0A 8AEA7157 5D060C7D B3970F85 A6E1E4C7
      ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226 1AD2EE6B
      F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
      BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31
      43DB5BFC E0FD108E 4B82D120 A93AD2CA FFFFFFFF FFFFFFFF

   The generator is: 2.

It should say:

3072-bit MODP Group

   This group is assigned id 15.

   This prime is: 2^3072 - 2^3008 - 1 + 2^64 * { [2^2942 pi] + 1690314 }

   Its hexadecimal value is:

      FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
      29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
      EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
      E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
      EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
      C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
      83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
      670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
      E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
      DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
      15728E5A 8AAAC42D AD33170D 04507A33 A85521AB DF1CBA64
      ECFB8504 58DBEF0A 8AEA7157 5D060C7D B3970F85 A6E1E4C7
      ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226 1AD2EE6B
      F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
      BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31
      43DB5BFC E0FD108E 4B82D120 A93AD2CA FFFFFFFF FFFFFFFF

   The generator is: 5.

Notes:

we have statement that 2 is a generator for 3072-bit MODP Group, but it's wrong because 2 ^ ((N - 1)/2) = 1 (mod N) where N is 2^3072 - 2^3008 - 1 + 2^64 * { [2^2942 pi] + 1690314 }. I think that the correct value of the generator for this group should be 5.
--VERIFIER NOTES--
This is for RFC3526 and it says that Generator should not be
2, but this is incorrect. The group in the RFC is generated
using the instructions frm the RFC2412 and that explains that
number 2 is not technically a generator, but there are reasons
to use it (APPENDIX E The Well-Known Groups of 2412):

Using 2 as a generator is efficient for some modular
exponentiation algorithms. [Note that 2 is technically not a
generator in the number theory sense, because it omits half of
the possible residues mod P. From a cryptographic viewpoint,
this is a virtue.]

This change would be break interoperability with old
implementations

RFC 3550, "RTP: A Transport Protocol for Real-Time Applications", July 2003

Note: This RFC has been updated by RFC 5506, RFC 5761, RFC 6051, RFC 6222, RFC 7022, RFC 7160, RFC 7164, RFC 8083, RFC 8108, RFC 8860

Source of RFC: avt (rai)

Errata ID: 3914
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Hani Mustafa
Date Reported: 2014-03-06
Rejected by: Richard Barnes
Date Rejected: 2014-03-06

Section A.1 says:

      init_seq(s, seq);
      s->max_seq = seq - 1;
      s->probation = MIN_SEQUENTIAL;

It should say:

      init_seq(s, seq);
      s->max_seq = seq == 0 ? seq : seq - 1;
      s->probation = MIN_SEQUENTIAL;

Notes:

If the first RTP packet has a sequence number of 0, the logic will cause cycles to increase by 1, which will affect "expected number of received packets" calculations.
--VERIFIER NOTES--
Submitter requested rejection.

Errata ID: 4192
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Julius Friedman
Date Reported: 2014-12-03
Rejected by: Ben Campbell
Date Rejected: 2015-07-22

Section 6.4.1 says:

sender's octet count: 32 bits
      The total number of payload octets (i.e., not including header or
      padding) transmitted in RTP data packets by the sender since
      starting transmission up until the time this SR packet was
      generated.  The count SHOULD be reset if the sender changes its
      SSRC identifier.  This field can be used to estimate the average
      payload data rate.

It should say:

sender's octet count: 32 bits
      The total number of payload octets 
      transmitted in RTP data packets by the sender since
      starting transmission up until the time this SR packet was
      generated.  The count SHOULD be reset if the sender changes its
      SSRC identifier.  This field can be used to estimate the average
      payload data rate.

Notes:

Where as payload octets is defined as the total number of data octets contained in a Rtp Packet minus the 12 Header octets for Rtp Packets.

Padding octets as well as octets which occur in the contributing source list should also be included as they may differ on a per packet basis and would make the total calculation invalid.

During TCP communication any application layer header should NOT be included in the total bytes count when including the header length.

Any Rtcp packet counters should include the total length of the packet (header, padding and any other data).
--VERIFIER NOTES--
Rejected based on discussion in avtcore

RFC 3575, "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", July 2003

Note: This RFC has been updated by RFC 6929

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: ops

Errata ID: 5093
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Octabiolopez
Date Reported: 2017-08-20
Rejected by: Warren Kumari
Date Rejected: 2017-08-21

Section Global says:

Notes:

Errata report was blank, assuming submitted in error / by a bot.
--VERIFIER NOTES--
Reported errata was blank - assuming submitted in error.

RFC 3588, "Diameter Base Protocol", September 2003

Note: This RFC has been obsoleted by RFC 6733

Note: This RFC has been updated by RFC 5729, RFC 5719, RFC 6408

Source of RFC: aaa (ops)

Errata ID: 3381
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vinay Parashar
Date Reported: 2012-10-17
Rejected by: RonBonica
Date Rejected: 2012-10-29

Section 8.20. Class says:

8.20.  Class AVP

As described in section 8.20.Class AVP,that Class AVP is used by server 
to give state information to accesses device. And Class AVP MUST be 
present in subsequent re-authorization,STR and accounting messages.

Now if application uses the base diameter messages for
re-authentication[RAR/RAA] and accounting[ACR/ACA] then these message 
definition should have Class AVP. But it is not present.

It should say:

Definition of RAR/RAA and ACR/ACA should have Class AVP, As STA message definition have.
<RAR>  ::= < Diameter Header: 258, REQ, PXY >
                 < Session-Id >
                 { Origin-Host }
                 { Origin-Realm }
                 { Destination-Realm }
                 { Destination-Host }
                 { Auth-Application-Id }
                 { Re-Auth-Request-Type }
                 [ User-Name ]
                 [ Origin-State-Id ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]//************** should have Class AVP **********//



<RAA>  ::= < Diameter Header: 258, PXY >
                 < Session-Id >
                 { Result-Code }
                 { Origin-Host }
                 { Origin-Realm }
                 [ User-Name ]
                 [ Origin-State-Id ]
                 [ Error-Message ]
                 [ Error-Reporting-Host ]
               * [ Failed-AVP ]
               * [ Redirect-Host ]
                 [ Redirect-Host-Usage ]
                 [ Redirect-Host-Cache-Time ]
               * [ Proxy-Info ]
               * [ AVP ] //************** should have Class AVP **********//



 <ACR> ::= < Diameter Header: 271, REQ, PXY >
                < Session-Id >
                { Origin-Host }
                { Origin-Realm }
                { Destination-Realm }
                { Accounting-Record-Type }
                { Accounting-Record-Number }
                [ Acct-Application-Id ]
                [ Vendor-Specific-Application-Id ]
                [ User-Name ]
                [ Accounting-Sub-Session-Id ]
                [ Acct-Session-Id ]
                [ Acct-Multi-Session-Id ]
                [ Acct-Interim-Interval ]
                [ Accounting-Realtime-Required ]
                [ Origin-State-Id ]
                [ Event-Timestamp ]
              * [ Proxy-Info ]
              * [ Route-Record ]
              * [ AVP ]//************** should have Class AVP **********//


 <ACA> ::= < Diameter Header: 271, PXY >
                < Session-Id >
                { Result-Code }
                { Origin-Host }
                { Origin-Realm }
                { Accounting-Record-Type }
                { Accounting-Record-Number }
                [ Acct-Application-Id ]
                [ Vendor-Specific-Application-Id ]
                [ User-Name ]
                [ Accounting-Sub-Session-Id ]
                [ Acct-Session-Id ]
                [ Acct-Multi-Session-Id ]
                [ Error-Reporting-Host ]
                [ Acct-Interim-Interval ]
                [ Accounting-Realtime-Required ]
                [ Origin-State-Id ]
                [ Event-Timestamp ]
              * [ Proxy-Info ]
              * [ AVP ]//************** should have Class AVP **********//



<STR> ::= < Diameter Header: 275, REQ, PXY >
                < Session-Id >
                { Origin-Host }
                { Origin-Realm }
                { Destination-Realm }
                { Auth-Application-Id }
                { Termination-Cause }
                [ User-Name ]
                [ Destination-Host ]
              * [ Class ] //****Class AVP present [correct implementation] ***//
                [ Origin-State-Id ]
              * [ Proxy-Info ]
              * [ Route-Record ]
              * [ AVP ]


      <STA>  ::= < Diameter Header: 275, PXY >
                 < Session-Id >
                 { Result-Code }
                 { Origin-Host }
                 { Origin-Realm }
                 [ User-Name ]
               * [ Class ]//****Class AVP present [correct implementation] ***//
                 [ Error-Message ]
                 [ Error-Reporting-Host ]
               * [ Failed-AVP ]
                 [ Origin-State-Id ]
               * [ Redirect-Host ]
                 [ Redirect-Host-Usage ]
                                    ^
                 [ Redirect-Max-Cache-Time ]
               * [ Proxy-Info ]
               * [ AVP ]

Notes:

--VERIFIER NOTES--
I think that there might be some confusion regarding this errata. Section 8.20 does not contain the text that the errata claims that it contains.

RFC 3610, "Counter with CBC-MAC (CCM)", September 2003

Source of RFC: INDEPENDENT

Errata ID: 6822
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Juergen Koeppel
Date Reported: 2022-01-24
Rejected by: Adrian Farrel
Date Rejected: 2022-01-27

Section 2.2 says:

First two octets   Followed by       Comment
    -----------------  ----------------  -------------------------------
    0x0000             Nothing           Reserved
    0x0001 ... 0xFEFF  Nothing           For 0 < l(a) < (2^16 - 2^8)
    0xFF00 ... 0xFFFD  Nothing           Reserved
    0xFFFE             4 octets of l(a)  For (2^16 - 2^8) <= l(a) < 2^32
    0xFFFF             8 octets of l(a)  For 2^32 <= l(a) < 2^64

It should say:

First two octets   Followed by       Comment
    -----------------  ----------------  -------------------------------
    0x0000             Nothing           Reserved
    0x0001 ... 0xFEFF  Nothing           For 0 < l(a) < (2^16 - 2^8)
    0xFF00 ... 0xFFFD  Nothing           Reserved
    0xFFFE             4 octets of l(a)  For (2^16 - 2^8) <= l(a) < 2^32
    0xFFFF             6 octets of l(a)  For 2^32 <= l(a) < 2^64

Notes:

The total size of the length field encoded according to the table in seciton 2.2 is 8 octets. The first column defines the first two octets. The second column defines the following octets, which in case of the first two octets being 0xFFFF is 6 octets, not 8 octets.
--VERIFIER NOTES--
Text a little earlier in Section 2.2 says:
If 2^32 <= l(a) < 2^64, then the length field is encoded as ten
octets consisting of the octets 0xff, 0xff, and eight octets encoding
l(a) in most-significant-byte-first order.
Thus, the quoted text is correct at:
0xFFFF 8 octets of l(a) For 2^32 <= l(a) < 2^64

This resolution may give rise to further issues, but they would warrant a separate errata report.

RFC 3618, "Multicast Source Discovery Protocol (MSDP)", October 2003

Source of RFC: msdp (rtg)

Errata ID: 4013
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Ramiro Garza Rios
Date Reported: 2014-06-12
Rejected by: Alia Atlas
Date Rejected: 2014-06-17

Section 12.2 says:

12.2. Defined TLVs


   The following TLV Types are defined:

   Code                        Type
   ===================================================
     1                  IPv4 Source-Active
     2                  IPv4 Source-Active Request
     3                  IPv4 Source-Active Response
     4                  KeepAlive
     5                  Reserved (Previously: Notification)

It should say:

12.2. Defined TLVs


   The following TLV Types are defined:

   Code                        Type
   ===================================================
     1                  IPv4 Source-Active
     2                  (Previously IPv4 Source-Active Request)
     3                  (Previously IPv4 Source-Active Response)
     4                  KeepAlive
     5                  Reserved (Previously: Notification)

Notes:

Since SA caching is mandatory for all MSDP speakers, the Source-Active request and response messages are no longer necessary. They should be removed from the text to avoid confusion or include a reason as to why they are included and a description of their purpose.
--VERIFIER NOTES--
This needs to go through the standards process. Deprecating messages in the protocol is not an errata item.

Errata ID: 5356
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Frank Hua Li
Date Reported: 2018-05-10
Rejected by: Alvaro Retana
Date Rejected: 2018-05-24

Section 5.3 says:

5.3.  SA Cache Timeout (SA-State Timer)

   Each entry in an SA Cache has an associated SA-State Timer.  A
   (S,G)-SA-State-Timer is started when an (S,G)-SA message is initially
   received by an MSDP peer.  The timer is reset to [SG-State-Period] if
   another (S,G)-SA message is received before the (S,G)-SA-State Timer
   expires.  [SG-State-Period] MUST NOT be less than [SA-Advertisement-
   Period] + [SA-Hold-Down-Period].

It should say:

5.3.  SA Cache Timeout (SA-State Timer)

   Each entry in an SA Cache has an associated SA-State Timer.  A
   (S,G)-SA-State-Timer is started when an (S,G)-SA message is initially
   received by an MSDP peer.  The timer is reset to [SG-State-Period] if
   another (S,G)-SA message is received before the (S,G)-SA-State Timer
   expires.  [SG-State-Period] MUST NOT be less than [SA-Advertisement-
   Period].

Or define the [SA-Hold-Down-Period] refers to.

Notes:

There is no definition of [SA-Hold-Down-Period] timer in the document. We should either remove the reference of [SA-Hold-Down-Period] from 5.3 or clearly define what [SA-Hold-Down-Period] refers to. If not, this will cause confusion for implementation.
--VERIFIER NOTES--
The discussion on the WG list is here: https://mailarchive.ietf.org/arch/msg/pim/HeCvgF59HdxWMp7PYSUUteL2D5E

RFC 3659, "Extensions to FTP", March 2007

Source of RFC: ftpext (app)

Errata ID: 901
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-04-14
Rejected by: Pete Resnick
Date Rejected: 2011-05-16

Section 7.5.4 says:

   The create fact indicates when a file, or directory, was first
   created.  Exactly what "creation" is for this purpose is not
   specified here, and may vary from server to server.  About all that
   can be said about the value returned is that it can never indicate a
   later time than the modify fact.

It should say:

   The create fact indicates when a file, or directory, was first
   created.  Exactly what "creation" is for this purpose is not
   specified here, and may vary from server to server.

Notes:

It is one of the benefits of 'Create' timestamps for directory
entries that there is *no* enforced relationship between that
timestamp and the 'Modify' timestamp related to the file *content*.

We still support legacy systems from Hewlett-Packard that indeed
maintain three timestamps per directory entry: 'Create', 'Modify',
and 'Access'. The very useful behaviour of the File System and
the proprietary Networking Services is as follows: If you move a
file to another directory or copy it (within a system, or across
the network), the 'Modify' timestamp does not change (since the
file content is unchanged from what it was then), only the 'Create'
timestamp of the new directory entry is set to the current time.
(This means the 'Modify' timestamp behaves like a 'last update'
timestamp embedded in the file content, e.g., in a PDF file.)
In this case, the create fact would have to be *later* than the
modify fact, for RFC 3659. Naturally, if a file was being edited,
the 'Modify' timestamp changes and will then be later than the
'Create' timestamp.
The natural behaviour of a hypothetical FTP client implementing
RFC 3659 in such environment, when performing a 'get' operation,
would be to obtain the modify timestamp of the remote file via
MLSx or MDTM and, after performing the RETR (and, perhaps verifying
the 'atomicity' of the transfer via another MDTM that should deliver
the same response again) setting the 'Modify' timestamp of the local
copy of the file to the moment corresponding to the MDTM result
value (or the modify fact value from the MLSx).
--VERIFIER NOTES--
This is a technical change that may be against the consensus of a WG and therefore is not appropriate for an erratum.

RFC 3665, "Session Initiation Protocol (SIP) Basic Call Flow Examples", December 2003

Source of RFC: sipping (rai)

Errata ID: 4516
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Fritz
Date Reported: 2015-10-30
Rejected by: Ben Campbell
Date Rejected: 2015-11-01

Section 3.2 says:

   F3 ACK Alice -> Proxy 1

   ACK sip:bob@biloxi.example.com SIP/2.0
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b43
   Max-Forwards: 70
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>;tag=3flal12sf
   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 1 ACK
   Content-Length: 0

It should say:

   F3 ACK Alice -> Proxy 1

   ACK sip:bob@biloxi.example.com SIP/2.0
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK12345
   Max-Forwards: 70
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>;tag=3flal12sf
   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 1 ACK
   Content-Length: 0

Notes:

ACK is a new transaction and need a new value for via-branch
--VERIFIER NOTES--
The flow in the RFC is correct. ACK is only a new transaction if the final response to the INVITE was in the 2xx class. In this case, the final response was a 407 - this ACK is hop-by-hop, and is part of the INVITE transaction.

Errata ID: 4723
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Benoit Entzmann
Date Reported: 2016-06-30
Rejected by: Ben Campbell
Date Rejected: 2016-06-30

Throughout the document, when it says:

CSeq: 1 BYE

It should say:

CSeq: 2 BYE

Notes:

RFC 3261:
Section 15.1.1 UAC Behavior
A BYE request is constructed as would any other request within a
dialog, as described in Section 12.

Section 12.2.1.1 Generating the Request
A request within a dialog is constructed by using many of the
components of the state stored as part of the dialog...
... Requests within a dialog MUST contain strictly monotonically
increasing and contiguous CSeq sequence numbers (increasing-by-one)
in each direction

Each direction of the dialog shows CSeq: 1 so whatever is the direction that generates the BYE it must increase the value to 2
--VERIFIER NOTES--
The CSeq numbering space is independent for each peer. Alice's CSeq values do not affect Bob's. The intent of the phrase "in each direction" in the quote is to say that each "direction" has increments independently of the other.

RFC 3711, "The Secure Real-time Transport Protocol (SRTP)", March 2004

Note: This RFC has been updated by RFC 5506, RFC 6904, RFC 9335

Source of RFC: avt (rai)

Errata ID: 7606
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: David Satterlee
Date Reported: 2023-08-17
Rejected by: Francesca Palombini
Date Rejected: 2023-11-07

Section B.3 says:

   This section provides test data for the default key derivation
   function, which uses AES-128 in Counter Mode.  In the following, we
   walk through the initial key derivation for the AES-128 Counter Mode
   cipher, which requires a 16 octet session encryption key and a 14
   octet session salt, and an authentication function which requires a
   94-octet session authentication key.

(...)

   Below, the auth key is shown on the left, while the corresponding AES
   input blocks are shown on the right.

   auth key                           AES input blocks
   CEBE321F6FF7716B6FD4AB49AF256A15   0EC675AD498AFEEAB6960B3AABE60000
   6D38BAA48F0A0ACF3C34E2359E6CDBCE   0EC675AD498AFEEAB6960B3AABE60001
   E049646C43D9327AD175578EF7227098   0EC675AD498AFEEAB6960B3AABE60002
   6371C10C9A369AC2F94A8C5FBCDDDC25   0EC675AD498AFEEAB6960B3AABE60003
   6D6E919A48B610EF17C2041E47403576   0EC675AD498AFEEAB6960B3AABE60004
   6B68642C59BBFC2F34DB60DBDFB2       0EC675AD498AFEEAB6960B3AABE60005

It should say:

   This section provides test data for the default key derivation
   function, which uses AES-128 in Counter Mode.  In the following, we
   walk through the initial key derivation for the AES-128 Counter Mode
   cipher, which requires a 16 octet session encryption key and a 14
   octet session salt, and an authentication function which requires a
   20-octet session authentication key.

(...)

   Below, the auth key is shown on the left, while the corresponding AES
   input blocks are shown on the right.

   auth key blocks                    AES input blocks
   CEBE321F6FF7716B6FD4AB49AF256A15   0EC675AD498AFEEAB6960B3AABE60000
   6D38BAA4                           0EC675AD498AFEEAB6960B3AABE60001
 
   auth key: CEBE321F6FF7716B6FD4AB49AF256A156D38BAA4

Notes:

The RFC specifies a 160 bit, 20-octet session authentication key throughout (section 5.2, Section 8.2, Section 9.2 and Section 9.5), but the vectors and derivation in section B.3 specifies the need for a 94-octet session key, and includes test vectors as such.
--VERIFIER NOTES--
This test vector does not contradict any other section. It explicitly says that it is a test vector for "an authentication function which requires a 94-octet session authentication key".

In rejecting this Errata report I note that the reported text is not an error, but a deliberate decision of the authors and working group.

RFC 3720, "Internet Small Computer Systems Interface (iSCSI)", April 2004

Note: This RFC has been obsoleted by RFC 7143

Note: This RFC has been updated by RFC 3980, RFC 4850, RFC 5048, RFC 7146

Source of RFC: ips (tsv)

Errata ID: 4332
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Powell
Date Reported: 2015-04-11
Rejected by: Martin Stiemerling
Date Rejected: 2015-04-14

Section B.4. says:

32 bytes of ones:

It should say:

32 bytes of 255s:

Notes:

The test data is correct but the description is wrong.
--VERIFIER NOTES--
This is purely editorial and on the edge of personal preference, if the "ones" are described based on base 2 notation or base 10 notation.

RFC 3728, "Definitions of Managed Objects for Very High Speed Digital Subscriber Lines (VDSL)", February 2004

Source of RFC: adslmib (ops)

Errata ID: 1788
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Smadar Tauber
Date Reported: 2009-05-24
Rejected by: Dan Romascanu
Date Rejected: 2009-06-03

Section Global says:

Example:
   vdslPhysCurrSnrMgn OBJECT-TYPE
       SYNTAX       Integer32 (-127..127)
       UNITS        "0.25dBm"
       MAX-ACCESS   read-only
       STATUS       current
       DESCRIPTION
           "Noise Margin as seen by this Vtu with respect to its
           received signal in 0.25dB.  The effective range is
           -31.75 to +31.75 dB."
       REFERENCE    "T1E1.4/2000-009R3, Part 1, common spec"
        ::= { vdslPhysEntry 5 }

   vdslPhysCurrAtn OBJECT-TYPE
       SYNTAX       Gauge32 (0..255)
       UNITS        "0.25dBm"
       MAX-ACCESS   read-only
       STATUS       current
       DESCRIPTION
           "Measured difference in the total power transmitted by
           the peer Vtu and the total power received by this Vtu.
           The effective range is 0 to +63.75 dB."

It should say:

UNITS statement (dBm) does not match units appearing in DESCRIPTION text (dB).

I think 'dB' are the right units for the objects above, but one can check that. Anyway, it is clear that there should not be the existing mismatch.

Same problem for more MIB objects in the RFC.


  

Notes:

--VERIFIER NOTES--
According to the discussions on the WG list, a new Errata report will be submitted including the complete list of objects affected by this change request.

RFC 3756, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", May 2004

Source of RFC: send (int)

Errata ID: 1643
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Shiang-Ming Huang
Date Reported: 2008-12-23
Rejected by: Brian Haberman
Date Rejected: 2012-05-04

Section 1.1 says:

   Conversely, the term
|   "trust relationship" denotes a mutual a priori relationship between
   the involved organizations or parties where the parties believe that
   the other parties will behave correctly even in the future.

It should say:

   Conversely, the term
|   "trust relationship" denotes a mutual priori relationship between
   the involved organizations or parties where the parties believe that
   the other parties will behave correctly even in the future.

Notes:

--VERIFIER NOTES--
The terminology "a priori" is correct. It defines a relationship that exists prior to their interaction.

RFC 3782, "The NewReno Modification to TCP's Fast Recovery Algorithm", April 2004

Note: This RFC has been obsoleted by RFC 6582

Source of RFC: tsvwg (wit)

Errata ID: 6789
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Clive Bloom
Date Reported: 2021-12-19
Rejected by: Martin Duke
Date Rejected: 2022-05-13

Section 6.1 says:

If the Cumulative Acknowledgement field didn’t cover more than
"recover", check to see if the congestion window is greater than
SMSS bytes and the difference between highest_ack and
prev_highest_ack is at most 4*SMSS bytes. If true, duplicate
ACKs indicate a lost segment (proceed to Step 1A in Section 3).
Otherwise, duplicate ACKs likely result from unnecessary
retransmissions (proceed to Step 1B in Section 3).

It should say:

If the Cumulative Acknowledgement field didn’t cover more than
"recover", check to see if the congestion window is greater than
SMSS bytes and the difference between highest_ack and
prev_highest_ack is at most 3*SMSS bytes. If true, duplicate
ACKs indicate a lost segment (proceed to Step 1A in Section 3).
Otherwise, duplicate ACKs likely result from unnecessary
retransmissions (proceed to Step 1B in Section 3).

Notes:

RFC3782 references to Gur03 and GF04 papers as to the initial sources
of the heuristics both ACK-based and Timestamp-based. Neither of those
papers nor Gur03 nor GF04 defines difference between highest_ack and previous_highest_ack
of at least 4*SMSS bytes upon receiving the third duplicate ACK as an indication
of droped retransmitted segment. Instead, section III of GF04 says:

"The acknowledgment heuristic is based on an observation that if the
TCP sender unnecessarily retransmits at least three adjacent packets,
there will be a jump by at least four segments in a cumulative
acknowledgment field. The sender will have correctly retransmitted at least
one packet, to advance the cumulative acknowledgment field, and
unnecessarily retransmitted at least three more to result in three duplicate
acknowledgments. Following the advancement of the cumulative acknowledgment
field, the sender stores the value of the previous cumulative acknowledgment
as prev_highest_ack and stores the latest cumulative acknowledgment as
highest_ack. Upon receiving the third duplicate acknowledgment,
the sender invokes a Fast Retransmit if its congestion window is greater
than one MSS (Maximum Segment Size), and the difference between highest_ack
and prev_highest_ack is at most three MSS."

According to GF04 if TCP sender in absence of any droped acknowledgments upon receiving
the third duplicate ACK has difference between highest_ack and prev_highest ack values
of at most/i.e. no more than 3*SMSS bytes then this is explicite indication of droped retransmitted
segment and leads TCP sender to invoke Fast Retransmit, but current description of ACK-based
heuristic in RFC3782 section 6.1 in part of: "if the congestion window is greater than
SMSS bytes and the difference between highest_ack and
prev_highest_ack is at most 4*SMSS bytes. If true, duplicate
ACKs indicate a lost segment (proceed to Step 1A in Section 3)", makes TCP sender to treat
difference between highest_ack and prev_highest_ack of 4SMSS bytes upon receiving 3rd
duplicate ACK as indication of lost retransmitted segment but again according to GF04 this is NOT so,
and makes TCP sender to invoke Fast Retransmit when in fact those three duplicate acknowledgments
indicate unnecessarily retransmitted segments and have in their acknowledgment fields sequence
number which receiver expects to receive next but which sender has NOT sent yet, so Fast Retransmit
has no point in this case.
--VERIFIER NOTES--
RFC 3782 has been obsoleted by RFC 6582.

RFC 3798, "Message Disposition Notification", May 2004

Note: This RFC has been obsoleted by RFC 8098

Note: This RFC has been updated by RFC 5337, RFC 6533

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 691
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2004-10-20
Rejected by: Peter Saint-Andre
Date Rejected: 2011-11-12

Appendix A

(1) disposition types
=====================
The dispositions "denied" and "failed" were removed from the
document reflecting the lack of implementation or usage ...


Now, the syntax production "disposition-type" in section 3.2.6. (on
page 14) and section 7. (on mid-page 22) has been changed to read:

    disposition-type = "displayed" / "deleted"

This means that the RFC 2298 disposition types "dispatched" and
"processed" have been removed from the syntax definitions as well!

Thus, either Appendix A lacks mentioning these removals  OR  these
items should not have been removed from the syntax definitions.

Nevertheless, all these disposition types removed from the syntax are
mentioned at many places throughout RFC 3798:

o  "dispatched" :

   - section 3.2.6. , final paragraph of the section on page 16
   - section 4. , third-to-last bullet on page 17
   - section 4. , first bullet on page 18

o  "processed" :

   - section 4. , third-to-last bullet on page 17
   - section 4. , first bullet on page 18
   - section 5. , 4th paragraph on page 18

o  "denied" :

   - section 2.1. , bottom of page 4
   - section 2.1. , end of 3rd paragraph on page 5
   - section 4. , third-to-last bullet on page 17
   - section 4. , first bullet on page 18
   - section 6.2. , end of first paragraph on page 19

o  "failed" :

   - section 2.2. , middle of second-to-last paragraph on page 6
   - section 2.2. , middle of second paragraph on page 7 (twice)
   - section 2.2. , third paragraph on page 7 (twice)
   - section 3.2.7. , in 2nd text line, on page 16
                    (mis-spelled "failure" there)
   - section 4. , third-to-last bullet on page 17
   - section 4. , first bullet on page 18

All these places in the text deal with the issue/sending/generation
of MDNs with the named deprecated disposition types (it would be
acceptable to talk about what to do with *received* such disposition
types for backwards compatibility with RFC 2298) !

It should say:

[not submitted]

Notes:

from pending
--VERIFIER NOTES--
Clearly this document is a mess. The solution is to publish an RFC that cleans up the mess (and verifies that there is indeed consensus to remove the "denied" and "failed" dispositions), not to handle this via the errata process.

RFC 3811, "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management", June 2004

Note: This RFC has been updated by RFC 7274

Source of RFC: mpls (rtg)

Errata ID: 1842
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Vishwas Manral
Date Reported: 2009-08-27
Rejected by: Adrian Farrel
Date Rejected: 2012-06-02

Section 3 says:

       MplsExtendedTunnelId ::= TEXTUAL-CONVENTION
          STATUS        current
          DESCRIPTION
             "A unique identifier for an MPLS Tunnel.  This may
              represent an IPv4 address of the ingress or egress
              LSR for the tunnel.  This value is derived from the
              Extended Tunnel Id in RSVP or the Ingress Router ID
              for CR-LDP."
          REFERENCE
             "RSVP-TE: Extensions to RSVP for LSP Tunnels,
              [RFC3209].

              Constraint-Based LSP Setup using LDP, [RFC3212]."
          SYNTAX  Unsigned32(0..4294967295)

It should say:

       MplsExtendedTunnelId ::= TEXTUAL-CONVENTION
          STATUS        current
          DESCRIPTION
             "A unique identifier for an MPLS Tunnel.  This may
              represent an IPv4 address of the ingress or egress
              LSR for the tunnel for an IPv4 network.  For IPv6
              this represents an IPv4 address of the ingress or
              egress LSR for the tunnel for an IPv6 network.
              This value is derived from the
              Extended Tunnel Id in RSVP or the Ingress Router ID
              for CR-LDP."
          REFERENCE
             "RSVP-TE: Extensions to RSVP for LSP Tunnels,
              [RFC3209].

              Constraint-Based LSP Setup using LDP, [RFC3212]."
          SYNTAX  OCTET STRING(SIZE(16))

Notes:

The Syntax is wrong. This change will require the new TC to be used through out the MPLS MIB modules. A MIB http://potaroo.net/ietf/idref/draft-manral-mpls-rfc3811bis/ was written for the purpose.
--VERIFIER NOTES--
Although only a few lines of text are proposed for modification, this change would make a technically un-interoperable change to existing implementations. Therefore it should be handled by discussion in the working group and a new RFC if there is consensus. I am rejecting the erratum.

RFC 3815, "Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)", June 2004

Source of RFC: mpls (rtg)

Errata ID: 227
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Kirkham
Date Reported: 2005-02-13
Rejected by: Adrian Farrel
Date Rejected: 2010-08-23

MplsFecEntry is defined as:

      MplsFecEntry ::= SEQUENCE {
          mplsFecIndex               IndexInteger,
          mplsFecType                INTEGER,
          mplsFecAddrType            InetAddressType,
          mplsFecAddr                InetAddress,
          mplsFecAddrPrefixLength    InetAddressPrefixLength,
          mplsFecStorageType         StorageType,
          mplsFecRowStatus           RowStatus
      }

It should say:

      MplsFecEntry ::= SEQUENCE {
          mplsFecIndex               IndexInteger,
          mplsFecType                INTEGER,
          mplsFecAddrPrefixLength    InetAddressPrefixLength,
          mplsFecAddrType            InetAddressType,
          mplsFecAddr                InetAddress,
          mplsFecStorageType         StorageType,
          mplsFecRowStatus           RowStatus
      }

Notes:

Because the OID assignments are:

mplsFecAddrPrefixLength - mplsFecEntry.3
mplsFecAddrType - mplsFecEntry.4
mplsFecAddr - mplsFecEntry.5
--VERIFIER NOTES--
After discussion with an author (Joan Cucchiara), a MIB Doctor (Mike Heard), and an MPLS MIB expert (Tom Nadeau), we conclude that no change is required.

In the words of Mike Heard...

While this may be a poor practice, I don't think it actually
violates RFC 2578. As far as I can see, the only thing it
actually says is this:

7.10. Mapping of the OBJECT-TYPE value
...
(2) If the object corresponds to a conceptual row, then at least one
assignment, one for each column in the conceptual row, is present
beneath that object. The administratively assigned name for each
column is derived by appending a unique, positive sub-identifier to
the administratively assigned name for the conceptual row.

which does not put any ordering constraints on the sub-identifiers.

Unless there is something that I have missed, it seems to me that
this is not actually an erratum.

RFC 3830, "MIKEY: Multimedia Internet KEYing", August 2004

Note: This RFC has been updated by RFC 4738, RFC 6309

Source of RFC: msec (sec)

Errata ID: 4638
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Christopher Dearlove
Date Reported: 2016-03-15
Rejected by: Stephen Farrell
Date Rejected: 2016-03-15

Section 4.2.8 says:

   The timestamp is as defined in NTP [NTP], i.e., a 64-bit number in
   seconds relative to 0h on 1 January 1900.  An implementation MUST be
   aware of (and take into account) the fact that the counter will
   overflow approximately every 136th year.  It is RECOMMENDED that the
   time always be specified in UTC.

It should say:

   The timestamp is as defined in NTP [NTP], i.e., a 64-bit number in
   seconds relative to 0h on 1 January 1900.  It is RECOMMENDED that the
   time always be specified in UTC.

Notes:

A 32-bt number of seconds overflows in about 136.1 years. A 64-bit number of seconds will, for all practical purposes, not overflow.

(The use in Section 4.2.3 is of a 64 bit number, not a 32 bit number, so 64 bits is correct.)
--VERIFIER NOTES--
Only 32 bits of the 64 count seconds. That's clear from the referenced NTP spec.

RFC 3862, "Common Presence and Instant Messaging (CPIM): Message Format", August 2004

Source of RFC: impp (app)

Errata ID: 4065
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sergio Garcia
Date Reported: 2014-07-28
Rejected by: Barry Leiba
Date Rejected: 2014-07-28

Section 4.1 says:

   Examples:

      From: Winnie the Pooh <im:pooh@100akerwood.com>

      From: <im:tigger@100akerwood.com>

It should say:

   Examples:

      From: "Winnie the Pooh" <im:pooh@100akerwood.com>

      From: <im:tigger@100akerwood.com>



Also there are other From and To headers examples in
 which name should be double quoted:

      h: From: "MR SANDERS" <im:piglet@100akerwood.com>
      h: To: "Depressed Donkey" <im:eeyore@100akerwood.com>

Notes:

From-header = "From" ": " [ Formal-name ] "<" URI ">"

Examples:

From: Winnie the Pooh <im:pooh@100akerwood.com>

But

Formal-name = 1*( Token SP ) / String
Token = 1*TOKENCHAR
String = DQUOTE *( Str-char / Escape ) DQUOTE
NAMECHAR = %x21 / %x23-27 / %x2a-2b / %x2d
/ %x5e-60 / %x7c / %x7e
/ ALPHA / DIGIT

; Any UCS char except CTLs or SEPARATORS:
TOKENCHAR = NAMECHAR / "." / UCS-highç

So Winnie the Pooh is not a TOKEN but a STRING and should be quoted:

From: "Winnie the Pooh" <im:pooh@100akerwood.com>
--VERIFIER NOTES--
The reporter missed seeing the "1*" in the ABNF for Formal-name; the construct can actually contain multiple space-delimited Tokens, and those names are all valid.

RFC 3877, "Alarm Management Information Base (MIB)", September 2004

Source of RFC: disman (ops)

Errata ID: 1652
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Brian Bidulock
Date Reported: 2009-01-13
Rejected by: Dan Romascanu
Date Rejected: 2010-05-11

Section 5.4 says:

alarmModelState -> ituAlarmPerceivedSeverity
       1        ->         clear (1)
       2        ->         indeterminate (2)
       3        ->         warning (6)
       4        ->         minor (5)
       5        ->         major (4)
       6        ->         critical (3)

It should say:

alarmModelState -> ituAlarmPerceivedSeverity
       1        ->         clear (1)
       2        ->         warning (6)
       3        ->         indeterminate (2)
       4        ->         minor (5)
       5        ->         major (4)
       6        ->         critical (3)

Notes:

alarmModelState requires that the states be defined from less severe to more severe; however, under ITU-T PerceivedSeverity from ITU-T Rec. X.721 | ISO/IEC 10165-2 "indeterminate" is more severe than "warning". This change corrects the order to match the requirement for order of severity for alarmModelState.
--VERIFIER NOTES--
While the discrepancy between the documents is unfortunate, there is not a technical requirement for the enumeration values to be identical, nor is there a technical requirement for the labels to be identical, even though there is obviously considerable documentation value in avoiding gratuitous differences.

What *is* technically important is that the MIB be able to uniquely represent all the cases from M.3100, and it accomplishes that goal.

In a future version of the document we can add an informative note alerting implementors to the discrepancies in numbering and spelling, so their implementations can include appropriate mapping functions to avoid losing information.

RFC 3905, "A Template for IETF Patent Disclosures and Licensing Declarations", September 2004

Source of RFC: ipr (gen)

Errata ID: 1545
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2008-10-08
Rejected by: RFC Editor
Date Rejected: 2009-02-10

Section 2 says:

Department:

It should say:

Organization:

Notes:

Searching for IPR statements made by a particular organization is more useful than seaching for a department name within an undisclosed organization.

This erratum was rejected because one of the authors (Valerie See) states:
I would (respectfully) disagree with the proposed edit. As I recall, when we authored this (I say "we" in the sense of the co-authors of the RFC), the reason we went with a "department" was to narrow things down within large companies and/or organizations. If you look at a sampling of the IPR disclosures filed with the IETF (admittedly, only from the perspective of my personal opinion), it seems to be generally true that the "patent holder/applicant" field has made the question of "who" (as in "organization") pretty clear.

Particularly since this is only an informational RFC, stating that the use of the template it contains is optional, and given the history, I don't feel that making the fix for the errata is the right thing to do.

RFC 3927, "Dynamic Configuration of IPv4 Link-Local Addresses", May 2005

Source of RFC: zeroconf (int)

Errata ID: 6293
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Markus Hofmann
Date Reported: 2020-09-22
Rejected by: Erik Kline
Date Rejected: 2020-12-09

Section 7 says:

7.  Router Considerations

   A router MUST NOT forward a packet with an IPv4 Link-Local source or
   destination address, irrespective of the router's default route
   configuration or routes obtained from dynamic routing protocols.

   A router which receives a packet with an IPv4 Link-Local source or
   destination address MUST NOT forward the packet.  This prevents
   forwarding of packets back onto the network segment from which they
   originated, or to any other segment.

It should say:

7.  Router Considerations

   A router MUST NOT forward a packet with an IPv4 Link-Local 
   destination address, irrespective of the router's default route
   configuration or routes obtained from dynamic routing protocols.

   A router which receives a packet with an IPv4 Link-Local 
   destination address MUST NOT forward the packet.  This prevents
   forwarding of packets back onto the network segment from which they
   originated, or to any other segment.

   A router MAY forward a packet with an IPv4 Link-Local source address if 
   the packet is an ICMP unreachable or ICMP time exceeded and the
   destination address is not a link local address.

Notes:

Link-Local IPv4 addressing is these days also often used for router to router link local connections.
Although the scope of the document is related to dynamic configuration of link local it makes statements not to forward packets for routers (not on the link local segment).
Once 169.254 addresses are used on router to router link local interfaces they might send back icmp unreachables for pmtu discovery or ttl expiration. In those cases the source IP might be a 169.254 of the routers link local router to router interface.
--VERIFIER NOTES--
Rejecting, per https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/, as this appears to "[propose] a change to the RFC that should be done by publishing a new RFC that replaces [or updates] the current RFC."

Also, as suggested by Eric Vyncke, consider whether any guidance from RFC 7404 is applicable (by analogy, from IPv6 to IPv4 link-local address usage).

RFC 3931, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", March 2005

Note: This RFC has been updated by RFC 5641

Source of RFC: l2tpext (int)

Errata ID: 2766
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Teco Boot
Date Reported: 2011-04-04
Rejected by: Brian Haberman
Date Rejected: 2012-05-09

Section 4.1.4 says:

   An LCCE MAY fragment a packet before encapsulating it in L2TP.  For
   example, if an IPv4 packet arrives at an LCCE from a Remote System
   that, after encapsulation with its associated framing, L2TP, and IP,
   does not fit in the available path MTU towards its LCCE peer, the
   local LCCE may perform IPv4 fragmentation on the packet before tunnel
   encapsulation. 

It should say:

   An LCCE MAY fragment a packet before encapsulating it in L2TP.  For
   example, if an IPv4 packet with DF=0 arrives at an LCCE from a Remote System
   that, after encapsulation with its associated framing, L2TP, and IP,
   does not fit in the available path MTU towards its LCCE peer, the
   local LCCE may perform IPv4 fragmentation on the packet before tunnel
   encapsulation. 

Notes:

Following RFC 791, IPv4 packets with the DF flag set shall not fragment such packets. RFC 3931 shall not make a precedent for fragmenting IPv4 packets with DF=1.
--VERIFIER NOTES--
The original text uses MAY so it does not mandate fragmentation behavior.

RFC 3947, "Negotiation of NAT-Traversal in the IKE", January 2005

Source of RFC: ipsec (sec)

Errata ID: 4936
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2017-02-16
Rejected by: Paul Wouters
Date Rejected: 2022-04-10

Section 5.2 says:

   The NAT-OA payloads are sent inside the first and second packets of
   Quick Mode.  The initiator MUST send the payloads if it proposes any
   UDP-Encapsulated-Transport mode, and the responder MUST send the
   payload only if it selected UDP-Encapsulated-Transport mode.  It is
   possible that the initiator sends the NAT-OA payload but proposes
   both UDP-Encapsulated transport and tunnel mode.  Then the responder
   selects the UDP-Encapsulated tunnel mode and does not send the NAT-OA
   payload back.

It should say:

   The NAT-OA payloads are sent inside the first and second packets of
   Quick Mode.  The initiator MUST send the payloads if it proposes any
   UDP-Encapsulated mode, and the responder MUST send the
   payload only if it selected UDP-Encapsulated-Transport mode.  It is
   possible that the initiator sends the NAT-OA payload but proposes
   both UDP-Encapsulated transport and tunnel mode.  Then the responder
   selects the UDP-Encapsulated tunnel mode and does not send the NAT-OA
   payload back.

Notes:

--VERIFIER NOTES--
This is an incorrect errata to the RFC3947 (IKEv1 NAT-T negotiation).

It asks to change where initiator MUST send NAT-OA payloads if it proposes any UDP-Encapsulation mode, compared to the proposing EDP-Encapsulated-Transport mode. The original text is correct, we only need to send NAT-OA payloads if UDP-Encapsulated-Transport mode is proposed, it is not required if only UDP-Encapsulated-Tunnel mode is proposed.

RFC 3958, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", January 2005

Note: This RFC has been updated by RFC 8553

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 608
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2007-10-17
Rejected by: Alexey Melnikov
Date Rejected: 2010-04-05

Section 6.5 says:

iana-registered-protocol  = ALPHA *31ALPHANUM

It should say:

Maybe:

iana-registered-protocol  = ALPHA *31ALPHANUM
ALPHANUM =  ALPHA / DIGIT

Notes:

The ALPHANUM production is missing from the grammar (and is not in
RFC 4234 either).

Alexey: this was obsoleted by Erratum # 2106.

--VERIFIER NOTES--
Obsoleted by Erratum # 2106, which fixed this properly.

RFC 3961, "Encryption and Checksum Specifications for Kerberos 5", February 2005

Note: This RFC has been updated by RFC 8429

Source of RFC: krb-wg (sec)

Errata ID: 5522
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Wrong required required checksum mechanism for des-cbc-crc
Date Reported: 2018-10-12
Rejected by: Benjamin Kaduk
Date Rejected: 2018-10-15

Section 6.2.3 says:

                               des-cbc-crc
   --------------------------------------------------------------------
   protocol key format      8 bytes, parity in low bit of each

   specific key structure   copy of original key

   required checksum        rsa-md5-des
   mechanism

It should say:

                               des-cbc-crc
   --------------------------------------------------------------------
   protocol key format      8 bytes, parity in low bit of each

   specific key structure   copy of original key

   required checksum        CRC32
   mechanism

Notes:

des-cbc-crc is using the modified crc32 checksum, its required checksum should be CRC32, constant defined in section 8
--VERIFIER NOTES--
Rejected per submitter request; the required Checksum is a distinct operation, not a subset of the encryption operation.

RFC 3967, "Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level", December 2004

Note: This RFC has been updated by RFC 4897, RFC 8067

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: gen

Errata ID: 201
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-01-00
Rejected by: Russ Housley

Normative references to HMAC in future IETF Standards Track documents should always refer to FIPS-198 instead of RFC 2104.

reading the fresh RFC 3967 (== BCP 97), I found that this memo uses
examples which are well known, but not very appropriate, for the
desired purpose:

(1)
    HMAC [RFC2104]

This algorithm - since almost three years - is a US Federal
Information Processing Standard!

( FIPS PUB 198, issued '2002 March 6' ;
  to download a PDF copy (updated '2002 April 8'), see
  <http://crc.nist.gov/publications/fips/index.html> )

This is an active standard published by a recognized standards body.
Therefore, *Normative References* to HMAC in future IETF Standards
Track documents should always refer to FIPS-198 instead of RFC 2104 !

It should say:

[see above]

Notes:

Remark 1:
FIPS-198 in turn refers to RFC 2104 as a readily available
source document for the algorithm, but gives a detailed,
independent description of the algorithm and its application.

Remark 2:
Expect alternative MAC algorithms like UMAC, TTMAC, EMAC,
and RMAC to get formally standardized soon by various Standards
Bodies. For example, the former three Algorithms are already
(since Feb. 2003) recommended for new applications to be used in
the public administration and economy within the European Union.
This has been the result of the NESSIE project - an open contest
similar to the AES contest of NIST's), see
<http://www.cryptonessie.org/> .

from pending
--VERIFIER NOTES--
2021-10-06: moved from Held for Document Update to Rejected per request from Murray Kucherawy. This erratum was reviewed while working on a bis document.

Errata ID: 706
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-01-03
Rejected by: Russ Housley

Normative references to HMAC in future IETF Standards Track documents should always refer to FIPS-198 instead of RFC 2104.

(2)
    MD5 [RFC1321]

According to the contemporary cryptographic literature, protocols
should now better use SHA-xxx (xxx = [1 / ] 224 / 256 / 384 / 512)
as a cryptographic hashing primitive instead of MD5.

See
- FIPS PUB 180-2, issued '2002 August 1', and amended by
  Change Note 1, issued '2004 February 25', for SHA-224,
and
- RFC 3174 (for SHA-1) and RFC 3874 (for SHA-224) -- based on above.

FIPS 180-2 should be used for Normative References in future IETF
Standards Track documents.

It should say:

[see above]

Notes:

Remark 3:
SHA-1 (as well as MD5) already is no more recommended for new
applications to be used in the public administration and economy
within the European Union, see the URL given in Remark 2 above!

from pending
--VERIFIER NOTES--
2021-10-06: moved from Held for Document Update to Rejected per request from Murray Kucherawy. This erratum was reviewed while working on a bis document.

RFC 3971, "SEcure Neighbor Discovery (SEND)", March 2005

Note: This RFC has been updated by RFC 6494, RFC 6495, RFC 6980

Source of RFC: send (int)

Errata ID: 3535
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-14
Rejected by: Ralph Droms
Date Rejected: 2013-03-10

Section 6.4.1 says:

         A link-local unicast address assigned to the sending interface,
|        or to the unspecified address if no address is assigned to the
         sending interface.

It should say:

         A link-local unicast address assigned to the sending interface,
|        or the unspecified address if no address is assigned to the
         sending interface.

Notes:

spurious word / grammar, and a clarification
--VERIFIER NOTES--
The original text is fine.

RFC 3973, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", January 2005

Note: This RFC has been updated by RFC 8736, RFC 9436

Source of RFC: pim (rtg)

Errata ID: 970
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Doll
Date Reported: 2007-05-16
Rejected by: Adrian Farrel
Date Rejected: 2011-09-04

 

Remark: In Section 4.7.10 it says, the 4th value is "The Rendezvous Point Tree
bit. Set to 0 for PIM-DM. Ignored upon receipt."

It should say:

[not submitted]

Notes:

from pending
--VERIFIER NOTES--
This Erratum is complaining that this RFC defines a bit, but then marks it as outside the scope of this document.

While this is bad practice, it does not break any rules and is not grounds for an Erratum. It might be justifiable e use of the bit if anyone is interested.

Furthermore, the Erratum does not make any specific point or propose and resolution.

Errata ID: 3270
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Joseph Weinstein
Date Reported: 2012-06-28
Rejected by: Adrian Farrel
Date Rejected: 2012-08-22

Section 4.5.1 says:

if StateRefreshCapable(I) == TRUE
         set PT(S,G) to largest active holdtime read from a Prune
         message accepted on I;

It should say:

if StateRefreshCapable(I) == TRUE
         set PT(S,G,I) to largest active holdtime read from a Prune
         message accepted on I;

Notes:

No macro PT(S,G) is defined anywhere in the RFC; the reference appears to be to P(S,G,I).
--VERIFIER NOTES--
Rejected as a duplicate of http://www.rfc-editor.org/errata_search.php?eid=3271

Errata ID: 3286
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Joseph Weinstein
Date Reported: 2012-07-16
Rejected by: Adrian Farrel
Date Rejected: 2012-08-22

Section 4.5 says:

(Additional subection)

It should say:

4.5.3 Receiving State Refresh Messages

When a State Refresh message is received, it may trigger state 
transitions to the upstream state machine and related actions, 
as described in Section 4.4.  It is then forwarded in accordance 
with Section 4.5.1.

Notes:

For clarity and completeness, an additional subsection is required to 4.5 describing the actions to be taken when a state refresh message is received. Since these actions have already been specified in Sections 4.4 and 4.5.1, it should be sufficient to simply refer to these sections. Without this additional subsection, an implementer could easily miss an important step in the processing of received state refresh messages.
--VERIFIER NOTES--
This may be fine and useful, but it does not qualify as Errata because it is
introducing new text and material.

If the WG feels strongly about this, it can be brought forward as a small
Informational I-D or included in an update of this RFC.

RFC 3977, "Network News Transfer Protocol (NNTP)", October 2006

Note: This RFC has been updated by RFC 6048

Source of RFC: nntpext (app)

Errata ID: 1521
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2008-09-23
Rejected by: Lisa Dusseault
Date Rejected: 2008-09-29

Section 3.4.1 says:

Except as an effect of the MODE READER command (Section 5.3) on a
mode-switching server, once a server advertises either or both of the
IHAVE or READER capabilities, it MUST continue to advertise them for
the entire session.

It should say:

Except as an effect of the MODE READER command (Section 5.3) on a
mode-switching server, once a server advertises either or both of the
IHAVE or READER capabilities, it SHOULD continue to advertise them for
the entire session.

Notes:

This condition should not be treated as a MUST but as a SHOULD.
Indeed, we can have the following case (amongst others):
* a news server connects to another one in transit mode;
* IHAVE is advertised;
* the news server authenticates via AUTHINFO (an NNTP
extension defined in RFC 4643);
* it is now authorized to only stream articles, thus IHAVE
is no longer available, replaced with STREAMING (an NNTP
extension defined in RFC 4644).

RFC 3977 should not prevent such a case from happening.
Otherwise, it would compel a news server to advertise IHAVE
even though that command is not available to the user.
The same remark also applies to the READER capability.
--VERIFIER NOTES--
This is a request to change the protocol, not an errata. Changes like this need to go through a new RFC.

Errata ID: 1523
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2008-09-23
Rejected by: Lisa Dusseault
Date Rejected: 2008-09-29

Section 5.3.3 says:

Example of use of the MODE READER command on a mode-switching server:

    [C] CAPABILITIES
    [S] 101 Capability list:
    [S] VERSION 2
    [S] IHAVE
    [S] MODE-READER
    [S] .
    [C] MODE READER
    [S] 200 Reader mode, posting permitted
    [C] CAPABILITIES
    [S] 101 Capability list:
    [S] VERSION 2
    [S] READER
    [S] NEWNEWS
    [S] LIST ACTIVE NEWSGROUPS
    [S] STARTTLS
    [S] .

In this case, the server offers (but does not require) TLS privacy in
its reading mode but not in its transit mode.

It should say:

Example of use of the MODE READER command on a mode-switching server:

  [C] CAPABILITIES
  [S] 101 Capability list:
  [S] VERSION 2
  [S] IHAVE
  [S] MODE-READER
  [S] .
  [C] MODE READER
  [S] 200 Reader mode, posting permitted
  [C] CAPABILITIES
  [S] 101 Capability list:
  [S] VERSION 2
  [S] READER
  [S] NEWNEWS
  [S] LIST ACTIVE NEWSGROUPS
  [S] STARTTLS
  [S] .

In this case, the server offers (but does not require) TLS privacy in
its reading mode but not in its transit mode.  Despite the 200
response code, the POST capability is not advertised, indicating that
the POST command is not yet available but may become available later
(presumably after a TLS negotiation and possibly authentication).
This example shows a case where the 200 response code cannot be as
accurate or fine-grained as the CAPABILITIES response.

Notes:

This precision should be added because of the comment "Reader mode, posting permitted". It makes it clearer and incidentally provides an interesting example regarding the use of the 200 response code.
--VERIFIER NOTES--
This is a request to change the document, not an erratum.

--RFC EDITOR NOTE--
2009-11-27: The Corrected Text was updated per a request from Julien Élie.

Errata ID: 1526
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2008-09-24
Rejected by: Lisa Dusseault
Date Rejected: 2009-11-23

Section 9.2 says:

mode-reader-command = "MODE" WS "READER"

It should say:

mode-command = "MODE" WS mode-variant
mode-variant = keyword

Notes:

Even though the ABNF syntax directly treats MODE READER as a command, MODE is
a base command and READER is a variant of this base command.
Therefore, when the keyword is an invalid mode, the 501 response code is sent:

[C] MODE UNKNOWN
[S] 501 Unknown MODE variant

--VERIFIER NOTES--
the errata contributor asked me to reject it.

Errata ID: 1707
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2009-03-05
Rejected by: Lisa Dusseault
Date Rejected: 2010-01-19

Section 6.1.1.2 says:

o  The high water mark will be one less than the low water mark, and
 the estimated article count will be zero.  Servers SHOULD use this
 method to show an empty group.  This is the only time that the
 high water mark can be less than the low water mark.

It should say:

o  The low water mark will be one more than the high water mark, and
 the estimated article count will be zero.  Servers SHOULD use this
 method to show an empty group.  This is the only time that the
 high water mark can be less than the low water mark.

Notes:

The difference in wording is subtle. The low water mark is one more than
the high water mark (that is to say that the low water mark has increased,
and the high water mark has not decreased). It will permit the following
article arrival to be handled by incrementing the high water mark and
leaving the low water mark unchanged.

To be more precise, if at a given time we have only one article in misc.test
and the following answer to a GROUP command:

[C] GROUP misc.test
[S] 211 1 12 12 misc.test

After cancelling this article, the same GROUP command SHOULD give:

[C] GROUP misc.test
[S] 211 0 13 12 misc.test


Besides, RFC 3977 also mentions in the same section:

The client may make use of the low water mark to
remove all remembered information about articles with lower numbers,
as these will never recur. This includes the situation when the high
water mark is one less than the low water mark.

It should be read as "when the low water mark is one more than the high
water mark". The answer to the previous GROUP command is not
"211 0 12 11 misc.test". Otherwise, a news client may still wrongly
consider that the article whose number is 12 is still present whereas
it could remove it if the low water mark was set to 13.

--VERIFIER NOTES--
[updated 2012-05-15 by Barry Leiba]

The high water mark is one less than the low water mark for empty
newsgroups. A major reason for doing it this way was to deal with
clusters of servers. If they're not perfectly synchronized, then
a cancel might be visible on one and not another. So if you connect
to the second one, it looks as if the article has been reinstated.
Wording it like this meant we didn't need special treatment of such
clusters. The low water mark cannot decrease.

RFC 3986, "Uniform Resource Identifier (URI): Generic Syntax", January 2005

Note: This RFC has been updated by RFC 6874, RFC 7320, RFC 8820

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 3330
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: David Sheets
Date Reported: 2012-08-29
Rejected by: Barry Leiba
Date Rejected: 2012-09-04

Section Appendix A says:

fragment      = *( pchar / "/" / "?" )

It should say:

fragment      = *( pchar / "/" / "?" / "#" )

Notes:

Appendix B's regex doesn't fail with this correction. Additionally, this gives freedom to media type designers. Specifically, the ((path?),(query?),(fragment?)) subsyntax could be reused in hypermedia type design as the "?" delimiter transitions path => query and the "#" delimiter transitions query => fragment. It also follows the pattern:
path = *( pchar / "/" )
query = *( pchar / "/" / "?" )
fragment = *( pchar / "/" / "?" / "#" )
--VERIFIER NOTES--
This is something that should be looked at further, but it is not an error in the spec and is unlikely to be a direct change we'd make in a revision of the spec.

Some applications at the time the specification was written parsed the fragment from left to right, and others parsed from right to left, which means they would get different results if "#" were allowed inside of a fragment. That's why it was not allowed in the ABNF. It's possible that situation has improved in the years since, but it would be difficult to test so many implementations. Deciding the right way to handle this goes beyond what can be handled by an erratum.

Errata ID: 4293
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Cesar Crusius
Date Reported: 2015-03-07
Rejected by: Barry Leiba
Date Rejected: 2015-03-07

Section Appendix B says:

^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?

It should say:

^(([^:/?#]+):)(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?

Notes:

The regular expression makes the scheme part optional, but both the ABNF in Appendix A and the text in Section 3 state that the scheme is in fact required.
--VERIFIER NOTES--
The context is that this is for parsing references:

The following line is the regular expression for breaking-down a
well-formed URI reference into its components.

The ABNF makes it clear that the scheme is, in fact, NOT required for URI references (see the ABNF for the "relative-ref" production).

Errata ID: 4393
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Steven Liekens
Date Reported: 2015-06-15
Rejected by: Barry Leiba
Date Rejected: 2015-06-15

Section 3.2.2 says:

dec-octet   = DIGIT                 ; 0-9
            / %x31-39 DIGIT         ; 10-99
            / "1" 2DIGIT            ; 100-199
            / "2" %x30-34 DIGIT     ; 200-249
            / "25" %x30-35          ; 250-255

It should say:

dec-octet = "25" %x30-35          ; 250-255
          / "2" %x30-34 DIGIT     ; 200-249
          / "1" 2DIGIT            ; 100-199
          / %x31-39 DIGIT         ; 10-99
          / DIGIT                 ; 0-9

Notes:

The 'dec-octet' rule requires more than 1 lookahead symbol.

Example value: 127

Parsers that implement a first-match-wins strategy will erroneously match 127 as ( DIGIT ), followed by two unexpected symbols.

Parsers that implement a first-match-wins strategy with the corrected grammar will correctly match 127 as ( "1" 2DIGIT ).
--VERIFIER NOTES--
Yes, except that ABNF defined in RFC 5234 is designed to describe what's valid to produce -- it's not designed as the definitive source for building a perfect parser. In particular, the order of the alternatives is not significant in ABNF, so reordering them is irrelevant.

In fact, the ABNF here is more specific than it often is. In other RFCs it will say things like
xyz = 0 / %x31-39 *2DIGIT ; valid values are 0-255
...and just let the comment restrict the maximum value.

Errata ID: 4394
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Steven Liekens
Date Reported: 2015-06-15
Rejected by: Barry Leiba
Date Rejected: 2015-06-15

Section 3.2.2 says:

IPv6address =                            6( h16 ":" ) ls32
                 /                       "::" 5( h16 ":" ) ls32
                 / [               h16 ] "::" 4( h16 ":" ) ls32
                 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
                 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
                 / [ *3( h16 ":" ) h16 ] "::"    h16 ":"   ls32
                 / [ *4( h16 ":" ) h16 ] "::"              ls32
                 / [ *5( h16 ":" ) h16 ] "::"              h16
                 / [ *6( h16 ":" ) h16 ] "::"

It should say:

IPv6address = (                6( h16 ":" ) ls32 ) 
            / (           "::" 5( h16 ":" ) ls32 )
            / ( [   h16 ] "::" 4( h16 ":" ) ls32 )
            / ( [ h16-2 ] "::" 3( h16 ":" ) ls32 )
            / ( [ h16-3 ] "::" 2( h16 ":" ) ls32 )
            / ( [ h16-4 ] "::"    h16 ":"   ls32 )
            / ( [ h16-5 ] "::"              ls32 )
            / ( [ h16-6 ] "::"               h16 )
            / ( [ h16-7 ] "::"                   )

h16-7       = ( *6( h16 ":" ) h16 ) / h16-6

h16-6       = ( *5( h16 ":" ) h16 ) / h16-5

h16-5       = ( *4( h16 ":" ) h16 ) / h16-4

h16-4       = ( *3( h16 ":" ) h16 ) / h16-3

h16-3       = ( *2( h16 ":" ) h16 ) / h16-2

h16-2       = (   [ h16 ":" ] h16 ) / h16

Notes:

The 'IPv6address' rule requires more than 1 lookahead symbol.

Example value: 1::

Parsers that implement a first-match-wins strategy will erroneously match 1:: as ( h16 ":" ), followed by an unexpected symbol.

Parsers that implement a first-match-wins strategy with the corrected grammar will correctly match 1:: as ( h16 "::" ).
--VERIFIER NOTES--
As with errata report 4393, this is trying to use ABNF beyond what it's meant for.

Errata ID: 7019
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Tim McSweeney
Date Reported: 2022-07-10
Rejected by: Francesca Palombini
Date Rejected: 2022-07-12

Section B says:

^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?

It should say:

^(([^:/?#]+):#)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?

Notes:

Added the missing '#" delimiter.
--VERIFIER NOTES--
In rejecting this Errata report I note that the reported error is not an error, but a deliberate decision of the authors and working group. The change, therefore, if it is to be applied needs to be achieved through a consensus document and definitely not via an errata report.

Errata ID: 1783
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christopher Yeleighton
Date Reported: 2009-05-15
Rejected by: Peter Saint-Andre
Date Rejected: 2010-09-15

Section 3.1. says:

Advice for designers of new URI schemes can be found in [RFC2718].

It should say:

Advice for designers of new URL schemes can be found in [RFC2718].

Notes:

[RFC2718] does not contain advice for designers of new URN schemes; it is applies to URL schemes only and it is titled accordingly.
The information as published is misleading.
--VERIFIER NOTES--
Given that RFC 4395 ("Guidelines and Registration Procedures for New URI Schemes") obsoletes the referenced RFC 2718 ("Guidelines for new URL Schemes"), this erratum is best considered in error.

Errata ID: 2717
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Winfred Qin
Date Reported: 2011-02-14
Rejected by: Peter Saint-Andre
Date Rejected: 2011-05-16

Section 3 says:

      hier-part   = "//" authority path-abempty
                  / path-absolute
                  / path-rootless
                  / path-empty

It should say:

      hier-part   = "//" authority path-abempty
                  / path-absolute
                  / path-noscheme
                  / path-rootless
                  / path-empty

Notes:

There are four ABNF rules for path, but the following words says:

'These restrictions result in five different ABNF rules for a path (Section 3.3)'

And in section 3.3, there are five rules.
--VERIFIER NOTES--
PSA: There is no error here, because the hierarchical part excludes
paths that are not preceded by "//", whereas the path rule includes
paths that are not preceded by "//" (thus five rules for "path" but
only four rules for "hier-part").

RFC 3998, "Internet Printing Protocol (IPP): Job and Printer Administrative Operations", March 2005

Source of RFC: ipp (app)

Errata ID: 6687
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Sweet
Date Reported: 2021-09-16
Rejected by: Francesca Palombini
Date Rejected: 2021-09-17

Section 4.1 says:

This OPTIONAL operation is a create job operation that allows a
client to re-process a copy of a job that had been retained in the
queue after processing was completed, canceled, or aborted (see
[RFC2911], section 4.3.7.2).  This operation is the same as the

It should say:

This DEPRECATED operation is a create job operation that allows a
client to re-process a copy of a job that had been retained in the
queue after processing was completed, canceled, or aborted (see
[RFC2911], section 4.3.7.2).  This operation is the same as the

Notes:

This operation has been deprecated by the IPP workgroup. The recommended replacement is the Resubmit-Job operation defined in PWG 5100.11.
--VERIFIER NOTES--
This sort of change to update for events since the time of publication is not appropriate for an erratum; errata are intended solely to indicate errors in a document that were errors at the time of publication. A revision of the document or a new document with an "Updates:" relationship would be more appropriate ways to indicate that the situation has changed.

RFC 4005, "Diameter Network Access Server Application", August 2005

Note: This RFC has been obsoleted by RFC 7155

Source of RFC: aaa (ops)

Errata ID: 1946
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Avi Lior
Date Reported: 2009-11-25
Rejected by: Dan Romascanu
Date Rejected: 2010-11-02

Section 9.2 says:

If the Accounting-Input-Octets, Accounting-Input-Packets,
   Accounting-Output-Octets, or Accounting-Output-Packets AVPs are
   present, they must be translated to the corresponding RADIUS
   attributes.  If the value of the Diameter AVPs do not fit
   within a 32-bit RADIUS attribute, the RADIUS Acct-Input-
   Gigawords and Acct-Output-Gigawords must be used.

It should say:

If the Accounting-Input-Octets, 
   Accounting-Output-Octets,  AVPs are
   present, they must be translated to the corresponding RADIUS
   attributes.  If the value of the Diameter AVPs do not fit
   within a 32-bit RADIUS attribute, the RADIUS Acct-Input-
   Gigawords and Acct-Output-Gigawords must be used.

Notes:

The last sentence of the original text causes confusion because according to RFC2869, the Acct-Input/Output-Gigawords are only overflows for the Acct-Input/Output-Octet attributes.
THE ABOVE CORRECTION BASICALLY DOES NOT PROVIDE FOR OVERFLOW FOR THE PACKET COUNTERS.
--VERIFIER NOTES--
The working group discussion on this item led to the following text change being recommended:

If the Accounting-Input-Octets, Accounting-Input-Packets, Accounting-Output-Octets, or Accounting-Output-Packets AVPs are present, they SHOULD be translated to the corresponding RADIUS attributes. However, if the value of the Accounting-Input-Octets AVP or Accounting-Output-Octets AVP does not fit within a 32-bit RADIUS attribute, the RADIUS Acct-Input-Gigawords and Acct-Output-Gigawords Attributes must be used.

Care must be taken when interworking Diameter with RADIUS due to the fact that there is no attribute available in RADIUS to record overflows in packet counters. One remedy that can be used is to limit the session time such that packet counter do not overflow. Another remedy would be to ignore the packet counters altogether and just rely on the octet counters.

RFC 4006, "Diameter Credit-Control Application", August 2005

Note: This RFC has been obsoleted by RFC 8506

Source of RFC: aaa (ops)

Errata ID: 4892
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: dengzhenjie
Date Reported: 2016-12-19
Rejected by: Benoit Claise
Date Rejected: 2017-01-03

Section 7 says:

   | PendingU | CC update answer received     | Terminate   | Idle     |
   |          | with result code equal to     | end user's  |          |
   |          | CREDIT_CONTROL_NOT_APPLICABLE | service     |          |

It should say:

   | PendingU | CC update answer received     | Grant     |   Idle   |
   |          | with result code equal to     | service to|          |
   |          | CREDIT_CONTROL_NOT_APPLICABLE | end user  |          |

Notes:

Note that in Section 9, It said:
when the result code in the CCA is DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE 4011, it indicates that the credit-control server determines that the service can be granted to the end user but that no further credit-control is needed for the service (e.g., service is free of charge).
--VERIFIER NOTES--
This is not an erratum against 4006 but a proposed change in the draft RFC4006bis (https://tools.ietf.org/html/draft-ietf-dime-rfc4006bis-00).

The original text quoted below is not in the RFC4006 but in the draft.

Hence this should be discussed on the dime mailing list.

Errata ID: 4890
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: dengzhenjie
Date Reported: 2016-12-16
Rejected by: Benoit Claise
Date Rejected: 2017-01-03

Section 7 says:

   | PendingE | Failure to send; requested     | Store      | Idle     |
   |          | action DIRECT_DEBITING; DDFH   | request    |          |
   |          | equal to TERMINATE_OR_BUFFER   | with       |          |
   |          |                                | T-flag     |          |
   | PendingE | Failure to send; requested     | Store      | Idle     |
   |          | action DIRECT_DEBITING; DDFH   | request    |          |
   |          | equal to TERMINATE_OR_BUFFER   | with       |          |
   |          |                                | T-flag     |          |

It should say:

   | PendingE | Failure to send; requested     | Store      | Idle     |
   |          | action DIRECT_DEBITING; DDFH   | request    |          |
   |          | equal to TERMINATE_OR_BUFFER   | with       |          |
   |          |                                | T-flag     |          |

Notes:

the state machine in the table of ''client, event based'' is duplicated
--VERIFIER NOTES--
Yes, this is an editorial mistake. but this not related to the RFC4006 but to the current version of the draft https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/, version 00 as of today.

RFC 4034, "Resource Records for the DNS Security Extensions", March 2005

Note: This RFC has been updated by RFC 4470, RFC 6014, RFC 6840, RFC 6944, RFC 9077

Source of RFC: dnsext (int)

Errata ID: 2824
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Edward Lewis
Date Reported: 2011-06-06
Rejected by: Brian Haberman
Date Rejected: 2012-04-30

Section 3.1.3 says:

   The value of the Labels field MUST NOT count either the null (root)
   label that terminates the owner name or the wildcard label (if
   present).

It should say:

   The value of the Labels field MUST NOT count either the null (root)
   label that terminates the owner name or the leftmost label if
   it is a wildcard.

Notes:

In RFC 4035, section 2.2, describing the same count uses this: ... "and not counting the leftmost label if it is a wildcard" to omit the leading wildcard label. (In 4034, the wildcard label is defined as "*" earlier in the same problematic section.)

The text in 4034 could be confused with having to count "wildcard labels" in the middle of a name, such as in name.*.tld. The reason for suggesting this errata is for compliance considerations.
--VERIFIER NOTES--
All wildcard labels start with * in the leftmost label. No other kind of wildcard label exists.

From RFC 1034:

4.3.3. Wildcards

In the previous algorithm, special treatment was given to RRs with owner
names starting with the label "*".

RFC 4072, "Diameter Extensible Authentication Protocol (EAP) Application", August 2005

Note: This RFC has been updated by RFC 7268, RFC 8044

Source of RFC: aaa (ops)

Errata ID: 2317
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Souheil Ben Ayed
Date Reported: 2010-06-30
Rejected by: Dan Romascanu
Date Rejected: 2010-11-02

Section 3.2. says:

      <Diameter-EAP-Answer> ::= < Diameter Header: 268, PXY >
                                < Session-Id >
                                { Auth-Application-Id }
                                { Auth-Request-Type }
                                { Result-Code }
                                { Origin-Host }
                                { Origin-Realm }
                                [ User-Name ]
                                [ EAP-Payload ]
                                [ EAP-Reissued-Payload ]
                                [ EAP-Master-Session-Key ]
                                [ EAP-Key-Name ]
                                [ Multi-Round-Time-Out ]
                                [ Accounting-EAP-Auth-Method ]
                                [ Service-Type ]

It should say:

      <Diameter-EAP-Answer> ::= < Diameter Header: 268, PXY >
                                < Session-Id >
                                { Auth-Application-Id }
                                { Auth-Request-Type }
                                { Result-Code }
                                { Origin-Host }
                                { Origin-Realm }
                                [ User-Name ]
                                [ EAP-Payload ]
                                [ EAP-Reissued-Payload ]
                                [ EAP-Master-Session-Key ]
                                [ EAP-Key-Name ]
                                [ Multi-Round-Time-Out ]
                              * [ Accounting-EAP-Auth-Method ]
                                [ Service-Type ]

Notes:

When one or more EAP methods used for authenticating the user, for each used EAP method an Accounting-EAP-Auth-Method AVP is added in the Diameter-EAP-Answer with a successful result code. In the message format of Diameter-EAP-Answer, one or more Accounting-EAP-Auth-Method AVPs can be included.
--VERIFIER NOTES--
This erratum if verified would create an non-backward-compatible change. The submiter is kindly requested to consider the discussions with the author on the WG list and if he still thinks that the change is needed to resubmit the erratum as Technical.

RFC 4084, "Terminology for Describing Internet Connectivity", May 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: ops

Errata ID: 4054
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Nottingham
Date Reported: 2014-07-17
Rejected by: joel jaeggli
Date Rejected: 2014-10-22

Section 2 says:

The provider may impose a filtering Web proxy on the 
connections; that proxy may change and redirect URLs 
to other sites than the one originally specified by the 
user or embedded link.

It should say:

The provider may require a HTTP proxy to be used.

Notes:

RFC7230 Section 2 defines a Web proxy as being nominated by the client, not the network operator; operator-imposed proxies (so-called "interception" proxies) are not legitimate in HTTP, even if they are not uncommon.

Furthermore, RFC7230 section 5.7.2 defines the constraints on the transformations HTTP proxies can make, not this document.
--VERIFIER NOTES--
the original is not wrong in the sense that it's historically appropriate. We should consider revising this document but lodging this as erratum doesn't change the intention of the original text.

RFC 4086, "Randomness Requirements for Security", June 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 3106
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Florian Weimer
Date Reported: 2012-02-05
Rejected by: Sean Turner
Date Rejected: 2012-05-06

Section 4.4 says:

(see below)

It should say:

(remove entire section)

Notes:

Compression is not suitable for de-skewing, even if headers are removed. For most compression algorithms, discriminators are known. For instance, in gzip output, the most significant bit of each byte is set with a frequency somewhat above 0.501 (except for small inputs). This means that the output is not uniformly distributed even when looking at isolated bytes.

I recommend removal of the entire section.
--VERIFIER NOTES--
I agree with the author:

Just to be crystal clear, I believe there is no "error" here. Just a
judgement call as to whether Section 4.4 should have been included. My
judgement that it should be included was ratified by the IETF at the
time the RFC was approved.

RFC 4103, "RTP Payload for Text Conversation", June 2005

Note: This RFC has been updated by RFC 9071

Source of RFC: avt (rai)

Errata ID: 5032
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Gunnar Hellstrom
Date Reported: 2017-06-07
Rejected by: Francesca Palombini
Date Rejected: 2023-11-07

Section 5.2 says:

After an idle period, the transmitter SHOULD set the M-bit to one in
the first packet with new text.

It should say:

After an idle period, the transmitter SHOULD set the M-bit to one in
the first packet with new text.

A number of approaches can be taken for how to compose the initial
packets in the session, and the packets sent at resumption after an
idle period. In order to harmonize transmitter behavior, and fulfill
requirements in RFC 2198[3] and RFC 4102[9], transmitters SHOULD
apply the following mechanism:  Initially in the session and at 
resumption of transmission after an idle period, when redundancy is
used, the packets to send SHOULD contain the same level of redundancy
as specified for the session. If redundant data for the specified
number of generations is not available for transmission, empty 
T140blocks SHOULD be inserted in the packet for transmission to make
it contain the specified level of redundancy. 

Notes:

RFC 4103 does not exactly specify how to compose the first packets in the session and the packets after an idle period, when redundancy is used in the session.

Even if receivers should be prepared to decode any valid packet composition, it eases interoperability when transmitters behave consistently.

RFC 2198 requires that the redundant format must carry at least the primary and one redundant level. RFC 4102 requires that if different compositions of the payloads in the packet is to be used, then each combination needs to be assigned its own payload type number. Assuming that that includes use of varying levels of redundancy with the same payload in the redundant data, these requirements lead to the recommendation to use the approach documented in the corrected text.
--VERIFIER NOTES--
Your comment is not in scope for errata reports, which are meant to collect errors in the documents, things that were actual errors at publication and that would have been fixed at that time had the working group or document authors noticed them -- they were just missed. What you've reported goes beyond what can be done in errata. The change, therefore, if it is to be applied needs to be achieved through a consensus document.

RFC 4119, "A Presence-based GEOPRIV Location Object Format", December 2005

Note: This RFC has been updated by RFC 5139, RFC 5491, RFC 7459

Source of RFC: geopriv (rai)

Errata ID: 827
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-12-21
Rejected by: Robert Sparks
Date Rejected: 2010-05-23

 

On mid-page 8, RFC 4119 specifies:
                                                     [...]  If the
    value in the 'retention-expires' element has already passed when
    the Location Recipient receives the Location Object, the Recipient
    MUST discard the Location Object immediately.

Now, RFC 4119 contains examples of Location Objects. Thus, the reader
of RFC 4119 (or his workstation) becomes a Location Recipient.
But those examples of Location Objects contained in RFC 4119 specify
a 'retention-expires' date that has passed *long before* the
publication of RFC 4119.
Therefore, every reader of RFC 4119, and every system receiving a
copy of RFC 4119, MUST immediately discard the RFC; moreover,
even the RFC editor SHOULD NOT ever have processed the draft!

But in this case, the above rule would not have become effective,
making these actions, creation and reading of the RFC, legitimate
again ...

It should say:

[see above]

Notes:

from pending

From the RAI reviewer: Strictly speaking, only the Location Objects contained in the RFC4119 MUST be discarded. Since this would only remove the examples from the RFC and not the specifiction, the RFC would remain effective, if somewhat less convenient to use.
--VERIFIER NOTES--

RFC 4122, "A Universally Unique IDentifier (UUID) URN Namespace", July 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 3970
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Jennifer Arsenault
Date Reported: 2014-04-19
Rejected by: Barry Leiba
Date Rejected: 2014-05-07

Section 4.1.3 says:

The version number is in the most significant 4 bits of the time
stamp (bits 4 through 7 of the time_hi_and_version field).

It should say:

The version number is in the most significant 4 bits of the
time_hi_and_version field...

Notes:

Errata 1957 and 3546 refer to the inconsistent bit numbering. That is a separate issue and has been left out of this correction. This report is in reference to the use of "time stamp" vs "time_hi_and_version field". The version number does not replace the most significant 4 bits of the time stamp. The 4-bit version number is in addition to the 60-bit time stamp.
--VERIFIER NOTES--
This seems to be a misunderstanding of the meaning here:
The time_hi_and_version field includes 4 bits for version, followed by the most significant 12 bits of the time stamp. Therefore, the most significant four bits of the time stamp *are* bits 4 thru 7 of the time_hi_and_version field.

That said, this is all a confusing mess, and really could use a revision for clarity.

RFC 4130, "MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)", July 2005

Source of RFC: ediint (app)

Errata ID: 2973
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Kyle Meadors
Date Reported: 2011-09-16
Rejected by: Pete Resnick
Date Rejected: 2011-11-12

Section 7.3 says:

   The currently supported values for MIC algorithm <micalg> values are:

        Algorithm   Value Used
        ---------    -------
         SHA-1        sha1
         MD5          md5

It should say:

   The currently supported values for MIC algorithm <micalg> values are:

        Algorithm   Value Used
        ---------    -------

         SHA-1      sha-1 or sha1
         MD5        md5
         SHA-224    sha-224
         SHA-256    sha-256
         SHA-384    sha-384
         SHA-512    sha-512

Notes:

The proper spelling is "sha-1" per http://www.iana.org/assignments/hash-function-text-names/hash-function-text. However, "sha1" should still be accepted to support backwards compatibility. The other hashes are newer ones since the RFC was published.
--VERIFIER NOTES--
A separate erratum was issued with the SHA1/SHA-1 fix. The additional algorithms cannot be added in an erratum.

Errata ID: 2974
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Kyle Meadors
Date Reported: 2011-09-16
Rejected by: Peter Saint-Andre
Date Rejected: 2011-11-12

Section 7.4.3 says:

   digest-alg-id = "sha1" | "md5"

It should say:

   digest-alg-id = "sha-1" | "sha-224" | "sha-256" | "sha-384" | "sha-512" | "sha1" | "md5"
		; The "sha1" is a legacy spelling of the "sha-1" defined hash in the IANA Textual Names Registry
		; It should be maintained for backwards compatibility

Notes:

The proper spelling is "sha-1" per http://www.iana.org/assignments/hash-function-text-names/hash-function-text. However, "sha1" should still be accepted to support backwards compatibility. The other hashes are newer ones since the RFC was published.
--VERIFIER NOTES--
Because this erratum really requires publication of a replacement RFC, in accordance with the "IESG Processing of RFC Errata for the IETF Stream" <http://www.ietf.org/iesg/statement/errata-processing.html> the appropriate processing is to reject it.

Errata ID: 3055
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: JP McCrory
Date Reported: 2011-12-20
Rejected by: Pete Resnick
Date Rejected: 2011-12-29

Throughout the document, when it says:

      Disposition: automatic-action/MDN-sent-automatically;
      processed/warning: duplicate-document

      Disposition: automatic-action/MDN-sent-automatically;
        processed/warning: duplicate-document
      Warning: An identical message already exists at the
        destination server.

      Disposition: automatic-action/MDN-sent-automatically;
        processed/warning
      Warning: duplicate-document

It should say:

(Remove/replace warning examples from section '7.5.6.  Backward Compatibility with Disposition Type, Modifier, and Extension' - see notes)

9.3.  Replay Remark

   Because business data documents normally contain transaction ids,
   replays (such as resends of not-yet-acknowledged messages) are
   discarded as part of the normal process of duplicate detection.
   Detection of duplicates by Message-Id or by business transaction
   identifiers is recommended.

(Add following comment to above section.)
   If duplicate is detected the disposition should be returned with 
   'processed' and without an error or warning status unless other
   errors occurred. Sending an error or warning on a duplicate can
   result in an endless communication loop between retransmissions
   and resulting error/warnings.

Notes:

Endless communication loops are a problem with AS2 and this is only supported by the RFC and its multiple examples of 'duplicate-document'. What most commonly happens is a file is sent synchronously to one of our partners but our two minute timeout in holding the connection for an MDN is reached. The recipients AS2 software generated the MDN but doesn't recognize the connection is no longer available for MDN return and as a result non-repudiation of receipt has not occurred. The file is later resent to the partner who then promptly sends an MDN with a processed/warning condition again not meeting our threshold of non-repudiation of receipt.

We have three or four occurrences of this exact scenario occur every week and because the RFC undercuts our ability to get AS2 software clients to address this issue at all many of our supplier are forced to manually mark their files as transmitted manually through a mailbox UI we have online.

We understand the need for duplicate detection and have our own in place but implemented in a way that endless communication loops cannot occur. Balanced duplicate detection is advised because to stringent of duplicate detection especially done within the communication protocol itself if problematic. An example of this would be partner who receive a file but then have issues in processing the data and did not take an archive of their data before processing as many do. These partners have requested our system to resend their data AS2 only to find the data is rejected before the file is received because it has the same 'message-id' as it did the first time it was sent and their AS2 software still have the message-id stored in their software's receiving records.

Again I support duplicate checking but it needs to be better defined for AS2 especially the elimination of the duplicate warning with the understanding of the unending communication loops that it can create through no fault of anyone just a missed MDN on the initial communication is all it takes.
--VERIFIER NOTES--
Aside from this being a poorly formatted report (it does not give proper original/change text and should probably have been split into multiple errata), none of this is at all appropriate for an erratum. This is a change to the examples and to add an additional warning given operational experience. This needs to be done via a document update, not an erratum.

RFC 4140, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", August 2005

Note: This RFC has been obsoleted by RFC 5380

Source of RFC: mipshop (int)

Errata ID: 182
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-09-14
Rejected by: Brian Haberman
Date Rejected: 2012-06-06

Appendix A

1.)  There are a couple of issues with the citations given
     in Appendix A, on pp. 24-27 :

1.1) I suspect that the repeated occurrences of "[5]" should
     in fact be "[4]" (the Fast Handover RFC 4068).

1.2) The final phrase at the bottom of page 26 should obviously
     refer to RFC 4067 (CXTP) instead of a "work in progress"
     (add appropriate ref to section 14.2.!)

1.3) The citations "[6]" on page 27 apparently make no sense --
     SEND does not update RFC 4068.  I suspect a reference to
     some "work in progress" would have been appropriate.

2.)  Minor typos and proposed textual improvements

2.1) On p.8, in line 5 (i.e. the end of section 4.1.):
     instead of "introduced in future" the text might perhaps
     better say: "introduced in the future".

2.2) On p. 14, in the bottom line (at the end of section 7.1.),
     the final "." is missing.

2.3) On p. 16, in the 2nd-to-last paragraph of section 7.2.,
     The phrase "RCoA is then bound to ..." should perhaps better
     say: "The RCoA is then bound to ...".

2.4) On page 19, in the final line of section 9.2., the word
     "movement" is mis-spelled "u0movement".

2.5) On page 20, in the enumerated list at the end of section 12.,
     I propose to remove the "The" in all 3 items, aligning with
     the titles of the subsequent sections 12.1. - 12.3.

It should say:

[see above]

Notes:

from pending





--VERIFIER NOTES--
RFC 4140 has been obsoleted by RFC 5380.

RFC 4173, "Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol", September 2005

Note: This RFC has been updated by RFC 7146

Source of RFC: ips (tsv)

Errata ID: 174

Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-10-17
Rejected by: Lars Eggert
Date Rejected: 2008-11-28
Report Text:

Two normative references have been obsoleted:

    RFC 2396 ( Ref. "[Lee98]" )
and
    RFC 2732 ( Ref. "[Hinden99]" )

have both been obsoleted by RFC 3986 == STD 66 (published in
January 2005) !

Affected pieces of RFC 4173:
- Both Ref's appear once (and together) near the bottom of
  page 4 (in the 6th-to-last line).
- Normative References section, bottom of page 9 + top of page 10
 --VERIFIER NOTES-- 
Independent of the publication date, the work on the draft that
became this RFC significantly predates publication of RFC 3986.
The references to those two RFCs are correct, and the obsoleted
status of the RFCs can be readily determined from the RFC Editor's
database.   

---

RFC 4180, "Common Format and MIME Type for Comma-Separated Values (CSV) Files", October 2005

Note: This RFC has been updated by RFC 7111

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 5464
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alperen Belgic
Date Reported: 2018-08-15
Rejected by: Benjamin Kaduk
Date Rejected: 2018-08-16

Section 2 says:

5.  Each field may or may not be enclosed in double quotes (however
       some programs, such as Microsoft Excel, do not use double quotes
       at all).  

It should say:

5.  Each field may or may not be enclosed in double quotes.

Notes:

For csv files, Microsoft Excel 2010 saves the value of a field enclosed in double quotes if a cell contains a comma in its value.
--VERIFIER NOTES--
Errata are only considered that would have been errors at the time the document was published.
The document refers to the version(s) of Excel that were available at its time of publication, not versions released since then.

RFC 4211, "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", September 2005

Note: This RFC has been updated by RFC 9045

Source of RFC: pkix (sec)

Errata ID: 798
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Rejected by: Sean Turner
Date Rejected: 2010-07-29

Section 4.2 says:

Key Encipherment Keys, in the lower part of page 10, in the two (doubly indented) paragraphs explaining the components of 'agreeMAC', uses improper names for these components -- cf. the ASN.1 syntax for PKMACValue at the top of page 9. The RFC says:

        vvvvvv
        macAlg contains the algorithm identifying the method used to
        compute the MAC value.

        macValue contains the computed MAC value.
        ^^^^^^^^

It should say (I propose to make use of hierarchical subfield
notation):

        agreeMAC.algID  contains the algorithm identifying the method
        used to compute the MAC value.

        agreeMAC.value  contains the computed MAC value.

It should say:

[see above]     

Notes:

--VERIFIER NOTES--
The implication of doing the second level of indentation indicates that
these fields are in the type referenced by the agreeMac field. Note that the same thing occurs just above for subsequentMessage. The type definition occurred in the previous section 4.1.

RFC 4217, "Securing FTP with TLS", October 2005

Note: This RFC has been updated by RFC 8996

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 7294
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mikael A
Date Reported: 2022-12-31
Rejected by: Orie Steele
Date Rejected: 2024-03-29

The abstract says:

   This document
   is intended to provide TLS support for FTP in a similar way to that
   provided for SMTP in RFC 2487, "SMTP Service Extension for Secure
   SMTP over Transport Layer Security", and HTTP in RFC 2817, "Upgrading
   to TLS Within HTTP/1.1.".

It should say:

   This document
   is intended to provide TLS support for FTP in a similar way to that
   provided for SMTP in RFC 3207, "SMTP Service Extension for Secure
   SMTP over Transport Layer Security", and HTTP in RFC 2817, "Upgrading
   to TLS Within HTTP/1.1.".

Notes:

Upgrade?
--VERIFIER NOTES--
The text was correct at the time of publishing, and the datatracker conveys that RFC 2487 was obsoleted by RFC 3207

RFC 4226, "HOTP: An HMAC-Based One-Time Password Algorithm", December 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 6181
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Yishuai Li
Date Reported: 2020-05-18
Rejected by: Benjamin Kaduk
Date Rejected: 2020-05-30

Section E.4 says:

   The server accepts if the following are all true, where C-server is
   its own current counter value:

   1) C-client >= C-server
   2) C-client - C-server <= s
   3) Check that HOTP client is valid HOTP(K,C-Client)
   4) If true, the server sets C to C-client + 1 and client is
      authenticated

   In this case, there is no need for managing a look-ahead window
   anymore.  The probability of success of the adversary is only v/10^6
   or roughly v in one million.  A side benefit is obviously to be able
   to increase s "infinitely" and therefore improve the system usability
   without impacting the security.

It should say:

   The server accepts if the following are all true, where C-server is
   its own current counter value:

   1) C-client >= C-server
   2) Check that HOTP client is valid HOTP(K,C-Client)
   3) If true, the server sets C to C-client + 1 and client is
      authenticated

   In this case, there is no need for managing a look-ahead window
   anymore.  The probability of success of the adversary is only v/10^6
   or roughly v in one million.  A side benefit is obviously to be able
   to increase C-server "infinitely" and therefore improve the system usability
   without impacting the security.

Notes:

1. Resynchronization should be allowed when C-client - C-server > s.
2. The look-ahead window s should not be increased.
--VERIFIER NOTES--
The proposed new text provides behavior equivalent to the behavior allowed by the old text with respect to the possibility of resynchronization in the face of large C-client/C-server skew.

RFC 4229, "HTTP Header Field Registrations", December 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 837
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-01-18
Rejected by: Peter Saint-Andre
Date Rejected: 2011-05-16

 

(2)

RFC 2068 [4] has been obsoleted by RFC 2616 [11], and the latter
purposely has omitted a few elements of HTTP from the former
specification because of "detected problems" and/or "lack of
implementation" -- cf. Section 19.6 of RFC 2616.
Thus, there is no more current specification for these elements.
According to my understanding that means that these elements
effectively have been deprecated by RFC 2616.

Among those (deprecated) elements of HTTP 1.1 are the HTTP Header
Fields:
         -  Content-Base
         -  Content-Version
         -  Derived-From
         -  Keep-Alive
         -  Link
         -  Public
         -  URI

As expected, the Registrations for these HTTP Header Fields, as
presented in RFC 4229, consistently all refer to RFC 2068 [4] as
the (obsolete) 'Specification document' -- but, very surprisingly,
the registered 'Status' entries for these Header Fields all contain:
"standard" instead of "deprecated".

According to my understanding of IETF procedures, a feature or
protocol element must not be named "standard" if its specification
has been officially obsoleted / deprecated by a Standards Track RFC.

Hence, IMHO the IANA Registrations for the above mentioned HTTP
Header Fields (Subsections 2.1.{21,33,41,59,62,89,108} of RFC 4229
should be immediately corrected to contain 'Status: deprecated".

It should say:

[see above]

Notes:

(Note: A status of "deprecated" still allows standards conformant
implementations to implement any such feature or protocol element
for the sake of backwards compatibility!)
--VERIFIER NOTES--
This is not an appropriate subject for an erratum.
Please take this up with the IANA or, better yet,
write an Internet-Draft. --Peter Saint-Andre

RFC 4234, "Augmented BNF for Syntax Specifications: ABNF", October 2005

Note: This RFC has been obsoleted by RFC 5234

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 777
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Zoltan Ordogh
Date Reported: 2006-09-18
Rejected by: Alexey Melnikov
Date Rejected: 2010-09-02

Section 3.4 says:

   A range of alternative numeric values can be specified compactly,
   using dash ("-") to indicate the range of alternative values.  Hence:

         DIGIT       =  %x30-39

   is equivalent to:

         DIGIT       =  "0" / "1" / "2" / "3" / "4" / "5" / "6" /

                        "7" / "8" / "9"

It should say:

[not supplied]

Notes:

The word equivalent is correct only when US-ASCII character set is used, since:

DIGIT = %x30-39 ;
means any hexadecimal value between 0x30 and 0x39,

while

DIGIT = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" ;
means any digit from 0 thru 9.

from pending
--VERIFIER NOTES--
As per Note in Section 2.3:

ABNF strings are case-insensitive and the character set for these
strings is us-ascii.

So these 2 representations *are* equivalent.

Errata ID: 778
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Zoltan Ordogh
Date Reported: 2006-09-18
Rejected by: Alexey Melnikov
Date Rejected: 2010-09-02

In Appendix B.1, it says:

         CHAR           =  %x01-7F
                                ; any 7-bit US-ASCII character,
                                ;  excluding NUL

It should say:

[see below]

Notes:

NUL is not defined.

Suggestions:
(1)
Re-write the document in a character-encoding-independent manner.
(2)
Add definition of NUL (or NULL) as terminating null character - watch =
out for character encoding!
(3)
Add definition of NOTNULL as any character but terminating null =
character - watch out for character encoding!

from pending
--VERIFIER NOTES--
NUL is defined in US-ASCII.

Errata ID: 783
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-10-13
Rejected by: Peter Saint-Andre
Date Rejected: 2010-11-18

 

 The following clarifications apply to the meta-grammar in section 4.

a) Near the bottom of page 10, the rule:

         repetition     =  [repeat] element

   should say:

|        repetition     =  ( [repeat] element ) / option

   At the top of page 11, the rule:

         element        =  rulename / group / option /
                           char-val / num-val / prose-val

   should say:

|        element        =  rulename / group /
                           char-val / num-val / prose-val

   These changes have the effect to formally disallow
   a <repeat> element in front of an <option>
   -- a senseless construct formerly unexpectedly allowed.

b) On page 11, the last rule:

         prose-val      =  "<" *(%x20-3D / %x3F-7E) ">"
                               ; bracketed string of SP and VCHAR
                               ;  without angles
                               ; prose description, to be used as
                               ;  last resort
   should say:

         prose-val      =  "<" *(%x20-3D / %x3F-7E) ">"
|                              ; bracketed string of:
|                              ;  SP and VCHAR without closing angle
                               ; prose description, to be used as
                               ;  last resort

   This change aligns the comment with the formal rule.

It should say:

[see above]  

Notes:

from pending
--VERIFIER NOTES--
Peter: The authors have consensus that these are stylistic issues and therefore are not errors.

Errata ID: 159
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2006-01-31
Rejected by: Peter Saint-Andre
Date Rejected: 2010-09-15

Section 2.4 says:

    External representations of terminal value characters will vary
    according to constraints in the storage or transmission environment.
    Hence, the same ABNF-based grammar may have multiple external
    encodings, such as one for a 7-bit US-ASCII environment, another for
    a binary octet environment, and still a different one when 16-bit
    Unicode is used.  Encoding details are beyond the scope of ABNF,
    although Appendix A (Core) provides definitions for a 7-bit US-ASCII
    environment as has been common to much of the Internet.

It should say:

    External representations of terminal value characters will vary
    according to constraints in the storage or transmission environment.
    Hence, the same ABNF-based grammar may have multiple external
    encodings, such as one for a 7-bit US-ASCII environment, another for
    a binary octet environment, and still a different one when 16-bit
    Unicode is used.  Encoding details are beyond the scope of ABNF,
    although Appendix B (CORE ABNF OF ABNF) provides definitions for
    a 7-bit US-ASCII environment as has been common to much of the
    Internet.

Notes:

--VERIFIER NOTES--
Fixed in RFC 5234.

Errata ID: 866
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2007-03-02
Rejected by: Peter Saint-Andre
Date Rejected: 2010-09-15

Appendix A says:

    External representations of terminal value characters will vary
    according to constraints in the storage or transmission environment.
    Hence, the same ABNF-based grammar may have multiple external
    encodings, such as one for a 7-bit US-ASCII environment, another for
    a binary octet environment, and still a different one when 16-bit
    Unicode is used.  Encoding details are beyond the scope of ABNF,
    although Appendix A (Core) provides definitions for a 7-bit US-ASCII
    environment as has been common to much of the Internet.

It should say:

    External representations of terminal value characters will vary
    according to constraints in the storage or transmission environment.
    Hence, the same ABNF-based grammar may have multiple external
    encodings, such as one for a 7-bit US-ASCII environment, another for
    a binary octet environment, and still a different one when 16-bit
    Unicode is used.  Encoding details are beyond the scope of ABNF,
    although Appendix B (Core) provides definitions for a 7-bit US-ASCII
    environment as has been common to much of the Internet.

Notes:

Appendix A" by "Appendix B" here.

from pending
--VERIFIER NOTES--
Fixed in RFC 5234.

RFC 4235, "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", November 2005

Note: This RFC has been updated by RFC 7463, RFC 8996

Source of RFC: sipping (rai)

Errata ID: 2268
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: David Grant
Date Reported: 2010-05-18
Rejected by: Robert Sparks
Date Rejected: 2010-10-07

Section 4.2 says:

<xs:complexType name="sessd">
   <xs:simpleContent>
      <xs:extension base="xs:string">
         <xs:attribute name="type" type="xs:string" use="required"/>
      </xs:extension>
   </xs:simpleContent>
</xs:complexType>

It should say:

<xs:complexType name="sessd">
  <xs:attribute name="type" type="xs:string"/>
</xs:complexType> 

Notes:

The sessd type is a simple type, which allows text content, yet the RFC does not describe what content it should have, so it should be an empty type instead.
--VERIFIER NOTES--
(From reviewer Dale Worley):

The description of the session-description element in section 4.1.6.3
is not particularly clear, but it is unambiguous:

4.1.6.3. Session Description Element

The session-description element contains the session description used
by the observed user for its end of the dialog. This element should
generally NOT be included in the notifications, unless it was
explicitly requested by the subscriber. It has a single attribute,
"type", which indicates the MIME media type of the session
description. To avoid repeating session description information in
each request, the subscriber can assume that the session description
is the same as in previous notifications if no session description
element is present in the corresponding local or remote element.

Therefore, a typical usage would be:

<?xml version="1.0" encoding="UTF-8"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:dialog-info"
version="1" state="full">
<dialog id="123456">
<state>confirmed</state>
<duration>274</duration>
<local>
<identity display="Alice">sip:alice@example.com</identity>
<target uri="sip:alice@pc33.example.com">
<param pname="isfocus" pval="true"/>
<param pname="class" pval="personal"/>
</target>
<session-description type="application/sdp">v=0
o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com
s=Session SDP
t=0 0
c=IN IP4 pc33.atlanta.com
m=audio 3456 RTP/AVP 0 1 3 99
a=rtpmap:0 PCMU/8000
</session-description>
</local>
<remote>
<identity display="Bob">sip:bob@example.org</identity>
<target uri="sip:bobster@phone21.example.org"/>
</remote>
<session-description type="application/sdp">[SDP sent by remote UA]</se\
ssion-description>
</dialog>
</dialog-info>

That is, <session-description> has a "type" attribute whose value is
the MIME type of the session description, and it has content which is
the session description.

(Note that both the <local> and <remote> elements have their own
<session-description>, as SDP is sent by both UAs. Presumably the
<session-description> of a participant is the SDP that was *sent* by
that participant.)

Within this understanding, the XML schema language in the RFC is
correct. The '<xs:extension base="xs:string">' specifies that the
content of <session-description> is a string, and the '<xs:attribute
name="type" type="xs:string" use="required"/>' specifies that
<session-description> must have an attribute 'type'.

(The situation could have been made much clearer if the RFC included
an example of the use of <session-description>.)

RFC 4237, "Voice Messaging Directory Service", October 2005

Source of RFC: vpim (app)

Errata ID: 810
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-11-30
Rejected by: Alexey Melnikov
Date Rejected: 2009-07-18

 

I suspect that the OID value given in Section 2 is not correct.
It does not match the one listed in section 4.2, on page 10,
4th text line.

Therefore I propose the following erratum:

RFC 4237, at the beginning of Section 2, on page 3, says:

   (IANA-ASSIGNED-OID.1 NAME 'vPIMUser'
           SUP 'top'
           ...          )

it should say:
                       vv
   (IANA-ASSIGNED-OID.1.1 NAME 'vPIMUser'
           SUP 'top'
           ...          )

It should say:

[see above]

Notes:

from pending
--VERIFIER NOTES--
Duplicate of the erratum # 157.

RFC 4253, "The Secure Shell (SSH) Transport Layer Protocol", January 2006

Note: This RFC has been updated by RFC 6668, RFC 8268, RFC 8308, RFC 8332, RFC 8709, RFC 8758, RFC 9142

Source of RFC: secsh (sec)

Errata ID: 152
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: denis bider
Date Reported: 2006-01-23
Rejected by: Pasi Eronen
Date Rejected: 2008-08-11

Section 12 says:

    SSH_MSG_DISCONNECT             1
    SSH_MSG_IGNORE                 2
    SSH_MSG_UNIMPLEMENTED          3
    SSH_MSG_DEBUG                  4
    SSH_MSG_SERVICE_REQUEST        5
    SSH_MSG_SERVICE_ACCEPT         6
    SSH_MSG_KEXINIT                20
    SSH_MSG_NEWKEYS                21

It should say:

    SSH_MSG_DISCONNECT             1
    SSH_MSG_IGNORE                 2
    SSH_MSG_UNIMPLEMENTED          3
    SSH_MSG_DEBUG                  4
    SSH_MSG_SERVICE_REQUEST        5
    SSH_MSG_SERVICE_ACCEPT         6
    SSH_MSG_KEXINIT                20
    SSH_MSG_NEWKEYS                21
    SSH_MSG_KEXDH_INIT             30
    SSH_MSG_KEXDH_REPLY            3

Notes:

--VERIFIER NOTES--
Errata IDs 152 and 1408 are combined to 1486.

Errata ID: 1408
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dwayne Litzenberger
Date Reported: 2008-04-11
Rejected by: Pasi Eronen
Date Rejected: 2008-08-11

Section 12 says:

    SSH_MSG_KEXDH_INIT             30
    SSH_MSG_KEXDH_REPLY            3

It should say:

    SSH_MSG_KEXDH_INIT             30
    SSH_MSG_KEXDH_REPLY            31

Notes:

This is a transcription error in the erratum dated 2006-01-23. Section 12 says "numbers 30-49 are used for kex packets", so using 3 for SSH_MSG_KEXDH_REPLY is clearly wrong. OpenSSH and python-paramiko both use 31, not 3.
--VERIFIER NOTES--
Errata IDs 152 and 1408 are combined into 1486.

RFC 4255, "Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints", January 2006

Source of RFC: secsh (sec)

Errata ID: 6267
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Jonathan Neuschäfer
Date Reported: 2020-08-26
Rejected by: Benjamin Kaduk
Date Rejected: 2020-08-30

Throughout the document, when it says:

It should say:

Updated by: 6594, 7479, 8709

Notes:

RFCs 6594, 7479, 8709 update the IANA registries "SSHFP RR Types for public key algorithms" and "SSHFP RR type for fingerprint types", that were originally described in RFC 4255. These RFCs thus (arguably) update RFC 4255. It would be helpful to have such an "Updated by" noticed in the header of RFC 4255.
--VERIFIER NOTES--
Arguably, those RFCs do not update RFC 4255, given that much of the point of having an IANA registry is to be able to allocate new values without updating the original document. I do not believe there is a convention of using an Updates relationship solely to indicate that a codepoint has been allocated from an IANA registry.

RFC 4256, "Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)", January 2006

Source of RFC: secsh (sec)

Errata ID: 758
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-18
Rejected by: Pasi Eronen
Date Rejected: 2009-02-16

Section 3.2 says:

"Information Requests", on page 5, RFC 4256 says:

   The language tag is deprecated and SHOULD be the empty string.  It
   may be removed in a future revision of this specification.  Instead,
   the server SHOULD select the language used based on the tags
   communicated during key exchange [SSH-TRANS].

   If the language tag is not the empty string, the server SHOULD use
   the specified language for any messages sent to the client as part of
   this protocol.  The language tag SHOULD NOT be used for language
   selection for messages outside of this protocol.  If the server does
   not support the requested language, the language to be used is
   implementation-dependent.

It should say:

[see Notes]

Notes:

[Replace by errata ID 1678]

(These two paragraphs apparently have been copied from Section 3.1
without change.)

This specification makes no sense here:

The Information Request is sent from the *server* to the client,
and it already contains strings that *do* make use of a particular
language/locale.

The one and only useful interpretation of the 'language tag'
in the Information Request message is that it specifies the
language/locale used for building the 'instruction' and 'prompt'
strings in the request.
This parallels the use of the language tag, e.g., in the
Disconnection Message of the SSH Transport Layer Protocol
(cf. RFC 4253, Sect. 11.1).

NOTE: The client might have announced a locale *list* in the
initial exchange, and the server should choose from that list;
the actual choice [for a particular message with text strings]
needs to be communicated to the client.

NOTE: In multi-stage authentication, the backend authentication
mechanisms will be the source of all these strings, and the SSH
server might have no choice than to just report the locale used
by each backend mechanism to the client; such mechanisms easily
could make use of different locales - hence the locale needs to
be announced per message from the server in this context!

NOTE: RFC 4253 recommends to send empty language tags fields in
the initial exchange; this makes the 'language tag' field in all
SSH protocol messages containing text to be presented to the user
*very* desirable !

Therefore, the 'language tag' should also better *not* be deprecated
in the SSH_MSG_USERAUTH_INFO_REQUEST message!

from pending
--VERIFIER NOTES--
[Replaced by errata ID 1678]

RFC 4270, "Attacks on Cryptographic Hashes in Internet Protocols", November 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 2658
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Lloyd Wood
Date Reported: 2010-12-04
Rejected by: Stephen Farrell
Date Rejected: 2011-11-12

Section 1 says:

The Internet protocol community needs to
migrate in an orderly manner away from SHA-1 and MD5 -- especially
MD5 -- and toward more secure hash algorithms.

It should say:

The Internet community needs to migrate in an orderly manner away from reliance for
security purposes on SHA-1 and MD-5 -- especially MD5 -- and toward more secure hash algorithms
for all security-related usages of hash functions in all protocols.

Notes:

This came up in discussion with Sean Turner, Martin Rex and the IESG over IESG Last Call: <draft-turner-md5-seccon-update-07.txt>.

RFC4270 lists seven uses for hash algorithms in section 3. MD5 should not be used for two of those [non-repudiable signatures and digital signatures in certificates] as those are are affected by collision attacks -- albeit only in limited circumstances. For the other five uses - particularly reliability checking (misnamed integrity protection in this draft) in a non-security context, MD5 remains fine to use. Martin flagged the original text as bad, and we came up with qualifiers - below.


On 3 Dec 2010, at 21:40, Martin Rex wrote:

> L.Wood@surrey.ac.uk wrote:

>> I also take issue with RFC4270's claim that:
>>
>> >The Internet protocol community needs to
>> > migrate in an orderly manner away from SHA-1 and MD5 -- especially
>> > MD5 -- and toward more secure hash algorithms.
>>
>> which is rather broad, and entirely without the context and qualifiers
>> we're discussing. RFC4270 was not written for a general audience,
>> but for a security audience. The Internet _security protocol_ community
>> may well need to migrate from these for certain uses (despite there not
>> yet being obvious things to move _to_), but RFC4270 and your draft's
>> sum take-away message that MD5BADDONOTUSE overstates the case.
>
> I agree that the above wording of rfc-4270 is BAD.
>
> It should have said:
>
> The Internet community needs to migrate in an orderly manner away from
> SHA-1 and MD5 -- especially MD5 -- and toward more secure hash algorithms
> for all security-related usages of hash functions in all protocols.

That wording is better, though I would also add a qualifier
on the front by saying 'away from reliance for security purposes on SHA-1
and MD-5...'. This should imo be filed as an erratum on RFC4270.
--VERIFIER NOTES--
This is a substantive change that would require "security-related" to be sufficiently well defined. Writing a draft about this would be better.

RFC 4271, "A Border Gateway Protocol 4 (BGP-4)", January 2006

Note: This RFC has been updated by RFC 6286, RFC 6608, RFC 6793, RFC 7606, RFC 7607, RFC 7705, RFC 8212, RFC 8654, RFC 9072

Source of RFC: idr (rtg)

Errata ID: 1332
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Aaron Hughes
Date Reported: 2008-02-26
Rejected by: Stewart Bryant
Date Rejected: 2011-08-02

Section 4.5 says:

      OPEN Message Error subcodes:

               1 - Unsupported Version Number.
               2 - Bad Peer AS.
               3 - Bad BGP Identifier.
               4 - Unsupported Optional Parameter.
               5 - [Deprecated - see Appendix A].
               6 - Unacceptable Hold Time.

It should say:

      OPEN Message Error subcodes:

               1 - Unsupported Version Number.
               2 - Bad Peer AS.
               3 - Bad BGP Identifier.
               4 - Unsupported Optional Parameter.
               5 - [Deprecated - see Appendix A].
               6 - Unacceptable Hold Time.
               7 - Unsupported Capability

Notes:

7 - Unsupported Capability orig from RFC3392 seems to have accidently disappeared.

Thanks!
Aaron
--VERIFIER NOTES--
The working group debated this point and concluded the following:

The functionality (specifically, BGP Capabilities) this error code applies to does not appear anywhere in RFC 4271 (or RFC 1771). As IANA records, this error subcode is defined in RFC5492/RFC3392, along with the related functionality. The IANA registry is the final authority as to code point assignments, and is correct as written. Accordingly, this erratum is rejected.

Errata ID: 3366
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Shashank Tyagi
Date Reported: 2012-09-26
Rejected by: Stewart Bryant
Date Rejected: 2013-09-20

Section 8.2.2 says:

If a TcpConnectionFails event (Event 18) is received, the local
      system:

        - closes the BGP connection,

        - restarts the ConnectRetryTimer,

        - continues to listen for a connection that may be initiated by
          the remote BGP peer, and

        - changes its state to Active.

It should say:

If a TcpConnectionFails event (Event 18) is received, the local
      system:

        - closes the BGP connection,

        - sets the HoldTimer to 0,

        - restarts the ConnectRetryTimer,

        - continues to listen for a connection that may be initiated by
          the remote BGP peer, and

        - changes its state to Active.

Notes:

HoldTimer should only be used to control time in between BGP packets.
Also in this case it can lead to case in ACTIVE state where HoldTimer expires before the ConnectRetryTimer leading to IDLE state.
--VERIFIER NOTES--
This represents a technical change to RFC4271 and is outside the scope of the errata system. The submitter is welcome to submit a draft proposing the change to RFC 4271 and work for consensus for the change in the IDR WG.

Errata ID: 3673
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: William McCall
Date Reported: 2013-06-28
Rejected by: Stewart Bryant
Date Rejected: 2013-10-04

Section 5 says:

Path attributes fall into four separate categories:

         1. Well-known mandatory.
         2. Well-known discretionary.
         3. Optional transitive.
         4. Optional non-transitive.

It should say:

Path attributes fall into five separate categories:

         1. Well-known mandatory.
         2. Well-known discretionary.
         3. Well-known.
         4. Optional transitive.
         5. Optional non-transitive.

Notes:

Local pref is only a "well-known" attribute as it fails the definition for the behavior as a mandatory attribute and it is not exactly discretionary per 5.1.5's definition of local pref and section 5's definition of discretionary which states:

"5.1.5. LOCAL_PREF

LOCAL_PREF is a well-known attribute that SHALL be included in all
UPDATE messages that a given BGP speaker sends to other internal
peers."

Section 5's definition of discretionary:

" [...]Others are discretionary and MAY
or MAY NOT be sent in a particular UPDATE message."

As a well-known mandatory attribute would result in a NOTIFICATION per section 6.3, it cannot be well-known mandatory because it is only for internal peers. Thus, it is a separate category.

6.3
" If any of the well-known mandatory attributes are not present, then
the Error Subcode MUST be set to Missing Well-known Attribute. The
Data field MUST contain the Attribute Type Code of the missing,
well-known attribute."

In a future revision, a new term would probably be best to describe this. However, the categorization of attributes is misleading for now and the simplest approach is to add the new category already used by 5.1.5.
--VERIFIER NOTES--
This erratum was discussed on the IDR list.

The consensus was that whilst an alternative is to revert
from OpenSent to Idle on event 18 at that point, this was not
what was decided when RFC4271 was being produced, and
no one saw a good engineering reason to change it at this
stage.

On a matter of process, this proposal is not an Erratum
as the IETF sees it but an engineering change.

The submitter is, of course, welcome to submit a draft
proposing this change to RFC 4271 and the to discuss the
merits of the change with the IDR Working Group.

Errata ID: 3031
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kireeti Kompella
Date Reported: 2011-11-14
Rejected by: Stewart Bryant
Date Rejected: 2013-02-28

Section 9.1.2 says:

The Phase 2 decision function is blocked from running while the Phase
3 decision function is in process.

It should say:

The Phase 3 decision function is blocked from running while the Phase
2 decision function is in process.

Notes:

I believe that is what was intended; the text as is confuses me no end.
--VERIFIER NOTES--
It is accepted that the RFC text is confusing, but the proposed errata text is incorrect because this proposed revision implies that Phase 2 can begin running while Phase 3 is still running this contradicts other text in the RFC (9.1.2) which states that "The Phase 3 Routing Decision function is blocked from running whilst the Phase 2 decision function is in process."

It is anticipated that the IDR WG will publish material clarifying mutual exclusion in RFC4271.

RFC 4274, "BGP-4 Protocol Analysis", January 2006

Source of RFC: idr (rtg)

Errata ID: 3775
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Rejected by: Stewart Bryant
Date Rejected: 2013-10-30

 

(7)  some Ref's inappropriately named Normative

The References "[BGP-VULN]" and "[SBGP]" do not fulfill the
criteria for being used as Normative References.
Their inclusion in Section 11.1, on page 14, might formally be
seen as inhibiting the progress of BGP-4 on the Standards Track.

Notes:

This was considered OK by the IETF and IESG of the time.
--VERIFIER NOTES--
The status of these references will have been considered by the IETF and the IESG of the time. The authors and reviewers of any future BGP document will evaluate the correct status of the references that they use.

Errata ID: 3803
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramakrishna DTV
Date Reported: 2013-11-14
Rejected by: Stewart Bryant
Date Rejected: 2014-03-02

Section 2.1 says:

   BGP enhances the AS_PATH attribute to include sets of autonomous
   systems as well as lists via the AS_SET attribute.

It should say:

   BGP enhances the AS_PATH attribute to include sets of autonomous
   systems as well as lists via the AS_SET path segment type.

Notes:

AS_SET is not an attribute. It is a path segment type.
--VERIFIER NOTES--
BCP: 172 recommends for Not Using AS_SET and AS_CONFED_SET in BGP, and thus this is unlikely to be an issue in the long term.

RFC 4282, "The Network Access Identifier", December 2005

Note: This RFC has been obsoleted by RFC 7542

Source of RFC: radext (sec)

Errata ID: 753
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Frank Ellermann
Date Reported: 2006-08-14
Rejected by: Dan Romascanu
Date Rejected: 2010-11-03

Section 2.1 says:

   c           =/ %x80-FF ; UTF-8-Octet      allowed (not in RFC 2486)
                          ; Where UTF-8-octet is any octet in the
                          ; multi-octet UTF-8 representation of a
                          ; unicode codepoint above %x7F.
                          ; Note that c must also satisfy rules in
                          ; Section 2.4, including, for instance,
                          ; checking that no prohibited output is
                          ; used (see also Section 2.3 of
                          ; [RFC4013]).
   x           =  %x00-FF ; all 128 ASCII characters, no exception;
                          ; as well as all UTF-8-octets as defined
                          ; above (this was not allowed in
                          ; RFC 2486).  Note that x must nevertheless
                          ; again satisfy the Section 2.4 rules.

It should say:

[see below]

Notes:

Shouldn't that be s/FF/F4/ as in STD 63, or maybe s/FF/FD/ ?
--VERIFIER NOTES--
There is no clear suggested change. The chairs are aware about issues with RFC 4282, and believe that a new document is probably required to address them.

Errata ID: 1623
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin Thomson
Date Reported: 2008-12-01
Rejected by: Dan Romascanu
Date Rejected: 2009-02-05

Section 2.1 says:

   realm       =  1*( label "." ) label

It should say:

   realm       =  *( label "." ) label

Notes:

The ABNF for realm forces the inclusion of two labels, which is not consistent with RFC 1034, which allows just one:
<subdomain> ::= <label> | <subdomain> "." <label>
--VERIFIER NOTES--
Not allowing single-label realms was a deliberate decision (and the examples of invalid NAIs in Section 2.8 also include this case). One of the reasons was that RFC 1034 considers names without dots to be "relative" names of local significance. Such names may be valid DNS names for some other purposes than NAIs, though.

Errata ID: 1848
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alan DeKok
Date Reported: 2009-09-08
Rejected by: Dan Romascanu
Date Rejected: 2010-05-10

Section 2.4 says:

   o  Normalization requirements, as specified in Section 2.2 of
      [RFC4013], are also designed to assist in comparisons.

It should say:

  o Normalization is, in general, a bad idea.

Notes:

Much of RFC 4282 is simply wrong.

Normalization can be done only when both the local and character set information is included with the text. And that information is not included with the username or realm.

In addition, not all systems will treat "User" the same as "user". The decision about how to
compare user names is site specific. User name comparisons SHOULD NOT be performed on
any system other than the final one that performs user authentication.
--VERIFIER NOTES--
The suggested change is rather abrupt and should be discussed with the WG as part of a possible revision of the document.

Errata ID: 1849
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alan DeKok
Date Reported: 2009-09-08
Rejected by: Dan Romascanu
Date Rejected: 2010-05-10

Section 2.4 says:

   o  Bidirectional characters are handled as specified in Section 2.4
      of [RFC4013].

It should say:

  o Bidrectional characters are handled in a site-specific fashion

Notes:

The rules in [4013] have shortcomings. Updates are in:

http://tools.ietf.org/html/draft-ietf-idnabis-bidi-05
--VERIFIER NOTES--
The suggested change is rather abrupt and should be discussed with the WG as part of a possible revision of the document.

Errata ID: 1850
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alan DeKok
Date Reported: 2009-09-08
Rejected by: Dan Romascanu
Date Rejected: 2010-05-10

Section 2.4 says:

   o  Unassigned code points are specified in Section 2.5 of [RFC4013].
      The use of unassigned code points is prohibited.

It should say:

  o Unassigned code points MUST be ignored

Notes:

Unassigned code points sometimes go through a process called "assignment". This means that they suddenly become valid.

Implementations that forbid unassigned code points will not be updated when the standards change to assign them. Therefore, they should ignore unassigned code points.

Happily, this is what all implementations do.
--VERIFIER NOTES--
The suggested change should be discussed with the WG as part of a possible revision of the document.

RFC 4291, "IP Version 6 Addressing Architecture", February 2006

Note: This RFC has been updated by RFC 5952, RFC 6052, RFC 7136, RFC 7346, RFC 7371, RFC 8064

Source of RFC: ipv6 (int)

Errata ID: 2702
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Bassam Al-Khaffaf
Date Reported: 2011-02-01
Rejected by: Ralph Droms
Date Rejected: 2012-03-26

Section 2.3 says:

For example, the following are legal representations of the 60-bit
prefix 20010DB80000CD3 (hexadecimal):

   2001:0DB8:0000:CD30:0000:0000:0000:0000/60
   2001:0DB8::CD30:0:0:0:0/60
   2001:0DB8:0000:CD30::/60

It should say:

For example, the following are legal representations of the 60-bit
prefix 20010DB80000CD3 (hexadecimal):

   2001:0DB8:0000:CD30:0000:0000:0000:0000/60
   2001:0DB8:0000:CD30::/60

Notes:

According to the erratum reported on 2010-08-16 by Michael Rushton, the second text representation address of the example will be no more valid and should be taken away and keep the first and third ones.
This is because the use of "::" indicates two or more groups of 16 bits of zeros. Thank you
--VERIFIER NOTES--
Related to Bob Hinden's review of errata 2466:

I believe that this errata should be rejected. This was discussed on the v6ops mailing list around February 25, 2011. I responded:

http://www.ietf.org/mail-archive/web/v6ops/current/msg07741.html

The thread starts at:

http://www.ietf.org/mail-archive/web/v6ops/current/msg07722.html

Also, two errata were filed based on this one (Errata ID: 2735, Errata ID: 2702) that I think should also be rejected as they assume that this errata was correct.

Errata ID: 2735
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Richard Hartmann
Date Reported: 2011-02-24
Rejected by: Ralph Droms
Date Rejected: 2012-03-26

Section 2.2 says:

2. Due to some methods of allocating certain styles of IPv6
      addresses, it will be common for addresses to contain long strings
      of zero bits.  In order to make writing addresses containing zero
      bits easier, a special syntax is available to compress the zeros.
      The use of "::" indicates one or more groups of 16 bits of zeros.
      The "::" can only appear once in an address.  The "::" can also be
      used to compress leading or trailing zeros in an address.


 For example, the following addresses

         2001:DB8:0:0:8:800:200C:417A   a unicast address
         FF01:0:0:0:0:0:0:101           a multicast address
         0:0:0:0:0:0:0:1                the loopback address
         0:0:0:0:0:0:0:0                the unspecified address

      may be represented as

         2001:DB8::8:800:200C:417A      a unicast address
         FF01::101                      a multicast address
         ::1                            the loopback address
         ::                             the unspecified address

It should say:

2. Due to some methods of allocating certain styles of IPv6
      addresses, it will be common for addresses to contain long strings
      of zero bits.  In order to make writing addresses containing zero
      bits easier, a special syntax is available to compress the zeros.
      The use of "::" indicates two or more groups of 16 bits of zeros.
      The "::" can only appear once in an address.  The "::" can also be
      used to compress leading or trailing zeros in an address.  All
      compressed groups of 16 bits of zeros MUST be aligned with their
      respective leading and trailing ":".

 For example, the following addresses

         2001:DB8:9300:0:12:0:0:417A    a unicast address
         FF01:0:0:0:0:0:0:101           a multicast address
         0:0:0:0:0:0:0:1                the loopback address
         0:0:0:0:0:0:0:0                the unspecified address

      may be represented as

         2001:DB8:9300:0:12::417A       a unicast address
         FF01::101                      a multicast address
         ::1                            the loopback address
         ::                             the unspecified address

      and MUST NOT be represented as

         2001:DB8:93::12:0:0:417A       an incorrect unicast address

Notes:

Errata ID: 2466 would change the text I am changing, as well.

My changed text includes the change from errata 2466 to avoid the likelyhood of human mistakes.

In case http://tools.ietf.org/html/draft-denog-v6ops-addresspartnaming becomes a RFC before this errata can be worked in, "group of 16 bits of zeros" should be replaced with "$new_term of zeros" or similar. As it looks today, $new_term will most likely end up being "hextet".



The current wording allows for 2001:DB8:9300:12:0:0:417A to be written as 2001:DB8:93::12:0:0:417A which is clearly wrong and against the intentions behind the relevant RFCs. While RFC 5952 puts additional constraints on compression, it still allows for the incorrect example given above.

Thus, alignment of 16 bit groups of zeros along ":" is enforced specifically.
--VERIFIER NOTES--
Related to Bob Hinden's report on errata 2466:

I believe that this errata should be rejected. This was discussed on the v6ops mailing list around February 25, 2011. I responded:

http://www.ietf.org/mail-archive/web/v6ops/current/msg07741.html

The thread starts at:

http://www.ietf.org/mail-archive/web/v6ops/current/msg07722.html

Also, two errata were filed based on this one (Errata ID: 2735, Errata ID: 2702) that I think should also be rejected as they assume that this errata was correct.

Errata ID: 4406
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Paluch
Date Reported: 2015-06-29
Rejected by: Brian Haberman
Date Rejected: 2015-06-30

Section 2.5.6 says:

   Link-Local addresses are for use on a single link.  Link-Local
   addresses have the following format:

   |   10     |
   |  bits    |         54 bits         |          64 bits           |
   +----------+-------------------------+----------------------------+
   |1111111010|           0             |       interface ID         |
   +----------+-------------------------+----------------------------+

It should say:

   Link-Local addresses are for use on a single link.  Link-Local
   addresses have the following format:

   |   10     |
   |  bits    |         54 bits         |          64 bits           |
   +----------+-------------------------+----------------------------+
   |1111111010|     arbitrary value     |       interface ID         |
   +----------+-------------------------+----------------------------+

Notes:

Section 2.4 of this RFC states that link-local addresses are identified by having the prefix FE80::/10. According to this prefix, the entire range of link-local addresses covers all addresses within the range of FE80:: through FEBF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF.

The format of link-local addresses as stated in Section 2.5.6 seems to partially contradict Section 2.4 in that it fixes the internal 54 bits between the 10-bit prefix and the IID to the value of 0. If that was the case then the prefix of link-local addresses would have been in fact FE80::/64 instead of FE80::/10, and the range of link-local addresses would have been limited to FE80:: through FE80::FFFF:FFFF:FFFF:FFFF. Thus, the definition of link-local addresses as follows from Section 2.4 does not align with the definition of link-local addresses as presented in Section 2.5.6.

I suggest resolving this internal contradiction by explicitly stating in Section 2.5.6 that the internal 54 bits of a link-local address that follow the FE80::/10 prefix can be of an arbitrary value.

Thank you!
--VERIFIER NOTES--
Section 2.4 reserves the FE80::/10 prefix for use on the local link. Section 2.5.6 specifies that the current definition of a link-local address falls in the FE80::/64 prefix. The suggested change would be a technical change to a consensus-based decision. The re-definition of the link-local address would need to be driven by a draft updating RFC 4291.

Errata ID: 2466
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Rushton
Date Reported: 2010-08-16
Rejected by: Ralph Droms
Date Rejected: 2012-03-26

Section 2.2.2 says:

In order to make writing addresses containing zero
      bits easier, a special syntax is available to compress the zeros.
      The use of "::" indicates one or more groups of 16 bits of zeros.
      The "::" can only appear once in an address.

It should say:

In order to make writing addresses containing zero
      bits easier, a special syntax is available to compress the zeros.
      The use of "::" indicates two or more groups of 16 bits of zeros.
      The "::" can only appear once in an address.

Notes:

--VERIFIER NOTES--
Bob Hinden evaluated this errata:

I believe that this errata should be rejected. This was discussed on the v6ops mailing list around February 25, 2011. I responded:

http://www.ietf.org/mail-archive/web/v6ops/current/msg07741.html

The thread starts at:

http://www.ietf.org/mail-archive/web/v6ops/current/msg07722.html

Also, two errata were filed based on this one (Errata ID: 2735, Errata ID: 2702) that I think should also be rejected as they assume that this errata was correct.

Errata ID: 863
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yelland Mr Michael
Date Reported: 2007-03-02
Rejected by: RFC Editor
Date Rejected: 2008-12-03

Section 2.7 says:

   Nodes must not originate a packet to a multicast address whose scop
   field contains the reserved value 0; if such a packet is received, it
   must be silently dropped.  Nodes should not originate a packet to a
   multicast address whose scop field contains the reserved value F; ...

It should say:

   Nodes must not originate a packet to a multicast address whose scope
   field contains the reserved value 0; if such a packet is received, it
   must be silently dropped.  Nodes should not originate a packet to a
   multicast address whose scope field contains the reserved value F; ...

Notes:

Typo: scop --> scope (2 times)

-- RATIONALE FOR REJECTION --

This isn't a typo. The field is named "scop". See Section 2.7:

scop is a 4-bit multicast scope value used to limit the scope of
the multicast group.

Thanks to Bob Hinden for pointing this out.

This report was incorrectly marked "Verified" from 2007-11-01 to 2008-12-03.

Errata ID: 864
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yelland Mr Michael
Date Reported: 2007-03-02
Rejected by: RFC Editor
Date Rejected: 2008-12-03

Section 2.7 says:

   Routers must not forward any multicast packets beyond of the scope
   indicated by the scop field in the destination multicast address.

It should say:

   Routers must not forward any multicast packets beyond the scope
   indicated by the scope field in the destination multicast address.

Notes:

Typo: scop --> scope; extraneous "of"

-- RATIONALE FOR REJECTION --

This isn't a typo. The field is named "scop". See Section 2.7:

scop is a 4-bit multicast scope value used to limit the scope of
the multicast group.

Thanks to Bob Hinden for pointing this out.

This report was incorrectly marked "Verified" from 2007-11-01 to 2008-12-03.

[There is an extraneous "of", which has been listed in a separate report: Errata ID 1627.]

Errata ID: 865
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yelland Mr Michael
Date Reported: 2007-03-02
Rejected by: RFC Editor
Date Rejected: 2007-12-03

Section 2.7 says:

   Nodes must not originate a packet to a multicast address whose scop
   field contains the reserved value 0; if such a packet is received, it
   must be silently dropped.  Nodes should not originate a packet to a
   multicast address whose scop field contains the reserved value F; ...

It should say:

   Nodes must not originate a packet to a multicast address whose scope
   field contains the reserved value 0; if such a packet is received, it
   must be silently dropped.  Nodes should not originate a packet to a
   multicast address whose scope field contains the reserved value F; ...

Notes:

Typo: scop --> scope (2 times)

-- RATIONALE FOR REJECTION --

This isn't a typo. The field is named "scop". See Section 2.7:

scop is a 4-bit multicast scope value used to limit the scope of
the multicast group.

Thanks to Bob Hinden for pointing this out.

This report was incorrectly marked "Verified" from 2007-11-01 to 2008-12-03.

RFC 4294, "IPv6 Node Requirements", April 2006

Note: This RFC has been obsoleted by RFC 6434

Note: This RFC has been updated by RFC 5095

Source of RFC: ipv6 (int)

Errata ID: 138
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-04-18
Rejected by: Brian Haberman
Date Rejected: 2012-05-09

 

(1) Page 7, Section 4.4

The RFC 4294 text says:

  4.4.  ICMP for the Internet Protocol Version 6 (IPv6) - RFC 2463

     ICMPv6 [RFC-2463] MUST be supported.

It should say:

  4.4.  ICMP for the Internet Protocol Version 6 (IPv6) - RFC 4443

     ICMPv6 [RFC-4443] MUST be supported.

The title of Section 4.4 in the Table of Contents should be
adapted accordingly.

Rationale: RFC 4443 (replacing and obsoleting RFC 2463) has been
published exactly 3 weeks before RFC 4294, and hence should be
used as the currently valid reference.


(2) Page 7, Section 4.5.1

RFC 4294 says:

  4.5.1.  IP Version 6 Addressing Architecture - RFC 3513

     The IPv6 Addressing Architecture [RFC-3513] MUST be supported as
     updated by [RFC-3879].

It should say:

  4.5.1.  IP Version 6 Addressing Architecture - RFC 4291

     The IPv6 Addressing Architecture [RFC-4291] MUST be supported.

Rationale: RFC 4291 (replacing and obsoleting RFC 3513, and thereby
incorporating RFC 3879) has been published more than 8 weeks before
RFC 4294, and hence should be used as the currently valid reference.


(3) Page 8, Section 5.1

RFC 4294 says:

     DNS is described in [RFC-1034], [RFC-1035], [RFC-3152], [RFC-3363],
     and [RFC-3596].  [...]

It should say:

     DNS is described in [RFC-1034], [RFC-1035], [RFC-3363], and
     [RFC-3596].  [...]

And subsequently, where RFC 4294 says,

  -  reverse addressing in ip6.arpa using PTR records [RFC-3152];

it should say:

  -  reverse addressing in ip6.arpa using PTR records [RFC-3596];

Rationale: RFC 3152 has been obsoleted and incorporated into RFC 3596.


(4) Page 10, Section 6.1.1

RFC 4294 says:

  6.1.1.  Transition Mechanisms for IPv6 Hosts and Routers - RFC 2893

It should say:

  6.1.1.  Transition Mechanisms for IPv6 Hosts and Routers - RFC 4213

Rationale: RFC 4213 (replacing and obsoleting RFC 2893) has been
published more than 6 months before RFC 4294, and hence should be
used consistently as the currently valid reference.  (The text body
of the section has been updated accordingly, before publication.)


(5) Page 11, Section 8.2

RFC 4294 says:

  8.2.  Security Protocols

     ESP [RFC-4303] MUST be supported.  AH [RFC-4302] MUST be supported.

It should say:

  8.2.  Security Protocols

     ESP [RFC-4303] MUST be supported.  AH [RFC-4302] MAY be supported.

Rationale: The new IPsec RFCs purposely have changed the requirement
level for AH.  From RFC 4301, page 9, 1st paragraph of Section 3.2 :

               [...]  IPsec implementations MUST support ESP and MAY
   support AH. (Support for AH has been downgraded to MAY because
   experience has shown that there are very few contexts in which ESP
   cannot provide the requisite security services.  Note that ESP can be
   used to provide only integrity, without confidentiality, making it
   comparable to AH in most contexts.)

In Section 13, RFC 4301 lists the differences from RFC 2401,
and it states on page 74:

   o Support for AH in both IPv4 and IPv6 is no longer required.

RFC 4294 does not give any arguments to override these statements.

(The IPsec references in RFC 4294 apparently have been changed
 shortly before publication without due adaptation of the text.)


(6) Section 12.1, Normative References :

- The reference [RFC-2463] should be replaced by a reference to
  RFC 4443 according to item (1) above.

- The reference [RFC-3152] (last item on page 14) should be deleted.
  That RFC has been obsoleted long time ago, and the material has been
  incorporated into RFC 3596 (see the entry [RFC-3596] on page 15)
  according to item (3) above.

- The reference [RFC-3513] should be replaced by an entry [RFC-4291],
  containing the proper reference to RFC 4291, according to item (2)
  above.

- The reference [RFC-3879] is not needed any more according to
  item (2) above; the material from RFC 3879 has been incorporated
  into RFC 4291, the successor of RFC 3513 -- see item (2) above.

Notes:

from pending
--VERIFIER NOTES--
This RFC is obsolete and new implementations should be referring to RFC 6434.

RFC 4301, "Security Architecture for the Internet Protocol", December 2005

Note: This RFC has been updated by RFC 6040, RFC 7619

Source of RFC: ipsec (sec)

Errata ID: 2178
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 4.1.1. says:

SPD-S, SPD-I, SPD-O
Pages 20,21

It should say:

Needs to be formulated differently.

Notes:

This text needs information which comes later in RFC4301. There must be an explanation of decorrelation (hint on Appendix B).
The part of outbound traffic is confusing. If you have no SPD-S entries, you can handle it the same way as explained for inbound traffic.
--VERIFIER NOTES--
There is no section 4.1.1.

Errata ID: 6635
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Isaac Lewis
Date Reported: 2021-07-09
Rejected by: Benjamin Kaduk
Date Rejected: 2021-07-21

Section 3.2 says:

Note that ESP can be used to provide only integrity, without
confidentiality, making it comparable to AH in most contexts.

It should say:

Note that ESP can be used to provide both integrity and
confidentiality.

Notes:

The original sentence contradicts the following one in the same section:

o The Encapsulating Security Payload (ESP) protocol [Ken05a] offers
the same set of services, and also offers confidentiality.
--VERIFIER NOTES--
The original text is conveying the intended sentiment, namely that: despite primarily being a mechanism to provide both confidentiality and integrity protection, ESP can also be configured in a mode that only provides integrity protection and not confidentiality protection. Such a mode is essentially directly analogous to what AH provides, and thus this statement supports the downgrading of AH support to only a MAY-level requirement.

Errata ID: 2183
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Tim Polk
Date Rejected: 2010-07-20

Section 5.1. says:

There is no requirement that an 
implementation buffer the packet if 
there is a cache miss.

It should say:

There is no requirement that an 
implementation buffers the packet if
there is a cache miss.

Notes:

typo
--VERIFIER NOTES--
original text was grammatically correct.

Errata ID: 2661
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bob Briscoe
Date Reported: 2010-12-04
Rejected by: Sean Turner
Date Rejected: 2011-03-10

Section header block says:

Obsoletes: 2401

It should say:

Obsoletes: 2401
Updates: 3168

Notes:

RFC 4301 updates RFC 3168 but does not indicate this in its header block.

Specifically, RFC 4301 updates the processing of the ECN field for IPsec tunnel mode that was specified in RFC 3168.
--VERIFIER NOTES--
This action was taken already. The RFC index is already updated and so is the datatracker.

Errata ID: 4709
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Phillip H. Griffin
Date Reported: 2016-06-14
Date Rejected: 2023-08-02

Section Appendix C says:

In the ASN.1 module for this RFC, the following errors prevented syntax 
checking and compilation for programming language code generation:

1. Changed "DEFINITIONS IMPLICIT TAGS = BEGIN" to 
           "DEFINITIONS IMPLICIT TAGS ::= BEGIN"

2. Changed "SPD = SEQUENCE OF SPDEntry" to 
           "SPD ::= SEQUENCE OF SPDEntry"

3. Changed 
   "parameters  ANY -- DEFINED BY algorithm } -- defined outside" to
   "parameters  ANY } -- defined outside"

4. Changed "SPDEntry = CHOICE" to "SPDEntry := CHOICE"

5. Changed "IPsecEntry = SEQUENCE" to "IPsecEntry ::= SEQUENCE"

6. Changed "BypassOrDiscardEntry = SEQUENCE" to 
           "BypassOrDiscardEntry ::= SEQUENCE"

7. Changed "InOutBound = CHOICE" to "InOutBound ::= CHOICE"

8. Changed "iso(1) org (3) dod (6)" to 
           "iso(1) identified-organization (3) dod (6)"

A correct ASN.1 module follows in the "Corrected Text" field. 

It should say:

SPDModule { 
   iso(1) identified-organization (3) dod (6) internet (1) security (5) 
      mechanisms (5) ipsec (8) asn1-modules (3) spd-module (1) 
}
   DEFINITIONS IMPLICIT TAGS ::= BEGIN

   IMPORTS
      RDNSequence FROM PKIX1Explicit88 { 
         iso(1) identified-organization(3) dod(6) internet(1) 
            security(5) mechanisms(5) pkix(7) id-mod(0) 
               id-pkix1-explicit(18) };

-- An SPD is a list of policies in decreasing order of preference

SPD ::= SEQUENCE OF SPDEntry

SPDEntry ::= CHOICE {
           iPsecEntry       IPsecEntry,               -- PROTECT traffic
           bypassOrDiscard  [0] BypassOrDiscardEntry } -- DISCARDBYPASS

       IPsecEntry ::= SEQUENCE {       -- Each entry consists of
           name        NameSets OPTIONAL,
           pFPs        PacketFlags,    -- Populate from packet flags
                              -- Applies to ALL of the corresponding
                              -- traffic selectors in the SelectorLists
           condition   SelectorLists,  -- Policy condition
           processing  Processing      -- Policy action
}

BypassOrDiscardEntry ::= SEQUENCE {
   bypass      BOOLEAN,        -- TRUE BYPASS, FALSE DISCARD
   condition   InOutBound }

InOutBound ::= CHOICE {
           outbound    [0] SelectorLists,
           inbound     [1] SelectorLists,
           bothways    [2] BothWays }

       BothWays ::= SEQUENCE {
           inbound     SelectorLists,
           outbound    SelectorLists }

       NameSets ::= SEQUENCE {
           passed      SET OF Names-R,  -- Matched to IKE ID by
                                        -- responder
           local       SET OF Names-I } -- Used internally by IKE
                                        -- initiator

       Names-R ::= CHOICE {                   -- IKEv2 IDs
           dName       RDNSequence,           -- ID_DER_ASN1_DN
           fqdn        FQDN,                  -- ID_FQDN
           rfc822      [0] RFC822Name,        -- ID_RFC822_ADDR
           keyID       OCTET STRING }         -- KEY_ID

       Names-I ::= OCTET STRING       -- Used internally by IKE
                                      -- initiator

       FQDN ::= IA5String

       RFC822Name ::= IA5String

       PacketFlags ::= BIT STRING {
                   -- if set, take selector value from packet
                   -- establishing SA
                   -- else use value in SPD entry
           localAddr  (0),
           remoteAddr (1),
           protocol   (2),
           localPort  (3),
           remotePort (4)  }

       SelectorLists ::= SET OF SelectorList

       SelectorList ::= SEQUENCE {
           localAddr   AddrList,
           remoteAddr  AddrList,
           protocol    ProtocolChoice }

       Processing ::= SEQUENCE {
           extSeqNum   BOOLEAN, -- TRUE 64 bit counter, FALSE 32 bit
           seqOverflow BOOLEAN, -- TRUE rekey, FALSE terminate & audit
           fragCheck   BOOLEAN, -- TRUE stateful fragment checking,
                                -- FALSE no stateful fragment checking
           lifetime    SALifetime,
           spi         ManualSPI,
           algorithms  ProcessingAlgs,
           tunnel      TunnelOptions OPTIONAL } -- if absent, use
                                                -- transport mode

       SALifetime ::= SEQUENCE {
           seconds   [0] INTEGER OPTIONAL,
           bytes     [1] INTEGER OPTIONAL }

       ManualSPI ::= SEQUENCE {
           spi     INTEGER,
           keys    KeyIDs }

       KeyIDs ::= SEQUENCE OF OCTET STRING

       ProcessingAlgs ::= CHOICE {
           ah          [0] IntegrityAlgs,  -- AH
           esp         [1] ESPAlgs}        -- ESP

       ESPAlgs ::= CHOICE {
           integrity       [0] IntegrityAlgs,       -- integrity only
           confidentiality [1] ConfidentialityAlgs, -- confidentiality
                                                    -- only
           both            [2] IntegrityConfidentialityAlgs,
           combined        [3] CombinedModeAlgs }

       IntegrityConfidentialityAlgs ::= SEQUENCE {
           integrity       IntegrityAlgs,
           confidentiality ConfidentialityAlgs }

       -- Integrity Algorithms, ordered by decreasing preference

       IntegrityAlgs ::= SEQUENCE OF IntegrityAlg

       -- Confidentiality Algorithms, ordered by decreasing preference

       ConfidentialityAlgs ::= SEQUENCE OF ConfidentialityAlg

       -- Integrity Algorithms

       IntegrityAlg ::= SEQUENCE {
           algorithm   IntegrityAlgType,
           parameters  ANY -- DEFINED BY algorithm -- OPTIONAL }

       IntegrityAlgType ::= INTEGER {
           none              (0),
           auth-HMAC-MD5-96  (1),
           auth-HMAC-SHA1-96 (2),
           auth-DES-MAC      (3),
           auth-KPDK-MD5     (4),
           auth-AES-XCBC-96  (5)
       --  tbd (6..65535)
           }

       -- Confidentiality Algorithms

       ConfidentialityAlg ::= SEQUENCE {
           algorithm   ConfidentialityAlgType,
           parameters  ANY -- DEFINED BY algorithm -- OPTIONAL }

       ConfidentialityAlgType ::= INTEGER {
           encr-DES-IV64   (1),
           encr-DES        (2),
           encr-3DES       (3),
           encr-RC5        (4),
           encr-IDEA       (5),
           encr-CAST       (6),
           encr-BLOWFISH   (7),
           encr-3IDEA      (8),
           encr-DES-IV32   (9),
           encr-RC4       (10),
           encr-NULL      (11),
           encr-AES-CBC   (12),
           encr-AES-CTR   (13)
       --  tbd (14..65535)
           }

       CombinedModeAlgs ::= SEQUENCE OF CombinedModeAlg

       CombinedModeAlg ::= SEQUENCE {
           algorithm   CombinedModeType,
           parameters  ANY } -- defined outside

                                    -- of this document for AES modes.
       CombinedModeType ::= INTEGER {
           comb-AES-CCM    (1),
           comb-AES-GCM    (2)
       --  tbd (3..65535)
           }

       TunnelOptions ::= SEQUENCE {
           dscp        DSCP,
           ecn         BOOLEAN,    -- TRUE Copy CE to inner header
           df          DF,
           addresses   TunnelAddresses }

       TunnelAddresses ::= CHOICE {
           ipv4        IPv4Pair,
           ipv6        [0] IPv6Pair }

       IPv4Pair ::= SEQUENCE {
           local       OCTET STRING (SIZE(4)),
           remote      OCTET STRING (SIZE(4)) }

       IPv6Pair ::= SEQUENCE {
           local       OCTET STRING (SIZE(16)),
           remote      OCTET STRING (SIZE(16)) }

       DSCP ::= SEQUENCE {
           copy      BOOLEAN, -- TRUE copy from inner header
                              -- FALSE do not copy
           mapping   OCTET STRING OPTIONAL} -- points to table
                                            -- if no copy
       DF ::= INTEGER {
           clear   (0),
           set     (1),
           copy    (2) }

       ProtocolChoice::= CHOICE {
           anyProt  AnyProtocol,              -- for ANY protocol
           noNext   [0] NoNextLayerProtocol,  -- has no next layer
                                              -- items
           oneNext  [1] OneNextLayerProtocol, -- has one next layer
                                              -- item
           twoNext  [2] TwoNextLayerProtocol, -- has two next layer
                                              -- items
           fragment FragmentNoNext }          -- has no next layer
                                              -- info

       AnyProtocol ::= SEQUENCE {
           id          INTEGER (0),    -- ANY protocol
           nextLayer   AnyNextLayers }

       AnyNextLayers ::= SEQUENCE {      -- with either
           first       AnyNextLayer,     -- ANY next layer selector
           second      AnyNextLayer }    -- ANY next layer selector

       NoNextLayerProtocol ::= INTEGER (2..254)

       FragmentNoNext ::= INTEGER (44)   -- Fragment identifier

       OneNextLayerProtocol ::= SEQUENCE {
           id          INTEGER (1..254),   -- ICMP, MH, ICMPv6
           nextLayer   NextLayerChoice }   -- ICMP Type*256+Code
                                           -- MH   Type*256

       TwoNextLayerProtocol ::= SEQUENCE {
           id          INTEGER (2..254),   -- Protocol
           local       NextLayerChoice,    -- Local and
           remote      NextLayerChoice }   -- Remote ports

       NextLayerChoice ::= CHOICE {
           any         AnyNextLayer,
           opaque      [0] OpaqueNextLayer,
           range       [1] NextLayerRange }

       -- Representation of ANY in next layer field

       AnyNextLayer ::= SEQUENCE {
           start       INTEGER (0),
           end         INTEGER (65535) }

       -- Representation of OPAQUE in next layer field.
       -- Matches IKE convention

       OpaqueNextLayer ::= SEQUENCE {
           start       INTEGER (65535),
           end         INTEGER (0) }

-- Range for a next layer field

NextLayerRange ::= SEQUENCE {
   start  INTEGER (0..65535),
   end    INTEGER (0..65535) 
}

-- List of IP addresses

AddrList ::= SEQUENCE {
   v4List  IPv4List OPTIONAL,
   v6List  [0] IPv6List OPTIONAL
}

-- IPv4 address representations

IPv4List ::= SEQUENCE OF IPv4Range

IPv4Range ::= SEQUENCE {    -- close, but not quite right ...
   ipv4Start  OCTET STRING (SIZE (4)),
   ipv4End    OCTET STRING (SIZE (4)) 
}

-- IPv6 address representations

IPv6List ::= SEQUENCE OF IPv6Range

IPv6Range ::= SEQUENCE {    -- close, but not quite right ...
   ipv6Start  OCTET STRING (SIZE (16)),
   ipv6End    OCTET STRING (SIZE (16)) 
}

END

Notes:

Note that I included an ASN.1 module stub to resolve an imported value in the module.

PKIX1Explicit88 {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18)
}
DEFINITIONS EXPLICIT TAGS ::= BEGIN

RDNSequence ::= SEQUENCE {}

END -- PKIX1Explicit88 --
--VERIFIER NOTES--
This is for RFC4301 and tries to fix the ASN.1 in Appendix C.
The proposed changes uses lines which are not part of the
RFC4301, i.e., the "=" -> "::=" that are listed as needed to
be done, are already "::=" in the RFC4301.

The only other proposed changes are to remove
"-- DEFINED BY algorithm" from one location, but it
leaves it in in few other places. It also proposes to change
iso(1) org (3) dod (6)" to "iso(1) identified-organization (3)
dod (6) which might be correct, but is not needed.

RFC 4302, "IP Authentication Header", December 2005

Source of RFC: ipsec (sec)

Errata ID: 2188
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-30

Section 3.3.3.2.2. says:

If padding bytes are needed
but the algorithm does not specify the padding contents, then the
padding octets MUST have a value of zero.

It should say:

The padding bytes MUST be zero. The algorithm MUST NOT specify
anything else.

Notes:

This is forced two times in this RFC4302, namely before in this
section 3.3.3.2.2 and in 3.4.4 .
--VERIFIER NOTES--
Section 3.4.4 deals with verification of the ICV, whereas section 3.3.3 deal with generation of an ICV. Thus discussion of padding is needed in both contexts and is not redundant. The text should remain as it is.

Errata ID: 2189
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 3.4.3. says:

received Sequence Number against the receive window.  In constructing
the full sequence number, if the low-order 32 bits carried in the
packet are lower in value than the low-order 32 bits of the
receiver's sequence number counter, the receiver assumes that the
high-order 32 bits have been incremented, moving to a new sequence
number subspace.  (This algorithm accommodates gaps in reception for

It should say:

received Sequence Number against the receive window.  In constructing
the full sequence number, if the low-order 32 bits carried in the
packet are lower in value than the low-order 32 bits of the
receiver's left edge's sequence number counter, the receiver assumes
that the
high-order 32 bits have been incremented, moving to a new sequence
number subspace.  (This algorithm accommodates gaps in reception for

Notes:

--VERIFIER NOTES--
There is no mention of a "left edge sequence number counter" in 4302.

Errata ID: 2185
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 2.4. says:

datagrams to SAs.  Implementations that support only unicast traffic
need not implement this de-multiplexing algorithm.

It should say:

datagrams to SAs.  Implementations that support only unicast traffic
need not to implement this de-multiplexing algorithm.

Notes:

grammar
--VERIFIER NOTES--
The original text is grammatically correct.

Errata ID: 2186
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Tim Polk
Date Rejected: 2010-07-20

Section 2.5. says:

Verification".  Thus, the sender MUST always transmit this field, but
the receiver need not act upon it.

It should say:

Verification".  Thus, the sender MUST always transmit this field, but
the receiver needs not to act upon it.

Notes:

grammar
--VERIFIER NOTES--
The original text is grammatically correct.

Errata ID: 2187
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Tim Polk
Date Rejected: 2010-07-20

Section 3.3.3.2.1. says:

(The padding is arbitrary, but need not be random to achieve
security.)  These padding bytes are included in the ICV calculation,

It should say:

(The padding is arbitrary, but needs not to be random to achieve
security.)  These padding bytes are included in the ICV calculation,

Notes:

grammar
--VERIFIER NOTES--
The original text is grammatically correct.

RFC 4306, "Internet Key Exchange (IKEv2) Protocol", December 2005

Note: This RFC has been obsoleted by RFC 5996

Note: This RFC has been updated by RFC 5282

Source of RFC: ipsec (sec)

Errata ID: 2193
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-05-07

Section 3.3.5. says:

         Attribute Type                 Value        Attribute Format
      --------------------------------------------------------------
      RESERVED                           0-13 Key Length (in bits)
      14                 TV RESERVED                           15-17
      RESERVED TO IANA                   18-16383 PRIVATE USE
      16384-32767

   Values 0-13 and 15-17 were used in a similar context in IKEv1 and
   should not be assigned except to matching values.  Values 18-16383
   are reserved to IANA.  Values 16384-32767 are for private use among
   mutually consenting parties.

   - Key Length

      When using an Encryption Algorithm that has a variable-length key,
      this attribute specifies the key length in bits (MUST use network
      byte order).  This attribute MUST NOT be used when the specified
      Encryption Algorithm uses a fixed-length key.

It should say:

?

Notes:

I do not understand anything.
Therefore I cannot offer a better formulation.
--VERIFIER NOTES--
No alternative text was proposed. Note that I did forward this to the authors of draft-ietf-ipsecme-ikev2bis.

RFC 4309, "Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)", December 2005

Source of RFC: ipsec (sec)

Errata ID: 129
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-02-03
Rejected by: Russ Housley

Section 5 says:

On page 6, the second paragraph of Section 5 says:

   Sequence Numbers are conveyed canonical network byte order.  Extended
   Sequence Numbers are conveyed canonical network byte order, placing
   the high-order 32 bits first and the low-order 32 bits second.
   Canonical network byte order is fully described in RFC 791, Appendix
   B.

The text should perhaps better say:

   Sequence Numbers are conveyed in canonical network byte order.
   Extended Sequence Numbers are conveyed in canonical network byte
   order, placing the high-order 32 bits first and the low-order 32 bits
   second.  Canonical network byte order is fully described in RFC 791,
   Appendix B.

The second half-sentence of the second sentence might even be considered
redundant, fully comprised by the term 'canonical network byte order',
and hence be omitted entirely.  Doing that, and following the maxim of
"making RFC text as simple as possible", the above text might be
abreviated to say:

   Sequence Numbers and Extended Sequence Numbers are conveyed in
   canonical network byte order.  Canonical network byte order is fully
   described in RFC 791, Appendix B.

Finally, considering that the SPI is a 32-bit number and covered by
the same ordering rule as well, the text might - even shorter - say:

   All fields are conveyed in canonical network byte order.  Canonical
   network byte order is fully described in RFC 791, Appendix B.

Please decide whether the initial text correction deserves an
Errata Note, possibly including the additional enhancement(s).

Notes:

word omissions - and opportunity to simplify the text

NOTE (2006-02-13)
I do not think that any of these will lead to confusion or
interoperability concerns. Thus, I do not think that they warrant
the time and other resources need to generate Errata.
Russ Housley

from pending

RFC 4322, "Opportunistic Encryption using the Internet Key Exchange (IKE)", December 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 125
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-20
Rejected by: Sean Turner
Date Rejected: 2010-08-06

Section General says:

It's a pity that RFC 4322, published a few days *after* the new IPsec
RFCs including the IKEv2 specification (RFC 4306), does not give a
perspective on Opportunistic Encryption in the context of IKEv2.

Notes:

To facilitate the recognition of the text changes proposed,
I have added change bars ('|') in column 1, and up/down pointing
marker lines ('^^^'/'vvv').
--VERIFIER NOTES--
No action proposed.

RFC 4327, "Link Management Protocol (LMP) Management Information Base (MIB)", January 2006

Note: This RFC has been obsoleted by RFC 4631

Source of RFC: ccamp (rtg)

Errata ID: 1938
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-02-24
Rejected by: Adrian Farrel
Date Rejected: 2009-10-30

 

(9)  lmpCcHelloInterval OBJECT-TYPE  (page 21)

An established 'default' specifies the value of a (newly created)
tabular object to be used when this object is not SET explicitely.
Hence,

   DESCRIPTION
       "This object specifies the value of the HelloInterval
        parameter.  The default value for this object should be
        set to lmpCcHelloIntervalDefault."
   ::= { lmpControlChannelEntry 10 }

should better say:

   DESCRIPTION
       "This object specifies the value of the HelloInterval
|       parameter.  The default value to be used for this object
|       is lmpCcHelloIntervalDefault."
   ::= { lmpControlChannelEntry 10 }


(9')   lmpCcHelloIntervalMin OBJECT-TYPE  (page 21) ,
(9'')  lmpCcHelloIntervalMax OBJECT-TYPE  (page 21/22) ,
(10)   lmpCcHelloDeadInterval OBJECT-TYPE  (page 22) ,
(10')  lmpCcHelloDeadIntervalMin OBJECT-TYPE  (page 22) , and
(10'') lmpCcHelloDeadIntervalMax OBJECT-TYPE  (page 22)

The change from item (9) above should be applied there similarly:

Replace the phrase,

           "[...].  The default value for this object should be
        set to lmp<*>Default."

by:

|          "[...].  The default value to be used for this object
|       is lmp<*>Default."

using, at all instances, the appropriate value for the placeholder <*>.


(13)  lmpTeLinkEntry OBJECT-TYPE  (page 36)

The DESCRIPTION clause contains the sentence:

                                                      [...].  The
        administrative status value is controlled from the ifEntry.
        [...]

This sentence should say:

                                                      [...].  The
|       administrative status is controlled from the ifEntry.
        [...]


(19)  lmpDataLinkEntry OBJECT-TYPE  (page 51)

The correction from item (13) above is to be applied here as well:

The sentence in the DESCRIPTION clause,

                   [...].  The administrative status value is
        controlled from the ifEntry.  [...]

should say:

|                  [...].  The administrative value is
        controlled from the ifEntry.  [...]


(22)  lmpNodeGroup OBJECT-GROUP  (page 71/72)

Near the top of page 72, the RFC says:

   DESCRIPTION
          "Collection of objects that represent LMP node
           configuration."
   ::= { lmpGroups 1 }

It should say:

   DESCRIPTION
|         "Collection of objects that represents the LMP node
           configuration."
   ::= { lmpGroups 1 }

[ In fact, it is *the collection* (singular) that represents
  the node configuration! ]


(24)  lmpDataLinkGroup OBJECT-GROUP  (page 76)

Similar to item (22) above, the clause,

   DESCRIPTION
          "Collection of objects that represent data-bearing link
           configuration."
   ::= { lmpGroups 9 }

should better say:

   DESCRIPTION
          "Collection of objects that represents data-bearing link
           configurations."
   ::= { lmpGroups 9 }

It should say:

[see above]

Notes:

Verifier's analysis:

9. No. Editorial change of no substance.
9' No. Editorial change of no substance.
9" No. Editorial change of no substance.
10. No. Editorial change of no substance.
10' No. Editorial change of no substance.
10" No. Editorial change of no substance.
13. No. The value is controlled, not the status.
19. No. The value is controlled, not the status.
22. No. The English is correct.
24. No. The English is correct.

Verified items are in Errata ID 705.

RFC 4330, "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", January 2006

Note: This RFC has been obsoleted by RFC 5905

Source of RFC: INDEPENDENT

Errata ID: 5895
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Daniel Loffgren
Date Reported: 2019-11-07
Rejected by: Adrian Farrel
Date Rejected: 2019-11-07

Section 4 says:

   Root Delay: This is a 32-bit signed fixed-point number indicating the
   total roundtrip delay to the primary reference source, in seconds
   with the fraction point between bits 15 and 16.  Note that this
   variable can take on both positive and negative values, depending on
   the relative time and frequency offsets.  This field is significant
   only in server messages, where the values range from negative values
   of a few milliseconds to positive values of several hundred
   milliseconds.

It should say:

   Root Delay: This is a 32-bit unsigned fixed-point number indicating
   the total roundtrip delay to the primary reference source, in seconds
   with the fraction point between bits 15 and 16.  This field is
   significant only in server messages.

Notes:

RFC 4330 claims the root delay is a number indicating the "total roundtrip delay to the primary reference source". As the minimum amount of time it can take to reach the other server is zero, the delay must be greater than or equal to zero. A sign should never be necessary for root delay alone.

NTPv3 (RFC 1305) defines the root delay type to be "…a signed fixed-point number indicating the total roundtrip delay to the primary reference source at the root of the synchronization subnet, in seconds. Note that this variable can take on both positive and negative values, depending on clock precision and skew."

While NTPv3 clearly indicates that it should be signed, it should still never be possible to populate this with a negative value since it is still a total roundtrip delay.

NTPv4 (RFC 5905) changes the root delay type to be the NTP Short Format, which "…includes a 16-bit unsigned seconds field and a 16-bit fraction field."

RFC 5905's Code Skeleton also has implementations that treat the root delay field as entirely unsigned:
/*
* Timestamp conversion macroni
*/
#define FRIC 65536. /* 2^16 as a double */
#define D2FP(r) ((tdist)((r) * FRIC)) /* NTP short */
#define FP2D(r) ((double)(r) / FRIC)
…
p->rootdelay = FP2D(r->rootdelay);
…
x.rootdelay = D2FP(s.rootdelay);
--VERIFIER NOTES--
RFC 4330 has been obsoleted by RFC 5905, an IETF standards track document. It is, therefore, inappropriate to continue to make errata reports against RFC 4330.

It may be worth noting that in RFC 5905, the 'Root Delay' field of the NTP message is described as:

Total round-trip delay to the reference clock, in NTP short format.

Errata ID: 6436
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Ellen Marie Dash
Date Reported: 2021-02-22
Rejected by: Adrian Farrel
Date Rejected: 2021-02-24

Section 5 says:

   The roundtrip delay d and system clock offset t are defined as:

      d = (T4 - T1) - (T3 - T2)     t = ((T2 - T1) + (T3 - T4)) / 2.

It should say:

   The roundtrip delay d and system clock offset t are defined as:

      d = (T4 - T1) - (T3 - T2)     t = ((T2 - T1) + (T4 - T3)) / 2.

Notes:

In the equation for "t", the values T3 and T4 are swapped. This can cause the value to be off by over 120 years.
--VERIFIER NOTES--
Note that:
- RFC 4330 has been obsoleted by RFC 5905 so raising errata reports against it is no longer
valuable
- RFC 5905 contains the same text as reported here
- There is already an errata report (https://www.rfc-editor.org/errata_search.php?eid=5020)
against RFC 5905 reporting this problem.

RFC 4343, "Domain Name System (DNS) Case Insensitivity Clarification", January 2006

Note: This RFC has been updated by RFC 5890

Source of RFC: dnsext (int)

Errata ID: 119
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2006-02-26
Rejected by: Brian Haberman
Date Rejected: 2012-04-30

Section 1 says:

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

It should say:

   The key words "MUST" and "MAY" in this document are to be
   interpreted as described in [RFC2119].

Notes:

Other than in the above-quoted sentence, there are no
instances of "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", SHOULD",
"SHOULD NOT", "RECOMMENDED", or "OPTIONAL" in the RFC (and the
instances above surely cannot be interpreted as described in RFC
2119; they are mere labels in the context of that sentence).
--VERIFIER NOTES--
The keyword paragraph is standard, and although words are mentioned that are later not used, this is not an error.

RFC 4357, "Additional Cryptographic Algorithms for Use with GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms", January 2006

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 4221
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Dick Franks
Date Reported: 2015-01-05
Rejected by: Kathleen Moriarty
Date Rejected: 2015-03-31

Section 11.4 says:

163 30  159:  SEQUENCE {
166 06    7:   OBJECT IDENTIFIER
           :    id-GostR3410-2001-CryptoPro-A-ParamSet
175 30  147:   SEQUENCE {
178 02   33:    INTEGER
           :     00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
           :     FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FD
           :     94
213 02    2:    INTEGER 166
217 02   33:    INTEGER
           :     00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
           :     FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FD
           :     97
...

It should say:

163 30  159:  SEQUENCE {
166 06    7:   OBJECT IDENTIFIER
           :    id-GostR3410-2001-CryptoPro-A-ParamSet
175 30  147:   SEQUENCE {
178 02   33:    INTEGER
           :     00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
           :     FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FD
           :     94
213 02    2:    INTEGER A6
217 02   33:    INTEGER
           :     00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
           :     FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FD
           :     97
...

Notes:

EC parameter 'b' is incorrectly specified using its base10 value where base16 expected.
--VERIFIER NOTES--
From Jim Schaad:
Short integers are dumped by the tool using base 10 not base 16. This was auto generated from the tool.

The difference in the format easy to see from the single line to the multiple line for base16 dumps.

(At best it is editorial in terms of clarification between bases)

RFC 4360, "BGP Extended Communities Attribute", February 2006

Note: This RFC has been updated by RFC 7153, RFC 7606

Source of RFC: idr (rtg)

Errata ID: 4944
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yang Yu
Date Reported: 2017-02-21
Rejected by: Alvaro Retana
Date Rejected: 2017-02-23

Throughout the document, when it says:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Type high    |  Type low(*)  |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          Value                |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             0 1 2 3 4 5 6 7
            +-+-+-+-+-+-+-+-+
            |I|T|           |
            +-+-+-+-+-+-+-+-+

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 0x00 or 0x40  |   Sub-Type    |    Global Administrator       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Local Administrator                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 0x01 or 0x41  |   Sub-Type    |    Global Administrator       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Global Administrator (cont.)  |    Local Administrator        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 0x03 or 0x43  |   Sub-Type    |                Value          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Value (cont.)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Type high    |  Type low(*)  |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          Value                |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            0 1 2 3 4 5 6 7
            +-+-+-+-+-+-+-+-+
            |I|T|           |
            +-+-+-+-+-+-+-+-+

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 0x00 or 0x40  |   Sub-Type    |    Global Administrator       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Local Administrator                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 0x01 or 0x41  |   Sub-Type    |    Global Administrator       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Global Administrator (cont.)  |    Local Administrator        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 0x03 or 0x43  |   Sub-Type    |                Value          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Value (cont.)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

The packet format convention used in this RFC is different from how it is commonly used.
--VERIFIER NOTES--
While the format used may not be the "common" one, the representation is clear and there's no need for this errata.

RFC 4363, "Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering, and Virtual LAN Extensions", January 2006

Source of RFC: bridge (ops)

Errata ID: 2680
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: *Zhong* Qiyao
Date Reported: 2011-01-04
Rejected by: Ron Bonica
Date Rejected: 2011-01-24

Section MIB says:

> Dear IETF Person-in-Charge,
>
>      We found that Q-BRIDGE-MIB (RFC 2674) had its content corrected
> using the RFC 4363.
>
>      While this kind of update and grammatical correction is a good
> thing,
> we found that:
>
> << old ("which" as correlative pronoun)
>        "The number of valid frames received by this port from
>        its segment which were classified as belonging to this
>        VLAN which were discarded due to VLAN related reasons.
>        Specifically, the IEEE 802.1Q counters for Discard
>        Inbound and Discard on Ingress Filtering."
> >>
>
> << new ("that" as correlative pronoun)
>        "The number of valid frames received by this port from
>        its segment that were classified as belonging to this
>        VLAN and that were discarded due to VLAN-related reasons.
>        Specifically, the IEEE 802.1Q counters for Discard
>        Inbound and Discard on Ingress Filtering."
> >>
>
>      According to our education, "which" is correct, and "that" is
> only
> colloquial.  But Microsoft Word seems to reject the use of "which" in
> such
> situations, and it may have mis-lead IETF into thinking that the Q-
> BRIDGE-MIB
> should remove "which" and use "that", which is a pity.
>
>      Thanks.
>
>                                        Qiyao #3165 &#37758;&#21855;&#22575;&#12288;&#19978;
> --------------------------------------------------------------------------
> *Zhong* Qiyao, Xinzhu, Tajvano ~{VSFtR"~}
> Greg 2009.12.13-19
> --------------------------------------------------------------------------

Notes:

Many places.
--VERIFIER NOTES--
Please see http://www.chicagomanualofstyle.org/CMS_FAQ/Whichvs.That/Whichvs.That01.html for details

Ron Bonica

RFC 4364, "BGP/MPLS IP Virtual Private Networks (VPNs)", February 2006

Note: This RFC has been updated by RFC 4577, RFC 4684, RFC 5462

Source of RFC: l3vpn (int)

Errata ID: 3647
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bharat Joshi
Date Reported: 2013-06-12
Rejected by: Brian Haberman
Date Rejected: 2013-06-13

Section 3.2 says:

If it is desired to have a particular host be in multiple virtual
sites, then that host must determine, for each packet, which virtual
site the packet is associated with.

It should say:

If it is desired to have a particular host to be in multiple virtual 
sites, then that host must determine, for each packet, which virtual 
site the packet is associated with.

Notes:

'host be' should be 'host to be'
--VERIFIER NOTES--
The original text is correct.

Errata ID: 3648
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bharat Joshi
Date Reported: 2013-06-12
Rejected by: Brian Haberman
Date Rejected: 2013-06-13

Section 4 says:

If two
routes to the same IP address prefix are actually routes to different
systems, it is important to ensure that BGP not treat them as
comparable.

It should say:

If two 
routes to the same IP address prefix are actually routes to two different
systems, it is important to ensure that BGP not treat them as comparable.

Notes:

'routes to different system' should be 'routes to two different system'
--VERIFIER NOTES--
The original text is correct.

RFC 4366, "Transport Layer Security (TLS) Extensions", April 2006

Note: This RFC has been obsoleted by RFC 5246, RFC 6066

Note: This RFC has been updated by RFC 5746

Source of RFC: tls (sec)

Errata ID: 111
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-05-29
Rejected by: David Hopwood
Date Rejected: 2006-05-29

 

(1)  imprecise syntax description for `ciphersuites`

This is an issue inherited from RFC 2246, RFC 3546, and RFC 4346;
I already have reported this issue against RFC 4346 (and RFC 4347
as well).

Section 7.4.1.2 of RFC 4346, on page 37 of RFC 4346 defines the syntax:

      uint8 CipherSuite[2];    /* Cryptographic suite selector */

According to the specifications given in Section 4.3 of RFC 4346,
vectors of type CipherSuite strictly must have byte lengths being
a multiple of 2.
This also means that the upper bound for a varaiable-length array
of type CipherSuite should always be a multiple of 2.

Hence, the declaration in Section 2.1 of RFC 4366 (on page 5),
an extended version of the basic declaration in Section 7.4.1.2
of RFC 4346 (on top of page 38), stating

         struct {
             ProtocolVersion client_version;
             Random random;
             SessionID session_id;
             CipherSuite cipher_suites<2..2^16-1>;
             CompressionMethod compression_methods<1..2^8-1>;
             Extension client_hello_extension_list<0..2^16-1>;
         } ClientHello;

should better say:

         struct {
             ProtocolVersion client_version;
             Random random;
             SessionID session_id;
|            CipherSuite cipher_suites<2..2^16-2>;
             CompressionMethod compression_methods<1..2^8-1>;
             Extension client_hello_extension_list<0..2^16-1>;
         } ClientHello;


(2)  incomplete semantics specified for "server_name" extension

Section 3.1 of RFC 4366, on page 9, defines the "server_name"
extension as containing a *list* of `ServerName` structures.

On page 10, the same section says:

   It is RECOMMENDED that clients include an extension of type
   "server_name" in the client hello whenever they locate a server by a
   supported name type.

   A server that receives a client hello containing the "server_name"
   extension MAY use the information contained in the extension to guide
   its selection of an appropriate certificate to return to the client,
   and/or other aspects of security policy.  In this event, the server
   SHALL include an extension of type "server_name" in the (extended)
   server hello.  The "extension_data" field of this extension SHALL be
   empty.

   If the server understood the client hello extension but does not
|  recognize the server name, it SHOULD send an "unrecognized_name"
             ^^^
   alert (which MAY be fatal).

and on page 19, Section 4 defines the error alert,

   -  "unrecognized_name": this alert is sent by servers that receive a
|     server_name extension request, but do not recognize the server
      name.  This message MAY be fatal.                   ^^^

All these clauses apparently state the semantics for the "server_name"
extension solely in the case where the data field of the extension in
the (extended) Client Hello contains a *single* `ServerName` structure.

IMHO, if the client, as allowed by the syntax, indeed specifies
multiple names in the "server_name" extension -- a feature that
seems to be useful in certain scenarios --, it needs to get feedback
from the server as to which of the specified names has been used for
the purpose described in the second paragraph cited above.
Hence, the server should better be instructed by the specification
to include the selected name in the "server_name" extension returned
to the client in the (extended) Server Hello.
For backwards compatibility, the specification should perhaps
prescribe to omit this feedback, reverting to the specification
cited above) in the case that the Client Hello received contained
only a single server name.

In parallel, the semantics of the "unrecognized_name" alerts should
be amended to mean: all received names are unrecognized.


(3)  incomplete / outdated referencing text

The paragraph of Section 3.2 spanning from page 11 to page 12, says:

                               [...].  For example, if the negotiated
<page break>
   length is 2^9=512, then for currently defined cipher suites (those
   defined in [TLS], [KERB], and [AESSUITES]), and when null compression
   is used, the record layer output can be at most 793 bytes: 5 bytes of
   headers, 512 bytes of application data, 256 bytes of padding, and 20
   bytes of MAC.  [...]

This apparently is not up to date.  I propose to either substitute
"[TLSbis]," for "[TLS]," in the text above -- thus referring only to
current specifications --, or even to substitute "[TLS] and [TLSbis],"
for "[TLS]," there -- thus honoring to the predecessor.


(4)   spurious blank line

Within Section 3.6, the 5th paragraph on page 18 is interrupted
by a blank line in the middle of a sentence.
Perhaps this is a formatting artifact inherited from the page break
that was at this place in the text in RFC 3546.

Thus, the text body:

   Servers return a certificate response along with their certificate by
   sending a "CertificateStatus" message immediately after the
   "Certificate" message (and before any "ServerKeyExchange" or
   "CertificateRequest" messages).  If a server returns a
|
   "CertificateStatus" message, then the server MUST have included an
   extension of type "status_request" with empty "extension_data" in the
   extended server hello.

should be joined to say:

   Servers return a certificate response along with their certificate by
   sending a "CertificateStatus" message immediately after the
   "Certificate" message (and before any "ServerKeyExchange" or
   "CertificateRequest" messages).  If a server returns a
   "CertificateStatus" message, then the server MUST have included an
   extension of type "status_request" with empty "extension_data" in the
   extended server hello.


(5)  punctuation issue in Informative Reference

The following Informative Reference entry on page 28 contains
syntactically inconsistent punctuation:

   [MAILINGLIST]  J. Mikkelsen, R. Eberhard, and J. Kistler, "General
                  ClientHello extension mechanism and virtual hosting,"
                  ietf-tls mailing list posting, August 14, 2000.

should say:

   [MAILINGLIST]  J. Mikkelsen, R. Eberhard, and J. Kistler, "General
|                 ClientHello extension mechanism and virtual hosting",
                  ietf-tls mailing list posting, August 14, 2000.

Notes:

All excerpts from the RFC text are taken literally, keeping their
original formatting, and modified text is formatted in conformance
with RFC guidelines again.

I use change bars ('|' in column 1) and casual up/down pointing
tags ('^^^' / 'vvv' marks in extra lines) to emphasize the location
of textual issues and/or proposed textual enhancements/corrections.

Issue (2) above certainly needs discussion; perhaps you know what
once was intended. The other issues seem to be straightforward.

from pending

RFC 4379, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", February 2006

Note: This RFC has been obsoleted by RFC 8029

Note: This RFC has been updated by RFC 5462, RFC 6424, RFC 6425, RFC 6426, RFC 6829, RFC 7506, RFC 7537, RFC 7743

Source of RFC: mpls (rtg)

Errata ID: 3934
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nobo Akiya
Date Reported: 2014-03-26
Rejected by: Adrian Farrel
Date Rejected: 2014-03-28

Section 4.5 says:

If the Reply Mode in the echo request is "Reply via an
IPv4 UDP packet with Router Alert", then the IP header MUST contain
the Router Alert IP option.

It should say:

If the Reply Mode in the echo request is "Reply via an
IPv4/IPv6 UDP packet with Router Alert", then the IP header MUST contain
the Router Alert IP option.

Notes:

IPv4 -> IPv4/IPv6
--VERIFIER NOTES--
The issue noted is valid, but the fix is more complicated because the IPv6 solution does not work "out of the box".

After discussion with the Reporter, the RFC authors, and the WG chairs, it is agreed that the situation will be fixed both by a quick I-D to allocate the necessary code points to make IPv6 work, and by a bus to this RFC for the necessary updates.

RFC 4388, "Dynamic Host Configuration Protocol (DHCP) Leasequery", February 2006

Note: This RFC has been updated by RFC 6148

Source of RFC: dhc (int)

Errata ID: 3516
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-02
Rejected by: Ralph Droms
Date Rejected: 2013-03-09

 

(1)  [word omission]

The second paragraph of section 4.2 of RFC 4388 says:

   The DHCP Server MIB effort [DHCPMIB] grew out of traffic engineering
   and troubleshooting activities at large DHCP installations, and is
   primarily intended as a method of gathering performance statistics
   about servers the load presented to them.

It should perhaps better say:

   The DHCP Server MIB effort [DHCPMIB] grew out of traffic engineering
   and troubleshooting activities at large DHCP installations, and is
   primarily intended as a method of gathering performance statistics
|  about servers and the load presented to them.
                ^^^^^


(2)  [improper wording]

RFC 4388 repeatedly talks about

   "[an] IP address most recently accessed by a client"
                                  ^^^^^^^^^^^
where, IMHO, it should talk about

|  "[an] IP address most recently assigned to a client"
                                  ^^^^^^^^^^^
Rationale:
  The client may access any IP address at any time.  Such access
  is mostly unrelated to the protocol described in RFC 4338.

The affected places in the text I found are:
- Section 5, first paragraph of both the second and the third
  bulleted items, on page 10 / 11, respectively;
- Last paragraph on page 17 (within section 6.4.1).


(3)  [incomplete specification]

The second paragraph of Section 6.4.1, on page 17, says:

   In the event that an IP address appears in the "ciaddr" field of a
   DHCPLEASEQUERY message, if that IP address is one managed by the DHCP
   server, then that IP address MUST be set in the "ciaddr" field of a
   DHCPLEASEUNASSIGNED message.

It should in fact say:

   In the event that an IP address appears in the "ciaddr" field of a
   DHCPLEASEQUERY message, if that IP address is one managed by the DHCP
   server, then that IP address MUST be set in the "ciaddr" field of a
|  DHCPRELEASEACTIVE or DHCPLEASEUNASSIGNED message returned.
   ^^^^^^^^^^^^^^^^^^^^^                           ^^^^^^^^^

Rationale:
  From the remaining text, it can be inferred that the "ciaddr"
  field from the DHCPLEASEQUERY message should be copied to an
  DHCPRELEASEACTIVE reply message as well -- cf. section 6.4.2.

IMHO, this copy should be performed generally, i.e. also in the case
described by the subsequent paragraph:

   If the IP address is not managed by the DHCP server, then a
   DHCPLEASEUNKNOWN message must be returned.

that therefore might be amended to say:

   If the IP address is not managed by the DHCP server, then a
|  DHCPLEASEUNKNOWN message MUST be returned, with that IP address
|  set in the "ciaddr" field.

[The original 'must' should be a 'MUST' because the alternatives
are also specified as a 'MUST' -- or else the specification would
be incomplete.]

Taken together, it might be preferable to restate this fact by
only changing the first paragraph cited above as follows, and leave
the second paragraph unchanged with the exception of the 'must':

   In the event that an IP address appears in the "ciaddr" field of a
|  DHCPLEASEQUERY message, then that IP address MUST be set in the
|  "ciaddr" field of any reply returned.

|  If that IP address is one managed by the DHCP server, then it MUST
|  reply with a DHCPRELEASEACTIVE or DHCPLEASEUNASSIGNED message.

   If the IP address is not managed by the DHCP server, then a
|  DHCPLEASEUNKNOWN message MUST be returned.

Please comment on which alternative you prefer.

Notes:

from pending
--VERIFIER NOTES--
Tool error

RFC 4413, "TCP/IP Field Behavior", March 2006

Source of RFC: rohc (tsv)

Errata ID: 4277
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Justin Yirka
Date Reported: 2015-02-23
Rejected by: Martin Stiemerling
Date Rejected: 2015-12-16

Section 2.1.1 says:

| DSCP*               |      6      |   ALTERNATING  |

It should say:

| DSCP*               |      6      |    CHANGING    |

Notes:

Fields marked as changing are classified as alternating, irregular, etc., in section 4 and Figure 11.
Classifying DSCP as alternating in Figure 1 implies a possible distinction between changing and alternating, despite alternating being a subclass of changing.
--VERIFIER NOTES--
The value ALTERNATING is correct, even though it is a subset of CHANGING.

Errata ID: 4278
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Justin Yirka
Date Reported: 2015-02-23
Rejected by: Martin Stiemerling
Date Rejected: 2015-12-16

Section 2.1.2 says:

| DSCP*               |      6      |   ALTERNATING  |

It should say:

| DSCP*               |      6      |    CHANGING    |

Notes:

Fields marked as changing are classified as alternating, irregular, etc., in section 4 and Figure 11.
Classifying DSCP as alternating in Figure 3 implies a possible distinction between changing and alternating, despite alternating being a subclass of changing.
--VERIFIER NOTES--
The value ALTERNATING is correct, even though it is a subset of CHANGING.

RFC 4443, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", March 2006

Note: This RFC has been updated by RFC 4884

Source of RFC: ipv6 (int)

Errata ID: 4445
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Dennis Ferguson
Date Reported: 2015-08-15
Rejected by: Brian Haberman
Date Rejected: 2015-09-15

Section 3.1 says:

   ICMPv6 Fields:

   Type           1

   Code           0 - No route to destination
[...]
                  5 - Source address failed ingress/egress policy
                  6 - Reject route to destination
[...]
   If the reason for the failure to deliver is lack of a matching entry
   in the forwarding node's routing table, the Code field is set to 0.
   (This error can occur only in nodes that do not hold a "default
   route" in their routing tables.)
[...]
   If the reason for the failure to deliver is that the route to the
   destination is a reject route, the Code field is set to 6.  This may
   occur if the router has been configured to reject all the traffic for
   a specific prefix.

   Codes 5 and 6 are more informative subsets of code 1.

It should say:

   ICMPv6 Fields:

   Type           1

   Code           0 - No route to destination
[...]
                  5 - Source address failed ingress/egress policy
                  6 - Destination address failed ingress/egress policy
[...]
   If the reason for the failure to deliver is lack of an entry in the
   forwarding node's routing table that can be used to reach the
   destination, the Code field is set to 0.  This error may be reported
   by nodes that lack a default route or are the origin of an aggregate
   route
[...]
   If the reason for the failure to deliver is that the packet with this
   destination address is not allowed due to ingress or egress filtering
   policies, the Code field is set to 6.

   Codes 5 and 6 are more informative subsets of code 1.

Notes:

A router that is the explicit or implicit origin of an aggregate
route prefix in routing must not forward messages to destinations
matching the aggregate prefix using a route with a prefix less specific
than the aggregate route it originated (e.g. a defaut route). This
constraint is necessary to produce correct, loop-free routing. The
parenthetical comment in the current description of the Code 0 error
overlooks the fact that such nodes may lack a route which may be used to
reach a destination matching an aggregate prefix, and may be the only
nodes which could report this lack, even if they do have routes to less
specific matching prefixes. The suggested change to the Code 0
description attempts to correct this.

Concerning Code 6, the earliest definition of a "reject route" I've
found in writing is in the RFC 2096 IP Forwarding Table MIB (though
4.3BSD-Reno kernels supported them in 1990 and there may well be earlier
uses). The updated description of inetCidrRouteType in RFC 4292 says this:

reject(2) refers to a route that, if matched, discards
the message as unreachable and returns a notification
(e.g., ICMP error) to the message sender. This is used
in some protocols as a means of correctly aggregating
routes.

In the MIB a reject route is a generic mechanism to indicate that packets
with matching destinations won't be forwarded using less specific routes,
but instead will be discarded if no more specific matching route to use
to forward the packet is known with an error being returned to the
message sender. The reason no specific error is associated with this is
that while the presence of the reject route describes how messages are
forwarded, or not forwarded (i.e. the mechanism), it does not describe why
they are being forwarded like that (i.e. the policy); to know the latter
requires knowing why the reject route was added. Knowing which error
will be reported hence requires knowing the purpose that is being
implemented by the reject route.

The original use of the mechanism, as indicated above, was to produce
correct forwarding on routers originating aggregate routes. Another use
of the mechanism, to prevent packets with Local IPv6 destination addresses
from being forwarded beyond a site's administrative boundary, was suggested
in Section 4.3 of RFC 4193 (I believe this can only be understood as a
suggestion, rather than an implementation requirement, since the policy
it requires could be indistinguishably implemented with a firewall filter
instead).

The current definition of Code 6 describes the error being reported
as "Reject route to destination", that is it ascribes the reason for
the error to the mechanism itself rather than the policy the mechanism
was employed to implement. If this was the intent then its discription
is technically inaccurate. A reject route does not necessarily implement
an administrative prohibition nor is its function necessarily to "reject
all traffic for a specific prefix"; the original use of reject routes
for aggregation is inconsistent with both of these. What I believe is
that the intent of Code 6 is to report the error associated with the
RFC 4193 border patrol policy, independent of how that is implemented, and
so I've changed the text to better reflect that.
--VERIFIER NOTES--
The changes proposed go beyond the level of fixing an error. Some of the changes are explicitly changing the consensus of the working group that developed the specification. If these changes are warranted, an internet-draft should be written and discussion started within the working group.

RFC 4444, "Management Information Base for Intermediate System to Intermediate System (IS-IS)", April 2006

Source of RFC: isis (rtg)

Errata ID: 87
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-05-29
Rejected by: Adrian Farrel
Date Rejected: 2012-08-16

 

(2)  issue: non-use of appropriate TC (?)

The isisCircLevelIDOctet OBJECT-TYPE macro instance, on page 36,
contains the SYNTAX clause:

    isisCircLevelIDOctet OBJECT-TYPE
        SYNTAX Unsigned32(0..255)

After comparison with similar context in the RFC, I suspect that it
would be appropriate to use the IsisUnsigned8TC TEXTUAL-CONVENTION
in this place as well:

    isisCircLevelIDOctet OBJECT-TYPE
|       SYNTAX IsisUnsigned8TC


(3)  issue: unexpected indexing

As described in the SMIv2 RFCs, RFC 4444 extends various tables
by "reusing" of common index objects.  Surprisingly, there are
two deviations from this practice I cannot detect any reason for:

(3.1)
The isisSystemCounterTable (page 39 ff.) is indexed by the fresh,
independant index object, "isisSysStatLevel", while IMHO it would
have been logical to use the already defined index object of the
isisSysLevelTable (page 25 ff.), "isisSysLevelIndex", for this
purpose as well.

(3.2)
The isisPacketCounterTable (page 46 ff.) is indexed in the 2nd place
by the fresh, independant index object, "isisPacketCountLevel",
while IMHO it would have been logical to use the full index structure
of the isisCircLevelTable (page 34 ff.), including the index object,
"isisCircLevelIndex" in the second place, for this purpose as well.


(4)  issue: many unusual UNITS clauses

The UNITS clause is intended a to contains a textual definition of
the units associated with the object (according to RFC 2578, Section
7.2).  Network management systems usually provide for narrow label
space in their display screens - expecting usual [physical] unit
names like "bytes", "kilobytes", "seconds", "centiseconds", "Mbps",
"packets", "frames", "cells", "percent", etc.

For most packet counters, RFC 4444 specifies very unusual, lengthy
texts in the UNITS clauses that duplicate the text given in the
respective DESCRIPTION clauses.
This style should better have been avoided and might be noted as
an issue for any potential future update to RFC 4444.

For example, the isisPacketCountCSNP OBJECT-TYPE declaration, on
page 49 :

    isisPacketCountCSNP OBJECT-TYPE
        SYNTAX Counter32
|       UNITS "Number of IS-IS CSNP frames seen in this direction at
|            this level"
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
            "The number of IS-IS CSNPs seen in this
             direction at this level."
        REFERENCE "{ISIS.aoi iSISControlPDUsSent (43)}"
    ::= { isisPacketCounterEntry 7 }

should perhaps better say:

    isisPacketCountCSNP OBJECT-TYPE
        SYNTAX Counter32
|       UNITS "frames"
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
            "The number of IS-IS CSNPs seen in this
             direction at this level."
        REFERENCE "{ISIS.aoi iSISControlPDUsSent (43)}"
    ::= { isisPacketCounterEntry 7 }


(5)  errata(?): overly restrictive RowStatus object descriptions

Some tables with conceptual rows that can be dynamically added
or deleted, contain a control object with SYNTAX RowStatus
and other control objects, e.g. with SYNTAX IsisAdminState.

I expect that the latter objects have been intended to control
the activity of "live" table rows, without the need to deactivate
these rows via the RowStatus object before setting the AdminState
to "on" or "off", so much the more the support for the
'notInServcie' state of the RowStatus objects is explicitely
"not required".  Therefore, I strongly suspect that some RowStatus
object DESCRIPTION clauses have unintentionally been worded overly
restrictive and should been corrected to allow AdminStatus changes.

Some other such clauses contain statements that are void due to the
lack of accessible objects in those tables they could be applied to.

I have identified the following instances of these issues:

(5.3)

The DESCRIPTION clause of the isisCircExistState OBJECT-TYPE macro
instance, on page 31, says:

        DESCRIPTION
            "The existence state of this circuit.  Setting the state
             to 'notInService' halts the generation and processing of
             IS-IS protocol PDUs on this circuit.  Setting the state
             to destroy will also erase any configuration associated
             with the circuit.  Support for 'createAndWait' and
             'notInService' is not required.

|            A row entry cannot be modified when the value of this
|            object is 'active'."

It should perhaps instead say:

        DESCRIPTION
            "The existence state of this circuit.  Setting the state
             to 'notInService' halts the generation and processing of
             IS-IS protocol PDUs on this circuit.  Setting the state
             to destroy will also erase any configuration associated
             with the circuit.  Support for 'createAndWait' and
             'notInService' is not required.

|            Any other accessible object in this table row, except
|            isisCircAdminState, cannot be modified when the value
|            of this object is 'active'."

(5.4)

The DESCRIPTION clause of the isisRAExistState OBJECT-TYPE macro
instance, on page 58, says:

        DESCRIPTION
            "The existence state of this Reachable Address.  This
             object follows the ManualOrAutomatic behaviors.  Support
             for 'createAndWait' and 'notInService' is not required.

|            A row entry cannot be modified when the value of this
|            object is 'active'."

It should perhaps instead say:

        DESCRIPTION
            "The existence state of this Reachable Address.  This
             object follows the ManualOrAutomatic behaviors.  Support
             for 'createAndWait' and 'notInService' is not required.

|            Any other accessible object in this table row, except
|            isisRAAdminState, cannot be modified when the value
|            of this object is 'active'."

(5.5)

The DESCRIPTION clause of the isisIPRAExistState OBJECT-TYPE macro
instance, on page 65, says:

        DESCRIPTION
            "The state of this IP Reachable Address.  This object
             follows the ExistenceState and ManualOrAutomatic
             behaviors.  Support for 'createAndWait' and
             'notInService' is not required.

|            A row entry cannot be modified when the value of this
|            object is 'active'."

It should perhaps instead say:

        DESCRIPTION
            "The state of this IP Reachable Address.  This object
             follows the ExistenceState and ManualOrAutomatic
             behaviors.  Support for 'createAndWait' and
             'notInService' is not required.

|            Any other accessible object in this table row, except
|            isisIPRAAdminState, cannot be modified when the value
|            of this object is 'active'."


(8)  issue: on-the-wire inefficiency in notifications

While admittedly the indexing structure of the MIB tables,
and the resulting lack of suitable accessible objects, apparently has
forced the introduction of the unusual and unusually large collection
of special objects with 'MAX-ACCESS accessible-for-notify'
(on pp. 71..74), some redundancies and inefficiencies in the
object groupings for notifications remain.  Repeatedly, the
number of objects could have been reduced by including properly
indexed objects into the notifications object groups instead of
separate "special" objects.  But this might have been considered
acceptable for the sake of a consistent object grouping style.

But there is one redundancy that could easily have been avoided.
The isisDatabaseOverload NOTIFICATION-TYPE declaration, on page 74,

    isisDatabaseOverload NOTIFICATION-TYPE
        OBJECTS {
            isisNotificationSysLevelIndex,
            isisSysLevelState
        }

includes the object, "isisSysLevelState", that already carries
the required SysLevelIndex in the index part of its OID, because
it is contained in the isisSysLevelTable.
Therefore, without any loss of information for the receiver of the
notification, this declaration could have been simplified to specify:

    isisDatabaseOverload NOTIFICATION-TYPE
        OBJECTS {
            isisSysLevelState
        }

Notes:

This Errata Note has been split with some elements moved to EID 3321.

All excerpts from the RFC text are taken literally, keeping their
original formatting, and modified text is formatted in conformance
with RFC guidelines again.

I use change bars ('|' in column 1) and casual up/down pointing
tags ('^^^' / 'vvv' marks in extra lines) to emphasize the location
of textual issues and/or proposed textual enhancements/corrections.

Naturally, items (3) and (8) cannot be addressed any more
"after the fact" (i.e. publication of the RFC), and item (4)
should be addressed in a future update.

from pending
--VERIFIER NOTES--
(2) Rejected. Too late for this change. No functional effect.
(3) Rejected. This is discussion not errata.
(4) Rejected. Nothing wrong with original text.
(5.3) Rejected. Pointless wordsmithing.
(5.4) Rejected. Pointless wordsmithing.
(5.5) Rejected. Pointless wordsmithing.
(8) Rejected. This is discussion not errata.

RFC 4447, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", April 2006

Note: This RFC has been obsoleted by RFC 8077

Note: This RFC has been updated by RFC 6723, RFC 6870, RFC 7358

Source of RFC: pwe3 (int)

Errata ID: 3111
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Rejected by: Stewart Bryant
Date Rejected: 2012-02-07

Section 6.3 says:

a) The first paragraph of Section 6.3, on page 22, says:

   As mentioned above, the Group ID field of the PWid FEC element, or
   the PW Grouping ID TLV used with the Generalized ID FEC element, can
   be used to withdraw all PW labels associated with a particular PW
   group.  [...]

It should say:

   As mentioned above, the Group ID field of the PWid FEC element, or
|  the PW Grouping ID TLV used with the Generalized PWid FEC element,
   can be used to withdraw all PW labels associated with a particular PW
   group.  [...]

b) The second paragraph of Section 6.3, on top of page 23, says:

   If the Generalized FEC element is used, the AGI, SAII, and TAII are
   not present, the PW information length field is set to 0, the PW
   Grouping ID TLV is included, the Interface Parameters TLV is not
   present, and the Label TLV is not present.  For the purpose of this
   document, this is called the "wild card withdraw procedure", and all
   PEs implementing this design are REQUIRED to accept such withdrawn
   message but are not required to send it.  Note that the PW Grouping
   ID TLV only applies to PWs using the Generalized ID FEC element,
   while the Group ID only applies to PWid FEC element.

It should say:

|  If the Generalized PWid FEC element is used, the AGI, SAII, and TAII
   are not present, the PW information length field is set to 0, the PW
   Grouping ID TLV is included, the Interface Parameters TLV is not
   present, and the Label TLV is not present.  For the purpose of this
   document, this is called the "wild card withdraw procedure", and all
   PEs implementing this design are REQUIRED to accept such withdrawn
   message but are not required to send it.  Note that the PW Grouping
|  ID TLV only applies to PWs using the Generalized PWid FEC element,
   while the Group ID only applies to PWid FEC element.

Notes:

--VERIFIER NOTES--
The terminology in the RFC is correct.
It is the "generalized PW FEC Element" and not the "generalized PWid FEC element"

Errata ID: 3113
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Rejected by: Stewart Bryant
Date Rejected: 2012-02-07

Section 5.4.2 says:

   The PW FEC TLV SHOULD not include the interface parameter sub-TLVs,
   as they are ignored in the context of this message.  When a PE's
   attachment circuit encounters an error, use of the PW Notification
   Message allows the PE to send a single "wild card" status message,
   using a PW FEC TLV with only the group ID set, to denote this change
   in status for all affected PW connections.  This status message
   contains either the PW FEC TLV with only the group ID set, or else it
   contains the Generalized FEC TLV with only the PW Grouping ID TLV.

   As mentioned above, the Group ID field of the PWid FEC element, or
   the PW Grouping ID TLV used with the Generalized ID FEC element, can
   be used to send a status notification for all arbitrary sets of PWs.
   [...]

It should say:

|  The PWid FEC element SHOULD NOT include the interface parameter
   sub-TLVs, as they are ignored in the context of this message.  When
   a PE's attachment circuit encounters an error, use of the PW
   Notification Message allows the PE to send a single "wild card"
|  status message, using a PWid FEC element with only the group ID set,
   to denote this change in status for all affected PW connections.
|  This status message contains either a FEC TLV with a PWid FEC element
|  with only the group ID set, or else it contains a FEC TLV with a
|  Generalized PWid FEC element together with only the PW Grouping ID
   TLV.

   As mentioned above, the Group ID field of the PWid FEC element, or
|  the PW Grouping ID TLV used with the Generalized PWid FEC element,
   can be used to send a status notification for all arbitrary sets of
   PWs.
   [...]

Notes:

clarifications, terms and wording

--VERIFIER NOTES--
The terminology was correct at the time of writing.

RFC 4450, "Getting Rid of the Cruft: Report from an Experiment in Identifying and Reclassifying Obsolete Standards Documents", March 2006

Source of RFC: newtrk (gen)

Errata ID: 776
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-18
Rejected by: Eliot Lear

 

(1)

Near the top of page 3, section 3 of RFC 4450 states the
reasons for removal from the list -- i.e. *not* moving
to HISTORIC state:
  o  RFC 1584  -- an expected future dependency;
  o  RFC 1755  -- believed to be actively in use.

Nevertheless, these two RFCs have been moved to HISTORIC
status along with the publication of RFC 4450, as can be
seen in rfcxx00.txt .
This is quite surprising. (Perhaps, you know what happened.)

Preferrably, the final RFC text would better have been
coordinated with the actual Standards Actions performed --
for example, by addition of an IESG statement explaining the
deviation from the text.


(2)

Due to the 'numeric limitation' applied (restriction to RFCs
with numbers in the range ~700...2000) there are now a couple
of RFCs that have lost their 'normative background'.

For example, the higher level SNA MIBs (RFCs 2051, (2155->)2455,
2456, 2457, and 2582) more or less depend on the now deprecated
basic SNA node MIBs, RFCs (1665->)1666 and 1747.  [ "xx->yy"
is my shorthand notation for "RFC xx obsoleted by RFC yy". ]
Arguably, in this case, these dependant RFCs might be considered
candidates for a move to HISTORIC as well.
But there certainly are other cases as well (I have not yet
checked all the details).

It therefore should perhaps be considered to repeat the
RFC 4450 'experiment' with an extended numeric range of RFCs,
e.g. up to RFC 2500.


(3)

On the other hand, the restriction to Standards Track documents
has other undesired implications:

a) In the past, usually at least an Experimental RFC has been
published as a first try for a new protocol (or an Informational
RFC, in the case of a third-party protocol), before a Standards
Track version has been developed.  Unfortunately, in this process
it obviously has been avoided very often to formally OBSOLETE
the predecessor RFC[s] when the Standards Track version has been
published.  (Similar undue 'politeness' can be observed, e.g.,
on the transition path of MIBs from SMIv1 to SMIv2.)
Caused by RFC 4450 we now have non-deprecated RFCs predating
RFCs moved to HISTORIC state.
(The example instances I've been aware of at first glance, though
still being listed as EXPERIMENTAL in the RFC index, fortunately
already had been removed in the past from the 'Experimental RFCs'
Section of rfcxx00.txt .)
It would be very useful, for clarity, to move these RFCs to
HISTORIC status as well.

b) There are 'companion documents' to Standards Track RFCs that
have been published as Informational RFCs for various (legitimate)
reasons.  These RFCs are outdated with their respective related
specifications, and as such, for clarity, should better be moved
to HISTORIC status as well.

For example, IMHO the following Informational and Experimental RFCs,
being closely related to RFCs that now have been deprecated, should
be considered candidates for deprecation (being made HISTORIC) as
well, for clarity, consistency, and/or historical context:

o  RFC 1477 (IDPR Introduction);
o  RFC 1482 (NSFNET Policy-Based Routing Database) -- IDPR related;
o  RFC 1585 (MOSPF Analysis and Experience) -- depending on RFC 1584;
o  RFC 1593 (SNA APPN Node MIB) -- 1st ed., eff.->2155->4255;
o  RFC 1634 (IPX over WAN Media) -- successor to RFC 1551, the siblings
            of which (RFCs 1552 and 1553) have been made HISTORIC;
o  RFC 1791 (TCP+UDP over IPX);     \  both still in
o  RFC 1792 (TCP/IPX MIB);          /  rfcxx00.txt !
o  RFC 1834 (WHOIS++ Introduction);
o  RFC 1875 (UNINETT PCA Policy) -- based on PEM.

It might therefore perhaps be useful to perform a RFC 4450 like
'experiment' for Informational and Experimental RFCs as well.


(4)

The restriction in the RFC 4450 effort on Proposed Standards
detracts from the fact that there are [Full] Standard RFCs as
well which are clearly outdated, or of questionable quality and/or
precision.
My personal (incomplete) hot list of candidates comprises:
     STDs 15, 16, 17, 19, 35, 40, 42, 44, 49
(Other legacy Standards doubtlessly should be updated, e.g.
STDs 5, 7, 13.)

Note: In particular the situation with STDs 16+17 is annoying.
      Replacements are established, but vendors do not switch
      to SMIv2 and the newer MIBs (and do not offer SNMPv3,
      with its improved security features!) because these old
      specifications are still listed as Standard.

I also strongly suspect that there are a few Draft Standard RFCs
that might be considered outdated.

It therefore might be worth repeating the RFC 4450 'experiment'
for Draft and Full Standards as well.

It should say:

[see above]

Notes:

From Eliot Lear <lear@cisco.com>

Alfred,

Thanks for taking the time to read the document. I'd like to encourage
you to share your comments with the newtrk working group. You can find
information on how to subscribe by going to http://www.ietf.org and
clicking on "Working Groups".

As to your specific comments...

Alfred ? wrote:
> Hello,
> I'd like to send you a few comments on the recently
> published RFC 4450 (Cruft Removal) authored by you.
>
> First of all, thanks for your effort!
>
> After reading the RFC and looking into the changes
> performed to rfcxx00.txt, I noticed a few issues.
>
>
> (1)
>
> Near the top of page 3, section 3 of RFC 4450 states the
> reasons for removal from the list -- i.e. *not* moving
> to HISTORIC state:
> o RFC 1584 -- an expected future dependency;
> o RFC 1755 -- believed to be actively in use.
>
> Nevertheless, these two RFCs have been moved to HISTORIC
> status along with the publication of RFC 4450, as can be
> seen in rfcxx00.txt .
> This is quite surprising. (Perhaps, you know what happened.)
>
> Preferrably, the final RFC text would better have been
> coordinated with the actual Standards Actions performed --
> for example, by addition of an IESG statement explaining the
> deviation from the text.
>

There was intended to be no deviation from the text. The RFC Editor is
also the one who keeps track of how specifications are classified.
>
> (2)
>
> Due to the 'numeric limitation' applied (restriction to RFCs
> with numbers in the range ~700...2000) there are now a couple
> of RFCs that have lost their 'normative background'.
>
> For example, the higher level SNA MIBs (RFCs 2051, (2155->)2455,
> 2456, 2457, and 2582) more or less depend on the now deprecated
> basic SNA node MIBs, RFCs (1665->)1666 and 1747. [ "xx->yy"
> is my shorthand notation for "RFC xx obsoleted by RFC yy". ]
> Arguably, in this case, these dependant RFCs might be considered
> candidates for a move to HISTORIC as well.
> But there certainly are other cases as well (I have not yet
> checked all the details).
>
> It therefore should perhaps be considered to repeat the
> RFC 4450 'experiment' with an extended numeric range of RFCs,
> e.g. up to RFC 2500.
>

I believe the problem you refer to would occur no matter what point we
stop. Also, at this time the normative limitation is being reconsidered.

>
> (3)
>
> On the other hand, the restriction to Standards Track documents
> has other undesired implications:
>
> a) In the past, usually at least an Experimental RFC has been
> published as a first try for a new protocol (or an Informational
> RFC, in the case of a third-party protocol), before a Standards
> Track version has been developed. Unfortunately, in this process
> it obviously has been avoided very often to formally OBSOLETE
> the predecessor RFC[s] when the Standards Track version has been
> published. (Similar undue 'politeness' can be observed, e.g.,
> on the transition path of MIBs from SMIv1 to SMIv2.)
> Caused by RFC 4450 we now have non-deprecated RFCs predating
> RFCs moved to HISTORIC state.
> (The example instances I've been aware of at first glance, though
> still being listed as EXPERIMENTAL in the RFC index, fortunately
> already had been removed in the past from the 'Experimental RFCs'
> Section of rfcxx00.txt .)
> It would be very useful, for clarity, to move these RFCs to
> HISTORIC status as well.
>
> b) There are 'companion documents' to Standards Track RFCs that
> have been published as Informational RFCs for various (legitimate)
> reasons. These RFCs are outdated with their respective related
> specifications, and as such, for clarity, should better be moved
> to HISTORIC status as well.
>

I think it's a matter of how you want to use the marking of "HISTORIC".
I apply it only to specifications that are only on the standards track.
You are correct that these docs are related, and the ISD effort would
probably merge them, but it's not clear to me how that would affect status.
> For example, IMHO the following Informational and Experimental RFCs,
> being closely related to RFCs that now have been deprecated, should
> be considered candidates for deprecation (being made HISTORIC) as
> well, for clarity, consistency, and/or historical context:
>
> o RFC 1477 (IDPR Introduction);
> o RFC 1482 (NSFNET Policy-Based Routing Database) -- IDPR related;
> o RFC 1585 (MOSPF Analysis and Experience) -- depending on RFC 1584;
> o RFC 1593 (SNA APPN Node MIB) -- 1st ed., eff.->2155->4255;
> o RFC 1634 (IPX over WAN Media) -- successor to RFC 1551, the siblings
> of which (RFCs 1552 and 1553) have been made HISTORIC;
> o RFC 1791 (TCP+UDP over IPX); \ both still in
> o RFC 1792 (TCP/IPX MIB); / rfcxx00.txt !
> o RFC 1834 (WHOIS++ Introduction);
> o RFC 1875 (UNINETT PCA Policy) -- based on PEM.
>
> It might therefore perhaps be useful to perform a RFC 4450 like
> 'experiment' for Informational and Experimental RFCs as well.
>
>
> (4)
>
> The restriction in the RFC 4450 effort on Proposed Standards
> detracts from the fact that there are [Full] Standard RFCs as
> well which are clearly outdated, or of questionable quality and/or
> precision.
> My personal (incomplete) hot list of candidates comprises:
> STDs 15, 16, 17, 19, 35, 40, 42, 44, 49
> (Other legacy Standards doubtlessly should be updated, e.g.
> STDs 5, 7, 13.)
>
> Note: In particular the situation with STDs 16+17 is annoying.
> Replacements are established, but vendors do not switch
> to SMIv2 and the newer MIBs (and do not offer SNMPv3,
> with its improved security features!) because these old
> specifications are still listed as Standard.
>
> I also strongly suspect that there are a few Draft Standard RFCs
> that might be considered outdated.
>
> It therefore might be worth repeating the RFC 4450 'experiment'
> for Draft and Full Standards as well.
>

And you might want to run that experiment. We had to start somewhere.
There is clearly more cruft.

Thanks,

Eliot

from pending

RFC 4455, "Definition of Managed Objects for Small Computer System Interface (SCSI) Entities", April 2006

Source of RFC: ips (tsv)

Errata ID: 82
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Rejected by: Keith McCloghrie
Date Rejected: 2007-07-10

 

(1)  typo

Section 3.5 of RFC 4455, on page 11, says:

   The management of SCSI commands is beyond the scope of this MIB
|  module.  Future SCSI Command MIB module can link to this MIB module,
   through the use of Object Identifiers (OIDs) or INDEX values of
   appropriate tables.

It should say:
                                          v
   The management of SCSI commands is beyond the scope of this MIB
|  module.  Future SCSI Command MIB modules can link to this MIB module,
   through the use of Object Identifiers (OIDs) or INDEX values of
   appropriate tables.


(2)  typo

Section 4.1 of RFC 4455, on page 11, says:

   The scsiDeviceGroup group contains the objects general to each SCSI
   instance: instance, device, and port objects.  It contains also the
   objects referring to the transport(s) used by those SCSI instances.
|  This group is mandatory for all SCSI managed system.

It should say:

   The scsiDeviceGroup group contains the objects general to each SCSI
   instance: instance, device, and port objects.  It contains also the
   objects referring to the transport(s) used by those SCSI instances.
|  This group is mandatory for all SCSI managed systems.
                                                      ^

(3)  word omission

The second paragraph of Section 4.7, on page 12, says:

   Managed systems acting as a SCSI target device and port and running
|  at high speed supporting should implement this group.

It should say:

   Managed systems acting as a SCSI target device and port and running
|  at high speed supporting statistics should implement this group.
                           ^^^^^^^^^^^


(4)  word omission

The second paragraph of Section 4.11, on page 13, says:

   Managed systems acting as a SCSI initiator device and port and
   running at high speed supporting should implement this group.

It should say:

   Managed systems acting as a SCSI initiator device and port and
|  running at high speed supporting statistics should implement this
   group.
                                   ^^^^^^^^^^^

(5)  text truncation

The DESCRIPTION clause of the scsiTransportFCP OBJECT-IDENTITY,
on page 24, says:

        "This identity identifies a Fibre Channel Protocol for SCSI,
        Second Version."

This sentence omits the most significant word, "transport".
It should say:

        "This identity identifies a Fibre Channel Protocol for SCSI,
|       Second Version, transport."
                      ^^^^^^^^^^^
or:
                                 vvvvvvvvvvvvvvvvvvv
|       "This identity identifies transport via the Fibre Channel
        Protocol for SCSI, Second Version."


(6)  incomplete description, and incomplete functionality ??

The DESCRIPTION clause of the scsiPortBusyStatuses OBJECT-TYPE,
on page 30, says:

        [...]
        Discontinuities in the value of this counter can occur at re-
        initialization of the management system."

Admittedly, this is true, but more importantly, the counter can
wrap back from 2^32-1 to 0 !!!
That should be noted there, and it should be detectable by means
of some 'discontinuity time stamp' object in the MIB module.


(7)  as (6) above

The same issue as stated in item (6) above also holds for the
scsiIntrDevOutResets OBJECT-TYPE, on page 33.


(8)  as (6) above

The same issue as stated in item (6) above also holds for all
counters in the SCSI Initiator Port Table, i.e. the DESCRIPTIONs
of the scsiIntrPortOutCommands, scsiIntrPortWrittenMegaBytes,
scsiIntrPortReadMegaBytes, and scsiIntrPortHSOutCommands
OBJECT-TYPEs, on page 35.


(9)  typo

The ASN.1 comment on top of page 36,

   -- SCSI target device discovered or authorized to attach each of the
   -- SCSI initiator ports of each SCSI initiator device of each
   -- instance.

should say:
                        v
|  -- SCSI target devices discovered or authorized to attach each of the
   -- SCSI initiator ports of each SCSI initiator device of each
   -- instance.


(10)  typo (spurious word)

The DESCRIPTION clause of the scsiDscTgtIndex OBJECT-TYPE, on page 37,
says:

        "This object is an arbitrary integer used to uniquely identify
        a particular SCSI target device either discovered by, or
|       configured for use with, one or more ports scsiDscTgtName of
        a particular device within a particular SCSI instance."

The spurious word "scsiDscTgtName" should be deleted.
Thus, it should say:

        "This object is an arbitrary integer used to uniquely identify
        a particular SCSI target device either discovered by, or
|       configured for use with, one or more ports of a particular
        device within a particular SCSI instance."


(11)  typo (spurious word)

The DESCRIPTION clause of the scsiDscTgtDevOrPort OBJECT-TYPE,
on page 37, says:

        "This object indicates whether this entry describes a
|       configured SCSI target device name (and applies to all ports
        on the identified SCSI target device) or an individual SCSI
        target port."

The spurious word "name" should be deleted.
Thus, it should say:

        "This object indicates whether this entry describes a
|       configured SCSI target device (and applies to all ports
        on the identified SCSI target device) or an individual SCSI
        target port."


(12)  similar to (6), and semantic overloading

The DESCRIPTION clause of the scsiDscTgtInCommands OBJECT-TYPE,
on page 38, says:

         [...]
         Discontinuities in the value of this counter can occur at re-
         initialization of the management system, and at other times as
         indicated by the value of scsiDscTgtLastCreation."

The literally same wording is repeated on page 39 in the DESCRIPTION
clauses of the OBJECT-TYPEs
-  scsiDscTgtWrittenMegaBytes,
-  scsiDscTgtReadMegaBytes, and
-  scsiDscTgtHSInCommands.

See the explanations for item (6) above.

The DESCRIPTION clause of the scsiDscTgtLastCreation OBJECT-TYPE,
at the bottom of page 39, says:

        "This object represents the value of sysUpTime when this row
|       was created."

Counter wrap-around isn't table row creation.
Thus, isn't the above referral heavy semantic overloading of
"Last Creation" time ??


(13)  typo

The ASN.1 comment near the bottom of page 43,

|  --***** Table of SCSI Target Device Attached to local SCSI
   --***** Initiator Ports

should say:
                                      v
|  --***** Table of SCSI Target Devices Attached to local SCSI
   --***** Initiator Ports


(14)  as (6) above

The DESCRIPTION clauses, on page 49, of the OBJECT-TYPEs
-  scsiTgtPortInCommands,
-  scsiTgtPortWrittenMegaBytes,
-  scsiTgtPortReadMegaBytes, and
-  scsiTgtPortHSInCommands
contain the sentence,

        Discontinuities in the value of this counter can occur at re-
        initialization of the management system."

the explanations given for item (6) above apply here as well.


(15)  improper wording

The DESCRIPTION clause of the scsiTgtPortHSInCommands OBJECT-TYPE,
on page 49, says:

        "This object represents the number of commands received.  This
|       object provides support for systems that can quickly generate a
        large number of commands because they run at high speed.
        [...]

Because this object counts *incoming* commands, the word "generate"
is considered improper and should be replaced by "accept" (or similar):

        "This object represents the number of commands received.  This
|       object provides support for systems that can quickly accept a
        large number of commands because they run at high speed.
        [...]


(16)  like (12) above

The SCSI Authorized Initiator table suffers from the same problems
as the Target Device Discovered Table (Item (12) above):

The DESCRIPTION clauses (on pages 52/53) of the OBJECT-TYPEs
-  scsiAuthIntrAttachedTimes,
-  scsiAuthIntrOutCommands,
-  scsiAuthIntrReadMegaBytes,
-  scsiAuthIntrWrittenMegaBytes, and
-  scsiAuthIntrHSOutCommands
each contain the identical sentence:

        Discontinuities in the value of this counter can occur at re-
        initialization of the management system, and at other times as
        indicated by the value of scsiAuthIntrLastCreation."

and the DESCRIPTION clause of the scsiAuthIntrLastCreation OBJECT-TYPE,
on page 53, says:

        "This object indicates the value of sysUpTime when this row was
        last created."

Counter wrap-around isn't table row creation.
Thus, isn't the above referral heavy semantic overloading of
"Last Creation" time ??


(17)  again, like (12) above

The SCSI LU table suffers from the same problems as above:

The DESCRIPTION clauses (on pages 60..62) of the OBJECT-TYPEs
-  scsiLuInCommands,
-  scsiLuReadMegaBytes,
-  scsiLuWrittenMegaBytes,
-  scsiLuInResets,
-  scsiLuOutTaskSetFullStatus, and
-  scsiLuHSInCommands
each contain the identical sentence:

        Discontinuities in the value of this counter can occur at re-
        initialization of the management system, and at other times as
        indicated by the value of scsiLuLastCreation."

while the DESCRIPTION clause of the scsiLuLastCreation OBJECT-TYPE,
on page 62, says:

        "This object indicates the value of sysUpTime when this row was
        last created."

Again, counter wrap-around isn't table row creation.
Thus, isn't the above referral heavy semantic overloading of
"Last Creation" time ??


(18)  MIB structure inconsistency ???

On page 66, RFC 4455 says:

   --********************** Notifications ******************************
|  -- scsiNotifications OBJECT IDENTIFIER ::= { scsiMIB  2 }
                                                        ^^^

   scsiNotificationsPrefix OBJECT IDENTIFIER
                                ::= { scsiNotifications 0 }

This is very notable, since on page 23, the same RFC has
specified:

   --****************** Structure of the MIB **************************
|  scsiNotifications OBJECT IDENTIFIER ::= { scsiMIB 0 }
   [...]
                                                    ^^^

At least, giving different values for the same object name
(though one instance is in an ASN.1 comment) is irritating.

The trailing OID component '0' is required for SNMPv1 backwards
compatibility.  Since it is already contained in the effective
'scsiNotifications' OID (as specified on page 23), the additional
introduction of 'scsiNotificationsPrefix' seems to be very
redundant.  Its use could be easily substituted by the use of
'scsiNotifications' in the two NOTIFICATION-TYPE invocations
on page 66, which would have resulted in the OID assignments,

   scsiTgtDeviceStatusChanged NOTIFICATION-TYPE
      [...]
   ::= { scsiNotifications 1 }

and

   scsiLuStatusChanged NOTIFICATION-TYPE
      [...]
   ::= { scsiNotifications 2 }

as usual in IETF MIBs.

That is now too late to be corrected, but the misleading ASN.1 comment
on page 66 of the RFC, as noted above, should be corrected to say:

   --********************** Notifications ******************************
|  -- scsiNotifications OBJECT IDENTIFIER ::= { scsiMIB  0 }
                                                        ^^^

(19)  typo

The ASN.1 comment on page 67,

      -- Conditionally mandatory groups to be included with
      -- the mandatory groups when the implementation has
|     -- SCSI target device.

should say:

      -- Conditionally mandatory groups to be included with
      -- the mandatory groups when the implementation has
|     -- SCSI target devices.
                           ^

(20)  typo

The DESCRIPTION clause of the scsiInitiatorDeviceGroup OBJECT-GROUP
invocation, on page 71, says:

        "This group is relevant for s SCSI initiator device and port."

should say:
                                    v
|       "This group is relevant for a SCSI initiator device and port."

or even better:

|       "This group is relevant for SCSI initiator devices and ports."


(21)  duplicate / redundant text

Section 10, on page 76, contains the 5th paragraph:

   We assume an HBA as the SCSI initiator device and a disk as the SCSI
   target device.  We assume that the SCSI target device has one logical
   unit, addressed by Logical Unit Number set to 0 (LUN0), which is the
   default LUN.  Parallel SCSI has only port identifiers, no port names.
   The transport pointer for parallel SCSI is set to 0 since there is no
   reference transport (SPI) MIB module.

This text is a slightly modified restatement of what is said in the
directly preceeding paragraph.
Thus, this paragraph should be deleted.

Notes:

Notes from Keith:
I think the only one of your corrections which is needed to avoid the
possibility of causing confusion to a reader is the one regarding the
OID of scsiNotifications. If an RFC Errata Note is created because
of that one, and all the other typos that you have found are also
included in the same RFC Errata Note, then my fear is that the one
which could be important will get buried in the triviality of the
others. Thus, I suggest that an RFC Errata Note, if created, should
only mention the OID of scsiNotifications.

I don't believe there are any items which need to be considered by the
WG for a future update to the MIB module.

from pending

RFC 4456, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", April 2006

Note: This RFC has been updated by RFC 7606

Source of RFC: idr (rtg)

Errata ID: 3898
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Gunjan Bansal
Date Reported: 2014-02-23
Rejected by: Stewart Bryant
Date Rejected: 2014-03-02

Section 8 says:

ORIGINATOR_ID

   ORIGINATOR_ID is a new optional, non-transitive BGP attribute of Type
   code 9.  This attribute is 4 bytes long and it will be created by an
   RR in reflecting a route.  This attribute will carry the BGP
   Identifier of the originator of the route in the local AS.  A BGP
   speaker SHOULD NOT create an ORIGINATOR_ID attribute if one already
   exists.  A router that recognizes the ORIGINATOR_ID attribute SHOULD
   ignore a route received with its BGP Identifier as the ORIGINATOR_ID.


CLUSTER_LIST

   CLUSTER_LIST is a new, optional, non-transitive BGP attribute of Type
   code 10.  It is a sequence of CLUSTER_ID values representing the
   reflection path that the route has passed.

   When an RR reflects a route, it MUST prepend the local CLUSTER_ID to
   the CLUSTER_LIST.  If the CLUSTER_LIST is empty, it MUST create a new
   one.  Using this attribute an RR can identify if the routing
   information has looped back to the same cluster due to
   misconfiguration.  If the local CLUSTER_ID is found in the
   CLUSTER_LIST, the advertisement received SHOULD be ignored.

Notes:

Although the guideline exists for the "egress" reflected routes (RR should create ORIGINATOR_ID if none exists, prepend its own ClusterId in CLUSTER_LIST), there is no guideline on how the routes received from iBGP peers be treated if "only one" attribute (ORIGINATOR_ID or CLUSTER_LIST) is present.
Should such routes be dropped (Considering them as a malformed routes ?)
--VERIFIER NOTES--
This is a question that should be addressed to the IDR WG.

Any new guideline that results should be considered for publication in an RFC. Technical changes of the type requested are outside the scope of the Errata process.

RFC 4480, "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)", July 2006

Source of RFC: simple (rai)

Errata ID: 2959
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Raphael Bossek
Date Reported: 2011-09-07
Rejected by: Richard Barnes
Date Rejected: 2013-04-16

Section 3.2. says:

Activities such as <appointment>, <breakfast>, <dinner>, <holiday>,
<lunch>, <meal>, <meeting>, <performance>, <travel>, or <vacation>
can often be derived from calendar information.

----on the next page----

lunch:  The person is eating his or her midday meal.

It should say:

Activities such as <appointment>, <breakfast>, <dinner>, <holiday>,
<meal>, <meeting>, <performance>, <travel>, or <vacation>
can often be derived from calendar information.

----on the next page----

(delete this line)

Notes:

The <lunch> activity is not allowed because not defined by the XML Schema in section in section 5.1. Because the XML Schema is immutable the documentation should be corrected.

--VERIFIER NOTES--
This erratum had previously been held for document update, but has since been rejected in favor of Erratum 3121. Please see that erratum at <http://www.rfc-editor.org/errata_search.php?eid=3121>

RFC 4490, "Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS)", May 2006

Source of RFC: smime (sec)

Errata ID: 1884
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-17
Rejected by: Tim Polk
Date Rejected: 2010-07-20

Section 2.1, pg. 4 says:

   When the Message Digest authenticated attribute is present, the
|  DigestedData digest contains a 32-byte digest in little-endian
   representation:

It should say:

   When the Message Digest authenticated attribute is present, the
|  DigestedData digest contains a 32-byte digest in big-endian
   representation:

Notes:

Rationale:
- Contradiction to other parts of the document,
which use "big-endian" == 'network byte order'
as established in the Internet architecture.
- Please also note that the ASN.1 BER/DER encoding is
based on the 'natural' byte order for left-to-right
scripts -- otherwise the intrinsically variable-length
representation used would be very complicated to deal
with in processing.
- Intrduction of varying endian-ness is a likely source
of implementation issues and, consequentially,
interoperability problems.
--VERIFIER NOTES--
authors confirmed that the DigestedData digest is encoded in little-endian representation in all
known implementations.

RFC 4491, "Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile", May 2006

Source of RFC: pkix (sec)

Errata ID: 1885
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-17
Rejected by: Tim Polk
Date Rejected: 2010-07-20

Section 2.3.1, 2.3.2 says:

a)  Section 2.3.1, page 7

|  GostR3410-94-PublicKey MUST contain 128 octets of the little-endian
   representation of the public key Y = a^x (mod p), where a and p are
   public key parameters, and x is a private key.

b) Section 2.3.2, page 9

   GostR3410-2001-PublicKey MUST contain 64 octets, where the first 32
|  octets contain the little-endian representation of x and the second
|  32 octets contain the little-endian representation of y.  [...]

It should say:

a)

|  GostR3410-94-PublicKey MUST contain 128 octets of the big-endian
   representation of the public key Y = a^x (mod p), where a and p are
   public key parameters, and x is a private key.

b)

   GostR3410-2001-PublicKey MUST contain 64 octets, where the first 32
|  octets contain the big-endian representation of x and the second
|  32 octets contain the big-endian representation of y.  [...]

Notes:

Rationale:
Inconsistency within the RFC.
Most parts of the memo make use of the Internet-standard
"network byte order". a.k.a. "big-endian byte order", which
also is at the heart of the ASN.1 BER/DER encoding.
Use of mixed endian-ness within a single context, or even
a single specification, is a likely source of implementation
errors and, consequently, interoperability problems.

Cf. the related Errata Note for RFC 4490, EID=1884.
--VERIFIER NOTES--
authors confirmed that little-endian encoding is correct.

RFC 4511, "Lightweight Directory Access Protocol (LDAP): The Protocol", June 2006

Source of RFC: ldapbis (app)

Errata ID: 75
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-06-23
Rejected by: Jim Sermersheim
Date Rejected: 2006-07-03

 

(2)  Typo

Section 2, on page 4, contains the paragraph:
                                        v
|  The term "SASL layer" refers to Simply Authentication and Security
   Layer (SASL) services used in providing security services, as well as
   associations established by these services.

It should say:
                                        v
|  The term "SASL layer" refers to Simple Authentication and Security
   Layer (SASL) services used in providing security services, as well as
   associations established by these services.


(3)  Misrepresented relationship between ISO 10646 and Unicode

Section 4.1.2 unfortunately has not corrected a misconception
initially spelled out in RFC 2251.

The first paragraph of Section 4.1.2, on page 7, says:

   The LDAPString is a notational convenience to indicate that, although
   strings of LDAPString type encode as ASN.1 OCTET STRING types, the
|  [ISO10646] character set (a superset of [Unicode]) is used, encoded
   following the UTF-8 [RFC3629] algorithm.  [...]

The (..) enclosed note on the relationship of ISO 10646 and Unicode
is *not* appropriate, as far as I know:

Unicode covers exactly the same character repertoire as ISO 10646,
but it *adds* a lot of *semantics* to ISO 10646.
The character repertoire synchronization between ISO 10646 and
Unicode is said to hold since 1993, and it is promised for all
future updates.
(Details can be found in Section 1.4 and Appendix C of
The Unicode Standard (book and online version), verbatim
identical in the Unicode 3.0 and Unicode 4.0 versions.)

In particular, this congruence holds for Unicode 3.2.0
(and the coordinated edition of ISO 10646) that has been
made the invariable base for the new LDAP specs.

Therefore, the above sentence should perhaps better be
corrected to say:

   The LDAPString is a notational convenience to indicate that, although
   strings of LDAPString type encode as ASN.1 OCTET STRING types, the
|  [ISO10646] character set (as detailed in [Unicode]) is used, encoded
   following the UTF-8 [RFC3629] algorithm.  [...]

(or similar).


(4)  Typo (word omission)

The 3rd paragraph of Section 4.2.2, on page 18, says:

   If the client receives a BindResponse where the resultCode is set to
   protocolError, it is to assume that the server does not support this
|  version of LDAP.  While the client may be able proceed with another
   version of this protocol (which may or may not require closing and
   re-establishing the transport connection), how to proceed with
   another version of this protocol is beyond the scope of this
   document.  Clients that are unable or unwilling to proceed SHOULD
   terminate the LDAP session.

It should say:
                                                 vvvv
|            [...].  While the client may be able to proceed with
   another version of this protocol (which may or may not require
   closing and re-establishing the transport connection), how to proceed
   with another version of this protocol is beyond the scope of this
   document.  [...]


Items (2)..(4) above might be considered for an Errata Note
to be posted to the RFC Editor's "RFC Errata" web pages.
I propose that you submit an Author's Errata Note, based on the
material presented above, and/or choosing alternate text for (3).

Notes:

In any case, these items should be noted for future reference,
whenever once another revision of these RFCs is to be produced,
e.g., for advancement on the Standards Track.

[note: (1) contained general comments and has been removed.]

Author saving on file for possible revision.

from pending

RFC 4519, "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", June 2006

Source of RFC: ldapbis (app)

Errata ID: 1761
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Fotis Georgatos
Date Reported: 2009-04-10
Rejected by: Alexey Melnikov
Date Rejected: 2010-09-02

Section 3.10 says:

3.10.  'organizationalRole'

   The 'organizationalRole' object class is the basis of an entry that
   represents a job, function, or position in an organization.
   (Source: X.521 [X.521])

      ( 2.5.6.8 NAME 'organizationalRole'
         SUP top
         STRUCTURAL
         MUST cn
         MAY ( x121Address $ registeredAddress $ destinationIndicator $
               preferredDeliveryMethod $ telexNumber $
               teletexTerminalIdentifier $ telephoneNumber $
               internationalISDNNumber $ facsimileTelephoneNumber $
               seeAlso $ roleOccupant $ preferredDeliveryMethod $
               street $ postOfficeBox $ postalCode $ postalAddress $
               physicalDeliveryOfficeName $ ou $ st $ l $
               description ) )

It should say:

3.10.  'organizationalRole'

   The 'organizationalRole' object class is the basis of an entry that
   represents a job, function, or position in an organization.
   (Source: X.521 [X.521])

      ( 2.5.6.8 NAME 'organizationalRole'
         SUP top
         STRUCTURAL
         MUST cn
         MAY ( x121Address $ registeredAddress $ destinationIndicator $
               preferredDeliveryMethod $ telexNumber $
               teletexTerminalIdentifier $ telephoneNumber $
               internationalISDNNumber $ facsimileTelephoneNumber $
               seeAlso $ roleOccupant $ 
               street $ postOfficeBox $ postalCode $ postalAddress $
               physicalDeliveryOfficeName $ ou $ st $ l $
               description ) )

Notes:

Any object classes that include the preferredDeliveryMethod twice should be either redefined, by including it only once, OR provide an explicit reference about how it should be interpreted by the implementations; such examples are:
organizationalRole (3.10)
residentialPerson (3.13)

Note that this error has been affecting OpenLDAP implementations at least
since year 2002; with the side-effect that imported ldif data would disappear:
http://www.openldap.org/lists/ietf-ldapbis/200207/msg00002.html
It is surprising that it has remained unaddressed during so many years.

Also, Kurt Zeilinga has proposed to adopt the following (sufficient) rule:
"that implementations SHOULD be (and are) ignoring the redundant listing".
--VERIFIER NOTES--
Kurt Zeilenga said:

This issue was raised to the LDAPbis WG at the time it was working on the I-D which became RFC 4519 yet RFC 4519 did not include the suggested change. Simply put, there was insufficient support of the suggested change at that time.

The change is also bad in that in removes one of the examples of multiple listed attributes, a rarely used but still valid (for historical reasons) of X.500/LDAP schema descriptions, and hence may lead to implementations not supporting this feature and by doing so causing interop problems.

RFC 4526, "Lightweight Directory Access Protocol (LDAP) Absolute True and False Filters", June 2006

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 67
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-06
Rejected by: Peter Saint-Andre
Date Rejected: 2010-09-15

Section 4 says:

   Subject: Request for LDAP Protocol Mechanism Registration Object
   Identifier: 1.3.6.1.4.1.4203.1.5.3 Description: True/False filters
   Person & email address to contact for further information:
        Kurt Zeilenga <kurt@openldap.org> Usage: Feature Specification:
   RFC 4526 Author/Change Controller: IESG Comments: none

It should say:

   Subject: Request for LDAP Protocol Mechanism Registration
   Object Identifier: 1.3.6.1.4.1.4203.1.5.3
   Description: True/False filters
   Person & email address to contact for further information:
        Kurt Zeilenga <kurt@openldap.org>
   Usage: Feature
   Specification: RFC 4526
   Author/Change Controller: IESG
   Comments: none

Notes:

--VERIFIER NOTES--
Although the RFC text has unfortunate line breaks, the registration with the IANA is accurate at http://www.iana.org/assignments/ldap-parameters

RFC 4541, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", May 2006

Source of RFC: magma (int)

Errata ID: 4032
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Josef Felber
Date Reported: 2014-06-30
Rejected by: Brian Haberman
Date Rejected: 2014-07-01

Section 2.1.2 says:

1) Packets with a destination IP address outside 224.0.0.X which are
      not IGMP should be forwarded according to group-based port
      membership tables and must also be forwarded on router ports.

It should say:

1) Packets with a destination IP address outside 224.0.0.X which are
      not IGMP should be forwarded according to group-based port
      membership tables. 

Notes:

IMHO it makes no sense to forward non-IGMP datagrams to router ports if these are not members of the refering groups.

Consider the following example:
A IGMP snooping switch is connected to two mcast servers and some hosts. Server A is the querier, server B is the non-querier.

Now with the prevailing version of RFC4541 any mcast data stream (outside 224.0.0.x, non IGMP) would be routed to the hosts which are members of the refering group (correct), but also to server A, because the switch recognizes this port as a mcast server port due to the querier function. But server A is not interested in the data streams of server B unless it joins the group. This behaviour uneccessarily loads the port of server A with bandwidth.

Obviously some (all?) switch models (like HP2920) show this erroneous behavior.

Kind Regards, Josef Felber
--VERIFIER NOTES--
The text in the RFC is correct. Router ports need to see the multicast traffic in order to correctly forward it to interested members not connected to the switch.

RFC 4544, "Definitions of Managed Objects for Internet Small Computer System Interface (iSCSI)", May 2006

Note: This RFC has been obsoleted by RFC 7147

Source of RFC: ips (tsv)

Errata ID: 61
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-04
Rejected by: Lars Eggert
Date Rejected: 2008-12-19

 

(9)  common problem with indiscontinuity tagging

The Session Stats Table defines and admits High-Capacity (64-bit)
and Low-Capacity (32-bit) octet counters.
If both types of counters are implemented, according to the
DESCRIPTION clauses of all these counters,

        [...]
        If this counter has suffered a discontinuity, the time of the
        last discontinuity is indicated in iscsiSsnDiscontinuityTime."

Hence, iscsiSsnDiscontinuityTime must indicate discontinuities
in the HC and the LC counters, i.e. it must be changed whenever
one of the LC counters wraps back to zero, making it almost
useless for efficient surveillance of discontinuities in all
the other counters covered by this object.
Perhaps, as it has been done in a few other IETF MIBs in the past,
inclusion of additional 32-bit counters yielding the high part
(most significant 32 bits) of the HC counters for use with SNMPv1
management stations would have allowed to change the semantics of
iscsiSsnDiscontinuityTime to avoid too frequent changes.

Notes:

--VERIFIER NOTES--
Item (9) - the situation in which "one of the LC counters wraps back to
zero" is a regular increment of a continuous counter, i.e., it
is not a discontinuity. Thus, this item is unfounded.

Errata ID: 1630
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-04
Rejected by: Lars Eggert
Date Rejected: 2008-12-19

 

(1)  outdated text

Within Section 6, the first paragraph on top of page 5 says:

   It is worthwhile to note that this is an iSCSI MIB module and as such
   reflects only iSCSI objects.  This module does not contain
   information about the SCSI-layer attributes of a device.  If a SCSI
|  layer is present, the SCSI MIB module, currently under development,
   may be used to manage SCSI information for a device.

The last apparently sentence is outdated.  There already is an
appropriate Informative Reference given on page 81 of the RFC.
The RFC should say:

   It is worthwhile to note that this is an iSCSI MIB module and as such
   reflects only iSCSI objects.  This module does not contain
   information about the SCSI-layer attributes of a device.  If a SCSI
|  layer is present, the SCSI MIB module [RFC4455] may be used to manage
   SCSI information for a device.
                                        ^^^^^^^^^^^


(2)  lack of distinguishing DESCRIPTION text

The iscsiDescriptors OBJECT-IDENTITY declarations, on page 16/17
of the RFC, unfortunately contain pairwise identical DESCRIPTION
clauses, making Header and Data Integrity identifiers
indistinguishable.
This obviously needs short-term correction, e.g.:


The DESCRIPTION clause of the iscsiHdrIntegrityNone OBJECT-IDENTITY,

    DESCRIPTION
        "The authoritative identifier when no integrity
|       scheme (for either the header or data) is being
<<page break>>
        used."

should better say:

    DESCRIPTION
        "The authoritative identifier when no integrity
|       scheme for the header is being used."

The DESCRIPTION clause of the iscsiHdrIntegrityCrc32c OBJECT-IDENTITY,

    DESCRIPTION
        "The authoritative identifier when the integrity
|       scheme (for either the header or data) is CRC32c."

should better say:

    DESCRIPTION
        "The authoritative identifier when the integrity
|       scheme for the header is CRC32c."

The DESCRIPTION clause of the iscsiDataIntegrityNone OBJECT-IDENTITY,

    DESCRIPTION
        "The authoritative identifier when no integrity
|       scheme (for either the header or data) is being
        used."

should better say:

    DESCRIPTION
        "The authoritative identifier when no integrity
|       scheme for the data is being used."

The DESCRIPTION clause of the iscsiDataIntegrityCrc32c OBJECT-IDENTITY,

    DESCRIPTION
        "The authoritative identifier when the integrity
|       scheme (for either the header or data) is CRC32c."

should better say:

    DESCRIPTION
        "The authoritative identifier when the integrity
|       scheme for the data is CRC32c."


(3)  4 similar typos

The DESCRIPTION clause of the iscsiInstSsnFailures  OBJECT-TYPE,
on page 20 of RFC 4544, says:

    DESCRIPTION
        "This object counts the number of times a session belonging
|       to this instance has been failed.  If this counter has
        suffered a discontinuity, the time of the last discontinuity
        is indicated in iscsiInstDiscontinuityTime."

It should better say:

    DESCRIPTION
        "This object counts the number of times a session belonging
|       to this instance has failed.  If this counter has suffered a
        discontinuity, the time of the last discontinuity is indicated
        in iscsiInstDiscontinuityTime."

The DESCRIPTION clause of the iscsiInstSsnDigestErrors OBJECT-TYPE,
on page 22 of RFC 4544, says:

    DESCRIPTION
|       "The count of sessions that were failed due to receipt of
        a PDU containing header or data digest errors.  If this
        counter has suffered a discontinuity, the time of the last
        discontinuity is indicated in iscsiInstDiscontinuityTime."

It should better say:

    DESCRIPTION
|       "The count of sessions that failed due to receipt of
        a PDU containing header or data digest errors.  If this
        counter has suffered a discontinuity, the time of the last
        discontinuity is indicated in iscsiInstDiscontinuityTime."

The DESCRIPTION clause of the iscsiInstSsnCxnTimeoutErrors OBJECT-TYPE,
on page 22 of RFC 4544, says:

    DESCRIPTION
|       "The count of sessions that were failed due to a sequence
        exceeding a time limit.  If this counter has suffered a
        discontinuity, the time of the last discontinuity
        is indicated in iscsiInstDiscontinuityTime."

It should better say:

    DESCRIPTION
|       "The count of sessions that failed due to a sequence
        exceeding a time limit.  If this counter has suffered a
        discontinuity, the time of the last discontinuity
        is indicated in iscsiInstDiscontinuityTime."

The DESCRIPTION clause of the iscsiInstSsnFormatErrors OBJECT-TYPE,
on page 23 of RFC 4544, says:

    DESCRIPTION
|       "The count of sessions that were failed due to receipt of
        a PDU that contained a format error.  If this counter has
        suffered a discontinuity, the time of the last discontinuity
        is indicated in iscsiInstDiscontinuityTime."

It should better say:

    DESCRIPTION
|       "The count of sessions that failed due to receipt of
        a PDU that contained a format error.  If this counter has
        suffered a discontinuity, the time of the last discontinuity
        is indicated in iscsiInstDiscontinuityTime."


(4)  incomplete descriptions

Within the Target Attributes Table, the objects
    iscsiTgtLastFailureType,
    iscsiTgtLastIntrFailureName,
    iscsiTgtLastIntrFailureAddrType, and
    iscsiTgtLastIntrFailureAddr
apparently have no meaningful value if no error has occurred (yet).
The DESCRIPTION clauses for these objects, on page 38/39 of RFC 4544,
do not indicate the behaviour of these objects in this case, i.e.,
when the iscsiTgtLastFailureTime instance in a given conceptual
row has the value zero.
The respective DESCRIPTION clauses should indicate whether these
objects
  -   should not be instantiated
or
  -   have a certain default value (t.b.d.)
in this case.


A similar issue holds for the objects in the Initiator Attributes
Table,
    iscsiIntrLastFailureType,
    iscsiIntrLastTgtFailureName,
    iscsiIntrLastTgtFailureAddrType, and
    iscsiIntrLastTgtFailureAddr
(The corresponding DESCRIPTIONS can be found on page 46/47.)


(5)  row creation / storageType restriction

Various tables contain rows that can be created/deleted dynamically.
Repeatedly, for these tables the DESCRIPTION clauses for the
corresponding StorageType objects contain the sentence
(e.g., for iscsiTgtAuthStorageType, on page 44):

                                  [...].  Rows in this table that were
         created through an external process may have a storage type of
         readOnly or permanent.

It is not clear from the text what precisely 'external process'
means, and therefore it remains open whether/why the restriction
on values `readOnly` or `permanent` makes sense.


(6)  unpleasant alignment

Any future update to this RFC should correct the unpleasant
staggered tabular alignment of the following row-structure
( SEQUENCE { ... } ) declarations for:
  o  IscsiPortalAttributesEntry,
  o  IscsiInitiatorAttributesEntry, and
  o  IscsiInitiatorLoginStatsEntry


(7)  Semantic gap in Initiator Login Stats Table ??

The Initiator Login Stats Table somehow is a "dual" of the
Target Login Stats Table.
Therefore, I miss an object in the Initiator Login Stats Table
corresponding to iscsiTgtLoginAuthorizeFails, counting received
Login Response PDUs with status class 0x202.


(8)  typo?

The DESCRIPTION clause of the iscsiSsnAuthIdentity OBJECT-TYPE,
on page 58 of the RFC, says:

    DESCRIPTION
        "This object contains a pointer to a row in the
        IPS-AUTH MIB module that identifies the authentication
|       method being used on this session, as communicated
        during the login phase."

I strongly suspect that it should say instead:

    DESCRIPTION
        "This object contains a pointer to a row in the
        IPS-AUTH MIB module that identifies the authentication
|       identity being used on this session, as communicated
        during the login phase."


(9)  common problem with indiscontinuity tagging

The Session Stats Table defines and admits High-Capacity (64-bit)
and Low-Capacity (32-bit) octet counters.
If both types of counters are implemented, according to the
DESCRIPTION clauses of all these counters,

        [...]
        If this counter has suffered a discontinuity, the time of the
        last discontinuity is indicated in iscsiSsnDiscontinuityTime."

Hence, iscsiSsnDiscontinuityTime must indicate discontinuities
in the HC and the LC counters, i.e. it must be changed whenever
one of the LC counters wraps back to zero, making it almost
useless for efficient surveillance of discontinuities in all
the other counters covered by this object.
Perhaps, as it has been done in a few other IETF MIBs in the past,
inclusion of additional 32-bit counters yielding the high part
(most significant 32 bits) of the HC counters for use with SNMPv1
management stations would have allowed to change the semantics of
iscsiSsnDiscontinuityTime to avoid too frequent changes.

Notes:

from pending
--VERIFIER NOTES--
duplicate of Errata #61

Errata ID: 1631
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-04
Rejected by: Lars Eggert
Date Rejected: 2008-12-19

 

(1)  outdated text

Within Section 6, the first paragraph on top of page 5 says:

   It is worthwhile to note that this is an iSCSI MIB module and as such
   reflects only iSCSI objects.  This module does not contain
   information about the SCSI-layer attributes of a device.  If a SCSI
|  layer is present, the SCSI MIB module, currently under development,
   may be used to manage SCSI information for a device.

The last apparently sentence is outdated.  There already is an
appropriate Informative Reference given on page 81 of the RFC.
The RFC should say:

   It is worthwhile to note that this is an iSCSI MIB module and as such
   reflects only iSCSI objects.  This module does not contain
   information about the SCSI-layer attributes of a device.  If a SCSI
|  layer is present, the SCSI MIB module [RFC4455] may be used to manage
   SCSI information for a device.
                                        ^^^^^^^^^^^


(2)  lack of distinguishing DESCRIPTION text

The iscsiDescriptors OBJECT-IDENTITY declarations, on page 16/17
of the RFC, unfortunately contain pairwise identical DESCRIPTION
clauses, making Header and Data Integrity identifiers
indistinguishable.
This obviously needs short-term correction, e.g.:


The DESCRIPTION clause of the iscsiHdrIntegrityNone OBJECT-IDENTITY,

    DESCRIPTION
        "The authoritative identifier when no integrity
|       scheme (for either the header or data) is being
<<page break>>
        used."

should better say:

    DESCRIPTION
        "The authoritative identifier when no integrity
|       scheme for the header is being used."

The DESCRIPTION clause of the iscsiHdrIntegrityCrc32c OBJECT-IDENTITY,

    DESCRIPTION
        "The authoritative identifier when the integrity
|       scheme (for either the header or data) is CRC32c."

should better say:

    DESCRIPTION
        "The authoritative identifier when the integrity
|       scheme for the header is CRC32c."

The DESCRIPTION clause of the iscsiDataIntegrityNone OBJECT-IDENTITY,

    DESCRIPTION
        "The authoritative identifier when no integrity
|       scheme (for either the header or data) is being
        used."

should better say:

    DESCRIPTION
        "The authoritative identifier when no integrity
|       scheme for the data is being used."

The DESCRIPTION clause of the iscsiDataIntegrityCrc32c OBJECT-IDENTITY,

    DESCRIPTION
        "The authoritative identifier when the integrity
|       scheme (for either the header or data) is CRC32c."

should better say:

    DESCRIPTION
        "The authoritative identifier when the integrity
|       scheme for the data is CRC32c."


(3)  4 similar typos

The DESCRIPTION clause of the iscsiInstSsnFailures  OBJECT-TYPE,
on page 20 of RFC 4544, says:

    DESCRIPTION
        "This object counts the number of times a session belonging
|       to this instance has been failed.  If this counter has
        suffered a discontinuity, the time of the last discontinuity
        is indicated in iscsiInstDiscontinuityTime."

It should better say:

    DESCRIPTION
        "This object counts the number of times a session belonging
|       to this instance has failed.  If this counter has suffered a
        discontinuity, the time of the last discontinuity is indicated
        in iscsiInstDiscontinuityTime."

The DESCRIPTION clause of the iscsiInstSsnDigestErrors OBJECT-TYPE,
on page 22 of RFC 4544, says:

    DESCRIPTION
|       "The count of sessions that were failed due to receipt of
        a PDU containing header or data digest errors.  If this
        counter has suffered a discontinuity, the time of the last
        discontinuity is indicated in iscsiInstDiscontinuityTime."

It should better say:

    DESCRIPTION
|       "The count of sessions that failed due to receipt of
        a PDU containing header or data digest errors.  If this
        counter has suffered a discontinuity, the time of the last
        discontinuity is indicated in iscsiInstDiscontinuityTime."

The DESCRIPTION clause of the iscsiInstSsnCxnTimeoutErrors OBJECT-TYPE,
on page 22 of RFC 4544, says:

    DESCRIPTION
|       "The count of sessions that were failed due to a sequence
        exceeding a time limit.  If this counter has suffered a
        discontinuity, the time of the last discontinuity
        is indicated in iscsiInstDiscontinuityTime."

It should better say:

    DESCRIPTION
|       "The count of sessions that failed due to a sequence
        exceeding a time limit.  If this counter has suffered a
        discontinuity, the time of the last discontinuity
        is indicated in iscsiInstDiscontinuityTime."

The DESCRIPTION clause of the iscsiInstSsnFormatErrors OBJECT-TYPE,
on page 23 of RFC 4544, says:

    DESCRIPTION
|       "The count of sessions that were failed due to receipt of
        a PDU that contained a format error.  If this counter has
        suffered a discontinuity, the time of the last discontinuity
        is indicated in iscsiInstDiscontinuityTime."

It should better say:

    DESCRIPTION
|       "The count of sessions that failed due to receipt of
        a PDU that contained a format error.  If this counter has
        suffered a discontinuity, the time of the last discontinuity
        is indicated in iscsiInstDiscontinuityTime."


(4)  incomplete descriptions

Within the Target Attributes Table, the objects
    iscsiTgtLastFailureType,
    iscsiTgtLastIntrFailureName,
    iscsiTgtLastIntrFailureAddrType, and
    iscsiTgtLastIntrFailureAddr
apparently have no meaningful value if no error has occurred (yet).
The DESCRIPTION clauses for these objects, on page 38/39 of RFC 4544,
do not indicate the behaviour of these objects in this case, i.e.,
when the iscsiTgtLastFailureTime instance in a given conceptual
row has the value zero.
The respective DESCRIPTION clauses should indicate whether these
objects
  -   should not be instantiated
or
  -   have a certain default value (t.b.d.)
in this case.


A similar issue holds for the objects in the Initiator Attributes
Table,
    iscsiIntrLastFailureType,
    iscsiIntrLastTgtFailureName,
    iscsiIntrLastTgtFailureAddrType, and
    iscsiIntrLastTgtFailureAddr
(The corresponding DESCRIPTIONS can be found on page 46/47.)


(5)  row creation / storageType restriction

Various tables contain rows that can be created/deleted dynamically.
Repeatedly, for these tables the DESCRIPTION clauses for the
corresponding StorageType objects contain the sentence
(e.g., for iscsiTgtAuthStorageType, on page 44):

                                  [...].  Rows in this table that were
         created through an external process may have a storage type of
         readOnly or permanent.

It is not clear from the text what precisely 'external process'
means, and therefore it remains open whether/why the restriction
on values `readOnly` or `permanent` makes sense.


(6)  unpleasant alignment

Any future update to this RFC should correct the unpleasant
staggered tabular alignment of the following row-structure
( SEQUENCE { ... } ) declarations for:
  o  IscsiPortalAttributesEntry,
  o  IscsiInitiatorAttributesEntry, and
  o  IscsiInitiatorLoginStatsEntry


(7)  Semantic gap in Initiator Login Stats Table ??

The Initiator Login Stats Table somehow is a "dual" of the
Target Login Stats Table.
Therefore, I miss an object in the Initiator Login Stats Table
corresponding to iscsiTgtLoginAuthorizeFails, counting received
Login Response PDUs with status class 0x202.


(8)  typo?

The DESCRIPTION clause of the iscsiSsnAuthIdentity OBJECT-TYPE,
on page 58 of the RFC, says:

    DESCRIPTION
        "This object contains a pointer to a row in the
        IPS-AUTH MIB module that identifies the authentication
|       method being used on this session, as communicated
        during the login phase."

I strongly suspect that it should say instead:

    DESCRIPTION
        "This object contains a pointer to a row in the
        IPS-AUTH MIB module that identifies the authentication
|       identity being used on this session, as communicated
        during the login phase."


(9)  common problem with indiscontinuity tagging

The Session Stats Table defines and admits High-Capacity (64-bit)
and Low-Capacity (32-bit) octet counters.
If both types of counters are implemented, according to the
DESCRIPTION clauses of all these counters,

        [...]
        If this counter has suffered a discontinuity, the time of the
        last discontinuity is indicated in iscsiSsnDiscontinuityTime."

Hence, iscsiSsnDiscontinuityTime must indicate discontinuities
in the HC and the LC counters, i.e. it must be changed whenever
one of the LC counters wraps back to zero, making it almost
useless for efficient surveillance of discontinuities in all
the other counters covered by this object.
Perhaps, as it has been done in a few other IETF MIBs in the past,
inclusion of additional 32-bit counters yielding the high part
(most significant 32 bits) of the HC counters for use with SNMPv1
management stations would have allowed to change the semantics of
iscsiSsnDiscontinuityTime to avoid too frequent changes.

Notes:

from pending
--VERIFIER NOTES--
duplicate of Errata #61

RFC 4552, "Authentication/Confidentiality for OSPFv3", June 2006

Source of RFC: ospf (rtg)

Errata ID: 2599
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: John W. O'Brien
Date Reported: 2010-11-02
Rejected by: Stewart Bryant
Date Rejected: 2013-05-06

Section 3 says:

In order to provide authentication to OSPFv3, implementations MUST
support ESP and MAY support AH.

It should say:

In order to provide authentication to OSPFv3, implementations MUST
support AH and MAY support ESP.

Notes:

Authentication can be provided by an implementation that supports AH only.
--VERIFIER NOTES--
This was discussed on the OSPF list: http://www.ietf.org/mail-archive/web/ospf/current/msg05827.html and the conclusion was that the errata should be rejected.

RFC 4553, "Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)", June 2006

Source of RFC: pwe3 (int)

Errata ID: 1048
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-03-07
Rejected by: Stewart Bryant
Date Rejected: 2011-08-04

 

There are two distinct "PWE3 Pseudowire Type" namespaces maintained
by IANA:

  - the 'L2TPv3 Pseudowire Types' subregistry of the
    "l2tp-parameters" registry, rooted in RFC 3831, and

  - the 'MPLS Pseudowire Type' subregistry of the "pwe3-parameters"
    registry, rooted in RFC 4446.

From the text of RFC 4553, it might be concluded that it was intended
to make identical PW type allocations in both subregistries for SAToP,
as has been done before in a similar manner in PWE3 RFCs dealing with
"<any> over MPLS PWs" and "<any> over L2TPv3 PWs".

But the IANA Considerations (Section 11) of RFC 4553 simply state,

   Allocation of PW types for the corresponding SAToP PWs is defined in
   [RFC4446].

... and RFC 4446 has only registered the following assignments for SAToP
over MPLS:

   0x0011  Structure-agnostic E1 over Packet                [SAToP]
   0x0012  Structure-agnostic T1 (DS1) over Packet          [SAToP]
   0x0013  Structure-agnostic E3 over Packet                [SAToP]
   0x0014  Structure-agnostic T3 (DS3) over Packet          [SAToP]

Looking into the two IANA registries quoted above, it can be seen
that indeed only "pwe3-parameters" contains these assignments,
whereas they are not listed in "l2tp-parameters".

Apparently, this has been overseen by all parties involved!

If this conclusion applies, you should urgently:

(1) submit an Author's RFC Errata Note for RFC 4553 to the RFC-Ed
    with an amendment to Section 11, e.g.:

    IANA should perform the same assignemnts in the L2TPv3 Pseudowire
    Type subregistry.

(2) Request this action from IANA.

Notes:

--VERIFIER NOTES--
The IANA registry has been updated to correctly reflect the assignment of PW types 0x0011 to 0x0014 to RFC4553. Signalling of TDM PWS over L2TPv3 was not specified until RFC5611, thus L2TPv3 PW type assignments were out of scope of RFC4553.

These IANA assignments would not be re-requested in a future version of this document and an implementer would not be misled by the existing IANA text, thus
reject seems to be the most appropriate state for this erratum.

RFC 4566, "SDP: Session Description Protocol", July 2006

Note: This RFC has been obsoleted by RFC 8866

Source of RFC: mmusic (rai)

Errata ID: 57
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Rejected by: Colin Perkins
Date Rejected: 2006-11-22

 

(1)  typo

On page 7 of RFC 4566, Section 4.6 says:

   The SDP specification recommends the use of the ISO 10646 character
|  sets in the UTF-8 encoding [5] to allow many different languages to
   be represented.  However, to assist in compact representations, SDP
   also allows other character sets such as ISO 8859-1 to be used when
   desired.  Internationalisation only applies to free-text fields
   (session name and background information), and not to SDP as a whole.

It should say:

   The SDP specification recommends the use of the ISO 10646 character
|  set in the UTF-8 encoding [5] to allow many different languages to
   be represented.  However, to assist in compact representations, SDP
   also allows other character sets such as ISO 8859-1 to be used when
   desired.  Internationalisation only applies to free-text fields
   (session name and background information), and not to SDP as a whole.


(2)  inconsistent specification

Contrary to the text in Section 4.6 (see above), Section 5 of RFC 4566
specifies, at the bottom of page 7:

   An SDP session description is entirely textual using the ISO 10646
   character set in UTF-8 encoding.  SDP field names and attribute names
   use only the US-ASCII subset of UTF-8, but textual fields and
   attribute values MAY use the full ISO 10646 character set.  [...]

These conflicting specifications might become a source of
interoperability problems, and therefore, the conflict should be
resolved by a clarification !!!

Note: Subsequent text in sections 5.* specifies behaviour related
to the "a=charset" attribute required if other charsets than UTF-8
are used in certain fields; therefore, the latter exclusive UTF-8
rule is most probably too restrictive and hence inappropriate.


(3)  misleading text / inconsistency + typo (missing article)

Still in Section 5, the second-to-last paragraph on page 8 of RFC 4566
says:

   An SDP session description consists of a session-level section
   followed by zero or more media-level sections.  The session-level
   part starts with a "v=" line and continues to the first media-level
|  section.  Each media-level section starts with an "m=" line and
|  continues to the next media-level section or end of the whole session
   description.  In general, session-level values are the default for
   all media unless overridden by an equivalent media-level value.

The second sentence does not accomodate for an important corner case
mentioned in the first sentence, and thus should be amended with
similar wording as below. The third sentence is imprecise as well,
because the "or" does not uniquely select the 'right' condition.

It should better say:

   An SDP session description consists of a session-level section
   followed by zero or more media-level sections.  The session-level
   part starts with a "v=" line and continues to the first media-level
|  section (or the end of the whole description, whichever comes first).
   Each media-level section starts with an "m=" line and continues to
|  the next media-level section or the end of the whole session
|  description - whichever comes first.  In general, session-level
   values are the default for all media unless overridden by an
   equivalent media-level value.


(4)  significant mis-specification

In the "Session description" block, on top of page 9, the RFC says:

         c=* (connection information -- not required if included in
              all media)
         b=* (zero or more bandwidth information lines)

It should say:

         c=* (connection information -- not required if included in
              all media descriptions)
         b=* (zero or more bandwidth information lines)

Rationale:
Strictly differentiating between "media" and "media description"
is always required to avoid confusion! ...
And connection information is rarely (if ever) seen in the media!


(5)  improper wording related with IP addresses

IP addresses (in IPv4 and IPv6) are always assigned to an interface,
not to a host or 'machine'.  Therefore, a Standards Track RFC
should never talk about  '*the* IP address of a machine'.
FQDNs are also not necessarily unique for a 'machine', e.g. a server
having multiple, 'role-based' FQDNs.

Therefore, in Section 5.2, the last paragraph on page 11,

|  <unicast-address> is the address of the machine from which the
      session was created.  For an address type of IP4, this is either
|     the fully qualified domain name of the machine or the dotted-
|     decimal representation of the IP version 4 address of the machine.
|     For an address type of IP6, this is either the fully qualified
      domain name of the machine or the compressed textual
|     representation of the IP version 6 address of the machine.  For
      both IP4 and IP6, the fully qualified domain name is the form that
|     SHOULD be given unless this is unavailable, in which case the
      globally unique address MAY be substituted.  A local IP address
      MUST NOT be used in any context where the SDP description might
      leave the scope in which the address is meaningful (for example, a
      local address MUST NOT be included in an application-level
      referral that might leave the scope).

should say:

|  <unicast-address> is an address of the machine from which the
      session was created.  For an address type of IP4, this is either
|     a fully qualified domain name of the machine or the dotted-
|     decimal representation of an IP version 4 address of the machine.
|     For an address type of IP6, this is either a fully qualified
      domain name of the machine or the compressed textual
|     representation of an IP version 6 address of the machine.  For
      both IP4 and IP6, the fully qualified domain name is the form that
|     SHOULD be given unless this is unavailable, in which case a
      globally unique address MAY be substituted.  A local IP address
      MUST NOT be used in any context where the SDP description might
      leave the scope in which the address is meaningful (for example, a
      local address MUST NOT be included in an application-level
      referral that might leave the scope).


(6)  improper term used

a)
Section 5.6 twice uses the term, "conference", where IMHO, according
to the definitions given in Section 2, the term, "session" should
be used.  This change makes the text better conform with the
classification of the "e=" and "p=" lines on page 9, as well.

The first textual paragraph of Section 5.6, on page 13, says:

   The "e=" and "p=" lines specify contact information for the person
|  responsible for the conference.  This is not necessarily the same
|  person that created the conference announcement.

It should say:

   The "e=" and "p=" lines specify contact information for the person
|  responsible for the session.  This is not necessarily the same person
|  that created the session announcement.

b)
Another instance of this issue occurs in Section 5.7, at the bottom
of page 14.  There, the RFC says:

   o  Sessions using an IPv4 multicast connection address MUST also have
      a time to live (TTL) value present in addition to the multicast
      address.  The TTL and the address together define the scope with
|     which multicast packets sent in this conference will be sent.  TTL
      values MUST be in the range 0-255.  [...]

It should say:

   o  Sessions using an IPv4 multicast connection address MUST also have
      a time to live (TTL) value present in addition to the multicast
      address.  The TTL and the address together define the scope with
|     which multicast packets sent in this session will be sent.  TTL
      values MUST be in the range 0-255.  [...]

c)
Finally, the last sentence of the second paragraph of Section 5.13,
on page 21,

                                                   [...].  Attribute
   fields can also be added before the first media field; these
   "session-level" attributes convey additional information that applies
   to the conference as a whole rather than to individual media.

should say, accordingly:

                                                   [...].  Attribute
   fields can also be added before the first media field; these
   "session-level" attributes convey additional information that applies
|  to the session as a whole rather than to individual media.


(7)  clarification

The second paragraph of Section 5.9, on page 17, says:

   The first and second sub-fields give the start and stop times,
   respectively, for the session.  These values are the decimal
   representation of Network Time Protocol (NTP) time values in seconds
   since 1900 [13].  To convert these values to UNIX time, subtract
   decimal 2208988800.

To make the time base unique and absolute, the time zone (UTC) needs to
be specified.
Hence, the RFC should say:

   The first and second sub-fields give the start and stop times,
   respectively, for the session.  These values are the decimal
   representation of Network Time Protocol (NTP) time values in seconds
|  since 1900, UTC [13].  To convert these values to UNIX time, subtract
   decimal 2208988800.


(8)  typo (missing article)

The second text paragraph of section 5.10, on page 18, says:

   To make description more compact, times may also be given in units of
   days, hours, or minutes.  [...]

It should say:

|  To make the description more compact, times may also be given in
   units of days, hours, or minutes.  [...]


(9)  legacy term not replaced

Since the advent of SIP and the Offer/Answer Model for SDP, it is
no more appropriate, in a general context, to name a
'session description' just a 'session announcement'.

The final paragraph of Section 5.11, on page 19, says:

   If a session is likely to last several years, it is expected that the
   session announcement will be modified periodically rather than
   transmit several years' worth of adjustments in one session
   announcement.

It should say therefore:

   If a session is likely to last several years, it is expected that the
|  session description will be modified periodically rather than
|  transmitting several years' worth of adjustments in one session
|  description.


(10) clarification of 'charset' related terminology, plus typos

Section 5.13 makes use of legacy terminology related to character
sets and "charsets".  It should use the stable, IESG policy based
IETF terminology.

a)
Hence, the first paragraph on page 22:

   Attribute values are octet strings, and MAY use any octet value
   except 0x00 (Nul), 0x0A (LF), and 0x0D (CR).  By default, attribute
   values are to be interpreted as in ISO-10646 character set with UTF-8
   encoding.  Unlike other text fields, attribute values are NOT
   normally affected by the "charset" attribute as this would make
   comparisons against known values problematic.  However, when an
   attribute is defined, it can be defined to be charset dependent, in
   which case its value should be interpreted in the session charset
   rather than in ISO-10646.

should better say:

   Attribute values are octet strings, and MAY use any octet value
   except 0x00 (Nul), 0x0A (LF), and 0x0D (CR).  By default, attribute
|  values are to be interpreted as in the ISO-10646 character set with
   UTF-8 encoding.  Unlike other text fields, attribute values are NOT
   normally affected by the "charset" attribute as this would make
   comparisons against known values problematic.  However, when an
   attribute is defined, it can be defined to be charset dependent, in
   which case its value should be interpreted in the session charset
   rather than in UTF-8.

Note: RFC 1815 has been deprecated; 'ISO-10646' is *not* considered a
"charset", whereas 'UTF-8' is.

b)
In Section 6, at the bottom of page 28, the RFC says:

      a=charset:<character set>

         This specifies the character set to be used to display the
         session name and information data.  By default, the ISO-10646
         character set in UTF-8 encoding is used.  If a more compact
         representation is required, other character sets may be used.
         For example, the ISO 8859-1 is specified with the following SDP
         attribute:

            a=charset:ISO-8859-1

The above headline should say:

      a=charset:<charset>

or perhaps even better:

      a=charset:<IANA-charset>

and the text body above should be changed to say:

|        This specifies the character set and encoding ("charset") to be
|        used for the session name and information data.  By default,
|        the ISO-10646 character set in UTF-8 encoding (charset "UTF-8")
         is used.  If a more compact representation is required, other
|        charsets may be used.  For example, the ISO 8859-1 charset is
         specified with the following SDP attribute:
         [...]

Note: The session description does not determine how parts of it
are *displayed* (theres may be some transcoding used, and fonts
or typefaces, etc., the charset must only be specified for SDP.)

The subsequent text on page 29,

         This is a session-level attribute and is not dependent on
         charset.  The charset specified MUST be one of those registered
         with IANA, such as ISO-8859-1.  The character set identifier is
         a US-ASCII string and MUST be compared against the IANA
         identifiers using a case-insensitive comparison.  If the
         identifier is not recognised or not supported, all strings that
         are affected by it SHOULD be regarded as octet strings.

         Note that a character set specified MUST still prohibit the use
         of bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR).  Character sets
         requiring the use of these characters MUST define a quoting
         mechanism that prevents these bytes from appearing within text
         fields.

should be changed to say (fixing typos as well):

         This is a session-level attribute and is not dependent on
         charset.  The charset specified MUST be one of those registered
|        with IANA, such as ISO-8859-1.  The charset identifier is a
         US-ASCII string and MUST be compared against the IANA
         identifiers using a case-insensitive comparison.  If the
         identifier is not recognised or not supported, all strings that
         are affected by it SHOULD be regarded as octet strings.

|        Note that a charset specified MUST still prohibit the use of
|        bytes 0x00 (NUL), 0x0A (LF), and 0x0D (CR).  Charsets requiring
         the use of these characters MUST define a quoting mechanism
         that prevents these bytes from appearing within text fields.


(11)  language related issues, plus typos

The RFC text on pp. 29/30 does not properly distinguish between, and
messes up, the specifics of session content (and its language[s]) and
the session *description* content (and the language[s] used therein).

Note: I show more context than absolutely necessary to perform the
recommended changes, to make these better understandable.

a)
On mid-page 29, RFC 4566 says:

      a=sdplang:<language tag>

         This can be a session-level attribute or a media-level
         attribute.  As a session-level attribute, it specifies the
         language for the session description.  As a media-level
         attribute, it specifies the language for any media-level SDP
         information field associated with that media.  Multiple sdplang
         attributes can be provided either at session or media level if
|        multiple languages in the session description or media use
|        multiple languages, in which case the order of the attributes
|        indicates the order of importance of the various languages in
|        the session or media from most important to least important.

(The last half-sentence is wrong and inappropriate.)

It should better say:

      a=sdplang:<language tag>

         This can be a session-level attribute or a media-level
         attribute.  As a session-level attribute, it specifies the
         language for the session description.  As a media-level
         attribute, it specifies the language for any media-level SDP
         information field associated with that media.  Multiple sdplang
         attributes can be provided either at session or media level if
|        multiple languages in the session or media description use
|        multiple languages.

b)
Skipping one paragraph, the next one says:

         The "sdplang" attribute value must be a single RFC 3066
         language tag in US-ASCII [9].  It is not dependent on the
         charset attribute.  An "sdplang" attribute SHOULD be specified
|        when a session is of sufficient scope to cross geographic
         boundaries where the language of recipients cannot be assumed,
|        or where the session is in a different language from the
         locally assumed norm.

It should say:

         The "sdplang" attribute value must be a single RFC 3066
         language tag in US-ASCII [9].  It is not dependent on the
         charset attribute.  An "sdplang" attribute SHOULD be specified
|        when a session description is of sufficient scope to cross
         geographic boundaries where the language of recipients cannot
|        be assumed, or where the session description is in a different
         language from the locally assumed norm.

c)
Next, in the explanations for:

      a=lang:<language tag>

extending from page 29 to page 30,

         This can be a session-level attribute or a media-level
         attribute.  As a session-level attribute, it specifies the
         default language for the session being described.  As a media-
         level attribute, it specifies the language for that media,
  <<page break>>
         overriding any session-level language specified.  Multiple lang
         attributes can be provided either at session or media level if
|        the session description or media use multiple languages, in
         which case the order of the attributes indicates the order of
         importance of the various languages in the session or media
         from most important to least important.

should be corrected to say:

         This can be a session-level attribute or a media-level
         attribute.  As a session-level attribute, it specifies the
         default language for the session being described.  As a media-
         level attribute, it specifies the language for that media,
  <<page break>>
         overriding any session-level language specified.  Multiple lang
         attributes can be provided either at session or media level if
|        the session or media use multiple languages, in which case the
         order of the attributes indicates the order of importance of
|        the various languages in the session or media, from most
         important to least important.




Note: In the meantime (since the publication of RFC 4566), RFC 3066
has been superseded by RFC 4646 plus RFC 4647, now together denoted
as BCP 47.


(12)  typo

On page 31, in the second paragraph of Section 7, RFC 4566 says:

            [...].  Many different transport protocols may be used to
   distribute session description, and the nature of the authentication
   will differ from transport to transport.  [...]

It should say:

            [...].  Many different transport protocols may be used to
|  distribute session descriptions, and the nature of the authentication
   will differ from transport to transport.  [...]


(13)  SDP Grammar issues  (ABNF in Section 9, p. 39 ff.),

a)
The rule for 'repeat-interval'  (page 41)  could easily have
re-used (incorporated) the 'integer' rule:

   repeat-interval =     POS-DIGIT *DIGIT [fixed-len-time-unit]

is equivalent to:

   repeat-interval =     integer [fixed-len-time-unit]

b)
The rule for FQDN, at the bottom of page 42, is wrong;
FQDNs really should allow up to 255 characters!
                         v
|  FQDN =                4*(alpha-numeric / "-" / ".")
                         ; fully qualified domain name as specified
                         ; in RFC 1035 (and updates)

Because details are not gived (can be found at other places),
this rule should perhaps be only minimally corrected to say:

|  FQDN =                *(alpha-numeric / "-" / ".")
                         ; fully qualified domain name as specified
                         ; in RFC 1035 (and updates)


At a minimum, serious issues should be addressed,
e.g. (2), (10), (11), and the ABNF mistake (13b).

Notes:

from pending

--VERIFIER COMMENT--
While you raise a number of valid minor issues, I see nothing which
needs urgent attention or correction. I'll keep a record of these
issues, to be included if there is a revision to RFC 4566, but I see
no need to submit an errata note to the RFC Editor.

Errata ID: 3278
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Riccardo Bernardini
Date Reported: 2012-07-03
Rejected by: Robert Sparks
Date Rejected: 2012-11-04

Section 5 says:

At page 9:


      Media description, if present
         m=  (media name and transport address)

It should say:

      Media description, if present
         m=* (media name and transport address)

Notes:

A '*' is added making "m=" lines optional

Rationale:
The description about media lines in section 5, page 9 is conflicting with the ABNF syntax of media-description in Section 9, page 40

media-descriptions = *( media-field
information-field
*connection-field
bandwidth-fields
key-field
attribute-fields )

According to the ABNF grammar, an SDP description can have zero "m=" lines, but according to the description at page 9, at least one line must be present. Note that the conflict could be solved also by replacing the media-descriptions definition with

media-descriptions = 1*( media-field ... )

but at page 8 (still Section 5) it is said

An SDP session description consists of a session-level section
followed by zero or more media-level sections. ...
^^^^^^^^^^^^^^^^^^^^^^^^

so, I guess that the ABNF grammar is correct.
--VERIFIER NOTES--
Please see the discussion at http://www.ietf.org/mail-archive/web/mmusic/current/msg09398.html

Errata ID: 4769
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Petr Vaněk
Date Reported: 2016-08-08
Rejected by: Ben Campbell
Date Rejected: 2016-08-08

Section 5.3. says:

5.3.  Session Name ("s=")

      s=<session name>

   The "s=" field is the textual session name.  There MUST be one and
   only one "s=" field per session description.  The "s=" field MUST NOT
   be empty and SHOULD contain ISO 10646 characters (but see also the
   "a=charset" attribute).  If a session has no meaningful name, the
   value "s= " SHOULD be used (i.e., a single space as the session
   name).

It should say:

5.3.  Session Name ("s=")

      s=<session name>

   The "s=" field is the textual session name.  There MUST be one and
   only one "s=" field per session description.  The "s=" field MUST NOT
   be empty and SHOULD contain ISO 10646 characters (but see also the
   "a=charset" attribute).  If a session has no meaningful name, the
   value "s=-" SHOULD be used (i.e., a single dash as the session
   name).

Notes:

In 3rd paragraph of section 5. is written: whitespace MUST NOT be used on either side of the "=" sign, which is incosistent with subsection 5.3. Therefore I suggest to use "-" (single dash) instead of " " (single space) for sessions without meaningful name.
--VERIFIER NOTES--
The mmusic working group is in the process of updating RFC 4566. If the issue applies to the updated text ( https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis/ ), please send comments to mmusic@ietf.org rather than file errata reports against RFC 4566.

RFC 4570, "Session Description Protocol (SDP) Source Filters", July 2006

Source of RFC: mmusic (rai)

Errata ID: 55
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Rejected by: Ross Finlayson
Date Rejected: 2006-11-01

Section 6 says:

        Purpose:            See this document
        Reference:          This document
        Values:             See this document, and registrations below

It should say:

        Purpose:            See RFC 4632
        Reference:          RFC 4632
        Values:             See RFC 4632

Notes:

The filled out SDP attribute registration template in the IANA
Considerations (Section 6) on page 10 contains improper wording
-- either just being garbage (there are no 'registrations below'
in the RFC), or getting inappropriate when extracted from the RFC
and included in a stand-alone IANA document.

--VERIFIER COMMENT--
Thanks for the comments. It would have been nice if these very minor
errors could have been corrected prior to RFC publication. However,
I'm not convinced that they are significant enough to warrant a RFC
Errata note. (If, however, the RFC editor disagrees, then I could
certainly go ahead and do this.)

Errata ID: 802
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Rejected by: Ross Finlayson
Date Rejected: 2006-11-01

Section 1 says:

   Applications and hosts may also
   share the source-filter information with network elements (e.g., with
   routers using [IGMPv3]) so they can potentially perform the traffic
|  filtering operation further "upstream," closer to the source(s).

It should say:

   Applications and hosts may also
   share the source-filter information with network elements (e.g., with
   routers using [IGMPv3]) so they can potentially perform the traffic
|  filtering operation further "upstream", closer to the source(s).

Notes:

quoting style

from pending

--VERIFIER COMMENT--
Thanks for the comments. It would have been nice if these very minor
errors could have been corrected prior to RFC publication. However,
I'm not convinced that they are significant enough to warrant a RFC
Errata note. (If, however, the RFC editor disagrees, then I could
certainly go ahead and do this.)

Errata ID: 804
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Rejected by: Ross Finlayson
Date Rejected: 2006-11-01

Section 1 says:

   Use of source-filters do not
   corrupt the ASM semantics but provide more control for receivers, at
   their discretion.

It should say:

|  Use of source-filters does not
|  corrupt the ASM semantics but provides more control for receivers, at
   their discretion.

Notes:

from pending

--VERIFIER COMMENT--
Thanks for the comments. It would have been nice if these very minor
errors could have been corrected prior to RFC publication. However,
I'm not convinced that they are significant enough to warrant a RFC
Errata note. (If, however, the RFC editor disagrees, then I could
certainly go ahead and do this.)

RFC 4577, "OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)", June 2006

Source of RFC: l3vpn (int)

Errata ID: 6840
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Igor Malyushkin
Date Reported: 2022-02-07
Rejected by: Eric Vyncke
Date Rejected: 2023-08-03

Section 4.2.4 says:

[...] If they are in different domains, and
   if routes from one are distributed into the other, the routes will
   appear as intra-network routes, which may not be what is intended.)

It should say:

[...] If they are in different domains, and
   if routes from one are distributed into the other, the routes will
   appear as inter-network routes, which may not be what is intended.)

Notes:

Inter-intra typo. Inter-network routes are used between the OSPF instances with the same Domain ID. With different Domain IDs, external-AS routes are applicable.
--VERIFIER NOTES--
The issue is that they will appear as intra-network routes while they are not.

RFC 4583, "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", November 2006

Note: This RFC has been obsoleted by RFC 8856

Source of RFC: mmusic (rai)

Errata ID: 4111
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christian Groves
Date Reported: 2014-09-14
Rejected by: Richard Barnes
Date Rejected: 2014-09-21

Section 9 says:

For the purpose of brevity, the main portion of the session
   description is omitted in the examples, which only show 'm' lines and
   their attributes.

   The following is an example of an offer sent by a conference server
   to a client.

   m=application 50000 TCP/TLS/BFCP *
   a=setup:passive
   a=connection:new
   a=fingerprint:SHA-1 \
        4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
   a=floorctrl:s-only
   a=confid:4321
   a=userid:1234
   a=floorid:1 m-stream:10
   a=floorid:2 m-stream:11
   m=audio 50002 RTP/AVP 0
   a=label:10
   m=video 50004 RTP/AVP 31
   a=label:11

...

It should say:

For the purpose of brevity, the main portion of the session
   description is omitted in the examples, which only show 'm' lines and
   their attributes.

   The following is an example of an offer sent by a conference server
   to a client.

   m=application 50000 TCP/TLS/BFCP *
   a=setup:passive
   a=connection:new
   a=fingerprint:SHA-1 \
        4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
   a=floorctrl:s-only
   a=confid:4321
   a=userid:1234
   a=floorid:1 mstrm:10
   a=floorid:2 mstrm:11
   m=audio 50002 RTP/AVP 0
   a=label:10
   m=video 50004 RTP/AVP 31
   a=label:11

...

Notes:

In section 6 of the RFC the ABNF for the "floorid" attribute is:
floor-id-attribute = "a=floorid:" token [" mstrm:" token *(SP token)]

The text string " mstrm:" is used to reference the media stream rather than "m-stream" that appears in the examples.
--VERIFIER NOTES--
The error noted in the erratum is already being addressed in a document that will obsolete this RFC.

RFC 4585, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", July 2006

Note: This RFC has been updated by RFC 5506, RFC 8108

Source of RFC: avt (rai)

Errata ID: 51
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-17
Rejected by: Joerg Ott
Date Rejected: 2006-08-17

Errors (11)-(19) of 19

(11)  [formatting issue]

In Section 6, the text around the page break from page 31 to page 32
is not formatted properly.
The RFC says:

      [...]
      audio and DTMF) or when codec changes occur, the payload type
      information may need to be conveyed explicitly as part of the FB
      message.  This applies to all
 << page break >>
      payload-specific as well as application layer FB messages.  It is
      up to the specification of an FB message to define how payload
      type information is transmitted.

It should say:

      [...]
      audio and DTMF) or when codec changes occur, the payload type
      information may need to be conveyed explicitly as part of the FB
      message.  This applies to all payload-specific as well as
 << page break >>
      application layer FB messages.  It is up to the specification of
      an FB message to define how payload type information is
      transmitted.


(12)  [inconsistent text]

Still in Section 6, the second paragraph on page 32 (immediately
following the text quotation in item (11) above) says:

                         vvv
|  This document defines two transport layer and three (video) payload-
   specific FB messages as well as a single container for application
   layer FB messages.  Additional transport layer and payload-specific
   FB messages MAY be defined in other documents and MUST be registered
   through IANA (see Section 9, "IANA Considerations").

It should say:
                         vvv
|  This document defines one transport layer and three (video) payload-
   specific FB messages as well as a single container for application
   layer FB messages.  Additional transport layer and payload-specific
   FB messages MAY be defined in other documents and MUST be registered
   through IANA (see Section 9, "IANA Considerations").

Rationale:
Cf. the third paragraph of Section 6, on page 31, and
the subsequent pages, in particular page 34, where the
second paragraph of Section 6.2 says:

|  A single general purpose transport layer FB message is defined in
   this document: Generic NACK.  It is identified by means of the FMT
   parameter as follows:

   [...]

(And so it does, per Section 6.2.1.)


(13)  [incomplete specification?]

Within Section 6.1, the last paragraph on page 33 says:

   Each RTCP feedback packet MUST contain at least one FB message in the
   FCI field.  Sections 6.2 and 6.3 define for each FCI type, whether or
   not multiple FB messages MAY be compressed into a single FCI field.
|  If this is the case, they MUST be of the same type, i.e., same FMT.
|  If multiple types of feedback messages, i.e., several FMTs, need to
   be conveyed, then several RTCP FB messages MUST be generated and
   SHOULD be concatenated in the same compound RTCP packet.

I strongly suspect -- and this is supported by the examples in the
RFC -- that feedback packets to be combined MUST also have the same
payload type (PT), not only agree in their FMT values.
Otherwise, there would be no way to carry the different PT values
in the FB message according to the format specified in Figure 3.

Therefore, the RFC should say:

   Each RTCP feedback packet MUST contain at least one FB message in the
   FCI field.  Sections 6.2 and 6.3 define for each FCI type, whether or
   not multiple FB messages MAY be compressed into a single FCI field.
|  If this is the case, they MUST be of the same type, i.e., same PT and
|  the same FMT.  If multiple types of feedback messages, i.e., several
|  PTs and/or several FMTs, need to be conveyed, then several RTCP FB
   messages MUST be generated and SHOULD be concatenated in the same
   compound RTCP packet.

(Authors, please supply alternative wording, if you desire.)

Note:
Perhaps, this issue arised because of the slightly differing
semantics implied for the various usages of the term "FB message"
in Section 6.1 -- (a) the whole RTCP FB message, and (b) a semantic
entity carried in the FCI field of that RTCP message.
Future updates to the RFC might try further clarifications of the
text to avoid this subtle sematic overloading.


(14)  [missing article]

The last paragraph of Section 6.3, at the bottom of page 35, says:

   The following subsections define the FCI formats for the payload-
|  specific FB messages, Section 6.4 defines FCI format for the
   application layer FB message.

It should say:

   The following subsections define the FCI formats for the payload-
|  specific FB messages, Section 6.4 defines the FCI format for the
   application layer FB message.


(15)  [extraneous words]

The second paragraph of Section 6.3.1.1, on page 36, says:

   Other RTP payload specifications such as RFC 2032 [6] already define
|  a feedback mechanism for some for certain codecs.  An application
   supporting both schemes MUST use the feedback mechanism defined in
   this specification when sending feedback.  For backward compatibility
   reasons, such an application SHOULD also be capable to receive and
   react to the feedback scheme defined in the respective RTP payload
   format, if this is required by that payload format.

It should say:

   Other RTP payload specifications such as RFC 2032 [6] already define
|  a feedback mechanism for certain codecs.  An application supporting
   both schemes MUST use the feedback mechanism defined in this
   specification when sending feedback.  For backward compatibility
   reasons, such an application SHOULD also be capable to receive and
   react to the feedback scheme defined in the respective RTP payload
   format, if this is required by that payload format.


(16)  [misleading wording]

The first paragraph of Section 6.3.2.2, on page 37, says:

                                                     vvvvv
|  The Slice Loss Indication uses one additional FCI field, the content
   of which is depicted in Figure 6.  The length of the FB message MUST
   be set to 2+n, with n being the number of SLIs contained in the FCI
   field.

To avoid the semantic overloading of the word "field", it should
perhaps better say:
                                                     vvvv
|  The Slice Loss Indication uses one additional FCI word, the content
   of which is depicted in Figure 6.  The length of the FB message MUST
   be set to 2+n, with n being the number of SLIs contained in the FCI
   field.


(17)  [typo]

The first paragraph of Section 6.3.3.1, on page 39, says:

                             v
                                   [...].  As this reference picture is
|  temporally further away then usual, the resulting predictively coded
   picture will use more bits.

It should say:
                             v
                                   [...].  As this reference picture is
|  temporally further away than usual, the resulting predictively coded
   picture will use more bits.


(18)  [inappropriate wording]

The first paragraph of Section 8, on page 42, says:

   RTP packets transporting information with the proposed payload format
   are subject to the security considerations discussed in the RTP
   specification [1] and in the RTP/AVP profile specification [2].  This
   profile does not specify any additional security services.

The wording of the first sentence is inappropriate for this RFC.
(It perhaps has been copied unchanged from an RFC with an RTP Payload
specification.)

RFC 4585 should say instead:

|  RTP packets transporting information as defined in various payload
|  formats supporting this profile are subject to the security
   considerations discussed in the RTP specification [1] and in the
   RTP/AVP profile specification [2].  This profile does not specify any
   additional security services.


(19)  [redundant Ref.]

The Normative Reference [7] (in Section 11.1, on page 48) and
the Informative Reference [20] (in Section 11.2, on page 49)
both point to RFC 3448.
([7] and [20] are referred to once each in the RFC text.)

This is unusual and unexpected.  Only one pointer to RFC 3448
should have been specified.  Authors, please check.

Notes:

from pending

--VERIFIER COMMENT--
Thanks for the review. I have only quickly skimmed your comments
and there does not seem to be anything serious.

We will be happy to archive these and migt consider them if
we do a revision of the RFC. But an errata document would
only make sense if there is something seriously hindering
interoperability. I have not seen anything falling into this
category (well, and there are implementations out there from
the spec).

Errata ID: 768
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-17
Rejected by: Joerg Ott
Date Rejected: 2006-08-17

Errors (1)-(10) of 19

(1)

Section 1.1 of RFC 4585, on mid-page 4, says:

   Feedback (FB) message:
      An RTCP message as defined in this document is used to convey
      information about events observed at a receiver -- in addition to
      long-term receiver status information that is carried in RTCP
      receiver reports (RRs) -- back to the sender of the media stream.
|     For the sake of clarity, feedback message is referred to as FB
|     message throughout this document.

I do not see how and why using the abbreviation might have improved
*clarity* of the text; apparently, it has been used for *brevity* .
Therefore, the two tagged lines should better say:

|     For the sake of brevity, feedback message is referred to as FB
|     message throughout this document.

Similarly, at the bottom of page 4, where the RFC says:

   Feedback (FB) threshold:
      The FB threshold indicates the transition between Immediate
      Feedback and Early RTCP mode.  [...]
      [...]
      to application designers and is not used in any calculations.  For
|     the sake of clarity, the term feedback threshold is referred to as
      FB threshold throughout this document.

The last 3 lines should better say:

      to application designers and is not used in any calculations.  For
|     the sake of brevity, the term feedback threshold is referred to as
      FB threshold throughout this document.


(2)

The first bulleted item in Section 3.1, on page 7, says:
                                                    vvvvvvvvvvvvv
|  o  Status reports are contained in sender report (SR)/received report
      (RR) packets and are transmitted at regular intervals as part of
      compound RTCP packets (which also include source description
      (SDES) and possibly other messages); these status reports provide
      an overall indication for the recent reception quality of a media
      stream.

For *clarity*, it perhaps should better say -- not binding together the
words intended to being separated by the slash marking the alternative:
                                                        vvv
|  o  Status reports are contained in sender report (SR) / received
      report (RR) packets and are transmitted at regular intervals as
      part of compound RTCP packets (which also include source
      description (SDES) and possibly other messages); these status
      reports provide an overall indication for the recent reception
      quality of a media stream.


(3)  [missing article]

In Section 3.4, on mid-page 11, RFC 4585 says:

   j) Let T_fd be the actual (randomized) delay for the transmission of
      FB message in response to an event at time t0.

It should say:

   j) Let T_fd be the actual (randomized) delay for the transmission of
|     a FB message in response to an event at time t0.
      ^^

(4)  [inappropriate wording]

The algorithm in Section 3.5.2, at the bottom of page 16, contains
the sub-step:

      4b) If allow_early == TRUE, then R MUST schedule an Early RTCP
          packet for te = t0 + RND * T_dither_max with RND being a
|         pseudo random function evenly distributed between 0 and 1.
                        ^^^^^^^^

This wording is inappropriate.  RND is not a *function* (that's code!),
but a *number*, the function *value*.  Therefore, the RFC should say:

      4b) If allow_early == TRUE, then R MUST schedule an Early RTCP
          packet for te = t0 + RND * T_dither_max with RND being a
|         pseudo random number evenly distributed between 0 and 1.
                        ^^^^^^


(5)  [inappropriate wording]

The algorithm in Section 3.5.3, at the top of page 19, says:

   2. Otherwise, a temporary value T_rr_current_interval is calculated
      as follows:

         T_rr_current_interval = RND*T_rr_interval

|     with RND being a pseudo random function evenly distributed between
      0.5 and 1.5.  This dithered value is used to determine one of the
      following alternatives:

Similar to item (4) above, the RFC should say instead:

   2. Otherwise, a temporary value T_rr_current_interval is calculated
      as follows:

         T_rr_current_interval = RND*T_rr_interval

|     with RND being a pseudo random number evenly distributed between
      0.5 and 1.5.  This dithered value is used to determine one of the
      following alternatives:


(6)  [typo / dup. wording]

Section 3.6.2 of RFC 4585, on mid-page 21, says:

   Example: If a 256-kbit/s video with 30 fps is transmitted through a
   network with an MTU size of some 1,500 bytes, then, in most cases,
|  each frame would fit in into one packet leading to a packet rate of
   30 packets per second.  [...]

It should say:

   Example: If a 256-kbit/s video with 30 fps is transmitted through a
   network with an MTU size of some 1,500 bytes, then, in most cases,
|  each frame would fit into one packet leading to a packet rate of
   30 packets per second.  [...]


(7)  [wrong ref. tag]

On mid-page 23, Section 4.1 of RFC 4585 says:

                             vvv
|  The AV profile defined in [4] is referred to as "AVP" in the context
   of, e.g., the Session Description Protocol (SDP) [3].  The profile
   specified in this document is referred to as "AVPF".

There apparently is a confusion of the ref. tags used.
The RFC should say:
                             vvv
|  The AV profile defined in [2] is referred to as "AVP" in the context
   of, e.g., the Session Description Protocol (SDP) [3].  The profile
   specified in this document is referred to as "AVPF".


(8)  [missing article]

In Section 4.2, near the top of page 25, the ABNF production:

      rtcp-fb-pt         = "*"   ; wildcard: applies to all formats
|                        / fmt   ; as defined in SDP spec

should better say, improving the ABNF comment text:

      rtcp-fb-pt         = "*"   ; wildcard: applies to all formats
|                        / fmt   ; as defined in the SDP spec
                                                ^^^^^


(9)  [inconsistent specification]

In Section 4.2, the ABNF on page 25 contains the following productions:

      rtcp-fb-val        = "ack" rtcp-fb-ack-param
                         / [...]
and
      rtcp-fb-ack-param  = SP "rpsi"
                         / SP "app" [SP byte-string]
                         / SP token [SP byte-string]
|                        / ; empty

This means that the feedback type "ack" *MAY* have parameters.

Contrary to that, below the ABNF, the RFC explains:

   Feedback type "ack":

      This feedback type indicates that positive acknowledgements for
      feedback are supported.

      The feedback type "ack" MUST only be used if the media session is
      allowed to operate in ACK mode as defined in Section 3.6.1.

|     Parameters MUST be provided to further distinguish different types
|     of positive acknowledgement feedback.

      [...]

The *MUST* in the tagged lines contradicts the ABNF.

Authors, please resolve the issue:

Either have the ABNF changed by omission of the tagged line above,

|                        / ; empty

or change the tagged explanation lines to say:

|     Parameters MAY be provided to further distinguish different types
|     of positive acknowledgement feedback.


(10)  [incomplete specification, and an extraneous word]

At the bottom of page 26, Section 4.2 of RFC 4585 says:

   Other feedback types <rtcp-fb-id>:

      Other documents MAY define additional types of feedback; to keep
      the grammar extensible for those cases, the rtcp-fb-id is
|     introduced as a placeholder.  A new feedback scheme name MUST to
      be unique (and thus MUST be registered with IANA).  Along with a
|     new name, its semantics, packet formats (if necessary), and rules
      for its operation MUST be specified.

It should say:

   Other feedback types <rtcp-fb-id>:

      Other documents MAY define additional types of feedback; to keep
      the grammar extensible for those cases, the rtcp-fb-id is
|     introduced as a placeholder.  A new feedback scheme name MUST be
      unique (and thus MUST be registered with IANA).  Along with a new
|     new name, its semantics, possible parameters, packet formats (if
      necessary), and rules for its operation MUST be specified.

Rationale:

a) "MUST to be unique" should be "MUST be unique".

b) Syntax and semantics of parameters (if any) obviously MUST be
   specified as well.  The RFC text in the IANA Considerations
   (Section 9) already reflects this requirement.
   For completeness and clarity, it should be stated here as well.
   I have proposed minimal additional wording -- you might choose
   alternative words.

Notes:

from pending

--VERIFIER COMMENT--
Thanks for the review. I have only quickly skimmed your comments
and there does not seem to be anything serious.

We will be happy to archive these and migt consider them if
we do a revision of the RFC. But an errata document would
only make sense if there is something seriously hindering
interoperability. I have not seen anything falling into this
category (well, and there are implementations out there from
the spec).

RFC 4588, "RTP Retransmission Payload Format", July 2006

Source of RFC: avt (rai)

Errata ID: 48
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-14
Rejected by: Jose Rey

Section 8.1 says:

   The following MIME subtype name and parameters are introduced in this
   document: "rtx", "rtx-time", and "apt".

   The binding used for the retransmission stream to the payload type
   number is indicated by an rtpmap attribute.  The MIME subtype name
   used in the binding is "rtx".

   The "apt" (associated payload type) parameter MUST be used to map the
   retransmission payload type to the associated original stream payload
   type.  If multiple original payload types are used, then multiple
   "apt" parameters MUST be included to map each original payload type
   to a different retransmission payload type.

It should say:

   The following MIME subtype name and parameters are introduced in this
   document: "rtx", "rtx-time", and "apt".

   The binding used for the retransmission stream to the payload type
   number is indicated by an rtpmap attribute.  The MIME subtype name
   used in the binding is "rtx".  The MIME type of the retransmission
   stream MUST be the same as the MIME type of the original stream.

   The "apt" (associated payload type) parameter MUST be used to map the
   retransmission payload type to the associated original stream payload
   type.  If multiple original payload types are used, then multiple
   "apt" parameters MUST be included to map each original payload type
   to a different retransmission payload type.

Notes:

This text only addresses the use of the media *sub*-type. Apparently,
it is implied that the media *type* of the associated streams match,
but I could not find a statement to this end in the RFC.

(In accordance with the language of RFC 4588, but contrary to BCP 13,
RFC 4288, I have again used the traditional wording "MIME type" here
instead of the currently recommended "media type".)

from pending

--VERIFIER COMMENT--

Thanks for your comments. However, I don't consider them worth of correction. Most are just editorial nits, some of which are even wrong. So, for the time being as Joerg said:

"We will be happy to archive these and migt consider them if we do a revision of the RFC. But an errata document would only make sense if there is something seriously hindering interoperability. I have not seen anything falling into this category (well, and there are implementations out there from the spec)."

Errata ID: 759
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-14
Rejected by: Jose Rey
Date Rejected: 2006-08-29

 

(1)  [missing article]

Within Section 4 of RFC 4588, the second paragraph on page 8 says:

            [...].  See Section 8.1 for the specification of how the
   mapping between original and retransmission payload types is done
|  with Session Description Protocol (SDP).

It should say:

            [...].  See Section 8.1 for the specification of how the
   mapping between original and retransmission payload types is done
|  with the Session Description Protocol (SDP).
       ^^^^^


(2)  [improper wording]

The 4th paragraph of Section 6.3, on page 12, says:

            [...].  In such cases, an appropriate "reorder delay"
   algorithm may not actually be timer based, but packet based.  For
|  example, if n number of packets are received after a gap is detected,
   then it may be assumed that the packet was truly lost rather than out
   of order.  This may turn out to be far easier to code on some
   platforms as a very short fixed FIFO packet buffer as opposed to the
   timer-based mechanism.

It should say:

            [...].  In such cases, an appropriate "reorder delay"
   algorithm may not actually be timer based, but packet based.  For
|  example, if n packets are received after a gap is detected, then it
   may be assumed that the packet was truly lost rather than out of
   order.  This may turn out to be far easier to code on some platforms
   as a very short fixed FIFO packet buffer as opposed to the timer-
   based mechanism.

(Alternatively, use  "if a number n of packets ..."  instead of the
 offending "if n number of packets ..." )


(3)  [word omission]

In the first paragraph of Section 6.4, on page 13, RFC 4588 says:

   [...]                                      v
|  Sending NACKs only in regular RTCP compound decreases the maximum
   delay between detecting an original packet loss and being able to
   send a NACK for that packet.  Implementers should consider the
   possible implications of this fact for the application being used.

It should say:

   [...]                                      vvvvvvvvv
|  Sending NACKs only in regular RTCP compound packets decreases the
   maximum delay between detecting an original packet loss and being
   able to send a NACK for that packet.  Implementers should consider
   the possible implications of this fact for the application being
   used.


(4)  [[posted separately.]]


(5)  [word omission]

Later on in Section 8.1, on mid-page 15, the RFC says:

      v
|  The syntax is as follows:

      a=fmtp:<number> apt=<apt-value>;rtx-time=<rtx-time-val>

It should say:

      vvvvv
|  The SDP syntax is as follows:

      a=fmtp:<number> apt=<apt-value>;rtx-time=<rtx-time-val>

(There also is a syntax for these parameters when written in a full
 MIME media type specification; this is not presented in the RFC,
 but it must be distinguished from the SDP syntax presented!)


(6)  [excessive text]

The final paragraph of Section 8.6, on mid-page 20, says:

   In the following sections, some example SDP descriptions are
|  presented.  In some of these examples, long lines are folded to meet
|  the column width constraints of this document; the backslash ("\") at
|  the end of a line and the carriage return that follows it should be
|  ignored.

It would suffice to say:

   In the following sections, some example SDP descriptions are
|  presented.

Rationale:
As will be shown below, in the examples given in Section 8.7,
there in fact is no need to perform this artificial line folding.


(7)  [simplification for improved clarity]

The artificial line folding in the examples in Section 8.7 can be
avoided without change in the indentation, while still conforming
with the line length limitations:

a) In the upper half of page 21, the lines,

   a=fmtp:98 profile-level-id=8;config=01010000012000884006682C209\
   0A21F

should read:

   a=fmtp:98 profile-level-id=8;config=01010000012000884006682C2090A21F

b) In the lower half of page 21, the lines,

   a=fmtp:96 profile-level-id=8;config=01010000012000884006682C209\
   0A21F

should read:

   a=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F

c) In the upper half of page 22, the lines,

   a=fmtp:96 profile-level-id=8;config=01010000012000884006682C209\
   0A21F

should read:

   a=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F


(8)  [clarification]

On mid-page 21, the text in Section 8.7 says:

   A special case of the SDP description is a description that contains
   only one original session "m" line and one retransmission session "m"
   line, the grouping is then obvious and FID semantics MAY be omitted
   in this special case only.

It should better say:

   A special case of the SDP description is a description that contains
   only one original session "m" line and one retransmission session "m"
|  line, the grouping is then obvious and lines with grouping syntax
   (FID semantics) MAY be omitted in this special case only.

Rationale:
It is impossible to only omit *semantics*.
Certain *lines* are omitted there -- the lines with grouping syntax
(and FID semantics).
Alternatively, "(FID semantics)" might be omitted entirely from
the changed text, as well.


(9)  [word omission -- clarification]

The first paragraph of Section 10.2, on page 25, says:

   This section shows how to combine retransmissions with layered
   encoding in multicast sessions.  Note that the retransmission
   framework is offered only for small multicast applications.  Refer to
   RFC 2887 [10] for a discussion of the problems of NACK implosion,
   severe congestion caused by feedback traffic, in large-group reliable
   multicast applications.

It should better say:

   This section shows how to combine retransmissions with layered
   encoding in multicast sessions.  Note that the retransmission
   framework is offered only for small multicast applications.  Refer to
|  RFC 2887 [10] for a discussion of the problems of NACK implosion, and
   severe congestion caused by feedback traffic, in large-group reliable
   multicast applications.
                                                                     ^^^


(10)  [word omission]

In the first paragraph on page 27, text within Section 13 says:

                                            [...].  Refer to Section 9.1
   of the Secure Real-Time Transport Protocol (SRTP) [12] for a
|  discussion the implications of two-time pads and how to avoid them.
             ^

It should say:
                                                    vvvvvvvvvvvvvvv
                                            [...].  Refer to Section 9.1
|  of the Secure Real-Time Transport Protocol (SRTP) specification [12]
|  for a discussion of the implications of two-time pads and how to
   avoid them.
                   ^^^^

(11)  [inconsistency]

In the fourth bullet on page 29, Appendix A.1 says:

   * avg-rtcp-size is approximated by 120 bytes.  This is a rounded-up
     average of 2 SRs, one for each SSRC, containing 40/8/28/32 bytes
     for IPv6/UDP/SR/SDES with CNAME, thus making 105 bytes each; and a
     RR with 40/8/64/32 bytes for IPv6/UDP/2*RR/SDES, making 157 bytes.
     [...]

I cannot follow these computations:
    40+8+28+32 = 105  ???   and   40+8+64+32 = 157  ???
What is wrong there?
Authors, please correct !

BTW:
What follows in the text essentially does not depend on the exact
figures, the rough order of magnitude is all that is needed.
But the presentation should be self-consistent.


(12)  [improvement of wording]

In the 6th bullet of Appendix A.1, the text on page 29/30 says:

        [...].  This means that if a packet is requested for
     retransmission a maximum of 2 times, the corresponding generic NACK
     report block requesting that particular packet is sent in two
 << page break >>
|    consecutive RTCP compounds; likewise, if it is requested for
     retransmission 10 times, then the generic NACK is sent 10 times.
     [...]

It should say:

        [...].  This means that if a packet is requested for
     retransmission a maximum of 2 times, the corresponding generic NACK
     report block requesting that particular packet is sent in two
 << page break >>
|    consecutive RTCP compound packets; likewise, if it is requested for
     retransmission 10 times, then the generic NACK is sent 10 times.
     [...]


(13)  [missing argument / clarification]

On page 31, Appendix A.2 says:
                                               vv
|  To find an estimate of the buffering time, T(), that a streaming
   server shall use in order to enable a given number of retransmissions
   for each packet, N.  [...]

It should say:
                                               vvv
|  To find an estimate of the buffering time, T(N), that a streaming
   server shall use in order to enable a given number of retransmissions
   for each packet, N.  [...]


(14)  [fractional sign]

Within the tables in Appendix A.4, on pages 32 and 33, the RFC text
uses the comma (",") as the fractional sign (central european style).
In IETF documents, the decimal point (".") should be used instead.


Authors, Please comment.
Items (4) / (11) need agreement / text correction from you.
Items (6) + (7) might be considered non-esssential.
All other items seem to be straightforward and suitable for
inclusion in an Errata Note.

Notes:

from pending

--VERIFIER COMMENT--


Thanks for your comments. However, I don't consider them worth of correction. Most are just editorial nits, some of which are even wrong. So, for the time being as Joerg said:

"We will be happy to archive these and migt consider them if we do a revision of the RFC. But an errata document would only make sense if there is something seriously hindering interoperability. I have not seen anything falling into this category (well, and there are implementations out there from the spec)."

RFC 4590, "RADIUS Extension for Digest Authentication", July 2006

Note: This RFC has been obsoleted by RFC 5090

Source of RFC: radext (sec)

Errata ID: 47
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alexander Schrab
Date Reported: 2006-09-21
Rejected by: Dan Romascanu
Date Rejected: 2009-09-03

Section 3.5 says:

Digest-Nextnonce        106
Digest-Response-Auth    107 

Notes:

--VERIFIER NOTES--
itis unclear what is wrong

RFC 4591, "Frame Relay over Layer 2 Tunneling Protocol Version 3 (L2TPv3)", August 2006

Note: This RFC has been updated by RFC 5641

Source of RFC: l2tpext (int)

Errata ID: 3222
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-11
Rejected by: Brian Haberman
Date Rejected: 2012-05-10

 

(1)  [line folding issue]

The final part of Section 3.2, on page 5 of RFC 4591, syas:

   General Result Codes regarding L2TP session establishment are defined
   in [RFC3931].  Additional Frame Relay result codes are defined as
   follows:

      17: FR PVC was deleted permanently (no longer provisioned) 18: FR
      PVC has been INACTIVE for an extended period of time 19:
      Mismatched FR Header Length

For clarity, the RFC sould say instead:

   General Result Codes regarding L2TP session establishment are defined
   in [RFC3931].  Additional Frame Relay result codes are defined as
   follows:

|     17: FR PVC was deleted permanently (no longer provisioned)
|     18: FR PVC has been INACTIVE for an extended period of time
|     19: Mismatched FR Header Length


(2)  [another line folding issue]

Within Section 3.5, on page 7, the RFC text just below the diagram
says:

   The Frame Relay Header Length Type is a 2-octet unsigned integer with
   the following values defined in this document:

      2: Two-octet Frame Relay Header 4: Four-octet Frame Relay Header

For clarity, the RFC sould say instead:

   The Frame Relay Header Length Type is a 2-octet unsigned integer with
   the following values defined in this document:

|     2: Two-octet Frame Relay Header
|     4: Four-octet Frame Relay Header


(3)  [missing colons, and formatting]

In Section 4.1, the explanations just below the FR Header diagrams
on page 8 of the RFC read:

   C/R (bit 6) FR frame C/R (command/response) bit [Q922].

   F - FECN (bit 12):  FR FECN (Forward Explicit Congestion
   Notification) bit [Q922].

   B - BECN (bit 13):
|
   FR BECN (Backward Explicit Congestion Notification) bit [Q922].

   D - DE (bit 14) FR DE bit indicates the discard eligibility [Q922].

For clarity, it should better say:

            vvvvv
|  C (bit 6):     FR frame C/R (command/response) bit [Q922].

|  F (bit 12):    FR FECN (Forward Explicit Congestion Notification)
|                 bit [Q922].

|  B (bit 13):    FR BECN (Backward Explicit Congestion Notification)
|                 bit [Q922].

|  D (bit 14):    FR DE bit indicates the discard eligibility [Q922].
             ^^^^

[ Additional rationale for the proposed clarifications:
  The "full bit names" have been removed from the left hand sides
  (corresponding to the diagrams), and replaced "C/R" by "C", because
  these "full bit names" do not appear in the diagrams, but already do
  appear in the explanatory text on the right hand side.  Thus, to the
  left of the colons, there now are only -- and precisely -- the terms
  from the diagrams. ]


(4)  [typo + word omission]

The first paragraph of Section 4.3, on page 9, says:
                                                           vv
   With L2TPv3 as the tunneling protocol, the packet resulted from the
   encapsulation is N bytes longer than Frame Relay frame without the
   opening and closing HDLC flags or FCS.  The value of N depends on the
   following fields:

It should say:
                                                           vvv
|  With L2TPv3 as the tunneling protocol, the packet resulting from the
|  encapsulation is N bytes longer than the Frame Relay frame without
   the opening and closing HDLC flags or FCS.  The value of N depends on
   the following fields:

It should say:

[see above]

Notes:

from pending
--VERIFIER NOTES--
Extraneous duplicate of errata 735

RFC 4601, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", August 2006

Note: This RFC has been obsoleted by RFC 7761

Note: This RFC has been updated by RFC 5059, RFC 5796, RFC 6226

Source of RFC: pim (rtg)

Errata ID: 1099
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26

Section List of Figu says:

Figure 7. Upstream (*,G) state machine ............................67

It should say:

Figure 7. Upstream (*,G) state machine .........................67-68

Notes:

Figure 1 occurs on pages 67-68, is listed as occurring on page 67.
--VERIFIER NOTES--
List of figures is like a table of contents and only needs to point to the first page on which the figure can be found.

Errata ID: 1100
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26

Section List of Figu says:

Figure 8. Upstream (S,G) state machine ............................71

It should say:

Figure 8. Upstream (S,G) state machine .........................72-73

Notes:

Figure 1 occurs on page 72-73, is listed as occurring on page 71.
--VERIFIER NOTES--
List of figures is like a table of contents and only needs to point to the first page on which the figure can be found.

Errata ID: 1102
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26

Section List of Figu says:

Figure 10. Per-interface (S,G) Assert State machine ...............84

It should say:

Figure 10. Per-interface (S,G) Assert State machine ............84-85

Notes:

Figure 1 occurs on pages 84-85, is listed as occurring on page 84.
--VERIFIER NOTES--
List of figures is like a table of contents and only needs to point to the first page on which the figure can be found.

Errata ID: 1103
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26

Section List of Figu says:

Figure 11. Per-interface (*,G) Assert State machine ...............92

It should say:

Figure 11. Per-interface (*,G) Assert State machine ............92-93

Notes:

Figure 1 occurs on pages 92-93, is listed as occurring on page 92.
--VERIFIER NOTES--
List of figures is like a table of contents and only needs to point to the first page on which the figure can be found.

Errata ID: 1120
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26

Section 4.5.2 says:

+------------++--------------------------------------------------------+
|            ||                         Event                          |
|            ++-------------+--------------+-------------+-------------+
|Prev State  ||Receive      | Receive      | Prune-      | Expiry Timer|
|            ||Join(*,G)    | Prune(*,G)   | Pending     | Expires     |
|            ||             |              | Timer       |             |
|            ||             |              | Expires     |             |
+------------++-------------+--------------+-------------+-------------+
|            ||-> J state   | -> NI state  | -           | -           |
|NoInfo (NI) ||start Expiry |              |             |             |
|            ||Timer        |              |             |             |
+------------++-------------+--------------+-------------+-------------+
|            ||-> J state   | -> PP state  | -           | -> NI state |
|Join (J)    ||restart      | start Prune- |             |             |
|            ||Expiry Timer | Pending      |             |             |
|            ||             | Timer        |             |             |
+------------++-------------+--------------+-------------+-------------+
|Prune-      ||-> J state   | -> PP state  | -> NI state | -> NI state |
|Pending (PP)||restart      |              | Send Prune- |             |
|            ||Expiry Timer |              | Echo(*,G)   |             |
+------------++-------------+--------------+-------------+-------------+

It should say:

+------------++--------------------------------------------------------+
|            ||                         Event                          |
|            ++-------------+--------------+-------------+-------------+
|Prev State  ||Receive      | Receive      | Prune-      | Expiry Timer|
|            ||Join(*,G)    | Prune(*,G)   | Pending     | Expires     |
|            ||             |              | Timer       |             |
|            ||             |              | Expires     |             |
+------------++-------------+--------------+-------------+-------------+
|            ||-> J state   | -            | -           | -           |
|NoInfo (NI) ||start Expiry |              |             |             |
|            ||Timer        |              |             |             |
+------------++-------------+--------------+-------------+-------------+
|            ||-> J state   | -> PP state  | -           | -> NI state |
|Join (J)    ||restart      | start Prune- |             |             |
|            ||Expiry Timer | Pending      |             |             |
|            ||             | Timer        |             |             |
+------------++-------------+--------------+-------------+-------------+
|Prune-      ||-> J state   |              | -> NI state | -> NI state |
|Pending (PP)||restart      |              | Send Prune- |             |
|            ||Expiry Timer |              | Echo(*,G)   |             |
+------------++-------------+--------------+-------------+-------------+

Notes:

In NoInfo state and in the Prune Pending state, upon receipt of the “Receive Prune(*,G)” event, there is an explicit state transition back to its own state. These seem redundant.
--VERIFIER NOTES--
It is perfectly possible to parse this with a basic knowledge of the protocol states and events.

Errata ID: 1125
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26

Section 4.5.7 says:

+----------------------------------------------------------------------+
|                         In Joined (J) State                          |
+-----------------+-----------------+-----------------+----------------+
| Timer Expires   | See Join(S,G)   | See Prune(S,G)  | See Prune      |
|                 | to RPF'(S,G)    | to RPF'(S,G)    | (S,G,rpt) to   |
|                 |                 |                 | RPF'(S,G)      |
+-----------------+-----------------+-----------------+----------------+
| Send            | Increase Join   | Decrease Join   | Decrease Join  |
| Join(S,G); Set  | Timer to        | Timer to        | Timer to       |
| Join Timer to   | t_joinsuppress  | t_override      | t_override     |
| t_periodic      |                 |                 |                |
+-----------------+-----------------+-----------------+----------------+

It should say:

+----------------------------------------------------------------------+
|                         In Joined (J) State                          |
+-----------------+-----------------+-----------------+----------------+
|  Event          | Timer Expires   | See Join(S,G)   | See Prune(S,G)  |
|                 |                 | to RPF'(S,G)    | to RPF'(S,G)    |
|                 |                 |                 |
+-----------------+-----------------+-----------------+----------------+
|  Action         | Send            | Increase Join   | Decrease Join   |
|                 | Join(S,G); Set  | Timer to        | Timer to        |
|                 | Join Timer to   | t_joinsuppress  | t_override      |
|                 | t_periodic      |                 |                 |
+-----------------+-----------------+-----------------+----------------+

Notes:

The remaining portions would be inserted into the left portion of the remaining table on Page 73 and the two overflowing items in that table would go into a continuation beneath the table on Page 73.
--VERIFIER NOTES--
It is perfectly possible to parse this with a basic knowledge of the protocol states and events.

Errata ID: 1132
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26

Section 4.9 says:

   All PIM control messages have IP protocol number 103.

It should say:

   All PIM control messages have IP protocol number 103, per RFC 1700.

Notes:

The IP protocol assignment information is given without a reference to RFC 1700/STD 2.
--VERIFIER NOTES--
Per RFC 3232, RFC 1700 is replaced by an online database. A reference is no longer appropriate.

Errata ID: 1148
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26

Section 4.2 says:

      # or Assert(*,G) message to be sent out interface iif.

It should say:

      # or Assert(*,G) message to be sent out iif.

Notes:

“should be sent out interface iif” is redundant as “iif” stands for “incoming interface” and this expands to: “should be sent out interface incoming interface”, which is redundant.
--VERIFIER NOTES--
In this case "iif" is the identifier of an interface. It reads better as it is.

Errata ID: 1153
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26

Section 4.5.1 says:

+------------++--------------------------------------------------------+
|            ||                          Event                         |
|            ++-------------+-------------+--------------+-------------+
|Prev State  ||Receive      | Receive     | Prune-       | Expiry Timer|
|            ||Join(*,*,RP) | Prune       | Pending      | Expires     |
|            ||             | (*,*,RP)    | Timer        |             |
|            ||             |             | Expires      |             |
+------------++-------------+-------------+--------------+-------------+
|            ||-> J state   | -> NI state | -            | -           |
|NoInfo (NI) ||start Expiry |             |              |             |
|            ||Timer        |             |              |             |
+------------++-------------+-------------+--------------+-------------+
|            ||-> J state   | -> PP state | -            | -> NI state |
|Join (J)    ||restart      | start Prune-|              |             |
|            ||Expiry Timer | Pending     |              |             |
|            ||             | Timer       |              |             |
+------------++-------------+-------------+--------------+-------------+
|Prune-      ||-> J state   | -> PP state | -> NI state  | -> NI state |
|Pending (PP)||restart      |             | Send Prune-  |             |
|            ||Expiry Timer |             | Echo(*,*,RP) |             |
+------------++-------------+-------------+--------------+-------------+

It should say:

+------------++--------------------------------------------------------+
|            ||                          Event                         |
|            ++-------------+-------------+--------------+-------------+
|Prev State  ||Receive      | Receive     | Prune-       | Expiry Timer|
|            ||Join(*,*,RP) | Prune       | Pending      | Expires     |
|            ||             | (*,*,RP)    | Timer        |             |
|            ||             |             | Expires      |             |
+------------++-------------+-------------+--------------+-------------+
|            ||-> J state   | -           | -            | -           |
|NoInfo (NI) ||start Expiry |             |              |             |
|            ||Timer        |             |              |             |
+------------++-------------+-------------+--------------+-------------+
|            ||-> J state   | -> PP state | -            | -> NI state |
|Join (J)    ||restart      | start Prune-|              |             |
|            ||Expiry Timer | Pending     |              |             |
|            ||             | Timer       |              |             |
+------------++-------------+-------------+--------------+-------------+
|Prune-      ||-> J state   | -           | -> NI state  | -> NI state |
|Pending (PP)||restart      |             | Send Prune-  |             |
|            ||Expiry Timer |             | Echo(*,*,RP) |             |
+------------++-------------+-------------+--------------+-------------+

Notes:

At the intersection of “NoInfo (NI)” and “ReceivePrune(*,*,RP)” it is noted that there is a change of state to “NI”, which is the current state – this is unnecessary. At the intersection of “PrunePending (PP)” and “ReceivePrune(*,*,RP)” it is noted that there is a change of state to “PP”, which is the current state – this is unnecessary.
--VERIFIER NOTES--
It is perfectly possible to parse this with a basic knowledge of the protocol states and events.

Errata ID: 1158
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26

Section 4.5.3 says:

+------------++--------------------------------------------------------+
|            ||                         Event                          |
|            ++-------------+--------------+-------------+-------------+
|Prev State  ||Receive      | Receive      | Prune-      | Expiry Timer|
|            ||Join(S,G)    | Prune(S,G)   | Pending     | Expires     |
|            ||             |              | Timer       |             |
|            ||             |              | Expires     |             |
+------------++-------------+--------------+-------------+-------------+
|            ||-> J state   | -> NI state  | -           | -           |
|NoInfo (NI) ||start Expiry |              |             |             |
|            ||Timer        |              |             |             |
+------------++-------------+--------------+-------------+-------------+
|            ||-> J state   | -> PP state  | -           | -> NI state |
|Join (J)    ||restart      | start Prune- |             |             |
|            ||Expiry Timer | Pending      |             |             |
|            ||             | Timer        |             |             |
+------------++-------------+--------------+-------------+-------------+
|Prune-      ||-> J state   | -> PP state  | -> NI state | -> NI state |
|Pending (PP)||restart      |              | Send Prune- |             |
|            ||Expiry Timer |              | Echo(S,G)   |             |
+------------++-------------+--------------+-------------+-------------+

It should say:

+------------++--------------------------------------------------------+
|            ||                         Event                          |
|            ++-------------+--------------+-------------+-------------+
|Prev State  ||Receive      | Receive      | Prune-      | Expiry Timer|
|            ||Join(S,G)    | Prune(S,G)   | Pending     | Expires     |
|            ||             |              | Timer       |             |
|            ||             |              | Expires     |             |
+------------++-------------+--------------+-------------+-------------+
|            ||-> J state   | -            | -           | -           |
|NoInfo (NI) ||start Expiry |              |             |             |
|            ||Timer        |              |             |             |
+------------++-------------+--------------+-------------+-------------+
|            ||-> J state   | -> PP state  | -           | -> NI state |
|Join (J)    ||restart      | start Prune- |             |             |
|            ||Expiry Timer | Pending      |             |             |
|            ||             | Timer        |             |             |
+------------++-------------+--------------+-------------+-------------+
|Prune-      ||-> J state   | -            | -> NI state | -> NI state |
|Pending (PP)||restart      |              | Send Prune- |             |
|            ||Expiry Timer |              | Echo(S,G)   |             |
+------------++-------------+--------------+-------------+-------------+

Notes:

At the intersection of “NoInfo (NI)” and “ReceivePrune(S,G)” it is noted that there is a change of state to “NI”, which is the current state – this is unnecessary. At the intersection of “PrunePending (PP)” and “ReceivePrune(S,G)” it is noted that there is a change of state to “PP”, which is the current state – this is unnecessary.
--VERIFIER NOTES--
It is perfectly possible to parse this with a basic knowledge of the protocol states and events.

Errata ID: 1171
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26

Section 4.5.9 says:

+----------------------------------------------------------------------+
|                    In NotPruned(S,G,rpt) State                       |
+----------+--------------+--------------+--------------+--------------+
|Override  | See Prune    | See Join     | See Prune    | RPF'         |
|Timer     | (S,G,rpt) to | (S,G,rpt) to | (S,G) to     | (S,G,rpt) -> |
|expires   | RPF'         | RPF'         | RPF'         | RPF' (*,G)   |
|          | (S,G,rpt)    | (S,G,rpt)    | (S,G,rpt)    |              |
+----------+--------------+--------------+--------------+--------------+
|Send Join | OT = min(OT, | Cancel OT    | OT = min(OT, | OT = min(OT, |
|(S,G,rpt);| t_override)  |              | t_override)  | t_override)  |
|Leave OT  |              |              |              |              |
|unset     |              |              |              |              |
+----------+--------------+--------------+--------------+--------------+

It should say:

See notes

Notes:

The table at the bottom of page 78 does not indicate what the rows are as opposed to the columns. It appears that the first row consists of events and the second row consists of actions to take upon receiving those events while in the “NotPruned(S,G,rpt) State”.
--VERIFIER NOTES--
It is perfectly possible to parse this with a basic knowledge of the protocol states and events.

Errata ID: 1173
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26

Section 4.6.4 says:

+----------------------------------------------------------------------+
|                         In NoInfo (NI) State                         |
+---------------+-------------------+------------------+---------------+
| Receive       |  Receive Assert   |  Data arrives    |  Receive      |
| Inferior      |  with RPTbit      |  from S to G on  |  Acceptable   |
| Assert with   |  set and          |  I and           |  Assert with  |
| RPTbit clear  |  CouldAssert      |  CouldAssert     |  RPTbit clear |
| and           |  (S,G,I)          |  (S,G,I)         |  and AssTrDes |
| CouldAssert   |                   |                  |  (S,G,I)      |
| (S,G,I)       |                   |                  |               |
+---------------+-------------------+------------------+---------------+
| -> W state    |  -> W state       |  -> W state      |  -> L state   |
| [Actions A1]  |  [Actions A1]     |  [Actions A1]    |  [Actions A6] |
+---------------+-------------------+------------------+---------------+

+----------------------------------------------------------------------+
|                   In I Am Assert Winner (W) State                    |
+----------------+------------------+-----------------+----------------+
| Assert Timer   |   Receive        |  Receive        |  CouldAssert   |
| Expires        |   Inferior       |  Preferred      |  (S,G,I) ->    |
|                |   Assert         |  Assert         |  FALSE         |
+----------------+------------------+-----------------+----------------+
| -> W state     |   -> W state     |  -> L state     |  -> NI state   |
| [Actions A3]   |   [Actions A3]   |  [Actions A2]   |  [Actions A4]  |
+----------------+------------------+-----------------+----------------+

It should say:

See notes.

Notes:

The tables at the bottom of page 84 do not indicate what the rows are as opposed to the columns. It appears that the first rows consist of events and the second rows consist of actions to take upon receiving those events while in the “NoInfo” state and “I AM Assert Winner” state.
--VERIFIER NOTES--
It is perfectly possible to parse this with a basic knowledge of the protocol states and events.

Errata ID: 1174
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26

Section 4.6.1 says:

+---------------------------------------------------------------------+
|                   In I Am Assert Loser (L) State                    |
+-------------+-------------+-------------+-------------+-------------+
|Receive      |Receive      |Receive      |Assert Timer |Current      |
|Preferred    |Acceptable   |Inferior     |Expires      |Winner's     |
|Assert       |Assert with  |Assert or    |             |GenID        |
|             |RPTbit clear |Assert       |             |Changes or   |
|             |from Current |Cancel from  |             |NLT Expires  |
|             |Winner       |Current      |             |             |
|             |             |Winner       |             |             |
+-------------+-------------+-------------+-------------+-------------+
|-> L state   |-> L state   |-> NI state  |-> NI state  |-> NI state  |
|[Actions A2] |[Actions A2] |[Actions A5] |[Actions A5] |[Actions A5] |
+-------------+-------------+-------------+-------------+-------------+

+----------------------------------------------------------------------+
|                    In I Am Assert Loser (L) State                    |
+----------------+-----------------+------------------+----------------+
| AssTrDes       |  my_metric ->   |  RPF_interface   |  Receive       |
| (S,G,I) ->     |  better than    |  (S) stops       |  Join(S,G) on  |
| FALSE          |  winner's       |  being I         |  interface I   |
|                |  metric         |                  |                |
+----------------+-----------------+------------------+----------------+
| -> NI state    |  -> NI state    |  -> NI state     |  -> NI State   |
| [Actions A5]   |  [Actions A5]   |  [Actions A5]    |  [Actions A5]  |
+----------------+-----------------+------------------+----------------+

It should say:

See notes.

Notes:

The table at the top of page 85 does not indicate what the rows are as opposed to the columns. It appears that the first row consists of events and the second row consists of actions to take upon receiving those events while in the “I Am Assert Loser” state.
--VERIFIER NOTES--
It is perfectly possible to parse this with a basic knowledge of the protocol states and events.

Errata ID: 1176
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26

Section 4.6.2 says:

+----------------------------------------------------------------------+
|                         In NoInfo (NI) State                         |
+-----------------------+-----------------------+----------------------+
| Receive Inferior      |  Data arrives for G   |  Receive Acceptable  |
| Assert with RPTbit    |  on I and             |  Assert with RPTbit  |
| set and               |  CouldAssert          |  set and AssTrDes    |
| CouldAssert(*,G,I)    |  (*,G,I)              |  (*,G,I)             |
+-----------------------+-----------------------+----------------------+
| -> W state            |  -> W state           |  -> L state          |
| [Actions A1]          |  [Actions A1]         |  [Actions A2]        |
+-----------------------+-----------------------+----------------------+

+---------------------------------------------------------------------+
|                    In I Am Assert Winner (W) State                  |
+----------------+-----------------+-----------------+----------------+
| Assert Timer   |  Receive        |  Receive        |  CouldAssert   |
| Expires        |  Inferior       |  Preferred      |  (*,G,I) ->    |
|                |  Assert         |  Assert         |  FALSE         |
+----------------+-----------------+-----------------+----------------+
| -> W state     |  -> W state     |  -> L state     |  -> NI state   |
| [Actions A3]   |  [Actions A3]   |  [Actions A2]   |  [Actions A4]  |
+----------------+-----------------+-----------------+----------------+

It should say:

See notes.

Notes:

The tables at the bottom of page 92 do not indicate what the rows are as opposed to the columns. It appears that the first rows consist of events and the second rows consist of actions to take upon receiving those events while in the “NoInfo” state and the “I Am Assert Winner” state.
--VERIFIER NOTES--
This is perfectly easy to parse having an understanding of the states and events for the protocol.

Errata ID: 1177
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26

Section 4.6.2 says:

+---------------------------------------------------------------------+
|                    In I Am Assert Loser (L) State                   |
+-------------+-------------+-------------+-------------+-------------+
|Receive      |Receive      |Receive      |Assert Timer |Current      |
|Preferred    |Acceptable   |Inferior     |Expires      |Winner's     |
|Assert with  |Assert from  |Assert or    |             |GenID        |
|RPTbit set   |Current      |Assert       |             |Changes or   |
|             |Winner with  |Cancel from  |             |NLT Expires  |
|             |RPTbit set   |Current      |             |             |
|             |             |Winner       |             |             |
+-------------+-------------+-------------+-------------+-------------+
|-> L state   |-> L state   |-> NI state  |-> NI state  |-> NI state  |
|[Actions A2] |[Actions A2] |[Actions A5] |[Actions A5] |[Actions A5] |
+-------------+-------------+-------------+-------------+-------------+

+----------------------------------------------------------------------+
|                    In I Am Assert Loser (L) State                    |
+----------------+----------------+-----------------+------------------+
| AssTrDes       | my_metric ->   |  RPF_interface  |  Receive         |
| (*,G,I) ->     | better than    |  (RP(G)) stops  |  Join(*,G) or    |
| FALSE          | Winner's       |  being I        |  Join            |
|                | metric         |                 |  (*,*,RP(G)) on  |
|                |                |                 |  Interface I     |
+----------------+----------------+-----------------+------------------+
| -> NI state    | -> NI state    |  -> NI state    |  -> NI State     |
| [Actions A5]   | [Actions A5]   |  [Actions A5]   |  [Actions A5]    |
+----------------+----------------+-----------------+------------------+

It should say:

See notes.

Notes:

The tables at the top of page 93 do not indicate what the rows are as opposed to the columns. It appears that the first rows consist of events and the second rows consist of actions to take upon receiving those events while in the “I Am Assert Loser” state.
--VERIFIER NOTES--
This is perfectly easy to parse having an understanding of the states and events for the protocol.

Errata ID: 1191
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26

Section 4.9.5.2 says:

  On a router with a large amount of multicast state,

It should say:

  On a router with a large amount of multicast states,

-or-

  On a router with a large amount of multicast state information,

-or-

  On a router with a large multicast state,

Notes:

Word choice.
--VERIFIER NOTES--
This is common usage.
"state information" might have been clearer, but "state" is acceptable.

RFC 4606, "Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", August 2006

Note: This RFC has been updated by RFC 6344

Source of RFC: ccamp (rtg)

Errata ID: 43
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Rejected by: Adrian Farrel
Date Rejected: 2011-05-08

 

(1)  use of "N"

In Section 2.1 of RFC 4606, on page 6, the explanations for
the NCC field contain the Note:

   Note 2: When a transparent STS-N/STM-N signal is requested that is
   limited to a single contiguously concatenated STS-Nc_SPE/VC-4-Nc, the
   signal type must be STS-N/STM-N, RCC with flag 1, NCC set to 1.

Such text (and similar) contains an unfortunate mess-up of two
distinct uses of "N", with different range of admissible values
for STS-N and STM-N.
This becomes particularly confusing in phrases like
"a single contiguously concatenated STS-Nc_SPE/VC-4-Nc".
I strongly recommend to avoid this overloaded use of "N"
in a single context.
Using "M" for one of these two "N"s instead, i.e. talking
about "STS-M/STM-N", or talking about "STS-<3*N>/STM-N" or
even "STS-3N/STM-N", would remove the ambiguity and add to
the clarity of the text.


(3)  continuation of (1)

Within section 3, the numbered rules on mid-page 13 would also
benefit from application of the arguments given in item (1) above:

   1.  S=1->N is the index of a particular STS-3/AUG-1 inside an
       STS-N/STM-N multiplex.  S is only significant for SONET STS-N
       (N>1) and SDH STM-N (N>0).  S must be 0 and ignored for STS-1 and
       STM-0.

should better be specified as:

   1.  S=1->N is the index of a particular STS-3/AUG-1 inside an
|      STS-3N/STM-N multiplex.
|      S is only significant for SONET STS-3N and SDH STM-N (N>0).
       S must be 0 and ignored for STS-1 and STM-0.

and

   2.  U=1->3 is the index of a particular STS-1_SPE/VC-3 within an
       STS-3/AUG-1.  U is only significant for SONET STS-N (N>1) and SDH
       STM-N (N>0).  U must be 0 and ignored for STS-1 and STM-0.

should better be specified as:

   2.  U=1->3 is the index of a particular STS-1_SPE/VC-3 within an
       STS-3/AUG-1.
|      U is only significant for SONET STS-3N and SDH STM-N (N>0).
       U must be 0 and ignored for STS-1 and STM-0.

Notes:

Erratum 43 has been duplicated to allow separate treatment of the different elements reported. This copy is used to address the rejected parts. The rest of the Erratum is now 2804.
--VERIFIER NOTES--
Points 1) and 3) are rejected. Although the repeated use of "N" could lead a reader to be confused, this is common usage amongst writers on TDM, and the readership within CCAMP has so far been unconfused.

RFC 4607, "Source-Specific Multicast for IP", August 2006

Source of RFC: ssm (rtg)

Errata ID: 905
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-08
Rejected by: Adrian Farrel
Date Rejected: 2013-09-18

 

problems with IPv6 SSM address range, and with related text

The 4th paragraph of Section 1, on page 3, RFC 4607 says:

   Addresses in the range FF3x::4000:0001 through FF3x::7FFF:FFFF are
   reserved in [IPv6-MALLOC] for allocation by IANA.  Addresses in the
   range FF3x::8000:0000 through FF3x::FFFF:FFFF are allowed for dynamic
   allocation by a host, as described in [IPv6-MALLOC].  Addresses in
   the range FF3x::0000:0000 through FF3x::3FFF:FFFF are invalid IPv6
   SSM addresses.  ([IPv6-MALLOC] indicates that FF3x::0000:0001 to
   FF3x::3FFF:FFFF must set P=0 and T=0, but for SSM, [IPv6-UBM]
   mandates that  P=1 and T=1, hence their designation as invalid.)  ...

I see a lot of problems in that reasoning.

a) The most obvious issue first:
As far as I can see, RFC 3307 [IPv6-MALLOC] only requires for
"Permanent IPv6 Multicast Addresses":

   Multicast addresses assigned by IANA MUST have the T bit set to 0 and
   the P bit set to 0.

(RFC 3307, Section 4, top of page 4)

This restriction is not mentioned for other cases.

Since the '3' nibbles in "FF3x::0000:0000 through FF3x::3FFF:FFFF"
just mean P=1 and T=1 (cf. RFC 3306 [IPv6-UBM], Section 4, pp. 2/3),
IMHO the phrase from the above quotation,
                  [IPv6-MALLOC] indicates that FF3x::0000:0001 to
   FF3x::3FFF:FFFF must set P=0 and T=0,
is neither logical nor conclusive.  Hence the final conclusion,
                   "hence their designation as invalid."
does not hold.

Perhaps it would have been much more simple and clear to just
declare the range FF3x::0000:0000 through FF3x::3FFF:FFFF as
reserved or invalid -- without giving any reason.

b) Delving into further details of RFC 3307, one can find that
Section 4.2 reserves the range 0x40000000 to 0x7FFFFFFF for
"Permanent IPv6 Multicast Group Identifiers" with the intent that
assignments in that range hold
   "regardless of the upper 96 bits of the multicast address".

On the other hand, the current IPv6 Addressing Architecture document
clearly states that
   T=0 means  "well known" / "permanently-assiged" / IANA allocated,
while
   T=1 means  "transient" / "dynamically allocated".
Under this rule, the above "regardless" in RFC 3307 is partially
invalid, because upper 96 bits containing T=1 are not allowed for
IANA allocated MC addresses.

[Note: Perhaps, this statement is also inappropriate, because
 RFC 3307 initially states (in Section 4, at the bottom of page 3):
   ....  The following guidelines assume that the prefix of the
   multicast address has been initialized according to [ADDRARCH] or
   [UNIMCAST].
 and both specifications quoted restrict or fix the values of some
 of these upper 96 bits ...]

Hence, there is a subtle conflict between RFC 3307 and RFC 4291 !

c) Taking the ADDRARCH and RFC 3307 rules together, it is clear
that the first sentence of the RFC 4607 quotation above,
   Addresses in the range FF3x::4000:0001 through FF3x::7FFF:FFFF are
   reserved in [IPv6-MALLOC] for allocation by IANA.
does not hold, as T=1 in these addresses !

Later on, in Section 9 (IANA Cosiderations, page 15), RFC 4607 says:

   IANA allocates IPv4 addresses in the range 232.0.0.1 through
   232.0.0.255 and IPv6 addresses in the range FF3x:4000:0001 to
   FF3x::7FFF:FFFF.  [...]

The latter clearly contradicts RFC 4291 for this reason (T=1).

Therefore, this range might better have been reserved/forbidden,
or excluded from the IPv6 SSM address range.


Taking all together:
There are serious conflicts between RFC 4291, RFC 3307, and RFC 4607.

Sadly enough, it seems that it was not a good idea to assign
FF3x::/32 for IPv6 SSM.

I'm sure that RFC 4291 should NOT be called in question.

Perhaps, it would have been better to restrict the IPv6 SSM range to
FF3x::8000:0000/31, and *not* provide for any subrange available
for specific IANA assignments.
Then, should there really arise the serious need for IANA allocated,
specific IPv6 SSM addresses, another (small) range (with T=0 and P=0)
could be assigned additionally for this purpose.

[Note 1: Thus, this address range would indeed fall under the regime
 of Section 4.1 of RFC 3307, "Permanent IPv6 Multicast Addresses".
 Note 2: T=0 + P=1 would necessitate a formal update to RFC 3306 that
 does not allow this combination, and maybe to RFC 3956 as well.]

Notes:

from pending
--VERIFIER NOTES--
This Errata Report is rejected because it constitutes a significant technical change to the specification. This rejection makes no judgement about whether the issues raised are right or wrong.

In considering the issues raised in this Errata Report readers are also invited to consider draft-ietf-6man-multicast-addr-arch-update that may be related work.

Errata ID: 904
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-08
Rejected by: Adrian Farrel
Date Rejected: 2011-05-08

Section 16 says:

   [RFC3513]     Hinden, R. and S. Deering, "Internet Protocol Version 6
                 (IPv6) Addressing Architecture", RFC 3513, April 2003.

It should say:

   [RFC4291]    Hinden, R. and S. Deering, "IP Version 6 Addressing 
                Architecture", RFC 4291, February 2006.

Notes:

Unfortunately, Section 1 (first paragraph) and Section 11
of RFC 4607 refer to the previous IPv6 Address Architecture
document, RFC 3513, that has been superseded by RFC 4291 (February 2006).

from pending
--VERIFIER NOTES--
At the time of document approval for 4607, 4291 had not been published and the authors needed to make a normative reference to an RFC and not to an I-D.

However, this is not an issue because anyone tracking the reference to 3513 will find that it has been obsoleted by 4291 and will read the correct document.

RFC 4627, "The application/json Media Type for JavaScript Object Notation (JSON)", July 2006

Note: This RFC has been obsoleted by RFC 7159

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 3159
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: James S. Chi
Date Reported: 2012-03-20
Rejected by: Peter Saint-Andre
Date Rejected: 2012-03-22

Section 2.5 says:

         string = quotation-mark *char quotation-mark

         char = unescaped /
                escape (
                    %x22 /          ; "    quotation mark  U+0022
                    %x5C /          ; \    reverse solidus U+005C
                    %x2F /          ; /    solidus         U+002F
                    %x62 /          ; b    backspace       U+0008
                    %x66 /          ; f    form feed       U+000C
                    %x6E /          ; n    line feed       U+000A
                    %x72 /          ; r    carriage return U+000D
                    %x74 /          ; t    tab             U+0009
                    %x75 4HEXDIG )  ; uXXXX                U+XXXX

         escape = %x5C              ; \

         quotation-mark = %x22      ; "

         unescaped = %x20-21 / %x23-5B / %x5D-10FFFF

It should say:

         string = quotation-mark *char quotation-mark

         char = unescaped /
                escape (
                    %x22 /          ; "    quotation mark  U+0022
                    %x5C /          ; \    reverse solidus U+005C
                    %x62 /          ; b    backspace       U+0008
                    %x66 /          ; f    form feed       U+000C
                    %x6E /          ; n    line feed       U+000A
                    %x72 /          ; r    carriage return U+000D
                    %x74 /          ; t    tab             U+0009
                    %x75 4HEXDIG )  ; uXXXX                U+XXXX

         escape = %x5C              ; \

         quotation-mark = %x22      ; "

         unescaped = %x20-21 / %x23-5B / %x5D-10FFFF

Notes:

There is a contradiction regarding solidus(/, %2F) character - it belongs to both escaped character and unescaped character. To solve this,delete following line:

%x2F / ; / solidus U+002F

The reason it should belong to unescaped character is clear. There's no gain by escape it.

The author has replied as follows:

There is no problem here. There is no requirement that there be a single encoding for each codepoint. "/" and "\/" are both allowed and both produce the same result. The second form was [provided] to allow insertion into HTML, where "</script>" interacts badly, but "<\/script>" does not.

Therefore, this report is rejected.
--VERIFIER NOTES--

RFC 4631, "Link Management Protocol (LMP) Management Information Base (MIB)", September 2006

Source of RFC: ccamp (rtg)

Errata ID: 825
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-06
Rejected by: Adrian Farrel

 

(1) [[posted separately.]]

(2)  [plaintext flaw]

In the second paragraph of Section 8, near the bottom of page 9,
RFC 4631 says:

                        [...].  The interrelation of entries in the
   ifTable is defined by Interfaces Stack Group defined in [RFC2863].

It should say:

                        [...].  The interrelation of entries in the
|  ifTable is defined by the Interfaces Stack Group defined in
   [RFC2863].
                        ^^^^^


(2') [punctuation] -- legacy, but not reported for RFC 4327

Conformant to the punctuation newly introduced in the REFERENCE
clauses, parts of the DESCRIPTION subclauses of the MODULE-IDENTITY
macro invocation should also be amended with a trailing full-stop:

On top of page 13, change:

        This revision published as RFC 4631"
   REVISION
       "200601110000Z"  -- 11 January 2006
   DESCRIPTION
       "Initial version published as RFC 4327"
   ::= { transmission 227 }

to say:

|       This revision published as RFC 4631."
   REVISION
       "200601110000Z"  -- 11 January 2006
   DESCRIPTION
|      "Initial version published as RFC 4327."
   ::= { transmission 227 }


(3)  LmpInterval TEXTUAL-CONVENTION  (page 13)

The clause,

   DESCRIPTION
       "The interval delay in milliseconds."

perhaps should better say:

   DESCRIPTION
|      "The delay interval in milliseconds."

or even:

   DESCRIPTION
|      "The interval period for a periodically performed LMP operation,
|       in milliseconds."

[Rationale: It's not the interval that's getting delayed ...]


(4)  LmpRetransmitInterval TEXTUAL-CONVENTION  (page 13)

The clause,

   DESCRIPTION
       "The retransmission interval delay in milliseconds."

perhaps should better say:

   DESCRIPTION
|      "The retransmission delay interval in milliseconds."

or even better:

   DESCRIPTION
|      "The (initial) retransmission interval in milliseconds."

[Rationale: It's not the interval that's getting delayed ...]


(old #5)  lmpNbrRetransmitInterval OBJECT-TYPE  (page 15)  -- resolved

(new #5)  lmpNbrRetransmitInterval OBJECT-TYPE  (page 15)
          -- legacy, but originally not reported

There's an extraneous blank line in the middle of the REFERENCE clause
that should be deleted (cf. lmpNbrRetryLimit OBJECT-TYPE, below).


(old #6)  lmpNbrRetryLimit OBJECT-TYPE  (page 15)  -- resolved

(new #6)  lmpCcUnderlyingIfIndex and lmpCcIsIf OBJECT-TYPEs  (page 20)
          -- newly introduced

The punctuation within the DESCRIPTION clauses for these objects
has been changed using one semicolon each.
IMHO, this is unfortunate because it might be misinterpreted as
excluding the subsequent half-sentences from the initial "If"
condition in these sentences that in fact are also preconditions
for the statements now after the semicolons.


(7)  lmpCcRemoteAddressType OBJECT-TYPE  (page 21)

   DESCRIPTION
       "This value represents the remote control channel IP address
        type.  In point-to-point configuration, this value can be set
        to unknown(0)."
   ::= { lmpControlChannelEntry 6 }

should better say:

   DESCRIPTION
       "This value represents the remote control channel IP address
|       type.  In point-to-point configurations, this value can be set
        to unknown(0)."
   ::= { lmpControlChannelEntry 6 }
                                              ^

[ The possible alternative, "In a point-to-point configuration, ..."
  is not proposed here, to maintain a style similar to the minimal
  change for the next object -- see (8) below.]


(8)  lmpCcRemoteIpAddr OBJECT-TYPE  (page 21) -- partially resolved

   DESCRIPTION
       "[...]
        The Control channel must be numbered on non-point-to-point
        configuration.  For point-to-point configuration, the
        remote control channel address can be of type unknown
        in which case this object must be a zero-length string.  The
        lmpCcRemoteId object then identifies the unnumbered
        address."
   ::= { lmpControlChannelEntry 7 }

should better say:

   DESCRIPTION
       "[...]
        The control channel must be numbered on non-point-to-point
|       configurations.  For point-to-point configurations, the
        remote control channel address can be of type unknown
        in which case this object must be a zero-length string.  The
        lmpCcRemoteId object then identifies the unnumbered
        address."
   ::= { lmpControlChannelEntry 7 }


(9)  lmpCcHelloInterval OBJECT-TYPE  (page 22)

An established 'default' specifies the value of a (newly created)
tabular object to be used when this object is not SET explicitely.
The default is never 'set', it is defined in the specification.
Hence,

   DESCRIPTION
       "This object specifies the value of the HelloInterval
        parameter.  The default value for this object should be
        set to lmpCcHelloIntervalDefault."
   ::= { lmpControlChannelEntry 10 }

should better say:

   DESCRIPTION
       "This object specifies the value of the HelloInterval
|       parameter.  The default value to be used for this object
|       is lmpCcHelloIntervalDefault."
   ::= { lmpControlChannelEntry 10 }


(9')   lmpCcHelloIntervalMin OBJECT-TYPE  (page 22) ,
(9'')  lmpCcHelloIntervalMax OBJECT-TYPE  (page 22) ,
(10)   lmpCcHelloDeadInterval OBJECT-TYPE  (page 23) ,
(10')  lmpCcHelloDeadIntervalMin OBJECT-TYPE  (page 23) , and
(10'') lmpCcHelloDeadIntervalMax OBJECT-TYPE  (page 23)

The change from item (9) above should be applied there similarly:

Replace the phrase,

           "[...].  The default value for this object should be
        set to lmp<*>Default."

by:

|          "[...].  The default value to be used for this object
|       is lmp<*>Default."

using, at all instances, the appropriate value for the placeholder <*>.


(11)  lmpControlChannelPerfEntry OBJECT-TYPE  (page 25)

   DESCRIPTION
       "An entry in this table is created by a LMP-enabled device for
        every control channel.  lmpCcCounterDiscontinuityTime is used
        to indicate potential discontinuity for all counter objects
        in this table."

The latter is not true.
In this MIB module, the discontinuity is monitored per table *entry*
(conceptual row), not for the table as a whole -- see the DESCRIPTIONs
for lmp<*>DiscontinuityTime later in the RFC.

Therefore, the above clause should say:

   DESCRIPTION
       "An entry in this table is created by a LMP-enabled device for
        every control channel.  lmpCcCounterDiscontinuityTime is used
        to indicate potential discontinuity for all counter objects
|       in this entry (conceptual row)."


(12)  lmpCcChannelStatusAckSent OBJECT-TYPE  (page 35)

The clause,

   DESCRIPTION
       "This object counts the number of ChannelStatus messages
        that have been sent on this control channel."
   ::= { lmpControlChannelPerfEntry 47 }

refers to the wrong message type; it should say:

   DESCRIPTION
|      "This object counts the number of ChannelStatusAck messages
        that have been sent on this control channel."
   ::= { lmpControlChannelPerfEntry 47 }


(13)  lmpTeLinkEntry OBJECT-TYPE  (page 37)

The DESCRIPTION clause contains the sentence:

                                                      [...].  The
        administrative status value is controlled from the ifEntry.
        [...]

This sentence should say:

                                                      [...].  The
|       administrative status is controlled from the ifEntry.
        [...]


(13') lmpLinkVerifyTransportMechanism OBJECT-TYPE  (page 41)  -- new

Missing punctution between the two parts of the REFERENCE clause:

   REFERENCE
       "Link Management Protocol, RFC 4204
        Synchronous Optical Network (SONET)/Synchronous Digital
        Hierarchy (SDH) Encoding for Link Management Protocol (LMP)
        Test Messages, RFC 4207."

should say:

   REFERENCE
       "Link Management Protocol, RFC 4204.
        Synchronous Optical Network (SONET)/Synchronous Digital
        Hierarchy (SDH) Encoding for Link Management Protocol (LMP)
        Test Messages, RFC 4207."

[... or use a semicolon after "RFC 4204".]
[Note: This item not reported for RFC 4327 -- there was a page
 break effectively hiding the issue.]


(14)  lmpTeLinkPerfEntry OBJECT-TYPE  (page 43)

The correction from item (11) above is to be applied here as well:

Replace:

   DESCRIPTION
       "An entry in this table is created by an LMP-enabled device for
        every TE link.  lmpTeCounterDiscontinuityTime is used
        to indicate potential discontinuity for all counter objects
        in this table."

by:

   DESCRIPTION
       "An entry in this table is created by an LMP-enabled device for
        every TE link.  lmpTeCounterDiscontinuityTime is used
        to indicate potential discontinuity for all counter objects
|       in this entry (conceptual row)."


(15)  lmpTeEndVerifyRetransmit OBJECT-TYPE  (page 46)
      -- rationale given now extended

   DESCRIPTION
       "This object counts the number of EndVerify messages that
        have been retransmitted over this control channel."
   ::= { lmpTeLinkPerfEntry 12 }

is inappropriate -- it does not match the indexing structure of the
LMP TE Link Performance Table.  In accordance with the text supplied
for the other objects in this Table, it should say:

   DESCRIPTION
       "This object counts the number of EndVerify messages that
|       have been retransmitted for this TE link."
   ::= { lmpTeLinkPerfEntry 12 }


(16)  lmpTeTestStatusFailureRetransmit OBJECT-TYPE  (page 48)

   DESCRIPTION
       "This object counts the number of TestStatusFailure messages
        that have been retransmitted on this TE link."
   ::= { lmpTeLinkPerfEntry 20 }

should say:

   DESCRIPTION
       "This object counts the number of TestStatusFailure messages
        that have been retransmitted for this TE link."
   ::= { lmpTeLinkPerfEntry 20 }

[ According to Section 12.5.8. of the LMP specification [RFC 4204],
  LMP TestStatusFailure messages are transmitted over the control
  channel; hence, "retransmitted *on* this TE Link" is wrong! ]


(17)  lmpTeLinkSummaryRetransmit OBJECT-TYPE  (page 49)

The correction from item (15) above is to be applied here as well:

Replace:

   DESCRIPTION
       "This object counts the number of LinkSummary messages that
        have been retransmitted over this control channel."
   ::= { lmpTeLinkPerfEntry 25 }

by:

   DESCRIPTION
       "This object counts the number of LinkSummary messages that
|       have been retransmitted for this TE link."
   ::= { lmpTeLinkPerfEntry 25 }


(18)  lmpTeChannelStatusAckSent OBJECT-TYPE  (page 50)

The correction from item (12) above is to be applied here as well:

Replace:

   DESCRIPTION
       "This object counts the number of ChannelStatus messages
        that have been sent for this TE link."
   ::= { lmpTeLinkPerfEntry 34 }

by:

   DESCRIPTION
|      "This object counts the number of ChannelStatusAck messages
        that have been sent for this TE link."
   ::= { lmpTeLinkPerfEntry 34 }


(19)  lmpDataLinkEntry OBJECT-TYPE  (page 52)

The correction from item (13) above is to be applied here as well:

The sentence in the DESCRIPTION clause,

                   [...].  The administrative status value is
        controlled from the ifEntry.  [...]

should say:

|                  [...].  The administrative status is controlled
        from the ifEntry.  [...]


(20)  lmpDataLinkPerfEntry OBJECT-TYPE  (page 56)

The correction from item (11) above is to be applied here as well:

Replace:

   DESCRIPTION
       "An entry in this table contains information about
        the LMP performance counters for the data-bearing links.
        lmpDataLinkDiscontinuityTime is used to indicate potential
        discontinuity for all counter objects in this table."

by:

   DESCRIPTION
       "An entry in this table contains information about
        the LMP performance counters for the data-bearing links.
        lmpDataLinkDiscontinuityTime is used to indicate potential
|       discontinuity for all counter objects in this entry."


(21a) lmpNotificationMaxRate OBJECT-TYPE  (page 58)
      -- item was numbered (21) previously; recent punctuation
         updates now incorporated in text below

The DESCRIPTION text (near the end of its 2nd paragraph, ff.) says:

                        [...].  For instance, a network of 100 nodes
        with 5 links of 128 wavelengths each and a link verification
        of 1 minute, with no more than 10% of the links failed at any
        given time, would have 1 notification per second sent from
        each node, or 100 notifications per second for the whole
        network.  The rest of the notifications are negligible
        compared to this number.

        To alleviate the congestion problem, the
        lmpNotificationMaxRate object can be used to implement a
        throttling mechanism.  It is also possible to enable/disable
        certain type of notifications.

It should say, correcting two flaws (line breaks adjusted):

                        [...].  For instance, a network of 100 nodes
        with 5 links of 128 wavelengths each and a link verification
|       interval of 1 minute, with no more than 10% of the links failed
        at any given time, would have 1 notification per second sent
        from each node, or 100 notifications per second for the whole
        network.  The rest of the notifications are negligible
        compared to this number.

        To alleviate the congestion problem, the
        lmpNotificationMaxRate object can be used to implement a
        throttling mechanism.  It is also possible to enable/disable
|       certain types of notifications.


(21b) lmpUnprotected NOTIFICATION-TYPE  (page 61)  -- newly introduced

In the DESCRIPTION clause,

                             [...].  If the remaining operational
        control channel fails, then there will be no more control
        channels between the pair of nodes and all the TE links
|       between the pair of nodes, will go to degraded state.  [...]
                                 ^

the newly added comma makes no sense, it separates the noun from the
verb after 'and'; this sentence should say:

                             [...].  If the remaining operational
        control channel fails, then there will be no more control
        channels between the pair of nodes and all the TE links
|       between the pair of nodes will go to degraded state.  [...]

Perhaps, a comma migth instead be inserted before the 'and':

                             [...].  If the remaining operational
        control channel fails, then there will be no more control
|       channels between the pair of nodes, and all the TE links
|       between the pair of nodes will go to degraded state.  [...]


(21c) lmpModuleReadOnlyCompliance MODULE-COMPLIANCE, restriction
      clause for (lmpDataLinkTable) OBJECT lmpDataLinkIPAddr  (page 71)

      DESCRIPTION
          "The size of the data-bearing link IP address depends on
           the type of data-bearing link.  Data-bearing link IP
           address size is zero if the link is unnumbered, four if
           the link IP address is IPv4, and sixteen if the link IP
           address is IPv6."

should better say:

      DESCRIPTION
          "The size of the data-bearing link IP address depends on
|          the type of data-bearing link.  The data-bearing link IP
           address size is zero if the link is unnumbered, four if
           the link IP address is IPv4, and sixteen if the link IP
           address is IPv6."


(22)  lmpNodeGroup OBJECT-GROUP  (page 72)

The RFC says:

   DESCRIPTION
          "Collection of objects that represent LMP node
           configuration."
   ::= { lmpGroups 1 }

It should say:

   DESCRIPTION
|         "Collection of objects that represents the LMP node
           configuration."
   ::= { lmpGroups 1 }

[ In fact, it is *the collection* (singular) that represents
  the node configuration! ]


(23)  lmpControlChannelGroup OBJECT-GROUP  (page 72/73)

On mid-pge 73, the RFC says:

   DESCRIPTION
          "Objects that can be used to configure LMP interface."

It should say:

   DESCRIPTION
|         "Objects that can be used to configure LMP interfaces."


(24)  lmpDataLinkGroup OBJECT-GROUP  (page 77)

Similar to item (22) above, the clause,

   DESCRIPTION
          "Collection of objects that represent data-bearing link
           configuration."
   ::= { lmpGroups 9 }

should better say:

   DESCRIPTION
          "Collection of objects that represents data-bearing link
           configurations."
   ::= { lmpGroups 9 }

Notes:

Some of the errata listed above correspond to errata also reported for RFC 4327 (referred to as "old").

from pending

--VERIFIER COMMENT--
While many of these comments would undoubtedly have led to a more polished
final RFC it is fortunate that none of them makes the document in any way
harder to read or less technically meaningful. I am sure that if and when
the RFC progresses from Proposed Standard to Draft Standard we can look back
at this list to ensure that your comments are addressed.

In future, however, I would urge you to make comments on the content and
format of CCAMP documents as they progress through the working group or
during IETF last call. Comments made later than that are very unlikely to be
considered by the authors for inclusion, but comments made earlier in the
process are very likely to be included.

Obviously, if issues of technical clarity or understanding do come up later
than this, we can address them through Errata while a new revision of the
RFC is prepared. On the other hand, Errata are probably not well used for
recording small format errors in the text as these are not strictly errors
of content or substance.

Errata ID: 39
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-06
Rejected by: Adrian Farrel
Date Rejected: 2007-02-24

Section 7 says:

      In lmpDataLinkTable:
   {

It should say:

   In lmpDataLinkTable:
   {

Notes:

spurious indentation

from pending

--VERIFIER COMMENT--
While many of these comments would undoubtedly have led to a more polished
final RFC it is fortunate that none of them makes the document in any way
harder to read or less technically meaningful. I am sure that if and when
the RFC progresses from Proposed Standard to Draft Standard we can look back
at this list to ensure that your comments are addressed.

In future, however, I would urge you to make comments on the content and
format of CCAMP documents as they progress through the working group or
during IETF last call. Comments made later than that are very unlikely to be
considered by the authors for inclusion, but comments made earlier in the
process are very likely to be included.

Obviously, if issues of technical clarity or understanding do come up later
than this, we can address them through Errata while a new revision of the
RFC is prepared. On the other hand, Errata are probably not well used for
recording small format errors in the text as these are not strictly errors
of content or substance.

RFC 4632, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", August 2006

Source of RFC: grow (ops)

Errata ID: 38
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Rejected by: Tony Li
Date Rejected: 2006-11-01

Section 2 says:

   3.  Eventual exhaustion of the 32-bit IPv4 address space.

       It was clear that then-current rates of Internet growth would
       cause the first two problems to become critical sometime between
       1993 and 1995.  Work already in progress on topological
       assignment of addressing for Connectionless Network Service
       (CLNS), which was presented to the community at the Boulder IETF
       in December of 1990, led to thoughts on how to re-structure the
       32-bit IPv4 address space to increase its lifespan.  Work in the
       ROAD group followed and eventually resulted in the publication of
       [RFC1338], and later, [RFC1519].

       The design and deployment of CIDR was intended to solve these
       problems by providing a mechanism to slow the growth of global
       routing tables and to reduce the rate of consumption of IPv4
       address space.  It did not and does not attempt to solve the
       third problem, which is of a more long-term nature; instead, it
       endeavors to ease enough of the short- to mid-term difficulties
       to allow the Internet to continue to function efficiently while
       progress is made on a longer-term solution.

       More historical background on this effort and on the ROAD group
       may be found in [RFC1380] and at [LWRD].

3.  Classless Addressing as a Solution

It should say:

   3.  Eventual exhaustion of the 32-bit IPv4 address space.

   It was clear that then-current rates of Internet growth would
   cause the first two problems to become critical sometime between
   1993 and 1995.  Work already in progress on topological
   assignment of addressing for Connectionless Network Service
   (CLNS), which was presented to the community at the Boulder IETF
   in December of 1990, led to thoughts on how to re-structure the
   32-bit IPv4 address space to increase its lifespan.  Work in the
   ROAD group followed and eventually resulted in the publication of
   [RFC1338], and later, [RFC1519].

   The design and deployment of CIDR was intended to solve these
   problems by providing a mechanism to slow the growth of global
   routing tables and to reduce the rate of consumption of IPv4
   address space.  It did not and does not attempt to solve the
   third problem, which is of a more long-term nature; instead, it
   endeavors to ease enough of the short- to mid-term difficulties
   to allow the Internet to continue to function efficiently while
   progress is made on a longer-term solution.

   More historical background on this effort and on the ROAD group
   may be found in [RFC1380] and at [LWRD].

3.  Classless Addressing as a Solution

Notes:

In Section 2, on page 4 of RFC 4632, the text after the
enumerated item '3.' up to the end of the section is indented
too much (by 4 columns), making it erroneously appear to belong
to that item '3.'

--VERIFIER COMMENT--
Thank you very much for your eagle eyes and your comments. I agree
with all of them. If you had submitted them during the Internet-draft
process, I would make all of these modifications immediately.
However, now that the RFC is issued, I believe that we should be quite
a bit more conservative before issuing Errata, so as to not congest
the Errata and obscure vital and substantive changes that might affect
actual interoperability of standards interpretation. With that view
in mind, I'd like to suggest that we not issue any Errata at this
time. I look forward to your input on subsequent draft documents.

Errata ID: 799
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Rejected by: Tony Li
Date Rejected: 2006-11-01

 

(1) [[posted separately.]]

(2)  typo (word replication)

In the second paragraph of Section 5.2, at the bottom of page 12,
RFC 4632 says:

                                             [...].  If the "child"
   network were to lose internal connectivity to 192.168.65.0/24 (which
|  is part of its aggregate), traffic from the "parent" to the to the
   "child" destined for 192.168.65.1 will follow the "child's"
   advertised route.  [...]
                                                        ^^^^^^^^^^^^^
It should say:

                                             [...].  If the "child"
   network were to lose internal connectivity to 192.168.65.0/24 (which
|  is part of its aggregate), traffic from the "parent" to the "child"
   destined for 192.168.65.1 will follow the "child's" advertised route.
   [...]


(3)  garbled sentence

The second paragraph of Section 7, on page 18, says:

   A description of techniques to populate the IN-ADDR.ARPA zone when
   and used address that blocks that do not align to octet boundaries is
   described in [RFC2317].

Apparently, this sentence is garbled; as written, it makes no sense.
Perhaps, it was intended to say:

   A description of techniques to populate the IN-ADDR.ARPA zone when
|  used address blocks do not align to octet boundaries is described in
   [RFC2317].


(4)  typo (singular/plural mismatch)

On page 19, the second enumerated bullet in Section 9 says:

   2.  Acceleration of the exponential trend in late 1993 and early 1994
       as CIDR "supernet" blocks were first assigned by the NIC and
       routed as separate legacy class-C networks by service provider.

It should say:

   2.  Acceleration of the exponential trend in late 1993 and early 1994
       as CIDR "supernet" blocks were first assigned by the NIC and
|      routed as separate legacy class-C networks by service providers.
                                                                     ^


(5)  incomplete status change of legacy documents

Section 11 (pp. 21/22) re-classifies a couple of legacy RFCs as
Historic.
Unfortunately, there are additional documents closely related to
these re-classified documents left alone -- and apparently still
current.
IMHO, it would have been much clearer to also re-classify RFC 1797
and RFC 1879 as Historic, as well.

Note:
Admittedly, there may be a gap in the IETF document maintenance
procedures not formally allowing Informational and Experimental
RFCs to be re-classified as Historic.  If this was the reason for
omitting the named RFCs from Section 11 of RFC 4632, it would
perhaps have been useful to "obsolete" these RFCs by RFC 4632.
This situation is bound to recur with more Informational RFCs
published as companion documents to Standards Track RFCs;
thus, a general procedural solution should be sought to visibly
(in the RFC index) 'outdate' such RFCs when updates get published.

Notes:

from pending

--VERIFIER COMMENT--
Thank you very much for your eagle eyes and your comments. I agree
with all of them. If you had submitted them during the Internet-draft
process, I would make all of these modifications immediately.
However, now that the RFC is issued, I believe that we should be quite
a bit more conservative before issuing Errata, so as to not congest
the Errata and obscure vital and substantive changes that might affect
actual interoperability of standards interpretation. With that view
in mind, I'd like to suggest that we not issue any Errata at this
time. I look forward to your input on subsequent draft documents.

RFC 4659, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", September 2006

Source of RFC: l3vpn (int)

Errata ID: 4087
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Wesley George
Date Reported: 2014-08-18
Rejected by: Adrian Farrel
Date Rejected: 2014-11-20

Throughout the document, when it says:

No "updates" metadata reference to update RFC4364

It should say:

This document updates RFC4364 (and associated metadata links)

Notes:

RFC4659 provides an extension to the standard defined in RFC4364 to add IPv6 support to a standard that was originally IPv4-only. This metadata link will make it clearer for implementers that both standards are necessary for a full implementation.
--VERIFIER NOTES--
Considering the definition of "updates", the normal terms of an errata report, and the discussion on the Bess mailing list I am rejecting this.

This should not be construed as meaning that IPv6 support is not critically important: BGP/MPLS VPNs should, of course, be fully functional in IPv6 networks.

RFC 4666, "Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)", September 2006

Source of RFC: sigtran (rai)

Errata ID: 2518
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Suyash Karmarkar
Date Reported: 2010-09-14
Rejected by: Robert Sparks
Date Rejected: 2010-09-14

Section 3.2. says:

3.2. Variable-Length Parameter Format

M3UA-Specific parameters. These TLV parameters are specific to the
M3UA protocol:

Registration Result                               0x0208
Deregistration Result                             0x0209
Local Routing Key Identifier                      0x020a

It should say:

3.2. Variable-Length Parameter Format

Common Parameters. These TLV parameters are common across the
different adaptation layers:

Registration Result                 0x0014,
Deregistration Result               0x0015,
Local Routing Key Identifier        0x0018,

Notes:

As the above three parameters mentioned are used for the same purpose in RFC 3868 and in RFC 4666. So the above parameters in RFC 4666 Section 3.2, the M3UA-Specific parameters can be considered to move them into the common parameters section 3.2 of RFC 4666 with the above sepecified values.

The advantage could be, for one who implements both SUA & M3UA can use the same encoding and decoding mechanisms/code for both the implementations.
--VERIFIER NOTES--
Per discussion on the SIGTRAN list, this is a fundamental and non-interoperable change to the protocol.

RFC 4669, "RADIUS Authentication Server MIB for IPv6", August 2006

Source of RFC: radext (sec)

Errata ID: 876
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-06
Rejected by: Dan Romascanu
Date Rejected: 2009-09-03

 

misleading RFC title, including abuse of defined terms 
(for RFCs 4668 - 4671) 

misleading RFC title, including abuse of defined terms 
(for RFCs 4668 - 4671)

IMHO, the RFC titles, "RADIUS ... MIB for IPv6" are misleading.
In fact, the new RFCs extend the RADIUS MIB modules to cover
IPv6, but they are not IPv6 specific!
Perhaps, better wording would have been "... for IPv4 and IPv6".

Furthermore, a very 'popular' clash of terms shines up here.
As specified in RFC 3410 and Part 1 of STD 62, RFC 3411, and
re-stated in the boilerplate Section 3, "The Internet-Standard
Management Framework", of all four RFCs, there's just one single
Management Information Base (MIB) comprised of various "MIB modules".
Thus, throughout the titles and the text bodies of the RFCs, the
proper term, "RADIUS ... MIB module" should be used instead of the
rather sluggish "RADIUS ... MIB".

Notes:

from pending
--VERIFIER NOTES--
no change in title is needed at this stage - ipV6 covers also ipv4n titles

RFC 4670, "RADIUS Accounting Client MIB for IPv6", August 2006

Source of RFC: radext (sec)

Errata ID: 27
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-06
Rejected by: Dan Romascanu
Date Rejected: 2009-09-03

The DESCRIPTION clause of the radiusAccClientRetransmissionsOBJECT-TYPE declaration says:

         DESCRIPTION
               "The number of RADIUS Accounting-Request packets
                retransmitted to this RADIUS accounting server.
                Retransmissions include retries where the
                Identifier and Acct-Delay have been updated, as
                well as those in which they remain the same."

It should say:

         DESCRIPTION
               "The number of RADIUS Accounting-Request packets
                retransmitted to this RADIUS accounting server.
                Retransmissions include retries where the
                Identifier and Acct-Delay have been updated, as
                well as those in which they remained the same."

Notes:

for temporal consistency

from pending
--VERIFIER NOTES--
the difference is not clear

Errata ID: 877
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-06
Rejected by: Dan Romascanu
Date Rejected: 2009-09-03

 

misleading RFC title, including abuse of defined terms 
(for RFCs 4668 - 4671)

IMHO, the RFC titles, "RADIUS ... MIB for IPv6" are misleading.
In fact, the new RFCs extend the RADIUS MIB modules to cover
IPv6, but they are not IPv6 specific!
Perhaps, better wording would have been "... for IPv4 and IPv6".

Furthermore, a very 'popular' clash of terms shines up here.
As specified in RFC 3410 and Part 1 of STD 62, RFC 3411, and
re-stated in the boilerplate Section 3, "The Internet-Standard
Management Framework", of all four RFCs, there's just one single
Management Information Base (MIB) comprised of various "MIB modules".
Thus, throughout the titles and the text bodies of the RFCs, the
proper term, "RADIUS ... MIB module" should be used instead of the
rather sluggish "RADIUS ... MIB".

Notes:

from pending
--VERIFIER NOTES--
no title change needed - ipv6 covers also previous ipv4 support

RFC 4671, "RADIUS Accounting Server MIB for IPv6", August 2006

Source of RFC: radext (sec)

Errata ID: 879
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-06
Rejected by: Dan Romascanu
Date Rejected: 2009-09-03

 

misleading RFC title, including abuse of defined terms 
(for RFCs 4668 - 4671)

IMHO, the RFC titles, "RADIUS ... MIB for IPv6" are misleading.
In fact, the new RFCs extend the RADIUS MIB modules to cover
IPv6, but they are not IPv6 specific!
Perhaps, better wording would have been "... for IPv4 and IPv6".

Furthermore, a very 'popular' clash of terms shines up here.
As specified in RFC 3410 and Part 1 of STD 62, RFC 3411, and
re-stated in the boilerplate Section 3, "The Internet-Standard
Management Framework", of all four RFCs, there's just one single
Management Information Base (MIB) comprised of various "MIB modules".
Thus, throughout the titles and the text bodies of the RFCs, the
proper term, "RADIUS ... MIB module" should be used instead of the
rather sluggish "RADIUS ... MIB".

Notes:

from pending
--VERIFIER NOTES--
no title change needed - ipv6 covers also previous ipv4 support

RFC 4672, "RADIUS Dynamic Authorization Client MIB", September 2006

Source of RFC: radext (sec)

Errata ID: 886
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-06
Rejected by: Stefaan De Cnodder
Date Rejected: 2006-11-07

 

(for RFC 4672 and 4673)

I am surprised that the 'OID anchor' of the RADIUS-DYNAUTH-xxx-MIB
modules does not match the OID hierarchy used in the other RADIUS
MIB modules published/updated concurrently.
I would have expected the new RADIUS MIB modules to be assigned OIDs
in the following, hierarchical way (using abbreviated notation):

  radiusMIB                  { mib-2 67 }  -- legacy, assigned by IANA
  radiusDynAuth              { radiusMIB 3 }       -- new
  RADIUS-DYNAUTH-CLIENT-MIB  { radiusDynAuth 1 }   -- new
  RADIUS-DYNAUTH-SERVER-MIB  { radiusDynAuth 2 }   -- new

instead of obtaining separate IANA assignments for the MIB module
OIDs, directly under mib-2.

Has there been a strong reason for this deviation from the established
pattern?

Notes:

from pending

--VERIFIER COMMENT--
Yes, there is a strong reason for it. In fact original in the first
versions of the draft, it was as follows:

radiusDynamicAuthorization OBJECT IDENTIFIER ::= { radiusMIB 3 }

radiusDynAuthServerMIBObjects OBJECT IDENTIFIER ::=
{ radiusDynAuthServerMIB 1 }

radiusDynAuthServer OBJECT IDENTIFIER ::=
{ radiusDynAuthServerMIBObjects 1 }


check
http://www.watersprings.org/pub/id/draft-decnodder-radext-dynauth-server-mib-00.txt

The reason for not doing so was that this was more difficult to
maintain. It was discussed at the mailinglist but I should search in the
archives to find it back.

RFC 4673, "RADIUS Dynamic Authorization Server MIB", September 2006

Source of RFC: radext (sec)

Errata ID: 885
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-06
Rejected by: Stefaan De Cnodder
Date Rejected: 2006-11-07

 

I am surprised that the 'OID anchor' of the RADIUS-DYNAUTH-xxx-MIB
modules does not match the OID hierarchy used in the other RADIUS
MIB modules published/updated concurrently.
I would have expected the new RADIUS MIB modules to be assigned OIDs
in the following, hierarchical way (using abbreviated notation):

  radiusMIB                  { mib-2 67 }  -- legacy, assigned by IANA
  radiusDynAuth              { radiusMIB 3 }       -- new
  RADIUS-DYNAUTH-CLIENT-MIB  { radiusDynAuth 1 }   -- new
  RADIUS-DYNAUTH-SERVER-MIB  { radiusDynAuth 2 }   -- new

instead of obtaining separate IANA assignments for the MIB module
OIDs, directly under mib-2.

Has there been a strong reason for this deviation from the established
pattern?

Notes:

from pending

--VERIFIER COMMENT--
Yes, there is a strong reason for it. In fact original in the first
versions of the draft, it was as follows:

radiusDynamicAuthorization OBJECT IDENTIFIER ::= { radiusMIB 3 }

radiusDynAuthServerMIBObjects OBJECT IDENTIFIER ::=
{ radiusDynAuthServerMIB 1 }

radiusDynAuthServer OBJECT IDENTIFIER ::=
{ radiusDynAuthServerMIBObjects 1 }


check
http://www.watersprings.org/pub/id/draft-decnodder-radext-dynauth-server-mib-00.txt

The reason for not doing so was that this was more difficult to
maintain. It was discussed at the mailinglist but I should search in the
archives to find it back.

RFC 4684, "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)", November 2006

Source of RFC: l3vpn (int)

Errata ID: 6226
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alexander ("Sasha") Vainshtein
Date Reported: 2020-07-09
Rejected by: Martin Vigoureux
Date Rejected: 2020-07-09

Section 4 says:

   The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix
   of 0 to 96 bits, encoded as defined in Section 4 of [5].

It should say:

   The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix
   of 0 to 96 bits, encoded as defined in Section 5 of [5].

Notes:

Reference [5] points to RFC 4760.
Encoding of prefixes in NLRI is defined in Section 5 "NLRI Encoding" of this document and not it Section 4.
--VERIFIER NOTES--
[5] points to rfc2858, and Section 4 in that rfc is the correct section to look into.

RFC 4690, "Review and Recommendations for Internationalized Domain Names (IDNs)", September 2006

Source of RFC: IAB

Errata ID: 4896
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hugo Salgado
Date Reported: 2016-12-27
Rejected by: Robert Sparks
Date Rejected: 2018-02-09

Section 8.2 says:

[IESG-IDN]          Internet Engineering Steering Group (IESG), "IESG
                    Statement on IDN", IESG Statements IDN Statement,
                    February 2003, <http://www.ietf.org/IESG/
                    STATEMENTS/IDNstatement.txt>.

It should say:

[IESG-IDN]          Internet Engineering Steering Group (IESG), "IESG
                    Statement on IDN", IESG Statements IDN Statement,
                    February 2003, <https://www.ietf.org/iesg/statement/
                    idn.html>.

Notes:

URL of resource has changed. Original gives 'Not found'.
--VERIFIER NOTES--
The right thing to do here is make sure the original URL redirects to the right place, which is now happening.

RFC 4707, "Netnews Administration System (NAS)", October 2006

Source of RFC: INDEPENDENT

Errata ID: 5814
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2019-08-18
Rejected by: Adrian Farrel
Date Rejected: 2019-08-18

Throughout the document, when it says:

Notes:

The report raised said:

> A future revision of the NAS protocol should mention the character set that MUST
> be used in commands, and also in answers.
>
> I advise current NAS implementations to use UTF-8 everywhere because UTF-8 is the
> encoding that will be encouraged in Netnews (NNTP commands already are in UTF-8
> per RFC 3977, and internationalized headers including newsgroup names are likely to
> be in UTF-8).

Whether or not this is good advice to future specifications and current implementations, this is not an erratum. Changes of this nature require to be documented in separate publications.
--VERIFIER NOTES--

Errata ID: 5819
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2019-08-18
Rejected by: Adrian Farrel
Date Rejected: 2019-08-18

Section 6.3.3.4 says:

   The VERS command is used to determine the protocol level to use
   between client and server.  The parameter is a protocol level that
   the client supports and wants to use.  The server will respond with
   the highest level accepted.
[...]
   When no option is given, the current protocol level will be printed.

It should say:

   The VERS command is used to determine the protocol level to use
   between client and server.  The optional parameter is a protocol
   level that the client supports and wants to use.  When this
   parameter is given, and is valid, the server will respond with
   the highest level accepted, at the start of the second line of its
   response, and the highest level it supports, at the end of that
   same line.
[...]
   When no parameter is given, or if the given parameter is invalid,
   the server will respond with the current protocol level, at the start
   of the second line of its response.

Notes:

The description should detail the syntax of the different possible answers to the VERS command. Especially, ABNF shows two "level" keywords in 302 and 402 answers, that are not explained in the original text.
--VERIFIER NOTES--
The suggested replacement text adds little or nothing to the understanding of the text which was clear to this uninformed reader.

RFC 4717, "Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks", December 2006

Source of RFC: pwe3 (int)

Errata ID: 605
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-10-17
Rejected by: Stewart Bryant
Date Rejected: 2011-08-03

Section 5.1.1 says:

- ATM One-to-one Cell Mode
- AAL5 PDU Frame Mode

It should say:

- ATM One-to-one Cell Mode  - PW Types: 0x000C and 0x000D
- AAL5 PDU Frame Mode       - PW Type:  0x000E

Notes:

--VERIFIER NOTES--
The author has correctly named the PW types and the reader can find the numeric identifier in both RFC4446 and the IANA registry. Thus the restatement of the numeric identifier is unnecessary.

Errata ID: 999
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-10-17
Rejected by: Stewart Bryant
Date Rejected: 2011-08-05

 

(1)  incomplete/missing specification of PW types

RFC 4446 (by means of reference update from drafts to published RFCs)
and the IANA "pwe3-parameters" registry refer to this document for
the allocation and description of a couple of (MPLS) Pseudowire Types.
Therefore, this memo should be explicit, precisely give the proper
information, and not leave the reader alone with some apparent
ambiguities in the registry.  (Unfortunately, the RFC uses
descriptive text labels for the PW types that do not match the
text listed as the 'Descriptions' in the MPLS PW Type registry.)

Excluding the PW type 0x001E assigned for the MFA, IANA lists seven
ATM PW types.  I (hopefully) was able to identify most of these in
RFC 4717, but the role of PW type 0x0003 initially remained unclear;
this gap in the meantime has been closed by RFC 4816, taking over
the 'ownership' for that PW type.

To fill in the gap, the following clarifications should be posted
in an RFC errata note for RFC 4717 (please correct if I'm wrong);
because there also is a L2TPv3 Pseudowire Type (sub-)registry
(in the IANA "l2tp-parameters" registry) I also use the precise
term, "MPLS PW Type", in the proposed clarifications.

(1a)  Section 5.1.1

The initial text of Section 5.1.1 (on page 7 of RFC 4717) says:

   This control word is used in the following encapsulation modes:

     - ATM One-to-one Cell Mode
     - AAL5 PDU Frame Mode

It should say:

   This control word is used in the following encapsulation modes:

|    - ATM One-to-one Cell Mode  - MPLS PW types 0x000C and 0x000D
|    - AAL5 PDU Frame Mode       - MPLS PW type 0x000E

(1b)  Section 5.1.2

The initial text of Section 5.1.2 (on page 8 of RFC 4717) says:

   This control word is used in the following encapsulation modes:

     - ATM N-to-one Cell Mode
     - AAL5 SDU Frame Mode

It should say:

   This control word is used in the following encapsulation modes:

|    - ATM N-to-one Cell Mode  - MPLS PW types 0x0009 and 0x000A
|    - AAL5 SDU Frame Mode     - MPLS PW type 0x0002

(1c)  see item (6a) below!

(1d)  missing IANA Considerations

NOTE:
  Would the above clarifications have been included in the RFC,
  it should also have contained an IANA Considerations Section.
  In the meantime, after some complaints and interventions, the
  IANA "pwe3-parameters" registry has been updated to contain the
  proper pointers to RFC 4717 for the abovementioned six PW Types.


(2)  Section 5.1.2 -- misleading specification due to omission.

On top of page 9, Section 5.1.2 says:

   The next 4 bits provide space for carrying protocol-specific flags.
   These are defined in the protocol-specific details below.
|
|  The next 6 bits provide a length field, which is used as follows:
   [...]

'The next 6 bits' is misleading; as indicated in the (unnumbered)
figure at the bottom of page 8, there is a 2-bit 'Res' field between
the Flags field and the Length field; unfortunately, the text lacks
any description of that field.
To fill this gap, the above text should be amended to say:

   The next 4 bits provide space for carrying protocol-specific flags.
   These are defined in the protocol-specific details below.

|  The subsequent 2-bit Res field is reserved; it SHOULD be set to 0
|  by the sending PE and ignored by the receiving PE.
|
|  The next 6 bits provide a length field, which is used as follows:
   [...]

Note: 'SHOULD' is appropriate as future (optional) specifications
      might assign semantics to that field.


(3)  Section 5.4 -- word omission

Section 5.4 (on page 10 of RFC 4717) says:

   The setting of the TTL value in the PW label is application
|  dependent.  In any case, [RFC3032] TTL processing procedure,
   including handling of expired TTLs, MUST be followed.

It should say:

   The setting of the TTL value in the PW label is application
|  dependent.  In any case, the [RFC3032] TTL processing procedure,
   including handling of expired TTLs, MUST be followed.


(4)  Section 6.3 -- word omission

On page 14, Section 6.3 of RFC 4717 contains the numbered item:

|      -iv. The Length of AAL5 frame may exceed the MTU of the PSN.
            This requires fragmentation, which may not be available to
            all nodes at the PW endpoint.

The RFC should say:

|      -iv. The Length of an AAL5 frame may exceed the MTU of the PSN.
            This requires fragmentation, which may not be available to
            all nodes at the PW endpoint.


(5)  Section 7.4 -- distorting typo

The initial text of Section 7.4 (on page 17 of RFC 4717) contains
the line:

|    - (b) On the ATM side of the PW
                                  ^^
This is misleading.  It certainly should say:

|    - (b) On the ATM side of the PE
                                  ^^

(6)  Section 8 -- misleading short text / lack of precision

Section 8 of RFC 4717 (on page 18) says:

   The N-to-one mode (N >= 1) described in this document allows a
   service provider to offer an ATM PVC- or SVC-based service across a
   network.  The encapsulation allows multiple ATM VCCs or VPCs to be
   carried within a single PSN tunnel.  A service provider may also use
   N-to-one mode to provision either one VCC or one VPC on a tunnel.
   This section defines the VCC and VPC cell relay services over a PSN
   and their applicability.

For clarity and added precision, it should say:

   The N-to-one mode (N >= 1) described in this document allows a
   service provider to offer an ATM PVC- or SVC-based service across a
|  packet switched network.  The encapsulation allows multiple ATM VCCs
   or VPCs to be carried within a single PSN tunnel.  A service provider
   may also use N-to-one mode to provision either one VCC or one VPC on
   a tunnel.  This section defines the VCC and VPC cell relay services
   over a PSN and their applicability.


(7)  Section 8.1 -- various clarifications

(7a)  missing applicability statement for PW Types -- also (1c) above

The initial paragraph of Section 8.1 (on page 19 of RFC 4717) says:

   This section describes the general encapsulation format for ATM over
   PSN pseudowires.

According to the expanations in item (1) above, it should say:

   This section describes the general encapsulation format for ATM over
|  PSN pseudowires used with the MPLS PW types 0x0009 and 0x000A (for
|  VCC and VPC transport, respectively) described in Section 5.1.2.

Note: As could be seen later, after the publication of RFC 4816,
this format is reused there.  Thus, it might be even better to say:

   This section describes the general encapsulation format for ATM over
|  PSN pseudowires used with the MPLS PW types 0x0009 and 0x000A (for
|  VCC and VPC transport, respectively) described in Section 5.1.2,
|  and PW Type 0x0003 (transparent cell transport [RFC-to-be-4816]).

Accordingly, an Informative Reference to the work-in-progress
predecessor of RFC 4816 would have to be added to Section 18.

(7b)  inprecise wording not reflecting requirements language elsewhere

In Section 8.1, the 3rd paragraph below Figure 4 (on mid-page 19)
says:

|  As shown above, in Figure 4, the ATM Control Word is inserted before
|  the ATM service payload.  It may contain a length field and a
   sequence number field in addition to certain control bits needed to
   carry the service.

Taken literally, this text is misleading and partially contradicts
the requirements specified in Section 5.1 (in the second paragraph
on page 7).  In particular, the entire ATM control word (the 3rd word
in Figure 4) is optional, and *not* the various bit fields therein.
To properly reflect these requirements, the RFC should says instead:

|  As shown above, in Figure 4, the optional ATM Control Word (if
|  present) is inserted before the ATM service payload. It contains a
   length field and a sequence number field in addition to certain
   control bits needed to carry the service.

(7c)  bad grammar

Within Section 8.1, the last paragraph on page 20 says:

     * When multiple VCCs or VPCs are transported in one pseudowire,
       VPI/VCI values MUST be unique.  When the multiple VCCs or VPCs
|      are from different a physical transmission path, it may be
                         ^^^                          ^
       necessary to assign unique VPI/VCI values to the ATM connections.
       If they are from the same physical transmission path, the VPI/VCI
       values are unique.

It should say:

     * When multiple VCCs or VPCs are transported in one pseudowire,
       VPI/VCI values MUST be unique.  When the multiple VCCs or VPCs
|      are from different physical transmission paths, it may be
                         ^                          ^^
       necessary to assign unique VPI/VCI values to the ATM connections.
       If they are from the same physical transmission path, the VPI/VCI
       values are unique.

(7d)  Improper use of RFC 2119 keywords

According to RFC 2119, 'MUST' requirements do not admit exceptions.
If exceptional behavior is to be admitted via 'MAY' clauses, the
generally preferred behavior must be specified with 'SHOULD'.

Thus in the light of the explanation at the bottom of page 20
-- quoted and clarified above in (7c) --, the two bullets on top
of page 21,

     * VPI

|      The ingress router MUST copy the VPI field from the incoming cell
       into this field.  For particular emulated VCs, the egress router
       MAY generate a new VPI and ignore the VPI contained in this
       field.

     * VCI

|      The ingress router MUST copy the VCI field from the incoming ATM
       cell header into this field.  For particular emulated VCs, the
       egress router MAY generate a new VCI.

should say:

     * VPI

|      The ingress router SHOULD copy the VPI field from the incoming
       cell into this field.  For particular emulated VCs, the egress
       router MAY generate a new VPI and ignore the VPI contained in
       this field.

     * VCI

|      The ingress router SHOULD copy the VCI field from the incoming
       ATM cell header into this field.  For particular emulated VCs,
       the egress router MAY generate a new VCI.


(8)  Sections 9.3 ff. -- alignment flaws in artwork

(8a)
Within Section 9.3, the top part of Figure 8 on page 24 contains
a misaligned border;

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               PSN Transport Header (As Required)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |                      Pseudowire Header                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | [...]

should be:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               PSN Transport Header (As Required)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |                      Pseudowire Header                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | [...]

The same flaw recurs ...

(8b)  within Section 9.4.1, in Figure 9 on page 25;
(8c)  within Section 9.4.1, in Figure 10 on page 26;
(8d)  within Section 11.1, in Figure 12 on page 29;


(9)  Section 9.4.1 -- word omission

On mid-page 25, the bullet,

     * VCI Bits

|      The 16-bit Virtual Circuit Identifier (VCI) incorporates ATM
       Layer VCI value of the cell.

should say:

     * VCI Bits

|      The 16-bit Virtual Circuit Identifier (VCI) incorporates the ATM
       Layer VCI value of the cell.


(10)  Section 10.1 -- multiple mis-specifications

(10a)
As will be explained below, the initial part of Section 10.1
(on page 27) comprises several issues.

The RFC says:

|  The AAL5 CPCS-SDU is prepended by the following header:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |  Res  |T|E|C|U|Res|  Length   |   Sequence Number (Optional)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              "                                |
   |                     ATM cell or AAL5 CPCS-SDU                 |
   |                              "                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 11: AAL5 CPCS-SDU Encapsulation

It should say:

|  The AAL5 CPCS-SDU or OAM cell is prepended the ATM Control Word:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |0 0 0 0|T|E|C|U|Res|  Length   |     Sequence Number (or 0)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|    Figure 11: Control Word used with AAL5 CPCS-SDU Encapsulation

Rationale:

(a.1)
The text is wrong and misleading; the figure does not (merely) show
'the prepended header' (i.e., the "ATM Control Word", according to
other parts of this RFC), but the payload as well!
The top level structure of the encapsulation is specified in Figure 4;
hence, it suffices to specify the details of the Control Word here.
Accordingly, the above replacement omits the payload and presents
a modified figure caption.

(a.2)
The 4 most significant bits of the ATM Control Word MUST be all zero.
Denoting the field as 'reserved' is misleading; future specifications
MUST NOT change the value.  See Section 5.1.2 of this RFC, RFC 4385,
and the recently published RFC 4928 for additional explanation!

(a.3)
The 'Sequence Number' field is *not* optional in the control word,
as erroneously might be deduced from the original version of the
figure; it MUST always be present; according to Section 5.1.2, only
the *processing* of this field is optional, and the reserved value 0
is *not* a valid sequence number; it indicates non-use of sequence
number processing.  Hence, the lower half of the ATM Control Word
either contains a sequence number or 0.

(10b)
The T bit explanation (in the lower half of page 27) contains
misleading and inappropriate wording related to Figure 4.
Figure 4 generally applies for both the proper AAL5 CPCS-SDU payload
or the case of an ATM OAM cell payload.  Furthermore, it should be
noted that Section 8.1 (which contains and explains Figure 4)
specifies the Flags field as 'reserved, should be set to 0'.
This is incompatible with the subsequent text that requires the T bit
to be set to 1 for an OAM cell.  Therefore, to avoid confusion,
the clause referencing to Figure 4 should better be deleted from
the T bit explanation.

Hence, the text,

       Bit (T) of the control word indicates whether the packet contains
       an ATM admin cell or an AAL5 payload.  If T = 1, the packet
|      contains an ATM admin cell, encapsulated according to the N-to-
|      one cell relay encapsulation, Figure 4.  If not set, the PDU
       contains an AAL5 payload.  The ability to transport an ATM cell
       in the AAL5 SDU mode is intended to provide a means of enabling
       administrative functionality over the AAL5 VCC (though it does
       not endeavor to preserve user-cell and admin-cell
       arrival/transport ordering).

should say:

       Bit (T) of the control word indicates whether the packet contains
       an ATM admin cell or an AAL5 payload.  If T = 1, the packet
|      contains an ATM admin cell.  If T = 0, the PDU contains an AAL5
       payload.  The ability to transport an ATM cell in the AAL5 SDU
       mode is intended to provide a means of enabling administrative
       functionality over the AAL5 VCC (though it does not endeavor to
       preserve user-cell and admin-cell arrival/transport ordering).

(10c)  incomplete specification

The description of the fields in Figure 11 is incomplete.
As a service to the reader, for completeness the following
text should be added at the end of Section 10.1:

|  For a description of the Length and Sequence Number fields, see
|  Section 5.1.2.


(11)  Section 11.1 -- surprising/confusing specification details

(11a)  danger of confusion - or a mis-specification?

The placement of the U and E bits in the Control Word shown in
Figure 12 (on page 29) comes to surprise.

Apparently, the two bits are exchanged relatively to their placement
within the PTI field in the Control Word shown in Figure 10
(on page 26).

If this has been done intentionally, it might surprise some
implementors, leading to interoperability problems.
In this case, a specific warning should have been added to the
RFC text in Section 11.1, somewhere below Figure 12, e.g.:

|  Warning to implementors: The order of the E and U bit is reversed
|  relative to their placement in the PTI field of the ATM cell header.
|  Section 11.2.2 below details the bit manipulations to be done by
|  the receiving PE.

But if this is an unintentional oversight, the Control Word part
of Figure 12,

                                                            [...]  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |0 0 0 0| Resvd |   Optional Sequence Number    |M|V| Res |U|E|C|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | [...]

should be corrected to say:

                                                            [...]  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |0 0 0 0| Resvd |   Optional Sequence Number    |M|V| Res |E|U|C|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | [...]
                                                              ^ ^
Note:
  In this case, the procedures laid out in Section 11.2.2
  could easily be collapsed to a simple bit field transfer!

(11b)  lack of precision

Below Figure 12, the RFC text on page 29 says:

   The M, V, Res, and C bits are as defined earlier for VCC One-to-one
   cell mode.

For clarity and completeness, it should say:

   The M, V, Res, and C bits are as defined earlier for VCC One-to-one
|  cell mode.  M must be set to 1 and V must be set to 0 for AAL5 PDU
|  Encapsulation; further details regarding the C bit are given below.


(12)  Section 11.2.1 -- internal mis-ref.

The 3rd bullet in Section 11.2.1, near the bottom of page 30, says:

     - The E and C bits of the fragment shall be set as defined in
|      section 9.
               ^
It should say:

     - The E and C bits of the fragment shall be set as defined in
|      section 11.1.
               ^^^^

Rationale:
  As explained above for item (11a), the specification of these bits in
  Section 11.1 is contrary to their (hidden) use in Sections 8 and 9.


(13)  Section 11.2.2 -- significant typo (wrong bit field name)

Section 11.2.2 (on page 31) contains the bullet:

      -iii. The least significant bit for the last ATM cell in the PSN
|           frame is set to the value of the UU bit of Figure 12.
                                             ^^
It should say:

      -iii. The least significant bit for the last ATM cell in the PSN
|           frame is set to the value of the U bit of Figure 12.
                                             ^

(14)  Section 12 -- internal mis-refs

The last paragraph of Section 12 (on page 32) says:

   In both the ATM-to-PSN and PSN-to-ATM directions, the method used to
   transfer the CLP and EFCI information of the individual cells into
   the ATM-specific field, or flags, of the PW packet is described in
|  detail in sections 6 through 9 for each encapsulation mode.
                      ^         ^
It should say:

   In both the ATM-to-PSN and PSN-to-ATM directions, the method used to
   transfer the CLP and EFCI information of the individual cells into
   the ATM-specific field, or flags, of the PW packet is described in
|  detail in sections 8 through 11 for each encapsulation mode.
                      ^         ^^

(15)  Abuse of language

'AAL5' stands for "ATM Adaptation Layer 5".  Hence, the wording
"ATM AAL5" is a replication considered a rough abuse of language.

All occurrences of "ATM AAL5" in the RFC should be corrected to "AAL5".

Notes:

--VERIFIER NOTES--
This complex, multi-part, erratum has been split into a number of errata to make it easier for the reader to determine the resolution of the components. Some components have been verified, some rejected and some deferred. To guard against an editing error I am leaving 999 itself untouched, but in rejected state lest it is necessary to inspect the original erratum text.

The reader is revered to the other errata raised against RFC4717 to determine the resolution of each element of this errata.

Errata ID: 2919
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-10-17
Rejected by: Stewart Bryant
Date Rejected: 2011-08-05

 

(7d)  Improper use of RFC 2119 keywords

According to RFC 2119, 'MUST' requirements do not admit exceptions.
If exceptional behavior is to be admitted via 'MAY' clauses, the
generally preferred behavior must be specified with 'SHOULD'.

Thus in the light of the explanation at the bottom of page 20
-- quoted and clarified above in (7c) --, the two bullets on top
of page 21,

     * VPI

|      The ingress router MUST copy the VPI field from the incoming cell
       into this field.  For particular emulated VCs, the egress router
       MAY generate a new VPI and ignore the VPI contained in this
       field.

     * VCI

|      The ingress router MUST copy the VCI field from the incoming ATM
       cell header into this field.  For particular emulated VCs, the
       egress router MAY generate a new VCI.

should say:

     * VPI

|      The ingress router SHOULD copy the VPI field from the incoming
       cell into this field.  For particular emulated VCs, the egress
       router MAY generate a new VPI and ignore the VPI contained in
       this field.

     * VCI

|      The ingress router SHOULD copy the VCI field from the incoming
       ATM cell header into this field.  For particular emulated VCs,
       the egress router MAY generate a new VCI.

Notes:

This is section 7(d) From erratum 999
--VERIFIER NOTES--
The MUST and the MAY refer to the behavior of different PW entities (ingress and egress router respectively), thus the original text is correct.

Errata ID: 2918
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-10-17
Rejected by: Stewart Bryant
Date Rejected: 2011-08-05

 

(1)  incomplete/missing specification of PW types

RFC 4446 (by means of reference update from drafts to published RFCs)
and the IANA "pwe3-parameters" registry refer to this document for
the allocation and description of a couple of (MPLS) Pseudowire Types.
Therefore, this memo should be explicit, precisely give the proper
information, and not leave the reader alone with some apparent
ambiguities in the registry.  (Unfortunately, the RFC uses
descriptive text labels for the PW types that do not match the
text listed as the 'Descriptions' in the MPLS PW Type registry.)

Excluding the PW type 0x001E assigned for the MFA, IANA lists seven
ATM PW types.  I (hopefully) was able to identify most of these in
RFC 4717, but the role of PW type 0x0003 initially remained unclear;
this gap in the meantime has been closed by RFC 4816, taking over
the 'ownership' for that PW type.

To fill in the gap, the following clarifications should be posted
in an RFC errata note for RFC 4717 (please correct if I'm wrong);
because there also is a L2TPv3 Pseudowire Type (sub-)registry
(in the IANA "l2tp-parameters" registry) I also use the precise
term, "MPLS PW Type", in the proposed clarifications.

(1a)  Section 5.1.1

The initial text of Section 5.1.1 (on page 7 of RFC 4717) says:

   This control word is used in the following encapsulation modes:

     - ATM One-to-one Cell Mode
     - AAL5 PDU Frame Mode

It should say:

   This control word is used in the following encapsulation modes:

|    - ATM One-to-one Cell Mode  - MPLS PW types 0x000C and 0x000D
|    - AAL5 PDU Frame Mode       - MPLS PW type 0x000E

(1b)  Section 5.1.2

The initial text of Section 5.1.2 (on page 8 of RFC 4717) says:

   This control word is used in the following encapsulation modes:

     - ATM N-to-one Cell Mode
     - AAL5 SDU Frame Mode

It should say:

   This control word is used in the following encapsulation modes:

|    - ATM N-to-one Cell Mode  - MPLS PW types 0x0009 and 0x000A
|    - AAL5 SDU Frame Mode     - MPLS PW type 0x0002

(1c)  see item (6a) below!

(1d)  missing IANA Considerations

NOTE:
  Would the above clarifications have been included in the RFC,
  it should also have contained an IANA Considerations Section.
  In the meantime, after some complaints and interventions, the
  IANA "pwe3-parameters" registry has been updated to contain the
  proper pointers to RFC 4717 for the abovementioned six PW Types.

======

(7a)  missing applicability statement for PW Types -- also (1c) above

The initial paragraph of Section 8.1 (on page 19 of RFC 4717) says:

   This section describes the general encapsulation format for ATM over
   PSN pseudowires.

According to the expanations in item (1) above, it should say:

   This section describes the general encapsulation format for ATM over
|  PSN pseudowires used with the MPLS PW types 0x0009 and 0x000A (for
|  VCC and VPC transport, respectively) described in Section 5.1.2.

Note: As could be seen later, after the publication of RFC 4816,
this format is reused there.  Thus, it might be even better to say:

   This section describes the general encapsulation format for ATM over
|  PSN pseudowires used with the MPLS PW types 0x0009 and 0x000A (for
|  VCC and VPC transport, respectively) described in Section 5.1.2,
|  and PW Type 0x0003 (transparent cell transport [RFC-to-be-4816]).

Accordingly, an Informative Reference to the work-in-progress
predecessor of RFC 4816 would have to be added to Section 18.


======

Notes:

This was section 1 and section 7(a) of Errata 999
--VERIFIER NOTES--
The ATM PW Encapsulation modes specified are used by multiple ATM PW types and the intent of the working group was to allow new ATM PW types to use these encapsulations without requiring an update or republication of RFC 4717

Errata ID: 2921
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-10-17
Rejected by: Stewart Bryant
Date Rejected: 2012-02-21

 

(11a)  danger of confusion - or a mis-specification?

The placement of the U and E bits in the Control Word shown in
Figure 12 (on page 29) comes to surprise.

Apparently, the two bits are exchanged relatively to their placement
within the PTI field in the Control Word shown in Figure 10
(on page 26).

If this has been done intentionally, it might surprise some
implementors, leading to interoperability problems.
In this case, a specific warning should have been added to the
RFC text in Section 11.1, somewhere below Figure 12, e.g.:

|  Warning to implementors: The order of the E and U bit is reversed
|  relative to their placement in the PTI field of the ATM cell header.
|  Section 11.2.2 below details the bit manipulations to be done by
|  the receiving PE.

But if this is an unintentional oversight, the Control Word part
of Figure 12,

                                                            [...]  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |0 0 0 0| Resvd |   Optional Sequence Number    |M|V| Res |U|E|C|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | [...]

should be corrected to say:

                                                            [...]  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |0 0 0 0| Resvd |   Optional Sequence Number    |M|V| Res |E|U|C|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | [...]
                                                              ^ ^
Note:
  In this case, the procedures laid out in Section 11.2.2
  could easily be collapsed to a simple bit field transfer!

Notes:

This is element 11(a) of Errata 999

This needs to checked against the corresponding ITU specification for this mode.
--VERIFIER NOTES--
RFC4717 and ITU-T Recommendation Y.1412 use the same bit definitions and the same bit ordering, and therefore one must conclude that the bit ordering was that which was intended by the authors and has thus implemented.

There have been no concerns expressed on the PWE3 list regarding the change of ordering between Figure 11 and Figure 12.

RFC 4719, "Transport of Ethernet Frames over Layer 2 Tunneling Protocol Version 3 (L2TPv3)", November 2006

Note: This RFC has been updated by RFC 5641

Source of RFC: l2tpext (int)

Errata ID: 4231
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Karsten Thomann
Date Reported: 2015-01-12
Rejected by: Brian Haberman
Date Rejected: 2015-01-12

Section 3.1 says:

The entire Ethernet frame, without the preamble or frame check
sequence (FCS), is encapsulated in L2TPv3 and is sent as a single
packet by the ingress LCCE.

It should say:

The entire Ethernet frame, without the preamble and frame check
sequence (FCS), is encapsulated in L2TPv3 and is sent as a single
packet by the ingress LCCE.

Notes:

The LCCE should remove the preamble AND FCS
--VERIFIER NOTES--
The without/or construct is a valid way in English to indicate that both fields are omitted during encapsulation.

RFC 4728, "The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4", February 2007

Source of RFC: manet (rtg)

Errata ID: 922
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-04-20
Rejected by: Dave Maltz
Date Rejected: 2007-04-20

Section 6.6 says:

      Opt Data Len

         8-bit unsigned integer.  Length of the option, in octets,
         excluding the Option Type and Opt Data Len fields.

It should say:

      Opt Data Len

         8-bit unsigned integer.  Length of the option, in octets,
         excluding the Option Type and Opt Data Len fields.  In this
         case, the value of this field is always 10.

Notes:

Provide specific length value.

Dave Maltz wrote:
"disagree. I'd prefer the original wording."

from pending

RFC 4733, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", December 2006

Note: This RFC has been updated by RFC 4734, RFC 5244

Source of RFC: avt (rai)

Errata ID: 3451
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Xavier Marjou
Date Reported: 2013-01-11
Rejected by: Gonzalo Camarillo
Date Rejected: 2013-04-04

Section 2.1 says:

Named telephone events are carried as part of the audio stream and
MUST use the same sequence number and timestamp base as the regular
audio channel to simplify the generation of audio waveforms at a 
gateway.

It should say:

Named telephone events are carried as part of the audio stream and
MUST use the same SSRC (therefore the same timing and sequence
number space) and the same timestamp clock rate as the regular
audio channel to simplify the generation of audio waveforms at a
gateway.

Notes:

RFC4733 was written in a way to avoid the multiple clock-rate problem by mandating the use of the same SSRC for DTMF and audio. However it's not explicitly written, which brings an ambiguity. It was commented that RFC4733 needs to be updated. (c.f. http://tools.ietf.org/wg/avtext/minutes?item=minutes-85-avtext.html)
--VERIFIER NOTES--
Discussions around this erratum resulted in the updated 3489 erratum.

RFC 4740, "Diameter Session Initiation Protocol (SIP) Application", November 2006

Source of RFC: aaa (ops)

Errata ID: 2315
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexandre Westfahl
Date Reported: 2010-06-28
Rejected by: Dan Romascanu
Date Rejected: 2011-08-03

Section 9.5.4 says:

      SIP-Authorization ::= < AVP Header: 380 >
                            { Digest-Username }
                            { Digest-Realm }
                            { Digest-Nonce }
                            { Digest-URI }
                            { Digest-Response }
                            [ Digest-Algorithm ]
                            [ Digest-CNonce ]
                            [ Digest-Opaque ]
                            [ Digest-QoP ]
                            [ Digest-Nonce-Count ]
                            [ Digest-Method]
                            [ Digest-Entity-Body-Hash ]
                          * [ Digest-Auth-Param ]
                          * [ AVP ]

It should say:

      SIP-Authorization ::= < AVP Header: 380 >
                        ***    [ Digest-Username ]
                        ***    [ Digest-Realm ]
                        ***    [ Digest-Nonce ]
                            { Digest-URI }
                        ***    [ Digest-Response ]
                            [ Digest-Algorithm ]
                            [ Digest-CNonce ]
                            [ Digest-Opaque ]
                            [ Digest-QoP ]
                            [ Digest-Nonce-Count ]
                            [ Digest-Method]
                            [ Digest-Entity-Body-Hash ]
                          * [ Digest-Auth-Param ]
                          * [ AVP ]

Notes:

According to RFC5090, defining Digest Authentication, we only have Digest-Method and Digest-URI during the first round trip.
As it is possible to add a Digest-Realm and Digest-Username, it is impossible to add a Digest-Nonce in the first round trip! The nonce is calculated in the diameter server so the RADIUS/Diameter gateway can't add a nonce when the first request arrive. This problem is not limited to Radius/Diameter gateway, a diameter peer can't add a nonce during the first MAR/MAA.

Maybe I was no clear enough in my explanation, since I am implementing Diameter-SIP now, I am sure there is a problem. I am available if you need more details or explanation.
--VERIFIER NOTES--
The errata is wrong.

The SIP-Authorization AVP carries the content of the Authorization header provided by the user in the SIP request.
As you can see below, the content of the

credentials = "Digest" digest-response
digest-response = 1#( username | realm | nonce | digest-uri
| response | [ algorithm ] | [cnonce] |
[opaque] | [message-qop] |
[nonce-count] | [auth-param] )

And username, realm, nonce, digest-uri, response are mandatory parameters in this header.
So the syntax is correct.

RFC 4742, "Using the NETCONF Configuration Protocol over Secure SHell (SSH)", December 2006

Note: This RFC has been obsoleted by RFC 6242

Source of RFC: netconf (ops)

Errata ID: 1903
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Xiang Li
Date Reported: 2009-10-07
Rejected by: Dan Romascanu
Date Rejected: 2010-05-10

Section 3.1 says:

S: <?xml version="1.0" encoding="UTF-8"?>
   S: <hello>
   S:   <capabilities>
   S:     <capability>
   S:       urn:ietf:params:xml:ns:netconf:base:1.0
   S:     </capability>
   S:     <capability>
   S:       urn:ietf:params:ns:netconf:capability:startup:1.0
   S:     </capability>
   S:   </capabilities>
   S:   <session-id>4<session-id>
   S: </hello>
   S: ]]>]]>

   C: <?xml version="1.0" encoding="UTF-8"?>
   C: <hello>
   C:   <capabilities>
   C:     <capability>
   C:       urn:ietf:params:xml:ns:netconf:base:1.0
   C:     </capability>
   C:   </capabilities>
   C: </hello>
   C: ]]>]]>

It should say:

S: <?xml version="1.0" encoding="UTF-8"?>
   S: <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
   S:   <capabilities>
   S:     <capability>
   S:       urn:ietf:params:xml:ns:netconf:base:1.0
   S:     </capability>
   S:     <capability>
   S:       urn:ietf:params:ns:netconf:capability:startup:1.0
   S:     </capability>
   S:   </capabilities>
   S:   <session-id>4<session-id>
   S: </hello>
   S: ]]>]]>

   C: <?xml version="1.0" encoding="UTF-8"?>
   C: <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
   C:   <capabilities>
   C:     <capability>
   C:       urn:ietf:params:xml:ns:netconf:base:1.0
   C:     </capability>
   C:   </capabilities>
   C: </hello>
   C: ]]>]]>

Notes:

the netconf namespace is missing in the sample hello message (for both client and server hello)
--VERIFIER NOTES--
this change should be discussed by the NETCONF WG as part of RFC 4742bis work

RFC 4757, "The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows", December 2006

Note: This RFC has been updated by RFC 6649

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 1648
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Ganga Mahesh Siddem
Date Reported: 2008-12-31
Rejected by: Sean Turner
Date Rejected: 2011-06-28

Section 7.3 says:

Kcrypt = HMAC(Klocal, "fortybits", (int32)0);
// len includes terminating null

Kseq = HMAC(Kss, "fortybits", (int32)0);
// len includes terminating null

It should say:

Kcrypt = HMAC(Klocal,(int32)0, "fortybits");
// len includes terminating null

Kseq = HMAC(Kss, (int32)0,"fortybits");
// len includes terminating null

Notes:

Larry Zhu confirmed this issue.Misordered arguments in HMAC function.
--VERIFIER NOTES--
I checked with Magnus Nystrom. He said their implementation is equal to the RFC.

Errata ID: 2067
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Michiko Short
Date Reported: 2010-03-05
Rejected by: Sean Turner
Date Rejected: 2011-06-28

Section 7.3 says:

// Encrypt the data (if encrypting)

                   if (encrypt)
                           RC4(Kcrypt, data);

                   // Save first 8 octets of HMAC Sgn_Cksum

                   Sgn_Cksum = HMAC(Ksign, Sgn_Cksum);
                   memcpy(Token.SGN_CKSUM, Sgn_Cksum, 8);

It should say:

// Encrypt the data (if encrypting)

                   if (encrypt)
                           RC4(Kcrypt, data);

                    // Sum the padding buffer
 
                   Sgn_Cksum += MD5(padding);

                   // Encrypt the padding (if encrypting)

                   if (padding)
                           RC4(Kcrypt, padding);

                  // Save first 8 octets of HMAC Sgn_Cksum

                   Sgn_Cksum = HMAC(Ksign, Sgn_Cksum);
                   memcpy(Token.SGN_CKSUM, Sgn_Cksum, 8);

Notes:

WRAP missing padding
--VERIFIER NOTES--
Turns out padding is already included in data, so Errata 1674, which I just approved, covers this. I verified this with Magnus Nystrom.

RFC 4763, "Extensible Authentication Protocol Method for Shared-secret Authentication and Key Establishment (EAP-SAKE)", November 2006

Source of RFC: INDEPENDENT

Errata ID: 1415
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-02-12
Rejected by: Bob Braden
Date Rejected: 2008-04-24

 

(3)  Section 3.2.8.2 -- clarification needed

Within Section 3.2.8.2, the second paragraph on page 20 says:

   The default encryption algorithm, as described in Section 3.2.8.3,
   requires the length of the plaintext to be a multiple of 16 bytes.
   The sender MAY need to include the AT_PADDING attribute as the last
|  attribute within the value field of the AT_ENCR_DATA attribute.  The
   length of the padding is chosen so that the length of the value field
   of the AT_ENCR_DATA attribute becomes a multiple of 16 bytes.  The
   AT_PADDING attribute SHOULD NOT be included if the total length of
   other attributes present within the AT_ENCR_DATA attribute is a
   multiple of 16 bytes.  The length of the AT_PADDING attribute
   includes the Attribute Type and Attribute Length fields.  The actual
   pad bytes in the value field are set to zero (0x00) on sending.  The
   recipient of the message MUST verify that the pad bytes are zero
   after decryption and MUST silently discard the message otherwise.

It should say:

   The default encryption algorithm, as described in Section 3.2.8.3,
   requires the length of the plaintext to be a multiple of 16 bytes.
   The sender MAY need to include the AT_PADDING attribute as the last
|  attribute within the plaintext of the value field of the AT_ENCR_DATA
   attribute.  The length of the padding is chosen so that the length of
   the value field of the AT_ENCR_DATA attribute becomes a multiple of
   16 bytes.  The AT_PADDING attribute SHOULD NOT be included if the
   total length of other attributes present within the AT_ENCR_DATA
   attribute is a multiple of 16 bytes.  The length of the AT_PADDING
   attribute includes the Attribute Type and Attribute Length fields.
   The actual pad bytes in the value field are set to zero (0x00) on
   sending.  The recipient of the message MUST verify that the pad bytes
   are zero after decryption and MUST silently discard the message
   otherwise.

Note:
The proper distinction between the plaintext and the ciphertext
version of fields that are encrypted in its on-the-wire form should be
heavily emphasized; neglecting this distinction can lead to significant
interoperability problems and catastrophic cryptographic failures!

(7)  Section 3.3.5 -- lack of specification, and artwork improvement

As above ...

The figure in Section 3.3.5, on page 28, contains the initial part:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Type=EAP-SAKE  |    Version=2  | Session ID    |   Subtype=1   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   AT_RAND_P    | Length = 18  |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   |  ...

It should say:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Code=2     |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type=EAP-SAKE |   Version=2   |  Session ID   |   Subtype=1   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   AT_RAND_P   |   Length=18   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   |  ...

On page 29, the explanation:

   Type

|     EAP-SAKE

should say:

   Type

|     EAP-SAKE=48

And the subsequent explanation headlines:

|  AT_RAND_P

|  AT_PEERID

|  AT_SPI_P

|  AT_MIC_P

should be amended to say, respectively:

|  AT_RAND_P (=2)

|  AT_PEERID (=6)

|  AT_SPI_P (=8)

|  AT_MIC_P (=4)


(13)  Section 4 -- lack of specification

The first paragraph of Section 4 (on page 37) says:

|  IANA allocated a new EAP Type for EAP-SAKE.
                                ^
It should say:

|  IANA allocated a new EAP Type, 48, for EAP-SAKE.
                                ^^^^^^

(14)  Section 5.5 -- spelling and terminology

'Server' and 'Peer' are distinguished roles of EAP entities.
Therefore, when talking about both participants in an EAP session,
the term 'Peer' (in headline case) should not be used to avoid
confusion.

Therefore, the last paragraph of Section 5.5, on page 40,
that says,

     [...]  Thus, the recipient of an EAP message can be assured that
|  the message it just received is the one just sent by the other Peer
   and not a replay, since it contains a valid MIC of the recipient's
|  nonce and the other Peer nonce.  As before, the extent of replay
   protection is commensurate with the security of the KDF used to
   derive the MIC, the length and entropy of the shared secret used by
   the KDF, and the length of the MIC.

should better say:

     [...]  Thus, the recipient of an EAP message can be assured that
|  the message it just received is the one just sent by the other party
   and not a replay, since it contains a valid MIC of the recipient's
|  nonce and the other party's nonce.  As before, the extent of replay
   protection is commensurate with the security of the KDF used to
   derive the MIC, the length and entropy of the shared secret used by
   the KDF, and the length of the MIC.


(15)  Section 8.1 -- outdated Normative Reference

On page 45, the ref. [SHA1] should better point to the current
version, "FIPS 180-2 (with Change Notice)", February 2004.

It should say:

[not submitted]

Notes:

from pending
--VERIFIER NOTES--
Repeticious and unnecessary reports.

RFC 4778, "Operational Security Current Practices in Internet Service Provider Environments", January 2007

Source of RFC: opsec (ops)

Errata ID: 833
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-02-15
Rejected by: Merike Kaeo

 

(2)  Section 2.1.2 -- typo

The final paragraph of Section 2.1.2, on page 9, says:

|  How ISPs manage these logins vary greatly, although many of the
   larger ISPs employ some sort of AAA mechanism to help automate
   privilege-level authorization and utilize the automation to bypass
   the need for a second authentication step.  [...]

It should say:
                                   vvv
|  How ISPs manage these logins varies greatly, although many of the
   larger ISPs employ some sort of AAA mechanism to help automate
   privilege-level authorization and utilize the automation to bypass
   the need for a second authentication step.  [...]


(3)  Section 2.2 -- typo

The first paragraph of Section 2.2, on page 10, says:

                         [...].  Note that while many of the security
   concerns and practices are the same for OOB management and in-band
   management, most ISPs prefer an OOB management system, since access
|  to the devices that make up this management network are more
   vigilantly protected and considered to be less susceptible to
   malicious activity.

It should say:

                         [...].  Note that while many of the security
   concerns and practices are the same for OOB management and in-band
   management, most ISPs prefer an OOB management system, since access
|  to the devices that make up this management network is more
   vigilantly protected and considered to be less susceptible to
   malicious activity.


(4)  Section 2.2.2 -- typo, and mis-wording

(4a)
Within Section 2.2.2, the 4th paragraph on page 13 says:

                                             [...].  Most large ISPs
   have multiple SNMP systems accessing their routers so it takes more
|  then one maintenance period to get all the strings fixed in all the
   right systems.  SNMP RW is not used and is disabled by configuration.
     ^
It should say:

                                             [...].  Most large ISPs
   have multiple SNMP systems accessing their routers so it takes more
|  than one maintenance period to get all the strings fixed in all the
   right systems.  SNMP RW is not used and is disabled by configuration.

(4b)
The next (5th) paragraph on page 13 says:

   Access control is strictly enforced for infrastructure devices by
|  using stringent filtering rules.  A limited set of IP addresses are
   allowed to initiate connections to the infrastructure devices and are
|  specific to the services to which they are to limited (i.e., SSH and
   SNMP).
                                             ^^^^
I suspect that it was intended to say:

   Access control is strictly enforced for infrastructure devices by
|  using stringent filtering rules.  A limited set of IP addresses is
|  allowed to initiate connections to the infrastructure devices, and
|  these addresses are specifically limited to the respective services
|  (i.e., SSH and SNMP).

(or use similar wording).


(5)  Section 2.2.3 -- word twister

In Section 2.2.3, on page 15, the 3rd bullet says:

   o  Data Origin Authentication - Management traffic is strictly
      filtered to allow only specific IP addresses to have access to the
|     infrastructure devices.  This does not alleviate risk the from
      spoofed traffic, although when combined with edge filtering using
      BCP38 [RFC2827] and BCP84 [RFC3704] guidelines (discussed in
      Section 2.5), then the risk of spoofing is mitigated, barring a
      compromised internal system.  [...]

It should say:

   o  Data Origin Authentication - Management traffic is strictly
      filtered to allow only specific IP addresses to have access to the
|     infrastructure devices.  This does not alleviate the risk from
      spoofed traffic, although when combined with edge filtering using
      BCP38 [RFC2827] and BCP84 [RFC3704] guidelines (discussed in
      Section 2.5), then the risk of spoofing is mitigated, barring a
      compromised internal system.  [...]


(6)  Section 2.3 -- typo

The 1st sentence of Section 2.3, on top of page 16, says:

   This section refers to how traffic is handled that traverses the
|  network infrastructure device.  [...]

It should say:

   This section refers to how traffic is handled that traverses the
|  network infrastructure devices.  [...]
                                ^

(7)  Section 2.3.4 -- typo

The last paragraph of Section 2.3.4, on page 18, says:

                                        [...].  One such example is at
|  edge boxes, where up to 1000 T1s connecting into a router with an
   OC-12 (Optical Carrier) uplink.  [...]
                                           ^^^
It should say:

                                        [...].  One such example is at
|  edge boxes, where up to 1000 T1s connect into a router with an OC-12
   (Optical Carrier) uplink.  [...]


(8)  Section 2.5.2 -- typos

(8a)
The first paragraph of Section 2.5.2, on page 24, says:

   Images and configurations are stored on specific hosts that have
   limited access.  All access and activity relating to these hosts are
|  authenticated and logged via AAA services.  When uploaded/downloading
   any system software or configuration files, either TFTP, FTP, or SCP
   can be used.  Where possible, SCP is used to secure the data transfer
   and FTP is generally never used.  All SCP access is username/password
   authenticated but since this requires an interactive shell, most ISPs
   will use shared key authentication to avoid the interactive shell.
   While TFTP access does not have any security measures, it is still
   widely used, especially in OOB management scenarios.  Some ISPs
|  implement IP-based restriction on the TFTP server, while some custom
   written TFTP servers will support MAC-based authentication.  The
   MAC-based authentication is more common when using TFTP to bootstrap
   routers remotely.

It should say:

   Images and configurations are stored on specific hosts that have
   limited access.  All access and activity relating to these hosts are
|  authenticated and logged via AAA services.  When uploading /
   downloading any system software or configuration files, either TFTP,
   FTP, or SCP can be used.  Where possible, SCP is used to secure the
   data transfer and FTP is generally never used.  All SCP access is
   username/password authenticated but since this requires an
   interactive shell, most ISPs will use shared key authentication to
   avoid the interactive shell.  While TFTP access does not have any
   security measures, it is still widely used, especially in OOB
|  management scenarios.  Some ISPs implement IP-based restrictions on
   the TFTP server, while some custom written TFTP servers will support
   MAC-based authentication.  The MAC-based authentication is more
   common when using TFTP to bootstrap routers remotely.

(8b)
The second paragraph of Section 2.5.2, on page 24, says:

   [...]                      v     vv
|  In at least one environment these, tools are Kerberized to take
   advantage of automated authentication (not confidentiality).
   'Rancid' is one popular publicly available tool for detecting
   configuration and system changes.

It should say:

   [...]                      vv     v
|  In at least one environment, these tools are Kerberized to take
   advantage of automated authentication (not confidentiality).
   'Rancid' is one popular publicly available tool for detecting
   configuration and system changes.


(9)  Appendix A.2 -- typo

The second bullet in Appendix A.2, on page 34, says:
                             vvvvvvvvvv
|  o  IP Source Route Option can allows attackers to establish stealth
      TCP connections.

It should say:

|  o  IP Source Route Option can allow attackers to establish stealth
      TCP connections.

It should say:

[not submitted]

Notes:

Merike Kaeo wrote:
"The spelling/typos I'm not so sure make that much of a difference for anyone reading them and would prefer that they not be used."

from pending

RFC 4791, "Calendaring Extensions to WebDAV (CalDAV)", March 2007

Note: This RFC has been updated by RFC 5689, RFC 6638, RFC 6764, RFC 7809, RFC 7953, RFC 8996

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 4152
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hiroaki KAWAI
Date Reported: 2014-11-05
Rejected by: Barry Leiba
Date Rejected: 2015-02-06

Section 7.8.1 says:

   BEGIN:VEVENT
   DTSTART;TZID=US/Eastern:20060102T120000
   DURATION:PT1H
   RRULE:FREQ=DAILY;COUNT=5
   SUMMARY:Event #2
   UID:00959BC664CA650E933C892C@example.com
   END:VEVENT
   BEGIN:VEVENT
   DTSTART;TZID=US/Eastern:20060104T140000
   DURATION:PT1H
   RECURRENCE-ID;TZID=US/Eastern:20060104T120000
   SUMMARY:Event #2 bis
   UID:00959BC664CA650E933C892C@example.com
   END:VEVENT
   BEGIN:VEVENT
   DTSTART;TZID=US/Eastern:20060106T140000
   DURATION:PT1H
   RECURRENCE-ID;TZID=US/Eastern:20060106T120000
   SUMMARY:Event #2 bis bis
   UID:00959BC664CA650E933C892C@example.com
   END:VEVENT
   END:VCALENDAR

It should say:

   BEGIN:VEVENT
   DTSTART;TZID=US/Eastern:20060102T120000
   DURATION:PT1H
   RRULE:FREQ=DAILY;COUNT=5
   SUMMARY:Event #2
   UID:00959BC664CA650E933C892C@example.com
   END:VEVENT
   BEGIN:VEVENT
   DTSTART;TZID=US/Eastern:20060104T140000
   DURATION:PT1H
   RECURRENCE-ID;TZID=US/Eastern:20060104T120000
   SUMMARY:Event #2 bis
   UID:00959BC664CA650E933C892C@example.com
   END:VEVENT
   END:VCALENDAR

Notes:

Remove the last VEVENT component in abcd2.ics, because it is outside of the time-range.
--VERIFIER NOTES--
The query requests the return of an entire resource (including all overridden instances) for any resource that has at least one component overlapping the time range.

RFC 4803, "Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base", February 2007

Source of RFC: ccamp (rtg)

Errata ID: 1883
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Vishwas Manral
Date Reported: 2009-09-16
Rejected by: Adrian Farrel
Date Rejected: 2010-10-30

Section MIB says:

gmplsInterfaceRsvpHelloPeriod OBJECT-TYPE
  SYNTAX       Unsigned32
  UNITS        "milliseconds"
  MAX-ACCESS   read-create
  STATUS       current
  DESCRIPTION
    "Period, in milliseconds, between sending Resource Reservation
     Protocol (RSVP) Hello messages on this interface.  A value of 0
     indicates that no Hello messages should be sent on this
     interface.

     This object is only valid if gmplsInterfaceSignalingCaps has no
     bits set or includes the rsvpGmpls bit."
  REFERENCE
    "1. RSVP-TE: Extensions to RSVP for LSP Tunnels, RFC 3209,
        section 5.
     2. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473,
        section 9.3."
  DEFVAL { 3000 }
::= { gmplsInterfaceEntry 2 }

It should say:

gmplsInterfaceRsvpHelloPeriod OBJECT-TYPE
  SYNTAX       Unsigned32
  UNITS        "milliseconds"
  MAX-ACCESS   read-create
  STATUS       current
  DESCRIPTION
    "Period, in milliseconds, between sending Resource Reservation
     Protocol (RSVP) Hello messages on this interface.  A value of 0
     indicates that no Hello messages should be sent on this
     interface.

     This object is only valid if gmplsInterfaceSignalingCaps has no
     bits set or includes the rsvpGmpls bit."
  REFERENCE
    "1. RSVP-TE: Extensions to RSVP for LSP Tunnels, RFC 3209,
        section 5.
     2. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473,
        section 9.3."
  DEFVAL { 5 }
::= { gmplsInterfaceEntry 2 }

Notes:

The default value is changed. The default value specified in the RFC is 5ms. Section 5.3 states:

This value MAY be configured on a per neighbor basis. The default value is 5 ms.
--VERIFIER NOTES--
After discussion on the CCAMP mailing list it was agreed that the MIB module text is as intended, and is deliberately different from the value in the protocol specification.

RFC 4820, "Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP)", March 2007

Source of RFC: tsvwg (wit)

Errata ID: 897
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-04-09
Rejected by: Lars Eggert
Date Rejected: 2009-01-14

Section 3 says:

   This chunk is used to pad an SCTP packet.  A PAD chunk can be used to
   enlarge the packet by 4 to 65536 bytes in steps of 4 bytes.  An SCTP
   packet MAY contain multiple PAD chunks.

It should say:

   This chunk is used to pad an SCTP packet.  A PAD chunk can be used to
   enlarge the packet by 4 to 65532 bytes in steps of 4 bytes.  An SCTP
   packet MAY contain multiple PAD chunks.

Notes:

The text below Figure 1 explains:

"Length: 2 bytes (unsigned integer)
This value holds the length of the Padding Data plus 4"

Because a 2-byte unsigned integer can accept values ranging
from 0 to 65535 and it can be inferred from the above text that
`Length` should be divisible by 4, the maximum value possible
for `Length`, and hence the maximum padding size is 65532 !

(In the spirit of the SCTP specification, I do not recommend to
change the definition of `Length` allowing 0 to encode 65536.)
--VERIFIER NOTES--
Discussion between authors and errata submitter resulted in an agreement that this errata is in fact incorrect.

RFC 4821, "Packetization Layer Path MTU Discovery", March 2007

Note: This RFC has been updated by RFC 8899

Source of RFC: pmtud (tsv)

Errata ID: 907
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ron Broersm
Date Reported: 2007-04-15
Rejected by: Matt Mathis
Date Rejected: 2007-04-15

Section 8 says:

   Since protocols that do not implement PLPMTUD are still subject to
   problems due to ICMP black holes, it may be desirable to limit to
   these protocols to "safe" MTUs likely to work on any path (e.g., 1280
   bytes).  Allow any protocol implementing PLPMTUD to operate over the
   full range supported by the lower layer.

There is an extra "to" in the first sentence.  It should read "...it may
be desirable to limit these protocols to safe MTUs....".

In the last one of the references at the end.....

   [frag-errors]   Heffner, J., "IPv4 Reassembly Errors at High Data
                   Rates", Work in Progress, December 2007.


The year is clearly wrong.

It should say:

[not submitted]

Notes:

Ooops, we all missed these....

I don't think these warrant errata, but that is your call..

Thanks,
--MM--

from pending

RFC 4842, "Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP)", April 2007

Source of RFC: pwe3 (int)

Errata ID: 981
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-17
Rejected by: Ron Cohen
Date Rejected: 2007-05-17

 

(0)  Title of the RFC <--> Scope / applicability (Section 2)

The second paragraph of Section 2 says:

   This document provides encapsulation formats and semantics for
|  emulating SONET/SDH circuits and services over MPLS packet-switched
   networks (PSNs).  [...]
                                                  ^^^^

Up to now, pseudowire encapsulations (and signaling protocol elements)
have been defined for MPLS and L2TPv3 in the data plane.

Previous PWE3 documents had developed a clear language for their scope,
saying (omitting the canonical expansion of acronyms),
   "... over MPLS [Networks]",
   "... over L2TPv3",           or
   "... over Packet [Networks]" iff applicable to MPLS *and* L2TPv3.

Confusingly and unfortunately, the title of RFC 4842 breaks that
clear naming scheme.


(1)  Section 4 -- acronym expansion

On page 5, Section 4 of RFC 4842 contains the lines:

                           vvvv
|  STM-n  Synchronous Transport Module-n (SDH)
   STS-n  Synchronous Transport Signal-n (SONET)

I'm getting confused.
>From most publicly available sources, I've been accustomed to expect:

                           vvv
|  STM-n  Synchronous Transfer Module-n (SDH)
   STS-n  Synchronous Transport Signal-n (SONET)

So, what's true?  Please check.


(2)  Section 5.2 -- missing article

The first paragraph of Section 5.2, near the bottom of page 7, says:
                                           v
|  The CEP header supports both a basic and extended mode.  The Basic
   CEP header provides the minimum functionality necessary to accurately
   emulate a SONET/SDH circuit over a PSN.  [...]

It should say:
                                           vvvv
|  The CEP header supports both a basic and an extended mode.  The Basic
   CEP header provides the minimum functionality necessary to accurately
   emulate a SONET/SDH circuit over a PSN.  [...]


(3)  Section 5.3

(3a)  -- missing article

In the lower half of page 10, Section 5.3 contains the explanation:

   Sequence Number [0:15]:  The packet sequence number MUST continuously
      cycle from 0 to 0xFFFF.  It is generated and processed in
      accordance with the rules established in [RTP].  The CEP receiver
      MUST sequence packets according to the Sequence Number field of
|     the CEP header and MAY verify correct sequencing using RTP
      Sequence Number field.
                                                            ^
It should say:

   Sequence Number [0:15]:  The packet sequence number MUST continuously
      cycle from 0 to 0xFFFF.  It is generated and processed in
      accordance with the rules established in [RTP].  The CEP receiver
      MUST sequence packets according to the Sequence Number field of
|     the CEP header and MAY verify correct sequencing using the RTP
      Sequence Number field.
                                                            ^^^^^

(3b)  -- surprising timestamp clock frequency

The next bullet on page 10 says:

   Timestamp [0:31]:  Timestamp values are used in accordance with the
      rules established in [RTP].  Frequency of the clock used for
|     generating timestamps MUST be 19.44 MHz based on a local
      reference.
                                    ^^^^^^^^^

This frequency value is surprising (for me).
I could not derive any immediate relationship to wellknown SONET/SDH
bit or frame rates, etc. -- cf. Tables 4 & 5 in Appendix A of the RFC.
If the specified value is correct, please give me a hint on its origin;
otherwise, please have it corrected in an RFC Errata Note.


(4)  Section 10.1 -- missing article

Within Section 10.1, in the second paragraph on page 20, the RFC says:
                                  v
|  UAS-CEP SHALL be declared after configurable number of consecutive
   SES-CEP, and cleared after a configurable number of consecutive
   seconds without SES-CEP.  Default value for each is 10 seconds.

It should say:
                                  vvv
|  UAS-CEP SHALL be declared after a configurable number of consecutive
   SES-CEP, and cleared after a configurable number of consecutive
   seconds without SES-CEP.  Default value for each is 10 seconds.


(5)  Section 11.2.1.1 -- confusing bit field specifications

In Section 11.2.1.1, Figure 7 and the long paragraph extending from
the bottom of page 23 to the top of page 24 say:

   The STS-1 EBM has the following format:

       0                   1                   2
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  VTG7 |  VTG6 |  VTG5 |  VTG4 |  VTG3 |  VTG2 |  VTG1 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 7: Equipped Bit Mask (EBM) for Fractional STS-1

   The 28 bits of the EBM are divided into groups of 4 bits, each
   corresponding to a different VTG within the STS container.  All 4
   bits are used to indicate whether VT1.5 (T1) tributaries are carried
|  within a VTG.  The first 3 bits read from right to left are used to
   indicate whether VT2 (E1) tributaries are carried within a VTG.  The
|  first 2 bits are used to indicate whether VT3 (DS1C) tributaries are
|  carried within a VTG.  The rightmost bit is used to indicate whether
   a VT6 (DS2) is carried within the VTG.  The VTs within the VTG are
   numbered from right to left, starting from the first VT as the first
   bit on the right.  For example, the EBM of a fully occupied STS-1
<< page break >>>
   with VT1.5 tributaries is all ones, while that of an STS-1 fully
   occupied with VT2 (E1) tributaries has the binary value
|  0111011101110111011101110111.

Ooops!

a)
If you have a numbered bit field, e.g., the VTG7 field:

       0 1 2 3 4 5
      +-+-+-+-+-+-+-
      |  VTG7 |  ...
      +-+-+-+-+-+-

and denote the binary representation of its value accordingly:
         <vtg7> = < b0, b1, b2, b3 >,
then "The *first* 3 bits read from right to left", apparently
specifies the number with the (bit-reversed) binary representation
                  < b2, b1, b0 > .

That does not correspond to the final example given, and it is not
really compatible with the last sentence before the page break.

Similarly, "the first 2 bits" used for VT3 / DS1C would be
  < b0, b1 >  -- or should it be (again, bit-revered)  < b1, b0 >  ??

Finally, "the rightmost bit" is used for VT6 / DS2, i.e.  < b3 > .

That seems fuzzy, at best.

Assuming that the example is correct, I strongly suspect that the
'active' bit groups are intended to be right justified in the 4-bit
groups, in any case, und that thus text above in fact should say:

   The 28 bits of the EBM are divided into groups of 4 bits, each
   corresponding to a different VTG within the STS container.  All 4
   bits are used to indicate whether VT1.5 (T1) tributaries are carried
|  within a VTG.  The 3 rightmost bits in a bit group are used to
|  indicate whether VT2 (E1) tributaries are carried within a VTG.
|  The 2 rightmost bits in a bit group are used to indicate whether
|  VT3 (DS1C) tributaries are carried within a VTG.  The rightmost bit
   is used to indicate whether a VT6 (DS2) is carried within the VTG.
   The VTs within the VTG are numbered from right to left, starting from
   the first VT as the first bit on the right.  [...]

b)
Further confusion arises from the fact that the above specification
overloads the field in a four-fold way but does not give any hint
as to how this overloading is encoded / disambiguated.

I've scratched my head for quite a time, looking for the appropriate
hooks to properly decode the field.
Much later in the text, it eventually turns out that this information
must be signalled out-of-band.

For clarity and precision, this fact should have been stated clearly
within Section 11.2.1.1.


(6)  Section 11.2.1.2

There's a mismatch in the notation between the formula given in
Section 11.2.1.2, on mid-page 24, and the subsequent explanations.
The RFC says:
                                                           vvv
|     B3[i]'(t) = B3[i](t-1) || B3[i]'(t-1) || B3[i](t) || B*3[i](t-1)

|     Where:

         B3[i]   = the existing B3[i] value in the incoming signal
         B3[i]'  = the new (compensated) B3[i] value
|        B3*[i]  = the B3[i] value of the unequipped VTs in the
                   incoming signal
         ||  =  exclusive OR operator
         t   =  the time of the current frame
         t-1 =  the time of the previous frame

IMHO, the notation 'B3*[i]' , as explained is the proper notation,
and the  'B*3'  in the formula should be changed accordingly.
Furthermore, the second line should be 'editorially reworked' for
proper indentation (as the text above and below) and capitalization.

Hence, the RFC should say:
                                                           vvv
|     B3[i]'(t) = B3[i](t-1) || B3[i]'(t-1) || B3[i](t) || B3*[i](t-1)

|   where:

         B3[i]   = the existing B3[i] value in the incoming signal
         B3[i]'  = the new (compensated) B3[i] value
         B3*[i]  = the B3[i] value of the unequipped VTs in the
                   incoming signal
         ||  =  exclusive OR operator
         t   =  the time of the current frame
         t-1 =  the time of the previous frame


(7)  Section 11.2.2.1 -- missing article

The last paragraph of Section 11.2.2.1, at the bottom of page 25,
says:

   A T3 is encapsulated asynchronously into a VC-3 container as
|  described in Section 10.1.2.1 of [G.707].  VC-3 container has only 85
   data columns, which is identical to the STS-1 container with the two
   fixed stuff columns 30 and 59 removed.  Other than that, the mapping
   is identical.

It should say:
                                              vv
   A T3 is encapsulated asynchronously into a VC-3 container as
|  described in Section 10.1.2.1 of [G.707].  A VC-3 container has only
   85 data columns, which is identical to the STS-1 container with the
   two fixed stuff columns 30 and 59 removed.  Other than that, the
   mapping is identical.


(8)  Section 11.2.3.1 -- onother missing article

The third paragraph of Section 11.2.3.1, near the bottom of page 27,
says:
                                                               v
|  [...].  This is the equivalent of multiplexing 7 VTGs within STS-1
   container in SONET terminology, except for the location of the fixed
   columns.

It should say:
                                                               vvvv
|  [...].  This is the equivalent of multiplexing 7 VTGs within an STS-1
   container in SONET terminology, except for the location of the fixed
   columns.


(9)  Section 11.2.3.2

(9a)  -- bad term / extraneous word

The first paragraph of Section 11.2.3.2, on top of page 28, says:

   The fractional VC-4 CEP header uses the VC-4 CEP header defined in
   this document.  Optionally, an additional 12-byte header extension
|  word is added.
   ^^^^^
It should say:

   The fractional VC-4 CEP header uses the VC-4 CEP header defined in
   this document.  Optionally, an additional 12-byte header extension
|  is added.

Rationale:  There are no such "12-byte words", AFAICS.

(9b)  -- confusing bit field specifications, again

Similar issues as explained in item (5) above also hold for the (long)
second paragraph below Figure 10, on mid-page 29.
Again, I strongly suspect that the text,

      [...].  All 4 bits are used to indicate whether VC-11 (T1)
|  tributaries are carried within a TUG-2.  The first 3 bits read right
|  to left are used to indicate whether VC-12 (E1) tributaries are
|  carried within a TUG-2.  The first bit is used to indicate that a
   VC-2 is carried within a TUG-2.  The VCs within the TUG-2 are
   numbered from right to left, starting from the first VC as the first
   bit on the right.  For example, [...]

in fact should say:

      [...].  All 4 bits are used to indicate whether VC-11 (T1)
|  tributaries are carried within a TUG-2.  The rightmost 3 bits are
   used to indicate whether VC-12 (E1) tributaries are carried within a
|  TUG-2.  The rightmost bit is used to indicate that a VC-2 is carried
   within a TUG-2.  The VCs within the TUG-2 are numbered from right to
   left, starting from the first VC as the first bit on the right.  For
   example, [...]

(9c)  -- typo / singular/plural mismatch

The last paragraph of Section 11.2.3.2, near the bottom of page 29,
says:
                                     vv
|           [...].  The A bit indicate the reason for removal of the
   entire TUG-3 columns.  [...]

It should say:
                                     vvv
|           [...].  The A bit indicates the reason for removal of the
   entire TUG-3 columns.  [...]


(10)  Section 12  -- item (0) and its bad consequences

In Section 12, we unfortunately return to the issue explained in
item (0) above.

Within Section 12, the first paragraph on page 31 says:

   The PW Type field in PWid Forwarding Equivalence Class (FEC) and PW
|  generalized ID FEC elements MUST be set to SONET/SDH Circuit
|  Emulation over Packet (CEP) [PWE3-IANA].

In RFC 4446 [PWE3-IANA], on page 3, I find *two* assignments:

   PW type Description                                      Reference
   ===================================================================
   0x0008  SONET/SDH Circuit Emulation Service Over MPLS    [CEP]
   0x0010  SONET/SDH Circuit Emulation over Packet          [CEP]

Hence, apparently Section 12 refers to PW type 0x0010.

Because there is an independent 'PW type' namespace for L2TPv3 and
RFC 4446 was MPLS-specific (although its title didn't say so!),
it could be concluded from the above that PW type 0x0010 was
intended for use over MPLS *and* L2TPv3, with a corresponding
assignment for L2TPv3 to be performed in another document, whereas
PW type 0x0008 apparently was reserved for an MPLS specific CEP
solution, and both were expected to be specified in the same document.

Since RFC 4842 is MPLS-only, it could be expected that it would
make use of that MPLS-specific PW type, 0x0008, not of 0x0010 !
Therefore, the above quoted text in Section 12 comes to great
surprise!

The IANA registry (today) still lists theses two lines as above,
where [CEP] is:

  [CEP]    "SONET/SDH Circuit Emulation Service Over Packet (CEP)",
           draft-ietf-pwe3-sonet-11.txt (work in progress)

Therefore:  What's the matter here ?

Apparently, RFC 4842 *is* the successor ot that I-D.

Has PW type 0x0008 been abandoned ?
Or is Section 12 wrong, and it should refer to PW type 0x0008 ?

In former case, the IANA registry should be updated, deprecating and
perhaps permanently reserving 0x0008, and 0x0010 should be renamed
to reflect its use (and all that should have been noted in Section 15
of RFC 4842!), e.g.:

   PW type Description                                      Reference
   ===================================================================
   0x0008  - deprecated - / -reserved -                     [IESG]
   0x0010  SONET/SDH Circuit Emulation over MPLS            [RFC4842]


(11)  Section 15 -- omissions

As explained in the preceding item, IANA has not properly updated
the pwe3-parameters registry upon publication od RFC 4842.

This is certainly due to missing instructions in Section 15,
which merely states (on page 35):

   IANA considerations for pseudowires are covered in [PWE3-IANA].  CEP
   does not introduce additional requirements from IANA.

This section should have been instructed to link one of the above
mentioned PW types to RFC 4842, and perform the intended disposition
with the other one.

Whatever the plans currently are, the IANA registry should be
updated accordingly and as soon as possible, to reduce the confusion.


(12)  Appendix A -- incomplete information

On mid-page 36, just below Table 4, Appendix A says:

   [...]
   A number of STS-1s may also be linked together to form a super-rate
|  signal with only one SPE.  The optical super-rate signal is denoted
   as OC-Nc, which has a higher payload capacity than OC-N.

For completeness and clarity, the super-rate signal mentioned should
be named.  According to the layman's guess (please correct if I am
wrong!), the RFC should say:

   [...]
   A number of STS-1s may also be linked together to form a super-rate
|  signal denoted STS-Nc, with only one SPE.  The optical super-rate
   signal is denoted as OC-Nc, which has a higher payload capacity than
   OC-N.

It should say:

[see above]

Notes:

Authors sent email about those that should be posted. They were posted as verified; the others are rejected.

from pending

RFC 4848, "Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)", April 2007

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 2158
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hadriel Kaplan
Date Reported: 2010-04-11
Rejected by: Pete Resnick
Date Rejected: 2011-08-04

Section 2.2 says:

        u-naptr-regexp = "!.*!"<URI>"!"

It should say:

        u-naptr-regexp = "!.*!<URI>!"

Notes:

The extra double-quotes in the replacement portion of the substitution expression are erroneous, right?
--VERIFIER NOTES--
The current text is correct.

RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", September 2007

Note: This RFC has been updated by RFC 5942, RFC 6980, RFC 7048, RFC 7527, RFC 7559, RFC 8028, RFC 8319, RFC 8425, RFC 9131

Source of RFC: ipv6 (int)

Errata ID: 3367
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Ron Bonica
Date Reported: 2012-09-27
Rejected by: Brian Haberman
Date Rejected: 2013-05-31

Section 4.2 says:

   Routers send out Router Advertisement messages periodically, or in
   response to Router Solicitations.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |     Code      |          Checksum             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Cur Hop Limit |M|O|  Reserved |       Router Lifetime         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Reachable Time                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Retrans Timer                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Options ...
     +-+-+-+-+-+-+-+-+-+-+-+-

   IP Fields:

      Source Address
                     MUST be the link-local address assigned to the
                     interface from which this message is sent.

      Destination Address
                     Typically the Source Address of an invoking Router
                     Solicitation or the all-nodes multicast address.

      Hop Limit      255

   ICMP Fields:

      Type           134

      Code           0

      Checksum       The ICMP checksum.  See [ICMPv6].

      Cur Hop Limit  8-bit unsigned integer.  The default value that
                     should be placed in the Hop Count field of the IP
                     header for outgoing IP packets.  A value of zero
                     means unspecified (by this router).

      M              1-bit "Managed address configuration" flag.  When
                     set, it indicates that addresses are available via
                     Dynamic Host Configuration Protocol [DHCPv6].

                     If the M flag is set, the O flag is redundant and
                     can be ignored because DHCPv6 will return all
                     available configuration information.

      O              1-bit "Other configuration" flag.  When set, it
                     indicates that other configuration information is
                     available via DHCPv6.  Examples of such information
                     are DNS-related information or information on other
                     servers within the network.

        Note: If neither M nor O flags are set, this indicates that no
        information is available via DHCPv6.

It should say:

   Routers send out Router Advertisement messages periodically, or in
   response to Router Solicitations.

    0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Code      |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Cur Hop Limit |M|O|H|Prf|Resvd|       Router Lifetime         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Reachable Time                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Retrans Timer                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Options ...
      +-+-+-+-+-+-+-+-+-+-+-+-


   IP Fields:

      Source Address
                     MUST be the link-local address assigned to the
                     interface from which this message is sent.

      Destination Address
                     Typically the Source Address of an invoking Router
                     Solicitation or the all-nodes multicast address.

      Hop Limit      255

   ICMP Fields:

      Type           134

      Code           0

      Checksum       The ICMP checksum.  See [ICMPv6].

      Cur Hop Limit  8-bit unsigned integer.  The default value that
                     should be placed in the Hop Count field of the IP
                     header for outgoing IP packets.  A value of zero
                     means unspecified (by this router).

      M              1-bit "Managed address configuration" flag.  When
                     set, it indicates that addresses are available via
                     Dynamic Host Configuration Protocol [DHCPv6].

                     If the M flag is set, the O flag is redundant and
                     can be ignored because DHCPv6 will return all
                     available configuration information.

      O              1-bit "Other configuration" flag.  When set, it
                     indicates that other configuration information is
                     available via DHCPv6.  Examples of such information
                     are DNS-related information or information on other
                     servers within the network.

      H

                     The Home Agent (H) bit is set in a Router Advertisement  
                     to indicate that the router sending this Router 
                     Advertisement is also functioning as a Mobile IPv6 
                     home agent on this link. [RFC3775]

        Prf 
                     2-bit default router preference, encoded as follows:

                       01      High
                       00      Medium (default)
                       11      Low
                       10      Reserved - MUST NOT be sent

                     Indicates whether to prefer this router over other 
                    default routers.  If the Router Lifetime is zero, the
                    preference value MUST be set to (00) by the
                    sender and MUST be ignored by the receiver.  If the
                    Reserved (10) value is received, the receiver MUST 
                    treat the value as if it were (00). [RFC4191]


        Note: If neither M nor O flags are set, this indicates that no
        information is available via DHCPv6.


 

Notes:

Contents of RFC 3775 and 4191 were not brought forward into RFC 4861
--VERIFIER NOTES--
OBE

RFC 4871, "DomainKeys Identified Mail (DKIM) Signatures", May 2007

Note: This RFC has been obsoleted by RFC 6376

Note: This RFC has been updated by RFC 5672

Source of RFC: dkim (sec)

Errata ID: 1385
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Murray S. Kucherawy
Date Reported: 2008-03-23
Rejected by: Pasi Eronen
Date Rejected: 2010-02-11

Section 3.6.1 says:

It is expected that many key servers will choose to present the keys in an
otherwise unstructured text format (for example, an XML form would not be
considered to be unstructured text for this purpose).  The following definition
MUST be used for any DKIM key represented in an otherwise unstructured textual
form.

It should say:

It is expected that many key servers will choose to present the keys in an
otherwise unstructured text format (for example, an XML form would not be
considered to be unstructured text for this purpose).  The following definition
MUST be used for any DKIM key represented in an otherwise unstructured textual
form.

The TXT RDATA format is described in section 3.3.14 of RFC1035.  If the retrieved
TXT record consists of more than one "character-string" (as defined in that
document), the RDATA MUST be preprocessed by concatenating all of the
"character-string"s together in the order in which they appeared in the RDATA
before being interpreted as described below.

Notes:

No guidance is provided about how to handle a single TXT RDATA which is subdivided into multiple character-strings, such as an encoded public key that is too large to fit in such a construct (which is limited by RFC1035 to be each 255 characters or less).
--VERIFIER NOTES--
Section 3.6.2.2 already specifies the necessary details.

Errata ID: 1942
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Murray S. Kucherawy
Date Reported: 2009-11-11
Rejected by: Pasi Eronen
Date Rejected: 2010-03-01

Section 3.4.4 says:

The "relaxed" body canonicalization algorithm:

It should say:

The "relaxed" body canonicalization algorithm MUST apply the following 
steps in order:

Notes:

The order of the steps should be enforced, as in section 3.4.2. I have two disagreeing interpretations that have resulted in an interoperability problem (fortunately a corner case), namely:

<CRLF><CRLF><SP><SP><CRLF> should be canonicalized as what? Taken top-to-bottom, the output is the empty body; given the other pending errata, the output should be a single <CRLF>; yet another interpretation strips trailing <CRLF>s first, then does space trimming, leaving the output as <CRLF><CRLF><CRLF>.

I might further suggest changing these steps to an enumerated/ordered list instead of a list of bullet points.
--VERIFIER NOTES--
Duplicate; this issue is already covered by errata 1384.

RFC 4872, "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", May 2007

Note: This RFC has been updated by RFC 4873, RFC 6780, RFC 9270

Source of RFC: ccamp (rtg)

Errata ID: 934
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-07
Rejected by: Adrian Farrel
Date Rejected: 2010-10-30

Section 17 says:

   This section presents the RSVP message-related formats as modified by
   this document.  Unmodified RSVP message formats are not listed.

It should say:

   This section presents the RSVP-TE message-related formats as modified
   by this document.  Unmodified RSVP-TE message formats are not listed.

Notes:

The first paragraph of Section 17 does not confine the scope of the
specification as it would be appropriate.

'Classic' RSVP (RFC 2205) is neither covered nor affected by the subsequently specified message formats.

from pending
--VERIFIER NOTES--
Compare with Erratum 945.

Same reason for rejection...

Although it is true that there is some common distinction between "classic" RSVP and RSVP-TE, the IP protocol number is the same, and the message numbers (and registry) are the same. In essence, there is just one protocol with two uses.

Errata ID: 3304
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Lyndon Ong
Date Reported: 2012-07-31
Rejected by: Adrian Farrel
Date Rejected: 2012-08-09

Section 11 & 12 says:

Section 11 says:


   (Full) LSP rerouting will be initiated by the head-end node that has
   either detected the LSP failure or received a Notify message and/or a
   PathErr message with the new error code/sub-code "Notify Error/LSP
   Locally Failed" for this LSP.  The new LSP resources can be
   established using the make-before-break mechanism, where the new LSP
   is set up before the old LSP is torn down.  This is done by using the
   mechanisms of the SESSION_ATTRIBUTE object and the Shared-Explicit
   (SE) reservation style (see [RFC3209]).  Both the new and old LSPs
   can share resources at common nodes.

Section 12 says:

   [No text on reversion for (full) LSP Rerouting.]

It should say:

Section 11 should say:


   (Full) LSP rerouting will be initiated by the head-end node that has
   either detected the LSP failure or received a Notify message and/or a
   PathErr message with the new error code/sub-code "Notify Error/LSP
   Locally Failed" for this LSP.  The new LSP resources can be
   established using the make-before-break mechanism, where the new LSP
   is set up before the old LSP is torn down.  This is done by using the
   mechanisms of the SESSION_ATTRIBUTE object and the Shared-Explicit
   (SE) reservation style (see [RFC3209]).  Both the new and old LSPs
   can share resources at common nodes.  The new LSP can be established
   without tearing down the old LSP in case of reversion (see section 12).

Section 12 should say:

   For "(full) LSP Rerouting", reversion implies that the old LSP is not 
   torn down by the head-end node after the new LSP is established. For
   reversion, the head-end node re-activates the old LSP after this has
   recovered.

Notes:

Current text in RFC 4872 describes reversion in the cases of 1+1 bidirectional Protection, 1:N Protection with Extra Traffic and Rerouting Without Extra Traffic, however it has no description of reversion with (Full) LSP Rerouting.
For (full) LSP Rerouting, the description in Section 11 instead implies that the old LSP is torn down. This has led to some confusion as to whether reversion with (full) LSP Rerouting is allowed or not allowed by the RFC. We believe this was not intentional. The additions would make it clear that reversion can be supported with (Full) LSP Rerouting.
--VERIFIER NOTES--
After discussions on the CCAMP mailing list it is the general opinion of the CCAMP WG that there is no technical issue and that if any WG participants wish to document how the current mechanisms can be used to support a particular usage/application that they are free to do so in a new informational draft.

RFC 4873, "GMPLS Segment Recovery", May 2007

Note: This RFC has been updated by RFC 9270

Source of RFC: ccamp (rtg)

Errata ID: 936
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-08
Rejected by: Adrian Farrel
Date Rejected: 2010-10-30

Section 4.2.3 says:

  In general, objects in a recovery LSP are created based on the
  corresponding objects in the LSP being protected.  [...]

It should say:

[not submitted]

Notes:

IMHO makes use of too sluggish language; talking about
"objects in a recovery LSP" or "objects in the LSP being protected"
should be avoided because it messes up the essentials of [G]MPLS,
the separation of the data plane carrying arbitrary labeled data
packets and the control plane (with RSVP-TE carrying the TE objects).
Unfortunately, similar language recurs at other places in the RFC;
for the sake of brevity, I refrain from listing all those instances
below.

I would appreciate very much future derived and/or related work to
return to a more precise language.

from pending
--VERIFIER NOTES--
There has long been a conflation of "LSP" to mean the data plane entity (connection) and the also the control plane state necessary to maintain the data plane entity. The body of people working in the MPLS and CCAMP working groups are used to this and can readily deduce which meaning is intended. Additional text is added when the author believes it is important to make an explicity distinction.

Since this Erratum is not specifically actionable on this RFC, it is rejected.

Errata ID: 944
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-08
Rejected by: Adrian Farrel
Date Rejected: 2010-10-30

 

The rules given in the two paragraphs on top of page 18,

   The resulting Path message is used to create the recovery LSP.  While
   the recovery LSP exists, the PROTECTION object in the original Path
   message  (unless overridden by local policy) MUST also be updated
   with the In-Place bit set (1).  From this point on, Standard Path
   message processing is used in processing the resulting and original
   Path messages.

   The merge node of a dynamically controlled recovery LSP SHOULD reset
   (0) the In-Place bit in the PROTECTION object of the outgoing Path
   message associated with the terminated recovery LSP.

apparently make dynamic 'overlapping' segment protection impossible.

One scenario that came to my mind was node failure protection
envisioned to be implemented by recovery LSPs for the primary LSP
A-B-C-D-E-F-G, depicted as follows:

                  H ----- I   J ----- K
                 /         \ /         \
          A --- B --- C --- D --- E --- F --- G
           \         / \         / \         /
            L ----- M   N ----- O   P ----- Q

The specified rules apparently inhibit the setup of such overlapping
segment protection LSPs.  Has this been intended ?

It should say:

[see above]

Notes:

from pending
--VERIFIER NOTES--
This is not an Erratum. If there is technical discussion to be had about the function enabled or prohibited by the specification, and the requirements for the provision of services in a network, these need to be taken to the CCAMP mailing list and might result in a revision to the RFC or a new draft.

Errata ID: 945
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-08
Rejected by: Adrian Farrel
Date Rejected: 2010-10-30

Section 7 says:

   This section presents the RSVP message related formats as modified by
   this document.  Where they differ, formats for unidirectional LSPs
   are presented separately from bidirectional LSPs.

It should say:

   This section presents the RSVP-TE message related formats as modified
   by this document.  Where they differ, formats for unidirectional LSPs
   are presented separately from bidirectional LSPs.

Notes:

Does not confine the scope of the specification as it
would be appropriate.

'Classic' RSVP (RFC 2205) is neither covered nor affected by the
subsequently specified (extended) message formats.

from pending
--VERIFIER NOTES--
Although it is true that there is some common distinction between "classic" RSVP and RSVP-TE, the IP protocol number is the same, and the message numbers (and registry) are the same. In essence, there is just one protocol with two uses.

RFC 4875, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", May 2007

Note: This RFC has been updated by RFC 6510

Source of RFC: mpls (rtg)

Errata ID: 961
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Rejected by: Adrian Farrel
Date Rejected: 2010-08-21

 

(1)  Section 4.5 -- syntax / punctuation issue

In the first paragraph of Section 4.5, on page 7, RFC 4875 says:
                                           vv
|           [...].  The < [<EXPLICIT_ROUTE>], <S2L_SUB_LSP> > tuple
   represents the S2L sub-LSP and is referred to as the sub-LSP
   descriptor.  [...]

Obviously, the tagged comma should be *inside* the square brackets:
                                           vv
|           [...].  The < [<EXPLICIT_ROUTE>,] <S2L_SUB_LSP> > tuple
   represents the S2L sub-LSP and is referred to as the sub-LSP
   descriptor.  [...]

The same issue recurs in the third paragraph of Section 4.5, on the
same page.

At similar places in the RFC, e.g. in the first paragraph of
Section 5.2.1, the comma is omitted entirely in the tuple notation.
That is very unusual.


(2)  Section 5.2.1 -- typo (text reformatting problem ?)

In the 5th line of the last-paragraph of Section 5.2.1,
    "Sub- Group"   should be spelled   "Sub-Group" .


(3)  Section 6.1 -- bad internal reference, and missing article

Within Section 6.1, the first text lines on page 17 say:

|  The S2L sub-LSP flow descriptor has the same format as S2L sub-LSP
|  descriptor in section 4.1 with the difference that a
   P2MP_SECONDARY_RECORD_ROUTE object is used in place of a P2MP
   SECONDARY_EXPLICIT_ROUTE object.  [...]

The RFC should say, inserting the missing article and correcting
the reference to point to Section 5.1 :

|  The S2L sub-LSP flow descriptor has the same format as the S2L
|  sub-LSP descriptor in section 5.1 with the difference that a
   P2MP_SECONDARY_RECORD_ROUTE object is used in place of a P2MP
   SECONDARY_EXPLICIT_ROUTE object.  [...]


(4)  Section 6.2 -- missing article

The second paragraph of Section 6.2, on mid-page 17, says:

                                 [...].  When the integrity bit is set
|  in the LSP_REQUIRED_ATTRIBUTE object, Resv message MUST NOT be sent
   upstream until all Resv messages have been received from the
   downstream neighbors.

It should say:

                                 [...].  When the integrity bit is set
|  in the LSP_REQUIRED_ATTRIBUTE object, a Resv message MUST NOT be sent
   upstream until all Resv messages have been received from the
   downstream neighbors.


(5)  Section 8.2 -- text duplication and inconsistency

The second paragraph of Section 8.2 (on page 23),

   A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC
   object(s) of a Resv message to the value that was received in the
   corresponding Path message.  If any of the incoming Resv messages
   corresponding to a single Path message carry a RESV_CONFIRM object,
   then the LSR MUST include a RESV_CONFIRM object in the corresponding
   Resv message that it sends upstream.  If the Sub-Group Originator ID
   is its own address, then it MUST set the receiver address in the
   RESV_CONFIRM object to this address, else it MUST propagate the
   object unchanged.

should be deleted entirely !

Rationale:
  The first two sentences in this paragraph are repeated almost
  literally in the subsequent (third) paragraph of the section.
  The third (last) sentence above essentially is superseeded, in
  a more precise manner, by the second and the third bullet at the
  bottom of page 23.
  But, perhaps most importantly, the first bullet there handles a
  subcase not covered by, and hence mis-specified, by that sentence!

  Apparently, the lower half of page 23 is a revised revision of
  the quoted second paragraph, which should have been deleted.


(6)  Section 10.2 -- clarification including mismatched angle
                     brackets, word omissions, and punctuation

Within Section 10.2, the third paragraph on page 26 says:

   [...]
|  A newly received Path message that matches SESSION object and Sender
   Tunnel Address, LSP ID, Sub-Group Originator ID> with existing Path
|  state carrying the same or different Sub-Group_ID, referred to Sub-
|  Group_ID(n) is processed as follows:

It should say:

   [...]
|  A newly received Path message that matches in SESSION object and
|  <Sender Tunnel Address, LSP ID, Sub-Group Originator ID> with
|  existing Path state carrying the same or a different Sub-Group_ID,
|  referred to as Sub-Group_ID(n), is processed as follows:

Or even better, a bit reworded for enhanced readability:

   [...]
|  A newly received Path message with SESSION object and <Sender Tunnel
|  Address, LSP ID, Sub-Group Originator ID> tuple matching existing
|  Path state carrying the same or a different Sub-Group_ID, referred to
|  as Sub-Group_ID(n), is processed as follows:


(7)  Section 11.3

Established language in IETF (and other) publications is "tear down",
not simply "tear", when it comes to the deletion of connections etc.

Therefore, while not really wrong, I would have appreciated the
following changes:

- in the 5th line of the 3rd paragraph of Section 11.3 (on page 28):
       "It does not tear any other branches ..."
  -->  "It does not tear down any other branches ..."

- in the 5th paragraph of Section 11.3, in the last text line on p.28:
       "... that are explicitely torn ..."
  -->  "... that are explicitely torn down ..."

[ I note this minor issue just for consideration in the preparation
  of future / derived work. ]


(8)  Section 15.1.2 -- another typo

On page 31, in the 6th line of the first paragraph of Section 15.1.2,

  "being backed- up"  should be  "being backed up"

[ The hyphenated form, "backed-up" is only appropriate in adverbial
  context, e.g., "a backed-up LSP". ]


(9)  Section 16 -- typo/grammar

Within Section 16, the third paragraph on page 34 says:

   There maybe overhead for an operator to configure ...

It should say:

   There may be overhead for an operator to configure ...
            ^

Rationale: Otherwise, the sentence lacks of a verb.


(10)  Section 17 -- bad internal reference

Within Section 17, in the second paragraph on page 35, the reader
is referred to:
                 "Figure 2 in section 24"
which should be:
                 "Figure 2 in Appendix A"


(11)  Section 18 -- typo (text reformatting problem ?)

Within Section 18, at the bottom of page 35,
    "re- merge"  should be  "re-merge"


(12)  Section 19

(12a) -- lack of precision / completeness

The sub-sections of Section 19 mostly remain a bit unspecific with
respect to Class *numbers* (only Section 19.3 does supply these),
whereas C-Type values always are specified fully.

For uniformity and completeness, and for the ease of the reader,
the following changes/amendments (determined after IANA lookup)
should be applied -- adopting the style of the RFC text from
Section 19.3 --, to the lines immediately above the class data
structure diagrams (I use abbreviated, diff-like notation):

o  in Section 19.1.1 (on mid-page 39):

   Class = SESSION, P2MP_LSP_TUNNEL_IPv4 C-Type = 13
--
   SESSION Class = 1, P2MP_LSP_TUNNEL_IPv4 C-Type = 13

o  in Section 19.1.2 (on page 40):

   Class = SESSION, P2MP_LSP_TUNNEL_IPv6 C-Type = 14
--
   SESSION Class = 1, P2MP_LSP_TUNNEL_IPv6 C-Type = 14

o  in Section 19.2.1 (on top of page 41):

   Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv4 C-Type = 12
--
   SENDER_TEMPLATE Class = 11, P2MP_LSP_TUNNEL_IPv4 C-Type = 12

o  in Section 19.2.2 (on top of page 42):

   Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv6 C-Type = 13
--
   SENDER_TEMPLATE Class = 11, P2MP_LSP_TUNNEL_IPv6 C-Type = 13

o  in Section 19.4.1 (at the bottom of page 43):

   Class = FILTER_SPEC, P2MP LSP_IPv4 C-Type = 12
--
   FILTER_SPEC Class = 10, P2MP LSP_IPv4 C-Type = 12

o  in Section 19.4.2 (at the top of page 44):

   Class = FILTER_SPEC, P2MP LSP_IPv6 C-Type = 13
--
   FILTER_SPEC Class = 10, P2MP LSP_IPv6 C-Type = 13

o  in Section 19.5 (on page 44):

                       The class of the P2MP SERO is the same as the
   SERO defined in [RFC4873].
--
                       The class of the P2MP SERO is 200, as assigned
   for the SERO in [RFC4873].

o  in Section 19.6 (on page 44):

                The class of the P2MP SRRO is the same as the SRRO
   defined in [RFC4873].
--
                The class of the P2MP SRRO is 201, as assigned for
   the SRRO in [RFC4873].


(12b) -- unusual presentation

It is unusual to present the explanations of fields in a diagram
in a sequence that does not correspond to the sequence of the
fields therein.

Therefore, I would have appreciated it to find ...

o  in Section 19.2.1 (on page 41) the explanation for "LSP ID"
   not at the bottom of the list, but at the second position,
   below the explanation for "IPv4 tunnel sender address";

and

o  in Section 19.2.2 (on page 42) the explanation for "LSP ID"
   not at the bottom of the list, but at the second position,
   below the explanation for "IPv6 tunnel sender address";


(13)  Section 20.2 -- similar to (12a)

Contrary to Section 20.1, Section 20.2 is silent about the class
numbers.  As in item (12a) above, for consistency and completeness,
the following changes should be applied, in accordance with the
style of the IANA registry file and Section 20.1 :

   Class Name = SESSION
--
     1  Class Name = SESSION


   Class Name = SENDER_TEMPLATE
--
    11  Class Name = SENDER_TEMPLATE


   Class Name = FILTER_SPEC
--
    10  Class Name = FILTER_SPEC


   Class Name = SECONDARY_EXPLICIT_ROUTE (Defined in [RFC4873])
--
   200  Class Name = SECONDARY_EXPLICIT_ROUTE


   Class Name = SECONDARY_RECORD_ROUTE (Defined in [RFC4873])
--
   201  Class Name = SECONDARY_RECORD_ROUTE


[ Note:
  I have deleted the repeated refs to RFC 4873 for uniformity;
  this information is already present in Section 19, it might
  only have been interesting here for the IANA in the I-D phase. ]

It should say:

[see above]

Notes:

I strongly recommend to at least address items (3), (5), (6),
and (10) by an RFC Errata Note; I leave it to your decision which
other items to include additionally; IMHO, items (1), (12a), and
(13) should get high priority among these.

from pending
--VERIFIER NOTES--
Multipart Erratum split into Errata 2481-2494

Errata ID: 2492
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Rejected by: Adrian Farrel
Date Rejected: 2010-08-21

Section 19 says:

Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.

(12)  Section 19

(12a) -- lack of precision / completeness

The sub-sections of Section 19 mostly remain a bit unspecific with
respect to Class *numbers* (only Section 19.3 does supply these),
whereas C-Type values always are specified fully.

For uniformity and completeness, and for the ease of the reader,
the following changes/amendments (determined after IANA lookup)
should be applied -- adopting the style of the RFC text from
Section 19.3 --, to the lines immediately above the class data
structure diagrams (I use abbreviated, diff-like notation):

o  in Section 19.1.1 (on mid-page 39):

   Class = SESSION, P2MP_LSP_TUNNEL_IPv4 C-Type = 13
--
   SESSION Class = 1, P2MP_LSP_TUNNEL_IPv4 C-Type = 13

o  in Section 19.1.2 (on page 40):

   Class = SESSION, P2MP_LSP_TUNNEL_IPv6 C-Type = 14
--
   SESSION Class = 1, P2MP_LSP_TUNNEL_IPv6 C-Type = 14

o  in Section 19.2.1 (on top of page 41):

   Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv4 C-Type = 12
--
   SENDER_TEMPLATE Class = 11, P2MP_LSP_TUNNEL_IPv4 C-Type = 12

o  in Section 19.2.2 (on top of page 42):

   Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv6 C-Type = 13
--
   SENDER_TEMPLATE Class = 11, P2MP_LSP_TUNNEL_IPv6 C-Type = 13

o  in Section 19.4.1 (at the bottom of page 43):

   Class = FILTER_SPEC, P2MP LSP_IPv4 C-Type = 12
--
   FILTER_SPEC Class = 10, P2MP LSP_IPv4 C-Type = 12

o  in Section 19.4.2 (at the top of page 44):

   Class = FILTER_SPEC, P2MP LSP_IPv6 C-Type = 13
--
   FILTER_SPEC Class = 10, P2MP LSP_IPv6 C-Type = 13

o  in Section 19.5 (on page 44):

                       The class of the P2MP SERO is the same as the
   SERO defined in [RFC4873].
--
                       The class of the P2MP SERO is 200, as assigned
   for the SERO in [RFC4873].

o  in Section 19.6 (on page 44):

                The class of the P2MP SRRO is the same as the SRRO
   defined in [RFC4873].
--
                The class of the P2MP SRRO is 201, as assigned for
   the SRRO in [RFC4873].

Notes:

--VERIFIER NOTES--
The risk of errors is reduced by only defining numbers once in a document. In any case, sufficient information exists in the document to make implementation simple.

Errata ID: 2494
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Rejected by: Adrian Farrel
Date Rejected: 2010-08-21

Section 20.2 says:

Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.

(13)  Section 20.2 -- similar to (12a)

Contrary to Section 20.1, Section 20.2 is silent about the class
numbers.  As in item (12a) above, for consistency and completeness,
the following changes should be applied, in accordance with the
style of the IANA registry file and Section 20.1 :

   Class Name = SESSION
--
     1  Class Name = SESSION


   Class Name = SENDER_TEMPLATE
--
    11  Class Name = SENDER_TEMPLATE


   Class Name = FILTER_SPEC
--
    10  Class Name = FILTER_SPEC


   Class Name = SECONDARY_EXPLICIT_ROUTE (Defined in [RFC4873])
--
   200  Class Name = SECONDARY_EXPLICIT_ROUTE


   Class Name = SECONDARY_RECORD_ROUTE (Defined in [RFC4873])
--
   201  Class Name = SECONDARY_RECORD_ROUTE

Notes:

--VERIFIER NOTES--
No need to make this change as all the important information is already present in the document in the IANA section.

RFC 4880, "OpenPGP Message Format", November 2007

Note: This RFC has been updated by RFC 5581

Source of RFC: openpgp (sec)

Errata ID: 2197
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 3.5. says:

A time field is an unsigned four-octet number containing the number
of seconds elapsed since midnight, 1 January 1970 UTC.

It should say:

A time field is an unsigned four-octet number containing the number
of seconds elapsed since midnight, 1 January 1970 UTC, ignoring leap
seconds.

Notes:

And I did not yet talk about relativity theory.
--VERIFIER NOTES--
The OpenPGP time is an integer denoting UTC time. An implementation is free to display with or without leap seconds just as it might display said time in a time zone.

Errata ID: 2198
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 3.7.1.3. says:

Initially, one or more hash contexts are set up as with the other S2K
algorithms, depending on how many octets of key data are needed.
Then the salt, followed by the passphrase data, is repeatedly hashed
until the number of octets specified by the octet count has been
hashed.

It should say:

Initially, one or more hash contexts are set up as with the other S2K
algorithms, depending on how many octets of key data are needed.
Then the concatenation of salt and passphrase data is repeated
sufficiently often and concatenated. The concatenation is truncated
to the number of octets specified by the octet count. The truncated
concatenation is hashed.

Notes:

Did I get it right? If not, clearify it.
There are a lot of interpretations of the fuzzy instruction.
E.g. it could be repeat{data:=truncate(concatenate(hash(data)))} until
the octet count is exceeded. And it is still unclear weather you have to
count for each hash context separately and weather you have to count the
preloads, too.
--VERIFIER NOTES--
Submitter does not even know if the erratum is correct.

Errata ID: 2201
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 4.2. says:

   The first octet of the packet header is called the "Packet Tag".  It
   determines the format of the header and denotes the packet contents.
   The remainder of the packet header is the length of the packet.
   ...
              +---------------+
         PTag |7 6 5 4 3 2 1 0|
              +---------------+
         Bit 7 -- Always one
         Bit 6 -- New packet format if set

It should say:

   The first octet of the packet header encodes the packet format and
   the "Packet Tag".  It determines the format of the header and denotes
   the packet contents. The remainder of the packet header is the length
   of the packet body.
   ...
              +---------------+
              |7 6 5 4 3 2 1 0|
              +---------------+
         Bit 7 -- Always one
         Bit 6 -- New packet format if set

Notes:

Only a part of the first octet (depending on the packet format, i.e.
depending on bit 6 of the first octet) is the Packet Tag.
The packet consists of header and body. The encoded length is the length
of the packet body.
--VERIFIER NOTES--
The suggestion is incorrect. The first octet of the header is called the packet tag. The packet tag contains other information besides tag information, but it is nonetheless called (and has always been called) the packet tag.

Errata ID: 2202
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 4.4.1. says:

   0 - The packet has a one-octet length.  The header is 2 octets long.

   1 - The packet has a two-octet length.  The header is 3 octets long.

   2 - The packet has a four-octet length.  The header is 5 octets long.

It should say:

   0 - The packet body has a one-octet length.  The header is 2 octets
       long.

   1 - The packet body has a two-octet length.  The header is 3 octets
       long.

   2 - The packet body has a four-octet length.  The header is 5 octets
       long.

Notes:

The packet consists of header and body. The encoded length is the length
of the packet body.
--VERIFIER NOTES--
The language is clear in the document. The Body Length refers to the length of the body. Colloquially, the document calls this the packet length, but OpenPGP is hardly unique in being a TLV record system in which the length is the length of the value, not of the Tag, Length, and Value.

Errata ID: 2203
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 4.4.2. says:

   1. A one-octet Body Length header encodes packet lengths of up to 191
      octets.

   2. A two-octet Body Length header encodes packet lengths of 192 to
      8383 octets.

   3. A five-octet Body Length header encodes packet lengths of up to
      4,294,967,295 (0xFFFFFFFF) octets in length.  (This actually
      encodes a four-octet scalar number.)

   4. When the length of the packet body is not known in advance by the
      issuer, Partial Body Length headers encode a packet of
      indeterminate length, effectively making it a stream.

It should say:

   1. A one-octet Body Length header encodes packet body lengths of up
      to 191 octets.

   2. A two-octet Body Length header encodes packet body lengths of 192
      to 8383 octets.

   3. A five-octet Body Length header encodes packet body lengths of up
      to 4,294,967,295 (0xFFFFFFFF) octets in length.  (This actually
      encodes a four-octet scalar number.)

   4. When the length of the packet body is not known in advance by the
      issuer, Partial Body Length headers encode a packet of
      indeterminate length, effectively making it a stream.

Notes:

The packet consists of header and body. The encoded length is the length
of the packet body.
--VERIFIER NOTES--
The language is clear in the document. The Body Length refers to the length of the body. Colloquially, the document calls this the packet length, but OpenPGP is hardly unique in being a TLV record system in which the length is the length of the value, not of the Tag, Length, and Value.

Errata ID: 2205
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.1. says:

   The value "m" in the above formulas is derived from the session key
   as follows.  First, the session key is prefixed with a one-octet
   algorithm identifier that specifies the symmetric encryption
   algorithm used to encrypt the following Symmetrically Encrypted Data
   Packet.  Then a two-octet checksum is appended, which is equal to the
   sum of the preceding session key octets, not including the algorithm
   identifier, modulo 65536.  This value is then encoded as described in
   PKCS#1 block encoding EME-PKCS1-v1_5 in Section 7.2.1 of [RFC3447] to
   form the "m" value used in the formulas above.  See Section 13.1 of
   this document for notes on OpenPGP's use of PKCS#1.

It should say:

?

Notes:

That is how to derive m from the session key and the algorithm
identifier.
But how to derive the session key and the algorithm identifier from m?
--VERIFIER NOTES--
Not actionable. No actual erratum.

Errata ID: 2225
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.9. says:

   If the special name "_CONSOLE" is used, the message is considered to
   be "for your eyes only".

It should say:

   If the special name "_CONSOLE_" is used, the message is considered to
   be "for your eyes only".

Notes:

If the name is actually "_CONSOLE", you should explicitly mention it.
--VERIFIER NOTES--
Erratum is wrong.

Errata ID: 2228
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.13. says:

   The plaintext of the data to be encrypted is passed through the SHA-1
   hash function, and the result of the hash is appended to the
   plaintext in a Modification Detection Code packet.  The input to the
   hash function includes the prefix data described above; it includes
   all of the plaintext, and then also includes two octets of values
   0xD3, 0x14.  These represent the encoding of a Modification Detection
   Code packet tag and length field of 20 octets.

It should say:

   The concatination of the prefix data descibed above, the plaintext to
   be encrypted and two octets of values 0xD3, 0x14 (These represent the
   encoding of a Modification Detection Code packet tag and length field
   of 20 octets) is passed through the SHA-1 hash function.

Notes:

The text is misleading and contradicting.
--VERIFIER NOTES--
Erratum is incorrect.

Errata ID: 2232
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 6.3. says:

   The encoded output stream must be represented in lines of no more
   than 76 characters each.

It should say:

   The encoded output stream MUST be represented in lines in according
   to the following algorithm.
   Choose a maximal line width w not greater than 76.  Insert after each
   w characters a line break.  If the last = (the beginning of the
   encoded checksum) is not at the beginning of a line, one line break
   MAY be inserted before the last =.

Notes:

The old formulation allows lines of different length and even empty
lines.
--VERIFIER NOTES--
The submitter describes legal, correct behavior, and amends the text to disallow it.

Errata ID: 2237
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 11.1. says:

   User Attribute packets and User ID packets may be freely intermixed
   in this section, so long as the signatures that follow them are
   maintained on the proper User Attribute or User ID packet.

It should say:

   User Attribute packets and User ID packets may be freely intermixed
   in this section, so long as the signatures that follow them are
   maintained on the proper User Attribute or User ID packet, and as
   long the first one is a User ID packet.

Notes:

The first one must be a User ID packet and must not be a User Attribute
packet.
--VERIFIER NOTES--
The RFC is correct. It says that they may be freely intermixed, to denote that they may be freely intermixed.

Errata ID: 3725
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Kwadronaut
Date Reported: 2013-09-14
Rejected by: Sean Turner
Date Rejected: 2014-01-14

Section 5.2.3.11. says:

Some implementations do not represent the interest of a single user
(for example, a key server).  Such implementations always trim local
certifications from any key they handle.

It should say:

Some implementations do not represent the interest of a single user
(for example, a key server).  Such implementations MUST always trim 
local certifications from any key they handle.

Notes:

Inspiration taken from a thread on sks-devel: http://lists.nongnu.org/archive/html/sks-devel/2013-09/msg00022.html

--VERIFIER NOTES--
As agreed by the authors, MUST is unnecessary here.

Errata ID: 2204
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.1. says:

   The recipient of the message finds a session key that is encrypted
   to their public key, decrypts the session key, and then uses the
   session key to decrypt the message.

It should say:

   The recipient of the message finds a Public-Key Encrypted Session Key
   packet that contains the session key encrypted with the recipient's
   public key, decrypts the session key, and then uses the session key
   to decrypt the message.

Notes:

There is only one session key, the session key, not a session key.
The recipient is singular.
Encrypted with public key, will be decrypted with secret key. Encrypted
(with the public key) to some cipher.
--VERIFIER NOTES--
The suggestion is more precise, but harder to read.

Errata ID: 2207
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.2. says:

   Note that if an implementation is creating an encrypted and signed
   message that is encrypted to a V3 key, it is reasonable to create a
   V3 signature.

It should say:

   Note that if an implementation is creating an encrypted and signed
   message that is encrypted with a V3 key, it is reasonable to create a
   V3 signature.

Notes:

Encrypted with a key to some cipher.
--VERIFIER NOTES--
I think we can accept that encrypting implicitly means there’s a cipher involved.

Errata ID: 2209
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.2.2. says:

     - One-octet length of following hashed material.  MUST be 5.

         - One-octet signature type.

         - Four-octet creation time.

It should say:

     - Six-octet with the following three items.

         - One-octet length of the remaining two items which are
           included in the hash.  MUST be 5.

         - One-octet signature type.

         - Four-octet creation time.

Notes:

It is not the lenght of hashed material, but it is the length of the
next two items, which are included in the hash. And these three items
belong together and have six-octet length.
--VERIFIER NOTES--
Erratum is incorrect.

Errata ID: 2210
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.2.2. says:

        - Two-octet field holding left 16 bits of signed hash value.

It should say:

        - Two-octet field holding the first 16 bits of signed hash
          value.

Notes:

left is misleading. It could be remaining (from leave). And there are
cultures where the last letters of a line are on the left side.
The convention is high digit before (not left of) low digit (which may
be odd for Arabs).
--VERIFIER NOTES--
The erratum makes good point that “left” is used where “first” or “high-order” might have been a better term. However, given that we know that we use Network Byte Order, “left” is a reasonable synonym for “first.” The IETF works in English and NBO; the comments about Arabs are well-taken, but pedantic and add no value.

Additionally, a search of other RFCs shows that we are not alone in using “left” to mean “high-order.” While this may be idiomatic rather than well-defined, our research shows it’s an IETF idiom as much as an OpenPGP idiom.

Errata ID: 2211
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.2.2. says:

   The details of the calculation are different for DSA signatures than
   for RSA signatures.

It should say:

   The details of the calculation are different for DSA signatures from
   that for RSA signatures.

Notes:

different from, not different than
--VERIFIER NOTES--
Our research shows that this is a matter of opinion -- in US English grammar, the “different than” is acceptable this way. Jon prefers “different from” (the suggested erratum) and David “different than.” Thus our agreed resolution is to reject, as this is debate over usage, not an actual erratum.

Errata ID: 2212
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.2.3. says:

     - Two-octet field holding the left 16 bits of the signed hash
       value.
   ...
   The left 16 bits of the hash are included in the Signature packet to
   provide a quick test to reject some invalid signatures.

It should say:

     - Two-octet field holding the high 16 bits of the signed hash
       value.
   ...
   The high 16 bits (first two octets) of the hash are included in the
   Signature packet to provide a quick test to reject some invalid
   signatures.

Notes:

Use exactly the sentence from 5.2.2.

left is misleading. It could be remaining (from leave). And there are
cultures where the last letters of a line are on the left side.
The convention is high digit before (not left of) low digit (which may
be odd for Arabs).
--VERIFIER NOTES--
Like errata 2210, but here Constantin corrects to “high” rather than “first.” I don’t believe either is so misleading as to warrant a change.

Errata ID: 2213
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.2.3. says:

     - Two-octet scalar octet count for following hashed subpacket data.
     - Hashed subpacket data set (zero or more subpackets).
     - Two-octet scalar octet count for the following unhashed subpacket
       data. 
     - Unhashed subpacket data set (zero or more subpackets).

It should say:

     - Two-octet scalar octet count for following hashincluded subpacket
       data.
     - Hashincluded subpacket data set (zero or more subpackets).
     - Two-octet scalar octet count for the following not hashincluded
       subpacket data. 
     - Not hashincluded subpacket data set (zero or more subpackets).

Notes:

The first field does not contain a hash. But it is included in the hash.
Unhashing is the reverse of hashing, which is hopefully unfeasible.
--VERIFIER NOTES--
This is incorrect.

Errata ID: 2215
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.2.3.1. says:

   An implementation SHOULD ignore any subpacket of a type that it does
   not recognize.

   Bit 7 of the subpacket type is the "critical" bit.  If set, it
   denotes that the subpacket is one that is critical for the evaluator
   of the signature to recognize.  If a subpacket is encountered that is
   marked critical but is unknown to the evaluating software, the
   evaluator SHOULD consider the signature to be in error.

It should say:

   Bit 7 of the subpacket type is the "critical" bit.  If set, it
   denotes that the subpacket is one that is critical for the evaluator
   of the signature to recognize.  If a subpacket is encountered that is
   marked critical but is unknown to the evaluating software, the
   evaluator SHOULD consider the signature to be in error.

   An implementation SHOULD ignore any subpacket of a type that it does
   not recognize.

Notes:

The explanation for recognizing should come before recognizing is used.
--VERIFIER NOTES--
The existing text explains the rule of thumb, and then the exception. The suggestion would be more confusing than the original.

Errata ID: 2217
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.2.3.18. says:

   Note also that since this is a URI, the key server can actually be a
   copy of the key retrieved by ftp, http, finger, etc.

It should say:

?

Notes:

Nonsense. The key server is not a copy of a key.
I do not get the point. What should be noted?

Modified to editorial.
--VERIFIER NOTES--
Not actionable. No actual erratum. To answer the question, this text reminds the reader that a URI can refer to a static entity, as well as a query to a server. Yes, this is arguably superfluous, but it is there because of the WG’s rough consensus.

Errata ID: 2218
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.2.4. says:

   All signatures are formed by producing a hash over the signature
   data, and then using the resulting hash in the signature algorithm.

   For binary document signatures (type 0x00), the document data is
   hashed directly.  For text document signatures (type 0x01), the
   document is canonicalized by converting line endings to <CR><LF>,
   and the resulting data is hashed.

   When a signature is made over a key, the hash data starts with the
   octet 0x99, followed by a two-octet length of the key, and then body
   of the key packet.  (Note that this is an old-style packet header for
   a key packet with two-octet length.)  A subkey binding signature
   (type 0x18) or primary key binding signature (type 0x19) then hashes
   the subkey using the same format as the main key (also using 0x99 as
   the first octet).  Key revocation signatures (types 0x20 and 0x28)
   hash only the key being revoked.

   A certification signature (type 0x10 through 0x13) hashes the User
   ID being bound to the key into the hash context after the above
   data.  A V3 certification hashes the contents of the User ID or
   attribute packet packet, without any header.  A V4 certification
   hashes the constant 0xB4 for User ID certifications or the constant
   0xD1 for User Attribute certifications, followed by a four-octet
   number giving the length of the User ID or User Attribute data, and
   then the User ID or User Attribute data.

   When a signature is made over a Signature packet (type 0x50), the
   hash data starts with the octet 0x88, followed by the four-octet
   length of the signature, and then the body of the Signature packet.
   (Note that this is an old-style packet header for a Signature packet
   with the length-of-length set to zero.)  The unhashed subpacket data
   of the Signature packet being hashed is not included in the hash, and
   the unhashed subpacket data length value is set to zero.

   Once the data body is hashed, then a trailer is hashed.  A V3
   signature hashes five octets of the packet body, starting from the
   signature type field.  This data is the signature type, followed by
   the four-octet signature time.  A V4 signature hashes the packet body
   starting from its first field, the version number, through the end
   of the hashed subpacket data.  Thus, the fields hashed are the
   signature version, the signature type, the public-key algorithm, the
   hash algorithm, the hashed subpacket length, and the hashed
   subpacket body.

   V4 signatures also hash in a final trailer of six octets: the
   version of the Signature packet, i.e., 0x04; 0xFF; and a four-octet,
   big-endian number that is the length of the hashed data from the
   Signature packet (note that this number does not include these final
   six octets).

   After all this has been hashed in a single hash context, the
   resulting hash field is used in the signature algorithm and placed
   at the end of the Signature packet.

It should say:

   All signatures are formed by producing a hash over the signature
   data, and then using the resulting hash in the signature algorithm.

   The signature data is the concatenation of a body and a trailer.

   For binary document signatures (type 0x00), the document data is
   is the sinature data body.  For text document signatures (type 0x01),
   the document is canonicalized by converting line endings to <CR><LF>,
   and the resulting data is the sinature data body.

   When a signature is made over one key, the signature data body is a
   Public-Key packet (see 5.5.) in the old packet format with two-octet
   body length (octet 0x99, followed by the two-octet body length,
   followed by the Public-Key packet body).  The signature data body of
   a subkey binding signature (type 0x18) or of a primary key binding
   signature (type 0x19) is the concatination of the Public-Key packet
   of the main key and a Public-Key (not a Public-Subkey packet) packet
   of the subkey in the format discribed above.  The signature data body
   of a Key Revocation signatures (type 0x20 or 0x28) is the Public-Key
   packet of the key being revoked in the format described above.

   The signature data body for a V3 certification signature (type 0x10
   through 0x13) is the concatination of the key packet in the format
   described above and the body of a User ID packet (see 5.11.).  The
   signature data body for a V4 certification signature (type 0x10
   through 0x13) is the concatenation of the key packet in the format
   descibed above, either the constant 0xB4 for User ID certification or
   the constant 0xD1 for User Attribute certification (User Attribute
   packets are not a required part of the OpenPGP standard.  Except as
   noted, a User Attribute packet may be used anywhere that a User ID
   packet may be used. (see 5.12.)),  a four-octet number giving the
   length of the User ID Packet body, and the User ID Packet body.
   (0xB4 starts an old-style packet header of a User ID packet with
   one-octet body length and 0xD1 starts the new-style packet header of
   a User Attribute packet.  But the body length is encoded
   differently.)

   When a signature is made over a Signature packet (type 0x50), the to
   signed Signature packet is trimmed by leaving out the not
   hashincluded subpacket data and setting the not hashincluded
   subpacket data length to zero.  The body of the signature data is the
   octet 0x88, followed by the four-octet-length of the to be signed
   Signature packet body, followed by the to be signed Signature packet
   body.  (0x88 starts an old-style packet header of a Signature packet
   with one-octet body length.  But the body length is encoded
   differently.)

   The signature data trailer for a V3 signature are five octets of the
   signature packet body, starting from the signature type field. This
   data is the signature type followed by the four-octet signature time.
   The signature data trailer for a V4 signature is the concatenation
   of a part of the signature packet body starting from the first field,
   the version number, through the end of the hashincluded subpacket
   data, one more time the version number (0x04), 0xFF, and a four-octet
   number of the length of the part included from the signature packet.

Notes:

The original is nearly unintelligible. Key, key packet, key packet body,
etc are confused until a signature hashes the User ID into a hash
context (sic!).

The 0x99 for all public-keys and the differently encoded body lenght for
User ID packets and User Attribute packets is really odd.
Proposal:
A Flag and a Feature for a new encoding of the signature body. Usage of
a the actual new-style packet headers with 0xFF and four-octet body
length.

Changed to editorial.
--VERIFIER NOTES--
As complex as the RFC’s text may be, it’s been through the IETF process including people actually coding to it. I don’t find the change any less complex and might contain errors.

Errata ID: 2220
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.5.3. says:

     - A Public-Key or Public-Subkey packet, as described above.

It should say:

     - A Public-Key or Public-Subkey packet body, as described above.

Notes:

There is no Public-Key packet header in the Secret-Key packet body.

Changed to editorial.
--VERIFIER NOTES--
Similar to Errata 2202 and 2203, it is an idiom of the document to say “packet” when it might be more precise to say “packet body.” It is, however, clear. If there are inconsistencies in this idiom, they’d make reasonable errata.

Errata ID: 2221
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.5.3. says:

     - If the string-to-key usage octet is zero or 255, then a two-octet
       checksum of the plaintext of the algorithm-specific portion (sum
       of all octets, mod 65536).

It should say:

     - If the string-to-key usage octet is not 254, then a two-octet
       checksum of the plaintext of the algorithm-specific portion (sum
       of all octets, mod 65536).

Notes:

Without the values values of 1 to 253 the following
Note that for all other values, a two-octet checksum is required.
is not just a note.

Changed to editorial.
--VERIFIER NOTES--
The RFC is correct.

Errata ID: 2223
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.5.3. says:

       This checksum or hash is encrypted together with the
       algorithm-specific fields (if string-to-key usage octet is not
       zero).

It should say:

       For V4 keys this checksum or hash is encrypted together with the
       algorithm-specific fields (if string-to-key usage octet is not
       zero).

Notes:

The following text says:
With V3 keys, the checksum is stored in the clear. With V4 keys,
the checksum is encrypted like the algorithm-specific data.

Changed to editorial.
--VERIFIER NOTES--
Text describing V3 keys precedes this text.

Errata ID: 2224
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.5.3. says:

   Encryption/decryption of the secret data is done in CFB mode using
   the key created from the passphrase and the Initial Vector from the
   packet.  A different mode is used with V3 keys (which are only RSA)
   than with other key formats.  With V3 keys, the MPI bit count prefix
   (i.e., the first two octets) is not encrypted.  Only the MPI non-
   prefix data is encrypted.  Furthermore, the CFB state is
   resynchronized at the beginning of each new MPI value, so that the
   CFB block boundary is aligned with the start of the MPI data.

   With V4 keys, a simpler method is used.  All secret MPI values are
   encrypted in CFB mode, including the MPI bitcount prefix.

It should say:

   Encryption/decryption of the secret data is done in CFB mode using
   the key created from the passphrase and the Initial Vector from the
   packet.

   A different mode is used with V3 keys (which are only RSA)
   than with other key formats.  With V3 keys, the MPI bit count prefix
   (i.e., the first two octets) is not encrypted.  Only the MPI non-
   prefix data is encrypted.  Furthermore, the CFB state is
   resynchronized at the beginning of each new MPI value, so that the
   CFB block boundary is aligned with the start of the MPI data.

   With V4 keys, a simpler method is used.  All secret MPI values are
   encrypted in CFB mode, including the MPI bitcount prefix.

Notes:

It is unclear if the Furthermore belongs only to V3 keys.

Changed to editorial.
--VERIFIER NOTES--
Text is in a paragraph describing V3 keys.

Errata ID: 2227
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.12. says:

   A User ID packet consists of UTF-8 text that is intended to represent
   the name and email address of the key holder.

It should say:

   A User ID packet body consists of UTF-8 text that is intended to
   represent the name and email address of the key holder.
or
   A User ID packet contains UTF-8 text that is intended to represent
   the name and email address of the key holder.

Notes:

Yes, it is pedantic. But the packet consists of header and body.
--VERIFIER NOTES--
Similar to errata 2220 etc. It is indeed pedantic as submitter notes.

Errata ID: 2229
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.13. says:

      Suffice it to say that many people consider properties such as
      deniability to be as valuable as integrity.

It should say:

      It is sufficient to say that many people consider properties such
      as deniability to be as valuable as integrity.

Notes:

Is that an imperative?
--VERIFIER NOTES--
Suggestion isn’t grammatical.

Errata ID: 2230
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.14. says:

   The Modification Detection Code packet MUST be the last
   packet in the plaintext data that is encrypted in the Symmetrically
   Encrypted Integrity Protected Data packet, and MUST appear in no
   other place.

It should say:

   The Modification Detection Code packet MUST be the last
   packet in the plaintext data that is encrypted in the Symmetrically
   Encrypted Integrity Protected Data packet, and MUST NOT appear in any
   other place.

Notes:

'MUST appear in no other place' postulates an existence in the nowhere.
--VERIFIER NOTES--
On its surface, a good suggestion, but lacks the force of the original.

Errata ID: 2231
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.14. says:

   A Modification Detection Code packet MUST have a length of 20 octets.

It should say:

   A Modification Detection Code packet MUST have a body length of 20
   octets.

Notes:

The packet consists of header and body.
--VERIFIER NOTES--
Similar to errata 2220 etc. It is indeed pedantic as submitter notes.

Errata ID: 2233
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 6.4. says:

   In Radix-64 data, characters other than those in the table, line
   breaks, and other white space probably indicate a transmission error,
   about which a warning message or even a message rejection might be
   appropriate under some circumstances.  Decoding software must ignore
   all white space.

   Because it is used only for padding at the end of the data, the
   occurrence of any "=" characters may be taken as evidence that the
   end of the data has been reached (without truncation in transit).  No
   such assurance is possible, however, when the number of octets
   transmitted was a multiple of three and no "=" characters are
   present.

It should say:

   In Radix-64 data, characters other than those in the table, line
   breaks earlier than defined by the first line's length without
   following '=' or '-', line breaks at the beginning of a line, and
   other white space probably indicate a transmission error, about which
   a warning message or even a message rejection might be appropriate
   under some circumstances.  After that check, decoding software must
   ignore all white space.

   The boundary between encoded data and encoded checksum is before the
   last '=' of a sequence of one, two or three '='.

Notes:

Might reject and must ignore is a contradiction.
There is always at least one '=', i.e. the beginning of the encoded
checksum.

Changed to editorial.
--VERIFIER NOTES--
There is no contradiction. The implementation must ignore all whitespace, and must reject all bogus ‘=’ characters.

Errata ID: 2239
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 12.1. says:

   Entries in square brackets are optional and ellipses indicate
   repetition.
   ...
           Primary-Key
              [Revocation Self Signature]
              [Direct Key Signature...]
               User ID [Signature ...]
              [User ID [Signature ...] ...]
              [User Attribute [Signature ...] ...]
              [[Subkey [Binding-Signature-Revocation]
                      Primary-Key-Binding-Signature] ...]

It should say:

   Entries in square brackets are optional, vertical bar separates
   alternatives, and ellipses indicate repetition.
   ...
           Primary-Key
              [Revocation Self Signature]
              [Direct Key Signature...]
               User ID [Signature ...]
              [[User ID [Signature ...] |
                      [User Attribute [Signature ...]]...]
              [[Subkey [Binding-Signature-Revocation]
                      Primary-Key-Binding-Signature] ...]

Notes:

11.1. says:
User Attribute packets and User ID packets may be freely intermixed
in this section, so long as the signatures that follow them are
maintained on the proper User Attribute or User ID packet, and as
long the first one is a User ID packet.

Changed to editorial.
--VERIFIER NOTES--
The RFC is correct. It says that they may be freely intermixed, to denote that they may be freely intermixed.

Errata ID: 2241
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 12.2. says:

   The fingerprint of a V3 key is formed by hashing the body (but not
   the two-octet length) of the MPIs that form the key material (public
   modulus n, followed by exponent e) with MD5.

It should say:

   The fingerprint of a V3 key is formed by hashing the concatenation
   of the bodies of the MPIs (MPI without two-octet length) that form
   the key material (public modulus n, followed by exponent e) with MD5.

Notes:

There are two bodies and one hash.

Changed to editorial.
--VERIFIER NOTES--
It could have been:

... by hashing the body (but not the two-octet length) of the two MPIs
^^^

But, it's clear from the parenthetical that there are two MPIs.

RFC 4905, "Encapsulation Methods for Transport of Layer 2 Frames over MPLS Networks", June 2007

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rtg

Errata ID: 1036
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-08-17
Rejected by: Stewart Bryant
Date Rejected: 2011-09-14

 

IMHO, RFC 4905 contains inappropriate text copied literally from
RFC 4906, in two places:
   a)  at the end of the Abstract, and
   b)  at the end of Section 3

The last sentence in a) says:

      [...]  This document describes the so-called "draft-martini"
   protocol, which has since been superseded by the Pseudowire Emulation
   Edge to Edge Working Group specifications described in RFC 4447 and
   related documents.

The last sentence in b) says:
                                                           [...].  The
   PWE3 Label Distribution Protocol control protocol document [RFC4447],
   which is backward compatible with this document, MUST be used for all
   new implementations of this protocol.

Roughly, RFC 4447 is the Standards Track successor of RFC 4906;
thus, both sentences are perfectly proper in the context of RFC 4906,
but they should have been replaced by more specific text matching
the technical contents of RFC 4905 and listing the corresponding
Standards Track documents.

Notes:

--VERIFIER NOTES--
This text concerned was included during the preparation of the original "draft-martini" drafts for publication as documents of historical interest to the IETF.

The text is harmless, and there is unlikely to be any value to the community in expending effort on corrected text.

Normally an issue like this would be held for update, but there will be no update to this document.

RFC 4928, "Avoiding Equal Cost Multipath Treatment in MPLS Networks", June 2007

Note: This RFC has been updated by RFC 7274

Source of RFC: mpls (rtg)

Errata ID: 5396
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Jitendra Kumar Sharma
Date Reported: 2018-06-18
Rejected by: Deborah Brungard
Date Rejected: 2021-02-26

Section Section 2 says:

   A less obvious case is when the packets of a given flow happen to
   have constant values in the fields upon which IP ECMP would be
   performed.  For example, if an Ethernet frame immediately follows the
   label and the LSR does ECMP on IPv4, but does not do ECMP on IPv6,
   then either the first nibble will be 0x4, or it will be something
   else.  If the nibble is not 0x4 then no IP ECMP is performed, but
   Label ECMP may be performed.  If it is 0x4, then the constant values
   of the MAC addresses overlay the fields that would have been occupied
   by the source and destination addresses of an IP header.  In this
   case, the input to the ECMP algorithm would be a constant value and
   thus the algorithm would always return the same result.

It should say:

<This paragraph should be removed>

Notes:

The example stated here seems incorrect. It talks about an L2VPN case where Ethernet frame starts immediately after the last label in the stack. But had it been an IP packet instead, the same initial 12 bytes, which is the place for MAC addresses in an Ethernet Frame, would not be the place of IP addresses, as IP addresses are placed at the end of 20-byte IP header (not start). Hence it would still be subjected to ECMP if precautions (as recommended in this RFC) are not been followed.
--VERIFIER NOTES--
This should be addressed by the working group (e.g., updating or revising the RFC).

RFC 4941, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", September 2007

Note: This RFC has been obsoleted by RFC 8981

Source of RFC: ipv6 (int)

Errata ID: 4594
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Johanna Ullrich
Date Reported: 2016-01-14
Rejected by: Brian Haberman
Date Rejected: 2016-01-15

Section 3.2 says:

Notes:

The algorithm for interface identifier generation is flawed: An adversary is able to infer a client's history value from a sequence of observed addresses and is able to infer all future interface identifiers of this certain client annihilating the extension's intended purpose of privacy protection.

For a detailed explanation on the algorithm's drawbacks, please see my paper:
https://www.sba-research.org/wp-content/uploads/publications/Ullrich2015Privacy.pdf
--VERIFIER NOTES--
The issue raised goes beyond a fix via the errata system. This should be raised in the appropriate working group within the IETF.

Errata ID: 5182
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Erik Kline
Date Reported: 2017-11-13
Rejected by: Erik Kline
Date Rejected: 2021-01-28

Section 3.6 says:

   Devices implementing this specification MUST provide a way for the
   end user to explicitly enable or disable the use of temporary
   addresses.

It should say:

   Devices implementing this specification SHOULD provide a way for the
   end user to explicitly enable or disable the use of temporary
   addresses.

Notes:

Allowing users to disable privacy features is not something that should be mandatory.
--VERIFIER NOTES--
It would be bad form, I suspect, for me to verify my own erratum. =)

As 4941bis is in the works, I'll Reject this and consider whether to (re)submit an erratum for the new document once published.

RFC 4948, "Report from the IAB workshop on Unwanted Traffic March 9-10, 2006", August 2007

Source of RFC: IAB

Errata ID: 3504
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bharat Joshi
Date Reported: 2013-03-01
Rejected by: Russ Housley
Date Rejected: 2013-04-25

Section 2.4 says:

As a result, not only is there no limit to what a host may do, but
also there is no trace after the event of what a host may have done.

It should say:

As a result, not only there is no limit to what a host may do, but 
also there is no trace of what a host may have done.

Notes:

1. 'is' in the first part of the sentence is not at the correct place.

2. 'after the event' is making the sentence improper.

RFC 4952, "Overview and Framework for Internationalized Email", July 2007

Note: This RFC has been obsoleted by RFC 6530

Note: This RFC has been updated by RFC 5336

Source of RFC: eai (app)

Errata ID: 1508
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-09-15
Rejected by: Lisa Dusseault
Date Rejected: 2008-09-15

Section 1.3, pg.5 says:

   An "i18mail user" has one or more non-ASCII email addresses.  [...]

Notes:

This unusual term, "i18mail user" does not appear anywhere else in
the RFC besides the quoted paragraph in the Terminology section.
--VERIFIER NOTES--
The term is used in draft-ietf-eai-mailinglist-03.txt, which refers to rfc4952.

RFC 4954, "SMTP Service Extension for Authentication", July 2007

Note: This RFC has been updated by RFC 5248

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 1020
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-08-25
Rejected by: Alexey Melnikov
Date Rejected: 2007-08-25

Section 9 says:

(4)  Section 9 -- distorted sentence

The 4th paragraph of Section 9, on mid-page 14, says:

  [...]
  The AUTH=<> parameter prevents such an attack from causing a relayed
|  message and, in the absence of other envelope authentication, from
|  picking up the authentication of the relay client.

IMHO, this sentence is distorted and potentially misleading.
The RFC should perhaps better say:

  [...]
  The AUTH=<> parameter prevents such an attack from causing a relayed
|  message, in the absence of other envelope authentication, to pick up
  the authentication of the relay client.

This is essentially what RFC 2554 said in this place, and which makes
much more sense to me.

It should say:

-

Notes:

---VERIFIER NOTE---
I tend to disagree in this case. The "and" was certainly missing in the original text. I also think the new version is more readable.

RFC 4960, "Stream Control Transmission Protocol", September 2007

Note: This RFC has been obsoleted by RFC 9260

Note: This RFC has been updated by RFC 6096, RFC 6335, RFC 7053, RFC 8899

Source of RFC: tsvwg (wit)

Errata ID: 3804
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Stephen Galvan Jr
Date Reported: 2013-11-16
Rejected by: Martin Stiemerling
Date Rejected: 2015-11-02

Section 3.3.2 says:

Notes:

something was placed in the ending line that made it almost unreadable.
--VERIFIER NOTES--
This errata is not technical and the presumably editorial part is not identifiable.

Errata ID: 4250
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Phung Pham
Date Reported: 2015-01-31
Rejected by: Martin Stiemerling
Date Rejected: 2015-07-16

Section 3.3.4 says:

                     +--------------------------------+
                     |   Cumulative TSN Ack = 12      |
                     +--------------------------------+
                     |        a_rwnd = 4660           |
                     +----------------+---------------+
                     | num of block=2 | num of dup=0  |
                     +----------------+---------------+
                     |block #1 strt=2 |block #1 end=3 |
                     +----------------+---------------+
                     |block #2 strt=5 |block #2 end=5 |
                     +----------------+---------------+

It should say:

                     +--------------------------------+
                     |   Cumulative TSN Ack = 12      |
                     +--------------------------------+
                     |        a_rwnd = 4660           |
                     +----------------+---------------+
                     | num of block=2 | num of dup=0  |
                     +----------------+---------------+
                     |block #1 strt=2 |block #1 end=3 |
                     +----------------+---------------+
                     |block #2 strt=5 |block #2 end=6 |
                     +----------------+---------------+

Notes:

According to the illustration of the DATA chunks just above it, with "still missing" TSN 13 and TSN 16, the block #2 end=6 not 5.
--VERIFIER NOTES--
Reasoning provided by M. Tüxen: "I think the RFC is correct. The first block is TSN 14 and TSN 15. Since the cumulative TSN ack is 12, this
is [2, 3]. The second block consists only of TSN 17. Therefore is is reported as [5, 5].
The block [5, 6] as you suggest would mean that TSN 17 and TSN 18 would have been received, which
is not the case described in the illustration."

Errata ID: 4876
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Pourtet
Date Reported: 2016-12-01
Rejected by: Spencer Dawkins
Date Rejected: 2018-07-10

Section 5.1.5. says:

3)  Compare the port numbers and the Verification Tag contained
    within the COOKIE ECHO chunk to the actual port numbers and the
    Verification Tag within the SCTP common header of the received
    packet.  If these values do not match, the packet MUST be
    silently discarded.

It should say:

3)  Compare the port numbers and the Verification Tag contained
    within the TCB data carried in the State Cookie to the actual
    port numbers and the Verification Tag within the SCTP common
    header of the received packet.  If these values do not match,
    the packet MUST be silently discarded.

Notes:

The comparison has to be performed between the values found in the SCTP common header and what is inside the TCB carried in the State Cookie. The current phrasing can lead to think that there are Verifcation Tag and port number fields within the COOKIE ECHO chunk yet outside the State Cookie.
--VERIFIER NOTES--
This errata was withdrawn by the submitter, and was not included in draft-ietf-tsvwg-rfc4960-errata.

RFC 4976, "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", September 2007

Note: This RFC has been updated by RFC 7977, RFC 8553, RFC 8996

Source of RFC: simple (rai)

Errata ID: 1276
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-14
Rejected by: Robert Sparks
Date Rejected: 2011-02-21

Section 6.4.3 says:

<< NONE >>

It should say:

<< add to the end of the section: >>

   Before forwarding a 200 response containing a Use-Path header field,
   the relay MUST prepend to the existing header field value the URI it
   supplies and wants the upstream neighbor to use in future requests in
   this session.

Notes:

As sadly confirmed by the flaws in the example in Section 5.1 (on p. 17),
the Relay Behavior / Handling Responses underspecifies the required
synthesis of the Use-Path header field value.

The above text is a strawman proposal and should be elaborated upon
before signing off this report.
--VERIFIER NOTES--
From reviewer Dale Worley:

The suggested change is incorrect. The value of the Use-Path header
generated by the server-relay in the 200 response is not intended to
be modified by any intermediate relay on the way to the client. This
can be seen by (1) the lack of any text specifying any transformation
of the Use-Path value by intermediate relays, and (2) the skeleton
example in section 5.1, page 14, which says "Use-Path returned by C: B
C". (In that example, a better rendering would be "Use-Path returned
by C: Btoken Ctoken".)

A relay can generate a complete Use-Path because the initial elements
can be extracted from the From-Path value of the request.

RFC 4978, "The IMAP COMPRESS Extension", August 2007

Source of RFC: lemonade (app)

Errata ID: 4478
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: poima fuimaono
Date Reported: 2015-09-19
Rejected by: Barry Leiba
Date Rejected: 2015-09-19

Section IMAP protoco says:

RFC 4978 vs. RFC 5032 -- mismatch in UPDATES clauses

Within two weeks, two RFCs have been published specifying amendments
to the IMAP protocol:

  o  RFC 4978  -- COMPRESS

  o  RFC 5032  -- WITHIN Search

Both IMAP extensions are similarly structured and arguably RFC 4978
modifies IMAP behaviour specified in RFC 3501 (and other IMAP
extension specifications: IMAP TLS and SASL) to a much greater extent
than RFC 5032 does.

Nevertheless and surprisingly, only RFC 5032 has the line,
  Updates: 3501
in its document header and hence in its RFC index metadata.

This is apparently inconsistent.

An update to the RFC metadata incoporating the relation
     "RFC 4978 updates RFC 3501"
would be welcome as well.
Report New Errata

It should say:

TBD following modifications

Notes:

Both IMAP extensions are similarly structured and arguably RFC 4978
modifies IMAP behaviour specified in RFC 3501 (and other IMAP
extension specifications: IMAP TLS and SASL) to a much greater extent
than RFC 5032 does.

Nevertheless and surprisingly, only RFC 5032 has the line,
Updates: 3501
in its document header and hence in its RFC index metadata.

This is apparently inconsistent.

An update to the RFC metadata incoporating the relation
"RFC 4978 updates RFC 3501"
would be welcome as well.
Report New Errata
--VERIFIER NOTES--
First, errata isn't meant to be used for RFC metadata.

Second, the reason that RFC 5032 "updates" 3501 is that the grammar for the IMAP SEARCH command isn't set up to be extensible, so adding search terms is an update to the base. In contrast, adding IMAP commands generally isn't.

Except that, yes, we have been inconsistent with that over time.

RFC 4992, "XML Pipelining with Chunks for the Internet Registry Information Service", August 2007

Note: This RFC has been updated by RFC 8996

Source of RFC: crisp (app)

Errata ID: 2830
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Rejected by: Peter Saint-Andre
Date Rejected: 2011-08-01

Section 6.5 says:

   These fields MUST NOT span multiple chunks.  Therefore, it should be
   noted that SASL data length exceeding the length of the chunk minus
   the length of SASL profile name minus one is an error.

It should say:

   These fields MUST NOT span multiple chunks.  Therefore, it should be
   noted that a mechanism data length exceeding the length of the chunk
   minus the mechanism name length minus three is an error.

Notes:

This section presents the diagram below (and subsequent field
explanations):

+-----------+-----------+-----------+-----------+
field | mechanism | mechanism | mechanism | mechanism |
| name | name | data | data |
| length | | length | |
+-----------+-----------+-----------+-----------+
octets 1 variable 2 variable

SASL Authentication


Apparently, the fate of the 'mechanism data length' field once has
been unsure, and it (almost) seems to be a redundant field anyway.

As specified, the data handed out by a SASL mechanism as a single
protocol message must be contained within the 'mechanism data' field
of a single chunk.
Apparently, there are no provisions for chunk padding in the protocol.
Therefore, according to the figure quoted above in item (A.2) and
the above figure, for these chunks the following equation holds
(for clarity, I denote the content of a field by giving the field
name in angular braces):

<chunk data length> = 1 ; length of 'name length' field
+ <name length>
+ 2 ; length of 'mechanism data length' field
+ <mechanism data length>

This leads to the conclusion that the 'mechanism data length' field
is redundant; I suspect it was left out from the SASL chunk structure
at the time when the paragraph quoted below was drafted.

Taking all together, the paragraph above makes no sense:

o The undefined term 'SASL data length' should be replaced with the
defined term, 'mechanism data length'.

o SASL *profiles* are not discussed in this memo,
the text consistently should talk about SASL *mechanism*s,
and use the defined field name, 'mechanism name length'.

o The constant overhead is *three* bytes, not *one*.

Furthermore, proper articles should be inserted to improve the language.

[Separating into individual errata from 1009]
--VERIFIER NOTES--
The authors of the specification note that the terms
being interchanged are defined to be equivalent in
section 6.5, so there is no substantive issue. This
could be adjusted editorially if the documents are
updated.

RFC 4996, "RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)", July 2007

Note: This RFC has been obsoleted by RFC 6846

Source of RFC: rohc (tsv)

Errata ID: 1288
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-21
Rejected by: Magnus Westerlund
Date Rejected: 2009-09-07

Throughout the document, when it says:

IR

It should say:

IR and IR-DYN

Notes:

RFC 4996 is very confusing regarding the ROHC packet types used.
Section 2 (on top of page 5) says only 3 types are used: IR, IR-CR, and CO.
This is restated in a few places.
But significant text in RFC 4996 also details the use of the IR-DYN
packet type.

According to RFC 4995, IR-DYN is a distinct packet type.

It looks like the terminology has been floating for some time,
and the text of RFC 4996 has not been adjusted to the final
terminology used in RFC 4995, before publication as an RFC,
although both RFCs have been published in a coordinated way.

To give the reader a hint on the problem, I suggest a change note
for Section 2 -- this will be posted as a separate Errata Note --
and detail the other places in the text affected by this issue
in an accompanying message to be evalueated by the verifiers,
to avoid an email avalanche.
This report will also include other issues found not suitable for
reporting via this form based system.
--VERIFIER NOTES--
Authors and WG chairs are of the opinion that it is reasonably clear that IR is both a class of packets type. So from the context it should be understandable when the class is meant rather than the specific type. And clarification would also require major changes in several docs.

Errata ID: 1289
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-21
Rejected by: Magnus Westerlund
Date Rejected: 2009-09-07

Section 2, pg. 5 says:

   ROHC-TCP packet types

      ROHC-TCP uses three different packet types: the Initialization and
      Refresh (IR) packet type, the Context Replication (IR-CR) packet
      type, and the Compressed packet (CO) type.

It should say:

   ROHC-TCP packet types

      ROHC-TCP uses four different packet types: the Initialization and
      Refresh (IR) packet type, the IR-DYN (IR, dynamic update) packet
      type, the Context Replication (IR-CR) packet type, and the
      Compressed packet (CO) type.

Notes:

ROHC-TCP makes use of IR-DYN packets, as can be seen in other parts
of the text.
According to RFC 4995, IR-DYN is a distinct ROHC packet type,
and RFC 4995 does not contain the notion of a packet sub-type
that might have justified subsuming IR-DYN as a non-self-sustaining
packet always to be included/assumed as well when talking about the
IR packet type.

For more information see the GLOBAL Errata Report issued on this topic.
--VERIFIER NOTES--
Authors and WG chairs are of the opinion that it is reasonably clear that IR is both a class of packets type. So from the context it should be understandable when the class is meant rather than the specific type. And clarification would also require major changes in several docs.

Errata ID: 1294
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-21
Rejected by: Magnus Westerlund
Date Rejected: 2009-09-07

Section 7, 1st para says:

   ROHC-TCP uses three different packet types: the Initialization and
   Refresh (IR) packet type, the Context Replication (IR-CR) packet
   type, and the Compressed (CO) packet type.

It should say:

   ROHC-TCP uses four different packet types: the Initialization and
   Refresh (IR) packet type, the Initialization and Refresh - Dynamic
   Part (IR-DYN) packet type, the Context Replication (IR-CR) packet
   type, and the Compressed (CO) packet type.

Notes:

See GLOBAL errata report on IR <-> IR-DYN for rationale.
--VERIFIER NOTES--
Authors and WG chairs are of the opinion that it is reasonably clear that IR is both a class of packets type. So from the context it should be understandable when the class is meant rather than the specific type. And clarification would also require major changes in several docs.

Errata ID: 1295
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-21
Rejected by: Magnus Westerlund
Date Rejected: 2009-09-07

Section 7.1 says:

7.1.  Initialization and Refresh (IR) Packets

It should say:

7.1.  Initialization and Refresh (IR and IR-DYN) Packets

Notes:

See GLOBAL errata report on IR <-> IR-DYN for rationale.
--VERIFIER NOTES--
Authors and WG chairs are of the opinion that it is reasonably clear that IR is both a class of packets type. So from the context it should be understandable when the class is meant rather than the specific type. And clarification would also require major changes in several docs.

Errata ID: 1300
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-21
Rejected by: Magnus Westerlund
Date Rejected: 2009-09-07

Section 8.3.2.3 says:

|  These 2 bits are the least significant bits of the MSN and are thus
   concatenated with the 14 bits already present in the FEEDBACK-2
   format.

It should say:

|  These 2 bits are the most significant bits of the MSN and are thus
   concatenated with the 14 bits already present in the FEEDBACK-2
   format.

Notes:

It does not make much sense to "provide 2 additional bits"
for a numerical value, and taking the *least* significant bits
for this purpose. This way, the interpretation of the other
encoded MSN bits would prematurely be changed by the presence
of the MSN option.
Therefore, I strongly suspect that the text is in error and
should be corrected as above.
--VERIFIER NOTES--
WG chair Calle Knutsson: This is the way we handle lsbs.

Errata ID: 3637
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Raj Kumar
Date Reported: 2013-06-04
Rejected by: Martin Stiemerling
Date Rejected: 2015-12-16

Section 8.2 says:

COMPRESSED rout_opt_0_replicate {
    discriminator =:= '10000000'                     [ 8 ];
    length        =:= irregular(8)                   [ 8 ];
    value         =:=
      irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ];
  }

It should say:

COMPRESSED rout_opt_1_replicate {
    discriminator =:= '10000000'                     [ 8 ];
    length        =:= irregular(8)                   [ 8 ];
    value         =:=
      irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ];
  }

Notes:

Incorrect Representation FN of IPv6 Route Options nomenclature
--VERIFIER NOTES--
This seems to be correct as this is referring to type 0 routing ext. headers. Nonetheless, this RFC has been obsoleted by RFC 6846.

RFC 5008, "Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)", September 2007

Note: This RFC has been obsoleted by RFC 6318

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 1023
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-18
Rejected by: Russ Housley
Date Rejected: 2007-09-18

 

(1)  Section 3  (nit)

In the first sentence of Section 3 (on page 3), the acronym expansion
performed should better have been accompanied by the insertion of the
definite article.

The RFC says:

   This section specifies the conventions employed by implementations
|  that support Elliptic Curve Digital Signature Algorithm (ECDSA).  The
   direction set by RFC 3278 [CMSECC] is followed, but additional
   message digest algorithms and additional elliptic curves are
   employed.  [...]

It should perhaps better say:

   This section specifies the conventions employed by implementations
|  that support the Elliptic Curve Digital Signature Algorithm (ECDSA).
   The direction set by RFC 3278 [CMSECC] is followed, but additional
   message digest algorithms and additional elliptic curves are
   employed.  [...]


(2)  Section 4.3 -- imprecise text, danger of ambiguity / confusion

In Section 4.3, near the bottom of page 9, a new paragraph has been
inserted in the part describing the [SEC1] KDF in general:

   To generate a key-encryption key, one or more KM blocks are
   generated, incrementing Counter appropriately, until enough material
   has been generated.  The KM blocks are concatenated left to right:

      KEK = KM ( counter=1 ) || KM ( counter=2 ) ...


But near the end of Section 4.3, on mid-page 10, the original text
from the draft has been left unchanged:

|  To generate a key-encryption key, one KM block is generated, with a
   Counter value of 0x00000001:

      KEK = KM ( 1 ) = Hash ( Z || Counter=1 || ECC-CMS-SharedInfo )


These two different, but very similar statements might well lead to
confusion.

As already indicated above, apparently the former text shall describe
the [SEC1] KDF in general, and the latter is intended to describe the
restricted particular use of that KDF in the context of S/MIME.

Therefore, the RFC should perhaps better have stated, in place of
the latter text:

                                   vvvvvvvvvvvvvvvvvvvvvv
|  To generate a key-encryption key for Suite B in S/MIME, one KM block
   is generated, with a Counter value of 0x00000001:

      KEK = KM ( 1 ) = Hash ( Z || Counter=1 || ECC-CMS-SharedInfo )

________
Note:
 It might have been even more suitable to have that text be moved up,
 making it part of the indented explanation of the 'Counter' element
 (2nd paragraph on page 10), where it could have been kept shorter:

      Counter is a 32-bit unsigned number, represented in network byte
      order.  Its initial value MUST be 0x00000001 for any key
      derivation operation.  In Suite B, Security Level 1 and Security
      Level 2, exactly one iteration is needed; the Counter is not
|     incremented; i.e., one KM block is generated, with a Counter value
|     of 0x00000001:
|
|        KEK = KM ( 1 ) = Hash ( Z || Counter=1 || ECC-CMS-SharedInfo )
________

As a minimally invasive change, I recommend posting the above
clarification (or any proper alternate text of your choice)
as an RFC Errata Note.

It should say:

-

Notes:

---VERIFIER NOTE---
Thanks for the careful review. I do not believe that these are worth the effort for an errata.

RFC 5012, "Requirements for Emergency Context Resolution with Internet Technologies", January 2008

Source of RFC: ecrit (rai)

Errata ID: 1260

Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-13
Rejected by: Robert Sparks
Date Rejected: 2010-12-06
Report Text:

double replication :  ability to   <->  to be able to    :-)
 --VERIFIER NOTES-- 
Partial report repeated in errata 1263   

---

RFC 5022, "Media Server Control Markup Language (MSCML) and Protocol", September 2007

Source of RFC: INDEPENDENT

Errata ID: 1233
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Rejected by: Nevil Brownlee
Date Rejected: 2011-03-28

Section 5.2 says:

   Attributes of <configure_conference>:

   o  reservedtalkers - optional (see note), no default value: The
      maximum number of talker legs allocated for the conference.  Note:
+     required when establishing the Conference Control Leg but optional
+     in subsequent <configure_conference> requests.

  o  reserveconfmedia - optional, default value "yes": Controls
      allocation of resources to enable playing or recording to or from
?     the entire conference.
?
?  When the reservedtalkers+1st INVITE arrives at the media server, the
   media server SHOULD generate a 486 Busy Here response.  Failure to
   send a 486 response to this condition can cause the media server to
   oversubscribe its resources.

It should say:

< amended/clarified text should be supplied by authors >

Notes:

The text spanning from page 12 to page 13 lacks of precision.

In the first bullet, it precisely specifies in which kind of leg
the attribute applies.
Similar information is missing entirely from the second bullet.
Also, it is not unambiguously clear whether "reservedtalkers+1st INVITE"
shall count the control leg or not.

Without added clarification, interoperability might suffer.

Authors response: In four years of deployment, no one has run into a real problem in the real world. No change needed.

--VERIFIER NOTES--

Errata ID: 1237
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Rejected by: Nevil Brownlee
Date Rejected: 2011-03-28

Section 6.1.1 says:

URL       and        URLs

It should say:

URI       and        URIs

Notes:

Throughout Section 6.1.1. ff., the RFC should better use
IETF standard terminology as codified in STD 66, RFC 3986.

In particular, the attribute name "baseurl" is a misnomer
and should better have been named "baseuri" (bottom of page 24).
--VERIFIER NOTES--
Author comment: Sounds editorial to me. If you want to change it everywhere, go for it. Changing baseurl to baseuri would change the protocol. Since it really is a seven-character string that seems to mean something, no harm in leaving it as is.

Errata ID: 1238
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Rejected by: Nevil Brownlee
Date Rejected: 2011-03-28

Section 6.1.1 says:

   o  locale - optional, no default value: Specifies the language and
      country variant used for resolving spoken variables.  The language
      is defined as a two-letter code per ISO 639.  The country variant
      is also defined as a two-letter code per ISO 3166.  These codes
      are concatenated with a single underscore (%x5F) character.

It should say:

< to be specified >

Notes:

The RFC should better apply existing IETF standards and not
try to establish ad-hoc usage conventions and/or syntaxes
for details already well specified in the IETF.

In particular, it is considered an error (on top of page 26)
to not apply, and refer to, RFC 4646 (BCP 47) for the
definition of language tags.
RFC 4646 deliberately has modified and extended the earlier
conventions roughly corresponding to what is described here.
--VERIFIER NOTES--
Authors comment: BCP 47 wasn't out yet when the base spec was published.
A new protocol - hence a new RFC - should make the changes suggested here.

Errata ID: 1244
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Rejected by: Nevil Brownlee
Date Rejected: 2011-03-28

Section 6.1.1.1 p.29 says:

   Attributes of <variable>:

   o  type - required, no default value: Specifies the major type format
      of the spoken variable to be played.  Allowable values are "dat"
      (date), "dig" (digit), "dur" (duration), "mth" (month), "mny"
      (money), "num" (number), "sil" (silence), "str" (string), "tme"
      (time), and "wkd" (weekday).

   o  subtype - optional, no default value: Specifies the minor type
      format of the spoken variable to be played.  Allowable values
      depend on the value of the corresponding "type" attribute.
      Possible values are "mdy", "ymd", and "dmy" for dates, "t12" and
      "t24" for times, "gen", "ndn", "crd", and "ord" for digits, and
      "USD" for money.

It should say:

< see Notes >

Notes:

The RFC here underspecifies many important details necessary
to be specified precisely to ensure interoperability:

a) What is the intended range of values for "wkd" ?
I guess, it may be "0", ..., "6" .
Or is it "1", ..., "7" ??
(Textual values make no sense -- or at least would make
implementations overly complicated requiring an any-language
to any-languange translation facility -- because the value
needs to be played out in the intended language according
to effective preferences.)

b) What are "gen", "ndn", "crd", and "ord" ?
No details are given to explain these abbreviations, and
most RFC readers will not be accustomed either to them.
I guess that "ord" might mean 'ordinal', "crd" be
'cardinal', and perhaps "gen" for 'generic', but "ndn" ?
The semantics need to be specified carefully for interoperability!

c) Another instance of overly US-centric thinking is the single "USD"
for money. To ensure wide-spread applicability and maintainability
of the protocol, the RFC should better apply the standard method
of incorporating the applicable 'official' registry by *reference*,
which in this case is the list of monetary units and their
internationally agreed-upon / assigned three-character
abbreviations from the ISO 4217 Maintenance Agency.
--VERIFIER NOTES--
Authors comment: This is an Informational RFC, not a Standards Track one.

Errata ID: 1253
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Rejected by: Nevil Brownlee
Date Rejected: 2011-03-28

Section 9.2 says:

   Attributes of <faxplay>:

   o  lclid - optional, default value "" (the empty string): A string
      that identifies the called station.

It should say:

   Attributes of <faxplay>:

   o  lclid - optional, default value "" (the empty string): A string
|     that identifies the calling station.

Notes:

I suspect that the RFC specifies the wrong station ID.
In Section 9.1, "lclid" clearly specifies the PSTN 'role'
the Media Server shall assume in processing a fax in answer mode;
there, it makes no sense to specify an identity that is not under
control of the media server accepting the incoming call.
Similarly, for <faxplay> in Section 9.2, the local ID the Media
Server shall assume in sending the fax needs to be specified;
as far as I understand the text, the Media Server is the *calling*
station in this scenario.
Should I be wrong with this diagnosis, perhaps other claraifcation(s)
to the RFC are needed.
--VERIFIER NOTES--
Authors comment: Incorrect diagnosis.

Errata ID: 1232
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Rejected by: Nevil Brownlee
Date Rejected: 2011-03-28

Section 5.1, page 11 says:

   When the conference is created by sending an INVITE containing a
   MSCML <configure_conference> payload, the resulting SIP dialog is
|  termed the "Conference Control Leg."  This leg has several useful
   properties.  The lifetime of the conference is the same as that of

It should say:

   When the conference is created by sending an INVITE containing a
   MSCML <configure_conference> payload, the resulting SIP dialog is
|  termed the "Conference Control Leg".  This leg has several useful
   properties.  The lifetime of the conference is the same as that of

Notes:

Syntax error in second paragraph on page 11.
(Period is not part of the term.)
Please apply 'rational quotation' !
--VERIFIER NOTES--
This (period inside the quote marks) is a common typographic convention, especially among LaTeX users.

Errata ID: 1250
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Rejected by: Nevil Brownlee
Date Rejected: 2011-03-28

Section 8, p.49-50 says:

MIME Type               or:              MIME type

(multiple instances each)

It should say:

Media Type               or:             media type

Notes:

a)
The RFC should apply IETF standard terminology.
In this case, it is clear that the RFC does *not* apply to the
context of email, and hence "MIME" should be avoided even more!
Please use the terminology established in RFC 2045 ff. !

b)
Furthermore, Table 3 on page 50 contains a couple of questionable
entries:
audio/x-alaw-basic is a private media type;
audio/ms-gsm looks like an IETF tree media subtype,
but it has not been registered with the IANA;
audio/x-wav is also a private media type; I guess it should
better be audio/vnd.wave (RFC 2361)
-- although the IANA apparently has lost
records of this media type registration.
--VERIFIER NOTES--
Authors comment: In four years of deployment, no one has run into a real problem in the real world. This is not a standards track RFC.

Errata ID: 1252
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-04
Rejected by: Nevil Brownlee
Date Rejected: 2011-03-28

Section 9.1 says:

a)
     URL


b)
     ://

c)

          ... it MUST match remote terminal's identifier, ...

It should say:

a)
     URI


b)
                     (nothing!)

c)

          ... it MUST match the remote terminal's identifier, ...

Notes:

Again, this section should apply strict IETF established terminology,
as per STD 66, RFC 3986; it contains a wealth of badly formed said
[URI] schemes.

Throughout the section,
a) replace "URL" by "URI" , and
b) use the precise forms of the URI schemes mentioned,
i.e. "file" , "http" , "https" .

c) In Table 4 on page 52, insert the missing article in the
5th line from the bottom.
--VERIFIER NOTES--
Authors comment: In four years of deployment, no one has run into a real problem in the real world.

RFC 5031, "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", January 2008

Note: This RFC has been updated by RFC 7163

Source of RFC: ecrit (rai)

Errata ID: 6359
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dale R. Worley
Date Reported: 2020-12-19
Rejected by: Barry Leiba
Date Rejected: 2020-12-22

Section 4.2, 7.2 says:

In section 4.2:

The 'sos' service type describes emergency services requiring an
immediate response, typically offered by various branches of the
government or other public institutions.

It should say:

In section 4.2, add a reference:

The 'sos' service type describes emergency services requiring an
immediate response, typically offered by various branches of the
government or other public institutions. [IRC]

In section 7.2, add a reference:

[IRC] Service Regulations annexed to the International Radiotelegraphic
Convention, Berlin, 1906, section 6. a., article XVI.
https://babel.hathitrust.org/cgi/pt?id=hvd.32044103239133&view=1up&seq=36

Notes:

The referenced section of the protocols of the convention is "Ships in distress make use of the following signal: . . . - - - . . . repeated at short intervals. ...".
--VERIFIER NOTES--
Thanks for suggesting the reference, and it's interesting to have a source that shows where the "sos" term started.

It's not an error, though: the RFC is correct as published, and there was never an intent to cite a reference there. So as an errata report, this is rejected... with encouragement for interested readers to look at the historic reference.

RFC 5035, "Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility", August 2007

Source of RFC: smime (sec)

Errata ID: 1480
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Kurt Zeilenga
Date Reported: 2008-07-30
Rejected by: Sean Turner
Date Rejected: 2010-04-20

Section Appendix A says:

SecurityCategory ::= SEQUENCE {
  type  [0] OBJECT IDENTIFIER,
  value [1] ANY DEFINED BY type
}

It should say:

SecurityCategory ::= SEQUENCE {
  type  [0] OBJECT IDENTIFIER,
  value [1] EXPLICIT ANY DEFINED BY type
}

Notes:

The RFC incorporates a bad ASN.1 construction from X.411. This construction was corrected in X.501 documents (see 2005). The tag on the value must be EXPLICIT otherwise it will be replaced by whatever tag the type used in the ANY calls for.
--VERIFIER NOTES--
An implicit tagged followed by an open type is converted to an explicit tag followed by an open type by the compiler.

Errata ID: 6735
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Ernst Lawende
Date Reported: 2021-11-12
Rejected by: RFC Editor

Section 4 says:

        ESSCertIDv2 ::=  SEQUENCE {
            hashAlgorithm           AlgorithmIdentifier
                   DEFAULT {algorithm id-sha256},
            certHash                 Hash,
            issuerSerial             IssuerSerial OPTIONAL
        }

It should say:

        ESSCertIDv2 ::=  SEQUENCE {
            hashAlgorithm           AlgorithmIdentifier
                   DEFAULT {id-sha256},
            certHash                 Hash,
            issuerSerial             IssuerSerial OPTIONAL
        }

Notes:

No value assignment for 'algorithm' exists, and the definition of id-sha256 already contains the full object identifier.
--VERIFIER NOTES--
Errata rejected per request from Russ Housley

RFC 5036, "LDP Specification", October 2007

Note: This RFC has been updated by RFC 6720, RFC 6790, RFC 7358, RFC 7552

Source of RFC: mpls (rtg)

Errata ID: 3416
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Jeff Wheeler
Date Reported: 2012-11-26
Rejected by: Adrian Farrel
Date Rejected: 2012-11-26

Section 3.1 says:

For a platform-wide label space, these SHOULD both be zero.

It should say:

For a platform-wide label space, these MUST both be zero.

Notes:

See Section 2.2.2 text, "The last two octets of LDP Identifiers for platform-wide label spaces are always both zero."
--VERIFIER NOTES--
The text in 2.2.2 is descriptive of the LDP identifiers, but not a requirement. The text in 3.1 describes how the LDP identifier is constructed.

The purpose of the "SHOULD" is to direct normal behavior, but not to absolutely require the use of zero in these two octets if a good reason can be found.

Furthermore, there is nothing that would actually prohibit the use of non-zero values. The identifier of a label space is a local matter and another node, seeing a label space identifier, should not make any assumptions about the label space (e.g., it being a global label space or not), nor should it really matter.

Errata ID: 4465
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Guijuan Wang
Date Reported: 2015-09-05
Rejected by: Deborah Brungard
Date Rejected: 2015-11-18

Section 3.5.3 says:

The first rule: 
In section 3.5.3 
   A, Label Advertisement Discipline
         [omitting the first paragraph]

         If one LSR proposes Downstream Unsolicited and the other
         proposes Downstream on Demand, the rules for resolving this
         difference is:

         -  If the session is for a label-controlled ATM link or a
            label-controlled Frame Relay link, then Downstream on Demand
            MUST be used.

         -  Otherwise, Downstream Unsolicited MUST be used.


The second rule: 
In section 3.5.7.1.3.

   In general, the upstream LSR is responsible for requesting label
   mappings when operating in Downstream on Demand mode.  However,
   unless some rules are followed, it is possible for neighboring LSRs
   with different advertisement modes to get into a livelock situation
   where everything is functioning properly, but no labels are 
   distributed.  For example, consider two LSRs Ru and Rd where Ru is
   the upstream LSR and Rd is the downstream LSR for a particular FEC.
   In this example, Ru is using Downstream Unsolicited advertisement
   mode and Rd is using Downstream on Demand mode.  In this case, Rd may
   assume that Ru will request a label mapping when it wants one and Ru
   may assume that Rd will advertise a label if it wants Ru to use one.
   If Rd and Ru operate as suggested, no labels will be distributed from
   Rd to Ru.

   This livelock situation can be avoided if the following rule is
   observed: an LSR operating in Downstream on Demand mode SHOULD NOT be
   expected to send unsolicited mapping advertisements.  Therefore, if
   the downstream LSR is operating in Downstream on Demand mode, the
   upstream LSR is responsible for requesting label mappings as needed.

It should say:

[not provided]

Notes:

Label advertisement mode negotiation rule is different in two sections.

when the label advertisement mode is different between LSR peers,
the resolving rule is defined twice in two chapters,
both use "must" or "SHOULD NOT", but they are completely different.

It's better to settle down which rule to use for this case.
Seems the first one is simpler for implementation.

Or if you want to keep both rules,
better to enumerate both of those two rules in each section,
and say the implementer can choose any of them.

--VERIFIER NOTES--
This suggested errata requires an update to the RFC, which requires consensus.

Errata ID: 4512
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Jiessie
Date Reported: 2015-10-26
Rejected by: Deborah Brungard
Date Rejected: 2015-11-18

Section 2.5.2 says:

2.4.1.  Basic Discovery Mechanism

   To engage in LDP Basic Discovery on an interface, an LSR periodically
   sends LDP Link Hellos out the interface.  LDP Link Hellos are sent as
   UDP packets addressed to the well-known LDP discovery port for the
   "all routers on this subnet" group multicast address.


2.5.2.  Transport Connection Establishment

   Note that when an LSR sends a Hello, it selects the transport address
   for its end of the session connection and uses the Hello to advertise
   the address, either explicitly by including it in an optional
   Transport Address TLV or implicitly by omitting the TLV and using it
   as the Hello source address.

Notes:

According to 2.4.1, an LSR send Hellos to "all routers on this subnet", the eligible reception LSR should be on this subnet.

2.5.2 states that one way for an LSR to advertise Transport Address is to uses it as Hello source address.

On the topology below, LSRa uses 1.1.1.1 as Transport Address and sends Hello(source:1.1.1.1 destination:224.0.0.2) to LSRb.
LSRb will ignore this packet which is not on its interface subnet.

1.1.1.1
|LSRa|--------------|LSRb|
10.1.1.1 10.1.1.2

My question is:
What's the scenario to use "implicitly" way to send Hello?
--VERIFIER NOTES--
This is not an errata, it is a question to be asked on the MPLS mailing list.

Errata ID: 5597
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramakrishna Rao DTV
Date Reported: 2019-01-10
Rejected by: Deborah Brungard
Date Rejected: 2019-01-10

Section 2.5.3 says:

   The session establishment setup attempt following a NAK'd
   Initialization message MUST be delayed no less than 15 seconds, and
   subsequent delays MUST grow to a maximum delay of no less than 2
   minutes.  The specific session establishment action that must be
   delayed is the attempt to open the session transport connection by
   the LSR playing the active role.

It should say:

   The session establishment setup attempt following a NAK'd
   Initialization message MUST be delayed no less than 15 seconds, and
   subsequent delays MUST grow to a maximum delay of no more than 2
   minutes.  The specific session establishment action that must be
   delayed is the attempt to open the session transport connection by
   the LSR playing the active role.

Notes:

In the 3rd line, "less" is changed to "more".

The intention is to cap the maximum delay. But the existing text implies no cap
essentially.
--VERIFIER NOTES--
This change is a technical change as it changes from no cap to a cap of 2 minutes. This request needs to go via the consensus process (e.g. RFC).

RFC 5050, "Bundle Protocol Specification", November 2007

Source of RFC: IRTF

Errata ID: 2694
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-01-28
Rejected by: Lars Eggert
Date Rejected: 2012-02-07

Section 10.1 says:

[URIREG]   Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
           Registration Procedures for New URI Schemes", RFC 4395,
           BCP 115, February 2006.

It should say:

[URIREG]   Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
           Registration Procedures for New URI Schemes", RFC 4395,
           BCP 35, February 2006.

Notes:

BCP number 115 has been mistakenly assigned to RFC 4395. RFC 4395 os BCP 35.
--VERIFIER NOTES--
Rejected after IRSG discussion.

RFC 5056, "On the Use of Channel Bindings to Secure Channels", November 2007

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 3247
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sujing Zhou
Date Reported: 2012-06-06
Rejected by: Sean Turner
Date Rejected: 2012-07-02

Section 2 says:

there are no MITMs between the two end-points at that higher 
network layer.  

It should say:

there are no MITMs between the two end-points at that lower 
network layer.  

Notes:

Typo in definition

--VERIFIER NOTES--
From the RFC:

Generally, some data that "names" a channel or one or both of its end-points such that if this data can be shown, at a higher network layer, to be the same at both ends of a channel, then there are no MITMs between the two end-points at that higher network layer. This term is used as a noun.

RFC 5060, "Protocol Independent Multicast MIB", January 2008

Source of RFC: pim (rtg)

Errata ID: 1447
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-06-14
Rejected by: Adrian Farrel
Date Rejected: 2011-09-28

Section 5, pg.32 ff. says:

Notes:

The description clauses of many columnar objects in the
PIM (*,G) State Table are underspecified:
If an object is "used with" a specific variant of PIM,
what is the desired behavior for other variants?
- shall the object be instantiated or not?
- if yes, what's the default / substitute value in this case?
- shouldn't such defaults be listed in DEFAULT clauses ?

Similar deficiencies also exist in the descriptions of objects
in other MIB tables in this MIB module.
--VERIFIER NOTES--
I don't see this as underspecified at all. In fact, objects like pimSGPimMode
and pimStaticRPPimMode are very specific in only supporting a limited range of
modes for the entire table. In effect, if another mode is in use, the table
cannot be used by definition.

Errata ID: 1448
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-06-14
Rejected by: Adrian Farrel
Date Rejected: 2011-09-28

Section 5, pg.47/48 says:

pimSGUpstreamPruneState OBJECT-TYPE
    SYNTAX     INTEGER {
 |                forwarding (1),
                  ackpending (2),
                  pruned (3)
               }
    ...
    DESCRIPTION
            "Whether the local router has pruned itself from the tree.
            This corresponds to the state of the upstream prune (S,G)
|           state machine in the PIM-DM specification.  This object is
|           used only by PIM-DM."

Notes:

The DESCRIPTION clause says: "This object is used only by PIM-DM."
Does this mean: "This object is only instantiated for PIM-DM." ?
Otherwise, the alternative:
noinfo(0),
should perhaps be allowed in the SYNTAX clause and be the DEFAULT.

Similar issues exist for the subsequent columnar objects,
pimSGUpstreamPruneLimitTimer, pimSGOriginatorState,
pimSGSourceActiveTimer, and pimSGStateRefreshTimer.

Also, there's no hint in the RFC why the other applicable
timers, GraftRetryTimer and OverrideTimer have not been
modeled in this MIB module.
--VERIFIER NOTES--
There are two issues in this Erratum...

1. "This object is only used..."

I interpret this to mean that an attempt to read the object in
other cases would return an error. Thus I don't see a problem
with the current text, and reject this part of the Erratum

2. "other timers are not modelled" Specifically:

GraftRetryTimer - I see pimInterfaceGraftRetryInterval
OverrideTimer - I see pimInterfaceOverrideInterval

The question is: why can't I see how the timer is running?
This looks like function that could have been added to the
MIB module, but was not.

However, someone who wants this function can add if they
feel inspired by revising the module or writing a new one.

RFC 5080, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", December 2007

Source of RFC: radext (sec)

Errata ID: 4476
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Wang
Date Reported: 2015-09-17
Rejected by: Kathleen Moriarty
Date Rejected: 2015-09-22

Section Section 2 says:

Section 2.1.1. page 6:
Any Access-Request packet that performs authorization checks,
including Call Check, SHOULD contain a Message-Authenticator
attribute.

section 2.2.2 page 11:
However, Access-Request packets not containing a Message-
Authenticator attribute always affect the cache, even though they may
be trivially forged.  To avoid this issue, server implementations may
be configured to require the presence of a Message-Authenticator
attribute in Access-Request packets.  Requests not containing a
Message-Authenticator attribute MAY then be silently discarded.

Client implementations SHOULD include a Message-Authenticator
attribute in every Access-Request to further help mitigate this
issue.

It should say:

Section 2.1.1. page 6:
Any Access-Request packet that performs authorization checks,
including Call Check, Must contain a Message-Authenticator
attribute.

section 2.2.2 page 11:
However, Access-Request packets not containing a Message-
Authenticator attribute always affect the cache, in some case 
such forgery is not trivial.  To avoid this issue, server 
implementations MUST be configured to require the presence of 
a Message-Authenticator attribute in Access-Request packets.  
Requests not containing a Message-Authenticator attribute 
MAY then be silently discarded.

Client implementations MUST include a Message-Authenticator
attribute in every Access-Request to further help mitigate this
issue.

Notes:

Message-Authenticator attribute defined in [RFC3579] is mandatory attribute for IEEE802.1x EAP User and optional attribute for other type of users. In RFC5080, the message-authenticator is used as an optional attribute. However in practice, Radius Implementation without Message-Authenticator attribute for Integrity check protection has become serious issue.
The attacker can take advantage of Access-Request packets not containing a Message-Authenticator attribute to perform authentication successfully.
Alternatively,the attacker can capture the packet and delete message-authenticatorattribute.
If the server do not check the message-authenticator attribute, the attacker can pass the authentication as well.
--VERIFIER NOTES--
This suggested errata would result in a normative change to the RFC, which requires consensus. The conversation has been moved to the RADext list to see if an update to the RFC is appropriate or not.

RFC 5084, "Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)", November 2007

Source of RFC: smime (sec)

Errata ID: 4774
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: QUAN NGUYEN
Date Reported: 2016-08-11
Rejected by: Kathleen Moriarty
Date Rejected: 2018-03-19

Section 3.2 says:

aes-ICVlen       AES-GCM-ICVlen DEFAULT 12

A length of 12 octets is RECOMMENDED.

It should say:

aes-ICVlen       AES-GCM-ICVlen DEFAULT 16

A length of 16 octets is RECOMMENDED.

Notes:

Many JCE providers including OpenJDK, BouncyCastle, Conscrypt have a bug to use 12 bytes authentication tag (aes-ICVlen) as default if the code path [1] uses CMS. According to Ferguson's attack (http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-GCM/Ferguson2.pdf), if a user encrypts 2^32 block length message, then 12 bytes authentication tag length has only 96 - 32 = 64 bits security which is not good enough nowadays. Furthermore, once a forgery happens then authentication is leaked.

[1] In other code paths, all providers use 16 bytes authentication tag as default.

------
AD Note: through on list discussions, it is clear this errata should be rejected.

The first half of this errata must be rejected. We do not change the ASN.1
for something like this under just about any circumstances.

Changing the recommendation of a value should probably not be done by an
erratum but by publishing a new document. We could make discuss and make
the recommendation change in the new S/MIME document in the LAMPS group
rather than in this document.

A possible way forward is a short draft that updates RFC 5084 to recommend the use of 16 octet authentication tags in all situations.
--VERIFIER NOTES--
AD Note: through on list discussions, it is clear this errata should be rejected.

The first half of this errata must be rejected. We do not change the ASN.1
for something like this under just about any circumstances.

Changing the recommendation of a value should probably not be done by an
erratum but by publishing a new document. We could make discuss and make
the recommendation change in the new S/MIME document in the LAMPS group
rather than in this document.

A possible way forward is a short draft that updates RFC 5084 to recommend the use of 16 octet authentication tags in all situations.

RFC 5087, "Time Division Multiplexing over IP (TDMoIP)", December 2007

Source of RFC: pwe3 (int)

Errata ID: 1219
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-03
Rejected by: Stewart Bryant
Date Rejected: 2011-08-04

Section 7.3 says:

                                                 vvv
      1.  If the TDMoIP PW has been set up using the PWE3 control
      protocol [RFC4447], the regular PW teardown procedures of these
      protocols SHOULD be used.
      ^^^^^^^^^                                   ^^^^^^^^^^^^^^^^^^^^

It should say:

      1.  If a TDMoIP PW over MPLS has been set up using the PWE3 control
      protocol [RFC4447], the regular PW teardown procedures of that
      protocol SHOULD be used.

Notes:

In the last part of Section 7.3, on mid-page 27, the RFC again does
not fulfill its promises of covering all kind of PW technology.
The first part of the sentence above again only talks about a single
control protocol - RFC 4447 (PW setup & maintenance for MPLS using LDP),
but the second part inconsistently says "procedures of these protocols".
So what about L2TPv3 ???

The text needs to be restricted in scope and made consistent as proposed
in the NEW text, or it needs to be expanded to cover L2TPv3 as well.
--VERIFIER NOTES--
This (pre-RFc5611) text was correct at the time of publication.

Errata ID: 1220
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-03
Rejected by: Stewart Bryant
Date Rejected: 2011-09-13

Section 9 says:

   For MPLS PSNs, PW Types for TDMoIP PWs are allocated in [RFC4446].

It should say:

   For MPLS PSNs, PW Types for TDMoIP PWs have originally been allocated
   provisionally in [RFC4446]; IANA has updated the References for MPLS
   pseudowire types 0x0016 and 0x0018 (for TDMoIP AAL1 mode and TDMoIP
   AAL2 mode respectively) in the "pwe3-parameters" registry to point
   to RFC 5087.

   IANA has allocated two pseudowire type values for these encapsulations
   from the "L2TPv3 Pseudowire Types" sub-registry of the "l2tp-parameters"
   registry as follows:
         <TBD1>  -  TDMoIP AAL1 Mode             [RFC5087]
         <TBD2>  -  TDMoIP AAL2 Mode             [RFC5087]

Notes:

The IANA considerations given are incomplete and much too imprecise.

The net result is that IANA has *not* reparented the assignments
for TDMoIP to RFC 5087, leaving the registry inconsistent and
confusing for all but the real PWE3 gurus.

And it has been missed entirely to request allocation of L2TPv3
PW types for the two encapsulations described in RFC 5087.

The NEW text shows what IANA better should have been advised to do
during the publication process of RFC 5087.

Perhaps, it is not too late to have these allocations be performed
after the publication of RFC 5087.
--VERIFIER NOTES--
The PW types registry has been updated so that types 0x16 and 0x18 now point to RFC5087. There seems to be limited value to the reader of RFC5087 in directing them to an erratum describing this registry update.

RFC5611 is the document that describes the signalling for TDM PWs using L2TPv3 and allocation of associated code points.

Errata ID: 1221
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-03
Rejected by: Stewart Bryant
Date Rejected: 2011-08-04

Section App. A says:

      if D > 0 then
        { packets expected, expected+1, ... received-1 are lost }
         while not over-run
           place filler (all-ones or interpolation) into playout buffer
           if not over-run then
             place packet contents into playout buffer
           else
             discard packet contents
           set expected = (received + 1) mod 2^16
       else  { late packet arrived }
         [...]

It should say:

       if D > 0 then
         { packets expected, expected+1, ... received-1 are lost }
         while not over-run  and  D > 0
           place filler (all-ones or interpolation) into playout buffer
           set D = D - 1
         if not over-run then
           place packet contents into playout buffer
         else
           discard packet contents
         set expected = (received + 1) mod 2^16
       else  { late packet arrived }
         [...]

Notes:

The pseudocode on mid-page 31 is severely flawed.
The counter value 'D' is never decremented and hence almost useless.
The code will erroneously loop until over-run.
Also, the final treatment must be taken out of the loop,
which needs to be indicated by reducing the indentation of 5 lines
by two character positions.
--VERIFIER NOTES--
D is a local temporary variable that is recalculated whenever a new packet is received and the condition (received = expected) is false. The scope of D is the else condition in which it is calculated.

Errata ID: 1209
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-03
Rejected by: Stewart Bryant
Date Rejected: 2011-08-04

Section 1, 5th para says:

   As with all PWs, TDMoIP PWs may be manually configured or set up
   using the PWE3 control protocol [RFC4447].  Extensions to the PWE3
   control protocol required specifically for setup and maintenance of
   TDMoIP pseudowires are described in [TDM-CONTROL].

It should say:

|  As with all PWs over MPLS, TDMoIP PWs may be manually configured or set
   up using the PWE3 control protocol [RFC4447].  Extensions to the PWE3
   control protocol required specifically for setup and maintenance of
|  TDMoIP pseudowires over MPLS are described in [TDM-CONTROL].

Notes:

The RFC pretends to cover all kinds of PWs; RFC 4447 only applies
to PWE3 over MPLS (with LDP signaling).
Either the abover text needs to be restricted in scope as porposed in the NEW
text or it should be amended to correctly cover the L2TPv3 case as well.
--VERIFIER NOTES--
This was correct at the time of publication. It was only with the later publication of RFC5611 that it became possible to signal L2TPv3 TDM PWs.

RFC 5106, "The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method", February 2008

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 1339
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-03
Rejected by: Sean Turner
Date Rejected: 2010-07-30

Section 7, pg.15 says:

   o  The packet contains an Encrypted payload that, when decrypted with
|     the appropriate key, yields an invalid decryption.

It should say:

   o  The packet contains an Encrypted payload that, when decrypted with
|     the appropriate key, yields an invalid plaintext.
                                             ^^^^^^^^^

Notes:

Location 1 first bullet on page 15.
--VERIFIER NOTES--
Document editor's choice.

RFC 5109, "RTP Payload Format for Generic Forward Error Correction", December 2007

Source of RFC: avt (rai)

Errata ID: 1226
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Adam Li
Date Reported: 2008-01-03
Rejected by: Robert Sparks
Date Rejected: 2010-10-28

Section 9.1 says:

In Step 13,

      13. Take the next 16 bits of the recovery bit string.  Whatever
          unsigned integer this represents (assuming network-order),
          take that many bytes from the recovery bit string and append
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
          them to the new packet.  This represents the CSRC list,
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
          extension, payload, and the padding of the RTP payload.

It should say:

      13. Take the next 16 bits of the recovery bit string.  Whatever
          unsigned integer this represents (assuming network-order),
          it represents the cumulative length of the CSRC list,
          ^^            ^^^^^^^^^^^^^^^^^^^^^^^^
          extension, payload, and the padding of the RTP payload
          of the packet to be recovered.
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Notes:

--VERIFIER NOTES--
From Peter Musgrave's review:
Editorial: rephrases a step in the instructions for RTP header reconstruction
Action: Rejected (In my opinion the new text is not significantly clearer and the use of the word cumulative is a bit confusing).

RFC 5148, "Jitter Considerations in Mobile Ad Hoc Networks (MANETs)", February 2008

Source of RFC: manet (rtg)

Errata ID: 1735
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Thomas Clausen
Date Reported: 2009-03-22
Rejected by: Adrian Farrel
Date Rejected: 2011-08-04

Section 7.2 says:

   [7]  Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized
        MANET Packet/Message Format", Work in Progress.

It should say:

   [7]  Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
              "Generalized MANET Packet/Message Format", RFC 5444,
              February 2009.

Notes:

draft-ietf-manet-packetbb ("Generalized MANET Packet/Message Format") was published as RFC5444. RFC5148 should, therefore, reference this archival document (RFC5444) rather than the Internet Draft.
--VERIFIER NOTES--
At the time of publication of RFC 5148 (February 2008), RFC 5444 had not been published and could only be cited as an Internet-Draft. RFC 5444 was not published until February 2009.

A future update of RFC 5148 can resolve this. Otherwise, the IETF's datatracker resolves the reference for the inquisitive reader.

RFC 5155, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", March 2008

Note: This RFC has been updated by RFC 6840, RFC 6944, RFC 9077, RFC 9157, RFC 9276

Source of RFC: dnsext (int)

Errata ID: 3479
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Andy Newton
Date Reported: 2013-02-07
Rejected by: Ralph Droms
Date Rejected: 2013-03-10

Appendix A

The example in Appendix A has an NSEC3 next hashed owner name field 
with the non-base 32 characters 9, 0, and 1.

It should say:

The example should be changed so that the field in question is 
valid base 32.

Notes:

--VERIFIER NOTES--
The example actually uses base32hex (see RFC 4648) and is, therefore, valid.

RFC 5162, "IMAP4 Extensions for Quick Mailbox Resynchronization", March 2008

Note: This RFC has been obsoleted by RFC 7162

Source of RFC: lemonade (app)

Errata ID: 3322
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Jan Kundrát
Date Reported: 2012-08-16
Rejected by: Pete Resnick
Date Rejected: 2013-01-28

Section 3.6 says:

A VANISHED response sent because of an EXPUNGE or UID EXPUNGE command
or because messages were expunged in other connections (i.e., the
VANISHED response without the EARLIER tag) also decrements the number
of messages in the mailbox; it is not necessary for the server to
send an EXISTS response with the new value.  It also decrements
message sequence numbers for each successive message in the mailbox
(see the example at the end of this section).  Note that a VANISHED
response caused by EXPUNGE, UID EXPUNGE, or messages expunged in
other connections SHOULD only contain UIDs for messages expunged
since the last VANISHED/EXPUNGE response sent for the currently
opened mailbox or since the mailbox was opened.  That is, servers
SHOULD NOT send UIDs for previously expunged messages, unless
explicitly requested to do so by the UID FETCH (VANISHED) command.

Note that client implementors must take care to properly decrement
the number of messages in the mailbox even if a server violates this
last SHOULD or repeats the same UID multiple times in the returned
UID set.  In general, this means that a client using this extension
should either avoid using message numbers entirely, or have a
complete mapping of UIDs to message sequence numbers for the selected
mailbox.

It should say:

A VANISHED response sent because of an EXPUNGE or UID EXPUNGE command
or because messages were expunged in other connections (i.e., the
VANISHED response without the EARLIER tag) also decrements the number
of messages in the mailbox; it is not necessary for the server to
send an EXISTS response with the new value.  It also decrements
message sequence numbers for each successive message in the mailbox
(see the example at the end of this section).

Note that a VANISHED response caused by EXPUNGE, UID EXPUNGE, or
messages expunged in other connections MUST only contain UIDs for
messages expunged since the last VANISHED/EXPUNGE response sent for
the currently opened mailbox or since the mailbox was opened.  That is,
servers MUST NOT send UIDs for previously expunged messages, unless
explicitly requested to do so by the UID FETCH (VANISHED) command.
This is required to prevent a possible race condition where new arrivals
for which the UID is not yet known by the client are expunged.

Notes:

If the servers were allowed to send VANISHED responses referring to non-existing UIDs, there's a possible race condition when new arrivals are expunged. This is due to the sequence-UID assymetry of EXISTS vs. VANISHED.

New arrivals are reported through EXISTS and their UIDs are not known to the client. Suppose the following scenario where two messages exist and their UIDs are 10 and 11. Two more messages arrive:

* 4 EXISTS
* VANISHED 12:20

The client has no way of knowing whether the two new arrivals have UIDs falling into the 12:20 range. As such, the client doesn't know whether there are two, three or four messages in the mailbox at this point.

See http://mailman2.u.washington.edu/pipermail/imap-protocol/2012-June/001781.html for details.
--VERIFIER NOTES--
This is a clear change to the intention of the document and is too large a change to be appropriate to an erratum. There is a problem here, but it is more properly handled by new work, which is being undertaken as http://datatracker.ietf.org/doc/draft-kundrat-qresync-arrived/

Errata ID: 3323
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Jan Kundrát
Date Reported: 2012-08-16
Rejected by: Pete Resnick
Date Rejected: 2012-11-04

Throughout the document, when it says:

The "ENABLE QRESYNC"/"ENABLE QRESYNC CONDSTORE" command
also tells the server that it SHOULD start sending VANISHED responses
(see Section 3.6) instead of EXPUNGE responses.

It should say:

The "ENABLE QRESYNC"/"ENABLE QRESYNC CONDSTORE" command
also tells the server that it MUST start sending VANISHED responses
(see Section 3.6) instead of EXPUNGE responses.

Notes:

The explicit allowance for EXPUNGE being sent instead of VANISHED means that clients still have to maintain a full sequence-to-UID mapping, otherwise there is a risk of losing synchronization. Given that QRESYNC itself is an optional extension, I find it hard to imagine a case where the server cannot send a proper VANISHED response.

If this errata gets accepted, it will require rather heavy editing of the document; the notion of EXPUNGE responses being allowed is followed throughout the whole RFC, including the examples.
--VERIFIER NOTES--
The fact that this is a change to a normative requirement of the document, and (as the notes say) the fact that it would cause extensive changes to the rest of the document, makes it inappropriate as an erratum.

RFC 5176, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", January 2008

Note: This RFC has been updated by RFC 8559

Source of RFC: radext (sec)

Errata ID: 3103
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Davide Magistri
Date Reported: 2012-02-03
Rejected by: Benoit Claise
Date Rejected: 2012-07-26

Section 7 says:

Disconnect Request with User-Name:

       0: xxxx xxxx xxxx xxxx xxxx 2801 001c 1b23    .B.....$.-(....#
      16: 624c 3543 ceba 55f1 be55 a714 ca5e 0108    bL5C..U..U...^..
      32: 6d63 6869 6261

Disconnect Request with Acct-Session-ID:

       0: xxxx xxxx xxxx xxxx xxxx 2801 001e ad0d    .B..... ~.(.....
      16: 8e53 55b6 bd02 a0cb ace6 4e38 77bd 2c0a    .SU.......N8w.,.
      32: 3930 3233 3435 3637                        90234567

Disconnect Request with Framed-IP-Address:

       0: xxxx xxxx xxxx xxxx xxxx 2801 001a 0bda    .B....."2.(.....
      16: 33fe 765b 05f0 fd9c c32a 2f6b 5182 0806    3.v[.....*/kQ...
      32: 0a00 0203

It should say:

Disconnect Request with User-Name:

       0: xxxx xxxx xxxx xxxx xxxx 2801 001c 1b23    .B.....$.-(....#
      16: 624c 3543 ceba 55f1 be55 a714 ca5e 0108    bL5C..U..U...^..
      32: 6d63 6869 6261

Disconnect Request with Acct-Session-ID:

       0: xxxx xxxx xxxx xxxx xxxx 2801 001e ad0d    .B..... ~.(.....
      16: 8e53 55b6 bd02 a0cb ace6 4e38 77bd 2c0a    .SU.......N8w.,.
      32: 3930 3233 3435 3637                        90234567

Notes:

Since cardinality notation value for Framed-IP-Address attribute has now been changed in section 3.6 ("Table of Attributes") compared to previous 3576 RFC (change was from "0-1" to "0"), the "Disconnect Request with Framed-IP-Address" example in section 7 ("Example traces") should be removed.

Furthermore, a new bullet in "Appendix A. Changes from RFC 3576" should be foreseen (just like the one related to Service-Type Attribute), such as:
o Use of the Framed-IP-Address, Framed-Interface-Id and Framed-IPv6-Prefix Attributes within a Disconnect-Request is prohibited

Broadly speaking, one thing that seems to me a bit unclear is that Attributes such as Framed-IP-Address, Framed-Interface-Id and Framed-IPv6-Prefix are still valid session identifiers that could be present in CoA Requests, while they have been totally prohibited in Disconnect Requests ( even if they are mentioned as valid in section 3, end of page #10 ).
From my point of view, either it's misplaced the example in section 7 or cardinality notation values in Disconnect Message Table of Attributes (related to the ones mentioned above) should be changed back to "0-1" (I personally think this last option would be better).
--VERIFIER NOTES--
Rejected. See the resolution in errata 3294

RFC 5185, "OSPF Multi-Area Adjacency", May 2008

Source of RFC: ospf (rtg)

Errata ID: 3595
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Marek Karasek
Date Reported: 2013-04-17
Rejected by: Stewart Bryant
Date Rejected: 2013-05-06

Section 4 says:

   A link-LSA SHOULD NOT be advertised for a multi-area adjacency.  The
   neighbor's IPv6 link local address can be learned in other ways,
   e.g., it can be extracted from the IPv6 header of Hello packets
   received over the multi-area adjacency.  The neighbor IPv6 link local
   address is required for the OSPFv3 route next-hop calculation on
   multi-access networks (refer to Section 3.8.1.1 of [OSPFV3]).

It should say:

OSPFv3 supports two Address Families (AF), AF IPv6 and AF IPv4, using
separate instances [RFC 5338]. The route calculation differs for the
IPv4 and IPv6 address families with respect to the next-hop
determination. OSPFv3 instances supporting an IPv6 AF SHOULD learn the
IPv6 next-hop address from the IPv6 Header source address and SHOULD
NOT advertise a Link-LSA for a multi-area adjacency. However, for
OSPFv3 instances supporting an IPv4 AF, the next-hop address cannot be
learned from the OSPFv3 hellos and require advertisement of the
Link-LSA. Hence, OSPFv3 instances supporting an IPv4 AF SHOULD
advertise a Link-LSA for the a multi-area adjacency (refer to section
2.5 of [RFC 5838]). If the Link-LSA is not advertised, the OSPFv3
instance MAY learn the IPv4 next-hop address from the Link-LSA
advertised on the primary adjacency.

Notes:

RFC5185 describes next-hop calculation which is not applicable to OSPFv3 process supporting AF IPv4 as defined in RFC5838. Errata defines how RFC5838 OSPFv3 process supporting AF IPv4 calculates next-hop address on multi-area interface.
--VERIFIER NOTES--
This is a technical change and is thus cannot be addressed through the errata process. The correct process for addressing this concern is by writing a draft that updates RFC5158 and testing whether there is OSPF WG and IETF consensus for publication of the proposed update.

Errata ID: 6506
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Ketan Talaulikar
Date Reported: 2021-04-02
Rejected by: John Scudder
Date Rejected: 2021-05-17

Section 2.7 says:

   Multi-area adjacencies are announced as point-to-point links.  Once
   the router's multi-area adjacency reaches the FULL state, it will be
   added as a link type 1 to the Router Link State Advertisement (LSA)
   with:

      Link ID = Remote's Router ID

      Link Data = Neighbor's IP Address or IfIndex (if the underlying
      interface is unnumbered).

   Unlike numbered point-to-point links, no type 3 link is advertised
   for multi-area adjacencies.

It should say:

   Multi-area adjacencies are announced as point-to-point links.  Once
   the router's multi-area adjacency reaches the FULL state, it will be
   added as a link type 1 to the Router Link State Advertisement (LSA)
   with:

      Link ID = Remote's Router ID

      Link Data = Router interface's IP Address or IfIndex (if the underlying
      interface is unnumbered).

   Unlike numbered point-to-point links, no type 3 link is advertised
   for multi-area adjacencies.

Notes:

The encoding of Link Data as specified in RFC5185 is not consistent with the base OSPF specification in RFC2328. This has resulted in different behaviors in deployed implementations where some follow RFC2328 (i.e. the corrected text) while others follow the Original text of RFC5185 leading to interop issues.

More importantly, for implementations of RFC5185, it is not possible to determine the Neighbor's interface IfIndex unless some additional mechanisms (that have not been specified or referenced by RFC5185) are implemented - viz. RFC8510.

This topic has been discussed in the LSR WG recently and this errata is being raised to track this issue : https://mailarchive.ietf.org/arch/msg/lsr/iL85WkrqhI17wUrxd-WozMQvKtE/
--VERIFIER NOTES--
As discussed here (https://mailarchive.ietf.org/arch/msg/lsr/9IAkRCbZN39loWcwKjtNWfUW_qA/) this would be a technical change vs. the WG consensus when the document was progressed, and should be rejected (see https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/ #7). The appropriate way to pursue this looks to be an update or bis.

RFC 5198, "Unicode Format for Network Interchange", March 2008

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 3991
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-31
Rejected by: Pete Resnick
Date Rejected: 2014-05-16

Section 2, pg.3 says:

   3.  The control characters in the ASCII range (U+0000 to U+001F and
|      U+007F to U+009F) SHOULD generally be avoided.  Space (SP,
|      U+0020), CR, LF, and Form Feed (FF, U+000C) are exceptions to
|      this principle, but use of all but the first requires care as
       discussed elsewhere in this document.  The so-called "C1
       Controls" (U+0080 through U+009F), which did not appear in ASCII,
       MUST NOT appear.

It should say:

   3.  The control characters in the ASCII range (U+0000 to U+001F and
|      U+007F to U+009F) SHOULD generally be avoided. CR, LF, and
|      Form Feed (FF, U+000C) are exceptions to
|      this principle, but use of these requires care as
|      discussed elsewhere in this document.
|      Space (SP, U+0020) is often treated as a control character and
|      described that way in many documents.  It SHOULD NOT appear in
|      identifiers.  When used in more general strings, it should be
|      used with caution because Unicode supports a number of other
|      spacing characters (see, e.g., NO-BREAK SPACE (U+00A0) and the
|      collection of characters in the range 2000..200B that may or may
|      not be considered equivalent depending on the normalization and
|      other rules used.  The so-called "C1 Controls" (U+0080 through
|       U+009F), which did not appear in ASCII, MUST NOT appear.

Notes:

Logical inconsistency:
SPACE is not contained in the enumeration in the first sentence;
thus, it is no *exception* to that rule, and the published text
does not make proper sense.
--VERIFIER NOTES--
The part of this erratum which says:

It SHOULD NOT appear in identifiers. When used in more
general strings, it should be used with caution because
Unicode supports a number of other spacing characters
(see, e.g., NO-BREAK SPACE (U+00A0) and the collection
of characters in the range 2000..200B that may or may
not be considered equivalent depending on the
normalization and other rules used.

while possibly true, is not appropriate for an erratum. It is a substantive change.

RFC 5216, "The EAP-TLS Authentication Protocol", March 2008

Note: This RFC has been updated by RFC 8996, RFC 9190

Source of RFC: emu (sec)

Errata ID: 1392
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-26
Rejected by: Pasi Eronen
Date Rejected: 2008-12-04

Section 2.3,pg.19 says:

[lower part of Figure 2]

         |                       |                         |
         V                       V                         V
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                         |
   |                        MSK, EMSK                        |
   |               label == "client EAP encryption"          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             |             |
     | MSK(0,31)   | MSK(32,63)  | EMSK(0,63)
     |             |             |
     |             |             |
     V             V             V

                     Figure 2 - EAP-TLS Key Hierarchy

It should say:

         |                       |                         |
         V                       V                         V
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                         |
   |                        MSK, EMSK                        |
   |               label == "client EAP encryption"          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              |              |            |
|    | Enc-RECV-Key | Enc-SEND-Key | RECV-IV    | SEND-IV
|    |  =           |  =           |  =         |  =
|    | MSK(0,31)    | MSK(32,63)   | EMSK(0,31) | EMSK(32,63)
     |              |              |            |
     V              V              V            V

                     Figure 2 - EAP-TLS Key Hierarchy

Notes:

Rationale:

Figure 2 should be comparable to Figure 1, but it does not
show the final deliverables with their names as they appear
in the referenced documents.
Also, the figure is surprisingly unbalanced; it shows the split
of MSK, but it does not show the split of EMSK; I cannot detect
any reason for this difference.
The proposal above includes both these names and the technical
details of how these variables are derived from MSK and EMSK,
according to the formulae given near the bottom of page 18.

To avoid these technical details and better align the abstraction
level in the presentation with Figure 1, alternatively the second
and the third tagged line above (those with "=" and MSK/EMSK)
could be left off.
--VERIFIER NOTES--

The updated figure is wrong -- RECV-IV/SEND-IV are not derived from EMSK.

RFC 5226, "Guidelines for Writing an IANA Considerations Section in RFCs", May 2008

Note: This RFC has been obsoleted by RFC 8126

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: gen

Errata ID: 2684
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2011-01-13
Rejected by: Russ Housley
Date Rejected: 2011-12-08

Section 4.2 says:

      5) Initial assignments and reservations.  Clear instructions
         should be provided to identify any initial assignments or
         registrations.  In addition, any ranges that are to be reserved
         for "Private Use", "Reserved", "Unassigned", etc. should be
         clearly indicated.

It should say:

      5) Initial assignments and reservations.  Clear instructions
         should be provided to identify any initial assignments or
         registrations.  In addition, any ranges that are to be reserved
         for "Private Use", "Reserved", etc. should be
         clearly indicated.

Notes:

Unassigned values are not "reserved". For bounded registries, they can be computed from the assigned/reserved values. For unbounded registries (think media types), mentioning them doesn't make any sense at all.
--VERIFIER NOTES--
No change is needed. The use of "should" provides any necessary flexibility. In the IANA Considerations section of a document that sets up a registry, authors tend to indicate which values are initially "Unassigned".

Errata ID: 2715
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-02-12
Rejected by: Russ Housley
Date Rejected: 2011-12-08

Section 4.2 says:

     5) Initial assignments and reservations.  Clear instructions
        should be provided to identify any initial assignments or
        registrations.  In addition, any ranges that are to be reserved
        for "Private Use", "Reserved", "Unassigned", etc. should be
        clearly indicated.

It should say:

     5) Initial assignments and reservations.  Clear instructions
        SHALL be provided to identify any initial assignments or
        registrations.  In addition, any ranges that are "Unassigned" 
        (only for those registries that have a bounded size), to be  
        "Reserved", used for "Private Use", "Experimentation", etc. 
        SHALL be clearly indicated.

Notes:

Julian Reschke included the following notes to his errata report #2684:

--Citation starts--
Unassigned values are not "reserved". For bounded registries, they can be computed from the assigned/reserved values. For unbounded registries (think media types), mentioning them doesn't make any sense at all.
--Citation ends--

Anyway, I propose to consider mentioning the norm about mandatory mentioning the Unassigned values in the registry description appropriate and useful. This would improve the work of IANA staff that will create the registries.
--VERIFIER NOTES--
Changing a "should" to a "SHALL" in a BCP cannot happen through the errata. IETF consensus is needed for such a change.

RFC 5233, "Sieve Email Filtering: Subaddress Extension", January 2008

Source of RFC: sieve (app)

Errata ID: 1331
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Derek Diget
Date Reported: 2008-02-26
Rejected by: Alexey Melnikov
Date Rejected: 2009-07-06

Section Section 4 says:

The ":user" argument specifies the user sub-part of the local-part of
an address.  If the address is not encoded to contain a detail sub-
part, then ":user" specifies the entire left side of the address
(equivalent to ":localpart").

It should say:

The ":user" argument specifies the user sub-part of the local-part of
an address.  If the address is not encoded to contain a detail sub-
part, then ":user" specifies the entire left side of the address
(equivalent to ":local-part").

Notes:

Through out the document ":local-part" is hyphenated, except for the instance in the last sentence of the paragraph above.
--VERIFIER NOTES--
":localpart" is defined in Section 8.3 of RFC 5228:

ADDRESS-PART = ":localpart" / ":domain" / ":all"

RFC 5234, "Augmented BNF for Syntax Specifications: ABNF", January 2008

Note: This RFC has been updated by RFC 7405

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 1423
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: David J. Rutkin
Date Reported: 2008-05-13
Rejected by: Alexey Melnikov
Date Rejected: 2010-09-03

Section 4. says:

repeat         =  1*DIGIT / (*DIGIT "*" *DIGIT)

It should say:

repeat         =  *DIGIT ["*" *DIGIT]

Notes:

In section 4. ABNF Definition of ABNF, on Page 10, the definition of <repeat> appears to be ambiguous.

After many weeks of study of RFC 5234 I am unable to discern which alternation to choose for <repeat> for the following string.

21*ARULENAME

Both alternatives are a valid solution but I was not able to determine from the RFC which one should be chosen. By my way of thinking, the first one encountered should be chosen but when done, the "*" is left and will cause a parsing error. Conversely I could have performed a look ahead check in my parsor, but that would produce a less efficient parser, forcing all alternatives to always be processed. In either case, the rule is ambiguous and, in my opinion, requires further definition.

My recommendation would be to change it to

repeat = *DIGIT ["*" *DIGIT]

This solution does not introduce any ambiguity and does not break any components of the definition of ABNF.

I realize that the forced presence of a digit on the <repeat> without the * is no longer present, but it was not necessary since the only use of <repeat> is by <repetition> and its presence is optional.

--VERIFIER NOTES--

The following is the text of an analysis of Erratum entry <http://www.rfc-editor.org/errata_search.php?rfc=5234&eid=1423>, made by Paul Overell:


> Section: 4.
>
> Original Text
> -------------
> repeat = 1*DIGIT / (*DIGIT "*" *DIGIT)
>

I can see nothing wrong with this, there is no ambiguity. To be ambiguous it would have to be able to generate a particular string in more than one way.

A <repeat> without a "*" can only be generated by the first alterative. A <repeat> with a "*" can only be generated by the second alternative.


> Corrected Text
> --------------
> repeat = *DIGIT ["*" *DIGIT]

This changes the syntax of <repeat> as it allow the empty string.


> Notes
> -----
> In section 4. ABNF Definition of ABNF, on Page 10, the definition of <repeat> appears to be ambiguous.
>
> After many weeks of study of RFC 5234 I am unable to discern which alternation to choose for <repeat> for the following string.
>
> 21*ARULENAME

This clearly matches the second alternative (*DIGIT "*" *DIGIT) and therefor is an instance of a <repeat>. This string can only be generated using the second alternative.


> Both alternatives are a valid solution but I was not able to determine from the RFC which one should be chosen. By my way of thinking, the first one encountered should be chosen but when done, the "*" is left and will cause a parsing error.

The first cannot be chosen precisely because the "*" is left and causes a parsing error.

> Conversely I could have performed a look ahead check in my parsor, but that would produce a less efficient parser, forcing all alternatives to always be processed.

The grammar given for ABNF is not, and does not claim to be, LL(0). I expect the ABNF grammar could be recast as LL(0) but there is no need, it was written for clarity.

I can't see the relevance of parser efficiency here.

> In either case, the rule is ambiguous and, in my opinion, requires further definition.

As discussed above, there is no ambiguity.


> My recommendation would be to change it to

> repeat = *DIGIT ["*" *DIGIT]
>
> This solution does not introduce any ambiguity and does not break any components of the definition of ABNF.

It is not equivalent to the original in that it allows the empty string.


> I realize that the forced presence of a digit on the <repeat> without the * is no longer present, but it was not necessary since the only use of <repeat> is by <repetition> and its presence is optional.

The proposed change to <repeat> breaks the definition of <repetition> as it then becomes ambiguous.

Consider the string "foo". With the proposed change to <repeat> it can be parsed as a <repetition> in two ways: <repeat> <element> or as <element>, the first with the option taken, the second with the option not taken. Two parse trees for the same string. To fix this ambiguity the definition of <repetition> would have to be changed to

repetition = repeat element


I recommend that this errata is rejected.

There is no ambiguity to fix, the proposed change is unnecessary, and would require an additional change to the definition of <repetition>.

Errata ID: 3096
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: MURATA Yasuhisa
Date Reported: 2012-01-23
Rejected by: Peter Saint-Andre
Date Rejected: 2012-01-26

Section B.1 says:

LWSP           =  *(WSP / CRLF WSP)

It should say:

LWSP           =  1*(WSP / CRLF WSP)

Notes:

RFC 822 said:
linear-white-space = 1*([CRLF] LWSP-char)
--VERIFIER NOTES--
Paul Overell notes the following (and Dave Crocker concurs):

###

The suggested change would give LWSP the same syntactic definition as RFC822's linear-white-space.

However, the successor to RFC822, RFC5322, doesn't use LWSP, it has its own definitions specifying header folding. Nor does RFC5234 itself use LWSP.

There are RFCs that use the existing definition, e.g. RFC6376, RFC5191, RFC5987. These would need to be fixed if we changed the definition of LWSP.

The existing definition of LWSP has been around since 1997, it is not wrong or unreasonable, just different from RFC822's linear-white-space.

###

Errata ID: 4040
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Chris Morgan
Date Reported: 2014-07-03
Rejected by: Barry Leiba
Date Rejected: 2014-07-04

Section B.1 says:

HEXDIG         =  DIGIT / "A" / "B" / "C" / "D" / "E" / "F"

It should say:

HEXDIG         =  DIGIT
               / "A" / "B" / "C" / "D" / "E" / "F"
               / "a" / "b" / "c" / "d" / "e" / "f"

Notes:

Various RFCs are quoting HEXDIG under the currently incorrect understanding that it includes a-f as well as 0-9 and A-F, and I believe this is the place where it should be changed, rather than altering them to use a different rule.

Here are a couple of examples of the problem this causes that came quickly to hand:

- RFC 7230: section 1.2 cites ?HEXDIG (hexadecimal 0-9/A-F/a-f)?, section 4.1 proceeds to use HEXDIG in chunk-size, which in RFC 2616 was HEX which did indeed include a-f.

- RFC 3986: it replaces the hex of RFC 2396, which included a-f, with this HEXDIG of RFC 2234 (of which this document is the latest form). This is then used in pct-encoded (percent-encoding in URLs), IPvFuture and h16 (IPv6 addresses), all of which can reasonably be expected to permit lowercase a-f as well as uppercase.
--VERIFIER NOTES--
In Section 2.3, RFC 5234 explicitly says this:

NOTE:
ABNF strings are case insensitive and the character set for these
strings is US-ASCII.

So the definition of HEXDIG already allows for both upper and lower case (or a mixture).

It's true that some people aren't aware of that, and write their documents without understanding it. But it is not an error in 5234.

Errata ID: 4564
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: iliwoy
Date Reported: 2015-12-14
Rejected by: Barry Leiba
Date Rejected: 2015-12-14

Section 3.8 says:

         [foo bar]

   is equivalent to

         *1(foo bar).

It should say:

         [foo bar]

   is equivalent to

         *1(foo/bar).

Notes:

--VERIFIER NOTES--
It seems that the reporter misunderstands what "[foo bar]"
means. It means that "foo bar" (the two tokens together, as a unit)
is optional. It is not suggesting an alternative of "foo" or "bar".

Errata ID: 5110
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Allan Hazarian
Date Reported: 2017-09-09
Rejected by: Barry Leiba
Date Rejected: 2020-05-14

Section B.1. says:

BIT            =  "0" / "1"

It should say:

BIT            =  %b0 / %b1

Notes:

The core rule BIT is written in the char-val rule syntax, which produces the ASCII chars %x30 ("0") and %x31 ("1"). For producing the 0 and 1 bit the bin-val rule should be used instead. Since the core rules use the hex-val rule extensively, using the bin-val rule shouldn't be a problem.
--VERIFIER NOTES--
No, the "BIT" construct is part of the "bin-val" construct, which gives "b0" or "b1", and "bin-val" is then part of "num-val", which is what produces "%b0" or "%b1". The ABNF is correct as written.

Errata ID: 4361
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Brian S. Julin
Date Reported: 2015-05-10
Rejected by: Barry Leiba
Date Rejected: 2015-05-12

Section 2.1 says:

Unlike original BNF, angle brackets ("<", ">") are not required.
However, angle brackets may be used around a rule name whenever their
presence facilitates in discerning the use of a rule name.  This is
typically restricted to rule name references in free-form prose

Notes:

Section 2.1 could be more explicit as to whether a parser, encountering a string that could be interpreted by humans as a rule name inside angles, should process it as a <rule-name> or not. The use of the words "typically restricted" allow for leeway in interpretation, and in light of section 4 note 1, implementors may be tempted to disregard the formal definition as being simply informative. Section 3.10 gives <prose-val> looser precedence than rule-name, adding weight to the idea that since there is a ambiguity to be resolved, angle brackets around rule names might be expected to appear in parser input.

It is also worth noting that the rule definition for <prose-val> prohibits the use of angle brackets around rule names within the contents of <prose-val> itself, and that the intended use of the <prose-val> rule is only described via comments.

Corrected text is not provided as the intent is unclear.
--VERIFIER NOTES--
Within an ABNF parsing context, the handling of rulenames with or
without angle-brackets is a small distinction. Parsers can and do
easily handle rulenames without the brackets; obviously they also can
handle the presence of the angle-brackets, although they generally
don't. Omitting brackets from ABNF intended for parsing was generally
received as an improvement over BNF, 40 years ago.

RFC 5237, "IANA Allocation Guidelines for the Protocol Field", February 2008

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: gen

Errata ID: 6990
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ruder Laplace
Date Reported: 2022-06-14
Rejected by: Lars Eggert
Date Rejected: 2023-08-11

Section 1 says:

1.  Introduction

   This document revises the IANA guidelines [RFC2780] for allocating
   new Protocol field values in IPv4 header [RFC0791].

It should say:

1.  Introduction

   This document revises the IANA guidelines [RFC2780] for allocating
   new Protocol field values in IPv4 header [RFC791].

Notes:

Either the link to RFC0791 should point to https://www.rfc-editor.org/rfc/rfc791 (without the zero), or the url to RFC0791 itself is wrong without the zero.
--VERIFIER NOTES--
This is about a rendering issue in the HTMLized version of the RFC. The reference entry does contain the correct URL.

RFC 5243, "OSPF Database Exchange Summary List Optimization", May 2008

Note: This RFC has been updated by RFC 9454

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rtg

Errata ID: 3886
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Anton Smirnov
Date Reported: 2014-02-10
Rejected by: Stewart Bryant
Date Rejected: 2014-03-02

Section 2 says:

It should say:

RFC 3623 "Graceful OSPF Restart" in section 2.2 "When to Exit
Graceful Restart" specifies that if router recovering its LSDB
after switchover did not receive its own pre-restart Router LSA
from neighbor helping in Graceful Restart then this should
be treated as unrecoverable change in the LSDB incompatible with
the Graceful Restart. To satisfy this verification neighbor's
Router LSA must never be optimized out of DBD exchange with a
neighbor performing Graceful Restart. This may happen if the
restarting router has multiple adjacencies and has already
learned its pre-restart Router LSA from some neighbors before
starting DBD exchange with others.

Notes:

--VERIFIER NOTES--
This appears to be a technical extension to the RFC and is thus outside the scope of the errata process.

The submitter should address the issue by publishing an RFC.

RFC 5245, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", April 2010

Note: This RFC has been obsoleted by RFC 8445, RFC 8839

Note: This RFC has been updated by RFC 6336

Source of RFC: mmusic (rai)

Errata ID: 3619
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Ashish Kundu
Date Reported: 2013-05-13
Rejected by: Gonzalo Camarillo
Date Rejected: 2013-05-15

Section Section 4, 5 says:

Missed candidate pair in ICE standard

It should say:

Scenario: X is caller, Z is callee. X is behind a non-full-cone 
(such as symmetric) NAT, Z is behind a full-cone NAT. 

ICE standard: Section 2.1 of RFC5245 describes the addresses that 
are collected as candidate addresses: (local address, server-reflexive 
address, TURN relay address).  For X: (X:x, X1:x1, Yx:yx), and for Z: 
(Z:z, Z1:z1, Yz:yz). 

Missed candidate pair in ICE standard: 
1. X:x sends a connection check message to the Z1:z1 (as part of the 
process in Section 2.2 of the standard) 
2. Since X is behind a non-full cone NAT such a symmetric one, NAT of 
X maps X:x to X2:x2, sends the message to Z1:z1
3. Z is behind a full-cone NAT, so packets received at Z1:z1 address 
is forwarded to Z:z by the NAT

Since X is behind a non-full cone NAT such a symmetric one and Z is 
behind a full-cone NAT, connection from X:x to Z1:z1 would be via a 
server-reflexive address X2:x2 of X, which is not a candidate address 
for X as specified by ICE. X2:x2 should be a candidate address of X, 
which however can only be determine when X sends a message to Z. The 
pair (X2:x2, Z1:z1) provides a direct connection option between X and Y.

Conditions on which X2:x2 is a valid candidate address:
1. One of the peers (Z) is behind a full-cone NAT, else step 3 above 
does not succeed.
2. X2:x2 is unique, i.e., different from X1:x1 (already covered by 
Section 2.1) if and only if one of the peers is  behind a non-full-cone 
NAT.

So I think there should be two stages in the candidate collection process:
A: Section 2.1 -- candidate addresses independent of the other clients
B: collection of the candidate pairs with respect to the peer, such as 
X2:x2 and Z2:z2, if any. 

B consists of the following steps including 1, 2, and 3:
4. Z:z determines if X2:x2 from which it received the message is a 
different address than in the candidate set of X.
5. If 4 is true, then send an OK message to X2:x2 that it received the
message with X2:x2 XOR-encoded.
6. X:x receives the OK message in 4, then X:x determines X2:x2 as its 
new candidate address.

If X:x decides to establish the connection via X2:x2, it sends ACK 
message to Z2:z2.

Notes:

This feedback for improvement of ICE candidate gathering and decision process was sent to Dr. Rosenberg on Nov 09, 2012. However, since I have not received any response from him over my next two followups and this e-mail, I thought it should be reported via this method.

This is not an error mesage, but a method to improve the candidate gathering and decision process of ICE.
--VERIFIER NOTES--

Errata ID: 3952
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Suresh Tummala
Date Reported: 2014-04-04
Rejected by: Richard Barnes
Date Rejected: 2014-04-09

Section 15.1 says:

priority = 1*10DIGIT

Notes:

priority = 1*10DIGIT

Here the maximum value it can hold is "9999999999"(ten-nines)(priority is of maximum length 10 DIGIT as per grammar in sec 15.1).

The number of bits required to hold the maximum value(ten-nines) is 34. Which requires a "double" value instead of integer of 32 bit.

Can i know why the priority is maximum of 10 DIGIT length? If possible we may decrease to 9 DIGIT, so that the value will be fit into integer of 32bit.

-- VERIFIER NOTES --
The limitation to 2^32-1 is made clear elsewhere in the text. The ABNF does not need to enforce this constraint

RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2", August 2008

Note: This RFC has been obsoleted by RFC 8446

Note: This RFC has been updated by RFC 5746, RFC 5878, RFC 6176, RFC 7465, RFC 7507, RFC 7568, RFC 7627, RFC 7685, RFC 7905, RFC 7919, RFC 8447, RFC 9155

Source of RFC: tls (sec)

Errata ID: 4382
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Laura Corcoran
Date Reported: 2015-05-29
Rejected by: EKR
Date Rejected: 2018-06-22

Section 4.3 says:

In the following example, Datum is defined to be three consecutive
   bytes that the protocol does not interpret, while Data is three
   consecutive Datum, consuming a total of nine bytes.

      opaque Datum[3];      /* three uninterpreted bytes */
      Datum Data[9];        /* 3 consecutive 3 byte vectors */

It should say:

In the following example, Datum is defined to be three consecutive
   bytes that the protocol does not interpret, while Data is three
   consecutive Datum, consuming a total of nine bytes.

      opaque Datum[3];      /* three uninterpreted bytes */
      Datum Data[3];        /* 3 consecutive 3 byte vectors */

Notes:

The 9 in "Datum Data[9]" should be a 3 because Datum is a data type that consumes 3 bytes, so as written the Data vector is 27 bytes long. To make it a 9 byte vector the 9 must change to a 3.
--VERIFIER NOTES--
This is not correct. The value here is the number of bytes, not the count of items.

Errata ID: 5036
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Stefan Goeman
Date Reported: 2017-06-09
Rejected by: Paul Wouters
Date Rejected: 2024-03-18

Section 7.4.1.2 says:

The ClientHello Structure indicates that a SessionID could be present.
However if I take a wireshark of a TLS session I always see a "Session 
ID Length" field, either with value 0 or value 32

It should say:

In the ClientHello structure and ServerHello structure, include 
a 1 byte "Session ID Length" field.

Notes:

The ClientHello Structure indicates that a SessionID could be present.
However if I take a wireshark of a TLS session I always see a
"Session ID Length" field, either with value 0 or value 32.
--VERIFIER NOTES--
This erratum is incorrect.

Here is the definition of SessionID:
opaque SessionID<0..32>;

The angle brackets mean that it is variable length and the 0..32 means that there is
a one-byte length field.

Errata ID: 5352
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Loic Etienne
Date Reported: 2018-05-09
Rejected by: Eric Rescorla
Date Rejected: 2018-05-10

Section 6.2.3.3. says:

struct {
    opaque nonce_explicit[SecurityParameters.record_iv_length];
    aead-ciphered struct {
        opaque content[TLSCompressed.length];
    };
} GenericAEADCipher;

It should say:

struct {
    opaque nonce_explicit[SecurityParameters.record_iv_length];
    aead-ciphered struct {
        opaque content[TLSCiphertext.length];
    };
} GenericAEADCipher;

Notes:

6.2.3.3. says: "The aead_output consists of the ciphertext output by the AEAD encryption operation. The length will generally be larger than TLSCompressed.length, [...]".

The definition is duplicated at A.1., and needs the same adjustment.
--VERIFIER NOTES--
aead-ciphered is an operator that takes content as the input.

Errata ID: 5409
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Eugene Adell
Date Reported: 2018-06-26
Rejected by: Benjamin Kaduk
Date Rejected: 2018-07-14

Section Appendix A.5 says:

   Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
   reserved to avoid collision with Fortezza-based cipher suites in
   SSL 3.

It should say:

   Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
   reserved to avoid collision with Fortezza-based cipher suites in
   SSL 3. The cipher suite value { 0x00, 0x1E } firstly also assigned to
   Fortezza has been released and has since been be reassigned. 

Notes:

RFC 2712 (Addition of Kerberos Cipher Suites to Transport Layer Security) in its Draft 01 version introduces three new cipher suites colliding with the three Fortezza ones. The Draft 02 version partially corrects that, by moving the Kerberos cipher suites values by two.
This omission of the third cipher suite has never been corrected, and this remains in the same state in the final RFC 2712, RFC 2246 and its successors including this one.

Changing the first Kerberos cipher suite value, or moving all of them, would now not make any sense. Enhancing the note as suggested is probably enough to mention how one Fortezza cipher suite disappeared.
--VERIFIER NOTES--
RFC 5246 is not the appropriate location to document this conflict.

Errata ID: 5535
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Dave Thompson
Date Reported: 2018-10-19
Rejected by: Benjamin Kaduk
Date Rejected: 2018-10-27

Section 4.7 says:

   In DSA, the 20 bytes of the SHA-1 hash are run directly through the
   Digital Signing Algorithm with no additional hashing. ...

It should say:

   In DSA, the bytes of the selected hash are run directly through the
   Digital Signing Algorithm with no additional hashing. ...

Notes:

In 2246 and 4346 this statement (then using the less-accurate spellings DSS and SHA) was correct because only SHA1 was used for DSA (and ECDSA, in 4492, versus SHA1+MD5 for RSA), but 5246 changed this to allow specifying one of several hashes, with selection constrained by the signature_algorithms extension (if present) or CertificateRequest field from the peer.

FIPS 186 actually defines the hashing step as part of signature generation and verification, so it might be even better to make this something like "For DSA, signature generation applies the selected hash [to the contents] and then computes two values, r and s." similar to the way the preceding paragraph of 5246 "In RSA signing" differs from the 2246 and 4346 versions by no longer treating the hashing as separate, but that is a bigger change to an obsoleted document, and arguably problematic because the normative reference is FIPS 186-2; as indicated in Appendix B on page 80, 186-3 which officially allowed DSA to use FIPS 180-3 hashes (not only SHA-1) was released in draft before 5246 but not finalized until after (2006-03 to 2009-06 versus 2008-08).
--VERIFIER NOTES--
As described in the reported Notes, at the time of publication, the DSA specification in force only allowed for the usage of SHA-1. So the document was correct at time of publication and an errata is not appropriate, even though subsequent events have allowed for the usage of a broader set of hash algorithms with DSA.

Errata ID: 6572
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Johannes Görlich
Date Reported: 2021-05-05
Rejected by: Paul Wouters
Date Rejected: 2024-03-21

Section 9 says:

In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the definition).

It should say:

In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the cipher suite TLS_RSA_WITH_AES_128_GCM_SHA256 (see Appendix A.5 for the definition).

Notes:

A must-be-implement cipher suite should not relay on a bulk encryption algorithm which is vulnerable to plain-text attacks or on a secure hash algorithm which has been proven to be insecure.
--VERIFIER NOTES--
errata is not the right process for a change such as proposed.
See also: https://mailarchive.ietf.org/arch/msg/tls/2mKIkvRoQNMEMkT04JAqBifEJSo/

Errata ID: 3191
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Martin Rex
Date Reported: 2012-04-12
Rejected by: Sean Turner
Date Rejected: 2012-04-19

Section Meta-Data says:

Obsoletes: 3268, 4346, 4366
Updates: 4492

It should say:

Updates: 4492

Notes:

"Obsoletes: 4366" is factually incorrect, because it is impossible to implement TLSv1.1 (rfc4346) or TLSv1.0(rfc2246) from the TLSv1.2 spec alone. (IPv6 does not obsolete IPv4 and HTTP/1.1 does not obsolete HTTP/1.0 either).

"Obsoletes: 4366" is factually incorrect, because some of the TLS extensions defined in rfc4366 do NOT appear in rfc5246 (and were updated by rfc6066). On top of that, in order to implement TLS extensions for TLSv1.0 or TLSv1.1, rfc4366 is indispensible, because it describes the necessary changes to the TLSv1.0 & TLSv1.1 PDUs, information that would be cumbersome to extract from rfc5246 compared to simply using rfc4366.

"Obsoletes: 3268" is factually incorrect, because 3268 is the document needed to implement the AES ciphersuites in implementations of TLS _prior_ to TLSv1.2,
such as TLSv1.0(rfc2246) and TLSv1.1(rfc4346), i.e. to add support for AES ciphersuites to an existing implementation of TLSv1.0, one would use TLSv1.0(rfc2246) plus rfc3268, rather than TLSv1.0 plus some undefined fragments of rfc5246.
--VERIFIER NOTES--
If you're looking to implement TLS 1.1 or TLS 1.0 you should be looking in those earlier specifications not RFC 5246.

One RFC can be obsoleted by more than RFC.

RFC 5247, "Extensible Authentication Protocol (EAP) Key Management Framework", August 2008

Note: This RFC has been updated by RFC 8940

Source of RFC: eap (int)

Errata ID: 1642
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yoshihiro Ohba
Date Reported: 2008-12-20
Rejected by: Jari Arkko
Date Rejected: 2009-03-11

Section 4 says:

   EAP pre-authentication
      In EAP pre-authentication, an EAP peer pre-establishes EAP keying
      material with an authenticator prior to arrival.  EAP
      pre-authentication only affects the timing of EAP authentication,
      but does not shorten or eliminate EAP (phase 1a) or AAA (phase 1b)
      exchanges;  Discovery (phase 0) and Secure Association Protocol
      (phase 2) exchanges occur as described in Section 1.3.  As a
      result, the primary benefit is to enable EAP authentication to be
      removed from the handoff critical path, thereby reducing latency.
      Use of EAP pre-authentication within IEEE 802.11 is described in
      [IEEE-802.11] and [8021XPreAuth].

   Proactive key distribution
      In proactive key distribution, keying material and authorizations
      are transported from the backend authentication server to a
      candidate authenticator in advance of a handoff.  As a result, EAP
      (phase 1a) is not needed, but the Discovery (phase 0), and Secure
      Association Protocol exchanges (phase 2) are still necessary.
      Within the AAA exchange (phase 1b), authorization and key
      distribution functions are typically supported, but not
      authentication.  Proactive key distribution is described in
      [MishraPro], [IEEE-03-084], and [HANDOFF].

It should say:

   EAP pre-authentication
      In EAP pre-authentication, an EAP peer pre-establishes EAP 
      keying material with an authenticator through which the peer has
      routed the EAP authentication prior to arrival.  EAP
      pre-authentication only affects the timing of EAP 
      authentication, but does not shorten or eliminate EAP (phase 1a)
      or AAA (phase 1b) exchanges through the authenticator.
      Discovery (phase 0) and Secure Association Protocol (phase 2)
      exchanges occur as described in Section 1.3.  As a result, the
      primary benefit is to enable EAP authentication to be removed
      from the handoff critical path, thereby reducing latency.  Use
      of EAP pre-authentication within IEEE 802.11 is described in
      [IEEE-802.11].

   Proactive key distribution
      In proactive key distribution, keying material and authorizations
      are transported from the backend authentication server to a
      candidate authenticator in advance of a handoff.  As a result, EAP
      (phase 1a) is not needed, but the Discovery (phase 0), and Secure
      Association Protocol exchanges (phase 2) are still necessary.
      Within the AAA exchange (phase 1b), authorization and key
      distribution functions are typically supported, but not
      authentication.  Proactive key distribution is described in
      [MishraPro], [IEEE-03-084], [HANDOFF] and [8021XPreAuth].

Notes:

The EAP pre-authentication definition should be more clear that an EAP peer
runs EAP authentication through the target authenticator before EAP keying material will be pre-established with the target authenticator prior to arrival.
--VERIFIER NOTES--
Discussion between EAP and HOKEY chairs and the ADs revealed that this is not an appropriate change.

RFC 5272, "Certificate Management over CMS (CMC)", June 2008

Note: This RFC has been updated by RFC 6402

Source of RFC: pkix (sec)

Errata ID: 4186
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Pierce Leonberger
Date Reported: 2014-11-18
Rejected by: Kathleen Moriarty
Date Rejected: 2015-03-31

Section 3.2.1.3.2 says:

The Data content type allows for general transport of unstructured
   data.

   The Data content type is used by this document for:

      Holding the encrypted random value y for POP proof in the
      encrypted POP control (see Section 6.7).

It should say:

See Notes

Notes:

It's invalid for the encoding of an ANY or OpenType to have "unstructured" data. See X.690 section 8.15:

8.15 Encoding of an open type
The value of an open type is also a value of some (other) ASN.1 type. The encoding of such a value shall be the complete encoding herein specified for the value considered as being of that other type.

Note there's similar wording in X.209 section 21 for ANY:

21 Encoding of a value of the ANY type
The encoding of an ANY type shall be the complete encoding specified in this Recommendation for the type of the value of the ANY type.
--VERIFIER NOTES--
The Data content type being referenced here is the Data content type from CMS. This type is defined as using an OCTET STRING wrapper around the data. Therefore unstructured data is not being placed at the ASN.1 level and the referenced text does not apply.

RFC 5277, "NETCONF Event Notifications", July 2008

Source of RFC: netconf (ops)

Errata ID: 6770
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Tetsuya Hasegawa
Date Reported: 2021-12-01
Rejected by: Rob Wilton
Date Rejected: 2021-12-01

Section 4 says:

4.  XML Schema for Event Notification

It should say:

Add a new section "YANG Module for Event Notifications".

Notes:

There is no YANG module for the NETCONF <notification> defined anywhere.
There is no standard YANG module for the <create-subscription> operation.

1) RFC 5277 predates RFC 6020, so YANG is not normative in RFC 5277.
Please use the update in RFC 8639.

2) It is not possible to model the <notification> element in YANG.

3) A new RFC is required to add new functionality. This is not a bugfix
suitable for an Errata.

--VERIFIER NOTES--

RFC 5280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", May 2008

Note: This RFC has been updated by RFC 6818, RFC 8398, RFC 8399, RFC 9549

Source of RFC: pkix (sec)

Errata ID: 1774
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Takashi Ito
Date Reported: 2009-05-04
Rejected by: Pasi Eronen
Date Rejected: 2009-05-27

Section 6.3 says:

   For each distribution point (DP) in the certificate CRL distribution
   points extension, for each corresponding CRL in the local CRL cache,
   while ((reasons_mask is not all-reasons) and (cert_status is
   UNREVOKED)) perform the following:

      (a)  Update the local CRL cache by obtaining a complete CRL, a
      delta CRL, or both, as required:

It should say:

   For each distribution point (DP) in the certificate CRL distribution
   points extension, for each corresponding CRL in the local CRL cache,
   while ((reasons_mask is not all-reasons) and (cert_status is
   UNREVOKED)) perform the following:

   (l)  Set the reasons_mask state variable to the union of
        its previous value and the value of the interim_reasons_mask
        state variable.

      (a)  Update the local CRL cache by obtaining a complete CRL, a
      delta CRL, or both, as required:

Notes:

This was reported in 2002 for RFC 3280, which this document obsoletes. The correction did not make it in to RFC 5280, and therefore applies to RFC 5280 as well.
--VERIFIER NOTES--
The correction already appears as step (l), the last step in the loop.

Errata ID: 3693
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Florian Weimer
Date Reported: 2013-08-12
Rejected by: Sean Turner
Date Rejected: 2013-08-14

Section 4.2.1.10 says:

   DNS name restrictions are expressed as host.example.com.  Any DNS
   name that can be constructed by simply adding zero or more labels to
   the left-hand side of the name satisfies the name constraint.  For
   example, www.host.example.com would satisfy the constraint but
   host1.example.com would not.

It should say:

[Add this to the paragraph]

   If an implementation extracts DNS names from the subject
   distinguished name, DNS name restrictions MUST be applied
   to these names as well.

Notes:

When used with TLS and HTTP (according to RFC 2818), section 4.2.1.10, Name Constraints, is technically a NOP that doesn't constraint the CA that has this attribute because RFC 2818 mandates processing of the common name attribute in the subject distinguished name. Consequentially, the constraint can be bypassed by issuing a certificate without a subject alternative name. The fix is to apply the DNS name restrictions to the relevant parts of the subject distinguished name, too, as implemented here:

https://bugzilla.mozilla.org/show_bug.cgi?id=394919
--VERIFIER NOTES--
The suggested change is not editorial; it represents a significant
technical change. It also does not accurately reflect the intent of the WG.

Errata ID: 5967
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Maxim
Date Reported: 2020-01-27
Rejected by: Benjamin Kaduk
Date Rejected: 2020-02-02

Section 4.2.2.1. says:

The authority information access extension indicates how to access information and services for the issuer of the certificate in which the extension appears.

It should say:

The authority information access extension indicates how to access information and services of the issuer of the certificate in which the extension appears.

Notes:

When you use "access services for the issuer" you refer to grandparent node for the certificate in certification path. But actually you mean here the parent node in certification path (the services of the CA that has issued the certificate) and that would be "services of the issuer".
--VERIFIER NOTES--
"the issuer of the certificate in which the extension appears" is a precise indication of the parent node and does not refer to the grandparent node.

Errata ID: 3085
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jim Wigginton
Date Reported: 2012-01-06
Rejected by: Sean Turner
Date Rejected: 2012-01-09

Section A.1 says:

BuiltInStandardAttributes ::= SEQUENCE {
   country-name                  CountryName OPTIONAL,
   administration-domain-name    AdministrationDomainName OPTIONAL,
   network-address           [0] IMPLICIT NetworkAddress OPTIONAL,
     -- see also extended-network-address
   terminal-identifier       [1] IMPLICIT TerminalIdentifier OPTIONAL,
   private-domain-name       [2] PrivateDomainName OPTIONAL,
   organization-name         [3] IMPLICIT OrganizationName OPTIONAL,
     -- see also teletex-organization-name
   numeric-user-identifier   [4] IMPLICIT NumericUserIdentifier
                                 OPTIONAL,
   personal-name             [5] IMPLICIT PersonalName OPTIONAL,
     -- see also teletex-personal-name
   organizational-unit-names [6] IMPLICIT OrganizationalUnitNames
                                 OPTIONAL }
     -- see also teletex-organizational-unit-names

It should say:

BuiltInStandardAttributes ::= SEQUENCE {
   country-name                  CountryName OPTIONAL,
   administration-domain-name    AdministrationDomainName OPTIONAL,
   network-address           [0] IMPLICIT NetworkAddress OPTIONAL,
     -- see also extended-network-address
   terminal-identifier       [1] IMPLICIT TerminalIdentifier OPTIONAL,
   private-domain-name       [2] IMPLICIT PrivateDomainName OPTIONAL,
   organization-name         [3] IMPLICIT OrganizationName OPTIONAL,
     -- see also teletex-organization-name
   numeric-user-identifier   [4] IMPLICIT NumericUserIdentifier
                                 OPTIONAL,
   personal-name             [5] IMPLICIT PersonalName OPTIONAL,
     -- see also teletex-personal-name
   organizational-unit-names [6] IMPLICIT OrganizationalUnitNames
                                 OPTIONAL }
     -- see also teletex-organizational-unit-names

Notes:

Seems to me that private-domain-name ought to be tagged IMPLICIT just like everything else?
--VERIFIER NOTES--
PrivateDomainName (unlike the other tagged components) is an untagged
CHOICE type.


Quote from X.680:

'30.8 The IMPLICIT alternative shall not be used if the type defined
by "Type" is an untagged choice type or an untagged open type or an untagged
"DummyReference" (see ITU-T Rec. X.683 | ISO/IEC 8824-4, 8.3).'

RFC 5291, "Outbound Route Filtering Capability for BGP-4", August 2008

Source of RFC: idr (rtg)

Errata ID: 3468
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: David Lamparter
Date Reported: 2013-01-22
Rejected by: Stewart Bryant
Date Rejected: 2013-02-06

Section 5 says:

5. Outbound Route Filtering Capability


   A BGP speaker that is willing to receive ORF entries from its peer,
   or a BGP speaker that would like to send ORF entries to its peer,
   advertises this to the peer by using the Outbound Route Filtering
   Capability, as described below.

   The Outbound Route Filtering Capability is a new BGP Capability
   [BGP-CAP] defined as follows:

      Capability code: 3

      Capability length: variable

      Capability value: one or more of the entries as shown in Figure 3.

         +--------------------------------------------------+
         | Address Family Identifier (2 octets)             |
         +--------------------------------------------------+
         | Reserved (1 octet)                               |
         +--------------------------------------------------+
         | Subsequent Address Family Identifier (1 octet)   |
         +--------------------------------------------------+
         | Number of ORFs (1 octet)                         |
         +--------------------------------------------------+
         | ORF Type (1 octet)                               |
         +--------------------------------------------------+
         | Send/Receive (1 octet)                           |
         +--------------------------------------------------+
         | ...                                              |
         +--------------------------------------------------+
         | ORF Type (1 octet)                               |
         +--------------------------------------------------+
         | Send/Receive (1 octet)                           |
         +--------------------------------------------------+

         Figure 3: Outbound Route Filtering Capability Encoding

Notes:

RFC5291 does not specify how the ORF capability is supposed to be used
in conjunction with multiple enabled AFI/SAFI combinations. The text
can be interpreted as either "one capability instance will be sent,
carrying multiple blocks as described in Figure 3" or as "the
capability will be supplied in more than instance".

Note also that RFC3392 [BGP-CAP] Section 4 reads:

BGP speakers MAY include more than one instance of a capability (as
identified by the Capability Code) with non-zero Capability Length
field, but with different Capability Value, and either the same or
different Capability Length. Processing of these capability
instances is specific to the Capability Code and MUST be described in
the document introducing the new capability.

Latter description of how multiple instances of the capability are to be
processed - albeit relatively obvious - is nowhere to be found in RFC5291.


Respectfully requesting a clarification,

David Lamparter
--VERIFIER NOTES--
This is beyond the scope of an errata system to address.

I think that the right process is for the WG to decide the answer
and if necessary for someone to write up a short update to
RFC5291

I have therefore rejected this errata.

The thread in the IDR list starts at
http://www.ietf.org/mail-archive/web/idr/current/msg12075.html

RFC 5296, "EAP Extensions for EAP Re-authentication Protocol (ERP)", August 2008

Note: This RFC has been obsoleted by RFC 6696

Source of RFC: hokey (sec)

Errata ID: 1961
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Glen Zorn
Date Reported: 2009-12-18
Rejected by: Stephen Farrell
Date Rejected: 2012-07-23

Section 10 says:

   Bernard Aboba    , Jari Arkko, Sam Hartman, Russ Housley    , Joe Salowey    ,
   Jesse Walker, Charles Clancy, Michaela Vanderveen, Kedar Gaonkar,
   Parag Agashe, Dinesh Dharmaraju, Pasi Eronen, Dan Harkins    , Yoshi
   Ohba, Glen Zorn, Alan DeKok, Katrin Hoeper, and other participants of
   the HOKEY working group.  The credit for the idea to use EAP-
   Initiate/Re-auth-Start goes to Charles Clancy, and the multiple link-
   layer SAs idea to mitigate the DoS attack goes to Yoshi Ohba.  Katrin
   Hoeper suggested the use of the windowing technique to handle
   multiple simultaneous ER exchanges.  Many thanks to Pasi Eronen for
   the suggestion to use hexadecimal encoding for rIKname when sent as
   part of keyName-NAI field.  Thanks to Bernard Aboba     for suggestions
   in clarifying the EAP lock-step operation, and Joe Salowey     and Glen
   Zorn for help in specifying AAA transport of ERP messages.  Thanks to
   Sam Hartman for the DSRK Authorization Indication mechanism.

It should say:

   Bernard Aboba, Jari Arkko, Sam Hartman, Russ Housley, Joe Salowey,
   Jesse Walker, Charles Clancy, Michaela Vanderveen, Kedar Gaonkar,
   Parag Agashe, Dinesh Dharmaraju, Pasi Eronen, Dan Harkins, Yoshi
   Ohba, Glen Zorn, Alan DeKok, Katrin Hoeper, and other participants of
   the HOKEY working group.  The credit for the idea to use EAP-
   Initiate/Re-auth-Start goes to Charles Clancy, and the multiple link-
   layer SAs idea to mitigate the DoS attack goes to Yoshi Ohba.  Katrin
   Hoeper suggested the use of the windowing technique to handle
   multiple simultaneous ER exchanges.  Many thanks to Pasi Eronen for
   the suggestion to use hexadecimal encoding for rIKname when sent as
   part of keyName-NAI field.  Thanks to Bernard Aboba for suggestions
   in clarifying the EAP lock-step operation, and Joe Salowey and Glen
   Zorn for help in specifying AAA transport of ERP messages.  Thanks to
   Sam Hartman for the DSRK Authorization Indication mechanism.

Notes:

Section is mis-formatted.

--RATIONALE--
The spacing error shown above is not present in the RFC (http://www.rfc-editor.org/rfc/rfc5296.txt).

RFC 5301, "Dynamic Hostname Exchange Mechanism for IS-IS", October 2008

Note: This RFC has been updated by RFC 6232

Source of RFC: isis (rtg)

Errata ID: 1540
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-10-08
Rejected by: Stewart Bryant
Date Rejected: 2011-01-28

Section 7, pg.4 says:

   This document specifies TLV 137, "Dynamic Name".  This TLV has
|  already been allocated and reserved [RFC2763].  As such, no new
|  actions are required on the part of IANA.

It should say:

   This document specifies TLV 137, "Dynamic Name".  This TLV has
|  already been allocated and reserved [RFC2763].  IANA has updated
|  the registry to reference this document for TLV 137.

Notes:

Rationale:
RFC 5226, section 5.2 lists references in IANA Registries
as subject to maintenance, and hence to be covered by IANA
Considerations sections in I-Ds / RFCs. Hence, re-parenting
of registrations should be explicitely mentioned there, in
order to avoid registries to become outdated/incomplete
over time, as has happened repeatedly in the past.

Fortunately, in this case IANA has operated intelligently
and updated the Ref. in the registry without being requested
explicitely. Thanks to IANA!

Nevertheless, I suggest to document this issue in an Errata Note
in order to remind future authors of the possible drawbacks of
not including update instructions for already existing registrations
in their IANA Considerations.
--VERIFIER NOTES--
This errata provided no additional information needed by an implementer of RFC5301.

RFC 5309, "Point-to-Point Operation over LAN in Link State Routing Protocols", October 2008

Source of RFC: isis (rtg)

Errata ID: 5007
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexander Vainshtein
Date Reported: 2017-04-30
Rejected by: Alvaro Retana
Date Rejected: 2018-03-14

Section 4.3 says:

For the ARP implementation (which checks that the subnet of the source 
address of the ARP request matches the local interface address), 
this check needs to be relaxed for the unnumbered p2p-over-lan circuits.

It should say:

For the ARP implementation (which checks that the subnet of the source 
address of the ARP request matches the local interface address), 
this check needs to be relaxed for the p2p-over-lan circuits 
(both numbered and unnumbered).

Notes:

Consider the following situation:
1. Two routers, R1 and R2, are connected by a physical P2P Ethernet link
2. OSPFv2 is enabled on the interfaces representing the endpoints of this link.
3. From the OSPF POV these interfaces:
o Are configured as P2P
o Belong to the same area
o Are assigned with IP addresses and subnet masks yielding different subnets
4. ARP check mentioned in the problematic text is not relaxed.

Under this conditions:
-Both R1 and R2 will accept Hello messages sent by the other router
(becase it ignores subnet in Hello messages received via P2P interfaces)
- Adjacency between R1 and R2 will progress to FULL state (because all OSPFv2 messages
will be sent with AllSPFRouters multicast IPv4 address)
- Unicast traffic sent by R1 to R2 (and vice versa) will be blackholed because ARP
will not resolve addresses assigned to the corresponding interfaces.
--VERIFIER NOTES--
RFC 5309 introduced the possibility of supporting an unnumbered configuration on a LAN. Statements in this RFC regarding ARP concerns are therefore deliberately limited to this new configuration.

For IS-IS, RFC 3787 Section 10 discusses concerns regarding mismatched subnets on numbered links.

For OSPF it is well known that there are some existing implementations which have supported mismatched subnets for many years.

Any concerns with ARP behavior in support of mismatched subnets on numbered LANs is out of scope of RFC 5309.

[https://mailarchive.ietf.org/arch/msg/isis-wg/aCFWc8KuE8xEy0-qIrN63odct1o/?qid=623f2d68947e2ec849fb2e2a7f2e6242]

RFC 5310, "IS-IS Generic Cryptographic Authentication", February 2009

Note: This RFC has been updated by RFC 6233, RFC 6232

Source of RFC: isis (rtg)

Errata ID: 2461
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Tony Li
Date Reported: 2010-08-12
Rejected by: Adrian Farrel
Date Rejected: 2012-08-16

Section 3.4 says:

The authentication data for the IS-IS IIH PDUs MUST be computed after
the IS-IS Hello (IIH) has been padded to the MTU size, if padding is 
not explicitly disabled.

It should say:

The authentication data for the IS-IS IIH PDUs MUST be computed after
the IS-IS Hello (IIH) has been padded to the MTU size, if padding is
not explicitly disabled.

ISes (routers) that implement CRYPTO_AUTH authentication and initiate LSP
purges MUST remove the body of the LSP and add the authentication TLV.  

Notes:

The RFC ignores the case of when an IS initiates a purge. Purges MUST be authenticated explicitly, otherwise the default protocol machinery will leave open a trivial attack.
--VERIFIER NOTES--
This issue appears to be correct, but does not qualify as something that can be addressed through the Errata System because it is a functional change to the document, not a typo. If the WG feels that it needs to be addressed, this should be captured in a new I-D.

Errata ID: 2462
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Tony Li
Date Reported: 2010-08-12
Rejected by: Adrian Farrel
Date Rejected: 2012-08-16

Section 3.5 says:

An implementation MAY have a transition mode where it includes
CRYPTO_AUTH information in the PDUs but does not verify this
information.  This is provided as a transition aid for networks in
the process of migrating to the new CRYPTO_AUTH-based authentication
schemes.

It should say:

An implementation MAY have a transition mode where it includes
CRYPTO_AUTH information in the PDUs but does not verify this
information.  This is provided as a transition aid for networks in
the process of migrating to the new CRYPTO_AUTH-based authentication
schemes.

ISes implementing CRYPTO_AUTH authentication MUST NOT accept
unauthenticated purges.   ISes MUST NOT accept purges that contain
TLVs other than the authentication TLV.  These restrictions are
necessary to prevent a hostile system from receiving an LSP, setting
the Remaining Lifetime field to zero, and flooding it, thereby
initiating a purge without knowing the authentication password.

Notes:

The RFC ignores the case of purges. With explicit definition, purge packets would not include authentication, which would open a trivial vector for attack.
--VERIFIER NOTES--
This issue appears to be correct, but does not qualify as something that can be addressed through the Errata System because it is a functional change to the document, not a typo. If the WG feels that it needs to be addressed, this should be captured in a new I-D.

RFC 5321, "Simple Mail Transfer Protocol", October 2008

Note: This RFC has been updated by RFC 7504

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: art

Errata ID: 4055
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Dave Crocker
Date Reported: 2014-07-19
Rejected by: Barry Leiba
Date Rejected: 2014-07-19

Section 3.6.2 says:

   This specification does not deal with the verification of return
   paths for use in delivery notifications.  Recent work, such as that
   on SPF [29] and DKIM [30] [31], has been done to provide ways to
   ascertain that an address is valid or belongs to the person who
   actually sent the message.

It should say:

   This specification does not deal with the verification of return
   paths for use in delivery notifications.  

Notes:

Neither SPF nor DKIM determine "validity" of an address. SPF determines whether an IP Address is 'authorized' to send mail with a particular domain name in the return address, but that does not validate the entire address, nevermind validating any destination or author addresses. DKIM has nothing at all to do with any existing address or domain name elsewhere in the message.

So I suggest merely dropping the problematic sentence.
--VERIFIER NOTES--
This is a change request, not an errata report.

Errata ID: 4079
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Sergey Afonin
Date Reported: 2014-08-12
Rejected by: Pete Resnick
Date Rejected: 2014-09-29

Section 4.3.2. says:

      DATA

         I: 354 -> data -> S: 250

                           E: 552, 554, 451, 452

                           E: 450, 550 (rejections for policy reasons)

         E: 503, 554

It should say:

      DATA

         I: 354 -> data -> S: 250

                           E: 552, 554, 451, 452

                           E: 450, 550 (rejections for policy reasons)

         E: 451, 503, 554

Notes:

"E: 451" after DATA exists in section 4.3.2 of RFC 2821:

DATA
I: 354 -> data -> S: 250
E: 552, 554, 451, 452
E: 451, 554, 503
--VERIFIER NOTES--
As discussed with the reporter: As far as we can tell, it was the intention to remove 451 in the transition from 2821 to 5321. This is not an error in the document. Error codes can be used by extensions without an update to 5321.

Errata ID: 4265
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Vance Kochenderfer
Date Reported: 2015-02-07
Rejected by: Barry Leiba
Date Rejected: 2015-03-01

Section F.2 says:

SMTP servers MUST continue to accept source route syntax as specified
in the main body of this document and in RFC 1123.  They MAY, if
necessary, ignore the routes and utilize only the target domain in the
address.

It should say:

SMTP servers MUST continue to accept source route syntax within RFC
5322 headers as specified in the main body of this document and in RFC
1123.  They SHOULD ignore source routes specified in envelope addresses
and utilize only the target domain, or MAY decline to accept envelope
addresses that specify source routes.

Notes:

The current wording of Section F.2 appears to contradict Sections 3.3 and 3.6.1.

Section 3.3 states: "Servers MUST be prepared to encounter a list of source routes in the forward-path, but they SHOULD ignore the routes or MAY decline to support the relaying they imply."

Section 3.6.1 states: "SMTP servers MAY decline to act as mail relays or to accept addresses that specify source routes."

RFC 1123 contains *two* separate relevant requirements: Section 5.2.6 states "A receiver-SMTP MUST accept the explicit source route syntax in the envelope..." and Section 5.2.19 states "Internet host software SHOULD NOT create an RFC-822 header containing an address with an explicit source route, but MUST accept such headers for compatibility with earlier systems."

It appears that Sections 3.3 and 3.6.1 are intended to remove the requirement to accept source route syntax within envelope addresses, but the current wording of Section F.2 contradicts this. If the intent of Section F.2 is only to continue the requirement to accept source route syntax within message headers, this should be made clear. The proposed text is written with this assumption in mind. If the intent of RFC 5321 is to remove both requirements, the proposed wording for Section F.2 requires further revision.

Also, if the intent of Sections 3.3 and 3.6.1 is to treat source routing differently for a <forward-path> and <reverse-path>, this should be clarified in all three sections. The proposed text assumes the requirements for both are the same.
--VERIFIER NOTES--
The text as it is, is what was intended. Moreover, this is another step along the way toward the deprecation of source routes, a path we started on a good many years ago. John Klensin is taking input for his working copy of a 5321bis, if specific text changes are suggested.

Errata ID: 6561
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Seiichi Hamada
Date Reported: 2021-04-27
Rejected by: Francesca Palombini
Date Rejected: 2022-03-25

Section 4.1.2. says:

Domain         = sub-domain *("." sub-domain)

It should say:

Domain         = sub-domain *("." sub-domain)[.]

Notes:

RFC-1034 section 3.1 say " Since a complete domain name ends with the root label, this leads to a printed form which ends in a dot." and also say 'a character string which represents a complete domain name (often called "absolute"). For example, "poneria.ISI.EDU." '.
It is necessary to allow a dot at the end of the domain name.
--VERIFIER NOTES--
As reported by John C Klensin in https://mailarchive.ietf.org/arch/msg/iesg/sAzZQpgOkD75eKQiS-RlWrmPhDk/ : The syntax used in SMTP predates RFC 1034. This possible change was discussed in the DRUMS WG when RFC 2821 was being assembled and rejected as likely to cause harm with existing implementations. If he recalls, that topic was revisited in the YAM WG that developed RFC 5321 with the conclusion to not reopen it.

So it is a substantive matter and not an editorial change and hence, as an erratum, it is rejected.

Errata ID: 2467
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Rushton
Date Reported: 2010-08-16
Rejected by: Pete Resnick
Date Rejected: 2011-06-11

Section 4.1.3 says:

   IPv6-comp      = [IPv6-hex *5(":" IPv6-hex)] "::"
                  [IPv6-hex *5(":" IPv6-hex)]
                  ; The "::" represents at least 2 16-bit groups of
                  ; zeros.  No more than 6 groups in addition to the
                  ; "::" may be present.

   IPv6v4-full    = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal

   IPv6v4-comp    = [IPv6-hex *3(":" IPv6-hex)] "::"
                  [IPv6-hex *3(":" IPv6-hex) ":"]
                  IPv4-address-literal
                  ; The "::" represents at least 2 16-bit groups of
                  ; zeros.  No more than 4 groups in addition to the
                  ; "::" and IPv4-address-literal may be present.

It should say:

   IPv6-comp      = [IPv6-hex *6(":" IPv6-hex)] "::"
                  [IPv6-hex *6(":" IPv6-hex)]
                  ; The "::" represents at least 1 16-bit groups of
                  ; zeros.  No more than 7 groups in addition to the
                  ; "::" may be present.

   IPv6v4-full    = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal

   IPv6v4-comp    = [IPv6-hex *4(":" IPv6-hex)] "::"
                  [IPv6-hex *4(":" IPv6-hex) ":"]
                  IPv4-address-literal
                  ; The "::" represents at least 1 16-bit groups of
                  ; zeros.  No more than 5 groups in addition to the
                  ; "::" and IPv4-address-literal may be present.

Notes:

As per RFC 4291 and RFC 3986, "::" can represent a single 16-bit group of zeroes.
--VERIFIER NOTES--
As per RFC 5952:

4.2.2. Handling One 16-Bit 0 Field

The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field.
For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but
2001:db8::1:1:1:1:1 is not correct.

Errata ID: 1820
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alessandro Vesely
Date Reported: 2009-07-30
Rejected by: Lisa Dusseault
Date Rejected: 2009-07-31

Section 3.9.2 says:

   A mailing list may be said to operate by "redistribution" rather than
   by "forwarding".     [...]     Note that
   the key difference between handling aliases (Section 3.9.1) and
   forwarding (this subsection) is the change to the backward-pointing
   address in this case.  [...]

It should say:

   A mailing list may be said to operate by "redistribution" rather than
   by "forwarding".     [...]     Note that
   the key difference between handling aliases (Section 3.9.1) and
   lists (this subsection) is the change to the backward-pointing
   address in this case.     [...]

Notes:

The change replaces the second occurrence of "forwarding" with "lists" in the first paragraph of section 3.9.2.

The term "forwarding" is generally used as a synonym of transmitting as opposed to delivering locally. The beginning of this section attempts to introduce the term "redistribution" for the specific type of transmission described therein. The phrase where the change is necessary, in its original wording, contradicts both the first phrase in its own paragraph, and the last phrase of the preceding section about aliases, which says that handling aliases may result in forwarding.
--VERIFIER NOTES--
This should be taken up with the group revising SMTP. The language chosen was intentional, so a fix is not as simple as an errata.

RFC 5322, "Internet Message Format", October 2008

Note: This RFC has been updated by RFC 6854

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 2104
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Wolf Lammen
Date Reported: 2010-04-02
Rejected by: Pete Resnick
Date Rejected: 2011-06-11

Section 4.1 says:

obs-unstruct    =   *((*LF *CR *(obs-utext *LF *CR)) / FWS)

It should say:

obs-unstruct    =   *(*LF *CR (obs-utext / FWS)) *LF *CR
                    ;The CR of a following CRLF MUST NOT be consumed.

Notes:

[I was notified, that errata report 1766 and 1908 has been verified, but apparently, report 1905 was left undecided. I am a bit concerned, because this report points to a true defect of RFC 5322, so, maybe, a clearer reasoning helps. This report is meant to replace my former posting 1905.]

The <obs-unstruct> rule covers field bodies of unstructured fields (as declared in section 2.2.1), that conform to obsoleted RFC 2822 or RFC 822. It is only to be used for downward compatibility when reading messages. It corresponds to <text> in RFC 822 and <obs-utext> in RFC 2822. In a conforming message, an unstructured field body is always followed by a field delimiting non-folding CRLF.

<obs-unstruct> is equivalent to *(d0-d127), so the CRLF delimiting the field is made part of the field body, as is the rest of the header section.

So my proposal refines the rule: Use any, possibly empty, sequence of ASCII characters, as long as it does not contain a CRLF outside of a folding white space.

There is a nuisance left: when applied possessively, the CR of the adjacent field delimiter CRLF is consumed as well. This cannot be overcome, no matter how you rewrite the rule, because the ABNF in RFC 5324 is not rich enough to express something like "consume all but one CR". A higher level construct like "obs-unstruct CRLF" must enforce a back-tracking step on the part of <obs-unstruct> in order to match. That is why I added the comment.
--VERIFIER NOTES--
Duplicate of erratum 1905, which I believe is correct as stated.

Errata ID: 2816
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Nemo
Date Reported: 2011-05-27
Rejected by: Pete Resnick
Date Rejected: 2011-05-27

Section 3.6.2 says:

   from            =   "From:" mailbox-list CRLF

   sender          =   "Sender:" mailbox CRLF

   reply-to        =   "Reply-To:" address-list CRLF

It should say:

   from            =   "From:" mailbox-list CRLF

   sender          =   "Sender:" mailbox CRLF

   reply-to        =   "Reply-To:" mailbox-list CRLF

Notes:

The text in section 3.6.2 (and everywhere else Reply-To is mentioned) makes it clear that Reply-To is envisioned as referring to one or more mailboxes. But the following chain of productions:

address-list -> address -> group -> DQUOTE DQUOTE ":" ";"

...means that the following Reply-To header would be permitted by the spec:

Reply-To: "" : ;

This header has no mailbox in it at all. So either the reply-to production rule is wrong (and should be a mailbox-list instead of an address-list), or the spec needs to explain what the semantics are for a Reply-To line with no mailboxes in it.

Note also the description of "group" in section 3.4:

The group construct allows the sender to indicate a named group of recipients.

Again, this does not envision using a group in a header like Reply-To. But that is what the current reply-to construct permits.

Summary: The RFC either needs to forbid Reply-To with zero mailboxes, or it needs to explain what the semantics of such a Reply-To are.
--VERIFIER NOTES--
Reply-To has allowed address lists (as against mailbox lists) as far back as RFC 733. This would be a change to long held consensus. Not appropriate for an erratum.

Errata ID: 3088
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Redwine
Date Reported: 2012-01-11
Rejected by: Pete Resnick
Date Rejected: 2012-02-20

Section 3.3 says:

date-time       =   [ day-of-week "," ] date time [CFWS]

It should say:

date-time       =   [ day-of-week "," ] date time [comment]

Notes:

If using the [CFWS] at the end of the original text, by the rules of CFWS, the next line could contain only FWS after the CRLF, which would violate the requirement found in 3.2.2, which reads: "...where CFWS occurs in this specification, it MUST NOT be inserted in such a way that any line of a folded header field is made up entirely of WSP characters and nothing else."
--VERIFIER NOTES--
CFWS allows there to be multiple comments, including comments that go on to the second line, which is perfectly OK.

Errata ID: 3675
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: David Hoerl
Date Reported: 2013-06-29
Rejected by: Pete Resnick
Date Rejected: 2013-07-08

Section 3 says:

3.2.3.  Atom Says:

   dot-atom        =   [CFWS] dot-atom-text [CFWS]

3.2.4.  Quoted Strings (but superseded by Errata 3135) Says:

   quoted-string   =   [CFWS]
                       DQUOTE ((1*([FWS] qcontent) [FWS]) / FWS) DQUOTE
                       [CFWS]

3.4.1.  Addr-Spec Specification Says:

   addr-spec       =   local-part "@" domain

   local-part      =   dot-atom / quoted-string / obs-local-part

   domain          =   dot-atom / domain-literal / obs-domain

   domain-literal  =   [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS]

It should say:

3.2.3.  Atom

   dot-atom        =   [CFWS] dot-atom-text [CFWS]

   dot-atom-lh     =   [CFWS] dot-atom-text [FWS]

   dot-atom-rh     =   [FWS] dot-atom-text [CFWS]

3.2.4.  Quoted Strings (but superseded by Errata 3135)

   quoted-string   =   [CFWS]
                       DQUOTE ((1*([FWS] qcontent) [FWS]) / FWS) DQUOTE
                       [CFWS]

   quoted-string-lh =  [CFWS]
                       DQUOTE ((1*([FWS] qcontent) [FWS]) / FWS) DQUOTE
                       [FWS]

3.4.1.  Addr-Spec Specification

   addr-spec       =   local-part "@" domain

   local-part      =   dot-atom-lh / quoted-string-lh / obs-local-part

   domain          =   dot-atom-rh / domain-literal / obs-domain

   domain-literal  =   [FWS] "[" *([FWS] dtext) [FWS] "]" [CFWS]

Notes:

Section 3.4.1 states "Comments and folding white space SHOULD NOT be used around the "@" in the addr-spec.", yet the ABNF specifically allows it without recourse to obsoleted terms. Given that the above statement is in fact correct, then the current ABNF should be modified as shown to reflect the above statement.
--VERIFIER NOTES--
The DRUMS Working Group made a conscious decision at the time of writing 2822 that they preferred clarity and ease of understanding of the ABNF at the expense of shift-reduce conflicts and other things that had to be limited in the text descriptions of the syntax, and that assumption carried over into 5322. This is one of those cases. While more precise, the correction is not what was intended, and there are many other cases where the text limits the more free syntax.

Errata ID: 5035
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Gene Hightower
Date Reported: 2017-06-09
Rejected by: Alexey Melnikov
Date Rejected: 2017-10-18

Section 3.3 says:

   time            =   time-of-day zone

   zone            =   (FWS ( "+" / "-" ) 4DIGIT) / obs-zone

It should say:

time            =       time-of-day FWS zone

zone            =       (( "+" / "-" ) 4DIGIT) / obs-zone

Notes:

The rfc5322 version of the syntax clearly forces the obs-zone to follow the time-of-day with no space. The syntax from rfc2822 seems to be what is actually in use in the real world. Why was this change made? Should it just be changed back?
--VERIFIER NOTES--
As per reply from Pete Resnick:

I believe this erratum report should be rejected. While it is true that
obs-zone does not begin with FWS, time-of-day ends with second, which
can be an obs-second, and obs-second ends with an optional CFWS.
Therefore, obs-zone is not forced to follow time-of-day with no space;
it just makes the space optional. And this allows for the original 822
syntax, which did not require space between the time-of-day and the
zone. (Somewhat goofy to allow that, but it is parseable.)

Errata ID: 5712
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Victor Shrubowich
Date Reported: 2019-04-29
Rejected by: Barry Leiba
Date Rejected: 2019-04-30

Section 3.2.2 says:

   FWS             =   ([*WSP CRLF] 1*WSP) /  obs-FWS
                                          ; Folding white space

It should say:

   FWS             =   ([*WSP] CRLF 1*WSP) /  obs-FWS
                                          ; Folding white space

Notes:

Both section 2.2.3 and part of section 3.2.2 ("Wherever folding appears in a message (that is, a header field body containing a CRLF followed by any WSP)") describe folding as adding CRLF followed by WSP, so CRLF is required for folding. However, the CRLF in the FWS rule is shown inside the square brackets, which would make it optional. It should not be inside the square brackets.

Square brackets: section 1.2.2 states "This specification uses the Augmented Backus-Naur Form (ABNF) [RFC5234] notation for the formal definitions of the syntax of messages." In RFC 5234, section 3.8 states "Square brackets enclose an optional element sequence".
--VERIFIER NOTES--

The FWS construct shows where folding is permitted (where CRLF *can* appear). The mechanism for actual folding is described in the text, and won't happen at each instance of FWS. Having the CRLF be optional is intentional and necessary.

Errata ID: 3400
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christoph Anton Mitterer
Date Reported: 2012-11-06
Rejected by: Pete Resnick
Date Rejected: 2012-12-10

Section 3.5. says:

   message         =   (fields / obs-fields)
                       [CRLF body]

   body            =   (*(*998text CRLF) *998text) / obs-body

It should say:

   message         =   (fields / obs-fields)
                       [CRLF body]

   body            =   (*(*998text CRLF) *998text) / obs-body

It is RECOMMENDED that message bodies are terminated by CRLF, though 
this is in principle not necessary (this does not apply to messages 
consisting only of a header section, as header fields are always CRLF
terminated).

Note however, that when transporting messages via SMTP the last lines 
of message bodies MUST be terminated by CRLF as specified int 
RFC 5321, section 4.1.1.4.

Notes:

Hi folks.

AFAIU, the definition of body allows message bodies (not header sections) that end without CRLF.

RFC5321 section 4.1.1.4. however states: "The mail data are terminated by a line containing only a period, that is, the character sequence "<CRLF>.<CRLF>", where the first <CRLF> is actually the terminator of the previous line".

So SMTP forbids, what this RFC allows.
I guess the SMTP RFC can't be changed here and it makes no particular sense to restrict RFC5322 on the other hand.

My suggestion was to add this clarification.

Perhaps a similar one should be added to RFC5321, telling that Internet Messages themselves wouldn't need the last CRLF.
--VERIFIER NOTES--
It is clearly a change from WG consensus to add any normative 2119 text regarding a terminating CRLF. (See archive of the DRUMS WG, 17-18 March 1998 in a thread with a subject of "Small Clarification to msg-fmt-04".) The CRLF is not required for the message syntax. There are things other than this that 5321 cannot transport, so is also unlikely to be in scope for 5321 as an erratum either. Perhaps a discussion of this might be useful for RFC 3030, but again, it is unlikely to be an erratum.

Errata ID: 2619
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dominic Sayers
Date Reported: 2010-11-10
Rejected by: Pete Resnick
Date Rejected: 2011-05-16

Section 3.4.1 says:

      It is therefore
      incumbent upon implementations to conform to the syntax of
      addresses for the context in which they are used.

It should say:

      Implementations MUST conform to the syntax of
      addresses for the context in which they are used.

Notes:

The phrase "incumbent upon" is not defined in RFC 2119. If another RFC defines a standard with the force of "MUST", then it is not an option for an implementation to ignore that standard. Therefore, implementations MUST conform to their syntax.

This rewording clarifies the recognition that should be given to the RFCs that inform the particular context of the implementation.
--VERIFIER NOTES--
Conforming (or failing to conform) to the syntax of another specification does not affect the interoperability of *this* specification. Therefore, RFC 2119 language is not appropriate. However, even if it could be argued that it was, an erratum is not the appropriate place to make such a change.

Errata ID: 2620
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dominic Sayers
Date Reported: 2010-11-10
Rejected by: Pete Resnick
Date Rejected: 2011-05-16

Section 3.4.1 says:

   Comments and folding white space
   SHOULD NOT be used around the "@" in the addr-spec.

It should say:

   Comments and folding white space
   SHOULD NOT be used around the "@" in the addr-spec. Comments and
   folding white space at the beginning and end of an addr-spec are
   semantically invisible.

Notes:

Section 3.2.2 says

"Runs of FWS, comment, or CFWS that occur between lexical tokens in a
structured header field are semantically interpreted as a single
space character."

but a leading or trailing space on an addr-spec would prevent it being interpreted as a valid RFC 5321 Mailbox (see http://tools.ietf.org/html/rfc5321#section-4.1.2).

This is important because this section of RFC 5322 also says

"It is therefore
incumbent upon implementations to conform to the syntax of
addresses for the context in which they are used."

Either the leading and trailing CFWS should be semantically "invisible" or additional logic is required for implementations to transform an RFC 5322 addr-spec into an RFC 5321 Mailbox.

Note: It may be true that leading and trailing CFWS is not "between lexical tokens". If so then it should be made clear what semantic interpretation to put on it in this case.
--VERIFIER NOTES--
1. "addr-spec" does not appear in 5321. 5321 and 5322 have two different definitions for "Mailbox" and "mailbox" respectively, and that is a topic for an update of these documents, not for an erratum.

2. This report does not want the CFWS to be *semantically* invisible; it wants it to be *syntactically* invisible when moving an addr-spec from a 5322 context to a 5321 context. This document does not discuss this use.

Errata ID: 3134
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ashley Willis
Date Reported: 2012-02-25
Rejected by: Pete Resnick
Date Rejected: 2012-04-28

Section Appendix A.5 says:

   From: Pete(A nice \) chap) <pete(his account)@silly.test(his host)>
   To:A Group(Some people)
        :Chris Jones <c@(Chris's host.)public.example>,
            joe@example.org,
     John <jdoe@one.test> (my dear friend); (the end of the group)

It should say:

   From: Pete(A nice \) chap) <pete(his account)@silly.test(his host)>
   To:A Group(Some people)
        :Chris Jones <c@(Chris's host.)public.example>,
            joe@example.org,
     John <jdoe@one.test> (my dear friend); (the end of the group)

Notes:

Errata 2515 and 2579 change the above text, but there is no change needed to the original RFC. The quote from Section 3.4.1 says "SHOULD NOT", not "MUST NOT" ("Comments and folding white space SHOULD NOT be used around the "@" in the addr-spec."). The example in A.5 "is aesthetically displeasing, but perfectly legal." It's meant to highlight extreme cases.
--VERIFIER NOTES--
Though unstated in the text, the intention of the WG was that the examples in A.1-5 were intended to be messages that conformed to all of the MUSTs and SHOULDs of section 3. Indeed, RFC 2119 defines SHOULD NOT to mean effectively MUST NOT unless you have fully understood and weighed the reasons for choosing a different course. The description below the example says that it is "aesthetically displeasing, but perfectly legal". I don't think violating a SHOULD NOT makes it "perfectly" legal.

RFC 5328, "A Uniform Resource Name (URN) Namespace for the Digital Video Broadcasting Project (DVB)", September 2008

Note: This RFC has been updated by RFC 7354, RFC 8553

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 3992
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alexander Adolf
Date Reported: 2014-05-19
Rejected by: Barry Leiba
Date Rejected: 2014-05-19

Section Authors' Add says:

Authors' Addresses

   Alexander Adolf
   Micronas GmbH
   Frankenthalerstrasse 2
   D-81539 Munich
   GERMANY
   Tel: +49 89 54845 7203
   Fax: +49 89 54845 7900
   EMail: alexander.adolf@micronas.com

   Peter MacAvock
   DVB Digital Video Broadcasting
   Ancienne Route 17a
   CH-1218 Geneva
   SWITZERLAND
   Tel: +41 22 717 2717
   EMail: macavock@dvb.org

It should say:

Authors' Addresses

   Alexander Adolf
   Condition-ALPHA
   Gabelsbergerstrasse 60b
   80333 Munich
   GERMANY
   Tel: +49 89 52314163
   EMail: alexander.adolf@condition-alpha.com

   Peter Siebert
   DVB Digital Video Broadcasting Project
   Ancienne Route 17a
   1218 Geneva
   SWITZERLAND
   Tel: +41 22 717 2717
   EMail: dvb@dvb.org

Notes:

I have changed my affiliation, and the DVB Project has a new managing director. Also, the DVB contact should use the generic email address (more longevity).
--VERIFIER NOTES--
The correction of the contact information needs to be done, but the errata system isn't the right way to do it. I'm working with the author to get a short update published that will make the change in a new RFC.

RFC 5331, "MPLS Upstream Label Assignment and Context-Specific Label Space", August 2008

Note: This RFC has been updated by RFC 7274

Source of RFC: mpls (rtg)

Errata ID: 3726
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Liu Lin
Date Reported: 2013-09-16
Rejected by: Adrian Farrel
Date Rejected: 2013-09-27

Section 6 says:

In the former case, an LSR distributes an upstream-assigned 
label binding for a FEC F if it is either (a) the ingress LSR 
for FEC F, or (b) if it has already received an upstream label 
binding for that FEC from its adjacent upstream LSR for FEC F, 
or (c) if it has received a request for a downstream label 
binding from its upstream adjacent LSR.

It should say:

In the former case, an LSR distributes an upstream-assigned 
label binding for a FEC F if it is either (a) the ingress LSR 
for FEC F, or (b) if it has already received an upstream label 
binding for that FEC from its adjacent upstream LSR for FEC F, 
or (c) if it has received a request for a upstream label 
binding from its downstream adjacent LSR.

Notes:

if a LSR has received a request for a downstream label binding from its upstream adjacent LSR, it will distributes a downstream-assigned label, not upstream-assigned-label. When a LSR has received a request for a upstream label binding from its downstream adjacent LSR, it may distributs a upstream-assigned label.
--VERIFIER NOTES--
The reporter has become confused between the different uses of "upstream" and "downstream" in the text.

The original text may have intended to imply that when an LSR receives a request for a downstream label from its upstream adjacent LSR then it
will use this as a trigger to send an upstream-assigned label to its
downstream adjacent LSR.

Thus the text is correct as it stands.

RFC 5340, "OSPF for IPv6", July 2008

Note: This RFC has been updated by RFC 6845, RFC 6860, RFC 7503, RFC 8362, RFC 9454

Source of RFC: ospf (rtg)

Errata ID: 2046
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Acee Lindem
Date Reported: 2010-02-17
Rejected by: Stewart Bryant
Date Rejected: 2012-02-07

Section 4.8.1 says:

   o  In Step 2, when a router Vertex V has just been added to the
      shortest-path tree, there may be multiple LSAs associated with the
      router.  All router-LSAs with the Advertising Router set to V's
      OSPF Router ID MUST be processed as an aggregate, treating them as
      fragments of a single large router-LSA.  The Options field and the




Coltun, et al.              Standards Track                    [Page 45]
^L
RFC 5340                     OSPF for IPv6                     July 2008


      router type bits (bits Nt, V, E, and B) should always be taken
      from the router-LSA with the smallest Link State ID.

   o  Step 2a is not needed in IPv6, as there are no longer stub network
      links in router-LSAs.

   o  In Step 2b, if W is a router and the router-LSA V6-bit or R-bit is
      not set in the LSA options, the transit link W is ignored and V's
      next link is examined.

It should say:

   o  In Step 2, when a router Vertex V has just been added to the
      shortest-path tree and the router-LSA R-bit is not set in the
      LSA options, Vertex V's links are ignored and the next vertex on
      the candidate list should be examined as described in Step 3.



Coltun, et al.              Standards Track                    [Page 45]
^L
RFC 5340                     OSPF for IPv6                     July 2008


   o  Also In Step 2, when a router Vertex V has just been added to the
      shortest-path tree, there may be multiple LSAs associated with the
      router.  All router-LSAs with the Advertising Router set to V's
      OSPF Router ID MUST be processed as an aggregate, treating them as
      fragments of a single large router-LSA.  The Options field and the
      router type bits (bits Nt, V, E, and B) should always be taken
      from the router-LSA with the smallest Link State ID.

   o  Step 2a is not needed in IPv6, as there are no longer stub network
      links in router-LSAs.

   o  In Step 2b, if W is a router and the router-LSA V6-bit is not set
      in the LSA options, the transit link to W is ignored and V's next
      link is examined.

Notes:

This changes reflects the fact that the R-bit and the V6-bit should not be handled identically. The R-bit allows the router to participate in the IPv6 unicast topology but does not allow transit traffic. The V6-bit doesn't allow either. This problem was pointed out by Balaji Ganesh.
--VERIFIER NOTES--
This has been superseded by Errata 2078

Errata ID: 7649
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Owen DeLong
Date Reported: 2023-09-19
Rejected by: John Scudder
Date Rejected: 2024-01-11

Section A.3.3 (in part) says:

Interface MTU
      The size in bytes of the largest IPv6 datagram that can be sent
      out the associated interface without fragmentation.  The MTUs of
      common Internet link types can be found in Table 7-1 of [MTUDISC].
      Interface MTU should be set to 0 in Database Description packets
      sent over virtual links.

It should say:

Interface MTU
      The size in bytes of the largest IPv6 datagram that can be sent
      out the associated interface without fragmentation.  The MTUs of
      common Internet link types can be found in Table 7-1 of [MTUDISC].
      Interface MTU should be set to 0 in Database Description packets
      sent over OSPF virtual links. This rule should not be applied to tunnel
      or other software interfaces.

Notes:

OSPF Virtual links carry only OSPF packets so MTU negotiation is not needed and this provision makes sense. For interfaces that have an actual MTU, even though they may be "virtual" interfaces, they are not "virtual links" in the intended meaning of this paragraph. As such, this change will provide clarification and remove ambiguity from the current standard. At least one popular router vendor implements this RFC as MTU = 0 sent on all GRE interfaces which results in incompatibilities with most other router platforms which expect an actual value. The router vendor points to this provision in the RFCs as justification for their implementation. It is (arguably) a legitimate, if nonsensical interpretation of the existing text.
--VERIFIER NOTES--
See discussion at https://mailarchive.ietf.org/arch/msg/lsr/mrmkQt9ETTYemukBzl6K_FmgHps/

It seems as though there is not clear consensus for the proposed change or even to make a similar change; as such the normal WG process (internet draft, WG consensus) is a better way to pursue the goal.

RFC 5357, "A Two-Way Active Measurement Protocol (TWAMP)", October 2008

Note: This RFC has been updated by RFC 5618, RFC 5938, RFC 6038, RFC 7717, RFC 7750, RFC 8545

Source of RFC: ippm (ops)

Errata ID: 3511
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Steve Baillargeon
Date Reported: 2013-03-08
Rejected by: Martin Stiemerling
Date Rejected: 2015-07-16

Section Appendix says:

              controller                              responder
          +-----------------+                   +-------------------+
          |     Server      |<----------------->|                   |
          | Control-Client  |                   | Session-Reflector |
          | Session-Sender  |<--TWAMP-Test----->|                   |
          +-----------------+                   +-------------------+

   This example provides a simple architecture for responders where
   their role will be to simply act as light test points in the network.
   The controller establishes the test session with the Server through
   non-standard means.  After the session is established, the controller
   transmits test packets to the responder.  The responder follows the
   Session-Reflector behavior of TWAMP as described in section 4.2 with
   the following exceptions.

   In the case of TWAMP Light, the Session-Reflector does not
   necessarily have knowledge of the session state.  IF the Session-
   Reflector does not have knowledge of the session state, THEN the
   Session-Reflector MUST copy the Sequence Number of the received
   packet to the Sequence Number field of the reflected packet.  The
   controller receives the reflected test packets and collects two-way
   metrics.  This architecture allows for collection of two-way metrics.

It should say:

              controller                              responder
          +-----------------+                   +-------------------+
          |     Server      |                   |                   |
          | Control-Client  |                   | Session-Reflector |
          | Session-Sender  |<--TWAMP-Test----->|                   |
          +-----------------+                   +-------------------+

   This example provides a simple architecture for responders where
   their role will be to simply act as light test points in the network.
   The controller establishes the test session with the Server through
   non-standard means.  After the session is established, the controller
   transmits test packets to the responder. Other examples are also
   possible. For instance, the responder may include a light Server
   responsible to instantiate the test session states based on the
   received test packets. The responder follows the Session-Reflector
   behavior of TWAMP as described in section 4.2 with the following
   exceptions.

   In the case of TWAMP Light, the Session-Reflector does not
   necessarily have knowledge of the session state.  IF the Session-
   Reflector does not have knowledge of the session state, THEN the
   Session-Reflector MUST copy the Sequence Number of the received
   packet to the Sequence Number field of the reflected packet.  The
   controller receives the reflected test packets and collects two-way
   metrics. This architecture allows for collection of two-way metrics.
   Otherwise IF the Session- Reflector has knowledge of the session
   state (using inspection of the received test packets for instance),
   THEN the Session-Reflector MUST generate it is own sequence number
   for each reflected packet.  The controller receives the reflected
   test packets and collects two-way and one-way metrics.  This
   alternative allows for collection of two-way and one-way metrics with
   TWAMP Light.

Notes:

Many readers of the appendix don't understand the meaning of informative and try to interpret the TWAMP light description as a specification. To correct this problem, it is recommended to add a few more lines explaning other TWAMP light architectures are possible. The original text describes a single TWAMP light architecture and this is misleading.
--VERIFIER NOTES--
Erratas are not meant to be used to expand existing text beyond textual clarifications.

RFC 5359, "Session Initiation Protocol Service Examples", October 2008

Source of RFC: sipping (rai)

Errata ID: 7718
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Fabien R.
Date Reported: 2023-12-01
Rejected by: Murray Kucherawy
Date Rejected: 2023-12-01

Section 2.1 says:

             |           No RTP Sent!        |

It should say:

             |           One way RTP         |
             |<==============================|

Notes:

If we follow the explanation next to the diagram, the RTP flow should be 'unidirectionnal' after the hold because F10 is using a=sendonly and F12 a=recvonly.

[AD Note, forwarded from Robert Sparks:]
The existing text explains and it is intentional that the diagram claims that no media is sent.
--VERIFIER NOTES--

RFC 5378, "Rights Contributors Provide to the IETF Trust", November 2008

Source of RFC: ipr (gen)

Errata ID: 5114
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: John Klensin
Date Reported: 2017-09-14
Rejected by: Lars Eggert
Date Rejected: 2021-03-29

Section 1(j) says:

"Legend Instructions": the standardized text that is maintained by the
IETF Trust and is included in IETF Documents and the instructions and
requirements for including that standardized text in IETF Documents.
The text and instructions are posted from time to time at
http://trustee.ietf.org/license-info.

It should say:

Beats me.  See below.  It is probably better to fix this problem by
making the link point to what the RFC says it points to than to
create a final erratum for the RFC, but even the latter would require 
some effort for the erratum to describe a stable reference.

Notes:

When this link is used, it redirects to http://trustee.ietf.org/license-info, but that link redirects to the Trust Legal Provisions main page (https://trustee.ietf.org/trust-legal-provisions.html ) which not only does not contain the promised text and instructions, but doesn't even contain the word "Legend". One might figure out that one is supposed to go to the actual TLP page (currently https://trustee.ietf.org/documents/IETF-TLP-5_001.html), but, while that page mentions "legend(s)" several times, one of those places is not in Section 6, which is described as "Text To Be Included..." and not "Legends" as this RFC implies.
--VERIFIER NOTES--
The web page at http://trustee.ietf.org/license-info still redirects to https://trustee.ietf.org/documents/trust-legal-provisions/, but that page was recently updated to point the reader to the IETF Trust FAQ for RFC5378 instructions.

RFC 5389, "Session Traversal Utilities for NAT (STUN)", October 2008

Note: This RFC has been obsoleted by RFC 8489

Note: This RFC has been updated by RFC 7350, RFC 8553

Source of RFC: behave (tsv)

Errata ID: 3327
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Todd Herman
Date Reported: 2012-08-20
Rejected by: Wes Eddy
Date Rejected: 2012-09-06

Section 15.3 says:

   The USERNAME attribute is used for message integrity.  It identifies
   the username and password combination used in the message-integrity
   check.

Notes:

There is no explanation or description as to where this "password" comes from. The statement indicates that the password is also part of the username field but that may not actually be true according to additional research I conducted and other portions of the specification.

If the password is part of this field than it should be explicitly noted how the two values are concatenated. If this is not accurate, than the "and password combination" portion should be removed.
--VERIFIER NOTES--
Based on BEHAVE mailing list discussion, other sections of the document (e.g. section 10) make this pretty clear, and there does not seem to be any need for a change or correction to the document.

RFC 5420, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", February 2009

Note: This RFC has been updated by RFC 6510

Source of RFC: ccamp (rtg)

Errata ID: 1688
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-02-20
Rejected by: Adrian Farrel
Date Rejected: 2010-01-02

Section 11.2,11.3 says:

     ... allocated only by IETF Consensus.
                                ^^^^^^^^^

It should say:

     ... allocated only by IETF Review.
                                ^^^^^^

Notes:

Location:
a) last paragraph of section 11.2
b) third paragraph of section 11.3

Rationale:
Adaptation to updated IANA policy terminology as per RFC 5226
has been missed.
--VERIFIER NOTES--
The IANA action was correctly taken in this case before the adoption of RFC5226 as an RFC. Thus the IANA action was correct. Furthermore, the mapping from IETF Consensus to IETF Review is well-known.

RFC 5443, "LDP IGP Synchronization", March 2009

Note: This RFC has been updated by RFC 6138

Source of RFC: mpls (rtg)

Errata ID: 4686
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexander Okonnikov
Date Reported: 2016-05-06
Rejected by: Deborah Brungard
Date Rejected: 2016-07-13

Section 3 says:

It should say:

(At the end of the section)

In case of OSPF while router advertises maximum cost, virtual link(s)
that cross link under question, could be broken. This is because
virtual link, which underlying path has cost greater than 0xFFFF,
considered as inoperational. As a result, virtually connected area(s)
could be isolated from backbone.

Notes:

In case there are two or more links on path taken by virtual link, and one of them has max link cost, path metric will exceed value 0xffff. As a result virtual link will become inoperational.
--VERIFIER NOTES--
This update requires consensus by the Working Group.

RFC 5451, "Message Header Field for Indicating Message Authentication Status", April 2009

Note: This RFC has been obsoleted by RFC 7001

Note: This RFC has been updated by RFC 6577

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 3182
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: D. Stussy
Date Reported: 2012-04-09
Rejected by: Barry Leiba
Date Rejected: 2012-04-18

Section Header. says:

It should say:

Updated by RFC 6577.

Notes:

RFC 6577 (March 2012) indicates that it updates 5451, but 5451 does not indicate it is updated. This update is the same as errata ID 2617 (date reported 2010-11-09).
--VERIFIER NOTES--
The "updated by" information is in the metadata for the RFC, and that metadata is correct (see the version in the datatracker: https://datatracker.ietf.org/doc/rfc5451/ ). The text of an RFC does not change once it's published.

RFC 5454, "Dual-Stack Mobile IPv4", March 2009

Source of RFC: mip4 (int)

Errata ID: 1719
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-03-15
Rejected by: Brian Haberman
Date Rejected: 2012-05-11

Section 2.2, pg.7 says:

   The following values are defined for use as a Code value in the above
   extension:

|     0 registration accepted, IPv6 to be tunneled to HoA

|     1 registration accepted, IPv6 to be tunneled to CoA

      8 registration rejected, reason unspecified

      9 registration rejected, administratively prohibited

It should say:

   The following values are defined for use as a Code value in the above
   extension:

|     0 registration accepted, IPv6 will be tunneled to HoA

|     1 registration accepted, IPv6 will be tunneled to CoA

      8 registration rejected, reason unspecified

      9 registration rejected, administratively prohibited

Notes:

Rationale: The extension described in this section is sent
from the Home Agent to the Mobile Node and reflects the decisions
made by the Home Agent. "to be tunnelled" could be misunderstood;
the text should better be stated as a confirmation; hence s/to/will/.
--VERIFIER NOTES--
The wording clearly conveys the action of tunneling the extension.

RFC 5464, "The IMAP METADATA Extension", February 2009

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 3160
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Adrien de Croy
Date Reported: 2012-03-22
Rejected by: Pete Resnick
Date Rejected: 2012-04-28

Section 4.4.2 says:

   The response consists of a list of entries, each of which have
   changed on the server or mailbox.

   Example:
           C: a NOOP
           S: * METADATA "" /shared/comment
           S: a OK NOOP complete

      In the above example, the server indicates that the "/shared/
      comment" server entry has been changed.

   Example:

           C: a NOOP
           S: * METADATA "INBOX" /shared/comment /private/comment
           S: a OK NOOP complete

      In the above example, the server indicates a change to two mailbox
      entries.

It should say:

needs design input

Notes:

unsolicited METADATA responses not clear as to scope / state

need some prose about what to do depending on client state.

if a client has a mailbox selected should it receive unsolicited metadata responses relating ONLY to that mailbox, or any mailbox? The response has a mailbox field, so it's feasible a client not in a selected state could want responses for any metadata change on any mailbox.
--VERIFIER NOTES--
A desire for more explanatory prose is not appropriate for an erratum.

RFC 5492, "Capabilities Advertisement with BGP-4", February 2009

Note: This RFC has been updated by RFC 8810

Source of RFC: idr (rtg)

Errata ID: 3882
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Ramakrishna DTV
Date Reported: 2014-02-05
Rejected by: Stewart Bryant
Date Rejected: 2014-03-02

Section 3 says:

"   A BGP speaker determines that its peer doesn't support capabilities
   advertisement if, in response to an OPEN message that carries the
   Capabilities Optional Parameter, the speaker receives a NOTIFICATION
   message with the Error Subcode set to Unsupported Optional Parameter.
   (This is a consequence of the base BGP-4 specification [RFC4271] and
   not a new requirement.)  In this case, the speaker SHOULD attempt to
   re-establish a BGP connection with the peer without sending to the
   peer the Capabilities Optional Parameter."

It should say:

"   A BGP speaker determines that its peer doesn't support capabilities
   advertisement if, in response to an OPEN message that carries the
   Capabilities Optional Parameter, the speaker receives a NOTIFICATION
   message with the Error Subcode set to Unsupported Optional Parameter.
   (This is a consequence of the base BGP-4 specification [RFC4271] and
   not a new requirement.) The next actions depends on the BGP
   speaker that received the NOTIFICATION. The speaker may intend to
   re-establish a BGP connection with the peer. In this case, the 
   speaker SHOULD attempt to re-establish a BGP connection with the 
   peer without sending to the peer the Capabilities Optional 
   Parameter. On the other hand, the speaker may not intend to 
   re-establish peering.  For example, a BGP speaker may not intend 
   to re-establish peering if it established
   peering to exchange IPv6 routes and determines that its peer does not
   support capabilities advertisement. The decision to re-establish the
   peering is local to the speaker."

Notes:

Notes: As explained above, it does not always make sense to
re-establish peering when the peer does not support capabilities
advertisement. Indeed, in a very similar scenario, this RFC itself
suggests the proposed behavior. Consider the following text in
Section 3:

" If a BGP speaker that supports a certain capability determines that
its peer doesn't support this capability, the speaker MAY send a
NOTIFICATION message to the peer and terminate peering (see Section
"Extensions to Error Handling" for more details). For example, a BGP
speaker may need to terminate peering if it established peering to
exchange IPv6 routes and determines that its peer does not support
Multiprotocol Extensions for BGP-4 [RFC4760]. The Error Subcode in
the NOTIFICATION message is then set to Unsupported Capability. The
message MUST contain the capability or capabilities that cause the
speaker to send the message. The decision to send the message and
terminate the peering is local to the speaker. If terminated, such
peering SHOULD NOT be re-established automatically."
--VERIFIER NOTES--
This is a technical matter that should be discussed in the WG and if the WG decides that clarification is needed it should be addressed in an RFC.

The text referenced above is a SHOULD, and thus an implementation decision. The provision of further guidance to the implementer is outside the scope of the errata process.

RFC 5514, "IPv6 over Social Networks", April 2009

Source of RFC: INDEPENDENT

Errata ID: 5223
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Luís Câmara
Date Reported: 2018-01-01
Rejected by: Adrian Farrel
Date Rejected: 2018-04-14

Section 7.1 says:

It should say:

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

Notes:

RFC 2119 key words (like SHOULD, SHOULD NOT, ...) are used throughout RFC 5514, but RFC 2119 is not referenced.
--VERIFIER NOTES--
The presence of RFC 2119 boilerplate and reference is needed if and only if the authors intend the use of upper case words to be interpreted as defined in RFC 2119.

Errata ID: 1750
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Brian Carpenter
Date Reported: 2009-04-01
Rejected by: Nevil Brownlee
Date Rejected: 2013-03-16

The title says:

IPv6 over Social Networks 

It should say:

IPv6 over Anti-Social Networks 

Notes:

--VERIFIER NOTES--
The body of 5514 is about communicating over Social Networks;
its title doesn't need to be changed.

RFC 5515, "Layer 2 Tunneling Protocol (L2TP) Access Line Information Attribute Value Pair (AVP) Extensions", May 2009

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: int

Errata ID: 4620
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Jewgenij Bytschkow
Date Reported: 2016-02-17
Rejected by: Eric Vyncke
Date Rejected: 2023-08-03

Section 4.1. says:

   The following AVPs MUST be present in the CSUN:

      Message Type

      Connect Speed Update (more than one may be present in the CSUN)

   Note that the LAC MUST NOT include a Connect Speed Update AVP for
   which it did not send a Connect Speed Update Enable AVP in the prior
   Incoming-Call-Request (ICRQ) control message for the session.

It should say:

   The following AVPs MUST be present in the CSUN:

      Message Type

      Connect Speed Update (more than one may be present in the CSUN)

   If a CSUN message contains two or more Connect Speed Update AVPs
   (as updates for two or more sessions in the tunnel), the Session ID
   of the L2TP control message MUST be 0.  It is because a CSUN message
   with several Connect Speed Update AVPs is related to several sessions
   in the tunnel, rather than to a single session. 

   Note that the LAC MUST NOT include a Connect Speed Update AVP for
   which it did not send a Connect Speed Update Enable AVP in the prior
   Incoming-Call-Request (ICRQ) control message for the session.

Notes:

The suggested additional MUST requirement is important for LAC-LNS
operation in order to avoid arbitrary, opposite and conflicting
interpretations and implementations of the RFC5515 on LAC and LNS.
--VERIFIER NOTES--
Section 4.1.1.2 of RFC 3931 has reserved that value of 0 for Session ID, this specific value cannot be re-used.

RFC 5519, "Multicast Group Membership Discovery MIB", April 2009

Source of RFC: magma (int)

Errata ID: 3690
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Herbie Robinson
Date Reported: 2013-07-30
Rejected by: Brian Haberman
Date Rejected: 2013-08-21

Section 5. says:

INDEX { mgmdHostInterfaceIfIndex,
mgmdHostInterfaceQuerierType }

It should say:

INDEX { mgmdHostInterfaceIfIndex,
mgmdHostInterfaceQuerierType, mgmdHostInterfaceQuerier}

Notes:

The mgmdHostInterfaceQuerier field should be included in the index to handle the case where there are multiple aliases.
--VERIFIER NOTES--
Adding support for aliases needs to be proposed for a future version of the group management protocols and the MIB. It cannot be added via an erratum statement.

RFC 5531, "RPC: Remote Procedure Call Protocol Specification Version 2", May 2009

Note: This RFC has been updated by RFC 9289

Source of RFC: nfsv4 (wit)

Errata ID: 4099
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: anatoly techtonik
Date Reported: 2014-09-05
Rejected by: Martin Stiemerling
Date Rejected: 2015-12-16

Throughout the document, when it says:

This document describes the Open Network Computing (ONC) Remote
Procedure Call (RPC) version 2 protocol as it is currently deployed
and accepted.

Notes:

The document doesn't describe UDP and TCP port number 111, which is used to make initial connection for RCP services discovery and port mapping. Port mapping is an essential part of protocol without which ONC RPC services can't work.

RFC doesn't describe 111 is hardcoded number or can be changed. Doesn't say that servers typically listen on both UDP and TCP 111 (Linux nfs-kernel-server).
--VERIFIER NOTES--
This RFC is solely describing the RPC protocol and not the underlying transport that might be used.

RFC 5545, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", September 2009

Note: This RFC has been updated by RFC 5546, RFC 6868, RFC 7529, RFC 7953, RFC 7986, RFC 9073, RFC 9074, RFC 9253

Source of RFC: calsify (app)

Errata ID: 2676
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Dennis Gearon
Date Reported: 2010-12-20
Rejected by: Alexey Melnikov
Date Rejected: 2011-01-20

Section 3.6.1 says:

                  ; The following are OPTIONAL,
                  ; but MUST NOT occur more than once.
                  ;
                  class / created / description / geo /
                  last-mod / location / organizer / priority /
                  seq / status / summary / transp /
                  url / recurid /
                  ;
                  ; The following is OPTIONAL,
                  ; but SHOULD NOT occur more than once.
                  ;
                  rrule /
                  ;
                  ; Either 'dtend' or 'duration' MAY appear in
                  ; a 'eventprop', but 'dtend' and 'duration'
                  ; MUST NOT occur in the same 'eventprop'.
                  ;
                  dtend / duration /
                  ;
                  ; The following are OPTIONAL,
                  ; and MAY occur more than once.
                  ;
                  attach / attendee / categories / comment /
                  contact / exdate / rstatus / related /
                  resources / rdate / x-prop / iana-prop
                  ^^^^^^^^^
                  ;

It should say:

                  ; The following are OPTIONAL,
                  ; but MUST NOT occur more than once.
                  ;
                  class / created / description / geo /
                  last-mod / location / organizer / priority /
                  seq / status / summary / transp /
                  url / recurid / resources 
                                  ^^^^^^^^^
                  ;
                  ; The following is OPTIONAL,
                  ; but SHOULD NOT occur more than once.
                  ;
                  rrule /
                  ;
                  ; Either 'dtend' or 'duration' MAY appear in
                  ; a 'eventprop', but 'dtend' and 'duration'
                  ; MUST NOT occur in the same 'eventprop'.
                  ;
                  dtend / duration /
                  ;
                  ; The following are OPTIONAL,
                  ; and MAY occur more than once.
                  ;
                  attach / attendee / categories / comment /
                  contact / exdate / rstatus / related /
                  rdate / x-prop / iana-prop
                  ;

Notes:

As per the definition of 'RESOURCES' in section 3.8.1.10,:

Conformance: This property can be specified once in "VEVENT" or
"VTODO" calendar component.

The text in the "VEVENT" definition has RESOURCES in the 'Option and MAY occur more than once.' section. The corrected text above corrects both sections;

1/ It is removed from the 'OPTIONAL/MAY occure more than once section.
2/ It is placed at the end of the 'OPTIONAL/MUST NOT occur more than once section.
--VERIFIER NOTES--
The correct fix is listed in Erratum 2677 which was approved.

Errata ID: 3405
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Hermann
Date Reported: 2012-11-09
Rejected by: Barry Leiba
Date Rejected: 2012-11-09

Section 3.3.10. says:

       weekday     = "SU" / "MO" / "TU" / "WE" / "TH" / "FR" / "SA"
       ;Corresponding to SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY,
       ;FRIDAY, and SATURDAY days of the week.

It should say:

       weekday     = "MO" / "TU" / "WE" / "TH" / "FR" / "SA" / "SU"
       ;Corresponding to MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY,
       ;SATURDAY, and SUNDAY days of the week.

Notes:

It is worldwide accepted that a working business week begins with
a monday in all business related activities (stock exchange etc. etc).

See also:
package Ada.Calendar.Formatting is
-- Day of the week:
type Day_Name is (Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday);
--VERIFIER NOTES--
This isn't an error in the document. Regardless of your opinion of whether the week should begin on Sunday, Monday, or Thursday, ABNF does not create any particular ordering. Implementations are always free to order them as they please.

Errata ID: 4606
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Harald Lampke
Date Reported: 2016-01-27
Rejected by: Barry Leiba
Date Rejected: 2016-01-27

Section 3.8.8.3 says:

       rstatus    = "REQUEST-STATUS" rstatparam ":"
                    statcode ";" statdesc [";" extdata]

It should say:

       rstatus    = "REQUEST-STATUS" statcode ":"
                    rstatparam ";" statdesc [";" extdata]

Notes:

'rstatparam' and 'statcode' are interchanged.
--VERIFIER NOTES--
The original text is correct: "rstatparam" defines the set of allowed *parameters* on the "REQUEST-STATUS" property. Parameters always occur immediately after the property name and before the ":" that separates the property value. The property *value* is a semicolon-separated structured text field with the first component being "statcode", and appears after the ":".

Errata ID: 5082
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: George Sexton
Date Reported: 2017-08-10
Rejected by: Francesca Palombini
Date Rejected: 2024-01-16

Section 3.8.7.3 says:

N/A

It should say:

The value must not be in the future.

Notes:

If future values are allowed for LAST-MODIFIED, it makes it very difficult for software to perform change management for a VEVENT.

Say for example, an event is imported from a source and the VEVENT has a future date. For example, December 20 2017 12:00:00Z

That event is then edited and assigned the actual correct date and time. Say August 9 2017 13:45:44Z.

Software that examines the VEVENT's LAST-MODIFIED to determine if the VEVENT record has been modified will not see the VEVENT is updated.

In order for different systems to perform change management, the value for LAST-MODIFIED should NEVER be a future date.
--VERIFIER NOTES--
The description of the property already implies that it is not in the future. And any handling of clock skew is an iTIP/CalDAV protocol issue, NOT a data format issue.

See https://mailarchive.ietf.org/arch/msg/calsify/x82GopunVcEh8y5UGSIsEIC3s6M/

Errata ID: 5214
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Richard Smith
Date Reported: 2017-12-24
Rejected by: Francesca Palombini
Date Rejected: 2024-01-16

Section 3.6.5 says:

       timezonec  = "BEGIN" ":" "VTIMEZONE" CRLF
                    *(
                    ;
                    ; 'tzid' is REQUIRED, but MUST NOT occur more
                    ; than once.
                    ;
                    tzid /
                    ;
                    ; 'last-mod' and 'tzurl' are OPTIONAL,
                    ; but MUST NOT occur more than once.
                    ;
                    last-mod / tzurl /
                    ;
                    ; One of 'standardc' or 'daylightc' MUST occur
                    ; and each MAY occur more than once.
                    ;
                    standardc / daylightc /
                    ;
                    ; The following are OPTIONAL,
                    ; and MAY occur more than once.
                    ;
                    x-prop / iana-prop
                    ;
                    )
                    "END" ":" "VTIMEZONE" CRLF

It should say:

       timezonec    = "BEGIN" ":" "VTIMEZONE" CRLF
                      timezoneprop timezonesubc
                      "END" ":" "VTIMEZONE" CRLF

       timezoneprop = *(
                      ;
                      ; 'tzid' is REQUIRED, but MUST NOT occur more
                      ; than once.
                      ;
                      tzid /
                      ;
                      ; 'last-mod' and 'tzurl' are OPTIONAL,
                      ; but MUST NOT occur more than once.
                      ;
                      last-mod / tzurl /
                      ;
                      ; The following are OPTIONAL,
                      ; and MAY occur more than once.
                      ;
                      x-prop / iana-prop
                      ;

       timezonesubc = *(
                      ;
                      ; One of 'standardc' or 'daylightc' MUST occur
                      ; and each MAY occur more than once.
                      ;
                      standardc / daylightc
                      ;
                      )

Notes:

The definition of icalbody shows that calendar properties precede components. Some components may contains sub-components. For those that may:

The definition of eventc (section 3.6.1 - Event Component) also shows that properties precede sub-components.

The definition of todoc (section 3.6.2 - To-Do Component) also shows that properties precede sub-components.

However, the definition of timezonec (section 3.6.5 - Time Zone Component) shows that properties and sub-components may be intermingled. The corrected text assumes this was not intended.
--VERIFIER NOTES--
The current ABNF doesn't appear to cause any interop problems, given that both ical4j and libical don't care about the order of properties and components within a VTIMEZONE component.

See https://mailarchive.ietf.org/arch/msg/calsify/x82GopunVcEh8y5UGSIsEIC3s6M/

Errata ID: 5215
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Richard Smith
Date Reported: 2017-12-24
Rejected by: Francesca Palombini
Date Rejected: 2024-01-16

Section 3.8.5.1 says:

   Purpose:  This property defines the list of DATE-TIME exceptions for
   recurring events, to-dos, journal entries, or time zone
   definitions.

...

   Conformance:  This property can be specified in recurring "VEVENT",
   "VTODO", and "VJOURNAL" calendar components as well as in the
   "STANDARD" and "DAYLIGHT" sub-components of the "VTIMEZONE"
   calendar component.

It should say:

   Purpose:  This property defines the list of DATE-TIME exceptions for
   recurring events, to-dos or journal entries.

...

   Conformance:  This property can be specified in recurring "VEVENT",
   "VTODO", and "VJOURNAL" calendar components.

Notes:

Section 3.8.5.1 describes Exception Date-Times (EXDATE).

tzprop (section 3.6.5) does not allow EXDATE.

(Of course, the problem could be that 3.6.5 should include EXDATE.)
--VERIFIER NOTES--
Excluding EXDATE from tzprop is the actual error and is worthy of a new errata.

See https://mailarchive.ietf.org/arch/msg/calsify/x82GopunVcEh8y5UGSIsEIC3s6M/

Errata ID: 5872
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Lars Henriksen
Date Reported: 2019-10-10
Rejected by: Alexey Melnikov
Date Rejected: 2020-03-25

Section 3.8.5.3 says:

Weekly on Tuesday and Thursday for five weeks:

       DTSTART;TZID=America/New_York:19970902T090000
       RRULE:FREQ=WEEKLY;UNTIL=19971007T000000Z;WKST=SU;BYDAY=TU,TH

It should say:

Weekly on Tuesday and Thursday for five weeks:

       DTSTART;TZID=America/New_York:19970902T090000
       RRULE:FREQ=WEEKLY;UNTIL=19971002T000000Z;WKST=SU;BYDAY=TU,TH

Notes:

The UNTIL rule is inclusive, and October 7, a Tuesday, should not be included.
--VERIFIER NOTES--
Neil Jenkins wrote: This erratum is invalid. The original example, while slightly weird, is correct as is. The event's DTSTART time is 09:00 New York TIme, and the UNTIL time is 00:00 UTC, which is before this. Therefore you would not get a recurrence on the 7 Oct with this rule and so it would produce 10 occurrences, as specified. The "corrected text" is in fact invalid, as this would remove the 2nd Oct occurrence.

Errata ID: 5920
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Lars Henriksen
Date Reported: 2019-11-26
Rejected by: Francesca Palombini
Date Rejected: 2024-01-16

Section 3.8.5.3 says:

Every Friday the 13th, forever:

       DTSTART;TZID=America/New_York:19970902T090000
       EXDATE;TZID=America/New_York:19970902T090000
       RRULE:FREQ=MONTHLY;BYDAY=FR;BYMONTHDAY=13

       ==> (1998 9:00 AM EST) February 13;March 13;November 13
           (1999 9:00 AM EDT) August 13
           (2000 9:00 AM EDT) October 13
           ...

It should say:

Every Friday the 13th, forever:

       DTSTART;TZID=America/New_York:19980213T090000
       RRULE:FREQ=MONTHLY;BYDAY=FR;BYMONTHDAY=13

       ==> (1998 9:00 AM EST) February 13;March 13;November 13
           (1999 9:00 AM EDT) August 13
           (2000 9:00 AM EDT) October 13
           ...

Notes:

The "DTSTART" property is not synchronized with the recurrence rule.

Although it may be removed from the recurrence set by an "EXDATE" property, the description at the start of section 3.8.5.3 leaves no doubt that the "DTSTART" property should still be synchronized with the recurrence rule.
--VERIFIER NOTES--
Rejected since it changes the intent of the example (showing exclusion the first instance). The example should be something like the following (possibly to be reported in a new errata):

DTSTART;TZID=America/New_York:19970613T090000
EXDATE;TZID=America/New_York:19970613T090000

See https://mailarchive.ietf.org/arch/msg/calsify/x82GopunVcEh8y5UGSIsEIC3s6M/

Errata ID: 6212
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Lars Henriksen
Date Reported: 2020-06-23
Rejected by: Francesca Palombini
Date Rejected: 2024-01-16

Section 3.8.5.3 says:

      Daily until December 24, 1997:

       DTSTART;TZID=America/New_York:19970902T090000
       RRULE:FREQ=DAILY;UNTIL=19971224T000000Z

       ==> (1997 9:00 AM EDT) September 2-30;October 1-25
           (1997 9:00 AM EST) October 26-31;November 1-30;December 1-23

It should say:

      Daily until December 24, 1997:

       DTSTART;TZID=America/New_York:19970902T090000
       RRULE:FREQ=DAILY;UNTIL=19971224T140000Z
                                       ^^
       ==> (1997 9:00 AM EDT) September 2-30;October 1-25
           (1997 9:00 AM EST) October 26-31;November 1-30;December 1-24
                                                                     ^^

Notes:

The UNTIL rule part has value type DATE-TIME (same as DTSTART), but the introductory text "Daily until December 24, 1997" mentions a DATE only. Assuming that "until", like UNTIL, is inclusive, I would expect

(1997 9:00 AM EST) December 24

to be the last instance, i.e. the unstated time is 9:00 AM. Translating to UTC you get

19971224T140000Z

The same error occurs in all examples of section 3.8.5.3 with "December 24, 1997", four in all: pages 123 (above), 125 (twice) and 126. The resulting occurrences are only affected for pages 123 and 125 (second).
--VERIFIER NOTES--
The example is correct as-is. UNTIL does not have to match the recurrence pattern.

See https://mailarchive.ietf.org/arch/msg/calsify/x82GopunVcEh8y5UGSIsEIC3s6M/

Errata ID: 3457
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Johannes Raggam
Date Reported: 2013-01-16
Rejected by: Barry Leiba
Date Rejected: 2013-01-16

Section 3.2 says:

Property parameter values that contain the COLON, SEMICOLON, or COMMA
character separators MUST be specified as quoted-string text values.

It should say:

Property parameter values that contain the COLON, SEMICOLON, COMMA or
SPACE character separators MUST be specified as quoted-string text
values.

Notes:

Section "3.2.2. Common Name" gives an example with an double-quoted parameter value with a SPACE in it:

ORGANIZER;CN="John Smith":mailto:jsmith@example.com
--VERIFIER NOTES--
That example also shows a double-quoted parameter value with a "J" in it, but that doesn't mean that values that contain "J" MUST be quoted. Examples are just examples, and any value MAY be quoted.

The ABNF is the definitive source. The ABNF at the bottom of page 10 and top of page 11 (Section 3.1) says that non-quoted values may contain any number of characters from the SAFE-CHAR set, and that set includes WSP (SP and HTAB; see RFC 5234). Quoting is not required on account of space characters.

Errata ID: 4150
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Peter Bachman
Date Reported: 2014-11-03
Rejected by: Barry Leiba
Date Rejected: 2014-11-04

Section 10.2 says:

[TZDB]                 Eggert, P. and A.D. Olson, "Sources for Time
                          Zone and Daylight Saving Time Data",
                          July 2009,
                          <http://www.twinsun.com/tz/tz-link.htm>.

It should say:

[TZDB]       Eggert, P. and A. Olson, "Sources for Time Zone and
                Daylight Saving Time Data", 1987,
                <ftp://ftp.iana.org/tz/code/tz-link.htm>.

              Internet Assigned Numbers Authority (IANA)
              "Time Zone Database"
                <http://www.iana.org/time-zones>.

Notes:

The twinsun.com version is no longer maintained by the volunteer(s) tz@elsie.nci.nih.gov. The document and the tz database, have been adopted by members of IETF and iana.org. The database itself is public domain.

The corrected text matches that of rfc6557 11.1. Normative References [TZDB]



http://tools.ietf.org/html/rfc6557
http://www.iana.org/time-zones/repository/tz-link.html
http://www.iana.org/time-zones
--VERIFIER NOTES--
The document was correct at the time it was published, so this report does not meet the formal criteria for errata.

That said, Peter is correct that the location of the time zone database has since changed, and readers should look to the new location, as he has specified in this report.

RFC 5546, "iCalendar Transport-Independent Interoperability Protocol (iTIP)", December 2009

Note: This RFC has been updated by RFC 6638

Source of RFC: calsify (app)

Errata ID: 3037
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Praveen Bhamidipati
Date Reported: 2011-11-30
Rejected by: Peter Saint-Andre
Date Rejected: 2011-11-30

Section 3.1.3 says:

   |   DURATION         | 0 or 1   | If present, REPEAT MUST be        |
   |                    |          | present.                          |
   |   REPEAT           | 0 or 1   | If present, DURATION MUST be      |
   |                    |          | present.                          |

It should say:

   |   DURATION         | 0 or 1   | If present, DURATION MUST be      |
   |                    |          | present.                          |
   |   REPEAT           | 0 or 1   | If present, REPEAT MUST be        |
   |                    |          | present.                          |

Notes:

Currently, the Component/Property doesn't match the term used in Comment. That needs to be corrected.
--VERIFIER NOTES--
Per discussion on the ietf-calsify list, this report simply misunderstands the intent of the document and is clearly false.

RFC 5549, "Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop", May 2009

Note: This RFC has been obsoleted by RFC 8950

Source of RFC: softwire (int)

Errata ID: 6786
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Mike Dubrovsky
Date Reported: 2021-12-17
Rejected by: Éric Vyncke
Date Rejected: 2023-08-02

Section 4 says:

   A BGP speaker MUST only advertise to a BGP peer the IPv4 or VPN-IPv4
   NLRI with an IPv6 Next Hop if the BGP speaker has first ascertained
   via BGP Capability Advertisement that the BGP peer supports the
   Extended Next Hop Encoding capability for the relevant AFI/SAFI pair.

It should say:

   A BGP speaker MUST only advertise to a BGP peer the IPv4 or VPN-IPv4
   NLRI with an IPv6 Next Hop if the BGP speaker has first ascertained
   via BGP Capability Advertisement that the BGP peer supports the
   Extended Next Hop Encoding capability for the relevant AFI/SAFI pair.
   
   IPv4 or VPN-IPv4 NLRI with an IPv6 Next Hop SHOULD be treated as 
   malformed if it received from a BGP speaker that has not sent BGP 
   Capability Advertisement for the relevant AFI/SAFI pair.   

Notes:

The behavior was not explicitly mentioned.
--VERIFIER NOTES--
The RFC 5549 has been obsoleted by RFC 8950. Per point 7 of https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/, this errata is rejected.
It appears to me that RFC 8950 may have the same error and may also require a similar errata.
Thanks for the report.

RFC 5557, "Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization", July 2009

Source of RFC: pce (rtg)

Errata ID: 3672
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Cyril Margaria
Date Reported: 2013-06-27
Rejected by: Adrian Farrel
Date Rejected: 2013-10-04

Section 5 says:

   The <svec-list> is changed as follows:

   <svec-list> ::= <SVEC>
                   [<OF>]
                   [<GC>]
                   [<XRO>]
                   [<svec-list>]

It should say:

   The <svec-list> is changed as follows:

   <svec-list> ::= <SVEC>
                   [<OF>]
                   [<GC>]
                   [<XRO>]
                   [<metric-list>]
                   [<svec-list>]

Notes:

RFC5440 defines <svec-list>::=<SVEC>[<svec-list>]
RFC5541 extend <svec-list> as follows:
<svec-list> ::= <SVEC>
[<OF>]
[<metric-list>]
[<svec-list>]

RFC5557 should include all the elements defined by the RFCs its extending.
The position of the metric-list may be kept after the [<OF>]
--VERIFIER NOTES--
The essence of his report is that message definitions in RFCs should include all
elements of RBNF from the messages as defined in previous RFCs.

Discussion of this point in the PCE working group led to a debate about
whether the RBNF is normative and should be "compilable". Some hold the
view that being conservative in what you send and liberal in what you
receive could only make this text normative for building messages not
parsing them. Others noted that, as with RSVP, the object ordering is
advisory not mandatory except as where noted explicitly in the text.

It is also worth noting that as various documents are developed in parallel,
getting the RBNF right in the RFCs might require last-minute edits in Auth48
which is undesirable for a host of reasons. Others observed that there is no
expectation that authors will read RFC in numeric order and that the RBNF for a
new feature in PCEP applies to how that feature is added.

All this led to http://datatracker.ietf.org/doc/draft-cmfg-pce-pcep-grammar/
which is an experiment to determine whether it is possible to derive an
aggregated RBNF description for all PCEP messages. This might (if successful) go
on to form a type of message registry to act as a stable reference point.

In rejecting this Errata report I note that the reported error is not a typo,
but a deliberate decision of the authors and working group. The fix, therefore,
if it is to be applied needs to be achieved through a consensus document.

RFC 5586, "MPLS Generic Associated Channel", June 2009

Note: This RFC has been updated by RFC 6423, RFC 7026, RFC 7214, RFC 7274

Source of RFC: mpls (rtg)

Errata ID: 4364
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexander ("Sasha") Vainshtein
Date Reported: 2015-05-12
Rejected by: Deborah Brungard
Date Rejected: 2015-05-18

Section 4.2.1 says:

   The Time-To-Live (TTL) field of the LSE that contains the GAL follows
   the definition and processing rules specified in [RFC3443].

It should say:

The value of the  Time-To-Live (TTL) field of the LSE that contains the 
GAL follows is irrelevant as long as it exceeds 1. (Setting this value 
to 0 or 1 SHOULD be avoided because it could result in trapping the OAM 
packets in with wrong reason: "TTL expiration" instead of "GAL  
encountered").  

Notes:

The processing rules specific in RFC 3443 deal with handling TTL in the LSE of a labeled packets that are forwarded based on this LSE, or with setting the TTL value by a LER pushing a label stack on an unlabeled packet.
As per the last para in Section 4.2, LSRs and LERs MUST NOT forward packets based on the LSE that contains GAL, hence these rules are mainly not applicable.
--VERIFIER NOTES--
This proposes a change to the RFC which needs to be agreed via working group consensus.

RFC 5601, "Pseudowire (PW) Management Information Base (MIB)", July 2009

Source of RFC: pwe3 (int)

Errata ID: 1860
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-09
Rejected by: Stewart Bryant
Date Rejected: 2011-11-12

Section 12, pg.26 says:

a) [[ 2nd para of DESCRIPTION clause for pwOutboundLabel OBJECT-TYPE: ]]

          For MPLS, MPLS over IP, or MPLS over Generic Routing
          Encapsulation (GRE) PSN, it represents the 20-bit PW tag;
          for L2TP, it represents the 32-bit Session ID; and for
|         IP PSN, it represents the destination UDP port number.

b) [[ 2nd para of DESCRIPTION clause for pwInboundLabel OBJECT-TYPE: ]]

          For MPLS, MPLS over IP, or MPLS over GRE PSN, it represents
          the 20-bit PW tag; for L2TP, it represents the 32-bit
|         Session ID; and for IP PSN, it represents the source
          UDP port number.

It should say:

a)
          For MPLS, MPLS over IP, or MPLS over Generic Routing
          Encapsulation (GRE) PSN, it represents the 20-bit PW tag;
          for L2TP, it represents the 32-bit Session ID; and for
|         IP PSN, it represents the remote UDP port number.

b)
          For MPLS, MPLS over IP, or MPLS over GRE PSN, it represents
          the 20-bit PW tag; for L2TP, it represents the 32-bit
|         Session ID; and for IP PSN, it represents the local
          UDP port number.

Notes:

Rationale:

Confusion of terms; the role of source vs. destination port number
changes with the direction in which the packets are sent, whereas
the role of local vs. remote port number is static (from the point
of view of each peer) and as such can be configured here.
The necessary clarification substitutes the proper terms for the
inappropriate ones.



--VERIFIER NOTES--
The original text is clear and correct.

Errata ID: 1864
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-09
Rejected by: Stewart Bryant
Date Rejected: 2012-02-21

Section 12, pg.40 says:

[[ 2nd para of DESCRIPTION clause for pwIndexMappingEntry OBJECT-TYPE: ]]

           Implementers need to be aware that if the value of
|          the pwIndexMappingPeerAddr (an OID) has more than
|          113 sub-identifiers, then OIDs of column instances
           in this table will have more than 128 sub-identifiers
           and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3."

It should say:

           Implementers need to be aware that if the value of
|          the pwIndexMappingPeerAddr corresponds to more than
|          113 sub-identifiers, then OIDs of column instances
           in this table will have more than 128 sub-identifiers
           and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3."

Notes:

Rationale: Clarification of potentially misleading text:
pwIndexMappingPeerAddr is *not* an OID by itself, it is
transformed into an OID when used as an index in the SMI.
An alternate replacement text might be:

Implementers need to be aware that if the value of
| the pwIndexMappingPeerAddr has a size of more than
| 112 octets, then OIDs of column instances
in this table will have more than 128 sub-identifiers
and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3."
--VERIFIER NOTES--
The original text is correct and easily understood by a MIB experts.

Errata ID: 1866
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-09
Rejected by: Stewart Bryant
Date Rejected: 2012-02-21

Section 12, pg.42 says:

[[ 2nd para of DESCRIPTION clause for pwPeerMappingEntry OBJECT-TYPE: ]]

          Implementers need to be aware that if the value of the
|         pwPeerMappingPeerAddr (an OID) has more than 113
          sub-identifiers, then OIDs of column instances in this
          table will have more than 128 sub-identifiers and cannot
          be accessed using SNMPv1, SNMPv2c, or SNMPv3."

It should say:

          Implementers need to be aware that if the value of the
|         pwPeerMappingPeerAddr corresponds to more than 113
          sub-identifiers, then OIDs of column instances in this
          table will have more than 128 sub-identifiers and cannot
          be accessed using SNMPv1, SNMPv2c, or SNMPv3."

Notes:

Rationale:
pwPeerMappingPeerAddr is an OCTET STRING, not an OID;
cf. EID=1864.
--VERIFIER NOTES--
The original text is correct and easily understood by a MIB experts.

Errata ID: 1871
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-09
Rejected by: Stewart Bryant
Date Rejected: 2012-02-21

Section 12, pg.45 says:

[[ 2nd para of DESCRIPTION clause for pwGenFecIndexMappingEntry OBJECT-TYPE: ]]

           Implementers need to be aware that if the combined value
           of pwGenFecIndexMappingAGI, pwGenFecIndexMappingLocalAII,
|          and pwGenFecIndexMappingRemoteAII (OIDs) has more than
|          113 sub-identifiers, then OIDs of column instances
           in this table will have more than 128 sub-identifiers
           and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3."

It should say:

           Implementers need to be aware that if the combined value
           of pwGenFecIndexMappingAGI, pwGenFecIndexMappingLocalAII,
|          and pwGenFecIndexMappingRemoteAII corresponds to more
|          than 113 sub-identifiers, then OIDs of column instances
           in this table will have more than 128 sub-identifiers
           and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3."

Notes:

Rationale (cf. EID=1864 and EID=1866):
These objects conceptually are not OIDs; they become mapped to
relative OIDs when used as INDEX variables. The corrected text
attempts this clarification with minimal textual footprint.
--VERIFIER NOTES--
The original text is correct and easily understood by a MIB experts.

Errata ID: 1872
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-09
Rejected by: Stewart Bryant
Date Rejected: 2011-08-03

Section 12, pg.46 says:

a)  [[ DESCRIPTION clause for pwGenFecIndexMappingLocalAII OBJECT-TYPE ]]

          "This object is an octet string representing the local
           forwarder attachment individual identifier (AII) to be used
           by this PW.  It is used as the SAII for outgoing signaling
|          messages and the TAII in the incoming messages from the
           peer."

b)  [[ DESCRIPTION clause for pwGenFecIndexMappingRemoteAII OBJECT-TYPE ]]

          "This object is an octet string representing the peer
           forwarder attachment individual identifier (AII) to be used
           by this PW.  It is used as the TAII for outgoing signaling
|          messages and the SAII in the incoming messages from the
           peer."

It should say:

a)
          "This object is an octet string representing the local
           forwarder attachment individual identifier (AII) to be used
           by this PW.  It is used as the SAII for outgoing signaling
|          messages and expected as the TAII in the incoming messages
           from the peer."

b)
          "This object is an octet string representing the peer
           forwarder attachment individual identifier (AII) to be used
           by this PW.  It is used as the TAII for outgoing signaling
|          messages and expected as the SAII in the incoming messages
           from the peer."

Notes:

Rationale: same as for EID=1858 !
--VERIFIER NOTES--
The original text looks clear

Errata ID: 1858
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-09
Rejected by: Stewart Bryant
Date Rejected: 2011-08-03

Section 12, pg.19/20 says:

a)  [[ DESCRIPTION clause for pwLocalAttachmentID OBJECT-TYPE,
       at the bottom of page 19: ]]

         "This object is an octet string representing the local
          forwarder attachment individual identifier (AII) to be
          used by this PW.  It is used as the Source AII (SAII) for
|         outgoing signaling messages and the Target AII (TAII) in
          the incoming messages from the peer.  Applicable if
          pwOwner equal 'genFecSignaling'."


b)  [[ DESCRIPTION clause for pwRemoteAttachmentID OBJECT-TYPE,
       on top of page 20: ]]
 
         "This object is an octet string representing the remote
          forwarder attachment individual identifier (AII) to be
          used by this PW.  It is used as the TAII for outgoing
|         signaling messages and the SAII in the incoming messages
          from the peer.
          Applicable if pwOwner equals 'genFecSignaling'."

It should say:

a)
         "This object is an octet string representing the local
          forwarder attachment individual identifier (AII) to be
          used by this PW.  It is used as the Source AII (SAII) for
|         outgoing signaling messages and expected as the Target
          AII (TAII) in the incoming messages from the peer.
          Applicable if pwOwner equal 'genFecSignaling'."

b)
         "This object is an octet string representing the remote
          forwarder attachment individual identifier (AII) to be
          used by this PW.  It is used as the TAII for outgoing
|         signaling messages and expected as the SAII in the
          incoming messages from the peer.
          Applicable if pwOwner equals 'genFecSignaling'."

Notes:

Rationale:
The phrase talking about "use" of a value in an incoming message
is potentially misleading. The insertion of "expected as" should
cure the issue, with minimal footprint.
--VERIFIER NOTES--
The original text clearly states the use of the object.

RFC 5623, "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering", September 2009

Source of RFC: pce (rtg)

Errata ID: 1897
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-30
Rejected by: Adrian Farrel
Date Rejected: 2009-11-07

Section 4.1, says:

a) Section 4.1, 2nd paragraph (bottom of page 10):

   A VNT Manager (VNTM) is defined as a functional element that manages
   and controls the VNT.  The PCE and VNT Manager are distinct
|  functional elements that may or may not be collocated.
                                                ^^

b) Section 4.2.4, trailing Note below Table 1 (on page 22):

   * Note that, in case of NSM-VNTM cooperation (separate flavor) and
     single PCE inter-layer path computation, the PCE function used by
|    NMS and VNTM may be collocated, but it will operate on separate
     TEDs.
                           ^^

It should say:

a)

   A VNT Manager (VNTM) is defined as a functional element that manages
   and controls the VNT.  The PCE and VNT Manager are distinct
|  functional elements that may or may not be co-located.

b)

   * Note that, in case of NSM-VNTM cooperation (separate flavor) and
     single PCE inter-layer path computation, the PCE function used by
|    NMS and VNTM may be co-located, but it will operate on separate
     TEDs.
 

Notes:

Rationale:
"collocated" and "co-located" (or "colocated") have very different
semantics! The latter seems to be the appropriate choice: two
logical entites (or subsystems) are located within the same system.
The former means "arranged/placed/sorted *somehow*, in the proper
way", without emphasis on neighborship or common enclosement.
--VERIFIER NOTES--
Email discussions with the RFC Editor yielded the following answer that appears to set the editorial standard for this word within RFCs going forward.

According to this text, the RFC is correct.
----
This particular word is accepted in many forms. Historically, we have
defaulted to co-located when spelled inconsistently within a document.
However, we do not apply this uniformly across the series because
there are so many accepted forms of the word. For example:

Webster's Dictionary has entries for colocate (1965) and
collocate (1513), but there is no entry for co-locate.

Webopeida only recognizes co-location.

Wikipedia lists

Colocation/collocation may refer to:

* Colocation (business), the placement of several entities in a
single location.
* The provision of computing services in a third-party colocation
centre.
* Collocation, in corpus linguistics, a sequence of words that
often occur together.
* Collocation method, used in maths to solve differential and
integral equations.

Additionally, the topic is discussed with no clear answer. For
example, see
http://www.webhostingtalk.com/archive/index.php/t-17495.html.

Our editor looked up "collocation" in Webster's, and believed that it
was correct, as it is defined as:

to set or arrange in a place or position; especially : to set side
by side

If we notice multiple spellings within a document, we tend to default
to "co-locate", but if the document consistently uses "collocation" or
"colocation", we do not change the spelling.

RFC 5632, "Comcast's ISP Experiences in a Proactive Network Provider Participation for P2P (P4P) Technical Trial", September 2009

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 1949
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-11-26
Rejected by: Lisa Dusseault
Date Rejected: 2009-12-01

Section 9 says:

   [SIGCOMM]  Xie, H., Yang, Y., Krishnamurthy, A., Liu, Y., and A.
              Silberschatz, "ACM SIGCOMM 2008 - P4P: Provider Portal for
|             Applications", Association for Computing Machinery SIGCOMM
              2008 Proceedings, August 2008, [..]

It should say:

   [SIGCOMM]  Xie, H., Yang, Y., Krishnamurthy, A., Liu, Y., and A.
              Silberschatz, "ACM SIGCOMM 2008 - P4P: Provider Portal for
|             Peer-to-Peer Applications", Association for Computing
|             Machinery, SIGCOMM 2008 Proceedings, August 2008, [..]

Notes:

Rationale: word omission.
--VERIFIER NOTES--
The authors checked the published title and confirmed it.

RFC 5652, "Cryptographic Message Syntax (CMS)", September 2009

Note: This RFC has been updated by RFC 8933

Source of RFC: smime (sec)

Errata ID: 5331
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Thomas Stimm
Date Reported: 2018-04-23
Rejected by: Eric Rescorla
Date Rejected: 2018-04-27

Section 6.1 and 8 says:

EncryptedData ::= SEQUENCE {
   version CMSVersion,
   encryptedContentInfo EncryptedContentInfo,
   unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }

EncryptedContentInfo ::= SEQUENCE {
   contentType ContentType,
   contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
   encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL }

It should say:

EncryptedData ::= SEQUENCE {
   version CMSVersion,
   encryptedContentInfo EncryptedContentInfo,
   encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL,
   unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }

EncryptedContentInfo ::= SEQUENCE {
   contentType ContentType,
   contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier }

Notes:

- Wrong enumeration of UnprotectedAttributes OPTIONAL [1] instead of [0].
- ‘UnprotectedAttributes OPTIONAL’ makes only sense, if ‘EncryptedContent OPTIONAL’ is available.
- It seems that OpenSSL and wolfSSL are using the suggested wrapping and are not following the RFC, here.
--VERIFIER NOTES--
Misunderstanding of the specification

RFC 5654, "Requirements of an MPLS Transport Profile", September 2009

Source of RFC: mpls (rtg)

Errata ID: 1953
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Zongpeng Du
Date Reported: 2009-12-02
Rejected by: Adrian Farrel
Date Rejected: 2009-12-03

Section 1 says:

Investment in equipment and facilities (Capital Expenditure
   (CAPEX)) and Operational Expenditure (OPEX) should be minimized.

It should say:

Investment in equipment and facilities (Capital Expenditure
   (CAPEX) and Operational Expenditure (OPEX) should be minimized.

Notes:

An unnecessary parenthesis.
--VERIFIER NOTES--
Orriginal is correct.

RFC 5655, "Specification of the IP Flow Information Export (IPFIX) File Format", October 2009

Source of RFC: ipfix (ops)

Errata ID: 1989
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-28
Rejected by: Dan Romascanu
Date Rejected: 2010-05-11

Section 10, pg. 39 says:

   [...]
|  IPFIX Templates tend to increase the information content per record
   by not requiring the export of irrelevant or non-present fields in
   records, and the technique described in [RFC5473] also reduces the
   export of redundant information.  [...]

It should say:

   [...]
|  IPFIX Templates tend to decrease the information content per record
   by not requiring the export of irrelevant or non-present fields in
   records, and the technique described in [RFC5473] also reduces the
   export of redundant information.  [...]

Notes:

Rationale: arguably s/increase/decrease/ .
--VERIFIER NOTES--
The text seems to be correct. Usage of templates increases efficiency by increasing the amount of information carried by a record.

Errata ID: 4308
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2015-03-19
Rejected by: Benoit Claise
Date Rejected: 2015-04-21

Section A.5 says:

A.5.  Complete File Example

   Bringing together the examples above and adding message headers as
   appropriate, a hex dump of the first 317 bytes of the example File
   constructed above would appear as in the annotated Figure 10 below.

It should say:

A.5.  Complete File Example

   Bringing together the examples above and adding message headers as
   appropriate, a hex dump of the first 285 bytes of the example File
   constructed above would appear as in the annotated Figure 10 below.

Notes:

s/317/285/

Figure 10 shows 18 lines of 16 octets each, less three octets in the final row.
(18 x 16 - 3) = 285 octets.

This can also be confirmed by the revised numbering in errata 2030 - though note that the dump is numbered from octet zero:

272: 80 02 00 50 06 00 00 46 50 00 00 00 41

Since the offset of the final octet ("41") is 284, the overall length must be 285.
--VERIFIER NOTES--
The errata 2030 has been updated to reflect this, as proposed by Paul Aitken.

RFC 5661, "Network File System (NFS) Version 4 Minor Version 1 Protocol", January 2010

Note: This RFC has been obsoleted by RFC 8881

Note: This RFC has been updated by RFC 8178, RFC 8434

Source of RFC: nfsv4 (wit)

Errata ID: 2751
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Ricardo Labiaga
Date Reported: 2011-03-21
Rejected by: Magnus Westerlund
Date Rejected: 2019-10-25

Throughout the document, when it says:

It should say:

12.5.4.1.  LAYOUTCOMMIT and change/time_modify
becomes
12.5.4.2.  LAYOUTCOMMIT and change/time_modify


12.5.4.2.  LAYOUTCOMMIT and size
becomes
12.5.4.3.  LAYOUTCOMMIT and size


12.5.4.3.  LAYOUTCOMMIT and layoutupdate
becomes
12.5.4.4.  LAYOUTCOMMIT and layoutupdate


Add new Section 
12.5.4.1 Implications of LAYOUTCOMMIT on file layouts
For file layouts, WRITEs to a Data Server that return a stable_how4 value of 
FILE_SYNC4 guarantee that data and file system metadata are on stable 
storage.  This means that a LAYOUTCOMMIT is not needed in order to make the 
data and metadata visible to the metadata server and other clients.

For file layouts, when WRITE to the data server returns UNSTABLE4 or 
DATA_SYNC4  and the NFL4_UFLG_COMMIT_THRU_MDS flag is set, the client MUST 
send the COMMIT to the metadata server.  A successful COMMIT to the metadata 
server guarantees that data and file system metadata are on stable storage.  
Therefore, any time that NFS4_UFLG_COMMIT_THRU_MDS is set, a LAYOUTCOMMIT (of 
the byte range specified by the layout) is not needed.

For file layouts, when NFL4_UFLG_COMMIT_THRU_MDS flag is not set, and WRITE or 
COMMIT to the data server return DATA_SYNC4, the client MUST send the 
LAYOUTCOMMIT to the metadata server in order to synchronize file metadata.  

The following table summarizes the rules when a LAYOUTCOMMIT is needed, and 
the effects of a COMMIT to a data server and metadata server.  

+------------+------------+------------+------------+----------+
| NFL4_UFLG_ | WRITE to   | Meaning of | Meaning    | LAYOUT   |
| COMMIT_    | DS returns | COMMIT to  | of COMMIT  | COMMIT   | 
| THRU_MDS   |            | DS         | to MDS     | required |            
+------------+------------+------------+------------+----------+
| Not Set    | UNSTABLE4  | DATA_SYNC4 | Nothing    | Yes      |
| Not Set    | DATA_SYNC4 | Nothing    | Nothing    | Yes      |
| Not Set    | FILE_SYNC4 | Nothing    | Nothing    | NO       |
| Set        | UNSTABLE4  | Nothing    | FILE_SYNC4 | NO       |
| Set        | DATA_SYNC4 | Nothing    | FILE_SYNC4 | NO       |
| Set        | FILE_SYNC4 | Nothing    | Nothing    | NO       |
+------------+------------+------------+------------+----------+

Note that a client can always demand FILE_SYNC4 or DATA_SYNC4 in WRITE's 
arguments.  Also note that specifying these stability levels may adversely 
impact performance.

If a LAYOUTCOMMIT is required, it should be sent before CLOSE to maintain 
close-to-open semantics.  If required, it should be sent before LOCKU, 
OPEN_DOWNGRADE, LAYOUTRETURN, and when the application issues fsync() [25].  
Again, if LAYOUTCOMMIT is required, it should be sent periodically to keep the 
file size and modification time synchronized.  This allows use cases like 
tail -f [56] which copies its input file to the standard output and updates 
the output as new lines become available in the input file.  It is up to the 
client implementation to determine how frequently LAYOUTCOMMIT is issued.  
Possible policies include every N'th COMMIT to a data server, every N'th unit 
of time, or after writing a stripe to a set of data servers.

Even if a required LAYOUTCOMMIT is not issued by the client, the data server 
and metadata servers have a set of responsibilities to fulfill in order to 
guarantee data consistency:
1) Data servers MUST commit data and synchronize modification and size 
attributes with the metadata server before a layout is revoked as described in 
section 12.5.4.
2) Data servers SHOULD commit data and synchronize modification and size 
attributes with the metadata server after the metadata server reboots.  In 
theory the client should commit the data, but this avoids the problem where 
both the client and metadata server crash at the same time.
3) The metadata server MAY periodically poll data servers to synchronize 
modification and size attributes.


Section 13.9.2.3 says:
   For the NFSv4.1-based data storage protocol, it is  necessary to re-
synchronize state such as the size attribute, and  the setting of 
mtime/change/atime.

Should say:
   For the NFSv4.1-based data storage protocol, it may be necessary to re-
synchronize state such as the size attribute, and the setting of 
mtime/change/atime.


Section 13.10 says:
   For the case above, this means that a LAYOUTCOMMIT will be done at close 
(along with the data WRITEs) and will update the file's size and change 
attribute.

Should say:
   For the case above, this means that, if necessary, a LAYOUTCOMMIT will be 
done at close (along with the data WRITEs) and will update the file's size and 
change attribute.


Section 18.3.4 says:
   The COMMIT operation is similar in operation and semantics to the POSIX 
fsync() [25] system interface that synchronizes a file's state with the disk 
(file data and metadata is flushed to disk or stable storage).  COMMIT 
performs the same operation for a client, flushing any unsynchronized data and 
metadata on the server to the server's disk or stable storage for the 
specified file.

Should say:
   The COMMIT operation is similar in operation and semantics to the POSIX 
fsync() [25] system interface that synchronizes a file's state with the disk 
(file data and metadata is flushed to disk or stable storage).  COMMIT 
performs the same operation for a client, flushing any unsynchronized data and 
metadata on the server to the server's disk or stable storage for the 
specified file.  When using pNFS, if a WRITE returned UNSTABLE4 and 
NFL4_UFLG_COMMIT_THRU_MDS is not set, then the client MUST COMMIT to the data 
server.  The COMMIT may result in flushing the data but not the metadata.  In 
this case, the metadata MUST be flushed with a subsequent LAYOUTCOMMIT to the 
metadata server.  A complete set of pNFS rules for flushing data and metadata 
is described in section 12.5.4.1.


Section 18.3.4 says:
   The above description applies to page-cache-based systems as well as buffer-
cache-based systems.  In the former systems, the virtual memory system will 
need to be modified instead of the buffer cache.

Should say:
   The above description applies to page-cache-based systems as well as buffer-
cache-based systems.  In the former systems, the virtual memory system will 
need to be modified instead of the buffer cache.

   Refer to Section 12.5.4.1 for a discussion of the effects of data stability 
levels on data servers or metadata servers.


Section 18.32.4 says:
   However, since it is possible for a WRITE to be done with a special 
stateid, the server needs to check for this case even though the client should 
have done an OPEN previously.

Should say:
   However, since it is possible for a WRITE to be done with a special 
stateid, the server needs to check for this case even though the client should 
have done an OPEN previously.

   Refer to Section 12.5.4.1 for a discussion of the effects of data stability 
levels on data servers or metadata servers.


Section 20.3.4 says:
   In the case of modified data being written while the layout is held, the 
client must use LAYOUTCOMMIT operations at the appropriate time; as required 
LAYOUTCOMMIT must be done before the LAYOUTRETURN.

Should say:
   In the case of modified data being written while the layout is held, the 
client may be required to use LAYOUTCOMMIT operations at the appropriate time; 
if LAYOUTCOMMIT is required, it must be done before the LAYOUTRETURN.


Add new informative reference to Section 23.2
[56] The Open Group, "section 'tail' of The Open Group Base Specifications 
Issue 6 IEEE Std 1003.1, 2004 Edition, HTML Version (www.opengroup.org), 
ISBN 1931624453, 2004.

Notes:

A new section describing the implications of LAYOUTCOMMIT on file layouts is
defined in this errata, along with updates to existing sections of the spec.
The technical details in this errata were agreed upon at the IETF Interim
Meeting in Sunnyvale, CA on Feb 18-19, 2011.
--VERIFIER NOTES--
This errata was rejected based on formal process grounds that Errata is not allowed to change the WG consensus at the time of publication, and also is very extensive. This issue do need to be addressed in an update to the RFC.

Errata ID: 5982
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: David Noveck
Date Reported: 2020-02-13
Rejected by: Magnus Westerlund
Date Rejected: 2020-09-03

Section 2.10.6.1.3.1 says:

   If a requester sent a Sequence operation with a slot ID and sequence
   ID that are in the reply cache but the replier detected that the
   retried request is not the same as the original request, including a
   retry that has different operations or different arguments in the
   operations from the original and a retry that uses a different
   principal in the RPC request's credential field that translates to a
   different user, then this is a false retry.  When the replier detects
   a false retry, it is permitted (but not always obligated) to return
   NFS4ERR_FALSE_RETRY in response to the Sequence operation when it
   detects a false retry.

It should say:

   If a requester sent a Sequence operation with a slot ID and sequence
   ID that are in the reply cache but the replier detected that the
   retried request is not the same as the original request, including a
   retry that was issued with a different XID or has different operations 
   or different arguments in the operations from the original and a retry 
   that uses a different principal in the RPC request's credential field 
   that translates to a different user, then this is a false retry.  When 
   the replier detects a false retry, it is permitted (but not always 
   obligated) to return NFS4ERR_FALSE_RETRY in response to the Sequence 
   operation when it detects a false retry

Notes:

The existing text can be read as requiring checksumming of all requests to foreclose the possibility of not noticing a false retry, which can result in data corruption. This can be a
significant performance consideraation in the processing of WRITE requests and could undercut the benefits of directly placing data to be written which is one of the impotant goals of RPC-over-RDMA.
--VERIFIER NOTES--
No consensus in the WG if this is just a correction. Thus rejecting the issue and may be brought for WG consenus discussion in the context of document update.

Errata ID: 2722
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ricardo Labiaga
Date Reported: 2011-02-15
Rejected by: Lars Eggert
Date Rejected: 2011-02-16

Section 15.2 says:

   | ILLEGAL              | NFS4ERR_BADXDR, NFS4ERR_OP_ILLEGAL         |
   | LAYOUTCOMMIT         | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED,     |

It should say:

   |                      | NFS4ERR_BADXDR, NFS4ERR_OP_ILLEGAL         |
   | LAYOUTCOMMIT         | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED,     |

Notes:

ILLEGAL is not an operation. The errors belong to GETFH, the previous operation listed.
--VERIFIER NOTES--
Submitter wishes to retract the errata.

RFC 5663, "Parallel NFS (pNFS) Block/Volume Layout", January 2010

Note: This RFC has been updated by RFC 6688

Source of RFC: nfsv4 (wit)

Errata ID: 4140
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christoph Hellwig
Date Reported: 2014-10-23
Rejected by: Martin Stiemerling
Date Rejected: 2016-02-02

Section 2.3.5 says:

   Block/volume class storage devices are not required to perform read
   and write operations atomically.  Overlapping concurrent read and
   write operations to the same data may cause the read to return a
   mixture of before-write and after-write data.  Overlapping write
   operations can be worse, as the result could be a mixture of data
   from the two write operations; data corruption can occur if the
   underlying storage is striped and the operations complete in
   different orders on different stripes.  When there are multiple
   clients who wish to access the same data, a pNFS server can avoid
   these conflicts by implementing a concurrency control policy of
   single writer XOR multiple readers.  This policy MUST be implemented
   when storage devices do not provide atomicity for concurrent
   read/write and write/write operations to the same data.

It should say:

   Block/volume class storage devices do not provide byte granularity
   access and can only perform read and write operations atomically at
   block granularity, and thus require read-modify-write cycles to write
   data smaller than the block size.  Overlapping concurrent read and
   write operations to the same data thus may cause the read to return
   a mixture of before-write and after-write data.  Additionally, data
   corruption can occur if the underlying storage is striped and the
   operations complete in different orders on different stripes.  When
   there are multiple clients who wish to access the same data, a pNFS
   server MUST avoid these conflicts by implementing a concurrency
   control policy of single writer XOR multiple readers for a given data
   region.

Notes:

No device classified as block device can support concurrent writes at arbitrary byte granularity, so reword the section to not confuse the reader. Also make it explicit that the reader XOR writer policy only applies to different clients, as existing client implementation require layouts not to be recalled due to their own LAYOUTGET operations. Note that fixing this on the client also isn't feasible as the block layout unfortunately decided to introduce it's own extent concept instead of using layouts to describe individual I/O mappings.
--VERIFIER NOTES--
David Black: " The new text effectively states that block I/O operations are always atomic at block granularity. That is not correct for all SCSI devices. The existing text suffices to warn implementers about what can go wrong here."

RFC 5681, "TCP Congestion Control", September 2009

Note: This RFC has been updated by RFC 9438

Source of RFC: tcpm (wit)

Errata ID: 2269
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2010-05-18
Rejected by: Lars Eggert
Date Rejected: 2010-05-20

Section 7 says:

   The description of fast retransmit and fast recovery has been
   clarified, and the use of Limited Transmit [RFC3042] is now
   recommended.

It should say:

   The description of fast retransmit and fast recovery has been
   clarified.

Notes:

Really using of Limited Transmit [RFC3042] is not recommended anywhere in RFC 5681.
--VERIFIER NOTES--
WG consensus is that this errata is incorrect.

Errata ID: 6233
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Charles Deng
Date Reported: 2020-07-20
Rejected by: Martin Duke
Date Rejected: 2020-07-21

Section 4.3 says:

Finally, after all loss in the given window of segments
has been successfully retransmitted, cwnd MUST be set to no more than
ssthresh and congestion avoidance MUST be used to further increase
cwnd.

It should say:

Finally, after all loss in the given window of segments
has been successfully retransmitted, cwnd MUST be set to no less than
ssthresh and congestion avoidance MUST be used to further increase
cwnd.

Notes:

if set cwnd no more than ssthresh, it will using slow start algorithm instead of congestion avoidance algorithm. so it should say "cwnd no less than ..." instead of "cwnd no more than ...".
--VERIFIER NOTES--
This would be a significant design change in TCP. The original text is as intended by the community.

RFC 5709, "OSPFv2 HMAC-SHA Cryptographic Authentication", October 2009

Note: This RFC has been updated by RFC 7474

Source of RFC: ospf (rtg)

Errata ID: 2989
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dai Wenjie (David Jet)
Date Reported: 2011-10-10
Rejected by: RFC Editor
Date Rejected: 2011-10-14

Section 3. says:

   With the additions in this document, the currently valid algorithms
   (including mode) for OSPFv2 Cryptographic Authentication include:

           Keyed-MD5               (defined in RFC 2328, Appendix D)

It should say:

   With the additions in this document, the currently valid algorithms
   (including mode) for OSPFv2 Cryptographic Authentication include:

           Keyed-MD5               (defined in RFC 2328, Appendix D)

Notes:

The link 'Appendix D' referenced is incorrect. It is now 'http://tools.ietf.org/html/rfc5709#appendix-D', and it should be 'http://tools.ietf.org/html/rfc2328#appendix-D'.
Pay attention to the difference of the numbers in links,please.

-- VERIFIER NOTES --
Errata are for the RFCs as available from rfc-editor.org.

RFC 5717, "Partial Lock Remote Procedure Call (RPC) for NETCONF", December 2009

Source of RFC: netconf (ops)

Errata ID: 2657
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: B Viswanath Reddy
Date Reported: 2010-12-02
Rejected by: Dan Romascanu
Date Rejected: 2011-03-09

Section Appendix C says:

Step 6 - Lock user Joe

   <nc:rpc
     xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
     xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0"
         message-id="104">
     <partial-lock>
       <select xmlns:usr="http://example.com/users">
|         /usr:top/usr:users/user[usr:name="Joe"]"
       </select>
     </partial-lock>
   </nc:rpc>

   The NETCONF server grants the partial lock.  The scope of this second
   lock includes only the <user> node with name Joe.  The lock protects
   all data below this particular <user> node.

   Step 7 - Receive lock

   <nc:rpc-reply
     xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
     xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0"
     message-id="104">
       <lock-id>2</lock-id>
       <locked-node xmlns:usr="http://example.com/users">
|           /usr:top/usr:users/user[usr:name="Joe"]"
       </locked-node>
   </nc:rpc-reply>

It should say:

Step 6 - Lock user Joe

   <nc:rpc
     xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
     xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0"
         message-id="104">
     <partial-lock>
       <select xmlns:usr="http://example.com/users">
|         /usr:top/usr:users/usr:user[usr:name="Joe"]"
       </select>
     </partial-lock>
   </nc:rpc>

   The NETCONF server grants the partial lock.  The scope of this second
   lock includes only the <user> node with name Joe.  The lock protects
   all data below this particular <user> node.

   Step 7 - Receive lock

   <nc:rpc-reply
     xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
     xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0"
     message-id="104">
       <lock-id>2</lock-id>
       <locked-node xmlns:usr="http://example.com/users">
|           /usr:top/usr:users/usr:user[usr:name="Joe"]"
       </locked-node>
   </nc:rpc-reply>

Notes:

The instance identifier /usr:top/usr:users/user[usr:name="Joe"]" must be replaced with /usr:top/usr:users/usr:user[usr:name="Joe"]"
--VERIFIER NOTES--
The solution for this errata is contained in errata #2746 proposed by Mehmet Ersue which is Verified.

RFC 5731, "Extensible Provisioning Protocol (EPP) Domain Name Mapping", August 2009

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: art

Errata ID: 4200
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2014-12-15
Rejected by: Barry Leiba
Date Rejected: 2014-12-17

Section 3.2.3 says:

 C:        <domain:curExpDate>2000-04-03</domain:curExpDate>

It should say:

 C:        <domain:curExpDate>2000-04-03Z</domain:curExpDate>

Notes:

The Z for UTC seems mandatory, per section 2.4 (in XML schema, it is optional http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#date ). Since <renew> is the only command with date (and not date-times), one may think dates are not forced to have a trailing Z but it is not mentioned in the RFC.

Detected by Kim-Minh Kaplan at AFNIC.
--VERIFIER NOTES--
The RFC could be clearer, but it is consistent that the "Z" is required in date-time but not on date only.

RFC 5751, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", January 2010

Note: This RFC has been obsoleted by RFC 8551

Source of RFC: smime (sec)

Errata ID: 2031
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Derek Edson
Date Reported: 2010-02-01
Rejected by: Tim Polk
Date Rejected: 2010-03-21

Section 3.4.3.2 says:

   The micalg parameter allows for one-pass processing when the
   signature is being verified.  The value of the micalg parameter is
   dependent on the message digest algorithm(s) used in the calculation
   of the Message Integrity Check.  If multiple message digest
   algorithms are used, they MUST be separated by commas per [MIME-
   SECURE].  The values to be placed in the micalg parameter SHOULD be
   from the following:

      Algorithm   Value Used

      MD5         md5
      SHA-1       sha-1
      SHA-224     sha-224
      SHA-256     sha-256
      SHA-384     sha-384
      SHA-512     sha-512
      Any other   (defined separately in algorithm profile or "unknown"
                   if not defined)

   (Historical note: some early implementations of S/MIME emitted and
   expected "rsa-md5", "rsa-sha1", and "sha1" for the micalg parameter.)
   Receiving agents SHOULD be able to recover gracefully from a micalg
   parameter value that they do not recognize.  Future names for this
   parameter will be consistent with the IANA "Hash Function Textual
   Names" registry.

Notes:

This revision creates a backward compatibility issue with S/MIME v2, S/MIME v3 and S/MIME v3.1 agents. In each of the previous (obsoleted) standards, they all refer to the micalg for SHA-1 as "sha1" and not "sha-1".

The historical note should mean that v3.2 agents will recognize "sha1" as emitted by earlier implementations, but these implementations are unlikely to recognize the micalg value of "sha-1" emitted by a v3.2 agent.

All previous standards state that receiving agents SHOULD be able to handle this situation gracefully, but when these agents fail to recognize a micalg value, they can no longer perform a "one-pass processing". Given that this parameter is "required", the most likely implication is that they will fail to verify the signature.

To ensure interoperability with clients supporting previous versions, the micalg for SHA-1 MUST remain as "sha1", and receiving agents SHOULD also accept "sha-1".

The micalg parameters values have always been defined as "SHOULD", but for interoperability they should be declared as "MUST".
--VERIFIER NOTES--
These changes were introduced for alignment with the names in the IANA "Hash Function Textual Names" registry. Given that the requirements is a SHOULD and the note explains the situation, I do not consider this text in error.

RFC 5765, "Security Issues and Solutions in Peer-to-Peer Systems for Realtime Communications", February 2010

Source of RFC: IRTF

Errata ID: 2512
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-09-07
Rejected by: Lars Eggert
Date Rejected: 2012-02-07

Section 1.1, pg. 6 says:

   The content of this document was partially derived from the article
   "Peer-to-peer Overlays for Real-Time Communication: Security Issues
|  and Solutions," published in IEEE Surveys & Tutorials, Vol. 11, No.
   1, and originally authored by Dhruv Chopra, Henning Schulzrinne,
   Enrico Marocco, and Emil Ivov.

It should say:

   The content of this document was partially derived from the article
   "Peer-to-peer Overlays for Real-Time Communication: Security Issues
|  and Solutions", published in IEEE Surveys & Tutorials, Vol. 11, No.
   1, and originally authored by Dhruv Chopra, Henning Schulzrinne,
   Enrico Marocco, and Emil Ivov.

Notes:

Rationale: Non-use of "rational quotation"; the comma is not part
of the title of the quoted article.

Note:
A general editing nit recurring numerous times throughout the RFC
is the inadvertent treatment of "et al." as the end of a sentence,
with _two_ space characters inserted after it; thus:

s/et al. /et al. /g !
--VERIFIER NOTES--
Rejected after IRSG discussion.

RFC 5766, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", April 2010

Note: This RFC has been obsoleted by RFC 8656

Note: This RFC has been updated by RFC 8155, RFC 8553

Source of RFC: behave (tsv)

Errata ID: 4933
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: shakeeb
Date Reported: 2017-02-15
Rejected by: Magnus Westerlund
Date Rejected: 2020-02-17

Section 17.3.3 says:

An attacker might attempt to disrupt service to other users of the
TURN server by sending Refresh requests or CreatePermission requests
that (through source address spoofing) appear to be coming from
another user of the TURN server.  TURN prevents this by requiring
that the credentials used in CreatePermission, Refresh, and
ChannelBind messages match those used to create the initial
allocation.  Thus, the fake requests from the attacker will be
rejected.

Notes:

When using short-term, credentials expire after a specific amount of time (such as 5
minutes) and clients get new credentials. The restriction imposed at section 17.3.3
prevents from refreshing allocation or permission using the new credentials.

This RFC approves RFC 5389. So one can use short-term credentials. But short-term credentials are useless if it can not be used to refresh allocation or permission.


The goal of 17.3.3 can be achieved by sending 438 with the new nonce.
--VERIFIER NOTES--
So TURN does not actually specify the usage of short-term credentials. It mandates support of long-term credentials as authentication mechanism. Also RFC 7635 (STUN for Third party Authorization) specifies how to handle expire of the access token. This is clearer in the replacement of RFC 5766 that will soon be published that specifies the following in Section 7.2:

If
the request is authenticated, the authentication MUST be done
either using the long-term credential mechanism of
[I-D.ietf-tram-stunbis] or the STUN Extension for Third-Party
Authorization [RFC7635] unless the client and server agree to
use another mechanism through some procedure outside the scope
of this document.

RFC 5789, "PATCH Method for HTTP", March 2010

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 3419
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Daniel Hardman
Date Reported: 2012-11-27
Rejected by: Barry Leiba
Date Rejected: 2012-11-27

Section 1 says:

A new method is necessary to improve interoperability and prevent
errors.  The PUT method is already defined to overwrite a resource
with a complete new body, and cannot be reused to do partial changes.
Otherwise, proxies and caches, and even clients and servers, may get
confused as to the result of the operation.

It should say:

A new method may be desirable (though it is not strictly necessary).
The PUT method is already defined to overwrite a resource or a subset
thereof (see RFC 2612 section 9.6), but the semantics of Content-Range
with PUT have been poorly understood and implemented by the community.
To avoid breaking existing proxies and caches that may be confused by PUT
with a partial update, PATCH seems like a better solution.

Notes:

Contrary to what is claimed in the justification for this RFC, RFC 2616 clearly
anticipates the possibility of doing PUT with a partial content range. See section
9.6 (http://tools.ietf.org/html/rfc2616#section-9.6). Thus, PUT is the moral
equivalent of fseek() + fwrite(), not just fwrite(). I have personally implemented
web services that use PUT with Content-Range, and I don't think I'm alone. The
fact that the community has not generally understood this nuance does not
necessarily mean PATCH is needed. It would be possible to simply clarify how
PUT is used with Content-Range and accomplish virtually everything that PATCH
is attempting. However, PATCH has the virtue of no semantic baggage, and it may
also be nice to use patch-if logic like the familiar *nix-style patch program, which
is a valid semantic enhancement to dumb update. This point needs to be made
more clearly in the RFC's preamble; as-is, I think the case for PATCH is too weak.
--VERIFIER NOTES--
A disagreement with IETF consensus does not an erratum make. You may have strong disagreement with the document as published, but what's published is what was intended to be published; this is not an "error" in the document.

RFC 5795, "The RObust Header Compression (ROHC) Framework", March 2010

Source of RFC: rohc (tsv)

Errata ID: 2108
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-04-05
Rejected by: Lars Eggert
Date Rejected: 2011-02-03

Section 3.2 says:

[[  last paragraph on page 9: ]]

|  An enhanced variant of CRTP, called eCRTP [RFC3545], means to improve
   the robustness of CRTP in the presence of reordering and packet
   losses, while keeping the protocol almost unchanged from CRTP.  As a
   result, eCRTP does provide better means to implement some degree of
   robustness, albeit at the expense of additional overhead, leading to
   a reduction in compression efficiency in comparison to CRTP.

It should say:

|  An enhanced variant of CRTP, called eCRTP [RFC3545], introduces means
   to improve the robustness of CRTP in the presence of reordering and
   packet losses, while keeping the protocol almost unchanged from CRTP.
   As a result, eCRTP does provide better means to implement some degree
   of robustness, albeit at the expense of additional overhead, leading
   to a reduction in compression efficiency in comparison to CRTP.

Notes:

Rationale: missing verb (legacy).
--VERIFIER NOTES--
Reject, but make note to improve this text in next update

Errata ID: 2109
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-04-05
Rejected by: Lars Eggert
Date Rejected: 2011-02-03

Section 5.1.2, pg.17 says:

[[  first paragraph on page 17: ]]

   PROFILES: Set of non-negative integers, where each integer indicates
   a profile supported by both the compressor and the decompressor.  A
|  profile is identified by a 16-bit value, where the 8 LSB bits
|  indicate the actual profile, and the 8 MSB bits indicate the variant
   of that profile.  The ROHC compressed header format identifies the
|  profile used with only the 8 LSB bits; this means that if multiple
   variants of the same profile are available for a ROHC channel, the
   PROFILES set after negotiation MUST NOT include more than one variant
   of the same profile.  The compressor MUST NOT compress using a
   profile that is not in PROFILES.

It should say:

   PROFILES:  Set of non-negative integers, where each integer indicates
   a profile supported by both the compressor and the decompressor.  A
|  profile is identified by a 16-bit value, where the 8 LSBs indicate
|  the actual profile, and the 8 MSBs indicate the variant of that
   profile.  The ROHC compressed header format identifies the profile
|  used with only the 8 LSBs; this means that if multiple variants of
   the same profile are available for a ROHC channel, the PROFILES set
   after negotiation MUST NOT include more than one variant of the same
   profile.  The compressor MUST NOT compress using a profile that is
   not in PROFILES.

Notes:

Rationale: Abuse of language;
the acronym definitions in Section 2.1 clearly say:
LSB Least Significant Bit.
...
MSB Most Significant Bit.
--VERIFIER NOTES--
proposed change is somewhat pedantic; it actually might reduce readability for some readers

RFC 5797, "FTP Command and Extension Registry", March 2010

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 3471
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alun Jones
Date Reported: 2013-01-27
Rejected by: Pete Resnick
Date Rejected: 2013-01-28

Section 5 says:

Notes:

Section 5 states that the IANA has set up the registry, but does not give any hints as to how to find it. A link to its location would be handy. I presume the correct location is http://www.iana.org/assignments/ftp-commands-extensions/ftp-commands-extensions.xml
--VERIFIER NOTES--
A a practice, we do not put URLs for registries into RFCs. Not an appropriate use of the errata system, in any event.

RFC 5802, "Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms", July 2010

Note: This RFC has been updated by RFC 7677, RFC 9266

Source of RFC: sasl (sec)

Errata ID: 3472
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Marko Kreen
Date Reported: 2013-01-28
Rejected by: Stephen Farrell

Section 5 says:

C: n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL
S: r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,
   i=4096
C: c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,
   p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts=
S: v=rmF9pqV8S7suAoZWja4dJRkFsKQ=

It should say:

C: n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL
S: r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,
   i=4096
C: c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,
   p=frsVRm77a2tPQ5vy+zZuaKRR17o=
S: v=01o5+Qz2QpK1yrmPi3ZwOZzQTzs=

Notes:

The test vector seems wrong, at least I cannot find code pattern that produces same result. Here is the code I used to calculate it:

https://gist.github.com/4654875

Errata ID: 5882
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Neil Madden
Date Reported: 2019-10-25
Rejected by: Benjamin Kaduk
Date Rejected: 2019-10-25

Section 2.2 says:

Hi(str, salt, i):

     U1   := HMAC(str, salt + INT(1))
     U2   := HMAC(str, U1)
     ...
     Ui-1 := HMAC(str, Ui-2)
     Ui   := HMAC(str, Ui-1)

     Hi := U1 XOR U2 XOR ... XOR Ui

It should say:

Hi(str, salt, i):

     U1   := HMAC(str, salt + INT(i))
     U2   := HMAC(str, U1)
     ...
     Ui-1 := HMAC(str, Ui-2)
     Ui   := HMAC(str, Ui-1)

     Hi := U1 XOR U2 XOR ... XOR Ui

Notes:

The first round of PBKDF2 is defined incorrectly with a hard-coded value "INT(1)" rather than "INT(i)" (the iteration count). See RFC 2898 section 5.2 step 3. This error means that the computation of PBKDF2 with n iterations is a prefix of the computation required for PBKDF2 with m iterations (with m > n), which is otherwise not the case (and may have security implications?).
--VERIFIER NOTES--
Rejected per submitter request. The 1 here indicates it is the first block of the output stream being computed, and only one such block is needed.

RFC 5810, "Forwarding and Control Element Separation (ForCES) Protocol Specification", March 2010

Note: This RFC has been updated by RFC 7121, RFC 7391

Source of RFC: forces (rtg)

Errata ID: 2570
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jamal Hadi Salim
Date Reported: 2010-10-16
Rejected by: Adrian Farrel
Date Rejected: 2010-10-18

Section Figure 1 says:

Figure 1 does not have a line joining CE2 and FE2 with Fp..

It should say:

Figure 1 should have a line joining CE2 and FE2 with Fp..

Notes:

This is just a description of how to fix.
I think this form can be improved so i can
enter descriptive text instead of s/orig/new approach
--VERIFIER NOTES--
After discussion with the WG, it was agreed that the figure deliberately reproduces a figure from RFC 3746 and should be left unchanged.

RFC 5812, "Forwarding and Control Element Separation (ForCES) Forwarding Element Model", March 2010

Note: This RFC has been updated by RFC 7408

Source of RFC: forces (rtg)

Errata ID: 2577
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jamal Hadi Salim
Date Reported: 2010-10-16
Rejected by: Adrian Farrel
Date Rejected: 2011-07-24

Section global says:

I dont know where to capture this, but it needs to be
captured somewhere and i couldnt think of a better place..
This is in regards to the XML definitions..

The baseID of events, componentIDs and capabilitiyIDs should be unique
within the LFB. The schema now distinguishes per category, not globally.

It should say:

It would valuable to be able to validate via the schema that there is
uniqueness.

Notes:

--VERIFIER NOTES--
This Erratum is rejected after consultation with the ForCES chair.

The LFB Class is unique globaly. The LFB instance is unique per LFB.
The LFB components are uniquely identified by LFB class::instance id.
Therefore by inference, the LFB events, componentIDs and capabilitiyIDs
are globaly unique.

RFC 5838, "Support of Address Families in OSPFv3", April 2010

Note: This RFC has been updated by RFC 6969, RFC 7949, RFC 8362, RFC 9454

Source of RFC: ospf (rtg)

Errata ID: 7644
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Owen DeLong
Date Reported: 2023-09-17
Rejected by: John Scudder
Date Rejected: 2024-01-11

Section 2.7 says:

   Interface MTU
      The size in octets of the largest address family specific datagram
      that can be sent on the associated interface without
      fragmentation.  The MTUs of common Internet link types can be
      found in Table 7-1 of [MTUDISC].  The Interface MTU SHOULD be set
      to 0 in Database Description packets sent over virtual links.

It should say:

   Interface MTU
      The size in octets of the largest address family specific datagram
      that can be sent on the associated interface without
      fragmentation.  The MTUs of common Internet link types can be
      found in Table 7-1 of [MTUDISC].  The Interface MTU SHOULD be set
      to 0 in Database Description packets sent over (OSPF3) virtual links.
      This recommendation MUST NOT be applied to tunnel and other virtual
      or software interfaces which carry traffic other than OSPF protocol packets.

Notes:

Currently, the language is ambiguous and at least one vendor has implemented OSPF3 sending an MTU of zero on GRE interfaces (and possibly others such as IPIP, IPSEC, etc., as I have not tested these). I believe that the intent of the RFC is to refer strictly to OSPF virtual-links which carry only OSPF protocol data and therefore have no meaningful MTU. When this is mistakenly applied to other forms of "virtual" interfaces such as tunnels, the results can be quite harmful.

As such, I think that clarification is in order, since the vendor in question is unrepentant and claims their current implementation to be compliant with the RFC.
--VERIFIER NOTES--
See discussion at https://mailarchive.ietf.org/arch/msg/lsr/wXdOtU9H2vIoA1xs10xZ4oh8bwU/

RFC 5849, "The OAuth 1.0 Protocol", April 2010

Note: This RFC has been obsoleted by RFC 6749

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 2549
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alasdair McIntyre
Date Reported: 2010-10-12
Rejected by: Peter Saint-Andre
Date Rejected: 2010-11-18

Section 3.4.1.3.1. says:

   For example, the HTTP request:

       POST /request?b5=%3D%253D&a3=a&c%40=&a2=r%20b HTTP/1.1
       Host: example.com
       Content-Type: application/x-www-form-urlencoded
       Authorization: OAuth realm="Example",
                      oauth_consumer_key="9djdj82h48djs9d2",
                      oauth_token="kkk9d7dh3k39sjv7",
                      oauth_signature_method="HMAC-SHA1",
                      oauth_timestamp="137131201",
                      oauth_nonce="7d8f3e4a",
                      oauth_signature="djosJKDKJSD8743243%2Fjdk33klY%3D"

       c2&a3=2+q

   contains the following (fully decoded) parameters used in the
   signature base sting:

It should say:

   For example, the HTTP request:

       POST /request?b5=%3D%253D&a3=a&c%40=&a2=r%20b HTTP/1.1
       Host: example.com
       Content-Type: application/x-www-form-urlencoded
       Authorization: OAuth realm="Example",
                      oauth_consumer_key="9djdj82h48djs9d2",
                      oauth_token="kkk9d7dh3k39sjv7",
                      oauth_signature_method="HMAC-SHA1",
                      oauth_timestamp="137131201",
                      oauth_nonce="7d8f3e4a",
                      oauth_signature="bYT5CMsGcbgUdFHObYMEfcx6bsw%3D"

       c2&a3=2+q

   contains the following (fully decoded) parameters used in the
   signature base sting:

Notes:

It looks like "GET" was updated to "POST" in a previous revision, but the oauth_signature was not updated at the same time. All other instances of this change from GET to POST did have the oauth_signature field correctly updated.
--VERIFIER NOTES--
Peter: This is superseded by erratum #2550.

RFC 5864, "DNS SRV Resource Records for AFS", April 2010

Note: This RFC has been updated by RFC 8553

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 2259
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-05-13
Rejected by: Pete Resnick
Date Rejected: 2011-08-04

Section Abstract says:

   ... DNS (Domain Name Service) ...

It should say:

   ... DNS (Domain Name System) ...

Notes:

Rationale: wrong expansion of acronym
--VERIFIER NOTES--
Both terms have been used. (See RFCs 830, 1001, 1834, etc.)

RFC 5880, "Bidirectional Forwarding Detection (BFD)", June 2010

Note: This RFC has been updated by RFC 7419, RFC 7880, RFC 8562

Source of RFC: bfd (rtg)

Errata ID: 6818
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2022-01-15
Rejected by: John Scudder
Date Rejected: 2022-05-09

Section 6.7.2 says:

      If the Auth Len field is not equal to the length of the password
      selected by the key ID, plus three, the packet MUST be discarded.

It should say:

      If the Auth Len field is not match to the length of the password
      selected by the key ID, plus three, the packet MUST be discarded.

Notes:

The value of the Auth Len field is the length of the password plus 3.
--VERIFIER NOTES--
https://mailarchive.ietf.org/arch/msg/rtg-bfd/ukbCzkS8NkTWdXEPvB9mlFtIiSQ/

This erratum proposes changing “is not equal” to “is not match”. As far as I can tell would make the text less, not more, precise.

RFC 5903, "Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2", June 2010

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 2308
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-06-22
Rejected by: Sean Turner
Date Rejected: 2011-11-12

Section 3.1 - 3.3 says:

a) in Section 3.1:

   Field Size:
    256

b) in Section 3.2:

   Field Size:
    384

c) in Section 3.3:

   Field Size:
    521

It should say:

a)

   Field bit width:
    256

b)

   Field bit width:
    384

c)

   Field bit width:
    521   

Notes:

Rationale:

The "size" of a finite field is the number of elements of the field,
according to century-old well-established mathematical terminology.
In the case of Sections 3.1 through 3.3, the field width is the prime
number p given 3 lines above the given snippets.
The idea is to give the number of bits needed to represent the field
elements (integers modulo p), which serve as the x and y coordinates
of the Elliptic Curve group points -- hence this should be denoted as
the bit width of the field (elements), which equals ceil(lb(p)).
--VERIFIER NOTES--
I just can't see keeping this as-is is going to cause any issues for implementers.

Errata ID: 2309
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-06-22
Rejected by: Sean Turner
Date Rejected: 2011-11-12

Section 10.2 says:

   [Err9]         RFC Errata, Errata ID 9, RFC 4753,
                  <http://www.rfc-editor.org>.

It should say:

   [Err9]         RFC Errata, Errata ID 9, RFC 4753; see
                  <http://www.rfc-editor.org/info/rfc4753>.

Notes:

Rationale:
A less experienced reader will likely have difficulties locating
the Errata entry given only the RFC Editor home page URL.
The RFC 'info' URIs have been introduced by RFC 5741 to provide
stable canonical URIs for all information related to a given RFC;
thus, the proper stable URI should be provided in the reference entry.
--VERIFIER NOTES--
The reference entry for Errata ID 9 is similar to how errata were referenced in previous RFCs (5550 and 5724). The URL of the main RFC Editor page was used intentionally, rather than the URL of the specific Errata ID or the RFC's info page (as in Alfred's corrected text).

RFC 5905, "Network Time Protocol Version 4: Protocol and Algorithms Specification", June 2010

Note: This RFC has been updated by RFC 7822, RFC 8573, RFC 9109

Source of RFC: ntp (int)

Errata ID: 3613
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Tony O'Brien
Date Reported: 2013-05-06
Rejected by: Brian Haberman
Date Rejected: 2013-05-06

Section 8 says:

Notes:

In the paragraph explaining the sanity checks on received packets, it states: "In the exchange above, a packet is duplicate or replay if the transmit timestamp t3 in the packet matches the org state variable T3." But in the pseudo-code in A.5.1 it states
/*
* If the transmit timestamp duplicates a previous one, the
* packet is a replay.
*/
if (r->xmt == p->xmt)
i.e. comparing the transmit timestamp p->xmt with the xmt state variable T1. Which is correct?

Similarly for the check for a bogus packet, Section 8 states: "A packet is bogus if the origin timestamp t1 in the packet does not match the xmt state variable T1. But the pseudo-code says:
/*
* If this is a broadcast mode packet, skip further checking.
* If the origin timestamp is zero, the sender has not yet heard
* from us. Otherwise, if the origin timestamp does not match
* the transmit timestamp, the packet is bogus.
*/
synch = TRUE;
if (r->mode != M_BCST) {
if (r->org == 0)
synch = FALSE; /* unsynchronized */

else if (r->org != p->xmt)
synch = FALSE; /* bogus packet */
}
i.e. it is comparing the transmit timestamp t3 in the packet with the org state variable T3.

Which is correct? Looking at Figure 15 my guess would be Section 8 is correct but I have seen code that more closely follows the pseudo-code.
--VERIFIER NOTES--
The Introduction of the document clearly states that the pseudo-code in the appendix is non-normative. Therefore the text in the main body of the specification describes the conformant behavior:

"The contents of Appendix A are non-normative examples designed to illustrate the protocol's operation and are not a requirement for a conforming implementation."

Errata ID: 4505
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Miroslav Lichvar
Date Reported: 2015-10-15
Rejected by: Brian Haberman
Date Rejected: 2015-12-14

Section A.5.1 says:

        /*
         * Update the origin and destination timestamps.  If
         * unsynchronized or bogus, abandon ship.
         */
        p->org = r->xmt;
        p->rec = r->dst;
        if (!synch)
                return;                 /* unsynch */

        /*
         * The timestamps are valid and the receive packet matches the
         * last one sent.  If the packet is a crypto-NAK, the server
         * might have just changed keys.  We demobilize the association
         * and wait for better times.
         */
        if (auth == A_CRYPTO) {
                clear(p, X_CRYPTO);
                return;                 /* crypto-NAK */
        }

        /*
         * If the association is authenticated, the key ID is nonzero
         * and received packets must be authenticated.  This is designed
         * to avoid a bait-and-switch attack, which was possible in past
         * versions.
         */
        if (!AUTH(p->keyid || (p->flags & P_NOTRUST), auth))
                return;                 /* bad auth */

It should say:

        /*
         * If the packet is a valid crypto-NAK, the server might have
         * just changed keys.  We demobilize the association and wait
         * for better times.
         */
        if (synch && auth == A_CRYPTO) {
                clear(p, X_CRYPTO);
                return;                 /* crypto-NAK */
        }

        /*
         * If the association is authenticated, the key ID is nonzero
         * and received packets must be authenticated.  This is designed
         * to avoid a bait-and-switch attack, which was possible in past
         * versions.
         */
        if (!AUTH(p->keyid || (p->flags & P_NOTRUST), auth))
                return;                 /* bad auth */

        /*
         * Update the origin and destination timestamps.  If
         * unsynchronized or bogus, abandon ship.
         */
        p->org = r->xmt;
        p->rec = r->dst;
        if (!synch)
                return;                 /* unsynch */

Notes:

The state variables must be updated after the authentication is checked in order to prevent DoS attacks on authenticated symmetric associations (CVE-2015-1799).
--VERIFIER NOTES--
The appendix is not the normative description of the protocol behavior. A change such as this needs consensus within the working group. To do that, a draft should be submitted with the proposed changes.

Errata ID: 5020
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Ferenc Wágner
Date Reported: 2017-05-15
Rejected by: Erik Kline
Date Rejected: 2022-08-29

Section 8 says:

theta = T(B) - T(A) = 1/2 * [(T2-T1) + (T3-T4)]

It should say:

theta = T(B) - T(A) = 1/2 * [(T2-T1) + (T4-T3)]

Notes:

The corresponding code line in A.5.1.1. agrees with this correction:

offset = (LFP2D(r->rec - r->org) + LFP2D(r->dst - r->xmt)) / 2;

taking Figure 7 into account:

| org | T1 | origin timestamp |
| rec | T2 | receive timestamp |
| xmt | T3 | transmit timestamp |
| dst | T4 | destination timestamp |
--VERIFIER NOTES--
As noted this thread:

https://mailarchive.ietf.org/arch/msg/ntp/AR7k0IP2PMgXdq2bknx6Eiz4upE/

'''
Theta is "the offset of B relative to A". The proposed revision is

1/2 * [(T2-T1) + (T4-T3)]

Example: Let's assume that B and A are exactly synced to UTC and that the
network delay is 50msec in each direction.

T2-T1 is the NTP mode 3 request delay (including network delay).

This gives 50 msec
T4-T3 is the NTP mode 4 response delay (including network delay).

This gives 50 msec.

The proposed revision gives 100msec/2 = RTT/2, not the expected offset of
zero.

The RFC5905 formula seems correct.

theta = T(B) - T(A) = 1/2 * [(T2-T1) + (T3-T4)]

but might have been clearer had it been written:

theta = T(B) - T(A) = 1/2 * [(T2-T1) - (T4-T3)]
'''

RFC 5906, "Network Time Protocol Version 4: Autokey Specification", June 2010

Source of RFC: ntp (int)

Errata ID: 3347
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: liyh
Date Reported: 2012-09-12
Rejected by: Brian Haberman
Date Rejected: 2012-09-12

Section 5 says:

Cookie exchange.  The request includes the public key of the server.The response includes the server cookie encrypted with this key.

It should say:

I don't know.

Notes:

how to decrypt?
--VERIFIER NOTES--
The decryption is carried out with the private key.

RFC 5912, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", June 2010

Note: This RFC has been updated by RFC 6960, RFC 9480

Source of RFC: pkix (sec)

Errata ID: 3623
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Carl Wallace
Date Reported: 2013-05-16
Rejected by: Sean Turner
Date Rejected: 2013-05-20

Section 14 says:

   -- CRL number extension OID and syntax
   ext-CRLNumber EXTENSION ::= {SYNTAX
       INTEGER (0..MAX) IDENTIFIED BY id-ce-cRLNumber }
   id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }

   CRLNumber ::= INTEGER (0..MAX)

It should say:

   -- CRL number extension OID and syntax
   CRLNumber ::= INTEGER 

   ext-CRLNumber EXTENSION ::= {SYNTAX
       CRLNumber IDENTIFIED BY id-ce-cRLNumber }
   id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }

Notes:

The CRLNumber extension was not defined to use the CRLNumber type. The CRLNumber type uses MAX to limit the maximum value. This limitation is inconsistent with section 5.2.3 and Appendix B, which allow CRLNumber values up to 20 octets in length.
--VERIFIER NOTES--
This errata is rejected at the request of the person who reported it (i.e., Carl). Another errata was submitted to correct a mistake.

RFC 5917, "Clearance Sponsor Attribute", June 2010

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 4558
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lars Wilhelmsen
Date Reported: 2015-12-07
Rejected by: Benjamin Kaduk
Date Rejected: 2019-10-26

Section Appendix A says:

IMPORTS

   -- Imports from New PKIX ASN.1 [RFC5912]

     DirectoryString
       PKIX1Explicit-2009
         { iso(1) identified-organization(3) dod(6) internet(1)
           security(5) mechanisms(5) pkix(7) id-mod(0)
           id-pkix1-explicit-02(51) }

It should say:

IMPORTS

   -- Imports from New PKIX ASN.1 [RFC5912]

     DirectoryString
       FROM PKIX1Explicit-2009
         { iso(1) identified-organization(3) dod(6) internet(1)
           security(5) mechanisms(5) pkix(7) id-mod(0)
           id-pkix1-explicit-02(51) }

Notes:

Missing "FROM" in import statement.
--VERIFIER NOTES--
While the FROM is indeed missing, there is another error in this text that was reported in eid5883; since that report fully supersedes this one, this errata report is redundant. "Rejected" is the least bad state in which to leave such a report.

RFC 5925, "The TCP Authentication Option", June 2010

Source of RFC: tcpm (wit)

Errata ID: 7135
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Venkatesh Natarajan
Date Reported: 2022-09-16
Rejected by: Martin Duke
Date Rejected: 2022-10-06

Section 7.3 says:

>> A TCP-AO implementation MUST allow for configuration of the
   behavior of segments with TCP-AO but that do not match an MKT.  The
   initial default of this configuration SHOULD be to silently accept
   such connections.  If this is not the desired case, an MKT can be
   included to match such connections, or the connection can indicate
   that TCP-AO is required.  Alternately, the configuration can be
   changed to discard segments with the AO option not matching an MKT.

It should say:

>> A TCP-AO implementation MUST allow for configuration of the
   behavior of segments with TCP-AO but that do not match any MKT or 
   no MKT is available. The initial default of this configuration 
   SHOULD be to silently accept such connections. In this mode of 
   operation, both the endpoints will not perform TCP-AO validation.
   If this is not the desired case, an MKT can be included to match such 
   connections, or the connection can indicate that TCP-AO is required. 
   Alternately, the configuration can be changed to discard segments
   with the AO option not matching an MKT.

Notes:

The RFC does not clearly draw out the distinction between treatment of segments with TCP-AO and without TCP-AO option.
Note that in the case of MKT mismatch as per existing RFC text, if either endpoint does TCP-AO validation, the session would not get established.
--VERIFIER NOTES--
As noted in the email below, when both sides do not have common configuration, the handshake will fail.

Please see https://mailarchive.ietf.org/arch/msg/tcpm/0zG2aP5tGBvbRJxuNOIPFYDK9Jg/

Errata ID: 5347
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ignacio Goyret
Date Reported: 2018-05-03
Rejected by: Mirja Kühlewind
Date Rejected: 2020-03-04

Section 5.1 says:

3. The TCP header, by default including options, and where the TCP
   checksum and TCP-AO MAC fields are set to zero, all in network-
   byte order.

   The TCP option flag of the MKT indicates whether the TCP options
   are included in the MAC.  When included, only the TCP-AO MAC field
   is zeroed.

   When TCP options are not included, all TCP options except for TCP-
   AO are omitted from MAC processing.  Again, the TCP-AO MAC field
   is zeroed for the MAC processing.

It should say:

3. The TCP header and TCP options, where the TCP checksum and TCP-AO
   MAC fields are always set to zero, all in network-byte order.

   The TCP option flag of the MKT indicates which TCP options are
   included in the MAC. When TCP options are not included, only the
   TCP option for TCP-AO (as described in Section 2.2) is included
   in the MAC. Otherwise, all the TCP options are included in the MAC.

Notes:

Rewording for clarity and simplification.
The original text could lead to confusion re '...When included, only the TCP-AO MAC field is zeroed.'
--VERIFIER NOTES--
Rejected as the proposed text does not seem fundamentally clearer.

RFC 5926, "Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)", June 2010

Source of RFC: tcpm (wit)

Errata ID: 5267
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Brian Weis
Date Reported: 2018-02-26
Rejected by: Mirja Kühlewind
Date Rejected: 2018-03-28

Section 3.1.1 says:

- Label:     A binary string that clearly identifies the purpose
                   of this KDF's derived keying material.  For TCP-AO,
                   we use the ASCII string "TCP-AO", where the last
                   character is the capital letter "O", not to be
                   confused with a zero.  While this may seem like
                   overkill in this specification since TCP-AO only
                   describes one call to the KDF, it is included in
                   order to comply with FIPS 140 certifications.

It should say:

- Label:     A binary string that clearly identifies the purpose
                   of this KDF's derived keying material.  For TCP-AO,
                   we use the ASCII string "TCP-AO", where the last
                   character is the capital letter "O", not to be
                   confused with a zero. The ASCII string is terminated
                   with a null octet (0x00). While this may seem like
                   overkill in this specification since TCP-AO only
                   describes one call to the KDF, it is included in
                   order to comply with FIPS 140 certifications.

Notes:

This section states that "Both of these KDFs are based on the iteration-mode KDFs specified in [NIST-SP800-108].", which is later clarified to be the "counter mode" KDF defined in that document. The definition of the "Label" input to the KDF in the original text is not clear.

[NIST-SP800-108] specifies that a 0x00 octet should follow the Label. This 0x00 octet is important when the KDF does not have control over the Context given it, which is the case here -- RFC 5926 depends on the definition in RFC 5925. RFC 5925 currently declares two fixed-size inputs for the Context (See Figures 7 & 8 of RFC 5925), so the Context length differs. Also, RFC 5925 RFC could be updated over over time to include other Contexts that are variable sized. The risk of excluding 0x00 is enabling an attacker to choose a specially-crafted Context that violates the clean separation between the Label and Context arguments. Therefore, it is important to include the 0x00 octet for TCP-AO.

I believe this 0x00 is implied in the specification of the string "TCP-AO", since conventionally many string definitions include a trailing 0x00 octet, The text should state that the 0x00 octet is present as part of the string.

If this errata does not result in adding the 0x00 octet, then its omission needs to be justified.
--VERIFIER NOTES--
NIST-SP800-108 does not require the use of 0x00. It only requires that the length and order of each field be defined unambiguously. The method of providing that length unambiguously to the KDF algorithm is an implementation issue.

RFC 5952, "A Recommendation for IPv6 Address Text Representation", August 2010

Source of RFC: 6man (int)

Errata ID: 2656
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: D. Stussy
Date Reported: 2010-12-02
Rejected by: Brian Haberman
Date Rejected: 2012-05-30

Section 4.3 says:

4.3.  Lowercase

   The characters "a", "b", "c", "d", "e", and "f" in an IPv6 address
   MUST be represented in lowercase.

It should say:

4.3.  Case of Alphabetic Digits.

   The digits "A" through "F" in an IPv6 address
   MUST be represented in upper case.  User and user
   derived input may be represented using lower case.

Notes:

Historically from the 1960's, hexidecimal digits other than decimal digits are represented by upper case letters. Lower case letters may have become acceptable as user input, but such resulted from lazy programmers who couldn't manage to hit the shift key on their keyboards. However, lower case is not acceptable for digit output. Many early assemblers would not even accept lower case as valid input digits except where the radix base exceeded 36 (thus exhausting all upper case values). This poor programming practice should not be allowed to be codified into any Internet standard.

References:
- Struble, George W., "Assembler Language Programming: The IBM System/360 and /370." Addison-Wesley Publishing Co., 1969 and 1975 (Second Edition), Page 6. ISBN 0-201-7322-6
- Barden, William Jr., "TRS-80 Assembly-Language Programming." Tandy Corporation, 1979, page 14. Library of Congress #79-63607
- Leventhal, Lance A., "6502 Assembly Language Programming." Osborne McGraw-Hill, 1979 and 1986 (Second Edition), Page 1-4. ISBN 0-07-881216-X
- Intel Corporation, "Intel486 Microprocessor Family Programmer's Reference Manual." 1995, Page 1-8 (Section 1.3.4). No ISBN or LoC #.
- Cress, Paul, Dirksen, Paul, and Grahm, J. Wesley, "Fortran IV with WatFor and WatFiv." Prentice-Hall, 1968 and 1970, Page 245. LoC 74-129241
- Mano, M. Morris, "Computer System Architecture." Prentice-Hall, 1982, Page 79. ISBN 0-13-166611-8
- Higgins, Richard J., "Electronics with Digital and Analog Integrated Circuits." Prentice-Hall, 1983, Page 60. ISBN 0-13-250704-8

However, I also note this ONE source permits mixed case:
- Kernighan, Brian W. & Ritchie, Dennis M., "The C Programming Language", Prentice Hall, 1978 (First Edition), Page 180. ISBN 0-13-110163-3

Many other pre-1990 computer science and engineering books show hexidecimal non-decimal digits as upper case only and NEVER as lower case. However, I could not find pages in them defining the lettered-digits as upper case only despite their consistent usage of upper case printing.
--VERIFIER NOTES--
This errata is attempting to overturn the clear consensus of the WG.

Errata ID: 2872
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Richard J. Smith
Date Reported: 2011-07-28
Rejected by: Brian Haberman
Date Rejected: 2012-06-01

Section 5 says:

   For these addresses, mixed notation is
   RECOMMENDED if the following condition is met: the address can be
   distinguished as having IPv4 addresses embedded in the lower 32 bits
   solely from the address field through the use of a well-known prefix.

It should say:

   For these addresses, mixed notation is 
   RECOMMENDED if the following conditions are met: the address can be
   distinguished as having IPv4 addresses embedded in the lower 32 bits 
   solely from the address field through the use of a well-known prefix, 
   and the entire address is not either the unspecified IPv6 address 
   "::" or the loopback IPv6 address "::1".

Notes:

RFC-4291 defines the 80-bit all-zeros prefix as indicating an "IPv4-compatible IPv6 address". Without further clarification in section 5 of RFC-5952, the recommended formatting of the IPv6 unspecified address would be "::0.0.0.0", and the recommended formatting of the IPv6 loopback address would be "::0.0.0.1". Neither of these recommended representations is desirable.
--VERIFIER NOTES--
::1 and :: are more specific and not part of the reserved block for IPv4 compatible addresses.

Errata ID: 3884
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Richard Hartmann
Date Reported: 2014-02-06
Rejected by: Brian Haberman
Date Rejected: 2014-02-12

Section 4.2.2. says:

4.2.2.  Handling One 16-Bit 0 Field

   The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field.
   For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but
   2001:db8::1:1:1:1:1 is not correct.

It should say:

4.2.2.  Incorrect use of "::"

   The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field.
   For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but
   2001:db8::1:1:1:1:1 is not correct.

   The symbol "::" MUST NOT be used just so. For example, the
   representation 2001:db8:1:1:1:1:1:1 is correct, but
   2001:db8:1:1::1:1:1:1 is not correct.

Notes:

You would think this should be obvious, but I have seen actual discussions that 2001:db8:1:1::1:1:1:1 is correct syntax. Explicitly forbidding this form does no harm and stops all discussions in this direction.

Thanks for your work.
--VERIFIER NOTES--
As agreed to by the document authors and the submitter, there is a reference to RFC 4291 that addresses the concern.

Errata ID: 4483
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: André Melancia
Date Reported: 2015-09-26
Rejected by: Brian Haberman
Date Rejected: 2015-09-28

Section 4.3 says:

—

It should say:

—

Notes:

Errata ID 2656, reported by D. Stussy in 2010-12-02 is CORRECT and perfectly justified.
This was however rejected on 2012-05-30. Justification on "verified notes" states "This errata is attempting to overturn the clear consensus of the WG.", which is WRONG, since WG consensus applies to the whole document, not specifically to section 4.3 or its unjustified and arbitrary lowercase conventioning.
There is no technical reason why lowercase "must" or "should" be used, instead, HISTORICALLY (which for any IETF work has been the "de facto" rule) uppercase has been used (see full justification in Errata ID 2656 mentioned above).
Additionally, and considering that modern devices are able to properly handle case changes without performance losses, the WG should discuss removing this rule altogether.
--VERIFIER NOTES--
The consensus of the working group was to employ lowercase despite your arguments. This erratum is attempting to overturn the consensus of the WG during the publication of this RFC.

Errata ID: 4900
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Krzyzaniak
Date Reported: 2017-01-10
Rejected by: Erik Kline
Date Rejected: 2021-12-27

Section 4.2.2. says:

Handling One 16-Bit 0 Field

The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field.
   For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but
   2001:db8::1:1:1:1:1 is not correct.

It should say:

But Section 2.2.  Zero Compression
says:

'A special syntax is available to compress the zeros.  The use of
      "::" indicates one or more groups of 16 bits of zeros.'

   It is possible to select whether or not to omit just one 16-bit 0
   field.

      2001:db8:aaaa:bbbb:cccc:dddd::1

      2001:db8:aaaa:bbbb:cccc:dddd:0:1

Notes:

In 2.2 :: for only one 16-bit 0 filed :: is used
4.2.2 says MUST NOT -RFC 2119 says
2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the
definition is an absolute prohibition of the specification.
--VERIFIER NOTES--
Valid versus canonical forms; see https://www.rfc-editor.org/errata/eid4986 for links to further discussion.

Errata ID: 4986
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julian de Prado
Date Reported: 2017-03-31
Rejected by: Erik Kline
Date Rejected: 2021-12-27

Section 2.2 says:

'A special syntax is available to compress the zeros. The use of
"::" indicates one or more groups of 16 bits of zeros.'

It should say:

'A special syntax is available to compress the zeros. The use of
"::" indicates two or more groups of 16 bits of zeros.'

Notes:

"indicates one" should be written as "indicates two"

for example:
'A special syntax is available to compress the zeros. The use of
"::" indicates two or more groups of 16 bits of zeros.'

2001:db8:aaaa:bbbb:cccc::1

2001:db8:aaaa:bbbb:cccc:0:0:1
--VERIFIER NOTES--
RFC 4291, section 2.2, #2 is clear that the current text is valid. Section 4.2.2 contains a specific recommendation for the defined canonical form in this situation. The canonical form is (must be) valid, but not all valid forms are canonical (of necessity :-).

To reach the working group discussion see this thread: https://mailarchive.ietf.org/arch/msg/ipv6/41x17WLwxBoS6AAtH6p0nuC84sk/

RFC 5965, "An Extensible Format for Email Feedback Reports", August 2010

Note: This RFC has been updated by RFC 6650

Source of RFC: marf (app)

Errata ID: 7091
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alessandro Vesely
Date Reported: 2022-08-16
Rejected by: Murray Kucherawy
Date Rejected: 2024-02-03

Section 2 says:

   e.  Except as discussed below, each feedback report MUST be related
       to only a single email message.  Summary and aggregate formats
       are outside of the scope of this specification.

It should say:

   e.  Except when using the Incidents field (see below),
       each feedback report MUST be related
       to only a single email message.  Summary and aggregate formats
       are outside of the scope of this specification.

Notes:

There doesn't seem to be another discussion of similarity.
--VERIFIER NOTES--
A single report is about a single message, even if it includes a claim that it is similar to other messages.

RFC 5969, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", August 2010

Source of RFC: softwire (int)

Errata ID: 3869
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Fernando Gont
Date Reported: 2014-01-20
Rejected by: Ted Lemon
Date Rejected: 2014-01-21

Section 9.2 says:

In order to prevent spoofing of IPv6 addresses, the 6rd BR and CE
MUST validate the embedded IPv4 source address of the encapsulated
IPv6 packet with the IPv4 source address it is encapsulated by
according to the configured parameters of the 6rd domain.

It should say:

In order to prevent spoofing of IPv6 addresses, the 6rd BR and CE
MUST validate the embedded IPv6 source address of the encapsulated
IPv6 packet with the IPv4 source address it is encapsulated by
according to the configured parameters of the 6rd domain.

Notes:

Authors have verified that the text as written in the RFC is correct, and the proposed change is incorrect.
--VERIFIER NOTES--
Authors have verified that the text as written in the RFC is correct, and the proposed change is incorrect.

RFC 5988, "Web Linking", October 2010

Note: This RFC has been obsoleted by RFC 8288

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 3080
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Matt Parker
Date Reported: 2012-01-05
Rejected by: Peter Saint-Andre
Date Rejected: 2012-01-26

Section 5 says:

  link-value     = "<" URI-Reference ">" *( ";" link-param )
  link-param     = ( ( "rel" "=" relation-types )
                 | ( "anchor" "=" <"> URI-Reference <"> )
                 | ( "rev" "=" relation-types )
                 | ( "hreflang" "=" Language-Tag )
                 | ( "media" "=" ( MediaDesc | ( <"> MediaDesc <"> ) ) )
                 | ( "title" "=" quoted-string )
                 | ( "title*" "=" ext-value )
                 | ( "type" "=" ( media-type | quoted-mt ) )
                 | ( link-extension ) )

It should say:

  link-value     = "<" URI-Reference ">" 
                     [( ";" rel-param )] 
                     *( ";" anchor-param ) 
                     *( ";" rev-param ) 
                     *( ";" hreflang-param ) 
                     [( ";" media-param )] 
                     [( ";" title-param )] 
                     [( ";" title-alt-param )] 
                     [( ";" type-param )] 
                     *( ";" link-extension )

  rel-param       = ( "rel" "=" relation-types )
  anchor-param    = ( "anchor" "=" <"> URI-Reference <"> )
  rev-param       = ( "rev" "=" relation-types )
  hreflang-param  = ( "hreflang" "=" Language-Tag )
  media-param     = ( "media" "=" ( MediaDesc | ( <"> MediaDesc <"> ) ) )
  title-param     = ( "title" "=" quoted-string )
  title-alt-param = ( "title*" "=" ext-value )
  type-param      = ( "type" "=" ( media-type | quoted-mt ) )

Notes:

The ABNF for link-value is misleading. It defines link-value as allowing any number of link-params. However, only upon reading the text of both sections 5.3 and 5.4 does the reader discover that "rel", "media", "title", "title*", and "type" are specifically allowed only once. Further, the text of section 5.2 is ambiguous as to whether or not multiple anchors are allowed.
--VERIFIER NOTES--
Mark Nottingham notes:

###

The proposed ABNF makes ordering significant, which is NOT specified or intended. ABNF can never capture all of the constraints on syntax; that's why we have prose.

###

Errata ID: 4344
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Rushforth
Date Reported: 2015-04-22
Rejected by: Barry Leiba
Date Rejected: 2015-04-22

Section 5 says:

media-type     = type-name "/" subtype-name
quoted-mt      = <"> media-type <">

It should say:

media-type = type-name "/" subtype-name
quoted-mt  = <"> type-name "/" subtype-name 
    *( OWS ";" OWS parameter )<">

Notes:

The text as it stands excludes the possibility of including media type parameters. https://tools.ietf.org/html/rfc6838#section-4.3

Suggested ABNF above adapted from https://tools.ietf.org/html/rfc7231#section-5.3.2
--VERIFIER NOTES--
For better or worse, doing it this way was an explicit decision when the document was developed, so this doesn't qualify as errata. Issues are being collected for a possible 5988bis, and this can be added and discussed there:
https://github.com/mnot/I-D/issues?q=is%3Aopen+is%3Aissue+label%3Arfc5988bis

Errata ID: 2596
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Andy Mabbett
Date Reported: 2010-10-29
Rejected by: Peter Saint-Andre
Date Rejected: 2010-11-18

Section nonspecific says:

n/a

It should say:

n/a

Notes:

Ignores prior art, such as http://wiki.whatwg.org/wiki/RelExtensions (for example, rel-accessibility)
--VERIFIER NOTES--
Peter: It was never the intent of this document to register existing link relations, therefore the document is not in error.

RFC 5996, "Internet Key Exchange Protocol Version 2 (IKEv2)", September 2010

Note: This RFC has been obsoleted by RFC 7296

Note: This RFC has been updated by RFC 5998, RFC 6989

Source of RFC: ipsecme (sec)

Errata ID: 3718
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Gerald Smith
Date Reported: 2013-09-04
Rejected by: Stephen Farrell
Date Rejected: 2014-06-03

Section 3.15.3 says:

A client can be assigned an IPv6 address using the
INTERNAL_IP6_ADDRESS Configuration payload. A minimal exchange might
look like this:

CP(CFG_REQUEST) =
INTERNAL_IP6_ADDRESS()
INTERNAL_IP6_DNS()
TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

CP(CFG_REPLY) =
INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)
INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44)
TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5)
TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

It should say:

CP(CFG_REPLY) =
INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)
INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44)
TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5)
TSr = (0, 0-65535, 2001:DB8:0:1:: - 2001:DB8:0:1:FFFF:FFFF:FFFF:FFFF)

Notes:

The INTERNAL_IP6_ADDRESS returned in the CFG_REPLY is a 64 bit subnet, but the TSr returned in the CFG_REPLY shows a 0 bit subnet instead of the 64 bit subnet.

Kathleen told me to reject this! (Based on ipsecme list discussion.)
--VERIFIER NOTES--
Kathleen told me to!

RFC 6020, "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", October 2010

Source of RFC: netmod (ops)

Errata ID: 4285
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Cesar Crusius
Date Reported: 2015-03-02
Rejected by: Benoit Claise
Date Rejected: 2015-03-10

Section 12 says:

revision-date-stmt = revision-date-keyword sep revision-date stmtend

It should say:

revision-date-stmt =
    revision-date-keyword sep revision-date optsep stmtend

Notes:

Allow spaces between the date string and the statement's end.
--VERIFIER NOTES--
This errata is now covered by the updated errata 4283

Errata ID: 5272
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Bob Harold
Date Reported: 2018-03-02
Rejected by: Benoit Claise
Date Rejected: 2018-03-06

Section 7.18.1 says:

   In order for a device to implement a feature that is dependent on any
   other features (i.e., the feature has one or more "if-feature" sub-
   statements), the device MUST also implement all the dependant
   features.

It should say:

   In order for a device to implement a feature that is dependent on any
   other features (i.e. the feature is a sub-statement of another 
   "if-feature" statement), the device MUST also implement all the 
   dependent features.

Notes:

The direction of the dependency is stated backwards.
Consider for example:

if-feature aaa;
statements ...;
if-feature bbb;

This should allow feature aaa to exist without feature bbb.
bbb should depend on aaa, but aaa should not depend on bbb
--VERIFIER NOTES--
The current text is correct, according to Kent Watsen

Errata ID: 4291
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Cesar Crusius
Date Reported: 2015-03-07
Rejected by: Benoit Claise
Date Rejected: 2015-03-10

Section 12 says:

   deviate-not-supported-stmt =
                         deviate-keyword sep
                         not-supported-keyword optsep
                         (";" /
                          "{" stmtsep
                          "}") 

It should say:

   deviate-not-supported-stmt =
                         deviate-keyword sep
                         not-supported-keyword
                         stmtend

Notes:

The rule is not incorrect, but unnecessarily replicates 'stmtend' within it.
--VERIFIER NOTES--
This is already fixed in draft-ietf-netmod-rfc6020bis-04.

Since this is not really a bug, I don't know if it is worth the effort
to accept this errata.

RFC 6029, "A Survey on Research on the Application-Layer Traffic Optimization (ALTO) Problem", October 2010

Source of RFC: IRTF

Errata ID: 3099
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivica Rimac
Date Reported: 2012-01-30
Rejected by: Lars Eggert

Section 2.1 says:

In such a technique, given a cost function C, a set 
of vertexes V and their corresponding edges, the triangle inequality 
holds if for any triple {a, b, c} in V, C(a, c) is always less than 
or equal to C(a, g) + C(b, c).

It should say:

In such a technique, given a cost function C, a set 
of vertices V and their corresponding edges, the triangle inequality 
holds if for any triple {a, b, c} in V, C(a, c) is always less than 
or equal to C(a, b) + C(b, c).

Notes:

"vertexes" or "vertices" is an acceptable plural form of "vertex".

RFC 6030, "Portable Symmetric Key Container (PSKC)", October 2010

Source of RFC: keyprov (sec)

Errata ID: 3369
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Simon Josefsson
Date Reported: 2012-10-03
Rejected by: Sean Turner
Date Rejected: 2013-03-16

Section 4.3.1 says:

   <Manufacturer>:  This element indicates the manufacturer of the
      device.  Values for the <Manufacturer> element MUST be taken from
      either [OATHMAN] prefixes (i.e., the left column) or from the IANA
      Private Enterprise Number Registry [IANAPENREG], using the
      Organization value.  When the value is taken from [OATHMAN],
      "oath."  MUST be prepended to the value (e.g., "oath.<prefix value
      from [OATHMAN]>").  When the value is taken from [IANAPENREG],
      "iana."  MUST be prepended to the value (e.g., "iana.<Organization
      value from [IANAPENREG]>").

It should say:

   <Manufacturer>:  This element indicates the manufacturer of the
      device.  Values for the <Manufacturer> element MAY be taken from
      either [OATHMAN] prefixes (i.e., the left column) or from the IANA
      Private Enterprise Number Registry [IANAPENREG], using the
      Organization value.  When the value is taken from [OATHMAN],
      "oath."  MUST be prepended to the value (e.g., "oath.<prefix value
      from [OATHMAN]>").  When the value is taken from [IANAPENREG],
      "iana."  MUST be prepended to the value (e.g., "iana.<Organization
      value from [IANAPENREG]>").

Notes:

The only thing changed is relaxing MUST to MAY.

The requirement that manufacturer strings begin with "oath." and "iana." is often ignored by implementations/deployments. Further, none of the examples throughout the document conform to the syntax. While we could regard these as implementation/deployment and editorial document bugs, I would argue that we could just as well relax the technical requirement because there appears to be no harm in allowing free-form text. This is what people appear to be using out there already.

Examples of non-conforming <Manufacturer> fields out there:
http://tools.ietf.org/html/draft-hoyer-keyprov-pskc-algorithm-profiles-01
http://download.gooze.eu/otp/seeds/20120919-test001-4282.xml
--VERIFIER NOTES--
Changing the requirement from MUST to MAY is not appropriate to do in an errata. Please produce a draft and we can see whether your change is acceptable to the rest of the IETF.

RFC 6044, "Mapping and Interworking of Diversion Information between Diversion and History-Info Headers in the Session Initiation Protocol (SIP)", October 2010

Note: This RFC has been obsoleted by RFC 7544

Source of RFC: INDEPENDENT

Errata ID: 3564
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Jayaraj Wilson
Date Reported: 2013-03-25
Rejected by: Nevil Brownlee
Date Rejected: 2014-02-12

Section 7.1 says:

Mapped into:
History-Info:
<sip: diverting_user1_address; privacy=none >; index=1,
<sip: diverting_user2_address; cause=408?privacy=history>;index=1.1,
<sip: diverting_user3_address; cause=486?privacy=none>;index=1.1.1,
<sip: last_diverting_target; cause=302>;index=1.1.1.1

It should say:

Mapped into:
History-Info:
<sip: diverting_user1_address; privacy=none >; index=1,
<sip: diverting_user2_address; cause=408?privacy=history>;index=1.1,
<sip: diverting_user3_address; cause=486?privacy=none>;index=1.1.1,
<sip: last_diverting_target; cause=302?privacy=none>;index=1.1.1.1

Notes:

Section 5 for Diversion to History Info mapping states
A last History-Info entry is created and contains:
- if a privacy parameter is present in the top-most Diversion entry,
then a Privacy header could be escaped in the History-Info header
as described above.

So if this is rule is applied then the last History Info entry must contain a privacy param corresponding to the top most Diversion and in this case it maps to none. On the other hand if this example is to be considered correct then we ought to modify section 5 to have no privacy for the last hi entry.
--VERIFIER NOTES--
In RFC 6044 section 7.1, the last History-Info line does not
correspond to the last diverting user (similar to the top-most
diversion entry), but to the last diversion TARGET. We don't have the
privacy of the last call forwarding destination - that's why there is
no privacy associated to this address.

The privacy info associated to diverting users 1, 2 and 3 are still
associated to these user addresses in the History-Info header.

Errata ID: 2606
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hadriel Kaplan
Date Reported: 2010-11-04
Rejected by: Nevil Brownlee
Date Rejected: 2014-03-06

Section 2.2.1 says:

|       |       |INVITE |       |       |       |     |       |        |
|       |       |------>|       |       |       |     |       |        |
|       |       |History-Info:  |       |       |     |       |        |
|       |       |<sip:proxyP1>; index=1,|       |     |       |        |
|       |       |<sip:userB>; index=1.1 |       |     |       |        |
|       |       |<sip:userC>; cause=302; index=1.1.1  |       |        |

It should say:

|       |       |INVITE |       |       |       |     |       |        |
|       |       |------>|       |       |       |     |       |        |
|       |       |History-Info:  |       |       |     |       |        |
|       |       |<sip:proxyP1>; index=1,|       |     |       |        |
|       |       |<sip:userB>; index=1.1 |       |     |       |        |
|       |       |<sip:userC?Reason=SIP%3Bcause%3D302>;index=1.1.1      |

Notes:

The "cause" field is not a Hist-Info header param, it's a param of a Reason header embedded in the URI.
Furthermore, the example shows things like "userC", while obviously it has to be something like "userC@host.com" to be a valid SIP URI.
--VERIFIER NOTES--
See erratum 3077, which corrects this erratum (2606)

Errata ID: 2607
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hadriel Kaplan
Date Reported: 2010-11-04
Rejected by: Nevil Brownlee
Date Rejected: 2014-03-06

Section 7 says:

   History-Info:
   <sip: diverting_user1_address; privacy=none >; index=1,
   <sip: diverting_user2_address; cause=408?privacy=history>;index=1.1,
   <sip: diverting_user3_address; cause=486?privacy=none>;index=1.1.1,
   <sip: last_diverting_target; cause=302>;index=1.1.1.1

7.2.  Example with History-Info Header Changed into Diversion Header

   History-Info:
   <sip: diverting_user1_address?privacy=history >; index=1,
   <sip: diverting_user2_address; cause=302? privacy=none>;index=1.1,
   <sip: last_diverting_target; cause=486>;index=1.1.1

It should say:

   History-Info:
   <sip:diverting_user1_address?Privacy=none>;index=1,
   <sip:diverting_user2_address?Reason=SIP%3Bcause%3D408?privacy=
      history>; index=1.1,
   <sip:diverting_user3_address?Reason=SIP%3Bcause%3D486?privacy=none>;
     index=1.1.1,
   <sip:last_diverting_target?Reason=SIP%3Bcause%3D302>;index=1.1.1.1

7.2.  Example with History-Info Header Changed into Diversion Header

   History-Info:
   <sip: diverting_user1_address?privacy=history >; index=1,
   <sip: diverting_user2_address?Reason=SIP%3Bcause%3D302&Privacy=none>;
     index=1.1,
   <sip: last_diverting_target?Reason=SIP%3Bcause%3D486>;index=1.1.1

Notes:

I know RFC 4244 makes this error all over the place, but the "cause" field is not a URI parameter. It is a header parameter of the Reason header field, and per the ABNF of RFC4244 Hist-Info, the Reason header is embedded into the URI, including its cause parameter - in other words, the cause field is a parameter of an embedded header inside a URI, as shown in the correction.

This error is made in section 2.2.1, 3.1, 5, 7.1, 7.2, and 7.3 of this RFC 6044.
--VERIFIER NOTES--
RFC author considers this erratum to be incorrect.

RFC 6052, "IPv6 Addressing of IPv4/IPv6 Translators", October 2010

Source of RFC: behave (tsv)

Errata ID: 5415
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Dale R. Worley
Date Reported: 2018-07-01
Rejected by: Magnus Westerlund
Date Rejected: 2020-01-16

Section 2.2 says:

   Bits 64 to 71 of the address are reserved for compatibility with the
   host identifier format defined in the IPv6 addressing architecture
   [RFC4291].  These bits MUST be set to zero.  When using a /96
   Network-Specific Prefix, the administrators MUST ensure that the bits
   64 to 71 are set to zero.  A simple way to achieve that is to
   construct the /96 Network-Specific Prefix by picking a /64 prefix,
   and then adding 4 octets set to zero.

[and other parts of the text]

It should say:

[This paragraph should be removed and corresponding changes made to
the rest of section 2.2.]

Notes:

Section 2.2 says that bits 64 to 71 of the Ipv6 address MUST be set to zero and references RFC 4291 as the authority. However, RFC 7136 says:

In particular, RFC 4291 defines a method by which the
Universal and Group bits of an IEEE link-layer address are mapped
into an IPv6 unicast interface identifier. This document clarifies
that those two bits are significant only in the process of deriving
interface identifiers from an IEEE link-layer address, and it updates
RFC 4291 accordingly.

Thus, the text I've referenced in RFC 6052 is to enforce a requirement that was not correctly applied, and RFC 6052's statement about bits 64 to 71 should be removed. In addition, there are consequent changes in other parts of RFC 6052, including Figure 1, where the "u" field should be removed from the address formats.
--VERIFIER NOTES--
AD (Magnus Westerlund): A clarification by a later RFC that impacts this RFC is not an errata. The change appears to require a consensus decision on how to handle it. Thus rejected on formal grounds, should be considered if document is revised in the future.

Errata ID: 5547
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Fred Baker
Date Reported: 2018-11-06
Rejected by: Mirja Kühlewind
Date Rejected: 2018-11-26

Section 3.1 says:

   The Well-Known Prefix MUST NOT be used to represent non-global IPv4
   addresses, such as those defined in [RFC1918] or listed in Section 3
   of [RFC5735].  Address translators MUST NOT translate packets in
   which an address is composed of the Well-Known Prefix and a non-
   global IPv4 address; they MUST drop these packets.

It should say:

The paragraph should be removed.

Notes:

IPv4 packets with private addresses are routinely translated to IPv4 packets with global addresses in NAT44. If a 464XLAT CLAT (stateless NAT64) cannot translate a private address to an IPv6 /96 prefix with that address as an IID (or whatever it's called), then the packet may not be translated to an IPv4 packet with a global address by the 464XLAT PLAT (stateful NAT64). This changes the intent of the sender, and in so doing violates the end to end principle. Practically speaking, it means that a network that uses 464XLAT or MAP-T with IPv4 in the subscriber and translating to IPv4 via NAT64 into the IPv4 Internet, it forces the network or the subscriber to purchase global address space. That's just silly. Let the user use private address space in the home or whatever.
--VERIFIER NOTES--
The orginial text was intended at time of publication. If this is not current anymore, the RFC needs to be updated by an IETF consensus doc.

Errata ID: 5984
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Jordi Palet Martinez
Date Reported: 2020-02-16
Rejected by: Magnus Westerlund
Date Rejected: 2020-02-17

Section 3.3 says:

Organizations deploying stateless IPv4/IPv6 translation SHOULD assign a Network-Specific Prefix to their IPv4/IPv6 translation service.

It should say:

Organizations deploying stateless IPv4/IPv6 translation SHOULD assign a Network-Specific Prefix for the exclusive use of their IPv4/IPv6 translation service.

Notes:

This seems obvious but is not. The NSP must only be used for the translation service. If the NSP is used only, for example in an enterprise network, in the LANs, and the translator allows it, it may create conflicts, as the resulting IPv6 address (NSP+IPv4 address) may be the same as a host inside the LAN has been configured with (either manually, or with SLAAC, DHCPv6), etc.

It has been confirmed that at least one vendor already realized this and the implementation doesn't work if the prefix is used both for the translator service and one of the LANs, but there is no explicit documentation on that. So if configured, the box doesn't work, but doesn't report is an an "invalid" config.
--VERIFIER NOTES--
This Errata requests requires WG consensus decision and thus outside of the Errata process. The specification does not prevent what is propsed as the appropriate way of assigning a NSP. The RFC does not restrict the usage, and as commented on the mailing list, there are ways to make even using the same prefix for both clients and the NAT64 device.

RFC 6056, "Recommendations for Transport-Protocol Port Randomization", January 2011

Source of RFC: tsvwg (wit)

Errata ID: 3739
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Jean-Yves Migeon
Date Reported: 2013-09-26
Rejected by: Martin Stiemerling
Date Rejected: 2013-09-30

Section Appendix A says:

   NetBSD 5.0.1 does not obfuscate its ephemeral port numbers.  It
   selects ephemeral port numbers from the range 49152-65535, starting
   from port 65535, and decreasing the port number for each ephemeral
   port number selected [NetBSD].

It should say:

   NetBSD 5.0.1 does not obfuscate its ephemeral port numbers.  It
   selects ephemeral port numbers from the range 49152-65535, starting
   from port 65535, and decreasing the port number for each ephemeral
   port number selected [NetBSD].

   NetBSD 6.0 supports RFC 6056 Algorithms 1, 2, 3, 4 and 5 with port
   numbers from the range 49152-65535 as documented in [NetBSD-RFC6056].

Notes:

The project implemented the RFC 6056 algorithms last year to obfuscate the ephemeral port numbers.

[NetBSD-RFC6056] reference is:
The NetBSD Project, "NetBSD Miscellaneous Information Manual -- RFC 6056, Randomization Algorithms", man page - section 7, August 2011.
--VERIFIER NOTES--
The proposed text is not an errata but an addendum which isn't handled via the errata procedures.

RFC 6062, "Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations", November 2010

Source of RFC: behave (tsv)

Errata ID: 3467
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Nazmus Shakeeb
Date Reported: 2013-01-22
Rejected by: Magnus Westerlund
Date Rejected: 2021-01-13

Section 5.2. says:

   Otherwise, the server MUST initiate an outgoing TCP connection.  The
   local endpoint is the relayed transport address associated with the
   allocation. 

It should say:

   Otherwise, the server MUST initiate an outgoing TCP connection.  This 
   connection MUST NOT be made using the relayed transport address 
   associated with the allocation.

Notes:

if you send connect request using the allocated port then port the will not be in listen mode and this will prevent incoming tcp connection on this port.

this will cause major problem while doing ice check. The effect is so bad that

it may cause 97% call failure while using turn tcp behind nat.
--VERIFIER NOTES--
To my understanding this errata is due to implementation limitation or error. One those systems I have knowledge of you can create a TCP connection outgoing from the same TCP port that you have a listener.

RFC 6067, "BCP 47 Extension U", December 2010

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 4363
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Ziegast
Date Reported: 2015-05-11
Rejected by: Barry Leiba
Date Rejected: 2015-05-12

Section All says:

This registration is invalid because it attempts to
impose restrictions on field ordering the governing
BCP47 has as illegal for extension subtag
canonicalization. The subtags are limited to 8
characters, and any subfields of a subtag must use a
DIGIT or ALPHA that is not a valid subfield character
as separator, not DASH as specified, to maintain a
particular subfield order.

It should say:

Not correctable, must be reformulated and a new RFC submitted.

Notes:

--VERIFIER NOTES--
BCP 47 requires that extensions have a canonical form. There is no restriction on subtag ordering in an extension imposed by BCP 47, but an extension can specify such an order (in this case it does). Subtags in this RFC are separated by DASH and the dash is not part of any subtag. Unlike the base language tag, there is interplay between subtags, but this is not the same thing as the submitter implies. There exist important implementations that depend on this.

RFC 6068, "The 'mailto' URI Scheme", October 2010

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 3491
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Stefan Ganzer
Date Reported: 2013-02-20
Rejected by: Pete Resnick
Date Rejected: 2013-03-08

Section 2 says:

      domain       = dot-atom-text / "[" *dtext-no-obs "]"

It should say:

      domain       = dot-atom-text

Notes:

Mailto URI has a hier-part that is either path-rootless or path-empty,
with an optional query component (see the syntax from RFC 3986 below).
In the path-rootless part, only characters in the set <pchar> are allowed.
Therefore the <domain> rule violates the general URI syntax, as it uses
the characters "[" and "]", which are not in <pchar>, to delimit a domain literal.

URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
hier-part = "//" authority path-abempty
/ path-absolute
/ path-rootless
/ path-empty
path-rootless = segment-nz *( "/" segment )
segment = *pchar
segment-nz = 1*pchar
query = *( pchar / "/" / "?" )
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
--VERIFIER NOTES--
The "Corrected Text" suggested by the reporter is incorrect. There are also several things in dot-atom-text which are also not in <pchar> ("#", "/", "?", "^", "`", "{", "|", "}"), so leaving dot-atom-text in place would not address the concern of the reporter. RFC 6068's answer is to simply say that, ABNF notwithstanding, some of the characters will need to be percent-encoded:

1. A number of characters that can appear in <addr-spec> MUST be
percent-encoded. These are the characters that cannot appear in
a URI according to [STD66] as well as "%" (because it is used for
percent-encoding) and all the characters in gen-delims except "@"
and ":" (i.e., "/", "?", "#", "[", and "]"). Of the characters
in sub-delims, at least the following also have to be percent-
encoded: "&", ";", and "=". Care has to be taken both when
encoding as well as when decoding to make sure these operations
are applied only once.

Now, this may have been a bogus way to do it (because you've got an ABNF which then has to be re-encoded to agree with generic URI syntax), but it was clearly agreed to when this document was published. Something may be wrong here, but this is not appropriate for a simple erratum.

RFC 6072, "Certificate Management Service for the Session Initiation Protocol (SIP)", February 2011

Source of RFC: sip (rai)

Errata ID: 2988
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Olle E. Johansson
Date Reported: 2011-10-10
Rejected by: Robert Sparks
Date Rejected: 2012-11-04

Section 8 says:

   The [RFC4474] authentication service defined a signature algorithm
   based on SHA-1 called rsa-sha1.  This specification adds a signature
   algorithm that is roughly the same but based on SHA-256 and called
   rsa-sha256.

It should say:

   The [RFC4474] authentication service defined a signature algorithm
   based on SHA-1 called rsa-sha1.  This specification adds a signature
   algorithm that is roughly the same but based on SHA-256 and called
   rsa-sha256. This is an update of RFC 4474.

Notes:

The Masthead doesn't indicate clearly that this RFC updates 4474 and thus the IETF tools web site doesn't indicate that 4474 is updated.
--VERIFIER NOTES--
Errata should not be used for changing draft metadata (it would not change the links you are looking at on the IETF tools website for example).

RFC 6083, "Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)", January 2011

Note: This RFC has been updated by RFC 8996

Source of RFC: tsvwg (wit)

Errata ID: 6323
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Claudio Porfiri
Date Reported: 2020-11-04
Rejected by: Martin Duke
Date Rejected: 2020-11-06

Section 1.1 says:

The maximum user message size is 2^14 bytes, which is the DTLS
      limit.

It should say:

The maximum user message size is limited by the DTLS implementation.

Notes:

TLS and DTLS handshake messages can be quite large (in theory up to 2^24-1 bytes, in practice many kilobytes).
See https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/?include_text=1
section 3.3 as reference
--VERIFIER NOTES--
The citation in the note clearly refers to handshake messages, not application data records. RFC 4347 and draft-ietf-tls-dtls13 clearly state that the limit is 2^14.

RFC 6093, "On the Implementation of the TCP Urgent Mechanism", January 2011

Note: This RFC has been obsoleted by RFC 9293

Source of RFC: tcpm (wit)

Errata ID: 4312
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Justin Yirka
Date Reported: 2015-03-24
Rejected by: Martin Stiemerling
Date Rejected: 2015-04-21

Section 3.1 says:

Unfortunately, virtually all TCP implementations process TCP urgent
indications differently.  By default, the last byte of "urgent data"
is delivered "out of band" to the application.  That is, it is not
delivered as part of the normal data stream [UNPv1].  For example,
the "out-of-band" byte is read by an application when a recv(2)
system call with the MSG_OOB flag set is issued.

It should say:

Unfortunately, virtually all TCP implementations process TCP urgent
indications differently.

For example, by default in particular UNIX implementations, the last
byte of "urgent data" is delivered "out of band" to the application.
That is, it is not delivered as part of the normal data stream [UNPv1].
For example, the "out-of-band" byte is read by an application when a
recv(2) system call with the MSG_OOB flag set is issued.

Notes:

The first and latter statements are contradictory, as a default is unlikely to apply when "virtually all" implementations process differently.
This correction to include "in particular UNIX implementations" would be appropriate at many points throughout the document in order to differentiate references to implementation specific features and terminology from references to terminology established in prior RFCs.
--VERIFIER NOTES--
Reading the text in a flow isn't giving the contradiction that there is a contradiction.

RFC 6106, "IPv6 Router Advertisement Options for DNS Configuration", November 2010

Note: This RFC has been obsoleted by RFC 8106

Source of RFC: 6man (int)

Errata ID: 4864
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Robin Johnson
Date Reported: 2016-11-14
Rejected by: Suresh Krishnan
Date Rejected: 2017-01-29

Section 5.2. says:

Length:
8-bit unsigned integer.  The length of the option
(including the Type and Length fields) is in units of
8 octets.  The minimum value is 2 if at least one
domain name is contained in the option.  The Length
field is set to a multiple of 8 octets to accommodate
all the domain names in the field of Domain Names of
DNS Search List.

It should say:

Length:
8-bit unsigned integer.  The length of the option
(including the Type and Length fields) is in units of
8 octets.  The minimum value is 2 if at least one
domain name is contained in the option.  The Length
field is set to a multiple of 8 octets to accommodate
all the domain names in the field of Domain Names of
DNS Search List.

The exact maximum value supported by a given network
is dictated by the MTU of the link, because the
Router Advertisement MUST NOT be fragmented as per
RFC6980#section5. The lowest possible MTU of 1280
results in a lower bound for the maximum value of 148
(representing 1192 octets).

Notes:

While the submitter's point is valid, there is not much that can be done on a per-option basis. Even if this option is sized so that it does not result in the fragmentation of the RA message, there might be other options that do. That is why the restriction for non-fragmentation is specified in a separate document and not in each document that defines an ND option.
--VERIFIER NOTES--
While the submitter's point is valid, there is not much that can be done on a per-option basis. Even if this option is sized so that it does not result in the fragmentation of the RA message, there might be other options that do. That is why the restriction for non-fragmentation is specified in a separate document and not in each document that defines an ND option.

RFC 6137, "The Network Trouble Ticket Data Model (NTTDM)", February 2011

Source of RFC: INDEPENDENT

Errata ID: 2728
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-02-23
Rejected by: Nevil Brownlee
Date Rejected: 2011-03-01

Section 11 says:

11.  References

11.1.  Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]   World Wide Web Consortium, "Extensible Markup Language
         (XML) 1.0 (Fifth Edition)", W3C Recommendation, 26 November
         2008, <http://www.w3.org/TR/2008/REC-xml-20081126>.

   [3]   World Wide Web Consortium, "XML Schema Part 0: Primer Second
         Edition", W3C Recommendation, 28 October 2004,
         <http://www.w3.org/TR/2004/REC-xmlschema-0-20041028/>.

   [4]   World Wide Web Consortium, "XML Schema Part 1: Structures
         Second Edition", W3C Recommendation, 28 October 2004,
         <http://www.w3.org/TR/xmlschema-1/>.

   [5]   World Wide Web Consortium, "XML Schema Part 2: Datatypes Second
         Edition", W3C Recommendation, 28 October 2004,
         <http://www.w3.org/TR/xmlschema-2/>.

   [6]   World Wide Web Consortium, "Namespaces in XML 1.0 (Third
         Edition)", W3C Recommendation, 8 December 2009,
         <http://www.w3.org/TR/2009/REC-xml-names-20091208/>.

   [7]   Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
         January 2004.

11.2.  Informative References

   [8]   Enabling Grids for E-sciencE, http://www.eu-egee.org/.

   [9]   Enabling Grids for E-sciencE, "ENOC, EGEE Network Operation
         Centre", http://technical.eu-egee.org/index.php?id=353.

   [10]  Rumbaugh, J., Jacobson, I., and G. Booch, "The Unified Modeling
         Language Reference Manual," ISBN 020130998X, Addison-Wesley,
         1998.

   [11]  Johnson, D., "NOC Internal Integrated Trouble Ticket System
         Functional Specification Wishlist ("NOC TT REQUIREMENTS")",
         RFC 1297, January 1992.

It should say:

11.  References

11.1.  Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]   World Wide Web Consortium, "Extensible Markup Language
         (XML) 1.0 (Fifth Edition)", W3C Recommendation, 26 November
         2008, <http://www.w3.org/TR/2008/REC-xml-20081126>.

   [3]   World Wide Web Consortium, "XML Schema Part 0: Primer Second
         Edition", W3C Recommendation, 28 October 2004,
         <http://www.w3.org/TR/2004/REC-xmlschema-0-20041028/>.

   [4]   World Wide Web Consortium, "XML Schema Part 1: Structures
         Second Edition", W3C Recommendation, 28 October 2004,
         <http://www.w3.org/TR/xmlschema-1/>.

   [5]   World Wide Web Consortium, "XML Schema Part 2: Datatypes Second
         Edition", W3C Recommendation, 28 October 2004,
         <http://www.w3.org/TR/xmlschema-2/>.

   [6]   World Wide Web Consortium, "Namespaces in XML 1.0 (Third
         Edition)", W3C Recommendation, 8 December 2009,
         <http://www.w3.org/TR/2009/REC-xml-names-20091208/>.

11.2.  Informative References

   [7]   Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
         January 2004.

   [8]   Enabling Grids for E-sciencE, http://www.eu-egee.org/.

   [9]   Enabling Grids for E-sciencE, "ENOC, EGEE Network Operation
         Centre", http://technical.eu-egee.org/index.php?id=353.

   [10]  Rumbaugh, J., Jacobson, I., and G. Booch, "The Unified Modeling
         Language Reference Manual," ISBN 020130998X, Addison-Wesley,
         1998.

   [11]  Johnson, D., "NOC Internal Integrated Trouble Ticket System
         Functional Specification Wishlist ("NOC TT REQUIREMENTS")",
         RFC 1297, January 1992.

Notes:

Here RFC 3688 should be rather Informative reference, since it provides the background information on the registry being modified.
--VERIFIER NOTES--
3688 is used here to specify the registry this XML schema is to be registered in.
It's as much a normative reference as that to 2119.

RFC 6143, "The Remote Framebuffer Protocol", March 2011

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rai

Errata ID: 2745
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-03-07
Rejected by: Robert Sparks
Date Rejected: 2011-03-08

Section 11 says:

11. References

11.1. Normative References

   [RFC1950]  Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format
              Specification version 3.3", RFC 1950, May 1996.

   [RFC1951]  Deutsch, P., "DEFLATE Compressed Data Format Specification
              version 1.3", RFC 1951, May 1996.

   [XLIBREF]  Nye, A., "XLIB Reference Manual R5", June 1994.

11.2. Informative References

   [RFC4254]  Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
              Connection Protocol", RFC 4254, January 2006.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

It should say:

11. References

11.1. Normative References

   [RFC1950]  Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format
              Specification version 3.3", RFC 1950, May 1996.

   [RFC1951]  Deutsch, P., "DEFLATE Compressed Data Format Specification
              version 1.3", RFC 1951, May 1996.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [XLIBREF]  Nye, A., "XLIB Reference Manual R5", June 1994.

11.2. Informative References

   [RFC4254]  Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
              Connection Protocol", RFC 4254, January 2006.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

Notes:

--VERIFIER NOTES--

RFC 6147, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", April 2011

Source of RFC: behave (tsv)

Errata ID: 3236
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Andrews
Date Reported: 2012-05-30
Rejected by: Wes Eddy
Date Rejected: 2012-09-13

Section 5.5 says:

An application that wants to perform validation 
on its own should use the CD bit.

It should say:

[Section 5.5 needs to be completely re analysed,]

Notes:

Section 5.5 is written around the assumption that a validating stub resolver will be setting CD=1 as well as DO=1. There is no such requirement RFC 4035 and in fact setting both CD=1 and DO=1 leaves the stub resolver vulnerable to answers from authoritative servers for the zone that are serving a stale copy of the zone and spoofed answers being sent to the DNS64 server.

Non CD=1 queries result in the DNS64 server in its recursive roll, filtering out, cryptographically bad answers.

DO=1 alone should disable synthesis.
--VERIFIER NOTES--
http://www.ietf.org/iesg/statement/errata-processing.html
says:
Changes that are clearly modifications to the intended consensus, or
involve large textual changes, should be Rejected.

RFC 6149, "MD2 to Historic Status", March 2011

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 2744
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-03-07
Rejected by: Robert Sparks
Date Rejected: 2011-03-08

Section 9 says:

9. Informative References

   [HASH-Attack] Hoffman, P. and B. Schneier, "Attacks on Cryptographic
                 Hashes in Internet Protocols", RFC 4270, November 2005.

   [KMM2010]     Knudsen, L., Mathiassen, J., Muller, F., and Thomsen,
                 S., "Cryptanalysis of MD2", Journal of Cryptology,
                 23(1):72-90, 2010.

   [KNMA2005]    Knudsen, L., and J. Mathiassen, "Preimage and Collision
                 Attacks on MD2", FSE 2005.

   [MD2]         Kaliski, B., "The MD2 Message-Digest Algorithm", RFC
                 1319, April 1992.

It should say:

9. References

9.1. Normative References

   [MD2]         Kaliski, B., "The MD2 Message-Digest Algorithm", RFC
                 1319, April 1992.

9.2. Informative References

   [HASH-Attack] Hoffman, P. and B. Schneier, "Attacks on Cryptographic
                 Hashes in Internet Protocols", RFC 4270, November 2005.

   [KMM2010]     Knudsen, L., Mathiassen, J., Muller, F., and Thomsen,
                 S., "Cryptanalysis of MD2", Journal of Cryptology,
                 23(1):72-90, 2010.

   [KNMA2005]    Knudsen, L., and J. Mathiassen, "Preimage and Collision
                 Attacks on MD2", FSE 2005.

Notes:

--VERIFIER NOTES--

RFC 6152, "SMTP Service Extension for 8-bit MIME Transport", March 2011

Source of RFC: yam (app)

Errata ID: 5646
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: HE Zhixiang
Date Reported: 2019-03-04
Rejected by: Barry Leiba
Date Rejected: 2021-03-01

Section 3 says:

Naturally, the usual SMTP data-stuffing algorithm applies, so that a
content that contains the five-character sequence of
<CR> <LF> <DOT> <CR> <LF>
or a content that begins with the three-character sequence of
<DOT> <CR> <LF>
does not prematurely terminate the transfer of the content.

It should say:

Naturally, the usual SMTP data-stuffing algorithm applies, so that a
content that contains the five-character sequence of
<CR> <LF> <DOT> <CR> <LF>
or a content that begins with the three-character sequence of
<DOT> <CR> <LF>
would prematurely terminate the transfer of the content.

Notes:

RFC 5321, section 4.5.2:
Without some provision for data transparency, the character sequence "<CRLF>.<CRLF>" ends the mail text and cannot be sent by the user.
--VERIFIER NOTES--
The text is referring to original, unprocessed text, and is saying that the example strings will "naturally" have "the usual SMTP data stuffing algorithm" applied to them. As a result, the existence of these strings in the original data will not terminate the transfer because they will be data-stuffed and will no longer appear as termination strings.

The text is correct as written, and the suggested rewrite incorrectly negates the meaning.

RFC 6154, "IMAP LIST Extension for Special-Use Mailboxes", March 2011

Source of RFC: morg (app)

Errata ID: 5431
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bron Gondwana
Date Reported: 2018-07-19
Rejected by: Alexey Melnikov
Date Rejected: 2018-07-26

Section 2 says:

An IMAP server that supports this extension MAY include any or all of
the following attributes in responses to the non-extended IMAP LIST
command.

It should say:

An IMAP server that supports this extension SHOULD include any or all of
the following attributes in responses to the non-extended IMAP LIST
command.

Notes:

There exist clients which send a non-extended LIST command and will correctly display and interact with mailboxes usefully if their special-uses are given in the response.

Because of this, many servers are already replying with the special-use attributes, and there are no known reports of clients being broken by that behaviour. Because of this, the MAY should be raised to a SHOULD, and server implementations should default to turning this on.
--VERIFIER NOTES--
The right way to make this change is to revise the document. MAY was intended at the time of publication.

RFC 6157, "IPv6 Transition in the Session Initiation Protocol (SIP)", April 2011

Source of RFC: sipping (rai)

Errata ID: 2987
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Olle E. Johansson
Date Reported: 2011-10-10
Rejected by: Robert Sparks
Date Rejected: 2011-11-04

Section 3.1 says:

Furthermore, there SHOULD
   exist both IPv6 and IPv4 DNS entries for outbound proxy servers.
   This allows the user agent to query DNS and obtain an IP address most
   appropriate for its use (i.e., an IPv4-only user agent will query DNS
   for A resource records (RRs), an IPv6-only user agent will query DNS
   for AAAA RRs, and a dual-stack user agent will query DNS for all RRs
   and choose a specific network.)

It should say:

Furthermore, there SHOULD
   exist both IPv6 and IPv4 DNS entries for outbound proxy servers.
   This allows the user agent to query DNS and obtain an IP address most
   appropriate for its use (i.e., an IPv4-only user agent will query DNS
   for A resource records (RRs), an IPv6-only user agent will query DNS
   for AAAA RRs, and a dual-stack user agent will query DNS for all RRs
   and choose a specific network.) This is an update to RFC 3263, in which
the client on a dual stack network queries for either A or AAAA.

Notes:

The RFC actually updates RFC 3263 - locating SIP servers - but doesn't make a clear note about it.
--VERIFIER NOTES--
It's not clear that this RFC intended to update 3263, but it does point to an issue in 3261 that should be clarified through a consensus process.

RFC 6176, "Prohibiting Secure Sockets Layer (SSL) Version 2.0", March 2011

Note: This RFC has been updated by RFC 8996

Source of RFC: tls (sec)

Errata ID: 5520
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eugene Adell
Date Reported: 2018-10-11
Rejected by: EKR
Date Rejected: 2018-10-11

Section 2 says:

   o  Sessions can be easily terminated.  A man-in-the-middle can easily
      insert a TCP FIN to close the session, and the peer is unable to
      determine whether or not it was a legitimate end of the session.

It should say:

   o  Sessions can be easily terminated.  A man-in-the-middle can easily
      insert a TCP FIN to close the session, and the peer is unable to
      determine whether or not it was a legitimate end of the session.

   o  The root certificate authority keys are overexposed. The server
      sends only one certificate signed by a root certificate authority,
      which means a frequent use of this authority keys for signing new
      certificates. This use can lead to key loss and the compromise of
      all certificates previously signed including the root certificate.

Notes:

Adding a deficiency.
Recent history showed that well-known authorities could loose their keys and it had a wide impact on security.
SSL 2.0 limits the certificate handshake message to one single certificate, thus making it impossible to send a certificate chain.
A certificate chain doesn't completely prevent key loss, but it gives more protection to the root certificate keys which can be stored and hidden until we need them again, which is much less often than without chaining.



--VERIFIER NOTES--
This isn't an error in the original document. It's new text you want to add.

RFC 6184, "RTP Payload Format for H.264 Video", May 2011

Source of RFC: avt (rai)

Errata ID: 4713
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Iñaki Baz Castillo
Date Reported: 2016-06-17
Rejected by: Francesca Palombini
Date Rejected: 2023-11-07

Section 8.1 says:

profile-level-id:
         A base16 [7] (hexadecimal) representation of the following
         three bytes in the sequence parameter

It should say:

profile-level-id:
         A base16 [7] (hexadecimal) representation of the following
         six bytes in the sequence parameter

Notes:

profile-level-id is composed of three 2-byte length fields.
--VERIFIER NOTES--
The original text is correct; 3 bytes in the binary representation become 6 text characters in base16.

Errata ID: 4714
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Iñaki Baz Castillo
Date Reported: 2016-06-17
Rejected by: Ben Campbell
Date Rejected: 2016-06-21

Section 8.2.2 says:

To simplify the handling and matching of these configurations, the
same RTP payload type number used in the offer SHOULD also be used
in the answer, as specified in [8]

[8] points to RFC 3264 "An Offer/Answer Model with the Session
Description Protocol (SDP)"

Notes:

The above statement is wrong. RFC 3264 does not mandate the same payload
type in both the offer and the answer. In fact, RFC 3264 section 5.1 states:

For sendonly RTP streams, the payload type
numbers indicate the value of the payload type field in RTP packets
the offerer is planning to send for that codec. For sendrecv RTP
streams, the payload type numbers indicate the value of the payload
type field the offerer expects to receive, and would prefer to send.

However, for sendonly and sendrecv streams, the answer might indicate
different payload type numbers for the same codecs, in which case,
the offerer MUST send with the payload type numbers from the answer.
--VERIFIER NOTES--
Rejected based on discussion on avtcore and payload lists. (3264 does in fact include the SHOULD).

RFC 6204, "Basic Requirements for IPv6 Customer Edge Routers", April 2011

Note: This RFC has been obsoleted by RFC 7084

Source of RFC: v6ops (ops)

Errata ID: 3175
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Sathyanarayana Venkataramanappa
Date Reported: 2012-04-04
Rejected by: RonBonica
Date Rejected: 2012-04-16

Section 4.2 says:

WPD-3:  The IPv6 CE router MUST be prepared to accept a delegated
           prefix size different from what is given in the hint.  If the
           delegated prefix is too small to address all of its
           interfaces, the IPv6 CE router SHOULD log a system management
           error.

It should say:

WPD-3:  The IPv6 CE router MUST be prepared to accept a delegated
           prefix size different from what is given in the hint.  If the
           delegated prefix is too small to address all of its
           interfaces or delegated prefix size is greater than /64, the 
           IPv6 CE router SHOULD log a system management
           error.

Notes:

Stateless Address Auto configuration uses 64 bit long EUI-64. If Delegated prefix size obtained on the wan side is greater than /64. This Prefix cannot be used on Lan side nodes to create SLAAC address using EUI-64
--VERIFIER NOTES--
RFC 6204 is about to be obsoleted by draft-ietf-v6ops-6204bis, which entered WG last call this weekend. So, fixing 6204 won't help much.

Please post a message to the V6OPS mailing list making the point that you make in the errata. If the WG agrees, the change will be made in the bis document.

RFC 6214, "Adaptation of RFC 1149 for IPv6", April 2011

Source of RFC: INDEPENDENT

Errata ID: 2854
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2011-07-06
Rejected by: Nevil Brownlee
Date Rejected: 2013-05-27

Section 3.2 says:

The whole section about the frame format and the lack of 
Layer2-type, and the technical choice behind it.

It should say:

RFC 6274, section 3.1 explicitely forbids this technique and 
requires that an IP implementation checks the version number, 
which will prevent RFC 6214 to work.

Notes:

Yes, I know that this RFC was published on April 1st... Nevertheless, this is an interesting technical point.

--VERIFIER NOTES--
RFC 6274 was published in July 2011, three months after RFC 6214.
Further, RFC 6274 is only Informational. The recommendation that you
mention asserts that "in practice different versions of IP are
identified by a different Protocol Type (e.g., EtherType in the case
of Ethernet) number in the link-layer protocol header." That assertion
is untrue of conforming implementations of RFC 6214, which, apparently,
the authors of RFC 6274 failed to consider.

RFC 6241, "Network Configuration Protocol (NETCONF)", June 2011

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

Source of RFC: netconf (ops)

Errata ID: 4544
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Keshava Bhat
Date Reported: 2015-11-24
Rejected by: Benoit Claise
Date Rejected: 2015-12-01

Section 6.1 says:

   XML subtree filtering is a mechanism that allows an application to
   select particular XML subtrees to include in the <rpc-reply> for a
   <get> or <get-config> operation.  A small set of filters for
   inclusion, simple content exact-match, and selection is provided,
   which allows some useful, but also very limited, selection
   mechanisms.  The server does not need to utilize any data-model-
   specific semantics during processing, allowing for simple and
   centralized implementation strategies.

   Conceptually, a subtree filter is comprised of zero or more element
   subtrees, which represent the filter selection criteria.  At each
   containment level within a subtree, the set of sibling nodes is
   logically processed by the server to determine if its subtree and
   path of elements to the root are included in the filter output.

   Each node specified in a subtree filter represents an inclusive
   filter.  Only associated nodes in underlying data model(s) within the
   specified datastore on the server are selected by the filter.  A node
   is selected if it matches the selection criteria and hierarchy of
   elements given in the filter data, except that the filter absolute
   path name is adjusted to start from the layer below <filter>.

   Response messages contain only the subtrees selected by the filter.
   Any selection criteria that were present in the request, within a
   particular selected subtree, are also included in the response.  Note
   that some elements expressed in the filter as leaf nodes will be
   expanded (i.e., subtrees included) in the filter output.  Specific
   data instances are not duplicated in the response in the event that
   the request contains multiple filter subtree expressions that select
   the same data.

It should say:

   XML subtree filtering is a mechanism that allows an application to
   select particular XML subtrees to include in the <rpc-reply> for a
   <get> or <get-config> operation.  A small set of filters for
   inclusion, simple content exact-match, and selection is provided,
   which allows some useful, but also very limited, selection
   mechanisms.  The server does not need to utilize any data-model-
   specific semantics during processing, allowing for simple and
   centralized implementation strategies.

   Conceptually, a subtree filter is comprised of zero or more element
   subtrees, which represent the filter selection criteria.  At each
   containment level within a subtree, the set of sibling nodes is
   logically processed by the server to determine if its subtree and
   path of elements to the root are included in the filter output.

   Each node specified in a subtree filter represents an inclusive
   filter.  Only associated nodes in underlying data model(s) within the
   specified datastore on the server are selected by the filter.  A node
   is selected if it matches the selection criteria and hierarchy of
   elements given in the filter data, except that the filter absolute
   path name is adjusted to start from the layer below <filter>.

   Response messages contain only the subtrees selected by the filter.
   Any selection criteria that were present in the request, within a
   particular selected subtree, are also included in the response.  Note
   that some elements expressed in the filter as leaf nodes will be
   expanded (i.e., subtrees included) in the filter output.  Specific
   data instances are not duplicated in the response in the event that
   the request contains multiple filter subtree expressions that select
   the same data.

   When a node in the subtree filter is unknown, the server sends a 
   <rpc-error> as reply with "unknown-element" error-tag. In case of
   <get-config> RPC, if the subtree filter contains a node that is
   not a configuration node, the server sends <rpc-error> as reply
   with "bad-element" error-tag. 

Notes:

It is not clear in the RFC what a netconf server should do when
it encounters invalid nodes in a subtree filter in case of
get/get-config RPC.
--VERIFIER NOTES--
I think the text is clear - it says that if the element "exactly
matches a corresponding portion of the supported data model" it is
included. If it is not even in the server's schema, it doesn't match
the "supported data model".

XPath filtering works the same way; elements that are not part of the
data model simply won't match, without producing an error.

Errata ID: 4856
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: frank feng
Date Reported: 2016-11-08
Rejected by: Benoit Claise
Date Rejected: 2016-12-20

Section 7.2 says:

config:  A hierarchy of configuration data as defined by one of
         the device's data models.  The contents MUST be placed in an
         appropriate namespace, to allow the device to detect the
         appropriate data model, and the contents MUST follow the
         constraints of that data model, as defined by its capability
         definition.  Capabilities are discussed in Section 8.

It should say:

config:  A hierarchy of configuration data as defined by one or more of
         the device's data models.  The contents MUST be placed in an
         appropriate namespace, to allow the device to detect the
         appropriate data model, and the contents MUST follow the
         constraints of that data model, as defined by its capability
         definition.  Capabilities are discussed in Section 8.

Notes:

--VERIFIER NOTES--
As discussed on the NETCONF mailing list.

Errata ID: 5443
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jonathan Natale
Date Reported: 2018-07-27
Rejected by: Ignas Bagdonas
Date Rejected: 2019-10-18

Section 4.4 says:

The <ok> element is sent in <rpc-reply> messages if no errors or
warnings occurred during the processing of an <rpc> request, and no
data was returned from the operation.

It should say:

The <ok> element is sent in <rpc-reply> messages if
and only if
no errors or
warnings occurred during the processing of an <rpc> request, and no
data was returned from the operation.

Notes:

I have been informed that an <ok> element should not include any errors or warnings, even in the event of the associated operation completing because the error's severity was only at warning level).
--VERIFIER NOTES--
Rejected based on WG mailing list discussion: https://mailarchive.ietf.org/arch/msg/netconf/nQYVm8sm5pZamtRAIhbcB9cOuos

Errata ID: 5596
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jonathan Hansford
Date Reported: 2019-01-09
Rejected by: Ignas Bagdonas
Date Rejected: 2019-10-19

Section 7.5 says:

      The duration of the lock is defined as beginning when the lock is
      acquired and lasting until either the lock is released or the
      NETCONF session closes.  The session closure can be explicitly
      performed by the client, or implicitly performed by the server
      based on criteria such as failure of the underlying transport,
      simple inactivity timeout, or detection of abusive behavior on the
      part of the client.  These criteria are dependent on the
      implementation and the underlying transport.

It should say:

      The duration of the lock is defined as beginning when the lock is
      acquired and lasting until either the lock is released or the
      NETCONF session closes.  The session closure can be explicitly
      performed by the client, or implicitly performed by the server
      based on criteria such as failure of the underlying transport,
      simple inactivity timeout, or detection of abusive behavior on the
      part of the client.  These criteria are dependent on the
      implementation and the underlying transport. Note that a lock
      associated with a persistent confirmed commit will be released if
      the NETCONF session closes and, if required, a new lock will have
      to be acquired.

Notes:

A persistent confirmed commit can survive a session termination, however any lock on that same session cannot. If a new session is established between the client and server, the client will need to acquire new locks if it wishes to protect the ongoing persistent confirmed commit.
--VERIFIER NOTES--
Rejected based on WG mailing list discussion: https://mailarchive.ietf.org/arch/msg/netconf/lNr91W5aK-abxDaqzadftjoE2Pg

RFC 6242, "Using the NETCONF Protocol over Secure Shell (SSH)", June 2011

Source of RFC: netconf (ops)

Errata ID: 5305
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: HengyingFan
Date Reported: 2018-03-26
Rejected by: Ignas Bagdonas
Date Rejected: 2018-03-27

Section 6 says:

   This document also recommends that SSH servers be configurable to
   allow access to the "netconf" SSH subsystem over other ports.  Use of
   that configuration option without corresponding changes to firewall
   or network device configuration may unintentionally result in the
   ability for nodes outside of the firewall or other administrative
   boundaries to gain access to the "netconf" SSH subsystem.

It should say:

   This document also recommends that SSH servers be configurable to
   allow access to the "netconf" SSH subsystem over other ports.  Use of
   that configuration option without corresponding changes to firewall
   or network device configuration may unintentionally result in the
   inability for nodes outside of the firewall or other administrative
   boundaries to gain access to the "netconf" SSH subsystem.

Notes:

ability -> inability
--VERIFIER NOTES--
It was discussed among reporter, document authors, and WG members and the conclusion was that the original text in the document is technically correct.

Email discussion:
https://mailarchive.ietf.org/arch/msg/netconf/xMBJjW9Sn5xzXZYhwVbRM0Im1fg

RFC 6243, "With-defaults Capability for NETCONF", June 2011

Source of RFC: netconf (ops)

Errata ID: 7427
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Dylan Sadoun
Date Reported: 2023-04-18
Rejected by: Rob Wilton
Date Rejected: 2023-10-02

Section 3.3 says:

When data is retrieved with a <with-defaults> parameter equal to 'explicit', a data node that was set by a client to its schema default value MUST be reported.  A conceptual data node that would be set by the server to the schema default value MUST NOT be reported. Non-configuration data nodes containing the schema default value MUST be reported.

It should say:

When data is retrieved with a <with-defaults> parameter equal to 'explicit', a data node that was set by a client to its schema default value MUST be reported. A conceptual data node that would be set by the server to the schema default value MUST NOT be reported. A conceptual data node that would be set by the server to a value other than its schema default value MUST be reported. Non-configuration data nodes containing the schema default value MUST be reported.

Notes:

The RFC defines "Explicitly set data" for the sole purpose of defining the explicit retrieval mode. This definition is clear about when data set by the server should be considered "explicitly set" i.e. when not set to the schema default value. However, the 2.3.1 and 3.3 sections are ambiguous and prone to misunderstanding, as they only emphasise the "set by the client" case, which leads to think that data set by the server to a value different from its schema default value should not be reported.
This erratum is for the 3.3 section.
--VERIFIER NOTES--
After discussion with the WG, it was agreed that several server implementations would likely behave as your errata suggests. However, the consensus was that this behavior is beyond what can be clarified as part of an errata without specifying a new RFC. In particular, it is noted that the current RFC predominantly defines expected behavior for data nodes modified via the external API between the client and server and defining "conceptual data nodes being set by a server" is beyond the scope of behavior specified by the RFC.

Please also see errata 7426 that helps clarify the behavior for section 2.3.1.

Errata ID: 7428
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dylan Sadoun
Date Reported: 2023-04-18
Rejected by: Rob Wilton
Date Rejected: 2023-10-02

Section Appendix A says:

A.2.  Example Data Set

[...]

  <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <interfaces xmlns="http://example.com/ns/interfaces">
      <interface>
        <name>eth0</name>
        <mtu>8192</mtu>
        <status>up</status>
      </interface>
      <interface>
        <name>eth1</name>
        <mtu>1500</mtu>
        <status>up</status>
      </interface>
      <interface>
        <name>eth2</name>
        <mtu>9000</mtu>
        <status>not feeling so good</status>
      </interface>
      <interface>
        <name>eth3</name>
        <mtu>1500</mtu>
        <status>waking up</status>
      </interface>
    </interfaces>
  </data>

  In this example, the 'mtu' field for each interface entry is set in
   the following manner:

              +--------------+--------------+--------------+
              | name         | set by       | mtu          |
              +--------------+--------------+--------------+
              | eth0         | client       | 8192         |
              | eth1         | server       | 1500         |
              | eth2         | client       | 9000         |
              | eth3         | client       | 1500         |
              +--------------+--------------+--------------+

[...]

A.3.1.  <with-defaults> = 'report-all'

   The behavior of the <with-defaults> parameter handling for the value
   'report-all' is demonstrated in this example.

    <rpc message-id="101"
         xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <get>
        <filter type="subtree">
          <interfaces xmlns="http://example.com/ns/interfaces"/>
        </filter>
        <with-defaults
         xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">
          report-all
        </with-defaults>
      </get>
    </rpc>

    <rpc-reply message-id="101"
               xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <data>
        <interfaces xmlns="http://example.com/ns/interfaces">
          <interface>
            <name>eth0</name>
            <mtu>8192</mtu>
            <status>up</status>
          </interface>
          <interface>
            <name>eth1</name>
            <mtu>1500</mtu>
            <status>up</status>
          </interface>
          <interface>
            <name>eth2</name>
            <mtu>9000</mtu>
            <status>not feeling so good</status>
          </interface>
          <interface>
            <name>eth3</name>
            <mtu>1500</mtu>
            <status>waking up</status>
          </interface>
        </interfaces>
      </data>
    </rpc-reply>

A.3.2.  <with-defaults> = 'report-all-tagged'

[...]

    <rpc message-id="102"
         xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <get>
        <filter type="subtree">
          <interfaces xmlns="http://example.com/ns/interfaces"/>
        </filter>
        <with-defaults
         xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">
          report-all-tagged
        </with-defaults>
      </get>
    </rpc>

    <rpc-reply message-id="102"
               xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
               xmlns:wd="urn:ietf:params:xml:ns:netconf:default:1.0">
      <data>
        <interfaces xmlns="http://example.com/ns/interfaces">
          <interface>
            <name>eth0</name>
            <mtu>8192</mtu>
            <status wd:default="true">up</status>
          </interface>
          <interface>
            <name>eth1</name>
            <mtu wd:default="true">1500</mtu>
            <status wd:default="true">up</status>
          </interface>
          <interface>
            <name>eth2</name>
            <mtu>9000</mtu>
            <status>not feeling so good</status>
          </interface>
          <interface>
            <name>eth3</name>
            <mtu wd:default="true">1500</mtu>
            <status>waking up</status>
          </interface>
        </interfaces>
      </data>
    </rpc-reply>

A.3.3.  <with-defaults> = 'trim'

   The behavior of the <with-defaults> parameter handling for the value
   'trim' is demonstrated in this example.

    <rpc message-id="103"
         xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <get>
        <filter type="subtree">
          <interfaces xmlns="http://example.com/ns/interfaces"/>
        </filter>
        <with-defaults
         xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">
          trim
        </with-defaults>
      </get>
    </rpc>

    <rpc-reply message-id="103"
               xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <data>
        <interfaces xmlns="http://example.com/ns/interfaces">
          <interface>
            <name>eth0</name>
            <mtu>8192</mtu>
          </interface>
          <interface>
            <name>eth1</name>
          </interface>
          <interface>
            <name>eth2</name>
            <mtu>9000</mtu>
            <status>not feeling so good</status>
          </interface>
          <interface>
            <name>eth3</name>
            <status>waking up</status>
          </interface>
        </interfaces>
      </data>
    </rpc-reply>

A.3.4.  <with-defaults> = 'explicit'

   The behavior of the <with-defaults> parameter handling for the value
   'explicit' is demonstrated in this example.

    <rpc message-id="104"
         xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <get>
        <filter type="subtree">
          <interfaces xmlns="http://example.com/ns/interfaces"/>
        </filter>
        <with-defaults
         xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">
          explicit
        </with-defaults>
      </get>
    </rpc>

    <rpc-reply message-id="104"
               xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <data>
        <interfaces xmlns="http://example.com/ns/interfaces">
          <interface>
            <name>eth0</name>
            <mtu>8192</mtu>
            <status>up</status>
          </interface>
          <interface>
            <name>eth1</name>
            <status>up</status>
          </interface>
          <interface>
            <name>eth2</name>
            <mtu>9000</mtu>
            <status>not feeling so good</status>
          </interface>
          <interface>
            <name>eth3</name>
            <mtu>1500</mtu>
            <status>waking up</status>
          </interface>
        </interfaces>
      </data>
    </rpc-reply>

It should say:

A.2.  Example Data Set

[...]

  <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <interfaces xmlns="http://example.com/ns/interfaces">
      <interface>
        <name>eth0</name>
        <mtu>8192</mtu>
        <status>up</status>
      </interface>
      <interface>
        <name>eth1</name>
        <mtu>1500</mtu>
        <status>up</status>
      </interface>
      <interface>
        <name>eth2</name>
        <mtu>9000</mtu>
        <status>not feeling so good</status>
      </interface>
      <interface>
        <name>eth3</name>
        <mtu>1500</mtu>
        <status>waking up</status>
      </interface>
      <interface>
        <name>eth4</name>
        <mtu>9112</mtu>
        <status>better call for help</status>
      </interface>
    </interfaces>
  </data>

  In this example, the 'mtu' field for each interface entry is set in
   the following manner:

              +--------------+--------------+--------------+
              | name         | set by       | mtu          |
              +--------------+--------------+--------------+
              | eth0         | client       | 8192         |
              | eth1         | server       | 1500         |
              | eth2         | client       | 9000         |
              | eth3         | client       | 1500         |
              | eth4         | server       | 9112         |
              +--------------+--------------+--------------+

[...]

A.3.1.  <with-defaults> = 'report-all'

   The behavior of the <with-defaults> parameter handling for the value
   'report-all' is demonstrated in this example.

    <rpc message-id="101"
         xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <get>
        <filter type="subtree">
          <interfaces xmlns="http://example.com/ns/interfaces"/>
        </filter>
        <with-defaults
         xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">
          report-all
        </with-defaults>
      </get>
    </rpc>

    <rpc-reply message-id="101"
               xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <data>
        <interfaces xmlns="http://example.com/ns/interfaces">
          <interface>
            <name>eth0</name>
            <mtu>8192</mtu>
            <status>up</status>
          </interface>
          <interface>
            <name>eth1</name>
            <mtu>1500</mtu>
            <status>up</status>
          </interface>
          <interface>
            <name>eth2</name>
            <mtu>9000</mtu>
            <status>not feeling so good</status>
          </interface>
          <interface>
            <name>eth3</name>
            <mtu>1500</mtu>
            <status>waking up</status>
          </interface>
          <interface>
            <name>eth4</name>
            <mtu>9112</mtu>
            <status>better call for help</status>
          </interface>
        </interfaces>
      </data>
    </rpc-reply>

A.3.2.  <with-defaults> = 'report-all-tagged'

[...]

    <rpc message-id="102"
         xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <get>
        <filter type="subtree">
          <interfaces xmlns="http://example.com/ns/interfaces"/>
        </filter>
        <with-defaults
         xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">
          report-all-tagged
        </with-defaults>
      </get>
    </rpc>

    <rpc-reply message-id="102"
               xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
               xmlns:wd="urn:ietf:params:xml:ns:netconf:default:1.0">
      <data>
        <interfaces xmlns="http://example.com/ns/interfaces">
          <interface>
            <name>eth0</name>
            <mtu>8192</mtu>
            <status wd:default="true">up</status>
          </interface>
          <interface>
            <name>eth1</name>
            <mtu wd:default="true">1500</mtu>
            <status wd:default="true">up</status>
          </interface>
          <interface>
            <name>eth2</name>
            <mtu>9000</mtu>
            <status>not feeling so good</status>
          </interface>
          <interface>
            <name>eth3</name>
            <mtu wd:default="true">1500</mtu>
            <status>waking up</status>
          </interface>
          <interface>
            <name>eth4</name>
            <mtu>9112</mtu>
            <status>better call for help</status>
          </interface>
        </interfaces>
      </data>
    </rpc-reply>

A.3.3.  <with-defaults> = 'trim'

   The behavior of the <with-defaults> parameter handling for the value
   'trim' is demonstrated in this example.

    <rpc message-id="103"
         xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <get>
        <filter type="subtree">
          <interfaces xmlns="http://example.com/ns/interfaces"/>
        </filter>
        <with-defaults
         xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">
          trim
        </with-defaults>
      </get>
    </rpc>

    <rpc-reply message-id="103"
               xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <data>
        <interfaces xmlns="http://example.com/ns/interfaces">
          <interface>
            <name>eth0</name>
            <mtu>8192</mtu>
          </interface>
          <interface>
            <name>eth1</name>
          </interface>
          <interface>
            <name>eth2</name>
            <mtu>9000</mtu>
            <status>not feeling so good</status>
          </interface>
          <interface>
            <name>eth3</name>
            <status>waking up</status>
          </interface>
          <interface>
            <name>eth4</name>
            <mtu>9112</mtu>
            <status>better call for help</status>
          </interface>
        </interfaces>
      </data>
    </rpc-reply>

A.3.4.  <with-defaults> = 'explicit'

   The behavior of the <with-defaults> parameter handling for the value
   'explicit' is demonstrated in this example.

    <rpc message-id="104"
         xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <get>
        <filter type="subtree">
          <interfaces xmlns="http://example.com/ns/interfaces"/>
        </filter>
        <with-defaults
         xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">
          explicit
        </with-defaults>
      </get>
    </rpc>

    <rpc-reply message-id="104"
               xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <data>
        <interfaces xmlns="http://example.com/ns/interfaces">
          <interface>
            <name>eth0</name>
            <mtu>8192</mtu>
            <status>up</status>
          </interface>
          <interface>
            <name>eth1</name>
            <status>up</status>
          </interface>
          <interface>
            <name>eth2</name>
            <mtu>9000</mtu>
            <status>not feeling so good</status>
          </interface>
          <interface>
            <name>eth3</name>
            <mtu>1500</mtu>
            <status>waking up</status>
          </interface>
          <interface>
            <name>eth4</name>
            <mtu>9112</mtu>
            <status>better call for help</status>
          </interface>
        </interfaces>
      </data>
    </rpc-reply>

Notes:

This erratum expands existing examples to include the case of a server setting data nodes to values other than their default schema values. This echoes the other errata about sections 2.3.1 and 3.3 and the explicit retrieval mode.
--VERIFIER NOTES--
After discussion with the WG, it was agreed that several server implementations would likely behave as your errata suggests. However, the consensus was that this behavior is beyond what can be clarified as part of an errata without specifying a new RFC. In particular, it is noted that the current RFC predominantly defines expected behavior for data nodes modified via the external API between the client and server and defining "conceptual data nodes being set by a server" is beyond the scope of behavior specified by the RFC.

Please also see errata 7426 that helps clarify the behavior for section 2.3.1.

RFC 6265, "HTTP State Management Mechanism", April 2011

Source of RFC: httpstate (app)

Errata ID: 3430
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Zhong Yu
Date Reported: 2012-12-13
Rejected by: Barry Leiba
Date Rejected: 2012-12-17

Section 4.1.1 says:

 max-age-av        = "Max-Age=" non-zero-digit *DIGIT
                       ; In practice, both expires-av and max-age-av
                       ; are limited to dates representable by the
                       ; user agent.
 non-zero-digit    = %x31-39
                       ; digits 1 through 9

It should say:

 max-age-av        = "Max-Age=" 1*DIGIT
                       ; In practice, both expires-av and max-age-av
                       ; are limited to dates representable by the
                       ; user agent.

Notes:

The current text forbids a server to send Max-Age=0.
--VERIFIER NOTES--
That is correct. As noted in the introduction, what servers should do and what clients should do are not the same. The ABNF in Section 4 limits the server intentionally, to maximize compatibility with deployed clients. See this text in the Introduction:

To maximize interoperability with user agents, servers SHOULD limit
themselves to the well-behaved profile defined in Section 4 when
generating cookies.

User agents MUST implement the more liberal processing rules defined
in Section 5, in order to maximize interoperability with existing
servers that do not conform to the well-behaved profile defined in
Section 4.

Errata ID: 3765
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Johannes Knaupp
Date Reported: 2013-10-25
Rejected by: Barry Leiba
Date Rejected: 2013-10-26

Section 4.1.1 says:

Servers SHOULD NOT include more than one Set-Cookie header field in
the same response with the same cookie-name.  (See Section 5.2 for
how user agents handle this case.)

It should say:

Servers MUST NOT include more than one Set-Cookie header field in
the same response.

Notes:

The HTTP specification (RFC 2616) says in its section 4.2: "Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. [...]"

Since the mentioned condition is not fulfilled in the case of Set-Cookie headers, only one Set-Cookie header is permissible in an HTTP message.

This also applies to the third example in section 3.1, even though it is not clearly specified there whether or not the two Set-Cookies originate from the same server response.

On the internet many HTTP messages contain multiple Set-Cookie headers, and this seems to make sense in order to avoid additional roundtrips. This, however, (1) does not match the HTTP specification, see above, and therefore (2) cannot be used with implementations stating that they were HTTP compatible and consequently only allow a single Set-Cookie header per response. Clearly, this is not a defect of those implementations, but of the specifications which are at least mistakable (if not contradictory).
--VERIFIER NOTES--
Part of the point of RFC 6265 is to document how cookies are actually
used on the Internet. As is noted in the introduction, existing use
doesn't always conform to what it should.  In particular, we know that
RFC 6265 doesn't always match up with RFC 2616, because the actual usage
isn't always strictly correct.

The variation from RFC 2616 that this report notes is intentional,
documenting the existing usage, and this errata report is rejected.

Errata ID: 3931
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Semyon Kholodnov
Date Reported: 2014-03-24
Rejected by: Barry Leiba
Date Rejected: 2014-03-24

Section 5.1.1 says:

   The user agent MUST use an algorithm equivalent to the following
   algorithm to parse a cookie-date.  Note that the various boolean
   flags defined as a part of the algorithm (i.e., found-time, found-
   day-of-month, found-month, found-year) are initially "not set".

   1.  Using the grammar below, divide the cookie-date into date-tokens.

   cookie-date     = *delimiter date-token-list *delimiter
   date-token-list = date-token *( 1*delimiter date-token )
   date-token      = 1*non-delimiter

   delimiter       = %x09 / %x20-2F / %x3B-40 / %x5B-60 / %x7B-7E
   non-delimiter   = %x00-08 / %x0A-1F / DIGIT / ":" / ALPHA / %x7F-FF
   non-digit       = %x00-2F / %x3A-FF

   day-of-month    = 1*2DIGIT ( non-digit *OCTET )
   month           = ( "jan" / "feb" / "mar" / "apr" /
                       "may" / "jun" / "jul" / "aug" /
                       "sep" / "oct" / "nov" / "dec" ) *OCTET
   year            = 2*4DIGIT ( non-digit *OCTET )
   time            = hms-time ( non-digit *OCTET )
   hms-time        = time-field ":" time-field ":" time-field
   time-field      = 1*2DIGIT

   2.  Process each date-token sequentially in the order the date-tokens
       appear in the cookie-date:

       1.  If the found-time flag is not set and the token matches the
           time production, set the found-time flag and set the hour-
           value, minute-value, and second-value to the numbers denoted
           by the digits in the date-token, respectively.  Skip the
           remaining sub-steps and continue to the next date-token.

       2.  If the found-day-of-month flag is not set and the date-token
           matches the day-of-month production, set the found-day-of-
           month flag and set the day-of-month-value to the number
           denoted by the date-token.  Skip the remaining sub-steps and
           continue to the next date-token.

       3.  If the found-month flag is not set and the date-token matches
           the month production, set the found-month flag and set the
           month-value to the month denoted by the date-token.  Skip the
           remaining sub-steps and continue to the next date-token.

       4.  If the found-year flag is not set and the date-token matches
           the year production, set the found-year flag and set the
           year-value to the number denoted by the date-token.  Skip the
           remaining sub-steps and continue to the next date-token.

It should say:

   The user agent MUST use an algorithm equivalent to the following
   algorithm to parse a cookie-date.  Note that the various boolean
   flags defined as a part of the algorithm (i.e., found-day-of-week,
   found-time, found-day-of-month, found-month, found-year) are 
   initially "not set".

   1.  Using the grammar below, divide the cookie-date into date-tokens.

   cookie-date     = *delimiter date-token-list *delimiter
   date-token-list = date-token *( 1*delimiter date-token )
   date-token      = 1*non-delimiter

   delimiter       = %x09 / %x20-2F / %x3B-40 / %x5B-60 / %x7B-7E
   non-delimiter   = %x00-08 / %x0A-1F / DIGIT / ":" / ALPHA / %x7F-FF
   non-digit       = %x00-2F / %x3A-FF

   day-of-week     = weekday / wkday
   wkday           = "mon" / "tue" / "wed" / "thu" / "fri" / "sat" /
                     "sun"
   weekday         = "monday" / "tuesday" / "wednesday" / "thursday" /
                     "friday" / "saturday" / "sunday"
   day-of-month    = 1*2DIGIT ( non-digit *OCTET )
   month           = ( "jan" / "feb" / "mar" / "apr" /
                       "may" / "jun" / "jul" / "aug" /
                       "sep" / "oct" / "nov" / "dec" ) *OCTET
   year            = 2*4DIGIT ( non-digit *OCTET )
   time            = hms-time ( non-digit *OCTET )
   hms-time        = time-field ":" time-field ":" time-field
   time-field      = 1*2DIGIT

   2.  Process each date-token sequentially in the order the date-tokens
       appear in the cookie-date:

       1.  If the found-day-of-week flag is not set and the token 
           matches the day-of-week production, set found-day-of-week 
           flag. Skip the remaining steps and continue to the next 
           date-token.

       2.  If the found-time flag is not set and the token matches the
           time production, set the found-time flag and set the hour-
           value, minute-value, and second-value to the numbers denoted
           by the digits in the date-token, respectively.  Skip the
           remaining sub-steps and continue to the next date-token.

       3.  If the found-day-of-month flag is not set and the date-token
           matches the day-of-month production, set the found-day-of-
           month flag and set the day-of-month-value to the number
           denoted by the date-token.  Skip the remaining sub-steps and
           continue to the next date-token.

       4.  If the found-month flag is not set and the date-token matches
           the month production, set the found-month flag and set the
           month-value to the month denoted by the date-token.  Skip the
           remaining sub-steps and continue to the next date-token.

       5.  If the found-year flag is not set and the date-token matches
           the year production, set the found-year flag and set the
           year-value to the number denoted by the date-token.  Skip the
           remaining sub-steps and continue to the next date-token.

Notes:

4.1.1 defines "sane-cookie-date" as "rfc1123-date, defined in [RFC2616], Section 3.3.1". However, both RFC1123 and RFC2616 mandate that date starts with day of the week, and indeed, most servers send cookies where Expires starts with day of the week.

In this particular case (Expire field) the day-of-week part of the date is insignificant, and client MAY ignore it.
--VERIFIER NOTES--
The reporter misunderstood the algorithm at first, thinking that it would fail when it couldn't parse the weekday token. In fact, the algorithm actually has the flexibility to ignore tokens it doesn't care about, and to handle tokens in any order. So there's no error here.

Errata ID: 4043
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Pierre Lepropre
Date Reported: 2014-07-06
Rejected by: Barry Leiba
Date Rejected: 2014-07-12

Section 5.1.4 says:

The user agent MUST use an algorithm equivalent to the following
algorithm to compute the default-path of a cookie:

It should say:

The user agent MUST use an algorithm equivalent to the following
algorithm to compute the default value for a cookie-path 
(and thereby matching the server-side semantics as defined in 4.1.2.4):

Notes:

The term "default-path" is not formally defined before and is quite misleading for the reader
A. going through the section 5.1.4 as it's only used there once and not again
until section 5.2.4 (once again) and 5.3 (once again).
B. not being a native English speaker

Furthermore, the true meaning of the "default-path" only appears sometime after at section 5.2.4 where it's finally bound altogether. Therefore, my personal recommendation would be to also replace the other occurrences of the "default-path" terms by "default cookie-path"
--VERIFIER NOTES--
This report is actually an enhancement request. The discussion of this report on the http-state mailing list should be reviewed if the document is ever revised.

Errata ID: 4044
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Pierre Lepropre
Date Reported: 2014-07-06
Rejected by: Barry Leiba
Date Rejected: 2014-07-12

Section 5.3 says:

Otherwise:

   Set the cookie's persistent-flag to false.

   Set the cookie's expiry-time to the latest representable
   date.

It should say:

Otherwise:

   Set the cookie's persistent-flag to false.

   Set the cookie's expiry-time to the latest representable
   date. This is a best-effort approach to ensure that the cookie 
   will effectively expire when "the current session is over" 
   (as defined by the user agent) and not anytime before.

Notes:

The second action item isn't necessarily obvious for an implementer/reader. If I got the intention right, then I believe it might improve the "user-friendly" rating of this document. Otherwise, it might still be beneficial to explicit a bit the reasoning behind that action.
--VERIFIER NOTES--
This report is actually an enhancement request. The discussion of this report on the http-state mailing list should be reviewed if the document is ever revised.

RFC 6266, "Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)", June 2011

Source of RFC: httpbis (wit)

Errata ID: 5383
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Magnar Ovedal Myrtveit
Date Reported: 2018-06-07
Rejected by: Francesca Palombini
Date Rejected: 2022-11-09

Section 4.1 says:

     disp-ext-parm       = token "=" value
                         | ext-token "=" ext-value
     ext-token           = <the characters in token, followed by "*">

   Defined in [RFC2616]:

     token         = <token, defined in [RFC2616], Section 2.2>
     quoted-string = <quoted-string, defined in [RFC2616], Section 2.2>
     value         = <value, defined in [RFC2616], Section 3.6>
                   ; token | quoted-string

   Defined in [RFC5987]:

     ext-value   = <ext-value, defined in [RFC5987], Section 3.2>

It should say:

     disp-ext-parm       = parmname "=" value
                         | ext-parmname "=" ext-value
     ext-parmname        = <the characters in parmname, followed by "*">

   Defined in [RFC2616]:

     quoted-string = <quoted-string, defined in [RFC2616], Section 2.2>
     value         = <value, defined in [RFC2616], Section 3.6>
                   ; token | quoted-string

   Defined in [RFC5987]:

     parmname    = <parmname, defined in [RFC5987], Section 3.2>
     ext-value   = <ext-value, defined in [RFC5987], Section 3.2>

Notes:

RFC 5987, Section 3.2.1, modifies the grammar from RFC 2616. These modifications should be used in RFC 6266. If not, it is impossible to determine whether a parameter should be a value or an ext-value based on the parameter name, since "*" is a valid character in token.
--VERIFIER NOTES--
The extended syntax is currently defined only for "filename", and any new parameter using the extended syntax would need to be defined in a document extending RFC 6266.

Errata ID: 3325
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jack Bates
Date Reported: 2012-08-18
Rejected by: Barry Leiba
Date Rejected: 2012-08-18

Section 4.1 says:

     content-disposition = "Content-Disposition" ":"
                            disposition-type *( ";" disposition-parm )

     disposition-type    = "inline" | "attachment" | disp-ext-type
                         ; case-insensitive
     disp-ext-type       = token

     disposition-parm    = filename-parm | disp-ext-parm

     filename-parm       = "filename" "=" value
                         | "filename*" "=" ext-value

     disp-ext-parm       = token "=" value
                         | ext-token "=" ext-value
     ext-token           = <the characters in token, followed by "*">

   Defined in [RFC2616]:

     token         = <token, defined in [RFC2616], Section 2.2>
     quoted-string = <quoted-string, defined in [RFC2616], Section 2.2>
     value         = <value, defined in [RFC2616], Section 3.6>
                   ; token | quoted-string

It should say:

     content-disposition = "Content-Disposition" ":"
                            disposition-type *( ";" disposition-parm )

     disposition-type    = "inline" / "attachment" / disp-ext-type
                         ; case-insensitive
     disp-ext-type       = token

     disposition-parm    = filename-parm / disp-ext-parm

     filename-parm       = "filename" "=" value
                         / "filename*" "=" ext-value

     disp-ext-parm       = token "=" value
                         / ext-token "=" ext-value
     ext-token           = <the characters in token, followed by "*">

   Defined in [RFC2616]:

     token         = <token, defined in [RFC2616], Section 2.2>
     quoted-string = <quoted-string, defined in [RFC2616], Section 2.2>
     value         = <value, defined in [RFC2616], Section 3.6>
                   ; token / quoted-string

Notes:

The grammar in the original text uses "|" to express alternation, but I think that only "/" is valid according to RFC 5234

Verifier notes: The grammar in 6266 is from RFC 2616, not from 5234. 6266 is correct as it stands.
--VERIFIER NOTES--
The grammar in 6266 is from RFC 2616, not from 5234. This text is correct as it stands.

RFC 6275, "Mobility Support in IPv6", July 2011

Source of RFC: mext (int)

Errata ID: 5898
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Jen Linkova
Date Reported: 2019-11-08
Rejected by: Eric Vyncke
Date Rejected: 2023-08-03

Throughout the document, when it says:

It should say:

It should say:

Updates: 4861 [in RFC header]

Notes:

RFC4861 Section 6.2.1 says that
"MaxRtrAdvInterval ..MUST be no less than 4 seconds"
and
"MinRtrAdvInterval...MUST MUST be no less than 3 seconds"

RFC6275 Section 7.5. changes those requirements to:
"Routers supporting mobility SHOULD be able to be configured with a
smaller MinRtrAdvInterval value and MaxRtrAdvInterval value to allow
sending of unsolicited multicast Router Advertisements more often.
The minimum allowed values are:

o MinRtrAdvInterval 0.03 seconds

o MaxRtrAdvInterval 0.07 seconds
"
so it should be flagged as a formal update to RFC4861.
--VERIFIER NOTES--
Deviation from RFC 4861 are allowed by its section 6.2.1:
" The default values for some of the variables listed below may be
overridden by specific documents that describe how IPv6 operates over
different link layers."

RFC 6281, "Understanding Apple's Back to My Mac (BTMM) Service", June 2011

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: tsv

Errata ID: 4378
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Sterling Garwood
Date Reported: 2015-05-28
Rejected by: Martin Stiemerling
Date Rejected: 2016-01-12

Section all says:

Notes:

This entire RFC needs to be either updated or marked as obsolete. Terms in the text such as the URL reference to me.com are obsolete as Apple has moved on and renamed the entire product. Apple no longer uses NAT-PMP as the name for their port mapping protocol and that product has moved to version 2.
--VERIFIER NOTES--
Erratas are not used to obsolote documents or mark them as historic.

RFC 6292, "Requirements for a Working Group Charter Tool", June 2011

Note: This RFC has been updated by RFC 6433

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: gen

Errata ID: 3642
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Benoit Claise
Date Reported: 2013-06-06
Rejected by: Lars Eggert
Date Rejected: 2021-03-11

Section 3.1 says:

   Creating a new WG record causes the Datatracker state for this
   potential new WG to be "Informal IESG review". 

It should say:

   Creating a new WG record causes the Datatracker state for this
   potential new WG to be "Not currently under review". 

Notes:

This is what the charter tool does btw.
--VERIFIER NOTES--
The RFC documented what we thought we wanted at the time. It is not documentation of the as-built or evolving software.

RFC 6350, "vCard Format Specification", August 2011

Note: This RFC has been updated by RFC 6868

Source of RFC: vcarddav (app)

Errata ID: 3199
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Larry Masinter
Date Reported: 2012-04-23
Rejected by: Barry Leiba
Date Rejected: 2012-05-02

Section 3.1 and 10.1 says:

In Section 3.1:

  It is invalid to specify a value other than "UTF-8" in the
   "charset" MIME parameter (see Section 10.1).

In Section 10.1:

      "charset": as defined for text/plain [RFC2046]; encodings other
      than UTF-8 [RFC3629] MUST NOT be used.

It should say:

(none, delete both sentences)

Notes:

There is no "charset" parameter for text/vcard. Perhaps there used to be one, but it isn't listed and would serve no purpose if it did. Since there is no parameter, advice about its value is inappropriate.
--VERIFIER NOTES--

RFC 6365, "Terminology Used in Internationalization in the IETF", September 2011

Source of RFC: appsawg (app)

Errata ID: 4005
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Klensin
Date Reported: 2014-06-04
Rejected by: Barry Leiba
Date Rejected: 2014-06-11

Throughout the document, when it says:

US-ASCII

It should say:

ASCII

Notes:

The term "US-ASCII" is an IETF artifact, left over from some misunderstandings about what "ASCII" referred to (and the complete absence of CSCII or CASCII, MSCII or MXSCII, BRSCII, ARSCII, and other "American" coded character sets). It is a source of confusion for people who come to IETF specifications with a background in coded character sets and terminology from other areas or standards bodies and has been warned against multiple times. It should not have appeared in this document except possibly with a warning against its use (and the use of other bogus terms like "ASCII7"). The second author, who is normally sensitive to the issue, has no idea how this got past him, even in text picked up from other documents, but supposes this is what errata are for.

In any event, there is no such thing as "US-ASCII": the term is an erroneous and misleading synonym/ substitute for "ASCII". The reference for the latter is correct, but the citation anchor should probably be corrected as well.
--VERIFIER NOTES--
(1) It's clear that this is NOT errata: the use of "US-ASCII" in the document was quite intentional at the time.

(2) If (and it's not clear that there's consensus on this) we think that "US-ASCII" is not the right term, the right answer is to revise the document. Should that be done, we'd open up quite a debate about what terminology is right, and why. Simply replacing all occurrences of "US-ASCII" with "ASCII" is unlikely to be the answer. Whatever should happen would be more complicated than that.

RFC 6376, "DomainKeys Identified Mail (DKIM) Signatures", September 2011

Note: This RFC has been updated by RFC 8301, RFC 8463, RFC 8553, RFC 8616

Source of RFC: dkim (sec)

Errata ID: 3758
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Majid Tajamolian & Nazilla Karkon
Date Reported: 2013-10-20
Rejected by: Barry Leiba
Date Rejected: 2013-10-20

Section 3.6.1. says:

v= Version of the DKIM key record (plain-text; RECOMMENDED, default
      is "DKIM1").  If specified, this tag MUST be set to "DKIM1"
      (without the quotes).  This tag MUST be the first tag in the
      record.  Records beginning with a "v=" tag with any other value
      MUST be discarded.  Note that Verifiers must do a string
      comparison on this value; for example, "DKIM1" is not the same as
      "DKIM1.0".

It should say:

v= Version of the DKIM key record (plain-text; RECOMMENDED, default
      is "1").  If specified, this tag MUST be set to "1"
      (without the quotes).  This tag MUST be the first tag in the
      record.  Records beginning with a "v=" tag with any other value
      MUST be discarded.  Note that Verifiers must do a string
      comparison on this value; for example, "1" is not the same as
      "1.0".

Notes:

The "DKIM" prefix in the version field is unnecessary.
for example the followings are snipped from an actual email via gmail.com:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:from:date:message-id:subject:to:content-type;
bh=46j07/8gDec8jTto/znsrAKiXDj6YJ7Wa2DCoZuhwXc=;
b=h6SViP6DcHgPwydJD6aztqyKd0UmCN3SdwmqZd0uCHmqrprphjN8qQ8AnBDhbwDhAa
DfHIDS8RSegELKtzsp95u+DnIFg1uNhIukKVpGT+9MqxfCSAFk7WpMe2O/2gcLruilTe
MxkKJ29s64NGevYewKtI8s73xHmbzD1NFH9ugdow8i9E16kgQ+vAx56qvbFTBwdEEw8I
6Bteu3tXEsYYbU/9Akm2GXS+6PFiDSbv47u3EmhRQIOK3e8DvcobrpicjL7vUwBCpQuf
J/c+Acdq4GZQoMoG9imzku0K2o0w33CZ1xUR1bARJKCVaJfWeHiEMQ2OJ9A6ZtqpyK0z
1Ftg==
--VERIFIER NOTES--
The reporters are confused. The text in Section 3.6.1 is about the key records in the DNS, and the document is correct. Section 3.5 is where the dkim-signature header field is described (and that is also correct).

Errata ID: 5551
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Borislav Petrov
Date Reported: 2018-11-09
Rejected by: Barry Leiba
Date Rejected: 2019-04-30

Section 6.3. says:

If an MTA does wish to reject such
   messages during an SMTP session (for example, when communicating with
   a peer who, by prior agreement, agrees to only send signed messages),
   and a signature is missing or does not verify, the handling MTA
   SHOULD use a 550/5.7.x reply code.

   Where the Verifier is integrated within the MTA and it is not
   possible to fetch the public key, perhaps because the key server is
   not available, a temporary failure message MAY be generated using a
   451/4.7.5 reply code, such as:

   451 4.7.5 Unable to verify signature - key server unavailable

   Temporary failures such as inability to access the key server or
   other external service are the only conditions that SHOULD use a 4xx
   SMTP reply code. 

Notes:

This contradicts RFC5321 which says:

...a relay SMTP has no need to inspect or
act upon the header section or body of the message data and MUST NOT
do so except to add its own "Received:" header field...
--VERIFIER NOTES--

There is nothing in the cited text above that suggests modifications to the message. The text only talks about which SMTP reply codes to use.

Errata ID: 5713
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Victor Shrubowich
Date Reported: 2019-04-30
Rejected by: Benjamin Kaduk
Date Rejected: 2019-04-30

Section 2.8 says:

FWS =   [*WSP CRLF] 1*WSP

It should say:

FWS =   [*WSP] CRLF 1*WSP

Notes:

In the ABNF RFC ([RFC5234]), section 3.8 states "Square brackets enclose an optional element sequence".

CRLF is required for folding. However, the CRLF in the FWS rule is shown inside the square brackets, which would make it optional. It should not be inside the square brackets.

(See Errata ID 5712 for FWS in [RFC5322], which is referenced at the end of section 2.8.)
--VERIFIER NOTES--
As noted by Dave Crocker, Folding White Space is a construct that permits a newline but does not require it -- only whitespace of some form is required to be present in order to match, not a specific kind of whitespace. The present construction, as corresponds to RFC 5322, is as intended.

Errata ID: 7862
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Steffen Nurpmeso
Date Reported: 2024-03-21
Rejected by: Murray Kucherawy
Date Rejected: 2024-03-22

Section 3.4.2 says:

[..]

It should say:

[insert after item 2]

Due to de-facto implementation practice, the term WSP of the following two items, 
as well as in the part that refers to after the separating colon (the field body) 
in the third, has to be interpreted differently, and must include all US-ASCII 
whitespace characters, namely %d9 (HT), %d10 (LF), %d11 (VT), %d12 (FF), %d12 
(CR) as well as %d32 (SP) [?](the isspace(3) set of characters in the ISO C "C" 
locale)[/?]

Notes:

As written.
The behaviour *could* originate in a partial misunderstanding of the Sendmail milter protocol, which is often used to implement DKIM; this protocol *may* send header continuation lines separated by lone LF bytes, instead of CRLF.
(Thanks to Claus Assmann of esmtp.org for this in-between-the-lines reading.)
--VERIFIER NOTES--
Withdrawn by submitter.

Errata ID: 3759
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Majid Tajamolian & Nazila Karkon
Date Reported: 2013-10-20
Rejected by: Barry Leiba
Date Rejected: 2013-10-20

Section 3.6.1. says:

   h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to
      allowing all algorithms).  A colon-separated list of hash
      algorithms that might be used.  Unrecognized algorithms MUST be
      ignored.  Refer to Section 3.3 for a discussion of the hash
      algorithms implemented by Signers and Verifiers.  The set of
      algorithms listed in this tag in each record is an operational
      choice made by the Signer.

It should say:

   a= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to
      allowing all algorithms).  A colon-separated list of hash
      algorithms that might be used.  Unrecognized algorithms MUST be
      ignored.  Refer to Section 3.3 for a discussion of the hash
      algorithms implemented by Signers and Verifiers.  The set of
      algorithms listed in this tag in each record is an operational
      choice made by the Signer.

Notes:

The correct tag is "a=" for algorithms not "h=". The latter is used for the "List of Included Headers in the Signature"
--VERIFIER NOTES--
The reporters are confused. The text in Section 3.6.1 is about the key records in the DNS, and the document is correct. Section 3.5 is where the dkim-signature header field is described (and that is also correct).

Errata ID: 5260
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ale
Date Reported: 2018-02-08
Rejected by: Barry Leiba
Date Rejected: 2019-04-30

Section 3.5 says:

It should say:

DKIM-Signature = "DKIM-Signature:" tag-list

Notes:

A formal definition is needed to make it explicit that this header field name is case insensitive, like all the other header field names.
--VERIFIER NOTES--

Header field names are case-insensitive, in general; there is neither need nor desire to repeat that in the DKIM spec.

RFC 6428, "Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile", November 2011

Note: This RFC has been updated by RFC 7214

Source of RFC: mpls (rtg)

Errata ID: 6296
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Sudipta Das
Date Reported: 2020-09-29
Rejected by: Deborah Brungard
Date Rejected: 2021-02-26

Section 3.7 says:

In coordinated mode, an implementation SHOULD NOT reset
bfd.RemoteDiscr until it is exiting the DOWN state.

It should say:

In coordinated mode, an implementation SHOULD reset
bfd.RemoteDiscr upon transitioning to the DOWN state, 
due to period of a Detection Time passing without the
receipt of a valid, authenticated BFD packet from the
remote system.

Notes:

This section seems to imply that when a BFD session, running in coordinated mode, experiences Control Detection Timer expiry, then it SHOULD retain the remote discriminator value *and* SHOULD also transmit the same value in Down packets.
However, in the case when the remote system, configured in Passive role, has its discriminator gets changed (say, after a system reboot which had caused the Detection Timer expiry), it may reject these packets as the received Your Discriminator value is no longer valid for the current session.
So the BFD session would never come back to Up state.

In a second scenario (unrelated to above one), if the local system is configured in Passive role and experiences Control Detection Timer expiry, it may continue transmitting Down packets since the bfd.RemoteDiscr is not reset to zero.
--VERIFIER NOTES--
This should be addressed by the working group (e.g., updating or revising the RFC).

RFC 6454, "The Web Origin Concept", December 2011

Source of RFC: websec (app)

Errata ID: 3249
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Anne van Kesteren
Date Reported: 2012-06-08
Rejected by: Barry Leiba
Date Rejected: 2012-06-10

Section 7.1. Syntax says:

origin              = "Origin:" OWS origin-list-or-null OWS
origin-list-or-null = %x6E %x75 %x6C %x6C / origin-list
origin-list         = serialized-origin *( SP serialized-origin )

It should say:

origin              = "Origin:" OWS origin-or-null OWS
origin-or-null      = %x6E %x75 %x6C %x6C / serialized-origin

Notes:

Rationale: List of origins was added for CORS http://www.w3.org/TR/cors/ but CORS does not require it and we should leave this as a choice.

This syntax restriction also has limited impact on 7.2. and 7.3.

See also: http://lists.w3.org/Archives/Public/www-archive/2012Jun/thread.html#msg1
--VERIFIER NOTES--
This should be considered if/when the document is worked on again, but it is not an "error" in the original document -- rather, it's something that's come up since -- and so it's not appropriate for errata.

RFC 6455, "The WebSocket Protocol", December 2011

Note: This RFC has been updated by RFC 7936, RFC 8307, RFC 8441

Source of RFC: hybi (app)

Errata ID: 3215
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Jesse Katzman
Date Reported: 2012-05-06
Rejected by: Barry Leiba
Date Rejected: 2012-05-06

Section 5.3 says:

The unpredictability of the masking key is
essential to prevent authors of malicious applications from selecting
the bytes that appear on the wire.

Notes:

I don't see how the client-to-server masking prevents "authors of malicious applications from selecting the bytes that appear on the wire".

Maliciously changing the contents of a message simply requires a few more steps than it would without masking, as far as I can tell.

I'm quite new at networking, so perhaps I'm missing something. Thank you.
--VERIFIER NOTES--
Not appropriate for errata; please take your input to the HyBi working group as it continues its efforts.

Errata ID: 3912
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Mattias Ekendahl
Date Reported: 2014-03-05
Rejected by: Barry Leiba
Date Rejected: 2014-03-24

Section 5.2 says:

    frame-payload-length    = ( %x00-7D )
                            / ( %x7E frame-payload-length-16 )
                            / ( %x7F frame-payload-length-63 )
                            ; 7, 7+16, or 7+64 bits in length,
                            ; respectively

    frame-payload-length-16 = %x0000-FFFF ; 16 bits in length

    frame-payload-length-63 = %x0000000000000000-7FFFFFFFFFFFFFFF
                            ; 64 bits in length

It should say:

    frame-payload-length    = ( %x00-7D )
                            / ( %x7E frame-payload-length-16 )
                            / ( %x7F frame-payload-length-64 )
                            ; 7, 7+16, or 7+64 bits in length,
                            ; respectively

    frame-payload-length-16 = %x0000-FFFF ; 16 bits in length

    frame-payload-length-64 = %x0000000000000000-FFFFFFFFFFFFFFFF
                            ; 64 bits in length

Notes:

Name of field and range is implying that it should be 63 bits in length, but documentation is saying 64 bits in 2 places.
--VERIFIER NOTES--
The intended interpretation is that lexically the field is 64 bit long but the value space is constrained to 63 bit (so the length can be represented in a 64 signed integer, with the sign bit always zero). It is a bit unconventional to use ABNF like this, but it is explained in Section 5.2.

Errata ID: 4184
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Jonathan Hall
Date Reported: 2014-11-17
Rejected by: Barry Leiba
Date Rejected: 2014-12-04

Section 5.4 says:

5.4.  Fragmentation

   The primary purpose of fragmentation is to allow sending a message
   that is of unknown size when the message is started without having to
   buffer that message.  If messages couldn't be fragmented, then an
   endpoint would have to buffer the entire message so its length could
   be counted before the first byte is sent.  With fragmentation, a
   server or intermediary may choose a reasonable size buffer and, when
   the buffer is full, write a fragment to the network.

   A secondary use-case for fragmentation is for multiplexing, where it
   is not desirable for a large message on one logical channel to
   monopolize the output channel, so the multiplexing needs to be free
   to split the message into smaller fragments to better share the
   output channel.  (Note that the multiplexing extension is not
   described in this document.)

   Unless specified otherwise by an extension, frames have no semantic
   meaning.  An intermediary might coalesce and/or split frames, if no
   extensions were negotiated by the client and the server or if some
   extensions were negotiated, but the intermediary understood all the
   extensions negotiated and knows how to coalesce and/or split frames
   in the presence of these extensions.  One implication of this is that
   in absence of extensions, senders and receivers must not depend on
   the presence of specific frame boundaries.

   The following rules apply to fragmentation:

   o  An unfragmented message consists of a single frame with the FIN
      bit set (Section 5.2) and an opcode other than 0.

   o  A fragmented message consists of a single frame with the FIN bit
      clear and an opcode other than 0, followed by zero or more frames
      with the FIN bit clear and the opcode set to 0, and terminated by
      a single frame with the FIN bit set and an opcode of 0.  A
      fragmented message is conceptually equivalent to a single larger
      message whose payload is equal to the concatenation of the
      payloads of the fragments in order; however, in the presence of
      extensions, this may not hold true as the extension defines the
      interpretation of the "Extension data" present.  For instance,
      "Extension data" may only be present at the beginning of the first
      fragment and apply to subsequent fragments, or there may be
      "Extension data" present in each of the fragments that applies
      only to that particular fragment.  In the absence of "Extension
      data", the following example demonstrates how fragmentation works.

      EXAMPLE: For a text message sent as three fragments, the first
      fragment would have an opcode of 0x1 and a FIN bit clear, the
      second fragment would have an opcode of 0x0 and a FIN bit clear,
      and the third fragment would have an opcode of 0x0 and a FIN bit
      that is set.

   o  Control frames (see Section 5.5) MAY be injected in the middle of
      a fragmented message.  Control frames themselves MUST NOT be
      fragmented.

   o  Message fragments MUST be delivered to the recipient in the order
      sent by the sender.

   o  The fragments of one message MUST NOT be interleaved between the
      fragments of another message unless an extension has been
      negotiated that can interpret the interleaving.

   o  An endpoint MUST be capable of handling control frames in the
      middle of a fragmented message.

   o  A sender MAY create fragments of any size for non-control
      messages.

   o  Clients and servers MUST support receiving both fragmented and
      unfragmented messages.

   o  As control frames cannot be fragmented, an intermediary MUST NOT
      attempt to change the fragmentation of a control frame.

   o  An intermediary MUST NOT change the fragmentation of a message if
      any reserved bit values are used and the meaning of these values
      is not known to the intermediary.

   o  An intermediary MUST NOT change the fragmentation of any message
      in the context of a connection where extensions have been
      negotiated and the intermediary is not aware of the semantics of
      the negotiated extensions.  Similarly, an intermediary that didn't
      see the WebSocket handshake (and wasn't notified about its
      content) that resulted in a WebSocket connection MUST NOT change
      the fragmentation of any message of such connection.

   o  As a consequence of these rules, all fragments of a message are of
      the same type, as set by the first fragment's opcode.  Since
      control frames cannot be fragmented, the type for all fragments in
      a message MUST be either text, binary, or one of the reserved
      opcodes.

   NOTE: If control frames could not be interjected, the latency of a
   ping, for example, would be very long if behind a large message.
   Hence, the requirement of handling control frames in the middle of a
   fragmented message.

   IMPLEMENTATION NOTE: In the absence of any extension, a receiver
   doesn't have to buffer the whole frame in order to process it.  For
   example, if a streaming API is used, a part of a frame can be
   delivered to the application.  However, note that this assumption
   might not hold true for all future WebSocket extensions.

Notes:

There is no indication or mention of the payload length of the frame with regards to fragmentation. In abstract, it's apparent that the payload length specified in the header of the frame corresponds to the actual frames payload length. However, implementations have been observed that allow the headers payload length to be specified as a higher length than the actual raw payload of that frame. In the event that this occurs, some implementations are reallocating memory to support the length of what is reported as the entire payload of all fragmented messages combined, and continue building the buffer off of each frame from that point forward by allocating enough memory for specified payload length. Obviously, this opens up the potential for a memory consumption DoS attack on an implementation that uses this method. A lack of specification with regards to the RFC allows for such a mistake to happen, as it is not clearly defined in the fragmentation section.

The RFC specifies that fragmented messages should be used to send messages of an unknown length, i.e. streaming media, and therefore should also specify that the frame length bit should be preserved to the length of only that current frame and not be used to specify the overall payload length of all fragmented messages combined. Implementations should be forced to work with them on a frame-by-frame basis and to drop the connection of any instances where the specified length of the frames payload does not match the length of the actual raw payload data for that one frame.
--VERIFIER NOTES--
Thanks, Jonathan, for some useful comments. As we discussed, these aren't appropriate for the errata system, but should be discussed on the relevant mailing list for possibly inclusion in an update or follow-on to the document. That list is <hybi@ietf.org>.

Errata ID: 5453
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2018-08-08
Rejected by: Alexey Melnikov
Date Rejected: 2018-09-20

Section 4.1 says:

   2.  If the response lacks an |Upgrade| header field or the |Upgrade|
       header field contains a value that is not an ASCII case-
       insensitive match for the value "websocket", the client MUST
       _Fail the WebSocket Connection_.

It should say:

   2.  If the response lacks an |Upgrade| header field or the |Upgrade|
       header field contains a value that does not match "WebSocket",
       the client MUST _Fail the WebSocket Connection_.

Notes:

HTTP upgrade tokens are case-sensitive, and the token registered by RFC 6455 is "WebSocket" (see <https://www.iana.org/assignments/http-upgrade-tokens/http-upgrade-tokens.xhtml>). Examples should be adjusted accordingly.

If stricter checks actually break the protocol, an alternative would be to register more variants of the token, such as "websocket".
--VERIFIER NOTES--
See <https://www.rfc-editor.org/errata/eid5498>. Implementations seem to be using "websocket", as shown in all examples in this RFC.

RFC 6458, "Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)", December 2011

Source of RFC: tsvwg (wit)

Errata ID: 6081
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: wanglihe
Date Reported: 2020-04-09
Rejected by: Martin Duke
Date Rejected: 2020-04-27

Throughout the document, when it says:

8.1.26    must indicate that they are
   finished sending a particular record by including the SCTP_EOR flag.

but I can not find where to use SCTP_EOR flag.

because

5.1  The msg_flags are not used when sending a message with sendmsg().

3.1.4  flags:  No new flags are defined for SCTP at this level.  See
      Section 5 for SCTP-specific flags used in the msghdr structure.

4.1.8 same with 3.1.4

9.10, 9.12    flags:  The same flags as used by the sendmsg() call flags (e.g.,
      MSG_DONTROUTE).

9.7   flags:  The same as sinfo_flags (see Section 5.3.2).

5.3.2 sinfo_flags not mention about it  

It should say:

maybe msg_flags should be used.

Notes:

Another problem is that, I think it should be discuss about debfine a flag like SCTP_BOR for beginning(init chunk) of a Record, because a stream of this socket(assoc) can still be used after send a SCTP_EOR.

And between a init chunk and a STCP_EOR, if I change SCTP_EXPLICIT_EOR status, what the socket will send the message?
--VERIFIER NOTES--
6111 addresses the same problem and has a more actionable recommendation.

Errata ID: 6131
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: wanglihe
Date Reported: 2020-04-09
Rejected by: Martin Duke
Date Rejected: 2020-04-27

Throughout the document, when it says:

8.1.26    must indicate that they are
   finished sending a particular record by including the SCTP_EOR flag.

but I can not find where to use SCTP_EOR flag.

because

5.1  The msg_flags are not used when sending a message with sendmsg().

3.1.4  flags:  No new flags are defined for SCTP at this level.  See
      Section 5 for SCTP-specific flags used in the msghdr structure.

4.1.8 same with 3.1.4

9.10, 9.12    flags:  The same flags as used by the sendmsg() call flags (e.g.,
      MSG_DONTROUTE).

9.7   flags:  The same as sinfo_flags (see Section 5.3.2).

5.3.2 sinfo_flags not mention about it  

It should say:

maybe msg_flags should be used.

Notes:

Another problem is that, I think it should be discuss about debfine a flag like SCTP_BOR for beginning(init chunk) of a Record, because a stream of this socket(assoc) can still be used after send a SCTP_EOR.

And between a init chunk and a STCP_EOR, if I change SCTP_EXPLICIT_EOR status, what the socket will send the message?
--VERIFIER NOTES--
This is an accidental duplication; please disregard.

Errata ID: 6132
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: wanglihe
Date Reported: 2020-04-09
Rejected by: Martin Duke
Date Rejected: 2020-04-27

Throughout the document, when it says:

8.1.26    must indicate that they are
   finished sending a particular record by including the SCTP_EOR flag.

but I can not find where to use SCTP_EOR flag.

because

5.1  The msg_flags are not used when sending a message with sendmsg().

3.1.4  flags:  No new flags are defined for SCTP at this level.  See
      Section 5 for SCTP-specific flags used in the msghdr structure.

4.1.8 same with 3.1.4

9.10, 9.12    flags:  The same flags as used by the sendmsg() call flags (e.g.,
      MSG_DONTROUTE).

9.7   flags:  The same as sinfo_flags (see Section 5.3.2).

5.3.2 sinfo_flags not mention about it  

It should say:

maybe msg_flags should be used.

Notes:

Another problem is that, I think it should be discuss about debfine a flag like SCTP_BOR for beginning(init chunk) of a Record, because a stream of this socket(assoc) can still be used after send a SCTP_EOR.

And between a init chunk and a STCP_EOR, if I change SCTP_EXPLICIT_EOR status, what the socket will send the message?
--VERIFIER NOTES--
Accidental duplication; please disregard.

Errata ID: 6133
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: wanglihe
Date Reported: 2020-04-09
Rejected by: Martin Duke
Date Rejected: 2020-04-27

Throughout the document, when it says:

8.1.26    must indicate that they are
   finished sending a particular record by including the SCTP_EOR flag.

but I can not find where to use SCTP_EOR flag.

because

5.1  The msg_flags are not used when sending a message with sendmsg().

3.1.4  flags:  No new flags are defined for SCTP at this level.  See
      Section 5 for SCTP-specific flags used in the msghdr structure.

4.1.8 same with 3.1.4

9.10, 9.12    flags:  The same flags as used by the sendmsg() call flags (e.g.,
      MSG_DONTROUTE).

9.7   flags:  The same as sinfo_flags (see Section 5.3.2).

5.3.2 sinfo_flags not mention about it  

It should say:

maybe msg_flags should be used.

Notes:

Another problem is that, I think it should be discuss about debfine a flag like SCTP_BOR for beginning(init chunk) of a Record, because a stream of this socket(assoc) can still be used after send a SCTP_EOR.

And between a init chunk and a STCP_EOR, if I change SCTP_EXPLICIT_EOR status, what the socket will send the message?
--VERIFIER NOTES--
Accidental duplicate, please disregard.

RFC 6482, "A Profile for Route Origin Authorizations (ROAs)", February 2012

Source of RFC: sidr (rtg)

Errata ID: 7079
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Job Snijders
Date Reported: 2022-08-10
Rejected by: John Scudder
Date Rejected: 2022-09-06

Section 4 says:

   Before a relying party can use a ROA to validate a routing
   announcement, the relying party MUST first validate the ROA.  To
   validate a ROA, the relying party MUST perform all the validation
   checks specified in [RFC6488] as well as the following additional
   ROA-specific validation step.

   o  The IP address delegation extension [RFC3779] is present in the
      end-entity (EE) certificate (contained within the ROA), and each
      IP address prefix(es) in the ROA is contained within the set of IP
      addresses specified by the EE certificate's IP address delegation
      extension.

It should say:

   Before a relying party can use a ROA to validate a routing
   announcement, the relying party MUST first validate the ROA.  To
   validate a ROA, the relying party MUST perform all the validation
   checks specified in [RFC6488] as well as the following additional
   ROA-specific validation step.

   o  The IP address delegation extension [RFC3779] is present in the
      end-entity (EE) certificate (contained within the ROA), and each
      IP address prefix(es) in the ROA is contained within the set of IP
      addresses specified by the EE certificate's IP address delegation
      extension.
   o  The AS Resources extension is not used in Route Origin Authorizations
      and MUST be omitted.

Notes:

The ROA RFC is a bit under-specified compared to other RPKI Signed Object profile definitions. (For example, RFC 8209 § 3.1.3.4 is less ambiguous on the matter of RFC3779 extensions.)
--VERIFIER NOTES--
This is a material (albeit small) change to the spec and doesn't appear to reflect the WG consensus at time of publication. Therefore rejecting, see https://mailarchive.ietf.org/arch/msg/sidr/A_2jMTLbpgpK1H0G3QsVJ44T-kE/ as well.

Errata ID: 7525
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Sacha Boudjema
Date Reported: 2023-05-26
Rejected by: John Scudder
Date Rejected: 2024-01-11

Section 3.3 says:

Within the ROAIPAddressFamily structure, addressFamily contains the Address Family Identifier (AFI) of an IP address family.  This specification only supports IPv4 and IPv6.  Therefore, addressFamily MUST be either 0001 or 0002.

Within a ROAIPAddress structure, the addresses field represents prefixes as a sequence of type IPAddress.  (See [RFC3779] for more details).  If present, the maxLength MUST be an integer ...

It should say:

Within the ROAIPAddressFamily structure, addressFamily contains the Address Family Identifier (AFI) of an IP address family.  This specification only supports IPv4 and IPv6.  Therefore, addressFamily MUST be either 0001 or 0002. The addresses field represents prefixes as a sequence of type ROAIPAddress.  

Within the ROAIPAddress structure, the address field represents an IPv4 or IPv6 prefix of type IPaddress (See [RFC3779] for more details).  If present, the maxLength MUST be an integer ...

Notes:

Original text contradicts does not align with normative ASN.1 schema.
--VERIFIER NOTES--
See discussion on the sidrops list at https://mailarchive.ietf.org/arch/msg/sidrops/cFCZREOerU-jGWWG5zh5PdXTLKE/

This erratum is filed against RFC 6482. Although RFC 6482 has not yet been marked "obsolete", this is only a formality -- draft-ietf-sidrops-rfc6482bis-09 has been approved for publication and is currently in the RFC Editor queue. When editing is complete and rfc6482bis is published as an RFC, 6482 will indeed be obsolete. In that spirit, I'm applying guideline 7 from https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/ and rejecting this erratum. Note that in the thread referenced above, Job says the erratum is fixed in the bis. If it's not, a new erratum should be raised against the bis.

RFC 6487, "A Profile for X.509 PKIX Resource Certificates", February 2012

Note: This RFC has been updated by RFC 7318, RFC 8209

Source of RFC: sidr (rtg)

Errata ID: 3168
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: David Mandelberg
Date Reported: 2012-03-26
Rejected by: Stewart Bryant
Date Rejected: 2013-05-06

Section 4.8 says:

   or non-critical.  A certificate-using system MUST reject the
   certificate if it encounters a critical extension it does not
   recognize; however, a non-critical extension MAY be ignored if it is
   not recognized [RFC5280].

It should say:

   or non-critical.  A certificate-using system MUST reject the
   certificate if it encounters an extension not explicitly mentioned
   in this document.  This is in contrast to RFC 5280 which allows
   non-critical extensions to be ignored.

Notes:

Other sections of the same document contradict the original section 4.8:

Section 1:

Any extensions not explicitly mentioned MUST be absent. The same
applies to the CRLs used in the RPKI, that are also profiled in this
document.

Section 8:

Certificate Extensions:
This profile does not permit the use of any other critical or
non-critical extensions.
--VERIFIER NOTES--
This is a technical change to the RFC and needs to be addressed though the IETF consensus process and rather than via the errata process.

Errata ID: 3174
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: David Mandelberg
Date Reported: 2012-04-03
Rejected by: Stewart Bryant
Date Rejected: 2013-05-06

Section 5 says:

   An RPKI CA MUST include the two extensions, Authority Key Identifier
   and CRL Number, in every CRL that it issues.  RPs MUST be prepared to
   process CRLs with these extensions.  No other CRL extensions are
   allowed.

It should say:

   An RPKI CA MUST include the two extensions, Authority Key Identifier
   and CRL Number, in every CRL that it issues.  The Authority Key
   Identifier extension MUST follow the same restrictions as in
   Section 4.8.3 above.  RPs MUST be prepared to process CRLs with
   these extensions.  No other CRL extensions are allowed.

Notes:

RFC 6487 doesn't specify any restrictions on the format of the AKI extension in CRLs.
--VERIFIER NOTES--
The discussion on the SIDR list concluded that this errata should be rejected, although there appears an issue that may need addressing through a new errata or a revision to the RFC text.

RFC 6497, "BCP 47 Extension T - Transformed Content", February 2012

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 4362
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Ziegast
Date Reported: 2015-05-11
Rejected by: Barry Leiba
Date Rejected: 2015-05-12

Section All says:

This registration is invalid because it attempts to
impose restrictions on field ordering the governing
BCP47 has as illegal for extension subtag
canonicalization. The subtags are limited to 8
characters, and any subfields of a subtag must use a
DIGIT or ALPHA that is not a valid subfield character
as separator, not DASH as specified, to maintain a
particular subfield order.

It should say:

Not correctable, must be reformulated and resubmitted
as new RFC.

Notes:

--VERIFIER NOTES--
BCP 47 requires that extensions have a canonical form. There is no restriction on subtag ordering in an extension imposed by BCP 47, but an extension can specify such an order (in this case it does). Subtags in this RFC are separated by DASH and the dash is not part of any subtag. Unlike the base language tag, there is interplay between subtags, but this is not the same thing as the submitter implies. There exist important implementations that depend on this.

RFC 6515, "IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN", February 2012

Source of RFC: l3vpn (rtg)

Errata ID: 5738
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Jingrong Xie
Date Reported: 2019-05-25
Rejected by: Martin Vigourex
Date Rejected: 2021-02-08

Section 2 says:

   1. "Network Address of Next Hop" field in the MP_REACH_NLRI
      attribute, as defined in Section 3 of [BGP-MP].  This field is
      preceded by a "length of next hop address" field. Hence, it is
      always clear whether the address is an IPv4 address (length is 4)
      or an IPv6 address (length is 16).  If the length of the next hop
      address is neither 4 nor 16, the MP_REACH_NLRI attribute MUST be
      considered to be "incorrect", and MUST be handled as specified in
      Section 7 of [BGP-MP].

It should say:

   1. "Network Address of Next Hop" field in the MP_REACH_NLRI
      attribute, as defined in Section 3 of [BGP-MP].  This field is
      preceded by a "length of next hop address" field. Hence, it is
      always clear whether the address is an IPv4 address (length is 12)
      or an IPv6 address (length is 24).  If the length of the next hop
      address is neither 12 nor 24, the MP_REACH_NLRI attribute MUST be
      considered to be "incorrect", and MUST be handled as specified in
      Section 7 of [BGP-MP].

Notes:

According to section 4.3.2 of RFC4364:
When a PE router distributes a VPN-IPv4 route via BGP, it uses its own address as
the "BGP next hop". This address is encoded as a VPN-IPv4 address with an RD of 0.
The MVPN should follow the same rule to use RD+IPv4 (len 12) or RD+IPv6 (len 24)
in "Network Address of Next Hop".
--VERIFIER NOTES--
as requested by the original poster:
https://mailarchive.ietf.org/arch/msg/bess/V3Qkf-Aeg3oIFiswDVRaSN43tyo/

RFC 6544, "TCP Candidates with Interactive Connectivity Establishment (ICE)", March 2012

Source of RFC: mmusic (rai)

Errata ID: 3231
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Nigel Pattinson
Date Reported: 2012-05-23
Rejected by: Robert Sparks
Date Rejected: 2012-06-07

Section 4 - 11 says:

Notes:

Apologies in advance - I have some feedback on the specification which I feel may be useful, but it is not by nature errata - I wasn't sure how else to report this.

In our company we have just implemented support for ICE-TCP, and in our opinion there are some areas of the specification which could use some clarification. Note that our implementation is designed to be used in an XMPP/Jingle context rather than with SIP, which potentially makes a difference in some of the areas mentioned below.

The specification makes no mention of foundations for TCP candidates. 4.1.1.3 in [RFC5245] specifies that TCP foundations must be different from UDP foundations, but it is unclear whether or not passive, active, and simultaneous open candidates should have distinct foundations. The same is true for NAT-assisted and tunneled candidate types - should these have distinct foundations from server-reflexive/relayed candidates ? We have guessed that in all cases they should be distinct.

4.1.1.4 in [RFC5245] states that server reflexive candidates should be kept alive until ICE processing completes. 11.2 in RFC 6544 does not contradict this, but does not clarify it either. This implies that TCP connections to a STUN server should be kept open for this duration, with STUN binding requests being sent at intervals. It is not clear to us that doing so would have any benefit, but we are not NAT experts. Either way it would be good if the ICE-TCP specification made it clear whether or not this was necessary or desirable.

When the offerer has relayed candidates obtained from a TURN server, it may not be possible to ensure that permissions are created for those passive candidates prior to the peer attempting to connect. This may result in failure of the peer's active check, and hence possibly in failure of ICE as a whole. The same basic problem can happen in ICE-UDP, but the UDP check would almost certainly be retried at a time when the permissions are in place, and so should succeed eventually. The situation could be exacerbated by the Jingle recommendation that candidates are sent to the peer as soon as they are discovered - in this case even the answerer's relayed candidates may not have the permissions in place when they are needed. We're not sure if there is a foolproof solution to these problems, but we do feel that the potential for failures should at least be mentioned.

7.1 states that for tcp-active candidates, unallocated ports should be used. This may result in many port allocations, so we wonder whether it would be preferable to reuse the same port for all connections made from a tcp-active candidate (where supported by the host OS, of course).

Sections 7.1 and 7.2 both note that a peer-reflexive candidate will 'typically' be produced. In 7.1 this is in reference to a STUN response received on an active TCP candidate, whereas in 7.2 it is in reference to a STUN request received on a passive TCP candidate. It is unclear to us whether the wording is intended to mean that this is different to the equivalent case in UDP, where a peer-reflexive candidate might, but would not 'typically', be produced. The only difference between TCP and UDP that we can see in this area is that the port actually used for active TCP candidates differs from that advertised, since all active TCP candidates are offered with 9 as the port number. We assume that this is the core reason behind the wording used, but think that it would be better if the specification explicitly stated this. We also believe that it is possible to correctly identify the correct active TCP candidate despite the lack of explicit port number information, simply by treating 9 as a wildcard that matches any port. Doing so has the benefit that all the information held against the candidate (especially priority and foundation) can be used as intended, whereas if a new peer-reflexive candidate is created this information will always be ignored for active TCP candidates. Currently our implementation does this wildcard matching, so will only produce peer-reflexive candidates in the same situations it would do if using UDP.

11.1 states that connections should be reopened if they have dropped or been closed for some reason, and have media that needs to be sent. This might make sense in an RTP context, but seems very dubious to us in the more general TCP case as it violates the normal reliability guarantees that TCP supplies. We think this requires further thought and at the very least should be configurable.
--VERIFIER NOTES--
Nigel - Thank you for your detailed feedback. As you anticipated, entering an errata is not the best path for you to begin this conversation. Instead, please send your comments to the MMUSIC working group's mail list. (See https://www.ietf.org/mailman/listinfo/mmusic).

RFC 6555, "Happy Eyeballs: Success with Dual-Stack Hosts", April 2012

Note: This RFC has been obsoleted by RFC 8305

Source of RFC: v6ops (ops)

Errata ID: 6745
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Matthew Menke
Date Reported: 2021-11-19
Rejected by: Warren Kumari (Ops AD)
Date Rejected: 2024-01-15

Section 5.6 says:

   Web browsers implement a same-origin policy [RFC6454] that causes
   subsequent connections to the same hostname to go to the same IPv4
   (or IPv6) address as the previous successful connection.  This is
   done to prevent certain types of attacks.

   The same-origin policy harms user-visible responsiveness if a new
   connection fails (e.g., due to a transient event such as router
   failure or load-balancer failure).  While it is tempting to use Happy
   Eyeballs to maintain responsiveness, web browsers MUST NOT change
   their same-origin policy because of Happy Eyeballs, as that would
   create an additional security exposure.

It should say:

<This section should be removed>

Notes:

This entire section should be deleted. Same-Origin policy has nothing to do with what IP connections to the same hostname go to. Two connections to the same host are same origin even if they're using different IPs. Happy Eyeballs is free to use whatever IP for a hostname it wants for an origin, and Same-Origin policy will not be violated.


[ Edit (WK) ]: I am rejecting this Errata because this RFC has been Obsoleted by RFC8305 - "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", which does not contain this text.
--VERIFIER NOTES--

RFC 6564, "A Uniform Format for IPv6 Extension Headers", April 2012

Source of RFC: 6man (int)

Errata ID: 4423
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Fernando Gont
Date Reported: 2015-07-20
Rejected by: Brian Haberman
Date Rejected: 2015-09-15

Section 5 says:

   Any IPv6 extension headers defined in the future, keeping in mind the
   restrictions specified in Section 3 and also the restrictions
   specified in [RFC2460], MUST use the consistent format defined in
   Figure 1.  This minimizes breakage in intermediate nodes that examine
   these extension headers.

It should say:

There's a bug in the logic of this document. Essentially:

   A key problem with the Uniform Format for IPv6 Extension Headers
   [RFC6564] lies in that both IPv6 Extension Headers and Transport
   Protocols share the same namespace ("Next Header" registry/
   namespace).  Thus, given an "unknown Next Header value", it is
   impossible to tell whether the aforementioned value refers to an IPv6
   Extension Header that employs the aforementioned uniform format, or
   an "unknown" upper-layer protocol (e.g. an "unknown" transport
   protocol).  That is, while [RFC6564] specifies the syntax for the
   Uniform Format for IPv6 Extension Headers, but it does not provide a
   mechanism for a node to identify whether the aforementioned format is
   being employed in the first place.

This problem is discussed in: draft-gont-6man-rfc6564bis.

Notes:

The problem is not specifically with Section 5, but rather with the logic in the document.
--VERIFIER NOTES--
The changes proposed go beyond the level of an erratum. The issue should be discussed within the 6MAN working group and a revision of 6564 published if there is consensus to do so.

RFC 6570, "URI Template", March 2012

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 3733
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Franz X Antesberger
Date Reported: 2013-09-23
Rejected by: Barry Leiba
Date Rejected: 2013-10-08

Section 2.4.1 says:

Prefix modifiers are not applicable to variables that have composite 
values.

It should say:

Prefix modifiers are neither applicable to variables that have
composite values, nor to a value which is a list of values or an
associative array of (name, value) pairs.

Notes:

It is not specified, what "{list:1}" with list=["red","green","blue"] produces,
see discussion here https://github.com/uri-templates/uritemplate-test/pull/27
--VERIFIER NOTES--
The spec defines...

In Level 4 templates, a variable may have a composite value in the
form of a list of values or an associative array of (name, value)
pairs. Such value types are not directly indicated by the template
syntax, but they do have an impact on the expansion process
(Section 3.2.1).

...just three paragraphs above that sentence. Hence, a list is a composite
value and the quoted sentence below says that prefix modifiers are not
applicable to them.

RFC 6571, "Loop-Free Alternate (LFA) Applicability in Service Provider (SP) Networks", June 2012

Source of RFC: rtgwg (rtg)

Errata ID: 3561
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Ciril Rozic
Date Reported: 2013-03-20
Rejected by: Stewart Bryant
Date Rejected: 2013-05-06

Section 3.1.1.1 says:

The LFA to P is via C2, because c < d + u.  It is node-protecting if
   eq2: x + e < x + c, i.e., if e < c.

It should say:

The LFA to P is via C2 if x + e < d + u + x.   It is node-protecting if
   eq2: x + e < c + x, i.e., if e < c.

Notes:

The condition for the first sentence e < d + u is not stated in the assumptions in Section 3.

The second sentence is not incorrect, but "c + x" is more consistent with eq1 in Section 2.
--VERIFIER NOTES--
The assumption that c < d + u is stated in section 3.0 (bullet 10) as a design assumption.

RFC 6620, "FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses", May 2012

Source of RFC: savi (int)

Errata ID: 3927
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Leaf Yeh
Date Reported: 2014-03-21
Rejected by: Ted Lemon
Date Rejected: 2014-03-21

Section 2.5 says:

   In order to provide proper
   source address validation, it is critical that the information
   distributed among the different FCFS SAVI devices be coherent.

It should say:

   In order to provide proper
   source address validation, it is critical that the information
   distributed among the different FCFS SAVI devices be not coherent.

Notes:

The above revision then complies with the other statements in the same paragraph:

<quote>
In particular, it is important to avoid having the same source address bound to different binding anchors in different FCFS SAVI devices. Should that occur, then it would mean that two hosts are allowed to send packets with the same source address, which is what FCFS SAVI is trying to prevent. In order to preserve the coherency of the FCFS SAVI bindings distributed among the FCFS SAVI devices within a realm, the Neighbor Discovery (ND) protocol [RFC4861] is used, in particular the Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages.
</quote>
--VERIFIER NOTES--
The proposed change is incorrect. I think you have misunderstood what the word "coherent" means, and this led to confusion.

RFC 6690, "Constrained RESTful Environments (CoRE) Link Format", August 2012

Source of RFC: core (wit)

Errata ID: 5254
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: David Mosberger
Date Reported: 2018-02-03
Rejected by: Francesca Palombini
Date Rejected: 2023-01-18

Section 2 says:

relation-types = relation-type
                   / DQUOTE relation-type *( 1*SP relation-type ) DQUOTE

It should say:

relation-types = reg-rel-type
               / DQUOTE relation-type *( 1*SP relation-type ) DQUOTE

Notes:

As defined originally "relation-types" may consist of a "URI". RFC 3986 defines URI to allow semi-colons in various places. For example, "http://;" seems to be a valid URI. Unfortunately, that makes parsing a link-param list ambiguous since its elements are separated by semicolons.

The proposed fix to to allow "ext-rel-type" (i.e., "URI") to appear only inside a quoted relation-type list.
--VERIFIER NOTES--
Although identifying a valid concern, this errata does not aim to clarify the original intent, but makes changes to the original RFC that were not agreed upon. The change, therefore, if it is to be applied needs to be achieved through a consensus document.

RFC 6698, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", August 2012

Note: This RFC has been updated by RFC 7218, RFC 7671, RFC 8749

Source of RFC: dane (sec)

Errata ID: 3594
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Viktor Dukhovni
Date Reported: 2013-04-16
Rejected by: Stephen Farrell
Date Rejected: 2016-09-19

Section 2.1.1 says:

      2 -- Certificate usage 2 is used to specify a certificate, or the
      public key of such a certificate, that MUST be used as the trust
      anchor when validating the end entity certificate given by the
      server in TLS.  This certificate usage is sometimes referred to as
      "trust anchor assertion" and allows a domain name administrator to
      specify a new trust anchor -- for example, if the domain issues
      its own certificates under its own CA that is not expected to be
      in the end users' collection of trust anchors.  The target
      certificate MUST pass PKIX certification path validation, with any
      certificate matching the TLSA record considered to be a trust
      anchor for this certification path validation.

It should say:

      2 -- Certificate usage 2 is used to specify a certificate, or the
      public key of such a certificate, that MUST be used as the trust
      anchor when validating the end entity certificate given by the
      server in TLS.  This certificate usage is sometimes referred to as
      "trust anchor assertion" and allows a domain name administrator to
      specify a new trust anchor -- for example, if the domain issues
      its own certificates under its own CA that is not expected to be
      in the end users' collection of trust anchors.  The target
      certificate MUST pass PKIX certification path validation, with any
      certificate matching the TLSA record considered to be a trust
      anchor for this certification path validation.  Since clients cannot
      be presumed to have their own copy of the trust-anchor certificate,
      when the TLSA association specifies a certificate digest, the TLS
      server MUST be configured to provide the trust-anchor certificate in
      its "certificate_list" TLS handshake message.

Notes:

As per discussion on the DANE WG list, this was overtaken by events and so is rejected.


This is critical for interoperability between clients and servers. A client that commits to verify TLSA RR certificate associations will fail if it can't obtain the required certificates. With usage "2" there is no presumption that these are available to the client. If servers are not obligated to provide them the protocol will consistently fail. With non-interactive protocols where there is no user to "click OK", such as SMTP, there is no good work-around and both client and server owners suffer.
--VERIFIER NOTES--
As per discussion on the DANE WG list, this was overtaken by events and so is rejected.

RFC 6706, "Asymmetric Extended Route Optimization (AERO)", August 2012

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 3319
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mark Ford
Date Reported: 2012-08-15
Rejected by: Adrian Farrel
Date Rejected: 2012-08-22

Section global says:

No comparison/contrast to Next-Hop Reachability Protocol (RFC 2332) is provided.  

It should say:

A paragraph or more detailing the differences between these two approaches would be welcome and help reduced confusion.

Notes:

There seems to be a strong similarity betweeen AERO and NHRP in terms of overall function.
--VERIFIER NOTES--
A discussion and clarification wrt NHRP, and I understand how that might enrich the work on Aero.

However, the Errata Reporting system is not the right way to raise this issue.
http://www.rfc-editor.org/status_type_desc.html describes the two types of
Errata:
Technical: An error in the technical content.
Editorial: A spelling, grammar, punctuation, or syntax error that does not
affect the technical meaning.
The IESG statement at http://www.ietf.org/iesg/statement/errata-processing.html
gives a more detailed view of what constitutes Errata.

The correct way to advance this particular issue is through email with the
author (possibly also copying an IETF discussion mailing list) and then, if
appropriate through the publication of an Internet-Draft to capture the
discussion or to revise this RFC with the discussion included.

RFC 6726, "FLUTE - File Delivery over Unidirectional Transport", November 2012

Source of RFC: rmt (tsv)

Errata ID: 3870
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Thomas Stockhammer
Date Reported: 2014-01-22
Rejected by: Martin Stiemerling
Date Rejected: 2014-04-16

Section 11.1 says:

Incremented the FLUTE protocol version from 1 to 2, due to concerns
   about backwards compatibility.  For instance, the LCT header changed
   between RFC 3451 and [RFC5651].  In RFC 3451, the T and R fields of
   the LCT header indicate the presence of Sender Current Time and
   Expected Residual Time, respectively.  In [RFC5651], these fields
   MUST be set to zero and MUST be ignored by receivers (instead, the
   EXT_TIME Header Extensions can convey this information if needed).
   Thus, [RFC5651] is not backwards compatible with RFC 3451, even
   though both use LCT version 1.  FLUTE version 1 as specified in
   [RFC3926] MUST use RFC 3451.  FLUTE version 2 as specified in this
   document MUST use [RFC5651].  Therefore, an implementation that
   relies on [RFC3926] and RFC 3451 will not be backwards compatible
   with FLUTE as specified in this document.

It should say:

Incremented the FLUTE protocol version from 1 to 2, due to concerns
   about backwards compatibility.  For instance, the LCT header changed
   between RFC 3451 and [RFC5651].  In RFC 3451, the T and R fields of
   the LCT header indicate the presence of Sender Current Time and
   Expected Residual Time, respectively.  In [RFC5651], these fields
   MUST be set to zero and MUST be ignored by receivers (instead, the
   EXT_TIME Header Extensions can convey this information if needed).
   Thus, [RFC5651] is not backwards compatible with RFC 3451, even
   though both use LCT version 1.  FLUTE version 1 as specified in
   [RFC3926] SHOULD use RFC 3451.  FLUTE version 2 as specified in this
   document MUST use [RFC5651].  Therefore, an implementation that
   relies on [RFC3926] and RFC 3451 will not be backwards compatible
   with FLUTE as specified in this document.

Notes:

The only change that is requested is to change "FLUTE version 1 as specified in
[RFC3926] MUST use RFC 3451." to "FLUTE version 1 as specified in
[RFC3926] SHOULD use RFC 3451. "

This is done as there are deployments that want to use the new functionalities of LCT as defined in RFC5651, but still want to be backward compatible to FLUTE version 1. The above statement being a must prevents this. However, if there are good reasons to not move to FLUTE version 2 (as this would break backward-compatibility for existing receivers), it should be possible to use FLUTE version 1 on top of LCT RFC5651 in order to use the functionalities in RFC5651, especially the header extensions.
--VERIFIER NOTES--
RFC errata are not used to debate MUST or SHOULD clauses, but to report fixes. The RMT mailingt list discussion also hinted to disagreement about this change in general.

RFC 6729, "Indicating Email Handling States in Trace Fields", September 2012

Source of RFC: appsawg (app)

Errata ID: 3337
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: D. Stussy
Date Reported: 2012-09-06
Rejected by: Barry Leiba
Date Rejected: 2012-09-06

Section 3 says:

In Section 6, the "state" clause is added to the Additional-
   Registered-Clauses IANA sub-registry.  The ABNF for this clause is:

      State = CFWS "state" FWS queue-state-keyword [ "/" value ]
...

Notes:

Clarification needed: Does this "state" clause keyword place before, after, or in either order with the "priority" clause keyword specified in RFC 6710? RFC 5321 does not specify an order for additional "Received:" header clauses defined after its publication. The order of additional clauses may need to be defined for proper parsing to determine validity of messages for spam classification or determination of other subversive purposes (as invalid values may indicate bad messages).

(See also the note filed in errata #1 filed for RFC 6710.)
--VERIFIER NOTES--
RFC 5321 gives no indication that the order of clauses in the Additional-Registered-Clauses group matters, and, indeed, the order should not matter. Each clause has a unique (registered) atom, and they can be parsed unambiguously from those.

RFC 6733, "Diameter Base Protocol", October 2012

Note: This RFC has been updated by RFC 7075, RFC 8553

Source of RFC: dime (ops)

Errata ID: 4209
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Hans Liu
Date Reported: 2014-12-25
Rejected by: Benoit Claise
Date Rejected: 2015-01-23

Section 5.4.3 says:

      BUSY                              1
         The peer’s internal resources are constrained, and it has
         determined that the transport connection needs to be closed.
         A receiver of a DPR with above result code SHOULD NOT attempt
         reconnection.

It should say:

      BUSY                              1
         The peer’s internal resources are constrained, and it has
         determined that the transport connection needs to be closed.
         A receiver of a DPR with above result code SHOULD either 
         connect to an alternate node, or attempt reconnection
         after a time period.

Notes:

In most implementations, the Diameter node will continue to serve its peer after the resources recover and expect reconnection. If the Diameter node won't like reconnection from peer, DO_NOT_WANT_TO_TALK_TO_YOU can be used instead of BUSY.
--VERIFIER NOTES--
The text describing the "BUSY" and "DO_NOT_WANT_TO_TALK_TO_YOU" cases is consistent with the text found in the introduction of the section 5.4.

"In the event that the
disconnect was a result of either a shortage of internal resources or
simply that the node in question has no intentions of forwarding any
Diameter messages to the peer in the foreseeable future, a periodic
connection request would not be welcomed. The Disconnection-Reason
AVP contains the reason the Diameter node issued the Disconnect-Peer-
Request message.

The Disconnect-Peer-Request message is used by a Diameter node to
inform its peer of its intent to disconnect the transport layer and
that the peer shouldn't reconnect unless it has a valid reason to do
so (e.g., message to be forwarded). "

So the main purpose for sending a DPR with the causes "BUSY" and "DO_NOT_WANT_TO_TALK_TO_YOU" is actually to avoid the periodic reconnection attempts governed by the Tc timer.
These exceptions are mentioned in the section 2.1:

"When no transport connection exists with a peer, an attempt to
connect SHOULD be made periodically. This behavior is handled via
the Tc timer (see Section 12 for details), whose recommended value is
30 seconds. There are certain exceptions to this rule, such as when
a peer has terminated the transport connection stating that it does
not wish to communicate."

Now, it is true that there is no clear guideline on how to behave when receiving the cause "BUSY" and this explains why some implementations in the field still attempt to re-open the connection, as after a normal transport failure detection. But it does not mean that the text in the RFC6733 is wrong.

Finally, if it is an attempt to clarify/modify the behavior of the peer receiving DPR with the "BUSY" cause, I don't think that using errata would be the most appropriate way.

Errata ID: 4462
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Keshab Upadhya
Date Reported: 2015-09-01
Rejected by: Stephen Farrell
Date Rejected: 2015-09-11

Section 6.1.4 6.1.6 says:

6.1.4.  Processing Local Requests

   A request is known to be for local consumption when one of the
   following conditions occurs:

   o  The Destination-Host AVP contains the local host's identity;

   o  The Destination-Host AVP is not present, the Destination-Realm AVP
      contains a realm the server is configured to process locally, and
      the Diameter application is locally supported; or

   o  Both the Destination-Host and the Destination-Realm are not
      present.

6.1.6.  Request Routing

   Diameter request message routing is done via realms and Application
   Ids. A Diameter message that may be forwarded by Diameter agents
   (proxies, redirect agents, or relay agents) MUST include the target
   realm in the Destination-Realm AVP.  Request routing SHOULD rely on
   the Destination-Realm AVP and the Application Id present in the
   request message header to aid in the routing decision.  The realm MAY
   be retrieved from the User-Name AVP, which is in the form of a
   Network Access Identifier (NAI).  The realm portion of the NAI is
   inserted in the Destination-Realm AVP.

   Diameter agents MAY have a list of locally supported realms and
   applications, and they MAY have a list of externally supported realms
   and applications.  When a request is received that includes a realm
   and/or application that is not locally supported, the message is
   routed to the peer configured in the routing table (see Section 2.7).

   Realm names and Application Ids are the minimum supported routing
   criteria, additional information may be needed to support redirect
   semantics.

It should say:

6.1.6 -
  When a request is received that includes a realm
   and/or application that is not locally supported, the message is
   routed to the peer configured

conflicts with 6.1.4 -
   The Destination-Host AVP is not present, the Destination-Realm AVP
      contains a realm the server is configured to process locally, and
      the Diameter application is locally supported

Notes:

please guide if 6.1.4 Local processing - "hostname not present" needs to be amended by "not present in host peer routing table". otherwise it conflicts with 6.1.6.
--VERIFIER NOTES--
DIME WG chairs report this is erroneous.

Errata ID: 4463
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Keshab Upadhya
Date Reported: 2015-09-01
Rejected by: Stephen Farrell
Date Rejected: 2015-09-11

Section 6.1.7 says:

6.1.7.  Predictive Loop Avoidance

It should say:

6.1.7.  Predictive Loop Detection and termination

Notes:

one full cycle of loop execution happens before route record is identified and loop being realized. A scenario example where two Diameter Agents are configured to do precedence based routing to two different hss and where as if hss otherwise does loadshare using 4 different links each in such cases loop can even be reach stage 2 before being realized therefore it doesn't qualify the avoidance or prevention rather detection and termination. thanks.
--VERIFIER NOTES--

There is no need or benefit from this change.

Errata ID: 4473
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Keshab Upadhya
Date Reported: 2015-09-14
Rejected by: Stephen Farrell
Date Rejected: 2015-10-07

Section 6.1.4 says:

6.1.4.  Processing Local Requests

The Destination-Host AVP is not present, the Destination-Realm AVP
contains a realm the server is configured to process locally, and
the Diameter application is locally supported; or

It should say:

6.1.4.  Processing Local Requests

The Destination-Host AVP is not present in peer routing table, 
the Destination-Realm AVP contains a realm the server is 
configured to process locally, and 
the Diameter application is locally supported; or

Notes:

6.1.4 - Processing Local Requests

The Destination-Host AVP is not present, the Destination-Realm AVP
contains a realm the server is configured to process locally, and
the Diameter application is locally supported

6.1.6 - Request Routing

When a request is received that includes a realm
and/or application that is not locally supported, the message is
routed to the peer configured

As given above 6.1.4 second rule contradicts with 6.1.6 para 2.
--VERIFIER NOTES--
DIME chairs recommended reject

Errata ID: 4931
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Luiz Solis
Date Reported: 2017-02-09
Rejected by: Benoit Claise
Date Rejected: 2017-02-10

Section 6.1.9 says:

Figure 6.1 provides an example of message routing using the procedures
listed in these sections.

(Origin-Host=nas.example.net)    (Origin-Host=nas.example.net)
(Origin-Realm=example.net)       (Origin-Realm=example.net)
(Destination-Realm=example.com)  (Destination-Realm=example.com)
                                 (Route-Record=nas.example.net)

+------+      ------>      +------+      ------>      +------+
|      |     (Request)     |      |      (Request)    |      |
| NAS  +-------------------+ DRL  +-------------------+ HMS  |
|      |                   |      |                   |      |
+------+     <------       +------+     <------       +------+
example.net    (Answer)   example.net     (Answer)   example.com
(Origin-Host=hms.example.com)   (Origin-Host=hms.example.com)
(Origin-Realm=example.com)      (Origin-Realm=example.com)

       Figure 6: Routing of Diameter messages

It should say:

Figure 6.1 provides an example of message routing using the procedures
listed in these sections.

(Origin-Host=nas.example.net)    (Origin-Host=nas.example.net)
(Origin-Realm=example.net)       (Origin-Realm=example.net)
(Destination-Realm=example.com)  (Destination-Realm=example.com)
(Route-Record=nas.example.net)*  (Route-Record=nas.example.net)
                                 (Route-Record=drl.example.net)*
+------+      ------>      +------+      ------>      +------+
|      |     (Request)     |      |      (Request)    |      |
| NAS  +-------------------+ DRL  +-------------------+ HMS  |
|      |                   |      |                   |      |
+------+     <------       +------+     <------       +------+
example.net    (Answer)   example.net     (Answer)   example.com
(Origin-Host=hms.example.com)   (Origin-Host=hms.example.com)
(Origin-Realm=example.com)      (Origin-Realm=example.com)

*Optional.

                  Figure 6: Routing of Diameter messages

Notes:

The relay or proxy agent should append their own identity optionally in an additional Route-Record AVP (282).
--VERIFIER NOTES--
The Route-Record is primarily used to detect loops:

6.1.3. Receiving Requests

A relay or proxy agent MUST check for forwarding loops when receiving
requests. A loop is detected if the server finds its own identity in
a Route-Record AVP. When such an event occurs, the agent MUST answer
with the Result-Code AVP set to DIAMETER_LOOP_DETECTED.

How to populate the Route-Record is described twice:

Section 2.9:

As noted in Section 6.1.9, a relay or proxy agent MUST append a
Route-Record AVP to all requests forwarded. The AVP contains the
identity of the peer from which the request was received.

6.7.1. Route-Record AVP

The Route-Record AVP (AVP Code 282) is of type DiameterIdentity. The
identity added in this AVP MUST be the same as the one received in
the Origin-Host of the Capabilities Exchange message.

Therefore, it's "rather clear" that a relay and a proxy MUST append a Route-Record to all requests forwarded with the identity of the peer from which the request was received

I think that Luis was maybe misled by the following text:

6.1.3. Receiving Requests

A relay or proxy agent MUST check for forwarding loops when receiving
requests. A loop is detected if the server finds its own identity in
a Route-Record AVP. When such an event occurs, the agent MUST answer
with the Result-Code AVP set to DIAMETER_LOOP_DETECTED.

in which "find its own identity" might have been confusing out of context. But sections 2.9 and 6.7.1 should have clarified this misunderstanding.

Whatever the reason for the proposed errata, it can be safely rejected.

Errata ID: 6833
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Kshitij Dutt
Date Reported: 2022-02-03
Rejected by: Rob Wilton
Date Rejected: 2023-10-02

Section 2.4 says:

The following Application Id values are defined:

         Diameter common message       0
         Diameter base accounting      3
         Relay                         0xffffffff

It should say:

The following Application Id values are defined:

         Diameter common message       0
         Diameter base accounting      3
         Relay                         0xffffff

Notes:

I presume relay application ID should be 0xffffff decimal equivalent of which is 16777215.
Instead 0xffffffff decimal translates to 4294967295.

This is assumption.
--VERIFIER NOTES--
The Application-ID field in the Diameter header is 32 bits long, hence the exist Application Id for "Relay" is correct.

RFC 6735, "Diameter Priority Attribute-Value Pairs", October 2012

Source of RFC: dime (ops)

Errata ID: 3859
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Hyungho Kim
Date Reported: 2014-01-02
Rejected by: Benoit Claise
Date Rejected: 2014-03-18

Section 5.1 says:

ALRP-Value                             617  3.4.2     Unsigned32

It should say:

ALRP-Value                             617  3.4.2     Unsigned8

Notes:

Conflicts with section 3.4.2, which says "The ALRP-Value AVP (AVP Code 617) is of type Unsigned8"
--VERIFIER NOTES--
In accordance with the DIME chairs: The introduction of new data types would imply a new version of the Base protocol..

"In the event that a new Basic AVP Data Format is needed,
a new version of this RFC MUST be created."

A bis document is required.

RFC 6749, "The OAuth 2.0 Authorization Framework", October 2012

Note: This RFC has been updated by RFC 8252, RFC 8996

Source of RFC: oauth (sec)

Errata ID: 3880
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Eriksen Costa
Date Reported: 2014-02-04
Rejected by: Kathleen Moriarty
Date Rejected: 2015-12-08

Section 10.16 says:

For public clients using implicit flows, this specification does not
provide any method for the client to determine what client an access
token was issued to.

It should say:

For public clients using implicit flows, this specification does not
provide any method for the authorization server to determine what
client an access token was issued to.

Notes:

A client can only know about tokens issued to it and not for other clients.

From the WG:
https://www.ietf.org/mail-archive/web/oauth/current/msg12391.html
--VERIFIER NOTES--
The current text is correct, see https://www.ietf.org/mail-archive/web/oauth/current/msg12391.html

RFC 6751, "Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises Equipment (6a44)", October 2012

Source of RFC: INDEPENDENT

Errata ID: 3385
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Andreas Cudok
Date Reported: 2012-10-18
Rejected by: Nevil Brownlee
Date Rejected: 2014-01-20

Section 6.6.2 says:

RR4-5 INVALID IPv6/UDP/IPv4 PACKET

      For ANY other case, the 6a44 relay MUST discard the packet.

It should say:

RR4-5 INVALID IPv6/UDP/IPv4 PACKET: INCONSISTENT SOURCE ADDRESSES

      If ALL the following conditions are satisfied, the 6a44 relay
      MUST discard the packet and return to the source an
      error-signaling bubble (i.e., with the "Bubble ID" field set
      to 0) which conveys the up-to-date IPv6 prefix of the client:
      (1) the IPv4 packet contains a complete UDP datagram (protocol
      = 17, offset = 0, more-fragment bit = 0); (2) the UDP payload
      is an IPv6 packet (length of at least 40 octets, version = 6);
      (3) the IPv6 source address starts with the 6a44-network IPv6
      prefix followed by a value (in the field that is composed of
      bits 48-79) that is different from the UDP/IPv4 source address
      of the received packet; (4) the IPv6 destination address is
      not a Teredo address whose embedded IPv4 address is the
      6a44-relay anycast address.

RR4-6 INVALID IPv6/UDP/IPv4 PACKET: ANY OTHER INVALID PACKET

      For ANY other case, the 6a44 relay MUST silently discard the
      packet.

Notes:

The conditions when to send an error-signaling bubble must be exactly specified. This is done by the modified RR4-5 rule. The orginal rule has moved to RR4-6 and changed from "discard" to "silently discard", i.e. without returning an error-signaling bubble to the source.

The reference "(i.e., not conforming to R44-2 condition (3) in Section 6.6.2)" in section 6.3 (which is wrong anyway because rule R44-2 doesn't exist) should be replaced by "(i.e., conformig to RR4-5 condition in Section 6.6.2)"
--VERIFIER NOTES--
Replaced bby Erratum 3388

RFC 6761, "Special-Use Domain Names", February 2013

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 4970
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexander Lay
Date Reported: 2017-03-15
Rejected by: Warren Kumari
Date Rejected: 2017-06-12

Section 6.1 says:

168.192.in-addr.arpa.

It should say:

192.168.in-addr.arpa.

Notes:

The IP address ranges listed in this document as private do not align with those listed as private in the referenced RFC 1918.
--VERIFIER NOTES--
Nope, there are in "reverse lookup" format.


The useful references are probably:
https://tools.ietf.org/html/rfc1033 Section IN-ADDR.ARPA and
https://tools.ietf.org/html/rfc6303 Section 4.1. RFC 1918 Zones.

More info (from rfc1033):
IN-ADDR.ARPA

The structure of names in the domain system is set up in a
hierarchical way such that the address of a name can be found by
tracing down the domain tree contacting a server for each label of
the name. Because of this 'indexing' based on name, there is no easy
way to translate a host address back into its host name.

In order to do the reverse translation easily, a domain was created
that uses hosts' addresses as part of a name that then points to the
data for that host. In this way, there is now an 'index' to hosts'
RRs based on their address. This address mapping domain is called
IN-ADDR.ARPA. Within that domain are subdomains for each network,
based on network number. Also, for consistency and natural
groupings, the 4 octets of a host number are reversed.

For example, the ARPANET is net 10. That means there is a domain
called 10.IN-ADDR.ARPA. Within this domain there is a PTR RR at
51.0.0.10.IN-ADDR that points to the RRs for the host SRI-NIC.ARPA
(who's address is 10.0.0.51). Since the NIC is also on the MILNET
(Net 26, address 26.0.0.73), there is also a PTR RR at 73.0.0.26.IN-
ADDR.ARPA that points to the same RR's for SRI-NIC.ARPA. The format
of these special pointers is defined below along with the examples
for the NIC.

PTR

<special-name> [<ttl>] [<class>] PTR <name>

The PTR record is used to let special names point to some other
location in the domain tree. They are mainly used in the IN-
ADDR.ARPA records for translation of addresses to names. PTR's
should use official names and not aliases.

For example, host SRI-NIC.ARPA with addresses 10.0.0.51 and 26.0.0.73
would have the following records in the respective zone files for net
10 and net 26:

51.0.0.10.IN-ADDR.ARPA. PTR SRI-NIC.ARPA.
73.0.0.26.IN-ADDR.ARPA. PTR SRI-NIC.ARPA.

Errata ID: 5025
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Kohl
Date Reported: 2017-05-25
Rejected by: Warren Kumari
Date Rejected: 2017-06-12

Section 6.1 says:

   The private-address [RFC1918] reverse-mapping domains listed below,
   and any names falling within those domains, are Special-Use Domain
   Names:

     10.in-addr.arpa.      21.172.in-addr.arpa.  26.172.in-addr.arpa.
     16.172.in-addr.arpa.  22.172.in-addr.arpa.  27.172.in-addr.arpa.
     17.172.in-addr.arpa.  30.172.in-addr.arpa.  28.172.in-addr.arpa.
     18.172.in-addr.arpa.  23.172.in-addr.arpa.  29.172.in-addr.arpa.
     19.172.in-addr.arpa.  24.172.in-addr.arpa.  31.172.in-addr.arpa.
     20.172.in-addr.arpa.  25.172.in-addr.arpa.  168.192.in-addr.arpa.

It should say:

   The private-address [RFC1918] reverse-mapping domains listed below,
   and any names falling within those domains, are Special-Use Domain
   Names:

     10.in-addr.arpa.      21.172.in-addr.arpa.  26.172.in-addr.arpa.
     16.172.in-addr.arpa.  22.172.in-addr.arpa.  27.172.in-addr.arpa.
     17.172.in-addr.arpa.  30.172.in-addr.arpa.  28.172.in-addr.arpa.
     18.172.in-addr.arpa.  23.172.in-addr.arpa.  29.172.in-addr.arpa.
     19.172.in-addr.arpa.  24.172.in-addr.arpa.  30.172.in-addr.arpa.
     20.172.in-addr.arpa.  25.172.in-addr.arpa.  31.172.in-addr.arpa.
     168.192.in-addr.arpa

Notes:

30.172.in-addr.arpa. is missing in the original list.
--VERIFIER NOTES--
Actually, as noted in Errata ID: 5039 it's not missing - it is between 22.172.in-addr.arpa and 23.172.in-addr.arpa. I've marked Errata 5039 as "Held for update" and am rejecting this one.

RFC 6762, "Multicast DNS", February 2013

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: int

Errata ID: 4529
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Willem Bermon
Date Reported: 2015-11-11
Rejected by: Brian Haberman
Date Rejected: 2016-04-05

Section Appendix G says:

We do not recommend use of unregistered top-level
   domains at all, but should network operators decide to do this, the
   following top-level domains have been used on private internal
   networks without the problems caused by trying to reuse ".local." for
   this purpose:

      .intranet.
      .internal.
      .private.
      .corp.
      .home.
      .lan.

It should say:

We do not recommend use of unregistered top-level domains.

Notes:

Since TLDs like .private are currently available for register. Appendix G is outdated and I would strongly advise the IETF to remove the suggested TLDs since they are no longer problem free. I believe that it is wise to make a harder statement in the RFC.
--VERIFIER NOTES--
During the development of this RFC, the text is consistent with the consensus of the community. Later developments by ICANN superseded the appendix, but that is not applicable for an erratum. Updates to the text should be proposed via the draft publication process.

RFC 6797, "HTTP Strict Transport Security (HSTS)", November 2012

Source of RFC: websec (app)

Errata ID: 4075
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Eric Lawrence
Date Reported: 2014-08-08
Rejected by: Barry Leiba
Date Rejected: 2014-08-11

Section 14 says:

   Without the "includeSubDomains" directive, HSTS is unable to protect
   such Secure-flagged domain cookies.

It should say:

   Without the "includeSubDomains" directive, HSTS is unable to protect
   such Secure-flagged domain cookies.

   Even with the "includeSubDomains" directive, the unavailability of 
   an "includeParent" directive means that an Active MITM attacker can 
   perform a cookie-injection attack against an otherwise 
   HSTS-protected victim domain.

   Consider the following scenario:

    The user visits https://sub.example.com and gets a HSTS policy with
    includeSubdomains set. All subsequent navigations to 
    sub.example.com and its subdomains will be secure.

    An attacker causes the victim's browser to navigate to 
    http://example.com. Because the HSTS policy applies only to 
    sub.example.com and its superdomain matches, this insecure 
    navigation is not blocked by the user agent.

    The attacker intercepts this insecure request and returns a 
    response that sets a cookie on the entire domain tree using a 
    Set-Cookie header.

    All subsequent requests to sub.example.com carry the injected
    cookie, despite the use of HSTS.

Notes:

To mitigate this attack, HSTS-protected websites should perform a background fetch of a resource at the first-level domain. This resource should carry a HSTS header that will apply to the entire domain and all subdomains.
--VERIFIER NOTES--
This is a valid issue, but not suitable for the errata system. The websec working group is discussing handling this with a short document to update RFC 6797.

RFC 6839, "Additional Media Type Structured Syntax Suffixes", January 2013

Note: This RFC has been updated by RFC 7303

Source of RFC: appsawg (app)

Errata ID: 4367
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Yakov Shafranovich
Date Reported: 2015-05-15
Rejected by: Barry Leiba
Date Rejected: 2015-05-28

Section 3.1 says:

Encoding considerations:

      Per [RFC4627], JSON is allowed to be represented using UTF-8,
      UTF-16, or UTF-32.  When JSON is written in UTF-8, JSON is 8bit
      compatible ([RFC2045]).  When JSON is written in UTF-16 or UTF-32,
      JSON is binary ([RFC2045]).

It should say:

Encoding considerations:  binary as per section 11 of RFC 7159

Notes:

RFC 7159, section 11 specifies that encoding for JSON is binary.
--VERIFIER NOTES--
This does not qualify as an erratum, but do see the mailing list discussion that starts here:
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg14321.html

RFC 6840, "Clarifications and Implementation Notes for DNS Security (DNSSEC)", February 2013

Note: This RFC has been updated by RFC 8749

Source of RFC: dnsext (int)

Errata ID: 4191
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Edward Lewis
Date Reported: 2014-12-02
Rejected by: Brian Haberman
Date Rejected: 2015-01-12

Section 5.11 says:

...

A signed zone MUST include a DNSKEY for each algorithm present in
      the zone's DS RRset and expected trust anchors for the zone.  The
      zone MUST also be signed with each algorithm (though not each key)
      present in the DNSKEY RRset.  

It should say:

A signed zone MUST include a DNSKEY for each algorithm present in
      the zone's DS RRset and expected trust anchors for the zone.  Each
      authoritative RRset in the zone MUST be signed with each 
      algorithm (though not each key) present in the DNSKEY RRset.  

Notes:

Zones aren't signed (per se), the data sets within them are. But not cut point (NS) and glue.
--VERIFIER NOTES--
This erratum is being rejected as the nomenclature being updated is understood within the community and is used in other DNSSEC specifications.

RFC 6844, "DNS Certification Authority Authorization (CAA) Resource Record", January 2013

Note: This RFC has been obsoleted by RFC 8659

Source of RFC: pkix (sec)

Errata ID: 4061
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Evan Hunt
Date Reported: 2014-07-24
Rejected by: Kathleen Moriarty
Date Rejected: 2014-09-03

Section 5.1 says:

Tag values SHOULD NOT contain any other characters.

It should say:

Tag values MUST NOT contain any other characters.

Notes:

Since the text representation of the tag field is unquoted, spaces and other whitespace must be explicitly excluded. Otherwise, it is possible to create a CAA record whose text representation cannot be parsed.
--VERIFIER NOTES--
This really gets down to MUST/SHOULD theology and whether you consider
the zone file syntax at the same level of conformance as DNS protocol.

The author believes SHOULD is correct here. The protocol on the wire will work
just fine if someone breaks this advice.

Yes, it might well break some zone file parsers. But those aren't on
the wire and that type of incompatibility is exactly what I would
expect from violating a SHOULD.

Code has to work if someone creates a RR with a non conformant label,
therefore a MUST does not saves any work. And the only circumstance in
which the editor can imagine someone using it would be where they wanted a
label that could not be inserted through normal zone files.

Phil Hallam-Baker certainly doesn't want people writing parsers to strip out records
with non conformant labels. So, stick with SHOULD.

Errata ID: 4515
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Tom Clegg
Date Reported: 2015-10-29
Rejected by: Kathleen Moriarty
Date Rejected: 2017-08-22

Section 4 says:

   o  If A(X) is not null, and R(A(X)) is not empty, then R(X) =
      R(A(X)), otherwise

It should say:

   o  If A(X) is not null, and CAA(A(X)) is not empty, then R(X) =
      CAA(A(X)), otherwise

Notes:

R is the algorithm being described here, so R(A(X)) means a recursive search on the CNAME target, including its parents. However, the example that follows, Parent(Alias(x.y.z)) is not part of the search. Either the algorithm is incorrectly specified, or the example is incomplete.

While this change is correct, it has already been accepted with HFDU in errata 5065.
--VERIFIER NOTES--
Errata 5065 was accepted first and covers this error.

Errata ID: 4922
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Attila Bruncsák
Date Reported: 2017-02-03
Rejected by: Stephen Farrell
Date Rejected: 2017-02-03

Section 4 says:

The search for a CAA record climbs the DNS name tree from the
   specified label up to but not including the DNS root '.'.

It should say:

The search for a CAA record must not climb the DNS name tree from the
   specified label up.

Notes:

Obviously it does not make any sense to climb up. If there would be CAA record published for the "com" TLD, than it would make what relation to the CAA of the "example.com" domain? From an other viewpoint: all CAs are going to check the "com" TLD for CAA record if a given organization has no CAA record published in its own domain?
Another, more practical example: "example.com" needs a certificate for his top domain (https://example.com/), so it decides to publish the CAA record to enforce the security. Doing this it may unknowingly affect the renewal of the certificate for the wellhidden.hr.example.com where the hr.example.com domain is under different administrative authority than example.com domain itself.
--VERIFIER NOTES--
This would be a change and hence is not an erratum

RFC 6846, "RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)", January 2013

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: tsv

Errata ID: 3669
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Raj Kumar
Date Reported: 2013-06-24
Rejected by: Martin Stiemerling
Date Rejected: 2013-06-24

Section 8.2 says:

 COMPRESSED ipv4_innermost_irregular {
    ENFORCE(is_innermost == 1);
    ip_id          =:=
      ip_id_enc_irreg(ip_id_behavior_innermost.UVALUE) [ 0, 16 ];
    ENFORCE(ip_inner_ecn == ip_ecn_flags.UVALUE);
  }

It should say:

COMPRESSED ipv4_innermost_irregular {
    ENFORCE(is_innermost == 1);
    ip_id          =:=
      ip_id_enc_irreg(ip_id_behavior_innermost.UVALUE) [ 0, 16 ];
    
  }

Notes:

I don't find any reason why IP-ID encoding in ipv4 irregular chain, should be dependent on ECN flags.
--VERIFIER NOTES--
"This errata is invalid. Those bits need to be bound in the format and needs to be done so in the irregular chain for the inner header which does special treatment for these."

Errata ID: 3724
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Raj Kumar
Date Reported: 2013-09-12
Rejected by: Martin Stiemerling
Date Rejected: 2013-09-20

Section 8.2 says:

tcp_opt_eol(nbits)
{
UNCOMPRESSED {
type =:= uncompressed_value(8, 0) [ 8 ];
padding =:=
uncompressed_value(nbits-8, 0) [ nbits-8 ];
}
CONTROL {
pad_len [ 8 ];
}
COMPRESSED eol_list_item {
pad_len =:= compressed_value(8, nbits-8) [ 8 ];
}
COMPRESSED eol_irregular {
pad_len =:= static;
ENFORCE(nbits-8 == pad_len.UVALUE);
}
}

It should say:

tcp_opt_eol(nbits)
{
UNCOMPRESSED {
type =:= uncompressed_value(8, 0) [ 8 ];
padding =:=
uncompressed_value(nbits-8, 0) [ nbits-8 ];
}
CONTROL {
pad_len [ 8 ];
}
COMPRESSED eol_list_item {

}
pad_len can be calculated at De compressor by following formula
pad_len = 4 -(length of uncompressed header formed till EOL byte % 4)

COMPRESSED eol_irregular {
pad_len =:= static;
ENFORCE(nbits-8 == pad_len.UVALUE);
}
}

Notes:

pad_len has the potential to become Inferred field, by doing this we can save one byte in compressed header and can effectively increase the compression efficiency.
--VERIFIER NOTES--
Rejected, as this is not an errata, as the 'corrected text' is in fact a change to the formal definition of the header formats.

RFC 6874, "Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers", February 2013

Source of RFC: 6man (int)

Errata ID: 3630
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Sweet
Date Reported: 2013-05-22
Rejected by: Brian Haberman
Date Rejected: 2013-05-23

Section 3 says:

   Such bare "%" signs are for user interface convenience, and need to
   be turned into properly encoded characters (where "%25" encodes "%")
   before the URI is used in any protocol or HTML document.  However,
   URIs including a ZoneID have no meaning outside the originating node.
   It would therefore be highly desirable for a browser to remove the
   ZoneID from a URI before including that URI in an HTTP request.

It should say:

   Such bare "%" signs are for user interface convenience, and need to
   be turned into properly encoded characters (where "%25" encodes "%")
   before the URI is used in any protocol or HTML document.  HTTP Clients
   MUST include a ZoneID in any URIs provided in an HTTP request since
   HTTP Servers will need it when generating URIs, otherwise the IPv6
   address will not be routable.

Notes:

The original advice ignores a very real issue: HTTP Servers that generate URIs from the client's Host: need to include the Client's zoneid in order for the link local address to be usable/routable.
--VERIFIER NOTES--
The zoneid is internal to the HTTP client. It would never be shared with a server, so there is no way for a server to know a client's zoneid.

Errata ID: 3631
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Sweet
Date Reported: 2013-05-22
Rejected by: Brian Haberman
Date Rejected: 2013-05-23

Section 4 says:

   An HTTP client, proxy, or other intermediary MUST remove any ZoneID
   attached to an outgoing URI, as it has only local significance at the
   sending host.

It should say:

   An HTTP client, proxy, or other intermediary MUST retain any ZoneID
   attached to an outgoing URI, as it will be the only way for an HTTP server
   to return a URI containing a link-local address that can subsequently be
   used by the HTTP client.

Notes:

The original advice ignores a very real issue: HTTP Servers that generate URIs from the client's Host: need to include the Client's zoneid in order for the link local address to be usable/routable.
--VERIFIER NOTES--
The zoneid is a strictly internal value that is not shared between devices.

Errata ID: 3632
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Sweet
Date Reported: 2013-05-23
Rejected by: Brian Haberman
Date Rejected: 2014-05-16

Section 3 says:

  Such bare "%" signs are for user interface convenience, and need to
  be turned into properly encoded characters (where "%25" encodes "%")
  before the URI is used in any protocol or HTML document.  However,
  URIs including a ZoneID have no meaning outside the originating node.
  It would therefore be highly desirable for a browser to remove the
  ZoneID from a URI before including that URI in an HTTP request.

It should say:

  Such bare "%" signs are for user interface convenience, and need to
  be turned into properly encoded characters (where "%25" encodes "%")
  before the URI is used in any protocol or HTML document.  HTTP Clients
  MUST include a ZoneID in any URIs provided in an HTTP request since
  HTTP Servers will need it when generating URIs, otherwise the IPv6
  address will not be usable by the Client.

Notes:

NOTE: PLEASE DO NOT REJECT THIS ERRATA BEFORE FURTHER REVIEW. I WILL BE SUBMITTING A NEW DRAFT PROPOSING THESE CHANGES; THIS ERRATA CAN SERVE AS PUBLIC NOTICE OF POTENTIAL CHANGES TO THE RFC.

The client uses the zoneid to choose a network interface to route packets to that link local address. If the server returns a uri in its response that uses the same link local address but without the client's zoneid, then the client will be unable to use said uri because it won't know which interface to use. Yes the server doesn't care about the zoneid but the client depends on it (for link local anyways).

The client can supply the zoneid in the Host header. For example, the following illustrates a typical IPP request using the previously recommended IPvFuture format (which CUPS implements and uses):

POST /ipp/print HTTP/1.1
Host: [v1.fe80::1234+en0]:631
Content-Type: application/ipp
Transfer-Coding: chunked

... IPP request ...

The printer then validates the Host header and responds with URIs containing the same Host value in any reported IPv6 link-local URIs.

The key issue is one of context - the client *may* be able to query the interface used for a particular socket connection but it probably can't (easily) cache and map this information in the URIs that are embedded in the content returned by the printer, particularly when the client may have to process said content from a variety of sources - IPP is also supported over a USB transport, HTML can be read from disk, etc. Clients are usually unable to connect to a given IPv6 link local address without the zoneid information to tell them which network interface to use. And typically the only reason clients use an IPv6 link local address is because it was handed to them by a discovery protocol like WS-Discovery...

Requiring the client to rewrite all URIs is a tremendous burden and is error-prone. Requiring the server to use the Host header is cheap in comparison. Having the server validate and use the Host value also helps interoperability since existing clients may not support the new IPv6addrz format - for example, CUPS doesn't support it since it validates URIs and Host values using the ABNF in RFC 3986/STD 66.

The Host header mechanism has been standard practice outside the IETF for several years now. It is part of IPP Everywhere (Printer Working Group), Wi-Fi Direct Print Services (Wi-Fi Alliance), IPP USB (USB Implementers Forum), and AirPrint (Apple). It solves the problem of client-side routing of IPv6 link local addresses that are used in URIs embedded in content returned by printers and other embedded devices.

Hundreds of millions of printers, computers, and mobile devices have been certified and shipped with IPv6 link local support using the IPvFuture format over the last 8 years. The new format is incompatible with parsers that use the ABNF in STD 66 (aka RFC 3986) and prevents the use of the Host header in HTTP requests to provide a backwards-compatible IPv6 implementation.
--VERIFIER NOTES--
The errata system is not intended as a notification system for potentially new work.

Errata ID: 3633
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Sweet
Date Reported: 2013-05-23
Rejected by: Ted Lemon
Date Rejected: 2014-05-01

Section 4 says:

  An HTTP client, proxy, or other intermediary MUST remove any ZoneID
  attached to an outgoing URI, as it has only local significance at the
  sending host.

It should say:

  An HTTP client, proxy, or other intermediary MUST retain any
  ZoneID attached to an outgoing URI, as it will be the only way
  for an HTTP server to return a URI containing a link-local address
  that can subsequently be used by the HTTP client.

Notes:

NOTE: PLEASE DO NOT REJECT THIS ERRATA BEFORE FURTHER REVIEW. I WILL BE SUBMITTING A NEW DRAFT PROPOSING THESE CHANGES; THIS ERRATA CAN SERVE AS PUBLIC NOTICE OF POTENTIAL CHANGES TO THE RFC.

The client uses the zoneid to choose a network interface to route packets to that link local address. If the server returns a uri in its response that uses the same link local address but without the client's zoneid, then the client will be unable to use said uri because it won't know which interface to use. Yes the server doesn't care about the zoneid but the client depends on it (for link local anyways).

The client can supply the zoneid in the Host header. For example, the following illustrates a typical IPP request using the previously recommended IPvFuture format (which CUPS implements and uses):

POST /ipp/print HTTP/1.1
Host: [v1.fe80::1234+en0]:631
Content-Type: application/ipp
Transfer-Coding: chunked

... IPP request ...

The printer then validates the Host header and responds with URIs containing the same Host value in any reported IPv6 link-local URIs.

The key issue is one of context - the client *may* be able to query the interface used for a particular socket connection but it probably can't (easily) cache and map this information in the URIs that are embedded in the content returned by the printer, particularly when the client may have to process said content from a variety of sources - IPP is also supported over a USB transport, HTML can be read from disk, etc. Clients are usually unable to connect to a given IPv6 link local address without the zoneid information to tell them which network interface to use. And typically the only reason clients use an IPv6 link local address is because it was handed to them by a discovery protocol like WS-Discovery...

Requiring the client to rewrite all URIs is a tremendous burden and is error-prone. Requiring the server to use the Host header is cheap in comparison. Having the server validate and use the Host value also helps interoperability since existing clients may not support the new IPv6addrz format - for example, CUPS doesn't support it since it validates URIs and Host values using the ABNF in RFC 3986/STD 66.

The Host header mechanism has been standard practice outside the IETF for several years now. It is part of IPP Everywhere (Printer Working Group), Wi-Fi Direct Print Services (Wi-Fi Alliance), IPP USB (USB Implementers Forum), and AirPrint (Apple). It solves the problem of client-side routing of IPv6 link local addresses that are used in URIs embedded in content returned by printers and other embedded devices.

Hundreds of millions of printers, computers, and mobile devices have been certified and shipped with IPv6 link local support using the IPvFuture format over the last 8 years. The new format is incompatible with parsers that use the ABNF in STD 66 (aka RFC 3986) and prevents the use of the Host header in HTTP requests to provide a backwards-compatible IPv6 implementation.
--VERIFIER NOTES--
The attempt to use this erratum as a placeholder seems to be sapping the urgency from the work the author of the erratum promised to do. This appears to be an end-run around the standards process. Please do not re-submit this erratum, but instead please get to work in 6man fixing this problem, if indeed there is consensus that your proposed fix is correct.

RFC 6887, "Port Control Protocol (PCP)", April 2013

Note: This RFC has been updated by RFC 7488, RFC 7652, RFC 7843

Source of RFC: pcp (int)

Errata ID: 3887
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Channy Zhang
Date Reported: 2014-02-11
Rejected by: Ted Lemon
Date Rejected: 2014-02-12

Section N/A says:

N/A

It should say:

N/A

Notes:

How PCP applies in the Dual-Egress NAT scene?

If the gateway device has two or more out interfaces to internet were doing different nat conversion in the ISP.
PCP MAP mode does not include the destination address, the gateway device how to choose the out interfaces? And how to choose the different NAT address pools?
This scene is very common in the ISP, it means that PCP does not apply in this scene?
--VERIFIER NOTES--
This is not the right way to address the issue you have raised. Please raise this issue in the PCP working group, so that the working group can come up with a consensus answer to the question.

Errata ID: 4255
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ad Steijvers
Date Reported: 2015-02-03
Rejected by: Ted Lemon
Date Rejected: 2015-02-03

Section 11,12 says:

Notes:

Add (preferable at the start of both section 11 and 12) the actual numerical definition of the OpCode explained in the section.

There is a lot of mentioning of the MAP and PEER opcodes in the document, but nowhere in the text can be found what the actual OpCodes are. Everywhere where the MAP OpCode or PEER OpCode is mentioned is the reader directed to section 11 or 12 respectively, 'where the OpCode is defined'. But in those sections there is no definition of the OpCode.

e.g.: section 7.1, in the field description of a PCP request packet:
"Opcode: A 7-bit value specifying the operation to be performed. MAP
and PEER Opcodes are defined in Sections 11 and 12."

I had to search the internet and found them at:
https://www.iana.org/assignments/pcp-parameters/pcp-parameters.xhtml

Where is stated:

Value Description Reference
0 ANNOUNCE [RFC6887]
1 MAP [RFC6887]
2 PEER [RFC6887]

The above three numerical definitions are nowhere to be found in the RFC6887 document and seem quite crucial for correct PCP implementations. Should the OpCodes already be defined in some other RFC document and is the reader expected to know about it, then I'd suggest to put a link to that other RFC document at the start of sections 11 and 12.
--VERIFIER NOTES--
The numerical opcodes are defined in section 19.2. I agree that the use of the term "opcode" is confusing, and it would be good to clarify that in a future update to the document, but the erratum as written is not correct.

RFC 6890, "Special-Purpose IP Address Registries", April 2013

Note: This RFC has been updated by RFC 8190

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: int

Errata ID: 3873
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Tuexen
Date Reported: 2014-01-23
Rejected by: Ted Lemon
Date Rejected: 2014-01-23

Section 2.2.3 says:

                 +----------------------+---------------------+
                 | Attribute            | Value               |
                 +----------------------+---------------------+
                 | Address Block        | ::ffff:0:0/96       |
                 | Name                 | IPv4-mapped Address |
                 | RFC                  | [RFC4291]           |
                 | Allocation Date      | February 2006       |
                 | Termination Date     | N/A                 |
                 | Source               | False               |
                 | Destination          | False               |
                 | Forwardable          | False               |
                 | Global               | False               |
                 | Reserved-by-Protocol | True                |
                 +----------------------+---------------------+

                       Table 20: IPv4-Mapped Address

It should say:

                 +----------------------+---------------------+
                 | Attribute            | Value               |
                 +----------------------+---------------------+
                 | Address Block        | ::ffff/96       |
                 | Name                 | IPv4-mapped Address |
                 | RFC                  | [RFC4291]           |
                 | Allocation Date      | February 2006       |
                 | Termination Date     | N/A                 |
                 | Source               | False               |
                 | Destination          | False               |
                 | Forwardable          | False               |
                 | Global               | False               |
                 | Reserved-by-Protocol | True                |
                 +----------------------+---------------------+

                       Table 20: IPv4-Mapped Address

Notes:

The address block for IPv4-Mapped addresses is ::ffff/96 and not ::ffff:0:0/96.
See the following reference which is also given in the table:
http://tools.ietf.org/html/rfc4291#section-2.5.5.2
--VERIFIER NOTES--
The proposed change is in error because it puts the 16 marker bits in the lowest 16 bits of the address, where the low 16 bits of the IPv4 address are supposed to go.

Errata ID: 3879
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Masataka MAWATARI
Date Reported: 2014-02-03
Rejected by: Ted Lemon
Date Rejected: 2014-03-18

Section 2.2.3 says:

                    +----------------------+----------------+
                    | Attribute            | Value          |
                    +----------------------+----------------+
                    | Address Block        | 2001::/32      |
                    | Name                 | TEREDO         |
                    | RFC                  | [RFC4380]      |
                    | Allocation Date      | January 2006   |
                    | Termination Date     | N/A            |
                    | Source               | True           |
                    | Destination          | True           |
                    | Forwardable          | True           |
                    | Global               | False          |
                    | Reserved-by-Protocol | False          |
                    +----------------------+----------------+

                             Table 23: TEREDO

                     +----------------------+--------------+
                     | Attribute            | Value        |
                     +----------------------+--------------+
                     | Address Block        | fc00::/7     |
                     | Name                 | Unique-Local |
                     | RFC                  | [RFC4193]    |
                     | Allocation Date      | October 2005 |
                     | Termination Date     | N/A          |
                     | Source               | True         |
                     | Destination          | True         |
                     | Forwardable          | True         |
                     | Global               | False        |
                     | Reserved-by-Protocol | False        |
                     +----------------------+--------------+

                          Table 28: Unique-Local

It should say:

                    +----------------------+----------------+
                    | Attribute            | Value          |
                    +----------------------+----------------+
                    | Address Block        | 2001::/32      |
                    | Name                 | TEREDO         |
                    | RFC                  | [RFC4380]      |
                    | Allocation Date      | January 2006   |
                    | Termination Date     | N/A            |
                    | Source               | True           |
                    | Destination          | True           |
                    | Forwardable          | True           |
                    | Global               | N/A [RFC4380]  |
                    | Reserved-by-Protocol | False          |
                    +----------------------+----------------+

                             Table 23: TEREDO

                    +----------------------+----------------+
                    | Attribute            | Value          |
                    +----------------------+----------------+
                    | Address Block        | fc00::/7       |
                    | Name                 | Unique-Local   |
                    | RFC                  | [RFC4193]      |
                    | Allocation Date      | October 2005   |
                    | Termination Date     | N/A            |
                    | Source               | True           |
                    | Destination          | True           |
                    | Forwardable          | True           |
                    | Global               | N/A [RFC4193]  |
                    | Reserved-by-Protocol | False          |
                    +----------------------+----------------+

                          Table 28: Unique-Local

Notes:

The global scope of TEREDO prefix (2001::/32) and Unique-Local prefix (fc00::/7) is not false.
The proposed revision is N/A with reference to each RFC.
--VERIFIER NOTES--
After discussion, we concluded that the ULA prefix change is not appropriate; a second erratum containing just the Teredo change has been submitted, so this one is not needed.

Errata ID: 6416
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Thomas
Date Reported: 2021-01-21
Rejected by: Eric Vyncke
Date Rejected: 2022-05-06

Section 2.2.2 says:

              +----------------------+----------------------------+
              | Attribute            | Value                      |
              +----------------------+----------------------------+
              | Address Block        | 0.0.0.0/8                  |
              | Name                 | "This host on this network"|
              | RFC                  | [RFC1122], Section 3.2.1.3 |
              | Allocation Date      | September 1981             |
              | Termination Date     | N/A                        |
              | Source               | True                       |
              | Destination          | False                      |
              | Forwardable          | False                      |
              | Global               | False                      |
              | Reserved-by-Protocol | True                       |
              +----------------------+----------------------------+

                    Table 1: "This host on this network"

It should say:

              +----------------------+----------------------------+
              | Attribute            | Value                      |
              +----------------------+----------------------------+
              | Address Block        | 0.0.0.0/8                  |
              | Name                 | "This network"             |
              | RFC                  | [RFC1122], Section 3.2.1.3 |
              | Allocation Date      | September 1981             |
              | Termination Date     | N/A                        |
              | Source               | True                       |
              | Destination          | False                      |
              | Forwardable          | False                      |
              | Global               | False                      |
              | Reserved-by-Protocol | True                       |
              +----------------------+----------------------------+

                          Table 1: "This network"

Notes:

RFC1122 states that 0.0.0.0/32 is "this host on this network" while 0.0.0.0/8 is "this network".
--VERIFIER NOTES--
-- verifier note --
This errata is a duplicate of errata 6404, which is verified.

Errata ID: 6956
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Thomas
Date Reported: 2021-01-21
Rejected by: Eric Vyncke
Date Rejected: 2023-08-03

Section 2.2.2 says:

              +----------------------+----------------------------+
              | Attribute            | Value                      |
              +----------------------+----------------------------+
              | Address Block        | 0.0.0.0/8                  |
              | Name                 | "This host on this network"|
              | RFC                  | [RFC1122], Section 3.2.1.3 |
              | Allocation Date      | September 1981             |
              | Termination Date     | N/A                        |
              | Source               | True                       |
              | Destination          | False                      |
              | Forwardable          | False                      |
              | Global               | False                      |
              | Reserved-by-Protocol | True                       |
              +----------------------+----------------------------+

                    Table 1: "This host on this network"

It should say:

              +----------------------+----------------------------+
              | Attribute            | Value                      |
              +----------------------+----------------------------+
              | Address Block        | 0.0.0.0/8                  |
              | Name                 | "This network"             |
              | RFC                  | [RFC1122], Section 3.2.1.3 |
              | Allocation Date      | September 1981             |
              | Termination Date     | N/A                        |
              | Source               | True                       |
              | Destination          | False                      |
              | Forwardable          | False                      |
              | Global               | False                      |
              | Reserved-by-Protocol | True                       |
              +----------------------+----------------------------+

                          Table 1: "This network"

Notes:

RFC1122 states that 0.0.0.0/32 is "this host on this network" while 0.0.0.0/8 is "this network".
--VERIFIER NOTES--
This errata is obsolete: it was fixed by errata 6404 by the same errata reporter.

RFC 6891, "Extension Mechanisms for DNS (EDNS(0))", April 2013

Source of RFC: dnsext (int)

Errata ID: 6982
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Avninder Sran
Date Reported: 2022-05-29
Rejected by: Eric Vyncke
Date Rejected: 2022-05-30

Section 4.3 says:

Traditional DNS messages are limited to 512 octets in size when sent over UDP [RFC1035]. Fitting the increasing amounts of data that can be transported in DNS in this 512-byte limit is becoming more difficult. For instance, inclusion of DNSSEC records frequently requires a much larger response than a 512-byte message can hold.

It should say:

Traditional DNS messages are limited to 512-bytes in size when sent over UDP [RFC1035]. Fitting the increasing amounts of data that can be transported in DNS in this 512-byte limit is becoming more difficult. For instance, inclusion of DNSSEC records frequently
 requires a much larger response than a 512-byte message can hold.

Notes:

In the original text, it says: DNS messages are limited to 512 octets in size, but it should be 512 bytes not octets.


--VERIFIER NOTES--
Most RFCs use "octets" and "bytes" as equivalent (even if I personally prefer "octets").

RFC 6901, "JavaScript Object Notation (JSON) Pointer", April 2013

Source of RFC: appsawg (app)

Errata ID: 3981
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: David Phillips
Date Reported: 2014-05-06
Rejected by: Barry Leiba
Date Rejected: 2014-05-07

Section 3 says:

See Notes

It should say:

The following two examples from section 5 are different:

Original: "/a~1b"
Proposed: "/a//b"

Original: "/m~0n"
Proposed: "/m~n"

The other examples are the same.

Notes:

The escape syntax seems weird and confusing. Rather than ~0 and ~1, why not use a repeated (double) slash to escape a slash? This is similar to how SQL escapes single quotes in string literals by using the single quote twice.

We have JSON functions in Presto (prestodb.io) that could benefit from an improved syntax (they currently use JSONPath), but I can't see understanding ~0 and ~1.
--VERIFIER NOTES--
This is a change request, not an errata report. The suggested change isn't directly acceptable, but could well be useful input into a new version of the specification. In any case, it's not addressing an error, but a feature change.

RFC 6902, "JavaScript Object Notation (JSON) Patch", April 2013

Source of RFC: appsawg (app)

Errata ID: 4596
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Missing 'Append' operation
Date Reported: 2016-01-21
Rejected by: Barry Leiba
Date Rejected: 2016-01-21

Throughout the document, when it says:

Its value MUST be one of "add", "remove", "replace", 
"move", "copy", or "test"; other values are errors. 

It should say:

Its value MUST be one of "add", "append", "remove", 
"replace", "move", "copy", or "test"; other values are errors. 

... and more text to add the 'append' op description.

Notes:

There is a key missing piece to this RFC. You can do { "op": "add", "path": "/attr", "value": "val"}, which will add or modify the 'attr' attribute, if it exists or not. However, you cannot add an item to a potentially non-existing array. Updating an array that may or may not exists, forces the client to always call GET on the resource. See this API spec: https://orchestrate.io/docs/apiref#keyvalue-patch which implements the op 'append', which would solve this problem.
--VERIFIER NOTES--
This is an enhancement suggestion, not an errata report; the errata system is not for that.

Errata ID: 5239
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Grzegorz Olszewski
Date Reported: 2018-01-19
Rejected by: Barry Leiba
Date Rejected: 2020-12-09

Section A.16 says:

An example target JSON document:

   { "foo": ["bar"] }

   A JSON Patch document:

   [
     { "op": "add", "path": "/foo/-", "value": ["abc", "def"] }
   ]

   The resulting JSON document:

   { "foo": ["bar", ["abc", "def"]] }

It should say:

An example target JSON document:

   { "foo": ["bar"] }

   A JSON Patch document:

   [
     { "op": "add", "path": "/foo/-", "value": ["abc", "def"] }
   ]

   The resulting JSON document:

   { "foo": ["bar", "abc", "def"] }

Notes:

surplus square brackets in resulting JSON document
--VERIFIER NOTES--
The example is correct as written: the value to be added to the array is itself an array, so the new element is ["abc", "def"].

Errata ID: 6351
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Palle Cogburn
Date Reported: 2020-12-09
Rejected by: Barry Leiba
Date Rejected: 2020-12-09

Throughout the document, when it says:

Notes:

If the patch elements included a property "previous" that contained the original value in case of an operation such as "remove" for instance, it would be easy to create the reverse operation - "add". In that way the path elements can be used as audit records and it is easy to revert a path or even a part of a patch, so the document is back to a previous version. All you have to do is apply the reverse patch and also add those elements to the audit trail.
Is this something to consider adding to this document or is it an implementation detail?
--VERIFIER NOTES--
This is a feature request, not an errata report, so it is rejected as an errata report. The suggested feature should be discussed on an appropriate mailing list to see if there is interest in adding this feature.

Errata ID: 4419
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Brett Zamir
Date Reported: 2015-07-17
Rejected by: Barry Leiba
Date Rejected: 2016-01-21

Section A.14 says:

An example target JSON document:

   {
     "/": 9,
     "~1": 10
   }

   A JSON Patch document:

   [
     {"op": "test", "path": "/~01", "value": 10}
   ]

   The resulting JSON document:

   {
     "/": 9,
     "~1": 10
   }

It should say:

Proper JSON Pointer escaping should occur when resolving
paths for application to the target document.

An example target JSON document:

   {
     "/": 9,
     "~1": 10
   }

   A JSON Patch document:

   [
     {"op": "add", "path": "/~01", "value": 11}
   ]

   The resulting JSON document:

   {
     "/": 9,
     "~1": 11
   }

Notes:

At http://tools.ietf.org/html/rfc6902#appendix-A.14 , I have a few issues:

1. Even though JSON Pointer is referenced elsewhere, I think reference ought to be made here to JSON Pointer in order to clarify what meaning "escape ordering" has here.
2. The operation indicated in this section is "test" which is not documented in its respective sections as returning any kind of document at all. I believe "add" or "replace" must have been the intended operation instead. And to make clear that the value of key "~1" would have actually been affected by such a modifying operation, the value in the result ought to differ from that in the original document.
--VERIFIER NOTES--
The example is correct, but could use clarification. The authors have noted this and put it in their JSON Patch issues list here: https://github.com/json-patch/json-patch-tests/issues/22

Errata ID: 4460
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lucas Bickel
Date Reported: 2015-08-29
Rejected by: Barry Leiba
Date Rejected: 2015-08-29

Section 4.1 says:

   However, the object itself or an array containing it does need to
   exist, and it remains an error for that not to be the case.  For
   example, an "add" with a target location of "/a/b" starting with this
   document:

   { "a": { "foo": 1 } }

   is not an error, because "a" exists, and "b" will be added to its
   value.  It is an error in this document:

   { "q": { "bar": 2 } }

   because "a" does not exist.

It should say:

   However, the object itself or an array containing it does need to
   exist, and it remains an error for that not to be the case.  For
   example, an "add" with a target location of "/a/b" starting with this
   document:

   { "a": { "foo": 1 } }

   is not an error, because "a" exists, and "b" will be added to its
   value.  It is an error in this document:

   { "q": { "bar": 2 } }

   because "a" does not exist. Considering a target location of "/a/1"
   it should be not be an error in this document:

    { "a": [ "foo" ] }

    while the same "add" into this document will be an error:

    { "a": [ ] }

    because "/a/0" does not exist.

Notes:

Adding to an object has such a nice example that explains the error cases. I think adding to a sequential array should have one as well.

To my understanding this is already pretty clear from RFC6901, I feel it will make the spec easier to implement if we have an example right here.
--VERIFIER NOTES--
Thanks for the comment, Lucas. This is, though, not a report of an error, so as an errata report it is rejected. It is a reasonable suggestion that we should consider if a new version of the document is done. The comment is recorded in the JSON mailing list archive.

RFC 6946, "Processing of IPv6 "Atomic" Fragments", May 2013

Source of RFC: 6man (int)

Errata ID: 3988
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Panos Kampanakis
Date Reported: 2014-05-15
Rejected by: Brian Haberman
Date Rejected: 2014-05-16

Section 4 says:

...MUST NOT be discarded upon receipt of... 

It should say:

...MUST be discarded upon receipt of... 

Notes:

--VERIFIER NOTES--
The text in the RFC is correct. Atomic fragments should not affect the re-assembly of legitimate fragments present in the re-assembly buffer.

RFC 6956, "Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library", June 2013

Source of RFC: forces (rtg)

Errata ID: 5700
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2019-04-19
Rejected by: Alvaro Retana
Date Rejected: 2019-09-10

Section 4.4 says:

                  <name>IPv4HeaderLengthMismatch</name>
                  <synopsis>
                   Exception case: packet with header length more
                   than 5 words.
                  </synopsis>

It should say:

                  <name>IPv4HeaderLengthMismatch</name>
                  <synopsis>
                   Exception case: packet with header length less
                   than 5 words.
                  </synopsis>

Notes:

page 37
--VERIFIER NOTES--
From the forces mailing list:

On April 22, 2019 at 9:25:22 PM, Weiming Wang (wmwang@zjsu.edu.cn) wrote:

Hi，

Packets with the header length more than 5 words are marked with Exceptional packest. Packets header with less than 5 words should be marked with Validate Error, as defined in

Section 4.4

<specialValue value="3">
<name>InvalidIPv4HeaderLengthSize</name>
<synopsis>
Error case: packet with header length field in
the header less than 5 words.
</synopsis>

RFC 6958, "RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Loss Metric Reporting", May 2013

Source of RFC: xrblock (rai)

Errata ID: 4424
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Varun Singh
Date Reported: 2015-07-21
Rejected by: Alissa Cooper
Date Rejected: 2015-11-05

Section 3.1 says:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Packets Lost in Bursts             |    Total...   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | ...Packets Expected in Bursts |    Number of Bursts   | Sum of|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                ...Squares of Burst Durations (ms-squared)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Packets Lost in Bursts             |    Total...   
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Packets Expected in Bursts |        Number of Bursts       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Sum of Squares of Burst Durations (ms-squared)  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ...    |                    reserved                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

The packet format on Section 3.1 shows 12 bits, however
section 3.2 defines the "Number of bursts" as a 16-bit field.

Relevant text from Section 3.2 pasted below:

Number of Bursts: 16 bits

The number of bursts in the period of the report (Interval or
Cumulative).

The measured value is an unsigned value. If the measured value
exceeds 0xFFFD, the value 0xFFFE MUST be reported to indicate
an over-range measurement. If the measurement is unavailable,
the value 0xFFFF MUST be reported.
--VERIFIER NOTES--
There is an error in the report. The reporter will report a new corrected errata.

RFC 6960, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", June 2013

Note: This RFC has been updated by RFC 8954

Source of RFC: pkix (sec)

Errata ID: 5929
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Mohit Sahni
Date Reported: 2019-12-06
Rejected by: Benjamin Kaduk
Date Rejected: 2019-12-10

Section 4.4.1 says:

   The nonce cryptographically binds a request and a response to prevent
   replay attacks.  The nonce is included as one of the
   requestExtensions in requests, while in responses it would be
   included as one of the responseExtensions.  In both the request and
   the response, the nonce will be identified by the object identifier
   id-pkix-ocsp-nonce, while the extnValue is the value of the nonce.

     id-pkix-ocsp           OBJECT IDENTIFIER ::= { id-ad-ocsp }
     id-pkix-ocsp-nonce     OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }

     Nonce ::= OCTET STRING

Notes:

In section 4.1.1, the standard MUST define a maximum length for Nonce or the Nonce MUST be of a defined fixed length. The current implementations that follow this standard are vulnerable to denial of service attacks since they will try to accept even the large size OCSP requests with very big nonce value and eventually will consume more memory.
--VERIFIER NOTES--
Rejected per submitter after discussion.
This is an enhancement request and will be discussed on the lamps@ietf.org mailing list.

RFC 6987, "OSPF Stub Router Advertisement", September 2013

Note: This RFC has been updated by RFC 8770

Source of RFC: ospf (rtg)

Errata ID: 4685
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexander Okonnikov
Date Reported: 2016-05-06
Rejected by: Alia Atlas
Date Rejected: 2016-07-13

Section 4 says:

It should say:

(At the end of the section)

If the stub router is located in transit area, crossed by virtual
link(s), latter will become inoperational in case the stub router is
on path between two virtual link endpoints - either due to only path
in transit area or due to topology changes which move stub router onto
this path. 

Notes:

Virtual links become inoperational in case path metric between two endpoints is > 0xffff. Path metric of two or more links, one of which has MaxLinkMetric, will inevitably exceed value 0xffff.
--VERIFIER NOTES--
The suggested text is technically correct, however it is really providing additional information rather than an actual errata. If this RFC is revised, then a discussion with the working group would be appropriate.

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.

RFC 7012, "Information Model for IP Flow Information Export (IPFIX)", September 2013

Source of RFC: ipfix (ops)

Errata ID: 3852
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Stewart Bryant
Date Reported: 2013-12-30
Rejected by: Benoit Claise
Date Rejected: 2014-03-02

Section 3.1.15-17 says:

3.1.15. dateTimeSeconds

   The type "dateTimeSeconds" represents a time value expressed with
   second-level precision.

3.1.16. dateTimeMilliseconds

   The type "dateTimeMilliseconds" represents a time value expressed
   with millisecond-level precision.

3.1.17. dateTimeMicroseconds

   The type "dateTimeMicroseconds" represents a time value expressed
   with microsecond-level precision.

3.1.18. dateTimeNanoseconds

   The type "dateTimeNanoseconds" represents a time value expressed with
   nanosecond-level precision.

It should say:

3.1.15. dateTimeSeconds

   The type "dateTimeSeconds" represents a time value in units of
   seconds based on coordinated universal time (UTC).  The choice of an
   epoch, for example, 00:00 UTC, January 1, 1970, is left to
   corresponding encoding specifications for this type, for example, the
   IPFIX protocol specification.  Leap seconds are excluded.  Note that
   transformation of values might be required between different
   encodings if different epoch values are used.

3.1.16. dateTimeMilliseconds

   The type "dateTimeMilliseconds" represents a time value in units of
   milliseconds based on coordinated universal time (UTC).  The choice
   of an epoch, for example, 00:00 UTC, January 1, 1970, is left to
   corresponding encoding specifications for this type, for example, the
   IPFIX protocol specification.  Leap seconds are excluded.  Note that
   transformation of values might be required between different
   encodings if different epoch values are used.

3.1.17. dateTimeMicroseconds

   The type "dateTimeMicroseconds" represents a time value in units of
   microseconds based on coordinated universal time (UTC).  The choice
   of an epoch, for example, 00:00 UTC, January 1, 1970, is left to
   corresponding encoding specifications for this type, for example, the
   IPFIX protocol specification.  Leap seconds are excluded.  Note that
   transformation of values might be required between different
   encodings if different epoch values are used.

3.1.18. dateTimeNanoseconds

   The type "dateTimeNanoseconds" represents a time value in units of
   nanoseconds based on coordinated universal time (UTC).  The choice of
   an epoch, for example, 00:00 UTC, January 1, 1970, is left to
   corresponding encoding specifications for this type, for example, the
   IPFIX protocol specification.  Leap seconds are excluded.  Note that
   transformation of values might be required between different
   encodings if different epoch values are used.

Notes:

Although section 1.1 says : - "Definitions of timestamp data types have been clarified." The edited text has removed the epoch definition, and this does not seem to have been incorporated elsewhere in the RFC.

Without a specified epoch, there is no unique definition of the timestamps.

My proposal above is to revert to the RFC5102 definitions. RFC7102 is intended to be backwards compatible with RFC5102 and thus the definitions need to be technically identical. Alternatively, if the text is now included elsewhere in RFC7012 or in another RFC, it would be helpful to the reader to provide a reference to the epoch definition in an editorial update to dateTimeX definitions in RFC7102.
--VERIFIER NOTES--
Reject reason: issue addressed in errata 3881

RFC 7044, "An Extension to the Session Initiation Protocol (SIP) for Request History Information", February 2014

Source of RFC: sipcore (rai)

Errata ID: 4181
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hans Erik van Elburg
Date Reported: 2014-11-14
Rejected by: Alissa Cooper
Date Rejected: 2015-11-01

Section 9.3 says:

9.3. Receiving a Response with History-Info or Request Timeouts

It should say:

9.3. Receiving a Response or Request times out

Notes:

The title of section 9.3 is misleading in the sense that it suggests that it only applies to responses that contain the History-Info header. This is not correct, it applies to all responses when the RFC7044 applies.
--VERIFIER NOTES--
This errata indicates an editorial preference rather than an error.

Errata ID: 5012
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dinoop Paloli
Date Reported: 2017-05-10
Rejected by: Ben Campbell
Date Rejected: 2017-05-10

Section 10.1.2 says:

If there is not a Privacy header field in the message

It should say:

If there is no Privacy header field in the message

Notes:

"If there is not a Privacy header" is not a correct sentence. We have to use "If there is no Privacy header"
--VERIFIER NOTES--
Either usage is acceptable.

RFC 7049, "Concise Binary Object Representation (CBOR)", October 2013

Note: This RFC has been obsoleted by RFC 8949

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 4409
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Jim Schaad
Date Reported: 2015-07-06
Rejected by: Barry Leiba
Date Rejected: 2020-07-17

Section 3.9 says:

  The sorting rules are:

      *  If two keys have different lengths, the shorter one sorts
         earlier;

      *  If two keys have the same length, the one with the lower value
         in (byte-wise) lexical order sorts earlier.

It should say:

  The sorting rules are:

      *  If the major types are different, the one with the lower value
          in numerical order sorts earlier.

      *  If two keys have different lengths, the shorter one sorts
         earlier;

      *  If two keys have the same length, the one with the lower value
         in (byte-wise) lexical order sorts earlier.

Notes:

As the rules are currently written, The integer -257 would be sorted after the integer 16 because has a length of 2 rather than a length of 1. First rule says shorter keys sort first. However the text above says the sorting is based on the byte representation of the key.
--VERIFIER NOTES--
This report has been rejected because this is a change in documented behavior
that would require working groupconsensus. That said, this was taken into account
by the working group during the production of the updated version of RFC 7049.

Errata ID: 4963
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: David Waite
Date Reported: 2017-03-12
Rejected by: Barry Leiba
Date Rejected: 2020-07-17

Section 3.9 says:

   same CBOR output, the following four rules would suffice:

   o  Integers must be as small as possible.

      *  0 to 23 and -1 to -24 must be expressed in the same byte as the
         major type;

      *  24 to 255 and -25 to -256 must be expressed only with an
         additional uint8_t;

      *  256 to 65535 and -257 to -65536 must be expressed only with an
         additional uint16_t;

      *  65536 to 4294967295 and -65537 to -4294967296 must be expressed
         only with an additional uint32_t.

   o  The expression of lengths in major types 2 through 5 must be as
      short as possible.  The rules for these lengths follow the above
      rule for integers.

   o  The keys in every map must be sorted lowest value to highest.
      Sorting is performed on the bytes of the representation of the key
      data items without paying attention to the 3/5 bit splitting for
      major types.  (Note that this rule allows maps that have keys of
      different types, even though that is probably a bad practice that
      could lead to errors in some canonicalization implementations.)
      The sorting rules are:

      *  If two keys have different lengths, the shorter one sorts
         earlier;

      *  If two keys have the same length, the one with the lower value
         in (byte-wise) lexical order sorts earlier.

   o  Indefinite-length items must be made into definite-length items.

It should say:

   same CBOR output, the following four rules would suffice:

   1.  Integers must be as small as possible.

      *  0 to 23 and -1 to -24 must be expressed in the same byte as the
         major type;

      *  24 to 255 and -25 to -256 must be expressed only with an
         additional uint8_t;

      *  256 to 65535 and -257 to -65536 must be expressed only with an
         additional uint16_t;

      *  65536 to 4294967295 and -65537 to -4294967296 must be expressed
         only with an additional uint32_t.

   2. The expression of lengths in major types 2 through 5 must be as
      short as possible.  The rules for these lengths follow the above
      rule for integers.

   3. The expression of the tag in major type 6 must be as short as 
      possible.  The rules for the tag value follow the above rule for
      integers.

   4. The expression of a simple type must be as short as possible. The 
      rules for simple types follow the above rules for integers.

   5. Indefinite-length items must be made into definite-length items.

   6. The keys in every map must be sorted lowest value to highest.
      Sorting is performed byte-for-byte on the binary representation
      of the key data items, without restrictions on keys having a 
      common major/minor type.

      If two keys of differing binary lengths are compared, the item 
      with the shortest length sorts first.

      Note that this rule allows maps to have keys of different major 
      types, even though that may be considered a bad practice that
      could lead to errors in some canonicalization implementations. 
      For example, negative integers may binary sort out of order
      with respect to positive integers.

Notes:

Several recommended changes, some editorial some technical:

- The items are numbered to indicate an appropriate order. This is recommended because converting items to minimal size and making indefinite-length items into definite length must be done before sorting map entries

- Rules were added for reducing the size of tags (major type 6) and simple types (major type 7).

- Within the sorting section for map entries:
- The original comment about 3/5 bit splitting was unclear, whether it was implying some transform was necessary before sorting the items. This was reworked to indicate that the keys were sorted by binary representation.
- The quoted note about mixed types is made a non-quoted comment. An example is given of negative and positive integers.
--VERIFIER NOTES--
This report has been rejected because this is a change in documented behavior
that would require working groupconsensus. That said, this was taken into account
by the working group during the production of the updated version of RFC 7049.

Errata ID: 4964
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: David Waite
Date Reported: 2017-03-12
Rejected by: Barry Leiba
Date Rejected: 2020-07-17

Section 3.9 says:

*  If two keys have different lengths, the shorter one sorts
         earlier;

It should say:

<removed>

Notes:

I would recommend this rule be struck for the following reasons, and a simple binary comparison regardless of length is used

1. It does not affect sorting order of single type entries, if the other rules around using minimal size are followed. This is because the ranges for representable values based on the 5-bit additional information are consistently increasing. In particular, minimal sized non-negative integers will sort in numerical order in either case

2. It does not affect text sorting. A block of text is length-prefixed already, which means that the bytes representing length will already sort shorter strings ahead of all longer strings

3. Using a simple binary comparison will group a mixed-type map by major type. All string keys will be together, for instance. As an example, a 1-6 character string value today could sort in the middle of a group of integer keys (for sufficiently large integers)

4. For keys which are arrays of items, the shortest length breaks the ability for sorted order to mean anything. For example, an [int x, int y] key will sort by x value then y value if straight binary comparison is used, but will sort in a different manner if length-based sorting is involved due to the potential for large `y`.

This is the use case which I personally am hitting, as my keys are composed of an array with the first element as epoch time.

5. It is not necessary to deal with mixed-length values. Due to several factors including termination of indefinite length items, it is not possible to append binary data to a well-formed CBOR value to get a different well-formed CBOR value. Thus all well-formed keys, if compared byte-for-byte, *will* differ without the need to zero-pad the data.
--VERIFIER NOTES--
This report has been rejected because this is a change in documented behavior
that would require working groupconsensus. That said, this was taken into account
by the working group during the production of the updated version of RFC 7049.

RFC 7050, "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis", November 2013

Note: This RFC has been updated by RFC 8880

Source of RFC: behave (tsv)

Errata ID: 5152
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Andrews
Date Reported: 2017-10-11
Rejected by: Magnus Westerlund
Date Rejected: 2021-01-13

Section IANA Conside says:

N/A 

It should say:

8.x DNSSEC

    ipv4only.arpa MUST be insecurely delegated.  This allows ISP's to
    modify / generate AAAA responses for ipv4only.arpa AAAA queries that
    will pass through unmodified caching servers as required by 8.1 (4).

Notes:

The protocol as described does not work when there is a validating caching server in the resolution path.

IANA should have been instructed to insecurely delegate ipv4only.arpa. This allows ISP's to modify the
AAAA response without running foul of DNSSEC validation.
--VERIFIER NOTES--
So this errata was correct on the issue, but errata was not the appropriate way of resolving this issue. RFC 8880 that updates RFC 7050 specifies a resolution to this errata.

Errata ID: 6270
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Andrews
Date Reported: 2020-09-01
Rejected by: Magnus Westerlund
Date Rejected: 2021-01-13

Section 3.4 says:

"PTR" query #2 for "2001:db8:43::192.0.0.170

It should say:

"PTR" query #2 for "2001:db8:43::192.0.0.171

Notes:

The second PTR query should be for the reverse of the DNS64 mapped well known address 192.0.0.171. This looks like a cut-and-paste error where 170 was not changed to 171.
--VERIFIER NOTES--
After discussion on Behave mailing list it appears that the example is not in contradiction with what the RFC specifies. There was some additional discussion around this for other potential improvements that should be considered in case the specification is revised.

Mail thread: https://mailarchive.ietf.org/arch/msg/behave/KuvD2ppb9LLD3LnzS-DJ7wVCgvc/

RFC 7139, "GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks", March 2014

Note: This RFC has been updated by RFC 7892

Source of RFC: ccamp (rtg)

Errata ID: 3924
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Fatai Zhang
Date Reported: 2014-03-20
Rejected by: Adrian Farrel
Date Rejected: 2014-03-24

Section 11 says:

5        Unassigned                            [RFC4328]

It should say:

5       Reserved (for G.709)                  [RFC7139]

Notes:

(1)Unassigned->Reserved (for G.709)
(2)[RFC4328]->[RFC7139]
--VERIFIER NOTES--
After discussion with the raiser of this report who was also the lead editor on the document, and also with one of the CCAMP chairs, the conclusion is that the text in Section 11 is correct. I will contact IANA to get the registry updated.

RFC 7141, "Byte and Packet Congestion Notification", February 2014

Source of RFC: tsvwg (wit)

Errata ID: 7237
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Sebastian Moeller
Date Reported: 2022-11-03
Rejected by: Martin Duke
Date Rejected: 2024-01-18

Section 2 says:

2.2.  Recommendation on Encoding Congestion Notification

   When encoding congestion notification (e.g., by drop, ECN, or PCN),
   the probability that network equipment drops or marks a particular
   packet to notify congestion SHOULD NOT depend on the size of the
   packet in question.
[...]
2.3.  Recommendation on Responding to Congestion

   When a transport detects that a packet has been lost or congestion
   marked, it SHOULD consider the strength of the congestion indication
   as proportionate to the size in octets (bytes) of the missing or
   marked packet.

   In other words, when a packet indicates congestion (by being lost or
   marked), it can be considered conceptually as if there is a
   congestion indication on every octet of the packet, not just one
   indication per packet.

   To be clear, the above recommendation solely describes how a
   transport should interpret the meaning of a congestion indication, as
   a long term goal.  It makes no recommendation on whether a transport
   should act differently based on this interpretation.  It merely aids
   interoperability between transports, if they choose to make their
   actions depend on the strength of congestion indications.

It should say:

I am not sure the text is actually salvageable, as it appears ti be a logic disconnect at the core of the recommendations.

Notes:

The recommendations seem not self consistent:
A) Section 2.2. recommends that CE marking should be made independent of packet size, so a CE-mark carries no information about packet size.

B) Section 2.3 then recommends to use the size of marked packets as direct indicators of congestion strength.

C) Section 2.3 then later clarifies that transports should interpret the size of CE-marked packets as correlate for congestion strength but are in no way required to take this interpretation into account when acting based on the congestion signal.


This has several problems:
1) A) and B) are in direct contradiction to each other. If we ask marking nodes to ignore packet size while marking, but end nodes to take it into account we basically create random congestion strength "information" by the pure chance of a specific packet of a specific size "catching" a CE mark. At which point we might as well simply draw a random number at the end-point to interpret congestion strength (except that packet sizes are not distributed randomly).

2) Asking endpoints to interpret CE_marks in this way but not act on it, is hardly actionable advice for potential implementers. If we can not recommend a specific way, we should refrain from offering recommendations at all to keep things as simple as reasonably possible.
--VERIFIER NOTES--
I would summarize the discussion on the WG list as follows:

1) while there is a tension between the two recommendations, it is logically coherent for one endpoint to do one thing and the other input to assume the opposite.

2) This is the original intent of the authors

3) Some people disagree with that design, but that is not a subject for errata.

RFC 7159, "The JavaScript Object Notation (JSON) Data Interchange Format", March 2014

Note: This RFC has been obsoleted by RFC 8259

Source of RFC: json (app)

Errata ID: 3983
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alain BENEDETTI
Date Reported: 2014-05-09
Rejected by: Pete Resnick
Date Rejected: 2014-05-16

Section 2. says:

JSON-text = ws value ws

It should say:

JSON-text = [BOM] ws value ws

BOM = %xFEFF

Notes:

Section 8.1 states:
[START QUOTE]
(...) implementations that parse JSON texts *MAY* ignore the presence of a byte order mark rather than treating it as an error.
[END QUOTE]

Indeed that means that a BOM *CAN* occur, and *MAY* be accepted instead of returning an error. So, if the BOM can be accepted, the grammar is incomplete as it does not show it.

Furthermore, about BOMs, see my other comments.
--VERIFIER NOTES--
The WG was clear that syntactically, the BOM is not part of a valid JSON-text, but implementation advice included that if one appears, it MAY be ignored. The document is correct as-is.

Errata ID: 3984
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alain BENEDETTI
Date Reported: 2014-05-09
Rejected by: Pete Resnick
Date Rejected: 2014-05-16

Section 7 says:

unescaped = %x20-21 / %x23-5B / %x5D-10FFFF

It should say:

unescaped = %x20-21 / %x23-5B / %x5D-D7FF / %xE000-10FFFF

Notes:

Section 1 says:
[START QUOTE]
A string is a sequence of zero or more Unicode characters [UNICODE]. Note that this citation references the latest version of Unicode rather than a specific release.
[END QUOTE]

Section 8.2 emphasizes on the characters not allowed by the Unicode norm:
[START QUOTE]
However, the ABNF in this specification allows member names and string values to contain bit sequences that cannot encode Unicode characters; for example, "\uDEAD" (a single unpaired UTF-16 surrogate).
[END QUOTE]

The ABNF cannot at the same time allow non conformant Unicode codepoints (section 7) and states conformance to Unicode (section 1).

Therefore, there is an incoherence that must be fixed between section 1 (and 8.2 that emphasizes it) and section 7. Hence the proposition of modification in section 7.

The other less preferable solution to this fix incoherence in RFC7159 would have been to NOT require Unicode conformance.
--VERIFIER NOTES--
The WG's consensus was to leave the full range present in the ABNF and add the interoperability guidance about values outside the Unicode accepted range.

Errata ID: 4220
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: mirabilos
Date Reported: 2015-01-05
Rejected by: Barry Leiba
Date Rejected: 2015-03-01

Section 7 says:

   […] All Unicode characters may be placed within the
   quotation marks, except for the characters that must be escaped:
   quotation mark, reverse solidus, and the control characters (U+0000
   through U+001F).

[…]

      unescaped = %x20-21 / %x23-5B / %x5D-10FFFF

It should say:

   […] All Unicode characters may be placed within the
   quotation marks, except for the characters that must be escaped:
   quotation mark, reverse solidus, the control characters (U+0000
   through U+001F), and codepoints beyond the BMP (U-00010000
   through U-0010FFFF).

[…]

      unescaped = %x20-21 / %x23-5B / %x5D-FFFF

Notes:

ECMA-262 states that "ECMAScript source text is assumed to be a sequence
of 16-bit code units", and everything must be converted to UTF-16 first.
This stems from the fact that Java™, like Win32, used UCS-2, which only
later got extended to allow UTF-16. This means that SMP codepoints must
always be escaped into their twelve-character form.

This is also an interoperability issue: implementations may wish to parse
(or generate) JSON by using a wchar_t data type (in C) which, depending on
the platform, may be only 16 bits wide. ECMAscript allows for this.
--VERIFIER NOTES--
This is reporting a disagreement with a decision the working group made in the development of the document, and is not reporting an erratum.

Errata ID: 4298
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Kay
Date Reported: 2015-03-11
Rejected by: Barry Leiba
Date Rejected: 2015-03-11

Section 7 Strings says:

4HEXDIG

It should say:

Something along the lines

4hexdig
hexdig = 0..9 A..F a..f

Notes:

The prose states that within a six-character escape sequence starting \u, the hex digits can be either upper or lower case. But the grammar only allows upper case, because it uses the symbol HEXDIG which is defined in RFC 5234 to include upper case A..F only. There is thus an inconsistency beween the grammar and the prose, and although most readers are likely to know which to believe, the spec is formally ambiguous on this point.
--VERIFIER NOTES--
The reporter doesn't understand RFC 5234. Look in Section 2.3 (Terminal Values), and see this:

> NOTE:
>
> ABNF strings are case insensitive and the character set for these
> strings is US-ASCII.

There is no inconsistency, and the text as written allows both upper and lower case for the hex digits.

RFC 7181, "The Optimized Link State Routing Protocol Version 2", April 2014

Note: This RFC has been updated by RFC 7183, RFC 7187, RFC 7188, RFC 7466

Source of RFC: manet (rtg)

Errata ID: 4872
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2016-11-30
Rejected by: Alvaro Retana
Date Rejected: 2017-01-25

Section 16.2 says:

   TC messages MAY be generated in response to a change in the
   information that they are to advertise, indicated by a change in the
   ANSN in the Neighbor Information Base.  In this case, a router MAY
   send a complete TC message and, if so, MAY restart its TC message
   schedule.  Alternatively, a router MAY send an incomplete TC message
   with at least the newly advertised network addresses (i.e., not
   previously, but now, an N_orig_addr or in an N_neighbor_addr_list in
   a Neighbor Tuple with N_advertised = true or an AL_net_addr) in its
   Address Blocks, with associated Address Block TLV(s).  Note that a
   router cannot report removal of advertised content using an
   incomplete TC message.

It should say:

   TC messages MAY be generated in response to a change in the
   information that they are to advertise, indicated by a change in the
   ANSN in the Neighbor Information Base.  In this case, a router MAY
   send a complete TC message and, if so, MAY restart its TC message
   schedule.  Alternatively, a router MAY send an incomplete TC message
   with at least the newly advertised network addresses (i.e., not
   previously, but now, an N_orig_addr or an N_neighbor_addr_list in
   a Neighbor Tuple with N_advertised = true or an AL_net_addr) in its
   Address Blocks, with associated Address Block TLV(s).  Note that a
   router cannot report removal of advertised content using an
   incomplete TC message.

Notes:

Unnecessary preposition "in"
--VERIFIER NOTES--
From Christopher Dearlove (author):

The "in" distinguishes the cases of N_orig_addr and an N_neighbor_addr_list. The former is a single address, the latter is a list of addresses. Therefore one looks for the address as the former, or in (the word that should not be deleted) the latter.

This erratum must be rejected.

RFC 7186, "Security Threats for the Neighborhood Discovery Protocol (NHDP)", April 2014

Note: This RFC has been updated by RFC 7985

Source of RFC: manet (rtg)

Errata ID: 4035
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Thomas Clausen
Date Reported: 2014-07-03
Rejected by: Adrian Farrel
Date Rejected: 2014-07-03

Throughout the document, when it says:

[RFC7185]

It should say:

[RFC7183]

Notes:

Related to errata 4034, which corrects the reference in the references section, the actual citation keys (which are RFC7185 in the document) should be corrected to [RFC7183] also.

Not quite sure if this should be a separate errata or the two should be combined?
--VERIFIER NOTES--
This is rejected as a duplicate of report 4034. That report can be used to capture all of the information required.

RFC 7208, "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", April 2014

Note: This RFC has been updated by RFC 7372, RFC 8553, RFC 8616

Source of RFC: spfbis (app)

Errata ID: 4081
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: D. Stussy
Date Reported: 2014-08-13
Rejected by: Barry Leiba
Date Rejected: 2014-08-14

Section 8.4 says:

(Paragraph 2):  if supported, the 5.7.1 enhanced status code
...

       550 5.7.1 SPF MAIL FROM check failed:
       550 5.7.1 The domain example.com explains:
       550 5.7.1 Please see http://www.example.com/mailpolicy.html

It should say:

if supported, the 5.7.7 enhanced status code
...

       550 5.7.7 SPF MAIL FROM check failed:
       550 5.7.7 The domain example.com explains:
       550 5.7.7 Please see http://www.example.com/mailpolicy.html

Notes:

5.7.1 generally refers to messages refused due to content or LOCAL policies.
5.7.7 refers to messages where there is an integrity problem.

5.7.7 is a better description for rejecting an unauthorized message due to the application of automatic checking criterion set by remote validation.

The author of this errata notes that the IANA is showing a pending addition to the enhanced codes to add SPF-specific error code 5.7.23 (in lieu of 5.7.1 or 5.7.7), but currently sees no valid RFC proposing it. The draft is located at: http://tools.ietf.org/html/draft-ietf-appsawg-email-auth-codes-07
--VERIFIER NOTES--
The code used was the clear choice of the working group, and can't be changed through the errata system.

Errata ID: 4082
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: D. Stussy
Date Reported: 2014-08-13
Rejected by: Barry Leiba
Date Rejected: 2014-08-14

Section 8.7 says:

...  If the message is rejected during the SMTP transaction for
this reason, the software SHOULD use an SMTP reply code of 550
and, if supported, the 5.5.2 enhanced status code ...

It should say:

...  If the message is rejected during the SMTP transaction for
this reason, the software SHOULD use an SMTP reply code of 550
and, if supported, the 5.7.8 enhanced status code ...

Notes:

5.5.2 refers to responses where there's an SMTP COMMAND syntax error.
5.7.8 refers to messages where authentication credentials are invalid.

5.7.8 is a better description for rejecting an unauthorized message due to the
application of invalid authentication credentials such as bad syntax in an SPF DNS record.

The author of this errata notes that the IANA is showing a pending addition to
the enhanced codes to add SPF-specific error code 5.7.24 (in lieu of 5.5.2 or
5.7.8), but currently sees no valid RFC proposing it. The draft is located at:
http://tools.ietf.org/html/draft-ietf-appsawg-email-auth-codes-07

The use of 5.5.2 here is misleading since the source of the error is not the
SMTP command stream.
--VERIFIER NOTES--
The code used was the clear choice of the working group, and can't be changed through the errata system.

Errata ID: 6432
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Kaspar Etter
Date Reported: 2021-02-17
Rejected by: Barry Leiba
Date Rejected: 2021-02-17

Section 4.4 says:

In accordance with how the records are published (see Section 3
above), a DNS query needs to be made for the <domain> name, querying
for type TXT only.

It should say:

?

Notes:

Request for clarification: Are CNAME indirections allowed or, in other words, do they have to be followed during record lookup? If yes, do they count towards the DNS lookup limits as defined in section 4.6.4? If yes, the following sentence has to be adapted as well: "SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS." If the answer to the first question is no, then this should be made clear in section 4.4.

Please note that whether using CNAMEs is a good or bad idea is irrelevant to my question. I also know that you can't add a CNAME record to an apex domain but SPF is not limited to such domains. I assume the answer/consensus will be the same for the initial, `a`, `include`, `exists` and `redirect` lookups. If not, this should also be clarified, of course.
--VERIFIER NOTES--
Errata reports are not the place to ask questions. An appropriate mailing list on which to discuss SPF is the <ietf-smtp> list.

RFC 7230, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", June 2014

Note: This RFC has been obsoleted by RFC 9110, RFC 9112

Note: This RFC has been updated by RFC 8615

Source of RFC: httpbis (wit)

Errata ID: 4412
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Rick Taylor
Date Reported: 2015-07-09
Rejected by: Barry Leiba
Date Rejected: 2015-07-09

Section 3.3.3 says:

If a Transfer-Encoding header field is present in a response and
the chunked transfer coding is not the final encoding, the
message body length is determined by reading the connection until
it is closed by the server.  If a Transfer-Encoding header field
is present in a request and the chunked transfer coding is not
the final encoding, the message body length cannot be determined
reliably; the server MUST respond with the 400 (Bad Request)
status code and then close the connection.

It should say:

Either:

If a Transfer-Encoding header field is present in a response and
the chunked transfer coding is not the final encoding, the
message body length is determined by reading the connection until
it is closed by the server.

Or:

If a Transfer-Encoding header field is present in a request and 
the chunked transfer coding is not the final encoding, the 
message body length cannot be determined 
reliably; the server MUST respond with the 400 (Bad Request) 
status code and then close the connection.

Notes:

The paragraph has two apparently contradictory rules. It is unclear which is the correct behaviour.
--VERIFIER NOTES--
They're not contradictory: the first is for responses and the second is for requests, which are different situations.

Errata ID: 4838
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Etan Kissling
Date Reported: 2016-10-22
Rejected by: Alexey Melnikov
Date Rejected: 2017-02-16

Section 4 says:

   Parameters are in the form of a name or name=value pair.

     transfer-parameter = token BWS "=" BWS ( token / quoted-string )

It should say:

   Parameters are in the form of a name or name=value pair.

     transfer-parameter = token 
                        / token BWS "=" BWS ( token / quoted-string )

Notes:

The form of a name cannot be represented with the original ABNF.
--VERIFIER NOTES--
Rejected as per the mailing list discussion:

<https://www.w3.org/Search/Mail/Public/search?type-index=ietf-http-wg&index-type=t&keywords=4838&search=Search>

Errata ID: 5216
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Jingcheng Zhang
Date Reported: 2017-12-25
Rejected by: Alexey Melnikov
Date Rejected: 2018-07-26

Section 5.4. says:

A client MUST send a Host header field in all HTTP/1.1 request
messages.  If the target URI includes an authority component, then a
client MUST send a field-value for Host that is identical to that
authority component, excluding any userinfo subcomponent and its "@"
delimiter (Section 2.7.1).  If the authority component is missing or
undefined for the target URI, then a client MUST send a Host header
field with an empty field-value.

It should say:

A client MUST send a Host header field in all HTTP/1.1 request
messages.  If the target URI includes an authority component, then a
client MUST send a field-value for Host that is identical to that
authority component, excluding any userinfo subcomponent and its "@"
delimiter (Section 2.7.1).  If the authority component is missing or
undefined for the target URI, then a recipient MUST reject this
request.

Notes:

First,

If the target URI includes an authority component, then a
client MUST send a field-value for Host that is identical to that
authority component.

Secondly, section 2.7.1 said:

A sender MUST NOT generate an "http" URI with an empty host
identifier. A recipient that processes such a URI reference MUST
reject it as invalid.

So a recipient MUST reject a request with empty authority.
--VERIFIER NOTES--
As per Roy T. Fielding: Reject. A target URI can be any URI scheme.

Errata ID: 5599
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael James
Date Reported: 2019-01-13
Rejected by: Alexey Melnikov
Date Rejected: 2019-04-15

Throughout the document, when it says:

2.3.  Intermediaries 
...
   HTTP is defined as a stateless protocol, meaning that each request
   message can be understood in isolation.  Many implementations depend
   on HTTP's stateless design in order to reuse proxied connections or
   dynamically load balance requests across multiple servers.  Hence, a
   server MUST NOT assume that two requests on the same connection are
   from the same user agent unless the connection is secured and
   specific to that agent.

2.5.  Conformance and Error Handling
...
   A recipient MUST interpret a received protocol element according to
   the semantics defined for it by this specification, including
   extensions to this specification, unless the recipient has determined
   (through experience or configuration) that the sender incorrectly
   implements what is implied by those semantics.  For example, an
   origin server might disregard the contents of a received
   Accept-Encoding header field if inspection of the User-Agent header
   field indicates a specific implementation version that is known to
   fail on receipt of certain content codings.
...

2.6.  Protocol Versioning
...
   A server MAY send an HTTP/1.0 response to a request if it is known or
   suspected that the client incorrectly implements the HTTP
   specification and is incapable of correctly processing later version
   responses, such as when a client fails to parse the version number
   correctly or when an intermediary is known to blindly forward the
   HTTP-version even when it doesn't conform to the given minor version
   of the protocol.  Such protocol downgrades SHOULD NOT be performed
   unless triggered by specific client attributes, such as when one or
   more of the request header fields (e.g., User-Agent) uniquely match
   the values sent by a client known to be in error.
...

It should say:

2.3.  Intermediaries 
...
   HTTP is defined as a stateless protocol, meaning that each request
   message can be understood in isolation.  Many implementations depend
   on HTTP's stateless design in order to reuse proxied connections or
   dynamically load balance requests across multiple servers.  Hence, a
   server MUST NOT assume that two requests on the same connection are
   from the same user agent unless the connection is secured and
   specific to that agent. User agents MUST include a User-Agent
   request-header field with CONNECT and individual query requests that
   uniquely identify the product making the request thru an
   intermediary.

2.5.  Conformance and Error Handling
...
   A recipient MUST interpret a received protocol element according to
   the semantics defined for it by this specification, including
   extensions to this specification, unless the recipient has determined
   (through experience or configuration) that the sender incorrectly
   implements what is implied by those semantics.  For example, an
   origin server might disregard the contents of a received
   Accept-Encoding header field if inspection of the User-Agent header
   field indicates a specific implementation version that is known to
   fail on receipt of certain content codings. User agents MUST 
   include a User-Agent request-header field with CONNECT and 
   individual query requests that uniquely identify the product
   making the request.
...

2.6.  Protocol Versioning
...
   A server MAY send an HTTP/1.0 response to a request if it is known or
   suspected that the client incorrectly implements the HTTP
   specification and is incapable of correctly processing later version
   responses, such as when a client fails to parse the version number
   correctly or when an intermediary is known to blindly forward the
   HTTP-version even when it doesn't conform to the given minor version
   of the protocol.  Such protocol downgrades SHOULD NOT be performed
   unless triggered by specific client attributes, such as when one or
   more of the request header fields (e.g., User-Agent) uniquely match
   the values sent by a client known to be in error. User agents 
   MUST include a User-Agent request-header field with CONNECT and 
   individual query requests that uniquely identify the product making
   the request.
...

Notes:

User agents MUST include a User-Agent
request-header field with CONNECT and individual query requests that
uniquely identify the product making the request thru an intermediary.

RFC 2616 Sec 14.43 specified made the "User-Agent" request-header as optional "User agents SHOULD include this field with requests." But RFC7230 drops most mentions of the User-Agent request-header field. Without this field intermediaries are left guessing.


Most of the complaints against including the User-Agent header is the monstrosity they have become an the spoofing. Even if the field only contains a SHA-256 hash of the binary making the request, this would differentiate between processes. But having it is still better from a security and interoperability perceptive.
--VERIFIER NOTES--
See WG summary at <https://lists.w3.org/Archives/Public/ietf-http-wg/2019JanMar/0029.html>

Errata ID: 6333
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Jeff Brower
Date Reported: 2020-11-13
Rejected by: Barry Leiba
Date Rejected: 2020-11-13

Section 3.2.6 (PDF) says:

     tchar          = "!" / "#" / "$" / "%" / "&" / "’" / "*"
                    / "+" / "-" / "." / "^" / "_" / "‘" / "|" / "~"

It should say:

     tchar          = "!" / "#" / "$" / "%" / "&" / "'" / "*"
                    / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"

Notes:

The generated PDF contains misleading right and left quotes (U+8217 and U+8216), which are not ASCII characters. The text and html versions of the RFC have the correct apostrophe and grave accent characters (' and `).
--VERIFIER NOTES--
Errata reports only apply to the canonical version of the published RFCs; in this case, that's the rfc7230.txt file, not the generated PDF.

Errata ID: 4136
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Frank Gevaerts
Date Reported: 2014-10-20
Rejected by: Barry Leiba
Date Rejected: 2014-10-21

Section A.2. says:

Bogus Content-Length header fields are now required to be handled as
errors by recipients.  (Section 3.3.2)

It should say:

Bogus Content-Length header fields are now required to be handled as
errors by recipients.  (Section 3.3.3)

Notes:

The mentioned requirement appears in 3.3.3 (5), not in 3.3.2
--VERIFIER NOTES--
The text in 3.3.3 is not what this item is referring to: it really is referring to Section 3.3.2 as a whole.

Errata ID: 4281
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Demian Brecht
Date Reported: 2015-02-26
Rejected by: Barry Leiba
Date Rejected: 2015-03-01

Section 3.3.2 says:

For messages that do not include a payload body, the Content-Length
indicates the size of the selected representation (Section 3 of
[RFC7231]).

It should say:

For outbound messages that do not include a payload body, the
Content-Length indicates the size of the selected representation
(Section 3 of [RFC7231]).

Notes:

Assuming my interpretation is correct, this phrase as-is is a little confusing given the next paragraphs states:

"A user agent SHOULD NOT send a Content-Length header field when the request message does not contain a payload body and the method semantics do not anticipate such a body."

The former is ambiguous, the latter explicit.
--VERIFIER NOTES--
The sentence in question has to be taken in context with the entire paragraph, with the rest of the section, and with the understand that it's only a summary. The details are provided in the rest of the section and in Section 3.3.3.

Errata ID: 5623
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Armin Abfalterer
Date Reported: 2019-02-05
Rejected by: Alexey Melnikov
Date Rejected: 2019-04-15

Section 2.7 says:

absolute-URI  = <absolute-URI, see [RFC3986], Section 4.3>

Notes:

RFC3986 defines "absolute-URI" very openly, especially regarding to "hier-part":

absolute-URI = scheme ":" hier-part [ "?" query ]

hier-part = "//" authority path-abempty
/ path-absolute
/ path-rootless
/ path-empty

The impact is reflected in RFC 7231 in the definition of the header fields Referer and Content-Location.

absolute-URI = <absolute-URI, see [RFC7230], Section 2.7>

Thus, following examples of header values are considered valid

Referer: https:foo/bar
Referer: https:/foo
Referer: https:/
Referer: foo:/

I'd suggest to define "hier-part" (but also "scheme") more strictly.
--VERIFIER NOTES--
As per WG discussion: <https://lists.w3.org/Archives/Public/ietf-http-wg/2019JanMar/0130.html>

Errata ID: 6565
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alissa Tung
Date Reported: 2021-04-29
Rejected by: Francesca Palombini
Date Rejected: 2021-04-29

Section section-6.3 says:

   o  If the received protocol is HTTP/1.0, the "keep-alive" connection
      option is present, the recipient is not a proxy, and the recipient
      wishes to honor the HTTP/1.0 "keep-alive" mechanism, the
      connection will persist after the current response; otherwise,

   o  The connection will close after the current response.

It should say:

   o  If the received protocol is HTTP/1.0, the "keep-alive" connection
      option is present, the recipient is not a proxy, and the recipient
      wishes to honor the HTTP/1.0 "keep-alive" mechanism, the
      connection will persist after the current response; otherwise, the
      connection will close after the current response.

Notes:

Error on breaking paragraph.
--VERIFIER NOTES--
This paragraph split into two bullets was meant to be as is in the document, for readability.

RFC 7231, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", June 2014

Note: This RFC has been obsoleted by RFC 9110

Source of RFC: httpbis (wit)

Errata ID: 4031
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Anne van Kesteren
Date Reported: 2014-06-30
Rejected by: Barry Leiba
Date Rejected: 2014-07-01

Section 3.1.1.1 says:

media-type = type "/" subtype *( OWS ";" OWS parameter )

It should say:

media-type = type "/" subtype *( OWS ";" OWS [parameter] )

Notes:

See the thread at http://lists.w3.org/Archives/Public/ietf-http-wg/2011JulSep/0027.html

Implementations are much more relaxed when it comes to parsing MIME types.

The above is probably still too strict. E.g. requiring that a parameter contains "=" is something I doubt is actually the case in practice.
--VERIFIER NOTES--
The ABNF is there to specify what the expected productions are, and is correct as it stands: we do not *want* things such as these to be produced:

Content-Type: text/plain;
Content-Type: text/plain; charset=iso8859-1;
Content-Type: text/plain;;;;;;;;;;;; ;;; ;;; ;;;

That said, this report addresses a real problem: lack of direction to parsers on how to be appropriately lenient. Because the fact is that general interoperability of this stuff in the wild would be improved if parsers accepted at least the first two of the examples above, which are illegal by the grammar, but which do get generated by less-than-perfect implementations.

I'm marking this report as "Rejected" because the problem it means to address is much broader than this one case, and can't be fixed with an errata report. But it's important that we take up work on a document that does properly address this issue.

Errata ID: 4180
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Michel Albert
Date Reported: 2014-11-14
Rejected by: Barry Leiba
Date Rejected: 2014-11-14

Section 6.4 says:

n/a

It should say:

n/a

Notes:

The section on status code 304 is missing even though that status code is mentioned in other parts of the document. RFC2616 described the status code as follows (in section 10.3.5):


> 10.3.5 304 Not Modified
>
> If the client has performed a conditional GET request and access is
> allowed, but the document has not been modified, the server SHOULD
> respond with this status code. The 304 response MUST NOT contain a
> message-body, and thus is always terminated by the first empty line
> after the header fields.
>
> The response MUST include the following header fields:
>
> - Date, unless its omission is required by section 14.18.1


This section would go right after "6.4.4. 303 See Other".
--VERIFIER NOTES--
Status code 304 relates to conditional requests, and is therefore documented in RFC 7232 (Section 4.1). This fact is shown in the table in RFC 7231, Section 6.1, and in the IANA registry "HTTP Status Codes" <http://www.iana.org/assignments/http-status-codes>.

Errata ID: 4232
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Christopher Olson
Date Reported: 2015-01-14
Rejected by: Barry Leiba
Date Rejected: 2015-01-17

Section 7.1.1.1 says:

GMT

It should say:

+0000

Notes:

The text refers to RFC 5322. There Sect 3.3 calls the use timezone abbreviations, like GMT, obsolete. It encourages using a numeric offset such as +0000.

The grammar for dates in 7231 Sect 7.1.1.1 uses GMT. Example dates throughout this RFC and others related to HTTP use GMT. This is inconsistent with 5322.

The RFCs for HTTP need to be modified to match 5322, or 7.1.1.1 needs a note that HTTP deliberately deviates from 5322 with regards to the timezone.
--VERIFIER NOTES--
The document is quite clear that the "GMT" version is preferred, and is necessary for compatibility with earlier versions and implementations.

Errata ID: 4351
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Nicolas Williams
Date Reported: 2015-04-29
Rejected by: Barry Leiba
Date Rejected: 2015-06-01

Section 4.3.6 says:

   A server MUST NOT send any Transfer-Encoding or Content-Length header
   fields in a 2xx (Successful) response to CONNECT.  A client MUST
   ignore any Content-Length or Transfer-Encoding header fields received
   in a successful response to CONNECT.

   A payload within a CONNECT request message has no defined semantics;
   sending a payload body on a CONNECT request might cause some existing
   implementations to reject the request.

It should say:

   Historically no semantics have been defined for request and 2xx
   (Successful) response bodies for CONNECT, but nonetheless some
   clients and some servers do use request and 2xx response bodies.

   Servers MUST NOT send a response body in a 2xx (Successful)
   response to CONNECT.  Because some proxies send an initial flight
   of tunneled application data in 2xx response bodies, clients MUST
   accept response bodies in 2xx responses to CONNECT, and MUST
   treat the response body as the initial flight of application data.

   Servers that receive a CONNECT request body SHOULD treat it as the
   initial flight of tunneled application data.

Notes:

Implementing the original text ("A client MUST ignore...") has the effect
that the client will leave in the lower layer's buffer any 2xx CONNECT
response body, and when the Transfer-Encoding is the identity, then this
will have the effect that the 2xx response body is seamlessly prepended
to the tunneled application data in the server-to-client direction.
It seems almost like this was the intent of the original text, but if so,
then it would be much better to state this than to describe one possible
implementation approach.

Also, it seems rather unlikely that ignoring the Transfer-Encoding for any
TE other than the identity. If the proxy really did use a compression
or chunked transfer encoding, then ignoring this on the client side
(and prepending the encoded 2xx response body to the server-to-client
tunneled application data) would quite clearly be wrong.

It also seems that some clients send the first flight of tunneled
application data in a CONNECT request body. While historically the
semantics of CONNECT request and 2xx response bodies have not been
defined, it is worth pointing out that [it appears, so I'm told; see
below] some clients and some proxies rely on CONNECT request and 2xx
response bodies bearing the first flight of tunneled application data,
and if so, then the RFC should mention it. I'm not sure how much
evidence we can demand for such behaviors, but the RFC demands behavior
that implies the intent described in this erratum and gives no evidence
to support the need for such behavior, therefore it seems much better
to describe the previously-implied intent explicitly and continue with
a little-or-no-evidence approach that should nonetheless yield the most
interoperability.

Finally, I asked for clarification on the HTTPbis list, and the answers
I received indicate that the intent may have been as described in
these notes.

See https://lists.w3.org/Archives/Public/ietf-http-wg/2015AprJun/0260.html
and follow-ups.
--VERIFIER NOTES--
This is a change request, not an errata report. Such changes can be proposed in the working group's issue tracker, here:
https://github.com/httpwg/http11bis/issues

Errata ID: 5300
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Jeffrey Yasskin
Date Reported: 2018-03-24
Rejected by: Francesca Palombini
Date Rejected: 2021-08-23

Section 8.1 says:

8.1.1.  Procedure

   HTTP method registrations MUST include the following fields:

   o  Method Name (see Section 4)

   o  Safe ("yes" or "no", see Section 4.2.1)

   o  Idempotent ("yes" or "no", see Section 4.2.2)

   o  Pointer to specification text

   Values to be added to this namespace require IETF Review (see
   [RFC5226], Section 4.1).

…

8.1.3.  Registrations

   The "Hypertext Transfer Protocol (HTTP) Method Registry" has been
   populated with the registrations below:

   +---------+------+------------+---------------+
   | Method  | Safe | Idempotent | Reference     |
   +---------+------+------------+---------------+
   | CONNECT | no   | no         | Section 4.3.6 |
   | DELETE  | no   | yes        | Section 4.3.5 |
   | GET     | yes  | yes        | Section 4.3.1 |
   | HEAD    | yes  | yes        | Section 4.3.2 |
   | OPTIONS | yes  | yes        | Section 4.3.7 |
   | POST    | no   | no         | Section 4.3.3 |
   | PUT     | no   | yes        | Section 4.3.4 |
   | TRACE   | yes  | yes        | Section 4.3.8 |
   +---------+------+------------+---------------+

It should say:

8.1.1.  Procedure

   HTTP method registrations MUST include the following fields:

   o  Method Name (see Section 4)

   o  Safe ("yes" or "no", see Section 4.2.1)

   o  Idempotent ("yes" or "no", see Section 4.2.2)

   o  Cacheable ("yes" or "no", see Section 4.2.3)

   o  Pointer to specification text

   Values to be added to this namespace require IETF Review (see
   [RFC5226], Section 4.1).

…

8.1.3.  Registrations

   The "Hypertext Transfer Protocol (HTTP) Method Registry" has been
   populated with the registrations below:

   +---------+------+------------+-----------+---------------+
   | Method  | Safe | Idempotent | Cacheable | Reference     |
   +---------+------+------------+-----------+---------------+
   | CONNECT | no   | no         | no        | Section 4.3.6 |
   | DELETE  | no   | yes        | no        | Section 4.3.5 |
   | GET     | yes  | yes        | yes       | Section 4.3.1 |
   | HEAD    | yes  | yes        | yes       | Section 4.3.2 |
   | OPTIONS | yes  | yes        | no        | Section 4.3.7 |
   | POST    | no   | no         | yes       | Section 4.3.3 |
   | PUT     | no   | yes        | no        | Section 4.3.4 |
   | TRACE   | yes  | yes        | no        | Section 4.3.8 |
   +---------+------+------------+-----------+---------------+

Notes:

HTTP Methods have 3 boolean properties, all of which 8.1.2 says a registration needs to define, but only 2 of them were included in the registry.
--VERIFIER NOTES--
As discussed during work on the HTTP core documents:
> "Cacheable" is not a boolean property of the method, but rather a capability inherent in the system in which one aspect is the method semantics.
See https://github.com/httpwg/http-core/issues/54 for detailed discussion.

Errata ID: 5448
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Magnar Ovedal Myrtveit
Date Reported: 2018-08-02
Rejected by: Alexey Melnikov
Date Rejected: 2018-09-04

Section 7.1.1.1 says:

Recipients of a timestamp value in rfc850-date format, which uses a
two-digit year, MUST interpret a timestamp that appears to be more
than 50 years in the future as representing the most recent year in
the past that had the same last two digits.

It should say:

Recipients of a timestamp value in rfc850-date format, which uses a
two-digit year, MUST interpret a timestamp that appears to be more
than 200 years in the future as representing the most recent date in
the past that also matches the timestamp.

Notes:

The combination of day-of-the-week, day-of-the-month, month, and the two last digits of the year repeats every 400 years. For example, "Friday, 01-Jan-00 00:00:00 GMT" (as formatted by rfc850) happens in the years ...1300, 1700, 2100, 2500, 2900...

With the original text, "Friday, 01-Jan-00 00:00:00 GMT" is interpreted as year 2000, since year 2100 is more than 50 years in the future, and year 2000 is the most recent year in the past with the same last two digits as 2100. However, if it really was year 2000, it should have said "Saturday, 01-Jan-00 00:00:00 GMT". So it would make more sense to interpret it as either year 1700 or year 2100. The corrected text interprets it as year 2100.

"Monday, 01-Jan-00 00:00:00 GMT" happens in years ...1100, 1500, 1900, 2300, 2700..., and is interpreted as year 1900, since 2300 is more than 200 years in the future.
--VERIFIER NOTES--
This changes the original intent of the text, so errata mechanism is not suitable.

Errata ID: 6149
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alan Egerton
Date Reported: 2020-04-29
Rejected by: Francesca Palombini
Date Rejected: 2021-04-29

Section 5.3.2 says:

The media type quality factor associated with a given type is
determined by finding the media range with the highest precedence
that matches the type.  For example,

  Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
          text/html;level=2;q=0.4, */*;q=0.5

would cause the following values to be associated:

+-------------------+---------------+
| Media Type        | Quality Value |
+-------------------+---------------+
| text/html;level=1 | 1             |
| text/html         | 0.7           |
| text/plain        | 0.3           |
| image/jpeg        | 0.5           |
| text/html;level=2 | 0.4           |
| text/html;level=3 | 0.7           |
+-------------------+---------------+

It should say:

The media type quality factor associated with a given type is
determined by finding the media range with the highest precedence
that matches the type.  For example,

  Accept: text/*;q=0.3, text/plain;q=0.7, text/plain;format=flowed,
          text/plain;format=fixed;q=0.4, */*;q=0.5

would cause the following values to be associated:

+--------------------------+---------------+
| Media Type               | Quality Value |
+--------------------------+---------------+
| text/plain;format=flowed | 1             |
| text/plain               | 0.7           |
| text/html                | 0.3           |
| image/jpeg               | 0.5           |
| text/plain;format=fixed  | 0.4           |
| text/plain;delsp=yes     | 0.7           |
+--------------------------+---------------+

Notes:

The optional "level" parameter of media type text/html was removed by informational RFC 2854 (The 'text/html' Media Type), [section 2](https://tools.ietf.org/html/rfc2854#section-2) of which states:

> Note that [HTML20] included an optional "level" parameter; in
> practice, this parameter was never used and has been removed from
> this specification.

More formally, [the current IANA registration of the text/html media type](https://www.iana.org/assignments/media-types/text/html), which is taken directly from [section 16.1 of the HTML specification](https://html.spec.whatwg.org/multipage/iana.html#text/html), does not include a "level" parameter.

Whilst the example is non-normative, it has given rise to misleading information—e.g. in the [MDN Web Docs glossary definition of "quality values"](https://developer.mozilla.org/en-US/docs/Glossary/quality_values), which states:

> Some syntax, like the one of Accept, allow additional specifiers
> like text/html;level=1. These increase the specificity of the value.
> Their use is extremely rare.
--VERIFIER NOTES--
As discussed in the mailing list:

> While it is theoretically possible for media types to no longer define a
> given parameter, it is not possible for them to limit usage of parameters
> in HTTP. This example is still fine.
>
> Note that this example has already been updated in http-core's Accept

Errata ID: 6354
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Sturge
Date Reported: 2020-12-10
Rejected by: Barry Leiba
Date Rejected: 2020-12-15

Section 7.1.2. says:

The field value consists of a single URI-reference.  When it has the
   form of a relative reference ([RFC3986], Section 4.2), the final
   value is computed by resolving it against the effective request URI
   ([RFC3986], Section 5).

   For 201 (Created) responses, the Location value refers to the primary
   resource created by the request.  For 3xx (Redirection) responses,
   the Location value refers to the preferred target resource for
   automatically redirecting the request.

   If the Location value provided in a 3xx (Redirection) response does
   not have a fragment component, a user agent MUST process the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://www.example.org/~tim" might result in a 303 (See Other)
   response containing the header field:

     Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.org/People.html#tim"

It should say:

The field value consists of a single URI-reference. Relative forms are not allowed and MUST include the entire redirected URI, even if the base URL part has not changed.

Notes:

Relative URIs in Location redirect headers should not be allowed.
Allowing relative URIs opens up, at best, inconsistent and poor implementations and interpretations, but more importantly it opens serious security holes.
For example, when the redirect emanates from a URL shortening service (e.g. bitly.com), an attacker can 'chain' multiple relative shortened URIs, effectively obfuscating the final and malicious site.
If security tools attempt to 'rebuild and resolve', this will have an impact on performance, and itself can be exploited by attackers by creating a circular redirect (this can of course be done with full URIs as well, but then a security monitoring tool can more easily detect such a scenario).
Yes, one would expect security tools to only redirect to a small maximum count (say 3), but in a Denial-of-Service attack, many of these can render a security monitoring tool impotent to other attacks happening in parallel.
In addition, unless *all* User-Agents (and there are a lot of them out there) interpret the relative URL absolutely consistently, this can lead to incorrect navigation at best, and such inconsistencies can be easily exploited by attackers at worst.
All in all, at a time when the industry is trying to make internet operations safer and more secure, allowing relative URLs does the opposite, and with little to no gain by allowing.
--VERIFIER NOTES--
The text says what the working group intended it to say, and this is not an erratum. What's more, it accurately reflects real-world usage.

The place to discuss changes such as this proposal, to be considered for future updates, is the HTTP working group's mailing list; see <https://datatracker.ietf.org/wg/httpbis/about/>.

Errata ID: 4224
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bjoern Hoehrmann
Date Reported: 2015-01-09
Rejected by: Barry Leiba
Date Rejected: 2015-01-17

Section 4.1 and A. D says:

     method = token

It should say:

     method = <method, see [RFC7230], Section 3.1.1>

Notes:

The HTTP/1.1 RFCs define rules imported across documents using prose rules for all rules except this one. This is an error because RFC7231 does not mean to re-define the production rule.
--VERIFIER NOTES--
This is asking for an editorial change, but the errata system is not the place to record proposals for editorial improvements. There is an issue tracker at <https://github.com/httpwg/http11bis/issues> for keeping issues for a possible future HTTP 1.1 update.

Errata ID: 4734
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alexey Blyshko
Date Reported: 2016-07-06
Rejected by: RFC Editor
Date Rejected: 2017-01-25

Section 5.3.5 says:

   The "Accept-Language" header field can be used by user agents to
   indicate the set of natural languages that are preferred in the
   response.  Language tags are defined in Section 3.1.3.1.

     Accept-Language = 1#( language-range [ weight ] )
     language-range  =
               <language-range, see [RFC4647], Section 2.1>

   Each language-range can be given an associated quality value
   representing an estimate of the user's preference for the languages
   specified by that range, as defined in Section 5.3.1.  For example,

     Accept-Language: da, en-gb;q=0.8, en;q=0.7

   would mean: "I prefer Danish, but will accept British English and
   other types of English".

It should say:

   The "Accept-Language" header field can be used by user agents to
   indicate the set of natural languages that are preferred in the
   response.  Language tags are defined in Section 3.1.3.1.

     Accept-Language = 1#( language-range [ weight ] )
     language-range  =
               <language-range, see [RFC5646], Section 2.1>

   Each language-range can be given an associated quality value
   representing an estimate of the user's preference for the languages
   specified by that range, as defined in Section 5.3.1.  For example,

     Accept-Language: da, en-GB;q=0.8, en;q=0.7

   would mean: "I prefer Danish, but will accept British English and
   other types of English".

Notes:

RFC4647 -> RFC5646
en-gb -> en-GB


--VERIFIER NOTES--
Rejected per Mark Nottingham (chair of HTTPBIS WG):
As far as I can tell, language-range is defined in RFC 4647, not in RFC 5646. So the change as proposed seems to be incorrect. (See BCP 47.)

The other change, from 'en-gb' to 'en-GB', may be seen as a tiny stylistic improvement (because the 'canonical' way to write country codes in language tags is upper case), but is not at all required (because language tags are case-insensitive).

Errata ID: 6019
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Osipov
Date Reported: 2020-03-16
Rejected by: Barry Leiba
Date Rejected: 2020-07-10

Section 3.1.1.1 says:

 A parameter value that matches the token production can be
   transmitted either as a token or within a quoted-string.  The quoted
   and unquoted values are equivalent.  For example, the following
   examples are all equivalent, but the first is preferred for
   consistency:

     text/html;charset=utf-8
     text/html;charset=UTF-8
     Text/HTML;Charset="utf-8"
     text/html; charset="utf-8"

It should say:

 A parameter value that matches the token production can be
   transmitted either as a token or within a quoted-string.  The quoted
   and unquoted values are equivalent.  For example, the following
   examples are all equivalent, but the first is preferred for
   consistency:

     text/html;charset=utf-8
     text/html;charset=UTF-8

Notes:

Section 3.1.1.2 defines charset value to be a token. I consider this to be a bad example which might cause confusion. Why should I quote the value if it is defined as token?! You make want to use some other example.
--VERIFIER NOTES--
What's relevant is the ABNF for *parameter*, and that allows both token and quoted-string. So the example is correct.

Errata ID: 6814
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: jk
Date Reported: 2022-01-10
Rejected by: Francesca Palombini
Date Rejected: 2022-01-11

Section Table of Contents says:

noneed

It should say:

noneed

Notes:

There is no hyper link to section 7.1.1 in Contents.
--VERIFIER NOTES--
Errata reports are for the authoritative versions hosted on rfc-editor.org, which for this document is the plain text version. As such, issues introduced by the "htmlization" process do not qualify. Additionally, the issue with the characters "ed " added in the ToC was reported in an errata already, see https://www.rfc-editor.org/errata/eid4072.

RFC 7232, "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", June 2014

Note: This RFC has been obsoleted by RFC 9110

Source of RFC: httpbis (wit)

Errata ID: 5236
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Chris Pacejo
Date Reported: 2018-01-16
Rejected by: Barry Leiba
Date Rejected: 2020-08-27

Section 2.1 says:

Likewise, a validator is weak if it is shared by two or more
representations of a given resource at the same time, unless those
representations have identical representation data.  For example, if
the origin server sends the same validator for a representation with
a gzip content coding applied as it does for a representation with no
content coding, then that validator is weak.  However, two
simultaneous representations might share the same strong validator if
they differ only in the representation metadata, such as when two
different media types are available for the same representation data.

It should say:

Likewise, a validator is weak if it is shared by two or more
representations of a given resource at the same time, even if those
representations have identical representation data.  For example, if
the origin server sends the same validator for a representation with
a gzip content coding applied as it does for a representation with no
content coding, then that validator is weak.

Notes:

This paragraph (and only this paragraph) seems to be in direct conflict with this earlier text from the same section:

"However, if a resource has distinct representations that differ only in their metadata, such as might occur with content negotiation over media types that happen to share the same data format, then the origin server needs to incorporate additional information in the [strong] validator to distinguish those representations."
--VERIFIER NOTES--
There is not a conflict here: The text quoted in the notes needs to be read in the context of the entire paragraph it appears in, which the "however" references. The quoted statement is being made in the context of generating strong validators based only upon the message body, when the headers might also change.

RFC 7233, "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", June 2014

Note: This RFC has been obsoleted by RFC 9110

Source of RFC: httpbis (wit)

Errata ID: 4391
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Nathan Herring
Date Reported: 2015-06-11
Rejected by: Barry Leiba
Date Rejected: 2015-06-11

Section 2.1 says:

   If a valid byte-range-set includes at least one byte-range-spec with
   a first-byte-pos that is less than the current length of the
   representation, or at least one suffix-byte-range-spec with a
   non-zero suffix-length, then the byte-range-set is satisfiable.
   Otherwise, the byte-range-set is unsatisfiable.

It should say:

   If a valid byte-range-set includes at least one byte-range-spec with
   a first-byte-pos that is less than the current length of the
   representation, or at least one suffix-byte-range-spec with a
   non-zero suffix-length and the current length of the representation
   is non-zero, then the byte-range-set is satisfiable. Otherwise, the
   byte-range-set is unsatisfiable.

Notes:

Asking for a range that includes trailing bytes (e.g., Range: bytes=-1) when the entity is zero bytes is, as stated here, satisfiable, and yet the service would be forced to yield a 206 code and there is no valid representation of Content-Range header, since you cannot specify a range with no length using the byte range type, the none range type is specified in section 2.3 with a meaning for Accept-Ranges only, and there are no other acceptable ranges in the IANA registry.

The alternative would be that we could overload the use of the none range and return 206 with Content-Length: 0, Content-Range: none for these requests for final bytes.
--VERIFIER NOTES--
It also says, in the same section:

If the selected representation is shorter than the specified
suffix-length, the entire representation is used.

So the response for the posited request is 200 (not 206).

Errata ID: 4472
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Florian Best
Date Reported: 2015-09-13
Rejected by: Barry Leiba
Date Rejected: 2015-09-29

Section 2.1 says:

   o  The first and last bytes only (bytes 0 and 9999):

        bytes=0-0,-1

It should say:

   o  The first and last bytes only (bytes 0 and 9999):

        bytes=0-1,-1

Notes:

If the first byte is requested the offset must be 1.
--VERIFIER NOTES--
The reporter has retracted this after more testing, saying that "The sentence 'the byte positions specified are inclusive' seems to explain it," though he thinks it could be explained more clearly and directly.

Errata ID: 4665
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Amichai Rothman
Date Reported: 2016-04-13
Rejected by: Alexey Melnikov
Date Rejected: 2017-02-23

Section 3.1 says:

It should say:

If all of the preconditions are true and the target representation
length is zero, the server SHOULD send a 200 (OK) response.

Notes:

An empty representation is unsatisfiable according to section 2.1, but not unsatisfiable according to section 4.4 if the first-byte-pos is zero. An empty 200 response is the simplest solution to this contradiction, since it is a valid response anyway (if the server chooses to ignore the Range header), clients already handle it properly, it provides all necessary information to the client, and stating it explicitly can prevent subtle edge-case pitfalls in both the RFC and its implementations.
--VERIFIER NOTES--
Mark Nottingham: this is not an erratum. Please raise an issue here:
<https://github.com/httpwg/http11bis/issues>

Errata ID: 4681
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Kannan Goundan
Date Reported: 2016-04-29
Rejected by: Alexey Melnikov
Date Rejected: 2016-05-05

Section 2.1 says:

byte-range-set  = 1#( byte-range-spec / suffix-byte-range-spec )

It should say:

byte-range-set = *( "," OWS ) ( byte-range-spec /
    suffix-byte-range-spec ) *( OWS "," [ OWS ( byte-range-spec /
    suffix-byte-range-spec ) ] )

Notes:

The document contains two ABNF definitions for "byte-range-set". They appear in Section 2.1 "Byte Ranges" and Appendix D "Collected ABNF".

The two definitions are different. It seems like the definition in Appendix D is the correct one.
--VERIFIER NOTES--
Alexey: As per comment from Julian: "Both are correct. See first sentence of Appendix D."

Errata ID: 4682
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Kannan Goundan
Date Reported: 2016-05-03
Rejected by: Alexey Melnikov
Date Rejected: 2017-02-23

Section 2.1 says:

byte-range-set= 1#( byte-range-spec / suffix-byte-range-spec )

It should say:

According to the "1#element" rule, the expansion would be:

    byte-range-set = ( byte-range-spec /
        suffix-byte-range-spec ) *( OWS "," OWS ( byte-range-spec /
        suffix-byte-range-spec ) )

But Appendix D has the definition:

    byte-range-set = *( "," OWS ) ( byte-range-spec /
        suffix-byte-range-spec ) *( OWS "," [ OWS ( byte-range-spec /
        suffix-byte-range-spec ) ] )

Notes:

This is a followup to my original report: <http://www.rfc-editor.org/errata_search.php?rfc=7233&eid=4681>

My original report was incorrect because I didn't notice the difference between "1*element" and "1#element". Thanks to Julian Reschke for pointing this out to me.

After looking up the "1#element" rule <https://tools.ietf.org/html/rfc7230#section-7>, it looks like Section 2.1 and Appendix D are more similar, but not exactly equivalent.

The Appendix D version of the rule seems to allow extra commas and OWS.
I'm trying to write strict parsing code for this header and am not sure which definition to follow.

P.S. I hope I didn't screw up again. I apologize for wasting your time (again) if I did.
--VERIFIER NOTES--
See HTTPBIS mailing list discussion.

RFC 7234, "Hypertext Transfer Protocol (HTTP/1.1): Caching", June 2014

Note: This RFC has been obsoleted by RFC 9111

Source of RFC: httpbis (wit)

Errata ID: 5564
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruce Adams
Date Reported: 2018-11-27
Rejected by: Alexey Melnikov
Date Rejected: 2019-03-25

Section 4.2.4 says:

A cache MUST NOT send stale responses unless it is disconnected
   (i.e., it cannot contact the origin server or otherwise find a
   forward path) or doing so is explicitly allowed (e.g., by the
   max-stale request directive; see Section 5.2.1).

It should say:

A cache SHOULD NOT send stale responses unless it is disconnected
   (i.e., it cannot contact the origin server or otherwise find a
   forward path) or doing so is explicitly allowed (e.g., by the
   max-stale request directive; see Section 5.2.1).

A cache MAY send stale responses if a cache-control extension for
stale content such as "stale-while-revalidate" is used 
(see RFC5861).

Notes:

The original text seems to conflict with https://tools.ietf.org/html/rfc5861#section-3

3. The stale-while-revalidate Cache-Control Extension

When present in an HTTP response, the stale-while-revalidate Cache-
Control extension indicates that caches MAY serve the response in
which it appears after it becomes stale, up to the indicated number
of seconds.

stale-while-revalidate = "stale-while-revalidate" "=" delta-seconds

If a cached response is served stale due to the presence of this
extension, the cache SHOULD attempt to revalidate it while still
serving stale responses (i.e., without blocking).

See also https://stackoverflow.com/questions/53324538/rest-low-latency-how-should-i-reply-to-a-get-while-an-upload-is-pending
--VERIFIER NOTES--
Mark Nottingham wrote:

Extensions are explicitly allowed to override requirements, and
making this a SHOULD would be too confusing (as many would read it as
"optional").

Errata ID: 4479
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Florian Best
Date Reported: 2015-09-20
Rejected by: Barry Leiba
Date Rejected: 2015-09-20

Section 5.3 says:

   The Expires value is an HTTP-date timestamp, as defined in 
   <a href="#section-7.1.1.1">Section</a>
   <a href="#section-7.1.1.1">7.1.1.1</a> of 
[<a href="./rfc7231" title="&quot;Hypertext Transfer Protocol (HTTP/1.1)
   : Semantics and Content&quot;">RFC7231</a>].

It should say:

   The Expires value is an HTTP-date timestamp, as defined in 
   <a href="./rfc7231#section-7.1.1.1">Section</a>
   <a href="./rfc7231#section-7.1.1.1">7.1.1.1</a> of 
[<a href="./rfc7231" title="&quot;Hypertext Transfer Protocol (HTTP/1.1)
   : Semantics and Content&quot;">RFC7231</a>].

Notes:

The anchor should link to RFC 7231. It links to the not-existing section in RFC 7234 itself.
--VERIFIER NOTES--
The links are not in the RFCs, but in the HTML tools rendering. The errata system isn't for that.

Errata ID: 4616
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Brian Chang
Date Reported: 2016-02-08
Rejected by: Alexey Melnikov
Date Rejected: 2017-02-23

Throughout the document, when it says:

(See Section 3.2 for additional details related to the use of public in
 response to a request containing Authorization, and Section 3 for 
 details of how public affects responses that would normally not be 
 stored, due to their status codes not being defined as cacheable 
 by default; see Section 4.2.2.)

has a status code that is defined as cacheable by default 
(see Section 4.2.2), or

It should say:

(See Section 3.2 for additional details related to the use of public in
 response to a request containing Authorization, and Section 3 for 
 details of how public affects responses that would normally not be 
 stored, due to their status codes not being defined as cacheable 
 by default; see Section 6.1 of [RFC7231].)

has a status code that is defined as cacheable by default 
(see Section 6.1 of [RFC7231]), or

Notes:

Section 4.2.2 is titled "Calculating Heuristic Freshness" but is referenced in the original text when talking about status codes. This is confusing despite having a reference to Section 6.1 of RFC7231 buried within the text.

There are other references to 4.2.2 as well, but those actually talk about heuristic freshness.
--VERIFIER NOTES--
See HTTPBIS mailing list discussion.

RFC 7235, "Hypertext Transfer Protocol (HTTP/1.1): Authentication", June 2014

Note: This RFC has been obsoleted by RFC 9110

Source of RFC: httpbis (wit)

Errata ID: 6307
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Nick Cullen
Date Reported: 2020-10-15
Rejected by: Barry Leiba
Date Rejected: 2020-10-19

Section 2.1 says:

2.1.  Challenge and Response

   HTTP provides a simple challenge-response authentication framework
   that can be used by a server to challenge a client request and by a
   client to provide authentication information.  It uses a case-
   insensitive token as a means to identify the authentication scheme,
   followed by additional information necessary for achieving
   authentication via that scheme.  The latter can be either a comma-
   separated list of parameters or a single sequence of characters
   capable of holding base64-encoded information.

   Authentication parameters are name=value pairs, where the name token
   is matched case-insensitively, and each parameter name MUST only
   occur once per challenge.

     auth-scheme    = token

     auth-param     = token BWS "=" BWS ( token / quoted-string )

It should say:

2.1.  Challenge and Response

   HTTP provides a simple challenge-response authentication framework
   that can be used by a server to challenge a client request and by a
   client to provide authentication information.  It uses a case-
   insensitive token as a means to identify the authentication scheme,
   followed by additional information necessary for achieving
   authentication via that scheme.  The latter can be either a comma-
   separated list of parameters or a single sequence of characters
   capable of holding base64-encoded information.

   Authentication parameters are name=value pairs, where the name token
   is matched case-insensitively, and each parameter name MUST only
   occur once per challenge.

     auth-scheme    = itoken

     auth-param     = itoken BWS "=" BWS ( token / quoted-string )

N.B. itoken is a restricted subset of token to ensure well defined case insensitivity.

Notes:

The general token specification allows many characters (including VCHAR) which means that case insensitivity is tricky to define. A more limited subset of token would be sensible, and the distinction between itoken and token is important in understanding the BNF, and matching that to the specification. The section above is a good example of the confusion that can arise, with 3 instances of token in the ABNF, but two of them are to be interpreted in a different way than the third occurence..
Confusion causes incompatibility with NEGOTIATE being rejected by a system that implements the ABNF, but wrongly expects Negotiate.
P.S. My 'corrected text' and my understanding of ABNF are incomplete. I crave assistance in forming a properly written definition of itoken to 'well define' the safe subset.
--VERIFIER NOTES--
The RFC says exactly what was intended, and changing that is beyond the scope of errata reports, and likely beyond the scope of the document. If there's an issue to discuss for a future revision of the RFC, an issue can be filed here:
https://github.com/httpwg/http-core/issues/

RFC 7240, "Prefer Header for HTTP", June 2014

Note: This RFC has been updated by RFC 8144

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 4317
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Brendan Long
Date Reported: 2015-03-30
Rejected by: Barry Leiba
Date Rejected: 2015-04-02

Throughout the document, when it says:

Prefer: respond-async, wait=100
Prefer: handling=lenient

Prefer: handling=lenient, wait=100, respond-async

Prefer: respond-async, wait=10
Prefer: priority=5

Prefer: respond-async, wait=10

It should say:

Prefer: respond-async; wait=100
Prefer: handling=lenient

Prefer: handling=lenient; wait=100; respond-async

Prefer: respond-async; wait=10
Prefer: priority=5

Prefer: respond-async; wait=10

Notes:

The ABNF in Section 2 says that preferences are separated with ";", but some of the examples use ",".
--VERIFIER NOTES--
The document is correct as is stands. The commas are separating
multiple preferences in a single header, as described in RFC 7230,
Section 7. The ABNF in Section 2 specifies how to separate parameters
within a single preference.

RFC 7241, "The IEEE 802/IETF Relationship", July 2014

Note: This RFC has been updated by RFC 9141

Source of RFC: IAB

Errata ID: 7609
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Peter Yee
Date Reported: 2023-08-19
Rejected by: RFC Editor
Date Rejected: 2024-04-09

Section 3.3 says:

(available at <https://datatracker.ietf.org/documents/LIAISON/file41.pdf>)

It should say:

(available at <https://www.ietf.org/lib/dt/documents/LIAISON/file41.pdf>)

Notes:

The datatracker location of the liaison statement from IEEE 802 has moved, leaving a dead link in RFC 7241.
--VERIFIER NOTES--
The link was correct at time of publication. In addition, a redirect is in place so it still works.

RFC 7252, "The Constrained Application Protocol (CoAP)", June 2014

Note: This RFC has been updated by RFC 7959, RFC 8613, RFC 8974, RFC 9175

Source of RFC: core (wit)

Errata ID: 4946
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Klaus Hartke
Date Reported: 2017-02-22
Rejected by: Francesca Palombini
Date Rejected: 2023-01-18

Section 6.1 says:

coap-URI = "coap:" "//" host [ ":" port ] path-abempty [ "?" query ]

It should say:

coap-URI = "coap:" "//" host [ ":" port ] path-abempty [ "?" query ]
               [ "#" fragment ]

Notes:

The optional fragment component allows for indirect identification of a secondary resource, as defined in Section 3.5 of RFC 3986. The fragment identifier is separated from the rest of the URI prior to a dereference; fragment identifiers are processed client-side and are not included in CoAP requests. The original text shows the syntax of coap:// URIs _after_ separating the fragment identifier, which leaves ambiguity as to whether fragment identifiers are supported or not. The corrected text shows the syntax of CoAP URIs _before_ separating the fragment identifier, which makes clear that fragment identifiers are supported.
--VERIFIER NOTES--
This errata is rejected to remain aligned with HTTP, see RFC 9110, Section 4.2.1

Errata ID: 4947
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Klaus Hartke
Date Reported: 2017-02-22
Rejected by: Francesca Palombini
Date Rejected: 2023-01-18

Section 6.2 says:

coaps-URI = "coaps:" "//" host [ ":" port ] path-abempty
               [ "?" query ]

It should say:

coaps-URI = "coaps:" "//" host [ ":" port ] path-abempty
               [ "?" query ] [ "#" fragment ]

Notes:

The optional fragment component allows for indirect identification of a secondary resource, as defined in Section 3.5 of RFC 3986. The fragment identifier is separated from the rest of the URI prior to a dereference; fragment identifiers are processed client-side and are not included in CoAP requests. The original text shows the syntax of coaps:// URIs _after_ separating the fragment identifier, which leaves ambiguity as to whether fragment identifiers are supported or not. The corrected text shows the syntax of CoAP URIs _before_ separating the fragment identifier, which makes clear that fragment identifiers are supported.
--VERIFIER NOTES--
This errata is rejected to remain aligned with HTTP, see RFC 9110, Section 4.2.2

Errata ID: 5284
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Mohamed Boucadair
Date Reported: 2018-03-09
Rejected by: Francesca Palombini
Date Rejected: 2023-01-18

Section 5.3.1 says:

The client SHOULD generate tokens in such a way that tokens currently
in use for a given source/destination endpoint pair are unique.

It should say:

The client SHOULD generate tokens in such a way that tokens currently
in use for a given source/destination endpoint pair are unique per
request.

Notes:

Multiple requests may be active for a given source/destination
endpoint pair. The OLD text is thus broken.

The NEW text is aligned with the definition of the Token:

A token is intended for use as a client-local identifier for
differentiating between concurrent requests (see Section 5.3); it
could have been called a "request ID".

Further, using the same token for a given source/destination endpoint
pair have some implications, for example, for applications which
require the support of multiple observe queries because RFC7641
states the following:

The entry in the list of observers is keyed by the client endpoint
and the token specified by the client in the request. If an entry
with a matching endpoint/token pair is already present in the list
(which, for example, happens when the client wishes to reinforce
its interest in a resource), the server MUST NOT add a new entry
but MUST replace or update the existing one.
--VERIFIER NOTES--
After discussing with the working group, it was agreed that the original text is correct and that the addition is redundant and does not help clarify it.

Errata ID: 5429
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Marian Buschsieweke
Date Reported: 2018-07-18
Rejected by: Francesca Palombini
Date Rejected: 2023-01-18

Section 4.4 says:

An Acknowledgement or Reset message is related to a Confirmable
message or Non-confirmable message by means of a Message ID along
with additional address information of the corresponding endpoint.
The Message ID is a 16-bit unsigned integer that is generated by the
sender of a Confirmable or Non-confirmable message and included in
the CoAP header.  The Message ID MUST be echoed in the
Acknowledgement or Reset message by the recipient.

The same Message ID MUST NOT be reused (in communicating with the
same endpoint) within the EXCHANGE_LIFETIME (Section 4.8.2).

Implementation Note:  Several implementation strategies can be
  employed for generating Message IDs.  In the simplest case, a CoAP
  endpoint generates Message IDs by keeping a single Message ID
  variable, which is changed each time a new Confirmable or Non-
  confirmable message is sent, regardless of the destination address
  or port.  Endpoints dealing with large numbers of transactions
  could keep multiple Message ID variables, for example, per prefix
  or destination address.  (Note that some receiving endpoints may
  not be able to distinguish unicast and multicast packets addressed
  to it, so endpoints generating Message IDs need to make sure these
  do not overlap.)  It is strongly recommended that the initial
  value of the variable (e.g., on startup) be randomized, in order
  to make successful off-path attacks on the protocol less likely.

It should say:

An Acknowledgement or Reset message is related to a Confirmable
message or Non-confirmable message by means of a Message ID along
with additional address information of the corresponding endpoint.
The Message ID is a 16-bit unsigned integer that is generated by the
sender of a Confirmable or Non-confirmable message and included in
the CoAP header.  Message IDs of subsequence messages send to the
same endpoint within EXCHANGE_LIFETIME MUST be strictly ascending
(wrapping around at a value of 65535).  Additionally, two
subsequently send Message IDs to the same endpoint SHOULD have a
difference of at most 16.  The Message ID MUST be echoed in the
Acknowledgement or Reset message by the recipient.

The same Message ID MUST NOT be reused (in communicating with the
same endpoint) within the EXCHANGE_LIFETIME (Section 4.8.2).

Implementation Note:  Several implementation strategies can be
  employed for generating Message IDs.  In the simplest case, a CoAP
  endpoint generates Message IDs by keeping a single Message ID
  variable, which is incremented each time a new Confirmable or Non-
  confirmable message is sent, regardless of the destination address
  or port.  Endpoints dealing with large numbers of transactions
  could keep multiple Message ID variables, for example, per prefix
  or destination address.  (Note that some receiving endpoints may
  not be able to distinguish unicast and multicast packets addressed
  to it, so endpoints generating Message IDs need to make sure these
  do not overlap.)  It is strongly recommended that the initial
  value of the variable (e.g., on startup) be randomized, in order
  to make successful off-path attacks on the protocol less likely.

Notes:

Without any restrictions on how Message IDs are generated, an implementation of CoAP duplication detection must be prepared to receive a random sequence of Message IDs.
One simple implementation strategy would be to store the received Message IDs along with a timestamp when they were received.
If a 16 bit time stamp would be used, 4 Bytes per tracked Message ID would be required.
If additionaly a CoAP server expects requests to be received at a rate of 1 message per second, at least 247 * 4 Byte or approximately 1 KiB have to be allocated per client.
A class 1 (see RFC 7228 Section 3) server could handle at most 10 clients in parallel, if anything apart duplicate detection could be implemented without using any memory at all.

If instead Message IDs have to be generated by incrementing a (global or per endpoint/network prefix/...) counter variable, duplicate detection can be implemented in a time and memory efficient way without limiting the rate of the message exchange between to nodes.
--VERIFIER NOTES--
In rejecting this Errata report I note that the reported error is not a typo, but a deliberate decision of the authors and working group. The change, therefore, if it is to be applied needs to be achieved through a consensus document.

RFC 7257, "Virtual Private LAN Service (VPLS) Management Information Base", July 2014

Source of RFC: l2vpn (rtg)

Errata ID: 4059
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexander ("Sasha") Vainshtein
Date Reported: 2014-07-23
Rejected by: Adrian Farrel
Date Rejected: 2014-11-20

Section 6 says:

N/A - this is about some missing MIB objects that should be there

It should say:

N/A - this is hardly the right place to define missing MIB objects

Notes:

As per RFC 4762 (which defines at least one of the two VPLS types for which this RFC defines Management Information Base), Virtual Switching Instance (VSI)(a local representation of a given VPLS instance within a given PE) is connected to CE devices via Attachment Circuits (AC). Hence I would expect that Management Information Base for VPLS would provide for some representation of ACs that perform this function for a given VSI.

However, this RFC does not even mention attachment circuits in any way.

I have tried to raise this issue with the WG and the authors. One of the authors has replied (see http://www.ietf.org/mail-archive/web/l2vpn/current/msg04539.html) that "ACs are attached to the VPLS instances and are represented as IfMIB entries". However, neither Interfaces MIB nor any of its key elements (e.g., ifIndex) are mentioned in this RFC.
--VERIFIER NOTES--
The errata system isn't to be used for recording future work or major defects in RFCs. These need to be taken to the relevant mailing lists (in this case pals@ietf.org) and progressed with Internet-Drafts.

This concern could probably be addressed through a new MIB module that augments the on in RFC 7257.

RFC 7296, "Internet Key Exchange Protocol Version 2 (IKEv2)", October 2014

Note: This RFC has been updated by RFC 7427, RFC 7670, RFC 8247, RFC 8983, RFC 9370

Source of RFC: ipsecme (sec)

Errata ID: 4930
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2017-02-08
Rejected by: Paul Wouters
Date Rejected: 2022-04-11

Section 3.16 says:

   Note that since IKE passes an indication of initiator identity in the
   first message in the IKE_AUTH exchange, the responder SHOULD NOT send
   EAP Identity requests.  The initiator MAY, however, respond to such
   requests if it receives them.

Notes:

The last sentence of this section contains unnecessary repetition written above (the last sentence in description of Type field).
--VERIFIER NOTES--
The text is fine and clear as is.

RFC 7301, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", July 2014

Note: This RFC has been updated by RFC 8447

Source of RFC: tls (sec)

Errata ID: 5176
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Ilya Grigorik
Date Reported: 2017-11-02
Rejected by: Paul Wouters
Date Rejected: 2024-03-21

Section 6 says:

IANA Considerations

It should say:

+Protocol:  HTTP/1.0
+Protocol:  HTTP/0.9

Notes:

RFC does not register ALPN identifiers for http/0.9 or http/1.0.
--VERIFIER NOTES--
Errata is not the method for modifying requests to IANA

See also: https://mailarchive.ietf.org/arch/msg/tls/j_A2WszoHniWzD609Cal5lFslxw/

RFC 7317, "A YANG Data Model for System Management", August 2014

Source of RFC: netmod (ops)

Errata ID: 4795
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kaja Mohideen
Date Reported: 2016-09-05
Rejected by: Benoit Claise
Date Rejected: 2016-09-05

Section 5 says:

typedef crypt-hash {
       type string {
         pattern
           '$0$.*'
         + '|$1$[a-zA-Z0-9./]{1,8}$[a-zA-Z0-9./]{22}'
         + '|$5$(rounds=\d+$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{43}'
         + '|$6$(rounds=\d+$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{86}';
       }

It should say:

typedef crypt-hash {
  type string {
    pattern
        '\$0\$.*'
      + '|\$1\$[a-zA-Z0-9./]{1,8}\$[a-zA-Z0-9./]{22}'
      + '|\$5\$(rounds=\d+\$)?[a-zA-Z0-9./]{1,16}\$[a-zA-Z0-9./]{43}'
      + '|\$6\$(rounds=\d+\$)?[a-zA-Z0-9./]{1,16}\$[a-zA-Z0-9./]{86}';
  }
  

Notes:

Character $ has special meaning in regular expression.
--VERIFIER NOTES--
No, "$" is not special in the regular expression dialect used in YANG
(XML Schema).

RFC 7323, "TCP Extensions for High Performance", September 2014

Source of RFC: tcpm (wit)

Errata ID: 5586
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Marco Caspers
Date Reported: 2018-12-27
Rejected by: Mirja Kühlewind
Date Rejected: 2020-03-06

Section 2.3 says:

Since the max window is 2^S (where S is the scaling shift count)
   times at most 2^16 - 1 (the maximum unscaled window), the maximum
   window is guaranteed to be < 2^30 if S <= 14.  Thus, the shift count
   MUST be limited to 14 (which allows windows of 2^30 = 1 GiB).  If a
   Window Scale option is received with a shift.cnt value larger than
   14, the TCP SHOULD log the error but MUST use 14 instead of the
   specified value.  This is safe as a sender can always choose to only
   partially use any signaled receive window.  If the receiver is
   scaling by a factor larger than 14 and the sender is only scaling by
   14, then the receive window used by the sender will appear smaller
   than it is in reality.

It should say:

Since the max window is 2^S (where S is the scaling shift count)
   times at most 2^16 - 1 (the maximum unscaled window), the maximum
   window is guaranteed to be < 2^30-2^14 if S <= 14.  Thus, the shift
 count
   MUST be limited to 14 (which allows windows of 2^30-2^14 ~ 1 GiB).
  If a
   Window Scale option is received with a shift.cnt value larger than
   14, the TCP SHOULD log the error but MUST use 14 instead of the
   specified value.  This is safe as a sender can always choose to only
   partially use any signaled receive window.  If the receiver is
   scaling by a factor larger than 14 and the sender is only scaling by
   14, then the receive window used by the sender will appear smaller
   than it is in reality.

Notes:

Shifting is inserting zeroes on the right hand side. Thus for S = 14 the 14 right most bits are zero and thus the calculation 2^30 is invalid for the guaranteed maximum window size.

Correct calculation formulae is (2^30 - 1) - (2^14 -1).
Which can be simplified to 2^30 - 2^14.
--VERIFIER NOTES--
That section is for illustration purposes only, and not intended as an exact value for the maximum supported window size.

It is correct that the maximum supported window size is 2^30-2^14, but the requirement is, that the window size has to remain smaller than 2^30.

Errata ID: 6798
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Yaakov Stein
Date Reported: 2021-12-26
Rejected by: Martin Duke
Date Rejected: 2022-05-13

Throughout the document, when it says:

The Timestamps option may appear in any data or <ACK> segment, adding

The timestamp clock may be derived from a system clock that is

A random offset may be added to the timestamp clock on a per-

It should say:

The Timestamps option MAY appear in any data or <ACK> segment, adding

The timestamp clock MAY be derived from a system clock that is

A random offset MAY be added to the timestamp clock on a per-

Notes:

several "MAY"s were incorrectly written as non RFC 2119 "may"s
--VERIFIER NOTES--
These examples are non-normative. The first is explanatory, and the other two are examples of ways to meet the requirement.

RFC 7332, "Loop Detection Mechanisms for Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)", August 2014

Source of RFC: straw (rai)

Errata ID: 4108
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Chozhan A
Date Reported: 2014-09-11
Rejected by: Ben Campbell
Date Rejected: 2017-03-15

Section 5 says:

If the received request did not contain a Max-Forwards header field,
one MUST be created in any request generated in the UAC side, as
described for proxies in Section 16.6, Step 3 of [RFC3261].

It should say:

If B2BUA creates a request as a result of processing a
incoming response, Max-Forwards MUST be added in any request
generated in the UAC side, as described for proxies in
Section 16.6, Step 3 of [RFC3261].

Notes:

Max-Forward is mandatory for Request as per RFC 3261. So this case is possible only on response processing.
--VERIFIER NOTES--
The existing text is correct. The fact that Max-Forwards is required to be present in a request does not invalidate text that says what to do if it is not.

RFC 7346, "IPv6 Multicast Address Scopes", August 2014

Source of RFC: 6man (int)

Errata ID: 6236
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Richardson
Date Reported: 2020-07-24
Rejected by: RFC Editor
Date Rejected: 2024-02-15

Section 5 says:

5.  Definition of Realm-Local Scope for IEEE 802.15.4

   When used in an IP-over-IEEE802.15.4 network, scop 3 is defined to
   include all interfaces sharing a Personal Area Network Identifier
   (PAN ID).

It should say:

5.  Definition of Realm-Local Scope for IEEE 802.15.4

   When used in an IP-over-IEEE802.15.4 network, scope 3 is defined to
   include all interfaces sharing a Personal Area Network Identifier
   (PAN ID).

Notes:

missing trailing 'e'
--VERIFIER NOTES--
Section 2.7 of RFC 4291 defines the field in the multicast address as "scop". This text is referencing the "scop" field.

RFC 7413, "TCP Fast Open", December 2014

Source of RFC: tcpm (wit)

Errata ID: 6239
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Simon khng ren hao
Date Reported: 2020-07-27
Rejected by: Martin Duke
Date Rejected: 2020-07-27

Section 5.2 says:

produces responses earlier before the handshake completes

It should say:

produces responses after the handshake completes

Notes:

Located on last paragraph last line of section on page 16. First line states 'not to respond with data until the handshake finishes' which contradicts the last line.
--VERIFIER NOTES--
This erratum does not correctly interpret the paragraph.

The sentence is:
"But the potential latency saving from TFO may diminish if the server application
produces responses earlier before the handshake completes."

The text refers to when the server response is available, not when it is sent. If the server data isn't yet available, then there is no message to withhold and therefore no performance penalty in waiting for the handshake to complete.

RFC 7421, "Analysis of the 64-bit Boundary in IPv6 Addressing", January 2015

Source of RFC: 6man (int)

Errata ID: 5699
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alexandre PETRESCU
Date Reported: 2019-04-19
Rejected by: Erik Kline
Date Rejected: 2021-12-18

Throughout the document, when it says:

Internet Engineering Task Force (IETF)                 B. Carpenter, Ed.
Request for Comments: 7421                             Univ. of Auckland
Category: Informational                                         T. Chown
ISSN: 2070-1721                                     Univ. of Southampton
                                                                 F. Gont
                                                  SI6 Networks / UTN-FRH
                                                                S. Jiang
                                            Huawei Technologies Co., Ltd
                                                             A. Petrescu
                                                               CEA, LIST
                                                          A. Yourtchenko
                                                                   Cisco
                                                            January 2015

It should say:

Internet Engineering Task Force (IETF)                 B. Carpenter, Ed.
Request for Comments: 7421                             Univ. of Auckland
Category: Informational                                         T. Chown
ISSN: 2070-1721                                     Univ. of Southampton
                                                                 F. Gont
                                                  SI6 Networks / UTN-FRH
                                                                S. Jiang
                                            Huawei Technologies Co., Ltd
                                                          A. Yourtchenko
                                                                   Cisco
                                                            January 2015

Notes:

For some reason I got in the group, then participated positively to the discussion, and I let myself tempted to have my name up on the first page of a published RFC; but finally, after much time and reflexion, I think I do not agree with the effects of this RFC.

I do not agree that 64bit is a boundary.

Remark: you are asking Type 'Technical' or 'Editorial'; only one choice is possible. I do not understand that. My issue is both.
--VERIFIER NOTES--
Quoting the AD at the time: "RFCs are immutable once published. Period."

For more discussion, see the mail archive thread https://mailarchive.ietf.org/arch/msg/ipv6/HzHbbAqaa4qquKNjaYtv3Te7IJc/

RFC 7427, "Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)", January 2015

Source of RFC: ipsecme (sec)

Errata ID: 4295
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Annie Yousar
Date Reported: 2015-03-10
Rejected by: Kathleen Moriarty
Date Rejected: 2015-03-31

Section A.4.2 says:

   Here the parameters are present and contain the default parameters,
   i.e., hashAlgorithm of SHA-1, maskGenAlgorithm of mgf1SHA1,
   saltLength of 20, and trailerField of 1.

   0000 : SEQUENCE
   0002 :   OBJECT IDENTIFIER  RSASSA-PSS (1.2.840.113549.1.1.10)
   000d :   SEQUENCE
   000f :     CONTEXT 0
   0011 :       SEQUENCE
   0013 :         OBJECT IDENTIFIER  id-sha1 (1.3.14.3.2.26)
   001a :         NULL
   001c :     CONTEXT 1
   001e :       SEQUENCE
   0020 :         OBJECT IDENTIFIER  1.2.840.113549.1.1.8
   002b :         SEQUENCE
   002d :           OBJECT IDENTIFIER  id-sha1 (1.3.14.3.2.26)
   0034 :           NULL
   0036 :     CONTEXT 2
   0038 :       INTEGER   0x14 (5 bits)
   003b :     CONTEXT 3
   003d :       INTEGER   0x1 (1 bits)

   Name = RSASSA-PSS with default parameters,
          oid = 1.2.840.113549.1.1.10
   Length = 64
   0000: 303e 0609 2a86 4886 f70d 0101 0a30 31a0
   0010: 0b30 0906 052b 0e03 021a 0500 a118 3016
   0020: 0609 2a86 4886 f70d 0101 0830 0906 052b
   0030: 0e03 021a 0500 a203 0201 14a3 0302 0101

It should say:

   If the default parameters are used, i.e., hashAlgorithm of SHA-1, 
   maskGenAlgorithm of mgf1SHA1, saltLength of 20, and trailerField 
   of 1, the parameters MUST NOT be encoded according to the 
   Distiguished Encoding Rules (DER) of ASN.1. Therefore the encoding
   is the same as of A.4.1.

   0000 : SEQUENCE
   0002 :   OBJECT IDENTIFIER  RSASSA-PSS (1.2.840.113549.1.1.10)
   000d :   SEQUENCE

   Name = RSASSA-PSS with default parameters,
          oid = 1.2.840.113549.1.1.10
   Length = 15
   0000: 300d 0609 2a86 4886 f70d 0101 0a30 00

Notes:

Section 3 requires the use of DER:
The ASN.1 used here is the same ASN.1 used in the AlgorithmIdentifier of PKIX (see Section 4.1.1.2 of [RFC5280]), encoded using distinguished encoding rules (DER) [CCITT.X690.2002].

KM: Reviewed by expert and response provided.

--VERIFIER NOTES--
From Tero Kivinen

In the RFC 4055 the section 3.1 says that even when the
default values are used the implementation MUST understand both
formats, i.e. the case where the default value is omitted and the case
where the default value is explicitly given:

From RFC4055 section 3.1:

hashAlgorithm

The hashAlgorithm field identifies the hash function. It MUST
be one of the algorithm identifiers listed in Section 2.1, and
the default hash function is SHA-1. Implementations MUST
support SHA-1 and MAY support any of the other one-way hash
functions listed in Section 2.1. Implementations that perform
signature generation MUST omit the hashAlgorithm field when
SHA-1 is used, indicating that the default algorithm was used.
Implementations that perform signature validation MUST
recognize both the sha1Identifier algorithm identifier and an
absent hashAlgorithm field as an indication that SHA-1 was
used.

In this case we are not actually doing either one of those options, we
are not generating signature, and we are not validating them. In this
document we are simply indicating what kind of signature will follows
this binary blob. Yes, when generating those ASN.1 objects for default
values implementations should use the A.4.1 version, but they might
also want to understand the version specified in the A.4.2.

Note, that in some cases the implementations might simply take the
AlgorithmIdentifier pieces from their own certificate and not generate
it at all, and this might cause them to take whatever the CA vendor
generated for them.

Actually when checking for the RFC4055 I notice it says that same
thing (MUST omit in generate, MUST recognize both) for everything else
(hashAlgorithm, maskGenAlgorithm, and trailerField) expect for
saltLength... I do not know if this means that for saltLength we
should actually not encode the default as number or if this is just
sloppy writing of the RFC4055...

> 0000 : SEQUENCE
> 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10)
> 000d : SEQUENCE
>
> Name = RSASSA-PSS with default parameters,
> oid = 1.2.840.113549.1.1.10
> Length = 15
> 0000: 300d 0609 2a86 4886 f70d 0101 0a30 00
>
>
> Notes
> -----
> Section 3 requires the use of DER:
> The ASN.1 used here is the same ASN.1 used in the AlgorithmIdentifier of PKIX (see Section 4.1.1.2 of [RFC5280]), encoded using distinguished encoding rules (DER) [CCITT.X690.2002].

Yes, when generating them they needs to be in DER, when matching the
values sent from the other end, the matching can be looser.


The format A.4.1 MUST be used when generating the RSASSA-PSS with default parameters, but A.4.2 can also be recognized.

If the implementation has real ASN.1 parser this is exactly what it will do automatically.

Errata ID: 4296
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Annie Yousar
Date Reported: 2015-03-10
Rejected by: Kathleen Moriarty
Date Rejected: 2015-03-24

Section A.4.3 says:

   Here the parameters are present and contain hashAlgorithm of SHA-256,
|  maskGenAlgorithm of SHA-256, saltLength of 32, and trailerField of 1.

   0000 : SEQUENCE
   0002 :   OBJECT IDENTIFIER  RSASSA-PSS (1.2.840.113549.1.1.10)
   000d :   SEQUENCE
   000f :     CONTEXT 0
   0011 :       SEQUENCE
   0013 :         OBJECT IDENTIFIER  id-sha256 (2.16.840.1.101.3.4.2.1)
   001e :         NULL
   0020 :     CONTEXT 1
   0022 :       SEQUENCE
|  0024 :         OBJECT IDENTIFIER  1.2.840.113549.1.1.8
   002f :         SEQUENCE
   0031 :           OBJECT IDENTIFIER id-sha256 (2.16.840.1.101.3.4.2.1)
   003c :           NULL
   003e :     CONTEXT 2
   0040 :       INTEGER   0x20 (6 bits)
|  0043 :     CONTEXT 3
|  0045 :       INTEGER   0x1 (1 bits)

   Name = RSASSA-PSS with sha-256, oid = 1.2.840.113549.1.1.10
|  Length = 72
   0000: 3046 0609 2a86 4886 f70d 0101 0a30 39a0
   0010: 0f30 0d06 0960 8648 0165 0304 0201 0500
   0020: a11c 301a 0609 2a86 4886 f70d 0101 0830
   0030: 0d06 0960 8648 0165 0304 0201 0500 a203
|  0040: 0201 20a3 0302 0101

It should say:

   Here the parameters are present and contain hashAlgorithm of SHA-256,
|  maskGenAlgorithm of MGF1 with SHA-256, saltLength of 32, and 
|  trailerField of 1.
|  Note that since the trailerField has the default value it MUST NOT be
|  encoded according to the Distiguished Encoding Rules (DER) of ASN.1.

   0000 : SEQUENCE
   0002 :   OBJECT IDENTIFIER  RSASSA-PSS (1.2.840.113549.1.1.10)
   000d :   SEQUENCE
   000f :     CONTEXT 0
   0011 :       SEQUENCE
   0013 :         OBJECT IDENTIFIER  id-sha256 (2.16.840.1.101.3.4.2.1)
   001e :         NULL
   0020 :     CONTEXT 1
   0022 :       SEQUENCE
|  0024 :         OBJECT IDENTIFIER  id-mgf1 (1.2.840.113549.1.1.8)
   002f :         SEQUENCE
   0031 :           OBJECT IDENTIFIER id-sha256 (2.16.840.1.101.3.4.2.1)
   003c :           NULL
   003e :     CONTEXT 2
   0040 :       INTEGER   0x20 (6 bits)

   Name = RSASSA-PSS with sha-256, oid = 1.2.840.113549.1.1.10
|  Length = 67
   0000: 3046 0609 2a86 4886 f70d 0101 0a30 39a0
   0010: 0f30 0d06 0960 8648 0165 0304 0201 0500
   0020: a11c 301a 0609 2a86 4886 f70d 0101 0830
   0030: 0d06 0960 8648 0165 0304 0201 0500 a203
|  0040: 0201 20

Notes:

1. The maskGenAlgorithm is in fact not SHA-256 (2.16.840.1.101.3.4.2.1), but MGF1 (1.2.840.113549.1.1.8) based on SHA-256 (2.16.840.1.101.3.4.2.1).

2. Section 3 requires the use of DER:
The ASN.1 used here is the same ASN.1 used in the AlgorithmIdentifier of PKIX (see Section 4.1.1.2 of [RFC5280]), encoded using distinguished encoding rules (DER) [CCITT.X690.2002].
--VERIFIER NOTES--
Per Tero Kivinen:

The id-mgf1 oid is there in the example, the tool I used didn't know
the name for it thus it just printed out the oid. As this does not
affect the binary object at all there is no problem in here.

> 2. Section 3 requires the use of DER:
> The ASN.1 used here is the same ASN.1 used in the
> AlgorithmIdentifier of PKIX (see Section 4.1.1.2 of [RFC5280]),
> encoded using distinguished encoding rules (DER) [CCITT.X690.2002].

Yes, but RFC4055 says that:

trailerField

The trailerField field is an integer. It provides
compatibility with IEEE Std 1363a-2004 [P1363A]. The value
MUST be 1, which represents the trailer field with hexadecimal
value 0xBC. Other trailer fields, including the trailer field
composed of HashID concatenated with 0xCC that is specified in
IEEE Std 1363a, are not supported. Implementations that
perform signature generation MUST omit the trailerField field,
indicating that the default trailer field value was used.
Implementations that perform signature validation MUST
recognize both a present trailerField field with value 1 and an
absent trailerField field.

I.e. you should recognize both formats. Yes, we could have another
example also showing the object value to used when generating these
and when omitting the default values (like we do have for SHA-1).

RFC 7432, "BGP MPLS-Based Ethernet VPN", February 2015

Note: This RFC has been updated by RFC 8584, RFC 9161

Source of RFC: l2vpn (rtg)

Errata ID: 5523
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Krishnamoorthy Arumugham
Date Reported: 2018-10-12
Rejected by: Deborah Brungard
Date Rejected: 2018-10-25

Section 7 says:

Clarifications to following sub-sections:
Section 7.1
Section 7.2
Section 7.5

It should say:

Section 7.1:
Add below text to the section 7.1 regarding the encoding 
of MPLS label:

"The value of the 20-bit MPLS label is encoded in the 
high-order 20 bits of the 3 bytes MPLS Label field."

Section 7.2:
Add below text to the section 7.2 regarding the encoding
of both the MPLS label fields:

"The value of the 20-bit MPLS label is encoded in the 
high-order 20 bits of the 3 bytes MPLS Label field for
both MPLS Label1 and MPLS Label2."

Section 7.5:
Add below text to the section 7.5 regarding the encoding
of ESI Label fields:

"The value of the 20-bit MPLS label is encoded in the 
high-order 20 bits of the ESI Label field."

Notes:

MPLS label is a 20-bit value and is stored in a 3 bytes field in a packet. The 20-bit MPLS label value is generally stored in higher order 20 bits of the 3 byte label field. The exact encoding to be followed for storing MPLS label values are not explicitly mentioned in the RFC 7432 under section 7.1, 7.2 and 7.5 for different types of EVPN routes. This lead to ambiguity in different implementations. Hence a clarification is required.
--VERIFIER NOTES--
The ESI label is required to be a "valid MPLS label value", there is no reason to interpret that it should be different from Label 1 and Label 2. There is nothing technically wrong with what is currently in the RFC.

Errata ID: 5746
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Yang Huang
Date Reported: 2019-06-05
Rejected by: Martin Vigoureux
Date Rejected: 2019-06-17

Section 11.2 says:

11.2.  P-Tunnel Identification
"...+ If the PE that originates the advertisement uses ingress 
replication for the P-tunnel for EVPN, the route MUST include the
PMSI Tunnel attribute with the Tunnel Type set to Ingress
Replication and the Tunnel Identifier set to a routable address of
the PE."

It should say:

a routable address of the PE is not so strict. And does this mean 
we use the Tunnel Identifier to construct P2P tunnel for ingress 
replication, or we use the Originating Router's IP Address in the 
IMET route key, or they are equivalent meaning?
This may cause interact problems when it implements differently. 
Could you clarify this? Thanks.

Notes:

--VERIFIER NOTES--
Errata is not the place to ask questions for clarifications

RFC 7489, "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", March 2015

Note: This RFC has been updated by RFC 8553, RFC 8616

Source of RFC: INDEPENDENT

Errata ID: 4907
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Don
Date Reported: 2017-01-16
Rejected by: Nevil Brownlee
Date Rejected: 2017-07-31

Section B.1.1. says:

   Example 3: SPF not in alignment:

        MAIL FROM: <sender@example.net>

        From: sender@child.example.com
        Date: Fri, Feb 15 2002 16:54:30 -0800
        To: receiver@example.org
        Subject: here's a sample

   In this case, the RFC5321.MailFrom parameter includes a DNS domain
   that is neither the same as nor a parent of the RFC5322.From domain.
   Thus, the identifiers are not in alignment.

It should say:

   Example 3: SPF not in alignment:

        MAIL FROM: <sender@example.net>

        From: sender@child.example.com
        Date: Fri, Feb 15 2002 16:54:30 -0800
        To: receiver@example.org
        Subject: here's a sample

   In this case, the RFC5322.From parameter includes a DNS domain
   that is neither the same as nor a parent of the RFC5321.MailFrom
   domain. Thus, the identifiers are not in alignment.

Notes:

Obviously, in the example MailFrom domain IS a parent of From domain.
--VERIFIER NOTES--
example.NET is not a parent of child.example.COM

Further, the explanatory text makes that clear.

Errata ID: 5370
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Cris van Pelt
Date Reported: 2018-05-28
Rejected by: Eliot Lear (ISE)
Date Rejected: 2022-08-21

Section 7.2.1.1 says:

   The extension MUST be "xml" for a plain XML file, or "xml.gz" for an
   XML file compressed using GZIP.

   "unique-id" allows an optional unique ID generated by the Mail
   Receiver to distinguish among multiple reports generated
   simultaneously by different sources within the same Domain Owner.

   For example, this is a possible filename for the gzip file of a
   report to the Domain Owner "example.com" from the Mail Receiver
   "mail.receiver.example":

     mail.receiver.example!example.com!1013662812!1013749130.gz

It should say:

   The extension MUST be "xml" for a plain XML file, or "xml.gz" for an
   XML file compressed using GZIP.

   "unique-id" allows an optional unique ID generated by the Mail
   Receiver to distinguish among multiple reports generated
   simultaneously by different sources within the same Domain Owner.

   For example, this is a possible filename for the gzip file of a
   report to the Domain Owner "example.com" from the Mail Receiver
   "mail.receiver.example":

     mail.receiver.example!example.com!1013662812!1013749130.xml.gz

Notes:

The example filename uses an invalid extension (not one of "xml", "xml.gz").
--VERIFIER NOTES--
Thank you for your report. This is a duplicate of another erratum: 5365.

Errata ID: 5552
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Borislav Petrov
Date Reported: 2018-11-09
Rejected by: Eliot Lear (ISE)
Date Rejected: 2022-09-30

Section 10.3. says:

Everything about it..

Notes:

DMARC relies on inspecting header information. This section suggestion is not allowed by rfc5321 and contradicts it:

...a relay SMTP has no need to inspect or
act upon the header section or body of the message data and MUST NOT
do so except to add its own "Received:" header field..

So the correct behaviour shoud be only the second option - 2xy and decide what to do after that being silent or not.
--VERIFIER NOTES--
The reporter has quoted from the wrong section of RFC 5321, and that that section does not discuss Message Submission Servers.

RFC 7498, "Problem Statement for Service Function Chaining", April 2015

Source of RFC: sfc (rtg)

Errata ID: 5336
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Boyuan Yan
Date Reported: 2018-04-26
Rejected by: Martin Vigoureux
Date Rejected: 2018-05-22

Section 3.3 says:

   The SFC encapsulation also carries data-plane metadata that provides
   the ability to exchange information between logical classification
   points and service functions (and vice versa) and between service
   functions.  Metadata is not used as forwarding information to deliver
   packets along the service overlay.

It should say:

   The SFC encapsulation also carries data-plane metadata that provides
   the ability to exchange information between logical classification
   points and service functions (and vice versa) and between service
   functions.  Metadata is used as forwarding information to deliver
   packets along the service overlay.

Notes:

Error occurs in the last sentence of 2nd paragraph in Section 3.3. Metadata should be used as forwarding information to deliver packets along the service overlay.
--VERIFIER NOTES--
SFC Path identification is not part of the metadata.

RFC 7515, "JSON Web Signature (JWS)", May 2015

Source of RFC: jose (sec)

Errata ID: 6118
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jason Heiss
Date Reported: 2020-04-22
Rejected by: Benjamin Kaduk
Date Rejected: 2020-04-25

Section 2 says:

(as permitted by Section 3.2)

Notes:

This appears to be a reference to section 3.2 of RFC 4648, but because it is somewhat ambiguous the HTML and PDF versions of the RFC link to section 3.2 of this RFC instead.
--VERIFIER NOTES--
Errata reports are for the authoritative versions hosted on rfc-editor.org, which for this document is the plain text version. As such, issues introduced by the "htmlization" process do not qualify.

RFC 7519, "JSON Web Token (JWT)", May 2015

Note: This RFC has been updated by RFC 7797, RFC 8725

Source of RFC: oauth (sec)

Errata ID: 5648
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Andy Delcambre
Date Reported: 2019-03-08
Rejected by: Roman Danyliw
Date Rejected: 2024-01-12

Section 1 says:

JSON Web Token (JWT) is a compact claims representation format
   intended for space constrained environments such as HTTP
   Authorization headers and URI query parameters.  JWTs encode claims
   to be transmitted as a JSON [RFC7159] object that is used as the
   payload of a JSON Web Signature (JWS) [JWS] structure or as the
   plaintext of a JSON Web Encryption (JWE) [JWE] structure, enabling
   the claims to be digitally signed or integrity protected with a
   Message Authentication Code (MAC) and/or encrypted.  JWTs are always
   represented using the JWS Compact Serialization or the JWE Compact
   Serialization.

   The suggested pronunciation of JWT is the same as the English word
   "jot".

It should say:

JSON Web Token (JWT) is a compact claims representation format
   intended for space constrained environments such as HTTP
   Authorization headers and URI query parameters.  JWTs encode claims
   to be transmitted as a JSON [RFC7159] object that is used as the
   payload of a JSON Web Signature (JWS) [JWS] structure or as the
   plaintext of a JSON Web Encryption (JWE) [JWE] structure, enabling
   the claims to be digitally signed or integrity protected with a
   Message Authentication Code (MAC) and/or encrypted.  JWTs are always
   represented using the JWS Compact Serialization or the JWE Compact
   Serialization.

Notes:

The suggested pronunciation is strange and confusing. It makes it hard to onboard new people verbally and always requires an explanation of the pronunciation. The standard already has a perfectly reasonable initialism of JWT that clearly refers to JSON Web Tokens. It is jarring to suggest a pronunciation that does not map to the letters of the spec, and in my experience often leads to confusion when used.
--VERIFIER NOTES--
This guidance was produced with the consensus of the WG. Per https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/, "Errata are items that were errors at the time the document was published"

Errata ID: 6622
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Padmanarayanan SR
Date Reported: 2021-06-25
Rejected by: Benjamin Kaduk
Date Rejected: 2021-07-04

Section 11 says:

All the security considerations in the JWS specification also apply
   to JWT, as do the JWE security considerations when encryption is
   employed.  In particular, Sections <a href="#section-10.12">10.12</a>

It should say:

All the security considerations in the JWS specification also apply
   to JWT, as do the JWE security considerations when encryption is
   employed.  In particular, Sections <a href="/doc/html/rfc7515#section-10.12">10.12</a>

Notes:

The link appears to be broken. It is intended to point to rfc7515#section-10.12 whereas it is pointing to the non-existent section of the same document.
--VERIFIER NOTES--
The "text" publication format (the only official format for RFCs prior to 8650) does not include HTML links, so the "original text" section of this report does not match the version of the RFC that this tool is used for. Accordingly, the submission has to be rejected as invalid.

RFC 7525, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", May 2015

Note: This RFC has been obsoleted by RFC 9325

Note: This RFC has been updated by RFC 8996

Source of RFC: uta (sec)

Errata ID: 4360
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin Rex
Date Reported: 2015-05-08
Rejected by: Barry Leiba
Date Rejected: 2015-05-28

Section 6.1 says:

6.1. Host Name Validation

   Application authors should take note that some TLS implementations do
   not validate host names.  If the TLS implementation they are using
   does not validate host names, authors might need to write their own
   validation code or consider using a different TLS implementation.

It should say:

6.1. Host Name Validation

   Application authors should take note that the TLS protocol explicitly
   defers checking of names and attributes of end-entity certificates
   to applications, see last sentence of RFC5246 , Section 1 (TLSv1.2).

   Some TLS implementations may offer a convenience function to perform
   a server endpoint identification according to RFC 2818, Section 3
   (HTTP over TLS).  For TLS implementations without such a convenience
   function, and for applications with different server identification
   schemes, application implementors may have to write the necessary
   code themselves.

Notes:

TLSv1.0 (rfc2246), TLSv1.1 (rfc4346) and TLSv1.2 (rfc5246) are quite
clear in that the original text is misleading on the actual properties
provided by a TLS implementation itself:

https://tools.ietf.org/html/rfc5246#page-5

how to interpret the authentication certificates
exchanged are left to the judgment of the designers and implementors
of protocols that run on top of TLS.
--VERIFIER NOTES--
The text is not incorrect as it stands, and, while this suggested change would have been good input during document development, it's not an erratum.

RFC 7540, "Hypertext Transfer Protocol Version 2 (HTTP/2)", May 2015

Note: This RFC has been obsoleted by RFC 9113

Note: This RFC has been updated by RFC 8740

Source of RFC: httpbis (wit)

Errata ID: 4645
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Jessie Liu
Date Reported: 2016-03-29
Rejected by: Barry Leiba
Date Rejected: 2016-03-29

Section 5.1 says:

idle:
      All streams start in the "idle" state.

      The following transitions are valid from this state:

      *  Sending or receiving a HEADERS frame causes the stream to
         become "open".  The stream identifier is selected as described
         in Section 5.1.1.  The same HEADERS frame can also cause a
         stream to immediately become "half-closed".

      *  Sending a PUSH_PROMISE frame on another stream reserves the
         idle stream that is identified for later use.  The stream state
         for the reserved stream transitions to "reserved (local)".

      *  Receiving a PUSH_PROMISE frame on another stream reserves an
         idle stream that is identified for later use.  The stream state
         for the reserved stream transitions to "reserved (remote)".

      *  Note that the PUSH_PROMISE frame is not sent on the idle stream
         but references the newly reserved stream in the Promised Stream
         ID field.

      Receiving any frame other than HEADERS or PRIORITY on a stream in
      this state MUST be treated as a connection error (Section 5.4.1)
      of type PROTOCOL_ERROR.

It should say:

idle:
      All streams start in the "idle" state.

      The following transitions are valid from this state:

      *  Sending or receiving a HEADERS frame causes the stream to
         become "open".  The stream identifier is selected as described
         in Section 5.1.1.  The same HEADERS frame can also cause a
         stream to immediately become "half-closed".

      *  Sending a PUSH_PROMISE frame on another stream reserves the
         idle stream that is identified for later use.  The stream state
         for the reserved stream transitions to "reserved (local)".

      *  Receiving a PUSH_PROMISE frame on another stream reserves an
         idle stream that is identified for later use.  The stream state
         for the reserved stream transitions to "reserved (remote)".

      *  Note that the PUSH_PROMISE frame is not sent on the idle stream
         but references the newly reserved stream in the Promised Stream
         ID field.

      Receiving any frame other than HEADERS, PUSH_PROMISE or 
      PRIORITY on a stream in this state MUST be treated as a 
      connection error (Section 5.4.1) of type PROTOCOL_ERROR.

Notes:

According to the description above and the state transformation in Figure 2, a stream in the 'idle' state could receive a PUSH_PROMISE frame.

While in the last statement of Original Text, receiving a PUSH_PROMISE on a stream in 'idle' state is a connection error.

Please fix this inconsistency problem.
--VERIFIER NOTES--
This is a duplicate of errata report #4535.

The report is incorrect: the text says "another stream" and has a note that explains this. The confusion that obviously exists should be considered in a future revision of the document.

Errata ID: 4663
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: D. Stussy
Date Reported: 2016-04-12
Rejected by: Alexey Melnikov
Date Rejected: 2017-02-23

Section 8 omits says:

[Note:  RFC 3875, section 4.1.16, defines the protocol version as:

HTTP-Version = "HTTP" "/" 1*digit "." 1*digit

Nothing in RFC 7540 redefines this.]

It should say:

Add paragraph at end of section 8 (before 8.1) - Clarification:

HTTP/2 preserves the format of the SERVER_PROTOCOL CGI variable,
both in the CGI interface and for any server logging purposes.  Where
a version string is necessary, it is "HTTP/2.0" as defined by RFC 3875.

Notes:

Compatibility is required with a prior published RFC, or a specific change superseding the prior RFC need be explicitly stated. This RFC states in its abstract:

"This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged"

RFC 7540, section 3.5's connection preface string containing "HTTP/2.0" implies that the RFC authors should have forseen this issue, and added a paragraph to section 8 to explicitly state no change in the CGI interface variable SERVER_PROTOCOL was desired. At least one implementation is using a version string of "HTTP/2", not "HTTP/2.0", because of how it is referred in this RFC. ("nghttp2.org" has incorrectly implemented this in its library routines.)
--VERIFIER NOTES--
Mark Nottingham: As discussed on HTTPBIS mailing list, this isn't an issue for the HTTP specification.

Errata ID: 5249
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Vasiliy Faronov
Date Reported: 2018-02-01
Rejected by: Alexey Melnikov
Date Rejected: 2018-09-04

Section 3.2.1 says:

     HTTP2-Settings    = token68

It should say:

     HTTP2-Settings    = [ token68 ]

Notes:

An initial SETTINGS frame is explicitly allowed by Section 3.5 to be empty. The payload of an empty SETTINGS frame is an empty sequence of octets, whose base64url encoding is an empty string. Thus, the HTTP2-Settings header field ought to permit an empty string as value. But the ABNF for "token68" does not match an empty string.
--VERIFIER NOTES--
Martin Thomson wrote:

The observation is correct. However, I'm not sure that this is the
solution I would choose. I'm not sure, but I think that an empty
header field would cause problems. Maybe the right conclusion to draw
here is that you have to include at least one setting if you use this
header field.

Alexey:

Agreement in the WG to reject the erratum as proposed, but a better fix might be proposed separately.

Errata ID: 4871
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Martin Thomson
Date Reported: 2016-11-30
Rejected by: Alexey Melnikov
Date Rejected: 2017-02-23

Section 5.3.4 says:

For example, assume streams A and B share a parent, and streams C
and D both depend on stream A. Prior to the removal of stream A,
if streams A and D are unable to proceed, then stream C receives
all the resources dedicated to stream A. If stream A is removed
from the tree, the weight of stream A is divided between streams
C and D. If stream D is still unable to proceed, this results in
stream C receiving a reduced proportion of resources. For equal
starting weights, C receives one third, rather than one half, of
available resources.

It should say:

For example, assume streams A and B share a parent, and streams C
and D both depend on stream A. When A is complete, streams C and
D receive all the resources that would be allocated to stream
A. If stream D is unable to proceed, stream C shares resources
with stream B. Assuming equal starting weights on all streams,
this means that streams B and C receive an equal share.  However,
if stream A is removed from the tree, the weight of stream A is
divided between streams C and D. With stream A removed and stream
D unable to proceed, stream C receives a reduced proportion of
resources. For equal starting weights, C receives one third,
rather than one half, of available resources.

Notes:

The example was incorrect. Dependent streams do not receive resources if their parent is blocked; they only receive resources once the parent is complete.

Note that I didn't correct the common misunderstanding regarding the third here. That might be further improved by doing the math. That is:

Before removal: A=N (C=N, D=N), B=N;
After removal: B=N, C=N/2, D=N/2;
Therefore viable streams are B=N and C=N/2 meaning a total pool of 3N/2. The resource proportion allocated to C is therefore (N/2)/(3N/2)=1/3.

But that would probably need an entire section for the example, rather than a single paragraph.
--VERIFIER NOTES--
See HTTPBIS mailing list discussion.

RFC 7543, "Covering Prefixes Outbound Route Filter for BGP-4", May 2015

Source of RFC: bess (rtg)

Errata ID: 4402
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Ron Bonica
Date Reported: 2015-06-26
Rejected by: Alvaro Retana
Date Rejected: 2016-04-15

Section 7 says:

    +------------------------------------------------+---------------+
    | Registry                                       | Code Point    |
    +------------------------------------------------+---------------+
    | BGP Outbound Route Filtering (ORF) Types       | CP-ORF (65)   |
    | Transitive Opaque Extended Community Sub-Types | CP-ORF (0x03) |
    +------------------------------------------------+---------------+

It should say:

    +------------------------------------------------+---------------+
    | Registry                                       | Code Point    |
    +------------------------------------------------+---------------+
    | BGP Outbound Route Filtering (ORF) Types       | CP-ORF (65)   |
    | Transitive Opaque Extended Community Sub-Types | CP-ORF (0x03) |
    | Capability Codes                               | CP-ORF (72)   |
    +------------------------------------------------+---------------+

Notes:

In the original text, we forgot to mention the value of the BGP capability code.
--VERIFIER NOTES--
RFC 5291 describes The Outbound Route Filter (ORF) Capability for BGP. According to RFC 5291, when two BGP speakers initiate a session between one another and they intend to exchange ORFs of any type, they must advertise the ORF capability. The ORF capability is registered with a value of 3 in the IANA BGP Capability Code Registry. The ORF capability also includes a list of ORF types that the BGP speaker can send and/or receive. IANA also maintains a BGP Outbound Route Filtering (ORF) Types registry.

RFC 7543 describes a new ORF type, called the Covering Prefix ORF (CP-ORF). RFC 7543 should conform to generic ORF procedures defined in RFC 5291. Specifically, when two BGP speakers initiate a session between one another and they intend to exchange CP-ORFs, they must advertise the ORF capability (value 3). The ORF capability must include CP-ORF (value 65) in the ORF type list.

RFC 7607, "Codification of AS 0 Processing", August 2015

Source of RFC: idr (rtg)

Errata ID: 4455
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2015-08-26
Rejected by: Alvaro Retana
Date Rejected: 2015-08-26

Section 5.1 says:

N/A

It should say:

N/A

Notes:

The normative reference to RFC 7606 is dangling (7606 has not been published).

===

(Alvaro Retana) rfc7606 is a valid reference.
--VERIFIER NOTES--
rfc7606 is a valid reference.

RFC 7633, "X.509v3 Transport Layer Security (TLS) Feature Extension", October 2015

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 4571
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Anonymous
Date Reported: 2015-12-28
Rejected by: Stephen Farrell
Date Rejected: 2015-12-28

Section 2.2 says:

2.2.  TLS Feature, X.509 Extension

   In order to avoid the confusion that would occur in attempting to
   specify an X.509 extension describing the use of TLS extensions, in
   this document the term "extension" is reserved to refer to X.509v3
   extensions and the term "TLS feature extension" is used to refer to
   what the TLS specification [RFC5246] refers to as an "extension".

It should say:

2.2.  TLS Feature, X.509 Extension

   In order to avoid the confusion that would occur in attempting to
   specify an X.509 extension describing the use of TLS extensions, in
   this document the term "TLS feature extension" is used to refer to
   the X.509 extension specified in this document.

Notes:

(There is no platonically correct version of the text, as the problem is with the entire RFC.)

Virtually every instance of the term "TLS feature extension" in the RFC refers to the X.509 extension. The sole instance of it referring to TLS extensions is the first paragraph of section 3.

Of the uses of the simple term "extension," the first two paragraphs of Section 3 contain the only three uses consistent with 2.2. The other three ("choose to have a certificate issued with this extension","critical extensions MUST reject the certificate","key usage extension") refer to X.509 extensions.
--VERIFIER NOTES--
Issue was discussed during AD eval and IESG eval so this is not an error.
An anonymously submitted erratum is also odd.

RFC 7643, "System for Cross-domain Identity Management: Core Schema", September 2015

Source of RFC: scim (sec)

Errata ID: 6438
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Andrew Webb
Date Reported: 2021-02-23
Rejected by: Barry Leiba
Date Rejected: 2021-02-23

Section 3.1. says:

     version  The version of the resource being returned.  This value
         must be the same as the entity-tag (ETag) HTTP response header
         (see Sections 2.1 and 2.3 of [RFC7232]).  This attribute has
         "caseExact" as "true".  Service provider support for this
         attribute is optional and subject to the service provider's
         support for versioning (see Section 3.14 of [RFC7644]).  If a
         service provider provides "version" (entity-tag) for a
         representation and the generation of that entity-tag does not
         satisfy all of the characteristics of a strong validator (see
         Section 2.1 of [RFC7232]), then the origin server MUST mark the
         "version" (entity-tag) as weak by prefixing its opaque value
         with "W/" (case sensitive).

It should say:

     version  The version of the resource being returned.  This value
         must be the same as the entity-tag (ETag) HTTP response header
         (see Sections 2.1 and 2.3 of [RFC7232]).  This attribute has
         "caseExact" as "true".  Service provider support for this
         attribute is optional and subject to the service provider's
         support for versioning (see Section 3.14 of [RFC7644]).  If a
         service provider provides "version" (entity-tag) for a
         representation and the generation of that entity-tag does not
         satisfy all of the characteristics of a strong validator (see
         Section 2.1 of [RFC7232]), then the origin server MUST mark the
         "version" (entity-tag) as weak by prefixing its opaque value
         with "W/" (case sensitive).

Notes:

In the original text, the hyperlinks applied to "2.1" and "2.3" incorrectly link to those sections in RFC 7643, whereas they should link to those sections in RFC 7232.
--VERIFIER NOTES--
Errata reports are for errors in the canonical version, which, for these RFCs, are the plain text versions. HTML renderings that include heuristically-generated links aren't covered by the errata system.

RFC 7665, "Service Function Chaining (SFC) Architecture", October 2015

Source of RFC: sfc (rtg)

Errata ID: 4974
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Phaneendra Manda
Date Reported: 2017-03-21
Rejected by: Alia Atlas
Date Rejected: 2017-03-21

Section 1.4 says:

One or more service functions can be involved in the delivery of
added-value services.  A non-exhaustive list of abstract service
functions includes: firewalls, WAN and application acceleration,
Deep Packet Inspection (DPI), Lawful Intercept (LI), server load
balancing, NAT44 [RFC3022], NAT64 [RFC6146], NPTv6 [RFC6296],
HOST_ID injection, HTTP Header Enrichment functions, and TCP
optimizer.

It should say:

One or more service functions can be involved in the delivery of
added-value services.  A non-exhaustive list of abstract service
functions includes: firewalls, WAN and application acceleration,
Deep Packet Inspection (DPI), Lawful Intercept (LI), server load
balancing, NAT44 [RFC3022], NAT64 [RFC6146], NPTv6 [RFC6296],
HOST_ID injection, HTTP Header Enrichment functions, TCP
optimizer, Parental control etc.

Notes:

Parental control can be added in the non-exhaustive list of abstract service functions. Also this list cannot be fixed, so etc an be added at the end of the list.
--VERIFIER NOTES--
The list specifically says that it is non-exhaustive. Adding more examples and an etc is not needed.

RFC 7719, "DNS Terminology", December 2015

Note: This RFC has been obsoleted by RFC 8499

Source of RFC: dnsop (ops)

Errata ID: 4611
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2016-02-02
Rejected by: Joel Jaeggli
Date Rejected: 2017-03-29

Section 2 says:

CNAME:  "It is traditional to refer to the owner of a CNAME record as
   'a CNAME'.  This is unfortunate, as 'CNAME' is an abbreviation of
   'canonical name', and the owner of a CNAME record is most certainly
   not a canonical name."  (Quoted from [RFC2181], Section 10.1.1)

It should say:

CNAME:  "It is traditional to refer to the label of a CNAME record as
   'a CNAME'.  This is unfortunate, as 'CNAME' is an abbreviation of
   'canonical name', and the label of a CNAME record is an alias, not
   a canonical name."  (Quoted from [RFC2181], Section 10.1.1)

Notes:

Incorrect quote from RFC 2181.
--VERIFIER NOTES--
Not a technical erratum.

is corrected already in

https://tools.ietf.org/html/draft-ietf-dnsop-terminology-bis-05

which should be examined for consistency

Errata ID: 5542
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Scott Corcoran
Date Reported: 2018-11-03
Rejected by: Warren Kumari (Ops AD)
Date Rejected: 2019-01-09

Section 1 says:

https://specs.webplatform.org/url/webspecs/develop

It should say:

https://webplatform.github.io/

Notes:

The RFC should be edited to reflect the intended content. Unfortunately, although I am technical, I do not have knowledge of the original. There are also other dead references.... and a reference to a "dead project" which is still living, here, but with little reference to DNS or domains.

RFC Editor note: Errata are typically not used to correct URLs that were functioning at the time of publication. For this case, please see RFC 8499 (which obsoleted RFC 7719) for the current information.
--VERIFIER NOTES--
Thank you for submitting this. RFC 7719 has been updated by RFC8499 (published after your errata was submitted), which doesn't contain the reference.

Thanks again
W

RFC 7725, "An HTTP Status Code to Report Legal Obstacles", February 2016

Source of RFC: httpbis (wit)

Errata ID: 5512
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Curt Self
Date Reported: 2018-10-02
Rejected by: Francesca Palombini
Date Rejected: 2022-11-09

Section 3 says:

Note that in many cases clients can still access the denied resource
by using technical countermeasures such as a VPN or the Tor network.

It should say:

(remove the sentence)

Notes:

I understand that the status code itself is kind of a joke (Fahrenheit 451), but the sentence above seems to have no place in a technical document. It provides no insight into use cases for either a client or implementing software.
--VERIFIER NOTES--
This statement went through IETF and IESG review as part of the original document. Removing it would be a material change to the contents of the document without first gaining consensus from the appropriate parties. The errata process cannot be used to make this kind of material change.

Errata ID: 5969
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Robert Rothenberg
Date Reported: 2020-01-29
Rejected by: Barry Leiba
Date Rejected: 2020-01-29

Section 3 says:

This status code indicates that the server is denying access to the
resource as a consequence of a legal demand.

It should say:

This status code indicates that the server is denying access to the
resource as a consequence of a legal demand or contractual restrictions to content.

Notes:

There are many cases where documents are not available in a part of the world because of contractual obligations, rather than legal ones.

For example, a television network may only have the rights to stream a video in a specific country. This is a legal requirement to comply with a contract. Visitors from other countries should receive an HTTP 451.
--VERIFIER NOTES--
This is not an erratum: the document says what it was intended to say at the time it was written.

RFC 7748, "Elliptic Curves for Security", January 2016

Source of RFC: IRTF

Errata ID: 5568
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Juan Alcasabas
Date Reported: 2018-12-07
Rejected by: Stanislav Smyshlyaev
Date Rejected: 2020-12-15

Section 5.2 says:

   Input u-coordinate:
     e5210f12786811d3f4b7959d0538ae2c31dbe7106fc03c3efc4cd549c715a493

It should say:

   Input u-coordinate:
     e5210f12786811d3f4b7959d0538ae2c31dbe7106fc03c3efc4cd549c715a413

Notes:

In the X25519 2nd test vector the last byte of input u-coordinate should be 13 instead of 93. This will fix inconsistency between u-coordinate, its base10 representation and the output u-coordinate.
--VERIFIER NOTES--
A change of one bit of the input u-coordinate in the hexadecimal representation is proposed (to make it "consistent" with the base 10 representation). However, implementations of x25519 should "mask" that bit after taking a u-coordinate as an input - therefore, the existing text of RFC does not have any errors there.

Errata ID: 5651
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Pierre Laurent
Date Reported: 2019-03-11
Rejected by: Stanislav Smyshlyaev
Date Rejected: 2020-12-15

Section 5 says:

z_2 = E * (AA + a24 * E)

It should say:

z_2 = E * (BB + a24 * E)

Notes:

When BB is used, the point multiplication of the second test vector

P = (0x13a415c749d54cfc3e3cc06f10e7db312cae38059d95b7f4d3116878120f21e5, 0x1)

by scalar k
0x4dba18799e16a42cd401eae021641bc1f56a7d959126d25a3c67b4d1d4e96648

gives the expected point
[k]P = (0x5779ac7a64f7f8e652a19f79685a598bf873b8b45ce4ad7a7d90e87694decb95, 0x1)

The implementation based on AA gives the unexpected point
[k]P = (0x3884d5c22af664f822cb3dd728b03c9fac1e1d78c772a74f05546566bd7bed9c, 1)
--VERIFIER NOTES--
It is proposed to modify the algorithm description for calculation of z_2. However, after checking the original algorithm independently, it was confirmed that the expected numbers are obtained. Therefore, the existing text of RFC does not have any errors here.

RFC 7761, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", March 2016

Note: This RFC has been updated by RFC 8736, RFC 9436

Source of RFC: pim (rtg)

Errata ID: 5343
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Frank Hua Li
Date Reported: 2018-04-28
Rejected by: Alvaro Retana
Date Rejected: 2018-05-24

Section 4.11 says:

4.11 Page 128: 
The normal keepalive period for the KAT(S,G) defaults to 210 seconds.
However, at the RP, the keepalive period must be at least the
Register_Suppression_Time, or the RP may time out the (S,G) state
before the next Null-Register arrives. Thus, the KAT(S,G) is set to
max(Keepalive_Period, RP_Keepalive_Period) when a Register-Stop
is sent.

It should say:

If the pseudo code in 4.4.2 page 43 is correct, the text should be:
The normal keepalive period for the KAT(S,G) defaults to 210 seconds.
However, at the RP, the keepalive period must be at least the
Register_Suppression_Time, or the RP may time out the (S,G) state
before the next Null-Register arrives. Thus, the KAT(S,G) is set to
RP_Keepalive_Period when a Register-Stop
is sent.

Notes:

4.11 Page 128: 4.11 Page 128:
The normal keepalive period for the KAT(S,G) defaults to 210 seconds.
However, at the RP, the keepalive period must be at least the
Register_Suppression_Time, or the RP may time out the (S,G) state
before the next Null-Register arrives. Thus, the KAT(S,G) is set to
max(Keepalive_Period, RP_Keepalive_Period) when a Register-Stop
is sent.

Frank's Note: This statement contradicts with pseudo code in 4.4.2 page 43.
In page 43, the KeepaliveTimer(S,G) is set to
RP_Keepalive_Period instead of max(Keepalive_Period, RP_Keepalive_Period).
quote from page 43:
if ( SPTbit(S,G) OR SwitchToSptDesired(S,G) ) {
if ( sentRegisterStop == TRUE ) {
set KeepaliveTimer(S,G) to RP_Keepalive_Period;
} else {
set KeepaliveTimer(S,G) to Keepalive_Period;
}
}
--VERIFIER NOTES--
See Errata ID 5342.

RFC 7807, "Problem Details for HTTP APIs", March 2016

Note: This RFC has been obsoleted by RFC 9457

Source of RFC: appsawg (art)

Errata ID: 7256
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ahmed Hussein
Date Reported: 2022-11-23
Rejected by: Francesca Palombini
Date Rejected: 2022-11-28

Section 3.2 says:

Note that because extensions are effectively put into a namespace by
the problem type, it is not possible to define new "standard" members
without defining a new media type.

It should say:

Note that because extensions are effectively put into a namespace by
the problem type, it is not possible to define new "standard" members
without defining a new problem type.

Notes:

Typo at the end of the sentence, defining extension members require defining new problem types not media types.
--VERIFIER NOTES--
In rejecting this Errata report I note that the reported error is not a typo, but a deliberate decision of the authors and working group.

RFC 7838, "HTTP Alternative Services", April 2016

Source of RFC: httpbis (wit)

Errata ID: 6481
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lucas Pardue
Date Reported: 2021-03-13
Rejected by: Francesca Palombini
Date Rejected: 2021-03-15

Section 2.4 says:

   Furthermore, if the connection to the alternative service fails or is
   unresponsive, the client MAY fall back to using the origin or another
   alternative service.  Note, however, that this could be the basis of
   a downgrade attack, thus losing any enhanced security properties of
   the alternative service.

It should say:

 ¯\_(ツ)_/¯

Notes:

Alt-Svc fall back is described in section 2.4 and mentions security properties, so I was expecting to see something about fall back in the security considerations. This might be implicitly covered by Section 9.3 but it could potentially be made more clear.
--VERIFIER NOTES--
General clarifications and request for improvements to the RFC in a possible future update of the document should be proposed using channels other than the errata process, such as the WG mailing list.

RFC 7855, "Source Packet Routing in Networking (SPRING) Problem Statement and Requirements", May 2016

Source of RFC: spring (rtg)

Errata ID: 5384
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: James Bensley
Date Reported: 2018-06-08
Rejected by: Martin Vigoureux
Date Rejected: 2018-11-03

Section 3.3.1.1.1 says:

      C1k has a link to C2j iff k = j.

         The core nodes of a given region are directly connected.
         Inter-region links only connect core nodes of the same plane.

      {C1k has a link to C1j} iff {C2k has a link to C2j}.

It should say:

      C1k has a link to C2j if k = j.

         The core nodes of a given region are directly connected.
         Inter-region links only connect core nodes of the same plane.

      {C1k has a link to C1j} if {C2k has a link to C2j}.

Notes:

Does "iff" mean something special that is different to "if" or is this a typo? If the former, should it be called out in a glossary?
--VERIFIER NOTES--
"iff" means "if and only if"
This abreviation is part of the RFC Editor's well known ones.
Please see: https://www.rfc-editor.org/materials/abbrev.expansion.txt

RFC 7871, "Client Subnet in DNS Queries", May 2016

Source of RFC: dnsop (ops)

Errata ID: 4736
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Robert Edmonds
Date Reported: 2016-07-08
Rejected by: Joel Jaeggli
Date Rejected: 2017-03-29

Throughout the document, when it says:

the Internet Software Consortium

It should say:

Internet Systems Consortium

Notes:

ISC (no "the") was originally founded as Internet Software Consortium, Inc. in 1994 but it has been known as Internet Systems Consortium, Inc. since 2004.
--VERIFIER NOTES--
Internet Software Consortium occurs only in the acknowledgements and while incorrect now it is generally the perogative of the authors to include in this section what they see fit. were a future version to be updated it's acknowledgements would probably include the then current contributors not the previous ones.

RFC 7880, "Seamless Bidirectional Forwarding Detection (S-BFD)", July 2016

Source of RFC: bfd (rtg)

Errata ID: 5211
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Greg Mirsky
Date Reported: 2017-12-16
Rejected by: Alvaro Retana
Date Rejected: 2018-03-14

Section 6.1 says:

   o  bfd.SessionType: This is a new state variable that describes
      the type of a particular session.  Allowable values for S-BFD
      sessions are:

      *  SBFDInitiator - an S-BFD session on a network node that
         performs a continuity test to a target entity by sending S-BFD
         packets.

      *  SBFDReflector - an S-BFD session on a network node that listens
         for incoming S-BFD Control packets to local entities and
         generates response S-BFD Control packets.

   The bfd.SessionType variable MUST be initialized to the appropriate
   type when an S-BFD session is created.

It should say:

   o  bfd.SessionType: This is a new state variable that describes
      the type of a particular session.  Allowable values for S-BFD
      sessions are:

      *  SBFDNone - indicates that the BFD session is not of S-BFD type.

      *  SBFDInitiator - an S-BFD session on a network node that
         performs a continuity test to a target entity by sending S-BFD
         packets.

      *  SBFDReflector - an S-BFD session on a network node that listens
         for incoming S-BFD Control packets to local entities and
         generates response S-BFD Control packets.

   The bfd.SessionType variable MUST be set to SBFDNone when a BFD
   session other than S-BFD. The bfd.SessionType variable MUST be 
   initialized to the appropriate type when an S-BFD session is created.

Notes:

The original text leaves value of the new variable bfd.SessionType unspecified if the type of BFD session is other than S-BFD.
--VERIFIER NOTES--
This report goes beyond pointing out an error in the document. If the changes are to me made (or discussed beyond the thread related to this report), it should be done through the normal WG channels.

https://mailarchive.ietf.org/arch/msg/rtg-bfd/dI5Y2YXBG3kACEjX5vIZgSJHVw4

RFC 7915, "IP/ICMP Translation Algorithm", June 2016

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: ops

Errata ID: 4818
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Wrong IPv4-to-IPv6 translations
Date Reported: 2016-10-04
Rejected by: Benoit Claise
Date Rejected: 2017-03-10

Section Appendix A says:

Example contains following IPv4-to-IPv6 translations:
   192.0.2.33   -> 2001:db8:1c0:2:21::
   198.51.100.2 -> 2001:db8:1c6:3364:2::

It should say:

The correct translations are:
   192.0.2.33   -> 2001:db8:1c0:2:2100::
   198.51.100.2 -> 2001:db8:1c6:3364:200::

Notes:

--VERIFIER NOTES--

This errata should be rejected. RFC7915 is correct as published.

When using 40-bit translation prefixes (as RFC7915 appendix A does),
bits 64 thru 71 is zero while the eight least significant bits of the
IPv4 address is stored in bits 72 thru 79 of the resulting
IPv4-embedded IPv6 address.

The errata appears to based on the false assumption that the entire 32
bits of the IPv4 address should be stored in bits 40-71 of the
resulting IPv4-embedded IPv6 address.

Relevant quotes from RFC6052 section 2.2:

> +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
> |PL| 0-------------32--40--48--56--64--72--80--88--96--104---------|
> +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
> |40| prefix |v4(24) | u |(8)| suffix |
> +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

> The IPv4 address is encoded following the prefix, most significant
> bits first. Depending of the prefix length, the 4 octets of the
> address may be separated by the reserved octet "u", whose 8 bits MUST
> be set to zero. In particular:

> o When the prefix is 40 bits long, 24 bits of the IPv4 address are
> encoded in positions 40 to 63, with the remaining 8 bits in
> position 72 to 79.

RFC 7935, "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure", August 2016

Note: This RFC has been updated by RFC 8208, RFC 8608

Source of RFC: sidr (rtg)

Errata ID: 5737
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alberto Leiva Popper
Date Reported: 2019-05-24
Rejected by: Alvaro Retana
Date Rejected: 2019-07-18

Section 3.1 says:

algorithm (which is an AlgorithmIdentifier type):
   The object identifier for RSA PKCS #1 v1.5 with SHA-256 MUST be
   used in the algorithm field, as specified in Section 5 of
   [RFC4055].  The value for the associated parameters from that
   clause MUST also be used for the parameters field.

It should say:

algorithm (which is an AlgorithmIdentifier type):
   The object identifier for RSA (rsaEncryption) MUST be used for the
   algorithm field, as specified in Section 3.2 of [RFC3370]. The value
   for the associated parameters from that clause MUST also be used for
   the parameters field.

Notes:

The field described in the paragraph belongs to a public key. The way I understand it, particularly due to the inclusion of a digest, "RSA PKCS #1 v1.5 with SHA-256" (sha256WithRSAEncryption) is not really a public key algorithm identifier; it's a signature algorithm identifier.

(Courtesy of Russ Housley) rsaEncryption also allows the public key to be used with PKCS#1 v1.5, RSASSA-PSS, and RSAES-OAEP.

All existing RPKI readers and writers that I've seen, as well as the global RPKI repository certificates themselves, currently use rsaEncryption as the public key algorithm of subjectPublicKeyInfo. Therefore, this change should also reflect existing practice.
--VERIFIER NOTES--
Any changes to normative statements require WG consensus. In this case, rfc7935 has been updated twice. Discussion should happen in the sidrops WG.

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.

RFC 7958, "DNSSEC Trust Anchor Publication for the Root Zone", August 2016

Source of RFC: INDEPENDENT

Errata ID: 5910
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: John Dickinson
Date Reported: 2019-11-15
Rejected by: Adrian Farrel
Date Rejected: 2019-11-22

Section 2.1.2 says:

The validFrom and validUntil attributes in the KeyDigest element
   specify the range of times that the KeyDigest element can be used as
   a trust anchor.  Note that the KeyDigest element is optional; if it
   is not given, the trust anchor can be used until a KeyDigest element
   covering the same DNSKEY record, but having a validUntil attribute,
   is trusted by the relying party.  Relying parties SHOULD NOT use a
   KeyDigest outside of the time range given in the validFrom and
   validUntil attributes.

It should say:

The validFrom and validUntil attributes in the KeyDigest element
   specify the range of times that the KeyDigest element can be used as
   a trust anchor.  Note that the validUntil element is optional; if it
   is not given, the trust anchor can be used until a KeyDigest element
   covering the same DNSKEY record, but having a validUntil attribute,
   is trusted by the relying party.  Relying parties SHOULD NOT use a
   KeyDigest outside of the time range given in the validFrom and
   validUntil attributes.

Notes:

The text after the ';' is difficult to read. I am not sure what is should say.
--VERIFIER NOTES--
The text does take a little effort to parse, but is correct as written.
It says validUntil is optional:
IF validUntil not given
DO FOREVER
use trust anchor
IF ( (NewKeyDigest covers same DNSKEY record) &&
(NewKeyDigest has a validUntil) &&
(NewKeyDigest is trusted by relying party) )
exit
ENDIF
ENDDO

RFC 7986, "New Properties for iCalendar", October 2016

Source of RFC: calext (art)

Errata ID: 5449
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Дилян Палаузов
Date Reported: 2018-08-03
Rejected by: Francesca Palombini
Date Rejected: 2022-11-23

Section 5.9 COLOR Pr says:

Description:   ...The value is a case-insensitive color name taken from
the CSS3 set of names, defined in Section 4.3 of [W3C.REC-css3-color-
20110607].

Example:  The following is an example of this property:
   COLOR:turquoise

It should say:

Description:   ...The value is either a case-insensitive color name
taken from the CSS3 set of names, defined in Section 4.3 of [W3C.REC-
css3-color-20110607], or a lower-cased rgb() functional notation with
absolute values specified in Section 4.2.1 of the same document.

Examples:  The following are examples of this property:
   COLOR:turquoise
   COLOR:rgb(61\,211\,68)

Notes:

draft-daboo-icalendar-extensions-07 removed the possibily to have RGB colours for COLOR.

CSS3 included color names, that browsers at that time suppored, originating from X11's rgb.txt. The color names and values were randomly chosen. The minimal distance between the colors isn't consistent. One motivation for creating a color name were hardware capabilities - an argument which isn't valid for 20 years now. There is no reason to limit the number of possible values for COLOR. A user interface for choosing a named color has either to offer the user the possibility to choose from a pre-filled list of colors, which could clutter the interface, or let the user choose any RGB color and narrow it later to the closest color with CSS3 name. This narrowing isn't trivial and performing it seems like having an RFC running in itself.
--VERIFIER NOTES--
In rejecting this Errata report I note that the reported error is not a typo, but a deliberate decision of the authors and working group. This sort of change needs to be achieved through a consensus document.

RFC 7991, "The "xml2rfc" Version 3 Vocabulary", December 2016

Source of RFC: IAB

Errata ID: 5781
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: John Klensin
Date Reported: 2019-07-14
Rejected by: Mirja Kühlewind (RSAB chair)
Date Rejected: 2024-03-13

Section Hdr & Abstra says:

Header: Obsoletes: 7749

And, in the Abstract: 

This document obsoletes the v2 grammar described in RFC 7749.

It should say:

Header: remove the "Obsoletes" line

Abstract: 

This new version of the syntax is expected to supersede the v2 grammar
described in RFC 7749 and has started to do so.

Notes:

The norm in the IETF is that is one document obsoletes another, we treat the obsoleted document as dead and no longer to be referenced. But xml2rfc v2 is very much not obsolete and won't be obsolete until v3 is fully deployed, I-Ds are __no longer__ being prepared and passed to the submission tool in v2, and the RFC Editor stops accepting v2 files when a document is transferred to them from a Stream manager.

We should accurately describe the status of documents, not anticipate the future, especially while the most common practice _in the IETF_ is still to use the prior version and its syntax.
--VERIFIER NOTES--
An RFC can obsolete another RFC without moving the RFC to historic. This is also what is done for newer versions of certain protocols like e.g. TLS.

RFC 8031, "Curve25519 and Curve448 for the Internet Key Exchange Protocol Version 2 (IKEv2) Key Agreement", December 2016

Source of RFC: ipsecme (sec)

Errata ID: 6339
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Christian Tschudin
Date Reported: 2020-11-17
Rejected by: Paul Wouters
Date Rejected: 2023-07-28

Section Appendix A says:

The public keys are generated from this using the formula in
Section 2:

pub_i = X25519(d_i, G) =
             48 d5 dd d4 06 12 57 ba 16 6f a3 f9 bb db 74 f1
             a4 e8 1c 08 93 84 fa 77 f7 90 70 9f 0d fb c7 66

pub_r = X25519(d_r, G) =
             0b e7 c1 f5 aa d8 7d 7e 44 86 62 67 32 98 a4 43
             47 8b 85 97 45 17 9e af 56 4c 79 c0 ef 6e ee 25

And this is the value of the Key Exchange Data field in the Key
Exchange payload described in Section 3.1.  The shared value is
calculated as in Section 2:

SHARED_SECRET = X25519(d_i, pub_r) = X25519(d_r, pub_i) =
             c7 49 50 60 7a 12 32 7f-32 04 d9 4b 68 25 bf b0
             68 b7 f8 31 9a 9e 37 08-ed 3d 43 ce 81 30 c9 50

It should say:

The public keys are generated from this using the formula in
Section 2:

pub_i = X25519(d_i, G) =
             a7 07 b3 bc 0f 37 56 fc 0a cf 33 55 85 c5 f7 7b
             9f 29 ff a4 24 70 14 af 84 70 5b eb 50 46 26 29

pub_r = X25519(d_r, G) =
             0e 57 7e 11 5d 6c 08 59 b8 51 36 d2 1b 1c fd 74
             67 9f 91 14 61 1d 79 c6 81 ba d0 8a 7e 1f 0a 04

And this is the value of the Key Exchange Data field in the Key
Exchange payload described in Section 3.1.  The shared value is
calculated as in Section 2:

SHARED_SECRET = X25519(d_i, pub_r) = X25519(d_r, pub_i) =
             d6 8d 8c ea fd 2c d3 ce 25 34 43 33 c8 9e 35 54
             9e 0f c6 1a 98 87 39 34 b1 8a 18 70 f0 3a 17 0c

Notes:

The test vector values given both for the public keys and for the shared secret are wrong. It turns out that they were derived from the unchanged random input, instead of d_X. An explanation could be that a first text version did not include the fixing of the random bits and that after inserting the respective paragraph (introducing fixed_X and d_X), it was forgotten to update pub_X and SHARED_SECRET.

Paul Wouters: endian issue mentioned in notes split into separate errata
--VERIFIER NOTES--
Paul Wouters (AD): As per Tobias Brunner:

The original test vector works for us (verified with multiple X25519
implementations). I think most of the confusion comes from the
different formatting of the values when compared to the test vectors in
RFC 7749 (in particular d_i/r).

In the latter, the values are given as long hex strings. It states:

"The inputs are generally given as 64 or 112 hexadecimal digits that
need to be decoded as 32 or 56 binary bytes before processing."

So these values are byte strings, i.e. each two hex digits simply
represent a byte. For the random_i/r, pub_i/r and SHARED_SECRET values
in RFC 8031 this has been made a bit clearer by separating the
individual bytes.

But then there are the d_i and d_r values. These are given as long hex
strings, however, unlike those in RFC 7749, they are not byte strings
but actually the numbers in base 16 after decoding the binary values
fixed_i/r as little-endian. Note that RFC 7749 also gives the decoded
numeric values of some of the inputs, but does so in base 10 thus
avoiding this confusion.

So in RFC 8031 it would have been clearer if these values were either
prefixed with 0x:

d_i = 0x549D5F4A460900E6D9F63F53586AD1DD8CEAF925739B78B676B4558630B41F70
d_r = 0x4856A039B8F178E9A1550722DCEF01559ECDBA30E0D0ADDD600D295352645408

or also given in base 10:

d_i = 38272331938479145686941743521879072306
324697418955568337792079861743202082672
d_r = 32719579781175365148694953981896303820
370069993938279311538545124444601603080

RFC 8032, "Edwards-Curve Digital Signature Algorithm (EdDSA)", January 2017

Source of RFC: IRTF

Errata ID: 5757
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Franck Rondepierre
Date Reported: 2019-06-21
Rejected by: Stanislav Smyshlyaev
Date Rejected: 2021-10-26

Section .1 says:

An element (x,y) of E is encoded as a b-bit string called ENC(x,y),
 which is the (b-1)-bit encoding of y concatenated with one bit that
 is 1 if x is negative and 0 if x is not negative.

It should say:

An element (x,y) of E is encoded as a b-bit string called ENC(x,y),
 which is the (b-1)-bit encoding of y concatenated 
with the least significant bit of x.

Notes:

Section 3.1 is not coherent with encodings described for Ed25519 (5.1.2) and Ed448 (5.2.2)
--VERIFIER NOTES--
The original text was correct (verified by Nick Sullivan).

RFC 8040, "RESTCONF Protocol", January 2017

Note: This RFC has been updated by RFC 8527

Source of RFC: netconf (ops)

Errata ID: 5565
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Qin Wu
Date Reported: 2018-12-03
Rejected by: Ignas Bagdonas
Date Rejected: 2019-10-23

Section 7 says:

              +-------------------------+------------------+
              | error-tag               | status code      |
              +-------------------------+------------------+
              | in-use                  | 409              |
              | lock-denied             | 409              |
              | resource-denied         | 409              |
              | data-exists             | 409              |
              | data-missing            | 409              |

It should say:

              +-------------------------+------------------+
              | error-tag               | status code      |
              +-------------------------+------------------+
              | in-use                  | 409              |
              | lock-denied             | 409              |
              | resource-denied         | 409              |
              | data-exists             | 409              |
              | data-missing            | 404              |

Notes:

The <error-tag> data missing should be mapped to status code '404' instead of '409' to get consistent with the defintion of data-missing in RFC6241.
--VERIFIER NOTES--
Rejected based on WG discussion: https://mailarchive.ietf.org/arch/msg/netconf/XfoOpKslbdbGbX8HZrQHtNRvVkw

Errata ID: 5761
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Qin WU
Date Reported: 2019-06-24
Rejected by: Ignas Bagdonas
Date Rejected: 2019-10-17

Section 4.4.1 says:

If the data resource already exists, then the POST request MUST fail
and a "409 Conflict" status-line MUST be returned.  The error-tag
value "resource-denied" is used in this case

It should say:

If the data resource already exists, then the POST request MUST fail
and a "409 Conflict" status-line MUST be returned.  The error-tag 
value "data-exists" is used in this case

Notes:

The error-tag value should be corrected as "data-exists" in this case
based on the context. According to error-tag definition in RFC6241:

error-tag: resource-denied
error-type: transport, rpc, protocol, application
error-severity: error
error-info: none
Description: Request could not be completed because of
insufficient resources.

It is apparent error-tag value "data-exists" should be corresponding
to the data resource already exists condition.
--VERIFIER NOTES--
Rejected based on the discussion on WG mailing list: https://mailarchive.ietf.org/arch/msg/netconf/LNYNKiK7RYhTeita4oCte0HVcLA

Errata ID: 5857
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Qin WU
Date Reported: 2019-09-11
Rejected by: Ignas Bagdonas
Date Rejected: 2019-10-17

Section 3.1 says:

   The server might respond as follows:

      HTTP/1.1 200 OK
      Date: Thu, 26 Jan 2017 20:56:30 GMT
      Server: example-server
      Cache-Control: no-cache
      Last-Modified: Thu, 26 Jan 2017 16:00:14 GMT
      Content-Type: application/yang-data+json

      { "operations" : { "example-jukebox:play" : [null] } }

It should say:

   The server might respond as follows:

      HTTP/1.1 200 OK
      Date: Thu, 26 Jan 2017 20:56:30 GMT
      Server: example-server
      Cache-Control: no-cache
      Last-Modified: Thu, 26 Jan 2017 16:00:14 GMT
      Content-Type: application/yang-data+json

      { "operations" :[ { "example-jukebox:play" : [null] } ]}

Notes:

Returned operations in the RESTCONF response should be an array of the particular type, therefore the brackets are needed to enclose a list of operations associated with example-jukebox.
--VERIFIER NOTES--
Rejected based on mailing list discussion: https://mailarchive.ietf.org/arch/msg/netconf/T9y2CxELL4gmvkbBischAUtnYMg

Errata ID: 5858
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Qin WU
Date Reported: 2019-09-11
Rejected by: Ignas Bagdonas
Date Rejected: 2019-10-22

Section 5.3.1,5.3.2 says:

      GET /restconf/data/interfaces/interface=eth1
          ?with-defaults=report-all-tagged HTTP/1.1
      Host: example.com
      Accept: application/yang-data+xml

      GET /restconf/data/interfaces/interface=eth1\
          ?with-defaults=report-all-tagged HTTP/1.1
      Host: example.com
      Accept: application/yang-data+json

It should say:

      GET /restconf/data/ietf-interfaces:interfaces/interface=eth1
          ?with-defaults=report-all-tagged HTTP/1.1
      Host: example.com
      Accept: application/yang-data+xml

      GET /restconf/data/ietf-interfaces:interfaces/interface=eth1\
          ?with-defaults=report-all-tagged HTTP/1.1
      Host: example.com
      Accept: application/yang-data+json

Notes:

Based on the rule defined in section 3.5.3 of RFC8040, the module name ietf-interface followed by a colon character (":") should be prepended to the node name interfaces.
--VERIFIER NOTES--
Examples in sections 5.3.1 and 5.3.2 are not based on ietf-intrefaces module.

Errata ID: 6271
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Kent Watsen
Date Reported: 2020-09-01
Rejected by: Robert Wilton
Date Rejected: 2024-01-12

Section 4.5 says:

   The "insert" (Section 4.8.5) and "point" (Section 4.8.6) query
   parameters MUST be supported by the PUT method for data resources.
   These parameters are only allowed if the list or leaf-list is
   "ordered-by user".

It should say:

   The "insert" (Section 4.8.5) and "point" (Section 4.8.6) query
   parameters MUST be supported by the PUT method for data resources.
   These parameters are only allowed if the target resource is a
   non-existent entry of an "ordered-by user" list or leaf-list.

Notes:

First, Section 3.5 (Data Resource) says that "list" and "leaf-leaf" are not a data resources:

A data resource represents a YANG data node that is a descendant node
of a datastore resource. Each YANG-defined data node can be uniquely
targeted by the request-line of an HTTP method. Containers, leafs,
leaf-list entries, list entries, anydata nodes, and anyxml nodes are
data resources.

Second, these query parameters only make sense when targeting a non-existent entry. If the entry does not exist, then PUT is being used like a POST: to create and place an item in an ordered list. However, if the entry exists, then PUT is being used to both replace the contents and (presumably) re-place the order in the list; but this doesn't make sense because:

1) "insert" defaults to "last".
2) there is no "insert" value to indicate "keep existing placement".
3) having to concoct valid "insert" and "point" values is hard.

Thus indiscriminate PUTs would move entries to the end, which can't be desired...
--VERIFIER NOTES--
Replaced by errata 6277.

Errata ID: 6342
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Muly Ilan
Date Reported: 2020-11-22
Rejected by: Rob Wilton
Date Rejected: 2024-01-15

Section 4.6.1 says:

To replace just the "year" field in the "album" resource (instead of
replacing the entire resource with the PUT method), the client might
send a plain patch as follows:
PATCH /restconf/data/example-jukebox:jukebox/\
library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1
Host: example.com
If-Match: "b8389233a4c"
Content-Type: application/yang-data+xml
<album xmlns="http://example.com/ns/example-jukebox">
<year>2011</year>
</album>

It should say:

To replace just the "year" field in the "album" resource (instead of
replacing the entire resource with the PUT method), the client might
send a plain patch as follows:
PATCH /restconf/data/example-jukebox:jukebox/\
library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1
Host: example.com
If-Match: "b8389233a4c"
Content-Type: application/yang-data+xml
<album xmlns="http://example.com/ns/example-jukebox">
<name>Wasting Light</name>
<year>2011</year>
</album>

Notes:

Missing key leaf value in the message-body (<name>Wasting Light</name>)
--VERIFIER NOTES--
As per this thread, https://mailarchive.ietf.org/arch/msg/netconf/ZlAQl3-YljG4tCDlrHP-PGb-KEY/ the consensus amongst the authors was that the RFC does not specify whether keys must be included in a YANG PATCH operation, and hence the default assumption is that they are not required.

It may be helpful for a a future revision of RESTCONF (or possibly YANG) to more explicitly state the required behaviour.

Errata ID: 6362
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Muly Ilan
Date Reported: 2020-12-22
Rejected by: Rob Wilton
Date Rejected: 2024-01-15

Section 4.3. says:

   The client might request the response header fields for an XML
   representation of a specific "album" resource:

      GET /restconf/data/example-jukebox:jukebox/\
         library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1
      Host: example.com
      Accept: application/yang-data+xml

   The server might respond as follows:

      HTTP/1.1 200 OK
      Date: Thu, 26 Jan 2017 20:56:30 GMT
      Server: example-server
      Content-Type: application/yang-data+xml
      Cache-Control: no-cache
      ETag: "a74eefc993a2b"
      Last-Modified: Thu, 26 Jan 2017 14:02:14 GMT

It should say:

   The client might request the response header fields for an XML
   representation of a specific "album" resource:

      GET /restconf/data/example-jukebox:jukebox/\
         library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1
      Host: example.com
      Accept: application/yang-data+xml

   The server might respond as follows:

      HTTP/1.1 200 OK
      Date: Thu, 26 Jan 2017 20:56:30 GMT
      Server: example-server
      Content-Type: application/yang-data+xml
      Cache-Control: no-cache

Notes:

Removed the "ETag" and "Last-Modified" header fields.

According to Appendix B.3.1. :
To retrieve only the configuration child resources, the "content"
parameter is set to "config". Note that the "ETag" and
"Last-Modified" headers are only returned if the "content" parameter
value is "config".
--VERIFIER NOTES--
This has been discussed at: https://mailarchive.ietf.org/arch/msg/netconf/SIpDoR7W8_na_USDHdMApjW6Wu8/

The example is not incorrect because an ETag and Last-Modified header are allowed to be returned if no content parameter has been specified, but only apply to the configuration data.

Note, the referenced text in Appendix B.3.1 (Note that the "ETag" and
"Last-Modified" headers are only returned if the "content" parameter
value is "config") looks to be incorrect and should be removed or clarified in a future revision of the protocol.

Errata ID: 6363
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Muly Ilan
Date Reported: 2020-12-22
Rejected by: Rob Wilton
Date Rejected: 2023-10-02

Section 4.8.2. says:

   By default, the server will include all sub-resources within a
   retrieved resource that have the same resource type as the requested
   resource.  The exception is the datastore resource.  If this resource
   type is retrieved, then by default the datastore and all child data
   resources are returned.

It should say:

   By default, the server SHOULD include all sub-resources within a
   retrieved resource that have the same resource type as the requested
   resource.  The exception is the datastore resource.  If this resource
   type is retrieved, then by default the datastore and all child data
   resources are returned.

Notes:

Substitute "will" by "SHOULD".

Use one of the keywords of RFC2119 to clarify the expected server behavior.
--VERIFIER NOTES--
The existing text is correct, and could probably be read equivalently to "the server MUST include". Changing "will" to "SHOULD" would change the meaning of the specification by giving flexibility for servers to not return sub-resources and yet still be compliant.

RFC 8058, "Signaling One-Click Functionality for List Email Headers", January 2017

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: art

Errata ID: 5558
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Etan Wexler
Date Reported: 2018-11-22
Rejected by: Alexey Melnikov
Date Rejected: 2018-11-26

Section 8.3 says:

Content-Length: 124

It should say:

Content-Length: 126

Notes:

The entity body of the message should have the sequence of carriage return and line feed after the final boundary marker. The inclusion of these two control codes would bring the count of octets of bits to 126, not 124. Given that the sequence of carriage return and line feed should have no associated glyphs, no change is needed at the end of the example.
--VERIFIER NOTES--
John R Levine wrote:

I believe this one is wrong and 124 is the correct length. It would be
126 if you put a \r\n after the -- at the end of the last MIME separator.
If the problem were that we'd left out the carriage returns, there are
four lines so the (wrong) length would have been 120.

RFC 8077, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", February 2017

Source of RFC: pals (rtg)

Errata ID: 5243
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: JAYANT BHARDWAJ
Date Reported: 2018-01-25
Rejected by: Deborah Brungard
Date Rejected: 2018-05-14

Section 6.1 says:

-  Group ID

      An arbitrary 32-bit value that represents a group of PWs that is
      used to create groups in the PW space.  The Group ID is intended
      to be used as a port index or a virtual tunnel index.  To simplify
      configuration, a particular PW Group ID at ingress could be part
      of a Group ID assigned to the virtual tunnel for transport to the
      egress router.  The Group ID is very useful for sending wildcard
      label withdrawals or PW wildcard status Notification messages to
      remote PEs upon physical port failure.

It should say:

-  Group ID
 
      An arbitrary 32-bit value that represents a group of PWs that is
      used to create groups in the PW space.  The Group ID is intended
      to be used as a port index or a virtual tunnel index.  To simplify
      configuration, a particular PW Group ID at ingress could be part
      of a Group ID assigned to the virtual tunnel for transport to the
      egress router.  The Group ID is very useful for sending wildcard
      label withdrawals or PW wildcard status Notification messages to
      remote PEs upon physical port failure or transport tunnel failure.

Notes:

The PW group can be created on basis of the transport tunnel index.

So Group Id can be used to send PW wildcard status notification to remote PEs on physical port failure or Transport tunnel failure.
--VERIFIER NOTES--
Based on input from the Chair and pals wg members, I have rejected this errata. This sentence is not a normative sentence, it is an example. There are no interoperability concerns with the current text.

RFC 8110, "Opportunistic Wireless Encryption", March 2017

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 5980
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexander Martin
Date Reported: 2020-02-12
Rejected by: John Scudder
Date Rejected: 2024-02-11

Section 4.3 says:

   This failure should be logged, and if the client abandons association
   due to the (repeated) receipt of invalid elements, notification of
   this fact should be provided to the user.

It should say:

   This failure SHOULD be logged, and if the client abandons association
   due to the (repeated) receipt of invalid elements, notification of
   this fact SHOULD be provided to the user.

Notes:

Uncapitalized "should" used instead of RFC 2119 "SHOULD".
--VERIFIER NOTES--
Use of RFC 2119 keywords is optional. The text is sufficiently clear with the lower-case “should”.

RFC 8126, "Guidelines for Writing an IANA Considerations Section in RFCs", June 2017

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 6522
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Ketan Talaulikar
Date Reported: 2021-04-08
Rejected by: Alvaro Retana
Date Rejected: 2021-04-08

Section 4.6 says:

   The intention behind "permanent and readily available" is that a
   document can reasonably be expected to be findable and retrievable
   long after IANA assignment of the requested value.  Publication of an
   RFC is an ideal means of achieving this requirement, but
   Specification Required is intended to also cover the case of a
   document published outside of the RFC path, including informal
   documentation.

It should say:

   The intention behind "permanent and readily available" is that a
   document can reasonably be expected to be findable and retrievable
   long after IANA assignment of the requested value.  Publication of an
   RFC is an ideal means of achieving this requirement, but
   Specification Required is intended to also cover the case of a
   document published outside of the RFC path, including informal
   documentation. Specific versions of Internet-Drafts, specifically
   IETF Working Group documents, that serve as "work in progress" 
   reference for RFC path documents also achieve this requirement 
   subject to Designated Expert review. Upon publication as RFC the
   reference may be updated upon request by Designated Expert.

Notes:

As part of the IESG review of draft-ietf-idr-bgp-ls-registry, the was a debate about whether an Internet-Draft serves the requirement of "permanent and readily available" for allocation under Specification Required policy. While IDs are indeed permanent and readily available these days and referencing a specific version does meet the requirements. However, the boiler plate text on IDs indicate that they many not be cited as reference other than work-in-progress.

For certain WGs (e.g. IDR) which await at least two implementations, the process of RFC publication takes time and it would have been good if the WG could have requested allocation based on a WG ID instead of following the tedious process of early allocation in RFC7120. The reference in IANA registry can then be update to the RFC upon publication and if not can remain with the reference to the ID.
--VERIFIER NOTES--
------

While the concerns are valid, this report doesn't target an error in the document but makes a proposal that will require community discussion and consensus.

RFC 8135, "Complex Addressing in IPv6", April 2017

Source of RFC: INDEPENDENT

Errata ID: 5485
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: John Doe
Date Reported: 2018-08-29
Rejected by: Adrian Farrel
Date Rejected: 2018-09-06

Throughout the document, when it says:

This document defines an Experimental Protocol for the 
Internet community.

It should say:

This document could have defined an Experimental Protocol 
for the Internet community. It might well have been useful 
to use floating point addresses for addressing qubits in 
a quantum computer where many small objects will occupy a 
tiny space, or with a protocol where location defines the 
dynamic address rather than the user. 

Instead of presenting a useful document it was thought that 
an April Fool's joke would be preferable. Furthermore, no 
submissions or work is to be performed on April 1st henceforth, 
lest it be confused with useful work versus a time for levity.

Notes:

We don't come here for jokes or porn or to hear about your intestinal problems. We come here for facts.
--VERIFIER NOTES--
While it is possible that you don't use the Internet for jokes or porn, this cannot be said for everyone. And you forgot pictures of cats.

RFC 8174, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", May 2017

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 6878
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Boris
Date Reported: 2022-03-10
Rejected by: RFC Editor
Date Rejected: 2022-04-05

Throughout the document, when it says:

http://www.rfc-editor.org/info/rfc8174
http://trustee.ietf.org/license-info
http://www.rfc-editor.org/info/rfc2119
http://internetmessagingtechnology.org

It should say:

https://www.rfc-editor.org/info/rfc8174
https://trustee.ietf.org/documents/trust-legal-provisions
https://www.rfc-editor.org/info/rfc2119
https://internetmessagingtechnology.org

Notes:

The URLs should be using HTTPS instead of HTTP and should be updated.
--VERIFIER NOTES--
This is how the URLs were presented when the RFC was published.

RFC 8175, "Dynamic Link Exchange Protocol (DLEP)", June 2017

Source of RFC: manet (rtg)

Errata ID: 6730
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Brian Sipos
Date Reported: 2021-11-03
Rejected by: Alvaro Retana
Date Rejected: 2021-11-05

Section 12.4 says:

The Peer Offer Signal completes the discovery process; see Section 7.1.

It should say:

The UDP source port and destination port MUST be set to the UDP destination port and source port, respectively, of the UDP packet containing the associated Peer Discovery Signal. The Peer Offer Signal completes the discovery process; see Section 7.1.

Notes:

The original text did not specify any requirement about the source or destination UDP port number of the Peer Offer signal.
--VERIFIER NOTES--
While this is a valid report, it is a duplicate of Errata ID: 6472. I am then marking this one as Rejected.

Errata ID: 6731
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Brian Sipos
Date Reported: 2021-11-03
Rejected by: Alvaro Retana
Date Rejected: 2021-11-05

Section 12.4 says:

The Peer Offer Signal completes the discovery process; see Section 7.1.

It should say:

The UDP source port and destination port MUST be set to the UDP destination port and source port, respectively, of the UDP packet containing the associated Peer Discovery Signal. The Peer Offer Signal completes the discovery process; see Section 7.1.

Notes:

The original text did not specify any requirement about the source or destination UDP port number of the Peer Offer signal.
--VERIFIER NOTES--
While this is a valid report, it is a duplicate of Errata ID: 6472. I am then marking this one as Rejected.

RFC 8176, "Authentication Method Reference Values", June 2017

Source of RFC: oauth (sec)

Errata ID: 6314
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: David Brossaard
Date Reported: 2020-10-20
Rejected by: Benjamin Kaduk
Date Rejected: 2020-10-20

Section 1. says:

For context, the "amr" (Authentication Methods References) claim is
   defined by Section 2 of the OpenID Connect Core 1.0 specification
   [OpenID.Core] as follows:

It should say:

For context, the "amr" (Authentication Methods References) claim is
   defined by Section 2 of the OpenID Connect Core 1.0 specification
   [OpenID.Core] as follows:

Notes:

There is no text change but the link on "Section 2" points to section 2 in the same RFC rather than section 2 in the OpenID Connect Core 1.0 specification.
--VERIFIER NOTES--
Errata reports are for reporting issues with the authoritative RFC version(s) as published by the RFC Editor. RFC 8176 predates the usage of the "v3 XML" format, so the plain text version is the authoritative one, and thus questions of HTML links are irrelevant for it.

RFC 8200, "Internet Protocol, Version 6 (IPv6) Specification", July 2017

Source of RFC: 6man (int)

Errata ID: 5170
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Fernando Gont
Date Reported: 2017-10-28
Rejected by: Suresh Krishnan
Date Rejected: 2020-02-03

Section 4.5 says:

              A Fragment Offset containing the offset of the fragment,
              in 8-octet units, relative to the start of the
              Fragmentable Part of the original packet.  The Fragment
              Offset of the first ("leftmost") fragment is 0.

It should say:

              A Fragment Offset containing the offset of the fragment,
              in 8-octet units, relative to the start of the
              "Extension & Upper-Layer Headers" Part of the original 
              packet. The Fragment Offset of the fragment containing
              the "Extension & Upper-Layer Headers" part is 0.

Notes:

Clearly, the first fragment will contain a Fragment Offset of 0.

However, given the figure:

---- cut here ----
original packet:

+-----------------+-----------------+--------+--------+-//-+--------+
| Per-Fragment |Ext & Upper-Layer| first | second | | last |
| Headers | Headers |fragment|fragment|....|fragment|
+-----------------+-----------------+--------+--------+-//-+--------+

fragment packets:

+------------------+---------+-------------------+----------+
| Per-Fragment |Fragment | Ext & Upper-Layer | first |
| Headers | Header | Headers | fragment |
+------------------+---------+-------------------+----------+

+------------------+--------+-------------------------------+
| Per-Fragment |Fragment| second |
| Headers | Header | fragment |
+------------------+--------+-------------------------------+
o
o
o
+------------------+--------+----------+
| Per-Fragment |Fragment| last |
| Headers | Header | fragment |
+------------------+--------+----------+


it is the part market as "Ext & Upper-Layer Headers" the one that will have a Fragment offset of 0, rather than the part marked as "first fragment". For example, one could envision this scenario:

---- cut here ----
original packet:

+-----------------+-----------------+---------------+
| Per-Fragment |Ext & Upper-Layer| first & last |
| Headers | Headers | fragment |
+-----------------+-----------------+---------------+

fragment packets:

+------------------+---------+-------------------+
| Per-Fragment |Fragment | Ext & Upper-Layer |
| Headers | Header | Headers |
+------------------+---------+-------------------+

+------------------+--------+---------------+
| Per-Fragment |Fragment| first & last |
| Headers | Header | fragment |
+------------------+--------+---------------+

---- cut here ----

Where the first fragment just contains the entire IPv6 header chain, and then second fragment contains the chunk marked as "first fragment" (this "first fragment" part is the only "Fragmentable" part of the packet).

Note: the text "The Fragment Offset of the first ("leftmost") fragment is 0." was re-phrased in the "corrected text", since it might confuse the reader regarding whether it refers to the actual first fragment (i.e. the first packet corresponding to the fragmented datagram), or the chunk marked as "first fragment" in the figure.
--VERIFIER NOTES--
Verifier's Note by Suresh Krishnan (Responsible AD for 6man): The 6man working group has chosen to address the subject of this Erratum and other related Errata using a consolidated fix detailed in the Erratum report #5945. I would like to thank the submitter Fernando Gont for bringing this up.

Errata ID: 5171
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Fernando Gont
Date Reported: 2017-10-29
Rejected by: Suresh Krishnan
Date Rejected: 2020-02-03

Section 4.5 says:

   The subsequent fragment packets are composed of:

      (1)  The Per-Fragment headers of the original packet, with the
           Payload Length of the original IPv6 header changed to contain
           the length of this fragment packet only (excluding the length
           of the IPv6 header itself), and the Next Header field of the
           last header of the Per-Fragment headers changed to 44.

      (2)  A Fragment header containing:

              The Next Header value that identifies the first header
              after the Per-Fragment headers of the original packet.

              A Fragment Offset containing the offset of the fragment,
              in 8-octet units, relative to the start of the
              Fragmentable Part of the original packet.

It should say:

   The subsequent fragment packets are composed of:

      (1)  The Per-Fragment headers of the original packet, with the
           Payload Length of the original IPv6 header changed to contain
           the length of this fragment packet only (excluding the length
           of the IPv6 header itself), and the Next Header field of the
           last header of the Per-Fragment headers changed to 44.

      (2)  A Fragment header containing:

              The Next Header value that identifies the first header
              after the Per-Fragment headers of the original packet.

              A Fragment Offset containing the offset of the fragment,
              in 8-octet units, relative to the start of the
              "Extension & Upper-Layer Headers" part of the original
              packet.

Notes:

This complements this errata:

Reported By: Fernando Gont
Date Reported: 2017-10-28
--VERIFIER NOTES--
Verifier's Note by Suresh Krishnan (Responsible AD for 6man): The 6man working group has chosen to address the subject of this Erratum and other related Errata using a consolidated fix detailed in the Erratum report #5945. I would like to thank the submitter Fernando Gont for bringing this up.

Errata ID: 5172
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Fernando Gont
Date Reported: 2017-10-29
Rejected by: Suresh Krishnan
Date Rejected: 2020-02-03

Section 4.5 says:

         The Fragmentable Part of the reassembled packet is constructed
         from the fragments following the Fragment headers in each of
         the fragment packets.  The length of each fragment is computed
         by subtracting from the packet's Payload Length the length of
         the headers between the IPv6 header and fragment itself; its
         relative position in Fragmentable Part is computed from its
         Fragment Offset value.

It should say:

         The "Ext & Upper-Layer Headers" part and Fragmentable Part of 
         the reassembled packet are constructed from the "chunks" 
         following the Fragment headers in each of the fragment packets.
         The length of each chunk is computed by subtracting from the 
         packet's Payload Length the length of the headers between the
         IPv6 header and chunk itself; the relative position of the 
         chunk is computed from its Fragment Offset value.

Notes:

* The original text misses how to construct the "Ext & Upper-Layer Headers" of the packet, which in the figures is not considered to be part of the "Unfragmentable part" (it *was* considered part of it in RFC2460).

* The original text does says:
The length of each fragment is computed
by subtracting from the packet's Payload Length the length of
the headers between the IPv6 header and fragment itself

Assuming "each fragment" refers to the pieces marked as "first fragment", "second fragment", etc., this does not apply for the computation of the length of the first fragment, since such computed length would otherwise include the length of the first fragment, plus the length of "Ext & Upper-Layer Headers".

* The "corrected text" requires more work, and employs the (previously undefined) term "chunk" to refer to the content of a fragment (the chunk following a Fragment Header in a given packet). This is because for all fragments other than the first, "fragment" is what follows an FH, but for the first fragment (given the figures), "first fragment" is NOT everything that follows the FH (i.e., it does not include the "Ext & Upper-Layer Headers" part.

* Note that in the corrected text, the phrase "its relative position in Fragmentable Part is computed from its Fragment Offset value", since the relative position is really from the "Ext & Upper-Layer Headers" part, rather than from the Unfragmentable part.
--VERIFIER NOTES--
Verifier's Note by Suresh Krishnan (Responsible AD for 6man): The 6man working group has chosen to address the subject of this Erratum and other related Errata using a consolidated fix detailed in the Erratum report #5945. I would like to thank the submitter Fernando Gont for bringing this up.

Errata ID: 5173
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Fernando Gont
Date Reported: 2017-10-29
Rejected by: Suresh Krishnan
Date Rejected: 2020-02-03

Section 4.5 says:

   reassembled original packet:

   +---------------+-----------------+---------+--------+-//--+--------+
   | Per-Fragment  |Ext & Upper-Layer|  first  | second |     | last   |
   |    Headers    |     Headers     |frag data|fragment|.....|fragment|
   +---------------+-----------------+---------+--------+-//--+--------+

It should say:

   reassembled original packet:

   +---------------+-----------------+---------+--------+-//--+--------+
   | Per-Fragment  |Ext & Upper-Layer|  first  | second |     | last   |
   |    Headers    |     Headers     | fragment|fragment|.....|fragment|
   +---------------+-----------------+---------+--------+-//--+--------+

Notes:

The figure in the "original text" is inconsistent with an earlier figure of the "original packet" (in page 18), where the "Ext & Upper-Layer Headers" part is followed by "first fragment" (rather than "first fragment data").

As an alternative to the "corrected text" above, one could modify such earlier figure (s/first fragment/first fragment data/), but this would beg a definition of "how is a fragment composed?" i.e., what's "fragment data" and what's not).
--VERIFIER NOTES--
Verifier's Note by Suresh Krishnan (Responsible AD for 6man): The 6man working group has chosen to address the subject of this Erratum and other related Errata using a consolidated fix detailed in the Erratum report #5945. I would like to thank the submitter Fernando Gont for bringing this up.

Errata ID: 6003
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Fernando Gont
Date Reported: 2020-03-02
Rejected by: Erik Kline
Date Rejected: 2020-05-10

Section 4 says:

   Extension headers (except for the Hop-by-Hop Options header) are not
   processed, inserted, or deleted by any node along a packet's delivery
   path, until the packet reaches the node (or each of the set of nodes,
   in the case of multicast) identified in the Destination Address field
   of the IPv6 header.

   The Hop-by-Hop Options header is not inserted or deleted, but may be
   examined or processed by any node along a packet's delivery path,
   until the packet reaches the node (or each of the set of nodes, in
   the case of multicast) identified in the Destination Address field of
   the IPv6 header.  The Hop-by-Hop Options header, when present, must
   immediately follow the IPv6 header.  Its presence is indicated by the
   value zero in the Next Header field of the IPv6 header.

It should say:

   The source node of a packet, identified by the source address, may
   include extension headers in a packet when it is created. Extension
   headers must not be inserted or removed or have their length altered
   by any node for the lifetime of the IPv6 packet. Note that it follows
   from these requirements that the length of an IPv6 packet cannot
   change once the packet has been created by the source node. The
   aforementioned rules apply to all IPv6 extension headers.

   Extension headers (except for the Hop-by-Hop Options header, a
   Routing Header, or a Destination Options header preceding a Routing
   Header) are not processed by any node along a packet's delivery path,
   until the packet reaches the final destination node (or each of the
   set of final destination nodes, in the case of multicast).

   For packets that do not include a Routing Header, the final
   destination node is identified by the Destination Address field of
   the IPv6 header. For packets that include a Routing Header, the final
   destination node is identified by the Destination Address field of
   the IPv6 header only when the Segments Left field of the Routing
   Header is 0.

   The Hop-by-Hop Options header may be examined or processed by any
   node along a packet's delivery path, until the packet reaches the
   final destination node (or each of the set of final destination
   nodes, in the case of multicast). The Hop-by-Hop Options header, when
   present, must immediately follow the IPv6 header.  Its presence is
   indicated by the value zero in the Next Header field of the IPv6
   header.

   A Destination Options header preceding a Routing Header is processed
   only by the destination node (or each of the set of destination
   nodes, in the case of multicast) identified by the Destination
   Address field of the IPv6 header. This means that a Destination
   Options header preceding a Routing Header will be processed by the
   first destination of the packet (specified by the Destination Address
   field of the IPv6 header at the source node) and by each node listed
   in the Routing Header.

   A Routing Header is processed only by the destination node (or each
   of the set of destination nodes, in the case of multicast) identified
   by the Destination Address field of the IPv6 header. This means that
   a Routing Header will be processed by the first destination of the
   packet (specified by the Destination Address field of the IPv6 header
   at the source node) and by each node listed in the Routing Header. 

Notes:

This erratum addresses the following problems from RFC8200:

* It clarifies that IPv6 does not support en-route insertion/removal
of IPv6 Extension Headers

* Clarifies the the processing rules for Routing Headers and Destination
Options headers preceding a Routing Header.


RATIONALE:

IPv6 never supported the en-route insertion/removal of IPv6 Extension Headers, since it would have broken a number of IPv6 core components, including:

* IPsec Authentication Header (AH)

* Path-MTU Discovery for IPv6 (RFC8201)

* Error reporting based on ICMPv6 error messages (RFC4443), since hosts
validate that received error messages correspond to packets sent by
the host receiving the error message.


It was the intent of RFC8200 to clarify this behavior, as noted by Appendix B ("Changes Since RFC 2460") of RFC8200:

o Clarified that extension headers (except for the Hop-by-Hop
Options header) are not processed, inserted, or deleted by any
node along a packet's delivery path.

however, the resulting text was far from perfect. This erratum means to more closely reflect and respect the intent of RFC8200.

The corrected text has benefited from the review and input from Ron Bonica, Brian Carpenter, and Tom Herbert.
--VERIFIER NOTES--
Section 3 clearly highlights for the reader when the IPv6 Destination Address in the header might differ from the IPv6 address of the ultimate destination.

As such, all references in the document to "Destination Address" lacking further qualifying text should be read bearing this in mind. The text in section 4 is no exception. The key text has remained unchanged since RFC 1883.

Though it may be fraught with operational peril, including impeding the correct processing by the source node of a received ICMPv6 error message's encapsulated packet payload, a strict literal reading of the existing text affords any node in the header's Destination Address field a (possibly surprising) degree of flexibility in the handling of extension headers.

If IPsec AH (RFC 4302) were in use, the overall IPv6 header Payload Length field would need to remain intact, but the contents of certain types of extension headers between the IPv6 header and the AH header may not need to be preserved. If AH is not in use, it is not clear that any AH-related requirements need apply at all.

Given the continuing discussion, whether this text (and its strict literal interpretation) is a feature or a bug appears to lack consensus.

In fact, considering the apparent lack of substantive progress toward resolution on this issue in the working group since https://www.rfc-editor.org/errata/eid5933 previously attempted to revise this text, continuing use of the erratum report process for this could risk the appearance of bypassing the working group consensus process.

The text from Section 3 makes it clear that making the kind of change proposed would require a consensus change; this is not a matter to be address by an erratum alone.

RFC 8206, "BGPsec Considerations for Autonomous System (AS) Migration", September 2017

Source of RFC: sidr (rtg)

Errata ID: 7183
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Iljitsch van Beijnum
Date Reported: 2022-10-26
Rejected by: Alvaro Retana
Date Rejected: 2022-10-27

Section 3 says:

Since SPs are using migration methods that are transparent to customers and therefore do not require coordination with customers, they do not have as much control over the length of the transition period as they might with something completely under their administrative control

It should say:

Since SPs are using migration methods that are transparent to customers and therefore do not require coordination with customers, they can transition at any time without delay.

Notes:

I have no corrected text. If the migration methods are transparent, how is it possible that SPs "do not have as much control over the length of the transition period as they might with something completely under their administrative control"? As it's transparent they would in fact have complete administrative control.
--VERIFIER NOTES--
===
This report is rejected because the current statement is correct in the context in which it is written. In short, SPs and customers both need to transition their configurations to the new ASN.

https://mailarchive.ietf.org/arch/msg/sidr/6OYVQlXdJcllkB-motxDi7uuqhg/

RFC 8214, "Virtual Private Wire Service Support in Ethernet VPN", August 2017

Source of RFC: bess (rtg)

Errata ID: 5571
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: gangadhara reddy chavva; SatishKumar N Rodd
Date Reported: 2018-12-10
Rejected by: Martin Vigoureux
Date Rejected: 2019-06-17

Section 3.1 says:

C If set to 1, a control word [RFC4448] MUST be present
when sending EVPN packets to this PE. It is
recommended that the control word be included in the
absence of an entropy label [RFC6790].

It should say:

C If set to 1, a control word [RFC4448] MUST be present
when sending EVPN packets to this PE. It is
recommended that the control word be included in the
absence of an entropy label [RFC6790]. 

For detailed explanation of the behavior of EVPN VPWS 
session based on control word bit can be referred link: 
https://tools.ietf.org/html/rfc4447#section-6.2

which explains all combinations of control word 
configurations in detailed way whic was missing in RFC8214.

Notes:

RFC8214 doesn't mention the cases where control word configuration between the PE's can mismatch, disabled, enabled. which will lead to ambiguity in protocol implementation.
--VERIFIER NOTES--
This could change the specification in a way which in fact would likely require consensus. Authors of this errata are encouraged to follow the normal process and start with having a discussion in BESS WG.

Errata ID: 6117
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Luc Andre Burdet
Date Reported: 2020-04-22
Rejected by: Martin Vigourex
Date Rejected: 2021-02-08

Section 3.1, 8 says:

3.1.  EVPN Layer 2 Attributes Extended Community
            0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |   MBZ                   |C|P|B|  (MBZ = MUST Be Zero)
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         Name     Meaning
         ---------------------------------------------------------------
         P        If set to 1 in multihoming Single-Active scenarios, ...
         B        If set to 1 in multihoming Single-Active scenarios, ...
         C        If set to 1, a control word [RFC4448] MUST be present ...

8.  IANA Considerations
   Initial registrations are as follows:

        P      Advertising PE is the primary PE.
        B      Advertising PE is the backup PE.
        C      Control word [RFC4448] MUST be present.

It should say:

Option 1 : change explicit bitfield
==========
3.1.  EVPN Layer 2 Attributes Extended Community
            0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
##<swap>   |   MBZ                   |C|B|P|  (MBZ = MUST Be Zero)
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         Name     Meaning
         ---------------------------------------------------------------
         P        If set to 1 in multihoming Single-Active scenarios, ...
         B        If set to 1 in multihoming Single-Active scenarios, ...
         C        If set to 1, a control word [RFC4448] MUST be present ...

8.  IANA Considerations
   Initial registrations are as follows:

        P      Advertising PE is the primary PE.
        B      Advertising PE is the backup PE.
        C      Control word [RFC4448] MUST be present.


Option 2 : change implicit order
==========
3.1.  EVPN Layer 2 Attributes Extended Community
            0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |   MBZ                   |C|P|B|  (MBZ = MUST Be Zero)
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         Name     Meaning
         ---------------------------------------------------------------
##       B        If set to 1 in multihoming Single-Active scenarios, ...
##<swap 'implicit' list order B,P to match bitfield>
##       P        If set to 1 in multihoming Single-Active scenarios, ...
         C        If set to 1, a control word [RFC4448] MUST be present ...

8.  IANA Considerations
   Initial registrations are as follows:

##      B      Advertising PE is the backup PE.
##<swap 'implicit' list order B,P to match bitfield>
##      P      Advertising PE is the primary PE.
        C      Control word [RFC4448] MUST be present.

Notes:

While technically section 8 is not requesting any bit-position from IANA registry, the ordering of requests P-B-C vs. the field definition B-P-C is confusing, or at least inconsistent.

A clarifying statement is required:
- the field definition is should be swapped; or
- the field definition shall prime over all the places implying order when listing P-B-C
--VERIFIER NOTES--
This is not a technical errata or at least the reasonable solution to it seems to be editorial (shifting text around) rather than modifying the order of bits on the wire.

RFC 8223, "Application-Aware Targeted LDP", August 2017

Source of RFC: mpls (rtg)

Errata ID: 5584
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jayant Bhardwaj
Date Reported: 2018-12-27
Rejected by: James N Guichard
Date Rejected: 2023-05-31

Section 2.3.2 says:

1. The S-bit of the TAC is set to 1 or 0 to advertise or withdraw it.

It should say:

1. The E-bit of the TAC is set to 1 or 0 to advertise or withdraw it.

Notes:

My understanding of this RFC suggests that in order to Advertize or Withdraw TAC , the bit E in TAC is used. In Point # 1 of section 2.3.2, it is mentioned that bit S is used. Looks this is Editorial mistake.
--VERIFIER NOTES--
I believe this errata is inaccurate. The S-bit is part of the "Capability Parameter" TLV as defined in RFC 5561 Section 3 and the TAE is the Targeted Application Capability that is defined in RFC8223. Section 2.3.2 is correct in stating that the S-bit of the TAC is set to 1.

RFC 8231, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", September 2017

Note: This RFC has been updated by RFC 8786, RFC 9353

Source of RFC: pce (rtg)

Errata ID: 6627
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Oscar Gonzalez de Dios
Date Reported: 2021-07-01
Rejected by: John Scudder
Date Rejected: 2021-10-06

Section 6.4 says:

  <request>::= <RP>
                      <END-POINTS>
                      [<LSP>]
                      [<LSPA>]
                      [<BANDWIDTH>]
                      [<metric-list>]
                      [<RRO>[<BANDWIDTH>]]
                      [<IRO>]
                      [<LOAD-BALANCING>]

It should say:

  <request>::= <RP>
                      <END-POINTS>
                      [<LSP>]
                      [<CLASSTYPE>]
                      [<LSPA>]
                      [<BANDWIDTH>]
                      [<metric-list>]
                      [<RRO>[<BANDWIDTH>]]
                      [<IRO>]
                      [<LOAD-BALANCING>]

Notes:

RFC 5455 defines the CLASSTYPE object and specifies that the CLASSTYPE object MUST
be inserted after the END-POINT objects. RFC 8231 defines the LSP object and specifies that the LSP object MUST be inserted after the END-POINTS object. Hence, it is not clear if CLASSTYPE or LSP goes after END-POINTS. Hence, to disambiguate and avoid interoperability issues, the proposal is to include the CLASSTYPE object in the updated grammar. The order would be <END-POINTS>[<LSP>][<CLASSTYPE>]
--VERIFIER NOTES--
See also the mail thread at https://mailarchive.ietf.org/arch/msg/pce/UmqIZSDtRqe7yC5v0wHU64mrGuI/ for more discussion and detail.

In https://mailarchive.ietf.org/arch/msg/pce/VUM5GymISrBiPgoUEVH8IkaM3tU/, the AD at the time (Adrian) rejected erratum 3672, which is similar to this one in that it complains about ambiguous ordering and asks for a fix. Adrian ends his rejection comment with

“In rejecting this Errata report I note that the reported error is not a typo,
but a deliberate decision of the authors and working group. The fix, therefore,
if it is to be applied needs to be achieved through a consensus document.”

AFAICT this reasoning applies equally in the current case. Actually, it applies even more so, because the WG was offered draft-cmfg-pce-pcep-grammar-02 and didn’t do anything with it, which implies no consensus was demonstrated to go forward with a solution to the identified problem.

Therefore, I'm also rejecting this erratum. The right way forward is for the WG to take on this problem.

RFC 8252, "OAuth 2.0 for Native Apps", October 2017

Source of RFC: oauth (sec)

Errata ID: 5848
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Bayard Bell
Date Reported: 2019-08-26
Rejected by: Benjamin Kaduk
Date Rejected: 2019-08-30

Section Appendix B.1 says:

Apps can initiate an authorization request in the browser, without
the user leaving the app, through the "SFSafariViewController" class
or its successor "SFAuthenticationSession", which implement the in-
app browser tab pattern.  Safari can be used to handle requests on
old versions of iOS without in-app browser tab functionality.

It should say:

Apps can initiate an authorization request in the browser, without
the user leaving the app, through the "ASWebAuthenticationSession"
class or its successors "SFAuthenticationSession" and
"SFSafariViewController", which implement the in-app browser tab
pattern.  The first of these allows calls to a handler registered
for the AS URL, consistent with Section 7.2. The latter two classes,
now deprecated, can use Safari to handle requests on old versions of
iOS without in-app browser tab functionality.

Notes:

SFAuthenticationSession documentation reflects deprecated status:

https://developer.apple.com/documentation/safariservices/sfauthenticationsession

Here's the documentation for ASWebAuthenticationSession:

https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession
--VERIFIER NOTES--
This sort of change to update for events since the time of publication is not appropriate for an erratum; errata are intended solely to indicate errors in a document that were errors at the time of publication. A revision of the document or a new document with an "Updates:" relationship would be more appropriate ways to indicate that the situation has changed.

RFC 8259, "The JavaScript Object Notation (JSON) Data Interchange Format", December 2017

Source of RFC: jsonbis (art)

Errata ID: 6208
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: David Golden
Date Reported: 2020-06-10
Rejected by: Barry Leiba
Date Rejected: 2020-06-10

Section 8.1 says:

In the interests of interoperability, implementations that parse JSON texts MAY ignore the presence of a byte order mark rather than treating it as an error.

It should say:

In the interests of interoperability, implementations that parse JSON texts MAY ignore the presence of a byte order mark or MAY interpret a byte order mark to indicate an alternate encoding rather than treating it as an error.

Notes:

The original line is copied from previous RFCs that specifically allowed alternate encodings. In the context of a new, UTF-8 only restriction, interoperability provisions should also address interpreting legacy formats that predate the restriction. By omission, readers may conclude that the *only* option for a BOM is to ignore or error.
--VERIFIER NOTES--
This is asking to revisit what we have consensus on, not a report of an error in the RFC.
The working group had extensive discussions on BOMs, and chose this particular working purposefully.

Errata ID: 7307
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Maxim Iurie
Date Reported: 2023-01-13
Rejected by: Francesca Palombini
Date Rejected: 2023-01-18

Section 3 says:

      null  = %x6e.75.6c.6c      ; null 

It should say:

      null  = %x6e.75.6c.6c      ; null without quotation marks for numeric attributes and "null" for string attributes.

Notes:

It is not clear how to encode null values in JSON.
Some are encoding all attributes as "null".
Some are encoding all attributes as null without quotation marks
Some are encoding string attributes as "null" and numeric attributes as null without quotation marks.
https://json.org is mentioning "null". ECMA 262 is mentioning "null" for string and +0F for numeric attributes. However providing zero for a number instead of null is incorrect and provides wrong results (in BI).
--VERIFIER NOTES--
The original specification is clear as such, and this errata would make a change that breaks the format, and is against the original intent of the text.

RFC 8280, "Research into Human Rights Protocol Considerations", October 2017

Source of RFC: IRTF

Errata ID: 5306
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Florian Schmaus
Date Reported: 2018-03-26
Rejected by: Allison Mankin (IRTF Chair)
Date Rejected: 2018-08-20

Section 5.2.3.4.1. says:

Likewise, user invisibility so that communication can
occur while users don't notify all buddies and other servers of their
availability is not part of the formal protocol and has only been
added as an extension within the XML stream rather than enforced by
the protocol.

Notes:

The sentence is not correct and thus misleading. XMPP imposes no restriction on communication depending on your own presence status. It is perfectly fine to communicate with someone *without* notifying "all buddies and other servers" of your availability.
--VERIFIER NOTES--
The RFC's editors concluded that accepting the erratum would not add value. IRTF Chair agrees.

Errata ID: 5307
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Florian Schmaus
Date Reported: 2018-03-26
Rejected by: Allison Mankin (IRTF Chair)
Date Rejected: 2018-08-20

Section 5.2.3.4.1. says:

While the
protocol does not specify that the resource must be exposed by the
client's server to remote users, in practice this has become the
default behavior.

Notes:

The sentence is incorrect. The resource is exposed to the remote user in standard 1:1 chats, since servers are required to stamp the 'from' value with the full JID as per RFC 6120 § 8.1.2.1 (stanza-attribute-from-stamp conformance requirement).
Note that the situation is different in groupchats: The resource is not required to be exposed, but when MUC is used, the presence in the channel also reveals the overall presence of the user. This is however, likely to change with future MUC replacement protocols.
I'd also like to point out that RFC 6120 § 13.10.2. and RFC 6121 § 11. discuss the security considerations and provide guidance in order to prevent those leaks
--VERIFIER NOTES--
The RFC's editors concluded that accepting the erratum would not add value. IRTF Chair agrees.

RFC 8287, "Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes", December 2017

Note: This RFC has been updated by RFC 8690, RFC 9214

Source of RFC: mpls (rtg)

Errata ID: 5290
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexander ("Sasha") Vainshtein
Date Reported: 2018-03-20
Rejected by: Deborah Brungard
Date Rejected: 2018-06-29

Section 5.1 says:

   The IPv4 IGP-Prefix Segment ID is defined in [SR].  The format is as
   specified below:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         IPv4 Prefix                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Prefix Length  |    Protocol   |         Reserved              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv4 Prefix

      This field carries the IPv4 Prefix to which the Segment ID is
      assigned.  In case of an Anycast Segment ID, this field will carry
      the IPv4 Anycast address.  If the prefix is shorter than 32 bits,
      trailing bits SHOULD be set to zero.

   Prefix Length

      The Prefix Length field is one octet.  It gives the length of the
      prefix in bits (values can be 1-32).

It should say:

   The IPv4 IGP-Prefix Segment ID is defined in [SR]. 
   The sub-TLV length MUST be set to 8, and its format is 
   as specified below:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         IPv4 Prefix                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Prefix Length  |    Protocol   |         Reserved              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv4 Prefix

      This field carries the IPv4 Prefix to which the Segment ID is
      assigned.  In case of an Anycast Segment ID, this field will carry
      the IPv4 Anycast address.  If the prefix is shorter than 32 bits,
      trailing bits SHOULD be set to zero.

   Prefix Length

      The Prefix Length field is one octet.  
      It gives the length of the
      prefix in bits (values can be 1-32).

Notes:

The RFC in its current form does not explicitly specify the length of the sub-TLV for the IPv4 IGP-Prefix Segment ID, while the format includes a reserved (MBZ) field at the end.
the implementers therefore must guess whether the reserved bits are or are not included in the sub-TLV guess. Such guesses have already caused interoperabilty issues with some implementations including these bits and some not including them.

For comparison, RFC 8029 explicitly specifies length of every sub-TLV it defines. It also never includes MBZ fields at the end of sub-TLVs in the sub-TLV length.

The proposed text is aligned with majority of implementations known to me.

Note also that sub-TLV length is also omitted in section 6.1. However, I am not aware of any actual interoperability issues with this sub-TLV.
--VERIFIER NOTES--
This change requires an update to the RFC, requires consensus.

RFC 8303, "On the Usage of Transport Features Provided by IETF Transport Protocols", February 2018

Source of RFC: taps (wit)

Errata ID: 6391
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2020-12-29
Rejected by: Martin Duke
Date Rejected: 2021-01-19

Section 4.1 says:

   o  GET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS):

      Pass 1 primitive/event: 'Get_TTL' and 'Get_IPV6_Unicast_Hops'

      Returns: IPv4 TTL value or IPv6 Hop Count value

      Comments: this allows an application to read the IPv4 TTL of the
      IPv6 Hop Count value from a received UDP(-Lite) datagram.

It should say:

   o  GET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS):

      Pass 1 primitive/event: 'Get_TTL' and 'Get_IPV6_Unicast_Hops'

      Returns: IPv4 TTL value or IPv6 Hop Count value

      Comments: this allows an application to read the IPv4 TTL or the
      IPv6 Hop Count value from a received UDP(-Lite) datagram.

Notes:

typo: of instead or
--VERIFIER NOTES--
Duplicate of 6373

Errata ID: 6374
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2020-12-29
Rejected by: Martin Duke
Date Rejected: 2021-01-19

Section 4.1 says:

   o  GET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS):

      Pass 1 primitive/event: 'Get_TTL' and 'Get_IPV6_Unicast_Hops'

      Returns: IPv4 TTL value or IPv6 Hop Count value

      Comments: this allows an application to read the IPv4 TTL of the
      IPv6 Hop Count value from a received UDP(-Lite) datagram.

It should say:

   o  GET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS):

      Pass 1 primitive/event: 'Get_TTL' and 'Get_IPV6_Unicast_Hops'

      Returns: IPv4 TTL value or IPv6 Hop Count value

      Comments: this allows an application to read the IPv4 TTL or the
      IPv6 Hop Count value from a received UDP(-Lite) datagram.

Notes:

typo: of instead or
--VERIFIER NOTES--
duplicate of 6373

Errata ID: 6390
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2020-12-29
Rejected by: Martin Duke
Date Rejected: 2021-01-19

Section 4.1 says:

   o  GET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS):

      Pass 1 primitive/event: 'Get_TTL' and 'Get_IPV6_Unicast_Hops'

      Returns: IPv4 TTL value or IPv6 Hop Count value

      Comments: this allows an application to read the IPv4 TTL of the
      IPv6 Hop Count value from a received UDP(-Lite) datagram.

It should say:

   o  GET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS):

      Pass 1 primitive/event: 'Get_TTL' and 'Get_IPV6_Unicast_Hops'

      Returns: IPv4 TTL value or IPv6 Hop Count value

      Comments: this allows an application to read the IPv4 TTL or the
      IPv6 Hop Count value from a received UDP(-Lite) datagram.

Notes:

typo: of instead or
--VERIFIER NOTES--
duplicate of 6373

Errata ID: 6392
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2020-12-29
Rejected by: Martin Duke
Date Rejected: 2021-01-19

Section 4.1 says:

   o  GET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS):

      Pass 1 primitive/event: 'Get_TTL' and 'Get_IPV6_Unicast_Hops'

      Returns: IPv4 TTL value or IPv6 Hop Count value

      Comments: this allows an application to read the IPv4 TTL of the
      IPv6 Hop Count value from a received UDP(-Lite) datagram.

It should say:

   o  GET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS):

      Pass 1 primitive/event: 'Get_TTL' and 'Get_IPV6_Unicast_Hops'

      Returns: IPv4 TTL value or IPv6 Hop Count value

      Comments: this allows an application to read the IPv4 TTL or the
      IPv6 Hop Count value from a received UDP(-Lite) datagram.

Notes:

typo: of instead or
--VERIFIER NOTES--
duplicate of 6373

Errata ID: 6393
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2020-12-29
Rejected by: Martin Duke
Date Rejected: 2021-01-19

Section 4.1 says:

   o  GET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS):

      Pass 1 primitive/event: 'Get_TTL' and 'Get_IPV6_Unicast_Hops'

      Returns: IPv4 TTL value or IPv6 Hop Count value

      Comments: this allows an application to read the IPv4 TTL of the
      IPv6 Hop Count value from a received UDP(-Lite) datagram.

It should say:

   o  GET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS):

      Pass 1 primitive/event: 'Get_TTL' and 'Get_IPV6_Unicast_Hops'

      Returns: IPv4 TTL value or IPv6 Hop Count value

      Comments: this allows an application to read the IPv4 TTL or the
      IPv6 Hop Count value from a received UDP(-Lite) datagram.

Notes:

typo: of instead or
--VERIFIER NOTES--
duplicate of 6373

Errata ID: 6394
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2020-12-29
Rejected by: Martin Duke
Date Rejected: 2021-01-19

Section 4.1 says:

   o  GET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS):

      Pass 1 primitive/event: 'Get_TTL' and 'Get_IPV6_Unicast_Hops'

      Returns: IPv4 TTL value or IPv6 Hop Count value

      Comments: this allows an application to read the IPv4 TTL of the
      IPv6 Hop Count value from a received UDP(-Lite) datagram.

It should say:

   o  GET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS):

      Pass 1 primitive/event: 'Get_TTL' and 'Get_IPV6_Unicast_Hops'

      Returns: IPv4 TTL value or IPv6 Hop Count value

      Comments: this allows an application to read the IPv4 TTL or the
      IPv6 Hop Count value from a received UDP(-Lite) datagram.

Notes:

typo: of instead or
--VERIFIER NOTES--
Duplicate

Errata ID: 6395
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2020-12-29
Rejected by: Martin Duke
Date Rejected: 2021-01-19

Section 4.1 says:

   o  GET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS):

      Pass 1 primitive/event: 'Get_TTL' and 'Get_IPV6_Unicast_Hops'

      Returns: IPv4 TTL value or IPv6 Hop Count value

      Comments: this allows an application to read the IPv4 TTL of the
      IPv6 Hop Count value from a received UDP(-Lite) datagram.

It should say:

   o  GET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS):

      Pass 1 primitive/event: 'Get_TTL' and 'Get_IPV6_Unicast_Hops'

      Returns: IPv4 TTL value or IPv6 Hop Count value

      Comments: this allows an application to read the IPv4 TTL or the
      IPv6 Hop Count value from a received UDP(-Lite) datagram.

Notes:

typo: of instead or
--VERIFIER NOTES--
duplicate of 6373

Errata ID: 6396
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2020-12-29
Rejected by: Martin Duke
Date Rejected: 2021-01-19

Section 4.1 says:

   o  GET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS):

      Pass 1 primitive/event: 'Get_TTL' and 'Get_IPV6_Unicast_Hops'

      Returns: IPv4 TTL value or IPv6 Hop Count value

      Comments: this allows an application to read the IPv4 TTL of the
      IPv6 Hop Count value from a received UDP(-Lite) datagram.

It should say:

   o  GET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS):

      Pass 1 primitive/event: 'Get_TTL' and 'Get_IPV6_Unicast_Hops'

      Returns: IPv4 TTL value or IPv6 Hop Count value

      Comments: this allows an application to read the IPv4 TTL or the
      IPv6 Hop Count value from a received UDP(-Lite) datagram.

Notes:

typo: of instead or
--VERIFIER NOTES--
duplicate of 6373

Errata ID: 6397
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2020-12-29
Rejected by: Martin Duke
Date Rejected: 2021-01-19

Section 4.1 says:

   o  GET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS):

      Pass 1 primitive/event: 'Get_TTL' and 'Get_IPV6_Unicast_Hops'

      Returns: IPv4 TTL value or IPv6 Hop Count value

      Comments: this allows an application to read the IPv4 TTL of the
      IPv6 Hop Count value from a received UDP(-Lite) datagram.

It should say:

   o  GET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS):

      Pass 1 primitive/event: 'Get_TTL' and 'Get_IPV6_Unicast_Hops'

      Returns: IPv4 TTL value or IPv6 Hop Count value

      Comments: this allows an application to read the IPv4 TTL or the
      IPv6 Hop Count value from a received UDP(-Lite) datagram.

Notes:

typo: of instead or
--VERIFIER NOTES--
duplicate of 6373

Errata ID: 6398
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2020-12-29
Rejected by: Martin Duke
Date Rejected: 2021-01-19

Section 4.1 says:

   o  GET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS):

      Pass 1 primitive/event: 'Get_TTL' and 'Get_IPV6_Unicast_Hops'

      Returns: IPv4 TTL value or IPv6 Hop Count value

      Comments: this allows an application to read the IPv4 TTL of the
      IPv6 Hop Count value from a received UDP(-Lite) datagram.

It should say:

   o  GET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS):

      Pass 1 primitive/event: 'Get_TTL' and 'Get_IPV6_Unicast_Hops'

      Returns: IPv4 TTL value or IPv6 Hop Count value

      Comments: this allows an application to read the IPv4 TTL or the
      IPv6 Hop Count value from a received UDP(-Lite) datagram.

Notes:

typo: of instead or
--VERIFIER NOTES--
duplicate of 6373

Errata ID: 6399
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2020-12-29
Rejected by: Martin Duke
Date Rejected: 2021-01-19

Section 4.1 says:

   o  GET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS):

      Pass 1 primitive/event: 'Get_TTL' and 'Get_IPV6_Unicast_Hops'

      Returns: IPv4 TTL value or IPv6 Hop Count value

      Comments: this allows an application to read the IPv4 TTL of the
      IPv6 Hop Count value from a received UDP(-Lite) datagram.

It should say:

   o  GET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS):

      Pass 1 primitive/event: 'Get_TTL' and 'Get_IPV6_Unicast_Hops'

      Returns: IPv4 TTL value or IPv6 Hop Count value

      Comments: this allows an application to read the IPv4 TTL or the
      IPv6 Hop Count value from a received UDP(-Lite) datagram.

Notes:

typo: of instead or
--VERIFIER NOTES--
duplicate of 6373

Errata ID: 6400
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2020-12-29
Rejected by: Martin Duke
Date Rejected: 2021-01-19

Section 4.1 says:

   o  GET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS):

      Pass 1 primitive/event: 'Get_TTL' and 'Get_IPV6_Unicast_Hops'

      Returns: IPv4 TTL value or IPv6 Hop Count value

      Comments: this allows an application to read the IPv4 TTL of the
      IPv6 Hop Count value from a received UDP(-Lite) datagram.

It should say:

   o  GET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS):

      Pass 1 primitive/event: 'Get_TTL' and 'Get_IPV6_Unicast_Hops'

      Returns: IPv4 TTL value or IPv6 Hop Count value

      Comments: this allows an application to read the IPv4 TTL or the
      IPv6 Hop Count value from a received UDP(-Lite) datagram.

Notes:

typo: of instead or
--VERIFIER NOTES--
duplicate of 6373

RFC 8312, "CUBIC for Fast Long-Distance Networks", February 2018

Note: This RFC has been obsoleted by RFC 9438

Source of RFC: tcpm (wit)

Errata ID: 5907
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Elliott Ecton
Date Reported: 2019-11-14
Rejected by: Mirja Kühlewind
Date Rejected: 2020-03-04

Section 5.1 says:

 +--------+----------+-----------+------------+-----------+----------+
   |   Loss |  Average |   Average |      CUBIC |     CUBIC |    CUBIC |
   | Rate P |    TCP W |   HSTCP W |   (C=0.04) |   (C=0.4) |    (C=4) |
   +--------+----------+-----------+------------+-----------+----------+
   |  10^-2 |       12 |        12 |         12 |        12 |       12 |
   |  10^-3 |       38 |        38 |         38 |        38 |       59 |
   |  10^-4 |      120 |       263 |        120 |       187 |      333 |
   |  10^-5 |      379 |      1795 |        593 |      1054 |     1874 |
   |  10^-6 |     1200 |     12279 |       3332 |      5926 |    10538 |
   |  10^-7 |     3795 |     83981 |      18740 |     33325 |    59261 |
   |  10^-8 |    12000 |    574356 |     105383 |    187400 |   333250 |
   +--------+----------+-----------+------------+-----------+----------+

                                  Table 1

It should say:

 +--------+----------+-----------+------------+-----------+----------+
   |   Loss |  Average |   Average |      CUBIC |     CUBIC |    CUBIC |
   | Rate P |    TCP W |   HSTCP W |   (C=0.04) |   (C=0.4) |    (C=4) |
   +--------+----------+-----------+------------+-----------+----------+
   |  10^-2 |       12 |        12 |          3 |         6 |       11 |
   |  10^-3 |       38 |        38 |         19 |        33 |       59 |
   |  10^-4 |      120 |       263 |        120 |       187 |      333 |
   |  10^-5 |      379 |      1795 |        593 |      1054 |     1874 |
   |  10^-6 |     1200 |     12279 |       3332 |      5926 |    10538 |
   |  10^-7 |     3795 |     83981 |      18740 |     33325 |    59261 |
   |  10^-8 |    12000 |    574356 |     105383 |    187400 |   333250 |
   +--------+----------+-----------+------------+-----------+----------+

                                  Table 1

Notes:

The CUBIC average window sizes for 10^2 and 10^3 are incorrect in the original text using expression 6.
--VERIFIER NOTES--
See Section 4.2. on how Cubic calculates the congestion window in TCP-Friendly Region.

Errata ID: 5909
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Elliott Ecton
Date Reported: 2019-11-14
Rejected by: Mirja Kühlewind
Date Rejected: 2020-03-04

Section 5.1 says:

   +--------+-----------+-----------+------------+-----------+---------+
   |   Loss |   Average |   Average |      CUBIC |     CUBIC |   CUBIC |
   | Rate P |     TCP W |   HSTCP W |   (C=0.04) |   (C=0.4) |   (C=4) |
   +--------+-----------+-----------+------------+-----------+---------+
   |  10^-2 |        12 |        12 |         12 |        12 |      12 |
   |  10^-3 |        38 |        38 |         38 |        38 |      38 |
   |  10^-4 |       120 |       263 |        120 |       120 |     120 |
   |  10^-5 |       379 |      1795 |        379 |       379 |     379 |
   |  10^-6 |      1200 |     12279 |       1200 |      1200 |    1874 |
   |  10^-7 |      3795 |     83981 |       3795 |      5926 |   10538 |
   |  10^-8 |     12000 |    574356 |      18740 |     33325 |   59261 |
   +--------+-----------+-----------+------------+-----------+---------+

                                  Table 2

It should say:

   +--------+-----------+-----------+------------+-----------+---------+
   |   Loss |   Average |   Average |      CUBIC |     CUBIC |   CUBIC |
   | Rate P |     TCP W |   HSTCP W |   (C=0.04) |   (C=0.4) |   (C=4) |
   +--------+-----------+-----------+------------+-----------+---------+
   |  10^-2 |        12 |        12 |          1 |         1 |       2 |
   |  10^-3 |        38 |        38 |          3 |         6 |      11 |
   |  10^-4 |       120 |       263 |         19 |        33 |      59 |
   |  10^-5 |       379 |      1795 |        105 |       187 |     333 |
   |  10^-6 |      1200 |     12279 |        593 |      1054 |    1874 |
   |  10^-7 |      3795 |     83981 |       3332 |      5926 |   10538 |
   |  10^-8 |     12000 |    574356 |      18740 |     33325 |   59261 |
   +--------+-----------+-----------+------------+-----------+---------+

                                  Table 2

Notes:

The average window size for the CUBIC columns were mostly incorrect in table 2. Corrected them using expression 6
--VERIFIER NOTES--
See Section 4.2. on how Cubic calculates the congestion window in TCP-Friendly Region.

RFC 8341, "Network Configuration Access Control Model", March 2018

Source of RFC: netconf (ops)

Errata ID: 6493
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Balazs Lengyel
Date Reported: 2021-03-24
Rejected by: Robert Wilton
Date Rejected: 2021-04-07

Section 3.5.2 says:

All the same rules as an instance-identifier apply,
except that predicates for keys are optional.  If a key
predicate is missing, then the node-instance-identifier
represents all possible server instances for that key.

It should say:

All the same rules as an instance-identifier apply,
except that predicates for keys are optional.  If a key
predicate is missing, then the node-instance-identifier
represents all possible server instances for that key.

Specifying prefixes for the node names is OPTIONAL. If a prefix is not specified the node-instance-identifier represents all possible server instances.

Notes:

For the typedef node-instance-identifier (and the leaf path) it is not clear whether the value should or should not include prefixes?

https://tools.ietf.org/html/rfc7950#section-9.13.2 states
"All node names in an instance-identifier value MUST be qualified with
explicit namespace prefixes"

https://tools.ietf.org/html/rfc7950#section-14 - instance-identifier rule
indicates the prefixes are optional.

Whichever is the correct answer it should be explicitly stated.
If prefixes are optional and we have 2 leaves with the same path except the namespace/prefix I assume both are referenced (effected) by the nacm rule. Correct?

Actually this is a bit misleading also in RFC7950.
--VERIFIER NOTES--
The required behavior is specified via section 9.13.2 of RFC 7950.

The ABNF for instance-identifier in RFC 7950 could be clearer to indicate that explicit prefixes are required, but either way the rules in section 9.13.2 of RFC 7950 for instance identifiers cannot be ignored.

RFC 8349, "A YANG Data Model for Routing Management (NMDA Version)", March 2018

Source of RFC: netmod (ops)

Errata ID: 6251
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Tarek Saad
Date Reported: 2020-08-07
Rejected by: Rob Wilton
Date Rejected: 2020-08-14

Section 7 says:

The RPC "active-route" is used to retrieve the active route in a RIB.
RFC8349 defined two AFIs (v4/v6).

draft-ietf-mpls-base-yang is defining a new RIB AFI for MPLS as per section 3 in RFC8349.

The RPC has a "MUST" statement that all RIBs must augment input
parameters with a leaf named 'destination-address'.

For MPLS RIB, it makes sense to augment with leaf named 'local-label' since MPLS routes are identified by MPLS label.

We ask to make the following change:

OLD:
           action active-route {
             description
               "Return the active RIB route that is used for the
                destination address.

                Address-family-specific modules MUST augment input
                parameters with a leaf named 'destination-address'.";

It should say:

NEW:
           action active-route {
             description
               "Return the active RIB route that is used for the
                destination address.

                Address-family-specific modules MUST augment input
                parameters with a suitable leaf that identifies the route.";

Notes:

--VERIFIER NOTES--
After discussion between the submitter and authors of the RFC it was agreed that the errata should be rejected.

RFC 8355, "Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks", March 2018

Source of RFC: spring (rtg)

Errata ID: 5380
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: James Bensley
Date Reported: 2018-06-06
Rejected by: Martin Vigoureux
Date Rejected: 2018-11-03

Section 3.2 says:

An alternative protection strategy consists in management-free local
   protection that is aimed at providing a repair for the destination
   based on the shortest path to the destination.

It should say:

An alternative protection strategy exists in management-free local
 protection

Notes:

--VERIFIER NOTES--
No justification given to justify the need for the change.

RFC 8365, "A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)", March 2018

Source of RFC: bess (rtg)

Errata ID: 7735
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Gaurav Sinha
Date Reported: 2023-12-19
Rejected by: John Scudder
Date Rejected: 2024-02-12

Section 8.3.1 says:

Since VXLAN and NVGRE encapsulations do not include the ESI label, 
other means of performing the split-horizon filtering function must 
be devised for these encapsulations.

It should say:

The "ESI Label" field, in the "ESI Label" Extended Community, is set 
to all zeros in case of VxLAN encapsulation. Since even though the 
VXLAN and NVGRE encapsulations send the "ESI Label" Extended Community, 
yet they do not set the "ESI label" field in it. Therefore, other means 
of performing the split-horizon filtering function must be devised for 
these encapsulations.

Notes:

It should be mentioned somewhere in this RFC document that the "ESI Label" Extended Community is sent with VxLAN encapsulation too, just like it is used with MPLS, but with the "MPLS Label" field set to all zeros in case of VxLAN.

Otherwise, it gives rise to the unanswered question in mind, about the value of that field, given that there are no labels in VxLAN.
--VERIFIER NOTES--
This change appears to be unneeded in this document, see https://mailarchive.ietf.org/arch/msg/bess/ztIEqCJh23KdAbEaec-zeQBwdSs/

Related (and mentioned in the referenced email thread) rfc7432bis does clarify the situation with the note, "The ESI label value MAY be zero if no split-horizon filtering procedures are required in any of the VLANs of the Ethernet Segment. This is the case in [RFC8214]".

RFC 8375, "Special-Use Domain 'home.arpa.'", May 2018

Source of RFC: homenet (int)

Errata ID: 6378
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kulvinder Matharu
Date Reported: 2021-01-02
Rejected by: Eric Vyncke
Date Rejected: 2021-01-03

Throughout the document, when it says:

"home.arpa."

It should say:

"home.arpa"

Notes:

The domain "home.arpa." is used throughout the document. The domain should, instead, be "home.arpa".
--VERIFIER NOTES--
As discussed over email, RFC 1034 specifies that FQDN should terminate with a dot else it is not a FQDN.

RFC 8402, "Segment Routing Architecture", July 2018

Note: This RFC has been updated by RFC 9256

Source of RFC: spring (rtg)

Errata ID: 7546
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Praveen Kumar
Date Reported: 2023-06-19
Rejected by: James Guichard
Date Rejected: 2023-06-19

Section 1 says:

The active segment is indicated by the Destination Address (DA) of the packet.
The next active segment is indicated by the SegmentsLeft (SL) pointer in the SRH.

It should say:

Not sure of the exact corrected text but I feel SegmentsLeft (SL) pointer denotes the active segment, not the next active segment.

Notes:

SL is the active segment
--VERIFIER NOTES--
I am rejecting this errata as https://www.rfc-editor.org/rfc/rfc8200#section-4.4 says “Number of route segments remaining, i.e., number of explicitly listed intermediate nodes still to be visited before reaching the final destination.”. In my opinion, the existing text for RFC 8402 is accurate based on the quoted text of RFC 8200.

RFC 8407, "Guidelines for Authors and Reviewers of Documents Containing YANG Data Models", October 2018

Note: This RFC has been updated by RFC 8819

Source of RFC: netmod (ops)

Errata ID: 7791
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dale R. Worley
Date Reported: 2024-01-30
Rejected by: RFC Editor
Date Rejected: 2024-02-08

Throughout the document, when it says:

There are two related items.

1) Section 3.7.1 "Security Considerations Section Template" begins

   X.  Security Considerations

   The YANG module specified in this document defines a schema for data
   that is designed to be accessed via network management protocols such
   as NETCONF [RFC6241] or RESTCONF [RFC8040].  The lowest NETCONF layer
   is the secure transport layer, and the mandatory-to-implement secure
   transport is Secure Shell (SSH) [RFC6242].  The lowest RESTCONF layer
   is HTTPS, and the mandatory-to-implement secure transport is TLS
   [RFC8446].

2) RFC 8470 says "the latest approved template (available at
<https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines>)".  But
the template at that URL says "the latest approved template (available
at
http://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines)."

It should say:

1) It would be helpful if the beginning of the template contained a
reference to RFC 8407 to provide a pointer back to where the templated
section of Yang module definitions was instantiated from.  Perhaps
starting the template with "[Instantiated from the template of
[RFC8407] section 3.7.1.]"

2) While the URL given in RFC 8407 works, the URL given in the online
template only goes to a generic page, "Welcome to the IETF Community
Wiki".  Presumably the URL in the online template should be the URL of
that page itself.

Notes:

Item (2) is a straightforward correction. Item (1) is in service to
having better pointers/references in our documents.

--VERIFIER NOTES--
1) The original text is not broken (including the URL). Text enhancements can be considered as part of https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8407bis/.

2) The Secretariat fixed the link.

RFC 8410, "Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure", August 2018

Note: This RFC has been updated by RFC 9295

Source of RFC: curdle (sec)

Errata ID: 5709
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lijun Liao
Date Reported: 2019-04-29
Rejected by: Benjamin Kaduk
Date Rejected: 2019-05-06

Section 10.2 says:

-

It should say:

-

Notes:

The example certificate is a self-signed certificate containing X25519 public key. Unlike standard EC public key, the public key for key exchange is NOT the same as the one for digital signature in curve25519. That means, for the same private key, the public keys for X25519 and for Ed25519 are different. As a result, the public key in the self-signed certificate can NOT be used to verify the signature. In this context, please replace the example certificate by one containing the Ed25519 public key.
--VERIFIER NOTES--
X25519 keys are only capable of key agreement, not signing, so by necessity a self-issued X25519 certificate cannot be self-signed. This document specifies, among other things, how to encode X25519 public keys into X.509 certificates, and so the example is accordingly a self-issued but not self-signed certificate. The issuing certificate has the same subject name but a different key (and key type).

RFC 8427, "Representing DNS Messages in JSON", July 2018

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: art

Errata ID: 5438
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Richard Gibson
Date Reported: 2018-07-24
Rejected by: Barry Leiba
Date Rejected: 2020-11-25

Section 2.3 says:

   o  rdataCNAME - A domain name

   o  rdataDNAME - A domain name

   o  rdataNS - A domain name

   o  rdataPTR - A domain name

   o  rdataTXT - A text value

   In addition, each of the following members has a value that is a
   space-separated string that matches the display format definition in
   the RFC that defines that RDATA type.  It is not expected that every
   receiving application will know how to parse these values.

   rdataCDNSKEY, rdataCDS, rdataCSYNC, rdataDNSKEY, rdataHIP,
   rdataIPSECKEY, rdataKEY, rdataMX, rdataNSEC, rdataNSEC3,
   rdataNSEC3PARAM, rdataOPENPGPKEY, rdataRRSIG, rdataSMIMEA, rdataSPF,
   rdataSRV, rdataSSHFP, rdataTLSA

It should say:

   o  rdataCNAME - A domain name

   o  rdataDNAME - A domain name

   o  rdataNS - A domain name

   o  rdataPTR - A domain name

   In addition, each of the following members has a value that is a
   space-separated string that matches the presentation format
   definition in the RFC that defines that RDATA type.  It is not
   expected that every receiving application will know how to parse
   these values.

   rdataCDNSKEY, rdataCDS, rdataCSYNC, rdataDNSKEY, rdataHIP,
   rdataIPSECKEY, rdataKEY, rdataMX, rdataNSEC, rdataNSEC3,
   rdataNSEC3PARAM, rdataOPENPGPKEY, rdataRRSIG, rdataSMIMEA, rdataSPF,
   rdataSRV, rdataSSHFP, rdataTLSA, rdataTXT

Notes:

"A text value" is insufficiently clear to describe the contents of a TXT record, which consists of "One or more <character-string>s". However, the immediately following description relying upon "display format" (corrected to "presentation format" per RFC 4034 and draft-ietf-dnsop-terminology-bis) _does_ cover it, so rdataTXT should move into the undifferentiated list.
--VERIFIER NOTES--
This is a request for a technical change, and is outside the scope of errata reports.

The change from "matches the display format" to "matches the presentation format" is a reasonable change in an errata report.

Errata ID: 6340
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Felipe Gasper
Date Reported: 2020-11-19
Rejected by: Barry Leiba
Date Rejected: 2020-11-25

Section 2.3 says:

   o  rdataCNAME - A domain name

   o  rdataDNAME - A domain name

   o  rdataNS - A domain name

   o  rdataPTR - A domain name

   o  rdataTXT - A text value

It should say:

   o  rdataCNAME - A domain name

   o  rdataDNAME - A domain name

   o  rdataNS - A domain name

   o  rdataPTR - A domain name

   o  rdataTXT - An array of text values

Notes:

Errata 5438 (https://www.rfc-editor.org/errata/eid5438) correctly notes that “A text value” is an improper definition of TXT records’ data; however, that errata incorrectly states that TXT record values are space-separated. While the individual character-strings in a TXT record may be represented as space-separated in an RFC-1035-style zone file, that’s not germane to the RDATA itself.
--VERIFIER NOTES--
As this report is based on errata report 5438 and that report has been Rejected, this one is also. They are both discussing a technical change to the document, outside the scope of an errata report.

RFC 8439, "ChaCha20 and Poly1305 for IETF Protocols", June 2018

Source of RFC: IRTF

Errata ID: 5675
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Stefan Heiss
Date Reported: 2019-03-25
Rejected by: Colin Perkins
Date Rejected: 2019-04-15

Section 2.5.1 says:

for i=1 upto ceil(msg length in bytes / 16)
   n = le_bytes_to_num(msg[((i-1)*16)..(i*16)] | [0x01])
   a += n
   a = (r * a) % p
   end

It should say:

for i=1 upto floor(msg length in bytes / 16)
   j = min(i*16-1, msg length in bytes - 1)
   n = le_bytes_to_num(msg[((i-1)*16)..j] | [0x01])
   a += n
   a = (r * a) % p
   end

Notes:

Corection for lengths of msg blocks (full blocks are of size 16, NOT 17 and last blocks of size != 16 have to be treated separately).
--VERIFIER NOTES--
Rejected in favour of errata 5689.

RFC 8466, "A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery", October 2018

Source of RFC: l2sm (ops)

Errata ID: 6384
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julian Lucek
Date Reported: 2021-01-08
Rejected by: Robert Wilton
Date Rejected: 2024-01-12

Section 8 says:

identity pbb-evpn {
   base service-type;
    description
      "Provider Backbone Bridge (PBB) service type using
       EVPNs as specified in RFC 7432.";
}

It should say:

identity evpn {
   base service-type;
    description
      "EVPN service type as specified in RFC 7432.";
}

Notes:

The mention of PBB is a mistake, it should be normal (non-PBB) EVPN, given that Section 3.1 lists EVPN and not PBB-EVPN among the supported L2VPN types. However, the reference to RFC 7432 in the original text box above is correct, as that RFC deals with EVPN, not PBB-EVPN.

(n.b. see erratum 5921 that has the "opposite" interpretation, i.e. that pbb-evpn is correct but that the RFC number is wrong)

--VERIFIER NOTES--
I think that this errata report can be regarded as a duplicate of 5922, that I have resolved as "held for document update". Certainly, I don't think that it is possible to infer consensus that the YANG module is wrong by defining pbb-evpn but the accompanying text is correct.

RFC 8519, "YANG Data Model for Network Access Control Lists (ACLs)", March 2019

Source of RFC: netmod (ops)

Errata ID: 5762
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Qin WU
Date Reported: 2019-06-24
Rejected by: Joel Jaeggli
Date Rejected: 2019-09-24

Section 4.1 says:

leaf type {
type acl-type;
description
  "Type of ACL.  Indicates the primary intended
   type of match criteria (e.g., Ethernet, 
   IPv4, IPv6, mixed, etc.) used in the list
   instance.";
}

It should say:

leaf type {
type acl-type;
default "ipv4-acl-type";
description
  "Type of ACL.  Indicates the primary intended
   type of match criteria (e.g., Ethernet, 
   IPv4, IPv6, mixed, etc.) used in the list
   instance.";
}

Notes:

I am wondering why not set default value for acl-type,e.g., set default value as "ipv4-acl-type" otherwise, how to determine which field under which choice will be matched upon and which action should be taken on them if the opetional parameter type under acl list is not set.

Also I want to better understand why acl type is removed from key indexes of access list and keep it as optional parameter under acl list. One case I am thinking in my mind is we add a mixed Ethernet, IPv4, and IPv6 ACL entry when we already have Ethernet ACL entry,IPv4 ACL entry , we don't need to remove existing ethernet entry and existing IPv4 entry in the list ("aces") and create a new entry with mixed ethernet, IPv4, IPv6 ACL, instead, we just add a new identity called mixed-eth-ipv4-ipv6-acl-type and add a new IPv6 entry.
--VERIFIER NOTES--

Mahesh Jethanandani replied:

This errata should be rejected for the following reason.

The whole idea of defining the identities for acl-type was to allow vendors to specify what capabilities their box is capable of supporting and then to specify what capabilities the vendors want to support. As such there is no “default capability" for every vendor. Besides, if a device advertises a mixed-eth-ipv4 feature, it is because it can only support Ethernet and IPv4 ACL combinations, and it cannot support IPv6 ACL matches. You do not add a capability of IPv6 match on the fly. It either has it, or it does not. If it does, advertise mixed-eth-ipv4-ipv6 capability to begin with.

The errata proposes a change to the standard and is not correcting an error in the document. additionaly it not clear why it would be appraise to set a default acl type.

The errata is declined.

RFC 8555, "Automatic Certificate Management Environment (ACME)", March 2019

Source of RFC: acme (sec)

Errata ID: 5771
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Rob Stradling
Date Reported: 2019-07-02
Rejected by: Benjamin Kaduk
Date Rejected: 2019-07-17

Section 7.1.1 says:

Clients access the directory by sending a GET request to the
directory URL.

It should say:

Clients access the directory by sending a GET request to the directory
URL.  Before making a request to any URL from the directory, the client
MUST evaluate whether the directory object is still fresh according to
the Cache-Control header(s) received when that directory object was
accessed.  If no Cache-Control header(s) were received, the client MUST
act as if "Cache-Control: no-cache" was received.  If the directory
object is no longer fresh, the client MUST access the directory again
(by sending another GET request to the directory URL) and then use the
updated directory object.

Notes:

The original text is underspecified, because it doesn't say how long a directory remains valid. A server should be able to update its directory (e.g., to add support for newAuthz, to update the termsOfService URL, etc) without having to worry about clients holding on to stale directory objects.
Whilst in practice many clients tend to re-fetch the server's directory object frequently, I think that it's unwise to leave this to chance.
--VERIFIER NOTES--
WG consensus per the thread including https://mailarchive.ietf.org/arch/msg/acme/I2oeALKJTyCwlMOp1v9BTadahyE is to reject the proposed erratum.

RFC 8572, "Secure Zero Touch Provisioning (SZTP)", April 2019

Source of RFC: netconf (ops)

Errata ID: 6685
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alex Krichevsky
Date Reported: 2021-09-14
Rejected by: Robert Wilton
Date Rejected: 2024-01-12

Section 8.3 says:

   Each URI entry in the bootstrap-server-list is structured as follows:

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
    |       uri-length              |          URI                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+

    * uri-length: 2 octets long; specifies the length of the URI data.
    * URI: URI of the SZTP bootstrap server.

It should say:

Multiple URI entries can be specified in a comma-separated list.

Notes:

Most of DHCP servers can be configured only with ASCII string for options.
--VERIFIER NOTES--
As discussed with the authors on the NETCONF mailing list the intent is to have one URI entry per uri-data entry (containing URI-length and the associated URI). Multiple instances of uri-data entry are permitted.

Errata ID: 6690
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alex Krichevsky
Date Reported: 2021-09-22
Rejected by: Rob Wilton
Date Rejected: 2021-09-22

Section 8.1 says:

   The DHCPv4 server MAY include a single instance of the
   OPTION_V4_SZTP_REDIRECT option in DHCP messages it sends.  Servers
   MUST NOT send more than one instance of the OPTION_V4_SZTP_REDIRECT
   option.

It should say:

The DHCPv4 server MAY include OPTION_V4_SZTP_REDIRECT in DHCP messages it sends.

Notes:

Duplicate of 6684.
--VERIFIER NOTES--
Duplicate of 6684.

Errata ID: 7223
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2022-11-01
Rejected by: Rob Wilton
Date Rejected: 2022-11-02

Section 5.2 says:

    4.  Loop back to Step 1

It should say:

    4.  Loop back to Step 2

Notes:

There is no need to repeat step 1.
--VERIFIER NOTES--
As per Kent's (the author) clarification:

Per the note beneath the diagram and the last paragraph in that section (Section 5.2), alternate config mechanisms MAY be used and they SHOULD unset the "flag enabling SZTP bootstrapping", which is what Step 1 tests.

RFC 8632, "A YANG Data Model for Alarm Management", September 2019

Source of RFC: ccamp (rtg)

Errata ID: 5953
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tetsuya Hasegawa
Date Reported: 2019-12-31
Rejected by: Deborah Brungard
Date Rejected: 2020-07-13

Section 3.5.1. says:

   From a resource perspective, an alarm can, for example, have the
   following lifecycle: raise, change severity, change severity, clear,

It should say:

   From a resource perspective, an alarm can, for example, have the
   following lifecycle: raise, change severity, clear,

Notes:

--VERIFIER NOTES--
Per authors and chairs, the current RFC text is correct as it exemplifies how the severity can change multiple times over the lifecycle of an alarm.

RFC 8639, "Subscription to YANG Notifications", September 2019

Source of RFC: netconf (ops)

Errata ID: 6366
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Muly Ilan
Date Reported: 2020-12-24
Rejected by: RFC Editor
Date Rejected: 2021-01-19

Section 4. says:

  feature subtree {
    description
      "This feature indicates support for YANG subtree filtering.";
    reference
      "RFC 6241: Network Configuration Protocol (NETCONF),
                 Section 6";
  }

  feature supports-vrf {
    description
      "This feature indicates that a publisher supports VRF
       configuration for configured subscriptions.  VRF support for
       dynamic subscriptions does not require this feature.";
    reference
      "RFC 8529: YANG Data Model for Network Instances,
                 Section 6";
  }

It should say:

  feature subtree {
    description
      "This feature indicates support for YANG subtree filtering.";
    reference
      "RFC 6241: Network Configuration Protocol (NETCONF),
                 Section 6";
  }

  feature supports-vrf {
    description
      "This feature indicates that a publisher supports VRF
       configuration for configured subscriptions.  VRF support for
       dynamic subscriptions does not require this feature.";
    reference
      "RFC 8529: YANG Data Model for Network Instances,
                 Section 6";
  }

Notes:

In the HTML version the two hyperlinks "Section 6" (for 'subtree' feature and for 'supports-vrf' feature) point to wrong RFCs.

--VERIFIER NOTES--
This is regarding the link generated in the rfc2html output, not the RFC itself (https://www.rfc-editor.org/rfc/rfc8639.txt).

RFC 8824, "Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)", June 2021

Source of RFC: lpwan (int)

Errata ID: 7391
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF
Reported By: Marco Tiloca
Date Reported: 2023-03-19
Rejected by: Eric Vyncke
Date Rejected: 2023-08-03

Section 5.4 says:

The SCHC Rule description MAY define sending some field values by
setting the TV to "not-sent", the MO to "ignore", and the CDA to
"value-sent".

It should say:

The SCHC Rule description MAY define sending some field values by
describing an empty TV, with the MO set to "ignore" and the CDA set to
"value-sent".

Notes:

The new text indicates to use an empty TV, consistent with the intended CDA "value-sent".
--VERIFIER NOTES--
The WG/author wrote:
"As you can see 'not set' has been transformed into 'not-sent' during
the edition. And I prefer to use this terminology that corresponds to
the RFC8724."
in https://mailarchive.ietf.org/arch/msg/lp-wan/Vw5P6i0DysYqxClBj-gUjMEmqWY/

Errata ID: 7392
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF
Reported By: Marco Tiloca
Date Reported: 2023-03-19
Rejected by: Eric Vyncke
Date Rejected: 2023-08-03

Section 6.2 says:

Since the Observe Option MAY use a RST message to inform a server
that the client does not require the Observe response, a specific
SCHC Rule SHOULD exist to allow the message's compression with the
RST type.

It should say:

Since the Observe extension MAY use a RST message to inform a server
that the client does not require the Observe response, a specific
SCHC Rule SHOULD exist to allow the message's compression with the
RST type.

Notes:

A RST message is not used by the Observe option itself, but by a CoAP client when using Observe.
--VERIFIER NOTES--
The authors wrote:
"[Ana] as soon as I understand CoAP RFC7252 uses Options, and in the
RFC7641 Observe is also an Option, so I don't think that the change is
needed. Because Observe is not an extension."
in https://mailarchive.ietf.org/arch/msg/lp-wan/amZkZfocq1SQCpFPNJzoxn3TMsY/

Errata ID: 7394
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF
Reported By: Marco Tiloca
Date Reported: 2023-03-19
Rejected by: Eric Vyncke
Date Rejected: 2023-08-03

Section 7.1 says:

equal 1

It should say:

equal

Notes:

See the cell value of Table 3, last row, column "MO".
--VERIFIER NOTES--
Per the WG/author in https://mailarchive.ietf.org/arch/msg/lp-wan/ZVVEzAILvuGbudfpLhNp2xJuBDc/

Errata ID: 7395
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF
Reported By: Marco Tiloca
Date Reported: 2023-03-19
Rejected by: Eric Vyncke
Date Rejected: 2023-08-03

Section 7.1 says:

SCHC compression reduces the header, sending only the Type, a mapped
code, and the least significant bits of the Message ID (9 bits in the
example above).

It should say:

SCHC compression reduces the header, sending only a mapped Type (and
only for uplink messages), a mapped code, and the least significant
bits of the Message ID (9 bits in the example above).

Notes:

As per the discussed rule from Table 3, the Type is also omitted if it is CON for downlink messages.
--VERIFIER NOTES--
The author/WG wrote:
"In this case we are making a difference between the index of the
matching-list sent in Type and the mapped index used for Code that belongs
to the RFC7252 section 12.1 IANA values."
in https://mailarchive.ietf.org/arch/msg/lp-wan/s7EO2F4JUPHUyFLc3Qr-5RnwNZE/

RFC 8877, "Guidelines for Defining Packet Timestamps", September 2020

Source of RFC: ntp (int)

Errata ID: 7012
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Nikolai Malykh
Date Reported: 2022-07-04
Rejected by: Erik Kline
Date Rejected: 2022-07-27

Section 4.2.1 says:

   Wraparound:
      This time format wraps around every 2^(32) seconds, which is
      roughly 136 years.  The next wraparound will occur in the year
      2036.

It should say:

   Wraparound:
      This time format wraps around every 2^(32) seconds, which is
      roughly 136 years.  The next wraparound will occur in the year
      2106.

Notes:

1970+136=2106, not 2036
--VERIFIER NOTES--
The Epoch starts from 1900, not 1970.

RFC 8890, "The Internet is for End Users", August 2020

Source of RFC: IAB

Errata ID: 6817
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: John Hickinbottom
Date Reported: 2022-01-13
Rejected by: RFC Editor
Date Rejected: 2022-04-06

Section 1, 4.3 says:

such as (but not limited to) end users, network ...

including (but not limited to) [RFC7754] on filtering, [RFC7258] ...

It should say:

such as end users, network ...

including [RFC7754] on filtering, [RFC7258] ...

Notes:

Remove redundant, faux legalese "(but not limited to)". Nothing about "such as" and "including" indicates that the following list of examples are exhaustive: just that they are members of a set.
--VERIFIER NOTES--
This is not a correction and it does not affect the readability of the document.

RFC 8912, "Initial Performance Metrics Registry Entries", November 2021

Source of RFC: ippm (ops)

Errata ID: 6762
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Nikolai Malykh
Date Reported: 2021-11-30
Rejected by: Martin Duke
Date Rejected: 2021-11-30

Section 10.1.4 says:

   RTLoss:  This metric assesses the estimated loss count for TCP
      packets constituting a single connection, exchanged between two
      hosts.  We consider the measurement of round-trip delay based on a
      single OP [RFC7011] somewhere in the network.  The output is the
      estimated loss count for the measurement interval.

It should say:

   RTLoss:  This metric assesses the estimated loss count for TCP
      packets constituting a single connection, exchanged between two
      hosts.  We consider the measurement of loss count based on a
      single OP [RFC7011] somewhere in the network.  The output is the
      estimated loss count for the measurement interval.

Notes:

This is where loss count is measured, not round-trip delay.
--VERIFIER NOTES--
From Al Morton: Sorry, but the original text is correct. In this case we have a RT loss *estimate* conducted in the context of (and using the same packets as) the RT Delay measurements described for TCP. We considered this text carefully before publication.

RFC 8913, "Two-Way Active Measurement Protocol (TWAMP) YANG Data Model", November 2021

Source of RFC: ippm (ops)

Errata ID: 6751
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2021-11-23
Rejected by: RFC Editor
Date Rejected: 2024-03-21

Section 5.1 says:

   Please note that the backslash ('\') character near the end of the
   diagram is used for formatting purposes only (i.e.,
   "reflector-udp-port]" should be treated as part of the same line as
   "[sender-ip sender-udp-port reflector-ip").

It should say:

   Please note that the backslash ('\') character near the end of the
   diagram is used for formatting purposes only (i.e.,
   "reflector-udp-port]" should be treated as part of the same line as
   "[sender-ip sender-udp-port reflector-ip]").

Notes:

Omitted character ']' at the end of a sentence.
--VERIFIER NOTES--
The original is correct. It explains how the following entry was broken across two lines due to line-length constraints:

+--ro test-session*
[sender-ip sender-udp-port reflector-ip \
reflector-udp-port]

RFC 8919, "IS-IS Application-Specific Link Attributes", October 2020

Note: This RFC has been obsoleted by RFC 9479

Source of RFC: lsr (rtg)

Errata ID: 6630
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Les Ginsberg
Date Reported: 2021-07-05
Rejected by: John Scudder
Date Rejected: 2022-05-14

Throughout the document, when it says:

Section 4.2:
OLD

If the SABM or UDABM Length in the Application Identifier Bit Mask
is greater than 8, the entire sub-TLV MUST be ignored.

(Later in Section 4.2)
OLD

If link attributes are advertised associated with zero-length
Application Identifier Bit Masks for both standard applications and
user-defined applications, then any standard application and/or any
user-defined application is permitted to use that set of link
attributes so long as there is not another set of attributes
advertised on that same link that is associated with a non-zero-length
Application Identifier Bit Mask with a matching Application Identifier
Bit set.

Section 6.2
OLD

Link attribute advertisements associated with zero-length Application
Identifier Bit Masks for both standard applications and user-defined
applications are usable by any application, subject to the
restrictions specified in Section 4.2. If support for a new
application is introduced on any node in a network in the presence
of such advertisements, these advertisements are permitted to
be used by the new application. If this is not what is intended,
then existing advertisements MUST be readvertised with an explicit
set of applications specified before a new application is introduced.

It should say:

Section 4.2
NEW

If the SABM or UDABM Length in the Application Identifier Bit Mask
is greater than 8, the entire sub-TLV MUST be ignored.

When SABM or UDABM Length is non-zero and the L-flag is NOT set, all
applications specified in the bit mask MUST use the link attribute
advertisements in the sub-TLV.

(Later in Section 4.2)
NEW

Link attributes MAY be advertised associated with zero-length
Application Identifier Bit Masks for both standard applications and
user-defined applications. Such link attribute advertisements MUST be
used by standard applications and/or user defined applications when
no link attribute advertisements with a non-zero-length Application
Identifier Bit Mask and a matching Application Identifier Bit set are
present for a given link. Otherwise, such link attribute advertisements
MUST NOT be used.

Section 6.2
NEW

Link attributes MAY be advertised associated with zero-length
Application Identifier Bit Masks for both standard applications and
user-defined applications. Such link attribute advertisements MUST be
used by standard applications and/or user defined applications when
no link attribute advertisements with a non-zero-length Application
Identifier Bit Mask and a matching Application Identifier Bit set are
present for a given link. Otherwise, such link attribute advertisements
MUST NOT be used.

Notes:

RFC 8919 defines advertising link attributes with zero
length Standard Application Bit Mask (SABM) and zero length User
Defined ApplicationBit Mask (UDABM) as a means of advertising link
attributes that can be used by any application. However, the text uses
the word "permitted", suggesting that the use of such advertisements
is "optional". Such an interpretation could lead to interoperability
issues and is not what was intended.

The replacement text below makes explicit the specific conditions when
such advertisements MUST be used and the specific conditions under
which they MUST NOT be used.
--VERIFIER NOTES--
It would be more appropriate to pursue this as an update or bis RFC, see discussion at https://mailarchive.ietf.org/arch/msg/lsr/_15rAwElfpGLDRxqjUuUJHiGdrQ/

RFC 8920, "OSPF Application-Specific Link Attributes", October 2020

Note: This RFC has been obsoleted by RFC 9492

Source of RFC: lsr (rtg)

Errata ID: 6631
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Les Ginsberg
Date Reported: 2021-07-05
Rejected by: John Scudder
Date Rejected: 2022-05-14

Section 5 says:

OLD

If link attributes are advertised with zero-length Application
Identifier Bit Masks for both standard applications and user-defined
applications, then any standard application and/or any user-defined
application is permitted to use that set of link attributes. If
support for a new application is introduced on any node in a network
in the presence of such advertisements, these advertisements are
permitted to be used by the new application. If this is not what is
intended, then existing advertisements MUST be readvertised with an
explicit set of applications specified before a new application is
introduced.

An application-specific advertisement (Application Identifier Bit Mask
with a matching Application Identifier Bit set) for an attribute MUST
always be preferred over the advertisement of the same attribute with
the zero-length Application Identifier Bit Masks for both standard
applications and user-defined applications on the same link.

It should say:

NEW

Link attributes MAY be advertised associated with zero-length
Application Identifier Bit Masks for both standard applications
and user-defined applications. Such link attribute advertisements
MUST be used by standard applications and/or user defined applications
when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier
Bit set are present for a given link. Otherwise, such link attribute
advertisements MUST NOT be used.

Notes:

RFC 8920 defines advertising link attributes with zero
length Standard Application Bit Mask (SABM) and zero length User
Defined ApplicationBit Mask (UDABM) as a means of advertising link
attributes that can be used by any application. However, the text uses
the word "permitted", suggesting that the use of such advertisements
is "optional". Such an interpretation could lead to interoperability
issues and is not what was intended.

The replacement text below makes explicit the specific conditions when
such advertisements MUST be used and the specific conditions under
which they MUST NOT be used.
--VERIFIER NOTES--
It would be more appropriate to pursue this as an update or bis RFC. See discussion at https://mailarchive.ietf.org/arch/msg/lsr/Ux9x1Zz9R8p7aZ_7iu1jjU-88E0/
and https://mailarchive.ietf.org/arch/msg/lsr/_15rAwElfpGLDRxqjUuUJHiGdrQ/

RFC 9001, "Using TLS to Secure QUIC", May 2021

Source of RFC: quic (wit)

Errata ID: 7785
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Tom Pearson
Date Reported: 2024-01-26
Rejected by: Zaheduzzaman Sarker
Date Rejected: 2024-01-29

Section 5. says:

The key and IV for the packet are computed as described in
Section 5.1.  The nonce, N, is formed by combining the packet
protection IV with the packet number.  The 62 bits of the
reconstructed QUIC packet number in network byte order are left-
padded with zeros to the size of the IV.  The exclusive OR of the
padded packet number and the IV forms the AEAD nonce.

It should say:

The key and IV for the packet are computed as described in
Section 5.1.  The nonce, N, is formed by combining the packet
protection IV with the packet number.  The 32 bits of the
reconstructed QUIC packet number in network byte order are left-
padded with zeros to the size of the IV.  The exclusive OR of the
padded packet number and the IV forms the AEAD nonce.

Notes:

Given the description of packet number reconstruction in RFC9000 section 17.1 and the example in RFC9000 Appendix A3, the length of reconstructed packet number should be 32 bits, not 62 bits.
--VERIFIER NOTES--
The full packet number is 62 bits, although it is never expressed as such in the packet number field of the header. Hence, this errata is rejected.

RFC 9067, "A YANG Data Model for Routing Policy", October 2021

Source of RFC: rtgwg (rtg)

Errata ID: 6845
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Kris Lambrechts
Date Reported: 2022-02-10
Rejected by: Alvaro Retana
Date Rejected: 2022-02-11

Section 7.2. says:

               list prefix-list {
                 key "ip-prefix mask-length-lower mask-length-upper";
                 description
                   "List of prefixes in the prefix set.";
                 uses prefix;
               }

It should say:

               list prefix {
                 key "ip-prefix mask-length-lower mask-length-upper";
                 description
                   "List of prefixes in the prefix set.";
                 uses prefix;
               }

Notes:

The name of this list is not natural and makes instance data hard to read. This is very apparent in the example in Appendix B. Policy Examples
--VERIFIER NOTES--
From the WG discussion: "This is a rather subjective comment since at this YANG data node is, in fact, a list. Also, it is a moot point since changing this would be a non-backward compatible YANG change."

RFC 9073, "Event Publishing Extensions to iCalendar", August 2021

Source of RFC: calext (art)

Errata ID: 7380
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Olaf Bartelt
Date Reported: 2023-03-09
Rejected by: Francesca Palombini
Date Rejected: 2023-11-09

Section 4 says:

The following changes to the syntax defined in iCalendar [RFC5545]
   are made here.  New elements are defined in subsequent sections.

   ; Addition of PARTICIPANT, VLOCATION, and VRESOURCE
   ; as valid components
   eventc     = "BEGIN" ":" "VEVENT" CRLF
                eventprop *alarmc *participantc *locationc *resourcec
                "END" ":" "VEVENT" CRLF

   ; Addition of properties STYLED-DESCRIPTION and STRUCTURED-DATA
   eventprop  =/ *styleddescription
                 *sdataprop

   ; Addition of PARTICIPANT, VLOCATION, and VRESOURCE
   ; as valid components
   todoc      = "BEGIN" ":" "VTODO" CRLF
                todoprop *alarmc *participantc *locationc *resourcec
                "END" ":" "VTODO" CRLF

   ; Addition of properties STYLED-DESCRIPTION and STRUCTURED-DATA
   todoprop =/ *styleddescription
               *sdataprop

   ; Addition of PARTICIPANT, VLOCATION, and VRESOURCE
   ; as valid components
   journalc   = "BEGIN" ":" "VJOURNAL" CRLF
                jourprop *participantc *locationc *resourcec
                "END" ":" "VJOURNAL" CRLF

   ; Addition of properties STYLED-DESCRIPTION and STRUCTURED-DATA
   jourprop =/ *styleddescription
               *sdataprop

   ; Addition of PARTICIPANT, VLOCATION, and VRESOURCE
   ; as valid components
   freebusyc  = "BEGIN" ":" "VFREEBUSY" CRLF
                fbprop *participantc *locationc *resourcec
                "END" ":" "VFREEBUSY" CRLF

   ; Addition of property STYLED-DESCRIPTION
   fbprop     =/ *styleddescription

It should say:

The following changes to the syntax defined in iCalendar [RFC5545]
   are made here.  New elements are defined in subsequent sections.

   ; Addition of PARTICIPANT, VLOCATION, and VRESOURCE
   ; as valid components
   eventc     = "BEGIN" ":" "VEVENT" CRLF
                eventprop *alarmc *participantc *locationc *resourcec
                "END" ":" "VEVENT" CRLF

   ; Addition of properties STYLED-DESCRIPTION and STRUCTURED-DATA
   eventprop  =/ *styleddescription
                 *sdataprop

   ; Addition of PARTICIPANT, VLOCATION, and VRESOURCE
   ; as valid components
   todoc      = "BEGIN" ":" "VTODO" CRLF
                todoprop *alarmc *participantc *locationc *resourcec
                "END" ":" "VTODO" CRLF

   ; Addition of properties STYLED-DESCRIPTION and STRUCTURED-DATA
   todoprop =/ *styleddescription
               *sdataprop

   ; Addition of PARTICIPANT, VLOCATION, and VRESOURCE
   ; as valid components
   journalc   = "BEGIN" ":" "VJOURNAL" CRLF
                jourprop *participantc *locationc *resourcec
                "END" ":" "VJOURNAL" CRLF

   ; Addition of properties STYLED-DESCRIPTION and STRUCTURED-DATA
   jourprop =/ *styleddescription
               *sdataprop

   ; Addition of PARTICIPANT, VLOCATION, and VRESOURCE
   ; as valid components
   freebusyc  = "BEGIN" ":" "VFREEBUSY" CRLF
                fbprop *participantc *locationc *resourcec
                "END" ":" "VFREEBUSY" CRLF

   ; Addition of property STYLED-DESCRIPTION
   fbprop     =/ *styleddescription

   ; Addition of property STYLED-DESCRIPTION
   alarmprop  =/ *styleddescription

Notes:

The usage of STYLED-DESCRIPTION in VALARMs is mentioned in section 6.5, but not represented as an extension to the syntax in section 4.
--VERIFIER NOTES--
See https://mailarchive.ietf.org/arch/msg/calsify/HmJBbZpxrvLqn2TR3HkBr9um08s/ for wg discussion.

RFC 9110, "HTTP Semantics", June 2022

Source of RFC: httpbis (wit)

Errata ID: 7107
Status: Rejected
Type: Technical
Publication Format(s) : HTML
Reported By: James Synge
Date Reported: 2022-08-31
Rejected by: RFC Editor
Date Rejected: 2022-10-12

Section 6.5.1 says:

For example, the chunked transfer coding in HTTP/1.1
allows a trailer section to be sent after the content
(Section 7.1.2 of [HTTP/1.1]).

It should say:

For example, the chunked transfer coding in HTTP/1.1
allows a trailer section to be sent after the content
(Section ?.?.? of [HTTP/1.1]).

Notes:

Section 7.1.2 does not exist. It isn't clear to me which section is the intended target of the reference.
--VERIFIER NOTES--
Errata rejected per Julian Reschke. Section 7.1.2 does exist.
See <https://www.rfc-editor.org/rfc/rfc9112#section-7.1.2>.

Errata ID: 7599
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Justine Krejcha
Date Reported: 2023-08-11
Rejected by: Francesca Palombini
Date Rejected: 2023-10-23

Section 6.4.1 says:

All 1xx (Informational), 204 (No Content), and 304 (Not Modified)
responses do not include content.

All other responses do include content, although that content might
be of zero length.

It should say:

All 1xx (Informational), 204 (No Content), 205 (Reset Content), 
and 304 (Not Modified) responses do not include content.

All other responses do include content, although that content might
be of zero length.

Notes:

Per section 15.3.6 (205 No Content), it says that servers MUST NOT generate a response. Section 6.4.1 says that "All 1xx, 204, and 304 response don't include content and others do." even though 205 response mustn't generate content.
--VERIFIER NOTES--
In rejecting this Errata report I note that the reported text is not an error, but a deliberate decision of the authors and working group.

Errata ID: 7530
Status: Rejected
Type: Editorial
Publication Format(s) : HTML
Reported By: Philippe Cloutier
Date Reported: 2023-05-29
Rejected by: RFC Editor
Date Rejected: 2023-07-07

Section 15.5.2. says:

The 401 (Unauthorized) status code indicates that the request has not
been applied because it lacks valid authentication credentials for
the target resource.

It should say:

The 401 (Unauthorized) status code indicates that the request has not
been processed because it lacks valid authentication credentials for
the target resource.

Notes:

"applying a request" is not a standard expression. Usually, requests are "treated", "granted" or "processed".

This phrasing was imported in Apache Tomcat; thanks to Mark Thomas for pointing out it came from this RFC.
--VERIFIER NOTES--
A method is applied to a resource to have an effect that results in a response. Any web search on "method applied" will show you that it is quite common in standard English. The request has already been processed, at least partially, in order to make a decision that resulted in a 401 error

RFC 9111, "HTTP Caching", June 2022

Source of RFC: httpbis (wit)

Errata ID: 7695
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, HTML
Reported By: Dron Rathore
Date Reported: 2023-11-07
Rejected by: Francesca Palombini
Date Rejected: 2024-01-16

Section 4.3.2 says:

   The proper evaluation of conditional requests by a cache depends on
   the received precondition header fields and their precedence.  In
   summary, the If-Match and If-Unmodified-Since conditional header
   fields are not applicable to a cache, and If-None-Match takes
   precedence over If-Modified-Since.  See Section 13.2.2 of [HTTP] for
   a complete specification of precondition precedence.

It should say:

   The proper evaluation of conditional requests by a cache depends on
   the received precondition header fields and their precedence.  In
   summary, the If-Match and If-Unmodified-Since conditional header
   fields are not applicable to a cache and hence such requests MUST
   be forwarded to the origin, and If-None-Match takes precedence
   over If-Modified-Since.  See Section 13.2.2 of [HTTP] for a complete
   specification of precondition precedence.

Notes:

Correction:
"the If-Match and If-Unmodified-Since conditional header fields are not applicable
to a cache [and hence such requests MUST be forwarded to the origin]"

This is based upon the reading of RFC 9111#section-4.3.2-3[1]:

A cache MUST NOT evaluate conditional header fields that only apply
to an origin server, occur in a request with semantics that cannot be
satisfied with a cached response, or occur in a request with a target
resource for which it has no stored responses; such preconditions are
likely intended for some other (inbound) server.


Current RFC 9110#section-13.1.1-13[2], RFC 9110#section-13.2.2[3] and RFC
9111#section-4.3.2-4[4] does not explicitly provide clear direction to cache servers as to
how to deal with If-Match and If-Unmodified-Since conditional headers[5].

The correction intends to provide more clarity for If-Match and If-Unmodified-Since
header as to how a cache server should handle conditional header which are meant
for origin server based on the reading of above produced section of
the RFC 9111#section-4.3.2-3.

If cache nodes have to ignore If-Match and If-Unmodified-Since header as per
RFC 9110#section-13.1.1-13 then in scenarios where they have a cached non-expired
content representation which can be satisfied sans If-Match and If-Unmodified-Since
headers the same will be returned back by cache and intermediary servers.

Caching layers with multiple content representation cached in the network may
return invalid response back causing higher requests errors when dealing with origin
applicable conditional headers that are sent to intermediary cache nodes from
edge cache nodes for cache hydration.

Consider the below scenario:

1. A caching system consisting of 2 cache layers with 3 servers each,
Server nodes "A" representing Edge cache nodes(A1, A2, A3),
Server nodes "B" representing intermediary cache nodes(B1, B2, B3), and an
origin server

2. All cache servers (A and B) make use of If-Match and If-Unmodified-Since to
hydrate their own cached content representation as per RFC 9110#section-13.1.1-12 [6]

3. All cache servers make use of 5MiB chunk ranges for cache hydration of large
files

4. Origin server contains a file foo with size 20MiB, with content
representation Etag E1

5. A client C1 who sends a range request for file foo with range 10-20MiB to edge node A1

6. For initial set of requests sent by edge node A1 the representation E1 gets
cached on 2 of the intermediary nodes B1 and B2 (because of 2 requests for
5MiB chunk each)

6. Content representation for file foo changes to Etag E2 on origin

7. A client C2 who sends a range request for file foo with range 10-20MiB to edge node A2

8. Requests to edge node A2 which does not have a cached representation causes it
to send 2 range requests for 5MiB each, in this case lets assume it is sent to
intermediary cache nodes B1(range:10-15MiB) and B3(range:15-20MiB),
B3 node faces cache-miss and hydrates its own cache from Range 15Mib-20MiB
with content representation E2. B1 node already has a cached representation E1
for requested range so it returns it back. A2 node which has now cached 10-15MiB E1
representation received from B1 has to returns error and performs a cache reset for
itself because of mixed representation for the whole user requested range.

In such a case where intermediary cache severs/nodes may end up with multiple
content representation an edge node who is trying to hydrate its own cache
will find it hard to do so, i.e. the first 5MiB
chunk may end up being served by intermediary cache nodes with representation
E1 and the other half of the chunk by nodes who have a content representation
E2. The error rates will be higher whenever content representation changes at
the origin server for such range requests.


[1]: https://www.rfc-editor.org/rfc/rfc9111#section-4.3.2-3
[2]: https://www.rfc-editor.org/rfc/rfc9110#section-13.1.1-13
[3]: https://www.rfc-editor.org/rfc/rfc9110#section-13.2.2
[4]: https://www.rfc-editor.org/rfc/rfc9111#section-4.3.2-4
[5]: https://github.com/httpwg/http-core/issues/1111
[6]: https://www.rfc-editor.org/rfc/rfc9110#section-13.1.1-12
--VERIFIER NOTES--
The suggestion is not a desired solution for the problematic text.

This part is not an error in the specification. Even when If-Match and If-Unmodified-Since are not applicable to a cache, their presence does not imply that the request must be forwarded to the origin. It will depend on other factors in the request and how/where the cache has been configured.

See https://mailarchive.ietf.org/arch/msg/httpbisa/k8UTKPDMQQZ-H5sHyJb7dldew7I/ for details.

RFC 9112, "HTTP/1.1", June 2022

Source of RFC: httpbis (wit)

Errata ID: 7214
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Niklas Wolber
Date Reported: 2022-10-31
Rejected by: Francesca Palombini
Date Rejected: 2022-11-09

Section 1.2 says:

The following core rules are included by reference, as defined in
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line
feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any
visible [USASCII] character).

It should say:

The following core rules are included by reference, as defined in
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
HEXDIG (hexadecimal 0-9/A-F), HTAB (horizontal tab), LF (line
feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any
visible [USASCII] character).

Notes:

Rule HEXDIG from RFC5234 is
HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
excluding lower-case letters.
--VERIFIER NOTES--
RFC 5234 section 2.3 says: ABNF strings are case insensitive and the character set for these strings is US-ASCII.

Errata ID: 7633
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Amos Jeffries
Date Reported: 2023-09-06
Rejected by: Francesca Palombini
Date Rejected: 2023-11-07

Section 2.2 says:

   Although the line terminator for the start-line and fields is the
   sequence CRLF, a recipient MAY recognize a single LF as a line
   terminator and ignore any preceding CR.

It should say:

   Although the line terminator for the start-line, fields, chunk
   and last-chunk is the sequence CRLF, a recipient MAY recognize
   a single LF as a line terminator and ignore any preceding CR.

Notes:

chunked encoding (section 6.3) uses CRLF for line/framing delimiters in the same manner as other HTTP message sections. But these lines are not listed as a possible sites of bare-LF line terminator. Which makes for an unnecessary parser exception and complicates possible request smuggling robustness between implementations.
--VERIFIER NOTES--
The difference was intentional. A chunked parser is not a start line or field parser (it is a message body parser) and it is supposed to be less forgiving because it does not have to retain backwards compatibility with 1.0 parsers.

Hence, bare LF around the chunk sizes would be invalid and should result in the connection being marked as invalid.

In any case, suggestions to further hardening of the chunked parser would have to be defined in that section, and would need to be achieved through a consensus document, not in an errata report.

RFC 9135, "Integrated Routing and Bridging in Ethernet VPN (EVPN)", October 2021

Source of RFC: bess (rtg)

Errata ID: 7686
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Denis Vrkic
Date Reported: 2023-10-20
Rejected by: John Scudder
Date Rejected: 2024-02-12

Section 6.1 says:

6.1.  Control Plane - Advertising PE

   When a PE (e.g., PE1 in Figure 4 above) learns the MAC and IP address
   of an attached TS (e.g., via an ARP request or ND Neighbor
   Solicitation), it populates its MAC-VRF/BT, IP-VRF, and ARP table or
   NDP cache just as in the case for symmetric IRB.

It should say:

6.1.  Control Plane - Advertising PE

   When a PE (e.g., PE1 in Figure 4 above) learns the MAC and IP address
   of an attached TS (e.g., via an ARP request or ND Neighbor
   Solicitation), it populates its MAC-VRF/BT and ARP table or
   NDP cache.

Notes:

- advertising PE (egress PE) is not advertising Label2 ("the MPLS Label2 field MUST NOT be included in this route.")
- so this must be asymmetric egress PE
- in 4.2 is stated that: "the asymmetric IRB mode simplifies the forwarding model
and saves space in the IP-VRF route table, since host routes are not installed in the route table."
- so i guess that, advertising PE in asymmetric mode, is NOT leaning/storing local IP to IP-VRF table only ARP (bound to IP-VRF) and MAC into MAC-VRF
--VERIFIER NOTES--
See https://mailarchive.ietf.org/arch/msg/bess/9pvIR6OysyFKso9rDRb-CJj7we8/

RFC 9218, "Extensible Prioritization Scheme for HTTP", June 2022

Source of RFC: httpbis (wit)

Errata ID: 7556
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Mo Zanaty
Date Reported: 2023-06-29
Rejected by: Murray Kucherawy
Date Rejected: 2023-07-17

Section 4.1 says:

The urgency (u) parameter value is Integer (see Section 3.3.1 of
[STRUCTURED-FIELDS]), between 0 and 7 inclusive, in descending order
of priority.

It should say:

The urgency (u) parameter value is Integer (see Section 3.3.1 of
[STRUCTURED-FIELDS]), between 0 and 7 inclusive, in ASCENDING order
of priority.

Notes:

The very next paragraph indicates ASCENDING order of priority:
"The smaller the value, the higher the precedence."
Minor nit: It is confusing and unnecessary to use "precedence" and "urgency" as aliases for "priority". Readers can be misled to think these are intended to be distinct properties rather than aliases.

[AD response] The operative phrase to me is "between 0 and 7 inclusive, in descending order of priority". I read that as a set of ordered values from 0 to 7 where the first value has the highest priority, the second value is down a notch, etc., hence, descending. The later phrase "The smaller the value, the higher the precedence" affirms this interpretation.
--VERIFIER NOTES--

RFC 9225, "Software Defects Considered Harmful", April 2022

Source of RFC: INDEPENDENT

Errata ID: 6910
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Joe Klein
Date Reported: 2022-04-01
Rejected by: Eliot Lear (ISE)
Date Rejected: 2022-08-21

Section 4. Best Current says:

6. In fact, assume all internal inputs also are the result of bugs.

It should say:

6. In fact, assume all internal inputs also are the result of bugs.

7. If the bug population increases after each subsequent software 
release, it is generally RECOMMENDED to deploy a Software Bug [BOMbs],
and return when the air has cleared.

[BOMbs] National Telecommunications and Information Administration,
United States Department of Commerce, 2021, https://ntia.gov/SBOM

Notes:

Extend the RFC to include another best practice, associated with BOMbs.
--VERIFIER NOTES--
Thanks for your thoughts. Follow-ups to this RFC are welcome, but must stand on their own merit.

RFC 9252, "BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)", July 2022

Source of RFC: bess (rtg)

Errata ID: 7357
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Kaliraj Vairavakkalai
Date Reported: 2023-02-16
Rejected by: James N Guichard
Date Rejected: 2023-05-31

Section 4 says:

   To achieve efficient packing, this document allows either 1) the
   encoding of the SRv6 Service SID as a whole in the SRv6 Services TLVs
   or 2) the encoding of only the common part of the SRv6 SID (e.g.,
   Locator) in the SRv6 Services TLVs and the encoding of the variable
   (e.g., Function or Argument parts) in the existing label fields
   specific to that service encoding.  This later form of encoding is
   referred to as the Transposition Scheme, where the SRv6 SID Structure
   Sub-Sub-TLV describes the sizes of the parts of the SRv6 SID and also
   indicates the offset of the variable part along with its length in
   the SRv6 SID value.  The use of the Transposition Scheme is
   RECOMMENDED for the specific service encodings that allow it, as
   described further in Sections 5 and 6.

It should say:

   To achieve efficient packing, this document allows either 1) the
   encoding of the SRv6 Service SID as a whole in the SRv6 Services TLVs
   or 2) the encoding of only the common part of the SRv6 SID (e.g.,
   Locator) in the SRv6 Services TLVs and the encoding of the variable
   (e.g., Function or Argument parts) in the existing label fields
   specific to that service encoding.  This later form of encoding is
   referred to as the Transposition Scheme, where the SRv6 SID Structure
   Sub-Sub-TLV describes the sizes of the parts of the SRv6 SID and also
   indicates the offset of the variable part along with its length in
   the SRv6 SID value.  The use of the Transposition Scheme is
   NOT RECOMMENDED in brownfield deployments where all participating BGP
   speakers may not support SRv6 forwarding, see Appendix X. 
   Transposition Scheme MAY be used if all speakers support procedures
   described in this document, for the specific service encodings that 
   allow it, and is encoded as described further in Sections 5 and 6.

Appendix X:

   Use of Transposition Scheme procedures may cause incorrect routing 
   in the following scenario:


                         RR1--+
                                \  +-------R2  [MPLS + SRv6]
                                 \ |
                         R1--------P-------R3  [MPLS only]
                   [MPLS + SRv6]   |
                                   +-------R4  [SRv6 only]

                     <---- Bidirectional Traffic ---->

            Figure: BGP L3VPN Interop between MPLS and SRv6 nodes

     This example shows a provider network with a mix of devices with
     different forwarding capabilities.  R1 and R2 support forwarding 
     both MPLS and SRv6 packets. R3 supports forwarding MPLS packets 
     only. R4 supports forwarding SRv6 packets only. All these nodes 
     have BGP session with Route Reflector RR1 which reflects routes 
     between these nodes with nexthop unchanged. BGP L3VPN (SAFI 128) 
     family is negotiated on these sessions.
            
     If SRv6 nodes R2, R1, R4 use Transposition Scheme described in 
     Section 4, it will cause misrouting at R3 because of 
     misinterpretation of the MPLS label field. Because of Transposition
     scheme, RFC 8277 encoded MPLS label field is not containing a valid
     MPLS label.

Notes:

Ref: https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/5
--VERIFIER NOTES--
The errata is a substantive change with new normative language. I am rejecting this errata on the basis that a discussion within the WG on these changes seems appropriate and if necessary an updated RFC is the correct vehicle rather than errata (Please see https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/ for guidance on the errata process).

RFC 9438, "CUBIC for Fast and Long-Distance Networks", August 2023

Source of RFC: tcpm (wit)

Errata ID: 7806
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Richard Scheffenegger
Date Reported: 2024-02-09
Rejected by: Martin Duke
Date Rejected: 2024-02-26

Section 4.1.2 says:

* cwndprior: Size of cwnd in segments at the time of setting ssthresh
  most recently, either upon exiting the first slow start or just
  before cwnd was reduced in the last congestion event.

It should say:

* cwndprior: Flight Size as defined in RFC5681 in segments at
  the time of setting ssthresh most recently, either upon exiting
  the first slow start or just before cwnd was reduced in the last
  congestion event.

Notes:

The implicit assumption appears to be, that only singular, isolated events happen during a cubic congestion control response. However, it is not uncommon that multiple events, such as loss, loss recovery initiation, followed by one or more RTOs happen. In many implementations, cwnd only properly tracks Flight Size while no loss recovery is going on. RFC5681 made it clear, that adjustments to ssthresh should be based off of the (estimated) Flightsize. Similarly, it appears prudent to observe Flight Size and not a potentially adjusted cwnd value here.

The observed effect of deriving cwnd_prior directly from cwnd, and not Flight Size is a deflated value for ssthresh, earlier transition from slow-start to congestion avoidance, and less rapid resumption of reasonable bandwidth after e.g. a burst loss event followed by a RTO.

RFC5681 section 7 has this to say around setting ssthresh:

The treatment of ssthresh on retransmission timeout was clarified.
In particular, ssthresh must be set to half the FlightSize on the
first retransmission of a given segment and then is held constant on
subsequent retransmissions of the same segment.
--VERIFIER NOTES--
The reporter and author agreed that Sec 4.6 is clear in this regard.

RFC 9450, "Reliable and Available Wireless (RAW) Use Cases", August 2023

Source of RFC: raw (rtg)

Errata ID: 7637
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Peter Yee
Date Reported: 2023-09-10
Rejected by: John Scudder
Date Rejected: 2024-01-11

Section 1 says:

IEEE 802.11 has identified a set of real applications
[IEEE80211RTA], which may use the IEEE802.11 standards.  They
typically emphasize strict end-to-end delay requirements.

It should say:

IEEE 802.11 has identified a set of real-time applications
[IEEE80211RTA], which may use the IEEE 802.11 standards.  They
typically emphasize strict end-to-end delay requirements.

Notes:

Given both the context and the title of the referenced document, "real-time" makes more sense here than "real".
--VERIFIER NOTES--
Authors note that "real" is intended, to mean "not just hypothetical." See https://mailarchive.ietf.org/arch/msg/raw/BRwbIzNaNVWgGo-fptJ2ZKAeOBc/

RFC 9460, "Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)", November 2023

Source of RFC: dnsop (ops)

Errata ID: 7871
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Shulhan
Date Reported: 2024-03-25
Rejected by: Warren Kumari (Ops AD)
Date Rejected: 2024-04-16

Section D.2 says:

example.com.   SVCB   1 foo.example.com. key667="hello\210qoo"

\# 32 (
00 01                                              ; priority
03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target
02 9b                                              ; key 667
00 09                                              ; length 9
68 65 6c 6c 6f d2 71 6f 6f                         ; value
)

\x00\x01                                           # priority
\x03foo\x07example\x03com\x00                      # target
\x02\x9b                                           # key 667
\x00\x09                                           # length 9
hello\xd2qoo                                       # value

It should say:

example.com.   SVCB   1 foo.example.com. key667="hello\210qoo"

\# 32 (
00 01                                              ; priority
03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target
02 9b                                              ; key 667
00 09                                              ; length 9
68 65 6c 6c 6f 88 71 6f 6f                         ; value
)

\x00\x01                                           # priority
\x03foo\x07example\x03com\x00                      # target
\x02\x9b                                           # key 667
\x00\x09                                           # length 9
hello\x88qoo                                       # value

Notes:

Original report:
The escaped octal number "\210" when encoded to hexadecimal should be "88" or "\x88", NOT "d2" or "\xd2".

The "d2" or "\xd2" is hexadecimal value for decimal number "210".


WK Edit: I am rejecting this Errata -- the display format (key667="hello\210qoo") is encoded using the DNS RFC1035 syntax, which specifies:
\DDD where each D is a digit is the octet corresponding to
the decimal number described by DDD.

This is, um, surprising to many, and a relatively common source of issues in the DNS parsing world.

I encourage future updates of the RFC to include a "footnote" / parenthetical pointing this out...
--VERIFIER NOTES--
I am rejecting this Errata -- the display format (key667="hello\210qoo") is encoded using the DNS RFC1035 syntax, which specifies:
\DDD where each D is a digit is the octet corresponding to
the decimal number described by DDD.

This is, um, surprising to many, and a relatively common source of issues in the DNS parsing world.

I encourage future updates of the RFC to include a "footnote" / parenthetical pointing this out...

Report New Errata